Comment redresser des projets en difficulté

Les consultants de Ernst & Young ont présenté, lors du DSI Symposium 2009 organisé par IDC, dont Best Practices Systèmes d’Information était partenaire, un état des lieux de la gestion de projets lorsque ceux-ci connaissent des difficultés : pourquoi les dérives surviennent-elles et comment faire pour limiter les dégâts ?

Tous les DSI le savent. Toutes les directions métiers en sont persuadées. Tous les informaticiens en subissent les conséquences : les projets informatiques coûtent cher. Surtout s’ils sont mal maîtrisés. Comment faire dès lors pour prévenir les dérives ?

Plusieurs études ont cherché à mesurer l’étendue des dégâts. La plus célèbre, celle du Standish Group publiée en 2004 et réalisée auprès de 365 organisations représentant 8 380 applications, montrait que 31 % des projets étaient arrêtés avant leur terme, 88 % des projets dépassaient les délais et/ou les budgets et que 44 % projets étaient terminés et opérationnels mais avec un dépassement des budgets et des délais initiaux, souvent avec une réduction du périmètre.

Pour Marie-Hélène Vedel, associée IT Advisory chez Ernst & Young, le constat est clair : les raisons génériques de dérives des projets sont souvent identiques, « même si chaque projet est un cas particulier, il n’y a pas de recettes miracles mais des bonnes pratiques de terrain ».

Quelques bonnes pratiques pour anticiper, limiter et contrôler les dérives

Tout d’abord, le sous-dimensionnement, pour faire accepter un projet, se paiera un jour ou l’autre. « Il est fondamental de mettre en adéquation le budget, les compétences et les plannings, ainsi que d’être inventif pour trouver comment faire au mieux avec les moyens disponibles », conseille Marie-Hélène Vedel. Deuxième constat : le temps perdu ne se rattrape plus.

« Au démarrage, on a toujours l’impression d’avoir le temps ou d’avoir du temps : or, les premières dates étant les plus faciles à tenir, il faut battre le temps dès le début, avec, pour prendre une image sportive, privilégier le départ lancé, avec un cockpit de pilotage prêt à fonctionner », résume Marie-Hélène Vedel.

Le troisième constat tient aux modes de management. D’une part, on observe des délais dans la prise de décisions et, d’autre part, « les mêmes mots sont utilisés par tous mais n’ont pas toujours la même signification », déplore Marie-Hélène Vedel, pour qui il importe « d’établir une culture commune dès le début du projet, avec de la méthode qui se positionne en complément de l’expérience. »

Enfin, « la faute de l’autre constitue toujours une bonne raison de dérive, ce qui suppose, pour contrer ce phénomène courant, de contractualiser les relations interprojet », propose Marie-Hélène Vedel. Marie-Hélène Vedel identifie deux cultures de management par rapport à l’annonce des difficultés. Le messager est soit « tué », ce qui a pour conséquence de retarder le plus longtemps possible l’annonce de la mauvaise nouvelle.

Soit on lui « offre à boire », c’est-à-dire que l’on se sert de la situation créée pour optimiser les délais et les coûts. La manière de prendre en compte les difficultés, et notamment les retards, varient selon le sort que l’on réserve au « messager » : « Dans le premier cas, celui-ci va trouver de bonnes raisons, des excuses de ne pas avoir pu réaliser le projet dans les conditions prévues », explique Marie-Hélène Vedel.

D’où la tentation bien légitime, et logique, d’octroyer de nouveaux budgets, d’ajuster le périmètre du projet et de donner plus de temps pour le réaliser, sans analyser les causes profondes. Au contraire, « dans une logique d’optimisation, le bon chef de projet va percevoir rapidement le degré de gravité et agira, après la recherche de la cause réelle, tout aussi rapidement par des actions de correction, de suivi rapproché ou des contournements, c’est un signe incontestable de maturité », précise Marie-Hélène Vedel.

Comment, dès lors, une équipe projet peut-elle faire la différence ? Selon Marie-Hélène Vedel, trois éléments se révèlent fondamentaux. « Tout d’abord, la qualité des équipes, caractérisée par l’implication d’un pilote, une crédibilité, de la détermination et de l’endurance.

Ensuite, il est utile d’impulser une dynamique de résultats et de succès, c’est une spirale positive, surtout si elle est appuyée par une gouvernance qui fluidifie la prise de décision. Enfin, il est inutile de fuir les problèmes : il faut au contraire systématiquement prévoir un plan B et la gestion des risques devient un outil de pilotage. » assure Marie-Hélène Vedel.

Surtout dans un environnement de crise : « Il ne s’agit pas de se demander comment conserver des projets en temps de crise (approche défensive), mais, au contraire, de repenser les projets permettant de faire face aux conséquences immédiates et différées de la crise (approche offensive), c’est une opportunité historique, pour les DSI, de redonner à leur fonction la place qu’elle mérite », assure pour sa part Michel Richard, associé chez Ernst & Young Advisory.

Que faire lorsque…
Toutes les « bonnes raisons » sont avancées pour changer de périmètre, de coûts de jalons…
  • Pérenniser la trajectoire du projet.
  • Maîtriser le périmètre du projet (refuser les changements s’ils n’apportent pas ou peu de valeur ajoutée).
La crise menace…
  • Mesurer pour objectiver la situation.
  • Gérer les risques par anticipation.
  • Impliquer le chef de projet dans la gestion de la crise pour s’assurer de la résorption de celle-ci.
La fatigue se fait sentir dans les équipes…
  • Organiser des rotations.
  • Maintenir la motivation des personnes (savoir récompenser prises de décisions et prises de risques).
Le court terme et le long terme sont incompatibles…
  • S’organiser différemment selon les phases du projet pour n’avoir qu’un objectif : un jalon ou la solution.
  • Différencier la phase de construction de la phase de déploiement.
Le projet dure et dure encore malgré le fait qu’il soit déjà en exploitation…
  • Définir le plus tôt possible des critères de « go-no go » de mise en production.
  • Afficher la transparence des critères de décision et gérer les priorités.
  • Savoir passer du mode projet au mode « vie courante » de l’application.
Source : Ernst & Young.

 

Trois études de cas
Cas n° 1
Une date fixe pour l’ouverture à la concurrence
Cas n° 2
Un projet Open Source, avec refonte à l’identique
Cas n° 3
Reprise d’une intégration de projet ayant échoué
Le contexte
  • Une date incontournable.
  • Un projet de plus de 300 millions d’euros.
  • Un retard d’un mois … à six mois du démarrage.
  • Une synchronisation de plus de 20 projets.
  • Un contrat ne prévoyant pas de validation du client avant la recette de la solution.
  • Un contrat de neuf mois qui après neuf mois en est toujours à la conception.
  • Un système à refaire à l’identique en logiciel libre.
  • Un intégrateur ayant abandonné en cours de route.
  • Un progiciel « lourd » pour de petites entités.
  • A 2 000 km de la maison mère.
Les actions entreprises
  • Mise en œuvre d’un cockpit de pilotage.
  • Comité de suivi, deux fois par semaine.
  • Plan d’action suivi tous les jours.
  • Remontée de l’avancement des microjalons, au moins une fois par semaine à la direction.
  • Un pilotage quotidien de ce qui était accepté par le client et des modifications demandées.
  • Davantage d’interfaces di­rec­tes avec les développeurs.
  • Coller à l’existant et rendre les règles de gestion en français compréhensibles par l’utilisateur.
  • Remise à plat du fonctionnel et des paramétrages.
  • Mise en place d’une équipe motivée et récompensée sur les résultats.
Le résultat obtenu
  • Ouverture du système à l’heure.
  • Poursuite de l’opération sécurisation pour les déploiements suivants.
  • Plus forte synchronisation des intervenants pour résoudre tout incident au démarrage.
  • Une solution opérationnelle, dans son domaine, la plus performante de la place après un an d’effort.
  • Un pilote opérationnel.
  • Une démonstration de la faisabilité.
Les best practices
  • Un suivi constant.
  • Des actions pas à pas, opérationnelles.
  • De la visibilité sur les interdépendances.
  • Analyse des impacts sur la trajectoire…
  • L’identique est difficile à obtenir avec des technologies entièrement différentes.
  • La conception UML n’est pas toujours compréhensible par les utilisateurs.
  • La validation du client et sa participation active est incon­tournable dès la conception.
  • Une équipe compétente et motivée pour relever le challenge.
  • Un travail rapproché
  • avec les utilisateurs pilotes.
  • Des victoires étape par étape.
Source : Ernst & Young