-

Commissie Elias geeft goed antwoord op de verkeerde vraag

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.

Deel dit bericht

7 Reacties

Martin

Eindelijk iemand die het mooi verwoord. Ik mis alleen nog een stukje over ambtenaren die zich met inhoudelijke details bemoeien zonder over kennis of kunde te beschikken en dat de overheid deze kennis en kunde los moet inkopen, bijvoorbeeld tijdens evaluatiemomenten.

Roland van Ipenburg

Zelfs de simpelste ICT-opdrachten zijn vaak complex, bevatten veel onzekerheden, veel verwevenheid van wensen, ontwerpkeuzes en uitvoeringsproblemen omdat de wet en regelgeving waar ze aan moeten voldoen, op gebaseerd zijn of faciliteren dat ook zijn. Ook een minimale eerste versie moet ook aan al die eisen voldoen omdat de overheid niet te vergelijken is met een marktpartij: De overheid heeft te maken met een monopolie op de diensten die ze biedt en een maatschappelijke plicht redelijkerwijs niemand van die diensten uit te sluiten. Normale marktpartijen hebben het gewoon een stuk gemakkelijker en kunnen er voor kiezen om maar een gedeelte van de markt te faciliteren als hun dat beter uitkomt. Dat is winst voor die marktpartijen, maar misschien ook niet erg efficient wat betreft maatschappelijke verantwoordelijkheid die een stuk verder gaat dan alleen maar wat toegevoegde waarde.

Bart Manuel

Beste Roland,

Je hebt zeker een punt, marktpartijen/Startups hebben het zeker makkelijker, maar ook moeilijker: hun budgetten zijn ordes van grootte kleiner. Misschien wel een zegen: beperking maakt inventief.

Verder: de overheid maakt zelf het beleid/ de wetten die vervolgens uitgevoerd moeten worden door implementatie in ICT: meer rekening houden met de uitvoerbaarheid vooraf zou al een hoop schelen: vraag maar aan de belastingdienst die allerhande onuitvoerbare toeslagen beleid in de maag gesplitst krijgt.

En nog iets: de overheid kan er idd niet voor kiezen om een stuk van de markt te negeren, maar mijn punt: ze kan wel kiezen om in eersten instantie een stuk van de nice-to-have functionaliteit te negeren.

In mijn ogen is ICT ontwikkeling een proces, geen project.

Dick Ottervanger

Een heel goede observatie, Bart. Tóch kan een ICT opdracht als een project uitgevoerd worden. Hangt er van af hoe je het inricht. Ik ben m’n hele werkende leven actief in de bouwkundige sector, Architectuur, Vastgoed, Constructie en heb ICT projecten van dichtbij meegemaakt, die vervolgens bij de oplevering niet helemaal doen wat beoogd was, zijn bijna nooit op tijd gereed en bijna altijd over budget. Tot zo ver ben ik het eens met je betoog.

Wat als een overheid, of particuliere opdrachtgever, die een ICT wens heeft dit in de markt zet als een DB contract (Design & Build) met een prestatie clausule, en een “bestek” van één A4-tje, waarin wordt omschreven wat de uitgangspunten zijn en wat het doel van het project is en wat het moet kunnen. Daarnaast wordt er ook een onderhoudscontract aan verbonden. Een implementatie datum is ook nodig, want het is niet vrijblijvend. Ook specificeer je de prioriteiten, beslis- en evaluatie momenten, dus Prince2 en waterval principes dienen m.i. wel toegepast te worden. Je legt de verantwoordelijkheid volledig bij de ICT aannemer, want hij is de deskundige.

Vervolgens pas je voor het “project” de LEAN methode toe, waarbij je dus constant gebruik maakt van ieders expertise.

Er dienen ook alternatieven aangeboden worden, want meerdere wegen leiden naar Rome.

Een onafhankelijke deskundige dient de aanbiedingen te evalueren.

Frans van As

Waarom ICT projecten bij de overheid ECHT mislukken.
Afgelopen maanden heeft heel ICT minnend Nederland wel gevolgd dat de onderzoekscommissie ICT, onder leiding van de heer Ton Elias, naarstig op zoek was naar de redenen waarom ICT projecten bij de overheid zo vaak uitdraaien op een fiasco. De commissie hoorde vele mensen, zowel uit de politiek als van (grotere) ICT bedrijven, om een duidelijke oorzaak te vinden voor dit fenomeen, iets wat de Nederlandse bevolking jaarlijks tussen de 1 en 5 miljard euro blijkt te kosten, grofweg tussen de 60 en 320 euro per Nederlander per jaar!
En wat blijkt uit het onderzoek? De overheid heeft te weinig kennis in huis, de grote ICT organisaties weten dat en spelen daar handig op in. Aanbestedingsregels leiden niet per definitie tot de gewenste resultaten. Verantwoording en besluitvorming gaan moeizaam.
Maar wees eens eerlijk. Wisten we dit niet al voordat het onderzoek van start ging? Wie is er nu “schuldig”? Wie moet nu boeten voor de gemaakte blunders in het verleden? En in de toekomst? Welke politicus of welke ICT organisatie moet nu boetes betalen, wordt geschorst of mag geen zaken meer doen met de overheid? Precies…..
Een van de oplossingen die de commissie voorstelt: implementeer een BIT, een Bureau ICT Toetsing.
Als je de tien regels leest die voor de BIT zijn bedacht, dan weet je het al: Dat gaat niet werken!
Niet in de huidige cultuur die binnen de overheid geldt. De regels stellen namelijk dat er OPENHEID en TRANSPARANTIE moet komen. Logisch, zou je zeggen: als je besluiten wilt nemen, moet je weten hoe de vlag er voor staat, welke grote risico’s je loopt, waar zaken goed gaan en waar zaken juist niet goed gaan.
Maar als er iets niet getolereerd wordt in de huidige cultuur is het openheid en transparantie!
Men wil helemaal niet weten wat er aan de hand is, waar het misgaat en hoe dat komt. Men wil gewoon zijn/haar eigen doelen nastreven en kostte wat kost doorgaan op de ingeslagen weg, om maar geen gezichtsverlies te hoeven leiden.
Openheid en transparantie wordt juist niet gewaardeerd!
Niet door de opdrachtgever, hij wil niet falen.
Niet door de opdrachtnemer, hij wil zijn opdracht niet teruggeven of stopzetten.
Is dat niet juist het probleem? De “schuldigen” zijn niet de architecten, bouwers, testers en beheerders die aan vaak veel te grote, complexe projecten werken met steeds nieuwe eisen en wensen in onmogelijke complexe ICT omgevingen. Wees eerlijk, vaak weten zij voorafgaand aan het project al dat het een onmogelijke opdracht is, die nooit binnen tijd en geld, laat staan kwaliteit behaald kan worden.
Hier gaat het dus al mis, aan het begin van de opdracht weten de vakbroeders het vaak al….Toch beginnen ze schoorvoetend en quasi gemotiveerd aan hun eigen Mission Impossible!
Hoe moeten we dit probleem oplossen?
Ik vrees dat hiervoor een cultuurverandering moet plaatsvinden. Er dient een cultuur gecreëerd te worden waarin men leert om te gaan met fouten, waarin men beloond wordt voor het nemen van initiatieven, ook als deze niet haalbaar blijken. Een cultuur waar fouten maken is toegestaan, als er maar van geleerd wordt. Een cultuur van Vertrouwen. Zo’n cultuur creëert openheid. Men moet niet bang hoeven te zijn om iets te zeggen.
In zo’n cultuur hoort ook Verantwoordelijkheid! Verantwoordelijkheid moet je nemen en verantwoordelijkheid moet je krijgen. Dat gaat dus twee kanten op.
Iemand die teveel fouten maakt moet daarop aangesproken worden. En als dat niet tot de gewenste resultaten verbeteringen leidt, is die persoon niet de juiste persoon voor de klus. Hij was toch verantwoordelijk? Dat is nu eenmaal zo. Zo gaat het in het bedrijfsleven toch ook? En in de voetballerij toch ook?
Verantwoordelijkheid krijgen is net zo belangrijk! Als je met goed gekwalificeerde mensen werkt, die de juiste intenties hebben, dan moet je kunnen vertrouwen op hun Vakmanschap. Deze vakmensen zijn immers niet voor niets op de opdracht gezet, toch? Laat ze hun ding doen, ga er van uit dat ze aan de doelen werken met de juiste bedoelingen.
Op deze wijze start je met een cultuurwijziging, die enkele jaren zal duren. Uiteraard moet je ook aan de projectbeheersingskant kijken. Het is toch logisch dat de opdrachtgever ook budgethouder is? Als er een wijziging van de plannen plaatsvindt, dan kijkt de opdrachtgever toch eerst of hij dat wel kan en wil betalen? Of zijn oorspronkelijke Business Case nog wel overeind blijft? Dit soort logica vinden we in elke beschreven projectmanagement methode terug. Dat is evident.
Maar openheid en transparantie is een minder tastbaar iets. En zolang men dat niet concreet kan maken, zal het bij loze woorden en uitgesproken intenties blijven……Jammer!
Want als je geen transparantie creëert zal het je nooit lukken om verantwoordelijke opdrachtgevers Informed Decisions te laten maken.

Frans van As

Mark Scholten

Veel wijze woorden, zowel in het originele stuk als in de reacties.

Ik kan me vinden in de woorden van Frank van As: fouten maken is vaak taboe in een overheidsomgeving en daar is veel op terug te voeren.

Nog weer een spade dieper gravend denk ik dat het taboe op het maken van fouten deels ligt in het politieke proces. Weinig politieke partijen laten de kans liggen om politiek voordeel te halen als een concurrerende partij een steek heeft laten vallen.

Meer nog denk ik dat we een pers zouden moeten hebben die een genuanceerder beeld biedt van ontwikkelingen en niet gaat voor de scoop van de mislukking.

Iedere Nederlander die met ICT of een ander (bouw)project gewerkt heeft weet hoe snel een foutje gemaakt is. Daar moet je niet kinderachtig over doen. Als je maar zorgt dat je niet te vaak fouten maakt en niet telkens dezelfde.

Kortom: met een pers die aan volwassener berichtgeving doet zorg je ervoor dat een foutje niet direct dodelijk is en dat overheidsfunctionarissen zich niet zo sterk gaan indekken.

Dan moet ook de lezer/kijker volwassen genoeg zijn om de kwaliteitspers de ruimte te geven. En ze niet te bestempelen als ‘slapjanussen’ bij een genuanceerd verhaal. Volgens mij zijn best veel Nederlanders bereid die ruimte aan de kwaliteitspers te gunnen.

Hugo Messer

1 onderwerp wat hier niet behandeld wordt is de omvang van partijen die aan grote overheids projecten werken. Volgens mij is de neiging om steeds dieper in regulering en ‘ouderwetse’ methodieken als waterval ondersteund door prince2 te verzanden. Vaste prijzen en budgetten passen niet goed in methodes die wel werken; agile, scrum, lean. Deze 2 combineren maakt dingen alleen maar erger.
Omdat de overheid groot en log is, zoekt ze partijen van dezelfde omvang. Daarnaast moeten risico’s afgewenteld worden en wie kan die dragen? de IT dinosaurussen. In mijn ogen zit daar de problematiek.
Het zou stukken effectiever zijn om flexibele afspraken te maken met kleinere teams of partijen. Al het bouwwerk op basis van scrum en agile principes ontwikkelen. Als een project dan de verkeerde kant op loopt (en in scrum kun je dat goed monitoren EN bijsturen), dan naar een ander team toe.

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond