Gérer l’incertitude d’un projet TI d’envergure

En 2008, les ministres responsables de la santé et des infrastructures du Québec annonçaient en grande pompe la mise en chantier du nouveau Centre hospitalier de l’Université de Montréal (CHUM). Le coût prévu de ce projet d’envergure nationale était de 1,3G$ et l’accueil des premiers patients était planifié pour 2015. Toutefois, c’est plutôt six ans après cet échéancier, soit en 2021, que l’ouverture officielle a été célébrée. On apprenait aussi à ce moment-là que la facture finale était de 3,6G$. Ainsi, cet hôpital a coûté trois fois plus cher pour des travaux qui auront pris deux fois plus de temps.  

Le CHUM représente assurément un cas extrême qui marque notre histoire pour les mauvaises raisons en matière de gestion de projets. Cela dit, les projets d’envergure qui dépassent les estimations budgétaires, temporelles et contractuelles sont très nombreux. En fait, selon plusieurs experts, la quasi-totalité des grands chantiers se classe dans cette catégorie. 

En pratique, estimer un projet est la tâche la plus complexe et ardue qu’ingénieurs et gestionnaires ont à entreprendre. C’est vrai pour nos institutions gouvernementales, mais c’est d’autant plus vrai au sein de nos organisations.  

Si vous pensez à des projets où les coûts et l’échéancier ont débordé au cours des quinze dernières années, il y a fort à parier que ceux qui vous viennent en tête tout de suite sont liés aux TI ou à la transformation numérique, et ce, même si vous avez au sein de votre équipe un responsable des TI très expérimenté et compétent.  

Les risques réels d’un projet d’envergure 

Selon une étude menée par Steve McConnell, une sommité dans le domaine du développement de logiciels aux États-Unis, le coût réel d’un projet varie entre 25 % et 400 % par rapport à la première estimation. En d’autres mots, un projet estimé à 100 000$ peut coûter quelque part entre la modique somme de 25 000$ et la faramineuse somme de 400 000$. M. McConnell sait de quoi il parle : il a occupé divers rôles clés qui l’ont amené à estimer des projets de transformation majeure chez Microsoft, Boeing et pour l’armée américaine sur une période de plus de 30 ans. De son propre aveu, il a toujours eu tort.  

D’emblée, il faut admettre qu’il y a une panoplie de biais cognitifs qui peuvent expliquer cette incapacité à respecter une estimation. Certains tiennent de la pseudoscience, alors que d’autres, tels que le fameux biais de l’optimisme (Planning Fallacy), ont été documentés dans le cadre d’études universitaires plus robustes. Il n’en reste pas moins qu’un fait prévaut : plus il y a d’humains impliqués à donner une estimation dans un projet donné, plus les risques que les chiffres initiaux soient erronés sont grands.  

D’un autre côté, sans humains, il n’y a pas de projets, ni même d’entreprises. Ainsi, il est inévitable d’impliquer des humains dans nos projets, peu importe les biais cognitifs qu’ils traînent avec eux.  

Le concept du cône de l’incertitude des projets

McConnell comprend bien l’impact que peut avoir une mauvaise estimation sur une organisation. En effet, un dépassement de coûts peut mener à l’abandon du projet, alors qu’un échéancier qui s’étire peut, quant à lui, causer la perte d’un avantage compétitif ou d’une occasion d’affaires. 

 Dans le but de mieux gérer les risques de ses projets TI, M. McConnell a décidé d’approcher l’enjeu de l’estimation différemment. Plutôt que de travailler à améliorer la capacité de l’humain à estimer dès le premier jour, une tâche qui semble impossible, il a choisi de mieux prévoir les risques liés à chaque étape (milestones) d’un projet. À la base de cette idée, il estime que peu importe le projet, les grands jalons seront les mêmes. C’est de là que lui est venue l’idée du cône de l’incertitude des projets TI. 

Sur l’axe des Y, on retrouve le facteur de variabilité de l’estimation, allant de 0.25 à 4. Sur l’axe des X, les grandes étapes « génériques » d’un projet TI. 

La philosophie derrière le modèle est simple, plus vous êtes loin de la date de livraison, plus votre estimation sera erronée. Ainsi, il propose que même votre estimation soit itérative.  

Exemple concret de l’utilisation du cône de l’incertitude des projets TI 

Pour illustrer l’application de ce modèle, prenons un exemple concret : vous souhaitez mettre en place un nouveau logiciel qui permettra de faciliter l’expérience de vos clients et de limiter les coûts liés au service à la clientèle. Vous avez bâti un appel d’offres avec quelques requis que vous envoyez à quatre firmes spécialisées. 

En recevant les offres, vous remarquerez déjà un fait étonnant : le prix du plus haut soumissionnaire est quatre fois plus élevé que le prix du plus bas soumissionnaire. Ces derniers ont-ils lu le même document? En vérifiant vos courriels à nouveau, vous confirmez que c’est bel et bien le cas. Alors, comment est-ce possible? 

Au moment du concept initial, vous êtes au point le plus loin de la livraison du projet et c’est là que l’interprétation de vos requis est la plus vague. Après tout, « connecter un nouveau logiciel à un logiciel comptable » peut signifier bien des choses. 

Dans ce contexte où vous savez que tous les soumissionnaires ont tort, il peut être difficile de choisir le bon partenaire d’affaires pour mener à bien votre projet. Il est donc légitime de se demander :  Comment faire pour gérer votre risque et vos appréhensions?  

Selon l’approche de McConnell, au lieu de faire estimer l’ensemble de votre projet, vous devriez vous concentrer uniquement sur le chemin à parcourir vers la prochaine étape, c’est-à-dire une définition complète des requis d’affaires. Ainsi, au lieu de vous avancer sur des prévisions budgétaires importantes qui se révéleront fausses et qui pourraient nuire à votre réputation, vous allez plutôt prévoir un plus petit budget lié à chacune des étapes qui vous mèneront à destination. Avec cette stratégie, vous verrez déjà votre marge d’erreur fondre de moitié. Ensuite, vous allez transformer ces requis en un backlog complet de requis techniques que les développeurs qui travaillent sur le projet comprennent facilement. Votre risque fondra alors à nouveau de moitié. 

 L’idée principale de ce concept est donc d’avancer de façon itérative jusqu’à ce que vous soyez à l’aise avec le niveau de risque. S’il y a 50 % d’écart entre le plus bas et le plus haut soumissionnaire, vous êtes probablement à la bonne place!  

Cet article s’insère dans une série d’articles portant sur les grandes questions des CIO. Pour recevoir nos prochains articles à ce sujet ou pour lire les articles déjà au dossier, rendez-vous sur logient.com. Restez à l’affût des dernières tendances du domaine en vous abonnant à nos comptes LinkedIn et Facebook.