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.
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.