ICT-Projecten: Theorie en Praktijk

Het is een feit: van de praktijk van ICT-projecten wordt niemand vrolijk. Een overgrote meerderheid van projecten levert niet op wat er vooraf van werd verwacht en kosten veel meer dan vooraf werd begroot. Wat zijn de redenen? Wat zijn de achtergronden? Waarom leveren de gestructureerde methodes zo weinig op? Op welke manier kunnen gestructureerde methodes wel toegevoegde waarde opleveren? Wat staat ons nog te wachten? In dit artikel zullen we op deze vragen ingaan.

Een groot aantal projecten wordt, als je het zakelijk probeert te objectiveren, tegen beter weten in gestart of voortgezet. De meeste van deze projecten zijn vanaf het begin al gedoemd te mislukken. Waarom worden ze dan toch gestart? En waarom worden na maanden, zo niet jaren van geldverspilling dan toch voortgezet?

Antwoorden op deze vragen vallen in verschillende categorieën. Het begint vaak al met het probleem van de projecteigenaar. Iemand die het eindresultaat bewaakt in termen van kosten en opbrengsten. Veel projecten missen deze persoon, want daar is toch de projectmanager voor? De projectmanager is er voor het uitwerken van de opdracht, niet voor het vaststellen van de opdracht en bewaken dat het project volgens de opdracht werkt en blijft werken. Wanneer de bewaking ook in handen van de projectmanager wordt gelegd, zijn uitvoering en controle bij één persoon samengebracht en is het resultaat voorspelbaar: het project gaat zijn eigen gang en bijsturing vindt naar believen van het projectteam plaats zonder dat dit wordt afgestemd. In zeer veel projecten bepaalt de projectmanager wat het eindresultaat moet zijn met als gevolg aan het eind een resultaat waarmee niemand gelukkig is of – erger nog – een onbruikbaar resultaat. In dit geval moet je jezelf ook afvragen waar de planning van het project op is gebaseerd. Meestal op los zand want van tevoren is niet goed gedefinieerd wat het projectresultaat zal zijn.

Een andere categorie is het soort projecten waar de leverancier het project initieert. Dit soort projecten kent vaak een interne leverancier of wordt gestart vanuit de situatie dat een beslisser in een organisatie overtuigd wordt om mee te gaan in een technische ontwikkeling die breed wordt toegepast. Denk bij dit laatste aan de golf van ERP invoeringen. Hoe dan ook, deze projecten worden veelal niet vanuit heldere zakelijke belangen gestart. In deze gevallen wordt bij de technische oplossing een vraag gezocht. In deze gevallen zal de opdrachtgever, maar ook de gebruiker zich per definitie terugtrekken, afgezien van een enkele enthousiaste gebruiker met een bovenmatige interesse in IT. In dit soort projecten zal uiteindelijk niet het belang van de klant vooropstaan, maar wordt voornamelijk vanuit het belang van de leverancier gedacht. Het project wordt veelal, zeker in het geval van een externe leverancier, voorzien van een enorme bezetting die natuurlijk niet gebaseerd is op een harde planning. Vervolgens wordt toch onderkend dat de gebruikersorganisatie een positie in het project moet hebben, want de leverancier onderkent dat het wel erg moeilijk wordt zonder enige sturing van de klant. In overleg met de klant wordt vervolgens een aantal mensen uit de gebruikersorganisatie aan het project toegevoegd, waardoor het projectteam nog meer wordt overladen. Daarbij komt nog dat dit meestal personen zijn met een enorme inzet en hart voor de zaak, maar met een beperkte visie en een grote starheid over hun manier van werken. Het resultaat van door de leverancier gestuurde projecten is niet mooi: een project dat een heel lange doorlooptijd heeft en zeer veel geld heeft gekost. En ook hier weer een resultaat oplevert waarmee niemand gelukkig is. Na een dergelijk project heeft iedereen boter op zijn hoofd en daarom wordt vervolgens alom verklaard dat het project een enorm succes was, maar de relatie tussen klant en extern leverancier wordt vrij snel beëindigd. De interne medewerkers aan het project worden, voor zover ze zich niet hebben kunnen indekken, tot zondebok benoemd (stilzwijgend want je kunt hiermee natuurlijk niet toegeven dat het project mislukt was) en zullen binnen de organisatie op een dood spoor terecht komen en waarschijnlijk uiteindelijk vertrekken.

Vaak zie je ook dat een dergelijk project vrij snel wordt opgevolgd door één of meerdere kleinere projecten die als doel hebben om met kleine aanpassingen toch nog te komen tot een werkbare oplossing. De resultaten van deze kleinere projecten leveren meestal veel op maar het zijn geen structurele oplossingen voor de problemen waarin een organisatie is beland.

Een bijzondere variant van de inmiddels beschreven projecten, is het “gedwongen” project. Iedereen kan zich nog de “Jaar 2000” projecten en de Europrojecten herinneren. Deze projecten waren veel al technisch van aard, leverden zakelijk niets op (behalve dan dat een bedrijf bij niet uitvoeren problemen kreeg) en werden veel al overgelaten aan de technisch specialisten. De gebruikersorganisatie wilde er veelal niet veel mee te maken hebben. Omdat deze projecten een duidelijk doel hadden, viel het met de negatieve resultaten meestal mee. Probleem voor de projectmanager is bij dit soort projecten dat er altijd een planning is die enorm onder druk staat. Omdat er geen positieve reden voor het project is, zijn partijen geneigd het project zoveel mogelijk uit te stellen en pas op het allerlaatste moment actie te ondernemen.

In 1997 bracht IT goeroe Edward Yourdon een uitstekend en ondanks de serieuze en potentieel deprimerende materie toch amusant boek uit over het wel maar vooral over het wee van dit soort projecten. Yourdon beschreef “Deatch march” projecten, projecten die, wanneer onderworpen aan een onpartijdige en objectieve beoordeling, een kans van meer dan 50% hebben om te falen. Ondanks dat we al weer jaren verder zijn, is de boodschap van Yourdon nog altijd actueel, misschien zelfs actueler dan ooit.

Yourdon schetst een somber en enigszins gechargeerd beeld van projecten die op deze wijze mislukken en ook vaak slachtoffers eisen. Het beeld wat hij schetste is echter nog altijd zeer herkenbaar. Een aantal citaten uit de inleiding:

Over de software industrie: “not a mature industry”. Het wordt vaak gezegd van de IT sector: de sector is nog verre van volwassen. De vergelijking met de bouw wordt dan gemaakt en de conclusie is dat de bouw veel beter is in het plannen en beheersen van project door een jarenlange ervaring en een veel grotere standaardisering. Maar is de bouw wel zo vergelijkbaar met de IT sector?

Over projecten: “In other words, death march projects exist because we’re stupid or incompetent”. Yourdon schrijft mislukkingen in IT projecten in hoge mate toe aan incompetentie. Helaas moet ik Yourdon hier gelijk geven. De gemiddelde IT-er is extreem eigenwijs. Wanneer we dan eindelijk een gestructureerde methode hebben die werkt (en geloof me, die zijn er echt geweest), dan was de betreffende methode geen lang leven beschoren. Naar de prullenbak ermee: te omslachtig, dan kan toch in de praktijk nooit werken? “Conclusion: Death march projects occur because senior manager are Machiavellian bastards and / or because our users are naïve and unrealistic”. Hoewel de schrijvers van dit artikel de ernst van de situatie zeker onder ogen zien en zich meestal aansluiten bij de visie van Yourdon gaat dit citaat misschien wat ver. Maar feit is wel dat veel projecten lijden onder slecht leiderschap: hinderlijke politiek, onvoldoende betrokkenheid, een speeltje voor de manager.

“I’m convinced that much of this is due to the rapid pace of change, combined with the usual disrespect that each new generation has for the advice offered by the previous generation”. Het is hierboven al gezegd: de sector is nog niet volwassen en de gemiddelde IT-er is bijzonder eigenwijs. Daarnaast is het zo dat gevestigde theorieën over volwassenheid van (IT) organisaties onderkennen dat elke technische vooruitgang een achteruitgang in volwassenheid betekent. Men moet namelijk leren omgaan met de nieuwe gereedschappen. “I’ve come to a sobering conclusion: Death march projects are the norm, not the exception”. Het is blijkbaar volgens Yourdon een realiteit dat projecten een grote mate van chaos in zich hebben. Niets bijzonders, niets om je over druk te maken. En zo is het ook. Een project is uniek, eenmalig, multidisciplinair en heeft bepaalde doelen. Kun je dan echt verwachten dat project een hoge slagingskans hebben? Want als het werk uniek en eenmalig is, is er blijkbaar ook weinig ervaring. En dus is het plannen een probleem en het project per definitie risicovol.

Yourdon schetste dus een weinig florissant beeld. Maar wat zag hij als achterliggende redenen?

Politiek. Vooral in grotere organisaties speelt politiek een grote rol. Doel en middelen van een project worden uit het oog verloren. Het project wordt een speelbal van krachten binnen een organisatie. Het gaat niet meer om de opbrengsten en kosten van een project maar om macht en de status die een project oplevert.

Naïeve beloften. Aan het begin van een project worden vaak gouden bergen beloofd. Het project zal weinig kosten, maar de opbrengsten zullen geweldig zijn. En wie hier niet in meegaat, is een zeur of erger nog: negatief. Een probleem hierbij is dat de belofte vaak wordt gemaakt door iemand die er niet op wordt afgerekend, de verkoper van een project die niet verantwoordelijk is voor het opleveren. Een risicoanalyse, toch één van de belangrijke activiteiten in ieder project, is in deze situatie niet mogelijk. De uitkomst wordt per definitie niet serieus genomen.

Naïef optimisme. Dit heeft grote overeenkomsten met het vorige punt. Hier wordt echter het blinde en onrealistische enthousiasme aangedragen door degene die het project moet uitvoeren. “Ja natuurlijk! Dat kunnen we wel even doen! Klaar in een weekje!” De ervaren rot kijkt ernaar en huivert. Misschien lukt het ook nog wel maar wat is het resultaat? Documentatie, gebruiksvriendelijkheid? Details die toch niet echt noodzakelijk zijn? En testen? “Wel nee, niet nodig.”

Avontuurlijke mentaliteit. Mensen, en zeker de minder ervaren IT-ers, worden onweerstaanbaar aangetrokken door nieuwe ontwikkelingen. En vervolgens gaan ze er ook helemaal voor. Plannen, heldere doelen: in het enthousiasme schiet het er helemaal bij in. Wat resteert is een ongecoördineerde set van activiteiten en veel ad-hoc werkzaamheden. Projecten waarin deze mentaliteit de overhand heeft, komen meestal voort vanuit de techniek.

Macho mentaliteit. “Niet zeuren, een echte kerel heeft geen slaap nodig! Als je niet met de druk kunt omgaan, hoor je hier niet!” Vanwege een volstrekt onrealistische planning, en erger nog onrealistische of zelfs niet beschreven doelen, wordt vanuit het management een enorme druk uitgeoefend op de mensen binnen het project. Dit gedrag zie je vaak bij (grotere) consultancy organisaties en wordt gevoed vanuit concurrentieoverwegingen. “Wij zijn beter dan de rest en kunnen het sneller!” Jammer alleen dat dit soort projecten meestal sneller resulteren in chaos en ontevreden klanten.

Intense concurrentie door de alsmaar snellere en grotere wereld. Tijdens de Internet hype werden in hoog tempo nieuwe producten in de markt geïntroduceerd. Denk aan on-line bankieren of de Internet boekshops. Om de concurrentie aan te kunnen letten alle partijen op elkaar en werd razendsnel gereageerd om ontwikkelingen bij concurrenten.

Intense concurrentie door nieuwe technologie. Ook hier geldt het Internet als recent voorbeeld. Wanneer nieuwe technologie ontwikkelingen mogelijk maakt, komt er een enorme drive om ook gebruik te maken van nieuwe ontwikkelingen. Maar wat als die nieuwe ontwikkelingen nog niet zijn uitgekristalliseerd? Een project dat is gebaseerd op technische beloften die nog niet perfect werken, trekt een zware wissel op alle betrokkenen. Vooral wanneer bij zo’n project ook nog eens sprake is van politiek en naïef optimisme.

Grote druk door maatregelen van de overheid. Zowel bij projecten binnen de overheid als daarbuiten is er sprake van een verplicht project. Er is sprake van een nieuwe wet of van nieuwe eisen die de overheid bedrijven oplegt. In mijn eigen praktijk heb ik meegemaakt dat een directeur van een gemeentelijke dienst zonder enig overleg een nieuwe faciliteit beloofde en een planning afgaf aan de politiek en daarna pas opdracht gaf voor een ondersteunend bedrijf zonder ook maar te informeren of zijn planning überhaupt mogelijk was. Overigens is het ook zo dat wanneer er ruim voldoende tijd en ruimte is voor dit soort gedwongen projecten, de natuurlijke drang tot uitstel bij mensen overneemt. Hoeveel Euro projecten werden pas op het allerlaatste moment gestart? En het uitstel tot het laatste moment was niet anders bij een andere soort projecten van een gedwongen aard: de “Jaar 2000” projecten.

Onverwachte en ongeplande crises. Natuurlijk gebeuren er onverwachte zaken in een project, maar waarom leidt dit vaak tot grote problemen in een project? Wederom vanwege de natuurlijke drang tot uitstel waardoor noodzakelijke maatregelen niet op tijd worden genomen.

Herkenbaar? Natuurlijk. Iedereen die wel eens aan een project heeft deelgenomen, herkent deze symptomen en aanleidingen. Maar wat heb je er nu aan? Niet veel. In projecten gaat het nu eenmaal zo en zal het ook zo blijven gaan. Maar wanneer je achterliggende oorzaken ervan bewust herkent, kun je er beter mee omgaan. Misschien zal het je zelfs helpen om te voorkomen dat je de volgende keer weer in zo’n hopeloos project terecht komt. Maar deze hoop is meestal theoretisch, tenzij je jezelf onmogelijk wilt maken bij je collega’s en werkgever.

De projecten die Yourdon beschreef als “Dead march projecten”, hadden alle dezelfde problemen: de doelen raakten gaandeweg op de achtergrond en andere prioriteiten namen over. Projecten raakten onbeheersbaar en de motivatie viel weg. Het gaat voor de projectleden niet meer over het projectresultaat, maar over het overleven van het project.

Deze tekst is samengesteld door Management Start.
(c) 2005

Reageer op dit artikel...