Pour continuer notre série sur la gestion d’un projet IT, nous abordons aujourd’hui la définition du projet. La connaissance du contexte acquise dans la phase précédente (voir notre article) nous a permis d’avoir une idée globale du projet et de ses enjeux. Il s’agit aujourd’hui de définir les ressources à mobiliser pour en assurer une bonne gestion.
L’un des points les plus importants de la définition du projet est de constituer l’équipe. Dans l’idéal, LES équipes. Nous essayons toujours d’avoir une équipe projet, une équipe étendue et un réseau d’experts.
L’équipe projet ne changera pas, ou très peu, tout au long du projet. Elle concentre toutes les informations et assure sa continuité. C’est elle qui s’assurera que le projet reste sur le droit chemin. Ses membres seront le point de contact des personnes extérieures concernant le projet. Idéalement, en plus du chef de projet, les différents services concernés doivent y être représentés par une ou deux personnes. Cette équipe doit rester de taille réduite autant que possible pour faciliter la communication.
La première de ses tâches sera de définir la matrice de responsabilités. Pour chaque sujet qui sera abordé, il faut identifier la personne capable de prendre la décision finale et d’arbitrer en cas de divergence. Les décisionnaires seront les responsables de chaque domaine côté client. Si un domaine n’a pas de responsable défini clairement dès le lancement, plusieurs difficultés peuvent apparaitre : pas ou délai de prise de décisions par l’équipe, remise en cause des choix effectués… Assigner un responsable a posteriori est plus compliqué car sa légitimité et l’assimilation du contexte peuvent être longues à acquérir.
L’équipe étendue sera, elle, constituée des différentes personnes ou équipes de travail chez chaque partie prenante intervenant au cours du projet. Les décisionnaires évoqués plus haut en font également partie. Chaque représentant des différentes parties prenantes (prestataires, différents services…) définit la matrice de responsabilités de son équipe afin d’être assisté au mieux dans son rôle.
Les experts sont appelés ponctuellement sur le projet, suivant les besoins. Ils sont les référents sur un sujet donné, apportant leurs connaissances sur des points très précis moins bien connus des membres des équipes projet et étendue. Ces dernières pourront donc se reposer sur eux et monter en compétences dans le domaine concerné.
Une fois l’équipe formée, les règles de gestion de projet peuvent être définies. Quels outils vont accueillir quelles informations, la fréquence des réunions et des reportings, dans quels cas l’équipe étendue est réunie, sur quels sujets des experts seront requis, quels sont les ateliers de travail nécessaires et qui doit y participer…
Lors de la première phase, nous avions défini le fil rouge du projet. Il s’agit maintenant d’approfondir chaque sujet. Toutes les fonctionnalités envisagées lors des premières phases doivent être revues et détaillées. Certaines peuvent également se rajouter tant qu’elles s’inscrivent dans la logique globale du projet.
Nous analysons ensuite la liste obtenue afin d’aboutir à la meilleure organisation possible. La première chose à prendre en compte est l’importance de chaque fonctionnalité pour le client. Différentes méthodes peuvent être utilisées pour classifier les différents besoins, comme la méthode MOSCOW (qui fera l’objet d’un article dédié). Il est important d’évaluer la complexité fonctionnelle d’un sujet (qui impactera le temps de définition de la solution et donc le temps où les équipes du client devront être disponibles) et le temps de réalisation de la solution technique (qui impactera la disponibilité des équipes de réalisation).
Ces pondérations vont permettre de programmer dans le temps les différentes fonctionnalités et de les répartir de manière équilibrée dans les vagues de développements successives. Cette liste ordonnée va constituer la roadmap du projet, avec ses différents jalons. Chaque vague contiendra une liste de fonctionnalités à réaliser absolument et une liste dans laquelle il sera possible de piocher si le projet avance plus vite que prévu. C’est l’un des documents les plus importants, qui va vivre tout au long du projet. Il faudra garder à l’esprit que pour un projet à réaliser dans un temps fini, le nombre de fonctionnalités pouvant être traitées est limité. Ainsi, si au cours du projet, une fonctionnalité de la seconde liste (« si on a le temps ») devient une fonctionnalité à réaliser absolument, cela signifiera la plupart du temps d’en déclasser d’autres.
Pourquoi constituer une telle liste ? Nous allons le voir dans le prochain article ! Le projet étant préparé, il peut se lancer ! Nous traiterons le suivi d’un projet en cours, dans lequel la roadmap aura un rôle prépondérant.