Zeven signalen dat een IT-project vastloopt

IT-projecten lopen zelden plotseling vast. Meestal zijn waarschuwingssignalen al weken of maanden zichtbaar. Ze worden alleen verklaard als tijdelijke drukte, extra afstemming of normale complexiteit. Door die signalen vroeg te herkennen kan de opdrachtgever nog bijsturen voordat herstel duur en bestuurlijk zwaar wordt.

1. De planning verschuift zonder dat de basis opnieuw wordt berekend

Een mijlpaal verplaatsen is op zichzelf geen crisis. Het wordt problematisch wanneer de nieuwe datum niet is gebaseerd op resterend werk, beschikbare capaciteit, afhankelijkheden en besluitmomenten. De planning wordt dan een wenslijst.

Vraag bij iedere grote verschuiving:

• welke oorzaak is weggenomen;
• welk werk resteert;
• welke capaciteit werkelijk is toegezegd;
• welke andere mijlpalen geraakt worden;
• wat het effect op budget en kwaliteit is.

2. De status is groen, maar belangrijke besluiten staan open

Een project kan activiteiten volgens planning uitvoeren terwijl fundamentele keuzes nog niet zijn gemaakt. Denk aan procesafwijkingen, integratieontwerp, datamigratie of acceptatiecriteria. Als deze besluiten later terugkomen, veroorzaken zij herstelwerk.

Een stuurgroeprapportage moet daarom niet alleen voortgang tonen, maar ook open besluiten met eigenaar, deadline en gevolg van uitstel.

3. Scope groeit via gesprekken en e-mail

Scopegroei hoeft niet formeel als change request te worden ingediend. Ze kan ook ontstaan doordat teams extra uitzonderingen opnemen, rapportages uitbreiden of tijdelijke oplossingen permanent maken. Het project voert dan meer werk uit zonder dat planning en budget worden aangepast.

Een bruikbaar wijzigingsproces is licht, maar verplicht ieder relevant verzoek tot beoordeling van waarde, impact en besluit.

4. Test, data en beheer worden naar achteren geschoven

Wanneer configuratie of ontwikkeling achterloopt, wordt tijd vaak teruggewonnen bij test, migratie, opleiding of beheer. Daarmee wordt het werk niet kleiner. Het risico wordt alleen later zichtbaar, op het moment dat herstellen het moeilijkst is.

Bescherm deze werkstromen met eigen planningen, eigenaren en gereedheidscriteria. Zij zijn geen afsluitende taken, maar lopen vanaf het begin mee.

5. Rapportages beschrijven activiteit, niet resultaat

Veel afgeronde workshops, documenten en tickets kunnen een indruk van voortgang geven. De relevante vraag is of geaccepteerde resultaten zijn opgeleverd. Een ontwerp dat nog niet is besloten of een configuratie die nog niet ketengetest is, is geen afgeronde bedrijfsfunctionaliteit.

Maak onderscheid tussen:

• werk gestart;
• concept gereed;
• beoordeeld;
• geaccepteerd;
• bruikbaar in de volledige keten.

6. Leveranciers wijzen bij ieder probleem naar een andere partij

Dit is een teken dat integratieverantwoordelijkheid en end-to-end testen onvoldoende zijn geregeld. Iedere leverancier kan individueel gelijk hebben, terwijl het project als geheel stilstaat.

De opdrachtgever moet bepalen wie een ketenprobleem coördineert, welke gegevens alle partijen delen en binnen welke termijn een gezamenlijke analyse wordt verwacht.

7. Niemand kan een betrouwbare eindprognose geven

Wanneer planning, budget, scope, risico en capaciteit afzonderlijk worden beheerd, kan niemand uitleggen wat nog nodig is om het eindresultaat te bereiken. Dan wordt ieder besluit genomen op onvolledige informatie.

Een betrouwbare prognose hoeft niet exact te zijn. Ze moet wel laten zien:

• welk resultaat nog openstaat;
• welke aannames zijn gebruikt;
• welke risico’s een bandbreedte veroorzaken;
• welke besluiten de prognose veranderen;
• wat het meest waarschijnlijke en het ongunstige scenario is.

Wat doet u bij meerdere signalen?

Start niet direct met een nieuwe planning. Laat eerst vaststellen welke oorzaken onder de signalen liggen. Een korte IT Project Health Check kan scope, plan, budget, governance, kwaliteit en leveranciers in samenhang beoordelen.

Daarna zijn drie uitkomsten mogelijk:

1. het project kan doorgaan met gerichte verbeteringen;
2. het project heeft een herstart en tijdelijke herstelregie nodig;
3. de huidige aanpak is niet verantwoord en moet fundamenteel worden gewijzigd of beëindigd.

Waarom vroeg ingrijpen werkt

Vroeg in het project zijn keuzes nog aanpasbaar en is herstelwerk beperkt. Vlak voor go-live zijn contracten, communicatie, gebruikersplanning en technische afhankelijkheden al vastgelegd. Een onafhankelijke beoordeling is daarom geen teken van mislukking, maar van professioneel opdrachtgeverschap.

Duidelijke antwoorden

Veelgestelde vragen

Is een gemiste mijlpaal direct reden voor project recovery?

Niet altijd. Belangrijk is of oorzaken, gevolgen en een realistische nieuwe prognose bekend zijn. Herhaald verschuiven zonder herstelplan is wel een sterk signaal.

Kan een project health check worden uitgevoerd zonder het project stil te leggen?

Ja. Een afgebakende review kan parallel aan lopende werkzaamheden plaatsvinden, zolang informatie en sleutelpersonen beschikbaar zijn.

Wie moet opdracht geven voor een onafhankelijke review?

Bij voorkeur de opdrachtgever, directie of stuurgroep die mandaat heeft om op basis van de uitkomst bij te sturen.