Gouden regels voor ICT projectbeheerGouden regels voor ICT projectbeheer(klik voor origineel formaat)

De drie gouden regels voor succesvol IT-projectbeheer

20 september 2010

Veel IT-projecten mislukken of leveren niet op wat ze beloven. Zo laat de Chaos Summary 2009 van de Standish Group uit april 2009 zien dat:

  • 24 procent van de projecten wordt afgebroken vóór afronding;
  • 44 procent van de projecten het budget overschrijdt (gemiddeld 1,9 keer),te laat is of niet de volledige scope levert;
  • en 68 procent van de projecten niet aan de verwachtingen voldoet.

Opmerkelijke cijfers die vreemd genoeg in de sector niet tot heel veel ophef leidden. Maar stel dat iemand op de trein naar Amsterdam Centraal stapt en zes van de tien keer in Rotterdam uitkomt. Of stel dat een online boekwinkel in de helft van de gevallen wel de schrijver goed heeft, maar niet de juiste titel stuurt. Een reiziger of klant kiest dan uiteraard heel snel voor een alternatief. En terecht. Ook in de IT is er een alternatief door de volgende drie gouden regels voor IT-projectbeheer te volgen. Ze zijn gebaseerd op de Theory of Constraints (TOC) van Eliyahu Goldratt en toegespitsts op IT-projectbeheer.

1.       Benoem het probleem dat opgelost moet worden zeer nauwkeurig

Een belangrijke reden voor het stranden of verzanden van IT-projecten is gebrek aan reflectie vooraf. In de westerse wereld zijn we geneigd om meteen in oplossingen te denken. We zien een probleem en bedenken onmiddellijk een oplossing. Dat gebeurt maar al te vaak zonder echte analyse. Wat is de kern van het probleem? Is het eigenlijk wel een echt probleem? Hebben we er werkelijk last van? En lost de gekozen route het probleem werkelijk op? Als we die vragen grondig doornemen, voorafgaand aan een IT-project, zijn verrassende uitkomsten mogelijk. Misschien is het probleem veel kleiner (of groter) dan we dachten. Of lost een flinke investering in hardware en software het in ieder geval niet op. Een eerste voorwaarde voor een succesvol project is dus grondig verifiëren wat het probleem is zonder nog aan concrete oplossingen te denken.

2.      Stel de scope van het project vast en houd je eraan

Een andere belangrijke reden voor het mislukken van IT-projecten is een gebrek aan controle op de afspraken die rond een project zijn gemaakt. Daardoor ontstaan gemakkelijk ‘uitstapjes’ naar zaken die niet ‘need to have’ maar ‘nice to have’ zijn. Deze uitstapjes zijn ongepland en zorgen daardoor heel gemakkelijk voor vertraging. Gedurende een IT-project is dus een continue focus op het einddoel nodig. Dit einddoel moet waarde toevoegen aan de organisatie. Het gaat erom dat een organisatie zich tijdens een project blijft richten op die waarde door vragen te blijven stellen. Zijn bijvoorbeeld nieuwe inzichten die binnen het project ontstaan inderdaad nodig om het einddoel te bereiken of introduceren ze een onnodige omweg? In de praktijk betekent dit dat een wijzigingsverzoek beoordeeld wordt op twee kenmerken:

A. Is de wijziging nodig om het probleem op te lossen? Zo ja, dan hoort de wijziging binnen de scope en wordt hij met ongewijzigde opleverdatum en budget meegenomen om het beloofde rendement te realiseren.

B. Voegt de wijziging waarde toe aan de oplossing en is die waarde hoger dan het (negatieve) effect op doorlooptijd en budget? Is met andere woorden de ROI netto hoger als de wijziging wordt meegenomen? Zo ja, dan honoreert de organisatie de wijziging en worden opleverdatum en budget aangepast om een hoger rendement te realiseren.

Is het antwoord bij beide kenmerken ‘nee’, dan wordt de wijziging terzijde geschoven. Afspraak is afspraak: afwijken van afspraken die gemaakt zijn ten aanzien van een IT-project zijn alleen logisch en verklaarbaar als het project meer rendement kan realiseren dan vooraf verwacht en gedacht. Op deze manier is het maximale te behalen uit IT-investeringen.

3.      Zorg voor de juiste planning

Projectactiviteiten kenmerken zich door veel onzekerheid over de activiteiten die binnen processen uitgevoerd worden. Deze onzekerheid brengt met zich mee dat activiteiten gepland worden met een zekerheidsmarge in de vorm van een (onzichtbare) tijdbuffer. Een planner neemt dan extra tijd om die onzekerheid op te vangen. Die keus is de ideale voedingsbodem voor het zogenaamde ‘Student’s Syndrome’. Naarmate iemand meer tijd heeft voor een activiteit, begint hij of zij daar later mee. In de meeste gevallen als de deadline echt nadert. In de tussentijd voert de persoon andere activiteiten uit, maar het is sterk de vraag of die werkelijk waarde toevoegen. Het is beter om een reële planning te maken en bijvoorbeeld zestig procent van de tijd in te delen en veertig procent achter de hand te houden als buffer. Door dit ‘snelkookpan’-concept is er voor de projectmedewerkers geen mogelijkheid om activiteiten uit te stellen. Zij blijven gefocust op het project. Binnen de IT-variant van de Theory of Constraints heet deze aanpak Critical Chain Project Management. Dat leidt ertoe dat taken die meevallen, bijdragen aan de versnelling van het project, terwijl een organisatie taken die tegenvallen snel signaleert en kan opvolgen. Projecten zijn op die manier in minder tijd en met grotere zekerheid op de afgesproken datum op te leveren.

Een ander aspect van planning is de klassieke manier om maximale output te realiseren. Daarbij plant de organisatie alle beschikbare resources helemaal vol. De gedachtegang hierbij is dat als iedereen bezig is, dit resulteert in optimale capaciteitsbenutting. Dat is echter één kant van het verhaal. De Theory of Constraints leert dat wanneer er sprake is van ketens van afhankelijke taken niet iedereen op ieder moment evenveel kan bijdragen aan het realiseren van nuttige output. Wanneer een organisatie de stroom van projecten in kaart brengt, zijn er typisch één of een klein aantal knelpunten te herkennen die de output limiteren. Dit is op te lossen door staggering. Hierbij stemt een organisatie de stroom aan projecten af op de knelpunten in de organisatie. Als de knelpunten maximaal benut worden, realiseert de organisatie een maximale output.


Met de theorie van Goldratt zijn in de productiesector opmerkelijke resultaten behaald. Hetzelfde geldt inmiddels voor de IT-sector waar de variant TOC-IT – ontwikkeld door Garansys – zorgt voor concreet resultaat bij IT-projecten. Het bedrijf onderstreept dit door garanties af te geven voor het op tijd en binnen budget opleveren van projecten.

Bookmark and Share
Garansys on LinkedIn