Incepta@IT B.V. IT-Consultant Projectmanagement. Consultancy in Almere

Categorie: Projectmanagement tools

  • Stakeholdermanagement voor IT-projectmanagers: belangen in kaart, risico’s onder controle

    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.

    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.

    Cirkelvormig schema met de organisatie centraal en stakeholdergroepen (eindgebruikers, leveranciers, directie, security-officer, etc.) als knooppunten eromheen met onderlinge relaties.

    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.

    Vier kwadranten met invloed (verticaal) en betrokkenheid (horizontaal), met per kwadrant de bijbehorende strategie. Maakt de prioriteringslogica direct visueel.

    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.

    Bowtie-diagram waarbij stakeholdergroepen expliciet zijn gelinkt aan oorzaken (links) en beheersmaatregelen (rechts). Verbindt de twee methoden visueel.

    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.

    Visueel stappenplan stakeholdermanagement. Geschikt als snelle samenvatting en deelbare afbeelding op social media.

    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.

  • Architectuur in IT-projecten – Jouw beste vriend als Projectmanager

    Bouw je project op een solide fundament, niet op drijfzand!

    Stel je eens het volgende voor: je bent een projectmanager en je krijgt de opdracht om een nieuw IT-systeem te realiseren. Het budget is vastgesteld, de deadline is duidelijk en het team staat te trappelen om aan de slag te gaan. Met volle overtuiging ga je aan de slag. Maar halverwege het project beginnen de problemen zich aan te dienen. De teams hebben moeite om elkaar te begrijpen, systemen sluiten niet goed op elkaar aan, en wat in het begin “een snelle oplossing” leek, kost helaas nu drie keer zoveel tijd om te repareren.

    Komt je dit bekend voor? Dit is precies wat er gebeurt als IT-architectuur wordt overgeslagen of als een bijzaak wordt beschouwd. En dat is een gemiste kans, want een goede IT-architectuur is niet je vijand, maar het is jouw beste troef.

    Projectmanager en IT-architect bekijken architectuurtekening samen
    Afbeelding gegenereerd met GPT Image 2

    Architectuur: meer dan tekeningen op een whiteboard

    Veel projectmanagers zien architectuur vaak als een verzameling abstracte tekeningen vol blokken en pijlen. “Leuk voor de techneuten, maar hoe helpt het mij?” Meer dan je zou denken. Architectuur draait om de cruciale keuzes die het verschil maken tussen een systeem dat stevig staat — of eentje dat bezwijkt onder zijn eigen gewicht.

    Het zorgt voor structuur, draagt bij aan samenhang en maakt systemen klaar voor de toekomst. Het is het onderscheid tussen software die over vijf jaar nog steeds aanpasbaar is, en software die niemand meer durft aan te raken.

    Om het iets tastbaarder te maken: er zijn twee termen die voor jou als projectmanager echt waardevol kunnen zijn: Architecture Building Blocks (ABB’s) en Solution Building Blocks (SBB’s).

    Building Blocks: de LEGO van jouw IT-project

    Zie het zo: een architect werkt met bouwstenen.

    Architecture Building Blocks (ABB’s)

    Dit zijn de conceptuele bouwstenen — de afspraken, patronen en standaarden die bepalen hóé het systeem in elkaar moet zitten. Denk aan: “We communiceren via API’s volgens REST-standaard” of “Alle data wordt versleuteld opgeslagen.” Dit zijn de regels van het spel, voordat er ook maar één regel code is geschreven.

    Solution Building Blocks (SBB’s) 

    Dit zijn de concrete invulling daarvan. Dit zijn de daadwerkelijke componenten, producten of diensten die worden ingezet om de architectuur te realiseren. Denk aan een specifieke clouddienst, een gekozen database-platform of een authenticatiemodule.

    Architecture Building Blocks en Solution Building Blocks als fundament van IT-project
    Afbeelding gegenereerd met GPT Image 2

    Waarom zijn deze bouwstenen goud waard voor jou als PM?

    Het antwoord is simpel: voorspelbaarheid en controle.

    Wanneer een architect vooraf heldere ABB’s en SBB’s definieert, weet jij als projectmanager:

    • Welke technische keuzes al gemaakt zijn (en dus geen discussie meer zijn)
    • Welke componenten hergebruikt kunnen worden (= tijdwinst en kostenbesparing)
    • Waar de risico’s zitten voordat ze jou verrassen in de testfase
    • Hoe teams op elkaar aansluiten zonder dat ze langs elkaar heen werken

    Niets tast een planning en budget zo snel aan als een fundamentele fout die pas laat in het project ontdekt wordt. Building blocks helpen dat te voorkomen.

    Minder verrassingen, meer grip

    Als projectmanager ben je eindverantwoordelijk voor Tijd, Geld en Kwaliteit. De architect is degene die jou op al drie vlakken ondersteunt, als je hem of haar vroeg genoeg betrekt bij het project.

    Een concreet voorbeeld: stel dat een stakeholder halverwege het project vraagt om een ingrijpende wijziging. Zonder architectureel inzicht sta je als PM met lege handen in dat gesprek. Mét een architect die de impact direct kan vertalen naar businesswaarde, die zegt “deze wijziging raakt de volgende drie SBB’s en verdubbelt de integratie-inspanning”, heb jij de onderbouwing om een professioneel gesprek te voeren over scope en budget.

    De architect is zo jouw vroegtijdige waarschuwingssysteem: van beveiligingsvraagstukken (denk aan AVG/GDPR-compliance) tot prestatieproblemen en afhankelijkheden tussen systemen.

    En het eindproduct? Daar plukken gebruikers de vruchten van

    Goede architectuur is uiteindelijk ook zichtbaar in het eindproduct, al is het misschien indirect. Een systeem gebouwd op solide ABB’s en SBB’s:

    • Schaalt mee als het aantal gebruikers groeit
    • Integreert soepel met andere systemen
    • Is veiliger omdat security by design is ingebakken
    • Is onderhoudbaar zodat toekomstige wensen snel én betaalbaar te realiseren zijn

    Samengevat: het eindproduct is niet alleen vandaag goed. Het blijft goed.

    Conclusie: omarm de architect, omarm de bouwstenen

    Architectuur is voor een IT-project wat een blauwdruk is voor een wolkenkrabber. Je kunt beginnen met stenen stapelen zonder tekening, maar de kans dat het gebouw instort voordat je de bovenste verdieping bereikt, is groot.

    Als projectmanager hoef je geen architect te worden. Maar begrijp de waarde van wat ze bieden. Betrek ze vroeg in het proces, maak architectuurrichtlijnen een integraal onderdeel van je Definition of Done, en gebruik de bouwstenen als een gemeenschappelijke taal tussen de business en de techniek.

    Solide IT-architectuur als fundering voor succesvol projectmanagement
    Afbeelding gegenereerd met GPT Image 2

    Want architectuur is geen vertraging. Het is een investering in snelheid, kwaliteit en controle, zowel voor jou, voor je team, als voor je eindgebruiker.

    Herken jij de uitdagingen uit dit blog? Of ben je benieuwd hoe je architectuur beter kunt integreren in jouw projectaanpak? Neem contact met ons op!

  • De IT-Consultant als professionele tolk: waarom communicatie IT-projecten maakt of breekt

    Stel je voor: je bent op vakantie in een land waar je de taal niet goed spreekt. Je hebt een allergie en probeert dat uit te leggen in een restaurant. De ober knikt vriendelijk en serveert precies het gerecht dat je niet kunt eten. In IT-projecten is dit een alledaags scenario, alleen heet de ober hier ‘de developer’ en ben jij ‘de business’. Wat heeft dit te maken met de IT-Consultant? Hoe kan hij helpen bij miscommunicatie in projecten?

    Het grootste probleem in IT-projecten is zelden de techniek. Er zijn genoeg vakmensen die complexe code schrijven of ingewikkelde netwerken ontwerpen. Het echte struikelblok is communicatie, en dat is precies waar een goede IT-Consultant het verschil maakt.

    IT-consultant als professionele tolk tussen business en IT

    Twee talen, één doel

    De business spreekt de taal van resultaten, ROI, klantervaring en deadlines. De IT-afdeling spreekt de taal van API’s, microservices, technical debt en schaalbaarheid.

    Wanneer de business vraagt om “een simpele knop waarmee klanten hun bestelling kunnen inzien”, hoort IT: “We moeten een beveiligde koppeling maken tussen de front-end en de legacy database, rekening houdend met de AVG-wetgeving en de load-balancer.”

    Zonder iemand die dat vertaalt, eindigt het op één van twee manieren: IT bouwt iets technisch solide dat totaal niet aansluit bij wat de klant wilde, of de business verwacht iets wat technisch niet haalbaar is binnen het beschikbare budget. Beide scenario’s zijn kostbaar, en naarmate een project langer loopt, worden ze dat meer.

    De IT-consultant als brug tussen Business en IT

    Een goede IT-consultant doet meer dan alleen een rapport scDe consultant als brug

    Een goede IT-consultant doet meer dan een rapport schrijven. De kern van de rol is de “waarom-vraag” van de business vertalen naar de “hoe-vraag” voor de techniek, en andersom.

    Dat vraagt drie concrete vaardigheden. Een consultant legt aan de directie uit dat ‘refactoring’ geen tijdverspilling is, maar noodzakelijk onderhoud om systemen stabiel te houden. Dezelfde consultant verduidelijkt aan de developers dat die “kleine aanpassing” directe invloed heeft op de kwartaalcijfers van de klant. En boven alles stelt de consultant de vragen waarmee ruis verdwijnt en het werkelijke probleem boven tafel komt.

    Wat dit onderscheidt van een gewone adviesopdracht is domeinbreedte. De consultant moet zowel bedrijfsprocessen als technische architectuur begrijpen, slechts één van de twee kennen is niet voldoende.

    Herken je de signalen?

    Als het misgaat, is het patroon herkenbaar. Projecten lopen vertraging op met als verklaring “de requirements waren niet duidelijk”. Opgeleverde functionaliteit wijkt af van wat besteld was. Business en IT spreken over hetzelfde project maar bedoelen iets anders. Vergaderingen eindigen zonder concrete besluiten of heldere vervolgstappen.

    Dat patroon lost zichzelf niet op.

    De consultant-encyclopedie: wat gezegd vs. wat bedoeld wordt

    Wie de brugfunctie wil begrijpen, moet de taal van de consultant zelf lezen. Die heeft zijn eigen woordenschat, soms zegt de consultant heel handig iets voor een professionele uitstraling, en soms gebruikt hij een manier om de harde waarheid te verzachten.

    Wat de consultant zegtWat er eigenlijk bedoeld wordt
    “Laten we dit even parkeren.”“Dit is een slecht idee en ik hoop dat je het morgen vergeten bent.”
    “We zoeken naar het laaghangende fruit.”“We doen eerst de makkelijke dingen zodat het lijkt alsof we snel resultaat boeken.”
    “Laten we hier een deep dive op doen.”“Ik weet het antwoord ook niet, dus we gaan er lang over vergaderen.”
    “We moeten de stakeholders managen.”“We moeten de mensen die dit project willen torpederen overtuigen tot ze ja zeggen.”
    “We werken volgens de Agile-methode.”“We hebben nog geen vastomlijnd plan en kijken per week wat we doen.”
    “Laten we dit offline bespreken.”“Stop met praten in deze vergadering, we zijn te laat voor de lunch.”
    “Er is sprake van een steile leercurve.”“Het is een chaos en niemand begrijpt hoe de software werkt.”
    “We moeten kijken naar de stip op de horizon.”“De details van nu zijn een drama — laten we dromen over een vage toekomst.”
    “Out-of-the-box denken.”“Ik heb een onrealistisch idee dat waarschijnlijk veel te duur is.”
    “We zoeken naar synergie.”“We voegen twee afdelingen samen die elkaar niet uitstaan in de hoop dat het goedkoper wordt.”
    “Best practice.”“Iedereen doet het zo — als het mislukt kunnen wij er niets aan doen.”
    “Het is een schaalbare oplossing.”“Op mijn laptop werkt het, maar ik weet niet wat er gebeurt als 1000 mensen tegelijk inloggen.”

    Wat het concreet oplevert

    Miscommunicatie is een van de grootste kostenposten in IT-projecten. Uit het Standish Group CHAOS Report (2020) blijkt dat slechts 31% van de IT-projecten volledig slaagt — op tijd, binnen budget en met de afgesproken functionaliteit. De helft eindigt als ‘challenged’ project: te laat opgeleverd, het budget overschreden of de scope aangepast. Gebrekkige communicatie en te weinig stakeholderbetrokkenheid zijn daarin structureel de meest voorkomende oorzaken.

    Een IT-consultant die de taal van beide werelden beheerst, heeft direct effect op het projectresultaat.

    1. Kortere doorlooptijden — Iedereen begrijpt vanaf de start wat de bedoeling is.
    2. Hogere kwaliteit — De oplossing sluit daadwerkelijk aan op de bedrijfsprocessen.
    3. Minder escalaties — Geen “wij-tegen-zij” spanningsveld meer tussen business en IT.

    Spreek jij de juiste taal?

    IT-consultancy draait om mensen begrijpen en ambities vertalen naar werkende oplossingen. De volgende keer dat je een IT-project start: wie vertaalt er dan voor jou?

    Benieuwd hoe wij de vertaalslag maken voor jouw organisatie? Neem contact op voor een vrijblijvend gesprek.

  • Wendbaar projectmanagement in een veranderende omgeving: kies een methode als middel, niet als doel

    Veel IT-projecten beginnen met een keuze voor de methode. Agile, Scrum of PRINCE2, er wordt een aanpak gekozen, en die aanpak wordt vervolgens gevolgd. Tot het project vastloopt, niet omdat de techniek tekortschoot, maar omdat de methode niet paste bij wat het project werkelijk nodig had.

    Dat is een patroon dat ik regelmatig terugzie bij projectmanagement. Een organisatie wil snel kunnen inspelen op verandering, maar kiest voor een zwaar governance-framework dat elke beslissing vertraagt. Of een team werkt in sprints, terwijl externe afhankelijkheden en vaste contractmomenten een iteratieve werkwijze feitelijk onmogelijk maken. De methode wordt leidend, het projectresultaat wordt bijzaak.

    Overzicht van projectmanagement methoden Agile, Scrum en PRINCE2 naast elkaar.
    Afbeelding gegenereerd met Nano Banana2

    Elke methode lost een ander probleem op

    Agile, Scrum en PRINCE2 zijn geen concurrerende aanpakken — ze zijn ontworpen voor verschillende situaties.

    PRINCE2 biedt structuur, heldere rollen en expliciete beslismomenten. Dat is waardevol bij projecten met veel bestuurlijke lagen, vaste budgetten en formele verantwoording. Denk aan infrastructuurmigraties of overheidsprojecten waarbij elke fase goedkeuring vereist van meerdere stakeholders.

    Agile is ontworpen voor situaties waarin eisen nog niet volledig bekend zijn en aanpassingen verwacht worden. Productontwikkeling waarbij de eindgebruiker gedurende het traject actief meedenkt, is daarvoor een voor de hand liggend voorbeeld.

    Scrum als specifieke invulling van Agile werkt het best in teams die zelforganiserend zijn en waarbij de doorlooptijd van feedbackloops kort is. Dat veronderstelt een bepaalde volwassenheid in het team en minimale externe afhankelijkheden.

    Het probleem ontstaat wanneer een aanpak wordt gekozen op basis van voorkeur of gewoonte, in plaats van op basis van de kenmerken van het project.

    Visuele tabel met Agile, Scrum en PRINCE2 op de assen: stabiliteit van eisen, beslissnelheid, type afhankelijkheden. Maakt de methodekeuze direct inzichtelijk.

    Wat de keuze voor een methode bepaalt

    Een aantal vragen helpt om de juiste aanpak te bepalen:

    Zijn de eisen stabiel of juist veranderlijk? Als de scope van een project bij de start grotendeels vaststaat, biedt een meer plangedreven aanpak houvast. Zijn de eisen nog onzeker of zullen ze gedurende het project verschuiven, dan vraagt dat om kortere cycli en frequentere afstemming.

    Wie heeft beslissingsbevoegdheid en hoe snel? Een organisatie met trage besluitvorming en meerdere bestuurlijke lagen werkt slecht met een aanpak die dagelijkse of wekelijkse sturing vereist. Scrum veronderstelt dat een product owner daadwerkelijk kan beslissen, dat is lang niet altijd het geval.

    Wat is de aard van de afhankelijkheden? Externe leveranciers, vaste contractmomenten en gekoppelde systemen beperken de speelruimte van een iteratieve aanpak. Een mixed-methods aanpak, waarbij de buitenste projectlaag plangedreven is en interne deeltrajecten iteratief, is in die gevallen vaak realistischer.

    Hoe volwassen is het team? Agile werken vraagt zelfsturing en intrinsieke verantwoordelijkheid. In teams waar dat nog niet aanwezig is, leidt een Agile aanpak niet tot snelheid maar tot onduidelijkheid.

    Methoden combineren in de praktijk

    In IT-projecten waarbij ik als consultant betrokken ben, is een hybride aanpak vaak de realiteit. De projectfasering en governance volgen een plangedreven structuur: heldere mijlpalen, vaste rapportages, expliciete go/no-go-momenten. Binnen die kaders werken de uitvoerende teams iteratief, met korte sprints en regelmatige afstemming met gebruikers.

    Dat vraagt om bewuste keuzes per projectlaag. Welk deel van het project heeft structuur en voorspelbaarheid nodig? Welk deel heeft juist ruimte voor aanpassing? Die vragen staan los van methodieken — ze gaan over de aard van het werk.

    De valkuil is dat hybride aanpakken vrijblijvend worden. “We doen iets van Agile en iets van PRINCE2” is geen keuze, het is het vermijden van een keuze. Een bewuste hybride aanpak vraagt om expliciete afspraken over welke principes gelden op welk niveau, wie welke beslissingen neemt en hoe de verbinding tussen de lagen wordt geborgd.

    Diagram met een buitenste plangedreven projectlaag en binnenste iteratieve uitvoeringslag. Visualiseert het hybride model concreet.

    De projectmanager als methode-onafhankelijke professional

    Een goede projectmanager is niet iemand die één methode uitstekend beheerst. Het is iemand die de kenmerken van een project kan lezen en op basis daarvan een aanpak kiest die past.

    Dat vraagt kennis van meerdere methoden, maar meer nog het vermogen om de organisatorische en menselijke context te beoordelen. Een project dat technisch gezien geschikt is voor Scrum, maar waarbij de opdrachtgever elke sprint goedkeuring wil verlenen op de backlog, werkt in de praktijk niet als Scrum. De formele aanpak aanpassen aan die realiteit is geen zwakte — het is professioneel oordeel.

    Wat dit betekent voor je aanpak

    Niet iedere situatie is gelijk, maar een aantal uitgangspunten helpt om methodekeuzes te verankeren in de praktijk.

    Beoordeel het project, niet de voorkeur. Kies de aanpak op basis van de stabiliteit van eisen, de beslisstructuur en de aard van de afhankelijkheden — niet op basis van wat je gewend bent of wat de organisatie eerder heeft gebruikt.

    Maak hybride afspraken expliciet. Als je methoden combineert, leg dan vast welke principes gelden op welk niveau. Onduidelijkheid hierover leidt tot conflicterende verwachtingen tussen teams en opdrachtgevers.

    Toets de aanpak regelmatig. Een methode die aan het begin van een project passend was, hoeft dat halverwege niet meer te zijn. Bouw evaluatiemomenten in om de aanpak zo nodig bij te stellen.

    Betrek stakeholders vroeg bij de methodekeuze. Een aanpak die intern logisch lijkt, maar niet aansluit bij de verwachtingen van de opdrachtgever of eindgebruikers, creëert frictie die het project vertraagt. Vroegtijdige afstemming voorkomt dat.

    Methode volgt project, niet andersom

    IT-projecten falen zelden door het kiezen van de verkeerde methode op papier. Ze falen doordat de methode niet is afgestemd op de werkelijkheid van het project: de organisatiestructuur, de beslissnelheid, de aard van de samenwerking en de mate van onzekerheid.

    Flexibiliteit in methodekeuze is geen gebrek aan discipline. Het is het gevolg van een heldere analyse van wat een project nodig heeft. Die analyse is de eerste verantwoordelijkheid van een projectmanager — voordat er ook maar één sprint gepland of één projectplan geschreven is.

    Wil je sparren over welke aanpak past bij jouw IT-project of organisatie? Neem contact op, ik denk graag met je mee.

  • Bowtie risicomanagement: helder inzicht in risico’s, in één oogopslag

    Veel risicoanalyses eindigen als een document dat na één lezing in een la verdwijnt. De bowtie methode werkt anders: één schema dat oorzaken, maatregelen en gevolgen tegelijk in beeld brengt en dat is iets dat iedereen in de kamer begrijpt, ook buiten de risicomanagementafdeling of werkgroep.

    Dat verklaart waarom de methode in zoveel sectoren opduikt: van veiligheidsmanagement en operationeel risicomanagement tot IT-projecten en compliance-vraagstukken.

    Wat is bowtie risicomanagement?

    Bowtie risicomanagement is een methode om risico’s visueel weer te geven. Het model heeft de vorm van een vlinderdas, vandaar de naam bowtie.

    In het midden staat de centrale gebeurtenis: het moment waarop het risico werkelijkheid wordt. Links staan de dreigingen of oorzaken die daartoe kunnen leiden. Rechts staan de mogelijke gevolgen.

    Daartussen komen de beheersmaatregelen: preventieve maatregelen aan de linkerkant voorkomen dat het misgaat, mitigerende maatregelen aan de rechterkant beperken de schade als het toch gebeurt.

    Zo zie je in één schema het risico zelf, welke barrières de organisatie heeft ingericht én waar die barrières ontbreken.

    Herkomst van de bowtie methode

    De methode heeft haar wortels in de olie- en gasindustrie. Shell ontwikkelde de aanpak in de jaren negentig als hulpmiddel voor het beheersen van procesrisico’s in gevaarlijke omgevingen. Het Energy Institute (Londen) formaliseerde de methode later en publiceerde in 2008 de eerste uitgebreide richtlijn: Bowtie methodology: A Guide to Best Practice. Sindsdien is de methode overgenomen in uiteenlopende sectoren, van luchtvaart en chemie tot gezondheidszorg en IT.

    Hoe werkt een bowtie-analyse?

    Concreet voorbeeld met een cyberrisico als centrale gebeurtenis (bijv. datalek), dreigingen zoals phishing en zwak wachtwoord, en maatregelen zoals MFA en encryptie. Maakt de methode direct toepasbaar voor de IT-doelgroep.

    Een bowtie-analyse brengt een risico in zes stappen in kaart:

    1. Kies een risico of scenario — bepaal welk risico je wilt analyseren.
    2. Benoem de centrale gebeurtenis — het moment waarop het misgaat.
    3. Inventariseer de dreigingen — welke oorzaken kunnen tot die gebeurtenis leiden?
    4. Breng preventieve maatregelen in kaart — wat voorkomt dat het gebeurt?
    5. Beschrijf de gevolgen — wat is de impact als het toch misgaat?
    6. Benoem mitigerende maatregelen — wat beperkt de schade?

    Zo brengt bowtie risicomanagement in één schema in

    Waarom kiezen organisaties voor de bowtie methode?

    De bowtie methode combineert eenvoud met diepgang. Begrijpelijk voor een breed publiek, sterk genoeg voor complexe risico’s.

    Veel risicoanalyses bestaan uit uitgebreide tabellen of lange documenten die niemand meer openslaat. Een bowtie maakt direct zichtbaar hoe oorzaken, maatregelen en gevolgen samenhangen, in één overzichtelijk schema, zonder dat je tien pagina’s hoeft door te spitten.

    De methode verandert ook hoe teams over risico’s praten. In plaats van gevaren opnoemen, stel je de vraag of bestaande maatregelen echt voldoende zijn. Dat levert andere gesprekken op dan een spreadsheet met RAG-statussen.

    Zwakke plekken zijn snel zichtbaar: waar ontbreken maatregelen, waar staat er maar één barrière tussen dreiging en gevolg? En omdat het schema visueel is, werkt het in presentaties, audits en trainingen, ook voor mensen zonder een Risicomanagement achtergrond.

    Wanneer gebruik je bowtie risicomanagement?

    Bowtie risicomanagement is breed toepasbaar: veiligheidsrisico’s, operationele risico’s, technische storingen, cyberrisico’s, kwaliteitsrisico’s, compliance-vraagstukken en projectrisico’s. De methode is het meest waardevol bij scenario’s met grote impact — waarbij veiligheid, continuïteit of reputatie op het spel staat.

    Iconen of visueel overzicht van de zeven toepassingsgebieden (veiligheid, IT, kwaliteit, compliance, etc.). Maakt de breedte van de methode in één oogopslag duidelijk.

    Een voorbeeld uit de praktijk: voor een opdrachtgever met een besloten netwerkomgeving voerden we een bowtie-analyse uit rondom netwerkuitval. De centrale gebeurtenis: het netwerk valt uit. Links in het schema kwamen de dreigingen in beeld, dit ging van technische storingen tot ontbrekende of onvoldoende procedures en richtlijnen, waardoor medewerkers bij uitval niet weten hoe te handelen.

    Rechts stonden de gevolgen. De operationele impact was direct duidelijk, maar wat de analyse ook blootlegde: bij uitval zonder heldere externe communicatie kan reputatieschade ontstaan. Klanten die niet tijdig worden geïnformeerd, trekken dan hun eigen conclusies. Dat risico was vooraf niet als zodanig benoemd.

    De mitigerende maatregelen aan de rechterkant van de bowtie richtten zich daarom op twee sporen: technisch herstel én communicatie. Een communicatieprotocol, wie informeert wie, wanneer en met welke boodschap, werd als expliciete maatregel opgenomen naast de technische herstelstappen.

    Voordelen van bowtie risicomanagement

    De voordelen van bowtie risicomanagement zijn het grootst voor organisaties die risico’s actief willen beheersen, niet alleen registreren.

    Een bowtie brengt een risico compact in beeld en toont direct welke barrières aanwezig zijn — en welke ontbreken. Daardoor wordt het stellen van prioriteiten concreter: je ziet niet alleen waar het goed zit, maar ook waar het dun is. Risico’s worden bespreekbaar buiten de bijvoorbeeld de risicoanalyse werkgroep, omdat het schema geen specialistische kennis vereist om te lezen. En de methode werkt even goed voor analyse als voor communicatie, training en evaluatie.

    Aandachtspunten bij een bowtie-analyse

    De bowtie methode oogt eenvoudig, maar de kwaliteit staat of valt met de inhoud. Een goede analyse vraagt om scherpe keuzes en realistische inzichten.

    Formuleer de centrale gebeurtenis helder en benoem dreigingen zo concreet mogelijk. Controleer of maatregelen echt effectief zijn, maak onderscheid tussen preventieve en mitigerende maatregelen en leg verantwoordelijkheden duidelijk vast.

    Een bowtie is daarmee geen mooi schema om te bewaren, het wordt daarmee echt een werkinstrument.

    Bowtie als continu hulpmiddel

    De methode stopt niet bij de analyse. Organisaties die er het meeste uithalen, gebruiken een bowtie als terugkerend referentiekader, ze gebruiken het als basis voor audits, verbeteracties, incidentevaluaties en periodieke reviews van beheersmaatregelen. In projecten werkt het ook goed als gedeeld risicoschema voor het hele team.

    Afsluitend

    Bowtie risicomanagement brengt dreigingen, maatregelen en gevolgen samen in één model. Het geeft snel overzicht, maakt risico’s bespreekbaar en laat zien waar de organisatie staat, zowel op papier als in de praktijk.

    Wil je risico’s duidelijker in beeld brengen? Dan is de bowtie methode een goed startpunt. 

    Heeft jouw organisatie hulp nodig bij het opzetten van een risicoanalyse? Wil je graag zien hoe dit in de praktijk werkt? Neem contact met ons op!