Shintolabs-Waarom-de-Design-Sprint-dé-oplossing-is

Waarom de Design Sprint dé oplossing is voor datagestuurd werken bij overheden

Iedereen in overheidsland praat erover, maar weinigen doen het: razendsnel resultaten boeken met dataprojecten. De vele discussies op afdelingsniveau (waarbij rapporten ongebruikt in bureaulades verdwijnen) en op bestuurlijk niveau (over de verspilling van miljoenen gemeenschapsgeld aan grote ICT-projecten) gaan voorbij aan de kern van de zaak: hoe moet het dan wel!? Zou het niet mooi zijn als er een methode is om in korte tijd uit te vinden of iets werkt of niet voordat je grote investeringen doet?

De overheid staat de laatste jaren steeds vaker onder druk vanuit een brede maatschappelijke discussie over de besteding van publiek geld. Of dit altijd terecht is, is een ander verhaal, maar dat er met een kritisch oog wordt gekeken naar bijvoorbeeld de ICT-uitgaven, is logisch. Want de overheid komt regelmatig in het nieuws met ‘mislukte’ ICT-projecten.

Bij de overheid gaan veel dingen goed, maar er wordt veel geklaagd vanuit de bevolking. Met name over verspilling van gemeenschapsgelden, zeker als het gaat om ICT. Dat is natuurlijk ook niet zo gek als je in de krant zo vaak leest over mislukte ICT-projecten. Dat moet anders (en dat kan ook).

Iedereen heeft wel eens gehoord van ‘big data’ en als er ergens veel data beschikbaar zijn, dan is het wel bij de overheid. Deze data kan heel goed worden ingezet om grote maatschappelijke vraagstukken op te lossen. Dat besef leeft inmiddels ook breed binnen de overheid. De grote vraag is: waar moet je beginnen?

Vaak worden er dan data scientists ingehuurd die mooie dashboards ontwikkelen bij voorkeur met een voorspellend model erin. Predictive Analytics noemen ze dat. Het probleem is dat deze toepassingen meestal in de spreekwoordelijke ‘bureaula’ verdwijnen. Waarom? Omdat ze vergeten de gebruiker mee te nemen in de ontwikkeling van de oplossing. Sterker nog: het lost vaak niet het grootste probleem op de werkvloer op. En dan schiet het middel zijn doel dus voorbij.

Het antwoord waar wij mee zijn gekomen, is de Design Sprint. Het is een methodologie uit de koker van Google Ventures, die al sinds 2010 succesvol wordt ingezet in Silicon Valley. Wij hebben dit omgebouwd tot een methode die uitstekend geschikt is om samen met een overheidsorganisatie in heel korte tijd te onderzoeken of iets werkt of niet, of het voldoende waarde toevoegt.

Met een team van vijf tot zeven mensen vanuit de opdrachtgever werken we vijf dagen aan het oplossen van een probleem dat leeft in een gemeente. En dan vooral de mensen die in de praktijk bezig zijn met het vraagstuk. Wij zetten ze volledig in de ‘drivers seat’.

Op de eerste dag zoomen we in op het probleem. Wat is het vraagstuk waar de gemeente mee worstelt, bijvoorbeeld op het gebied van ondermijnende criminaliteit of fraude, mobiliteit, handhaving of een ander thema. Welke data is er beschikbaar? Welke externe experts kunnen hierop reflecteren?

Op dag twee gaan we aan de slag in verschillende werkvormen en laten de gebruikers bedenken we hoe de oplossing eruit moet komen te zien. Bij het onderdeel ‘Lightning Demos’ laten gebruikers zelf voorbeelden zien waarvan zij denken dat het kan helpen. Dat kan zijn een app, een website of zelfs een handige functie op een iPhone.

De derde dag is de dag waarop keuzes moeten worden gemaakt door de gebruikers. Er wordt een storyboard gemaakt waarmee precies kan worden gevisualiseerd hoe de oplossing eruit moet komen te zien en hoe dat past in hun dagelijkse werkzaamheden. En vooral dat laatste is essentieel.

Hierna, op dag vier, wordt door ons het prototype gebouwd. Er wordt gebruik gemaakt van echte data en de oplossing ziet er uit alsof deze al helemaal klaar is. Dat is natuurlijk niet zo, maar het gaat er uiteindelijk om dat de gebruikers dat denken en feedback kunnen geven.

En dat gebeurt op de laatste en belangrijkste dag. De validatiedag, waarbij feedback kan worden gegeven op het prototype. Feedback van gebruikers die ook bezig zijn met het vraagstuk, maar niet deelgenomen hebben aan de Design Sprint. Wat werkt wel en wat werkt niet? En: heeft het zin om een volgende stap te zetten?

Een Design Sprint is eigenlijk altijd succesvol in de betekenis dat het altijd resultaten oplevert. Of je hebt iets bedacht waarvan je weet dat het werkt of je hebt in korte tijd ontdekt dat verder ontwikkelen niet zinvol is.

Ik vind het iedere keer weer prachtig om te zien hoe de oplossing vanuit de gebruikers zelf komt en dus niet vanuit de techniek. Zo is de adoptie uiteindelijk hoog en voorkom je dat toepassingen niet gebruikt gaan worden. En dat veel gemeenschapsgeld wordt verkwist!