Certains projets ont encore tendance à dériver. Ils durent plus longtemps que prévu et finissent par coûter plus cher qu’espéré. Selon la dernière étude du Standish Group ([1]) 43 % des projets dérivent ([2]). C’est beaucoup mais par rapport à la même enquête effectuée il y a vingt ans on constate un net progrès (courbe rouge). A l’époque 53 % des projets dérivaient. En vingt ans on a gagné 10 %. C’est pas mal, cela représente un progrès moyen de 0,5 % par an. C’est un peu lent car, à ce rythme il va être nécessaire d’attendre 80 ans pour voir disparaître toute dérive des projets informatiques.
Evolution des pourcentages de réussite, de dérive et d’échec des projets selon les enquêtes du Standish Group
Heureusement on a assisté pendant ces mêmes années à une diminution significative du nombre de projets qui échouent. C’était jadis la plaie des grands projets. En vingt ans le taux d’échec est passé de 31 % à 18 % (la courbe verte). C’est un progrès considérable mais on constate depuis le début des années 2000 à une sorte de résistance de cette tendance à la baisse. En effet on était arrivé à 15 % en 2002 puis au cours des années suivantes ce pourcentage est curieusement remonté pour atteindre 24 % en 2008. Heureusement il est revenu à 18 % en 2012. A quels facteurs seraient dus cette remontée ? Relâchement des efforts de rigueur, recours à des démarches agiles mal maîtrisées ? …
Comme le montre la courbe des projets réussissant dans les budgets et les délais prévus le pourcentage de ces projets est passé en 20 ans de 16 % à 39 % (courbe bleu). C’est un progrès considérable. En gros le taux de succès des projets augmente d’un peu plus de 1 % par an. Dans les années le nombre de projets réussissant dans le budget et le planning prévus sera supérieur à celui de ceux qui dérivent.
Ces progrès sont dus à l’influence de nombreux facteurs. Parmi ceux-ci un des plus significatifs est la diminution de l’instabilité fonctionnelle des projets. Celle-ci est facile à apprécier : selon le moment et l’interlocuteur consulté le contenu de la future application varie de manière significative car chaque partie prenante à sa propre vision de la future application. Cette instabilité ne peut que se traduire par des dérives significatives. Pour limiter ce risque il est nécessaire de stabiliser le plus vite possible son périmètre fonctionnel et de faire savoir ces choix à tous les intéressés.
Un mot un peu barbare
Le terme « périmètre fonctionnel » peut paraître étrange et complexe ([3]). C’est pourtant une notion très simple. C’est une démarche permettant de définir le contenu de la future application et aussi ce qui n’en fait pas partie. En général l’ensemble des parties prenantes sont d’accord sur le noyau de l’application par contre il existe des approches très variables concernant les fonctions périphériques.
Ainsi dans une comptabilité générale le noyau comprend la saisie des écritures comptables et éditer des journaux, une balance et un grand livre. Personne n’a de doute sur la nécessité de ces fonctions. Par contre on peut s’interroger sur la nécessité de gérer les comptes clients à l’aide de ce même système et notamment la relance des clients.
La définition de la frontière fonctionnelle de l’application est toujours une opération délicate. Il existe toujours des situations délicates et, si on n’y prend pas garde, on risque de se retrouver avec de nombreuses zones floues. On ne peut pas l’éviter. Il faut simplement veiller à ce que leur importance soit limitée. Plus l’incertitude est importante plus la probabilité de dérive est élevée.
Pour lever ces ambiguïtés une première approche consiste à identifier l’ensemble des objets à produire. Pour cela on va définir :
- la liste des fonctions à mettre en œuvre. Généralement dans une application il existe entre 5 et 10 fonctions, rarement plus. Elles figurent normalement dans la barre de commande située en haut de l’écran. Ce sont généralement des verbes d’action comme : saisir, contrôler, consulter, éditer,…
- les sous-fonctions détaillent le contenu de chaque fonction. Elles figurent dans les menus déroulants ou dans le ruban. Il y a entre cinq et vingt sous-fonctions par fonction. Certaines applications peuvent avoir des centaines sous-fonctions mais la plupart des applications traditionnelles comprennent moins de 100 sous-fonctions.
- les tâches sont les différentes options offertes par une sous-fonction. Elles figurent normalement dans des boites de dialogues.
Le tableau ci-dessous donne un exemple de la décomposition en fonctions et en sous-fonctions d’une application de facturation.
 |
| Analyse en fonctions et en sous-fonctions |
 |
| Cartographie du périmètre fonctionnel de la facturation |
Le périmètre fonctionnel permet d’évaluer l’importance des développements à effectuer et ainsi d’en déduire la charge de travail nécessaire, le budget et le planning du projet.
Fixer le plutôt possible le périmètre fonctionnel
En effet, pour arriver à fixer un planning et un budget il est au préalable nécessaire d’avoir stabilisé le périmètre de la future application. Avant d’avoir fait ce travail il est toujours délicat de dire combien cela va coûter. Il est difficile de chiffrer quelque chose tant qu’elle n’a pas été définie. Dans ces conditions la stratégie consistant à stabiliser le périmètre fonctionnel le plus tardivement possible n’est pas la meilleure approche pour maîtriser les risques liés à un projet. Plus on repousse le moment de la stabilisation du périmètre fonctionnel plus la maîtrise du processus est délicate et donc plus la probabilité de dérive du projet augmente.
Au contraire la bonne pratique consiste à le stabiliser le plutôt possible, c’est-à-dire dès la première étude concernant le projet. Selon l’entreprise elle s’appelle l’expression des besoins, l’étude de faisabilité ou d’opportunité, le dossier d’investissement, le business case,… Les noms sont différents mais d’un document à l’autre on retrouve les mêmes éléments et en particulier la définition du périmètre fonctionnel.
Normalement, dans le cours ultérieur du projet, il ne doit pas y avoir de remise en cause du périmètre fonctionnel. Il est par contre très fréquent qu’il y ait des rectifications de frontière. Généralement elles concernent des points mineurs. Cependant, si ces changements portent sur des points essentiels cela signifie qu’il est probablement nécessaire de revoir le budget du projet et donc son planning de réalisation.
L’impact des rectifications mineures de frontière
Un calcul simple permet de mesurer l’impact de ces rectifications. Dans une application moyenne il y a 10 fonctions qui ont chacune 10 sous-fonctions soit au total 100 sous-fonctions. L’oubli d’une sous-fonction comme un écran de consultation ou l’édition d’un état représente statistiquement 1 % du budget. Par contre l’oubli d’une fonction complète c’est un risque de dérapage de 10 %. Or, il arrive qu’on puisse oublier au départ deux ou trois fonctions importante qui vont apparaître au moment de l’analyse fonctionnelle, voire de la programmation. Leur découverte tardive ne peut que se traduire par des dérapages significatifs des délais et du budget du projet.
Ces différents travaux et notamment l’analyse fonctionnelle n’ont pas pour but de découvrir de nouvelles fonctions à traiter mais de détailler celles qui sont identifiées. Ceci peut, le cas échéant, amener à rectifier les frontières du périmètre fonctionnel mais pas à les déplacer.
Dans le cas des projets simples ce travail peut se faire en une seule étape mais dès que la future application est un peu compliquée on a intérêt à procéder en trois temps :
- l’expression des besoins afin de fixer le périmètre fonctionnel, len budget et le délai du projet,
- l’analyse fonctionnelle permet de vérifier que tout ce qui a été demandé par le métier a bien été identifié, Ceci se traduit par une série d’exigences ([5]).
- l’analyse détaillée définit la manière dont seront produits les différents services demandés.
A la fin de l’analyse fonctionnelle il est trop tard pour corriger le tir
Parfois, pour différentes raisons, dont certaines sont parfaitement honorables, on a tendance à repousser le moment de la stabilisation du périmètre fonctionnel jusqu’à la fin du processus d’établissement du cahier des charges. C’est en particulier le cas lorsque les points de vue des différentes parties-prenantes concernées par le projet sont très divergents. Dans ce cas on profite des groupes de travail créés dans le cadre de l’analyse fonctionnelle pour chercher à dégager un consensus et généralement on l’obtient. Cette approche est intéressante mais elle a souvent pour effet d’accumuler le nombre de fonctions et de sous-fonctions à mettre en œuvre. Cela risque de se traduire par un alourdissement de la conception de la future application avec des risques significatifs de dérive du projet.
En fait, à la fin de l’analyse fonctionnelle il est un peu tard pour stabiliser le périmètre fonctionnel car à ce moment on a déjà dépensé environ 20 % du budget du projet. Si on constate qu’il faut revenir sur les choix préalablement effectués la dérive risque d’être alors conséquente. Pour éviter ce type de situation il est préférable de fixer le plutôt possible le périmètre fonctionnel et de s’tenir.
Pour établir un budget et un planning il est nécessaire d’avoir stabilisé le périmètre fonctionnel
Il est difficile de lancer un projet sans avoir une idée du budget et du délai nécessaire pour le mener à bien. La décision dépend en grande partie de ces deux informations. Il est, pour cela, nécessaire d’avoir au préalable stabilisé le périmètre fonctionnel. Comme, généralement la décision du « go-no go » est prise à la fin de l’étude d’expression des besoins il est logique que ces choix aient été arrêtés à ce moment-là.
Sur la base du nombre de fonctions et de sous-fonctions identifiées on va s’efforcer d’estimer la charge. Ce n’est pas simple car à ce stade du processus de définition du contenu de la future application ses concepteurs ne connaissent pas le détail des opérations qui vont devoir être réalisées. Pour effectuer ce premier chiffrage on procède par analogie avec des projets similaires. Cela donne des phrases du type : « on est plus tôt autour de 1.000 jours » ou bien « on est entre 800 ou 1.200 jours ». Ce premier chiffrage est ensuite affiné à la fin de l’analyse fonctionnelle.
Sur la base de cette estimation on va établir un premier planning du projet compte-tenu de la disponibilité des équipes et des compétences nécessaires. Ce sera le « baseline ». Elle permettra ensuite d’évaluer les décalages constatés. De même on effectuera un premier chiffrage du budget du projet qui permettra d’apprécier l’importance d’éventuelles dérives.
Si on s’aperçoit que le projet ne rentre pas dans le planning ou dans le budget prévu il est alors possible de revoir le périmètre fonctionnel de la future l’application. Il est alors possible de chercher à le restreinte au seul noyau et de repousser une partie des demande à la prochaine version. Dans certains cas on peut envisager d’éclater le projet en deux et de confier leur réalisation à deux équipes différentes ou choisir de faire réaliser les deux projets successivement par la même équipe.
Une autre approche est possible !
Face à l’approche classique réputée lourde et lente on oppose souvent une possible démarche plus légère et plus rapide : l’approche agile. Ses défenseurs affirment que les projets connaissent moins d’échecs et moins de dérive. Comme on ne disposait pas jusqu’alors de statistiques il fallait les croire sur parole. Le rapport 2013 du Chaos Report du Standish Group analyse les probabilités de succès ou d’échec des petits projets (1 million de dollars en coût de développement ([6])) selon qu’ils utilisent une démarche en cascade ou une approche agile.
Enquête Globale
|
Démarche Agile
|
Approche cascade
| |
Succès
|
39 %
|
46 %
|
49 %
|
Dérive
|
43 %
|
48 %
|
43 %
|
Echec
|
18 %
|
6 %
|
8 %
|
Taux de succès, de dérive et d’échec des petits projets selon la démarche utilisée : agile ou cascade
On constate que les petits projets réussissent mieux que les grands car ils ont un taux d’échec plus faible. Mais surtout on observe qu’il n’y a pas de différence significative entre les deux approches. Plus étonnant : le modèle en cascade a un taux de succès supérieur à la démarche agile : 49 % contre 46 %. A l’inverse les projets en suivant une approche de type cascade dérivent moins : 43 % contre 48 %. Cependant, il faut être prudent, les écarts sont faibles et peu significatifs. Ce tableau montre, que contairement à ce qui est souvent affirmé, le recours aux démarches agiles n’améliore pas significativement les taux de succès des projets.
Ceci explique peut-être le faible rythme de baisse du pourcentage des projets dérivant qui sont passés en vingt ans de 53 % à 43 %. Les démarches de type agile ont l’avantage d’éviter de devoir effectuer une analyse fonctionnelle qui est toujours une étape longue mais elles n’évitent pas les risques de dérive. Pour lutter contre celle-ci la bonne pratique consiste à renforcer le travail effectué en amont notamment lors de l’expression des besoins de façon à avoir un périmètre fonctionnel stabilisé dès le début du processus de gestion de projet.
En guise de conclusion
Cette bonne pratique est évidente et devrait être connues de tous mais, il faut bien le constater, ce n’est pas toujours le cas. La preuve : le niveau élevé des projets qui dérivent reste encore important. Au lieu de s’échiner à trouver la démarche parfaite, qui n’existe peut-être pas, on devrait plutôt concentre les efforts sur la définition rapide du périmètre fonctionnel.
[1] - Chaos Manifesto 2013, Think Big, Act Small, The Standish Group.
[2] - La dérive moyenne des délais observée est de 74 % et la dérive des coûts est de 59 %. Dans ces cas on ne délivre en moyenne que 69 % des fonctions prévues. La dérive des délais et des coûts sont liés.
[3] - En anglais on utilise le terme « scope ». On peut le traduire par champ. En français on l’utilise peu et à peine plus celui de champ fonctionnel.
[4] - On appelle parfois ce type de représentation de l’urbanisme. Le terme est un peu grandiloquent. Celui de schéma fonctionnel est plus juste.
[5] - Le terme exigence est une mauvaise traduction de l’anglais requirement. Le terme spécification aurait été plus juste.
[6] - A mon avis en fixant le seuil des grands projets à 1 million de dollars le Standish Group met la barre un peu haute. Un projet d’un million de dollars est de l’ordre de 1.500 jours-hommes. Cela me semble un seuil un peu trop élevé. Personnellement, j’aurais plutôt mis le seuil vers 250.000 euros soit 340.000 dollars correspondant à environ 500 jours-hommes.
Aucun commentaire:
Enregistrer un commentaire