Wat is het dat grote IT/ICT projecten zo vaak mislukken? Wat maakt dat grote projecten regelmatig het nieuws halen vanwege bijna hilarisch-grote tijds- en budgetoverschrijdingen?
Grote IT / ICT projecten
Met name grote IT / ICT projecten leveren vaak treurige, bijna lachwekkende voorbeelden op van mismanagement. Het is niet voor niets dat er onder projectmanagers de grap rondgaat: “het getal Pi gebruik je bij het berekenen van omtrek en oppervlakte van cirkels. Maar ook bij de overschrijdingsgraad van tijd en budget van grote projecten”.
Overschrijdingen door te hoge ambities en verwachtingen, slechte voorbereidingen, een bestuurlijke desinteresse en dientengevolge een gebrek aan aansturing en mismanagement.
In de afgelopen jaren is steeds duidelijker geworden dat grote, steeds veranderende opdrachten geeft, en dat bedrijven die zonder morren uitvoeren. De eindverantwoordelijken ontdekken pas veel te laat dat hetgeen ze oorspronkelijk hebben besteld, niet naar wens werkt. Reden is maar al te vaak dat als een opdracht eenmaal is verstrekt, de belangstelling bij verantwoordelijke ministers en hoge ambtenaren wegzakt. Lagere ambtenaren kunnen het verder opknappen. En die blijven aanmodderen totdat het op een gegeven moment echt niet meer gaat.
De 7 Gouden Regels voor Projectsucces
Vanuit historisch perspectief en ruim beschikbare praktijkervaring kunnen we een zevental ‘regels’ – ‘gouden regels’ – opstellen om tot een zo goed mogelijk projectsucces te geraken.
1. Opdrachtgeverschap
Het liefst heb je als project team een dedicated opdrachtgever die z’n rol op de klassieke wijze invult. Een opdrachtgever die als een bok op de haverkist op het project zit, vanaf het begin tot het einde. Een opdrachtgever die vanaf het begin blij is met wat er gebeurt in het project, omdat door het team helder en duidelijk aan de oplossing van het aangegeven probleem wordt gewerkt. Eentje die ervan overtuigd is en blijft dat aan het einde van het project het probleem naar aller tevredenheid zal zijn opgelost.
Een opdrachtgever dus die serieuze eigenaarschap uitoefent. Een opdrachtgever ook die leiderschap vertoont, korte communicatielijnen hanteert en knopen durft door te hakken als dat nodig is. Die niet bang is om keuzes te maken en besluiten te nemen, wat sowieso aan de orde is in een project. Omdat in een project het team altijd te maken krijgt met (nog niet bewezen) innovaties, onzekerheden, niet ingecalculeerde issues en tegenvallers.
Dan is het ook wel geruststellend als de opdrachtgever voldoende diepe zakken heeft. In andere woorden, voldoende resources ter beschikking heeft om extra werk en uitgaven op te kunnen vangen en eventueel extra mensen in te kunnen schakelen.
2. Scope en plan
Bij het opzetten en formuleren van een project tis het overdenken van het Wat en het Hoe van groot belang. Om goed na te denken over de scope en het plan c.q. de planning. Wat dient er volgens de verkozen scope allemaal te gebeuren, wat hoort wel bij het project en wat niet, en wanneer is iets goed-genoeg?.
Qua plan of planning is het belangrijk de tijd in de gaten te houden. Ervaren projectmanagers weten dat de tijd zo tussen de vingers wegglipt, als je niet oppast. Het opstellen van een goed tijdpad is een kunst mop zich. Het project opstarten met een (nieuw) team vereist – zeker in het begin- de nodige aandacht en communicatie. Een strak aansturen, een wekelijkse meeting met feedback en feed forward en een goed oog op het functioneren van het team, zijn een must do voor de projectmanager.
3. Twee koplampen
Dan de 2 Koplampen. Uit de literatuur komt naar voren dat er twee koplampen nodig zijn om “het schip veilig de haven binnen te loodsen”. De eerste is, zoals voornoemd, een dedicated opdrachtgever die boven op het project zit. Die serieuze eigenaarschap uitoefent en knopen durft door te hakken. Die voldoende steun en vertrouwen van de organisatie ondervindt om het project tot het einde toe te leiden. en het eindproduct verwelkomen, omarmen en volhartig willen implementeren.
De tweede koplamp is een projectteam dat ‘het kunstje’ al eens eerder heeft gedaan. Die daarmee kennis en ervaring heeft opgedaan met dit type projecten. Die praktisch, intuïtief en wijs weet te handelen daar waar het nodig is. Een team dat samenwerken en kwaliteit hoog in het vaandel heeft staan. Een team ook die weet wanneer ‘vers’ bloed nodig is om succesvol verder te gaan.
4. KISS principe
Het KISS-principe – Keep It Short and Simple of Keep It Simple and Straightforward – is afkomstig uit de programmeur-wereld. Daar was het in zwang ter vermijding van grote en vooral gecompliceerde programma’s. Het was in feite een vertaling van Dijkstra’s uitspraak “Simplicity is a prerequisite for reliability” (eenvoud is een voorwaarde voor betrouwbaarheid)
Juist bij grote, complexe, dynamische IT / ICT projecten is het zaak om het ‘simpel’ te houden. Om het project als het ware ‘grijpbaar’ te houden. Om ook met kleine, behapbare, ‘mens-maat’ stappen vooruit te gaan, met stappen die betrokkenen ook kunnen vatten.
Het meest fnuikend voor een IT /ICT project is de vraag naar “connectivity”. Naar een koppeling met andere systemen. Naar bestaande systemen die uiterst ingewikkeld, groot en ambigu zijn – helaas vaak ook aardig verouderd – en daarmee om een complexe aansluiting vragen. Een grotere garantie voor een falen is er bijna niet…
5. VUCA
In een VUCA-wereld met een toenemende onzekerheid, complexiteit, dynamiek, disruptieve technologische innovaties, snelle sociaal-economische veranderingen, een steeds nadrukkelijker aandacht voor de Sustainable Development Goals, een gewenste flux, … is het zaak om op tijd stil te staan.
Om frequent en grondig te bezien, te reflecteren, of de oorspronkelijke project-premissen nog wel kloppen. Of de doelen en doelstellingen, de vooronderstellingen en de aannames, de context en stand van zaken qua ontwikkelingen, nog overeind staan c.q. hetzelfde zijn als bij aanvang aangenomen.
Eén van de belangrijkste kenmerken van projectmanagement betreft het indelen van een project in ‘fatsoenlijke’ fasen. Ervaren projectmanagers pleiten ervoor om het gebruikelijke “Go – No Go” principe aan het eind van elke fase om te draaien naar een “No Go – Go” principe: “We gaan niet verder tenzij…”. Ergo: altijd “No Go” en alleen een ‘Go” als alle betrokken partijen akkoord kunnen gaan met een voortzetting van het project…
