Wanneer is een ict-project niet meer beheersbaar? Volgens promovendus Erald Kulk is dat wanneer er te veel wijzigingen binnen korte tijd aan een projectorganisatie worden gevraagd. Hij ontwikkelde een model waarmee bedrijven kunnen zien wanneer een project niet meer beheersbaar is.
Wat heb je onderzocht?
Mijn onderzoek bestaat uit twee delen. Het eerste deel gaat over een rekenmodel dat ik ontwikkeld heb. Het model laat zien wanneer een ict-project onbeheersbaar wordt. Dat meet ik aan de hand van het aantal wijzigingen (requirements) dat een project krijgt binnen een bepaalde tijd. Het tweede deel gaat over de redenen van kostenoverschrijdingen bij ict-projecten.
Hoe ziet het model dat je ontwikkeld hebt eruit?
Ik baseer me bij dit model op het rente-op-rente-principe, een model dat ook gebruikt wordt door wetenschapper Capers Jones. Ik ga er van uit dat een wijziging van een project nooit op zichzelf staat en dat er altijd extra werk uit voorkomt. Als je honderd euro op de bank zet en je vangt 2 procent rente, krijg je de eerste keer twee euro rente, maar de tweede keer is dat meer. Dat geldt ook voor ict-projecten.
Het verschil tussen het principe van Capers Jones en mijn model is dat ik de projectduur als tijdfactor heb toegevoegd.
Er zijn onderzoekers die zeggen dat je juist geen extra wijzigingen moet toelaten als je project gestart is. Jij denkt daar anders over?
Wijzigingen horen bij ict-projecten. Het kan zijn dat de wetgeving verandert of dat er nieuwere technologie beschikbaar komt. En tijdens een project kan er sprake zijn van voortschrijdend inzicht waardoor je een ict-project moet aanpassen.
Door te meten wat er gebeurt en daarop in te spelen, hou je het project toch beheersbaar.
Wordt nu niet bijgehouden hoeveel wijzigingen een project krijgt?
Dat gebeurt wel. Bedrijven noemen dat functiepuntanalyses. Een functiepunt is een wijziging van het project. Die functiepunten worden bijvoorbeeld in een service level agreement (sla) vastgelegd.
De manier waarop ik de functiepunten gebruik bestond alleen nog niet. Door mijn model te gebruiken kun je kortlopende en langlopende projecten met elkaar vergelijken.
Waarom heb je de projectduur als tijdfactor aan het model van Caper Jones toegevoegd?
Jones zegt dat een project met groeipercentages tussen de 2 en 5 procent een beheersbaar project is. De projecten die ik onderzocht hadden ook deze groeipercentages, maar er zaten ook geslaagde projecten tussen waar de groei van het aantal wijzigingen 10 tot 15 procent was. Dit bleken vaak korte projecten te zijn.
Hoe kunnen bedrijven jouw model gebruiken?
Op de website van mijn promotor Chris Verhoef is een excelbestand te downloaden waar bedrijven gegevens in kunnen vullen. Aan de hand van dit model kunnen bedrijven dan besluiten om requirements niet door te voeren of juist langzamer door te voeren.
Je hebt ook kostenoverschrijdingen en kostenonderschrijdingen van ict-projecten onderzocht. Wat zijn hier de oorzaken van?
Uit de analyse die ik maakte blijkt dat projecten waar veel externe ontwikkelaars aan werken een grotere kans hebben op kostenoverschrijding. Externen hebben tijd nodig om ingewerkt te worden. Dat wordt vaak niet ingecalculeerd bij de projectkosten. Ook geldt: hoe groter de ontwikkelomgeving, hoe groter de kans op kostenoverschrijding. Dat komt omdat bij grotere afdelingen de communicatie over veel lijnen loopt. Dat is kost tijd.
Waarom heb je ook naar kostenonderschrijdingen gekeken?
Ik heb gekeken naar projecten waar de kosten 5 procent onder of 2 procent boven de begroting waren. Dat noemde ik een misschatting. Ook een onderschrijving is vervelend. Het geld reserveer je toch voor een project. Dat kun je op dat moment niet uitgeven.
De redenen voor kostenwijzigingen die je geeft klinken als open deuren.
Dat geeft niet. Eerder waren het alleen onderbuikgevoelens van ict-afdelingen. Nu wordt dit onderbuikgevoel ondersteund door harde data. Er is namelijk weinig analytisch onderzoek op dit gebied.
Wat raadt je bedrijven aan naar aanleiding van je onderzoek?
Meten is weten. Verzamel data over een ict-project en analyseer niet alleen vooraf, maar ook tussendoor en achteraf. Als je tussendoor erop stuurt, dan kun je er nog bijsturen. De data die je achteraf meet bij een project, kun je weer voor analyses bij nieuwe projecten gebruiken.
Erald Kulk
Erald Kulk (1978) studeerde bedrijfswiskunde en informatica. Na zijn studie werkte hij enkele jaren bij bedrijven als Accenture en Webarchitects. In 2004 startte hij zijn promotie-onderzoek bij het project Exploring Quantifiable Information Technology Yields (EQUITY) aan de Vrije Universiteit van Amsterdam. Chris Verhoef was zijn promotor.
Functiepuntanalyses gaan helemaal niet over het aantal wijzigingen dat een project krijgt. Functiepunten is een vrij (klassieke) manier om de functionele omvang van een systeem te bepalen. Dat is iets anders dan een aantal wijzigingen. Je kan de omvang van één wijziging wel weer in functiepunten uitdrukken om een idee te krijgen van de omvang van de wijziging. Dat zegt echter nog niets over het aantal wijzigingen.
Interessant artikel met veel herkenbare correlaties. Alleen de opmerking “waar de kosten 5 procent onder 2 procent boven de begroting waren. Dat noemde ik een misschatting” vind ik bevreemdend. Die marges zijn geringer dan de standaardmarges van een projectbegroting.
Het gebruik van FPA bij het meten van de omvang van de wijzigingen, heb ik meer gezien (i.v.m. het doorbelasten van meer-/minderwerk).
Op zich zijn de resultaten van het onderzoek interessant om kennis van te nemen. Ik vind het echter wel ver gaan om te spreken van een onderzoek naar de beheersbaarheid van projecten als eigenlijk alleen gekeken wordt naar de impact van wijzigingen (overigens worden de termen wijzigingen en groei door elkaar gebruikt in het stuk).
Als ik naar het model kijk, dan lijkt het erop dat dat kijkt naar het verschil in omvang tussen een beginsituatie en een latere. Het gaat er daarbij aan voorbij dat groei van omvang iets anders is dan wijzigen van de requirements. Maar ik mis vooral een veelheid aan factoren die impact hebben op de beheersbaarheid, zoals invulling van randvoorwaarden, beschikbaarheid kennis, toegankelijkheid van users, samenhang met andere projecten, verloop in het team. Nog in het midden gelaten dat het succes van projecten voor een zeer groot deel door zachte factoren wordt bepaald.
Een goede start, maar wat mij betreft vooral een aanzet voor verder onderzoek.
Ik mis echter een aantal factoren, en vind de nu gebruikte nog al plat toegepast:
– inleertijd van mensen hangt af van de bekendheid met materie, niet van het in- of extern zijn.
– projecten hebben uitgangspunten en randvoorwaarden. Als deze niet blijken te kloppen, dan wel niet ingevuld worden, kan dat een sterke impact hebben op de projectduur.
There are lies
There are damned lies
And there are statistics
Ik zie niet zoveel waarde in dit verhaal. Wanneer echt projectmanagement wordt toegepast en wat minder technisch teammanagement onder het mom van projectmanagement, wordt dit verhaal veel minder relevant.
Functiepunten om omvang van één wijziging aan te duiden kan heel zinvol zijn. De impact van een wijziging is echter niet alleen gekoppeld aan het het aantal functiepunten.
Bovendien gaat het om de beheersing van meer factoren dan bijvoorbeeld tijd en geld. Denk daarbij aan hoe je gezamenlijk omgaat met niet te voorspellen tegenvallers.