Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Software Cost Enginering is een apart beroep

 

Expert

drs. Harold van Heeringen
Senior Consultant, METRI. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4657423). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

En weer komt er een wc-eend voorbij gevlogen ....

Google voor de aardigheid eens even op "kostenoverschrijding bouw projecten" en een groot deel van het artikel kan zo weggestreept worden....
Als de bouwsector, een vakgebied wat al eeuwen bestaat, al niet eens in staat is omvangrijke projecten goed in te schatten, waarom verwachten we dit dan wel van een jonge sector zoals de ICT?

Dat vervolgens het resultaat van de werkzaamheden van de software cost engineeers (of equivalente benamingen) niet op waarde wordt geschat heeft niets van doen met de titelatuur van betrokkennen.
Het artikel lezende komt bij mij zelfs een wedervraag op: als ik zie wat voor methodieken de cost engineers tot hun beschikking hebben, waarom lopen vandaag de dag dan nog steeds zoveel IT projecten uit budget?
Kunnen de cost engineers niet met de methodieken overweg, voldoen de methodieken niet of is hier iets anders aan de hand?

Het onderwerp is absoluut interessant, maar voordat we met mooie titels en kreten gaan sturen, zal men eerst moeten aantonen dat men in staat is om goede schattingen en begrotingen te maken. Pas dan krijgt het vakgebied software cost engineering toegevoegde waarde.

De methodieken zijn er wel, maar worden niet of nauwelijks gebruikt. Daar zit het probleem! Onbekendheid, maar ook ten onrechte teveel vertrouwen in zogenaamde expert begrotingen. We weten inmiddels allemaal wel uit de studies dat expert begrotingen gemiddeld 30% te optimistisch zijn. Ook weten we uit de literatuur en uit vele studies dat optimistische begrotingen een garantie zijn voor het mislukken van projecten. Zolang deze relatief jonge industrie niet de volgende stap naar volwassenheid zet, blijven dit soort wc eenden nodig!

De opmerking van PaVaKe staat met stip op nummer een van alle argumenten die je hoort om maar niet op een gestructureerde manier met begroten om te gaan. Op nummer twee staat IT is volledig anders, niet vergelijkbaar met projecten in andere industrien. En op drie, er zijn geen mothoden en technieken beschikbaar.
Ik zal de laatste zijn die zal zeggen dat als je het methodisch aanpakt er geen missers meer zullen zijn maar op de expertbasis zoals nu meestal gebeurt heb je geen enkele verdedigbare basis voor je project. Vandaar dat een "Basis of Estimate - Software Services" (in ontwikkeling), afgeleid van de "34R-05 Basis of Estimate" hieraan zal bijdragen. En niet alleen aan meer transparantie in begrotingen maar ook aan erkenning van Cost Engineering als specifieke discipline binnen de IT.

@Ton

Om misverstanden te voorkomen: je hoort me niet zeggen dat we niet op een gestructureerde manier met schattingen en begrotingen om moeten gaan!

Maar er wordt een vergelijking gemaakt met een bouwsector, waar net zo goed forse overschrijdingen van budget voor komen, terwijl ze daar blijkbaar wel professionals hebben op het gebied van budgeteren.
Dat schept (bij mij in ieder geval) geen vertrouwen in de werking van deze aanpak.

Waar ik vooral benieuwd naar ben is de oorzaken achter de overschrijding. Zijn dat echt verkeerde schattingen, of speelt bijvoorbeeld willen aanbesteden tegen een zo laag mogelijke prijs hier een rol (geldt overingens ook voor de bouwsector)? Komt dit door slecht schatten van de experts, of komt dit doordat allerlei managers en calculateurs een eigen correctiefator loslaten op de initiële schattingen? Te vaak worden de schattingen van de experts door managers gedecimeerd, en krijgen dezelfde experts vervolgens te horen dat ze er te lang over doen.
Historische projectdata is daarom ook van groot belang; daarmee kunnen sommige van deze factoren inzichtelijk gemaakt worden.

Overigens ben ik wel van mening dat de IT sector volledig anders is. In een IT project haalt men het in zijn hoofd om tijdens het project de architectuur om te gooien. In de bouw zie je dat echt niet gebeuren. Als de fundering er eenmaal ligt, ga je niet ineens bedenken dat je gebouw rond moet worden ipv vierkant.
Ook wordt binnen de IT (veel te) makkelijk van hardware gewisseld. In een auto bijvoorbeeld wordt alles van A tot Z doorgerekend alvorens men de motor gaat maken en plaatsen. Wil men dan toch een andere motor erin, wordt alles opnieuw doorgerekend. In de IT schuiven we gewoon een andere PC erin, en vertrouwen we erop als "de expert" roept dat dit geen verschil maakt.

Deze flexibiliteit van de IT is aan de ene kant de kracht van de sector, maar kijk ik naar mijn eigen ervaringen, wordt er nog veel te vaak lichtzinnig mee omgesprongen, wat zich o.a. uit in projecten die gierend uit de bocht vliegen.

Er bestaat geen enkel excuus om niet door experts en op basis van methoden begrotingen te laten maken. Het gebruik van seniors hierin is zeker wel relevant. Een onderdeel van een methode is ook een goed toetsingskader, lijkt me dat op zijn minst daarbij de uitvoering betrokken moet zijn.

De oorzaken dat projecten niet binnen de begroting blijven zijn naar mijn mening vooral:
- geen onderscheid tussen commerciële prijs en werkelijke begroting. Er is vaak een commerciële reden om voor een bepaalde prijs aan te bieden. Vaak worden de "begroters" onder druk gezet om het hierop aan re sluiten. Het onderscheid tussen de voorgecalculeerde financiële marge en de projectbegroting is een business afweging. De marge is een resultaat van die keuze en beïnvloedt de planning niet (c.p.). De financiële verantwoording van het project dient 2 niveaus te zijn: commercieel en operationeel.
- wijzigende specs en requirements gedurende het project. Hiervoor zijn methodes beschikbaar en worden afspraken gemaakt. Je opdrachtgever een plezier willen doen is heel nobel, maar dat kan niet zonder consequenties (bij een fatsoenlijke begroting).
- werken op basis van aannames, ipv met opdrachtgever af te stemmen. Bij problemen, vragen, ideeen wordt er maar al te vaak met de beste bedoelingen doorgewerkt en een keuze gemaakt, waarbij de opdrachtgever NIET is betrokken. project en account management kunnen elkaar hierbij prima aanvullen en aan het werk houden. Afstemming intern is 1. Praten met je klant is 2. Betrokkenheid van account management bij project management of projectoverleg is een makkelijk hulpmiddel, evenals een up to dat inzicht in planning en budget.

Zolang projecten worden aanbesteed op basis van 'laagste bieder wint' zullen onvolledige of te lage kostenschattingen blijven prevaleren. Eerst de opdracht winnen, daar gaat het om. Daarna, als het point-of-no-return is bereikt, de rest binnenharken via meerwerkbegrotingen.
Daarnaast kun je alleen maar betrouwbaar begroten als je de ontwikkelomgeving al vele malen hebt gebruikt voor het bouwen van soortgelijke systemen door dezelfde ervaren mensen.
Tenslotte staan ook leveranciers altijd onder forse druk om omzet en winst ten opzichte van vorig jaar te verhogen. Ook dat is marktwerking.

Zolang de onderliggende architectuur en de bijbehorende talen en frameworks continue blijven veranderen zal het afgeven van een goede inschatting moeilijk blijven, hoe "wetenschappelijk" onderbouwd ook. Een factor 5 afwijken van de inschatting voor de bouw van een component (want opdelen in kleine componenten is belangrijk!) is nog steeds vaak realiteit vanwege onervarenheid met bovenstaande. In de bouw is de architectuur veel minder een moving target en zijn de ingredienten ook veel minder talrijk. Ervaring uit het verleden geeft ook niet altijd (een betere) garantie voor de toekomst. Het continu blijven finetunen van je rekenmodellen op basis van componenten en architectuurvernieuwingen is dan ook het enige wat we kunnen blijven doen.

Zou Columbus een nauwkeurige planning hebben kunnen geven wanneer hij de Nieuwe Wereld zou ontdekken? Zou Nasa op voorhand exact hebben kunnen inschatten wat het kost om een man op de maan te zetten?

Iets wat nog niet eerder uitgevoerd is, zal onvoorspelbaar zijn. Als je honderd keer exact hetzelfde IT systeem bouwt, zal je de honderd en eerste keer een redelijke inschatting kunnen maken.

Alle projecten zijn per definitie uniek, dat is waar. Als je echter de projecten meet en de productiviteit van afgeronde projecten bepaalt, dan zie je dat er voor groepen vergelijkbare projecten (bijvoorbeeld Java projecten) een gemiddelde productiviteit wordt gerealiseerd (bijvoorbeeld gemeten in bestede uren per functiepunt), met daarom een spreiding. Voor Java projecten is de productiviteit in een bepaalde organisatie bijvoorbeeld 8 uur per functiepunt (en tussen de 6 en de 10 uur/FP). Hiermee kun je dus wel degelijk een begroting maken van een nieuw Java project. Het aantal functiepunten kun je op basis van de documentatie meten, je vermenigvuldigt dit met 8 en je hebt een eerste ruwe schatting. Met tools en modellen kun je dan vervolgens de impact van doorlooptijd, team size, aantal sprints, etc. doorrekenen.

Hiermee kun je dus ook eenvoudig de expertbegroting challengen. Als deze lager uitvalt, zal de expert moeten aangeven waarom zijn begroting lager uitvalt dan op basis van een objectieve meeteenheid en historische data mag worden verwacht. Vaak komen dan 'vergeten activiteiten' en 'optimisme' naar boven.

Een Software Cost Engineer zorgt voor objectief onderbouwde en verdedigbare begrotingen. Als deze te hoog uitvalt naar de smaak van de klant of de commerciële afdeling, dan is het een zaak van het aanpassen van de omvang (klant krijgt minder functionaliteit voor dezelfde prijs) of het toekennen van een korting (klant betaalt een lagere prijs, maar het aantal uren en doorlooptijd blijft hetzelfde!)

Overigens is NASA een van de organisaties die het toepassen van formele Cost Engineering technieken uitgebreid toepast. En zij gebruiken inderdaad de data van voorgaande projecten om de kosten van nieuwe projecten, hoe onzeker die ook zijn, enigszins te kunnen onderbouwen. En als Columbus van zijn eerder afgeronde reizen een gemiddelde snelheid van bijvoorbeeld aantal afgelegde mijlen per dag zou hebben bijgehouden en hij zou een schatting maken van de afstand naar de nieuwe wereld, dan had ook hij op basis van deze afstand en de historische data een ruwe schatting kunnen maken van het aantal dagen dat deze reis ongeveer zou gaan kosten.

Ik heb voor een artikel uit 2008 over Scope Management (het gestructueerd toepassen van Sofware Cost Engineering) al eens de parallel getrokken met Columbus en het is verluffend hoe goed hij zijn reis kon plannen me de informatie die voorhanden was. Klein detail was dat er nog een continent bleek te liggen tussen Japan en Spanje . . je kunt niet alles voorzien.

Zo is het ook met IT-projecten. We kunnen niet alles voorzien, maar op basis van de informatie die vooraf beschikbaar is kunnen we van een aantal projecten voorspellen dat de afgegeven begrotingen een zeer beperkt realiteitsgehalte hebben. Als we nu eens beginnen met het niet uitvoeren of herdefiniëren van dit soort projecten. Maar dan moeten opdrachtgevers die boodschap wel willen horen.

PaVaKe heeft absoluut een punt waar hij de vraag stelt naar de oorzaak. Aanbestedingen draaien vaak alleen maar om de laagste prijs en dan zal een opdrachtnemer de vraag zo minimaal mogelijk interpreteren om de opdracht gegund te krijgen. Een dergelijke manier van aanbesteden stimuleert niet tot een realistischer begrotingsdiscpline.

Goede software cost engineers helpen echt, vooral als ze naast de opdrachtgever gaan staan. Dan volgen de leveranciers vanzelf.

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×