Les passations de projet sont là où l’élan se perd - sauf si vous disposez d’une checklist claire. Avec Trupeer, vous pouvez gagner des heures sur la documentation de passation en commençant par un modèle de checklist de passation de projet gratuit, en le personnalisant avec vos directives de marque, puis en transformant la checklist en une vidéo explicative que l’équipe qui reçoit pourra utiliser pour monter en compétence rapidement.

Qu’est-ce qu’un modèle de checklist de passation de projet ?

Une checklist de passation de projet est la liste des éléments qui doivent être vrais avant que la sortie d’un projet ne passe de l’équipe qui l’a construit à l’équipe qui va l’exploiter.

Elle couvre la documentation, la formation, les accès, les modalités de support, les défauts en suspens, la responsabilité et la validation formelle. Un modèle vous fournit les éléments et le bloc de validation.

La distinction à faire dès le départ est la suivante : ce n’est pas une passation personnelle. Quand une personne quitte un poste et le transmet à un successeur, le problème est le transfert de connaissances entre individus, et notre modèle de SOP de transfert de connaissances couvre cela.

Une passation de projet se fait entre organisations plutôt qu’entre personnes. Un projet se termine ; quelque chose continue. L’équipe qui reçoit va vivre avec cela pendant des années, et dans des conditions définies par le projet.

Une passation est une acceptation, pas une notification

Presque toutes les checklists de passation ont la même structure et la même propriété fatale. Elles sont complétées par l’équipe projet, élément par élément, puis signées par l’équipe qui reçoit à la fin.

Cette séquence rend la signature du destinataire une simple formalité. Au moment où on la demande, le projet est en train de se clôturer, le sponsor est dans la salle, le budget est en cours de libération et la date de livraison a été annoncée. Refuser à ce stade, c’est être la personne qui a bloqué un projet déjà terminé à la dernière étape.

Ainsi, la signature est donnée, et l’équipe qui reçoit passe les deux années suivantes à gérer ce qu’elle a signé.

Une acceptation est différente d’une notification sur un point seulement : le droit de refuser doit être réel. Cela exige deux conditions, et aucune n’apparaît dans une checklist de passation standard. Les critères doivent être rédigés par le destinataire plutôt que par le projet. Et ils doivent être convenus suffisamment tôt pour que refuser plus tard soit préautorisé, plutôt que politiquement coûteux.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Après avoir effectué tous les changements nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Aperçu et ajustements fins du modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.

Depuis l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle apparaît exactement comme vous le souhaitez.

Avec un modèle de checklist de passation de projet, vous pouvez :

• Gagner du temps sur les passations : évitez la page blanche grâce à une structure conçue pour les transitions de projet.

• Couvrir chaque livrable : des sections intégrées garantissent qu’aucun élément important n’est oublié.

• Rester conforme à votre charte : appliquez votre logo, vos polices et vos couleurs grâce au kit de marque de Trupeer.

• Former l’équipe qui reçoit plus rapidement : associez la checklist à une vidéo explicative.

• Standardiser les passations : utilisez le même modèle pour chaque transition de projet.

• Atteindre des équipes internationales : traduisez les checklists de passation en 65+ langues en un clic.

L’équipe qui reçoit n’a pas eu voix au chapitre sur la conception

Il vaut la peine de nommer l’asymétrie sous-jacente, car elle explique le comportement plutôt que d’accuser qui que ce soit.

Un projet est commandé par un sponsor, cadré par un chef de projet, puis livré par une équipe constituée à cette fin. Les personnes qui exploiteront ensuite le résultat sont généralement consultées au sujet des exigences, parfois, et presque jamais au sujet de la maintenabilité.

Elles héritent ensuite des conséquences : la charge d’astreinte, les contournements manuels, la dette technique, les défauts reportés, le prestataire dont le contrat de support couvre uniquement les heures ouvrées, et les plaintes des clients.

Aucune de ces choses n’est visible dans un document d’exigences, et aucune n’est, en particulier, la faute de quelqu’un. Les incitations de l’équipe projet visent la livraison. Les incitations de l’équipe d’exploitation visent les trois années suivantes. La passation est le point unique où ces deux ensembles d’incitations se rencontrent, et cela se produit le dernier jour, dans une salle où une partie a tout l’élan.

La solution consiste à déplacer la discussion vers un moment où les deux parties ont encore quelque chose à gagner.

Des critères d’acceptation rédigés par le destinataire pendant la planification

L’intervention est légère, et elle change toute la dynamique.

Au stade de la planification, avant le début de la livraison, l’équipe qui exploitera la sortie rédige les conditions selon lesquelles elle l’acceptera. Pas le projet. Eux.

Un ensemble viable tient généralement sur dix ou douze critères. Des runbooks existent pour chaque tâche planifiée ou automatisée. Aucun défaut au-dessus d’une sévérité convenue ne reste ouvert. L’astreinte et le support en dehors des heures ouvrées sont convenus et contractualisés, avec un coût connu. Le service desk a été formé, avec un taux de réussite documenté. La documentation telle que construite a été vérifiée par l’exploitation en réalisant un petit nombre de tâches réelles en utilisant uniquement cette documentation. Les accès et les autorisations sont transférés vers des comptes basés sur les rôles. Les modalités de support du prestataire sont en place et testées. La supervision et l’alerte existent et ont été prouvées.

Le sponsor du projet et le responsable de l’équipe qui reçoit signent cette liste pendant la planification.

Deux conséquences en découlent. Le projet peut planifier et budgéter pour répondre aux critères plutôt que de les découvrir à la fin, ce qui coûte moins cher pour tout le monde. Et refuser lors de la clôture devient l’application d’un accord préalable plutôt qu’un acte d’obstruction : la différence entre un droit qui existe sur le papier et un droit qu’une personne peut réellement utiliser.

Hypercare, et pourquoi le projet ne doit pas partir au go-live

Le deuxième mécanisme aligne les incitations après la signature, plutôt qu’avant.

Un projet qui passe la main au go-live et se dissout n’a aucun intérêt à ce qui se passe ensuite. Chaque défaut reporté, chaque tâche non documentée et chaque runbook manquant devient le problème de quelqu’un d’autre le lundi suivant.

Une période d’hypercare change cela. Pendant une période définie après la passation, généralement de trente à quatre-vingt-dix jours selon l’ampleur, l’équipe projet reste responsable. Des personnes nommées restent disponibles, le budget reste ouvert, et les défauts qui surviennent pendant cette fenêtre sont corrigés par le projet plutôt que soulevés comme un nouveau travail.

La valeur n’est pas principalement le support. Elle réside dans ce que cela change dans le comportement pendant la livraison. Une équipe qui sait qu’elle répondra au téléphone le premier mois documentera différemment au douzième mois.

Trois détails rendent cela efficace. Nommez les personnes, car « l’équipe projet » se disperse. Ouvrez explicitement le budget, car un engagement d’hypercare sans argent est une promesse que personne ne peut tenir. Et définissez ce que couvre l’hypercare, c’est-à-dire les défauts et les lacunes de connaissances, distinctement des nouvelles demandes : sinon, la période devient une fenêtre d’amélioration gratuite et le projet ne se clôture jamais.

Modèle gratuit de checklist de passation de projet : les éléments à copier

Copiez à partir d’ici. Les deux blocs marqués d’un astérisque sont les ajouts.

En-tête. Projet, sortie transmise, équipe qui transmet, équipe qui reçoit, date cible de passation, date de fin d’hypercare.

Critères d’acceptation, rédigés par le destinataire pendant la planification. Les dix à douze conditions, chacune avec un moyen de vérification et un oui ou un non. Cette section est complétée par l’équipe qui reçoit, pas par le projet.

Documentation. Description telle que construite vérifiée par rapport à la réalité. Runbooks pour chaque tâche planifiée. Limites connues et contournements actuels. Dossiers d’architecture ou d’actifs. Notre modèle de documentation de projet indique lesquels de ces éléments valent la peine d’être conservés.

Préparation opérationnelle. Supervision en place et testée. Alertes acheminées vers une destination réelle. Sauvegarde et restauration prouvées, pas seulement configurées. Capacité disponible indiquée. Parcours d’escalade nommé avec couverture en dehors des heures ouvrées.

Défauts et dette. Défauts ouverts listés par sévérité, avec responsables et dates cibles. Tout ce qui est délibérément reporté est consigné comme une décision plutôt que comme un oubli.

Formation et personnes. Qui a été formé, sur quoi, avec des preuves de compétence. Responsable nommé côté réception. Préparation du service desk.

Accès et administration. Comptes transférés vers des comptes basés sur les rôles plutôt que vers des individus nommés. Licences et contrats attribués. Modalités de support du prestataire testées.

Commercial. Coûts récurrents confirmés et budgétés. Conditions de garantie et date d’expiration. Contrats cédés si nécessaire.

Conditions d’hypercare. Durée, personnes nommées, ce qui est couvert et ce qui ne l’est pas, et comment cela se termine.

Validation. Partie qui transmet, partie qui reçoit et sponsor. Avec la date, et avec toute condition associée.

Copiez à partir d’ici.

La société dont le responsable des opérations a signé sous pression

Bramfield Group, une société de services professionnels d’environ deux mille deux cents personnes, a remplacé son système de gestion de la pratique. Seize mois, environ quatre millions six cent mille livres, livrés dans les délais.

La passation à l’exploitation IT a eu lieu au go-live. La checklist comportait trente-quatre éléments, tous complétés par l’équipe projet, et a été signée par le responsable de l’exploitation IT le jour où le projet a été clôturé.

Ce que l’exploitation a réellement reçu était moins encourageant que ce que suggéraient trente-quatre coches. Onze documents, dont quatre décrivaient le système tel qu’il était conçu plutôt que tel qu’il était construit. Aucun runbook pour les six tâches planifiées exécutées pendant la nuit. Quarante-sept défauts ouverts, dont neuf classés comme élevés. Aucune organisation d’astreinte, car le contrat de support du prestataire ne couvrait que les heures ouvrées. Et aucune formation du service desk, car il avait été supposé que le prestataire la fournirait.

Le responsable de l’exploitation a signé quand même. Interrogé après coup, il a déclaré que le projet se clôturait ce vendredi-là, que le sponsor était dans la salle, et que refuser aurait signifié être la personne qui a bloqué un projet de quatre millions et demi de livres au dernier obstacle.

Au cours des six mois suivants, il y a eu trois échecs de tâches nocturnes qui ont nécessité d’escalader vers un prestataire qui avait déjà quitté. La résolution au premier contact du service desk sur le nouveau système s’est établie à vingt-deux pour cent contre soixante et onze pour cent sur le système remplacé. Les neuf défauts de sévérité élevée ont nécessité une résolution médiane de quatorze semaines, car le budget du projet était clôturé et chacun exigeait son propre dossier d’affaires. L’exploitation IT a enregistré trois cent quarante heures de travail supplémentaire en heures supplémentaires, soit environ dix-neuf mille livres.

Le coût total non planifié sur les six mois, y compris la remédiation des défauts, s’est élevé à environ deux cent quarante mille livres.

Le programme suivant a fait deux choses différemment.

L’exploitation IT a rédigé douze critères d’acceptation au stade de la planification, y compris des runbooks pour chaque tâche planifiée, zéro défaut de sévérité élevée à la passation, une organisation d’astreinte contractualisée, un service desk formé avec un taux de réussite documenté, ainsi qu’une documentation telle que construite vérifiée par l’exploitation en réalisant trois tâches réelles en utilisant uniquement cette documentation. Le sponsor et le responsable de l’exploitation ont signé cette liste avant le début de la livraison.

Et une période d’hypercare de quatre-vingt-dix jours a été convenue, avec deux membres de l’équipe projet nommés conservés et le budget maintenu ouvert.

La première tentative de passation a échoué sur deux critères et a été corrigée en trois semaines. La résolution au premier contact du service desk a atteint soixante-quatre pour cent le premier mois. Il n’y a eu aucune escalade vers d’anciens membres de l’équipe projet. L’hypercare a consommé environ cent quarante heures du budget conservé.

Composants généraux d’une checklist de passation de projet

La ligne qui prédit le plus les autres est la première. Lorsque les critères d’acceptation proviennent du destinataire pendant la planification, les lignes restantes sont généralement respectées, car le projet a eu douze mois pour les préparer.

Les étapes d’une passation de projet réussie

Pendant la planification. L’équipe qui reçoit rédige les critères d’acceptation. Le sponsor et le destinataire signent. La date de passation et les conditions d’hypercare sont intégrées au plan, et notre modèle de plan de projet IT couvre la façon de rendre ces dates réelles plutôt que simplement souhaitées.

Pendant la livraison. La documentation et les runbooks s’accumulent plutôt que d’être produits à la fin. Le responsable nommé côté équipe qui reçoit assiste aux revues de conception pour tout ce qui impacte l’exploitabilité.

Quatre à six semaines avant la passation. Un test à blanc par rapport aux critères d’acceptation, afin que les échecs soient identifiés alors qu’il reste encore du temps. C’est l’étape qui transforme un refus en correction.

Lors de la passation. Vérification formelle par rapport aux critères, le destinataire effectuant la vérification plutôt que de lire un rapport. Validation avec toutes les conditions consignées.

Pendant l’hypercare. Les défauts et les lacunes de connaissances sont gérés par le projet. Un contrôle hebdomadaire entre les deux parties.

À la fin de l’hypercare. Une courte revue, la clôture du projet, puis le transfert des éléments restants vers le travail normal de l’équipe qui reçoit, avec des responsables.

Défis courants lors des passations de projet, et solutions

Le destinataire ne peut pas refuser. Des critères d’acceptation convenus pendant la planification, signés par le sponsor : c’est l’argument central de cette page.

La documentation décrit la conception plutôt que la réalisation. Vérifiez-la en demandant à l’exploitation d’effectuer des tâches réelles à partir de celle-ci : c’est le seul test qui fonctionne.

Runbooks manquants pour les tâches automatisées. Ils sont invisibles pendant la livraison parce qu’ils fonctionnent, et ils sont la cause la plus fréquente d’une escalade à trois heures du matin vers quelqu’un qui est parti.

Les défauts reportés deviennent permanents. Listez-les avec des responsables et des dates avant la validation, et traitez tout élément sans date comme un échec de critère.

Pas d’organisation d’astreinte. Peu coûteux à convenir pendant l’appel d’offres et coûteux à ajouter ensuite : il doit donc figurer dans les critères d’acceptation et dans le contrat.

Accès détenu par des individus. Transférez vers des comptes basés sur les rôles avant la passation, pas après le départ de quelqu’un.

Le projet se dissout au go-live. Hypercare, avec des personnes nommées et un budget maintenu ouvert.

Personne n’est responsable de la sortie. Nommez le responsable côté réception pendant la planification, pas lors de la clôture, et impliquez-le dans les revues de conception.

Passation de la construction et de l’IT, et en quoi elles diffèrent

La structure est commune et deux éléments diffèrent de manière significative.

Passation de la construction et des installations comporte une couche statutaire et contractuelle. La réception des travaux, la période de responsabilité pour défauts, la retenue, les validations des réglementations de construction, et le dossier santé et sécurité requis par les réglementations de construction, qui est un livrable distinct de la documentation d’exploitation. Le manuel d’exploitation et de maintenance est l’élément central de la passation et mérite un traitement à part, que notre modèle de manuel d’exploitation et de maintenance fournit, y compris pourquoi il est généralement accepté plutôt que vérifié.

Passation IT et logiciel n’a pas d’équivalent statutaire dans la plupart des cas, ce qui signifie que la discipline doit venir des critères d’acceptation plutôt que d’un contrat. Ses éléments distinctifs sont la supervision, les tests de restauration, l’astreinte, les seuils de sévérité des défauts et le transfert d’accès, et son risque distinctif est que tout semble aller bien jusqu’au premier échec en dehors des heures ouvrées.

Lorsque le changement est mis en production dans une fenêtre avec option de rollback, notre modèle de méthode de procédure couvre le basculement lui-même, qui est un document différent de la passation.

Passation de projet ou passation personnelle en quittant un poste ?

Deux documents, tous deux appelés passation, avec des problèmes différents.

Une passation de projet transfère une sortie d’une équipe qui livre vers une équipe qui exploite. Le problème concerne l’acceptation, l’exploitabilité et le coût récurrent : c’est largement une question commerciale et organisationnelle.

Une passation personnelle transfère un rôle d’un individu à son successeur. Le problème concerne les connaissances tacites, et c’est largement une question de ce que la personne qui part ne sait pas qu’elle sait. Notre modèle de SOP de transfert de connaissances couvre cela, y compris pourquoi demander à quelqu’un d’écrire ce qu’il sait produit sa description de poste plutôt que ses connaissances.

Si vous quittez un poste, vous voulez le second. Un modèle de checklist de passation de projet adapté à un usage personnel produit une liste de systèmes et de mots de passe, ce qui est la partie facile, et omet tout ce qui compte réellement.

Puis-je obtenir un modèle de checklist de passation de projet dans Excel ?

Excel, et c’est le bon choix pour une raison précise : les critères d’acceptation ont besoin d’une colonne de vérification et d’un statut, et la liste des défauts a besoin de la sévérité, du responsable et de la date. Ce sont deux tableaux qui se filtrent et se relisent plutôt que de se lire comme un texte.

Construisez-le en deux feuilles. Les critères d’acceptation avec des colonnes pour le critère, la façon dont il est vérifié, qui le vérifie, le statut et la date. Et le registre des défauts avec la sévérité, le responsable, la date cible et s’il est accepté comme reporté.

Word ou Google Docs pour l’accord de contexte : conditions d’hypercare, bloc de validation et toute condition associée à l’acceptation. C’est la partie qui est signée.

PDF pour la passation signée, archivée avec le dossier du projet. Étant donné qu’une passation est le document auquel les gens reviennent quand quelque chose se passe mal dix-huit mois plus tard, figer et dater la version signée compte davantage ici que pour la plupart des documents.

Comment produire des runbooks que l’équipe qui reçoit acceptera

Les runbooks sont l’élément le plus souvent manquant lors de la passation et celui qui cause le plus de dégâts, car une tâche planifiée qui s’est déroulée parfaitement pendant six mois de tests ne donne aucun avertissement que personne ne sait comment la récupérer.

Ils manquent pour une raison banale. Rédiger un runbook signifie documenter un processus qu’on a configuré des mois plus tôt, en détail, au moment du projet où il y a le moins de temps et le moins d’envie.

Trupeer AI supprime une grande partie de ce coût. Quiconque a construit ou exploite la tâche enregistre lui-même son exécution, y compris le chemin d’échec et de récupération, et la sortie est un runbook écrit avec les étapes et les écrans déjà capturés. Six tâches nocturnes deviennent un après-midi plutôt qu’une tâche cochée sans avoir été réellement faite.

Enregistrez-le. Marquez-le. Traduisez-le. Trupeerisez-le.

Cela rend aussi la documentation vérifiable, ce que les critères d’acceptation exigent : l’exploitation peut effectuer la tâche à partir du runbook plutôt que de le lire et d’espérer. Le créateur de SOP couvre les procédures, notre modèle de SOP IT couvre la décision de ce qui vaut la peine d’être maintenu, et le contenu vit dans votre base de connaissances avec une charte cohérente. Les instructions de configuration se trouvent dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il un modèle gratuit de checklist de passation de projet dans Excel ?

Excel est le bon format : les critères d’acceptation et le registre des défauts sont des feuilles séparées, avec des colonnes de vérification et de statut pour les deux. Il n’y a pas de téléchargement verrouillé et pas de formulaire. Le changement qui vaut la peine d’être fait par rapport à ce que vous utilisez déjà, c’est de faire remplir la feuille des critères par l’équipe qui reçoit pendant la planification, plutôt que par le projet lors de la clôture.

Existe-t-il un modèle gratuit de checklist de passation de projet dans Word ?

Word convient à l’accord autour de la checklist : conditions d’hypercare, validation et toute condition associée à l’acceptation. Conservez les tableaux de critères et de défauts dans un tableur, car les deux doivent être filtrés et aucun n’est lu comme un texte.

Où puis-je trouver un document de passation de projet au format PDF ?

Plusieurs universités et organismes publics publient les leurs, et ils valent la peine d’être lus pour la liste des éléments. Lisez-les pour la couverture plutôt que pour la structure, et vérifiez si l’un d’eux comporte des critères d’acceptation rédigés par la partie qui reçoit, car la plupart n’en ont pas : c’est la différence dont parle cette page.

Existe-t-il un modèle de passation quand on quitte un poste ?

Il s’agit d’une passation personnelle plutôt que d’une passation de projet, et elle nécessite une approche entièrement différente, car la partie difficile est la connaissance que vous ne réalisez pas avoir. Notre modèle de SOP de transfert de connaissances couvre cela, y compris une méthode qui fait ressortir ce qu’une liste ne fera pas.

Qui signe une passation de projet ?

Trois parties : l’équipe qui transmet, l’équipe qui reçoit et le sponsor. La signature du sponsor compte parce qu’elle rend le refus du destinataire légitime plutôt qu’obstructif, et c’est la raison pour laquelle les critères doivent être signés pendant la planification comme lors de la passation.

Quelle durée doit avoir une période d’hypercare ?

Trente jours pour quelque chose de petit, soixante à quatre-vingt-dix pour un système conséquent, et plus longtemps lorsque tout un cycle d’activité doit passer avant que les problèmes apparaissent, comme une fin de premier mois ou une fin de première année. Ce qui compte plus que la durée, c’est que des personnes nommées et un budget maintenu ouvert soient derrière.

Que se passe-t-il si l’équipe qui reçoit refuse la passation ?

Si les critères ont été convenus pendant la planification, la réponse est simple : le projet corrige les critères qui échouent et les re-présente. Dans l’exemple ci-dessus, la première tentative a échoué sur deux critères et a été résolue en trois semaines. Un refus sans critères préalables devient une négociation : c’est pourquoi les critères comptent plus que le droit de refuser.

Quelle est la différence entre passation et clôture ?

La passation transfère la sortie à ceux qui vont l’exploiter. La clôture met fin au projet : coûts finaux, contrats, ressources libérées, enregistrements archivés. Elles sont souvent réalisées le même jour, ce qui est une erreur, car la clôture supprime le budget et les personnes dont l’hypercare dépend. Passer la main, faire l’hypercare, puis clôturer.