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