Een van mijn hobby’s is om oude versies van websites te bekijken. Neem bijvoorbeeld Netfllix, eind jaren ‘90. De website was niet meer dan een rare banner met glimmende DVD’s, een plaatje van een paar films en een brievenbus. Het concept was: we sturen mensen een DVD per post, die kijken ze, en dan sturen ze de DVD weer terug. Ik herhaal het nog een keer: je ‘huurt’ online een film, je wacht totdat die met de post bezorgd wordt, en dan moet je zelf de film weer terugsturen met de post. Nu, bijna twintig jaar later heeft Netflix ruim 83 miljoen abonnees wereldwijd. Wat is er gebeurd?

Of liever gezegd, wat is er niet gebeurd? Want waar ik Netflix tegenwoordig op mijn telefoon in de trein kan starten en door laat lopen op mijn tv als ik thuis kom, zijn veel online overheidsdiensten niet anders dan Netflix 20 jaar geleden. Ik geloof dat dat komt door een fundamenteel probleem bij de overheid: focus op functionaliteiten, niet op processen. Dat laatste, een goed proces, is precies wat de namen die we kennen om hun gebruiksgemak en online service onderscheidt. Spotify, Amazon, Facebook, Google, ze hebben allemaal een proces dat gericht is op continu verbeteren. Of het nou Agile, Scrum, LEAN, rapid prototyping, design thinking of hoe dan ook heet, het is gebaseerd op een paar kernprincipes die niets te maken hebben met functionaliteiten en alles met kwaliteit en continu verbeteren.

Die principes zijn simpel: je doet aannames over wat waarde toevoegt voor je klant, die aannames test je op basis van prototypes, metingen en analyses. Dat doe je doorlopend, in korte projecten, met teams die bestaan uit echte mensen. Mensen die behoefte hebben aan ruimte, vrijheid en vertrouwen. Mensen die iets opleveren dat werkt, hoe klein ook, en vervolgens met elkaar reflecteren op wat ze gemaakt hebben. Build - measure - learn, in termen van de Lean Startup, het boek van Eric Ries. De kern is dat het een proces is waarin je leert en maakt tegelijk. Door de eenvoud denk je: het is zo simpel, hoe komt hier Netflix uit voort? Vervolgens zeg je: Ik hoef niet zo’n proces, ik wil gewoon de Netflix onder overheidsdiensten zijn, doe mij ook zo’n website en een app, het moet een newsfeed als Facebook hebben en een soort Uber voor klantcontact zijn. En dat waren dan je niet zo famous last words voordat je eindigde met ontevreden klanten en een enkele reis naar de vergetelheid.

Ik kan je vertellen waarom deze methode werkt —sneller maken betekent sneller fouten maken en betekent sneller weten of je op het juiste pad zit—, maar als je zelf Spotify, Netflix of Google gebruikt weet je dat het werkt. Interessanter is waarom het zo lastig is om dit bij de overheid te laten werken. Ik geloof dat dat te maken heeft met de valkuil van denken in functionaliteiten gecombineerd met een gebrek aan kennis over de alternatieven. Een focus op functionaliteiten gaat als volgt. In het beste geval begin je met een onderzoek naar de behoefte van je klant. Daaruit volgt een grote hoeveelheid wensen. Die breng je netjes in kaart, net als de wensen van je stakeholders en je baas. Dan begint het circus: je baas heeft een nieuwe app geïnstalleerd op z’n iPhone en wil dat ook in het product hebben, de stuurgroep vindt de kleur niet mooi, Juridische Zaken vindt dat de disclaimers niet duidelijk zijn, voor je het weet is je product een Frankenstein geworden. Zelfs als je deze horde weet te nemen kom je bij de volgende: je hebt eisen opgesteld, je bouwt het product, dan wordt het getest, je haalt wat bugs eruit, en eindelijk is het dan klaar voor de buitenwereld.

Tot zover kan het nog goed gaan, maar nu komt het echte probleem: wat vinden je klanten er van? En wat doe je als ze het niks vinden? Heb je budget om aanpassingen te doen? Ga je een volgende versie maken? Begin je dan weer met wensen ophalen? Deze stap-voor-stap methode, ook wel waterfall genoemd mist het vermogen om te leren. Niet alleen van fouten, maar ook van best practices, aannames die niet klopten of juist wel, behoeften van klanten die in de praktijk anders bleken te zijn. Waar waterfall wel geschikt voor is, is de behoefte van veel overheidsmanagers om vooraf te weten welke functionaliteiten ze kunnen verwachten tegen welke prijs. De agile werkwijze van Silicon Valley, met zijn fail fast, fail often, fail forward motto is makkelijk af te schrijven als een trend of een gimmick en er zullen ook zeker weer nieuwe werkwijzen en methodes komen, maar wat niet verandert is de kern: je kunt je producten niet verbeteren zonder te bouwen en te leren, en hoe sneller je bouwt en leert, hoe sneller je producten beter worden en je klanten tevreden.

Willen we een overheid die op die manier kan werken, dan moet er wel iets veranderen. Het heeft geen zin om te investeren in functionaliteiten en nieuwe technologieën als niet het proces van continu verbeteren op orde is. Ik denk dat de volgende stappen daarin cruciaal zijn.

• Denk in modules, niet in opzichzelfstaande projecten. Elke module kan op zichzelf waarde toevoegen, maar door te kiezen voor een inrichting met modules kun je makkelijker losse onderdelen verbeteren en inwisselen en dwing je de organisatie en de software om ook te kunnen interacteren met andere onderdelen (API’s zijn hier een voorbeeld van)
• Richt je teams anders in: productgericht, niet functioneel. Als je snel aannames wil testen heb je designers en user-experience ontwerpers nodig die prototypes kunnen maken en testen. Het heeft geen zin om een team van developers af te rekenen op designs die niet werken, dus dat betekent dat je teams ook meerdere disciplines in zich moeten hebben en als team verantwoordelijk zijn.
• Vertrouw in het proces, en het resultaat volgt. Spreek uit dat je het proces belangrijker vindt dan het resultaat en ga niet alsnog functionaliteiten eisen. Als jij de enige klant bent is dat prima, maar anders geldt: werkt het voor de klant of werkt het niet? Vragen naar processtappen kan natuurlijk altijd en laat je betrokkenheid zien.

Welke stap denk jij dat essentieel is voor betere ICT-projecten bij de overheid?