Budgetoverschrijding of begrotingstekort

De laatste tijd verschijnen er weer met enige regelmaat berichten over budgetoverschrijdingen van IT-projecten. De teneur is veelal dat IT-projecten gewoon niet in de hand te houden zijn en dat budgetoverschrijdingen iets is wat er schijnbaar bij hoort. De belangrijkste bron van dit soort berichtgeving is de reeks aan CHAOS rapporten die jaarlijks door onderzoeksbureau Standish worden uitgevoerd. Eén belangrijk aspect wordt in dergelijke onderzoeken systematisch over het hoofd gezien en dat is het tekort aan kwaliteit van de oorspronkelijke begroting.

Ik ben mijn werkzame leven ver buiten de IT begonnen, namelijk op een ingenieursbureau dat zich bezighield met de voorbereiding van één van de grootste infrastructurele werken sinds de Deltawerken, de aanleg van de Betuweroute: 160 kilometer spoorlijn van het Rotterdamse havengebied naar de Duitse grens bij Zevenaar. De cost engineers daar wisten al voordat de eerste meter spoor was aangelegd dat de totale kosten aanzienlijk hoger zouden zijn dan de bedragen waar in de politiek over werd gedebatteerd. Waren hun inzichten gebruikt als oorspronkelijke budgetraming, dan was de budget overschrijding uiteindelijk veel kleiner uitgevallen . . of had de Betuweroute er nu niet gelegen.

Toen ik me een aantal jaren later ging bezighouden met het begroten van IT-projecten bleek dat er daar soms ook op een vergelijkbare manier begroot werd. Inmiddels heb ik voldoende projecten langs zien komen die eigenlijk al "mislukt" zijn voordat ze starten. In mijn blogpost van 2 januari heb ik al het één en ander geschreven over de totstandkoming van zulke begrotingen.

Als het probleem niet uniek is voor de IT, dan kunnen we ook kijken naar oplossingen die buiten de IT hebben geholpen dit probleem beheersbaar te maken. Eén van die oplossingen is het classificeren van begrotingen naar verschillende typen en die te koppelen aan het gebruiksdoel. De AACE (Association for the Advancement of Cost Engineering) heeft hiervoor een generieke classificatie bedacht:

• Klasse 5 is een begroting die gemaakt wordt als maximaal een paar procent van de uiteindelijke oplossing in detail bekend is. De onzekerheid is 4-20 keer zo groot als van een klasse 1 begroting en een klasse 5 begroting is alleen geschikt voor screening van ideeën en globale haalbaarheidsstudies.
• Klasse 4 is een begroting die gemaakt wordt als maximaal 15% van de uiteindelijke oplossing in detail bekend is. De onzekerheid is 3-12 keer zo groot als van een klasse 1 begroting en een klasse 4 begroting wordt gebruikt voor conceptramingen en haalbaarheidsstudies.
• Klasse 3 is een begroting die gemaakt wordt als 10-40% van de uiteindelijke oplossing in detail bekend is. De onzekerheid is 2-6 keer zo groot als van een klasse 1 begroting en een klasse 3 begroting wordt gebruikt om globale budgetten vast te kunnen stellen.
• Klasse 2 is een begroting die gemaakt wordt als 30-75% van de uiteindelijke oplossing in detail bekend is. De onzekerheid is maximaal 3 keer zo groot als van een klasse 1 begroting. Dit type begroting wordt gebruikt als interne raming voor aanbestedingen.
• Klasse 1 is een begroting die gemaakt wordt als minimaal 65% van de uiteindelijke oplossing in detail bekend is. Dit type begroting is geschikt om fixed-price fixed-date contracten af te kunnen sluiten.

Een klasse 1 begroting in de IT kent nog steeds een onzekerheidsmarge van -4 tot +12%. Dat betekent dat de bandbreedte flink groter wordt bij hogere klassen. Bij klasse 2 loopt de maximale bandbreedte al van -12% tot +36%. Als we deze systematiek gaan toepassen en een project als technisch goed uitgevoerd gaan beschouwen als het binnen de corresponderende bandbreedte valt weet ik zeker dat het aantal projecten met een budgetoverschrijding (buiten de bandbreedte) aanzienlijk lager zal liggen. Het is nog steeds niet ongebruikelijk dat een IT leverancier gevraagd wordt om een fixed-price fixed-date aanbieding te doen, terwijl maximaal een klasse 2 en soms zelfs maar een klasse 3 begroting gemaakt kan worden. Als het dan mis gaat is het eerder een begrotingstekort dan een budgetoverschrijding.

Deze post is oorspronkelijk geplaatst op de website van Computable.