Moins votre projet est avancé, plus l’incertitude est élevée.
C’est plutôt logique d’ailleurs : au démarrage d’un projet, il y a plus d’inconnus que d’éléments connus. Puis au fur et à mesure de la progression, cela s’inverse.
On utiliser le cône d’incertitude pour représenter cela. Je vous explique en détail cette notion dans cet article.
Qu’est-ce que le cône d’incertitude en gestion de projet ?
Le cône d’incertitude est un graphique représentant l’évolution de l’incertitude d’un projet dans le temps.
Au début d’un projet, il existe beaucoup d’inconnus sur le périmètre, le travail à réaliser ou les résultats possibles. Les estimations sont donc sujettes à de fortes variabilités.
Puis au fur et à mesure de la progression du projet dans le temps et que davantage d’informations sont recueillies, le cône se rétrécit.
Les estimations se font de plus en plus précises, les risques diminuent ainsi que l’incertitude, jusqu’à atteindre une variabilité de 0% sur la fin du projet.
Cet outil permet de donner une variabilité (par exemple : plus ou moins 40%) à ses estimations. On peut ainsi projeter des dates de fin de projet dans le temps, en prenant en compte 3 scénarios :
- Scénario Optimiste.
Tout va bien dans le meilleur des mondes. On prend systématiquement en compte les estimations les plus faibles afin d’identifier la date de fin au plus tôt du projet. - Scénario Réaliste.
Dans ce cas de figure, on tient compte du fait que certaines tâches peuvent finir en avance et que d’autres peuvent être retardées. On obtient ainsi la date de fin probable du projet, qui doit se situer entre l’échéance finale au plus tôt et l’échéance au plus tard du projet. - Scénario Pessimiste.
On imagine que tout ce qui peut mal se passer va mal se passer, selon la loi de Murphy. En prenant en compte les estimations les plus élevées, on détermine ainsi la date de fin au plus tard du projet.
Pour construire un cône d’incertitude, vous devez créer un graphique à deux axes :
- L’axe horizontal contient les jalons projet.
- L’axe vertical correspond au degré d’erreur des estimations projet. On parle aussi de variabilité ou de variance.
Cette notion de cône d’incertitude est principalement utilisée dans le monde du développement logiciel, mais elle gagnerait à être employée dans d’autres secteurs d’activité.
Exemple de cône d’incertitude
Comment utiliser le cône d’incertitude ?
Le concept de cône d’incertitude peut être utilisé aussi bien avec des projets traditionnels (type Waterfall) que des projets agiles (par exemple Scrum). Avec toutefois quelques différences :
1 ) Méthodes agiles
Le cône d’incertitude n’est pas explicitement défini dans le manifeste agile ou le guide Scrum. Mais il s’agit néanmoins d’une notion importante à maîtriser, et sur laquelle vous pouvez avoir des questions si vous passez votre certification PSM1.
En agilité et en Scrum, ça ne sert à rien de faire des estimations détaillées et poussées pour proposer un planning détaillé du projet. Les estimations sont plutôt réalisées pour chaque user stories.
Elles permettent à l’équipe d’identifier la charge de travail à inclure dans le sprint, et au Product Owner d’estimer le nombre de sprints nécessaires pour mener à bien le projet.
Mais l’estimation du travail est souvent source de tension ou de conflit entre l’équipe de développement et les commanditaires du projet ou encore avec le Product Owner.
Dans son livre « Agile estimating and planning », Mike Cohn nous explique pourquoi. Selon lui, un plan projet doit permettre de :
- Guider les décisions des investissements à réaliser.
- Savoir si un projet est sur le point de livrer des fonctionnalités que les utilisateurs attendent.
- Connaître le nombre de ressources disponibles pour travailler sur ce projet pendant une période définie.
Estimer et planifier est l’une des activités les plus difficiles en gestion de projet, et le cône d’incertitude nous le montre bien.
Steve McConnell, le père du cône d’incertitude a tiré de son expérience de redresser des projets en difficulté chez Microsoft une observation :
Plus le projet approche de sa phase finale, plus les estimations qu’on réalise deviennent proches de la durée finale réelle. A l’inverse, au démarrage d’un projet, les estimations sont très éloignées de ce que sera la réalité.
Steve McConnell
Il a même défini dans son livre « Software project survival guide » des coefficients montrant les variations de l’écart entre le temps estimé et le temps réel.
Ainsi, au début du projet, les estimations oscillent entre 4 fois et 0,25 fois la durée que le projet prendra réellement.
Si un projet est estimé à 100 jours homme lors de son initialisation, la durée réelle de ce projet se situera au final entre 25 et 400 jours-homme, soit un rapport de 1 à 16.
Si 1 seule personne travaille sur ce projet, la livraison du logiciel se fera entre 5 semaines et 1 an et demi. ça commence à faire !
C’est précisément pour cela que les méthodes agiles organisent le travail en sprint, des cycles itératifs de courte durée de 4 semaines maximum, afin de forcer l’équipe à obtenir du feedback de la part des utilisateurs, et de prioriser le travail en fonction.
Il ne sert à rien de détailler un travail et/ou de l’estimer précisément si sa réalisation est éloignée dans le temps.
Vous devez donc prioriser les fonctionnalités présentes dans votre backlog, détailler les user stories qui doivent être intégrées dans le prochain sprint, et les estimer uniquement à ce moment-là.
Exemple de cône d’incertitude
2 ) Gestion de projet traditionnelle
En utilisant des méthodes de gestion de projet traditionnelles, dites prédictives, on cherche à déterminer l’ensemble du périmètre et à planifier l’ensemble du projet lors de sa phase de préparation, et avant de la phase de réalisation.
Sauf que d’après le cône d’incertitude, au début du projet, les estimations oscillent entre 4 fois et 0,25 fois la durée que le projet prendra réellement.
On a donc un haut degré d’erreur au démarrage du projet dans les estimations et la planification du projet.
A titre d’exemple, si un projet est estimé à 100 jours homme lors de son initialisation, la durée réelle de ce projet se situera au final entre 25 et 400 jours-homme, soit un rapport de 1 à 16 !
Un projet mal estimé, et qui ne tient pas compte du cône d’incertitude, pourrait vite devenir non-rentable et s’arrêter prématurément.
En gestion de projet classique (comme Waterfall), ce concept de cône d’incertitude s’applique aussi bien aux estimations de la durée de réalisation ds tâches, qu’à la portée du projet ou encore au budget prévisionnel.
Afin de combattre l’incertitude, et d’améliorer la précision des estimations, je vous conseille de ne pas tout planifier d’un coup.
Découpez votre projet en sous-projets ou en phases, et planifiez-les de l’un à l’autre.
Par exemple, si vous travaillez actuellement sur la phase 2, vous planifiez le travail de la phase 3 afin d’être prêt. Le travail de la phase 4 sera planifié pendant la phase 3 et ainsi de suite.
Exemple de cône d’incertitude
Avantages et Défis du cône d’incertitude
Voici les principaux avantages et défis à relever lorsqu’on utilise le cône d’incertitude en gestion de projet :
1 ) Avantages
- Mieux comprendre la notion de risques et d’impacts projet.
Le cône d’incertitude permet de visualiser que les risques sont plus importants au début du projet, ont plus de chances de se produire, et que les impacts peuvent être dévastateurs. Les risques diminuent ensuite en terme de probabilité de survenance et d’impact tout au long du projet. - Être transparent sur le niveau d’incertitude du projet.
A un instant t donné, le cône d’incertitude permet d’avoir une idée de l’incertitude qui règne sur le projet. Cela est particulièrement utile lorsqu’on communique et collabore avec les parties prenantes clés du projet. - Prendre de meilleures décisions.
Les décisions opérationnelles et stratégiques prennent en compte le niveau d’incertitude du projet ainsi que les variances dans les estimations. On prend donc de meilleures décisions et on est plus efficace. - Ne plus prendre des estimations pour argent comptant.
Les estimations ne sont plus considérées comme des engagements, mais comme des estimations, avec l’imprécision que cela comporte. La variabilité (exemple : +/- 20%) permet d’apprécier l’estimation, et d’obtenir un scénario optimiste et pessimiste, dans lequel on devrait tomber. - Créer une relation de confiance.
Les estimations données avec les variabilités permettent d’établir la confiance entre e client et l’équipe projet. Les estimations deviennent de plus en plus fiables au fur et à mesure de l’avancement du projet.
2 ) Défis
- Difficile à mesurer avec précision.
L’incertitude d’un projet est toujours difficile à mesurer avec précision, de trop nombreux facteurs rentrant en jeu. En fonction des personnes et de la maturité du chef de projet et de son équipe, la forme du cône d’incertitude peut varier. - Compliqué voire impossible de prédire les risques qui vont survenir.
On peut prévoir les risques opérationnels, organisationnels et stratégiques qui pourraient se produire, en estimant leur probabilité de survenance. Mais on ne peut pas déterminer avec exactitude et 100% de précision ce qui va arriver. - Le management ou le client qui prennent des estimations pour des dates gravées dans le marbre.
Le problème des estimations en gestion de projet, c’est que c’est souvent compris comme des dates gravées dans le marbre et des engagements fermes et définitifs. Mais ce n’est pas le cas. Faire changer les mentalités, c’est ce qu’il y a de plus long. - Les plans de projet basés sur des estimations doivent être remaniés régulièrement.
Si le plan de management du projet est basé sur des estimations, cela signifie qu’il doit régulièrement être mis à jour pour tenir compte des dernières informations recueillies, et des nouvelles estimations.
Histoire et origines du cône d’incertitude
Le concept du cône d’incertitude a été développé à la base pour l’ingénierie et la construction dans l’industrie chimique, par l’American Association of Cost Engineers (AACE International).
Ils ont publié un système d’estimation standard, proposé avec des plages d’incertitude en 1958, et ont présenté des illustrations « de cône » dans la littérature de l’industrie à cette époque.
Ce concept a ensuite été repris par Barry Boehm dans le domaine du développement logiciel, sous le nom de « Funnel Curve », courbe en entonnoir.
Le concept a été validé par des projets de développement de logiciels pour l’US Air Force et pour la NASA.
Il apparaît pour la première fois sous le nom de cône d’incertitude (cone of uncertainty en anglais) dans le livre « Software project survival guide », de Steve McConnell sorti, en 1998.
Plus récemment, Mike Cohn aborde également cette notion en détail dans son livre best-seller « Agile estimating and planning ».
