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'.
Ik snap het niet. Er is voor ieder project toch een contract opgesteld? Waarin duidelijke grenzen voor tijd, budget en resultaat worden opgenomen? Als je daar overheen gaat, dan weet je: dan doe je iets niet goed. Les een van projectmanagement gaat over het opdelen van projecten (staging) om de afzonderlijke delen zoveel mogelijk in de hand te houden. Kennelijk worden tijd- en budgetoverschrijdingen niet gemeld of opgelost in een projectdeel maar meegenomen naar het volgende. Hetgeen helemaal in gaat tegen alles wat we geleerd hebben. Vind je het dan gek als elk project uit de hand loopt?
Kennelijk is aanbesteding bij overheidsprojecten tegenwoordig iets van zo laag mogelijk inschrijven, want als het uit de klauwen loopt past de overheid toch wel bij.
@Henk:
Welkom in de real-world!
Bij een project van een paar duizend euro zijn specificaties nog sluitend op te stellen, maar de kosten en complexiteit van dit soort systemen zijn te groot om een sluitende beschrijving te hebben.
Als je specificaties en contracten 1:1 gaat volgen wordt niemand blij. De klant krijgt een waardeloze bende omdat er vast ergens een functionaliteit vergeten is te beschrijven. (Oeps, een order kan niet meer gewijzigd worden) En de leverancier is enorm veel tijd kwijt om te beschrijven wat standaard is (Met het pijltje omhoog kan de waarde van het aantal met 1 verhoogd worden…)
Uiteindelijk komt hier een middenweg in, en dan is het lastig om te bepalen wat een “ordersysteem” nu exact inhoud voor de klant en leverancier. Zeker als er tientallen koppelingen en tientallen mensen betrokken bij zijn.
Jij koopt jouw auto natuurlijk ook met de complete specificatie erbij: TERUG! de fuseekogelrubber is grijs ipv zwart… Ik koop zelf een auto die rijdt, omdat ik niet 10x zoveel voor een auto wil betalen omdat de volledige specificatie moet worden doorgenomen voordat ik teken.
O ja, het gaat hier trouwens helemaal niet over overheidsprojecten, maar in het algemeen.
Een belangrijke vraag is natuurlijk in hoeverre het altijd duidelijk is dat de dienstverlener faalt. Ik ken voorbeelden waarbij een contract werd gesloten maar de opdrachtgever onvoldoende duidelijk kon aangeven wat hij nodig had. Verder geven opdrachtgevers vrijwel nooit de gehele sturing uit handen aan een leverancier en zullen zijn zelf ook zaken moeten regelen.
Eigenlijk zijn met name aanbestedingen hierin schijnzekerheid. De klant kan nooit exact beschrijven wat hij wil hebben en de leverancier kan nooit met zekerheid beloven dat hij dit kan leveren binnen de beoogde tijd. En toch blijven wel telkens doen alsof dat wel het geval is, terwijl er toch diverse voorbeelden zijn die het tegendeel bewijzen.
Een mooi voorbeeld is het ICT project ‘Joint Strike Fighter’… Uitstappen ho maar, kan niet meer, is de leverancier in gebreke?? Ik betwijfel het.
Op kleinere schaal worden ook projecten gestart waarbij de allernieuwste applicaties en systemen moeten worden geïmplementeerd, waarvan niet eens de meest basale bugs en comptabiliteit vraagstukken bekend zijn (die worden alleen bekend door je op nieuw terrein te gaan bewegen).
Wel denk ik dat de commerciële kant van de markt vaak nalaat op die risico’s in te gaan naar een klant. En veel opdrachtgevers willen dat ook helemaal niet horen, en zo draait de cirkel lekker rond…..
Het falen is doorgaans niet zo moeilijk te bewijzen, anders moeten alle partijen hebben zitten te slapen. Als het mis gaat, dan ligt dat meestal aan beide kanten en is er ook (directe en indirecte) schade aan beide kanten. De vraag hoe groot de schade aan beide kanten is en hoe de schuld verdeeld zou moeten worden, is meestal moeilijker te beantwoorden. Daar kom je alleen uit door vanaf het begin helder te communiceren. Hoe slechter je dat doet, hoe groter de totale schade.
Zeker als partijen tegenover elkaar zijn komen te staan, werkt men te veel vanuit de eigen denkwereld. Maar contracten gelden niet alleen voor het moment dat de samenwerking leverancier-klant nog goed verloopt, maar juist ook voor als het mis gaat. Tezamen met de wetgeving (die soms leidend en soms aanvullend is) bepalen zij hoe gehandeld moet worden om nog meer schade te voorkomen.
De aanbevelingen van Van der Putt zijn goed. Ga er nooit vanuit dat de rechter dezelfde denkbeelden heeft over redelijkheid en billijkheid als jijzelf.
Ik moest weer eens denken aan een oud project waar ik bij betrokken was.
Daar werd getest met een stopwatch in de hand. En ook als de oplevering te laat was kwam er een ton boete per dag bij.
Heel vreemd genoeg liep dat project redelijk soepel.
Ik kan boekdelen vol schrijven met schrijnende voorbeelden van falende ICT-projecten bij de overheid. Hiermee gaan miljoenen verloren, zonder dat daar iemand voor verantwoordelijk wordt gesteld.
als ik contraexpertises doe kijk ik mede naar de gevolgde ontwikkelaanpak. wat deed men eerst, wat deed men na elkaar dan wel naast elkaar. en spiegel dat een door veel ervaring ontwikkeld referentiekader.
dan is het niet meer moeilijk om aan te tonen waar een project begon te ontsporen. voorbeelden van grote projecten en ook dat referentiekader heb ik beschikbaar. en datzelfde referentiekader gebruik ik ook proactief.
dagblad trouw heeft al eens enige woorden gewijd aan deze aanpak, maar de doorbraak moet nog komen.
Gezamenlijk het probleem te lijf gaan… dat voorkomt een falend project. En waarom vragen afnemers in de IT eigenlijk niet om garanties?
Iedereen met niveau vanaf prince2 foundation kan een project opzetten dat niet kan falen.
Het gaat erom om fasen te plannen waarbij je na afloop de tussenresultaten steeds tegen de Business Case toetst.
Het is de taak van de Project Manager om dit plan op te stellen en van de Business om hiervoor mandaat te geven. Het gaat mis als minstens een van die partijen prutser is en de ander dat accepteert (in feite dus beide prutser 🙂