PRINCE2
PRINCE2 (PRojects IN Controlled Environments) est une méthode de gestion et de certification de projet structurée qui se focalise sur trois points : l'organisation, la gestion et le contrÎle du projet. Elle est décrite comme une méthode générique et structurée pour appréhender, gérer et mener jusqu'à accomplissement n'importe quel type de projet, quelle que soit sa taille. En 2010, l'adoption de PRINCE2 était considérée comme grandissante et soutenue par un bon accueil des professionnels de la gestion de projet[1].
Historique
- 1975 : Simpact Systems Ltd crée une méthode de gestion de projet baptisée PROMPT (Project Reporting, Organization & Management Planning Technique). Elle est basée sur des expériences pratiques réussies. Au départ, la méthode repose sur l'évaluation continue du projet par rapport aux résultats escomptés par l'organisation.
- 1979 : PROMPT est adopté par le CCTA (Central Computer and Telecommunications Agency) comme norme à utiliser pour tous les projets dans le domaine des Technologies de l'Information du Royaume-Uni.
- 1980 : le CCTA est rebaptisé OGC (Office of Government Commerce).
- 1989 : PRINCE est lancé et remplace PROMPT dans les projets du gouvernement britannique.
- 1996 : la version de la méthode (PRINCE2) a été étendue et rendue plus flexible pour pouvoir gérer des projets de tous types et de toutes envergures.
- 2009 : l'OGC, publie le , PRINCE2:2009, fruit d'un travail de révision en profondeur pour rendre PRINCE2 moins ambiguë et plus compatible avec les autres démarches de l'OGC (ITIL, P3O, P3M3, MSP, M_o_R etc.). Le choix du nom, en place de PRINCE3, a été choisi pour caractériser la démarche de continuité, et de fidélité aux fondamentaux de la méthode.
- 2013 : l'OGC crée avec la société Capita une coentreprise dénommée Axelos à laquelle il transfÚre l'essentiel de ses créations[2].
Projet
Un projet est une organisation temporaire crĂ©Ă©e dans le but de livrer un ou plusieurs produits d'affaires dĂ©finis dans un cas/raison d'affaire (Business Case) approuvĂ©. PRINCE2 dĂ©finit la gestion de projet comme consistant Ă planifier, dĂ©lĂ©guer, monitorer, contrĂŽler et motiver des activitĂ©s afin de remplir des objectifs dĂ©finis Ă l'intĂ©rieur de cibles de performance[3]. PRINCE2 reconnaĂźt les spĂ©cificitĂ©s de projet suivantes : un projet est montĂ© pour permettre une Ă©volution de son organisation commanditaire, il est donc unique et doit ĂȘtre accompli dans une pĂ©riode de temps dĂ©finie. Il fait appel Ă des compĂ©tences puisĂ©es dans un vivier large qui peut mĂȘme s'Ă©tendre au-delĂ de l'organisation hĂŽte. Il sous-tend des risques liĂ©s Ă son caractĂšre exceptionnel. Un projet doit ĂȘtre maĂźtrisĂ© pour rĂ©ussir.
Programme
La méthode PRINCE2 fait souvent référence à un programme comme entité commandant un projet. Un programme est un portefeuille de projets répondant à une stratégie donnée de l'organisation hÎte[4].
La gestion d'un programme d'entreprise est assurée par des personnes dirigeantes de plusieurs projets afin qu'elles aient une vue globale des projets existants.
MĂ©thode
La mĂ©thode tient compte des facteurs changeants de lâenvironnement du projet susceptibles dâinfluencer son succĂšs.
PRINCE2 identifie six variables typiques impliquées dans la gestion de projet : contraintes de temps, contraintes de coût, cible qualité, cadre, risques et enfin bénéfices[5].
Sur chacune de ces variables, lorsqu'un niveau est fixé pour un projet, les variables deviennent ses contraintes ou cibles de performance.
Ce niveau est la tolĂ©rance avec laquelle il doit ĂȘtre atteint.
Les contraintes ou cibles de performance sont fixées par le commanditaire du projet (programme, organisation hÎte).
PRINCE2 identifie deux catégories de produit : les produits dits spécialisés qui correspondent à ce qui est attendu du projet et les produits de gestion, que la méthode élabore pour la conduite du projet et pour audit[6].
La méthode est constituée de trois familles d'éléments, nommées : principes, thÚmes et processus[7].
Principes
PRINCE2 s'enracine sur des fondamentaux de principes transcendants, inhérents à la gestion de projet dans sa généralité, dont il fait découler les articulations de son approche et qui sont au nombre de sept[8] :
- Justification permanente de la raison d'affaire du projet
- Prise en compte de l'expérience accumulée, à la fois en s'inspirant des leçons du passé et en déployant un mécanisme permettant de capturer et archiver pour l'avenir les observations faites durant le projet en cours
- Définition de rÎles et de responsabilités pour assurer les aspects du déroulement du projet
- Découpage du projet en étapes intermédiaires de taille permettant un contrÎle aisé
- Gestion par exception, qui implique de définir un champ d'autonomie (tolérance) pour chaque strate hiérarchique au-delà duquel seulement un mécanisme d'alerte est lancé dans la chaßne de gestion, ceci dans le but d'alléger le fardeau de cette derniÚre[9]
- Focalisation du projet, de son organisation et de sa préparation sur le produit final attendu de celui-ci
- Adaptabilité de la méthode de gestion à l'environnement du projet
Ces sept principes fondamentaux identifiés par PRINCE2 résonnent dans toutes les techniques de la méthode.
ThĂšmes
Les thĂšmes dĂ©crivent les aspects de la gestion de projet qui doivent ĂȘtre abordĂ©s continuellement pour que le projet puisse ĂȘtre menĂ© Ă bien. Ils sont au nombre de sept, comme les principes dont ils s'inspirent[10] :
Cas d'affaire
Raison d'affaire |
---|
Résumé
(points-clefs, coûts, bénéfices, agenda) |
Raisons
(inclut l'alignement avec la |
Bénéfices
(incluant les collatéraux) |
Horizon temporel des bénéfices |
Coûts
(incluant les coûts opérationnels) |
Analyse de l'investissement |
Explication des risques majeurs |
Le cas d'affaire est dĂ©fini clairement dĂšs le dĂ©but du projet et reconsidĂ©rĂ© tout au long de son dĂ©roulement : c'est une considĂ©ration majeure de la gestion de projet selon la mĂ©thode PRINCE2[11], si elle vient Ă disparaĂźtre, le projet passe en phase de clĂŽture. Ce thĂšme incarne le premier principe de la justification permanente de la raison d'affaire du projet. Le document associĂ© est trĂšs complet et comprend un rĂ©sumĂ© incluant les bĂ©nĂ©fices et retour sur investissement attendus, la raison d'affaire proprement dite et son adĂ©quation avec les stratĂ©gies du programme ou organisation hĂŽte commissionnant le projet, les options alternatives, le dĂ©tail des gains attendus ainsi que leurs effets de bord, le calendrier, les coĂ»ts, le retour sur investissement et enfin l'identification des risques. Le but essentiel de la raison d'affaire est de permettre au conseil (vid. inf.) de dĂ©terminer si le projet prĂ©sente et conserve de l'intĂ©rĂȘt, s'il est viable au sens oĂč il peut ĂȘtre menĂ© Ă terme et s'il peut produire les rĂ©sultats attendus.
Organisation
L'organisation du projet va assigner les rĂŽles des diffĂ©rents acteurs pour la direction, la gestion, le contrĂŽle, etc. du projet. LĂ encore, il s'agit d'aspects dĂ©coulant directement du principe de dĂ©finition des rĂŽles et responsabilitĂ©s et la mĂ©thode insiste sur les champs de responsabilitĂ© de chacun des membres de la structure de gestion nommĂ©e pour le projet et sur ce qui est attendu d'eux. PRINCE2 promeut quatre strates de gestion. La premiĂšre est hiĂ©rarchiquement au-dessus du projet : il s'agit du commanditaire. Comme introduit plus haut, dans les organisations d'une certaine taille, les projets sont groupĂ©s dans des portefeuilles dĂ©tenus par des programmes[12] : pour cette raison la terminologie PRINCE2 pour cette strate est gestion de programme. Ă la strate immĂ©diatement infĂ©rieure on trouve la plus haute structure hiĂ©rarchique du projet : le conseil. L'exĂ©cutif du Conseil, identifiĂ© par le programme, est la personne responsable du projet et reprĂ©sente ses intĂ©rĂȘts supĂ©rieurs qui sont ceux du client. Sur recommandation ou non de la gestion de programme, l'exĂ©cutif s'entoure des personnes nĂ©cessaires pour reprĂ©senter les intĂ©rĂȘts clients/utilisateurs de mĂȘme que ceux des fournisseurs qui vont rĂ©aliser le projet concrĂštement[13]. Le reprĂ©sentant utilisateur doit s'assurer de la bonne prise en compte des requĂȘtes client et veille Ă ce que les bĂ©nĂ©fices attendus soient maximisĂ©s alors que le reprĂ©sentant fournisseur veille Ă ce que la solution technique choisie soit fiable et rĂ©alisable dans les cibles de performances. Il s'agit de la strate de direction. Le conseil nomme le gestionnaire de projet Ă la troisiĂšme strate. Le gestionnaire peut ĂȘtre Ă©paulĂ© par un soutien de projet, qui est une ressource administrative. C'est la strate de gestion proprement dite. Ă un niveau encore infĂ©rieur, on trouve la strate de rĂ©alisation, lĂ oĂč les produits du projet prennent effectivement corps. Sa complexitĂ© peut nĂ©cessiter le concours d'Ă©quipes de travailleurs spĂ©cialisĂ©s qui seront menĂ©es par des gestionnaires d'Ă©quipes, dĂ©pendant directement du Gestionnaire de Projet.
Qualité
Description produit |
---|
Clef de référence |
Intitulé du produit |
Utilité |
Composition |
Origine |
Description |
Compétences de fabrication |
CritÚres qualité |
Tolérance sur critÚres qualité |
Méthodes évaluation qualité |
Compétences évaluation qualité |
Responsabilités évaluation qualité |
Le principe de focalisation de la mĂ©thode PRINCE2 sur les produits et rĂ©sultats du projet commande le thĂšme de l'assurance qualitĂ©, aspect prisĂ© de PRINCE2[14]. PRINCE2 reconnaĂźt quatre aspects de la gestion qualitĂ© : le systĂšme qualitĂ© qui documente les principes et mĂ©canismes qualitĂ© existant dans l'organisation hĂ©bergeant le projet, l'assurance qualitĂ© qui veille sur le systĂšme qualitĂ© - si ces deux composantes n'existent pas, PRINCE2 recommande qu'elles reviennent au conseil de projet dans le cadre de l'assurance projet - la planification qualitĂ©, qui dĂ©crit, Ă l'intĂ©rieur du projet, comment les standards seront atteints ainsi que la description des produits avec leurs critĂšres d'acceptation et les responsabilitĂ©s associĂ©es, et enfin le contrĂŽle qualitĂ© qui recense les mĂ©thodes d'Ă©valuation retenues. L'ensemble de ces activitĂ©s qualitĂ© sous la responsabilitĂ© du conseil, dĂ©finit la stratĂ©gie de gestion qualitĂ©. La mĂ©thode prescrit l'enregistrement des critĂšres client/utilisateur dĂšs le processus de dĂ©marrage du projet dans le brief de projet alors que l'approche pour assumer la qualitĂ© requise est consignĂ©e dans le document d'initialisation du projet, produit durant le processus Ă©ponyme. On doit y trouver l'explication de l'application du systĂšme d'assurance qualitĂ© et des standards associĂ©s, quelles responsabilitĂ©s les endossent et enfin les mĂ©canismes pour assurer la bonne conduite du projet. La description des produits incluant les produits intermĂ©diaires, consignĂ©e dans le document du mĂȘme nom, contient une douzaine d'entrĂ©es : un identifiant, le nom du produit, son importance, ses sous-parties, son origine, sa description physique, les compĂ©tences Ă rĂ©unir pour le fabriquer, les critĂšres qualitĂ© auxquels il doit rĂ©pondre ainsi que leur tolĂ©rance, les mĂ©thodes d'analyse qualitĂ©, les compĂ©tences Ă regrouper pour les accomplir et enfin les responsables de la revue qualitĂ©. Ă la remise d'un produit spĂ©cialisĂ©, Ă la fin d'une sĂ©quence ou du projet complet, une revue qualitĂ© est organisĂ©e[15]. Cette activitĂ© permet de rassembler des spĂ©cialistes indĂ©pendants pour Ă©valuer si les produits livrĂ©s rĂ©pondent aux exigences et critĂšres d'acceptation. Quatre rĂŽles sont dĂ©finis : un prĂ©sident de session chargĂ© de mener la revue, un assistant administratif, le dĂ©monstrateur du produit et enfin l'analyste. La session de revue a pour objectif de rĂ©pondre Ă des questions qui n'ont pas pu ĂȘtre rĂ©glĂ©es durant la phase de prĂ©paration qui a normalement permis aux protagonistes d'analyser le produit. Finalement, trois types de dĂ©cision peuvent ĂȘtre rendus : le produit est soit satisfaisant, soit nĂ©cessite quelques corrections, soit doit subir des modifications majeures avant une autre revue qualitĂ©.
Planification
Le principe du contrĂŽle Ă©troit de la rĂ©alisation du projet par morcellement en Ă©tapes sĂ©quentielles demande un effort de planification qui est un autre thĂšme identifiĂ© par PRINCE2 qui a une vision trĂšs complĂšte sur la question : un plan de projet ne se limite pas Ă un calendrier mais renseigne sur ce qui doit ĂȘtre produit, comment (en incluant les ressources nĂ©cessaires), sur les techniques pour atteindre les standards qualitĂ© prescrits, ainsi que l'analyse de risque. Trois niveaux de planification sont distinguĂ©s : la planification du projet dans son ensemble, qui est essentiellement la rĂ©fĂ©rence pour le suivi assurĂ© par le conseil de projet, la planification des Ă©tapes qui est l'outil du gestionnaire de projet pour en assumer le dĂ©roulement et enfin la planification pour les Ă©quipes de travail attachĂ©es aux tĂąches Ă rĂ©aliser, ce dernier niveau Ă©tant optionnel pour PRINCE2. Le principe de la focalisation sur le produit impacte significativement l'Ă©laboration de la planification du projet et des sĂ©quences[16] : c'est en effet Ă partir de la description dĂ©taillĂ©e des produits, incluant leurs critĂšres qualitĂ©, que les activitĂ©s nĂ©cessaires Ă leur rĂ©alisation peuvent ĂȘtre identifiĂ©es et par voie de consĂ©quence les efforts requis, le calendrier et les risques (surtout associĂ©s Ă des produits externes desquels le projet dĂ©pend mais sur lesquels il a peu de contrĂŽle). C'est ce que PRINCE2 appelle la planification basĂ©e sur les produits. Le produit ultime du projet est dĂ©composĂ© en sous-produits et produits intermĂ©diaires qui doivent ĂȘtre assumĂ©s au cours du projet. Ce diagramme hiĂ©rarchique est couplĂ© Ă une carte de flux de produits permettant d'organiser dans le temps l'Ă©laboration des produits intermĂ©diaires en tenant compte de leur inter-dĂ©pendance. Les activitĂ©s et tĂąches sont identifiĂ©es et organisĂ©es Ă partir de ce diagramme de flux et peuvent ĂȘtre structurĂ©es en un organigramme des tĂąches du projet.
Risque
Les risques anticipés sont analysés durant le processus d'initialisation, sont consignés dans le registre des risques et sont reconsidérés tout au long du projet[17]. La combinaison de la probabilité évaluée d'occurrence d'un risque et de son impact détermine son degré. PRINCE2 comprend une stratégie de gestion des risques qui commande l'élaboration de contre-mesures dÚs qu'un risque est identifié. La définition d'une stratégie de gestion du risque est un mécanisme systématique d'identification et d'évaluation d'un risque, et de planification et d'implantation d'une contre-mesure. La responsabilité des risques est répartie au sein du conseil : l'exécutif doit s'assurer que l'ensemble des risques touchant le projet sont identifiés, suivis et traités[18] et que cela soit clairement documenté dans la raison d'affaire. Le représentant utilisateur considÚre l'impact opérationnel des risques sur le produit du projet alors que le représentant fournisseur est responsable des risques pouvant peser sur l'intégrité du cycle de livraison du produit.
Changement
Le thĂšme du changement, dans lequel apparaĂźt aussi le principe de gestion par exception, identifie un Ă©vĂ©nement quand il est anticipĂ© que ses consĂ©quences impacteront les objectifs ou produits du projet, sa planification ou son respect des contraintes de performance. DĂ©cidĂ©s ou subis, les Ă©vĂ©nements sont distribuĂ©s entre trois catĂ©gories par PRINCE2 : des requĂȘtes formulĂ©es, un manquement ou un dĂ©faut d'un bien ou service attendu dans la planification du projet et une derniĂšre catĂ©gorie de problĂšmes gĂ©nĂ©raux. PRINCE2 reconnaĂźt que les projets sont naturellement exposĂ©s Ă des Ă©vĂ©nements et des besoins d'Ă©volution qui doivent ĂȘtre identifiĂ©s, Ă©valuĂ©s et rester sous le contrĂŽle de la strate de gestion adaptĂ©e : agrĂ©er un changement et commissionner le budget adĂ©quat relĂšvent du Conseil, mĂȘme si, dans certaines limites, le gestionnaire de projet a gĂ©nĂ©ralement quelque latitude. PRINCE2 stipule donc qu'une configuration de projet[19] (une technique de contrĂŽle des changements) doit ĂȘtre dĂ©finie, donnant une ligne de rĂ©fĂ©rence pour la gestion du projet et l'Ă©laboration de ses produits. La stratĂ©gie de configuration est dĂ©cidĂ©e Ă l'Ă©tape d'Initiation et le systĂšme de configuration doit permettre de suivre l'Ă©volution des produits afin de donner un instantanĂ© du projet Ă demande : c'est le statut des produits. Le systĂšme de configuration informe des procĂ©dures prescrites pour traiter les changements et la rĂ©solution des Ă©vĂ©nements ainsi que sur les responsabilitĂ©s respectives.
Progression
Avec le thĂšme de suivi de la progression de projet, PRINCE2 stipule et met en place les mĂ©canismes permettant Ă chaque strate de gestion de monitorer la progression de la strate immĂ©diatement infĂ©rieure avec pour but d'Ă©valuer les rĂ©alisations dĂ©jĂ effectuĂ©es en rĂ©fĂ©rence aux cibles prĂ©alablement fixĂ©es, de prĂ©voir la satisfaction des objectifs et, plus drastiquement, de dĂ©cider si le projet conserve sa raison d'ĂȘtre. L'Ă©valuation de la progression s'effectue Ă l'aide de deux types de contrĂŽle : l'un pĂ©riodiquement (rapports rĂ©guliers du gestionnaire au conseil, par exemple), le second Ă des points d'articulation spĂ©cifiques (rapports de fin de sĂ©quences).
Processus
PRINCE2 distingue sept types de processus de gestion qui servent Ă segmenter la direction du projet[20]. Un processus est un ensemble structurĂ© d'activitĂ©s conçues pour rĂ©aliser un objectif spĂ©cifique. Il prend un ou plusieurs Ă©lĂ©ments ou clefs dĂ©finis en entrĂ©e - information, requĂȘte - et les transforme en Ă©lĂ©ments ou clefs de sortie - dĂ©cision, approbation, information. Les activitĂ©s s'exĂ©cutant Ă l'intĂ©rieur des processus s'appuient sur les thĂšmes prĂ©sentĂ©s plus haut. L'ensemble des processus est organisĂ© en un flot[21] et structure le rĂŽle de chacun des acteurs impliquĂ©s.
Les processus sont détaillés ci-dessous : chaque processus est désigné par une abréviation, les initiales en début de ligne correspondent aux initiales en anglais et en fin de ligne leur traduction en français.
(SU) Ălaborer un projet (EP)
(SU) - Elaborer un projet (EP) est la premiÚre étape pour définir tous les prérequis lorsque le mandat pour un projet est émis par une organisation. Le mandat identifie l'exécutif du projet qui nomme par la suite le reste de la structure de gestion, à commencer par le gestionnaire de projet puis le conseil. Consultation des archives pour tirer parti de l'expérience accumulée, ébauche de la raison d'affaire, étoffement du mandat en un brief de projet et planification de l'étape d'initialisation sont les cinq autres des six activités de ce processus qui a donc comme entrée le mandat et comme sortie six produits : le journal qui va servir à consigner les observations futures, le journal du gestionnaire de projet, la structure de gestion, le brief (incluant la définition du projet et l'ébauche de la raison d'affaire), la documentation de l'approche et la planification de l'étape suivante qui est le processus d'initialisation. Le brief, l'approche et la planification de l'étape d'initialisation servent au conseil pour avorter ou au contraire sanctionner la marche vers l'initialisation. Les documents produits par ce processus servent d'entrée au processus d'initialisation qui suit, si approuvé par le conseil.
(DP) Diriger un projet (DP)
(DP) - Diriger un projet (DP) est un processus spécifique au conseil pour assurer la direction du projet sur toute sa durée de vie. Ses activités se divisent essentiellement en décisions et approbations d'un cÎté et en un mécanisme de communication informelle pour rester en prise avec le déroulement du projet de l'autre. Ce processus s'amorce dÚs que le conseil a pris naissance, au début du processus d'élaboration du projet et sa premiÚre décision et la sanction pour amorcer le processus d'initialisation du projet, qui est aussi une séquence, sur la base de la présentation du plan pour cette séquence, du brief et de l'approche.
(IP) Initialiser un projet (IP)
(IP) - Initialiser un projet (IP) est un processus clef, car c'est ici que la planification de l'ensemble du projet, la justification de sa raison d'affaire, l'évaluation des bénéfices attendus, l'approche qualité, etc. sont décidés. Au cours de ce processus, un important document est produit : le document d'initialisation du projet, qui est un composite des points précédents. Ce document sera en permanence consulté et réévalué à l'issue de chaque séquence et servira, in fine, au conseil pour l'évaluation des réalisations et la conduite du projet. Formellement, initialiser un projet comprend huit activités : l'élaboration des quatre stratégies de gestion (qualité, risque, configuration et communication) et leur harmonisation avec celles préexistantes dans l'environnement du projet (programme/organisation hÎte), l'élaboration détaillée de la raison d'affaire et de la revue des bénéfices, la mise en place des processus de contrÎle, le détail de la planification de l'ensemble du projet et la construction du document d'initialisation qui consolide tous les précédents. Le document d'initialisation est, avec le plan pour la séquence suivante, le produit de sortie de ce processus.
(CS) ContrÎler une séquence (CS)
(CS) - ContrĂŽler une sĂ©quence (CS) ou Ă©tape est, d'une certaine façon, au gestionnaire de projet ce que diriger un projet est au conseil. C'est au cours de ce processus que le gestionnaire de projet suit le dĂ©roulement du travail. Cela inclut notamment la prĂ©paration d'un lot de travaux, acceptĂ© par les Ă©quipes d'exĂ©cution, en suivre le bon dĂ©roulement au travers de canaux de communication comme les rapports d'avancement pĂ©riodiques, puis Ă©valuer la livraison en retour des produits. Le gestionnaire doit Ă©galement mener un audit gĂ©nĂ©ral et permanent du dĂ©roulement de la sĂ©quence, dĂ©busquer et suivre les Ă©vĂšnements et risques et entreprendre les actions nĂ©cessaires pour Ă©viter tout dĂ©raillement de la sĂ©quence et du projet. Il communique avec le conseil sur une base rĂ©guliĂšre pour le tenir au courant de l'Ă©volution. Si besoin est, c'est-Ă -dire s'il devient Ă©vident que la sĂ©quence ne pourra ĂȘtre assurĂ©e Ă l'intĂ©rieur des tolĂ©rances sur les cibles de performance, le gestionnaire en informe le conseil par l'intermĂ©diaire d'un rapport d'exception. Ce dernier dĂ©cide de la suite du projet, incluant la redĂ©finition de la planification en un plan d'exception pour la sĂ©quence suivante et pour le reste du projet d'une façon gĂ©nĂ©rale aprĂšs reconsidĂ©ration de la raison d'affaire.
(MP) GĂ©rer la livraison du produit (LP)
(MP) - GĂ©rer la livraison du produit (LP) est le cĆur de l'exĂ©cution du projet. Les exĂ©cutants, ou leur chef d'Ă©quipe si la taille le justifie, discutent et agrĂ©ent les lots de travaux en provenance du gestionnaire de projet, l'informent de la progression et lui retournent les produits finis, qu'il agrĂ©e Ă son tour. Un lot de travaux est dĂ©fini par la description des produits Ă rĂ©aliser (aussi appelĂ©s « livrables ») et les contraintes de performance, essentiellement les coĂ»t, durĂ©e et qualitĂ©. Les tests et contrĂŽles qualitĂ© sont effectuĂ©s avant la remise des produits au gestionnaire.
(SB) Gérer une limite de séquence (LS)
(SB) - GĂ©rer une limite de sĂ©quence (LS) peut ĂȘtre vu comme un sous-processus de diriger un projet. GĂ©rer une limite de sĂ©quence permet en effet au Conseil d'Ă©valuer si une sĂ©quence/Ă©tape s'est bien dĂ©roulĂ©e en produisant les rĂ©alisations attendues selon les contraintes de performances ciblĂ©es. Cela se fait en consultant le rapport de fin de sĂ©quence transmis par le gestionnaire de projet accompagnĂ© d'une revue, conduite par ce dernier, de la raison d'affaire et du plan de rĂ©alisation des bĂ©nĂ©fices. Au cours de ce processus, la sĂ©quence suivante est planifiĂ©e et avalisĂ©e par le conseil s'il Ă©value que le projet maintient sa raison d'affaire.
(CP) Clore le projet (CP)
(CP) - Clore le projet (CP). Ce processus s'enclenche Ă la fin de la derniĂšre Ă©tape du plan. La clĂŽture de projet Ă©value les produits au regard des cibles consignĂ©es dans le document d'initiation du projet et archive les expĂ©riences et observations vĂ©cues pour consultation future. C'est le gestionnaire de projet qui, Ă l'issue de ce processus, propose au conseil la clĂŽture du projet en lui remettant le rapport de fin de projet, qui Ă son tour l'entĂ©rine sur la base de son Ă©valuation. La planification pour la rĂ©alisation des bĂ©nĂ©fices est Ă©galement revue par le gestionnaire de projet avant d'ĂȘtre remise au conseil. Les produits sont remis aux clients/utilisateurs et les ressources sont libĂ©rĂ©es. Bien que cela soit Ă©tranger Ă la stricte gestion de projet, PRINCE2 recommande de documenter l'acceptation des produits par les clients Ă cette Ă©tape. PRINCE2 rend obligatoire le processus de clĂŽture mĂȘme en cas d'abandon anticipĂ©. Le gestionnaire de projet doit alors faire l'inventaire de ce que le projet a dĂ©jĂ produit et indiquer clairement Ă quel point dans le dĂ©roulement la clĂŽture a lieu. PRINCE2 distingue 4 activitĂ©s : la prĂ©paration (planifiĂ©e ou avortĂ©e suivant le cas) de la clĂŽture, la remise des produits finis, l'Ă©valuation du projet et enfin la notification de la recommandation de clĂŽture au conseil. Cette sĂ©rie d'activitĂ©s se base sur les documentations du statut de produits, de l'initiation du projet, des trois registres qualitĂ©, Ă©vĂ©nements et risques, et enfin du journal des observations. Elles produisent le rapport de fin de projet ainsi que le rapport des observations pour rĂ©fĂ©rence future.
On peut grouper ces processus en quatre grands ensembles :
- DĂ©marrage (SU)
- Initialisation (IP)
- Exécution (CS, MP, SB)
- ClĂŽture (CP)
Flux de processus
Les processus promus par PRINCE2 pour organiser la gestion de projet s'organisent et se connectent en un flux qui pave le chemin pour l'ensemble des acteurs impliquĂ©s et qui peut ĂȘtre imagĂ© par le scĂ©nario suivant :
Avant le projet, quelqu'un a une idĂ©e d'affaire et donne un mandat Ă une personne de la direction pour l'analyser dans un Ă©ventuel projet et qui en deviendra l'exĂ©cutif : c'est la commande du projet. Cette personne va Ă©laborer ou dĂ©marrer le prĂ©projet dans le processus EP. Elle va nommer un chef de projet qui va effectuer la premiĂšre prĂ©analyse pour dĂ©terminer si l'idĂ©e vaut la peine de mettre en place un projet. L'infrastructure de gestion est nommĂ©e durant ce processus et le conseil de projet est formĂ©, qui assumera son rĂŽle dĂ©sormais dans le cadre du processus diriger un projet (DP). Il est recommandĂ© que les membres du conseil, Ă savoir l'exĂ©cutif, reprĂ©sentants utilisateur et fournisseur, soient identifiĂ©s dans des strates supĂ©rieurs de gestion afin d'ĂȘtre en mesure de mobiliser facilement les ressources nĂ©cessaires. Le gestionnaire de projet va rĂ©aliser certaines activitĂ©s et fournir des Ă©lĂ©ments de rĂ©ponse au conseil, sous la forme d'un brief qui contient notamment une Ă©bauche de la raison d'affaire, l'approche et la dĂ©finition du projet ainsi que les critĂšres d'acceptation du produit final de mĂȘme qu'une requĂȘte pour dĂ©marrer l'initialisation du projet. Sur cette base, le conseil dĂ©cidera souverainement de l'initialisation ou non du projet (IP) qui est le processus-sĂ©quence suivant. Dans l'hypothĂšse positive, le conseil devra valider le plan pour la sĂ©quence/processus d'initialisation prĂ©sentĂ©e par le gestionnaire de projet. C'est aussi durant cette premiĂšre Ă©valuation que les journaux sont ouverts. Durant la sĂ©quence d'initialisation, la raison d'affaire est dĂ©taillĂ©e, les stratĂ©gies de communication, qualitĂ©, gestion de risque et configuration sont posĂ©es de mĂȘme que le plan du projet, divisĂ© en sĂ©quences dont les limites offrent un contrĂŽle au conseil sur son dĂ©roulement. Le gestionnaire prĂ©pare Ă©galement le plan pour la prochaine sĂ©quence et envoie une requĂȘte au conseil pour demander le dĂ©marrage du projet. Par la suite, les sĂ©quences se suivent, sont gĂ©rĂ©es par le gestionnaire de projet qui commande la rĂ©alisation des produits auprĂšs des Ă©quipes techniques au travers de processus de livraison de produits (LP) et qui surveille l'Ă©closion et Ă©volution de risques et problĂšmes. Il reporte rĂ©guliĂšrement au conseil et dĂ©clenche la limite de sĂ©quence (LS) le moment venu. Il rĂ©dige alors un rapport dans lequel le statut des risques est dĂ©taillĂ© qu'il adresse au conseil de mĂȘme qu'une mise Ă jour de la raison d'affaire et d'une revue de la planification de rĂ©alisation des bĂ©nĂ©fices Ă venir. Si le conseil est satisfait, il entĂ©rine le plan pour la prochaine sĂ©quence que le gestionnaire a Ă©galement prĂ©parĂ©. La derniĂšre sĂ©quence correspond au processus de clĂŽture qui voit la remise du rapport de fin de projet au conseil et la livraison des produits. Le rapport de fin de projet consolide Ă©galement les observations qui pourront servir Ă transmettre l'expĂ©rience de gestion acquise Ă de futures initiatives. Dans le cas oĂč, au cours d'une sĂ©quence, le gestionnaire de projet anticipe un dĂ©rapage (dĂ©rive des coĂ»ts, du calendrier, impossibilitĂ© de rĂ©aliser un produit selon les standards entendus), il produit un rapport d'exception pour le conseil qui contient une description de la situation, son impact et les options recommandĂ©es. Le conseil peut souhaiter alors la clĂŽture prĂ©maturĂ©e, ce qui enclenche le processus correspondant durant lequel le gestionnaire a la charge de bonifier les rĂ©alisations dĂ©jĂ existantes. Sinon, il commande auprĂšs du gestionnaire un plan de remplacement pour terminer la sĂ©quence mise en exception. Si le plan du projet est Ă©galement retouchĂ©, le conseil doit chercher l'approbation de la structure hĂŽte.
DĂ©tail des processus
(SU) - Ălaborer un projet - (EP)
Processus dans lequel le projet est dĂ©fini. On examine s'il est utile. En pratique, c'est une phase courte et rigoureuse oĂč le responsable du projet collabore intensivement avec le commanditaire. Le projet est commandĂ© officiellement et le responsable dĂ©termine alors la composition et l'organisation du projet.
Ce processus consiste en six Ă©tapes :
- (SU1) â Nommer l'exĂ©cutif et le chef de projet (EP1)
- (SU2) â Composer l'Ă©quipe de gestion du projet (EP2)
- (SU3) â Nommer l'Ă©quipe de gestion du projet (EP3)
- (SU4) â PrĂ©parer l'exposĂ© du projet (EP4)
- (SU5) â DĂ©finir l'approche du projet (EP5)
- (SU6) â Planifier la sĂ©quence dâinitialisation (EP6)
(IP) - Initialiser le projet - (IP)
Processus obligatoire dans tout projet PRINCE2. Une réflexion qui permet d'établir de solides bases au projet avant d'agir. On y détermine les résultats escomptés, le planning, les tùches et les responsabilités de chacun. L'étape la plus importante de ce processus est le "document d'initialisation de projet" (PID/DIP).
Ce processus consiste en six Ă©tapes :
- (IP1) â Planifier la qualitĂ© (IP1)
- Détails d'un "plan qualité"
- Harmonisation avec les processus de qualité déjà en place dans l'organisation
- Définir les techniques et les méthodes utilisées
- Qui sont les principaux intéressés ?
- (IP2) â Planifier le projet (IP2)
- (IP3) â Affiner le Cas d'Affaire et les risques (IP3)
- (IP4) â CrĂ©er les contrĂŽles du projet (IP4)
- (IP5) â CrĂ©er les dossiers du projet (IP5)
- (IP6) â Assembler le document dâinitialisation du projet [DIP] (IP6)
(DP) - Diriger un projet - (DP)
- (DP1) â Autoriser l'Initialisation (DP1)
- (DP2) â Autoriser un projet (DP2)
- (DP3) â Autoriser un plan de sĂ©quence ou un plan dâexception (DP3)
- (DP4) â Donner des directives appropriĂ©es (DP4)
- (DP5) â Confirmer la clĂŽture du projet (DP5)
(CS) - ContrÎler une séquence - (CS)
- (CS1) â Autoriser un lot de travaux (CS1)
- (CS2) â Ăvaluer la progression (CS2)
- (CS3) â Collecter les incidences de projet (CS3)
- (CS4) â Analyser les incidences de projet (CS4)
- (CS5) â Examiner l'Ă©tat de la sĂ©quence (CS5)
- (CS6) â Rapporter les points clĂ©s (CS6)
- (CS7) â Mener des actions correctives (CS7)
- (CS8) â RĂ©fĂ©rer des incidences de projet (CS8)
- (CS9) â RĂ©ceptionner un lot de travaux achevĂ© (CS9)
(MP) - GĂ©rer la livraison des produits - (LP)
- (MP1) â Accepter un lot de travaux (LP1)
- (MP2) â ExĂ©cuter un lot de travaux (LP2)
- (MP3) â Livrer un lot de travaux (LP3)
(SB) - Gérer les limites de séquences - (LS)
- (SB1) â Planifier une sĂ©quence (LS1)
- (SB2) â Mettre Ă jour le plan de projet (LS2)
- (SB3) â Mettre Ă jour le Cas d'Affaire (LS3)
- (SB4) â Mettre Ă jour le recueil des risques (LS4)
- (SB5) â Rapporter une fin de sĂ©quence (LS5)
- (SB6) â Produire un plan dâexception (LS6)
DĂ©tail des aspects techniques
Trois techniques sont préconisées mais on peut cependant leur adjoindre d'autres techniques en vigueur dans l'entreprise
Technique Planification Basée sur le Produit
Implique la production de :
- Description de Produit du produit final
- Structures de décomposition du produit (SDP)
- Description de produit
- Diagrammes de flux des produits (DFP)
Technique de MaĂźtrise des Changements
Trois types :
- Demande de changement (ou RFC).
Proposition demandée pour un changement du référentiel d'un produit.
- Hors spécifications.
Quelque chose qui devrait ĂȘtre fourni par le projet mais qui n'est actuellement pas fourni (ou prĂ©vu qu'il ne soit pas fourni). Cela peut ĂȘtre un produit manquant ou qui ne rĂ©unit pas les spĂ©cifications.
- Questions et problĂšmes
Toute question que le gestionnaire de projet doit résoudre ou escalader.
Ces 3 types dâĂ©vĂ©nements concernent uniquement un Ă©vĂ©nement qui est survenu, non planifiĂ© et qui exige une action du gestionnaire.
Certification
Il existe deux types de certification PRINCE2, reconnues dans le monde entier. Ces certificats peuvent se passer l'un aprÚs l'autre trÚs rapidement, suivant les centres de formations agréés. Ces certificats et se définissent ainsi:
Examen PRINCE2 Fondamental
Cet examen vĂ©rifie quâun collaborateur dispose des connaissances nĂ©cessaires pour participer Ă un projet gĂ©rĂ© selon la mĂ©thode PRINCE2. La rĂ©ussite de cet examen et ainsi l'obtention du certificat passe par la maĂźtrise des principes et de la terminologie de la mĂ©thode, et plus prĂ©cisĂ©ment :
- la description des objectifs et des principales tùches des différents rÎles, des sept composantes, des sept processus et de leurs sous-processus, ainsi que des techniques ;
- la citation des documents générés par les différents processus, et la connaissance des processus et documents correspondants ;
- la description de lâobjectif principal et le contenu des documents ;
- l'explication des relations entre les processus, les produits Ă livrer, les rĂŽles et la gestion dâun projet.
Examen PRINCE2 Praticien
Cet examen est la garantie d'une maĂźtrise parfaite de la mĂ©thode PRINCE2 pour gĂ©rer un projet. Le candidat doit avoir rĂ©ussi, auparavant, lâexamen Fondamental et doit ĂȘtre capable dâappliquer et dâadapter les principes de la mĂ©thode PRINCE2 pour anticiper les attentes et Ă©viter ou prĂ©voir les problĂšmes dâun projet donnĂ©. Plus particuliĂšrement, le candidat doit :
- expliquer tous les processus, toutes les composantes et toutes les techniques de maniĂšre dĂ©taillĂ©e et donner des exemples de produits tels quâils pourraient ĂȘtre rĂ©alisĂ©s pour rĂ©pondre aux besoins dâun projet donnĂ© ;
- dĂ©montrer quâil comprend les relations entre les processus, les composantes, les techniques et les produits PRINCE2 et quâil est en mesure de les mettre en Ćuvre ;
- prouver quâil comprend le pourquoi des processus, des composantes et des techniques de PRINCE2 et les principes qui les sous-tendent ;
- dĂ©montrer quâil est capable dâadapter PRINCE2 aux besoins du projet.
(PRINCE2 est une marque déposée de la société Axelos.)
Relation avec d'autres normes et référentiels
Axelos a publiĂ© en 2015 un livre blanc comparant PRINCE2 avec la norme internationale ISO 21500 relative au management de projets adoptĂ©e en 2012, ainsi qu'avec le PMBOK que le PMI a alignĂ© avec la nouvelle norme en 2013[22]. Selon cette analyse PRINCE2 se positionnerait comme une mĂ©thode de management de projet, avec des rĂŽles et responsabilitĂ©s, des processus et des documents de management de projet clairement dĂ©finis, alors que ISO 21500 et PMBOK seraient davantage des cadres de rĂ©fĂ©rence identifiant des processus (et dans le cas du PMBOK des techniques et outils), mais laissant toute latitude quant Ă la maniĂšre de les mettre en Ćuvre en pratique.
D'autres comparaisons accrĂ©ditent la complĂ©mentaritĂ© de PRINCE2 et de PMBOK, dont l'une du PMI[23] confirme le caractĂšre de mĂ©thode prĂȘt Ă l'emploi de PRINCE2, tout en rappelant que la mĂ©thode traite de principes, processus et pratiques mais sans aborder en profondeur l'Ă©ventail plus large de techniques et outils de gestion de projets proposĂ© par le PMBOK.
Notes et références
- Creating value in project management using PRINCE2 (Sargeant R, Hatcher C, Trigunarsyah B, Coffey V, and Kraatz JA), 2010, Report Queensland University of Technology, Brisbane Australia. .
- (en) « Axelos, Capita and the PRINCE2 Joint Venture », sur Advantage Learning UK, (consulté le )
- Passing the PRINCE2(R) 2009 Edition Foundation Exam - A Study Guide (Hedeman, B et al.), 2011. Van Haren Publishing. (ISBN 978 90 8753 622 0).
- Program Management (Rankins GJ), 2006. Information Age .
- PRINCE2 Methodology: An Innovative Technique of Project Management growing progressively across the globe (Saad S, Ibrahim A, Asma O, Khan MS, and Abdul A), Proc. 3rd Int. Conf. Bus. Mgt. Feb. 27-28 2013, Lahor, Pakistan. (ISBN 978-969-9368-07-3). .
- Productâbased planning: the importance of project and project management deliverables in the management of clinical trials (Bryde DJ and Joby R), 2007. R&D Management 37(4) 363-77 .
- PRINCE2 2009 Edition: Quick Reference Card (Portman H and Newton S), 2010. Van Haren Publishing. (ISBN 978-90-8753-565-0). .
- The Essence of the PRINCE2 Project Management Method (Bentley C), Chap. 2 2009. .
- USING PRINCE2 AND ITIL PRACTICES FOR COMPUTING PROJECT AND SERVICE MANAGEMENT IN A SCIENTIFIC INSTALLATION (FernĂĄndez-Carreiras D, Cuni G, Klora J, Martin M, Matilla O, Nardella A, and PĂ©rez A), Proc. 14th Int. Conf. Acc. Large Exp. Phys. Contr. Syst. p. 517-20. Oct. 7-11 2013, San Francisco USA. TUMI01 (ISBN 978-3-95450-139-7). .
- Enhance PMBOKÂź by Comparing it with P2M, ICB, PRINCE2, APM and Scrum Project Management Standards (Ghosh S, Forrest D, DiNetta T, Wolfe B, and Lambert DC), 2012. PM World Today 14(1) .
- Application of Standard Project Management Tools to Research--A Case Study from a Multi-National Clinical Trial (Gist P and Langley D), 2007. J. Res. Admin. 38(2) p. 51-58 .
- Project Management Based on PRINCE2TM-PRINCE2 Edition 2005 (Hedeman B) Chap. 1 2004 Ed. 3. Van Haren Publishing Netherland (ISBN 97890 7721283 7) .
- An Introduction to PRINCE2Âź. (Turley F) 2010. Management Plazza. .
- Project Quality Management Approaches: A Comparative Evaluation of International Standards (Zafarani E), Int. Conf. Constrct. Proj. Mgt, 16-18 Sept. 2011, Singapore. 15, p. 37-43. .
- Methodologies of project management (Macek W), 2010. Contemporary economics 4(4) p. 267-80 .
- Modelling new directions with product-based planning (King V), 29th Higher Education Research Development Society of Australasia Annual Conf. 2006, Perth July 10-12, Australia. .
- Prince2: A methodology of project management (Pincemaille C), Report Cork Institute of Technology 2008, Cork Ireland.
- An enterprise information security model for a micro finance company: a case study (Owen M), PhD diss. Nelson Mandela Metropolitan University 2009, Port Elizabeth, South Africa.
- The irrelevance of project management as a professional discipline (Morris P), 17th World Congress on Project Management 2003, Moscow June 4-6, Russia.
- How PRINCE2 can complement PMBOK and your PMP (Siegelaub, JM), Proc. PMI Global Congress 2004, Anaheim USA. .
- In search for IT Project Management Performance Improvement at CSPY: combining PRINCE2 with Information Architecture elements (Brouwer, R), Master 2007, University of Amsterdam, Netherland. .
- (en) « PRINCE2Ÿ, the PMBOKŸ Guide and ISO 21500:2012 », sur AXELOS (consulté le )
- (en) « Project Management Methodology Knowledge », sur www.pmi.org (consulté le )
Voir aussi
Articles connexes
- Gestion de projets
- P3M3, gestion de portefeuilles de projets
- ISO 21500 - Lignes directrices sur le management de projet (norme internationale)