Onenigheid tussen stakeholders

Onenigheid tussen stakeholdersIeder ICT-project heeft stakeholders. Als niemand belang heeft bij het te ontwikkelen systeem zou er immers geen budget voor zijn. Voor requirements analisten is het cruciaal om inzicht te hebben in alle stakeholders en hun belangen. Dit zijn immers de belangrijkste bronnen voor de requirements.

Heb jij alle stakeholders in beeld? Met hoeveel verschillende soorten groepen stakeholders moet jij rekening houden in je project? Bij de meeste ICT-projecten loopt dat aantal al snel op tot boven de tien stakeholdersgroepen.

Zitten je stakeholders altijd op één lijn?

Grote kans van niet. Ik ben nog nooit een project tegengekomen waarbij er geen meningsverschillen tussen stakeholders waren. Dat is niet verwonderlijk aangezien de stakeholders heel divers zijn en vanuit verschillende achtergronden en belangen tegen het project aankijken. Dit is positief en gezond: het verruimt je blikveld, stimuleert creativiteit en is onmisbaar voor innovatie. Maar als stakeholders blijven vasthouden aan hun mening en het niet eens kunnen worden, ontstaan soms lastige conflicten.

Wat doe jij als de stakeholders het niet eens kunnen worden?

... of erger, als er een conflict over de requirements ontstaat?

Conflict stakeholdersHier zijn mijn tips:

  • Breng alle stakeholders en hun belangen vroegtijdig in beeld zodat je niet voor verrassingen komt te staan. 'Vergeten' stakeholders is een recept voor weerstand en onenigheid.
  • Houd alle stakeholders vanaf het begin op de hoogte van de tot dan toe opgestelde requirements en de besluiten zodat de meningsverschillen en conflicten vroegtijdig aan de oppervlakte komen.
  • Stel de aard van het conflict vast zodat je een oplossingsstrategie kunt kiezen die daarbij past. Conflicten kunnen verschillende oorzaken hebben:
    1. Verschil in informatie
      Een conflict kan ontstaan doordat één of meer stakeholders foutieve of te weinig informatie heeft gekregen of doordat de stakeholders de informatie op verschillende manieren interpreteren.
    2. Verschil in doelstellingen
      Als stakeholders niet dezelfde doelen nastreven kan gemakkelijk een conflict ontstaan. Bijvoorbeeld doordat de ene stakeholder de verkoopprijs van het product zo laag mogelijk wil houden en een andere stakeholder het aantal serviceverzoeken en foutmeldingen wil terugdringen.
    3. Verschil in belangen
      Tegenstrijdige belangen leiden niet zelden tot conflicten. Het meest in het oog springende voorbeeld is de altijd aanwezige strijd in projecten tussen snelle time-to-market, halen van de planning, extra functionaliteit en goede softwarekwaliteit.
    4. Persoonlijke relaties
      Een goede voedingsbodem voor conflicten zijn verstoorde persoonlijke relaties tussen stakeholders. Niet de requirements zelf maar bijvoorbeeld laten zien wie de meeste macht heeft, is dan de bron van het conflict.
    5. Verschil in hiërarchie of status
      Soms ontstaat een conflict doordat een stakeholder de overtuiging heeft dat een collega niet competent genoeg is om de juiste requirements te benoemen. Dat oordeel wordt soms geveld over (hiërarchisch) ondergeschikte medewerkers of minder gespecialiseerde collega's.
  • Kies de best bij de situatie en de aard van het conflict passende strategie. Als requirementsanalist heb je de keuze uit een lange lijst met onderhandelings- en andere strategieën om het conflict samen met de stakeholders op te lossen.
  • Betrek alle stakeholders bij het zoeken naar een oplossen voor het conflict. Dit geldt ook voor de stakeholders die geen conflict hebben maar wel belang hebben bij het onderwerp. Op deze manier voorkom je dat later een tweede conflict over hetzelfde onderwerp ontstaat.
  • Maak aan het begin van het project met alle stakeholders afspraken over de te volgen procedure bij een eventueel conflict. Wanneer een conflict zich manifesteert ben je daarvoor waarschijnlijk te laat.

Er zijn ongetwijfeld nog veel meer waardevolle tips te geven. Laat jouw tips achter in het reactieveld.

Op waardevolle leermomenten,
Nicole de Swart

Community of interest
Elkaar verder helpen bij het opstellen van requirements, daarvoor is deze community bedoeld.
Hier schrijven leden regelmatig over hun ervaringen en visie op het vakgebied.
Community
Deze community is begin 2012 gestart vanwege de wens om het Requirements Kenniscentrum interactiever te maken.


Word ook gratis lid
Schrijf je in en ontvang eens per maand requirementstips en actuele informatie.






Reacties (12)

- probeer niet zelf het conflict op te lossen. Laat het over aan de stakeholders. Benadruk wel het belang voor het project bij een oplossing van het conflict. Maak het niet jou probleem.
Albert Jan Hoff
Mijn tip: Zorg dat alle stakeholders hetzelfde begrippenkader hanteren en erkennen. Ogenschijnlijk dezelfde begrippen, die een andere interpretatie kunnen bevatten, zijn een bron voor conflicten.

Zo kan bijvoorbeeld hetzelfde woord (begrip) binnen de context van twee verschillende organisaties een heel verschillende inhoud hebben. Door dit verschil in interpretatie van een begrip ontstaat aan beide zijden onbegrip voor elkaars positie en onstaan mogelijk conflicten.
Doralin Duta
In een Scrum aanpak is de Product Owner degene die alle neuzen in dezelfde richting brengt.
<<
De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product en de werkzaamheden van het Ontwikkelteam.Hoe dit precies gedaan wordt verschilt enorm per organisatie, Scrum Team en individuen.De Product Owner is de enige persoon die verantwoordelijk is voor het managen van de Product Backlog.[...]
Om te kunnen slagen als Product Owner, moet de gehele organisatie zijn of haar beslissingen respecteren. De beslissingen van de Product Owner zijn zichtbaar in de inhoud en ordening van de Product Backlog.
>>
Scrum Guide 2011 - scrum.org

Mocht de Requirements Analyst de rol van Product Owner vervullen, dan spellen zijn/haar Soft Skills - zoals stakeholders- en verwachtingmanagement, conflicthantering, communicatievaardigheden - een belangrijk rol (naast zijn/haar Hard Skills).
De Ridder Anja
Het is beter om één aanspreekpunt te hebben die beslissingsbevoegdheid heeft welke requirements is belangrijker dan de andere.
Vaak zijn conflicten te voorkomen door de elicitatie van requirements niet individueel te doen maar het in workshopvorm te doen. Dan zie je dat door de interactie tussen stakeholders er al veel meer begrip ontstaat voor elkaars belangen of zienswijzes. Door deze interactie en begrip die daardoor ontstaat, voorkom je veel conflicterene requirements al in een vroegtijdig stadium.
Rob van Haarst
Mmm, het klinkt goed, één centraal aanspreekpunt die de neuzen dezelfde kans op krijgt en ook nog het laatste woord heeft over prioriteiten. Maar waarom zou iedereen zomaar naar zo'n persoon luisteren?

In Scrum krijgt de Product Owner wel heel veel op zijn of haar bordje. Ik ben nog weinig van dat soort superpersonen met zoveel natuurlijk gezag tegengekomen.

Mijn tip: gebruik liever een goede, aan alle betrokkenen uitgedragen methodiek en maak iedereen gezamenlijk verantwoordelijk voor de INHOUD van de product backlog.

De Product Owner is dan niet eindverantwoordelijk voor: wat is het beste voor het project of de organisatie. Maar voor dingen als: is de product backlog duidelijk en consistent; hebben we deze beslissing niet al eerder genomen; snapt en raadpleegt iedereen de product backlog wel; is de motivatie en bron van deze prioritering wel traceerbaar voor iedereen.

Als het lukt om een centraal aanspreekpunt met beslissingsbevoegdheid te vinden (zoals de product owner in Scrum) dan zou dat een hoop 'gedoe' schelen voor de analist.

Dit brengt mij op de vraag:
Hoe ver gaat de verantwoordelijkheid van de requirementsanalist als er meningsverschillen of conflicten ontstaan tussen stakeholders?

Mijn antwoord: Als requirementsanalist zou ik mijn best doen om conflicten te voorkomen en ik zou in eerste instantie de lead nemen bij het oplossen van een conflicten. MAAR als blijkt het de oorzaak van het conflict ligt bij '4. persoonlijke relaties of 5. hiërarchie of status' (zie artikel) of dat het conflict om een andere reden hardnekkig blijkt te zijn, dan zou ik het terugleggen bij de business/opdrachtgever.

Ik ben benieuwd hoe jij omgaat met conflicten. Laat het aub even weten in het reactievel hieronder.
Gerrit Muizelaar
Het maakt eigenlijk niet zo veel uit of je requirements engineering moet doen in een traditioneel "waterval-traject" of juist in een RUP/SCRUM omgeving. Overal zijn er directe en indirecte stakeholders die uiteenlopende belangen kunnen hebben. Voer daarom altijd - en in een zo vroeg mogelijk stadium - een krachtenveldanalyse uit. Typer je partijen o.b.v.

1) Kan hij/zij invloed uitoefenen op het eindresultaat/de samenwerking of kan hij/zij invloed daarvan ondervinden
2) Betrekking: in hoeverre laten partijen zich leiden door de onderlinge relatie (de mate van vetrouwen die ze daar in hebben)

Je krijgt dan verschillende soorten stakeholders die je kunt plotten in een diagram: coalitiepartners, bondgenoten, opportunisten, twijfelaars, dwarsliggers en opponenten. Nadat je ze hebt geplot in een x/y diagram, breng je de onderlinge relaties aan en geeft daarbij aan of de relatie éénzijdig is dan wel twee kanten op gaat. En of het om een positieve of negatieve beinvloeding gaat. Als je dit allemaal in kaart hebt gebracht, kun je per stakeholder een actorkaart invullen, waarin je de benaderingsstrategie (inclusief korte termijn acties) aangeeft. Grofweg staan twee modellen je ter beschikking: het weerstandsstrategiemodel en de participatieladder (voor het bepalen van de mate waarin je een partij wilt betrekken). Je kunt er voor kiezen om het weerstandsstrategiemodel van Ezerman te gebruiken. Filosofie is dus dat hoe minder je overtuigings- en macht-dwangstrategieën al in vroege fasen van het veranderingsproces toepast, des te meer de bereidheid ontstaat om mee te denken over de wenselijkheid van de veranderingen.

Als je er echt niet uit komt: je hebt dan in ieder geval structuur aangebracht in de chaos, je hebt inzichtelijk gemaakt wie met welke belangen waarom reageert zoals hij/zij reageert. De uiteindelijke beslissing kun je dan met onderbouwing voorleggen aan de opdrachtgever of product owner die de knoop moet doorhakken.
Communicatie is de enige manier om verschillen te overbruggen. Ik denk wel dat je niet zelf die verschillen moet proberen op te lossen, maar moet proberen en faciliteren dat de stakeholders onderling de verschillen oplossen.
Hierboven wordt aangegeven dat dit kan worden opgelost door niet met de stakeholders te praten maar met 1 vertegenwoordiger van deze stakeholders, maar dit werkt natuurlijk alleen voor zover deze persoon zich dan van bewust is dat hij/zij de stakeholders bij elkaar moet brengen. Dit is niet een probleemoplossing, maar het verleggen van het probleem. En ik zou zo'n cruciaal punt liever niet uit handen geven.
Eric Fassotte
Net zoals Paul van Kemenade zou ik alle stakeholders bij elkaar zetten.

1. Verschil in informatie
Door het groepsproces komt hier (meer) gelijkheid in. De analist heeft hierin een grote rol.

2. Verschil in doelstellingen
De groep zal een juiste balans weten te vinden om toch tot een onder de omstandigheden optimale oplossing te komen.

3. Verschil in belangen
hier komt Paul's argument van het vergroten van het wederzijds begrip om de hoek kijken.

4. Persoonlijke relaties
In een groep kunnen 'verstoringen door persoonlijke relaties' moeilijker uitgespeeld worden door het groepsproces. Als analist kun je ook goed observeren of dit 'spel' gespeeld wordt en daarop reageren. Let er wel goed op, dat de meerderheid niet altijd gelijk heeft.

5. Verschil in hiërarchie of status
In een workshop komt dit snel genoeg tot uiting in de reacties van de zich superieur voelende stakeholder. Hierop kun je als analist dan op inspelen door de andere juist het woord te geven en zijn kant van het verhaal te laten doen

Kortom: Door stakeholders bij elkaar te brengen in een workshop, zal de zelfreinigende werking van het groepsproces gaan werken. De analist moet er wel goed op letten, dat dit op de juiste manier gebeurt.
Maurice Spee
Meest eenvoudige en in de praktijk bewezen oplossing is om de stakeholders samen te brengen in 1 overleg, waarin ze face-2-face hun standpunten en ideeen toelichten. Vaak is dat al voldoende en blijkt de oorzaak van het probleem - misinterpratie van geschreven tekst - weggenomen te zijn.
Belangen verstrengelingen zijn er altijd. Maar is het niet zo dat het aanleveren/inventariseren van requirements een continue proces is? En in eerste instantie zal iedere requirement benoemd en beschreven worden. In de praktijk zullen de requirements pas geïnventariseerd worden op het moment dat een opdracht geformuleerd is. Het is naar mijn idee dan ook van belang die opdracht zo helder mogelijk te krijgen. Of dit nu in een traditioneel plan van aanpak komt of in een vision document als je met Scrum aan de slag gaat.

De opdracht zal dan ook de kaders en richting moeten geven, waarbij al een groot deel van mogelijke conflicten in belangen wordt weggenomen. Dan is het zaak om goed te kijken naar de toegevoegde waarde voor de business van een requirement. Waarom blijft een stakeholder zo vasthouden aan het belang van een requirement? Eigen of business belang?

Zoals Paul aangeeft: zorg na eventueel een individuele ronde van inventarisatie altijd voor een vorm waarin alle stakeholders betrokken zijn om de belangen toe te lichten. Schets daarbij eerst nogmaals de opdracht en kaders. Wat is het te bereiken einddoel en voor wie of welk proces? Geef het overzicht/inzicht in de requirements waar geen conflicten in zitten en wat dus al wel bereikt is. Leg de focus dan alleen op de nog op te lossen conflicten. Vraag toelichting aan de stakeholder. Laat de stakeholder de toelichting geven gerelateerd aan het einddoel. Het groepsproces zal zorgen voor het bepalen van het uiteindelijke belang.

En zorg dat er een iemand eindverantwoordelijk is: product owner, opdrachtgever, projectleider. Dus mocht er geen overeenstemming komen, dan maakt de eindverantwoordelijke, gefundeerd, een keus.

Geef een reactie

Reactie:
Naam:
E-mailadres:
Website URL:
(Verplicht)
(Verplicht, wordt niet gepubliceerd)
(Optioneel, wordt gebruikt als link)
Om misbruik te voorkomen, dien je onderstaande 'captcha' in te vullen.
7 F X D S
Captcha:
(Verplicht, neem alle cijfers en letters (hoofdlettergevoelig) over zonder spaties)