Regelmatig is er discussie over wat de beste manier is om it-projecten te begroten. Kan dat het beste met een gespecialiseerde calculatieafdeling die alle begrotingen maakt of kun je beter je mensen trainen in het maken van goede begrotingen. Het beste antwoord is: Dat hangt er van af. Gelukkig zijn er wel een aantal universele waarheden, te weten één begroting is geen begroting, een begroting kent altijd onzekerheden en verwar een kostenbegroting niet met een aanbiedingsprijs
Eén begroting is geen begroting
Als er maar één begroting is opgesteld heb je geen enkel houvast om de kwaliteit van die begroting te kunnen beoordelen. Om dat te kunnen doen heb je minimaal een tweede begroting nodig. Best practice daarbij is om voor die twee begrotingen een andere aanpak te gebruiken:
– Top-down versus bottom-up
– Activity based versus ervaringscijfers per deliverable
Iedere begrotingstechniek heeft sterke en zwakke kanten. Door tenminste twee verschillende aanpakken te kiezen kun je de zwakke kanten van de gebruikte aanpakken verminderen. Door verschillende begrotingen naast elkaar te houden worden ook direct risicogebieden zichtbaar op de punten waar de details van de verschillende aanpakken sterk afwijken. Op die risicogebieden is het in de regel raadzaam om strikter risico management toe te passen.
Een begroting kent altijd onzekerheden
Hoe vaak kom je het niet tegen dat een kostenbegroting wordt gepresenteerd als absolute waarheid? Een goede begroting zou tenminste drie scenario's moeten presenteren:
– Worst case
– Expected case
– Best case
In de it zie ik nog steeds een voorkeur om het best case scenario als uitgangspunt te nemen voor de dienstverlening. Door dat te doen, weet je voor vrijwel 100 procent zeker dat de uitvoering slechter zal presteren dan de begroting. Gebruik je het worst case scenario dan krijg je een uitvoering die niet zo strak wordt uitgevoerd als zou kunnen, omdat er toch voldoende ruimte in de begroting zat. Als de begroting onderdeel was van een aanbiedingstraject in competitie loop je daarmee het risico dat een concurrent het werk gegund krijgt, omdat die meer risico heeft genomen in hun aanbieding.
Hoeveel risico je kunt nemen is vaak sterk afhankelijk van de bedrijfscultuur. In een open cultuur die aanmoedigt tot experimenteren zal het risico vaak scherper zijn dan in een bedrijfcultuur waar scherp wordt afgerekend op budgetoverschrijdingen en gemiste opdrachten. In wat voor cultuur je ook opereert, om een goede keuze te kunnen maken voor een risicoprofiel zul je eerst de onzekerheden in de begroting moeten kennen.
Verwar een kostenbegroting niet met een aanbiedingsprijs
Veel begrotingen in commerciële organisaties als de mijne vormen de basis voor een aanbiedingsprijs aan een klant. Haal dat niet door elkaar. Een begroting is de beste inschatting vanuit een vakinhoudelijk perspectief van de eenheden die nodig zijn om de it-dienstverlening te kunnen leveren en de bijbehorende kosten van de keuze voor een oplossing en bemensing. Die oplossing en bemensing kunnen wel beïnvloed worden door commerciële afwegingen, maar de resulterende kostenbegroting is een helder en duidelijk vakinhoudelijk resultaat.
Een aanbiedingsprijs is een financiële aanbieding die geoptimaliseerd is om het werk binnen te halen. Belangrijke input hiervoor zijn de gunningscriteria en een voorgeschreven prijsmodel. Het resultaat hoeft geen relatie te hebben met de kostenbegroting.
De beste manier om it-diensten te begroten
Het maken van een goede begroting is een vak. Een vak kun je alleen maar ontwikkelen als je vaak genoeg oefent. Dat zou pleiten voor een klein team van specialisten. Toch kun je alleen een echt goede begroting maken als je voldoende kennis hebt van de gevraagde dienstverlening. Dat pleit dan weer voor het trainen van project managers, architecten en senior ontwikkelaars in het maken van een goede begroting.
Ik geloof stellig in de drie universele waarheden en heb ze gecombineerd tot een simpel maar doeltreffend begrotingsproces. Bepaal de oplossing, laat experts begroten vanuit hun kennis, de projectleider vanuit zijn of haar overzicht en het Pricing Office op basis van parametrische analyse. Als je deze begrotingen op een goede manier combineert resulteert dat in een begroting die inzicht geeft in de onzekerheden en compenseert voor de 'niet-standaard' elementen die een project per definitie heeft. Begroten wordt gedaan door vakinhoudelijke experts, pricing wordt gedaan door sales en financiële experts. Op deze manier wordt geborgd dat begroten en pricen niet door elkaar gaan lopen. Dit wordt weergegeven in de nevenstaande figuur:
Voor meer informatie over deze aanpak raad ik aan het artikel te lezen dat ik voor de UKSMA 2011 conferentie heb geschreven (in het Engels).
Frank,
Het idee om begrotingen op te stellen op basis van een mediaan die bepaald wordt door Pricing Office (controlerende), experts (uitvoerenden) en projectmanager (sturende) heeft een aantal nadelen. Zo zal waarde van Pricing Office bij opstellen van begroting als stuurmiddel afnemen als er geen ervaringscijfers zijn. Ze moeten dan, net als de projectmanager hun quotes halen bij de experts waardoor er geen sprake meer is van een ‘overwogen’ gemiddelde. En bij een ‘gewogen’ gemiddelde zal rekening gehouden moeten worden met de projectmanager die begroting uiteindelijk gebruikt als stuurmiddel in zijn of haar project.
Als er dus te krap begroot wordt met een scherpe aanbiedingsprijs zal deze dus sturen op meerwerk of bezuinigen op kwaliteit. Projecteren van kosten verliest desondanks niet zijn nut maar het mag geen doel worden, want je kunt rekenen tot een kilo een ons weegt maar denk aan Godfried Bomans die al zei: “Een statisticus waadde vol vertrouwen door een rivier die gemiddeld één meter diep was. Hij verdronk.”
Beste Frank,
Er zijn nog veel meer parameters te bedenken die hout snijden in begrotingen:
1. Metrics, dus vergelijkingen uit andere branches en aanbieders van diensten;
2. Ervaringscijfers uit vorige projecten bij dezelfde of vergelijkbare organisaties;
3. Werken met een rolling forecast tijdens uitvoering, dus maandelijks kijken of het einddoel binnen de gestelde tijd en budget wordt gehaald.
Met gemiddelden komen we niet ver en als er bedragen worden genoemd dat gaan managers zelf middelen.
Ander probleem in de ICT dat je zelf aantipt: Vakinhoudelijke experts willen altijd een ferrari bouwen, sales mensen zijn opportunistisch, accountants gaan voor de grootste risico opslag. Als gebruiker krijg je nooit wat je wilt en als dat wel zo is: te laat.
Met geluk krijg je een best GUESS.
Ewout,
Juist op basis van ervaringscijfers kun je je een beeld vormen van wat de scenario’s zijn. Wat ik niet bedoeld heb is dat je op een gemiddelde uit moet komen. Je moet een beeld hebben van je worst case scenario, je best case scenario en je risicoprofiel en dan kiezen waar je met je aanbiedingsprijs een “doorwaadbare plaats” ziet, om aan te sluiten op de beeldspraak van Bomans. Gemiddelden zonder meer zijn niet beter dan een single point estimate en kunnen er voor zorgen dat je project “verdrinkt”.
Willem,
Metrics/ervaringscijfers zijn een must, voor zowel expertbegrotingen als parametrische begrotingen. Anders wordt het een mening of een guess. Een goede begroting maakt inzichtelijk wat de effecten zijn van een Ferrari, een opportunistische aanbieding, de risicodekking en een tijdige oplevering, zodat een overwogen keuze gemaakt kan worden. Dat is meer dan een best guess.
Met onnauwkeurige getallen nauwkeurig rekenen is een vak apart.
Dat geldt met name om iets te begroten of meestal wat onnauwkeuriger, in te schatten. Het is maar net het doel waar het voor moet dienen.
Echter met kennis van zaken zijn er altijd goede kengetallen die de financien afschatten. Het probleem zit hem vaak in de kennis van zaken overigens… Omgekeerd zal niet gaan werken….
@ Frank,
het lijkt me dat je een TCO berekening bedoeld inclusief onderbouwing ipv een begroting.
Maarten,
Het zou een TCO-berekening kunnen zijn, maar meestal is datgene wat een IT dienstverlener doet, maar een deel van de TCO.