De afgelopen jaren zijn er vele onderzoeken gepubliceerd waarin de algemene tendens was dat de meeste softwarerealisatieprojecten nog steeds mislukken. Het meest bekende onderzoek op dit gebied is het Chaos-rapport van de Standish Group. In de 2009-editie van dit rapport staat dat slechts 32 procent van de softwareprojecten gestart in 2008 succesvol was (op tijd, binnen budget en de afgesproken functionaliteit geleverd). Hieruit valt af te leiden dat 68 procent van de projecten dus niet succesvol zijn geweest.
Een aantal oorzaken zijn inmiddels genoemd: te weinig aandacht voor requirements, te weinig betrokkenheid vanuit de opdrachtgever, te weinig ‘human skills' bij de projectmanager, etc. De belangrijkste reden is echter het feit dat er bij de start van de meeste projecten wordt begroot op basis van onrealistische verwachtingen. Een begroting die is gebaseerd op onrealistische verwachtingen leidt vrijwel altijd tot grote problemen in het project. In dit artikel wordt beschreven hoe men kan toetsen welke verwachtingen realistisch zijn, waarom de meeste projecten toch van start gaan met een begroting gebaseerd op onrealistische verwachtingen en waarom juist dit soort projecten vaker falen dan slagen.
Anno 2009 worden de meeste softwarerealisatieprojecten nog steeds eenzijdig begroot door middel van een zogenaamde expertbegroting. Eén of een aantal experts bekijken de specificaties van het te realiseren systeem en bepalen hoeveel uren hieraan besteed zullen gaan worden. Uit onderzoek blijkt echter dat de expertbegroting meestal geen realistische begroting is. Experts zijn ook bij uitstek subjectief in hun oordeel, vergeten nog wel eens wat activiteiten en denken vaak onterecht dat organisaties leren van fouten die in eerdere projecten zijn gemaakt. Volgens McConnell kan een expertbegroting daarom wel 30 procent te optimistisch zijn. Daar komt nog bij dat de doorlooptijd van een project (door verschillende goeroes op het gebied van ‘software estimation' beschouwd als één van de belangrijkste 'cost drivers' voor een begroting) vaak niet wordt begroot maar wordt opgelegd. Als we uitgaan van het volgende verband, onder andere gepubliceerd door een van de toonaangevende metricsgoeroes op deze aardbol: Larry Putnam, dan zien we dat de begroting in feite een directe resultante is van de gekozen doorlooptijd. Volgens Putnam gebeurt dit zelfs met de volgende formule:
Dit effect wordt in de volgende figuur weergegeven. Voor ieder project is er een aantal uren/ doorlooptijd-combinatie mogelijk (bij dezelfde omvang en productiviteit). Er is echter een ‘onmogelijke zone' waarin de doorlooptijd te kort is om het project uit te kunnen voeren en er is een ‘onpraktische zone' waarbij de begrote doorlooptijd van het project zo lang is dat men weinig waarde meer hecht aan de uitkomst van het project.
Dit houdt in dat de gekozen doorlooptijd voor een project bijzonder belangrijk is en dat het aantal benodigde uren erg afhankelijk is van deze doorlooptijd. Volgens Putnam kan een doorlooptijd van één maand minder er zo maar toe leiden dat het aantal benodigde uren met 50 procent toeneemt. Dit komt doordat er dan met een groter team gewerkt moet worden en dat iedere extra persoon in een team de totale productiviteit (bijvoorbeeld gemeten in het aantal uren dat gemiddeld benodigd is om een functiepunt te realiseren) doen afnemen.
In de praktijk zal de doorlooptijd eerder te krap dan te ruim worden gekozen (de begroting is immers gebaseerd op de optimistische expertbegroting), wat ertoe leidt dat veel softwareprojecten al direct vanaf de start gedoemd zijn te mislukken. Druk vanuit de opdrachtgever is hierbij de meest voorkomende oorzaak. Soms is het belangrijk om een bepaalde ‘time-to-market' te halen, maar in sommige gevallen wordt er ook druk op de doorlooptijd van een project gezet zonder dat daar een goede reden voor is. Het resultaat is dat men gewoon te weinig uren begroot voor de doorlooptijd die is gesteld. Ook in het geval dat een bepaalde doorlooptijd gehaald moet worden, is het zaak om een realistische schatting te maken van de teamomvang en het benodigde aantal uren.
Optimistische begrotingen
Als we ervan uitgaan dat de meeste softwareprojecten van start gaan onder onrealistische verwachtingen (te krappe doorlooptijd, begroot door middel van een gemiddeld 30 procent te optimistische expertbegroting), dan ligt het erg voor de hand dat een gemiddeld project in de problemen komt. Helaas blijken de standaard reacties van de gemiddelde projectleider (bijvoorbeeld het toevoegen van nieuwe medewerkers aan het project) het project meestal wel veel duurder te maken en maar weinig tijdswinst op te leveren. Dit komt onder andere door het creëren van extra communicatiepaden, het inwerken van de nieuwe medewerkers (gaat ten koste van de productiviteit van iemand anders), etc. De enige echt effectieve methode, het terugbrengen van de op te leveren functionaliteit naar een realistische omvang, wordt helaas vrijwel nooit toegepast.
Hoe dan wel? De beste methode om een realistische begroting te maken is gebaseerd op het opstellen van een methodische begroting naast het uitvoeren van de expertbegroting. Met een methodische begroting bedoel ik dat de volgende stappen moeten worden uitgevoerd:
1) Het meten van de omvang van de te realiseren software. Dit kan door het toepassen van een ISO gecertificeerde (dus objectieve, herhaalbare en verifieerbare) methodiek zoals NESMA of IFPUG-functiepuntanalyse of de meer accurate en meestal beter toepasbare methode COSMIC. Het resultaat is de functionele omvang in (COSMIC)-functiepunten.
2) Het vermenigvuldigen van de omvang met een realistisch productiviteitscijfer. Dit productiviteitscijfer, door de International Software Benchmarking Standards Group (ISBSG) aangeduid als PDR (Project Delivery Rate) wordt uitgedrukt in uur/functiepunt (NESMA/IFPUG) of uur/COSMIC-functiepunt (COSMIC). De meest realistische productiviteitscijfers zijn die zijn gebaseerd op de eigen ervaringscijfers van de organisatie zelf. Organisaties die deze ervaringscijfers niet hebben, kunnen echter eenvoudig (en goedkoop) de ISBSG-database aanschaffen, waarin de projectgegevens en productiviteitscijfers van meer dan vijfduizend projecten zijn opgenomen. Het grote voordeel van deze database is dat men al de data in Microsoft Excel krijgt opgeleverd en dus zelf analyses kan gaan maken om op deze manier de voor het betreffende project meest realistische productiviteit en doorlooptijd kan vaststellen.
3) Het gebruik van tools (zoals QSM SLIM of Galorath SEER-SEM om de begroting te tunen op zaken zoals gewenste doorlooptijd, maximale teamomvang, minimaal gewenst kwaliteitsniveau, totale kosten.
Niet alle organisaties hebben de beschikking hebben over dit soort tools. Het is echter al een goed startpunt om de eerste twee stappen uit te voeren om een indicatie te krijgen van de realiteitszin van de expertbegroting. Zie voor een voorbeeld het kader.
Voorbeeld
Een organisatie wil een nieuw systeem gaan bouwen in Java. De requirements staan op papier en een expert heeft een begroting opgesteld van vijfduizend uur voor functioneel ontwerp, bouw, systeemtest en acceptatietest. Volgens de expert moet het project in tien maanden afgerond kunnen worden. De opdrachtgever heeft op dat moment nog geen idee of deze begroting realistisch is of deze in lijn ligt met ervaringscijfers en of deze marktconform is.
Om meer zekerheid te krijgen laat men door een onafhankelijke partij een functiepuntanalyse uitvoeren op de documentatie. Uit deze analyse komt een omvang van duizend functiepunten. Dit betekent dat de expertbegroting neerkomt op 5,0 uur/functiepunt.
Als in de ISBSG-database wordt geselecteerd op Java, dan blijkt dat het marktgemiddelde (de mediaan) 9,4 uur/FP is bij een verwachtte doorlooptijd van veertien maanden. De methodische begroting zou daarom neerkomen op 1000 * 9,4 = 9400 uur met een doorlooptijd van veertien maanden.
De ISBSG geeft aan dat de beste 25 procent van de projecten een betere PDR dan 7,3 uur/FP heeft gerealiseerd. De door de expert afgegeven begroting van 5,0 uur/FP is dus in dit licht zeer optimistisch en vermoedelijk zeer onrealistisch te noemen.
Deze organisatie zou er goed aan doen om haar verwachtingen en dus haar begroting bij te stellen.
Heel herkenbaar. Begint al met de definitie van projectsucces. Sturen op kosten, tijd en kwaliteit is lastig als je niet in staat bent een relatie te leggen met de baten (de benefits) van het project. Vooraf schatten is één, tijdens een project bijsturen naar aanleiding van veranderde omstandigheden is net zo belangrijk. In een aantal gevallen pleit ik dan ook voor het integraal sturen op baten en kosten/tijd/kwaliteit van een project of programma. Als de projectmanager alleen voor de uitvoering verantwoordelijk is – zoals in het artikel beschreven – en niet voor de exploitatie van het resultaat dat die uitvoering gaat opleveren, ligt daar een rol voor de opdrachtgever of bijvoorbeeld een sales/marketing verantwoordelijke. Dan is een project succesvol als “het product dat met het project in de markt wordt gezet succesvol is”, d.w.z. dat de exploitatieprognose wordt gehaald. Voor welke ICT-projecten zou dat een heel andere kijk op succes geven?
Jan Bloem is senior organisatie-adviseur en gespecialiseerd in projectenbesturing.
Goed om deze inmiddels klassiek geworden wijsheid weer eens in het spotlicht te zetten. Inderdaad een expertbegroting kan wel 30 procent te optimistisch zijn. Dus doe ik er standaard 30% bij als ik niet de tijd heb om de begroting diepgaand door te nemen. Bij een FPA/PDR kan dit verschil soms nog meer zijn. Elke klassiek geschoolde PM weet het. Maar veel accountmanagers, projectleiders die in de internetwereld groot zijn geworden en vooral opdrachtgevers weten het nog niet.
Dit artikel zou (met licht gewijzigde inhoud *) verspreid moeten worden onder algemeen managers en accountmanagers.
* De toevoegingen van Jan Bloem zijn ook heel zinvol.