Incepta@IT Projectmanagement

Tag: Technical Debt

  • Technical debt: wat je nu laat liggen, betaal je later!

    Technical debt: wat je nu laat liggen, betaal je later!

    Technical debt zorgt ervoor dat je altijd later de rekening betaald

    Technical debt: wat je nu laat liggen, betaal je later!

    Een snelle oplossing die vandaag tijd bespaart, betaalt zich later terug met rente. Dat is technical debt. Het is de technische schuld die je opbouwt zodra je kiest voor wat op dat moment uitkomt in plaats van voor wat het probleem echt oplost. De rekening komt later, en meestal hoger dan de besparing van toen.

    Voor een projectmanager die geen architect is, klinkt technical debt al gauw als een probleem voor de techneuten. Dat is het niet. Het raakt precies waar jij verantwoordelijk voor bent, namelijk tijd, budget en kwaliteit. Wat het is, hoe je het uitlegt aan een opdrachtgever en wanneer je die schuld beter wél of juist níet aangaat, lees je hieronder.

    Wat technical debt is

    Technical debt is het verschil tussen de snelle oplossing en de goede oplossing. Kies je voor de snelle, dan leen je in feite tijd van de toekomst. Zolang de schuld openstaat, betaal je rente: elke wijziging kost meer moeite, elke koppeling wordt lastiger, en op een gegeven moment durft niemand het systeem nog aan te raken.

    Net als een financiële lening is technical debt niet per definitie fout. Een lening kan een verstandige zet zijn, mits je weet dat je hem aangaat en een plan hebt om hem af te lossen. Het gevaar zit in de schuld die je opbouwt zonder het door te hebben, waar niemand meer zicht op heeft.

    Hoe je het uitlegt aan een niet-technische opdrachtgever

    Vergelijk het met onderhoud aan een auto. Je kunt de olie nu niet verversen en versleten banden laten zitten. Dat scheelt vandaag geld. Maar loopt de motor vast of krijg je een ongeluk door die banden, dan ben je veel meer kwijt dan de onderhoudsbeurt ooit had gekost.

    Uitgesteld onderhoud in IT werkt hetzelfde. De besparing van nu is zichtbaar en concreet, de rekening later is groter maar nog onzichtbaar. Jouw taak in dat gesprek is die latere rekening zichtbaar maken vóórdat de opdrachtgever alleen naar de besparing van vandaag kijkt.

    Een voorbeeld uit de praktijk

    In een project moesten op grote schaal accesspoints worden vervangen. Op bepaalde plekken werd niet het juiste type geïnstalleerd, omdat dat op dat moment sneller voor handen was en goedkoper leek. Het netwerk deed het, dus op papier was de klus klaar.

    Later bleek de dekking op die plekken niet te voldoen. De accesspoints moesten alsnog worden vervangen door het juiste type, met alle bijkomende werkzaamheden opnieuw. De besparing van de eerste ronde verdween volledig in de tweede. Dit is technical debt in het klein: een keuze die op het moment zelf logisch leek, maar dubbel werd betaald.

    Wanneer technical debt een verstandige keuze is

    Soms is een schuld aangaan de juiste beslissing. Wachten op de perfecte oplossing kan meer kosten dan een bewuste, tijdelijke keuze nu.

    • Een harde deadline of regelgeving. Moet je op een vaste datum voldoen aan een wettelijke eis, dan is een goede tijdelijke oplossing beter dan een perfecte die te laat komt.
    • Een bewuste, tijdelijke keuze. Je kent het volledige beeld, weet welke schuld je aangaat en legt vast wanneer en hoe je hem aflost.

    Wanneer het juist niet verstandig is

    De schuld wordt riskant zodra je hem aangaat zonder het overzicht, of op een plek waar de gevolgen niet te overzien zijn.

    • Een keuze uit onwetendheid. Je mist het volledige beeld, maar besluit toch. Dan neem je een schuld die je niet kunt inschatten en dus ook niet kunt beheersen.
    • Rond beveiliging. Bij securitymaatregelen zijn de gevolgen van een snelle keuze te groot. Hier hoort altijd een goed doordachte afweging, geen kortere weg.

    Grip houden op je technische schuld

    Het verschil tussen verstandige en onverstandige technical debt zit niet in de schuld zelf, maar in of je hem kent. Maak elke bewuste tijdelijke keuze zichtbaar, leg vast waarom je hem maakt en wanneer je hem aflost. Zo blijft het een instrument in plaats van een verrassing die halverwege het project de kop opsteekt.

    Speelt dit in een lopend of aankomend project? Bespreek waar jouw technische schuld zit en hoe je hem beheersbaar houdt.

    Plan een vrijblijvend gesprek

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

    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!