Juridisch risicomanagement in IT-projecten Rens Jan Kramer 17 september 2015
Wie Mr. Rens Jan Kramer (36) advocaat sinds 2002 specialist IT-recht sinds 2010 Vestiging Maastricht-Airport Praktijkgroep Handelsrecht T 088-304 01 49 M 06 46 18 67 23
Citaat “De mislukking van een IT-project berust nooit op technische problemen, maar altijd op een managementprobleem”.
© Mr. H.B. Kramer a.k.a. “oom Harry” raadadviseur institutionele zaken, Algemene Rekenkamer
Voorbeelden
Voorbeeld A73: verkeers- en tunneltechnische installaties (vtti): Design- en Construct; 52 systemen, meer software dan in een Boeing 747.
“Tunnelregisseur” “Financiële angel” Geen duidelijke besluitvormingsstructuur Loskoppeling, vereenvoudiging Les: start met bepalen omvang en functies ICT
•
“Risico” + juridische risicogebieden Waarschijnlijkheid x gevolg = risico(niveau) Juridische risicogebieden
-
Wettelijke verplichtingen (b.v. privacy)
-
Contracten (b.v. ongewenste betalingsverplichtingen, beperkte opzegbaarheid) Rechten van derden (b.v. IErechten)
-
Aansprakelijkheden/procedures (b.v. nonconformiteit)
Risicomanagement algemeen Fase 1: Risicoanalyse: -
Scope
-
Potentiële gevaren
-
Bijbehorende risico’s
Fase 2: Risico evaluatie: -
Welke risico’s aanvaardbaar
-
Opties
Fase 3: Risico reductie: -
Besluitvorming
-
Implementatie
-
Monitoren
IT-contract = risicoverdeling Fase 1: Risico-analyse (vóór start contractsonderhandelingen): -
Request for Proposal : Wat zijn de doelstellingen?
-
Bijbehorende risico’s: Welke potentiële consequenties?
Fase 2: Risicoevaluatie (tijdens contractsvorming): -
Beslissing welke risico’s aanvaardbaar zijn: Hoe waarschijnlijk? Hoe hard onderhandelen?
Fase 3: Risico-reductie: -
Besluitvorming: Adresseren risico’s in juridische bepalingen
-
Implementatie
-
Monitoren: Contractmanagement!
Algemene risico’s IT projecten (I)
Uiteenlopende verwachtingen.
Geen duidelijke projectverantwoordelijkheid bij leverancier of afnemer. Onvoldoende invulling waarschuwingsplicht en onderzoeksplicht.
Onvoorziene organisatorische consequenties.
Algemene risico’s IT-projecten (II)
Ontbreken voldoende draagvlak, afzijdigheid management. Te ambitieus: Specificaties vooraf onvoldoende benoemd –> verschil van inzicht omtrent deliverables. Voortschrijdend inzicht: nieuwe “issues”, kosten, levertijd. Dubbelrol consultant/leverancier.
Traditionele of “Waterval”methode
Start: context, voorwaarden, planning Requirements: analyse, vaststelling en prioritering
Ontwerp: functioneel en technisch
Realisatie
Testen en Invoeren
Kenmerken Watervalmodel • Per fase eenduidige verantwoordelijkheid opdrachtgever en klant. • Afgebakend onderscheid in deliverables (requirements, functioneel/technisch ontwerp, code). • Go/no-go momenten aanwijsbaar. • Per fase een discipline betrokken. • Vaststaande scope.
Kenmerken Watervalmodel (II) • Meerwerk/scope change = discussie
• Gebreken pas aan slot openbaar • Acceptatietest juridiseert • Schuldvraag centraal • Star; weinig aanpassing gaandeweg
Statistieken Watervalmethode • 14% succesvol • 57% “betwist” (lees: mondde uit in geschil) • 29% geschrapt of anderszins mislukt
Agile-development methodes 1. Ontwikkeling in korte iteraties (“sprints”) deelfunctie direct operationeel. 2. Werk in multidisciplinaire teams van beide partijen. 3. Tussentijds wijzigende ‘back-log’ met ‘work-items’. 4. Testen gelijktijdig met bouwen. 5. Geen formele eindacceptatie. 6. In NL vrijwel altijd ‘Scrum’.
Varianten • Scrum • Kanban • Agile Datawarehousing, • Crystal
• Extreme Programming
Theoretische voordelen • Snelle ‘return on investment’ • Bijstellen doelen geen probleem • Klein afbreukrisico • Gebruikersorganisatie dicht op de realisatie
Theoretische nadelen •
Slechter of niet gedocumenteerde systemen (vendor lock in).
•
Onbeheersbaarheid aantal cycli (vertrouwen!).
•
Hoe weet ik voor hoe veel ik wat krijg?
•
Minder eenduidige aansprakelijkheid leverancier?
In NL ook vaak: mengvorm/grijs gebied •
Wel ‘het intensieve contract’/iteratieve ontwikkeling en samenwerking,
maar ook •
vast eindresultaat voor vaste prijs;
•
wel milestones.
Juridisch… Welke risico’s resteren?
Statistieken Agile-development methode • 42% projecten succesvol
• 49% werd betwist, lees: mondde uit in geschil • 9% geschrapt of anderszins mislukt
Bron: Standish Group CHAOS Report
Agile/Scrum in court Rb. Midden-Nederland 12 nov. 2014 (Netrom/Flexservice Solutions) Contract Netrom: -
“volledige no-cure-no pay garantie”
-
FENIT voorwaarden van toepassing
Agile/Scrum in court (ii) Gebreken bij finale oplevering:
- Volledig ontbreken van technische documentatie van de source code; - niet-voldoening aan ‘multilanguage eis’.
Agile/scrum in court (iii) Oordeel rechtbank: “Volgens de zogenaamde Agile/scrum methode gewerkt…” : “..niet meer dan inspanning, terbeschikkingstelling bekwame ontwikkelaars”.
“ Agile, dus aanpassingen gewoon bijbetalen”.
Agile/scrum in court (iv) Uitzonderingen (wanneer geen goed opdrachtnemerschap):
(a) Overschrijding deadlines (b) Niet-nakoming afspraken
Of schending zorg goed opdrachtnemer door: C-1 Inefficiënt werken C-2 Niet (adequaat)(laten) testen van resultaten C-3 Niet programmeren volgens objectief professionele standaard C-4 Niet waarschuwen van de opdrachtgever voor nadelige gevolgen instructies
Voorbeeld: geen goede beëindigingsregeling Vzr. Rb. Overijssel 1 mei 2015 (Fazzination/Landstede) -
Ontwikkeling sociaal netwerkplatform met Agile/Scrum methode.
-
Opdrachtgever zegt ovk op na pilot.
-
Leverancier vordert nakoming resterende projectduur.
-
Afwijzing: opdracht (7:408 BW) te allen tijde opzegbaar door opdrachtgever.
Kwalificatie IT-contract •
Ontwikkeling (al dan niet ‘agile’), overdracht, licentiëring; koop onderhoud en ondersteuning:
•
Veelal gemengde ovk-en, diverse sets wettelijke regels van toepassing.
•
Vb: aanschaf software. HR in Beeldbrigade-arrest: = “verbintenisrechtelijke” koop. Art. 7:17 BW (nonconformiteit) van toepassing maar software intrinsiek behept met fouten. Maar goederenrechtelijk? En auteursrechtelijk?
•
Duitsland: Werk- en geen Dienstvertrag!
Tip 1: Kort contract en juiste AV • Lang: bemoeilijkt contractmanagement en samenwerking. • Inkoop: b.v. ARBIT 2014; niet Nederland ICT voorwaarden. • Leverancier: b.v. Nederland ICT, eigen mantelovereenkomst.
Tip 2: Zorg voor goede governance • Betrek stakeholder bij project (demonstraties). • Vaste ‘productowner’, leg verantwoordelijkheid vast. • Documenteer besluitvorming in stuurgroep. • Vermijd ‘zweverige’ gezamenlijke verantwoordelijkheid. • Bij voorkeur geen externe projectleiding.
Tip 2: Scope + verwijzingen Beschrijf de scope globaal.
Koppel opdracht aan doelstellingen, functioneel ontwerp, opzet Back Log, offerte (verwijzen en aanhechten, niet stapelen!). Verwijzen naar notulen stuurgroep (aanhechten).
Tip 3: Benoem resultaatverplichtingen expliciet • Minimale functionaliteit + koppelbaarheid (ook in de toekomst!
• Tijd • (Software)kwaliteit – b.v. ISO norm 25010 • Continuïteit team (project owner/scrum master en projectleiding)
Tip 4: Garantie dat back-log realistisch is/blijft • Beding een Quality Assessment door derde (o.a. van de broncode); benoem criteria uit ISO norm. • Sanctie: sprints om niet of kortingen. • Voorkom perverse prikkels (uren: geen meerwerk; enkel extra ‘functiepunten)’.
Tip 5: Eerst herstellen, dan discussiëren •
Schadeformulier met wederzijdse visies
•
Beding vooraf: herstel, daarna financiële afwikkeling
•
Evt: ‘hersteliteraties’ achteraf
•
Of compensatie verloren ontwikkelcapaciteit
Tip 6: Maak ander ‘problem owner’ Opdrachtgever: benoem advies leverancier + daarop gebaseerde keuzes. Leverancier: benoem deskundigheid opdrachtgever en diens instructies inclusief geboden risico’s/alternatieven.
Tip 7: Maak tussentijdse exit mogelijk • Na afloop van elke sprint of te allen tijde (opzegtermijn). • Enkel vergoeding beschikbare functionaliteit.
• Medewerking leverancier, scenario’s, geen opschorting. Gedragscode Retransitie 2014 (platformoutsourcing.nl).
Tip 8: Beperk gevolgen ontbinding/beëindiging • Bewaar substantiële betalingstermijn voor het eind. • Geef opdrachtnemer een escape maar op een redelijke basis. • Sluit ongedaanmakingsverplichtingen bij ontbinding uit.
Tip 9: Sluit niet direct een onderhoudsovereenkomst/SLA
Niet na mislukking ook (jarenlange) onderhoudsverplichting!
Tip 10: Zorg voor overdracht auteursrechten • Standaarddelen: licentie; maatwerk: overdracht. • Stel bezit broncode maatwerk veilig ook na updates, releases.
Voorbeeld “Credits to your account shall be the sole and exclusive remedy in the event that there is no server availability”: - Verkapte exoneratie + uitsluiting ontbinding
Geschillenregeling • Mini-arbitrage: benoem onafhankelijke derde om gedurende het project volgens vooraf vastgestelde procedure snel – binnen 3 dagen - en goedkoop geschillen te beslechten (op bindendadvies basis). • SGOA-arbitrage.
Risico’s verwezenlijken zich toch? •
Meld fouten en gebreken z.s.m. na ontdekking, gedocumenteerd, schriftelijk, stel reële hersteltermijn.
•
Eerst formele positiebepaling, dan gemeenschappelijk belang.
•
Ga niet te snel mee in geboden alternatieven.
Vragen?
