1. Home
  2. Kennis
  3. Artikelen
  4. Hoe herken je een ontsporend IT project? En hoe krijg je die weer “back on track”?

Hoe herken je een ontsporend IT project? En hoe krijg je die weer “back on track”?

Begint uw klant steeds meer en steeds gedetailleerdere controlevragen te stellen over de status van het project? Krijgt u van uw leverancier te horen dat dit soort vragen veel te veel tijd kost en ten koste gaat van het halen van de beloofde go-live datum? Kan uw leverancier wederom geen inzicht geven in de stand van zaken van het project? Gefeliciteerd (cynisch), uw IT-project is aan het ontsporen. Hoe zet u uw project weer op de rails? In dit blog geef ik een aantal tips om dit om te draaien en om te voorkomen.
Leestijd 
Auteur artikel Ernst-Jan van de Pas
Gepubliceerd 27 juni 2022
Laatst gewijzigd 27 juni 2022

Patroon van een IT-project

IT projecten volgen meestal een bepaald patroon bestaande uit: (1) onderzoeksfase, (2) ontwerpfase, (3) uitvoeringsfase, (4) opleverfase en (5) onderhoudsfase.

  • In de onderzoeksfase wordt doorgaans onderzoek gedaan naar de specifieke inrichting en configuratie van uw bestaande IT-landschap. Wat moet worden vervangen? Hoe zien de werkprocessen er uit? Hoe verhouden die werkprocessen zich tot de werkprocessen die door het nieuwe systeem worden ondersteund (verschillenanalyse). Doelstelling van deze fase is dat een goed begrip wordt verkregen van het werk dat verricht moet worden. Vaak ook ter controle of validatie van de uitgangspunten die zijn beschreven in de offertefase.
  • In de ontwerpfase worden de uitkomsten van de onderzoeksfase uitgezet in de tijd. Wat moet in welke volgorde worden aan- of opgepakt? Er wordt een roadmap en planning gemaakt en in veel gevallen (dat is wel heel verstandig) wordt er een visualisatie van de toekomstige en huidige situatie gemaakt. Doelstelling van deze fase is om te komen tot een concreet plan van aanpak om van de bestaande naar de nieuwe situatie te werken, met bijbehorende planning en lijst van afhankelijkheden en verdeling van verantwoordelijkheden (wat moet de leverancier en wat moet de afnemer doen).
  • In de uitvoeringsfase wordt (zoals de naam van de fase al doet vermoeden) uitvoering gegeven aan het plan van aanpak. Dit kan op basis van een Agile/Scrum methodologie gaan of waterval of anders. Belangrijk aandachtspunt is dat in elk project onverwachte situaties op zullen komen die niet voorzien zijn. Aan het einde van de uitvoeringsfase zal doorgaans de conversie/migratie van de data plaatsvinden.
  • In de opleverfase wordt het geheel van de opgeleverde software getest en indien goed bevonden in gebruik genomen. In veel gevallen wordt enkel gekeken naar de functionaliteiten van de software (voldoen die aan datgene wat afgesproken is) en/of vinden ketentests plaats of het geheel van de opgeleverde software daadwerkelijk aansluit in het grotere landschap en of de werkprocessen goed ondersteund worden. Ook moet in deze fase zorggedragen worden dat de nieuwe software en (bijgestelde) werkprocessen worden geadopteerd door de organisatie. Hiervoor dienen trainingen plaats te vinden.
  • In de onderhoudsfase wordt de nieuwe software “naar beheer gestuurd”, dat wil zeggen dat het vanaf dit moment onderhouden wordt. Dit is een belangrijk moment omdat het IT-project en de daarbij horende afspraken In feite ophouden en worden overgenomen door de afspraken in het onderhoudscontract, meestal een separate SLA. Juridisch wordt het toetsingskader dus anders (zei het dat gebreken nog steeds onder de leveringsovereenkomst moeten worden opgelost).

Niet volgen van dit patroon

Veel IT-projecten ontsporen doordat dit patroon niet of niet goed wordt gevolgd. Door allerlei omstandigheden wordt vaak gestart bij de uitvoeringsfase, zonder dat er een gedegen onderzoek heeft plaatsgevonden en/of zonder dat er een goed plan van aanpak wordt opgesteld met de bijbehorende roadmaps, verdeling van verantwoordelijkheden, visualisaties van de ‘soll’ en ‘ist’ situatie. Dat dit veel tijd kost moge wellicht zo zijn maar zonder een gedegen onderzoek en plan is een IT-project heel lastig onder controle te houden. Evenmin is dan mogelijk om de eigen verantwoordelijkheid van de afnemer in te kleuren: wanneer moet nu precies welke informatie aangeleverd worden? Wanneer moeten mijn eigen mensen beschikbaar zijn? 

De vragen uit de inleiding van dit blog zijn duidelijke symptomen van het ontsporen van een IT-project door gebrek aan inzicht/overzicht. Dat gebrek voedt vervolgens het wantrouwen van een afnemer in de doorgaans sussende woorden van de leverancier ("alles is onder controle, we gaan die deadline gewoon halen"). De neiging die dan ontstaat is dat de afnemer steeds vaker steeds meer gaat vragen naar bewijs dat het inderdaad nog op orde is, wat weer het wantrouwen bij de leverancier volgt (“geloof me nu maar”). Over en weer ontstaan irritaties. De leverancier gaat (vaak terecht) zeggen dat de rekening en verantwoording die moet worden afgelegd veel te veel tijd gaat kosten en dat daardoor de Go-live datum niet meer gehaald gaat worden. Wat weer de angst voedt van de afnemer dat het niet op tijd af gaat komen ("zie je nou wel, ik zij het toch dat het project ontspoord is"). De irritaties slaan door naar verwijten over en weer en is een conflict gauw geboren.

Hoe los je het op?

Simpel, door alsnog fase 1 en fase 2 te doorlopen. Er voor te zorgen dat er een fatsoenlijk plan van aanpak ligt waarin duidelijk is wie, wat, wanneer moet doen. Dit is de enige manier om het project weer onder controle te brengen. 

Daarnaast is het zaak om te zorgen voor een goede project governance. Ook hierover hebben wij al het nodige geschreven. Niet alles wat in een project gebeurd is voorzienbaar tijdens de onderzoeksfase. Tegenslagen moeten worden geabsorbeerd, dit moet alleen op een ordentelijke en transparante wijze gebeuren.  

Wat als de leverancier dit niet meer wil doen?

In de praktijk wordt meestal in het IT-contract een concrete afspraak gemaakt dat het project zal worden verricht aan de hand van een concreet plan van aanpak waarin een aantal zaken terug moeten keren: zoals planning, verdeling van verantwoordelijkheden, wijze waarop het project wordt bestuurd en kan worden bijgestuurd (governance), wijze waarop de conversie/migratie gaat plaatsvinden, etcetera. Als een dergelijke afspraak is gemaakt kun je daar nakoming van eisen, desnoods bij de rechter onder versterking van een dwangsom.

En als die afspraak niet is gemaakt?

Dan val je terug op de wet. Een dergelijk IT-contract is een overeenkomst van opdracht. Op grond van de wet zal een leverancier (als opdrachtnemer) zorgvuldig moeten handelen (7:401 BW). Dit is de zorgplicht waar wij al veelvuldig over hebben geschreven en welke zorgplicht de laatste jaren enorm in beweging is. Onderdeel van de zorgplicht is (onder meer) dat de leverancier de opdrachtgever op de hoogte moet houden over de uitvoering en voltooiing van zijn opdracht en rekening en verantwoording moet afleggen (7:403 BW). Het niet voldoen aan deze norm kan dus een schending van de zorgplicht meebrengen. Dat biedt dus ook een haakje voor een nakomingsvordering.

Het is dus in de eerste plaats aan de leverancier om de eerste stap te zetten. Dat is in de meeste gevallen ook redelijk gelet op de hogere mate van deskundigheid van een leverancier in het doorlopen van een IT-project.