24. august 2017 Juridiske aspekter omkring udbud, køb og implementering af offentlige ITprojekter Ole Horsfeldt oho@gorrissenfederspiel.com
Emnet i dag er, hvordan vi bruger kontrakter i IT projekter. Hvad er vores paradigme og organisatoriske vaner, og hvad resulterer de i? To hovedpointer: - Vi anvender ikke aftaler, der afspejler vores behov - Sålænge vi fastholder vores nuværende paradigme og organisatoriske vaner, vil de fleste større IT-projekter være nødlidende Lad os sætte perspektivet: - Det meste fokus og den offentlig omtale omhandler implementeringsprojekter og ikke den efterfølgende drift - Men længden af driftsaftaler er 2-3 gange implementeringsaftalernes og omkostningerne langt
Er vi ikke dygtige nok, eller er vores rammebetingelser forkerte? VISION KONTRAKTSTYRING PROCESSER Projekt og samarbejde forankres i topledelsen Der styres efter fælles mål og efter de vigtigste forretningsmæssige behov De rette kompetencer matches og er til stede gennem hele projektet Governance og scope tilpasses projektets karakter og drøftes tidligt Problemer, udfordringer og risikoanalyser deles hele vejen gennem projektet Der holdes fokus på transparens og åbenhed Tidlig og vedvarende dialog dyrkes Agerer vi for det meste i henhold hertil? Principperne er åbenbart rigtige, men er det overhovedet muligt at agere efter dem under det nuværende kontraktparadigme?
Hvilken nytte vil vi opnå, når vi indgår IT-kontrakter? Driftssikre, sikre og brugervenlige systemer, der effektivt understøtter borgernes og myndighedernes behov Men hvordan kontraherer vi oftest? For ikke at overskride budgettet/bevillingen scopebeskyttelse fast pris bod og andet ansvar ved forsinkelse Reelt kan tilstrækkelig beskyttelse ikke opnås, medmindre risíkoen for de fleste uforudsete omstændigheder og andre risici overvæltes på leverandøren Paradigmet i dag (den organisatoriske vane) Start: Nyt system skal anskaffes Adfærd: Overvælt al risiko Belønning: Kunden kan Ikke holdes ansvarlig
Hvad sker i praksis? 1. Konsekvent undervurdering af risici fra både kunde og leverandør 2. Der indgås aftale på et ufuldstændigt grundlag eller med uperfekt viden 3. Leverandøren har reelt ikke forstået kundens behov og forventninger og opgavens kompleksitet 4. Kunden bliver klogere undervejs mht.. egen kunnen og funktionelle krav 5. Dårligt samarbejde opstår 6. Begge parter positionerer sig for at undgå ansvar Konflikt: forsinkelse, fordyrelse og fastlåste positioner uden incitament til at søge kompromisser
1. Når vi indgår kontrakter, er vi overansvarlige og for risiko adverse - vi indgår aftale ud fra en worst case betragtning og worst case er budgetoverskridelse 2. Men vores (kontrakt)-paradigme vores ønske om risikoovervæltning og forudsigbarhed og sikkerbed fører i sig selv til konflikt, fordi vi indgår aftale på grundlag af uperfekt viden 3. Når vi indgår og styrer efter paradigmet, undlader vi at sammenholde nytteværdien af implementering af effektive behovsopfyldende systemer overfor den potentielle tabsrisiko (budgetoverskridelsen) og vi værdiansætter heller ikke fordelene ved at blive klogere undervejs overfor en budgetoverskridelse. I det større perspektiv betyder det, at systemimplementeringer enten forsinkes eller opgives, fordi der fokuseres på tabet under aftalte kontraktvilkår fremfor nytteværdien.
Vi må fundamentalt ændre vores paradigme Men vores kontrakter og vores evne til at gennemføre og styre IT projekter har stået stille i de sidste 25 år Vi skal erkende, at det ikke er muligt at overvælte de fleste risici Vi skal erkende, at det er økonomisk mere effektivt som kunde at påtage sig flere risici Vi skal anskue vores IT projekter som en portefølje og ikke enkeltvist Vi skal styre efter at maksimere nytteværdien af nye systemer fremfor at undgå budgetoverskridelser Derfor skal vores kontrakter være baseret på: Kortere projektforløb og mindre idriftssættelser Formulering, opfyldelse og løbende tilpasning af krav skal være baseret på samarbejde, hvor kunden bærer den overordnede risiko for scope creep og budgettet Betaling efter tidsforbrug Reel mulighed for udskiftning af leverandøren Teknologien og mulighederne har ændret sig fundamentalt 1. 2. 3. 4. 5.
Alternativet til det nuværende paradigma er at tage ansvar for risici Start: Nyt system skal anskaffes Adfærd: Overvælt al risiko Belønning: Kunden kan Ikke holdes ansvarlig Start: Nyt system skal anskaffes Adfærd: Vurder og tag ansvar for at styre risici Belønning: Flere nye systemer implementeres hurtigere=højer e portefølje nytteværdi
Tom DeMarco: For the past 40 years, for example, we ve tortured ourselves over our inability to finish a software project on time and on budget. - DeMarco, 1995 But this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or transforms a company or how it does business Software development is and always will be somewhat experimental.