Het is voor opdrachtgevers verre van eenvoudig om juridische actie te ondernemen wanneer een ict-dienstverlener faalt bij de uitvoering van een ict-project. Om tussentijds een ict-project te kunnen ontbinden en bijvoorbeeld schadevergoeding te ontvangen voor geleden schade, moet aan 'behoorlijk wat' voorwaarden worden voldaan. Dat schrijft ict-jurist Polo van der Putt in een artikel op de website IT en Recht.
'Veel ict-projecten lopen uit, kosten meer dan begroot of leveren niet de gevraagde functionaliteit', schrijft van der Putt. 'Vaak vertoont een project al tijdens de rit de eerste tekenen van mislukking. De wet biedt de afnemer dan soms de mogelijkheid om er tussentijds uit te stappen.' Aan deze 'voortijdige ontbinding zijn echter behoorlijk wat voorwaarden ontbonden, zo legt de ict-jurist uit. Dat geldt overigens ook wanneer de afnemer de opleverdatum wel afwacht.
Dit alles komt doordat rechters volgens de ict-jurist 'in het geval van ict-overeenkomsten een eigen invulling hebben gegeven aan het wettelijke systeem voor nakoming en tekortkoming.' Daardoor kunnen juristen volgens Van der Putt hun cliënten pas goed verdedigen wanneer ze op de hoogte zijn van de 'relevante jurisprudentie'. 'Anders kan plotsklaps blijken dat fatale termijnen toch niet fataal zijn, ingebrekestellingen geen rechtsvervolg hebben of dat een nakomingsbevestiging soms niet volstaat.'
Verzuim aantonen is lastig
De ict-jurist geeft in zijn artikel een aantal waarschuwingen aan medejuristen en afnemers. Ten eerste moet een opdrachtgever tijdig actie ondernemen. 'Als een afnemer niets doet wanneer de leverancier te kort schiet, kan hij het recht verliezen om zich later nog op tekortkoming te beroepen.'
Ten tweede moet dit op de juiste manier gebeuren. De opdrachtgever moet 'verzuim' aantonen, wil hij in zijn recht staan. Maar: 'Hoofdregel is dat verzuim pas intreedt nadat de schuldenaar een herkansingspoging heeft gehad en opnieuw heeft gefaald.'
Belangrijk is bovendien dat bij die herkaningspoging een termijn wordt gesteld. Van der Putt haalt een uitspraak aan van een rechter uit 2009 in een geschil tussen Fortis en ict-dienstverlener Raindrop, waarbij de rechter twee door Fortis gestuurde brieven niet wil aanmerken als ingebrekestellingen, omdat er geen termijn in wordt gesteld.
SAP
Daarnaast moet de ingebrekestelling 'de verweten gebreken met voldoende detail te beschrijven.' Van der Putt verwijst daarbij naar een rechtszaak van Waterdrinker tegen SAP. Omdat de kamer- en tuinplantenleverancier in een brief niet specifieert wat exact het probleem is, weigert de rechter 'ingebrekestelling' vast te stellen.
De opdrachtgever schrijft volgens Van der Putt namelijk aan SAP dat 'de geconstateerde tekortkomingen mogelijk nog te verhelpen zijn, maar dat Waterdrinker wegens een gebrek aan vertrouwen kiest voor beëindiging van het project.' De rechter ziet daarom geen aanleiding om te constateren dat er sprake is van 'een blijvende onmogelijkheid van nakoming'.
@John van Voren. Het ICT~Office contract is bedoeld als referentie en niet als letterlijke uitleg van een bepaalde situatie. Natuurlijk hebben grote bedrijven, eigen uitgebreide contracten als basis voor hun inkoop.
Naast een solide juridische basis, is het doorlopend managen van het project vanuit de afnemer een andere belangrijke pijler voor succes. En dan bedoel ik een projectmanager van niveau (die wordt aangestuurd door de persoon – directie niveau – die ook de onderhandeling en de contracten heeft gedaan), met voldoende mandaat om zijn opdrachtnemer te kunnen sturen. Naast mandaat is ook de beschikbare tijd voor projectmanagement een belangrijk aspect. In veel gevallen volgt een bedrijf de waan van de dag (of van de week), terwijl het uitgestippelde projectbeleid wordt ondergesneeuwd door de eisen van nieuw aangestelde businessmanagers.
Met andere woorden: “Denk al voor ge doende gaat en doende denk dan nog”.
@Prince2: specificaties voor “fit for use” en “fit for purpose” – wel even lezen: “Onderwerp van levering moeten de overeengekomen specificities zijn (géén verwijzing naar producten van de leverancier, maar naar bedrijfsprocessen van de afnemer)”
@jurist: wellicht is het boek “Lead IT or lose IT” van Nico Beenker wat voor jou?
@Henk: Jouw metafoor gaat op bij het leveren van een kant-en-klaar software pakket met optionele modules (auto met airco).
Voor zoiets is inderdaad een eenduidig leveringscontract op te stellen.
De schrijver heeft het echter over de ontwikkeling van nieuwe software (een nieuw model auto).
Van idee naar product is een lange weg en, zoals bij alle ontwikkeltrajecten het geval is, worden details pas tijdens het traject ingevuld.
Vertrouwen en goede samenwerking tussen de partijen is hierbij onontbeerlijk.
Het contract heeft dan ook eerder het karakter van een intentie-verklaring dan een specificatie.
Uiteindelijk komt het aan op de kwaliteit van hoe het projectwerk wordt gedaan zowel door uitvoerenden als leidinggevenden, hoe de teams samenwerken en blijven inspelen op veranderingen, welke kunde en kennis ieder an sich heeft en hoe soepel de samenwerking is met diegenen waar het project mee heeft te maken en hoe kundig en ervaren de opdrachtgever is. (Het-wij-ik-zij).
Overigens ben ik nog nooit een studie tegengekomen waarbij significante verschillen werden aangetoond bij falende projecten en niet-falende projecten. Kortom, zolang er geen degelijk onderzoek is geweest kan ieder roepen dat – vul in naar eigen keuze – procent van de projecten faalt.
In het artikel wordt ook ingegaan wat het doet met projectmedewerkers als ze steeds op projecten komen waar de stekker eruit wordt gehaald. Het primaire belang, als hij is gedetacheerd bij een klant, is dat zijn eigen werkgever hem “goed” houdt voor het volgende project.
Als je geluk hebt is er bij het project waar de stekker eruit is nog geld om te evalueren en te bepalen wat in soortgelijke situaties anders had gemoeten cq welke kennis en vaardigheden op een hoger peil moeten worden gebracht.
De discrepancy tussen wat een opdrachtgever van een
ICT project verwacht en wat de leverancier levert
kan verschillende oorzaken hebben:
1) begin :overenthousiaste consultants halen de
opdracht binnen en zeggen toe dat hun product alle
functionaliteit levert die gevraagd wordt vaak bezijden
de waarheid, want de developpers weten wel beter
Het is maar een deel van wat er gevraagd wordt
2) De manageers van de opdrachtgever moeten
hun mensen mee krijgen de nieuwe werkwijze te gaan
gebruiken, dat lukt niet altijd
2) Btoch wordt begonnen met inventarisatie van eisen, wensen planningen, inzet mensen en middelen maar
het inzicht ontbreekt hoe ze de alle
3) lopende het project worden de obstakels ontdekt,
mesnsen op andere projecten gezet