Poulpy, le retour (et il n'est pas content)
15-01-2020
  • Blog

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 étaient critiques 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 :

 

 

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’est d’abord agi 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 multiprojets. 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 :

 

 

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 multiprojet. 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 multiprojet, 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 !

Recevez notre newsletter

Afin de vous offrir la meilleure expérience de navigation sur ce site, nous utilisons des cookies. Ces cookies nous servent uniquement à retenir la langue (français ou anglais) dans laquelle vous souhaitez voir le site s’afficher.
In order to provide you with the best browsing experience, we use cookies. These cookies are only used to remember the language (French or English) in which you wish to display the website. By continuing on this site, you agree to their use.