Sauvetage de Projet
Comment sauver un projet technique ? Livre Blanc
Un projet en panne ? Un projet mal accepté par les utilisateurs ? Un planning qui dérape trop ? Les raisons du - ou des – problèmes peuvent être nombreuses : erreurs de conception, prestataire démissionnaire ou incompétent, imprécisions sur le besoin …
Recevoir le livre blanc
Dans ce guide, découvrez :
- Comment poser un diagnostic ?
- Les méthodes de sauvetage
- Quelques cas pratiques
- Nos recommandations
Ce livre blanc propose un nouveau classement des risques et une méthodologie plus précise pour tenter de sauver votre projet.
Un sujet passionnant !
The Coding Machine a souvent eu l’occasion d’aider des clients en difficulté sur leur projet. Ces situations critiques nous ont permis d’appréhender les origines de ces dérapages, de trouver des solutions et de les mettre en œuvre.
Le « sauvetage de projet » est un sujet passionnant à plusieurs titres :
- Il nécessite de mobiliser une très large palette de compétences : des compétences humaines, pour distinguer objectivement les problèmes réels de ceux qui sont fantasmés, des compétences techniques, afin de pouvoir plonger au cœur des applications, et enfin de la créativité pour imaginer ou trouver les bonnes solutions.
- C’est une activité exigeante : les attentes des clients sont fortes. Ces missions nécessitent de déployer une énergie importante au démarrage afin de convaincre les différentes parties prenantes et de mettre en place les bonnes actions correctrices.
Différence entre « risque » et « échec »
Un risque est susceptible d’être géré : il est possible de mener des actions préventives ou correctives. Un échec est souvent une accumulation de problèmes qui indépendamment les uns des autres auraient pu trouver une solution. Autrement dit, c’est une succession de risques non gérés qui aboutit souvent à un blocage global du projet. La différence entre les deux n’est pas évidente. La tendance naturelle est de mener des actions pour tenter de corriger les problèmes qui se présentent au fur et à mesure du temps. Parfois, en ayant la tête dans un projet, il n’est pas rare de perdre en lucidité. Un problème qui peut sembler très grave ne l’est peut-être pas et inversement. Alors, si vous vous posez la question de savoir si votre projet est raté ou si vous êtes simplement en train de gérer un risque, vous êtes certainement à une étape cruciale du développement de votre projet.
S’inquiéter est une bonne maladie. Car plus on se rend compte tard des problèmes, plus c’est grave. Autrement dit, plus on accumule les risques au fur et à mesure du projet, plus le sauvetage s’annonce difficile !
Ce livre blanc est là pour vous livrer une synthèse de nos expériences, les écueils à éviter et vous exposer les méthodes que nous avons appliquées. Si vous estimez que votre projet est sur de mauvais rails ou en pleine tourmente ou si, plus simplement, vous souhaitez approfondir la notion de risques sur un projet, ce livre blanc est fait pour vous.
Attention : Ce livre blanc est le fruit de notre expérience. Vous y trouverez peut- être des défauts ou en soulèverez des limites. N’hésitez pas à nous en faire part. D’autre part, nous sommes convaincus que nous n’avons toujours pas fait le tour du sujet, vous avez le droit de faire preuve de créativité !
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.
