Project Rescue
How to rescue your technical project? Free guide
A broken project? A project poorly accepted by users? A schedule that gets out of hand too much? The reasons for the problem (s) can be numerous: design errors, resigning or incompetent service provider, imprecision of the need, etc.
Receive this white paper
In this guide, discover:
- How to make a diagnosis?
- Rescue methods
- Some practical cases
- Our recommendations
This white paper proposes a new classification of risks and a more precise methodology to try to save your project.
A fascinating subject!
The Coding Machine has often had the opportunity to help clients in difficulty with their project. These critical situations have enabled us to understand the origins of these slippages, to find solutions and to implement them.
“Project Rescue” is a fascinating subject for several reasons:
- It requires mobilizing a very wide range of skills: human skills, to objectively distinguish the real problems from those that are fantasized, technical skills, in order to be able to dive into the heart of the applications, and finally creativity to imagine or find the good solutions.
- It is a demanding activity: client expectations are high. These missions require a significant amount of energy to be deployed at the start in order to convince the various stakeholders and to put in place the right corrective actions.
Difference between “risk” and “failure”
A risk is likely to be managed: it is possible to take preventive or corrective actions. Failure is often an accumulation of problems that independently of one another could have been solved. In other words, it is a succession of unmanaged risks which often results in an overall blockage of the project. The difference between the two is not obvious. The natural tendency is to take action to try to correct problems that arise over time. Sometimes, having your head in a project, it is not uncommon to lose your lucidity. A problem that may seem very serious may not be, and vice versa. So, if you are wondering if your project is failing or if you are just managing risk, you are certainly at a crucial stage in the development of your project.
Worrying is a good disease. Because the later we realize the problems, the more serious it is. In other words, the more risks we accumulate as the project progresses, the more difficult the rescue will be!
This white paper is there to provide you with a summary of our experiences, the pitfalls to avoid, and explain the methods we have applied. If you feel that your project is on the wrong track or in turmoil or if, more simply, you want to deepen the notion of risks on a project, this white paper is for you.
Note: This white paper is the result of our experience. You may find flaws there or raise limits. Please let us know. On the other hand, we are convinced that we still have not covered the subject, you have the right to be creative!
LE PERIMETRE A LA DERIVE
Symptôme très fréquent : dès l’origine du projet, un périmètre très vaste est défini ou des besoins de plus en plus complexes sont exprimés au fur et à mesure du projet.
C’est un cas qui se produit souvent 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 donc plus « vendable ». Dans la réalité, c’est souvent l’inverse. En général, il vaut mieux 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. C’est faux car 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 peuvent 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
LE PRIX HAMEÇON
Le prix proposé par le prestataire est volontairement bas afin d’«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,
- Le projet est bloqué car vous ne souhaitez pas (ou ne pouvez pas) continuer à
Ce “faux prix” risque de 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.
PROJETER SES ANGOISSES (OU FAIRE DES SUPPOSITIONS)
Ce n’est pas à proprement parler un risque. La méconnaissance des projets peut générer des angoisses irrationnelles. Il nous est déjà arrivé d’intervenir sur un projet qui allait plutôt bien ! Il est donc important de mettre en œuvre, dès le démarrage, un dispositif de gouvernance permettant de mesurer l’avancement, gérer les risques et d’arbitrer les évolutions. Tous les dispositifs qui permettront aux parties prenantes d’être à l’aise avec le projet et son avancement.
Ces mesures : temps consommé, avancement etc. doivent permettre de fournir à l’ensemble de l’équipe un avis objectif sur l’état de votre projet. Ils permettent de mettre en œuvre des plans d’actions pour gérer certains risques ou replanifier certaines parties du projet.
L’EFFET TUNNEL
L’effet tunnel consiste à développer pendant une longue période sans faire intervenir les utilisateurs. La solution développée risque, in fine, de ne pas convenir aux besoins/souhaits des utilisateurs. La recette, longue et donc fastidieuse, risque alors d’être bâclée, les utilisateurs ne disposant pas forcément du temps nécessaire pour la faire aboutir.
LE NOMBRE D’ANOMALIES
Voilà une question qui revient souvent : est-ce qu’un nombre important d’anomalies durant la phase de recette indique qu’un projet est en train de se planter ?
Dans la plupart des cas, non ! Il faut tordre le cou à cette idée reçue. Plus le nombre d’anomalies est important, plus vos utilisateurs testent la solution. C’est lorsque la solution n’est pas assez testée que l’on peut rencontrer des difficultés en production. Donc, de manière contre-intuitive, cet indicateur est plutôt un facteur de qualité.
La première recette technique doit permettre de régler la plupart des anomalies de base. Si cela n’est pas le cas, un recadrage peut s’avérer nécessaire pour éviter l’épuisement des utilisateurs en cours de recette.
L’autre nuance que l’on peut apporter est de déterminer si les corrections sont efficaces. Des problèmes liés aux performances qui ne peuvent être corrigés indiquent peut- être des problèmes importants liés à la conception.
