IT-projecten: Eerst proberen, dan doen!

IT-projecten hebben een slechte reputatie. Ze duren te lang, kosten te veel en leveren te weinig op. Welbeschouwd is het een wonder dat er nog zoveel IT-projecten slagen. Want de manier waarop grote IT-projecten worden aangestuurd moet fundamenteel anders.

Veel projecten worden gestuurd op een vooraf bepaalde begroting in tijd en geld: dít moet het resultaat zijn, het mag zoveel kosten en dán moet het af zijn. Dat kan werken, maar alleen als er een realistische planning en schatting is gemaakt en er onderweg niet te veel verandert. En dat is zelden het geval. Te vaak is een projectbegroting gebaseerd op magisch denken: als we hard genoeg hopen, wordt het vanzelf waar. Neem de minister die onder druk in de kamer een datum noemt waarop ‘het probleem is opgelost’. Of een projectgroep die een bedrag in het ‘project initiation document’ zet waarmee de stuurgroep kan leven. Of de leverancier die een scherpe offerte afgeeft om concurrenten de loef af te steken. Met een goed beeld van het eindresultaat en van wat er nodig is om dat te bereiken, heeft zo’n begroting weinig te maken.

DOE-projecten

Niet dat schatten en plannen voor ieder IT-project onmogelijk is. Van een leverancier die in het derde ziekenhuis een ERP-implementatie uitvoert, mag je verwachten dat hij een beeld heeft van hoe lang zoiets duurt en wat het gaat kosten. Er is duidelijk met welk soort systemen er gekoppeld moet worden en wat de impact is voor medewerkers – en de leverancier brengt mensen mee die ervaring hebben opgedaan in vergelijkbare projecten. Dat betekent niet dat zo’n project eenvoudig is. Er gebeuren altijd onverwachte dingen. Maar in de regel volstaan degelijk projectmanagement en aanverwante maatregelen daarvoor. Dit zijn ‘doe-projecten’: projecten met weinig onzekere factoren, die je met vertrouwen kunt aanpakken.

Veel IT-projecten kennen echter onzekere factoren die het schatten bemoeilijken. Een grote ambitie, een nieuwe leverancier, hippe technologie of veranderende werkprocessen zijn maar enkele voorbeelden. In zo’n situatie schieten de foutmarges in de schattingen omhoog. Stug vasthouden aan een vooraf bepaalde begroting leidt dan vanzelf tot mislukking. De controlemechanismes verder opschroeven werkt averechts: strenger toezicht, meer controle, vaker rapporteren, het stuurt het project alleen maar sneller zijn ondergang tegemoet.

Probeerprojecten

Voor zulke projecten is een aanpak nodig waarin je niet schematisch maar verkennend te werk gaat. Dat betekent: kleine stappen zetten. Alternatieven uitproberen om te kijken welke kansrijk zijn. Het doel bijstellen op basis van de opgedane ervaringen. Niet krampachtig doorgaan, maar (liefst vroeg) durven stoppen en de investering zien als vergoeding voor een leerervaring. En vooral: niet op dag één een einddatum en bedrag afgeven en je daarop blindstaren. Dit gaat verder dan agile werken.

De verkennende aanpak van ‘probeerprojecten’ betekent dat de opdrachtgever en andere belanghebbenden onzekerheid accepteren en daarmee om kunnen gaan. Het is cruciaal voor het succes van een project om te weten of je met een doe- of een probeerproject te maken hebt. Doe-projecten kun je gewoon doen – hoewel je onderweg scherp moet blijven op nieuwe onzekere factoren waardoor je afdwaalt naar onbekend terrein. Probeerprojecten moet je niet doen, maar proberen. Dit moet ook terugkomen in de projectaanpak: goede (en continue) risico-inschattingen, inzetten van mitigerende maatregelen en regelmatige reflectie op fundamentele vragen: is de aanpak nog goed? Moeten we andere stappen nemen? Moeten we wellicht stoppen? Dat gaat niet zozeer om lef – stoppen moet een normale en realistische uitkomst kunnen zijn. Het is ook cruciaal om te herkennen of de cultuur klaar is voor een probeeraanpak. Zo niet, vlucht dan niet in schijnzekerheid, maar neem onzekerheden weg tot er een doe-project overblijft dat wel planbaar is. Bijvoorbeeld door niet de nieuwste technologie te kiezen, maar genoegen te nemen met technologie waarmee de organisatie vertrouwd is.

Door opnieuw met een bekende leverancier samen te werken. Of door het project op te breken in meerdere kleine projecten en die na elkaar uit te voeren. Elk kleiner doe-project kan een deelresultaat opleveren en onzekerheden verkleinen of wegnemen. Weersta in elk geval de verleiding om een complex project op te breken en de kleinere projecten parallel uit te voeren in een programma. Dan neem je de onzekerheden niet weg, maar verplaats je ze naar het programmaniveau.

Te snel te groot

Voor veel van de IT-projecten die als mislukt in het nieuws komen, is de vraag gerechtvaardigd of ze niet ten onrechte als doe-project zijn aangepakt. Vanaf dag één gingen ze in volle omvang voor jaren aan de slag, terwijl er zoveel onzekere aspecten speelden dat proberen beter op zijn plaats was geweest. In plaats daarvan is doormarcheren de norm, tot de begrote tijd en het geld op zijn en het hele project als falend IT-project wordt afgeblazen. Bij een probeeraanpak was er niets ‘mislukt’, maar hadden we tegen beperkte inspanning en kosten kunnen leren wat in ieder geval niet werkt. Om vervolgens constructief verder te zoeken naar oplossingen die wél succesvol zijn. Maar vaak wordt achteraf vooral naar zondebokken gezocht: de minister belooft beterschap, de projectgroep heft zichzelf op, de leverancier gaat op zoek naar zijn volgende klus.

Erkennen dat er onzekerheden zijn, is moeilijker dan het lijkt. In de politiek wordt professionele nuance nogal eens verward met een gebrek aan daadkracht. In de pers scoren pittige oneliners beter dan mitsen en maren. Kritisch tegengeluid laten horen is slechter voor je cv dan een gefaald miljoenenproject. In offertetrajecten leggen realistische bandbreedtes het af tegen een lage, vaste prijs. Zo blijven we de mislukte IT-projecten krijgen die we verdienen.

Laat u gegevens achter voor de 7 waarschuwingssignalen om de kans op succesvolle ICT-projecten te vergroten!