Ämne 5.2 — Programledt arbete

I en mening: Programledt arbete samordnar en uppsättning relaterade projekt och produkter mot en strategisk förändring som ingen av dem kunde leverera ensam, och håller en tydlig siktlinje från arbetet till de nyttor det är avsett att realisera.

Varför detta är viktigt inom hälsa och vård#

De största förändringarna inom hälsa och vård är aldrig ett enda projekt. Att rulla ut en delad vårdjournal över ett integrerat vårdsystem (ICS), flytta en region till en enda elektronisk patientjournal, omvandla ett förlopp för akut och brådskande vård eller leverera ett program för virtuella vårdavdelningar över flera sjukhus — var och en av dessa är en samordnad bunt av projekt, produktteam, personalförändring, fastighetsarbete och klinisk omgestaltning, samordnad mot ett strategiskt utfall. Förvaltar ni delarna isolerat kolliderar de: oförenliga datastandarder, dubblerade utgifter, motstridiga kliniska arbetsflöden och nyttor som aldrig faktiskt materialiseras.

Programledning finns för att hålla ihop den koalitionen och hålla den riktad mot utfall och nyttor, inte bara leveranser. Detta spelar akut roll inom hälsa och vård eftersom systemomfattande förändring berör patientsäkerhet över organisationsgränser, binder stora summor offentliga medel över flera år och beror på att många autonoma organisationer väljer att röra sig i takt. Ett program ger det ledarskap, det delade målläge och den nyttodisciplin som krävs för att få det att ske — och, lika viktigt, för att veta om det fungerar.

Det återkommande misslyckande det skyddar mot är programmet som spenderar miljoner, levererar en hög tekniska leveranser och ändå inte förändrar något mätbart för patienter eller personal. Detta ämne använder Managing Successful Programmes (MSP), den brittiska offentliga sektorns dominerande ramverk, och visar hur programledt arbete samexisterar med de projektledda (Ämne 5.1 — Projektledt arbete) och produktledda (Ämne 5.0 — Produktledt arbete) arbetssätt det samordnar. Ämne 5.3 — Företagsövergripande projektportföljhantering (EPPM) förklarar sedan hur en organisation prioriterar över många program.

Grundläggande begrepp#

Program. En tillfällig, flexibel organisation skapad för att samordna, leda och övervaka en grupp relaterade projekt och aktiviteter för att leverera utfall och nyttor i linje med strategiska mål. Ett program skiljer sig från ett projekt genom att det definieras av det utfall och de nyttor det söker, och det hanterar osäkerheten i att samordna många rörliga delar, snarare än att leverera en enda fast leverans.

MSP (Managing Successful Programmes). Det brittiska ramverket för god praxis för att förvalta omvälvande förändring genom flera relaterade projekt. Det är organiserat kring principer, teman och ett ”omvandlingsflöde” av processer, och är utformat för stor, komplex förändring där slutläget är känt i riktning men vägen innebär många ömsesidigt beroende leveranser.

Vision och ritning (blueprint). Visionen är den lockande bilden av den framtid programmet kommer att skapa. Ritningen gör den konkret: den beskriver den målbild för verksamhetsmodellen (target operating model) — det framtida tillståndet för processer, organisation, teknik, information och roller (ofta sammanfattat som POTI). Ritningen är den referenspunkt varje projekt styrs mot, så att delarna summerar till en sammanhängande helhet.

Nyttorealisering (benefits realization). Programledningens hjärta. Nyttor är de mätbara förbättringar som motiverar investeringen — färre försenade utskrivningar, färre dubbletter av prover, snabbare diagnos, lägre administrativ börda. MSP behandlar att identifiera, kartlägga, mäta och aktivt förvalta nyttor över hela livscykeln som en kärndisciplin, eftersom leveranser bara skapar värde när de används för att förändra hur vård levereras.

Transcher (tranches). MSP bryter ett program i transcher — block av arbete som slutar vid en större granskningspunkt där ett steg av förmåga har levererats och nyttorealisering kan börja. En tranche är ett tillfälle att påvisa utfall, pröva ritningen mot verkligheten och avgöra om man ska fortsätta, justera eller stoppa, snarare än bara en skiva av tidsplanen.

Programstyrelse och SRO. Senior Responsible Owner (SRO) är den enskilda individ som är ansvarig för att programmet når sina mål och realiserar sina nyttor, med tillräcklig senioritet och befogenhet att leda och fatta beslut. SRO leder en programstyrelse — typiskt en förändringsansvarig i verksamheten, projektledare och seniora intressenter — som ger riktning över organisationsgränser.

Förändringsansvarig i verksamheten (business change manager, BCM). MSP:s särskilda roll: någon från den operativa verksamheten (inte leveransteamet) som är ansvarig för att förankra förändringen och realisera nyttorna på plats. BCM är skälet till att program levererar utfall och inte bara leveranser — projekt lämnar över förmåga, BCM förvandlar den till nytta.

Bästa praxis#

1. Förankra programmet i en vision och en ritning. Definiera det strategiska utfallet och översätt det till en konkret målbild för verksamhetsmodellen (processer, organisation, teknik, information — POTI). Varje ingående projekt och produkt styrs då mot samma framtida tillstånd, vilket är det som hindrar en koalition av leveranser från att fragmenteras.

2. Förvalta nyttor, inte bara leveranser. Bygg en nyttokarta som kopplar varje leverans till de utfall och mätbara nyttor den bör ge, med ägare och baslinjer. Granska nyttor aktivt över programmet, och var villiga att stoppa arbete som inte kommer att löna sig — MSP:s betoning på nyttorealisering är den disciplin som skiljer ett program från en dyr att göra-lista.

3. Strukturera arbetet i transcher med verkliga granskningspunkter. Leverera förmåga i transcher, och vid varje tranchegräns, påvisa de nyttor som hittills realiserats, pröva ritningen mot det ni lärt er och fatta ett genuint fortsätt/justera/stoppa-beslut. Tidiga transcher bör rikta in sig på synliga snabba vinster för att bygga intressenters förtroende för de svårare senare.

4. Utse en bemyndigad SRO och en verklig programstyrelse. Namnge en enda SRO med den senioritet och befogenhet som krävs för att leda programmet och avgöra över organisationsgränser, och sammankalla en styrelse som genuint företräder de berörda organisationerna. Program misslyckas när ansvaret är diffust eller SRO inte faktiskt kan få tvärgående beslut att hålla.

5. Placera förändringsansvariga i den operativa verksamheten. Tilldela BCM från frontlinjeorganisationerna att äga införande och nyttorealisering där vården levereras. Förmåga som levererats men inte införts realiserar ingen nytta; BCM-rollen är mekanismen som sluter det glappet.

6. Samordna — mikrostyr inte — de ingående projekten och produkterna. Programmet sätter ritningen, beroendena, standarderna och nyttorna; det låter projekt och produktteam leverera inom den ramen. Det förvaltar skarvarna — delade datastandarder, informationsstyrning, sekvensering och delad infrastruktur — inte de inre detaljerna i varje leverans.

7. Förvalta tvärgående risk, beroenden och intressenter obevekligt. Det värde ett program tillför jämfört med fristående projekt ligger till stor del i att hantera vad som händer mellan dem. Upprätthåll en vy på programnivå av beroenden och delade risker, och investera kraftigt i intressentengagemang över autonoma organisationer, eftersom samordning är frivillig, inte befalld.

8. Avsluta programmet när förändringen är förankrad, och lämna över pågående tjänster till produktteam. Ett program är tillfälligt. När ritningen är uppnådd och nyttor realiseras, avsluta det medvetet, överför varaktiga tjänster till varaktiga produktteam (Ämne 5.0) och fortsätt följa nyttor in i den ordinarie verksamheten — många nyttor uppstår efter att programmet tagit slut.

Frågor att diskutera med ditt team#

1. Har vår seniora ansvarige faktiskt befogenhet att få beslut att hålla över suveräna partnerorganisationer, eller bara ansvaret när de inte gör det? Programledt arbete lever eller dör på tvärgående befogenhet, eftersom förändringen spänner över autonoma sjukhus, primärvård, närsjukvård, psykiatri och socialtjänst som inte bara kan beordras röra sig i takt. Det karakteristiska misslyckandet är en namngiven SRO som bär det personliga, offentliga ansvaret för nyttor men saknar ställningen att tvinga en motvillig partner att anta en delad datastandard eller ändra ett kliniskt arbetsflöde — ansvar utan befogenhet. Debatten bör vara öppen om var verklig makt finns i systemet: om programstyrelsen genuint företräder de berörda organisationerna eller är ett rapporteringsforum, om SRO är tillräckligt senior för att dennes beslut hedras över suveräna gränser och vad som händer när en partner vägrar röra sig. Beakta ett färskt beslut över organisationer och följ om det faktiskt höll. Ett bra svar namnger vem SRO är och prövar dennes befogenhet mot en konkret tvärgående konflikt, är ärligt om de organisationer som effektivt kan välja bort och behandlar en representativ styrelse och inbäddade förändringsansvariga som bärande mekanismer för frivillig samordning snarare än styrningsdekoration.

2. Hur ska vi veta att detta program har realiserat nyttor och inte bara levererat leveranser — och vem i den operativa verksamheten är ansvarig för att förvandla förmåga till nytta? Leveransteater är den återkommande patologi ämnet varnar för: ett program spenderar miljoner, producerar en hög interoperabilitetsplattformar och integrationer och ändå förändras ingenting mätbart för patienter eller personal. Den skillnad som förhindrar det är förändringsansvarig i verksamheten — någon från den operativa frontlinjen, inte leveransteamet, ansvarig för att förankra förändringen och realisera nyttan där vård levereras — så frågan tvingar teamet att namnge dessa personer och bekräfta att de finns. Spänningen är att leverans är synlig och tillfredsställande medan införande är långsamt, oglamoröst och lätt att anta kommer att ske av sig självt; en delad vårdjournal begravd bakom en extra inloggning realiserar ingen nytta hur väl den än byggts. Ta med nyttokartan till diskussionen och stresstesta om varje leverans är kopplad till en ägd, med baslinje, mätbar nytta (färre dubbletter av prover, minskade försenade utskrivningar) eller om nyttor bara påstås. Ett ärligt svar namnger en BCM i varje partnerorganisation, erkänner var nyttor i dag är oägda eller omätta och accepterar att vissa nyttor uppstår först efter att programmet avslutats och måste följas in i den ordinarie verksamheten.

3. Delar vi detta program i transcher för att ta hem tidiga nyttor och skapa verkliga fortsätt/justera/stoppa-punkter, eller driver vi mot en big bang-leverans som skjuter all risk till ett enda sent ögonblick? Transcher är det som skiljer ett program från en dyr fryst plan: varje tranchegräns bör leverera ett steg av förmåga, påvisa de nyttor som hittills realiserats, pröva ritningen mot det som faktiskt lärts och stödja ett genuint beslut att fortsätta, justera eller stoppa. Frestelsen inom hälsa och vård är att sekvensera för teknisk bekvämlighet och skjuta upp synligt värde — att ansluta varje sjukhus innan någon kan använda något — vilket lastar all risk på en enda sen leverans och lämnar styrelsen utan evidens för att försvara fortsatt investering genom budget- och politiska cykler. Debatten bör granska om tidiga transcher medvetet riktar in sig på snabba vinster som bygger intressenters förtroende för det svårare senare arbetet, och om granskningspunkterna är verkliga beslut eller tidsplanskontrollpunkter. Beakta vad den första påvisbara nyttan är, hur snart den landar och vad styrelsen faktiskt skulle göra vid en tranchegranskning om införandet släpade eller ritningen visade sig fel. Ett bra svar beskriver konkreta transcher med tidiga, mätbara vinster, behandlar varje gräns som ett verkligt go/no-go med ritningen genuint öppen för revision och är ärligt om varje tryck att skjuta värde till slutet.

4. Har vi en enda, underhållen ritning av målbilden för verksamhetsmodellen, eller optimerar varje projekt i tysthet mot sin egen version av framtiden? Ritningen — den konkreta POTI-målbilden av processer, organisation, teknik och information — är det som får delarna att summera till en sammanhängande helhet snarare än en kollision av lokalt förnuftiga beslut. Utan en optimerar varje ingående projekt rationellt för sitt eget omfång: ett sjukhus väljer en datastandard som passar dess befintliga EPR, ett annat utformar ett kliniskt arbetsflöde kring sin egen bemanning och den delade vårdjournalen fragmenteras i integrationer som tekniskt ansluter men inte hänger ihop. Spänningen är att underhålla en ritning känns som overhead för leveransteam under press att leverera, och den måste vara en levande referens som prövas om vid varje tranche snarare än ett dokument skrivet en gång och lagt på hyllan. Debatten bör fastställa om ritningen faktiskt finns i användbar form, vem som äger den och om verkliga projektbeslut styrs av den eller bara avstäms mot den i efterhand. Beakta ett färskt designval i ett projekt och fråga om ritningen formade det eller i tysthet åsidosattes. Ett ärligt svar kan peka på en aktuell ritning, namnger dess ägare och är uppriktigt om var lokal optimering redan drar isär målbilden.

5. När programmet avslutas, vad består — och har vi namngett de varaktiga produktteam som ska driva förmågan och fortsätta följa nyttor in i den ordinarie verksamheten? Ett program är tillfälligt per definition, men den delade vårdjournalen, interoperabilitetsplattformen och de nyttor de ger är det inte, så avslut är ett designproblem att planera från början snarare än en eftertanke. Det återkommande misslyckandet i båda ändar av spektrumet är verkligt: vissa program avslutas aldrig och hårdnar till permanenta byråkratier långt efter att förändringen förankrats, medan andra avslutas abrupt och lämnar en levande klinisk tjänst utan varaktig ägare. Ämnet är uttryckligt med att varaktiga tjänster ska överföras till varaktiga produktteam (Ämne 5.0) och att många nyttor uppstår först efter att programmet tagit slut och måste följas in i ordinarie verksamhet — vilket innebär att de mottagande teamen och det fortlöpande nyttoägarskapet måste identifieras medan programmet ännu har befogenhet och finansiering att etablera dem. Debatten bör lyfta vem som ska driva varje varaktig förmåga, hur den ska finansieras när omvandlingspengarna upphör och vem som fortsätter mäta nyttor när programstyrelsen upplösts. Ett bra svar namnger de specifika produktteamen och ägarna i ordinarie verksamhet, beskriver finansieringsövergången ärligt och behandlar avslut och nyttouppföljning som planerade transcher snarare än en hoppfull överlämning.

6. Hur förvaltar vi skarvarna mellan projekten — delade standarder, informationsstyrning, sekvensering och delad infrastruktur — snarare än det inre i varje leverans? Det värde ett program tillför jämfört med en uppsättning fristående projekt ligger nästan helt i utrymmet mellan dem: beroendena, de delade datastandarderna, ramverket för informationsstyrning och samtycke och den gemensamma infrastruktur ingett enskilt projekt äger men alla är beroende av. Frestelsen för ett programteam är att glida in i att mikrostyra det inre i varje leverans — bekvämt, synligt arbete — medan de genuint svåra tvärgående skarvarna förblir oförvaltade tills de dyker upp som ett integrationsfel eller ett hinder för informationsstyrning vid driftsättning. Inom hälsa och vård är dessa skarvar ovanligt bärande, eftersom data och samtycke korsar suveräna organisatoriska och regulatoriska gränser där samordning är frivillig och lagstadgade plikter är delade men ojämnt resursatta. Debatten bör pröva om det finns en vy på programnivå av beroenden och delade risker, vem som äger de delade standarderna och infrastrukturen och om programmet samordnar skarvar eller lägger sig i projektdetaljer. Ett ärligt svar identifierar de specifika skarvar som mest hotar utfallet, namnger deras ägare och är uppriktigt om huruvida programmet tillför värde vid gränserna eller dubblerar arbetet i de projekt det borde möjliggöra.

I praktiken: ett exempel från hälsa och vård#

Ett ICS sätter sig för att leverera en delad vårdjournal som ger kliniker över akutsjukvård, närsjukvård, psykiatri, primärvård och socialtjänst en enhetlig bild av en person. Inget enskilt projekt kan leverera detta: det spänner över flera sjukhus, flera källsystem, avtal om informationsstyrning, omgestaltning av kliniska arbetsflöden och allmänhetens medverkan. Det samordnas som ett MSP-program.

SRO — en ICS-chef med genuin tvärsystembefogenhet — leder en programstyrelse med företrädare från varje partnerorganisation och namngivna förändringsansvariga i var och en. Programmet sätter en vision (”rätt information, om rätt person, tillgänglig för rätt kliniker, vid vårdtillfället”) och en ritning som beskriver målbilden för verksamhetsmodellen: arkitekturen för datadelning och standarderna (HL7 FHIR-baserad interoperabilitet), ramverket för informationsstyrning, samtyckesmodellen och de omgestaltade kliniska arbetsflödena.

Arbetet organiseras i transcher. Tranche ett ansluter två villiga akutsjukhus och levererar en skrivskyddad journal, en medveten snabb vinst som bevisar ansatsen och låter styrelsen påvisa en tidig nytta — en mätbar minskning av dubbla prover — för att bygga förtroende. Vid tranche ett-granskningen får styrelsen veta att klinikers införande släpar där journalen är begravd bakom en extra inloggning, så den justerar ritningen för att prioritera integration med enhetlig inloggning innan utrullningen vidgas.

Under programmet samexisterar arbetssätten. Interoperabilitetsplattformen drivs av ett varaktigt produktteam (Ämne 5.0) som fortsätter förbättra den under hela programmet och längre. Varje sjukhus anslutning är ett avgränsat projekt (Ämne 5.1) med eget affärscase och driftsättning. Programmet självt samordnar ritningen, standarderna, beroendena och — genom BCM — nyttorealiseringen. När ritningen är uppnådd och nyttorna kring dubbla prover och försenade utskrivningar flödar avslutas programmet; plattformens produktteam består, och nyttouppföljningen fortsätter in i den ordinarie verksamheten.

Sektorperspektiv#

Startup-företag#

Få startup-företag driver program i MSP:s mening — de saknar det flerorganisationsomfång som definierar ett — men ett växande företag som driftsätter över flera sjukhus blir i praktiken en programdeltagare. Dess realistiska roll är som leverantör inom någon annans program: att anpassa sin produkt till programmets ritning, nå tranchemilstolpar och mata det nyttocase SRO måste styrka. Finansiering och överlevnad beror på att programmet fortsätter, så startup-företaget behandlar tranchegranskningar som existentiella go/no-go-punkter och investerar i de förändringsansvarigas framgång, eftersom införande på plats är det som förnyar dess kontrakt. Den disciplin det måste låna är nyttospråket — att rama in sitt värde som realiserade utfall, inte levererade funktioner.

Småföretag#

En etablerad liten vårdgivare — en läkarpraktik, ett närapotek, ett vårdhem eller en liten hälsotekniksleverantör förbi startfasen — driver nästan aldrig ett program, men dras rutinmässigt in i ett som berörd deltagare när ett ICS rullar ut en delad vårdjournal eller konvergerar system över området. Dess praktiska angelägenhet är den skarv programmet äger: den måste anta de föreskrivna datastandarderna, avtalen om informationsstyrning och samtyckesmodellen med tunn eller ingen dedikerad IT-förmåga och ingen marginal att absorbera arbetsflödesförändring, men bär samma rättsliga plikter som de stora sjukhusen runt den. Den mest värdefulla relationen den har är med förändringsansvarig för sitt område, eftersom ett väl stött införande — utbildning, enhetlig inloggning, ett arbetsflöde som passar hur praktiken faktiskt drivs — är skillnaden mellan att programmets nytta landar och att förändringen i tysthet kringgås. Dess realistiska krav på programmet är proportionerligt stöd och sekvensering som inte förutsätter resurser i företagsskala, och dess ärliga bidrag är tidig, rak återkoppling vid tranchegranskningar om vad som är ogenomförbart på plats.

Storföretag#

Ett ICS eller ett stort sjukhus är det naturliga hemmet för programledt arbete: delade vårdjournaler, EPR-konvergens och förloppsomvandling är i grunden flerorganisatoriska och fleråriga. Det svåra är befogenheten — SRO måste få beslut att hålla över suveräna partnerorganisationer som inte bara kan beordras, så en genuint representativ programstyrelse och förändringsansvariga inbäddade i varje partner är bärande, inte dekorativa. Finansieringen är blandad (systemomvandlingspengar, sjukhuskapital, nationella anslag), vilket gör nyttokartan och tranchegranskningar väsentliga för att försvara fortsatt investering inför systemledare och tillsynsmyndigheter. Den återkommande risken i denna skala är leveransteater: teknisk leverans utan att någon är ansvarig för att förvandla den till nytta.

Staten#

I nationell skala bär program den tyngsta styrningen — de går typiskt in i Government Major Projects Portfolio, genomgår kvalitetssäkring och gateway-granskningar av Infrastructure and Projects Authority och svarar inför ministrar, Public Accounts Committee och National Audit Office. SRO är personligt och offentligt ansvarig för nyttorealisering över hela systemet, och ritningar måste förena nationella standarder (interoperabilitet, informationsstyrning, NHS App som gemensam ytterdörr) med lokal autonomi. Finansiering löper genom fleråriga utgiftsöversyner, så tranchering och nyttoevidens är mekanismen för att upprätthålla eller stoppa investering över budget- och politiska cykler. Insatserna är på befolkningsnivå: ett nationellt programs nyttor — eller dess misslyckande — mäts i miljontals patienter och miljarder pund.

Vanliga felmönster#

• Leveransteater. Programmet levererar tekniska leveranser men ingen äger att förvandla dem till nyttor, så ingenting förändras för patienter. Åtgärd: nyttokartor med ägare och BCM i den operativa verksamheten.
• Ett program som bara är ett stort projekt. Styrning med fast omfång och leveransfokus tillämpad på genuint osäker, flerorganisatorisk förändring. Åtgärd: styr efter utfall/nyttor och transcher, inte en enda fryst plan.
• En maktlös SRO. Ansvar utan befogenhet att avgöra över gränser. Åtgärd: utse en SRO tillräckligt senior för att få tvärsystembeslut att hålla, uppbackad av en representativ styrelse.
• Ingen ritning / inget målläge. Projekt optimerar lokalt och delarna hänger aldrig ihop. Åtgärd: definiera och underhåll en POTI-ritning som allt styrs mot.
• Big bang i stället för transcher. All risk skjuts till en enda sen leverans. Åtgärd: tranchera arbetet, ta hem tidiga nyttor och planera om vid granskningspunkter.
• Program som aldrig avslutas. Det blir en permanent byråkrati långt efter att förändringen förankrats. Åtgärd: avsluta medvetet, lämna över varaktiga tjänster till produktteam, fortsätt följa nyttor i ordinarie verksamhet.

Mognadsmodell#

Checklista#

• Är detta genuint flerprojekts-, flerorganisatorisk förändring mot ett strategiskt utfall?
• Finns en tydlig vision och en konkret ritning (målbild för verksamhetsmodellen / POTI)?
• Finns en nyttokarta som kopplar leveranser till mätbara, ägda, med baslinjea nyttor?
• Är arbetet strukturerat i transcher med verkliga fortsätt/justera/stoppa-granskningspunkter?
• Finns en bemyndigad SRO med befogenhet att avgöra över organisationsgränser?
• Företräder programstyrelsen genuint de berörda organisationerna?
• Är förändringsansvariga inbäddade i den operativa verksamheten för att äga införande?
• Förvaltas tvärgående standarder, beroenden och delade risker på programnivå?
• Samexisterar produktledda, projektledda och programledda arbetssätt med tydliga roller (Ämne 5.0–5.2)?
• Finns ett medvetet avslut, med varaktiga tjänster överlämnade till varaktiga produktteam och nyttor följda in i ordinarie verksamhet?

Viktiga källor#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): principer, teman och omvandlingsflödet (inklusive ritning, transcher, nyttohantering och rollerna SRO/BCM).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — vägledning om större program, SRO-ansvar och kvalitetssäkring/gateway-granskningar.
• HM Treasury — The Green Book och vägledning om nyttohantering (bedömning och utvärdering av nyttor).
• AXELOS — Management of Portfolios (MoP), för att placera program i en portfölj (se Ämne 5.3 — Företagsövergripande projektportföljhantering (EPPM)).
• NHS England — vägledning om integrerade vårdsystem och delade vårdjournaler (interoperabilitet, HL7 FHIR-standarder) för domänkontexten.
• Mik Kersten — Project to Product, för skiftet från leveransbaserad till utfalls-/nyttobaserad investering.

Referenser#

1. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipedia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipedia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipedia — 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/