Het IT-Betuwelijn effect

PDF Versie

Het grootste deel van de IT-projecten bij de
overheid loopt onderweg averij op, niet in de
laatste plaats omdat ze maar blijven uitdijen. En
niemand die de bestuurder waarschuwt dat de
zoveelste uitbreiding er een te veel is. Tijd dat
die zelf leert om gezonde groei te onderscheiden
van bedreigende woekering.  Professor Chris
Verhoef geeft college IT-diagnostiek.

We hebben het allemaal gezien: grote
infrastructurele projecten waarvan de kosten
totaal uit de klauwen liepen en de opbrengsten
twijfelachtig bleken.  Een combinatie van
polderen, overmoed en Oost-Indische doofheid
garandeert escalatie van kosten.  En niemand die
een halt toeroept aan de voortdenderende
ongelukstrein.  Achteraf is het allemaal makkelijk
praten, maar zitten we wel opgescheept met de
gevolgen: veel te dure onrendabele oplossingen.

Bij een IT-Betuwelijn is de weg naar disaster
vergelijkbaar met die van infra, alleen levert
het vaak helemaal niets op, niet eens een
onrendabel systeem.  Behalve dan een paar dure
softwarelicenties, dure high-end hardware en
meer.  Vast verderop wel weer te gebruiken, als
pleister op de wonde.

Net als bij civiele bouwprojecten gaan we het de
volgende keer beter doen!  Maar hoe dan?  De
gemiddelde besluitvormer bij de overheid is toch
een abecedarius (m/v) als het gaat om
informatietechnologie.  Dus de wil om het beter te
doen is er uiteraard, maar kennelijk geldt bij IT
niet de uitdrukking: met het ambt komt het
verstand.  Dat wil zeggen dat in de praktijk het
meest geleerd wordt, vooral door managers die
niet worden gekweld door de juiste kennis en
kunde.  Dan zouden we immers nu wel van alle
IT-disasters verlost zijn geweest.

Hoe herken je een IT-Betuwelijn?  Dat begint bij
meten. En denk nu niet te snel: meten is weten,
want met meten blijk je er niet te wezen.  Ik
maak regelmatig mee dat ondanks alle juiste
metingen niemand de problemen bleek te
onderkennen.  Niemand, inclusief
adviesorganisaties met dure consultants, kantoren
en kekke rapportkaftjes.  Het is als een huisarts
die meer dan 40 graden koorts meet en vervolgens
niet concludeert dat de patient
hoogstwaarschijnlijk zo ziek als een hond is.

Functiepunten

Het is een best-practice om de hoeveelheid IT uit
te drukken in functiepunten.  Laat je vooral niet
van de wijs brengen door mensen die zeggen niet
te geloven in functiepunten; het is sinds jaar en
dag de beste metriek die we hebben om met
dit soort issues om te gaan.  Een
functiepunt is een IT-inhoudsmaat die aangeeft
hoeveel functionaliteit er in een plan met
eisen zit.  Op het moment dat de plannen klaar
zijn, begint het gepolder.  Die wil een beetje
meer naar links, die moet een tunneltje en van
een ander moet er weer een extra bochtje in.
Kortom, na niet al te lange tijd moet je wederom
meten wat de nieuwe hoeveelheid
functionaliteit is die in de aangepaste
eisen is neergeslagen.  Een beetje
`samengestelde-interest-rekenen' en je weet de
zogenoemde requirementsvolatiliteit.

Benchmarking

37 graden is de normaaltemperatuur bij mensen, en
42 graden betekent hoge koorts.  Huisarts
bellen.  We hebben dus benchmarks om de
juiste dingen te doen.  Evenzo zijn die er voor
het IT-Betuwelijneffect.  De barometer moeten we
alleen instellen op veranderlijkheid van de
plannen in plaats van het weer.  En die meet je
door tijdens een project een aantal keren de
hoeveelheid informatietechnologie te peilen
en die te vergelijken met benchmarkgegevens.

De normaalvolatiliteit van overheids-IT is rond
de 2,5 procent groei van de requirements per
maand in geval van civiele toepassingen.  Dat is
eigenlijk al iets te hoog, want onder de 1
procent zou ideaal zijn.  Als het om IT onder
militaire standaards gaat, is de volatiliteit 3,5
procent per maand.  Nogmaals, volatiliteit wordt
net zo berekend als de samengestelde interest van
een spaarrekening.  Bij civiele informatiesystemen
is volatiliteit boven de 5 procent een
faalfactor.  Met andere woorden, boven de 5
procent is de patient zeer waarschijnlijk
ernstig ziek.

Voorbeeld

Een organisatie mat haar projecten regelmatig
door en gebruikte de gemeten groei als
extrapolatiemiddel om de totale kosten van het
uiteindelijke project in te schatten.  Het idee
was simpel: meet een paar keer, bepaal de groei,
trek het lijntje door en je weet waar je over
praat op het einde van de rit.  Als de metingen
goed geinterpreteerd waren geweest, had je
direct kunnen concluderen dat het project door de
enorme groei op het einde van de rit vrijwel
zeker gestrand zou zijn.  Het is als de huisarts
die de koorts ziet toenemen en uitrekent
wanneer de patient de juiste temperatuur heeft
om er een eitje op te bakken.

De gemeten hoeveelheden functiepunten heb
ik omgezet naar requirementsvolatiliteit.  Er
bleek een maandelijkse groei te zijn van 12
procent, 4.3 procent en 6.5 procent voor
verschillende fasen van het gehele systeem.
Die werd veroorzaakt door groeistuipen van 66
procent, 11.5 procent en 26 procent van een
kennelijk uiterst volatiel onderdeel van het
geheel.  Met het benchmark van 5 procent in de
hand is het een abc'tje geworden om de diagnose
te stellen.  Het project is niet onder controle en
maatregelen zijn per direct nodig.  Falen van het
project is zeer waarschijnlijk gezien de
hoge groeipercentages.  Alle hens aan dek dus.

Deze figuur toont een frequentiekarakteristiek
(gezond) van requirementsvolatiliteit, zeg maar
de gemiddelde groei van het eisenpakket dat aan
de functionaliteit van IT-projecten wordt
gesteld, gemeten in een laagrisicoportefeuille.
De piek van de curve zit net na de nul:
uitstekend. Daarnaast is er de karakteristiek
(wildgroei) van een onderzocht
overheidsproject. De top in de staart is te
wijten aan de hoge volatiliteit van een
deelproject. De karakteristiek wijkt erg af van
de benchmark, en op een negatieve manier: er is
sprake van wildgroei.  Het project verkeert
hoogstwaarschijnlijk in ernstige problemen. Tijd
om aan de bel te trekken!

Flexibiliteit is nodig

Een zero-change policy is een vaak gehoorde, maar
te simpele oplossing.  Dat komt omdat nadat de
eisen zijn uitgekristalliseerd, bij verdere
uitwerking vragen naar voren komen die
begripsverhogend werken op de eisen zelve en
daarmee worden de plannen aangepast of
uitgebreid.  Een rigide eisenpakket werkt dan
tegen in plaats van mee, dus iets flexibel moet
je wel wezen.

Het kan ook zijn dat een onderdeel van de
voorziene functionaliteit op losse schroeven komt
te staan en daarmee afvalt.  Er is dus ook goede
en gezonde volatiliteit.  Maar hoe zie je het
verschil?  Dat is niet zo gemakkelijk zonder
constitutionele kennis van het project, de
context en de organisatie die verantwoordelijk
is.  Maar met een benchmark in de hand kun je wel
tijdig signalen opvangen die nader onderzocht
kunnen worden.

Volatiliteitskarakteristiek

Laten we eerst kijken naar de
requirementsvolatiliteit van een
laagrisicoportefeuille. In figuur 1 zie je een
frequentiekarakteristiek van
requirementsvolatiliteit gemeten in zo'n
laagrisicoportefeuille.  De piek van de curve zit
net na de nul. In percentages is de mediane
volatiliteit net onder de 1 procent, dat is
prachtig.  De gemiddelde volatiliteit is iets
hoger en komt neer op 2.7 procent, dus gemiddeld
in de ordegrootte van de benchmarkvolatiliteit
bij de overheid, die endemisch wat te hoog is.

We zien in de figuur zowel positieve als
negatieve maandelijkse groei met grote
uitschieters van -40 procent naar +60 procent
groei per maand.  Dat klinkt potentieel ongezond.
Nu is het zo dat bij heel kleine projecten met
een sterke groei niet noodzakelijk sprake is van
ernstige risico's.  Net zoals heel kleine
kinderen wel eens hoge koorts kunnen hebben
zonder dat het meteen een ramp hoeft te wezen.
Voorbeeldje. Een systeem van 25 functiepunten
(wat heel klein is), blijkt sterk te groeien,
bijvoorbeeld naar 100 functiepunten, dus er zal
sprake zijn van een hoge maandelijkse groei.
Maar omdat 100 functiepunten nog steeds heel
klein is, zal hier geen noemenswaardig risico
optreden.  Pas als de projecten groot zijn en een
hoge volatiliteit vertonen, heb je sterke
signalen dat het project niet onder controle is
en zal gaan falen.

Laten we de grafiek eens uitbreiden met een
karakteristiek opgespannen door de
groeipercentages van een overheidsproject.  Net
zoals Gaudi zijn beroemde kathedraal ontwierp met
stukjes ketting kunt u zelf met een paar
paperclips en punaises uw eigen kettinglijn
opspannen.  Het gaat om een groot project (denk
aan duizenden functiepunten).  We zien nu naast
onze benchmarkkarakteristiek onze geknutselde
kantoorkathedraal.  Die kettinglijn geeft het
groeigedrag weer dat tijdens het project is
gemeten.  Wat opvalt is dat de karakteristiek meer
naar rechts staat en een lokale top in de staart
heeft.  Die laatste top is te wijten aan de zeer
hoge volatiliteit van een deelproject.  De
karakteristiek wijkt erg af van de benchmark,
en op een negatieve manier: er is sprake
van wildgroei.  Omdat het project groot is, geeft
dit plaatje dan ook meteen een signaal dat het
project hoogstwaarschijnlijk in ernstige
problemen verkeert.  Een nader onderzoek van dit
project is dan ook hard nodig.

Samenvattend kunnen we zeggen dat meten nodig is,
maar niet voldoende.  De gemeten waarden moeten
ook op de juiste manier geinterpreteerd worden
en vergeleken met benchmarks van
laagrisicoportefeuilles.  Op die manier verkrijg
je razendsnel inzicht in de status van je
IT-investeringen en heb je snel boven tafel welke
projecten je nadere aandacht vereisen.  Als meten
en weten door professionals wordt uitgevoerd, kun
je IT-falen voorkomen omdat je dan veel
duidelijker op de radar krijgt waar de
potentiele IT-Betuwelijnen zitten.

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.