Een goed contract opstellen is bepaald geen sinecure. Zeker niet als het gaat om een contract voor een IT-project dat een grote impact heeft op uw organisatie. Jammer genoeg leert de praktijk dat er vaak maar weinig tijd wordt uitgetrokken voor het opstellen en uitonderhandelen van een goed contract, wat zich later opbreekt omdat afspraken onvoldoende duidelijk blijken te zijn en leiden tot interpretatieverschillen. Het contract wordt vaak gezien als een vervelend sluitstuk van een (vaak al lang lopend) onderhandeltraject waarbij partijen al lang blij zijn overeenstemming te hebben bereikt over de prijs. Niet zelden blijkt echter pas bij het opstellen van het contract dat onvoldoende duidelijk is wat er precies moet worden geleverd en aan welke eisen datgene moet voldoen. In deze bijdrage treft u een vijftal vragen aan die u helpen om te beoordelen of de kernafspraken voldoende terugkomen in het contract.
Wat, Wie, Hoe, Wanneer en Wat vragen
De volgende praktische vragen vormen een handig hulpmiddel bij het beoordelen van (IT-) contracten. Als u antwoord kunt geven op de volgende vragen, dan heeft u in ieder geval de kern van de verplichtingen te pakken:
Wat moet er worden geleverd?
Deze vraag richt zich tot de leveringsomvang (scope). Wat moet nog wel worden geleverd en wat niet meer? Het spreekt voor zich dat dit voldoende duidelijk moet zijn om teleursrellingen en meerwerkdiscussies te voorkomen. Voorts moet voldoende duidelijk zijn aan welke eisen (specificaties) de software of hardware moet voldoen. Een hele logische vraag hoor ik u denken, maar opmerkelijk genoeg is dit wel een vraag die in de praktijk onvoldoende aandacht krijgt of zelfs helemaal niet goed kan worden beantwoord. Dit terwijl het vaststellen van de specificaties uitermate belangrijk is omdat dit niet alleen de leveringsomvang definieert, maar tegelijk ook de toetssteen is bij de acceptatietest of er daadwerkelijk conform afspraak is opgeleverd. Zonder een helder antwoord op deze vraag is het heel lastig om vast te stellen of er juridisch gezien sprake is van een tekortkoming.
Wie moet Wat leveren?
Duidelijk moet zijn welke verantwoordelijkheden bij welke partij thuishoren. Is de leverancier degene die (vrijwel) alle werkzaamheden verricht en is de rol van de afnemer beperkt tot slechts het verlenen van de noodzakelijke medewerking aan de leverancier (bijvoorbeeld het verstrekken van informatie over bepaalde werkprocessen, het aanbieden van een werkplek op locatie, etc.) of gaat het om een samenwerkingsproject waarbij de rol van de afnemer even groot is als die van de leverancier. In het laatste geval zullen nauwkeurige afspraken gemaakt moeten worden over de invulling van die rolverdeling.
Hoe moet Wie, Wat leveren?
Dit is de vraag hoe de software wordt geïmplementeerd of geïnstalleerd. Moet daarvoor een implementatieproject worden opgetuigd? Vaak zullen daarbij afspraken moeten worden gemaakt over een bepaalde volgordelijkheid. Dergelijke afspraken (samen met vraag 2) zullen goed moeten worden vastgelegd, bijvoorbeeld in een implementatieplan, plan van aanpak of ander document dat onderdeel uitmaakt van de overeenkomst.
Wanneer moet Wie, Wat, Hoe leveren?
Deze vraag spreekt voor zich: Er zal een duidelijke planning moeten zijn met een of meerdere heldere oplevermomenten. Daarbij zal ook duidelijk moeten zijn wat er precies op die momenten moet worden opgeleverd en door wie. Vaak wordt hier gekozen voor het opknippen van projecten in verschillende mijlpalen (milestones).
Wat kost Wanneer, Wie, Wat en Hoe?
Deze vraag krijgt begrijperlijkerwijs vaak veel aandacht, maar toch is het verstandig om te controleren of alle te verrichten werkzaamheden daadwerkelijk door de financiële afspraken worden gedekt. Niet zelden blijkt dat er nog geen duidelijkheid is over bijvoorbeeld de implementatiekosten omdat alle focus heeft gelegen op het uitonderhandelen van een mooie licentievergoeding. Als er wordt overeengekomen om de software in delen (milestones) op te leveren, is het voor de afnemer van belang om de betaalmomenten aan (de acceptatie van) die milestones te koppelen. Zodoende wordt voorkomen dat de kosten en de opleveringen uit elkaar gaan lopen.
Het voorgaande is een methode om snel tot de kern van een overeenkomst te komen. Het is uiteraard niet alomvattend om te komen tot een goed IT-contract. Er zal natuurlijk ook aandacht moeten worden besteed aan het wegnemen of verdelen van specifiek projectrisico’s en gekeken moeten worden naar bijvoorbeeld garanties, service levels en aansprakelijkheid. Als echter de kern van de overeenkomst duidelijk is, zult u die bepalingen veel minder snel nodig hebben.
Wat, Wie, Hoe, Wanneer en Wat vragen
De volgende praktische vragen vormen een handig hulpmiddel bij het beoordelen van (IT-) contracten. Als u antwoord kunt geven op de volgende vragen, dan heeft u in ieder geval de kern van de verplichtingen te pakken:
- Wat moet er worden geleverd?
- Wie moet Wat leveren?
- Hoe moet Wie, Wat leveren?
- Wanneer moet Wie, Wat, Hoe leveren?
- Wat kost Wanneer, Wie, Wat en Hoe?
Wat moet er worden geleverd?
Deze vraag richt zich tot de leveringsomvang (scope). Wat moet nog wel worden geleverd en wat niet meer? Het spreekt voor zich dat dit voldoende duidelijk moet zijn om teleursrellingen en meerwerkdiscussies te voorkomen. Voorts moet voldoende duidelijk zijn aan welke eisen (specificaties) de software of hardware moet voldoen. Een hele logische vraag hoor ik u denken, maar opmerkelijk genoeg is dit wel een vraag die in de praktijk onvoldoende aandacht krijgt of zelfs helemaal niet goed kan worden beantwoord. Dit terwijl het vaststellen van de specificaties uitermate belangrijk is omdat dit niet alleen de leveringsomvang definieert, maar tegelijk ook de toetssteen is bij de acceptatietest of er daadwerkelijk conform afspraak is opgeleverd. Zonder een helder antwoord op deze vraag is het heel lastig om vast te stellen of er juridisch gezien sprake is van een tekortkoming.
Wie moet Wat leveren?
Duidelijk moet zijn welke verantwoordelijkheden bij welke partij thuishoren. Is de leverancier degene die (vrijwel) alle werkzaamheden verricht en is de rol van de afnemer beperkt tot slechts het verlenen van de noodzakelijke medewerking aan de leverancier (bijvoorbeeld het verstrekken van informatie over bepaalde werkprocessen, het aanbieden van een werkplek op locatie, etc.) of gaat het om een samenwerkingsproject waarbij de rol van de afnemer even groot is als die van de leverancier. In het laatste geval zullen nauwkeurige afspraken gemaakt moeten worden over de invulling van die rolverdeling.
Hoe moet Wie, Wat leveren?
Dit is de vraag hoe de software wordt geïmplementeerd of geïnstalleerd. Moet daarvoor een implementatieproject worden opgetuigd? Vaak zullen daarbij afspraken moeten worden gemaakt over een bepaalde volgordelijkheid. Dergelijke afspraken (samen met vraag 2) zullen goed moeten worden vastgelegd, bijvoorbeeld in een implementatieplan, plan van aanpak of ander document dat onderdeel uitmaakt van de overeenkomst.
Wanneer moet Wie, Wat, Hoe leveren?
Deze vraag spreekt voor zich: Er zal een duidelijke planning moeten zijn met een of meerdere heldere oplevermomenten. Daarbij zal ook duidelijk moeten zijn wat er precies op die momenten moet worden opgeleverd en door wie. Vaak wordt hier gekozen voor het opknippen van projecten in verschillende mijlpalen (milestones).
Wat kost Wanneer, Wie, Wat en Hoe?
Deze vraag krijgt begrijperlijkerwijs vaak veel aandacht, maar toch is het verstandig om te controleren of alle te verrichten werkzaamheden daadwerkelijk door de financiële afspraken worden gedekt. Niet zelden blijkt dat er nog geen duidelijkheid is over bijvoorbeeld de implementatiekosten omdat alle focus heeft gelegen op het uitonderhandelen van een mooie licentievergoeding. Als er wordt overeengekomen om de software in delen (milestones) op te leveren, is het voor de afnemer van belang om de betaalmomenten aan (de acceptatie van) die milestones te koppelen. Zodoende wordt voorkomen dat de kosten en de opleveringen uit elkaar gaan lopen.
Het voorgaande is een methode om snel tot de kern van een overeenkomst te komen. Het is uiteraard niet alomvattend om te komen tot een goed IT-contract. Er zal natuurlijk ook aandacht moeten worden besteed aan het wegnemen of verdelen van specifiek projectrisico’s en gekeken moeten worden naar bijvoorbeeld garanties, service levels en aansprakelijkheid. Als echter de kern van de overeenkomst duidelijk is, zult u die bepalingen veel minder snel nodig hebben.
Gerelateerd
IT
