Hoewel de procedurele afspraken over meerwerk vooraf meestal goed gemaakt worden, gaat het in de praktijk vaak mis. De terugkerende vraag is steeds of bepaalde functionaliteit wel of niet begrepen was in de eerder opgestelde specificaties of aanwezig mocht worden verondersteld in de aangeschafte standaard pakketten.

Case: Wel of geen meerwerk

Hoewel de procedurele afspraken over meerwerk vooraf meestal goed gemaakt worden, gaat het in de praktijk vaak mis. De terugkerende vraag is steeds of bepaalde functionaliteit wel of niet begrepen was in de eerder opgestelde specificaties of aanwezig mocht worden verondersteld in de aangeschafte standaard pakketten. Gelijkwaardige partijen, die vaardig communiceren en ook oog hebben voor het belang van de andere partij, komen er samen wel uit. Lukt dat niet dan brengen zij hun verschillen van mening terug tot de essentie en leggen dat voor aan een mediator, bindend adviseur of arbiter. Dat is de goedkoopste en meest volwassen manier om een conflict op te lossen. In die gevallen waar dit niet gebeurt, ziet men vaak enigszins naïeve opstellingen aan beide kanten ter zake van het meerwerk. De leverancier claimt meerwerk omdat hij zoveel extra uren heeft moeten besteden. De opdrachtgever wijst alle meerwerkclaims af, omdat hij uiteindelijk niets extra wil, dan bij de start van het project, te weten een goed werkend informatiesysteem.

Staan de partijen vervolgens voor de rechter, arbiter of bindend adviseur dan zijn zij vaak teleurgesteld dat deze de in hun ogen uiterst redelijke eisen niet kan honoreren. Hoe bewijs je achteraf dat er sprake is van meerwerk? Sommige ICT-leveranciers overleggen verschillende versies van de source code om aan te tonen dat de software is gewijzigd. De reactie van de opdrachtgever is dan dat die wijzigingen nodig waren om fouten op te lossen. In de meeste zaken wordt de ICT-leverancier opgelegd om met hardere bewijzen te komen voor het geclaimde meerwerk.

Case: Fouten in een software pakket

Pleegt een ICT-leverancier wanprestatie, wanneer zich fouten in de opgeleverde software bevinden? Wanneer dat de definitie van wanprestatie is, dan zal het lastig zijn om nog een automatiseerder te vinden die geen wanprestatie pleegt. Het gaat eerder om de aard en omvang van de fouten. In conflicten van deze aard, die aan de SGOA worden voorgelegd, ligt de bewijslast bij de opdrachtgever, die moet aantonen, dat de fouten, die de leverancier ontkent, echt bestaan, en zodanig ernstig zijn, dat daarmee niet (tijdelijk) te leven viel c.q. valt. Fouten van cosmetische aard kunnen in het algemeen geen reden zijn om de overeenkomst te ontbinden. In de loop der jaren wordt wel anders tegen fouten aangekeken. Vroeger was het gebruikelijk dat de software werd gegarandeerd voor uitsluitend die gevallen die in de acceptatietest voorkwamen. Wanneer de (standaard) software eenmaal geaccepteerd was, waren de fouten ook het eigendom van de klant. Het verbeteren daarvan werd normaliter in rekening gebracht. Tegenwoordig vinden we dat fouten in standaard pakketten gratis door de leverancier moeten worden opgelost. In de praktijk is het usance dat de klant een vast bedrag betaalt voor onderhoud van de software, waaronder tevens valt het verbeteren van fouten. Onderstaand volgen een aantal verschillende praktijkgevallen uit de ICT-praktijk.