Aujourd’hui, la partie AMOA / Product Owner qui est en moi a envie de partager avec vous les résultats d’un rapport statistique très sérieux qui montre que 83% des projets informatiques n’aboutissent pas comme ils l’étaient prévus au début.

Le Standish Group, qui est spécialisé dans le conseil et la recherche de données sur les performances de développement de logiciels, mène des enquêtes depuis 1994 sur les taux de réussite et d’échec des projets informatiques. Voici ci-après les conclusions clés de son dernier rapport : le Standish Group Chaos Studies 2018.

A noter que les statistiques sont basées sur l’analyse de plus de 50 000 projets informatiques à travers le monde entre 2013 et 2017, avec des coûts moyens de développement allant de moins de 400 000 euros à plus de 2 millions d’euros.

Au menu :

  1. Qu’est-ce qu’un projet informatique qui réussit ou qui échoue ?
  2. Qu’est-ce qui fait qu’un projet informatique va mieux réussir… ou pas ?
  3. L’Agilité réussit-elle mieux que les méthodes traditionnelles ?
  4. Est-ce que tous les projets informatiques ont les mêmes chances d’aboutir ?
  5. Quel est l’impact de la sur-hiérarchisation dans la réussite d’un projet IT ?
  6. En résumé…

1. Qu’est-ce qu’un projet informatique qui réussit ou qui échoue ?

Le Standish Group se base sur le trio magique des critères utilisés en gestion de projet : le respect de la qualité, du coût et du délais. Voici les définitions :

  • Projet réussi : les 3 critères sont atteints. Le projet a été terminé dans les temps, le budget initialement prévu a été respecté et le logiciel comporte les fonctionnalités demandées,
  • Projet en difficulté : 2 critères sur 3 sont atteints. Le logiciel a été terminé et fonctionne mais il est en retard sur le planning prévu, a dépassé le budget ou propose moins de fonctionnalités qu’il aurait dû,
  • Projet en échec : le projet a été arrêté lors du développement ou il a bien été développé mais n’est pas utilisé (ce qui arrive souvent malheureusement, mais ça sera le sujet d’un autre article sur la conduite du changement, ça m’inspire…).

Remarque : pour le Chaos studies de 2018, les mesures de succès ont été améliorées pour inclure la livraison de la valeur client, l’alignement sur les objectifs stratégiques et la satisfaction client (en plus de la capacité à estimer et planifier un projet, et à le livrer selon le plan d’origine). Livrer un projet parfaitement dans les délais et le budget sans atteindre les objectifs commerciaux serait un énorme gaspillage et raterait complètement le point, on est d’accord.

Débutons l’exploration…

2. Qu’est-ce qui fait qu’un projet informatique va mieux réussir… ou pas ?

Premier constat, il est tout d’abord assez incroyable de découvrir que seulement 14% des projets IT sont considérés comme étant « réussis » et qu’un nombre énooorme (je pèse mes mots) de projets se retrouvent hors délais, hors budget ou avec des fonctions en moins.

Taux de réussite des projets IT_rapport 2018

Selon le rapport :

  • 31,1% des projets sont stoppés avant d’être terminé et ne sont donc jamais déployés !
  • 52,7% des projets dépassent de 189% leurs prévisions budgétaires. Sachant que l’impact financiers liés aux délais ou aux manques de fonctionnalités peuvent alourdir la facture (l’exemple de la ville de Denver aux USA est cité ; l’échec du logiciel de gestion de bagages du nouvel aéroport lui coûterait 1,1 million de dollars / jour),
  • seulement 9% des projets sont terminés dans les temps et dans le budget chez les grands groupes (16,2% en moyenne pour les autres entreprises). Et pour couronner le tout, il y manquerait quand même 60% des fonctionnalités (30% pour les autres entreprises qui s’en sortent nettement mieux).

> Qu’est-ce qui fait qu’un projet IT réussit ?

Le Standish Group a posé la questions aux cadres de l’informatique : les trois premiers facteurs de réussite sont l’implication des utilisateurs dans le processus, le soutien de la direction et un énoncé clair des besoins.

Qu'est-ce qui fait qu'un projet réussit

> Qu’est-ce qui fait qu’un projet est mis à mal ?

Pour les équipes techniques, ce qui les empêche de bien travailler c’est le manque de visibilité sur les besoins réels des utilisateurs, le fait qu’ils ne soient pas assez bien décrits ou qu’on les modifie suite à des erreurs de préparation.

Qu'est-ce qui fait qu'un projet IT est mis à mal

> Qu’est-ce qui fait qu’un projet IT est annulé ou reporté ?

On retrouve dans le top 3 : les spécifications incomplètes (ou pas assez claires), le manque d’implication des utilisateurs, et le manque de ressources.

Qu'est-ce qui fait qu'un projet IT est annulé ou reporté

3. L’Agilité réussit-elle mieux que les méthodes traditionnelles ?

Les résultats de l’étude montrent que les projets agiles ont 60% plus de chances de succès que les projets non agiles. En y regardant de plus près, les projets en cascade sont trois fois plus susceptibles d’échouer que les projets agiles.

 

Pas étonnant !

Rappelez-vous que la philosophie Agile maximise la collaboration entre les utilisateurs et les équipes techniques, et accélère les processus de décisions, de développement et d’adaptation en cas d’erreur. Tout ce qui apparaît sur la liste des « choses importantes » à la bonne réussite d’un projet IT.

Et pourtant !

En Agile, moins d’un projet sur deux sort complet, dans les temps, dans le budget ET est accepté par les utilisateurs… Une marge importante de progression à mon avis, qui dénote à quel point il est encore difficile de faire passer les entreprises en agile d’un claquement de doigts et sans accompagnement dans le temps !

Mais terminons cette partie sur une note positive ! Les entreprises réussissent de plus en plus de projets ! Et, vu comme le monde du digital va continuer à s’accroître de manière exponentielle dans les années à venir, c’est une trop bonne chose 👍

4. Est-ce que tous les projets informatiques ont les mêmes chances d’aboutir ?

Une autre conclusion clé du Chaos Studies est que les gros projets ont des taux d’échec plus élevés.

En observant les données, on constate que :

  • les projets Agiles, quelque soit leur taille, ont un avantage significatif sur les projets en cascade,
  • les taux d’échec des projets sont plus liés à la taille des projets qu’à la méthode (Agile ou cascade),
  • combiner petit projet et Agilité favorise le succès d’un projet.

Taux de réussite par taille de projet IT_Rapport 2018

Extrait du rapport :

« Lorsque nous séparons «agile contre non-agile» par taille, nous trouvons des données vraiment intéressantes. Les grands projets agiles réussissent deux fois plus vite que les projets non agiles et échouent deux fois plus souvent. Les projets «moyennement agiles» ne s’en sortent pas beaucoup mieux (31% contre seulement 19% pour les projets non agiles). Ce n’est que dans la petite catégorie que le non-agile se rapproche de l’agile. Par conséquent, nous concluons que la taille l’emporte sur la méthodologie agile, mais en combinaison, elles peuvent être mortelles. » – Série de rapports du Groupe Standish CHAOS, Théorie de la latence des décisions

Les entreprises et organisations qui prennent le temps de décomposer les grandes initiatives en « morceaux » constatent qu’elles peuvent mieux gérer leurs calendrier et les risques de dépassement du budget. Cela leur permet aussi de proposer de la valeur aux utilisateurs par petits morceaux mis à disposition (je vous ferais prochainement un article sur ce sujet qu’on appelle le MVP et la MMP).  .

5. Quel est l’impact de la sur-hiérarchisation dans la réussite d’un projet IT ?

L’étude a montré qu’un délai de 1h à 5h  dans la prise de décision peut réduire le taux de réussite d’un projet informatique de 58% à 18%. Autrement dit, si votre entreprise prend près de 5 heures pour prendre des décisions, vous avez trois fois moins de chances de réussir votre projet dans le budget et les délais impartis.

Impact du délai de la prise de décision sur le succès d'un projet IT

.

Encore un argument en faveur de l’agilisation et du désilotage des entreprises (et pas que du point de vue du développement informatique…).

En résumé…

Bien qu’elles ne soient pas nécessairement une solution miracle, les données factuelles montrent que les approches Agiles peuvent VRAIMENT aider à réduire les risques du projet car elles :

  • découpent les gros projets en sous-projets
  • réduisent les délais de prises de décisions
  • intègrent plus les utilisateurs finaux dans la phase de préparation et de test
  • permettent de proposer de la valeur rapidement
  • permettent de gérer les problèmes plus efficacement
  • et plus encore…

Cela dit, l’Agilité ne sera pas toujours la meilleure solution pour certains projets (les développeurs de la NASA vont peut-être avoir du mal à valider les logiciels des sondes d’exploration spatiales en itération de 2 semaines…), sans compter qu’elle est parfois tout simplement extrêmement difficile à mettre en place dans les organisations.

Le cycle traditionnel en cascade n’est pas mort, loin de là !

Dans tous les cas, je vous recommande de vous faire accompagner par des spécialistes des 2 méthodes (Product Owner pour l’Agilité ou AMOA pour les méthodes traditionnelles) car ils pourront garantir que la bonne communication entre ceux qui pensent les objectifs stratégiques, ceux qui développent les solutions informatiques et ceux qui les utilisent.

« Seul, on va plus vite. Ensemble on va plus loin. » proverbe africain

Sources : The Standish Group