Une présentation de lancement de projet doit laisser à l’équipe un périmètre partagé, des responsabilités nommées et un premier point de contrôle. Profitez de la réunion pour trancher les choix qui conditionnent la suite, pas pour lire tout le plan de projet. Un ordre du jour concis et un relevé de décisions visible sont plus utiles qu’une longue présentation de contexte.
Prenons un projet fictif de portail de demandes internes. La première version permettra aux salariés de demander du matériel ou un déplacement, et aux approbateurs d’accepter ou de retourner ces demandes. La réunion doit déterminer si les demandes d’accès font aussi partie de cette version.
L’ordre du jour et le tableau de périmètre ci-dessous peuvent servir à créer une présentation de lancement à partir de texte dans Presenti. Ajoutez les données de votre projet avant de générer le brouillon, puis consignez les décisions dans les diapositives ou le journal de décisions de l’équipe.
Un ordre du jour de 30 minutes à adapter
Envoyez l’ordre du jour avec un bref résumé du projet en amont. Les participants doivent savoir quelle décision attend leur contribution et quels documents servent de contexte. Si un désaccord risque de prendre quinze minutes, réservez ce temps au lieu de le dissimuler derrière les présentations des participants.
| Horaire | Discussion | Résultat attendu |
|---|---|---|
| 00:00–04:00 | Pourquoi ce projet existe et à qui il s’adresse | Un objectif de projet partagé |
| 04:00–12:00 | Périmètre de la première version et choix concernant les demandes d’accès | Éléments inclus, exclus et encore ouverts consignés |
| 12:00–18:00 | Responsabilités et pouvoir de décision | Responsables de la réalisation, de l’acceptation et de la dépendance non résolue |
| 18:00–25:00 | Premier point de contrôle et dépendances | Livrable, condition d’acceptation et date visée |
| 25:00–30:00 | Relire les décisions et confirmer les prochaines actions | Relevé de décisions et date de la prochaine réunion |
Ce calendrier est un exemple, pas une règle universelle. Un lancement réunissant plusieurs entreprises peut nécessiter des séances distinctes sur les contrats, la sécurité ou la conception technique. Prévoyez-les explicitement plutôt que de transformer le lancement en atelier à tout faire.
Rendez le choix de périmètre visible
« Construire un portail de demandes » laisse trop de place à l’interprétation. Montrez le périmètre de la version sur une diapositive, avec une ligne distincte pour le choix non résolu. Voici le point de départ de l’équipe fictive :
| Élément | Position initiale | Décision à prendre |
|---|---|---|
| Demande de matériel | Première version | Champs obligatoires et rôle d’approbation |
| Demande de déplacement | Première version | Transmission de l’approbation au service financier |
| Demande d’accès | Non tranché | Inclure une approbation manuelle ou reporter jusqu’à clarification de l’intégration avec la gestion des identités ? |
| Attribution automatique des accès | Hors première version | Aucun engagement lors de cette réunion |
Le commanditaire choisit de reporter les demandes d’accès : l’équipe destinataire et le travail d’intégration ne sont pas encore définis. Notez le choix et sa raison : « Les demandes d’accès sont exclues de la première version ; l’équipe informatique estimera le travail avant la prochaine revue du périmètre. » Ne transformez pas « reporté » en « bientôt disponible » sur une diapositive ultérieure.
Remplacez l’organigramme par trois questions de responsabilité
Précisez qui pilote le travail, qui accepte le résultat et qui peut modifier le périmètre. Ici, le responsable de réalisation coordonne le développement ; le responsable de l’exploitation accepte le pilote selon les critères définis ; le commanditaire décide si un nouveau type de demande modifie le périmètre de la version. Le contact du service financier fournit les règles d’approbation des déplacements, mais ne devient pas automatiquement responsable du projet.
Si vous utilisez RACI, écrivez l’action à côté des initiales. « Accountable : commanditaire » renseigne moins que « Le commanditaire approuve les changements de périmètre de la première version ». Pour une dépendance, indiquez le responsable qui reçoit la demande, pas seulement la personne qui l’envoie.
Les recommandations de PMI sur la réunion de lancement abordent objectifs, inclusions et exclusions du périmètre, stratégie, risques, hypothèses et responsabilités. La présentation ouvre ces sujets à la discussion ; elle ne remplace ni l’autorisation du projet ni un plan détaillé.
Définissez ce que le premier point de contrôle doit démontrer
Le premier point de contrôle de cette équipe teste le parcours d’une demande de matériel ; ce n’est pas simplement « prototype terminé ». Un salarié participant au pilote doit pouvoir soumettre une demande, un approbateur la retourner avec un motif, et le salarié retrouver le résultat. Le responsable de l’exploitation observe le test et décide si ce parcours est prêt pour un petit pilote.
Placez les prérequis à côté de la date : le service financier doit fournir la règle d’approbation et l’équipe informatique les comptes de test. Si l’un des deux est en retard, l’équipe revoit le point de contrôle au lieu de raccourcir discrètement les tests. Appliquez aux jalons suivants la même logique : un livrable et une condition d’acceptation. Avant de vous engager sur ce point de contrôle, une présentation de planification des capacités permet de rapprocher le travail nécessaire des heures réellement disponibles dans l’équipe.
Relisez ce relevé de décisions avant de conclure
L’intervenant peut terminer la réunion avec ce relevé, complété pendant la discussion :
Décision : La première version inclut les demandes de matériel et de déplacement. Exclusions : Demandes d’accès et attribution automatique des accès. Motif : Le responsable des demandes d’accès et l’effort d’intégration restent à définir. Prochaine action : L’informatique estime le parcours des demandes d’accès pour la prochaine revue du périmètre. Premier point de contrôle : Soumettre, retourner et retrouver une demande de matériel. Responsable de l’acceptation : Responsable de l’exploitation. Dépendances : Comptes de test et règles d’approbation du service financier. Prochaine revue : [date et responsable de la réunion].
Diffusez ce relevé avec les diapositives après la réunion. Les nouveaux membres doivent pouvoir distinguer le périmètre accepté des idées évoquées. Lorsqu’un choix change, ajoutez le motif et le responsable au lieu d’effacer l’historique.
Construisez la présentation de lancement dans Presenti à partir de l’ordre du jour, du tableau de périmètre et du point de contrôle. Une présentation utile aide encore l’équipe lorsque surgit la première question de périmètre ; elle ne se contente pas d’être élégante le jour de la réunion.
