Denken in oplossingen doen we bijna allemaal. Dat is hartstikke goed en waardevol, maar niet voordat je het probleem helder hebt. En hier wringt de schoen.
Stakeholders hebben, vaak onbewust, al een oplossing in hun hoofd. Het is verleidelijk om daarin mee te gaan en user stories, requirements of wijzigingsverzoeken te definieren die de gewenste oplossing beschrijven.
De kans is dan groot dat er veel tijd, geld en energie in het realiseren van de verkeerde oplossing wordt gestoken.
Als niet duidelijk is welk probleem opgelost moet worden, gaat de oplossing een eigen leven leiden. Het realiseren van die oplossing wordt dan het doel in plaats van het achterliggende probleem uit de wereld helpen.
Maak het probleem helder
Idealiter begint het team bij een nieuwe opdracht of nieuw project met het helder maken van het probleem. Vroeger maakten we daarvoor een uitgebreide probleemanalyse om op basis daarvan oplossingsrichtingen voor te stellen.
Tegenwoordig doen we dat met een productvisie met daarin het productdoel en gaan we de oplossing iteratief en incrementeel ontwikkelen.
Maar in de praktijk zien we dat veel te weinig organisaties hun agile aanpak op deze manier vormgegeven. Dat biedt je als analist de kans om je toegevoegde waarde te laten zien.
Het achterliggende probleem
Goed doorvragen naar het achterliggende probleem leidt niet zelden tot nieuwe inzichten bij stakeholders en uiteindelijk tot een eenvoudigere, effectieve of goedkopere oplossing.
Dat is helaas makkelijker gezegd dan gedaan. Je moet namelijk tegen de stroom in zwemmen.
Als iedereen al diep in de details van de oplossing zit en jij vragen gaat stellen over het achterliggende probleem, word je dat vaak niet in dank afgenomen. Als je dat ook nog eens doet door steeds te vragen naar het “waarom”, raken je gesprekspartners al snel geïrriteerd.
Tactvol doorvragen
Omdat dit een veelvoorkomend uitdaging onder analisten is, hebben we onderstaande tip opgenomen in ons gratis e-book 52 Agile requirements tips & inspirerende quotes.
Nieuwsgierig naar onze andere agile requirements tips & inspirerende quotes? Download hier gratis het e-book.
Voorbeeldvragen
In de laatste zin van deze tip worden drie manieren genoemd om waarom-vragen af te wisselen met andere type vragen. Om het concreet te maken geven we van alle drie de manieren een aantal voorbeelden.
1. Waarom-vraag anders formuleren
Je camoufleert de waarom-vraag als het ware. Dat doe je bijvoorbeeld met vragen als:
- Wat is de reden dat …?
- Wat is daar het voordeel van?
- Waar heb je dat voor nodig?
2. Probleemgerichte vragen stellen
Het idee is om door te vragen over het belang van de oplossing in plaats van dieper in te gaan op de details van de oplossing. Dat kan bijvoorbeeld met de volgende vragen:
- Waar heb je geen last meer van, als deze oplossing gerealiseerd is?
- Wat gaat er mis als dat geen prioriteit krijgt?
- Waar heb je dat precies voor nodig?
3. Toekomstgerichte vragen stellen.
Hierbij vraag je door naar de gewenste situatie. Je stelt bijvoorbeeld vragen als:
- Wat gaat er straks beter als dit project succesvol is afgerond?
- Wanneer is dit project wat jou betreft een succes?
- Wat hoop je hiermee te bereiken?
Deze voorbeeldvragen komen uit de online training De kunst van het doorvragen. Daarin leer je hoe je goed doorvraagt zonder irritatie op te wekken, zodat je het achterliggende probleem boven water krijgt.
Nicole de Swart & Priya Soekhai
Het probleem goed in kaart hebben is een noodzakelijke maar niet voldoende voorwaarde. Het probleem begrijpen is een ding maar begrijpen waarom het een probleem is (hinderpaal voor strategische doelen) en hoe het wegwerken ervan zal bijdragen aan het realiseren van de strategie vormen in tandem met het begrijpen van een probleem een noodzakelijke en voldoende voorwaarde.
Outcomes vormen de weg hiertoe. Een probleemstelling is, leuk maar helpt niet veel. Weten dat facturen te laat gemaakt worden (het probleem) is goed maar waarom moet het sneller (bv verbeteren van het financieel rendement – maar dan in meetbare kenmerken uitgedrukt zoals cashflow met 10% verbeteren over drie jaar). Meteen wordt duidelijk dat informatica niet de volledige oplossing kan bieden omdat bv de gehele procesflow (order to cash) moet herbekeken worden. Dit zal leiden tot change management,, aanpassingen in andere systemen, communicatie naar klanten en dergelijke.
Bijkomend is nog dat we ons meestal blindstaren op de investering en de rest vergeten. In het beste geval is dit verantwoordelijk voor zo’n 20% van de lifecycle kost en de daadwerkelijke ontwikkeling bedraagt ongeveer 1/3 daarvan – dus ongeveer 6% van de lifecycle kost. Software ontwikkeling wordt dan peanuts in het verhaal.
Hallo Rik, Bedankt voor de aanvulling. Inderdaad ook noodzakelijk om te weten waarom iets een probleem is.