Stakeholder management, maar dan bottom-up

Nu het eind van het jaar in zicht komt, maken veel organisaties hun plannen op voor 2019. Onderdeel hiervan is het benoemen van duidelijke prioriteiten, die zorgen voor een passende budgetverdeling en inzet van de beschikbare capaciteit. Dat klinkt eenvoudiger dan het is. Plannen maken lukt vaak nog wel, maar het stellen van duidelijke prioriteiten is een stuk lastiger. Vooral als er meerdere stakeholders zijn, ieder met hun eigen belangen. Hoe ga je hiermee om als er sprake is van vele kapiteins en maar één schip? Oftewel: hoe organiseer je je stakeholder management?

Bij veel organisaties wordt er op verschillende volwassenheidsniveaus ‘geëxperimenteerd’ met Scrum en Agile werken. Daarbij is de context van elke organisatie uniek. Het maakt niet uit hoe ver een organisatie is met het creëren van een Agile mindset en het werken in bijvoorbeeld scrumteams: er zijn geen panklare recepten voor het neerzetten van een scrumteam of het organiseren van sturing en governance rondom dat team of binnen een organisatie. Een hoofdingrediënt is vaak: hoe organiseer je team(s) rondom producten?

Tegengestelde belangen in stakeholder management

Rondom sturing en governance van een product kun je grofweg onderscheid maken tussen een complex en minder complex stakeholderveld. Zelf heb ik in een situatie gezeten als Product Owner Business Intelligence, waarbij de diverse directies van de organisatie afnemer waren van de BI-inzichten. Business controllers hadden inzicht nodig in de financiële en operationele cijfers, HR was met name geïnteresseerd in mobiliteit en vitaliteit en de managementteams van de verschillende directies hadden hun eigen rapportage- en dashboarding-behoeften. Kortom: vele stakeholders die allemaal behoefte hadden aan inzicht en meer datagedreven wilden worden.

Maar er zat maar één Scrumteam en één Product Owner, die verantwoordelijk is voor de Product Backlog en het prioriteren daarvan. Die manier van werken, met een Product Owner, was relatief nieuw. En dat betekende ook wat voor het stakeholder management. Als Product Owner word je gek van al die tegengestelde belangen en verschillende niveaus van invloed. Prioritering is nog wel mogelijk als je besluitvaardig bent, maar als je alles wilt overleggen met je stakeholders, wordt het een vervelend en complex klusje. En als je besluitvaardig bent, bestaat het risico dat je stakeholders zich onvoldoende gehoord voelen over de prioritering. Hoe organiseer je nou de buy-in voor de prioritering? Of eigenlijk: Hoe organiseer je ‘bottom-up’ stakeholder management om met elkaar een (juiste) prioritering te stellen?

Als je besluitvaardig bent, bestaat het risico dat je stakeholders zich onvoldoende gehoord voelen over de prioritering. Hoe organiseer je nou de buy-in voor de prioritering?

Stakeholder management: Stappenplan

Met veel stakeholders, veel belangen en verschillende niveaus van invloed en niemand die echt gelukkig is met de huidige situatie, wordt het lastig om een succesvol bottom-up stakeholder management voor elkaar te krijgen. Daarom laat ik je graag kennis maken met een stappenplan om meer waarde te halen uit bottom-up stakeholder management. Typische takken van sport waarbij je een soortgelijk stakeholderveld treft, zijn: intranet, datadomein, infrastructuur en webportalen. Maar ook op andere situaties is het zeker toepasbaar.

Stap 1. Breng je stakeholderveld in kaart

Ben kritisch bij het in kaart brengen van je stakeholders. Zelf had ik te maken met die ene business controller die altijd alle afwijkingen spot in de data en een fijne sparringpartner is. Niet iemand met het juiste niveau als het gaat om de afstemming van de prioritering, maar wel voor de uitwerking op inhoud, zoals het niveau van user story’s. Daarnaast had ik die ene afdelingsmanager met veel belang bij het product en veel invloed op andere stakeholders, maar die inhoudelijk wat tekortkomt.

Begin met het in kaart brengen van je stakeholderveld en bedenk hoe je je stakeholders gaat ‘involveren’. Roman Pichler heeft hier mooie handvatten voor. Het doel van stakeholder mapping verwoordt hij hier mooi: ‘It’s […] important to engage the right stakeholders and […] work with them in the right way.’

Die ene business controller komt in het ‘Subjects’ vak, de afdelingsmanager in het ‘Players’ vak. Denk ook aan formele en informele stakeholders. Staar niet blind op ‘managementniveau’, maar kijk ook naar gebruikersgroepen. Werk ook uit op welke manier de verschillende stakeholders invloed en belang hebben. Leer ze kennen en probeer hun uitdagingen te begrijpen. Heb je je stakeholders in kaart gebracht? Hoe vol is het veldje van de Players?

Stap 2. Speel het spel met de Players

Met de stakeholdermapping heb je een eerste stap gezet met je stakeholder management. Het doel van de volgende stap is het voorbereiden van de Players op het vervolg en ze duidelijk maken wat je van hen verwacht. En wat ze van jou mogen verwachten natuurlijk.

Mijn uitkomsten van de stakeholder mapping waren een overzicht van de stakeholders en een plan om de verschillende soorten stakeholders te betrekken bij het spel. Voor het vervolg zijn met name de Players van belang. Zij hebben voldoende invloed en belang om ze te betrekken bij het bepalen van de prioritering. Het is van belang erachter te komen of zij voldoende mandaat hebben bij hun achterban om als ‘vertegenwoordigers’ te worden gezien van die achterban.

Hier kom je achter door het rechtstreeks aan een Player te vragen. Het is van belang voor het vervolg om je verwachtingen helder over te brengen richting de Player. Deze persoon zal zelf de communicatie en afstemming met de achterban moeten regelen: door het ophalen van de wensen/problemen/behoeften m.b.t. je product en door het aanwijzen van mensen met meer inhoudelijke kennis voor het uitwerken van die wensen/problemen/behoeften (hierna: epics). Maak ook duidelijk wat ze van jou kunnen verwachten: hoe ga je ze helpen het spel te spelen?

Stap 3. Breng samen met de Players de behoeften in kaart en verbind er waarde aan

Wat je vooral niet moet vergeten: waar hebben de Players je hulp en die van het team bij nodig? Het doel van deze stap is om in kaart te brengen wat hun behoefte is en er een vorm van waarde aan te verbinden. Ga dus in gesprek met je Players.

Zelf had ik regelmatig gesprekken met de diverse Players. Daarin ontwikkelde ik de relatie met de stakeholder en was er voldoende ruimte to talk business. In deze gesprekken bracht ik hun behoefte (in de vorm van epics) in kaart. Dus: vraag ze het wat en waarom van hun behoefte goed toe te lichten.

Wat is hun probleem en waarom moet dit worden opgelost? Als je het niet oplost, wat valt er dan om of vliegt in de fik? Probeer ook de mogelijke resultaten in kaart te brengen; stel nou dat we dit voor je gaan oppakken, wat verwacht je dan te kunnen als het af is en aan welke vraag kun je dan voldoen? Het belangrijkste is dat de stakeholders leren een verhaal te vertellen. Een verhaal blijft vele malen beter hangen dan een lijst met requirements.

Het belangrijkste is dat de stakeholders leren een verhaal te vertellen. Een verhaal blijft vele malen beter hangen dan een lijst met requirements.

Je helpt je Players het verhaal te vertellen over het wat en waarom. Een belangrijk resultaat van deze stap is het verbinden van waarde aan de epics vanuit de verschillende stakeholders. Iedereen vertelt z’n eigen verhaal, maar je wilt de waarde van de epics kunnen afzetten tegen een ‘objectieve maatstaf’. Denk hierbij aan de bijdrage van deze epic aan de strategische doelstellingen van de organisatie en aan klantwaarde.

Probeer dus de waarde te plotten binnen de context van de organisatie. Zelf plotte ik de waarde op drie assen: klantwaarde, bijdrage aan strategische doelstellingen en stakeholderwaarde (bijv. afspraken met externe partijen). Elk van deze drie assen scoorden we van 0 t/m 3. Een epic dat hoog scoorde op de drie assen, had dus ook een hoge waarde. stakeholder management

Stap 4. Bepaal de inspanning van de epics met je team

De uitkomst van stappen 3 en 4 is een waarde/inspanning-matrix. Een laatste stap is het ophalen van de inspanning om een dergelijk epic te realiseren. Het is aan het team om die inschatting te maken. Het moet geen rocket science zijn, maar vooral een snelle inschatting van de benodigde inspanning. Zelf gebruikte ik samen met het team T-shirt sizes. In een sessie met het team lichtte ik de epics toe en het team ging in gesprek over de mogelijke omvang. Met je scrum master kun je hier een leuke werkvorm voor verzinnen. stakeholder management

Stap 5. Plot de epics op waarde en inspanning voor een goed gesprek met de stakeholders

Roep na al dit voorwerk de stakeholders bijeen om in een gezamenlijke sessie de prioritering te bepalen en verzin hier een leuke werkvorm voor. Het is van belang om de stakeholders te vertellen wat het doel van de sessie is en wat je verwacht van hun deelname. Het is denkbaar dat stakeholders andere hiërarchische strepen op hun schouder dragen.

Vraag ze om dat even los te laten: in deze sessie gaat het over het bepalen van prioritering, gekeken naar waarde (die heb je in stap 3 ‘stakeholder neutraal’ gemaakt) en inspanning (door het team ingeschat) in stap 4. Grijp in als je ziet dat er traditioneel vanuit de hiërarchie wordt gestuurd in de sessie. Laat de stakeholders onderling de prioritering uitmaken, maar daag ze uit door vragen te stellen over het wat en waarom van ‘hun epic’.

Neem zoveel tijd als hun agenda’s toelaten, zorg ervoor dat het resultaat een lijst van prioriteiten is en koppel terug hoe je met deze uitkomsten verder gaat. Let op dat er tijdens de sessie geen sprake is van scope creep: de epics die de stakeholders met zich meenemen, zijn de epics die op dat moment worden besproken. Als er nieuwe epics of thema’s werden aangehaald, zette ik deze op een parkeerplaats met als boodschap: hier komen we een volgende keer op terug!

Stakeholder management: tips
Geef de sessie een leuke naam en leg op voorhand uit wat het doel is van de sessie. Bedenk een leuke werkvorm voor het vormgeven aan de prioritering. Zelf werkte ik met pokerfiches: de Players bepaalden zelf hoeveel geld ze wilden inzetten op de verschillende epics. De epics met het meeste geld kregen de grootste prioriteit. Laat de stakeholders met elkaar onderhandelen en zorg dat het gesprek vooral gaat om de bijdrage aan de (strategische) doelstellingen van de gehele organisatie en minder om de (persoonlijke) belangen van de individuele stakeholder.

Prioritering is een richtlijn en geen wet. De Product Owner heeft het mandaat om de uiteindelijke prioritering te bepalen op basis van zijn/haar inzichten van waarde, inspanning, complexiteit, afhankelijkheden, risico’s et cetera.

Stap 6. Evalueer!

Heb je bovenstaande stappen doorlopen en je eerste sessie gehad? Vraag de stakeholders dan om hun feedback en hun Return on Time Invested. Ben trots op wat je hebt neergezet! En vooral: bedenk hoe je dit spel met enige regelmaat kunt spelen. De wereld verandert en de prioritering (van epics en product backlog) verandert zeer waarschijnlijk mee. Daar wil je je stakeholders bij betrekken.

Zelf hield ik deze sessie om de twee sprints (elke zes weken), zodat ik voortgang kon laten zien en kon aangeven wat we hadden geleerd in die zes weken. Zo’n sessie is namelijk ook de uitgelezen plek om met je stakeholders in gesprek te gaan over voortgang, successen, impediments, keuzes en bovenal: hoe gaan en blijven we samen naar de resultaten toe werken?

Ervaringen en next steps

Mijn ervaringen met bovenstaand stappenplan? Ik onderschatte hoeveel tijd het kost om dit proces neer te zetten met mijn stakeholders. En ik onderschatte hoe enthousiast de stakeholders zijn over de uitkomsten van de sessies. Naar aanleiding van hun feedback zijn de sessies verder ontwikkeld, werd er vanuit het team transparantie gegeven over de voortgang (sprint rapportages, burn-up charts per epic) en impediments en was over het algemeen het gevoel dat er meer inzicht, invloed en vertrouwen was in het team.

Er zijn vele leuke manieren om de waarde en effort te bepalen van een epic of thema. Denk maar eens na over hoe je dit toepast binnen je eigen situatie of organisatie. Het gaat om uitproberen, evalueren en leren. Complexiteit hierbij is wel dat ook je stakeholders op een andere manier moeten gaan werken dan ze gewend zijn. stakeholder management