Verborgen kosten in IT projecten

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…

Standish Group

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.

Onderzoeksscope

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.

Waterval implementatie

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.

Agile implementatie

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.

Stanmets

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.

Werkelijke kosten inclusief verborgen kosten

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:

1. Rechtvaardiging
2. Requirements en ontwerp
3. Ontwikkeling en testen
4. Implementatie en opleiden

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:

• Vergaderingen: Dit zijn vergaderingen of gesprekken over de voortgang, discussies, e.d. als reguliere overleggen, maar daarnaast ook directie of stuurgroepen op de hoogte blijven houden.
  
  
• Management: Hierin worden de kosten gerekend over algemeen projectmanagement en daarin zit ook management specifiek richting de softwareleveranciers of verandermanagement.
  
  
• Gebruikersinput en terugkoppeling: Hierin worden de kosten gerekend om de gebruikers te laten aanhaken bij het project. Zij bepalen mede voor een groot deel het succes van de totale acceptatie en hebben daardoor een belangrijke rol in elk project.
  
  
• Overig: Hierin worden alle overige kosten ondergebracht die niet direct toe te wijzen zijn aan één van de andere categorieën. Te denken valt aan extra analyse werk voor het ontwerpen of specificeren van requirements.

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.

Respondenten

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.

Conclusie

• In beide type omgevingen zitten veel van de verborgen kosten in vergaderingen. In de traditionele omgeving een factor 12,7 meer dan de agile omgeving.
• Het gebrek aan feitenmateriaal waarover gesproken kan worden, is in beide omgevingen een hoofdreden voor de vele vergaderingen.
• Testen en acceptatie is een ondergeschoven activiteit, wat resulteert in extra hoge verborgen kosten in beide omgevingen.
• Agile is niet alleen qua doorlooptijd en acceptatie beter, maar ook de verborgen kosten kunnen beter worden gemanaged.
• Vanuit de respondenten is er een gelijkmatige verdeling tussen schattingen boven en onder het daadwerkelijk percentage.

Testen en acceptatie is een ondergeschoven activiteit, wat resulteert in extra hoge verborgen kosten in beide omgevingen.

Aanbeveling

• Knip projecten op in kleinere onderdelen, zodat het totaal beter beheersbaar is. Op basis van dit onderzoek zien we niet alleen een meer beheersbaar project, maar ook de acceptatie onder de gebruikers is hoger.
• Betrek gebruikers in het testen en accepteren van IT, omdat zij de inhoudelijke kennis over het dagelijkse werk hebben. Daarnaast laat dit onderzoek zien dat hiermee veel (verborgen) kosten bespaard kunnen blijven.
• Gebruik gereedschappen als TestMonitor. Het resultaat hiervan is dat tijdens vergaderingen over feitenmateriaal wordt beschikt en met het centraal issuemanagement ook alle stakeholders vanuit dezelfde “waarheid” de activiteiten uitvoeren.