Contact : 06 71 12 81 23

  • Le blog
  • La recette du projet réussi : SMALL IS BEAUTIFUL ! KEEP IT SIMPLE IS WONDERFUL!

28 Nov 2016

La recette du projet réussi : SMALL IS BEAUTIFUL ! KEEP IT SIMPLE IS WONDERFUL!

Par Jérôme Bouloton

- Catégories : Publications

« S’habiller à sa taille et se chausser à son pied : voilà la sagesse », disait Horace. C’est clairement ce que démontre les différentes études sur le retour sur investissement des projets IT, études qui constatent que plus les projets IT sont gros, moins ils ont de chances de réussir.

Les raisons de ces échecs liés à la taille ? Une grande complexité dans l’organisation des projets, un calvaire à piloter, des capacités d’exécution toujours trop faibles et une difficulté croissante pour l’entreprise à détecter les dérives, gérer les risques et alerter les sponsors du projet. On retrouve ces difficultés dans tous les projets mais elles s’accroissent et s’intensifient avec la taille du projet.

Keep it simple is wonderful !

La complexité du projet est une fonction croissante de sa taille, idem pour les risques liés à l’exécution, la transformation et la création de valeur.

Leonard disait « la simplicité est la sophistication suprême ». Il a construit de nombreuses machines savantes, en gardant en tête que simple, c’est mieux.

Si la France est aussi un pays d’ingénieurs, alors essayons de trouver des solutions plutôt que de résoudre des problèmes. Analysis paralysis ?

Small is beautiful !

Selon l’étude Chaos de 2015 de Standish group, seulement 29% des projets informatiques en général sont un succès, quand 52% d’entre eux sont livrés avec des objectifs revus à la baisse.

Les particularités des gros projets sont qu’ils sont soumis à de plus gros budgets, à une couverture géographique plus large, à des objectifs à atteindre plus conséquents et/ou à une équipe projet plus importante. Par ailleurs, la distance ne facilite pas toujours le travail d’équipe…

L’étude établit que le taux de réussite diminue en fonction de la taille du projet : 2% de réussite pour un très gros projet, 9% pour un projet moyen, 62% pour un petit projet ! Sur 100 projets informatiques abandonnés, 72% seront des moyens à gros projets.

On peut le voir en termes d’objectifs fixés : pour un nombre minimal de lignes codées, on ne note aucun retard à la livraison et aucun projet arrêté. Pour 10 milliards de lignes, plus de 60% des projets sont arrêtés et environ 20% des projets sont livrés en retard.

Un gros projet, c’est aussi des ambitions revues à la baisse pendant son exécution : si environ 25% des projets SI ne verront jamais le jour, plus de 50% seront livrés avec des objectifs revus à la baisse. On peut noter quelques exemples relevés dans une étude de Roland Berger sur la gestion de projets : un projet initialement prévu à 10 implantations qui passe à 2 implantations en cours de projet, un projet concernant une BU entière réduit à seulement un référentiel produit et une couverture de 20 pays initialement prévue réduite à une couverture nationale seulement…

On rectifie le tir au niveau budget également. Un budget et des délais parfois multiplié par 2… 17%
des projets IT échouent en dépassant tellement le budget qu’elles mettent en péril l’existence même de l’organisation. Selon McKinsey&Company, sur la moitié des projets IT de plus de 15 millions de dollars, 45% sont hors budget et 56% seront livrés avec un résultat en-dessous des objectifs prévus en consommant, quand même, tout le budget de départ.

Small & simple : les clés du bonheur ?

Pour réussir son projet, il faut notamment adresser trois types de risques :
• Le risque lié à l’exécution (build),
• Le risque lié à la transition (change),
• Le risque lié à la création de valeur (perform).

Que ceux qui font du projet se lèvent : ces risques sont difficiles à maîtriser.   🙂

Par ailleurs, les 3 catégories de risques entraînent des conséquences différentes :
Les risques d’exécution mènent au risque d’arrêt du projet, les risques liés à une transition entraînent des perturbations dans la mise en œuvre du projet. Il existe également le risque que les solutions apportées par le projet ne créent pas de valeur (souvent, l’entreprise sous-investit dans la phase de conception / design du projet).

La formalisation en amont faciliterait-elle la réalisation en aval ?  🙂

Ce qu’il faut faire ? Et qui doit le faire ? La recette secrète…

Les directions générales doivent être impliquées fortement dans le projet (sponsor fort = moins de soucis), notamment pour la prise de décision et la résolution des problèmes, et s’adapter aux changements. Les objectifs doivent être cohérents, clairs pour tous les acteurs, et réalistes. Le périmètre d’intervention doit être clairement délimité et les équipes prêtes à travailler ensemble.

penser-pauvre-25302743Les futurs utilisateurs doivent également s’investir dans la mise en place de la technologie. Help me help you !

Ce qui est particulièrement intéressant, c’est que la direction de projet arrive en 3ème position dans la responsabilité des échecs. Les manquements en matière de qualité (bon sens aux abonnés absents?) et d’expérience de l’équipe projet sont ici pointés du doigt.

L’estimation des délais n’est souvent pas réaliste, c’est pourquoi une feuille de route solide est nécessaire. Le cahier des charges doit mieux définir le besoin, pour ainsi faciliter durant le projet les moments de la conception, de la réalisation et du déploiement.

Fail fast !

On note également un taux de réussite lié à la méthode utilisée. 42% des projets utilisant la méthode agile sont un succès quand seulement 9% sont abandonnés. Pour les gros projets, 18% sont un succès grâce à cette méthode contre 3% de projets réussis avec la méthode en cascade.projet IT

Cependant, même 23% des gros projets utilisant cette méthode échouent. 27% des projets moyens l’utilisant sont un succès, 62% sont livrés avec des objectifs revus à la baisse et 11% d’entre eux échouent contre 7% de projets moyens réussis, 68% livrés avec des problèmes et 25% d’échecs avec la méthode en cascade.

Evidemment, les petits projets réussissent bien mieux avec les deux méthodes mais la méthode agile permet de faire mieux : 58% de réussites, 38% livrés avec problèmes et 4% d’abandons, contre 44% de réussites, 45% de livrés avec objectifs non atteints et 11% d’échecs avec la méthode en cascade.

Cependant, il convient de modérer l’impact de la méthode agile sur la réussite des projets, n’arrivant qu’en 7ème sur la liste des facteurs clés de succès.

Concrètement, qu’est-ce que ça implique ?

Il faut dé-risquer ! Riskless !

En déterminant les zones de risques, en les analysant en profondeur, en définissant un plan de gestion des risques. A l’aide d’entretiens et d’ateliers, les zones de risques doivent être identifiées, les causes profondes et les leviers des risques déterminés, un plan et une feuille de route formalisés.

 

Il faut donc changer les habitudes des utilisateurs, limiter le nombre de personnes impliquées, limiter le temps engagé et limiter les coûts, qui, au-delà d’un certain montant et d’un certain temps, cessent d’être utiles. La complexité du dit-projet, la loi du silence qui règne entre les différents acteurs et le manque d’indicateurs sont autant de facteurs liés à la taille du projet qui impactent négativement la tenue des délais et des budgets.

Un maître mot : Small is beautiful. Une devise : Keep it simple ! Une méthode : Fail fast !

La difficulté inhérente à la réussite de tout projet… c’est dur la gestion des risques, c’est difficile de mobiliser les troupes, d’exprimer son besoin, bref… le syndrome de la page blanche…) entretient une littérature conséquente sur la gestion de projet.

Les méthodes agiles (pour les plus anciens), le design thinking, DEVOPPS, FabLabs, etc. pour les moins anciens, sont des réponses pragmatiques et efficaces aux difficultés à réussir le changement:
• Itération courte, test, retour d’expérience

Horace commentait sur la sagesse par une métaphore vestimentaire.

L’indien ajoute Trust, Purpose, Dialog !

Voilà la recette secrète de l’efficacité au travail et les clés de la réussite de vos projets.

Banzai !