En quoi un Programme est-il différent d’un Portefeuille de Projets ou d’un gros Projet avec des sous-projets ?
L’objet de cet article est de clarifier le concept de Programme en s’appuyant sur les définitions du PMI ou de l’OGC.
Définitions
| Projet | Entreprise temporaire, décidée en but de produire un résultat, produit ou service unique. |
| Programme | Groupe de projets en rapport les uns avec les autres, gérés de manière coordonnée afin d’obtenir des gains et un contrôle supérieurs à ce qu’on aurait en les gérant indépendamment les uns des autres. |
| Portefeuille | Ensemble de projets et de programmes qui sont regroupés afin de faciliter une gestion efficace dans l’atteinte des objectifs stratégiques. |
Définitions du PMI librement traduites
Différences Programme vs Gros Projet avec des sous-projets
Dans un projet avec des sous-projets, les liens entre les sous-projets sont plus forts que les liens entre les projets d’un programme. Notamment, dans un gros projet, chaque sous-projet ne peut exister en dehors de l’ensemble. Dans un programme, on peut imaginer que des projets puissent continuer même si le programme est remis en cause.
Concrètement, dans un programme, chaque projet a son propre Business Case, c.-à-d. sa propre justification. Dans le gros projet, il n’y a qu’un seul Business Case et les sous-projets sont créés afin de faciliter la gestion d’un projet très complexe.
Le programme a aussi son propre Business Case qui explicite les gains générés au niveau du programme et justifie la création de cette couche de management supplémentaire.
Différences Programme vs Portefeuille
Un portefeuille rassemble des projets qui n’ont pas forcément de rapport entre eux. Dans un programme, c’est justement le rapport existant – ou possible – entre les projets qui est la raison d’être du programme.
Le terme rapport est volontairement assez vague pour couvrir des situations diverses.
L’exemple évident de rapport entre les projets est la notion d’interdépendance (ex: le projet A utilise un résultat du projet B). Dans ce cas, le programme permet de renforcer le contrôle par une meilleure coordination entre les projets.
Mais un programme permet aussi de créer de nouveaux liens entre les projets afin de générer des bénéfices supplémentaires. Un programme permet de créer de nouvelles opportunités.
Par exemple, en réunissant plusieurs projets au sein d’un programme, on peut générer des offres combinées à plus grande valeur ajoutée. Sans programme, l’offre combinée risque de ressembler à un patchwork sans homogénéité.
De plus, la bonne coordination de plusieurs projets peut générer une valeur supplémentaire, par exemple en créant un effet d’annonce grâce à la sortie simultanée de plusieurs produits.
Enfin, le programme est aussi une source d’économies (par ex: passage d’appels d’offres plus importants, développements de composants réutilisables sur plusieurs projets, mutualisation des coûts publicitaires ou de communication etc.).
Le portefeuille et le programme ont des vocations très différentes. Le portefeuille est un outil de pilotage managérial. De son côté, le programme apporte une valeur business supplémentaire en plus d’être un outil de pilotage.
Quelles sont les techniques spécifiques de la gestion de programme ?
Il n’y en a pas vraiment car la gestion d’un programme empreinte tour à tour les techniques de la gestion de portefeuille de projets (alignement stratégique, sélection des projets, optimisation des ressources etc.) et toutes celles de la gestion de projets (risques, coûts, délais, qualités, communication etc.).
Les processus spécifiques à la gestion de programme sont:
- ceux qui concernent l’initialisation du programme et la mise en place de la structure de management
- ceux liés à la gestion des gains stratégiques (Benefits Management)
La gestion des gains stratégiques est sans doute l’élément le plus spécifique car c’est la raison d’être du programme.
Le programme se situe à cheval entre le portefeuille de projets et le gros projet. C’est pourquoi la frontière est souvent floue. Nous espérons que cet article vous aura apporté un nouvel éclairage. N’hésitez pas à nous laisser vos commentaires.
PS: Cet article a été écrit suite à la participation à la formation «Best Pratices in Program Management» de PMGS.
PPM Consultant
Bonjour
merci Renaud pour cette vision de synthèse que je partage pour l’essentiel. J’irai un cran plus loin sur les « benefits » : j’ai l’impression que la gestion des benefits, même si elle est présentée comme spécifique par le PMI, devrait en réalité être partagée par l’ensemble des strates portfolio et project. En effet, pourquoi faire un projet si on n’identifie pas les bénéfices attendus ? Idem dans les méthodes agiles : on séléctionne les fonctions prioritaires en fonction de leur valeur apportée (encore une notion de benefits). Idem en gestion de portefeuille de projet : on va en priorité lancer les projets apportant le plus de bénéfices et tenter de définir un portefeuille permettant de répartir la réalisation des bénéfices régulièrement.
Je dirais que la partie Gestion des Parties Prenantes est sans doute l’une des complexités de la gestion de programme (même si elle ne lui est pas spécifique) puisque plus ce que l’on gère est important, plus il y a d’acteurs, de parties intéressées / impactées… et plus cela devient complexe à gérer.
Merci en tous cas à Michel et à PMGS pour cette formation qui a réuni dix participants et un formateur intéressant !
Stratification et focalisation
Jean a écrit: « j’ai l’impression que la gestion des benefits, même si elle est présentée comme spécifique par le PMI, devrait en réalité être partagée par l’ensemble des strates portfolio et project ». Oui et non: le programme doit définir et « prouver » les benefits. Comme composant d’un portefeuille, la justification du programme doit s’accorder à « l’intention stratégique » de ce portefeuille. Le composants du programme (en particulier les projets) doivent démontrer leur contribution à atteindre les bienfaits du programme: les projets créent des « livrables » et c’est le travail du programme pour en tirer les bienfaits. À chaque strate donc sa spécificité.
Par contre, comme l’explique la formation PMGS, les techniques de gestion des portefeuilles peut et doit être appliquée dans le management des programmes pour optimiser le découpage et execution des composants.
Merci à Kik pour cette précision. (Kik est le concepteur de la formation de PMGS sur la gestion de programme).
J’avoue que j’avais un peu la même interrogation que Jean.
Autorisation de reproduction de votre schéma
Bonjour,
Je tiens un blog sur la gestion des partenariats associations – entreprises. Votre article est intéressant dans le cadre de mes articles et je souhaiterais obtenir l’autorisation de réutiliser votre schéma dans un article où je tenterais d’appliquer ce que vous évoquez à la gestion de projets associatifs.
Pourriez-vous me répondre par mail ?
D’avance merci,
Bien cordialement,
Merci!
Ce cour a apporté plus de lumière à mes cours de classe
Merci pour ces distinctions très éclairantes.
j’utiliserai cela pour animer des sessions de défintion de contenu de portefeuilles et programmes.
merci encore