Ieder jaar gaat wereldwijd 4300 miljard euro door het putje aan mislukte IT-projecten. Carolien Schönfeld onderzocht dertig rampprojecten en probeerde te achterhalen wat er mis ging. Want van fouten zou je moeten kunnen leren.
Die 4300 miljard is schrikbarend, maar bevat ook de indirecte kosten van gederfde omzet en verlies aan marktaandeel. Want dat punt wil Schönfeld wel graag maken in haar boek Hoe IT-projecten slagen en falen: op het gierend uit de klauwen laten lopen van IT-projecten heeft de overheid niet het alleenrecht. Scala, de groothandel in erotiek-artikelen, betrok in 2004 een splinternieuw distributiecentrum waarvan de IT het liet afweten. Een jaar later was een omzetdaling van tegen de 10 procent het gevolg.
GERECENSEERD:
Hoe IT-projecten slagen en falen
Carolien Lucy Schönfeld
(Academic Service, 159 blz., 24.95)
21 procent mislukt
En zo zijn er elk jaar wel commerciële en overheidspartijen die de mist in gaan met IT. Of we er dan maar mee moeten stoppen? Natuurlijk niet. IT is inmiddels niet meer weg te denken, dus die grote projecten zullen overal worden gestart, om hopelijk iets minder vaak fout te gaan. De statistieken laten wat dat betreft jaar na jaar verbetering zien. Maar over 2010 zijn de cijfers nog steeds niet heel bemoedigend: wereldwijd lukte 38 procent van alle projecten, 21 procent mislukte nog steeds.
Complex, ambitieus, onvolwassen
Hoe dat komt? Schönfeld sprak met verantwoordelijken van handenvol mislukte projecten. Wel op basis van strikte anonimiteit, zo'n nederlaag schreeuw je natuurlijk niet van de daken. Helaas bleven vaak ook de namen van de opdrachtgevers geheim, al zullen IT-insiders hier en daar wel partijen herkennen. De oorzaken van falen zijn velerlei. Te grote complexiteit, te grote ambitie, slecht opdrachtgeverschap, onvolgroeidheid van het product en de onvolwassenheid van de markt zijn de belangrijkste. Die worden aangewezen en door iedereen erkend. Achteraf.
Eigen ervaring
Maar hoe ging het dan precies mis? Schönfeld bevroeg niet alleen anderen, zelf heeft ze ook ervaring met een mislukt IT-project, waar ze instapte na de fusie van twee rijksdiensten voor archeologie en monumenten. Dat liep uit op een herkenbaar pandemonium van vervuilde databestanden, twee culturen, uitbesteding aan derden tegen een te laag budget, onduidelijkheid over de eisen en uiteindelijk een opleverdatum die nog in de toekomst ligt, terwijl het systeem allang niet meer doet waarvoor het bedacht was: monumenten in beeld brengen. Persoonlijke les van de schrijver: stap nooit als stuurgroepleider in een al lopend project, want je haalt je kennisachterstand nooit meer in.
Rollen: Opdrachtgever
Veel brokken worden gemaakt bij de communicatie. Het boek gaat ook daarom uitgebreid in op de verschillende rollen bij een IT-project en de tegenwoordig gangbare methode voor projectmanagement: Prince2 (Projects in controlled environments). De opdrachtgever verzamelt vaak mensen in een stuurgroep, waarbij een projectleider als schaap met vijf poten thuis moet zijn in ict, organisatieverandering, motiveren, aansturen en meer. Dat maakt die job al bijna ondoenlijk. Het helpt wel als die projectleider niet wordt gewisseld, zoals maar al te vaak gebeurt tijdens een project en als hij de steun en vertrouwen van de directie geniet.
Leverancier
Over IT-leveranciers zijn boeken vol te schrijven. Over het algemeen krijgen ze een zeventje van hun klanten voor de kwaliteit van de diensten die ze leveren. Waar het vaak fout gaat bij de aanbieders: enthousiasme over de nieuwe technologie, ontaardend in misplaatst optimisme. Dat leidt tot te strakke deadlines, grote beloften en een te lage prijsstelling voor technologie die uiteindelijk niet doet wat was beloofd. Maar de leveranciers hebben toch ook wel geleerd over waar het bij de klant mis kan gaan. Tegenwoordig vertellen ze het vaker en eerlijker als de wensen of verwachtingen van een klant onvervulbaar zijn. Er is zelfs een meetmethode in zwang geraakt, om als het ware de volwassenheid van de klant in kaart te brengen.
Techniek: niet flexibel
Het fijne van IT: dat het heel goed is in standaardprocessen. Het nadeel: dat gebruikers struikelen over de standaardisatie die IT oplegt. Vaak roept het weerstand op, als enige menselijke creativiteit wordt bedreigd of mensen hun werkwijze moeten aanpassen aan de nieuwe systemen. Kiezen voor een standaardpakket heeft kostenvoordelen, maar het aanpassen kan vaak tot grote extra uitgaven leiden. Zo gaf de Protestantse Kerk Nederland opdracht tot het bouwen van een ledenregistratiesysteem, dat na jaren en drie miljoen euro investeringen moest worden afgeschreven. De aanpassingen waren zó talrijk en zwaar geworden, dat het systeem onwerkbaar traag en onoverzichtelijk was geworden.
Lessons learned
De lessons learned van de kerkorganisatie vormen een aardige boodschappenlijst: aanpassen is vaak meer werk dan nieuwbouw. De ingehuurde projectleiders hadden te weinig kennis van de kerkelijke cultuur. Het ontwikkelmodel voorzag niet in tussentijdse evaluatie door de gebruiker, waardoor ellende te laat aan het licht kwam. Schönfeld zet ook van andere projecten, van de bank Van Lanschot tot een Londense ambulancedienst en P-Direct, het roemruchte HR-systeem waar 130.000 rijksambtenaren onder vallen, de geleerde lessen op een rij.
Health check
Het IT-projectenboek trekt een paar nuttige algemene conclusies uit de her en der geleerde lessen. Een eerste: elke organisatie zou een gedegen zelfonderzoek moeten uitvoeren, alvorens aan een IT-project te beginnen: is er voldoende kennis en ervaring, heersen er geen weerstand of verborgen conflicten rond de verandering? Zo'n health check kan een boel ellende voorkomen, zeker als projectleiders daarna nog zelf de vrije keus hebben voor die cruciale rol. En liefst die klus niet accepteren als nare bijkomstigheid van een nieuwe baan.
ICT architect
Schönfeld vindt ook dat het tijd wordt om het ontwikkelsysteem Prince2 met zijn formele opzet aan te passen voor alle zachte kanten van het proces, waarbij de interactie tussen alle mensen die erbij betrokken zijn, meer aandacht krijgt. Ze ziet bovendien een toekomst waarin, net als in de bouw, opdrachtgever en aannemer standaard een architect als derde partij naast zich krijgen. Als ontwerper, maar ook als onafhankelijke controleur bij het uitwerken van het bestek en de bouw.
Overheid: lastig
Terug naar de overheid, die volgens Schönfeld wel degelijk een groter risico loopt op faalprojecten dan marktpartijen. Het zou helpen als politieke ambitie kan worden ingedamd tot werkbare proporties en termijnen. Directies van overheidsorganisaties zouden niet langer de ICT-beslissingen aan anderen mogen overlaten: zij zouden zelf verantwoordelijk moeten worden voor het slagen en mislukken van het IT-beheer. Een uitvoeringstoets vooraf, die duidelijk maakt of de vaak politiek gedreven ambities haalbaar zijn en een sterke ambtelijke leiding die ook de minister bij de les houdt, zouden behulpzaam zijn.
En dan nu goed?
Hoe IT-projecten slagen en falen is geen lijvig handboek dat, mits goed in praktijk gebracht, alles voortaan in goede banen kan leiden. Daarvoor is het te beknopt. Maar het is gelukkig ook geen sensatie- of griezellectuur over de onmacht en onkunde die je tot in de meest eerbiedwaardige organisaties zult aantreffen. Het zet, goed met casuïstiek onderbouwd, op een rij waar het mis kan gaan. Tot echt nieuwe inzichten leidt dat niet. Maar wie een IT-project op zich af ziet komen heeft na lezing zijn eigen boodschappenlijstje met kritische vragen en do's en don'ts om bij de hand te houden bij een volgende vergadering waar de glorieuze toekomst wordt geschetst die IT de organisatie kan brengen.
