Column budgetoverschrijding

Afbeelding van Pixabay door Erich Westendarp.

Met enige regelmaat duiken ze weer op: de berichten over weer een enorme budgetoverschrijding van een IT-project. De teneur is vaak dat IT-projecten gewoon niet in de hand te houden zijn en dat budgetoverschrijdingen iets is wat schijnbaar hoort in de IT. Onderzoeksbureau Standish publiceert vrijwel jaarlijks hoe het staat met budget- of tijdsoverschrijdingen in de IT onder de veelzeggende titel CHAOS. Ik zal niet beweren dat overschrijdingen niet voorkomen in de IT. Wat ik wel al heel lang zie gebeuren is dat er één belangrijk aspect systematisch over het hoofd gezien wordt en dat is het tekort aan kwaliteit van de oorspronkelijke begroting. Veel projecten met een “budgetoverschrijding” hadden gewoon nooit uitgevoerd kunnen worden binnen de oorspronkelijke begroting, bewust of onbewust. Bij dit soort projecten is er eigenlijk sprake van een “begrotingstekort” en niet van een slecht gemanaged project.


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 budgetoverschrijding beperkt gebleven tot een paar procent. Of had de Betuweroute er nu niet gelegen, omdat er te weinig draagvlak zou zijn voor de grote investering in iets waar lang niet iedereen het nut van inzag. Zelfs met de huidige energieprijzen blijft het een moeizame worsteling om transport over meer dan 100 kilometer van de weg te halen.

Toen ik me een aantal jaren later ging bezighouden met het begroten van IT-projecten bleek dat er in de IT op een vergelijkbare manier met begroten wordt omgegaan. Ik mag regelmatig meekijken met ontspoorde projecten. De rode draad in veel van die projecten is dat ze met een onhaalbare begroting zijn gestart. Soms bewust gestuurd, omdat veel beslissers weten dat hun RvC of (politieke) controleorganen het project niet meer zullen stoppen als het begonnen is. Maar vaak ook onbewust, omdat het begroten van IT-projecten nog steeds in de kinderschoenen staat.

Het probleem van begroten is niet uniek voor de IT. Dus 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.

Dit betekent wel dat we beslissers op moeten voeden met een bandbreedte en een onzekerheidsmarge en dat gaat in tegen ons gevoel van vakmanschap. Hoe beter de vakman, hoe kleiner de onzekerheid, zegt onze interne natuur. Maar als de oplossing nog niet volledig bekend is, is het juist heel professioneel om aan te geven dat de begroting van een project een onzekerheidsmarge kent.

Uit onze projectendatabase van meer dan 10.000 gerealiseerde IT-projecten blijkt dat een klasse 1 begroting nog steeds een onzekerheidsmarge van -4 tot +12% kent. 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 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 de informatie over de gevraagde oplossing maximaal een klasse 2 en soms zelfs maar een klasse 3 begroting toelaten. Als het dan mis gaat is het eerder een begrotingstekort dan een budgetoverschrijding.

Een bijdrage van

Frank VogelezangFrank Vogelezang houdt zich al sinds 1999 bezig met het begroten en inzichtelijk maken van IT-projecten. Met zijn inzichten heeft hij wereldwijd al vele tientallen organisaties geholpen in zowel de private als de publieke sector met het onderbouwd begroten van en beslissen over IT diensten, projecten en transformaties. Sinds 2017 doet hij dit vanuit het onafhankelijk adviesbureau IDC Metri.

Frank Vogelezang
IPMA-NL lidmaatschap

0 Reacties

Laat een reactie achter

Het e-mailadres wordt niet gepubliceerd.

*

©2022 IPMA Nederland - Platform Projectmanagement

Neem contact op

We zijn nu niet online. Maar je kan ons een email sturen, dan nemen we zo spoedig mogelijk contact op.

Versturen

Log in met je gegevens

Gegevens vergeten?