Bij het ontwikkelen en implementeren van informatiesystemen heeft elke organisatie te maken met kosten. Bij de start wordt een berekening gemaakt van het budget, al dan niet gebaseerd op een uitgebreide business case. En gedurende het project, wordt dit budget uitgeput. Nadat het informatiesysteem is opgeleverd is de opdrachtgever geïnteresseerd in de finale afrekening van het project. Wat zijn nu de werkelijke kosten ten opzichte van de gebudgetteerde kosten?Your blog post content here…
De Standish Group doet al jaren wereldwijd onderzoek naar het succesvol zijn van IT projecten en als afgeleide hiervan hebben zij een onderzoek uitgevoerd naar de werkelijke kosten van een project inclusief de verborgen kosten (*Standish Group, Money Pit 2015). Daarnaast is deze vraag gesteld op een vakbeurs aan respondenten over wat zij inschatten als % verborgen kosten?
Om te bepalen wanneer projecten op tijd en binnen budget worden opgeleverd, is het van belang om vast te stellen wat dit budget nu daadwerkelijk is. Dit is geen eenvoudig antwoord, omdat er geen standaarden zijn om budgetten te berekenen, wat resulteert in verschillende vormen en inhoud van een gecalculeerd budget. Zelfs over soortgelijke projecten.
Om te bepalen wanneer projecten op tijd en binnen budget worden opgeleverd, is het van belang om vast te stellen wat dit budget nu daadwerkelijk is.
Het onderzoek is uitgevoerd over twee type omgevingen: een traditionele omgeving met een waterval implementatie en een andere in een agile omgeving, waarbij de onderzochte cases gelijk zijn in termen van functionaliteit en aantallen gebruikers. Het doel van beide projecten was het vervangen van het bestaande primaire informatiesysteem.
Het type bedrijf waar de waterval implementatie is toegepast was een decentraal gestuurde grote onderneming, hoge bureaucratie, risicomijdend en langzaam in besluitvorming. De hele implementatie had een doorlooptijd van 4,5 jaar, waarvoor 3 jaar initieel was gepland. Het eerste jaar is gebruikt voor het ontwikkelen van de requirements en het maken van de ontwerpen. De 2,5 jaar daarna zijn gebruikt om het systeem daadwerkelijk te ontwikkelen en een deel daarvan voor quality assurance en gebruikersacceptatietesten. Het duurde vervolgens nog een jaar voordat de gebruikers het systeem accepteerde.
Het type bedrijf waar de agile implementatie is toegepast was ook een decentraal gestuurde grote onderneming met een project doorlooptijd van 2 jaar, waarbij initieel ook 3 jaar gebudgetteerd stond. De eerste drie maanden werden besteed aan de ontwikkeling en het creëren van het basis programma van eisen en de algemene missie. Ondanks een eerste mislukking, werd na zes maanden een werkend basisproduct opgeleverd. Het opvolgende jaar werden kritische toevoegingen uitgeleverd, wat resulteerde in snelle acceptatie door de eindgebruikers.
Eén van de belangrijkste instrumenten die Standish gebruikt voor deze berekeningen is het Standish Metric System, genaamd Stanmets. Als je denkt aan Stanmets, denk aan het bepalen van de prijs van uw huis. Ten eerste zou je kijken naar vergelijkbare verkochte woningen in uw locatie, rekening houdend met het aantal slaapkamers, badkamers, land en alle andere voorwaarden. Daarna kijk je naar de kwaliteit van de bouw en de gekozen bouwonderdelen (cv, isolatie, e.d.). Tot slot breng je al deze elementen bij elkaar om de prijs van uw huis te bepalen. Alle projecten krijgen projectprofielen met 25 basiselementen, die gegevens omvatten als prestaties, vaardigheden, types, methodologieën, industrieën en volwassenheidsniveaus. Deze projectprofielen worden vervolgens gekoppeld aan de Stanmets. De Standish database omvat meer dan 100.000 projecten voor vergelijkingen. De gemiddelde werkelijke kosten per Stanmet voor een groot waterval project is $97 en voor een klein agile project $74.
De werkelijke kosten voor beide cases zijn vastgesteld op basis van daadwerkelijk gebudgetteerde kosten. De verborgen kosten zijn berekend op basis van de Stanmets en niet gebudgetteerde kosten. Voor het traditionele project was het budget vastgesteld op $15 miljoen, de werkelijke kosten waren $30 miljoen en de werkelijke kosten inclusief de verborgen kosten waren $45 miljoen. Voor het agile project was het budget eveneens $15 miljoen, waarbij de werkelijke kosten berekend zijn op $10 miljoen en de werkelijke kosten inclusief de verborgen kosten op $12,5 miljoen. Gemiddelde percentage verborgen kosten op basis van de werkelijke kosten is 37,5%.
Verborgen kosten in een IT project
Om meer helderheid te krijgen in waar nu de verborgen kosten met name zitten zijn de kosten onderverdeeld in vier “klassieke” faseringen:
Voor het agile project spreekt het voor zich dat deze fasering door elkaar loopt.
In de onderstaande grafieken worden beide aanpakken met de uitsplitsing van de verborgen kosten uiteengezet gecategoriseerd naar een viertal hoofdgroepen, omdat daar de grootste “winst” valt te behalen:
In de rechtvaardigingsfase wordt het totale project “verkocht” richting de organisatie. Het is op zich vreemd dat voor de start van een project al kosten gebudgetteerd zouden moeten worden voor een pré startfase, maar in verschillende omgevingen (met name in de overheid) zitten hier dus wel verborgen kosten. Je moet denken aan kosten voor analyse stakeholders, commitment vanuit directie, vergaderingen met gebruikers en leveranciers, etc. De meeste organisaties gebruiken deze fase om de randen van het project te schetsen. Het kostenverschil tussen beide type aanpakken in deze fase is dat een agile project 7,2 keer goedkoper is.
In de requirement en ontwerpfase is het kostenvoordeel van een Agile project over hetzelfde primaire informatiesysteem al 5,6 keer goedkoper. De kostenstijging in deze fase zit voor een traditionele aanpak met name in “nutteloze” vergaderingen. Deze aanpak vraagt voor het specificeren van de requirements, waarna de daadwerkelijke ontwerpen kunnen worden gemaakt. En juist bij het specificeren en ontwerpen krijg je lange discussies met je gebruikers en management.
In de ontwikkeling en testfase zit het grote verschil. Het verschil tussen beide aanpakken is 2,6 keer goedkoper voor de Agile manier, maar ook daar zitten de hoogste verborgen kosten. Bij Agile worden de verborgen kosten met name verdeeld over de categorieën terugkoppeling en betrokkenheid van de eindgebruikers en het managen van de stakeholders. Bij de traditionele aanpak zitten de verborgen kosten met name in “nutteloze” vergaderingen.
In de implementatie en opleidingsfase zitten ook de meeste verborgen kosten in het vergaderen. Het grote verschil tussen beide aanpakken is dat bij de traditionele aanpak een “big bang” aanpak wordt gehanteerd. Dus alle functionaliteit in één keer en bij een Agile aanpak incrementeel. Juist door deze incrementele implementatie is minder tijd (en kosten) noodzakelijk voor opleiding en afstemming (vergaderen) en is de acceptatie van de gebruikers eenvoudiger.
In de vorm van een survey is aan verschillende respondenten op een vakbeurs dezelfde vraag gesteld: “Doe een schatting naar het % verborgen kosten ten opzichte van de werkelijke kosten van een IT project?” In het uitgevoerde survey was er een populatie van 103 respondenten die allemaal een antwoord gegeven hebben op de vraagstelling in de vorm van een percentage. In de onderstaande figuur worden de resultaten weergegeven, gecategoriseerd naar vier groepen.
Van de respondenten heeft 11% een schatting gemaakt in de juiste richting van de verborgen kosten. Opvallend is dat 48% denkt dat de verborgen kosten in deze case onder de 40% ligt en 52% het tegenovergestelde. Een klein detail is dat 11% zelfs denkt dat de verborgen kosten boven de 100% ligt en een gelijk % van de respondenten dat de verborgen kosten onder de 20% ligt.
Testen en acceptatie is een ondergeschoven activiteit, wat resulteert in extra hoge verborgen kosten in beide omgevingen.