De beste manier om IT diensten te begroten

Eens in de zoveel tijd kom ik weer in een discussie terecht over de beste manier om IT diensten te begroten. Kan dat het beste met een gespecialiseerde calculatieafdeling die alle begrotingen maakt of kun je beter alle projectmanagers, architecten en seniore ontwikkelaars trainen in het maken van goede begrotingen. Met deze vraag worstel ik al meer dan tien jaar.
Het beste antwoord is: Dat hangt er van af. Gelukkig zijn er wel een aantal universele waarheden rondom dit onderwerp:

1. Eén begroting is geen begroting
2. Een begroting kent altijd onzekerheden
3. 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 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, ben je voor vrijwel 100% 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 hebben 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 seniore 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 onderstaande figuur:

Voor de UKSMA 2011 conferentie heb ik hierover een artikel geschreven (in het Engels) dat hier gedownload kan worden.
Deze post is ook gepubliceerd op de Computable website onder de titel IT-diensten begroten kent haken en ogen.