Emne 5.2 — Programledet arbejde

I én sætning: Programledet arbejde koordinerer en række beslægtede projekter og produkter mod en strategisk forandring, som ingen af dem kunne levere alene, og bevarer en klar synslinje fra arbejdet til de gevinster, det skal realisere.

Hvorfor det er vigtigt i sundhed og pleje#

De største forandringer i sundhed og pleje er aldrig et enkelt projekt. Udrulning af en fælles omsorgsjournal på tværs af et integreret plejesystem (ICS), flytning af en region til én elektronisk patientjournal, transformation af et akut- og skadestuforløb eller levering af et virtuelt afdelingsprogram på tværs af flere hospitaler — hver af disse er en koordineret pakke af projekter, produktteams, arbejdsstyrkeforandring, bygningsarbejde og klinisk redesign, afstemt til ét strategisk resultat. Styres brikkerne isoleret, kolliderer de: uforenelige datastandarder, duplikerede udgifter, modstridende kliniske arbejdsgange og gevinster, der aldrig reelt materialiserer sig.

Programledelse findes for at holde den koalition sammen og for at holde den rettet mod resultater og gevinster, ikke blot outputs. Det betyder meget i sundhed og pleje, fordi systemomfattende forandring berører patientsikkerhed på tværs af organisatoriske grænser, binder store offentlige summer over flere år og afhænger af, at mange autonome organisationer vælger at bevæge sig i takt. Et program leverer ledelsen, den fælles målsituation og gevinstdisciplinen til at få det til at ske — og, lige så vigtigt, til at vide, om det virker.

Det tilbagevendende svigt, det værner imod, er programmet, der bruger millioner, leverer en bunke tekniske outputs og alligevel ikke ændrer noget målbart for patienter eller personale. Dette emne bruger Managing Successful Programmes (MSP), den britiske offentlige sektors dominerende rammeværk, og viser, hvordan programledet arbejde sameksisterer med de projektledede (emne 5.1 — Projektledet arbejde) og produktledede (emne 5.0 — Produktledet arbejde) arbejdsformer, det koordinerer. Emne 5.3 — Virksomhedsdækkende projektporteføljestyring (EPPM) forklarer derefter, hvordan en organisation prioriterer på tværs af mange programmer.

Kernebegreber#

Program. En midlertidig, fleksibel organisation oprettet for at koordinere, lede og overvåge en gruppe beslægtede projekter og aktiviteter for at levere resultater og gevinster afstemt til strategiske mål. Et program adskiller sig fra et projekt ved at være defineret af det resultat og de gevinster, det søger, og det håndterer usikkerheden ved at koordinere mange bevægelige dele frem for at levere ét fast output.

MSP (Managing Successful Programmes). Det britiske best practice-rammeværk til styring af transformerende forandring gennem flere beslægtede projekter. Det er organiseret omkring principper, temaer og et "transformationsflow" af processer og er designet til stor, kompleks forandring, hvor sluttilstanden er kendt i retning, men vejen involverer mange indbyrdes afhængige leverancer.

Vision og blueprint. Visionen er det overbevisende billede af den fremtid, programmet vil skabe. Blueprintet gør den konkret: det beskriver den fremtidige driftsmodel — den fremtidige tilstand af processer, organisation, teknologi, information og roller (ofte opsummeret som POTI). Blueprintet er det referencepunkt, hvert projekt styres mod, så brikkerne tilsammen bliver en sammenhængende helhed.

Gevinstrealisering. Programledelsens hjerte. Gevinster er de målbare forbedringer, der begrunder investeringen — færre forsinkede udskrivninger, færre duplikerede prøver, hurtigere diagnose, lavere administrativ byrde. MSP behandler identifikation, kortlægning, måling og aktiv styring af gevinster gennem hele livscyklussen som en kernedisciplin, fordi outputs kun skaber værdi, når de bruges til at ændre, hvordan pleje leveres.

Tranches. MSP opdeler et program i tranches — blokke af arbejde, der slutter ved et større gennemgangspunkt, hvor et trin af kapabilitet er leveret, og gevinstrealisering kan begynde. En tranche er et øjeblik til at demonstrere resultater, revurdere blueprintet mod virkeligheden og beslutte, om man skal fortsætte, justere eller stoppe, frem for blot en skive af tidsplanen.

Programbestyrelse og SRO. Senior Responsible Owner (SRO) er den ene person, der er ansvarlig for, at programmet opfylder sine mål og realiserer sine gevinster, med tilstrækkelig anciennitet og beføjelse til at lede og træffe beslutninger. SRO’en leder en programbestyrelse — typisk en forandringsansvarlig, projektledere og seniorinteressenter — der giver retning på tværs af organisatoriske grænser.

Forandringsansvarlig (business change manager, BCM). MSP’s karakteristiske rolle: en person fra den operationelle forretning (ikke leveranceholdet), der er ansvarlig for at forankre forandringen og realisere gevinsterne i praksis. BCM’en er grunden til, at programmer leverer resultater og ikke blot outputs — projekter overdrager kapabilitet, BCM’en omsætter den til gevinst.

Bedste praksis#

1. Forankr programmet i en vision og et blueprint. Definér det strategiske resultat, og omsæt det til en konkret fremtidig driftsmodel (processer, organisation, teknologi, information — POTI). Hvert underliggende projekt og produkt styres så mod den samme fremtidige tilstand, hvilket forhindrer en koalition af leverancer i at fragmentere.

2. Styr gevinster, ikke blot leverancer. Byg et gevinstkort, der kobler hvert output til de resultater og målbare gevinster, det skal producere, med ejere og baselines. Gennemgå gevinster aktivt på tværs af programmet, og vær villige til at stoppe arbejde, der ikke vil betale sig tilbage — MSP’s vægt på gevinstrealisering er den disciplin, der adskiller et program fra en dyr opgaveliste.

3. Strukturér arbejdet i tranches med reelle gennemgangspunkter. Lever kapabilitet i tranches, og demonstrér ved hver tranchegrænse de gevinster, der er realiseret indtil videre, gentest blueprintet mod det, I har lært, og træf en ægte fortsæt/justér/stop-beslutning. Tidlige tranches bør målrette synlige hurtige gevinster for at opbygge interessenternes tillid til de sværere senere.

4. Udpeg en bemyndiget SRO og en reel programbestyrelse. Nævn en enkelt SRO med den anciennitet og beføjelse, der skal til for at lede programmet og beslutte på tværs af organisatoriske grænser, og indkald en bestyrelse, der reelt repræsenterer de berørte organisationer. Programmer fejler, når ansvaret er diffust, eller SRO’en reelt ikke kan få tværgående beslutninger til at holde.

5. Placér forandringsansvarlige i den operationelle forretning. Tildel BCM’er fra frontlinjeorganisationerne til at eje adoption og gevinstrealisering, hvor pleje leveres. Kapabilitet, der er leveret, men ikke taget i brug, realiserer ingen gevinst; BCM-rollen er mekanismen, der lukker det hul.

6. Koordinér — mikrostyr ikke — de underliggende projekter og produkter. Programmet fastsætter blueprintet, afhængighederne, standarderne og gevinsterne; det lader projekter og produktteams levere inden for den ramme. Det styrer sømmene — fælles datastandarder, informationsstyring, sekvensering og fælles infrastruktur — ikke de interne detaljer i hver leverance.

7. Styr tværgående risiko, afhængighed og interessenter ubønhørligt. Den værdi, et program tilføjer ud over selvstændige projekter, ligger i høj grad i at styre, hvad der sker mellem dem. Vedligehold et overblik på programniveau over indbyrdes afhængigheder og fælles risici, og invester kraftigt i interessenthåndtering på tværs af autonome organisationer, da afstemning er frivillig, ikke beordret.

8. Luk programmet, når forandringen er forankret, og overdrag løbende tjenester til produktteams. Et program er midlertidigt. Når blueprintet er opnået, og gevinster realiseres, luk det bevidst, overfør varige tjenester til varige produktteams (emne 5.0), og bliv ved med at følge gevinster ind i den daglige drift — mange gevinster tilfalder først efter programmet er slut.

Spørgsmål at drøfte med dit team#

1. Har vores senior ansvarlige ejer faktisk beføjelsen til at få beslutninger til at holde på tværs af suveræne partnerorganisationer, eller kun ansvaret, når de ikke gør? Programledet arbejde lever og dør af beføjelse på tværs af grænser, fordi forandringen spænder over autonome hospitaler, primærsektor, kommunal pleje, psykiatri og socialpleje, der ikke blot kan beordres til at bevæge sig i takt. Det karakteristiske svigt er en navngiven SRO, der bærer det personlige, offentlige ansvar for gevinster, men mangler stående til at tvinge en tøvende partner til at tage en fælles datastandard i brug eller ændre en klinisk arbejdsgang — ansvar uden beføjelse. Debatten bør være åben om, hvor den reelle magt sidder i systemet: om programbestyrelsen reelt repræsenterer de berørte organisationer eller er et rapporteringsforum, om SRO’en er senior nok til, at vedkommendes beslutninger respekteres på tværs af suveræne grænser, og hvad der sker, når en partner afviser at bevæge sig. Overvej en nylig beslutning på tværs af organisationer, og følg, om den faktisk holdt. Et godt svar nævner, hvem SRO’en er, og prøver vedkommendes beføjelse mod en konkret konflikt på tværs af grænser, er ærligt om de organisationer, der reelt kan fravælge, og behandler en repræsentativ bestyrelse og indlejrede forandringsansvarlige som bærende mekanismer for frivillig afstemning frem for styringsudsmykning.

2. Hvordan ved vi, at dette program har realiseret gevinster og ikke blot leveret outputs — og hvem i den operationelle forretning er ansvarlig for at omsætte kapabilitet til gevinst? Outputteater er den tilbagevendende patologi, emnet advarer imod: et program bruger millioner, producerer en bunke interoperabilitetsplatforme og integrationer, og alligevel ændres intet målbart for patienter eller personale. Det skel, der forhindrer det, er forandringsansvarlig — en person fra frontlinjens drift, ikke leveranceholdet, ansvarlig for at forankre forandringen og realisere gevinst, hvor pleje leveres — så spørgsmålet tvinger teamet til at nævne de personer og bekræfte, at de findes. Spændingen er, at levering er synlig og tilfredsstillende, mens adoption er langsom, uglamourøs og let at antage vil ske af sig selv; en fælles omsorgsjournal gemt bag et ekstra login realiserer ingen gevinst, uanset hvor godt den er bygget. Tag gevinstkortet med til diskussionen, og stresstest, om hvert output er koblet til en ejet, baselinet, målbar gevinst (færre duplikerede prøver, reducerede forsinkede udskrivninger) eller om gevinster blot postuleres. Et ærligt svar nævner en BCM i hver partnerorganisation, indrømmer, hvor gevinster i dag er uejede eller umålte, og accepterer, at nogle gevinster først tilfalder efter programmet lukker og skal følges ind i den daglige drift.

3. Opdeler vi dette program i tranches for at hjemtage tidlige gevinster og skabe reelle fortsæt/justér/stop-punkter, eller glider vi mod en big-bang-levering, der udskyder al risiko til ét sent øjeblik? Tranches er det, der adskiller et program fra en dyr frossen plan: hver tranchegrænse bør levere et trin af kapabilitet, demonstrere hidtil realiserede gevinster, gentest blueprintet mod det, der faktisk er lært, og understøtte en ægte beslutning om at fortsætte, justere eller stoppe. Fristelsen i sundhed og pleje er at sekvensere af hensyn til ingeniørbekvemmelighed og udskyde synlig værdi — at forbinde alle hospitaler, før nogen kan bruge noget — hvilket lægger al risiko i én sen levering og efterlader bestyrelsen uden evidens til at forsvare fortsat investering gennem finansielle og politiske cyklusser. Debatten bør undersøge, om tidlige tranches målretter bevidste hurtige gevinster, der opbygger interessenternes tillid til det sværere senere arbejde, og om gennemgangspunkterne er reelle beslutninger eller tidsplankontrolpunkter. Overvej, hvad den første påviselige gevinst er, hvor hurtigt den lander, og hvad bestyrelsen faktisk ville gøre ved en tranchegennemgang, hvis adoptionen haltede, eller blueprintet viste sig forkert. Et godt svar beskriver konkrete tranches med tidlige, målbare gevinster, behandler hver grænse som en ægte go/no-go med blueprintet reelt åbent for revision og er ærligt om ethvert pres for at udskyde værdi til slutningen.

4. Har vi ét enkelt, vedligeholdt blueprint af den fremtidige driftsmodel, eller optimerer hvert projekt i det stille mod sin egen version af fremtiden? Blueprintet — den konkrete POTI-målsituation for processer, organisation, teknologi og information — er det, der får brikkerne til at blive en sammenhængende helhed frem for et sammenstød af lokalt fornuftige beslutninger. Uden et optimerer hvert underliggende projekt rationelt for sit eget omfang: ét hospital vælger en datastandard, der passer til dets eksisterende EPJ, et andet designer en klinisk arbejdsgang omkring sin egen bemanding, og den fælles omsorgsjournal fragmenterer til integrationer, der teknisk forbinder, men ikke hænger sammen. Spændingen er, at vedligeholdelse af et blueprint føles som overhead for leveranceteams under pres for at levere, og at det skal være en levende reference, gentestet ved hver tranche, frem for et dokument skrevet én gang og lagt på hylden. Debatten bør fastslå, om blueprintet faktisk findes i brugbar form, hvem der ejer det, og om reelle projektbeslutninger styres af det eller blot afstemmes til det bagefter. Overvej et nyligt designvalg i ét projekt, og spørg, om blueprintet formede det eller i det stille blev tilsidesat. Et ærligt svar kan pege på et aktuelt blueprint, nævner dets ejer og er åbent om, hvor lokal optimering allerede trækker målsituationen fra hinanden.

5. Når programmet lukker, hvad består så — og har vi navngivet de varige produktteams, der vil drive kapabiliteten og blive ved med at følge gevinster ind i den daglige drift? Et program er midlertidigt pr. definition, men den fælles omsorgsjournal, interoperabilitetsplatformen og de gevinster, de producerer, er det ikke, så lukning er et designproblem, der skal planlægges fra starten frem for en eftertanke. Det tilbagevendende svigt i hver ende af spektret er reelt: nogle programmer lukker aldrig og hærder til permanente bureaukratier længe efter forandringen er forankret, mens andre lukker brat og efterlader en levende klinisk tjeneste uden varig ejer. Emnet er eksplicit om, at varige tjenester bør overføres til varige produktteams (emne 5.0), og at mange gevinster først tilfalder efter programmet slutter og skal følges ind i den daglige drift — hvilket betyder, at de modtagende teams og det løbende gevinstejerskab skal identificeres, mens programmet stadig har beføjelsen og finansieringen til at etablere dem. Debatten bør bringe frem, hvem der vil drive hver varig kapabilitet, hvordan den finansieres, når transformationspengene stopper, og hvem der bliver ved med at måle gevinster, når programbestyrelsen er opløst. Et godt svar nævner de konkrete produktteams og driftsejere, beskriver finansieringsovergangen ærligt og behandler lukning og gevinstopfølgning som planlagte tranches frem for en håbefuld overdragelse.

6. Hvordan styrer vi sømmene mellem projekter — fælles standarder, informationsstyring, sekvensering og fælles infrastruktur — frem for det indre af hver leverance? Den værdi, et program tilføjer ud over et sæt selvstændige projekter, bor næsten helt i rummet mellem dem: afhængighederne, de fælles datastandarder, informationsstyrings- og samtykkerammen og den fælles infrastruktur, som intet enkelt projekt ejer, men alle afhænger af. Fristelsen for et programteam er at glide ind i mikrostyring af det indre i hver leverance — komfortabelt, synligt arbejde — mens de reelt svære tværgående sømme forbliver ustyrede, til de dukker op som et integrationssvigt eller en informationsstyringsblokering ved go-live. I sundhed og pleje er disse sømme usædvanligt bærende, fordi dataflow og samtykke krydser suveræne organisatoriske og regulatoriske grænser, hvor afstemning er frivillig, og juridiske pligter er delte, men ujævnt ressourcesatte. Debatten bør teste, om der er et overblik på programniveau over indbyrdes afhængigheder og fælles risici, hvem der ejer de fælles standarder og infrastrukturen, og om programmet koordinerer sømme eller blander sig i projektdetaljer. Et ærligt svar identificerer de specifikke sømme, der mest truer resultatet, nævner deres ejere og er åbent om, hvorvidt programmet tilfører værdi ved grænserne eller duplikerer arbejdet i de projekter, det skulle muliggøre.

I praksis: et eksempel fra sundhed og pleje#

Et ICS sætter sig for at levere en fælles omsorgsjournal, der giver klinikere på tværs af akut, kommunal, psykiatrisk, primær og social pleje et samlet overblik over en person. Intet enkelt projekt kan levere dette: det spænder over flere hospitaler, flere kildesystemer, informationsstyringsaftaler, redesign af kliniske arbejdsgange og offentlig inddragelse. Det koordineres som et MSP-program.

SRO’en — en ICS-direktør med reel beføjelse på tværs af systemet — leder en programbestyrelse med repræsentanter fra hver partnerorganisation og navngivne forandringsansvarlige i hver. Programmet fastsætter en vision ("de rette oplysninger om den rette person, tilgængelige for den rette kliniker i behandlingsøjeblikket") og et blueprint, der beskriver den fremtidige driftsmodel: dataudvekslingsarkitekturen og standarderne (HL7 FHIR-baseret interoperabilitet), informationsstyringsrammen, samtykkemodellen og de redesignede kliniske arbejdsgange.

Arbejdet er organiseret i tranches. Tranche ét forbinder to villige akuthospitaler og leverer en skrivebeskyttet journal, en bevidst hurtig gevinst, der beviser tilgangen og lader bestyrelsen demonstrere en tidlig gevinst — en målbar reduktion i duplikerede prøver — for at opbygge tillid. Ved tranche-ét-gennemgangen lærer bestyrelsen, at klinikeradoptionen halter, hvor journalen er gemt bag et ekstra login, så den justerer blueprintet til at prioritere single sign-on-integration, før udrulningen udvides.

Under programmet sameksisterer arbejdsformerne. Interoperabilitetsplatformen drives af et varigt produktteam (emne 5.0), der bliver ved med at forbedre den gennem hele programmet og videre. Hvert hospitals tilslutning er et afgrænset projekt (emne 5.1) med sin egen business case og go-live. Selve programmet koordinerer blueprintet, standarderne, afhængighederne og — gennem BCM’erne — gevinstrealiseringen. Når blueprintet er opnået, og gevinsterne ved færre duplikerede prøver og forsinkede udskrivninger flyder, lukker programmet; platformens produktteam består, og gevinstopfølgningen fortsætter ind i den daglige drift.

Sektorperspektiver#

Startup#

Få startups kører programmer i MSP’s forstand — de mangler det flerorganisatoriske omfang, der definerer et — men en scale-up, der udrulles på tværs af flere hospitaler, bliver reelt en programdeltager. Dens realistiske rolle er som leverandør inde i en andens program: at afstemme sit produkt til programmets blueprint, ramme tranchemilepæle og fodre den gevinstcase, SRO’en skal dokumentere. Finansiering og overlevelse afhænger af, at programmet fortsætter, så startuppen behandler tranchegennemgange som eksistentielle go/no-go-punkter og investerer i de forandringsansvarliges succes, fordi adoption i praksis er det, der fornyer dens kontrakt. Den disciplin, den må låne, er gevinstsprog — at rammesætte sin værdi som realiserede resultater, ikke leverede funktioner.

Lille virksomhed#

En etableret lille udbyder — en lægepraksis, et lokalt apotek, et plejehjem eller en lille sundhedsteknologileverandør forbi startup-fasen — kører næsten aldrig et program, men bliver rutinemæssigt revet med ind i et som berørt deltager, når et ICS udruller en fælles omsorgsjournal eller konvergerer systemer på tværs af området. Dens praktiske bekymring er den søm, programmet ejer: den skal tage de påbudte datastandarder, informationsstyringsaftaler og samtykkemodel i brug med tynd eller ingen dedikeret it-kapacitet og intet slæk til at absorbere arbejdsgangsændringer, men bærer alligevel de samme juridiske pligter som de store hospitaler omkring den. Det mest værdifulde forhold, den har, er til den forandringsansvarlige for sit lokalområde, fordi en velstøttet adoption — uddannelse, single sign-on, en arbejdsgang der passer til, hvordan praksis faktisk kører — er forskellen mellem, at programmets gevinst lander, og at forandringen i det stille omgås. Dens realistiske krav til programmet er proportional støtte og sekvensering, der ikke forudsætter ressourcer i virksomhedsskala, og dens ærlige bidrag er tidlig, åben feedback ved tranchegennemgange om, hvad der er uarbejdsdueligt i praksis.

Stor virksomhed#

Et ICS eller et stort hospital er det naturlige hjem for programledet arbejde: fælles omsorgsjournaler, EPJ-konvergens og forløbstransformation er iboende flerorganisatoriske og flerårige. Det svære er beføjelse — SRO’en må få beslutninger til at holde på tværs af suveræne partnerorganisationer, der ikke blot kan beordres, så en reelt repræsentativ programbestyrelse og forandringsansvarlige indlejret i hver partner er bærende, ikke dekorative. Finansiering er blandet (systemtransformationsmidler, hospitalskapital, nationale tildelinger), hvilket gør gevinstkortet og tranchegennemgangene afgørende for at forsvare fortsat investering over for systemledere og regulatorer. Den tilbagevendende risiko i denne skala er outputteater: teknisk levering uden nogen ansvarlig for at omsætte den til gevinst.

Myndighed#

I national skala bærer programmer den tungeste styring — de indgår typisk i Government Major Projects Portfolio, gennemgår Infrastructure and Projects Authority-assurance og gateway-reviews og svarer til ministre, Public Accounts Committee og National Audit Office. SRO’en er personligt og offentligt ansvarlig for gevinstrealisering på tværs af hele systemet, og blueprints skal forene nationale standarder (interoperabilitet, informationsstyring, NHS App som fælles hoveddør) med lokal autonomi. Finansiering løber gennem flerårige Spending Review-bevillinger, så tranching og gevinstevidens er mekanismen til at opretholde eller standse investering på tværs af finansielle og politiske cyklusser. Indsatsen er i befolkningsskala: et nationalt programs gevinster — eller dets fiasko — måles i millioner af patienter og milliarder af pund.

Typiske fejlmønstre#

• Outputteater. Programmet leverer tekniske outputs, men ingen ejer omsætningen til gevinster, så intet ændres for patienter. Løsning: gevinstkort med ejere og BCM’er i den operationelle forretning.
• Et program, der blot er et stort projekt. Fast-omfangs-, outputfokuseret styring anvendt på reelt usikker, flerorganisatorisk forandring. Løsning: styr efter resultater/gevinster og tranches, ikke én frossen plan.
• En magtesløs SRO. Ansvar uden beføjelse til at beslutte på tværs af grænser. Løsning: udpeg en SRO, der er senior nok til at få beslutninger på tværs af systemet til at holde, bakket op af en repræsentativ bestyrelse.
• Intet blueprint / ingen målsituation. Projekter optimerer lokalt, og brikkerne hænger aldrig sammen. Løsning: definér og vedligehold et POTI-blueprint, alt styres mod.
• Big bang i stedet for tranches. Al risiko udskudt til én sen levering. Løsning: opdel arbejdet i tranches, hjemtag tidlige gevinster og omplanlæg ved gennemgangspunkter.
• Program, der aldrig lukker. Det bliver et permanent bureaukrati længe efter forandringen er forankret. Løsning: luk bevidst, overdrag varige tjenester til produktteams, og bliv ved med at følge gevinster i den daglige drift.

Modenhedsmodel#

Tjekliste#

• Er dette reelt forandring på tværs af flere projekter og organisationer mod ét strategisk resultat?
• Er der en klar vision og et konkret blueprint (fremtidig driftsmodel / POTI)?
• Er der et gevinstkort, der kobler outputs til målbare, ejede, baselinede gevinster?
• Er arbejdet struktureret i tranches med reelle fortsæt/justér/stop-gennemgangspunkter?
• Er der en bemyndiget SRO med beføjelse til at beslutte på tværs af organisatoriske grænser?
• Repræsenterer programbestyrelsen reelt de berørte organisationer?
• Er forandringsansvarlige indlejret i den operationelle forretning til at eje adoption?
• Styres tværgående standarder, afhængigheder og fælles risici på programniveau?
• Sameksisterer produktledede, projektledede og programledede arbejdsformer med klare roller (emne 5.0–10)?
• Er der en bevidst lukning, med varige tjenester overdraget til varige produktteams og gevinster fulgt ind i den daglige drift?

Centrale kilder#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): principper, temaer og transformationsflowet (herunder blueprint, tranches, gevinststyring og SRO/BCM-rollerne).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — vejledning om større programmer, SRO-ansvar og assurance/gateway-reviews.
• HM Treasury — The Green Book og vejledning i gevinststyring (vurdering og evaluering af gevinster).
• AXELOS — Management of Portfolios (MoP), til placering af programmer i en portefølje (se emne 5.3 — EPPM).
• NHS England — vejledning om integrerede plejesystemer og fælles omsorgsjournaler (interoperabilitet, HL7 FHIR-standarder) til domænekontekst.
• Mik Kersten — Project to Product, til skiftet fra outputbaseret til resultat-/gevinstbaseret investering.

Referencer#

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/