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. 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 budgetoverschrijding 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 procent 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 procent 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 procent 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 procent. Dat betekent dat de bandbreedte flink groter wordt bij hogere klassen. Bij klasse 2 loopt de maximale bandbreedte al van -12 tot +36 procent. 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.
Applaus!
Dit stuk zou door alle projectmanagers en andere leden van elke project- en programmaboard moeten worden gelezen. Hoe vaak komt het niet voor dat een project wordt gevraagd een schatting af te geven en dan niet wordt geloofd? Vaak wordt het ongeloof ingegeven door een van de volgende factoren (of moet ik zeggen misvattingen):
1. Het idee dat projectleden inherent lui zijn en zichzelf gewoon meer tijd geven om te nietsen. Als ze 3 maanden zeggen, moet je gewoon de planning “challengen” en dan gaan er automatisch een paar weken af. De waarschuwingen die ze bij die nieuwe planning afgeven (o.a. “er mag nu ECHT niets fout gaan of onverwachts gebeuren”) gaan we gewoon negeren.
2. Het idee dat planningen ALTIJD 20% “onverwachts” bevatten die per definitie niet gaat worden gebruikt. Dus alle planningen moeten minstens 20% lager worden onderhandeld (en dat gebeurt dan ook vaak).
En als de vernieuwde hernieuwde planning niet wordt gehaald geven we het project gewoon de schuld, zij hadden dit tenslotte in hun planning moeten meenemen.
Met het in het artikel genoemde klassificatie-systeem wordt in elk geval de context waarbinnen de schatting is afgegeven duidelijk gedefinieerd neergezet en kunnen alle partijen er het gewicht aan geven die het verdient.
Het zal niet alle problemen wegnemen overigens. Als voorbeeld de betuwelijn: als duidelijk was geweest dat de betuwelijn zou gaan kosten wat het uiteindelijk heeft gekost had de toenmalig verantwoordelijke minister zijn/haar politieke ambitie nooit kunnen verwezenlijken. Politieke drijfveren zijn notoir voor het opzettelijk incorrect (doen laten) inschatten van projectkosten (zie bijv. ook de Noord-Zuid lijn in Amsterdam).
Er zijn een hele hoop factoren die een overschrijding te weeg kunnen brengen. De gene die ik het meest zie en waar ik altijd handig op in speel is het niet volledig of niet goed beschrijven van de wens.
Laatst had ik een klant die vroeg om een Rack. (niet meer niet minder)
Hierbij heb even zitten zoeken van wat voor rack de beste klant wilde en kwam tot de ontdekking dat dit niet beschreven was in de RFP.
Uiteraard wist ik wat voor rack de klant wilde omdat hij eigenlijk alleen maar een bepaald type rack wil. Echter dit rack kostte 3,500 euro.
Omdat de winnaar puur op prijs werd geselecteerd heb ik besloten het rack van 3,500 euro te vervangen door een Billy van IKEA.
Nadat ik het project gewonnen had kwam natuurlijk de melding, dat dit niet was wat ze wilde en er moest een goed rack komen. Welke uiteraard geleverd kan worden tegen meerprijs.
Nu is dit een simpel voorbeeld maar naar mijn idee gaat het veel vaker zo. Veel bedrijven of instanties weten niet hoe ze moeten aan besteden, als ze vervolgens voor een partij kiezen kunnen ze niet meer terug en zijn ze gebonden aan die prijzen/oplossing.
Slim van de aanbiedende partij dus want meerwerk levert veel geld op.
Naast de genoemde classificatie heeft AACE nog meer “Best Practices”. Een andere in deze context belangrijke standaard is de Base of Estimate. Deze standaard beschrijft hoe de documenten, methodes en aannames samenhangen bij het tot stand komen van een begroting waarbij de aspecten transparantie en traceerbaarheid (relevant bij Governance)duidelijk in beeld zijn.
De NESMA heeft deze standaard op dit moment in onderzoek voor aanpassing aan IT projecten.
Een classificatie systeem m.b.t. mate van beschikbare details kan zeker helpen bij het vergroten van de bewustwording van de opdrachtgevers en daarmee het bepalen van de benodigde contingency. Een organisatie die zich hiervan bewust is, heeft inderdaad een betere kans om goede budgetten op te stellen.
Daarnaast zijn er wat mij betreft nog een aantal andere factoren die een sterke invloed hebben op de uitkomsten en dus ook het benodigde budget / contingency zoals:
– De mate waarin projectdeelnemers wijzigingen op afgesproken eisen / wensen mogen doorvoeren. Er wordt te weinig een officieel wijzigingsbudget vastgesteld omdat al gauw het budget met 10% (of meer) verhoogd moet worden. Verder is er in mijn ervaring lang niet altijd een methode om eisen / wensen uit te ruilen voor nieuwe eisen / wensen
– De ervaring van de projectleden. Er wordt vaak uitgegaan van ervaren projectleden terwijl die niet altijd (direct) beschikbaar zijn.
– De complexiteit van de voorgestelde oplossing. Bijvoorbeeld meerdere pakketen met elkaar laten samenwerken is lang niet altijd eenvoudig te realiseren.
– De deelnemende organisaties. Hoe meer verschillende (externe) partijen hoe groter de kans dat er verschillen in werkwijze zijn of dat er meer politiek is.
– De omvang van het project. Hoe groter hoe meer overhead er vaak aanwezig is door het in verhouding toenemende aantal ’toezichthouders’ / leiders.
De blogpost waar ik in de tekst naar verwees is te vinden op http://watkostit.blogspot.com/2012/01/middeleeuwse-business-cases.html.
Beste Frank,
Ik denk dat jij hier de kern van mijn ‘kennisbetoog’, die ik overigens al jaren hou en nooit van af ben geweken, precies aangeeft.
1. Een project is niet hetzelfde als een IT project
2. Een politicus/ambtenaar heeft geen verstand van projecten
3. Een projectleider/manager is GEEN IT projectleider/manager
De reden hiervoor is bijzonder eenvoudig. Geen van de betreffende betrokkenen in dergelijk geschetste IT projecten heeft geen clue van de IT, de materie IT en de wetmatigheden van IT maar doen wel alsof ze het allemaal volkomen begrijpen.De gevolgen van dergelijke ‘arrogantie’ kom je in de praktijk op tal van plaatsen tegen en ook de kern van jouw betoog.
Dat iets er al of niet zou zijn gekomen wanneer er al of geen budgetoverschrijding zou hebben plaatsgenomen vind ik een non argument. Als je dit als commercieel opererende organisatie toe wil laten is dat een afweging natuurlijk. Maar die afweging wordt aanzienlijk anders wanneer dit het voortbestaan van diezelfde organisatie betreft.
Wanneer je het wil hebben over politieke keuzes vs een commerciële organisatie, dan zie je hier de stupiditeit ten top van politiek en ambtenarij. Zij hebben geen enkel oog of inzicht voor verhoudingen en kosten en baten verhoudingen maar nemen graag beslissingen die volkomen tegen alle ‘gezonde regels/opvattingen’ indruisen. De reden? Ego maar niet maatschappelijk nut.
Ik denk dat daar de grootste verschillen zitten uiteindelijk. Je kunt natuurlijk allerlei prachtige modellen bedenken maar wanneer je het zou willen hebben over IT, dan is dat juist een materie waarbij kostenbaten uitstekend en helder zijn weer te geven.
Maar ja, als je niet begrijpt hoe de IT als materie werkt en de wetmatigheden veronachtzaamd, dan krijg je dit soort voorstellingen. Helaas.
In de praktijk (vooral overheid) wordt je vaak geleefd door budgetten die al lang van te voren op hoog niveau en op basis van vage ambities zijn vastgesteld (en in beton gegoten). In feite klasse 6, men heeft nog geen idee van de oplossing maar het maximale budget ligt al vast.
Op het moment dat de ambities worden omgezet in concrete projectplannen blijkt er veel te weinig budget en wordt er (onder druk) toch maar weer veel te optimistisch begroot. Als PM moet je dan wel heel sterk in je schoenen (durven) staan. Slecht opdrachtgeverschap is vaak een grotere oorzaak voor projectfalen dan slecht projectmanagement.
Mijn punt: om de grote boze wereld rond je project in toom te houden heb je niet zo veel aan deze klasse-indeling. Afgezien daarvan is het wel een interessant hulpmiddel voor bewustwording over de manier van begroten.
De best practices die de IT industrie kan overnemen uit andere (meer volwassen) industrieen zijn m.i. de moeite van het onderzoeken meer dan waard. We zitten op dit moment als ITindustrie met een geloofwaardigheidsprobleem en dat kan alleen worden opgelost als:
– projecten realistisch worden begroot (ipv optimisisch);
– in aanbestedingen niet automatisch de goedkoopste (optimistische) inschrijver wint, maar de meest realistische;
– standaarden worden gebruikt, zoals de voorgestelde klasse indeling, maar ook b.v. scopemanagement (northern scope of southern scope) om changes tijdens het project te managen.
Zolang we er niet in slagen om de industrie naar een hoger volwassenheidsniveau te tillen, blijven falende projecten de orde van de dag ben ik bang.
Waar het op neer lijkt te komen is dat je pas goed kunt begroten als de requirementsanalyse hebt gedaan en beschikt over een goedgekeurd FO. In de praktijk is dit echter vaak onderdeel van het project. Dus kunnen we vaststellen (en reageerder Ronald bevestigt dat feitelijk) dat de begroting nooit klopt en je vervolgens nog alle kanten uit kunt, met alle gevolgen van dien.
Mijn vraag: welke activiteiten zitten niet in een project die wel noodzakelijk zijn en bijdragen aan het kunnen opstellen van een klasse 1 begroting?
Verder vraag ik me af of en zo ja in hoeverre, bijvoorbeeld op basis van impactanalyses, de gevolgen van de implementatie nog meegenomen (kunnen) worden in de projectbegroting.
Wat ik hier mis is de definitie van het begrip ‘project’. Wanneer is een IT project een IT project. Zijn we dan al aan het bouwen, of hebben we alleen nog maar een wens die via requirementsanalyse, FO en TO en impactanalyses helemaal in kaart moet worden gebracht? Ook in de reacties lijkt iedereen van dezelfde definitie uit te gaan, maar nergens worden man en paard genoemd.
Klasse 1 begrotingen zijn volgens mij alleen mogelijk als de wens is gedefinieerd, de analyse is gedaan en de oplossing en de weg er naartoe in beeld zijn. Bij negen van de tien projecten is dat niet het geval en horen de inventarisatie- en definitiefase er gewoon bij. Daar valt nauwelijks op te begroten. Op het moment dat IT de organisatie specifieke vragen stelt over wat ze nu eigenlijk willen begint e.e.a. al uit de bocht te vliegen.
Een ander artikel deze week, gaat in op architectuur en dat dit ingebed moet worden in de gehele organisatie. In grote lijnen is de boodschap hetzelfde: de business is verantwoordelijk voor een goed fundament. IT kan daarbij helpen en dat moet zij ook gaan doen. Zij zou niet langer een organisatie in een organisatie moeten zijn, maar veel meer geïntegreerd om op effectieve en efficiënte wijze de business functionerende functionaliteit te leveren, deze te beheren en te onderhouden. IT dienstverleners die nog steeds begrotingen durven geven die gebaseerd zijn op een niet gedefinieerde vraagstelling bedotten de boel.
Anderzijds moet de business zich realiseren dat projecten minstens twee kanten kennen: de vraagklant en de leverkant. Wie de vraagkant niet onder controle heeft en zich beperkt tot het uitspreken van wensen zal nooit een klasse 1 begroting kunnen ontvangen. De wens zal niet uitkomen.
Eigenlijk moet Frank dit stuk niet (alleen) in Computable zetten, maar (ook) in een businessmagazine. Help de business bewust te worden.