Scope en specificatie bij ICT-projecten: voorkom dat het misgaat

In de praktijk blijkt dat zulke problemen vaak niet ontstaan door technische uitdagingen, maar door onduidelijke afspraken over de scope en specificaties van het project. Wanneer het tot een geschil komt, beoordeelt de rechter wat partijen precies zijn overeengekomen, en juist bij vage afspraken leidt dat tot onvoorspelbare uitkomsten.

Wat is de scope van een ICT-project?

De scope beschrijft welke werkzaamheden, functionaliteiten en resultaten onderdeel zijn van het project. Anders gezegd: wat levert de softwareleverancier precies op en wat valt buiten de opdracht?

​Een duidelijke scope vermeldt in ieder geval:

• de werkzaamheden die de leverancier uitvoert;
• welke functionaliteiten worden ontwikkeld;
• welke resultaten worden opgeleverd;
• de taken die bij de opdrachtgever liggen;
• welke afhankelijkheden en uitgangspunten gelden;
• wat uitdrukkelijk buiten de opdracht valt;
• hoe partijen het resultaat testen en accepteren.

In veel ICT-projecten blijken opdrachtgever en leverancier verschillende verwachtingen te hebben. Een opdrachtgever gaat ervan uit dat een bepaalde functionaliteit onderdeel is van de opdracht, terwijl de leverancier deze beschouwt als aanvullend werk. Zolang het project volgens planning verloopt, blijft dat verschil vaak onopgemerkt. Zodra tijdsdruk of budgetoverschrijdingen ontstaan, leidt dit regelmatig tot een geschil. Een ICT-contract moet daarom niet alleen beschrijven wat erin zit, maar ook wat erbuiten valt.

Waarom een duidelijke scope en goede specificaties onmisbaar zijn

Bij softwareontwikkeling vormen de specificaties de basis van het project. Hierin staat wat de software moet kunnen, welke prestaties worden verwacht en aan welke eisen het eindproduct moet voldoen. Toch zien wij in ICT-contracten regelmatig beschrijvingen die te algemeen zijn. Begrippen als "gebruiksvriendelijk", "toekomstbestendig" of "volledig geïntegreerd" klinken aantrekkelijk. Maar zij bieden weinig houvast wanneer discussie ontstaat over de vraag of de software voldoet aan de afspraken.

Daarom is het verstandig om eisen zoveel mogelijk concreet en meetbaar vast te leggen. Hoe duidelijker de specificaties, hoe eenvoudiger partijen later kunnen vaststellen of de software correct is ontwikkeld en opgeleverd.

Hoe legt de rechter de scope van het project uit?

​Wanneer partijen van mening verschillen over hun afspraken, legt de rechter het contract uit aan de hand van de Haviltex-maatstaf. De Hoge Raad heeft in deze uitspraak bepaald dat niet alleen de letterlijke tekst van het contract telt. Ook de omstandigheden en wat partijen redelijkerwijs van elkaar mochten verwachten, spelen een rol. Een duidelijke contracttekst kan daarbij veel gewicht hebben. Hoe concreter de scope en specificaties zijn vastgelegd, hoe minder ruimte bestaat voor discussie over de uitleg.

Agile softwareontwikkeling vraagt om duidelijke afspraken

Veel softwareprojecten worden tegenwoordig uitgevoerd volgens een agile werkwijze. Daarbij wordt de software stapsgewijs ontwikkeld en kunnen nieuwe wensen gedurende het traject worden toegevoegd. Agile werken past op het eerste gezicht ongemakkelijk in traditionele contractvormen. Kenmerk van de scrum-methode is dat het eindresultaat niet vooraf volledig vaststaat, maar gaandeweg wordt uitgewerkt in korte sprints. Dat biedt flexibiliteit, maar creëert ook juridische risico's als de contractuele afspraken niet meegroeien.

Bij agile softwareontwikkeling zijn duidelijke afspraken noodzakelijk. Denk bijvoorbeeld aan afspraken over de doelstellingen van het project, de prioritering van functionaliteiten, acceptatie van sprints, de gevolgen van wijzigingen voor planning en budget en hoe partijen nieuwe wensen beoordelen. Wanneer deze afspraken ontbreken, ontstaat al snel discussie over de vraag of sprake is van een aanvulling binnen de opdracht of van meerwerk.

​Voorkom discussie over meerwerk

Vrijwel ieder ICT-project verandert gedurende de uitvoering. Nieuwe inzichten, gewijzigde bedrijfsprocessen of aanvullende wensen kunnen aanleiding zijn om de oorspronkelijke opdracht aan te passen.

​De meest voorkomende valkuil voor leveranciers is dat zij extra werkzaamheden uitvoeren zonder daarover schriftelijke afspraken te maken. Weigert de opdrachtgever later te betalen, omdat het werk volgens hem al bij de opdracht hoorde? Dan kan het voor de leverancier lastig zijn om de aanvullende vergoeding betaald te krijgen. Dit risico kun je beperken met een contractuele wijzigingsprocedure, ook wel een changeprocedure of RFC-proces genoemd.

​Leg daarom in het ICT-contract vast wanneer de scope wijzigt, wie de gevolgen voor planning en kosten beoordeelt, wanneer de leverancier extra kosten mag rekenen en hoe partijen wijzigingen vastleggen en goedkeuren.

​Een goede changeprocedure geeft zowel de opdrachtgever als de softwareleverancier duidelijkheid. De opdrachtgever behoudt controle over het budget en de planning. De leverancier weet welk werk binnen de oorspronkelijke opdracht valt en voor welk werk hij extra kosten mag rekenen. Zo voorkomt de procedure discussies over meerwerk en vertraging.

Pak iedere wijziging daarom als volgt aan:

1. beschrijf de gewenste wijziging;
2. stel een RFC op;
3. beoordeel de gevolgen voor de planning en kosten;
4. leg vast of de wijziging binnen of buiten de bestaande scope valt;
5. vraag de opdrachtgever om schriftelijk akkoord;
6. begin pas daarna met het meerwerk.

Dat kan tijdens een lopend project bureaucratisch voelen, maar biedt de sterkste bescherming als later een geschil ontstaat.

Acceptatie van software: maak het meetbaar

Als leverancier wil je een duidelijk moment waarop het project formeel is opgeleverd en geaccepteerd. Zonder dat moment blijft de discussie over "gereed of niet" eindeloos voortduren. Een goed acceptatieproces bevat concrete testcriteria, een redelijke testtermijn en een regeling voor stilzwijgende acceptatie. Bijvoorbeeld: als de opdrachtgever niet binnen een bepaalde termijn gemotiveerd afkeurt, geldt het werk als geaccepteerd.

Spreek vooraf af wie accepteert, op basis van welke criteria, en binnen welke termijn. Leg testresultaten vast en laat de opdrachtgever schriftelijk bevestigen wanneer een oplevering akkoord is. Heldere acceptatieafspraken zorgen ervoor dat beide partijen weten wanneer een softwareproject succesvol is afgerond.

Juridische problemen voorkom je aan de voorkant

Bij veel ICT-geschillen blijkt achteraf dat de afspraken over scope, specificaties, meerwerk en acceptatie onvoldoende waren uitgewerkt. Het oplossen van die discussies kost vaak veel tijd, geld en energie.

Investeer daarom in een helder contract met concrete specificaties, een werkbare wijzigingsprocedure en duidelijke acceptatiecriteria. Documenteer wijzigingen en testresultaten schriftelijk. Dat is niet alleen relevant in het kader van projectmanagement, het is ook je sterkste verdediging op het moment dat er een conflict ontstaat.

Heb je vragen over een ICT-contract of een lopende discussie over scope of meerwerk? Wij adviseren leveranciers regelmatig over hun contractuele positie en denken graag met je mee.