Fact-based Project Quality Assurance kun je niet alleen

Inleiding

Uit recent onderzoek blijkt dat slechts 20 procent van de projecten binnen tijd en budget met succes wordt afgerond ([Stan13], [Stan14]). In de literatuur worden hiervoor verschillende oorzaken en best practices gegeven. KPMG ([Donk12]) noemt bijvoorbeeld deze drie hoofdoorzaken:

1. Complexiteit en risico’s van projecten worden geregeld onderschat, opbrengsten, tijdslijnen en eigen kunnen worden overschat.
2. Er wordt nog vaak te licht gedacht over projectmanagement.
3. Organisaties leggen de focus van hun projectmanagement vaak meer op verantwoording dan op sturing.

Project Quality Assurance wordt dikwijls gezien als een effectief en efficiënt middel om de slagingskans van een project te vergroten. Organisaties met een hoge succesgraad voor projecten rapporteren vaker de periodieke inzet van QA. Bijna de helft van de organisaties maakt hier gebruik van. Voor de organisaties die QA nog niet structureel inzetten, ligt hier een kans. Immers, door QA niet alleen achteraf maar ook vooraf en tijdens projecten in te zetten, kan men de bijdrage van projecten aan de realisatie van de strategie vergroten. Ondanks dat bijna de helft van de organisaties gebruikmaakt van QA, lijkt de slagingskans achter te blijven.

Een mogelijke oorzaak is dat in de meeste organisaties deliverables vaak in het licht van een procesaudit worden beoordeeld (‘is document aanwezig, ja/nee?’) en in mindere mate op hun inhoud. Daarnaast zien we ook dat de kwaliteitswaarborging plaatsvindt binnen het Project Management Office (PMO), dat zelden onafhankelijk is. Ook zien we dat PMO’s steeds professioneler worden. Hierdoor kan het zijn dat bepaalde project controls effectief blijken te zijn maar dat de waarde hiervan laag is. Dit wordt onderschreven door twee voorbeelden uit de praktijk:

1. Er is een risk log aanwezig, maar als je de risicoverantwoordelijke binnen het PMO spreekt en vraagt naar de belangrijkste risico’s, zal hij antwoorden dat hij alleen verantwoordelijk is voor de risk log en niet voor de interpretatie ervan.
2. De configuratie van het grootboek lijkt goed te zijn voor de paar testen die zijn gepland, terwijl de overige grootboekaccounts niet allemaal zo zijn geconfigureerd als in de documentatie is ontworpen.

In beide situaties lijken de project controls te werken maar de effectiviteit hiervan valt te betwijfelen: operatie geslaagd, patiënt overleden.

De bouwkundig adviseur

Project Quality Assurance kan worden vergeleken met de inzet van een bouwkundig adviseur bij het bouwen van een huis. Wie kent het niet: er is een offerte gemaakt met een aannemer om een huis te laten verbouwen, maar het eindresultaat is niet zoals verwacht; de aannemer is er echter van overtuigd dat wat hij opgeleverd heeft, voldoet aan de overeengekomen specificaties. Er is een conflict, maar wie heeft er gelijk? Aan een dergelijk conflict kunnen verschillende oorzaken ten grondslag liggen:

1. Is de offerte duidelijk genoeg, bevat deze de juiste algemene voorwaarden, garanties, voldoende gedetailleerde specificaties, boeteclausules et cetera?
2. Zijn de materialen die zijn gebruikt conform het bestek? Is de bouw gefocust op de korte termijn of heeft de aannemer oog gehad voor het feit dat het gebouw minimaal dertig jaar mee moet gaan?
3. Had de opdrachtgever niet beter moeten controleren voor de oplevering, of misschien wel tijdens de oplevering? Door elke week even langs te lopen had hij de aannemer tijdig kunnen wijzen op zaken die niet in orde waren.
4. Opdrachtgever en opdrachtnemer hebben een tegenstrijdig belang: de opdrachtgever wil zo veel mogelijk waar voor zijn geld, de opdrachtnemer wil een zo hoog mogelijke marge.

De opdrachtgever is vaak geen materiedeskundige en is daardoor meestal niet in staat dit soort diepgaande onderzoeken te doen. Hij beoordeeld de opdracht op basis van zijn eigen context, achtergrond en ervaring. Daarnaast verbouwt een mens één, hooguit twee keer in zijn leven een huis, dus hoe kun je dan weten wat de valkuilen zijn en daar proactief op sturen? In veel gevallen is het dus verstandig een bouwkundig adviseur in te huren om de kwaliteit van de bouw te verbeteren. Een bouwkundig adviseur inzetten voor ERP-projecten gebeurt door het inzetten van een Project Quality Assurance-rol binnen een programma. Dit wordt vaak uitgevoerd door een hiertoe opgeleide en gecertificeerde (IT-)auditor.

De toegevoegde waarde van een bouwkundig adviseur hangt sterk af van het contract dat afgesloten is:

• Zo’n adviseur kan af en toe eens op de bouwplaats rondlopen en hier en daar aangeven dat zaken niet conform de standaarden zijn. In dit geval stelt de adviseur bijvoorbeeld vast dat de kozijnen netjes zijn geplaatst en geschilderd, maar zegt niet of deze op de juiste plaats staan en of de materiaalkeuze conform het bestek is. De toegevoegde waarde is dan relatief laag.
• Hij voegt meer waarde toe als hij niet alleen kijkt naar wat er is gebouwd, maar ook naar de vraag of datgene wat is gebouwd, wel is afgesproken (juiste kwaliteit hout), of er niets is vergeten (bijvoorbeeld internetaansluitingen), of er iets anders is opgeleverd dan is afgesproken (rieten dak in plaats van dakpannen) en of het toekomstbestendig is (op punten voldoet de elektra niet aan de daarvoor bestaande certificering). Dit soort zaken kunnen alleen worden geïdentificeerd als de bouwkundig adviseur voldoende tijd heeft om grondig door bestek en bouwplannen heen te lopen en een externe specialist kan inschakelen als hij de kennis zelf niet heeft of twijfelt.

De timing van het inhuren van deze bouwkundig adviseur is ook essentieel. Hoe eerder in het proces de adviseur meekijkt, des te eerder er kan worden bijgestuurd en hoe groter de kans dat grote kostenposten in de toekomst kunnen worden voorkomen.

Een bouwkundig adviseur huurt specialisten in om de kwaliteit van het bouwwerk te beoordelen (wist u bijvoorbeeld dat er een NEN 1010-certificering is voor de kwaliteit van de elektra?). Een bouwkundig adviseur zal altijd een elektricien inhuren om het bouwwerk volgens deze NEN-certificering te laten toetsen.

Dit voorbeeld is een analogie met ICT-projecten. Zoals eerder aangegeven neemt de slagingskans toe als een bouwkundig expert wordt ingehuurd. Deze slagingskans wordt nog groter als de bouwkundig adviseur niet alleen oppervlakkig meekijkt maar feitelijk vaststelt wat de kwaliteit van de bouw is, gebaseerd op afspraken die de opdrachtgever met de aannemer heeft gemaakt. Hoe eerder deze expert wordt ingehuurd, des te lager de herstelkosten zijn. Door de benodigde detailkennis zal de bouwkundig adviseur dit niet alleen kunnen en zal hij specialisten moeten inhuren.

Fact-based Project Quality Assurance

Impliciet spreekt het voor zich dat een project een hoger risico met zich meebrengt dan een reguliere lijnactiviteit. Een project wordt begrensd door tijd en budget en is mede afhankelijk van goede multidisciplinaire samenwerking. Daarnaast geldt, ondanks de aanwezigheid van een projectplan, dat de afgelegde weg vaak anders is dan op voorhand is beschreven. Het zal voor u als lezer geen verrassing zijn dat met name grotere (ERP-gerelateerde) projecten dikwijls niet binnen – of zelfs ver buiten – planning en budget worden opgeleverd. Ook het resultaat wijkt vaak af van de vooraf gestelde doelstellingen of verwachtingen. Onderzoek bevestigt dit ([Koza07]). Grote ERP-implementaties lopen veel meer kans om niet te slagen dan mensen verwachten. In de laatste decennia blijkt 25 procent van de projecten te slagen en 25 procent te mislukken. Voor de overige 50 procent van de projecten wordt het beoogde resultaat deels gehaald. Dit wordt bevestigt door de Standish Group, die vanaf 1994 hier onderzoek naar heeft gedaan ([Stan94], [Stan13], [Stan14]). Projecten met een omvang kleiner dan een miljoen euro kennen een succespercentage van 76 procent, terwijl boven de miljoen dit percentage daalt naar 10 procent ([Stan13]). KPMG heeft in 2012 een groot onderzoek gedaan naar projecten en programma’s ([Donk12]). Een van de vijf conclusies was dat organisaties die een hoge succesgraad voor projecten rapporteerden, aangaven Project Quality Assurance periodiek in te zetten ([Donk12]).

Er is de laatste jaren al veel geschreven over Project Quality Assurance ([Vale12], [Meul01]). Hierbij wordt generiek gesteld dat Project Quality Assurance tot doel heeft om:

1. te bewaken dat er geen goal reduction plaatsvindt;
2. te bewaken dat het eindresultaat voldoende kwaliteit heeft;
3. te bewaken dat het juiste niveau van interne beheersing wordt bereikt;
4. onafhankelijk te adviseren aan de projectverantwoordelijken.

Hierna wordt beschreven hoe deze doelen feitelijk kunnen worden getoetst.

1 Bewaken dat er geen goal reduction plaatsvindt

Als de tijdlijnen van het project in gevaar komen, is het aanpassen van de scope een van de mogelijkheden om binnen de gestelde tijdlijnen live te gaan. Normaal gezien gebeurt dit door middel van een changeproces en zal bij een zekere grootte akkoord gevraagd moeten worden van de stuurgroep opdat belanghebbenden op de hoogte zijn en deze scopewijziging goedkeuren.

In de praktijk gebeurt dit vaak niet en probeert de projectmanager of de leverancier (system integrator) te beknibbelen op de kwaliteit en/of de scope van de implementatie. Vaak zijn deze wijzigingen niet zichtbaar in gangbare controles omdat dikwijls de scope van de testscripts wordt aangepast aan de aangepaste scope. Door een goede lijncontrole uit te voeren kan worden vastgesteld of de overeengekomen scope daadwerkelijk kwalitatief wordt opgeleverd. Een handig begin is om de processtappen te nummeren; ook elke andere kapstok kan worden gebruikt. De kunst is nu om voor elk van deze genummerde stappen vast te stellen of deze functionaliteit is beschreven (is er bijvoorbeeld een procesbeschrijving aanwezig?), of er functionele en technische documentatie is, en of deze functionaliteit ook daadwerkelijk is geconfigureerd, (positief en negatief) is getest (via unit-, integratie- en acceptatietesten) en is getraind aan de eindgebruikers. Een handig hulpmiddel hiervoor is de template in figuur 1; stel per cel vast of en waar deze controle aanwezig is.

Figuur 1. Template voor het toetsen van volledigheid. [Klik op de afbeelding voor een grotere afbeelding]

Als de auditor de volledigheid van de oplevering heeft vastgesteld, is de vervolgstap om vast te stellen of de kwaliteit van voldoende niveau is.

2 Bewaken dat het eindresultaat voldoende kwaliteit heeft

In dit artikel worden drie voorbeelden genoemd (niet limitatief) om feitelijk vast te stellen dat de oplossing van voldoende kwaliteit is.

A Kwaliteit van het testproces vaststellen

In de praktijk zien we vaak dat het testen van opzet, bestaan en werking van de project controls rondom het testen niet representatief is voor de daadwerkelijk uitgevoerde testactiviteiten. Hoe vaak gebeurt het niet dat heel ambitieus wordt bedacht dat integratietesten met eindgebruikersrollen gedaan moeten worden, dat de voor de belangrijkste landen essentiële stromen binnen het systeem (inclusief interfaces en master data) getest moeten worden en dat deze testscripts ook afgetekend moeten worden door een eindgebruiker of key user. De (IT-)auditor beoordeelt vervolgens of de testscripts de scope afdekken, of er eindgebruikersprofielen worden genoemd in de testscripts, of de testscripts van voldoende kwaliteit zijn en of de testscripts zijn afgetekend (en issues zijn gelogd). Maar wat zegt dit over de daadwerkelijke testactiviteiten binnen het systeem? Oké, er staat een handtekening op het testscript, dus in principe kun je zeggen dat de eigenaar akkoord is. Maar is dit voldoende?

Het uiteindelijke doel van testen is om vast te stellen dat het systeem juist en volledig is geconfigureerd. Deze gegevens zijn allemaal in het testsysteem aanwezig. Door een download te maken van de relevante tabellen en deze vervolgens te analyseren kun je de projectmanager en stuurgroep feitelijk en gegevensgericht inzicht geven in de effectiviteit van het testen:

• Hoeveel testen zijn er uitgevoerd in de unit-, integratie- of acceptatietesten?
• Zijn hierbij alle inkoop-, verkoop- en andere relevante stromen getest, voor alle bedrijfsonderdelen en voor alle landen (en voor welke niet)?
• Zijn binnen deze stromen alle uitzonderingen getest?
• Wie heeft deze testen uitgevoerd? De key user, de eindgebruiker of toch de programmeur omdat het project in tijdsnood zat?

Onze ervaring leert dat we vaak de volgende conclusies kunnen trekken:

• Het testen is kwalitatief minder uitgevoerd dan het afgetekende testscript aangeeft: testen zijn voor een (beperkte) subset van de scope uitgevoerd.
• Ondanks dat de testscripts aangeven dat er moet worden getest met eindgebruikersrollen, blijkt vaak dat de testen daadwerkelijk door IT- of projectmedewerkers zijn uitgevoerd.

B Kwaliteit van de softwarecode vaststellen

In 2013 geeft [Amor13] al aan dat ondanks dat er veel vooruitgang is geboekt met gestandaardiseerde projectaanpakken zoals Prince2 en MSP, in de praktijk het softwarekwaliteitsaspect vaak onderbelicht blijft als er een te sterke sturing plaatsvindt op tijd en budget. Daarnaast geeft [Amor13] aan dat – als er al naar wordt gekeken – dit vooral vanuit een procesmatig oogpunt plaatsvindt, de feitelijke invulling van de kwaliteitstesten wordt niet verder uitgewerkt. Hierdoor ontstaan er volgens [Amor13] twee risico’s:

1. Wanneer het einde van het project wordt getest, worden fouten vaak te laat in het proces gevonden, waardoor de impact op de einddatum groot is.
2. Het tweede risico is subtieler en wordt ‘technische schuld’ genoemd. Dit betekent dat de software ogenschijnlijk goed werkt, maar onder de motorkap niet op een optimale manier is gerealiseerd. Dat leidt vaak op ongewenste momenten tot problemen.

Dat het schrijven van kwalitatief goede software geen sinecure is en dat het probleem van kwalitatief niet toereikende software nog steeds actueel is, bewijzen programma’s in de media die aantonen dat het niet evident is dat de opgeleverde software aan de eerder gestelde kwaliteitseisen voldoet ([Zemb15]).

Een softwarespecialist kan een aantal feitelijke waarnemingen doen. Ten eerste is er software beschikbaar die de kwaliteit en onderhoudbaarheid van de code feitelijk kan vaststellen. Daarnaast kan deze specialist vaststellen of de opgeleverde documentatie volledig en van voldoende niveau is. Tot slot kan deze specialist vaststellen of de softwarecode voldoet aan internationale standaarden en modulair is opgebouwd, waardoor de software niet alleen schaalbaar is maar ook snel in onderhoud genomen kan worden.

C Readiness van de project-, IT- en gebruikersorganisatie

Een snel en effectief hulpmiddel om de readiness van de project-, IT- en gebruikersorganisatie te achterhalen is een enquête. Door een enquête uit te sturen naar de verschillende stakeholders binnen een programma heb je als auditor op een relatief snelle manier een compleet en feitelijk beeld van verschillende deelaspecten binnen het programma. Deze enquête kan ook worden gebruikt als scopinginstrument of als risicoanalyse om gefocust een project te beoordelen. Daarnaast kunnen de uitkomsten van de enquête bijvoorbeeld worden gebruikt als input in de te voeren gesprekken, als toetsingsinstrument voor de (IT-)auditor of om cultuur en gedrag binnen het project te beoordelen (zie ook [Bekk16] in deze Compact).

Figuur 2. Voorbeeldresultaat van een enquête op selectie van deelgebieden. [Klik op de afbeelding voor een grotere afbeelding]

In figuur 2 is een gedeelte van een bestaande enquête te weergegeven. Hier is duidelijk te zien dat binnen dit project de deelgebieden ‘testen’ en ‘interne controle’ verhoogde aandacht behoeven.

KPMG maakt gebruik van een geautomatiseerde vragenlijst die binnen een audit kan worden gebruikt. De klant kan ook gebruikmaken van deze vragenlijst en enquête. De database bestaat uit een paar honderd vragen op de gebieden project governance, project management, change management, performance management, mensen, technologie en processen en kan worden toegespitst op het onderzoek dat moet worden uitgevoerd. Daarnaast is deze vragenlijst geschikt voor traditionele ‘waterfall’-en Scrum-projecten. Een specialistische module kan worden gebruikt om cultuur en gedrag binnen een project te beoordelen.

Let bij een enquête goed op de communicatie en de omvang van de vragenlijst. Het is aan te bevelen om de projectmanager als sponsor van deze enquête te laten optreden en indien nodig de resultaten anoniem te behandelen om de eerlijkste respons te krijgen. Ook moet de vragenlijst niet te lang zijn en moet deze voor alle stakeholders te begrijpen zijn.

3 Bewaken dat het juiste niveau van interne beheersing wordt bereikt

Vaak constateren wij dat een system integrator het configureren van beheersmaatregelen en logische toegangsbeveiliging niet als hoogste prioriteit binnen een implementatie ziet. Het heeft dan ook de voorkeur om als (IT-)auditor feitelijk te onderzoeken of de maatregelen effectief zijn ontworpen en of deze ook daadwerkelijk conform zijn geconfigureerd.

Er zijn verschillende aspecten waarop kan worden getoetst:

• Applicatiecontroles. Applicatiecontroles zijn beheersmaatregelen die binnen een (ERP-)systeem worden geconfigureerd. De vraag die een IT-auditor zichzelf stelt is: zijn de systeemtechnische controlemaatregelen effectief geconfigureerd? Om deze vraag te beantwoorden kan de auditor een SAP-specialist samen met een interne-controle- (of GRC-) specialist een feitelijk onderzoek laten doen om de juiste configuratie van de key controls vast te stellen. Voorbeelden van vragen die dan worden onderzocht zijn: Is het grootboek geconfigureerd zoals ontworpen? Zijn de juiste rekeningen geblokkeerd voor handmatige boekingen? Zijn de juiste three-way-match-toleranties geconfigureerd? Zijn de verplichte velden juist geconfigureerd? Is het autorisatie- en procuratieregister juist en volledig in het ERP-systeem ingebouwd?
• Logische toegangsbeveiliging en ongewenste functievermengingen. Er zijn in de markt verschillende tools beschikbaar voor het analyseren van de opzet van de logische toegangsbeveiliging en de functiescheidingen binnen een (ERP-)systeem. Hierdoor krijg je feitelijk inzicht in de kwaliteit van de ingerichte functiescheidingen (zoals in figuur 3).

Figuur 3. Overzicht van ingerichte ongewenste functievermenging.

4 Onafhankelijk adviseren aan de projectverantwoordelijken

Het resultaat van een Project Quality Assurance-onderzoek is om de belanghebbende (zoals projectleiding, projectsponsor, stuurgroep en raad van commissarissen) onafhankelijk te kunnen informeren over de kwaliteit van het programma op de voorgenoemde aspecten.

Naast een inhoudelijke beoordeling van de kwaliteit van de project deliverables is het ook mogelijk een feitelijke beoordeling te doen van de project controls zelf. Laten we als voorbeeld het issue-managementproces nemen binnen een project. Het doel van issue management is om gecontroleerd projectissues te registreren, op te lossen en te hertesten. Hierbij kan het helpen om een aantal feitelijke analyses uit te voeren. Natuurlijk rapporteert de projectmanager zelf ook op (een subset van) deze KPI’s. Echter, een onafhankelijke bevestiging, of een diepere analyse van de uitzonderingen en gestructureerd inzicht hierin worden als toegevoegde waarde gezien.

Op het issue-registratiesysteem, het issueregister of het ticketsysteem zouden de volgende analyses kunnen worden uitgevoerd:

• Testvoortgang per domein. Probeer inzichtelijk te krijgen wat de huidige voortgang is van het testproces. Welke testen zijn klaar, afgekeurd of staan nog open om te testen?
• Hoeveel issues (defects) zijn er gelogd op het programma? Wat is de prioriteit van deze issues?
• Wat is de gemiddelde oplostijd van issues, en kijkend naar de trend, hoeveel issues staan al meer dan een aantal dagen open? Wat is hiervan het voorspellende karakter? Welke risico’s heeft dit voor de go-live?
• Work-arounds zijn vaak tijdelijke oplossingen die worden bedacht omdat er onvoldoende tijd beschikbaar is om voor go-live het gewenste resultaat te behalen. Deze work-arounds worden veel gebruikt om kritische issues tijdelijk op te lossen. Dikwijls houdt een projectteam een lijst bij van work-arounds. Even zo vaak is deze lijst van work-around niet aanwezig. In het laatste geval probeer je feitelijk het aantal work-arounds te achterhalen in gesprekken met stakeholders. Analyseer bijvoorbeeld ook eens de issues die gewijzigd zijn van issues met prioriteit 1 naar issues met prioriteit 2. Vaak komt bij deze wijziging een work-around kijken en daarbij is het de vraag of de stakeholders hiervan op de hoogte zijn.

Figuur 4. Voorbeeld van een feitelijke analyse van een ticketsysteem. [Klik op de afbeelding voor een grotere afbeelding]

Conclusie

Zoals in de inleiding aangegeven heeft het uitvoeren van een Project Quality Assurance-onderzoek een positieve impact op het slagen van een project of programma. Toch zie je dat met name projecten groter dan 1 miljoen euro nog steeds vaak niet succesvol zijn, ondanks het PMO dat hiervoor is ingeregeld. In dit artikel is betoogd dat de kwaliteit van een Project Quality Assurance-onderzoek wordt vergroot door feitelijk naar de kwaliteit van project deliverables te kijken om zo naast het PMO onafhankelijke inzichten te kunnen geven in het project. Dit onderzoek kan eenmalig, periodiek of continu (als onderdeel van het programma) plaatsvinden. De voorbeelden die zijn genoemd maken duidelijk dat de IT-auditor dit niet alleen kan. Temeer omdat er naast de genoemde vier soorten aspecten op veel meer gebieden binnen een programma feitelijk onderzoek kan plaatsvinden om vast te stellen hoe het project er écht voor staat. De operatie is dan geslaagd en de patiënt is hopelijk niet overleden. De conclusie is dan al snel getrokken dat een IT-auditor als bouwkundig adviseur dit niet alleen kan.