Une présentation de demande de modification de projet doit montrer la différence entre le plan approuvé et le changement proposé. Donnez à la personne qui décide l’engagement actuel, l’ajout demandé, ses conséquences et des options claires. Une nouvelle exigence n’est pas approuvée simplement parce qu’elle figure sur la dernière diapositive.
Une fois l’analyse d’impact validée par les responsables concernés, vous pouvez organiser la demande de modification en un premier diaporama avec Presenti. Conservez les hypothèses et le statut d’approbation dans le texte fourni. Ils font partie de la demande et ne sont pas des détails à supprimer lors de la synthèse.
Commencer par le plan de référence approuvé
Supposons qu’une équipe prépare un pilote interne de réservation. Le périmètre convenu comprend un formulaire de réservation, des confirmations par e-mail et un rapport hebdomadaire d’utilisation. Le lancement du pilote est prévu à la fin de la sixième semaine, avec un budget approuvé de 40 000 dollars américains. Le commanditaire demande maintenant une authentification unique avant le démarrage du pilote.
Ces chiffres de planification sont fictifs et servent tout au long de l’exemple. Les estimations de l’équipe sont des hypothèses pédagogiques, pas des tarifs ni des engagements de livraison pour une intégration réelle.
La première diapositive doit préciser ce qui est déjà engagé et ce qui est demandé. Placez la version du plan de référence ou la référence de son approbation à côté du périmètre pour permettre aux participants de la vérifier. Si le plan actuel a déjà évolué, réconciliez d’abord les versions avant de le comparer à une nouvelle proposition.
Les recommandations de Microsoft pour évaluer les modifications de projet abordent les effets sur les exigences, le financement et les dates, ainsi que l’autorité nécessaire pour approuver une demande. Le diaporama doit suivre les règles d’approbation réelles du projet. Un modèle générique ne peut pas déterminer qui détient cette autorité.
Montrer l’impact supplémentaire, pas seulement un nouveau total
Dans l’exemple, le responsable technique estime que l’ajout de l’authentification unique nécessite 8 000 dollars américains au-delà du budget approuvé et dix jours ouvrés supplémentaires au calendrier actuel. L’estimation suppose que la configuration des identités, les comptes de test et les personnes chargées de la revue seront disponibles au moment voulu. Ces hypothèses doivent apparaître à côté du chiffre.
| Élément | Plan approuvé | Modification proposée | Résultat en cas d’approbation |
|---|---|---|---|
| Périmètre | Formulaire de réservation, confirmations par e-mail, rapport hebdomadaire | Ajouter l’authentification unique | Périmètre existant, intégration et travaux de recette convenus |
| Budget | 40 000 dollars américains | Ajout estimé à 8 000 dollars américains | Total estimé à 48 000 dollars américains |
| Lancement du pilote | Fin de la sixième semaine | Prolongation estimée à dix jours ouvrés | Fin de la huitième semaine selon le calendrier de cinq jours par semaine de l’exemple, sans jours fériés ni conflits de ressources |
| Dépendances | Prérequis actuels du pilote | Configuration des identités, comptes de test, revue de l’intégration | L’estimation doit être réexaminée si un prérequis arrive en retard |
L’ajout représente 20 % du budget initial : 8 000 ÷ 40 000 dollars américains. Ce pourcentage apporte du contexte ; ce n’est pas une règle d’approbation automatique. De même, dix jours de travail estimés ne signifient pas nécessairement dix jours de retard au lancement. Ici, l’exemple suppose explicitement que le travail supplémentaire prolonge la séquence d’activités qui détermine le lancement. Dans un vrai plan, montrez les dépendances et les capacités disponibles qui justifient l’effet sur le calendrier.
Évitez d’annoncer une nouvelle date exacte si l’équipe n’a fourni qu’une durée et des prérequis non confirmés. Si une date précise est nécessaire, calculez-la sur le calendrier du projet avec la personne responsable du planning.
Présenter des choix qui peuvent réellement être approuvés
« Accepter ou refuser » peut masquer une option intermédiaire utile. Pour cette demande, comparez trois approches sur une même base :
| Option | Ce qui change | Conséquence principale | Ce qui doit être confirmé |
|---|---|---|---|
| Ajouter l’intégration avant le lancement | Conserver tous les livrables actuels et ajouter l’authentification unique | Total estimé à 48 000 dollars américains et prolongation de dix jours ouvrés | Dépendances, capacité de revue et approbation de la modification |
| Conserver le pilote actuel ; prévoir l’intégration ensuite | Maintenir le périmètre approuvé du pilote ; étudier une version ultérieure distincte | Le lancement initial reste la référence de planification | Acceptabilité du dispositif d’accès existant et éventuel travail supplémentaire lié à une intégration ultérieure |
| Échanger des éléments du périmètre du pilote | Étudier le remplacement ou le report d’un autre livrable | Effets sur le coût et la date pas encore estimés | Livrable pouvant être déplacé, dépendances associées et estimation révisée |
La troisième option ne signifie pas automatiquement « même budget, même date ». Supprimer un rapport ne prouve pas que les mêmes personnes ou le même temps peuvent être réaffectés à une intégration. Indiquez clairement qu’une option n’est pas chiffrée et demandez une analyse d’impact si elle reste intéressante.
La deuxième option comporte aussi une condition. Si la nouvelle exigence est indispensable au fonctionnement du pilote, il peut être impossible de la reporter. La présentation doit faire apparaître ce fait, plutôt que de conserver dans le tableau un choix commode mais inutilisable.
Structurer la demande de modification en six diapositives
- La décision demandée. Identifiez la modification, l’option recommandée et la date à laquelle la décision est nécessaire.
- L’engagement actuel. Montrez le périmètre, le budget et les jalons approuvés avec la référence du plan initial.
- Le motif de la demande. Expliquez qui a besoin de la modification et ce qui se passe si elle est reportée. Distinguez une obligation d’une préférence.
- L’impact. Présentez les ajouts en coûts, délais, travail et dépendances. Attribuez les estimations aux responsables concernés.
- Les alternatives. Comparez les choix réalisables et la question non résolue pour chacun.
- La trace de la décision. Prévoyez des champs explicites pour la décision réelle, les conditions, la personne qui décide et la date.
Placez les détails de conception technique et la décomposition des estimations en annexe. La séquence principale doit expliquer les conséquences sans obliger la personne qui approuve à examiner chaque tâche. Une vue du périmètre avant et après est souvent plus claire qu’une feuille de route générale où la nouvelle exigence se perd parmi les travaux existants.
Traiter les incertitudes et les informations tardives en réunion
Si une dépendance change pendant la réunion, montrez quelle partie de la recommandation elle affecte. Par exemple, l’absence de comptes de test peut invalider la prolongation de dix jours. Consignez le besoin d’une estimation actualisée au lieu de défendre un chiffre devenu obsolète.
Une décision conditionnelle doit être tout aussi précise. « Poursuivre si le responsable technique confirme l’estimation et si le commanditaire approuve le supplément budgétaire » ne signifie pas « Approuvé ». Ne colorez pas les deux statuts en vert et ne retirez pas les conditions de la dernière diapositive.
Après la réunion, conservez la version de la demande qui a été discutée et rattachez-y la décision consignée. Ne modifiez le plan de réalisation que par le processus de gestion des modifications convenu pour le projet. Une présentation révisée ne suffit pas à indiquer à l’équipe quel périmètre, quelle date ou quel budget fait désormais autorité.
Préserver le statut de la décision dans le texte de départ
Collez les consignes relues dans Presenti pour les organiser en un premier diaporama modifiable. Incluez le plan de référence, les estimations et les hypothèses du projet dans le texte source ; un simple sujet comme « demande de modification » laisserait trop d’éléments du dossier sans précision.
Crée une présentation de six diapositives pour une demande de modification d’un pilote interne fictif de réservation. Périmètre approuvé : formulaire de réservation, confirmations par e-mail, rapport hebdomadaire d’utilisation. Budget approuvé : 40 000 dollars américains. Lancement prévu : fin de la sixième semaine. Ajout demandé : authentification unique avant le lancement du pilote. Estimation du responsable technique : 8 000 dollars américains supplémentaires et dix jours ouvrés prolongeant la séquence qui détermine le lancement, à condition que la configuration des identités, les comptes de test et les personnes chargées de la revue soient disponibles. Utilise une semaine de cinq jours ouvrés sans jours fériés uniquement pour cet exemple. Compare l’ajout immédiat, le maintien du pilote actuel avec étude d’une version ultérieure, et l’échange d’éléments du périmètre sous réserve d’une nouvelle estimation. N’attribue ni coût ni date à cet échange non chiffré. Garde visibles les exigences obligatoires, les hypothèses et les conditions d’approbation. Laisse vides les champs de décision réelle et de personne habilitée à approuver ; n’invente pas d’approbation.
Relisez le premier diaporama pour repérer les glissements de sens : « estimé » devenu « confirmé », une option conditionnelle transformée en promesse, ou un champ vide remplacé par une approbation. Ces changements comptent davantage que le choix du thème graphique. Le diaporama final doit faciliter l’examen de la demande tout en préservant les engagements initiaux.
