Sujet 5.2 — Travail piloté par le programme

En une phrase : Le travail piloté par le programme coordonne un ensemble de projets et produits liés vers un changement stratégique qu'aucun ne pourrait livrer seul, tenant une ligne de vue claire depuis le travail jusqu'aux bénéfices qu'il est censé réaliser.

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

Les plus grands changements dans la santé et l'action sociale ne sont jamais un seul projet. Déployer un dossier de soins partagé à travers un integrated care system (ICS), déplacer une région vers un seul dossier de santé électronique, transformer un parcours de soins urgents et d'urgence, ou livrer un programme de service virtuel à travers plusieurs trusts — chacun de ceux-ci est un paquet coordonné de projets, équipes produit, changement de main-d'œuvre, travail d'installations, et reconception clinique, aligné vers un résultat stratégique unique. Gérez les pièces isolément et elles entrent en collision : normes de données incompatibles, dépense dupliquée, flux de travail cliniques contradictoires, et bénéfices qui ne se matérialisent jamais réellement.

La gestion de programme existe pour tenir cette coalition ensemble et la garder pointée vers les résultats et bénéfices, pas seulement les livrables. Cela compte de manière aiguë dans la santé et l'action sociale car le changement à l'échelle du système touche la sécurité patient à travers les frontières organisationnelles, engage de grandes sommes d'argent public sur plusieurs années, et dépend de nombreuses organisations autonomes choisissant de se déplacer au même pas. Un programme fournit le leadership, l'état cible partagé, et la discipline de bénéfice pour faire arriver cela — et, tout aussi important, savoir si cela fonctionne.

L'échec récurrent contre lequel il garde est le programme qui dépense des millions, livre un tas de livrables techniques, et pourtant ne change rien de mesurable pour les patients ou le personnel. Ce sujet utilise Managing Successful Programmes (MSP), le cadre dominant du secteur public britannique, et montre comment le travail piloté par le programme coexiste avec les modes pilotés par le projet (Sujet 5.1 — Travail piloté par le projet) et le produit (Sujet 5.0 — Travail piloté par le produit) qu'il coordonne. Le Sujet 5.3 — Gestion de portefeuille et projets d'entreprise (EPPM) explique ensuite comment une organisation priorise à travers de nombreux programmes.

Concepts fondamentaux#

Programme. Une organisation temporaire et flexible créée pour coordonner, diriger, et superviser un groupe de projets et activités liés afin de livrer des résultats et bénéfices alignés sur des objectifs stratégiques. Un programme diffère d'un projet en ce qu'il est défini par le résultat et les bénéfices qu'il recherche, et il gère l'incertitude de coordonner de nombreuses pièces mobiles, plutôt que de livrer un seul livrable fixe.

MSP (Managing Successful Programmes). Le cadre de bonnes pratiques britannique pour gérer le changement transformationnel via de multiples projets liés. Il est organisé autour de principes, thèmes, et un « flux transformationnel » de processus, et est conçu pour un changement grand et complexe où l'état final est connu en direction mais le chemin implique de nombreuses livraisons interdépendantes.

Vision et plan directeur. La vision est l'image convaincante de l'avenir que le programme créera. Le plan directeur (blueprint) la rend concrète : il décrit le modèle opérationnel cible — l'état futur des processus, organisation, technologie, information, et rôles (souvent résumé comme POTI). Le plan directeur est le point de référence vers lequel chaque projet est piloté, afin que les pièces s'additionnent en un tout cohérent.

Réalisation des bénéfices. Le cœur de la gestion de programme. Les bénéfices sont les améliorations mesurables qui justifient l'investissement — sorties retardées réduites, moins de tests dupliqués, diagnostic plus rapide, charge administrative plus faible. MSP traite l'identification, la cartographie, la mesure, et la gestion active des bénéfices à travers tout le cycle de vie comme une discipline centrale, car les livrables ne créent de la valeur que lorsqu'ils sont utilisés pour changer comment les soins sont livrés.

Tranches. MSP divise un programme en tranches — des blocs de travail se terminant à un point de révision majeur où une étape de capacité a été livrée et la réalisation des bénéfices peut commencer. Une tranche est un moment pour démontrer les résultats, réévaluer le plan directeur contre la réalité, et décider de continuer, ajuster, ou arrêter, plutôt que simplement une tranche du calendrier.

Comité de programme et SRO. Le Senior Responsible Owner (SRO) est l'individu unique responsable de ce que le programme atteigne ses objectifs et réalise ses bénéfices, avec assez d'ancienneté et d'autorité pour diriger et prendre des décisions. Le SRO préside un comité de programme — typiquement un business change manager, des responsables de projet, et des parties prenantes seniors — qui fournit la direction à travers les frontières organisationnelles.

Business change manager (BCM). Le rôle distinctif de MSP : quelqu'un du métier opérationnel (pas l'équipe de livraison) responsable d'intégrer le changement et réaliser les bénéfices sur le terrain. Le BCM est pourquoi les programmes livrent des résultats et pas seulement des livrables — les projets transmettent la capacité, le BCM la transforme en bénéfice.

Bonnes pratiques#

1. Ancrez le programme dans une vision et un plan directeur. Définissez le résultat stratégique et traduisez-le en un modèle opérationnel cible concret (processus, organisation, technologie, information — POTI). Chaque projet et produit constituant est alors piloté vers le même état futur, ce qui est ce qui empêche une coalition de livraisons de se fragmenter.

2. Gérez les bénéfices, pas seulement les livrables. Construisez une carte de bénéfices liant chaque livrable aux résultats et bénéfices mesurables qu'il devrait produire, avec des propriétaires et des bases. Révisez les bénéfices activement à travers le programme, et soyez disposé à arrêter le travail qui ne va pas se rembourser — l'accent de MSP sur la réalisation des bénéfices est la discipline qui sépare un programme d'une liste de tâches coûteuse.

3. Structurez le travail en tranches avec de véritables points de révision. Livrez la capacité en tranches, et à chaque frontière de tranche démontrez les bénéfices réalisés jusqu'à présent, retestez le plan directeur contre ce que vous avez appris, et prenez une véritable décision continuer/ajuster/arrêter. Les premières tranches devraient cibler des gains rapides visibles pour construire la confiance des parties prenantes pour les plus difficiles à venir.

4. Nommez un SRO habilité et un véritable comité de programme. Nommez un SRO unique avec l'ancienneté et l'autorité pour diriger le programme et décider à travers les frontières organisationnelles, et convoquez un comité qui représente véritablement les organisations affectées. Les programmes échouent quand la responsabilité est diffuse ou que le SRO ne peut pas réellement faire tenir des décisions transfrontalières.

5. Placez des business change managers dans le métier opérationnel. Assignez des BCM depuis les organisations de première ligne pour posséder l'adoption et la réalisation des bénéfices là où les soins sont livrés. La capacité livrée mais non adoptée ne réalise aucun bénéfice ; le rôle de BCM est le mécanisme qui ferme cet écart.

6. Coordonnez — ne microgérez pas — les projets et produits constituants. Le programme fixe le plan directeur, les interdépendances, les normes, et les bénéfices ; il laisse les projets et équipes produit livrer à l'intérieur de ce cadre. Il gère les coutures — normes de données partagées, gouvernance de l'information, séquençage, et infrastructure partagée — pas le détail interne de chaque livraison.

7. Gérez le risque, la dépendance, et les parties prenantes transversaux sans relâche. La valeur qu'un programme ajoute par rapport aux projets autonomes réside largement dans la gestion de ce qui se passe entre eux. Maintenez une vue au niveau programme des interdépendances et risques partagés, et investissez lourdement dans l'engagement des parties prenantes à travers les organisations autonomes, puisque l'alignement est volontaire, pas commandé.

8. Clôturez le programme quand le changement est intégré, et transmettez les services continus aux équipes produit. Un programme est temporaire. Lorsque le plan directeur est atteint et que les bénéfices sont réalisés, clôturez-le délibérément, transférez tout service durable vers des équipes produit durables (Sujet 5.0), et continuez à suivre les bénéfices dans l'activité courante — de nombreux bénéfices s'accumulent après la fin du programme.

Questions à discuter avec votre équipe#

1. Notre senior responsible owner a-t-il réellement l'autorité de faire tenir des décisions à travers des organisations partenaires souveraines, ou seulement la responsabilité quand elles ne tiennent pas ? Le travail piloté par le programme vit ou meurt sur l'autorité transfrontalière, car le changement couvre des trusts autonomes, les soins primaires, communautaires, de santé mentale, et l'action sociale qui ne peuvent pas simplement être ordonnés de se déplacer au même pas. L'échec caractéristique est un SRO nommé qui porte la responsabilité personnelle et publique pour les bénéfices mais manque de la position pour contraindre un partenaire réticent à adopter une norme de données partagée ou changer un flux de travail clinique — responsabilité sans autorité. Le débat devrait être franc sur où se trouve le véritable pouvoir dans le système : si le comité de programme représente véritablement les organisations affectées ou est un forum de rapport, si le SRO est assez senior pour que ses décisions soient honorées à travers les frontières souveraines, et ce qui se passe quand un partenaire refuse de bouger. Considérez une décision transorganisationnelle récente et tracez si elle a réellement tenu. Une bonne réponse nomme qui est le SRO et teste son autorité contre un véritable conflit transfrontalier, est honnête sur les organisations qui peuvent effectivement se retirer, et traite un comité représentatif et des business change managers intégrés comme des mécanismes porteurs de charge pour l'alignement volontaire plutôt que de la décoration de gouvernance.

2. Comment saurons-nous que ce programme a réalisé des bénéfices et n'a pas simplement livré des livrables — et qui, dans le métier opérationnel, est responsable de transformer la capacité en bénéfice ? Le théâtre de livrables est la pathologie récurrente contre laquelle le sujet met en garde : un programme dépense des millions, produit un tas de plateformes et intégrations d'interopérabilité, et pourtant rien de mesurable ne change pour les patients ou le personnel. La distinction qui l'empêche est le business change manager — quelqu'un de l'opération de première ligne, pas l'équipe de livraison, responsable d'intégrer le changement et réaliser le bénéfice là où les soins sont livrés — donc la question force l'équipe à nommer ces personnes et confirmer qu'elles existent. La tension est que la livraison est visible et satisfaisante tandis que l'adoption est lente, peu glamour, et facile à supposer qu'elle se produira simplement ; un dossier de soins partagé enterré derrière une connexion supplémentaire ne réalise aucun bénéfice aussi bien qu'il soit construit. Apportez la carte de bénéfices à la discussion et testez si chaque livrable est lié à un bénéfice possédé, avec une base, et mesurable (moins de tests dupliqués, sorties retardées réduites) ou si les bénéfices sont simplement affirmés. Une réponse honnête nomme un BCM dans chaque organisation partenaire, admet où les bénéfices sont actuellement non possédés ou non mesurés, et accepte que certains bénéfices s'accumulent seulement après que le programme se clôt et doivent être suivis dans l'activité courante.

3. Découpons-nous ce programme en tranches pour encaisser les bénéfices précoces et créer de véritables points continuer/ajuster/arrêter, ou dérivons-nous vers une livraison big-bang qui reporte tout le risque à un moment tardif unique ? Les tranches sont ce qui sépare un programme d'un plan gelé coûteux : chaque frontière de tranche devrait livrer une étape de capacité, démontrer les bénéfices réalisés jusqu'à présent, retester le plan directeur contre ce qui a réellement été appris, et soutenir une véritable décision de continuer, ajuster, ou arrêter. La tentation dans la santé et l'action sociale est de séquencer pour la commodité d'ingénierie et reporter la valeur visible — connectant chaque trust avant que quiconque ne puisse utiliser quoi que ce soit — ce qui charge tout le risque dans une seule livraison tardive et laisse le conseil d'administration sans preuve pour défendre l'investissement continu à travers les cycles fiscaux et politiques. Le débat devrait examiner si les premières tranches ciblent des gains rapides délibérés qui construisent la confiance des parties prenantes pour le travail plus difficile à venir, et si les points de révision sont de véritables décisions ou des points de contrôle de calendrier. Considérez quel est le premier bénéfice démontrable, à quelle vitesse il atterrit, et ce que le conseil d'administration ferait réellement à une révision de tranche si l'adoption traînait ou le plan directeur s'avérait erroné. Une bonne réponse décrit des tranches concrètes avec des gains précoces et mesurables, traite chaque frontière comme un véritable go/no-go avec le plan directeur véritablement ouvert à révision, et est honnête sur toute pression de reporter la valeur à la fin.

4. Avons-nous un plan directeur unique et maintenu du modèle opérationnel cible, ou chaque projet optimise-t-il discrètement vers sa propre version de l'avenir ? Le plan directeur — le modèle opérationnel cible POTI concret de processus, organisation, technologie, et information — est ce qui fait que les pièces s'additionnent en un tout cohérent plutôt qu'une collision de décisions localement sensées. Sans cela, chaque projet constituant optimise rationnellement pour son propre périmètre : un trust choisit une norme de données qui convient à son EPR en place, un autre conçoit un flux de travail clinique autour de sa propre dotation en personnel, et le dossier de soins partagé se fragmente en intégrations qui se connectent techniquement mais ne cohèrent pas. La tension est que maintenir un plan directeur semble une charge pour des équipes de livraison sous pression de livrer, et il doit être une référence vivante retestée à chaque tranche plutôt qu'un document écrit une fois et mis de côté. Le débat devrait établir si le plan directeur existe réellement sous une forme utilisable, qui le possède, et si de véritables décisions de projet sont pilotées par lui ou simplement réconciliées avec lui après coup. Considérez un choix de conception récent dans un projet et demandez si le plan directeur l'a façonné ou a été discrètement outrepassé. Une réponse honnête peut pointer vers un plan directeur actuel, nomme son propriétaire, et est franche sur où l'optimisation locale démembre déjà l'état cible.

5. Lorsque le programme se clôt, qu'est-ce qui perdure — et avons-nous nommé les équipes produit durables qui exploiteront la capacité et continueront à suivre les bénéfices dans l'activité courante ? Un programme est temporaire par définition, mais le dossier de soins partagé, la plateforme d'interopérabilité, et les bénéfices qu'ils produisent ne le sont pas, donc la clôture est un problème de conception à planifier dès le début plutôt qu'une réflexion après coup. L'échec récurrent à chaque extrémité du spectre est réel : certains programmes ne se clôturent jamais et se durcissent en bureaucraties permanentes longtemps après que le changement soit intégré, tandis que d'autres se clôturent abruptement et échouent un service clinique en direct sans propriétaire durable. Le sujet est explicite que les services durables devraient être transférés vers des équipes produit durables (Sujet 5.0) et que de nombreux bénéfices s'accumulent seulement après la fin du programme et doivent être suivis dans l'activité courante — ce qui signifie que les équipes réceptrices et la propriété continue des bénéfices doivent être identifiées pendant que le programme a encore l'autorité et le financement pour les établir. Le débat devrait faire surgir qui exploitera chaque capacité durable, comment elle sera financée une fois l'argent de transformation arrêté, et qui continue de mesurer les bénéfices quand le comité de programme s'est dissous. Une bonne réponse nomme les équipes produit et propriétaires d'activité courante spécifiques, décrit honnêtement la transition de financement, et traite la clôture et le suivi des bénéfices comme des tranches planifiées plutôt qu'une transmission pleine d'espoir.

6. Comment gérons-nous les coutures entre les projets — normes partagées, gouvernance de l'information, séquençage, et infrastructure partagée — plutôt que les internes de chaque livraison ? La valeur qu'un programme ajoute par rapport à un ensemble de projets autonomes réside presque entièrement dans l'espace entre eux : les interdépendances, les normes de données partagées, le cadre de gouvernance de l'information et de consentement, et l'infrastructure commune qu'aucun projet unique ne possède mais dont tous dépendent. La tentation pour une équipe de programme est de dériver vers la microgestion des internes de chaque livraison — travail confortable, visible — tandis que les coutures transversales véritablement difficiles ne sont pas gérées jusqu'à ce qu'elles émergent comme un échec d'intégration ou un blocage de gouvernance de l'information à la mise en production. Dans la santé et l'action sociale, ces coutures sont anormalement porteuses de charge, car les flux de données et le consentement traversent des frontières organisationnelles et réglementaires souveraines où l'alignement est volontaire et les obligations légales sont partagées mais dotées en ressources de manière inégale. Le débat devrait tester s'il y a une vue au niveau programme des interdépendances et risques partagés, qui possède les normes et infrastructure partagées, et si le programme coordonne les coutures ou s'immisce dans le détail de projet. Une réponse honnête identifie les coutures spécifiques qui menacent le plus le résultat, nomme leurs propriétaires, et est franche sur si le programme ajoute de la valeur aux frontières ou duplique le travail des projets qu'il devrait habiliter.

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

Un ICS entreprend de livrer un dossier de soins partagé donnant aux cliniciens à travers les soins aigus, communautaires, de santé mentale, les soins primaires, et l'action sociale une vue unifiée d'une personne. Aucun projet unique ne peut livrer cela : il couvre plusieurs trusts, plusieurs systèmes sources, des accords de gouvernance de l'information, une reconception de flux de travail clinique, et un engagement public. Il est coordonné comme un programme MSP.

Le SRO — un exécutif d'ICS avec une véritable autorité transsystème — préside un comité de programme avec des représentants de chaque organisation partenaire et des business change managers nommés dans chacune. Le programme fixe une vision (« la bonne information, sur la bonne personne, disponible pour le bon clinicien, au point de soin ») et un plan directeur décrivant le modèle opérationnel cible : l'architecture et les normes de partage de données (interopérabilité basée HL7 FHIR), le cadre de gouvernance de l'information, le modèle de consentement, et les flux de travail cliniques reconçus.

Le travail est organisé en tranches. La tranche un connecte deux trusts de soins aigus volontaires et livre un dossier en lecture seule, un gain rapide délibéré qui prouve l'approche et laisse le comité démontrer un bénéfice précoce — une réduction mesurable des tests dupliqués — pour construire la confiance. À la révision de tranche un, le comité apprend que l'adoption clinicienne traîne là où le dossier est enterré dans une connexion supplémentaire, donc il ajuste le plan directeur pour prioriser l'intégration d'authentification unique avant d'élargir le déploiement.

Sous le programme, les modes coexistent. La plateforme d'interopérabilité est exploitée par une équipe produit durable (Sujet 5.0) qui continue à l'améliorer à travers tout le programme et au-delà. La connexion de chaque trust est un projet borné (Sujet 5.1) avec son propre dossier commercial et sa mise en production. Le programme lui-même coordonne le plan directeur, les normes, les interdépendances, et — via les BCM — la réalisation des bénéfices. Lorsque le plan directeur est atteint et que les bénéfices de tests dupliqués et de sorties retardées circulent, le programme se clôt ; l'équipe produit de plateforme perdure, et le suivi des bénéfices continue dans l'activité courante.

Angles sectoriels#

Startup#

Peu de startups exploitent des programmes au sens MSP — elles manquent la portée multi-organisationnelle qui en définit un — mais une entreprise en croissance déployant à travers plusieurs trusts devient effectivement un participant de programme. Son rôle réaliste est celui d'un fournisseur à l'intérieur du programme de quelqu'un d'autre : aligner son produit sur le plan directeur du programme, atteindre les jalons de tranche, et alimenter le dossier de bénéfices que le SRO doit prouver. Le financement et la survie dépendent de la continuation du programme, donc la startup traite les révisions de tranche comme des points go/no-go existentiels et investit dans le succès des business change managers, car l'adoption sur le terrain est ce qui renouvelle son contrat. La discipline qu'elle doit emprunter est le langage de bénéfices — cadrer sa valeur comme des résultats réalisés, pas des fonctionnalités livrées.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, ou un petit fournisseur de health-tech ayant dépassé le stade de la startup — n'exploite presque jamais un programme, mais est routinièrement balayé dans un en tant que participant affecté lorsqu'un ICS déploie un dossier de soins partagé ou converge des systèmes à travers le territoire. Sa préoccupation pratique est la couture que le programme possède : il doit adopter les normes de données mandatées, les accords de gouvernance de l'information, et le modèle de consentement avec une capacité informatique mince ou inexistante et aucune marge pour absorber le changement de flux de travail, pourtant il porte les mêmes obligations légales que les grands trusts autour de lui. La relation la plus précieuse qu'il ait est avec le business change manager de sa localité, car une adoption bien soutenue — formation, authentification unique, un flux de travail qui correspond à comment le cabinet fonctionne réellement — est la différence entre le bénéfice du programme atterrissant et le changement étant discrètement contourné. Sa demande réaliste au programme est un soutien proportionné et un séquençage qui ne suppose pas des ressources à l'échelle d'entreprise, et sa contribution honnête est un retour précoce et franc aux révisions de tranche sur ce qui n'est pas viable sur le terrain.

Entreprise#

Un ICS ou grand trust est le foyer naturel du travail piloté par le programme : dossiers de soins partagés, convergence EPR, et transformation de parcours sont intrinsèquement multi-organisationnels et pluriannuels. La partie difficile est l'autorité — le SRO doit faire tenir des décisions à travers des organisations partenaires souveraines qui ne peuvent pas simplement être ordonnées, donc un comité de programme véritablement représentatif et des business change managers intégrés dans chaque partenaire sont porteurs de charge, pas décoratifs. Le financement est mélangé (argent de transformation système, capital de trust, allocations nationales), ce qui rend la carte de bénéfices et les révisions de tranche essentielles pour défendre l'investissement continu auprès des dirigeants système et des régulateurs. Le risque récurrent à cette échelle est le théâtre de livrables : livraison technique sans que personne ne soit responsable de la transformer en bénéfice.

Gouvernement#

À l'échelle nationale, les programmes portent la gouvernance la plus lourde — ils entrent typiquement dans le Government Major Projects Portfolio, subissent l'assurance et les revues de passage de l'Infrastructure and Projects Authority, et répondent aux ministres, au Public Accounts Committee, et au National Audit Office. Le SRO est personnellement et publiquement responsable de la réalisation des bénéfices à travers tout le système, et les plans directeurs doivent réconcilier les normes nationales (interopérabilité, gouvernance de l'information, l'application NHS comme porte d'entrée commune) avec l'autonomie locale. Le financement circule via des règlements de revue de dépenses pluriannuels, donc le découpage en tranches et la preuve de bénéfices sont le mécanisme pour soutenir ou arrêter l'investissement à travers les cycles fiscaux et politiques. Les enjeux sont à l'échelle de la population : les bénéfices d'un programme national — ou son échec — se mesurent en millions de patients et milliards de livres sterling.

Modes d'échec courants#

• Théâtre de livrables. Le programme livre des livrables techniques mais personne ne possède leur transformation en bénéfices, donc rien ne change pour les patients. Correctif : cartes de bénéfices avec propriétaires, et BCM dans le métier opérationnel.
• Un programme qui n'est qu'un grand projet. Gouvernance à périmètre fixe et axée sur les livrables appliquée à un changement véritablement incertain et multi-organisationnel. Correctif : gérer par résultats/bénéfices et tranches, pas un seul plan gelé.
• Un SRO impuissant. Responsabilité sans autorité de décider à travers les frontières. Correctif : nommer un SRO assez senior pour faire tenir les décisions transsystème, soutenu par un comité représentatif.
• Aucun plan directeur / état cible. Les projets optimisent localement et les pièces ne cohèrent jamais. Correctif : définir et maintenir un plan directeur POTI vers lequel tout est piloté.
• Big-bang au lieu de tranches. Tout le risque reporté à une livraison tardive. Correctif : découper le travail en tranches, encaisser les bénéfices précoces, et replanifier aux points de révision.
• Programme qui ne se clôt jamais. Il devient une bureaucratie permanente longtemps après que le changement soit intégré. Correctif : clôturer délibérément, transmettre les services durables aux équipes produit, continuer à suivre les bénéfices dans l'activité courante.

Modèle de maturité#

Liste de contrôle#

• Est-ce véritablement un changement multi-projet et multi-organisationnel vers un résultat stratégique unique ?
• Y a-t-il une vision claire et un plan directeur concret (modèle opérationnel cible / POTI) ?
• Y a-t-il une carte de bénéfices liant les livrables à des bénéfices mesurables, possédés, et avec une base ?
• Le travail est-il structuré en tranches avec de véritables points de révision continuer/ajuster/arrêter ?
• Y a-t-il un SRO habilité avec l'autorité de décider à travers les frontières organisationnelles ?
• Le comité de programme représente-t-il véritablement les organisations affectées ?
• Les business change managers sont-ils intégrés dans le métier opérationnel pour posséder l'adoption ?
• Les normes transversales, interdépendances, et risques partagés sont-ils gérés au niveau programme ?
• Les modes pilotés par le produit, le projet, et le programme coexistent-ils avec des rôles clairs (Sujets 5.0–10) ?
• Y a-t-il une clôture délibérée, avec les services durables transmis aux équipes produit durables et les bénéfices suivis dans l'activité courante ?

Sources clés#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): principles, themes, and the transformational flow (including blueprint, tranches, benefits management, and the SRO/BCM roles).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — guidance on major programmes, SRO accountability, and assurance/gateway reviews.
• HM Treasury — The Green Book and benefits-management guidance (appraisal and evaluation of benefits).
• AXELOS — Management of Portfolios (MoP), for positioning programmes within a portfolio (see Sujet 5.3 — EPPM).
• NHS England — guidance on integrated care systems and shared care records (interoperability, HL7 FHIR standards) for the domain context.
• Mik Kersten — Project to Product, for the shift from output-based to outcome/benefit-based investment.

Références#

1. Program management — Wikipédia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipédia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipédia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipédia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipédia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipédia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipédia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipédia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipédia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipédia — https://en.wikipedia.org/wiki/Stakeholder_management
11. Managing Successful Programmes (MSP): principles, themes, and the transformational flow — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/MSP-1006
12. Guidance on major programmes, SRO accountability, and assurance/gateway reviews — Cabinet Office / Infrastructure and Projects Authority — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
13. The Green Book and benefits-management guidance — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
14. Management of Portfolios (MoP) — AXELOS / PeopleCert — https://www.peoplecert.org/
15. Integrated care systems and shared care records (interoperability, HL7 FHIR standards) — NHS England — https://www.england.nhs.uk/integratedcare/
16. Project to Product — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/