La gestion de soi lors du sauvetage d’un projet

Le diagnostic est sans appel, votre projet est planté. Pas de panique, TheCodingMachine vous apporte des solutions !

 
Poser le bon diagnostic résout une grande partie du problème, car une fois que les problèmes sont identifiés, il est possible de mettre en place un plan d’actions efficace.
Pour garantir un résultat fiable et sérieux, solliciter une société extérieure reste, à notre avis, la meilleure option (si vous choisissez cette solution, n’hésitez pas à nous appeler). Car la toute première étape consiste à se débarrasser des problèmes périphériques qui accompagnent inévitablement la dérive d’un projet et parasitent notre vision. Faire appel à un tiers qui est indépendant et sans a priori permet de dépassionner le débat.

L’importance du contexte

Réussir le sauvetage d’un projet nécessite de plonger au cœur du problème afin de dresser un tableau objectif de l’état du projet. Quels sont les problèmes ? Peuvent-ils être résolus rapidement ? Par qui et de quelle manière ?
Les solutions dépendent étroitement de l’état du projet : le projet est-il encore en développement ou bien en production. Elles dépendent aussi de la nature des problèmes : est-ce un problème technique ? Un problème concernant le périmètre ? Ces solutions dépendent évidemment de la taille du projet. Plus un projet est petit, plus il est simple de le reprendre depuis le début.
Un bon conseil : ne pas avoir peur … de supprimer le problème
Si les problèmes ont une origine technique, l’application développée a peu de chance d’être « sauvée ». Corriger des erreurs graves de conception de l’architecture est souvent très coûteux. A budget équivalent, il vaut mieux reprendre les développements techniques « from scratch ». L’analyse de l’existant doit donc être méticuleuse pour éviter de jeter une application qui pourrait être sauvée, mais également pour ne pas vouloir sauver cette application à tout prix et faire durer l’échec.

La définition du périmètre : facteur essentiel du sauvetage de projet

La peur du « pas assez » ou le périmètre à la dérive

La peur du « pas assez » est un symptôme fréquent. Dès l’origine du projet, le client définit un périmètre très vaste ou
exprime des besoins de plus en plus complexes au fur et à mesure du projet.Ce cas est fréquent lorsque le client souhaite lancer une nouvelle activité. Proposer de nombreuses fonctionnalités
donne l’impression rassurante d’offrir un service plus complet au client final. Dans la réalité, c’est souvent l’inverse. Il faut définir le périmètre le plus petit possible, tester rapidement et redéfinir le besoin en utilisant les retours utilisateurs ou bêta testeurs (« Pave the cow path »).
Définir un périmètre très vaste donne aussi l’impression trompeuse de coûter moins cher qu’un développement en
plusieurs étapes. Cela ne reste qu’un leurre. Au final, si de nombreuses fonctionnalités ne servent pas, le coût de ces
développements inutiles et de l’effort nécessaire pour les produire peut mener le projet vers l’échec. La dérive d’un périmètre peut aussi être attribuée à une mauvaise gestion de projet. Un prestataire en mauvaise position, comme par exemple dans le cas d’un retard important ou d’un problème de ressources, peut accepter des développements complémentaires en espérant conserver de bonnes relations avec son client. Il lui rend un mauvais service. En cumulant retard et nouveaux développements, le projet risque d’être encore plus long à
finaliser.

Le prix hameçon

Le prix proposé par le prestataire est volontairement bas afin de « hameçonner » le client. Un prestataire minimise volontairement le prix de la prestation afin de remporter le marché.
Au fil du projet, deux situations se présenteront :
• Les développements continuent car vous acceptez de nombreux avenants par rapport au prix initial
• Le projet est bloqué car vous ne souhaitez pas (ou ne pouvez pas) continuer à payer.
Ce « faux prix » peut fortement dégrader la relation que vous entretenez avec votre prestataire à mesure que le projet
avance.
Il est cependant nécessaire de faire la différence entre un acte délibéré (un prestataire qui hameçonne un client) et un périmètre qui évolue et grandit anormalement en cours de route (là, c’est un peu la faute du donneur d’ordre).

Méthode pour un sauvetage de projet efficient

Votre projet n’avance plus ? Il est dans une situation critique ?

Cet article se propose de vous donner les clés pour sauver un projet en distinguant différentes étapes :
1. Est-il possible de sauver le projet ?
2. Quelles sont les pistes pour résoudre les problèmes
humains ?
3. Comment résoudre les problèmes techniques ?

La différence entre le risque et une situation d’échec
Le risque est susceptible d’être géré. Il est donc possible de mener des actions correctives. A l’inverse, une situation d’échec est une accumulation de risques non gérés qui aboutissent souvent à un blocage global du projet.
Si vous vous posez la question de savoir si votre projet est totalement planté ou si vous êtes simplement en train de gérer un risque, vous êtes à une étape cruciale du développement de votre projet. En général, plus on se rend compte tard du plantage, plus c’est grave. Autrement dit, plus on accumule les risques au fur et à mesure du projet, plus le sauvetage s’annonce difficile !

Les dangers qui vous guettent !
Chaque étape d’un projet comporte des risques. La plupart des risquent qui menacent un projet sont connus à l’avance même si certains apparaissent dans des situations particulières parce que liés à une problématique unique.
Néanmoins, la manière de structurer la réponse aux besoins des utilisateurs (expression de besoin et cahier des charges) et le choix du prestataire constituent des étapes clés pour limiter tout débordement sur un projet à venir. Vous devrez y porter une attention particulière.
Si vous souhaitez en apprendre plus sur le sujet, n’hésitez pas à télécharger notre Livre blanc dédié :