Veel bedrijven hanteren een projectmatige manier van werken, of dat nu IT of non-IT betreft. Doordat de bijdrage van IT aan de bedrijfsvoering steeds omvangrijker, complexer en dus risicovoller wordt, neemt het aantal IT-projecten hand over hand toe. Dit verklaart de behoefte aan professioneel Project Portfolio Management.

Chris Verhoef, hoogleraar aan de VU in Amsterdam, heeft zich verdiept in het slim en evenwichtig managen van IT-projecten. Hij pleit ervoor om beslissingen met betrekking tot portfoliomanagement te nemen op basis van feiten: "Besluitvorming op basis van een onderbuikgevoel is niet aan te bevelen. Wie IT goed wil besturen moet weten waar hij op stuurt. Zonder data valt er weinig te besturen."

Hoe maak je nu de effecten van Project Portfolio Management (PPM) zichtbaar, positief of negatief, in maat en getal? "Natuurlijk", vertelt Verhoef, "spelen zaken als transparantie, control, effectiviteit en efficiëntie hierin een belangrijke rol. Er is nog veel werk aan de winkel om de meeste IT-organisaties naar dit niveau te brengen. Uit een onderzoek van enige tijd terug blijkt dat een substantieel deel van alle IT-projecten geen businesscase heeft. Veel organisaties hebben dan ook geen idee of ze nu teveel, te weinig of voldoende uitgeven aan IT. Ze doen niet aan benchmarking. Tegenstrijdig hiermee is de perceptie van de deelnemers aan het onderzoek dat de balans tussen de druk op kostenbesparing en IT-effectiviteit goed is. Een klassiek geval van het uitvergroten van kleine positieve bevindingen en het bagatelliseren van zaken waar we liever niet voor uitkomen."

Gissen is missen
Goed IT-bestuur heeft volgens Verhoef vijf zaken echt op orde. "1) Data. Je kunt niet besturen zonder historische gegevens en forecasting. Met behulp van data creëer je transparantie. 2) Controle. Je hebt regels nodig. Welke dat moeten zijn wat hun effect is, hangt af van de organisatie. 3) Budget. Geld is altijd aanwezig in een eindige hoeveelheid. Datzelfde geldt voor 4) tijd en 5) functionaliteit, want anders loopt een en ander uiteraard niet. Het liefst valt een IT-project binnen budget en planning vallen en voldoet het aan bepaalde eisen. De accuratesse van je projectplanning is een indicatie van de stabiliteit van je project. Het voornaamste is en blijft dat een project toegevoegde waarde levert. Enige kostenoverschrijding hoeft dan geen enkel probleem te vormen. Volgens het genoemde onderzoek scoren IT-organisaties slecht op deze vijf punten. Iedereen kent en onderschrijft het adagium 'Meten is weten' of 'What gets measured gets managed'. Aardige variaties daarop zijn 'Gissen is missen', of wat dacht je van 'Gokken is dokken'. Je moet dus data hebben, maar je moet er ook weer niet onder bedolven raken. De gegevens waarop je stuurt moeten ergens betrekking op hebben en je moet de betrouwbaarheid kennen."

Datapatronen en deadlines
Verhoef licht een aantal herkenbare patronen toe die helpen bij de analyse van data. Aan het overperfecte datapatroon (figuur 1) zie je direct dat de weergave van de werkelijkheid te mooi is om waar te zijn.

Een correlatie van bijvoorbeeld 100 procent tussen de schatting van het aantal gewerkte uren en de feitelijk gewerkte uren, is op zijn zachtst gezegd verdacht. Daar kun je maar beter niet op sturen. Zelfs in een sterk gecontroleerde situatie is het de normaalste zaak ter wereld om 10 procent zogeheten 'stray values' te hebben in je data. Het heterogene datapatroon (figuur 2), ook wel een 'hagelschotcurve' genoemd, is het omgekeerde van overperfecte data.

De correlatie in het voorbeeld van figuur 2 tussen productiviteit en omvang is nagenoeg nihil, terwijl je bij toegenomen omvang van een IT-project lagere productiviteit zou verwachten omdat er meer communicatie nodig is. Met deze data moet nog iets worden gedaan, wil het enige betekenis krijgen. Bij veel organisaties overschrijdt de meerderheid van de projecten de deadline. "Aan iedere deadline", vertelt Verhoef, "zit een kanselement. Wanneer je deadlines kiest op basis van de klassieke definitie – the first non-zero probability: de eerste gelegenheid waarop de waarschijnlijkheid op het halen van de deadline hoger dan nul is – weet je bijna zeker dat je erover heen gaat. Kies je daarentegen voor een deadline die evenveel kans heeft om gehaald te worden als om overschreden te worden, krijg je een andere voorspellende waarde waar je beter op kunt sturen." Verhoef laat een voorbeeld zien van een IT portfolio database van 495 IT-projecten met hun kosten en doorlooptijd. Na een aantal analyserende handelingen valt op dat de doorlooptijd van de meeste projecten verdacht dicht tegen 6, 12 of 24 maanden aan zitten. "Dat is vreemd", meent Verhoef. "Je zou verwachten dat een klein project lagere kosten heeft dan een groot project, maar dat zien we in deze data nauwelijks terug. De kosten bij bepaalde tijdsintervallen zijn hier nagenoeg willekeurig. Nadere bewerking van de data bewijst dit. Bijna de helft van de projecten die tegen de 6 maanden aanschurken zitten qua kosten in dezelfde range als de helft van de projecten die op 12 maanden zitten. Hieruit kun je opmaken dat de helft van alle 12-maanden-projecten qua kosten net zo goed 6 maanden hadden kunnen duren. Dat klopt natuurlijk niet, want als een project langer duurt, gebruik je meer kostbare resources. Deze gegevens komen niet overeen met de wetmatigheid dat een langduriger project duurder zou zijn dan een korter project. Hier is duidelijk iets aan de hand."

De hydraulische softwarewet
Verhoef tilt één voorbeeldproject uit de databrij: de ontwikkeling van een informatiesysteem, duur: 12 maanden, kosten: 1 miljoen dollar. "We constateerden al dat langdurige projecten normaliter duurder zijn dan kortdurende projecten. Wanneer je een project met een technische doorlooptijd van 12 maanden drastisch sneller wilt afronden, nemen de kosten ook drastisch toe. Dit principe – uitgevonden door Putnam & Putnam – kunnen we uitdrukken in een formule, die ik de hydraulische softwarewet noem, naar de natuurkundige wet van het opbouwen van vloeistofdruk om te kunnen remmen bijvoorbeeld. Door het verkorten van de doorlooptijd, neemt de kostendruk toe met een macht van bijna 4. Het opvoeren van de tijdsdruk geeft dus enorme kostenexplosie. Vergelijken we ons voorbeeldproject met een benchmark dan blijkt het project te duur en qua tijd te krap gepland. Het naar achteren verschuiven van de deadline maakt het project goedkoper. Je kunt aan de hand van de 'isobaren' van de benchmark en die van het voorbeeldproject zelfs berekenen dat wanneer je twee weken langer over het project zou doen, je dan 13 procent kosten kunt besparen. Het analyseren van dergelijke kosten/tijd plaatjes helpt je enorm om in je projectportfolio de juiste prioriteiten te stellen en geld te besparen. "

Niet alleen meer kostenpost Verhoef toont een andere kosten/tijdgrafiek waar 50 IT-projecten in staan afgebeeld, met een gezamenlijk budget van 41,3 miljoen dollar. "Van deze businessunit", licht hij toe, "werd gezegd dat ze te duur waren. Niemand kon evenwel aantonen waar dat aan lag, wat er goedkoper moest en hoe ze dat moesten doen. Om dat inzichtelijk te maken heb ik ieder project vergeleken met de benchmark die het best aansluit bij deze specifieke situatie en er de hydraulische softwarewet op toegepast. De uitkomsten wijzen uit dat de portfolio van deze businessunit sterk lijdt aan tijdcompressie. Alle projecten liggen ruim boven de benchmark qua prijs en tijd. Als we dat transponeren naar de benchmark blijkt dat wanneer we in totaal 105 maanden meer zouden uittrekken voor de projecten, dus 12 procent meer tijd, we dan 15 miljoen dollar kunnen besparen, ofwel 36 procent. Voor alle duidelijkheid, dit betreft een academische berekening, want je kunt uiteraard niet zeggen dat je al je projecten volgens benchmarks gaat doen. Maar het biedt wel inzicht. In dit geval werd duidelijk dat de businessunit duurder uit is omdat de projecten op tijd werden gemanaged. Een businesscase en betrouwbare data zijn onmisbaar om goede beslissingen te nemen. Dat iets gisteren af moet zijn, kan een hele goede businesscase zijn. Maar het kan nooit de bedoeling zijn om alles te managen op time-to-market. Niet elk IT-project is namelijk tijdkritisch. Dat worden ze wanneer managers bijvoorbeeld noodzakelijke projecten degraderen tot niet-strategisch, waardoor ze van hun radar verdwijnen. Deze projecten worden veel te laat opgestart waardoor het death-march projecten worden: missions impossible met navenant hoge kosten, schreeuwend hoog risico en de bijna-garantie van reputationele schade."

Nog altijd worden veel IT-projecten zonder business case gemanaged. Mede hierdoor houdt het imago van de IT-afdeling als kostenpost hardnekkig stand. Bewuste afwegingen omtrent risico's, tijd en kosten maken betere sturing mogelijk en dragen ertoe bij dat IT sneller zal transformeren van noodzakelijk kwaad naar leverancier van toegevoegde waarde.

De input van dit artikel is afkomstig van een toespraak die Chris Verhoef hield tijdens een rondetafel over Time to Market die DigitalBoardroom organiseerde in samenwerking met CA.

Dit artikel is verschenen in het tijdschrift TIEM, nr 25, mei 2008.