Het is voor opdrachtgevers verre van eenvoudig om juridische actie te ondernemen wanneer een ict-dienstverlener faalt bij de uitvoering van een ict-project. Om tussentijds een ict-project te kunnen ontbinden en bijvoorbeeld schadevergoeding te ontvangen voor geleden schade, moet aan 'behoorlijk wat' voorwaarden worden voldaan. Dat schrijft ict-jurist Polo van der Putt in een artikel op de website IT en Recht.
'Veel ict-projecten lopen uit, kosten meer dan begroot of leveren niet de gevraagde functionaliteit', schrijft van der Putt. 'Vaak vertoont een project al tijdens de rit de eerste tekenen van mislukking. De wet biedt de afnemer dan soms de mogelijkheid om er tussentijds uit te stappen.' Aan deze 'voortijdige ontbinding zijn echter behoorlijk wat voorwaarden ontbonden, zo legt de ict-jurist uit. Dat geldt overigens ook wanneer de afnemer de opleverdatum wel afwacht.
Dit alles komt doordat rechters volgens de ict-jurist 'in het geval van ict-overeenkomsten een eigen invulling hebben gegeven aan het wettelijke systeem voor nakoming en tekortkoming.' Daardoor kunnen juristen volgens Van der Putt hun cliënten pas goed verdedigen wanneer ze op de hoogte zijn van de 'relevante jurisprudentie'. 'Anders kan plotsklaps blijken dat fatale termijnen toch niet fataal zijn, ingebrekestellingen geen rechtsvervolg hebben of dat een nakomingsbevestiging soms niet volstaat.'
Verzuim aantonen is lastig
De ict-jurist geeft in zijn artikel een aantal waarschuwingen aan medejuristen en afnemers. Ten eerste moet een opdrachtgever tijdig actie ondernemen. 'Als een afnemer niets doet wanneer de leverancier te kort schiet, kan hij het recht verliezen om zich later nog op tekortkoming te beroepen.'
Ten tweede moet dit op de juiste manier gebeuren. De opdrachtgever moet 'verzuim' aantonen, wil hij in zijn recht staan. Maar: 'Hoofdregel is dat verzuim pas intreedt nadat de schuldenaar een herkansingspoging heeft gehad en opnieuw heeft gefaald.'
Belangrijk is bovendien dat bij die herkaningspoging een termijn wordt gesteld. Van der Putt haalt een uitspraak aan van een rechter uit 2009 in een geschil tussen Fortis en ict-dienstverlener Raindrop, waarbij de rechter twee door Fortis gestuurde brieven niet wil aanmerken als ingebrekestellingen, omdat er geen termijn in wordt gesteld.
SAP
Daarnaast moet de ingebrekestelling 'de verweten gebreken met voldoende detail te beschrijven.' Van der Putt verwijst daarbij naar een rechtszaak van Waterdrinker tegen SAP. Omdat de kamer- en tuinplantenleverancier in een brief niet specifieert wat exact het probleem is, weigert de rechter 'ingebrekestelling' vast te stellen.
De opdrachtgever schrijft volgens Van der Putt namelijk aan SAP dat 'de geconstateerde tekortkomingen mogelijk nog te verhelpen zijn, maar dat Waterdrinker wegens een gebrek aan vertrouwen kiest voor beëindiging van het project.' De rechter ziet daarom geen aanleiding om te constateren dat er sprake is van 'een blijvende onmogelijkheid van nakoming'.
CasperD, 12-01-2011 15:00: Het zal me aan mijn aars oxideren welke kleur de rubber rond de fuseekogel heeft. Maar als ik een auto bestel met airco en die zit er bij levering niet in, dan heeft een of andere pipo zijn werk niet goed gedaan. En als de kleur van de lak anders is dan besteld, is er gewoon niet aan de voorwaarden van het contract voldaan. Daar heb je nu eenmaal een contract, een PID enz. voor.
Zoals met elk project gaat het niet om gemierenneuk, maar enorme tijd- en budgetoverschrijdingen zijn dermate basaal dat je daar echt niet meer van kan spreken.
En dat van de overheid was maar een voorbeeld.
Helaas is dit artikel gebaseerd op de werkelijkheid zoals die in ‘onze’ ICT wereld de overhand heeft.
Overeenkomsten zijn heel vaak standaard ICT-Office contracten (inspanningsverplichting en fitness for specification) terwijl als onderwerp van aankoop de licenties van de software met aanvullend maatwerk worden genoemd. Als bijlage en beschrijving van de leveringsverplichting wordt doorgaans de offerte van de leverancier gebruikt.
Op deze manier is het voor de leverancier heel goed mogelijk om met een goed gevoel van comfort een scherpe aanbieding te doen, om zodoende de concurrentie voor te blijven.
Voor de afnemer is een dergelijke constructie desastreus. En wel om de volgende reden.
1. De verplichting van de leverancier beperkt zich tot het doen van een inspanning (uren budget);
2. De leveringsverplichting is omschreven in ‘termen’ van de leverancier, die daar een eigen uitleg aan kan geven;
3. Zodra hij vindt dat de specificaties zijn gehaald, ligt de bewijslast van eventuele ontbrekende of foutieve onderdelen bij afnemer (door de inspanningsverplichting).
Directies van bedrijven die grote ICT-projecten wensen te gaan doorvoeren, doen er goed aan om passende overeenkomsten (maatwerk) op te (laten) stellen. Randvoorwaarden waar een passende overeenkomst aan moet voldoen zijn o.a.:
1. Resultaatverplichting (fit for use of fit for purpose);
2. Onderwerp van levering moeten de overeengekomen specificities zijn (géén verwijzing naar producten van de leverancier, maar naar bedrijfsprocessen van de afnemer);
3. Heldere afspraken over wijzigingen, escalaties, acceptaties, projectmanagement;
Verder moet de afnemer bij voorbaat besluiten welke twee van de volgende projectparameters fixed en onveranderbaar zijn: geld, tijd, functionaliteit.
Lopende het project dient de afnemer een projectmanager aan het project toe te kennen, die instaat is om de leverancier volgens de afspraken te managen. Managen op de projectparameters waarvan er één als flexibel is aangemerkt. Alleen op die manier wordt de kans op falen geminimaliseerd.
Dit heeft niets met IT of leverancierscondities te maken, maar alles met het volgens van rechtsregels die gelden voor alle soorten dienstverlening (sterker: voor alle leveringen, producten en diensten) Advocaten die hierover klagen moeten zich eens afvragen of voor een door hen opgesteld contract “fit for purpose” wordt gegrandeert en of de advocaat z’n honorarium terugbetaald als een contractonderhandeling uitloopt.
Voorbeelden zijn leuk; neem die auto zonder de airco. Je moet dan wel melden dat de airco ontbreekt; de autodealer kan niet op afstand zien of de airco ontbreekt of de gebruiker een instellingsfout maakt of zelfs met ramen open rijdt. Specificeren wat er mankeert is kennelijk net zo moeilijk voor afnemers als speciferen wat je wilt hebben. Goed opdrachtgeverschap is een schaars goed.
Dit kan alleen als volgt worden opgelost en ingebed binnen de competentiegebieden van de PM.
Contracten: Contracten dienen waterdicht te zijn. Er mag geen enkele ruimte bestaan tussen afspraken. Aangezien het project in z’n geheel bestaat uit het maken van afspraken, dienen de afspraken helder beschreven te zijn. Het moet zo zijn dat een rechter op het contract kan rechtspreken. Er mogen geen situaties ontstaan dat het er niet staat, dat er veronderstellingen zijn, aannames of ‘ik bedoelde’, want dan geef je ruimte voor speculaties en misverstanden. Een contract hoort een weergave te zijn van de beoogde projectuitvoering. Bij geschil moet het dan ook puntsgewijs aantoonbaar zijn waar de afwijkingen zijn opgetreden en wie daar een specifieke rol in heeft gehad.
Voorbeeld het verhaal van Hans Brinkers
Wie kent niet het verhaal van Hans Brinkers, die Nederland redde van de verdrinkingsdood door zijn vinger in het gat in de dijk te steken. Een toevalstreffer? Een goed geleid project? We weten het niet, we hebben allemaal wel vernomen dat het contractueel heel wat voeten in de aarde had. Voordat je het gat kunt dichten, moet de dijk gebouwd worden. In het verleden was er altijd veel hulp van goedwillende burgers; goede bedoelingen, die niet altijd goed uitpakten. Als iemand de helpende hand uitsteekt, doe je niet moeilijk. Je krijgt dan een inspanningscommitment, en geen resultaatsverplichting. Dat lijkt aardig, maar kan lastig worden als de dijk het lang moet uithouden. Toegegeven, bij de noodreparaties mag ook iedereen meehelpen. De les: stel kwaliteitseisen aan de projectmedewerkers onder de contractkop ‘organisatie’. De dijk is gebouwd met verschillende materialen. Wie die geleverd heeft, is niet duidelijk. Iedereen die een vrachtje over heeft brengt dat. Na enige tijd gaan de basaltblokken schuiven over het te natte zand; de inkoop was niet in de haak. De les: schrijf een specificatie en neem in het contract de afname-inspectie op. Na oplevering is iedereen blij; het natte gevaar is ingedamd. Over verborgen gebreken zijn geen afspraken gemaakt. Na jaren beginnen de gebreken. Een gildelid heeft gesjoemeld. De dijk zakt sneller in dan verwacht. Reparaties ten laste van de opdrachtgever is de enige oplossing. Het gildelid is reeds gevlogen. De les: maak afspraken over termijnen en prestaties. Met een garantie en bankgarantie of inhouding kun je veel geld besparen. Er is jarenlang doorgeploeterd zonder contract, steeds weer wat verzakt en opgelapt. Er is geen onderhoudscontract, want dat is duur. We laten dijkwachters regelmatig inspecteren. Die enkele keer dat het mis gaat, is toch in een andere eeuw. Dat risico hoef je niet te managen. De bevolking is eraan gewend dat het bij stormvloed maar net goed gaat. Het grote gevaar is echter rustig aan het werk. Van binnen rot de dijk onzichtbaar weg. Het water vreet zich een weg.
Dan komt Hans Brinkers langs. Het was hem al opgevallen dat het gras op de dijk een bruine plek kreeg. Hij dacht ‘zeker graszaad gekocht zonder specificatie en garantie’. Nu ziet hij een straaltje uit de dijk komen. Het zand spoelt mee met het water. Eindelijk wordt Brinkers wakker en steekt bij gebrek aan ander gereedschap zijn vinger in de dijk. Hij heeft geen communicatieplan opgesteld voor als hij in moeilijkheden komt. De gsm ligt thuis, want hij zou alleen even zijn vaste wandelingetje maken. Uren later gaat mevrouw Brinkers samen met de buurman op zoek. Als ze hem vinden, zegt Brinkers alleen maar: “een gat in de dijk”. Dat er iets moet gebeuren is duidelijk, ook voor de buurman, een ervaren projectmanager. Die heeft ooit een boekje gelezen over projecten en contracten en zegt: “Even wachten, ik moet thuis naslaan wat ik nu moet doen. Dat kost nu wat tijd, maar levert een veel beter resultaat op. Tot straks.
John Roos
06 81430098
Rare conclusie van John. Wat nou fit for use? Moet de klant dus wel eerst in detail specificeren welk beoogd gebruik. Fit for purpose; idem dito. Verschuil je niet achter juridische kwalificaties, maar zeg wat je wilt zodat de leverancier kan aangeven of hij dat wil en kan leveren en hoe je samen met goede communicatie zorgt dat projecten goed verlopen. Evt met positieve prikkels om succes te stimuleren (geld of pizzas voor teams etc). Overigens…de meeste projecten lopen goed af. Zou advocaat Polo geen tekstverwerker gebruiken (met vast heel veel bugs en regelmatige fixes) dan zou hij geen artikelen meer schrijven. Of heeft hij nog een typemachine?
Enige oplossing voor de crisis in ICT-projecten is vertrouwen. Net zo goed als iemand ook een advocaat in huurt op grond van vertrouwen (door referenties, voorgaande ervaring), of naar een arts gaat op grond van vertrouwen, zo zouden ICT-bedrijven ingehuurd moeten worden.
Zo’n ICT-bedrijf kan vertrouwen wekken door zo snel en zo vaak mogelijk goed werkende software op te leveren. Als een bedrijf niet binnen een maand goed functionerende software kan opleveren, is er geen vertrouwen. Dat voorkomt dat na een jaar of vele jaren van worstelen niks is opgeleverd. Dat zorgt er ook voor dat zogenaamde ‘waterdichte’ contracten ook niet opgesteld hoeven te worden – van zulke contracten worden alleen juristen beter.
De ‘auto-bestellen’ metafoor wordt er ook weer bijgehaald in sommige comments. Software IS niet het bouwen van een auto. Software is het ONTWERPEN van een auto. Daar zit een wereld van verschil tussen.
Ik hoor wel iets doorschemeren over kwaliteit, maar daar begint het wel mee. Eerst goede requirements opstellen (wat toch best moeilijk blijkt te zijn in de praktijk) Als het project gstart is tussentijds controleren of deze requirements goed zijn doorvertaald in tussenproducten en daarna gestructureerd testen.
Uiteraard is een goede fasering en een goede relatie met de betrokken partijen belangrijk, maar hoe vaak gebeurt het niet dat er door voortschrijdend inzicht niet wordt voldaan aan de gestelde wensen en eisen van de opdrachtgever. Dat moet dus goed gemanaged worden. Ik heb zelf meegemaakt dat bij een project (in verre vorm van escalatie werd gediscusieerd over de punt bij duizendtallen dat niet was gespecificeerd in de requirements. Het projectbudget was ongeveer gedubbeld en deelname in dat project is dan echt niet leuk meer.
Pas de laatste jaren wordt steeds duidelijker dat management van Requirements een must is. Probleem daarbij is dat projecten, waarvan het resultaat veelal moet aansluiten op bestaande omgevingen, tegen het gegeven aanlopen dat, ondanks dat de Requirements voor die projecten goed zijn beschreven, er sprake is van onvoldoende zicht en grip op die bestaande omgeving. Domweg omdat in het verleden de zaken niet goed zijn beschreven, noch gedocumenteerd. In projecten krijg je dan te maken met het geldverslindende fenomeen Voortschrijdend Inzicht. Veel organisaties doen er daarom goed aan te investeren in het beschrijven van de huidige situatie en vast te leggen op welke fronten deze wel voldoet en op welke fronten niet. En dat kan weer alleen goed worden gedaan op basis van duidelijke processen en goed functionerend informatiemanagement. Kortom: terug naar de basis, de regie in handen van de business en ICT als kritische leverancier of service organisatie die duidelijke eisen stelt aan de beginsituatie en aan de vraagstelling waarvoor zij met oplossingen moet komen.
@John, ik vrees dat jouw werkelijkheid een beetje anders is dan de onze. Ik heb geen enkel miljoenencontract gezien zonder maatwerk op verzoek van inkoopmanagers, projectmanagers, enzovoorts van de opdrachtgevers. Ook als het om slechts enkele tonnen gaat, dan nog zie ik steeds weer maatwerkcontracten.
Volgens mij haal je een MKB-situatie en een grootbedrijf/overheid-situatie door elkaar. Grote afnemers hebben hun eigen standaardcontracten op basis van hun inkoopvoorwaarden.
Probeer maar eens bij Philips, Essent of een ministerie zaken te doen via alleen een standaard ICT~Office contract. Dat luk je niet. Bij publieke en private tenders vragen de uitbestedende partijen altijd aan de inschrijvers in hoeverre zij aan hun inkoopvoorwaarden kunnen voldoen.
De standaard ICT~Office contracten worden aan het MKB en kleine organisaties aangeboden, maar ook die zijn meestal slim genoeg om die aan te laten passen.
Wat wel belangrijk is dat vanaf het begin een projectmanager van de opdrachtgever meewerkt aan het opstellen van de specificaties en van het contract. Juristen en NEVI inkoopmanagers hebben geen verstand van het meten van de vorderingen bij een ICT-contract. Jouw voorstel van “Lopende het project dient de afnemer een projectmanager aan het project toe te kennen” is dus verkeerd. Dan kan het al te laat zijn.
Gerbrand van Dieijen, 14-01-2011 09:55 De auto metafoor wordt erbij gehaald dat partijen zich gewoon moeten houden aan de specificaties en de afspraken.