Agenda de réunion de lancement de projet pour les équipes d'ingénierie
La question que les réunions de lancement sautent
Un lancement de projet qui se déroule bien laisse l'équipe alignée sur ce qu'il faut construire, qui fait quoi, et quand les choses sont dues. Cet alignement tient généralement environ trois semaines. Ensuite le périmètre dérive, une partie prenante change d'avis sur une hypothèse fondamentale, une dépendance glisse, et l'équipe découvre qu'elle n'a jamais convenu de qui prend la décision quand deux personnes raisonnables ne sont pas d'accord.
La question que la plupart des agendas de lancement sautent est : comment cette équipe prendra-t-elle des décisions quand quelque chose tourne mal ? Pas le plan de projet — le cadre de prise de décision. Qui est responsable du périmètre quand une fonctionnalité doit être coupée ? Que fait l'équipe quand une contrainte technique invalide une exigence produit ? Quelle partie prenante a le dernier mot quand deux départements veulent des choses différentes ?
Ces questions sont faciles à répondre au lancement parce que rien n'est encore en jeu. Elles sont bien plus difficiles à répondre en cours de projet quand tout le monde a pris position. Le modèle ci-dessous réserve du temps pour elles avant que la partie difficile commence.
L'agenda (à copier-coller)
Durée : 60 à 90 minutes selon la complexité du projet
Format : Animé ; toutes les parties prenantes et contributeurs clés présents ou ayant consulté les documents avant le début
Section 1 — Objectif et périmètre du projet (20 min)
- Énoncer l'objectif en une phrase : à quoi ressemble le succès, mesurable si possible
- Dans le périmètre : ce que le projet livrera, nommé précisément
- Hors périmètre : ce que ce projet ne fera explicitement pas — lister au moins trois éléments
- Critères de succès : comment l'équipe saura-t-elle que le projet est terminé ?
- L'EM ou le PM anime cette section ; les ingénieurs s'expriment si le périmètre déclaré ne correspond pas à la faisabilité
Section 2 — Rôles et responsabilités (15 min)
- Pour chaque flux de travail, nommer un responsable — pas une équipe, une personne
- Qui a le dernier mot sur : le périmètre produit, l'architecture technique, les communications externes ?
- Qui est informé vs. consulté vs. décideur sur chaque type de décision majeure ?
- Nommer le chef de projet qui est redevable quand rien d'autre n'est clair
Section 3 — Contraintes et risques (15 min)
- Contraintes dures : délai, budget, conformité, dépendances vis-à-vis d'autres équipes
- Risques connus : quels sont les trois principaux facteurs qui pourraient faire dérailler ce projet ?
- Pour chaque risque : probabilité, impact, et responsable de la mitigation
- Qu'est-ce qui causerait l'annulation ou la réduction significative du projet ? Nommez-le maintenant
Section 4 — Plan de communication (10 min)
- À quelle fréquence l'équipe se synchronisera-t-elle ? Sous quel format ?
- Qui reçoit une mise à jour de statut, et comment ? Ne supposez pas que les parties prenantes veulent le même canal
- Où vit la documentation du projet ?
- Quel est le chemin d'escalade si quelque chose bloque le projet ?
Section 5 — Questions ouvertes (15 min)
- Lister toutes les questions auxquelles l'équipe ne peut pas répondre aujourd'hui
- Pour chacune : assigner un responsable et une date limite à laquelle la réponse est nécessaire
- Les questions sans date et sans responsable seront toujours ouvertes à mi-parcours
Section 6 — Prochaines étapes (10 min)
- Les trois choses qui doivent se produire dans les cinq prochains jours ouvrés pour démarrer le vrai travail
- Chaque prochaine étape a un seul responsable
- Confirmer comment le récapitulatif du lancement sera distribué et à qui
Ce que les modèles de lancement populaires ratent
La plupart des modèles de lancement sont exhaustifs sur le plan de projet et superficiels sur ce qui se passe quand le plan ne tient pas. Ils produisent un document de périmètre propre et une matrice RACI, ce qui est utile. Ils ne produisent pas de réponse partagée à « que faisons-nous quand le fournisseur de base de données triple ses prix en cours de projet ? » ou « qu'est-ce qu'on coupe si on atteint la date limite dure à 80 % des fonctionnalités complètes ? »
L'absence de périmètre exclu est l'autre lacune constante. Énoncer ce qui est dans le périmètre est simple. Énoncer ce qui est explicitement hors périmètre — lister trois ou quatre choses spécifiques que le projet ne fera pas — force la même conversation sur les attentes des parties prenantes mais depuis l'autre direction. Les parties prenantes qui allaient supposer que le client mobile était inclus le découvrent au lancement plutôt qu'en semaine six.
La troisième lacune est la section des questions ouvertes. Les équipes ne veulent pas faire remonter ce qu'elles ne savent pas au lancement parce que ça donne l'impression d'admettre un manque de préparation. Mais les réponses inconnues deviennent des blocages en cours de projet, et les blocages en cours de projet sont coûteux. Plus tôt vous savez que la question existe, plus tôt quelqu'un peut en prendre la responsabilité.
Pour voir comment ces lacunes s'accumulent en surcharge sur un projet de plusieurs mois : La taxe des réunions.
Pourquoi les notes de lancement valent la peine d'être bien faites
Le document de lancement est l'artefact le plus fréquemment consulté dans tout projet. C'est ce que les gens vérifient quand le périmètre est contesté, quand un nouveau membre rejoint l'équipe, quand une partie prenante demande « n'avons-nous pas décidé X au lancement ? » Un lancement bien documenté est un projet plus facile à gérer.
Pavleur capture le lancement complet automatiquement : le périmètre tel qu'énoncé, les rôles tels qu'assignés, les risques tels que nommés, les questions ouvertes avec leurs responsables, les prochaines étapes avec leurs responsables et dates. Si quelqu'un a partagé son écran avec le brief projet, un diagramme ou un document de spécifications en cours de réunion, le visuel est inclus dans le rapport avec la discussion. Les outils audio seuls vous donnent qui a dit quoi ; ils ne capturent pas le diagramme d'architecture à l'écran quand le tech lead décrivait la dépendance. Le rapport résultant sert de document de référence du projet dès le premier jour. Pour comparer cela aux outils de capture de réunion traditionnels : Pavleur face aux alternatives.
Une note sur la présence
Toute personne censée prendre une décision sur ce projet devrait assister au lancement, ou consulter un enregistrement complet et un résumé écrit avant que le travail commence. Une partie prenante qui manque le lancement et apprend le périmètre de manière informelle deux semaines plus tard est un litige de périmètre en cours de projet en attente de se produire. Le rôle du lancement est de construire un contexte partagé, et le contexte partagé n'existe que si les personnes concernées sont dans la salle.