Un projet informatique ne dérape presque jamais pour des raisons techniques. Il dérape parce qu'on a construit quelque chose que personne n'avait précisément demandé, et que le constat arrive trop tard pour être bon marché.
Les cinq causes, dans l'ordre de fréquence
Nous les avons vues, et nous avons contribué à au moins deux d'entre elles.
Le périmètre non borné
Personne n'a écrit ce que le projet ne fera pas. Chaque demande supplémentaire semble minime, et l'accumulation double le délai sans qu'une seule décision ait été prise.
Le décideur absent
Les questions s'accumulent en attendant quelqu'un qui n'a pas le temps. Deux jours d'attente par question, vingt questions, et le projet a pris deux mois sans qu'aucun travail ait été mal fait.
La donnée pire que prévu
On découvre en cours de route que le fichier de référence est incohérent, ou que le logiciel supposé exporter n'exporte pas. Ce risque se lève par une sonde d'une journée avant de commencer, et presque personne ne la fait.
La contrainte découverte tard
Hébergement, langue, fonctionnement hors connexion, compatibilité avec un système existant. Découverte à mi-parcours, une seule d'entre elles peut imposer de reconstruire.
Le refus de dire non
Un prestataire qui accepte tout produit un projet qui n'aboutit pas. Ce n'est pas de la complaisance, c'est un défaut de méthode.
Aucune de ces cinq causes n'est technique. C'est pourquoi ajouter des développeurs à un projet en retard le retarde davantage : le problème n'a jamais été la capacité de production.
Les trois signaux qui préviennent à l'avance
Ils apparaissent des semaines avant que le retard soit visible, et ils se surveillent sans compétence technique.
Les réunions s'allongent et ne décident rien. Quand une réunion de projet se termine sans qu'une question ouverte ait été tranchée, le projet vient de perdre une semaine.
La liste des points ouverts grandit au lieu de rétrécir. C'est le meilleur indicateur qui existe, et il tient sur une page. S'il n'existe pas, c'est déjà un signal.
Personne ne peut dire ce qui est fini. « Presque terminé » sur trois lots successifs signifie qu'aucun n'est réellement fini, parce que le critère de fin n'a pas été écrit.
Ce qui l'évite, et qui se décide au début
Quatre gestes, tous pris avant la première ligne de code.
Écrire ce qui est hors périmètre, explicitement. C'est l'élément le plus efficace et le plus souvent omis d'un cahier des charges.
Écrire la recette avant, c'est à dire la liste des contrôles qui seront faits à la livraison. Une exigence dont on ne sait pas écrire le contrôle est trop floue pour être tenue.
Découper en phases arrêtables, chacune produisant quelque chose d'utile. Un projet en un seul bloc de six mois transfère tout le risque sur le client.
Sonder ce qui est incertain, par un test minuscule et sans conséquence, plutôt que de bâtir sur une hypothèse. Deux heures contre plusieurs semaines.
Quand ça a déjà dérapé
Trois questions, dans cet ordre, avant toute décision technique.
Qu'est ce qui fonctionne aujourd'hui ? Même un projet jugé raté en contient toujours. Les identifier évite de tout jeter, qui est la réaction spontanée et rarement la bonne.
Le besoin d'origine est il toujours le bon ? Un projet enlisé a souvent commencé il y a deux ans, et l'entreprise a changé.
Que se passe t il si on ne fait rien pendant trois mois ? Si la réponse est « rien de grave », vous avez le temps de décider correctement.
Ce que nous faisons différemment
Nous écrivons le hors périmètre et la recette avant de chiffrer. Nous découpons en phases arrêtables, et vous ne payez jamais au delà du devis signé.
Et nous disons non. Plusieurs fois par an, l'audit conclut qu'il ne faut pas développer, qu'un logiciel du marché suffit, ou que le vrai problème est ailleurs. Cela nous coûte des missions et cela évite des dérapages.
L'audit est offert et rendu sous 48 heures.
Un projet qui traîne ?
Audit gratuit sous 48 heures, et il peut conclure qu'il faut arrêter
Demander un audit gratuit