Soll vs. ist
In theorie is de vraag of er sprake is van een tekortkoming eigenlijk heel eenvoudig. De vraag is in feite of er overeenkomstig de afspraken is geleverd. Wanneer er minder is geleverd dan er is overeengekomen, dan is er sprake van een tekortkoming. In de juridische literatuur wordt dit ook wel eens met Duitse termen aangeduid als een vergelijking tussen soll (wat zou er moeten zijn geleverd?) en ist (wat is er feitelijk geleverd?).
Maar wat is er eigenlijk overeengekomen?
Tot zover de theorie. De praktijk is namelijk een stuk weerbastiger. Zo blijkt namelijk regelmatig dat helemaal niet zo duidelijk is wat partijen nu eigenlijk zijn overeengekomen. Soms is er geen contract of andere documentatie waarin de afspraken eenduidig op een rijtje staan, maar bestaan de afspraken uit een verzameling van e-mails, telefoonnotities en notulen van diverse overleggen. Soms staat er zelfs helemaal niets op papier en zijn alle afspraken alleen mondeling gemaakt. Aangezien het Nederlandse contractenrecht vormvrij is (artikel 3:37 BW jo. artikel 6:217 BW), kunnen al die afspraken (of ze nu op schrift staan of niet) relevant zijn voor de beoordeling wat partijen nu eigenlijk zijn overeengekomen.
Daar tegenover staat dat het ook wel eens voorkomt dat in plaats van een gebrek aan afspraken, er juist erg veel verschillende afspraken zijn gemaakt. Zo komt het voor dat voor een bestaand project nieuwe contracten worden afgesloten, zonder dat rekening is gehouden met de historische afspraken in dat bestaande project. Berucht bij ICT-projecten is ook het gedurende het project steeds wijzigen van de specificaties (floating specs), hetzij formeel door steeds opnieuw wijzigingsverzoeken (veelal change requests genoemd) in te dienen, hetzij informeel door in allerlei overleggen en andere vormen van communicatie specifieke nadere afspraken te maken. Zie in dat kader bijvoorbeeld het grote aantal wijzigingsverzoeken dat speelde in de uitspraak van de rechtbank Utrecht in het geschil tussen Fortis en Raindrop.
Ook komt het regelmatig voor dat er wel degelijk een contract is, maar dat partijen zich in feite helemaal niet aan de afspraken uit dat contract hebben gehouden. Ook dat kan - vanwege diezelfde vormvrijheid van het contractenrecht - relevant zijn voor de beoordeling wat partijen nu eigenlijk hebben afgesproken. Het bestaande contract kan door dat gedrag namelijk zijn gewijzigd, aangevuld of zelfs (bij uitzondering) niet langer relevant zijn.
Goed contractmanagement is dus erg belangrijk. Zeker bij de wat langlopende contracten komt het immers vaak voor dat gaandeweg, bijvoorbeeld vanwege voortschrijdend inzicht, de afspraken (zowel specificaties als werkafspraken) moeten worden bijgesteld. Het is van belang die nieuwe afspraken goed vast te leggen, om discussie achteraf hierover te vooorkomen.
Onduidelijkheden in de afspraken
Het kan dus een behoorlijke puzzel zijn om helder te krijgen wat er precies is afgesproken. Daarmee is echter de vraag of er sprake is van een tekortkoming vaak nog niet te beantwoorden. Regelmatig blijkt namelijk dat de afspraken die partijen hebben gemaakt, niet bepaald uitblinken in helderheid. Met andere woorden: het is dan wel duidelijk welke afspraken er zijn gemaakt, maar wat die afspraken nou eigenlijk betekenen...
Zo komt het nog steeds voor dat er opdrachten worden verstrekt tot bijvoorbeeld de ontwikkeling van een softwarepakket, zonder dat duidelijk is wat dat softwarepakket dan vervolgens precies moet kunnen. De specificatie blijft in een dergelijk geval veelal beperkt tot een algemene/abstracte omschrijving van de functionaliteit. Als echter niet duidelijk is wat er geleverd moet worden, dan zal het ook erg lastig worden om aan te tonen dat sprake is van een tekortkoming (dus dat er te weinig is geleverd).
Bij hele evidente fouten in (om bij het voorbeeld te blijven) de software kan dan nog wel worden teruggevallen op de stelling dat software toch in ieder geval de eigenschappen moet hebben die redelijkerwijs daarvan verwacht mogen worden en/of dat van een kundige programmeur verwacht mag worden dat deze geen software met fouten van een dergelijk kaliber oplevert. Voor minder duidelijke gevallen ("de software reageert niet zo vlot", "de software werkt niet gebruikersvriendelijk", etc.) wordt het bij gebrek aan duidelijke afspraken echter best lastig om aan te tonen dat de software dergelijke eigenschappen had behoren te hebben en dat er bij gebreke daarvan (dus) sprake is van een tekortkoming. Zie in dat kader bijvoorbeeld ook onze eerdere berichtgeving over [intlink id="4930" type="post"]het geschil tussen Bull en Audax[/intlink], waar onder meer gestreden werd over de betekenis van begrippen als ‘performance’ en ‘high available’.
Interpretatie van de afspraken
In het contract, de algemene voorwaarden of andere (juridisch getinte) documenten kunnen bovendien bepalingen staan die verder "inkleuren" wat er nu precies is overeengekomen. Dat kan in de praktijk wel eens heel vervelend uitpakken en tot veel misverstanden leiden, zeker wanneer de technische specificaties en juridische randvoorwaarden door verschillende personen zijn opgesteld die verder geen onderling overleg hebben gehad.
Zo wil er in algemene voorwaarden nog wel eens staan dat op de leverancier alleen inspanningsverplichtingen en geen resultaatsverplichtingen rusten. Dat ene zinnetje kan een wereld van verschil maken. Stel dat in het contract staat "Vragen zullen tijdig worden beantwoord door de helpdesk", terwijl in de toepasselijke algemene voorwaarden staat dat alle verbintenissen inspannings- of juist resultaatsverbintenissen zijn. Dat leidt tot heel verschillende uitkomsten, zoals blijkt het volgende (ietwat gechargeerde) schema.
| Inspanningsverbintenis | Resultaatsverbintenis | |
|---|---|---|
| Afspraak | De helpdesk zal zich inspannen (doet zijn best) om vragen tijdig te beantwoorden | De helpdesk zal alle vragen tijdig beantwoorden |
| Tekortkoming | Wanneer de helpdesk onvoldoende inspanningen heeft getroost | Wanneer niet alle vragen tijdig zijn beantwoord |
Zo zijn er nog wel meer voorbeelden te geven waarbij algemene voorwaarden of het contract een nadere inkleuring geven van wat er in (technische) documenten staat omtrent hetgeen partijen zijn overeengekomen. Denk in dat kader aan bepalingen als "alle levertijden zijn louter indicatief", "leverancier is gerechtigd de prijzen tussentijds aan te passen, ook voor lopende projecten", "bij overschrijding van het overeengekomen budget is leverancier niettemin gerechtigd het meerwerk tegen de gebruikelijke uurtarieven in rekening te brengen", etc. Dat het effect van dergelijke "kleine lettertjes" groot kan zijn, blijkt bijvoorbeeld uit [intlink id="3005" type="post"]het geschil tussen de VVD en Perfect Database[/intlink], waarin de rechtbank (kort samengevat) oordeelde dat Perfect Database inderdaad niet tijdig een goed werkend systeem aan de VVD had opgeleverd, maar dat Perfect Database niettemin (vanwege de algemene voorwaarden) de VVD slechts een fractie van het betaalde geld terug hoefde te betalen.
Een ander aandachtspunt in dit kader is dat overeengekomen criteria soms vanuit het perspectief van leverancier dan wel afnemer heel anders kunnen worden geinterpreteerd. Zo is het best denkbaar dat een leverancier oprecht meent en er van is overtuigd dat de door hem opgeleverde applicatie voldoet aan de eis "de applicatie zal gebruikersvriendelijk zijn", terwijl de gebruikers moord en brand schreeuwen omdat er in hun ogen in redelijkheid niet met de betreffende software is te werken. In dat geval zal zowel moeten worden onderzocht hoe de overeengekomen eis in redelijkheid mag worden geinterpreteerd, als hoe datgene wat is opgeleverd in redelijkheid mag worden beschouwd.
Wie moest eigenlijk wat leveren?
In de wat complexere trajecten zijn vaak meerdere partijen betrokken. De wijze waarop de samenwerking is ingericht is bepalend voor de vraag wie er moet presteren en daarmee dus ook of er wel sprake is van een tekortkoming van de betreffende partij. Wanneer die onderlinge partijverhouding niet of niet duidelijk is geregeld, zal eerst moeten worden onderzocht hoe die partijverhouding nu eigenlijk ligt voordat kan worden onderzocht of er wel sprake is van een tekortkoming.
De betreffende samenwerking kan op allerlei verschillende manieren worden ingericht: waarbij een partij als eindverantwoordelijke ("hoofdaannemer") diverse hulppersonen ("onderaannemers") aanstuurt, waarbij alle partijen hoofdelijk verbonden zijn (dus iedereen is verantwoordelijk voor het eindresultaat) of waarbij met verschillende partijen afzonderlijke overeenkomsten worden gesloten (zoals een afzonderlijke overeenkomst met een datacentrum en een afzonderlijke overeenkomst met een softwareleverancier, terwijl die laatste wel afhankelijk is van dat datacentrum).
En wat is er nu eigenlijk geleverd?
Pas wanneer duidelijk is wat partijen zijn overeengekomen, hoe dat moet worden geinterpreteerd en wie nu eigenlijk wat moet leveren, kan de vergelijking worden gemaakt met wat er is geleverd om te constateren of er al dan niet sprake is van een tekortkoming. Daarvoor zal duidelijk moeten zijn wat er nu eigenlijk is opgeleverd. Dat zal bij de oplevering van bijvoorbeeld standaard hardware of software op een drager in de regel vrij eenvoudig zijn, daar is immers op een bepaalde datum een bepaald fysiek product aangeleverd. Dat fysieke product kan worden onderzocht en vergeleken met de overeengekomen specificaties. Het kan soms al lastiger worden wanneer de overeenkomst strekt tot het verrichten van diensten.
Hier komt het belang van een goede acceptatietest, inclusief een goede contractuele borging daarvan, om de hoek kijken. In een goede acceptatietest ligt vast wat er onderzocht moet worden, hoe dat onderzoek plaatsvindt en wat er gebeurt bij eventueel afkeuren. De acceptatietest vormt daarmee een onverbrekelijk geheel met de rest van de afspraken. Ook hier komt weer het belang van goed contractmanagement om de hoek kijken: mochten de afspraken tussentijds zijn bijgesteld, dan is het uiteraard van belang dat ook tijdens de acceptatietest wordt gewerkt conform en getoetst aan de laatste versie van de afspraken.
Moraal van het verhaal: maak duidelijke afspraken
Het zal ondertussen duidelijk zijn: het is van belang om alle afspraken in een IT-traject duidelijk, eenduidig en zo min mogelijk voor interpretatie vatbaar vast te leggen. Wanneer afspraken goed zijn vastgelegd is het namelijk veel eenvoudiger om te onderzoeken of er sprake is van een tekortkoming dan wanneer er niets vastligt. Dat wil overigens niet zeggen dat er geen mogelijkheden bestaan wanneer geen van de gemaakte afspraken ergens vast ligt, het vergt alleen wat meer onderzoek om bijvoorbeeld an de hand van getuigenverklaringen te reconstrueren wat die afspraken ook alweer inhielden. Wat dat betreft kan een hoop tijd en moeite achteraf worden bespaard wanneer de afspraken vooraf duidelijk worden vastgelegd. Niet alleen de eigen positie staat zo helder op papier, ook eventuele tegenstrijdige visies van de wederpartij kunnen met duidelijke afspraken vaak eenvoudig worden weerlegd.
Tot besluit
Dat er sprake is van een tekortkoming wil overigens niet per se zeggen dat er (dus) sprake is van een plicht tot schadevergoeding, dat daarmee het recht is ontstaan de overeenkomst te ontbinden of dat er dan automatisch andere juridische mogelijkheden open staan. Het antwoord op die vragen ligt genuanceerd. De vraag of er sprake is van een tekortkoming is namelijk slechts een van de hordes die moet worden genomen in een IT-geschil. Er zijn echter meer hordes te nemen, daarover meer in de volgende artikelen uit deze serie.
