PRINCE2 (PROjects IN Controlled Environments) est une méthode structurée de gestion de projet et un programme de certification de praticiens. PRINCE2 met l’accent sur la division des projets en étapes gérables et contrôlables. Il est adopté dans de nombreux pays du monde, notamment au Royaume-Uni, dans les pays d’Europe occidentale et en Australie.

PRINCE2 a été développé en tant que norme du gouvernement britannique pour les projets de systèmes d’information. En juillet 2013, la propriété des droits sur PRINCE2 a été transférée de HM Cabinet Office à AXELOS Ltd, une joint-venture entre le Cabinet Office et Capita, avec respectivement 49% et 51% des parts.

Le présent article tend à présenter les différents aspects de la méthode.

L’article présentera les 7 processus permettant la gestion d’un projet en Prince2

1. Démarrage d’un projet, dans lequel l’équipe de projet est nommée, y compris un cadre et un chef de projet, et un dossier de projet est produit
2. Lancer un projet, dans lequel l’analyse de rentabilisation est affinée et la documentation de lancement du projet est assemblée
3. Diriger un projet, qui dicte la manière dont le comité de direction du projet supervise le projet
4. Contrôler une étape, qui dicte la manière dont chaque étape doit être contrôlée, y compris la manière dont les lots de travaux sont autorisés et distribués
5. Gérer la livraison du produit, qui a pour objectif de contrôler le lien entre le chef de projet et le ou les chefs d’équipe en imposant des exigences formelles sur l’acceptation, l’exécution et la livraison du travail du projet.
6. Gestion des limites d’étape, qui dicte comment passer d’une étape à l’autre
7. Clôture d’un projet, qui couvre le déclassement formel du projet, les actions de suivi et l’évaluation des avantages.

On découvrira la terminologie de la méthodologie ainsi que les différents aspects organisationnels pour aboutir à la réussite de son projet.

LA MÉTHODE PRINCE2

Gérer un projet selon PRINCE2

L’ensemble des chapitres de cette première partie est centré sur la façon dont la méthode PRINCE2 conseille de gérer un projet, quelle que soit sa nature.

Ces chapitres décrivent donc la méthode telle qu’elle est, mais aussi précisent quelques concepts qui ne sont pas explicites en eux-mêmes.

Qu’est-ce que PRINCE2 ?

Objectif

PRINCE2 est une méthode non exclusive largement utilisée dans plus de 150 pays à travers le monde. De par son approche novatrice et fiable, cette méthode est considérée comme la meilleure méthode de gestion de projet, et plus de 20 000 organisations en bénéficient déjà. Cela est dû en grande partie au fait que PRINCE2 est véritable ment générique et adaptable à n’importe quel type de projet, indépendamment de sa dimension, de l’organisation qui le supporte, de sa localisation géographique ou de la culture qui le met en œuvre.

Les paragraphes qui suivent présentent la genèse de cette méthode et les quelques difficultés de lecture liées à cette genèse.

ORIGINE DE PRINCE2

PRINCE2, acronyme de PRoject IN Controlled Environments est une méthode développée sous le contrôle de l’OGC, Office of Government Commerce, dont le premier propriétaire a été le CCTA (Central Computer and Telecomunications Agency) et qui appartient actuellement au Cabinet Office.

La méthode PRINCE2, dérivée de la méthode PROMPTII, a été publiée en 1996 en tant que méthode de projet générique.

En 2006, la méthode a été revue pour l’adapter à l’environnement, rendre la méthode plus simple et l’intégrer aux autres méthodes de l’OGC.

En juin 2010, à la suite d’une réorganisation du gouvernement du Royaume-Uni, l’ensemble des référentiels a été transféré au Cabinet Office.

Le Cabinet Office présente d’autres référentiels que PRINCE2. Ces référentiels proposent des conseils pratiques, adaptables et efficaces, tirés d’expériences réussies mais aussi de retour d’expérience d’échecs cuisants. Réduites à leurs éléments essentiels, les expériences traduites dans ces référentiels peuvent être appliquées à tout type d’entreprise et d’organisation. Ces référentiels ont contribué à améliorer les processus et les opérations pour les organisations de toutes tailles — y compris les petites entreprises, les organismes du secteur public et des grandes entreprises internationales.

Le portefeuille de référentiels ainsi constitué présente un large éventail des meilleures pratiques de gestion. Des informations complémentaires peuvent être trouvées en visitant les sites Web des produits spécifiques ci-dessous :

• PRojects IN Controlled Environments (PRINCE2@) — for Project management, Managing Successful Programmes (MSP@) — for Program management,
• Management of Risk (M o R@) — for risk management,
• IT Service Management (ITIL@) — for IT service management,
• Management of Portfolios (MoPTM ) — for portfolio management, Management of Value (MoVTM ) — for value management, e Portfolio, Program and Project Offices (P30@),
• Portfolio, program and Project management maturity model (P3M3@).

Ces référentiels sont complémentaires, soit parce qu’ils apportent des précisions sur différents aspects, soit parce qu’ils participent à la gouvernance globale d’une organisation.

En 2013, le gouvernement britannique a décidé de céder les droits de PRINCE2 ainsi que d’ITIL à une société privée CAPITA qui exploite ces droits au sein d’une société nommée AXELOS.

PRÉCAUTIONS DE LECTURE

PRINCE2 étant une méthode d’origine anglo-saxonne, rédigée intégralement en anglais, il est parfois difficile de traduire l’esprit de la méthode par des mots équivalents Ln d’une autre langue.

Dans ce livre, il n’est pas question de reprendre la traduction en français de l’ouvrage qui fait référence, par ailleurs de très bonne qualité, mais d’éclairer le lecteur quant à des termes « abusivement » traduits ou par définition diversement interprétables. Quand des termes anglais sont plus appropriés, car passés dans le langage courant professionnel, ils sont sciemment utilisés ou indiqués dans ce livre.

Exemples de difficultés

La traduction de « Business Case » par « Cas d’Affaire » semblait inutile car « Cas d’Affaire » est un néologisme : pour preuve, sur la toile, à part les sites plus ou moins dédiés à PRINCE2 et quelques sites anglophones dont la traduction est douteuse, cette expression n’existe pas. « Dossier commercial » aurait certainement été plus proche, bien que trop connoté « commerce Vouloir traduire ce terme est équivalent à vouloir traduire « marketing » : cela est inutile et source de confusion.

L’utilisation des deux termes « avancement » et « progression », qui dans le langage courant sont synonymes, peut engendrer une confusion. Dans la version de 2005, les traductions de « Highlight Report » et « Checkpoint Report » étaient « rapport de point clef » et « rapport de point de contrôle ». Dans la version de 2009 (celle dont il est question dans cet ouvrage), les traductions sont respectivement « Rapport de Progression » et « Rapport d’Avancement ». Il aurait été plus astucieux, quitte à ne pas traduire mot à mot, d’utiliser par exemple « Rapport au COPIL » et « Rapport au Chef de Projet », ou « Rapport de Séquence » et « Rapport de Lot de Travaux ».

Les leçons tirées de l’expérience sont habituellement nommées « Retours d’Expérience » dans le langage courant professionnel, avec comme diminutif « REX ».

« Stage » a été traduit par « séquence » et non par « phase » ou « étapes », certainement pour éviter la confusion avec les phases du projet (préprojet, initialisation, réalisation et clôture). De plus, la lettre « S » en début de mot permet de ne pas confondre avec Projet et Phase dans les acronymes des noms de processus (« DP », « EP », IP ») qui ne sont pas utilisés dans cet article.

La critique est facile, mais l’art de la bonne traduction est plus complexe. De plus, les sociétés ou organisations françaises ne se sont pas bousculées pour aider Andy Murray, auteur principal, à écrire l’ouvrage de référence.

Remercions les auteurs de ne pas avoir reproduit un piège que l’on retrouve par exemple dans ITIL, qui sous le terme de « problème » désigne ce qui n’en est pas un dans le langage courant, mais qui ressemblerait simplement à une « cause d’un incident ». Le référentiel CMMI a d’ailleurs intelligemment franchi l’obstacle en utilisant la terminologie « Analyse Causale » ce qui semble parfaitement clair et représentatif du sujet.

Afin de conserver un vocabulaire commun et en usage lors des certifications, nous o utiliserons la traduction officielle, en complétant l’idée sous-jacente lorsque cela paraît nécessaire.

Dans le cadre de l’adoption de la méthode, les auteurs recommandent d’adapter le vocabulaire aux us et coutumes de l’organisation adoptant PRINCE2, facilitant ainsi l’emploi de PRINCE2.

Convention de syntaxe et définitions préalables

Pour aider à la lecture, des conventions ont été utilisées et certaines définitions préalables sont nécessaires.

Les noms ou groupe de mots désignant des objets spécifiques à la méthode PRINCE2, ou pour lesquels il est intéressant d’attirer l’attention du lecteur, ont une capitale en première lettre des noms, par exemple : le produit Exposé de projet ou le processus Initialiser le projet.

Les premières occurrences de ces objets sont en caractères gras pour marquer le caractère important de la syntaxe de l’objet ainsi désigné.

En italique figure le texte qui est extrait directement de l’ouvrage Réussir le management de projet avec PRINCE2 ou d’autres ouvrages conçus sous l’égide du Cabinet Office. Les autres citations d’auteurs sont simplement placées entre guillemets.

Focus sur le vocabulaire PRINCE2

La notion de produit est très importante pour PRINCE2, le Produit de Projet (ou les Produits de Projet) est ce que le projet doit livrer au final, que ce soit un pont, une application ou un immeuble. Un Produit désigne tout livrable ou composant que le projet doit fournir, c’est un constituant du Produit de Projet, comme un pilier de pont, une pièce d’une application informatique ou les fondations de l’immeuble. Les Produits de Management ne sont pas des composants des Produits, ils permettent le projet, ce sont des documentations, des enregistrements, des rapports, des outils ou des instances. Enfin les Produits Spécialistes désignent les produits techniques créés par les équipes de réalisation.

Une Séquence désigne une étape identifiée de la vie du projet. Une Séquence technique correspond au temps consacré pour réaliser les produits de la séquence en question, la Séquence de Management recouvre une à plusieurs Séquences technique, elle correspond à la vision qu’ont les responsables du projet.

L’Acceptation d’un produit désigne la validation et la ratification du Produit de Projet, alors que l’Approbation ne concerne qu’un ou plusieurs produits.

Le terme Qualité recouvre un concept différent de ce que son qualificatif suggère. Un objet de qualité désigne dans le langage courant quelque chose de bien, de bon, de beau, alors qu’il se réfère ici uniquement aux caractéristiques techniques d’un produit. Ces caractéristiques doivent être mesurables pour que l’on puisse les valider.

La Surveillance désigne les activités nécessaires pour vérifier que des tâches ou processus sont en cours, alors que le Contrôle s’attache plus généralement à la o vérification des résultats de ce que ces tâches fournissent.

Bien que souvent employé, le terme Prioriser n’existe pas dans la langue française. Ln Il signifie donner une priorité.

On désigne par le nom Organisation, l’entreprise ou l’établissement client dont va dépendre le projet. PRINCE2 suppose que le projet est mandaté par une organisation nommée de façon générique Entreprise ou par un Programme qui peut être compris comme un ensemble de projets.

Bien que parfaitement synonymes, les termes de Progression et d’Avancement doivent être considérés de façon particulière dans PRINCE2 lorsqu’ils sont associés à un Rapport, car ils désignent alors un échange d’informations entre des niveaux hiérarchiques différents.

Le terme Assurance doit être pris sous deux acceptations. Il désigne soit les activités nécessaires pour s’assurer de quelque chose, soit l’entité responsable pour partie de ces activités.

Pourquoi une méthode ?

Objectif

De nombreuses études statistiques montrent que les projets sont loin d’obtenir les résultats escomptés lorsqu’ils arrivent à terme et que les budgets d’origine ont souvent été dépassés.

Parmi ces études, celles du Standish Group font référence. Elles se basent parfois sur une théorie du chaos qui résume ce que ressentent les acteurs d’un projet.

Les chapitres suivants présentent ces thèmes, sachant que les données du Standish Group serviront de fil conducteur à cet ouvrage afin d’apprécier la méthode PRINCE2.

DE LA THÉORIE DU CHAOS

Selon Wikipedia : « La théorie du chaos traite des systèmes dynamiques rigoureusement déterministes, mais qui présentent un phénomène fondamental d’instabilité appelé ” sensibilité aux conditions initiales ” qui, modulant une propriété supplémentaire de récurrence, les rend non prédictibles en pratique à ” long ” terme. »

La théorie du chaos est née d’études menées par le grand scientifique méconnu Henri Poincaré, père de la physique moderne, contemporain des Curie, Rutherford ou Langevin et dont certains prétendent qu’il est le véritable géniteur de théorie de la relativité restreinte.

Cette théorie scientifique du chaos, qui s’applique à des phénomènes physiques, pourrait être reprise au compte de nos projets, souvent imprédictibles, complexes et présentant une sensibilité aux conditions initiales incertaines. Ceci tend à prouver que certains phénomènes sont imprédictibles car par trop instables et que l’entropie latente universelle tend à nous décourager de toute tentative de prédiction.

LE CHAOS REPORT

Pas étonnant que ce nom de Chaos Report ait été donné à une étude menée depuis la fin des années 1970 par le Standish Group, étude qui porte sur l’analyse des causes d’échec de projets informatiques et leur progression d’année en année. Il n’y a pas de quoi être fier, car même si les chiffres sont contestables dans leur analyse, les résultats semblent prouver que seulement 37 % des projets informatiques sont totalement réussis. Encore faudrait-il analyser ces chiffres en sachant que plus de 90 % des projets s’arrêtent et redémarrent une à plusieurs fois avant d’aboutir.

Tableau 2.1 Évolution de la réussite des projets informatiques.

Les enquêtes réalisées par le Standish Group sont aussi exhaustives que possible. Les résultats sont basés sur des campagnes de recherche et des entretiens avec des cadres informatiques. L’échantillon comprenait des grandes, moyennes et petites entreprises de secteurs majeurs, comme la banque, la finance, l’industrie, le commerce de détail et de gros, la santé, l’assurance, les services, les organismes locaux, étatiques et fédéraux. L’échantillon total était de 365 entreprises et a concerné 8 380 applications (données 1995).

Dans le cadre du Chaos Report, les projets ont été classés selon trois types :

• Projet réussi : le projet est terminé dans les temps et respecte le budget et le o périmètre initial
• Projet dégradé : le projet est terminé et opérationnel, mais dépasse le budget et le délai initial, et est à moindre périmètre ;
• Projet annulé : le projet est annulé en cours de développement.

L’aspect le plus intéressant de l’étude est de découvrir pourquoi les projets échouent en général. C’est un excellent retour d’expérience. Pour ce faire, le Standish Group a interrogé des cadres informatiques afin qu’ils donnent leur opinion concernant les raisons déterminant la réussite des projets.

Les quatre principales raisons permettant à un projet d’aboutir sont la participation des utilisateurs, appui des dirigeants, un énoncé clair des exigences, et une planification adéquate.

Identification d’un Projet

Sans eux, le risque d’échec augmente de façon spectaculaire.

D’autres facteurs sont mis en avant dans le tableau suivant.

Tableau 2.2 — Les différents facteurs de réussite d’un projet.

Connaissant ces chiffres, essayer de palier par une méthodologie tout ou partie des facteurs de risque, c’est tenter de réduire le risque d’échec du projet en lui-même. Sachant qu’en la matière comme dans d’autres, le risque zéro n’existe pas.

Tout au long de cet ouvrage consacré à PRINCE2, les concepts de la méthode sont mis en relation avec ces facteurs de réussite afin de vérifier en quoi cette méthode de gestion de projet répond à ces facteurs de risque.

IDENTIFICATION D’UN PROJET

Nous l’avons vu, tout peut être sujet à projet, mais tout n’est pas projet. Pour cerner ce qui pourrait être un projet, le mieux est de rechercher les caractéristiques qui le o distinguent des opérations courantes.

Le Changement : sans changement apporté, il n’y a pas de projet et l’activité déployée ne sera qu’une activité dans la continuité des opérations courantes, récurrentes, certainement génératrice de plus de valeur pour l’entreprise, mais sans apport de renouveau. C’est souvent ce caractère qui fait l’attrait d’un projet.

L’Unicité : aucun projet ne ressemble à un autre. Un autre projet rassemblera d’autres équipes à une date différente dans un contexte particulier. Même semblables, tous les projets sont différents.

L’Inter-fonctionnalité : le changement est toujours le fruit d’une collaboration d’acteurs d’horizons différents qui tous concourent au succès du projet. Ceci dans le meilleur des cas, car en réalité, cette disparité de formation, de culture et souvent d’intérêt provoque des tensions préjudiciables au projet. A l’inverse, considérons que le caractère multidisciplinaire d’un projet apporte une richesse qu’il y a lieu d’exploiter cette richesse est dans tous les cas indispensables pour obtenir un résultat accompli.

L’aspect temporaire : un projet s’inscrit dans le temps, il est temporaire, possède un début et, espérons-le, une fin définie, qui lui donneront d’ailleurs ce caractère unique.

L’incertitude : beaucoup plus que les opérations courantes, tout projet présente au moins un risque, ne serait-ce que de ne pas aboutir, ou à l’inverse, d’arriver à concrétiser ce pour quoi il a été fait. Tant il est vrai que cette incertitude que l’on nomme risque présente à la fois un volet Menace, mais également un aspect Opportunité.

La gestion des projets n’est pas une science nouvelle, et son association avec la gestion des risques non plus selon Luc de Clapiers, Marquis de Vauvenargue au XVIII e siècle, « La science des projets consiste à prévenir les difficultés de l’exécution. »

LA NÉCESSITÉ D’UNE MÉTHODE

Le tout n’est pas de « faire des projets » au sens positif et populaire du terme, encore faut-il les réaliser. C’est à ce moment que les ennuis commencent, car passer du rêve, de la projection, à la réalité est souvent difficile, voire impossible. Les raisons de cette difficulté sont multiples. Simples humains, souvent nous ne disposons pas de ressources (au sens de moyens) infinies. Disposerions-nous de ces ressources, que nos capacités (savoir-faire) seraient à coup sûr limitées.

Les contraintes

En cela vous trouvez les premières limites d’un projet, mais également les premières questions à se poser avant d’entreprendre tout projet : Avons-nous les ressources et les capacités pour le mener à bien ?

La première question que nous allons nous poser concerne donc la faisabilité du projet en prenant en compte nos forces, tout en gardant à l’esprit que « le jeu doit en valoir la chandelle ». Autrement dit, que les bénéfices escomptés générés par le projet restent supérieurs aux efforts à fournir. Entendez par Bénéfice tout ce que peut o engendrer le projet, pas seulement l’intérêt pécuniaire, ni un simple rapport entre ce qui est dépensé et ce qui est obtenu, mais également parfois une obligation légale, Ln une contrainte réglementaire, une décision stratégique à laquelle l’entreprise doit répondre.

La viabilité

Des événements extérieurs peuvent, au cours du projet, affecter ce bénéfice et rendre caduc le projet en lui-même. Ce constat permet de se rendre compte que ce qui pourrait n’être perçu que comme une question initiale est en fait une question qui doit rester omniprésente à l’esprit des personnes concernées par le projet. Le type de démarche récurrente qu’implique une méthode permet d’éviter des dépenses inutiles dans des projets qui ne livreront que de piètres bénéfices, si jamais ils aboutissent. Laissons le soin à chacun d’illustrer par ses propres exemples la nécessité de ce qui précède, les projets non aboutis sont nombreux, toutes les études montrent qu’avec un peu de discernement ces projets auraient dû être arrêtés à temps et peut-être même ne pas être commencés.

Une fois personnellement convaincu que le projet est réalisable et porteur de bénéfice, il nous faut aussi convaincre des partenaires qui peuvent être réticents aux changements. Pour les convaincre, nous allons devoir leur communiquer les éléments qui prônent la nécessité de réaliser le projet, leur exposer le plus clairement possible les arguments qui nous font penser que le projet est porteur de bénéfice, mais aussi réalisable. Cet argumentaire doit s’accompagner de réponses aux questions « comment », « avec quoi » et « avec qui » se fera le projet, permettant ainsi à ces partenaires de se projeter dans le projet et d’être convaincus qu’il est viable.

La préparation

90 % de la réussite est dans la préparation, ce ne sont pas les sportifs de haut niveau ni même les joggeurs du dimanche qui contrediront cela. Avant de mettre en oeuvre les ressources et moyens nécessaires au projet, encore faut-il les identifier et être en mesure de les réquisitionner. Rarement « nous partîmes 500 pour arriver 3 000 au port », ce serait plutôt l’inverse. Et ce n’est pas le dénombrement des forces qui en fait la force, mais leur organisation, leur préparation et leur détermination.

Identifier ces ressources (moyens) et aptitudes (savoir-faire) ne suffit pas si leur concours au projet n’est pas clairement défini. En d’autres termes, insuffler la volonté de participer au projet et clarifier les « redevabilités » et interactions de chacun est, sinon indispensable, du moins nécessaire. Il s’agit d’organiser dans le temps les différents produits et tâches à accomplir après les avoir définis, et faire partager cette vision du futur. Cette activité se concrétise souvent par un plan de bataille, de bâtiment, de voyage… ou par le renoncement, au regard de tous les obstacles à surmonter.

Cette phase est primordiale car elle garantit qu’avant de commencer à réaliser le projet, nous allons nous assurer que nous maîtrisons suffisamment les ressources et les savoir-faire pour le mener à bien. Il n’est bien entendu pas question de tout o maîtriser, c’est une utopie, mais au moins de nous doter des outils et de la conviction que nos chances de réussite sont maximales. Cette phase permet également de se doter des moyens nécessaires pour répondre aux objections plus ou moins positives de nos partenaires et des associés au projet.

Rendre des comptes

Dotés de moyens et convaincus de notre savoir-faire, nous allons pouvoir concrètement passer aux réalisations nécessaires au projet. Parce que nous sommes en quelque sorte « sponsorisés par ceux qui nous ont financés, appuyés ou seulement encouragés, nous devons leur rendre des comptes. Savoir leur communiquer que le projet reste viable, qu’il progresse et apporte même déjà des améliorations, ne serait-ce que la certitude que nous sommes sur le bon chemin est indispensable car ces sponsors doivent continuer à nous « supporter », c’est-à-dire continuer à nous apporter conseils et préconisations. Ils peuvent aussi éventuellement nous informer de ce qu’ils apprennent ou savent de ce qui pourrait impacter le projet. Mais ces sponsors ne sont pas à notre disposition, si nous voulons les intéresser, il faut organiser des réunions de compte rendu à des moments pendant lesquels ils seront disponibles.

Reprenez les quelques paragraphes qui précèdent, traduisez-les dans votre langage et dans les termes de votre métier, utilisez votre bon sens, et vous aurez la méthode que vous recherchez. C’est ce qu’ont fait les auteurs de la méthode PRINCE2, en fixant un vocabulaire commun à une méthode logique et universelle de gestion de projet prenant en compte son environnement,

Selon Maurice Blondel, « L’avenir ne se prévoit pas, il se prépare » .

Que propose PRINCE2 ?

Objectif

PRINCE2 s’appuie sur trois concepts importants : les principes, les thèmes et les processus. En nombre restreint, ils permettent de structurer la démarche de gestion de projet de façon simple et pragmatique.

Ce chapitre introduit ces trois concepts, détaillés dans les chapitres suivants, et les raisons qui conduisent à l’adoption de PRINCE2.

STRUCTURE DE PRINCE2

A l’inverse de nombreux référentiels qui ont multiplié le nombre de leurs processus ces dernières années (20, 30, plus de 40 processus pour certains), PRINCE2 dans sa version de 2009 a réduit à sept le nombre de ses processus pour clarifier sa démarche projet. Soyons-leur reconnaissants, tant il est vrai que faire compliqué est simple, rendre accessible est un exercice difficile. Comme l’a écrit Anton Tchekhov : « La brièveté est sœur du talent ».

Les processus suivent le phasage de tout projet, soit le préprojet, le démarrage de projet, la réalisation et enfin la fin du projet, et mettent en avant les activités souvent récurrentes à mener pour faire progresser le projet.

Les auteurs de PRINCE2 ont introduit de façon intelligente des principes et des thèmes pour compléter ces processus en expliquant ce qu’étaient pour eux les fondamentaux de la gestion de projet (les Principes) et donnant un éclairage particulier sur ce qui pouvait concourir à cette activité (les Thèmes).

Les principes servent à expliquer ce qui est intangible sur un projet PRINCE2. Tout projet se réclamant de la méthode PRINCE2 se doit de respecter ces principes.

L’adoption de ces principes est indispensable à toute organisation qui voudrait gérer des projets à l’aide de la méthode PRINCE2. A l’inverse, ne pas adopter ces principes engendre inéluctablement des interprétations préjudiciables et revient à manquer de la rigueur nécessaire prônée par cette méthode.

Les thèmes abordent certains aspects essentiels de la gestion de projet. Ils sont adaptables et fournissent les bases des disciplines essentielles de la gestion de projet, comme la planification, la gestion de la qualité ou celle des risques. Mais ils fournissent également un éclairage particulier sur certains aspects de la gestion de projet, comme le Cas d’Affaire, l’Organisation, la prise en compte des événements tels les Changements en cours de projet ou le contrôle de la Progression.

Les thèmes sont les suivant :

• Le Cas d’Affaire,
• L’Organisation,
• La Qualité,
• Les Plans,
• Les Risques,
• Les Changements,
• La Progression.

Parce qu’un projet est dépendant de son environnement, il est nécessaire de le prendre en compte, c’est-à-dire d’adapter le projet à cet environnement. Comprenez adapter l’utilisation de la méthode PRINCE2 aux particularités du projet en temps que tel (taille, risque, complexité, etc.), mais également à ce qui est extérieur au projet mais qui peut l’impacter (métier, culture, maturité, etc.).

Figure 3.1 — Processus, Thèmes et Principes.

Les paramètres de régulation

Un projet PRINCE2 repose donc sur l’utilisation de processus étayés par des thèmes adaptés à l’environnement et en accord avec des principes fondamentaux et intangibles.

Il existe 7 processus, 7 thèmes et 7 principes.

Selon Sénèque, « Ce n’est pas parce que c’est difficile que l’on n’ose pas. C’est parce que l’on n’ose pas que c’est difficile ».

Six paramètres délimitant un projet

L’activité de contrôle ne doit pas se faire sans discernement mais en identifiant les paramètres permettant de réguler un projet.

Appelés également variables ou aspects de performance d’un projet, ces SIX paramètres seront au cœur des surveillances et contrôles que va devoir mener le Chef de Projet.

Les deux variables de pilotage les plus connues et les plus utilisées sont évidemment le délai et le coût. De façon commune, nous nous fixons un objectif avec une date de fin et tentons de limiter les coûts.

Mais d’autres paramètres interviennent, car respecter les délais et les coûts d’un projet n’augure pas que le projet répondra aux attentes, c’est-à-dire ses caractéristiques Qualité, et une définition claire du Périmètre du projet, c’est-à-dire ce qui est inclus dans le projet et de ce fait ce qui en est exclu.

Si le délai et le coût sont des inducteurs du projet par le fait qu’ils induisent des contraintes au sens négatif du terme, la qualité et le périmètre sont souvent des incontournables qui définissent le “Produit de Projet”, et c’est ce qui restera du projet.

Prenons l’exemple de la construction d’une maison, nous aimerions qu’elle nous coûte le moins cher possible et qu’elle soit terminée au plus tôt, mais nous n’accepterions pas d’habiter dans une maison dont le toit fuit (problème de qualité) ou livrée sans toutes les huisseries (problème de périmètre).

Cet exemple est simpliste car la construction d’une maison est suffisamment courante pour ne laisser que peu d’inconnues. Dans un projet complexe, par son ampleur ou son caractère innovant, beaucoup d’inconnues existent au démarrage du projet ou ne seront identifiées qu’au cours du projet. Se mettre d’accord sur le périmètre et sur la qualité des livrables est donc indispensable car ceci est la source première des retards et dérapages d’un projet, et surtout de l’insatisfaction des parties prenantes. Il s’agit de gérer au mieux les Exigences des utilisateurs relativement à tous les autres aspects du projet.

Ne pas commencer un projet dont le périmètre et la qualité sont aussi précisément définis que possible, devrait être la règle d’or de tout bon Chef de Projet et de toute organisation ayant la responsabilité d’un projet. Le Chef de projet ne fait souvent que proposer, là où l’entreprise dispose.

Mesurer les risques et les bénéfices

En complément à ces quatre paramètres qui bornent et définissent le projet, PRINCE2 ajoute la quantification des risques et la détermination des bénéfices du projet. Ces deux paramètres sont des paramètres de raison, ce sont des « garde-fous ».

La quantification du risque permet de s’assurer, au début et tout au long du projet, que l’on a une chance raisonnable d’atteindre notre objectif. Ceci parce que l’on aura pris le soin d’estimer tous les risques et éventuellement de les juguler quand cela est possible. Rien ne sert de commencer la construction de notre maison si nous n’avons pas la certitude (ou presque) d’obtenir notre permis de construire ou notre prêt bancaire.

Figure 3.2 — Les 6 caractéristiques universelles ou aspects d’un projet.

Rares sont les projets qui ne « dérivent » pas en coût, délai, qualité ou périmètre. Conserver à l’esprit le bénéfice attendu par le projet (c’est-à-dire se demander si le jeu en vaut toujours la chandelle) permet de savoir arrêter à temps un gaspillage inutile. Que ce soit dans l’industrie, dans les services ou dans l’administration. Nous avons tous à l’esprit des projets parfois pharaoniques qui n’ont jamais eu comme utilité que de répondre aux délires maniaques d’un homme ou d’une organisation. Ce n’est pas l’hydravion « Wild Goose » d’Howard Hughes, octo-moteurs presque aussi gros que l’Airbus A380, ni simplement les piscines désaffectées et autres bâtisses vides dont nous finançons l’entretien qui viendront contredire ce fait. Mais ces projets chimériques ont conduit également à « l’invention » de l’Amérique ou à Apollo Il

Les paramètres de régulation

Victor Hugo a bien résumé cette situation, selon lui :

« Une idée fixe aboutit à la folie ou à l’héroïsme ».

Savoir arrêter un projet qui ne mènera pas aux bénéfices escomptés est une décision difficile à prendre mais certainement plus méritoire que de persévérer dans une mauvaise voie.

Comme beaucoup de chefs de projet, j’ai appris sur le tas, sinon sur le tard. J’ai notamment été responsable de la partie numérique d’un projet qui consistait à automatiser les tests d’un composant d’un avion, pour lequel le client a dépensé quelques millions de francs de l’époque.

En fin de projet, très fier du travail réalisé par toute l’équipe, je présentais l’ensemble des installations qui tenait à peine dans un cube de 20 m de côté, aboutissement de deux ans d’effort. Un technicien me sourit et me glissa à l’oreille : « Sais-tu comment nos concurrents remplacent tout ce bazar ? Ils installent le composant sur un avion en exploitation commerciale et le testent simplement en condition réelle d’utilisation ».

Nous avions travaillé pendant des mois à reproduire au sol des conditions de température, de pression et d’hygrométrie complexes, qui existent simplement en altitude. Ne me demandez pas les raisons qui ont conduit à ce projet qui par ailleurs ne permettait même pas de tester le composant en question pour tous les types d’avions, ni dans tous les types de configuration.

J’ai aussi participé à un projet connexe à celui de la « Carte Pastel », qui devait permettre de téléphoner d’une cabine ou de chez vos voisins et amis sans que ceux-ci n’en subissent les coûts, projet intéressant mais complètement dépassé alors que le GSM pointait son nez et que le BIPBOP était arrêté en Angleterre la semaine où il démarrait en France. J’ai échappé de justesse au projet de transport d’icebergs vers la péninsule arabique, et à d’autres que je ne citerais pas pour ne vexer personne

Mais encore une fois, la critique est facile !

« Si vous voulez aller sur la mer sans aucun risque, n’achetez pas un bateau, achetez une île ! » Marcel Pagnol

Réponse de ce chapitre aux facteurs de réussite du projet

Tout au long de cet ouvrage consacré à PRINCE2, les concepts de la méthode sont mis en relation avec ces facteurs de réussite fournis par l’étude CHAOS afin de vérifier en quoi cette méthode de gestion de projet répond à ces facteurs de risque.

La colonne « Primaire » est cochée quand le concept ou les idées développées dans le chapitre sont en complète adéquation avec les facteurs de réussite du projet selon l’étude CHAOS. La colonne « Secondaire » quand ces mêmes éléments sont en relation mais ne répondent pas exactement à la préoccupation liée du facteur de réussite.

Les six aspects d’un projet permettent de clarifier les exigences et les contraintes du projet, de faire partager la vision et les objectifs en les spécifiant, mais aussi de clarifier l’appartenance du projet en déterminant au profit de qui sera réalisé le projet.

Tableau 3.1 — Relation entre le CHAOS et les 6 aspects du projet.

POURQUOI ADOPTER PRINCE2 ?

Les raisons d’adopter la méthodologie PRINCE2 sont multiples. Elles sont liées essentiellement à la volonté de partage de l’expérience, de clarification des relations et des échanges et d’une définition claire des rôles et responsabilités.

Le fait que cette méthode soit universelle, largement diffusée dans le monde anglo-saxon et préconisée par la Communauté Européenne est un atout majeur.

Pour exemple, les projets ayant permis les Jeux olympiques de Londres ont été organisés à l’aide de la méthode PRINCE2. De l’avis de tous, ce sont les Jeux les mieux organisés depuis des décennies.

Contrairement à ce qui semble en première lecture, cette méthode implique un besoin d’informations et pas nécessairement de pléthore de documents, de décisions et pas obligatoirement de réunions.

Dans l’adaptation de la méthode, il est préconisé d’ajuster avec soin le nombre et la forme des documents échangés. Le chapitre Adaptation présente comment des petits projets peuvent être gérés à l’aide de seulement quatre documents.

La grande latitude donnée lors d’une séquence est tout à fait en accord avec des méthodes de projet comme les méthodes AGILE dont SCRUM, permettant aux réalisateurs du projet de s’exprimer librement à l’intérieur d’un périmètre parfaitement encadré.

Ce qui n’est pas traité par PRINCE2

De plus, PRINCE2 favorise la délégation et donc la confiance entre les acteurs du projet, tout en gardant à chaque niveau le contrôle nécessaire, en adéquation avec le niveau de confiance adopté.

PRINCE2 ne couvre ni les techniques de gestion de projet, ni les techniques d’un secteur particulier (bâtiment, informatique, industrie, service…), ni les aptitudes à la communication ou au leadership du Chef de Projet.

Considérant soit que ces techniques sont déjà documentées ailleurs ou trop spécifiques à un secteur et donc non suffisamment génériques pour entrer dans le cadre d’une méthode universelle.

Considérant également que l’aptitude du Chef de Projet peut revêtir bien des aspects qui sont plus liés à sa personnalité et à son style qu’à une codification normalisée.

Concernant les techniques de gestion de projet, ceci peut paraître étrange mais PRINCE2 considère à juste titre que l’utilisation de telle méthode d’estimation ou de tel outil de planification reste le choix des acteurs du projet.

En annexe sont présentés les outils ou méthodes les plus utilisés et les liens utiles.

Les principes PRINCE2

Objectif

Connaître les principes de PRINCE2 est essentiel pour comprendre la méthode. Ils sont en nombre restreint ce qui permet de les mémoriser aisément car ils doivent être respectés quel que soit le type de projet.

Le chapitre suivant permet de mieux appréhender la portée de ces principes universels.

CARACTÉRISTIQUES DES PRINCIPES

Les principes de PRINCE2 sont les obligations de référence qu’un projet PRINCE2 devrait suivre. Ils proviennent de retours d’expérience de nombreux projets, réussis ou non et à ce titre, sont des retours d’expérience universels.

Les principes fournissent un cadre de bonnes pratiques pour les personnes impliquées dans un projet.

Quel que soit le projet, PRINCE2 propose de s’en remettre à sept principes qui ont tous les qualités suivantes :

• universels, c’est-à-dire applicables quels que soient la taille, l’objet, la com plexité et même la culture des acteurs du projet
• auto-validants, car issus de l’expérience de multiples projets à travers le monde et de tous les secteurs d’activité
• habilitants, permettant aux utilisateurs de cette méthode de se conforter dans la certitude d’utiliser les meilleures pratiques.

Ces principes sont au nombre de sept :

• Justification continue pour l’entreprise,
• Leçons tirées de l’expérience,
• Rôles et responsabilités définis,
• Management par séquences,
• Management par exception,
• Focalisation sur le produit,
• Adaptation à l’environnement de projet.

Ces principes sont la base de l’utilisation de PRINCE2. Ils sont incontournables si l’on veut gérer un projet à l’aide de PRINCE2.

• Justification continue pour l’entreprise
• Retour d’expérience
• Rôles et responsabilités définis
• Management par Séquences
• Management par Exception
• Focalisation sur le Produit
• Adaptation à l’environnement

Figure 4.1 — Les 7 Principes.

PRINCIPE 1 : JUSTIFICATION CONTINUE POUR L’ENTREPRISE

Tout au long de son déroulement, un projet PRINCE2 doit rester justifié pour l’organisation qui a mandaté le projet. Sans cela, le projet en lui-même ne se justifie plus.

La notion de justification métier sous-entend que le projet amènera toujours des gains, que ces gains soient pécuniaires ou autres, et que ceux-ci ne seront pas compensés par des dépenses en ressources annulant ces gains, bref que le projet sera au total « bénéficiaire ».

La vérification de cette justification est aussi nécessaire en début de projet pour faire accepter son démarrage, qu’en cours de projet, afin d’avertir au plus tôt si le projet dérive et semble ne plus justifier les efforts consentis.

Cette justification est enregistrée dans le Cas d’Affaire (en Anglais Business Case), au titre des bénéfices et contre bénéfices, du budget global du projet et ROI (retour sur investissement) mais aussi dans les raisons de faire le projet.

Documenter cette justification et la maintenir à jour tout au long du projet est primordial pour PRINCE2. En effet, cela permet de ne pas commencer des projets que l’on ne saurait terminer et de les arrêter au plus tôt afin de limiter les dépenses si le projet ne se justifie plus.

Même si arrêter un projet est toujours un échec, surtout dans sa phase de développement, mieux vaut réallouer les ressources et capacités à d’autres activités plutôt que de s’entêter dans une entreprise vaine.

Souvent, les raisons d’arrêter un projet ne sont pas inhérentes au projet lui-même, mais simplement à son environnement. Modification de la stratégie de l’entreprise, évolution du marché, concurrence, changement de réglementations, évolution technologique, etc. entraînent parfois la remise en question d’un projet.

J’ai quelques souvenirs d’un projet industriel de pilotage d’un laboratoire de test d’engins électromécaniques de forte puissance, qui à sa sortie faisait sourire, car entre-temps alors que nous travaillions sur des générations précédentes d’ordinateurs disponibles au début du projet, la technologie PC était apparue. Que répondre à ces détracteurs, est-ce qu’une veille technologique nous aurait permis de nous simplifier la vie ? Nul ne peut réécrire l’histoire (sauf les vainqueurs bien entendu). En tout cas une vérification de l’adéquation de ce projet de modernisation entraînant des couts importants et la remise en question des hypothèses de départ aurait certainement permis, sinon d’arrêter complètement le projet, du moins de le suspendre afin que cette modernisation corresponde à un véritable bond technologique.

Ce ne sont pas les exemples qui manquent et nous avons tous souffert de ce genre de situation.

Certains prônent que l’on n’apprend jamais que par ses échecs, encore faut-il les reconnaître et savoir en tirer des leçons pour l’avenir.

PRINCIPE 2 : LECONS TIRÉES DE L’EXPÉRIENCE

Alors que tirer parti de l’expérience d’autrui est à la base du développement de la société humaine, les organisations cherchent souvent à réinventer la roue, peut-être par crainte de plagiat ou d’être taxées de « jouer la facilité ».

Cela est vrai notamment au niveau individuel, peut être par crainte de manque d’originalité. Or c’est à l’inverse de ce qu’une organisation doit faire, afin de recueillir plus rapidement les bénéfices d’un projet et ainsi éviter les erreurs que d’autres ont déjà commises.

Avant le démarrage d’un projet, au moment de faire des choix, il est important de vérifier si des expériences peuvent être partagées au sein de l’organisation et de tirer parti de projets antérieurs ou similaires.

En retour, lors du projet et à sa clôture, l’expérience acquise doit être transmise et conservée par l’organisation. Il s’agit donc bien d’agir dans les deux sens, en amont récupérer l’expérience déjà acquise, en aval, enrichir l’organisation de l’expérience acquise.

La difficulté n’est souvent pas d’identifier ce qui serait utile de transmettre mais la façon de le transmettre et de pérenniser cette connaissance.

Dans beaucoup d’organisations, ce chapitre relève des « normes et standards utilisés moins qu’un « Bureau Projet » (Project Management Office, PMO) ne joue déjà ce rôle ou qu’une entité déléguée à la qualité (Assurance Qualité) ne se charge de transmettre ces Retours d’Expérience qui sont la richesse d’une entreprise à la condition de savoir les transmettre et les utiliser.

Chaque projet peut transmettre des Retours d’Expérience. Par exemple, dans le cas d’organisations proposant d’estimer les projets en fonction de l’expérience acquise (Méthode d’évaluation historique et statistique), chaque projet concourt dans son domaine à revoir les paramètres de calcul de la méthode d’évaluation (voir annexes). Ceci vaut également pour l’appréciation des risques, ou celle des fournisseurs et peut aller jusqu’à une simple charte graphique pour rédiger les documents nécessaires au projet.

PRINCIPE 3 : RÔLES ET RESPONSABILITÉS DÉFINIS

Toutes les Parties Prenantes du projet doivent savoir ce que l’on attend d’elles et en retour ce qu’elles pourront en récupérer, en avantage comme en charge d’ailleurs.

En corrélation, il faut savoir ce que les parties prenantes attendent du projet et identifier quelles seront leurs obligations.

Il s’agit là à la fois de déterminer quels sont les intérêts des parties prenantes mais également leurs redevabilités, ce qu’elles doivent fournir au projet. Il faut insister sur ce néologisme de redevabilité car il ne s’agit pas tant de définir et de confier des rôles et des responsabilités supplémentaires, mais bien de clarifier quels sont les contraintes et les attendus à chaque phase du projet, afin que chacun soit responsabilisé et puisse s’engager sur le projet en connaissance de cause (et d’effet sur son activité personnelle).

Tout projet comprend trois intérêts distincts représentés par trois parties prenantes identifiables :

• Les demandeurs ou sponsors au sein de l’entreprise, ils sont à l’origine du projet et demandent à ce que le projet respecte les objectifs fixés au démarrage ;
• Les futurs Utilisateurs des produits générés par le projet, ce sont eux qui par l’utilisation des produits réaliseront les bénéfices escomptés par les sponsors/mandataires ;
• Les Fournisseurs qui vont réaliser les travaux permettant de développer les différents produits du projet. Ces fournisseurs peuvent être internes ou externes. Ils mobiliseront les ressources spécialistes nécessaires à l’achèvement des travaux.

Ces trois intérêts doivent être absolument représentés au sein du projet afin que chaque partie prenante puisse s’exprimer et concourir efficacement au projet.

Que les rôles et responsabilités soient définis dans le projet implique nécessairement que des moyens de communication efficaces existent et perdurent tout au long du projet entre les acteurs.

Il ne faut pas oublier que le projet est temporaire. Les parties prenantes sont rarement dédiées à plein-temps au projet. Savoir solliciter ces parties prenantes à bon escient et leur donner le bon niveau d’information et de capacité de décision est primordial au succès du projet.

PRINCIPE 4 : MANAGEMENT PAR SÉQUENCES (DE MANAGEMENT)

Il est habituel de découper un projet en étapes techniques, par exemple de commencer par la conception du produit à réaliser, puis de le réaliser et enfin de le mettre en œuvre.

Ce découpage, s’il est indispensable, répond à la vision technique du projet mais pas à celle des sponsors qui ne s’intéressent certainement pas à ces « détails techniques » et surtout qui n’ont ni le temps, ni la connaissance nécessaire.

Il est donc nécessaire de pouvoir fournir à ces dirigeants une vision qui leur permet de contrôler l’avancement du projet et sa justification, sans qu’ils soient obligés o d’investir trop de temps dans ces contrôles,

L’autre idée sous-jacente de ce découpage est de fournir un plan global du projet, une vue globale des étapes successives nécessaires à l’accomplissement. Les détails étant réservés à un autre plan validé avant chaque séquence qui donne une vision plus réaliste de ce qui pourra être réalisé au cours de la séquence suivante.

En effet, prévoir tous les détails d’un projet assez long ou complexe est une utopie compte tenu des aléas du projet. Cette prévision serait rapidement obsolète, d’où l’intérêt de rapprocher l’activité de planification de l’endroit (en termes d’échelle de temps) où elle sera appliquée.

Découper le projet en séquences de management permet d’avoir un « Horizon de planification » gérable mais également d’avancer étape par étape, l’étape suivante n’étant entreprise qu’une fois l’étape précédente validée. Tout ceci est développé dans le thème « Plans ».

PRINCIPE 5 : MANAGEMENT PAR EXCEPTION

L’idée principale est d’être économe quant aux sollicitations des différents niveaux de management entre eux et notamment d’économiser le temps de la direction, qui n’a pas pour rôle principal de s’occuper des « détails », tout en lui permettant de conserver le niveau de contrôle nécessaire.

Vouloir gérer par exception signifie surtout être capable de déléguer des responsabilités claires aux niveaux inférieurs. Ceci n’est pas évident car déléguer c’est faire confiance, ce qui n’est pas toujours possible.

Manager par exception requiert de savoir définir le plus précisément possible ce que ce niveau de management « inférieur » est autorisé à faire ou ne pas faire, et plus précisément savoir définir les limites de son action. Il s’agit en fait de déléguer une responsabilité et de façon plus humaine de faire confiance à autrui. Il est intéressant d’associer ce principe au concept de redevabilité, le niveau supérieur va ainsi définir ce que le niveau inférieur de management doit lui fournir et sous quelles contraintes.

Cela consiste à fixer des Tolérances sur les six paramètres du projet.

Sur les coûts et délais

Il s’agit de fixer des limites en temps et/ou en argent, que ces limites soient positives ou négatives.

Par exemple, la direction précisera au management du projet que le projet ne doit pas dépasser 5 % du budget cible et qu’il doit terminer le projet au plus tôt pour telle date (avant cette date, cela poserait peut-être des problèmes de synchronisation entre projets ; comme par exemple, la sortie d’un nouvel avion avant que les aménagements nécessaires à son stockage ou son envol soient terminés), et au plus tard pour telle autre date. Cette dernière limite étant souvent la plus évidente.

Sur la qualité et le périmètre

Ln Il s’agit de définir des variations admissibles de ces deux paramètres, par exemple des tolérances de dimensionnement (+1/- telle caractéristique). Chaque caractéristique du produit peut être délimitée, ne serait-ce que par appel à une référence normative (norme de la construction, modèle théorique, standards de la profession…). Il est évident que la variation de ces deux paramètres entraîne celle des deux précédents (coûts et délai) dans la majorité des cas.

Sur les risques et les bénéfices

Concernant les risques, il s’agit de faire le cumul des risques associés au projet et de définir les limites à ne pas dépasser. Ce cumul peut être réalisé en traduisant l’impact de chaque risque en argent, d’en faire la somme et de décider de ne pas dépasser une valeur définie. Cette tolérance de risque peut également se traduire par une « intolérance » à certains risques (pertes de données, risque sur les personnes physiques…).

• La valorisation de l’impact du risque est parfois difficile car elle dépend de ce qui est pris en compte.
• L’effet immédiat (directement lié au projet par exemple), l’effet différé (lié à l’entreprise qui ne va pas pouvoir réaliser les bénéfices escomptés),
• Les dommages collatéraux (des pertes d’exploitation engendrées par le dommage par exemple).

Puisque dans la définition PRINCE2, les risques peuvent à la fois être des menaces mais aussi des opportunités, il y a lieu de regarder la signification à donner des limites de tolérance aux opportunités. Limiter une opportunité n’a pas vraiment de sens. Par exemple, le Chef de Projet peut avoir à référer à sa hiérarchie de toute opportunité avant de pouvoir l’adopter. De la même manière, il est fort probable que si une opportunité existe, elle engendre des variations des autres paramètres (coût, délai, qualité…) qui seront eux limités à des variations convenues.

Les bénéfices se doivent également d’être soumis au management par exception et donc délimités. S’il est facilement compréhensible que la direction veuille être prévenue si les bénéfices attendus fluctuent de manière négative, en revanche, fixer une limite sur un accroissement trop important des bénéfices semble plus difficile à comprendre.

Prenons un exemple, une entreprise est sélectionnée dans le cadre d’un appel d’offre de construction d’un nouveau prototype d’aéronef. Si en cours de développement les calculs révèlent que cet appareil dépassera les bénéfices attendus (par exemple une consommation moindre de ressources pour sa construction), la nécessité de prévenir la direction est réelle, même si l’impact sur le projet et le Produit de Projet est en lui-même peu important. Allons plus loin, l’entreprise peut décider pour des raisons de marketing de ne pas dépasser certains bénéfices, sous peine de passer à côté de futurs marchés. On rejoint très vite la notion de tolérances de qualité.

De méchantes langues prétendent que la durée de vie de certains produits du commerce est calculée de façon à ne pas compromettre de futures ventes et que certaines administrations n’ont aucun intérêt à faciliter leurs procédures internes et protocoles sous peine de disparition.

Selon l’adage populaire : « la fonction créée l’organe », dans le cas qui précède c’est plutôt l’organe qui créé la fonction.

PRINCIPE 6 : FOCALISATION SUR LE PRODUIT

Il est intéressant de se concentrer sur le produit et pas uniquement sur les activités nécessaires à sa réalisation. On rejoint là l’idée d’obligation de résultat et pas seulement d’obligation de moyens.

Cela revient à définir parfaitement, par des listes de Produits, ce qui est à réaliser avant de se poser la question de comment ou par qui va être réalisé le produit ou composant de produit en question. Ce à quoi on s’intéresse en premier, c’est au mur, pas au travail du maçon ni aux parpaings.

Le projet et les activités induites ne doivent pas être une fin en soi, surtout pour les participants. Ce qui restera, ce sont les produits réalisés qui doivent répondre à des exigences définies ; seules ces exigences traduites en Critères d’Acceptation négociés avec le client permettront de valider le résultat de manière non contestable. Ces Critères d’Acceptation sont à la base d’un contrôle efficace.

Qu’à partir de la définition des produits, il soit nécessaire de déterminer les activités, les ressources et les moyens, mais également de prendre en compte les adhérences avec d’autres projets est en revanche indispensable.

PRINCIPE 7 : ADAPTATION À L’ENVIRONNEMENT DE PROJET

L’adaptation à l’environnement du projet permet de prendre en compte les caractéristiques intrinsèques du projet. Les caractéristiques extrinsèques sont plutôt du domaine de l’intégration comme nous le verrons plus loin dans le chapitre Adaptation de PRINCE2.

Il est question de personnaliser le projet en fonction de :

• Sa taille,
• Sa complexité,
• Son importance,
• Son niveau de risque,
• Son potentiel.

Il est nécessaire de corréler le niveau de contrôle du projet à ces critères, pour Ln ne pas provoquer une surcharge « administrative » sur de petits projets simples, et à l’inverse de ne pas risquer de perdre le contrôle de projets difficiles et stratégiques pour l’entreprise.

Il convient de ne pas perdre de vue que la méthode PRINCE2 requiert des informations mais pas nécessairement de documents et des décisions mais pas obligatoirement des réunions.

Dans le chapitre Adaptation de PRINCE2, nous verrons ce qui est adaptable et ce qui est obligatoire.

RELATIONS ENTRE THÈMES ET PRINCIPES

Les sept thèmes sont en relation étroite avec les principes qu’ils se doivent de respecter. Le schéma suivant donne une perspective des relations entre les thèmes et les principes.

Figure 4.2 — Relations entre les Thèmes et les Principes.

L’adaptation à l’environnement renvoie à tous les thèmes, ainsi chaque thème doit être adapté au projet sous peine, par exemple, de rejet de la méthode par une bureaucratie pesante et inadaptée ou à l’inverse adopter peu de méthode dans la gestion du projet qui, laissé à lui-même, aboutira à une désorganisation risquée.

Réponse de ce chapitre aux facteurs de réussite du projet

Rappel : tout au long de cet ouvrage consacré à PRINCE2, les concepts de la méthode sont mis en relation avec ces facteurs de réussite fournis par l’étude CHAOS afin de vérifier en quoi cette méthode de gestion de projet répond à ces facteurs de risque.

Quant aux Retours d’Expérience, qui ne figurent sur le schéma qu’en relation avec le thème qualité, on pourrait être tenté de le faire participer à tous les thèmes, tant il o peut être nécessaire de s’en servir pour faire progresser le management du projet sous toutes ses facettes.

Tableau 4.1 Le CHAOS et les Principes.

Les Principes de PRINCE2 répondent à la plupart des critères relevés dans l’étude du Chaos. En ce qui concerne le rapprochement des jalons du projet, si PRINCE2 ne précise rien dans les principes, cette notion est plutôt liée à la visibilité qui est un critère de détermination de la durée des séquences. Ceci est développé dans le thème « Plans » et est appelé Horizon de Planification. Bien entendu, si par Jalons plus rapproché les personnes ayant répondu aux questionnaires du CHAOS en pensant à un meilleur contrôle du projet, PRINCE2 répond évidemment à ce besoin.

Le projet PRINCE2

Objectif

Comprendre comment PRINCE2 découpe le projet en phases afin d’obtenir une démarche progressive et contrôlée du projet est l’objet de ce chapitre, qui introduit également les sept processus.

LES PHASES DU PROJET

Une façon simple de représenter les phases d’un projet est de reprendre le schéma o proposé par le PMBoK (Project Management Bodie Of Knowledge, voir annexes).

Figure 5.1 — Phasage du projet selon le PMBoK.

Trois grandes phases se succèdent, la conception prépare la réalisation, suivie de l’exploitation du résultat. La conception correspond au démarrage, la réalisation contient à la fois l’exécution de ce qui avait été prévu de faire mais également la planification des activités ainsi que son contrôle et sa surveillance ; la clôture du projet précède l’exploitation du produit, c’est-à-dire généralement la réalisation des bénéfices liés à l’utilisation des produits ou services.

PRINCE2 reprend ces grandes phases en précisant en quoi la phase de démarrage du projet est primordiale, comment réaliser les « boucles » de réalisation et en clôturant le projet de façon claire avant la livraison des produits du projet dans un cadre opérationnel.

Ces précisions permettent de clarifier le contenu de ces phases et surtout un contrôle plus précis des attentes de chaque phase.

La première approche est de se limiter à trois phases principales.

L’idée de base de PRINCE2 est de découper la phase projet en séquences de management, suivant le principe décrit au chapitre précédent, de façon à doter la direction des moyens de contrôles adéquats et d’une vision de l’avancement du projet adaptée à cette direction.

Figure 5.2 — Pré Phasage du proiet.

Pour ce faire, il est imposé un découpage en séquence de management, dont la première constitue l’initialisation du projet et la dernière contient les activités nécessaires à la clôture du projet, suivant le schéma :

Figure 5.3 — Phasage du projet selon PRINCE2.

Ainsi, le projet ayant été approuvé dans le préprojet, pourra démarrer en commençant par une préparation de tout ce qui est nécessaire au lancement de la réalisation des produits nécessités par le projet.

LE PRÉPROJET

La phase de préprojet permet de préciser l’idée ou le besoin à l’origine du projet qui sont les déclencheurs du projet. Ce que PRINCE2 formalise sous le nom de Mandat de Projet qui peut prendre diverses formes, du Post-it au cahier des charges élaboré. Il est souvent issu d’études de faisabilité, préalables au projet.

Cette phase va consister à ne pas se lancer dans un projet qui ne se révélerait pas viable ou simplement réalisable. Elle se concrétise par un processus nommé « Elaborer un Projet » dont le principal objectif est de récupérer de l’information et de la mettre en forme afin de fournir à la Direction des éléments lui permettant de prendre la décision de lancement du projet.

L’activité principale dans ce processus sera bien entendu de faire une étude d’opportunité qui se concrétisera par un Exposé de Projet, termes que PRINCE2 utilise pour désigner le rapport de cette étude que fera le Chef de Projet à sa Direction.

Cette étude doit être conduite aussi rapidement que possible et bien souvent sans moyen, puisque le projet n’a pas encore démarré et qu’à ce stade, il est peu probable qu’il y ait un budget dédié au projet.

Figure 5.4 Le préprojet.

Si la Direction conclut au démarrage du projet, une phase de préparation planifiée lui succédera. Cette Séquence d’lnitialisation, première séquence obligatoire du projet, sera plus ou moins importante en termes de coût et de délai en fonction de l’envergure du projet. Il n’est pas question de développer des Produits Spécialistes (produits que va réaliser le projet) dans cette séquence, mais simplement de se préparer et de se doter des éléments nécessaires à la réussite du projet. C’est notamment dans cette séquence que seront planifiés les contrôles nécessaires au projet ainsi que les moyens et une partie des ressources.

À la fin de cette séquence, un plan détaillé de la première Séquence de Livraison sera proposé, le tout étant soumis à l’approbation de la Direction du projet en vue de la validation. Cette validation est nécessaire au lancement de la réalisation des produits constitutifs du projet. Cette séquence sera assurée par le processus « Initialiser un Projet », mais également par le processus « Diriger un Projet » dédié à la Direction du projet et au processus « Gérer une Limite de Séquence » permettant au Chef de Projet de créer le Plan de Séquence suivante.

Figure 5.5 — L’initialisation du projet

LES SÉQUENCES DE LIVRAISON

Des séquences de « réalisation » (au moins une ! ) vont se succéder permettant de livrer les différents produits nécessaires au projet. Chaque séquence est contrôlée par le Chef de Projet avec le processus « Contrôler une Séquence » qui lui permet de distribuer les différentes tâches pour développer les produits. Ces tâches sont sous la responsabilité de Chefs d’Equipes responsables de la livraison des produits. Le processus « Gérer la Livraison du Produit » fait le lien entre le Chef de Projet et les Chefs d’Equipe.

A chaque fin de séquence de management, le Plan de Séquence suivant est finalisé afin de décrire de façon adaptée au contexte le contenu de la séquence suivante. Ceci à travers le processus « Gérer une Limite de Séquence » déclenché à l’approche de chaque fin de séquence. Une validation formelle par la direction du Plan de Séquence suivante et du bilan de la séquence en cours de finalisation est nécessaire afin de lancer la séquence suivante.

Le projet se déroule donc séquence par séquence, validée individuellement. Ceci permet de n’avoir à planifier en détail que la séquence suivante et de ne pas avancer sans qu’un contrôle formel de l’avancement du projet et sans qu’une approbation formelle de ce qui a été déjà réalisé, ait été faite.

Il n’y a pas pour PRINCE2 de séquence de clôture, mais simplement une dernière séquence qui contient les activités nécessaires à la clôture du projet. En effet, seul le processus Contrôler une séquence est à même de pouvoir gérer des activités de réalisation de produit.

LA DERNIÈRE SÉQUENCE

Cette séquence est gérée comme n’importe quelle autre séquence du projet, mais le Chef de Projet utilise le processus « Clore le Projet » pour gérer la vérification et le contrôle indispensables à une fin claire du projet. Une Ebauche de Notification de clôture de projet est adressée à la Direction qui vérifie que le projet peut être clos.

Figure 5.7 — La fin du projet.

Pour la clarté de l’exposé, dans la suite de ce livre, la représentation ainsi que les abréviations suivantes sont utilisées, sachant que nous reviendrons sur chacun des processus de façon détaillée.

Figure 5.8 — Relations entre les phases et les processus PRINCE2.

Légende :

• EP : Elaborer un Projet
• IP : Initialiser un Projet
• DP : Diriger un Projet
• CS : Contrôler une Séquence
• LS : Gérer une Limite de Séquence
• GLP : Gérer la Livraison du Produit
• CP : Clore le Projet

Tableau 5.1 – Le CHAOS et les phases du projet.

Réponse de ce chapitre aux facteurs de réussite du projet

Les phases de préproiet et d’initialisation permettent d’anticiper la plupart des problèmes que rencontrent les projets. C’est notamment dans ces phases qu’il est prescrit d’impliquer les parties prenantes et de définir la communication adéquate, mais également de spécifier le Produit de Projet et de planifier le projet avec ce que cela implique comme description du livrable et les Critères d’Acceptation associés.

Avant le projet

Objectif

Ce chapitre décrit les activités qui doivent être menées pour préparer le projet en lui-même. Cette phase est constituée de deux processus principaux, Elaborer et Initialiser le projet, basés sur un document essentiel qu’est le Cas d’Affaire. Ces processus déterminent également l’organisation pour la suite du projet.

« Prévoir, c’est déjà agir. » selon Henri Fayol

THÈME : CAS D’AFFAIRE

Le projet va être déclenché parce que PRINCE2 appelle un « Mandat de Projet ». Ce mandat peut prendre diverses formes, de la simple parole pour aller jusqu’à l’appel d’offre ou le cahier des charges de quelques milliers de pages.

De ce mandat va découler un document essentiel qui servira au pilotage du projet sur toute sa durée. Ce document est le Cas d’Affaire.

Le Cas d’Affaire, appelé Business Case en anglais (et en français professionnel également d’ailleurs), n’est que l’interprétation du Mandat de Projet fait par le Chef de Projet et une personne représentative de l’entreprise qui est nommée Exécutif. Ce Cas d’Affaire va conditionner le projet à tel point que toute modification du Cas d’Affaire sera considérée comme un changement à autoriser formellement. En corollaire, il est nécessaire de vérifier l’impact sur le Cas d’Affaire de tout changement.

Le Cas d’Affaire replace aussi le projet dans son environnement. Avec le Plan de Revue des Bénéfices, c’est le seul document qui contient des données « extra vie du projet » comme le coût et les délais d’utilisation des produits, notamment les coÛts récurrents (exploitation, maintenance, etc.) et la durée de vie des produits pour autant qu’ils continuent à apporter des bénéfices.

Pour l’anecdote, on peut regretter que certains projets ou simples produits n’aient pas respecté cette démarche et que dans le coût initial de ces projets, il n’ait pas été ajouté le coût de démantèlement ou simplement de mise au rebut.

Le Cas d’Affaire doit donc contenir toutes les informations qui permettront au Comité de Pilotage de Projet (instance qui est chargée de contrôler le projet) de vérifier que le projet est et restera viable et réalisable et donc qu’il justifie en cela les dépenses.

Parce qu’un projet peut être amené à évoluer ou simplement à connaître des aléas, le Cas d’Affaire est lui-même amené à évoluer : il vit tout au long du projet. Ceci le différencie d’un simple dossier commercial, parfois aussi vite oublié qu’il a servi de déclencheur à un projet/affaire.

Un des sujets majeurs traités dans le Cas d’Affaire est le bénéfice que l’on espère retirer du projet. A ce propos, il convient de ne pas confondre •

• Livrable : un composant ou le Produit de Projet en entier, que cela soit un produit tangible, une personne, un système ou un service (qui portent tous le nom de Produit dans PRINCE2)
• Résultat : ce résultat sera apporté par l’utilisation du Ou des produits générés par le projet ;
• Bénéfice : le gain mesurable engendré par le résultat.

Figure 6.1 — Relations entre livrable, résultat et bénéfice.

Exemple : un projet consistant à améliorer le trafic dans une ville, pourrait avoir comme :

• Livrable : une application informatique permettant la synchronisation des feux de signalisation ;
• Résultat : que les feux sont maintenant synchronisés ;
• Bénéfice : la constance du flux quantifié de véhicule malgré une augmentation du nombre de véhicules en circulation.

Attention de conserver toujours en ligne de mire ces bénéfices, car de la même façon qu’un Chef de Projet a tendance à davantage se focaliser sur les activités que sur le produit, il est assez fréquent également de ne se focaliser que sur les livrables et non sur les bénéfices que doivent engendrer les résultats liés à l’utilisation des livrables.

Les bénéfices peuvent évoluer dans le temps. A la fin de chaque phase du projet, il est donc intéressant de vérifier cette évolution et de prendre les mesures adéquates en cas de dégradation, allant jusqu’à l’arrêt prématuré du projet.

Figure 6.2 — Historique du Cas d’Affaire.

Les bénéfices sont estimés en phase de préprojet, puis affinés en phase d’initialisation, vérifiés à chaque fin de séquence de management et enfin confirmés tout au long du projet, si cela est possible, mais surtout à la fin du projet et au-delà lors de l’utilisation effective du Produit de Projet. Ceci est défini dans le Plan de Revue des Bénéfices qui couvre une période allant au-delà du projet, généralement couvrant une partie de l’utilisation du ou des Produits de Projet.

Responsabilités

L’Exécutif est l’unique responsable du Cas d’Affaire pendant toute la durée du projet alors que le Chef de Projet en a rédigé conjointement le contenu et son évolution tout au long du projet.

Les bénéfices attendus décrits dans le Cas d’Affaire sont spécifiés par les Utilisateurs

Principaux, ainsi que les résultats. Le Chef de Projet retranscrit ces données dans le Cas d’Affaire et spécifie le Plan de Revue des Bénéfices dont la responsabilité est partagée entre l’Exécutif pendant le projet et l’entreprise ou le programme après le projet.

Les utilisateurs portent la responsabilité de s’assurer que les bénéfices attendus sont décrits dans le Plan de Revue des Bénéfices.

Le schéma suivant indique les processus en relation avec le Cas d’Affaire.

Figure 6.3 — Relations entre le Cas d’Affaire et la vie du projet.

Tableau 6.1 — Le CHAOS et les phases du proiet.

Réponse de ce chapitre aux facteurs de réussite du projet

Le Cas d’Affaire est le document central du projet. Il permet de s’assurer que les enjeux du projet sont bien compris et partagés par toutes les parties dont les utilisateurs et les fournisseurs. Ce Cas d’Affaire est la référence commune à toutes les parties prenantes qui ne devraient accepter de commencer le projet que lorsqu’elles sont d’accord avec le contenu de ce document.

THÈME : ORGANISATION

Avant de développer ce qui sera fait dans le processus Élaborer un projet, il est intéressant de voir comment PRINCE2 préconise d’organiser le projet.

Le thème Organisation a pour objectif de « définir et d’établir la structure des redevabilités et des responsabilités du projet ». Ce qui répond au 3 e principe de PRINCE2 : Rôles et Responsabilités définis.

Les acteurs du projet ont besoin de savoir qui décide, qui doit valider, qui doit approuver, qui doit réaliser, qui doit contrôler, etc. Ceci constitue la définition d’une structure d’équipe conciliant la nécessité de faire avec celle de contrôler et permet une gouvernance de projet adaptée à l’environnement du projet.

Les relations entre acteurs du projet sont de type Client/Fournisseur, environnement Client/Fournisseur, en ce que les contraintes doivent être réciproques, sinon équilibrées, c’est-à-dire impliquer une réciprocité de contrainte et de bénéfice.

Les trois intérêts du projet

Pour PRINCE2, « le projet est une organisation temporaire, créée en vue de livrer un ou plusieurs produits d’entreprise conformément à un Cas d’Affaire convenu Cette o définition liminaire introduit la notion de fugitivité de cette organisation et par là la nécessité pour des acteurs, qui ne se sont peut-être jamais rencontrés au préalable et qui n’auront plus aucun contact par la suite, de s’organiser de façon efficiente pendant ce laps de temps limité qu’est un projet.

Il est nécessaire, si l’on veut que le projet aboutisse, que tous les intérêts des participants soient représentés au sein de la direction de projet.

Les trois intérêts principaux sont l’Entreprise, les Utilisateurs et les Fournisseurs. Le projet n’est que l’aboutissement consensuel des intérêts des trois parties.

On peut noter que deux des rôles (Utilisateur et Fournisseur principal) sont assimilables à des rôles que l’on retrouve dans les métiers de la construction mais aussi de l’informatique. Ce sont les Maîtrises D’ouvrage et les Maîtrises d’œuvre. Ces rôles n’existent pas dans le monde Anglo-saxon, d’où ces appellations parfois difficiles à cerner opérationnellement de Client et de Fournisseur principaux.

L’Entreprise

C’est l’Entreprise qui investit dans le projet afin de créer un produit qui répondra aux besoins de ses utilisateurs ou de ses clients, même si ces clients sont des entités internes de la même entreprise ou du même groupe d’intérêt. Le point de vue de l’entreprise est celui du « payeur », il consent à investir, encore faut-il que cela apporte de la valeur ajoutée. Un produit trop cher ou à peu de valeur ajoutée n’aura pas crédit à ses yeux.

Figure 6.4 — Les 3 intérêts principaux du projet.

On peut noter que ce substantif « Entreprise » désigne un organisme constitué privé ou public, à but lucratif ou non, Dans certains cas, il peut même s’agir d’une personne physique (construction d’un pavillon par exemple).

L’Utilisateur

L’utilisateur est le prescripteur. C’est souvent le client final mais il peut être représenté par l’entité commerciale ou marketing de l’entreprise par exemple. Ces utilisateurs utiliseront (ou feront utiliser) le produit final, et produiront de ce fait les bénéfices attendus. Ce sont également ceux qui géreront le Produit de Projet bien au-delà de la durée du projet en le maintenant ou l’exploitant. Ces utilisateurs sont aussi ceux qui seront affectés indirectement par le Produit de Projet cornme dans le cas de techniciens éventuellement externes à l’organisation devant exploiter un système d’information que livrerait le projet. Plus généralement, ce sont tous ceux qui pourraient indirectement être impactés par le projet.

Ces utilisateurs sont les sachant fonctionnels. Ils fourniront les ressources nécessaires pour spécifier les exigences liées aux produits et les bénéfices attendus. Ils ont un devoir de définition de validation des produits vis-à-vis du projet et plus généralement de réalisation des bénéfices envers l’entreprise.

La forme représentative de l’utilisateur est nommée Utilisateur Principal ou Utilisateurs Principaux en ce qu’ils doivent représenter les intérêts de tous ceux qui ont un intérêt direct ou sont simplement impactés par les produits du projet. Par exemple, ils doivent représenter les intérêts des riverains en cas de construction immobilière ou même les fournisseurs de maintenance si le produit doit être maintenu sur toute sa durée de vie, c’est le cas des concessionnaires automobiles qui sont représentés auprès des constructeurs afin de faire part de leurs difficultés de maintenance par exemple.

Le Fournisseur

Le fournisseur, qu’il soit interne ou externe, est l’apporteur de ressources et de capacités pour développer les produits du projet. Il a le plus souvent une obligation de résultat.

Si les intérêts de l’Entreprise et de l’Utilisateur ont de fortes chances de converger rapidement, celui du fournisseur, surtout s’il est externe, peut rapidement diverger et des conflits néfastes au projet peuvent en découler. D’où l’importance pour le fournisseur d’être considéré comme partie prenante dans le projet et qu’il soit consulté comme un acteur essentiel du projet.

Ces fournisseurs sont les sachant techniques. Ils fourniront les ressources pour réaliser les produits, ils ont bien souvent un devoir légal de conseil dans le projet.

La forme représentative du fournisseur est nommée Fournisseur Principal ou Fournisseurs Principaux, ils représentent leurs propres intérêts mais également ceux de leurs sous-traitants, cotraitants, etc.

La Direction de l’Entreprise ou du Programme

Cette « direction » a un rôle à jouer dans le projet. Son rôle est plus précisément décrit dans le second manuel de PRINCE2 « Directing Successfull Projects With PRINCE2 »

Etant à l’origine du projet, il en confie la responsabilité à l’Exécutif qui est son o représentant. Cette direction est consultable tout au long du projet afin de recueillir ses conseils et éventuellement décisions. Pour en savoir plus sur la gestion de Programme, la méthode Managing Successful Programmes (MSP@) a été développée à l’instar de PRINCE2 sous l’égide de l’OGC. Cette méthode permet de coordonner l’organisation, la direction et la mise en oeuvre d’un portefeuille de projets et d’activités à des fins stratégiques.

Les niveaux de l’Organisation PRINCE2

PRINCE2 distingue quatre niveaux dans l’organisation, dont seulement trois font partie de l’équipe de management de projet.

Ces niveaux sont imperméables en ce qu’il y a un cheminement « hiérarchique » a priori obligatoire, du Chef d’Equipe au Chef de Projet, de celui-ci au Comité de Pilotage qui est la voix de l’Entreprise ou du Programme.

Figure 6.5 – Les niveaux hiérarchiques du projet.

La Direction de l’Entreprise ou du Programme n’est pas considérée comme faisant partie de l’équipe de management de projet bien qu’elle soit le commanditaire du projet.

Cette structure temporaire peut introduire de nouvelles dépendances hiérarchiques qui ne sont pas celles de l’organisation cliente ou fournisseur. Ainsi, dans le cadre du projet, le Chef de Projet peut être amené à gérer un Chef d’Equipe qui par ailleurs est Responsable d’une entité spécialisée de l’Entreprise. De même, les Chefs d’équipe proviennent souvent de l’organisation d’un fournisseur externe à laquelle ils doivent hiérarchiquement rendre compte, ce qui peut poser des conflits d’intérêt.

Il convient de bien différencier ce management fonctionnel du management hiérarchique habituel sous peine de rencontrer des difficultés dans l’établissement des priorités. Le Comité de Pilotage de Projet doit s’engager auprès du Chef de Projet afin de l’aider dans cette tâche.

Il devient rare que les équipes travaillent uniquement sur un projet pour des raisons apparentes de productivité ou d’efficience ; tel Chef de Projet gère plusieurs projets, Ln telle équipe de réalisation passe d’un chantier à un autre dans la même semaine quand ce n’est pas dans la même journée. Il y a des limites à ce genre de pratique, qui génére de la dispersion, des erreurs, du temps de commutation entre deux tâches, etc.

Il n’y a pas de solution miracle à cette évolution de la société, on peut juste essayer de faire en sorte que le temps laissé entre deux commutations de tâches soit suffisamment important pour que ce qui est réalisé dans ce laps de temps apporte suffisamment de valeur au projet. Ce paramètre est à prendre en considération lors de l’estimation de la durée du projet et éventuellement de celle de tolérances (de durée mais également et malheureusement de risque, de qualité et même de coût).

Le Comité de Pilotage de Projet est redevable du projet vis-à-vis de la Direction d’Entreprise ou du Programme. Il doit valider et approuver les produits de management que lui fournit le Chef de Projet. Il est l’autorité ultime des changements, autorisant les déviations de séquence, les plans d’exception et validant chaque séquence de management.

Le Comité de Pilotage de Projet est le véritable responsable du projet dans ses attendus c’est-à-dire en termes de bénéfices. Ce Comité n’est pas permanent au sens où d’autres activités requièrent son attention, des activités métier pour les utilisateurs, d’autres projets qu’ont les fournisseurs ou de la gestion d’entité pour l’Exécutif par exemple. Aussi PRINCE2 cherche à ce que cette Direction de Projet ne soit pas sollicitée en permanence ou à mauvais escient ; c’est tout le principe de Management par Exception.

Le Chef de Projet gère le projet au quotidien, il est responsable de l’organisation du projet et doit s’assurer que celui-ci délivre les produits définis. Il gère les événements qui pourraient avoir une Incidence sur le projet et s’assure que le projet reste dans les tolérances fixées par la Direction. C’est le chef d’orchestre du projet qui veille à ce que le projet se déroule comme convenu lors du « contrat » passé avec la Direction de Projet, n’interpellant celle-ci que lorsque c’est nécessaire ou à des échéances de contrôle programmées.

Enfin la Livraison, « cheville ouvrière » du projet, dépend hiérarchiquement des fournisseurs, qui délivrent les Produits Spécialistes tels que spécifiés par le Chef de Projet. Si le projet le rend nécessaire, des Chefs d’Equipe peuvent être utilisés, sinon c’est le Chef de Projet qui joue également ce rôle.

Les différents acteurs

Le schéma ci-dessous résume la structure de l’équipe de projet et ses relations.

Le Comité de Pilotage de Projet

Le but de cette partie de l’organisation est de donner au projet une véritable gouvernance représentative de tous les intérêts du projet.

o Aussi, ce Comité de Pilotage de Projet est-il constitué en forme de triumvirat composé de l’Exécutif représentant l’Entreprise ou le Programme, des Utilisateurs Principaux représentant des utilisateurs et enfin, des Fournisseurs Principaux pour les fournisseurs. Historiquement, il n’existe pas de triumvirat qui ne se soit transformé en dictature, cette « dictature » est présente dans le Comité de Pilotage de Projet en ce que l’Exécutif est l’ultime responsable des décisions et porte en définitive la responsabilité du projet par son pouvoir financier.

Répétons-le, le Comité de Pilotage de Projet est souvent constitué de responsables qui disposent de peu de temps à consacrer au projet, ce n’est d’ailleurs pas leur rôle. Il est donc nécessaire que le Chef de Projet ajuste les besoins indispensables de communication avec cette contrainte. Le 5 e principe : le Management par exception ainsi qu’une bonne Adaptation du projet (7 e principe) répondent à cette exigence.

Une Assurance Projet peut être nommée lors de la constitution des équipes afin d’aider le Comité de Pilotage de Projet dans ses tâches de contrôle du projet.

Figure 6.6 – Structure de l’organisation du proiet.

Le Comité de Pilotage de Projet porte l’autorité et la responsabilité du projet, il Ln est redevable de :

• La réussite du projet,
• Fournir les directives appropriées et surtout unanimes au Chef de Projet,
• Fournir les ressources et faciliter leur intégration au sein du projet, fournir les fonds nécessaires au projet,
• Apporter son soutien au Chef de Projet,
• Assurer la communication bilatérale avec l’extérieur du projet.

De façon plus précise, l’Exécutif a pour responsabilité de s’assurer que le projet reste viable jusqu’à sa clôture et que les acteurs du projet sont focalisés sur la livraison des produits et des bénéfices. En tant que responsable des fonds engagés, l’Exécutif doit veiller à ce que ces fonds soient utilisés à bon escient, de façon économe, mais aussi à ce que ces fonds soient disponibles.

L’Exécutif est aussi responsable de la nomination de l’Equipe Projet et notamment des autres membres du Comité de Pilotage de Projet avec l’aide de la Direction de l’Entreprise ou du Programme, dont l’Exécutif n’est que l’émanation.

A ce propos, PRINCE2 ne précise pas que la nécessité de prévoir un budget sous-entend non seulement des fonds, mais aussi un plan des dépenses et un suivi budgétaire du projet. Ceci est pallié par la mise à jour du Plan de Projet et du Plan de Séquence en cours de projet qui doivent correspondre à des activités de suivi du « este à Faire » notamment.

Enfin, ce rôle ne peut être assuré que par une personne unique, tant il est vrai que le pouvoir ne se partage pas.

Les Utilisateurs Principaux représentent les intérêts de ceux qui utiliseront le produit et délivreront les bénéfices en utilisant les produits du projet, mais aussi les intérêts de tous ceux qui seront impactés par le projet et ses produits.

Ils représentent notamment le savoir fonctionnel, ils ont une obligation de définition de leurs attentes.

Ils ont pour charge de spécifier leurs besoins et contraintes et de valider les Critères d’Acceptation du Produit de Projet. Ils doivent être en nombre limité pour rester efficaces et être autorisés à fournir les ressources utilisateur nécessaires au projet, notamment lors des phases de définition et d’approbation des produits et d’acceptation des produits du Projet.

Il ne faut pas oublier que la durée des Produits de Projet excède celle du projet et donc que les acteurs de la gestion opérationnelle, de la maintenance et du support de ces produits doivent également être représentés, qu’ils soient externes ou internes. Les produits pourraient être maintenus et supportés par des fournisseurs externes par la suite, les intérêts de ceux-ci doivent être pris en compte.

Les Fournisseurs Principaux représentent les intérêts de ceux qui vont concevoir, réaliser et peut-être mettre en œuvre les Produits du Projet, ils représentent les savoirs techniques et technologiques, ils ont une obligation de conseil et pratiquement toujours de résultat.

Ils fournissent les ressources nécessaires au projet pour réaliser ce qui a été spécifié.

Si la gestion des opérations, la maintenance ou le support des produits du projet sont assurés par le Fournisseur ; ils représentent également les intérêts de ces fournisseurs. Ceci peut sembler antinomique avec le même rôle assuré par les Utilisateurs Principaux, peu importe qui assure au final ce rôle pourvu que ces intérêts soient représentés, d’autant que ces opérations peuvent être au final partagées pour partie, ce qui est souvent le cas (par exemple : le chauffe-eau d’un pavillon doit être simple à régler en température et à remettre en marche après la trêve estivale pour l’utilisateur — opération courante — mais également accessible en cas d’opération maintenance du chauffagiste — opération de maintenance — d’un fournisseur agréé).

Le Chef de Projet est nommé par l’Exécutif et/ou par le Comité de Pilotage de Projet, il est comme l’Exécutif, une personne unique. Il a la délégation du Comité de Pilotage de Projet de gérer les équipes et les relations avec l’Assurance Projet.

Le Chef de Projet est responsable du bon déroulement du projet au jour le jour. Il est responsable des activités de l’ensemble des processus à l’exception des processus Diriger le Projet et Gérer la Livraison des Produits (quand il n’est pas lui-même Chef d’Equipe).

PRINCE2 préconise que le Chef de Projet provienne de l’organisation cliente, mais ceci n’est pas obligatoire.

Le Chef de Projet peut être assisté d’un Support Projet distinct qui remplira certaines tâches dont il conservera la responsabilité (voir Support Projet).

Le Chef d’Equipe doit se concentrer sur la réalisation des produits convenus avec le Chef de Projet. Il gère les membres des équipes de réalisation des produits.

En fonction de la taille du projet, des compétences nécessaires, il peut n’y avoir aucun Chef d’Equipe ou au contraire plusieurs. S’il n’y a pas de Chef d’Equipe, c’est le Chef de Projet qui assume ces rôles. Il est admis que si certains Chefs d’équipe peuvent être nommés dès le début de Projet, il est possible que d’autres ne le soient que lors du processus Gérer une Limite de Séquence, juste avant qu’ils aient à intervenir sur le projet. Dans tous les cas, ils devront être sollicités (ou représentés) pour la planification des tâches qui leur seront allouées.

Le Chef de Projet attribue le travail au Chef d’Equipe sous forme de Lots de Travaux afin de préciser de façon formelle et aussi précise que nécessaire ce qu’il attend.

On peut noter qu’en plus des informations contenues dans le Lot de Travaux, celuici peut être complété avec des informations de gestion, tel que de N O d’imputation comptable, des ressources allouées, des coûts, etc.

L’Assurance Projet est de la responsabilité du Comité de Pilotage de Projet Ln qui en assume le rôle, mais il peut déléguer en nommant d’autres personnes à ce rôle.

L’Assurance Projet est indépendante du Chef de Projet afin qu’il n’y ait pas de conflit d’intérêt et qu’elle puisse agir en toute liberté.

L’Assurance Projet n’a pas comme seul but de surveiller pour le compte du Comité de Pilotage de Projet. Son rôle est aussi de fournir des conseils au Chef de Projet.

L’Assurance Projet doit répondre aux besoins qualité des trois intérêts du Projet, aussi elle peut être triple

• Assurance (Projet) Entreprise,
• Assurance (Projet) Utilisateur,
• Assurance (Projet) Fournisseur.

En effet, l’entité métier qui va utiliser le produit peut être soumise à des contraintes particulières (normes, référentiels, sécurité, etc.) que le projet doit respecter et donc qu’elle doit contrôler. De la même façon, un Programme peut avoir édicté des standards ou un fournisseur devoir répondre à des critères propres au fonctionnement de ses équipes.

Même si cela peut sembler paradoxal, cette Assurance Projet de par ses interconnexions avec le Comité de Pilotage Projet et donc les utilisateurs, peut être amenée à jouer un rôle d’interface avec les Chefs d’équipe.

Comme pour l’Assurance Projet, le Comité de Pilotage de Projet peut déléguer sa responsabilité concernant les changements au projet à une Autorité de Changement nommée.

Cette délégation doit être enregistrée avant la fin du processus Initialiser un projet et être consignée dans la Stratégie de Configuration.

En fonction de l’impact mais aussi de la nature des changements, cette autorité peut être déléguée au Chef de Projet ou à des personnes ou entités qui seront en mesure de prendre la meilleure décision possible. C’est le cas, par exemple, si le changement en question requiert une compétence particulière (exemple : réseau informatique interne d’entreprise, plateforme commune, aspect légal, raison géographique, …), mais aussi si l’on prévoit que les changements seront nombreux et mobiliseront trop le Comité de Pilotage de Projet.

Il y a en fait quatre niveaux d’Autorité de Changement :

• La Direction de l’Entreprise ou du Programme,
• Le Comité de Pilotage de Projet,
• L’Autorité de Changement / Assurance Projet,
• Le Chef de Projet.

En effet, le Chef de Projet peut être lui-même autorisé à prendre des décisions quant aux changements.

Les deux dernières autorités sont dites déléguées.

On peut noter que l’Autorité de Changement peut être assurée par l’Assurance Projet.

Dans tous les cas, il y a lieu de bien documenter les niveaux d’autorité en fonction de l’impact ou de tout autre paramètre ainsi que les rôles correspondants.

Tout en en conservant la responsabilité, le Chef de Projet peut déléguer une partie de ses activités à un Support Projet. Ces activités seront essentiellement administratives, tenues à jour des registres et des configurations par exemple, mais aussi techniques, comme l’expertise dans les outils de planification. Il peut aussi être chargé de fournir un Rapport d’Etat du Produit.

Certaines entreprises centralisent les activités de gestion de configuration des biens qu’elles utilisent. Dans ce cas, le Support Projet est assuré, pour partie, par les personnes qui gèrent ces biens.

Ce Support Projet est parfois assimilable à un Bureau de Projet qui coordonne et supporte les projets. Attention toutefois au risque de conflit d’intérêts si ce bureau fait également office d’Assurance Projet.

Les membres de l’équipe vont concevoir, réaliser et mettre en place les produits. Ce sont des professionnels compétents dans leur spécialité. Ils apportent leur savoir faire technique et même s’ils ne sont pas considérés comme faisant partie de l’équipe de projet, ils doivent se sentir concernés par le projet et ses enjeux.

Un projet, c’est avant tout des hommes et des femmes indispensables à la réussite du projet et chacun sait que le travail en collaboration n’est pas facile. Les acteurs de l’équipe de projet doivent être particulièrement attentifs à cet aspect afin que chacun travaille pour le projet et non contre les autres.

Evolution de l’équipe de projet

Il est peu probable, sur un projet assez long ou quelque peu complexe, que l’équipe de projet reste identique tout au long du projet. Pour des raisons de défections de personnes ou par exemple lorsque les fournisseurs se succèdent au cours du projet et deviennent successivement Fournisseur Principal. Pour illustrer ceci, prenons l’exemple d’une maison, le couvreur aura du mal à se sentir concerné et représentatif lors des fondations de la maison et à l’inverse l’entrepreneur du gros ceuvre de sous bassement vis-à-vis des électriciens ou des décorateurs. Le mieux serait d’avoir un “maître d’ceuvre” unique supervisant tous les corps de métier. Si les rôles sont correctement documentés et compris par ces différents fournisseurs, leur changement a peu d’importance à la condition qu’ils soient représentatifs et se sentent solidaires des autres fournisseurs.

On voit par cet exemple que si changement d’équipe il y a, il vaut mieux que cela se fasse à la transition entre les séquences,

Les deux rôles unipersonnels que sont l’Exécutif et le Chef de Projet ne devraient pas être réattribués, mais dans la pratique, ce n’est pas toujours possible. Dans ce cas, une passation formelle sur un laps de temps conséquent est nécessaire.

Centre d’Excellence

Il s’agit pour l’organisation de constituer une entité « normative » indépendante des projets et qui fournit de l’aide aux Chefs de Projets. Or sa fonction de définition de normes, ce Centre d’Excellence a pour objet de fournir les compétences et la formation nécessaire et peut fournir également l’Assurance Qualité à certains projets. C’est souvent cette entité qui gère les outils comme le système de gestion des configurations, les outils d’estimation et de gestion de projet. Ce Centre d’Excellence peut également arbitrer lors de la fourniture de ressources critiques entre les différents projets.

Retour d’expérience

Se rappeler que l’organisation touche des humains et non des machines.

Eviter les lourdeurs administratives inutiles ; plus un circuit est direct et plus il est efficace. Les acteurs sont là pour faire avancer le projet, pas pour lire des rapports sans fin, ni pour remplir en permanence des bordereaux pour un contrôle inefficace. C’est toute la philosophie PRINCE2 : Adapter à l’environnement ! Communiquer avec efficience !

Analyser les parties prenantes et déterminer quel pourra être leur niveau d’implication sur le projet.

Essayer de comprendre les structures hiérarchiques, les organigrammes de l’entreprise, mais également les structures non hiérarchiques, celles qui permettent réellement aux entreprises de fonctionner.

Passer plus de temps à expliquer l’organisation du projet si celle-ci ne respecte pas la structure hiérarchique de l’organisation.

Demander conseil au Comité de Pilotage de Projet qui est bien souvent détenteur de connaissances historiques sur les personnes qui vont intervenir sur le projet.

Signaler tout manquement des Utilisateurs Principaux immédiatement car ils sont garants des définitions et des résultats du projet ; trop souvent les utilisateurs affectés sur le projet n’ont ni les connaissances, ni les capacités de décision pour assumer leur fonction dans le projet.

Rencontrer au plus tôt les Chefs d’Equipe et travailler avec eux, même et surtout s’ils sont externes à l’entreprise, c’est eux qui vont être en charge de ce qui va être produit, s’en faire des alliés est indispensable.

En toute théorie, le Chef de Projet n’est pas forcément un sachant technique. Dans la réalité, s’il ne maîtrise le domaine technologique principal du projet, une organisation technique va le « court-circuiter » et il ne jouera plus qu’un rôle administratif.

Enfin, connaître quelques techniques de développement personnel n’est pas superflu (PNL, Ennéagramme, Belbin, Krauthammer, Process Communication, etc.).

De l’importance relative du Chef de Projet

Quelle que soit la méthode, le projet ne vaut souvent que par son acteur principal, le Chef de Projet.

Le rôle du Chef de Projet est primordial car de ses qualités, notamment celle de savoir organiser et communiquer, va dépendre la réussite ou l’échec du projet.

Le Chef de Projet est à la fois auteur et chef d’orchestre d’une pièce qui ne se jouera qu’une fois. Ce n’est pas un « homme-orchestre » en ce qu’il ne jouera pas toutes les partitions et de tous les instruments, mais c’est celui qui conduira le projet à bonne fin. Il va devoir composer avec toutes les parties concernées, chercher un consensus pour que l’ceuvre aboutisse au meilleur des résultats dans les conditions et l’environnement qui lui aura été fixé.

S’il reconnaît que les qualités personnelles de leadership et de communication sont indispensables à tout Chef de Projet, PRINCE2 laisse à d’autres méthodes le soin de reconnaître ou développer ces qualités.

PRINCE2 considère que le rôle du Chef de Projet est essentiellement de :

• Planifier, c’est-à-dire de prévoir les étapes nécessaires pour réussir son projet, comprenez organiser entre elles l’ensemble des activités et pas seulement de les inscrire sur un calendrier.
• Déléguer, tant il est vrai qu’un Chef de Projet n’est pas celui qui construit, il dépend des acteurs qui vont réaliser les tâches nécessaires au projet. On rejoint ici le caractère « interfonctionnel » d’un projet et la nécessité de se faire aider pour terminer dans des délais impartis.
• Surveiller, c’est-à-dire vérifier que tout se déroule conformément à ce qui a été planifié et réagir au plus vite en cas de problème. Ce qui amènera le Chef de Projet à éventuellement replanifier pour tenir compte des impondérables inhérents à tout projet.
• Contrôler, « la confiance n’exclut pas le contrôle » suivant l’adage populaire. Ce contrôle permet au Chef de Projet de valider les résultats des tâches qu’il a déléguées. Et bien entendu, cela lui permet d’apporter des corrections ou améliorations nécessaires en cours de projet.

Figure 6.7 — Les 4 activités du Chef de Projet.

Ces quatre activités, apparemment séquentielles, sont menées tout au long du projet. Elles contiennent par nature une autre activité essentielle du Chef de Projet, la communication. C’est de par sa capacité à communiquer que le Chef de Projet arrivera à obtenir de ses partenaires ce qui est nécessaire au projet.

L’utilisation de techniques de planification ou de contrôle est indispensable de façon à ne pas réinventer la roue et profiter des expériences acquises par d’autres. Ce qui est un principe fondamental de PRINCE2.

Tableau 6.2 — Le CHAOS et l’organisation du projet.

Réponse de ce chapitre aux facteurs de réussite du projet

Concernant le fait qu’une équipe soit dédiée, PRINCE2 signale ce problème et recommande de déterminer des laps de temps consacré exclusivement au projet de façon à limiter les inconvénients liés au basculement entre les différents travaux d’une personne ou d’une équipe.

PROCESSUS : ÉLABORER UN PROJET

Le processus Elaborer un projet permet de dégrossir le projet et de s’assurer de façon rapide que le projet est fiable et réalisable.

L’alias de ce processus pourrait être « peu de temps, pas d’argent ». En effet, il faut s’imaginer qu’il s’agit dans cette phase de vérifier rapidement si le projet « en vaut le coup » alors qu’aucun budget n’est disponible, mais aussi si l’on dispose des moyens nécessaires au moins pour aller plus loin, dans ce qui pourrait ressembler à une étude d’opportunité et de faisabilité. Attention, pour les auteurs de PRINCE2, cette étude de faisabilité est en amont du projet et doit être considérée comme un projet. Les résultats de ce projet d’étude de faisabilité pourront être utilisés pour créer le Mandat de Projet.

Ainsi, s’il est de prime abord confirmé que le projet n’est pas viable, ce projet ne sera même pas initialisé. S’il apparaît qu’il peut l’être, on aura « dégagé le terrain » et assemblé les informations nécessaires pour prendre une décision le plus factuellement possible.

Figure 6.8 — Positionnement du processus Élaborer un projet.

Les deux acteurs principaux de ce processus sont le Chef de Projet mais également l’Exécutif.

A ce stade, ce n’est pas au Chef de Projet de prendre les décisions, il ne fait que compléter un dossier avec l’aide de l’Exécutif mais aussi avec des utilisateurs, des fournisseurs et autres parties prenantes jugées nécessaires pour le compte des o véritables décideurs que constituera le Comité de Pilotage de Projet. Le Chef de Projet va préparer un dossier, appelé « Exposé de projet » afin d’aider les décideurs à se Ln positionner. C’est dans ce cadre que récupérer les retours d’expériences joue un rôle prépondérant.

Elaborer un projet va permettre également de nommer les membres de l’équipe de management de projet, sachant que même s’il est difficile à ce stade de connaître l’ensemble des parties prenantes concernées qui interviendront sur le projet, il est toutefois important de s’assurer que les ressources nécessaires à l’initialisation du projet pourront être mobilisées.

Même s’il pourrait sembler qu’à cette phase, seuls le Chef de Projet et l’Exécutif vont opérer, en fait tous les membres de l’équipe projet vont apporter leur contribution : les utilisateurs en précisant leurs exigences en relation avec le Mandat de Projet, les fournisseurs en proposant des possibles solutions, l’Assurance Projet en apportant ses conseils et en validant à la fois les hypothèses mais également les débuts de solutions. Bref, tous vont être mis à contribution pour éliminer, autant que faire se peut, les hypothèses erronées.

Il est évident que tout ceci se base sur l’expérience des différents acteurs que le Chef de Projet consignera dans un Journal des Retours d’Expérience contenant les éléments et preuves permettant au Chef de Projet de justifier les choix d’origine.

L’Exposé du Projet est en fait une synthèse de toutes les consultations. C’est cet Exposé de projet qui sera présenté au Comité de Pilotage de Projet afin que celui-ci décide si le projet peut être initialisé ou non.

Il peut sembler étrange que ce soit les acteurs qui ont préparé cet Exposé de projet qui décident de l’avenir du projet tant il est vrai que PRINCE2 essaie de se prémunir contre les situations dans lesquelles le juge et le parti sont rassemblés. Mais si l’on y réfléchit à deux fois, cela constitue le premier engagement formel de toutes les parties prenantes concernées par le projet. Cela garantit la bonne compréhension des enjeux du projet dès l’origine par les différentes parties prenantes, mais aussi pour le Chef de Projet, que le Comité de Pilotage de Projet aura validé sa retranscription des différentes consultations qu’il a menées avec l’Exécutif.

Pour que le Comité de Pilotage de Projet prenne la décision de continuer le projet, le Chef de Projet doit également proposer un planning d’initialisation du projet, qui consistera à préparer tout ce qui sera nécessaire pour le bon déroulement du projet.

On l’aura compris, le processus Elaborer un projet consiste essentiellement à :

• Nommer les acteurs du management de projet,
• Produire une étude qui posera les bases du projet en formalisant les exigences des utilisateurs, éliminer avec les fournisseurs potentiels les solutions qui ne pourraient aboutir,
• S’assurer que l’Exécutif pourra s’engager à financer le projet.

Les activités du Processus

Les six activités du processus Elaborer un Projet résument ce qui doit être fait avant qu’un projet ne soit « accepté ».

Nommer l’Exécutif et le Chef de Projet

C’est la direction de l’entreprise, de l’organisme ou du programme qui va nommer l’Exécutif qui sera le décisionnaire et le responsable ultime du projet. On voit ici que le processus Elaborer un projet est en partie de la responsabilité du « mandateur » ou commanditaire (ceux qui ont envoyé le Mandat de Projet). De fait, ce processus engage la majeure partie des parties prenantes responsables.

L’Exécutif est nommé en fonction du Mandat de Projet (quel est l’objet du projet ?), il est en fait le « mandataire » du projet en fonction également de sa capacité à engager et gérer des ressources financières pour le projet.

L’Exécutif a comme responsabilité principale d’être l’ultime décideur car il est également l’ultime responsable en cas d’échec du projet. Il est responsable de la nomination des membres de l’équipe projet et du travail que le Fournisseur comme l’Utilisateur Principal devront réaliser tout au long du projet.

L’Exécutif va ensuite nommer le Chef de Projet sous contrôle du Mandateur qui peut avoir ses préférences et définir le rôle et les responsabilités du Chef de Projet.

Dès que le Chef de Projet apparaît, il faut se représenter celui-ci munit d’un journal (un simple cahier à spirale 7.) qui le suivra tout au long du projet et lui permettra de noter de façon informelle tout ce qui peut concerner le projet. Ce journal est le « Journal de Projet ».

Recueillir les Retours d’Expérience

Cette activité consiste essentiellement dans la création du « Journal de Retour d’Expérience » dans lequel vont être consignées toutes les expériences utiles au projet, en provenance de projets antérieurs mais également d’organismes externes ou du mandataire.

Ce formalisme peut sembler inutile à première vue car cela pourrait être consigné simplement dans le Journal de Projet. L’importance que revêt ce journal est liée à l’obligation d’enregistrer les raisons et fondements des choix qui vont être faits par la suite.

Par extension, on pourrait retrouver dans ce journal des liens vers des normes, des standards, des études techniques, des méthodes, des benchmarks, des comptes rendus d’ateliers, etc., tout ce qui pourra permettre au Chef de Projet et à l’Exécutif d’orienter les choix qu’ils vont être amenés à faire lors de la rédaction de l’Exposé de projet et du Cas d’Affaire.

Cette activité répond précisément au 2e principe de PRINCE2 : Retours d’Expérience.

Composer et nommer l’équipe projet

Il s’agit de composer une équipe la plus efficace possible, c’est-à-dire compétente, ayant les connaissances et l’autorité suffisante afin d’assurer le succès du projet.

Essentiellement le Chef de Projet et l’Exécutif doivent regarder :

• s’il est nécessaire que le Chef de Projet soit assisté par une équipe de support dont nous verrons plus loin les prérogatives ;
• si le Chef de Projet doit jouer le rôle éventuel de Chef d’Equipe, sachant qu’à ce stade du projet, tous les Chefs d’équipe ne peuvent vraisemblablement pas être nommés, ils seront nommés par la suite à l’initialisation et vraisemblablement avant de lancer toute séquence de management ;
• qui pourra jouer le rôle d’Utilisateur Principal
• qui aura le rôle de Fournisseur Principal, sachant qu’à ce stade il est fort peu probable qu’il puisse être désigné notamment si le projet nécessite des accords commerciaux avec des acteurs externes ;
• qui aura le rôle d’Assurance Projet auprès du Chef de Projet si les membres nommés du Comité de Pilotage de Projet n’ont pas les moyens d’assurer cette responsabilité.

Le but de cette activité est d’arriver à définir la structure hiérarchique de l’équipe projet et de décrire les rôles et responsabilités et surtout les redevabilités » de chaque membre, répondant ainsi au 3 e principe de PRINCE2 : Rôle et Responsabilités définis.

Préparer l’ébauche du Cas d’Affaire

Le Cas d’Affaire, qui doit piloter le projet comme nous l’avons vu précédemment, découle du Mandat de Projet, ou pour des projets faisant partie d’un programme, du Cas d’Affaire qui aurait été déjà défini par ce programme.

L’Exécutif est responsable de la rédaction du Cas d’Affaire qui doit présenter une vue globale et notamment exposer les raisons de réaliser le projet et les bénéfices escomptés.

Le Chef de Projet pour sa part, produit la Description de Produit de Projet qui constitue la spécification globale de ce que le projet doit délivrer, et surtout présente les exigences du client, c’est-à-dire la qualité du Produit de Projet (et la façon de l’obtenir) et son corollaire les Critères d’Acceptation du Produit de Projet ainsi que les tolérances qualité de ces critères et les méthodes et responsabilité d’acceptation.

L’objet de la Description de Produit de Projet est essentiellement d’obtenir du client une vision claire de ce qu’il souhaite obtenir et des critères quantifiables afin de ne laisser que peu de doute quant à ses exigences. Ceci est essentiel, car à défaut, il est fort probable que le Produit de Projet ainsi mal défini soit rejeté faute d’un accord préalable.

Cette phase apparaîtra essentielle à tous ceux qui ont connu des projets qui n’en finissaient pas ou qui étaient remis en question en permanence faute d’avoir su définir à l’origine des Critères d’Acceptation rigoureux.

Cette ébauche de Cas d’Affaire est nécessaire afin d’obtenir l’acceptation du Comité de Pilotage de Projet, on ne parle encore dans cette phase du projet que d’ébauche car les informations ne pourront être complétées qu’avec les travaux réalisés dans le cadre de l’initialisation du projet. Il faut se rappeler également que lors de l’élaboration du projet il nous faut aller vite et sans moyens car aucun budget n’est assigné.

Définir l’Approche du projet et Assembler l’Exposé du Projet

Par cette activité, nous entrons dans le vif du sujet : comment allons-nous développer les produits ?

Ceci est l’objet de l’Approche projet qui consiste à déterminer comment le projet doit être abordé, en fait quelle est la solution « technico-commerciale » avant que ne puisse être planifié le projet.

Les questions auxquelles il est nécessaire de répondre sont :

• allons-nous développer en interne le produit ?
• à partir de quelle base existante interne ce produit pourrait-il être développé
• existe-t-il une solution commerciale qui pourrait nous servir ?
• sur quelle technologie allons-nous nous appuyer ?
• quels normes, standards et pratiques devons-nous utiliser ?

Là commence le véritable travail du Chef de Projet qui à l’aide de l’ensemble des informations et Retours d’Expériences recueillis, va déterminer par ses recommandations l’avenir du projet.

Le travail résultant est l’assemblage de l’Exposé de projet qui sera, comme son nom l’indique, une présentation éventuellement sous forme de diaporama faite au Ln Comité de Pilotage de la façon dont on envisage de mener le projet et de toutes les informations qui ont été recueillies. Cette présentation doit aider à prouver que la démarche présentée est la plus adaptée compte tenu du contexte, même et surtout si cette démarche tend à prouver que le projet n’est pas viable.

Cet Exposé de projet est donc l’assemblage des principaux documents déjà produits :

• Ebauche de Cas d’Affaire,
• Description de Produit de Projet,
• Approche du Projet,
• Structure de l’équipe Projet,
• Description des rôles des parties prenantes déjà identifiées.

En plus de ces documents, l’Exposé de projet doit contenir.

• Un rappel du contexte et des objectifs,
• Les résultats souhaités,
• Les périmètres et les exclusions,
• Les contraintes et hypothèses, permettant de justifier l’approche proposée,
• Les tolérances du projet qui seront affinées et reproduites lors de l’élaboration des plans,
• L’énumération de l’ensemble des parties prenantes pour ce qu’elles ont pu être identifiées à cette étape,
• Les interfaces avec d’autres projets notamment si le projet fait partie d’un programme.

Cet Exposé de projet dont l’origine est le Mandat de Projet est l’amorce d’autres Produits de Managements, notamment la Documentation d’lnitialisation de Projet.

Planifier la séquence d’initialisation

Alors que nous n’avons ni temps ni argent pour le processus Elaborer un projet, si l’on veut préparer correctement le projet après qu’il ait été décidé de le lancer, il faut du temps et des moyens pour initialiser le projet.

En fonction de la complexité du projet, il peut être choisi d’appliquer les processus Contrôler une séquence et Gérer une limite de séquence afin de réaliser certains Lots de Travaux nécessaires à une initialisation en relation avec la complexité du projet.

Ce Plan de Séquence d’initialisation est le premier plan créé par le Chef de Projet, il est joint à l’Exposé du Projet afin de donner au Comité de Pilotage de Projet toutes les informations nécessaires à la prise de décision.

Retour d’expérience

• Ne pas confondre But et Objectif, souvent trop de projets (objectif), ne répondent pas aux buts fixés par l’entreprise.
  Plus les exigences des utilisateurs sont précises et moins il y aura de risque de changement en cours de projet.
• Identifier les parties prenantes aussi exhaustivement que possible est indispensable pour mener à bien un projet. Aussi, identifier toutes les parties prenantes : tous les acteurs internes ou externes ayant un intérêt au projet, que ce soit le client, le commanditaire, l’entreprise, l’équipe projet, les entités fonctionnelles intervenantes, les entités internes impactées même indirectement, les sous-traitants des fournisseurs et les cotraitants, les organismes gouvernementaux, les syndicats et groupements d’intérêt, etc.
• L’identification est le prélude à une bonne communication à la condition que l’on ait déterminé quels sont les intérêts respectifs des parties prenantes.
• Laisser des traces écrites, car l’accord verbal ne laisse pas de traces et n’a pas de mémoire.
• Fixer des tolérances (coût, délais, périmètre) dès cette phase et les publier. • Ne pas hésiter à prolonger la phase d’initialisation en engageant des travaux préparatoires, des études complémentaires, etc.
• S’assurer dès cette phase que les enjeux sont compris et que la mobilisation des équipes est réelle et en adéquation avec leur charge propre.
• ldentifier dans les parties prenantes les réticents et ne perdez pas de temps à essayer de les convaincre.
• S’appuyer sur les leaders d’opinion pour vous gagner la masse des indifférents.
• Organiser une réunion formelle de lancement avec toutes les parties prenantes sous forme de « kick off » si possible et les plus hauts responsables concernés de l’organisation, mais aussi des fournisseurs et des entités métier concernées. En fonction du contexte, organiser un « pot » avec toutes les personnes dont les équipes de réalisation. C’est l’occasion pour tous les acteurs du projet de se rencontrer et de mettre un visage sur ce qui n’est bien souvent qu’un nom sur un document.
• Attention à la taille de l’équipe. Le nombre de liaisons/communications s’exprime en fonction du nombre de personnes par la formule :
  NBc = (N) x (N-1)/2
  
  Une équipe ne devrait pas en principe dépasser sept personnes, ce qui induit déjà 21 liaisons possibles.
  Même si PRINCE2 organise la communication, les interactions entre des personnes trop nombreuses nuisent à la réussite du projet.

En conclusion, l’élaboration du projet doit être réalisée même si elle doit être menée rapidement et sans fonds.

« Un problème sans solution est un problème mal posé. »

Albert Einstein

Nota : les produits entre parenthèses sont des produits de management non décrits précisément en annexe dans le manuel PRINCE2.

Figure 6.10 — Principaux Échanges et Produits de Management du Processus Élaborer un projet.

Tableau 6.3 Le CHAOS et le processus Élaborer un projet.

Réponse de ce chapitre aux facteurs de réussite du projet

Cette phase est essentielle car elle devrait permettre d’éliminer les proiets qui ne pourront pas aboutir pour des raisons de faisabilité, de financement ou simplement d’intérêt pour l’entreprise ou les utilisateurs.

LE DÉMARRAGE DU PROJET

Le préprojet est terminé, le Comité de Pilotage de Projet a donné son feu vert pour Initialiser le projet, il s’agit maintenant de mettre le projet sur les rails. Avant d’engager des moyens importants sur le projet, mieux vaut commencer par travailler sur les fondations du projet, tant il est vrai que 90 % de la réussite est dans la préparation.

Il faut transformer le but du projet en objectifs de réalisation quantifiables de façon à donner l’assurance au Comité de Pilotage de Projet que ces objectifs seront atteints.

Un des objectifs de l’Initialisation du Projet est de permettre à l’organisation de comprendre comment les objectifs de réalisation pourront être atteints en documentant les différents aspects de suivi et de contrôle du projet et en préparant les méthodes et outils nécessaires.

Avant de développer le processus Initialiser le projet, il est nécessaire de présenter les trois thèmes dont les stratégies vont être développées dans ce processus :

• La Qualité,
• Le Changement (inclus dans la Stratégie de Configuration),
• Les Risques.

THÈME : QUALITÉ

Selon PRINCE2 : « Le thème Qualité a pour objectif de définir et mettre en ceuvre les moyens utilisés pour le projet pour créer et vérifier les Lnproduits adaptés aux besoins ».

Cette définition permet de situer exactement quelle est la position de PRINCE2 quant à la qualité. Il ne s’agit pas de redéfinir une méthode qualité novatrice mais de s’en tenir au niveau du projet et d’essayer de spécifier et de mettre en ceuvre les ressources et capacités nécessaires au contrôle des produits. De par son 6e principe, la focalisation sur le produit, PRINCE2 considère que la qualité se doit d’être axée sur le produit qui doit répondre à des besoins et apporter des bénéfices.

Le modèle du client au client

La définition de la qualité par PRINCE2 issue de l’ensemble des normes ISO 9000 est :

La qualité est l’ensemble des fonctionnalités et caractéristiques inhérentes ou attribuées d’un produit, d’une Personne, d’un Processus, d’un service et/ou d’un système lui Permettant de démontrer qu’il répond aux attentes ou qu’il satisfait aux besoins, aux exigences ou aux spécifications convenues ».

Le schéma suivant présente le modèle du client au client adopté par la plupart des méthodologies ayant trait à la qualité.

Figure 6.11 — Le modèle du « client au client » IS09000 : 2000.

Ainsi la qualité au sens PRINCE2, bien qu’axée sur le produit, doit prendre en compte les personnes, les processus, les services et les systèmes concernés par le projet.

La problématique de la qualité se résume souvent dans la définition de ce que l’on place sous ce terme qualité. Le schéma suivant donne les quatre faces de la qualité (SLA = Service Level Agreement, KPI = Key Performance Indicator)

Si lors de la définition des exigences, ces quatre faces ne sont pas prises en compte, même si le produit répond à la qualité attendue, déclinaison stricto sensu de ce que o veut le client, au final, la qualité perçue peut ne pas être au rendez-vous et donner un produit rejeté en opération. Autrement dit, les caractéristiques techniques d’un produit n’en font pas un produit acceptable, tant il est vrai qu’un produit doit répondre à un besoin client qui n’est peut-être pas celui auquel le fournisseur pense au premier abord :

Selon Les bonnes pratiques ITIL : « Les clients n’achètent pas des produits, mais la satisfaction d’un besoin particulier ».

6.5.2 Planification et Contrôle

Dans le cadre de PRINCE2, le processus mis en place est le reflet de ces exigences en ce qu’il est scindé en deux sous-ensembles, la Planification de la Qualité et le Contrôle de la Qualité, qui répondent à la partie droite du schéma sur la qualité.

SLA : Convention de Service

KPI : Indicateur de Performance

Figure 6.12 — Les 4 faces de la qualité.

La Planification de la Qualité répond à certaines exigences et doit définir les objets à contrôler et les contrôles. Le Contrôle de la Qualité est la mise en oeuvre des moyens de contrôle.

La Planification de la Qualité demande que tous les produits du projet soient identifiés et définis dans les Descriptions de Produit, le Contrôle Qualité intervenant pour mettre en place les méthodes et le Contrôle Qualité tout au long du projet, de façon à garantir notamment au Comité de Pilotage de Projet la qualité de ce qui sera livré.

Le schéma 6.13 résume les activités qualité menées tout au long du projet.

Ln Les exigences qualité sont le fruit de négociations avec le client lors de la conception du Produit de Projet en ce qui concerne ses attentes, mais également de toutes les contraintes présentes sous forme de normes, standards, réglementations, législations, « façon de faire », retours d’expérience, faisabilité technique, etc. Le référentiel ITIL (Information Technology Infrastructure Library) résume ces contraintes par le schéma 6.14.

La « solution acceptable » de ce schéma est celle pour laquelle il y aura lieu de définir des Critères d’Acceptation.

Ces Critères d’Acceptation sont structurés en une liste de définitions mesurables des caractéristiques d’un produit. Ces caractéristiques physiques, logiques, financières doivent être mesurables afin qu’une acceptation puisse être obtenue sans objection quant aux qualités présentées par le produit terminé.

Figure 6.13 — Les activités de la qualité.

Figure 6.14 — Les contraintes de conception.

Cette liste de Critères d’Acceptation peut être priorisée car certains critères peuvent ne pas être compatibles ou d’importance moindre, ceci permettant de se mettre d’accord avec le client sur les réelles priorités du projet en termes de qualité.

PRINCE2 propose la liste de priorité suivante (« MoSCoW ») :

• « Must have » : Doit obligatoirement avoir •
• « Should have » : Devrait avoir ;
• « Could have » : Pourrait avoir
• « Won’t have for now » : N’aura pas pour l’instant.

Ces Critères d’Acceptation sont documentés dans la Description de Produit de Projet constitué dans la phase de préprojet.

Si les produits composant le Produit de Projet ne peuvent tous être définis sous forme de Critères d’Acceptation lors de cette phase, dans tous les cas, ces critères doivent être arrêtés lors de la phase d’initialisation du projet et vérifiés à chaque fin de séquence de management.

Le Produit de Management Description de Produit de Projet faisant partie des Produits de Management de type référentiels, en cas de changement d’un de ces critères, la procédure de Maîtrise des Changements est utilisée et ce changement doit être validé par le Comité de Pilotage de Projet.

Répétons-le, les critères de qualité se doivent d’être mesurables, sinon ils n’ont aucune valeur. Tout critère subjectif est à proscrire. Ainsi les notions d’esthétique, d’attrait, d’accessibilité, d’intérêt, d’harmonie, de « ré utilisabilité », de pertinence, etc. qui ne seraient pas adossées à une caractéristique mesurable n’ont aucun intérêt, car sujette à discussion.

Certains critères peuvent être difficiles à mesurer, dans ce cas il faut être capable de transformer ces critères en d’autres critères mesurables. Par exemple la « beauté » d’un bâtiment se résume en des critères de respect de loi d’esthétique ou dans le résultat d’un concours.

Voici ce qu’en dit un commentaire concernant l’article 53 de la directive 2004/18 du 31 mars 2004 (Site internet : http://www.info-marches-publics.net).

Un critère pouvant être prépondérant

« A travers ce critère, /e pouvoir adjudicateur exprime la nécessité pour le candidat de prendre en compte l’intégration de l’objet du marché au sein de son environnement, d’en apprécier l’harmonie avec ce qui l’entoure. Autrement dit, il s’agit d’attendre des prestations qu’elles correspondent à certains critères de « beauté ».

Dans un arrêt du Conseil d’état du 28 avril 2006, la question s’est posée de savoir si ce critère pouvait être déterminant dans l’attribution d’un marché.

En l’espèce, le marché attribué avait pour objet du mobilier urbain. Un candidat estimait avoir été écarté injustement sur la base du critère esthétique.

Or, la haute juridiction a reconnu que le pouvoir adjudicateur pouvait retenir le critère esthétique comme critère prépondérant d’attribution du marché.

Cependant, en l’espèce, le Conseil d’état a donné raison au requérant en estimant que le pouvoir adjudicateur n ‘avait pas rempli correctement ses obligations de publicité et de mise en concurrence. En effet, ni les documents contractuels, ni la réponse à la demande de précisions émanant du candidat évincé n’ont fourni d’indication sur les prestations attendues au regard du critère esthétique. »

Ce commentaire est clair et semble justifié. Le Contrôle de la Qualité consiste à mettre en oeuvre ce qui a été défini par la Planification de la Qualité. Il s’agit non seulement de mettre en œuvre les méthodes mais également de recueillir les preuves que la qualité désirée est acquise et d’obtenir les approbations des produits et l’acceptation finale du Produit de Projet.

PRINCE2 distingue deux méthodes de qualité principales.

• Les méthodes « en cours de processus » : dans ce cas, des méthodes ou procédures spécifiques sont intégrées tout au long de la réalisation, par exemple, en automatisant certains contrôles le long d’une chaîne de production, l’utilisation de méthode de type Lean6Sigma dans le processus de fabrication ou simplement en organisant des vérifications ponctuelles lors de la réalisation des produits.
• Les méthodes d’évaluation : il s’agit en général de méthodes de contrôle a Posteriori, par exemple des tests ou des inspections.

En fonction de la qualité recherchée et des moyens du projet, les deux méthodes sont conjugables. Tout en conservant à l’esprit que plus tôt une non-conformité est relevée et moindre est le coût de correction.

Dans tous les cas, les méthodes doivent être structurées et formelles, c’est-à-dire notamment planifiées et documentées.

PRINCE2 propose une Technique de Revue Qualité, tout en précisant que cette technique n’est pas obligatoire et qu’il existe de nombreuses autres techniques d’inspection qualité. Ce qui est obligatoire par contre c’est l’obtention formelle de l’approbation d’un produit.

Technique de revue qualité

Les trois étapes de la revue qualité

1. Préparation de la revue

Il s’agit de planifier la revue en désignant les interlocuteurs, s’assurer qu’ils sont o disponibles et en possession de ce qui leur est nécessaire pour réaliser les vérifications du produit avant la revue. Ces vérifications se concrétisent par la rédaction d’une liste d’observations [questions qui seront soumises lors de la revue.

1. Ordre du jour de la réunion

Lors de la revue, le produit est présenté et les objections ou questions sont abordées et des actions éventuelles planifiées. Un document récapitulant ces actions doit être communiqué aux parties concernées. Le résultat de la revue peut être :

• Achevé : le produit est conforme.
• Achevé sous condition : des réserves sont émises et les actions doivent préciser comment ces réserves peuvent être levées.
• Incomplet : le produit n’est pas conforme et devra être soumis à une autre revue qualité.

Concernant les deux derniers statuts du produit passé en revue, une décision/action sera à prendre afin de traiter cette non-conformité.

1. Suivi de la revue

Après cette revue, si des actions sont nécessaires afin de corriger ce qui a été défini ou entériner les défauts (voir la notion de Compromis), elles sont coordonnées, vérifiées et contrôlées. A la suite de la réalisation de ces actions, le produit est approuvé par la revue et l’approbation doit être obtenue des approbateurs.

Les rôles de la Revue Qualité

Le Président. Il est responsable de la tenue de la revue, en participant à sa mise en oeuvre, en cherchant un consensus entre les autres intervenants de la revue et en communiquant les résultats.

L’Administrateur. C’est le support administratif du Président, notamment en ce qui concerne l’enregistrement des actions, des résultats, des enregistrements qualité, etc.

Le Représentant. C’est lui qui soumet le produit à l’approbation, il fait généralement partie de ceux qui ont réalisé le produit. Il répond aux questions/observations listées lors de la préparation de la revue. A ce titre, si le produit n’est pas conforme, c’est lui qui coordonnera les actions pour achever le produit.

Le(s) Vérificateur(s). Il est vraisemblable que ce rôle soit rempli par plusieurs experts techniques ou fonctionnels qui vérifieront le produit en fonction de leur domaine de spécialité propre. Ils remplissent une liste de questions/observations qui seront consolidées par le Président.

L’Approbateur. La ou les personnes en charge d’approuver le produit, si cela est possible dans le cadre de la revue Qualité.

L’Assurance Qualité

« Assurance Qualité » est un terme qui peut prêter à confusion, suivant qu’il est pris dans le sens de « l’activité qui permet de se donner l’assurance que les critères de Ln qualité sont atteints » , ou dans le sens de « l’entité opérationnelle qui est chargée de ces opérations et de la définition du Système de Management de la Qualité », c’est-à-dire les normes et procédures à appliquer dans l’organisation pour vérifier que la qualité désirée est au rendez-vous.

Dans les deux cas, cette Assurance Qualité se doit d’être indépendante des acteurs du projet afin de conserver une certaine impartialité.

De façon courante, un Système de Management de la Qualité existe dans une organisation, d’où découle un Plan d’Assurance Qualité que PRINCE2 fait produire au sein de la Stratégie Qualité, qui est à la fois le nom de l’activité et celui du Produit de Management conséquent.

Pour information, l’Assurance Qualité répond à une norme (8402-94) qui en donne la définition suivante :

Figure 6.15 — Les composants de l’Assurance Qualité.

« Ensemble des activités préétablies et systématiques mises en ceuvre dans le cadre du système qualité, et démontrées en tant que besoin, pour donner la confiance appropriée en ce qu’une entité satisfera aux exigences pour la qualité ».

L’Assurance Qualité a ainsi pour but de rassurer le client sur la qualité de la prestation de l’entreprise. Elle se décline sous la forme d’un document écrit, appelé « Manuel d’Assurance Qualité » , récapitulant l’ensemble de la politique qualité de l’entreprise ».

Comment comprendre les interactions entre Planification, Contrôle et Assurance Qualité et l’Assurance Projet ?

La Planification et le Contrôle de la Qualité sont organisés au sein du projet de façon à s’assurer de la qualité des livrables, il s’agit également de donner au Comité de Pilotage de Projet les moyens internes au projet de vérification de la qualité de tous les aspects du projet.

L’Assurance Qualité, au sens entité, est une émanation de l’organisation, indépendante du projet qui vérifie que le projet suit les recommandations/normes/standards o prescrits par l’organisation.

L’Assurance Projet joue le même rôle mais est interne au projet et réfère au Comité de Pilotage de Projet.

Dans les faits, les activités opérationnelles de ces Assurances vont se recouper. Il est difficile d’imaginer une Assurance Projet qui n’aurait pas pris en compte les prescriptions de l’Assurance Qualité.

Il y a donc lieu pour le Comité de Pilotage de Projet de vérifier que le niveau adéquat d’assurance est présent, mais aussi que la charge de travail induite est proportionnée au projet, et d’organiser le projet de façon à ce que ce niveau adéquat d’assurance soit présent.

Tableau 6.4 — Relations entre Assurance Projet et Assurance Qualité.

Retour d’expérience

• La qualité passe par la stabilité d’après Edward Deming, inventeur de la roue du même nom. Un projet en perpétuelle évolution n’aboutira pas.
• La qualité ne doit pas se transformer en surcroît de bureaucratie.
• La véritable qualité vient de la rencontre de deux volontés, l’opérationnelle qui cherche à améliorer les procédés et celle de la hiérarchie qui cherche à mieux contrôler. Sans ces deux volontés, point de salut.
• La « sur-qualité » coûte cher et surtout elle ne rapporte rien.
• Seul ce qui se contrôle peut se gérer, seul ce qui se mesure peut se contrôler, seul ce qui est défini peut se mesurer.

Tableau 6.5 — Le CHAOS et le thème qualité.

Réponse de ce chapitre aux facteurs de réussite du projet

Le thème Qualité, essentiel pour un projet et donc pour PRINCE2, permet tout au long du projet de s’assurer que les utilisateurs ont bien livré leurs exigences et valident les produits au fur et à mesure de leur réalisation. Bien que cela ne soit pas spécifique à ce thème, la mesure des bénéfices en cours de projet, pour ceux qui pourraient l’être, permet également de vérifier la réalisation des objectifs et par là, la vision de l’organisation.

THÈME : CHANGEMENT

Lors de toutes les phases d’un projet peut survenir un événement qui doit être pris en compte et qui modifie le projet. Rares sont les projets qui ne subissent pas de changements en cours de réalisation.

Cet événement ou Requête de Changement peut provenir de multiples sources, les utilisateurs, les fournisseurs, les acteurs du projet et de façon générique, de toutes les parties prenantes identifiées ou non.

Les changements peuvent avoir deux raisons principales : recherche de gain ou correction d’erreurs. Dans les deux cas, il y a lieu de définir une référence afin de pouvoir évaluer l’impact du changement et prendre les décisions adéquates. Cet impact ne peut être évalué que si l’on dispose d’une Base de Référence. Cette base de référence est constituée à partir des produits de management de type référentiels, comme le Cas d’Affaire, la Documentation d’lnitialisation de Projet, les Descriptions de Produits, etc. (voir la typologie des Produits de Management), qui lorsqu’ils ont été enregistrés, constituent le socle descriptif du projet. Ainsi, tout événement susceptible de modifier ce socle est perçu comme un changement et doit être analysé, évalué, faire l’objet d’une proposition d’évolution, autorisé et enfin implémenté ; c’est-à-dire que l’on cherche à Maîtriser les Changements.

De façon générique, le thème Changement incorpore les incidences et la gestion des configurations.

Le terme « Incidence » désigne tout événement qui pourrait avoir un impact sur le projet et qui doit éventuellement être pris en compte. Cela peut être quelque chose qui n’était pas prévu et qui doit être éventuellement corrigé ou une information qui doit être prise en compte car elle peut avoir un impact sur le projet. Ainsi, la définition de l’« Incidence » est suffisamment générique pour recouvrir tout ce qui proviendrait de l’extérieur ou de l’intérieur du projet et qui doit être traité, hors les risques avérés. A ce titre, les Requêtes de Changement sont des incidences, ainsi que les Hors-Spécifications qui sont deux types d’incidence.

Tableau 6.6 — Les types d’incidence.

Les Hors Spécifications ne sont qu’un sous-ensemble des problèmes ou des soucis ; ils sont différentiés par leur traitement. Un Hors Spécification touche ce qui avait été Ln spécifié et qui n’a pas été fait ou été mal fait. Dès lors, une décision doit être prise pour accepter ce défaut ou cette non-réalisation. Le Comité de Pilotage de Projet peut avaliser cette défaillance sous la forme d’un Compromis qui n’est autre que l’acceptation d’une défaillance de réalisation, appelé couramment « non-conformité ». Par exemple, lors du contrôle d’une construction d’un immeuble, les plaques isolantes de recouvrement de l’intérieur des murs ne sont pas ajustées dans le respect de normes de la profession, qui figurent dans les normes à respecter ; comme le projet risque de prendre du retard si le fournisseur doit refaire ce plaquage, un Compromis est accordé car cette non-conformité pourra être masquée, par exemple, par le revêtement de surface prévu.

Le tableau suivant présente les différents types de réponse que peut émettre le Comité de Pilotage de Projet à l’un des trois types d’Incidence. Attention, ceci ne veut pas dire que toutes les incidences seront soumises au Comité de Pilotage de Projet, car en fonction de leur impact et suivant le principe de Management par exception, elles peuvent être traitées directement par le Chef de Projet.

Le thème Changement contient donc la Maîtrise des Changements, mais aussi la Gestion des Incidences comme nous venons de le voir, et la Gestion des Configurations.

La Gestion des Incidences

Le Chef de Projet est en permanence à l’écoute de tout événement qui pourrait affecter son projet, quelle que soit l’origine des incidences, en provenance du client, d’un fournisseur, d’un responsable d’équipe ou toute autre partie prenante ou informateur. Ainsi, l’annonce non prévue de la sortie d’un nouveau produit qui pourrait constituer un inconvénient ou un avantage pour le projet doit être traitée comme une incidence.

En fonction de son appréciation de l’importance de l’incidence, le Chef de Projet enregistrera cette incidence de façon informelle et/ou formelle.

Tableau 6.7 — Réponses du Comité de Pilotage du Projet aux incidences.

Plusieurs Produits de Management sont à sa disposition. En premier lieu, il gère son Journal de Projet qui doit lui servir pour transcrire tout ce qui a trait au projet, par exemple une incidence est inscrite de façon informelle sur ce journal. S’il juge que l’incidence doit être formalisée et portée à la connaissance des acteurs du projet, l’incidence est inscrite dans le Registre des incidences, ce registre n’est que la formalisation de ce qui est inscrit dans le journal. Au cas où il le juge utile, par exemple parce que l’incidence est importante pour le projet, le Chef de Projet émet un Rapport d’Incidence, retranscription formalisée dont le but est d’informer « formellement » le Comité de Pilotage de Projet. S’il est probable que l’incidence ait un impact conséquent sur le projet, c’est-à-dire en cas de dépassement de tolérance (voir chapitres Progression et Plan), le Chef de Projet émettra également un Rapport d’Exception.

Attention, ces rapports ne sont pas exclusifs, l’émission d’un Rapport d’Exception n’exclut pas l’émission d’un Rapport d’Incidence préalable. Il s’agit en fait d’une escalade correspondant à la gravité de l’incidence.

Figure 6.16 — L’enregistrement d’une incidence

Il faut noter que le Rapport d’Incidence permet, outre les Incidences, de rapporter o les Hors Spécifications et les Changements au Comité de Pilotage de Projet qui répondra par des conseils, des Compromis, des autorisations de changement. Et cela Ln peut se concrétiser également par une demande de Plan d’Exception si, suite à un

Rapport d’Exception, le Comité de Pilotage de Projet décide de faire cette demande. Pour plus d’information sur la gestion des Incidences, voir le chapitre Contrôler une séquence.

La Maîtrise des Changements

On parle bien ici de Maîtrise des Changements c’est-à-dire d’essayer non pas de freiner les changements mais de les gérer de bout en bout, en commençant par leur captation et leur autorisation préalable.

Selon Héraclite, « La seule constante c’est le changement », avoir une maîtrise de ces changements, c’est s’assurer de la maîtrise du projet.

Cet encadrement des changements répond au besoin non pas de limiter ces changements mais de les contrôler en s’assurant de leur impact sur le projet. En effet, un projet en perpétuelle évolution n’a que peu de chance d’aboutir à un résultat. L’histoire de l’aéronautique est pleine de projets d’aéronefs qui n’ont jamais été concrétisés car à force de vouloir tout faire faire au même engin, celui-ci était inapte à remplir quelque mission que ce soit. Ce fut le cas du programme CRB (Chasse, Reconnaissance, Bombardement) décidé dans les années 1920 par le gouvernement français qui aboutit à avion de chez Breguet qui ne fut suivi d’aucune série car inapte à remplir correctement une seule des trois missions antinomiques et irréalistes dans l’état des connaissances de l’époque. En informatique, cela amène souvent à produire des projets sans architecture compréhensible et surtout non maintenables car trop complexes. Et je vous passe les modèles d’automobile que je ne me risquerais pas à citer et qui à force de vouloir être grande et petite, économe mais luxueuse, rapide mais sûre, restent dans les cartons. Bref, on n’invente pas tous les jours une Traction Avant de chez Citroën ou un Renault Espace.

On peut noter également que les méthodes AGILE sont réputées permettre de mieux gérer des projets indéfinis. Ceci devrait être pris en compte dans les versions ultérieures de PRINCE2.

Un Budget de changement peut être incorporé au budget du projet, notamment sur les projets pour lesquels il est prévisible que de nombreuses demandes de changement puissent être faites, ceci étant d’autant plus prévisible si le projet est complexe, si les exigences client ne sont pas vraiment arrêtées, si la technique n’est pas bien maîtrisée, si la technologie est en constante évolution, etc. Ce budget est inclus dans les budgets des différents plans (voir thème Plan), il sert à financer les coûts des changements mais également les coûts des études de ces changements.

Ce budget ressemble plus à une provision comptable car il n’est pas obligatoirement utilisé.

Ce budget peut être affecté à une Autorité de Changement distincte. Les critères d’affectation de ce budget de changement tiennent évidemment compte des critères o retenus pour affecter certains changements à cette autorité. Ce budget peut également être « temporel » en ce qu’il peut être prévu pour une phase particulière du projet, par exemple à l’initialisation d’un projet complexe, si des études préalables doivent être réalisées conditionnant le coût du projet lui-même.

Maîtriser les changements, c’est

• Collecter les requêtes de Changement : ne laisser qu’un point d’entrée unique à toute requête de changement pour le qualifier et l’escalader au bon niveau de décision ;
• Examiner le changement demandé : évaluer l’impact du changement sur le projet ;
• Proposer une solution : trouver une solution efficiente permettant de concilier les risques, les coûts, les délais, etc. ;
• Autoriser le changement : affecter la décision à l’autorité du changement adéquate (voir Autorité de Changement)

Figure 6.17 — Procédure de Maîtrise des Changements.

• Mettre en oeuvre le changement : produire les Lots de Travaux complémentaires nécessaires pour la mise en œuvre du changement.

Cette procédure peut s’appliquer également à la gestion des autres incidences (Problème ou Souci, Requête de Changement ou Hors-Spécification), tant il est vrai que le traitement est le même quelle que soit la nature de l’incidence. Dans les trois cas, il faudra Collecter, Examiner, Proposer, Autoriser et éventuellement Mettre en ceuvre. Cette procédure est transverse à plusieurs processus (voir le processus Contrôler une séquence).

La Gestion de la Configuration

La Maîtrise des Changements implique la connaissance des produits et des relations entre ces produits gérés ou non par le projet, sous la forme d’une Gestion de la Configuration.

Qu’est-ce qu’une Configuration ?

Une configuration est un arrangement d’éléments fonctionnels en fonction de leur nature et caractéristiques principales. Cela se résume souvent par la description d’une structure composée d’éléments et de relations, suivant le modèle Entité-Association que les méthodes MERISE, SADM, SDM/S ont utilisées à partir des années 1970, repris également par tous les développements sur les bases de données relationnelles.

Ce modèle Entité-Association a été également repris dans les Diagrammes de Bachman dont les travaux ont permis notamment de réaliser les Systèmes de Gestion de Base de Données (SGBD) actuels.

Pour comprendre ce qu’est une configuration, le mieux est de la représenter sous forme schématique.

Figure 6.18 — Exemple de configuration matérielle informatique.

Figure 6.19 — Exemple de configuration mécanique.

Ces configurations peuvent correspondre à différents types de représentation accessible à des professionnels de la spécialité en question. Par exemple concernant la configuration du matériel informatique, il faut comprendre que l’utilisateur a accès à son poste de travail ou que son poste de travail échange des données avec un serveur (matériel partagé) au travers d’un réseau informatique international (jargon : WAN) concernant la représentation mécanique, du fait de leur position sur cette vue éclatée, la pièce 5 est positionnée après la pièce 4 sur l’axe 1 et ce moyeu est symétrique, etc.

Ces deux représentations pourraient sous-entendre que seuls les produits réalisés par le projet sont gérés en configuration. En réalité pas seulement, car les Produits de Management associés ont leur place dans les représentations ainsi que des produits qui ne seraient pas réalisés par le projet appelés « Dépendances ou Produits Externes

Ainsi, sur la représentation de matériel informatique, alors qu’elle représente l’ensemble d’un site par exemple, le projet n’a peut-être en charge que les aspects réseau, ou sur la représentation mécanique, le projet ne s’occupe que du montage et la représentation est en elle-même que la partie « notice d’assemblage » qui est un des produits à fournir par le projet.

Ces structures schématiques peuvent être représentées sous forme d’organigramme hiérarchique ou schéma heuristique :

Figure 6.20 — Exemple de structure de configuration.

Ou simplement sous forme de liste décalée :

Exemple succinct pour la construction d’un Pavillon :

1. Aménagement préalable
   1. Suppression de la végétation
   2. Sondage géotechnique
2. Fondation / Gros Œuvre
   1. Excavation

Figure 6.21 — Exemple de mise en forme de type MindMap.

• 1. Dalle
  2. Murs

1. Couverture
   1. Charpente
   2. Tuiles
2. Huisseries
3. Plomberie
4. Electricité
5. Peinture

Ou toute forme qui paraîtrait adaptée au contexte du projet comme une simple description verbale.

Les Eléments de Configuration peuvent être :

• Des Produits,
• Des groupements de produits,
• Des produits de management,
• Des produits ou dépendances externes.

Mais on peut aller plus loin, ils peuvent aussi être :

• Des contrats,
• Des entités opérationnelles,
• Des lieux géographiques,
• Des processus,
• Des compétences,
• Des règlements, etc.

Pour certaines entreprises comme les cabinets d’études, l’outil de gestion de o configuration se résumera dans une Gestion Electronique de Document (GED), puisque leurs produits seront essentiellement constitués de documents.

Ln L’ensemble de ces éléments mis en relation constitue un outil permettant d’estimer l’impact d’une incidence et ainsi de pouvoir prendre des décisions étayées à l’aide d’informations si possible complètes et à jour.

Pour définir le niveau de granularité, c’est-à-dire la finesse de description des produits, il est nécessaire de prendre en considération le niveau d’indépendance des produits. En effet, la gestion des configurations doit essentiellement permettre de mesurer l’impact d’une incidence, aussi si la granularité est trop fine, le risque de ne plus savoir tenir à jour les enregistrements est importante, à l’inverse un niveau de granularité trop élevé ne fournira pas les données nécessaires. Par exemple, il n’est pas forcément nécessaire de détailler les composants d’un PC si le niveau « Poste de Travail » est suffisant. Il est également possible qu’un Elément de configuration soit une structure d’autres éléments de configuration, par exemple, l’appellation « four » regroupe l’ensemble des éléments constituant le four qui ont eux-mêmes leur propre description en termes d’élément de configuration.

La Gestion de la Configuration permet au projet de déterminer pour toute incidence, l’impact direct (le changement ne touche qu’un seul produit, ce qui est relativement rare) ou l’impact « collatéral » (le changement nécessite de revoir plusieurs produits en relation). Par exemple, si la documentation nécessaire à la formation n’est pas imprimée, cette incidence provoque une annulation ou un décalage de la formation. Autre exemple pratique, « toute modification d’un Produit de Management entraîne un changement qui doit être autorisé par le bon niveau d’autorisation des changements » ; on a une relation (règle dans ce cas) entre un produit donné et une responsabilité décisionnaire.

La Gestion de la Configuration n’a dans tous les cas de véritable valeur ajoutée que si l’aspect « relationnel » est développé.

Ces relations se concrétisent par des verbes, comme : tourne sur… , est situé à…, fait partie de… , lance/arrête…, contrôle… , met à jour…, crée…, récupère…, est le contact de…, est le contrat de…, est propriétaire de…, est en copie de…, etc.

L’emploi de cardinalités ou multiplicités est également conseillé afin de mieux décrire si les relations sont uniques (1 à 1) ou multiples (n à n). Par exemple, la Description de Produit s’applique à un seul produit, relation 1 à 1, en revanche, le Plan de Projet décrit plusieurs Séquences, relation 1 à n (fig. 6.22).

Figure 6.22 — Exemple de relations et de cardinalités.

Les activités de la Gestion de la Configuration

PRINCE2 propose la procédure de Gestion de la Configuration suivante :

1. Planification : déterminer le niveau adéquat de granularité de la gestion de la configuration,
2. Identification : identifier tous les éléments de configuration,
3. Contrôle : mettre à jour les configurations en gardant le contrôle sur ce qui est fait,
4. Suivi d’état : sous la forme d’un Rapport d’Etat du Produit qui est un instantané historique de la configuration qui peut être nécessaire au Chef de Projet à tout moment (fin de séquence ou de projet, incidence, risques, progression),
5. Vérification et Audit : revue et audit de la configuration afin de s’assurer de la validité des informations.

De façon pratique, parce que la Gestion de la Configuration se doit d’être outillée pour être efficace, cette procédure peut également prendre la forme simplifiée suivante •

• Phases Amont
  • Conception : concevoir le modèle de données, déterminer la granularité et identifier les modèles d’éléments de configuration ;
  • Peuplement : construction ou paramétrage de l’outil et mise à jour initiale des données et relations ;
• Phases Récurrentes :
  • Opération : utilisation de l’outil et contrôle de performance de cette utilisation ;
  • Surveillance : détection des anomalies (contenu) et corrections.

Ce découpage apparemment similaire permet de mieux concrétiser les phases de préparation en amont (Conception et Peuplement) et courantes (Opération et Surveillance). Le suivi d’état n’étant que l’utilisation de l’outil pour sortir l’état préformaté nécessaire, par exemple un Rapport d’Etat du Produit.

Cette gestion de la configuration, simple dans ses principes, peut très vite devenir impossible à maintenir à jour et représenter un travail incompatible avec le budget du projet. Même sur un petit projet, les éléments de configuration se comptent en dizaines voire en centaines, de multiples intervenants vont modifier en permanence ces éléments de configuration aussi le caractère « administratif » de la Gestion de Ln la Configuration ne les encourage pas en général à ce que les Enregistrements de Configuration soient mis à jour.

Il n’y a pas de solution miracle, même si l’automatisation de cette gestion permet de pallier un manque de discipline ; cette discipline est nécessaire sous peine de voir se dégrader le niveau de complétude et de véracité des enregistrements. Ceci entraîne irrémédiablement une désaffection de la gestion de configuration, non conforme à la réalité opérationnelle.

Du fait d’une gestion qui peut s’avérer très rapidement lourde, le Support Projet, s’il existe, reprend la tâche opérationnelle de tenue à jour des enregistrements. Et de toute évidence, le maintien en condition opérationnelle tant de l’outil que des données est du ressort de l’organisation cliente (mais aussi parfois fournisseur, sinon les deux), ne serait-ce que parce qu’après le projet tout ou partie de ces enregistrements devra continuer à être gérée au niveau opérationnel. Ce maintien est en général assuré par l’organisation cliente mais parfois également de façon redondante par les fournisseurs à des fins de maintenance ou de connaissance du parc installé chez un client par exemple.

Dans le thème Plan, la 4e phase consiste à réaliser un Diagramme de Flux des Produits qui donne la Liste des produits spécialistes à réaliser et l’ordre dans lequel ils doivent être réalisés ; ceci constitue une partie du modèle de données de configuration car certaines relations de dépendances (chronologiques, hiérarchiques, géographiques) peuvent être reprises.

Retour d’expérience

• Le but principal de la gestion de configuration est de donner les moyens à la maîtrise de changements. Aussi, la granularité des enregistrements doit être en relation avec ce but : trop de détails et cela devient vite non maintenable, pas assez de détails et ces enregistrements sont opérationnellement inutiles.
• Le prosélytisme est de rigueur, il faut essayer de convaincre les acteurs que partager une information juste est toujours préférable à de multiples formats disparates et inaccessibles.
• Les outils informatiques simples et bon marché permettent de mettre en œuvre rapidement une gestion de configuration adaptée à un projet, le mieux étant que cette gestion de configuration soit gérée par l’organisation, afin de s’inscrire dans la pérennité.
• Si cela est trop compliqué à mettre en place, faire une simple gestion des produits principaux, même sans relation, peut être suffisant sur des petits projets.
• Plus le projet est complexe ou critique et plus une véritable Gestion de la Configuration est indispensable.
• Le Diagramme de Flux des Produits peut constituer le modèle relationnel simple de la gestion de configuration.
• Maîtriser les changements, c’est avant tout gérer les flux d’information entre les acteurs du projet. A défaut, les produits réalisés comporteront des modifications par rapport aux Descriptions de Produit aussi inutiles que coûteuses. Les relations entre utilisateurs et équipes de projet sont particulièrement à surveiller dans ce cadre.
• Gérer les incidences requiert de la part du Chef de Projet une connaissance technique et fonctionnelle exhaustive qu’il ne peut pas avoir. Se référer à des experts est dès lors indispensable, le devoir de conseil du Comité de Pilotage de Projet doit être mis à profit, ne serait-ce que pour trouver ces experts.
• Trop de changements tuent le projet et indique que la phase préprojet a été mal conduite (technologie non maitrisée, exigences floues, motivations incertaines, errements politiques, etc.), ce qui est après tout un excellent retour d’expérience pour rester positif !

Tableau 6.8 — Le CHAOS et la gestion de la configuration.

Réponse de ce chapitre aux facteurs de réussite du projet

Paradoxalement la Gestion de la Configuration, thème important de PRINCE2, ne semble pas participer à résoudre les défaillances constatées sur un projet. Ceci s’explique par le fait que souvent, lors de la phase projet, les acteurs se dotent d’outils personnels leur permettant de pallier un manque de Gestion de la Configuration au niveau projet, par exemple par une mémorisation personnelle de ce qu’ils utilisent et réalisent.

D’autre part, la Structure de Décomposition du Produit, vu dans le thème Plan, sert souvent de base de configuration simplifiée en ce qu’elle met en relation les produits en montrant leurs dépendances. Dans tous les cas, passer en phase opérationnelle sans s’être doté de cet outil ne fait que reculer le travail de réalisation de celui-ci pendant cette phase opérationnelle de support et maintenance.

THÈME : RISQUE

Toute activité comporte un risque, ne serait-ce que celui d’aboutir ; comme dans le texte de la chanson « L’enfance » chantée par Jacques Brel, on trouve : « Mon père était un chercheur d’or, l’ennui c’est qu’il en a trouvé ».

Un risque c’est un événement incertain qui, s’il se produit, impact le projet. Cet impact peut être néfaste, on parle alors de menace, ou bénéfique, il s’agit alors d’une opportunité.

• Le Risque une Incidence probable anticipée.

Identifier des risques, c’est anticiper et ne pas se laisser surprendre lors de leur survenance, mais aussi tenter de réduire l’impact de ces incertitudes sur le projet en apportant des réponses adaptées. C’est se préparer tant il est vrai que cette préparation amplifiera la capacité du projet à absorber les risques. Ce n’est pas pour rien que les pilotes ou les pompiers s’entraînent à gérer des situations qu’ils ne rencontreront peut-être jamais : pour paraphraser Louis de Broglie : « La gestion des risques est la condition de tous les succès ».

Il y a un risque à ne pas, à trop ou à mal gérer les risques, c’est de ne plus rien faire par crainte d’échouer ou à l’inverse, d’attendre d’une main divine la solution à tous nos problèmes. La perception du risque peut être faussée par des facteurs subjectifs, propres à chaque être humain, ou même par des facteurs culturels ou conjoncturels.

La Gestion des Risques

La Gestion des Risques est liée trop souvent à la personnalité du Chef de Projet qui, par excès de prudence, sclérose le projet, ou par excès d’optimisme lui fait prendre des risques, y compris à l’organisation.

Une gestion des risques efficace permet de répondre au I er principe, la Justification Continue du projet pour l’entreprise.

La gestion des risques commence par l’identification des risques, première phase recommandée par PRINCE2 dans un schéma qui contient cinq phases.

Figure 6.23 – Les 5 phases de la gestion des risques.

Identifier

C’est déjà identifier le contexte, c’est-à-dire comprendre les objectifs qui sont à risque et d’en déduire une Stratégie de Risque pour ce projet. C’est également identifier les risques, c’est-à-dire identifier les menaces et opportunités pouvant impacter le projet. Pour être sémantiquement correct, ce n’est pas les risques qui vont être en premier identifiés mais les menaces ou opportunités dans un premier temps.

Il ne s’agit d’ailleurs pas d’identifier seulement les menaces et les opportunités mais également et tout d’abord d’identifier les produits et les vulnérabilités de ces produits sur lesquels vont porter les menaces et opportunités. A chaque risque, il est nécessaire d’apporter une réponse formelle.

Pour identifier les risques encore faut-il être clair sur la définition du risque qui doit prendre la forme suivante :

Figure 6.24 — L’identification des risques et des réponses.

• La Cause du risque est l’origine du risque qu’il va falloir surveiller de façon proactive.
• L’Evénement du risque décrit la zone d’incertitude, c’est en fait le risque luimême.
• L’Effet du risque est l’impact que le risque pourrait produire (fig. 6.25).

Figure 6.25 — La cause, l’évènement et l’effet du risque.

Décrire le risque suivant ces trois aspects permet de ne pas confondre le risque en lui-même et sa cause : un projet n’a jamais attrapé la grippe, en général ce sont les acteurs du projet qui risquent d’être malades et font prendre du retard au projet s’ils doivent s’arrêter.

Afin d’essayer d’être exhaustif dans la recherche des risques pouvant impacter le projet, il est intéressant de disposer d’une liste des risques possibles, comme indiqué dans le schéma ci-après.

Figure 6.26 — La catégorisation des risques.

Les risques externes au projet

Stratégique :

• Aucune stratégie ou non-conformité à la stratégie
• Retard de livraison du projet
• Partenariat mal défini
• Communication externe défaillante Impact du projet trop important

Législatif et réglementaire :

• Solution non conforme à la législation
• Solution non conforme à la réglementation

Politique :

• Défaut de politique ou de leadership
• Incohérence des objectifs des différentes parties prenantes
• Instabilité des exigences des utilisateurs

Les risques internes au projet

Technique :

• Instabilité des technologies utilisées
• Défaut de maîtrise des technologies
• Exploitabilité inconnue ou dégradée
• Solution difficile à déployer en production

Méthodologie

• Méthodologie mal adaptée au contexte du projet
• Méthodologie partiellement ou totalement inappliquée
• Trop de méthodologies

Humain

• Présence de personnes irremplaçables ou incontournables
• Conflits entre les personnes, problèmes personnels
• Ressources peu ou pas disponibles (compétence, quantité, charge, maturité)
• Formation ou expérience insuffisante

Financier

• Capacité financière du sponsor insuffisante
• Plan de trésorerie inadapté
• Impact d’un retard de livraison sur le ROI
• Pénalités de retard trop importantes

Juridique et contractuel

• Devoir et obligations non tenus du projet vis-à-vis de tiers
• Devoir et obligations non tenus de tiers vis-à-vis du projet
• Obligation de conseil absente

Organisationnel

• Parties prenantes non exhaustives
• Parties prenantes non impliquées
• Flou organisationnel, défaut de responsabilité
• Manque d’arbitrage sur les changements et autres dérogations
• Mise en place de circuits de responsabilité non officiels
• Processus et procédures non respectées

Qualité

• Mauvaise compréhension des exigences
• Test ou intégration incomplet
• Mauvaise gestion des exigences explicites : spécifications insuffisantes
• Mauvaise gestion des exigences implicites : non-maîtrise du métier, de la réglementation…
• Spécifications et solution technique non alignées
• Exigences non vérifiables ou non acceptables

Communication

• Développement de rumeurs autour du projet
• Ressources réticentes à s’impliquer
• Mauvaise communication interne au projet
• Mauvaise communication externe

Apprécier

Après avoir identifié les risques, il s’agit maintenant d’apprécier chaque risque en estimant son impact et sa probabilité, ainsi que sa proximité.

L’Impact est le résultat d’un risque s’il se produit, la Probabilité est l’évaluation du caractère incertain d’un événement ; quant à la Proximité, c’est le facteur temps, la date estimée à laquelle le risque pourrait survenir. Le produit de la probabilité par l’impact (matérialisé à l’aide d’une unité commune : Euros, jours) est souvent appelé Criticité du risque.

Il est nécessaire de consolider toutes ces informations sur les risques en faisant leur Evaluation, c’est-à-dire en cumulant l’ensemble des risques estimés et en donnant une « gravité globale » au projet. Ceci peut être fait par cumul des criticités, soit en créant un schéma représentatif de la dispersion des risques, soit en utilisant un outil commun spécifique à l’organisation permettant de pondérer les risques et d’en déduire si le projet peut être initialisé ou arrêté (un simple tableur permet d’obtenir un outil parfaitement performant).

Le classement dans une matrice des risques de tous les risques identifiés permet non seulement de visualiser les risques inacceptables, mais aussi de déterminer l’exposition au risque par agrégation des points représentant chaque risque. On en déduit, par exemple, si le projet est très exposé à de nombreux petits risques de faible probabilité ou à quelque risque à impact fort qu’il faudra maîtriser.

Dans la figure suivante, qui représente une matrice de risque, la ligne de « Tolérance aux risques » ou « Profil de Risque » indique qu’il faut remédier au risque N^O4, par exemple en réduisant sa probabilité et/ou son impact, et être vigilant sur les risques situés en milieu de tableau. Cette vigilance est la raison d’être du Surveillant de risque.

Un diagramme de Pareto, permet également de trouver les causes à traiter en priorité, en visualisant ce qui est à l’origine des risques ; voici un exemple repris du tableau du rapport CHAOS.

Figure 6.27 — Matrice de risque et tolérance aux risques.

Figure 6.28 — Exemple de diagramme de Pareto.

Ce schéma n’est pas le plus significatif, car en général, il existe un très petit nombre de causes de risque qui génère la majorité des risques, comme les problèmes réseau redondants ou d’explorateurs dans les années 1990 dans le secteur du traitement informatique, ou les retards de livraison des composants dans le secteur du bâtiment.

Une étude de ce type, bien que simpliste en apparence, ne doit pas être négligée car elle permet de supprimer un grand nombre de risque simultanément par application d’une réponse parfois simple : un changement de fournisseur, une technologie plus pérenne, des zones de stockage tampon, etc.

Planifier

C’est essentiellement déterminer les réponses aux risques, que ces réponses soient proactives ou réactives ou même consistent à ne rien faire.

La Réponse au risque doit être proportionnée aux risques. Inutile de passer du temps et de l’argent dans la recherche d’une réponse aux risques de faible probabilité, de faible impact ou tout simplement de faible criticité.

Il est heureusement peu probable qu’un avion de ligne s’écrase sur l’immeuble qui héberge l’équipe projet. Ce type de risque devrait être pris en compte par l’organisation plus que par le projet. Inutile donc de fantasmer sur ce qui n’arrivera jamais (si cela arrivait, de toute façon, la préoccupation première ne serait pas de sauver le projet).

Il est souvent plus intéressant de réfléchir aux réponses globales qui sont en définitive peu nombreuses, qu’à tenter d’évaluer tous les risques. Cela se résume en o des moyens humains, techniques ou financiers supplémentaires, permettant de pallier toute une série de risques communs (technique, financier, humain, etc.).

En général, il n’est pas de bon ton de prévoir de façon formelle et communiquée certains risques, notamment ceux liés à des failles possibles dans l’organisation, à des comportements humains hasardeux ou à des défauts de communication toujours possible. Mieux vaut passer sous silence certains risques de défaillances d’autrui ou de l’organisation identifiée, tout en prévoyant « large » au niveau des moyens ou ressources afin de pallier ces inconvénients.

Le tableau suivant présente les différents types de réponse aux menaces et aux opportunités :

Tableau 6.9 — Les types de réponses aux risques.

L’exemple simplifié suivant permet d’illustrer chaque type de réponse.

Lors d’un projet de construction d’un tronçon d’autoroute, le sol est peut-être marécageux et le projet risque d’être non viable.

Je décide de :

Ne pas construire	Éviter
Construire sur une zone réputée non marécageuse	Réduire (la probabilité)
Changer le tracé si une zone marécageuse est rencontrée	Repli (plan B)
Souscrire une police d’assurance ou transférer le surcoût aux fournisseurs	Transférer
Partager avec les fournisseurs le coût des travaux supplémentaires si nécessaire	Partager
Ne rien faire (on verra bien…)	Accepter

Attention, le fait de construire sur une zone RÉPUTÉE non marécageuse ne Ln supprime pas le risque (réponse = éviter), mais ne fait que diminuer la probabilité (réponse = réduire).

A l’inverse, j’avais prévu que la zone serait marécageuse, mais elle ne l’est pas :

Je décide de :

Augmenter le retour sur investissement du projet	Exploiter
Faire des sondages par anticipation et d’optimiser le parcours	Améliorer
Faire profiter les fournisseurs et le projet de cette aubaine	Partager
Ne rien faire car les travaux sont déjà planifiés	Rejeter

Nota : concernant la réponse « Améliorer », on cherche ici à amplifier la probabilité de trouver un sol non marécageux sur tout le parcours.

Eviter correspond presque toujours à ne pas faire quelque chose, sinon à arrêter tout ou partie du projet. Par exemple, il est plus difficile de couvrir un bâtiment en cas d’intempérie, je décide donc de ne réaliser le travail de couverture qu’à la « belle saison » ,

Réduire, c’est agir sur la probabilité ou sur l’impact. Dans ce cas, il faut évaluer le risque résiduel ou de nouveaux risques (risque secondaire) apparaissant du fait de la mise en place d’une réponse (certaines personnes sont allergiques aux vaccins, détourner le tracé d’une autoroute peut provoquer des protestations, etc.). C’est la réponse la plus adoptée, mais elle introduit des risques résiduels ou secondaires qu’il faut également juguler.

Le Repli est équivalent à un « plan B qui ne sera appliqué que si l’événement du risque est avéré, par exemple, aller acheter des bâches pour couvrir la charpente si la pluie menace, acquérir un éradicateur de virus en cas d’attaque virale informatique.

Transférer correspond à faire assumer par une tierce partie l’impact financier (exemple une assurance), mais il peut s’agir pour une organisation de transférer une prestation de façon à ce que ce soit le fournisseur qui prenne les risques à sa charge, étant entendu que le prix de la prestation en sera certainement affecté. Ce fournisseur de par ses moyens et ressources est dans ce cas sans doute mieux à même d’absorber les risques en question. Par exemple, un couvreur sait comment procéder en cas d’intempérie, les professionnels de l’informatique ont des structures dédiées à la sécurité des informations.

Partager, c’est avoir contracté avec ses fournisseurs de façon à ce que les coÛts de certains risques, souvent techniques, soient partagés entre les contractants, par exemple sous forme de joint venture particulière.

Accepter, c’est ne rien faire, non pas par négligence mais simplement par constat d’impuissance devant le type de risque ou parce que le coût de la réponse est hors de proportion avec l’impact du risque, ou parce que l’on en peut déterminer ni l’impact, ni la probabilité. Par exemple : un flux de rayons Gamma interstellaire, l’arrêt maladie d’un collaborateur non encore identifié, etc.

Exploiter une opportunité consiste à profiter de ce que cette opportunité apportera au projet (une amélioration technologique, une équipe dynamique et motivée, une o baisse de tarif ou de taux de change).

Améliorer revient à essayer d’amplifier la probabilité qu’une opportunité identifiée survienne ou d’amplifier son impact. Adopter des solutions éprouvées de façon à ce que la charge correction suite à un défaut soit quasiment nulle, former les intervenants aux techniques spécialistes du projet et en faire profiter les autres projets, par exemple.

Rejeter une opportunité équivaut à ne pas profiter de ce que cette opportunité peut apporter au projet. Ceci pour des raisons techniques, économiques, de standardisation, politique, marketing, etc. Par exemple, bien que sur un projet, telle nouvelle technologie permettrait de faciliter la réalisation, cette technologie est rejetée car elle n’est pas conforme aux standards de l’entreprise ; ou je décide d’inventer un nouveau type de connecteur afin de rendre mon produit incompatible avec les autres produits du marché.

Exécuter

Cette phase « exécuter » est la phase opérationnelle, elle consiste à veiller à ce que les risques ne surviennent pas ou que l’impact soit maîtrisé en cas de survenance. Ceci est le rôle du Surveillant du Risque, qui est responsable de la gestion du risque, notamment la surveillance de l’occurrence, mais aussi la mise en oeuvre des réponses qui seront exécutées par l’Exécuteur du Risque.

Le Surveillant et l’Exécuteur peuvent être la même personne, il faut seulement éviter qu’une seule et même personne ait la charge de gérer tous les risques du projet.

Le Surveillant du Risque est aussi appelé parfois Pilote du risque ou Responsable du risque, il lui faut notamment vérifier les Précurseurs du risque, c’est-à-dire les facteurs annonciateurs de l’occurrence de l’événement du risque.

Ces deux acteurs sont identifiés formellement pour chaque risque dans le Registre des Risques.

La mise en œuvre des réponses, objet de cette phase Exécuter, peut être faite par anticipation à la survenance d’un risque, par exemple si l’on veut réduire la probabilité ou l’impact du risque pour qu’ils soient rendus acceptables par la direction, ou a posteriori notamment dans le cas du repli.

Communiquer

Communiquer est une activité transverse à toutes les activités de la gestion des risques. Cette communication est nécessaire pour s’assurer que tous les acteurs du projet sont sensibles à la gestion des risques, notamment à remonter tous les risques apparaissant en cours de projet.

A part le Rapport d’Etat du Produit, tous les rapports permettent de communiquer sur les risques. Il faut noter également que les Rapports d’Incidence et d’Exception peuvent ne pas faire référence à un risque (avéré ou non) qui en serait l’origine. Une Incidence n’est jamais qu’un risque avéré qui n’a pas été anticipé (pas toujours).

Le Budget de Risque

A l’instar du Budget de Changement, le Budget de Risque est un budget incorporé au budget du projet mais uniquement utilisable pour financer les réponses aux risques. Ce budget n’est pas totalement à dépenser et il ressemble plus en cela à une provision pour risque au niveau comptable qu’à un budget. Il est constitué d’une partie budget, ce qu’il est déjà prévu de financer comme réponse, et une partie provision pour ce qui n’est pas encore connu lors de sa détermination.

Financer les réponses aux risques, c’est par exemple financer une police d’assurance, un antivirus informatique, la recherche de fournisseurs en secours, des bâches de protection, un audit technique, le surcoût du transfert de réalisation à un fournisseur, etc. Ce budget ne peut être infini, il ne sert pas à financer les dommages liés à l’impact du risque. Ces dommages sont souvent assurés à un autre niveau, par exemple comptabiliser une provision financière globale pour tous les projets d’une organisation et ne rien faire au niveau du projet (il s’agit alors de prévoir le financement d’une réponse globale mais pas au niveau du projet).

Le calcul de ce budget revient souvent à appliquer les us et coutumes de l’organisation en termes de calcul de risque. Usuellement, les sociétés affectent un pourcentage du budget total aux risques (exemple : 5 %), éventuellement en fonction d’abaques, fruits du retour d’expérience de la société, pour le type de projet en question. Une autre méthode simple est de faire la somme de toutes les gravités de tous les risques identifiés (appelée « technique de valeur attendue ») et d’ajouter une provision pour les risques non identifiés.

Quant à utiliser une méthode probabiliste de type Monte-Carlo (c’est-à-dire en utilisant des méthodes de détermination aléatoire), mieux vaut y réfléchir à deux fois et considérer que le nombre de risque est suffisamment faible pour que les résultats soient complètement aléatoires, sinon on peut se demander si un tel nombre de risques (probabilité rime avec grand nombre) ne remet pas en cause le projet en lui-même.

Retour d’expérience

• Peu importe de calculer l’impact et la probabilité de façon exacte, ce qui importe surtout, c’est d’identifier le maximum de risques tangibles et de nommer un Surveillant pour chaque risque. Le même Surveillant peut assumer la charge de plusieurs risques.
• Il est possible de procéder de façon complètement opposée, c’est-à-dire d’identifier toutes les réponses aux risques dont on peut disposer sur le projet (ou dans l’organisation) et de chercher à quels risques ces réponses pourraient répondre. En effet, le nombre de risque est important alors que les moyens en contre-mesure sont limités : cela permet d’avancer beaucoup plus rapidement, notamment en classant les risques en fonction de leurs réponses.
• Il est tentant d’assimiler un risque avéré à une incidence non encore survenue. Les deux facteurs discriminants sont que le risque est identifié au départ, ce qui n’est pas le cas d’une incidence et de ce fait, une réponse est déjà planifiée, et qu’une incidence peut être déclarée alors qu’elle n’est pas encore apparue. La différence est que l’événement incidence est certain à la différence du risque qui conserve un certain degré d’incertitude (probabilité < 100 %) quand il est déclaré. Par exemple, si un membre de l’équipe technique tombe malade, cela peut être une incidence de type problème ou souci, sauf s’il a été prévu qu’un membre de l’équipe technique tombe malade et qu’une réponse appropriée a été décidée. Dans le cas de l’incidence, après vérification de l’impact, il faut éventuellement trouver à le remplacer, dans le cas du risque avéré, la réponse choisie était peut-être de prévoir plus de temps pour la réalisation du produit impacté.
• Pour ce qui est des risques résiduels et des risques secondaires la réponse choisie est finalement d’accepter ces risques. Lorsqu’ils sont avérés, cela revient à traiter une incidence.
• Ne pas perdre de temps à identifier des risques indétectables, improbables ou sans impact.
• Reprendre à son compte la phrase de Frédéric le Grand : « On vous pardonnera toujours d’avoir été battu, jamais d’avoir été surpris ». La charge du Chef de Projet a beau être découpée en quatre phases consécutives de la Planification au Contrôle, ce n’est pas un processus linéaire et le Chef de Projet doit être en permanence vigilant et anticiper les événements.
• La gestion des risques est dynamique. Chaque risque n’a pas la même importance tout au long de la vie du projet, des risques vont disparaître ou auront un impact moindre, d’autre apparaître ou devront être surveillés très attentivement ; la proximité des risques évolue également (la grippe s’attrape plutôt en hiver qu’en plein été par exemple).
• S’il n’est pas possible d’évaluer un budget de risque, estimer une provision pour risque (par exemple de 5 % du budget total du projet). Cela vaut toujours mieux que de redemander une rallonge budgétaire à chaque incidence qui aurait pu être anticipée (et qui ne rentre pas dans les tolérances).
• S’il n’est pas possible d’obtenir un budget pour les risques, les identifier et anticiper les réponses est toutefois indispensable.
• Rester proche des équipes techniques, c’est de là que surgiront les nouveaux risques identifiés, et à l’écoute des autres projets en cours qui rencontrent peut-être les difficultés futures du projet.
• Anticiper, anticiper, anticiper : c’est dans la précipitation que sont prises les décisions les plus catastrophiques (voir les comptes rendus de catastrophes aériennes pour s’en convaincre).
• Attention de ne pas devenir psychopathe (Sir Winston Churchill disait) « Un pessimiste voit la difficulté dans chaque opportunité, un optimiste voit l’opportunité dans chaque difficulté, » et, « Le pire n’est jamais certain. »

Tableau 6.9 — Le CHAOS et la gestion des risques.

Réponse de ce chapitre aux facteurs de réussite du projet

Paradoxalement, si le thème de la gestion des risques semble peu contribuer aux facteurs de réussite du projet, il peut a contrario être utilisé pleinement pour gérer les facteurs d’échec, simplement en identifiant chaque facteur comme un risque et en déterminant quelles pourraient être :

• Les menaces ou opportunités,
• Les ressources ou produits impactés,
• Les vulnérabilités,
• Les contre-mesures.

Tant il est vrai que se poser la bonne question au bon moment, c’est déjà résoudre une partie des problèmes actuels ou futurs. Et globalement est-ce que la réponse n’est pas dans l’utilisation de la méthode PRINCE2 ? D’où le point d’interrogation dans toutes les cellules du tableau 6.6.

PROCESSUS : INITIALISER UN PROJET

Cette étape ne doit pas être négligée car elle conditionne le projet non seulement dans ses réalisations techniques, mais surtout et de façon essentielle dans les relations entre parties prenantes du projet. Elle doit avoir comme objectif de rassurer les acteurs quant à la maîtrise du projet par le Chef de Projet.

Il faut que chacun des acteurs à la fin de cette phase sache :

• Quelle méthode de management sera utilisée,
• Quelles seront les « redevabilités »,
• Qui sera impliqué dans le projet,
• Quel en est le calendrier,
• Ce que l’on attend du projet,
• Quels sont les risques principaux,
• Comment sera contrôlé le projet,
• Comment sera assurée la communication dans et en dehors du projet.

Le processus Initialiser le Projet est déclenché par l’autorisation d’initialiser le projet donné par le Comité de Pilotage de Projet.

Figure 6.29 — Les processus déployés à l’initialisation du projet.

En fin de processus, le Document d’lnitialisation de Projet accompagné du Plan de Projet est envoyé au Comité de Pilotage de Projet en vue de sa validation et de l’autorisation de lancement du projet. Le Comité de Pilotage de Projet a également besoin du plan de première séquence pour prendre sa décision, sachant que ce Plan de Séquence est produit par le processus Gérer une Limite de séquence qui est détaillé au chapitre consacré à ce processus.

Les activités du Processus

Les huit activités du processus Initialiser le Projet permettent de poser les fondations du projet.

Figure 6.30 — Les activités du processus Élaborer un projet.

La source des stratégies est souvent constituée des normes et standards de l’organisation, entreprise et/ou programme, qui devraient avoir été recueillies dans le Journal des Retours d’Expérience au moins en référence. Il est fort probable que ces stratégies aient déjà été préparées pour d’autres projets et que le seul travail du Chef de Projet soit de faire référence à des stratégies communes à tous les projets de cette organisation, en les complétant avec les spécificités du projet. Inutile donc de « réinventer la poudre » il s’agit là d’un excellent exemple de retour d’expérience.

Ces stratégies vont permettre de mettre en place les Contrôles du Projet qu’elles décrivent pour ce qui en est connu à cette phase du projet. La mise en place de ces contrôles conduit au Plan de Projet, et réciproquement, car les deux activités se complètent et doivent être menées en parallèle.

Il faut noter que même si ces quatre stratégies sont créées lors du processus Initialiser le projet, elles sont susceptibles d’être revues au cours du projet en fonction des incidences, changements ou tout autre événement amenant à reconsidérer ces stratégies. Comme elles constituent un référentiel validé par le Comité de Pilotage de Projet, toute modification est à lui soumettre pour approbation.

Préparer la stratégie des risques

La préparation de la Stratégie des Risques vise à définir les objectifs de la gestion des risques ainsi que ces différents composants, à savoir :

• La procédure adoptée,
• Les rôles et responsabilités,
• Les tolérances au niveau du projet,
• Les outils et techniques utilisées,
• Un calendrier des activités de gestion des risques.

Pour ce faire, le Chef de Projet prend en compte toutes les données recueillies précédemment dans son Journal de Projet, dans celui des Retours d’Expérience et dans l’Exposé de projet. Il définit la procédure de Gestion des Risques en prenant exemple sur la procédure décrite dans le chapitre Gestion des Risques (identifier, estimer, planifier, exécuter, communiquer).

Le Chef de Projet définit également les outils, techniques, enregistrements à conserver, rôles et responsabilités, barèmes d’évaluation des risques et de proximité, les précurseurs, les catégories, les tolérances au niveau projet et le calendrier des activités de gestion des risques. Bref, tout ce qui peut lui être utile pour gérer les risques.

Les précurseurs sont des événements qui permettent d’anticiper sur la survenue d’un risque ; par exemple, chaque année la grippe se déplaçant d’est en ouest de la planète, le fait qu’un nouveau virus apparaisse en Asie permet de récupérer les souches nécessaires à la création du vaccin de l’année. Ces précurseurs doivent être reconnus lors de cette phase, sachant qu’ils devront être actualisés chaque fois qu’un nouveau risque sera pris en compte ou évoluera.

Il est nécessaire que l’Assurance Projet connaisse cette stratégie et qu’elle puisse o vérifier qu’elle correspond aux exigences tant du Comité de Pilotage de Projet que de la Direction de l’Entreprise ou du Programme.

Le Chef de Projet aidé éventuellement par son Support Projet va créer le Registre des Risques et le compléter avec les risques déjà identifiés et consignés dans l’ébauche du Cas d’Affaire (risques principaux) et dans le Journal du Projet.

Enfin, c’est lors de l’initialisation qu’est également estimé le Budget de Risque et définit la manière dont il va être contrôlé (voir le Thème Risque).

Au sortir de cette activité, la Stratégie des Risques et le Registre des Risques auront été créés, ainsi que le Budget de Risque s’il est estimé nécessaire.

Préparer la stratégie qualité

La Stratégie Qualité (diminutif de la stratégie de gestion de la qualité) a pour objet essentiel d’assurer que les exigences de l’utilisateur sont clairement formulées, rigoureusement collectées, correctement retranscrites et que les Critères d’Acceptation peuvent être définis en fonction de ces exigences et validés par l’utilisateur, afin que nulle ambiguïté ne subsiste. Ceci est une des conditions essentielles à la réussite d’un projet.

Comme pour toutes les autres stratégies, le Chef de Projet prend en compte l’ensemble des informations en sa possession pour définir les outils, techniques, enregistrements à conserver, rôles et responsabilités et le calendrier des activités de Management de la Qualité.

Cette stratégie doit être approuvée par le Comité de Pilotage de Projet.

Le Chef de Projet, aidé par son éventuel Support Projet, va créer le Registre Qualité qu’ils actualiseront au fur et à mesure de l’avancement du projet avec les détails des activités de contrôle de la qualité.

Au sortir de cette activité, la Stratégie Qualité et le Registre Qualité ont été créés. Même s’il n’y a pas de budget de changement, les activités de gestion de la qualité doivent être quantifiées et prises en compte dans le budget du projet et a fortiori dans tous les plans qui reprennent ces activités et donc ces budgets.

Nota : A la différence de la Stratégie des Risques, les tolérances liées à la qualité ne sont pas définies dans la stratégie mais dans les Descriptions de Produit, tant il est vrai que la qualité à ce niveau pourrait se traduire par une définition des caractéristiques du produit et non des processus mis en œuvre. Ce qui répond au 6e principe de PRINCE2 : Focalisation sur le produit.

Préparer la Stratégie de Configuration

Le but de cette stratégie est de définir les modalités permettant au projet de conserver la maîtrise de ses produits, qu’ils soient de management ou spécialistes.

La Stratégie de Configuration, de par son objet, inclut également la Maîtrise des Changements et la Gestion des Incidences, qui par définition, impactent les éléments de configuration.

o Il est fort probable que le projet ne soit ni le premier, ni le seul à gérer ses configurations, et que l’organisme se soit déjà doté d’outils et de procédures de gestion des configurations. Dans ce cas, il ne s’agira pas de définir la gestion de configuration, mais de définir les Enregistrements de Configuration et peupler l’outil qui aura été construit ou acheté et paramétré au préalable.

Comme pour les autres stratégies, le Chef de Projet prend en compte l’ensemble des informations en sa possession pour définir les outils, les techniques, les enregistrements à conserver, les rôles et responsabilités, le calendrier des activités de gestion de la configuration. Il définit de façon plus particulière la procédure de gestion des configurations en prenant exemple sur celle que propose PRINCE2 (Planifier, identifier, contrôler, gérer l’état, vérifier et auditer).

Le Chef de Projet, aidé éventuellement par son Support Projet, va créer le Registre des Incidences et le compléter avec les incidences déjà identifiées et consignées dans le Journal du Projet et que le Chef de Projet veut consigner de façon formelle. Il va également créer les Enregistrements de Configuration initiaux, ceux pour lesquels les produits ont déjà été définis, par exemple : les Produits de Management, le Produit de Projet et les Produits spécialistes déjà décrits.

Enfin, le Chef de Projet doit compléter la structure et les rôles de l’équipe projet s’il apparaît qu’une Autorité de Changement est nécessaire au projet, ceci bien entendu en accord avec le Comité de Pilotage de Projet qui est l’ultime responsable de l’acceptation des demandes de changement.

De la même façon que pour les risques, accorder un Budget de Changement peut être nécessaire. Dans ce cas, les modalités d’utilisation de ce budget doivent être précisées. Il faut également préciser qui sera en charge de l’Autorité de Changement pour un type de changement en particulier et donc en charge d’un budget correspondant à cette autorité (voir chapitre Organisation).

Le Chef de Projet doit s’assurer auprès de l’Assurance Projet que cette stratégie est conforme à ce qui est recherché tant par le Comité de Pilotage de Projet que par la Direction de l’Entreprise ou du Programme.

Préparer la Stratégie de Communication

Les quatre stratégies peuvent être menées en parallèle, mais il est recommandé de terminer par la Stratégie de Communication qui synthétise les besoins en communication des autres stratégies.

Quelle soit interne ou externe au projet et à l’organisation, la communication doit être planifiée entre toutes les parties prenantes, y compris par le niveau Direction de l’Entreprise ou du Programme.

Le travail essentiel réalisé lors de cette activité est d’identifier les besoins en information des parties prenantes. Ceci passe par une analyse des parties prenantes de façon à connaître, outre leurs besoins, quelle est la meilleure façon de communiquer avec chacune d’entre elles.

Communiquer n’est pas qu’émettre, il faut s’assurer de la réception du message et de sa compréhension afin d’être certain tout au long du projet que les messages o sont compris pour ce qu’ils veulent délivrer. Les projets achoppent souvent non pas par un manque de communication, quoique cela soit aussi souvent le cas, mais par Ln une incompréhension des messages entre les parties prenantes. Plus les lignes de communication s’allongent (géographiquement, hiérarchiquement, culturellement, etc.) et plus il est nécessaire de travailler le volet communication du projet, il en est de même pour le nombre d’interlocuteurs.

On peut noter qu’autant les autres stratégies peuvent provenir de standards de l’organisation, autant la Stratégie de Communication est spécifique au projet car les acteurs ne sont pas les mêmes.

Comme pour les autres Stratégies, le Chef de Projet prend en compte l’ensemble des informations en sa possession pour définir la procédure de gestion de la communication, les outils, les techniques, les enregistrements à conserver, les rôles et les responsabilités, le calendrier des activités de gestion de la communication ainsi que l’analyse des parties prenantes en termes de communication.

Mettre en place les contrôles du projet

Mettre en place les contrôles du projet consiste à définir les différents contrôles, en adéquation avec ce que le Comité de Pilotage de Projet souhaite instaurer pour s’assurer du succès du projet.

Il s’agit non seulement de définir ces contrôles mais de les situer dans le temps du projet et de décrire à la fois les mécanismes de contrôle mais également les rôles des acteurs.

Pour ce faire, le Chef de Projet va prendre en compte tout ce qu’il a pu récupérer comme informations, tant au niveau des Retours d’Expérience que ce qu’il a retranscrit dans les documents issus des stratégies.

Les besoins de contrôle du projet dépendent de sa taille, de son importance et des risques encourus, de sa complexité et de la confiance en l’équipe. En cela, ces besoins de contrôle vont influencer le découpage du projet en séquences. La fréquence désirée des contrôles conditionne la taille des séquences de management.

Le Chef de Projet va prendre en compte toutes les communications déjà définies entre tous les niveaux de management du projet (fréquence, format, média, contenu), la communication de fin de séquence. Il doit également définir les modalités de suivi et les procédures décisionnelles de tous les niveaux d’autorité vis-à-vis des autres parties prenantes.

Ces contrôles contiennent également les procédures de remontée des incidences, des changements et des Exceptions afin que soient déterminées précisément les « redevabilités » de chacun lors du contrôle.

L’Assurance Projet vérifiera que le résultat est conforme aux attentes du Comité de Pilotage de Projet.

Ces Contrôles de Projet en grande partie déjà définis dans les stratégies, font l’objet d’un chapitre de la Documentation d’initialisation de Projet.

Les deux activités Mettre en place les contrôles du projet et Créer le Plan de Projet doivent être menées en parallèle car elles produisent des éléments nécessaires o communs et fonctionnent de façon itérative.

Créer le Plan de Projet

Pour que le Comité de Pilotage de Projet puisse accepter le lancement des travaux nécessaires à la réalisation, le Chef de Projet doit lui fournir un Plan de Projet en collaboration étroite avec les parties prenantes concernées interne et externe.

Attention, il ne s’agit pas simplement de fournir un calendrier de ces activités, mais de regrouper ou de créer l’ensemble des informations et outils pour la planification des activités nécessaires au projet, notamment.

• La Structure de Décomposition du Produit de projet,
• Le Diagramme de Flux des Produits principaux,
• Les Descriptions de Produits principaux,
• Les Dépendances Externes,
• Les Tolérances de niveau projet (Coût, délai, périmètre),
• Les échéances liées aux Contrôles du Projet,
• Les méthodes d’estimation,
• Les outils de planification et de contrôle,
• Les modalités de livraison dans un environnement opérationnel,
• Les accords ou contrats de maintenance (sous forme de produit).

Le Chef de Projet doit également identifier les ressources requises et confirmer la disponibilité et l’acceptation des personnes retenues.

Le Support Projet créé ou met à jour les Enregistrements de Configuration de chaque produit contenu au niveau du Plan de Projet, ainsi qu’il le fera pour tous les produits définis pour chaque séquence.

Le Plan de Projet doit non seulement couvrir les activités nécessaires à la réalisation des produits mais également celles pour la gestion du projet.

Cette activité couvre également la détermination du budget du projet à partir des éléments connus et déjà consignés dans le Cas d’Affaire notamment.

Affiner le Cas d’Affaire

Le Chef de Projet peut affiner le Cas d’Affaire maintenant qu’il a obtenu des informations plus précises sur les tâches à réaliser, les différents coÛts après consultation des parties prenantes et validation dans le Plan de Projet et dans les stratégies, notamment celle des risques.

Ce Cas d’Affaire détaillé, et potentiellement évolutif en cas de changement, constitue la base pour le contrôle continu de la viabilité du projet, répondant ainsi au 1 er principe de PRINCE2 : Justification continue pour l’entreprise.

Le Chef de Projet va passer en revue toutes les informations en sa possession afin de mettre à jour le Cas d’Affaire.

C’est lors de cette activité que va être créé le Plan de Revue des Bénéfices.

Ce Plan de Revue des Bénéfices va contenir l’ensemble des activités planifiées afin Ln de vérifier que les bénéfices escomptés et inscrits dans le Cas d’Affaire sont réalisés en cours ou après le projet.

Assembler la Documentation d’initialisation de Projet

La Documentation d’initialisation de Projet est le « contrat » entre le Chef de Projet et le Comité de Pilotage de Projet.

Toutes les informations nécessaires à la gestion du projet doivent y être consignées afin de constituer LE référentiel du projet.

La Documentation d’initialisation de Projet assemblée lors de l’Initialisation du Projet est utilisée pour obtenir l’approbation du Comité de Pilotage de Projet afin de continuer le projet. Mais cette D.I.P., son contenu autrement dit, est susceptible d’évoluer tout au long du projet et sert de référence par rapport à ce qui va être développé.

On parle ici « d’assemblage » car la D.I.P. rassemble divers Produits de Management créés en amont comme l’Approche Projet, les stratégies, le Cas d’Affaire, le Plan de Projet, la Structure et les Rôles de l’équipe projet, les Contrôles du Projet et enfin, l’Adaptation du projet.

Concernant l’adaptation, PRINCE2 ne dédie pas une activité en particulier pour adapter le projet. Cette adaptation est diffuse au sein de la constitution des stratégies mais une partie aura également été réalisée dès l’Elaboration du projet, notamment la production du Plan de Séquence d’initialisation.

Durant l’assemblage, le Chef de Projet aura soin de vérifier que les informations des différents documents ne sont ni incompatibles et ni redondantes. Ceci évitera bien entendu les confusions mais également le surcroît de travail de maintenance de ces documents.

Figure 6.31 – Les Principaux Échanges et Produits de Management du Processus Initialiser le projet.

Retour d’expérience

• Vérifier encore que toutes les parties prenantes sont identifiées.

• Récupérer les Appels d’Offre, les réponses et les divers contrats nécessaires.

• Définir des Critères d’Acceptation indiscutables et exhaustifs.

• Toujours prévoir une provision pour risque et une provision pour les changements de façon formelle et si ce n’est pas possible, de façon informelle.

• Ne créer des Enregistrements de Configuration que s’il est possible de les maintenir à jour, mieux vaut une granularité faible qu’une base non mise à jour.

• La base de données de configuration est essentielle pour vérifier les impacts directs ou indirects des changements et des incidences ; ceci ne peut être accompli que si les éléments de configuration sont en relation les uns avec les autres (relation physique ou virtuelle).

• Formaliser, formaliser, formaliser, attention toutefois à ne pas transformer le projet de réalisation en « projet de documentation » , donc simplifier au maximum et éviter les redondances.

• Communiquer, communiquer, communiquer mais à bon escient, c’est-à-dire en ayant analysé les parties prenantes, leurs besoins et les canaux de communication.

Intermède sur la communication

Après avoir identifié les parties prenantes, encore faut-il communiquer correctement avec elles… C’est un art difficile car il est fait de logique et d’éléments non maîtrisables qui peuvent remettre en question en quelques instants la bonne fin d’un projet.

Bien communiquer, c’est communiquer peu mais à bon escient en maîtrisant à la fois l’information en elle-même mais aussi l’intention liée à la diffusion de cette information. Le bon contenu, Sur le bon média, Au bon interlocuteur, Au bon moment, Et dans le bon langage !

Se rappeler qu’en matière de communication, un interlocuteur assimile

• 10 % de ce qu’il lit,
• 20 % de ce qu’il entend,
• 30 % de ce qu’il voit,
• 50 % de ce qu’il voit et entend,
• 80 % de ce qu’il dit,
• 90 % de ce qu’il dit en le faisant.

Prendre du temps à faire des présentations claires, c’est gagner du temps.

Contrairement aux apparences, il n’y a pas autant de document/Produit de Management à créer que cela pour gérer un projet PRINCE2, notamment s’il est de taille modeste. Les stratégies devront être seulement complétées, car il est fort probable qu’elles soient déjà définies dans un « Plan d’Assurance Qualité » (PAQ) commun à tous les projets de l’entreprise ou du programme, le Cas d’Affaire est vraisemblablement issu d’un appel d’offre ou de la réponse faite à cet appel d’offre, les rôles devraient déjà étre décrits, etc.

La méthode a besoin

• D’informations et pas nécessairement de pléthore de documents,
• De décisions et pas nécessairement de réunions…

L’implication des parties prenantes selon MSP GManagng Successfu/ Programmes) de l’OGC peut être définie en six étapes

Qui ?	Identifier les parties prenantes
Quoi ?	Créer et analyser leur profil
Comment ?	Définir une stratégie d’engagement.
Quand ?	Planifier l’engagement.
Que faire ?	Engager les parties prenantes
Quel résultat ?	Mesurer l’efficience du dispositif.

Positionner les parties prenantes sur une matrice pouvoir / intérêt ou pouvoir / Influence et sur une carte des acteurs permet de schématiser les relations et de déterminer où mener des actions d’amélioration de la communication et éviter d’investir du temps là où cela ne sert à rien (fig. 6.32).

Il existe d’excellentes méthodes de gestion de la communication et de détermination des types psychologiques parmi lesquelles le MBTI (Mye/S Briggs Type Indicator), l’ennéagramme, la PNL (Programmation Neuro Linguistique), l’AT (Analyse Transactionnelle), etc. En connaître au moins une peut être utile en faisant attention de ne pas en abuser car ce sont des outils pernicieux si les intentions des pratiquants ne sont pas louables.

Figure 6.32 — Positionnement et cartes des acteurs (tiré du PMBoK).

Réponse de ce chapitre aux facteurs de réussite du projet

Il n’est pas étonnant que dans cette phase d’initialisation du projet la majorité des facteurs se trouvent concernés et il est intéressant de constater qu’il y aurait à tirer avantage en portant une attention particulière sur le soutien des responsables opérationnels, un jalonnement plus rapproché et l’affectation des équipes à un projet unique.

Tableau 6.10 — Le CHAOS et le processus Initialiser le projet.

En cours de Projet

Objectif

Ce chapitre décrit les activités qui doivent être engagées pour mener le projet à bon port. Cette phase est constituée de trois processus principaux : Contrôler une séquence, Gérer la livraison des produits et Gérer la limite d’une séquence.

« Vous ne sauriez croire avec quelle facilité l’impossible se fait quand il est nécessaire. »

Anatole France

Après le préprojet et son initialisation, le projet va réellement commencer. Le décor est planté, c’est-à-dire que tout est normalement prêt de façon à ce que les o produits puissent être réalisés conformément à ce qui a déjà été décrit, ou ce qui va l’être avant de lancer chaque séquence.

Deux processus ont la charge de mener à bien ces opérations au quotidien, sachant que le processus Diriger le Projet reste omniprésent tout au long de cette phase.

Avant de développer le processus Contrôler une séquence, la présentation du thème Plan et du thème Progression sont indispensables car ces thèmes conditionnent notamment la marche du projet par anticipation (thème Plan) ou par validation (thème Progression).

THÈME : PLAN

Un plan est de façon générale un moyen de communiquer avec les acteurs du projet.

Figure 7.1 Les processus déployés en cours de projet.

Un plan ce n’est pas une série de dates, c’est une construction logique d’informations permettant à celui qui lit ce plan de savoir quels sont les objectifs, quel est le cheminement pour arriver à cet objectif et éventuellement ce que l’on attend de lui. Ce n’est donc pas un simple calendrier où sont inscrits des tâches ou des livrables.

Le plan structure le projet au sens où il permet de définir les objectifs du projet et les attendus des acteurs. Le plan est parfois la seule vision documentée partagée par tous d’un projet, il se doit donc d’être compréhensible et accessible à tous.

Un plan, si précis et judicieux soit-il, n’est qu’un canevas de référence à des activités qui va sans cesse évoluer tout au long du projet pour prendre en compte les aléas toujours possibles. C’est une référence mouvante à laquelle doivent pouvoir se o rattacher aussi bien les fournisseurs que tous les autres acteurs du projet.

Un plan n’est qu’une vue de l’esprit, une projection, celle du Chef de Projet qui élabore le plan qui n’est au début du projet qu’une représentation formalisée plus ou moins fondée de l’avenir. Au cours du projet, c’est aussi le moyen de visualiser facilement les progrès accomplis par rapport à la réalité, si le Plan est résumé sur un diagramme temporel, comme s’est souvent le cas.

Un plan doit :

• Être le reflet du Cas d’Affaire,
• Fournir des estimations de qualité,
• Fournir des prédictions de qualité,
• Permettre de valider la démarche,
• Être « robuste » aux aléas possibles,
• Être économique,
• Être adapté à l’environnement,
• Être simple.

La planification basée sur le produit

PRINCE2 adopte une philosophie de planification basée sur le produit. Ce qui consiste à découper le Produit de Projet en différents produits le constituant, décrire chacun de ces produits puis définir la succession de réalisation de ces produits (voir figure 7.2 Technique de planification basée sur le produit).

Figure 7.2 — Technique de planification basée sur le produit.

PRINCE2 insiste sur l’importance de créer d’abord une liste des produits, alors que trop souvent l’action de planifier consiste pour le Chef de Projet à ouvrir son outil de o planification et commencer à fixer dans le temps des activités.

Si ceci donne une vue pratique sur les actions à mener pour arriver à un résultat, il faut prendre en compte que les clients n’achètent pas des « actions », mais bien des produits, des faits.

C’est pour cela que commencer par faire une liste exhaustive des produits d’un projet est indispensable.

Pour illustrer ceci, prenons un projet qui consisterait à fournir des ceufs sur le plat. Vous commenceriez bien entendu par faire la liste des ingrédients : deux œufs, une cuillère d’huile, sel/poivre, mais aussi une poêle, un réchaud, du gaz ; voici pour la liste des produits.

Les activités de ce projet pourraient être :

• S’assurer que tous les produits sont disponibles,
• Casser les ceufs dans la poêle,
• Ajouter le sel et le poivre,
• Faire chauffer la poêle pendant 5 minutes à feu moyen.

La première des activités dépendrait d’un autre projet consistant à aller acheter les ingrédients, ces produits indispensables à votre projet seront donc des produits externes. Vous pourriez confier la deuxième activité à une tierce personne (votre enfant…)

Nous voyons donc que pour ce projet somme toute assez simple, il est indispensable de commencer par l’identification de tous les constituants avant même d’envisager de commencer la planification.

Les sept étapes essentielles proposées par PRINCE2

Figure 7.3 – Les 7 étapes de la planification.

Concevoir le plan

Choisir les outils et méthodes d’estimation en prenant en compte les besoins en communication des acteurs du projet et les normes en vigueur dans l’organisation.

Définir et analyser les produits

Mettre en œuvre la technique de planification basée sur le produit.

Identifier les activités et les dépendances

Bien que le Diagramme de Flux du Produit reste la référence, lister et organiser les activités peut s’avérer nécessaire ; ce sont ces activités qui permettent de déterminer la charge.

A ce niveau, il est nécessaire de déterminer les dépendances tant internes (qui ne dépendent que du Chef de Projet et de son équipe) mais aussi externes, vis-à-vis des produits qui sont nécessaires au projet mais ne dépendent pas du Chef de Projet, par exemple un produit qui dépend d’un autre projet, que ce produit existe déjà ou non. Les dépendances externes ne sont pas que des produits, cela peut être une décision ou n’importe quel événement qui permettrait de synchroniser les actions (attente d’une décision du Comité de Pilotage de Projet, libération d’une ressource, Approbation d’un produit…).

Préparer les estimations

Estimer un projet, c’est estimer les efforts et identifier les ressources requises dans le cadre du projet. Cela permet de prévoir les charges et ressources nécessaires et par conséquent les coÛts et la durée d’exécution du plan.

Ce n’est pas une science exacte et ces estimations seront revues tout au long du projet pour tenir compte des réalités : retour d’expérience sur les capacités des ressources par exemple.

Divers facteurs influencent l’estimation comme la nouveauté technologique, le contexte politique, les relations dans l’entreprise, la dimension du projet, les facteurs culturels, la proximité géographique, etc.

Préparer l’ordonnancement

Il s’agit de :

• Définir l’ordre des activités en tenant compte des Chemins Critiques (voir Diagramme de PERT en annexe). Cela permet également de visualiser les o activités qui possèdent une marge d’exécution (appelé également Battement),
• Évaluer la disponibilité des ressources, assigner les ressources,
• Niveler l’utilisation des ressources, au cas où les charges seraient mal réparties entre les ressources (recherche des disponibilités),
• Convenir de points de contrôle, nécessaires au Comité de Pilotage de Projet,
• Définir les échéances, qui sont appelées Jalons du projet dans le langage courant ; ce sont des événements importants dans la vie du projet qu’il faut identifier, par exemple, la fin d’un Lot de Travaux, d’une Séquence, etc.
• Calculer le total des besoins en ressources et les coûts, ce qui permet de produire le budget du plan (y compris les budgets de risque et de changements s’ils existent),
• Présenter le calendrier, de façon graphique si possible et avec plusieurs niveaux de détail de façon à ce qu’il reste lisible.

Documenter le plan

Il s’agit de rédiger le Plan (voir description d’un plan).

Analyser les Risques

La planification va révéler de nouveaux risques (Chemin critique par exemple) qu’il faut consigner dans le Registre des Risques et gérer comme n’importe quel risque.

Les différents plans

Ce n’est pas parce que PRINCE2 a pour principe de planifier par les produits que la planification des activités n’est pas effectuée. Mais celle-ci ne doit être que la conséquence de la planification des produits comme le décrit le schéma suivant.

PRINCE2 prévoit quatre niveaux de plan dont trois qui intéressent plus particulièrement le projet.

Figure 7.4 — Les niveaux de plan.

Ln Le schéma 7.4 précise où sont créés les plans, sachant que les Plans de Projet et de Séquences doivent être revus à chaque limite de séquence et a fortiori quand apparaît un Plan d’Exception.

Le Plan de Projet

Le Plan de Projet identifie les principales réalisations du projet et les principaux points de contrôle. Il prend en compte les contraintes du Plan d’Entreprise ou de Programme.

Le Plan de Projet est le référentiel du Comité de Pilotage de Projet lui permettant de contrôler la progression du projet.

Ce plan contient notamment tout ce qui est nécessaire au Comité de Pilotage de Projet pour connaître les coÛts et les délais inhérents au projet.

Figure 7.5 — Les processus impliqués dans la planification.

Le Plan de Séquence

Le Plan de Séquence est un « sous Plan de Projet », il présente de façon détaillée ce qui sera réalisé lors de la séquence. Ce plan est destiné au Chef de Projet afin de lui permettre de contrôler la séquence. Il contient le niveau de détail nécessaire et suffisant pour ce contrôle. Le fait que le Plan de Séquence soit produit juste avant que la séquence ne commence, et non à l’initialisation, permet d’affiner ce plan en tenant compte de ce qui s’est déroulé (retour d’expérience sur les séquences précédentes par exemple) et d’ainsi mieux coller aux réalités de l’environnement. Mais aussi de ne se donner qu’un horizon de planification réaliste et gérable, tant il est vrai que plus une o planification recouvre un laps de temps important et plus cette planification est sujet à caution, la médiumnité n’est pas encore un critère de sélection d’un Chef de Projet.

Le Plan d’équipe

Le Plan d’Equipe est facultatif car son utilité n’est en général réelle que sur les projets de taille importante. De plus, les équipes pouvant être externes à l’organisation, le Plan d’Equipe n’a pas forcément à être connu du Chef de Projet, pour des raisons commerciales par exemple, du moment que celui-ci a prévu les interfaces et les contrôles nécessaires pour s’enquérir de la progression d’un Lot de Travaux, notamment à l’aide de Rapports d’Avancement. S’il est créé, le Plan d’Equipe devrait suivre les mêmes règles de création que les autres plans.

Le Plan d’Exception

Le Plan d’Exception est un plan créé lorsque le plan d’origine ne peut plus être suivi, que ce soit le Plan de Séquence ou le Plan de Projet, Ce Plan d’Exception va alors se substituer au plan qu’il remplace. L’autorité compétente, Comité de Pilotage de Projet ou Direction de l’Entreprise ou du Programme devra donner son aval pour ce remplacement.

Il n’y a pas de Plan d’Exception pour le niveau Lots de Travaux. Si un Chef d’Equipe estime que le Lot de Travaux risque d’aller au-delà des tolérances spécifiées, il en informe le Chef de Projet en générant une incidence, celui-ci demandera des actions correctives si le dépassement au niveau du Lot de Travaux reste tolérable au niveau de la séquence. Sinon, le Chef de Projet agira comme il le ferait pour n’importe quelle incidence pouvant affecter les tolérances de séquence et/ou de projet.

Retour d’expérience

• « La carte n’est pas le territoire » selon Alfred Korsybski, le plan n’est jamais que la représentation « schématique » d’une réalité infiniment plus complexe. La solution est dans la recherche du meilleur compromis entre vouloir tout planifier et en général avoir à refaire le plan à peine le projet commencé, et conserver des zones d’incertitudes et ne pas savoir gérer ces zones.
• Ne pas oublier d’estimer les activités de gestion du management et de contrôle de la qualité, elles représentent souvent 20 % de la charge du projet.
• En général, les estimations sont optimistes, ne serait-ce que parce que de nombreux projets sont pilotés par les délais, date butoir qu’il faut respecter absolument.
• Des ressources affectées à plusieurs projets simultanément vont prendre plus de temps que des ressources dédiées au projet.
• Le temps est immuable, ce que l’on en fait est variable : des objectifs clairs et des défis à relever permettent à des équipes de se surpasser, à l’opposé, s’affairer à ne rien faire est universellement pratiqué.
• Ne pas perdre son âme à essayer de faire plaisir à sa hiérarchie, les miracles sont rares, donc prévoir large.
• Plus l’équipe est nombreuse et plus les tâches requièrent de temps.
• Une femme donne naissance à un enfant en neuf mois. Neuf femmes ne peuvent pas le faire en un mois, il y a des tâches qui ne peuvent se paralléliser ; de plus, incorporer de nouvelles ressources prend du temps au projet, surtout dans l’affolement d’un projet qui prend l’eau.
• Accepter que les estimations ne soient que des estimations, on apprend en se trompant, jamais en ne risquant rien.
• Le Plan de Séquence n’est jamais qu’un Plan de Projet détaillé et suffit à décrire les activités des Lots de Travaux sur de petits projets.
• Des outils informatiques existent, il faut les utiliser de façon à comprendre qu’ils sont surtout utiles dans la conception et dans l’historisation des plans, et souvent complètement inadaptés pour faire une présentation synthétique et claire. Or le « planning » est un excellent média de communication, parfois le seul sur le projet.
• Obtenir une visibilité sur les plans d’équipe des fournisseurs peut être utile afin de vérifier la réservation des ressources et des moyens. Vérifier que quelqu’un a bien été affecté à une tâche et que cette personne semble avoir les compétences nécessaires.
• Prévoir que les décisions et approbations demanderont du temps, voire les identifier comme des activités du projet sinon des dépendances externes est une bonne pratique.
• Créer l’urgence ; en général, les ressources du projet vont miraculeusement trouver le temps qui leur semblait impossible à trouver, de même pour les aspects financiers.

Tableau 7.1 – Le CHAOS et le Thème Plan.

Réponse de ce chapitre aux facteurs de réussite du projet

Le thème Plan fournit apparemment peu de réponses aux facteurs d’échec d’un projet. Concernant le rapprochement des jalons, c’est effectivement dans ces activités de planification que ces décisions devraient être prises. Même si PRINCE2 ne prône pas un jalonnement « serré », il est toutefois clairement indiqué que l’horizon de planification doit être en adéquation avec l’environnement du projet. Si le projet est complexe, crucial, ou présente des risques, l’attention que doit lui porter le Comité de Pilotage du Projet doit être en relation, et par conséquence, le découpage en séquences de management doit être plus fin. Ceci afin que le Comité de Pilotage du Projet puisse contrôler au plus près l’évolution du projet.

THÈME : PROGRESSION

Le thème progression correspond à une Analyse de la valeur acquise tout au long du projet. Cette progression est planifiée dans les plans et doit être contrôlée, c’est-à-dire mesurée par rapport à des cibles de performances quantifiées de coût, délai, qualité, périmètre, risque et bénéfice (les six aspects d’un projet).

Les tolérances

Ces cibles mesurables sont assorties de Tolérances qui sont des déviations admissibles et qui portent non seulement sur les coûts et les délais, mais également sur les quatre autres aspects d’un projet. Ces Tolérances permettent de répondre au 5^e Principe, celui de Management par Exception en ce qu’elles permettent de limiter, par exemple, le nombre d’incidences remontées au Comité de Pilotage de Projet sous forme d’exception. Les incidences mineures sont traitées par le niveau de management adéquat sans qu’il soit nécessaire de demander une autorisation préalable au traitement.

Ces Tolérances sont le degré de latitude laissé au Chef de Projet ou au Chef d’Equipe, mais aussi au Comité de Pilotage de Projet. En cela, PRINCE2 propose de déléguer de véritables responsabilités, car elles sont clairement délimitées. Une autonomie claire est donnée aux responsables du niveau inférieur, ceci permettant d’amortir les « soubresauts » du projet au bon niveau tout en conservant le niveau de contrôle adéquat. Tant qu’un responsable reste dans son domaine de tolérance, il peut apporter les actions correctives qu’il juge adéquat au problème rencontré, la décision lui incombe et l’information peut être faite a Posteriori sous la forme d’un rapport périodique (Rapport d’Avancement ou Rapport de Progression). Le Chef de Projet peut également choisir d’envoyer un Rapport d’Incidence pour formaliser l’événement ou le Chef d’Equipe émettre une incidence sous le format précisé dans la Stratégie de Communication à destination du Chef de Projet.

A défaut de Tolérances correctement définies (et donc de contrôles), le niveau supérieur de management est appelé à prendre toutes les décisions. Le responsable n’a de ce fait plus de marge de manœuvre, ce qui le réduit à un rôle de « passe-plat » et le discrédite à coup sûr. Que ce responsable soit le Chef de Projet, le Chef d’Equipe ou même le Comité de Pilotage de Projet qui chacun ont des Tolérances définies par le o niveau supérieur de management.

La figure 7.6 présente dans quels Produits de Management sont disponibles Ln les tolérances mais également sous quelle forme ou à l’aide de quel Produit de

Management un niveau avertira le niveau supérieur du dépassement d’une tolérance.

Il est donc évident que la détermination des Tolérances est très importante à chaque niveau car elle est le reflet de l’organisation et du niveau de confiance envers les niveaux de responsabilité inférieurs.

Les niveaux de Tolérances sont définis et mis à jour dans trois processus (Elaborer un Projet, Initialiser un Projet et Gérer une limite de Séquence) dans divers Produits de Management en fonction de l’aspect (Domaine de Tolérance) sur lequel porte la Tolérance. Le tableau 7.2 résume où sont documentées les Tolérances des six aspects du projet.

Les Tolérances Qualité sont uniquement présentes dans les Descriptions de Produit.

Figure 7.6 – Les Tolérances et les Rapports correspondants.

Seul le Cas d’Affaire contient la notion de Bénéfice et ceci seulement au niveau Projet, les Tolérances de Bénéfice sont donc dans le Cas d’Affaire.

Les Tolérances de Risque sont décrites dans la Stratégie correspondante, le Comité de Pilotage de Projet et le Chef de Projet fixent ces Tolérances respectivement dans le Plan de Séquence et dans le Lot de Travaux.

S’il est aisé de comprendre à quoi peuvent correspondre des Tolérances de Délai ou de Coût, en revanche, cela demande à être précisé pour les autres Tolérances.

Tableau 7.2 — Association entre Tolérances et Produits de Management.

• Tolérances de Périmètre : le périmètre est l’ensemble des produits à livrer, la tolérance porte donc sur un ou plusieurs produits qui pourraient ne pas être livrés, par exemple déploiement d’une solution informatique sur une région administrative et non sur tout le territoire. Cette tolérance se réfère obligatoirement à une Description de Produit de Projet sous la forme d’une Structure de Décomposition du Produit de Projet.
• Tolérances de Risque : deux formes sont envisageables : la limite peut porter sur le cumul des menaces (sur la somme des criticités par exemple), ainsi un projet ne sera déclaré viable que si le cumul de ses criticités ne dépasse pas 10 % du budget du projet ; la limite peut porter sur un type de risque particulier qui atteindrait une fonction vitale de l’entreprise. Par exemple, aucun risque ne doit être pris pendant la période de vacances par la production informatique du site d’appel d’une société d’assurance de voyageurs ; pas de mise en production par exemple lors de cette période. On peut noter que s’il est envisageable de définir des Tolérances sur les menaces, celles sur les opportunités sont plus « opportunistes » et n’ont a priori aucun intérêt à être définies au préalable.
• Tolérance de Qualité : la Qualité est décrite par PRINCE2 au travers des caractéristiques des produits ou processus associés. Dans ce cadre, elles font parties des Descriptions de Produit car associées directement à la caractéristique visée. Par exemple, une dimension physique en tout cas mesurable telle que longueur, couleur, temps, goût, intensité sonore, radiation, imperméabilité, dureté Brinell, hygrométrie, température, pression, ampérage, Tesla, conductivité thermique, fréquence, etc. Dans tous les cas quelque chose qui ne soit pas subjectif et donc sujet à conflit.
• Tolérance de Bénéfice : souvent définies en termes de marge d’une autre valeur, par exemple, 5 % de réduction des coûts d’émission d’une facture, 10 % de réduction du temps de traitement, 15 % d’augmentation du Chiffre d’Affaire. Ces Tolérances seront données en proportion de ces valeurs, sachant qu’il est peu probable qu’une Tolérance soit définie du côté « positif » de la variation (limiter l’amélioration du chiffre d’affaire ou du temps gagné est peu probable quoiqu’envisageable pour des raisons politiques ou de sur-qualité).

Découpage de la séquence

La plupart des projets sont définis par des séquences techniques ou spécialistes qui sont le reflet de ce qui doit être réalisé sur le projet ou d’un regroupement de tâches à réaliser par une équipe. Cette forme de planification, si elle permet aux réalisateurs du projet de se projeter directement dans le travail à réaliser, ne constitue pas la vision que veut en avoir le client. Le risque de n’avoir qu’un découpage en séquences techniques est que le projet puisse être dirigé par les équipes spécialistes et non par la direction du client.

Ceci n’exclut pas le fait que les séquences de management puissent coïncider avec les séquences techniques, même si cela est improbable. Le tout est de conserver à l’esprit que le Plan de Projet et le découpage en séquences de management doivent en premier lieu préserver les intérêts du client et faciliter son exigence de contrôle.

Le découpage en Séquence de Management doit donc tenir compte de l’impératif de définir des points de contrôle clairs pour le management du projet. La fin d’une séquence de management peut correspondre à des décisions que le Comité de Pilotage de Projet doit prendre, ne serait-ce que de continuer le projet en fonction des résultats de la séquence précédente.

Il n’est pas nécessaire que la fin de chaque séquence de management corresponde à une fin de Séquence Technique, il y aura lieu de préciser dans les Descriptions de Produit concernées ce qui doit être achevé, exemple, trois des sept modules de programme d’une application doivent être achevés, ou la moitié des murs de façade peints, etc.

Les trois schémas suivants montrent comment est découpé un projet constitué préalablement de sept séquences techniques. On peut noter qu’une séquence technique peut-être commencée dans une séquence de management et terminée dans une autre.

Figure 7.7 — Planification des séquences techniques.

Figure 7.8 — Détermination des contrôles de haut niveau.

Figure 7.9 — Planification finale du projet

Dimensionnement de la séquence

Le découpage en séquences de management est fonction d’un certain nombre de paramètres.

L’horizon de planification : c’est la visibilité que l’on veut se donner vis-à-vis du projet. Cet horizon dépend du niveau de risque des activités d’une séquence donnée ou par exemple de la confiance que l’on a dans l’équipe projet. En fait, cet horizon dépend essentiellement de l’environnement du projet et notamment des acteurs et du niveau de confiance réciproque.

Les séquences techniques : aligner la fin des séquences de management avec celle des séquences techniques peut présenter l’avantage de fournir au Comité de Pilotage de Projet des résultats tangibles, éventuellement nécessaires pour prendre des décisions étayées sur ces résultats (fin d’un audit, d’une mission de conseil, etc.).

Alignement sur les activités de programme : le programme pilote le projet. Pour un programme découpé en tranches, la fin d’une séquence d’un projet peut avoir à correspondre avec la fin d’une tranche afin d’être revue ensemble.

Le degré de risque : des fins de séquences placées à certaines étapes du projet o permettent au Comité de Pilotage de prendre des décisions qui peuvent s’avérer cruciales dans le cadre d’un projet risqué.

Pour conclure, outre que cette technique de planification en séquences de management permet de satisfaire les besoins en termes de contrôle de la direction du projet, elle permet de se donner l’obligation de planifier en détail les séquences juste avant leur démarrage. Cette proximité de la planification avec le moment où les tâches vont être réalisées permet une meilleure planification et de ne pas avoir en permanence à retravailler des planifications qui à peine publiées sont déjà obsolètes.

Outils de contrôle

Un certain nombre d’outils sont proposés dans le cadre de PRINCE2 pour assurer le contrôle du projet.

1. Au niveau du Comité de Pilotage de Projet

• Plan de Projet,
• Plan d’Exception
• Rapport de Progression
• Rapport de Fin de Séquence
• Rapport de Fin de Projet

1. Au niveau du Chef de Projet :

• Plans de Séquence
• Rapport d’Avancement
• Journal de Projet
• Registre des Incidences
• Rapport d’état du Produit
• Registre Qualité

1. Au niveau du Chef d’Equipe (bien qu’il ne s’agisse pas d’un contrôle au niveau projet)

• « Lots de Travaux » sachant qu’il est laissé libre quant aux contrôles qu’il veut mettre en place au niveau des équipes.

L’analyse de tendances remarquables au niveau des registres peut également indiquer un problème concernant l’avancement des travaux, par exemple, reprises systématiques des travaux réalisés par tel membre d’une équipe (Qualité), retard systématique dans la livraison d’une équipe (Incidence).

On peut noter que les Rapports d’Avancement et de Progression sont dits périodiques, tous les autres rapports sont considérés comme réactifs (en réponse à un événement).

Techniques d’évaluation de la progression

Les principales techniques d’évaluation de la progression sont les suivantes :

• Gestion de la valeur des revenus : il s’agit de mesurer objectivement le résultat obtenu en fonction de l’effort fourni.
• Graphique de Jalons : consiste à schématiser sur un graphique temporel ce qui avait été prévu par rapport à ce qui a été réalisé.
• Courbe en « S » : autre forme plus commune de la gestion de la valeur du revenu, assez représentative du fait qu’au démarrage, peu de choses sont réalisées pour un coup plus important. Ce type de graphique permet surtout de se projeter et de visualiser les dépassements prévisibles par projection.

Peu importe la technique utilisée du moment qu’elle est unique et partagée. La plus-value n’est pas dans la technique mais dans la capacité d’anticipation et de réaction.

Retour d’expérience

• S’il est intéressant de passer du temps à définir des Tolérances de coût, de délai et de qualité et d’identifier les fonctions sur lesquelles des menaces inacceptables peuvent peser, en revanche, les Tolérances de Bénéfices et de Périmètre sont peu utilisées car difficiles à définir et requièrent surtout une attention systématique et une décision opportuniste du niveau de responsabilité compétent pour prendre une décision.
• Faire comprendre et accepter par tous (et soi-même) que la confiance n’exclue pas le contrôle.
• Fixer des Tolérances, c’est savoir déléguer intelligemment et prendre et donner de véritables responsabilités. C’est véritablement responsabiliser les acteurs.
• Il y a plus de bon sens dans les équipes techniques qu’on ne le pense généralement : à consulter donc avant de planifier des contrôles.
• Une hiérarchie n’a aucun intérêt si elle n’a aucun pouvoir discrétionnaire : virer les niveaux intermédiaires superflus.
• L’autonomie n’est pas l’anarchie, ce n’est qu’une forme de gouvernance intelligente : donner leur autonomie aux acteurs du projet en les responsabilisant.
• Les fins de séquences peuvent coïncider avec des « portes » (Gates en langage français professionnel courant) correspondant à des prises de décisions formelles quant à la continuation du projet (GoNogo toujours en langage français professionnel courant).
• La technique d’évaluation de la progression dite en « S » est intéressante car elle permet de repérer les dysfonctionnements actuels et d’en visualiser de futurs par simple projection linéaire.

Tableau 7.3 — Le CHAOS et le thème Progression.

Réponse de ce chapitre aux facteurs de réussite du projet

Les mêmes remarques faites pour le thème Plan peuvent être reprises pour le thème Progression, qui ne donne que peu de réponses essentielles aux facteurs d’échec d’un projet. Il faut toutefois remarquer l’importance de l’horizon de planification adéquat pour répondre au facteur de jalonnement rapproché. Les tolérances permettent de confirmer que les attentes sont réalistes en ce qu’elles fixent des limites a priori acceptables quant aux six aspects du projet et que cela permet en cas de déviation de réagir par anticipation à la déviation.

PROCESSUS : CONTRÔLER UNE SÉQUENCE

Une fois que tout a été préparé, le projet peut « démarrer » et les premiers produits être réalisés. Le but du processus Contrôler une séquence est essentiellement d’affecter les travaux aux équipes de réalisation et de surveiller l’avancement des travaux. Le Chef de Projet, acteur principal de ce processus, va également capter et traiter les incidences qui pourraient impacter la séquence en cours, mais également la suite du projet.

Il faut noter qu’aucun autre processus de PRINCE2 ne permet de contrôler des activités de réalisation, d’où l’utilisation de ce processus pour gérer les activités de fin de projet ou pour prolonger la séquence d’initialisation pour des projets complexes.

Si tout se déroule selon le plan, le travail à effectuer par le Chef de Projet est juste de :

• Distribuer le travail selon ce qui a été convenu,
• Surveiller l’avancement,
• Réceptionner les produits,
• Rapporter la progression.

Mais tout ne se passe pas toujours comme cela était prévu et dans ce cas, le Chef de Projet doit :

• Recueillir les incidences,
• Mener les actions correctives,
• Rapporter une incidence et éventuellement une Exception.

À la fin de la séquence, le Chef de Projet fait le bilan de la séquence et propose le Plan de Séquence suivante au travers du processus Gérer une limite de séquence.

Le schéma suivant présente les huit activités du processus.

Ces activités peuvent être dissociées en trois groupes :

1. Les Lots de Travaux,
2. Le « reporting »,
3. Le suivi et la gestion des événements.

Figure 7.10 — Les activités du processus Contrôler une séquence.

Groupe 1 : Les Lots de Travaux

Autoriser un Lot de Travaux

Le Chef de Projet est seul à pouvoir déclencher les Lots de Travaux tel que le Plan de Séquence le décrit. Il fournit au Chef d’Equipe toute la documentation nécessaire extraite de la Documentation d’initialisation de Projet. Il est probable que le Chef d’Equipe ait préalablement produit un Plan d’équipe et qu’il en ait fait part au Chef de Projet. A fortiori, quand il n’y a pas de Chef d’Equipe, les tâches sont affectées par le Chef de Projet en fonction de la disponibilité des intervenants qui doit être connue Ln voire maîtrisée.

Cette activité constitue une passation formelle de tâches à exécuter, mais aussi le déclencheur de ces tâches. On peut imaginer qu’en cas d’équipe de réalisation externe, un contrat aura déjà été signé et les bons de commande passés.

Examiner l’état d’un Lot de Travaux

Pendant la durée de réalisation du Lot de Travaux, le Chef de Projet va s’assurer de l’avancement de celui-ci tel que décrit dans le Lot de Travaux, notamment au travers des Rapports d’Avancement.

Les registres sont tenus à jour par le Support Projet et servent d’indicateurs de progression, mais aussi à anticiper les possibles dépassements de tolérances. Chaque

Figure 7.11 — Les principaux échanges du groupe 1 : Lots de Travaux.

Enregistrement de Configuration correspondant aux produits réalisés possède un statut indiquant potentiellement l’état d’avancement du produit en question.

Réceptionner des Lots de Travaux achevés

Il s’agit de s’assurer que chaque produit des Lots de Travaux a bien été approuvé, que les Enregistrements de Configuration correspondants sont à jour et que le Registre Qualité a été complété.

Groupe 2 : Le « reporting »

Remonter les incidences et les risques

Le Chef de Projet remonte les Incidences et les Exceptions vers le Comité de Pilotage de Projet en fonction des événements qui surviennent lors de la séquence. Il agit selon sa propre appréciation pour les Incidences mais aussi en fonction des risques de dépassement des tolérances concernant la remontée d’Exceptions.

Figure 7.12 — Les principaux échanges du groupe 2 : le reporting.

Les impacts de risque du projet peuvent être remontés si nécessaire au Comité de Pilotage de Projet par l’intermédiaire d’un Rapport d’Incidence. Cela peut être le cas si le Chef de Projet décide de signaler l’impact d’un risque résiduel ou d’un risque ayant pour réponse « accepter ».

Ces rapports ne sont pas exclusifs, un Rapport d’Exception est toujours précédé d’un Rapport d’Incidence.

Rapporter la progression

Le Chef de Projet rapporte la progression définie dans la Stratégie de Communication. C’est une compilation des Rapports d’Avancement et des informations contenues dans les registres, dans le Journal de Projet et celui des Retours d’Expérience.

Groupe 3 : Le suivi et la gestion des événements

Recueillir et analyser les incidences et les risques

Le Chef de Projet doit être vigilant à ce que tout événement pouvant avoir un effet sur le projet lui soit signalé. Ces événements peuvent avoir comme origine n’importe Ln quelle partie prenante du projet. C’est souvent l’occasion de découvrir des parties prenantes non encore identifiées.

Chaque incidence doit être enregistrée de façon informelle sur le Journal de Projet ou formelle dans le Registre des Incidences et analysée pour mesurer l’impact qu’elle peut avoir sur le projet. En fonction de cet impact, l’incidence peut provoquer une simple action corrective ou nécessiter un Rapport d’Exception.

Concernant les risques, le Surveillant de risque peut signaler l’occurrence du risque et ainsi déclencher la réponse appropriée qui peut se décliner en action corrective (Repli dans ce cas car toute autre réponse aura été exécutée préalablement). Toutes les parties prenantes peuvent signaler un nouveau risque qui doit être enregistré dans le Registre des Risques, affecté et communiqué aux personnes adéquates (voir le thème Risque).

Figure 7.13 – Les principaux échanges du groupe 3 Suivi et gestion des événements.

Examiner l’état de la séquence

Outre le suiV1 que doit faire le Chef de Projet dans l’activité Examiner le Lot de Travaux, il est nécessaire de conserver le contrôle global de la séquence qui peut comporter plusieurs Lots de Travaux en parallèle.

Il s’agit de faire l’analyse de la séquence en cours par rapport aux plans et objectifs du projet et bien entendu vis-à-vis des incidences et des risques avérés.

Il convient donc de se donner une vue d’ensemble de la progression du projet. De façon systématique, tous les registres doivent être maintenus à jour et analysés, l’avancement des travaux est comparé au Plan de Séquence et la vérification que cet avancement est en corrélation avec tous les référentiels, la D.I.P notamment, doit être effectuée.

Le Chef de Projet peut s’appuyer sur le Comité de Pilotage de Projet en demandant conseil et décider s’il doit lui envoyer des Rapports d’Incidence ou d’Exception afin de l’alerter formellement à propos d’un événement.

C’est également dans cette activité que le Chef de Projet activera les processus de Fin de Séquence ou de Fin de Projet à l’approche de la fin de séquence en cours.

Mener les actions correctives

Une action corrective consiste à créer un Lot de Travaux qui va permettre de redresser une déviation constatée ou future par rapport aux plans. Une action corrective ne peut être menée que si l’impact de l’événement la rendant nécessaire ne produit pas un dépassement des tolérances fixées, à quelque niveau que ce soit. Une action corrective peut également être menée pour pallier une incidence qui risque de faire dévier le projet de ses tolérances. Ceci dans le cas où l’impact de l’incidence peut être anticipé, par exemple, une non-conformité que l’on peut régler facilement (câblage non terminé, fuite dans un réseau d’alimentation, etc.).

En cas de dépassement des tolérances de séquence ou de projet, il y a lieu de faire un Rapport d’Exception et éventuellement le Plan d’Exception associé sera demandé par le Comité de Pilotage de Projet (voir le chapitre concernant le Processus : Gérer la Limite d’une Séquence pour la production du Plan d’Exception).

Le Chef de Projet et le Comité de Pilotage de Projet doivent travailler en relation constante et efficiente (principe de Management par exception). Ceci implique que le Chef de Projet peut recevoir, sous forme de conseil, des directives afin d’apporter des corrections à ce qui est en cours de réalisation.

Il ne faut pas oublier que le terme Incidence recouvre à la fois les Problèmes ou Soucis, mais également les Requêtes de Changement et les Hors Spécifications. Si ces Incidences rentrent dans le cadre des tolérances, elles sont donc traitées comme des actions correctives.

Relation avec la Maîtrise des Changements

Dans le cadre de la Maîtrise des Changements et du contrôle des incidences proposée dans le Thème Plan, PRINCE2 propose la procédure suivante.

Ces activités correspondent essentiellement aux activités du processus Contrôler une séquence, mise à part l’activité de décider qui est sous la responsabilité du Comité o de Pilotage de Projet, mais pouvant être déléguée au Chef de Projet ou à une Autorité de Changement, selon le schéma suivant.

Figure 7.14 — Procédure de contrôle des incidences et de maîtrise des changements.

Figure 7.15 Répartition des activités de la Procédure de contrôle des incidences et de maîtrise des changements.

Attention, dans le schéma précédent, on suppose que l’autorité de changement n’est pas déléguée. Si elle l’est, l’activité « 4-Décider » sera dévolue à l’Autorité de Changement pré déterminée,

Retour d’expérience

• Faire attention à ne pas rentrer dans une routine, même si les phases précédentes de préparation sont primordiales et devraient avoir placé le projet sur des rails, le Chef de Projet ne doit pas relâcher sa vigilance.
• Ce qui est passé, est passé. Passer trop de temps à décrire ce qui s’est bien passé dans des rapports n’est pas très productif. Le seul intérêt de tels rapports se trouve dans le retour d’expérience et l’historisation du travail accompli.
• Il est normal que tout n’ait pas été prévu dans le plan. Rechercher les précurseurs de déviation (dans les faits, analyser les risques) permet de ne pas se laisser surprendre.
• Prévoir qu’en général aucun rapport n’est lu où agir comme si, et que s’ils sont lus ils sont souvent mal interprétés. Un Executive Summary ( * ) (« ce que doivent comprendre ceux qui n’ont pas lu » ) est indispensable.
• Rien n’est plus désagréable à une hiérarchie d’apprendre trop tard qu’un projet ne va pas remplir ses objectifs. Prévenir au plus tôt d’un problème est indispensable.
• Un Rapport d’Incidence ne comprenant pas au moins une solution est à proscrire, c’est souvent le reflet de la non-maîtrise du projet par le Chef de Projet : rapporter un problème à une hiérarchie sans proposer une solution, c’est avoir à gérer deux problèmes.
• Attention aux actions correctives non maîtrisées, c’est de là que proviendront les futurs problèmes. Une action corrective a le même droit à une conception soignée que n’importe quel produit.
• L’Assurance Projet doit remplir son rôle de conseil, elle doit être sollicitée et ses conseils pris en compte. Son rôle de conseil doit primer sur son rôle de contrôle.
• Garder une trace de tous les événements et des échanges, même si cela ne protège pas de tous les aléas d’un projet, cela peut servir de preuve en cas « d’atterrissage forcé ».
• Rien ne sert « d’ouvrir le parapluie », en cas d’orage on est toujours trempé. Mieux vaut avoir anticipé et s’il est obligatoire de sortir, avoir prévu des vêtements de pluie o et un paratonnerre portatif ». En conclusion, si c’est possible, ne pas participer à un projet voué à l’échec, on se souviendra de votre participation à l’échec et non des Ln efforts pour y remédier, ni de votre bonne volonté. Sinon, écrire clairement qu’elles sont vos appréhensions, proposer des solutions et prévoir un plan B personnel (sortir de ce projet ou de l’organisation au plus vite, par exemple).

( * ) Executive Summary : Présenter sur une seule page les points à retenir, éventuellement sous forme de SWOT (voir annexes) ou de Tableau de bord.

Tableau 7.4 — Le CHAOS et le processus Contrôler une séquence.

Réponse de ce chapitre aux facteurs de réussite du projet

Les facteurs de réussite adressés par le processus Contrôler une séquence sont sensiblement équivalents à ceux adressés par les thèmes Plan et Progression. Le découpage en Lots de Travaux permet éventuellement de s’assurer de la compétence de l’équipe et de l’affecter à une équipe dédiée.

PROCESSUS : GÉRER LA LIVRAISON DES PRODUITS

Ce processus est le parfait miroir des activités dédiées à la gestion des Lots de Travaux du processus Contrôler une séquence.

Si le projet le nécessite, par sa taille par exemple, le Chef de Projet peut faire office de Chef d’Equipe. Il peut également déléguer à un membre de l’équipe une partie de ce qu’il aurait délégué à un Chef d’Equipe et notamment distribuer les tâches à réaliser.

Le Chef d’Equipe, s’il existe, est responsable de ce processus, c’est le lien entre le Chef de Projet et le Chef d’Equipe. Ce lien est constitué d’exigences formalisées entre les deux parties qui peuvent se concrétiser par des contrats. A l’instar du Chef de Projet qui va contrôler au jour le jour le travail nécessaire à la réalisation du projet dans la séquence, le Chef d’Equipe opère de même au sein du ou des Lots de Travaux qui lui ont été confiés.

Le Chef d’Equipe distribue le travail à l’équipe dont il a la charge, s’assure de l’avancement des travaux et rapporte au Chef de Projet. Il peut émettre une incidence ou signaler un nouveau risque selon les modalités de communication qui lui ont été remises. Selon ce qui a été spécifié dans le Registre Qualité dont un extrait peut lui être fourni, il doit obtenir l’approbation pour tous les produits spécifiés dans les Lots de Travaux qui contiennent les Descriptions de Produit à livrer. Les Descriptions de Produit doivent inclure les méthodes qualité à utiliser.

Figure 7.16 — Les activités du processus Gérer la livraison des produits.

Le processus Gérer la Livraison des Produits est basé sur trois activités.

Accepter un Lot de Travaux. Avant que le Lot de Travaux ne soit accepté, le Chef d’Equipe et le Chef de Projet doivent se mettre d’accord sur ce qu’il y a à livrer, les besoins en communication et les contraintes particulières liées à ce Lot de Travaux. Le Chef d’Equipe planifie les tâches à réaliser afin de vérifier que les produits peuvent être achevés dans les contraintes spécifiées. Le Chef d’Equipe s’assure auprès de l’Assurance Projet que son Plan d’équipe est viable notamment au regard de la disponibilité des Vérificateurs/Approbateurs des produits.

On peut imaginer que tout ceci peut se faire par anticipation et que le Chef de Projet n’attend pas le dernier moment pour consulter le Chef d’Equipe. Lors Ln de l’initialisation du projet, lorsque le Chef de Projet créé le Plan de Projet, il a l’obligation de vérifier la disponibilité des équipes et leur acceptation. Par ailleurs, lors de la planification de la séquence suivante, le Chef de Projet doit consulter les Chefs d’Equipe. Tant il est vrai que les planifications doivent se faire en corrélation avec les parties prenantes concernées.

Même si le Registre Qualité n’est pas fourni intégralement pour mise à jour au Chef d’Equipe, les procédures de mise à jour de ce registre sont spécifiées dans le Lot de Travaux. Par exemple, les flux d’information entre l’équipe et le Support Projet qui tient à jour ce registre sont indiqués. Il en est de même pour la mise à jour des Enregistrements de Configuration.

Exécuter un Lot de Travaux. Conformément au Lot de Travaux, le Chef d’Equipe vérifie qu’aucune déviation n’est possible, sinon il avertit par anticipation du risque livraison des produits ou de l’incidence le Chef de Projet selon les modalités de communication mises en place et qui sont décrites dans le Lot de Travaux.

A la fréquence prévue dans le Lot de Travaux, le Chef d’Equipe fait parvenir au Chef de Projet un Rapport d’Avancement.

Livrer un Lot de Travaux. Le Chef d’Equipe informe le Chef de Projet de l’achèvement du Lot de Travaux. Il livre les produits selon la procédure indiquée dans le Lot de Travaux.

Principaux échanges et Produits de Management du Processus sont décrits dans le schéma ci-dessous.

Figure 7.17 Les Principaux Échanges et Produits de Management

Retour d’expérience

• Vérifier que les ressources prévues sont disponibles, même et surtout si l’équipe ne fait pas partie de l’organisation du client.
• Attention, les distances géographiques et hiérarchiques entre le Fournisseur et les Chefs d’équipe sont souvent importantes.
• Essayer de travailler en étroite collaboration avec les Chefs d’équipe, c’est de là que vont venir les Incidences et de là également que vient le bon sens technique et organisationnel.
• Eviter trop de bureaucratie, la rigidité en retour lui est directement proportionnée. ‘Ne pas oublier ceux qui réalisent, sans eux rien ne se ferait. Les faire participer aux décisions et les féliciter est primordial pour conserver une bonne ambiance sur le projet et surtout leur implication. D’autant qu’ils savent souvent mieux que quiconque ce qu’il faudrait faire.
• Prévenir tout conflit d’intérêt en essayant de comprendre les réels objectifs de chacun des membres de l’équipe. Ceux-ci ne sont certainement pas inscrits dans le Cas d’Affaire mais vont conditionner également la réussite du projet.

Tableau 7.5 — Le CHAOS et le processus Gérer la livraison des produits.

Réponse de ce chapitre aux facteurs de réussite du projet

Le processus Gérer la Livraison de Produits n’affecte que peu les facteurs de réussite du projet. Le lien de l’équipe avec l’Assurance Projet peut permettre de valider la compétence de l’équipe et son engagement vis-à-vis du projet. Les Rapports d’Avancement et la remontée des risques et incidences peuvent permettre également de contrôler ces deux éléments.

PROCESSUS : GÉRER LA LIMITE D’UNE SÉQUENCE

Pourquoi un processus particulier pour gérer une limite de séquence ?

Le processus Contrôler une séquence est le processus que gère au quotidien le Chef de Projet alors que Gérer la Limite d’une Séquence, c’est faire un bilan de ce qui a été réalisé dans la séquence et préparer le contrôle formel que va réaliser le Comité de Pilotage de Projet. Ce contrôle va porter sur ce qui a été réalisé et approuvé lors de cette séquence mais également sur le Plan de Séquence suivante que produit ce processus. Enfin, c’est l’occasion de fournir au Comité de Pilotage de Projet les éléments lui permettant de conserver sa confiance dans le projet en lui fournissant les informations de viabilité continue du projet à travers le Cas d’Affaire.

En cas de dépassement des tolérances de la séquence et/ou du projet, un Plan d’Exception est réalisé à la demande du Comité de Pilotage de Projet, suite à un Rapport d’Exception envoyé par le Chef de Projet.

La fin d’une séquence est un moment important de la vie du projet. Ce découpage rythme le contrôle du projet, à chaque fin de séquence un certain nombre de produits ont été réalisés et approuvés, marquant ainsi une étape franchie par le projet assorti de livrables tangibles et donc remarquables.

Ce processus est activé vers la fin d’une séquence, sauf en cas de demande de Plan d’Exception. Ceci revient au même puisque si le Plan d’Exception est accepté, la séquence en cours est replanifiée. Activer un Plan d’Exception, revient dans un premier temps à « clore la séquence en cours ».

En cas de demande de clôture prématurée du projet, ce processus est remplacé par le processus Clore le Projet, ainsi qu’à l’approche de la fin de la dernière séquence du projet. Dans ce cas, le bilan de cette dernière séquence est remplacé par un bilan plus global, celui du projet sous la forme d’un Rapport de Fin de Projet.

Gérer une limite de séquence

Gérer une limite de séquence comporte cinq activités, comme illustré dans le schéma ci-dessous.

Planifier la séquence suivante

La séquence suivante peut impliquer un changement complet des équipes, par exemple sur des chantiers qui incluraient des métiers différents. Il est donc nécessaire de trouver un nouveau mode de fonctionnement avec les nouvelles équipes, pour définir les nouveaux rôles notamment. Le Comité de Pilotage de Projet doit être consulté et il y o a lieu de travailler à la préparation de la prochaine séquence en étroite relation avec les Chefs d’Equipe et l’Assurance Projet. Les Chefs d’Equipe peuvent ainsi préparer leurs plans et anticiper les besoins de ressources.

Toutes les Descriptions de Produit nécessaires à la séquence suivante doivent être finalisées au niveau de détail requis pour être fournies au Chef d’Equipe.

Si la séquence suivante est la dernière séquence du projet, les activités nécessaires à la clôture du projet doivent être planifiées à ce moment. En effet, ces activités doivent être contrôlées par le Chef de Projet comme toute autre activité à travers le processus Contrôler une séquence.

Actualiser le Plan de Projet

Le Plan de Projet doit refléter la réalité de la progression de la séquence en cours, mais aussi du Plan de Séquence suivante ou du Plan d’Exception en cours d’élaboration dans ce processus, et notamment contenir les dernières données de coût et de dates de fin prévisibles.

Figure 7.18 — Les activités du processus Gérer une limite de séquence.

Actualiser le Cas d’Affaire

Il s’agit plus évidemment de mettre à jour la Documentation d’lnitialisation de Projet que seulement le Cas d’Affaire. Le Cas d’Affaire doit être révisé car il pilote le o projet et permet de vérifier que le projet reste viable. Les évolutions doivent être incorporées au Cas d’Affaire dont la responsabilité revient au Comité de Pilotage de Ln Projet. D’autres Produits de Management vont également être mis à jour comme les Stratégies, notamment si l’équipe projet évolue.

Rapporter la fin de séquence

Le bilan de la séquence en cours doit refléter la réalité de ce qui s’est passé et donner au Comité de Pilotage de Projet l’assurance que le projet est toujours capable de remplir les objectifs qui lui ont été fixés.

Au cas où des produits auraient été remis aux utilisateurs au cours de la séquence, une acceptation de prise en charge par le client des produits doit être confirmée (Opération et maintenance). Cette action est appelée : « remise progressive de produit ».

Si des produits n’ont pas été achevés ou sont « non conformes », la procédure de traitement des Hors-Spécifications a pu être appliquée et des compromis accordés, ce qu’il faut signaler.

Cette fin de séquence peut être mise à profit pour rapporter les expériences acquises lors de la séquence à travers le Journal des Retours d’Expérience.

Produire un Plan d’Exception

En cas de suspicion de dépassement des tolérances de la séquence ou du projet, le Chef de Projet doit envoyer un Rapport d’Exception au Comité de Pilotage qui peut lui demander de produire un Plan d’Exception. L’application de ce Plan d’Exception marquera une limite de séquence en cas d’application, d’où son élaboration dans le processus Gérer une limite de séquence. Tout ce passe comme si on appliquait le plan approuvé de la séquence suivante.

Figure 7.19 – Le déroulement du traitement d’une incidence.

En fonction de l’exception, tout ou partie du projet peut être suspendu en attendant que le nouveau plan puisse être mis en place.

Ce plan est réalisé en collaboration avec l’Assurance Projet et avec les Chefs d’Equipe de la même façon qu’un Plan de Projet ou de Séquence le serait.

Le schéma 7.19 indique le cheminement d’une Exception au travers des processus PRINCE2.

Les principaux Echanges et Produits de Management du Processus sont décrits ci-dessous.

Figure 7.20 — Les Principaux Échanges et Produits de Management du Processus Gérer une limite de séquence.

Retour d’expérience

• Le bilan de fin de séquence est une étape importante du projet car il faut démontrer au Comité de Pilotage de Projet que le projet est toujours sous contrôle« À défaut de cette démonstration, le risque de voir le Comité de Pilotage de Projet s’ingérer dans la gestion quotidienne du projet est important.
• Le Plan d’Exception doit faire l’objet de la plus grande attention : on vient de rencontrer un problème, ce n’est pas le moment de les cumuler par excès de précipitation. On ne perd pas de temps en faisant les choses correctement mais plus souvent en essayant d’en gagner en « bricolant ». Se rappeler que Confucius a dit « une petite impatience ruine un grand projet ».
• Attention de rediffuser les documents actualisés aux parties prenantes concernées, avec une note précisant ce qui a évolué pour en faciliter la lecture. Ne pas tomber dans l’écueil inverse de diffuser des documents trop fréquemment, essayer de grouper.
• Organiser une réunion formelle et travailler la présentation afin qu’elle montre le travail accompli et surtout les efforts restant à consentir, sans s’enferrer dans les détails.
• Profiter de cette réunion pour remercier les fournisseurs et leurs équipes, ce sont peut être les prochains fournisseurs des futurs projets. C’est également le moment pour réimpliquer toutes les parties prenantes du projet.
• Faire de la « publicité » autour de ce qui a été réalisé, une réunion conviviale c’est-à-dire un « pot ») est toujours le bienvenu pour améliorer la communication.

Tableau 7.6 — Le CHAOS et le processus Gérer une limite de séquence.

Réponse de ce chapitre aux facteurs de réussite du projet

Le processus Gérer la Limite d’une Séquence contribue au travers de la création du Plan de Séquence suivante à ce que les exigences du projet soient bien comprises par les parties prenantes et acquérir en cela le soutien des responsables opérationnels dont les contraintes doivent être prises en compte également. Le fait que le Plan de Séquence suivante soit créé au plus près du démarrage de la séquence en question permet d’obtenir un plan réaliste car prenant en compte les réalités du terrain et les Retours d’Expériences acquis lors des séquences précédentes.

PROCESSUS : DIRIGER UN PROJET

Le processus Diriger un projet est le processus du Comité de Pilotage de Projet. Il va lui permettre de contrôler le projet, donner des conseils et des autorisations. Un projet PRINCE2 est sous la responsabilité du Comité de Pilotage de Projet qui n’en délègue au Chef de Projet que le management au jour le jour.

Le Comité de Pilotage de Projet est composé de membres représentatifs des trois intérêts du projet. A ce titre, il a le pouvoir financier et décisionnaire, et est le sachant fonctionnel et technique ultime à travers l’Utilisateur et le Fournisseur Principal.

Bien que normalement peu disponible, il revient au Comité de Pilotage de Projet de prendre toutes les décisions importantes. Il est également la voix de l’extérieur du projet notamment celle de l’Entreprise ou du Programme.

Le Comité de Pilotage de Projet doit prendre des décisions unanimes, mais malgré tout, l’Exécutif conserve l’autorité ultime que lui confère sa responsabilité financière.

Parce que ce comité disparaît avec la fin du projet, il doit s’assurer que le Plan de Revue des Bénéfices est tenu à jour pour ceux des bénéfices qui ne pourraient être contrôlés qu’après le projet.

Ce processus est déclenché par la demande d’initialisation de projet envoyée en fin de processus Elaborer un projet.

Ce processus est constitué de cinq activités, reflet des activités correspondantes de tous les autres processus à l’exception du processus Gérer la Livraison des Produits avec lequel il n’a pas de relation directe.

Figure 7.20 — Les activités du Processus Diriger le projet.

Autoriser l’Initialisation

L’initialisation du projet requiert du temps et de l’argent ; comme cette phase est planifiée, elle est normalement accompagnée par un budget, alors qu’aucun budget n’avait été dévolu à ce moment du projet (le processus Elaborer un projet n’a pas de budget alloué).

Après avoir revu l’Exposé du Projet, la Description de Produit de Projet et le Cas d’Affaire, ce qui ne devrait être qu’une formalité étant entendu que les membres du Comité de Pilotage de Projet ont largement participé à cette élaboration, le Plan de Séquence d’initialisation est examiné afin de déterminer si les ressources et moyens requis sont présents.

Autoriser le Projet

A la fin de la séquence d’initialisation, le Chef de Projet envoie au Comité de Pilotage de Projet la Documentation d’lnitialisation de Projet et le Plan de la première séquence de réalisation (produite par le processus Gérer une limite de séquence).

Le Comité de Pilotage de Projet va vérifier que le projet est viable à travers l’examen du Cas d’Affaire et que toutes les Stratégies et les contrôles sont en place pour s’assurer de pouvoir commencer la réalisation des produits du projet.

Autoriser le Plan de Séquence ou d’Exception

À la fin de la séquence en cours, le Chef de Projet envoie au Comité de Pilotage de Projet un Rapport de Fin de Séquence complété par un Plan de Séquence suivante.

L’analyse de ces Produits de Management permet au Comité de Pilotage de Contrôler la bonne progression du projet et d’autoriser la séquence suivante.

Les tolérances pour la prochaine séquence sont examinées ainsi que les Recommandations d’Actions de Suivi, notamment si des produits ont été rendus opérationnels. o Les Recommandations d’Actions de suivi, incluses dans le Rapport de Fin de Projet, sont les actions recommandées à effectuer après la clôture du projet. Il peut s’agir d’une tâche en suspens, d’Incidences ou de risques non traités.

Nota : il est possible également de trouver des Recommandations d’Actions de Suivi dans le Rapport de Fin de Séquence, en cas de remise de produit progressive.

Cette Autorisation a également pour objet de tenir la Direction de l’Entreprise ou du Programme informée de l’avancement du projet.

Donner les directives appropriées

Cette activité est la plaque tournante du processus Diriger le projet. Elle est déclenchée à la fois par des sollicitations du Chef de Projet sous forme de Rapport (Fin de séquence, Incidence ou Exception), mais aussi par la Direction de l’Entreprise ou du Programme qui peut décider à tout moment de revoir le Mandat de Projet, c’est-à-dire d’apporter 146

un Changement au projet, mais également de l’arrêter prématurément ou simplement de le suspendre.

Cette activité traite toutes les incidences qui lui sont soumises, c’est-à-dire aussi bien les Problèmes ou Soucis que les Requêtes de Changement (de son niveau de responsabilité) ou les Hors Spécifications.

Une directive peut prendre la forme de l’émission d’une incidence car tout membre du Comité de Pilotage de Projet peut soumettre une incidence. Dans ce cas, l’incidence correspondant à un Problème ou Souci ou à une Requête de changement. Une directive peut également se présenter sous la forme d’un conseil dont la forme est à préciser dans la Stratégie de Communication.

Autoriser la clôture du projet

Le Comité de Pilotage de Projet contrôle à l’aide du Rapport de Fin de Projet et de la Documentation d’initialisation de Projet que le projet peut être clos, c’est-à-dire qu’il a remis tout ce qui lui était possible de remettre. Le Comité de Pilotage de Projet doit vérifier que tous les produits ont été livrés et acceptés par les utilisateurs.

Trois Produits de management sont à créer ou à mettre à jour par le Chef de projet :

• Le Rapport de Fin de Projet doit inclure d’éventuelles Recommandations d’Actions de Suivi qui peuvent faire l’objet d’un document séparé pour certaines actions. Il peut s’agir par exemple d’un dossier d’exploitation, de consignes de renouvellement de licences, d’une procédure de maintenance, etc.
• La complétude du Plan de Revue des Bénéfices doit être vérifiée et approuvée, et sa responsabilité transférée à la Direction de l’Entreprise ou du Programme.
• Le Rapport de Retour d’Expérience est à envoyer à la partie de l’organisation qui a pour mission de le traiter. Il n’est pas nécessaire que ce rapport soit créé à la clôture du projet, bien que ce soit logiquement le meilleur moment.

Cette activité de vérification de « plausibilité » de la clôture doit être menée en o relation étroite avec la Direction de l’Entreprise ou du Programme, seule instance pérenne.

Ln Une Notification de clôture de projet doit être envoyée à l’ensemble des parties prenantes. Ce document doit comporter une date de clôture afin que tous les coûts résiduels non encore imputés le soient.

Dans le cas d’une clôture prématurée, les tâches sont identiques.

Retour d’expérience

• Chaque échéance dans le processus Diriger le Projet marque une étape importante du projet, c’est l’occasion de remercier les participants, d’organiser une manifesta tion ou simplement de communiquer.
• Le Comité de Pilotage de Projet joue un rôle majeur dans un projet PRINCE2. Son activité ou sa passivité engendre la réussite ou l’échec du projet encore plus sûrement que la capacité du Chef de Projet à gérer le projet au jour le jour. Bien choisir les membres de ce comité est donc primordial. Qu’un contrôle d’adéquation et de motivation soit fait par l’entreprise ou le programme n’est pas dénué de sens.
• Se rappeler qu’un projet géré avec PRINCE2 c’est avant tout un projet AVEC un Comité de Pilotage de Projet fort, c’est-à-dire décisionnaire, participatif, coopératif, constructif, cohérent, mais aussi opérationnel et empathique.
• Garder les acteurs du Comité de Pilotage de Projet impliqués est une gageure, c’est pourtant essentiel, d’autant que le projet ne l’est pas pour l’entreprise.

Tableau 7.7 — Le CHAOS et le processus Diriger le projet.

Réponse de ce chapitre aux facteurs de réussite du projet

Le processus Diriger le Projet reprend en miroir l’ensemble des activités des autres processus hormis celles du processus Gérer la Livraison des Produits. De ce fait, ce qui a été évoqué comme points concourant à répondre aux facteurs de succès d’un projet peut être repris au compte de ce processus. Les seules lignes complétées dans le tableau précédent concernent l’existence même d’un processus dédié au Comité de Pilotage de Projet qui implique les Utilisateurs en requérant leur présence et avis tout au long du projet et peut permettre d’impliquer une partie des responsables opérationnels. De même, cela oblige à donner une vision claire de l’appartenance du Produit de Projet.

La fin du Projet

Objectif

Ce chapitre décrit le processus final de PRINCE2, c’est-à-dire comment clore « proprement » un projet.

« Rien ne réussit comme le succès. » Alexandre Dumas

« Une fin de projet claire donne toujours de meilleurs résultats par rapport à la tendance naturelle à dériver vers la période d’utilisation », selon PRINCE2, ce qui reflète la réalité de projets n’en finissant pas de se terminer.

Dans cette dernière phase du projet, un seul processus est nouveau. Il n’y a pas de o séquence de fin de proj et, mais simplement une dernière séquence dans laquelle le Chef de Projet a également planifié les travaux nécessaires à la clôture du projet avec les autres travaux de cette dernière séquence. Ceci parce que ces travaux méritent autant que les autres d’être gérés avec le processus Contrôler une séquence. Au nombre de ces travaux, si cela n’est pas prévu par le projet, il peut y avoir le transfert technologique aux équipes opérationnelles de support et de maintenance.

PROCESSUS : CLORE LE PROJET

Il s’agit lors de la clôture du projet de faire le bilan du projet. Il faut également s’assurer que tous les produits nécessaires ont été remis afin que les objectifs puissent être atteints, et notamment que les sites prévus pour l’installation des produits peuvent les supporter. Par exemple, que l’hébergeur a la capacité d’accueillir les nouvelles applications informatiques ou simplement que l’accès à l’immeuble de logements, objet du projet, est accessible par la route.

Figure 8.1 – Les processus déployés en fin de projet.

L’Acceptation des Produits du Projet doit être obtenue de l’Utilisateur.

Cette clôture « franche » du projet sert souvent de limite pour le paiement des fournisseurs externes (ou de date faisant foi pour le début de la garantie).

L’objet de ce processus est de savoir démobiliser les acteurs du projet mais également de fournir aux parties prenantes qui sont concernées après que le projet ait été clos les éléments leur permettant de gérer les produits.

Ce processus est également activé en cas de clôture prématurée du projet.

Ce processus contient cinq activités, décrites ci-dessous.

Préparer la clôture planifiée

Il s’agit de s’assurer que tous les produits planifiés ont été réalisés et livrés, et donc que les résultats ont été obtenus, afin de pouvoir prévenir la Direction de l’Entreprise ou du Programme de la libération des ressources directement ou indirectement utilisées par le proj et. Cela permet également de faire date en cas de règlement vers les fournisseurs externes.

Figure 8.2 — Les activités du processus Clore le proiet.

Préparer la clôture prématurée

Au cas où le Comité de Pilotage de Projet déciderait de mettre un terme au projet de façon prématurée, le Chef de Projet doit s’assurer de récupérer tout ce qui peut être réutilisable de ce qui a déjà été réalisé, au minimum l’expérience acquise sur les raisons de l’abandon du projet. Des travaux complémentaires peuvent être nécessaires et doivent être approuvés par le Comité de Pilotage de Projet afin de terminer, conserver, sécuriser, protéger ou transférer ce qui a déjà été réalisé ou est en cours d’achèvement et qui pourrait être réutilisable.

Remettre les produits

Tous les produits réalisés au cours du projet doivent être transférés aux entités opérationnelles qui vont « prendre la main » sur ces produits. Ce transfert s’accompagne de la livraison de Plan de Revue des Bénéfices à l’entité qui a la charge de les vérifier (Utilisateurs, Programme, etc.) et de Recommandations d’Actions de Suivi.

Ces Recommandations d’Actions de Suivi doivent inclure non seulement le travail encore à accomplir, mais également les Incidences et les Risques susceptibles d’affecter les résultats et bénéfices du projet. Par exemple, des licences ou contrats à renouveler ou à signer, des requêtes de changement (évolutions) non prises en compte dans le projet, des faiblesses structurelles non prises en compte dans le projet mais à palier (apparition de criques dans les liaisons entre nervures et le revêtement de l’aile nécessitant de les renforcer par collage, prise en compte de données météorologiques exceptionnelles en cas de tsunami…

Évaluer le projet

Faire le bilan du projet est indispensable pour profiter de l’expérience accumulée. Ceci est d’autant plus vrai que la plupart des acteurs du projet vont disparaître de l’organisation cliente, ce qui constitue une perte réelle de savoir-faire.

A minima, faire la comparaison entre ce qui avait été prévu/estimé et ce qui a été effectivement réalisé permet de rendre plus réalistes les chiffrages de projets futurs en cas d’utilisation de méthode historique d’estimation.

Recommander la clôture

Il s’agit d’émettre une Recommandation de Clôture à destination du Comité de Pilotage de Projet. Tous les registres et journaux doivent être fermés à ce stade, même si le projet n’est pas encore clos. Le Chef de Projet doit également préparer l’ébauche de Notification de clôture de projet pour le Comité de Pilotage de Projet.

C’est aussi le bon moment pour faire de la publicité autour de la réussite du projet au profit de l’ensemble des participants.

Retour d’expérience

• Terminer un projet n’est pas toujours facile, mais mieux vaut réouvrir un nouveau projet que de s’éterniser à prendre en compte des changements apportés par la mise en oeuvre opérationnelle des produits.
• Faire un transfert formel des responsabilités, car il serait dommage que les produits se dégradent parce que non entretenus ou pire que tout le travail accompli ne serve à rien car la disparition du Chef de Projet peut créer un manque dans l’organisation o(promoteur de la nouvelle solution proposée par le projet).
• Les projets sont trop souvent techniques et la composante humaine n’est pas Lnassez prise en compte. Tout projet devrait être inclus dans un projet de conduite de changement débordant largement de la phase de réalisation des produits.
• Comme pour la fin d’une séquence, remercier les participants, organiser un « pot » avec les hiérarchies de toutes les entités internes ou externes ayant participé (surtout si le projet est une réussite).
• En profiter pour « faire le ménage » et archiver les données du projet de façon à ce qu’elles soient réutilisables.
• Faire le bilan du projet est difficile car c’est revoir le passé, la plupart des participants ont déjà en tête leur prochain projet. Inutile donc de faire un bilan du projet si cela n’est pas suivi de fait, c’est-à-dire de préservation de l’expérience acquise sur le projet par l’entreprise, laisser la capitalisation aux seuls individus.
• Pas de nostalgie, selon Frank L. Wright : « Mon projet préféré ? Le prochain ».

Tableau 8.1 – Le CHAOS et le processus Clore le projet

Réponse de ce chapitre aux facteurs de réussite du projet

Le projet se termine, on peut espérer que tout ce qui a été fait au préalable a servi à remplir les conditions de la réussite du projet. Pas étonnant donc que cette clôture de projet n’enrichisse pas vraiment le tableau précédent.

Dans tous les cas, si la propriété du produit n’était pas claire, c’est le moment de pallier ce problème car l’équipe projet disparaissant, il serait dommage que les travaux réalisés ne soient pas utilisés mais aussi que les produits ne soient pas maintenus.

L’adaptation du projet

Objectif

PRINCE2 préconise d’adapter chaque projet à son environnement mais aussi d’intégrer la méthode au sein de l’organisation. Ce chapitre décrit comment adapter le projet et donne des clefs pour réduire notamment la charge « bureaucratique » du projet.

Adapter la méthode PRINCE2 au projet est non seulement nécessaire mais indispensable. Imaginer déployer plus de 26 Produits de Management et retenir l’attention de dirigeants pour un projet de quelques semaines est évidemment contre-productif. o A part quelques cas exceptionnels, si l’organisation du projet demande plus de temps que le projet lui-même il y a lieu de se poser des questions.

Mais que peut-on adapter des éléments de PRINCE2 lorsque tous semblent à première vue nécessaires pour contrôler le projet ?

En fait, tout revient à se poser la question autour de ce verbe contrôler. Que veut-on contrôler en réalité et avec quelle précision pour assurer la gouvernance adéquate du projet ? Et inversement quels sont les contrôles superflus ?

Attention, il s’agit d’adapter la méthode au projet et non le projet à la méthode. En d’autres termes, ne pas perdre de vue que le projet prime et qu’il peut être contreproductif de vouloir absolument utiliser une méthode là où la maturité des personnes ou de l’organisation n’est pas suffisante.

Il faut réussir à appliquer le niveau de contrôle management de projet tout en ne le surchargeant pas excessivement.

Adapter la méthode ne consiste pas à abandonner certains éléments, mais au contraire à l’adopter dans son intégralité en adaptant certains éléments.

L’Adaptation de la méthode PRINCE2 traite également de l’Incorporation. Lors de l’adoption de PRINCE2 par une organisation, il est nécessaire d’incorporer un certain nombre d’éléments puis d’adapter ces éléments à chaque projet.

Le tableau suivant présente ce que l’on peut adapter de ce qui ressort plutôt de l’incorporation.

Tableau 9.1 — L’Incorporation et l’Adaptation.

Ce qui ne peut de toute manière pas être adapté, ce sont les principes qui doivent être systématiquement respectés. En effet, ils sont à la base de la « philosophie » de gestion de projet PRINCE2, ne pas les respecter revient à dénaturer la méthode.

Tout le reste ou presque peut être adapté, c’est ce que présente la suite de ce chapitre en prenant chaque Thème et chaque Produit de Management.

ADAPTATION DES THÈMES

Le Cas d’Affaire

Parce que le Cas d’Affaire pilote le projet, il est impensable qu’il puisse disparaître. Il peut en revanche être incorporé à un Cas d’Affaire plus large, celui du Programme dont est issu le projet par exemple. A l’inverse, le Cas d’Affaire peut se limiter à ce qui est quantifiable, les bénéfices attendus et les tolérances relatives, ainsi que l’information nécessaire à l’évaluation de l’investissement, afin de prévoir le budget nécessaire au projet ; ces éléments permettant à minima de pouvoir justifier le projet pour l’entreprise.

Dans le cadre d’un projet à forte connotation commerciale, il y a deux Cas d’Affaire, celui du projet et celui du Fournisseur. Ces deux Cas d’Affaire doivent démontrer qu’ils restent viables pour chacune des parties tout au long du projet sous peine de désaffection.

L’Organisation

Il semble trivial d’écrire que plus le projet est de taille importante et plus le nombre de participant devrait être élevé, et inversement. Il y a cependant une véritable réflexion à mener quant à la taille critique à ne pas dépasser afin que le projet soit encore « gérable » (selon la formule vue précédemment NBC = (N) * (N-I) 1/2).

Pour les projets de petite, voire de très petite taille, certains rôles peuvent être conjugués c’est-à-dire affectés à une seule et même personne. En reprenant chacun de ces rôles •

• L’Exécutif peut assumer le rôle d’Utilisateur Principal,
• Le Comité de Pilotage Projet assume le rôle d’Assurance Projet,
• Le Chef de Projet est son propre Support Projet,
• Le Chef de Projet est également Chef d’Équipe,
• L’Autorité de Changement est répartie entre le Chef de Projet et le Comité de Pilotage de Projet,

La figure 9.1 présente une telle organisation.

Dans un contexte multi-organisation, c’est-à-dire lorsque le projet fait appel à de multiples fournisseurs, et surtout concentre les exigences de multiples « clients », partenariats, consortium, etc., il est parfois difficile de déterminer la propriété du projet. On retrouve ici une des causes de défaillance d’un projet que cite le CHAOS.

Le mieux dans ce contexte est d’arriver à trouver un consensus entre toutes ces parties prenantes dont les intérêts vont évidemment diverger. Dans tous les cas, ceci est du ressort du Comité de Pilotage de Projet et surtout de l’Exécutif qui doit trouver le bon équilibre entre trop de participants au Comité de Pilotage de Projet avec le risque de lenteur de prise de décision et pas assez, ce qui va engendrer des frustrations o et la perte du savoir des interlocuteurs écartés.

La Qualité

Pour les petits projets simples, à défaut d’une véritable stratégie, une explication sur les caractéristiques attendues en termes de Description de Produit (inclus dans la Documentation d’initialisation de Projet), est complétée par l’énumération des critères de validation du produit final.

Pour les projets adossés à des programmes, la Stratégie Qualité du projet est dérivée de celle du programme dont les membres peuvent assumer le rôle d’Assurance et de Contrôle Qualité.

Il est par ailleurs possible de prendre en termes de Stratégie Qualité le Système de Management de la Qualité d’un fournisseur, éventuellement plus adapté au domaine du projet que celui de l’entreprise.

Figure 9.1 — L’équipe projet minimum.

Les Plans

Ln Un simple calendrier des activités, des participants et ce qui doit être produit peut convenir pour les projets simples.

Dans le cadre d’un programme, le projet doit satisfaire à toutes les exigences du programme notamment pour la planification.

Les Plans doivent tenir compte de l’aspect commercial du projet et notamment prendre en compte dans le découpage en séquence des aspects facturation. Dans tous les cas, il y a lieu d’être vigilant au risque que représente la défection d’un fournisseur ou l’arrêt prématuré du projet en terme pécuniaire.

Les Risques

Une analyse simple de risque (avec le risque que cela comporte bien entendu) peut convenir et le Journal de Projet servir à enregistrer les risques. La Stratégie des Risques du projet peut découler de celle du programme et utiliser les mêmes barèmes, catégories et techniques d’évaluation.

Dans le cadre d’un projet à forte connotation commerciale, il peut être dangereux de partager le même Registre des Risques. Dans ce cas, scinder le registre en plusieurs autres permet de ne pas divulguer certaines informations propres à telle ou telle capacité d’un fournisseur. Cela a pour effet de restreindre la transparence, mais comme avantage de ne pas alarmer inutilement les interlocuteurs parfois peu au courant des risques particuliers à un type de projet dont ils n’ont pas l’habitude.

Les Changements

La forme la plus primitive de gestion de configuration peut consister à faire une liste des produits à réaliser avec leur version et le lieu de stockage. Le Journal de Projet peut permettre d’enregistrer définitivement les incidences dont les requêtes de changement.

La Stratégie de Configuration du projet reprendra celle du programme et notam ment les interactions entre les éléments de configuration. Le Budget de Changement doit comprendre les procédures commerciales entre client et fournisseur, par exemple nouvelle commande, modification de commandes antérieures, etc.

La Progression

Le contrôle peut se résumer à des échanges verbaux qu’il est conseillé toutefois de consigner dans le Journal de Projet afin de constituer un historique minimum.

Dans le cadre d’un programme, celui-ci peut largement influencer le séquencement du projet et édicter des contrôles obligatoires, parce que différents projets peuvent être à synchroniser, o Il est nécessaire que les contrôles répondent à la fois aux besoins de gouvernance des deux organisations cliente et fournisseur. Ceci implique parfois la nécessité de doublement des rapports. Notamment lorsque le Chef de Projet dépend hiérarchiquement de l’organisation du fournisseur.

ADAPTATION DES PROCESSUS

Dans le cas de projets simples et peu complexes, il est possible de fusionner les processus Elaborer le Projet et Initialiser le Projet et de produire la Documentation d’initialisation de Projet sans Exposé du Projet.

De même, le processus Elaborer le Projet peut être géré par le programme qui nomme l’Exécutif, l’équipe projet et le Chef de Projet qui n’est responsable que de la production du Plan de Séquence d’initialisation.

Dans un cadre commercial, le processus Elaborer le Projet devrait se dérouler avant l’attribution des contrats dans la mesure où il correspond à l’organisation des réponses aux appels d’offre liées au projet, c’est-à-dire que ces réponses à appel d’offre constituent le Mandat de Projet. Le processus Initialiser le projet doit prendre en compte le temps nécessaire aux préparations du fournisseur (Stratégies, Plans, etc.) et aux négociations commerciales.

ADAPTATION DES PRODUITS DE MANAGEMENT

Cas d’Affaire : voir l’adaptation sur le thème de même nom.

Description de Produit et Description de Produit de Projet : une simple liste de caractéristiques contenue dans la D.I.P.

Document d’initialisation de Projet : « Contenant » majeur d’un petit projet simple.

Exposé du Projet : peut-être omis et remplacé par la production de la D.I.P. dans le cas d’un petit projet simple.

Lot de Travaux : s’il n’y a pas de Chef d’Equipe, la transmission verbale peut convenir entre le Chef de Projet et les membres de l’équipe de réalisation.

Plan : les plans peuvent être de simples calendriers contenant la description de ce qui est à réaliser.

Plan de Revue des Bénéfices : peut être un simple paragraphe de la D.I.P.

Les Stratégies peuvent ne consister qu’à citer les standards de l’organisation dans la D.I.P.

Figure 9.2 — Les Produits de Management pour un petit projet.

Enregistrement de Configuration : ils peuvent être placés dans le Journal du Projet de façon à constituer un historique des versions par exemple.

Journal de Projet : reste d’autant plus indispensable que le projet est modeste, car il va faire office de registre pour les incidences, les risques, les activités de Management de la Qualité et les Retours d’Expérience, ainsi que pour enregistrer la configuration.

Tous les rapports peuvent se faire de manière verbale ou par simple courriel.

Rapport d’Avancement : inutile s’il n’y a pas de Chef d’Equipe.

Rapport de Progression : contient le Rapport d’Etat du Produit.

Rapport de Fin de Séquence : inutile s’il n’y a qu’une séquence.

Rapport de Fin de Projet : contient le Rapport de Retours d’Expérience.

Rapport d’Incidence : remplacé par le Journal de Projet.

Rapport d’Exception : reste nécessaire, s’il y a lieu d’en produire un, mais peut être simplifié.

Le schéma 9.2 présente l’organisation des Produits de Management sur un projet simple.

Retour d’expérience

• Cette adaptation doit être prise au sérieux car c’est ce qui va faire basculer le projet vers trop de bureaucratie ou un laxisme au niveau contrôle et historisation.
• Tout dépend également de la maturité des parties prenantes aussi bien internes qu’externes à l’organisation cliente.
• Utiliser la technique du processus « mou » (auteur de ce concept m’est inconnu), c’est-à-dire démarrer à partir de quelques « principes » facilement admissibles et adapter en fonction des gains de maturité et de la nécessité des contrôles. • Etre exigeant sur les incontournables (date de remise, contenu, formalisme) et anticiper la partie « administrative ».
• Simplifier et automatiser, des outils simples sont accessibles sur la toile.

Tableau 9.0 — Le CHAOS et l’adaptation.

Réponse de ce chapitre aux facteurs de réussite du projet

L’Adaptation du proiet à son environnement concourt certainement à la réussite du projet, elle permet une meilleure compréhension des équipes, en simplifiant les interfaces, les utilisateurs sont plus directement concernés par le projet, les responsables opérationnels arrivent mieux à gérer les interactions entre leurs attributions quotidiennes et les attendus du projet, il est possible d’adapter le jalonnement du projet aux besoins de contrôle, les parties prenantes de haut niveau peuvent se doter de moyens de contrôle adéquats.

Un projet PRINCE2 est-il protégé du chaos ?

Objectif

Après avoir décliné pour chaque concept son impact sur les défauts constatés par l’étude du Chaos Report, que peut-on déduire de l’utilisation de la méthode PRINCE2 ?

C’est le but de ce chapitre de montrer comment répondre à cette question.

Si l’on fait la synthèse de l’ensemble des tableaux présentant les réponses de PRINCE2 aux besoins du CHAOS, il ressort de façon évidente que PRINCE2 répond o parfaitement à ces besoins :

• L’implication des utilisateurs est réalisée par leur participation effective au Comité de Pilotage de Projet.
• Le soutien des responsables opérationnels est obtenu par leur implication lors de la recherche des parties prenantes de la Stratégie de Communication et s’ils sont fournisseurs du projet par leur participation aux décisions dans le Comité de Pilotage du Projet.
• L’énoncé clair du projet est fait par un document dédié, le Cas d’Affaire et dans toutes les Descriptions de Produits qui suivront.
• Le thème Plan répond parfaitement au besoin d’une planification adéquate, si le Plan de Projet présente une vue d’ensemble de ce qui est à réaliser, les différents plans de Séquence et d’équipe permettent d’affiner au niveau voulu cette planification, et ce, au plus près de la réalisation des produits.
• La participation conjointe des utilisateurs et des fournisseurs au Comité de Pilotage de Projet permet de confronter les demandes parfois irréalistes aux faisabilités techniques et pourquoi pas fonctionnelles si dans les fournisseurs il y a des experts des métiers.
• L’adaptation et les thèmes contrôle et plan répondent au besoin de rapprochement des jalons, à condition que ce besoin soit identifié et que les ressources soient disponibles pour effectuer les contrôles.
• La compétence de l’équipe n’est pas un sujet traité par PRINCE2 qui exclut clairement de proposer des moyens de contrôle des compétences spécialistes de l’équipe. Toutefois, la détermination de la structure de l’organisation, ainsi que la définition claire des redevabilités permettent de signaler tout manque et peut-être d’anticiper par la connaissance de la structure de l’équipe tout manque de compétence.
• La propriété du produit est clairement indiquée dès l’élaboration du projet. La Direction de l’Entreprise ou du Programme mandate l’équipe projet, qui à la fin du projet retourne les produits achevés à leur mandateur. Les remises progressives des produits correspondent également à un transfert formel de propriété. Par ailleurs, tout au long du projet, si l’Exécutif est responsable ultime de tout ce qui se fait, les utilisateurs sont conviés à participer et donner leur avis ; ces utilisateurs seront vraisemblablement les futurs propriétaires du Produit de Projet. En rappel, les équipes de maintenance et de support futurs sont aussi représentées par les utilisateurs.

Le Cas d’Affaire dans son chapitre « Raisons » doit présenter clairement la vision de l’entreprise ou du programme et les objectifs de réalisation du projet. Ce Cas d’Affaire va « piloter » le projet, c’est-à-dire qu’à chaque étape importante du projet sa justification va être contrôlée.

Comme pour les compétences de l’équipe, le fait de dédier une équipe au projet n’est pas une obligation pour PRINCE2. En revanche, ce sujet est largement évoqué et la proposition de PRINCE2 est d’éviter de trop nombreuses perturbations d’une o équipe en essayant que celle-ci puisse se consacrer exclusivement au projet pendant un laps de temps identifié et convenu. Quant à la vérification du travail véritablement Ln fourni par l’équipe de réalisation, ceci s’effectue au travers des spécifications contenues dans les Lots de Travaux assorties des Descriptions de Produits contenant les Critères d’Approbation. Le Chef de Projet peut ainsi contrôler le travail à la remise des produits au travers du Registre Qualité. En rappel, le Chef de Projet adresse un Lot de Travaux au Chef d’Equipe ou à un représentant de l’équipe, qui doit accepter « formellement » le Lot de Travaux, ceci permettant une implication de l’équipe. Par ailleurs, le Chef de Projet a construit ses plans en concertation avec les parties prenantes dont les Chefs d’équipe.