Organiser les responsabilités et la communication

1. Repérer les personnes concernées

Une partie prenante peut contribuer au projet, décider de ses ressources, utiliser son résultat ou subir ses conséquences. La liste ne se limite donc pas aux développeurs et au sponsor. Les clients pilotes, le support, le responsable technique et le chargé d’affaires doivent être considérés.

Pour chaque partie prenante, noter ses attentes, son influence, les informations dont elle a besoin et la manière de l’associer. Cette analyse évolue : un service peu concerné au début peut devenir essentiel lors de la mise en exploitation.

Une matrice influence-intérêt aide à préparer les échanges, mais ne doit pas enfermer les personnes dans une étiquette. Une personne peu influente peut détenir une information indispensable sur le travail réel.

2. Distinguer coordination et décision

Le sponsor porte la justification et les arbitrages qui dépassent l’équipe. Le chef de projet coordonne la préparation, le suivi et les alertes dans le mandat reçu. Les experts et contributeurs réalisent le travail et fournissent les estimations techniques. Le représentant des utilisateurs aide à préciser le besoin et à vérifier l’usage.

Ces responsabilités doivent être adaptées à la taille du projet. Une même personne peut cumuler plusieurs responsabilités, à condition que les arbitrages restent explicites. Dans Scrum, les responsabilités de Product Owner, Scrum Master et Developers répondent à un cadre particulier étudié plus loin ; elles ne se déduisent pas automatiquement d’un organigramme classique.

3. Construire une matrice RACI

RACI relie les activités ou livrables aux responsabilités : R réalise, A répond de la décision ou du résultat, C est consulté et I est informé. La convention du cours retient un seul A par ligne, afin d’éviter une validation sans responsable clairement identifié.

Une matrice se discute avec les personnes concernées. Elle ne leur attribue pas silencieusement une autorité qu’elles n’ont pas. Trop de personnes consultées sur chaque détail peuvent aussi ralentir le projet : la consultation doit servir une décision précise.

4. Préparer un plan de communication

Un échange utile précise son destinataire, sa fréquence, son support et son résultat attendu. Un point opérationnel identifie les blocages immédiats ; une revue avec le sponsor prépare les arbitrages ; une démonstration recueille des retours sur le produit.

Le compte rendu conserve les décisions, les actions, leurs responsables et leurs échéances. Il n’a pas besoin de retranscrire chaque phrase. « L’équipe discutera du risque » ne permet pas de suivre une action ; « le responsable technique teste l’export avant vendredi et communique le résultat » est vérifiable.

Chez NKILItech, un tableau partagé peut présenter les actions et un journal séparé conserver les décisions importantes. Il faut également prévoir comment alerter sans attendre la réunion suivante lorsqu’une échéance critique devient menacée.

5. Traiter les désaccords et protéger la capacité

Un désaccord peut porter sur le besoin, la priorité, l’estimation ou la solution. Avant de chercher un compromis, identifier le point réellement contesté et les faits disponibles. Un prototype ou un test limité peut parfois résoudre une incertitude plus vite qu’une longue discussion.

La disponibilité annoncée doit tenir compte du support courant, des congés et des autres engagements. Une personne disponible deux jours par semaine ne représente pas une capacité de cinq jours pour le projet. Une allocation théorique irréaliste produit un retard prévisible.

Escalader signifie transmettre une décision au bon niveau, avec des options et leurs conséquences. Cela n’exonère pas l’équipe de proposer un choix argumenté.

Exercices corrigés