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.
@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 https://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.