Accueil Blog Généralités Maîtrise d'ouvrage - Maîtrise d'oeuvre : la guerre des clans
Maîtrise d'ouvrage - Maîtrise d'oeuvre : la guerre des clans
(6 votes)
Mardi, 12 Août 2008 15:53

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:

  1. le choix du chef de projet,
  2. la disponibilité des membres de l'équipe
  3. 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)
Commentaires (3)Add Comment
...
Ecrit par Christophe, August 30, 2008
En réalité, le MOA, c'est celui qui paie : c'est donc le client (ou éventuellement son délégué). Le MOE, c'est le chef de projet, qui pilote la réalisation en optimisant le QCD du projet. Le MOA paie, et sera responsable de l'exploitation (au sens utilisation) du système au quotidien une fois que celui-ci est démarré.
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 !!
Abus
vote down
vote up
Votes: +0
...
Ecrit par Renaud, October 21, 2008
Christophe,

Votre commentaire fait appraître un problème de sémantique.

Dans mon article, je me sers de la définition de wikipédia comme référence, où la MOA est définie comme un pont entre les directions métiers et la DSI et "assure la responsabilité du pilotage du projet". La MOA est donc une entité distincte du client, des utilisateurs et des directions métiers. Si les 2 notions sont confondues, pourquoi utiliser le terme de MOA ?

Je suis complètement d'accord avec vous sur l'importance d'utiliser des métriques pour faciliter la communication. D'ailleurs PMA est le seul logiciel de gestion de projet à ma connaissance qui inclut la taille du périmètre dans ses indicateurs de base et suit ses évolutions dans le temps.

Pour conclure avec la notion de MOA, en tant qu'ancien DSI, je me sens presque insulté par la définition fournie dans wikipédia: "La maîtrise d’ouvrage est responsable de l’efficacité de l'organisation et des méthodes de travail autour des systèmes d'information." Quelle est alors le rôle de la Direction des Systèmes d'Information ?

L'informatique doit se départir de cette image négative de technicité et d'isolement pour en faire un partenaire et un puissant facilitateur.


Abus
vote down
vote up
Votes: +0
...
Ecrit par Christophe ALBERT, October 22, 2008
Pour mettre un peu d'eau aux moulins, je peux témoigner que dans l'organisation de mon entreprise (opérateur téléphonie), la tendance actuelle est au rapprochement (fusion serait le terme exact, mais les MOA ont la vie dure et la sensibilité fine) entre les deux "fonctions".
Raisons essentielles principales : beaucoup de guéguerres inutiles, une réactivité insuffisante du fait de l'exercice soit-disant incontournable de la "contractualisation au forfait", du manque de professionnalisme des MOA et de leur effectif insuffisant au regard de l'ampleur de la conduite du changement à mettre en oeuvre dans un univers aussi changeant que les télécoms et surtout les MOE sont montées en compétences sur les métiers des utilisateurs internes et externes, ce qui rend les MOA moins indispensables.
Abus
vote down
vote up
Votes: +0

Ecrivez un commentaire

busy
 
 

Flux RSS du Blog

S'abonner au flux

Voir aussi