Publié par SEO690281 le
Partie 4 de notre série « Gérer un projet IT » ! Dans les parties précédentes, nous évoquions les différentes étapes d’un projet puis nous avions détaillé les phases de contextualisation et de définition du projet.
Dans cet article, nous abordons un projet déjà en cours. Comment gérer les aléas, sans dépasser le budget et les délais ?
Dans un premier temps, la roadmap sert de guide aux membres de l’équipe, en donnant l’ordre dans lequel aborder les fonctionnalités. Mais quel que soit le projet, même le mieux préparé, des aléas et contre-temps arrivent. C’est dans ces moments que la roadmap, que nous avons établi dans la phase précédente, va prendre tout son sens car elle est un merveilleux outil d’aide à la décision !
Un projet a une enveloppe, une date de fin, des jalons. La roadmap peut donc aider le chef de projet et l’équipe projet à décider du contenu d’une livraison. En effet, comme expliqué précédemment, la roadmap indique pour chaque vague le contenu essentiel et le contenu espéré. A titre indicatif, le contenu essentiel ne représente que rarement plus de 60% de la charge disponible pour une même vague. Cela permet d’assurer sa livraison en temps et en heure dans la grande majorité des cas et très régulièrement d’ajouter certaines fonctionnalités « espérées ».
La roadmap permet donc plus de contrôle et de flexibilité sur les coûts et la gestion de ressources du projet.
Documenter l’avancée du projet est essentiel afin de faciliter la communication entre toutes les parties prenantes et de permettre à l’équipe projet de prendre ses décisions de manière éclairée. Cela permet également d’anticiper les éventuels aléas et d’en atténuer les conséquences.
Faire des points réguliers est nécessaire mais n’est pas toujours suffisant. Il ne faut pas oublier de consigner chaque décision prise tout au long du projet dans un document auquel tout le monde peut avoir accès. La roadmap fait bien sûr partie de ces documents mais on peut y ajouter la consignation des décisions prises en réunion, les démonstrations des fonctionnalités et les retours de tests ou tout autre document de suivi qui aura pu être défini au cours des phases précédentes.
Le tableau de bord de l’équipe est maintenant prêt, fonctionnel. Le projet se déroule. Le temps viendra d’y mettre un terme. Dans le prochain article, nous verrons que cela ne se limite pas à la mise en production des fonctionnalités. Il faut également s’intéresser à l’après. Dernière étape, dernier article… ne le manquez pas !