Comme beaucoup d’entreprises ou de services, vous avez peut-être mis au point et systématisé votre méthodologie interne de conduite de projet. Votre référentiel méthodologique est devenu la véritable colonne vertébrale pour la conduite de vos projets avec son cycle de vie standard, ses phases, ses jalons, sa gouvernance, ses livrables. Il est un élément essentiel au bon fonctionnement de vos projets mais répond-il à tous les contextes projet? Peut-être est-il temps de lui apporter un peu de flexibilité et d’agilité?
Intégrer de l’agilité : est-ce la fin des référentiels méthodologiques projets traditionnels ?
La question devient donc : comment intégrer de l’agilité dans ma méthodologie projet tout en capitalisant sur les acquis et en conservant le cycle de vie procédural / traditionnel / waterfall ?
Le constat : les référentiels classiques, ça marche encore souvent, mais plus tout le temps
« Mes projets ne rentrent plus dans les cases ! » : c’est la remarque que font beaucoup de PMO et de chefs de projet…
En effet, les référentiels méthodologiques « maison » ont été créé pour rationaliser et homogénéiser les cycles de vie des projets avec une approche procédurale (dite aussi waterfall ou cycle en V… ). Ils sont basés sur le principe d’un déroulement unique ou chaque phase crante sur des livrables et des décisions (GO / NO GO)
Il est clair qu’ils constituent un élément clé de la performance des projets : partager une même grammaire et un même vocabulaire projet pour toute l’organisation, tout le monde y gagne car chacun comprend les tâches à réaliser pour chaque phase, les rôles et responsabilités, les livrables à produire, les décisions à prendre…
Ces référentiels méthodologiques classiques, j’allais dire « historique » : ça fonctionne encore très bien
En effet, la plupart des projets restent encore parfaitement à l’aise avec une approche procédurale avec 4, 5 ou 6 phases qui s’enchaînent : projets industriels, projets d’ingénierie évidemment … mais aussi certains projets de systèmes d’information.
Il faut donc absolument garder cet acquis de la logique traditionnelle !
Le cycle de vie projet traditionnel ne représente plus vraiment la réalité de certains projets
Que constate-t-on quand ça ne « ne rentrent plus dans les cases » ? Simplement que la réalité des projets évolue car il faut aller plus vite en délivrant plus rapidement certains lots ou pouvoir s’adapter au contexte en réalisant le projet par incrément, sans avoir tout spécifié dès le départ.
Pour répondre à ce besoin croissant de souplesse et d’agilité, le système de phases classiques et de jalons standards ne fonctionne plus très bien.
Quelques exemples de scénarios que la plupart d’entre vous rencontrent (non exhaustif !)
- Des projets réalisés et/ou déployés par lots : on n’a donc qu’un seul phasage projet mais de nombreuses phases différentes en parallèle pour chaque lot. C'est le cas de projet dont les lots suivent chacun toute ou partie des phases types (conception, réalisation, validation …)
- Des gros projets qui sont en fait des programmes (on remonte d’un cran), qui sont constitués de projets et qui nécessitent une gouvernance unique mais avec des phases « tuilées » en fonction des projets. C'est le cas des projets dont les parties suivent les phases types (conception, réalisation, validation …) mutualisées ou non.
- Des projets qui intègrent toute ou partie de leur conception / exécution en mode agile ou en mode hybride (agile + traditionnel. Je vous invite d’ailleurs à lire l’excellent billet du blog sur le mode Wagile. C'est le cas des projets mixant des approches agiles et traditionnelles sur un ou plusieurs lots.
L’enjeu est donc de capitaliser sur les acquis du référentiel projet traditionnel tout y apportant des modalités pour embarquer de l’agilité.
Ajouter de l’agilité à votre référentiel : comment faire ?
Back to the basics : revenons aux fondamentaux sur le jalonnement. Le jalonnement est reconnu comme un élément fondamental du pilotage de projet : marquer des point d’arrêts à des moments clés du projet pour :
- analyser / valider les livrables réalisés dans la phase précédente,
- faire un point sur les coûts, les délais à date et réévaluer la trajectoire prévue en ajustant éventuellement le plan initial,
- prendre la décision de lancer la phase suivante.
Comme nous le savons tous, en mode procédural traditionnel les moments clés pour les jalons sont positionnés en fins de phases (on peut aussi ajouter des jalons complémentaires). Si l’on fait le parallèle avec la méthode SCRUM en mode agile, le jalonnement virtuel correspond au tempo de chaque SCRUM.
Dans les situations plus complexes, dites « hybrides », quand les approches traditionnelles et agiles se mêlent et où les phases se chevauchent, une très bonne approche est de garder / renforcer la notion de jalon, tout en passant en second plan la notion de phases.
Les jalons en méthodologie « hybride » : que demander aux chefs de projet ?
2 principes sont à appliquer :
Principe 1 : consolider les jalons de lancement et de fin de projet
Quelques que soit les types de projets, ces jalons doivent rester « standards » et donc obligatoires et normés. En effet ils restent cruciaux pour :
- sécuriser le lancement du projet en particulier au travers de la formalisation des différents documents comme le business case, le Plan de Management de Projet… qui définissent le « pourquoi » le projet, c’est « quoi » le projet et « comment » on va mener le projet,
- systématiser les jalons standards de fin de projet pour pouvoir cadrer et mesurer les coûts/qualité/délais à terminaison, faire le bilan du projet et assurer les conditions de sortie du portefeuille des projets.
Un pilotage de et des « jalons de contrôle » flexibles dépendant de la stratégie de réalisation du projet
Principe 2 : mettre en place des jalons de « contrôle » ad hoc
Ces jalons seront positionnés par le chef de projet en fonction de la stratégie qu’il propose pour la réalisation de son projet. Ainsi, ces jalons de contrôle peuvent tout à fait se caler en fin de phase classique si cela fait sens pour tout ou partie du projet : par exemple la fin de conception ou la fin de recette/validation … pour un lot, etc.
Ces jalons de contrôle peuvent aussi et surtout se positionner à tout autre moment clé du projet : par exemple quand il est prévu d’avoir utilisé 50% du budget pour un lot en mode agile (burndown chart), ou la date prévue pour la mise en production un premier lot …
Concernant la définition de ces jalons c’est au chef de projet de l’expliciter au lancement du projet. Ainsi il va annoncer à l’avance, pour chacun des jalons de contrôle qu’il propose, la liste des livrables ou les événements significatifs attendus, le coût correspondant et la date prévue pour le passage du jalon.
Tout au long du projet, il sera dès lors possible de comparer la trajectoire prévue avec la trajectoire réalisée, ceci pour les coûts, les délais et les livrables.
Cette approche simple et efficace permet à la gouvernance du projet et du portefeuille, d’avoir une bonne vision des prévisions et un bon contrôle sur l’avancement, quel que soit la nature des projets
Conclusion : oui, on peut profiter du meilleur des 2 mondes
Avec ce type de référentiel qui mixe des « jalons standards » et des « jalons de contrôle » adaptés à chaque projet, on cumule les avantages :
- on capitalise sur la culture projet de l’entreprise, en particulier sur les modalités de préparation et de lancement des projets. En effet, les phases amont restent inchangées (opportunité, étude/ faisabilité…).
- on renforce l’engagement et la responsabilisation du chef de projet. Il doit préparer de manière soignée son plan projet pour choisir les meilleurs jalons de contrôle et définir la trajectoire coût qualité délai.
- on dispose d’un système qui s’adapte à tout type de situation projet tout en restant simple et homogène dans sa gouvernance.
Merci par avance pour vos réactions et questions. J’aurai le plaisir de vous répondre et de vous donner quelques bonnes pratiques opérationnelles sur le mode « hybride » dans un prochain billet .
