Projektkontrakter med fokus på gevinstrealisering Nicolai Dragsted, Bender von Haller Dragsted 14. juni 2012 Indledning • Digitalisering, effektivisering, besparelser - Behov drejer sig ikke om it og teknik. Behov er forretningsmæssige, og de opnåede forretningsmæssige gevinster er afgørende • Forretningsmæssige behov kan sættes i centrum for juridiske værktøj 2 Indledning Ad Polsag: Version 2, 8. marts 2012 Statens It-projektråd: Vi skal være bedre til at trække stikket Statslige institutioner har for lidt erfaring med store itprojekter og er for dårlige til at bruge den erfaring, de har, lyder det fra Lars Frelle-Petersen, vicedirektør i Digitaliseringsstyrelsen. Af Theis Holtz HansenTorsdag, 8. marts 2012 - 15:09 3 Indledning Version 2, 8. marts 2012: • Undervisningsministeriet spilder 36 millioner på itpilotprojekt • Undervisningsministeren kritiserer, at projektet fik lov til at køre i fem år, før det blev stoppet, selvom modellen var forældet. • »Der skal ikke anvendes flere midler til et it-projekt, som har et forældet koncept. Alternativet til at stoppe arbejdet nu vil være en risiko for, at endnu flere penge bliver spildt. Projektet har været i gang siden 2006, og det er beklageligt, at det ikke er blevet stoppet noget før 4 Statens it-projektmodel • • • • • Idé: Analyse: Projektoplæg BC, Gevinstrealiseringsplan, PID, Risikoanalyse Anskaffelse: Kravspecifikation, udbudsbetingelser, udbud, underskrive kontrakt Gennemførsel: Projektforløb Realisering: Høste gevinsterne 5 Fase Analyse Standarder Prince2 + Økonomistyrelsens skabeloner fra Q1 2011 Fokus for standard Fokus for ressourcer Anskaffelse (kravspecifikation) Ingen autoriserede paradigmer Anskaffelse (Udbud) Konsulenter Udbudsjurister Kontraktjurist Projektleder med fokus på teknik med fokus på udbudsregler med fokus på opfyldelse af kravspec. med fokus på projektledelse Ingen autoriserede paradigmer Økonomi Forretningsansvarlig med fokus på økonomi Anskaffelse (Kontrakt) Gennemførsel (Projekt) K01 og K02 Prince2 + standardkontrak diverse ter (opdaterede projektmetoder versioner af kontrakt fra 1987) Etablering af system Projektledelse defineret i kravspecifikation 6 Grundlæggende problemer Økonomistyrelsens skabeloner ser på ét projekt og tænker ikke på etablering af en kontrakt. Business case udfærdiges som alibi, ikke som aktivt værktøj i samspil med leverandør I business case og gevinstrealiseringsplan overses mange opgaver kunden har eneansvar for. I gængse standardkontrakter overses de grundlæggende forretningsmæssige behov, der ligger til grund for beslutningsgrundlaget. Der er slet ingen juridiske værktøj gearet til løbende prioritering efter de ofte dynamiske og skiftende forretningsmæssige behov. 7 Grundlæggende sammenhæng • Beslutningsgrundlag / forretningens behov  Business case  Gevinstrealisering • Udbudsmaterialet  Udbudsbetingelser med evalueringsmodel  Kravspecifikation • Kontrakt • Projektledelse 8 Business case og gevinstrealiseringsplan 9 Link mellem Business Case og kontrakt Business case proces Assessments Baselines Assumptions Business objectives Business Initiatives Business case Material Benefit candidates Improvements Realization plan IT contracts based on benefit realization Iterations Requirement specification Draft contract Mapping requirements and benefits Categorization of requirements Contract Business case og gevinstrealisering • Udgifter ved nyt system: Afholdes indledningsvis • Besparelser: Opnås senere • Cash flow: Afhænger af tidsplan • Gevinster: Opnås senere Udgifter er som regel sikre. Realisering af besparelser samt øvrige gevinster afhænger af forudsætninger og antagelser. Ved nogle forudsætninger og antagelser kan realiseringen deraf fremmes eller sikres i en kontrakt. Ved andre er kunden eneansvarlig for deres realisering. 11 Antagelser og forudsætninger • Forventet reaktion på nyt system  Kunde / rådgiver • Implementering og forandringsledelse  Kunde / Leverandør (som projektleder, rådgiver og forandringskonsulent) • Tidsplan (afgørende for besparelser og cashflow beregning)  Kunde / Leverandør (tid frem til indgåelse af kontrakt er kunden eneansvarlig for) • Teknologi (Funktionalitet og servicemål)  Leverandør Blå: Grøn: Indebærer krav til Kunden Indebærer krav til Leverandøren 12 Ansvar for antagelse/forudsætning Kategori af antagelse / forudsætning Ansvarlig Antagelser vedrørende reaktioner på nyt system (”markedets” / borgernes / ansattes / etc.) Kunden selv (eller ekstern rådgiver) Afvikling af udbud før kontraktindgåelse Kunden selv (eventuelt med bistand fra tredjemand) Implementering, uddannelse og forandringsledelse under samt efter projekt Kunden selv (eventuelt med bistand fra tredjemand eller leverandøren) Tidsplan (afgørende for beregning af cashflow) Kunden selv (frem til indgåelse af kontrakt) Leverandøren (efter indgåelse af kontrakt), dog kunden selv i mindre grad (ansvarlig for egne ydelser) Kvalitet af kundens egne projektressourcer, projektfaciliteter, dokumentation, værktøj, licenser, it-miljø og data Kunden selv (leverandøren eller tredjemand kan eventuelt bistå med forbedring eller etablering deraf) Yderligere teknologi (funktionalitet, servicemål) Leverandøren 13 Relation mellem gevinster og krav • Alle krav stilles for at business case kan realiseres og gevinsterne opnås • Kategorisering af krav efter vigtighed for business case     • MK (mindstekrav) K1 (afgørende krav) K2 (krav) K3 (mindre vigtige krav) Sammenhæng mellem hvert enkelt krav og business case bør mappes (kortlægges) 14 Eksempel på mapping Gevinst Spare 10 mio. i personaleudgift over 4 år ved etablering af selbetjeningsløsning Antagelse/forudsætning Detaljering af forudsætning Reducere med 2 ansatte i år 1 Omplacering eller og yderligere 3 ansatte i år 2 afskedigelse Forandringsledelse Tidsplan Borgerne vil benytte sig af den etablerede selvbetjeningsløsning Løsningen er let at acceptere, forstå og anvende for borgerne Krav Kunden skal ** Kunden skal ** Bonus til leverandøren ved hurtig accept og ibrugtagning hos borgerne Milepæle i kontrakt samt for anskaffelsesfasen Krav til leverandøren omkring servicemål Krav til leverandøren omkring usability Krav om ** Krav om ** Krav om ** Prioritering af krav Ud for hvert enkelt krav fastlægges en prioritet som enten MK, K1, K2 eller K3. Prioritet skal kunne begrundes i en kombination af det enkelte kravs teknologiske, procesrelaterede og forretningsmæssige betydning. 15 Eksempel på mapping Gevinst Antagelse/forudsætning Spare 10 mio. i personaleudgift over 4 år ved etablering af selbetjeningsløsning Løsningen er let at anvende for kunden og reducerer behov for indtastning af data Service løft Forkortede sagsbehandlingstider p.g.a. mere effektivt workflow ** Håndtering af eventuelt forøget antal henvendelser p.g.a. lettere adgang for berettigede borgere til at sende ansøgning ** Detaljering af forudsætning Fungerer integreret med øvrige systemer og passer til workflow Tage højde for økonomiske og arbejdsmæssige konsekvenser ved øget antal henvendelser Forandringsledelse Krav ** ** ** ** Krav til leverandøren vedr. ** Kunden skal ** Kunden skal ** Prioritering af krav Ud for hvert enkelt krav fastlægges en prioritet som enten MK, K1, K2 eller K3. Prioritet skal kunne begrundes i en kombination af det enkelte kravs teknologiske, procesrelaterede og forretningsmæssige betydning. 16 Mapping er led i kvalitetssikring • Efterprøver forudsætninger og antagelser • Kortlægger sammenhæng mellem business case og det enkelte krav  Er gevinsten sikret ved krav?  Bidrager kravet til sikring af gevinst?  Kan kravets betydning for gevinstrealisering berettige den valgte kategori (MK, K1, K2 eller K3) ?  Er kravet overflødigt og bør udgå? 17 Juridisk betydning af mapping Når business case og mapping indgår i kontraktens bilag, har det betydning efter den almindelige baggrundsjura • Forståelse og fortolkning af det enkelte krav • Betydning for mangelvurdering • Betydning for væsentlighedsvurdering • Betydning for erstatningskrav  Adækvans  Direkte eller indirekte tab 18 Prioriteringsgrundlag 19 Prioritering af ressourcer er afgørende! • Ingen kravspecifikationer er fejlfri • Projekter afvikles i en verden med knappe ressourcer, og projektlederne er altid under pres • Teknologiske, forretningsmæssige og politiske ændringer • Erkendelser undervejs i projekter • Tydelig prioritering giver projektdeltagerne tryghed • Klar prioritering støtter mere effektiv ressourceanvendelse • Kontraktmæssig opfyldelse er et relativt begreb 20 Krav som grundlag for prioritering • Kategorisering af krav (MK, K1 - K3) • Fastsættes på grundlag af business case og gevinster • Kategoriseringen indgår i kontrakt og kan benyttes som et prioriteringsgrundlag • Kontraktens bestemmelser relateres til og forankres i prioriteringsgrundlaget 21 Kontrakten 22 Grundlæggende kontraktfilosofi IT-kontraktens barndom • Kontrakten skal sikre levering af den vare, der defineres bedst muligt i en kravspecifikation Nutidens behov ved it-projektkontrakter • Forretningsmæssige behov skal i centrum, ikke teknik  understøtte opfyldelse af kundens business case  etablere rammer for optimering af kundens udbytte fra ressourcer anvendt til et projektsamarbejde  være et aktivt værktøj til planlægning, styring og samarbejde  danne grundlag for løbende prioritering og omprioritering af ressourceforbrug • Påstand: K-33, K-17, K-18, K01 og K02 gør i nogle sammenhæng mere skade end gavn! 23 Grundlæggende kontraktfilosofi Projektkontraktens formål: • Fastlægge en baseline for det ønskede resultat  Basalt juridisk sikkerhedsnet  Forretningsorienteret kravspecifikation • Fremme opfyldelse af kundens business case  Tydelig relation til business case  Prioriteringsgrundlag • Planlægge og styre samarbejde under projektet  Uddybning af ansvar for projektledelse, rådgivning og samarbejde  Beskrive tidsplan, organisation og projektmodel  Sikre gode rammer for kundens deltagelse i projektet 24 Link mellem Business Case og kontrakt Business case proces Assessments Baselines Assumptions Business objectives Business Initiatives Business case Material Benefit candidates Improvements Realization plan IT contracts based on benefit realization Iterations Requirement specification Draft contract Mapping requirements and benefits Categorization of requirements Contract Kravspecifikation • Forretningsmæssigt formulerede krav – SL07 • Non-funktionelle krav  Projektledelse  Rådgivning  Forandringsledelse • Prioriteringsgrundlag (Kategoriseringen MK, K1 – K3) • Business case, gevinstrealiseringsplan og mapping indgå i kontrakt som bilag til kravspecifikation (særlig vigtigt ved agile forløb) 26 Business case • • Brug i kontrakt eller kravspecifikation. F.eks. ERP12: ”8.1.3 Leverandøren skal i sin projektledelse tage hensyn til Kundens udgifter udenfor Kontrakten, jf. bilag 12C, og skal i sin projektledelse tage højde for sådanne udgifters indvirken på Kundens samlede business case” ”8.4 Prioritering og omprioritering: Leverandøren skal i sin projektledelse fokusere på de aktiviteter og etablering af den funktionalitet, der understøtter realisering af Kundens Business Case, jf. Leverancebeskrivelsen med tilhørende bilag 3a. …..” ”8.4.1: Hvor de enkelte kravs vigtighed er kvalificeret med angivelse af klassifikation (MK og K1-K3), skal Leverandøren, med mindre parterne aftaler andet, i sin projektledelse følge den anførte klassifikation ved at sikre prioritering af MK samt K1 kravs opfyldelse frem for K2 krav samt K2 kravs opfyldelse frem for K3 krav, jf. endvidere pkt. 8.6.2”” 27 Business case • Brug i kontrakt eller kravspecifikation. F.eks. ERP12: [19.4.2 Uanset om Kunden har taget Systemet i brug, er overtagelsesprøven aldrig bestået før eventuelle MK eller K1 krav, som i Kundens business case er identificeret som ”key enablers”, er opfyldt uden funktionshindrende mangler.] 28 Kategorisering af krav • Ved afregning efter T/M med estimat eller maksimum, eller ved agile forløb. ERP 12: ”8.6.1 Styringen af ressourceforbrug skal af Leverandøren varetages således, at (i) de aftalte milepæle (jf. bilag 1) kan overholdes, (ii) de i Kontrakten eventuelle beskrevne mindstekrav samt K1 krav overholdes, og (iii) de i Kontrakten anførte ressourcer er tilstrækkelige til etablering af Systemet” 29 God Contract Management forudsætter bl.a. løbende vedligeholdelse, opdatering og supplering af paradigmer og procedurer 30 Hvad indebærer god Contract Management? • Sammenhæng sikret: Beslutningsgrundlag – udbudsbetingelser – kontrakt – projektledelsen i projekterne • Sammenhæng sikret ved en kombination af standarddokumenter, vejledning til arbejdet med dokumenterne, fastlagte procedurer og uddannelse af aktørerne • Løbende evaluering og opdatering 31 Hvad er baggrunden for ERP12? • Ikke tilstrækkelig med en ny klon af K33/17/18/01/02. Gennemskrivning ud fra ny kontraktfilosofi • Business case og gevinstrealisering skal have en fremtrædende rolle • Større fokus på processen  Projektledelse  Prioritering  Økonomistyrelsens skabeloner 32 Kontaktoplysninger • Advokatvirksomheden BvHD www.bvhd.dk • Nyhedsbreve  www.bvhd.dk/nyhedsbrev-tilmelding Nicolai Dragsted  Telefon: 72 24 12 12  Direkte telefon: 39 14 16 25  Mobil telefon: 24 46 62 25  E-mail: nd@bvhd.dk 33 Om BvHD: • • • • • • • • • Største It-advokatvirksomhed i Danmark 18 advokater/jurister i København og Skanderborg Solid klientbase Alliance med Bird & Bird Specialist områder:  IT-kontrakter  Outsourcing  Open Source  Persondata  Udbudsret  Mediation,  Voldgifts-, klage- og retssager på vores kerneområder Forfatter til ca. 80% af dansk faglitteratur om it-kontrakter Arbejdet med it-kontrakter siden 1986 Specialistvirksomhed indenfor it-ret siden 1994 Skrev bidrag til it-udredningen Specialistrollen: It-kontrakter private sektor • Kundeside • Leverandørside It-kontrakter med ansvar for udbudsret • 4 regioner + tværregionale udbud • ca. 30 kommuner, herunder Københavns Kommune koncernservice • KOMBIT • En række forsyningsvirksomheder