Sujet 5.1 — Travail piloté par le projet

En une phrase : Le travail piloté par le projet est le bon outil lorsque le travail a un périmètre défini, une vie finie, et un état final clair — un effort temporaire et contrôlé livré selon un temps, coût, et qualité convenus, puis clos.

Pourquoi c'est important dans la santé et l'action sociale#

Tout n'est pas un service vivant. Une partie du travail le plus important dans la santé et l'action sociale est véritablement finie : migrer d'un dossier de santé électronique à un autre, déployer le Wi-Fi à travers un parc hospitalier, remplacer des serveurs en fin de vie, désengager un système hérité avant la fin d'un contrat fournisseur, ou livrer l'élément numérique d'une nouvelle construction hospitalière. Ce travail a un début, un milieu, et une fin définie. Le gérer comme un produit sans fin gaspillerait de l'argent et brouillerait la responsabilité ; il a besoin de la discipline d'un projet.

La gestion de projet gagne sa place ici précisément parce que les enjeux sont élevés et les contraintes dures. Une bascule de migration de données a un week-end de mise en production fixe, un risque de sécurité patient si les dossiers sont perdus ou corrompus, et une falaise contractuelle si l'ancien système s'éteint. L'argent public est engagé contre un dossier commercial, et le Parlement, les auditeurs, et les conseils d'administration demanderont s'il a été dépensé comme approuvé. Le travail piloté par le projet fournit la gouvernance — un dossier commercial, des portes d'étape, et une clôture contrôlée — qui permet à un conseil d'administration d'engager du capital avec confiance et d'arrêter le travail proprement si la justification disparaît.

Le danger est d'utiliser cet outil pour le mauvais travail. La gouvernance pilotée par le projet appliquée à un service numérique évolutif produit la pathologie « construire et abandonner » décrite au Sujet 5.0 — Travail piloté par le produit. Ce sujet explique où le travail piloté par le projet est le bon instrument, et où ses limites commencent. Il se situe aux côtés du Sujet 5.2 — Travail piloté par le programme, qui coordonne de multiples projets, et du Sujet 5.3 — Gestion de portefeuille et projets d'entreprise (EPPM), qui choisit entre ces outils.

Concepts fondamentaux#

Projet. Une organisation temporaire créée pour livrer un ou plusieurs livrables définis selon une spécification convenue, dans les contraintes de temps, coût, et qualité. La caractéristique définissante est qu'il est temporaire — il existe pour atteindre une fin définie puis se dissoudre.

Le triangle de fer (périmètre, temps, coût). Le modèle de contrainte classique : le périmètre, le calendrier, et le budget sont interdépendants, et la qualité est affectée par comment ils sont équilibrés. Changez-en un et vous changez les autres ; le contrôle de projet est largement la discipline de gérer ce compromis de manière transparente.

PRINCE2 (PRojects IN Controlled Environments). La méthode de projet structurée du gouvernement britannique, largement utilisée à travers le NHS et le secteur public. Elle est construite sur des principes (justification commerciale continue, rôles définis, gérer par étapes, gérer par exception, se concentrer sur les produits, apprendre de l'expérience, adapter à l'environnement) et organise le travail en étapes contrôlées avec un comité de projet fournissant la direction.

PMI / PMBOK. Le Guide to the Project Management Body of Knowledge du Project Management Institute est le contrepoint international dominant, cadrant le travail de projet autour de domaines de performance et de principes plutôt qu'un processus par étapes prescrit. PRINCE2 et PMBOK sont des prismes complémentaires sur la même discipline.

Dossier commercial. Le document qui justifie le projet : le problème, les options évaluées, les bénéfices attendus, les coûts, et les risques. Dans PRINCE2, le dossier commercial est vivant — il est vérifié à chaque frontière d'étape, et si la justification continue disparaît, la bonne décision est d'arrêter. Dans les organismes publics britanniques, cela est habituellement structuré comme le modèle des cinq cas du HM Treasury (stratégique, économique, commercial, financier, de gestion).

Portes d'étape. Un projet PRINCE2 est divisé en étapes de gestion séparées par des portes de décision. À chaque frontière, le comité de projet prend une décision délibérée arrêt/continuer : il révise le progrès et le dossier commercial, approuve le plan de l'étape suivante, et n'engage des ressources que pour cette étape. C'est comment un conseil d'administration garde le contrôle et évite de jeter du bon argent après du mauvais.

Registre RAID. Un registre unique de Risques, Hypothèses, Problèmes (Issues), et Dépendances — l'artefact de contrôle central du chef de projet. RAID rend l'incertitude visible et gérable : les risques sont des choses qui pourraient se produire, les problèmes sont des choses qui se sont produites, les hypothèses sont ce sur quoi le plan repose, et les dépendances sont ce dont le plan a besoin d'ailleurs.

Bonnes pratiques#

1. Commencez par un dossier commercial honnête et gardez-le vivant. Utilisez une structure reconnue (le modèle des cinq cas dans les organismes publics britanniques) pour évaluer de véritables options, pas une seule réponse prédéterminée. Puis traitez le dossier commercial comme un document vivant révisé à chaque porte d'étape — la justification commerciale continue est le premier principe PRINCE2, et la perdre est une raison légitime d'arrêter.

2. Définissez le périmètre précisément et contrôlez les changements qui lui sont apportés. La valeur d'un projet est une définition claire et bornée de « terminé ». Convenez du périmètre, établissez-en la base, et acheminez chaque changement proposé via un processus de contrôle de changement afin que le glissement de périmètre ne consomme pas discrètement le budget et le calendrier.

3. Gérez par étapes avec de véritables portes de décision. Divisez le travail en étapes de gestion et tenez une véritable révision arrêt/continuer à chaque frontière. Une porte qui dit toujours « continuer » est du théâtre ; la discipline ne fonctionne que si arrêter ou replanifier est une véritable option que le conseil d'administration exercera.

4. Exploitez un registre RAID vivant et escaladez par exception. Maintenez les Risques, Hypothèses, Problèmes, et Dépendances en un seul endroit, révisez-le régulièrement, et utilisez le « gérer par exception » de PRINCE2 — le chef de projet fonctionne à l'intérieur de tolérances convenues et escalade au conseil d'administration seulement quand une tolérance est menacée. Cela garde le temps senior concentré sur de véritables décisions.

5. Assignez une responsabilité claire et à point unique. PRINCE2 insiste sur des rôles définis : un comité de projet avec un propriétaire responsable senior/exécutif possédant le dossier commercial, un utilisateur senior représentant ceux qui utiliseront le livrable, et un fournisseur senior. Une responsabilité ambiguë est la cause la plus courante de dérive.

6. Planifiez la transition vers le service en direct avant de commencer. Un projet livre un livrable ; quelqu'un doit l'exploiter ensuite. Convenez de l'équipe réceptrice, du modèle de support, et de la transmission de sécurité clinique (DCB0160 pour le déploiement) comme partie du projet, afin que la mise en production ne soit pas une falaise vers un vide de propriété.

7. Intégrez la sécurité clinique, la gouvernance de l'information, et les tests. Pour tout système touchant les données patient, le dossier de sécurité clinique, la DPIA, et les tests de bascule/retour en arrière ne sont pas des extras optionnels — ce sont des livrables de porte. Une migration sans plan de retour en arrière testé n'est pas prête pour la mise en production.

8. Clôturez le projet délibérément et capturez les leçons. Une fin définie signifie une clôture définie : confirmez que les livrables sont acceptés, transmettez aux opérations, libérez l'équipe, et enregistrez les leçons apprises (le journal des leçons de PRINCE2). Un projet non clôturé fuit des ressources et de la responsabilité indéfiniment.

Questions à discuter avec votre équipe#

1. Le travail devant nous est-il véritablement fini avec un état final défini, ou tendons-nous la main vers la gouvernance de projet car c'est la voie de financement que nous connaissons ? C'est la question décisive sur laquelle le sujet tourne, car la discipline pilotée par le projet est le bon instrument seulement quand le travail a véritablement un début, un milieu, et une fin définie. Dans une organisation de santé et d'action sociale, l'attraction vers la forme de projet est forte — la budgétisation en capital, la machinerie de dossier commercial, et le rapport au conseil d'administration sont tous construits pour cela — donc un service numérique évolutif peut être habillé en projet simplement parce que c'est comment l'argent est libéré, ce qui produit ensuite la pathologie de construction-et-abandon. Le débat devrait examiner chaque candidat honnêtement : un remplacement de système de pathologie avant qu'un fournisseur ne retire le support a une falaise contractuelle dure et est sans ambiguïté fini, tandis que « améliorer l'application patient » n'a aucun état final et appartient au Sujet 5.0. Considérez s'il y a une véritable mise en production après laquelle l'équipe devrait se dissoudre, ou si quelqu'un devra continuer à améliorer la chose indéfiniment. Une bonne réponse résiste à utiliser la gouvernance de projet comme une habitude, nomme l'état final concret et l'événement qui définit « terminé », et est disposée à dire qu'une partie de ce que nous exploitons actuellement comme des projets n'aurait jamais dû en être.

2. À nos portes d'étape, ce conseil d'administration arrêterait-il ou replanifierait-il réellement un projet qui a perdu sa justification — et pouvons-nous pointer vers un moment où nous l'avons fait ? Les portes d'étape ne sont un contrôle que si arrêter est une véritable option que le conseil d'administration exercera ; une porte qui dit toujours « continuer » est du théâtre, et la justification commerciale continue est le premier principe PRINCE2 précisément parce que la perdre devrait mettre fin au travail. La tension dans la santé et l'action sociale est aiguë : arrêter une migration EPR à moitié construite ou une bascule de système de laboratoire ressemble à admettre l'échec, gaspiller un coût irrécupérable, et perturber des cliniciens qui ont déjà changé leurs plans, donc les conseils d'administration rationalisent de continuer même tandis que le dossier commercial s'évapore discrètement. Apportez un véritable exemple à la discussion — un projet où les tests ont révélé que le risque de mappage de données était pire que supposé, ou où les bénéfices ont glissé — et demandez si la porte a été utilisée comme conçue ou tamponnée automatiquement. Considérez quelles tolérances déclenchent l'escalade, qui au conseil d'administration a la position pour appeler un arrêt, et si le raisonnement de coût irrécupérable est nommé et contesté dans la pièce. Une réponse honnête admet où les portes ont été des formalités, décrit les conditions sous lesquelles le conseil d'administration arrêterait ou recadrerait véritablement, et traite l'autorité d'arrêter avant une perte publique comme la véritable valeur de la discipline plutôt qu'une menace.

3. Qui reçoit le livrable de chaque projet comme un service en direct, et comment rendons-nous la transmission de sécurité clinique et la propriété continue un livrable de porte plutôt qu'une falaise ? Un projet livre un livrable ; quelque chose de fini se termine, mais la chose qu'il a produite doit être exploitée, améliorée, et gardée sûre longtemps après que l'équipe se dissout — et l'échec silencieux le plus courant est que personne ne la possède de l'autre côté. Dans un système touchant les données patient, ce n'est pas de l'ordre administratif : le dossier de sécurité de déploiement DCB0160, la DPIA, un retour en arrière testé, et une équipe réceptrice nommée sont ce qui se tient entre une mise en production contrôlée et un vide de propriété où les risques de sécurité s'accumulent non gérés. Le débat devrait forcer la clarté sur la transition avant que le projet ne commence, pas au week-end de mise en production : quelle équipe opérationnelle le prend, quel est le modèle de support, et si cette équipe a la capacité et le mode de travail (piloté par le produit, selon le Sujet 5.0) pour continuer à l'améliorer. Considérez des mises en production récentes concrètes et si la transmission était planifiée ou improvisée, et si « le projet est terminé » a été autorisé à signifier « et maintenant ce n'est le travail de personne ». Une bonne réponse nomme l'équipe réceptrice et le modèle de support en amont, traite la transmission de sécurité comme une porte que le projet ne peut pas passer sans, et assigne explicitement l'amélioration continue du service en direct au bon mode de travail plutôt que de le laisser dériver.

4. Lorsque le triangle de fer mord et que le périmètre, le temps, et le coût entrent en collision, quelle contrainte fléchissons-nous, et la sécurité patient est-elle jamais autorisée à être la variable qui cède ? Chaque véritable projet finit par frapper le moment où le calendrier, le budget, et le périmètre promis ne peuvent pas tous tenir, et comment l'équipe résout cette pression révèle ce qu'elle valorise réellement. Dans la santé et l'action sociale, le piège est distinctif : parce que la date de fin est souvent une falaise contractuelle dure — un fournisseur retirant le support, un bail expirant, un centre de données fermant — le temps ne peut souvent pas bouger, donc la pression atterrit silencieusement sur la qualité, ce qui dans un système clinique signifie couper les tests, compresser la validation, ou livrer avec des défauts de mappage de données connus. La discussion devrait nommer, à l'avance, quel coin du triangle l'organisation protégera et lequel elle sacrifiera, et être explicite que la sécurité clinique et la gouvernance de l'information ne sont pas la soupape de décharge même quand tout le reste est fixe. Regardez une bascule récente et demandez ce qui a discrètement cédé quand les dates ont tenu : était-ce la répétition de retour en arrière, la fenêtre de validation clinique, la formation ? Considérez qui a l'autorité de déplacer la date de mise en production plutôt que d'éroder la marge de sécurité, et si cette conversation se passe ouvertement au conseil d'administration ou par défaut sur le terrain. Une réponse honnête énonce l'ordre de priorité avant la pression, traite une date glissée ou une étape replanifiée comme un résultat légitime, et refuse de laisser une pression de calendrier tacite se convertir en risque clinique non consigné.

5. Notre registre RAID est-il un instrument vivant qui change ce que nous faisons, ou un document que nous maintenons pour paraître gouvernés — et ferait-il surgir le risque qui coule réellement le projet ? Un registre RAID ne gagne sa place que si le réviser change les décisions ; la pathologie courante est un registre écrit au lancement, présenté aux conseils d'administration, et jamais véritablement agi tandis que les risques qui comptent mûrissent sans surveillance. Dans une migration ou bascule, les risques décisifs sont souvent spécifiques et connaissables — des résultats historiques qui ne se mapperont pas proprement vers de nouvelles plages de référence, une dépendance envers les changements de pare-feu d'une autre équipe, une hypothèse que la ressource de validation clinique sera libre quand nécessaire — et la question est si le registre les nomme concrètement ou se cache derrière des entrées génériques comme « contraintes de ressources ». Le débat devrait tester si l'escalade par exception est réelle : le chef de projet fonctionne-t-il à l'intérieur de tolérances convenues et attire-t-il l'attention du conseil d'administration seulement quand l'une est menacée, ou est-ce que tout reste soit silencieux soit devient une crise ? Considérez si les quasi-incidents et problèmes matérialisés se réinjectent dans comment la prochaine étape est planifiée, ou sont simplement consignés et oubliés. Une bonne réponse peut pointer vers une décision que le registre RAID a réellement changée, distingue les deux ou trois risques qui pourraient véritablement arrêter le projet de la longue traîne de mineurs, et traite le registre comme un contrôle fonctionnel plutôt qu'un artefact produit pour l'assurance.

6. Après que nous clôturons et dissolvons, quelqu'un vérifie-t-il si les bénéfices dans le dossier commercial se sont réellement matérialisés — et le saurions-nous s'ils ne l'ont pas fait ? Le dossier commercial promet des bénéfices pour justifier la dépense, mais le travail piloté par le projet se termine naturellement à la mise en production et la libération de l'équipe, donc le moment de vérité — la migration a-t-elle réellement réduit le risque, coupé le coût, ou amélioré les soins — tombe habituellement après que tout le monde soit passé à autre chose et que personne ne soit responsable de le confirmer. Cela compte de manière aiguë dans la santé et l'action sociale publiques, où l'argent est engagé contre un dossier commercial à cinq cas dont on a dit au Parlement, aux auditeurs, et aux conseils d'administration qu'il livrerait des résultats spécifiques, pourtant la réalisation des bénéfices est l'étape la plus souvent sautée car le projet qui l'aurait possédée n'existe plus. La discussion devrait décider qui hérite du suivi des bénéfices quand le projet se clôt, sur quelle période, et contre quelles mesures de base — qui doivent être capturées avant la mise en production ou elles sont perdues. Considérez un projet récemment complété et demandez franchement si quelqu'un a depuis vérifié ses bénéfices promis, et si un manque atteindrait jamais le conseil d'administration qui l'a approuvé. Une réponse honnête assigne la propriété des bénéfices post-clôture à une fonction permanente plutôt qu'à l'équipe dissoute, capture la base pendant que le projet est encore en direct, et est disposée à enregistrer qu'un projet a livré son résultat à temps et dans le budget mais n'a pas livré la valeur qui l'a justifié.

En pratique : un exemple de santé et d'action sociale#

Un trust de soins aigus doit remplacer son système de gestion d'information de laboratoire de pathologie vieillissant avant que le fournisseur en place ne retire le support dans 14 mois. C'est du travail piloté par le projet manuel scolaire : date de fin fixe, périmètre défini, falaise contractuelle dure, et risque aigu de sécurité patient si les résultats sont perdus en migration.

Le trust écrit un dossier commercial à cinq cas évaluant trois options (mise à niveau sur place, achat d'un nouveau système, partage d'une instance régionale), sélectionne l'achat, et met en place un projet PRINCE2 avec un comité clair : un exécutif possédant le dossier commercial, un utilisateur senior (le scientifique biomédical principal), et le fournisseur senior. Le travail est divisé en étapes de gestion — achat, construction et configuration, migration de données, tests, et mise en production — chacune se terminant par une porte de décision.

Le chef de projet exploite un registre RAID. Un risque clé est que les résultats historiques pourraient ne pas se mapper proprement vers les plages de référence du nouveau système ; une dépendance est les changements de pare-feu de l'équipe réseau ; une hypothèse est que la ressource de validation clinique sera disponible pour les tests. À la porte d'étape de migration, les tests révèlent que le risque de mappage de données est pire que supposé, donc le conseil d'administration utilise la porte comme conçue : il ne continue pas aveuglément, mais approuve une étape replanifiée avec une fenêtre de validation étendue et un plan de retour en arrière testé, protégeant la sécurité patient plutôt que le calendrier original.

La mise en production se passe sur un week-end contrôlé avec le plan de retour en arrière en attente et une validation de sécurité clinique DCB0160. Le système est accepté, transmis à l'équipe des opérations qui l'exploitera, les leçons sont consignées, et le projet est formellement clôturé. L'équipe se dissout — correctement, car le travail est véritablement terminé. Ce qui vient ensuite (amélioration continue du service en direct) est un mode de travail différent, et le trust est prudent de ne pas garder une équipe de projet complète fonctionnant perpétuellement pour le faire.

Angles sectoriels#

Startup#

Une petite entreprise de santé numérique exploite rarement des projets PRINCE2 formels, mais un véritable travail fini apparaît toujours — une migration de données ponctuelle vers une nouvelle plateforme cloud, une poussée de certification Cyber Essentials ou DTAC, une remédiation de test de pénétration avant un grand contrat NHS. La startup gère ceux-ci comme des efforts légers et limités dans le temps avec un propriétaire nommé et une définition claire de terminé, empruntant la discipline (périmètre fixe, une date de fin, un go/no-go) sans le cérémonial (aucun comité de projet formel, aucun portillonnage à cinq étapes). Le financement est réellement l'attention du fondateur et la piste de décollage, donc le risque est que le travail fini soit pressé entre les sprints de produit et jamais réellement clôturé. Le correctif est de nommer un propriétaire unique et une date limite dure, et de traiter la certification ou la migration comme terminée et réglée plutôt que perpétuellement « en cours ».

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, ou une clinique monosite — rencontre le travail piloté par le projet comme des événements occasionnels mais inévitables : changer de fournisseur de système clinique, migrer vers une nouvelle plateforme de gestion de cabinet, ou remplacer des appareils en fin de vie avant que le support n'expire. L'organisation a de vrais patients et des opérations continues mais aucune fonction de projet ou informatique dédiée, donc « l'équipe de projet » est habituellement le gestionnaire de cabinet ou un gestionnaire agréé faisant cela aux côtés de son travail quotidien, s'appuyant souvent sur le fournisseur entrant pour mener la migration. La discipline qui survit au contact avec cette réalité est le noyau léger : un état final clair, un périmètre établi comme base afin que le fournisseur ne l'étende pas discrètement, une personne responsable nommée, et un retour en arrière testé avant toute bascule qui touche les dossiers patient. Le piège est de sous-traiter non seulement le travail mais le jugement — accepter la date de mise en production du fournisseur et ses assurances de mappage de données sans vérification indépendante — car les mêmes obligations de sécurité clinique et de gouvernance de l'information (DCB0160, une DPIA) s'appliquent quelle que soit la taille de l'organisation. Le correctif est de garder la propriété de la décision go/no-go et des critères d'acceptation en interne, même quand toute autre paire de mains appartient au fournisseur.

Entreprise#

Un grand trust du NHS ou un integrated care system (ICS) est là où le travail piloté par le projet est le plus chez lui : remplacements EPR, Wi-Fi à l'échelle du parc, sorties de centre de données, et bascules portent tous des falaises contractuelles et de sécurité patient dures. Ici, l'appareil complet est justifié — un dossier commercial à cinq cas, un comité PRINCE2 avec un exécutif/SRO nommé, un utilisateur senior et un fournisseur senior, des étapes de gestion avec de véritables portes, et un registre RAID vivant — car les sommes sont grandes, l'exposition de sécurité est aiguë, et l'audit interne et le conseil d'administration scruteront la dépense. L'échec caractéristique à cette échelle est d'appliquer la même gouvernance indistinctement aux services vivants (Sujet 5.0 — Travail piloté par le produit) et au travail fini, donc une vue de portefeuille (Sujet 5.3 — Gestion de portefeuille et projets d'entreprise) qui achemine chaque pièce de travail vers le bon mode compte. La sécurité clinique (DCB0160) et un retour en arrière testé sont des livrables de porte, pas des extras optionnels.

Gouvernement#

À l'échelle nationale ou de projet majeur, le travail piloté par le projet se situe à l'intérieur du régime d'assurance du gouvernement : l'Infrastructure and Projects Authority mène des revues de passage, le Green Book et le modèle des cinq cas du HM Treasury gouvernent le dossier commercial, et les plus grands projets entrent dans le Government Major Projects Portfolio avec une responsabilité publiée envers le Parlement et le National Audit Office. La responsabilité est intensément publique — le propriétaire responsable senior est personnellement responsable et peut être convoqué devant un comité restreint — donc les portes d'étape et les évaluations d'options sont un contrôle de grade statutaire, pas du théâtre. Le financement est libéré tranche par tranche contre des dossiers commerciaux approuvés et l'appétit pour le risque est faible, car l'échec devient une nouvelle en première page. La véritable valeur de la discipline ici est l'autorité d'arrêter ou de recadrer un projet défaillant avant qu'il ne devienne une perte publique.

Modes d'échec courants#

• Gérer un service évolutif comme un projet. Appliquer une gouvernance à périmètre fixe et dissolution à la fin à un produit numérique vivant produit la pathologie d'abandon. Correctif : utiliser le travail piloté par le produit (Sujet 5.0) là où le service est continu.
• Le dossier commercial comme un ticket ponctuel vers le financement. Écrit une fois pour débloquer de l'argent, puis jamais revisité. Correctif : le réviser à chaque porte d'étape ; être disposé à arrêter.
• Portes d'étape tamponnées automatiquement. Des portes qui ne disent jamais « arrêter » ne fournissent aucun contrôle. Correctif : faire d'arrêter ou replanifier une véritable option du conseil d'administration et l'utiliser.
• Glissement de périmètre sans contrôle de changement. Des ajouts non contrôlés font exploser le temps et le coût. Correctif : établir le périmètre comme base et acheminer chaque changement via le contrôle de changement.
• Aucun plan de transition vers le service. Le projet se termine et personne ne possède le livrable. Correctif : convenir de l'équipe réceptrice et du modèle de support avant la mise en production.
• RAID comme classeur. Un registre qui est écrit et jamais agi. Correctif : réviser RAID régulièrement et escalader par exception.
• Ne jamais réellement clôturer. Des projets zombies qui consomment des ressources sans fin. Correctif : une clôture délibérée avec acceptation, transmission, et leçons capturées.

Modèle de maturité#

Liste de contrôle#

• Le travail est-il véritablement fini avec un périmètre défini et un état final (pas un service continu) ?
• Y a-t-il un dossier commercial vivant (modèle des cinq cas) révisé à chaque porte d'étape ?
• Le périmètre est-il établi comme base, avec un processus de contrôle de changement fonctionnel ?
• Les étapes de travail sont-elles définies, chacune se terminant par une véritable porte de décision arrêt/continuer ?
• Les rôles du comité de projet sont-ils clairs — exécutif/SRO, utilisateur senior, fournisseur senior ?
• Un registre RAID vivant est-il maintenu, avec escalade par exception ?
• La sécurité clinique (DCB0160), la DPIA, et les tests de bascule/retour en arrière sont-ils des livrables de porte ?
• L'équipe des opérations réceptrice et le modèle de support sont-ils convenus avant la mise en production ?
• Y a-t-il une clôture délibérée : acceptation, transmission, libération de l'équipe, leçons consignées ?
• L'amélioration continue du service en direct a-t-elle été assignée au bon mode de travail ?

Sources clés#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7th edition) and the PRINCE2 principles, themes, and processes.
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) and The Standard for Project Management.
• HM Treasury — Guide to Developing the Project Business Case (the Five Case Model / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — assurance and gateway review guidance for major projects.
• NHS Digital Clinical Safety standard DCB0160 (deployment of health IT systems).
• NHS England — NHS Service Manual and Digital Service Standard (for service-transition and user-need context).

Références#

1. Project management — Wikipédia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipédia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipédia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipédia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipédia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipédia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipédia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipédia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipédia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipédia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipédia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety