Succesfactoren herkennen in IT-projectrapportages

Om strategische doelen te blijven realiseren, moeten organisaties zich voortdurend aanpassen aan veranderende omstandigheden. Deze bijstelling vindt veelal projectmatig plaats. Er is veel onderzoek gedaan naar de faal- en succesfactoren van zulke projecten. Projecten verlopen regelmatig niet volgens plan, zowel in het bedrijfsleven als bij de (Rijks)overheid. Dit lijkt niet te veranderen door de jaren heen.

Verantwoordingsrapportages over IT-projecten kunnen een positieve bijdrage leveren aan projectbeheersing. Ze bieden auditors de mogelijkheid om risico’s vroegtijdig te signaleren aan de opdrachtgever, zodat tijdig kan worden bijgestuurd. In dit artikel staat de volgende vraag centraal: hoe kunnen auditors succesfactoren herkennen in verantwoordingsrapportages van IT-projecten, en hoe kan dit bijdragen aan projectsucces? Daarbij is uitgegaan van de veronderstelling dat het identificeren van succesfactoren – in tegenstelling tot faalfactoren, die vaak pas achteraf zichtbaar worden – essentieel is om projecten proactief te sturen richting een succesvol resultaat.

Agile werkwijze en rapportages

Verantwoordingsrapportages zijn traditioneel ingebed in de watervalprojectmethodiek (zoals Prince2) waarbij formele rapportages richting het management een integraal onderdeel vormen van de projectbeheersing. In contrast staat de populaire agile projectfilosofie die formele rapportages aan het management als overbodig beschouwt. Binnen agile zijn teams zelfsturend en leveren zij iteratief werkende producten op. De gedachte is dat directe waardecreatie en frequente oplevering van prioritaire functionaliteit voldoende transparantie bieden. Aanvullende rapportages zijn dan ‘verspilling’.

Hoewel IT-projecten binnen grote hiërarchische organisaties vaak gebruikmaken van een agile ontwikkelmethodiek in de ontwikkelteams, worden de projecten voornamelijk traditioneel hiërarchisch aangestuurd. Deze hybride agile/waterval-projecten kunnen vaak tussentijds de toegevoegde waarde al meten door de kortcyclische releases van delen van het product (agile) én kunnen hierover rapporteren in de verantwoordingsrapportages aan het management (waterval). Hierdoor is in theorie overzicht houden en coördineren eenvoudiger. In praktijk resulteert dit vaak in een moeizame samenwerking tussen de opdrachtgever en de product owner en ambiguïteit over rollen en verantwoordelijkheden.

Succesfactoren identificeren

Succesfactoren zijn geïdentificeerd en gecategoriseerd vanuit de literatuur. Hierbij is gebruikgemaakt van onder andere de Amerikaanse PMBOK Guide, de Europees georiënteerde IPMA Project Excellence Baseline en specifiek op de Rijksoverheid gerichte modellen van Bureau Gateway. Vervolgens zijn semigestructureerde interviews afgenomen bij verschillende interne auditors, CIO-adviseurs en projectexperts ter aanvulling en validatie van de onderkende succesfactoren. Uit dit onderzoek is gebleken dat, om een project te laten slagen, succesfactoren noodzakelijk zijn op vijf dimensies (zie figuur 1). Hierna worden per dimensie de succesfactoren benoemd en kort toegelicht.

 De rapportage

• Transparantie: is er een onafhankelijke appreciatie van de verantwoordingsrapportage, bijvoorbeeld door middel van quality assurance? Zo nee, is op een andere wijze geborgd dat de verantwoordingsrapportages een getrouw beeld van de staat van het project weergeven? Is de opzet van eerdere verantwoordingsrapportages consistent met de huidige opzet, zodat ze vergelijkbaar zijn?
• Frequentie: hoe vaak worden verantwoordingsrapportages opgeleverd? Sluit deze frequentie aan bij het ontwikkelritme van de ontwikkelteams? Worden de verantwoordingsrapportages tijdig verstrekt aan de opdrachtgever?
• Typen indicatoren: bevatten de verantwoordingsrapportages prognoses en eventueel real-time informatie uit dashboards?
• Risicomanagement: bevatten de verantwoordingsrapportages een risicoregister waarin zowel bedreigingen als kansen vanuit verschillende perspectieven worden gerapporteerd?

De opdrachtgever

• Verandermanagement: werken de opdrachtgever en product owner actief aan verandermanagement, bijvoorbeeld door samenwerking met de eindgebruikers?
• Verantwoordelijkheid: is de governance, inclusief de rollen en verantwoordelijkheden in en rond het project eenduidig beschreven?
• Leiderschap: wordt externe expertise ingezet waar nodig? Is de opdrachtgever op de hoogte van de status van het project en spreekt de product owner regelmatig met de opdrachtgever? Stuurt de opdrachtgever bij op basis van de projectstartdocumentatie en verantwoordingsrapportages?

Het team

• Communicatie en samenwerking: is het ontwikkelteam stabiel? Worden deelresultaten tijdig en kwalitatief opgeleverd volgens planning? Is de samenwerking naar tevredenheid? Worden reflectie-instrumenten of coaching ingezet om samen te verbeteren? Is er effectieve communicatie tussen het team, opdrachtgever en andere stakeholders?

De middelen

• Kwaliteit en continue verbetering: wordt de kwaliteit voortdurend gemeten om bij te kunnen sturen? Is er voortgang in het oplossen van kritieke problemen?
• Middelen: is het project zo klein mogelijk gehouden (kortcyclisch) en in fasen gesplitst? Zijn de ontwikkel- en beheerkosten gesplitst? Prioriteert de opdrachtgever op basis van beschikbare middelen (budget en capaciteit)?

Het product

• Waarde: is er een begroting en een verwachting van de toegevoegde waarde van het project (kosten/baten)? Worden relevante kritieke prestatie-indicatoren (KPI’s) gehanteerd die aansluiten bij de projectdoelstellingen?

Projectsucces

In de literatuur wordt onderscheid gemaakt tussen projectsucces en het projectmanagementsucces. Projectsucces wordt behaald als het project meer toegevoegde waarde (financieel of kwalitatief) oplevert voor de betrokkenen, dan het project heeft gekost. Bij projectmanagementsucces blijft het projectproces binnen de kaders van de scope, het budget en de planning. Dit impliceert dat wanneer een project tijdig wordt stopgezet vanwege het niet meer kunnen realiseren van meerwaarde, het project zelf een mislukking zal zijn. Dan is er echter wel sprake van projectmanagementsucces.

In dit artikel hanteren we de volgende definitie van projectsucces: een project is succesvol wanneer het eindresultaat – ondanks eventuele overschrijdingen in tijd of budget – meer waarde toevoegt dan het project heeft gekost. Deze benadering erkent dat absolute beheersing van tijd en geld ondergeschikt kan zijn aan het realiseren van meerwaarde door projectresultaten.

Succesfactoren herkennen

Verantwoordingsrapportages bevatten veelal niet alle indicatoren voor de succesfactoren die noodzakelijk zijn om een IT-project te laten slagen. Een deel is in de projectstartdocumentatie te vinden. Dit gaat bijvoorbeeld om de ‘definition of done’, het afzetten van de toegevoegde waarde van het project ten opzichte van de kosten in een businesscase en eenduidige afspraken over de governance. De auditor kan de succesfactoren in het project herkennen door eerst vanuit de projectstartdocumentatie naar de verantwoordingsrapportages te kijken. Daarna kan de auditor inhoudelijk de indicatoren uit de rapportages te beoordelen en vervolgens als sluitstuk eventueel interviews met interne en externe betrokkenen uitvoeren.

Verband projectstartdocumentatie en verantwoordingsrapportages
Bij de start van het project wordt nagedacht over de bijdrage van het project aan waardecreatie of de organisatiestrategie. Samen met afspraken over de governance dient dit te worden vastgelegd in projectstartdocumentatie. Vervolgens horen de verantwoordingsrapportages de voortgang te rapporteren. In de praktijk is dit verband niet altijd aanwezig. Onduidelijke afspraken of ontbrekende projectstartdocumentatie verergeren dit probleem: zo is het niet duidelijk of het project wel de juiste focus en bijbehorende scope heeft. Hierdoor wordt er mogelijk minder efficiënt met de beschikbare middelen omgegaan.

Als wel wordt gerapporteerd over de focus van het project in de verantwoordingsrapportages, is het eenvoudiger voor de opdrachtgever om bij te sturen. Dit bijsturen kan door middel van het wijzigen van de teamsamenstelling en het inzetten van andere middelen, maar mogelijk ook door het herijken van de projectstartdocumentatie. Kortom, als de auditor geen vastgelegde afspraken in de projectstartdocumentatie kan terugvinden, is scopeverschuiving een relevant risico.

Verantwoordingsrapportages horen consistent, volgens een vooraf afgesproken model, te worden opgesteld

Verantwoordingsrapportages geven handvatten voor bijsturen
Voor het kunnen bijsturen op het project dient de informatie uit de verantwoordingsrapportages relevant te zijn. Daarom kan het nuttig zijn om bij de projectstart afspraken te maken over de doelgroep, de vorm en de inhoud van de rapportages. In de praktijk wordt er vaak operationele informatie gedeeld in de verantwoordingsrapportages, maar dat stelt de opdrachtgever niet in staat om effectief besluiten te nemen.

De verantwoordingsrapportages horen ook consistent, volgens een vooraf afgesproken model, te worden opgesteld. Alleen op die manier kan de opdrachtgever (en de auditor) een trendanalyse doen. Het liefst is het model bij alle projecten hetzelfde, zodat ook onderlinge afhankelijkheden en de context beter inzichtelijk zijn. Ontbreekt consistentie, dan kan dat een signaal zijn van onvoldoende sturing door product owner en opdrachtgever.

Belangrijkste indicatoren in de rapportage: tijd, geld en kwaliteit
Het primaire doel van verantwoordingsrapportages is de verantwoording over de duivelsdriehoek: tijd, geld en kwaliteit. De eerste twee indicatoren zijn eenvoudig te interpreteren. Kwaliteit is moeilijker te meten, maar de eerdergenoemde projectstartdocumentatie kan daar met harde afspraken bij helpen. Deze drie indicatoren laten de uiteindelijke gevolgen van onderliggende problemen in het project zien. Wat die onderliggende problemen daadwerkelijk zijn, zou in een toelichting of in het risicoregister moeten zijn opgenomen.

Secundaire indicatoren in de rapportage: communicatie en samenwerking
Hoewel softe succesfactoren niet zo makkelijk aan een KPI kunnen worden gekoppeld, is het wel van belang om hier aandacht aan te geven in de verantwoordingsrapportages. Belangrijke indicatoren zijn de stabiliteit in het ontwikkelteam en de communicatie met betrokkenen. Dit kan de auditor attenderen op mogelijke risico’s in de samenwerking binnen en buiten het ontwikkelteam.

Agile methodologie kan bijdragen aan snellere risicosignalering
In theorie zou een kortcyclische ontwikkelaanpak kunnen bijdragen aan vroegtijdige risico-identificatie door zowel de opdrachtgever, als product owner en het ontwikkelteam, als de auditor. Als deze methodiek wordt gecombineerd met continue monitoring, bijvoorbeeld in een realtime dashboard, is het eenvoudiger om focus te behouden en bij te sturen waar nodig.

In praktijk blijkt echter dat veel grote hiërarchische organisaties een hybride aanpak hanteren. Hierbij wordt de projectaansturing nog grotendeels volgens de Prince2-methodiek uitgevoerd, terwijl de ontwikkelteams agile werken. Dit wordt met name veroorzaakt door traditionele governance, projectgerichte financiering, en het ontbreken van kennis (‘de taal’) bij de opdrachtgevers. Dit zorgt voor verwarring en soms zelfs voor ineffectieve sturing door de opdrachtgever.

De frequentie van verantwoordingsrapportages kan deze risico’s signaleren aan de auditor. Als de frequentie van de verantwoordingsrapportages niet aansluit bij het ritme van de agile sprints, is er een mismatch tussen de aansturing van en de ontwikkeling in het project. Een zeer positief signaal is als de opdrachtgever aansluit bij de agilerituelen, zoals sprint reviews met demonstraties van opgeleverde functionaliteit. Dit bevordert wederzijds begrip en versterkt de sturingsmogelijkheden.

Verantwoordingsrapportages slechts een deel van het beeld
De verantwoordingsrapportages zijn in praktijk niet altijd bruikbaar voor trendanalyse, bijvoorbeeld doordat de weergave van indicatoren wijzigt of geen eenduidige definitie van indicatoren of vaste sjablonen worden gehanteerd. Op dat moment wordt het appels met peren vergelijken, waardoor trendanalyse moeilijk of zelfs onmogelijk wordt. Daarnaast is de toelichting op de cijfers in de verantwoordingsrapportages vaak niet transparant. Product owners hebben dikwijls een optimistische bias in de rapportages, waardoor je tussen de regels door moet lezen. Een formele quality-assurancefunctie in het project kan bijdragen aan de transparantie. Als laatste kunnen interviews van de auditor met opdrachtgever, product owner en betrokkenen bijdragen aan een betrouwbaarder beeld van de risicofactoren van het IT-project.

Vooral softe factoren zoals verandermanagement, samenwerking en communicatie blijven meestal onderbelicht

Samenvattend

In dit artikel zijn de resultaten opgenomen van het onderzoek naar hoe auditors succesfactoren kunnen herkennen in verantwoordingsrapportages van IT-projecten, met als doel eerder risico’s te signaleren en bij te dragen aan projectsucces. Op basis van literatuurstudie en interviews met auditors en projectexperts zijn vijf dimensies van succesfactoren geïdentificeerd: rapportages, opdrachtgever, team, middelen, product. Elke dimensie kent specifieke indicatoren, zoals waardecreatie, governance, samenwerking en transparantie.

In de praktijk bieden verantwoordingsrapportages niet de informatie om alle elf onderkende indicatoren weer te geven en te kunnen beoordelen. Vooral softe factoren zoals verandermanagement, samenwerking en communicatie blijven meestal onderbelicht. Deze factoren laten zich moeilijk vangen in harde meetwaarden, maar zijn wel cruciaal voor het uiteindelijke projectsucces.

Door rapportages te combineren met informatie uit projectstartdocumentatie en interviews met betrokkenen, kunnen auditors zich een vollediger beeld vormen van de projectstatus en vroegtijdig risico’s signaleren. Daarnaast dragen deze verantwoordingsrapportages, op basis van de onderkende succesfactoren bij aan het vergroten van projectsucces.