Un projet IT qui derive, c’est rarement une surprise. Les signaux sont la depuis des semaines : les reunions de suivi deviennent des seances de justification, les jalons reculent, les specs changent en silence.
Pourtant, dans la plupart des organisations, on attend que la situation devienne critique avant d’agir. Le cout de l’inaction est toujours plus eleve que celui de l’intervention precoce.
Etape 1 – Poser un diagnostic objectif
- Avant toute action corrective, il faut comprendre ou en est reellement le projet. Pas avec les slides du dernier COPIL, mais avec les faits : livrables produits, ecarts vs plan initial, dette technique accumulee, moral des equipes.
- Nous utilisons une grille de diagnostic en 20 points qui couvre la gouvernance, la technique, le fonctionnel et l’humain. En 48h, le tableau est clair.
Etape 2 – Identifier les causes racines
Un projet ne derive jamais pour une seule raison. Les causes les plus frequentes que nous observons en mission : absence de product owner legitime, specs non stabilisees, recette absente ou tardive, turnover dans l’equipe projet.
Etape 3 – Recadrer le perimetre
C’est souvent la decision la plus difficile : accepter de reduire le perimetre pour sauver l’essentiel. Mieux vaut livrer 70% qui fonctionne que 100% qui ne tient pas.
Etape 4 – Restructurer la gouvernance
Un projet en derive a souvent un probleme de gouvernance avant d’avoir un probleme technique. Clarifier les roles, reduire les instances, rendre les decisions tracables.
En resume
Reprendre un projet IT en derive, c’est avant tout un exercice de lucidite et de methode. Les outils comptent moins que la capacite a poser un diagnostic honnete et a prendre des decisions difficiles rapidement.
