Juridische consequenties van hoe je afspraken binnen een project maakt

Projecten die foutloos, binnen tijd en budget worden opgeleverd zijn schaars en bestaan misschien zelfs niet; ik ben ze in ieder geval nog nooit tegengekomen. Bij grotere projecten wordt bij de start veel aandacht besteed aan het contract; de juridische afdeling of een externe advocaat kijkt mee en het getekende contract wordt keurig opgeslagen in de spreekwoordelijke la.

Dan komen tijdens de uitvoering van het project de onvermijdelijke eerste hobbels. Het blijkt toch complexer om de beloofde koppeling te realiseren, de gegevens die gemigreerd moeten worden bevatten uitzonderingen die tijdens de voorstudie niet aan het licht zijn gekomen, of de klant voert de tussentijdse testen onvoldoende gedetailleerd uit, waardoor later in het project hiaten in de software aan het licht komen.

Afspraken vastleggen om juridische consequenties bij projecten te voorkomen

In de praktijk worden veel van deze issues in eerste instantie in de stuurgroep besproken en leiden bijvoorbeeld tot een Irregularity Report waarin hernieuwde afspraken worden gemaakt. Of de projectleider van de leverancier stuurt de projectleider een mail waarin wordt uitgelegd waarom het project vertraagd is, wanneer het onderdeel wordt opgeleverd, waarna de klant schoorvoetend akkoord gaat met de nieuwe planning.

In beginsel is het een goede zaak dat partijen in een dergelijke situatie in onderling overleg tot een oplossing proberen te komen; het is echt niet nodig om met een advocaat naar deze gesprekken te gaan. Maar wat wel aanbevelenswaardig is – en in mijn ogen zelfs noodzakelijk – is dat de betrokkenen in een project, en dan met name de projectleider, op de hoogte zijn van enkele juridische basisbeginselen, in ieder geval om te voorkomen dat de goede afspraken uit het contract worden ondermijnd.

Voorbeelden uit de praktijk

Fatale termijnen bij een project

Bij het vaststellen van ‘fatale termijnen‘ spreken de leverancier en de klant af dat zodra een overeengekomen datum niet wordt gehaald, de partij die moest presteren automatisch ‘in verzuim’ is. Dit betekent dat de ontvangende partij de overeenkomst mag ontbinden en mogelijk ook recht heeft op schadevergoeding. Het project loopt uit, partijen maken een nieuwe planning, maar ook die wordt niet gehaald. De klant wil van het project af en ontbindt – mede op grond van het niet behalen van de fatale termijn.

Omdat partijen nieuwe afspraken hebben gemaakt, en de klant daarbij niet heeft aangetekend dat zij blijft vasthouden aan fatale termijnen, wijst de rechter de eis van de klant af. Een projectleider die kennis had van fatale termijnen had waarschijnlijk een andere aanpak gekozen door vast te houden aan de fataliteit van de termijnen, nieuwe termijnen ook als fataal te kwalificeren en bij de ontbinding in ieder geval ook een ingebrekestelling te versturen.

Zorgplicht bij een project

De laatste jaren wordt steeds vaker een beroep gedaan op de zorgplicht die de leverancier van IT-diensten heeft. De zorgplicht is een open norm, wat betekent dat in de wet niet precies te vinden is wanneer een leverancier aan zijn zorgplicht heeft voldaan; er staat slechts dat de opdrachtnemer de zorg van een goede opdrachtnemer in acht dient te nemen.

Jurisprudentie over dit onderwerp geeft een verdere invulling van het begrip zorgplicht. Zo bepaalde de rechter dat indien het voorzetten van een project alleen maar meer geld gaat kosten, de IT-leverancier moet sturen op opschorting of beëindiging van de overeenkomst. In een andere zaak bepaalde de rechter dat indien er een groot kennisverschil bestaat tussen de klant en de leverancier – wat bij veel IT-projecten het geval zal zijn – de leverancier in het kader van zijn zorgplicht de consequenties van de voorgestelde aanpak, in dit geval het toepassen van de Agile methodiek, moet uitleggen wat de consequenties daarvan zijn en de opdrachtgever begeleiden tijdens de uitvoering van het project.

Ten slotte blijkt uit een andere uitspraak dat de leverancier alles in het werk moet stellen om het project te laten slagen. Een projectleider die op de hoogte is van de invulling van het begrip zorgplicht staat sterker in het gesprek met een leverancier op het moment dat de voortgang van het project niet loopt zoals afgesproken.

Meerwerk bij projecten

Met name in softwareprojecten waarbij vooraf niet ieder detail gedetailleerd is vastgelegd en geen Agile Scrum aanpak is gekozen, wordt regelmatig de meerwerk-discussie gevoerd: de leverancier is van mening dat de gevraagde functionaliteit niet in de opdracht is opgenomen terwijl de klant van mening is dat dit juist wel het geval is. In geval van een fixed price afspraak in een softwareproject is de kans op deze discussie alleen maar groter.

Om te voorkomen dat relatief ongemerkt het project uitdijt met meerwerk op verzoek van de (eind)gebruiker, is in veel overeenkomst vastgelegd dat meerwerk alleen wordt uitgevoerd nadat dit schriftelijk is goedgekeurd. Er zijn uitspraken te vinden waarbij een goedkeuring van het meerwerk door de projectleider als rechtsgeldig kwalificeert, terwijl in het contract is opgenomen dat de stuurgroep een dergelijk besluit moet nemen.

Maar er zijn ook uitspraken te vinden waarbij de leverancier gehouden wordt aan een dergelijke contractuele bepaling omdat volgens de rechter een dergelijke bepaling is opgenomen om onaangename verrassingen voor de opdrachtgever en discussies tussen partijen moet voorkomen.

Acceptatietesten

Een acceptatietest is meestal het sluitstuk van een project en de meeste IT-contracten bevatten een regeling hierover. Enerzijds met als doel om de opdrachtgever in de gelegenheid te stellen om het geleverde werk te beoordelen voor ingebruikname en anderzijds om de leverancier te beschermen tegen fouten die door de klant tijdens een test gevonden hadden kunnen worden, maar door oppervlakkig testen niet zijn gevonden.

Er zijn situaties denkbaar waarbij de opdrachtgever van mening is dat de opgeleverde software dusdanig slecht is (of onvoldoende gereed is) om een overeengekomen acceptatieprocedure niet uit te voeren. Uit de jurisprudentie blijkt dat dit een onverstandige beslissing kan zijn.

Ook als het systeem niet werkende onderdelen bevat die een succesvolle afronding van de acceptatietest in de weg staan, is het nodig om de acceptatietest uit te voeren en adequate meldingen van deze issues zodat de leverancier deze kan verhelpen.

Projectleiding

Uit bovenstaande voorbeelden blijkt dat de houding en communicatie van de projectleider in een project verschillende verstrekkende juridische gevolgen kan hebben. En ook de invulling van de projectleidersrol heeft consequenties; zo kan slecht projectmanagement van de leverancier een ontbindingsgrond opleveren. Maar als in de overeenkomst ‘gezamenlijk projectmanagement‘ wordt afgesproken, wordt dat door de rechter in het nadeel van de klant uitgelegd.

Training recht voor (IT) projectmanagers

De training Recht voor IT projectmanagers is een korte praktijkgerichte training waarin deze en andere relevante juridische aspecten voor een projectleider bij de uitvoering van een IT-project aan bod komen. De training leert je aan de hand van concrete voorbeelden en recente jurisprudentie met welke juridische aspecten je rekening houdt in de uitvoering van een project. Het leert je wat je het beste kunt doen zodra een project spaak loopt.

Daarnaast krijg je een overzicht van de meer algemene juridische leerstukken die relevant zijn voor een projectleider, zoals het verschil tussen ontbinden en opzeggen. Tijdens de training wordt met verschillende praktijkvoorbeelden geoefend.

Hier vindt je meer informatie over de training Recht voor projectleiders.

Dit artikel is geschreven door Martijn Berk, Jurist en gespecialiseerd in recht bij projecten.