Projectmanagement in de IT verwijst naar het geheel van activiteiten die het mogelijk maken om een zakelijke behoefte om te zetten in een technisch leverbaar product, binnen een vooraf gedefinieerd kader van kosten, tijd en kwaliteit. Het aansturen van een IT-project binnen een bedrijf vereist beheersing van zowel de functionele scope, de technische afhankelijkheden als de coördinatie van de teams. Drie dimensies die, als ze slecht zijn afgestemd, voldoende zijn om een project te laten ontsporen nog voor de eerste regel code is geschreven.
Cybersecurity en NIS2-naleving: een projectrisico dat al bij de afbakening moet worden geïntegreerd
De meeste gidsen voor IT-projectmanagement behandelen risico’s vanuit het perspectief van het budget of de tijdlijn. De Europese richtlijn NIS2 voegt een directe regelgevende beperking toe: de betrokken organisaties moeten rekening houden met de beveiliging van hun leveranciers en dienstverleners, inclusief hun eigen kwetsbaarheden.
In de praktijk betekent dit dat een IT-project dat gebruikmaakt van een SaaS-leverancier, een host of een integrator deze afhankelijkheden moet in kaart brengen vanaf de fase van de afbakening. De beveiligingseisen worden dan opgenomen in de contracten, en de verificatie van de bewijsstukken van naleving wordt een mijlpaal van het project, geen eenmalige audit die achteraf wordt uitgevoerd.
De Franse tijdlijn voor de transpositie van NIS2 is nog niet volledig gestabiliseerd, maar de organisaties die mogelijk betrokken zijn, hebben er belang bij om vooruit te plannen. Het bepalen van de status van de entiteit, het documenteren van de risico’s en het testen van de detectie en melding van incidenten vormen een op zichzelf staande klus binnen het aansturen van een IT-project. Gespecialiseerde middelen maken het mogelijk om deze aansturingskwesties verder te verkennen: https://www.projets-informatiques.fr/ centraliseert onder andere ervaringen met het leiden van IT-projecten.
Een vaak onderschat punt: NIS2 kan worden gecombineerd met andere kaders zoals DORA of de Cyber Resilience Act. Eenzelfde incident kan dan leiden tot meerdere meldingen, met verschillende termijnen en criteria. Het project moet van tevoren definiëren wie het incident kwalificeert en wie beslist om te melden, om verwarring in de operatie op het slechtste moment te voorkomen.
Aansturing van de projectscope: de stille afwijking die het duurst is
De scope van een IT-project verwijst naar het geheel van functionaliteiten, leverbare producten en beperkingen die door alle belanghebbenden bij de start zijn geaccepteerd. Elke niet-geformaliseerde wijziging van deze scope vormt wat men noemt scope creep.
Scope creep manifesteert zich niet door een spectaculaire aanvraag. Het neemt de vorm aan van micro-toevoegingen: een extra veld in een formulier, een integratie met een derde partij “die maar twee dagen zal duren”, een rapport dat tijdens een voortgangsvergadering wordt gevraagd. Individueel lijkt elk onschuldig. Gecombineerd over meerdere maanden verschuiven ze de planning met enkele weken en mobiliseren ze niet-geplande middelen.
Formaliseren van het wijzigingsverzoekproces
Om deze afwijking te beheersen, moet elke wijziging van de scope door een expliciet proces gaan. Dit proces omvat drie concrete elementen:
- Een wijzigingsverzoek (change request) opgesteld door de aanvrager, waarin de behoefte, de geschatte impact op de planning en het budget, en de zakelijke rechtvaardiging worden beschreven.
- Een stuurgroep of een aangewezen verantwoordelijke die de aanvraag valideert of afwijst op basis van objectieve criteria, niet tijdens een informele discussie.
- Een update van het projectreferentiekader (planning, budget, functionele documentatie) bij elke geaccepteerde wijziging, zodat het team altijd op een actuele versie van de scope werkt.
Zonder dit mechanisme absorbeert de projectmanager de aanvragen bij default, en wijkt de werkelijke scope af van de contractuele scope. De traceerbaarheid van wijzigingen beschermt zowel het technische team als de opdrachtgever.
Communicatie tussen technische teams en zakelijke afdelingen: structureren van de uitwisselingen
Communicatie in een IT-project beperkt zich niet tot het versturen van een wekelijkse rapportage. Het terugkerende probleem ligt in de asymmetrie van de taal tussen de technische teams en de zakelijke belanghebbenden. Een ontwikkelaar spreekt over API’s, technische schuld en sprints. Een commercieel directeur wil weten of de functionaliteit beschikbaar zal zijn voor het volgende kwartaal.
Deze asymmetrie genereert twee soorten disfuncties. De eerste: de zakelijke teams valideren specificaties die ze niet hebben begrepen, wat leidt tot leverbare producten die voldoen aan het bestek maar onbruikbaar zijn. De tweede: de technische teams onderschatten het belang van een zakelijke behoefte omdat deze vaag is geformuleerd.
Synchronisatierituelen aangepast aan de context
De frequentie en het formaat van de uitwisselingen moeten variëren afhankelijk van de fase van het project. In de afbakeningsfase verminderen co-creatieworkshops met visuele hulpmiddelen (mock-ups, gebruikerspaden) misverstanden. In de uitvoeringsfase volstaat een korte dagelijkse of tweewekelijkse bijeenkomst tussen de projectmanager en de zakelijke referenten om afwijkingen te detecteren voordat ze blokkades worden.
Een gedeeld dashboard, in real-time bijgewerkt via een taakbeheertool, vervangt nuttig de lange rapportage-e-mails. Het doel is niet om het aantal vergaderingen te vermenigvuldigen, maar om de informatie toegankelijk te maken op het juiste detailniveau voor elke gesprekspartner.
Projectmanagementindicatoren voor IT-projecten: meten wat telt
Een project aansturen zonder indicatoren is als rijden zonder dashboard. Twee categorieën indicatoren verdienen het om parallel te worden gevolgd: voortgangsindicatoren en gezondheidsindicatoren.
Voortgangsindicatoren meten de vooruitgang ten opzichte van het plan: percentage voltooide taken, naleving van mijlpalen, budgetverbruik. Ze beantwoorden de vraag “zijn we op schema?”.
Gezondheidsindicatoren meten de kwaliteit van het proces zelf: aantal openstaande bugs, testdekking, gemiddelde tijd voor het oplossen van afwijkingen, deelnamepercentage aan communicatierituelen. Een project kan “op schema” zijn terwijl het een technische schuld opbouwt die zal exploderen na de productie.
- Het volgen van de snelheid (in agile methode) of van de geplande/werkelijke afwijking (in sequentiële methode) maakt het mogelijk om de middelen aan te passen voordat de vertraging onomkeerbaar wordt.
- Het aantal geaccepteerde wijzigingsverzoeken per sprint of per fase geeft een objectieve maat voor de stabiliteit van de scope.
- De beschikbaarheidsgraad van testomgevingen signaleert vaak onzichtbare technische knelpunten in de klassieke rapportages.
Het volgen van deze indicatoren vereist discipline, maar ook inzicht. Een dashboard dat overbeladen is met metrics verliest zijn waarschuwingsfunctie. Drie tot vijf goed gekozen indicatoren, herzien bij elke stuurgroep, bieden meer waarde dan twintig grafieken die niemand leest.
Het succes van een IT-project hangt minder af van de keuze voor een agile of sequentiële methode dan van het vermogen van het team om een stabiele scope te handhaven, leesbare uitwisselingen tussen zakelijke en technische teams te creëren, en indicatoren te hebben die actie ondernemen voordat er een crisis ontstaat. Regelgevende naleving, met name met NIS2, voegt nu een vierde dimensie toe die het projectmanagement niet langer aan de zijlijn kan behandelen.
