Onderwerp 5.1 — Projectgestuurd werken

In één zin: Projectgestuurd werken is het juiste instrument wanneer de klus een afgebakende reikwijdte, een eindig leven en een duidelijke eindtoestand heeft — een tijdelijke, beheerste onderneming die tegen afgesproken tijd, kosten en kwaliteit wordt geleverd en daarna wordt afgesloten.

Waarom dit ertoe doet in gezondheid en zorg#

Niet alles is een levende dienst. Een deel van het belangrijkste werk in gezondheid en zorg is werkelijk eindig: migreren van het ene elektronisch patiëntendossier naar het andere, wifi uitrollen over een ziekenhuisterrein, servers aan het einde van hun levensduur vervangen, een legacysysteem uitfaseren voordat een leverancierscontract afloopt of het digitale deel van een nieuwbouw ziekenhuis leveren. Dit werk heeft een begin, een midden en een duidelijk einde. Het als open product beheren zou geld verspillen en verantwoording vertroebelen; het heeft de discipline van een project nodig.

Projectmanagement verdient zijn plek hier juist omdat de inzet hoog is en de beperkingen hard. Een cutover van een datamigratie heeft een vast go-live-weekend, een risico voor patiëntveiligheid als dossiers verloren gaan of beschadigd raken en een contractuele afgrond als het oude systeem uitgaat. Publiek geld is vastgelegd tegen een businesscase, en het Parlement, accountants en besturen zullen vragen of het is besteed zoals goedgekeurd. Projectgestuurd werken biedt het bestuur — een businesscase, beslispoorten en een beheerste afsluiting — waarmee een bestuur met vertrouwen kapitaal kan toezeggen en het werk netjes kan stoppen als de rechtvaardiging vervalt.

Het gevaar is dit instrument voor de verkeerde klus te gebruiken. Projectbestuur toegepast op een zich ontwikkelende digitale dienst produceert de pathologie van “bouwen en verlaten” beschreven in Onderwerp 5.0 — Productgestuurd werken. Dit onderwerp legt uit waar projectgestuurd werk het juiste instrument is en waar zijn grenzen beginnen. Het staat naast Onderwerp 5.2 — Programmagestuurd werken, dat meerdere projecten coördineert, en Onderwerp 5.3 — Enterprise-projectportfoliomanagement (EPPM), dat tussen deze instrumenten kiest.

Kernbegrippen#

Project. Een tijdelijke organisatie opgericht om een of meer gedefinieerde opbrengsten te leveren volgens een afgesproken specificatie, binnen beperkingen van tijd, kosten en kwaliteit. Het bepalende kenmerk is dat het tijdelijk is — het bestaat om een gedefinieerd einde te bereiken en dan uiteen te gaan.

De ijzeren driehoek (reikwijdte, tijd, kosten). Het klassieke model van beperkingen: reikwijdte, planning en budget zijn onderling afhankelijk, en kwaliteit wordt beïnvloed door hoe ze in balans worden gebracht. Verander het ene en u verandert de andere; projectbeheersing is grotendeels de discipline om deze afweging transparant te beheren.

PRINCE2 (PRojects IN Controlled Environments). De gestructureerde projectmethode van de Britse overheid, breed gebruikt in de NHS en de publieke sector. Zij is gebouwd op beginselen (voortdurende zakelijke rechtvaardiging, gedefinieerde rollen, beheer per fase, beheer bij uitzondering, focus op producten, leren van ervaring, aanpassen aan de omgeving) en ordent werk in beheerste fasen waarbij een projectbestuur richting geeft.

PMI / PMBOK. De Guide to the Project Management Body of Knowledge van het Project Management Institute is de overheersende internationale tegenhanger, die projectwerk kadert rond prestatiedomeinen en beginselen in plaats van een voorgeschreven gefaseerd proces. PRINCE2 en PMBOK zijn complementaire lenzen op dezelfde discipline.

Businesscase. Het document dat het project rechtvaardigt: het probleem, de beoordeelde opties, de verwachte baten, de kosten en de risico’s. In PRINCE2 is de businesscase levend — zij wordt bij elke fasegrens getoetst, en als de voortdurende rechtvaardiging verdwijnt, is de juiste beslissing te stoppen. In Britse publieke organen is zij gewoonlijk gestructureerd als het Five Case Model van HM Treasury (strategisch, economisch, commercieel, financieel, management).

Beslispoorten (stage gates). Een PRINCE2-project is verdeeld in managementfasen gescheiden door beslispoorten. Bij elke grens neemt het projectbestuur een bewuste stop-/doorgaanbeslissing: het toetst de voortgang en de businesscase, keurt het plan voor de volgende fase goed en legt middelen alleen voor die fase vast. Zo houdt een bestuur de controle en voorkomt het goed geld achter slecht geld aan te gooien.

RAID-logboek. Eén enkel register van Risico’s, Aannames, Issues en Afhankelijkheden (Dependencies) — het kerninstrument van beheersing van de projectmanager. RAID maakt onzekerheid zichtbaar en beheersbaar: risico’s zijn dingen die kunnen gebeuren, issues zijn dingen die zijn gebeurd, aannames zijn waar het plan op leunt en afhankelijkheden zijn wat het plan elders nodig heeft.

Beste praktijken#

1. Begin met een eerlijke businesscase en houd haar levend. Gebruik een erkende structuur (het Five Case Model in Britse publieke organen) om echte opties te beoordelen, niet één vooraf bepaald antwoord. Behandel de businesscase daarna als een levend document dat bij elke beslispoort wordt getoetst — voortdurende zakelijke rechtvaardiging is het eerste beginsel van PRINCE2, en haar verliezen is een legitieme reden om te stoppen.

2. Definieer de reikwijdte nauwkeurig en beheers wijzigingen erin. De waarde van een project is een duidelijke, afgebakende definitie van “klaar”. Spreek de reikwijdte af, leg haar vast als nulmeting en leid elke voorgestelde wijziging door een proces van wijzigingsbeheer zodat scope creep niet stilletjes het budget en de planning opeet.

3. Beheer per fase met echte beslispoorten. Breek het werk op in managementfasen en houd bij elke grens een echte stop-/doorgaantoets. Een poort die altijd “doorgaan” zegt is toneel; de discipline werkt alleen als stoppen of herplannen een echte optie is die het bestuur zal gebruiken.

4. Run een levend RAID-logboek en escaleer bij uitzondering. Houd Risico’s, Aannames, Issues en Afhankelijkheden op één plek bij, toets ze regelmatig en gebruik het “beheer bij uitzondering” van PRINCE2 — de projectmanager werkt binnen afgesproken toleranties en escaleert alleen naar het bestuur wanneer een tolerantie wordt bedreigd. Zo blijft senior tijd gericht op echte beslissingen.

5. Wijs duidelijke verantwoordelijkheid bij één punt toe. PRINCE2 staat erop dat rollen worden gedefinieerd: een projectbestuur met een senior verantwoordelijke/executive die de businesscase bezit, een senior gebruiker die degenen vertegenwoordigt die de opbrengst zullen gebruiken en een senior leverancier. Dubbelzinnige verantwoording is de meest voorkomende oorzaak van drift.

6. Plan de overgang naar live dienst voordat u begint. Een project levert een opbrengst; iemand moet haar daarna exploiteren. Spreek het ontvangende team, het ondersteuningsmodel en de overdracht van klinische veiligheid (DCB0160 voor inzet) af als onderdeel van het project, zodat go-live geen afgrond is in een vacuüm van eigenaarschap.

7. Bouw klinische veiligheid, informatiebeheer en testen erin. Voor elk systeem dat patiëntdata raakt zijn het klinisch veiligheidsdossier, de DPIA en het testen van cutover en terugdraaien (rollback) geen optionele extra’s — het zijn poortdeliverables. Een migratie zonder een geteste rollback is niet klaar voor go-live.

8. Sluit het project bewust af en leg lessen vast. Een gedefinieerd einde betekent een gedefinieerde afsluiting: bevestig dat de opbrengsten zijn geaccepteerd, draag over aan operatie, laat het team vrij en leg geleerde lessen vast (het lessenlogboek van PRINCE2). Een niet-afgesloten project lekt onbepaald middelen en verantwoording.

Vragen om met uw team te bespreken#

1. Is het werk voor ons werkelijk eindig met een gedefinieerde eindtoestand, of grijpen wij naar projectbestuur omdat het de financieringsroute is die wij kennen? Dit is de beslissende vraag waar het onderwerp om draait, want projectgestuurde discipline is alleen het juiste instrument wanneer de klus werkelijk een begin, een midden en een duidelijk einde heeft. In een organisatie in gezondheid en zorg is de trek naar projectvorm sterk — kapitaalbegroting, het apparaat van businesscases en rapportage aan het bestuur zijn er allemaal op gebouwd — dus een zich ontwikkelende digitale dienst kan als project worden aangekleed louter omdat zo geld vrijkomt, wat dan de pathologie van bouwen-en-verlaten produceert. Het debat moet elke kandidaat eerlijk onderzoeken: een vervanging van het pathologiesysteem voordat een leverancier ondersteuning intrekt heeft een harde contractuele afgrond en is ondubbelzinnig eindig, terwijl “verbeter de app voor patiënten” geen eindtoestand heeft en thuishoort in Onderwerp 5.0. Overweeg of er een echte go-live is waarna het team uiteen moet gaan, of dat iemand het ding onbepaald zal moeten blijven verbeteren. Een goed antwoord weerstaat projectbestuur als gewoonte, noemt de concrete eindtoestand en de gebeurtenis die “klaar” definieert en is bereid te zeggen dat sommige dingen die wij nu als project runnen nooit een project hadden mogen zijn.

2. Zou dit bestuur bij onze beslispoorten werkelijk een project stoppen of herplannen dat zijn rechtvaardiging heeft verloren — en kunnen wij wijzen op een keer dat wij het deden? Beslispoorten zijn alleen een beheersmaatregel als stoppen een echte optie is die het bestuur zal gebruiken; een poort die altijd “doorgaan” zegt is toneel, en voortdurende zakelijke rechtvaardiging is het eerste beginsel van PRINCE2 juist omdat haar verlies het werk moet beëindigen. De spanning in gezondheid en zorg is acuut: een half gebouwde EPD-migratie of een cutover van een laboratoriumsysteem stoppen voelt als falen toegeven, gezonken kosten verspillen en clinici verstoren die hun plannen al hebben aangepast, dus besturen rationaliseren doorgaan terwijl de businesscase stilletjes verdampt. Breng een echt voorbeeld in de discussie — een project waar testen onthulde dat het risico van datamapping erger was dan aangenomen, of waar baten wegglipten — en vraag of de poort werd gebruikt zoals ontworpen of werd afgestempeld. Overweeg welke toleranties escalatie triggeren, wie in het bestuur het gezag heeft een stop te bevelen en of redeneringen over gezonken kosten in de kamer worden benoemd en bevraagd. Een eerlijk antwoord geeft toe waar poorten formaliteiten waren, beschrijft de voorwaarden waaronder het bestuur werkelijk zou stoppen of de reikwijdte verkleinen en behandelt het gezag om te stoppen vóór een publieke afschrijving als de echte waarde van de discipline en niet als bedreiging.

3. Wie ontvangt de opbrengst van elk project als live dienst, en hoe maken wij overdracht van klinische veiligheid en doorlopend eigenaarschap tot een poortdeliverable in plaats van een afgrond? Een project levert een opbrengst; iets eindigs eindigt, maar wat het voortbracht moet lang nadat het team uiteen is gegaan worden geëxploiteerd, verbeterd en veilig gehouden — en het meest voorkomende stille falen is dat niemand het aan de andere kant bezit. In een systeem dat patiëntdata raakt is dit geen administratieve netheid: het veiligheidsdossier voor inzet onder DCB0160, de DPIA, een geteste rollback en een benoemd ontvangend team staan tussen een beheerste go-live en een vacuüm van eigenaarschap waar veiligheidsrisico’s onbeheerd oplopen. Het debat moet duidelijkheid afdwingen over de overgang vóór het project begint, niet op het go-live-weekend: welk operationeel team neemt het over, wat is het ondersteuningsmodel en heeft dat team de capaciteit en werkwijze (productgestuurd, volgens Onderwerp 5.0) om het te blijven verbeteren? Overweeg concrete recente go-lives en of de overdracht gepland of geïmproviseerd was en of “het project is af” mocht betekenen “en nu is het niemands taak”. Een goed antwoord noemt het ontvangende team en het ondersteuningsmodel vooraf, behandelt de overdracht van veiligheid als een poort waar het project niet zonder doorheen kan en wijst de doorlopende verbetering van de live dienst uitdrukkelijk toe aan de juiste werkwijze in plaats van haar te laten afdrijven.

4. Wanneer de ijzeren driehoek knelt en reikwijdte, tijd en kosten botsen, welke beperking laten wij dan meebuigen — en mag patiëntveiligheid ooit de variabele zijn die zwicht? Elk echt project bereikt uiteindelijk het moment waarop planning, budget en beloofde reikwijdte niet alle drie kunnen standhouden, en hoe het team die knelling oplost onthult wat het werkelijk waardeert. In gezondheid en zorg is de valkuil bijzonder: omdat de einddatum vaak een harde contractuele afgrond is — een leverancier die ondersteuning intrekt, een aflopende huur, een sluitend datacentrum — kan tijd vaak niet bewegen, dus de druk valt stilletjes op kwaliteit, wat in een klinisch systeem betekent testen schrappen, validatie samenpersen of opleveren met bekende gebreken in datamapping. De discussie moet vooraf benoemen welke hoek van de driehoek de organisatie zal beschermen en welke zij zal opofferen, en expliciet zijn dat klinische veiligheid en informatiebeheer niet het overdrukventiel zijn, ook wanneer al het andere vaststaat. Kijk naar een recente cutover en vraag wat stilletjes zwichtte toen de data standhielden: was het de repetitie van de rollback, het venster voor klinische validatie, de training? Overweeg wie het gezag heeft de go-live-datum te verschuiven in plaats van de veiligheidsmarge uit te hollen en of dat gesprek openlijk in het bestuur gebeurt of standaard op de werkvloer. Een eerlijk antwoord stelt de prioriteitsvolgorde vóór de crunch vast, behandelt een verschoven datum of een herplande fase als een legitieme uitkomst en weigert onuitgesproken planningsdruk om te laten zetten in ongelogd klinisch risico.

5. Is ons RAID-logboek een levend instrument dat verandert wat wij doen, of een document dat wij bijhouden om bestuurd te lijken — en zou het het risico aan het licht brengen dat het project werkelijk laat zinken? Een RAID-logboek verdient zijn plek alleen als het toetsen ervan beslissingen verandert; de gebruikelijke pathologie is een register dat bij de start is geschreven, aan besturen gepresenteerd en nooit werkelijk gebruikt terwijl de risico’s die ertoe doen onbewaakt rijpen. Bij een migratie of cutover zijn de beslissende risico’s vaak specifiek en kenbaar — historische uitslagen die niet schoon op nieuwe referentiebereiken zullen mappen, een afhankelijkheid van wijzigingen in de firewall van een ander team, een aanname dat middelen voor klinische validatie vrij zijn wanneer ze nodig zijn — en de vraag is of het logboek die concreet noemt of zich verschuilt achter generieke posten als “beperkte middelen”. Het debat moet toetsen of escalatie bij uitzondering echt is: werkt de projectmanager binnen afgesproken toleranties en vraagt hij de aandacht van het bestuur alleen wanneer er een wordt bedreigd, of blijft alles stil of wordt het een crisis? Overweeg of bijna-ongevallen en werkelijk opgetreden issues terugvloeien in hoe de volgende fase wordt gepland, of simpelweg worden gelogd en vergeten. Een goed antwoord kan wijzen op een beslissing die het RAID-logboek werkelijk veranderde, onderscheidt de twee of drie risico’s die het project werkelijk kunnen stoppen van de lange staart van kleine en behandelt het logboek als werkende beheersmaatregel en niet als artefact geproduceerd voor zekerheid.

6. Controleert iemand nadat wij zijn afgesloten en uiteen zijn gegaan of de baten uit de businesscase werkelijk zijn gerealiseerd — en zouden wij het weten als dat niet zo was? De businesscase belooft baten om de uitgave te rechtvaardigen, maar projectgestuurd werk eindigt van nature bij go-live en vrijlating van het team, dus het moment van de waarheid — verminderde de migratie werkelijk risico, sneed zij kosten of verbeterde zij zorg — valt gewoonlijk nadat iedereen is doorgegaan en niemand verantwoordelijk is voor de bevestiging. Dit doet er acuut toe in publieke gezondheid en zorg, waar geld is vastgelegd tegen een businesscase volgens het Five Case Model waarvan het Parlement, accountants en besturen is verteld dat zij specifieke uitkomsten zou opleveren, terwijl batenrealisatie de stap is die het vaakst wordt overgeslagen omdat het project dat haar zou hebben bezeten niet meer bestaat. De discussie moet beslissen wie het volgen van baten erft wanneer het project sluit, over welke periode en tegen welke nulmetingen — die vóór go-live moeten worden vastgelegd of verloren gaan. Overweeg een recent afgerond project en vraag ronduit of iemand sindsdien de beloofde baten heeft gecontroleerd en of een tekort ooit het bestuur zou bereiken dat het goedkeurde. Een eerlijk antwoord wijst eigenaarschap van baten na afsluiting toe aan een vaste functie en niet aan het ontbonden team, legt de nulmeting vast terwijl het project nog live is en is bereid vast te leggen dat een project zijn opbrengst op tijd en binnen budget leverde maar niet de waarde die het rechtvaardigde.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een algemeen ziekenhuis moet zijn verouderde laboratoriuminformatiesysteem voor pathologie vervangen voordat de zittende leverancier over 14 maanden de ondersteuning intrekt. Dit is een schoolvoorbeeld van projectgestuurd werk: vaste einddatum, gedefinieerde reikwijdte, een harde contractuele afgrond en acuut risico voor patiëntveiligheid als uitslagen bij de migratie verloren gaan.

Het ziekenhuis schrijft een businesscase volgens het Five Case Model die drie opties beoordeelt (opwaarderen ter plekke, een nieuw systeem aanbesteden, een regionale instantie delen), kiest voor aanbesteding en zet een PRINCE2-project op met een duidelijk bestuur: een executive die de businesscase bezit, een senior gebruiker (de leidende biomedisch analist) en de senior leverancier. Het werk wordt verdeeld in managementfasen — aanbesteding, bouw en configuratie, datamigratie, testen en go-live — elk eindigend in een beslispoort.

De projectmanager voert een RAID-logboek. Een belangrijk risico is dat historische uitslagen mogelijk niet schoon op de referentiebereiken van het nieuwe systeem mappen; een afhankelijkheid zijn de wijzigingen in de firewall van het netwerkteam; een aanname is dat middelen voor klinische validatie beschikbaar zullen zijn voor het testen. Bij de beslispoort van de migratie onthult testen dat het risico van datamapping erger is dan aangenomen, dus het bestuur gebruikt de poort zoals ontworpen: het gaat niet blind door maar keurt een herplande fase goed met een verlengd validatievenster en een geteste rollback, en beschermt patiëntveiligheid boven de oorspronkelijke planning.

Go-live gebeurt over een beheerst weekend met het rollbackplan paraat en een goedkeuring van klinische veiligheid onder DCB0160. Het systeem wordt geaccepteerd, overgedragen aan het team van operatie dat het zal runnen, lessen worden gelogd en het project wordt formeel afgesloten. Het team gaat uiteen — terecht, omdat de klus werkelijk af is. Wat daarna komt (voortdurende verbetering van de live dienst) is een andere werkwijze, en het ziekenhuis let erop geen volledig projectteam eeuwig te laten doorlopen om het te doen.

Sectorperspectieven#

Startup#

Een klein bedrijf in digitale gezondheid draait zelden formele PRINCE2-projecten, maar werkelijk eindig werk komt wel voor — een eenmalige datamigratie naar een nieuw cloudplatform, een certificeringsinspanning voor Cyber Essentials of DTAC, herstel na een pentest vóór een groot NHS-contract. De startup behandelt deze als lichte, tijdgebonden inspanningen met een benoemde eigenaar en een duidelijke definitie van klaar, en leent de discipline (vaste reikwijdte, een einddatum, een go/no-go) zonder de ceremonie (geen formeel projectbestuur, geen poorten in vijf fasen). Financiering is in feite aandacht van oprichters en looptijd, dus het risico is dat eindig werk tussen productsprints wordt geperst en nooit werkelijk wordt afgesloten. Het tegengif is een enkele eigenaar en een harde deadline te noemen en de certificering of migratie als afgedaan te behandelen en niet als eeuwig “in uitvoering”.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of een kliniek met één vestiging — ontmoet projectgestuurd werk als incidentele maar onvermijdelijke gebeurtenissen: van leverancier van klinisch systeem wisselen, migreren naar een nieuw praktijkbeheerplatform of apparaten aan het einde van hun levensduur vervangen voordat de ondersteuning vervalt. De organisatie heeft echte patiënten en lopende operaties maar geen toegewijde project- of IT-functie, dus het “projectteam” is gewoonlijk de praktijkmanager of een geregistreerde manager die dit naast de dagelijkse taak doet, vaak leunend op de binnenkomende leverancier om de migratie uit te voeren. De discipline die het contact met deze werkelijkheid overleeft is de lichte kern: een duidelijke eindtoestand, een als nulmeting vastgelegde reikwijdte zodat de leverancier die niet stilletjes uitbreidt, een benoemde verantwoordelijke en een geteste rollback vóór elke cutover die patiëntdossiers raakt. De valkuil is niet alleen het werk maar ook het oordeel uitbesteden — de go-live-datum en de toezeggingen over datamapping van de leverancier aanvaarden zonder onafhankelijke controle — want dezelfde plichten voor klinische veiligheid en informatiebeheer (DCB0160, een DPIA) gelden ongeacht hoe klein de organisatie is. Het tegengif is het eigenaarschap van de go/no-go-beslissing en de acceptatiecriteria intern te houden, ook wanneer elk ander paar handen van de leverancier is.

Grote onderneming#

Een groot NHS-ziekenhuis of integrated care system (ICS) is waar projectgestuurd werk het meest thuis is: vervangingen van EPD’s, wifi over het hele terrein, het verlaten van datacentra en cutovers dragen allemaal harde contractuele en patiëntveiligheidsafgronden. Hier is het volledige apparaat gerechtvaardigd — een businesscase volgens het Five Case Model, een PRINCE2-bestuur met een benoemde executive/SRO, senior gebruiker en senior leverancier, managementfasen met echte poorten en een levend RAID-logboek — omdat de bedragen groot zijn, de veiligheidsblootstelling acuut is en interne audit en het bestuur de uitgave zullen toetsen. Het kenmerkende falen op deze schaal is hetzelfde bestuur zonder onderscheid toepassen op levende diensten (Onderwerp 5.0 — Productgestuurd werken) en op eindig werk, dus een portfolioblik (Onderwerp 5.3 — Enterprise-projectportfoliomanagement (EPPM)) dat elk werk naar de juiste werkwijze leidt doet ertoe. Klinische veiligheid (DCB0160) en een geteste rollback zijn poortdeliverables, geen optionele extra’s.

Overheid#

Op nationale of grootprojectschaal zit projectgestuurd werk binnen het regime van zekerheid van de overheid: de Infrastructure and Projects Authority voert gatewayreviews uit, de Green Book en het Five Case Model van HM Treasury besturen de businesscase en de grootste projecten komen in de Government Major Projects Portfolio met gepubliceerde verantwoording aan het Parlement en de National Audit Office. Verantwoording is intens publiek — de senior verantwoordelijke is persoonlijk aansprakelijk en kan voor een select committee worden geroepen — dus beslispoorten en optiebeoordelingen zijn beheersing van wettelijke kwaliteit, geen toneel. Financiering komt tranche voor tranche vrij tegen goedgekeurde businesscases en de risicobereidheid is laag, omdat falen voorpaginanieuws wordt. De echte waarde van de discipline is hier het gezag om een falend project te stoppen of de reikwijdte te verkleinen voordat het een publieke afschrijving wordt.

Veelvoorkomende faalpatronen#

• Een zich ontwikkelende dienst projectmatig managen. Bestuur met vaste reikwijdte en ontbinding aan het einde toepassen op een levend digitaal product produceert de pathologie van verlating. Oplossing: gebruik productgestuurd werk (Onderwerp 5.0) waar de dienst doorloopt.
• De businesscase als eenmalig toegangskaartje voor financiering. Eenmaal geschreven om geld vrij te maken en daarna nooit herzien. Oplossing: toets haar bij elke beslispoort; wees bereid te stoppen.
• Beslispoorten die afgestempeld worden. Poorten die nooit “stop” zeggen bieden geen controle. Oplossing: maak stoppen of herplannen een echte optie van het bestuur en gebruik haar.
• Scope creep zonder wijzigingsbeheer. Ongecontroleerde toevoegingen blazen tijd en kosten op. Oplossing: leg de reikwijdte vast als nulmeting en leid elke wijziging door wijzigingsbeheer.
• Geen plan voor overgang naar dienst. Het project eindigt en niemand bezit de opbrengst. Oplossing: spreek het ontvangende team en het ondersteuningsmodel af vóór go-live.
• RAID als archiefkast. Een logboek dat wordt geschreven en nooit gebruikt. Oplossing: toets RAID regelmatig en escaleer bij uitzondering.
• Nooit werkelijk afsluiten. Zombieprojecten die middelen verbruiken zonder einde. Oplossing: een bewuste afsluiting met acceptatie, overdracht en vastgelegde lessen.

Volwassenheidsmodel#

Checklist#

• Is het werk werkelijk eindig met een gedefinieerde reikwijdte en eindtoestand (geen doorlopende dienst)?
• Is er een levende businesscase (Five Case Model) die bij elke beslispoort wordt getoetst?
• Is de reikwijdte als nulmeting vastgelegd, met een werkend proces van wijzigingsbeheer?
• Zijn de werkfasen gedefinieerd, elk eindigend in een echte stop-/doorgaanpoort?
• Zijn de rollen in het projectbestuur duidelijk — executive/SRO, senior gebruiker, senior leverancier?
• Wordt een levend RAID-logboek bijgehouden, met escalatie bij uitzondering?
• Zijn klinische veiligheid (DCB0160), DPIA en testen van cutover/rollback poortdeliverables?
• Zijn het ontvangende operationele team en het ondersteuningsmodel afgesproken vóór go-live?
• Is er een bewuste afsluiting: acceptatie, overdracht, vrijlating van het team, lessen gelogd?
• Is de doorlopende verbetering van de live dienst toegewezen aan de juiste werkwijze?

Belangrijkste bronnen#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (7e editie) en de beginselen, thema’s en processen van PRINCE2.
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) en The Standard for Project Management.
• HM Treasury — Guide to Developing the Project Business Case (het Five Case Model / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — richtlijnen voor zekerheid en gatewayreviews voor grote projecten.
• Norm voor klinische veiligheid van NHS Digital, DCB0160 (inzet van IT-systemen in de gezondheidszorg).
• NHS England — NHS Service Manual en Digital Service Standard (voor de context van overgang naar dienst en gebruikersbehoefte).

Referenties#

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