L'Urgence et les Projets Informatiques

L'urgence comme contexte de travail

On m’a posé récemment la question de savoir si le travail « en urgence » s’organise différemment par rapport au travail « normal ». Après avoir analysé tous les aspects, fausses bonnes idées et tendances, je me rends compte que la réponse est : non! Dès qu’on est dans une situation d’urgence, la tentation est très grande de faire un peu n’importe quoi et adopter des modes de fonctionnement « spécial situation d’urgence », qui ne font que renforcer la panique et le retard.

Que ça soit la conséquence d’une mauvaise estimation dès le départ, d’un imprévu qui a fait perdre du temps ou bien des contraintes plus ou moins justifiées imposées par la hiérarchie, l’urgence semble accompagner quasi-systématiquement nos chers projets informatiques ! Le contexte le plus favorable et fréquent pour ce type de situation est de loin celui des projets au forfait : je dirai sans hésiter que le meilleur moyen d’assurer l’échec de votre projet est de le contractualiser au forfait !

Petit tour des erreurs déjà testées et approuvées, les plus systématiques et efficaces pour planter votre projet :

Erreur très efficace n°1 : Il faut tout lancer au plus vite ! Ou pas …

Lancer vite le plus de tâches possible ne fait pas avancer plus vite ! En revanche, ça a immédiatement quelques conséquences vraiment négatives sur le projet :

• créer au sein de l’équipe un sentiment «d’urgence » voir de panique peu propice à la productivité.
• les tâches ainsi lancées dans la précipitation ne sont pas les plus importantes, nécessaires ou prioritaires, mais plutôt celles qu’on a vu en 1er

Au lancement du projet, il y a trois choses qui sont vraiment indispensables d’après moi, peu importe le degré d’urgence :

1. Prendre le temps mais surtout le recul nécessaire pour faire une 1ère analyse la plus objective possible des priorités du projet. Si on parle d’un périmètre fonctionnel donné, identifier des lots/macro-fonctionnalités et demander au client de les prioriser : il aurait beau à dire que tout est hautement prioritaire et que c’est tout ou rien, vous les prioriserez tout de même à sa place, avec les éléments dont vous disposez, et la réalisation va suivre cet ordre de priorités : on maximise le ROI et on s’assure qu’on implémente à tout moment la fonctionnalité la plus importante. On maximise la valeur du produit livré, à chaque itération. Lorsque, malgré tous les efforts déployés, il faudra accepter que tout ne soit pas fini pour une date donnée, votre client sera moins mécontent de voir qu’il lui manque les écrans d’administration (utilisés une fois par an) plutôt qu’une partie du processus métier principal ! J’ai vu trop souvent des chefs de projets se cacher derrière l’éternelle excuse « le client ne veut pas/n’est pas d’accord », en oubliant que le professionnel dans le domaine dont on parle n’est pas le client. De plus est, assez souvent, ce client ne nous dit même pas toute la vérité, mais il faut qu’on la trouve et qu’on l’aide malgré lui ! Si un scénariste se penchait sur nos réalités, le résultat dépasserait certainement le succès de Dr. House...!

2. Avoir la/une bonne équipe : Ceci ne veut surtout pas dire prendre uniquement des stars du développement, incapables de sacrifier les hauts principes de la solution technique parfaite, complexe et coûteuse sur l’autel du pragmatisme. L’équipe parfaite contient d’après moi que des gens qui ont envie de travailler sur le projet et de travailler ensemble, en tant qu’équipe, qui sont conscients qu’ils ont des choses à apprendre et des concessions à faire. Au passage, ils devraient avoir aussi les connaissances requises, bien entendu, mais ceci n’est pas suffisant. Avoir un ou plusieurs héros dans l’équipe ne suffit pas pour vous assurer la réussite, en revanche un seul mauvais élément qui démotive les autres est suffisant pour planter le projet, ou tout au moins vous empêcher de le réussir. Il m’est arrivé plus d’une fois de décider de me séparer d’un membre de l’équipe sans être sure de pouvoir le remplacer à temps, mais ça c’est toujours avéré une bonne décision.

3. Mettre en place un début d’organisation : une 1ère version des processus d’organisation projet les plus indispensables, qu’on complétera/adaptera par la suite suivant le besoin. Les organisations qui essayent de faire rentrer tous les projets dans le cadre de la méthodologie maison échouent aussi souvent que les autres et souvent avec plus de dégâts. La solution magique s’appelle « le Lean ».

Erreur très efficace n°2 : Ne pas maintenir le planning, on n’a pas le temps !

La plupart des projets établissent un planning au départ parce que le client le demande, puis l’ignorent jusqu’à ce que le client le demande à nouveau. Le planning n’est pas vu comme un outil de pilotage et ce pour une mauvaise raison : on n’a pas le temps nécessaire pour le faire évoluer, et de toute façon ça ne se passe jamais comme prévu dans le planning. Il est vrai que la fréquence de mise à jour, corroborée avec un niveau de détail inapproprié peuvent vite transformer cette activité de suivi incontournable dans un petit cauchemar qu’on aurait vite arrêté.

Concernant le niveau de détail, J. Von Neumann disait: "There’s no sense in being precise when you don’t even know what you’re talking about". Inutile d’établir un planning ultra détaillé pour les phases du projet qui vont arriver dans un an, mais il doit être plus détaillé pour les deux semaines à venir. Si dans une semaine on le revoit et on constate que rien ne s’est passé comme prévu depuis, deux choses sont à faire :

1. le mettre à jour, avec les nouveaux éléments
2. définir les actions nécessaires pour rattraper les activités qui avaient été prévues mais non réalisées.

Mais on ne détaille toujours pas les activités de mise en production qui arriveront dans un an ! La vraie valeur de cette activité de planification consiste dans l’analyse qu’on fait en comparant la situation « actuelle » avec la situation qui avait été « planifiée ».

Erreur très efficace n°3 : Improviser des styles de management « spécial projet urgent »

Comme les premiers réflexes (sous l’influence de la panique) ne sont pas forcément les bons, il ne faut pas céder à la tentation de ne plus faire du monitoring et du pilotage et plonger soi-même dans les tâches de l’équipe, avec la fausse bonne idée de «mieux les aider ». Même si votre projet s’appelle « Le Titanic » et il n’y a vraiment plus aucun espoir, il faut toujours avoir un capitaine qui fait son job, même quand et surtout si la situation n’est pas complètement rassurante.

Abandonner le pilotage du projet et réaliser des tâches de développement c’est avouer qu’il n’y a plus de capitaine : c’est une très mauvaise idée. Au contraire, dans des situations délicates il faut davantage suivre son projet et chercher des solutions, donner à l’équipe le sentiment que le principal est sous contrôle et qu’on ne fait pas n’importe quoi. L’équipe doit être informée de la situation, la communication doit être transparente mais obligatoirement positive et sincère : si vous n’y croyez plus, demander à votre hiérarchie de changer de capitaine. Il ne faut surtout pas laisser des intervenants externes (client, manager) venir déranger l’équipe, leur mettre la pression et leur transmettre leur inquiétudes, justifiées ou pas. Vous avez le devoir de faire écran de protection, de discuter avec tous ces intervenants et de communiquer à l’équipe les informations digérées et filtrées, réelles mais graduées, avec le dosage précis de pression que vous seul auriez jugé utile pour augmenter l’efficacité de leur travail.

Erreur très efficace n°4 : S’inspirer (uniquement) de contes de fées lorsqu’on prend les hypothèses d’estimation!

Lorsqu’on estime le travail à venir (et comme on n’a pas de marge vu qu’on est déjà dans l’urgence), une erreur très courante est de prendre des hypothèses de type : « telle tâche doit prendre 2 jours donc je lui prévois 2 jours ». Et faire la même chose pour l’ensemble du travail restant. Vous allez obtenir un planning utopique de 10 jours avec 5 hypothèses très optimistes. Cela prouve au client (immature, autrement il n’y croit pas) qu’on est confiant sur la maîtrise de la suite. Si vous n’habitez pas Disneyland, ceci n’arrivera jamais : dans la vraie vie, celle où il y a des vrais gens et des vrais logiciels, il n’arrive jamais que toutes les activités se passent idéalement. Le contraire non plus, alors comment trouver la bonne marge, la plus réaliste possible, à inclure dans son estimation ? Niels Bohr avait raison de constater que « Prediction is very difficult, especially about the future », mais des techniques existent. Si vous n’en connaissez aucune, utilisez votre bon sens, votre intuition et votre expérience, mais dans aucun cas ne faites pas comme si on avait Superman et La Bonne Fée dans l’équipe! Le client va peut-être faire semblant de le croire, mais vous, vous savez que ce n’est pas vrai… !:)

Erreur très efficace n°5 : Tout miser sur le jour J, même quand il tombe un Vendredi 13

Faire comme si on y croyait alors que tous les éléments (plan de charge, planning, risques…) prouvent qu’il est très improbable d’y arriver dans les conditions actuelles et demander à l’équipe des efforts surhumains pour « livrer à temps», en réduisant des phases « pas indispensables » comme… la recette ! est également une très mauvaise idée.

On livrera au client le jour J un produit qui contient en théorie toutes les fonctionnalités du périmètre (écrans d’administration inclus), mais qui plante au beau milieu de chaque cas d’utilisation…. Résultat : client extrêmement déçu, équipe frustrée et exténuée et hiérarchie pas contente. Du tout.

Dans les mêmes délais et avec les mêmes ressources, la bonne approche aurait été de découper le projet en « lots », développer par ordre de priorité aussi bien les lots que les fonctionnalités à l’intérieur d’un lot et livrer au client de manière incrémentale. Je connais peu de clients qui auraient refusé cette approche, qui n’a que des avantages :

• Augmenter progressivement la confiance du client, si ce n’est sur la tenue du délai final, au moins sur la qualité du produit
• Livrer en 1er les parties les plus importantes, qui ont le plus de valeur métier (*business value*)
• S’assurer qu’on livre le jour J un produit peut-être incomplet mais qui fonctionne parfaitement sur les parties réalisées

Conclusion

Il est évident que l’approche idéale c’est de prévoir un mode de fonctionnement orienté priorités client dès le départ. Les modes de contractualisation classiques (forfait ou régie) sont dépassés et ils ne favorisent pas la réussite de nos projets. L’approche la mieux adaptée à la réalité est la contractualisation agile, que nous mettons en œuvre avec nos clients. Ce n’est pas au projet de s’adapter à une méthodologie et à un contrat établis, mais c’est la réalisation qui doit s’adapter aux besoins et au contexte évolutif du client, qu’aucun cahier de charges ne peut détailler de manière exhaustive d’emblée pour les x mois à venir. Et le contrat doit renforcer ce mode de fonctionnement.

Établir un cadre de travail optimal et la méthodologie qui correspondent au mieux au contexte précis, mettre en place la bonne équipe et accompagner le client dans l’évaluation et la priorisation de son besoin, livrer de manière incrémentale en maximisant la valeur, dans un climat de transparence et professionnalisme nous ont vite fait oublier les projets des fausses urgences !