Votre organisme souhaite mettre en place une méthodologie centralisée de management de projet, et la décliner sur les différents projets, en particulier à l’aide des plans de management.

Cette fiche propose de lever le voile sur les fonctions et sur les activités associées à ce type de PMO.

Dans certains organismes, les métiers de PMO sont des métiers relativement nouveaux en comparaison à d’autres métiers d’ingénieurs, qu’ils soient généralistes ou spécialistes.

En fonction du positionnement du PMO au sein de l’organisme (rattaché au « Project Management Office » ou intégré au projet), celui-ci est soumis à des influences très différentes.

Cette fiche se propose de travailler spécifiquement sur ce type de PMO et les spécificités de ses relations avec le « Project Management Office ».

La fonction de Project Management Officer est une fonction relativement nouvelle dans les organisations si on la compare à des fonctions comme celles de comptable, de mécanicien ou de directeur général. De plus, le trigramme anglo-saxon signifiant Project Management Office (ou Officer si l’on parle de l’individu) contribue à accentuer le flou sur la définition et le rôle dudit PMO.

Cette fiche se propose donc d’apporter une vision la plus large possible sur les activités que peut être amené à effectuer un Project Management Officer au sein de l’industrie. Ne sont pas traitées dans cette fiche les activités de Project Management Officer dans d’autres secteurs comme la banque ou l’assurance, par exemple.

Lorsque l’on parle de management de projet, l’attention est généralement focalisée sur le chef de projet, perçu comme « l’homme-orchestre » capable de tout résoudre avec son « couteau suisse ». Dans les petits projets, celui-ci est en effet souvent le seul affecté à l’animation et est amené à réaliser l’ensemble des tâches de management. Cette vision est cependant réductrice de la réalité de la plupart des projets et contribue à masquer la technicité et le rôle des autres membres de l’équipe projet.

Cette fiche vous présente le rôle du « Risk Manager ». Celui-ci est garant au sein du projet de la mise sous contrôle des risques et de leur maîtrise pendant toute la durée de celui-ci.

Le Risk Manager d’une équipe projet est en charge de dérouler l’ensemble des processus lié à la gestion des risques sur le projet.

Pour y parvenir, on retrouve dans le PMBOK les processus suivants :

• planification du management des risques ;
• identification des risques ;
• mise en œuvre de l’analyse qualitative des risques ;
• mise en œuvre de l’analyse quantitative des risques ;
• planification des réponses aux risques ;
• maîtrise des risques.

Une fois cette analyse terminée, le projet est sous contrôle sous l’angle de la gestion des risques.

Cependant, la question se pose de savoir quels risques remonter aux instances de gouvernance.

Quelle méthode utiliser :

• remonter les risques financiers les plus importants en impact ?
• remonter les risques financiers pondérés les plus importants ?
• ...

Ce questionnement prend un sens encore plus opérationnel lorsqu’il s’agit non plus de remonter les risques d’un seul projet, mais d’un programme tout entier.

Cette fiche propose des éléments de réponse à cette problématique.

L’analyse de risques est une discipline transverse qui met en œuvre un grand nombre de métiers et de compétences. Le Risk manager, tout comme le chef de projet, ne peut et ne doit pas être un homme-orchestre mais bien un chef d’orchestre. En effet, le Risk manager, s’il est souvent ingénieur généraliste ou spécialisé, ne peut pas être un expert de tous les domaines qui interviennent dans la création et la mise à jour d’une analyse de risques (mécanique, neutronique, juridique, commercial…).

La présente fiche se propose d’analyser le rôle des acteurs dans la démarche d’analyse de risques avec un focus particulier sur le chef de projet et sur le Risk manager.

Le retour d’expérience a cela de particulier que tout le monde en parle mais que très peu de personnes ne le formalisent. Il n’est pas rare d’entendre des chefs de projets ou des membres de l’équipe projet dire qu’il faudra penser à faire un REX sur le sujet. Cependant, qui en est responsable ? Comment le formaliser ? Et quel est le livrable ? Des questions qui restent souvent sans réponses.

Deux explications à cela. La première est que, pour beaucoup, le REX concerne le passé. Ce qui est une erreur car c’est justement en capitalisant que l’on construit plus sereinement le futur et que l’on gagne un temps précieux dans les projets de demain.

La seconde explication tient au fait que, dans une société de l’information, la posséder revient à posséder le pouvoir. L’individu a peur qu’en capitalisant son expérience, il perde de son importance, voire sa raison d’être, au sein de l’entreprise. Or, tout au contraire, en partageant cette expérience dans le cadre du REX, le « sachant » se pose en expert du domaine, capable de prendre du recul sur les réalisations et d’en tirer les points positifs et les points d’amélioration.

Vous êtes chef de projet et votre entreprise vous demande de mettre en œuvre une nouvelle méthode pour suivre l’état d’avancement de votre projet : la méthode de la valeur acquise. Vous lisez la procédure, commencez à mettre en œuvre le processus avec le planificateur et le gestionnaire des coûts du projet et vous vous dites que cette méthode est extraordinaire car elle va vous permettre de complètement piloter votre projet.

STOP. Il est temps de faire une pause et de rester réaliste. Premièrement, la méthode de la valeur acquise ne peut en aucun cas vous permettre de piloter votre projet car, pour piloter une « formule 1 », vous avez besoin d’un volant. Or dans le cas présent, on ne vous fournit que le compteur de vitesse et le compte-tours. La méthode de la valeur acquise vous présente l’état de votre projet, c’est un indicateur ; en aucun cas, elle ne vous fournit les leviers pour maintenir ou corriger la trajectoire pour arriver à destination. De plus, pour que l’indicateur fournisse une représentation fidèle de la réalité de la situation à un instant T, il est essentiel d’avoir correctement étalonné le compteur et de s’être assuré qu’on est bien dans le domaine de valeurs dans lequel le compteur fournit des informations pertinentes.... L’objectif de cette fiche est précisément de vous donner des clés afin d’utiliser au mieux cette méthode.

Au sein d’un projet, les questions suivantes se posent souvent :

• ce « risque » est-il une incertitude technique ou un aléa ?
• comment intégrer les incertitudes techniques et les aléas dans le planning ?
• n’a-t-on pas compté deux fois les mêmes « risques », à la fois dans le budget et dans l’analyse de risques ?

C’est à ce type de questions que cette fiche se propose de répondre.

Cette fiche donne les clés pour construire un tableau de bord projet efficace.

Cette construction se fait en trois points :

• la définition des indicateurs « standard » ;
• la définition d’indicateurs permettant de s’adapter aux spécificités du projet ;
• la construction du tableau de bord à partir des indicateurs précédemment définis.

Les deux concepts clés sont :

• la nécessaire simplicité et reproductibilité des indicateurs sélectionnés ;
• la cohérence d’ensemble que doit assurer le tableau de bord.

La définition du périmètre d’un projet est l’une des premières phases d’un projet. Elle permet de définir ce qui sera à l’intérieur du projet et ce qui sera à l’extérieur de celui-ci. Cette notion est essentielle car elle aidera ensuite le chef de projet à caractériser ce qui devra être fait au titre du contrat, et ce qui pourra faire l’objet d’avenants (donc de ressources financières supplémentaires pour le projet).

Dans cette logique, il convient de bien différencier ce qui est de la responsabilité du projet et de son déroulement – on parle alors de cycle de vie du projet – d’une notion bien plus large dans laquelle s’inscrit le produit – on parle alors de cycle de vie du produit.

Cette fiche propose également d’expliquer comment s’articulent les différents processus de management de projet durant le déroulement d’un projet.

Cette fiche recense et donne des éléments de réponse aux questions que ne manque pas de se poser le planificateur utilisant un outil informatique pour planifier un projet.

En effet, avant de commencer la planification d’un projet, on peut s’interroger sur :

• les données d’entrée de l’outil ;
• le type d’outil utilisé (collaboratif ou non) ;
• les représentations souhaitées du projet (vision par installation, sous-projet, etc.) ;
• les calendriers à définir ;
• les extractions du planning nécessaires (extraction vers un fichier Excel pour créer des courbes d’avancement physique ou des courbes temps/temps, fichier .csv pour dialogue avec SAP, etc.) ;
• les différents affichages possibles du planning (pour le client, les partenaires, les sous-traitants) ;
• la mise en forme graphique (ce que l’on veut mettre en avant graphiquement).

Cette fiche explique comment construire un organigramme des tâches afin de regrouper de manière optimale l’ensemble des travaux à réaliser au sein d’un projet.

L’organigramme des tâches est essentiel avant de passer aux tâches fines de planification. En effet, il permet de s’assurer que toutes les actions à mener sont bien référencées et organisées en ce sens. Il est la donnée d’entrée fondamentale du planning.

Il permet également d’avoir une décomposition commune et cohérente entre les disciplines de planification et de gestion des coûts.

La création de cet organigramme aboutit à la définition de lots de travaux. C’est précisément dans la définition de ces lots de travaux que réside la difficulté mais aussi l’intérêt de ce travail de structuration de projet. Chacun des lots doit avoir une taille suffisante pour conserver une vision macroscopique du travail global à réaliser mais raisonnable pour être confié à un responsable de lot qui sera garant de la tenue des délais, du budget, de la qualité et de la conformité technique de son contenu.

Note : Il est très important de différencier l’organigramme des tâches (OT) de l’arborescence produit (ou « Product Breakdown Structure » - PBS) et de l’organigramme fonctionnel (OF, ou Organizational breakdown structure, OBS). Ce dernier représente la structure des différents niveaux de responsabilités dans le projet.