Lorsqu’on recherche une méthode de gestion de projet en phase avec l’excellence opérationnelle, nous avons le choix entre deux solutions innovantes :
- Les méthodes agiles plébiscitées par le monde de l’édition de logiciel
- Et le CCPM (Critical Chain Project Management), la gestion de projet par la chaine critique dont les plus grands fans sont les inconditionnels de la théorie des contraintes
Si on retrouve quelques similitudes dans les deux approches, globalement les deux approches sont diamétralement opposées.
En quoi les deux approches sont fondamentalement opposées…
Cette opposition est issue du fait que les méthodes agiles remettent totalement en cause le cycle traditionnel d’un projet (Cycle en V), en préconisant de découper le projet en sous-projets appelés sprint.
Alors que dans le CCPM, Goldratt ne remet aucunement en cause le cycle traditionnel. Simplement, il utilise les buffers pour gérer la contrainte de ressource sur le chemin critique du projet.
A titre personnel, ayant constaté les dégâts désastreux que pouvait entrainer un cycle en V (retard de plusieurs mois dans l’intégration d’un ERP avec un décalage complet entre la solution implantée et le besoin client), j’étais a priori plus enclin à favoriser l’approche des méthodes agiles…
Jusqu’au jour où…
Jusqu’au jour où j’ai pris conscience que les méthodes agiles reposaient sur un pré requis INDISPENSABLE… La possibilité de faire des tests en continu !
Eh oui, comme la conduite du projet se fait par la décomposition du projet en sous projets, cela signifie qu’a minima il faut faire un test à chaque fin de sprint pour s’assurer que le programme fonctionne bien avant livraison au client.
Précisons bien que ce test en fin de sprint est un minimum, car dans la réalité, les tests se réalisent à l’intégration de chaque nouvelle fonctionnalité… Ainsi, un sprint fait déjà l’objet d’une multitude de tests…
Mais en quoi est-ce que les tests viennent remettre en cause le choix du mode de gestion de projet…?
Effectivement, on peut imaginer que chaque projet fasse l’objet d’un test avant livraison et recette… Mais dans certains cas, la phase de prototypage, les simulations, les tests… sont incroyablement coûteux !
Prenons l’exemple de la conception d’un semi-conducteur… La réalisation d’un échantillon peut coûter plusieurs centaines de milliers d’euros ! Dans ce cas, comment imaginer lancer la conception, tester, revoir la conception, tester de nouveau…etc.
Voilà pourquoi la souplesse du test constitue un critère essentiel dans le choix de la méthode de gestion de projet. Si le cycle traditionnel s’impose, alors la gestion de projet par la chaine critique pourra être privilégiée.
En revanche dans le cas d’un développement informatique où l’automatisation des tests est aisée, les méthodes agiles type scrum ou XP seront plus adéquat.
Dans tous les cas, il est préférable de maitriser les deux méthodes pour utiliser au mieux celle qui s’avère la plus adaptée à la problématique de gestion de projet à laquelle nous devons répondre. Par exemple, il peut tout a fait être envisageable de prévoir un avancement par sprint à l’intérieur d’une gestion globale par CCPM !
Et vous quelle méthode privilégiez-vous pour quelle typologie de projet ? ;-D
Demain je vous dévoilerai l’étape 0 de la TOC dont Goldratt n’a jamais parlé… Alors, restez connectés ! 😉