Politieke deadlines: dodelijk voor IT

PDF Versie

Het grootste deel van de IT-projecten bij de
overheid loopt onderweg averijop, veelal omdat
de politieke situatie de deadline bepaalt zonder
dat wordt nagegaan of die technisch haalbaar
is. Professor Chris Verhoef leert debestuurder
realistische deadlines inschatten.

De politiek heeft er een handje van om nieuwe
wet- en regelgeving op feestelijke, gemakkelijk
te onthouden datums in te laten gaan. De eerste
januari van het nieuwe jaar is een populaire
en voor de hand liggende keuze.  Dat men
deadlines stelt lijkt me een prima idee, en
als dat gepaard gaat met feestelijke opleverdata
is dat ook prima. Er is echter wel een probleem
als de regelingen significante IT-ondersteuning
behoeven.

Op het moment dat er grote IT-investeringen
nodig zijn om wet- en regelgeving te handhaven,
uit te voeren, te controleren, of op te baseren,
krijg je namelijk ook te maken met wat er
uberhaupt technisch mogelijk is binnen een
bepaald tijdvak.

Als het gaat om de realisering van een
nieuw stuk infrastructuur, zoals een
spoorlijn, stormvloedkering, kantoorgebouw,
kanaal of anderszins, volgt na het besluit
tot bouw of aanleg altijd een implementatiefase
die duurt zolang als technisch vereist is. Al
naar gelang de extra eisen, bezwaarschriften,
beschikbaarheid van personeel en stand der
techniek kom je dan op een opleverdatum uit.

Bij IT zien we een ander beeld, en niet alleen
bij de overheid. Bestuurders besluiten over
deadlines en daarmee ook over technische
deadlines, zonder rekening te houden met de
IT-component in de betreffende wet- en regelgeving.
Dat is als het besluiten tot de aanleg van een
nieuwe spoorlijn, inclusief opleverdatum, zonder
een ingenieur gesproken te hebben. Bij een
spoorlijn gebeurt dat niet in de praktijk, en
dat zou bij informatietechnologie ook niet
moeten gebeuren. Omdat de bestuurder geen
inzicht heeft in de technische kant van de
zaak, zal hij te rade moeten gaan bij de
specialist, de software engineer. Des te meer
omdat de kosten die het gevolg zijn van deze
politieke deadlines extreem hoog kunnen oplopen.
Wie dergelijke waarschuwingen in de wind slaat
koerst met zijn project op een afgrond af.

IT-kostenhydrauliek

Het samendrukken van vloeistoffen lukt slechts
mondjesmaat, maar een heel klein beetje
samenpersen levert een enorme vloeistofdruk
op. Daarop is het principe van de hydrauliek
gebaseerd. De natuurkundige wet erachter is
dat de druk maal het volume constant is. Bij
informatietechnologie is een soortgelijk fenomeen
aan de orde en dat noem ik ook wel de
hydraulische-softwarewet. Als je de doorlooptijd
van een IT-project `samenperst', neemt de
kostendruk extreem toe. Dat gaat volgens de
softwarewet die luidt dat de kosten maal
doorlooptijd tot de macht vier constant is.
Dat betekent dus dat wanneer de doorlooptijd
zelfs maar een beetje wordt `samengeperst', de
kosten extreem veel hoger zullen uitvallen.

De wet geldt slechts voor een beperkte bandbreedte.
Het is dus niet zo dat je, omgekeerd geredeneerd,
software voor niets kunt produceren als je er
maar lang genoeg over doet. Integendeel, als
je er te lang over doet, wordt het ook weer
duurder. De reden daarvoor is dat je kennis
weer vergeet, dat dingen verouderen en dat
zaken overnieuw moeten worden gedaan. Er bestaan
curves die de softwarehydrauliek goed in kaart
brengen.

Een voorbeeld van zo'n curve is billboard 1
(zie PDF). Daarin staan verticaal de kosten en
staat horizontaal de tijd. De curve laat zien
dat voor een bepaald project de kosten oplopen
naarmate er minder tijd voor realisatie
beschikbaar is. De kosten nemen ook weer toe
naarmate er (te) veel tijd aan besteed wordt.
De twee horizontale stippellijnen stellen de
bandbreedte voor waarbinnen je het IT-project
kunt doen volgens de meest geeigende
productiemethode. In de andere gevallen doe je
aan zogenoemde tijdcompressie (links boven de
stippellijn) of tijddecompressie (rechts boven
de stippellijn), beide zeer nadelig voor het
kostenverloop van het project. Bovendien brengt
dat grote risico's met zich mee omdat je niet
de meest geeigende productiemethode kunt
gebruiken. Zo'n curve heet wel een effort-tijd
trade-off curve.

Ook in de reguliere bouw geldt dat te snel
werken, bijvoorbeeld betonstorten en niet
wachten tot de vloer droog is voordat je de
volgende verdieping erop zet, problemen geeft.
Dat zorgt wel voor hogere opleversnelheden,
maar het brengt grote risico's met zich mee
omdat niet met de meest geeigende productiemethode
gewerkt wordt. Datzelfde effect krijg je ook
bij IT als je te snel (of veel te langzaam)
wilt opleveren.

Benchmarken

Hoe moet je nu de deadline van een IT-project
waarvoor geen historische gegevens van
vergelijkbare projecten beschikbaar zijn---een
standaardsituatie in overheidsland---inschatten?
Een voorbeeld.

Stel, we hebben te maken met een IT-project
dat de kerntaak van een overheidsdienst
ondersteunt. Er is besloten dat de IT-kant in
twaalf maanden opgeleverd wordt voor 1 miljoen
euro. Dit soort mooie getallen zie ik vaker in
de praktijk als het om IT-investeringen gaat.

Wat je nu kunt doen, is de investering benchmarken
en kijken hoelang een IT-project van een miljoen
eigenlijk mag duren. Vervolgens kun je dan de
softwarehydrauliek ervan bepalen en zien wat
je kunt besparen als je niet de politieke, maar
de technische realiteit volgt.

In billboard 2 (zie PDF) is de doorlopende lijn
van linksboven naar rechtsonder een stukje van
een effort-tijd trade-off curve in het
tijdcompressiegedeelte; het linkerstuk van
billboard 1. Op die lijn is het IT-project
gesitueerd: 1 miljoen euro en twaalf maanden
doorlooptijd. De stippellijn die van linksonder
naar rechtsboven loopt, is een benchmark die
aangeeft welke kosten er redelijkerwijs bij
welke doorlooptijden horen. We zien: projecten
die langer duren, kosten meer en omgekeerd.
Die lijn is opgesteld uit benchmarkgegevens
van vele IT-projecten. Als we via de hydraulische
lijn omlaag lopen naar de benchmarklijn gaan
de kosten omlaag en de doorlooptijd wordt
langer. Ik heb voor dit geval een en ander
netjes uitgerekend en dan kom je uit op het
volgende: als je nu twee weken meer de tijd
neemt, kun je 141 duizend euro besparen. Wat
je hier ziet, is het dodelijke effect dat
politieke deadlines op IT-projecten kunnen
hebben.

Enige tijd geleden heb ik een dergelijke
berekening voor een overheidsorganisatie gemaakt.
De gehele IT-afdeling van deze organisatie had
sterk het gevoel dat de door de politiek
opgelegde deadline van 1 januari tweeduizend-zoveel
onhaalbaar was. Maar men kreeg dat niet in maat
en getal gevat. En dan krijg je het bij
bestuurders ook heel lastig voor het voetlicht.
Uit mijn berekeningen bleek dat de tijdcompressie
die er op het IT-project was gelegd vanuit de
politieke deadline de kosten met een factor
van meer dan tien uit de pan deden rijzen.

Ik had keurig netjes berekend wat de technische
opleverdatum zou moeten zijn, gegeven de
hoeveelheid functionaliteit en de activiteiten
die door de verschillende partijen zouden worden
uitgevoerd. Zeg maar een technisch doorloopschema.
Dat gaf aan dat er minimaal anderhalf jaar meer
nodig was dan dat er nu voor stond.

Deze technische berekening gaf de verantwoordelijken
in kwestie genoeg ammunitie om de strijd aan
te gaan met de politieke besluitvormers om iets
aan de door wet- en regelgeving ingegeven
deadline te doen.

Het project kreeg een jaar uitstel. In mijn
ogen nog te weinig, wat later ook bleek, maar
de kostendruk was van de ketel. Er ging een
zucht van verlichting door het gehele gebouw
toen die kogel door de kerk was.

Samenvattend verdient het aanbeveling om, net
als bij andere bouwtrajecten, veel meer rekening
te houden met de meest geeigende productiemethoden
en de daarbij behorende door de techniek
ingegeven opleverschema's. Zelfs met beperkte
gegevens kun je al heel snel de onhaalbaarheid
van veel te optimistische deadlines inschatten.
Zo kan voorkomen worden dat IT-projecten die
met normale doorlooptijden en dito kosten een
kans van slagen hebben, door politieke deadlines
falen.

Meer weten over de wondere wereld van ICT 
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica 
aan de Vrije Universiteit in Amsterdam.  Hij
schrijft maandelijks een column in AG II.  Hij is
te bereiken via email:  x@cs.vu.nl.  Deze tekst is 
copyright SDU.  Niets van deze uitgave mag zonder
schriftelijke toestemming van de uitgever worden
overgenomen of worden gepubliceerd.