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:
Verplicht
E-mailadres:
Verplicht, wordt niet gepubliceerd
Website URL:
Optioneel, wordt gebruikt als link
Om misbruik te voorkomen, dien je onderstaande captcha in te vullen.
p2rlJ
Captcha:
Verplicht, neem alle cijfers en letters (hoofdlettergevoelig) over zonder spaties