Pour ceux qui ne les connaîtraient pas, je vous en donne ici un petit résumé. Etonné par le décalage entre le nombre de licences de progiciel vendues pour le développement de projet et le faible nombre pour leur mise en production, Jim Johnson, le fondateur de cet institut, s’est aperçu en 1994 qu’une grande proportion de projets informatiques étaient abandonnés en cours de route. Il lui est alors venu l’idée de faire une grande enquête auprès des services informatiques de sociétés pour quantifier plus précisément les projets qui étaient :
- Réussis (« succeeded »), c’est-à-dire ayant tenus toutes leurs promesses en matière de fonctionnalités alors que les délais et le budget était tenu
- En difficulté (« challenged »), en montrant une combinaison partielle ou totale de dépassement budgétaire, calendaire ou une réduction de leur périmètre attendu
- Abandonnés (« failed ») en cours de route par leurs commanditaires
On peut comprendre pourquoi ces chiffres ont pu faire réagir, ce qui a par ailleurs assuré le succès de cet institut de recherche. Certaines mauvaises langues vont jusqu’à dire que ces chiffres sont volontairement alarmistes pour assurer son modèle économique.
En tout cas, alors que ces chiffres ont été utilisés dans de nombreuses recherches sur le management de projets informatiques, les détracteurs de ces chiffres sont assez nombreux aujourd’hui. Ainsi R. Glass en 2006 (“The Standish Report: Does It Really Describe a Software Crisis?” Comm. ACM, vol. 49, no. 8, 2006, pp. 15–16.) se demandait si l’industrie informatique serait aussi florissante si la majorité des projets informatiques se soldaient par des échecs. Avec un si faible taux de réussite, on peut effectivement se demander comment il se trouve encore des responsables près à risquer leur budget sur des opérations aussi aléatoires …
La représentativité de l’échantillon de projet ayant servis à faire l’estimation est mise en doute. En effet, le Standish Group ne fournit que des chiffres agrégés, et ne communique pas sur les noms des projets et des compagnies qui les ont lancés. En fait, ils récoltent les enquêtes en échange de la confidentialité des répondants, ce qu’on peut tout à fait comprendre au vu des résultats : autant on peut être fier de montrer des projets réussis, autant on n’a pas envie d’étaler ses échecs sur la place publique … Une idée serait de fournir les données désagrégées de l’enquête en rendant anonyme les noms des projets et sociétés. Mais ceci ne lèverait pas les soupçons nourris sur la représentativité et l’impartialité des données. En tout cas, les propos de Jim Johnson en 2006 (Interview par InfoQ) ne font rien pour rassurer ceux qui s’inquiètent de la représentativité de son échantillon. D’autres comme Molokken et Jorgensen s’étonne de l’évolution importante du taux de dépassement annoncé des projets, mettant en cause la stabilité des méthodes d’enquête dans le temps (« How large are software cost overruns : A review of the 1994 CHAOS Report », Information and Software Technology, vol. 48, no. 8, 2006, pp. 297–301.).
Dans un autre registre et plus récemment, Eleveens et Verhoef (“The Rise and Fall of the Chaos Report Figures”, IEEE Software January/February 2010 ) mettent gravement en cause les chiffres du Standish Group en donnant des exemples de projets menés par différentes organisations.Les auteurs montrent que les projets tombent dans la catégorie des échecs partiels ou totaux du Standish principalement quand l’estimation initiale de charge, et donc de coût et de délai était plutôt sous-évaluée. Or l’étude différentielle des projets de plusieurs organisations montrent que l’estimation initiale est parfois proche du résultat finalement obtenu, parfois très éloignée et dispersée. Mais l’indicateur du Standish peut tout à fait donner un taux de succès élevé à une organisation qui chiffre très mal ses projets (l’estimation initiale est loin du résultat) si elle a tendance à sur estimer. Ou bien donner une très mauvaise note à une organisation qui sous-estime, mais seulement légèrement, ses estimations initiales même si elles sont finalement proche du réalisé. Il suffirait donc de surestimer copieusement pour bien s’en sortir. En d’autre terme, les chiffres annoncés seraient justes, mais leur définition même induit un biais qui ne reflète pas la pertinence des estimations de charge. Néanmoins, le sous-entendu de l'article est qu'un projet est réussi si l'estimation de charge et de coût converge pendant le projet, ce qui reflète une perspective bien particulière.
Pourtant, si j’en crois mon expérience, j’ai une tendance non seulement à croire les chiffres du Standish Group, mais aussi à trouver leur définition du succès ou de l’échec pertinente. Peut-être ai-je une opinion biaisée par le fait que j’ai souvent été appelé en urgence pour rattraper des situations difficiles sur les projets, mais je ne suis pas surpris que l’on trouve une faible minorité de projets qui se passent parfaitement bien. Surtout, je trouve la définition du succès appropriée car, si elle ne reflète pas la précision de l’estimation initiale, elle correspond tout-à-fait à l’opinion que se fera a posteriori un donneur d’ordre en faisant le bilan du projet : ai-je bien ce que j’ai demandé pour les moyens qu’on m’a réclamé ? Il y a d’ailleurs d’autres études autour des projets informatiques réalisés pour l’administration britannique (Sauer, C. and Cuthbertson, C., "The State of IT Project Management in the U.K.", Computer Weekly, Oxford, 2003. ; POST Report Government IT projects 2003) ou par KPMG (Global IT Project Management Survey 2005) qui confirment le faible taux de réussite des grands projets informatiques.
D’ailleurs, les analyses du Standish Group ne s’arrêtent pas au constat de l’échec, mais en cherche aussi les causes. Et l’analyse colle vraiment avec les difficultés que l’on rencontre pendant les projets : utilisateurs peu impliqués et versatiles modifiant sans cesse des besoins mal définis, ou sponsor absent mais exigeant des délais irréalistes. Ainsi, les facteurs clés de succès remontés sont, dans un ordre décroissant :
- l’implication des utilisateurs
- le support du management et l’appropriation du projet par un sponsor fort
- une expression claire du besoin
- une bonne planification
- des attentes réalistes
- des jalons de projet rapprochés
- une équipe compétente
- une vision et des objectifs clairs
- une équipe projet travaillant avec acharnement (en dernier !)
Ainsi, si la construction de ces chiffres est opaque, ils sont tout à fait réalistes et utiles, et peuvent vraiment servir à comprendre que la réussite d’un projet informatique n’est pas du seul ressort du fabricant, mais aussi et surtout du client.
