Quality Assurance op projecten: de onafhankelijke vinger aan de pols voor de stuurgroep
Organisaties draaien steeds meer op projecten. Niet alleen omdat er “meer te doen is”, maar omdat strategische veranderingen tegenwoordig vaak juist via projecten en programma’s worden gerealiseerd. Nieuwe wet- en regelgeving, digitalisering, ketensamenwerking, datagedreven werken, kostenreductie, outsourcing, cybersecurity, nieuwe proposities: in veel organisaties loopt de echte koerswijziging niet via de lijn, maar via tijdelijke veranderinitiatieven.
Dat brengt een risico met zich mee dat ik vaak zie: audit- en risk-specialisten zijn van nature sterk op de ‘ongoing’ kant van de organisatie. De vaste processen, de bestaande controls, de operationele performance. Logisch, want daar is veel data, daar zijn herhaling en routines, en daar liggen de klassieke beheersvraagstukken.
Maar juist daardoor kan de ‘change’ kant onderbelicht blijven. En dat is precies waar veel van de grootste risico’s en waardecreatie samenkomen: in de keuzes die nu worden gemaakt over scope, ontwerp, afhankelijkheden, leveranciers, planning en acceptatie. Als je daarop te laat bijstuurt, is herstel vaak duur, pijnlijk en politiek gevoelig.
Een begrijpelijke reflex in projecten is: de deadline is al krap, we moeten vooruit. Dan kan een QA-rol voelen als een controlerende functie die tempo uit het project haalt. Mits goed ingevuld is het juist het tegenovergestelde. Goede QA is geen rem, maar een versneller: door vroeg scherpte te brengen in scope, besluiten, afhankelijkheden en stuurinformatie voorkom je discussie en herstelwerk later. Het doel is niet om het project “netjes” te maken, maar om te zorgen dat de stuurgroep snel en goed kan sturen, juist als de druk toeneemt.
Projecten mislukken zelden door één grote fout. Het gaat vaker om een stapeling van kleine signalen die te lang blijven liggen: scope die langzaam uitwaaiert, besluiten die niet echt landen, afhankelijkheden die onderschat worden, of risico’s die wel op papier staan maar niet worden beheerst.
Juist daarom zie je steeds vaker een Quality Assurance-rol op projecten. Niet als extra projectlaag, maar als onafhankelijke functie die namens de stuurgroep meekijkt of het project nog steeds beheerst en bestuurbaar is.
Wat bedoelen we met Quality Assurance op projecten?
Quality Assurance (QA) op projecten is een onafhankelijke assurance- en adviesfunctie die rapporteert aan de stuurgroep of opdrachtgever en niet aan de projectmanager. Het doel is simpel en kan o.a. de volgende vragen beantwoorden:
- Is het project zó ingericht dat succes waarschijnlijk is?
- Wordt er aantoonbaar gestuurd op de belangrijkste risico’s, afhankelijkheden en besluiten?
- Is de informatievoorziening richting de stuurgroep volledig, eerlijk en tijdig?
- Worden afwijkingen vroeg gezien en effectief opgevolgd?
QA is dus geen extra PMO en ook geen uitvoerende rol. Het is een governance-gerichte spiegel: scherp op beheersing, transparantie en besluitvorming.
QA versus QC: de verschillen
In de praktijk merken we dat termen soms door elkaar heen lopen. Daarom wordt hieronder nog even stilgestaan bij een belangrijk onderscheid.
Quality Control (QC) zit ín het project
QC is gericht op de kwaliteit van de projectproducten en activiteiten. Denk aan:
- Reviewen van deliverables (ontwerp, requirements, testresultaten).
- Naleving van werkwijzen en standaarden binnen het team.
- Kwaliteitscriteria, acceptatiecriteria, testdekking.
- Proceskwaliteit in de uitvoering (bijvoorbeeld change control, documentatie, sprint discipline).
QC werkt veelal onder verantwoordelijkheid van de projectmanager of binnen het projectteam, soms met een aparte QC lead, afhankelijk van de omvang van het project of programma.
Quality Assurance (QA) staat náást het project en kijkt naar beheersing
QA richt zich niet primair op “is dit document goed”, maar op “is dit project bestuurbaar en onder controle”. Voorbeelden daarvan zijn:
- Is er heldere scope en is scopewijziging expliciet besloten?
- Is de planning realistisch en gebaseerd op aannames die getoetst worden?
- Worden risico’s vertaald naar beheersmaatregelen, owners en opvolging?
- Is er één versie van de waarheid over voortgang, issues en afhankelijkheden?
- Is escalatie tijdig, of blijft men te lang hangen?
Kort gezegd: QC bewaakt de productkwaliteit, QA bewaakt de projectbeheersing en governance.
QA versus 3e-lijns Internal Audit: de verschillen
Tsjonge, wat een functies en begrippen allemaal. Maar toch goed om even in te gaan op het onderscheid tussen het een en het ander. Daarom wordt hieronder ook nog even stilgestaan bij het onderscheid tussen QA en Internal Audit.
Internal audit is breder en vaak hoger gepositioneerd
Derdelijns internal audit kijkt meestal vanuit het bredere organisatieperspectief:
- Governance en control rondom projectportfolio en projectbesturing.
- Naleving van policies, frameworks en besluitvormingsstructuren.
- Effectiviteit van interne beheersing, ook over meerdere projecten heen.
- Lessons learned en structurele verbeteringen.
Internal audit kan ook naar een specifiek project kijken, maar kan daarbij juist de scope verbreden: niet alleen het projectteam kan dan binnen de scope vallen, maar ook de rol van de stuurgroep / het opdrachtgeverschap, de QA-functie, de eventuele rol van de second line, leverancierssturing en de aansluiting op strategische doelen. Heeft Internal Audit die insteek, dan is er sprake van een rolzuivere invulling. De aanbevelingen die daaruit voortkomen, richten zich doorgaans op structurele verbeteringen op organisatieniveau.
In de praktijk zien we echter ook wel dat Internal Audit tijdelijk uit de zuivere derdelijns rol stapt en de QA-rol op zich neemt. Vooral bij de meer betrokken opererende auditfuncties (of de functies die ook al gewend zijn om Risicomanagement erbij te nemen) zien we dat gebeuren.
QA is dichter op de bal en bedoeld om bij te sturen
QA is doorgaans veel meer aanwezig gedurende het project. Deze functie richt zich vooral op het vroegtijdig signaleren van mogelijke knelpunten en het tijdig bijsturen van het project. Daarbij is QA expliciet bedoeld als ondersteuning van de stuurgroep en helpt de stuurgroep haar rol als opdrachtgever goed uit te voeren.
Hoe ziet QA in de praktijk eruit?
Een sterke QA-aanpak is licht genoeg om het project niet te belasten, maar stevig genoeg om echte signalen boven tafel te krijgen. De kunst is om QA zo te organiseren dat het niet bureaucratisch wordt. Een effectieve QA-aanpak is lightweight en risicogericht: korte reviews, scherpe vragen en heldere conclusies op de punten die er echt toe doen. Geen dikke rapporten, geen herhaling van wat het project al doet, en geen micromanagement.
QA houdt het tempo er onder ander in door:
- Alleen te verdiepen als signalen daar aanleiding toe geven.
- Observaties te vertalen naar beslispunten voor de stuurgroep.
- Afspraken concreet te maken (wie doet wat, wanneer, en wat betekent dat voor scope en planning).
- Te zorgen voor één consistent beeld van voortgang en risico’s, zodat er minder ruis en minder statusdiscussie is.
Bij de invulling van QA in de praktijk zien we veelal eenzelfde ritme van werken ontstaan. Daarbij zijn logischerwijs vier belangrijke elementen / fases te onderscheiden.
1) Intake en “control picture”
“Kwaliteit zit aan de voorkant”, die uitspraak geldt ook bij projecten en programma’s. Daarom is het logisch om bij de start van het project al betrokken te zijn en de peilstok te steken in de volgende belangrijke waarborgen voor succes:
- Projectdoel, scope, succescriteria, stakeholders.
- Governance: rollen, mandaten, besluitvorming.
- Belangrijkste risico’s, afhankelijkheden, contracten, leveranciers.
- Baseline: planning, budget, kwaliteit, benefits.
Als output van deze eerste fase kan worden opgeleverd: een korte “control picture” voor de stuurgroep, met de belangrijkste aandachtspunten voor de projectbeheersing.
2) Periodieke health checks
Vervolgens wordt van de QA-functie verwacht dat zij periodieke health checks doet. Bijvoorbeeld maandelijks of per fasegate kan er worden gekeken naar:
- Voortgang versus baseline en trends.
- Risico’s en issues: beweging, ownership, effectiviteit mitigaties.
- Scope control: hoeveel change, wat is besloten, wat sluipt erin.
- Planning realisme: aannames, resources, afhankelijkheden.
- Stuurinformatie: klopt het verhaal, of wordt er gemasseerd.
- Besluitvorming: worden besluiten voorbereid, genomen en uitgevoerd.
Als krachtige, doelgerichte output van deze fase zien we doorgaans één pagina met stoplichten, kernobservaties en concrete acties voor stuurgroep en project.
3) Deep dives op risicogebieden
Als er signalen zijn, kan QA gericht verdiepen, op allerlei specifieke thema’s. Op verzoek van de stuurgroep, of op eigen voordracht. Voorbeelden van onderwerpen waarop een deep dive kan plaatsvinden, zijn:
- Leveranciersperformance en contractmanagement.
- Datamigratie en testaanpak.
- Integratie met operatie en change management.
- Security en privacy-by-design.
- Benefits management en business case.
4) Escalatie en “speak up”
Tenslotte is het cruciaal dat QA de ruimte moet hebben om te escaleren naar de voorzitter van de stuurgroep en/of opdrachtgever als het nodig is, zonder daarbij te kunnen worden belemmerd door de projectmanager.
Wanneer voegt QA het meeste waarde toe?
In de kern dient QA uiteraard waarde toe te voegen aan het project. We zien in de praktijk dat QA vooral effectief is in de volgende situaties:
- Grote programma’s of complexe projecten met meerdere leveranciers.
- Projecten met hoge druk, veel politiek, of kritieke deadlines.
- Transformaties waarbij business, IT en operatie moeten landen.
- Projecten met veel afhankelijkheden of onduidelijke scope.
- Projecten waar de stuurgroep beperkte tijd heeft en toch grip wil.
Afsluiting: de business case van QA
Een QA-functie op een project of programma wordt soms gezien als extra overhead. In de praktijk is het vaak precies het omgekeerde: QA is een relatief kleine investering die helpt om hoge(re) kosten te voorkomen.
De totale kosten van een project zitten immers niet alleen in het budget van het projectteam. Ze zitten ook in:
- Vertraging en doorlooptijdverlenging (met extra inzet van mensen en leveranciers).
- Herstelwerk en rework door te late bijsturing.
- Scope-uitbreiding zonder expliciete besluitvorming.
- Gemiste of uitgestelde benefits.
- Extra risico’s rondom compliance, security, datakwaliteit en reputatie.
- Frictie tussen business en IT doordat verwachtingen niet worden gemanaged.
Juist op die punten kan QA veel waarde toevoegen, omdat het vroegtijdig zichtbaar maakt waar bestuurbaarheid onder druk staat en waar besluitvorming nodig is. Het voorkomt dat de stuurgroep pas ingrijpt als de opties beperkt en de kosten hoog zijn.
Daarom is QA vaak een no-brainer vanuit kostenperspectief: de investering is meestal een fractie van de totale programma-uitgaven, terwijl één tijdige interventie al kan voorkomen dat een project maanden uitloopt of dat er achteraf kostbare hersteltrajecten nodig zijn.
Als je QA goed positioneert (rapporteren aan de stuurgroep, licht georganiseerd, scherp op de echte beheerspunten), dan koop je met relatief weinig middelen iets wat in veel projecten schaars is: vroeg inzicht, betere besluiten en aantoonbaar meer grip.
Heeft u een project of programma dat een goede QA verdient?
Neem contact met ons op voor een vrijblijvend adviesgesprek. Dan verkennen we gezamenlijk de business case voor QA en de manier waarop het in uw organisatie kan worden vormgegeven.
