|
Pourquoi ne retrouve-t'on pas les concepts de MOE1 et de MOA2 dans les standards internationaux (CMMI, PMbok, Prince2, Spice...) ?
Connaissez-vous une traduction en anglais qui soit totalement satisfaisante pour le domaine informatique ?
Les concepts de MOE/MOA en Informatique sont une exception "à la française". Or il n'existe aucune étude montrant l'intérêt d'une telle organisation dans les projets informatiques ou qui justifierait cette exception.
En fait, il y a de multiples inconvénients à une telle approche. Car elle crée systématiquement 2 clans avec leur propre chef: d'un côté la MOA et de l'autre la MOE.
Les 2 chefs appartiendront en général à des services différents: une direction métier pour la MOA et la DSI pour l'informatique. Le projet risque alors de devenir le contexte d'une guerre de clans digne d'une époque moyenâgeuse.
Les principaux risques d'une telle organisation sont:
- le développement de visions divergentes du projet à l'origine de malentendus
- une communication entre les équipes moins rapide et moins efficace car plus contrôlée
- d'avoir le projet contaminé par les dissensions entre les services
- l'installation d'un climat de méfiance
- la possibilité de reporter la faute sur l'autre équipe
Cependant cette scission en MOA/MOE n'est nullement nécessaire.
Il s'agit d'un héritage du domaine de la construction (BTP). Or le parallèle entre les projets informatiques et les projets de construction trouve rapidement ses limites.
D'ailleurs, il existe un autre exemple de transposition douteuse du domaine du BTP vers l'Informatique: le cycle en cascade. Celui-ci a finalement été supplanté après maints échecs par les méthodes itératives, voir les méthodes agiles.
La meilleure solution est d'avoir: un projet, un seul chef, une équipe soudée constituée de personnes des différents services.
Il faudra pour cela surmonter 3 difficultés:
- le choix du chef de projet,
- la disponibilité des membres de l'équipe
- les difficultés de communication dans une équipe hétérogène.
Les difficultés 1 et 2 ne sont pas nouvelles et sont à l'origine de l'apparition des modes d'organisation par projet et matricielle. Il importe surtout que le chef de projet dispose d'une autorité suffisante et d'une qualification adéquate.
La dernière difficulté sera résolue en amont du projet d'autant plus facilement que les personnes appartiennent à la même équipe et travaillent ensemble.
En fait, il y a un cas où la séparation en 2 clans est inévitable: c'est lorsqu'on fait appel à un prestataire externe. Dans ce cas, le couple MOA/MOE s'apparente à une relation Client / Fournisseur, ce qui se traduit sans problème en anglais.
PS: Pour ceux qui rechercheraientt malgré tout une traduction anglaise de MOA et MOE, vous trouverez quelques éléments de réponses dans ce forum.
Trackback(0)
 |
Se connecter à PMA
S'abonner au flux 
Blog 
TrackBack URI for this entry
RSS feed Comments
Affichez les commentaires
Ajoutez un commentaire
Cette distinction est donc bien utile dans le cadre d'une relation client / fournisseur.
Dans une grande entreprise, le MOA est le représentant dans le projet de la direction utilisatrice du logiciel, et le MOE le chef de projet coté direction informatique. La traduction "Business Owner" est plus explicite : le MOA, c'est le propriétaire du processus métier automatisé. La fonction de MOE est temporaire (la durée du projet), mais le MOA devra ensuite rester le garant du système au quotidien et en demander des évolutions ...
Pour faciliter la relation MOA / MOE, l'utilisation d'une métrique, comme les points de fonction, peut faciliter les échanges, en aidant à répondre à la question : est-ce que le système est cher à cause d'une faible productivité des équipes informatiques, ou bien parce qu'il est très grand et très complexe (ce qu'il faut mesurer avec une méthode comme l'analyse points fonctions).
En revanche, on trouve aussi parfois plusieurs chefs de projet dans un même projet informatique : un chef de projet MOE (lien entre le métier et l'informatique), patron du projet et devrant délivrer le produit/process dans les délais en respectant le budget, un 2ème "chef de projet informatique front-office" dont le rôle est de délivrer le produit informatique (dans les délais) ; un 3ème chef de projet informatique "back-office" qui pilote vraiment le développement. Là, cela commence vraiment à faire beaucoup et à devenir très lourd et très cher !!