Une présentation de passation de projet doit montrer si l’équipe qui prend le relais peut assumer la responsabilité du travail, et pas seulement si l’équipe projet a terminé sa réalisation. Expliquez ce qui a été accepté, ce que l’équipe repreneuse a démontré, les points encore ouverts et qui interviendra après le transfert.
Séparez trois décisions : accepter un livrable, autoriser sa mise en exploitation et clôturer formellement le projet. Elles peuvent intervenir à des moments différents. Une fois les preuves et les responsabilités proposées clairement établies, transformez la synthèse de passation en un premier diaporama modifiable. Les diapositives facilitent l’examen de ces décisions ; elles ne les prennent pas à la place des responsables.
Nommer précisément ce qui est transféré
« Le projet est terminé » est trop vague pour guider l’équipe suivante. Indiquez le service, le processus ou l’actif transféré, sa version, le responsable qui le reprend et le moment prévu pour le transfert. Précisez ce qui reste explicitement hors du périmètre, par exemple une future fonction de reporting ou un ancien processus sans lien avec la passation.
Les travaux de l’APM sur la passation de projet, en anglais considèrent la passation comme une transition plutôt que comme une date unique. Ils mettent l’accent sur des responsabilités claires, un transfert de connaissances utile et l’implication des futurs utilisateurs. C’est une base pertinente pour le diaporama : montrer les conditions d’une prise en charge, pas une ligne d’arrivée symbolique.
Dans l’exemple, un projet a mis en place un nouveau processus de demande de matériel pour une équipe d’exploitation interne. Le périmètre comprend un formulaire, des règles d’acheminement, un guide d’exploitation et une procédure pour les exceptions. Le responsable des opérations doit en reprendre la responsabilité. Ce projet fictif illustre la réunion de passation ; il ne correspond pas à un déploiement de Presenti et ne décrit pas des fonctions d’automatisation du produit.
La première diapositive pourrait annoncer : « Transférer le processus de demande de matériel uniquement après acceptation de la procédure d’exception, réussite de la mise en situation du remplaçant et accord sur la responsabilité du support. » Ce titre indique la proposition et les conditions qui empêchent encore le transfert. Il ne cache pas un point non résolu derrière un statut vert « terminé ».
Distinguer les livrables acceptés de la préparation opérationnelle
Préparez un court registre des livrables avant de concevoir le diaporama. Pour chaque résultat important, indiquez la version, le critère d’acceptation et la preuve. « Envoyé aux opérations » décrit une livraison ; cela ne démontre pas que les opérations l’ont examiné ou accepté.
| Livrable | Preuve dans le projet fictif | Ce qui reste à faire |
|---|---|---|
| Formulaire de demande v1.3 | Le responsable repreneur a accepté les champs obligatoires et envoyé une demande de test normale. | Aucun problème de formulaire ouvert n’est enregistré. |
| Règles d’acheminement v1.2 | Les demandes normales ont atteint la file de traitement attribuée à l’équipe repreneuse pendant le test. | Le scénario de remplacement en cas d’absence n’a pas encore été validé de bout en bout. |
| Guide d’exploitation v1.0 | Le responsable principal a suivi la procédure standard sans être guidé à chaque étape par le chef de projet. | Le remplaçant n’a pas pu ouvrir les instructions relatives aux exceptions pendant l’exercice. |
| Procédure d’exception v0.9 | Un brouillon désigne le rôle proposé pour les remontées de problèmes. | L’équipe repreneuse n’a ni accepté la procédure ni démontré son application. |
Conservez la véritable preuve d’acceptation dans le système de suivi convenu pour le projet, avec la personne habilitée, la date et la version. Ajoutez un lien ou une référence depuis la diapositive. Une synthèse dans un diaporama ne remplace pas les documents d’approbation exigés par le contrat ou l’organisation.
Ne transformez pas le tableau en « prêt à 75 % » parce que trois lignes paraissent presque terminées. Les éléments ne sont pas des unités équivalentes de préparation, et une seule exception non maîtrisée peut compter davantage que plusieurs documents achevés. Nommez directement la condition restante.
Montrer ce que l’équipe peut faire sans vous
La diapositive la plus révélatrice vient souvent d’une répétition menée par l’équipe qui prend le relais. Choisissez des actions proches du travail quotidien et une exception plausible. Le but est de repérer les connaissances, les accès ou les responsabilités qui manquent pendant que l’équipe projet reste disponible.
Dans l’exemple, demandez à l’équipe de traiter une demande normale, de retrouver la procédure à jour, de gérer une demande en l’absence du responsable principal et d’indiquer où consigner une exception non résolue. Utilisez des données de test autorisées et l’environnement convenu pour l’exercice.
Pendant cette répétition fictive, la demande normale aboutit. Le cas d’absence arrive dans la file du remplaçant, mais celui-ci ne peut pas ouvrir les instructions d’exception. Ce constat est plus précis et plus utile que « la formation est incomplète ». Il identifie un manque concret d’accès et de procédure, auquel on peut affecter un responsable avant de refaire le test.
La correction ne consiste pas simplement à envoyer un document supplémentaire. Faites établir l’accès approuvé par la personne responsable, confirmez la version de la procédure à utiliser et rejouez le même scénario d’absence. Consignez ce qui s’est passé. Participer à une formation ne prouve pas que cette tâche précise peut être réalisée.
Si la répétition ne peut pas être terminée avant le transfert prévu, expliquez pourquoi et qui peut accepter le risque qui en découle. Ne présentez pas comme réussi un test qui n’a pas eu lieu. Si la condition restante empêche une utilisation sûre ou praticable, proposez de différer cette partie du transfert plutôt que d’affaiblir le critère d’acceptation par une reformulation.
Consigner ce qu’un nouveau test réussi change réellement
Poursuivons le cas fictif des demandes de matériel par une deuxième répétition, R2, après correction du droit d’accès. Il s’agit d’un exemple de compte rendu rempli, pas d’un test effectué par Presenti. La première répétition décrite plus haut reste R1 ; son échec n’est pas effacé. R2 utilise un environnement de test autorisé et des demandes d’essai permises, en l’absence du responsable principal.
| Champ du compte rendu R2 | Entrée dans l’exemple fictif |
|---|---|
| Scénario et versions | Le remplaçant traite une demande exceptionnelle ; formulaire v1.3, règles d’acheminement v1.2, guide v1.0 et projet de procédure d’exception v0.9. |
| Comportement attendu | Retrouver la demande, ouvrir les instructions à jour, suivre le traitement des exceptions et consigner le résultat sans aide du chef de projet. |
| Comportement observé | La demande arrive dans la file du remplaçant. Celui-ci ouvre les instructions, suit le circuit d’escalade prévu pour le test et consigne le résultat sans aide. |
| Preuves à conserver | Compte rendu du scénario, historique de la demande d’essai, versions des procédures et observation de l’équipe repreneuse. Dans un projet réel, joindre leurs références exactes et la date du test. |
| Condition résolue | Le défaut d’accès n’empêche plus de mener à bien ce scénario testé. |
| Conditions encore ouvertes | La procédure v0.9 reste un projet en attente d’acceptation par l’équipe repreneuse ; la responsabilité du support après transfert n’est toujours pas convenue. |
La diapositive de décision peut désormais indiquer : « Différer le transfert opérationnel. Le remplaçant a terminé R2 : le défaut d’accès est résolu pour ce scénario. Le responsable repreneur doit encore confirmer la version acceptée de la procédure d’exception. Le commanditaire et le responsable repreneur doivent convenir de la responsabilité du support. La responsabilité opérationnelle actuelle reste en place ; la date du transfert n’est pas fixée. » Le progrès est visible sans faire disparaître les conditions restantes.
Si les preuves manquantes sont fournies par la suite, la personne habilitée peut réexaminer le transfert. La nouvelle trace de décision doit préciser les preuves examinées, les versions et limites acceptées, le responsable repreneur et le moment où le transfert prend effet. Si une modification de procédure change les étapes testées, déterminez si R2 les couvre encore ou si une autre répétition est nécessaire. Ne réutilisez pas automatiquement l’ancien résultat.
Le tableau suivant conserve les conditions initiales de R1. Dans votre registre de travail, gardez cet historique et ajoutez le résultat de R2 au point relatif à l’accès. Ne clôturez pas les points « procédure » et « support » simplement parce qu’ils figurent dans le même tableau.
Attribuer aux points ouverts des responsabilités et des limites claires
Une passation peut comporter du travail non terminé, mais chaque point ouvert exige un accord explicite. Montrez qui en assure la résolution, qui prend en charge le fonctionnement quotidien dans l’intervalle, quelle limite temporaire s’applique et qui est habilité à l’accepter. Ces rôles peuvent être différents.
| Point ouvert | Organisation proposée | Preuve nécessaire pour le clore |
|---|---|---|
| Le remplaçant ne peut pas accéder aux instructions d’exception | Le responsable des accès côté projet corrige l’autorisation ; le responsable repreneur organise le nouveau test. | Le remplaçant mène le scénario d’absence à bien avec le guide actuel. |
| La procédure d’exception n’est pas acceptée | Le responsable des opérations examine la procédure avec le chef de projet ; une liste de présence en réunion ne vaut pas approbation implicite. | La trace d’approbation identifie la version acceptée et ses éventuelles limites. |
| La responsabilité du support après transfert n’est pas convenue | Le commanditaire et le responsable repreneur confirment les contacts, la période de couverture et le circuit de remontée des problèmes. | Les deux équipes savent quel rôle traite chaque type de demande. |
Dans cet exemple, le transfert proposé reste soumis aux deux premières conditions. L’organisation du support doit elle aussi être convenue avant le changement de responsabilité. Le tableau présente des propositions, pas des engagements déjà pris par des personnes réelles.
Dans un autre projet, un défaut visuel sans conséquence importante pourrait être accepté comme travail ultérieur. Cela ne crée pas une règle générale autorisant le transfert de tous les défauts. Appuyez-vous sur les véritables critères d’acceptation et pouvoirs de décision ; rendez chaque limite visible pour les personnes qui exploiteront le résultat.
Rendre compréhensible la première semaine d’exploitation
Une diapositive de support doit expliquer ce qui se passe quand quelqu’un a besoin d’aide après le transfert. Nommez le contact opérationnel principal, son remplaçant, le contact projet pendant la période d’assistance convenue et le circuit à utiliser pour un problème urgent. Précisez quand cette organisation temporaire prend fin ou sera réexaminée.
N’inventez pas une promesse de support de deux semaines parce qu’elle tient bien sur la diapositive. Si la durée ou la disponibilité n’est pas convenue, indiquez qu’une décision reste nécessaire. Distinguez une demande d’aide d’une autorisation de modifier le périmètre accepté.
Dans l’exemple, le responsable repreneur propose une revue des exceptions non résolues pendant la première semaine. Elle doit vérifier si le remplacement fonctionne réellement et si le guide demande une correction. Elle ne rouvre pas implicitement le périmètre achevé du projet et ne garantit pas que chaque nouvelle demande sera traitée par l’équipe projet.
Rendez faciles à trouver le guide actuel, les preuves d’acceptation et le registre des points ouverts. Si ce changement s’inscrit dans un plan opérationnel plus large, rattachez-le aux responsables et rythmes de suivi du plan opérationnel, présentés dans ce guide en anglais, au lieu de créer des responsabilités contradictoires dans les diapositives.
Conduire la discussion de passation en six diapositives
La réunion doit aboutir à une décision sur la responsabilité, pas simplement constater qu’un diaporama a été présenté.
- Proposition de transfert : processus, version, responsable repreneur, moment prévu et conditions éventuelles.
- Périmètre accepté : principaux livrables, preuves d’acceptation et exclusions explicites.
- Démonstration de l’équipe repreneuse : tâches normales et exceptions testées, résultats réels et lacunes.
- Points ouverts : blocages, travaux ultérieurs acceptés, responsables et preuves nécessaires pour chaque résolution.
- Support opérationnel : contacts, remplacement, assistance temporaire du projet et limites du circuit de remontée.
- Trace de décision : poursuivre, poursuivre dans les limites approuvées ou différer ; consigner la décision autorisée et la prochaine revue.
Utilisez un tableau étroit pour les conditions non résolues et une chronologie simple pour la responsabilité du support. Évitez de réduire un plan de projet entier sur une seule diapositive. Les procédures détaillées restent dans les documents référencés ; le diaporama porte les preuves et les choix dont l’équipe repreneuse a besoin maintenant.
Partir des preuves, puis consigner la véritable décision
Utilisez les consignes suivantes après avoir remplacé l’exemple par des informations approuvées. Conservez la distinction entre une tâche achevée, un livrable accepté et une action proposée.
Les consignes ci-dessous utilisent la situation du premier exercice R1, avant la suite hypothétique R2. Si vous présentez une situation ultérieure, remplacez les statuts concernés par les résultats et approbations effectivement consignés. Ne combinez pas un nouveau test réussi avec l’ancienne affirmation qu’aucun nouveau test n’a encore été validé.
Crée une présentation de passation de projet en six diapositives pour le processus fictif de demande de matériel décrit ci-dessus. Le public est composé du commanditaire et de l’équipe d’exploitation repreneuse. Présente le transfert proposé, le périmètre accepté, les résultats réels de la répétition, les conditions non résolues, l’organisation du support et la décision demandée. La demande normale a réussi ; le remplaçant n’a pas pu ouvrir les instructions d’exception pendant l’exercice et le nouveau test n’a pas encore été validé ; la procédure d’exception n’est pas acceptée. Ne marque pas le projet comme clôturé, n’invente pas d’approbations et ne présente pas le support proposé comme déjà convenu. Identifie clairement les responsables et les dates manquants comme des informations à compléter.
Lisez attentivement la conclusion générée. « Prêt pour la passation » déformerait la source ; « Prêt une fois les conditions indiquées remplies » conserve le cadre de la décision proposée. Comparez la dernière diapositive au véritable résultat de la réunion avant de la diffuser.
Après la décision autorisée, mettez à jour le responsable repreneur, la date d’effet, les limites acceptées et les actions restantes dans le dossier source comme dans le diaporama. La clôture du projet peut ensuite être examinée selon le fonctionnement habituel de l’organisation. Une passation utile permet à l’équipe de travailler à partir de ce qu’elle reçoit ; elle ne se mesure pas à l’assurance de la diapositive finale.
