Vous le savez sûrement — enfin, je l’espère — un des éléments les plus importants dans les projets est l’identification des besoins d’affaires.
Cette activité se déroule pendant les phases de planification et d’analyse et il est nécessaire d’obtenir l’approbation de ceux-ci pour aller de l’avant dans le projet.
Pour mener à bien cet exercice, il est nécessaire de bien comprendre les processus « As-Is » pour ensuite définir un « To-Be » qui tiendra compte de l’ensemble des besoins, ces derniers devant être documentés dans une Matrice des Besoins (en anglais un Requirements Traceability Matrix).
L’exercice de cueillette des besoins se fait à travers des entrevues individuelles, des sessions de travail en groupe ainsi que l’analyse de certains documents, ex. des rapports. Or, un des dangers de cet exercice est de sombrer dans les détails et de perdre de vue l’essentiel de ce que nous cherchons à construire.
Lors des entrevues, les utilisateurs décrivent ce qu’ils font en détail, sans toutefois tenir compte que certaines actions/activités sont parfois une conséquence des limites des outils avec lesquels ils travaillent.
L’équipe d’analyse a alors la lourde tâche d’identifier ce qui est essentiel au processus — vs — ce qui est une conséquence d’un processus et d’outils limitatifs. Une incapacité à faire cela aura deux conséquences :
- L’échéancier risque d’être dépassé puisqu’un temps important sera accordé à l’analyse d’activités qui n’apporteront pas de valeur lorsque le nouveau processus et les nouveaux outils seront mis en place.
- Les processus « To-Be » et les nouveaux outils risquent de recréer des inefficacités liées aux paradigmes de l’ancien système.
Comment faire pour éviter ce piège ?
Tout d’abord, reconnaissez l’importance d’avoir de bons analystes d’affaires qui sauront mener les entrevues et les sessions de travail. Ensuite, assurez-vous d’identifier une ou des personnes dans l’organisation avec qui vous pourrez valider régulièrement les résultats de votre analyse. Cette personne ne devrait pas être votre « Key User », ce dernier faisant partie intégrante de l’équipe de projet, il/elle peut perdre l’objectivité nécessaire à mettre un terme à l’analyse des besoins.
Finalement, le gestionnaire de projet a aussi son rôle à jouer. Même s’il ne connaît pas tous les détails, il doit être en mesure de « flairer » une « suranalyse ».
Les approches de gestion de projet Agile peuvent aussi vous permettre d’éviter ce piège. En forçant la livraison de fonctionnalités, les utilisateurs autant que l’équipe de projet n’auront d’autre choix que de mettre l’emphase sur les éléments essentiels, mais surtout, les « démos » de fin de sprint aideront les utilisateurs à se libérer de leurs paradigmes.
