Par Jean-Baptiste JOURDANT, Responsable de l’offre Management de projet chez CSP Formation
« -C’est plus possible ! C’est nous qui devons être en relation avec le prestataire ! Tu n’as pas le droit de leur parler en direct !
– OK, OK ! Pas besoin de s’énerver. Je voulais juste accélérer le mouvement et m’assurer que les informations passent bien des utilisateurs aux développeurs…»
Moi, je veux bien. Si le patron de la DSI le dit, je ne vais pas m’y opposer. Mais s’ils connaissaient un peu le sujet, ça m’arrangerait pour mon projet. Comment je vais faire maintenant ? Je suis le chef de projet, mon patron, c’est le commanditaire du projet et je n’ai pas de droit de parler à mes prestataires ! De plus, il y a un nombre d’intermédiaires hallucinants entre les extrêmes de ce projet, de l’utilisateur final au développeur. Avec une dégradation systématique de la compréhension du sujet à chaque étape. Comment faire ?
Avant tout, de quoi parle-t-on ?
Voyons la nature des interlocuteurs possibles sur un projet, dans la chaîne de responsabilités. Ces définitions ne sont pas universelles d’ailleurs et peuvent recouvrir différentes réalités suivant les domaines dans lesquels elles sont utilisées.
La Maîtrise d’Ouvrage (MOA) : c’est donneur d’ordre au profit de qui l’ouvrage est réalisé. En gros, le client.
La Maîtrise d’Œuvre (MOE) : c’est l’entité chargée de réaliser l’ouvrage. Le responsable des opérations nécessaires à son achèvement.
Les délégués : parfois, chacune de ses entités délègue tout ou partie de leur responsabilité à des spécialistes.
On parle de MOAD (MOA déléguée, capable de prendre des décisions) ou AMOA (Assistance à MOA, plutôt exécutante). On peut avoir des entités internes spécialisées (un bureau des projets, par exemple, dans son rôle support) ou des consultants externes.
On parle aussi de MOED (MOE déléguée, avec fort niveau d’engagement) ou d’assistance à MOE (interventions ponctuelles ou exécutions). Ce sont des sous-traitants ou prestataires qui assurent ces fonctions.
La chaine de la « dé-valeur »
Je reviens maintenant sur mon projet de SI, que j’illustrais par le dialogue d’introduction.
Dans la première organisation mise en place, le CP MOA est placé comme « coordinateur » central du projet, avec une structure interne « MOAD » en support des opérations méthodologiques « projet ». Peu de rapport entre cette structure MOAD et la MOE sous-traitée.
Dans cette organisation, 2 comités de pilotage sont mis en place : Comité externe (CP MOA et client externe) et un comité de pilotage interne (CP MOA et CP MOAD). Avec évidemment les hiérarchies concernées. Le responsable et pilote de la réalisation est bien entendu le CP MOA, qui dans les faits cumule (en interne) les responsabilités de MOA et MOE, puisque la MOE est externe.
Évidemment, chaque sous-organisation produit ses tableaux de bord et a sa propre vision de l’avancement et de la santé du projet.
Suite à la soufflante du DSI, une nouvelle organisation est peu à peu mise en place.
Dans cette organisation, la MOA reste dans un rôle purement « défense des intérêts de son client » (commanditaire et utilisateurs). La structure interne de support aux projets reprend un rôle de MOE et devient responsable de la réalisation devant la MOA. Les comités mis en place deviennent le Comité de pilotage de « l’ouvrage » (CP MOA avec les utilisateurs) et le comité de pilotage de « l’œuvre » (CP MOE avec le prestataire et le CP MOA).
Quel bazar !
Dans cette nouvelle disposition à trois chefs de projets et deux comités de pilotage, une couche théorique s’est ajoutée et l’utilisateur s’est encore éloigné du producteur.
Comment faire pour limiter les incompréhensions entre ces représentants ?
Comment assurer une bonne adéquation entre le besoin et le livrable ?
Est-il vraiment nécessaire d’avoir autant de chefs de projets… au même niveau, sur le même projet ?
Ne peut-on pas avoir un unique comité de pilotage ?
Rationalisons !
Tout d’abord les chefs de projets.
- Le CP MOA n’est pas le chef de projet. Il porte le besoin et garantit la satisfaction du client. Il recueille, exprime, recadre, arbitre, informe. Il est MOA. On peut l’appeler CP MOA. Mais si un chef de projet MOE est nommé à l’intérieur de l’organisation, ce sera bien lui le chef du projet. Avec une relation « client-fournisseur » interne.
- Le CP MOE, est celui qui coordonne l’ensemble des activités sur le projet. Il garantit 2 axes principaux : la communication transverse et l’application de la méthodologie de management de projet. Il s’assure de la bonne information des parties prenantes en temps réel, diffuse les tableaux de bord, gère les risques et s’assure de la résolution correcte de tout problème.
- La MOE déléguée pour réaliser l’ouvrage met en place une équipe projet de producteurs et d’experts. Chef de projet MOE délégué ? Oui, bien sûr, mais dans son entité propre.
Nos deux comités de pilotage ?
Plus vraiment. Il reste UN comité de pilotage animé par le CP MOE. De part et d’autres (côté client et côté prestataire) restent des réunions de suivi, de surveillance, d’avancement. Mais il ne s’agit plus de pilotage.
Les livrables méthodologiques ?
Entre les deux organisations, les tableaux de bords (TDB) ont été recentrés sur le chef de projet (CP MOE) et le cahier des charges fonctionnel lui a échu. Si ce n’est pas le cas, il risque de rester une « boîte aux lettres », un organisateur, un gestionnaire de projet. L’appropriation de la maîtrise fonctionnelle est l’espace critique de sa crédibilité.
Conclusion ?
En phase d’avant projet (type SI), lorsque la solution n’est pas encore définie, la MOA définit un pilote de cette phase. Un « chef de projet » en charge de cadrer le projet, identifier les risques majeurs, construire un business plan, recueillir la structure des besoins, évaluer pertinence et faisabilité.
Il peut être le chef de projet MOE responsable de la réalisation, en dialogue avec le commanditaire. Mais, il peut aussi n’être que « l’avocat » de la MOA.
Dans ce cas, il sera important lors de la phase de planification du projet et au plus tard au démarrage de l’exécution, d’avoir défini clairement les rôles et responsabilités de la chaîne de transformation du besoin en charges fonctionnelles, en solution technique puis en solution opérationnelle.
Et quelle que soit l’organisation choisie, le chef de projet, unique, devra :
1° garantir la plus grande fluidité de la communication entre acteurs « éloignés », en créant autant de points de rencontres que nécessaires,
2° maîtriser l’application des meilleures pratiques méthodologiques tout au long du projet.
<!–[if !mso]> <! st1\:*{behavior:url(#ieooui) } –>
Maîtrises ?
Par Jean-Baptiste JOURDANT,
Responsable de l’offre Management de projet chez CSP Formation
« -C’est plus possible ! C’est nous qui devons être en relation avec le prestataire ! Tu n’as pas le droit de leur parler en direct !
– OK, OK ! Pas besoin de s’énerver. Je voulais juste accélérer le mouvement et m’assurer que les informations passent bien des utilisateurs aux développeurs…»
Moi, je veux bien. Si le patron de la DSI le dit, je ne vais pas m’y opposer. Mais s’ils connaissaient un peu le sujet, ça m’arrangerait pour mon projet. Comment je vais faire maintenant ? Je suis le chef de projet, mon patron, c’est le commanditaire du projet et je n’ai pas de droit de parler à mes prestataires ! De plus, il y a un nombre d’intermédiaires hallucinants entre les extrêmes de ce projet, de l’utilisateur final au développeur. Avec une dégradation systématique de la compréhension du sujet à chaque étape. Comment faire ?
Avant tout, de quoi parle-t-on ?
Voyons la nature des interlocuteurs possibles sur un projet, dans la chaine de responsabilités. Ces définitions ne sont pas universelles d’ailleurs et peuvent recouvrir différentes réalités suivant les domaines dans lesquels elles sont utilisées.
La Maitrise d’Ouvrage (MOA) : c’est donneur d’ordre au profit de qui l’ouvrage est réalisé. En gros, le client.
La Maitrise d’Œuvre (MOE) : c’est l’entité chargée de réaliser l’ouvrage. Le responsable des opérations nécessaires à son achèvement.
Les délégués : parfois, chacune de ses entités délègue tout ou partie de leur responsabilité à des spécialistes.
On parle de MOAD (MOA déléguée, capable de prendre des décisions) ou AMOA (Assistance à MOA, plutôt exécutante). On peut avoir des entités internes spécialisées (un bureau des projets, par exemple, dans son rôle support) ou des consultants externes.
On parle aussi de MOED (MOE déléguée, avec fort niveau d’engagement) ou d’assistance à MOE (interventions ponctuelles ou exécutions). Ce sont des sous-traitants ou prestataires qui assurent ces fonctions.
La chaine de la « dé-valeur »
Je reviens maintenant sur mon projet de SI, que j’illustrais par le dialogue d’introduction.
Dans la première organisation mise en place, le CP MOA est placé comme « coordinateur » central du projet, avec une structure interne « MOAD » en support des opérations méthodologiques « projet ». Peu de rapport entre cette structure MOAD et la MOE sous-traitée.
Dans cette organisation, 2 comités de pilotage sont mis en place : Comité externe (CP MOA et client externe) et un comité de pilotage interne (CP MOA et CP MOAD). Avec évidemment les hiérarchies concernées. Le responsable et pilote de la réalisation est bien entendu le CP MOA, qui dans les faits cumule (en interne) les responsabilités de MOA et MOE, puisque la MOE est externe.
Evidemment, chaque sous-organisation produit ses tableaux de bord et a sa propre vision de l’avancement et de la santé du projet.
Suite à la soufflante du DSI, une nouvelle organisation est peu à peu mise en place.
Dans cette organisation, la MOA reste dans un rôle purement « défense des intérêts de son client » (commanditaire et utilisateurs). La structure interne de support aux projets reprend un rôle de MOE et devient responsable de la réalisation devant la MOA. Les comités mis en place deviennent le Comité de pilotage de « l’ouvrage » (CP MOA avec les utilisateurs) et le comité de pilotage de « l’œuvre » (CP MOE avec le prestataire et le CP MOA).
Quel bazar !
Dans cette nouvelle disposition à trois chefs de projets et deux comités de pilotage, une couche théorique s’est ajoutée et l’utilisateur s’est encore éloigné du producteur.
Comment faire pour limiter les incompréhensions entre ces représentants ?
Comment assurer une bonne adéquation entre le besoin et le livrable ?
Est-il vraiment nécessaire d’avoir autant de chefs de projets… au même niveau, sur le même projet ?
Ne peut-on pas avoir un unique comité de pilotage ?
Rationalisons !
Tout d’abord les chefs de projets.
Le CP MOA n’est pas le chef de projet. Il porte le besoin et garantit la satisfaction du client. Il recueille, exprime, recadre, arbitre, informe. Il est MOA. On peut l’appeler CP MOA. Mais si un chef de projet MOE est nommé à l’intérieur de l’organisation, ce sera bien lui le chef du projet. Avec une relation « client-fournisseur » interne.
Le CP MOE, est celui qui coordonne l’ensemble des activités sur le projet. Il garantit 2 axes principaux : la communication transverse et l’application de la méthodologie de management de projet. Il s’assure de la bonne information des parties prenantes en temps réel, diffuse les tableaux de bord, gère les risques et s’assure de la résolution correcte de tout problème.
La MOE déléguée pour réaliser l’ouvrage met en place une équipe projet de producteurs et d’experts. Chef de projet MOE délégué ? Oui, bien sûr, mais dans son entité propre.
Nos deux comités de pilotage ?
Plus vraiment. Il reste UN comité de pilotage animé par le CP MOE. De part et d’autres (côté client et côté prestataire) restent des réunions de suivi, de surveillance, d’avancement. Mais il ne s’agit plus de pilotage.
Les livrables méthodologiques ?
Entre les deux organisations, les tableaux de bords (TDB) ont été recentrés sur le chef de projet (CP MOE) et le cahier des charges fonctionnel lui a échu. Si ce n’est pas le cas, il risque de rester une « boîte aux lettres », un organisateur, un gestionnaire de projet. L’appropriation de la maîtrise fonctionnelle est l’espace critique de sa crédibilité.
Conclusion ?
En phase d’avant projet (type SI), lorsque la solution n’est pas encore définie, la MOA définit un pilote de cette phase. Un « chef de projet » en charge de cadrer le projet, identifier les risques majeurs, construire un business plan, recueillir la structure des besoins, évaluer pertinence et faisabilité.
Il peut être le chef de projet MOE responsable de la réalisation, en dialogue avec le commanditaire. Mais, il peut aussi n’être que « l’avocat » de la MOA.
Dans ce cas, il sera important lors de la phase de planification du projet et au plus tard au démarrage de l’exécution, d’avoir défini clairement les rôles et responsabilités de la chaine de transformation du besoin en charges fonctionnelles, en solution technique puis en solution opérationnelle.
Et quelle que soit l’organisation choisie, le chef de projet, unique, devra :
1° garantir la plus grande fluidité de la communication entre acteurs « éloignés », en créant autant de points de rencontres que nécessaires,
2° maîtriser l’application des meilleures pratiques méthodologiques tout au long du projet.
Cette demande vous semble-t-elle étrange ? Êtes-vous comme de nombreux PMs qui fuient les audits comme la grippe H1N1 ? Les considérez-vous comme une perte de temps au mieux et un assassin potentiel de projet dans les cas extrêmes ? 
Par exemple, pendant un projet de construction et déploiement de progiciel de gestion intégrée (PGI), nous avons eu un audit interne. Une fois compris que le focus était essentiellement de s’assurer que nous contrôlions correctement dépenses et risques, il fut facile pour l’équipe de fournir les évidences de ce que nous faisions dans ces domaines. Nous avons montré notre processus de suivi des dépenses, notre méthode de suivi des affectations, le journal des questions ouvertes et le registre des risques. Le responsable financier a été rassuré par les résultats de l’audit. De plus, les auditeurs nous ont aidés à aller plus loin dans notre management des risques en nous permettant d’organiser une session de revue et de brainstorming sur les risques avec le comité exécutif du projet.
Vous devriez aussi prendre en compte le fait que les auditeurs feront certainement des points de suivi avec la direction et les commanditaires. Ils partageront leur état avancement à ces sessions, exposeront leurs découvertes, testeront leurs idées initiales (pour voir les réactions potentielles) et, plus tard, ils présenteront leurs recommandations (intermédiaires puis finales).
Sur de nombreux projets, vous constaterez que les auditeurs vous aideront énormément à améliorer certains aspects comme le contrôle du périmètre, la rigueur dans la gestion des demandes de changement ou l’engagement de vos sponsors dans le management des risques. Les auditeurs portent un œil externe sur votre projet et sont donc bien plus objectifs que vous ne pouvez l’être.
Does this title sound odd to you? Are you like many PMs trying to escape audits as much as possible? Do you consider them as a waste of time at best and a potential killer in extreme cases?
For example, we were audited during an Enterprise Resource Planning (ERP) system construction and deployment. It was an internal audit. Once we understood that the focus was essentially to ensure that we were in control of project spend and managing the risks correctly, it was easy for the team to provide clear evidence of what we were doing in these areas. We showed our expenses tracking process, time tracking method, issues log and risk register. The Chief Finance Officer was reassured by the findings. Additionally, the auditors helped us to further highlight our top risks to the steering committee during a specific risk management brainstorming and review session with them.
You should also consider that the auditors will most certainly have some checkpoints with management and audit sponsors. They will share their progress at these sessions, expose findings, test the water on initial ideas (to see potential reactions), and at a later stage present recommendations (draft and final).
We shared our recommendations with the project team before management and also helped define and put in place action plans to address the identified issues. We even followed up after the audit on execution of these action plans. This, I am sure, was much more beneficial to the company than a one-off report.
As a conclusion, I suggest that if your project is not yet being audited, you consider which areas could be improved using external advice and eventually solicit an audit on these: Get help before someone above you decides that you need to be helped.
DantotsuPM.com 