Mij blijft deze zin al een tijd bij:
“een pobleem is het verschil tussen de huidige en de gewenste situatie”.
Waarheid als een koe. Dat klopt natuurlijk altijd.
In de praktijk is het vaak onduidelijk wat het probleem is. Echte maatschappelijke opgaven zoals hoe om te gaan met klimaatverandering, inrichting van de stad, etc. zijn wicked. Wicked problemen zijn heel moeilijk of onmogelijk op te lossen vanwege onvolledige, tegenstrijdige, of steeds wijzigende eisen. Eisen die vaak ook nog moeilijk te herkennen zijn. De oplossingen van dat soort problemen zijn alleen “goed” of “fout”. Oftewel: valide voor een stakeholder. Niet verifieerbaar.
Daarom worden er “eisen opgehaald”. Dat is belangrijk. Echter zal niet iedere belanghebbende zijn of haar eisen klaar hebben liggen voor het specifieke probleem. Ook komen eisen niet overeen. De maatschappelijke opgave is wicked! Het team moet dan ook aan de slag het probleem te formuleren. Wat wel eens lijkt te worden vergeten is dat het hierbij niet anders kan dan ook oplossingen uit te gaan werken. Want: stakeholders kunnen veel beter feedback geven op een uitwerking van de oplossingsrichtingen of prototypen. Bovendien, bij wicked problemen zijn probleem en oplossing onderling afhankelijk.
De twee termen solution space (oplossingen bedenken, prototypen uitwerken) en problem space (situatie observeren, begrip opschrijven/definieren) zijn twee perspectieven van Design Thinking waar ik graag gebruik van maak in dat soort situaties.
Het uitwerken van beiden helpt duidelijk te maken wat de opgave is. Beiden zijn geen tegenstelling, maar een perspectief op dezelfde situatie. De specificatie van het probleem en de uitwerking van de oplossing kunnen dan wel gescheiden worden beschouwd en zelfs vastgelegd. De informatie stromen onderling moeten goed verwoven blijven (“terugkoppeling”), omdat feedback op een oplossingsrichting of het prototype juist helpt de hypothesen in de problem space te testen en verbeteren. Dit is ook een van de belangrijkste concepten achter Virtual Design en Construct: redeneren vanuit een oplossing die expliciet is beschreven om vooraf gedefinieerde doelstellingen te testen.
Leuk allemaal, beetje theoretisch. Hoe pak je dat praktisch aan?
- Modelleer de beschikbare informatie in concepten en onderlinge relaties. Dit kan een brainstorm cloud zijn, figuren op een whiteboard, of zelfs een beschrijving in een visuele taal zoals UML. Vaak lukt dit nog niet direct in detail of erg gestructureerd. Dat hoeft ook niet. Verzin ook niets nieuws. Met het model moet wel zichtbaar en – nog belangrijker – vlot deelbaar en controleerbaar worden wat bekend is. De opdeling van informatie in concepten en structuren is systems thinking. Vanuit diverse disciplines komen daar verschillende ‘patronen’ bij kijken om te helpen de beschikbare informatie te ordenen. Zo denkt de GISser al snel in beschikbare kaartlagen, de systems engineer in functies en systemen, en de civiel ontwerper in fysieke objecten op locatie. Die ervaring helpt de situatie snel en goed te duiden.
- Bespreek deze visuele informatie in een groep inclusief de probleem eigenaren. Een groep diverse stakeholders is bij dit soort overleggen altijd nuttiger dan meerdere gesprekken een-op-een. Door ideeën uit te wisselen en te bespreken worden verschillende perspectieven inzichtelijk. Begrip van de situatie groeit. Werk het visuele model bij.
- Werk vervolgens een (of enkele) oplossingsrichtingen uit. Dit kan nog schetsmatig. Bespreek het met in ieder geval het bredere team verantwoordelijk voor de realisatie van de oplossing. Bijvoorbeeld de modelleur die de vertaalslag maakt naar een Revit of Infraworks model. Zorg dat er onderling begrip is en dat de diepgang voldoende is om snel en goed de oplossing uit te werken. Blijven er (te) veel oplossingsrichtingen over? Vraag dan de probleem eigenaar de meest kansrijke richtingen te kiezen voor uitwerking en aan te geven waarom.
- Werk afhankelijk van de beschikbare en passende middelen zo vlot mogelijk een (of enkele) oplossingen uit. Net als bij scrum, maak iets dat werkt. Concreet: dus geografisch geprojecteerd op de kaart of – in de eerder genoemde “Virtual Design & Construct” termen – in ruimte en in tijd begrenst (zoals een massa model van de lay-out op het terrein incl. fasering).
- Plan meerdere vervolg iteraties (of sprints) in. Iedere sprint geeft feedback op een verdere uitwerking van de oplossing. Hoe meer iteraties je doet, hoe meer de oplossing het juiste maatwerk wordt voor een specifiek probleem en groep stakeholders.
De alsmaar complexere opgaven in de leefomgeving vragen niet om bekende oplossingen. Daar is het volgens mij essentieel bewust het proces in te richten gericht op iteraties en de bijbehorende tools op feedback. Vanuit het samen bespreken van de oplossing los je dan vlotter problemen op. Design Thinking dus.
