Après une revue d’affaires incluant une étude de terrain et une analyse cognitive des tâches, il a été constaté que le nouveau logiciel nécessitait trois fois plus d’actions de la part des utilisateurs. Le chef de projet a réagi en déclarant que le périmètre du projet est de faire la transition, de respecter les délais et le budget. En d’autres termes, il ne souhaitait pas modifier le plan.
Après avoir réexaminé les résultats, ils ont réalisé que la situation était encore pire que prévu. Au final, le client a suivi nos recommandations parce que les faits étaient indiscutables et nous avons trouvé une solution qui permettait d’intégrer la technologie existante déjà en usage au sein de l’institution financière.
De nombreux projets informatiques sont planifiés et définis avant même que l’analyse des besoins ou les études de terrain ne soient effectuées. Au cours des vingt dernières années de redressement de projets, nous avons rencontré des centaines de situations similaires.
L’année dernière, nous avons participé à un camp de formation de trois jours organisé par le PMI (Project Management Institute). Ce qui nous a le plus étonnés, c’est l’acceptation généralisée par la communauté du PMI de l’ironie de la planification et de l’estimation pour les projets logiciels.
Voici le problème :
Pour estimer un projet, vous devez d’abord connaître la quantité de travail nécessaire pour mener à bien ce projet. Construire deux (2) km de route nécessitera deux fois plus de travail que de construire un (1) km.
Dans un projet logiciel, la quantité de travail est définie par ce que vous allez construire (les fonctions). Vous aurez une bonne idée des fonctions que vous allez construire après la phase de spécification fonctionnelle. Étant donné que la spécification fonctionnelle est généralement réalisée après la planification et l’estimation, vous obtenez les informations nécessaires pour estimer le projet après son démarrage. C’est un peu comme si vous deviez planifier et budgéter le traitement médical avant que le diagnostic ne soit établi.
Je peux vous assurer que, dans la physique, mon précédent domaine, vous seriez licencié ou mis de côté assez rapidement si vous proposiez quelque chose de ce genre.
De plus, l’estimation lors de la phase de planification relève de la spéculation. Dans la méthodologie PMI, ils mentionnent des techniques ésotériques telles que la méthode des points de fonction ou les données historiques, ou encore d’autres combinaisons, mais, à notre avis, il s’agit d’une couverture sophistiquée pour de la spéculation. Oui, il existe des méthodes de calcul, mais les hypothèses d’entrée sont basées sur des jugements humains (des suppositions). Ces jugements varient d’une personne à l’autre. Souvent, l’estimateur n’a aucune idée des affaires et des opérations. Par exemple, les architectes logiciels estiment après avoir rencontré les représentants des utilisateurs, qui ont eux-mêmes rencontré les analystes commerciaux, qui n’ont jamais rencontré les utilisateurs finaux.
Typiquement, une fois les estimations faites, le budget, le périmètre et le calendrier sont établis. Le conseil approuve le budget, les personnes sont embauchées et l’exécution du projet commence. Si vous découvrez au cours du projet que les besoins réels de l’entreprise diffèrent de ce que vous aviez prévu, l’histoire ci-dessus se répète. Le chef de projet vous dira que c’est hors du périmètre. Ou il pourrait vous dire que vos nouvelles découvertes pourraient être classées comme un changement à la fin du projet. N’oubliez pas qu’il a été embauché pour exécuter le plan, même s’il s’avère erroné. N’est-ce pas ?