Généralement, aux dires des Gestionnaires, les projets de développement TI sont tous urgents, mais la réalité est que certains le sont plus que d’autres !
Typiquement, en mode agile, on parle de sprints de 3 semaines suite au sprint 0 qui est le sprint initial de « définition ». Cependant, on rencontre de plus en plus de situations où le client demande un développement Agile+++ ou, si vous préférez, des projets qui nécessitent un développement en mode Agile accéléré… très accéléré !
On parlera d’un, deux ou trois sprints très courts (une ou deux semaines maximum) avec des livrables et des attentes bien définis.
Est-ce que les demandes sont irréalistes ? Est-ce que la planification a été déficiente ? Ça, c’est une autre histoire… Une chose est certaine est qu’en mode Agile+++, il n’y a pas de place pour le « red tape », on veut des ressources compétentes qui collaborent entre elles et qui sont motivées à livrer !
Et comment tout cela s’exécute-t-il ? Alors, commençons par le commencement.
L’occasion fait le larron
Il y a plusieurs raisons pour lesquelles un client fera appel à une firme externe pour son développement logiciel.
La première, et l’une des plus importantes, est pour aller chercher de la compétence. Il s’agira d’une entreprise (de tout acabit) qui ne possède pas à l’interne l’expertise nécessaire à un nouveau projet de développement urgent.
La deuxième est généralement un manque de capacité :
- Il peut s’agir d’une grande entreprise avec son propre département TI mais dont le département n’a tout simplement pas le temps de réaliser ce projet spécifique de développement TI. D’un autre côté, la collaboration avec cette équipe sera primordiale.
- Il peut aussi s’agir d’une PME n’ayant pas d’équipe de développement à l’interne ou dont les ressources sont limitées.
On pourrait qualifier la troisième de « le feu est pris » :
C’est le cas d’une organisation qui se fait imposer un changement dû à un changement de réglementation, d’orientation ou autre. Par exemple, ce sera le cas épineux où une entreprise d’une bonne envergure et menant de front plusieurs projets de développement pour répondre à un changement d’orientation technologique et dont certains sont dépendants des autres, et qui a besoin de synchroniser les livrables de 3 ou 4 projets de développement simultanés; elle fera donc appel à une firme externe pour mener à bien l’un ou certains de ces projets.
Rien ne sert de courir… il faut partir avant le temps !
L’expérience nous apprend que le meilleur des plans ne tient pas face à la réalité, en TI plus qu’ailleurs, mais l’idée, c’est de mettre toutes les chances de votre côté, surtout quand les délais sont serrés.
Plus haut, on a parlé de compétence. Pour augmenter les chances de succès, il faut d’abord compter sur un ou de bons analystes qui sauront mettre noir sur blanc, une bonne définition de la portée du projet (scope) et des livrables attendus. Et s’y tenir, s’y conformer !
Et pour cela, il vous faudra pouvoir compter sur un bon Gestionnaire de Projet et un bon Product Owner, deux postes clés dans la réussite de tout projet de développement TI.
Évidemment, les développeurs devront être des gens d’expérience et être motivés.
Facteurs clés de la réussite d’un projet de développement TI
On ne saurait être plus basique que cela; vous devez mettre en place de bons outils de suivi qui généreront de bonnes métriques, des mesures significatives telles que le calcul de la projection du projet : heures exécutées à ce jour + reste à faire.
Il faut mettre en place une bonne communication; c’est-à-dire créer de bons canaux de communication :
- Préconiser la méthode agile SCRUM
- Impliquer une ressource décisionnelle avec pouvoir exécutoire
- Identifier une ressource possédant la connaissance de l’intelligence d’affaires de l’entreprise (probablement le « product owner »)
- Planifier de courtes réunions à fréquence déterminée avec les décisionnels du projet afin de communiquer le vrai statut de celui-ci
- Prévoir une cellule de crise (CTO, directeur TI, gestionnaire de projets) pour pouvoir réagir rapidement
- Capitaliser sur la transparence : il faut pouvoir dire ce qu’il en est (qualité pas au rendez-vous, attentes irréalistes, refus de demande de changements, etc.), ne pas avoir peur de se dire les vraies affaires
Post Mortem, pour le prochain projet de développement TI
Étonnamment, peu de gestionnaires de projets le réalisent mais il faut préparer la rétrospective (debriefing) pendant le projet.
On parle ici d’Intelligence technologique. Les personnes clés du projet doivent avoir le réflexe d’inventorier les notes, les minutes, les décisions critiques (architecture, UI, fonctionnalités, etc.) prises au cours du projet afin d’en évaluer les impacts qui se transformeront potentiellement en tâches et recommandations dans le cadre d’étapes ultérieures ou de futurs projets de développement.