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

Categorie: IT-Architectuur

  • 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!

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