Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Voorkom onenigheid tussen stakeholders

Ieder ict-project heeft stakeholders. Als niemand belang heeft bij het te ontwikkelen systeem zou er immers geen budget voor zijn. Voor requirementsanalisten 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? Ik heb een aantal tips om deze situaties te voorkomen.

Breng allereerst 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 vervolgens de aard van het conflict vast zodat je een oplossingsstrategie kunt kiezen die daarbij past. Conflicten kunnen namelijk verschillende oorzaken hebben (zie kader).

Kies vervolgens 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. Ook moet je alle stakeholders betrekken 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.

Tot slot adviseer ik om aan het begin van het project met alle stakeholders afspraken te maken over de te volgen procedure bij een eventueel conflict. Wanneer een conflict zich manifesteert ben je daarvoor waarschijnlijk te laat.

Oorzaken van een conflict

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.

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.

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.

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.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4803919). © Jaarbeurs IT Media.
?

 

Reacties

Nicole

Stakeholder:
"From old practice of land claims, mineral rights, etc., where one placed a (wooden) stake to delineate the boundary of a claim of a property right."

Dat klinkt mij in de oren als piketpaaltjes slaan waardoor er uiteindelijk alleen nog maar mistake-holders overblijven;-)

Ewout ik denk dat je nog een stukje vergeet te kopiëren van het web vwb je definitie:

What is the history of the term stakeholder?

Beetje flauw om zo een opmerking te plaatsen als we weten wat er wordt bedoelt met de term stakeholder:

Een belanghebbende of stakeholder is een persoon of organisatie die invloed ondervindt (positief of negatief) of zelf invloed kan uitoefenen op een specifieke organisatie, een overheidsbesluit, een nieuw product of een project.
(wikipedia)

Willem,

Flauw of ongezouten?

Even wat verder googlen omdat er juist in academische wereld een leuke discussie is over wat nu precies een stakeholder is, de invulling van de term wordt namelijk nog weleens vanuit verschillende visies gedaan. Want wat zijn nu die 'vergeten' stakeholders waarover Nicole het heeft?

Ik ken namelijk nog wel een rijtje mistake-holders, met name bij (ICT)projecten waar het opstellen van requirements achteraf via een Poolse landdag gedaan lijkt te zijn.

Is dit oplossen / begeleiden van dit soort conflicten een taak van een requirementsanalist ???

Zelf zou ik zo'n taak eerder verwachten aan de kant van programma-management, roadmap of iets in die hoek. Daar wordt op basis van de belangen van de diverse stakeholders bepaald wat er in de volgende release van een product komt.
Mijns inziens is het dan aan de requirementsanalist om de wensen te analyseren en om te zetten naar requirements. Echter, op dat moment zijn de conflicten en tegenstrijdigheden reeds beslecht.

Reageerders gedragen zich hierbij juist wat academisch.
Nicole is hier de requirement expert met ervaring.
Kan me voorstellen dat alle (wannabe of niet) stakeholders zich gehoord willen zien. En ik neem aan dat de eigenaar ook in de requirements vermeld wordt. Aan de business om te oordelen en budgetteren.

Nicole,

1) Pa Va Ke was me voor. Zit je niet op de stoel van programmamanager? De zaken rondom managen van stakeholders behoren tot de taken van project- of programmamanager en niet een requirementconsultant.

2) dank voor de tips. Maar de benoemde tips ga je in het eerste jaar werken als projectleider/projectmanager als ervaring opdoen. Ik ga ervan uit dat de lezers van deze site (en dit artikel) geen beginners zijn

Misschien een tip voor jou: Lees het boek "100% succesvolle IT-projecten" ( http://www.managementboek.nl/boek/9789043023740/100-succesvolle-it-projecten-klaas-jung)

Het komt op mij over dat je hier pleit om iedereen tevreden te willen houden. Een loffelijk streven maar vaak is de realiteit toch wat weerbarstiger jammer genoeg. Iedereen een beetje tevreden dan maar? Ook een theoretische mogelijkheid ware het niet dat het zelfbewustzijn van de mensen ook nog eens om de hoek komt kijken. Dat in balans krijgen kan inderdaad een stevige uitdaging zijn. Het in balans houden is volgens mij de échte uitdaging. Naarmate de tijd verstrijkt is het zaak om die balans te houden door alleen in te spelen op de recente ontwikkelingen en zo strak mogelijk aan alle eerder gedane afspraken houden.
Als je een gebouw bouwt dan is dat meestal wel duidelijk. Maar als het om IT gaat wordt er nog steeds te makkelijk gedaan over aanpassingen. Het is onmogelijk om er nog een verdieping bovenop te zetten en binnen de afgesproken tijd te blijven.

Wat tips betreft moest ik denken aan een project wat al wat langer geleden is. De projectleider, een man met Italiaans bloed en misschien daarom ook wel wat sluwer was dan de gemiddelde Nederlander, die er vanaf het begin behoorlijk dicht op zat. Er moest iets geleverd worden en daar was een einddatum over afgesproken. Niet dat we er op zaten te wachten want het kwam pas later aan de orde. Maar toch omdat het zo was afgesproken was het heel belangrijk dat die datum gehaald zou worden terwijl het heel waarschijnlijk was dat dit niet het geval zou zijn.
Maar doordat het feit dat hij er zo dicht op zat kon hij de anderen aan hun woord houden en had hij al bij voorbaat een mentaal overwicht en stellen dat hij al wat had toegegeven qua het te laat zijn van een levering en dat daar wel iets tegenover mocht staan. Hij noemde dat 'wisselgeld'.

Requirement, stakeholder,kan het ook in het Nederlands? Dat voorkomt discussies, hoop ik.
Genoemde oorzaken van conflicten vindt ik open deuren, iedereen die wat over het modewoord (ook engels) coaching leest vindt het zelfde.
In google heeft coaching meer treffers in Nederland als er inwoners zijn, in Nederland . . .
Toch ook eens requiremens proberen.

@Nicole Je noemt een aantal oorzaken van conflicten die jou het werk van requirements optstellen belemmeren. Vraag is wat jij daar mee moet? Het lijkt me dat je er doorheen manouvreert en die requirements zo goed mogelijk op papier krijgt. Dat laatste, goede requirements, dat is waarom het gaat. Het wordt vervelend als het je werkt beinvloed dan is het tijd om aan de bel te trekken.

Persoonlijke belangen, onderlinge relaties, verschil in hierarchie (macht): waar heb je er niet mee te maken? Dat is nou de apenrots. Ik denk als die invloeden de overhand hebben dan sneuvelen de inhoud en de kwaliteit als eerste.

Het lijkt me dat schrijfster een punt heeft. De eisen/wensen van alle belanghebbenden moeten meegenomen worden in de analyse.

Dat is niet alleen maar een taak voor de programmamanager, die overigens vaak de kennis ontbeert om dit te kunnen, dat is zeker ook de taak van de requirementsanalyst.

Voorbeeld: als je beheereisen niet meeneemt in de analyse, kun je eindigen met een product dat niet beheerd kan of zal worden. Tel uit je verlies. Toch worden beheerders vaak vergeten is mijn ervaring.

Dat betekent overigens niet dat je altijd iedereen tevreden moet houden. Je zult af en toe keuzes moeten maken.

@ PaVaKe, Reza : Sommige dingen moet je vooral niet aan managers overlaten. Recept voor ellende.

@Jan

Ik weet niet of het een typefout is of woordspeling maar 'requiremens' is wel een mooie;-)

Brombeer,
Veel zaken hieromtrent moeten in het haalbaarheidsonderzoek (fase-0) en verder in de Business Case uitgewerkt zijn. Misschien niet tot op het niveau dat een requirementsconsultant dit moet doen maar wel tot zover dat hij/zij zijn/haar werk lekker kan verrichten.
Als de requirementsconsultant erachter komt dat de verwachtingen van de stalkeholders een showstopper vormen voor het project terwijl het project een GO heeft gekregen dan is de kans zeer groot dat het project gaat mislukken.

Naar mijn mening, Nicole schiet hierboven als een requirementsconsultant in deze zaak te veel door. De zaken rondom stakeholders worden op wat hogere niveau gespeeld dan waar een requirementsconsultant zit.

Ik zeg niet dat projectmanager deze zaak gaat uitwerken maar wel dat hij het voorwerk moet doen zodat de requirementsconsultant verder haar/zijn werk kan doen.

Het is een bekend feit dat business analisten, requirements engineers en andere functionarissen die met de verkrijging van eisen en wensen (voor het bouwen van de brug tussen business en informatiesystemen) zijn belast veel en veel beter op de hoogte zijn van inhoud en aanverwant detail dan projectmanagers. Een manager managet, zie zijn functienaam. Hij bewaakt de grote lijn, werkt samen met en FACILITEERT de BA of requirements engineer. Uiteraard kan hij van inhoud en aanverwante details op de hoogte zijn maar als je een BA of Requirements engineer inhuurt, denk dan goed na waarvoor. In het proces ter verkrijging van de juiste requirements is het de RE die inhoudelijk met de stakeholders werkt, is het de RE die als eerste de obstakels tegenkomt en is het de RE die als eerste de taak heeft eventuele tegengestelde belangen te synchroniseren. Moet de RE dan bij elk obstakel aan de bel trekken bij de PM? Je kunt geen gedragen requirements genereren als je tegengestelde belangen niet oplost. Als het de RE in een bepaalde situatie niet lukt het conflict opgehelderd te krijgen, kan deze altjd nog samen met de PM hiernaar kijken. En een oplossing genereren voor een bepaald conflict kan een heel leuk en energiegevend proces zijn. Zo had ik zelf recent te maken met verschillen van inzicht over de oplossing voor de gang van zaken van een bepaalde berekening. ACHT verschillende stakeholders en meningen. En ik zat daar tussen met mijn relatief geringe kennis over dat specifeke onderwerp. Ik heb voorgesteld om met zijn allen bij elkaar te komen, eenieder zijn zegje te laten doen, pro's en contra's op tafel en te komen tot één oplossing die voor iedereen werkt. En ik heb maar één ding gedaan: modereren. Overigens onder de afspraak dat we de kamer zouden verlaten als we een 95% oplossing hadden bedacht. 3 uur later waren we klaar. Onderschat asjeblieft de de kennis en vaardigheid van een ervaren RE niet, die kan heel goed met minimaal contact met een PM samenwerken.

En nog een verzoekje. Laten we niet over elk woordje gaan lopen steggelen wat het precies betekent en wat google erover zegt. Ga er gewoon vanuit dat het artikel juist is. Iemand die niet heel deskundig i s wordt geen Computable-expert.

@Wilco ... ik mis in je betoog een rol, namelijk van programma manager (roadmap manager of hoe je die rol ook zou willen benoemen).

Kernvraag is denk ik waar de rol van requirement analist in de organisatie gepositioneerd is. Is de analist degene die de requirements in kaart brengt, en (eventueel samen met de programma manager) de roadmap vaststeld, of komt hij pas om de hoek kijken als de roadmap / programma al is vastgesteld, en gaat hij de vastgestelde requirements voor de eerstvolgende release van het product analyseren ...

Je hoort me niet zeggen dat het artikel onjuist is. Ik heb alleen een ander beeld bij de rol van requirement analist.

Overigens wil ik je graag even attenderen op een artikel wat ik onlangs geschreven heb, zie http://www.computable.nl/artikel/opinie/development/4799651/1277180/in-de-ict-bestaat-de-niet.html

Het steggelen zoals jij beschrijft ontstaat omdat hier gesproken wordt over "De requirement analist", een rol die, blijkens de diverse reacties, verschillend ingevuld / geïnterpreteerd wordt bij organisaties......

I rest my case

Zolang iemand zelf invulling mag geven aan zijn/haar profiel is de stelling:
"Iemand die niet heel deskundig i s wordt geen Computable-expert."
niet houdbaar.
Slechts uit de geleverde artikelen mag blijken of de aangegeven expertise ook aanwezig is. Dat is niet altijd het geval, maar meestal wel, gelukkig.

Wilco,

Ik begrijp dat 'requiremensen' moeite hebben met de dubbelzinnigheden die onze taal kent. We zijn daar trouwens niet de enige in en mijn vraag aan Nicole over hoe dit alles te vertalen bij uitbesteding (al dan niet naar het buitenland) is nog steeds onbeantwoord. Want juist in aan/uitbesteding veranderd de definitie van stakeholders namelijk nog weleens, denk dat Pa Va Ke dit met reactie ook duidelijk maakt.

Juridisch zijn er dan nog maar 2, hoewel er natuurlijk vaak eerst meerdere partijen meedingen naar de opdracht. Hoe denk je trouwens dat eisen, vereisten en wensen vanuit aanbieders perspectief ingevuld gaan worden bij een EMVI?

Nicole zal vast een expert in haar vakgebied zijn maar de loodgieter is dat ook en die moet je wel in duidelijk Nederlands uitleggen wat het probleem is. Zolang 'requiremensen' dus blijven vasthouden aan hun eigen waarheid door alles te buigen naar hun eigen referenties zie ik dus nog veel mistake-holders.

Misschien zegt acroniem FUBAR je iets want in de vertalingen van requirements bij een keten van verschillende (en tegengestelde) belangen gaat nog heel veel fout. En even voor de duidelijkheid ik ben een engineer die nog weleens vreemde 'patches' ziet, onmogelijke combinaties in hardware/software en vele andere kunstwerken.

P.S.
Om Computable-expert te worden hoef je alleen maar een account aan te maken en actief te publiceren of te reageren. Aangezien je de helft al gedaan hebt ben ik benieuwd naar een opinie van jouw.

@Ewout: Ook dit artikel en de reacties staan weer bol van anglosisme.

Afwijkende interpretaties hebben van de ware betekenissen van de woorden werkt erg verwarrend, zoals Ewout ook aangeeft.

Ook heb ik wel eens meegemaakt bij een klant, toen ik over afkortingen doorvroeg, ze niet eens wist waar ze er net voor heel wijs over liep te vergaderen. (En dat was dan niet een technische afkorting, maar een afkorting van binnen dat bedrijf)

Stakeholders, belangen, requirements en conflicten zijn er op allerlei niveau's. Het speelt voordat een ontwikkelproject wordt gestart en (op een gedetailleerder niveau) tijdens het project en het vaststelen van requirements. Zowel een programmamanager als een requirementsanalist (en anderen) hebben ermee te maken. Wilco heeft dat m.i. treffend beschrijven vanuit het oogpunt van een requirementsanlist.

Nicole,

Zoals ik jouw en Wilco's reacties lees (die van Willem negeer ik) gaat het in dit artikel dus om conflicten en stakeholders in fase-0 zoals Reza het noemde en ben ik nieuwsgierig naar de rol van 'Requiremensen' bij oplossen van conflicten tussen interne- en externe claimholders. Want aangezien verschillende onderzoeken laten zien dat 25% van de problemen met budget en planning nog steeds rechtstreeks voortkomen uit issues met de requirements is de opsteller ervan ook een stakeholder, al dan niet officieus.

Kijkend naar je 'grijze gebied' raakt dat een verschil in belangen omdat de opdrachtgever meestal juist een belang heeft bij de snelle time-to-market, het halen van de planning, extra functionaliteit en goede softwarekwaliteit. Opstellen van de requirements, bepalen van de stakeholders is dus ook aan tijd en budget gebonden omdat één vereiste nog onbenoemd blijft: KOSTENREDUCTIE. En dit is zeker bij uitbesteding een zwaarwegende factor:

http://dspace.ou.nl/bitstream/1820/4319/1/INF_20120619_Ridder.pdf

Als ik via JBF framewerk in een conclusie mag springen mis ik bij de definitie stakeholder dus vooral het begrip EIGENAARSCHAP omdat de gulden middenweg oplossingen nog vaak tot het omgekeerde leiden, guldens zijn weg en we worden afgescheept met een niet of slecht werkend systeem. Want uiteindelijk gaat het natuurlijk om het referentiekader, wat is het vertrekpunt van waaruit worden de stakeholders bepaald worden en de requirements opgesteld.

Sorry voor mijn botheid maar ik vind je antwoord te makkelijk want je schuift de drol ontwijkend over de tafel om geen vieze handen te krijgen, een 'Stappelaartje' dus;-)

Wat ik een beetje mis in het hele verhaal is dat onderdeel wat juist zo Cruciaal kan zijn in vrijwel ALLE IT trajecten,;

Het Managen van Stakeholders.

Het is kinnesinne, m.i. dan, hoe het al of niet bedoeld, benoemd, aangewezen, gebruikt, betermd 'Stakeholder' te moeten zien of benoemen. Als je het sec neemt zijn het gewoon belanghebbenden in 'een traject'.
Belanghebbenden die er al of geen belang bij hebben.

Nutteloze discussies
Waar komen nu de meeste discussies doorgaans uit voort? Mijn ervaring is daarin heel erg simpel. Je veronachtzaamt iets wat gewoon 'basaal projectmanagement' is namelijk 'Communicatie'. De initiator, welke rol die ook in 'de keten' vervult, die uitlegt aan de stakeholders hoe men iets noemt en bedoeld.

Dat voorkomt volgens mij de dicussie meteen al.

In het verlengde...
Aansluitend is het dan aan de initiator van project of programma, om de stakeholders bij te brengen, te managen, hoe IT in elkaar steekt, en waarom je op die manier met bepaalde zaken om zou moeten gaan. Je zult de stakeholders eerst moeten verduidelijken hoe IT zich gedraagt en waarom je op die manier met de materie om moet gaan, voor je verder gaat.

In deze fase van het verhaal ligt namelijk de oplossing van deze discussie. Als je namelijk in het traject toe staat, tegen alle conventie van IT in, dat mensen met 'changes' komen, welke deze ook zouden zijn, dan krijg je discussies als deze.

Leg de 'stakeholders' nu eerst eens in een seminar uit wat de basale do's en don'ts zijn van IT, dan ben je deze discussie op voorhand kwijt.

Nicole,
Spijtig dat je met dit kort antwoord/reactie terug bent gekomen. We zijn in dit artikel je Stakeholders, zo te zien ben je niet als een requirementconsultant in staat om naar je stakeholders te luisteren en in discussie te komen.

Ik vraag me verder af of je als requirementconsultant iest anders in je projecten meegemaakt hebt of niet! Ik zie dat je 10x artikelen op je naam staan en je schrijft nergens anders over behalve.......... ja hoor: requirements.

Het artikel suggereert dat stakeholders die niet op een lijn zitten uiteindelijk in een conflict situatie terechtkomen. Dat lijkt zwaar aangezet.

Het is een illusie dat stakeholders op een lijn zitten in een IT project, juist omdat iedere stakeholder zijn eigen belangen zal hebben. De vraag is dan ook of stakeholders wel op een lijn moeten zitten, dat lijkt mij namelijk niet. Je zult verschillende belangen afwegingen hebben en die moet de projectleider of programma manager maken. De eisen en wensen dienen integraal te worden opgesteld, of iedere eis of wens wordt gehonoreerd is de vraag en ook weer een besluit van de projectmanager of programma manager.

Het is juist de spanning tussen de stakeholders belangen waarin een project kan excelleren of mislukken, dat heeft niet veel met requirements te maken, meer met verwachtingsmanagement, wat kan een systeem wel en wat niet, daar moet vanaf het begin duidelijkheid in komen.

Sowieso is al dit soort problematiek met belanghebbenden typisch iets voor grote-bedrijven-ziektes omgevingen.

Als politieke spelletjes gaan meespelen, worden onmogelijke dingen opeens mogelijk en omgekeerd. De belanghebbenden zullen misschien nooit op een lijn zitten of komen.

Daar komt ook nog eens bij dat de klant zelf vaak niet weet wat hij precies wil.

Uiteindelijk wil je de handen op elkaar hebben voor een gevalideerde en goedgekeurde set systeem requirements zodat je de juiste functionaliteit bouwt om de business- en gebruikers requirements te realiseren.
Het is handig als je weet wie de belanghebbenden zijn, wie daarvan de dikste vinger in de pap heeft en langs welke route je de grootste kans op een succesvol requirementstraject hebt.
Vergeet niet dat requirements aan de vraagkant zitten. Juist de vraagkant moet via die set requirements controle houden op wat er uiteindelijk wordt gebouwd. Diezelfde set vormt tevens de basis voor handleidingen, testcases en wijzigingsaanvragen.
Essentiële documentatie dus.

Expert
Nicole de Swart

Nicole de Swart
Requirements expert, Reaco Academy. Expert van voor het topic .
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×