Nooit meer ‘googlen naar ict’: lean startup binnen de overheid?

“UWV blijft IT-projecten gunnen aan bedrijven waar het niet tevreden mee is.” “De rijksoverheid verbrandt 1 tot 5 miljard euro aan IT-projecten die mislukken.” “Kamervoorzitter Van Miltenburg moest betekenis ict googelen.” Ton Elias, die ‘veel’ IT-projecten heeft gemanaged, adviseert om een nieuw bureau op te zetten die alle IT-plannen boven de 5 miljoen euro vooraf moet toetsen op haalbaarheid. De actualiteit liegt er niet om.

De enthousiaste manager en zijn applicatie

Ken je deze situatie? Een enthousiaste manager koopt een applicatie omdat hij denkt dat het ‘de dienstverlening naar onze klanten beter maakt’. De applicatie is voorzien van de nieuwste innovatie op het gebied van online dienstverlening en andere vernuftige functionaliteiten. Een paar koppelingen regelen en klaar is kees. Niks mis mee, zo lijkt op het eerste gezicht, en eigenlijk best wel een innovatieve stap voorwaarts, want dat moet binnen de overheid ook gestimuleerd worden, zegt de directeur.

‘Lean’ processen & trainingen

De applicatie moet vervolgens worden uitgerold in het team of de organisatie. Een aantal processen moeten ‘Lean’ gemaakt worden en iedereen moet verplicht een knoppentraining volgen. Met enig ongemak worstelen een aantal medewerkers zich door de training. Een aantal andere medewerkers zijn plotseling ziek of hebben een niet te verzetten afspraak. Tijd voor een mailtje van de secretaresse van de manager: “Jullie worden wel echt verwacht op de training.”

De stuurgroep lijdt aan ‘featuritis’

Om de uitrol van het IT-systeem te realiseren is een projectmanager aangesteld en een stuurgroep in het leven geroepen. De stuurgroepleden zijn adepten van Prince2, omdat dat zo goed werkte bij andere projecten en hen het gevoel gaf ‘in control’ te zijn. De stuurgroep is samengesteld uit een brede groep van managers, want dan is de organisatie op een goede manier vertegenwoordigd. De projectmanager krijgt de taak om een uitgebreid projectplan te schrijven, waarin alle eisen, wensen, risico’s en tegenmaatregelen zijn omschreven. Het projectplan is onderwerp van discussie: iedereen in de stuurgroep wil graag laten weten dat ook zij verstand heeft van het onderwerp. Ze verzinnen, zonder dat er een probleem bestaat, nieuwe verbeteringen voor het product: featuritis.

Serieuze wallen bij de projectmanager

Ondertussen zijn we een paar versies van het projectplan verder. De projectmanager, die nu al serieuze wallen begint te krijgen, hoort alles aan. En zit ondertussen met de gebakken peren: het begint duidelijk te worden dat de klant het nut van de oplossing niet zo ziet. De wensen- en eisen lijst loopt volledig uit de hand, omdat alle stakeholders hun boodschappenlijst in het project willen krijgen. Het wordt namelijk als een eenmalig project beschouwd, een trein die je niet mag missen.

Hoe kon het zo uit de klauwen lopen?

Tijd, energie en geld worden in hoog tempo ‘verbrand’, zonder dat het de waarde creëert die het eigenlijk zou moeten opbrengen. Dit soort (wens)projecten duren vaak erg lang, waardoor het eindproduct al achterhaald is zodra het klaar is. Het frappante is dat dit vaak de gangbare manier is om IT-projecten te starten. Niet voor niets worden er Tweede Kamer-commissies in het leven geroepen die onderzoeken hoe het toch kan dat ict-projecten van de overheid zo uit de klauwen kunnen lopen. Aan het eind van die projecten is er een half werkend product, een half tevreden klant, een goed gespekte leverancier en een rechtszaak in wording.

Verschil tussen een bestaande organisatie en een startup

Het grote belangrijkste verschil tussen een bestaande organisatie en een startup is niet dat de één ‘groot’ en de ander ‘klein’ is. Nee, een bestaande organisatie voert een businessplan uit, het kent de klanten (hoop je) al en de producten en organisatie zijn erop ingericht. Een startup is juist op zoek naar een schaalbaar businessmodel. Dus, een bestaande organisatie ‘voert uit’, een startup is ‘op zoek’. Dit is een groot verschil. Op het moment dat een bestaande organisatie innovatieve diensten in- of extern aanbiedt, is de organisatie eigenlijk ‘op zoek’ naar wie de klanten zijn en wat voor hen van waarde is. Innovatie is nieuw, en daardoor per definitie omgeven door allerlei onzekerheden.

Maar hoe zorg je er nu voor dat iemand z’n ‘hallucinatie’ niet een geld- en energieverbrandende motor wordt?

Een oplossing voor een probleem dat niet bestaat

Ik heb het idee dat Lean aardig ingeburgerd is of ingeburgerd begint te raken binnen de overheid en bedrijven. Maar dan vooral met het perspectief van hoe we bestaande processen slimmer kunnen maken. We hebben nog te weinig scherp waarom we een bepaalde (IT-)oplossing kiezen voor een probleem dat we denken te zien. Je kunt de Lean-startupmethode gebruiken om te bepalen welke koers je moet bewandelen.

Maak een ‘minimal viable product’

De methode draait om gevalideerd leren. Wat je doet is eerst in kaart brengen welke problemen je (beoogde) gebruikers hebben. Vervolgens toets je deze problemen bij echte. Zo kom je er al snel achter of het probleem dat je denkt te zien ook inderdaad door meerdere mensen ervaren wordt. Vervolgens kun je hetzelfde doen met oplossingsrichtingen. In het geval van een IT-project kan het maken van een minimal viable product (MVP) ervoor zorgen dat je een eenvoudige versie van je oplossing met echte klanten valideert.

Feedback van je klanten

Het doel van het maken van zo’n MVP is niet om een ‘bug’-vrij topproduct neer te zetten, maar om feedback van je klanten te krijgen. Het zorgt ervoor dat je de cyclus van bouwen, meten en leren zo snel en goedkoop mogelijk doorloopt. MVP is dus eigenlijk een experiment waarin je zo simpel mogelijk je belangrijkste aannames rondom je probleem of oplossing kan toetsen. Zo vermijd je dat je een heel product maakt waar niemand op zit te wachten en vergroot je je leervermogen. Zo’n MVP kan al zo simpel zijn als een landingspagina met: ‘Herken je dit probleem? Klik hier’.

Je wilt meten wat mensen echt gaan doen

Je wilt meten wat mensen doen, niet wat ze zeggen dat ze (gaan) doen. Zo kwam er eens een manager bij me die graag wilde gaan beeldbellen en chatten met klanten. Daarvoor had hij al een aardige module. Maar op dat moment wisten we beiden nog niet of de klant ook wilde beeldbellen en chatten. Ik adviseerde hem om een gratis Skype-account aan te maken, twee uur per dag de gelegenheid te bieden om te beeldbellen en hiervoor een oproep te doen op de homepage. Het bericht heeft 800 clicks gekregen en er waren twee mensen die wilden beeldbellen. Daar kun je uit opmaken dat de behoefte naar beeldbellen niet zo groot is. Van belang is om te achterhalen ‘which job needs to be done’.

Een IT-project is eigenlijk geen project!

Weer terug naar de IT-projecten. Als we hebben ondervonden dat een IT-oplossing echt een oplossing is voor een bestaand probleem bij bestaande mensen, mogen we aan de slag. Het eerste dat we vaak doen is een door veel onzekerheden omgeven opdrach, volgens de traditionele projectmanagementmethode in beton gieten. Met Prince2 en de watervalmethode specificeren we van tevoren precies wat het eindproduct moet zijn. Als particuliere opdrachtgever of de overheid weet je vooraf nooit exact wat het eindresultaat wordt. Eenvoudige IT-projecten zijn al vaak complex, bevatten onzekerheden, veel ontwerpkeuzes en nog meer uitvoeringsproblemen om dit goed te kunnen doen. Daarnaast zit een organisatie ook nog vaak met een legacy van oude systemen en koppelingen die het al niet eenvoudiger maken.

De commissie Elias adviseert dat we vooraf beter moeten nadenken over wat het eindresultaat precies moet zijn. Dit is wat ook de nieuwe commissie BIT moet gaan doen. Maar het is wat mij betreft precies wat ze niet moeten doen.

Wat moet je dan wel doen?

Om met deze onzekerheden om te gaan moet je juist niet met watervalmethoden ontwikkelen. Doordat de wensen- en eisenlijst van stakeholders uit de hand loopt, wordt de scope te groot. Hierdoor gaan IT developers in één keer ee  naar binnen gericht development-proces opzetten. Het product wordt precies zo gemaakt zoals van te voren bedacht is. Met als gevolg dat dat toch niet was waar de klant op zat te wachten, zo blijkt uit de eerste testen. Een proces waarin je niet leert van de feedback van klanten en opdrachtgever. De gevolgen daarvan zijn uitgebreid in de krant terug te lezen. De ov- chipkaart is daar een mooi voorbeeld van. Technisch werkt dat ding prima, functioneel is het een draak (pre-paid saldo, in- en uitchecken, waar je het uitchecken dus vergeet).

Succesvolle IT-projecten zet je op met Agile-methodieken, iets waar lean-startup ook op gestoeld is. Je ontwerpt met je klantteam korte sprints. Aan het eind van elke sprint, die maximaal twee weken mag duren, lever je werkende software op die de klant test. Zo bepaal je elke keer wat er ontwikkeld wordt op basis van wat je getest hebt en kun je tussentijds bijsturen. Met zo’n IT-project werk je toe naar een eerste versie die online kan. Zo leer je weer van wat bezoekers met je product doen en plan je een tweede fase in, waarin je meeneemt wat er verbeterd of uitgebreid kan worden. Bol.com geeft hun medewerkers bijvoorbeeld twee weken om een idee uit te testen.

Stap af van Prince2 en watervalmethodes

Wil de overheid succesvol IT projecten leiden, dan moet ze afstappen van werken met Prince2 en watervalmethodes en hun inkoopmethoden erop aanpassen. Leveranciers zien namelijk de zwaktes in de specificaties, bieden onder de prijs aan en komen vervolgens met een lijst meerwerk aan zetten waar je u tegen zegt.

Foto’s met dank aan Fotolia.