QA bij Projecten en Programma's

Een strategisch perspectief voor internal auditors, bestuurders en directie

Maart 2026

Management Summary

QA door Internal Audit werkt het beste in vier fasen: businesscase-toets vóór aanvang, governance- en plancheck bij de start, scope- en risicomonitoring tijdens de uitvoering, en benefits-evaluatie bij afsluiting. Die fasering is geen administratieve verplichting. Het is het verschil tussen tijdig ingrijpen en schade beperken achteraf.

De cijfers maken de urgentie zichtbaar. Slechts 31% van alle projecten wordt afgerond binnen tijd, budget en scope.¹⁶ IT-projecten gaan gemiddeld 73% over budget, infrastructurele megaprojecten 28%.¹ De geschatte jaarlijkse verspilling wereldwijd bedraagt circa 2 biljoen dollar. Dat zijn geen toevalligheden. Het zijn patronen met bekende oorzaken.

De drie hardnekkigste valkuilen zijn optimisme-bias bij budgettering, de sunk cost fallacy die doorgang rechtvaardigt bij falende trajecten, en groupthink in stuurgroepen die kritische signalen dempt. Elk van deze mechanismen is herkenbaar, en elk ervan is te onderkennen als Internal Audit vroeg genoeg aansluit.

Audit hoeft de strategie niet te beoordelen, wél of het besluitvormingsproces deugde. Het bewaakt de onafhankelijkheid en richt de aandacht op wat beïnvloedbaar is.

Deze whitepaper richt zich op drie doelgroepen: internal auditors die QA willen inrichten of professionaliseren, bestuurders en directie die meer grip willen op hun project- en programmaportfolio, en projectprofessionals die willen begrijpen hoe onafhankelijke QA hun werk versterkt.

1. Inleiding

1.1 Aanleiding en relevantie

Grote organisaties besteden 10 tot 30% van hun operationele budget aan projecten en programma's. Veel geld. En toch mislukt het grootste deel.

De slaagkans van projecten en programma's is al decennia zorgwekkend, ondanks deze forse investeringen. Slechts 31% van alle projecten wordt succesvol afgerond binnen tijd, budget en scope. Wereldwijd faalt naar schatting 70% van alle projecten in enige mate. De geschatte jaarlijkse verspilling: meer dan 2 biljoen euro.¹⁶

De oorzaken zijn divers en goed gedocumenteerd. Kahneman en Tversky beschreven hoe optimisme-bias leidt tot systematische onderschatting van kosten en doorlooptijden.² Arkes en Blumer (1985) toonden aan dat de sunk cost fallacy organisaties ertoe brengt om te blijven investeren in falende projecten.⁵ Janis (1972) liet zien dat groupthink kritische geluiden in stuurgroepen smoort.⁴

De Nederlandse context voegt aan dit internationale beeld een eigen laag van governance en toezicht toe. De Corporate Governance Code, herzien in 2022, verankert dat het bestuur verantwoordelijk is voor adequate risicobeheersing en interne controle.²⁰ Met de introductie van de Verklaring omtrent Risicobeheersing (VOR), die per boekjaar 2025 geldt voor beursgenoteerde ondernemingen, moet het bestuur expliciet verklaren dat de interne risicobeheersingssystemen naar behoren functioneren. Voor grote projecten en programma's betekent dit dat projectrisico's niet langer buiten de bestuurlijke verantwoording kunnen vallen. De VOR dwingt bestuurders om projectgovernance te behandelen als onderdeel van hun formele risicorapportage, niet als operationeel detail.

Op rijksniveau functioneert het Adviescollege ICT-toetsing (AcICT) als onafhankelijk toezichtmechanisme op grote overheids-ICT-projecten. Het AcICT, wettelijk verankerd per 1 juli 2024 als opvolger van Bureau ICT-toetsing (BIT), toetst ICT-projecten boven de vijf miljoen euro op haalbaarheid, risico's en slaagkans.²³ De adviezen zijn openbaar en worden aan de Tweede Kamer gestuurd. De Algemene Rekenkamer constateert in haar structurele rapportages over digitalisering bij het Rijk een terugkerend patroon: ambities worden onvoldoende afgewogen tegen beschikbare capaciteit, ICT-projecten kosten meer en duren langer dan begroot, en de informatievoorziening aan het parlement is incompleet.⁶

Voor de financiële sector creëert de Digital Operational Resilience Act (DORA), per 17 januari 2025 van kracht, een aanvullend governance-kader. DORA verplicht banken, verzekeraars en andere financiële instellingen om digitale operationele weerbaarheid te borgen, inclusief ICT-risicomanagement, incidentrapportage en toezicht op derde partijen. DNB en AFM zien toe op naleving. Elk IT-verandertraject bij een financiële instelling moet aantoonbaar voldoen aan DORA-vereisten rond weerbaarheid en continuïteit. Projecten die nieuwe systemen introduceren of bestaande migreren, vallen onder verscherpt toezicht op operationele risico's.

De CGC, het AcICT, de Algemene Rekenkamer en DORA vormen samen een toezichtlandschap waarin projectfalen geen geïsoleerd operationeel probleem meer is. Het is een governance-kwestie geworden. Bestuurders worden persoonlijk aangesproken op de kwaliteit van hun projectbeheersing, of het nu gaat om een digitale transformatie bij een beursgenoteerde onderneming, een rijksbrede ICT-voorziening of een systeemmigratie bij een bank.

1.2 Probleemstelling

De meeste organisaties missen een systematisch mechanisme voor onafhankelijke kwaliteitstoetsing van projecten en programma's. Internal Audit vult die leemte. Vanuit de derde lijn, met een mandaat voor onafhankelijke en objectieve toetsing, is Internal Audit de ogen en oren van het bestuur bij complexe veranderinitiatieven.

1.3 Doelstelling en leeswijzer

Deze whitepaper biedt een integraal referentiekader voor QA door Internal Audit bij projecten en programma's. De structuur volgt twaalf hoofdstukken: het conceptueel kader (H2), de GIAS (H3), governance en risicomanagement (H4), de rol van Internal Audit (H5), structurele faalpatronen (H6), methodieken en raamwerken (H7), Agile en QA (H8), handvatten voor auditors (H9), handvatten voor bestuurders en directie (H10), casussen (H11), en conclusies en aanbevelingen (H12).

2. Conceptueel Kader: QA versus QC

2.1 Wat is Quality Assurance?

Quality Assurance in de context van projecten en programma's is de systematische, onafhankelijke beoordeling van processen, governance-arrangementen en risicobeheersing die het succes van een veranderinitiatief bepalen. Het doel is niet de technische kwaliteit van deliverables toetsen (dat is Quality Control), maar beoordelen of de juiste condities aanwezig zijn voor een succesvol project of programma.

QA draait om het DIRFT-principe: Do It Right the First Time. Deliverables zijn vanaf het begin foutloos. Fouten corrigeren kost altijd meer dan fouten voorkomen.

2.2 QA versus QC: fundamenteel onderscheid

Dimensie	Quality Assurance (QA)	Quality Control (QC)
Aanpak	Proactief, preventiegericht	Reactief, gericht op detectie
Timing	Gedurende het hele proces	Aan het einde, of bij checkpoints
Focus	Procesgericht	Productgericht
Betrokkenheid	Organisatiebreed	Vast team of vaste afdeling
Doel	Defecten voorkomen	Defecten opsporen en verhelpen
Kostenimpact	Hogere investering vooraf, lagere kosten op termijn	Lagere investering vooraf, mogelijk hogere kosten op termijn
Verantwoordelijkheid	Internal Audit / onafhankelijke QA-functie	Projectteam / testteam

2.3 Projecten versus programma's

Aspect	Project-QA	Programma-QA
Primaire focus	Levering binnen kaders (tijd, geld, kwaliteit)	Realisatie van strategische benefits
Governance	Stuurgroep, projectmanager, opdrachtgever	Programme board, SRO, business change managers
Risico-accent	Scope creep, planningsrisico, technisch risico	Niet-gerealiseerde benefits, strategische drift, complexe afhankelijkheden
Businesscase	Eenmalige beoordeling, periodieke review	Continu herijken tegen strategische doelen
Stakeholders	Afgebakend en stabiel	Breed, verschuivend, politiek beladen
Tijdshorizon	Maanden tot 1-2 jaar	Jaren, vaak 3-5+ jaar

2.4 Het Three Lines Model

Lijn	Rol bij projecten	Kernverantwoordelijkheden
Eerste lijn	Projectmanagement en operationele teams	Dagelijkse uitvoering, risicomanagement, implementatie van beheersmaatregelen
Tweede lijn	Risicomanagement, compliance, projectbeheersing	Beleidsontwikkeling, toezicht op naleving, risicomonitoring
Derde lijn	Internal audit	Onafhankelijke, objectieve assurance over governance en risicomanagement
Governing body	Board, auditcommissie, stuurgroep	Strategische richting, risicobereidheid, toezicht op alle drie de lijnen

Het Three Lines Model, gepubliceerd door het IIA in 2020, markeert een fundamentele verschuiving in het denken over governance en assurance.¹⁸ Het verdwijnen van de woorden "of Defence" is geen cosmetische aanpassing. Het oude model suggereerde dat de drie lijnen primair bestaan om de organisatie te beschermen tegen risico's. In het nieuwe model dragen alle drie de rollen bij aan waardecreatie. De eerste lijn beheert risico's in de dagelijkse operatie. De tweede lijn ondersteunt, monitort en daagt uit. De derde lijn biedt onafhankelijke assurance. Het vertrekpunt is niet langer verdediging maar het realiseren van doelstellingen.

De nadruk op samenwerking vervangt de strikte scheiding die het oude model kenmerkte. In de praktijk leidde het "of Defence"-model regelmatig tot silo-denken: de eerste lijn voelde zich niet verantwoordelijk voor risicomanagement omdat "de tweede lijn dat doet", terwijl Internal Audit zich beperkte tot het achteraf vaststellen van tekortkomingen. Het nieuwe model benadrukt dat alle drie de functies werken vanuit gedeelde doelstellingen en dat de waarde van Internal Audit toeneemt naarmate de samenwerking intensiever is.

Internal Audit opereert niet als poortwachter die aan het einde van een fase een oordeel velt, maar als enabler die gedurende het hele traject inzicht biedt. Bij een grootschalig transformatieprogramma kan Internal Audit vroeg in de planfase business cases toetsen, tijdens de uitvoering governance-structuren beoordelen en bij afronding de realisatie van beoogde baten evalueren. Die continuïteit is alleen mogelijk als de lijnen elkaar niet als tegenstanders zien maar als complementaire functies met een gedeeld belang.

Stel bij elke QA-review de vraag: "Hoe weten we straks of dit programma heeft opgeleverd wat het beloofde?" Blijft het antwoord vaag, dan is dat een rode vlag. Een goed benefits register bevat per benefit: een eigenaar, een nulmeting, een streefdoel, een meetmethode en geplande meetmomenten. Internal Audit is bij uitstek toegerust om de nulmeting uit te voeren, het streefdoel te toetsen op SMART-heid, de meetmethode te beoordelen en de voortgang van de metingen te challengen.

3. De Global Internal Audit Standards en QA

De Global Internal Audit Standards (GIAS) van het IIA zijn in 2024 gepubliceerd en per 9 januari 2025 van kracht als opvolger van het voormalige IPPF.

3.1 Assurance- en adviesdiensten

Assurancediensten: Internal Audit formuleert een oordeel of trekt conclusies over de beoordeelde activiteit. Centraal staat de driehoeksrelatie tussen auditee, belanghebbende (bestuur, audit committee) en Internal Audit als onafhankelijke beoordelaar.

Adviesdiensten: aard en reikwijdte worden vooraf afgesproken met de vragende partij, zonder formeel oordeel. Internal Audit opereert als critical friend of sparringpartner.

Stel bij elk QA-engagement vooraf vast of het een assurance- of adviesdienst is. Die keuze bepaalt de rapportagevereisten, de vereiste onafhankelijkheid en het type conclusies.

3.2 Relevante GIAS-standaarden

Opdrachtplanning (Principe 13 / Standaard 13.3): verlangt documentatie van QA-doelstellingen, reikwijdte, normen, middelen en tijdschema. Stem dit af op project-gates of mijlpalen.

Objectiviteit en onafhankelijkheid (Standaarden 2.1 en 2.2) Een auditor die eerder als adviseur bij een project betrokken was, kan niet zonder meer een formele assurance-opdracht voor datzelfde project uitvoeren.

Competentie en zorgvuldigheid (Standaarden 3.1 en 4.2) Het auditteam moet aantoonbare kennis hebben van projectmanagementmethodieken, governance-principes en benefits management.

De overgang van het International Professional Practices Framework (IPPF) naar de Global Internal Audit Standards in januari 2024 is meer dan een herstructurering.¹⁵ De GIAS organiseert de standaarden in vijf domeinen: het doel van internal auditing, ethiek en professionaliteit, het besturen van de auditfunctie, het managen van de auditfunctie en het uitvoeren van auditdiensten. De nadruk verschuift van compliance-gericht auditen naar waardecreatie. Voor QA bij projecten betekent dit dat de auditor toetst of procedures worden gevolgd én of het project bijdraagt aan de strategische doelstellingen.

Standaard 9.4 vereist dat de chief audit executive een risicogebaseerd auditplan opstelt. Projecten en programma's worden hierin opgenomen op basis van materialiteit en risicoprofiel, niet op basis van een vast rotatiepatroon. Een transformatieprogramma van twintig miljoen euro met hoge technische complexiteit rechtvaardigt een andere auditfrequentie dan een routinematig vervangingsproject. De GIAS bieden de chief audit executive expliciet de ruimte om het plan dynamisch aan te passen wanneer het risicoprofiel verandert, bijvoorbeeld bij scopewijzigingen of wisseling van sleutelfiguren.

De opdrachtcyclus voor QA-opdrachten volgt een helder patroon. Standaard 13.2 vereist dat de auditor de activiteit die wordt beoordeeld grondig begrijpt, inclusief de relevante risico's. In projectcontext: de projectdoelstellingen, governance-structuur, stakeholderbelangen en budgettering doorgronden voordat de scope wordt bepaald. Standaard 13.3 schrijft voor dat doelstellingen en scope voor elke opdracht worden vastgelegd. Tijdens de uitvoering (Standaard 14.1) verzamelt de auditor informatie die relevant, betrouwbaar en toereikend is. Bij de communicatie (Standaard 15.1) worden bevindingen gerapporteerd aan bestuur en management. In projectcontext is de timing cruciaal: een rapport dat drie maanden na een go-live verschijnt, heeft beperkte waarde vergeleken met een tussentijds signaal dat bijsturing mogelijk maakt.

Standaard 6.2 vereist dat het auditcharter het mandaat van de auditfunctie specificeert, inclusief scope en typen diensten. Voor QA bij projecten is dit een essentieel ankerpunt. Als het charter geen expliciete verwijzing bevat naar project-assurance, kan de auditfunctie in de praktijk worden geweerd met het argument dat dit "buiten het mandaat" valt. Een goed ingericht charter benoemt het recht op toegang tot projectinformatie, de bevoegdheid om gevraagd en ongevraagd te adviseren over projectrisico's, en de rapportagelijn naar het auditcomité bij escalatie. Zonder deze verankering blijft QA bij projecten een discretionaire activiteit.

De GIAS staan QA bij projecten niet in de weg. Ze versterken het. Het onderscheid tussen assurance en advies, de nadruk op risicogebaseerd werken en de competentie-eisen geven Internal Audit een stevig professioneel kader.

4. Governance en Risicomanagement

4.1 Governance-architectuur

Effectieve governance is de sterkste voorspeller van project- en programmasucces. Bij projecten betekent dat: een helder mandaat voor de projectmanager, een actieve stuurgroep met beslissingsbevoegdheid en duidelijke escalatieroutes. Bij programma's komen daar een programme board bij, een Senior Responsible Owner (SRO) die eindverantwoordelijk is voor de realisatie van benefits, en business change managers.

4.2 Taxonomie van projectrisico's

Risicocategorie	Beschrijving	QA-aandachtspunten
Strategisch risico	Misalignment met organisatiestrategie	Validiteit businesscase; strategische fit; periodieke herijking
Governance-risico	Onduidelijke rollen; ineffectieve besluitvorming	Rolbeschrijvingen; stuurgroep-effectiviteit; mandaten
Scope-risico	Scope creep en onduidelijke requirements	Changemanagement en traceability van requirements
Planningsrisico	Onrealistische deadlines en resourceconflicten	Realisme van de planning en analyse van het kritieke pad
Financieel risico	Budgetoverschrijdingen en onbetrouwbare kostenramingen	Kostenschattingsmethodiek en earned value-indicatoren
Technologisch risico	Onvolwassen technologie en integratieproblematiek	Technologische gereedheid en architectuurbeslissingen
Organisatorisch risico	Veranderweerstand en cultuurbarrières	Veranderbereidheid en stakeholderanalyse
Benefits-risico	Benefits niet gedefinieerd; geen eigenaar	Benefits register; KPI-definities; benefits tracking
Cybersecurity- en digitaliseringsrisico	Projecten met datamigraties, systeemintegraties of cloudtransities introduceren digitale risico's. Testomgevingen bevatten vaak productiedata zonder adequate beveiliging. Schaduw-IT ontstaat wanneer projectteams eigen tooling inrichten buiten de IT-governance om. NIS2 en DORA stellen aanvullende eisen aan digitale weerbaarheid die vanaf de ontwerpfase moeten worden meegenomen.	Toets of datamigraties een gevalideerd migratieplan hebben met rollback-scenario's. Verifieer dat testomgevingen geen onbeschermde productiedata bevatten. Controleer of DORA- en NIS2-vereisten zijn opgenomen in het projectplan en of naleving aantoonbaar is.
Leveranciers- en uitbestedingsrisico	Afhankelijkheid van externe leveranciers creëert risico's rond continuïteit, kwaliteit en kosten. Vendor lock-in beperkt de onderhandelingspositie. Multi-vendor-omgevingen introduceren coördinatiecomplexiteit en onduidelijke verantwoordelijkheden bij incidenten. Contractuele afspraken sluiten niet altijd aan op de werkelijke projectbehoefte, met name rond intellectueel eigendom en exit-arrangementen.	Beoordeel of contracten exit-clausules, escrow-regelingen en prestatie-indicatoren bevatten. Toets bij multi-vendor-projecten of de demarcatie tussen leveranciers helder is en of er een effectief regiemodel functioneert. Controleer of het leveranciersrisico is opgenomen in de projectrisicoanalyse.
Regulatoir en compliance-risico	Projecten opereren binnen een toenemend complex regulatoir landschap. AVG/GDPR geldt voor elk project dat persoonsgegevens verwerkt. Sectorspecifieke regulering zoals de Wft, DORA en NIS2 stelt aanvullende eisen. Het risico strekt zich uit tot vertragingen en meerkosten door niet-tijdige implementatie van wettelijke vereisten.	Verifieer of een Data Protection Impact Assessment (DPIA) is uitgevoerd voor projecten met persoonsgegevensverwerking. Toets of sectorspecifieke regelgeving is vertaald naar concrete projectvereisten. Beoordeel of de projectplanning rekening houdt met de effectieve datum van nieuwe regulering.

4.3 Gedragswetenschappelijke dimensie

De planning fallacy, beschreven door Kahneman en Tversky, verklaart waarom projectplanningen systematisch te optimistisch zijn.² Mensen baseren hun schattingen op het best denkbare scenario in plaats van op historische uitkomsten van vergelijkbare projecten. Flyvbjerg toont aan dat bij grote projecten budgetoverschrijdingen en vertragingen niet de uitzondering zijn maar de norm, en dat dit patroon decennialang stabiel is.¹

Naast deze onbewuste bias identificeert Flyvbjerg een bewuste variant: strategic misrepresentation.¹⁹ Projectinitiatiefnemers presenteren kosten bewust te laag en baten bewust te hoog om goedkeuring te verkrijgen. In een concurrentie om schaarse middelen wint het project met de aantrekkelijkste business case, niet het project met de meest realistische. Flyvbjerg beschouwt strategic misrepresentation als een zwaardere factor dan de planning fallacy: waar optimisme-bias een menselijke beperking is, is strategische vertekening een rationele keuze met perverse prikkels. De auditor moet niet alleen toetsen of een planning realistisch is, maar ook of de institutionele prikkels eerlijkheid bevorderen of juist bestraffen.

De sunk cost fallacy houdt projecten in leven die gestopt zouden moeten worden.⁵ Naarmate er meer is geïnvesteerd, wordt stoppen psychologisch moeilijker, ongeacht de vooruitzichten. Dit effect wordt versterkt door escalation of commitment: niet alleen de reeds gemaakte kosten spelen mee, maar ook reputatie-effecten en politieke dynamiek. Een bestuurder die een programma publiekelijk heeft verdedigd, ervaart stopzetten als persoonlijk falen. Het resultaat is dat projecten doorlopen die geen redelijke kans op succes meer hebben.

Groupthink manifesteert zich in projectomgevingen als het ontbreken van kritische tegenspraak.⁴ Stuurgroepen waarin alle leden dezelfde belangen delen, produceren besluiten zonder werkelijke deliberatie. Een projectmanager die problemen escaleert, riskeert het label "negatief" te krijgen. Afwijkende signalen worden niet onderdrukt door dwang maar door sociale druk en het verlangen naar consensus.

De uniqueness bias is een minder bekende maar even schadelijke factor: de overtuiging dat het eigen project fundamenteel anders is dan alle voorgaande projecten. "Onze situatie is uniek, dus historische data is niet relevant." Deze redenering blokkeert het gebruik van referentiegegevens en maakt elke planning tot een inschatting vanuit de buik. Flyvbjerg beschouwt dit als een van de hardnekkigste obstakels voor betere projectvoorspellingen, omdat het de deur sluit naar de meest effectieve debiasing-techniek.⁷

Reference Class Forecasting (RCF), ontwikkeld door Flyvbjerg op basis van het werk van Kahneman en Tversky, biedt een systematische correctie.¹⁹ De methode werkt in drie stappen: stel een referentieklasse samen van vergelijkbare projecten, analyseer de statistische verdeling van uitkomsten in die klasse, en positioneer de specifieke prognose van het project binnen die verdeling. Als negentig procent van vergelijkbare projecten meer dan twintig procent over budget ging, is een prognose die precies op budget uitkomt statistisch ongeloofwaardig. Internal Audit past RCF toe door bij business case reviews te vragen: welke referentieklasse is gehanteerd? Zijn de historische uitkomsten meegewogen? En als het projectteam claimt dat hun project uniek is: op welke empirische gronden?

5. De Rol van Internal Audit

5.1 Mandaat en positionering

Bij een faalpercentage van circa 42%¹⁶ kan internal audit het zich niet permitteren om passief te wachten op het volgende audit-interval of de volgende stage gate. De grootste waarde zit niet in het bevestigen van control design, maar in de vraag of het programma werkelijk is ingericht om de strategische intentie te realiseren.

5.2 Het rollenspectrum

Rol	Kenmerken	Output	Onafhankelijkheid
Formele audit	Volledige audit met formeel rapport en opvolging	Auditrapport met bevindingen en aanbevelingen	Maximale zekerheid
Assurance review	Gerichte beoordeling van specifieke onderdelen	Reviewrapportage met conclusie	Hoog
Advisory	Advies op verzoek; geen formele conclusie	Adviesmemo of presentatie	Matig; vereist bewaking
Critical friend	Doorlopende betrokkenheid, real-time feedback	Informele signalen en periodieke rapportage	Deze twee sporen staan op gespannen voet en vragen om expliciete afspraken
Observer	Stuurgroepen bijwonen, rapportages meelezen	Early warning signals richting management	Hoog; passieve rol

De organisatie hanteert drie reviewvormen: (1) quick scan, een snelle toets op hoofdlijnen; (2) opinie, een adviesgerichte beoordeling zonder formeel assurance-karakter; en (3) deep dive, een geconcentreerde review van één specifiek onderwerp.

5.3 Zes strategische focusgebieden

1. Challengen van het risk universe - Projectrisico's zijn mogelijk niet meegenomen in het periodiek herziene risk universe
2. Agile audit planning - Flexibel, agile en responsief auditplan met standaardreservering voor project assurance
3. Vroege betrokkenheid - Meer waarde in het reviewen van de businesscase tijdens ontwikkeling dan bij post-implementatie
4. Real-time feedback - Kortere, dashboard-achtige rapporten; vaste uitnodigingen voor governance-forums
5. Outcome assurance - Vraag: "Wat zal er anders zijn voor de business en hoe weten we dat?"
6. Due professional care en specialisatie - Co-sourcing waar expertise ontbreekt; Agile-terminologie beheersen

5.4 Competentieprofiel

• Kennis van PRINCE2, PMBOK, Agile/Scrum, SAFe en relevante sectorspecifieke methoden
• Begrip van benefits management en programmagovernance (MSP)
• Financiële analysevaardigheden (earned value management, kostenschattingsmethoden)
• Stakeholder management en communicatieve vaardigheden op bestuursniveau
• Kennis van IT-architectuur en technologie bij digitale transformatieprogramma's

6. Waarom projecten falen: Structurele patronen

Het Chartered Institute of Internal Auditors identificeerde tien terugkerende patronen die consistent bijdragen aan projectfalen. Deze patronen zijn structureel en doorsnijden sectoren en projecttypen.

6.1 De tien terugkerende patronen

1. Onvoldoende adoptierisicomanagement Verandermanagement wordt als randactiviteit behandeld. Projecten stagneren omdat eindgebruikers niet gereed zijn.

2. Onduidelijke of niet-afgestemde programma-uitkomsten Iedereen heeft een ander beeld van wat het project moet opleveren. Beslissingen worden versnipperd genomen, zonder samenhangend kader.

3. Zwakke governance en rolonduidelijkheid Stuurgroepen wisselen voortdurend van samenstelling, escalatiepaden zijn vaag en besluitvorming stagneert. Niemand voelt zich eigenaar, dus niemand grijpt in.

4. Onzichtbare risico's voor het leiderschap Risicologboeken bestaan, maar ze zijn oppervlakkig. De blik is naar binnen en naar beneden gericht. Wat zich buiten en boven afspeelt, bereikt de boardroom niet.

5. Gebrekkige business readiness Projecten krijgen groen licht zonder dat iemand toetst of de organisatie de verandering kan absorberen. De gevolgen worden zichtbaar na go-live, niet ervoor.

6. Gefragmenteerde architectuur Parallelle werkstromen zonder overkoepelende architectuur leiden tot duplicatie en gemiste synergieën. Elke afdeling bouwt zijn eigen oplossing, los van het geheel.

7. Optimisme-bias en zichtbaarheidslacunes 'Groen totdat het rood is': overmoedigheid en het ontbreken van een echte challengecultuur maskeren problemen tot het te laat is.

8. Benefits niet gevolgd of getraceerd Na go-live verdwijnt benefits-realisatie van de agenda. Post-implementatiereviews blijven oppervlakkig of vinden niet plaats.

9. Data-, integratie- en procesgereedheid onderschat Onvoldoende zicht op datakwaliteit en interface-gereedheid bij systeemtransities levert verrassingen op het slechtste moment.

10. Operating model of cultuur niet afgestemd Leveringsteams bouwen voor een toekomst waar de organisatie nog niet klaar voor is.

6.2 Culturele waarschuwingssignalen

• Terughoudendheid om te escaleren of gebrekkige plannen ter discussie te stellen
• Weerstand tegen het adopteren van nieuwe processen ondanks formele go-live
• Tactische afsluiting van issues om deadlines te halen; root causes uitgesteld
• Verkeerd afgestemde prikkels: snelheid of kosten boven strategische doelen
• Overdreven optimisme in rapportages: 'groen totdat het rood is'-verrassingen

7. Methodieken en Raamwerken

7.1 Gateway Review-proces

Gate	Naam	Focus
Gate 0	Strategische beoordeling	Afstemming op organisatiestrategie en bedrijfsbehoefte
Gate 1	Preliminaire evaluatie	Haalbaarheid en analyse van opties
Gate 2	Business case	Kwaliteit en robuustheid van de businesscase
Gate 3	Contractering	Gereedheid voor contract- en leveranciersbeheer
Gate 4	Gereedheid voor dienstverlening	Operationele gereedheid en transitieplanning
Gate 5	Benefits-realisatie	Daadwerkelijke realisatie van geplande benefits

7.2 QA-focus per projectfase

Fase	Kernvragen voor QA	Deliverables voor toetsing
Initiatie	Klopt de businesscase? Zijn de governance-structuren op orde?	Businesscase, projectcharter, stakeholderanalyse
Planning	Kloppen de schattingen? Werkt het risicomanagement?	Projectplan, WBS, risicoregister
Uitvoering	Ligt het project op koers? Worden risico's daadwerkelijk beheerst?	Voortgangsrapportages, change logs, earned value data
Oplevering	Zijn de acceptatiecriteria behaald? Is de transitie naar beheer geborgd?	Testresultaten, transitieplan, lessons learned
Afsluiting en benefits	Worden de beoogde benefits daadwerkelijk gerealiseerd?	Benefits-realisatierapport, post-implementatiereview

7.3 MSP 5e editie

MSP is ontwikkeld door AXELOS (nu PeopleCert) en geldt als het meest uitgebreide en in Europa meest gebruikte raamwerk voor programmamanagement. De vijfde editie (2020) rust op drie kerncomponenten: zeven principes, zeven governance-thema's en zeven processen.

De zeven MSP-principes:

1. Lead with Purpose: Leiderschap met een heldere visie en strategische richting
2. Collaborate Across Boundaries: Samenwerking over organisatorische grenzen
3. Deal with Ambiguity: Effectief omgaan met onzekerheid en complexiteit
4. Align with Priorities: Continue afstemming op organisatieprioriteiten
5. Deploy Diverse Skills: Inzet van diverse competenties en perspectieven
6. Realize Measurable Benefits: Focus op meetbare batenrealisatie als kernresultaat
7. Bring Pace and Value: Snelheid combineren met daadwerkelijke waardelevering

De zeven governance-thema's:

Thema	Beschrijving	Relevantie voor QA en audit
Organisation	Hoe rollen, verantwoordelijkheden en besluitvorming zijn ingericht	Maakt zichtbaar wie verantwoordelijk is voor kwaliteit
Design	Het ontwerp van de gewenste eindsituatie (blueprint)	Kwaliteitscriteria en meetbare doelstellingen
Justification	Doorlopende validatie van de business case	Fundament voor assurance bij investeringsbeslissingen
Structure	Projectstructuur en samenhang binnen het programma	Bewaking van afhankelijkheden en integratierisico's
Knowledge	Kennismanagement, informatiestromen en geleerde lessen	Leereffecten structureel verankeren
Assurance	Assurance op programmaniveau inrichten	Directe aansluiting op de rol van internal audit (Three Lines)
Decisions	Besluitvorming en escalatie	Governance-effectiviteit en escalatiecultuur als auditfocus

De zeven MSP-processen:

1. Identify the Programme: Vaststellen van de programma-scope en strategische rationale
2. Design the Outcomes: Ontwerpen van de gewenste eindresultaten en de blueprint
3. Plan Progressive Delivery: Plannen van de gefaseerde levering via tranches
4. Deliver the Capabilities: Uitvoeren van projecten die de benodigde capabilities opleveren
5. Embed the Outcomes: Verankeren van de resultaten in de organisatie
6. Evaluate New Information: Continu evalueren van nieuwe informatie en aanpassen
7. Close the Programme: Formele afsluiting met evaluatie van batenrealisatie

7.4 Vergelijking normatieve kaders

Aspect	MSP	ISO 21503	PMI Standard
Oorsprong	AXELOS/PeopleCert (VK)	ISO (internationaal)	PMI (VS)
Karakter	Methodiek (prescriptief)	Guidance (principieel)	Standaard (beschrijvend)
Assurance-component	Expliciet thema	Governance-activiteit	QA binnen life cycle
Benefits management	Zeer uitgebreid	Beschreven	Performance domain
Geschikt als norm	Ja, bij adoptie	Ja, universeel	Ja, bij adoptie
Certificeringen	MSP Foundation en Practitioner	Niet certificeerbaar	PgMP

7.5 Maturity model voor QA-assessment

Niveau	Classificatie	Kenmerken
1	Initieel (Ad hoc)	Geen formeel QA-proces. Resultaten zijn volledig afhankelijk van individuele competentie.
2	Herhaalbaar	Basisprocessen bestaan, maar worden niet consistent toegepast. Governance is beperkt.
3	Gedefinieerd	Gestandaardiseerde methoden, een werkend PMO en geïntegreerd risicomanagement.
4	Beheerst	KPI's, portfoliomanagement, actieve benefits tracking, CI/CD bij Agile-projecten
5	Geoptimaliseerd	Organisatiebreed leren, predictive analytics, integratie met strategie-executie

Toets primair aan de standaard die de organisatie zelf hanteert. Zonder expliciete methodiek is ISO 21503 het meest neutrale en breed erkende referentiekader.

8. Agile als Projectmethodiek en de Impact op QA

Agile-projecten slagen drie keer vaker dan watervalprojecten (Standish Group CHAOS Report).¹⁶ Dat vraagt om een fundamenteel andere inrichting, uitvoering en beoordeling van quality assurance.

8.1 Waterval versus Agile

Dimensie	Waterval	Agile
Projectstructuur	Lineair en sequentieel: elke fase wordt afgerond voordat de volgende begint	Iteratief en cyclisch: korte sprints van 2 tot 4 weken
Kwaliteitsborging	QA vindt plaats in een aparte testfase na de ontwikkeling	QA zit in elke sprint; testen is een doorlopend proces
Feedbackcyclus	Feedback aan het einde	Doorlopende feedback via sprint reviews en retrospectives
Stakeholderbetrokkenheid	Alleen betrokken bij de start (eisen) en bij oplevering	Doorlopend betrokken bij elke iteratie
Wijzigingsbeheer	Wijzigingen zijn duur en worden zo veel mogelijk vermeden	Wijzigingen horen erbij en zijn onderdeel van het proces
Levering	Lever een werkend product op aan het einde	Werkende incrementen na elke sprint, vroege waarderealisatie

8.2 SAFe built-in quality: vijf dimensies

• Flow: Optimaliseren van de waardestroom om bottlenecks te elimineren
• Architectuur- en ontwerpkwaliteit: flexibel, onderhoudbaar en schaalbaar ontwerp
• Codekwaliteit: code-reviews, pair programming en geautomatiseerde testing
• Systeemkwaliteit: testen van het gehele systeem inclusief integraties
• Releasekwaliteit: releases stabiel, volledig en gereed voor productie

8.3 Governance-vergelijking waterval versus Agile

Governance-aspect	Waterval	Agile / SAFe
Beslismomenten	Fase-gates en gateway reviews	Sprint reviews, PI planning, system demo's
Kwaliteitspoorten	Formele QA-fase na ontwikkeling	Doorlopend testen met een Definition of Done per sprint
Voortgangsrapportage	Statusrapportage per fase	Burndown charts, velocity metrics en dashboards
Risicozichtbaarheid	Risicoregister, periodieke updates	Sprint-retrospectives, PI-riskboards
Stakeholderfeedback	Begin en einde	Elke sprint (2–4 weken)
Auditaanpak	Formele fase-reviews	Agile audits in sprints met real-time feedback
Benefits tracking	Post-implementatiereview	Incrementeel, meetbaar na elke release

8.4 Aanbevelingen voor internal audit bij Agile

1. Investeer in training van het auditteam in Agile principes en praktijken
2. Stel een divers team samen met kennis van Agile methodieken en diepgaande sector-expertise
3. Ontwikkel een flexibel auditplan met een prioriteitenlijst in plaats van een rigide 12-maandenplan
4. Bouw een nauwere relatie op met de audit-opdrachtgever om evolving needs te begrijpen
5. Benut data-analytics en technologie om de efficiëntie van audits te verhogen
6. Stel KPI's vast om de effectiviteit van Agile audits te meten en bij te sturen

Spreek vooraf QA-momenten af die aansluiten op het Agile-ritme: na elke derde of vierde sprint, of bij PI-boundaries in SAFe.

8.5 Hybride modellen en "Agile in name only"

De meeste organisaties werken niet zuiver agile of zuiver waterval. De praktijk is hybride. Veelvoorkomende combinaties zijn water-scrum-fall, waarin de plannings- en opleverfase waterval verlopen maar de bouwfase in sprints wordt uitgevoerd, en PRINCE2 Agile, dat het governance-raamwerk van PRINCE2 combineert met agile delivery.²¹ Hybride modellen zijn pragmatisch. Ze worden problematisch wanneer de organisatie claimt agile te werken maar in werkelijkheid watervaldenken domineert. Dit verschijnsel, soms aangeduid als "Agile in name only", kenmerkt zich door het uitvoeren van Scrum-ceremonies zonder de onderliggende principes te omarmen.

Een auditor herkent dit patroon aan concrete signalen. De scope staat vast bij aanvang en wordt niet bijgesteld op basis van voortschrijdend inzicht. Sprint reviews zijn demonstraties aan het management in plaats van feedbackmomenten met eindgebruikers. De Definition of Done is zo verwaterd dat technische schuld structureel wordt doorgeschoven. De Product Backlog wordt behandeld als een gedetailleerd projectplan. Retrospectives vinden wel plaats maar leiden niet tot meetbare verbeteringen.

Internal Audit toetst bij hybride projecten specifiek of de gekozen methode past bij de aard van het project en of de governance-structuur aansluit op de werkwijze. Een waterval-stuurgroep die maandelijks vergadert, biedt onvoldoende sturing voor een project dat in tweewekelijkse sprints werkt. De auditor beoordeelt of de hybride aanpak een bewuste ontwerpkeuze is, gedocumenteerd en afgewogen, of een onbedoeld compromis dat het slechtste van beide werelden combineert.

8.6 Scrum-specifieke QA-vragen

Bij projecten die Scrum toepassen, richt Internal Audit zich op de kernelementen van het framework. De Product Owner maximaliseert de waarde van het product. De centrale vraag is of deze rol werkelijk mandaat heeft. Kan de Product Owner zelfstandig prioriteiten stellen en items schrappen? Of functioneert hij of zij als doorgeefluik voor een stuurgroep die de feitelijke besluiten neemt? Een Product Owner zonder mandaat ondermijnt het hele Scrum-mechanisme, omdat prioritering dan niet wordt gedreven door waarde maar door hiërarchie.

De Definition of Done bepaalt wanneer een product increment als af wordt beschouwd. Een effectieve DoD is uitdagend: niet alleen functionele eisen maar ook testdekking, documentatie, security-checks en performance-criteria. De auditor toetst of de DoD schriftelijk is vastgelegd, of deze periodiek wordt aangescherpt en of het team zich eraan houdt. Een verwaterde DoD is een vroege indicator van toekomstige kwaliteitsproblemen.

De Sprint Retrospective is het leermechanisme van Scrum. De auditor stelt vast of retrospectives plaatsvinden, of de uitkomsten worden vastgelegd en of verbeteracties worden opgepakt. Een team dat elke twee weken dezelfde problemen benoemt zonder dat er iets verandert, leert niet.

Technische schuld verdient aandacht als auditonderwerp. Het accumuleert wanneer een team bewust kiest voor een snelle oplossing die op termijn extra werk veroorzaakt. Signalen zijn een toenemend aantal defects per sprint, langere doorlooptijden voor eenvoudige wijzigingen en een groeiend verschil tussen de velocity van het team en de werkelijk opgeleverde waarde. De auditor maakt technische schuld bespreekbaar door te vragen hoeveel sprintcapaciteit structureel gaat naar het oplossen van bestaande problemen in plaats van het bouwen van nieuwe functionaliteit.

9. Praktische Handvatten voor Auditors

9.1 QA-checklist projectreview

A. Governance en besturing

• Is er een actueel en goedgekeurd projectcharter met duidelijke doelstellingen?
• Zijn de rollen en verantwoordelijkheden (RACI) eenduidig vastgelegd en gecommuniceerd?
• Functioneert de stuurgroep effectief: vergaderfrequentie, besluitvorming, aanwezigheid?
• Zijn escalatieroutes gedefinieerd en worden deze in de praktijk gebruikt?

B. Businesscase en benefits

• Is de businesscase gebaseerd op realistische aannames en extern gevalideerd?
• Zijn benefits SMART gedefinieerd met duidelijke eigenaren en meetmomenten?
• Wordt de businesscase periodiek herijkt op basis van voortschrijdend inzicht?
• Is er een mechanisme voor post-implementatie benefits tracking?

C. Risicomanagement

• Is er een actueel risicoregister met eigenaren, mitigerende maatregelen en deadlines?
• Zijn de belangrijkste risico's geëscaleerd naar de stuurgroep met concrete actievoorstellen?
• Is er adequate contingency in budget en planning voor geïdentificeerde risico's?

D. Planning en voortgang

• Is de planning gebaseerd op een gedetailleerde Work Breakdown Structure?
• Worden voortgangsrapportages tijdig en accuraat opgeleverd?
• Is er een formeel change management-proces voor scope-wijzigingen?

E. Kwaliteit en oplevering

• Is er een kwaliteitsplan met gedefinieerde acceptatiecriteria?
• Zijn testplannen opgesteld en worden testresultaten systematisch vastgelegd?
• Worden lessons learned systematisch vastgelegd en gedeeld?

F. Aanvullend bij Agile projecten

• Hanteert het team een heldere Definition of Done die kwaliteitscriteria bevat?
• Worden sprint reviews daadwerkelijk gebruikt om feedback van stakeholders te verwerken?
• Wordt technische schuld bewust gemanaged?

9.2 Rapportagevorm en communicatie

• Gebruik een RAG-status (Rood-Amber-Groen) dashboard als eerste pagina van elke rapportage
• Beperk bevindingen tot vijf tot zeven meest materieel significante observaties
• Formuleer elke bevinding met een duidelijke implicatie en concrete, uitvoerbare aanbeveling
• Bespreek concept-bevindingen altijd eerst met het projectteam; plan vooruit, want afstemmen kost tijd

Gebruik een one-page QA-dashboard dat in één oogopslag de status toont van governance, businesscase, risico's, planning, kwaliteit en stakeholders.

10. Handvatten voor Bestuurders en Directie

10.1 QA als strategisch sturingsinstrument

Projectfalen kost geld en ondermijnt strategie. Projectgovernance is een kernverantwoordelijkheid, niet een technisch detail. Het raakt aan waardecreatie, reputatie en vertrouwen van stakeholders.

Wat bestuurders en directie moeten borgen bij projectgovernance:

• Financiële oversight: Waarborgen dat projecten binnen budget verlopen en financiële risico's adequaat worden beheerd
• Investeringsbeslissingen: Beoordelen en goedkeuren van investeringsmogelijkheden inclusief de potentiële return on investment
• Strategische richting: Vaststellen van de visie, missie en waarden als kompas voor alle projectinvesteringen
• Tone at the top: Bevorderen van een cultuur van escalatie, transparantie en realistische rapportage
• Portfolio-optimalisatie: Handhaven van een gebalanceerd portfolio
• Accountability: Verantwoordelijk houden van het management voor het implementeren van beleid

10.2 Kritische vragen voor bestuurders en directie

Strategische vragen

• Past dit project of programma nog steeds bij onze strategische prioriteiten?
• Als we vandaag opnieuw zouden beginnen, zouden we dezelfde keuzes maken?
• Wie is de eigenaar van de benefits en hoe wordt hij of zij afgerekend op de realisatie?

Governance-vragen

• Beschikt de stuurgroep over de juiste samenstelling, mandaat en tijdsbesteding?
• Zijn er escalaties geweest en zo ja, zijn deze adequaat afgehandeld?
• Welke informatie bereikt mij niet via de reguliere rapportagelijnen?

Vragen vanuit risicoperspectief

• Wat zijn de drie grootste risico's en wat doen we eraan?
• Welke aannames in de businesscase zijn het kwetsbaarst en wat is het effect als ze niet uitkomen?
• Is er een realistisch fallback-scenario als het project onhoudbaar blijkt?

Aanvullende vragen bij Agile en programmamanagement

• Worden Agile-principes zoals built-in quality en continue feedback effectief toegepast?
• Is bij programma's het MSP-assurancekader ingericht conform het Three Lines of Defence-model?
• Is de organisatie gereed om de verandering te absorberen en te bestendigen?
• Worden lessons learned daadwerkelijk geïntegreerd in volgende projectfasen?

De krachtigste vraag die een bestuurder kan stellen is niet 'hoe staat het ervoor?' maar 'wat weet ik niet?' QA door Internal Audit brengt precies die blinde vlekken in de informatievoorziening aan het licht.

10.3 QA op portfolioniveau

Op portfolioniveau beoordeelt Internal Audit of de resource-allocatie aansluit bij de strategische prioriteiten, of er zicht is op cross-project afhankelijkheden en cumulatieve risico's, en of de portfolio-governance voorziet in periodieke herijking.

Eén jaarlijkse portfolio-review door Internal Audit, gebaseerd op geaggregeerde bevindingen uit individuele QA-engagements, levert meer organisatiebrede verbeterkracht op dan tien losse projectreviews.

11. Casussen en Geleerde Lessen

11.1 Publieke sector

In Nederland concludeerde de Commissie-Elias (Tweede Kamer, vergaderjaar 2013-2014, 33 326, nr. 5) dat ICT-projecten bij de rijksoverheid structureel leden onder onrealistische planningen, gebrekkige governance en onvoldoende onafhankelijke toetsing. In het Verenigd Koninkrijk wees het National Audit Office herhaaldelijk op het belang van onafhankelijke assurance (HC 960, Session 2019-2021; HC 554, Session 2023-24).

Kernlessen uit de publieke sector:

• Onafhankelijke QA moet verankerd zijn in het governance-framework vanaf de initiatiefase
• De SRO moet persoonlijk verantwoordelijk worden gehouden voor het aanvragen en opvolgen van QA-bevindingen
• Gateway reviews op natuurlijke beslismomenten zijn effectiever dan periodieke audits op willekeurige momenten

11.2 Casus: kernbankensysteem bij een grote bank

Een grote Nederlandse bank startte een programma om het kernbankensysteem te vervangen. Budget: 400 miljoen euro, doorlooptijd vier jaar. Internal Audit schoof pas in het tweede jaar aan, nadat de stuurgroep ontdekte dat voortgangsrapportages elkaar tegenspraken.

De eerste QA-review van Internal Audit bracht drie problemen aan het licht: de businesscase steunde op migratiescenario's zonder empirische onderbouwing, het programma kende drie rapportagelijnen die niet op elkaar waren afgestemd, en op bestuursniveau was geen benefits owner aangewezen. Het programma werd achttien maanden later opgeleverd dan gepland. De businesscase bleef positief, maar de vertraging was vermijdbaar.

Les: Had Internal Audit eerder aan tafel gezeten, dan waren de governance-problemen maanden eerder boven water gekomen.

11.3 Casus: digitaal loket bij een overheidsinstelling

Een grote overheidsinstelling startte een programma voor de ontwikkeling van een digitaal burgerloket: negen deelprojecten, vier leveranciers, totaalbudget 85 miljoen euro. Internal Audit zat er vanaf dag één bij.

Na het derde kwartaal constateerde Internal Audit dat twee deelprojecten technisch onverenigbare oplossingen bouwden. Die vroege signalering bespaarde naar schatting vier tot zes maanden herwerk. De CIO achteraf: "De projectleiders wisten het wel, maar durfden niet te escaleren. Ze waren bang voor de consequenties."

Les: QA door Internal Audit doorbreekt de informatiesilo's die binnen de projectorganisatie intact blijven.

11.4 Casus: ERP-implementatie bij een productiebedrijf

Een internationaal productiebedrijf rolde een nieuw ERP-systeem uit over veertien locaties in zes landen. Halverwege bleek change management structureel onderbelicht: medewerkers vielen terug op schaduwadministraties in Excel. Pas nadat een dedicated change management-workstream werd toegevoegd, steeg de adoptiegraad bij de volgende uitrolfase meetbaar.

Les: Technisch succes is geen garantie voor programmasucces. QA moet de menselijke kant van verandering expliciet toetsen.

11.5 Casus: de migratie die niemand wilde stoppen

Een middelgrote financiële instelling besluit haar kernverwerkingssysteem te migreren naar een nieuw platform. De business case belooft lagere operationele kosten en een modernere architectuur. Budget: veertien miljoen euro, doorlooptijd achttien maanden. De stuurgroep bestaat uit drie directieleden die het project gezamenlijk sponsoren.

Na zes maanden ontstaan de eerste problemen. De complexiteit van de datamigratie is onderschat: historische transactiedata blijkt inconsistenties te bevatten die handmatige correctie vereisen. Het projectteam vraagt om een scopewijziging en drie maanden extra doorlooptijd. De stuurgroep stemt in, maar past het budget slechts marginaal aan. Internal Audit is op dat moment niet betrokken. Het auditcharter bevat geen expliciete verwijzing naar project-assurance en de chief audit executive heeft het project niet opgenomen in het auditplan omdat het "onder directieverantwoordelijkheid" valt.

Na twaalf maanden is het project acht maanden achter op schema en vijf miljoen euro over budget. Een externe review, ingeschakeld op aandringen van de raad van commissarissen, constateert fundamentele tekortkomingen: geen onafhankelijke kwaliteitsborging, geen gestructureerd risicomanagement, geen referentietoets tegen vergelijkbare migraties. De leverancier heeft contractueel een sterke positie en heeft inmiddels twee keer het team gewisseld. De migratie wordt uiteindelijk afgerond na 28 maanden en 23 miljoen euro. De beloofde baten worden slechts gedeeltelijk gerealiseerd.

Les: Als Internal Audit in de planfase de business case had getoetst met Reference Class Forecasting, was de onderschatting van de migratiecomplexiteit vroegtijdig gesignaleerd. Als het auditcharter project-assurance had geborgd, was onafhankelijke kwaliteitsborging geen gunst geweest maar een recht. Het verschil tussen een project dat ontspoort en een project dat wordt bijgestuurd is zelden de techniek. Het is de aanwezigheid van iemand die de juiste vragen stelt op het moment dat bijsturen nog mogelijk is.

11.6 Universele lessen

Les	Implicatie voor QA-praktijk
Vroeg starten levert het meeste rendement op	Richt QA in vanaf de businesscase-fase, niet pas wanneer uitvoeringsproblemen zichtbaar worden
Onafhankelijkheid staat niet ter discussie	De auditor rapporteert direct aan het bestuur of auditcomité, zonder tussenlaag van projectmanagement
Benefits realisation vereist structurele borging	QA houdt niet op bij go-live. Benefits materialiseren vaak pas maanden na oplevering
Competentie bepaalt geloofwaardigheid	Investeer in projectmanagementkennis bij auditors. Zet gastauditors in voor specifieke expertise waar het eigen team niet over beschikt.
Cultuur bepaalt effectiviteit	In een open organisatie werkt QA fundamenteel beter dan in een organisatie waar fouten worden afgestraft.

12. Conclusie en Aanbevelingen

12.1 Synthese

Quality Assurance door Internal Audit voegt waarde toe op drie niveaus. Op projectniveau signaleert het risico's voor ze escaleren. Op portfolioniveau legt het structurele patronen bloot die op één project onzichtbaar blijven. En het verankert verantwoording en transparantie in de governance.

In agile omgevingen verschuift kwaliteitsborging van een afzonderlijke fase naar een doorlopende activiteit. Het Three Lines Model, MSP en de GIAS 2024 leveren het professionele kader. De bereidheid om te escaleren, realistische rapportages te eisen en strategische alignment te toetsen: dat is wat het verschil maakt.

Data-analytics en kunstmatige intelligentie openen nieuwe mogelijkheden voor continuous project monitoring. Waar de auditor traditioneel steekproefsgewijs toetst op basis van periodieke reviews, maakt technologie het mogelijk om projectdata continu te analyseren. Automatische afwijkingsdetectie signaleert wanneer de burn-down rate structureel afwijkt van het plan, wanneer het aantal openstaande risico's sneller groeit dan de mitigerende maatregelen, of wanneer het budgetverloop een patroon vertoont dat bij vergelijkbare projecten leidde tot overschrijding. Predictive project analytics gaat een stap verder: op basis van historische data berekent een model de waarschijnlijkheid van vertraging of budgetoverschrijding. Dit vervangt het oordeel van de auditor niet. Het verrijkt dat oordeel met patronen die het menselijk oog niet ziet in de massa van projectrapportages.

Generatieve AI verandert het projectwerk zelf. Teams genereren code, documentatie en testscenario's sneller dan ooit. Dat versnelt iteraties, maar introduceert nieuwe risico's. AI-gegenereerde deliverables vereisen eigen kwaliteitsborging: wie reviewt de output, op welke criteria en met welk mandaat? Wanneer een projectteam een architectuurbeslissing baseert op een AI-aanbeveling, moet de auditor kunnen vaststellen welke input het model ontving, welke alternatieven zijn overwogen en of de beslissing bewust en gedocumenteerd is genomen.

Continuous assurance, het ideaal van doorlopende in plaats van periodieke zekerheid, is de logische volgende stap. Bij projecten betekent dit: niet eenmalig een gateway review uitvoeren, maar gedurende het hele traject signalen ontvangen, analyseren en terugkoppelen. Dit vraagt een andere werkwijze: real-time toegang tot projectdashboards, methodologie die verschuift van steekproeven naar continue monitoring, en competenties die data-analyse en kennis van agile werkwijzen combineren met klassieke auditexpertise. De GIAS bieden hiervoor de ruimte.¹⁵ De uitdaging ligt niet in de standaarden maar in het vermogen van auditfuncties om die ruimte te benutten.

12.2 Aanbevelingen voor Internal Audit

1. Neem project- en programma-QA expliciet op in het audit universe met jaarlijkse risicoanalyse
2. Differentieer de QA-aanpak: projectgerichte benadering (scope-planning-budget) versus programmabendering (governance-benefits-alignment)
3. Combineer formele assurance-momenten bij gates met informele advisory en monitoring
4. Investeer structureel in projectmanagementkennis, inclusief Agile frameworks (Scrum, SAFe) en MSP
5. Adopteer Agile audit-methoden voor Agile projecten; gebruik MSP-assurancekader bij programma's
6. Rapporteer kort, visueel en actiegericht: dashboards en RAG-statussen; maximaal zeven bevindingen
7. Aggregeer bevindingen tot organisatiebrede inzichten; deel periodieke meta-analyse met senior management
8. Verschuif de focus van delivery tracking naar outcome assurance; zet adoptierisico op de agenda

12.3 Aanbevelingen voor bestuurders en directie

1. Benut QA door Internal Audit actief als strategisch sturingsinstrument
2. Richt een formeel opvolgingsproces in voor QA-aanbevelingen met eigenaren en deadlines
3. Stel de juiste vragen: niet alleen 'hoe staat het ervoor?' maar 'wat weten we niet?'
4. Borg eigenaarschap van benefits op bestuursniveau; benefits realisatie is een lijnverantwoordelijkheid
5. Eis realistische businesscases met kwantitatieve benefits en onafhankelijke validatie
6. Begrijp de verschillen in financieel toezicht tussen waterval- en Agile-projecten
7. Bevorder een cultuur van transparantie en open escalatie
8. Onderschrijf Agile adoptie en creëer de culturele voorwaarden: psychologische veiligheid en continue leerbereidheid

QA kost een fractie van het projectbudget. Het maakt het verschil tussen bijsturen en afschrijven. Succesvolle project assurance wordt niet gemeten in het aantal bevindingen. Het wordt gemeten in gerealiseerde projectdoelstellingen.

Bijlage A: Overzicht relevante standaarden en raamwerken

Raamwerk	Uitgever	Relevantie voor QA
PRINCE2	AXELOS / PeopleCert	Procesgebaseerd projectmanagement; ingebouwde quality review-technieken
PMBOK (7e ed.)	PMI	Principegericht raamwerk, breed gedragen als standaard
MSP (5e ed.)	AXELOS / PeopleCert	Programmamanagement, benefits management, expliciet assurance-thema
COBIT 2019	ISACA	IT-governance raamwerk, toepasbaar op digitale transformatieprogramma's
Agile / SAFe	Scaled Agile Inc.	Iteratieve methoden, ingebouwde kwaliteitsborging, aangepaste QA-benadering
ISO 21503:2022	ISO	Internationale standaard voor programmamanagement en programme assurance
PMI Standard for Program Management (5e editie)	PMI	Program QA, governance en benefits management
GIAS (2024)	The Institute of Internal Auditors	Normatief kader voor internal audit; eisen aan assurance- en adviesdiensten
PRINCE2 (7e ed.)	PeopleCert	Procesgebaseerd projectmanagement; 7e editie (2023) integreert agile-principes
CGC 2022	Monitoring Commissie CGC	Nederlandse Corporate Governance Code; VOR en rol auditfunctie (principe 1.2)

Bronnen

1. Flyvbjerg, B. (2021). Top Ten Behavioral Biases in Project Management. Project Management Journal, 52(6), 531-546. DOI: 10.1177/87569728211049046.
2. Kahneman, D. & Tversky, A. (1979). Prospect Theory. Econometrica, 47(2), 263-291.
3. Flyvbjerg, B. (Ed.) (2017). The Oxford Handbook of Megaproject Management. Oxford University Press. ISBN: 978-0-19-873224-2.
4. Janis, I.L. (1972). Victims of Groupthink. Houghton Mifflin. ISBN: 978-0-395-14002-4.
5. Arkes, H.R. & Blumer, C. (1985). The Psychology of Sunk Cost. Organizational Behavior and Human Decision Processes, 35(1), 124-140.
6. Commissie-Elias (2014). Eindrapport: Grip op ICT. Tweede Kamer, vergaderjaar 2013-2014, 33 326, nr. 5.
7. Flyvbjerg, B. & Bester, D.W. (2021). The Cost-Benefit Fallacy. Journal of Benefit-Cost Analysis, 12(3), 395-419.
8. UK National Audit Office (2020). Lessons learned from major programmes. HC 960, Session 2019-2021.
9. UK National Audit Office (2024). Lessons learned: Delivering value from government investment in major projects. HC 554, Session 2023-24.
10. ISO (2022). ISO 21503:2022 Guidance on programme management.
11. PMI (2024). The Standard for Program Management, 5th Edition. ISBN: 978-1-62825-814-1.
12. PMI (2021). PMBOK Guide, 7th Edition. ISBN: 978-1-62825-664-2.
13. AXELOS (2020). Managing Successful Programmes (MSP), 5th Edition. ISBN: 978-0-11-331676-2. Rechten overgedragen aan PeopleCert in 2021 (PeopleCert ISBN: 978-9-92560-044-1).
14. ISACA (2018). COBIT 2019 Framework: Governance and Management Objectives. ISBN: 978-1-60420-764-4.
15. IIA (2024). Global Internal Audit Standards (GIAS). Van kracht per 9 januari 2025. theiia.org/standards
16. Standish Group (2020). CHAOS Report 2020.
17. Chartered IIA (2024). Auditing What Matters: Patterns from Recent Project Assurance Reviews.
18. IIA (2020). The IIA's Three Lines Model: An Update of the Three Lines of Defense. Position paper, juli 2020. theiia.org
19. Flyvbjerg, B. (2023). How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project. Macmillan. ISBN: 978-1-250-19665-1.
20. Monitoring Commissie Corporate Governance Code (2022). Nederlandse Corporate Governance Code 2022. Den Haag. commissiecorporategovernance.nl
21. AXELOS (2015). PRINCE2 Agile. TSO. ISBN: 978-0-11-331151-4.
22. Kotter, J.P. (1996). Leading Change. Harvard Business Review Press. ISBN: 978-0-87584-747-4.
23. Adviescollege ICT-toetsing (AcICT) (2024). Instellingsbesluit AcICT. Staatscourant 2024. acict.nl