(Mislukte) automatiseringsprojecten: hoe een conflict te voorkomen?

Automatiseringsprojecten kunnen tijdrovende, complexe en kostbare projecten zijn. Goede afspraken die nauwgezet worden vastgelegd in een overeenkomst zijn daarbij onontbeerlijk. Helaas verlopen automatiseringen in de praktijk niet altijd vlekkeloos. Vaak is voor afnemers niet duidelijk wat van IT-leveranciers mag én kan worden verwacht. Van cliënten krijgen wij regelmatig de vraag hen bij te staan in een conflict over een mislukte automatisering. Dergelijke conflicten zijn vrijwel altijd complex en lastig te doorgronden. Bovendien, niets is zo vervelend als een conflict. Vaak streven partijen tegenovergestelde belangen en doelen na. Hoe kunt u voorkomen dat automatiseringsprojecten mislukken? Wat als het resultaat niet aan uw verwachtingen voldoet? Voor zowel afnemer als automatiseerder is het goed om te weten dat de rechter in geschillen over mislukte automatiseringen de prestatie van de IT-leveranciers vaak aan de hand van hun zorgplicht beoordeeld. Wat houdt die zorgplicht in?

15 okt. 2019

Juridisch kader ICT-projecten

Er bestaat geen wettelijke definitie voor ICT-overeenkomsten en -dienstverlening. Onze wet kent ook geen specifieke wettelijke bepalingen voor ICT-contracten. Omdat een specifiek wettelijk kader ontbreekt, kan er dus niet worden teruggevallen op de wet waar het de inhoud en reikwijdte van de overeenkomst betreft. Daarom is het – nog meer dan bij andersoortige overeenkomsten - van belang om in een ICT-contract duidelijk te omschrijven wat het onderwerp van de overeenkomst is, wat er precies wordt geleverd, voor welk doel en op welke wijze dit wordt geleverd. In de praktijk zien wij echter regelmatig dat afspraken tussen partijen niet duidelijk worden vastgelegd. Sommige partijen gaan zelfs omvangrijke automatiseringsprojecten aan op basis van een opdrachtbevestiging en algemene voorwaarden. Algemene voorwaarden omvatten een set generieke afspraken die op iedere overeenkomst van toepassing verklaard kunnen worden. Gezien de generieke aard van algemene voorwaarden is het meestal niet afdoende om alleen daarmee de relatie tussen IT-leverancier en de afnemer te regelen. De specifieke omschrijving van de prestatie en harde afspraken over de specificaties en functionaliteiten staan in de regel niet in algemene voorwaarden. Vaak blijft dan vaag wat de leverancier precies had moeten opleveren, wanneer hij aan zijn leveringsplicht heeft voldaan en of de leverancier bijvoorbeeld verantwoordelijk is voor goede koppelingen van het automatiseringspakket met de andere systemen bij de afnemer. Dit kan zorgen voor (dure) teleurstellingen.

Zorgplicht IT-dienstverleners

In een kwestie die speelde voor de rechtbank Noord-Holland van 14 november 2018 (ECLI:NL:RBNHO:2018:10021) zou Betty Blocks volgens de scrum/Agile methode software ontwikkelen ten behoeve van de administratie van een vastgoedbeheerder. Kort samengevat wordt bij de Agile-methode, anders dan softwareontwikkeling volgens de klassieke Waterfall-methode, niet vooraf contractueel volledig vastgelegd wat er op (detailniveau) precies gebouwd gaat worden. In plaats daarvan wordt gaandeweg het traject, aan de hand van de test-feedback van de opdrachtgever, verder afgestemd wat er precies gebouwd gaat worden. Wel worden vanuit de bedrijfsactiviteiten van de opdrachtgever vooraf de wensen/eisen (“requirements”) geïnventariseerd en neergelegd in een totale userstory. Deze scrum-ontwikkelingsmethode beoogt te voorkomen dat automatiseringsprojecten ontsporen. Het is namelijk de bedoeling dat afnemer en leverancier in nauwe samenwerking en in korte iteraties (tussensprints) werkende software opleveren. Dit zou in deze zaak gebeuren in slechts 19 weken en vijf sprints.

Het project liep echter al heel snel vast. Het vastgoedbedrijf klaagde over gebrek aan begeleiding waardoor het volgens het vastgoedbedrijf niet lukte om de software te testen en te beoordelen. Het vastgoedbedrijf schortte vervolgens de betalingen aan Betty Blocks op en zij ontbond de overeenkomst. Betty Blocks liet het er niet bij zitten en vorderde in een procedure betaling van de achterstallige rekeningen en schadevergoeding. De rechtbank beoordeelde de prestatie van Betty Blocks naar de mate waarin deze aan haar zorgplicht had voldaan.

Wat houdt die zorgplicht in? Wanneer sprake is van een overeenkomst van opdracht dient een IT-leverancier minimaal te handelen conform de inspanningen die van een “redelijk handelend vakgenoot” geëist kunnen worden. Voor IT-opdrachten wordt dit vertaald naar de vraag of het handelen van de ICT-leverancier: “al of niet voldeed aan de mate van zorgvuldigheid die van een redelijk handelend en bekwaam automatiseringsdeskundige geëist mag worden”. Deze zorgplicht betreft een open norm en kan daardoor tot verantwoordelijkheden van IT-leveranciers leiden die niet letterlijk in de overeenkomst zijn omschreven. Een aantal concrete voorbeelden uit IT-jurisprudentie waarin een (verzwaarde) zorgplicht voor IT-dienstverleners werd aangenomen betreffen de volgende:

  • In geval van projectleiding dient een IT-leverancier de voortgang proactief te bewaken en een klant aan te spreken indien deze niet voortvarend genoeg meewerkt;
  • De IT-leverancier dient alles in het werk te stellen om het project te laten slagen, waaronder de inzet van voldoende personeel. De klant mag goed projectmanagement verwachten;
  • De IT-leverancier zal bij de uitvoering van een project het belang van de klant in het oog moeten houden en de klant daar adequaat over moeten informeren. Indien de voortgang alleen maar geld zal kosten zonder direct voordeel, dient de leverancier aan te sturen op opschorting of beëindiging;
  • Een IT-leverancier die meent dat voor het welslagen van een project een bepaald traject noodzakelijk is, dient de klant daar vooraf op te wijzen en te waarschuwen voor de risico’s van het achterwege laten daarvan;
  • Overeengekomen budget- en resultaatverantwoordelijkheid van de IT-leverancier brengt een waarschuwingsplicht voor de leverancier mee indien wijzigingen die de klant verlangt het budget of resultaat in gevaar brengen;
  • Bij de aanschaf van software mag de klant in ieder geval de functionaliteit verlangen waarvan hij aan de leverancier heeft aangegeven dat die voor hem van belang is en die ook benodigd is voor het normale gebruik van de software, tenzij hij is gewaarschuwd dat de functionaliteit in de software ontbreekt;
  • Het steeds wisselen van projectleiders van leverancier gaat ten koste van de communicatie en continuïteit en onder meer daardoor is er sprake van mismanagement van het project.

Uit jurisprudentie valt bovendien te destilleren:

  • De belangen van de klant dienen voorop te staan;
  • Een overeenkomst dient professioneel en met voldoende inzet te worden uitgevoerd;
  • Een leverancier dient voorafgaande aan contractsluiting en tijdens de uitvoering van het contract de klant te informeren en te waarschuwen indien de wensen van de klant niet gerealiseerd kunnen worden of grote risico’s in zich dragen, of indien nieuwe risico’s of bijkomende kosten ontstaan.

In de Betty Blocks zaak stelde de rechter vast dat in dit geval het “procesmanagement tot de taken van de IT-leverancier behoorde”. De IT leverancier had diens klant adequaat moeten begeleiden bij het testen. Omdat dit niet gebeurde is Betty Blocks tekortgeschoten in haar zorgplicht.