De MoSCoW-methode in IT-contracten

In de volksmond heet het dat overeenkomsten in juridische zin gebaseerd zijn op wilsovereen-stemming. Eenvoudig gezegd: ik bied u mijn oude auto (198.000 km) met kenteken AB-66-YZ te koop aan voor de prijs van 4.000 euro, te betalen binnen twee weken, waarna u mijn aanbod aanvaardt door te zeggen dat u het barrel voor dat bedrag wel wilt overnemen. De koopovereenkomst komt tot stand met het aanvaarden van mijn aanbod. Consensus tussen koper en verkoper, oftewel wils-overeenstemming. Over consensualisme als ‘basic’ van het overeenkomstenrecht zijn al ontelbare boeken vol met veel juridische wijsheden geschreven.

Wat voor de koopovereenkomst van mijn auto geldt, geldt in essentie ook voor IT-contracten. Toch is de vraag wat de partijen bij een IT-contract – opdrachtgever en leverancier – elk nou precies hebben gewild, praktisch gezien, vaak wel de meest ingewikkelde. Achteraf wordt de inhoud van de gemaakte afspraken niet zelden ter discussie gesteld.

IT: words have no proper meaning

Meer dan eens ontstaan die discussies (en geschillen) doordat de partijen elk een andere betekenis geven aan de bewoordingen uit het contract. Want wat hebben partijen exact voor ogen als de leverancier zich in de tekst van zijn contract heeft verplicht tot het leveren van een ‘totaaloplossing’ of tot ‘ontzorging’ van de klant? Heb je als leverancier met deze veelomvattend klinkende termen – wellicht onbedoeld – meer verwachtingen gewekt dan je eigenlijk voor ogen had?

En wat bedoelen partijen precies met de ‘implementatie’ van een systeem als het IT-contract voorziet in een verder niet gedefinieerde implementatieverplichting? Of: wat zijn de gevolgen wanneer je als bedrijfsjurist of advocaat, wellicht onbewust onbekwaam, een softwarecontract vol propt met ‘feel good’ passages en hol IT-jargon, zoals een garantieclausule die zegt dat de te leveren software “proven technology” moet zijn?

Gebrekkige en halfslachtige communicatie en vage of dubbelzinnige woorden waren – en zijn nog steeds – een van de meest voorkomende bronnen van IT-conflicten. Reden: ‘words have no proper meaning’. Er zijn immers maar weinig termen in de IT-sector waarvan de betekenis onwrikbaar vast staat. Het maken en beoordelen van een goed IT-contract vereist dus ten minste bekendheid met de zin en onzin van IT-jargon.

MoSCoW: het prioriteren van software-eisen

De basale vraag wat partijen bij een IT-contract exact hebben gewild, is ook soms lastig als de makers ervan tamelijk kritiekloos hebben aangeknoopt bij methodes uit de wereld van software engineers. Zo zie ik al jarenlang regelmatig IT-projectcontracten waarin nogal lichtvaardig de resultaten van een zogeheten MoSCoW-analyse zijn opgenomen. Zo’n analyse, veelal afkomstig uit de pen van IT-ers van de opdrachtgever, is dan vastgelegd in een bijlage dat onderdeel is van het contract.

De MoSCoW-methode is een sinds 1992 bestaande en inmiddels veelgebruikte methode, destijds ontwikkeld in de schoot van het IT-bedrijf Oracle, waarmee de eisen en wensen (‘requirements’) die aan de beoogde projectresultaten worden gesteld, zijn geprioriteerd. Dat kunnen bijvoorbeeld software-eisen zijn.

MoSCoW is een acroniem, waarvan de hoofdletters M, S, C en W een bijzondere betekenis geven aan de eisen en wensen van de opdrachtgever. Draagt een eis de hoofletter M (‘must haves’), dan moet de software zonder meer aan die eis voldoen. Is dat niet het geval, dan wordt het ontwikkelproject als mislukt beschouwd. Eisen waarvoor geldt dat het weliswaar wenselijk is dat daaraan wordt voldaan, maar die overigens niet onmisbaar zijn om de software behoorlijk te kunnen gebruiken, krijgen in de MoSCoW-methode het predikaat S (‘should haves’). De C staat voor de ‘could haves’, eisen die het karakter van ‘nice to have’ hebben: leuk om te hebben, maar niks wezenlijks. De W van de ‘won’t haves’ zijn eisen die voor nu buiten het project vallen.

De letters M, S, C en W geven aldus aan welke relatieve zwaarte aan de eisen en wensen m.b.t. de in de overeenkomst bedoelde software toekomt. Met de MoSCoW-methode geeft een opdrachtgever aan dat voor hem niet alle eisen en wensen van gelijk gewicht zijn. Het spreekt voor zich dat die insteek contractueel de nodige vragen oproept.

Wanprestatie en wijzigingsprocedures

Ik beperk me hier tot twee contractuele aandachtspunten. Zo is er ten eerste de vraag waarop je als opdrachtgever jouw leverancier uiteindelijk mag beoordelen en  ‘afrekenen’. Kan de leverancier wanprestatie voor de voeten worden geworpen als de C-eisen (“could haves”) niet of niet allemaal zijn opgepakt? Tijdgebrek kan daar de oorzaak van zijn. Vaak ligt aan het opnemen van C-eisen in het contract impliciet de gedachte ten grondslag dat die alleen worden uitgevoerd als er in het project nog tijd over is. Het nalaten C-eisen uit te voeren levert dus niet snel een wanprestatie op.   

Het kern van een wanprestatie van de leverancier gaat vooral over het niet nakomen van M- en S-eisen? Of mogen we bij de wansprestatievraag ook minder zwaar tillen aan het niet voldoen aan S-eisen? De maker van een goed IT-contract laat over dit soort vragen uiteraard geen enkele onduidelijkheid bestaan. De jurist die het contract schrijft of daarover adviseert, zal in voorkomend geval de juridische impact van de MoSCoW-classificatie dus uitdrukkelijk moeten adresseren. De contractpraktijk laat evenwel zien dat dat niet altijd even zorgvuldig gebeurt.

Invulling van projecten

Nog een ander punt van aandacht. Heeft de opdrachtgever gedurende het IT-project de vrijheid om te besluiten tot aanpassing van de prioritering van zijn eisen en wensen? Als het project ‘agile’ wordt uitgevoerd, dan ligt dat voor de hand. Dat is immers eigen aan een agile aanpak. Maar het kan anders liggen als partijen tevens afspraken hebben gemaakt over de allocatie van ontwikkelcapaciteit. Je ziet soms wel dat partijen afspreken dat bijv. 65% van de beschikbare ontwikkelcapaciteit wordt ingezet voor het uitvoeren van M-eisen, 30% voor S-eisen en 5% voor C-eisen. 

In dat geval zou het eenzijdig uitbreiden van bijvoorbeeld de set met M-eisen werkverzwaring voor de leverancier inhouden, waardoor de haalbaarheid van het project en de afgesproken doorlooptijden onder druk komen te staan. In verband daarmee voorziet een IT-contract dat uitgaat van de MoSCoW-methode idealiter in een stevig gewaarborgde wijzigingsprocedure. Het maken daarvan is echt juristenwerk.  

Methode toepassen

Al met al kan contracteren op basis van de MoSCoW-methode heel realistisch zijn. De methode is immers een uitwerking van de vanzelfsprekende gedachte dat niet alle eisen en wensen van IT-opdrachtgevers even belangrijk zijn. Maar hanteer je deze methode, zorg dan wel voor een goede juridische inbedding in het IT-contract! Om gedonder over de uitleg van de methode ‘an sich’ en over de inhoud van projectresultaten te voorkomen.