Onderwerp 5.2 — Programmagestuurd werken

In één zin: Programmagestuurd werken coördineert een reeks verwante projecten en producten naar een strategische verandering die geen van hen alleen kan leveren, en houdt een duidelijke zichtlijn tussen het werk en de baten die het moet realiseren.

Waarom dit ertoe doet in gezondheid en zorg#

De grootste veranderingen in gezondheid en zorg zijn nooit één enkel project. Een gedeeld zorgdossier uitrollen over een integrated care system (ICS), een regio naar één elektronisch patiëntendossier brengen, een traject voor spoedeisende zorg transformeren of een programma voor virtuele afdelingen over meerdere ziekenhuizen leveren — elk daarvan is een gecoördineerde bundel van projecten, productteams, verandering in het personeel, werk aan huisvesting en klinisch herontwerp, afgestemd op één strategische uitkomst. Beheer de onderdelen afzonderlijk en ze botsen: onverenigbare datastandaarden, dubbele uitgaven, tegenstrijdige klinische werkstromen en baten die nooit werkelijk worden gerealiseerd.

Programmamanagement bestaat om die coalitie bijeen te houden en gericht op uitkomsten en baten, niet alleen op opbrengsten. Dit doet er acuut toe in gezondheid en zorg omdat verandering op systeemniveau de patiëntveiligheid over organisatiegrenzen heen raakt, grote sommen publiek geld over meerdere jaren vastlegt en afhangt van veel autonome organisaties die ervoor kiezen in de pas te bewegen. Een programma biedt het leiderschap, de gedeelde doeltoestand en de batendiscipline om dat mogelijk te maken — en, even belangrijk, om te weten of het werkt.

Het terugkerende falen waartegen het beschermt is het programma dat miljoenen uitgeeft, een stapel technische opbrengsten levert en toch niets meetbaars verandert voor patiënten of personeel. Dit onderwerp gebruikt Managing Successful Programmes (MSP), het overheersende kader van de Britse publieke sector, en toont hoe programmagestuurd werk naast de projectgestuurde (Onderwerp 5.1 — Projectgestuurd werken) en productgestuurde (Onderwerp 5.0 — Productgestuurd werken) werkwijzen bestaat die het coördineert. Onderwerp 5.3 — Enterprise-projectportfoliomanagement (EPPM) legt vervolgens uit hoe een organisatie prioriteert over veel programma’s.

Kernbegrippen#

Programma. Een tijdelijke, flexibele organisatie opgericht om een groep verwante projecten en activiteiten te coördineren, aan te sturen en te overzien om uitkomsten en baten te leveren die zijn afgestemd op strategische doelen. Een programma verschilt van een project doordat het wordt gedefinieerd door de uitkomst en baten die het nastreeft, en de onzekerheid beheert van het coördineren van veel bewegende delen in plaats van één vaste opbrengst te leveren.

MSP (Managing Successful Programmes). Het Britse kader van beste praktijken voor het beheren van transformerende verandering via meerdere verwante projecten. Het is georganiseerd rond beginselen, thema’s en een “transformationele stroom” van processen, en ontworpen voor grote, complexe verandering waarvan de eindtoestand in richting bekend is maar het pad veel onderling afhankelijke leveringen omvat.

Visie en blauwdruk. De visie is het aansprekende beeld van de toekomst die het programma zal scheppen. De blauwdruk maakt haar concreet: zij beschrijft het doeloperatiemodel (target operating model) — de toekomstige toestand van processen, organisatie, technologie, informatie en rollen (vaak samengevat als POTI). De blauwdruk is het referentiepunt waarnaar elk project wordt gestuurd, zodat de onderdelen optellen tot een samenhangend geheel.

Batenrealisatie. Het hart van programmamanagement. Baten zijn de meetbare verbeteringen die de investering rechtvaardigen — minder vertraagde ontslagen, minder dubbele onderzoeken, snellere diagnose, lagere administratieve last. MSP behandelt het identificeren, in kaart brengen, meten en actief beheren van baten over de hele levenscyclus als kerndiscipline, omdat opbrengsten alleen waarde scheppen wanneer zij worden gebruikt om te veranderen hoe zorg wordt geleverd.

Tranches. MSP breekt een programma op in tranches — blokken werk die eindigen bij een belangrijk toetsmoment waarop een stap in vermogen is geleverd en batenrealisatie kan beginnen. Een tranche is een moment om uitkomsten aan te tonen, de blauwdruk aan de werkelijkheid te toetsen en te beslissen door te gaan, bij te sturen of te stoppen, en niet louter een plak van de planning.

Programmabestuur en SRO. De Senior Responsible Owner (SRO) is de ene persoon die verantwoordelijk is voor het halen van de doelstellingen van het programma en het realiseren van de baten, met voldoende senioriteit en gezag om te leiden en beslissingen te nemen. De SRO zit een programmabestuur voor — doorgaans een business change manager, projectleiders en senior belanghebbenden — dat richting geeft over organisatiegrenzen heen.

Business change manager (BCM). De onderscheidende rol van MSP: iemand uit de operationele organisatie (niet het leveringsteam) die verantwoordelijk is voor het inbedden van de verandering en het realiseren van de baten op de werkvloer. De BCM is waarom programma’s uitkomsten leveren en niet alleen opbrengsten — projecten dragen vermogen over, de BCM maakt er baat van.

Beste praktijken#

1. Verankeer het programma in een visie en een blauwdruk. Definieer de strategische uitkomst en vertaal haar naar een concreet doeloperatiemodel (processen, organisatie, technologie, informatie — POTI). Elk samenstellend project en product wordt dan gestuurd naar dezelfde toekomstige toestand, wat een coalitie van leveringen ervan weerhoudt uiteen te vallen.

2. Beheer baten, niet alleen deliverables. Bouw een batenkaart die elke opbrengst koppelt aan de uitkomsten en meetbare baten die zij moet voortbrengen, met eigenaren en nulmetingen. Toets baten actief over het programma en wees bereid werk te stoppen dat zich niet zal terugbetalen — de nadruk van MSP op batenrealisatie is de discipline die een programma onderscheidt van een dure takenlijst.

3. Structureer het werk in tranches met echte toetsmomenten. Lever vermogen in tranches en toon bij elke tranchegrens de tot dan toe gerealiseerde baten aan, toets de blauwdruk opnieuw aan wat u hebt geleerd en neem een echte beslissing om door te gaan, bij te sturen of te stoppen. Vroege tranches moeten zichtbare snelle winsten nastreven om het vertrouwen van belanghebbenden voor de moeilijkere latere op te bouwen.

4. Benoem een bevoegde SRO en een echt programmabestuur. Noem één SRO met de senioriteit en het gezag om het programma aan te sturen en over organisatiegrenzen heen te beslissen, en roep een bestuur bijeen dat de betrokken organisaties werkelijk vertegenwoordigt. Programma’s falen wanneer verantwoording diffuus is of de SRO beslissingen over grenzen heen niet kan laten standhouden.

5. Plaats business change managers in de operationele organisatie. Wijs BCM’s uit de organisaties in de frontlinie aan om adoptie en batenrealisatie te bezitten waar zorg wordt geleverd. Vermogen dat wordt geleverd maar niet wordt overgenomen realiseert geen baat; de rol van de BCM is het mechanisme dat die kloof dicht.

6. Coördineer — micromanage niet — de samenstellende projecten en producten. Het programma stelt de blauwdruk, de onderlinge afhankelijkheden, de normen en de baten vast; het laat projecten en productteams binnen dat kader leveren. Het beheert de naden — gedeelde datastandaarden, informatiebeheer, volgorde en gedeelde infrastructuur — niet het interne detail van elke levering.

7. Beheer overkoepelend risico, afhankelijkheid en belanghebbenden onophoudelijk. De waarde die een programma toevoegt boven losse projecten ligt grotendeels in het beheren van wat er tussen hen gebeurt. Houd een overzicht op programmaniveau van onderlinge afhankelijkheden en gedeelde risico’s en investeer zwaar in betrokkenheid van belanghebbenden over autonome organisaties heen, want afstemming is vrijwillig en niet bevolen.

8. Sluit het programma wanneer de verandering is ingebed en draag doorlopende diensten over aan productteams. Een programma is tijdelijk. Wanneer de blauwdruk is bereikt en baten worden gerealiseerd, sluit het bewust af, draag blijvende diensten over aan duurzame productteams (Onderwerp 5.0) en blijf baten volgen in de reguliere bedrijfsvoering — veel baten ontstaan nadat het programma eindigt.

Vragen om met uw team te bespreken#

1. Heeft onze senior responsible owner werkelijk het gezag om beslissingen te laten standhouden over soevereine partnerorganisaties, of alleen de verantwoording wanneer ze dat niet doen? Programmagestuurd werk staat of valt met gezag over grenzen heen, omdat de verandering autonome ziekenhuizen, eerste lijn, gemeenschapszorg, ggz en sociale zorg omspant die niet eenvoudig kunnen worden bevolen in de pas te bewegen. Het kenmerkende falen is een benoemde SRO die de persoonlijke, publieke verantwoording voor baten draagt maar niet het gezag heeft om een onwillige partner te dwingen een gedeelde datastandaard over te nemen of een klinische werkstroom te wijzigen — verantwoording zonder gezag. Het debat moet openhartig zijn over waar de echte macht in het stelsel zit: vertegenwoordigt het programmabestuur de betrokken organisaties werkelijk of is het een rapportageforum, is de SRO senior genoeg dat zijn beslissingen over soevereine grenzen worden gehonoreerd en wat gebeurt er wanneer een partner weigert mee te bewegen. Overweeg een recente beslissing over organisaties heen en volg of zij werkelijk standhield. Een goed antwoord noemt wie de SRO is en toetst diens gezag aan een concreet conflict over grenzen heen, is eerlijk over de organisaties die zich feitelijk kunnen terugtrekken en behandelt een representatief bestuur en ingebedde business change managers als dragende mechanismen voor vrijwillige afstemming en niet als decoratie van bestuur.

2. Hoe weten wij dat dit programma baten heeft gerealiseerd en niet louter opbrengsten heeft geleverd — en wie in de operationele organisatie is verantwoordelijk voor het omzetten van vermogen in baat? Opbrengsttoneel (output theatre) is de terugkerende pathologie waarvoor het onderwerp waarschuwt: een programma geeft miljoenen uit, produceert een stapel platforms en koppelingen voor interoperabiliteit en toch verandert niets meetbaars voor patiënten of personeel. Het onderscheid dat dat voorkomt is de business change manager — iemand uit de operationele frontlinie, niet het leveringsteam, die verantwoordelijk is voor het inbedden van de verandering en het realiseren van baat waar zorg wordt geleverd — dus de vraag dwingt het team die mensen te noemen en te bevestigen dat ze bestaan. De spanning is dat levering zichtbaar en bevredigend is terwijl adoptie traag, onopvallend en gemakkelijk als vanzelfsprekend wordt aangenomen; een gedeeld zorgdossier verstopt achter een extra login realiseert geen baat, hoe goed het ook is gebouwd. Breng de batenkaart naar de discussie en toets of elke opbrengst is gekoppeld aan een bezeten, van een nulmeting voorziene, meetbare baat (minder dubbele onderzoeken, minder vertraagde ontslagen) of dat baten louter worden beweerd. Een eerlijk antwoord noemt een BCM in elke partnerorganisatie, geeft toe waar baten nu zonder eigenaar of ongemeten zijn en aanvaardt dat sommige baten pas ontstaan nadat het programma sluit en moeten worden gevolgd in de reguliere bedrijfsvoering.

3. Delen wij dit programma in tranches op om vroege baten veilig te stellen en echte momenten van doorgaan/bijsturen/stoppen te creëren, of drijven wij naar een big-bang-levering die al het risico naar één laat moment verschuift? Tranches zijn wat een programma onderscheidt van een dure bevroren planning: elke tranchegrens moet een stap in vermogen leveren, de tot dan toe gerealiseerde baten aantonen, de blauwdruk opnieuw toetsen aan wat werkelijk is geleerd en een echte beslissing ondersteunen om door te gaan, bij te sturen of te stoppen. De verleiding in gezondheid en zorg is te ordenen voor het gemak van engineering en zichtbare waarde uit te stellen — elk ziekenhuis verbinden voordat iemand iets kan gebruiken — wat al het risico in één late levering laadt en het bestuur zonder bewijs laat om voortgezette investering te verdedigen door begrotings- en politieke cycli. Het debat moet onderzoeken of vroege tranches bewust snelle winsten nastreven die het vertrouwen van belanghebbenden voor het moeilijkere latere werk opbouwen, en of de toetsmomenten echte beslissingen zijn of planningscontroles. Overweeg wat de eerste aantoonbare baat is, hoe snel zij landt en wat het bestuur bij een toetsing van een tranche werkelijk zou doen als adoptie achterbleef of de blauwdruk onjuist bleek. Een goed antwoord beschrijft concrete tranches met vroege, meetbare winsten, behandelt elke grens als een echte go/no-go waarbij de blauwdruk werkelijk open staat voor herziening en is eerlijk over elke druk om waarde naar het eind uit te stellen.

4. Hebben wij één enkele, onderhouden blauwdruk van het doeloperatiemodel, of optimaliseert elk project stilletjes naar zijn eigen versie van de toekomst? De blauwdruk — het concrete POTI-doeloperatiemodel van processen, organisatie, technologie en informatie — is wat de onderdelen laat optellen tot een samenhangend geheel in plaats van een botsing van lokaal verstandige beslissingen. Zonder haar optimaliseert elk samenstellend project rationeel voor zijn eigen reikwijdte: het ene ziekenhuis kiest een datastandaard die past bij zijn zittende EPD, een ander ontwerpt een klinische werkstroom rond zijn eigen bezetting en het gedeelde zorgdossier valt uiteen in koppelingen die technisch verbinden maar niet samenhangen. De spanning is dat een blauwdruk onderhouden voor leveringsteams onder druk om op te leveren als overhead voelt, en zij moet een levende referentie zijn die bij elke tranche opnieuw wordt getoetst en niet een eenmaal geschreven en opgeborgen document. Het debat moet vaststellen of de blauwdruk in bruikbare vorm bestaat, wie haar bezit en of echte projectbeslissingen erdoor worden gestuurd of er achteraf slechts mee in overeenstemming worden gebracht. Overweeg een recente ontwerpkeuze in één project en vraag of de blauwdruk haar vormde of stilletjes werd genegeerd. Een eerlijk antwoord kan wijzen op een actuele blauwdruk, noemt haar eigenaar en is openhartig over waar lokale optimalisatie de doeltoestand al uiteen trekt.

5. Wat blijft er bestaan wanneer het programma sluit — en hebben wij de duurzame productteams benoemd die het vermogen zullen runnen en baten blijven volgen in de reguliere bedrijfsvoering? Een programma is per definitie tijdelijk, maar het gedeelde zorgdossier, het platform voor interoperabiliteit en de baten die ze voortbrengen zijn dat niet, dus afsluiting is een ontwerpprobleem dat vanaf het begin moet worden gepland en geen bijzaak. Het terugkerende falen aan beide uiteinden van het spectrum is echt: sommige programma’s sluiten nooit en verharden tot permanente bureaucratieën lang nadat de verandering is ingebed, terwijl andere abrupt sluiten en een live klinische dienst zonder duurzame eigenaar achterlaten. Het onderwerp is expliciet dat blijvende diensten moeten overgaan naar duurzame productteams (Onderwerp 5.0) en dat veel baten pas ontstaan nadat het programma eindigt en moeten worden gevolgd in de reguliere bedrijfsvoering — wat betekent dat de ontvangende teams en het doorlopende eigenaarschap van baten moeten worden geïdentificeerd terwijl het programma nog het gezag en de financiering heeft om ze te vestigen. Het debat moet aan het licht brengen wie elk blijvend vermogen zal runnen, hoe het wordt gefinancierd wanneer het geld voor transformatie stopt en wie baten blijft meten wanneer het programmabestuur is ontbonden. Een goed antwoord noemt de specifieke productteams en eigenaren van de reguliere bedrijfsvoering, beschrijft de overgang van financiering eerlijk en behandelt afsluiting en het volgen van baten als geplande tranches en niet als een hoopvolle overdracht.

6. Hoe beheren wij de naden tussen projecten — gedeelde normen, informatiebeheer, volgorde en gedeelde infrastructuur — in plaats van de interne zaken van elke levering? De waarde die een programma toevoegt boven een reeks losse projecten ligt vrijwel geheel in de ruimte tussen hen: de onderlinge afhankelijkheden, de gedeelde datastandaarden, het kader voor informatiebeheer en toestemming en de gemeenschappelijke infrastructuur die geen enkel project bezit maar van alle afhangen. De verleiding voor een programmateam is af te drijven naar het micromanagen van de interne zaken van elke levering — comfortabel, zichtbaar werk — terwijl de werkelijk moeilijke overkoepelende naden onbeheerd blijven tot ze opduiken als een integratiefout of een blokkade door informatiebeheer bij go-live. In gezondheid en zorg zijn deze naden ongewoon dragend, omdat dataverkeer en toestemming soevereine organisatorische en regelgevende grenzen oversteken waar afstemming vrijwillig is en wettelijke plichten gedeeld maar ongelijk bemand zijn. Het debat moet toetsen of er een overzicht op programmaniveau is van onderlinge afhankelijkheden en gedeelde risico’s, wie de gedeelde normen en infrastructuur bezit en of het programma naden coördineert of zich met projectdetails bemoeit. Een eerlijk antwoord identificeert de specifieke naden die de uitkomst het meest bedreigen, noemt hun eigenaren en is openhartig over of het programma waarde toevoegt aan de grenzen of het werk dupliceert van de projecten die het zou moeten mogelijk maken.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een ICS besluit een gedeeld zorgdossier te leveren dat clinici in de acute zorg, gemeenschapszorg, ggz, eerste lijn en sociale zorg één samenhangend beeld van een persoon geeft. Geen enkel project kan dit leveren: het omspant meerdere ziekenhuizen, verscheidene bronsystemen, overeenkomsten over informatiebeheer, herontwerp van klinische werkstromen en publieksbetrokkenheid. Het wordt gecoördineerd als een MSP-programma.

De SRO — een bestuurder van het ICS met echt gezag over het hele stelsel — zit een programmabestuur voor met vertegenwoordigers van elke partnerorganisatie en benoemde business change managers in elk. Het programma stelt een visie vast (“de juiste informatie, over de juiste persoon, beschikbaar voor de juiste clinicus, op het zorgmoment”) en een blauwdruk die het doeloperatiemodel beschrijft: de architectuur en normen voor datadeling (interoperabiliteit op basis van HL7 FHIR), het kader voor informatiebeheer, het toestemmingsmodel en de herontworpen klinische werkstromen.

Het werk is georganiseerd in tranches. Tranche één verbindt twee gewillige algemene ziekenhuizen en levert een alleen-lezen dossier, een bewuste snelle winst die de aanpak bewijst en het bestuur in staat stelt een vroege baat aan te tonen — een meetbare vermindering van dubbele onderzoeken — om vertrouwen op te bouwen. Bij de toetsing van tranche één leert het bestuur dat adoptie door clinici achterblijft waar het dossier achter een extra login is verstopt, dus het stuurt de blauwdruk bij om integratie met single sign-on voorrang te geven vóór verbreding van de uitrol.

Onder het programma bestaan de werkwijzen naast elkaar. Het platform voor interoperabiliteit wordt gerund door een duurzaam productteam (Onderwerp 5.0) dat het gedurende het hele programma en daarna blijft verbeteren. De aansluiting van elk ziekenhuis is een afgebakend project (Onderwerp 5.1) met een eigen businesscase en go-live. Het programma zelf coördineert de blauwdruk, de normen, de onderlinge afhankelijkheden en — via de BCM’s — de batenrealisatie. Wanneer de blauwdruk is bereikt en de baten van minder dubbele onderzoeken en minder vertraagde ontslagen stromen, sluit het programma; het productteam van het platform blijft bestaan en het volgen van baten gaat door in de reguliere bedrijfsvoering.

Sectorperspectieven#

Startup#

Weinig startups runnen programma’s in de zin van MSP — zij missen de reikwijdte over meerdere organisaties die er een definieert — maar een scale-up die over verscheidene ziekenhuizen uitrolt wordt in feite een deelnemer aan een programma. Zijn realistische rol is die van leverancier binnen het programma van een ander: zijn product afstemmen op de blauwdruk van het programma, tranchemijlpalen halen en de batencase voeden die de SRO moet onderbouwen. Financiering en overleven hangen af van het voortbestaan van het programma, dus de startup behandelt toetsingen van tranches als existentiële go/no-go-momenten en investeert in het succes van de business change managers, omdat adoptie op de werkvloer is wat zijn contract vernieuwt. De discipline die het moet lenen is de taal van baten — zijn waarde framen als gerealiseerde uitkomsten en niet als opgeleverde functies.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of een kleine leverancier van health-tech voorbij de startupfase — runt vrijwel nooit een programma, maar wordt routinematig meegesleurd als betrokken deelnemer wanneer een ICS een gedeeld zorgdossier uitrolt of systemen over het gebied laat convergeren. Zijn praktische zorg is de naad die het programma bezit: het moet de verplichte datastandaarden, overeenkomsten voor informatiebeheer en het toestemmingsmodel overnemen met dunne of geen toegewijde IT-capaciteit en zonder speling om verandering van werkstroom op te vangen, en toch draagt het dezelfde wettelijke plichten als de grote ziekenhuizen om hem heen. De waardevolste relatie die het heeft is die met de business change manager van zijn gebied, want een goed ondersteunde adoptie — training, single sign-on, een werkstroom die past bij hoe de praktijk werkelijk draait — is het verschil tussen de baat van het programma die landt en de verandering die stilletjes wordt omzeild. Zijn realistische vraag aan het programma is evenredige ondersteuning en een volgorde die geen middelen op schaal van een grote onderneming veronderstelt, en zijn eerlijke bijdrage is vroege, openhartige terugkoppeling bij toetsingen van tranches over wat op de werkvloer onwerkbaar is.

Grote onderneming#

Een ICS of groot ziekenhuis is de natuurlijke thuishaven van programmagestuurd werk: gedeelde zorgdossiers, convergentie van EPD’s en transformatie van trajecten zijn inherent multi-organisatie en meerjarig. Het moeilijke deel is gezag — de SRO moet beslissingen laten standhouden over soevereine partnerorganisaties die niet eenvoudig kunnen worden bevolen, dus een werkelijk representatief programmabestuur en in elke partner ingebedde business change managers zijn dragend en niet decoratief. Financiering is gemengd (geld voor systeemtransformatie, kapitaal van het ziekenhuis, nationale toewijzingen), wat de batenkaart en toetsingen van tranches essentieel maakt om voortgezette investering te verdedigen tegenover leiders van het stelsel en toezichthouders. Het terugkerende risico op deze schaal is opbrengsttoneel: technische levering waarbij niemand verantwoordelijk is voor het omzetten ervan in baat.

Overheid#

Op nationale schaal dragen programma’s het zwaarste bestuur — zij komen doorgaans in de Government Major Projects Portfolio, ondergaan zekerheid en gatewayreviews van de Infrastructure and Projects Authority en leggen verantwoording af aan ministers, de Public Accounts Committee en de National Audit Office. De SRO is persoonlijk en publiek verantwoordelijk voor batenrealisatie over het hele stelsel, en blauwdrukken moeten nationale normen (interoperabiliteit, informatiebeheer, de NHS App als gemeenschappelijke voordeur) verzoenen met lokale autonomie. Financiering loopt via meerjarige begrotingsafspraken, dus tranches en bewijs van baten zijn het mechanisme om investering over begrotings- en politieke cycli te behouden of te stoppen. De inzet is op schaal van de bevolking: de baten van een nationaal programma — of zijn falen — worden gemeten in miljoenen patiënten en miljarden ponden.

Veelvoorkomende faalpatronen#

• Opbrengsttoneel. Het programma levert technische opbrengsten maar niemand bezit het omzetten ervan in baten, dus er verandert niets voor patiënten. Oplossing: batenkaarten met eigenaren, en BCM’s in de operationele organisatie.
• Een programma dat gewoon een groot project is. Bestuur met vaste reikwijdte en gericht op opbrengsten toegepast op werkelijk onzekere verandering over meerdere organisaties. Oplossing: beheer op uitkomsten/baten en tranches, niet op één bevroren plan.
• Een machteloze SRO. Verantwoording zonder gezag om over grenzen heen te beslissen. Oplossing: benoem een SRO die senior genoeg is om beslissingen over het hele stelsel te laten standhouden, gesteund door een representatief bestuur.
• Geen blauwdruk / doeltoestand. Projecten optimaliseren lokaal en de onderdelen komen nooit tot samenhang. Oplossing: definieer en onderhoud een POTI-blauwdruk waar alles naartoe wordt gestuurd.
• Big bang in plaats van tranches. Al het risico wordt uitgesteld naar één late levering. Oplossing: deel het werk in tranches op, boek vroege baten en herplan bij toetsmomenten.
• Programma dat nooit sluit. Het wordt een permanente bureaucratie lang nadat de verandering is ingebed. Oplossing: sluit bewust af, draag blijvende diensten over aan productteams en blijf baten volgen in de reguliere bedrijfsvoering.

Volwassenheidsmodel#

Checklist#

• Is dit werkelijk verandering over meerdere projecten en organisaties naar één strategische uitkomst?
• Is er een duidelijke visie en een concrete blauwdruk (doeloperatiemodel / POTI)?
• Is er een batenkaart die opbrengsten koppelt aan meetbare, bezeten baten met nulmeting?
• Is het werk gestructureerd in tranches met echte toetsmomenten voor doorgaan/bijsturen/stoppen?
• Is er een bevoegde SRO met gezag om over organisatiegrenzen heen te beslissen?
• Vertegenwoordigt het programmabestuur de betrokken organisaties werkelijk?
• Zijn business change managers ingebed in de operationele organisatie om adoptie te bezitten?
• Worden overkoepelende normen, onderlinge afhankelijkheden en gedeelde risico’s op programmaniveau beheerd?
• Bestaan productgestuurde, projectgestuurde en programmagestuurde werkwijzen naast elkaar met duidelijke rollen (Onderwerpen 5.0–10)?
• Is er een bewuste afsluiting, met blijvende diensten overgedragen aan duurzame productteams en baten gevolgd in de reguliere bedrijfsvoering?

Belangrijkste bronnen#

• AXELOS / PeopleCert — Managing Successful Programmes (MSP): beginselen, thema’s en de transformationele stroom (inclusief blauwdruk, tranches, batenmanagement en de rollen van SRO/BCM).
• Cabinet Office / Infrastructure and Projects Authority (IPA) — richtlijnen over grote programma’s, verantwoording van de SRO en zekerheid/gatewayreviews.
• HM Treasury — The Green Book en richtlijnen voor batenmanagement (beoordeling en evaluatie van baten).
• AXELOS — Management of Portfolios (MoP), om programma’s binnen een portfolio te positioneren (zie Onderwerp 5.3 — EPPM).
• NHS England — richtlijnen over integrated care systems en gedeelde zorgdossiers (interoperabiliteit, HL7 FHIR-normen) voor de context van het domein.
• Mik Kersten — Project to Product, voor de verschuiving van investering op basis van opbrengsten naar uitkomsten/baten.

Referenties#

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/