Poulpy, le retour (et il n’est pas content)

Parlons pipeline projet.

Dans l’article précédent, nous avions vu l’intérêt de Poulpy* dans une logique de Focus & Finish d’un projet.

Nous avions d’ailleurs pris l’exemple d’un client ayant souhaité utiliser cette approche pour un de ses projets. Qui était critique par rapport aux autres projets en cours.

Pour expliciter quelques éléments de contexte supplémentaire, nous parlons d’un projet d’implémentation d’un ERP. Il se trouve que pour cette (très grande) société, installer un ERP n’est pas un projet mais une somme de projets plus ou moins interconnectés entre eux.

Dans le contexte initial de la demande, il s’agissait de récupérer un projet le plus vite possible. Car avant même d’avoir débuté, les délais semblaient intenables.

C’est ainsi que nous avions mis en œuvre Poulpy sur la chaîne critique de ce projet. Mais voilà ce qu’il s’est passé ensuite :

fever chart

Frustrant, n’est-ce pas ? Comme vous pouvez le constatez le projet est allé très vite, plus que de raison. Et aujourd’hui, il attend… un autre projet en cours dans le portefeuille.

Lorsque la chaîne critique a été développée dans les année 90, il s’agissait d’abord d’une méthode centrée sur un projet ou des environnements « somme de mono projets » ; plusieurs projets faits en parallèle par des équipes dédiées. Toutefois, les environnements actuels sont plutôt des organisations multi projets. C’est-à-dire qu’une même ressource peut se retrouver sur plusieurs projets en même temps. Et pas nécessairement avec la même équipe.

Pour revenir à notre exemple. Il faut imaginer un en-cours de projet (comme un en-cours atelier) avec un ensemble de tâches (ou de composants) réparties à différents endroits du flux (éparpillés dans un atelier). Dans les ateliers, quand nous sommes confrontés à un en-cours trop important, l’action que nous avons tendance à réaliser est de réduire cet en-cours. Afin de réduire les files d’attentes et donc de diminuer les cycles d’exécution.

Il en va de même pour une organisation projet, à ceci près que le flux n’est pas physique. Ce qui le rend plus difficile à identifier.

C’est là où l’intérêt du pipeline associé à de bonnes règles de gestion en flux tiré peut servir :

pipeline projet

Le pipeline consiste à identifier les projets en cours et à élaborer des règles pour contrôler cet en-cours… Et éviter la noyade des équipes entre le multitâche et le multi-projet. Un des enjeux de cette phase est de correctement définir les règles de gestion et de sauter le pas dans leurs respects.

En conclusion, on peut dire que Poulpy est un élément clé du dispositif d’un flux de projet rapide. Toutefois, dans un environnement multi-projet, il convient d’avoir des règles de gestion correctement définies pour contrôler l’en-cours et laisser Poulpy naviguer en eaux claires.

* Nous avons ici opté pour Poulpy, le poulpe d’Avène, mais vous pouvez choisir la mascotte qui vous convient le mieux !