12 Voorkomen is beter dan genezen. ICT-contracten en conflictpreventie

?enbericht

Voorkomen is beter dan genezen. ICT-contracten en conflictpreventie

12

Prof. mr. drs. C. Stuurman*

Inleiding

12.1

ICT-projecten leiden tot veel conflicten. Hoewel dit gegeven in brede kring bekend is, lijkt het voorkomen, beheersen en efficient oplossen van conflicten in veel gevallen althans bij het aangaan van ICT-contracten weinig prioriteit te krijgen. Veel verder dan het regelen van het toepasselijke recht, het bevoegde forum (rechter, arbiter, SGOA, ...) en de overlegstructuur, lijken partijen vaak niet te komen. Dat is een gemiste kans; er kan vooraf veel meer worden gedaan om te voorkomen dat er bij ICT-projecten geschillen ontstaan die een bedreiging vormen voor de succeskansen van het project. In deze bijdrage zal de aandacht daarom met name uit gaan naar de wijze waarop de inhoud van ICT-contracten kan bijdragen aan het voorkomen. Het accent ligt derhalve niet op het 'genezen', maar vooral op het voorkomen.

12.2

Conflicten

12:2.1

Inleiding

Bij het uitvoeren van IT-projecten ontstaan conflicten op allerlei manieren. Hoewel oorzaak, verschijningsvorm en (potentiele) gevolgen steeds projectspecifiek zijn, vertonen deze toch ook de nodige gemeenschappelijke kenmerken. In dit hoofdstuk zal eerst kort worden ingegaan op de technische en organisatorische achtergronden van het ontstaan van conflicten, waarna de verbinding met een aantal juridische slaag- en faalfactoren zal worden gemaakt.

Prof. mr. drs. C. Stuurman is als partner werkzaam bij Van Doorne advocaten, notarissen en fiscalisten te Amsterdam, en daar verantwoordelijk voor de praktijkgroep Informatietechnologie. Tevens is hij als hoogleraar 'Normering van Informatietechnologie' verbonden aan het Centrum voor Recht, Technologic en Samenleving (TILT) van de Universiteit van Tilburg. Met dank aan Louis Jonker (advocaat bij de praktijkgroep Informatietechnologie van Van Doorne) voor zijn bijdragen aan eerdere versies van deze publicatie.

260


12.2.2

Slaag- en faalfactoren van projecten

Er is recent (weer) veel geschreven over het slagen en falen van IT-projecten. Dit met name onder invloed van de rapporten zoals eind 2007 en medio 2008 uitgebracht door de Algemene Rekenkamer.1 Het thema is echter al veel ouder. Al in 1982 verscheen van de hand van Jan Oonincx onder de titel 'Waarom falen informatiesystemen nog steeds?'2 een publicatie over dit onderwerp. Het valt op dat de achterliggende oorzaken van het frequent mislukken van IT-projecten in de afgelopen tientallen jaren opmerkelijk constant zijn gebleken. In de meeste gevallen betreft het een of meer van de volgende oorzaken: 1. inadequaat projectmanagement; 2. niet realistische deadlines; 3. slechte communicatie; 4. incomplete dan wel zwakke definitie van requirements; dan wel 5. onvoldoende betrokkenheid van toekomstige gebruikers.3 De bovengenoemde factoren zijn de belangrijkste 'drivers' voor het ontstaan van problemen bij ICT-projecten. Dat betekent uiteraard niet automatisch dat ook uitsluitend deze factoren ten grondslag liggen aan conflicten bij dergelijke projecten. Zo kan er bijv. sprake zijn van zuiver externe omstandigheden (zoals wijzigingen in wet- en regelgeving, fusies of overnames, een kredietcrisis etc.) waarvan de gevolgen niet kunnen worden overwonnen door een betere beheersing van de onderscheiden faalfactoren. Niettemin lijkt aannemelijk dat ten minste een groot deel van conflicten welke zich voordoen bij ICT-projecten direct of indirect gerelateerd zijn aan de bovengenoemde factoren. / De onderscheiden slaag- en faalfactoren zijn weliswaar primair technisch en organisatorisch van aard, maar kunnen ook worden verbonden met diverse aspecten, van de juridische relatie tussen opdrachtgevers en opdrachtnemers bij IT-projec- ; ten. Uiteraard 'vertalen' zij zich vaak in juridische geschillen, met nakoming.;< (soms) of schadevergoeding (vaak) als inzet. -> Voor deze bijdrage is dat al 'te laat' in het proces; hier wil mij richten op de faseu die daaraan voorafgaan. Dit betreft zowel de voorbereiding, inhoud als uitvoeriag van IT-contracten. De kwaliteit van die fasen bepaalt in belangrijke mate (maar niet uitsluitend, er kan zoals opgemerkt sprake zijn van ingrijpende exterae omstandigheden) wat het risicoprofiel van het project is in termen van (potentiele) conflicten.

1 2 3

'Lessen uit ICT-projecten van de overheid', Delen A en B, zie www.rekenkamer.nl. A. van Dijk , 'Succes-faalfactoren bij ICT projecten', Informatie, juli/augustus 2008, p. 40. Van Dijk, a.w., p. 44. De genoemde factoren worden in de literatuur wel als de zogenaamde 'big hitters* aangeduid.

De praktij! vaak (een 1. schend 2. onzorg 3. inadeq Deze juric scheiden tEen voorb ingevuld t se is een t onrealistis kwaliteit A door onvo lijk de voc welke ran( de contrac vaak een : gerelateen nagement' Over de p nisch, org, de praktijl dat vaak r faalfacton disch slui De (prakt sche, org£ zoek lonk In het volj den ingeg

12.3 12.3.1 Indien co gevolgenr: ten. In ess daaraan n van de re informati'

iflictpreventie

ijecten. Dit !008 uitgeuder. Al in ialen inforvan IT-pro:ken. In de

itstaan van at ook uitprojecten. /ijzigingen raarvan de ng van de ; een groot iirect gere:h en orgae aspecten IT-projecnakoming p de fasen uitvoering late (maar le externe (potentie-

ig hitters' aan-

261

Hoofdstuk 12

De praktijkervaring leert dat in geval van conflicten bij ICT-projecten met name vaak (een of meer van) de volgende aspecten relevant zijn: 1. schending informatieplichten; 2. onzorgvuldige voorbereiding van het contractproces; 3. inadequate vastlegging en uitvoering van afspraken. Deze juridische factoren vertonen een zekere samenhang met de eerder onderscheiden technische en organisatorische faalfactoren. Een voorbeeld is de wijze waarop de informatieplichten tussen partijen worden ingevuld bij het aangaan van het contract. Gebrekkig onderzoek in de initiatiefase is een belangrijke reden voor het op papier vastleggen van - naar later blijkt onreahstische deadlines, een belangrijke faalfactor. Ditzelfde geldt vaak voor de kwaliteit van de requirements; in veel gevallen wordt de basis daarvoor gelegd door onvoldoende informatie van de zijde van opdrachtgever (wat zijn nu werkelijk de voornaamste eisen) en onvoldoende onderzoek door de leverancier (onder welke randvoorwaarden kunnen deze eisen worden gerealiseerd). Voor wat betreft de contractinhoud is de wijze waarop de onderlinge communicatie is geregeld vaak een indicator voor de kwaliteit van het overleg tussen partijen en daarmee gerelateerd aan de kritische slaag- en faalfactoren 'communicate' en projectmanagement'. Over de precieze verhouding tussen de diverse typen slaag- en faalfactoren (technisch, organisatorisch, juridisch,....) is ongetwijfeld nog (veel) meer te zeggen. In de praktijk kan worden vastgesteld dat in de gevallen waarm een project mislukt, dat vaak mede is terug te voeren op een of meer van de onderscheiden juridische faalfactoren Deze faalfactoren dekken echter niet elk mislukking af. Een jundisch sluitende voorbereiding en uitvoering waarborgt nu eenmaa geen succes. De (Praktijk)conclusie dat er samenhang bestaat tussen de onderscheiden technische organisatorische en juridische faalfactoren is hier voldoende. Nader onderzoek lonkt. In het volgende hoofdstuk zal op de onderscheiden juridische aspecten nader worden ingegaan.

12.3

Juridische faalfactoren

12.3.1

Tekortschietende invulling van informatieplichten

Indien conflicten ontstaan is voor de vraag naar de toerekening (wie draagt de gevolgen?) cruciaal om vast te stellen welke verplichtingen op elk der partijen rusL In essentie komt het daarbij aan op de tekst van het contract, de uitleg welke daaraan mag worden gegeven en de, aanvullende dan wel beperkende, werking van de redelijkheid en de billijkheid (art. 6:248 BW). De op partijen rustende informatieplicht vormt van dit laatste aspect vaak de voornaamste component.


Hoofdstuk 1

De historic, inclusief rechtspraak, leert dat veel IT-conflicten zijn terug te voeren op het niet of niet-volledig nakomen van op hen rustende informatieplichten door een of beide partijen. Met betrekking tot deze informatieplichten kan een onderscheid worden gemaakt tussen a) het verstrekken van informatie, b) het doen van onderzoek, en c) het waarschuwen van de andere partij.4 Een korte schets.

dat op her De deskui ver toegei tieplichtei

262

Adviseur en leverancier zijn verplicht de (potentiele) opdrachtgever zo duidelijk en volledig mogelijk voor te lichten over de (consequenties van) het betreffende project. Voorts rust op elk van hen een onderzoeksplicht. Deze reikt verder naarmate de opdrachtgever meer als een leek op automatiseringsgebied is te beschouwen. De uitspraak in het geschil Broere/Olivetti5 is een schoolvoorbeeld daar waar het gaat om de onderzoeksplicht van de leverancier. Ook in de Magneetkaartzaak6 werd het bestaan van een onderzoeksplicht voor de leverancier aangenomen. Niettemin beslisten de arbiters uiteindelijk in het voordeel van de leverancier, omdat de opdrachtgever een deskundige had moeten inschakelen en had moeten stoppen met het geven van opdrachten. Adviseur en leverancier hebben steeds een eigen verantwoordelijkheid te onderzoeken of de wensen/eisen van de opdrachtgever iiberhaupt haalbaar zijn. Tijdsdruk van de zijde van de opdrachtgever kan hen van deze verplichting niet (volledig) bevrijden.7 Verder geldt dat adviseur en leverancier de plicht heeft om de opdrachtgever te waarschuwen voor eventuele risico's (waaronder begrepen het behouden van de opdrachtgever voor te hoog gespannen verwachtingen). Een voorbeeld is de arbitragezaak Dolmans/Burroughs*. Onder omstandigheden kan de waarschuwingsplicht zelfs zover gaan dat een adviseur of leverancier de opdracht niet zal mogen uitvoeren als hij bekend is of had moeten zijn met risico's die onverantwoord zijn in het licht van de bedrijfsvoering van de opdrachtgever. De informatieplichten van adviseur en leverancier worden begrensd door de informatieplichten welke op de opdrachtgever rusten. Op de opdrachtgever rust in, beginsel de verplichting om de wederpartij te informeren over de eigen organisa*, tie, alsmede om ten minste een minimumset aan wensen/eisen voor het project te identificeren en vast te leggen. In hoeverre op de opdrachtgever een onderzoeksplicht rust, hangt onder meer sterk af van diens mate van deskundigheid. Indien de opdrachtgever zich bijv. laat bijstaan door een externe adviseur, is aannemelijk

4 5 6 7 8

In relatie tot IT-contracten voor het eerst beschreven in: G.Vandenberghe, Partijenaansprakelijkheid bij sajlwarecontracten, Antwerpen-Deventer: Kluwer 1984. HR 11 november 1983, RvdW 1983, 194. Raad van Arbitrage voor Metaalnijverheid en -Handel 12 oktober 1979, TvA 1980/1. Gerechtshof Den Haag 8 maart 1994, Computerrecht 1984/2, p. 29 (KBC/Brinkers). Raad van Arbitrage Metaalnijverheid en -Handel 18 februari 1985, Computerrecht 1985/6.

Veel infoi de voorbe reiding is gedaan. i (bedrijfs)] van een, c meeste ge (te) haasti 72.3.2 Niet allee staan, ool Vanuit he gel: maak citeit, des De inrich veel geva goede vei 1. 2. 3. 4.

de ma de ma de rui de mi meet de mi specij de m; conto

In de pral het voora en geld, <

Zie onde p. 42. O van zijn trouwen 10 Aan opd

263

Hoofdstuk 12

dat op hem een zwaardere onderzoeksplicht rust dan wanneer dit niet het geval is.9 De deskundigheid van een externe adviseur wordt in beginsel aan de opdrachtgever toegerekend. De deskundigheid van de opdrachtgever kan de eigen informatieplichten van de adviseur en leverancier nooit helemaal doen verdwijnen. Veel informatieplichten spelen in het bijzonder (maar niet uitsluitend) een rol bij de voorbereiding van IT-projecten. Zoals vaak geldt ook hier: een goede voorbereiding is het halve werk. In de IT-praktijk is dat veelal gemakkelijker gezegd dan gedaan. Gebrek aan capaciteit en deskundigheid, maar ook commerciele, (bedrijfs)politieke en financiele druk, leiden er vaak toe dat de informatiepositie van een, of vaak beide, partijen onvoldoende is bij de start van het project. In de meeste gevallen wordt dit in de loop van het traject (pijnlijk) zichtbaar en blijkt de (te) haastige voorbereiding duur te worden betaald. 12.3.2

Onzorgvuldige voorbereiding contractfase

Niet alleen het invullen van de informatieplichten komt vaak onder (tijds)druk te staan, ook het onderhandelings- en contractproces wordt hierdoor vaak getroffen. Vanuit het perspectief van risicobeheersing is echter een belangrijke ervaringsregel: maak van het contract(proces) geen sluitpost (in termen van tijd, geld, capaciteit, deskundigheid of anderszins). De inrichting van het onderhandelings- en contractproces verschilt per project. In veel gevallen blijken met name de volgende factoren relevant voor het al of niet goede verloop van het proces, en de kwaliteit van de uitkomsten daarvan: 1. 2. 3. 4.

de mate van betrokkenheid van juristen vanaf de startfase; de mate van betrokkenheid van voldoende gespecialiseerde IT-juristen; de raimte voor volledige inhoudelijke juridische toetsing; de mogelijkheid de resultaten van juridische toetsing in het contractproces mee te nemen; 5. de mate waarin juridisch maatwerk mogelijk is welke is toegesneden op de specifieke omstandigheden van het project; 6. de mate van betrokkenheid van het verantwoordelijke management10 bij de contractbesprekingen. In de praktijk is de score op deze parameters vaak gemengd. De ervaring leert dat het vooraf maken van adequate afspraken het meest efficient is, in termen van tijd en geld, om het project in goede banen te leiden. Anders gezegd: besparingen

9

Zie onder meer Ofyslager/Intermation, vicepresident Rb. Amsterdam 16 oktober 1986, Computerrecht 1987/1, p. 42. Of er in een concreet geval op een opdrachtgever daadwerkelijk een onderzoeksplicht rust, zal, behalve van zijn mate van deskundigheid, ook onder meer kunnen afhangen van de mate waarin hij heeft mogen vertrouwen op de inlichtingen van de leverancier. 10 Aan opdVachtgeverszijde: zowel de IT-afdeling als de 'business' (toekomstige gebruikers).

264


(onderbesteding van tijd en geld ten opzichte van hetgeen is benodigd voor het tot stand brengen van een adequaat contract) die om welke reden dan ook precontractueel worden toegepast, leiden als regel tot aanzienlijke11 extra investeringen om (alsnog) de uitvoering van het contract in goede banen te leiden. Hierbij speelt onder meer een rol dat de problematiek in de uitvoeringsfase vaak beduidend lastiger is te controleren dan in de onderhandelingsfase. Zo zal de opdrachtgever zich goed dienen te realiseren dat in de onderhandelingsfase de leverancier nog onder druk staat (intern en van concurrenten) om het contract binnen te halen. Na het ondertekenen van het contract zijn de verhoudmgen wezenlijk veranderd. De leverancier zal 'de deal' verdedigen; ruimte voor concessies (met als gevolg marges onder druk of meer risico) is er niet of nauwelijks meer. Voor de opdrachtgever zal 'bijbetalen' vaak nog de enige optie zijn om de leverancier te bewegen zijn prestaties wezenlijk te veranderen. 12.3.3

Inadequate vastlegging en uitvoering van afspraken; kwaliteitstoets

Het thema 'kwaliteit van contracten' is complex, met veel ruimte voor verschillende visies. Een voor de hand liggende vraag is uiteraard: kwaliteit in welke zin? Het bekende bierviltje kan de drager zijn voor een contract dat technisch of commercieel uitstekend uitpakt. Juridisch is er strikt genomen ook al weinig aan de hand; vrijwel alle IT-contracten zijn vormvrij en nergens staat dat een contract uitgebreid moet zijn. Toch gaat dit als regel niet op voor IT-contracten. Een tweetal aspecten van het begrip 'kwaliteit' wil ik hier nader belichten. Ten eerste de consequentie van het gegeven dat IT-projecten nauwe samenwerking vereisen, en ten tweede de flexibiliteit welke is vereist voor het omgaan met de dynamiek van IT-projecten. IT vraagt nauwe samenwerking Complexe IT-projecten vereisen een actieve samenwerking tussen partijen, op voet van gelijkheid. Die - voor het welslagen noodzakelijke - balans vertaald naar een contract, betekent dat er een juist evenwicht moet worden gevonden tussen de rechten en verplichtingen van leverancier en opdrachtgever. Sterk in het voordeel van slechts een van partijen opgestelde contracten zullen in de meeste gevallen, een risicoverhogende factor. Dit mede omdat het bij IT-contracten niet alleen ga&t om de uitvoering van de vastgelegde afspraken als zodanig (wie doet wat, en met, welk resultaat), maar ook om het (steeds) aanpassen van de afspraken aan de zieh wijzigende omstandigheden.

11

Ik ben niet bekend met onderzoek op dit punt, maar de uitkomsten zullen ongerwijfeld een belangrijke les V0f men voor het inrichten van (de aanloop naar) IT-projecten.

Hoofdst,

Indien steld, 2 nen ve aanhar conflic Vanuit sprake waardt (BiZarespec onder opdrac werkt, zijn be voorde onbeps

Naar n gepast richtin He geblek accept (onder

Hoofdstuk 12

265

Indien contractvoorwaarden slechts in het voordeel van een van partijen zijn opgesteld, zal dit overigens de kans op het aanhangig maken van een geschil soms kunnen verkleinen; de onderliggende partij zal zich namelijk snel realiseren dat het aanhangig maken van een geschil kansloos is. Dit betekent echter niet dat er geen conflict(situatie) zal ontstaan, met alle gevolgen van dien. Vanuit het oogpunt van conflictbeheersing verdienen gebalanceerde contractafspraken dan ook de voorkeur. De thans veel gebruikte 'standaarden' (FENIT-voorwaarden, en inmiddels in mindere mate, de Modelcontracten Automatisenng (BiZa-modellen)) zijn beide (zeer) eenzijdig in het voordeel van de leveranciers respectievelijk opdrachtgever opgesteld. Dit uit zich in de FENIT-voorwaarden onder meer in de wijze waarop de informatie- en medewerkingsphchten van de opdrachtgever op diverse plaatsen in de voorwaarden expliciet nader zijn uitgewerkt terwijl de informatieplichten van de adviseur/leverancier meermaals sterk zijn b'egrensd. In de BiZa-modellen is het vaak niet beter gesteld, maar dan in het voordeel van de opdrachtgever; aanvullend zijn vergaande garanties en (deels onbeperkte) aansprakelijkheden opgenomen. De juridisch-technische kwaliteit van de beide sets voorwaarden is goed, maar dat geldt niet als een en ander wordt bezien in de sleutel van het leveren van een bijdrage aan een geslaagd project. Naar mij bekend komt zowel de overheid als de ICT-branche binnenkort met aangepaste voorwaarden. Hopelijk is bij het opstellen daarvan een stap in de goede richting gezet. . . Het is te betreuren dat de ICT-branche en gebraikers tot heden met in staat zijn gebleken gezamenlijk om een set voorwaarden te komen die voor beide partijen acceptabel zijn. Een mooie doelstelling voor 'de digitale polder'; het buitenland (onder meer Denemarken) laat zien dat het wel kan. Een dergelijk resultaat zou ook een mooie bijdrage kunnen leveren aan het verminderen van het aantal conflicten rond aanbestedingstrajecten. De ervanng leert dat aanbestedende diensten de opzet van de procedures en het verbod op onderhandelen (bij openbare en niet-openbare aanbestedingen) nogal eens aangrijpen om zeer eenzijdige contractvoorwaarden op te leggen. De prijs die daarvoor, juist door de opdrachtgever, in de loop van het project wordt betaald is vaak hoog. Kwaliteit vraagt flexibiliteit Een van de kenmerken van IT-projecten is het beperkte 'zicht' dat er bestaat op onrwikkelingen die verder dan drie, of in gunstige gevallen soms hooguit zes maanden, verder weg liggen. Oorzaken zijn onder meer de nauwe verwevenheid van IT-projecten met het bedrijfsproces van de opdrachtgever (gevoeligheid voor alle daarvoor relevante in- en externe ontwikkelingen), de complexiteit van het vaststellen van eisen (inclusief vaak gebrekkig vooronderzoek), en voortschnjdend inzicht aan gebruikerszijde (wat kan er nog meer). Dit alles vraagt zowel een

266


meer productgerichte benadering (heldere vastlegging van eisen, alsmede spelregels voor bouw, testen en acceptatie) als een meer procesgerichte benadering (procedures voor het bewaken van de haalbaarheid en bruikbaarheid van lopende afspraken en indien noodzakelijk bijstellen daarvan, inclusief aanpassen van het contract). Op beide punten lijkt in de praktijk relatief veel mis te gaan. Ten eerste valt op dat contracten nogal eens onvolledig zijn; er wordt geen volledige beschrijving gegeven van de uit te voeren taken en de bijbehorende verantwoordelijkheden. Ook ontbreekt vaak het antwoord op de vraag 'what if...?'. Bijv. ten aanzien van termijnen is het goed om, naast de afspraken over de precieze betekenis daarvan (inspanning/resultaat), ook vast te leggen wat er gaat gebeuren bij (dreigende) overschrijding (sancties, aanpassen projectplanning,...). Dit is niet alleen vanuit gebruikersperspectief belangrijk, termijnoverschrijdingen ontstaan. niet zelden door gebrekkige medewerking van opdrachtgeverszijde. Voldoende aandacht voor procesgerichte afspraken kan voorkomen dat partijen vaker dan nodig gaande het project voor (te veel) onvoorziene omstandigheden, en alle daarbij behorende risico's, komen te staan. Onderdeel van de procesgerichte kwaliteit is ook de mate waarin het contract aansluit bij de - voortdurend veranderende - projectrealiteit. Vaak is de inkt van de handtekeningen nog niet opgedroogd en de eerste mismatch tussen de feitelijke situatie en de inhoud van het contract is een feit. In het kader van het voorkomen en beheersen van conflicten is het van belang dat het contract niet alleen op het moment van het aangaan de verhouding tussen partijen beschrijft, maar dat de afsprakenset mee wordt ontwikkeld als het project zich ontvouwt Heldere communicatieprocedures en voldoende aandacht voor change management zijn belangrijke bouwstenen. Het contract moet derhalve na het ondertekenen niet 'de lade in', maar actief worden gebruikt en aangepast waar nodig. In de praktijk blijkt dit in veel gevallen een, ' (te) zware opgave. Zo worden 'op de werkvloer' door de met de uitvoering belasr te betrokkenen vaak nadere afspraken en afwijkingen overeengekomen, welke niet' steeds goed worden gedocumenteerd. Verder leert de ervaring - vreemd genoeg - '' dat zodra de handtekeningen zijn gezet, de originele ondertekende versie niet steeds voldoende zorgvuldig wordt bewaard waardoor partijen in opmerkelijk veel gevallen nog slechts de beschikking hebben over de laatste conceptversie. Het verbeteren van contractbeheer kan dan ook in belangrijke mate bijdragen aaa1 het (verder) voorkomen van conflicten. De benodigde investering (extra aandacht vanuit het projectmanagement en later vanuit contractmanagement voor de con* tractuele aspecten) verdient zich in veel gevallen al weer snel terug. Ten tweede zijn de gemaakte afspraken niet steeds eenduidig. Dat varieert vaa regelrechte inconsistenties (conflicterende afspraken) tot het niet of niet consistent gebruiken van begrippen. Voorbeelden zijn onder meer het door elkaar gebruikea

Hoofdstuk

van beg ding), 'r

Hierbij ^ disch de nische, i schillenc aansturii In dit ve: zien naa: gelijkwa tractsbej dighedei hetgeen: echter sp Raad me de bepal; eenkoms de risico

Wie latei halve nai duidig vi op confli pretaties Een in di van Enge Aan dez rechtsge's breken. I probleme Kennis ei essentiee voorkorm Om uitle

12 13 14 15

267

Hoofdstuk 12

van begrippen als 'inspanning', 'resultant', 'garanties' (vaak zonder nadere duiding), 'risico', 'verantwoordelijk', 'voor rekemng van', etc. Hierbij wreekt zich ook nogal eens dat het contract bestaat uit een typische juridisch deel (de zuiver juridische afspraken), en een groot aantal bylagen van technische, f inanciele of organisatorische aard. Deze documenten worden vaak in verschillende werkgroepen opgesteld waarbij de inhoud daarvan door onvoldoende aansturing van het contractproces niet (voldoende) zijn gecoordrneerd. In dit verband belangrijk dat in de Nederlandse rechtspraak een ontwikkeling is te zien naar een meer objectieve uitleg van contracten welke worden gesloten tussen gelijkwaardige professionele partijen. Nog steeds moet by de uitleg van conLtsbepalingen gekeken worden naar de zin die partijen in de= gegeven omstandigheden over en weer redelijkerwijs aan de bepalmgen mochten toekennen en hetgeen zij te dien aanzien redelijkerwijs van elkaar mochten verwachten Indien echter sprake is van handelspartijen van een gelijkwaardig mveau, hecht de Hoge Raad met name waarde aan een tekstuele en daarmee meer objectieve uitleg van de bepalingen van de overeenkomst." Handelspartijen sluiten immers vaker overeenkomsten af en zijn beter in staat om hun eigen belangen te behartigen en om de risico's van een overeenkomst in te kunnen schatten. Wie later ook in rechte een beroep op een contract zal willen doen heeft er derhalve nadrukkelijk belang bij de bereikte overeenstemming nauwkeung en eenduidig vast te leggen. Duidelijkheid over de gemaakte afspraken zal ook de tarns op conflicten verminderen; aan conflicten liggen immers vaak verschillende mterpretaties van afspraken ten grondslag. Een in dit verband voor de ICT-sector specif iek kenmerk is het veelvuldig gebruik van Engelstalige technische en ook juridische termen (zoals specifieke garanties). Ian deze laaL komen in een Anglo-Amerikaanse context vaak specifieke rechtsgevolgen toe, welke in Nederland (althans in dwingendrechtelijke zm) ont• breken Dit kan snel leiden dan tot uitlegconflicten als gevolg van afstemmings; problemen tussen de gehanteerde taal en het van toepassmg verklaarde recht • Kermis en begrip van veelvoorkomende misverstanden in dit verband is dan ook ' eSentieel om via afdoende contractuele waarborgen potentiele mtlegconflicten e voorkomen. Zie meer uitgebreid hierover Drum", maar ook meer recent Tj ttes ' Om uitlegconflicten te voorkomen verdient een duidehjke, ondubbelzinmge en

14 15

ende misverstanden bij het gebruik van Anglo-Amerikaanse termen in internationale contracten', Contracteren 2008/2.

268

Hoofdstuk


tie vraa§ vers, en gevallen onderscl voorkorr

transparante vastlegging van de afspraken van partijen dan ook nadrukkelijk de voorkeur. Alles overziend, kunnen veel ICT-conflicten worden voorkomen door een samenspel van de volgende twee vragen: - de what-vraag: de te sluiten overeenkomst wordt gedegen voorbereid, waarbij voldoende aandacht wordt besteed aan de reikwijdte van de te leveren prestaties en de daaraan verbonden risico's, en de eenduidige vastlegging daarvan; - de what z/-vraag: bij elke overeengekomen verplichting of verdeling van verantwoordelijkheden dient te worden ingebeeld wat de situatie zal zijn indien de betreffende verplichting niet of niet tijdig wordt nagekomen dan wel niet of niet tijdig naar de overeengekomen verantwoordelijkheid wordt gehandeld (kortom: wat indien het anders loopt dan afgesproken?) Indien de antwoorden op deze vragen vervolgens helder en consistent worden vastgelegd in de overeenkomst, en daarbij ook sprake is van een zekere balans in het waarborgen van de belangen van elk der partijen, wordt een belangrijke bijdrage worden geleverd aan het verminderen van het risico op conflicten. Vervolgens is in het kader van contractmanagement een taak weggelegd om adequaat te handelen indien de what z/-vraag zich daadwerkelijk manifesteert.

12.4

Slotopmerkingen

ICT-projecten blijven fascineren, ook als object van contracten. In het in 2004 uitgebrachte rapport van de Royal Academy of Engineering and the British Computer Society16, word treffend opgemerkt dat eigenlijk wel bekend is hoe ITprojecten goed moeten worden aangepakt maar dat de 'lessons learned' niet in een collectief geheugen lijken te worden opgenomen. Het proces van de totstandkoming van ICT-contracten lijkt hiervoor ook niet immuun. Goede contracten zijn geen conditio sine qua non voor een succesvol project. Als IT-projecten mislukken mankeert er echter veelal wel ook het nodige aan de onderliggende contracten en (overige) projectdocumentatie. De kwaliteit, in ruime zin des woords, van IT-contracten is een van de (vele) factoren die het risicoprofiel van IT-projecten bepalen, en daarmee ook de kans op het ontstaan conflicten beinvloeden.

, „ ', , ,'

In de dagelijkse praktijk moeten er uiteraard ook als het gaat om de contractvor- \ ' ming steeds weer afwegingen worden gemaakt over de inzet van de per definitie /schaarse kennis en kunde. Maatvoering is ook hier van belang; niet elke transac- '

16

The Challenges of Complex IT Projects, Royal Academy of Engineering and the British Computer Society 2004 (www.raeng.co.uk).

269 Hoofdstuk 12

tie vraagt om een uitgebreid contracttraject. Zowel leveranciers als opdrachtgevers en n^Tvigeten de hen adviserende consultants, lijken echter in te veel revallen het being van tijdige en voldoende aandacht voor het contractproces te ondSc^en Een verdele professionalisering op dit punt kan veel conflicten voorkomen.

12 Voorkomen is beter dan genezen. ICT-contracten en conflictpreventie

Recommend Documents