Livre Blanc

Sauvetage de Projet

Quelques risques en détail

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.

Poser un diagnostic

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 ? Une relation qui s’est dégradée avec votre prestataire ?

Pour garantir un diagnostic dépassionné, solliciter une société extérieure est souvent une bonne option. En effet, de nombreux problèmes périphériques qui accompagnent inévitablement la dérive d’un projet, parasitent notre vision. Faire appel à un tiers qui est indépendant et sans a priori permet de rationaliser le débat.

Poser ce diagnostic permet de résoudre la majorité des problèmes, car une fois identifiés, il est possible de mettre en place un plan d’actions efficace.

Méthodes de sauvetage

Vous avez établi le diagnostic et votre projet risque de ne pas aboutir du tout. Pas de panique, The Coding Machine vous apporte des solutions !

Étape 1 – La pire et la plus simple… parfois il faut avoir le courage de supprimer le problème

Si les problèmes ont pour origine une mauvaise (voire très mauvaise) architecture technique, l’application développée a très peu de chance d’être « sauvée ». Corriger ce type d’erreurs est souvent aussi coûteux que le redéveloppement complet de l’application.

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.

Ce que l’on peut récupérer est souvent une partie de la conception fonctionnelle : processus ou écran par exemple.

Étape 2 – Gérer les problèmes périphériques : Quelles solutions pour gérer les problèmes humains ?

Il faut tout d’abord établir un constat d’échec. Cela semble évident aux chefs de projets dont le prestataire est démissionnaire. Pour celui qui aura un prestataire qui tente de le rassurer, lui promet d’aboutir et qui tente de garder une bonne relation, établir ce constat sera, en revanche, difficile.

Si l’application mérite d’être sauvée, il est nécessaire de s’attaquer aux problèmes humains. C’est souvent délicat car les sentiments qui agitent les parties sont rarement bienveillants. Il est toujours douloureux de se tromper ou d’avoir le sentiment de s’être fait avoir par un prestataire peu scrupuleux. Se lamenter n’est pourtant pas une solution.

Impossible, malheureusement, d’indiquer ici une solution universelle. Nous vous recommandons bon sens et pragmatisme : êtes-vous victime de votre prestataire ou bien de vous-même ? Est-ce que changer le management du projet va vous permettre de porter un nouveau regard sur le projet, apporter une nouvelle motivation à l’équipe ? Est-il possible de créer un électrochoc, de déclencher une prise de conscience de la part des équipes ?

Dans ce domaine, la créativité n’a pas de limites. Voici une présentation des pistes les plus évidentes et les plus efficaces :

• Le désengagement du prestataire – et son éventuel remplacement, permet souvent de voir le projet avec un œil neuf afin d’évacuer les problèmes récurrents : Ce désengagement est-il souhaitable, possible ? Quels coûts supplémentaires va-t-il engendrer ? Quels bénéfices va-t-il rapporter ? Comment envisager la phase de transition ?
• Changer les équipes peut redonner un second souffle au   Pour cela il est nécessaire que l’image du projet ne soit pas trop dégradée afin de ne pas décourager les nouveaux collaborateurs : Ce changement est-il souhaitable, possible ? Quelle organisation mettre en place, qui conserver ?
• Faire une pause, pour tenter de stabiliser le projet et se remettre les idées en place pour se réorganiser : Cette pause est-elle souhaitable, possible ? Combien de temps (trop risquerait de mettre fin au projet) ? Qui et comment planifier la suite du projet ? Relancer les développements par étape, morceler les problèmes, permet d’en voir le bout et ainsi de se motiver : Peut-être est-il possible de découper le projet en sous- ensembles ? Le coût de cette réorganisation est-il supportable ? Les équipes sont-elles prêtes à ce changement ?

Étape 3 – Gérer les problèmes techniques

Si le projet peut être sauvé, alors allons-y, n’attendons plus ! Ce qui n’empêche pas d’intégrer méthode et rigueur à notre opération de sauvetage.

Pour identifier les risques et les actions associées à la reprise de votre projet, plusieurs techniques sont envisageables. Nous vous en proposons une qui a le mérite d’être à la fois simple à partager et facile à appliquer :

Classement des risques et actions :

• Impact : le coût associé à la survenance du Par exemple, la chute de la base de données principale a un coût supérieur à la chute d’un serveur de mail
• Probabilité : la probabilité de survenance du problème;
• Effort de correction : le coût associé à la mise en place d’un correctif;
• Catégorie : la catégorie associée au risque (architecture, sécurité du code, …)