We weten allemaal dat veel softwareprojecten falen. Als belangrijke reden wordt vaak genoemd dat de begroting van het project niet realistisch was. De vraag is dan natuurlijk: waarom niet? Waarom wordt er nog zo weinig gebruikt gemaakt van professionals op het gebied van het begroten van projecten? De realiteit is dat er wel professionals zijn, maar dat deze niet of nauwelijks gebruikt worden omdat 'men' denkt dat experts beter kunnen begroten.
Heeft u zich wel eens afgevraagd waarom het in de IT-wereld nog steeds geaccepteerd wordt dat miljoenenprojecten worden begroot door middel van inschattingen van één of meerdere inhoudelijke experts? Uit vele onderzoeken blijkt dat expertbegrotingen meestal (veel) te optimistisch zijn en dit wordt dan ook gezien als één van de belangrijkste faalfactoren van softwarerealisatieprojecten. Het starten van een project op basis van realistische verwachtingen is een zeer belangrijke voorwaarde voor het slagen van een project!
Kun je je voorstellen dat een groot bouwbedrijf het begroten van het bouwen van een nieuw hotel overlaat aan een aantal senior bouwvakkers en metselaars? Binnen de bouwsector is het beroep Cost Engineer een belangrijk beroep en bouwbedrijven zetten gecertificeerde Cost Engineers in om zo goed mogelijk de kosten, doorlooptijden en risico’s van projecten te begroten.
Op de website van de Dutch Association of Cost Engineers site (DACE) staat het volgende te lezen: Cost Engineers leveren onafhankelijke en betrouwbare kostenramingen en kostenbeheersing (project controls) ten behoeve van de ontwikkeling, voorbereiding, uitvoering en beheer en onderhoud van investeringsprojecten. Zij zijn professionele adviseurs, intern of extern, aan projecteigenaren, financiers of aannemers en worden ingeschakeld van de vroegste (front end) tot de laatste projectfase (close out). Zij baseren hun ramingen op de analyse van onder andere scope, planning (schedule), locatiefactoren, life cycle benaderingen en risico’s. Zij hanteren daartoe zowel deterministische als probabilistische berekeningen.
Werkzaamheden zoals geduid door de DACE, worden ook binnen veel it-afdelingen van (grote) Nederlandse bedrijven uitgevoerd, zoals bijvoorbeeld bij de Belastingdienst, ING, Rabobank en diverse ministeries. Ook (grote) softwareleveranciers als Sogeti en Atos hebben aparte afdelingen die alle genoemde werkzaamheden van Cost Engineers uitvoeren. Projecten worden in een vroeg stadium begroot op basis van omvangbepalingmethoden als functiepuntanalyse of COSMIC en vervolgens verwerkt in een methodische begroting door middel van het gebruik van historische projectdata en geavanceerde begrotingstools als SEER-SEM of QSM SLIM. Scenario’s worden uitgerekend, bijvoorbeeld verschillende doorlooptijden of een andere omvang van het ontwikkelteam. Hierbij worden ook de risicomarges in kaart gebracht en kan men bijvoorbeeld beslissen een hoog ‘confidence percentage’ te kiezen voor de begroting.
De medewerkers die deze werkzaamheden in de IT-wereld uitvoeren worden zelden Cost Engineer genoemd of als een Cost Engineer gewaardeerd. De meeste mensen die in dit werkveld actief zijn, stellen zich voor als consultant metrieken, begrotingsanalist of materiedeskundige begroten.
Het gebrek aan goede functiebenamingen voor deze mensen leidt ertoe dat het resultaat van hun werkzaamheden vaak niet op de juiste waarde wordt geschat en dat er daardoor te weinig gebruik wordt gemaakt van de kennis, vaardigheden, data en tools die deze mensen kunnen inzetten om IT-projecten nauwkeurig en goed onderbouwd te begroten. Ik zou daarom graag zien dat Software Cost Engineering als een volwaardig beroep wordt gezien en dat (grote) projecten verplicht door gecertificeerde Software Cost Engineers moeten worden begroot.
De Nederlandse Software Metriekengebruikers Associatie (NESMA) zet zich in Nederland in om de discipline Software Cost Engineering verder vorm te geven en hecht hier in de lange termijn plannen veel waarde aan. Een goed begin is de introductie van de ‘Basis of Estimate’. Dit is een document dat de NESMA ter beschikking stelt en waarin de onderbouwing van een begroting wordt geformaliseerd, als bijlage van de begroting. Het kan echter nog jaren duren voordat er een certificeringsprogramma voor Software Cost Engineers op de markt komt. Tot dat moment daar is, zou ik de mensen die zich bezighouden met dit soort werkzaamheden alvast de tip willen geven om zich waar mogelijk alvast Software Cost Engineer te noemen, zodat een start kan worden gemaakt met het inburgeren van deze term.
Software Cost Engineering is een enorm interessant gebied. Zoals Harold al aangeeft: Als je achteraf meet kun je heel goed berekenen hoeveel uur gemiddeld besteed wordt per *voeg willekeurige eenheid toe*. Als je alle details kent kun je dus van een toekomstig project heel nauwkeurig berekenen wat het gaat kosten.
En daar zit de crux: Als je alles van te voren weet kun je alles heel exact bepalen…….
Hoeveel projecten zijn er ooit in de IT gedaan waar daadwerkelijk uitgevoerd werd wat men van te voren bedacht had (Of anders gezegd: In hoeveel projecten wist men van te voren wat men uiteindelijk aan functionaliteit nodig zou hebben)? En wellicht nog wel belangrijker: Hoeveel geld is er weg gegooid in beschrijvingen en schattingen van dingen die nooit uitgevoerd zijn?
Software Cost Engineering heeft alleen zin als je veel tijd besteed aan beschrijvingen van zaken waarvan je niet weet of je ze nodig hebt. Dat deden we in de Jaren ’90 en de succesratio was abominabel (16% en minder volgens Standish). Sindsdien hebben we veel geleerd. Vooral om geen werk te doen wat niets toevoegd. Als je geen uitgebreide functionele beschrijvingen maakt van zaken waarvan je niet zeker bent of je ze wel nodig hebt dan is het plots ook niet meer mogelijk om een functiepunt analyse te doen.
In de Agile wereld van tegenwoordig, waar de Project Succes rate meer dan twee keer zo hoog is, is het een stuk lastiger geworden om van te voren te bepalen wat iets gaat kosten. Vooral ook omdat de specificaties en eisen iedere paar weken veranderen. Uiteraard kun je dan iedere paar weken je berekening gaan aanpassen maar onderzoek wijst óók uit dat low-tech schattings methoden zoals Planning Poker qua nauwkeurigheid nauwelijks onder doen voor uitgebreidere methoden (Ook hier weer: Standish maar ook onderzoek van Microsoft binnen de eigen organisatie).
Daarmee kom je op het gebied van economie: Zoveel mogelijk waarde tegen zo laag mogelijke kosten. Een FPA kost meer geld dan een Planning poker sessie en levert geen waarde. Daarmee is FPA dus niet meer interessant.
Ik geloof heilig in het in de hand houden van de kosten van functionaliteit. Ik geloof ook heilig dat de methoden die we op dit moment daarvoor beschikbaar hebben niet voldoen in een wereld waar “Value for the lowest cost” en een zo kort en flexibel mogelijke time-to-market de belangrijkste drijfveren zijn.