Sing Hallelujah: het evangelie van design thinking luidkeels verkondigd

Onlangs las ik een artikel in het digitale magazine van ICTU (februari 2021): Denken als een designer. Hoe kunnen we bij de overheid design thinking inzetten? Aanleiding was de Conferentie Design thinking bij de overheid en de daaraan voorafgaande design-sprintweek, beiden georganiseerd door datzelfde Gebruiker Centraal. Verschillende deelnemers deden in het artikel een ‘Dr. Albannetje’ en zongen ‘Hallelujah’ . Bijvoorbeeld Gerda Dijkstra, informatiemanager in de gemeente Achtkarspelen-Tytsjerksteradiel. Gerda deed mee aan de design-sprintweek die voorafging aan de conferentie. “We hebben in vier dagen tijd een concreet en werkbaar prototype neergezet, dat vind ik echt heel gaaf. […] Een belangrijk inzicht is dat we de eindgebruiker vanaf het begin bij het ontwikkelproces moeten betrekken.”

Ook Marianne Schimmel, business consultant bij het UWV, ontdekte waarom dat betrekken van die gebruikers zo relevant is: “Een jongere in ons team vertelde ons dat wat we maakten hem deed denken aan online therapie. Ik dacht meteen dat dat niet goed was en dat we het dus anders moesten doen. Maar na doorvragen bleek hij het helemaal niet erg te vinden dat het daarop leek. Wat een onjuiste aanname had kunnen worden voor de rest van het proces, werd dus direct weggenomen.”

Een supergoede digitale conferentie met een rockstar-dagvoorzitter

Gerda en Marianne zijn overtuigd en kunnen niet wachten om in hun eigen organisatie aan de slag te gaan. Ze verwoorden goed het gevoel van alle deelnemers aan de conferentie en design-sprintweek. De conferentie was top; het programma zat goed in elkaar, de sprekers waren interessant en de onderlinge interactie is natuurlijk het leukste. Bovendien was het ook nog eens een supergoed voorbereide én uitgewerkte digitale conferentie, waarbij design-thinking-bij-de-overheid-rockstar Maike Klip als dagvoorzitter de show stal. Gezien de vele enthousiaste reacties was het een dag met grote impact.

En toch bekroop mij gedurende de dag een unheimisch gevoel. Dat heb ik vaker als ik al die fanatiekelingen aanhoor die te vuur en te zwaard het design-thinking-evangelie verkondigen. Jaja, gebruiker centraal… Jaja, aannames testen en iteratief werken… Er is geen speld tussen te krijgen, begrijp me niet verkeerd. Ik ben het er volledig mee eens. Maar ik vind het een onaf verhaal. Dat zal ik toelichten.

Veel innovatieteams gaan te snel door naar het volgende spannende project

Wat ik regelmatig zie in de praktijk: veel projecten met een design-thinkingaanpak stoppen te vroeg. Ze zijn nog niet af als ze opleveren. In eerste instantie valt dat niet zo op. Dergelijke projecten volgen keurig de stappen in het veelgebruikte Double Diamond-model van de UK Design Council. Ze starten met onderzoek onder gebruikers naar behoeften en verbeterkansen (Discover). Ze formuleren een duidelijk (verbeter)plan met goed beargumenteerde keuzes voor functionaliteiten of diensten (Define). Dan ontwerpt en ontwikkelt het projectteam lekker iteratief, inclusief testen (Develop). En levert ten slotte een werkend eindproduct op (Deliver).

Double Diamond-model van de UK Design Council

Double Diamond Framework for Innovation (UK Design Council)

 

Wat dat ‘opleveren’ betekent in de praktijk? Meestal verloopt dat als volgt. Het innovatieteam heeft onderzocht, bedacht, getest – het werkt. Dus zegt het team: Strik erom, opleveren, alsjeblieft: nu is het van u, beste ‘business’! Het innovatieteam geeft presentaties over de nieuwe oplossing aan het managementteam, vaak ook aan de medewerkers. Het team benadrukt dat een representatieve afvaardiging van de professionals heeft meegedacht, en dat er met echte eindgebruikers is getest. De potentie is enorm, zo blijkt uit de experimenten, dus iedereen is enthousiast. Juichend sluiten ze het project samen af. Champagne!

Vervolgens is het on to the next one: er lonkt altijd weer een spannend nieuw innovatieproject aan de horizon.

Innovatieteams ‘live for new shit’: hun focus ligt op de toekomst, potentie en verbetering

Innovators zijn mensen die leven met de blik vooruit. Ze kijken naar de toekomst, naar potentie. Niet naar wat was, maar naar wat kan zijn. Dat wil overigens niet zeggen dat innovatieteams met de rug naar het verleden staan. Ze zijn zich terdege bewust dat je moet leren van het verleden om te bepalen hoe de toekomst moet worden. Ze brengen goed in kaart hoe een proces of dienst nu ingevuld wordt, en waar het schuurt. Dat is – uiteraard samen met goed begrip van leefwereld, ervaring en behoeften van eindgebruikers – het startpunt voor de vernieuwing.

Van daaruit kun je nieuwe oplossingen bedenken. En dat wenkend perspectief, daar gaan innovatieteams vol voor. Eenmaal een oplossingsrichting gekozen, duiken ze volledig in het nieuwe, het betere. They live for new shit, zou Vin Diesel zeggen. ‘Het huidige’ is met dat levensmotto alleen maar ballast, en blijft voor een groot deel buiten beeld in het innovatietraject. Dat is ook nodig. Als je niet loskomt van vandaag, wordt morgen nooit anders.

Maar het heeft ook een keerzijde.

De blinde vlek die maakt innovatieteams dat de ‘business’ (onbewust) in de steek laten

Op zich lijkt met bovenstaande niet veel mis. Goed onderbouwde vernieuwing, getest en wel. Iedereen enthousiast, en een werkend product. What could possibly go wrong? Genoeg, blijkbaar, want er mislukken nog altijd ontzettend veel innovaties. In mijn observatie komt dat doordat innovatieteams een deel van hun verantwoordelijkheid laten liggen.

Op enig moment moeten vandaag en morgen namelijk wel weer bij elkaar komen. Door zich af te keren van het huidige, door obsessief te focussen op de werking van het nieuwe, zijn innovatieteams zich vaak maar ten dele bewust van wat écht moet worden aangepakt. En hebben hun plannen voor verbetering, vernieuwing of verandering te weinig aandacht voor hoe alle betrokkenen en hun routines “zelf het hardnekkigste deel van het probleem zijn”, zoals onderzoekers van de Nederlandse School voor Openbaar Bestuur schrijven in hun essay Experimenteren en opschalen (p. 59-60).

Het klinkt misschien wat hard, maar ik vind: door die blinde vlek laten innovatieteams de business uiteindelijk tóch in de steek. Onbewust, dat wel, dus je kunt het ze niet écht kwalijk nemen. Niettemin is het adagium van innovatieteams eigenlijk, parafraserend op Stevie Wonders grote hit: Designed, sealed, delivered (Up yours)!

Veel innovatieteams zijn blind voor wat er na hun kunstje komt: héél veel werk

Laat ik het anders zeggen. Net als Stevie Wonder zijn veel innovatieteams blind voor wat er achter hen aan komt. In dit soort projecten is dat vaak een shitload aan werk. Een greep uit wat ik dagelijks tegenkom? Nieuwe procedures ontwerpen en/of huidige procedures aanpassen. Afgewogen keuzes maken bij conflicten tussen nieuw en oud (en dus héél veel afstemmen). Procesinstructies opstellen of aanpassen. Management meenemen, nut en noodzaak uit blijven leggen. Zorgen dat ze op de juiste dingen gaan of blijven sturen. Nieuwe kpi’s ontwikkelen, of afspraken maken over de oude in relatie tot de nieuwe dienst of interventie. Medewerkers meenemen, instrueren en trainen. Zorgen dat medewerkers niet alleen kunnen werken met de nieuwe dienst of interventie, maar dat ook willen én doen. Rapporteren over de ‘adoptie’ van die nieuwe dienst aan het management (wórdt het ook echt gebruikt?), en zorgen dat zij op de juiste knoppen gaan en blijven duwen om dat te bevorderen. Et cetera, et cetera.

Een nuancering is hier wel op zijn plaats. Want zeker bij grotere innovatieopgaven, die bijvoorbeeld volgen uit ingrijpende beleids- of koerswijzigingen, is die shitload aan werk wél integraal onderdeel van de aanpak. Maar in heel veel projecten met een design-thinkingaanpak is het innovatieteam er niet of veel te weinig mee bezig.

En laten we eerlijk zijn: het is ook niet altijd het leukste deel van het werk. Immers, in deze stap botst de verbeteringen of vernieuwing heel vaak (dat wat in je project bewezen ‘werkt’) op de huidige werkwijzen, (ongeschreven) regels of beleidskaders (dat wat ‘hoort’). Dat leidt tot frictie, discussie en gedoe. De meeste innovatieteams houden niet van gedoe, en ook niet van de details in deze fase van ‘inpassen en -meten’. Het vraagt dan ook andere activiteiten dan die ze gewend zijn. Dan waar ze goed in zijn. Het vraagt andere competenties.

Opleveren is nog geen implementeren: the devil is in the details

Het moge duidelijk zijn: wat mij betreft moeten innovatieteams hun organisatie in elk project (en dus niet alleen in heel grote systeeminnovaties) helpen om goed te implementeren. Te borgen. Want alleen dan kun je voorkomen dat het project waar je zo hard aan hebt gewerkt sterft in schoonheid, en eindigt op het kerkhof van de goede bedoelingen.

En dat is iets anders dan datgene waar veel innovatieteams zich wél hard voor maken: het creëren van een innovatieve, lerende cultuur in de organisatie, waardoor mensen continu willen optimaliseren. Dat komt ook terug in de grijze cirkel achter de beide diamanten in het model van de veelgeroemde UK Design Council, in de afbeelding hierboven. Echt waardevol, daar niet van. Maar is het genoeg?

Ik denk het niet. Hoewel het zeker belangrijk is om de juiste skills en vooral mindset in de organisatie te ontwikkelen, is wat er éérst nodig is eigenlijk veel minder groots en meeslepend. De Design Council beschrijft per fase van haar Double Diamond-model de methodes die je kunt toepassen om je project tot een goed einde te brengen. De voorgestelde aanvliegroute van de ‘Deliver’-fase – zorg voor een gefaseerde uitrol, doe een goede finale test en organiseer een feedbackloop voor optimalisatie na lancering – is in mijn optiek te beperkt.

De 5 fasen van Social Service Design.

De 5 fasen van Social Service Design (Uit: Boudewijn Bugter. (2021). Social Service Design: Innoveren op het snijvlak van maatsschappelijke vraagstukken en publieke dienstverlening. Van Duuren Management.)

Volgens mij is wat de Design Council (en dus iedereen die hun model gebruikt) de ‘Deliver’-fase noemt eigenlijk gewoon nog het staartje van de ‘Develop’-fase. Het model dat mijn collega’s en ik in onze projecten gebruiken, stoelt wel degelijk op allerlei bekende innovatie- en design-thinkingmodellen, al vullen we die modellen aan (zie illustratie hierboven).

Maar bovenal interpreteren wij de ‘Deliver’-fase wél serieus anders. Ik herhaal het nog maar eens: opleveren is nog geen implementeren. Daarbij zit de duivel in de details: een ‘Deliver’-fase in mijn definitie gaat juist over de eerder genoemde details van het ‘inpassen en -meten’ in de huidige organisatie. En over het duurzaam blijven (op)leveren van toegevoegde en publieke waarde.

Closing the loop: zorg dat je niet losgezongen raakt, maar de organisatie voldoende aanhaakt

Allereerst maken mijn collega’s en ik er een punt van om tijdens het ontwerpen de feedbackloop in de organisatie te sluiten. Daarbij bedoel ik niet de feedback tussen eindgebruiker en nieuwe dienst of product, maar juist die tussen het nieuwe en het oude. Tussen management en uitvoering. Tussen innovatieteam en de mensen waar ze voor werken.

In dat kader hield ook Jasper van Kuijk onlangs een fijn betoog in de Volkskrant. Hij pleit voor bedachtzamer omgaan met innovatie, voor de noodzaak van om innovatieprojecten niet te ver los te koppelen van de dagelijkse praktijk. Hij schrijft: “Innovatie gaat over iets anders doen dan wat je al doet en dus is het logisch om daar ruimte voor te creëren. Zodat een team tijd heeft om van een afstand naar dingen te kijken. Om te experimenteren zonder dat dat direct morgen resultaat op hoeft te leveren. […] Juist in de vrijheid van innovatielabs zit een valkuil. Die kan namelijk ook doorschieten naar los gezongen. Dan resulteert dat losstaan van de dagelijkse praktijk erin dat wat bedacht wordt weliswaar heel vernieuwend is, maar ook onhaalbaar. Of nutteloos. En dat zelfs goeie (vernieuwende én haalbare) concepten lastig hun weg vinden naar de rest van de organisatie. Mensen willen toch minder snel aan de slag met ideeën die niet van hen zijn, het not-invented-heresyndroom. Ook gevaarlijk: de mensen die dat nieuwe concept ‘alleen nog uit hoeven te werken’ snappen het veel minder goed dan degene die het bedacht hebben.”

Ook (ex-)designprofessor Kim Erwin (IIT Institute of Design) herkent het laatste punt dat Van Kuijk maakt. Ze noemt dat “the idea that can’t leave the room”: een kleine groep mensen in de innovation war room kent de finesses, maar daarbuiten gaat het mis. Nieuwe ideeën worden namelijk geaccepteerd, verworpen of genegeerd, op basis van hoe goed we ze begrijpen. Erwin pleit ervoor om de organisatie (of het systeem) waarbinnen je innoveert niet simpelweg te vertellen wat het eindresultaat van je project is (zoals veel innovatieteams dus doen: ‘delivered, and now it’s yours!), maar juist in het hele proces mee te nemen.

Mijn collega’s en ik zorgen daarom altijd voor een side track in ons innovatieproject, waarbij we alle activiteiten, inzichten, opbrengsten en ontwerp- en strategische keuzes zo veel en zo snel mogelijk al delen. Ook zoeken we al de interactie met de organisatie, op verschillende niveaus, zodat mensen in een vroeg stadium input kunnen geven en voor kunnen sorteren. Als je er niet voor zorgt dat het juiste gesprek op het juiste moment aan de juiste tafels wordt gevoerd, kom je nooit voorbij de pilot of het experiment. Dat communicatiespoor noemen wij het ‘verhaalbaar maken’ van de verandering. Dat is een belangrijke succesfactor voor de implementatie en adoptie van innovaties, die vaak over het hoofd gezien wordt.

De activiteiten en competenties die elk innovatieteam morgen aan elk project moet toevoegen

Voor het organiseren van die verbinding c.q. feedbackloop tussen verschillende lagen en processen is niet per se een apart teamlid nodig, maar wel een serie activiteiten die ervoor zorgt dat iedereen die nodig is op het juiste moment geïnformeerd en geïnvolveerd wordt. Maar pas op: verwar dit niet met ‘gewoon’ goed projectmanagement. In hun lezenswaardige essay Design thinking binnen de overheid (het essay is de moeite waard, maar weet wel: om het te downloaden moet je je gegevens achterlaten) schrijven André Schaminée en Kees Dorst al dat die feedbackloop tussen lagen en processen “niet besloten [zit] in de design-thinkingmethodologie”. Ze noemen dit “vooralsnog een vaag gebied waar de kwaliteit van procesbegeleiders en hun vaardigheid om te wheelen en dealen binnen het systeem cruciaal is” (p. 38). In die definitie lijken de activiteiten die nodig zijn nog het meeste op wat bekend staat als stakeholdermanagement. En dat is dan ook de eerste competentie die innovatieteams toe moeten voegen.

Een tweede competentie die elk innovatieteam zou moeten toevoegen is goed implementatiemanagement. Ook hier geldt: bij grote innovatieprogramma’s is deze rol doorgaans echt wel ingevuld, maar bij het gemiddelde kleinere innovatieproject zeker niet. De rol van de implementatiemanager wordt gaandeweg het project groter; in de ontwerp- en iteratiecyclus van het prototype zorgt hij of zij dat de juiste mensen op juiste het moment al betrokken worden. Maar naarmate het moment dichterbij komt dat een dienst of interventie wérkt en klaar is om geïmplementeerd te worden, moet de implementatiemanager echt aan de bak. Dan moet er een implementatie- en schalingsstrategie liggen die zorgt dat de organisatie gecontroleerd én met voldoende tempo leert werken met de nieuwe dienst of interventie. Meestal betekent dat ook: anders werken.

Dat vraagt dus om transitie- of verandermanagement; de derde competentie die toegevoegd moet worden. Een transitiemanager ondersteunt en coacht management en medewerkers bij de daadwerkelijke implementatie — een fase ná het oplevermoment zelf, die dus best lang kan duren. Hij of zij begeleidt bij de nieuwe manier van werken, en besteedt veel aandacht aan het daarbij behorende gewenste gedrag en de gewenste houding of denkwijze. Dat betekent dus óók dat innovatieteams al in het ontwerptraject moeten nadenken over dat gedrag en die houding – en dat is niet altijd vanzelfsprekend onderdeel van hun scope.

Deze 3 competenties of rollen hoeven niet per se door 3 personen ingevuld te worden. Ze liggen dicht tegen elkaar aan. We zien dan ook vaak dat ze worden gecombineerd, en door 1 of 2 teamleden worden ingevuld.

Ten slotte: innovatie is sexy, maar is ‘verbeteren’ soms niet genoeg?

Als laatste gooi ik nog maar een knuppel in het hoenderhok: moeten we altijd innoveren? Ik snap dat het spannend(er) is dan sleutelen aan het huidige. En ja, in sommige situaties is het volledig opnieuw uitvinden van een servicemodel of het ontwikkelen van iets volstrekt nieuws nodig. Omdat een probleem blijft voortbestaan, omdat er zand in de raderen zit waardoor alles vastloopt, of omdat het simpelweg een kwestie is van innovate or die. Maar in andere gevallen is het eigenlijk voldoende om ‘een mastje erbij’ te zetten, zoals Yousri Mandour en Dorien van der Heijden een incrementele verbetering noemen in hun boek De strategie van de kreeft.

Ook Van Kuijk wijst in zijn eerder genoemde column op de waarde van kleinere en haalbare verbeterstappen in multidisciplinaire verbeterteams die vanuit een uitdaging of thema te werk gaan en alleen ‘innoveren’ als dat écht nodig is: “Meer dan in innovatielabs zie ik wat in het organiseren van innovatieprojecten met zowel hardcore-innovatietijgers als mensen uit ‘de lijn’ of de meer reguliere productontwikkeling. En die niet in het wilde weg innoveren, maar rond een uitdaging of thema. Met als opdracht niet ‘innoveert!’ maar ‘verbetert! (en innoveert als dat nodig blijkt)’.”

Voor zo’n soort opdracht geldt alles wat ik hierboven schreef nog steeds, maar wel in mindere mate. Want in een optimalisatietraject is – de naam zegt het al – iedereen er juist op gebrand om het huidige te verbeteren. Dan is de innovatie veel meer onderdeel van het huidige proces. En daarbij zijn modellen als de Double Diamond wel degelijk effectief, praktisch en bruikbaar.

In die gevallen kun je volstaan met een simpele ‘oplevering’, omdat de volgende stappen geborgd zijn in het proces. En zou je – om ook maar af te sluiten met Stevie Wonder –  een tijdje na lancering kunnen volstaan met een telefoontje naar de business: “I just called to say I love it, maar hoe bevalt het júllie?”

Dit artikel verscheen op 30 maart 2021 bij Gebruiker Centraal.