Commissie Elias geeft goed antwoord op de verkeerde vraag

Geen reacties
Tags: , , ,
Posted 21 okt 2014 in nieuws

Opvallend in het rapport van de commissie Elias is dat het gaat over wat er mis gaat met ICT-Projecten en hoe die projecten beter moeten. De commissie komt met zinnige aanbevelingen: het opzetten van het Bureau ICT-Toetsing (BIT) dat projectplannen toetst en projecten eventueel kan tegenhouden, betere informatievoorziening aan de Kamer over doel, voortgang en kosten van projecten, etcetera.

Wat hier rammelt is de soort vanzelfsprekende aanname dat ICT altijd in de vorm van een Project moet worden uitgevoerd. Want wat is een Project? Volgens Wikipedia: “Een project is een geheel van activiteiten om in een tijdelijke organisatie binnen gestelde condities een vooraf gedefinieerd resultaat te bereiken.”. En in het ‘vooraf gedefinieerde resultaat’ wringt precies de schoen. Zowel particuliere opdrachtgevers alsook de overheid zijn praktisch nooit in staat om vooraf exact te specificeren wat het eindresultaat moet zijn (een ‘bestek’). En zonder een 100 procent sluitend bestek kan je niet zinnig aanbesteden en contracteren, en dus ook niet een project managen en tot een goed einde brengen.

Nu zul je misschien denken: dan moet er dus vooraf beter worden nagedacht en beter gespecificeerd moeten worden wat het resultaat moet zijn, kortom een goed bestek gemaakt worden. Dat is inderdaad precies wat de commissie Elias aanbeveelt, en wat ook het nieuwe BIT moet gaan toetsen.

Mijn stelling: dit is een illusie.

  • Zelfs de simpelste ICT-opdrachten zijn vaak te complex, bevatten te veel onzekerheden, te veel verwevenheid van wensen, ontwerpkeuzes en uitvoeringsproblemen om dit ooit te kunnen doen.
  • De wensen-en eisenlijst van projecten lopen vaak volledig uit de hand, omdat alle stakeholders hun boodschappenlijst in het project gepropt willen hebben. Omdat een project gedefinieerd is als een eindstation kan niemand van de stakeholders zich veroorloven deze trein te missen.
  • Dit soort wensprojecten duren vaak jaren waardoor het eindproduct per definitie achterhaald is tegen de tijd dat het klaar is.

Het traditionele projectdenken, gebaseerd op Prince2 en Waterval principes heeft in het verleden ruimschoots bewezen niet te functioneren, en wat de commissie Elias ook voorstelt om het strenger en strakker te doen, het gaat ook nooit functioneren.

De succesvolste en innovatiefste ICT-ondernemingen in de wereld hebben deze methodes al lang afgezworen en zijn door naar Agile methodieken en gebruiken bijvoorbeeld Lean Startup principes om kortcyclisch te werken, en zo snel mogelijk een feedbackloop op te zetten door producten in de markt te zetten waar gebruikers op reageren en die continue in snelle iteraties verbeterd kunnen worden. Ze hebben vooraf een ruw idee waar ze heen willen, maar hebben echt geen ‘vooraf gedefinieerd eindresultaat’ en al helemaal geen ‘tijdelijke organisatie’ om daar te komen: ze zetten een permanent team neer om hun producten of diensten te ontwikkelen, en sturen het continue bij met de nieuwste inzichten.

De populaire videodienst Netflix is ooit begonnen DVD’s in rode enveloppen heen en weer te sturen. Als zij Prince2 hadden toegepast hadden ze nu in het rijtje bij FreeRecordshop en Videoland gestaan.

Waarom past de ICT-industrie deze inzichten dan niet toe bij overheidsprojecten? Het antwoord is simpel: omdat ze daar geen belang bij heeft, en omdat de overheid de project-illusie zelf graag in stand wil houden. Het resultaat: rammelende aanbestedingen, leveranciers die vooraf precies weten waar de zwakke plekken zitten in de specificaties, onder de prijs aanbieden, en vervolgens jarenlang de overheid uitmelken met een schrikbarende hoeveelheid meerwerk.

En de overheid krijgt er als opdrachtgever geen grip op, want juridisch is er geen speld tussen te krijgen. Want u denkt toch niet dat de leveranciers de pijn dragen van al die budgetoverschrijdingen?

De ironie kent geen grenzen. Op dezelfde dag dat de commissie Elias haar rapport aan de Kamer presenteert laait de discussie over de OV-chipkaart in diezelfde Kamer weer op. Alle politici zijn uiteraard onthutst over dat onding: ‘dit kan zo niet langer’.

De ironie zit hem er in dat de voornaamste pijnpunten (pre-paid borgsaldo, uit-inchecken bij vervoerderswissel, vergeten uit te checken) allemaal functionele systeemfouten zijn waarvoor de Kamer als opdrachtgever volledig verantwoordelijk is. Technisch gezien werkt die kaart eigenlijk bewonderenswaardig goed.

Hoe moet het dan wel?

Als de overheid moderne en gebruikersvriendelijke digitale diensten wil ontwikkelen, dan zal ze moeten accepteren dat vooraf bijna niet te bepalen is hoe die dienst precies moet functioneren. Ze moet afstappen van het ‘hoe’. Het ‘wat’ de dienst in grote lijnen moet gaan doen moet ze wel strak sturen, en continue bijsturen. Ze zal vervolgens moeten bedenken wat het minimaalste van het minimaalste van is wat de eerste versie van de dienst moet kunnen. Dat gaat pijn doen, want alle boodschappenlijstjes, stokpaardjes en ander politiek hobbyisme moeten rücksichtslos overboord. Ze moet (vooral van zichzelf) eisen dat de eerste versie van de dienst er binnen drie maanden en een beperkt budget staat.

En dan moet ze in een continue kortcyclisch ritme van maximaal één maand blijven meten, evalueren, doorontwikkelen en nieuwe versies uitbrengen, net zolang tot de kosten van een volgende versie hoger worden dan de te verwachten toegevoegde waarde. Dan moet ze stoppen. En als een leverancier twee keer faalt in het leveren van een versie, moet die leverancier vervangen worden.

En om nog even terug te komen op die boodschappenlijstjes van stakeholders: door te laten zien dat je continue blijft doorontwikkelen en nieuwe versies uitbrengt, kan de angst om de projecttrein te missen ook overboord en kan je best een treintje later nemen en in de volgende versie meegaan met je wensen. Want die volgende versie, die komt er met deze aanpak gegarandeerd.



Lees het volledige bericht op Emerce »


Add Your Comment