Mislukken van IT-projecten: keuze maken tussen doorgaan of stoppen
Als software ontregeld raakt of niet goed functioneert, zijn wij zelf vaak helemaal onthand, kunnen bedrijfsprocessen gefrustreerd raken of zelfs helemaal tot stilstand komen met alle mogelijke gevolgen van dien. Clichés zegt u? Helaas laat de praktijk zien dat IT-projecten met enige regelmaat mislukken omdat de software niet (goed) functioneert, de performance hapert, de conversie van gegevens is mislukt, het project veel duurder is dan eerder was begroot en/of veel te laat is opgeleverd.
Als een afnemer hiermee geconfronteerd wordt, zal hij een fundamentele keuze moeten maken tussen doorgaan met die software en/of leverancier of - als hij daar geen vertrouwen meer in heeft – stoppen daarmee. Juridisch vertaalt dit zich in het vorderen van nakoming van datgene wat is overeengekomen of juist ontbinding of anderszins beëindiging van de overeenkomst op grond van wanprestatie. Beide vorderingen (nakoming of ontbinding) worden vaak gecombineerd met een schadeclaim. Wees echter niet te snel met het maken van deze keuze. Laat u goed adviseren over de gevolgen, risico’s en mogelijkheden voordat u actie onderneemt.
Maak een goede analyse van de situatie
IT-geschillen zijn meestal complex. Een leverancier is in veel gevallen afhankelijk van de afnemer, bijvoorbeeld met betrekking tot het verstrekken van specificaties (wat wil de afnemer eigenlijk?), bij het aanleveren van data die moeten worden geconverteerd of gemigreerd naar het nieuwe systeem, of bij het inrichten van systemen. De vraag rijst dan al snel of het mislukken van het project aan de leverancier of de afnemer te wijten is. Het is dus van belang om vooraf een goede analyse te maken van de risico’s en mogelijkheden. In de komende weken zullen wij ingaan op de volgende belangrijke onderwerpen die onderdeel uitmaken van een dergelijke analyse.
- Deel 2: Is er sprake van een tekortkoming? Concreet komt dit neer op de vraag of de software geschikt is voor de afnemer en indien dat ook is overeengekomen, of de desbetreffende software op een deugdelijke wijze is geïmplementeerd. Vergeleken moet worden: (A) wat is er overeengekomen met (B) wat is er opgeleverd. Dit lijkt eenvoudig, maar dat is het niet. Soms zijn er helemaal geen specificaties of zijn die er wel maar blijken die niet zo duidelijk te zijn als werd gedacht. Soms zijn vooraf opgegeven specificaties compleet weggecontracteerd of worden deze gaandeweg aangepast (“floating spec’s”). Er kan sprake zijn van meerwerk. Allemaal omstandigheden waardoor het zeer lastig kan zijn om vast te stellen of er überhaupt sprake is van een tekortkoming. Hoe ga je hier mee om? In dit deel zal nader worden stilgestaan bij deze problematiek.
- Deel 3: Veel gebruikte verweren van leveranciers. IT-projecten vereisen doorgaans ook een behoorlijke inspanning van de afnemer, simpelweg omdat de leverancier niet precies weet hoe de bedrijfsprocessen van de afnemer in elkaar zitten en hoe de software moet worden ingeregeld. De afnemer zal hem daarbij moeten helpen. Veel gehoorde verweren zijn dan ook: De te late oplevering ligt niet aan de leverancier maar aan het feit dat de afnemer de specificaties te laat hebt aangeleverd of dat de afnemer zelf te veel te weinig en onvoldoende deskundige mensen op het project heeft gezet. In dit deel wordt ingegaan op hoe je hiermee omgaat.
- Deel 4: Is de leverancier in verzuim? Verzuim is een belangrijk juridisch begrip dat aan de basis staat van elke ontbindingsvordering of schadeclaim. Op enkele uitzonderingen na zal een deugdelijke ingebrekestelling moeten worden verstuurd, voordat verzuim kan worden vastgesteld. Daar gaat het in de praktijk vaak mis. Soms wordt er geen ingebrekestelling verstuurd als dat wel had gemoeten of wordt wel een ingebrekestelling verstuurd maar voldoet die niet aan de daarvoor geldende eisen. Aan de andere kant wordt door de afnemer soms ook niet de medewerking verleend die nodig is om de leverancier zijn verplichtingen tijdig of volledig te laten nakomen, waardoor de afnemer in zogenoemd schuldeisersverzuim kan komen te verkeren. Indien dat wordt vastgesteld, heeft dat verstrekkende gevolgen. In dit deel zal nader worden ingezoomd op deze begrippen.
- Deel 5: Wanneer kan de overeenkomst worden ontbonden of beëindigd? Als sprake is van een (ernstige) tekortkoming kan de overeenkomst in beginsel worden ontbonden. Er zijn echter ook andere (meestal contractuele) mogelijkheden om de overeenkomst te beëindigen. Wat is het verschil tussen ontbinding en de meest voorkomende beëindigingsmogelijkheden? En wat zijn de gevolgen daarvan? Zo gaat ontbinding er bijvoorbeeld vanuit dat elke partij de door hem geleverde prestaties terugkrijgt. Betekent dit dat de afnemer al zijn geld kan terugkrijgen? Hoe moet je omgaan met prestaties die niet kunnen worden teruggegeven, bijvoorbeeld de door de leverancier geleverde diensten? In dit deel zal hier nader op in worden gegaan.
- Deel 6: Schadevergoeding. Mislukte IT-projecten kunnen enorme schade veroorzaken. Denk bijvoorbeeld aan alle kosten die nodeloos gemaakt zijn voor het mislukte project of extra kosten die nog gemaakt moeten worden om een nieuw alternatief systeem aan te schaffen of het oude pakket langer in de lucht te houden. Kun je deze kosten allemaal claimen? In het slotstuk van deze serie zal nader worden ingegaan op de vraag wat er komt kijken bij het instellen van een schadeclaim.
Seminar IT-geschillen 3.0 op 9 oktober 2012
Ik maak direct van deze gelegenheid gebruik door u te wijzen op ons seminar IT-geschillen. Tijdens dat seminar zullen onder meer de hiervoor genoemde onderwerpen behandeld worden, zal in worden gegaan op belangrijke ontwikkelingen in de rechtspraak en kunt u uw vragen kwijt aan de sprekers. Meer informatie over dit seminar? U kunt zich ook direct aanmelden.
