L'auteur et consultant Scott W. Ambler a mené une enquête sur les résultats des projets IT depuis 2007. Il a mis ces résultats et toutes ses évaluations disponibles gratuitement afin que d'autres puissent librement effectuer leur propre analyse du contenu.
Il résume les résultats de son enquête de 2011 dans un article du Dr Dobbs intitulé "How Successful are IT Projects, Really?"(A quel point les projets d'IT sont-ils couronnés de succès, réellement ?).
Il explore l'impact du "paradigme de développement" sur le résultat des projets, en vue d'identifier quelles sont les meilleures approches. Il décrit les 5 approches qu'il a examiné :
Sur un projet ad hoc de développement logiciel, l'équipe ne suit pas un processus défini.
Sur un projet itératif de développement logiciel, l'équipe suit un processus qui s'organise en périodes souvent décrites comme des itérations ou des bloques de temps. En un jour donné du projet, les membres de l'équipe peuvent être en train de rassembler des prérequis, de concevoir le design, d'écrire du code, de tester, etc. Un exemple de processus itératif est RUP.
Sur un projet agile de développement logiciel, l'équipe suit un processus itératif allégé, hautement collaboratif, s'auto-organisant, et orienté sur la qualité. Des exemples de processus agiles sont OpenUP, Scrum, ou XP.
Sur un projet traditionnel de développement logiciel, l'équipe suit un processus par étapes où les prérequis sont identifiés en premier, puis l'architecture/design est défini, ensuite vient la partie code, les tests et le déploiement. Les processus traditionnels sont souvent qualifiés de processus en "cascade" ou simplement "en série".
Lean est une philosophie / un état d'esprit orienté valeur pour un client. Un processus lean s'efforce en permanence d'optimiser la valeur ajoutée pour un client final, tout en minimisant les pertes qui peuvent être mesurées en termes de temps, qualité et coût. En fin de compte, la lean est le développement d'une organisation apprenante. Kanban et Scrumban sont des exemples de méthodes/processus lean.
Lorsque Ambler analyse les résultats il utilise les définitions suivantes pour les projets qui sont une réussite, en difficulté et échoués :
Dans le cadre de cette étude, un projet est considéré comme une réussite si une solution a été livrée et qu'elle correspondait aux résultats attendus dans un intervalle acceptable pour le client. Un projet est considéré comme en difficulté si une solution a été livrée, mais que l'équipe n'a pas complètement atteint les objectifs prévus (e.g., la qualité était correcte, le projet était terminé a peu près dans les temps, mais le RIO était trop faible). Un projet est considéré en échec si l'équipe n'a pas livré de solution du tout. Dans les prochaines études, je pense que je retravaillerai la définition de projets échoués pour exclure les projets annulés volontairement avec le plein accord des parties concernées.
Avec ces définitions il arrive aux résultats suivants :
- Les approches itératives et agiles ont statistiquement le même taux de réussite, avec 69% des projets itératifs couronnés de succès et 25% en difficulté; alors que 67% des projets agiles sont considérés comme un succès et 27% contesté.
- Les équipes traditionnelles et ad hoc ont aussi statistiquement les mêmes niveaux de réussite qui de leur coté sont statistiquement plus faible que ceux réalisés par des équipes itératives ou agiles. Dans ce cas, les équipes traditionnelles atteignent 50% de succès et 36% de mise en difficulté, et les équipes ad hoc ont 49% de succès et 38% sont en difficulté.
- 62% des projets lean sont considérés une réussite et 30% en difficulté, les plaçant pile au centre entre les équipes agiles/itératives et les traditionnelles/ad hoc.
L'article continue en examinant la relation entre plusieurs facteurs qui contribuent au succès d'un projet et à l'approche utilisée. Il regarde le succès comme un concept multidimensionnel :
- Temps/calendrier : 20% préfèrent livrer à temps selon le calendrier, 26% préfèrent livrer lorsque le système est prêt à être expédié et 51% disent que les deux ont autant d'importance.
- Retour sur Investissement (ROI) : 15% préfère livrer en accord avec le budget, 60% préfèrent offrir un bon ROI et 25% disent que les deux sont aussi importants.
- Valeur partenariale : 4% préfère construire un système conforme au spécifications, 80% préfère accéder aux besoins réels des partenaires et 16% disent que les deux sont aussi important.
- Qualité : 4% préfèrent livrer dans les temps et le budget, 57% préfèrent livrer des systèmes de haute qualité qui sont faciles à maintenir et 40% disent que les deux sont aussi importants.
Il compare le résultat de chaque dimension à l'approche de développement utilisée et conclut finalement :
Une fois encore, cette étude a montré que les méthodes de développement agile et itératif semblent être plus efficaces que les méthodes traditionnelles ou ad hoc. Ces résultats sont en accord avec les études précédentes et expliquent probablement au moins pour partie cette tendance générale de la communauté IT à évoluer vers des stratégies agiles.
Ambler n'est certainement pas le seul à mener des études sur le succès des projets. Celui qui est probablement le plus cité est le Standish Group Chaos Survey, qui utilise une définition beaucoup plus contraignante du succès comme dans les temps, dans le budget et dans le périmètre. Le dernier rapport Chaos du Standish Group a été publié en mars 2011. Le président du Standish, Jim Johnson, a déclaré
"Les résultats de cette étude représentent le plus haut taux atteint dans l'histoire du CHAOS Research, Nous entrons clairement dans une nouvelle ère dans la compréhension de pourquoi les projets réussissent ou échouent."
Est-ce que la définition d'Ambler du succès est correct, et est-ce que ses résultats reflètent la réalité de votre organisation ?
La participation à cette étude était sur la base du volontariat - cela peut-il influencer les résultats ?