Elk IT-project heeft er last van. Een directeur die halverwege het project andere prioriteiten stelt. Een security-officer die pas in de laatste fase aanschuift. Een leverancier die belangrijke informatie achterhield. Dit gebeurt niet omdat mensen onwillig zijn, maar vaak omdat er geen gedeeld beeld was van wie welke rol speelt, wat er op het spel staat en welke risico’s er schuilen in de samenwerking met elkaar.
Stakeholdermanagement lost dat op, als je het maar serieus aanpakt.
Inhoudsopgave
Wie zijn jouw stakeholders eigenlijk?
In IT-projecten is de kaart van stakeholders vaak ingewikkelder dan in veel andere sectoren. Je hebt te maken met een combinatie van technische en niet-technische betrokkenen, elk met zijn eigen, belangen en verwachtingen. Bovendien begrijpen ze elkaar soms niet omdat het jargon wat ze gebruiken vaak heel verschillend is.
Je kunt als stakeholders denken aan eindgebruikers, applicatiebeheerders, enterprise architecten, security-officers, directie, inkopers en externe leveranciers. Het Freeman-model is een nuttig hulpmiddel om deze partijen overzichtelijk in kaart te brengen: de organisatie staat centraal, met daaromheen een netwerk van stakeholders met onderlinge relaties.
Wat IT-projecten uniek maakt, is dat stakeholders niet alleen belangen hebben bij het eindresultaat, maar ook actief invloed uitoefenen op het proces. Een enterprise architect die zich niet gehoord voelt, kan bijvoorbeeld besluiten blokkeren. Een leverancier die niet op tijd wordt betrokken, draagt oplossingen aan die niet passen binnen het bestaande applicatielandschap. Deze problemen hebben vaak gevolgen voor de doorlooptijd, kosten en kwaliteit van het project.
Prioriteren: wie verdient welke aandacht?
Niet elke stakeholder vraagt om dezelfde hoeveelheid tijd en moeite. De Mendelow-matrix biedt een handige structuur: stakeholders worden ingedeeld op basis van hun invloed én hun betrokkenheid bij het project.
- Hoge invloed, hoge betrokkenheid → Betrek ze actief bij het project en werk met ze samen,
- Hoge invloed, lage betrokkenheid → Informeer ze goed, want hun steun is noodzakelijk; we willen ze tevreden houden.
- Lage invloed, hoge betrokkenheid → Houd ze betrokken en geef informatie zo veel als nodig is.
- Lage invloed, lage betrokkenheid → Monitor ze en beschouw ze als actieve toeschouwers bij het project.
Deze indeling is alleen niet statisch. De positie van stakeholders kan verschuiven gedurende een project. Een eindgebruiker die in de beginfase weinig invloed lijkt te hebben, kan halverwege het project een belangrijke rol spelen bij de acceptatietest. Het is daarom belangrijk om je stakeholderkaart regelmatig bij te werken. Een goed ritme hiervoor is bijvoorbeeld na elke sprint review of aan het begin van een nieuw kwartaal.
De bowtie-methode risicoanalyse toepassen op je stakeholders
Waar stakeholdermanagement en risicomanagement samenkomen, wordt het boeiend. De bowtie-methode biedt een gestructureerde manier om per stakeholdergroep de aanwezige risico’s te analyseren.
De redenatie hier achter is simpel maar krachtig: stakeholders zijn niet alleen betrokkenen bij een project, ze zijn tegelijkertijd een potentieel een bron van risico’s, maar kunnen ook een risicobeheersing maatregel zijn.
Kijk naar de linkerkant van de bowtie: welke oorzaken kunnen leiden tot een ongewenste gebeurtenis? Denk aan een enterprise architect die niet tijdig wordt betrokken, een directeur die de projectscope informeel uitbreidt, of een leverancier die onvoldoende zicht heeft op de bestaande IT-architectuur. Dit zijn oorzaken die je kunt koppelen aan bepaalde stakeholdergroepen.
Aan de rechterkant van de analyse komt de vraag naar voren: als het toch misgaat, welke maatregelen kunnen dan de gevolgen beperken? Ook hier hebben stakeholders een actieve rol. Een goed geïnformeerde security-officer die vroeg in het project is aangehaakt, kan de kans op kostbare hersteltrajecten later aanzienlijk verkleinen. Een eindgebruiker die regelmatig meedenkt via sprint reviews, merkt afwijkingen sneller op dan een formele acceptatietest die pas aan het eind plaatsvindt
Door je stakeholderkaart te verbinden aan een bowtie-analyse, maak je de overstap van reactief naar proactief. Je krijgt niet alleen zicht op wie er bij het project betrokken is, maar ook waar de kwetsbaarheden zitten en welke stakeholders je als barrière kunt inzetten.
Hoe enterprise architectuur te gebruiken is
Een van de meest ondergewaardeerde hulpmiddelen in stakeholdermanagement is de bestaande enterprise architectuur. Veel IT-projectmanagers benutten architectuurdocumentatie voornamelijk intern. Dit is een gemiste kans.
De enterprise architectuur biedt een objectief en gedeeld referentiekader dat je kunt gebruiken bij conflicterende belangen. Wanneer een zakelijke stakeholder vraagt om een oplossing die indruist tegen de architectuurprincipes, maakt een visueel architectuuroverzicht het gesprek concreter dan abstracte argumenten over technische schuld of risico’s op de lange termijn.
Bovendien helpt datzelfde overzicht niet-technische stakeholders te begrijpen waarom bepaalde keuzes worden gemaakt. Dit vergroot het begrip tussen technische en niet-technische betrokkenen, wat vaak een bron van spanning is in IT-projecten.
Zet de enterprise architectuur actief in tijdens bijeenkomsten met stakeholders. Gebruik het niet alleen als een presentatie van feiten, maar als een onderwerp voor discussie. Vraag stakeholders hoe hun wensen passen binnen het bestaande landschap. Alleen die vraag al bevordert realisme en zorgt voor meer draagvlak.
Wat je direct kunt doen
Op basis van de combinatie van stakeholdermanagement, risicodenken en enterprise architectuur zijn er enkele praktische aanpakken die echt het verschil maken.
Breng je stakeholders goed in kaart; gebruik het Freeman-model om ook de minder voor de hand liggende betrokkenen te ontdekken. De leverancier die jij ziet als uitvoerder kan voor de directie wel eens een strategische partner zijn.
Koppel elke stakeholdergroep aan je bowtie; benoem duidelijk welke oorzaken en gevolgen bij welke stakeholders horen. Dit maakt je risicoanalyse concreet en je communicatie gericht.
Gebruik architectuurprincipes als ondersteuning; wanneer belangen botsen, helpt de enterprise architectuur om het gesprek terug te brengen naar onpartijdige uitgangspunten.
Combineer feedbackmomenten; een sprint review biedt je groepsfeedback, terwijl een kort één-op-één gesprek erna zorgt voor verdere verdieping. Deze combinatie geeft je een veel vollediger beeld dan wanneer je slechts één methode gebruikt.
Houd je stakeholderkaart actueel; een verouderd overzicht kan een vals gevoel van controle geven. Zorg ervoor dat je een vaste update plant in je projectritme.
Stakeholdermanagement als fundament, niet als bijzaak
IT-projecten falen zelden alleen door technische problemen. Vaak zijn het miscommunicatie, onduidelijke verwachtingen of het te laat betrekken van stakeholders die de oorzaak vormen.
Stakeholdermanagement is dan ook niet slechts een administratieve taak; het vormt de basis voor je projectbeslissingen, helpt risico’s te beheersen en draagt bij aan het creëren van draagvlak.
Door je stakeholderkaart te combineren met de bowtie-methode en de enterprise architectuur als gemeenschappelijke uitgangspunten te hanteren, ontwikkel je een strategie waarbij belangen en risico’s geen onverwachte complicaties meer zijn, maar beheersbare elementen.
Wil je sparren over hoe je stakeholdermanagement, risicoanalyse en enterprise architectuur samenkomt in jouw IT-project? Neem contact op, ik denk graag met je mee.
