Het plannen van een IT-project is de sleutel tot het voorkomen van ontsporingen (met name op het gebied van budget, deadlines en kwaliteit). Volg deze belangrijke stappen voor een goede start.

Een goede planning betekent niet “een schema maken”: het betekent uitlijnen belanghebbenden, definieer wat wordt geleverd, organiseren werk en master risico's.

1. De projectdoelstellingen definiëren

Doel :

Verduidelijk waarom maken we het project, voor wieen hoe we succes meten.

Beste praktijk

• Doelstellingen formuleren SMART : Specifiek, Meetbaar, Haalbaar, Realistisch, Tijdgebonden.
• Voeg toe KPI En acceptatiecriteria vanaf het begin (anders wordt “klaar” subjectief).
• Onderscheidend :
  • Bedrijfsdoelstellingen (waarde) vs technische doelstellingen (middelen)
  • Moet hebben vs Leuk om te hebben

Cijfers/benchmarks

• Beperk jezelf tot 3 tot 5 SMART-doelstellingen maximum: daarboven verwatert de prioritering.
• Definiëren 2 tot 4 KPI's (Te veel KPI's = geen management).

Voorbeeld van een SMART-doelstelling

“Verkort de tijd die nodig is om after-sales verzoeken te verwerken door 48 h tot 24 h door 30/06, Het implementeren van een ticketportaal en kennisbank, met een gebruikerstevredenheid ≥ 4/5.”

Verwachte resultaten

• Achtergrond (1-2 pagina's): context, SMART-doelstellingen, KPI's, reikwijdte, mijlpalen.
• Definitie van Gedaan / acceptatiecriteria (zelfs in V-cyclusmodus).

2. Belanghebbenden identificeren

Doel :

Vermijd knelpunten: wie beslist, wie valideert, wie voert uit, wie heeft er last van?

Beste praktijk

• Stakeholders in kaart brengen: Sponsor / Eigenaar / Gebruikers / IT / Beveiliging / Juridisch / Operaties / Ondersteuning / Leveranciers.
• Gebruik een RACI-matrix voor elke belangrijke deliverable (specificaties, tests, productielancering, etc.).
• Anticiperen op verandermanagement : Wie verliest wat? Wie wint wat?

Cijfers/benchmarks

• 1 sponsor duidelijk geïdentificeerd (en beschikbaar): anders is arbitrage onmogelijk.
• 1 beslissing = 1 beslisser (anders oneindige consensus).
• Bezoek ten minste 1 vertegenwoordiger van de gebruiker per belangrijk profiel (bijv. backoffice + frontoffice).

Voorbeeld van RACI (uittreksel)

• R (Verantwoordelijk): IT-projectmanager
• A (Verantwoordelijk) : Zakelijke sponsor
• C CISO, DPO, Operaties, Inkoop
• I Ondersteuning, betrokken teams

Verwachte resultaten

• Stakeholderkaart (invloed/impact)
• RACI + lijst van commissies (rollen, frequentie, arbitrageregels)

3. Opstellen van specificaties

Doel :

Definiëren wat is inbegrepen / uitgesloten, eisen, beperkingen en validatiecriteria.

Beste praktijk

• Aanbevolen structuur :
  1. Achtergrond & doelstellingen
  2. Omtrek (IN/OUT)
  3. Functionele vereisten (user stories of specificaties)
  4. Niet-functionele vereisten (perf, beveiliging, SLA, toegankelijkheid)
  5. Beperkingen (IS, regelgeving, budget, planning)
  6. Gegevens en interfaces (API's, flows, formaten)
  7. Test- en acceptatiestrategie
  8. Inzet en ondersteuning
• Formaliseren veronderstellingen en afhankelijkheden (vaak vergeten).
• Nu bepalen hoe de wijzigingsverzoek (anders ontstaat er scope creep).

Cijfers/benchmarks

• Streef naar 10 tot 25 functionele vereisten goed geschreven in plaats van 80 vaag.
• Voeg toe 5 tot 10 niet-functionele vereisten minimum (beveiliging, beschikbaarheid, back-up, RTO/RPO, prestaties, audit, etc.).
• Om ambiguïteit te verminderen: elke eis moet testbaar zijn (receptcriteria).

Voorbeeld

“De gebruiker kan een ticket aanmaken door ≤ 2 minuten, met hulpstukken tot 10 Mb, en ontvangt een bevestigingsmail in minder dan 60 seconden.”

Verwachte resultaten

• Eisen specificatie (of backlog) gevalideerd
• Regels voor perimeterbeheer (proces voor wijzigingsverzoeken)

4. Middelen en deadlines plannen

Doel :

Behoefte omzetten in uitvoerbaar plan Taken, werklast, afhankelijkheden, mijlpalen.

Beste praktijk

• Snijd in WBS (Work Breakdown Structure): batches → subbatches → taken.
• Schatten met behulp van eenvoudige methoden :
  • 3 punten Optimistisch / Waarschijnlijk / Pessimistisch
  • Speelschema (Agile) of PERT (als je wilt verfijnen)
• Identificeer de kritiek pad (de taken die de einddatum verschuiven).
• Maak tijd voor wat vaak vergeten wordt: testen, acceptatie, correctie, documentatie, ondersteuning, implementatie, uitvoering.

Nuttige cijfers

• Typische uitsplitsingen (benchmarks) :
  • Ontwikkeling/parametrering : 40-60 %
  • Tests + correctie 20-35 %
  • Zakelijk recept : 10-20 %
  • Uitrol en veranderingsbeheer : 10-20 %
• Plan een buffer :
  • Bekend project / laag risico : 10 %
  • Project met meerdere teams / afhankelijkheden : 15 %
  • Innovatief/onzeker project : 20 %

Voorbeeld miniplanning

Ticketportaal“ project - 8 weken

• S1: inkadering + workshops (2-3 workshops van 2 h)
• S2-S4: bouwen (sprints of batches)
• S5: systeemtests + correcties
• S6: bedrijfsrecept (scenario's + PV)
• S7: voorbereiding op inzet + training (sessies 1 h)
• S8: opstarten productie + hypercare (5 dagen)

Verwachte resultaten

• Planning (Gantt / stappenplan / releaseplan)
• Werkdrukplan (wie doet wat, wanneer)
• Mijlpalen + doorgangscriteria (Go/No-Go)

5. Risico's beoordelen

Doel :

Anticipeer op obstakels en vermijd de brandweerstand.

Beste praktijk

• Houd een RAID-logboek Risico's, aannames, problemen, afhankelijkheden.
• Met behulp van een eenvoudige matrix Waarschijnlijkheid (1-5) x Impact (1-5) = score (1-25).
• Voor elk risico : preventie + plan B + eigenaar + herzieningsdatum.

Cijfers/benchmarks

• Bij een standaardproject is het de bedoeling om 10 tot 20 risico's geïdentificeerd met de omlijsting (ja, dat is normaal).
• Risicobeoordeling wekelijks als een team, maandelijks in commissie.

Voorbeelden van risico's en tegenmaatregelen

• Risico afhankelijkheid van een instabiele externe PLC
  • Preventie: belastingstests + contractuele SLA
  • Plan B: caching / gedowngrade modus
• Risico onvoldoende zakelijke beschikbaarheid voor het recept
  • Preventie: reserveer uw slots vanaf de planningsfase
  • Plan B: Recept door “belangrijkste gebruikers” + prioritaire scenario's

Verwachte resultaten

• Risicoregister (score, verantwoordelijke, actieplan)
• Continuïteitsplan / geleidelijke inzet indien nodig

6. Regelmatige controle instellen

Doel :

Houd controle en ontdek vroeg: «hoe eerder je het ziet, hoe minder het kost».

Beste praktijk

• Een stuurroutine instellen :
  • Wekelijkse projectupdate (30-45 min): voortgang, risico's, beslissingen
  • Dagelijks (15 min) als toegewijd ontwikkelteam (Agile)
  • Stuurgroep (elke 2-4 weken): arbitrage, budget, planning
• Bewaak 4 eenvoudige indicatoren:
  • Vooruitgang (voltooide vs. geplande deliverables)
  • Kwaliteit (defecten, slagingspercentage testen)
  • Tijdschema's (hiaten en kritisch pad)
  • Risico's (totaalscore, nieuwe risico's, openstaande punten)

Cijfers/benchmarks

• 1 verslag (CR) in ≤ 24 h na elke commissievergadering.
• Een dashboard 1 pagina (geen roman): leesbaar door een sponsor in 2 minuten.

Concreet voorbeeld van een “dashboard met 1 pagina”.”

• Algehele status: 🟢/🟠/🔴
• 3 hoogtepunten van de week
• 3 grote risico's + plannen
• Verwachte beslissingen van de sponsor (met deadline)
• Volgende mijlpaal + criteria

Verwachte resultaten

• Rapporten + actieplan (wie/wat/wanneer)
• Projectdashboard
• Ontvangstrapport + Go/No-Go