Mais il est où le Chef de Projet ?

De l’importance de reconnaître les rôles d’un projet

L'intérêt d'une bonne communicaton en conduite de projet

L'intérêt d'une bonne communication en conduite de projet

Le contexte : intervenant en conseil auprès d’une institution du secteur de la culture très investie dans l’ingénierie de médiation numérique, j’ai été amené à participer au dénouement de certains « nœuds », à l’identification de points durs et à la cartographie de zones pas très franches dans lesquelles prospéraient à peu près tous les risques que peut affronter un projet ; pour ce faire, j’avais proposé à mon client de placer chaque acteur de ses projets sur une grille de rôles et identifier qui prend quelles prérogatives mais aussi quelles responsabilités et comment il est supposé fonctionner.

Je vous livre ces rôles. Rien de très original pour qui a un peu d’expérience de projets, mais c’est juste ma synthèse. Un peu de méthode. À débattre en commentaire.

La maîtrise d’ouvrage (MOA)

Le maître d’ouvrage sait exprimer ses besoins. Il veille à ne pas s’engager dans la formulation de solutions. En revanche, il formule ses exigences fonctionnelles et non fonctionnelles. Il sait définir les critères de qualité qui lui permettront d’évaluer les livrables de la maîtrise d’œuvre (voir ci-après) afin de les accepter ou de les rejeter (ou de les négocier). Il s’engage à fournir les éléments dont a besoin la maîtrise d’œuvre pour développer. Il adopte et assume des processus de prise de décision consistants tout au long d’un projet. Il emploie avec compétence des outils de travail collaboratif en interne, comme avec ses prestataires. Il veille à une bonne circulation de l’information en interne. Il est fier de la qualité des productions qu’il a imaginées et fait réaliser, et le fait savoir. L’entreprise porteuse de projets se doit au minimum d’assumer son rôle de maître d’ouvrage. La MOA peut se décomposer en deux rôles.

La MOA « Métier »

Les responsables de production et d’exploitation, ceux qui commandent le produit au nom des utilisateurs dont ils ont la charge ou qu’ils représentent. Ils sont les premiers en charge de l’expression de besoins, le recensement des contraintes et des autres postes de cahier des charges.

La MOA « technique »ou « digitale » ou « support »

En charge de la conduite de projet de développement du côté MOA, porteur de méthodologie, peut être un spécialiste des techniques mises en œuvre, interlocuteur en interface de la MOA Métier et de la MOE, en développements agiles, il sera appelé « Product Owner ». Une entreprise qui a la chance de disposer de MOA support pourra professionnaliser sa relation avec ses prestataires intervenant en MOE, que ceux-ci soient tiers, ou internes à l’organisation.

La maîtrise d’œuvre (MŒ)

L’acteur en charge de la MŒ est garant de la bonne réalisation technique des produits développés et tirant le meilleur parti des techniques. Il a un devoir de conseil vis à vis du MOA. Lorsque la réalisation du produit doit faire appel à plusieurs prestataires ou compétences, le MOE coordonne ceux-ci et s’assure de la qualité des livrables et du respect des délais. Avant toute livraison en recette, le MOE teste les livrables selon une méthodologie rigoureuse qui permet de s’assurer de la conformité du produit aux spécifications et exigences.
Une complexité apparaît lorsque tout ou partie d’un projet est confié à des personnels internes pour réalisation : quelles exigences ? quel contrat de service ? quelle maintenance ? quelle adéquation réelle des compétences aux besoins ? quelle articulation avec les prestataires tiers ?

Les prestataires

Sous la conduite de la MOE, ou directement de la MOA technique pour de très petits projets ne nécessitant pas de coordination ni ne présentant de dépendances complexes, les prestataires ont une fonction technique circonscrite : expertise, architecture d’information, design, concepteur d’expérience utilisateur, modeleur, intégrateur web, développeur, opérateur de tests (TRA), opérateur de maintenance (TMA), intégrateur de systèmes et réseaux, référenceur, photographe, réalisateur audiovisuel, flasheur, rédacteur, technicien régie…

La gouvernance

Garant de la bonne prise en compte des enjeux politiques et stratégiques mais aussi du respect des engagements éventuellement pris par l’entreprise vis à vis de partenaires tiers, l’organes de gouvernance du projet (« comité de pilotage ») doit donner aux participants opérationnels le cadre nécessaire à la réussite de leurs missions. En particuliers devront être définis les règles de décision applicables, les critères d’évaluation des résultats produits, les modalités de circulation de l’information, les prérogatives et responsabilités des acteurs…

Un peu d'humour. Quoi que...

Un peu d'humour. Quoi que...

Mais… où est le Chef De Projet ?

Sous l’influence des méthodes agiles, la fonction de « chef de projet » a tendance à s’estomper. Cela ne signifie pas qu’il faille renoncer à une fonction de pilotage. Toutefois, la vision traditionnelle du « chef » (même si elle avait considérablement été enrichie ces dernières années) cède la place à celle d’un facilitateur — le Scrum master, dans une équipe de développement agile pratiquant Scrum — partenaire du « Product Owner » représentant les utilisateurs et lui même en interface avec les tenant des besoins métiers. C’est pourquoi les fonctions qui permettent de partager une vision de l’avancement du projet — liste de jalons, tâches et sous-tâches, planning, affectation de ressources au projet… — si elles ne sont pas assumées directement par un membre de la MOA (technique, de préférence) ou de la MOE (et attention à ne pas laisser se développer 2 versions du projet !) peuvent être dévolues à un profil de « secrétaire de projet », qui s’attachera à tenir à jour les tableaux de bords nécessaires au management pour s’assurer du bon déroulement du projet et anticiper au maximum sur l’apparition de dérives.

Oui, bon, mais pour ma PME ? Il faut être une peu polyvalent, non ?

Certes, la décomposition en organes de gouvernance, MOA Métier + support, MOE, Prestataires semble plutôt taillée pour les organisations nombreuses et hiérarchiques. Toutes les entreprises n’auront simplement pas assez de monde pour jouer chaque rôle. Et les projets ne seront pas assez gros pour le justifier. Cependant, garder à l’esprit que, incarnés par une ou plusieurs personnes, ou assumés par un seul « chef de projet » chacun de ces rôles a une mission qui doit être remplie. Les prestataires livrent à la MOE. La MOE livre à la MOA qui réceptionne. La MOA Métier remonte tous les besoins et les formalise… Il n’y a que des inconvénients à négliger, au nom d’un prétendu pragmatisme, le caractère systémique de tout projet.

Ami lecteur, tu es concerné par l’un de ces rôles ? Que penses-tu de cette vision ? Ton expérience… ?

Ce contenu a été publié dans e-business, avec comme mot(s)-clé(s) , , , , , , , , , . Vous pouvez le mettre en favoris avec ce permalien.
  • http://twitter.com/jay_wyler Jay W.

    Intéressant comme descriptif des rôles,et les illustrations sont très pertinentes !
    Bien entendu cela n’est applicable que pour des grosses structures. Dans une structure moyenne, voir petite, le MOE à tendance à disparaître, une partie de son travail est pris en charge par le MOA et l’autre par le prestataire.
    Il me semble que le principal problème dans la gestion de projet, c’est le respect par les différents acteurs, du cahier des charges. Du COPIL qui change d’avis à chaque réunion, au prestataire qui tout d’un coup décide d’opter pour une autre solution que celle établie dans la propal, le rôle du chef de projet est avant tout celui de garde fou, En réunion du copil, je passais souvent mon temps à faire comprendre que facteurs temps super sérré + facteurs budget ultra limité = pas possible de revenir sur les décisions déjà actés, cela peut-être compliqué lorsqu’on se retrouve face à une pléthore d’officiel, de directeurs en tout genre, qui pensent bien entendu tout savoir sur tout. Il faut savoir faire preuve de beaucoup de pédagogie et de diplomatie. De l’autre côté, car on sera forcément amené à faire des compromis, il est important de ne pas trop modifier le rapport de force avec le prestataire, à force de modification et de changement de route, le prestataire peut rapidement décider d’accepter mais selon ses propres conditions et exigences… Le chef de projet doit donc se placer en tant qu’interlocuteur légitime avec le prestataire, pour cela il se doit aussi d’être force de proposition et de s’approprier d’une certaine manière, les changements de cap, ne pas laisser le prestataire définir seul la maîtrise d’oeuvre. Il s’agit de conserver sa légitimité et de garder le contrôle des opérations, cela entraîne des responsabilités supplémentaires certes, mais il vaut toujours mieux défendre auprès d’un copil inquiet une décision prise soit même que de dire,  vous nous avez demandé ceci, alors le prestataire à fait cela. On tire toujours sur le messager, et le chef de projet se doit d’être toujours plus que le messager, il se doit d’être l’avocat du parti absent. Savoir défendre un point de vue, mettre les acteurs face à leur responsabilité, sans jamais incriminer personne sauf ce bon vieux contexte, c’est ça qui sauve le chef de projet ! 

    Dernier point, les outils de contrôle, de suivi, la rigueur des phases de recettes… généralement au bout de deux jours, les seuls outils de communication qui tiennent la route, ce sont les mails et le téléphone.  On pense à tort trop souvent qu’on perd du temps à se servir de ce type d’outil et il est difficile de faire comprendre aux différents acteurs que c’est un investissement pour une conduite de projet rigoureuse. 
    Une des valeurs ajoutés d’un chef de projet c’est réussir à fédérer, non pas uniquement autour d’un projet commun, mais d’un espace de travail collaboratif intelligent et efficace. On se retrouve trop souvent avec cinq versions différentes d’un tableau de suivi, et des rapports de bug dans des mails. bref un casse tête pour le chef de projet ne serait-ce que de transmettre toutes les informations. 

    voilà un petit retour d’expérience d’un chef de projet web… j’dois vous laisser, j’ai des rapports de bug à terminer.

    • http://www.fxbodin.com/fx/ François-Xavier Bodin

      Merci pour ce retour d’expérience très riche Jérémy. Juste une observation sur les comités de pilotage qui changent d’avis à chaque réunion. En toute rigueur (on peut rêver ?) en même temps qu’il formule ses attentes / exigences / objectifs politiques, s’il formule en regard les critères d’évaluation, alors il ne devrait avoir qu’à juger de la conformité aux critères ; du TDD appliqué à la gouvernance. Ce que l’on observe IRL, ce sont des comités de pilotage à qui l’on demande des arbitrages : outrepasser une « deadline », renoncer à des fonctionnalités, ou pire, à un niveau de qualité, assumer des demandes d’avenants financiers… Mais il s’agit alors d’un projet en crise…

  • http://twitter.com/jay_wyler Jay W.

    Oui mais ce sont bien ces critères d’évaluations qui font le plus souvent défaut ! Cela a souvent été mon rôle de faire des choix d’arbitrage que je soumettais au COPIL notamment dans la suppression de fonctionnalité pour pouvoir rester dans le cadre financier et respecter les deadline. Soumettre les solutions à la gouvernance, encore une tâche qui incombe au chef de projet IRL ! 
    Un autre aspect du rôle du chef de projet sur mon blog d’ailleurs ( un peu d’auto-promo au passage…)  : http://schizophrenia.jeremywyler.fr/lodysee-dun-ergonome-en-herbe/