De overheid heeft de besturing en beheersing van ict-projecten niet op orde. Dat kost de belastingbetaler miljarden euro’s. De parlementaire onderzoekscommissie ICT publiceerde vorige week haar onthutsende conclusies.
De overheid krijgt er flink van langs in het eindrapport van de parlementaire onderzoekscommissie ICT. Een greep uit de bevindingen: de overheid heeft haar ICT-projecten niet onder controle, ze heeft onvoldoende inzicht in kosten en baten, kennis en management schieten tekort en de overheid leert niet van fouten.
Zo kan het gebeuren dat projecten jarenlang tegen hoge kosten doormodderen en uiteindelijk mislukken. Terwijl de rekeningen aan de ICT-bedrijven die de opdrachten uitvoerden keurig worden betaald. Een miljardenstrop voor de belastingbetaler. Maar wat is eigenlijk de verantwoordelijkheid van de ICT-bedrijven? Laten zij projecten willens en wetens in de soep lopen en is alles geoorloofd als je voornaamste doel is om winst te maken?
Marijn Janssen, professor ‘ICT and governance’ aan de faculteit Techniek, Bestuur en Management wil desgevraagd eerst vaststellen dat projectfalen een bekend fenomeen is, binnen en buiten de ICT. “In de literatuur vind je een reeks klassieke faalfactoren die je keer op keer tegenkomt.” In een wetenschappelijk artikel dat hij laat zien, staan er 36. Op nummer één staat het slecht inschatten van opdrachten. Verder komen vaak voor: slecht plannen, onrealistische verwachtingen en wensdenken.
Janssen: “Het probleem met ICT is dat de complexiteit en de dynamiek heel groot zijn. ICT-projecten zijn ingewikkeld en veranderingen volgen elkaar snel op. Ik denk dat daarom de aanbeveling van de commissie-Elias om een projectbureau op te tuigen dat opdrachten moet toetsen niet de juiste weg is. Dat leidt tot extra complexiteit, terwijl je die nu juist wilt reduceren. Bovendien kost meer governance meer tijd. Die tijd is er niet. Een toetsing door het bureau kan een half jaar later al niet meer valide zijn. Als er problemen ontstaan, hebben bestuurders altijd de neiging om te centraliseren, om het naar zich toe te trekken. Maar je moet niet te veel bestuurlijke rompslomp neerzetten. ICT-projecten zijn daarvoor te complex.”
Wat nodig is, is juist decentralisatie, stelt Janssen. En dus nieuwe manieren van werken. Mensen op decentraal niveau moeten door opleiding bewapend worden om om te gaan met die complexiteit en dynamiek. “Ze moeten heel flexibel zijn, om steeds kleine stappen te maken. Agile development (zie kader) noemen we dat: binnen een beperkt aantal weken, meestal drie, kom je tot een werkend product, dat je daarna weer een stukje verder ontwikkelt. De DigiD is daarvan een mooi voorbeeld. Iedere versie heeft een hoger beveiligingsniveau. Ik vind het jammer dat de commissie-Elias niet heeft gekeken naar succesvolle projecten. Er is een gigantische behoefte aan ICT-ers, maar met alle nadruk op projecten die fout gaan, wordt het werk er niet aantrekkelijker op.”
Dan nu naar de rol van ICT-ers. Ligt alle schuld van projectfalen bij de overheid, of moeten ook de ICT-bedrijven op de pijnbank? De commissie-Elias zegt daar weinig over, maar zij stelt wel voor om eerdere (wan)prestaties van bedrijven mee te wegen bij aanbestedingen. Verder beveelt de commissie een gedragscode aan, waarin goed opdrachtgever- én opdrachtnemerschap zijn gedefinieerd.
Janssen vindt dat laatste weinig zinvol, ‘omdat het tot de normale verwachtingen zou moeten behoren dat mensen zich aan de regels houden en ethisch te werk gaan’. “De meeste ICT-ers zijn goedbedoelend, hebben geen kwaad in de zin.” Een lijst aanleggen met wanpresteerders vindt hij desalniettemin logisch, al is dat minder eenvoudig dan het lijkt. “Want wat was de reden dat een project is verknald? Soms door wanprestaties van het ICT-bedrijf, soms doordat opdrachtgevers bijvoorbeeld steeds meer eisen toevoegen, soms is een project simpelweg ingehaald door de tijd.”
Daar komt volgens hem bij dat ICT-bedrijven geen zicht hebben op de gehele ICT-omgeving waarbinnen hun nieuw te bouwen software moet gaan draaien. “Je kunt niet eerst alles analyseren en dan met je offerte komen, want in feite ben je dan al aan het project begonnen.” Daarbij helpt het niet als een ICT-bedrijf niet de juiste kennis in huis heeft. “Ze redeneren vaak dat ze die wel in huis halen als de opdracht binnen is. Maar eigenlijk heb je bij het opstellen van de offerte al én diepe ICT-kennis nodig én kennis van de omgeving waarbinnen je opereert en hoe je die door je software transformeert.”
Janssen denkt dat dat te ondervangen is, door de diepe analyse als eerste onderdeel van het project te laten plaatsvinden. Dan wordt duidelijk of een project haalbaar is. “Beide partijen willen dat het goed loopt, ze hebben een gedeelde verantwoordelijkheid. Ze moeten een project stop durven zetten en zo’n beslissing zou gerespecteerd moeten worden.”
Kader: Agile development
Agile software development gaat uit van het idee dat een opdrachtgever op voorhand niet weet wat hij nodig heeft. Er moet een probleem worden opgelost, of klanten moeten sneller worden geholpen. Het ICT-bedrijf moet daarvoor software ontwikkelen die nog niet bestaat, in een wereld die constant verandert, terwijl het de kennis nog moet opdoen. Er zijn veel onbekende factoren. Daarom heeft het geen zin een groot plan op te stellen. De opdrachtgever wil dat vaak, niet in de laatste plaats om risico’s uit te bannen. Alleen, de zekerheid die ze zo creëren, is een schijnzekerheid.
Het ICT-bedrijf kan de opdracht beter klein houden en werken met kleine teams, is de gedachte. Zo’n team ontwikkelt eerst het kleinst mogelijke onderdeel van de oplossing, een stuk software dat meteen waardevol is. Op basis daarvan gaat de ontwikkeling verder, steeds in stappen van twee of drie weken. Gaat er onderweg iets mis, dan is bijsturen gemakkelijker en blijft de financiële schade beperkt.
Comments are closed.