In het vorige deel van deze blogreeks hebben we de juridische grondslagen van ‘verkuttificatie’ besproken. Maar wat gebeurt er als de problemen niet sluipend, maar acuut ontstaan door een mislukt automatiseringstraject? In dit blog duiken we in de complexe problematiek van projectfalen in de IT-sector. We leggen de focus op de systeemfouten die vaak de oorzaak zijn van deze mislukkingen en analyseren de juridische risico’s die inherent zijn aan de populaire agile-methodologie.

IT norm

1. De systemische aard van projectfalen

Mislukte automatiseringsprojecten vormen al decennialang een hardnekkig probleem in de IT-sector. De faalkosten zijn aanzienlijk en leiden tot verspilling van miljarden euro’s per jaar, zowel in de private als in de publieke sector. Vooral grote overheidsprojecten in Nederland lijken systematisch te falen, met voorbeelden als de ov-chipkaart en C2000, maar ook in de private sector zijn IT-projecten niet zeker van succes. De oorzaken zijn vaak systemisch en liggen niet enkel bij de leverancier, maar ook bij de opdrachtgever. Problemen ontstaan door een gebrek aan gedeelde visie, onduidelijke doelstellingen, onrealistische tijdlijnen, en een tekort aan uitwisseling van specialistische kennis bij de partijen. De juridische gevolgen van dergelijke mislukkingen kunnen verstrekkend zijn. Grote rechtszaken, zoals die tegen Capgemini, demonstreren dat mislukte projecten kunnen resulteren in schadevergoedingen van miljoenen euro’s. De juridische procedures zijn echter vaak complex, kunnen soms jaren duren en hebben een onzekere uitkomst.

2. Agile in het juridisch vizier

De agile-methodologie, met zijn flexibiliteit en snelle iteraties, wordt vaak gezien als een oplossing voor het falen van traditionele IT-projecten. Juridisch gezien introduceert deze aanpak echter een nieuw spectrum van risico’s. Waar de traditionele watervalmethode uitgaat van een gedetailleerd programma van eisen, kent een agile-project geen vooraf vastgelegde, gedetailleerde eindspecificatie. Dit is de belangrijkste juridische valkuil. Wanneer een opdrachtgever niet tevreden is met het opgeleverde werk, is het extreem lastig om juridisch aan te tonen dat de leverancier tekort is geschoten, simpelweg omdat er geen concrete afspraak was over wat er precies geleverd moest worden, of dat hij daar een eigen aandeel in had. Zonder een duidelijke specificatie kan de opdrachtgever niet bewijzen dat het geleverde niet voldeed, waardoor een claim op basis van wanprestatie vaak afgewezen zal worden.

Bovendien leidt de aard van de samenwerking in een agile-project tot een verschuiving van de aansprakelijkheid van de leverancier naar die van de afnemer. De nauwe, iteratieve samenwerking tussen partijen creëert een gedeelde verantwoordelijkheid, waarbij de aansprakelijkheid van de leverancier is beperkt tot de correcte uitvoering van het proces en het nakomen van zijn inspanningsverplichtingen. De juridische strijd draait dan niet langer om de vraag wat er is opgeleverd, maar om de vraag hoe het proces is verlopen. De juridische focus verschuift van het eindproduct naar de kwaliteit van het proces. Dit betekent dat een succesvolle juridische claim zich moet richten op tekortkomingen in het proces, zoals ontoereikend projectmanagement, een gebrek aan transparantie over de sprintresultaten, of het nalaten van de leverancier om de opdrachtgever te wijzen op risico’s. De bewijslast ligt voor de afnemer dan bij het falen van de leverancier om zijn rol als expert correct te vervullen, in plaats van de afwezigheid van een specifieke functionaliteit.

De flexibiliteit van agile, die bedoeld is om snel op veranderende behoeften te reageren, kan echter ook een katalysator zijn voor het proces van ‘verkuttificatie’. Waar agile-teams de flexibiliteit gebruiken om de gebruikerservaring te verbeteren en zich te richten op het creëren van waarde, kan de methode ook worden ingezet om continue, kleine aanpassingen (“twiddling”) aan het product door te voeren met als enig doel het verhogen van de winst. Omdat een agile-project geen vooraf gedetailleerde eindspecificatie kent, biedt het de leverancier de contractuele ruimte om geleidelijk waarde te onttrekken, in plaats van deze toe te voegen. In een omgeving waar de focus verschuift van het oplossen van gebruikersproblemen naar het voldoen aan de eisen van aandeelhouders, kan agile worden misbruikt om “features” te implementeren die “bewezen onhandig” zijn maar die wel voldoen aan kortetermijndoelen. De verantwoordelijkheid voor het succes van het project verschuift hierdoor subtiel van het leveren van een kwalitatief eindproduct naar de succesvolle uitvoering van het proces, wat de weg effent voor de “extractieve fase” van verkuttificatie. Het juridische risico voor de klant is dat de flexibiliteit van agile wordt ingezet tegen diens belangen, terwijl de juridische middelen om hiertegen op te treden beperkt blijven tot het aantonen van een gebrekkig proces in plaats van een falend product.

3. De rol van contractuele bepalingen

Vanwege de inherente juridische onzekerheden van agile projecten, is het contract een essentieel instrument om risico’s te mitigeren. Een goed opgesteld agile contract moet het gebrek aan gedetailleerde specificaties ondervangen met goede afspraken over het proces. Essentiële bepalingen omvatten een afbakening van de ‘vision’ en de scope in grote lijnen, vaak vastgelegd in ‘epics’. Ook is het aan te raden een ‘checkpoint’-fase in te bouwen, een initiële testperiode waarin de samenwerking wordt geëvalueerd en de definitieve prijs, scope of planning kan worden bijgesteld.

Verder zijn duidelijke procedures voor change management cruciaal. De flexibiliteit van agile moet worden gekanaliseerd in een proces waarin wijzigingen in eisen, scope en kosten transparant worden beheerd, terwijl dat niet moet leiden tot een onjuiste voorstelling van zaken bij het aangaan van de overeenkomst. De overeenkomst moet tevens gedetailleerde clausules bevatten over aansprakelijkheid en de vergoeding van schade. Een andere belangrijke contractuele bepaling betreft het intellectueel eigendom (IE). Zonder expliciete afspraken blijft het auteursrecht op op maat gemaakte code bij de ontwikkelaar. Een opdrachtgever die volledige controle wil over de broncode, moet een duidelijke overdrachtsclausule opnemen die de IE-rechten van de leverancier en diens medewerkers overdraagt – óók indien slechts een beperkt aantal sprints worden afgenomen (al dan niet wegens vroegtijdige beëindiging op welke wijze dan ook) dat niet leidt tot een eindproduct.

Lees hier de andere delen van deze blogserie:

Ontdek hoe jouw onderneming zich kan beschermen tegen verborgen risico’s. Wouter Dammers, advocaat IT-recht bij LAWFOX, is specialist en biedt strategisch juridisch advies om u te beschermen tegen de valkuilen van ‘verkuttificatie’, mislukte automatiseringen en onduidelijke contracten. Neem vandaag nog contact met ons op voor een juridische due diligence, een contract-audit of een adviesgesprek. Samen waarborgen we de toekomst van jouw technologische roadmap.

Naar blog overzicht

IT norm

Mannelijke advocaat met bril, donkere kleding, oranje achtergrond. LAWFOX

Wouter Dammers / Over de auteur

Als oprichter van LAWFOX combineert Wouter Dammers cum laude juridische expertise met een diepe technische achtergrond. Hij is de advocaat voor ondernemers die de ‘uitleg-fase’ willen overslaan. Wouter snapt direct wat uw API, blockchain-protocol of IT-stack doet. Hij staat bekend als de juridische rebel die strijdt tegen technologisch machtsmisbruik en ‘vendor lock-in’. Met baanbrekende successen, zoals het eerste NFT-beslag in Nederland, bewijst hij dat het recht ook in Web3 gehandhaafd kan worden. Wouter biedt “Champions League kwaliteit in spijkerbroek”: topniveau advocatuur, maar dan toegankelijk, direct en zonder poeha.