Le contexte projet

PMBOK vs. PRINCE2 : Des Rivaux Complémentaires

Prince2 PMBOK

Quand on aborde la gestion de projet, on pense généralement aux deux certifications les plus connues que sont celles du PMBOK et de PRINCE2. Le passage d’une certification en management de projet est, pour beaucoup, synonyme de meilleure « recrutabilité » et leur assure une base solide pour exercer leur rôle de chef de projet. Aussi, avant de se lancer dans une démarche de certification, est-il nécessaire de peser les bénéfices de chacune, en fonction du contexte professionnel que vous souhaitez atteindre.

Sur les petits projets, un Business Analyst peut également être amené à coiffer la double casquette de chef de projet MOA (=chef de projet fonctionnel, chef de projet maîtrise d’ouvrage). Et, de manière plus globale, la capacité du Business Analyst a exercer sa discipline en toute connaissance du contexte projet est fondamentale. Travailler sur des projets gérés en V, en cascade, en spirale, ou agiles est en effet très différent.

Dans cet article écrit il y a quelques années mais encore très pertinent lorsqu’il s’agit de gestion de projets traditionnels, Thibault Trintignac fait le point sur ce qui rassemble et divise les deux certifications phare de gestion de projet : PMBOK et Prince2.

PMBOK vs. PRINCE2: les deux principales certifications en gestion de projet

Un projet a pour but de permettre, ou de mettre en œuvre une stratégie d’entreprise, afin que celle-ci puisse suivre, et s’adapter à son environnement changeant. Or, l’étude du Gartner Group évalue qu’un projet sur deux échoue, ou ne réalise pas les objectifs qui le justifiaient. Le Standish Group, quant à lui, évalue que 80% des projets ne réalisent pas les objectifs, ou ne respectent pas les délais fixés.

(Note de BestOfBusinessAnalyst.fr: Le Standish Group Chaos Report de 2015, fait tomber cette statistique effarante à 71%, mais elle n’est reste pas moins dramatiquement élevée et inacceptable).

>> Lire aussiPourquoi 83% des projets informatiques échouent-ils?

Ces deux études montrent qu’une grande partie des projets ne répondent pas aux attentes qui les motivaient. Ces causes d’échecs sont nombreuses, mais deux d’entre elles ont été les plus souvent citées:

A ce jour, deux grands modèles de gestion de projet sont internationalement reconnus, en termes de volume de certifications délivrées : PRINCE2® et PMBOK® Guide.

 

Le PMBOK: les standards de la gestion de projet

Le PMBOK® Guide, est édité par le « Project Management Institute » (PMI), une association professionnelle fondée en 1969 regroupant plus d’un million de membres, à travers 185 pays. Le premier volume de ce standard américain fut réalisé en 1987 ; sa première édition fut publiée en 1996, et c’est la sixième édition qui, au jour où est publié cet article, est actuellement mis en pratique. 

Ce guide est basé sur des principes de planifications et de découpage en lots d’activités (tâches) à réaliser pour la bonne marche d’un projet. Il s’appuie sur de nombreuses approches, telles que le PERT, ou le Gantt, et se veut être un reflet des meilleures pratiques en gestion de projet.

Le PMBOK® Guide décrit la gestion de projet à travers 42 processus : ils sont classés en 5 groupes chronologiques de processus (initiation, planification, exécution, contrôle, clôture), et 9 domaines de connaissances (intégration, périmètre, délais, coûts, qualité, ressources humaines, communication, risques, approvisionnements).

 

La méthodologie PRINCE: la référence pour la gestion de projets informatiques

La méthodologie PRINCE a été créée, quant à elle, en 1989 au Royaume-Uni, par la Central Computer and Telecommunications Agency (CCTA), en tant que norme pour les projets informatiques. L’agence fut rebaptisée l’Office of Government Commerce (OGC), connue aujourd’hui comme le « Cabinet Office ».

Le cabinet édite aujourd’hui d’autres méthodologies telles qu’ITIL® (IT service management), M_o_R® (Management du risque) etc.

PRINCE signifie PRrojects IN Controlled Environments. Son ancêtre est PROMPT. Il fut l’un des premiers manuels édités et spécialisés dans la gestion des projets informatiques.

Le chiffre « 2 » se rapporte à la deuxième version de la méthode, lancée en octobre 1996. Cette nouvelle version fut réorientée vers une approche des meilleures pratiques, utilisable dans tous types de projets.

PRINCE2® propose à travers 40 activités, une méthode structurée de gestion de projet. Celle-ci est traduite à travers 8 processus de management de projet (diriger un projet, démarrer un projet, lancer un projet, planifier, gérer la production, contrôler une phase, gérer le passage entre phases, clôturer).

Ces processus sont regroupables en 4 phases (démarrage, initialisation, exécution, clôture), 8 éléments d’application (Plan d’Affaire, organisation, plans, contrôles, management du risque, qualité dans l’environnement projet, management de la configuration, contrôle des modifications) et 3 techniques spécifiques dans la gestion de projet (planification du produit : « Project based planning » ; contrôle des modifications : « Change Control » ; revues qualité « Quality Review »).

 

Des principes similaires, des approches différentes

Ces deux référentiels sont basés sur des principes similaires, eux-mêmes construits autour de processus (hors processus d’initialisation d’un projet, dans PRINCE2®) et de domaines de connaissances comparables (hors fonction achat, couverte uniquement dans le PMBOK®), mais faisant appel à des terminologies, des techniques, et des approches de gestion différentes.

Par exemple, PRINCE2® définit le temps, les coûts, la qualité, la portée, les avantages et les risques d’un projet comme des variables. PMBOK® utilise également ces éléments, mais les appelle « des contraintes ».

P2 PMBOK fig1

Deux définitions du projet

Le PMBOK® Guide définit un projet comme étant « une entreprise temporaire pour créer un produit, service ou un résultat unique » .

De son côté, PRINCE2® définit la notion de projet comme étant « une forme d’organisation temporaire qui est mise sur pied dans le but de livrer un ou plusieurs produits d’entreprise suivant un cas d’affaire (Business Case) spécifique ».

Cette notion de « Business Case » est l’élément clé du projet. C’est ce qui justifie son existence, et maintient sa validité. Il est défini dans le processus d’initialisation du projet (SU), non couvert par le PMBOK®.

 

Business Case vs Project Charter

Le « business case » sera actualisé tout au long du projet : à chaque phase terminée, il est adapté. Cette adaptation mène à une réévaluation du projet qui permettra de vérifier si le projet a toujours un sens, et donc, si celui-ci doit être poursuivi ou non.

>> Lire aussiEst-ce au Business Analyst de rédiger le Business Case?

La définition du « Business Case » aboutira au processus d’initiation du projet (IP), qui produira le « document d’initialisation du projet » (PID).

Ce document est considéré comme stable. Il est destiné à définir toutes les réponses aux questions: quoi, pourquoi, qui, quand et le comment du projet. Il est le document de base sur lequel le Comité de pilotage du projet évaluera les progrès accomplis, les problèmes rencontrés, et le suivi de la viabilité du projet.

La similitude au PMBOK® pourrait être le « Project Charter » qui est un résultat du processus d’initialisation du projet. Le guide définit le « Project Charter » comme «un document délivré par la direction générale qui autorisera formellement l’existence du projet. Il sera donné au chef de projet dudit projet, le pouvoir d’utiliser les ressources organisationnelles pour les différentes activités du projet ».

 

L’organisation d’un projet

PRINCE2® décrit une organisation de gestion de projet composée de quatre niveaux parallèles :

  • La direction générale : le « Corporate or Programme Management » qui fournit l’orientation générale du projet.
  • Le comité directeur du projet, également appelé Comité de pilotage, ou encore le groupe de gestion : le « Project Board », qui est responsable de la réussite du projet. Il en est le mandataire, et dispose de l’autorité nécessaire à la bonne marche du projet. Ce comité est présidé par « l’Executive », nommé par le « Corporate management ».
  • Le chef de projet (« Project Manager ») qui agit au nom du Project Board, dans les limites qui lui sont fixées : on parlera de « Tolérances ». Celles-ci décrivent les niveaux d’acceptabilité en termes de qualité, de temps, et de coût.
  • Le (ou les) chef(s) d’équipe et l’équipe projet, qui sont en charge de la gestion des livraisons des différents produits.

 

Les rôles et responsabilités

« L’Executive » aura le plus haut niveau de responsabilité dans le projet. Il devra veiller à ce que le projet maintienne son champ d’activité, mais aussi que les risques soient bien identifiés et gérés.

En outre, il veillera à ce que le projet atteigne ses objectifs, et fournisse les résultats attendus. Il représente le client du projet et il est le propriétaire du «Business Case». Plus généralement, son rôle consiste à assurer la direction du projet.

Le chef de projet, est quant à lui « une personne qui obtient l’autorité, et la responsabilité de la gestion du projet au jour-le-jour pour fournir les « produits » attendus, dans les limites convenues avec le Project Board « . Son rôle consiste donc à assurer la maîtrise du projet.

Le guide définit plus simplement le chef de projet : c’est « une personne responsable de la gestion d’un projet. »

Également, il utilise le terme « Sponsor » pour définir le rôle « directeur de projet ». Ce « sponsor » fait partie des « Stakeholders » (parties prenantes). Il est défini comme « l’individu ou le groupe à l’intérieur ou l’extérieur d’un organisme qui fournit toutes les ressources, en espèces ou en nature, pour le déroulement du projet. »

>> Lire aussi5 étapes pour identifier les contributeurs d’un projet

 

Les parties prenantes

Les parties prenantes identifiées dans le Guide, correspondent à la notion de client proposé dans PRINCE2®. Le PMBOK® définit une partie prenante comme une personne, ou une organisation, qui est activement impliquée dans le projet, ou dont les intérêts peuvent être affectés par l’exécution, ou l’achèvement du projet.

Ainsi, outre la distinction en termes de responsabilité du chef de projet, PRINCE2® va plus loin dans la catégorisation des parties prenantes. Il en reconnaît au minimum trois, tous membres du « Project Board »:

  • L’executive : Sponsor d’affaires qui commande le projet, et offre les ressources financières
  • Les utilisateurs, qui sont les personnes qui utiliseront le produit une fois qu’il sera terminé
  • Les fournisseurs, qui offriront l’expertise, la technique et les ressources nécessaires pour le projet

 

L’organisation générale du projet

En termes d’organisation générale du projet, PRINCE2® insiste sur les rôles de chacun, et leur maillage à travers le RACI décrivant clairement les limites d’actions, et les responsabilités de chacun. En revanche contrairement au PMBOK®, PRINCE2® ne donne aucune information de gestion des ressources humaines.

En effet, le PMBOK® consacre un domaine entier à ce sujet, où il développe les principes de constitution de l’équipe projet, son développement, et sa gestion au quotidien.

Dans ce sens, PMBOK® met l’accent sur l’utilisation des compétences non techniques de l’équipe, dans le but de réduire les conflits, et accroître la coopération : PMBOK® insiste sur l’importante notion de leadership afin d’assurer le succès d’un projet.

 

Planification produit et organisation des taches

Les deux manuels proposent chacun une technique de gestion de projet différente :

  • La planification basée sur le produit, ou encore « l’arborescence produit » (PBS – Product-Based Planning) pour PRINCE2®.
  • L’organigramme des tâches, appelé également « organigramme technique » (WBS – WorkBreakdown Structure) pour PMBOK®.

 

La planification basée sur le produit

La planification basée sur le produit est une technique de décomposition cohérente et organisée du produit final, à réaliser par le projet, en produits, et sous-produits dits « simples », « intermédiaires » et « de qualité ». Ces derniers sont généralement associés à des documents.

Cette technique sera réalisée en trois étapes :

  • La production d’une structure de décomposition de produit
  • La description de chaque produit et sous-produit
  • La production d’un diagramme de flux de produit. Ce dernier élément a pour but de présenter l’ordre de préséance des produits

Cette technique a pour intérêt de décomposer les différents produits en des éléments gérables, permettant d’identifier les ressources (délais, personnes, coûts, …etc) nécessaires à leur élaboration, les responsabilités correspondantes, et toutes leurs interfaces.

Le diagramme permettra notamment de faire ressortir les niveaux d’intégration de chaque sous-produit, et d’aider à la mise en place de la gestion de la documentation « qualité ».

 

L’organigramme des tâches

L’organigramme des tâches est quant à lui une technique de « découpage hiérarchique en livrables spécifiques des travaux devant être exécutés par l’équipe ».

Chaque tâche est décrite à travers une fiche de tâche (Work Package). Cette décomposition permettra à la fois d’approfondir la portée du projet, et de le découper en unités de travail gérables.

La méthode WBS

La méthode du WBS est axée sur le/les livrables. Chacun d’eux est décomposé en sous-livrables, jusqu’à l’obtention de tâches suffisamment concrètes pour qu’il soit possible de gérer l’ensemble du projet et d’en assurer le suivi de manière logique et efficace.

P2 PMBOK fig2

La création d’une structure WBS permet donc de diviser le projet en entités uniques plus petites, plus simples à appréhender, à évaluer et à gérer.

Le WBS donne également une représentation exacte et sans aucune ambiguïté du travail à accomplir. A l’inverse, tout travail qui n’est pas envisagé par le WBS n’a pas sa place dans le projet.

L’approche PBS

L’approche PBS permet d’exercer un contrôle à chaque produit et jalon du projet. Pour PRINCE2®, le contrôle est au cœur de la gestion de projet : il est un facteur de diminution du risque d’échec.

Ces contrôles ont pour but de garantir la fourniture des produits, répondant à des critères de qualité définis dans le business case. Ils font office de « checkpoint », pour le déclenchement des phases suivantes. Tous les contrôles et les résultats sont notifiés dans le document de suivi du projet.

Les écarts constatés, si supérieurs à la « tolérance » (variables définies par le « projet board »), sont reportés au project board, qui décidera des mesures à prendre. Celles-ci peuvent être dites « d’urgence », c’est-à-dire, que les coûts et les délais alloués à la phase du produit seront révisés, ou dites de « change control ».

Cette dernière fait référence à un processus de changement maîtrisé qui garantit que les autres processus vont eux, continuer à être maîtrisés : évaluation de l’impact d’un changement d’approche projet, au niveau des processus initialement décrits.

 

Réduire les échecs vs. améliorer les chances de succès d’un projet

À travers son approche des contrôles produits, qui permet l’application du concept de management par exception, PRINCE2® propose une méthode qui vise à améliorer les taux de réussite d’un projet.

En effet, PRINCE2® propose une méthode structurée qui permet de réduire les échecs issus d’une erreur de gestion, de contrôle ou d’utilisation incorrecte d’outils ou de techniques.

Or PRINCE2® ne propose qu’une méthodologie de maîtrise des risques connus, ou déjà identifiés par le passé (notion d’expérience).

PMBOK® vise également à augmenter le taux de réussite d’un projet, mais en proposant l’application de processus, d’outils, de techniques, mais surtout, de bonnes pratiques pour la détection, l’analyse et la planification des réponses au risque.

C’est pourquoi PMBOK® ne garantit pas le succès d’un projet, mais cherche a en améliorer les chances de succès.

 

À retenir à propos de PRINCE2® et PMBOK®

PRINCE2® et PMBOK® sont les deux modèles de gestion de projet les plus connus, et les plus utilisés à travers le monde. Tous deux sont portés par des organismes dépositaires de leur méthodologie ; tous deux revendiquent, sans s’opposer ouvertement, leur supériorité technique.

 

Deux modèles différents, mais pas opposés

Or devoir faire le choix entre ces deux modèles de gestion n’est pas l’approche à adopter. PMBOK® et PRINCE® sont certes différents, mais pas opposés. Au contraire, ils sont complémentaires :

  • PMBOK® est un corpus de connaissances, se focalisant avant tout sur les outils, techniques et meilleures pratiques en matière de management de projet. Il propose un modèle de processus, mais celui-ci n’est pas aussi détaillé que dans PRINCE2®

  • PRINCE2® est une méthodologie qui met l’accent sur les processus à suivre pour gérer un projet.

 

Les limites des modèles

Toutefois, ces deux modèles présentent des limites. Le principe des deux méthodes est de cadrer le projet, donc d’avoir une gestion de projet séquencée.

Or, certes adaptable, cette approche par séquence ne laisse pas de place à l’agilité, flexibilité qui pourrait être utile au projet : avoir une approche plus exploratrice du projet, telle que la méthode SCRUM® le permettrait.

Également, aucun des deux modèles ne prend en compte le cycle de vie de l’équipe projet. Certes, PMBOK® insiste sur le management des ressources humaines, la notion de leadership, etc… ; PRINCE® insiste pour sa part sur le côté organisationnel du projet, description et responsabilités des rôles classiques, et spéciaux.

Mais aucun n’aborde le principe de cohésion d’équipe (cycle de Tuckman) : prise en compte des valeurs de « l’homme », intégration d’un individu dans l’équipe, liens sociaux et professionnels de l’équipe, …etc

En effet, la bonne cohésion de l’équipe est également un facteur de succès du projet : l’intégration d’une ressource, certes compétente, mais susceptible de devenir une source de conflit, doit être considérée comme un risque potentiel d’échec.

Mais gageons que les prochaines mises à jour de ces modèles sauront s’enrichir de ces notions complémentaires!

Note de Best Of Business Analyst : le PMI et Prince2 se sont, depuis l’écriture de cet article, tous deux dotés d’une certification de gestion de projet agile, complétant les certifications traditionnelles décrites ici.

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

Share on facebook
Share on twitter
Share on linkedin
Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *