IBM-saken om AutoPASS: heving av IKT-kontrakt

Sakens bakgrunn Partenes påstander og påstandsgrunnlag Den ankende part, Staten v/Samferdselsdepartementet, har i hovedtrekk gjort gjeldende: Ankemotparten, International Business Machines AS, har i hovedtrekk gjort gjeldende: Lagmannsretten bemerker 1 Innledning – Kravene, hovedspørsmålet og lagmannsrettens konklusjon 2 Overordnet blikk på tilbuds- og løsningsbeskrivelsesfasen 3 Var det inntrådt vesentlig mislighold på hevingstidspunktet? 3.1 Innledning – Partenes syn på de rettslige utgangspunktene 3.1.1 Hevingsvarselet som ramme 3.1.2 Sondringen mellom hoved- og biforpliktelser 3.1.3 Bevistemaet 3.2 Rammene som hevingsvarselet konkret setter i denne saken 3.3 Har IBM vesentlig misligholdt prosjektstyringen? 3.3.1 Innledning – Forholdene som lagmannsretten vil vurdere 3.3.2 Realistisk gjennomføringsplan 3.3.3 Reell fremdriftsrapportering 3.3.4 Verktøy

, herunder konfigurasjonsstyring og kravsporing 3.3.5 Bemanning og organisering 3.3.6 Estimeringen i tilbudsfasen og ut av løsningsbeskrivelsesfasen 3.3.7 Helhetlig logisk datamodell 3.3.8 Innsyn i arkitekturbeslutninger 3.3.9 De øvrige forholdene som kan påberopes og blir påberopt 3.3.10 Konklusjon – Inntrådt vesentlig mislighold 4 Var det klart på hevingstidspunktet at det ville inntre vesentlig forsinkelse (antesipert forsinkelse)? 4.1 Innledning – Partenes syn på de rettslige utgangspunktene 4.1.1 Beviskravet 4.1.2 Bevistemaet 4.2 Om IBM har gitt en utvetydig tilkjennegivelse for antesipert mislighold 4.3 Om SVV i virkeligheten mente at det ikke eksisterte en hevingsrett 4.4 Hadde IBM krav på fristforlengelse og flytting av milepæler? 4.4.1 Innledning – Oversikt over gruppene av forhold som kan begrunne fristforlengelse/flytting av milepæler og lagmannsrettens konklusjon 4.4.2 Ferie 4.4.3 Fristforlengelse på grunn av endringsanmodninger hvor konsekvensen hadde inntrådt da kontrakten ble hevet – Noen fellesspørsmål 4.4.3.1 Innledning 4.4.3.2 Kontraktens regler om endringer 4.4.3.3 Særlig om iterative prosesser 4.4.3.4 Generelt

om endringer under konstruksjonsfasen 4.4.4 EA053 Økt kompleksitet 4.4.4.1 Innledning – Behandlingen av EA053 4.4.4.2 Partenes anførsler 4.4.4.3 Utgangspunkter for lagmannsrettens drøftelse 4.4.4.4 Fritaksregler 4.4.4.5 ACT- og TST-fil 4.4.4.6 Brukergrensesnitt 4.4.4.6.1 Innledning 4.4.4.6.2 Endringer i kundebildet – «Ett stegs registrering» 4.4.4.6.3 Brikkelogistikk og fjerning av brukergrensesnittet «bomsnitt» 4.4.4.7 Økt kompleksitet LB-2020-82571-2 4.4.4.7.1 Innledning 4.4.4.7.2 «SAP i CRM» – Merarbeid på grunn av økt kompleksitet i tilknytning til EA018 4.4.4.7.3 Brukerhistorien UC_CM_03 (Håndtere sak) 4.4.4.7.4 Brukerhistorien UC_AM_05 (Ny avtale) 4.4.4.7.5 Brukerhistorien UC_AM_ADM_13 (Bompakke) 4.4.4.7.6 Brukerhistorier i tilknytning til brikkelogistikk 4.4.4.7.7 Andre brukerhistorier i gruppen «økt kompleksitet» 4.4.4.8 «Annet» 4.4.4.9 Oppsummering – gruppene av brukerhistoriene i EA053 4.4.4.10 Statens generelle innsigelser til EA053 4.4.4.10.1 Om IBM kan kreve endring for arbeid som allerede er utført 4.4.4.10.2 Om arbeidet i EA053 var på kritisk linje 4.4.4.10.3 Om usikkerhetsmatrisens betydning for de endringer som kan

kreves 4.4.4.10.4 Statens øvrige innsigelser 4.4.4.11 EA053 – Konklusjon 4.4.5 EA054 Arbeidsform 4.4.5.1 Innledning – Behandlingen av EA054 4.4.5.2 Partenes anførsler 4.4.5.3 Om IBMs krav er et «plunder og heft»-krav 4.4.5.4 Kontraktens bestemmelser om leverandørens plikter og kundens medvirkning 4.4.5.5 Usikkerheten knyttet til SVVs gjennomføringsevne 4.4.5.6 Rapporter om fremdriftshindringer i konstruksjonsfasen 4.4.5.7 Om ansvaret for å bidra til en standardløsning 4.4.5.8 Fritaksberettigede kjøretøy – buss i rute 4.4.5.9 Audit fields (revisjonsspor) 4.4.5.10 Avtalestruktur 4.4.5.11 Bompakke 4.4.5.12 Aksjoner i «Tasks» 4.4.5.13 EA054 – konklusjon 4.4.6 EA067 Greenbird 4.4.7 EA078 Kina-saken 4.4.7.1 Innledning og partenes anførsler 4.4.7.2 Lagmannsrettens syn 4.4.8 Underkjenningen av kontrollpunkt 2 (KP2) 4.4.8.1 Innledning – Betydningen av KP2 for IBMs krav på fristforlengelse/flytting av milepæler 4.4.8.2 Hva som etter kontrakten skal skje i et kontrollpunkt 4.4.8.3 Behandlingen av KP2 4.4.8.4 Volumet som grunnlag for å underkjenne KP2 4.4.8.5 Testrapporten som grunnlag for å underkjenne KP2 4.4.8.6 Gjennomføringsplanen som

grunnlag for å underkjenne KP2 4.4.9 EA108, 113 og 117 4.4.10 EA112 (R8 miljø) 4.4.11 Oppsummering 4.5 Kunne IBM nådd HMP2 til 5.1 april 2016/HMP2.2 til 12.2 august 2016? 4.5.1 De sakkyndiges vurderinger av når HMP2 kunne vært nådd 4.5.2 Lagmannsrettens vurdering av når HMP2 og HMP2.2 kunne vært nådd 4.5.2.1 Innledning – Metoden 4.5.2.2 Ressursene som var trukket ut av iterasjon 3 4.5.2.3 DCUT-arbeidet i iterasjon 3 4.5.2.4 Iterasjonstesten av iterasjon 3 og SIT 4.6 Konklusjon – antesipert vesentlig forsinkelse 5 Vederlag 5.1 Innledning 5.2 Kort om vederlagsmekanismen i Leveranseavtalen LB-2020-82571-2 5.3 Betaling for programvare 5.4 IBMs krav på betaling for utført arbeid 5.5 Beregning av målprisen 5.6 Målpristaket 5.7 Endringer som ikke inngår i målprisen 5.7.1 Innledning 5.7.2 EO064 – Preventive aksjoner grunnet EA078 5.7.3 EA069 – PRO Planarbeid 5.8 Vederlag under Finansieringsavtalen – IBMs påstand post 2 5.9 Ubetalte fakturaer 5.10 Oppsummering – IBMs vederlagskrav 5.11 IBMs krav om erstatning/avbestillingskompensasjon 5.11.1 Erstatning/avbestillingskompensasjon etter Leveranseavtalen 5.11.2 Avbestillingskompensasjon i

medhold av avtalene om vedlikehold og drift 5.12 Renter 6 Sakskostnader LB-2020-82571-2 Saken gjelder krav om erstatning og vederlag etter heving av avtale om levering av en informasjons- og kommunikasjonsteknologiløsning (IKT-løsning) for innkreving av bompenger.

Sakens bakgrunn

Statens vegvesen (SVV) og International Business Machines AS (IBM) inngikk 20. desember 2013 avtale om levering av en IKT-løsning for innkreving av bompenger i Norge (Leveranseavtalen). SVV og IBM inngikk samtidig tre andre avtaler: en om drift- og forvaltning, en om videreutvikling og konsulentbistand og en om finansiering (Finansieringsavtalen). Oslo tingrett har beskrevet bakgrunnen for avtaleinngåelsen slik: AutoPASS er det norske systemet for innkreving av bompenger. Med AutoPASS-avtale og bombrikke belastes bilpasseringer automatisk i alle tilknyttede bompengeanlegg. Bompengeanleggene styres av bompengeselskaper opprettet for å delfinansiere veiprosjekter. Kommuner og fylker er vanligvis majoritetseiere. På kontraktstidspunktet var normen at det ble opprettet ett bompengeselskap for hvert veiprosjekt, slik at antallet var over 50. De fleste har satt ut den operative innkrevingen til et driftsselskap. SVV er den utøvende myndighet på vegne av staten og Stortinget, og fastsetter de tekniske kravene til AutoPASS.

I AutoPASS er det en felles sentral IKT-løsning som administrerer kundeforhold, bearbeider alle data om passeringer i bomstasjoner, klargjør faktureringsgrunnlag for bompengeselskapene og foretar avregninger mellom disse. I 2006 ble det inngått avtale med Q-Free ASA om utvikling og drift av en slik sentral IKT-løsning. Dette sentralsystemet fikk navnet CS Norge. SVV ervervet ikke eiendomsretten, men inngikk avtale med Q-Free om bruk og drift av løsningen. SVV gjennomførte i 2011 et forprosjekt for å vurdere hvilket konsept som skulle velges i forbindelse med at avtalen med Q-Free løp ut. Konklusjonen ble at SVV skulle anskaffe en egen IKT-løsning som skulle erstatte CS Norge. Prosjektet fikk navnet AutoPASS Grindgut. Leveranseavtalen er basert på kontraktstandarden PS2000 og består av tre deler: Kontraktdokumentet (del I), Generelle kontraktsbestemmelser (del II) og Bilag A til H (del III). Bilag A inneholder i korthet SVVs behovsanalyse, IBMs grove løsningsforslag og en usikkerhetsmatrise. Bilag B inneholder administrative bestemmelser. Bilag C inneholder bestemmelser om gjennomføringen.

Drifts- og forvaltningsavtalen og videreutviklings- og konsulentbistandsavtalen er basert på statens standardavtaler (SSA-D, SSA-F, SSA-U og SSA-B). Tingretten har beskrevet PS2000 med milepæler slik: PS2000 er utarbeidet for systemutviklingsprosjekter hvor det ikke er hensiktsmessig eller mulig på forhånd å fastsette nøyaktige eller detaljerte spesifikasjoner, og hvor det er usikkerhet ved prosjektgjennomføringen. Gjennomføringsmodellen illustreres slik:

Fig ur 1. Gjennomføringsmodell Hver hovedfase avsluttes ved en hovedmilepæl (HMP). I Leveransekontrakten er hovedmilepælene for løsningsbeskrivelsesfasen (HMP1), konstruksjonsfasen (HMP2) og godkjenningsfasen (HMP3) satt til 13. februar 2014, 14. oktober 2014 og 19. mars 2015. Fremdriftsplanen inneholder i tillegg tidspunkter for øvrige milepæler i de enkelte fasene. Konstruksjonsfasen (KF) gjennomføres etter en iterativ (repeterende) prosjektmodell som tar høyde for at rammebetingelser, muligheter og behov kan endres underveis i prosessen. Ved avslutning av hver iterasjon gjøres det en evaluering, samtidig som en ny iterasjon planlegges. De iterative prosessene innebærer bevisste gjentakelser for å få økt grad av måloppnåelse gjennom stadige forbedringer, jf. Veilederen til PS2000 v. 3.1 side 5 og Føyen mfl., Kontrakter for utarbeidelse av programvare, 2006, side 64. Konstruksjonsfasen inneholder den første dagbotsanksjonerte milepælen, som er HMP2.2. I milepælsplanen i Bilag C var den satt til 8. januar 2015. Leveranseavtalen ble inngått etter konkurranse med forhandling.

Oppstarten av løsningsbeskrivelsesfasen ble forsinket fordi en av de andre tilbyderne – BT Signaal – begjærte midlertidig forføyning mot SVVs beslutning om å tildele kontrakten til IBM. Denne forsinkelsen førte til den første endringen av milepælene (EO001). Tingretten har beskrevet IBMs løsning for AutoPASS Grindgut slik: Løsningen til IBM besto av ulike samarbeidende applikasjoner og var basert på deres Road User Charging Asset (RUC) som var tatt i bruk i storbyene Stockholm og Brisbane. De mest sentrale applikasjonene var SugarCRM (kunde- og saksbehandling), SAP FI-CA (økonomi), Cognos (rapportering) og IRIS (identifikasjon og prising). De tre førstnevnte er kommersielt tilgjengelige standardprodukter som IBM har tilpasset bompengeformålet. IRIS er spesialutviklet av IBM. IBM hadde brukt RUC ikke bare i Stockholm og Brisbane, men også i bompengeløsningen for London. IBM planla å oppgradere RUC før oppstarten av løsningsbeskrivelsesfasen for AutoPASS Grindgut slik at utviklingen kunne tuftes på demoløsninger. Arbeidet med å oppgradere RUC (enhancement-prosjektet) ble forsinket.

Videre hadde IBM aldri brukt SugarCRM i noen bompengeløsning tidligere. Grindgut-prosjektet var mer komplisert enn de tre tidligere bompengeprosjektene. I tilbudet til SVV estimerte IBM likevel å forbruke langt færre timer på Grindgut enn på det mest sammenliknbare prosjektet – Brisbane. IBM la opp til at utviklingen av AutoPASS Grindgut skulle skje som en Global Delivery (GD) med ett leveransesenter lokalt i Norge (GEO) og fem leveransesentre i India og Kina. Etter hvert ble antallet leveransesentre utenfor Norge redusert til fire. Offshore-andelen var over 70 prosent. PS2000 er en samspillskontrakt. Konsulentfirmaet A-2 Norge AS (A-2) ble utpekt som uavhengig kvalitetssikrer i prosjektet. Tingretten har beskrevet organiseringen av prosjektet slik: SVVs arbeid var organisert i delprosjektene Anskaffelse, Leveranse og Innføring. Disse hadde en felles styringsgruppe [SG] som besto av ledere fra SVV, representanter fra bompenge- og driftsselskapene, SVVs prosjektledelse i Grindgut og KPMG som kvalitetssikrer. Styringsgruppen rapporterte til Vegdirektøren.

IBMs arbeid inngikk i delprosjektet Leveranse, og IBM ble tidvis invitert til enkelte møter i styringsgruppen, oftest for å orientere om enkeltpunkter på agendaen. I tråd med PS2000 ble det opprettet en felles koordineringsgruppe (KG) med representanter fra SVV, IBM og A-2. KG møttes som regel én gang i måneden og koordinerte utførelsen av Grindgut som prosjektets øverste administrative funksjon. Det ble holdt 24 møter før Leveransekontrakten ble hevet. SVV og IBM utpekte hver sin prosjektleder. IBMs prosjektleder hadde det daglige ansvaret for planlegging, organisering og ledelse slik at arbeidet ble utført i henhold til kontraktsforpliktelsene. IBM leverte månedlige statusrapporter på fremdriften i prosjektet. SVVs prosjektleder hadde ansvaret for å lede arbeidet med SVVs forpliktelser og å koordinere dette med IBMs prosjektleder. Felles prosjektledermøter ble holdt én gang i uken, hvor også A-2 ofte deltok. Det ble holdt 55 prosjektledermøter før heving. Prosjektarbeidet ble organisert i følgende tretten arbeidsstrømmer.

Strømmene som omtales mest i denne saken er CRM (kunde- og saksbehandling), FIN (økonomi), INT (integrasjon) og IRIS (Identification, Rating and Interoperability Services). De øvrige strømmene var AMS (Forvaltning), ARC (Arkitektur), INF (Infrastruktur), MIG (Migrasjon), REP (Rapportering), SEC (Security), SEL (selvbetjening), TES (Test) og TRA (Opplæring). Opprinnelig var det også en fjortende strøm – Roadside Gateway (RSGW). RSGW ble etter hvert en del av IRIS-strømmen. Tingretten har beskrevet hva som skjedde i løsningsbeskrivelsesfasen (LBF) slik: LBF som startet 17. januar 2014 tok lengre tid enn forventet. Etter enighet ble HMP1 utsatt til 30. mai 2014. Løsningsbeskrivelsen som ble levert 20. mai ble underkjent av SVV. IBM leverte på nytt i slutten av juni. Med noen restanser ble denne løsningsbeskrivelsen godkjent 4. juli 2014, slik at prosjektet gikk inn i KF. Ved HMP1 ble ansvaret for den inntrådte forsinkelsen diskutert. De økte kostnadene ble fordelt mellom partene, med omlag 35 prosent på SVV. I tillegg ble fristene for HMP2 og HMP3 endret til 28. april og 13. november 2015, jf. EO042.

Løsningsbeskrivelsesfasen tok dobbelt så lang tid som planlagt. SVV aksepterte å dekke 4 prosent, og ikke 35 prosent, av kostnadene ved denne forsinkelsen. Ved EO042 ble HMP2.2 satt til 4. september 2015 og HMP2.3 satt til 13. november 2015. Kontraktspartene endret ikke på milepælene etter dette. Den godkjente løsningsbeskrivelsen med restanser er en del av kontrakten. Løsningsbeskrivelsen danner grunnlaget for gjennomføringen av konstruksjonsfasen. Dens hovedformål er å verifisere og forankre kontraktspartenes felles forståelse av kravene til leveransen. Tingretten har beskrevet hva som skjedde i konstruksjonsfasen (KF) slik: Etter at løsningsbeskrivelsen var godkjent, skulle leveransen utvikles gjennom tre iterasjoner. SVV skulle evaluere gjennomføringen av en iterasjon i et kontrollpunkt som etterfulgte testing av iterasjonen. Fullføring av en iterasjon representerte en milepæl, som igjen var knyttet opp mot en betalingsplikt for SVV. Ved leveransen til hvert kontrollpunkt skulle IBM levere en plan for neste iterasjon til godkjenning av SVV. IBM hadde i starten av KF problemer med å få opp produktiviteten på et ønsket nivå.

Innhold fra iterasjon 1 ble derfor flyttet til iterasjon 2. Leveransene i iterasjon 1 ble demonstrert for SVV i møter 8-10. oktober 2014. Det første kontrollpunktet (KP1) ble holdt i perioden 15-21. oktober 2014. Ifølge [...] A-2 [...] var det levert knapt 15 prosent av det totale omfanget – om lag halvparten av det som var planlagt. KP1 ble aldri formelt godkjent av SVVs prosjektledelse, men SVVs styringsgruppe vedtok likevel betaling til IBM 19. desember 2014.

KP2 med avsluttende kontrollpunktmøte 28. april 2015 ble ikke godkjent av SVV. Begrunnelsen var at testrapporten hadde mangler, IBM hadde levert mindre enn avtalt av løsningen og at fremdriftsplanen var urealistisk. IBM bestred underkjenningen av KP2. I prosjektledermøte 10. juni 2015 opplyste IBM at leveransen til KP2 omfattet 80 prosent av planlagt innhold for iterasjon 2 ved KP1, og at selskapet ville prioritere å levere de resterende 20 prosentene til et nytt kontrollpunkt. Arbeidet med den resterende 20-prosenten, ble kalt iterasjon 2.5. Videre ble ressursene som hadde begynt arbeidet med iterasjon 3 i delvis parallell med iterasjon 2, trukket ut av prosjektet. Tvisten om underkjenningen av KP2 ledet til avslutningen av avtaleforholdet. Tingretten har beskrevet avslutningen slik: SVV ga hevingsvarsel 22. juni 2015. Det ble gjort gjeldende at Leveransekontrakten kunne heves med grunnlag i både inntrådt og antesipert vesentlig mislighold. SVV hevet denne og tilhørende avtaler 27. juli 2015. IBM mente hevingen var uberettiget og et vesentlig mislighold.

De valgte selv å heve Finansieringsavtalen 5. august, og Leveransekontrakten med øvrige tilhørende avtaler 14. august 2015. IKT-løsningen, så langt den var utviklet, har ikke vært tilgjengelig for partene eller retten under rettssaken. Løsningen var installert i driftsmiljøet hos firmaet Basefarm. IBM sørget for back-up i tråd med SVVs EO061 i juni 2015. SVV betalte ikke, og etter hevingen ble den fysiske infrastrukturen koblet ned og back-up ikke opprettholdt. Staten v/Samferdselsdepartementet reiste 29. mars 2016 søksmål mot IBM for Oslo tingrett med krav om erstatning fra IBM. IBM tok til motmæle og krevde vederlag fra staten. Oslo tingrett avsa dom 31. januar 2020. Tingretten mente i korthet at SVVs heving ikke var rettmessig; det var SVV som hadde misligholdt sine medvirkningsforpliktelser. Dommen hadde slik domsslutning:

1. International Business Machines AS frifinnes.
2. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS 75 586 016 – syttifemmillionerfemhundreogåttisekstusenogseksten – kroner i vederlag under Leveransekontrakten med tillegg av lovens til enhver tid gjeldende forsinkelsesrente fra 14. september 2015 til betaling skjer.
3. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS 61 002 016 – sekstienmillionertotusenogseksten – kroner i vederlag under Finansieringsavtalen med tillegg av lovens til enhver tid gjeldende forsinkelsesrente av 7 964 072 – syvmillionernihundreogsekstifiretusenogsyttito – kroner fra 7. august 2015 til betaling skjer og 53 037 944 - femtitremillionertrettisyvtusennihundreogførtifire – kroner fra 4. september 2015 til betaling skjer.
4. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS 2 565 045 – tomillionerfemhundreogsekstifemtusenogførtifem – kroner i erstatning med tillegg av lovens til enhver tid gjeldende forsinkelsesrente fra 14. september 2015 til betaling skjer.
5. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS sakskostnader med 42 071 288 - førtitomillionersyttientusentohundreogåttiåtte – kroner. For nærmere detaljer vedrørende saksforholdet vises det til tingrettens dom og lagmannsrettens bemerkninger nedenfor.

Staten v/Samferdselsdepartementet har anket dommen til Borgarting lagmannsrett. IBM har inngitt avledet anke.

Ankeforhandling er holdt over 56 rettsdager fra 13. januar til 6. mai 2022 i Borgarting lagmannsretts hus. Partene møtte ved sine prosessfullmektiger. Det ble avhørt i alt 21 – hvorav fire sakkyndige – vitner. Om bevisføringen for øvrig vises det til rettsboken.

Partenes påstander og påstandsgrunnlag Lagmannsretten gjengir her partenes påstandsgrunnlag i sammenheng, men vil i en del utstrekning også utdype partenes påstandsgrunnlag under lagmannsrettens bemerkninger.

Den ankende part, Staten v/Samferdselsdepartementet, har i hovedtrekk gjort gjeldende: SVVs heving av kontrakten var rettmessig. Tingretten har verken forholdt seg til kontraktens bestemmelser om løsningsbeskrivelsesfasens funksjon eller Høyesteretts retningslinjer for vurdering av begivenhetsnære bevis og «plunder og heft»-krav. Tingretten har ignorert flere av statens sentrale anførsler, særlig anførselen om lav kompetanse i CRM-strømmen. Tingretten har feilaktig lagt til grunn at IBMs rapportering av Earned Value (EV) ga et dekkende bilde av fremdriften i prosjektet og at IBMs økning i Estimate at Completion (EAC) nesten utelukkende skyldtes nye krav fra SVV om funksjonalitet («scope creep»). Problemet var at IBM hadde underestimert prosjektet. Tingretten har ikke forstått at SVVs hovedhensikt med prosjektet var å få oppfylt behov i bompengedriften, og ikke å ta i bruk standardkomponentene SugarCRM, SAP FI-CA, Cognos og IRIS. Tingretten har ikke forholdt seg til at IBM besvarte SVVs behovsbeskrivelse med at 50 prosent av kravene måtte oppfylles ved en eller annen form for tilpasning av disse fire standardkomponentene.

Tingretten har ikke fått med seg at IBM fikk gjennomslag for at mye av designarbeidet skulle gjøres i konstruksjonsfasen. SVV satte som forutsetning for å akseptere IBMs løsningsbeskrivelse at vegvesenet ikke skulle overta risikoen for at det gjensto mye arbeid med use casene (brukerhistoriene) i CRM-strømmen. SVV misligholdt ingen medvirkningsforpliktelser, jf. Bilag C punkt 4.2.1.5, 4.2.2.6 og 4.3.12. SVV misligholdt ingen forpliktelse knyttet til å begrense spesialutvikling. SVV sto fritt til å bestille endringer, jf. Generelle kontraktsbestemmelser punkt 3.6.1 første avsnitt. Det var IBM som måtte passe på at SVVs ønsker ikke lå utenfor det som IBM hadde forpliktet seg til å utvikle, jf. punkt 3.6.1 andre og tredje avsnitt. IBM skulle også sikre at det ikke ble mer spesialutvikling enn nødvendig og bruke demoløsninger, jf. SVVs behovsanalyse i Bilag A punkt 2.2.5 og IBMs svar til GK.01.07 Standardisering av arbeidsprosesser. På grunn av forsinkelsen i enhancement-prosjektet, etterlevde ikke IBM denne prosessen i løsningsbeskrivelsesfasen.

Kontraktspartene var enige om at IBM skulle sikre at det ikke ble mer spesialutvikling enn nødvendig også i konstruksjonsfasen, jf. tiltak nr. 111 i usikkerhetsmatrisen. SVV fremsatte ingen nye krav som medførte spesialutvikling i konstruksjonsfasen. Under enhver omstendighet la IBM – tross gjentatte oppfordringer – ikke til rette for at SVV kunne bidra til redusert spesialutvikling. SVV hindret ikke IBMs fremdrift i konstruksjonsfasen ved sene avklaringer. Kontrakten inneholdt ingen regulering av hvor raskt SVV måtte komme med avklaringer. Hvis SVV hindret fremdriften, misligholdt IBM sitt overordnede ansvar for prosjektstyringen, jf. Bilag B punkt 2.5.5 og juridisk teori. IBM bekreftet gjentatte ganger høsten 2014 at SVV ikke hindret fremdriften. IBM eskalerte ikke at SVV hindret fremdriften, men lette etter endringsanmodninger. Det fins ikke spor i begivenhetsnære bevis for at SVV hindret fremdriften nevneverdig høsten 2014 ved håndteringen av fritaket «buss i rute» eller andre spørsmål.

Det kan ikke være brudd på en medvirkningsforpliktelse at SVV krevde at IBM fulgte samarbeidsprosessen som var avtalt i løsningsbeskrivelsen, jf. PRO006 Arbeidsprosesser. Grunnen til IBMs svake fremdrift var mangel på kunnskap om SugarCRM og mangel på CRM-eksperter i det lokale teamet. Det fins heller ikke spor i begivenhetsnære bevis for at SVV hindret fremdriften våren 2015. Undersøkelsene som ble gjort med sikte på å finne ut av årsaken til den svake fremdriften fra januar 2015, medførte bare tiltak på IBMs hånd. IBM fremsatte ingen endringsanmodninger våren 2015 basert på at SVV hindret fremdriften og har mistet retten til å påberope seg disse forholdene, jf. Generelle kontraktsbestemmelser punkt 3.6.1. Sett på bakgrunn av at SVV tapte rundt 10 millioner kroner i måneden på denne tiden, er fraværet av endringsanmodninger et sterkt bevis på at SVV ikke utgjorde noen hindring våren 2015. SVV misligholdt ingen medvirkningsforpliktelse ved oppfølgningen av IBMs planverk, fremdriftsrapportering, prosjekthåndbok og logiske datamodell. SVV hadde full rett til å følge opp at IBM etterlevde sine kontraktsforpliktelser.

IBM skulle utarbeide en gjennomføringsplan som kunne brukes som styringsgrunnlag, jf. restansene R1, R3 og R5 til IBMs løsningsbeskrivelse og PRO006. Det var IBM som bestemte at planene skulle detaljeres ned på «use case»-nivå. At SVV hadde 80 til 100 skriftlige kommentarer til planene, må ses i

sammenheng med at de var på 1 200 til 1 400 linjer. Planene holdt også lav kvalitet. IBMs ressurser som jobbet med planene, ønsket ikke å samarbeide med SVV enda partene skulle det, jf. Bilag C punkt 4.3.2. IBM laget aldri noen plan som selskapet klarte å overholde. IBM erkjente etter hvert grunnleggende mangler ved sin egen EV-rapportering. SVVs kommentarer til prosjekthåndboken kan ikke ha skapt nevneverdige utfordringer for IBM. SVVs kontinuerlige bestrebelser med sikte på å få IBM til å utarbeide en helhetlig logisk datamodell, var sårt tiltrengt som grunnlag for IBMs utviklingsarbeid og berettiget siden PS2000 er en samspillskontrakt. IBM forpliktet seg til å utarbeide en logisk datamodell i løsningsbeskrivelsesfasen og til å oppdatere den i alle iterasjonene i konstruksjonsfasen, jf. Bilag C punkt 7, ARC005 i leveranselisten til HMP1 og MIG002. Den skulle også dekke økonomidata, jf. forklaringen fra SVVs arkitekturansvarlige, Mihaly Fekete. IBM arbeidet usystematisk og silobasert med den logiske datamodellen og gjorde den aldri ferdig.

Den konseptuelle datamodellen som ble presentert i juni 2015 var et godt utgangspunkt, men tilfredsstilte ikke kravene til en fullverdig logisk datamodell. Som en konsekvens av at IBM brøt forpliktelsen til å utarbeide en logisk datamodell, ble migreringsstrømmen forsinket. At en helhetlig logisk datamodell ikke ble ferdigstilt, medvirket sannsynligvis også til at IBM aldri fikk integrert komponentene i løsningen før hevingen. SVV misligholdt ingen medvirkningsforpliktelse knyttet til styringsparametere. Kontrakten regulerer ikke hvilke styringsparametere som SVV kan prioritere. EA035/040 ble ikke underkjent fordi SVV endret styringsparametere, men fordi endringsanmodningen bare var til fordel for IBM og stor ulempe for SVV. IBMs eneste formål med å fremsette denne endringsanmodningen, var å unngå å komme i mislighold. IBM var da innforstått med at det var liten sannsynlighet for at kontraktspartene ville klare å utarbeide en kuttliste med tilstrekkelig volum til å påvirke fremdriftsplanen. SVV kan ikke bebreides for manglende samlokalisering. Det var IBM som hadde plikt til å stille med lokaler.

SVV motsatte seg ikke IBMs forslag om å organisere samspillet etter team. IBM kom imidlertid ikke tilbake med forslag om hvilke team som skulle sitte mer samlet. IBM ønsket ikke å involvere SVV. SVV kan heller ikke bebreides for å ha holdt tilbake godkjenning av endringsanmodninger. SVVs avvisning av EA053 og EA054 var rettmessig. Endringsanmodningene som ble fremsatt etter februar 2015, var stort sett ikke konsekvensutredet per hevingstidspunktet. På hevingstidspunktet 27. juli 2015 forelå det et inntrådt vesentlig mislighold fra IBMs side som ga SVV hevingsrett etter Generelle kontraktsbestemmelser punkt 6.4.2. Hevingsvarselet 22. juni 2015 må tolkes i lys av både forutgående og etterfølgende korrespondanse. Forhold som er påberopt som hevingsgrunn, kan presiseres. Det må være adgang til å trekke inn andre forhold kort tid etter hevingsvarselet. Det er ingen tradisjon i norsk rett for å oppstille mer rigide regler enn dette. Hevingsvarselet må således tolkes i lys av SVVs brev i perioden 27. mai til 28. august 2015. Statens anførsler ligger innenfor varselets rammer.

Staten er heller ikke avskåret fra å påberope forhold som ikke var synlig for SVV før hevingen. Dette gjelder først og fremst den manglende kompetansen i GD India og GD Kina. Kontraktens bestemmelser om prosjektgjennomføring var ikke uten innhold. Sondringen mellom bi- og hovedforpliktelser er bare et pedagogisk grep som ikke har selvstendig betydning for vurderingen av om et mislighold er vesentlig, jf. juridisk teori. Grovt mislighold av den generelle prosjektstyringen i en samspillskontrakt, medfører en forhøyet risiko for at prosjektet mislykkes, som kunden ikke må akseptere. Dette vil alltid være vesentlig mislighold. Ingen av hevingsgrunnene er bortfalt på grunn av manglende reklamasjon. SVV reklamerte på misligholdet innen rimelig tid. Mislighold ved forsett eller grov uaktsomhet er uansett ikke bortfalt på grunn av manglende reklamasjon. IBM misligholdt grovt plikten til å stå for en forsvarlig prosjektstyring. IBM hadde det overordnede ansvaret for å planlegge, organisere og lede utviklingsarbeidet, jf. Bilag B punkt 2.5.3 og 2.5.5.

IBM pliktet også å allokere relevant og tilstrekkelig kompetanse, utarbeide en realistisk gjennomføringsplan og rapportere reell fremdrift, jf. Generelle kontraktsbestemmelser punkt 1.2 tredje avsnitt, restanse R5 og Bilag B punkt 4. IBM utarbeidet aldri noen realistisk fremdriftsplan slik selskapet var forpliktet til etter restanse R5 og PRO006 Arbeidsprosesser enda SVV etterlyste, og IBM lovte, dette i så å si alle KG-møter fra september 2014 til mai 2015. Gjennomføringsplanen, versjon 4.0, som ble levert til KP2, var ikke realistisk. At IBM ikke utarbeidet en realistisk plan, var et forsettlig eller grovt uaktsomt brudd på kontrakten. IBM så at selskapet ikke ville klare å

nå dagbotsanksjonerte milepæler. IBM utarbeidet heller aldri noen gjennomføringsplan som var god nok, teknisk sett. Planene viste ikke nødvendige avhengigheter. IBM klarte aldri å rapportere reell fremdrift i prosjektet. Opptil 80 prosent av timene som ble rapportert inntjent (EV-rapportert), kom fra tidsdrevne aktiviteter. Rapporteringen var ikke i tråd med bransjestandarden for Earned Value Management (EVM). Dette var en veldig grov feil. At EV-rapporteringen ikke var reell, ble erkjent i KG-møte 17. april 2015. SVV opphevet aldri IBMs plikt til å rapportere reell fremdrift, men jobbet gjennom hele kontraktsperioden for å få IBM til å gjøre dette. IBMs widget-rapportering var ikke egnet til å gi SVV et reelt bilde av fremdriften. Den var bare egnet til å forvirre. IBM la bare frem «DCUT-burn down»oversikter sporadisk og på et aggregert nivå. Den siste oversikten er for mars 2015. IBM benyttet heller ikke verktøy som selskapet hadde forpliktet seg til, jf. Bilag C punkt 2.3.1. SVV påpekte dette ved godkjenningen av løsningsbeskrivelsen, jf. restansen R7.

IBMs valg om ikke å ta i bruk verktøyet Rational Requirement Composer (RRC) fra begynnelsen av løsningsbeskrivelsesfasen medførte store problemer med sporing og dokumentasjon av kravene som partene var blitt enige om. IBM benyttet heller aldri verktøy på en ensartet måte på tvers av land og strømmer. IBM allokerte ikke relevant og tilstrekkelig kompetanse til prosjektet. Prosjektledelsen i det lokale teamet hadde nesten ikke erfaring med å jobbe med GD i komplekse utviklingsprosjekter. Prosjektlederen som ble satt inn fra august 2014, var ikke «complex certified». Ressursene i CRM-strømmen i GD India hadde ingen eller helt begrenset erfaring med SugarCRM. Produktiviteten og kvaliteten på kildekoden viser at de ikke hadde relevant og tilstrekkelig kompetanse. IBMs interne kvalitetssikrere mente at lav kompetanse på SugarCRM var en av hovedgrunnene til problemene i CRM-strømmen. Arbeidet som det skulle utarbeides macrodesign for i den lokale CRM-strømmen, ble seksdoblet fra tilbudsfasen til begynnelsen av september 2014. Det ble ikke hentet inn flere ressurser enda IBMs interne kvalitetssikrere rapporterte et kritisk behov for dette.

Kompetansen til SAP-teamet i GD Kina var lav. Dette ble konstatert allerede i mai 2014. IBM forholdt seg passivt til dette helt til begynnelsen av juni 2015 enda fremdriften i SAP-strømmen var minimal. Det lokale SAP-teamet hadde ingen ressurs på Advanced Business Application Programming (ABAP) før i februar 2015. Annet grovt mislighold er offshore-andelen på over 70 prosent og fem leveransesentre, svikten ved estimeringen i både tilbudsfasen og ut av løsningsbeskrivelsesfasen samt den begrensede erfaringen med bompengedomenet. IBM klarte heller ikke å følge opp den avtalte arbeidsmetodikken med bruk av demoløsninger. Videre fikk ikke SVV innsyn i arkitekturbeslutninger. IBM utarbeidet ingen helhetlig logisk datamodell. IBM klarte ikke å få på plass et fungerende system for konfigurasjonsstyring. Ytelsestesten som skulle vært gjennomført i iterasjon 1, ble aldri gjennomført. IBM endret gjennomføringsmodellen fra en iterativ prosess til et fossefallsprosjekt. IBM nedbemannet prosjektet i juni/juli 2015 for å tvinge SVV til å akseptere selskapets gjennomføringsplan. IBM fremsatte også helt uholdbare endringsanmodninger.

Det foreligger fem kontraktsbrudd som hver for seg eller samlet utgjør forsettlig, eller i det minste grovt uaktsomt, mislighold på IBMs hånd. I tillegg til bruddene på plikten til å utarbeide realistiske planer, rapportere reell fremdrift og allokere relevant og tilstrekkelig kompetanse, gjelder dette IBMs nedbemanning av prosjektet i juni/juli 2015 og IBMs fremsettelse av oppblåste endringsanmodninger. SVVs underkjennelse av IBMs leveranse til KP2, var rettmessig, jf. Generelle kontraktsbestemmelser punkt 3.4.5 tredje avsnitt, Bilag C punkt 4.3.7 og PRO006 Arbeidsprosesser punkt 3.4.2. Underkjennelsen bygde på tre innbyrdes uavhengige grunnlag. Det er tilstrekkelig at ett av grunnlagene står seg. For det første var ikke gjennomføringsplanen som IBM leverte til KP2, realistisk. IBM var forpliktet til å levere en slik plan. SVV satte dette som betingelse for godkjenning av IBMs løsningsbeskrivelse. IBM aksepterte denne betingelsen. IBM bekreftet at selskapet skulle lage en realistisk plan i flere senere KG-møter.

Denne plikten opphørte ikke selv om planen skulle vise at IBM ville ha overskredet en dagbotsanksjonert milepæl med mer enn 100 dager. Kravet om at planen skulle være realistisk, har ikke noe innhold hvis ikke SVV kunne etterprøve realismen. Planen kunne ikke baseres på ren ønsketenkning. Med den historisk lave produktiviteten og den lave kvaliteten på kildekoden, var det null prosent sannsynlighet for IBMs gjennomføringsplan om å nå HMP2 til 23. september 2015. IBM må allerede da planen ble levert 22. april 2015, ha sett at HMP2 først ville blitt nådd langt inne i 2016. Det var null prosent sannsynlighet for at DCUT-arbeidet i iterasjon 3 kunne blitt ferdig til 10. juni 2015 for CRM, INT, IRIS, REP osv. og til 15. juni 2015 for SAP. IBM måtte i så fall ha mangedoblet produktiviteten. INT-strømmen i GD India hadde nesten ikke fremdrift, og det lokale teamet hadde store problemer med å ferdigstille grensesnittspesifikasjonene for de

interne grensesnittene. SAP-strømmen i GD Kina hadde heller ikke fremdrift. GDene i både India og Kina ga beskjed internt i IBM om at planen ikke var realistisk. Det var null prosent sannsynlighet for planen om å gjennomføre iterasjonstestingen av iterasjon 3 på to måneder og 10 dager. Det var helt usannsynlig at IBM ville brukt kortere tid på testingen av iterasjon 3 enn av iterasjon 2. Iterasjon 3 utgjorde rundt 70 prosent av løsningen. Den omfattet mer kompleks funksjonalitet og flere interne grensesnitt. Det var null prosent sannsynlighet for planen om å gjennomføre System Integration Test (SIT) på 49 dager. Alle eksterne grensesnitt skulle testes for første gang i SIT. Planen hadde mange datoer som allerede var overskredet. Planen utgjorde et forsettlig eller grovt uaktsomt kontraktsbrudd. For det andre leverte IBM mindre omfang til KP2 enn det selskapet var forpliktet til. Etter løsningsbeskrivelsen var IBM forpliktet til å levere 80 prosent av løsningen til KP2. IBM kunne ikke ensidig flytte innhold mellom iterasjoner.

Det er tvilsomt om SVV ble bundet ved passivitet til å akseptere at det skulle leveres et mindre volum til KP2. SVV ble uansett ikke bundet til mer enn det SVV forholdt seg passiv til, og var derfor ikke forpliktet til å akseptere at mer enn 50 prosent av løsningen skulle leveres i iterasjon 3. IBM leverte bare 30 prosent av løsningen til KP2. Differansen på 20 prosentpoeng var nok til å underkjenne KP2. At IBM 10. juni 2015 erkjente at selskapet bare hadde levert rundt 80 prosent av iterasjon 2, var også tilstrekkelig til å underkjenne KP2. For det tredje ga ikke testrapporten et godt bilde av testaktiviteter, funn og resultater. Rapporten manglet viktige elementer. Den beskrev bare kunde- og enhetstest. Øvrig testing var ikke beskrevet. Løsningen som ble testet, var ikke i samsvar med kontraktens krav og spesifikasjoner. IBMs testleder hadde ikke kunnskap om kontrakten og testplanene. Det er umulig å se at IBM forholdt seg til noen testplan. Test caser er borte. Testingen ble ikke gjennomført i samsvar med SVVs teststrategi, jf. IF.09.01 og Bilag C punkt 4.3.4.

IBM testet ikke reell dataflyt gjennom grensesnittene i integrasjons- og iterasjonstestingen. Det forelå en åpen A-feil som ikke fremgikk av rapporten. Siden underkjennelsen av KP2 var rettmessig, hadde ikke IBM krav på mer tid og penger etter EA108, EA113 og EA117. Subsidiært var tingrettens vurdering av disse tre endringsanmodningene korrekt. EA108 gjaldt arbeid som IBM uansett måtte ha gjort. IBM hadde heller ikke andre endringsanmodninger som klart utelukket antesipert mislighold. Ingen av endringsanmodningene i gruppen der IBM hevder at konsekvensene allerede er inntrådt, var berettigede. Alle linjene i EA053 var en del av IBMs kontraktsforpliktelser etter løsningsbeskrivelsen. Arbeidet lå innenfor IBMs DCUT-estimater fra midten av september 2014, og var ikke resultat av nye krav fra SVV. Arbeidet var også helt eller delvis gjennomført da endringsanmodningen ble fremsatt. Hva gjelder EA054, er det ingen holdepunkter i begivenhetsnære bevis for at SVV forsinket IBM høsten 2014. Hva gjelder EA108, EA113 og EA117, ble ikke IBM forledet av SVV med hensyn til gjennomføringen av KP2. KP2 ble rettmessig underkjent.

De påståtte konsekvensene av endringsanmodningene er uforståelige. Hva gjelder EA067, har ikke IBM sannsynliggjort at arbeidet med Greenbirds gjennomgang medførte ventetid for øvrige deler av prosjektorganisasjonen. Hva gjelder EA069, hadde IBM påtatt seg å utarbeide masterplanen i løsningsbeskrivelsen. Heller ingen av endringsanmodningene i gruppen som IBM hevder at SVV ville bestilt hvis kontrakten ikke var blitt hevet, var berettigede. IBMs produktivitet var så lav at selskapet ikke kunne krevd ekstra tid. Enhver ny endringsordre ville derfor bare ført til ytterligere forsinkelser. IBM har bevisbyrden for at det ville kommet til forhold som ville gjort det mulig å redusere forsinkelsen. EA075, EA076, EA085, EA095 og EA103 lå innenfor kontrakten. EA061 var knyttet til at IBM ikke hadde tatt inn over seg utfordringene ved å tilby en «multi tenancy»-løsning. Det må IBM bære risikoen for. EA078 ville ikke forsinket arbeidet. SVV ville akseptert at IBM kunne fortsette som før til selskapet hadde fått gjennomført nødvendige tiltak. Tidskonsekvensene som IBM har anslått, er ikke reelle.

Det forelå antesipert vesentlig mislighold på hevingstidspunktet som ga SVV hevingsrett etter Generelle kontraktsbestemmelser punkt 6.3.2, jf. punkt 6.1.1.1 og 6.1.1.2. Kravet om at det måtte være «klart» at en dagbotsanksjonert milepæl ville blitt overskredet med mer enn 100 dager, var oppfylt. Klarhetskravet vil alltid være oppfylt der medkontrahenten har gitt «et utvetydig tilkjendegivende» på at leveransen vil bli forsinket, jf. Rt-1924-1056 og juridisk teori. For øvrig finnes det lite autoritativ rettspraksis om beviskravet. Rt-1987-1205 gjaldt en meget spesiell sak. Veilederen til PS2000 taler om at antesipert mislighold må være «overveiende sannsynlig». Hagstrøm m.fl. taler om «skjellig grunn». Det er bevisresultatet

som må være klart, og ikke hvert enkelt beviselement, jf. til illustrasjon Rt-2005-1353 avsnitt 14. Klarhetskravet vil alltid være oppfylt der debitor allerede er betydelig forsinket og han ikke gjør noe forsøk på å gi en plausibel forklaring på hvordan han skal klare å forhindre vesentlig mislighold. Hevingsretten kan bortfalle på grunn av manglende reklamasjon og passivitet, jf. Hagstrøm m.fl. og fremstillingen til styringsgruppemøte (SG-møte) 20. mars 2015. Innstillingen til SG-møte 15. juni 2015 om at det var «nå, og ikke vesentlig mye fremover i tid» at SVV hadde mulighet til å heve, må forstås i lys av tilkjennegivelsen i «direktørmøtet» 8. juni 2015 og muligheten for at hevingsretten kunne bortfalle. Prinsipalt var planskissene som IBM presenterte i direktørmøtet 8. juni 2015 og KG-møtet 16. juni 2015 «et utvetydig tilkjendegivende» på antesipert mislighold. Skissene viste at IBM ville komme til å overskride HMP2 med flere hundre dager både med og uten EA053 og andre mulige endringsanmodninger. Konteksten viser at datoene i skissene var en utvetydig tilkjennegivelse.

IBM presenterte datoene som svar på SVVs oppfordring om å komme med tiltak for å sikre realisering av prosjektet. IBM presenterte ingen nye datoer etter hevingsvarselet 22. juni 2015. IBM hadde ikke krav på fristforlengelse. Subsidiært ville IBM ikke under noen omstendighet klart å nå HMP2 før tidligst høsten 2016. Forsinkelsen ut av HMP2 ville ha vært minst like stor ved HMP2.2. Etter nedbemanningen i juni 2015, ville IBM tidligst gjenopptatt arbeidet med iterasjon 3 i slutten av september 2015. Gjenstående DCUT-arbeid i iterasjon 3 ville tatt minst seks måneder. Det var mindre enn 10 prosent sannsynlighet for at dette arbeidet kunne blitt ferdig på seks måneder. Holte Consulting AS (Holte) la til grunn som «best case» at SAP-strømmen kunne blitt ferdig på seks måneder regnet fra begynnelsen av juni 2015, og at INT-strømmen kunne blitt ferdig noe etter dette. Leif-Arne Rones la til grunn at INT-strømmen ville hatt behov for 273 kalenderdager, ca. ni måneder, på å ferdigstille iterasjon 3. SAP-strømmen i GD Kina ser ikke ut til å ha fungert på noe tidspunkt og hadde helt begrenset fremdrift.

Andre strømmer meldte fra om at de ikke fikk gjort planlagt arbeid på grunn av avhengigheter til SAP FI-CA. INTstrømmen i GD India meldte fra om dette helt frem til hevingstidspunktet. Det er ingen holdepunkter for at IBM klarte å løse noen mer grunnleggende utfordringer i SAP-strømmen med de ressursene som ble satt på lokalt i mai/juni 2015. IBM har ikke redegjort for kompetansen til ressursene og hvilke oppgaver de skulle løse. IBM har heller ikke redegjort for at selskapet klarte å identifisere hva som var problemet i SAP-strømmen og at disse ble løst. Det var svært stor sannsynlighet for at IBM ikke hadde avdekket alle problemer. IBM hadde i løpet av våren 2015 ikke klart å løse grensesnittet mellom SAP FI-CA og SugarCRM knyttet til sletting av faktura, sletting av tilleggsavgifter og utstedelse av kreditnota. Holte vurderte ikke de kvalitative utfordringene i SAP-strømmen ved forutsetningen om at IBM ville klart å løse dem ved å sette på fire svært kompetente ressurser. INT-strømmen hadde store utfordringer som ikke var løst på hevingstidspunktet. Strømmen hadde historisk hatt svært lav fremdrift.

Den hadde oppdaget grensesnitt som ikke var estimert på hevingstidspunktet. Det lokale teamet hadde store utfordringer med å ferdigstille kravspesifikasjonene for de interne grensesnittene. Bare 50 prosent av grensesnittspesifikasjonene var ferdige i begynnelsen av juni 2015. Teamet hadde frem til da klart 15 prosentpoeng per måned. Det gjensto således ca. tre måneder med arbeid med grensesnittspesifikasjonene. Fremdriften i INT-strømmen ble ikke bedre i mai, juni og juli 2015. Det var ingen fremdrift i iterasjon 3 i juni 2015 og svært lav produktivitet i iterasjon 2.5. Arbeidet med enkle grensesnitt ble ikke borte ved bruk av generiske grensesnitt. Den lave produktiviteten i INT-strømmen underbygges av at bare 18 til 33 av de i alt 100 grensesnittene var ferdig DCUT-utviklet før hevingen. Iterasjonstestingen ville tatt minst seks måneder. IBM planla å gjøre testingen av iterasjon 3 tre ganger raskere enn testingen av iterasjon 2, enda selskapet planla å gjøre testingen av iterasjon 3 mye mer kompleks. IBM hadde ikke hatt en så rask fremdrift som planlagt på noe tidspunkt i prosjektet.

All «ende til ende»-testing av interne grensesnitt skulle gjøres i iterasjon 3. IBM baserte testplanen på en feilrate på 10 prosent. Verken Holte eller Rones har sett på testrapportene og hva som kan utledes av disse. Rones la IBMs plan om 38 dager til grunn uten nærmere vurdering. Holte mente at en feilrate på nivå med det som ble erfart ved iterasjonstestingen av iterasjon 2, ville fått dramatiske konsekvenser for ferdigdatoen. IBM har ikke presentert noen argumentasjon for at feilraten ville blitt nevneverdig lavere ved testingen av iterasjon 3. System Integration Test (SIT) ville tatt minst fire måneder, slik Rones har lagt til grunn. Det er ingen grunn til å fravike hans vurdering. Holte la IBMs plan om 49 dager til grunn, men forutsatte da at selskapet ville ha testet

de eksterne grensesnittene fortløpende i iterasjonstestingen, det vil si at IBM ikke ville fulgt egen plan. Etter IBMs testplan skulle nemlig «ende til ende»-testingen av eksterne grensesnitt først skje i SIT. Ifølge IBMs testleder hadde IBM ikke en gang begynt å planlegge SIT. Endelig er IBMs planskisser fra 8. juni 2015 også sterke bevis for at konstruksjonsfasen ikke ville ha vært ferdig før høsten 2016. IBM ville ikke hatt krav på fristforlengelse for ferier hvis kontrakten ikke hadde blitt hevet. Kontrakten ga ikke IBM krav på automatisk fristforlengelse for perioder da SVV tok ferie. IBM hadde i høyden krav på fristforlengelse der ferien forsinket arbeid på kritisk linje, jf. Generelle kontraktsbestemmelser punkt 6.3.1, og var dessuten forpliktet til å planlegge arbeidet slik at SVVs ferier ikke forsinket arbeid på kritisk linje. Verken kontraktstolkning, avtaleloven § 36 eller generell misbrukslære gir grunnlag for å sensurere SVVs rett til å heve på grunn av antesipert mislighold. PS2000 gir kunden rett til å heve hvis det er klart at leverandøren vil overskride en dagbotsanksjonert milepæl med mer enn 100 dager, jf.

Generelle kontraktsbestemmelser punkt 6.3.2, jf. punkt 6.1.1.1 og 6.1.1.2. PS2000 oppstiller ingen ytterligere vilkår for heving. Det er ikke rettspraksis for sensur av fremforhandlede standardkontrakter og innarbeidede bransjestandarder etter avtaleloven § 36. Det finnes ingen generell misbrukslære i norsk avtalerett. SVVs avveininger før hevingen var uansett hensiktsmessige og av en karakter som domstolene ikke kan overprøve Forutsatt at SVVs heving var rettmessig, har staten krav på full erstatning, utmålt etter rettens skjønn, for det økonomiske tapet som SVV er påført som følge av IBMs mislighold. Staten har krav på å bli stilt økonomisk som om avtalen var blitt oppfylt etter sitt innhold, det vil si som om IBM hadde levert et fungerende Grindgutsystem som kunne settes i drift til 13. november 2015, jf. at formålet med erstatning i kontraktsretten er å skape et oppfyllelsespress. Avtaler skal holdes. Det er ansvarsgrunnlag i Leveranseavtalen for både statens og bompengeselskapenes tap. Staten kan kreve erstattet både eget og bompengeselskapenes tap, ikke bare ved inntrådt, men også ved antesipert forsinkelse, jf.

Generelle kontraktsbestemmelser punkt 6.1.1.2, jf. punkt 6.3.2 og kontraktens systematikk. Staten kan også kreve erstattet både eget og bomselskapenes tap ved inntrådt vesentlig mislighold, jf. Generelle kontraktsbestemmelser punkt 6.1.1.2 og 6.1.2.4, jf. punkt 6.4.2. Staten krever uansett bare erstatning for sitt eget tap, og ikke bompengeselskapenes tap. Det økonomiske tapet kan deles inn i tre tapsposter. Den første tapsposten er den økonomiske verdien av Grindgut-systemet som staten skulle ha mottatt samt utlegg i forbindelse med misligholdet. Staten har prinsipalt krav på erstatning tilsvarende den økonomiske verdien av Grindgut fratrukket sparte kostnader som følge av misligholdet (fordeler) (den positive kontraktsinteressen). Det gjelder ikke noe vilkår om at SVV har foretatt en rettslig dekningstransaksjon for å få erstattet verdien av uteblitt ytelse. Den økonomiske verdien av Grindgut må fastsettes ved en kostnadsbasert tilnærming.

Etter kost pluss-metoden er verdien av Grindgut i kontraktsmessig stand, summen av SVVs bidrag i å frembringe kontraktsmessig ytelse, vederlaget som IBM har krav på ved kontraktsmessig ytelse og eventuell verdiskapning. Det er bare SVVs bidrag og IBMs vederlag (kost), og ikke eventuell verdiskapning (pluss), som kreves her. Sparte kostnader som følge av misligholdet, kommer til fradrag i både SVVs bidrag og IBMs vederlag ved kontraktsmessig ytelse, men bare i kompatibel tapspost. SVVs bidrag er dokumentert til 120 millioner kroner. Dersom IBM har krav på vederlag, blir erstatningen tilsvarende høyere. Staten aksepterer at det kan være grunnlag for et skjønnsmessig fradrag på fire millioner kroner. Det er ikke grunnlag for å gjøre fradrag for fordel av «gjenbrukbarhet i konkurransegrunnlag». Subsidiært har staten som alternativ utmåling av den positive kontraktsinteressen, krav på erstatning av kostnadene ved frembringelsen som er forgjeves pådratt, jf. kjøpsloven § 67, Ot.prp.nr.80 (1986–1987) side 121, Rt-1938-602 (Blårev), Rt-2002-1110 (Bodum) og juridisk teori. Forgjeves pådratte kostnader er 116 millioner kroner.

Staten har i begge tilfeller også krav på avviklingskostnader høsten 2015 med 8,7 millioner kroner. Dette er direkte tap som følge av IBMs vesentlige mislighold. Den andre tapsposten er SVVs kostnader til forlenget leie av CS Norge fra 13. november 2015 til 1. april 2021. Dette er også et direkte økonomisk tap som følge av IBMs vesentlige mislighold, jf. Generelle kontraktsbestemmelser punkt 6.4.1 andre avsnitt, kjøpsloven § 67 andre ledd bokstav b og tredje ledd bokstav a, Ot.prp.nr.80 (1986–1987) side 124 og juridisk litteratur. Den totale leiekostnaden for perioden fra november 2015 til april 2021, var vel 414 millioner kroner. Fordelen som SVV har hatt ved ikke å måtte betale drifts- og vedlikeholdsvederlag til IBM, kommer til fradrag med 21 millioner kroner per år. For hele perioden fra

november 2015 til april 2020, utgjorde dette 116 millioner kroner. I tillegg har staten krav på å få erstattet kostnadene til utvikling av en selvbetjeningsløsning for CS Norge med vel 28 millioner kroner. Ingen av IBMs innvendinger mot denne posten kan føre frem. Partene har ikke avtalt seg bort fra kjøpslovens regulering av hva som skal anses som indirekte tap. SVV har oppfylt sin tapsbegrensningsplikt. Den tredje tapsposten er SVVs tapte fordeler ved å ikke få på plass en moderne og mer effektiv bompengeløsning i november 2015. Denne erstatningsposten kreves ikke, men synliggjør at fraværet av verditap på grunn av slit og elde ikke er kompatibelt med de to erstatningspostene som kreves. Det er SVV som har lidt det økonomiske tapet i både den første og andre tapsposten. Det var SVV som inngikk kontrakten med IBM og som hadde rettskrav på oppfyllelse av kontrakten. SVV mottok og betalte fakturaene for prosjektet. Det var også SVV som inngikk kontrakten med Q-Free om forlenget leie av CS Norge. SVV ble fakturert og betalte Q-Free. Utgiftene ble ført som kostnader i SVVs regnskaper.

At utgiftene ble finansiert av bompengeselskapene eller bilistene, innebærer ikke at ikke staten har lidt et tap. Det er fortsatt et tap av offentlige midler. Rt-2008-738 (flyseteavgift) gir ikke støtte for noe annet. Det er ingen holdepunkter i norsk rett for at «overveltning» av et tap som følge av kontraktsbrudd, er en fordel som kommer til fradrag i skadelidtes krav på erstatning. Finansiering av tap fra tredjepart medfører ikke fradrag i erstatningen, jf. Rt1965-1115 og Rt-2010-1305. Staten har ikke overdratt sitt erstatningskrav. Kontraktens ansvarsbegrensninger gjelder ikke fordi IBMs vesentlige mislighold knyttet til prosjektstyringen, var forsettlig eller grovt uaktsomt, jf. Generelle kontraktsbestemmelser punkt 6.4.1 andre avsnitt. Punkt 6.4.1 andre avsnitt ble ikke opphevet ved SVVs brev 7. mai 2013. Diskusjonen i dette brevet gjaldt ikke generelt, men var knyttet til tapte bompenger. Subsidiært, for det tilfellet at ansvarsbegrensningene gjelder, var alle tapspostene direkte tap. Begrensningen mot indirekte tap i punkt 6.4.1 første avsnitt andre punktum er uten betydning.

Begrensningen til «Kontraktsprisen uten merverdiavgift» i punkt 6.4.1 andre avsnitt første punktum utgjør 97 316 487 kroner. Hvis IBM har krav på ytterligere betaling for endringer, heves dette taket. Hvis SVVs heving av kontrakten var rettmessig, har IBM ikke krav på vederlag. Prinsipalt kunne SVV heve med tilbakevirkende kraft etter den deklaratoriske bakgrunnsretten fordi IBM ikke har utarbeidet noe som har hatt verdi for SVV og fordi IBMs mislighold var forsettlig eller grovt uaktsomt. PS2000 viser til denne bakgrunnsretten ved formuleringen «i utgangspunktet» i Generelle kontraktsbestemmelser punkt 6.4.2.1. Statens rett til å påberope heving med tilbakevirkende kraft er ikke tapt ved passivitet. Subsidiært har IBM bare krav på vederlag for den delen av løsningen som er godkjent i et kontrollpunkt. Leverandørens krav på vederlag er forskjellig avhengig av hvem som hever: Der kunden hever, har leverandøren krav på vederlag for den delen av «Leveransen som er dokumentert utført». Der leverandøren hever, har leverandøren krav på vederlag for den delen av «Leveransen som er utført», jf.

Generelle kontraktsbestemmelser henholdsvis punkt 6.4.2.1 første avsnitt og punkt 6.4.2.2 første avsnitt. Ordlydsforskjellen og begrepet «dokumentert» må tilordnes et meningsinnhold. Med «Leveransen» menes utviklet løsning/kode og ikke timeforbruk. Det er bare løsningen/koden som kan overtas og tas i bruk. Det avtalte vederlagsformatet taler for denne tolkningen. IBM hadde risikoen for egen ineffektivitet. Med «dokumentert» menes godkjent i et kontrollpunkt. Det er bare i kontrollpunktene at den utviklede løsningen dokumenteres. IBM har ikke krav på noen del av fastprisen, jf. Bilag D punkt 2.1, fordi SVV ikke har fått overlevert noen av lisensene, jf. Generelle kontraktsbestemmelser punkt 6.4.2.1 andre avsnitt. Subsidiært har ikke IBM krav på vederlag for standard programvare, jf. Bilag F punkt 2.1. Hvis SVV hadde fått overlevert lisensene, kunne SVV levert lisensene tilbake og krevd vederlaget tilbakebetalt. Staten kan ikke stilles dårligere når SVV ikke har fått lisensene overlevert og er fratatt muligheten til å levere dem tilbake. Det er maksimalt 15 prosent av løsningen som er godkjent i et kontrollpunkt.

Det eneste kontrollpunktet som kan være godkjent, er KP1. Hvis SVVs heving av kontrakten var urettmessig, har IBM bare krav på vederlag for den delen av løsningen som var utviklet på hevingstidspunktet. Maksimalt 50 prosent av løsningen var utviklet på dette tidspunktet. Kontraktens målprismekanisme må forstås slik at den ga IBM krav på maksimalt 115 prosent av målpris. Ingen av IBMs endringsanmodninger der det hevdes at konsekvensen allerede var inntrådt, var rettmessige. Ingen gir krav på økning av målprisen og målpristaket. Finansieringsavtalen gir ikke IBM noe selvstendig krav på vederlag, jf. Bilag F punkt 2.1. IBM har ikke opparbeidet en ubetinget rett til beløpene som er inkludert i Finansieringsavtalen; beløpene er

forskuddsbetalinger. Finansieringsavtalen regulerer ikke situasjonen der Leveranseavtalen er hevet på grunn av forsettlig eller grovt uaktsomt vesentlig mislighold. I en slik situasjon har ikke IBM rett til å få utbetalt beløpene som er inkludert i Finansieringsavtalen. IBM har ikke krav på avbestillingskompensasjon, prinsipalt fordi SVVs heving var rettmessig, subsidiært fordi Leveranseavtalen og tilhørende avtaler ble avsluttet ved heving fra IBMs side. Det er nedlagt slik påstand:

1. Staten v/Samferdselsdepartementet tilkjennes erstatning fastsatt etter rettens skjønn.
2. International Business Machines AS har ikke noe krav på vederlag for arbeid utført etter kontrakt nr. 2012148869 / 8061300107 omhandlende felles IKT-løsning for bompengebetaling i Norge «AutoPASS Grindgut».
3. International Business Machines AS har ikke krav på erstatning.
4. Staten v/Samferdselsdepartementet tilkjennes sakens omkostninger for tingretten og lagmannsretten.

Ankemotparten, International Business Machines AS, har i hovedtrekk gjort gjeldende: SVVs heving av kontrakten var ikke rettmessig. SVV kunne ikke heve basert på antesipert forsinkelse. Det var ikke «klart» på hevingstidspunktet at IBM ville overskredet en dagbotbelagt milepæl tillagt ekstra tid etter fremsatte endringsanmodninger, med mer enn 100 dager, jf. Generelle kontraktsbestemmelser punkt 6.3.2, jf. punkt 6.1.1.1 og 6.1.1.2. Veilederen til PS2000 viser at det gjelder et svært høyt krav til bevis. Rettskilder knyttet til andre standardkontrakter, lovbestemmelser, traktater og internasjonale standarder som benytter kriteriet «klart», og juridisk teori om den obligasjonsrettslige bakgrunnsretten, viser at det kreves «en til visshet grensende sannsynlighet» for fristoverskridelse eller at fristoverskridelse er «sikkert». Rt-1987-1205 taler om «særdeles sterkt bevis». Prinsipalt viser uttalelser internt i SVV i juni 2015 om at hevingsretten ville bortfalle hvis den ikke ble benyttet før flytting av milepælsdatoer, at det aldri har eksistert en hevingsrett.

SVVs forklaring om at uttalelsene bare knytter seg til reklamasjon og passivitet, er oppkonstruert. Uttalelsene knyttet seg til heving. Subsidiært hadde SVV ikke hevingsrett etter en detaljert endrings- og fremdriftsanalyse. Det strenge beviskravet tilsier at analysen må skje ut fra en «very best case»-vurdering. Beviskravet må være oppfylt for hvert trinn i prosessen, jf. til illustrasjon HR-2021-871-U avsnitt 13 flg. og Rt-2004-1063 avsnitt 7 flg. På hevingstidspunktet hadde IBM fremsatt endringsanmodninger som flyttet kontraktens milepæler med minst 369 kalenderdager (186 + 183 dager). IBM kunne i «very best case» levert innenfor 100 dager av de endrede milepælene. Statens enkle tilnærming om at IBM ga en «utvetydig tilkjennegivelse» i direktørmøtet 8. juni 2015, er ikke holdbar. Situasjonen liknet overhodet ikke på Rt-1924-1056. Planene som ble presentert i direktørmøtet, var dessuten bare skisser og forhandlingsutspill etter at SVV hadde nektet å godkjenne IBMs tidligere planer basert på at de ikke var realistiske. Hvis IBMs forsøk på å komme SVV i møte med slakkere planer var en hevingsgrunn, var det satt opp en felle for IBM.

Utviklingen av løsningen kunne vært ferdig i løpet av september 2015. Enkle «widget units»-beregninger viser at 100 prosent av alle widgets til og med iterasjon 2, rundt 60 prosent av alle widgets i iterasjon 3 og rundt 80 prosent av alle widgets i hele løsningen, var fullført per 10. juni 2015. Fra 29. april til 10. juni 2015 ble det fullført 259 widgets, det vil si 170 widgets per måned. Det gjensto 498 widgets 10. juni 2015. Dette tilsvarer arbeid i mindre enn tre måneder. «DCUT burndown»-beregningene til statens to sakkyndige har den fordelen at de eliminerer virkningen av to av de omstridte faktorene produktivitet (Cost Performance Indicator (CPI)) og tidsdrevne ressurser. Leif-Arne Rones har ekstrapolert fremdriften i INT-strømmen i perioden fra 18. desember 2014 til 2. juni 2015 for å finne ferdigtidspunktet for DCUT-arbeidet. Det er en svakhet ved hans rapport at det ikke er begrunnet hvorfor den er basert på fremdriften i disse fem månedene. Dette var et avgjørende valg. Rones har så lagt til 60

dager for oppbemanning av iterasjon 3. Anslaget er ikke begrunnet. A-2 la til grunn én måned for både ned- og oppbemanningen. Rones kunne ikke utelukke at IBM kunne ha opprettholdt fremdriften i mai 2015. I en «very best case»-vurdering må det tas høyde for at farten i mai 2015 ikke var maksfart. Holte Consulting AS har ekstrapolert fremdriften i de fem siste ukene før 4. juni 2015. Ifølge ekstrapoleringene ville all utvikling i strømmene INT, CRM, Self Service, Reporting og Security vært ferdig i løpet av september 2015. Med unntak for INT-strømmen, kunne Trond Botheim ikke utelukke at fremdriften i de fem siste ukene ville ha fortsatt. Det er en svakhet ved Holtes rapport at det ikke er gjort en nærmere analyse av INT-strømmen i de fem siste ukene. Mesteparten av inntjeningen i mai var påbegynt i slutten av april 2015. Dessuten tok testing, feilretting og KP2 mye tid frem til april 2015. Arbeid med enkle grensesnitt var satt på hold i slutten av mars og gjenopptatt med generiske grensesnitt fra slutten av april 2015. Per juni 2015 kunne flere grensesnitt realiseres gjennom generiske grensesnitt.

Det skjedde en kraftig oppbemanning i INTstrømmen. Det skjedde også en oppbemanning i SAP-strømmen. Basert på Holtes tall for gjenstående DCUTtimer og produksjonskapasitet per ressurs i SAP-strømmen, ville det tatt mindre enn tre måneder å fullføre utviklingen i denne strømmen. At deler av det gjenstående arbeidet i SAP-strømmen ble levert til iterasjon 2.5, reduserer det gjenværende arbeidet ytterligere og viser kapasiteten. IBM skal ikke belastes for tid til oppbemanning av iterasjon 3. Nedbemanningen av denne iterasjonen var foranlediget av SVVs urettmessige underkjenning av KP2, og var i tråd med kontraktens system, jf. Generelle kontraktsbestemmelser punkt 3.4.5 tredje avsnitt. Statens sakkyndige overdriver uansett tiden for oppbemanning. Det er ut fra en «very best case»-vurdering ikke grunnlag for å anta at dette ville tatt så lang tid som to måneder. IBM ville ut fra en «very best case»-vurdering fulgt sin egen plan for iterasjonstest og SIT på henholdsvis 38 og 49 kalenderdager eller forsert. Produktiviteten ble vesentlig forbedret med ny testleder.

Flesteparten av testene i iterasjon 3, var gjentakelser av testene i iterasjon 2 og ville gått dobbelt så raskt. Ressurser som var ferdige med DCUT-arbeid kunne bistått med testing. Feilraten var redusert fra iterasjon 2 til 3. Det lå forseringsmuligheter i helgejobbing og økt grad av parallellitet i testingen. Rones la til grunn IBMs plan om at iterasjonstesten kunne vært gjennomført på 38 dager. Det var ikke unntatt fra hans mandat å vurdere lengden på iterasjonstesten. Han la derimot til grunn at SIT optimistisk sett ville tatt tre måneder/12 uker dels basert på en 1:2:2-regel. En slik regel har ikke forankring i noen kilder. Holte la IBMs plan om at SIT kunne vært gjennomført på 49 dager til grunn. Underkjenningen av KP2 var ikke rettmessig. IBM har derfor krav på fristforlengelse etter EA108, EA113 og EA117. Ved vurderingen av antesipert forsinkelse skal det derfor heller ikke tas hensyn til tiden som ville gått med til oppbemanning av iterasjon 3. Underkjenningen var klart illojal og belyser SVVs uvilje og forberedelse på heving.

SVV hadde bestemt seg for underkjenningen på forhånd og sett seg ut «for lite volum» som hovedbegrunnelse. KP2 kunne ikke underkjennes basert på omfang. SVV fikk løpende informasjon i rapporter og møter om at mer enn 50 prosent av omfanget/utviklingen utsto til iterasjon 3. SVV fikk informasjon om scope-grensene gjennom release notes, kundetest og scope-oversikter, og hadde full oversikt over innholdet av iterasjon 2 da inngangskriteriene til oppstart av KP2 ble ansett for oppnådd. SVV fremsatte ingen innsigelser og ble bundet ved passivitet. Det var for øvrig 46 prosent av løsningen som gjensto til iterasjon 3, og ikke 67 prosent slik tingretten la til grunn. KP2 kunne ikke underkjennes på grunn av urealistisk plan. PERT-analysen som SVV vurderte realismen etter, var basert på uriktige forutsetninger om at iterasjon 2 var 50 prosent av totalløsningen, at iterasjon 3 ikke var påbegynt og at iterasjon 3 ville ta like lang tid som iterasjon 2. Kontrakten gir ikke SVV rett til å overprøve IBMs realismevurdering, jf. Bilag C punkt 5.1.1. En slik rett vil undergrave klarhetskravet til antesipert mislighold.

Leverandøren har rett til å fortsette arbeidet mot leveransedato innenfor 100-dagersfristen så lenge dette praktisk talt ikke er utelukket, og må kunne ha en plan som reflekterer denne ambisjonen. Som fremholdt av A-2 27. april 2015, er det «leverandørens ansvar å sette datoen basert på egen vurdering av situasjonen». Planen var uansett ikke urealistisk. Blant annet viser begivenhetsnære bevis at IBM hadde som ambisjon å følge planen. Etterfølgende hendelsesforløp er ikke relevant ved vurderingen av realismen. KP2 kunne ikke underkjennes basert på testrapportens innhold. SVVs begrunnelse var at rapporten bare beskrev kunde- og enhetstest, «ikke den øvrige testingen». Rapporten fulgte en omforent mal. Testrapporten var ett av inngangskriteriene til oppstart av KP2 og ble godkjent 22. april 2015.

IBM hadde krav på 186 kalenderdager fristforlengelse per hevingstidspunktet for EA053, EA054, EA067, EA108, EA112, EA113 og EA 117. IBM hadde i tillegg krav på 183 dager fristforlengelse for 13 funksjonelle endringsanmodninger som var fremsatt, men ikke utført på hevingstidspunktet, det vil si EA061, EA075, EA076, EA084, EA085, EA089, EA093, EA095, EA096, EA097, EA099, EA103 og EA105. Dette er endringer som SVV måtte ha. Staten er enig i at EA061, EA084, EA085, EA089, EA093, EA096, EA097 (EA099) og EA105 utgjør endringer i kontrakten. IBM ville også hatt krav på fristforlengelse for de resterende 22 prosentene av EA053 om prosjektet ikke hadde stoppet opp i juli 2015. Videre må ferier, herunder påskeferien i uke 12 i 2016, hensyntas. EA078 (Kina-saken) ville også gitt IBM tid til å hente inn eventuelle forsinkelser. EA068 (frysperiode) kunne også gitt fristforlengelse. SVV opptrådte ikke lojalt til kontraktens endringsregime. SVV unnlot å behandle fremsatte endringsanmodninger og ta stilling til endringsbehovet av taktiske hensyn. Eventuelle uklarheter som dette skaper, må gå utover SVV.

SVV kunne ikke heve basert på aktuelt mislighold. SVV gjør nå bare gjeldende mislighold av prosjektstyringen. Dette er en biforpliktelse. Etter bakgrunnsretten gir mislighold av biforpliktelser bare hevingsrett i ekstreme tilfeller som hvis opptredenen unntaksvis må oppfattes som bevisst illojalitet, jf. Hagstrøm. Dette forsterkes når kontraktens regulering av mislighold og misligholdsvirkninger er knyttet til hovedforpliktelsen som er resultatforpliktelsen, samlet betegnet som Leveransen, jf. Generelle kontraktsbestemmelser punktene 6.1.2 og 1.2 første avsnitt lest i sammenheng med punktene 6.1.2.1, 6.1.2.2, 6.1.2.3 og 6.1.2.4. Det samme kan utledes av veilederen til PS2000 og Føyen m.fl. Leverandørens resultatforpliktelse er et sterkt reelt argument mot prosjektstyringen som hevingsgrunn. Resultatforpliktelsen må innebære autonomi for IBM med hensyn til organiseringen og styringen. Staten kan ikke påberope andre hevingsgrunner enn de som ble angitt i hevingsvarselet, jf. Rt-1994-1617. Forhold som er lagt til etter hevingen, kan ikke påberopes. Det gjelder ikke noe unntak for forhold som var usynlige for SVV på hevingstidspunktet.

Dette er uansett en teoretisk problemstilling. Kunden skal ikke blande seg opp i eventuelle mangler ved kompetansen i GDene. Foruten antesipert forsinkelse ble det i varselet bare påberopt mangler ved prosjektstyringen, og da konkretisert til mangler ved fremdriftsrapporteringen. Det ble ikke anført at prosjektstyringen måtte forbedres innen 30 dager. Det kan spørres om det overhodet er noe aktuelt mislighold å vurdere. Det forelå ikke noe aktuelt vesentlig mislighold av pliktene knyttet til prosjektstyringen. Kontraktens krav til fremdriftsrapportering i Generelle kontraktsbestemmelser punkt 2.3 og Bilag B punkt 4.1, er begrensede og mer fleksible enn det staten gjør gjeldende. Bransjestandarden Project Management Institute (PMI) er ikke nevnt i kontrakten. Den er ikke fremlagt. Det er ikke pekt på konkrete avvik fra PMI. Bransjestandarden er ikke entydig. IBMs rapportering var kontraktsmessig på hevingstidspunktet, jf. forklaringen fra IBMs utviklingsleder for GDene, Sander van der Harst. Staten har ikke ført van der Harsts motpart i SVV, Anne Torland, som vitne.

IBM ga også supplerende rapporter på widget-nivå fra november 2014 og rapporter om «DCUT burn down» fra desember 2014. Hadde SVV etterlyst «DCUT burn down»-rapportene da de fra april 2015 opphørte som faste innslag i status- og månedsrapportene, ville vegvesenet ha fått dem. «DCUT burn down»-rapportene forekom dessuten i enkelte dokumenter fra mai og juni 2015. Mislighold av biforpliktelsen fremdriftsrapportering utgjorde uansett ikke noe vesentlig mislighold. Eventuelle feil ved rapporteringen var svært beskjedne. SVV var klar over svakhetene ved rapporteringen og var til enhver tid i stand til å gjøre egne vurderinger av fremdriften og problemene i prosjektet, jf. eksempelvis PERT-analysen 17. april 2015. IBMs rapportering fikk aldri SVV til å undervurdere utfordringene i prosjektet. De øvrige påberopte hevingsgrunnene ligger utenfor hevingsvarselet og er bortfalt på grunn av manglende reklamasjon. Disse grunnene kan under ingen omstendighet anses som vesentlig mislighold. Når det gjelder hevingsgrunnen gjennomføringsplaner, stilte SVV overdrevne krav til detaljering, jf. forklaringen fra Henning Denstad fra A-2.

Det er planstatusen på hevingstidspunktet som er relevant. Det ble ikke reist kritikk mot den tekniske kvaliteten på planen som ble levert til KP2. Denne planen kunne som nevnt ikke underkjennes på grunn av manglende realisme. Når det gjelder hevingsgrunnen verktøy, var IBMs hovedforpliktelse å opplyse om og dokumentere hvilke verktøy selskapet ville bruke, jf. Bilag C punkt 2.3 første avsnitt. IBM opplyste at selskapet kom til å bruke verktøypakken Rational med Rational Requirement Composer (RRC), Rational Team Concert (RTC) og Rational Quality Manager (RQM), jf. punkt 2.3.1. SVV brukte HP-verktøy, men var «åpen» for å tilpasse seg

IBMs verktøyanbefaling, jf. punkt 2.3 andre avsnitt. I løsningsbeskrivelsesfasen var partene enige om å bruke System Requirements Specification (SRS) i stedet for kravsporingsverktøyet RRC, jf. leveranselisten til HMP1 (ARC001) og historikken til SRS-dokumentet. Etter HMP1 var partene enige om å legge SRS-kravene inn i det felles testverktøyet RQM, jf. PRO006 Arbeidsprosesser punkt 5. IBM brukte RQM og RTC hele tiden. Det var SVV som brøt forpliktelsen til felles bruk av dette testverktøyet og forsinket prosjektet. IBM hadde rett til å bemanne prosjektet slik selskapet fant det hensiktsmessig. Kontrakten stilte ikke noen kompetansekrav. Eventuelle konsekvenser for fremdrift, kvalitet og kostnad ble ivaretatt gjennom de misligholdsbeføyelsene som kontrakten ga SVV knyttet til resultatforpliktelsen og målpristaket. IBMs prosjektledelse var sterk og hadde relevant GD-erfaring. Utfordringene i GDene skyldtes vekst i prosjektet og press på spesialutvikling. Dette ble fulgt opp på adekvat måte. IBM var i sin fulle rett til å organisere seg med en offshore-andel på mer enn 70 prosent og fem leveransesentre.

Når det gjelder hevingsgrunnen estimering, kan ikke forhold i tilbudsfasen, det vil si før kontraktsinngåelsen, være kontraktsbrudd. Estimeringen ut av løsningsbeskrivelsesfasen var av underordnet betydning på hevingstidspunktet. Hevingsgrunnen arbeidsmetodikk er ikke konkretisert. SVVs krav om «en helhetlig logisk datamodell» eksisterer ikke i Leveranseavtalen. Leveranselisten til HMP1 forutsatte at det skulle leveres en logisk datamodell, men sa ingenting om innholdet. Det er ingen bevis for at SVV kommuniserte sitt krav før i konstruksjonsfasen. Det er da ingen kontraktsforpliktelse som er brutt. IBM skulle ikke utvikle en løsning fra bunnen av, men levere en modulær løsning bestående av eksisterende applikasjoner – SugarCRM, SAP FI-CA, Cognos og IRIS – med hver sin datamodell. Løsningen bygde videre på det allerede utviklede RUC. Det var derfor ikke nødvendig med en konseptuell datamodell. IBM leverte en logisk datamodell til HMP1. Logisk datamodell var ikke en restanse ved HMP1 og er således godkjent.

At IBM likevel utarbeidet en konseptuell datamodell, skyldtes SVVs misnøye med de oppdaterte delene av den logiske datamodellen som ble oversendt i løpet av konstruksjonsfasen. IBM ønsket å komme SVV i møte. Dette arbeidet hadde god progresjon før hevingen. Subsidiært var SVVs heving begrunnet i utenforliggende hensyn og av den grunn urettmessig, jf. lojalitetsplikten i kontraktsforhold, alternativt avtaleloven § 36. Begivenhetsnære bevis viser at SVV helt fra før kontraktsinngåelsen og inn i konstruksjonsfasen, forventet store forsinkelser uten at prosjektet ble stoppet. Interne dokumenter viser at forsinkelse ikke var den motiverende faktoren bak hevingen. Andre alternativer ble vurdert til å ta lengre tid enn Grindgut. Dette underbygges av at det gikk flere år å erstatte CS Norge. Interne dokumenter viser også at de reelle grunnene bak hevingen var misnøye med den kontraherte løsningen, usikkerhet om løsningen ville møte brukernes forventninger, omfattende endringsbehov, bompengereformen og juridiske betraktninger.

IBM har krav på vederlag for de utførte delene av leveransen etter Generelle kontraktsbestemmelser punkt 6.4.2.1 og 6.4.2.2, uavhengig av om SVVs hevingskrav var berettiget. Hevingen har bare virkning fremover i tid – ex nunc. Staten la dette til grunn i hevingsbrevet. Dette er bindende for SVV etter sitt innhold. SVV har dessuten fremsatt krav om heving med tilbakevirkende kraft for sent. IBM har krav på betaling av programvare. Alle deler av den avtalte programvaren var tatt i bruk under utviklingen av Grindgut. Gitt at IBM hadde hevingsrett, er det bare IBM som kunne be om å få programvare tilbake mot å tilbakebetale vederlag, jf. Generelle kontraktsbestemmelser punkt 6.4.2.2. SVV hadde derfor plikt til å betale. Gitt at SVV hadde hevingsrett, er statens krav om at IBM ikke kan kreve vederlag for programvare, fremsatt for sent. Subsidiært gjelder tilbakeleveringsretten bare for standard programvare som definert i Bilag F. IBMs egenutviklede programvare RUCT, er ikke standard. Fradraget for standard programvare utgjør i så fall maksimalt 18,5 millioner kroner.

Dette beløpet må reduseres med 50 prosent fordi halvparten av fastprisen forfalt til betaling ved HMP1, jf. EO038. Vederlaget skal beregnes ut fra påløpt tid opp til målpristaket. Det skal ikke multipliseres med utførelsesgraden slik tingretten gjorde. Det er ikke holdepunkter i kontrakten for en slik forholdsmessighetsvurdering. Riktig justert målpris er 116 millioner kroner fordi IBM hadde krav på godkjenning av flere endringer. Hvis det skal foretas en forholdsmessighetsvurdering, var 80 prosent en riktigere utførelsesgrad enn 70 prosent som tingretten la til grunn. Målpristaket var 130 prosent slik tingretten la til grunn, og ikke 115 prosent slik SVV hevder. Motstrid mellom tabell og tekst i kontrakten, må gå utover SVV som anbyder. Vederlagskravet under Leveranseavtalen blir da 177,1 millioner kroner. I og med at dette overstiger beløpene som var lagt inn under

Finansieringsavtalen, får ikke denne avtalen selvstendig betydning. IBM har likevel krav på 61 millioner kroner etter Finansieringsavtalen punkt 1.1, 1.2 og 3.2 for tre signerte leveringsattester som er gjort uttrykkelig uavhengig av Leveranseavtalen. IBM har krav på erstatning med 7,9 millioner kroner for avviklingskostnader, jf. Generelle kontraktsbestemmelser del II punkt 6.4.2 jf. 6.4.1. IBM har også krav på avbestillingskompensasjon med 11,8 millioner kroner etter SSA-V og SSA-D. SVVs uberettigede heving må likestilles med en avbestilling. Det var feil rettsanvendelse av tingretten å legge vekt på at IBM valgte å heve avtalene i august 2015. Subsidiært, for det tilfellet at SVVs heving var rettmessig, har staten ikke krav på erstatning. Et eventuelt økonomisk tap er ikke lidt av staten. Erstatningskrav for tap som er lidt av andre enn kontraktsparten, krever kontraktshjemmel. Staten har hjemmel til å gjøre gjeldende tap hos drifts- og bompengeselskapene ved faktisk forsinkelse og feil/mangler, jf.

Generelle kontraktsbestemmelser punkt 6.1.1.2 og 6.1.2.4, men ikke ved antesipert forsinkelse og «annet vesentlig mislighold», jf. punkt 6.3.2, jf. 6.4.1 og 6.4.2, jf. 6.4.1. Det er ikke grunnlag for å utvide området for å kunne kreve erstatning for tap som er lidt av andre enn kontraktsparten, gjennom «harmonisering». Alt tap som staten har krevd erstattet, er belastet bompengeselskapene og deretter bilistene. Bompengeavtalen og annen dokumentasjon viser dette. Statens eventuelle intensjon eller forpliktelse til å videreføre erstatningen til bompengeselskapene, er uten betydning. Staten og bompengeselskapene har uansett ikke lidt noe tap. Anskaffelseskostnadene er bompengefinansiert. Kostnadene er således veltet videre over på bilistene, jf. Rt2007-738. Staten så dette på samme måte i BT Signaal-saken. Atter subsidiært er tapspostene som kreves, enten negativ kontraktsinteresse eller indirekte tap som staten er avskåret fra å kreve. Prosjektkostnadene på 116 millioner kroner i den første tapsposten, er negativ kontraktsinteresse.

Prosjektkostnadene er ikke noe mål for Grindgut-løsningens verdi blant annet fordi prosjektet var anskaffelsesrettslig, og ikke økonomisk, begrunnet. Normer for verdsettelse av aktiva/regler for regnskapsførsel er av liten interesse her. Et aktivum kan uansett ikke verdsettes til kostpris dersom kostnaden ikke kan tjenes inn. Siden Grindgut ikke hadde noen omsetningsverdi, måtte verdien i så fall bestå i en neddiskontert fremtidig kontantstrøm fra fordelen ved en mer effektiv bompengeinnkreving. «Forgjeves kostnader» er ikke forårsaket av misligholdet, men av kontraktsinngåelsen. Det foreligger derfor ikke årsakssammenheng. Tapt fortjeneste som følge av utvidet leie av CS Norge på 327 millioner kroner i den andre erstatningsposten, er indirekte tap. Partene var enige om dette i to og et halvt år etter SVVs heving. Det ble avklart i anbudsfasen at det ikke var nok med en generell tolkning av kjøpsloven § 67 og at tapt fortjeneste falt utenfor leverandørens erstatningsansvar. Eventuell uklarhet må gå utover anbudsinnbyderen. Staten så også dette på samme måte i BT Signaal-saken. Oslo byfogdembete var enig.

Uansett innebar forlenget leie av CS Norge intet økonomisk tap. Det må tas hensyn til verditap på Grindgut. Partene var enige om dette i lang tid. Med en prosjektprognose på 570 millioner kroner og en antatt levetid på ti år, blir årlig avskrivning 57 millioner kroner. Årlig leie av CS Norge var 48,1 til 76,9 millioner kroner. Årlig kostnad til drift og vedlikehold av Grindgut, var avtalt til 21,3 millioner kroner. Disse størrelsene oppfyller kravet til komputabilitet og viser at årlig tap er null. Tapsperiodens lengde er dessuten ett eller høyst to år. Kostnaden til CS Norge ville ikke opphørt 13. november 2015 uansett eventuelt IBM-mislighold. På grunn av endringsbehov og bomselskapenes frysperioder, ville SVV overveiende sannsynlig utløst opsjoner slik at vegvesenet ville hatt kostnader til CS Norge til 15. desember 2016. Tapsperioden kan således tidligst ha startet 15. desember 2016. At det var behov for CS Norge så lang tid som seks år etter hevingen, kan ikke ha hatt sammenheng med et eventuelt IBM-mislighold. Med en tapsperiode på ett eller maksimalt to år fra og med 2017, da den årlige leien var 48,1

(2017) og 48,9

(2018) millioner kroner, er det årlige tapet også null. Atter atter subsidiært gjelder ansvarsbegrensningene i Leveranseavtalen uansett skyldform. Dette går frem av endringene som SVV gjorde i konkurransegrunnlaget ved brev 7. mai 2013. Oslo byfogdembete la dette til grunn i BT Signaal-saken. Eventuell uklarhet må gå utover SVV som utformet konkurransegrunnlaget. IBM har uansett ikke opptrådt med forsett eller grov uaktsomhet. IBMs avveining av egne interesser mot SVVs interesser er ikke hensynsløs eller sterkt illojal. Det foreligger heller ikke årsakssammenheng mellom statens økonomiske tap og IBMs påståtte grove skyld. Ansvarsbegrensningene medfører sterk beskjæring. Uansett må et eventuelt tap reduseres på grunn av medvirkning, jf. skadeserstatningsloven § 5-1 første ledd, og misligholdt

tapsbegrensningsplikt ved å ha brukt mange år på å skaffe et nytt system tilpasset bompengereformen, jf. samme bestemmelse andre ledd. Det er nedlagt slik påstand: I anken: Anken forkastes. I den avledede anken:

1. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS kroner 177 105 392 for vederlag under Leveranseavtalen med tillegg av lovens til enhver tid gjeldende forsinkelsesrente fra 14. september 2015 til betaling skjer.
2. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS kroner 61 002 016 for vederlag under Finansieringsavtalen med tillegg av lovens til enhver tid gjeldende forsinkelsesrente av kroner 7 964 072,21 fra 7. august 2015 til betaling skjer og kroner 53 037 944 fra 4. september 2015 til betaling skjer.
3. Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS kroner 19 725 224 i erstatning for krav under Leveranseavtalen, SSAD og SSA-V med tillegg av lovens til enhver tid gjeldende forsinkelsesrente fra 14. september 2015 til betaling skjer.

I begge tilfeller:

Staten v/Samferdselsdepartementet dømmes til å betale International Business Machines AS' sakskostnader for lagmannsretten.

Lagmannsretten bemerker

1 Innledning – Kravene, hovedspørsmålet og lagmannsrettens konklusjon Lagmannsretten skal i korthet ta stilling til to krav: Det første er statens krav på erstatning; det andre er IBMs krav på vederlag. Det er enighet om at staten bare kan ha krav på erstatning hvis SVVs heving 27. juli 2015 var rettmessig. Det er også enighet om at IBM har krav på vederlag hvis hevingen var urettmessig. Det er derimot uenighet om IBM har krav på vederlag hvis SVVs heving var rettmessig. Staten har gjort gjeldende at IBM ikke har krav på vederlag hvis hevingen var rettmessig, mens IBM har gjort gjeldende at kravet på vederlag står i samme stilling enten hevingen var rettmessig eller ikke. Sakens hovedspørsmål er således om SVVs heving var rettmessig. Staten har gjort gjeldende at SVV hadde to grunnlag som hver for seg ga rett til å heve: Det ene grunnlaget var inntrådt vesentlig mislighold på hevingstidspunktet; det andre var antesipert vesentlig forsinkelse på det samme tidspunktet. IBM har bestridt begge grunnlagene.

Siden spørsmålet er om IBM misligholdt kontrakten, kommer lagmannsretten bare inn på SVVs forhold i den grad de belyser IBMs forhold. Lagmannsretten ser det med andre ord ikke som nødvendig å vurdere særskilt om SVV misligholdt kontrakten. Lagmannsretten er i likhet med tingretten kommet til at staten ikke har krav på erstatning fordi SVV verken kunne heve på grunnlag av inntrådt vesentlig mislighold eller antesipert vesentlig forsinkelse. IBM har da krav på vederlag. Lagmannsretten begrunner hvorfor SVV ikke kunne heve på grunnlag av inntrådt vesentlig mislighold i punkt 3 og hvorfor SVV ikke kunne heve på grunnlag av antesipert vesentlig forsinkelse i punkt 4 nedenfor. Vederlagsspørsmålet blir behandlet i punkt 5. Lagmannsretten tar imidlertid helt innledningsvis, i punkt 2, et overordnet blikk på tilbuds- og løsningsbeskrivelsesfasen.

2 Overordnet blikk på tilbuds- og løsningsbeskrivelsesfasen Lagmannsretten er enig med staten i at IBM tok noen valg i tilbudsfasen som innebar en forhøyet risiko for at Grindgut-prosjektet ville mislykkes. Anskaffelsesprosedyren fulgte reglene om konkurranse med forhandling i forskrift om offentlige anskaffelser. I konkurransegrunnlaget 21. januar 2013, satte SVV HMP2.3 til 15. april 2015. Leverandøren kunne angi en alternativ dato, men dette måtte i så fall begrunnes. (FU 3281 på 3850) Det går frem av en e-post internt i SVV 4. desember 2014 at det ifølge vegvesenets juridiske avdeling, var «grunn til å tro at flere av leverandørene i stor grad lot seg påvirke av denne datoen ved utarbeidelsen av sine tilbud». (TU2 1546 på 1548) IBM innga tilbud 18. februar 2013, 23. mai 2013, 7. august 2013 (Best And Final Offer (BAFO)) og 4. september 2013 (revidert tilbud) med forhandlinger innimellom. I IBMs tilbud var HMP2.3 satt til 19. mars 2015. Dette var om lag en måned tidligere enn datoen som var satt i konkurransegrunnlaget.

(FU 7103 på 7160 og FU 9105 på 9161) IBMs tilbud bygde på at selskapet ville bruke langt færre timer på Grindgut enn det selskapet hadde brukt på sitt tidligere bompengeprosjekt i Brisbane enda Grindgut var mer komplekst enn Brisbane-prosjektet. (TU2 764 på 773) Prosjektgjennomføringen hvilte på en forutsetning om at IBMs eksisterende asset, Road User Charging (RUC), ble oppgradert før løsningsbeskrivelsesfasen. Oppgraderingen ble kalt enhancement-prosjektet. (FU 5333 på 5346, FU 7980 på 7992 og TU2 724 på 737) Med oppgraderingen ville arbeidet med løsningen kunne tuftes på demoløsninger, jf. Bilag A «Vedlegg til vedlegg 2.2 Kravtabell generelle krav» punkt 5 «GK.01.07 Standardisering av Arbeidsprosesser» og Bilag C punkt 4.2.2.4 «Integrasjon mot vedlikehold og drift». (FU 8563 på 8575 og FU 9105 på 9112) I IBMs interne Proposal Baseline Assessment (PBA) 2. august 2013, i forkant av BAFO, sto det: Delays will impact the project. (FU 7980 på 7983) IBMs løsning bygde på de fire applikasjonene SugarCRM, SAP FI-CA, Cognos og IRIS.

IBM valgte SugarCRM enda selskapet ikke hadde brukt denne applikasjonen i bomprosjekter tidligere og enda selskapet så at det ville bli vanskelig å skaffe SugarCRM-ressurser. IBMs ledende kvalitetssikrer, Anders Thörnqvist, skrev sammen med to andre Subject Matter Experts (SMEs), følgende i IBMs interne Application Innovation Services (AIS) Technical Delivery Assessment (TDA) 13. februar 2013: Sugar CRM has not been used in RUC deals and skills are not available in the Nordic. Effort from Sugar added to the cost case. Action: Look outside of IBM if Sugar Architect is not found within IBM Nordic. (TU 1110) Prosjektet ble organisert med en offshoreandel på over 70 prosent og opptil fem leveransesteder. Anders Thörnqvist skrev i IBMs interne AIS TDA 15. mai 2013: [...] We are not aware of any other project that has been successfully run in this way and this represents a significant risk. (FU 5481 på 5488) IBMs kvalitetssikrere foreslo risikoreduserende tiltak internt.

I PBA-vurderingen 2. august 2013, ble det satt som én «BAFO action» at det måtte rekrutteres en prosjektleder (Project Manager (PM)) med omfattende GDerfaring fra utviklingsprosjekter («AIS projects») i minst fire til seks måneder for å sikre en effektiv oppstart av GDene. (FU 7980 på 7988) Det ble sett som avgjørende å ha en effektiv og klar arbeidsprosess i prosjektet med klar og tett styring. Følgende tiltak ble anbefalt:

• Clearly describe the project process in the proposal; how the Design phase will be executed, requirements tracked etc. Describe the priority to use standard functionality and that the estimates are based on this. Client responsibilities and deliverables must be clearly spelled out.
• The low local presence means that the local consultants need to take the role as PM’s or technical PM’s. Before BAFO submission the whole governance and execution set-up should be reviewed and optimized. Staffing, tooling, work processes etc. should be reviewed. Consider doing a demo of the whole work process as part of negotiation meeting.
• At least at start-up a PM with significant experience from projects with high GD content should be

engaged.

• Client require quite extensive project planning and reporting. The PMO set-up and the PMO tooling (eg. Earned Value and planning tools) must be carefully planned and ready for use from day 1 of the project. (FU 7989) Staten har innhentet sakkyndige vurderinger av prosjektet fra professor Magne Jørgensen og IT-rådgiver LeifArne Rones. Magne Jørgensen skrev i rapporten «Vurdering av Grindgut-prosjektet» 1. desember 2021 at TDA-vurderingen 15. mai 2013 burde medført «økt satsning på å bygge opp det lokale teamet». (TU2 2812 på 2821) Han beskrev at utviklingsteamene innen samme land, ofte ikke var samlokaliserte, og at det var «svært mange kommunikasjonsledd mellom brukerne (der behovene er) og utviklingsmiljøene». Han hadde i sin «tid som prosjektleder, rådgiver og forsker [...] aldri kommet over et prosjekt med så mange kommunikasjonsledd og så kompleks organisering (inkludert geografisk spredning)». (TU2 2820) Leif-Arne Rones skrev i «Leveransevurdering av Grindgut» 2. desember 2021 at IBM hadde satt opp prosjektet «på en slik måte at det nærmest ville være umulig å lykkes». (TU2 2825 på 2829) Det er på det rene at IBM ikke fulgte opp alle forutsetningene og anbefalingene fra tilbudsfasen, i løsningsbeskrivelsesfasen. For eksempel var ikke RUC oppgradert før løsningsbeskrivelsesfasen. RUC ble ikke levert før 17. april 2014. (TU 1678 og 1679) Prosjektlederen som ble satt inn, hadde ingen omfattende erfaring med å jobbe med GD. Lederen som ble satt inn i CRM-strømmen, hadde ikke erfaring med SugarCRM. I evalueringen av løsningsbeskrivelsesfasen skrev Anders Thörnqvist og kvalitetssikrer Andy Wright at SAPteamet i GD Kina ikke fungerte. De anbefalte å flytte SAP-strømmen til GD India og rekruttere en lokal SAP prosjektleder med GD-erfaring. (TU2 1021 på 1022) Anbefalingen om å flytte SAP-strømmen til GD India fikk støtte fra IBMs prosjekteier og Risk Manager («RM»), Kjetil Westgaard. (TU2 1024) Ved overgangen til konstruksjonsfasen, skrev Andy Wright og kvalitetssikrer Ulrike Vauth i IBMs interne Phase Gate 1 Review 20. august 2014:
• Project Governance, Accountability and Process not established sufficiently
• Planning: details and dependencies are missing (and to be matched to accountability and effort)
• [...]
• No real task/effort/cost management established: tracking and reporting missing (kind of «blind» status, need to trust what GD is saying once a week)
• Local team does not really know or check what GD is doing; big risk that they are not doing the right things and that quality is not sufficient (FU 14680 på 14682) Anders Thörnqvist meldte følgende utestående aksjon i intern e-post til Kjetil Westgaard med kopi til blant annet European Public Sector Delivery Leader and Executive Partner, Stewart Knox, og leder for Global Business Services i Norge, Geir Haugen, 28. august 2014:

Lack of basic governance processes (planning, tracking, issues, financial ...) – starting to improve but long way to go (FU 15103) Anders Thörnqvist reiste spørsmål om prosjektet burde få tillatelse til å «overspend now» for å redusere risikoen for forsinkelse og sanksjoner. Han anbefalte en rekke tiltak for å styrke det lokale teamet med blant annet «additional functional SMEs for CRM».

Det er på det rene at IBM heller ikke fulgte opp alle anbefalingene som var gitt frem til overgangen til konstruksjonsfasen eller først fulgte dem opp etter lang tid. For eksempel hadde heller ikke den nye prosjektlederen som ble satt inn i konstruksjonsfasen, omfattende erfaring med å jobbe med GD. IBM arbeidet med å skaffe tilstrekkelige ressurser i GD India helt frem til desember 2014. Mer enn halvparten av ressursene som ble satt inn i GD India, hadde ingen erfaring med SugarCRM.

Kvalitetssikrernes anbefalinger var imidlertid ingen kontraktstekst. IBM var således ikke forpliktet til å følge deres anbefalinger i seg selv. Dette ser det ut til å være enighet om. Kvalitetssikrernes oppgave var dessuten nettopp å fokusere på problemene og utfordringene i prosjektet. Videre skal spørsmålet om SVV hadde grunnlag for å heve kontrakten, vurderes ut fra situasjonen på hevingstidspunktet 27. juli 2015. Dette er det også enighet om. Lagmannsretten ser derfor bare tidligere problemer og utfordringer i prosjektet som relevante hvis de fortsatt gjorde seg gjeldende på hevingstidspunktet. Lagmannsretten går over til å begrunne hvorfor SVV ikke kunne heve på grunnlag av inntrådt vesentlig mislighold.

3 Var det inntrådt vesentlig mislighold på hevingstidspunktet?

3.1 Innledning – Partenes syn på de rettslige utgangspunktene Partene er uenige om hvilke rammer hevingsvarselet – og hevingserklæringen – setter for hvilke forhold som kan påberopes som hevingsgrunn. Staten har i korthet gjort gjeldende at varselet og erklæringen bare setter visse rammer. Det er adgang både til å presisere påberopte hevingsgrunner så lenge det dreier seg om samme forhold og til å trekke inn andre omstendigheter innen rimelig tid. Alle hevingsgrunnene som er påberopt under domstolsbehandlingen ligger innenfor disse rammene. IBM har gjort gjeldende at varselet setter absolutte rammer, og at det bare er manglende fremdriftsrapportering som kan påberopes. Partene er også uenige om forholdene som påberopes som hevingsgrunn og som alt i alt kan karakteriseres som mislighold av prosjektstyringen, er en biforpliktelse, og hvilken betydning det i så tilfellet har. Staten har i korthet gjort gjeldende at prosjektstyringen ikke kan være en biforpliktelse i en samspillskontrakt, og at vesentlige mangler ved prosjektstyringen kan gi grunnlag for heving.

IBM har gjort gjeldende at prosjektstyringen er en biforpliktelse, og at det er tvilsomt om kontrakten hjemler heving ved mislighold av slike forpliktelser. Lagmannsretten ser på de rettslige utgangspunktene for hvilke rammer hevingsvarselet setter i punkt 3.1.1 og sondringen mellom hoved- og biforpliktelser i punkt 3.1.2 nedenfor. Lagmannsretten ser deretter på bevistemaet i punkt 3.1.3.

3.1.1 Hevingsvarselet som ramme Det følger av Generelle kontraktsbestemmelser punkt 6.4.2 at kontrakten kan heves «med 30 kalenderdagers varsel» ved vesentlig mislighold, og at hevingsretten «bortfaller dersom misligholdet er opphørt eller avhjulpet i løpet av denne perioden». (FU 8458 på 8479) Slik lagmannsretten ser det, indikerer ordlyden at formålet med varselet er å klargjøre hvilke forhold som må rettes for at heving skal avverges, jf. at hevingsretten «bortfaller dersom misligholdet er opphørt eller avhjulpet» innen varslingsfristen. Kontrakten stiller ellers ingen uttrykkelige krav til hevingsvarselets – eller hevingserklæringens – innhold. Veilederen til PS2000, versjon 3.1, oppdatert 15. november 2010, gir heller ingen veiledning om hva varselet må inneholde. Av punkt 8.3 med overskriften «Fellesregler om inntruffet og forventet mislighold», går det imidlertid frem at bestemmelsene i PS2000 er «presisert og harmonisert i forhold til andre tilsvarende kontraktsstandarder». Veilederen viser også til «alminnelige kontraktsrettslige prinsipper».

I mangel av andre rettskilder, gir andre tilsvarende kontraktstandarder og alminnelige kontraktsrettslige prinsipper veiledning. Det følger av de fleste tilvirkningskontraktstandardene, blant annet av NTK/NF 2015 punkt 26.1, NS 8405 punkt 39.1, NS 8406 punkt 29.1, NS 8407 punkt 46.1 og SSA-T, at heving må varsles.

NTK/NF punkt 26.1 gir hevingsrett på nærmere angitte vilkår «med øyeblikkelig virkning ved varsel til Leverandøren». Kontrakten stiller ingen uttrykkelige krav til varselets form eller innhold utover at det må være skriftlig. Kaasen skriver i kommentarene til punkt 26.1 i Tilvirkningskontrakter, 1. utgave, side 705, at det likevel er naturlig å kreve at hevingsgrunnen identifiseres. Etter NS 8405 punkt 39.1 tredje avsnitt første punktum «skal den parten som ønsker å heve, skriftlig ha gitt den andre parten en rimelig frist til å rette forholdet, med varsel om hevning om så ikke skjer». Kolrud m.fl. skriver om varselets innhold i kommentarene til NS 8405, 2004, side 495, at varselet må «identifisere hvilket mislighold som påberopes og at heving vil bli foretatt, eller vurderes foretatt, dersom forholdet ikke blir rettet» siden heving «kan få betydelige konsekvenser for den annen part». Marthiniussen m.fl. skriver i kommentarene til den samme standarden, 2016, side 667, at varselet må konkretisere hvilket mislighold som påberopes. Han fortsetter: [...] Er det forsinkelse, må det fremgå.

Dersom det er flere forhold man påberoper seg, må samtlige tas med i varselet. Følgen av å unnlate å ta med alle forhold er at de utelatte forhold ikke vil bli tatt med i vurderingen av om misligholdet er vesentlig, som en domstol i siste instans må foreta. [...] NS 8406 punkt 29.1 andre avsnitt har så å si identisk ordlyd som NS 8405 punkt 39.1 tredje avsnitt første punktum. I LH-2017-66455 uttalte Hålogaland lagmannsrett at «hevingsvarselet setter rammen for de forholdene som er relevante ved vurderingen av om det foreligger hevingsgrunn». Lagmannsretten viste til Arvesen m.fl. sine kommentarer til NS 8406 punkt 29.1, side 476, som skriver det samme som Marthiniussen m.fl. Lagmannsrettene i LH-2015-77899 og LF-2018-45329 tok det samme rettslige utgangspunktet. Borgarting lagmannsrett tok også dette rettslige utgangspunktet i LB-2017-1178, men mente at hevingserklæringen «i dette tilfellet» måtte «suppleres av den felles forståelse som forelå mellom partene om hvilke problemer som forelå på hevningstidspunktet».

Selv om hevingserklæringen var «nokså generell», forelå det mye korrespondanse mellom partene som viste at entreprenøren var klar over hvilke konkrete feil som byggherren mente forelå. NS 8407 punkt 46.1 første avsnitt tredje punktum har så å si identisk ordlyd som NS 8405 punkt 39.1 tredje avsnitt første punktum og NS 8406 punkt 29.1 andre avsnitt. Nordtvedt m.fl. skriver i kommentarene til NS 8407, 1. utgave, 2013, side 684, at varselet må inneholde «en tilstrekkelig konkret angivelse av misligholdet til at parten får en reell mulighet til å rette». Han skriver videre: [...] Ettersom den misligholdende part skal gis adgang til å rette, vil det være nødvendig at alle hevningsgrunnlag som skal påberopes, angis eksplisitt dersom den hevende part vil påberope flere forhold.

Den misligholdende part vil på denne måten være gitt anledning til å rette de aktuelle forholdene. [...] Nordtvedt m.fl. omtaler også diskusjonen i juridisk teori om hevingserklæringen må omfatte alle forhold som påberopes som hevingsgrunn, og nevner at Hagstrøm i Obligasjonsrett, 2011, side 464, «legger til grunn at utgangspunktet er at den som hever ikke har adgang til å skifte standpunkt senere, men at rekkevidden av utgangspunktet kan være usikkert fordi det må være adgang til å presisere hevingsgrunnlaget som er påberopt senere». Nordtvedt m.fl. fortsetter: For NS 8407 vil bestemmelsen om hevingsvarsel etter vårt syn skjerpe kravene til at den det heves overfor, gis en fullstendig oversikt over de faktiske omstendigheter som påberopes, slik at rettingsadgangen blir reell. Etter SSA-T punkt 11.5.4 første avsnitt forutsetter hevingsrett at kunden har gitt «skriftlig varsel og rimelig frist til å bringe forholdet i orden».

I LE-2018-76187-3 pekte Eidsivating lagmannsrett på at «formålet med kravet til forutgående varsel er at leverandøren ikke skal risikere hevning uten først å ha fått anledning til å rette på forholdet», og at det «normalt ikke» vil «være i noen av partenes interesse at hevning skjer i andre tilfeller av mislighold enn der hvor leverandøren ikke kan eller vil hjelpe». Siden leverandøren skal gis mulighet for å rette, mente lagmannsretten også at kunden ikke kan «benytte andre hevingsgrunner enn de som er påberopt i varselet». Kontraktsretten ellers gir veiledning om at det er hevingserklæringen som setter rammer for hvilket hevingsgrunnlag som kan påberopes. At det er hevingserklæringen og ikke hevingsvarselet som setter rammer i kontraktsretten ellers, må etter lagmannsretten syn forstås på bakgrunn av at en hevingserklæring som regel kan pareres med et tilbud om retting.

Rt-1994-1617 gjaldt heving i tomtefesteforhold. Bortfesteren hadde tatt forbehold i hevingserklæringen om å komme tilbake med «ytterligere anførsler og grunnlag» for hevingen. Høyesterett uttalte at slike forbehold «i det minste» måtte følges opp «innen rimelig tid», og godtok ikke at bortfesteren kom med en ny anførsel om forurensning i grunnen over ett og et halvt år etter hevingserklæringen. Festeren måtte få «vite hva hevingsgrunnlaget er, slik at han settes i stand til å ta stilling til om han skal godta hevingen eller ikke, og hvorledes han i tilfelle skal innrette seg». Slik lagmannsretten ser det, måtte festeren også få vite hva hevingsgrunnlaget var for å bli satt i stand til å vurdere retting. Bortfesterens hevingserklæring ga nemlig festeren rett til å kreve en frist for retting. Under henvisning til Rt-1994-1617, skriver Hagstrøm m.fl. i Obligasjonsrett, 3. utgave, 2021, side 487 flg., at «utgangspunktet må være at kreditor ikke har adgang til å skifte standpunkt og påberope alternative eller supplerende hevingsgrunner som forelå allerede da hevning ble erklært».

Hensynene som Høyesterett la vekt på, gjør seg ifølge Hagstrøm gjeldende i de fleste kontraktstyper. Han holder frem at «realdebitor kan ha en adgang til å parere et hevningskrav med et tilbud om retting av mangler», og at retteadgangen ikke blir reell hvis «hevningskravet kan fremsettes på et grunnlag realdebitor innretter seg på å rette» og så opprettholdes på et annet grunnlag. Han forsetter: Rekkevidden av utgangspunktet kan være usikkert. Kreditor må i ettertid ha adgang til å presisere det grunnlag som er påberopt som hevningsgrunn, dersom det dreier seg om samme forhold. I forlengelsen av uttalelsen i Rt-1994-1617 må det vel også være adgang til innen rimelig tid å inndra andre omstendigheter, selv om dette ikke er varslet ved et alminnelig forbehold. Basert på rettskildene knyttet til andre tilvirkningskontraktstandarder med krav om varsel før heving og hensynene som er vektlagt i Rt-1994-1617 og juridisk teori, legger lagmannsretten til grunn at hevingsvarselet må identifisere og konkretisere alle forholdene som påberopes som hevingsgrunn slik at adgangen til retting blir reell.

Dette kan stille seg annerledes hvis kontraktspartene har en felles forståelse av hvilke konkrete feil som foreligger. Basert på det samme grunnlaget legger lagmannsretten til grunn at det som et alminnelig kontraktsrettslig prinsipp ikke er adgang til å påberope andre forhold som hevingsgrunn enn de som er påberopt i hevingsvarselet. Dette kan stille seg annerledes hvis det er tale om presisering av samme forhold eller hvis de nye forholdene påberopes innen rimelig tid. Lagmannsretten er etter dette enig med staten i at det er relevant å se på hva SVV skrev til IBM i perioden fra 27. mai til 28. august 2015 om hvilke forhold som kunne gi grunnlag for heving. Lagmannsretten går over til å se på sondringen mellom hoved- og biforpliktelser.

3.1.2 Sondringen mellom hoved- og biforpliktelser Slik lagmannsretten ser det, må prosjektstyringen anses som en biforpliktelse selv om kontrakten er en samspillskontrakt. I Generelle kontraktsbestemmelser punkt 1.2 med overskriften «Generelt om Leverandørens plikter», står det i første avsnitt: Leverandørens forpliktelse omfatter alle arbeider og ytelser som Leverandøren skal utføre eller besørge utført i henhold til Kontrakten, inklusive alle leveranser av maskin- og programvare, utvikling av programvare, dokumentasjon, opplæring og tilhørende tjenester. Disse forpliktelsene er heretter samlet betegnet som Leveransen. (FU 8458 på 8462) Lagmannsretten leser punkt 1.2 første avsnitt slik at det beskriver leverandørens resultatforpliktelse i kortfattet form. Etter punkt 1.2 tredje avsnitt plikter leverandøren blant annet «å allokere relevant og tilstrekkelig kompetanse og å samarbeide med Kunden i den grad som er nødvendig for profesjonelt å oppfylle forpliktelsene i Kontrakten». Lagmannsretten leser punkt 1.2 tredje avsnitt slik at det beskriver leverandørens innsatsforpliktelse i kortfattet form.

Prosjektstyringen hører innunder dette avsnittet.

Generelle kontraktsbestemmelser punkt 1.3 har overskriften «Generelt om Kundens plikter». Her går det frem at kunden «plikter å samarbeide med Leverandøren som beskrevet i Kontrakten slik at Leverandøren ikke blir forsinket eller på annen måte forhindret i å oppfylle sine forpliktelser». (FU 8463) Hvordan samarbeidet mellom leverandøren og kunden skal foregå, er utdypet i punkt 2. (FU 8463 flg.) Etter punkt 2.3 skal leverandøren blant annet «periodisk rapportere og presentere status for Kunden, basert på rutiner for oppfølging og rapportering beskrevet i Bilag B». (FU 8465) Etter Bilag B punkt 2.5.5 har leverandøren «lederansvaret for arbeidet med løsningsbeskrivelse, konstruksjon, godkjenning og idriftsettelse, selv om arbeidet foregår i samarbeid med Kunden». (FU 9069 på 9077) Etter Bilag B punkt 4.1 skal leverandøren blant annet rapportere fremdriften. (FU 9078) For lagmannsretten, ser resultatforpliktelsen ut til å være leverandørens hovedforpliktelse etter kontrakten. Det er denne forpliktelsen som trer frem som «det sentrale elementet» i leverandørens ytelse, jf.

Haaskjold, Kontraktsforpliktelser, 2. utgave, 2013, side 466 og Hagstrøm m.fl., Obligasjonsrett, 2021, side 123. Formålet med leverandørens innsatsforpliktelse, prosjektstyringen, ser derimot ut til å være en biforpliktelse. Denne forpliktelsen skal bare «sikre en smidig og hensiktsmessig avvikling av kontraktsforholdet», jf. igjen Haaskjold side 466. Dessuten ser hevingsretten etter kontrakten i første rekke ut til å være knyttet til resultatforpliktelsen, «Leveransen». Det følger av Generelle kontraktsbestemmelser punkt 6.4.2 at «skadelidende part» kan heve «etter bestemmelsene i punktene ovenfor». (FU 8458 på 8479) Det foreligger hevingsrett ved inntrådt og antesipert forsinkelse, jf. punkt 6.1.1.2 og 6.3.2. Heving på grunn av forsinkelse forutsetter at «Leveransen ikke er kontraktsmessig utført innen tidspunktene for en av Milepælene, slik disse er definert i Fremdriftsplanen», jf. punkt 6.1.1. (FU 8475) Videre foreligger det hevingsrett ved inntrådte og antesiperte feil eller mangler som er vesentlige, jf. punkt 6.1.2.4 og 6.3.2.

(FU 8477) Feil og mangler er definert som «avvik mellom avtalt og levert Leveranse», jf. punkt 6.1.2. (FU 8476) Ved vurderingen av om feilen eller mangelen er vesentlig, «skal det tillegges vekt om den hindrer Kunden i å benytte Leveransen», jf. igjen punkt 6.1.2.4. (FU 8477) Feilene, manglene og vesentlighetsvilkåret peker således tilbake til resultatforpliktelsen, «Leveransen». At kontraktens hevingsbestemmelser i første rekke peker tilbake til resultatforpliktelsen, taler også for at innsatsforpliktelsen, prosjektstyringen, er en biforpliktelse. At kontraktens bestemmelser om kundens rett til reklamasjon og utbedring peker tilbake på resultatforpliktelsen, jf. Generelle kontraktsbestemmelser punkt 6.1.2.1, 6.1.2.2 og 6.1.2.3, taler for det samme. (FU 8476) For øvrig omtaler verken veilederen til PS2000 eller Føyen m.fl., Kontrakter for utvikling av programvare, 2006, hevingsrett på grunn av vesentlige feil og mangler for annet enn resultatforpliktelsen.

Selv om hevingsretten i første rekke ser ut til å være knyttet til resultatforpliktelsen, mener lagmannsretten at det likevel er hjemmel etter kontrakten for heving ved mislighold av biforpliktelser. Av Generelle kontraktsbestemmelser punkt 6.4.2 følger det ikke bare at «skadelidende part» kan heve «etter bestemmelsene i punktene ovenfor», men også «ved annet vesentlig mislighold fra den andre parts side». Slik lagmannsretten forstår tilføyelsen om «annet vesentlig mislighold», rommer den hevingsrett ved brudd på biforpliktelser såfremt bruddet er vesentlig. Haaskjold gir på side 466 og 467, og Hagstrøm m.fl. gir på side 126, uttrykk for at sondringen mellom hovedog biforpliktelser, som utgangspunkt bare har pedagogisk og ikke rettslig betydning. Haaskjold skriver likevel på side 467 og 468 at det kan «være grunn til å anta at brudd på biforpliktelser ikke like lett som brudd på hovedforpliktelsen vil kunne karakteriseres som vesentlig mislighold som gir rett til heving», og understreker at dette følger «av en analyse av hva som ligger i vesentlig mislighold» og «ikke av sondringen mellom hoved- og biforpliktelser».

Han gir også uttrykk for at «et krav på erstatning i praksis ofte vil fremstå som den mest adekvate sanksjonen ved brudd på biforpliktelsene». Hagstrøm m.fl. skriver tilsvarende på side 126: [...] Brudd på biforpliktelser vil ofte ikke være så alvorlige at de gir hevningsrett, dersom opptredenen ikke unntaksvis må oppfattes som en bevisst illojalitet som i hvert fall i mer langsiktige kontraktsforhold må kunne gi den krenkede grunnlag for å komme ut av forholdet. [...] Normalt vil imidlertid et erstatningskrav være den mest praktiske beføyelse ved mislighold av biforpliktelser.

Lagmannsretten legger etter dette til grunn at brudd på biforpliktelser kan gi hevingsrett, men at det skal en del til for at bruddet utgjør et vesentlig mislighold selv om partene har inngått en samspillskontrakt. For det tilfellet at brudd på biforpliktelser ikke kan anses som vesentlige, legger lagmannsretten på den andre siden til grunn at bruddene vil kunne være relevante ved vurderingen av om det foreligger hevingsrett på annet grunnlag, det vil her si antesipert vesentlig forsinkelse.

3.1.3 Bevistemaet Bevistemaet blir etter dette hvilke hevingsgrunner som kan påberopes etter hevingsvarselet, om hevingsgrunnene som kan påberopes og blir påberopt, utgjør mislighold av kontrakten og om misligholdet er vesentlig. Føyen m.fl. skriver på side 483 om vurderingen av hva som er å anse som en vesentlig mangel etter levering: [...] Etter som heving som misligholdsbeføyelse er et svært alvorlig skritt å gå til i et utviklingsprosjekt, er det naturlig å veie eventuelle momenter som måtte tale for hevingsrett på kundens hånd – mot prosjektets størrelse og mengden av ressurser nedlagt fra leverandørens side. Lagmannsretten slutter seg til dette synspunktet og legger til grunn at prosjektets størrelse og mengden nedlagte ressurser fra leverandørens side, er momenter som taler for en høy terskel for heving også ved brudd på biforpliktelser før levering. Dette må etter lagmannsrettens syn særlig gjelde hvis misligholdet av biforpliktelser ikke er til hinder for at resultatforpliktelsen kan oppfylles i tide til å forhindre heving på grunn av antesipert vesentlig forsinkelse.

Lagmannsretten går over til å se på hva som konkret kan påberopes som grunnlag for hevingen etter hevingsvarselet utfylt med korrespondansen kort tid før og etter varselet. Dette blir behandlet i punkt 3.2. Om de påberopte forholdene utgjør vesentlig inntrådt mislighold, blir behandlet i punkt 3.3.

3.2 Rammene som hevingsvarselet konkret setter i denne saken I hevingsvarselet 22. juni 2015 sto det under overskriften «Nærmere om IBMs vesentlige mislighold» at misligholdet «særlig» knyttet seg til det som SVV vurderte «som et forventet mislighold på grunn av IBMs løpende forsinkelse». Om inntrådt mislighold sto det: [...] Videre mener vi at IBM befinner seg i et aktuelt mislighold knyttet til kvalitet, kostnad, innhold i leveransen og den generelle prosjektstyringen. (FU 25115 på 25116) Under underoverskriften «Aktuelt mislighold» sto det på nytt at IBM befant seg «i vesentlig mislighold med hensyn til kvalitet, kost, leveranseomfang og den generelle prosjektstyringen» og at dette «underbygges også av de rapporter A-2 har fremlagt». (FU 25117) Hva som skal ha vært mislighold av prosjektstyringen, ble utdypet under overskriften «Grov uaktsomhet og forsettlige forhold hos IBM».

Ifølge SVV hadde IBM «opptrådt grovt uaktsomt ved ikke å varsle om prosjektets manglende fremdrift og ufullstendige leveranser, og de generelle utfordringer IBM» hadde hatt med leveransen siden disse «forholdene» måtte «antas å ha vært godt kjent for IBM over lengre tid». IBM hadde «underkommunisert» og ikke «vært åpne om de forhold som de var pliktige til å varsle SVV om» etter Generelle kontraktsbestemmelser punkt 2.3. (FU 25117) IBM hadde gitt «klart utilstrekkelig informasjon» om at selskapet hadde utsatt «den vesentlige delen av konstruksjonsfasen [...] til iterasjon 3». IBM hadde «heller ikke åpnet for nødvendig samspill med SVV». At det hadde vært «et fortløpende problem for SVV å få innsyn i IBMs utviklede løsning og planer», tydet på at IBM «også forsettlig» hadde misligholdt sine kontraktsforpliktelser. (FU 25118) SVV varslet at kontrakten ville bli hevet med mindre IBM utbedret forholdene innen 30 dager. (FU 25115 og 25118) Slik lagmannsretten ser det, var hevingsvarselet meget generelt formulert.

De eneste forholdene ved «den generelle prosjektstyringen» som SVV kan sies å ha identifisert og konkretisert i varselet, var at IBM hadde forsømt plikter knyttet til rapportering om fremdriften og leveranseomfanget, herunder rapportering om at

innhold var utsatt til iterasjon 3, og at IBM hadde forsømt plikter knyttet til samspill om og innsyn i løsningen og planene. Ved kommunikasjonen kort tid før og etter varselet, ble imidlertid ytterligere forhold identifisert og konkretisert, og påberopte forhold ble presisert. Første gang SVV skrev til IBM om vesentlig mislighold, var i brev 27. mai 2015, om lag en måned før hevingsvarselet. Under overskriften «IBMs vesentlige mislighold» sto det blant annet: SVV kan her vise til vesentlige restanser som stammer fra HMP1 og KP1, som fortsatt er utestående, samt ulike andre forhold som har vært utestående gjennom flere måneders KG-møter. Eksempler på det sistnevnte er sakene som ble eskalert til KG20. Ingen av disse sakene er lukket per i dag. SVV vil også peke på at IBMs prognoser endres fortløpende og uten nærmere begrunnelse. (FU 24182 på 24186 og 24187) Restansene «som stammer fra HMP1» var ikke nærmere identifisert eller konkretisert i brevet 27. mai 2015.

Basert på referatene fra KG-møtene, legger lagmannsretten til grunn at kontraktspartene hadde en felles forståelse av at SVV siktet til restansene R1, R3, R5 og R7 om gjennomføringsplan og verktøybruk. (FU 14225 flg.) Restansene «som stammer fra [...] KP1» var heller ikke nærmere identifisert eller konkretisert i brevet 27. mai 2015. Lagmannsretten legger til grunn at kontraktspartene hadde en felles forståelse av at SVV siktet til A-2s konklusjoner i rapport til KP1 31. oktober 2014. (FU 16708 på 16711) A-2 konkluderte her med at «mangelfull [...] realisme i fremdriftsplanen for iterasjon 2 og 3 [...] med høy sannsynlighet» ville føre til at HMP2 ikke ville bli nådd «med riktig kvalitet og omfang», og at «mangelfulle detaljerte planverk for iterasjon 2» ville føre til «at både fremdriftsmåling i forhold til baseline og grunnlaget for tilfredsstillende styring» var «svakt». A-2 konkluderte også med at «mangelfull beskrivelse av innhold og arkitektur i løsningen» kunne føre til både «redusert kvalitet på løsningen» og redusert mulighet «for SVV til å bidra konstruktivt med forbedring og optimalisering av løsningen».

Sakene «som ble eskalert til KG20» var heller ikke nærmere identifisert eller konkretisert i brevet 27. mai 2015. Det går imidlertid tydelig frem av punkt 5 «Eskalerte saker» i referatet fra KG-møte nr. 20 17. april 2015 at mangelfull logisk datamodell og mangelfulle planer for konfigurasjonsstyring og kravsporing var blant de eskalerte sakene. (FU 22624 på 22628) Det går frem av punkt 6 «Endringer» at det var «flere omtvistede endringer» som var eskalert, deriblant EA053 og EA054. (FU 22629) Hevingsvarselet viste ikke til brevet 27. mai 2015 under beskrivelsen av hva som skal ha vært vesentlig mislighold av prosjektstyringen, men viste til dette brevet, restansene ut av HMP1 og KP1 samt A-2s rapport 31. oktober 2014 under den innledende oppsummeringen av hendelsesforløpet. (FU 25115) Hevingsvarselet hadde også en generell henvisning til «de rapporter A-2 har fremlagt» under beskrivelsen av hva som skal ha vært vesentlig mislighold.

(FU 25116) Slik lagmannsretten ser det, kan SVV ved disse henvisningene sies å ha identifisert og konkretisert mislighold knyttet til gjennomføringsplanen, verktøybruken og arkitekturløsningen som forhold som kunne begrunne heving. Hevingsvarselet viste derimot ikke til sakene som ble eskalert til KG-møte nr. 20, noe som kan tale for at disse sakene – logisk datamodell, planer for konfigurasjonsstyring og kravsporing samt omtvistede endringer – ikke lenger ble ansett som forhold som kunne begrunne heving. Lagmannsretten bemerker i denne forbindelsen at det under listen over de eskalerte sakene i punkt 5 i referatet fra KG-møte nr. 20, sto: Etter eskalering til KG har det vært progresjon på flere av sakene. SVV ser positivt på dette, og er kjent med at status i vedlagt saksfremlegg for enkelte saker derav ikke er helt oppdatert med siste døgns endringer.

(FU 22624 på 22628) Slik lagmannsretten ser det, kan imidlertid de eskalerte sakene mangelfull logisk datamodell og mangelfulle planer for konfigurasjonsstyring og kravsporing, sies å være omfattet av forhold som ble identifisert og konkretisert i hevingsvarselet med videre henvisninger: Mangelfull logisk datamodell kan sies å ligge innunder det identifiserte og konkretiserte forholdet arkitektur, og mangelfulle planer for konfigurasjonsstyring og kravsporing kan sies å ligge innunder det identifiserte og konkretiserte forholdet verktøy. Videre ble mislighold knyttet til logisk datamodell og endringsanmodninger, fastholdt og presisert i den videre korrespondansen frem til og med 28. august 2015.

I brev 3. juli 2015, om lag to uker før varselfristen løp ut, viste SVV under punkt 5.2 om «Aktuelt mislighold», underpunkt 5.2.2 om «Kvalitet og prosjektstyring», til A-2s rapport 5. juni 2015. (FU 25357 på 25363 flg.) I denne A-2-rapporten sto det om logisk datamodell (LDM): Arbeidet med LDM har pågått lenge og er fortsatt ikke ferdig. Vi mener det er en risiko for at omfattende utviklingsarbeid og endringer sent i prosjektgjennomføringen kan medføre endringer også i LDM, med følgekonsekvenser for datakonsistens, systemarkitektur og migrering. [...] (FU 24498 på 24508) I brevet 3. juli 2015 ble «Omtvistede endringsanmodninger» beskrevet som aktuelt mislighold i punkt 5.2.1. (FU 25357 på 25363) I punkt 6 med overskriften «Grov uaktsomhet og forsett», underpunkt 6.1 med overskriften «Nærmere om IBMs underkommunikasjon og motvilje mot å levere», sto det: IBM har for øvrig ikke åpnet for nødvendig samspill med SVV. Det har i hele Konstruksjonsfasen vært et problem for SVV å få innsyn i IBMs utviklede løsning og planer, til tross for gjentatte forespørsler fra SVV sin side.

SVV er innforstått med at Kunden plikter å samarbeide med Leverandøren for å sikre at Leverandøren er i stand til å levere som forutsatt. SVV har gjennom hele kontraktsløpet stilt sine ressurser til disposisjon, men har gjennomgående blitt nektet innsyn i utviklet løsning. (FU 25366) I punkt 6.2 med overskriften «Flytting av innhold mellom iterasjoner» sto det blant annet: IBMs foreslåtte flytting av innhold i iterasjon 2 til iterasjon 3 medfører også at det oppstår en endring med hensyn til ansvarsreguleringen i inngåtte Kontrakt, til Leverandørens fordel. Herunder vil flyttingen føre til at avtalte betalingsplan blir uforholdsmessig opp mot det som skal leveres. Samlet sett ville en flytting av innhold mellom iterasjoner som nevnt utgjøre en vesentlig endring i inngått Kontrakt, hvilket SVV ikke har anledning til å gå inn på. (FU 25367) Slik lagmannsretten ser det, presiserte SVV ved brevet 3. juli 2015 at forholdet arkitektur omfattet mislighold knyttet til logisk datamodell. SVV presiserte også forholdene knyttet til endringsanmodninger samt samspill om og innsyn i løsningen og planene.

Videre ble det identifisert og konkretisert at selve flyttingen av innhold fra iterasjon 2 til iterasjon 3, var et forhold som kunne begrunne heving. SVV skrev avslutningsvis i brevet 3. juli 2015 at vegvesenet forventet at IBM, innen utløpet av varslingsfristen, iverksatte tiltak som sikret at IBM kunne «levere i henhold til Kontrakt innenfor det avtalte leveranseomfang, kostnadsregime, tid og kvalitet». (FU 25367) Lagmannsretten er enig med IBM i at denne avsluttende passusen om retting var egnet til å forvirre fordi den bare ser ut til å knytte seg til antesipert og ikke til inntrådt mislighold, men legger liten vekt på dette. SVV hadde listet opp en rekke forhold knyttet til inntrådt mislighold. Det fulgte klart nok av både kontrakten og hevingsvarselet at forhold som kunne begrunne heving, måtte rettes innen fristen på 30 dager for å avverge heving enten forholdene knyttet seg til antesipert eller inntrådt mislighold.

I SVVs hevingserklæring 27. juli 2015, ble det under overskriften «Aktuelt mislighold» gjentatt at IBM hadde «vesentlig misligholdt sine kontraktsforpliktelser med hensyn til kvalitet, kost, leveranseomfang og den generelle prosjektstyringen» og at dette var underbygd «også av de rapporter A-2 har fremlagt». Det ble også vist til brevet 3. juli 2015, «særlig punktene 5.2.2 og 6». (FU 26028 på 26031) I svaret på IBMs heving av Finansieringsavtalen og Leveranseavtalen med de tilhørende avtalene om drift, forvaltning og utvikling 5. og 14. august 2015, skrev SVV 28. august 2015, om lag en måned etter SVVs egen heving, i punkt 4.2 med overskriften «Aktuelt mislighold»: SVV mener for det første at IBM har misligholdt den varslingsplikten som følger av Kontrakten Del II pkt. 2.3. De utfordringene IBM hadde i prosjektet må antas å ha vært godt kjent for IBM over lengre tid. På tross av at rapportering har funnet sted i henhold til de intervaller som Kontrakten legger opp til, er det SVVs oppfatning at IBM har underkommunisert og vært inkonsistente i sin kommunikasjon, samt ikke vært åpne om de forhold som de var pliktige å varsle SVV om.

Etter SVVs oppfatning utgjør dette også et grovt uaktsomt forhold på IBM sin side. A-2 skriver følgende om IBMs fremdriftsrapportering:

«EV-rapporteringen [fremdriftsrapportering/«inntjent verdi»] har aldri fungert etter intensjonen og gjenspeiler ikke den reelle utviklingen i prosjektet. ETC [estimat for gjenstående arbeid] baseres i hovedsak på gjenstående kalendertid og antall ressurser og ikke estimat for resterende arbeid.» (FU 26112 på 26118) SVV skrev også at IBM hadde fremsatt endringsanmodninger «uten hjemmel i Kontrakten». (FU 26119) I punkt 4.2.1 med overskriften «Manglende kvalitet på IBMs arbeid» trakk SVV frem «at IBM aldri leverte en fullstendig logisk datamodell». (FU 26120) I punkt 4.2.2 med overskriften «IBMs manglende leveranseevne og kompleksitet i egne løsningsvalg», skrev SVV at IBM ikke «hadde foretatt en reell estimering av arbeidet før Konstruksjonsfasen startet, eventuelt at IBM sin oppfatning av kravenes, og dermed løsningens kompleksitet, har økt under Konstruksjonsfasen», og at dette var IBMs ansvar. (FU 26122) I punkt 4.2.3 med overskriften «IBMs manglende prosjektorganisering og -styring» skrev SVV blant annet: SVV har i hele prosjektperioden savnet og forventet troverdige prognoser og en realistisk gjennomføringsplan.

Dette var for øvrig en restanse fra HMP1 som aldri ble oppfylt i prosjektet. A-2 er av samme oppfatning, jf. følgende sitat fra A-2s rapport av 05.06.2015: «[d]e ulike planversjonene hittil i konstruksjonsfasen har vært top-down datostyrt uten nødvendig realisme. Det er et grunnleggende problem at nødvendige underlag for å kunne utarbeide planen er fraværende, svakt fundert eller mangelfullt harmonisert.» (FU 26123) SVV skrev i samme punkt også: Når det gjelder IBMs organisering og team vil SVV fremheve at mange av IBMs prosjektdeltakere pendlet til Oslo fra mange ulike land. SVV opplevde og påpekte manglende intern kommunikasjon i IBM. Arbeidet var fra IBM sin side organisert i «strømmer» som hadde lite kontakt med hverandre, og både planlegging, rapportering og løsningsbeskrivelse skjedde per strøm. Dette, kombinert med språkutfordringer, vanskeliggjorde koordinering internt hos IBM. (FU 26124) SVV siterte i fortsettelsen følgende fra A-2s rapport 31. oktober 2014: Ledelse av og samspillet mellom alle aktørene på tvers av geografi, kultur og språk hos kunde og leverandør er en betydelig utfordring.

Det er en lang vei fra et bomselskap i Trøndelag til en utvikler i India. Behov, krav og tilbakemeldinger skal først gjennom SVV og IBM lokalt, før det kommer til IBM GD. Dette gir en fare for at viktige nyanser går tapt. (FU 26124 og FU 16708 på 16713) SVV behandlet også stans i arbeidet for iterasjon 3, flytting av innhold mellom iterasjoner, dialogen mellom partene og «IBMs grunnløse endringsanmodninger» i egne punkter (punktene 4.2.7, 4.2.8, 4.2.9 og 4.2.10). (FU 26112 på 26127 og 26128) Slik lagmannsretten ser det, presiserte SVV ved brevet 28. august 2015 mislighold knyttet til fremdriftsrapportering, logisk datamodell, realistisk fremdriftsplan, flytting av innhold mellom iterasjoner, samspill og endringsanmodninger. SVV identifiserte og konkretiserte også mislighold knyttet til estimering, organisering og stans i arbeidet for iterasjon 3 som forhold som kunne begrunne heving.

Oppsummert hadde SVV kort tid etter hevingen identifisert og konkretisert følgende forhold som begrunnelse for hevingen: rapportering om fremdrift og leveranseomfang, herunder rapportering om flytting av innhold fra iterasjon 2 til iterasjon 3, samspill om og innsyn i løsningen og planene, realistisk og detaljert gjennomføringsplan, verktøybruk, herunder konfigurasjonsstyring og kravsporing, arkitekturløsningen, herunder logisk datamodell, flytting av innhold, endringsanmodninger, estimering, organisering og stans i arbeidet med iterasjon 3. Det er bare disse forholdene som kan påberopes som grunnlag for hevingen. Lagmannsretten går over til å begrunne hvorfor det ikke det forelå inntrådt vesentlig mislighold på hevingstidspunktet.

3.3 Har IBM vesentlig misligholdt prosjektstyringen? 3.3.1 Innledning – Forholdene som lagmannsretten vil vurdere Av forholdene som kan påberopes som grunnlag for hevingen, påberopes ikke lenger rapporteringen om leveranseomfang, herunder rapporteringen om flytting av innhold fra iterasjon 2 til iterasjon 3, samspill og detaljeringen av gjennomføringsplanen. Når det gjelder mislighold knyttet til arkitekturløsningen, påberopes det nå bare at SVV ikke fikk innsyn i arkitekturbeslutninger og at det aldri ble utarbeidet en helhetlig logisk datamodell. Forholdene som kan påberopes og blir påberopt er etter dette realistisk gjennomføringsplan, rapportering om fremdrift, verktøybruk, herunder verktøy for konfigurasjonsstyring og kravsporing, organisering, estimering, innsyn i arkitekturbeslutninger, helhetlig logisk datamodell, flytting av innhold, stans i arbeidet med iterasjon 3 og endringsanmodninger. Det rettes ikke lenger noen kritikk mot løsningens innhold eller kvalitet. Alle forholdene som kan påberopes og blir påberopt, har med IBMs prosjektstyring å gjøre.

Staten har i tillegg påberopt at IBM hadde begrenset erfaring med bompengedomenet, at IBM ikke fulgte opp avtalt arbeidsmetodikk med bruk av demoløsninger og at IBM ikke gjennomførte ytelsestest i iterasjon 1. Lagmannsretten går ikke inn på disse forholdene. Dette er forhold som både faller utenfor rammen av SVVs hevingsvarsel og som var synlige for vegvesenet på hevingstidspunktet. De kan ikke påberopes. Lagmannsretten går over til å vurdere om hvert av forholdene som kan påberopes og blir påberopt, utgjorde mislighold av kontrakten, og i tilfellet om misligholdet var vesentlig, i punkt 3.3.2 til 3.3.9 nedenfor. Ved vurderingen tar lagmannsretten utgangspunkt i at IBM som leverandør hadde både ansvaret for å planlegge, organisere og lede arbeidet slik at det ble gjennomført i tråd med kontraktsforpliktelsene, jf. Bilag B punkt 2.5.3, og det overordnede «lederansvaret for arbeidet med løsningsbeskrivelse, konstruksjon, godkjenning og idriftsettelse», jf. Bilag B punkt 2.5.5. (FU 9069 på 9075 og 9077) Lagmannsretten behandler forholdene i samme rekkefølge som staten, og ser på forholdet realistisk gjennomføringsplan først.

3.3.2 Realistisk gjennomføringsplan Kontrakten taler om både gjennomføringsplan og fremdriftsplan. I denne saken er begrepene gjennomføringsplan og fremdriftsplan brukt om hverandre. Generelle kontraktsbestemmelser og Bilag C bruker begrepet fremdriftsplan. Det følger av Generelle kontraktsbestemmelser punkt 3.2.4 at «Fremdriftsplanen» er tidspunktene for gjennomføringen av leveransen etter Bilag C, og at den er basert på kontraktens milepæler. (FU 8458 på 8466) Etter punkt 3.4.1 skal kontraktspartene «sammen, men under Leverandørens ledelse og styring, legge en detaljplan for hvert trinn i Konstruksjonsfasen, innenfor rammene av Fremdriftsplanen». (FU 8467) Etter punkt 3.4.5 skal leverandøren utarbeide en plan i hvert kontrollpunkt for det etterfølgende trinnet «basert på overordnet Fremdriftsplan og erfaringer fra gjennomført trinn». (FU 8468) Det følger av Bilag C punkt 5 om «Fremdriftsplan» under punkt 5.1.1 med overskriften «Milepælsplan» at fremdriftsplanen «skal» strukturere aktivitetene frem mot kontraktens milepæler.

Planen skal vise avhengigheter mellom hovedaktivitetene og plassere aktivitetene i tid slik at milepælene «kan nås». (FU 9105 på 9161) Ved kontraktsinngåelsen ble det utarbeidet en plan for hele prosjektet («Prosjektplan») som er inntatt som et vedlegg til Bilag C. (FU 9245 flg.) PRO006 Arbeidsprosesser som ble levert til HMP1 (løsningsbeskrivelsen), bruker begrepet gjennomføringsplan. (FU 10) Etter PRO006 Arbeidsprosesser, versjon 2.8, datert 18. november 2014, punkt 10, skulle det utarbeides et planverk strukturert i tre nivåer: En masterplan (det øverste nivået), en gjennomføringsplan (det midterste

nivået) og detaljerte oppfølgingsplaner (det nederste nivået). Masterplanen viste prosjektets totale tidslinje med samtlige faser. De detaljerte oppfølgingsplanene besto av «detaljerte oversikter og aksjoner på et dag-til-dag nivå». Om gjennomføringsplanen står det: [...] Dette er en detaljert gjennomføringsplan som angir hver av iterasjonene, samtlige funksjonsområder og strømmer på et hensiktsmessig detaljnivå. [...] I tillegg vil denne planen beskrive både interne og eksterne avhengigheter. Dette vil være den sentrale planen for styring og oppfølgning av prosjektet totalt sett. (FU 62 på 101) Staten har gjort gjeldende at IBM pliktet å utarbeide en realistisk gjennomføringsplan, mens IBM har gjort gjeldende at kontrakten ikke inneholder noe krav om at planen må være realistisk. Generelle kontraktsbestemmelser og Bilag C stiller ikke noe uttrykkelig krav til at fremdriftsplanen/gjennomføringsplanen må være realistisk.

En naturlig språklig forståelse av Generelle kontraktsbestemmelser punktene 3.2.4 og 3.4.1 og Bilag C punkt 5.1.1 lest i sammenheng, kan tale for at planen må ligge innenfor de kontraktsfestede milepælene, jf. formuleringen i Generelle kontraktsbestemmelser punktene 3.2.4 og 3.4.1 om at detaljplanene for hvert trinn skal legges innenfor fremdriftsplanen som igjen er basert på kontraktens milepæler, og formuleringen i Bilag C punkt 5.1.1 om at planen «skal» strukturere aktivitetene frem mot milepælene. Ordlyden kan på den andre siden også tale for at planen må være realistisk, jf. formuleringen i Bilag C punkt 5.1.1 om at planen skal strukturere aktivitetene frem mot milepælene slik at de «kan nås». PRO006 Arbeidsprosesser stiller heller ikke noe uttrykkelig krav til at planen må være realistisk, men gir veiledning om at den må kunne styres etter, jf. formuleringen om at gjennomføringsplanen var «den sentrale planen» for styring av prosjektet.

Slik lagmannsretten ser det, forpliktet IBM seg uansett hva som kan utledes av kontraktens ordlyd, til å utarbeide en realistisk gjennomføringsplan etter løsningsbeskrivelsen som ble godkjent med restanser. SVV satte 4. juli 2014 «Mangler i plan for konstruksjonsfasen» som restanse R5. SVV viste til at manglene «understøttes av A2-tiltak» og satte «A2-tiltak skal gjennomføres» som forutsetning for å godkjenne HMP1. Tiltakene dreide seg om å «sikre realistisk fremdriftsplanlegging». (FU 14223 og FU 14225 på 14229) IBM aksepterte alle SVVs restanser, inkludert restanse R5. SVV etterlyste en realistisk gjennomføringsplan i så å si alle KG-møtene fra og med 18. september 2014, og IBM bekreftet forpliktelsen til å utarbeide en realistisk plan i disse møtene. IBM oversendte gjennomføringsplaner mellom møtene og medga helt frem til og med 17. april 2015 at planene måtte forbedres.

I referatet fra KG-møte 18. september 2014 heter det: Prosjektledelsen på begge sider har konkludert med at man skal prioritere å ferdigstille konsistente, dekkende og troverdige planer: «Gjennomføringsplan» (Detaljert plan for alle aktiviteter og leveranser som skal utføres i alle «strømmene» ila Konstruksjonsfasen) og «Masterplan (skal dekke alle aktiviteter og leveranser som skal gjennomføres frem til 15. nov 2015, men ikke på detalj-nivå). (FU 15488 på 15492) Det heter videre at planverket hadde «vært for fragmentert og inkonsistent» og hadde «manglet både interne avhengigheter og avhengigheter mot SVV», samt at IBM ville oversende en oppdatert versjon av planene 19. september 2014. (FU 15489) IBM oversendte 23. september 2014 PRO001 Gjennomføringsplan versjon 0.91. Det går frem av referatet fra KG-møte 24. oktober 2014 at SVV fortsatt ventet på planverk fra IBM, og at vegvesenet forventet en gjennomføringsplan som dekket samtlige strømmer, dekket alle aktiviteter for hele iterasjon 2, hensyntok alle avhengigheter og viste hva som var innholdet/scope i iterasjon 2 og 3. Aktivitetene måtte også være estimert.

Det var enighet om at IBM skulle levere oppdatert planverk til 26. oktober 2014. (FU 16529 på 16531) IBM oversendte 29. oktober 2014 PRO001 Gjennomføringsplan versjon 1.1. Det går frem av referatet fra KG-møte 18. november 2014 at Jane Bordal, som ledet både koordineringsgruppen og SVVs styringsgruppe (SG), etterlyste en forklaring på hvorfor planene fortsatt ikke var ferdigstilt. (FU 17223) IBM forklarte at selskapet hadde planer på flere nivåer og at de i det daglige styrte etter «planer på lavt

nivå, i store regneark per team», men at disse ikke viste sammenhenger og avhengigheter som var «nødvendige» for å kunne lage en konsolidert plan som prosjektet samlet hadde behov for. IBM var enig i at «prosessen for arbeid med planer» ikke hadde vært «god nok». SVV krevde at planene «som et minimum» måtte være «korrekte, konsistente og vise avhengigheter», og at de måtte vise hva vegvesenet ble forventet å levere til prosjektet og tidspunktene for leveransene slik at vegvesenet blant annet kunne ha «rett bemanning til rett tid». (FU 17224) Det går frem av presentasjonen som IBMs og SVVs prosjektledere, Terje Harangen og Anne-Marie Ytrehus, holdt i fellesskap i KG-møtet 18. november 2014 at IBM skulle sikre at både gjennomføringsplanen og masterplanen var «troverdige og konsistente». (FU 17241 på 17258) IBM oversendte 22. november 2014 PRO001 Gjennomføringsplan versjon 1.2 og 6. desember 2014 PRO001 Gjennomføringsplan versjon 1.3. I KG-møte 18. desember 2014 krevde SVV å få en plan med datoer som vegvesenet kunne «stole på». SVV mente at prosjektet ikke kunne fortsette med planer som «alle» visste ikke holdt.

IBM opplyste at selskapet ville «starte med planarbeidet sammen med SVV umiddelbart etter nyttår». Prognosen var at gjennomføringsplanen ville bli levert 15. januar 2015. (FU 18383 på 18386) Det ble også bestemt at IBM skulle utarbeide en realistisk prognose for oppnåelse av HMP2 og HMP3. (FU 18388 og 18198) Det går frem av referatet fra KG-møte 15. januar 2015 at SVV var opptatt av at det ble kommunisert «en realistisk prognose» som skulle holde for gjennomføringen; SVV så det ikke som «ønskelig med flere prognose endringer av HMP2 datoen». (FU 19410 på 19413) IBM oversendte 20. januar 2015 PRO001 Gjennomføringsplan versjon 2.0 og 12. februar 2015 PRO001 Gjennomføringsplan versjon 2.1. Det går frem av referatet fra KG-møte 19. februar 2015 at SVV krevde at IBM presenterte «en realistisk troverdig totalplan» som Bordal kunne presentere i SG-møte og møte med Samferdselsdepartementet henholdsvis 23. og 25. februar 2015. IBM forklarte at planarbeidet var omfattende, og at det var «nedprioritert og forsinket hos dem grunnet manglende kapasitet». A-2 viste her «forståelse for SVVs frustrasjon».

Ifølge A-2 var det ikke «noen troverdighet» i planene og prognosene som IBM hadde levert frem til da. Det går frem av referatet at planen da var at HMP2 skulle nås 20. juli 2015. Ifølge A-2 burde IBM hatt «tilstrekkelig med erfaring og kjennskap med status og fremdrift til å kunne beskrive forutsetninger og legge planprognoser for både HMP2 og HMP3» på dette tidspunktet. (FU 20425 på 20426) IBM oversendte først 6. mars 2015 PRO001 Gjennomføringsplan versjon 2.2. I KG-møte 17. mars 2015 ga A-2 uttrykk for at det var «vanskelig å gi en vurdering av plan og fremdrift» fordi det ikke forelå «en baselinet plan» som partene trodde på og som det ble rapportert konsistent opp mot. A-2 anbefalte å etablere «en omforent, baselinet plan som minimum» inkluderte «alle avhengigheter mellom partene». (FU 21286 på 21290) IBM oversendte 23. mars 2015 PRO001 Gjennomføringsplan versjon 3.0. og 17. april 2015 PRO001 Gjennomføringsplan versjon 2.3. Det går frem av referatet fra KG-møte 17. april 2015 at A-2 savnet «realisme i IBMs planverk»: Det synes som om IBM har bestemt seg for en dato for HMP2, og kjører etter den.

I en plan man selv har kontroll på alle elementer i, vil dette være en mulig strategi, men med så mange avhengigheter mellom flere parter vil det ikke være mulig å gjennomføre en så aggressiv plan uten svært tett samspill. Under overskriften «Kommentarer fra IBM» sto det at IBM lovte «å levere en troverdig plan som alle i KG tror på», og at IBM jobbet med «å fastsette tiltak» som synliggjorde «mulig fremdrift i henhold til plan». (FU 22624 på 22627 og 22628) Oppsummert mener lagmannsretten at IBM forpliktet seg til å utarbeide en realistisk gjennomføringsplan ved å akseptere restansen R5 ved HMP1 og gjentatt bekrefte denne forpliktelsen gjennom konstruksjonsfasen. På den andre siden viser ikke aksepten av restansen R5 og de etterfølgende bekreftelsene, mer enn at IBM var forpliktet til å utarbeide en gjennomføringsplan som var realistisk i den forstand at milepælene i den kunne nås, jf. Bilag C punkt 5.1.1, og at den kunne styres etter, jf. PRO006. Lagmannsretten legger i dette at det måtte kunne latt seg gjøre å nå planens milepæler i praksis. At planen kunne styres etter, innebærer ikke nødvendigvis

at den måtte ligge fast. I en iterativ prosess med samhandling som her, måtte det være rom for fleksibilitet og justeringer i planen. Slik lagmannsretten ser det, oppfylte ikke IBM forpliktelsen til å utarbeide en realistisk gjennomføringsplan i tiden før KG-møtet 17. april 2015. IBM ser ut til å ha sagt seg enig i dette frem til dette tidspunktet. Slik lagmannsretten også ser det, ble imidlertid dette forholdet rettet før hevingstidspunktet 27. juli 2015. IBM oversendte 22. april 2015 PRO001 Gjennomføringsplan versjon 4.0. Denne planen ble levert til kontrollpunkt 2 (KP2). IBMs leveranse til KP2 ble underkjent av SVV. SVV ga tre begrunnelser for å underkjenne KP2. Den ene begrunnelsen var at planen ikke var realistisk. (FU 23210 på 23213) Staten har gjort gjeldende at det var null prosent sannsynlighet for at IBM kunne ferdigstilt arbeidet innen datoene i planen. IBM har bestridt dette. Lagmannsretten mener at denne planen var realistisk og kommer tilbake til dette i punkt 4.4.8.6 nedenfor. Det er ikke gjort gjeldende at det ble oversendt gjennomføringsplaner etter dette som var enda mindre realistiske.

Det forelå således ikke mislighold av forpliktelsen til å utarbeide en realistisk plan på hevingstidspunktet. At det ikke forelå en realistisk plan, kan da ikke begrunne SVVs heving. Staten har også gjort gjeldende at IBM aldri utarbeidet en plan som var av god nok teknisk kvalitet, mens IBM har gjort gjeldende at SVV stilte overdrevne krav og at dette forholdet uansett må anses som rettet på hevingstidspunktet. Det har vært svært lite bevisførsel om den tekniske kvaliteten på gjennomføringsplanene. I den grad det har vært noe å utsette på planenes tekniske kvalitet, er lagmannsretten imidlertid enig med IBM i at dette forholdet må anses som rettet på hevingstidspunktet. Som lagmannsretten kommer tilbake til i punkt 4.4.8.6 nedenfor, ble det ikke reist kritikk mot den tekniske kvaliteten på PRO001 Gjennomføringsplan versjon 4.0 som ble levert til KP2. Det er heller ikke kommet frem noen kritikk mot den tekniske kvaliteten på senere planer. At planene ikke var av god nok teknisk kvalitet, kan således heller ikke begrunne SVVs heving.

3.3.3 Reell fremdriftsrapportering Etter kontrakten skal leverandøren «periodisk rapportere og presentere status for Kunden, basert på rutiner for oppfølging og rapportering i Bilag B», jf. Generelle kontraktsbestemmelser punkt 2.3. (FU 8458 på 8465) I Bilag B punkt 4.1 om oppfølging og rapportering, står det blant annet: Fremdriftsoppfølgning skal foretas i forhold til to ulike referanserammer; milepæler (Hovedmilepæler, Kontrollpunkter og øvrige Milepæler) og planlagt fremdrift i form av periodiserte fremdriftsplaner, slik planene er fastlagt i Bilag C. Milepæler blir enten nådd eller ikke nådd, mens reell fremdrift beregnes og sammenholdes med planlagt fremdrift og timeforbruk. (FU 9069 på 9078) I punkt 4.1 er det også listet opp ni krav til de månedlige statusrapportene. Kravet for fremdrift lyder slik: [...] S-kurve med planlagt og reell fremdrift (inntjent verdi). I tillegg inkluderes en budsjettkurve og tilhørende prognose basert på reell fremdrift pluss oppdatert estimat for gjenstående tid. (FU 9079) Etter punkt 4.1 skal leverandøren også «fortløpende rapportere forbruk av timer basert på Earned Value».

Rapportene skal vise «Forbrukte timer, %Ferdig, %Brukt, Kostnadsindeks og Fremdriftsindeks per fase/WBS». (FU 9079) WBS er forkortelse for Work Breakdown Structure. Rapportene skal bruke parameterne Earned Value (EV), Planned Value (PV), Budget at Completion (BAC), Actual Cost (AC), Cost Performance Index (CPI), Schedule Performance Index (SPI), Estimate at Completion (EAC) og Estimate to Completion (ETC). (FU 9080) Disse rapporteringsparameterne er standard bransjebegreper innen Earned Value Management (EVM). Staten har innhentet en sakkyndig rapport fra IT-rådgiver Leif-Arne Rones 2. desember 2021. Med utgangspunkt i bransjestandarden Project Management Institute (PMI), definerte Rones de aktuelle parameterne slik:

• Planned value (PV): Planlagt verdi for prosjektet på et gitt tidspunkt. Ved prosjektets slutt, skal PV representere den totale verdien på leveransen (BAC).
• Budget At Completion (BAC): Siste omforente estimat (baseline) for hele prosjektet. Det er det samme som summen av PV ved prosjektets slutt.
• Earned value (EV): Inntjent verdi på et gitt tidspunkt. Brukes ofte for å kunne si noe om ferdigstillelsesgraden for prosjektet. EV kan aldri bli større enn PV.
• Actual cost (AC): Faktisk kostnad på et gitt tidspunkt, dvs. den påløpte kostnaden for å levere den oppnådde verdien EV. For den faktiske kostnaden AC er det ingen øvre begrensning mot planlagt verdi, dvs. den kan bli vesentlig større enn PV. IBM bruker forkortelsen ACT i statusrapportene.
• Cost performance index (CPI): CPI=EV/AC Måler forholdet mellom inntjent verdi og faktisk kostnad. Dette er den mest sentrale parameteren i EVM metodikken. CPI under 1 uttrykker at det leveres mindre verdi enn kostnaden som påløper, dvs. leveransen ligger an til å få en kostnadsoverskridelse.
• Schedule Performance index (SPI): SPI= EV/PV Måler forholdet mellom inntjent verdi og hvor man hadde planlagt å være. SPI under 1 uttrykker at verdi leveres langsommere enn planlagt, dvs. at prosjektet ligger an til en forsinkelse.
• Estimate at completion (EAC): Estimert sluttkostnad for prosjektet. Baseres på faktisk kostnad AC og et estimat for gjenstående arbeid (ETC) ved en gitt rapporteringsperiode.
• Estimate to complete (ETC): Estimat for gjenstående arbeid. Vurderes pr arbeidspakke ved hver rapporteringsperiode, og rulles opp for hele prosjektet. (Rones, TU2 2825 på 2830) Alle rapporteringsparameterne kan måles i både timer og kroner.

Staten har gjort gjeldende at IBM var forpliktet til å rapportere om fremdriften i tråd med bransjestandarden. IBM har gjort gjeldende at bransjestandarden ikke har noen plass i kontrakten.

IBM opplyste i sitt første tilbud 18. februar 2013 at selskapet ville bruke prosjektstyringsmetodikken IBM Worldwide Project Management (WWPMM), og at WWPMM var «harmonisert med metodeverket til Project Management Institute (PMI)». (FU 4315 på 4664) Kontrakten viser imidlertid ikke til noen bransjestandarder.

I statusrapport 10. februar 2014 skrev SVVs Stein Ødegaard, som da var delprosjektleder for delprosjektet Leveranse, under det avsluttende punktet med overskriften «Erfaringer»:

I kontrakten stilles det krav om at det skal rapporteres inntjent verdi, men ingen kriterier for hvordan inntjent verdi skal settes. Ut fra hva vi har fått så langt er vi usikre på hvilken verdi denne rapporteringen av inntjent verdi vil gi oss. IBM har signalisert at de er åpne for å forbedre modellen sin for inntjent verdi, som er positivt. Erfaringen er likevel at dersom inntjent verdi-rapportering er veldig viktig for kunden bør det beskrives bedre i kontrakten hvordan man ønsker å gjennomføre det. (FU 10192 på 10196 og 10197) SVV var med andre ord i tvil om verdien av EV-rapporteringen under løsningsbeskrivelsesfasen fordi Leveranseavtalen ikke stilte «kriterier for hvordan inntjent verdi» skulle settes. SVV mente også at kriteriene for hvordan inntjent verdi skulle settes, burde beskrives bedre hvis rapporteringen av inntjent verdi var «veldig viktig for kunden». SVV tok til tross for denne tvilen ikke initiativ til en bedre beskrivelse av kriteriene for inntjent verdi, for eksempel ved å vise til bransjestandard, i løsningsbeskrivelsen.

Slik lagmannsretten ser det, går det likevel klart nok frem av Bilag B punkt 4.1 at rapporteringen skulle vise «reell» fremdrift «basert på Earned Value». Siden Earned Value er et standard bransjebegrep, må det anses for å være en presumsjon for at rapporteringen var i tråd med bransjestandard for EVM med mindre det var enighet om noe annet.

IBMs EV-rapportering inkluderte såkalte «tidsdrevne» aktiviteter slik som prosjektledelsen fra det lokale teamet i Norge. De tidsdrevne aktivitetene var vanskelig å knytte til planlagte leveranser. De ga ingen indikasjon på om en arbeidspakke var ferdigstilt eller ikke og førte derfor til at fremdriftsrapporteringen ikke ble reell; de «forurenset» rapporteringen. Leif-Arne Rones innførte begrepet «produksjonsdrevne aktiviteter» som en motsetning til begrepet tidsdrevne aktiviteter. Han definerte begrepet slik:

• Produksjonsdrevne aktiviteter: Aktiviteter for de teamene som jobber direkte med utvikling av løsningen. Planlagt verdi er basert på de akkumulerte DCUT estimatene for alle de enkelte arbeidspakkene i hvert team (iflg. IBM). [...] (TU2 2825 på 2830) Arbeidet med design, utvikling og enhetstesting (Design, Construction and Unit testing (DCUT)), kan regnes som produksjonsdrevet. Å skille ut arbeidet med DCUT i rapporteringen, ble sett som én løsning på «forurensningsproblemet».

Det ser ikke ut til å være omtvistet at det ikke var i tråd med bransjestandard å inkludere tidsdrevne aktiviteter i EV-rapporteringen.

IBMs prosjektleder, Terje Harangen, og utviklingsleder for GDene, Sander van der Harst, har forklart at SVV var innforstått med at de tidsdrevne aktivitetene ble «distribuert» på strømmene i EV-rapporteringen og at denne rapporteringen derfor ikke ga et uttrykk for reell fremdrift. Harangen og van der Harst har også forklart at det var SVVs controller, Anne Torland, som hadde bedt om at de tidsdrevne aktivitetene ble tatt med. Torland hadde sagt at hun hadde behov for å se den totale økonomiske statusen for alle kostnadene i prosjektet. Torland har ikke avgitt vitneforklaring.

Slik lagmannsretten ser det, viser de begivenhetsnære bevisene at SVV var klar over at de tidsdrevne strømmene var inkludert og at EV-rapporteringen ikke viste reell fremdrift. De begivenhetsnære bevisene gir derimot ikke holdepunkter for at det var Torland eller andre i SVV som ba om at rapporteringen skulle skje på denne måten. De begivenhetsnære bevisene viser at SVV tvert imot ikke var fornøyd med rapporteringen, og at kontraktspartene etter hvert uansett ble enige om å gjøre endringer i den.

I IBMs månedsrapport for november 2014, datert 6. desember 2014, punkt 3 «EV-rapportering», sto det under overskriften «Beregning av Planlagt verdi (PV) og Inntjent verdi (EV)»:

For de teamene som jobber direkte med utvikling av løsningen er Planlagt verdi basert på de akkumulerte DCUT estimatene for alle de enkelte arbeidspakkene i hvert team. Planlagte timer for de lokale ressursene innen disse teamene er lagt til på toppen av DCUT estimatene og fordelt jevnt ut i perioden. For disse teamene beregnes Inntjent verdi av den budsjettert kostnaden for de ferdigstilte arbeidspakkene, i tillegg kommer den planlagte kostnaden for lokale ressurser i perioden. Det er flere team som er typisk tidsdrevne, eksempler er ARC, PRO, TES og TRA. Her er Planlagt verdi satt lik den estimerte ressursbruken for hver enkelt uke basert på kapasitetsplanen. Inntjent verdi er satt lik planlagt timeforbruk per uke/team multiplisert med gjennomsnittlig timepris. (FU 16798 på 16809 og TU2 2825 på 2848) Under overskriften «Foreslått endring» sto det:

Det er foreslått fra både SVV og IBM å gjøre en endring i PV og EV beregningen når det kommer til hvilken timepris som skal legges til grunn. Det er enighet om at man ved bruk av faktiske timepriser fra ratecard ville få et mer riktig budsjett og inntjent verdi, i praksis er det mest aktuelt å benytte én pris for GD og én for lokale ressurser. (FU 16809) Slik lagmannsretten leser denne månedsrapporten, beskrev den at de tidsdrevne aktivitetene var lagt inn i EVrapporteringen. Forslaget om endring i timeprisene ville bare delvis løst problemet med forurensing. Det går frem av referatet fra KG-møtet 18. desember 2014 at IBM presenterte nøkkeltall fra månedsrapporten for november 2014 i dette møtet. Dette referatet viser også at SVV var klar over forurensningen fra de tidsdrevne strømmene. Her sto det: [...] Konstruksjonsfasen sett som helhet ligger noe etter plan i forhold inntjent verdi, tross høyere kostnader enn planlagt. Grunnet et stort lokalt team med høyere timerater enn GD, og at de lokale ressursene er «tidsdrevne» og derav driver «inntjent verdi» til å være høyere enn reell fremdrift av iterasjon 2.

Produksjonen har derfor reelt ikke kommet så langt som IBMs statusrapport fremstiller. (FU 18383 på 18384) I dette møtet ble IBM og SVV enige om at månedsrapportene også burde inkludere status fra utviklingsteamene i GDene, det vil si DCUT-teamene, fordi dette ville gi «et bedre bilde av reell fremdrift enn dagens rapportering». (FU 18386)

Sander van der Harst deltok ikke i dette KG-møtet, men har forklart at selv om SVV var opptatt av reell fremdriftsrapportering, var det ikke tale om EV-rapportering på dette tidspunktet. IBMs månedsrapport for desember 2014, datert 9. januar 2015, inneholdt en så å si identisk beskrivelse av EVrapporteringen som rapporten for november 2014. IBM tilføyde at det ikke hadde vært mulig å få innarbeidet timeprisendringen i denne rapporten, men at selskapet ville «følge opp dette videre». SVVs kommentar til denne tilføyelsen var: «Fint med forklaring av dette». (FU 19250 på 19260) I tillegg ble det lagt til et nytt nøkkeltall: «Prosent ferdig (EV/BAC) for DCUT team i konstruksjonsfasen». Dette tallet var bare basert på EV og BAC i teamene CRM, FIN (SAP), INT, IRIS, REP og SEL. SVVs kommentar til det nye nøkkeltallet var: «Bra at dette nå er med».

(FU 19261) Månedsrapporten for desember 2014 viste ikke status fra DCUT-teamene i EV-rapporteringen, men i form av grafiske fremstillinger av «Total DCUT Burndown» og «Total DCUT «Widget» Tracking». «Total» betød at fremstillingene var aggregert for flere strømmer (CRM, SSP, REP, MIG, INT, SEC og RSGW). Widgets var brukerhistorier brutt ned til arbeidspakker. SSP er forkortelse for Self Service Portal, også ofte forkortet til SEL. I denne månedsrapporten var det også tatt inn fremstillinger av «DCUT «Widget» Tracking» for IRIS, INT og SAP-FICA. (FU 19216 på 19223 flg.) Ifølge Terje Harangen ble widget-rapporteringen introdusert av IBMs European Public Sector Delivery Leader and Executive Partner, Stewart Knox. SVV hadde ingen kommentarer til at status fra DCUT-teamene bare gikk frem av «DCUT Burndown» og «DCUT «Widget»». At dette ikke ble kommentert, kan slik lagmannsretten ser det, tale for Sander van der Harsts forklaring om at enigheten i KG-møtet 18. desember 2015 ikke gjaldt EV-rapportering.

I IBMs månedsrapport for januar 2015, datert 6. februar 2015, var timeprisendringen innarbeidet slik som varslet i rapporten for desember 2014. (FU 19960 på 19971) Denne månedsrapporten viste også status fra DCUT-teamene i form av «Total DCUT Burndown» og «Total DCUT «Widget» Tracking». (FU 19968 flg.) Anne Torland ga følgende «tilbakemelding på EV-rapportering for januar» 2015 i e-post 12. februar 2015 til Sander van der Harst: Som jeg nevnte da vi pratet kort sammen om EV-rapporteringen så har jeg ikke sett noen inkonsistenser i tallene, eller noe som ikke ser «riktig» ut J Sender som avtalt her noen flere tilbakemedlinger:

1. Jeg syns dere forklarer grundig og bra hvilke endringer dere har gjort i modellen (dette med endring i bruk av timepriser), og hvilke konsekvenser dette får. Og det er supert.
2. Ellers når det gjelder modellen så lurer jeg på hvor mye de lokale ressursenes «tidsstyrte» bidrag styrer ferdigstillelsesgraden for utviklingsteamene. Ut fra tallene dere har levert så ser det ut som at dere ligger nesten på plan, og at dere kan rekke forventet ferdigdato 28/4. Men ifølge siste prognose vi har mottatt så er ny forventet ferdigdato 20/7, som vel betyr at rapportert ferdiggrad er noe for høy(?). Mitt innspill er altså å se på det tidsstyrte bidraget for utviklingsteamene, og om det å gjøre dette på en annen måte kan gi en mer reell ferdigstillelsesgrad (for DCUT-team). [...] (FU 20270) Lagmannsretten er enig i statens forståelse av Anne Torlands innspill i punkt 2. Torland ser her ut til å ha foreslått å identifisere det tidsdrevne bidraget slik at EV-rapporteringen kunne gi et mer reelt bilde av fremdriften, det vil si fremdriften i DCUT-arbeidet.

Sander van der Harst har forklart at han ble enig med Anne Torland om å skille ut DCUT i EV-rapporteringen. IBM har ikke gjort gjeldende at van der Harst ikke hadde kompetanse til å forplikte selskapet på dette punktet; IBM har tvert imot gjort gjeldende at van der Harst hadde kompetanse til å avtale at rapporteringen skulle avvike fra bransjestandard.

Slik lagmannsretten ser det, må IBM etter dette sies å ha forpliktet seg til å skille ut DCUT i EV-rapporteringen etter Anne Torlands e-post 12. februar 2015. Utskillingen av DCUT, ville brakt EV-rapporteringen mer i tråd med bransjestandard. Dette ser imidlertid ikke ut til å ha skjedd.

I ekstraordinært SG-møte 9. mars 2015 presenterte SVV en prognose som viste at HMP2 ville bli nådd 6. november 2015. IBMs lederrepresentant, Geir Haugen, kommenterte at usikkerheten knyttet til denne datoen var lavere enn det SVV opplevde, at det var gjennomført 1 000 av totalt 1 400 test caser og at det ikke var noe som tilsa at løsningen ikke lot seg levere. Haugen opplyste at det ville bli gjennomført tiltak for å bedre

fremdriftsrapporteringen. Rapporteringen hadde ikke vært «god nok». Forbedringen i rapporteringen skulle skje ved å måle fremdriften «innen de tre områdene: Detaljert design, konstruksjon og test, basert på henholdsvis status på usecases, fremdrift workpackages og gjennomførte testcaser». (FU 21070 på 21071) Slik lagmannsretten forstår Geir Haugens forslag, talte han ikke om EV-rapportering her. DCUT skulle måles på de tre områdene brukerhistorier («use cases»), arbeidspakker/widgets («work packages») og test caser. Det kan se ut til at SVV først aksepterte at DCUT ble målt på denne måten. Den 16. mars 2015 skrev Stein Ødegaard, som hadde vært hovedprosjektleder fra oppstarten av konstruksjonsfasen, at SVV manglet «trygghet» for at IBM rapporterte «reell fremdrift» og at vegvesenet så «frem til resultatet av» den forbedrede fremdriftsrapporteringen som Geir Haugen hadde lovet i det ekstraordinære SG-møtet 9. mars 2015. (FU 21231) Etter KG-møte 17. mars 2015 sto det imidlertid som åpen aksjon at «EV kapitlet» ikke var «tilfredsstillende p.t». (FU 21286 på 21291) I referatet fra KG-møte 17. april 2015 sto det om EV-rapporteringen:

• Måten EV brukes i rapporteringen viser ikke den reelle fremdriften av selve løsningsutviklingen i prosjektet. Burndown på DCUT-timer og gjennomførte testcaser er mer interessant fremdriftsrapportering enn det som vises i EV regnskapet.
• IBM ønsker fremover å gjøre en mer manuell vurdering av SPI/CPI for bedre rapporteringen. (FU 22624 på 22625) EV-rapporteringen var ikke tema i KG-møtene 12. mai og 16. juni 2015. (FU 23704 flg. og 24893 flg.) EVrapporteringen var derimot tema i A-2s «Rapport til KP2» 5. juni 2015. Her sto det: EV-rapporteringen har aldri fungert etter intensjonen og gjenspeiler ikke den reelle utviklingen i prosjektet. ETC baseres i hovedsak på gjenstående kalendertid og antall ressurser og ikke estimat for gjenstående arbeid. (FU 24498 på 24503) Lagmannsretten legger etter dette til grunn at DCUT ikke ble skilt ut i EV-rapporteringen slik Anne Torland og Sander van der Harst ble enige om etter Torlands e-post 12. februar 2015. Dette utgjorde mislighold av kontrakten.

Selv om dette var kritikkverdig, mener lagmannsretten at dette misligholdet isolert sett ikke var vesentlig. SVV var klar over svakhetene i EV-rapporteringen. Rapporteringen av inntjent verdi ble ikke sett som viktig nok for SVV til at vegvesenet tok initiativ til å regulere hvordan inntjent verdi skulle settes i løsningsbeskrivelsen slik Stein Ødegaard var inne på i statusrapporten 10. februar 2014. IBM var åpen om svakhetene ved rapporteringen og rapporterte dessuten om fremdriften på andre måter. IBM begynte med «widget unit»-rapporteringen fra november 2014. Den første grafiske fremstillingen av widget-rapportering skal ha vært en statusrapport for strømmene SAP (FIN) og IRIS til prosjektledermøte 26. november 2014. (FU 17530 flg.) Det ble etter hvert også gitt tabellariske oppsett. Den første skal ha vært en presentasjon til SG-møte 20. mars 2015. (FU 21486 flg.) IBM fortsatte med widget-rapportering i ulike former frem til hevingstidspunktet.

IBM begynte med «DCUT Burndown»-rapporteringen fra desember 2014. Den første skal ha vært til prosjektledermøte 3. desember 2014. (FU 17772 på 17776) Det ble tatt inn fremstillinger av DCUT Burndown i statusrapportene til prosjektledermøtene. Det ble også tatt inn slike fremstillinger i månedsrapportene fra og med rapporten for desember 2014. De opphørte som fast innslag fra og med månedsrapporten for april 2015. Dette er forklart med at IBM byttet prosjektleder fra Terje Harangen til Nicolai Rygh på denne tiden. Det ble imidlertid gitt fremstillinger av DCUT Burndown i andre dokumenter. Det ble for eksempel tatt inn en «DCUT Burndown»-rapport i den felles statusrapporten som Rygh og SVVs delprosjektleder for prosjektet Leveranse, Anne-Marie Ytrehus, ga til KG-møte 12. mai 2015. (FU 23729 på 23734) Både «widget unit»- og «DCUT Burndown»-rapporteringen bygde på IBMs DCUT-rapporter. Det kan da spørres, slik staten har gjort, hvorfor ikke IBM like gjerne EV-rapporterte tallene fra DCUT-rapportene. For lagmannsretten er det sentralt i denne sammenhengen at IBMs EV-rapportering ikke skjulte antesipert vesentlig forsinkelse.

Misligholdet var ikke til hinder for at IBM kunne oppfylt resultatforpliktelsen i tide. At det ikke forelå antesipert vesentlig forsinkelse, kommer lagmannsretten som nevnt tilbake til i punkt 4.

Som IBMs lederrepresentant i SG-møtet, Geir Haugen, var inne på i SG-møtet 9. mars 2015, bidro også testrapportene til å gi et bilde av den reelle fremdriften i prosjektet. Etter lagmannsrettens syn fikk SVV alt i alt et godt bilde av reell fremdrift. Endelig får det betydning at det er tale om mislighold av en biforpliktelse i et svært omfattende prosjekt som IBM hadde kommet langt med og nedlagt store ressurser i per hevingstidspunktet. IBM hadde overskredet målpristaket på dette tidspunktet. Lagmannsretten kommer tilbake til dette i punkt 5 nedenfor.

3.3.4 Verktøy, herunder konfigurasjonsstyring og kravsporing Etter Bilag C punkt 2.3 skal leverandøren «opplyse om og dokumentere hvilke verktøy de velger å benytte» samt «inkludere en vurdering av om valgene gir føringer for samarbeidet mellom Kunden og Leverandøren». Det står også at kunden normalt benytter HP-verktøy, «men er åpen for å tilpasse seg verktøy som Leverandøren anbefaler». (FU 9105 på 9112) I Bilag C punkt 2.3.1 svarte IBM at leverandøren vil benytte verktøypakken Collaborative Lifecycle Management (CLM) som består av følgende «fire produkter innenfor IBM sin Rational portefølje»: Rational Requirement Composer (RRC), Rational Team Concert (RTC), Rational Quality Manager (RQM) og Design Manager (DM). (FU 9112) Det er RRC, RTC og RQM som er av interesse i fortsettelsen. I korthet er RRC verktøy for kravsporing, RTC verktøy for feilhåndtering og RQM verktøy for testing. I Bilag C punkt 2.3.1 svarte IBM også at CLM håndterer fem elementer som leverandøren «har identifisert» som «avgjørende for utvikling av nye løsninger».

De fem elementene er «verktøystøtte for planlegging på tvers av prosjektet, sporbarhet, kontekstbasert samhandling, forutsigbarhet og understøttelse av kontinuerlig forbedring». (FU 9112 og 9113) I Bilag C punkt 2.3.1.2 er sporbarhet forklart på følgende måte: Sporbarhet handler om å kunne koble sammen elementer som for eksempel krav, kodeartefakter, oppgaver og testcaser slik at man alltid har kontroll på hvilke gap som finnes i prosjektet. I Grindgut benytter prosjektmedarbeiderne CLM som en sømløs integrert plattform som støtter sporbarhet mellom disse elementene. (FU 9114) SVV satte 4. juli 2014 som restanse R7 ved IBMs løsningsbeskrivelse at «Implementering av design- og utviklingsmodell» var «mangelfullt beskrevet». SVV beskrev restansen på følgende måte: Det mangler beskrivelse av hvordan leverandørens designmetodikk skal implementeres og benyttes i konstruksjonsfasen og hvordan dette understøttes med valgt verktøy. IBM beskriver følgende i kontrakten PS2000-Bilag C kap. 2.3.1 «Leverandøren har identifisert fem elementer som viser seg å være avgjørende for utvikling av nye løsninger.

Dette er verktøystøtte for planlegging på tvers av prosjektet, sporbarhet, kontekstbasert samhandling, forutsigbarhet og understøttelse av kontinuerlig forbedring. Ved gjennomføring av Grindgut danner disse fem elementene grunnlaget for valg og utnyttelse av verktøy.» Vi kan ikke se at disse elementene er dokumentert og hensyntatt i løsningsbeskrivelsen og vi oppfatter det derfor slik at verdien og sikkerheten for kunden ved å benytte verktøykasse er sterkt redusert. [...] SVV satte følgende forutsetning for godkjenning av HMP1: IBM skal innen oppstart av iterasjon 1 beskrive hvordan designmetodikken skal implementeres og benyttes. IBM skal videre beskrive hvilke krav som stilles til kunden [...] knyttet til utformingen og til verifikasjonen av detaljert design. (FU 14223 på 14230) IBM aksepterte alle SVVs restanser, inkludert restanse R7. Staten har gjort gjeldende at IBM skulle tatt kravsporingsverktøyet RRC i bruk fra begynnelsen av løsningsbeskrivelsesfasen, og at IBMs valg om å ikke gjøre dette, ga selskapet svært store problemer ved

gjennomføringen av kontrakten. IBM har gjort gjeldende at det var enighet om å bruke et annet system enn RRC. Slik lagmannsretten ser det, viser A-2s rapport om kravsporing 24. februar 2015 at RRC ble tatt i bruk om lag et halvt år ute i konstruksjonsfasen. Rapporten bygde blant annet på intervjuer med prosjektledelsen, tre strømledere, testleder og arkitekt. (FU 20627 på 20632) Det går frem at «svært lite informasjon var lagt inn i RRC på intervjutidspunktene». (FU 20634) Det går også frem: Bruk av Rational er nedfelt i kontrakten, men innføringen har skjedd langt senere enn ønskelig. IBMs lokale team har ingen tidligere erfaring fra bruk av Rational. (FU 20636) Lagmannsretten legger til grunn at det skapte problemer for gjennomføringen av kontrakten at RRC ble tatt sent i bruk. A-2 skrev i rapporten 24. februar 2015: Mangelen på bruk av et profesjonelt verktøy gjør at arbeidet med kravsporing er ressurskrevende og med en klar risiko for at feil og mangler oppstår. Det er nødvendig, men meget krevende å ta i bruk et slikt verktøy (Rational) så sent i prosjektgjennomføringen.

(FU 20635) Etter lagmannsrettens syn, ser det imidlertid ut til å ha vært enighet helt frem til slutten av november 2014 om at kravsporing ikke skulle skje i RRC. I IBMs leveranseliste 21. juni 2014, inngår «System Requirement Specification» (SRS)/«System Krav Spesifikasjon» som ARC001. (FU 13961) Kravene til løsningen ble registrert i et SRS-dokument i Word. Det går frem av historikken til SRS-dokumentet at det hadde vært gjenstand for kontinuerlig bearbeidelse fra det ble opprettet av IBMs arkitekt, Henrik Strömbäck, 13. desember 2013, og at det ble godkjent 4. juli 2014. (FU 14347 på 14348) I A-2 rapporten om kravsporing 24. februar 2015 heter det om SRS-dokumentet: Alle kontraktens krav er beskrevet og kommentert i SRS-dokumentet, riktignok med stor grad av henvisning til andre dokumenter, uten å beskrive nærmere hvor i dokumentet kravene blir ivaretatt. Sporingen av krav fra kontrakten til SRS er etter vårt syn utført på en tilfredsstillende måte.

(FU 20627 på 20641) Det går frem av en e-post som SVVs innleide prosjektstøtte, Nina Jørgensen, sendte til IBMs leder av prosjektkontoret, Nicolai Rygh m.fl. 26. juni 2014 at det var enighet om at både SVV og IBM skulle bruke testverktøyet RQM. (FU 14039) RRC er ikke nevnt. I PRO006 Arbeidsprosesser, versjon 0.95 med kommentarene etter HMP1 innarbeidet, datert 5. september 2014, står det om verktøy i konstruksjonsfasen: Kravene fra SRS dokumentet vil bli lagt inn i Rational Quality Manager (RQM). Strukturen fra SRS vil bli ivaretatt der. Kravene vil bli knyttet til testcaser. RQM vil benytest (sic) av både Leverandør og Kunde. Det vil bli opprettet en felles instans for RQM tilgjengelig for Kunden (lisenser knyttet til dette blir behandlet i egen endringsordre). (FU 10, FU 62 på 63, FU 13961 og TU2 1224 på 1251) Kravene skulle med andre ord knyttes og spores til test casene i RQM som skulle brukes av både SVV og IBM. RRC er heller ikke nevnt her. Det går ikke uttrykkelig frem av de begivenhetsnære bevisene at SRS, og etter hvert RQM, skulle brukes i stedet for RRC.

De begivenhetsnære bevisene viser imidlertid at SVV heller ikke var opptatt av RRC så sent som i slutten av november 2014. Da IBM 7. november 2014 inviterte til kurset «RRC og RQM for Grindgut», svarte SVVs testleder, Lars-Olav Engseth, 10. november 2014 at det pågikk «en intern diskusjon i SVV for lettkurset og eventuelt vente til RQM er klar i endelig instans lokalisert, tilgjengelig og med riktige data». (FU 17002) Engseths svar dreide seg med andre ord bare om RQM. Også e-posten som SVVs delprosjektleder for delprosjektet Leveranse, Anne-Marie Ytrehus, skrev til IBMs testkoordinator lokalt, Elisa Iglesias, m.fl. 25. november 2015, viser at SVV frem til da, bare hadde sett for seg bruk av testverktøyet RQM. Ytrehus innledet e-posten slik:

Vi konstaterer at det som startet som et spørsmål om testverktøy nå har utviklet seg til spørsmål om en portefølje av verktøy CLM (=RRS, RTC, RQM), som skal dekke alle aspekter av prosjektet, – fra begynnelse til slutt. Anne-Marie Ytrehus avsluttet med følgende meddelelse: SVV har kommet frem til at det innebærer for stor risiko å skulle innføre et helt nytt, komplekst og ukjent verktøy for testing på dette stadiet av prosjektet. SVV og IBM har dog behov for å samarbeide i forbindelse med test og SVV må få innsyn i test case, få rapporter, osv. Dette betyr av vi må starte med blanke ark og beskrive hvordan samhandlingen skal skje uten felles testverktøy, ref også mine spørsmål tidligere i dag. (FU 17466) Lagmannsretten forstår e-posten slik at Anne-Marie Ytrehus så på verktøypakken CLM med ikke bare RQM, men også RRC (feilskrevet RRS) og RTC, som en ny utvikling, jf. formuleringen om at «det som startet som et spørsmål om testverktøy [...] har utviklet seg til spørsmål om en portefølje av verktøy CLM (=RRS, RTC og RQM)».

At Ytrehus bare meddelte at SVV ikke ville ta i bruk RQM, kan tale for at hun ikke så RRC og RTC som aktuelle å svare ut. Ytrehus har ikke forklart seg om verktøy i Grindgut. Det ser imidlertid ikke ut til å være omtvistet at SVV aldri tok i bruk noen av verktøyene i CLM. Det går frem av IBMs interne, ukentlige statusrapport 28. november 2014 at IBM la til grunn at SVV hadde konkludert med «not to buy RQM». (FU 17613 på 17619) Så langt ser SVV og IBM ut til å ha vært enige om at kravsporing skulle skje i testverktøyet RQM. Samtidig ser SVV ut til å ha besluttet å ikke ta i bruk RQM. Det skjedde en endring i PRO006 Arbeidsprosesser, versjon 2.8, datert 18. desember 2014, dagen før KP1 ble flyttet til Finansavtalen. I versjon 2.8 står det: Kravene fra SRS dokumentet vil bli lagt inn i Rational Requirements Composer (RRC). Strukturen fra SRS vil bli ivaretatt der. Kravene vil bli knyttet til testcaser Verktøyet benyttes til å forbedre kvaliteten, tid og smidighet av planlegging, design og levering på tvers av strømmene. Hele Collaborative Lifecycle Management (CLM) pakka vil benyttes av både Leverandør og Kunde.

Det vil bli opprettet en felles instans for Rational Quality Manager (RQM) tilgjengelig for Kunden (lisenser knyttet til dette blir behandlet i egen endringsordre). (FU 62 på 97) SRS-dokumentet skulle med andre ord ikke lenger legges inn i RQM, men i RRC. Videre skulle både IBM og SVV bruke hele verktøypakken CLM, inkludert RQM. Det har vært sparsomt med bevisførsel om bakgrunnen for endringene som kom med PRO006 Arbeidsprosesser, versjon 2.8. IBMs sjefsarkitekt, Svein Rimestad, har forklart at det var mye «frem og tilbake» rundt RRC. Rimestad satte dette i sammenheng med at det hadde skjedd en utskiftning på prosjektledernivå. Både SVVs Anne-Marie Ytrehus og IBMs Terje Harangen hadde kommet inn som nye prosjektledere fra begynnelsen av konstruksjonsfasen. Ifølge Rimestad fikk IBM etter hvert kritikk for sin kravstyring. Lagmannsretten ser det imidlertid som det sentrale her at IBM ikke kan anses for å ha misligholdt kontrakten ved å ta kravsporingsverktøyet RRC sent i bruk når det var enighet mellom SVV og IBM helt frem til desember 2014 om at kravsporingen skulle skje på annen måte.

At RRC ble tatt sent i bruk, kan således ikke begrunne SVVs heving. Staten har også gjort gjeldende at IBM aldri tok i bruk verktøyene på en ensartet måte på tvers av land og strømmer. IBM ser ikke ut til å ha bestridt at selskapet var forpliktet til å ta i bruk verktøyene på en slik måte. Bilag C punkt 2.3.1 taler da også om «verkstøystøtte for planlegging på tvers av prosjektet». Etter PRO006 Arbeidsprosesser, versjon 2.8, skulle RRC «benyttes til å forbedre kvaliteten, tid og smidighet av planlegging, design og levering på tvers av strømmene». IBM har i stedet gjort gjeldende at det var SVV som brøt forpliktelsen til bruk av felles verktøy og forsinket prosjektet. Lagmannsretten legger til grunn at RRC og RQM bare ville hevet kvaliteten på kravsporingen ved ensartet bruk på tvers av strømmene. Lagmannsretten legger også til grunn at SVVs og IBMs sene avklaring om verktøybruk,

ga grunnlag for usikkerhet for om RRC og RQM ville gi effektivitetsgevinst til og med iterasjon 3, og at SVVs beslutning om ikke å ta CLM i bruk, svekket effekten av å ta RRC og RQM i bruk. A-2 skrev om dette i rapporten 24. februar 2015:

• Innlegging av informasjon i RRC/RQM vil trolig isolert sett bidra til å heve kvaliteten på kravsporingen (pga bedre total oversikt). Dette forutsetter ensartet bruk av Rational på tvers av strømmene.
• Det er utfordringer knyttet til kvaliteten på konfigurasjonsstyringen av dokumenter som ligger utenfor og innenfor systemet i forbindelse med overgangen fra Word til RRC.
• Det er svært usikkert om det kan forventes effektivitetsgevinst fra bruk av Rational i konstruksjonsfasen: – I iterasjon 2 vil RRC ikke gi noen effekt, mens RQM benyttes for IBMs test. – I løpet av februar er planen at all informasjon med linker til krav blir lagt inn i RRC/RQM. Grunnet omfang og kompleksitet vil prosjektet trolig få liten gevinst av dette i gjennomføringen av iterasjon 3.
• Bruk av Rational vil kunne bidra positivt under integrasjonstestingen (SIT), samt for resterende gjennomføring av prosjektet og under forvaltning.
• SVV vil trolig bruke HPQC (test administrasjon) og Jira (defect håndtering). Jira har en RQM Connector mens integrasjon med HPQC ikke vil bli benyttet. Dette er en bedre løsning enn eksport til Word, men vil ikke ha samme effekt som hvis begge partene hadde benyttet et felles verktøy. (FU 20627 på 20636) A-2 anbefalte at Rational ble tatt «i bruk av samtlige strømmer fra en definert dato for å sikre tilfredsstillende konfigurasjonsstyring og et felles informasjonsgrunnlag for IBM og SVV», og at det ble etablert «en plan for [å] sikre en mest mulig ensartet bruk av Rational i de forskjellige funksjonelle strømmene». (FU 20637) Etter det lagmannsretten kan se, hadde ikke A-2 lenger bemerkninger til bruken av RRC i juni 2015. A-2s observasjoner og vurderinger om verktøy i rapporten om KP2 5. juni 2015, gjaldt bare testverktøy. (FU 24498 på 24509 og 24510) Lagmannsretten legger derfor til grunn at det da ikke lenger var noe å utsette på IBMs bruk av RRC.

A-2s observasjon om testverkøy i rapporten 5. juni 2015 var:

Partene (GD Kina, GD India, IBM lokalt, SVV) benytter alle ulike IT-verktøy for planlegging, gjennomføring og oppfølging av testingen (fra test case t.o.m. verifisering av krav). SVV er hittil i meget liten grad gitt mulighet for å se testcasene og kjenne testplanen på forhånd (gjelder alle leveranser til nå). (FU 24509) A-2s vurdering om testverktøy var:

Leveranseprosjektet er meget komplekst med mange involverte parter og kommunikasjonslinjer. Både språk (i kommunikasjon og dokumentasjon) og sikring av felles forståelse i og mellom strømmene er en synlig utfordring i praksis. Dette forverres av at IBM benytter ulike verktøy og arbeidsprinsipper i løsningsutarbeidelse, oppfølging og kommunikasjon i strømmene. Som et minimum bør alle strømmene benytte Rational på lik måte for planlegging, gjennomføring og dokumentasjon av testene fremover (ref. anbefalt tiltak i kravsporingsrapporten). Dette vil føre til en bedre samhandling når mange tusen tester skal gjennomføres. (FU 24510) Lagmannsretten legger på denne bakgrunn til grunn at IBM lokalt og GDene brukte RQM på ulik måte i begynnelsen av juni 2015. Dette var ikke i tråd med Bilag C punkt 2.3.1 og PRO006 Arbeidsprosesser, versjon 2.8.

Lagmannsretten mener imidlertid at dette er et forhold som IBM etter omstendighetene ikke kan lastes for. Lagmannsretten ser dette forholdet i sammenheng med SVV ikke tok i bruk CLM, inkludert RQM. At SVV ikke tok i bruk RQM, var ikke i tråd med PRO006 Arbeidsprosesser. PRO006, versjon 0.95 (2.2), forutsatte at RQM skulle brukes av både leverandør og kunde. At SVV ikke tok i bruk noen av verktøyene i CLM, var ikke i tråd med PRO006, versjon 2.8, som forutsatte at «hele» CLM-pakken skulle brukes av både leverandør og kunde, og at det skulle opprettes «en felles instans» for RQM.

Etter lagmannsrettens vurdering førte dette mest sannsynlig til at IBM fikk mindre tid og ressurser til å sørge for at land og strømmer brukte testverktøyet på en ensartet måte. IBM skulle bruke CLM, inkludert RQM. Som Anne-Marie Ytrehus skrev 25. november 2014, innebar SVVs beslutning om verktøy at kontraktspartene måtte «starte med blanke ark og beskrive hvordan samhandlingen» skulle «skje uten felles testverktøy». (FU 17466) Siden SVV ikke tok i bruk noen av verktøyene i CLM i det hele tatt, måtte IBM således arbeide med å finne frem til en annen samhandlingsmåte og samhandle med SVV om tester utenfor CLM; IBM måtte forholde seg til det som er omtalt som et «dobbelt bokholderi». Det ser ikke ut til å være omtvistet at kontraktens milepæler var svært ambisiøst satt. Nye arbeidsoppgaver innebar da nødvendigvis mindre tid til andre oppgaver. At IBM lokalt og GDene brukte CLM, inkludert RQM, på ulik måte, kan da ikke begrunne SVVs heving.

3.3.5 Bemanning og organisering Som nevnt har leverandøren både ansvaret for å planlegge, organisere og lede arbeidet slik at det blir gjennomført i tråd med kontraktsforpliktelsene og det overordnede lederansvaret for arbeidet i alle kontraktfasene, jf. Bilag B punkt 2.5.3 og 2.5.5. (FU 9069 på 9075 og 9077) Videre følger det av Generelle kontraktsbestemmelser punkt 1.2 tredje avsnitt at leverandøren «plikter å allokere relevant og tilstrekkelig kompetanse». (FU 8458 på 8462) Kontrakten stiller ingen krav til formell kompetanse og bestemt erfaring. Slik lagmannsretten ser det, sitter IBM da igjen med en restkompetanse til å organisere og bemanne prosjektet slik som selskapet finner det hensiktsmessig så lenge IBM oppfyller hovedforpliktelsen, resultatforpliktelsen, i tide. Eventuelle konsekvenser av organiseringen og bemanningen for kvalitet, fremdrift og kostnad, vil være ivaretatt gjennom SVVs misligholdsbeføyelser ved vesentlige mangler ved resultatforpliktelsen, vesentlig inntrådt forsinkelse og vesentlig antesipert forsinkelse, samt gjennom målpristaket.

Staten har gjort gjeldende at IBM har misligholdt kontrakten ved ikke å bemanne prosjektet med relevant og tilstrekkelig kompetanse. IBM har bestridt dette. Det er ikke omtvistet at forholdet knyttet til bemanning, ligger utenfor rammen av hevingsvarselet. Staten har gjort gjeldende at dette forholdet likevel kan påberopes fordi det ikke var synlig for SVV på hevingstidspunktet. IBM har også bestridt dette. Lagmannsretten ser det ikke som nødvendig å ta stilling til om forhold som ikke var synlig på hevingstidspunktet, kan påberopes fordi lagmannsretten uansett mener at bemanningen ikke utgjorde mislighold av kontrakten. Som nevnt i punkt 2 foran, anbefalte IBMs interne kvalitetssikrere i tilbuds- og løsningsbeskrivelsesfasen å rekruttere en prosjektleder med omfattende GD-erfaring fra utviklingsprosjekter for minst fire til seks måneder av oppstartsfasen, styrke det lokale teamet med blant annet flere Subject Matter Experts (SMEs) for CRM samt flytte utviklingen i SAP-strømmen fra GD Kina til GD India.

Staten har holdt frem at IBM dels ikke fulgte disse anbefalingene og dels fulgte dem opp for sent, enda GDerfaring, SugarCRM-kompetanse og SAP-kompetanse viste seg som kritisk for prosjektet utover i konstruksjonsfasen. Lagmannsretten er et stykke på vei enig i dette. Verken prosjektlederen som ble satt inn i løsningsbeskrivelsesfasen, Øyvind Myhren, eller prosjektlederen som ble satt inn i konstruksjonsfasen, Terje Harangen, hadde omfattende erfaring med å jobbe med GD fra før. Harangen var ikke «complex certified». Myhren og Harangen var likevel ikke uten erfaring med å jobbe med GD. Lederen som ble satt inn lokalt for CRM-strømmen, Tonje Offenberg Bye, hadde ikke arbeidet med SugarCRM før. Det ble imidlertid satt inn tiltak for å kompensere for Byes manglende erfaring med denne applikasjonen. Tonje Offenberg Bye har forklart at hun først brukte Sugar Labs for å forstå løsningen, og at hun fra tidlig i januar 2014 brukte DRI Nordics Joakim Norlinder og Emil Kilhage jevnlig for det tekniske. Norlinder og Kilhage var eksperter på Sugar i Norden. De var «trusted partners» og kunne til og med endre kildekoden.

Samtidig var det behov for flere CRM-ressurser lokalt, særlig CRM SMEs, som kunne bistå Bye.

Tonje Offenberg Bye har forklart at hun fikk inn Claus Bergh som CRM SME i september 2014. Bergh støttet Bye på brukerhistorier om kundebehandling. Hun fikk videre inn to nyutdannede («graduates»), Ane Heimly Jenssen og Tri Cao Vu, i oktober 2014. Jenssen og Vu arbeidet med brukerhistorier («use cases»). Bye har også forklart at hun fikk Lukas Ruppen inn på brikkelogistikk (OBU/CRM SME). Dette ser imidlertid ikke ut til å ha vært tilstrekkelig. Det går frem av IBMs interne ukentlige statusrapport 12. desember 2014 at det kom inn en OBU/CRM SME fra 28. november 2014, som etter alt å dømme var Ruppen, men at det fortsatt var behov for CRM SME lokalt «ASAP». (FU 18094 på 18107 og 18119) Det går frem av IBMs interne «Development Status Report» 27. januar og 2. februar 2015 at ytterligere CRM SMEs ble ansett som kritisk og at kandidater var under evaluering. (FU 19779 på 19780 og FU 19891 på 19892) Det går frem av statusrapporten til prosjektledermøte 25. februar 2015 at IBM hadde gjort noen interne omrokkeringer for å avhjelpe situasjonen. Her sto det: Additional CRM SME still critical. Internal shifts of resources to mitigate.

(FU 20679 på 20682) I Project Management Review (PMR) 5. mars 2015 sto det: CRM Sugar seems to be one of the most challenging work stream, mostly due to lack of key competence from start. Despite the fact that the team have got some assistance from external Sugar SME’s. Det ble sett som «urgent» å sette på en «senior Sugar resource (DRI), full time, on-site in Oslo». (FU 20914 på 20923) I «Development Status Report» for strømmene CRM, SSP, REP, MIG, INT, SEC og RSGW 9. mars 2015 går det frem at man vurderte å avhjelpe den høye arbeidsbelastningen for CRM SME med støtte fra Geo team og DRI. (FU 21073 på 21074) Det går frem av tilsvarende rapport 17. mars 2015 at «DRI support being set up». (FU 21359 på 21360) Timeoversikter viser at bruken av DRI tok seg opp fra februar 2015. (TU2 525 og TU2 603) Det er ikke rapportert om mangel på CRM SME etter mars 2015. Bemanningen i GD India ble gradvis trappet opp fra seks ressurser per september 2014 til 17 fra 19. desember 2014. Ti av de 17 hadde ingen erfaring med SugarCRM fra før. (FU 18122 på18154 og TU 972 flg.) De resterende syv hadde bare begrenset erfaring.

Det ble imidlertid satt inn tiltak for å kompensere for den manglende erfaringen med SugarCRM også i India. I Project Management Review (PMR) 13. februar 2015 sto det: Staffing with «right» skills has always been a challenge. In the absence of availability of SugarCRM skills, resources are trained and deployed. Not having hands-on and SugarCRM experience is a risk as it may impact productivity. (FU 20301 på 20311 (FU 20303 og 20306)) Det går også frem: Most of the open positions are closed now but staffing «right» skills and experienced people has always been a challenge. (FU 20310) Bye har forklart at reviews som dette gikk til prosjektlederne og ikke til henne. Det Kilhage formidlet til henne, var at GD India virket kompetente på Sugar etter opplæringen. Slik lagmannsretten ser det, baserer SugarCRM seg på et kjent kodespråk. Opplæring i denne applikasjonen trenger derfor ikke å ta lang tid. Som lagmannsretten kommer tilbake til i punkt 4.4.8.6 og 4.5.2.4, taler utviklingen i feilraten fra januar til februar 2015 for at kvaliteten på koden som ble skrevet, var tilfredsstillende.

GD India rapporterte likevel lav produktivitet hele våren 2015. Det går frem av rapport fra GD India 19. juni 2015 at IBM planla å bytte ut «low performing resources» med eksterne konsulenter fra begynnelsen av juni 2015. (FU 25043 på 25047) SAP-utviklingen ble aldri flyttet fra GD Kina til GD India enda denne strømmen også rapporterte om lav produktivitet. Det ble satt inn annet tiltak, men svært sent i prosjektet. Noe av GD Kinas arbeid ble flyttet til det lokale teamet i Norge, men først i begynnelsen av juni 2015. Det lokale SAP-teamet hadde heller ingen

ressurser på Advanced Business Application Programming (ABAP), det vil si SAP-programmerere, før i februar 2015. Oppsummert ser det for lagmannsretten ut til at IBM hadde vansker med å skaffe «relevant og tilstrekkelig» kompetanse på CRM- og SAP-strømmene til langt ut på våren 2015, og at dette fikk konsekvenser for fremdriften. Når lagmannsretten mener at bemanningen ikke utgjorde mislighold av kontrakten, er det fordi bemanningen ble tilstrekkelig til at IBM, vurdert ut fra situasjonen på hevingstidspunktet, kunne oppfylt resultatforpliktelsen i tide. For øvrig var det ikke lenger CRM- og SAP-strømmen som utgjorde utfordringene i prosjektet på hevingstidspunktet. Lagmannsretten kommer tilbake til dette i punkt 4. Bemanningen kan således ikke begrunne SVVs heving. Staten har også gjort gjeldende at IBM har misligholdt kontrakten ved å organisere prosjektet med en offshoreandel på over 70 prosent og opptil fem leveransesteder. Det er ikke omtvistet at IBMs offshoremodell, går frem av Bilag B. Her står det blant annet at utviklingen «hovedsakelig» skulle skje i lavkostland.

Slik lagmannsretten ser det, var organiseringen da kontraktsmessig. Lagmannsretten mener videre at effektivitetstapet som følge av offshoremodellens lange kommunikasjonslinjer, ikke utgjorde mislighold av kontrakten så lenge IBM kunne oppfylt resultatforpliktelsen i tide ut fra situasjonen på hevingstidspunktet, jf. igjen punkt 4 under. Organiseringen kan således heller ikke begrunne SVVs heving.

3.3.6 Estimeringen i tilbudsfasen og ut av løsningsbeskrivelsesfasen Staten har gjort gjeldende at det var grov svikt ved estimeringen både i tilbudsfasen og ut av løsningsbeskrivelsesfasen. Statens eneste begrunnelse i prosedyren for at estimeringen skal ha utgjort mislighold, var at den førte til at GD India ikke ble bemannet i tide. Svikt i estimeringen skal med andre ord ha ført til at IBM ikke sørget for relevant og tilstrekkelig kompetanse, jf. Generelle kontraktsbestemmelser punkt 1.2 tredje avsnitt. IBM har bestridt dette. Estimatet for SugarCRM som lå til grunn for IBMs endelige tilbud, var 1 947 DCUT-timer. (TU 1115 på 1117) Estimatet økte til 7 018 DCUT-timer i estimeringsrapporten 27. juni 2014 og videre til 12 269 DCUT-timer i estimeringsrapporten 5. september 2014. (FU bilag 1182 og TU2 bilag 36) Økningen i estimatene fra juni til september 2014 tilsa et økt bemanningsbehov i GD India. Lagmannsretten ser ikke at estimeringen i tilbudsfasen kan ha utgjort mislighold av kontrakten. IBM tilbød en pris, og ikke estimater. At estimatene holdt, er IBMs risiko. SVVs interesse er ivaretatt av målprisen.

IBM hadde full anledning til å påta seg et tapsprosjekt, og forpliktet seg ikke til å holde seg innenfor bestemte estimater ved kontraktsinngåelsen. Dessuten skjedde estimeringen i tilbudsfasen nesten to år før oppbemanningen i GD India høsten 2014. Lagmannsretten har vanskelig for å se at estimeringen i tilbudsfasen, kunne få betydning for bemanningen så lang tid etterpå. Uansett om økningen i estimatene skyldtes svikt i estimeringen ut av løsningsbeskrivelsesfasen, ser ikke lagmannsretten at dette kan ha utgjort mislighold av kontrakten. Begrunnelsen for at estimeringen utgjorde mislighold, var bemanningen i GD India. Når dette ikke utgjorde mislighold, jf. punkt 3.3.5 foran, kan ikke estimeringen anses for å ha utgjort mislighold heller. Konsekvensen av eventuell svikt i estimeringen, sen bemanning, gjorde seg som nevnt ikke lenger gjeldende på hevingstidspunket. Staten hadde en tilleggsbegrunnelse for at svikt i estimeringen utgjorde mislighold i innledningsforedraget.

Dette var at SVV ikke ville godkjent IBMs løsningsbeskrivelse 4. juli 2014 hvis IBM hadde oppfylt sin opplysnings- og veiledningsplikt og gitt dekkende informasjon i estimeringsrapporten ut av løsningsbeskrivelsesfasen. Staten viste til at kunden har rett til å avbestille erstatningsfritt hvis endringsomfanget overstiger kontraktsprisen med mer enn syv prosent, jf. Generelle kontraktsbestemmelser punkt 3.3.2 og Bilag D punkt 2.2. (FU 8458 på 8466 og FU 9271 på 9276) Denne begrunnelsen ble ikke gjentatt i prosedyren. Selv om denne begrunnelsen ikke ble fastholdt i prosedyren, bemerker lagmannsretten at SVV hadde signert endringsordrer for mer enn syv prosent av kontraktsprisen før 4. juli 2014. Det går frem av SVVs innstilling 3. juli 2014 at det på dette tidspunktet var signert endringsordrer tilsvarende åtte prosent av kontraktsprisen. (FU

14144 på 14148) Det ble signert endringsordrer tilsvarende 11 prosent av kontraktsprisen i forbindelse med HMP1. SVV og IBM ble også enige om at grensen på 25 prosent for «hoppeplikten» etter Bilag C punkt 6, skulle beregnes «basert på oppdatert Målpris etter HMP1 regulert i EO029». (FU 14243) Lagmannsretten kommer tilbake til denne endringen i punkt 4.4.3.2 nedenfor. Dessuten går det frem av referatet fra SVVs SGmøte 25. juni 2014 at erfaringene fra løsningsbeskrivelsesfasen tilsa «et forventet stort endringsomfang også i fortsettelsen av prosjektet». (FU 13987 på 13989) At SVV 4. juli 2014 godkjente IBMs løsningsbeskrivelse enda grensen på syv prosent var overskredet og oppjusterte grensen for hoppeplikten samtidig som det ble forventet stort endringsomfang også i fortsettelsen, taler slik lagmannsretten ser det, mot at SVV ville avbestilt 4. juli 2014 om vegvesenet hadde hatt kunnskap om innholdet i estimeringsrapporten 5. september 2014. Det er for øvrig ingen vitner som har gitt uttrykk for at SVV ikke ville godkjent IBMs løsningsbeskrivelse, men avbestilt, hvis estimatene fra september 2014 hadde vært kjent i juni 2014.

Estimeringen kan således ikke begrunne SVVs heving.

3.3.7 Helhetlig logisk datamodell Det går ikke frem noe uttrykkelig krav om en helhetlig logisk datamodell av Leveranseavtalen, men bare om en logisk datamodell. Det går frem av Bilag A punkt 3 «Grovt løsningsforslag», punkt 3.1 «Overordnet løsnings-/arkitekturskisse», at Grindgut-løsningen «er basert på IBMs Road User Charging Asset (RUC) som består av et sett med komponenter» og at RUC «innebefatter identifisering, prising og integrasjons- og samhandlingstjenester, kunde- og saksbehandling, brikkelogistikk og web-baserte selvbetjeningsløsninger». (FU 8485 på 8522) De funksjonelle komponentene er implementert gjennom ulike standardprodukter. For eksempel er økonomifunksjonen implementert ved SAP FI-CA og kunde- og saksbehandlingsfunksjonen ved SugarCRM. (FU 8523) Bilag A punkt 3.1 inneholder «Figur 14 Spesifikk komponentmodell» og «Figur 15 Overordnet Datamodell». Den spesifikke komponentmodellen viser de ulike komponentene i løsningen i fargekoder. Den overordnede datamodellen viser relasjonen mellom de mest sentrale entitetene som for eksempel kunde, kundeavtale og brikke, samt relasjonen mellom disse entitetene og komponentene.

Fargekodene i komponentmodellen er videreført i datamodellen. (FU 8526) Slik lagmannsretten ser det, viser figurene 14 og 15 at IBMs løsningskonsept var komponentbasert. Hvis det ikke hadde vært for at det skulle skje tilpasninger i løsningen, kunne figur 15 vært sett som en logisk datamodell. Som lagmannsretten kommer tilbake til i punkt 4.4.5 nedenfor, skulle det skje tilpasninger. Figuren må derfor ses som en konseptuell datamodell. En konseptuell datamodell er mindre detaljert enn en logisk datamodell. Med oppdateringer gjennom prosjektet, kunne den konseptuelle datamodellen endt opp som den logiske datamodellen for løsningen. Leveranselisten i Bilag C punkt 7 forutsetter at det skal leveres en «Data Model» og at den skal leveres i løsningsbeskrivelsesfasen og oppdateres i alle iterasjonene i konstruksjonsfasen. (FU 9105 på 9165) Det går ikke frem av Bilag C hva datamodellen skal inneholde. IBM leverte «ARC005 Logic Data Model» som del av sin løsningsbeskrivelse.

(FU 10 og FU 13450 flg.) I ARC005 versjon 0.94, datert 20. juni 2014, heter det i punkt 1.2 «Beskrivelse»: En logisk data modell er en implementerings-uavhengig datamodell og representerer generelt sett den siste leveransen i det logiske data design arbeidet i et prosjekt. Den reflekterer dynamikken i entitetene i logisk datadesign og optimaliserer entitetene i datamodellen for å sikre at hver entitet er tydelig og unikt representerer et forretningsbegrep. (FU 13458 og (FU 22569 på 22572)) Det heter i punkt 2 «Logisk Datamodell» at den logiske datamodellen «skisserer relasjonene mellom de viktigste dataentitetene». (FU 13460) Slik lagmannsretten ser det, viser ikke punkt 2 en helhetlig logisk datamodell, men en logisk datamodell for hver og en av de fleste komponentene i løsningen. (FU 13462, 13465, 13468, 13469, 13472, 13476 og 13481)

Det går frem av ARC005 versjon 0.94, punkt 2.8 «SAP – Økonomiske entiteter og relasjoner», at standardsystemet for håndtering av økonomifunksjonalitet, SAP FI-CA, «dekker mye mer enn vi skal behandle i Grindgut» og at det derfor ikke ville bli gitt «et fullstendig bilde av datamodellen» for denne komponenten. (FU 13485) Logisk datamodell var ingen restanse ut av løsningsbeskrivelsesfasen. I godkjenningsbrevet 4. juli 2014 skrev imidlertid Stein Ødegaard, som da var SVVs delprosjektleder for delprosjektet Leveranse: Vi vil i tillegg laste opp kommenterte dokumenter og tilbakemeldingsskjemaer på angitt sted i IPWC. Som for restansene, forutsettes det at IBM hensyntar og innarbeider disse kommentarene før oppstart av konstruksjonsfasens iterasjon 1. (FU 14223) IPWC er en forkortelse for samhandlingsverktøyet IBM Program Work Center. Det ble lastet opp et tilbakemeldingsskjema til ARC005 Logisk datamodell (LDM) i IPWC med SVVs arkitekturansvarlige, Mihaly Fekete, som forfatter.

I versjon 0.94, datert 26. juni 2014, sto det i punkt 14: En logisk modell må beskrive informasjonselementer på et funksjonelt nivå, slik det er forståelig for kunden.

• Det må tydelig markeres hvilke attributter som har funksjonell betydning og hvilke har kun teknisk betydning (eller bare utelate de siste fra den logiske modellen)
• Forutsetningen for å godkjenne dette dokumentet er at den funksjonelle forklaringen både på entitet- og attributtnivå utføres og dokumenteres på norsk under Konstruksjonsfase. [...] Tydelig beskrivelse av informasjonselementer er en forutsetning for å verifisere løsningen på funksjonelt nivå og dette gjelder for dokumentet i helhet. Attributtene uansett dokumenteres på norsk i Datasett spesifikasjonen som er høy grad basert på LDM dokumentet.

Det ble også lastet opp et tilbakemeldingsskjema til MIG002, migreringsdatasettspesifikasjon, med Mihaly Fekete som forfatter. I versjon 0.90, datert 3. juni 2014, sto det i punkt 15: [...] Det ble ikke gjennomført en grundig analyse av Logiske data modellen på felt nivå og derfor Kunde må ta et forbehold overfor kvaliteten av entitetene.

Løsningen skulle være:

Vidare detaljering och verifisering av dataelementer görs under detaljerad design i konstruktionsfasen. Kommentarer på enskilda attribut hanteras där. Uppdateringar av Migrerings datasett spesifikasjon görs vid behov.

Mihaly Fekete har forklart at han krevde mer enn bare en norsk oversettelse i tilbakemeldingsskjemaet til ARC005. Han krevde at IBM dokumenterte den funksjonelle forretningsforståelsen. Det ble dessuten poengtert flere ganger at det var viktig for SVV at alle dataelementene, også de økonomirelaterte, ble identifisert og beskrevet i konstruksjonsfasen, og at relasjonen mellom elementene ble beskrevet på en strukturert måte på tvers av komponentene. IBM sa at selskapet skulle utvikle logisk datamodell i konstruksjonsfasen som også omfattet de økonomirelaterte elementene. Han stolte på dette.

Staten har i påstandsgrunnlaget for at SVV ikke har brutt sin medvirkningsplikt, gjort gjeldende at SVV stilte detaljering og verifisering av entitetene i den logiske datamodellen som betingelse for godkjenning av IBMs løsningsbeskrivelse gjennom kommentaren til MIG002, samt at IBM pliktet å utarbeide en helhetlig logisk datamodell som reflekterte økonomienheter i SAP og deres relasjoner mot andre komponenter i løsningen selv om dette ikke ble stilt som betingelse for godkjenning i kommentaren. Videre misligholdt IBM kontrakten fordi det ikke ble utarbeidet en helhetlig logisk datamodell. Dette førte til at migreringsstrømmen ble forsinket og at IBM aldri fikk integrert komponentene i løsningen før SVVs heving.

IBM har gjort gjeldende at SVV godkjente ARC005 til HMP1 siden logisk datamodell ikke ble ført opp som en restanse og at kravet om en helhetlig logisk datamodell ikke kan være brudd på kontrakten, fordi det ble fremsatt først under konstruksjonsfasen.

Lagmannsretten finner ingen holdepunkter i de begivenhetsnære bevisene for at IBM på noe tidspunkt i konstruksjonsfasen forpliktet seg til å føye de ulike komponentenes logiske datamodeller sammen til en helhetlig logisk modell. Slik lagmannsretten ser det, var det heller ikke nødvendig å utarbeide en helhetlig

logisk datamodell med IBMs løsningskonsept så lenge IBM hadde kontroll på integrasjonene mellom komponentene i løsningen. Det IBM skulle utarbeide, var en logisk datamodell gjennom oppdatering av den overordnede datamodellen i Bilag A punkt 3.1 og den logiske datamodellen som ble levert til HMP1 i ARC006. Slik lagmannsretten ser det, manglet disse datamodellene bare en integrasjonsmodell for å kunne betegnes som én logisk datamodell. Den logiske datamodellen skulle oppdateres i alle iterasjonene i konstruksjonsfasen og ferdigstilles til sist, jf. leveranselisten i Bilag C punkt 7 og ARC005 versjon 0.94 punkt 1.2. (FU 9105 på 9165 og FU 13458 (FU 22572)) At den logiske datamodellen til HMP1 ble godkjent på betingelsene som ble stilt i kommentarene i IPWC, innebar etter lagmannsrettens syn ikke mer enn at entitetene måtte detaljeres og verifiseres i konstruksjonsfasen, jf. godkjenningsbrevet 4. juli 2014 og kommentaren til MIG002. (FU 14223) At den logiske datamodellen skulle dekke økonomidata selv om dette ikke ble stilt som betingelse i kommentarene, finner lagmannsretten ikke holdepunkter for i de begivenhetsnære bevisene.

Den logiske datamodellen som ble levert som del av løsningsbeskrivelsen, ARC005 versjon 0.94 punkt 1.2, ble oppdatert i konstruksjonsfasen. IBMs sjefsarkitekt, Svein Rimestad, oversendte 26. november 2014 en oppdatert logisk datamodell (LDM) for CRM-delen. Rimestad avsluttet oversendelsen slik: Full versjon av LDM leveres til slutt i konstruksjonsfasen. 26.11 versjonen utgjør et viktig steg mot den. Full LDM leveranse vil også inneholde modeller for IRIS og SAP satt sammen i et helhetlig worddokument. De underliggende modellene for IRIS og SAP vil i den nærmeste tiden bli oppjustert og publisert på dette området. (FU 17534) SVVs delprosjektleder for delprosjektet Leveranse, Anne-Marie Ytrehus, skrev i e-post til IBMs prosjektleder, Terje Harangen, med kopi til Mihaly Fekete 8. januar 2015 at den logiske datamodellen som SVV hadde fått innsyn i, var «svært mangelfull» fordi den «ikke dekket SAP- og IRIS-data». Ytrehus fortsatte at dette selvsagt måtte «på plass i EN LDM som skal dekke helhetlig løsning».

(FU 19210) Svein Rimestad oversendte 2. mars 2015 en oppdatert logisk datamodell for SAP-delen basert på punkt 2.8 i datamodellen som ble levert til HMP1. (FU 20783) Mihaly Fekete meldte tilbake i e-post 13. mars 2015 at denne oversendelsen bare ble ansett som et utkast. Fekete avsluttet e-posten slik: SVV har flere anledninger [...] poengtert at en Logisk Datamodell skal beskrive informasjonselementer og sammenheng mellom disse fra et helhetlig funksjonelt perspektiv og dette er en forutsetning til at informasjon i den helhetlige løsningen håndteres riktig og henger sammen tvers av komponenter. (FU 21121) SVV hadde på dette tidspunktet innhentet en arkitekturgjennomgang fra Greenbird Integration Technology AS 5. mars 2015. I Greenbirds gjennomgang sto det under punkt 3.1 «Funn»:

• Det er ikke definert en kanonisk datamodell.
• Ingen overordnet logisk datamodell funnet. (FU 20832 på 20844) Det samme går for øvrig frem av Greenbirds rapport 30. april 2015. (FU 23293 på 23306) Svein Rimestad bekreftet overfor Mihaly Fekete 13. mars 2013 at oversendelsen 2. mars 2015 ikke var et endelig utkast, men fortsatte:

Vi finner det ikke naturlig å inkludere SAP sin datamodell i vårt LDM dokument.

Vår logiske datamodell er basert på vår IRIS asset, samt vår bruk av SugarCRM. For IRIS, RSGW og SugarCRM gjør vi flere tilpasninger i prosjektet. Det er derfor naturlig med en UML-basert modell for disse, som så dokumenteres i LDM-dokumentet.

Noen «fullverdig» LDM har aldri vært vår intensjon i dette prosjektet. (FU 21122) UML er forkortelse for Unified Modeling Language.

Svein Rimestad har forklart at han med den siste setningen om at en fullverdig LDM aldri hadde vært IBMs intensjon, bare mente SAP-delen. Lagmannsretten ser denne forklaringen i sammenheng med ARC005 versjon

0.94 punkt 2.8 hvor det står at det ikke ville bli gitt et fullstendig bilde av datamodellen til SAP FI-CA. Rimestad har også forklart at han burde ha svart at den logiske datamodellen var basert på RUC, som eksisterte som datamodell allerede. I og med RUC var en rekke grensesnitt mellom komponentene, identifisert allerede. Mihaly Fekete svarte i e-post 20. mars 2015 at setningen om at en fullverdig LDM aldri hadde vært IBMs intensjon, falt på sin egen urimelighet. Fekete sa seg enig i at det ikke var hensiktsmessig å beskrive datamodellen for SAP i den logiske datamodellen, men at modellen måtte dokumentere informasjon og relasjoner som «mastres» i SAP. (FU 21442 og 21444) Svein Rimestads e-post 13. mars 2015 førte til at mangelfull logisk datamodell ble eskalert til koordineringsgruppen. I KG-møte 17. april 2015 fikk IBM frist til 24. april 2015 for å levere en plan for ferdigstillelse av logisk datamodell. (FU 22624 på 22628) For lagmannsretten ser det ut til at arbeidet med den logiske datamodellen deretter kom over i et mer konstruktivt spor.

I saksfremlegget 16. april 2015 til KG-møte 17. april 2015 skrev SVV at vegvesenets forventning til logisk datamodell var «best beskrevet av IBM selv» – i ARC005 punkt 1.2 «Beskrivelse». (FU 22572) Mihaly Fekete og IBMs prosjektleder, Terje Harangen, har forklart at det ble etablert en felles forståelse for kriteriene for en logisk datamodell. IBM presenterte en «Unified Logical Data Model» for SVV i møte 1. juni 2015. (FU 770) Partene ser ut til å være enige om at datamodellen som ble presentert her, var konseptuell. Det går likevel frem av e-post fra Svein Rimestad til blant andre Mihaly Fekete 2. juni 2015 at denne modellen «was overall accepted well». (FU 24377) Videre går det frem av referatet fra KG-møte 16. juni 2015 at det hadde vært «progresjon» i arbeidet, at det var planlagt logisk datamodell i nytt format for ny gjennomgang før 1. juli 2015 og at saken var nedskalert til prosjektledernivå. (FU 24893 på 24894 og 24895) Svein Rimestad har forklart at dette arbeidet var i ferd med å bli ferdigstilt i begynnelsen av juli 2015. Arbeidet med logisk datamodell var imidlertid ikke ferdigstilt på hevingstidspunktet.

Terje Harangen har forklart at dette skyldtes hevingen. Sett på bakgrunn av at den logiske datamodellen skulle utvikles med utgangspunkt i RUC som eksisterte som datamodell allerede, og sett på bakgrunn av progresjonen i arbeidet med logisk datamodell, ser lagmannsretten ingen grunn til at IBM ikke ville ferdigstilt den logiske datamodellen til sist, slik kontrakten forutsetter, om det ikke hadde vært for SVVs heving. Endelig er det ikke dokumentert at arbeidet med den logiske datamodellen førte til forsinkelser i migreringsstrømmen eller andre utfordringer i prosjektet. For eksempel ga Greenbird ingen utbedringsanbefalinger knyttet til logisk datamodell for at løsningen kunne «gå i produksjon» i rapportene 5. mars 2015 og 30. april 2015. (FU 20832 på 20834 og FU 23293 på 23295) At den logiske datamodellen ikke var ferdigstilt på hevingstidspunktet, kan således heller ikke begrunne SVVs heving.

3.3.8 Innsyn i arkitekturbeslutninger Staten har i innledningsforedraget gjort gjeldende at IBM ikke ga SVV innsyn i arkitekturbeslutninger enda PS2000 er en samspillskontrakt, og at det var derfor SVV måtte innhente arkitekturgjennomgangen fra Greenbird Integration Technology AS, jf. KG-møte 17. mars 2015. Ifølge staten fikk også Greenbird svært begrenset innsikt i arkitekturen. Det er vist til at Greenbird ikke fant en kanonisk datamodell og overordnet logisk datamodell. Staten har fastholdt manglende innsyn i arkitekturbeslutninger som hevingsgrunn i prosedyren, men har ikke utdypet dette. IBM har ikke kommentert dette forholdet i prosedyren. I KG-møtet 17. mars 2015 holdt SVV frem: Som kunde har man krav på innsyn i alle kvalitetsmessige aspekter ved både løsningen og gjennomføring av prosjektet. SVV har valgt å gjennomføre en arkitekturreview og en sikkerhetsreview. Årsaken til at disse er igangsatt er bekymring for det som SVV opplever som manglende forståelse, lavt

engasjement, og manglende respons hos IBM i forhold til IKT-faglige selvfølgeligheter som behov for en logisk datamodell (som grunnlag for konstruksjon), kontroll på begreper og roller, god systemdokumentasjon, helhetlig løsning, konfigurasjons-styring mv. SVV mener at en god Logisk Data Model tidligere i prosjektet ville ha avdekket behovene for de avklaringene som for tiden pågår i CRMområdet mye tidligere. SVV stiller spørsmål ved engasjementet, kompetansen og innsatsen til hhv arkitektur- og infrastruktur-ansvarlig. Arkitekturreview er gjennomført av Greenbird, og resultatet er lagt frem for IBM og SVV i felles møte. Det har kommet frem at manglende dokumentasjon (av arkitektur og løsning) har vært et hinder for Greenbirds arbeid. [...] (FU 21286 på 21289) Slik lagmannsretten leser dette referatet, viste SVV til retten til innsyn som en form for hjemmel for arkitekturgjennomgangen uten å gi direkte uttrykk for at IBM nektet innsyn. Som årsak til arkitekturgjennomgangen, pekte SVV i stedet på mangel på forståelse og engasjement hos IBM for en logisk datamodell tidlig i prosjektet.

Forholdet mangel på innsyn i arkitekturbeslutninger har knapt blitt berørt under vitneforklaringene. IBMs sjefsarkitekt, Svein Rimestad, og SVVs delprosjektleder for delprosjektet Leveranse, Anne-Marie Ytrehus, har rett nok forklart at SVV ba om innsyn flere ganger, men uten å gå nærmere inn på hva det ble bedt om innsyn i og hva som var begrunnelsen for at det ikke ble gitt innsyn. IBMs utviklingsleder for GDene, Sander van der Harst, har forklart at SVV ba om å få se kodede dokumenter som han mente at vegvesenet ikke hadde rett til å se. Ingen har forklart at det var mangel på innsyn i arkitekturbeslutninger som var årsaken til at Greenbird ble engasjert. Greenbird-rapporten gir i seg selv ikke holdepunkter for at Greenbird ble engasjert på grunn av manglende innsyn i arkitekturbeslutninger. Thorsten Heller, som var med på å utarbeide rapportene fra Greenbird 5. mars 2015 og 30. april 2015, og som kunne forklart hva Greenbird fikk innsyn i og hva Greenbird mente med funnene knyttet til kanonisk og logisk datamodell, ble frafalt som vitne.

Som nevnt mener lagmannsretten at det var en logisk datamodell under utarbeidelse og oppdatering i konstruksjonsfasen som skulle ferdigstilles til slutt. At det ikke ble funnet en ferdigstilt logisk datamodell i mars og april 2015, var derfor å forvente. Slik saken er opplyst, mener lagmannsretten at SVV må anses for å ha fått tilstrekkelig innsyn gjennom arkitekturgjennomgangen til Greenbird. Lagmannsretten viser til at Greenbird fikk godt nok innsyn til å si hva som måtte til for at løsningen kunne gå i produksjon. Mangel på innsyn i arkitekturløsningen kan således ikke begrunne SVVs heving.

3.3.9 De øvrige forholdene som kan påberopes og blir påberopt Staten har påberopt IBMs flytting av innhold fra iterasjon 2 til 3 slik at Grindgut ble endret til et fossefallsprosjekt og IBMs nedbemanning i juni/juli 2015, som forhold som kunne begrunne heving. Lagmannsretten ser ikke at disse forholdene kan begrunne heving. Lagmannsretten mener at SVV aksepterte flyttingen av innhold fra iterasjon 2 til iterasjon 3 og at nedbemanningen i juni/juli 2015 var en berettiget reaksjon på SVVs urettmessige underkjennelse av IBMs leveranse til KP2. Lagmannsretten kommer tilbake til dette i punkt 4.4.8.4 nedenfor. Staten har også påberopt at IBM har fremsatt uholdbare endringsanmodninger og at dette kunne begrunne heving. Lagmannsretten er heller ikke enig i dette. Lagmannsretten mener at IBMs endringsanmodninger ikke var uholdbare og kommer tilbake til dette i punkt 4.4. Lagmannsretten ser det etter dette ikke som nødvendig å ta stilling til om noen av forholdene som er påberopt som hevingsgrunn er bortfalt på grunn av manglende reklamasjon.

3.3.10 Konklusjon – Inntrådt vesentlig mislighold

Oppsummert mener lagmannsretten at det av alle forholdene som kan påberopes og blir påberopt som grunnlag for SVVs heving på grunn av inntrådt vesentlig mislighold, bare var IBMs EV-rapportering som utgjorde mislighold av kontrakten, men at dette forholdet ikke kan anses som vesentlig. Misligholdet var knyttet til en biforpliktelse. IBM hadde kommet langt med og nedlagt store ressurser i prosjektet. Det var åpenhet om svakhetene ved EV-rapporteringen, og IBM ga SVV et godt bilde av reell fremdrift på andre måter. Rapporteringen skjulte ikke antesipert mislighold. Lagmannsretten går så over til å begrunne hvorfor det ikke var grunnlag for å heve på grunn av antesipert vesentlig forsinkelse.

4 Var det klart på hevingstidspunktet at det ville inntre vesentlig forsinkelse (antesipert forsinkelse)?

4.1 Innledning – Partenes syn på de rettslige utgangspunktene Partene er uenige om beviskravet for antesipert forsinkelse. Staten har gjort gjeldende at det gjelder et strengt beviskrav, men har vist til rettskilder som taler om at det er nok med «overveiende» sannsynlighet og «skjellig grunn» for å kunne heve begrunnet med antesipert forsinkelse. Staten har holdt frem at en teoretisk mulighet for at IBM ville greid å levere i tide, ikke kan være tilstrekkelig. IBM har gjort gjeldende et strengere beviskrav enn staten. IBM har holdt frem rettskilder som taler om «til visshet grensende sannsynlighet» for antesipert forsinkelse. Partene er også uenige om hva som skal bevises. SVV har gjort gjeldende at det er bevisresultatet, og ikke hvert beviselement som må være klart, mens IBM har gjort gjeldende at det er hvert trinn i utviklingen frem mot levering, som må vurderes. Lagmannsretten behandler beviskravet i punkt 4.1.1 og bevistemaet i punkt 4.1.2 nedenfor.

4.1.1 Beviskravet Det følger av Generelle kontraktsbestemmelser punkt 6.4.2 at «skadelidende part» kan heve «etter bestemmelsene i punktene ovenfor eller ved annet vesentlig mislighold fra den andre parts side». (FU 8458 på 8479) Etter punkt 6.3.2 kan en part heve hvis «det er klart at det vil inntre kontraktsbrudd som vil gi» denne parten «hevingsrett». (FU 8478) Punkt 6.1.1.2 gir kunden hevingsrett «når dagbotperioden har utløpt». (FU 8476) Dagbotperioden utløper 100 kalenderdager etter en dagbotsanksjonert milepæl, jf. punkt 6.1.1.1. (FU 8475) De dagbotsanksjonerte milepælene kan flyttes som en konsekvens av endringer, jf. punkt 3.6. (FU 8471) Overskridelse av en (endret) dagbotsanksjonert milepæl med 100 kalenderdager er med andre ord likestilt med vesentlig mislighold. En part kan heve hvis det er «klart» at den andre parten vil overskride en (endret) dagbotsanksjonert milepæl med mer enn 100 kalenderdager. Spørsmålet blir da hvordan beviskravet i uttrykket «klart» i Generelle kontraktsbestemmelser punkt 6.3.2 må tolkes.

Slik lagmannsretten ser det, tilsier en alminnelig språklig forståelse av uttrykket «klart» at det kreves mer enn alminnelig sannsynlighetsovervekt. I veilederen til PS2000, versjon 3.1, oppdatert 15. november 2010, side 34, heter det under punkt 8.3 med overskriften «Fellesregler om inntruffet og forventet mislighold»: Dersom det er overveiende sannsynlig at en part vil misligholde, for eksempel at kunden ikke har penger til å betale leverandøren, er det ikke riktig at leverandøren skal fortsette å pådra seg kostnader som med rimelig sikkerhet aldri vil bli dekket. Leverandøren har derfor adgang til å heve kontrakten før misligholdet konkret har oppstått, dersom dette kan dokumenteres. Slik lagmannsretten ser det, gir også uttrykket «overveiende sannsynlig» veiledning om at det kreves mer enn alminnelig sannsynlighetsovervekt. Sammen med uttrykkene «rimelig sikkerhet» og «dersom det kan dokumenteres», gis det veiledning om et strengt beviskrav. Det går videre frem at bestemmelsene i PS2000 er «presisert og harmonisert i forhold til andre tilsvarende kontraktstandarder». Veilederen viser som nevnt også

til «alminnelige kontraktsrettslige prinsipper». I mangel av andre rettskilder for tolkningen av beviskravet i uttrykket «klart» i PS2000, gir andre tilsvarende kontraktstandarder og alminnelige kontraktsrettslige prinsipper veiledning. Andre tilvirkningskontraktsstandarder som bruker uttrykket «klart», gir veiledning om et strengt beviskrav. NTK/NF 2015 punkt 26.1 bokstav b, gir selskapet (kunden) hevingsrett hvis det er «klart» at leveringen «vil bli forsinket med mer enn 15% av tidsperioden fra Arbeidets start til Leveringsdato, eller 120 dager». Kaasen skriver i kommentarene til punkt 26.1 i Tilvirkningskontrakter, 1. utgave, side 700: Hva som skal til for at det skal være «klart» at det vil inntreffe en forsinkelse som nevnt, må bedømmes ut fra de vanlige kriterier for antesipert mislighold. Siden det dreier seg om et fremtidig forhold, kan det naturligvis ikke kreves visshet. En simpel overvekt av sannsynlighet er på den annen side ikke tilstrekkelig.

Det må kreves en «inntil visshet grensende sannsynlighet» for at forsinkelsen vil materialisere seg, vurdert på grunnlag av de informasjoner man har om planer, aktuell fremdrift og tilgjengelige ressurser. Etter det lagmannsretten forstår er sitatet «inntil visshet grensende sannsynlighet» hentet fra Almén, Augdahl og Ussing, jf. Hagstrøm m.fl. Obligasjonsrett, 3. utgave, 2021, side 646. NS 8405 punkt 39.1, NS 8406 punkt 29.1 og NS 8407 punkt 46.1, gir en part hevingsrett «dersom det er klart at vesentlig mislighold vil inntre». Kolrud m.fl. skriver i kommentarene til NS 8405, 2004, side 492, at det med «klart» menes «sikkert», og at det er den som påberoper antesipert mislighold som har bevisbyrden for at klarhetskravet er oppfylt. Ved tvist vil domstolen «normalt måtte foreta en bred vurdering» av om dette kravet er oppfylt. Marthiniussen m.fl. skriver i kommentarene til den samme standarden, 2016, side 666, at sannsynlighet ikke er nok; «det må kreves større grad av sikkerhet». Han fremholder at det her er «av betydning at hevning normalt har store økonomiske konsekvenser for den som har misligholdt avtalen». Hagstrøm m.fl.

Obligasjonsrett, 3. utgave, 2021, ser derimot ut til å mene at det bare gjelder et krav om alminnelig sannsynlighetsovervekt («skjellig grunn») etter NS 8405. I et petit-avsnitt på side 647 står det: Dersom det eksempelvis er tale om hevning av en entreprisekontrakt i medhold av NS 8405 pkt. 39.1 på grunn av antesipert mislighold, må bevisvurderingen mye baseres på det som er skjedd i kontraktsforholdet. Fordi hevning alene har virkning for det fremtidige arbeid, vil det avgjørende for hvorvidt hevningsrett foreligger, være om byggherren har skjellig grunn til å frata entreprenøren det gjenstående arbeid. Lagmannsretten legger mindre vekt på denne uttalelsen. Den avviker fra både Kolrud m.fl. og Marthiniussen m.fl., og er bare begrunnet med en fotnote til Sandviks kommentarer til den tilbaketrukne standarden NS 3401. Som lagmannsretten kommer tilbake til, skriver Hagstrøm m.fl. dessuten at det for andre kontrakter enn NS 8405, gjelder et strengt beviskrav for antesipert mislighold.

Under henvisning til blant annet Hagstrøm, uttaler således Hålogaland lagmannsrett i LH-2017-66455 følgende om klarhetskravet i NS 8406 punkt 29.1: Hevingsrett på grunnlag av antesipert mislighold er betinget av meget høy grad av sannsynlighet, basert på den informasjon som er tilgjengelig på hevingstidspunktet, for at vesentlig mislighold vil inntre; «en til visshet grensende sannsynlighet» som formulert i Hagstrøm «Obligasjonsrett» 2. utgave side 612 og Nordtvedt m.fl. «NS 8407 Kommentarutgave» side 680, «sikkert» som formulert av Kolrud m.fl. i «NS 8405 kommentarutgave» side 331. Nordtvedt m.fl. slutter seg i kommentarene til NS 8407, 1. utgave, 2013, side 680 og 681, til Kaasens syn om at «det må foreligge en inntil visshet grensende sannsynlighet for at misligholdet vil inntreffe», og da «vurdert på grunnlag av den informasjon som er tilgjengelig på hevingstidspunktet». Nordtvedt m.fl. fortsetter: Den som hever på grunn av antesipert mislighold, har byrden med å bevise at vilkåret er oppfylt.

Ved en eventuell senere tvistesak må domstolen ta stilling til om det på hevingstidspunktet fremsto som sikkert at et vesentlig mislighold ville inntre. Kontraktsretten ellers gir også veiledning om et strengt beviskrav.

I likhet med PS2000, NTK 15/NF 15, NS 8405, NS 8406 og NS 8407, gir kjøpsloven § 62, håndverkertjenesteloven § 15, avhendingslova § 6-2, bustadoppføringslova § 20 og husleieloven § 2-12, hevingsrett hvis det er «klart»/«klårt» at mislighold vil inntre. Det følger av forarbeidene til både kjøpsloven og avhendingslova at uttrykket «klart»/«klårt» innebærer at «kravet til sannsynlighet er sterkt», jf. Ot.prp.nr.80 (1986–1987) side 113 og Ot.prp.nr.66 (1990–1991) side 126. Forarbeidene til håndverkertjenesteloven «forutsetter en høy grad av sannsynlighet», jf. Ot.prp.

(19881989) side 84. I LH-2015-167184 la lagmannsretten under henvisning til Hagstrøm til grunn at uttrykket innebærer at det må være «helt på det rene at det vil bli mislighold». Det følger av forarbeidene til husleieloven at uttrykket «klart» innebærer et «strengt» krav til sannsynlighet, og at det i prinsippet kreves «en til visshet grensende sannsynlighet», jf. Ot.prp.nr.82 (1997–1998) side 162. Også UN Convention on Contracts for the International Sale of Goods (CISG) artikkel 72, UNIDROIT Principles of International Commercial Contracts (UPICC) artikkel 7.3.3 og Principles of European Contract Law (PECL) artikkel 9:304, gir hevingsrett hvis det er «clear» at mislighold vil inntre. Ifølge Schlectriem og Schwenzers kommentarer til CISG artikkel 72, 4. utgave, side 1030, kreves det «a very high and obvious degree of probability» for antesipert mislighold. Ramberg oppsummerer i Internationella Köplagen (CISG), 2016, «att de förhållanden som berättigar till hävning på grund av förväntade hävningsgrundande avtalsbrott sällan föreligger».

Etter kommentaren til UPICC artikkel 7.3.3 innebærer kravet om at det må være «clear that there will be nonperformance» at «a suspicion, even a well-founded one», ikke vil være tilstrekkelig. Ifølge Lando og Beales kommentarer til PECL artikkel 9:304, 2000, side 417, kreves det «an obvious unwillingness or inability to perform». Også for kontraktstyper som ikke oppstiller et klarhetskrav, gjelder det et strengt beviskrav. I Rt-1987-1205 satte selger frem en ny anførsel for Høyesterett om rett til heving på grunn av antesipert mislighold. Hun gjorde gjeldende at kjøper ikke ville vært i stand til å betale kjøpesummen for en hotelleiendom. Høyesterett uttaler at det «måtte [...] kreves særdeles sterkt bevis for at [kjøper] virkelig var ute av stand til å betale». Etter Rt-1924-1056 og Rt-1924-1199 vil beviskravet være oppfylt hvis debitor gir «et utvetydig tilkjendegivende» for at mislighold vil inntre. I den første 1924-avgjørelsen hadde selger innledet et skriv til kjøper med at «det icke finnes nogon möjlighet» for at han ville greie å levere i tide.

Denne beskjeden om at mislighold ikke var til å unngå, ble ikke ansett som tilbakekalt. I den andre 1924-avgjørelsen hadde kjøperen på forhånd utvetydig gitt til kjenne at han ikke aktet å oppfylle fordi han ikke anså seg forpliktet til det. Hagstrøm m.fl. skriver på side 621 i Obligasjonsrett, 3. utgave, 2021, at retten til å heve på grunn av antesipert mislighold, inntrer når det er «helt på det rene» at det vil bli mislighold, og at «en mer eller mindre godt begrunnet mistanke om at det kan bli mislighold» ikke bør være tilstrekkelig. På side 645 til 646 står det at det etter den tradisjonelle oppfatningen, kreves «en meget høy grad av sannsynlighet», og at beviskravet gjerne er blitt formulert slik at «det måtte foreligge en til visshet grensende sannsynlighet». Det fremholdes samtidig at det strenge beviskravet må ses på bakgrunn av at antesipert mislighold blant annet gir adgang til å kreve erstatning. Haaskjold skriver tilsvarende på side 192 i Obligasjonsrett – en innføring, 2017, at kreditor har rett til å heve hvis det «nærmest er på det rene at mislighold vil inntre».

Han skriver på side 195 at det gjelder «et særlig strengt beviskrav» for heving på grunn av antesipert mislighold, og at «en ofte benyttet formulering er at det må foreligge en «til visshet grensende sannsynlighet»». Han forklarer denne formuleringen med at «det er noe nær sikkert at det vil inntre et vesentlig mislighold». Basert på kontraktens ordlyd og veileder, rettskilder knyttet til andre tilvirkningskontraktsstandarder og lovregler som oppstiller et klarhetskrav for heving på grunn av antesipert mislighold samt alminnelige kontraktsrettslige prinsipper, legger lagmannsretten til grunn at det gjelder et særlig strengt beviskrav for antesipert forsinkelse. Det kreves noe nær visshet for antesipert mislighold eller at det er noe nær sikkert at et slikt mislighold vil inntre. Beviskravet kan oppfylles ved en vurdering av informasjonen om planer, aktuell fremdrift og tilgjengelige ressurser på hevingstidspunktet eller ved «et utvetydig tilkjennegivende» om at det ikke fins noen mulighet for å levere i tide. Lagmannsretten mener at dette tolkningsresultatet har gode grunner for seg.

Slik for eksempel Haaskjold forklarer på side 192, bygger reglene om antesipert mislighold på en avveining av kryssende hensyn. Han skriver: [...] På den ene siden tilsier hensynet til debitor at terskelen for antesipert mislighold bør legges høyt. Debitor skal ikke tape muligheten til å oppfylle sin del av kontrakten på grunn av kreditors mer eller mindre velbegrunnede frykt for mislighold. Debitor skal heller ikke risikere å bli utsatt for sanksjoner uten at det er temmelig klare holdepunkter for at mislighold vil inntre. Hertil kommer at kreditor ikke skal kunne fragå en inngått avtale ved å fremsatte påstander om at debitor ikke vil kunne klare å oppfylle. Også i tilfeller hvor risikoen for mislighold er til stede, forekommer det at debitor allikevel vil kunne evne å prestere kontraktsmessig. Dersom det derimot nærmest er på det rene at mislighold vil inntre, tilsier på den annen side hensynet til kreditor at han ikke skal behøve å vente til misligholdet er et faktum med å gjøre kontraktsbruddet gjeldende.

Hvis et kontraktsbrudd fremstår som noe nært sikkert, vil det ofte være i begge parters interesse at kontrakten heves, og at partene kan innrette seg på annen måte. Reglene om antesipert mislighold har dermed en klar side mot den alminnelige tapsbegrensningsplikten og prinsippet om lojalitet i kontraktsforhold. Marthinussen m.fl. skriver på side 663 at det har vært «antatt at det må tas i betraktning om byggherren kommer i en bedre situasjon ved å heve». Heving i entrepriseforhold innebærer ofte ytterligere forsinkelser for kunden. Lagmannsretten legger etter dette til grunn at det kan være et støtteargument i vurderingen av antesipert vesentlig forsinkelse, om kunden kom i en bedre situasjon ved å heve. For lagmannsretten ser det ikke ut til at SVV gjorde det, selv om det forutsettes at SVV hevet kontrakten med rette slik at staten har krav på erstatning uten at IBM har krav på vederlag, slik staten har gjort gjeldende. Staten bygger sitt erstatningskrav på at SVV har lidt et økonomisk tap på 446 millioner kroner som følge av hevingen. Kravet er bygd på to tapsposter.

Forenklet sagt består den første posten av SVVs prosjektkostnader på 120 millioner kroner. Den andre består av SVVs kostnader ved forlenget leie av CS Norge på 415 millioner kroner, fratrukket sparte driftskostnader ved Grindgut med 116 millioner kroner og tillagt kostnadene til selvbetjeningsløsning for CS Norge med 28 millioner kroner. Erstatningen ville således ikke ha dekket kostnadene ved en alternativ løsning. Kostnadene ved den alternative løsningen er ikke kjent for lagmannsretten. Det er derimot på det rene at det tok over seks år å utvikle den. Til sammenlikning var vederlaget til IBM begrenset av et målpristak. Som lagmannsretten kommer tilbake til i punkt 5 nedenfor, utgjør IBMs krav på vederlag 172 115 094 kroner. Videre, som lagmannsretten kommer tilbake til i punkt 4.6, kunne Grindgut-prosjektet vært klart for ordinær idriftsettelse 3. mai 2016 (HMP2.2). Dette ville vært i god tid før den alternative løsningen var på plass. SVV vurderte det som sannsynlig at en alternativ løsning ville kostet mer og tatt lengre tid enn Grindgutprosjektet, allerede i slutten av løsningsbeskrivelsesfasen.

Dette går frem av presentasjoner til styringsgruppen

19. og 28. mai 2014 og vurderinger internt i SVV av «Alternative scenarier ved terminering av kontrakt med IBM» 17. og 27. juni 2014. (FU 12491 flg., 12755 flg., 13007 flg., 14052 flg. og 14065 flg.) At en alternativ løsning ville tatt lengre tid, var fortsatt vurderingen i tiden før hevingen. I SVVs presentasjon til SG-møte 20. mars 2015 ble videreføring av avtalen med IBM vurdert som «raskeste vei til mål (forutsatt dagens prognoser)». (FU 21476 på 21481) I Vegdirektoratets rapport til Samferdselsdepartementet 7. mai 2015 ble det lagt til grunn at Grindgut-prosjektet «tidligst» kunne avsluttes høsten 2016, og at etablering av en alternativ løsning sannsynligvis ville «ta om lag 3 til 5 år». (FU 23585 på 23586 og 23588) At etablering av en alternativ løsning sannsynligvis ville ta om lag tre til fem år, går også frem av Vegdirektoratets rapport 15. juni 2015. (FU 24867 på 24868) Lagmannsretten går over til å se på bevistemaet.

4.1.2 Bevistemaet SVV har vist til Rt-2005-1353 avsnitt 14 som illustrasjon for at det er bevisresultatet, og ikke hvert beviselement som må være klart, mens IBM har vist til HR-2021-871-U avsnitt 13 flg. og Rt-2004-1063 avsnitt 7 flg. som illustrasjon for at det er hvert trinn i utviklingen frem mot levering, som må vurderes. Etter lagmannsrettens syn har disse tre avgjørelsene fra Høyesterett om det strafferettslige beviskravet, ingen direkte overføringsverdi. Om de skulle ha noen overføringsverdi, må de etter lagmannsrettens syn gi veiledning

om at det er hvert vilkår for heving, i den grad det er flere vilkår, som må være «klart», og ikke hvert trinn i et hendelsesforløp. Avgjørelsene slår fast at det er hvert enkelt straffbarhetsvilkår, og ikke hvert trinn i et hendelsesforløp, som må være bevist utover enhver rimelig tvil, jf. HR-2021-871-U avsnitt 14 med videre henvisning til Rt-2005-1353 avsnitt 14 samt Rt-2004-1063 avsnitt 7 og 9. IBM har i tillegg vist til LH-2017-66455 til støtte for sitt syn. Hålogaland lagmannsrett ser her ut til å ha lagt til grunn at det måtte være klart at planen for hvert trinn, det vil konkret si fremdriften i tunnelarbeidene (inndriften) og etterarbeidene, ville blitt overskredet. Denne trinnvise tilnærmingen er imidlertid ikke begrunnet. Etter kontrakten mellom SVV og IBM var vilkåret for å heve på grunn av antesipert mislighold bare at det på hevingstidspunktet var klart at en endret dagbotsanksjonert milepæl ville blitt overskredet med mer enn 100 dager. Det er da dette som må være klart, og ikke hvert trinn i utviklingen frem mot levering.

Samtidig vil en trinnvis tilnærming gi en god struktur på totalvurderingen av om IBM ville greid å levere i tide. Bevistemaet blir etter dette om det ut fra informasjonen på hevingstidspunktet 27. juli 2015, var noe nær visshet for eller noe nær sikkert at IBM ville overskredet en endret dagbotsanksjonert milepæl med mer enn 100 dager. Etter EO042 skulle HMP2 vært nådd 28. april 2015. (FU 10081 (FU 17742)) Ved HMP2 skulle iterasjon 3, iterasjonstesten og systemintegrasjonstesten (SIT) vært ferdig. HMP2 er ikke dagbotsanksjonert. Den første dagbotsanksjonerte milepælen er HMP2.2. Etter EO042 skulle HMP2.2 vært nådd 4. september 2015. Ved HMP2.2 skulle kundetest og prøvedrift vært ferdig og løsningen godkjent for ordinær idriftsettelse. (TU2 2780 på 2784 og FU 9105 på 9161) IBM hadde begrensede muligheter for å vinne tid i perioden på 129 kalenderdager mellom HMP2 og HMP2.2. Denne perioden kan imidlertid få betydning, for eksempel hvis IBM har rett til fristforlengelse for SVVs ferie. Tillagt 100 kalenderdager, blir hevingsfristen 6. august 2015 med utgangspunkt i HMP2 og 13. desember 2015 med utgangspunkt i HMP2.2.

Hvis IBM får medhold i alle eller noen av endringskravene som har virkning på kontraktens milepæler, og i kravet om fristforlengelse for ferier, utskytes hevingsfristen ytterligere. Lagmannsretten behandler om det er grunnlag for å endre disse milepælene i punkt 4.4 og om det er klart at IBM ikke kunne nådd de endrede milepælene i punkt 4.5 nedenfor. Lagmannsretten behandler imidlertid først statens anførsel om at IBM har gitt en utvetydig tilkjennegivelse for antesipert mislighold i punkt 4.2 og IBMs anførsel om at SVV mente at vegvesenet ikke hadde hevingsrett i punkt 4.3.

4.2 Om IBM har gitt en utvetydig tilkjennegivelse for antesipert mislighold Staten har gjort gjeldende at beviskravet for antesipert mislighold er oppfylt ved to planskisser som IBM presenterte i direktørmøte 8. juni 2015. Ifølge staten innebar de to skissene en utvetydig tilkjennegivelse for at IBM ville komme til å overskride HMP2 med flere hundre dager. Staten har holdt frem at tilkjennegivelsene aldri ble tilbakekalt. Lagmannsretten er ikke enig i dette. Den ene planskissen som IBM presenterte i direktørmøtet 8. juni 2015, viste at HMP2 ville vært nådd i midten av mai 2016 uten EA053 og andre endringsanmodninger. Den andre skissen viste at HMP2 ville vært nådd i november 2016 med EA053 og andre endringsanmodninger. (FU 24640 på 24645 og 24646) Slik lagmannsretten ser det, utgjorde de to planskissene ingen utvetydig tilkjennegivelse i seg selv. Det går ikke frem av planskissene som ble presentert i direktørmøtet 8. juni 2015 at det ikke fantes noen mulighet for å unngå mislighold. Planskissene er dessuten merket med «DRAFT».

Det går heller ikke frem av referatet fra direktørmøtet at det ikke fantes noen mulighet for å unngå mislighold. På agendaen for møtet sto det blant annet at IBM skulle redegjøre for tiltak innenfor minst tre «områder». Det ene området var «gjennomføring, herunder (men ikke begrenset til) realistisk gjennomføringsplan». I referatet heter det bare om dette: IBM gjennomgikk i møtet en overordnet planskisse for det IBM anser for å være kontraktert omfang, og for det omfanget som IBM anser for å være utenfor kontraktens omfang. I henhold til skissen vil en løsning som omfatter alt kontraktert omfang og alle identifiserte endringer kunne ferdigstilles innen juni 2017. Det konstateres i møtet at partene åpenbart ikke har vært enig om en plan, og at uenighet om

omfang er en av hovedårsakene til det. (FU 24637 og 24638) Slik lagmannsretten videre ser det, utgjorde planskissene heller ingen utvetydig tilkjennegivelse i kontekst. SVV hadde 28. april 2015 underkjent KP2. Begrunnelsen var blant annet at IBM ikke hadde levert en realistisk gjennomføringsplan. Planskissene som ble presentert i direktørmøtet 8. juni 2015, kom etter oppfordring fra SVV i brev 27. mai 2015 med overskriften «Kontrollpunkt 2, Hovedmilepæl 2 og IBMs mislighold». I brevet holdt SVV fast ved at underkjenningen av KP2 var rettmessig, at det ikke var satt frem noen endringsanmodninger som hadde innvirkning på kontraktens milepæler og at det forelå vesentlig mislighold, herunder antesipert forsinkelse. SVV mente også at IBM hadde utvist grov uaktsomhet og forsett. SVV ønsket likevel at prosjektet skulle gjennomføres og lykkes, og rundet av brevet slik: SVV inviterer i den forbindelse til et møte hvor IBM konkret bes redegjøre for hvilke tiltak som IBM vil iverksette for å sikre at prosjektet kan bli realisert. Sentrale forhold i denne sammenheng er blant annet kompetanse, løsning og gjennomføring.

Spesielt viktig er tiltak IBM nå må iverksette for å sikre en realistisk og gjennomførbar gjennomføringsplan for prosjektet. [...] (FU 24182 til 24188) Lagmannsretten ser etter dette på planskissene som et forsøk fra IBMs side på å komme SVV i møte etter at vegvesenet hadde underkjent planen til KP2, og alle planer før KP2, som urealistiske. Det går frem av presentasjonen for øvrig at IBM hadde utviklet skissen over fire-fem uker «in the expectation that joint efforts between IBM and SVV would be put into solving the programme fundamentals and commercial issues over the same time period», men at IBM også hadde som intensjon «to deliver its obligations according to the contract». (FU 24643 og 24644) Slik lagmannsretten ser det, måtte det være rom for å presentere skisser som forhandlingsutspill. At det måtte være rom for forhandlingsutspill, må særlig gjelde hvis utspillene bygde på urettmessige krav fra SVV. De aktuelle planskissene bygde på SVVs underkjenning av KP2. Det går frem av presentasjonen at IBM vurderte skissen uten EA053 som det eneste alternativet, fordi SVV bestred endringsanmodningene knyttet til CRM.

(FU 24642) Lagmannsretten mener at det ikke var grunnlag for å underkjenne KP2 og avslå alle endringsanmodninger knyttet til CRM, og kommer tilbake til dette i punkt 4.4. At IBM gjentok presentasjonen med de to planskissene fra 8. juni 2015 i KG-møte 16. juni 2015, endrer ikke lagmannsrettens syn. (FU 24893 og FU 24921 på 24924 og 24925) Etter dette forelå det ingen «utvetydig tilkjennegivelse» å tilbakekalle. Lagmannsretten bemerker likevel at IBM holdt fast på sine tidligere gjennomføringsplaner etter at SVV sendte varsel om heving 22. juni 2015. I brev 29. juni 2015 bestred IBM at det forelå antesipert mislighold. IBM begrunnet dette med at selskapet både hadde krav på fristforlengelse med 300 til 325 dager og at det ville hatt forseringsmuligheter. IBM rundet av brevet med å fastholde at selskapet ville følge «planen som ble levert til SVV før godkjenningen av KP1 (Gjennomføringsplan v.1.2)».

(FU 25244, 25248, 25249 og 25251) I brev 10. juli 2015 viste IBM også til de omstridte endringsanmodningene og fortsatte: Når SVV viser til nye prognosedatoer IBM har meddelt i utkast til fremdriftsplaner tas det ikke høyde for SVVs urettmessige underkjenning av KP2 og forholdene fremhevet i bl.a. EA 108 og EA 113. (Siste offisielle fremdriftsplan var planen levert til KP2, som IBM har vist til i sitt forrige brev). FU 25479 på 25481) Ifølge gjennomføringsplanene som ble levert til både KP1 og KP2, ville kontraktens milepæler vært nådd i tide. Lagmannsretten går over til å se på IBMs anførsel om at SVV egentlig mente at vegvesenet ikke hadde hevingsrett.

4.3 Om SVV i virkeligheten mente at det ikke eksisterte en hevingsrett IBM har gjort gjeldende at SVV ga uttrykk for forventninger internt i juni 2015 som viser at hevingsretten aldri har eksistert.

Lagmannsretten er heller ikke enig i dette. Slik lagmannsretten ser det, er det rett nok naturlig å forstå en del uttalelser internt i SVV i juni 2015 slik at vegvesenet trodde at det hadde en hevingsrett som det kunne miste ved å godkjenne endringsanmodninger og flytte milepælsdatoer. I referatet fra SG-møte 2. juni 2015 heter det: Det ble [...] påpekt viktigheten av å ikke godkjenne noe som gjør at SVV mister rettigheter overfor IBM. (FU 24387 på 24391) I prosjektets saksfremlegg (innstilling) 15. juni 2015 til SVVs styringsgruppe punkt 2.4 med overskriften «Risiko ved videreføring av prosjektet» heter det blant annet: Videreføring med utvidet tidsplan må ansees som en aksept av overskridelse på tid og muligheten til å senere hevde mislighold på tid vil være vesentlig svekket. (FU 24871 på 24874) I punkt 4 med overskriften «Prosjektets vurdering» heter det: Kontraktsmessig er det nå, og ikke vesentlig mye lenger fremover i tid, at SVV har mulighet til å heve Kontrakten og kunne kreve erstatning fra IBM basert på påstand om vesentlig mislighold.

(FU 24876) I SVVs presentasjon til ekstraordinært SG-møte 16. juni 2015 heter det blant annet at «valgmuligheten heving bortfaller dersom den ikke benyttes nå». SVV anbefalte derfor heving. (FU 26654 på 26666) I referatet fra SGmøtet 16. juni 2015 heter det: Det er et begrenset mulighetsvindu i forhold til et eventuelt ønske om å benytte hevingsretten grunnet leverandørens mislighold på tid. Det er derfor et mål å ta en slik beslutning så snart som mulig og innen ca en uke. (FU 24996) I SVVs statusrapport 19. juni 2015 punkt 7.4 med overskriften «R10- Kontraktens rammer brytes» heter det at «videreføring av prosjektet vil kreve vesentlige endringer både ved kontraktuelt å flytte milepælsdatoer og ved å imøtegå IBMs krav om endringer». «Konsekvensen av å bryte kontraktens [...] rammer» ville blant annet være at «hevingsposisjon bortfaller». (FU 25029 på 25041) Slik lagmannsretten også ser det, går det klart frem av sammenhengen at disse uttalelsene ikke dreide seg om reklamasjon eller passivitet. Det var videreføring eller heving som ble drøftet. Planskissene som IBM presenterte 8. juni 2015 hadde ingen plass i drøftelsene.

Uttalelsene taler for IBMs syn på at SVV mente at det ikke forelå noen hevingsrett hvis endringsanmodningene ble tatt i betraktning. Lagmannsretten mener imidlertid at IBM ikke kan bygge noen rett på disse uttalelsene. Uttalelsene ble fremsatt internt. At SVV kunne miste en hevingsrett ved å godkjenne endringsanmodninger, berodde dessuten på en misforståelse. Det avgjørende for SVVs hevingsrett var ikke om endringsanmodningene ble avslått eller ikke, men om de var berettigede eller ikke. Lagmannsretten går over til å se på om IBMs endringsanmodninger var berettigede slik at IBM hadde krav på fristforlengelse og flytting av milepæler.

4.4 Hadde IBM krav på fristforlengelse og flytting av milepæler? 4.4.1 Innledning – Oversikt over gruppene av forhold som kan begrunne fristforlengelse/flytting av milepæler og lagmannsrettens konklusjon De forholdene som IBM har påberopt som grunnlag for fristforlengelse og flytting av milepæler, kan deles inn i tre grupper: (i) forhold som etter praktiseringen av kontrakten ville gitt krav på fristforlengelse, mer konkret SVVs ferier; (ii) forhold som rettmessig var påberopt som endringer til kontrakten og hvor konsekvensen av

endringen var inntrådt ved heving; og (iii) forhold som rettmessig var påberopt som endringer til kontrakten, men hvor konsekvensen ennå ikke var inntrådt ved heving. Lagmannsretten behandler forholdet i gruppe (i) i punkt 4.4.2. Lagmannsretten behandler noen fellesspørsmål for gruppe (ii) i punkt 4.4.3. Forholdene i gruppe (ii) som kan gi IBM krav på fristforlengelse og flytting av milepæler og EA078 i gruppe (iii) blir behandlet i kronologisk rekkefølge i punkt 4.4.4 til 4.4.10. Lagmannsretten mener at disse forholdene ga eller ville gitt IBM krav på fristforlengelse med 250 kalenderdager. Det er bare de tidsmessige konsekvensene av endringsanmodningene som blir behandlet i punkt 4.4. EO064 og EA069 i gruppe (ii) har bare kostnadsmessige konsekvenser og blir derfor ikke behandlet her. Lagmannsretten kommer tilbake til de kostnadsmessige konsekvensene i punkt 5 om vederlag.

4.4.2 Ferie IBM har gjort gjeldende at selskapet har krav på fristforlengelse med 21 kalenderdager for sommerferie 2015, 21 kalenderdager for juleferie 2015 og syv kalenderdager for påskeferie 2016. Staten har gjort gjeldende at kontrakten ikke gir IBM automatisk krav på fristforlengelse for perioder der SVV tar ferie, og at IBM i høyden har krav på fristforlengelse der ferien forsinker arbeid på kritisk linje, jf. Generelle kontraktsbestemmelser punkt 6.3.1. Videre har staten gjort gjeldende at IBM er forpliktet til å prøve å planlegge arbeidet slik at SVVs ferier ikke forsinker arbeid på kritisk linje. Leveranseavtalen er taus om virkningen av alminnelige ferier på planer og milepæler, men allerede under anskaffelsesprosessen stilte SVV krav om at ferie måtte tas inn i IBMs planer. (FU 7052 på 7059) Dette ble konkretisert i EO001, som ble signert 30. januar 2014 og som flyttet datoene på milepælene på grunn av forsinket signering av kontrakten.

(FU 10035) I tillegg til den tiden som var et resultat av forsinket kontraktsinngåelse, ble det lagt inn 21 kalenderdager mellom HMP0 og HMP1 for å hensynta SVVs behov for 21 kalenderdager juleferie i 2013. I EO001 ble det også forutsatt at milepælene skulle revideres på nytt som en del av HMP1 basert på en ny plan som skulle utarbeides i løsningsbekrivelsesfasen, «hvor også ferie hensyntas». Det er uomstridt at det ved fastsettelse av nye milepæler etter HMP1 ble lagt til fire uker for SVVs sommerferie i 2014. Dette står ikke uttrykkelig i EO042, men det går frem av de underliggende planene og er bekreftet i SVVs presentasjon til SG-møte 23. januar 2015. (FU 19695 på 19702) I samme presentasjon går det frem at SVV forventet at IBM i sine planer måtte legge inn tid for sommer-, jul og påskeferie dersom disse lå mellom HMP2 og HMP3. Lagmannsretten har ikke oversikt over om det er lagt inn ferie i IBMs gjennomføringsplaner (PRO001) levert under løsningsbeskrivelsesfasen.

Det går imidlertid frem av SVV-interne dokumenter at SVV la til juleferie 2014 (24 dager) og påskeferie 2015 (en uke) på datoene i IBMs planer da de gjorde egne tidsberegninger og vurderinger i forbindelse med beslutningen om kontrakten skulle videreføres etter HMP1. (TU2 Dok.nr.03 og FU 12491 på 12494) Under konstruksjonsfasen stilte SVV konkrete krav om at IBM la tid for SVVs ferier inn i sine planer. I brev 15. desember 2014 ba SVV IBM om å utarbeide realistiske prognoser for oppnåelse av HMP2 og hele prosjektperioden frem til HMP3, hvor prognosene måtte «hensynta [...] SVVs kontraktsfestede ferieavvikling i juli måned». (FU 18198) Som nevnt i punkt 3.3.2 leverte IBM versjon 4.0 av gjennomføringsplanen til KP2 22. april 2015. I oversendelsen går det frem at planen nå inkluderte IBMs «vurdering av effekten av juliferie som må endringshåndteres». (FU 22991) I referatet fra kontrollpunktmøte nr. 3a 22. april 2015, ble det opplyst at planen hensyntok «ferie i juli (uke 28-30)». (FU 22992) Leveranseavtalen er som nevnt en samhandlingskontrakt, som innebærer at SVVs personale måtte være tilgjengelig for IBM for dialog og avklaringer.

I SVVs ferieperioder ville denne medvirkningsplikten ikke kunne oppfylles, i hvert fall ikke fullt ut, og dette ville kunnet forsinke fremdriften. SVVs rådgiver/kvalitetssikrer, Inger Røst, forklarte at bakgrunnen for at SVV stilte krav om at IBM la inn kalendertid for ferier i sine planer, nettopp var å ta høyde for at SVV ikke ville være fullt bemannet og tilgjengelig for avklaringer i ferieperioder.

Lagmannsretten mener etter dette at kontrakten har blitt praktisert slik at sommer, jul og påskeferie har blitt lagt inn i IBMs planer etter krav fra SVV uten noen vurdering av om ferien ville forsinke arbeid på kritisk linje. Oppsummert har milepælene i EO001 og EO042 blitt endret for å ta hensyn til ferie. SVV stilte krav om at SVVs kontraktsfestede ferie i juli 2015 skulle hensyntas i IBMs planer. IBM varslet at selskapet ville kreve at milepælene ble flyttet tilsvarende effekten av sommerferien 2015 som IBM ble pålagt å legge inn i gjennomføringsplanen versjon 4.0, og dette fremkalte ikke motforestillinger fra SVV. Lagmannsretten mener at SVV ikke med rette ville kunnet avvise en endringsanmodning med krav om fristforlengelse og flytting av milepæler med 21 kalenderdager for ferie i juli 2015, hvis en endringsanmodning slik IBM varslet om 22. april 2015 hadde blitt fremmet før kontrakten ble hevet. Tilsvarende legger lagmannsretten til grunn at milepælene ville blitt flyttet med 21 kalenderdager for julen 2015 og syv kalenderdager for påskeferien 2016.

Lagmannsretten mener etter dette at IBM har krav på til sammen 49 dagers fristforlengelse på grunn av SVVs ferie.

4.4.3 Fristforlengelse på grunn av endringsanmodninger hvor konsekvensen hadde inntrådt da kontrakten ble hevet – Noen fellesspørsmål 4.4.3.1 Innledning Det er ni endringsanmodninger i saken hvor konsekvensen av endringen hadde inntrådt da kontrakten ble hevet. I syv av disse var det krevd fristforlengelse/flytting av milepæler. De syv endringsanmodningene er EA053 (CRM økt kompleksitet), EA054 (CRM arbeidsform og prosess), EA067 (Greenbird), EA108 (Manglende tilbakemelding IT2), EA112 (R8), EA113 (Forberedelse og gjennomføring KP2) og EA117 (Gjennomføring av IT2 og nytt KP2). Samlet har IBM krevd 268 kalenderdagers fristforlengelse i disse endringsanmodningene. Lagmannsretten gjør rede for kontraktens regulering av endringer, og knytter noen kommentarer til endringer i iterative prosesser i punkt 4.4.3.2 og 4.4.3.3.

I punkt 4.4.3.4 redegjør lagmannsretten for kontraktspartenes håndtering av endringsanmodninger og endringsordrer i konstruksjonsfasen, samt de utfordringene denne håndteringen hadde i prosjektet. 4.4.3.2 Kontraktens regler om endringer Endringer i leveransen er regulert i Generelle kontraktsbestemmelser punkt 3.6 og Bilag C punkt 6. (FU 8458 på 8471 og 9105 på 9163) Bestemmelsene gir SVV og IBM på nærmere vilkår rett til å anmode om endring ved fremsettelse av en endringsanmodning (EA). SVVs endringsadgang er vid. SVV kan anmode om endringer «i form av økning og reduksjon av omfang og innhold i den avtalte Leveransen og endring av Fremdriftsplanen», jf. Generelle kontraktsbestemmelser punkt 3.6.1 første avsnitt. Endringsadgangen er imidlertid begrenset ved at nettoeffekten av samtlige endringer ikke kan overstige 25 prosent av målprisen ved kontraktsinngåelse, jf. Bilag C punkt 6. Ved EO026 ble dette endret slik at grensen beregnes basert på oppdatert Målpris etter HMP1 regulert i EO029. (FU 14243) SVVs endringsadgang er også begrenset av reglene om direkte anskaffelser i forskrift om offentlige anskaffelser.

IBMs endringsadgang er snevrere enn SVVs adgang. Etter punkt 3.6.1. andre avsnitt kan IBM utstede en endringsanmodning dersom SVV «krever utført arbeid eller leveranser som [IBM] hevder faller utenfor Leveransen», eller dersom SVV «ved handling eller unnlatelse påfører [IBM] arbeid eller kostnad som faller utenfor Leveransen eller forsinker [IBM]». IBM kan også utstede en endringsanmodning dersom relevante lover eller forskrifter er gitt eller endret etter at kontrakten ble inngått, og dette fører til merarbeid, kostnad eller forsinkelse for IBM. Dette siste alternativet er ikke aktuelt i vår sak. Etter punkt 3.6.1 andre avsnitt siste setning skal IBM fremsette endringsanmodning «uten ugrunnet opphold», ellers bortfaller retten til å påberope seg endringen. IBM skal på bakgrunn av en utstedt endringsanmodning «foreta en konsekvensutredning for Leveransen, Kontraktsprisen og Fremdriftsplanen», jf. punkt 3.6.1 tredje avsnitt. Konsekvensutredning skal foreligge innen fem arbeidsdager, jf. Bilag C punkt 6. IBM kan kreve tilleggsvederlag for dokumenterte merkostnader med

konsekvensutredningen av endringsanmodninger fremsatt av SVV og av endringsanmodninger de selv fremsetter som resulterer i utstedelse av endringsordre (EO). Etter at konsekvensen av en endringsanmodning er utredet skal SVV meddele om IBMs konsekvensutredning aksepteres og om forholdet representerer en endring, jf. Generelle kontraktsbestemmelser punkt 3.6.2 første avsnitt. Dersom SVV aksepterer at forholdet representerer en endring og konsekvensene av denne, skal SVV enten frafalle det kravet som utløste endringsanmodningen eller utstede en endringsordre (EO). Endringsordre skal dokumenteres skriftlig på et fastlagt skjema der konsekvenser for leveransen, kontraktsprisen og fremdriftsplanen fremgår, jf. punkt 3.6.2 andre avsnitt. Endringsordre skal undertegnes av bemyndiget person fra hver av partene, og leveransen, kontraktsprisen og fremdriftsplanen skal da justeres i samsvar med konsekvensene slik de fremgår av endringsordren. Endringsordren kan etter punkt 3.6.2 først iverksettes i forbindelse med et Kontrollpunkt, det vil si at selve endringen først kan utføres i et etterfølgende trinn.

Generelle kontraktsbestemmelser punkt 3.6.3 regulerer omtvistede endringsordre. En endring defineres som omtvistet dersom SVV ikke aksepterer at det foreligger grunnlag for en endring og/eller konsekvensene ikke aksepteres. Omtvistede endringer skal håndteres i samsvar med kontraktens alminnelige konfliktløsningsprosedyre i Generelle kontraktsbestemmelser punkt 8.6. Dette innebærer at tvisten først skal forsøkes løst gjennom alminnelige forhandlinger mellom kontraktspartenes prosjektledere. Blir den ikke løst der, skal tvisten bringes inn for behandling i koordineringsgruppen. Hver av kontraktspartene kan når som helst kreve en tvist forelagt for koordineringsgruppen ved å fremsette skriftlig krav om det, og koordineringsgruppen skal da møtes innen fem dager. Blir tvisten ikke løst i slikt møte, skal det avholdes et nytt møte innen fem arbeidsdager. Tvister som ikke lar seg løses gjennom behandling i koordineringsgruppen, kan bringes inn for domstolen. 4.4.3.3 Særlig om iterative prosesser Leverandøren kan som nevnt kreve endring dersom kunden «krever utført arbeid eller leveranser som [...] faller utenfor Leveransen».

For å konstatere en endring, er det da nødvendig å fastslå hva som var avtalt om leveransen og hvilket arbeid som skulle utføres. Her står leveransespesifikasjonen sentralt. Som nevnt under «sakens bakgrunn» er PS2000 utarbeidet for systemutviklingsprosjekter hvor det ikke er hensiktsmessig eller mulig på forhånd å fastsette nøyaktige eller detaljerte spesifikasjoner, og er basert på at utviklingen skjer i iterasjoner. Spesifikasjonen av leveransen er ikke utarbeidet i detalj før prosjektet startes opp, og ligger ved avtaleinngåelse på et generelt og overordnet nivå i form av kundens behovsanalyse og leverandørens grove løsningsforslag. Således inneholder Bilag A i vår sak «beskrivelser og kravtabeller som gir en grov spesifikasjon av Kundens behov, krav og egne leveranser» og «Leverandørens utdypning av forutsetninger og forbehold i et grovt løsningsforslag». (FU8485 på 8489) PS2000 bygger på at kontraktspartene skal utarbeide de mer detaljerte spesifikasjonene underveis, i første omgang i løsningsbeskrivelsesfasen. Denne fasen skal munne ut i en omforent løsningsbeskrivelse for det videre utviklingsarbeidet.

Løsningsbeskrivelsen i en iterativ prosess er imidlertid ikke noen endelig spesifikasjon, og vil ofte være noe grovere enn tilsvarende spesifikasjoner ved utvikling etter fossefallsmetoden, jf. Føyen m.fl., Kontrakter for utvikling av programvare 2006 side 249. Iterative prosesser forutsetter at spesifikasjonene skal kunne endres i løpet av de iterasjonene som gjennomføres i konstruksjonsfasen. Den mer detaljerte spesifiseringen foregår da basert på prototyping/ utvikling hvor funksjonaliteten fastlegges underveis og i nært samarbeid med kundens brukergruppe, jf. Føyen mfl. ibid. I tillegg foregår en ytterligere spesifisering ved at kunden bidrar med sine innspill til design av systemet under gjennomføring av de enkelte iterasjoner. Den endelige detaljspesifikasjonen for den enkelte iterasjon vil derfor ikke være klar før iterasjonen er gjennomført og godkjent av kunden. Endringer i form av mer detaljerte spesifikasjoner av hva som utvikles, står således helt sentrale i forbindelse med iterative prosjekter, jf. Føyen m.fl. ibid side 291.

Føyen mfl. skriver på side 203 at et problem ved prosjektgjennomføring etter iterative utviklingsprosesser, er at det kan være vanskelig å definere hva som er en forfining av en spesifikasjon, og hva som er tillegg eller endring. Lagmannsretten oppfatter at dette har vært en sentral utfordring i Grindgut. Utfordringen ligger i at «forfining» og «endring» ligger på en skala, og at det som i utgangspunktet starter som en forfining av en

spesifikasjon, på ett eller annet tidspunkt vil gli over i et tillegg eller endring når intensiteten i detaljeringen øker utover det som var forventet eller forutsatt. Det kan være vanskelig å fastslå underveis når overgangen fra forfining til tillegg eller endring skjer. Dessuten må partenes forventninger og forutsetninger trekkes inn som en vurdering av hva som er et tillegg eller endring, og disse kan være vanskelige å fastslå. 4.4.3.4 Generelt om endringer under konstruksjonsfasen Kontraktspartene etterlevde kontraktens endringsregime under konstruksjonsfasen. (FU 16714) Endringsanmodninger ble fremsatt på fastlagt skjema, med en beskrivelse av innholdet, behovet og konsekvensen. Kontraktspartene drøftet endringsanmodninger først i prosjektledermøte, og eskalerte dem til behandling i KG-møter hvis ikke de ble enige. SVV hadde riktignok innvendinger på IBMs beskrivelse av endringsbehov og konsekvensene i flere endringsanmodninger, men lagmannsretten oppfatter at det ikke var endringsregimet som sådan som var utfordringen.

Utfordringen lå i at det tok lang tid å behandle endringsanmodninger, og at uenighet om endringsanmodninger ikke ble løst. Lagmannsretten legger til grunn at SVV forventet et betydelig endringsomfang under konstruksjonsfasen. I SGmøte 25. juni 2014, mot slutten av løsningsbekrivelsesfasen, rapporterte daværende prosjektleder Jo Andersen at «erfaringene fra løsningsbeskrivelsesfasen tilsier et forventet stort endringsomfang også i fortsettelsen av prosjektet». (FU 13987 på 13989) En intern risikomatrise viser at SVV på det tidspunktet antok at endringsomfanget «optimistisk» sett ville være på 30 prosent av kontraktspris, mest «sannsynlig» på 45 prosent av kontraktspris og «pessimistisk» sett på 50 prosent av kontraktspris. (FU 12918 på 12921) Kontraktsprisen var på dette tidspunktet på 82,6 millioner kroner. At SVV forventet endringer «opp mot 50 prosent av kontraktspris» i konstruksjonsfasen går også frem av statusrapport for prosjektet for juli 2014. I samme rapport går det frem at «risiko for at styringsmål og styringsramme ikke vil være tilstrekkelig grunnet høy risiko for tidsplan og endringsomfang», ble ansett for å være stor.

(FU 14645 på 14651 og 14652) Delprosjektleder AnneMarie Ytrehus skrev i statusrapport for delprosjektet leveranse for juli 2014 at arbeidet med detaljert design etter all sannsynlighet ville avdekke behov for ytterligere endringsordre, og at omfanget var ukjent. (FU 14117 på 14119) I SVVs presentasjon til SG-møte 23. februar 2015, like etter at IBM hadde utstedt EA053 og EA054, ga SVVs prosjektledelse uttrykk for at de forventet et «stort endringstrykk» fra IBM fremover i konstruksjonsfasen og at det lå et overslag på 44 millioner kroner til endringer i kostnadsprognosen som ble fremlagt for styringsgruppen. (FU 20584 på 20590) Slik lagmannsretten ser det, lå det i kontraktens art at det ville komme et betydelig antall endringer, jf. det som er omtalt over i punkt 4.4.3.3 om endringer i iterative utviklingsprosesser. Et forsterkende tilleggselement i Grindgut-prosjektet var at kravene i kontraktens Bilag A (behovsanalysen) var uklare.

Videre hadde SVVs brukere – bompengeselskapene og driftsselskapene – i begrenset grad blitt involvert i arbeidet med behovsanalysen og i arbeidet med å detaljere spesifikasjonene i løsningsbeskrivelsesfasen enda brukerne hadde levert en rapport til SVV i starten av løsningsbeskrivelsesfasen med tydelige forventninger til hva som måtte medtas i Grindgut. (FU 10198) Først fra slutten av oktober 2014, mer enn to måneder inn i konstruksjonsfasen, ble flere bompengeselskaper involvert i arbeidsmøter til detaljering av design. Slik lagmannsretten ser det, bidro dette til å øke endringsomfanget, jf. nedenfor. Lagmannsretten legger videre til grunn at SVV var restriktiv med å godkjenne endringsanmodninger utstedt av IBM i konstruksjonsfasen, og at det tok lang tid å få avklaringer. Fra begynnelsen av februar 2015 godkjente SVV ingen endringsanmodninger fremsatt av IBM. Flere endringsanmodninger fremsatt av SVV ble heller ikke godtatt eller undertegnet selv om kontraktspartene var enige om at det var grunnlag for dem. Et fellestrekk ved endringsanmodningene fremsatt av IBM, var at IBM også krevde fristforlengelse.

Det ble etter hvert mange uløste og omstridte endringsanmodninger, noe som fikk betydning for samarbeidet i prosjektet og for planlegging og fremdrift. At endringsbehandling var krevende og at SVV generelt var «meget tilbakeholdne» med å godkjenne endringsanmodninger, ble kommentert av A-2 i rapport til KP2 5. juni 2015. (FU 24498 på 24505) A-2 vurderte at utfordringene knyttet til endringsbehandlingen hadde en sammensatt bakgrunn. Utfordringene kom «primært som et resultat av upresise krav i kontrakten, uklarheter i SRS-dokumentet [System Requirements Specification] fra LBF, mangelfull presisjon i dokumentasjon fra arbeidsmøter mellom partene både i LBF og KF, og at underlag er sendt til GD uten at tilstrekkelig avklaring er gjort med SVV». A-2 pekte på svakheter både ved IBMs grunnlag for endringsanmodninger og ved SVVs endringshåndtering, og på at det var «en tydelig mistro mellom partene som gjør endringshåndtering meget vanskelig». Rapporten understreket at det

var «en stadig økende risiko for at manglende beslutninger kan få uheldige konsekvenser for fremdrift og løsningens innhold ved idriftsettelse». A-2s Henning Denstad forklarte seg for lagmannsretten. Han gjentok at det var svakheter ved IBMs grunnlag for noen av endringskravene, men understreket at dette ikke rokket ved at SVV var «unødvendig restriktiv» hva gjelder å godkjenne IBMs endringskrav. Lagmannsretten går nå over til å behandle de omtvistede endringsanmodningene i gruppe (ii) og EA078 i gruppe (iii) i kronologisk rekkefølge.

4.4.4 EA053 Økt kompleksitet 4.4.4.1 Innledning – Behandlingen av EA053 EA053 er en oppsamling av en rekke endringer fra perioden høsten 2014 til februar 2015. (FU 19987) Den ble utstedt av IBM ved Nicolai Rygh 6. februar 2015 og gjelder «CRM Økt kompleksitet». Den omfatter til dels arbeid som allerede var utført, og til dels endringer som IBM hadde identifisert, men hvor arbeidet ikke var utført. Behovet for endringen er i endringsanmodningen beskrevet slik: Leverandøren ser at kompleksiteten knyttet til utviklingen av Use-Case knyttet til CRM er omfattende og basert på at kravene detaljeres ut med nye ikke-kjente krav enn det den opprinnelige løsningen og estimeringen la til grunn. Prosjektet har justert tidsplanen for å ivareta denne økte kompleksiteten, og denne endringen er nødvendig for å justere målpris og milepæler for å ta høyde for denne økte kompleksiteten. Leverandøren har bemannet opp prosjektet for å øke kapasitet for å ta høyde for de økte estimatene, samt gjort øvelser sammen med Kunden for å redusere omfanget innenfor dette området (ref. EA0xx).

EA0xx ble avvist av Kunden og det var på det tidspunktet ikke aktuelt for Leverandøren å øke kapasiteten ytterligere for å levere gjenværende omfang av løsningen. Leverandøren har analysert de ulike strømmene, og ser at flere strømmer har økt basis estimat. Endringen fokuserer likevel kun på CRM, da det er kompleksitet på dette området som driver den kritiske linjen i prosjektet. Det økte omfanget CRM forklares ned på aktivitetsnivå i vedlagte excel-fil. Kapasiteten tilgjengelig innenfor CRM for å gjøre DCUT drives av tilgjengelig antall utviklere. Det er mobilisert 16 utviklere innenfor dette området. Basert på en effektivitetsgrad på 80% produserer disse 522 DCUT timer per uke. Med en økningen på DCUT tilsvarende 3742 timer, betyr dette at Leverandøren vil trenge 6,8 uker for å levere det utvidede omfanget på disse Use-Casene. Endringen flytter den kritiske linjen i prosjektet med 6,8 uker, og kostnaden for denne endringen tilsvarer kostnaden for hele prosjektet. Verdien anslås basert på gjennomsnittet av de fire siste ukene, og utgjør da 19 660 718 Kroner.

Henvisningen til EA0xx er en henvisning til EA035/EA040, utstedt av IBM 28. november 2014 og avvist av SVV 12. desember 2014, jf. punkt 4.4.4.10.4 nedenfor. (FU 17579 og FU 18068 på 18069) Excel-filen som IBM la ved EA053, inneholdt opprinnelig 95 ulike brukerhistorier (use cases) som ifølge IBM hadde økt i kompleksitet i løpet av konstruksjonsfasen. (ExcelD29 B346) Årsaken til den økte kompleksiteten var kort beskrevet, for eksempel at funksjonalitet var «mangelfullt beskrevet i kravdokumentasjon og løsningsbeskrivelsesfasen» (32 tilfeller), at endringen skyldtes «merarbeid knyttet til ikke-funksjonelle krav pga økt kompleksitet» (13 tilfeller), at endringen skyldtes «merarbeid knyttet til brukergrensesnitt pga økt kompleksitet» (12 tilfeller), at det var et «nytt Usercase» (fire tilfeller) eller at «brukergrensesnittet ble i utgangspunktet ikke estimert» (tre tilfeller). Årsaken til den økte kompleksiteten var ikke oppgitt for åtte av brukerhistoriene, men disse er senere frafalt. For hver brukerhistorie var det oppgitt et timeestimat ved HMP1, et re-estimert antall timer, og avviket.

Sammen med listen over brukerhistoriene fulgte en liste over de 16 utviklerne som ifølge IBM var blitt mobilisert til å utføre utviklingsarbeidet IBM krevde dekning for, og en oversikt over hvordan kravet i EA053 var beregnet. De underliggende beregningene ble ikke gjort tilgjengelig for SVV. SVV avviste EA053 ved brev 23. februar 2015. (FU 20575) SVV mente at de påståtte endringene verken var et resultat av at SVV hadde stilt nye krav som ikke var kjent under løsningsbeskrivelsen eller skyldtes forhold

som var skjult for IBM under løsningsbeskrivelsesfasen. SVV var også uenig i at CRM alene var på kritisk linje. Kontraktspartene møttes i perioden 13. til 19. mars 2015 og gjennomgikk 46 prosent av brukerhistoriene i detalj, men ble ikke enige om noen av dem. (FU 22853) SVV mente at alt lå innenfor avtalt omfang, mens IBM fastholdt at den økte kompleksiteten utgjorde endringer i forhold til spesifisert funksjonalitet fra løsningsbeskrivelsesfasen. IBM meldte EA053 som omtvistet 19. mars 2015, og kontraktspartene møttes til drøftelser sammen med A-2 24. mars 2015. SVV sto fast på at EA053 var urettmessig og avviste den på nytt i brev til IBM av samme dag. (FU 21656) Den 27. mars 2015 ble det holdt ekstraordinært KG-møte for å behandle eskalerte endringsanmodninger, blant annet EA053. (FU 21711) Som saksgrunnlag forelå det et notat fra A-2 med et forslag til løsning. (FU 21696) A-2s forslag gikk ut på at EA053 skulle endres til å omfatte «50 % faktisk timebruk i konstruksjon», og at hovedmilepælsplanen ble justert tilsvarende. A-2 mente at det var å forvente at en slik justering maksimalt ville utgjøre to-tre uker på HMP2.

Forslaget gikk videre ut på at SVV skulle dekke kostnadene ved den endrede EA053. Kontraktspartene mente imidlertid at det ikke var grunnlag for å bli enige i KG-møtet, og det ble fattet vedtak om at prosjektlederne Anne-Marie Ytrehus og Terje Harangen skulle «sette seg ned sammen etter påskeferien for å se på et mer konkret forslag enn det som foreligger per nå». A-2 skulle følge dette arbeidet og gjennomføre forhandlinger mellom kontraktspartene før neste KG-møte 17. april 2015. Lagmannsretten bemerker at A-2s forslag er i referatet fra KG-møtet angitt å være at EA053 skulle endres til å omfatte «1/3 av faktisk tidsbruk i konstruksjon», men dette stemmer ikke med A-2s notat. EA053 var tema på et møte mellom SVVs Arve Kirkevold og IBMs Kjetil Westgaard og Urs Briner 31. mars 2015. (FU 21910 og 21912) De ble enige om at de ønsket å finne en minnelig løsning for å lukke EA053 i god tid før neste planlagte KG-møte i april 2015, og at de som grunnlag for drøftelsene om en minnelig løsning ville «verifisere» A-2s anbefaling.

De ble også enige om at fremtidige endringer – i omfang, tidslinje og/eller kostnad – skulle avtales før arbeidet ble påbegynt. EA053 ble imidlertid ikke lukket, og var sammen med EA054 (se punkt 4.4.5 nedenfor) på dagsordenen til KGmøtet 17 april 2015. (FU 22629) Koordineringsgruppen kom ikke til enighet om endringsanmodningene, men fattet vedtak om at hver av kontraktspartene skulle «skaffe seg mandat og forhandlingsrom for å kunne håndtere» EA053. Forhandlingene skulle starte opp etter at KP2 var godkjent, og ledes av Stein Ødegaard og Kjetil Westgaard. Ødegaard var SVVs hovedprosjektleder i konstruksjonsfasen, og Westgaard var IBMs prosjekteier. Videre skulle IBM trekke EA054 forutsatt at EA053 ble løst. EA054 ble derfor satt på vent inntil videre. Av møtereferatet går det frem at A-2 anbefalte «en kompensasjon i størrelsesorden 6-9 mill. og en flytting av milepæl med 2-3 uker», samt at EA054 ble tatt i betraktning ved behandlingen av EA053. Etter dette KG-møtet utarbeidet A-2 et forhandlingsgrunnlag i form av et notat 19. april 2015 med sin «forståelse av endringsanmodningen og forslag til løsning».

(FU 22853) A-2 anså «den totale konsekvens angitt av IBM (ca. 18 mill og 4,5 uker) som sannsynlig utfra det angitte endringsvolumet på 3.500 DCUT timer og gitt lav mulighet til å forhindre følgekostnader og påvirkning av milepæler». Samlet ga dette «et utfallsrom på forhandlingen mellom 1,5 og 18 mill, og 1 – 5 uker forskyvning av milepæl». A-2s anbefaling for forhandlinger om EA053 var igjen «kompensasjon i størrelsesorden 6-9 mill. og en flytting av milepæl med 2-3 uker», og at «EA054 tas med i betraktning under behandling av EA053». Stein Ødegaard ba i innkalling til SG-møte 24. april 2015 om mandat til å forhandle frem en løsning for EA053 og EA054 innenfor rammen av A-2s anbefaling. (FU 21918 på 21919 og TU 2424) Styringsgruppen var imidlertid ikke villig til å gi noen forhandlingsfullmakt «før endringsanmodningene er konkrete og sporbare mot avtalens krav». Styringsgruppen fattet vedtak om at styringsgruppens leder, Jane Bordal, kunne gi koordineringsgruppens leder, Arve Kirkevold, fullmakt til å inngå endringsanmodningene «når omforent løsning med IBM er fremlagt og i henhold til kravet om å være konkret og sporbart».

(FU 23009 på 23012) EA053 ble ikke behandlet på KG-møte 12. mai 2015. (FU 23704 på 23707) Det går likevel frem av referatet fra møtet at IBM hadde fått forhandlingsmandat, men at selskapet ville «vurdere både nytteverdien og konsekvensen av å gå inn i detaljene, da dette vil kreve ressurser i prosjektet på begge sider». SVVs delprosjektleder for delprosjektet Leveranse, Anne-Marie Ytrehus, skrev i statusrapporten for mai 2015 at IBM «ikke [har] vært i stand til å forklare hvordan de har kommet frem til sine estimater for de 95 påståtte endringene EA053 omfatter, og de har heller ikke klart å påvise at noen av sakene skyldes at SVV har endret

sine krav». Hun rapporterte videre at IBM hadde bedt SVV om å utøve hoppeplikt og instruere IBM til å levere, men at SVV ikke kunne gjøre dette uten å gå utover kontraktens begrensninger på hvor stor andel av målprisen hoppeplikten kunne anvendes på. Hun konkluderte ut fra dette med at det så ut som om «IBM egentlig ikke ønsker å levere SVV en løsning som fyller de behovene som var intensjonen og målet med å inngå denne Kontrakten». (FU 23339 på 23341) Kontraktspartene møttes flere ganger i begynnelsen av juni 2015 for å gå gjennom de enkelte endringene i excel-arket linje for linje, men ble ikke enige om at noen av disse var endringer. (FU 24358, 24379 og 24468) I SG-møte 2. juni 2015, hvor hovedpunktet på agendaen var «alternative planer for prosjektet», stilte styringsgruppen spørsmål om omfanget av endringer var så stort som IBM hevdet. Svaret fra prosjektet var at «magefølelsen er at dette virker litt oppblåst, men at det er vanskelig å svare konkret på da IBM ikke gir tilstrekkelig innsyn i løsningen».

Det var likevel «hevet over enhver tvil at avstanden mellom partene når det gjelder hva som er endringer og ikke er stor, og at EA’er som fremmes fra IBM synes å være overestimert». (FU 24408 på 24410) I samme møte understreket styringsgruppen «viktigheten av å ikke godkjenne noe som gjør at SVV mister rettigheter overfor IBM». (FU 24408 på 24412) EA053 var tema på det såkalte direktørmøtet 8. juni 2015. IBM fastholdt at arbeidet i endringsanmodningen var utenfor scope, og varslet at IBM ikke ville levere innholdet i EA053 uten at SVV instruerte om det. (FU 24637) A-2 avga en ny innstilling 10. juni 2015, og opprettholdt konklusjonen fra tidligere notater. (FU 24700) I KG-møte 16. juni 2015 bekreftet IBM at de hadde tatt arbeidet i EA053 ut av planverket «inntil SVV krever den gjennomført via avtalens «hoppeplikt» eller kravet aksepteres». (FU 24893 på 24896) A-2 mente at SVV burde vurdere å bruke hoppeplikten hvis ikke kontraktspartene kom til «enighet om endringsstyring av omfanget».

(FU 24899 på 24907) SVV viste til at de ikke fikk aksept av styringsgruppen for en «sjablongløsning» av en så vesentlig endring, og at det krevdes «en reell endringsanmodning som [er] konkretisert før beslutning vil tas». Situasjonen var fastlåst. Dette var siste KG-møtet før kontrakten ble hevet. Før behandlingen for domstolene, frafalt IBM 37 av de påståtte endringene som inngikk i EA053. For lagmannsretten omfatter EA053 endringer på 58 brukerhistorier på til sammen 3 108 DCUT-timer. 4.4.4.2 Partenes anførsler IBM har i korthet gjort gjeldende at kompleksiteten i alle de 58 brukerhistoriene som kravet i EA053 nå omfatter, økte på grunn av at SVV stilte nye krav til brukerhistoriene sammenlignet med det som ble forutsatt i løsningsbeskrivelsen. Økningen i kompleksiteten gir IBM i utgangspunktet et krav på fristforlengelse med 39 kalenderdager og økning av målprisen med 16 329 640 kroner. Da 78 prosent av arbeidet var utført på hevingstidspunktet, har IBM i forbindelse med vederlagskravet krevd økning av målpris med 12 737 119 kroner, jf. punkt 5.5. Staten har i korthet gjort gjeldende at SVVs avvisning av EA053 var rettmessig.

SVV har ikke krevd arbeidet utført. IBM har heller ikke påvist at noen av de påståtte estimatøkningene skyldtes at SVV fremsatte nye krav i konstruksjonsfasen. EA053 var en oppkonstruert endringsanmodning der IBM forsøkte å gi SVV ansvaret for sine feilestimeringer i løsningsbeskrivelsesfasen. IBM fremsatte EA053 – og EA054 – for å hindre at selskapet kom i vesentlig mislighold. Arbeidet som er beskrevet i EA053 representerte ikke endringer, men arbeid som hele tiden var en del av kontrakten og som var inntatt i IBMs interne DCUT-estimater og gjennomføringsplaner. 21 av linjene i EA053 som IBM hevdet lå utenfor kontrakten, mente IBM lå innenfor kontrakten i EA035/EA040. IBMs DCUT-estimater for SugarCRM økte ikke etter september 2014 slik man ville forventet dersom kompleksiteten hadde økt. Under enhver omstendighet kan IBM ikke kreve endring for arbeid som allerede var utført da EA053 ble fremsatt. Dette gjaldt ca. 40 prosent av de enkelte linjene. Det er uansett ikke påvist at arbeidet i EA053 lå på kritisk linje.

Usikkerhetsmatrisen og usikkerhetspåslaget begrenser også de endringsanmodningene IBM kan få medhold i. 4.4.4.3 Utgangspunkter for lagmannsrettens drøftelse Lagmannsretten legger til grunn at SVV anså funksjonaliteten som er beskrevet i de 58 omtvistede brukerhistoriene eller «linjene» i EA053, som nødvendige for at løsningen skulle oppfylle vegvesenets behov. I notat 19. april 2015 skrev A-2 at deres forståelse etter møter med kontraktspartene, var at «begge parter mener

listen representerer nødvendig funksjonalitet hvor alt må implementeres». (FU 22853) I statusrapporten for mai 2015 skrev delprosjektleder Anne-Marie Ytrehus at «sakene EA053 består av er krav som må oppfylles for at løsningen skal kunne gå i produksjon». (FU 23339 på 23341) Ytrehus bekreftet i sin forklaring for lagmannsretten at SVV ikke kunne ha klart seg uten noe av funksjonaliteten som er beskrevet i de 95 linjene som EA053 opprinnelig besto i. Gitt at SVV anså funksjonaliteten som nødvendig, legger lagmannsrettens også til grunn at SVV ville ha krevd arbeidet utført hvis vegvesenet først hadde akseptert at det lå utenfor kontrakten. Det blir da etter lagmannsrettens syn kunstig å vurdere om SVV «fremsatte» nye krav i konstruksjonsfasen, slik staten hevder. Hovedspørsmålet for lagmannsretten blir om arbeidet som inngår i EA053 er «arbeid eller leveranser som [...] faller utenfor Leveransen», jf. Generelle kontraktsbestemmelser punkt 3.6.1. (FU 8458 på 8471) Lagmannsretten legger videre til grunn at SVV har vært enig i at EA053 omfattet rettmessige endringer.

A-2 observerte i notat 19. april 2014 at «prosjektlederne er enige om at opprinnelig EA053 beskriver en reell økning i arbeidsomfanget for leverandør» og at «begge parter må bære en del av skylden for det utvidede arbeidsomfanget». (FU 22853 på 22854) I SG-møte 2. juni 2015 svarte «prosjektet», enten hovedprosjektleder Stein Ødegaard eller delprosjektleder Anne-Marie Ytrehus, på spørsmål fra styringsgruppen om omfanget av endringer var så stort som IBM hevdet, derimot at «magefølelsen» var at IBMs krav «virker litt oppblåst» og at det «synes å være overestimert». (FU 24408 på 24410) Lagmannsretten forstår disse begivenhetsnære bevisene slik at SVV mente at i hvert fall en del av arbeidet i EA053 lå utenfor scope. Dette ble bekreftet av forklaringene fra både Ødegaard og SVVs funksjonelt løsningsansvarlige, Arve Leivestad. De 58 brukerhistoriene som EA053 nå består i, kan inndeles på forskjellige måter, og partene har hatt ulike tilnærminger til inndelingen. Lagmannsretten har valgt å dele brukerhistoriene i fem grupper, som kan fremstilles slik: Gruppe

Estimat
Utført
Saker Timer Saker Timer
1. Fritaksregler
2
278
2
278
2. ACT- og TST-fil
6
305
6
305
3. Brukergrensesnitt
14
503
11
367
4. Økt kompleksitet
20 1 080
13
857
5. Annet
16
11
612
Totalt
58 3 108
942
43 2 419

Tabellen er kopiert fra tingrettens dom side 105, men med rettede tall. Grupperingen av brukerhistoriene bygger på inndelingen i en IBM-presentasjon til kontraktspartenes gjennomgang av EA053 i begynnelsen av juni 2015. (FU 24358) Antallet saker (brukerhistorier) i hver gruppe og antallet DCUT-timer er hentet fra Tonje Offenberg Byes skriftlige forklaring i forbindelse med IBMs tilsvar for tingretten i hjelpedokumentet i FU bilag 1354, som hun brukte som støtte under sin forklaring for lagmannsretten. Antallet saker i gruppe 3 og 4 avviker fra tallene som ble presentert i IBMs prosedyre, da én brukerhistorie (linje 23) var representert i begge gruppene. Lagmannsretten har kategorisert denne brukerhistorien under gruppe 3. For øvrig var det regnefeil i antallet DCUT-timer i gruppe 2. Lagmannsretten vurderer de enkelte gruppene i punkt 4.4.4.4 til 4.4.4.8 nedenfor. 4.4.4.4 Fritaksregler Gruppen «fritaksregler» utgjør to av 58 brukerhistorier i EA053, og 278 DCUT-timer. (FU bilag 1354 linjer 4 og 65) Alle disse timene var utført på hevingstidspunktet og inngår i IBMs krav på både fristforlengelse og vederlag.

IBMs endringskrav er begrunnet med at kravene til fritak var mangelfullt beskrevet i kravdokumentasjonen og løsningsbeskrivelsen, og at kravene i konstruksjonsfasen utviklet seg til en annen fritaksløsning enn den som IBM hadde lagt til grunn for sine estimater og som IBM med rimelighet kunne forutse. Staten har gjort gjeldende at IBM ut av løsningsbeskrivelsesfasen aksepterte å bygge løsningen på en ikke-uttømmende liste over fritak. For øvrig var det kravstilt i Bilag A GK.01.03 at det skulle være «enkelt å parametrisere forretningsregler som støtter regler for bompengeinnkreving i Norge, i dag og i fremtiden». (FU 8561) Dette innebærer at løsningen måtte være meget fleksibel og kunne håndtere nye takst- og rabattregler, inkludert fritak. Lagmannsretten er enig med IBM i at gruppen «fritak» utgjør endringer. Det eneste konkrete kravet til fritak i Bilag A, er F.01.33 – «Tidsbestemte fritaksavtaler skal automatisk kunne endres til «vanlig» avtale når fritaksavtalens gyldighet utløper». (FU 8591) I løsningsbeskrivelsesfasen ble kravet til fritak detaljert i en e-postutveksling mellom IBMs Tonje Offenberg Bye og SVVs Arve Leivestad.

(FU 11858 og 11878) I e-post 21. mars 2014 ba Tonje Offenberg Bye om en avklaring på hvilke fritak løsningen skulle støtte. Dette ble registrert som en aksjon for SVV i aksjonslisten for CRM med frist 25. mars 2014. (FU bilag 1113, linje 42) I e-post 25. mars 2014 sendte Arve Leivestad en liste over hvilke typer kjøretøy som kunne få fritak. (FU 11878) Han opplyste at det først og fremst var bevegelseshemmede som hadde tidsbestemte fritaksavtaler. Han opplyste videre at det i tillegg til fritak for bestemte typer kjøretøy, også fantes «adressebestemte fritak» – også kalt «bomringbestemte fritak» – som ga fritak for enkelte husstander på grunn av husets plassering i forhold til en bomstasjon, men at han måtte høre med de enkelte driftsselskapene om detaljene og om slike fritak fortsatt var aktuelle. Han la til i uthevet skrift at listen over fritak «ikke [er] en uttømmende liste». Leivestad forklarte for lagmannsretten at tanken bak denne formuleringen ikke var å holde tilbake noe, men å unngå at IBM kunne kreve en endring hvis SVV hadde oversett noe.

Aksjonspunktet som Tonje Offenberg Bye opprettet 21. mars 2014, ble lukket 2. april 2014. Den 9. mai 2014 ble det opprettet en ny aksjon for SVV med frist 30. mai 2014 for å avklare og definere adressebestemte/bomringbestemte fritak. (FU bilag 1113, linje 113) I aksjonspunktet skrev IBM: «fritak basert på adresse og bomring er ikke hensyntatt i CRM». Bye forklarte for lagmannsretten at bakgrunnen for dette var at SVV ikke hadde kommet tilbake med den nødvendige avklaringen. Aksjonspunktet var ikke lukket ved utgangen av løsningsbeskrivelsesfasen, og ble flyttet til prosjektstyringsverktøyet «Tasks» i IPWC da denne ble tatt i bruk, se punkt 4.4.5.12 nedenfor. (FU 12782) Lagmannsretten legger etter dette til grunn at det ut av løsningsbeskrivelsesfasen (ved HMP1) var avtalt og forutsatt at løsningen skulle tilrettelegge for at tidsbestemte fritaksavtaler automatisk skal gjøres om til vanlige avtaler ved utløpsdatoen (F.01.33) og at den i tillegg skulle støtte fritak for de typer kjøretøy som var listet opp i Arve Leivestads e-post 25. mars 2014.

Spørsmålet om adressebestemte/bomringbestemte fritak var ikke avklart, og IBM hadde tatt forbehold om at dette ikke var hensyntatt i CRM. Forbeholdet i Leivestads e-post kan etter lagmannsrettens syn ikke tillegges rettsvirkning. Det var SVVs oppgave å skaffe oversikt over de aktuelle fritak; dette var ikke noe IBM hadde rådighet over. Lagmannsretten mener videre at man ikke kan utlede av det generelle kravet i GK.01.03 at løsningen måtte ta høyde for alle fritak. Hvis dette var et krav fra SVVs side, skulle dette ha blitt krevd uttrykkelig i kravtabellen. På grunnlag av kravene som forelå ved utgangen av løsningsbeskrivelsesfasen, designet IBM en løsning hvor fritak ble gitt på kjøretøynivå (for eksempel el-bil eller utrykningskjøretøy) eller avtalenivå (for eksempel for bevegelseshemmede eller busselskap) og hvor avtalekunden måtte dokumentere grunnlaget for bestemte fritak. (FU 16140 på 16153 flg. og FU 16157 flg.) At fritak ble gitt på avtalenivå, innebar at fritak var knyttet til bompengeanlegg, og ikke til bestemte bomstasjoner.

Retten til fritak ble registrert i CRM, mens IRIS sørget for at passeringen og fritaket ble priset riktig. I CRM-arbeidsmøte 4. september 2014 reiste IBM spørsmål om hvordan fritak for konsesjonert kjøretøy i rute («buss i rute») og anleggsmaskiner skulle håndteres. (FU 15214) For buss i rute var praksisen i CS Norge at det måtte opprettes en avtale med hvert bompengeselskap langs ruten for å få fritak, mens kontraktspartene diskuterte alternativet med å opprette én avtale for hvert busselskap som ga fritak for alle relevante bomstasjoner langs ruten på tvers av bompengeselskap. Til denne diskusjonen ble det knyttet en aksjon for IBM: «Update Contract Design with bus». Slik oppdatering forutsatte imidlertid at SVV besluttet hvilke forretningsregler skulle gjelde. Inntil en beslutning ble tatt, kunne ikke IBM fullføre design. (FU 16140 på

16145 og FU 16157 på 16158) I slutten av oktober hadde SVV fortsatt ikke konkludert med hvilke forretningsregler skulle gjelde, og i CRM-arbeidsmøte 30. oktober 2014 ble det lagt til en fellesaksjon: «Run this by the other Toll Companies/ Operators to reach an agreement». (FU 16170 på 16707) Den 3. november 2014 ble det holdt et møte for avklaring av fritak. I tillegg til IBM og SVV deltok representanter fra flere bompengeselskaper og driftsselskaper i dette møtet. Av referatet fra møtet går det frem at det for buss i rute, adressebaserte fritak og «autoriserte kjøretøy» skulle være mulig å velge hvilke bomstasjoner det skulle gis fritak i. (FU 16855 på 16860) Dette var et annet design enn det IBM hadde lagt opp til basert på det som var avtalt ut av løsningsbeskrivelsesfasen, og utløste behov for ekstra skreddersøm i CRM. Staten har ikke gjort gjeldende at dette designet var kravstilt og derfor lå innenfor leveransen, men at SVV aldri krevde at IBM skulle løse buss i rute med fleksibilitet til å gi fritak per bomstasjon. Løsningen ble tilbudt av IBM uten antydning om at det ville utgjøre en endring.

SVV kunne levd godt med løsningen som var praktisert i CS Norge. Lagmannsretten mener at dersom dette var tilfellet, ville det ha blitt avklart allerede 4. september 2014 da spørsmålet om den nærmere utformingen av fritaksreglene ble reist. Omfanget av de etterfølgende diskusjonene og møtevirksomheten viser at SVV var opptatt av størst mulig fleksibilitet. SVVs delprosjektleder for delprosjektet Leveranse, Anne-Marie Ytrehus, uttalte som nevnt i månedsrapporten for mai 2015 at sakene EA053 består av, er krav som «må oppfylles for at løsningen skal kunne gå i produksjon». Videre viser grunnlaget for diskusjonene som IBM presenterte i møtene at den alternative løsningen som ble drøftet for buss i rute, krevde endringer i designet som var avtalt. Lagmannsretten konkluderer etter dette med at arbeidet i gruppen «fritaksregler» faller utenfor Leveransen og utgjør en endring. 4.4.4.5 ACT- og TST-fil Gruppen «ACT- og TST-fil» utgjør seks av 58 brukerhistorier i EA053, og 305 DCUT-timer (FU bilag 1354 linjer 5, 49, 51, 53, 55 og 68).

Alle disse timene var utført på hevingstidspunktet og inngår i IBMs krav på både fristforlengelse og vederlag. IBM har begrunnet dette endringskravet med at det under arbeidet med ACT-fil (Actor Table/file) og TST-fil (Toll Station Table) og integrasjon av det internasjonale EasyGo-samarbeidet i Grindgut-løsningen, ble avdekket at kundemedarbeidere måtte få tilgang til informasjon om utenlandske aktører for å håndtere klager fra avtalekunder om bompasseringer i utlandet. Dette innebar at utenlandske operatører og utstedere måtte vises i CRM brukergrensesnitt (GUI), mens IBMs løsning var designet slik at denne informasjonen ble mottatt og prosessert i IRIS. IBM har anført at det ut av løsningsbeskrivelsesfasen ikke forelå noen krav om at utenlandske operatører og utstedere skulle vises i CRM brukergrensesnitt (GUI), og at dette utgjorde en endring. Kravet omfatter tiden og kostnadene forbundet med å redesigne brukergrensesnittet i CRM, CRM Logisk Datamodell og grensesnittet mellom CRM og IRIS. Lagmannsretten mener at IBM ikke kan gis medhold i dette.

Riktignok stilte Bilag A ikke krav til hvordan ACT- og TST-filene skulle håndteres og prosesseres. En IBM presentasjon av 28. august 2014 med tittel «CRM Iterasjon 0/0A» viser imidlertid at IBM helt i starten av konstruksjonsfasen hadde jobbet med eller planla å jobbe med «field mapping completion for ACT file», da det var behov for nye felter i SugarCRM for ACT-filen («Added fields required in SugarCRM for ACT file»). (FU 15034) Formålet med dette arbeidet var ifølge presentasjonen å forberede til integrasjon av brukergrensesnitt. Lagmannsretten mener at presentasjon viser at behovet for å vise ACT- og TST-filene i CRM var kjent for IBM ved utgangen av løsningsbeskrivelsesfasen. Arbeidet omfattes av Leveransen og utgjør ikke noen endring. 4.4.4.6 Brukergrensesnitt

4.4.4.6.1 Innledning Gruppen «brukergrensesnitt» utgjør 14 av 58 brukerhistorier i EA053, og 503 DCUT-timer. Ti av brukerhistoriene har sammenheng med SVVs krav til kundebildet i SugarCRM. Disse brukerhistoriene

behandles i punkt 4.4.4.6.2 nedenfor. To av brukerhistoriene er knyttet til SVVs krav om implementering av økonomifunksjonalitet i SugarCRM («SAP-i-CRM»). Av praktiske grunner behandles disse sammen med åtte brukerhistorier i gruppen «økt kompleksitet» som også har tilknytning til tematikken «SAP-i-CRM», se punkt 4.4.4.7.2. En av brukerhistoriene er knyttet til brikkelogistikk og en gjelder fjerning av et brukergrensesnitt fra løsningen. Disse er behandlet sammen i punkt 4.4.4.6.3.

4.4.4.6.2 Endringer i kundebildet – «Ett stegs registrering» For ti brukerhistorier i gruppen «brukergrensesnitt» er IBMs endringskrav begrunnet med at SVV i løpet av konstruksjonsfasen endret kravene til kundebildet i SugarCRM (FU bilag 1354 linjer 15, 16, 19, 23, 24, 25, 26, 27, 43 og 73). Dette økte kompleksiteten i SugarCRM og førte til merarbeid med en rekke grensesnitt og ikkefunksjonelle krav i CRM. Kravet omfatter tiden og kostnadene forbundet med dette merarbeidet. Til sammen står disse brukerhistoriene for 414 DCUT-timer, hvorav 301 timer var utført på hevingstidspunktet. Lagmannsretten er enig med IBM i at arbeidet knyttet til disse brukerhistoriene er arbeid som faller utenfor Leveransen. Det var ikke stilt eksplisitte krav til kundebildet i Bilag A, men i løsningsbeskrivelsesfasen krevde SVV at registrering av en ny kunde og et nytt kundeforhold skulle kunne utføres fra bare ett skjermbilde.

Skjermbildet skulle utformes med samme struktur og feltrekkefølge som de papirbaserte brukeravtaleskjemaene som fortsatt var i bruk den gangen, jf. blant annet referat fra arbeidsmøte 21. januar 2014 hvor det under sak 2 om «registrere kunde» går frem at «feltrekkefølgen på registrering av avtale fra papirskjema må samsvare». Kravet ble omtalt som «one-step registration window» eller ett-stegs registreringsvindu. (FU 10702) Ett-stegs registreringsvindu ble av IBM identifisert som en endring ved utarbeidelse av løsningsbeskrivelsen og inntatt som endringspost CI_AM_06 i E0019 – Utvidelse av omfang CRM. (FU 12603 og bilag 1157, Fane EO019 CRM.Account, linje 6) Endringen er der beskrevet som «One Unified View for Customer Registration Process in Self Service and SugarCRM», og «An optimized view wherein registration is a one-stop process that stitches together customer, contact, address, contract and vehicle addition in one view». Ved gjennomgangen av løsningsbeskrivelsen var kontraktspartene enige om at denne funksjonaliteten måtte implementeres i løsningen. SVV bestred imidlertid at dette var en endring.

Lagmannsretten behøver ikke å ta stilling til om dette var en endring i løsningsbeskrivelsesfasen. Funksjonaliteten som er beskrevet i CI_AM_06 ble, sammen med en rekke andre anførte endringer, nedfelt i EO018-20 som ble signert som del av forliket ved HMP1. Funksjonaliteten var derfor uansett omfattet av Leveransen fra det tidspunktet. IBM har gjort gjeldende at kravet ut av løsningsbeskrivelsesfasen var at kunder og kundeopplysninger kunne registreres i ett kundebilde i CRM og Selvbetjening. Under konstruksjonsfasen kom det imidlertid krav fra brukerne om at alle kunderelaterte brukerhistorier skulle kunne utføres fra ett skjermbilde (kundebildet), dvs. både registrering, oppdatering og endring av kunderelaterte opplysninger, samt mer kompliserte brukerhistorier som overføring av brikker og sammenslåing av avtaler. Dette krevde betydelig skreddersøm av kundebildet. Staten har gjort gjeldende at SVV aldri har krevd dette, og at IBM uansett forpliktet seg til å levere denne funksjonaliteten gjennom CRM Brukergrensesnittspesifikasjonen som ble levert til godkjenning av HMP1.

Lagmannsretten ser først på hva IBM forpliktet seg til å levere ut av løsningsbeskrivelsesfasen. Bakgrunnen for funksjonaliteten og navnet som kontraktspartene ga til funksjonaliteten – «one-step registration» – taler for at den er begrenset til registrering av kundeopplysninger. Ordlyden i CI_AM_06, som er sitert over, taler for det samme. I CRM Brukergrensesnittspesifikasjon versjon 0.94, datert 23. mai 2014, punkt 3.2 går det imidlertid frem at «Kundevisninger (Customer View) vil bli tilpasset for å tillate Kundebehandler å opprette og håndtere en Kunde med Avtale, Kontaktinformasjon, Brikker og Kjøretøy i samme visning» (lagmannsrettens kursivering). (FU 12662 på 12694) Ordlyden kan tolkes slik at man fra kundebildet skulle kunne gjøre mer enn bare å registrere kundeopplysninger. Begrepet «opprette og håndtere» i CRM Brukergrensesnittspesifikasjon versjon 0.94 punkt 3.2 må imidlertid leses i sammenheng med innholdet i dokumentet for øvrig. Punkt 3.2 er et underpunkt i kapittel 3 om «Håndtering av kundeforhold (Customer Relation Management)» og har overskriften «Kunder».

Punkt 3.2 har flere underpunkter, og noen av disse har ytterligere underpunkter. Detaljeringsnivået øker for hvert underpunkt.

Underpunkt 3.2.2 har overskriften «Oppføringsvisning (Record View») og i punkt 3.2.2.1 er det tatt inn en helsides figur (prototype) av skjermbildet for privatkunder (Privatkunde Record View) (kundebildet). I innledningen til figuren står det at dette er «prototype på hvordan Privat Kjøretøyeier Visning vil se ut ved registrering av en Kunde med Avtale og Kontaktperson. En fullpris kunde vil vises og administreres i samme visning» (lagmannsrettens kursivering). Dette må etter lagmannsrettens syn forstås slik at skjermbildet for kunder skal benyttes til å registrere kunden og kundeopplysninger («Avtale og Kontaktperson»). Alle opplysninger som er registrert vil også vises i skjermbildet ved oppslag på kunden. Videre vil kunden administreres fra kundebildet. Det ligger imidlertid ikke i dette at avtale eller kontaktperson skal kunne administreres fra kundebildet. Prototypen for Privatkunde Record View som er tatt inn i underpunkt 3.2.2.1, underbygger at det kun er registrerte opplysninger om kunden som kan administreres fra kundebildet.

Prototypen viser at kundebildet består av en visning med en menylinje øverst med faner for de forskjellige modulene som inngår i SugarCRM: «accounts», «contacts», «reports», «cases», «kunder», «addresses», «contracts», «vehicles» og «assigned tag». At prototypen viser kundebildet, går frem av at fanen for «kunder» i menylinjen lyser hvitt mens de andre er svarte. Kundebildet består for øvrig av fire felter som ligger etter hverandre, og hvert felt korresponderer med en av modulene i menylinjen. Det øverste feltet viser grunnleggende opplysninger om kunden – (kundemodulen). Disse opplysningene skal det både registreres i og administreres fra kundebildet. Feltet under heter «kontakt» og korresponderer med kontaktmodulen i menylinjen. Feltet under heter «adresser» og korresponderer med adressemodulen. Det nederste feltet heter «Avtaler» og korresponderer med avtalemodulen. Feltet for «Avtaler» inneholder knapper for funksjonene «Legg til Avtale», «Legg til Brikke/Kjøretøy» og «Radera» (fjerne), som med all tydelighet viser at funksjonaliteten for å administrere avtaler ligger i avtalemodulen, og ikke i kundemodulen.

Feltet for «adresser» inneholder også en knapp for funksjonen «legg til adresse», som viser at funksjonaliteten for å administrere adresser ligger i adressemodulen og ikke i kundemodulen. Prototypen for Bedriftskunde Record View som er inntatt i underpunkt 3.2.2.2, inneholder de samme endringsknappene som prototypen for Privatkunde Record View. I innledningen til denne prototypen går det frem at «en fullpriskunde som er en bedrift vil vises og administreres i samme visning». Heller ikke her er det nevnt at avtale eller kontaktperson administreres fra kundebildet. SVVs presentasjon til et statusmøte med driftsselskapene 12. september 2014, underbygger etter lagmannsrettens syn at SVV var innforstått med at ett-stegs registreringsvindu var begrenset til registrering av kundeopplysninger. Arbeidsprosessen i ett-stegs registreringsvindu var oppgitt å omfatte «- registrere kunde med kontaktopplysninger, verifisere informasjon og unik postadresse; – opprette AutoPASS hovedavtale med avtaleopplysninger og merke avtale med brikkebehov; – registrere kjøretøy: verifisering og oppslag mot AutoSys avhengig av ferdigstilt tjeneste for dette».

(FU 15285 på 15297) Lagmannsretten mener etter dette at IBM i løsningsbeskrivelsen forpliktet seg til å levere ett-stegs registrering av ny kunde og nytt kundeforhold fra samme kundebilde. IBM forpliktet seg derimot ikke til å levere en løsning hvor alle opplysninger om en kunde og kundeforholdet, f.eks. avtale, kontaktinformasjon, brikker og kjøretøy, kunne administreres fra samme kundebilde. Spørsmålet er så om kravene til kundebildet ble endret i konstruksjonsfasen. I møte 1. juni 2015 om EA053 identifiserte IBM en rekke kunderelaterte brukerhistorier som SVV i løpet av konstruksjonsfasen hadde krevd implementert i kundebildet. (FU 24358 på 24365) Lagmannsretten er enig med staten i at det ikke er dokumentert noe uttrykkelig krav fra SVV om at disse brukerhistoriene skulle kunne utføres fra kundebildet. Lagmannsretten finner det imidlertid sannsynliggjort at det gjennom iterasjon 1 og iterasjon 2 var en klar forventning fra SVV og brukerne om at dette skulle kunne gjøres. Forventningen kom først til uttrykk etter at IBMs design på ett-stegs registreringsvindu ble presentert på demodagene fra 8. til 10. oktober 2014.

I oppsummeringen fra demodagene observerte SVV at brukerrepresentantene mente at løsningen var mindre effektiv enn dagjeldende løsning, som i motsetning til løsningen i Grindgut viste mye informasjon i ett skjermbilde. Brukerne var kritiske til at kundebehandler måtte bruke mus/tast for å klikke seg videre fra kundebildet for å få frem mer informasjon på forskjellige nivåer/områder. (FU 16391 og 16400) Brukernes observasjon er reflektert i A-2s rapport til KP1, hvor det går

frem at brukerne hadde uttrykt uro for at brukervennligheten i systemet, spesielt i CRM, ikke ble godt nok ivaretatt og at «bruken av systemet var et skritt tilbake for dem». (FU 16708 på 16713) Forventningen kom også til uttrykk i CRM-arbeidsmøter fra slutten av oktober 2014, hvor også bompengeselskapene deltok. Tonje Offenberg Bye har forklart at det i disse møtene kom tydelig frem at brukerne var misfornøyd med SugarCRMs modulbaserte løsning. De mente at den ikke var tilpasset deres hverdag og ønsket endringer som gjorde den likere dagjeldende løsning, herunder at alle kunderelaterte brukerhistorier skulle kunne utføres fra kundebildet. Bye har forklart at SVVs representant i arbeidsmøtene, Arve Leivestad, ikke gjorde noe forsøk på å nedjustere brukerrepresentantenes forventninger hva gjelder endringer i standardfunksjonaliteten. Dette underbygges av forklaringen fra Leivestad selv. På spørsmål fra IBMs prosessfullmektig om han noen gang satte foten ned for ønsker om tilpasninger fra brukerrepresentantene, svarte Leivestad at han ikke hadde noen konkrete eksempler på dette.

Han erindret at fokuset i arbeidsmøtene var å drøfte «løsningen som IBM skulle utvikle», og at de i møtene ikke diskuterte om det var spørsmål om tilpasning eller ikke. Hva gjelder muligheten til å utføre alle kunderelaterte brukerhistorier fra kundebildet, forklarte Leivestad at han oppfattet at denne funksjonaliteten var kravstilt ut av leveringsbeskrivelsesfasen. Som nevnt over mener lagmannsretten at dette ikke er riktig. Under enhver omstendighet er det på rene at SVV så det som nødvendig å kunne implementere de kunderelaterte brukerhistoriene som IBM hadde identifisert, i kundebildet, jf. over. Staten kan etter lagmannsrettens syn ikke høres med at SVV ikke har krevd denne funksjonaliteten. Lagmannsretten konkluderer etter dette med at SVVs krav til kundebildet i konstruksjonsfasen krevde mer enn forfining av det som var kravstilt i løsningsbeskrivelsen. SVV krevde skreddersøm. Det måtte i hovedsak mer skreddersøm til i brukergrensesnittet UC_AM_05 Ny Avtale og UC_AM_FO_01 Registrere FO Avtaleeier/Avtaleadministrasjon. (FU bilag 1354 linjer 43 og 73) Merarbeidet dette medførte, ga IBM krav om endring.

Med skreddersøm av kundebildet oppsto det behov for tilpasninger og konfigurering for å oppfylle en rekke ikke-funksjonelle krav som i utgangspunktet skulle leveres som standard i SugarCRM («out-of-the-box»). Kravet til hurtigtaster mv. (IF.13.04), kravet til brukertilpassede skjermbilder (IF.13.06), kravet til at nøkkelfelter skulle vises på alle tilhørende skjermbilder (IF.13.02) og kravet til mapping av roller i SugarCRM til funksjoner som knapper, menyvalg i moduler, paneler og subpaneler i visninger (IF.01.04) er eksempler på krav som utløste slike behov. Lagmannsretten mener at det ble stilt krav i konstruksjonsfasen som innebar tilpasninger og konfigurering som gikk langt utover det IBM måtte regne med som følge av at selskapet forpliktet seg til å levere ett-stegs registrering av ny kunde og nytt kundeforhold fra samme kundebilde etter løsningsbeskrivelsen. Kravene utløste merarbeid og økte kompleksiteten i de tilpasningene som måtte gjøres, jf. forklaringen fra Tonje Offenberg Bye og IBMs presentasjon til møte 1. juni 2015 om EA053.

(FU 24365) Brukerhistoriene i FU bilag 1354 linjer 15, 16, 19, 23, 24, 25, 26 og 27 gjelder merarbeid av denne art. Lagmannsretten konkluderer etter dette med at arbeidet med de ti brukerhistoriene i EA053 som er knyttet til SVVs krav til kundebildet, er arbeid som faller utenfor Leveransen og utgjør endringer.

4.4.4.6.3 Brikkelogistikk og fjerning av brukergrensesnittet «bomsnitt» For en av brukerhistoriene i gruppen «brukergrensnitt» er IBMs endringskrav begrunnet med at kravene til rapporter for brikkelogistikk var mangelfullt beskrevet i kravdokumentasjonen og løsningsbeskrivelsen, og at SVV kom med krav under konstruksjonsfasen som IBM ikke med rimelighet kunne ha forutsett. (FU bilag 1354 linje 40) Brukerhistorien står for 20 DCUT-timer, hvorav 19 timer (95 prosent) var utført på hevingstidspunktet. IBM har gjennom FU bilag 1354 gjort gjeldende at rapportspesifikasjonen (REP4000 Report Specifications – OBU logistics) ble utviklet i løsningsbeskrivelsesfasen basert på krav F.11.59, som stilte krav om at det skulle være mulig å generere rapport over «antall brikker klar for tildeling». (FU 8643) Rapportspesifikasjonen forutsatte at rapportene skulle leveres basert på standardløsningen med tilpasninger, med en grafisk fremstilling og detaljer per kjøretøy.

Under arbeidet med brikkelogistikk og behov i konstruksjonsfasen, kom det frem at enkelte av rapportene mest sannsynlig ikke var dekkende for hensikten med rapporteringen, som var å vise en potensiell backlogg ved tildeling av brikker. Det ble derfor flagget en endring i EA053. Merarbeidet besto i en redesign av rapporten for å vise en aggregert sum av brikker på vent (pending), og ikke individuelle

innslag/rader (kjøretøy) som ventet på tildeling. Dette krevde skreddersøm. Endringen ble loggført i februar 2015, og ytterligere en endring i spesifikasjonen ble utført i mars 2015. Linje 67 i FU bilag 1354 gjelder fjerning av brukergrensnittet UC_AM_ADM_11 Setup / Maintain Toll Slice (bomsnitt). Brukerhistorien står for seks DCUT-timer. Arbeidet var utført på hevingstidspunktet, og alle seks timene inngår i IBMs krav for fristforlengelse og vederlag. IBM har gjennom FU bilag 1354 gjort gjeldende at denne brukerhistorien ikke var en del av leveransen ved løsningsbekrivelsesfasen, men at den kom inn i datamodellen for CRM i august 2014. Dette underbygges av en sammenlikning av to versjoner av dokumentet Use Case Modell Kundeavtale. I versjon 0.95, som ble levert til løsningsbekrivelsesfasen, var «bomsnitt» ikke listet som en brukerhistorie i CRM-løsningen. (FU 13393) I versjon 2.4, som ble oppdatert 25. august 2014, ble UC_AM_ADM_11 tatt med.

(FU 15337 på 15405) IBM mente at brukergrensesnittet, som innebar at kundebehandlere kunne opprette og vedlikeholde ett eller flere bomsnitt for en bomstasjon, var en endring, og fremmet EA063 for merarbeid i form av dokumentasjon og design på det som i utgangspunktet var en standardløsning i SugarCRM. SVV mente at dette ikke var noen endring, og avviste EA063. I november 2014 bestemte SVV seg for at det likevel ikke var behov for funksjonaliteten knyttet til bomsnitt i SugarCRM, og brukergrensesnittet ble fjernet fra løsningen (FU 14764 på 14766). Gjennom EA053 har IBM krevd dekket seks timer for merarbeidet med å fjerne UC_AM_ADM_11 fra løsningen. Staten har ikke behandlet disse to brukerhistoriene. Tingretten kom til at alle brukerhistoriene i gruppen «brukergrensesnitt», herunder linjene 40 og 67, utgjorde endringer. Da det ikke er kommet anførsler eller bevis som gir lagmannsretten grunnlag for å overprøve tingrettens vurdering, legger lagmannsretten tingrettens vurdering til grunn, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd. 4.4.4.7 Økt kompleksitet

4.4.4.7.1 Innledning Gruppen «økt kompleksitet» utgjør 20 av 58 brukerhistorier i EA053 og 1 080 DCUT-timer. Endringskravet er fra IBMs side begrunnet med at kompleksiteten i brukerhistoriene økte under konstruksjonsfasen og gikk utover det som IBM med rimelighet kunne forutse ut av løsningsbeskrivelsesfasen. Bakgrunnen var dels at SVVs krav var mangelfullt beskrevet i kravdokumentasjonen og løsningsbeskrivelsen, og dels at SVV kom med nye krav til eksisterende elementer. Lagmannsretten mener at økt kompleksitet i prinsippet kan gi grunnlag for en endringsanmodning i en kontrakt basert på PS2000. Det vises til det som er skrevet i punkt 4.4.3.3 om at kontraktstandarden bygger på at de mer detaljerte spesifikasjonene for leveransen skal utarbeides underveis, både i løsningsbeskrivelsesfasen og i konstruksjonsfasen. Kravene blir altså ikke «låst» i løsningsbeskrivelsesfasen, men skal kunne endres og detaljeres ytterligere i samarbeid mellom partene og kundens brukergruppe. Kravene slik de er stilt ut av løsningsbeskrivelsesfasen, danner likevel grunnlaget for leverandørens estimering av tid og kost.

Hvor kravene endres, eller nye krav kommer til, er det på det rene at leverandøren kan kreve endring. Det samme må også gjelde der kravene detaljeres og blir mer komplekse enn det leverandøren med rimelighet kunne forvente. Utfordringen er å skille mellom den detaljeringen som ligger innenfor det leverandøren med rimelighet måtte forvente ut fra det kravet som er fastsatt, og det som ligger utenfor. SVV syntes også å mene at økt kompleksitet i prinsippet kan gi grunnlag for endring. I forbindelse med behandlingen av EA027 og EA030 under løsningsbeskrivelsesfasen, aksepterte SVV å ta noe av kostnaden «siden kompleksiteten i prosessen som skal håndteres er høyere enn IBM kunne forutse». (FU bilag 1157) Det samme må etter lagmannsrettens syn gjelder i konstruksjonsfasen. Hva gjelder de enkelte brukerhistoriene i gruppen «økt kompleksitet», er 20 brukerhistorier knyttet til SVVs krav om implementering av økonomifunksjonalitet i SugarCRM («SAP-i-CRM»). Det samme gjelder to av brukerhistoriene i gruppen «brukergrensesnitt», jf. punkt 4.4.4.6.1 over. Lagmannsretten behandler disse brukerhistoriene samlet i punkt 4.4.4.7.2.

Den største enkelte brukerhistorien i gruppen «økt kompleksitet» gjelder UC_CM_03 (Håndtere sak), og er behandlet i punkt 4.4.4.7.3. De andre «store» brukerhistoriene i

denne gruppen – UC_AM_05 (Ny avtale) og UC_AM_ADM_13 (Bompakke) – er behandlet i henholdsvis punkt 4.4.4.7.4 og 4.4.4.7.5. Fire av brukerhistoriene har sammenheng med brikkelogistikk og behandles i punkt 4.4.4.7.6. De øvrige brukerhistoriene behandles samlet i punkt 4.4.4.7.7.

4.4.4.7.2 «SAP i CRM» – Merarbeid på grunn av økt kompleksitet i tilknytning til EA018 Åtte av brukerhistoriene i gruppen «økt kompleksitet» har sammenheng med implementeringen av økonomifunksjonalitet i CRM. Disse brukerhistoriene (FU bilag 1354 linjer 14, 29, 37, 85, 86, 87, 88 og 90) utgjør til sammen 364 DCUT-timer, hvorav 230 timer var utført på hevingstidspunktet. To av brukerhistoriene i gruppen «brukergrensesnitt», jf. punkt 4.4.4.6 over, er også knyttet til implementering av økonomifunksjonalitet i SugarCRM (FU bilag 1354 linjer 12 og 83) og behandles også her. Disse står for 63 DCUT-timer, hvorav 41 timer var utført på hevingstidspunktet. Før lagmannsretten behandler de aktuelle brukerhistoriene, gjør den rede for sin vurdering av saksforholdet rundt implementeringen av økonomifunksjonalitet i SugarCRM. IBMs tilbudte løsning – RUC – var en modulbasert løsning sammensatt av ulike komponenter med brukergrensesnitt for de ulike brukergruppene, blant annet SugarCRM for kunde- og saksbehandling og SAP FI-CA for økonomimedarbeidere.

I IBMs svar på krav GK.01.07 Standardisering av Arbeidsprosesser, går det frem at løsningen skulle bruke standardprosesser i SAP og SugarCRM, med konfigurering i SugarCRM for å tilpasse saksbehandlingen til bompengesammenheng. (FU 4540) I IBMs svar på krav IF.01.04 går det frem at tilgangen til løsningen var knyttet til roller. (FU 4483) I IBMs svar på krav IF.13.01 (Skjermbildelayout), går det frem at SugarCRM og SAP-FICA hadde hvert sitt eget brukergrensesnitt, og at det var et skille mellom kundebehandlere, økonomimedarbeidere og andre brukerroller. Om økonomiløsningen heter det: Standardløsningen SAP FI-CA benyttes for økonomifunksjonene. De rollene som skal administrere økonomi vil benytte SAP brukergrensesnitt. Skjermbildene i SAP er utviklet iht SAP sine standarder, og designet for effektiv bruk til sitt formål. Harmonisering av dette brukergrensesnittet er begrenset til økonomifunksjonene. Øvrige interne brukerroller vil ikke benytte SAP bildene. Der kundebehandling har bruk for å se på økonomidata ifm med enkeltavtaler, vises dette internt i brukergrensesnitt for kundebehandling. (Lagmannsrettens kursivering).

(FU 8749) Den tilbudte løsningen innebar at kundebehandlere og økonomimedarbeidere skulle arbeide i hver sin applikasjon – kundebehandlere i SugarCRM og økonomimedarbeidere i SAP FI-CA. Gjennom en integrasjon med SugarCRM skulle kundebehandlere kunne se økonomiske data i SugarCRM, men ikke forvalte dem. Hvis kundebehandlere skulle endre økonomiske data eller utføre andre økonomifunksjoner, måtte de bruke SAP FICA. Gjennom aksept av IBMs tilbud, aksepterte SVV denne modul- og rollebaserte løsningen. SVV hadde i Bilag A (behovsanalysen) beskrevet at den største delen av saksbehandlingen som kundebehandlere gjorde, knyttet seg til klager på faktura og tilleggsavgifter. Det gikk også frem at kundebehandlere skulle kunne korrigere feilaktig belastede passeringer. Under beskrivelsen av «kundehenvendelser», under overskriften «utføre saksbehandling» står det: Formål med prosessen [utføre saksbehandling] er å sikre at saksbehandlingen blir utført på en ensartet og effektiv måte. Den største delen av saksbehandlingen er knyttet til klage på faktura og tilleggsavgifter for kunde uten gyldig avtale.

Ved klage på faktura vil saksbehandler gjøre oppslag på relevant data for aktuell klage. Det kan for eksempel være passeringsinformasjon, bilder, avtaleforhold, faktura- og innbetalingsinformasjon mm. Eksempel på klage på faktura er ved opplevd feilaktig belastet passering(er) f.eks. i forbindelse ved solgt kjøretøy. Ved medhold i denne type saker/klager vil det være behov for at passering(er) som er belastet/fakturert en avtale skal kunne krediteres, korrigeres og belastes en annen avtale eller faktureres som fullpris til kjøretøyeier. (FU 8511) I kravtabellen over funksjonelle krav i Bilag A var det stilt krav til økonomifunksjonalitet i F.07 Fakturering og F.08 Innbetaling. (FU 8611 og 8616) I tilbudet beskrev IBM at fakturering og innbetaling skulle håndteres i SAP FI-CA. (FU 4433 og 4449) I vedlegget til kravtabellen går det frem at økonomiløsningen (SAP FI-CA) hadde «en standard intern grensesnitt mot løsning for saksbehandling». (FU 8663) Det heter videre:

Gjennom denne integrasjonen vil endringer som er foretatt i fakturagrunnlaget oppdateres i Økonomiløsningen. Saksbehandleren som foretar rettelser av denne typen i saksbehandlingsløsningen må være satt opp med de nødvendige rettigheter for å kunne gjennomføre disse endringer. Ved å akseptere IBMs tilbud, aksepterte SVV dette. F.09 Kundehenvendelser inneholdt enkelte funksjonelle krav som forutsatte at kundebehandlere skulle ha tilgang til økonomifunksjonalitet. F.09.18 krevde at det skulle være mulig for kundebehandlere ved kundehenvendelser «å utsette betalingskrav under saksbehandlingstiden». F.09.21 krevde at kundebehandlere skulle kunne korrigere feilaktig belastede passeringer, og F.09.22 krevde at kundebehandlere skulle kunne «endre registreringsnummer på et valgt bilde» og behandle passeringen på nytt. (FU 8623) Det går frem av dokumentet «Prosessbeskrivelser Kundehenvendelser v.0.9», utarbeidet av IBM under løsningsbeskrivelsesfasen, at IBM var innforstått med og aksepterte at økonomifunksjonaliteten som var kravstilt i F.09, skulle implementeres i SugarCRM.

(FU 11578 på 11588) Behovsanalysen beskrev ikke annen økonomifunksjonalitet som kundebehandlere skulle kunne endre. Staten har vist til at behovsanalysen to steder stiller krav om et «enhetlig brukergrensesnitt». I punkt 2.2. om «Generelle krav» i innledningen til Bilag A, heter det: Selv om det ikke fremgår eksplisitt av Bilag A, er det en forutsetning at Løsningsbeskrivelsen utarbeides og videre at komponentene utvikles og tilpasses slik at Leveransen fremstår for Kunden som en helhet, med et enhetlig og konsistent brukergrensesnitt. (FU 8489) Og i kravtabellen for ikke-funksjonelle krav er det i krav IF.01 om Brukskvalitet, stilt følgende krav til brukergrensesnittet: IF.01.03 Brukergrensesnitt Løsningens brukergrensesnitt / brukerinteraksjon skal utformes slik at den understøtter arbeidsprosesser på en effektiv måte og sikre god ergonomi. (FU 8683) Staten har under henvisning til Bilag A kapitel 2.2 og IF.01 gjort gjeldende at SVV stilte krav i kontrakten om at kundebehandlere både kunne lese og endre økonomiske data fra «deres» brukergrensesnitt (SugarCRM). Lagmannsretten er ikke enig i dette.

Lagmannsretten mener at det er vanskelig å lese noen konkrete rettigheter eller forpliktelser ut av det som står om generelle krav i innledningen til Bilag A. Dette gjelder særlig i betraktning av at det ved innledningen til kravtabellen over ikke-funksjonelle krav går frem at tabellen lister «alle generelle krav til løsningen». (FU 8682) Det er i tabellen ikke stilt noen krav til brukergrensesnittet. Hva gjelder IF.01.03, viste IBM i sitt svar til at «de prosessene som har med kundebehandling, logistikk, rapportering og finans å gjøre benytter standardisert programvare og brukergrensesnitt som er optimalisert for å understøtte de arbeidsprosessene som kreves av løsningen». (FU 8727) Lagmannsretten mener at «de arbeidsprosessene som kreves av løsningen», må begrenses til de arbeidsprosessene som var identifisert i behovsanalysen, jf. ovenfor. Hvis SVV mente at kundebehandlere måtte kunne se og endre annen økonomisk data enn dette, måtte de ha stilt uttrykkelig krav om dette.

I arbeidsmøtene som ble avholdt under løsningsbeskrivelsesfasen kom det frem ønsker om å implementere mer økonomifunksjonalitet i SugarCRM enn det som var kravstilt i F.09, slik at kundebehandlere ikke behøvde å gå inn i SAP FI-CA for å utføre økonomifunksjoner. I dokumentet «Prosessbeskrivelser Kundehenvendelser» versjon 0.9 datert 7. mars 2014, presiserte IBM at implementering av denne funksjonaliteten ville bli lagt frem som et forslag i en endringsanmodning (EA018). (FU 11578 på 11581, 11588 og 11589) Lagmannsretten forstår dette slik at kontraktspartene ble enige om at dette var endringer. Implementering av mer økonomifunksjonalitet i SugarCRM («SAP-i-CRM») ble i hvert fall under henvisning til EA018, bestilt i EO018-20 som ble signert som del av forliket ved HMP1. I dokumentet «Use Case-modell Kundehenvendelser» versjon 0.95, som ble godkjent av SVV ved HMP1, går det frem at endringen gjaldt implementering av følgende økonomifunksjonalitet i SugarCRM:

• Trigge generering av ny faktura
• Trigge generering av kreditnota, uavhengig av nytt fakturagrunnlag
• Fryse fakturaløp
• Stoppe fakturaløp, gjelder også purringer
• Sende varsel om f.eks. saldo, utstedt faktura, forfalt faktura
• Sende ut fakturakopi
• Se status på en faktura (purret, 2. gangs purring, sendt inkasso)
• Se tekstfeltene (masterdata) som er lagt til i SAP til de enkelte aktivitetene for en faktura
• Se saldo per avtale, eventuelt mot en lavterskel for faktura
• Se alle transaksjoner, all historikk
• Samlefaktura (TU2 1147 på 1154) Lagmannsretten forstår det slik at all denne økonomifunksjonaliteten er standard i SAP-FICA, men at det krevde skreddersøm å implementere den i SugarCRM.

Partene har bare vært inne på noen av brukerhistoriene i EA053 som har sammenheng med implementering av økonomifunksjonalitet i SugarCRM. IBM har i stor grad vist til tingrettens vurdering om at brukerhistoriene utgjorde endringer. Staten har vist til at økonomifunksjonalitet i CRM ble bestilt som en endring ved HMP1, og at IBM ikke kan kreve mer tid og penger for at IBM da ikke analyserte konsekvensen av endringen godt nok. Lagmannsretten er enig med staten i at IBM som utgangspunkt må bære risikoen for sine egne eventuelle feilestimeringer. Konsekvensene av å bygge økonomifunksjonalitet inn i SugarCRM som IBM ikke med rimelighet kunne ha forutsett ut av løsningsbeskrivelsesfasen, må imidlertid kunne danne grunnlag for endring. Lagmannsretten mener at det i denne sammenhengen må sees hen til at det å bygge økonomifunksjonalitet inn i SugarCRM, representerte et grunnleggende avvik fra IBMs modulbaserte løsning og innebar å redesigne og skreddersy det som i utgangspunktet var standard brukergrensesnitt mellom SAP FI-CA og SugarCRM.

Slik lagmannsretten ser det, ville det på grunn av avhengigheter i systemet og mengden gjenstående detaljdesign, vært bortimot umulig i løsningsbeskrivelsesfasen å overskue og estimere alle konsekvensene av dette. Først når redesignet var ferdig, ville man få den fulle oversikten over konsekvensene av all skreddersøm som måtte til. Brukerhistorien I_CRM_FICA_213-C Innhente sist brukt bankkontonummer, er etter lagmannsrettens syn et eksempel på at det ikke var mulig for IBM å forutse konsekvensen av endringen som ble avtalt ut av løsningsbeskrivelsesfasen. (FU bilag 1354 linje 12) Visning av sist brukte bankkontonummer var ikke kravstilt i Bilag A, men ble inkludert i «SAP-i-CRM»funksjonalitet i EO018-20. IBM har ikke krevd endring for å implementere denne funksjonaliteten i SugarCRM.

Endringskravet i EA053 er begrunnet med at IBM, basert på erfaringene med skreddersøm av Kundebildet og ett-stegs registrering (se punkt 4.4.4.6.2 over), antok at kompleksiteten i CRM-løsningen ville øke fordi SVV ville ønske at sist brukte bankkontonummer ikke bare skulle kunne vises i SugarCRM, men at det også skulle kunne utføres kommandofunksjoner (for eksempel endringer) på sist brukte bankkontonummer fra SugarCRM. Tonje Offenberg Bye har forklart at det kom slike krav da arbeidspakken ble levert, og det er ikke bestridt. Slik lagmannsretten ser det, var dette noe som IBM ikke med rimelighet kunne ha forutsett ved estimeringen ut av løsningsbeskrivelsesfasen.

I tillegg kom det krav fra SVV i arbeidsmøte om at «sist brukt bankkontonummer» ble tatt med som mulig søkekriteria i brukerhistorien UC_AM_18 Search & View Customer, jf. referat fra arbeidsmøte 20. november 2014. (FU 17343 på 17347) SVV mente at dette ikke var en endring, men fulgte av krav F.01.07 i Bilag A om at «det skal være mulig å utføre kundesøk basert på alle opplysninger knyttet til en kunde. F.eks. navn, kundenummer, registreringsnummer på kjøretøy, brikkenummer, fakturanummer og lignende». IBMs tilbudte løsning bygde på SugarCRMs standard søk-funksjonalitet uten tilpasninger. (FU 8586) Det å legge til sist brukte bankkontonummer som søkekriteria, krevde skreddersøm. Ved utgangen av løsningsbeskrivelsesfasen var «sist brukte bankkontonummer» som søkekriteria, ikke definert som en del av UC_AM_18. Konsekvensen av at økonomifunksjonalitet ble lagt inn i SugarCRM, var imidlertid at «sist brukte bankkontonummer» ble knyttet til en kunde i SugarCRM.

Lagmannsretten er enig med staten i at «sist brukt bankkontonummer» da strengt tatt kom inn under F.01.07, men mener at IBM ikke kan lastes for at selskapet i løsningsbeskrivelsesfasen ikke estimerte for skreddersømmen dette medførte. Dette var etter lagmannsrettens

syn økt kompleksitet som ble påvist av detaljdesign og som IBM ikke med rimelighet kunne forutse. Dette må gi grunnlag for endring. For lagmannsretten ser det ut til at også SVV mente at implementeringen av økonomifunksjonaliteten i SugarCRM økte kompleksiteten i løsningen betraktelig, og at ingen av kontraktspartene hadde full oversikt over hva denne implementeringen innebar. I prosjektmøtet 5. mars 2015 uttrykte SVV bekymring for at man «utvikler mye i CRM nå, som SAP ivaretar». (FU 20813 på 20816) SVV ved Anne-Marie Ytrehus oppsummerte bekymringen på følgende måte i e-post samme dag til IBM ved Terje Harangen, med overskrift «SAP, CRM og økonomifunksjoner i kundebehandling»: CRM-utviklingen er etter sigende «på kritisk linje» i prosjektet. Vi (og flere i IBM sitt team) ser noen åpenbare grep som kan gjøres for få ned omfanget av utviklingen innen CRM, og som også forenkler løsningen og øker sikkerhet, sporbarhet og datakonsistens, og reduserer risikoen for feil. Saksbehandlerne som skal bruke løsningen har behov for å bruke mange økonomifunksjoner, som i dag ligger i SAP, som f.eks

• Faktura: Vise, endre, lage kopi ++
• Passeringer: søk, endre, verifisere, kreditere, reprosessere
• Inkasso: Hele prosessen
• Innbetaling: Oppfølging av innbetaling
• Endring av betalingsopplysninger Vårt inntrykk er at en del av denne SAP-funksjonaliteten (med tilhørende data) nå bygges inn i CRMløsningen, – dvs at man bygger en «SAP light» inn i Sugar CRM. SVV stiller spørsmål ved dette, – da løsningen jo nettopp skal bygge på de forskjellige modulenes særtrekk og styrker. Vi tror heller ikke IBM har spesiell kompetanse til å gjøre dette. Det er helt sikkert at denne tilnærmingen øker faren for feil og inkonsistenser i løsningen, og skaper uforutsigbarhet for datakvalitet og andre konsekvenser hvis en feil først oppstår «et-eller-annet-sted» i løsningen.

Vårt forslag (som vi vet at støttes av flere i IBM sitt team) er å konsentrere arbeidet om å lage gode interfacer direkte mot SAP. Det finnes flere alternative måter å gjøre dette på, og dette er mye enklere (og raskere!) enn å fortsette det vi oppfatter at er dagens praksis (skreddersøm i CRM). IBM har personer i sitt team som har kompetanse til å få gjort dette.

Vi som kunde ønsker selvsagt at IBM skal unngå å bygge en «SAP light» inn i Sugar CRM så langt det er mulig.

Vi er opptatt av at løsningen skal være enklest mulig å vedlikeholde, – også ved oppgraderinger av SAP eller Sugar CRM til nyere versjoner.

Vi ber deg gjøre de vurderingene du mener er fornuftig ift dette, og komme med en tilbakemelding til oss, – senest i PL-møte (onsdag 11. mars). (FU 20908) Alt unntatt de tre siste avsnittene i e-posten ble også tatt med i SVVs statusrapport for delprosjektet Leveranse for februar 2015 med overskriften «Faglig dårlig valg av løsning-arkitektur skaper forsinkelser i CRM». (FU 19861 på 19875) Lagmannsretten mener at kritikken som SVV rettet mot IBM, var uberettiget og i beste fall berodde på en misforståelse, i det den overser at det var SVV som i løsningsbeskrivelsesfasen stilte krav om at IBM bygde en «SAP-light» inn i SugarCRM.

I referatet fra prosjektmøtet 11. mars 2015 går det frem at IBM oppfattet at diskusjonene med SVV ble drevet «i retning av behov for å se fåtalls skjermbilder, og lite interesse ift å bytte mellom SAP og CRM», mens SVV mente at det var «IBM sitt ansvar å påpeke dette» i arbeidsmøter. (FU 21103 på 21105) Også i referatet fra KGmøtet 17. mars 2015 går det frem at SVV mente at IBM hadde «valgt en løsningsstrategi som bygger for mye funksjonalitet som allerede ligger i SAP inn i CRM». (FU 21286 på 21289) Igjen synes SVV å overse at det var SVV som hadde stilt krav om mer økonomifunksjonalitet nettopp for at kundebehandlere skulle slippe å benytte SAP FI-CA.

Diskusjonen rundt «SAP-i-CRM» fortsatte utover våren 2015. Av referatet fra prosjektmøtet 6. mai 2015 går det frem at IBM fortsatt var «forvirret ift hva SVV ønsker» hva gjelder «Sugar CRM vs CRM i SAP». (FU 23478) I mai 2015 utstedte SVV EA102. (FU 23722) SVV ba her IBM om å analysere en «alternativ metode for å gjøre SAP-relatert funksjonalitet tilgjengelig for relevante kundeservice-roller». Så vidt lagmannsrettens forstår var dette ikke utredet på hevingstidspunktet. I sum mener lagmannsretten at implementeringen av økonomifunksjonaliteten i SugarCRM økte kompleksiteten utover det IBM med rimelighet kunne forutse. Arbeidet som er beskrevet i de ti brukerhistoriene i EA053 som er knyttet til implementering av økonomifunksjonalitet i SugarCRM, faller utenfor Leveransen og utgjør endringer.

4.4.4.7.3 Brukerhistorien UC_CM_03 (Håndtere sak) Den største enkelte brukerhistorien i gruppen «økt kompleksitet» er UC_CM_03 (Håndtere sak). (FU bilag 1354 linje 81) Den utgjør 170 DCUT-timer og litt i underkant av 16 prosent av kravet i denne gruppen. Samtlige timer var utført på hevingstidspunktet. Tingretten skrev om denne brukerhistorien i dommen på side 67: Alle henvendelser til bompengeselskapene ble registrert som en sak. For å lette oversikt og administrasjon av sakene skulle hver sak ha en status (som sa noe om hvor i prosessen saken var) og en sakstype (som sa noe om hva slags sak det var). Dette kravet er relativt generelt formulert i behovsanalysen (FU 8510): Saksbehandlingen må dekkes på en slik måte at det enkelte bompengeselskap til en hver tid har en god oversikt over innmeldte saker, pågående saker og avsluttede saker. Senere, under overskriften «Motta henvendelse» (FU 8511): Formål med prosessen er å sikre at alle henvendelser blir gruppert til riktig sakstype.

Henvendelser kan være alt fra generelle spørsmål om at brikken ikke fungerer, oppsigelse av avtale, bytte av bil, endring av bilnummer etc. til klage på faktura. Henvendelser kan komme fra ulike kanaler I LBF ble brukerhistoriene for saksbehandling dokumentert i «Use Case Model Case Management» (TU2239). Av brukerhistorien UC_CM_01 (Create case) fremkommer det at løsningen skal fange opp informasjon om blant annet sakstype og status (TU2249). Brukerhistorien UC_AM_03 beskriver hvordan brukerne arbeider med saker, herunder oppdatering av status. Prosessene er detaljert i dokumentet «Process Definitions Case Management» (TU1809). Her står det at feltene vil bli detaljert nærmere i KF (TU1818). Workshopen i iterasjon 2 resulterte i svært komplekse krav til status og sakstype (Dok84 Bilag 1354, linje 81): [Brukerhistorien] endte opp med 2 nivåer av sakstyper, 6 hovedtyper med 0-6 undertyper (tidligere 1 nivå), og 4 statuser hvorav status 'På vent' hadde egne årsakskoder og 'Lukket' egne løsningskoder (tidligere 3).

Totalt sett var denne løsningen og tilhørende regler for gyldige overganger mellom disse mer kompleks enn opprinnelig forutsatt. Statusoverganger er ikke

OOTB.

Retten er enig med IBM at dette var en endring. Partene har ikke behandlet denne brukerhistorien særskilt i sine fremstillinger og prosedyrer under ankeforhandlingen. Det er således ikke kommet anførsler eller bevis som gir lagmannsretten grunnlag for å overprøve tingrettens vurdering. Lagmannsretten legger til grunn tingrettens vurdering om at økningen i kompleksiteten i brukerhistorien UC_CM_03 (Håndtere sak), var en endring, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd.

4.4.4.7.4 Brukerhistorien UC_AM_05 (Ny avtale)

Brukerhistorien UC_AM_05 (Ny avtale) (FU bilag 1354 linje 42) står for 160 DCUT-timer og utgjør litt i underkant av 15 prosent av kravet i gruppen «økt kompleksitet». Samtlige timer var utført på hevingstidspunktet. IBM har gjort gjeldende – og det er heller ikke bestridt – at basisflyten i UC_AM_05 (Ny avtale) besto av 47 enkeltsteg ved utgangen av løsningsbekrivelsesfasen. Det var knyttet ca. 14 forretningsregler til brukerhistorien på dette tidspunktet. Lagmannsretten forstår det slik at brukerhistorien ikke endret seg mer i iterasjon 1 enn det IBM med rimelighet kunne forutse. I iterasjon 2 kom det imidlertid krav fra SVV som førte til at antall steg i basisflyten økte til 61, og at antallet forretningsregler steg til ca. 42. For eksempel var det i steg 4 per 17. september 2014 beskrevet at bruker skulle velge bomanlegg for ny avtale fra en bruttoliste over bomanlegg. (FU 15412 på 15434) Dette var standardløsningen i SugarCRM. I CRMarbeidsmøte 27. november 2014 krevde SVV at brukeren bare skulle få opp de bompakkene som var tilgjengelig til bomselskapet man ønsket å opprette ny avtale hos, og ikke en bruttoliste.

(FU 17553 på 17558) At dette ble tatt inn i brukerhistorien, går frem ved å sammenligne versjon 2.11 datert 17. september 2014 og versjon 2.44 datert 16. desember 2014 av dokumentet Use Case Model Account Management. (FU 15412 på 15434 og FU 18251 på 18278) Et annet eksempel er at det i steg 7 per 17. september 2014, var beskrevet at brukeren ved registrering av ny tilleggsavtale skulle skrive inn et eksisterende brikkenummer (OBU) og få beskjed om dette var gyldig eller ikke. (FU 15434) I CRM-møte 11. november 2014 om tilleggsavtale stilte SVV krav om søk-mens-du-skriver funksjonalitet, og at aktuelle brikkenumre skulle vises når brukeren begynte å skrive inn. (FU 18058 på 18060) At dette ble tatt inn i brukerhistorien, går frem ved å sammenligne versjon 2.11 datert 17. september 2014 med versjon 2.44 datert 16. desember 2014 av dokumentet Use Case Model Account Management.

(FU 15412 på 15434 og FU 18251 på 18278) Et tredje eksempel er at det i steg 11 per 17. september 2014, var forutsatt at systemet skulle avgjøre om et kjøretøy kvalifiserte for et fritak ved å anvende forretningsregelen for fritatte kjøretøy, og fastsette tidsvinduet for fritaket. (FU 15412 på 15434) På dette tidspunktet var det eneste kjente tidsbestemte fritaket, fritak for bevegelseshemmede (HC-kort), som var kravstilt i krav F.01.33. (FU 8591) Som nevnt i punkt 4.4.4.4 over, ble forretningsreglene for fritak endret og utvidet utover høsten 2014. I og med at forretningsreglene for fritak ble mer kompliserte, ble også brukerhistorien mer komplisert da flere fritak skulle implementeres. I dokumentet Use Case Model Account Management versjon 2.44, datert 16. desember 2014, går det frem at det i tillegg var kommet til ytterligere krav til fritak. (FU 18251 på 18279) Lagmannsretten mener at de nye kravene og nye forretningsreglene innebar en detaljering som gikk utover det IBM med rimelighet kunne forutse ved utgangen av løsningsbeskrivelsesfasen.

Arbeidet som beskrevet i FU bilag 1354 linje 42 angående brukerhistorien UC_AM_05 (Ny avtale) faller utenfor Leveransen og utgjør en endring.

4.4.4.7.5 Brukerhistorien UC_AM_ADM_13 (Bompakke) Brukerhistoriene UC_AM_ADM_13 (Opprette/vedlikeholde Bompakke) og UC_AM_ADM_14 (Opprette/vedlikeholde Avtalekontorabatt) i FU bilag 1354 linjer 69 og 70 henger sammen, og utgjør 154 DCUT-timer, eller ca. 14 prosent av kravet i gruppen «økt kompleksitet». Samtlige timer var utført på hevingstidspunktet. Med «bompakke» menes en rabattordning på tvers av et bompengeprosjekt. I november 2014 ble det oppdaget behov for funksjonalitet som tillot at en kunde kunne inngå flere avtaler med samme bompengeselskap for å kunne få rabatt i alle anleggene til vedkommende bompengeselskap. Dette medførte behov for å kunne ha flere bompakker per selskap. Funksjonaliteten var ikke kravstilt i Bilag A. IBM utstedte 13. januar 2015 EA047 og SVV utstedte 21. januar 2015 EO044. (FU 19360 og 19575) Det er økt kompleksitet utover EA047/EO044 som danner grunnlag for IBMs krav. Lagmannsretten mener at kompleksiteten i brukerhistoriene økte utover det som var kravstilt i EO044. Tonje Offenberg Bye forklarte at mens fem brukerhistorier for området Kundeavtale var berørt av endringen ved

iterasjon 2, var ti brukerhistorier berørt på hevingstidspunktet. I tillegg gikk det mer tid og penger enn estimert på grunn av endringer i forretningsregler knyttet til denne brukerhistorien. At kompleksiteten økte synes ikke å være bestridt. Staten mener imidlertid at IBM må bære ansvaret for dette fordi det skyldes at IBM ikke analyserte konsekvensene av endringen godt nok. Lagmannsretten er ikke enig i at IBM må bære ansvaret for at kompleksiteten økte utover EA047/EO044. IBM flagget behovet for en endring så snart behovet for ny funksjonalitet ble oppdaget i begynnelsen av november 2014. Den 5. november 2014 var det et møte hos SVV mellom IBM, SVV og en rekke representanter fra bompengeselskapene. Formålet med møtet var å drøfte «redesign of the Multi-tenancy/Contract model» som følge av den nye funksjonaliteten.

Etter møtet sendte IBM ved Tonje Offenberg Bye en e-post med møtereferat til møtedeltakerne med en beskrivelse av den foreløpige beslutningen om å implementere funksjonaliteten, en liste over forretningsreglene man i møtet hadde kommet frem til skulle gjelde, og en kort beskrivelse av innvirkningen (impact) som endringen ville ha for løsningen for øvrig. Hun ba samtidig om nødvendig aksept og godkjenning for å implementere redesignet. (FU 16900) Gunilla Stüssi, som var utleid fra Fjellinjen til SVV, ba deltakerne fra SVV og bompengeselskapene om å bekrefte at innholdet i e-posten stemte med det som ble drøftet i møtet. (FU 16921) Stüssi meldte tilbake til Tonje Offenberg Bye at hun hadde behov for noen avklaringer med SVVs informasjonsarkitekt, Mihaly Fekete, som hun forventet neste dag. Det kom imidlertid aldri noen merknader eller innsigelser fra SVV eller fra bompengeselskapene, og IBMs redesign ble derfor basert på innholdet i møtereferatet.

Det hastet å implementere endringen i funksjonalitet knyttet til bompakke da dette var kritisk for å sikre stabilitet i løsningens logisk datamodell og for å unngå forsinkelser i migreringsplanen. I et internt notat fra november/desember 2014 skrev Tonje Offenberg Bye: [...] Since no objections or disapproval were received, CRM team lead & Gunilla Stussi decided not to wait any longer, but ask GD to further implement this change immediately, affecting firstly the LDM, UC specs and CRM UI design. This decision was made to ensure critical functionality in CRM/SEL, data quality in SAP, a stable LDM to support MIG and overall Master Data Management throughout the solution and was a verbal agreement between G.Stussi & T.Bye. To wait for a formal Change Request process to come through would have jeopardized the It2 timeline and put several team’s progress at risk, or worse, It2 would have been delivered without this critical aspect of the Toll Entities configuration and resulted in an LDM not being stable regarding core configuration elements which is on the critical path for MIG.

This would also have made the change more costly to develop at a later stage. (FU18017) IBM ved Nicolai Rygh formidlet dette til SVV ved Arve Ryan 9. desember 2014, samtidig som han ba Ryan om å gjøre «en vurdering om funksjonaliteten skal reverseres, eller om dere ønsker å endringshåndtere dette». (FU 18017) Lagmannsretten legger til grunn at Arve Ryan var kjent med redesignet helt fra starten av siden han deltok i møtet 5. november 2014 og mottok referatet fra møtet. Den 9. desember 2014 utstedte IBM en intern endringsordre overfor GD India basert på det som kom frem i møtet 5. november 2014. IBM ved Nicolai Rygh sendte en kopi av den interne endringsordren til SVV ved Arve Ryan og ba igjen SVV om å opprette en endringsanmodning hvis vegvesenet ønsket funksjonaliteten (FU 18027). SVV gjorde ikke det, og IBM utstedte selv en endringsanmodning (EA047 Bompakke) 13. januar 2015 (FU 19360). SVV kapitulerte og utstedte EO044 Bompakke åtte dager senere, den 21. januar 2015.

(FU 19575) Lagmannsretten mener at SVV må bære ansvaret for at EA047/EO044 ble basert på det som viste seg å være en ufullstendig beskrivelse av nødvendig redesign og en ufullstendig liste over forretningsregler. SVV var fra deltakelsen i møtet 5. november 2014 klar over at kravene til bompakke var overordnet beskrevet, og hadde selv ansvar for å sørge for at listen over forretningsreglene var fullstendig. Når SVV ikke bidro til å avklare kravene eller forretningsreglene frem til EO044 ble utstedt, må SVV bære ansvaret for at kompleksiteten økte utover EO044. Lagmannsretten konkluderer med dette at den økte kompleksiteten beskrevet i FU bilag 1354 linjer 69 og 70 angående UC_AM_ADM_13 (Opprette/ vedlikeholde Bompakke) og UC_AM_ADM_14 (Opprette/vedlikeholde Avtalekontorabatt), faller utenfor Leveransen og utgjør endringer.

4.4.4.7.6 Brukerhistorier i tilknytning til brikkelogistikk Brukerhistoriene UC_AM_24, UC_LOG_05.1, UC_LOG_06 og UC_LOG_20 henger sammen med brikkelogistikken (FU bilag 1354 linjer 45, 93, 94 og 95). De står for 108 DCUT-timer, hvorav 102 timer var utført på hevingstidspunktet. IBMs endringskrav for disse brukerhistoriene er basert på at de var mangelfullt beskrevet i kravdokumentasjonen og løsningsbeskrivelsen, og at det i konstruksjonsfasen kom en detaljering utover det som med rimelighet kunne forventes ut av løsningsbeskrivelsesfasen. Brukerhistorier som i utgangspunktet var kort beskrevet, endte opp med beskrivelser over flere sider, flere forretningsregler og flere steg, jf. FU bilag 1354 og forklaringen fra Tonje Offenberg Bye for lagmannsretten. Staten har ikke behandlet disse brukerhistoriene særskilt. Tingretten har lagt til grunn at de utgjør endringer. Lagmannsretten legger til grunn tingrettens vurdering om at økningen i kompleksiteten i brukerhistorien UC_AM_24, UC_LOG_05.1, UC_LOG_06 og UC_LOG_20, utgjør en endring, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd.

4.4.4.7.7 Andre brukerhistorier i gruppen «økt kompleksitet» De andre brukerhistoriene i gruppen «økt kompleksitet» – linjene 32, 33, 44 og 84 i FU bilag 1354 – ble ikke belyst under ankeforhandlingen. De står for 124 DCUT-timer, hvorav 41 timer var utført ved hevingstidspunktet. IBM har for disse vist til tingrettens vurdering av at de utgjør endringer. SVV har ikke kommet med anførsler eller bevis knyttet til de enkelte brukerhistoriene som gir lagmannsretten grunnlag for å overprøve tingrettens vurdering om at økningen i kompleksiteten i disse brukerhistoriene, utgjør endringer. Lagmannsretten legger til grunn tingrettens vurdering om at økningen i kompleksiteten i brukerhistorien i linjene 32, 33, 44 og 84 i FU bilag 1354, utgjør endringer, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd. 4.4.4.8 «Annet» Gruppen «Annet» består av 16 brukerhistorier av ulik art. (FU bilag 1354 linjer 3, 7, 8, 10, 38, 46, 47, 48, 61, 63, 71, 77, 78, 79, 91 og 96) Disse brukerhistoriene står for 942 DCUT-timer. Elleve av disse brukerhistoriene, som står for 612 timer, var utført på hevingstidspunktet.

Disse brukerhistoriene ble ikke behandlet under ankeforhandlingen. Tingretten uttalte om disse i dommen på side 105: Av de øvrige elleve sakene fremstår tre som utvidelser av brukerhistorier etter samme mønster som UC_AM_05. Disse utgjør en fjerdedel av arbeidstimene (linje 45, 93 og 94). Resten synes å skyldes sene avklaringer og utvidelser av brukerhistorier etter samme mønster som de øvrige konfliktene. En gjennomgang av de 11 enkeltsakene i gruppe 5 viser et lignende mønster, hvor mange av sakene er nært forbundet med saker i gruppe 1-4. For eksempel ser linje 38 ut til å handle om konsekvensen av en utvidet UC_CM_03 (Ny avtale) på rapporter, mens linje 63 er relatert til bompakke og linje 77-79 til One-Step Registration. Resten synes også her å skyldes varianter av sene avklaringer og utvidelser av brukerhistorier. Tingretten konkluderte med at disse utgjorde endringer. Det er ikke kommet anførsler eller bevis som gir lagmannsretten grunnlag for å overprøve tingrettens vurdering.

Lagmannsretten legger til grunn tingrettens vurdering om at økningen i kompleksiteten i brukerhistorien i gruppen «Annet», var endringer, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd. 4.4.4.9 Oppsummering – gruppene av brukerhistoriene i EA053 Lagmannsretten konkluderer med dette at alt arbeid som er beskrevet i EA053, med unntak av arbeidet i forbindelse med ACT- og TST-filen, var utenfor Leveransen. Til sammen utgjør dette 2 803 DCUT-timer.

4.4.4.10 Statens generelle innsigelser til EA053

4.4.4.10.1 Om IBM kan kreve endring for arbeid som allerede er utført Staten har gjort gjeldende at IBM ikke kan kreve endring for 1 200 av DCUT-timene i EA053 fordi dette var arbeid som allerede var utført da EA053 ble fremmet. Staten har vist til Generelle kontraktsbestemmelser punkt 3.6.1 andre avsnitt siste setning, som slår fast at endringsanmodning skal fremsettes av leverandøren «uten ugrunnet opphold, ellers vil retten til å påberope seg endringen bortfalle». IBM har gjort gjeldende at IBM har varslet uten ugrunnet opphold. Subsidiært har IBM gjort gjeldende at staten har mistet retten til å påberope preklusjon fordi SVV har inngått realitetsdrøftelser om endringen, sammenholdt med langvarig passivitet. Lagmannsretten tar ikke standpunkt til om IBM har fremsatt EA053 «uten ugrunnet opphold», da den mener at statens preklusjonsinnsigelse uansett må anses frafalt eller tapt på grunn av passivitet. Lagmannsretten legger til grunn at den omstendighet at SVV har innlatt seg på realitetsdrøftelser om endringskravet, ikke alene kan føre til at statens preklusjonsinnsigelse går tapt.

Realitetsdrøftelsene kan imidlertid inngå som et element i vurderingen av om preklusjonsinnsigelsen må anses frafalt eller tapt ved passivitet, jf. HR-2020-2254-A (Rambøll) avsnitt 58. Slik lagmannsretten ser det, fikk SVV i februar 2015 den nødvendige kunnskapen om at deler av arbeidet i EA053 var utført før endringsanmodningen ble utstedt. SVVs funksjonelt løsningsansvarlige, Arve Leivestad, forklarte for lagmannsretten at han var helt klar over at EA053 omfattet arbeid som allerede var gjort, og at dette var en av grunnene til at han reagerte på den da den ble utstedt i februar 2015. Han forklarte videre at han formidlet sine observasjoner til prosjektledelsen, da han oppfattet det som «merkelig» at endringsanmodningen omfattet brukerhistorier som man hadde jobbet med i konstruksjonsfasen, gjort ferdig og validert. De begivenhetsnære bevisene understøtter at SVVs prosjektledelse var kjent med at deler av arbeidet i EA053 allerede var utført. Etter et møte mellom SVVs Arve Kirkevold og IBMs Kjetil Westgaard og Urs Briner 31. mars 2015, skrev Westgaard en e-post med en oppsummering av det de var blitt enige om.

Det siste punktet i oppsummeringen var at «future changes (in scope, timeline and/or cost) should be agreed before the work is started». (FU 21910 og 21912) I referatet fra KG-møte 17. april 2015 går det også frem av omtalen av A-2s forslag til føringer for forhandlinger om EA053, at det var «en forutsetning at det ikke skal utstedes ytterligere endringsanmodninger som omfatter omfangsendringer tilbake i tid» (FU 22629). Det samme går frem av notat 19. april 2015 utarbeidet av A-2 etter det nevnte KG-møtet. Det er ikke bestridt at statens preklusjonsinnsigelse først ble gjort gjeldende i stevningen 1. september 2016. (FU 26760 på 26870) Dette var over 18 måneder etter at EA053 ble utstedt. I mellomtiden hadde EA053 vært gjenstand for omfattende drøftelser i prosjektets organer, og den var blitt formelt avvist med omfattende begrunnelse, uten at SVV påberopte at den var for sent fremsatt, jf. punkt 4.4.4.1 over.

Lagmannsretten mener at tidsforløpet, sett i sammenheng med at SVV har innlatt seg på realitetsdrøftelser uten å anføre at endringsanmodningen var for sent fremsatt, må føre til at statens preklusjonsinnsigelsen er gått tapt på grunn av langvarig passivitet.

4.4.4.10.2 Om arbeidet i EA053 var på kritisk linje At arbeid ligger på kritisk linje, innebærer at annet arbeid må stoppe opp. Øvrige arbeidsstrømmer må vente på den aktuelle arbeidsstrømmen før de kan arbeide videre. Staten har gjort gjeldende at IBM aldri har påvist at arbeidet i EA053 lå på kritisk linje, og at IBM dermed ikke har krav på fristforlengelse. SVV bestred allerede da EA053 ble avvist i brev 23. februar 2015 at «CRM alene» var på kritisk linje, og hevdet at IBM hadde store utfordringer med sine leveranser på alle områder. (FU 20575) For lagmannsretten har staten gjort gjeldende at det hele våren 2015 var klart at SAP-strømmen ville bli ferdig

minst et halvt år etter CRM-strømmen, dvs. at det var SAP-strømmen, og ikke CRM-strømmen, som lå på kritisk linje. Om ikke IBM påviste at arbeidet i EA053 lå på kritisk linje, viser de begivenhetsnære bevisene at IBM i hvert fall fra midten av november 2014 og utover våren 2015 ga klart uttrykk for at CRM-strømmen lå på kritisk linje. I referat fra KG-møte 18. november 2014 går det frem at IBM rapporterte at «det er de to områdene CRM og INT som er på kritisk linje for å nå HMP2 til 28. april». (FU 17223 på 17225) IBM deltok i møte i SVVs styringsgruppe 23. januar 2015, og rapporterte da at «driver for å endre tidslinjen er CRM og tilhørende integrasjoner, som er på kritisk linje». (FU 19614) Det samme går frem av IBMs månedsrapport for februar 2015, hvor det står at «arbeidet innenfor CRM utgjør kritisk sti og driver tidslinjen». (FU 20957 på 20960) Og i referat fra KG-møte 17. mars 2015 går det frem av presentasjonen av «7 keys» under overskriften «CRM» at «omfang og kompleksitet er størst, driver tidslinjen og er på kritisk sti».

(FU 21286 på 21288) Slik lagmannsretten ser det utelukker uansett ikke den omstendigheten at SAP-strømmen var på kritisk sti, at også CRM-strømmen var det. Prosjektet hadde en stram tidsplan. Forsinkelse på et område ville med nødvendighet påvirke den kritiske linjen selv om fremdriften fra før var god. Når IBM som leverandør ble påført merarbeid i CRM-strømmen i størrelsesorden ca. 2 803 DCUT-timer – slik lagmannsretten har kommet til – på toppen av en allerede stram tidsplan, ligger det etter lagmannsrettens syn i dagen at denne strømmen lå på kritisk linje. Lagmannsretten finner støtte for sitt syn i Føyen m.fl., Kontrakter for utvikling av programvare 2006 side 289, hvor det fremholdes at «endringer i prosjektet som vedtas i utviklingsfasen vil nesten uten unntak medføre konsekvenser for prosjektets tidsplaner».

Marthinussen m.fl., NS8405 Kommentarutgave til Norsk Standard 8405 (2016), gir på side 340, uttrykk for det samme, og oppstiller en presumsjon for at det foreligger en hindring i tilfeller hvor entreprenøren pålegges en endring, i hvert fall en endring av et visst omfang: I tilfeller hvor volumet av endringer eller hindringer blir stort, men hvor den enkelte hindring eller endring ikke i seg selv påvirker fremdriften, vil man måtte se på summen av forholdene ved vurderingen av om fremdriften hindres. Det er likevel ikke upraktisk at summen av endringer kan bli så omfattende at dette påvirker fremdriften. Ofte vil entreprenøren ha problemer med å dokumentere påvirkning på den kritiske linje fordi fremdriftsplanen ikke er tilstrekkelig detaljert til å vurdere om det foreligger en hindring for fremdriften.

Ved vurderingen av om det er dokumentert at det foreligger en hindring som påvirker fremdriften, bør man kunne oppstille en presumsjon for at det foreligger en hindring i tilfeller hvor entreprenøren pålegges en endring i form av tilleggsarbeid i forhold til kontrakt, eller der hvor byggherren ikke følger opp sine plikter for eksempel til å levere tegninger i henhold til fastsatt leveranseplan. I alle fall gjelder dette der endringene har et visst omfang. Lagmannsretten tar ikke stilling til om det bør oppstilles en presumsjon for at det foreligger en hindring i tilfeller hvor entreprenøren pålegges en endring av noen størrelse. Lagmannsrettens konklusjon om at arbeidet i EA053 lå på kritisk linje, bygger på en konkret vurdering av endringens omfang sammenholdt med den stramme tidsplanen.

4.4.4.10.3 Om usikkerhetsmatrisens betydning for de endringer som kan kreves Staten har gjort gjeldende at usikkerhetsmatrisen i Bilag A punkt 5 og usikkerhetspåslaget i vederlaget begrenser de endringskravene som IBM kan få medhold i. Ifølge staten fastsetter kontrakten at usikkerhet som er identifisert i usikkerhetsmatrisen og som realiseres i konstruksjonsfasen, ikke gir grunnlag for endring. Lagmannsretten oppfatter at anførselen er særlig knyttet til usikkerheten for at det oppstår «vesentlig avvik fra det som ligger som standardfunksjonalitet i IBMs løsning». Dette ble inntatt som usikkerhet nr. 111 i utkast til usikkerhetsmatrise 5. juni 2014 og i oppdatert og omforent usikkerhetsmatrise fra november 2014. (FU 12988 på 12990 og TU2 1459 på 1463) Statens anførsel innebærer at SVV gjennom usikkerhetsmatrisen har overført ansvaret for identifiserte usikkerheter til IBM, og at IBM gjennom usikkerhetspåslaget har fått vederlag for å påta seg slikt ansvar.

Lagmannsretten mener at det ikke er holdepunkter for dette, og at kontrakten ikke kan forstås slik staten gjør gjeldende. Anførselen bygger på Generelle kontraktsbestemmelser punkt 3.2.2, som lyder: I usikkerhetsmatrisen som inngår i Bilag A, har partene før kontraktsinngåelsen identifisert og vurdert viktige usikkerhetselementer som kan ha betydning for Leverandørens gjennomføring av Leveransen. Usikkerhetsmatrisen danner grunnlaget for usikkerhetspåslaget som inngår i Kontraktsprisen, ref. punkt 4.1. Usikkerhetsmatrisen skal oppdateres etter Løsningsbeskrivelsesfasen, ref. punkt 3.3. Usikkerhetsmatrisen er for øvrig ikke underlagt Kontraktens endringshåndtering i punkt 3.6 og gir etter Løsningsbeskrivelsesfasen ikke grunnlag for endring av Kontrakten. (FU 8465) Slik lagmannsretten forstår ordlyden i bestemmelsen, er det usikkerhetspåslaget som ikke kan endres som følge av justering i usikkerhetsmatrisen etter løsningsbeskrivelsen.

Lagmannsretten forstår formuleringen om at usikkerhetsmatrisen ikke er underlagt kontraktens endringshåndtering slik at justeringer i matrisen etter løsningsbeskrivelsen, derimot kan danne grunnlag for endringshåndtering. Lagmannsretten finner støtte for sin tolking i Veilederen til PS2000. I punkt 5.2.2 heter det: Den usikkerhetsmatrisen som blir inkludert i kontrakten danner også grunnlaget for leverandørens usikkerhetspåslag, ref. Del II punkt 4.1. I fasene etter løsningsbeskrivelsen får endringer i matrisen ikke lenger kontraktsmessige konsekvenser. Det vil si at usikkerhetspåslaget forblir uendret i kontraktens levetid etter løsningsbeskrivelsen, selv om innholdet i usikkerhetsmatrisen endres underveis. Samtidig innebærer det at endringer i usikkerhetsmatrisen som blir avdekket under løsningsbeskrivelsesfasen, kan danne grunnlag for endringshåndtering og inngå i den endringsanmodning som leverandøren kan utstede i forbindelse med godkjenning av løsningsbeskrivelsen, ref. punkt 5.3.2. (Lagmannsrettens kursivering).

(FU 2278) Statens tolking ville etter lagmannsrettens syn føre til urimelige resultater ved at IBM fikk tilført usikkerheter som selskapet ikke hadde noen mulighet til å kontrollere. Dette gjelder for eksempel ansvar for ukjente eller uavklarte myndighetskrav, ansvar for manglende presisjon i konkurransegrunnlaget, ansvar for SVVs idriftsettelse og ansvar for manglende IKT-kompetanse hos SVV. Lagmannsretten finner det klart at dette ikke ha vært hensikten med usikkerhetsmatrisen og usikkerhetspåslaget. Usikkerhetsmatrisen hadde sammenheng med SVVs egen usikkerhetsstyring. (FU 8232) I større entrepriser benyttes usikkerhetsmatriser som et redskap for å vurdere og dokumentere identifiserte usikkerheter med tanke på å kalibrere usikkerhetene mot hverandre, identifisere tiltak for å håndtere dem, og utpeke en tiltaksansvarlig. Som regel vil en part være ansvarlig for tiltakene knyttet til de usikkerhetene som hører til den eller de entreprisene han selv er ansvarlig for.

I Veilederen til PS2000 heter det: Hensikten med å inkludere begge parter i en slik usikkerhetsmatrise, er å få avdekket ulike vurderinger av usikkerhet hos partene og gi et grunnlag for fordelingen av risiko og videre definere tiltak for å redusere både sannsynlighet og konsekvens av at risikoen slår til. (FU 2278) Arbeidet med usikkerhetsmatrisen i Grindgut fulgte denne prosessen. I konkurransegrunnlaget hadde SVV identifisert ti usikkerhetselementer og gitt sin egen vurdering av sannsynligheten og konsekvens. (FU 3392) Tilbyderne ble bedt om å «fylle ut sin vurdering (sannsynlighet og konsekvens) av de usikkerhetselementene som Kunden har i sin initielle usikkerhetsmatrise», og eventuelt å angi andre usikkerhetselementer enn de som SVV hadde identifisert. Usikkerhetsmatrisen som ved kontraktsinngåelsen ble tatt inn i Bilag A, inneholdt SVVs og IBMs respektive vurderinger av sannsynlighet og konsekvens. Den inneholdt tiltak for å håndtere usikkerheten og pekte ut hvem som var ansvarlig for tiltak.

(FU 8550) Slik lagmannsretten ser det, ble tiltak og ansvar allokert til den av kontraktspartene som var nærmest til å håndtere usikkerhetselementet. Således ble ansvar og tiltak knyttet til usikkerhetselementet «idriftsettelse (konvertering/produksjonssetting)» og «Kundens evne til å foreta avklaringer og beslutninger løpende», allokert til SVV. På den andre siden ble ansvar og tiltak knyttet til usikkerhetselementet «høye krav til ytelse i løsningen», allokert til IBM. For noen av usikkerhetselementene var det identifisert flere tiltak med enten felles ansvar eller hver sin ansvarlig. For eksempel ble det for usikkerhetselementet «organisering og samarbeid mellom Kunde og Leverandør», identifisert fire tiltak med felles ansvar. Det er ikke holdepunkter for at

kontraktspartene allokerte ansvaret for et usikkerhetselement til en part som ikke hadde mulighet til å håndtere den. Usikkerhetspåslaget er i Generelle kontraktsbestemmelser punkt 4.1 bokstav c definert som «et prosentvis tillegg til det timebaserte arbeidet, hvor tilleggets størrelse skal være en konsekvens av usikkerhetsmatrisen, ref. punkt 3.2.2». (FU 8472) Slik lagmannsretten ser det, skal påslaget reflektere den identifiserte usikkerheten i prosjektet. Det er ikke holdepunkter for at påslaget skal være vederlag for å påta seg usikkerheter som SVV står nærmest å håndtere, slik staten synes å hevde. Hadde dette vært tilfellet, ville det måttet komme uttrykkelig og tydelig frem.

4.4.4.10.4 Statens øvrige innsigelser Staten har gjort gjeldende at EA053 er en oppkonstruert endringsanmodning der IBM forsøker å gi SVV ansvaret for en feilestimering som IBM gjorde ut av løsningsbeskrivelsesfasen. Det er vist til at IBMs opprinnelig krav i EA053 er mistenkelig lik økningen i IBMs DCUT-estimater fra juni til september 2014. Det er også vist til at flere av linjene som IBM i EA053 hevder lå utenfor kontrakten, var linjer som IBM mente lå innenfor kontrakten i EA035/EA040 (Task Force Scope). Lagmannsretten har i punkt 4.4.4.4 til 4.4.4.8 redegjort for at EA053 gir uttrykk for reelle endringer. Det ligger motsetningsvis i dette at lagmannsretten mener at EA053 ikke er oppkonstruert. Det er derfor ikke nødvendig for lagmannsretten å gå inn i statens anførsler om dette. Lagmannsretten bemerker likevel at den ikke finner holdepunkter i de begivenhetsnære bevisene for en sammenheng mellom IBMs estimatøkning i september 2014 og IBMs krav i EA053.

Lagmannsretten går ikke inn i statens regnestykke, men nøyer seg med å påpeke at IBMs DCUT-estimater for CRM-strømmen ikke bare økte fra juni til september 2014, men også i perioden fra desember 2014 til februar 2015 da EA053 ble fremmet. Etter re-estimeringen i september 2014, hvor estimatene for CRM-strømmen ble nesten doblet i forhold til estimatene i juni 2014, ble DRI engasjert til å bistå GD India med å gjennomgå estimatene. Per 30. oktober 2014 var estimatet redusert til 9 052 DCUT-timer, hvorav 7 124 timer for gjenstående arbeid (iterasjon 2 og 3). (FU 16752) Fra midten av desember 2014 da EA053 ble varslet, til februar 2015 da EA053 ble fremmet, økte imidlertid DCUT-estimatene for CRM med over 2 000 timer. (FU bilag1611 fanen EV figures) Lagmannsretten mener at det er mer nærliggende å se denne økningen i sammenheng med EA053 enn økningen i estimatene i september 2014.

Hva gjelder sammenhengen mellom EA053 og EA035/EA040 (Task Force Scope), viser lagmannsretten til at IBM, for de linjene i EA053 dette gjelder, ikke har gjort gjeldende at funksjonaliteten ikke var kravstilt, men at kompleksiteten til kravstilt funksjonalitet økte i konstruksjonsfasen. De to endringsanmodningene er derfor ikke gjensidig utelukkende, slik staten synes å hevde. 4.4.4.11 EA053 – Konklusjon Lagmannsretten konkluderer etter dette med at IBM har krav på fristforlengelse for alt arbeid som er beskrevet i EA053, med unntak av arbeidet i forbindelse med ACT- og TST-filen. Timene for ACT- og TST-filen utgjør 305 DCUT-timer, eller litt i underkant av 10 prosent av det totale kravet på 3 108 DCUT-timer (39 dager). Lagmannsretten reduserer derfor fristforlengelseskravet med 4 dager. IBM får medhold i krav om fristforlengelse med 35 kalenderdager for EA053. De kostnadsmessige konsekvensene av EA053 er som tidligere nevnt behandlet i punkt 5.

4.4.5 EA054 Arbeidsform 4.4.5.1 Innledning – Behandlingen av EA054 EA054 ble utstedt av IBM ved Nicolai Rygh 7. februar 2015. (FU 20014) Den har nær sammenheng med EA053. Mens EA053 gjelder merarbeidet til utvikling (DCUT-timer) på grunn av at SVV stilte krav i konstruksjonsfasen som økte kompleksiteten i løsningen, gjelder EA054 konsekvensene av arbeidsformen og LB-2020-82571-2

prosessen med å utarbeide brukerhistoriene i CRM-strømmen. Endringskravet er også begrunnet i at SVV ikke bidro tilstrekkelig til at en standard løsning kunne realiseres. I EA054 er endringskravet begrunnet slik: Arbeidet med utarbeidelse av Use-Case i Konstruksjonsfasen har avdekket en arbeidsform som etter Leverandørens mening er annerledes og vesentlig mer arbeidskrevende enn den som ble lagt til grunn for Kontrakten. Ved at detaljerte krav og øket kompleksitet dukker opp sent i prosessen medfører dette en økt arbeidsbelastning på Leverandørens ressurser og mer arbeid i gjennomføring ved økt antall WorkShop's samt etterarbeid etter WorkShop'ene. [...] Videre opplever Leverandøren at Kunden ikke tar tilstrekkelig ansvar for å bidra til at en standard løsning, i tråd med uttalte ambisjoner, kan realiseres. Kontrakten legger til rette for at et slikt ansvar balanseres mellom partene, mens erfaringen i det daglige er at dette ansvaret i stor grad legges på Leverandøren. Implisitt i dette ligger at Leverandøren opplever at Kunden i mindre grad bidrar til at avtalt tidslinje kan nås.

EA054 inneholder en rekke eksempler på det IBM mente var en mer krevende arbeidsform og manglende bidrag til realisering av en standard løsning, som lagmannsretten kommer tilbake til. De tidsmessige konsekvensene var estimert til 480 timer merarbeid i GEO og 2 012 uproduktive timer i GD India. IBM krevde en økning av målprisen med 582 timer og 818 241 kroner, og en fristforlengelse på 30 arbeidsdager, tilsvarende 42 kalenderdager. SVV avviste EA054 ved brev 23. februar 2015. (FU 20621) SVV mente at IBM hadde ansvar for å styre og lede prosjektets arbeidsform. SVV viste blant annet til at arbeidsformen som IBM selv hadde beskrevet i PRO006 Arbeidsprosesser og levert til HMP1, aldri hadde blitt gjennomført, at manglende fremdrift i arbeidsmøter skyldtes forhold på IBMs side, og at grunnen til at detaljerte krav og økt kompleksitet dukket opp sent i prosessen, var et utslag av hvordan IBM hadde lagt opp fremdriften. EA054 ble eskalert til koordineringsgruppen og behandlet i KG-møtet 17. april 2015 sammen med EA053.

(FU 22624 på 22629) I et notat utarbeidet forut for KG-møtet hadde A-2 foreslått at «EA054 godkjennes da det ansees som svært sannsynlig at arbeidsmengden i detaljering har vært større enn opprinnelig antatt». (FU 22334) A-2 foreslo at kostnaden ved EA054 skulle deles med en tredjedel på SVV og to tredjedeler på IBM. A2 foreslo videre at påvirkningen på tidslinjen skulle justeres fra fem til tre uker og at IBM skulle bære to av de tre ukene, slik at HMP2 ble flyttet med en uke. I KG-møtet ble det fattet vedtak om å sette EA054 på vent inntil videre mens kontraktspartene jobbet med EA053. Forutsatt at det ble en løsning på EA053, skulle IBM trekke EA054, jf. punkt 4.4.4.1 over.

EA053 ble som kjent aldri løst, og både EA053 og EA054 var fortsatt bestridt på hevingstidspunktet. 4.4.5.2 Partenes anførsler IBM har i korthet gjort gjeldende at SVV var til hinder for fremdriften i CRM-strømmen høsten 2014 ved at vegvesenet ikke evnet å gjøre avklaringer og treffe beslutninger innenfor de tidsrammene som var angitt i tilbudet, og at SVVs deltakere i CRM-arbeidsmøter ikke oppfylte kontraktens krav til kompetanse om SVVs virksomhet, behov og krav. Dette førte til at det lokale teamet i Norge (GEO) ble forsinket med å produsere brukerhistorier, som var arbeidsgrunnlaget for GD India, og at GD India ble gående ledig uten arbeidsoppgaver. SVVs gjennomføringsevne sviktet allerede i løsningsbekrivelsesfasen. SVV klarte ikke å snu trenden i konstruksjonsfasen. Staten har i korthet gjort gjeldende at SVV ikke var til hinder for IBMs fremdrift, og at SVV medvirket i henhold til kontrakten. IBMs prosjektledelse bekreftet flere ganger i løpet av høsten 2014 at SVV ikke var til hinder for IBMs fremdrift. IBMs krav i EA054 er et «plunder og heft»-krav.

IBM har ikke oppfylt de kravene som Høyesterett har stilt til identifiseringen av de arbeidsoperasjonene som har blitt påvirket av SVVs forhold. Lagmannsretten behandler først i punkt 4.4.5.3 statens anførsel om at IBMs krav i EA054 er et «plunder og heft»-krav. IBMs krav bygger delvis på at SVV sviktet i gjennomføringen av sin medvirkningsplikt, og i punkt 4.4.5.4 gis det derfor en oversikt over kontraktens krav til partenes medvirkning under kontraktens løp. I punkt 4.4.5.5 går lagmannsretten inn på bevisene knyttet til statens gjennomføringsevne ved kontraktsinngåelsen og under kontraktens løp. I punkt 4.4.5.6 behandler lagmannsretten rapporter om fremdriftshindringer i konstruksjonsfasen. EA054 er også til dels begrunnet i at SVV ikke tok tilstrekkelig ansvar for å bidra til at en standard løsning kunne realiseres. Dette spørsmålet behandles i punkt 4.4.5.7. De konkrete eksemplene på

fremdriftshindringer som er trukket frem i EA054 og under ankeforhandlingen, er behandlet i punkt 4.4.5.8 til 4.4.5.12. 4.4.5.3 Om IBMs krav er et «plunder og heft»-krav Staten har som nevnt gjort gjeldende at IBMs krav i EA054 er et «plunder og heft»-krav, og at IBM ikke har oppfylt de kravene som Høyesterett har stilt til identifiseringen av de arbeidsoperasjonene som har blitt påvirket av SVVs forhold. Lagmannsretten er ikke enig i at EA054 er et «plunder og heft»-krav. Høyesterett har i HR-2019-1225-A (HAB) uttalt følgende om uttrykket «plunder og heft»: (54) Betegnelsen plunder og heft er et bransjeuttrykk som ikke har et entydig rettslig innhold. Men kjernen er at entreprenøren påføres ekstrakostnader som følge av at forhold på byggherrens hånd medfører nedsatt produktivitet eller forstyrrelser på annet arbeid hos entreprenøren. (55) Det er altså tale om avledete konsekvenser av forhold som byggherren svarer for, som pålegg om endringer i det som er avtalt, eller forsinkelse eller annen svikt i byggherrens medvirkningsplikt.

I praksis vil plunder og heft ofte skyldes samvirke mellom flere årsaker, hvorav noen kan tilskrives byggherren og andre entreprenøren. Det er sikker rett at entreprenøren som utgangspunkt har rett til kompensasjon for plunder og heft som skyldes forhold som byggherren har risikoen for, med mindre dette er uttrykkelig ekskludert i kontrakten, jf. Brøndmo, Plunder og heft – status og utfordringene fremover, i På rett grunn II, Festskrift til Norsk Forening for Byggeog Entrepriserett, 2021, Rettsdata.no. At entreprenøren som utgangspunkt har rett til kompensasjon for plunder og heft, følger av de entrepriserettslige standardkontraktene, er stadfestet i rettspraksis og må anses som alminnelig entrepriserett. I enkelte standardkontrakter følger retten til kompensasjon for plunder og heft eksplisitt av en egen bestemmelse. I andre standardkontrakter er retten forutsatt som del av en varslingsregel, mens den i atter andre er forutsatt som del av en utmålingsregel.

Selv uten slike eksplisitte eller forutsatte rettsgrunnlag, har entreprenøren rett til kompensasjon for plunder og heft etter de generelle reglene for kompensasjon for merkostnader som skyldes byggherreforhold. Dette illustreres av HAB-dommen nevnt over. Der var rettsgrunnlaget for entreprenørens krav den generelle regelen i NS 3430 pkt. 21.1

(1) om entreprenørens rett til kompensasjon for byggherreforhold. Lagmannsretten antar at et «plunder og heft»-krav fra IBM kunne ha vært forankret i Generelle kontraktsbestemmelser punkt 6.2 om kundens mislighold, som i punkt 6.2.2 illustrerer sondringen mellom krav på de direkte og de indirekte konsekvensene av kundens manglende medvirkning. Her understrekes det også at et krav om endring er et annet type krav enn et krav om plunder og heft: Dersom Kunden misligholder [...] plikten til å medvirke ved oppfyllelsen av Leveransen, har Leverandøren krav på justering av Fremdriftsplanen og/eller Kontraktsprisen ved utstedelse av en Endringsanmodning. Tap som Leverandøren påføres som følge av Kundens mislighold, og som det ikke kompenseres for ved Endringsanmodningen, kan kreves erstattet av Kunden i henhold til punkt 6.4.1. (FU 8477) Første punktum gjelder de direkte konsekvensene av manglende medvirkning, som gir leverandøren rett til å kreve justering av fremdriftsplanen og kontraktsprisen gjennom utstedelse av en endringsanmodning.

Andre punktum gjelder de indirekte konsekvensene av manglende medvirkning – forstyrrelser på andre arbeider – som kun gir leverandøren rett til å kreve erstatning. IBMs krav i EA054 er forankret i Generelle kontraktsbestemmelser punkt 3.6.1, som gir leverandøren rett til å utstede en endringsanmodning dersom kunden «ved handling eller unnlatelse påfører leverandøren arbeid eller kostnad [...] som forsinker» leverandøren. IBM krever ikke kompensasjon/erstatning for forstyrrelser for de indirekte konsekvensene, men fristforlengelse og justering av målprisen for de direkte konsekvensene av SVVs manglende medvirkning. At manglende medvirkning fra kundens side gir krav på endring av kontrakten, er understreket i veilederen til PS2000, punkt 8.2 om kundens mislighold. Her går det frem:

PS2000-kontraktsstandarden baseres på et nært samarbeid mellom leverandøren og kunden. Dersom kunden ikke oppfyller sine forpliktelser, vil det kunne bli umulig for leverandøren å oppfylle sine. Kundens eventuelle mislighold vil derfor gi leverandøren krav på endring av sine forpliktelser og rettigheter. Slik lagmannsretten ser det, har IBM med rette fremmet sitt krav for virkningen av SVVs påståtte manglende medvirkning som et endringskrav. 4.4.5.4 Kontraktens bestemmelser om leverandørens plikter og kundens medvirkning Som nevnt i punkt 3.1.2 over er den overordnede ansvarsfordelingen mellom IBM og SVV regulert i Generelle kontraktsbestemmelser punkt 1.2 og 1.3. (FU 8462) IBM sto for Leveransen, mens SVV pliktet å samarbeide med IBM, slik at IBM «ikke blir forsinket eller på annen måte forhindret i å oppfylle sine forpliktelser». Som også nevnt er PS2000 basert på et nært samarbeid mellom leverandøren og kunden. Kontraktens krav til kundens medvirkning i prosjektet er utdypet i Bilag B (Administrative Bestemmelser) punkt 2.5.4.

Det går frem av punkt 2.5.4 at «Kunden skal medvirke til at Leveransen kan gjennomføres i henhold til Kontrakten, og at dette «skal skje gjennom deltagelse med eget personale som skal ha tilstrekkelig kompetanse om egen virksomhet, behov og krav». (FU 9075) Blant annet skal følgende oppgaver utføres av kunden: «sørge for at forutsetningene for kontraktinngåelsen er oppfylt», «delta i arbeidsgrupper for å gjennomgå og utdype spesifikasjonene», «bidra med prioriteringer og løpende funksjonelle avklaringer» og «sørge for rettidig ferdigstillelse av eventuelle egne leveranser». (FU 9077) I vedlegg til Bilag B går det frem at SVVs løsningsteam (funksjonelt ansvarlig og teknisk ansvarlig) blant annet skal «løse opp i løpende avklaringer, eskaleringer, hindringer i de ulike teamene» og «skaffe godkjenning fra SVV for avklaringer, eskaleringer, osv fra teamene». (FU 9084) Leverandørens ansvar er også utdypet i Bilag B. Blant annet er det i punkt 2.5.5 presisert at leverandøren har «lederansvaret for arbeidet med løsningsbeskrivelse, konstruksjon, godkjenning og idriftsettelse, selv om arbeidet foregår i samarbeid med Kunden».

(FU 9077) I punkt 2.5.3 går det frem at leverandørens prosjektleder «har det daglige ansvar for at Leveransen planlegges, organiseres og ledes slik at arbeidet blir gjennomført i henhold til kontraktsforpliktelsene». Dette ansvaret inkluderer den interne kvalitetssikringen hos leverandøren, herunder å sørge for at arbeidet utføres i henhold til god forretningsskikk og i henhold til relevante, etablerte bransjestandarder. (FU 9075) IBM har for det første vist til at selskapet i tilbudet stilte som forutsetning at SVVs AutoPass-prosjekt var gitt «myndighet til å ta tekniske og funksjonelle avgjørelser angående prosjektet». For det andre var det IBMs «forutsetning for planlegging og kostnadsberegning [...] at kunden skal gi endelig tilbakemelding i henhold til dokumenterte godkjenningsprosedyre beskrevet i [Bilag C – Gjennomføring] kapittel 7.2.2.1 i løpet av fem arbeidsdager». (FU 4330) Lagmannsretten mener at henvisningen til Bilag C punkt 7.2.2.1 IBMs andre forutsetning, taler for at den bare gjaldt den formelle akseptanseprosedyren for dokumentasjon som IBM skulle oversende til SVV for godkjenning under prosjektet.

(FU 4624) Både denne forutsetningen og den første forutsetningen om at prosjektdeltakerne hadde myndighet til å ta tekniske og funksjonelle avgjørelser angående prosjektet, ble imidlertid frafalt i IBMs siste tilbud 4. september 2013. (FU 7103 på 7845) Under forhandlingene om tidsplanen formidlet IBM at det var «en forutsetning for planen [...] at beslutninger blir foretatt innenfor akseptable tidsrammer som angitt i tilbudet». (FU 6169) Denne forutsetningen mener lagmannsretten knytter seg til beslutninger generelt. Det er uklart om denne forutsetningen ble akseptert av SVV. Lagmannsretten mener imidlertid at det uansett må gjelde et generelt prinsipp om at beslutninger må foretas innen rimelig tid. En plikt til å treffe beslutninger innen rimelig tid kan under enhver omstendighet utledes av Bilag B punkt 2.5.4, jf. over. 4.4.5.5 Usikkerheten knyttet til SVVs gjennomføringsevne SVV identifiserte egen «evne til å foreta avklaring og ta beslutninger løpende» som en usikkerhet i usikkerhetsmatrisen som ble inntatt i kontrakten i Bilag A.

(FU 8550 på 8552) På en skala fra 1 til 4 vurderte SVV sannsynligheten for at usikkerheten ville inntreffe, til å være 2 (middels, 10-30 prosent) og konsekvensen

dersom risikoen inntraff til å være 4 (meget stor, > 25 prosent av kontraktssum). Tiltak for å håndtere usikkerheten var å «etablere beslutningsfora for løsning og innhold utenfor prosjektet, i Statens Vegvesen og mot bompengeselskapene» og «bemyndiggjøre Kundens ressurser i prosjektet». Ansvaret for tiltaket ble allokert til SVV. Etter lagmannsrettens syn må dette forstås slik at partene mente at det lå nærmest SVV å håndtere denne usikkerheten, jf. punkt 4.4.4.10.3 over. I løsningsbeskrivelsesfasen rapporterte SVV internt om egen gjennomføringsevne gjennom usikkerhetsmatriser/usikkerhetskart inntatt i de månedlige statusrapportene for delprosjektet leveranse. I statusrapport for januar 2014 skrev SVV ved prosjektleder Stein Ødegaard at sannsynligheten for at usikkerheten knyttet til kundens evne til å foreta avklaringer og ta beslutninger løpende gjennom både løsningsbeskrivelsesfasen og konstruksjonsfasen ville inntreffe, var stor (25-50 prosent) og at konsekvensen var alvorlig både hva gjelder tid, kvalitet og omdømme. (FU 10192 på 10195 og 10196) Denne vurderingen sto uendret gjennom løsningsbeskrivelsesfasen.

I den første perioden ble det identifisert tiltak fra SVVs side for å håndtere usikkerheten. I rapporten for januar 2014 går det frem at SVV skulle «etablere prosesser i LBF for å sikre forutsigbarhet og kompletthet i løsningsbeskrivelsene». (FU 10196) I rapporten for februar 2014 ble det lagt til at det skulle stilles «klare krav til forberedelser, og gjennomføring for våre ressurser slik at alle er forberedt til WS og møter». I tillegg måtte «prosessen for å sammenstille Wsene til løsningsbeskrivelser være så tydelig at det kan planlegges med rett og tilstrekkelige ressurser for review». (FU 10954 på 10958) I rapportene for mars 2014 frem til slutten av løsningsbekrivelsesfasen, er både tiltakene og merknadene fjernet. Det ble heller ikke utpekt noen ansvarlig eller frist, i motsetning til det som gjelder for andre identifiserte usikkerheter. (FU 11436 på 11442/11443 (mars), FU 11925 på 11931/11932 (april), FU 12343 på 12349/12350 (mai), FU 12928 på 12933/12934 (juni)).

SVV gjorde en intern vurdering av «risiko for at kundesiden i prosjektet ikke har evne og kapasitet til å gjennomføre kundens forpliktelser i henhold til planer og avtale» mot slutten av løsningsbekrivelsesfasen. I en usikkerhetsmatrise 1. juni 2014 vurderte SVV at sannsynligheten for at usikkerheten ville inntreffe, var høy (4 på en skala fra 1 til 5), og at konsekvensen var middels (3). (FU 12918 på 12919) Konsekvensene for tid og kostnad var «forsinkelser i leverandørens fremdriftsplan» og «økte kostnader, når det er kunden som forårsaker disse vil det måtte påregnes at leverandør krever kompensasjon i form av endringsordre». Tiltak for å håndtere usikkerheten inkluderte å «etablere prosesser for hvordan kundesiden av prosjektet skal jobbe sammen både internt og mot utviklingsleverandør» og «vurdere prosjektorganiseringen på kundesiden i fht om denne er optimal for å gjennomføre prosjektet». Samtidig som SVV gjorde sin egen vurdering internt, jobbet kontraktspartene sammen med en oppdatert usikkerhetsmatrise til HMP1.

I et utkast 5. juni 2014 ble sannsynligheten for usikkerheten knyttet til SVVs «evne til å foreta avklaring og ta beslutninger løpende», stående på samme nivå – 2 (middels) – som i usikkerhetsmatrisen som inngikk i Bilag A, mens konsekvensen dersom usikkerheten inntraff, ble redusert fra 4 til 2 (middels). (FU 12944 på 12947) Det ble også føyd til i beskrivelsen av usikkerhetselementet at usikkerheten «påvirkes av at der er mange interessenter hos kunden». Tiltak for å håndtere usikkerheten var de samme som i den opprinnelige usikkerhetsmatrisen i Bilag A, med SVV som ansvarlig. Etter lagmannsrettens syn er fastsettelsen av nivået på risikoen i dette utkastet, vanskelig å forene med SVVs interne vurdering av egen gjennomføringsevne. SVVs vurdering av egen gjennomføringsevne under løsningsbeskrivelsesfasen, går også frem av spredte interne møtereferater. Til SG-møte 29. januar 2014 rapporterte Stein Ødegaard at «Kundesiden bør være bedre forberedt og samkjørte før gjennomføring av hvert enkelt arbeidsmøte» og at SVV måtte få «kontroll på deltakelse i arbeidsmøtene».

(FU 10850 på 10851) Ifølge Ødegaard opplevde prosjektet «at noen personer ikke møter opp, mens andre stiller i møter de ikke er invitert til». I SG-møte 25. juni 2014 ble «Kundens egen gjennomføringsevne» identifisert som ett av to «hovedområder som antas å være store usikkerhetsfaktorer». (FU 13987 på 13989) IBMs strømledere rapporterte internt om erfaringer med arbeidsformen mot slutten av løsningsbeskrivelsesfasen. De viste til «slow client decision making» og «a broad range of stakeholders and the need for repeated re-assurances». (TU 1690 på 1691 og TU2 1001 på 1002). Disse erfaringene ble fremlagt for SVV under overleveringen av løsningsbeskrivelsen i mai 2014. Hver IBM-strøm presenterte sine observasjoner på hvordan de hadde jobbet. CRM-strømmen rapporterte blant annet at det hadde vært en «utfordring å få tilgang til SVV-ressurser» og «å få svar i tide på aksjonspunkter». (FU 12595 på 12614)

I notat 14. mai 2014 om kostnadsdriverne i løsningsbeskrivelsesfasen, identifiserte A-2 «en arbeidsform som krever mye samspill og avklaringer mellom partene» og «mangelfull operativ gjennomføringskraft» som to av driverne. (FU 12434 på 112437) A-2 skrev blant annet: Arbeidsformen i LBF ble annerledes og mer krevende å lede og gjennomføre enn det IBM opprinnelig hadde planlagt og estimert. Det er en helt annen prosess å «avklare krav i WS og sende ut et oppdatert dokument» enn å «videreutvikle en løsningsbeskrivelse og avstemme innholdet med en kunde som ikke snakker med en tunge». Nødvendig tid for løpende avklaring og godkjenning har gjennomgående vært for optimistisk planlagt. [...] Utfordringene med ulike oppfatninger om styring, en krevende arbeidsform og mangelfull gjennomføringskraft har bidratt til både forsinkelse og økte kostnader. Alle de tre driverne vil etter vårt syn videreføres på samme måte inn i konstruksjonsfasen (KF). SVV tok på seg en del av ansvaret for dette.

Som nevnt under redegjørelsen for sakens bakgrunn, tok løsningsbeskrivelsesfasen dobbelt så lang tid som planlagt, og IBM fremmet krav om dekning av halvparten av merkostnader knyttet til forsinkelsen. I et løsningsskisse utarbeidet av A-2 den 3. juli 2014 går det frem at løsningsforslaget var: basert på at begge parter har et ansvar for at HMP1 ble tre måneder forsinket. Resultatene fra de gjennomførte arbeidsmøtene var ikke på et tilstrekkelig faglig nivå og hadde klare mangler. Dette kan knyttes både til SVV sin medvirkning og IBM sin styring og ledelse av møtene og dokumentproduksjonen. Begge parter var enige på KG2 møtet om at det var nødvendig med en replanlegging og gjennomføring av flere arbeidsmøter for å lukke mangler og heve kvaliteten på dokumentene. [...] Løsningsforslaget innebærer en deling av kostnadene hvor [...] SVV tar sin del av kostnaden primært ut i fra manglende styring på deltakernes input på arbeidsmøtene og en krevende avklaringsprosess. (TU2 1212) Det ble ikke godkjent en omforent usikkerhetsmatrise til HMP1.

Fra august 2014, etter at Anne-Marie Ytrehus overtok etter Stein Ødegaard som delprosjektleder for delprosjektet leveranse, forsvant usikkerhet om egen gjennomføringsevne ut av usikkerhetsrapporteringen i de månedlige statusrapportene. SVVs gjennomføringsevne var likevel et tema i konstruksjonsfasen. Kontraktspartene leverte en fellesrapport om usikkerhetstiltak til KG-møte 24. oktober 2014 hvor både sannsynlighet og konsekvens for risikoen knyttet til SVVs gjennomføringsevne, fikk en score på 3 på en skala fra 1 til 4. (TU2 1443 på 1449) Tiltak fra SVVs side for å håndtere usikkerheten var «Tydelighet ift interessenter» og «Eskaleringer». Denne vurderingen av risiko og tiltak ble inntatt i en oppdatert usikkerhetsmatrise som ble presentert for KG-møte den 18. november 2014. (TU2 1459 på 1461) I møte hos Samferdselsdepartementet 20. oktober 2014 presenterte SVV en intern usikkerhetsmatrise hvor usikkerheten knyttet til egen gjennomføringsevne var satt på «rødt» og var blant de høyeste usikkerhetsmomentene i prosjektet på det tidspunktet. (FU 16216) Sannsynligheten for at risikoen ville inntreffe ble ansett for å være stor

(4) og konsekvensen alvorlig

(4) på en skala fra 1 til 5. Det samme går frem av SVVs presentasjon til SG-møte 25. november 2014. (FU 17469 på 17485) Til SG-møte 23. februar 2015 ble sannsynlighet for at risikoen ville inntreffe redusert til moderat (3), mens konsekvensen ble fortsatt ansett for å være alvorlig (4). (FU 20584 på 20591) Det kan se ut til at SVV i sine interne vurderinger vurderte usikkerheten knyttet til egen gjennomføringsevne til å være høyere enn det som kom til uttrykk i prosjektets usikkerhetsmatrise. Uansett mener lagmannsrettens at de begivenhetsnære bevisene viser at SVV vurderte egen gjennomføringsevne som et betydelig usikkerhetselement gjennom hele prosjektet. Det er lite som tyder på at SVV arbeidet strukturert med å håndtere usikkerheten i konstruksjonsfasen. Som nevnt ble usikkerheten tatt ut av rapporteringen i de månedlige statusrapportene fra august 2014. Anne-Marie Ytrehus forklarte at hun ikke var kjent med den interne usikkerhetsmatrisen SVV utarbeidet mot slutten av løsningsbeskrivelsesfasen. SVVs funksjonelt løsningsansvarlige, Arve Leivestad, kunne heller ikke huske å ha sett den.

Han forklarte videre at det ikke var laget noen beslutningsmatrise i SVV for arbeidet med brukerhistoriene, men at man hadde ulike grader av beslutninger avhengig av brukerhistoriens kompleksitet. 4.4.5.6 Rapporter om fremdriftshindringer i konstruksjonsfasen

Partene er uenige om IBM under konstruksjonsfasen rapporterte til SVV om at fremdriften ble forsinket av SVV. Lagmannsretten konstaterer at det kom ulike rapporter på ulike tidspunkter, og at de til dels var motstridende. Av referatet fra KG-møtet 18. september 2014 – ca. seks uker inn i konstruksjonsfasen – går det frem at «IBM bekrefter at SVV sin deltagelse og bidrag så langt ikke har vært til hinder for fremdriften». (FU 15488 på 15490) Syv dager senere, i e-post 24. september 2014, oversendte imidlertid IBMs prosjektleder, Terje Harangen, en «Flight Deck action Plan» fra en IBM-intern gjennomgang 19.-20. august 2014, til blant annet SVVs hovedprosjektleder Stein Ødegaard, delprosjektleder Anne-Marie Ytrehus og prosjekteier Arve Kirkevold. (FU 15700) «Flight decket» ble oversendt i respons til aksjon KG44 fra KG-møtet 18. september 2014, hvor IBM ble oppfordret til å dele deler av den IBM-interne rapporten med SVV. Rapporten pekte på flere forhold hos SVV som IBM mente var en utfordring for fremdriften.

Forholdene gjaldt blant annet «Sign-off Use Cases – It1», «Process for Handling Requirements, Use Cases», «Low productivity due to communication w/SVV» og «Sign-off process Use-Cases – process IBM/SVV». (FU 15701 på 15705) Samtlige var markert som rødt (alvorlig) på tidspunktet for den interne gjennomgangen og i perioden frem til 15. september 2014. I den påfølgende uke frem til 22. september 2014 var punktet «Low productivity due to communication w/SVV» fortsatt rødt, mens de andre var blitt gule. Lagmannsretten konstaterer at det er motstrid mellom den IBMinterne rapporten som ble delt med SVV, og det som står i referatet fra KG-møtet 18. september 2014. Iterasjon 1 pågikk frem til slutten av september 2014, og 31. oktober 2014 leverte A-2 en rapport til MP1/KP1. (FU 16708) I rapporten observerte A-2 at det gikk for sakte å gjøre avklaringer mellom partene. Det har gjennom iterasjon 1 ikke vært gjennomført en detaljert designavklaring med tilstrekkelig involvering av kunden.

SVV har gjennom iterasjonen hatt en noe avventende holdning til å bistå i arbeidet med å lukke restanser og avklare detaljering av krav og design, samt andre forhold der de lurer på hvorfor ikke IBM spør. (FU 16713) SVVs delprosjektleder Anne-Marie Ytrehus tok opp beslutningsvegring som et tema i prosjektledermøte 5. november 2014. Det går frem av møtereferatet at «SVV uttalte at det pågår mange WS» og at SVV stilte spørsmålet: «Hva kommer ut av disse, det må besluttes! Beslutningsvegring – må tas tak i fra begge parter». (FU 16871 på 16872) I KG-møte 18. november 2014 ser det ut til at de umiddelbare problemene hadde løst seg. Det er referert at «IBM venter ikke på SVV på noen områder som hemmer fremdrift p.t.» og at «SVV ønsker ikke å være til hinder for fremdrift fremover heller og ber IBM om at alle avvik må meldes i fra så raskt som mulig, slik at SVV kan aksjonere i forhold til dette». (FU 17223 på 17225) Den 11. desember 2014 sendte IBMs Nicolai Rygh en e-post til SVVs Anne-Marie Ytrehus om et slikt konkret tilfelle knyttet til «hovedavtale, tilleggsavtale og brikke», jf. punkt 4.4.5.10 nedenfor.

(FU 18053) Videre går det frem av en rekke aksjoner i prosjektstyringsverktøyet Tasks at IBM ventet på avklaringer og svar på aksjonspunkter, jf. punkt 4.4.5.12 nedenfor. 4.4.5.7 Om ansvaret for å bidra til en standardløsning For lagmannsretten ser det klart nok ut til at det var en uttalt målsetning at AutoPASS Grindgut skulle være basert på mest mulig bruk av standardiserte moduler. Målsettingen var i styringsdokumentet for gjennomføring av prosjektet, fremhevet som ett av syv hovedkrav som måtte oppfylles for å oppnå hovedhensikten med prosjektet: Vi skal etablere IKT-løsningen med stor fleksibilitet gjennom modulisering og bruk av mest mulig standardiserte moduler og grensesnitt. Vi skal redusere omfanget av spesialutvikling så mye som mulig. (FU 2785) Videre heter det i styringsdokumentet kapittel 2.5 om anskaffelsesprosedyrer: Anskaffelsen tar utgangspunkt i at bompengebetaling i all hovedsak er standard prosesser som i stor grad ligner på andre virksomheters prosesser. Vi er derfor åpne for at det finnes andre måter å bygge deler av prosessen rundt bompengebetaling på enn i dagens løsning, uten at dette bryter med rammer og

krav. Andre måter å bygge prosesser på åpner for effektiviseringspotensiale ut over det vi ser i dag og det åpner for mulighet for bruk av standardløsninger. Vi legger derfor opp til å spille på leverandørmarkedet for å definere og utvikle endelig løsning. Dette betyr at prosjektet i kravspesifikasjonen holder seg på tilstrekkelig overordnet nivå for å hindre at løsningsrommet låses. (FU 2801) I konkurransegrunnlaget etterspurte SVV bruk av standardsystemer og standardløsninger der det var mulig. Dette kom til uttrykk i to ikke-funksjonelle krav: IF.04.11 Utprøvde løsningskonsept Løsningen skal baseres på utbredte, utprøvde og anerkjente konsepter. Eventuelle rammeverkene (sic) kan være kommersielle produkter eller bestå av åpen kildekode. Utvikling av egne generelle rammeverk skal unngås. (FU 8701) IF.06.07 Standard systemer Løsningen skal bruke standardsystemer og -løsninger hvor det er mulig. Det skal dokumenteres av leverandør at system tilfredsstiller krav om å være et standard system (utbredelse i marked).

(FU 8705) Gjennom utformingen av kravene i kravtabellene ga SVV tilbyderne betydelig spillerom til å tilby standardprodukter og standardprosesser. Mens noen av de funksjonelle kravene var presist og detaljert beskrevet, la mange ingen eller bare generelle føringer på hvordan kravet skulle oppfylles. Dette var et bevisst valg, jf. sitatet fra styringsdokumentet over. SVVs funksjonelt løsningsansvarlige, Arve Leivestad, var leid inn i prosjektet helt fra anskaffelsesfasen. Han forklarte at SVV ønsket å tiltrekke seg tilbydere med ulike løsninger som kunne dekke vegvesenets krav, og at utformingen av kravene hadde til formål at tilbyderne skulle spille inne sine alternative løsninger. IBM tilbød en løsning som bygde på standardmoduler og standardprosesser, og tilpasninger av disse, jf. punkt 3.3.7 og 4.4.4.7.2 over. I tilbudspresentasjonen 27. februar 2013 presiserte IBM at det var «satset på å ikke bygge en kundespesifikk løsning, men å tilpasse en standardløsning til kunden» og at selskapet tolket den omstendighet at det ikke var kravstilt predefinerte prosesser «dithen at vi kan tilby våre standardprosesser».

IBM fremholdt at dette tok selskapet «raskere inn i produksjon og betyr at vi kan kjøre «out of the box» med raskere implementering». (FU 5323 på 5326 og 5332) I revidert tilbud 7. august 2013 (BAFO) understreket IBM igjen at den tilbudte løsningen var «basert på en utstrakt bruk av standard programvare». (FU 6218) Samtidig går det frem av IBMs svar til behovsanalysen (Bilag A) at det ville være behov for tilpasninger i standardmodulene for å oppfylle omtrent halvpartene av kravene. SVV la under evalueringen av innkomne tilbud til grunn at IBMs tilbudte løsning bygde på tilpasning av standardløsninger og aksepterte dette ved aksept av IBMs tilbud. (FU 7089 på 7101, FU 7975 på 7977 og FU 8023 på 8025 og 8030) Fordelen med å bruke standardiserte moduler er at de gir lavere grunnpris og enklere vedlikehold. Ulempene er at de gir mindre brukervennlighet ved spesielle behov, og at tilpasninger i dem er kostbare. Ved bruk av standardiserte moduler, er det ofte en målsetting å begrense omfanget av tilpasninger. (FU 2145 på 2169) SVVs arbeid med usikkerhetsanalysen for Grindgut-prosjektet viser at SVV var klar over dette.

(FU 8232 på 8252 og 8253) SVV identifiserte som usikkerhet nr. 4 «usikkerhet i hvorvidt det igjennom prosjektet vil leveres en løsning som tilfredsstiller kvalitetskravene både teknisk og funksjonelt». Usikkerheten bygde blant annet på at «bruk av standardmoduler har både en opp- og nedside», og at ulempen ved «aksept av bruk av standardmoduler», var at «leverandør vil ønske å benytte standardsystemets prosesser» mens «kundens brukere vil ønske å gjenskape dagens løsning». Tiltak for å håndtere usikkerheten var blant annet at «BS og DS deltar i LBF slik at bruken av leverandørens standardmoduler/-prosesser blir avstemt så tidlig som mulig». (FU 8526) SVV tok ikke med usikkerhet nr. 4 i forslag til usikkerhetsmatrisen som ble inkludert i Bilag A. Holdningen i SVVs prosjektledelse gjennom hele prosjektet, var at man i størst mulig grad skulle benytte IBMs standardmoduler og prosesser. Utfordringen, slik lagmannsretten ser det, var at dette ikke var avstemt med brukerne og SVVs medarbeidere på nivåene under prosjektledelsen.

Målsettingen om mest mulig bruk av standardiserte moduler kom under press fra brukerne tidlig i løsningsbekrivelsesfasen. Den 3. januar 2014 leverte Fjellinjen, Vegamot, Agder Bomdrift og Vegfinans en 25siders rapport som inneholdt «en rekke tydelige krav og behov til nytt sentralsystem Grindgut». (FU 10198) Rapporten ble presentert for SVV i møte 10. januar 2014 hvor bompengeselskapene hevdet at «original

kravspesifikasjon tok utgangspunkt i dagens løsning» mens «bompengeselskapene trenger morgendagens løsning». (FU 10253 på 10255) Rapporten fokuserte på «hvordan vi mener bompengeinnkreving burde gjøres», men var «ikke en fullstendig liste over hva bompengeselskapene og driftsselskapene trenger i Grindgut». Rapporten var heller «ikke avstemt med opprinnelig kravspesifikasjon». (FU10256) Det er ingen tegn i rapporten på at bompengeselskapene forholdt seg til SVVs målsetting om mest mulig bruk av standardiserte moduler. SVVs tilbakemelding på rapporten viser at SVV formidlet til bompengeselskapene at mange av deres ønsker ikke ville bli møtt, og at mange av dem var «utenfor prosjektets mandat». (FU 10472) Rapporten og behandlingen av den etterlater imidlertid et klart inntrykk av at det var et betydelig avvik mellom SVVs og bompengeselskapenes – brukergruppens – forventninger til Grindgut-løsningen ved inngangen til løsningsbeskrivelsesfasen. To endringer fra løsningsbeskrivelsesfasen medførte store avvik fra IBMs standardiserte modulbaserte løsning og utløste behov for skreddersøm.

Det ene var endring av kundebildet og «ett-stegs registrering». Det andre var implementeringen av økonomifunksjonalitet i SugarCRM («SAP-i-CRM»). Lagmannsretten viser til redegjørelsene i punkt 4.4.4.6.2 og 4.4.4.7.2 over. Begge endringer var drevet av bompengeselskapenes brukerbehov. I et notat 27. mars 2014 observerte A-2 at det var «behov for forventningsavklaring mellom partene og overfor interessentene, spesielt Fjellinjen» og at det var nødvendig å avklare «behovet for tilpassede arbeidsprosesser i forhold til målet om mest mulig standard funksjonalitet i systemet (kost/nytte)». (FU 11906 på 11911 og 11915) I utkast til oppdatert usikkerhetsmatrise mot slutten av løsningsbeskrivelsesfasen ble risikoen for at det oppsto «vesentlig avvik fra det som ligger som standardfunksjonalitet i IBMs løsning» inntatt som en ny usikkerhet, antakeligvis etter forslag fra IBM.

(FU 12987 på 12990) På dette tidspunktet ble det ikke foreslått tiltak for å håndtere usikkerheten, men i den oppdaterte og omforente usikkerhetsmatrisen som ble presentert til KG-møtet i november 2014, ble det opprettet et tiltak for IBM om å ha «fokus på standardfunksjonalitet der dette er tilstrekkelig for [å] løse kundens behov». (TU2 1459 på 1463) Samtidig ble det opprettet et nytt tiltak for SVV om å vise «tydelighet ift interessenter». Tiltaket var knyttet til usikkerhetselementet «forsinkelser grunnet kundens evne til å foreta avklaringer og ta beslutninger løpende», som var påvirket av «at det er mange interessenter hos kunden». (TU2 1461) Målsettingen om mest mulig bruk av standardiserte moduler kom under ytterligere press fra brukerne i konstruksjonsfasen. Nye krav til Kundebildet og krav om at adressebestemte fritak og fritak for buss-i-rute skulle legges inn i SugarCRM, utløste behov for skreddersøm, jf. punkt 4.4.4.6.2 og 4.4.4.4.

Det samme gjorde kravene til sakshåndtering, jf. punkt 4.4.4.7.3, krav knyttet til rapportene for brikkelogistikk, jf. punkt 4.4.4.7.6 og økte krav til økonomifunksjonalitet i SugarCRM, jf. punkt 4.4.4.7.2. Kontraktspartene ble utover høsten 2014 og våren 2015 svært uenige om SVV hadde krevd skreddersøm. For lagmannsretten er det tilstrekkelig å vise til at A-2 i rapport til KP2 5. juni 2015 konstaterte: Løsningen inneholder mindre bruk av standard funksjonalitet enn forventet. IBM opplever på den ene siden at SVV ønsker bruk av mest mulig standard funksjonalitet, men på den annen side at de (og brukerne) krever avvik fra eller er lite tilfreds med standard funksjonalitet. Kontraktens krav er også motstridige. (FU 24498 på 24507) A-2s Henning Denstad forklarte at han oppfattet at kontraktspartene var omforent om at standardfunksjonaliteten dekket mindre enn opprinnelig antatt. Han forklarte også at det var et gap mellom den graden av standardisering som SVV ønsket, og de forventningene som bompengeselskapene hadde til en ny løsning. A-2 var usikker på hvor dypt ønsket om standardisering var forankret.

Dette ble tatt opp som en utfordring i A-2s første rapport 14. mai 2014, jf. punkt 4.4.5.5 over og ble, som forespeilet der, en betydelig utfordring utover i prosjektet. SVVs delprosjektleder, Anne-Marie Ytrehus, forklarte at hun ikke gjorde noe spesifikt for å holde bompengeselskapenes forventninger til den nye løsningen på plass, eller for å sørge for at målsettingen om mest mulig bruk av standardiserte moduler ikke kom under press fra brukerne. Hun forventet at IBM skulle komme til henne hvis brukerne kom med krav som ikke var dekket av IBMs tilbudte løsning. Dette var blitt kommunisert til IBM flere ganger, blant annet i KG-møte 18. november 2014 og KG-møte 18. desember 2014. (FU 17223 på 17224 og FU18383 på 18384) Hun fikk imidlertid aldri henvendelser fra IBM om at brukerne krevde funksjonalitet som utløste behov for mer skreddersøm.

SVVs funksjonelt løsningsansvarlige, Arve Leivestad, som deltok i alle arbeidsmøtene i CRM-strømmen, forklarte at han heller ikke gjorde noe spesielt for å styre brukerrepresentantenes forventninger til løsningen. Han hadde ikke noen konkrete eksempler på at han hadde sagt nei til ønsker om tilpasninger fra brukerrepresentantene. Lagmannsretten går nå over til å behandle de konkrete sakene i EA054 som IBM har fremholdt som eksempler på en mer krevende arbeidsform og manglende bidrag til realisering av standardløsning. 4.4.5.8 Fritaksberettigede kjøretøy – buss i rute Arbeidsprosessen rundt fritaksberettigede kjøretøy/buss i rute er nevnt som et eksempel på at det gikk med uforholdsmessig mye tid på avklaringer og at «detaljerte krav [...] dukker opp sent i prosessen». Dette medførte «en økt arbeidsbelastning på Leverandørens ressurser og mer arbeid i gjennomføring ved økt antall WorkShop’s samt etterarbeid». I EA054 står det: Et eksempel på dette er prosessen knyttet til fritaksberettigede kjøretøy. IBM utarbeider et grunnlag med detaljer inn til første Workshop.

I løpet av møtet avdekkes ytterligere detaljer som Leverandøren da må oppdatere for UseCase'et. Ved neste Workshop kommer endre (sic) flere detaljer som igjen fører til nye runder. Dette er en prosess som er avhengig av at Leverandøren må stille de rette spørsmålene for å få ut uttømmende liste av krav i første runde. (FU20014) Hva gjelder den funksjonelle endringen knyttet til fritaksberettigede kjøretøy, viser lagmannsretten til punkt 4.4.4.4, hvor spørsmålet om endring i fritaksregler som grunnlag for kravet i EA053 er behandlet. Lagmannsretten mener at avklaringsprosessen rundt fritaksreglene ble uforholdsmessig lang. Slik det går frem av punkt 4.4.4.4, ble spørsmålet om hvordan fritak skulle håndteres, tatt opp i CRM-arbeidsmøte 4. september 2014. (FU 15214) Lagmannsretten mener at SVV ut av dette møtet fikk i oppgave å avklare hvilke forretningsregler skulle gjelde for fritak.

SVVs funksjonelt løsningsansvarlige, Arve Leivestad, forklarte at han kunne ha tatt en beslutning i arbeidsmøtet, men at han ikke gjorde det fordi han oppfattet at IBM tilbød en fleksibilitet som han ønsket å diskutere med driftsselskaper og bompengeselskaper. Det er ikke gitt noen forklaring på hvorfor en diskusjon/avklaring med andre interessenter ikke kunne skje raskt, slik kontrakten legger opp til. Spørsmål om fritak/buss i rute var oppe i ikke mindre enn syv CRM-arbeidsmøter gjennom september og oktober 2014, uten at en beslutning ble tatt. Først i forbindelse med «avklaringsmøte» 3. november 2014, hvor både SVV og representanter fra flere bompengeselskaper og driftsselskaper deltok, ble det truffet en beslutning som IBM kunne basere sitt design på. (FU 16855) Lagmannsretten bemerker at det var på dette tidspunktet at prosjektleder Anne-Marie Ytrehus uttrykte seg om beslutningsvegring, jf. over. 4.4.5.9 Audit fields (revisjonsspor) Det andre eksemplet på at arbeidsprosessen ble uforholdsmessig lang og ressurskrevende, er prosessen rundt audit fields (revisjonsspor).

IBM gjør gjeldende at den langvarige beslutningsprosessen førte også til merarbeid på ni brukertilfeller som allerede var avsluttet til iterasjon 1 (UC_AM_ADM_01 til 03 og 05 til 10). Detaljering av kravene til revisjonsspor av felter for kunder, avtaler, konto og adresser ble tatt opp i det første CRM-arbeidsmøte i konstruksjonsfasen 15. august 2014. (FU 14655 på 14656) Av møtereferatet går det frem at SVV fikk i oppgave å foreslå en «list of tracked changes». Lagmannsretten legger til grunn at dette var forretningsregler som SVV hadde ansvar for å skaffe. I neste arbeidsmøte 27. august 2014 fikk SVV i oppgave å foreslå en «list of audit fields». (FU 14693 på 14964) Lagmannsretten oppfatter at dette er det samme aksjonspunktet som i det forrige arbeidsmøtet. IBM fikk i oppgave å oversende «LDM doc & suggestions from GD». Dette ble fulgt opp av IBM 29. august 2014. IBM oversendte da en presentasjon til SVV med en liste over de feltene som det kunne være aktuelt å opprette et revisjonsspor på.

(FU 15129 og 15133) På den første siden av presentasjonen går det frem at IBM hadde identifisert alle aktuelle felter for alle modulene, men at antall felter som det skulle opprettes revisjonsspor på, kunne påvirke ytelsen på løsningen. Spørsmålet om revisjonsspor var oppe i arbeidsmøte 1. september 2014. (FU 15185) Aksjonen for SVV ut av dette møtet var å fortsette gjennomgangen («continue reviewing»). Aksjonen for SVV ut av arbeidsmøtet 9. september 2014 var: «Prepare to finish audit walkthrough next meeting Thursday Sep 11th». (FU 15268 på

15269) Det går frem av møtereferatet at SVV ble bedt om å gi sine kommentarer senest innen 16. september 2014 hvis de skulle tas i betraktning for iterasjon 1. Det er ikke fremlagt noe referat fra et arbeidsmøte 11. september 2014, og det er for lagmannsretten uvisst om det ble holdt et arbeidsmøte den dagen. Avklaringen kom imidlertid for sent for iterasjon 1. SVV traff en beslutning om hvilke felter det skulle opprettes revisjonsspor på den 2. oktober 2014. (FU 15842) Det er for lagmannsretten vanskelig å forstå hvorfor det tok så lang tid for SVV å beslutte hvilke felter det skulle opprettes revisjonsspor på. SVVs funksjonelt løsningsansvarlige, Arve Leivestad, forklarte at han oppfattet det som merkelig at IBM stilte spørsmål rundt revisjonsspor da SVV var vant med å ha revisjonsspor i CS Norge. Slik lagmannsretten ser det, underbygger Leivestads forklaring at det burde ha vært enkelt for SVV å avklare spørsmålet raskt dersom vegvesenet ønsket samme løsning i Grindgut. SVV fikk raskt et godt beslutningsunderlag fra IBM med oversendelse av presentasjonen 29. august 2014.

Presentasjonen inneholdt en «smørbrødliste» over aktuelle felter, og det burde vært enkelt for SVV å markere sine ønsker på presentasjonen, noe som også Leivestad bekreftet i sin forklaring. Tonje Offenberg Bye forklarte imidlertid at SVV ikke kom med noe svar på egen hånd, og at IBM måtte sitte sammen med SVV i møter og gå gjennom presentasjonen for å få en avklaring, noe som stjal tid. 4.4.5.10 Avtalestruktur I likhet med de foregående eksemplene, gjelder eksempelet «avtalestruktur» sendrektig avklaring av forretningsregler som det var SVVs ansvar å avklare og avgjøre. IBM har også fremmet en funksjonell endringsanmodning EA076 CRM Avtalestruktur. Lagmannsretten behandler ikke EA076 særskilt, jf. punkt 4.4.7.1 nedenfor, og ser heller ikke behov for å behandle den for å ta standpunkt til EA054. Spørsmålet her er ikke om «CRM Avtalestruktur» var en endring, men om arbeidsprosessen rundt avtalestruktur ble uforholdsmessig lang og ressurskrevende.

Ved e-post 11. desember 2014 til SVVs Anne-Marie Ytrehus varslet IBMs Nicolai Rygh at det i arbeidsmøter «stadig dukker opp nye kombinasjoner» for «hovedavtale, tilleggsavtale og brikke [...] som har betydning for valg som må / ikke må være tilgjengelig for sluttbrukeren». (FU 18053) IBM mente at disse kombinasjonene verken var beskrevet i Bilag A (behovsanalysen) eller i løsningsbeskrivelsen. Rygh skrev at han forventet at SVV hadde «oversikt over gyldige kombinasjoner» som SVV kunne sende til IBM «slik at vi kan ta en gjennomgang for å se hva som er dekket i løsningsbeskrivelsen, og hva som må håndteres». Den 16. desember 2014 sendte SVVs funksjonelt løsningsansvarlige, Arve Leivestad, e-post til Tonje Offenberg Bye m.fl. med en 13 sider lang presentasjon som, ifølge e-posten, «illustrerer ulike varianter av avtalestruktur og koblinger mellom kjøretøy/brikke/ avtaleeier». (FU 18338 flg) Videre skrev Leivestad: Denne listen er ikke ment å være en fullstendig systematisk beskrivelse. Det kan være ytterligere nyanser til hver case som ikke kommer frem i bildet.

Det er ikke gitt noen forklaring på hvorfor SVV ikke kunne sende over en uttømmende liste over gyldige (gjeldende) kombinasjoner så sent i prosjektet. Staten har vist til at IBM tidlig i løsningsbeskrivelsesfasen fikk i oppgave å foreslå en forenklet avtalestruktur da gjeldende avtalestruktur var «mangfoldig og ulik benyttet fra ulike BS». (FU 10703) Lagmannsretten kan ikke se at dette er relevant her. Poenget er at det i arbeidsmøter i konstruksjonsfasen oppsto behov for avklaringer som det var SVVs ansvar å bidra til å løse opp i. Tonje Offenberg Bye forklarte at IBM, istedenfor å kunne ta utgangspunkt i en systematisk beskrivelse av gjeldende kombinasjoner, måtte holde flere møter med SVV for å få den nødvendige informasjon, noe som stjal tid. At det ble holdt flere arbeidsmøter for å gå gjennom aktuelle scenarier og kombinasjoner med SVV og finne omforente formuleringer på forretningsreglene, synes heller ikke å være bestridt. 4.4.5.11 Bompakke Arbeidsprosessen rundt «bompakke» (Toll entities) er også nevnt i EA054 som et eksempel på en arbeidsprosess som ble uforholdsmessig lang og ressurskrevende.

Prosessen rundt utarbeidelse av brukerhistoriene for bompakke er beskrevet i punkt 4.4.4.7.5 over, og lagmannsretten viser til redegjørelsen der.

4.4.5.12 Aksjoner i «Tasks» Til støtte for sitt krav i EA054 har IBM vist til oppgaver/aksjoner i prosjektstyringsverktøyet «Tasks» som ble allokert til SVV, men som enten ikke ble besvart eller ble sent besvart. Staten har gjort gjeldende at eksemplene fra Tasks ikke er av et slikt omfang at de kan påvise at IBMs fremdrift ble hindret av manglende og forsinkede avklaringer fra SVV. Staten har også gjort gjeldende at flere av oppgavene var besvart selv om dette ikke er synlig i Tasks, og at IBM uansett har unnlatt å undersøke om kontraktspartene bare har glemt å føre avklaringene inn i Tasks. Fra konstruksjonsfasen har IBM vist til aksjon 9.36, «Avklaring rundt distribusjonskanal (fakturaer osv)», som ble tatt opp av Tonje Offenberg Bye i CRM-møte 2. september 2014 og lagt inn i Tasks 5. september 2014 med en dags frist for SVV å besvare. (FU 15216) Aksjonen ble først lukket 4. februar 2015. Aksjon 9.36 er beslektet med aksjon 9.39 «Avklar fakturamåte (brev, e-post..)».

(FU 15709) Denne aksjonen ble først opprettet som en aksjon for SVV i CRM-arbeidsmøte 23. september 2014, men opprettet i Tasks 15. november 2014 med frist for svar fra SVV 17. november 2014. (FU 15671) Aksjonen var ikke lukket i Tasks på hevingstidspunktet. Staten har gjort gjeldende at aksjonene 9.36 og 9.39 ble besvart senest 23. oktober 2014. Det er vist til at beskrivelsen av basisflyten for UC_AM_05 (Ny avtale) i dokumentet «Use Case Model Account Management» versjon 2.15 datert 23. oktober 2014, inneholdt den løsningen som kontraktspartene var blitt enige om. Lagmannsretten mener at det har formodningen mot seg at i hvert fall aksjon 9.39 var kvittert ut 23. oktober 2014 ettersom oppgaven ble opprettet i Tasks etter denne datoen. SVVs funksjonelt løsningsansvarlige, Arve Leivestad, forklarte at han brukte Tasks aktivt. Lagmannsretten mener at det er mest sannsynlig at han ville ha sørget for at aksjonen ble lukket dersom oppgaven allerede var løst.

Det at dokumentet «Use Case Model Account Management» inneholder den løsningen som kontraktspartene landet på, utelukker heller ikke at det var diskusjon rundt temaet og behov for avklaring, slik lagmannsretten ser det. Utover høsten 2014 ble det utarbeidet ikke mindre enn 44 versjoner av dokumentet, og mange av stegene i basisflyten var gjenstand for endringer, jf. punkt 4.4.4.7.4 over. Aksjon 9.47 «Definer forretningsregel for validering av utenlandske organisasjonsnumre», ble opprinnelig opprettet som en aksjon for SVV i CRM-arbeidsmøte 15. august 2014 og opprettet som en aksjon for SVV i Tasks 15. november 2014. (FU 14655 på 14656 og FU 15708) Fristen var 17. november 2014, men aksjonen var ikke lukket i Tasks på hevingstidspunktet. Staten har gjort gjeldende at IBM allerede 14. oktober 2014, var kjent med at det ikke fantes forretningsregler rundt format for utenlandske organisasjonsnumre.

Staten har vist til aksjon 9.67, «Format på organisasjonsnummer», opprettet i Tasks 14. oktober 2015 hvor det går frem at «for utenlandske organisasjoner er det ikke identifisert forretningsregler rundt format, disse vil dermed ikke bli verifisert, kun sjekket at er unike». (TU2 1440) Det er også anført at IBM burde ha funnet ut av dette selv. Lagmannsretten mener at det har formodningen mot seg at det ble opprettet oppgaver i Tasks på spørsmål som allerede var avklart eller løst, uten at SVV reagerte og sørget for at oppgaven ble lukket, jf. over. Slik lagmannsretten ser det, er det mer nærliggende å tolke aksjon 9.67 slik at aksjonen med å definere forretningsregel for validering av utenlandske organisasjonsnumre, ennå ikke var besvart/lukket. Aksjon 9.67 var heller ikke lukket på hevingstidspunktet. Det å definere forretningsreglene var SVVs ansvar. Det er uten betydning at IBM eventuelt kunne ha funnet ut av dette selv.

Aksjonen 9.66 «Kjøretøysopplysninger», med spørsmål om hvilke opplysninger som skulle være påkrevd for kjøretøy som ble lagt inn manuelt, ble opprettet som en aksjon for SVV i Tasks 14. oktober 2014 med frist 21. oktober 2014. (TU2 1439) Staten har gjort gjeldende at aksjonen ble besvart i møte 16. oktober 2014, mens IBM har gjort gjeldende at den kun delvis ble besvart. (FU 16168) Aksjonen står som påbegynt i Tasks 14. oktober 2014, men var ikke lukket på hevingstidspunktet. Slik lagmannsretten ser det, var aksjonspunktet stort sett besvart i CRM-møtet 16. oktober 2014, men det var fortsatt spørsmål som trengte avklaring. Av møtereferatet går det frem at SVV var «usikker om næringskode skal være med» og «usikker om det er flere koder for utrykningskjæretøy».

Aksjon 9.65 knyttet til avklaring av forretningsregel for «Maxi taxi» ble opprettet som en aksjon for SVV i Tasks 13. oktober 2014 med frist 22. oktober 2014. (FU 16018) Aksjonen står som påbegynt i Tasks 21. oktober 2014, men var ikke lukket på hevingstidspunktet. Staten har gjort gjeldende at aksjonen ble besvart i møte 16. oktober 2014. (FU 16168) Slik lagmannsretten ser det, var aksjonen delvis besvart i CRM-møtet 16. oktober 2014, men det var fortsatt spørsmål som måtte «sjekkes opp» og som SVV ikke klarte å svare på. Lagmannsretten er enig med staten i at eksemplene fra Tasks som IBM har vist til, alene ikke er av et slikt omfang at de påviser at IBMs fremdrift ble hindret av manglende og forsinkede avklaringer fra SVV.

Lagmannsretten mener imidlertid at de støtter opp under de konkrete eksemplene som det er vist til i EA054, og at de underbygger at avklaringer tok uforholdsmessig mye tid. 4.4.5.13 EA054 – konklusjon I sum mener lagmannsretten at det er sannsynliggjort at arbeidsformen og -prosessen med å utarbeide brukerhistoriene i CRM-strømmen ble annerledes og vesentlig mer arbeidskrevende enn den som ble lagt til grunn for kontrakten, og at SVV ikke bidro tilstrekkelig til å begrense omfanget av skreddersøm slik at en standard løsning kunne realiseres. Lagmannsretten mener videre at dette hadde konsekvenser for fremdriften. IBM har krevd fristforlengelse og flytting av milepæler med 42 kalenderdager. Lagmannsretten mener at kravet er høyt, og at 28 kalenderdager er et mer rimelig estimat av forsinkelsen. Lagmannsretten mener videre at IBM må bære en del av ansvaret for at prosessen med å utarbeide brukerhistoriene ble mer arbeidskrevende. Lagmannsretten viser til at IBM i medhold av Bilag B punkt 2.5.3 og 2.5.5 hadde det overordnede lederansvaret for arbeidet i alle kontraktfasene.

(FU 9075 og 9077) Dette tilsier at IBM hadde ansvar for å treffe tiltak for å bringe arbeidsformen inn i et mer konstruktivt spor slik at den ikke hindret fremdriften. SVV hadde en medvirkningsplikt, men begge parter hadde et ansvar for en effektiv prosess. Lagmannsretten viser også til at A-2 i notat 13. april 2015 påpekte at en del av årsaken til problemene som oppsto, var at prosessbeskrivelsen for detaljering av design med involvering fra SVV som ble definert og gjennomgått ved oppstart av konstruksjonsfasen, ikke ble fulgt. (FU 22334) Dette var IBMs ansvar. Manglende involvering av SVV i detaljering av design var også påpekt i A-2s rapport 5. juni 2015. (FU 24506/7) Slik lagmannsretten ser det, bidro også IBMs komplekse organisering og lange kommunikasjonslinjer til at arbeidet med å utarbeide brukerhistoriene ble mer arbeidskrevende enn forventet, jf. punkt 3.2 og 3.3.3.5. Lagmannsretten utelukker heller ikke at IBMs vansker med å skaffe relevant og tilstrekkelig kompetanse på CRM- og SAP-strømmene, hadde betydning for den arbeidsformen som utartet seg.

Lagmannsretten mener etter dette at begge kontraktspartene må bære ansvaret for de tidsmessige konsekvensene av EA054. Sett hen til at kontraktspartene hadde inngått en samspillskontrakt, og i mangel av andre klare holdepunkter, mener lagmannsretten at ansvaret må deles likt. Lagmannsretten konkluderer med dette at IBM gis medhold i at EA054 gir krav på fristforlengelse med 14 kalenderdager.

4.4.6 EA067 Greenbird EA067 gjelder merarbeid som følge av IBMs deltakelse i arkitekturvurderingen av Grindgut som SVV bestilte fra Greenbird Consulting AS og som ble gjennomført i perioden januar/februar 2015, jf. punkt 3.3.8 over. IBM har krevd fristforlengelse med to kalenderdager og kostnadsdekning med 277 465 kroner. Staten er enig i at EA067 utgjør en endring, men er uenig i at IBMs deltakelse i Greenbirds gjennomgang hadde tidskonsekvenser for Grindgut som gir krav på fristforlengelse. SVV er også uenig i IBMs kostnadskrav. EA067 ble opprettet av SVV ved Nina Jørgensen 5. mars 2015. (FU 20868) SVV foreslo å utstede en endringsordre på 171 339 kroner for 120 timer medgått til IBMs deltakelse i Greenbirds gjennomgang. IBM svarte på EA067 15. april 2015 og gjorde gjeldende at timene medgått til deltakelse i Greenbirds gjennomgang måtte faktureres som «øvrig arbeid». (FU 22515) IBM krevde samtidig fristforlengelse med to kalenderdager for forsinkelse som følge av prosjektledernes deltakelse i gjennomgangen. I IBMs svar heter det:

SVV har benyttet IBMs ressurser for å gjøre et review som ikke er regulert av krav kontrakten. SVV anmodet IBM om [...] å være med på review men det ble presisert fra SVV at omfanget var begrenset og ikke skulle gå ut over produksjon av leveranser. IBM har loggført alle timer medgått til review og mener at antall timer medgått langt overgår de timer som ble antydet før oppstart av review. Videre har review medført at sentrale ressurser har benyttet sine timer på dette review i stedet for å produsere leveranser på kritisk linje i prosjketet. Timene medgått anses derfor som «øvrige arbeid», og SVV bes ustede en EO for å dekke kostnaden. ... GD leveransene knyttet til CRM, INT og ARC har blitt forsinket pga Kundens bruk av henholdsvis Svein Rimestad, Tonje Bye og Wenche Brateng. Kostnad for ventetid i GD utgjør derfor 2 dager av henholdsvis AR, CRM og INT. ... Forsinkelse fastsettes derfor til 277 465 kroner. Tingretten kom til at EA067 var berettiget og ga IBM medhold i både kostnadskravet og fristforlengelseskravet.

I dommen på side 108 heter det: Bistanden fant sted i en fase hvor IBM hadde høyt fokus på å ferdigstille iterasjon 2, og der GD hadde behov for jevnlige tilbakemeldinger fra det norske prosjektteamet. Innvirkningen på prosjektorganisasjonen til IBM var derfor mest sannsynlig slik de har anført, herunder kostnadene for ventetid i GD. Endringsanmodningen fremstår således som riktig og rimelig. IBM har rett til økning av målpris med vederlaget beskrevet i EA067. Kravet om 2 dager fristforlengelse anses også som berettiget. Staten har som nevnt bestridt både IBMs kostnadskrav og krav om på fristforlengelse. Standpunktet er imidlertid ikke nærmere begrunnet under ankeforhandlingen. Det er således ikke kommet anførsler eller bevis som gir lagmannsretten grunnlag for å overprøve tingrettens vurdering. Lagmannsretten legger derfor tingrettens vurdering til grunn, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd.

4.4.7 EA078 Kina-saken 4.4.7.1 Innledning og partenes anførsler EA078 – «hindre eksponering av produksjonsdata i Kina» – ble opprettet av SVV ved Arve Ryan 16. mars 2015. (FU 21233) Under overskriften «Beskrivelse av ønsket endring» står det følgende: Statens vegvesen har i brev varslet IBM om at de har oppdatert sin sikkerhetsvurdering og landrisiko. Som følge av dette skal produksjonsdata generelt og persondata spesielt ikke være eksponert i Kina. Med eksponert menes her at data ikke skal kunne finnes i Kina (dette omfatter alle typer tilgang fra Kina). Med Kina menes innenfor de geografiske grensene til Folkerepublikken Kina. [...] Statens vegvesen ber IBM om en beskrivelse av hvordan dette skal løses teknisk og administrativt og hvilke konsekvenser det har. Beskrivelsen skal omfatte konsekvenser både for utviklingsfasen og for forvaltningsperioden. IBM har gjort gjeldende at EA078 er en endring til kontrakten som SVV ville ha bestilt, og som ville gitt selskapet krav på fristforlengelse med 90 kalenderdager.

Staten har på sin side gjort gjeldende at EA078 ikke gir grunnlag for fristutsettelse, og at IBM må bære de eventuelle tidsmessige konsekvensene av endringen. IBM hadde uavhengig av SVVs oppdaterte sikkerhetspolicy, ikke rett til å behandle, og dermed ikke rett til å eksponere, personopplysninger i Kina i konstruksjonsfasen. IBM er ansvarlig for eventuelle forsinkelser forbundet med å innføre tiltak for å hindre eksponering av personopplysninger der. EU-kommisjonen har ikke godkjent Kina som et land som har regler som ivaretar personvernet på tilsvarende måte som land i EØS-området. Overføring og annen behandling av personopplysninger i medhold av daværende personopplysningsloven § 29 var dermed utelukket. Kontraktspartene hadde ikke inngått noen EU standardkontrakt (EU Model Clause) som ville tillatt behandling av personopplysninger i Kina, og SVV var ikke forpliktet til å inngå en slik kontrakt. Det var IBMs valg av

Kina som utviklingslokasjon sammen med IBMs manglende etablering av sikkerhetsrutiner for å hindre eksponering av produksjonsdata i Kina som foranlediget tiltak fra SVVs side, herunder bestilling av datasikkerhetsprogrammet «Guardium» for å skjerme personopplysninger utenfor EU (EO048), og utstedelse av EA078. (FU 21225) IBM opplyste at Guardium ville løse alle problemene knyttet til å sikre persondata mot tilgang fra Kina, både under utvikling, test og produksjon. Kina-saken ble under prosjektgjennomføringen ansett for å være et potensielt stor utfordring for avtalene om vedlikehold og drift. Det er ingen holdepunkter i begivenhetsnær dokumentasjon for at Kina-saken ville ha nevneverdig konsekvenser for Leveranseavtalen. SVV ga uttrykkelig beskjed om at man skulle kjøre videre til nødvendig kompetanse og roller var på plass utenfor Kina. Behovet for ressursene fra Kina ville først ha oppstått i april/mai 2016. Det var derfor god tid for å få ressursene fra Kina på plass.

IBM påberopte seg tiltak som umulig kunne være en konsekvens av Kinasaken for Leveranseavtalen. 4.4.7.2 Lagmannsrettens syn Staten kan ikke få medhold i at IBM må bære konsekvensene av forsinkelsen som oppstod som følge av Kinasaken. Det er ikke omtvistet at IBMs offshoremodell går frem av Bilag B, og SVV visste helt fra tilbudsfasen at deler av utviklingen ville foregå i Kina. Etter kontrakten skulle imidlertid alt utviklingsarbeid i Kina, inkludert migreringstesting, foregå uten bruk av produksjonsdata/personopplysninger. Det var derfor ikke nødvendig å regulere overføring og behandling av personopplysninger med en EU standardkontrakt eller andre tiltak for å hindre eksponering av produksjonsdata i Kina. Etter Bilag C punkt 4.3.12 hadde SVV plikt til å skaffe anonymiserte testdata for bruk i migreringstest. (FU 9132) SVV fikk imidlertid problemer med å oppfylle denne plikten, og kontraktspartene måtte underveis i prosjektet endre migreringsstrategi til å ta i bruk produksjonsdata som inneholdt personopplysninger i migreringstesting.

En EU standardkontrakt ville løst denne utfordringen hadde det ikke vært for at SVVs endrede sikkerhetspolicy ikke under noen omstendighet tillot overføring av personopplysninger til land utenfor EU. Lagmannsretten finner det klart at både EO048 (Guardium) og EA078 (hindre eksponering av produksjonsdata i Kina) var foranlediget av forhold på SVVs side, nemlig endringene i migreringsstrategien kombinert med endringen i SVVs sikkerhetspolicy. Begge strategiene ble endret etter at kontrakten ble inngått. SVV må derfor bære risikoen og ansvaret for de tidskonsekvensene dette hadde for prosjektet. Både EO048 (Guardium) og EA078 synes å være direkte foranlediget av rapporten «Grindgut sikkerhetsgjennomgang», som ble utarbeidet av KPMG på oppdrag fra SVV. (FU 20466) I innledningen til rapporten, som ble overlevert 19. februar 2015, går det frem at SVV i oppdragsbeskrivelsen hadde oppgitt følgende som bakgrunn for oppdraget: Vegvesenet har besluttet skjerpede interne regler for håndtering av personopplysninger.

Med skjerpet menes at de er strengere enn de generelle lovene for personvernopplysninger, og innebærer blant annet at persondata ikke skal kunne aksesseres fra land utenfor Europa. Disse endringene er innført etter kontraktsdato med leverandør av Grindgut prosjektet. Leverandøren utfører store deler av systemutviklingen og forvaltningen i lavkostland. Hovedtyngden av leverandørens personale befinner seg derfor i India og i Kina. (FU 20469) KPMG påpekte i rapporten at det ikke var inngått noen avtale om overføring av personopplysninger til utlandet, og heller ikke noen EU standardkontrakt som ville ha muliggjort overføring av personopplysninger til land utenfor EU. Da vedlikehold av deler av løsningen etter kontrakten skulle gjøres fra Kina, ville personopplysninger bli eksponert til ressurser der, og tiltak for å sikre informasjonssikkerhet i henhold til personopplysningsloven måtte iverksettes før vedlikeholdsperioden ble igangsatt.

KPMG påpekte, slik lagmannsretten har vist til, at slike tiltak i utgangspunktet ikke var nødvendige i konstruksjonsfasen, da utvikling og test var planlagt gjennomført uten bruk av produksjonsdata og dermed personopplysninger. Underveis i prosjektet var det imidlertid avdekket at det kunne oppstå behov for produksjonsdata i test av migrering, som var planlagt gjennomført før HMP2. Om dette skrev KPMG: Prosjektet har gjennom workshops jobbet seg frem til alternative migreringsstrategier og konkludert med å endre migreringsstrategi fra den som er avtalt i kontrakten. Endelig migreringsstrategi er per rapportdato ikke fastlagt. I henhold til leveransekontrakten skal kunden fremskaffe anonymiserte testdata. Dersom

leveranseprosjektet kun benytter anonymiserte testdata vil ikke personopplysninger være eksponert i denne fasen og personopplysningsloven [er] irrelevant med tanke på systemtilgang fra tredjeland. I intervjuer har det fremkommet at prosjektet så langt ikke har lykkes med å produsere anonymiserte testdata som vil sikre en fullverdig test av migreringen. Partene har derfor diskutert mulig behov for bruk av produksjonsdata i stedet. Dersom arbeidet med ny migreringsstrategi resulterer i at produksjonsdata som inneholder personopplysninger vil bli brukt til testmigrering vil personopplysningsloven være relevant i testfasen. Det betyr at tiltak som beskrevet i observasjon 1 må være implementert innen migreringstestingen kan starte. (FU 20475) KPMG identifiserte i «observasjon 1» tre mulige, alternative tiltak for å løse sikkerhetsutfordringene ved overføring av personopplysninger til land utenfor EU. Det første alternativet var å inngå en EU standardkontrakt med selskapene som håndterte personopplysninger i utlandet.

SVVs endrede sikkerhetspolicy tillot imidlertid ikke under noen omstendigheter overføring av personopplysninger til land utenfor EU. Denne løsningen var derfor ikke aktuell, verken i konstruksjonsfasen eller i vedlikeholdsfasen. Det andre alternativet var å hindre at medarbeidere i tredjeland fikk tilgang til personopplysningene i Grindgut-løsningen, og det tredje alternativet var å flytte eller erstatte ressurser i tredjeland. Det er flere forhold som etter lagmannsrettens syn underbygger at SVV så på konsekvensene av endringene i egen migreringsstrategi og sikkerhetspoilcy som sitt ansvar. Det første forholdet er det enkle faktum at det var SVV som tok initiativet til å opprette EO064 og EA078. Dette tyder i seg selv på at SVV oppfattet bestillingen av Guardium og det å hindre eksponering av produksjonsdata i Kina, som endringer til kontrakten som SVV hadde ansvar for. Det andre forholdet er SVVs egen omtale av «Kina-saken» i de begivenhetsnære bevisene.

Da funnene fra KPMGs sikkerhetsgjennomgang ble presentert for SVVs styringsgruppe i møte 20. mars 2015, ble EA078 omtalt som et nytt krav fra SVV ang. håndtering av bruk av selskap i Kina til utvikling og forvaltning. Dette kan bli en potensiell større endring. Vi venter på endringsanalyse fra IBM. (FU 21449) Videre går det frem av referatet fra KG-møte 17. april 2015 at SVV var innforstått med at deres krav om endring ville få betydning for tidsplanen: Kunden har varslet begrensninger knyttet til Kina som vil påvirke tidsplanen. Dette må avklares snarest slik at planverket kan reflektere dette. SVV venter på konsekvensanalyse fra IBM (EA078) på dette. Når analysen foreligger kan partene sammen jobbe for at konsekvensen for tidsplanen blir så liten som mulig. (FU 22624 på 22626) Det tredje forholdet er bestilling av datasikkerhetsprogrammet Guardium gjennom utstedelse av EO048 14. mars 2015, kort tid etter at KPMGs rapport ble overlevert SVV.

Bakgrunnen for endringsordren er beskrevet slik: Statens vegvesen har etter kontraktsinngåelse stilt krav om skjerming av personopplysninger utenfor EU og vil benytte produktet IBM InfoSphere Guardium for dette. Dette produktet skal settes opp slik at det skjermer dataene som er lagret sentralt, slik at kun autoriserte brukere vil se umaskerte data. Det vil både gjelde personopplysninger i produksjon og test. (FU21225) Bestillingen av Guardium hadde ikke tidsmessige konsekvenser for prosjektet, men SVV påtok seg uten videre kostnadene ved bestillingen. Det var aldri et tema at IBM måtte bære noen del av kostnadene, eller at IBM hadde noe ansvar for skjerming av personopplysninger utenfor EU, verken i konstruksjonsfasen eller i vedlikeholdsfasen. Et fjerde forhold er prosessen rundt EA078. EA078 ble opprettet av SVV 16. mars 2015, bare to dager etter at EO048 (Guardium) ble undertegnet. Begrunnelsen for EA078 er identisk med begrunnelsen for EO048. Bakgrunnen for at SVV utstedte EA078 synes å være at SVV var usikker på om Guardium alene var tilstrekkelig til å sikre informasjonssikkerhet i henhold til SVVs endrede sikkerhetspolicy.

Slik det fremgår over ba SVV i EA078 IBM om å beskrive hvordan sikkerhetsutfordringene som fulgte av endringene i SVVs sikkerhetspolicy skulle løses teknisk og administrativt, og hvilke konsekvenser dette ville ha for utviklingsfasen og forvaltningsperioden. IBM ved Nicolai Rygh sendte utkast til konsekvensanalyse til SVV ved Arve Ryan 20. april 2015. (FU 22906) Under «Beskrivelse av foreslått endring» skrev IBM blant annet følgende: Leverandøren har vurdert brevet mottatt av SVV, og avgitt en foreløpig rapport. Denne er gjennomgått med SVV. Og basert på en vurdering av behovet for å skjerme løsningen foreslås det å utstede endringsordre for å reflektere følgende Endringsbehov Merkantile endringer PS2000:

1. Flytte Rational og kode repository fra IBMs kinesiske datasenter til BF [Basefarm] eller IBM i EUsonen
2. Utvide SAP kapasiteten lokalt med 2 ABAP, og 1 SAP FI konsulent frem til HMP2.2
3. Flytte 2 ressurser fra GSBC fra Kina til Norge frem til HMP2.2
4. Flytte all integrasjonsarbeid til India som pt foregår i Kina Administrative endringer PS2000:
5. Blokkere tilgang til BF-miljø med produksjonsdata med IDer i Kina
6. Utstede lokale norske identer for ressurser plassert i Norge eid av norsk personalansvarlig Det vurderes som trolig at aksjon 3 vil forsinke prosjektet pga den tiden norske myndigheter vil bruke på å godkjenne midlertidig arbeidstillatelser for de Kinesiske medarbeiderne. Samtidig vurderes det at en økning av SAP kompetanse lokalt vil være med på å redusere risiko for feil i løsningen, og samtidig også øke kapasiteten som kan bidra inn i avklaringer som vil redusere risiko også for migrering av finansielle data.

Til spørsmålet om endringen ville påvirke prosjektets fremdriftsplan, besvarte IBM «Ja, hvor mye må vurderes».

Den 30. april 2015 ga SVV ved Arve Ryan «konkret tilbakemelding» på punktene i IBMs konsekvensanalyse. (FU 23455) Til punkt 1 skrev SVV at det ville «avhenge av Guardium diskusjonen om dette er nødvendig før HMP3», mens punkt 2 og 3 var «avhengig av Guardium-diskusjonen om dette må være på plass før HMP2.2». Til punkt 4 til 6 skrev SVV kort at tiltaket var «OK». Det er ikke spor av at SVV mente at IBM måtte bære ansvar for noe av dette.

Den 5. mai 2015 skrev SVV ved Arve Ryan igjen til IBM ved Nicolai Rygh i anledning EA078, med beskjed om at tiltaket med å flytte ressurser fra Kina måtte opprettholdes, men at man i en overgangsfase skulle arbeide ut fra at implementering av Guardium var tilstrekkelig for å trygge sikring av produksjonsdata. (FU 23455) Slik lagmannsretten ser det, erkjente SVV her at flytting av ressurser fra Kina var et nødvendig tiltak for å løse problemet på sikt:

Dataeier og systemeier kan på nåværende tidspunkt ikke si om (riktig oppsatt) Guardium i seg selv er tilstrekkelig på lang sikt for å ivareta krav om at produksjonsdata ikke skal være eksponert i Kina. Vi må derfor opprettholde tiltaket med å flytte personer ut av Kina. Dette skal derfor omfattes av konsekvensutredningen. [...] I en overgangsfase, inntil nødvendig kompetanse og roller er på plass utenfor Kina, arbeider vi fortsatt ut fra at bruk av Guardium og andre administrative og tekniske tiltak vil være tilstrekkelig. Dvs at arbeidet kan fortsette som planlagt, f.eks. med testdata i migreringsstrømmen.» Igjen er det ikke spor av at SVV mente at IBM måtte bære ansvar for dette tiltaket.

Det femte forholdet som underbygger at SVV var ansvarlig for konsekvensene for prosjektet av den potensielle eksponeringen av produksjonsdata i Kina, er SVVs opprettelse av EO064 (Preventive aksjoner grunnet EA078). (FU 24760) Ved denne endringsordren erkjente SVV forpliktelsen til å bære kostnadene for mobilisering av lokale tilleggsressurser og IBMs kostnader knyttet til søknader om arbeidstillatelser for to ressurser fra GBSC Kina. EO064 ble opprettet av SVV ved Arve Ryan 10. juni 2015 og ble lagt til signering 11. juni 2015. (FU 24762) IBM eskalerte den til Koordineringsgruppen 25. juni 2015 etter at SVV varslet at signeringen var tilbakeholdt i medhold av Leveranseavtalen Del II punkt 6.3.1 fordi SVV mente at IBM var i

vesentlig mislighold og hadde varslet heving av kontrakten. (FU 25160, 25292 og 25964) EO064 var fortsatt ikke signert på hevingstidspunktet. Lagmannsretten mener at SVVs tilbakehold av signeringen av EO064, var urettmessig. EO064 omfatter kostnader knyttet til økning i bemanningen i Norge med tre lokale ressurser i perioden 1. til 29. mai 2015, jf. punkt 2 i IBMs konsekvensanalyse sitert over, og kostnader knyttet til «prosess for å skaffe arbeidstillatelser i Norge for de medarbeiderne hvor det er vurdert at det er best å flytte de til Norge», «2 medarbeidere fra GBSC (Kina)», jf. punkt 3 i IBMs konsekvensanalyse. Det går frem av endringsordren at endringen var «nødvendig for å dekke IBMs merkostnad knyttet til instruksjonen fra SVV». EO064 omfatter ikke de tidsmessige konsekvenser for prosjektet. Det var altså de kostnadsmessige konsekvensene som ble skilt ut fra EA078 og lagt inn i EO064. Samtidig ble det presisert at det skulle «opprettes en ny [endringsordre] for konsekvensen for planverket knyttet til tidspunktet for når SVV tar beslutningen om å blokkere tilgangen».

Lagmannsretten mener at denne tilføyelsen underbygger at SVV erkjente ansvar også for de eventuelle tidsmessige konsekvensene av nødvendige tiltak for å hindre eksponering av personopplysninger i Kina. Spørsmålet om implementering av Guardium var tilstrekkelig for å trygge sikring av produksjonsdata i henhold til SVVs endrede sikkerhetspolicy, fortsatte ut over våren 2015, og saken var ikke lukket da SVV hevet kontrakten. Det er ikke ført bevis som gjør lagmannsretten i stand til å vurdere om Guardium ville vært tilstrekkelig for å trygge sikring av produksjonsdata slik at migreringstest ville kunnet finne sted som planlagt. Lagmannsretten finner imidlertid holdepunkter i de tidsnære bevisene for at usikkerheten som SVV ved Arve Ryan ga uttrykk for i skriv 5. mai 2015, var stor, og at SVV var innforstått med at tidskonsekvensene av Kinasaken kunne være betydelig. Det vises til referat fra møtet i SVVs styringsgruppe 20. mars 2015 sitert over, hvor SVVs prosjektledelse ga uttrykk for at EA078 kunne bli «en potensiell større endring».

(FU 21449) Den 2. juni 2015 stilte styringsgruppen spørsmål om Kina-saken (EA078) «vil være en endring som innbefattes av begrensingene gitt av Lov om Offentlige anskaffelser». (FU 24410) Dette må forstås som et spørsmål om endringen kunne anses som «vesentlig». Svar fra prosjektet var at spørsmålet måtte avklares med jurist, og at prosjektleder ville følge opp og gi tilbakemelding. Lagmannsretten mener på bakgrunn av de begivenhetsnære bevisene at Guardium mest sannsynlig ikke ville vært tilstrekkelig for å trygge sikring av produksjonsdata i henhold til SVVs endrede sikkerhetspolicy, og at det ville vært nødvendig å flytte to ressurser fra GSBC Kina til Norge for å gjennomføre migreringstest, dvs. før HMP 2.2. Uansett om SVV kan anses for å ha erkjent ansvar eller ikke, må SVV da bære både de tidsmessige og kostnadsmessige konsekvensene av dette. IBM har krevd fristforlengelse med 90 kalenderdager basert på saksbehandlingstiden i Utlendingsdirektoratet for visumsøknader våren 2015, og har gjort gjeldende at migreringstest måtte ha blitt utsatt til de kinesiske medarbeiderne var på plass i Norge.

Saksbehandlingstiden i Utlendingsdirektoratet er ikke bestridt, men SVV har gjort gjeldende at fristforlengelsen som er krevd er for stor, og at IBM uansett bare har krav på fristforlengelse i den grad endringen påvirker kritisk linje. Det er ikke ført bevis for at saksbehandlingstiden for visumsøknadene for de to kinesiske medarbeiderne, kunne vært kortet ned, og lagmannsretten legger 90 kalenderdager for denne behandlingen til grunn. Arbeidet med migreringstest lå på kritisk linje da dette var blant de siste aktivitetene før HMP2.2 og kunne ikke gjøres parallelt med annet utviklingsarbeid. SVV hadde 5. mai 2015 varslet IBM om at selskapet ville bli bedt om å starte arbeidet med å forberede visumsøknader og hadde i EO064 påtatt seg ansvaret for kostnadene forbundet med dette. EO064 var imidlertid ikke undertegnet på hevingstidspunktet. Konsekvensene av at dette ikke ble gjort, må gå utover SVV. Lagmannsretten konkluderer etter dette med at «Kina-saken» gir IBM krav på fristforlengelse med 90 kalenderdager.

4.4.8 Underkjenningen av kontrollpunkt 2 (KP2) 4.4.8.1 Innledning – Betydningen av KP2 for IBMs krav på fristforlengelse/flytting av milepæler IBM har fremsatt tre endringsanmodninger, EA108, EA113 og EA117, som forutsetter at SVVs underkjenning av KP2 ikke var rettmessig.

Lagmannsretten vurderer denne forutsetningen i punkt 4.4.8.4 til 4.4.8.6 nedenfor, men ser først på hva som etter kontrakten skal skje i et kontrollpunkt i punkt 4.4.8.2 og behandlingen av KP2 i punkt 4.4.8.3. Spørsmålet om EA108, EA113 og EA117 gir krav på fristforlengelse og flytting av milepæler, blir behandlet i punkt 4.4.9. 4.4.8.2 Hva som etter kontrakten skal skje i et kontrollpunkt Et kontrollpunkt avslutter en iterasjon, i kontrakten omtalt som et trinn, jf. Generelle kontraktsbestemmelser punkt 3.4.2 første avsnitt. Her heter det blant annet: [...] Et Kontrollpunkt representerer i motsetning til en Milepæl ikke nødvendigvis en avslutning eller et oppnådd resultat, men er et beslutningspunkt som danner grunnlag for det videre arbeidet. (FU 8458 på 8467) Hva som skal skje i et kontrollpunkt, er regulert i Generelle kontraktsbestemmelser punkt 3.4.5. Etter første avsnitt skal kunden «evaluere gjennomføringen av et trinn», det vil kort sagt si evaluere gjennomføringen av designet, utviklingen og testingen i en iterasjon.

Det skjer normalt ikke en prøving av om det foreligger en løsning som oppfyller kontraktens krav i kontrollpunktet, jf. punkt 3.4.2. En slik prøving skjer etter at alle kontrollpunktene er gjennomført, og prosjektet er over i godkjennings- og avslutningsfasen, jf. punkt 3.5. Etter punkt 3.4.5 andre avsnitt skal endringsanmodninger som har vært utstedt og utredet i trinnet, «eventuelt besluttes gjennomført ved utstedelse av Endringsordre for iverksettelse i et etterfølgende trinn». Videre skal usikkerhetsmatrisen gjennomgås og oppdateres. I tredje avsnitt står det: Leverandøren skal utarbeide en plan for etterfølgende trinn basert på overordnet Fremdriftsplan og erfaringer fra gjennomført trinn. Arbeidet med etterfølgende trinn skal først igangsettes når Kunden innen en frist som er definert i Bilag C, har godkjent planen og den oppdaterte usikkerhetsmatrisen. [...] (FU 8468) Fristen «for å godkjenne/underkjenne Kontrollpunktet er 5 arbeidsdager», jf. Bilag C punkt 4.3.7. (FU 9105 på 9129) Godkjennelse av et kontrollpunkt gir leverandøren krav på betaling, jf.

Generelle kontraktsbestemmelser punkt 4.3 fjerde avsnitt og Bilag D punkt 3. (FU 8458 på 8474 og FU 9271 på 9280) Kontrollpunktet starter med en evaluering av inngangskriteriene. Begrepet «inngangskriterier» er brukt i PRO006 Arbeidsprosesser, versjon 2.8, punkt 3.4.2. Inngangskriteriene som er listet opp her er leverandørens testrapport, tilgang til leveransen for verifikasjon, eventuell omforent liste og plan for håndtering av restanser/avvik, eventuelle endringsanmodninger som er utstedt og utredet, plan for etterfølgende iterasjon inkludert leveranseliste, usikkerhetsmatrisen og dokumenter i henhold til leveranselisten. (FU 62 på 86) Kontrollpunktet avsluttes med et kontrollpunktmøte, jf. Bilag C punkt 4.3.7. Møtet skal behandle leverandørens protokoll over testresultater, leverandørens liste over restanser/avvik, eventuelle endringsanmodninger som er utstedt og utredet, leverandørens plan for etterfølgende trinn, usikkerhetsmatrisen og godkjenning/underkjenning av kontrollpunktet. Endringsordre skal innarbeides i planverket.

(FU 9105 på 9129) 4.4.8.3 Behandlingen av KP2 KP2 skulle vært gjennomført i månedsskiftet januar/februar 2015, men var blitt utsatt flere ganger. Testingen av iterasjon 2 hadde hatt svak fremdrift. (FU 18855 på 18858, FU 19410 på 19411 og FU 20430 på 20432) IBM iverksatte tiltak fra februar 2015 og fremdriften tok seg opp. (FU 20957 på 20959 og FU 22124 på 22126) KP2 startet 13. april 2015, men ble avbrutt samme dag fordi SVV mente at inngangskriteriene ikke var oppfylt. IBM leverte nytt materiale, og KP2 startet på nytt 20. april 2015. Inngangskriteriene ble ansett som oppfylt 22. april 2015. (FU 23179 på 23180) SVV underkjente IBMs leveranse til KP2 28. april 2015. Begrunnelsen ser ut til å ha utviklet seg noe i dagene frem mot underkjenningen. I referatet fra SVVs SG-møte 24. april 2015 står det: Ved underkjennelse av KP2, må IBM levere på nytt før milepælen eventuelt kan oppnås. Det antas at det er for lite volum levert inn til KP2 som vil være hovedargumentet for en avgjørelse om å underkjenne KP2. (FU 23009 på 23010)

SVV meddelte underkjenningen i kontrollpunktmøte 28. april 2015. (FU 23178) Det går frem av referatet fra møtet at SVV underkjente KP2 ikke bare fordi volumet til og med iterasjon 2 skal ha vært «langt mindre enn avtalt», men også fordi gjennomføringsplanen ikke skal ha vært «troverdig». SVV ved hovedprosjektleder Stein Ødegaard varslet IBM i e-post rett etter møtet om at det ville komme et brev med en bekreftelse på underkjenningen senere samme dag. (FU 23228) I det varslede brevet tilføyde SVV en tredje begrunnelse. SVV underkjente her IBMs testrapport. (FU 23210 på 23211) I KG-møte 12. mai 2015 opplyste SVV at det var «manglende troverdighet i planen» som var hovedårsaken til underkjenningen. (FU 23704 på 23705) IBM hadde påbegynt arbeidet med iterasjon 3 i parallell med iterasjon 2. Som følge av underkjenningen av KP2, stanset IBM arbeidet med iterasjon 3 fra midten av juni 2015. IBM nedbemannet iterasjon 3 for å fokusere på ny leveranse til iterasjon 2. (FU 25014 på 25015, jf.

FU 24684 på 24687) Lagmannsretten legger til grunn av rettmessighetsvurderingen skal skje ut fra situasjonen på tidspunktet da SVV underkjente KP2, og mener at verken volumet, gjennomføringsplanen eller testrapporten ga SVV grunnlag for å underkjenne IBMs leveranse til KP2. Lagmannsretten begrunner hvorfor volumet ikke ga grunnlag for underkjenningen i punkt 4.4.8.4, hvorfor testrapporten ikke ga grunnlag for dette i punkt 4.4.8.5 og hvorfor gjennomføringsplanen ikke gjorde det i punkt 4.4.8.6. 4.4.8.4 Volumet som grunnlag for å underkjenne KP2 Det følger av Bilag C punkt 2.2.1.1 at det endelige omfanget for hver iterasjon avtales under løsningsbeskrivelsesfasen. (FU 9105 på 9110) Etter løsningsbeskrivelsen var IBM forpliktet til å levere rundt 80 prosent av hele løsningen per KP2. Dette innebar at rundt 20 prosent skulle gjenstå til iterasjon 3. Avtalen om volum kunne imidlertid endres ved enighet om noe annet. For eksempel skrev SVV i underkjenningsbrevet 28. april 2015 at vegvesenet «indirekte» hadde «gått med på en scope-fordeling» som var presentert i et allmøte 24. september 2014 (feilskrevet 23. september 2014).

SVV skrev videre at det ikke var «avtalt noen annen scope-fordeling» enn det som fulgte av «power point»-presentasjonen i dette møtet. (FU 23210 på 23212) «Power point»-presentasjonen ga en oversikt over hva som skulle gjøres i hver iterasjon, men ga ingen prosentfordeling mellom iterasjonene. (FU 15684 flg.) Slik lagmannsretten ser det, ble SVV bundet ved passivitet til en annen scope-fordeling enn den som ble avtalt under løsningsbeskrivelsesfasen. SVV fikk informasjon under konstruksjonsfasen om at iterasjon 3 ville omfatte langt mer enn 20 prosent av løsningen, og følgelig at iterasjon 0 til 2 ville omfatte langt mindre enn 80 prosent av løsningen. I månedsrapporten for november 2014 opplyste IBM at «en betydelig andel av leveransen» var «blitt flyttet til iterasjon 3». (FU 16798 på 16801) I KG-møte 18. november 2014 formidlet IBM at det var ca. 50 prosent av det totale scopet som ville gjenstå til iterasjon 3, og at fordelingen mellom scope-elementene for iterasjon 2 og 3, var flytende.

(FU 17223 på 17224) I referatet fra KG-møte 18. desember 2014 står det også at 50 prosent av den totale utviklingen skulle gjennomføres i iterasjon 3. (FU 18383 på 18385) I referatet fra KG-møte 15. januar 2015 står det at 57 prosent av utviklingen gjensto til iterasjon 3. (FU 19410 på 19412) IBMs deltestplan for iterasjon 2 fra 15. januar 2015 og PRO001 Gjennomføringsplan 2.0 fra 20. januar 2015, viste hva som etter dette skulle gjøres i hver av iterasjonene. (FU 19422 på 19430 og FU bilag 204) SVV fremsatte ingen umiddelbare innsigelser mot denne informasjonen, og la den til grunn internt i tiden før underkjenningen. I SVVs statusrapport 19. januar 2015 står det at «mer enn 50 prosent av omfanget» var lagt til iterasjon 3 i IBMs planer. (FU 19520 på 19521) Det samme står i SVVs statusrapport 17. februar 2015. (FU 20370 på 20372) I referatet fra SG-møte 23. februar 2015 står det at «over 50 prosent av utviklingsoppgavene» var planlagt inn i iterasjon 3. (FU 20581 på 20582) SVVs statusrapport 12. mars 2015 viser det samme. (FU 19861 på 19862) SVV fikk informasjon om innholdet av iterasjon 3 også på annen måte.

Gjennom «Release Notes» 22. desember 2014, 21. januar 2015 og 13. februar 2015, fikk SVV en detaljert beskrivelse av innholdet i iterasjon 2 på «use case»-nivå per 13. februar 2015. (FU 18575 flg. (26907), FU 26926 flg., FU 20279 flg.) SVV fremsatte ingen umiddelbare innsigelser mot volumet som fremkom av disse dokumentene. SVV fikk også se

innholdet av iterasjon 2 under generalprøven fra 23. til 27. mars 2015 og kundetesten fra 7. til 10. april 2015. SVV fremsatte heller ingen umiddelbare innsigelser mot volumet i forbindelse med disse testene. Det går frem av referatet fra behandlingen av inngangskriteriene i kontrollpunktmøte 13. april 2015 at IBM redegjorde for at ca. 55 prosent av løsningen gjensto til iterasjon 3 slik at iterasjonene til og med iterasjon 2 tilsvarte ca. 45 prosent. (FU 22322 på 22323) Det går også frem at IBM skulle levere «en oppdatert release note for å redegjøre for innholdet i leveransen til KP2». (FU 22328) I e-post 15. april 2015 ble IBM i tillegg bedt om en «komplett og kvalitetssikret scopeliste» for iterasjonene til og med iterasjon 2. (FU 22499) Under KG-møte 17. april 2015 poengterte SVV «at selv om det ikke er direkte beskrevet som eget inngangskriterium, er en entydig oversikt over hva som er levert så langt i prosjektet (iterasjon 0, 1 og 2) nødvendig for å kunne evaluere både leveranse og testrapport, samt plan for gjenstående arbeid i konstruksjonsfasen». (FU 22624 på 22625) IBM leverte scope-oversikter både 15. og 17. april 2015.

(FU 22502, 22681 og 22687) SVVs delprosjektleder for delprosjektet Leveranse, Anne-Marie Ytrehus, bekreftet i e-post 22. april 2015 at inngangskriteriene til oppstart av kontrollpunktet i perioden 22. til 28. april 2015, kunne «anses som oppnådd». (FU 22985) Inngangskriteriene ble med andre ord godkjent fem dager etter at SVV hadde mottatt siste scope-oversikt. Flytting av innhold til iterasjon 3 hadde vært et gjennomgangstema våren 2015. Slik saken er opplyst, finner lagmannsretten ikke holdepunkter for at oversiktene fra 15. og 17. april 2015 hadde et vesentlig annet innhold enn oversiktene tidligere denne våren. Oppsummert fikk SVV helt fra november 2014 informasjon om at iterasjon 3 ville omfatte opp til 57 prosent av løsningen uten at vegvesenet fremsatte umiddelbare innsigelser mot dette. SVV fikk også informasjon om innholdet av iterasjon 3 gjennom release notes og scope-oversikter uten at vegvesenet fremsatte umiddelbare innsigelser. Lagmannsretten mener da at SVV ble bundet ved passivitet til å akseptere et volum på helt ned til 43 prosent av hele løsningen per KP2.

Slik lagmannsretten ser det, leverte IBM et volum til KP2 som var innenfor det som SVV hadde bundet seg til å akseptere. Når det gjelder andelen av løsningen som ble levert til KP2, har IBM anslått dette etter to tilnærminger. IBMs første tilnærming er å sammenlikne fullførte og planlagte widgets per april 2015. For iterasjon 0 og 1, var 342 av 342 planlagte widgets fullført. Det går frem av IBMs ukentlige statusrapport 29. april 2015 at 1109 av 1109 planlagte widgets for iterasjon 2 og 528 av 1 217 planlagte widgets for iterasjon 3, var fullført. (FU 23249 på 23251) Totalt var det 2 668 planlagte widgets. Forutsettes det at alle widgets var omtrent like store og kompliserte, var nesten 55 prosent av løsningen levert per KP2 ((342 + 1 109)/2 668). Det sto følgelig vel 45 prosent igjen til iterasjon 3. Det sto med andre ord mindre igjen til iterasjon 3 enn det som SVV hadde bundet seg til å akseptere ved passivitet. IBMs andre tilnærming er å sammenlikne utførte DCUT-timer i iterasjon 0 til 2 og iterasjon 3 med alle utførte DCUT-timer i strømmene IRIS, SAP og CRM (GD India).

IBM har på grunnlag av ulike kilder, blant annet sin egen EV-rapportering, laget et hjelpedokument som viser at det per 26. juni 2015 var utført 32 354 DCUTtimer i iterasjon 0 til 2 og 27 766 DCUT-timer i iterasjon 3. (FU bilag 1182, 1589, 1590, 1609, 1610 og 1611) Iterasjon 0 til 2 utgjorde da 54 prosent, mens iterasjon 3 utgjorde 46 prosent av alt utført DCUT-arbeid (60 120 timer) i disse strømmene per 26. juni 2015. Slik lagmannsretten ser det, gir ikke denne beregningen svar på hvor stor andel av løsningen som sto igjen til iterasjon 3 etter leveransen til KP2. For å finne ut hvor mye som sto igjen, må gjenstående timer trekkes inn. Ifølge IBM gjensto det 8 456 DCUTtimer i disse tre strømmene. Med IBMs tall utgjorde iterasjon 0 til 2 da 47 prosent av utført og planlagt arbeid per 26. juni 2015 (32 354/(/(60 120 + 8 456)). Det sto følgelig igjen 53 prosent igjen til iterasjon 3. Dette var også mindre enn det som SVV hadde bundet seg til å akseptere ved passivitet. Samtidig viser IBMs EV-rapportering at det per 26. juni 2015 sto igjen 31 254 timer (ETC) på iterasjon 2 og 3 til sammen.

(FU bilag 1611) Estimatet for konstruksjonsfasen som helhet, det vil si alle iterasjonene fra og med 0 til og med 3, var 251 324 timer. I så tilfellet sto det igjen 12 prosent av løsningen (31 254/251 324). Denne beregningen kan imidlertid ikke gi svar på hvor stor andel av løsningen som sto igjen til iterasjon 3 etter leveransen til KP2. Beregningen viser situasjonen to måneder etter KP2 og den inkluderer iterasjon 2 som på dette tidspunktet må bety iterasjon 2.5.

Ifølge IBMs EV-rapportering per 24. april 2015, sto det igjen 54 534 timer på iterasjon 2 og 3 til sammen på dette tidspunktet. (FU bilag 159) Estimatet for konstruksjonsfasen var da 229 797 timer. I så tilfellet sto det igjen (54 534/229 797) 24 prosent etter KP2. Denne beregningen kan si noe om hvor stor andel som sto igjen etter KP2, men ikke hvor mye av dette som var del av iterasjon 3. På den andre siden kan det ikke ha stått igjen mer til iterasjon 3 ved KP2 enn 24 prosent. Selv om det var store svakheter ved IBMs EV-rapportering, mener lagmannsretten at disse totaltallene gir en sterk indikasjon på at det gjensto langt mindre til iterasjon 3 enn det som SVV hadde bundet seg til å akseptere ved passivitet. Staten har holdt frem at opplysningene som IBM ga i KG-møte 12. mai 2015 om at selskapet på det tidspunktet var «65 % ferdig med konstruksjonsfasen, og 50 % ferdig med iterasjon 3», viser at iterasjon 3 utgjorde 70 prosent av løsningen. (FU 23704 på 23707) Lagmannsretten legger mindre vekt på disse uttalelsene. Det går ikke frem hvilken scope-forståelse og hvilke underlag som er lagt til grunn for uttalelsene.

Staten har videre gjort gjeldende at IBM i prosjektledermøte 10. juni 2015 uansett erkjente at selskapet bare hadde levert rundt 80 prosent av innholdet av iterasjon 2 slik det var beskrevet i Gjennomføringsplanen versjon 1.2 til KP1, og at avviket på 20 prosent var tilstrekkelig for å underkjenne KP2 på grunn av volum. (FU 24684 på 24687) Lagmannsretten er ikke enig i dette. Det IBM opplyste i møtet 10. juni 2015, var at leveransen til KP2 omfattet 80 prosent av innholdet som var planlagt for iterasjon 2 ved KP1, og at selskapet ville sette alt inn på å levere de resterende 20 prosentene. (FU 24687) IBM ga med andre ord opplysninger om hvor stor del av iterasjon 2 som var flyttet til iterasjon 3 i tiden mellom KP1 og KP2. IBM opplyste det samme i EA117 10. juli 2015. IBM redegjorde her for at innholdet som var planlagt for iterasjon 2 ved KP1, var definert gjennom Gjennomføringsplanen versjon 1.2. Innholdet var så blitt «videre endret etter KP1». «Som følge av dette» ble det levert ca. 80 prosent av innholdet som fulgte av Gjennomføringsplanen versjon 1.2.

I EA117 skrev IBM også at selskapet hadde levert det innholdet til KP2 «som partene sammen» hadde «jobbet etter». (FU 25559) Som nevnt mener lagmannsretten at SVV hadde bundet seg til å akseptere at en stor del av innholdet, ble flyttet til iterasjon 3. De 20 prosentene som det er tale om her, ligger innenfor det volumet som SVV hadde bundet seg til å akseptere ville bli flyttet. Lagmannsretten går over til å begrunne hvorfor testrapporten ikke ga grunnlag for å underkjenne KP2. 4.4.8.5 Testrapporten som grunnlag for å underkjenne KP2 Det følger av Generelle kontraktsbestemmelser punkt 3.4.3 at leverandøren skal teste «den del av Leveransen som er utviklet, integrert og tilpasset» for hver iterasjon, og at Bilag C regulerer hvordan testingen skal gjennomføres. (FU 8458 på 8467) Etter Bilag C punkt 4.3.4 skal testing «planlegges, gjennomføres og dokumenteres i henhold til Teststrategi for Statens vegvesen». (FU 9105 på 9128) At testing skal skje i henhold til teststrategien for SVV, følger også av Bilag A IF.09.01.

(FU 8485 på 8714) Etter Bilag C punkt 4.3.4 følger det av teststrategien til SVV at leverandøren har ansvaret for «enhets-, integrasjons-, iterasjons- og systemtest» i konstruksjonsfasen, og at kunden har ansvaret for «akseptanse- og produksjonstest» i godkjennings- og avslutningsfasen. Det er forklart at det med systemtest menes «samlet system- og integrasjonstest» (SIT). Videre skal det utarbeides «en omforent overordnet testplan» i tråd med teststrategien. Etter Bilag C punkt 2.2.1.1 og punkt 4.3.3 resulterer hver iterasjon i en integrert løsning. (FU 9111 og 9128) Det var prioritert å realisere hovedtransaksjonsflyten fra vegdata til bokføring, det vil si fra vegkant via IRIS til SAP FI-CA, tidlig. (FU 9111) Teststrategien for SVV er vedlagt Bilag C. (FU 9128 og FU 9250 flg.) Etter teststrategien punkt 2.1, skal testplanene utarbeides med utgangspunkt i den europeiske standarden IEEE 829 2008. Det samme skal testrapportene. (FU 9255)

Det ble utarbeidet en omforent overordnet testplan (OTP) med en mal for testrapporter i henhold til standarden IEEE 829. (FU 9207 flg., FU 13502 flg. på 13570, FU 16618 flg. på 16685) Det går frem at det skjer enhets-, integrasjons- og iterasjonstesting for hver iterasjon. (FU 9221 flg.) Etter OTP punkt 5.3.4.3 starter verifikasjonen av iterasjonen når planen for verifikasjonen er godkjent, iterasjonstesten er sluttført, spesifikasjonene for iterasjonstesten er utarbeidet og ressursene til verifikasjonen er allokert. (FU 9224) Formålet er å gjøre kunden «i stand til å vurdere om det avtalte innholdet i en iterasjon» er implementert og fungerer i henhold til testspesifikasjonen. (FU 9223) Ved enhetstesting, testes hver enkelt enhet og modul. Ved integrasjonstesting, testes de interne og eksterne grensesnittene, det vil si den funksjonelle samhandlingen mellom komponentene i løsningen, jf. SVVs teststrategi punkt 4.1.2. (FU 9262) Enhetstesting skjer under utviklingen av enhetene. Ifølge IBMs testleder fra 28. februar 2015, Sally Drew, skjer integrasjonstesting kontinuerlig helt fra enhetstesting.

Ved iterasjonstesting, testes koden som er ferdigstilt innenfor iterasjonen. Iterasjonstesting utføres på tvers av leveransene fra utviklingsteamene, jf. SVVs teststrategi punkt 4.1.3. (FU 9263) I tillegg skulle det skje en kundetest til slutt i hver iterasjon, jf. punkt 4.1.5. (FU 9264) Bilag C punkt 4.3.7 første avsnitt definerer grensen for feil ved leveransen til et kontrollpunkt. Grensen er satt til null A-feil, 16 B-feil og 30 C-feil. (FU 9105 på 9129) I Generelle kontraktsbestemmelser punkt 3.4.4 er disse tre feilkategoriene definert slik:

• A-Feil er Feil som er så alvorlige at driften stanser eller må stanses for en kritisk gruppe av brukere av Leveransen og feilen ikke kan omgås,
• B-Feil er Feil som kan omgås, men som forsinker driften,
• C-Feil er Feil som det ikke er nødvendig å utbedre for å igangsette eller opprettholde driften. (FU 8458 på 8468) I underkjenningsbrevet 28. april 2015 skrev SVV at IBMs testrapport manglet «viktige elementer for å kunne gi et godt bilde av testaktivitetene, samt funn og testresultater». SVV begrunnet underkjenningen med at testrapporten bare beskrev «Kundetest og enhetstest, og ikke den øvrige testingen» som hadde «foregått over flere måneder». (FU 23210 på 23211) Slik lagmannsretten ser det, ble IBMs testrapport godkjent som del av inngangskriteriene. Under behandlingen av temaet testrapport i KP-møte 13. april 2015, presiserte SVV stort sett bare at vegvesenet forventet en rapport som gjenspeilte testplanen. (FU 22322 på 22324) Under evalueringen av iterasjon 2 i dette møtet, opplyste IBMs prosjektleder, Terje Harangen, at mange av test casene i iterasjon 2 hadde vært «mer på enhetstestnivå». (FU 22328) I brev til IBM samme dag konkluderte SVV med at det ikke forelå noen testrapport som oppfylte inngangskriteriet. SVV viste bare til at listen over feil ikke var oppdatert. (FU 22331) Verken referatet fra KP-møtet eller brevet 13. april 2015 angir at rapporten skulle beskrive «den øvrige testingen» som hadde «foregått over flere måneder».

IBM oversendte testrapport for iterasjon 2 både 13. og 17. april 2015. (FU 22261 flg. og FU 22703 flg.) IBM vedla detaljerte lister over test casene som var gjennomført. Av Appendix A til begge rapportene går det for eksempel frem at 140 av 240 test caser knyttet til grensesnitt (UI) i IRIS ikke var kjørt. (FU 22273 og 22717) IBM vedla resultatene fra kundetesten i Appendix B til rapporten fra 13. april 2015. Her går det for eksempel frem at 15 av 18 kundetest caser knyttet til bombrikke (OBU) ikke var kjørt. (FU 22306) Testrapporten fra 17. april 2015 ble gjennomgått i KP-møte 20. april 2015. Det går frem av referatet fra møtet at SVV blant annet mente at det forelå en A-feil som ikke var kommet med. Det var enighet om at IBM skulle levere en oppdatert testrapport for iterasjon 2 til 21. april 2015. (FU 22871 på 22873) Det går også frem at SVV etterlyste «flere elementer i testrapporten». Blant annet ønsket SVV å vite hva slags testing som var utført, herunder om det var utført integrasjonstesting, samt se på malen sammen med IBM.

(FU 22874) I en e-post på formiddagen 20. april 2015 skrev SVVs innleide prosjektstøtte, Nina Jørgensen, at vegvesenet ønsket et møte om disse elementene i uke 19, det vil si etter KP2. (FU 22855) Det går således heller ikke frem av referatet fra og korrespondansen i etterkant av KP-møtet 20. april 2015 at testrapporten til KP2 skulle beskrive «den øvrige testingen».

SVV ville for øvrig hatt oversikt over all testing om SVV hadde tatt i bruk testverktøyet RQM, jf. punkt 3.3.4 foran.

IBMs testleder, Sally Drew, oversendte den oppdaterte testrapporten til SVV på kvelden 20. april 2015. (FU 22856 og FU 22857 flg.) Drew har forklart at hun gjennomførte testen og skrev rapporten med utgangspunkt i den omforente malen. Malen viste hva testplanen og rapporten skulle inneholde. Lagmannsretten mener at en sammenlikning av innholdsfortegnelsen til rapporten og malen, underbygger Drews forklaring om dette. (FU 22858 og 22859 samt FU 16684 og 16685) Videre beskrev testrapporten at det ikke bare var gjennomført kundetest og enhetstesting, men også noe integrasjonstesting. (FU 22861 og 22862) Det går frem av rapporten punkt 2.1.2.3 at iterasjonstestingen hadde fokusert på «System Level verification, e.g. inspect the output of an output file as opposed to inspecting the transferred data in the target system», og at testingen av iterasjon 3 skulle gjøres «more integrated». I punkt 2.1.2.2.5 står det at testingen hadde «brought forward a number of integration issues which highlighted some significant (but largely resolved in the end) challenges».

En ordlydstolkning av disse punktene i testrapporten tilsier at IBM hadde testet om integrasjonen var åpen og identifisert hva som sto igjen av integrasjonstesting. Den reelle dataflyten mellom komponentene var derimot ikke testet. Drew har forklart at det skjedde integrasjonstesting helt fra enhetstestingen, men at det er en rimelig tolkning av testrapporten punkt 2.1.2.2.5 at den reelle dataflyten mellom komponentene, ikke var testet. Også den detaljerte listen over de gjennomførte test casene som fulgte rapporten 20. april 2015, viser at det hadde skjedd integrasjonstesting. (FU 26676 flg.) I likhet med Appendix A til rapportene 13. og 17. april 2015, viser Appendix A til rapporten 20. april 2015 at det ble testet 38 grensesnitt. (FU 26676 flg., jf. FU 22272 og 22715) I likhet med Appendix A til rapporten fra 13. april 2015, viser også Appendix A til rapporten fra 20. april 2015 at 140 av 240 test caser knyttet til grensesnitt i IRIS ikke var kjørt. (FU 26681) Drew har forklart at hun ikke husket hva som var årsaken til at disse test casene ikke ble kjørt, og at dette burde vært kommentert i rapporten.

Hun husket derimot at OBU-test casene (brikke-test casene) som ikke ble kjørt under kundetesten, jf. Appendix B til rapporten 13. april 2015, ikke fungerte. Som nevnt bekreftet SVV 22. april 2015 at inngangskriteriene til KP2 kunne «anses som oppnådd». (FU 22985) Inngangskriteriene ble således godkjent to dager etter den siste testrapporten. SVV hadde dessuten vist særskilt interesse for hva slags testing som var utført, herunder om det var utført integrasjonstesting, i forkant. Lagmannsretten mener da at SVV må anses for å ha godtatt testrapporten med vedlegg. Testrapporten var ett av inngangskriteriene til KP2. (PRO006, jf. FU 22322 og 22871) Rapporten med vedleggene redegjorde utførlig for testspesifikasjonene. I bekreftelsen på at inngangskriteriene kunne anses som oppnådd 22. april 2015, ble det tilføyd at det ikke var gitt noen «bekreftelse på aksept av kvaliteten på mottatt leveranse», og at SVV ville starte «evalueringen av leveransen» (lagmannsrettens kursivering).

(FU 22985) I brevet 28. april 2015 ble underkjenningen av testrapporten da også begrunnet med at SVV var uenig i rapportens konklusjon om at «løsningen» som var testet under kundetesten, var «i henhold til krav og spesifikasjoner». (FU 23210 på 23211) Slik lagmannsretten ser det, vurderes kvaliteten på leveransen i et kontrollpunkt ut fra antallet A-, B- og C-feil. Vurderingen av kvaliteten ut fra kontraktens krav for øvrig, skjer i godkjennings- og avslutningsfasen etter at alle trinn er gjennomført, jf. Generelle kontraktsbestemmelser punkt 3.4.5 siste avsnitt og punkt 3.5.1 første avsnitt. (FU 8458 på 8468 og 8469) Testrapporten konkluderte med et antall feil som lå godt innenfor feilgrensene etter Bilag C punkt 4.3.7 første avsnitt: Det ble funnet null A-feil, åtte B-feil og 20 C-feil etter kjøring av 100 prosent av i alt 2 691 planlagte test caser. Syv av B-feilene og 17 av C-feilene var i strømmen CRM/REP, det vil si GD India. Antallet test caser i denne strømmen var oppgitt til 1 314. (FU 22857 på 22861 og 22864) IBM hadde planlagt flere enn 1 314 test caser tidligere.

Det går frem av statusrapporter 13. og 19. januar 2015 at det var planlagt for henholdsvis 1 505 og 1 506 test caser. (FU 18915 på 18920 og FU 18922 på 18927) Lagmannsretten ser ingen holdepunkter for at IBM fjernet test caser med sikte på å komme under grensene for A-, B- og C-feil.

Drew har forklart at hun satte seg inn i den siste statusrapporten som ledd i overtakelsen som testleder fra 28. februar 2015. I statusrapporten 23. februar 2015 var antallet test caser for GD India 1 320. (FU 18956 på 18963) Drew har videre forklart at hun ikke husket om hun var klar over reduksjonen på nesten 200 planlagte test caser for GD India fra januar til februar 2015, eller om hun var klar over reduksjonen, men ikke så det som nødvendig å kommentere den. Selv om hun skulle ønske at hun hadde kommentert reduksjonen, var hun likevel ikke overrasket over den. Hun pekte på dubletter som en vanlig årsak; to tester som dekket samme funksjonalitet, ble sett som én ekvivalent. Hun pekte også på at kontrakten ikke stilte noe krav til ferdigstillelsesgrad for testingen. Som Drew har vært inne på, burde reduksjonen i antallet test caser ha vært kommentert i testrapporten. Samtidig vurderer lagmannsretten hennes dublettforklaring som plausibel.

Dessuten mener lagmannsretten at flyttingen av innhold fra iterasjon 2 til iterasjon 3 og endringer i løsningens funksjonalitet, også gir en nærliggende forklaring på reduksjonen i antallet test caser fra januar til februar 2015. IBM skulle bare teste det som var «utviklet, integrert og tilpasset» av «det avtalte innholdet» for iterasjon 2, jf. Generelle kontraktsbestemmelser punkt 3.4.3 og OTP punkt 5.3.4.3. Det avtalte volumet får betydning for antallet test caser. Videre gir ikke de begivenhetsnære bevisene holdepunkter for at IBM gikk inn for å fjerne test caser med sikte på å komme under feilgrensene. Staten har holdt frem at minst seks interne grensesnitt ikke var testet i tråd med SVVs teststrategi. Lagmannsretten ser det ikke som nødvendig å ta stilling til dette. Statusen for disse grensesnittene var uansett kjent for SVV og inkludert i inngangsvilkårene, som er godkjent. Lagmannsretten ser heller ikke at IBMs testrapport skjulte en åpen A-feil etter kundetesten.

Ifølge testrapport 27. mars 2015 hadde grensesnittet for replikering av kontrakter mellom SAP og SugarCRM (I-CRM-FICA-051/ #48969), en feil med status «show stopper» og en alvorlighetsgrad («severity») «critical». (FU 21 725 på 21752) IBMs leder for SAP-strømmen, Trond Bådstangen, meldte i e-post internt i IBM 10. april 2015 at feilen hadde «severity 1». (FU 22119 og 22120) Drew delte e-posten med SVVs testleder, LarsOlav Engseth, 11. april 2015, og nedgraderte feilen til «major». (FU 22118) I testrapport 13. april 2015 var feilen lukket, men fortsatt gradert som «critical». (FU 22262 på 22290) I testrapport 20. april 2015 var feilen nedgradert til «major». (FU 26676 på 26699) Drew har forklart at feilen ved grensesnittet ville blitt kategorisert som en A-feil hvis det ikke hadde blitt funnet en «work around», men at kategoriseringen kunne reduseres til en B-feil med en «work around», jf. den nevnte kategoriseringen av feil i Generelle kontraktsbestemmelser punkt 3.4.4. Drew har videre forklart at en feil ikke kan lukkes med en «work around».

IBM nektet i KP-møte 20. april 2015 for at grensesnittet hadde en A-feil og viste til at det virket etter «implementering av en short term fix/work around». SVV gjorde det klart at en «short term fix/work around» ikke var akseptabel. IBM og SVV var uenige om kontrakten ga vegvesenet rett til å reteste feilen. (FU 22871 på 22873) I konsolidert release note 21. juli 2015 er #48969 ført som en tidligere feil som ble fikset i iterasjon 2.5. (FU 25 969 på 25979) Lagmannsretten mener at disse begivenhetsnære bevisene viser at SVV var informert om feilen ved grensesnittet slik at den ikke var skjult. Lagmannsretten mener videre at det relevante spørsmålet i denne sammenhengen, er om feilen var en A-feil, og ikke om den ble lukket før SVV fikk anledning til retesting. Slik lagmannsretten ser det, kunne ikke feilen ved brukergrensesnittet være en A-feil så lenge den kunne omgås med en work around, jf. Generelle kontraktsbestemmelser punkt 3.4.4. Testrapporten konkluderte da med rette at dette ikke var en A-feil. Enten denne feilen ble stående som åpen eller lukket, ville antallet B- eller C-feil fortsatt ligge innenfor feilgrensene.

Det avtalte innholdet for iterasjon 2 må etter dette sies å ha fungert etter de godkjente testspesifikasjonene. Lagmannsretten går så over til å begrunne hvorfor gjennomføringsplanen ikke ga grunnlag for å underkjenne KP2. 4.4.8.6 Gjennomføringsplanen som grunnlag for å underkjenne KP2

Som nevnt mener lagmannsretten at IBM var forpliktet til å utarbeide en gjennomføringsplan til KP2 som var realistisk i den forstand at planen kunne nås. I underkjenningsbrevet 28. april 2015 skrev SVV at prognosedatoene var «urealistiske» og at planen ikke tok hensyn til «erfaringer og prosjektets reelle produktivitet». (FU 23210 på 23213) SVV bygde på en intern Program Evaluation and Review Technique (PERT)-analyse fra 17. april 2015. (FU 22759 og FU 23179 på 23202) Etter PERT-analysen ville IBM i «best case» nådd HMP2 9. november 2015 og «most likely» nådd HMP2 17. august 2016. Analysen la til grunn at iterasjon 2 var 50 prosent av totalløsningen og at IBM ville bruke like lang tid på iterasjon 3 som iterasjon 2. Den tok ikke hensyn til at iterasjon 3 var påbegynt. I underkjenningsbrevet skrev SVV også at planen til KP2 inneholdt flere datoer som var overskredet. (FU 23213) Presentasjonen som SVV holdt i KP-møte samme dag, listet opp prognosedatoer som IBM hadde satt og som selskapet ikke hadde overholdt.

(FU 23179 på 23193 flg.) Holte Consulting AS telte i rapport 25. november 2021 opp at om lag 350 av 1 100 aktiviteter som skulle vært påbegynt, ikke var det. (TU2 2780 på 2795) Slik lagmannsretten forstår staten, gjøres det ikke gjeldende at SVV kunne underkjenne planen på grunn av dårlig teknisk kvalitet. At planen inneholdt flere datoer som var overskredet, skal etter det lagmannsretten forstår bare underbygge at den ikke var realistisk. A-2 skrev for øvrig i rapporten «Foreløpige observasjoner knyttet til KP2» 27. april 2015:

• Fremdriftsplanen frem mot HMP2 er etter vår vurdering kvalitetsmessig klart forbedret gjennom det arbeidet som er utført i forbindelse med KP2.
• Det er fortsatt rom for forbedringer, men planen er nå etter vår vurdering i ferd med å kunne bli et reelt styringsredskap for prosjektet, ut fra en «godt nok» betraktning. (FU 23130 på 23132) Etter IBMs gjennomføringsplan til KP2 (PRO001 versjon 4.0 fra 22. april 2015), skulle DCUT-arbeidet for alle strømmene være ferdig 10. juni 2015 med unntak for SAP-strømmen, som skulle være ferdig 15. juni 2015. Planen innebar således at iterasjon 3 skulle gjøres ferdig i løpet av mindre enn to måneder. Iterasjonstestingen for iterasjon 3 skulle skje over noe mer enn to måneder fra 13. mai til 24. juli 2015, det vil si i delvis parallell med iterasjon 3. SIT skulle ta 49 dager. Ifølge denne planen, skulle IBM nådd HMP2 23. september 2015. (FU bilag 208) IBM hadde begrensede muligheter for å vinne tid etter HMP2. Det var SVV som sto for de etterfølgende milepælene HMP2.1, fullført godkjenningsprøve (akseptansetest), og HMP2.2, pilotmigrering med mer (prøvedrift). Partene har derfor redegjort for sine respektive syn på realismen av IBMs plan til KP2, frem til HMP2, det vil si frem til fullført design, utvikling og enhetstesting (DCUT), iterasjonstesting og systemintegrasjonstest (SIT).

Ved vurderingen av om denne gjennomføringsplanen kunne vært nådd, skal imidlertid endringsanmodninger «som har vært utstedt og utredet i gjennomførte trinn», tas i betrakting, jf. Generelle kontraktsbestemmelser punkt 3.4.5 andre avsnitt og veilederen til PS2000, versjon 3.1, punkt 5.3.3.4, side 24. (FU 8458 på 8468) Lagmannsretten ser det derfor som mest korrekt å vurdere realismen i IBMs gjennomføringsplan i forhold HMP2.2. I motsetning til HMP2, reflekterer HMP2.2 at IBM har krav på fristforlengelse for SVVs ferier og EA078 (Kina). SVV har ikke fremsatt krav om mer tid til akseptansetest og prøvedrift. IBMs gjennomføringsplan inkluderte tre uker sommerferie (uke 28-30), EA053, EA075 og EA091, men ikke juleferie, EA054 (Arbeidsform), EA067 (Greenbird) og EA078 (Kina-saken). (FU 22330 og 22992) Som nevnt mener lagmannsretten at SVVs ferier ga IBM rett til fristforlengelse, herunder 21 dager for SVVs juleferie. Som også nevnt var både EA054, EA067 og EA078 endringsanmodninger som var utstedt før KP2 og som lagmannsretten mener var tilstrekkelig utredet til at de ga IBM rett til fristforlengelse med til sammen 106 dager (14+2+90).

Når juleferie, EA054, EA067 og EA078 inkluderes i IBMs plan til KP2, skulle HMP2 nås 28. januar 2016 og HMP2.2 nås 5. juni 2016.

Ved vurderingen av om IBMs plan til KP2 kunne vært nådd, må videre «erfaringer fra gjennomført trinn», tas i betrakting, jf. Generelle kontraktsbestemmelser punkt 3.4.5 tredje avsnitt. (FU 8468) Slik lagmannsretten ser det, taler ikke erfaringene fra iterasjon 2 mot at IBM kunne nådd HMP2 28. januar 2016 og HMP2.2 til 5. juni 2016.

Fremdriften i DCUT-arbeidet hadde rett nok vært svært svak frem til KP2. Den aggregerte «DCUT Burndown»-oversikten som IBM delte med SVV i forbindelse med KP2, viser at IBM bare hadde ferdigstilt arbeidspakker med Planned Value (PV) på vel 4 000 DCUT-timer i firemånedersperioden fra 19. desember 2014 til 22. april 2015 (gjennomsnittlig 1 000 DCUT-timer per måned). Per 22. april 2015 gjensto det å ferdigstille arbeidspakker med PV på i underkant av 12 000 DCUT-timer til den siste en og en halv måneden. (FU 23197) Hvis IBM skulle greid å gjøre disse ca. 12 000 DCUT-timene ferdig til 15. juni 2015, måtte selskapet med andre ord blitt åtte ganger mer produktiv. IBMs interne DCUT Burndown-oversikter og rapporter per strøm fra denne tiden, viser at fremdriften hadde vært særlig svak i strømmene SAP, INT og CRM. (FU 21990 på 21991, FU 23078 på 23083 og 23099 samt FU bilag 1603 og 1608) Professor Magne Jørgensen har forklart at en produktivitet som har satt seg, ikke endres uten grunnleggende endringer. A-2 har pekt på det samme.

(FU 16708 på 16712) Den svake fremdriften i SAP-strømmen ga dessuten grunnlag for bekymring for at denne strømmen hadde problemer som ikke var avdekket. IBMs interne kvalitetssikrer, Anders Thörnqvist, rapporterte internt 8. april 2015: Finding #37 Only very few SAP enhancements identified. This may be an indication that scope will grow. (TU bilag 1772) Grensesnitt mellom SAP FI-CA og SugarCRM knyttet til sletting av fakturaer, sletting av tilleggsavgifter og utstedelse av kreditnotaer, var ikke løst. Lorenz Lorenzen, som IBM hadde satt til å styrke planarbeidet fra mars 2015, flagget i intern e-post 15. april 2015 at spesifikasjonene for de interne grensesnittene ville bli ferdig «months later than» 29. mai 2015 med «the current» ressurssituasjon lokalt i Norge og forårsake overskridelse av HMP2. (FU 22566) GD Kina meldte 30. april 2015, det vil si to dager etter KP2-underkjenningen, at det ville bli krevende å holde planen. (FU 21990 på 21991) GD India meldte 1., 8. og 15. mai 2015 at «overall timelines are not realistic».

(FU 23354 på 23358, FU 23652 på 23656 og FU 23779 på 23780) Planen som GD Kina og GD India ga tilbakemeldinger på her, var planen fra 22. april 2015 om å ferdigstille DCUT-arbeidet til midten av juni 2015 uten tillegg av endringer. På den andre siden har SVVs funksjonelt løsningsansvarlige for CRM-strømmen, Arve Leivestad, forklart at funksjonaliteten var på plass ved KP2 og at misnøyen etter kundetesten gikk på brukeropplevelsen og brukervennligheten. Videre hadde IBM brukt fire måneder på iterasjonstestingen av iterasjon 2. IBM opplyste i EA108 at selskapet hadde hatt fokus på feilretting i seks av ukene. (FU 24458 på 24459) Iterasjon 3 var noe større enn iterasjon 2. Iterasjon 3 omfattet minst like kompleks funksjonalitet og like mange interne grensesnitt. IBM la dessuten opp til en mer kompleks testing av iterasjon 3. Blant annet skulle IBM begynne å teste ikke-funksjonelle krav og bruke mer realistiske testdata. (FU 22857 på 22862) IBM skulle også gjøre all «ende til ende»-testing av interne grensesnitt i iterasjon 3.

Thörnqvist pekte i rapport 8. april 2015 på at utfordringene under iterasjon 1 og 2 med «late staffing, wrong skillset, lack of delivery control» hadde begynt å dukke opp som «quality issues». (TU 2401 på 2402) På den andre siden utviklet feilraten seg slik at det var grunn til å forvente mindre omfattende feilretting i iterasjon 3. Statusrapportene 6. og 13. januar 2015 viste feilrater på henholdsvis 48 og 36 prosent (eksklusive blokkerte tester). (FU 18906 på 18913 og FU 18915 på 18920) Statusrapporten fra 23. februar 2015 viste at feilraten var kommet ned i ca. 15 prosent. (FU 18956 på 18963) Det var da liten grunn til å mistenke noe grunnleggende feil med kildekoden. Som nevnt i punkt 4.4.8.5 viste testrapporten 20. april 2015 at løsningen hadde få feil. Sett på bakgrunn av denne utviklingen i feilraten, mener lagmannsretten at testplanen for iterasjon 3 kunne basere seg på en feilrate på 10 prosent. (FU 19007) Det var således ikke grunn til å legge inn like mye tid til feilretting i planen som for iterasjon 2.

Videre taler utviklingen i antallet blokkerte tester caser for at det var fremdrift iterasjonstestingen og i leveransen. Det går frem av statusrapportene 13. og 19. januar 2015 at henholdsvis 415 og 250 av om lag 1 500

test caser var blokkert. (FU 18915 på 18920 og FU 18922 på 18927) Det går frem av statusrapporten 23. februar 2015 at antallet blokkerte test caser var nede i 106 av 1 320. (FU 18956 på 18963) IBMs testleder, Sally Drew, har redegjort for at produktiviteten økte fra 0,9 test caser per ressurs per dag i perioden 18. februar til 16. mars 2015, til 2,2 test caser per ressurs per dag i perioden fra 17. til 31. mars 2015. Det ble arbeidet for ytterligere produktivitetsøkning. Det gjaldt å endre tenkningen til testerne. Den 25. mars 2015 greide de i alt 16 testerne den gangen å teste 100 test caser med helge- og overtidsarbeid. Ifølge Drew ville dessuten majoriteten av testene for iterasjon 3 ha vært repetisjoner av testene for iterasjon 2 og derfor ha gått raskere. Den første runden med testing tar oftest dobbelt så lang tid som senere tester. Det var ikke gjort noen erfaringer med SIT som planen om 49 dager kunne vurderes ut fra. SIT skulle gjennomføres for første gang etter iterasjonstestingen av iterasjon 3. Her skulle blant annet alle eksterne grensesnitt testes for første gang.

IBMs ledelse mente at HMP2 kunne ha vært nådd til 23. september 2015 slik planen til KP2 la opp til. Interne e-poster 22. april 2015 viser at IBM hadde som ambisjon å følge gjennomføringsplanen til KP2. IBMs lokale utviklingsleder for GD India, Jan Hård af Segerstad, skrev at det var «imperative for IBM that we deliver according to the dates set out in this plan and I hereby advice each stream to adjust internal planning accordingly». (FU 23000) European Public Sector Delivery Leader and Executive Partner, Stewart Knox, skrev at «we now have to deliver against this plan». (FU 23001) A-2 trodde derimot ikke at det ville ha latt seg gjøre å holde IBMs plan til KP2. I en presentasjon med «Foreløpige observasjoner knyttet til KP2» 27. april 2015, står det: Selv om planen og den indre konsistensen er forbedret, er det fortsatt problematisk at datoen for HMP2 er såpass aggressivt satt. Vi ser ikke tilstrekkelige tiltak for å kunne si at vi tror det vil la seg gjøre å være ferdig innen 23.9. Samtidig er det leverandørens ansvar å sette datoen basert på egen vurdering av situasjonen.

(FU 23130 på 23135) Som nevnt er spørsmålet imidlertid ikke om HMP2 kunne ha vært nådd til 23. september 2015, men om HMP2 kunne vært nådd til 28. januar 2016 – og om HMP2.2 kunne vært nådd 5. juni 2016. Som lagmannsretten kommer tilbake til under vurderingen av når IBM kunne ha nådd HMP2 basert på situasjonen da SVV hevet kontrakten 27. juli 2015 i punkt 4.5 nedenfor, mener lagmannsretten at HMP2 realistisk sett kunne ha vært nådd til 26. desember 2015, og at HMP2.2 da kunne vært nådd 3. mai 2016. Lagmannsretten mener at vurderingen av når HMP2 kunne vært nådd, blir den samme basert på situasjonen da IBM leverte planen til KP2 22. april 2015. Ut fra erfaringene med iterasjon 2, la IBM inn tiltak for å bedre produktiviteten. Det går frem av referatet fra KP-møte 13. april 2015 at IBM så på planen som «aggressiv, med behov for spesifikke tiltak for å øke produktiviteten», og at IBM ønsket «å ta grep i forhold til testplanleggingen for iterasjon 3». (FU 22322 på 22330 og 22328) Det ble tatt grep som ville satt IBM i stand til å løse gjenstående oppgaver slik som det nevnte grensesnittet mellom SAP FI-CA og SugarCRM.

Som lagmannsretten kommer tilbake til under vurderingen av når IBM kunne nådd HMP2 basert på situasjonen da SVV hevet kontrakten 27. juli 2015, besluttet IBM før KP2 å utarbeide generiske grensesnitt mellom SAP FI-CA og SugarCRM. (FU 2082 og 20719) Utfordringene med grensesnitt mellom SAP FI-CA og SugarCRM, var således ikke bare tenkt løst ved å utfordre «CRM as a front-end for SAP functionality» slik IBMs lokale utviklingsleder for GD India, Jan Hård af Segerstad, skrev i ukesrapport 17. april 2015. (FU 22256 på 22257) Videre foreslo eksempelvis Lorenz Lorenzen i den nevnte e-posten 15. april 2015, å sette inn ekstra ressurser for å ferdigstille grensesnittspesifikasjonene for de interne grensesnittene. Han ga samtidig uttrykk for at spesifikasjonene i så tilfellet kunne bli ferdig etter planen. (FU 22566) Slik lagmannsretten forstår denne eposten, kunne de ekstra ressursene langt på vei skaffes bare ved å øke stillingsprosenten til ressursene som allerede var tilgjengelig.

Etter dette er det ikke nødvendig for lagmannsretten å gå inn på om plikten til å utarbeide en realistisk plan opphørte hvis den ville ha vist at hevingsfristen «klart» ville ha blitt overskredet.

4.4.9 EA108, 113 og 117

IBM har som nevnt fremmet tre endringsanmodninger med bakgrunn i underkjenningen av KP2: EA108 som ble utstedt 3. juni 2015, EA 113 som ble utstedt 10. juni 2015, og EA117 som ble utstedt 10. juli 2015. (FU 24458, 24704 og 25559) EA108 om «manglende tilbakemelding fra SVV om innholdet i iterasjon 2», og EA113 om «forberedelse og gjennomføring av Kontrollpunkt 2», knytter seg til SVVs underkjenning av scope/innholdet i KP2. De er begge begrunnet i at SVV brøt medvirkningsplikten ved å ikke varsle IBM om sine innsigelser på innholdet i iterasjon 2 på et tidligere tidspunkt, jf. Generelle kontraktsbestemmelser punkt 1.3 og 6.2.2. Kravet om fristforlengelse bygger på at SVVs syn på volumet i iterasjon 2, innebar at det hele tiden hadde vært umulig å få godkjent KP2. KP2 var et «spill for galleriet» og arbeidet til å forberede KP2 – gjennomføre tester (inkludert kundetester), feilrette for å få leveransen innenfor inngangskriteriene, forberede dokumentleveranser, planer, møter m.m. – var bortkastet. Kravet i EA108 er på 56 kalenderdager og gjelder perioden 2. februar til 27. mars 2015.

Kravet omfatter seks uker for å teste leveransen til KP2 med fokus på feilretting i stedet for å utføre utviklingsaktiviteter, en uke for å gjennomføre kundetest og en uke for å forberede til KP2. Kravet i EA113 knytter seg til selve gjennomføringen av KP2 med underkjenning av inngangskriteriene m.m. i perioden 13. til 28. april 2015, og er på 16 kalenderdager, hvorav syv dager i uke 16 for «gjennomføring og stopp av Kontrollpunkt + forberedelser til Kontrollpunkt» og ni dager i uke 17 og 18 for «gjennomføring, stopp og restart av Kontrollpunkt». EA117 knytter seg til perioden etter underkjenningen av KP2 og gjelder «gjennomføring av iterasjon 2 og nytt kontrollpunkt 2». Endringsanmodningen er begrunnet slik: Som en konsekvens av at SVV så langt ikke har godkjent KP2 og gjennom dette heller ikke planen for Iterasjon 3 ... vil IBM i samarbeide med SVV levere de resterende 20% av Iterasjon 2, definert i Gjennomføringsplanen v.1.2.

Ved slik leveranse til et nytt Kontrollpunkt 2 vil IBM oppdatere planen for Iterasjon 3 slik at denne kan bli gjennomgått og godkjent som en del av Kontrollpunktgjennomføringen i Kontrakten, og at denne planen kan danne basis for en omforent plan for resten av gjennomføringen av prosjektet. Denne endringsanmodning inneholder den økte tid og kost IBM har og har planlagt med for å levere de resterende 20% av Iterasjon 2, ved et nytt forsøk på å få et godkjent Kontrollpunkt 2 og dermed sikre en godkjent Iterasjon 3 plan for leveranse av resten av prosjektet. SVV har som følge av sine beslutninger som beskrevet ovenfor, gjort det nødvendig for IBM å gjennomføre leveransen i henhold til kontrakt på en langt mindre effektiv måte. Det er kostnadene ved en slik lavere effektivitet og følgende konsekvenser i form av forsinkelser i prosjektet som er dekket av denne endringsanmodning.

Det er klart at kodeutvikling og testing utført i denne perioden er omfattet av kontrakten, og som følge av dette er kostnadene relatert til design, koding og «Unit Testing» (DCUT) samt testutførelse i perioden for denne endringsanmodning ikke tatt med i beregning av kostnadene for endringen. IBMs plan for å levere den resterende 20 prosent av iterasjon 2 ved KP1 som beskrevet over, ble presentert for SVV i det såkalte direktørmøtet 8. juni 2015. (FU 24640 på 24644) I EA117 har IBM krevd fristforlengelse med 113 kalenderdager for perioden fra 8. juni 2015 og frem til 29. september 2015, som var planlagt dato for ferdigstillelse av den oppdaterte planen for iterasjon 3. Lagmannsretten tar ikke stilling til om SVV har brutt sin medvirkningsplikt ved å ikke varsle IBM om at de mente at volumet i iterasjon 2 ikke var tilstrekkelig for å oppnå KP2-godkjenning. For lagmannsretten er det tilstrekkelig å vise til at underkjenningen av KP2 var urettmessig, jf. punkt 4.4.8 over.

Det følger av Generelle kontraktsbestemmelser punkt 3.6.1 at IBM har krav på fristforlengelse i den grad selskapet er påført merarbeid eller forsinket som følge av den urettmessige underkjenningen. (FU 8471) Lagmannsretten mener at det er merarbeidet knyttet til å gjennomføre et nytt KP2 som bør danne grunnlaget for et endringskrav. Når lagmannsretten har kommet til at underkjenningen av den gjennomførte KP2 var urettmessig, følger det motsetningsvis at KP2 skulle ha blitt godkjent i april 2015, og at IBM skulle ha vært spart for arbeid og forberedelser til enda et KP2. Det er derfor merarbeid og forberedelser til å gjennomføre et nytt KP2 med større scope, som er konsekvensen av underkjenningen. Lagmannsretten behandler derfor EA117 først, da denne omfatter «gjennomføringen av iterasjon 2 og nytt kontrollpunkt 2». Etter Generelle kontraktsbestemmelser punkt 3.4.5 kunne arbeid med iterasjon 3 først igangsettes når SVV hadde godkjent planen for denne iterasjonen. (FU 8468) Konsekvensen av den urettmessige underkjenningen

av KP2, var som nevnt at IBM ikke fikk godkjent planen for iterasjon 3, som IBM allerede var i gang med. Lagmannsretten mener at IBM, i mangel av en godkjent plan, ikke hadde annet valg enn å stanse aktivitetene for iterasjon 3 og fokusere på å levere det som gjensto på iterasjon 2 for å få godkjent KP2, herunder levere en oppdatert plan for iterasjon 3. Lagmannsretten mener at IBM må kunne kreve fristforlengelse for de tidsmessige konsekvensene av denne replanleggingen av leveransen, og den lavere effektivitetsgraden som gjennomføringen av et nytt KP2 medførte, slik det er beskrevet i EA117. Slik lagmannsretten ser det, er det dette som er den reelle konsekvensen av underkjenningen av KP2. Fristforlengelseskravet i EA117 er som nevnt på 113 kalenderdager og omfatter perioden fra 8. juni 2015 til 29. september 2015, herunder gjennomføringen av et nytt KP2. Det er i EA117 presisert at kravet ikke omfatter utvikling, feilretting og testing, og lagmannsretten legger dette til grunn. I følge IBM var 44 prosent av arbeidet i EA117 utført på hevingstidspunktet.

Dette har imidlertid ikke betydning for fristforlengelseskravet, bare for vederlagskravet, jf. punkt 5.5 nedenfor. Lagmannsretten mener at kravet er høyt, særlig sett hen til at det bare var 20 prosent av iterasjon 2 ved KP1 som det gjensto å ferdigstille. Likevel ser lagmannsretten det som sannsynlig at behovet for replanleggingen av iterasjon 2 forsinket IBM vesentlig. At resten av iterasjon 2 måtte utvikles separat i stedet for som del av iterasjon 3, medførte mest sannsynlig også et effektivitetstap. Planleggingen og gjennomføringen av at nytt KP2 ville også krevd tid. Ved den konkrete vurderingen har lagmannsretten sett hen til at A-2 mente at forsinkelsen på prosjektet ved å innføre et nytt KP2, ville vært på to måneder. (FU 24915 på 24919) Lagmannsretten mener at to måneder er et rimelig estimat av forsinkelsen, og gir IBM medhold i en fristforlengelse på 60 kalenderdager for EA117.

Når IBM gis medhold i kravet om fristforlengelse for tiden til å planlegge og forberede et nytt KP2 i EA117, kan de ikke samtidig få medhold i kravet om fristforlengelse for tiden til å planlegge og forberede seg til det opprinnelige KP2 i EA108 og EA113. Etter kontrakten måtte IBM gjennomføre ett KP2. IBMs leveranse til KP2 i april 2015 skulle ikke vært underkjent, men godkjent. IBMs arbeid og forberedelser til dette gjennomførte kontrollpunktet var i dette perspektivet ikke noe som selskapet kan kreve endring for. Arbeidet var slik sett ikke en konsekvens av den urettmessige underkjenningen av KP2. Lagmannsretten mener videre at IBM ikke kan få medhold i kravet i EA108 om fristforlengelse for tiden brukt på å teste og feilrette leveransen til KP2 i stedet for å utføre utviklingsaktiviteter. IBM ville uansett også måttet gjøre dette arbeidet på ett eller annet tidspunkt for å sikre kvaliteten på arbeidet. Arbeidet var ikke en konsekvens av den urettmessige underkjenningen av KP2.

4.4.10 EA112 (R8 miljø) EA112 ble opprettet av IBM ved Nicolai Rygh 4. juni 2015. Den gjelder merarbeid som IBM skal ha blitt påført som følge av SVVs manglende lukking av restanse R8, som ble opprettet ved godkjenning av HMP1. (TU2 1665) Endringskravet er begrunnet som følger: Leverandøren har besvart R8, samt oppfølgingsspørsmålene fra Kunden. Kunden holder denne åpen grunnet ønske om å få tilgang til miljøet før saken lukkes. Dette var ikke en aktuell problemstilling ved HMP1, og lukking av R8 kan ikke hindres av dette. Det er avtalt tidspunkt for når Kunden vil få tilgang til miljøet. [...] Leverandør vurderer merarbeidet påført av Kunden for arbeid knyttet til R8 som ligger utenfor restansens opprinnelige karakter til å tilsvare to dagers forsinkelse. To dager verdsettes basert på sist ukes forbruk til 1 039 015 Kroner. Tingretten uttalte om EA112 i dommen på side 110: I SVVs statusrapport for mai 2015 fremgår det at R8 ble lukket i uke 23-24 (FU 23348). Det vil si omtrent samtidig som IBM fremsatte endringsanmodningen (4. juni var torsdag i uke 23). Lukkingen var sannsynligvis foranlediget av EA112.

Det må antas at SVV utsatte lukkingen av andre grunner enn de som opprinnelig ble oppgitt i R8. Det kommer imidlertid ikke tydelig frem av underlaget hvorfor en slik utsettelse skal ha ført til at IBM fikk merarbeid tilsvarende to dagers forsinkelse. Retten finner derfor ikke at det er ført tilstrekkelig bevis for at EA112 var berettiget.

Partene har knapt behandlet EA112 under ankeforhandlingen. Det er etter lagmannsrettens syn ikke kommet anførsler eller bevis som gir lagmannsretten grunnlag for å overprøve tingrettens vurdering. Lagmannsretten legger derfor tingrettens vurdering om at EA112 ikke var berettiget, til grunn, jf. tvisteloven § 29-18 tredje ledd, jf. § 11-2 første ledd.

4.4.11 Oppsummering Oppsummert mener lagmannsretten at IBM har krav på fristforlengelse og flytting av kontraktens milepæler med i alt 250 kalenderdager (49 dager for SVVs ferie, 35 dager for EA053 (økt kompleksitet), 14 dager for EA054 (arbeidsform), to dager for EA067 (Greenbird), 90 dager for EA078 (Kina) og 60 dager for EA117 (nytt KP2)). Etter dette blir hevingsfristen 5.2 april 2016 med utgangspunkt i HMP2 og 12.3 august 2016 med utgangspunkt i HMP2.2. Lagmannsretten vil i punkt 4.5 nedenfor begrunne at det på hevingstidspunktet ikke kunne anses som klart at IBM ville overskredet disse endrede hovedmilepælene. Lagmannsretten ser det derfor ikke som nødvendig å gå inn på om IBM hadde krav på fristforlengelse og flytting av milepæler som følge av andre forhold i gruppe (iii) (forhold som rettmessig var påberopt som endringer til kontrakten, men hvor konsekvensen ennå ikke var inntrådt ved heving) enn EA078.

4.5 Kunne IBM nådd HMP2 til 5.1 april 2016/HMP2.2 til 12.2 august 2016? 4.5.1 De sakkyndiges vurderinger av når HMP2 kunne vært nådd Staten har innhentet to analyser av fremdriften til HMP2. Begge analysene inneholder vurderinger av hvor lang tid det ville tatt å gjennomføre følgende fire trinn: tilbakeføre ressursene som var tatt ut av iterasjon 3 fra midten av juni 2015, gjøre ferdig DCUT-arbeidet for iterasjon 3 samt gjennomføre iterasjonstesten for iterasjon 3 og SIT. Den første analysen er rapport fra Holte Consulting AS 25. november 2021. (TU2 2780 flg.) Holte har utarbeidet prognoser for det gjenstående DCUT-arbeidet basert på IBMs DCUT-rapporter frem til begynnelsen av juni 2015 (4. juni 2015). Holte forutsatte at det ikke ville skje endringer i ressurser og omfang, og lagde prognoser for ferdigstillelsesdato ved lineære ekstrapoleringer av tidligere nedbrenningsfart i de ulike strømmene.

Den optimistiske prognosen, kalt «best case», la nedbrenningsfarten i de fem siste ukene før begynnelsen av juni 2015 til grunn, mens den pessimistiske, kalt «worst case», la farten i de fem siste månedene før begynnelsen av juni 2015 til grunn. Holte lagde også et gjennomsnitt av de to prognosene, kalt «sannsynlig». (TU2 2797 og FU bilag 1610) Etter den positive prognosen ville DCUT-arbeidet i strømmene INT, CRM, SEL, REP og SEC, vært ferdig i løpet av september 2015. (TU2 2795 flg.) Holte presiserte imidlertid uten nærmere begrunnelse at INT-strømmen ville vært «ferdig tidligst samtidig med den siste av SAP og CRM, men ikke under noen omstendighet før 1.12.2015». (TU2 2798) Holte vurderte at det ikke var godt nok grunnlag for prognoser for SAP-strømmen. Denne strømmen var ifølge Holte «i oppbrudd» i juni 2015 «med overføring av videre arbeid til lokal organisasjon».

(TU2 2797) Med utgangspunkt i 2 400 gjenstående DCUT-timer i SAP-strømmen og en etableringsforsinkelse på to måneder, vurderte Holte at denne strømmen måtte ha vært tilført en produksjonskapasitet på minst fire nye kompetente ressurser på full tid («FTE» (Full Time Equivalent)), det vil si 600 timer per måned, for at den kunne vært ferdig til desember 2015. (TU2 2804) Holte vurderte at tilbakeføringen av ressursene som ble tatt ut av iterasjon 3 fra midten av juni 2015, optimistisk sett ville tatt to måneder. (TU2 2803 og 2807) Iterasjonstesten og SIT ville optimistisk sett tatt henholdsvis tre måneder og 49 dager. (TU2 2806 og 2807) At SIT optimistisk sett ville tatt 49 dager, var tatt fra IBMs gjennomføringsplan til KP2. Holte konkluderte med at IBM ville endt med en forsinkelse på over 400 dager i forhold til den kontraktsfestede HMP2-datoen 28. april 2015, uansett scenario. Optimistisk sett, ville HMP2 vært nådd 418 dager forsinket den 19. juni 2016. (FU 2783 og 2807)

Seniorrådgiver Trond Botheim, som har skrevet rapporten fra Holte sammen med analytiker Borgar Lund, har forklart at prognosene ikke var en «best case»-/«worst case»-fremstilling. Han gjorde ingen vurdering av sannsynligheten for «best case», men ville heller ikke talt om «best case» hvis han ikke hadde trodd at dette var et mulig scenario. Han utelukket ikke at strømmene CRM, SEL, REP og SEC kunne blitt ferdig i løpet av september 2015, men utelukket at INT-strømmen kunne blitt det. Han vurderte den økte fremdriften i INTstrømmen de siste fem ukene før begynnelsen av juni 2015 som midlertidig fordi den avvek fra alle andre perioder. Han så det derfor som helt usannsynlig at denne fremdriften ville vedvare. Trond Botheim har videre forklart at det optimistiske anslaget over hvor lang tid det ville tatt å oppbemanne iterasjon 3, bygde på hans subjektive vurdering av hva som skulle til for å remobilisere. Det var en «finger i været»-betraktning. Det optimistiske anslaget over hvor lang tid iterasjonstesten av iterasjon 3 ville tatt, bygde på at den ville tatt like lang tid som iterasjonstesten av iterasjon 2.

Det optimistiske anslaget over hvor lang tid det ville tatt å gjennomføre SIT, forutsatte at de eksterne grensesnittene var testet i forkant. Den andre analysen er rapport fra IT-rådgiver Leif-Arne Rones 2. desember 2021. (TU2 2825 flg.) Leif-Arne Rones la til grunn at omfanget og varigheten av design (D), utvikling/enhetstesting (CUT) og testing, som en tommelfingerregel sto i et 1:2:2-forhold; hvis CUT hadde tatt 100 dager, ville testingen ta like lang tid. (TU2 2857) I likhet med Holte Consulting AS, brukte Rones INT-strømmen for å anslå når DCUT-arbeidet ville vært ferdig. Han viste til at denne strømmen var svært viktig for «ende til ende»-testing, og at den historisk sett hadde hatt den laveste fremdriften. Han tok utgangspunkt i at det gjensto 2 134 DCUT-timer i INT-strømmen per 2. juni 2015 og ekstrapolerte basert på at det i perioden på fem måneder fra slutten av desember 2014 til begynnelsen av juni 2015 (2. juni 2015), var nedbrent 1 310 DCUT-timer. (TU2 2859 og bilag 1610) Han kom til at INT-strømmen ville vært «nedbrent etter ytterligere 273 kalenderdager».

Han la til 60 kalenderdager for tilbakeføring av ressursene som var blitt tatt ut av iterasjon 3, og kom til at INT-strømmen ville blitt ferdig i slutten av april 2016. (TU2 2859) Leif-Arne Rones la så til 38 dager for iterasjonstesting og 12 uker/tre måneder for SIT ved bruk av 1:2:2regelen. (TU2 2858, 2861 og 2862) At iterasjonstesten ville tatt 38 dager, var tatt fra IBMs gjennomføringsplan til KP2 uten nærmere vurdering. Rones kom til at HMP2 ville vært nådd 26. oktober 2016. Dette ville vært 547 dager forsinket i forhold til den kontraktsfestede HMP2-datoen 28. april 2015. (TU2 2860) Leif-Arne Rones har forklart at han tok utgangspunkt i INT-strømmen også fordi denne strømmen blir ferdig til sist. Han vurderte at det ikke var grunnlag for å ta utgangspunkt i nedbrenningsfarten i mai 2015 ved ekstrapoleringen. Det som skjedde i mai, var bare en «kalving» av arbeid som var påbegynt i månedene februar til april 2015. Av de 747 DCUT-timene som ble inntjent i mai 2015, var det bare 100 som var påbegynt denne måneden. Videre flatet nedbrenningen ut fra slutten av mai 2015.

Forutsatt at det ble satt inn tiltak som virket, ville han likevel ikke utelukke at nedbrenningsfarten i mai 2015 fortsatte. Leif-Arne Rones har videre forklart at han ikke overprøvde IBMs vurdering av at iterasjonstesten ville tatt 38 dager, men at han forlenget SIT til 12 uker/tre måneder («80 arbeidsdager») fordi eksterne grensesnitt ikke var testet tidligere. Han la til grunn at det dreide seg om ca. 40 grensesnitt og at IBM greide å teste fem til ti grensesnitt per måned. Han hadde ingen konkrete kilder for 1:2:2-regelen. Han brukte den som en tommelfingerregel «av og til».

4.5.2 Lagmannsrettens vurdering av når HMP2 og HMP2.2 kunne vært nådd 4.5.2.1 Innledning – Metoden Lagmannsretten ser det ikke som «klart» at IBM ville ha overskredet hevingsfristen 5.1 april 2016 med utgangspunkt i HMP2 og 12.2 august 2016 med utgangspunkt i HMP2.2. Lagmannsretten tar ved vurderingen av om IBM kunne ha nådd hevingsfristen, utgangspunkt i de sakkyndiges metode med å ekstrapolere nedbrenningsfarten i «DCUT burndown». Denne metoden eliminerer IBMs mislighold knyttet til EV-rapporteringen. Lagmannsretten tar også utgangspunkt i de samme fire trinnene som de sakkyndige, det vil si tilbakeføring av ressursene som var tatt ut av iterasjon 3 fra midten av juni 2015, DCUT-arbeidet, iterasjonstesten for iterasjon 3 og SIT. Siden det som må være klart for at kontrakten kunne heves, er at hevingsfristen ville blitt overskredet, blir vurderingstemaet imidlertid om IBM alt i alt kunne nådd

levering innenfor hevingsfristen. Den trinnvise tilnærmingen brukes bare som struktur ved totalvurderingen av om IBM ville greid å levere i tide. Sett på bakgrunn av at det kreves noe nær visshet for antesipert mislighold eller at det er noe nær sikkert at et slikt mislighold ville ha inntrådt, mener lagmannsretten at dette strenge beviskravet ikke vil være oppfylt hvis IBM realistisk sett kunne ha nådd hevingsfristen. Det måtte kunne latt seg gjøre å nå hevingsfristen i praksis. Som varslet under behandlingen av underkjenningen av gjennomføringsplanen til KP2 i punkt 4.4.8.6, mener lagmannsretten at HMP2 realistisk sett kunne ha vært nådd 26. desember 2015, og at HMP2.2 da kunne ha vært nådd 3. mai 2016. Dette er innenfor hevingsfristen. 4.5.2.2 Ressursene som var trukket ut av iterasjon 3 Etter lagmannsrettens syn skal det ikke legges inn tid for tilbakeføring av ressursene som ble trukket ut av iterasjon 3 fra midten av juni 2015. IBM trakk ut ressursene av iterasjon 3 som svar på underkjenningen av leveransen til KP2.

I prosjektledermøtet 10. juni 2015 redegjorde IBM for at selskapet i stedet ville sette inn alt på å levere den gjenstående 20prosenten av iterasjon 2 slik denne iterasjonen var definert ved KP1 (iterasjon 2.5), og at IBM «i nytt KP2» ville be om «godkjenning av plan for iterasjon 3». (FU 24684 på 24687) Det samme går frem av brev fra IBM til SVV 17. juni 2015. (FU 25014 på 25015 og 25016) Slik lagmannsretten ser det, falt IBM her bare tilbake på kontraktens system om at «arbeidet med etterfølgende trinn», det vil her si iterasjon 3, «først igangsettes når Kunden [...] har godkjent planen» for dette trinnet, jf. Generelle kontraktsbestemmelser punkt 3.4.5 tredje avsnitt. (FU 8458 på 8468) I og med at SVV ikke hadde godkjent noen plan for iterasjon 3, skulle det heller skje noe arbeid med denne iterasjonen. Som nevnt mener lagmannsretten at underkjenningen av KP2 var urettmessig. Ved den videre vurderingen av når DCUT-arbeidet med iterasjon 3 ville vært ferdig, må det da ses bort fra den urettmessige underkjenningen.

Hvis det ikke hadde vært for denne underkjenningen, ville arbeidet med iterasjon 3 ha fortsatt uavbrutt. 4.5.2.3 DCUT-arbeidet i iterasjon 3 Etter lagmannsrettens syn kunne IBM realistisk sett ha blitt ferdig med DCUT-arbeidet i iterasjon 3 innen september 2015. For lagmannsretten ser det ut til at det var utviklingen i strømmene SAP og INT som ville avgjort hvor tidlig iterasjon 3 kunne ha blitt ferdig. Det er ingen holdepunkter for at det var store problemer i andre strømmer enn SAP og INT på hevingstidspunktet. Problemene i CRM-strømmen var langt på vei løst. Som nevnt har SVVs funksjonelt løsningsansvarlige for CRM-strømmen, Arve Leivestad, forklart at funksjonaliteten var på plass allerede ved KP2. Det er lagt frem tre videoer som støtter Leivestads forklaring. (TU2 bilag 43 til 45) IBMs arkitekt for CRM-strømmen, Tonje Offenberg Bye, har forklart at hun lagde videoene i november/desember 2015, det vil si fire/fem måneder etter at kontrakten ble hevet, og at de viser løsningen «utpå våren en eller annen gang», det vil si våren 2015. Dessuten var iterasjon 2.5 levert 21. juli 2015.

(FU 25969 flg.) Strømmene SAP og INT hadde hatt lavest produktivitet i prosjektet. SAP-strømmen i GD Kina hadde hatt meget svak fremdrift hele våren 2015. I perioden på fem måneder fra slutten av desember 2014 til og med mai 2015, hadde GD Kina i gjennomsnitt gjort ferdig arbeidspakker med Planned Value (PV) på 200 DCUT-timer per måned. I den mest produktive måneden, mai 2015, ble det gjort ferdig arbeidspakker på bare 270 DCUT-timer. Andre strømmer meldte fra internt i IBM om at de ikke fikk gjort planlagt arbeid på grunn av avhengighet til SAP. Det går frem av statusrapport fra GD Kina 5. juni 2015 at mesteparten av arbeidet med utviklingen av grensesnitt, var flyttet fra GD Kina til GEO. (FU 24573 på 24574) I mai 2015 ble SAP-strømmen styrket med fem FTE lokalt i Norge (GEO). I begynnelsen av juni 2015 ble GEO styrket med ytterligere én FTE. Dette går frem av IBMs månedsrapport for mai 2015. (FU 24580 på 24593) Med disse ressursene på plass i GEO allerede i begynnelsen av juni 2015, er det ikke grunnlag for Holte Consultings etableringspåslag på to måneder.

Med Holtes overslag over gjenstående DCUT-timer på 2 400 og produksjon per FTE på 150 DCUT-timer per

måned, ville utviklingsarbeidet i SAP-strømmen ha vært fullført på mindre enn tre måneder regnet fra begynnelsen av juni 2015 (2 400 timer/(6 x 150) timer per måned = 2,67 måneder). Det ser imidlertid ut til at gjenstående DCUT-timer i SAP-strømmen var høyere enn 2 400 i begynnelsen av juni 2015. En sammenlikning av månedsrapportene fra GD Kina for mai og juni 2015, viser at det bare var arbeidspakker på rundt 1 000 DCUT-timer som ble flyttet fra Kina til GEO. (FU 24309 på 24310 og FU 24573 på 24574) Månedsrapporten for juni viser at det gjensto 1 900 DCUT-timer i GD Kina i begynnelsen av juni 2015, og at GD Kina skulle fokusere på funksjons- og ytelsestesting («function testing og performance test»). (FU 24574) Gjenstående DCUT-timer i SAP ser således ut til å ha vært 2 900 timer i begynnelsen av juni 2015 (1 000 + 1 900). Med Holtes tall for produksjon per FTE, ville utviklingen i SAP-strømmen da ha vært fullført på noe over tre måneder regnet fra begynnelsen av juni 2015 (2 900 timer/900 timer per måned = 3,22 måneder).

Utviklingen i SAP-strømmen ville således ha vært fullført innen september 2015, også med 2 900 gjenstående DCUT-timer. Ut fra IBMs månedsrapportering ser det ut til at to av de seks FTEene som ble satt inn i GEO, ikke arbeidet i SAP-strømmen i juni 2015. (FU bilag 1611) Slik lagmannsretten ser det, kunne SAP-strømmen ha blitt ferdig innen september 2015 også om to av de seks FTEene først kom i gang med DCUT i denne strømmen fra juli 2015. Med bare 600 fullførte timer i juni, ville det tatt om lag to og en halv måned fra begynnelsen av juli å fullføre SAP (2 300 timer/900 timer per måned = 2,56 måneder). Det ville dessuten vært gode muligheter for å oppbemanne SAP-strømmen ytterligere om nødvendig. Som påpekt av Holte, er SAP et globalt markedsledende produkt som det burde vært mulig å finne ressurser til. (TU2 2780 på 2804) At INT-strømmen i GD India 1. mai, 8. mai, 22. mai, 12. juni og 17. juli 2015 rapporterte om svak fremdrift på grunn av avhengighet til SAP, kan rett nok tale for at SAP-strømmen hadde kvalitative utfordringer som ikke lot seg løse bare ved ressursøkningen og flyttingen av SAP-grensesnitt til GEO i mai/juni 2015.

(FU 23354 på 23355, FU 23354 på 23373, FU 23652 på 23672, FU 24075 på 24077, FU 24075 på 24099, FU 24770 på 24772 og 24799 samt FU 25887 på 25917) Ifølge de to siste rapportene 12. juni og 17. juli 2015, var fire av 15 arbeidspakker forsinket fordi INT-strømmen ventet på grensesnittspesifikasjoner fra SAP («delayed due to dependency on SAP HLD» (High Level Design)). (FU 23672, 24099, 24799, 24803 og 25917) Det skjedde med andre ord liten forbedring i HLD rent faktisk. Lagmannsretten ser imidlertid mangelen på forbedring fra juni til juli i sammenheng med at ressursene var blitt trukket ut av iterasjon 3 fra midten av juni 2015 som følge av den urettmessige underkjenningen av KP2. Lagmannsretten ser ellers ingen grunn til at ikke styrkingen av GEO fra mai/juni 2015 ville ha forbedret koordineringen mellom SAP- og INT-strømmen og løst andre utfordringer i SAP-strømmen slik som gjenstående oppgaver som grensesnittet mellom SAP FI-CA og SugarCRM knyttet til sletting av faktura, sletting av tilleggsavgifter og utstedelse av kreditnota.

SAP er et standardisert produkt som inneholder all funksjonalitet for økonomistyring og krever normalt lite tilpasning. INT-strømmen i GD India hadde også hatt meget svak fremdrift hele våren 2015. Fra slutten av desember 2014 til og med mai 2015, hadde INT-strømmen gjort ferdig arbeidspakker med Planned Value (PV) på 1 003 DCUT-timer. Som for SAP-strømmen, vil det i gjennomsnitt si 200 DCUT-timer per måned. Ved inngangen til mai 2015 gjensto det om lag 3 200 DCUT-timer. I mai 2015 ble det derimot gjort ferdig arbeidspakker med PV på 747 DCUT-timer slik at det ved inngangen til juni 2015 gjensto om lag 2 450 DCUT-timer. (FU bilag 1610 linje 764, jf. FU bilag 208 linje 779) Videre var det bare utarbeidet kravspesifikasjoner for 30 prosent av de interne grensesnittene 22. april 2015 og 50 prosent av de interne grensesnittene 5. juni 2015. (FU bilag 208 linje 779 og bilag 210 linje 764) Lagmannsretten legger til grunn at det her ikke var tale om 30 og 50 prosent av alle grensesnitt, men av grensesnittene som det måtte utarbeides kravspesifikasjoner for.

Kravspesifikasjoner for grensesnitt som ivaretas av standardfunksjonalitet i modulene SugarCRM eller SAP FI-CA, er allerede dekket av IBMs løsning. For slike grensesnitt er det derfor ikke nødvendig å utarbeide egne kravspesifikasjoner. Hvis Leif-Arne Rones hadde lagt til grunn at INT-strømmen bare hadde gjort ferdig arbeidspakker med PV på 1 003 DCUT-timer i perioden på fem måneder før begynnelsen av juni 2015 og at det gjensto 2 450 DCUTtimer i begynnelsen av juni 2015, ville han med sine ekstrapoleringer ha kommet til at det hadde tatt enda lengre tid enn 273 kalenderdager fra begynnelsen av juni 2015 å ferdigstille INT-strømmen. Slik lagmannsretten ser det, blir det imidlertid ikke riktig å se på nedbrenningsfarten over de siste fem månedene, slik Leif-Arne Rones har gjort.

Den svake fremdriften i INT-strømmen våren 2015 hadde sammenheng med forhold som IBM ikke kan lastes for. Kravene til økonomifunksjonalitet (SAP) i SugarCRM, innebar en stor mengde enkle grensesnitt. Som effektiviseringstiltak, besluttet IBM 27. februar 2015 å utvikle generiske grensesnitt mellom SAP og SugarCRM for noen enkle grensesnitt. (FU 2082 og 20719) Utviklingen av de enkle grensesnittene som ble berørt ble satt på hold 23. mars 2015. (FU 21936 på 21955) Videre tok KP2 mye av tiden frem til slutten av april 2015. Siden INT er den siste strømmen som gjøres ferdig, er det dessuten logisk og vanlig at store deler av integrasjonsarbeidet gjøres ferdig mot slutten. Fremdriften bør måles i perioder hvor det skal skje utvikling. Dette er forhold som taler mot å bruke nedbrenningsfarten over en så lang periode som de siste fem månedene. Samtidig ble det satt i verk tiltak i INT-strømmen fra 1. mai 2015 som ser ut til å ha økt fremdriften. Det skjedde en oppbemanning. Seks FTEer i GD India ble økt til ti.

(FU 22567) Rapport fra GD India 3. juli 2015 viser at planlagte DCUT-timer økte tilsvarende fire FTEer fra 290 i april til 450 fra mai 2015, og at den faktiske DCUT-aktiviteten økte fra mai 2015. (FU 25370 på 25409) Som nevnt ble det gjort ferdig arbeidspakker på i alt 747 DCUT-timer i mai 2015. «Work tracking»-filen viser at 402 av disse DCUT-timene ble påbegynt i slutten av april 2015, og at nesten alle av de 402 DCUT-timene ble inntjent før 15. mai 2015, det vil si på mindre enn en måned. De resterende 345 DCUT-timene som ble inntjent i mai 2015, gjaldt grensesnitt som var påbegynt i februar 2015 og satt på hold fra 23. mars til 17. april 2015. Bare 27 prosent av arbeidet med disse grensesnittene ble utført i februar 2015. (FU bilag 1596) Inntjeningen i mai var med andre ord bare i begrenset grad «kalving» av arbeid som var påbegynt i månedene fra februar til april 2015. Dette er forhold som taler for å bruke nedbrenningsfarten i mai eller de fem siste ukene før begynnelsen av juni 2015. Med nedbrenningsfarten i mai 2015, ville INT-strømmen ha vært ferdig på vel tre måneder regnet fra begynnelsen av juni 2015.

(2 450 timer/747 timer per måned = 3,23 måneder) Med farten de siste fem ukene, kom Holte til at INT ville ha vært ferdig ca. 20. september 2015. Slik lagmannsretten ser det, blir det ikke riktig å korrigere nedbrenningsfarten i mai eller de fem siste ukene før begynnelsen av juni med den svakere fremdriften i juni og juli siden den hadde sammenheng med den urettmessige underkjenningen av KP2. Det går frem av rapporter fra GD India 19. juni og 17. juli 2015 at iterasjon 3 stanset opp fra midten av juni 2015 fordi fokuset var blitt flyttet over på iterasjon 2.5. (FU 25043 på 25075 og FU 25887 på 25917) GD India rapporterte likevel 12. og 19. juni 2015 om eksterne grensesnitt som var påbegynt, men som ikke kunne gjøres ferdig før CRM API (Application Programming Interface) var på plass. (FU 24770 på 24801 og FU 25043 på 25075) Det går frem av rapporten 17. juli 2015 at API var på plass på dette tidspunktet. (FU 25903) API ville økt nedbrenningsfarten ytterligere. For øvrig var fremdriften i iterasjon 2.5 fra midten av juni til midten av juli 2015, god.

Det ble brukt 233 DCUT-timer på å gjøre ferdig arbeidspakker med PV på 246 DCUT-timer. (FU 25917 og 25918) Scope for iterasjon 2.5 var ca. 300 DCUT-timer. (FU 25917) IBM har gjort gjeldende at gjenstående DCUT-timer ved inngangen til juni 2015 må reduseres fra 2 450 til 1 850 på grunn av Kina-saken. Lagmannsretten er ikke enig i dette. Arve Ryan, som var endringsansvarlig for SVV, bekreftet i e-post med overskriften «EA078 Kina-analyse» 30. april 2015 at alt integrasjonsarbeid som da foregikk i GBSC Kina, måtte flyttes til India. (FU 23455) En sammenlikning av rapportene fra GD India 15. og 22. mai 2015 taler for at det ble flyttet integrasjonsarbeid i siste halvdelen av mai 2015 tilsvarende 600 DCUT-timer. (FU 23779 på 23802 og 23807 samt FU 24075 på 24099 og 24109) Denne flyttingen ser imidlertid ikke ut til å ha medført noe merarbeid for IBM. Som nevnt i punkt 4.4.7 over har IBM bare angitt flytting av to ressurser fra GBSC Kina til Norge som tidskonsekvens i

EA078. (FU 22 906)

Samtidig går det frem av rapport fra GD India 17. juli 2015 at det var identifisert «certain new interfaces» som ikke var tatt inn i planene for iterasjon 3. (FU 25887 på 25926) De nye grensesnittene ville bidratt til å forlenge nedbrenningstiden. Slik lagmannsretten ser det, representerte på den andre siden beslutningen om å utvikle generiske grensesnitt en betydelig forseringsmulighet. Generiske grensesnitt er gjenbrukbare; ett generisk grensesnitt fungerer for flere enkle grensesnitt. I arkitekturbeslutningen 27. februar 2015 er det beskrevet at «a demand of numerous simple interfaces» mellom

SugarCRM og SAP FI-CA, hadde vist seg å være «a time consuming effort». (FU 2082 og 20719) Bruk av generiske grensesnitt ble begrunnet slik: Reusing one standard interface for this type of interfaces is expected to reduse effort, design, implementation and test significantly. The result will be redused time and cost meaning improved ability to reach deadlines and at the same time improve quality. (FU 2082) I beslutningen ble det identifisert noen grensesnitt som kunne være kandidater for generiske grensesnitt. Det var i alt 11 enkle interne grensesnitt mellom CRM og SAP FI-CA som skulle realiseres gjennom de to generiske grensesnittene I-CRM-FICA-303 (#303) og I-FICA-CRM-304 (#304). Seks av de enkle interne grensesnittene skulle realiseres gjennom #303. #303 (Proof of Concept (PoC) I-OBUL-FICA-208) ble påbegynt i februar 2015. (FU 20719 og FU bilag 1610) Mens det ble arbeidet med dette generiske grensesnittet, ble arbeidet med de berørte enkle grensesnittene satt på hold. Det går frem av ukesrapporter 8. og 15. mai 2015 at DCUT-arbeidet med #303 ble ferdig 8. mai 2015.

(FU 23652 på 23673 og FU 23779 på 23803) For lagmannsretten ser det ut til at det sto igjen noe arbeid på #303 etter DCUT. De seks enkle grensesnittene som skulle realiseres gjennom dette generiske grensesnittet, hørte til iterasjon 3. I ukerapport 17. juli 2015 er fem av disse enkle grensesnittene (052, 217, 218, 219 og 221) merket som «handover delayed». (FU 25887 på 25923 og 25924) Det går frem at det var «idle capacity due to insufficient work for iteration and focus shifting to Drop 2.5 with dependencies/waiting mode». (FU 25927) #304 ble byttet ut med #173 for iterasjon 2.5. (FU 24075 på 24101) Det går frem av ukesrapporter 19. juni og 10. juli 2015 at DCUT-arbeidet med #173 kom forsinket i gang 19. juni 2015, og at dette generiske grensesnittet ble ferdig 10. juli 2015. (FU 25043 på 25075 og FU 25790 på 25820 og 25821) Det går frem av Release Note 21. juli 2015 at #173 ble implementert i leveransen av iterasjon 2.5 med unntak for noe scope i CRM-strømmen som ble utsatt til iterasjon 3. (FU 25969 på 25977, 25978, 25984 og 25990).

Det var i alt åtte enkle eksterne grensesnitt som skulle realiseres gjennom de to generiske grensesnittene I-ESBFTP-301 (#301) og I-ESB-FTP-302 (#302). High Level Design (HLD) for #301 og #302 ble påbegynt 6. april 2015. DCUT for disse generiske grensesnittene ble påbegynt 17. april 2015. (FU 22786 på 22807) DCUT-arbeidet var ikke avsluttet på tidspunktet for hevingen. IBM har utarbeidet et hjelpedokument som viser at DCUT-arbeidet var 57 prosent ferdig per 4. juni 2015. (FU bilag 1610) Det går frem av statusrapporten fra GD India 17. juli 2015 at arbeidet var satt på hold på grunn av skiftet til iterasjon 2.5. (FU 25887 på 25917 og 25922) Oppsummert ser det ut til at det sto igjen noe arbeid på alle de fire generiske grensesnittene på hevingstidspunktet før de kunne anses som helt ferdige. Lagmannsretten ser dette i sammenheng med at ressursene var trukket ut av iterasjon 3 som følge av den urettmessige underkjenningen av KP2, og ser bort fra at de generiske grensesnittene var uferdige ved vurderingen av når HMP2 realistisk sett kunne vært nådd.

Lagmannsretten legger til grunn forklaringen fra IBMs Tonje Offenberg Bye om at de interne og eksterne generiske grensesnittene innebar at DCUT-arbeidet for de berørte enkle grensesnittene ikke lenger var nødvendig. «Work tracking»-filen per 5. mars 2015 viser at det var fire av seks grensesnitt under #303 («#208») som var estimert (052, 217, 218 og 219), og at disse fire hadde PV på 283 DCUT-timer. (FU bilag 1596) Tracking-filen per 4. juni 2015 viser at disse 283 timene var tatt ut av totalt gjenstående arbeid 19. mai 2015. (FU bilag 1610) De fire grensesnittene under #173 hadde PV på 336 DCUT-timer. (FU 25790 på 25821 og FU bilag 1596) Tracking-filen per 4. juni 2015 viser at grensesnittene under #301 og #302 hadde PV på 887 DCUT-timer. De generiske grensesnittene hadde således potensiale til å gjøre arbeid med PV på så mye som rundt 1 500 DCUTtimer i INT-strømmen, overflødig. Det er uenighet om hvor mange enkle grensesnitt som alt i alt skulle utvikles og hvor mange av disse som var ferdigstilt på tidspunktet for hevingen. Ifølge staten var det 100 grensesnitt som skulle utvikles, hvorav 18 til 33 var 100 prosent ferdigstilt.

Ifølge IBM var det 87 grensesnitt som skulle utvikles, hvorav 50 var 100 prosent ferdigstilt. Partene har illustrert sine synspunkter ved hjelp av hjelpedokumenter. Partene ser ut til å være uenige om antallet grensesnitt som er «out of scope» («OOS») og ferdigstillelsesgrad.

Saken er svakt opplyst på dette punktet. Lagmannsretten ser ingen grunn til å fravike statens oppfatning om at det var 100 grensesnitt. Basert på at det ble testet 38 grensesnitt til KP2, jf. Appendix A til rapporten 20. april 2015, ser lagmannsretten det imidlertid som mest sannsynlig at antallet ferdige grensesnitt var høyere enn 38. Lagmannsretten mener imidlertid at det ikke er andelen gjenstående grensesnitt, men kompleksiteten av det gjenstående arbeidet med dem, som er av betydning for når de kunne blitt ferdig. Kompleksiteten av det gjenstående arbeidet er ikke kjent. Lagmannsretten ser samtidig ingen holdepunkter for at noen av dem var av en slik karakter at IBM ikke ville klart dem innen september 2015. For lagmannsretten ser det ut til at alle grensesnittene var påstartet og at det var tilfredsstillende fremdrift i INT-strømmen. Sett på bakgrunn av at mye av integrasjonsarbeidet ofte gjøres ferdig til slutt, og at det var satt i verk tiltak som ville ha økt fremdriften i INT-strømmen, mener lagmannsretten at andelen ferdigstilte grensesnitt ikke taler mot at denne strømmen kunne ha blitt ferdig innen september 2015.

Slik lagmannsretten ser det, kan det etter dette ikke utelukkes at INT-strømmen kunne ha blitt ferdig før 1. desember 2015 slik Holte har gjort. Holte har ikke tatt hensyn til at SAP-strømmen ble oppbemannet slik at den kunne ha blitt ferdig innen september 2015. Holte har heller ikke tatt hensyn til at INT-strømmen ble oppbemannet, og at det var satt i gang arbeid med generiske grensesnitt. At alt DCUT-arbeidet i iterasjon 3 da kunne ha vært gjort ferdig innen september 2015, har slik lagmannsretten ser det, også støtte i en enkel «widget unit»-beregning. Per 29. april 2015 var det fullført 528 widgets, mens det per 10. juni 2015 var fullført 787. (FU 23249 på 23251 og FU 24689 på 24691) Det var med andre ord fullført 259 widgets på rundt en og en halv måned. Videre gjensto det 498 widgets per 10. juni 2015. Med fremdriften i perioden 29. april til 10. juni 2015, ville det vært fullt mulig å bli ferdig på tre måneder. 4.5.2.4 Iterasjonstesten av iterasjon 3 og SIT Slik lagmannsretten ser det, kunne iterasjonstesten av iterasjon 3 og SIT realistisk sett ha vært gjennomført på til sammen 87 (38 + 49) dager.

Ved vurderingen av hvor lang tid iterasjonstesten av iterasjon 3 realistisk sett kunne ha tatt, legger lagmannsretten liten vekt på vurderingene til Holte Consulting og Leif-Arne Rones på henholdsvis tre måneder og 38 dager. Verken Holte eller Rones har sett på testrapportene og hva som kunne utledes av dem. Lagmannsretten legger større vekt på at testingen av iterasjon 2 hadde tatt fire måneder, det vil si over tre ganger så lang tid som 38 dager, og at det skulle testes et større volum for iterasjon 3. Som nevnt la IBM også opp til en mer kompleks testing av iterasjon 3. IBM skulle begynne å teste ikke-funksjonelle krav og bruke mer realistiske testdata. All «ende til ende»-testing av interne grensesnitt testing skulle skje i iterasjonstesten av iterasjon 3. Disse forholdene taler mot at iterasjonstesten av iterasjon 3 kunne blitt gjennomført på 38 dager. På den andre siden hadde feilretting tatt mye tid ved testingen av iterasjon 2. Fra 23. februar til 11. juni 2015 ble feilraten redusert fra ca. 15 til ca. 10 prosent.

(FU 18956 på 18963 og FU 19007 på 19010) Den reduserte feilraten taler for at mulige feil ved kildekoden for en stor del var blitt løst, og at det ville gått med langt mindre tid til feilretting ved testingen av iterasjon 3. Som nevnt under behandlingen av KP2-underkjenningen, økte dessuten testproduktiviteten etter at Sally Drew kom inn som ny testleder fra slutten av februar 2015. I siste halvdel av mars 2015 var produktiviteten likevel bare på noe over to test caser per ressurs per dag. Sally Drew har forklart at det blant annet var et problem at GD India vegret seg mot å gi dårlige nyheter og at de derfor testet fem ganger heller enn én. Ifølge Drew måtte produktiviteten ha kommet opp i bransjestandarden Capers Jones på åtte test caser per ressurs per dag for å kunne gjort ferdig testingen av iterasjon 3 på 38 dager. Hun mente at dette ville ha latt seg gjøre siden flesteparten av testene for iterasjon 3, ville ha vært repetisjoner av tester for iterasjon 2. Hun pekte i tillegg på at antall testere kunne ha vært økt fra de 17 som var tilgjengelig i juni 2015.

Selv om det aldri ble planlagt med helge- og overtidsarbeid, kunne også dette ha vært gjort. Lagmannsretten deler Sally Drews syn på at repetisjonene fra testingen av iterasjon 2, ville økt testproduktiviteten. Videre kunne ressurser fra fullførte strømmer vært omdisponert til testing. Lagmannsretten deler også synet på at det lå forseringsmuligheter i overtids- og helgejobbing. Testing kunne også delvis skjedd i overlapp med utviklingen av iterasjon 3. Lagmannsretten ser etter dette 38 dager til iterasjonstestingen som realistisk.

Ved vurderingen av hvor lang tid SIT realistisk sett kunne tatt, legger lagmannsretten til grunn at SIT skulle omfatte all «ende til ende»-testing av eksterne grensesnitt. Holte Consultings vurdering var at SIT optimistisk sett kunne tatt 49 dager, forutsatte at denne «ende til ende»testingen var gjort i forkant. Leif-Arne Rones vurderte 12 uker/tre måneder til «SIT/Perform SIT Test» som «svært optimistisk» basert på den udokumenterte 1:2:2-regelen og «erfaring fra andre systemintegrasjonsprosjekter». Siden det ikke var gjort «ende til ende»-testing av eksterne grensesnitt i forkant, vurderte Rones at «SIT/Migration Testing» optimistisk sett ville tatt 16 uker. (TU2 2825 på 2857, 2858 og 2861) Rones ser ikke ut til å ha tatt høyde for en økning i testressurser. Sally Drew har på spørsmål knyttet til den såkalte 1:2:2-regelen, forklart at antall DCUT-timer ikke er et gyldig utgangspunkt for vurderingen av antall dager til SIT. Hennes metode var å gjøre et overslag over størrelsen på SIT i form av test scenarier. Et test scenario er en kjede av test caser.

Det tar lengre tid å kjøre ett test scenario enn en test case, men antallet test scenarier er lavere enn antall test caser. For eksempel vil 200 test scenarier kunne bestå av 4 000 test caser. Selv om IBM aldri kom i gang med planleggingen av SIT, så Drew det som overkommelig for 17 ressurser, som kunne økes til 30 etter hvert som utviklingen ble ferdig, å gjøre ferdig SIT på 49 dager. Hun mente at testingen av eksterne grensesnitt generelt var uproblematisk, og at SIT kunne ha vært gjennomført på mindre enn 49 dager. Lagmannsretten deler Drews syn på at DCUT-timer ikke er noe godt utgangspunkt for vurderingen av antall dager til SIT og at «ende til ende»-testing av eksterne grensesnitt som oftest er uproblematisk. Lengden på SIT avhenger først og fremst av forretningsprosessene. Hvis for eksempel fakturering skjer månedlig, vil ikke SIT kunne gjennomføres på kortere tid enn en måned. Det er ikke trukket frem forretningsprosesser i løsningen som ikke lot seg teste innenfor en periode på en måned. «Ende til ende»-testing av eksterne grensesnitt er uproblematisk så lenge grensesnittene er laget for integrasjoner.

Integrasjoner vil ligge ferdig i SAP FI-CA eller følge av en fast kravspesifikasjon med et standardisert testløp i forhold til eksempelvis tredjepartgrensesnitt opp mot banker. Det kan oppstå behov for flere runder med test for integrasjoner som ikke har vært gjort tidligere. På den andre siden inneholder API (Application Programming Interface) standard datautvekslingsformater som letter «ende til ende»-testingen av de eksterne grensesnittene. For øvrig tok verken Holte Consulting eller Leif-Arne Rones høyde for at INTstrømmen kunne vært ferdig innen september 2015. Som nevnt vurderte Rones denne strømmen for svært viktig for «ende til ende»-testing. Lagmannsretten deler også Drews syn på at SIT lett kunne ha blitt tilført ressurser. SIT gjøres ferdig etter utviklingen. På tidspunktet for SIT, kunne ressurser ha blitt omdisponert fra utviklingen til testing. Med den planlagte økningen i ressurser på opptil 30, ser lagmannsretten 49 dager på SIT som realistisk. Siden funksjonaliteten var på plass og integrasjonen var i gang, mener lagmannsretten endelig at SIT kunne ha vært kjørt i delvis overlapp med iterasjonstesten av iterasjon 3.

Som A-2 var inne på i rapporten om kravsporing 24. februar 2015, kunne verktøypakken CLM også bidratt positivt under SIT. (FU 20627 på 20636) At SIT kunne ha vært kjørt i delvis overlapp med iterasjonstesten, tilsier at det kunne latt seg gjøre å gjennomføre testingen på 87 dager.

4.6 Konklusjon – antesipert vesentlig forsinkelse Etter lagmannsrettens vurdering kunne det realistisk sett latt seg gjøre for IBM å ferdigstille alt DCUT-arbeidet innen september 2015 og gjennomføre integrasjonstesten og SIT på til sammen 87 dager. HMP2 og HMP2.2 kunne da alt i alt ha vært nådd henholdsvis 26. desember 2015 og 3. mai 2016. Dette er før hevingsfristen, jf. punkt 4.4.11 foran. SVV hadde ikke grunnlag for å heve på grunn av antesipert vesentlig forsinkelse. Siden lagmannsretten er kommet til at det verken forelå inntrådt vesentlig mislighold eller antesipert vesentlig forsinkelse på hevingstidspunktet, var SVVs heving av Leveranseavtalen urettmessig. SVV hevet ikke bare Leveranseavtalen 27. juli 2015, men også «alle de øvrige inngåtte avtaler om drift, vedlikehold og videreutvikling av AutoPASS Grindgut». (FU 26028 på 260343). Leveranseavtalen var tett tilknyttet avtalene om drift, vedlikehold og videreutvikling. Hevingen av de øvrige avtalen var således også urettmessig.

Det er etter dette ikke nødvendig å vurdere IBMs anførsel om at hevingen var urettmessig på grunn av vikarierende motiver. Det er heller ikke nødvendig å gå inn på erstatningskravet som staten har fremsatt. Statens anke skal etter dette forkastes.

5 Vederlag

5.1 Innledning Lagmannsretten har konkludert med at SVVs heving av Leveranseavtalen var urettmessig. IBM hadde derfor rett til å heve Leveransekontrakten og tilhørende avtaler, jf. Generelle kontraktsbestemmelser punkt 6.2.2, jf. 6.4.2. Heving av Leveranseavtalen gir IBM krav på betaling for «den delen av Leveransen som er utført», jf. Generelle kontraktsbestemmelser punkt 6.4.2.2 første avsnitt tredje setning. I tillegg har IBM rett til å kreve erstatning, jf. Generelle kontraktsbestemmelser punkt 6.4.2, jf. 6.4.1. IBM har også krevd avbestillingskompensasjon i medhold av avtalene om vedlikehold og drift. Staten har prinsipalt gjort gjeldende at IBM ikke hadde utarbeidet noe av verdi for SVV på hevingstidspunktet, at «IBMs mislighold var forsettlig eller grovt uaktsomt» og at SVV da kunne heve med tilbakevirkende kraft. Staten har subsidiært, for det tilfellet at SVVs heving var rettmessig, gjort gjeldende at IBM bare kan kreve vederlag for den den delen av løsningen som var godkjent i et kontrollpunkt.

Lagmannsretten oppfatter staten slik at både den prinsipale og subsidiære anførselen gjelder for det tilfellet at SVVs heving var rettmessig. Staten har atter subsidiært, for det tilfellet at SVVs heving var urettmessig, gjort gjeldende at IBM bare kan kreve vederlag for den delen av løsningen som var utviklet på hevingstidspunktet. Videre har staten bestridt at IBM har krav på betaling for programvaren som er beskrevet i kontrakten. Kontraktens målprismekanisme må dessuten forstås slik at den ga IBM krav på maksimalt 115 prosent av målpristaket dersom kontrakten hadde blitt gjennomført. IBM har heller ikke krav på avbestillingsvederlag. Kontrakten ble avsluttet ved IBMs etterfølgende heving. Generelle kontraktsbestemmelser punkt 6.4.1 gir leverandøren i slike tilfeller rett til å kreve erstatning, men IBM har ikke lidt noe tap. Lagmannsretten har kommet til at IBM har krav på vederlag under Leveranseavtalen og Finansieringsavtalen på til sammen 172 115 094 kroner, og erstatning/ avbestillingskompensasjon under Leveranseavtalen på til sammen 2 565 045 kroner.

Lagmannsretten mener at avtalene om vedlikehold og drift ikke gir IBM krav på avbestillingskompensasjon ved SVVs urettmessige heving. Dette begrunnes nærmere nedenfor.

5.2 Kort om vederlagsmekanismen i Leveranseavtalen Leveransens vederlagsmekanisme er regulert i Generelle kontraktsbestemmelser punkt 4, jf. Bilag D. (FU 8458 på 8472) Vederlaget består av tre elementer: et fastpriselement, et målpriselement og et tillegg for henholdsvis godkjenningsprøven og garantiperioden. Det er bare fastpriselementet og målprisen som er relevant for lagmannsrettens beregning av vederlaget. Fastpriselementet omfatter elementer som er uavhengig av omfanget av leverandørens arbeid, for eksempel maskin- og programvare som inngår i leveransen, jf. Generelle kontraktsbestemmelser punkt 4.1 bokstav a. (FU 8472) Fastpriselementet i Leveranseavtalen besto utelukkende av programvare og lisenser, jf. Bilag D punkt 2.1. (FU 9271 på 9274) På tidspunktet for kontraktsinngåelsen var dette elementet priset til 30 869 893 kroner. (FU 9275) Ved EO048 ble fastpriselementet økt med 2 770 750 kroner. (FU 10089 og 10090) Målpriselementet er lik summen av IBMs kostnadsestimat for timebasert arbeid i løsningsbeskrivelsesfasen og konstruksjonsfasen, og et usikkerhetspåslag på åtte prosent, jf.

Generelle kontraktsbestemmelser punkt 4.1 bokstav b og Bilag D punkt 2.1 (FU 8472). Ved kontraktsinngåelsen var målprisen fastsatt til 49 355 341 kroner. (FU 9275) Som følge av endringsordrer økte målprisen til 58 451 095 kroner ved slutten av løsningsbeskrivelsesfasen, og til 58 815 591 kroner i løpet av konstruksjonsfasen.

Partene er enige om at målprisen var 58 815 591 kroner på hevingstidspunktet. Lagmannsretten behandler først IBMs krav på betaling for programvare i fastpriselementet i punkt 5.3. IBMs krav på betaling for utført arbeid (målpriselementet), behandles i punkt 5.4 flg. IBMs vederlagskrav er oppsummert i punkt 5.10. IBMs krav på avbestillingskompensasjon behandles i punkt 5.11. IBMs krav på renter behandles i punkt 5.12.

5.3 Betaling for programvare Staten har bestridt at IBM har krav på betaling for programvaren som er beskrevet i Bilag D. Slik lagmannsretten ser det følger IBMs krav på betaling for programvare direkte av Generelle kontraktsbestemmelser punkt 6.4.2.2 første avsnitt. Leverandøren har krav på betaling for den delen av Leveransen som er utført. Det ligger i dette at leverandøren som utgangspunkt skal få betalt for alt som er levert. IBMs krav på betaling for programvare, gjelder også standard programvare i Bilag F. Punkt 6.4.2.2 andre avsnitt lyder: Dersom Leveransen omfatter utstyr og/eller Komponenter som i Bilag F er definert som standard programvare, kan Leverandøren alternativt kreve at Kunden leverer dette tilbake mot å betale tilbake det vederlag som er betalt for slikt utstyr og Komponenter. Ordet «alternativt» viser tilbake til utgangspunktet i første avsnitt. Det vil si at leverandøren, i stedet for å kreve full betaling for alt som er levert, kan kreve tilbake standard programvare i Bilag F, mot å betale tilbake det vederlaget som kunden har betalt for dette.

Løsningen er et unntak fra punkt 6.4.2.2 første avsnitt første setning om at kontrakten i utgangspunktet bare kan heves for den gjenstående del av Leveransen (ex nunc). I Veilederen til PS2000 er bakgrunnen for at kontrakten i utgangspunktet bare kan heves med virkning ex nunc, beskrevet slik i punkt 8.5, side 35: Virkningen av heving gjelder i utgangspunktet bare fra hevingstidspunktet, ref. Del II punkt 6.4.2.1 og 6.4.2.2. Det innebærer at den som hever ikke kan kreve tilbake det han har ytet mot å gi tilbake det han har fått (restitusjon). Grunnen til det er at en restitusjon av tjenester ikke er mulig og at en restitusjonsplikt i realiteten bare ville bli en belastning for leverandøren og i verste fall en meget tung byrde. Derimot vil en restitusjon både være naturlig og mulig når kontrakten også omfatter utstyr og standard programvare. PS2000-kontraktsstandarden åpner derfor for at den hevende part som et alternativ kan kreve restitusjon av disse ytelsene. Retten til å kreve restitusjon av programvare er i punkt 6.4.2.2 forbeholdt leverandøren.

Kunden kan ikke ved leverandørens rettmessige heving kreve at leverandøren tar tilbake programvare og erstatte det vederlaget som er betalt for programvaren. En slik rett for kunden gjelder bare ved kundens rettmessige heving, jf. punkt 6.4.2.1 andre avsnitt. IBM har ikke bedt om tilbakelevering av programvare. SVV er derfor forpliktet til å betale. Den avtalte programvaren fremgår som nevnt av Bilag D punkt 2.1 og var på tidspunktet for kontraktsinngåelsen prissatt til 30 869 893 kroner. (FU 9274) Ved EO048 opprettet av SVV ved Arve Ryan 12. mars 2015 ble overvåkings- og skjermingsverktøyene Guardium og Qradar tatt inn i Leveransen. (FU 10089) Det fremgår av EO048 at endringen økte fastpriselementet i Leveranseavtalen Bilag D med 2 770 750 kroner, hvorav 2 454 750 kroner for Guardium og 316 000 kroner for Qradar. Guardium ble installert hos Basefarm 3. juni 2015, og vederlaget for Guardium skal derfor betales. (FU 24436) Det er imidlertid ikke ført bevis for at Qradar var anskaffet før hevingstidspunktet, og levering av Qradar anses derfor ikke som «utført». Vederlaget for Qradar skal derfor ikke betales.

(FU 10090) Lagmannsretten mener etter dette at SVV er pliktig å betale 33 324 643 kroner for programvare.

5.4 IBMs krav på betaling for utført arbeid Generelle kontraktsbestemmelser 6.4.2.2 gir som nevnt leverandøren som rettmessig hever kontrakten, krav på betaling for «den delen av Leveransen som er utført». Staten har gjort gjeldende at IBMs krav på vederlag må begrenses til den andelen av løsningen som var utviklet på hevingstidspunktet. IBM har gjort gjeldende at det ikke kan innfortolkes en slik begrensning i punkt 6.4.2.2, og at selskapet har krav på vederlag for den utførte delen av leveransen målt etter timeforbruket opp til målpristaket. Lagmannsretten mener at det ikke er holdepunkter for det synet staten har gjort gjeldende. Kontraktens ordlyd er klar. Verken punkt 6.4.2.2 eller Generelle kontraktsbestemmelser for øvrig tilsier at bestemmelsen skal tolkes innskrenkende eller at det skal innfortolkes en slik begrensning som staten hevder. Det er heller ikke holdepunkter for statens syn i Veilederen til PS2000 eller juridisk litteratur. En harmonisert tolking av kontraktens ulike bestemmelser om leverandørens krav på vederlag ved avbrudd, taler også imot statens syn.

Kontraktens bestemmelser om leverandørens krav på vederlag ved avbrudd, er grunnleggende like. Generelle kontraktsbestemmelser punkt 6.4.2.1 gir leverandøren ved kundens rettmessige heving, krav på vederlag for «de deler av Leveransen som er dokumentert utført, men ikke betalt». Punkt 6.4.2.2 gir leverandøren ved egen rettmessige heving som nevnt krav på betaling for «den delen av Leveransen som er utført». Punkt 7.3 gir leverandøren ved kundens avbestilling, krav på «ikke betalt, men opptjent vederlag for de deler av Leveransen som er dokumentert utført».

(FU 8480) Om bestemmelsen i punkt 7.3 heter det i Veilederen til PS2000, punkt 5.3.2 side 21: Dersom kunden avbestiller leveransen etter løsningsbeskrivelsesfasen, har leverandøren krav på å få dekket kostnader i henhold til timeforbruk, begrenset til en nærmere angitt øvre ramme, samt eventuelle tilleggskostnader som leverandøren har pådratt seg. [...] Slik lagmannsretten ser det, tilsier den grunnleggende likheten mellom kontraktens avbruddsregler og hensynet til en harmonisert tolking, at punkt 6.4.2.2 og 6.4.2.1 – i hvert fall i mangel av klare holdepunkter for noe annet – må tolkes på samme måte. Både hensynet til forutberegnelighet og oppgjørstekniske hensyn taler også imot statens syn. Standpunktet ville få den uheldige konsekvensen at den gjenværende delen av utviklingsarbeidet ville måtte estimeres. Dette ville være tidkrevende og konfliktdrivende, og ville nødvendigvis måtte bero på et skjønn. Vederlag basert på timeforbruk opp til målpristaket, gir både forutberegnelighet og er oppgjørsteknisk enkelt.

Lagmannsretten mener etter dette at IBM har krav på vederlag for alt utført arbeid opp til målpristaket, og at kravet ikke er begrenset til den andelen av løsningen som var utviklet på hevingstidspunktet.

5.5 Beregning av målprisen Partene er som nevnt innledningsvis enige om at målprisen på hevingstidspunktet, når godkjente endringsordrer fra løsningsbeskrivelsesfasen og konstruksjonsfasen er hensyntatt, utgjorde 58 815 591 kroner. Ved beregningen av IBMs vederlagskrav, må dette beløpet justeres for kompensasjonen for endringer som IBM har fått medhold i. For arbeidet i EA053 CRM-økt kompleksitet, har IBM i utgangspunktet krevd 16 329 640 kroner. Da bare 78 prosent av arbeidet var utført på hevingstidspunktet, har IBM krevd økning av målpris med 12 737 119 kroner. Lagmannsretten har i punkt 4.4.4 gitt IBM medhold i at 90 prosent av kravet var berettiget. Målprisen skal derfor økes med 90 prosent av 12 737 119 kroner, dvs. med 11 463 407 kroner, for EA053. I EA054 CRM Arbeidsform og prosess for utarbeidelse av Use-Case, krevde IBM en økning av målprisen med 582 timer og 818 241 kroner, og en fristforlengelse på 42 kalenderdager. Lagmannsretten har i punkt 4.4.5 gitt IBM medhold i krav om fristforlengelse med 14 kalenderdager, tilsvarende 33,3 prosent av kravet.

Målprisen skal derfor økes med 33,3 prosent av 818 241 kroner, dvs. med 272 474 kroner, for EA054. I EA067 Greenbird krevde IBM en fristforlengelse på to kalenderdager og en økning av målprisen med 277 465 kroner. Lagmannsretten har i punkt 4.4.6 gitt IBM medhold i at kravet i EA067 var rettmessig. Målprisen skal derfor økes med 277 465 kroner for EA067. I EA117 Gjennomføring av iterasjon 2 og nytt kontrollpunkt, krevde IBM en fristforlengelse på 113 dager og en økning av målprisen med 27 823 timer og 16 527 085 kroner. IBM har gjort gjeldende at 44 prosent av

merarbeidet i EA117 var utført på hevingstidspunktet og har krevd 7 271 917 kroner for dette merarbeidet. Lagmannsretten har i punkt 4.4.9 gitt IBM medhold i en fristforlengelse på 60 kalenderdager for EA117, tilsvarende 53 prosent av kravet. Målprisen skal derfor økes med 53 prosent av 7 271 917 kroner, dvs. med 3 854 116 kroner, for EA117. Lagmannsretten har etter dette kommet til at målprisen skal økes med til sammen 15 867 462 kroner for endringer som IBM har fått medhold i. Til dette må det legges til et usikkerhetspåslag på 8 prosent, tilsvarende 1 269 397 kroner. Den oppdaterte målprisen etter at endringer som IBM har fått medhold i er hensyntatt, utgjør etter dette 75 952 450 kroner.

5.6 Målpristaket Målprisen var utgangspunktet for en incentiv- og sanksjonsordning i Bilag D punkt 2.3, hvor overskridelser og underskridelser ble fordelt mellom kontraktspartene etter en avtalt fordelingsnøkkel innenfor et tak i forhold til målprisen – målpristaket. Partene er enige om at IBM hadde nådd målpristaket ved KP2 i april 2015. Selskapet rapporterte i månedsrapport for juni 2015 et virkelig (faktisk) forbruk på 157 562 609 kroner. (FU 25442) Målpristaket danner derfor det maksimale vederlaget for timebasert arbeid som IBM har krav på. Partene er imidlertid uenige om hvordan Bilag D punkt 2.3 skal forstås og således om hvordan målpristaket skal beregnes. Bilag D punkt 2.3 lyder: Følgende incentiv- og sanksjonsordning, slik det er definert i Generelle kontraktsbestemmelser, skal gjelde som fordelingsnøkkel for differansen mellom virkelig kostnad og fastsatt Målpris: Fordelingsnøkkel ved underskridelse av Målpris Nedre tak for avvik mellom virkelig Prosent av (incentiv) kostnad og Målpris avvik Tilleggsvederlag gjeldende for avvik i forhold til Målpris, inntil nedre tak

50%

Tilleggsvederlag for avvik utover det nedre tak

70%

Fordelingsnøkkel ved overskridelse av Målpris (sanksjon)

Øvre tak for avvik mellom virkelig Prosent av kostnad og Målpris avvik

Reduksjon i vederlag, gjeldende for avvik i forhold til Målpris, inntil øvre tak Reduksjon i vederlag for avvik utover det øvre tak

100 %

50% 130%

100 %

I modellen ligger at Leverandør for arbeid ut over 130 % av målpris vil motta et vederlag tilsvarende 130 % av målpris. Tilsvarende for arbeid under 70 % av målpris vil leverandøren motta et vederlag tilsvarende 70 % av målpris. Virkelig kostnad skal baseres på godkjent timeforbruk og reell gjennomsnittlig timerate. Fastsatt Målpris er basert på estimat og forhåndsberegnet gjennomsnittlig timerate, ref. punkt 2.1. Teksten i første avsnitt under tabellen var inntatt i konkurransegrunnlaget da konkurransen ble utlyst i januar 2013. (FU 3879) IBM ønsket å fjerne tak og bunn i målprismodellen, og slettet teksten og tallene i tabellene i sitt tilbud 18. februar 2014. (FU 4752 og 6153) SVV tok teksten og tallene inn i konkurransegrunnlaget igjen etter gjennomført første forhandlingsrunde, jf. brev 7. mai 2013 fra SVV til IBM vedlagt utkast til Bilag D versjon 2.1. (FU 5469 og FU 5471 på 5475)

Partene er uenige om bestemmelsen skal forstås slik at det maksimale vederlaget for timebasert arbeid (målpristaket) er 115 prosent eller 130 prosent av målprisen. Staten har gjort gjeldende at det går klart frem av de to tabellene i Bilag D punkt 2.3 at IBM ved overskridelse av målprisen kun har krav på 50 prosent av vederlaget mellom 100 og 130 prosent av målprisen og at timeforbruk utover 130 prosent av målprisen ikke godtgjøres. Det maksimale vederlaget er således 115 prosent av målprisen. Det er motstrid mellom tabellene og teksten under tabellene, men teksten under tabellene gir ikke mening. Incentivene og sanksjonene blir borte hvis leverandøren får fullt betalt mellom målpris og 130 prosent av målprisen og kunden får 100 prosent av besparelsen mellom målpris og 70 prosent av målpris, slik det står i teksten. IBM-interne dokumenter viser at IBM forsto SVVs intensjon med målprismekanismen. IBM kan ikke påberope seg en motstrid i kontraktsteksten når det hele tiden har vært klart for IBM hva SVVs intensjon var. IBM har gjort gjeldende at ordlyden i teksten under tabellene er klar.

Den må forstås slik at arbeid til og med 130 prosent av målprisen godtgjøres som vanlig, og at sanksjonen er full avkortning av vederlag for arbeid utover 130 prosent. Det maksimale vederlaget er således 130 prosent av målprisen. Det bestrides at kontraktspartene hadde en felles forståelse av målprismekanismen. Uansett må uklarheten mellom tabellen og den etterfølgende tekst gå utover SVV som forfattet både endringer i modellen og den forklarende teksten, så lenge det ut fra en objektiv betraktning ikke fremstår som klart hva SVV mente. Staten har vist til IBM-interne dokumenter til støtte for sitt syn om at kontraktspartene hadde en felles forståelse av SVVs intensjon med målprismekanismen. Et av disse dokumentene er fra før kontraktsinngåelsen og er en grafisk fremstilling av målprisen som synes å vise at overskridelser av målprisen skal deles 50:50 opp til 130 prosent av målprisen, jf. presentasjon til IBMs Deal Board 5. august 2013.

(TU2 899 på 903) Lagmannsretten mener imidlertid at det er vanskelig å trekke klare konklusjoner fra presentasjonen, særlig sett i lys av at IBM-interne dokumenter fra etter kontraktsinngåelse viser at det var ulike oppfatninger av hvordan målpristaket skulle forstås. I en Project Management Review 22. august 2014 står det at «loss will be shared 50% upto 30%, beyond 30%, IBM will be at complete loss». (FU14931) I en IBM-intern presentasjon 8. mai 2015 står det derimot at «Work>130% of the TP IBM will receive payment=130% of the TP». (FU23598 på 23615) I mangel av klare holdepunkter for en felles forståelse, må Bilag D punkt 2.3 tolkes objektivt. Dette er det klare utgangspunktet i kontrakter inngått mellom næringsdrivende, jf. blant annet Rt-2002-1155, Rt-2010-961 avsnitt 44 og Rt-2010-1345 (Oslo Vei) avsnitt 59. Prinsippet om objektiv tolking står særlig sentralt i entreprisekontrakter inngått etter anbud. Høyesterett har i Rt-2012-1729 (Mika) avsnitt 58 uttalt: Ved anbud, der kontraktsgrunnlaget er utarbeidet av den ene parten alene, er det krav om like konkurransevilkår for tilbyderne.

Prinsippet om en objektiv fortolkning av avtaler mellom næringsdrivende får derfor en særlig styrke i entrepriseforhold. Tolking av entreprisekontrakt som er inngått etter anbud har vært tema i flere saker i Høyesterett. En sentral dom er inntatt i Rt-2007-1489 (Byggholt). Her understreket Høyesterett anbudsinnbyderens ansvar for at konkurransegrunnlaget er klart. I avsnitt 62 heter det: Det vil på denne bakgrunn være av vesentlig betydning at anbudsgrunnlaget som legges fram for anbyderne, er grundig gjennomarbeidet med sikte på å få fram en klar og presis prosjektbeskrivelse. Det samme gjelder for de enkelte utgiftsposter som forutsettes priset. [...] Det sier seg selv at det vil være byggherren som ved utformingen av anbudsgrunnlaget vil måtte bære ansvaret for at en slik målsetting blir oppnådd. Videre i avsnitt 75: Som jeg tidligere har påpekt, er det anbudsinnbyderens ansvar å sørge for et klart og entydig anbudsgrunnlag. Jeg finner det da ikke riktig å pålegge anbyderen risikoen for uklarheten med mindre det ut fra en objektiv betraktning framstår som klart hva anbudsinnbyderen har ment.

Det sentrale synspunktet i Byggholt-dommen, slik lagmannsrettens ser det, er at dersom konkurransegrunnlaget er uklart, så må det tolkes objektivt. Dersom det etter en slik objektiv tolking er «klart» kva byggherren har meint, må dette tolkingsalternativet legges til grunn. Dersom det derimot er uklart hva byggherren har ment, må det tolkingsalternativet som er i favør av tilbyderen legges til grunn.

Synspunktet i Byggholt-dommen er fulgt opp av Høyesterett i Rt-2012-1729 (Mika). Etter å ha uttalt at prinsippet om en objektiv fortolkning av avtaler mellom næringsdrivende får en særlig styrke i entrepriseforhold, jf. over, fortsetter Høyesterett i avsnitt 58: For at tilbyderne skal kunne konkurrere på like vilkår, må anbudsgrunnlaget – som danner basis for den senere kontrakten – være klart formulert. Uklarhet må i utgangspunktet gå ut over anbudsinnbyderen, som ensidig utformet det grunnlaget tilbyderen må forholde seg til. Er det – til tross for enkelte uklare punkter – etter en objektiv fortolkning likevel klart hva som er ment, må tilbyderen holde seg til dette. Siste setning er utdypet i avsnitt 102: Selv om det gjelder et krav til klarhet i utformingen av konkurransegrunnlaget, kan ikke dette strekkes så langt at tilbyder ved enhver mulig uklarhet uten videre kan legge til grunn den forståelsen som er vedkommendes interesse, når det framstår som klart hva anbudsinnbyderen har ment. En slik adgang ville kunne åpne for en uheldig jakt på uklare formuleringer og spekulasjoner i tekstutformingen.

I avsnitt 67 fremhever Høyesterett at det «vil kunne være nødvendig å se samtlige kontraktsdokumenter i sammenheng» når innholdet i konkurransegrunnlaget skal fastlegges, og i avsnitt 69 at det avgjørende er hvordan en «normalt forstandig tilbyder» oppfatter de beskrivelser som er gitt i kontraktsdokumentene. Høyesterett har i Rt-2010-961 også uttalt: Spørsmålet om hvordan kontraktsforholdet mellom partene skal forstås, må da avgjøres ut fra en objektiv fortolkning av bestemmelsene. Det at bestemmelsene må tolkes objektivt, innebærer imidlertid ikke at de utelukkende skal tolkes ut fra hva en naturlig språklig forståelse av bestemmelsen tilsier. Bestemmelsens ordlyd må blant annet leses i lys av de formål de skal ivareta, og andre reelle hensyn. Høyesterett har sist i HR-2019-830-A sluttet seg til den rettspraksisen som her er gjennomgått. Slik lagmannsretten ser det, er det etter en objektiv tolking ikke klart og entydig hvordan målpristaket i Bilag D punkt 2.3 skal forstås.

Tabellene trekker i retning av at målpristaket er 115 prosent av målprisen, slik staten har gjort gjeldende, mens teksten under tabellene er utvetydig på at målpristaket er 130 prosent av målprisen. Det er motstrid mellom alternativene, og de kan ikke harmoniseres. Lagmannsretten mener videre at begge tolkinger er resonnable for en normalt forstandig tilbyder. Selv om leverandørens incentiv til å jobbe for at endelig vederlag blir under målprisen, er svakere i løsningen som er beskrevet i teksten enn i løsningen som går frem av tabellen, er den likefult en mulig alternativ incentiv- og sanksjonsmodell i en entreprisekontrakt. Lagmannsretten er ikke enig med staten i at teksten under tabellen ikke gir mening, isolert sett. Under disse omstendighetene, mener lagmannsretten at uklarheten i punkt 2.3 må gå utover SVV. Lagmannsretten legger etter dette til grunn at målpristaket er 130 prosent av målprisen. Lagmannsretten har i punkt 5.5 kommet til at den oppdaterte målprisen etter at endringer som IBM har fått medhold i er hensyntatt, utgjør 75 952 450 kroner. Målpristaket utgjør 130 prosent av dette beløpet, dvs. 98 738 185 kroner.

Partene er som nevnt enige om at målpristaket er passert. IBM har derfor krav på 98 738 185 kroner i vederlag for utført arbeid.

5.7 Endringer som ikke inngår i målprisen 5.7.1 Innledning I tillegg til endringsanmodninger som har konsekvenser både på tid og målprisen og som er behandlet i punkt 5.5, omfatter saken en endringsordre og en endringsanmodning som bare har konsekvenser for vederlagskravet. Disse er beregnet som «tid og materiell», og har ikke betydning for målprisen.

5.7.2 EO064 – Preventive aksjoner grunnet EA078 EO064 gjaldt preventive aksjoner grunnet EA078. (FU 24760) Lagmannsretten har drøftet EO064 i punkt 4.4.7.2 i forbindelse med behandlingen av Kina-saken, og konkluderte der med at SVVs tilbakehold av signeringen av EO064, var urettmessig. Det går frem av endringsordren at de kostnadsmessige konsekvensene

av EO064 var 491 428 kroner. Staten har erkjent kravet under ankeforhandlingen. IBM har derfor krav på 491 428 kroner eks. mva. i vederlag for EO064.

5.7.3 EA069 – PRO Planarbeid EA069 gjaldt PRO Planarbeid, og ble opprettet av IBM ved Nicolai Rygh 9. mars 2015. (FU 21068) Bakgrunnen for endringsanmodningen var at SVV hadde «krevd deltagelse fra Leverandøren utover det Leverandøren får dekket under kontrakten. Leverandører ble bedt om [å] utføre arbeid for å få på plass planverk som ligger på Kunden». IBM brukte Lorentz Lorentzen til å utføre arbeidet, og krevde 149 573 kroner for påløpt arbeid, og at videre bistand måte endringshåndteres. Det er ukjent for lagmannsretten når SVV avviste EA069, men den ble eskalert til koordineringsgruppen og var til behandling i KG-møte 17. april 2015. (FU 22624 på 22629) Av IBMs brev til SVV 24. mars 2015 går det frem at planarbeidet det strides om, var «totalplan for prosjektet». (FU 21651) I referatet fra KG-møte 17. april 2015 og i A-2s presentasjon til KG-møte 12. mai 2015, går det frem at kontraktspartene var enige om at «den reelle utfordringen» var «ansvarsforholdet mellom SVV og IBM for perioden HMP2 til HMP3».

A-2 foreslo at kontraktspartene skulle innhente en juridisk vurdering av ansvaret for planlegging og gjennomføring av HMP2 og HMP3, og at dette skulle legges til grunn for beslutningen av EA069. Dette arbeidet skulle starte opp etter gjennomføring av KP2, med mål om å presentere resultatet til neste KG-møte i mai 2015. (FU 22624 på 22629 og 22633 og FU 23750 på 23759) Avklaringen var fortsatt under arbeid på tidspunktet for KG-møte 12. mai 2015. (FU 23704 på 23709) I KG-møte 16. juni 2015 ble det besluttet at EA069 skulle nedskaleres og håndteres videre på prosjektledernivå. (FU 24893 på 24898) Saken var ikke lukket på hevingstidspunktet. Staten har gjort gjeldende at planarbeidet for perioden mellom HMP2 og HMP3 (godkjennings- og avslutningsfasen) var IBMs ansvar. Staten viser til leveranselisten ut av løsningsbeskrivelsesfasen, hvor det går frem at IBM hadde ansvar for å levere «PRO0011 Masterplan» til HMP2. (FU 13961) IBM har gjort gjeldende at det går frem av Bilag C punkt 4.5 at SVV hadde ansvar for å planlegge akseptansetest og prøvedriften, dvs. aktiviteter i perioden mellom HMP2 og HMP3.

Lagmannsretten mener at IBM må gis medhold i sitt syn basert på en objektiv tolking av Bilag C punkt 4.5. Punkt 4.5 sjette avsnitt lyder: Hensikten med Kundens test (akseptansetest) er å verifisere at løsningen inkludert migreringsmotoren oppfyller inngangskriteriene til HMP2 – «Leveransen klar til Godkjennings- og avslutningsfasen». Akseptansetesten og prøvedriften, vil bli planlagt og utført av Kunden. Ordlyden er etter lagmannsrettens syn klar, og må forstås slik at SVV hadde ansvar for planarbeidet for godkjennings- og avslutningsfasen. Dette underbygges av de etterfølgende avsnittene i punkt 4.5. Avsnitt syv beskriver aktivitetene som IBM ville hatt ansvar for, mens avsnitt åtte beskriver aktiviteter som IBM ville ha deltatt på. Det er ikke noe i disse avsnittene som tyder på at IBM hadde ansvar for planarbeidet for godkjennings- og avslutningsfasen. Det er ikke holdepunkter for at kontraktspartene i leveranselisten til HMP1, har ment å endre reguleringen av ansvaret for planlegging av akseptansetesten og prøvedriften. Dessuten er leveransen beskrevet som «Overview Master Project Plan».

IBM har gjort gjeldende at første del av Masterplanen ville baseres på IBMs gjennomføringsplan, og at det er derfor naturlig at IBM skulle stå for å levere enn oversikt. Forpliktelsen var imidlertid begrenset til dette. Etter lagmannsrettens syn, er det forenlig med ordlyden at IBMs forpliktelse var begrenset til å levere en oversikt. Lagmannsretten mener etter dette at EA069 utgjør en endring, og at IBM har krav på 149 573 kroner uten merverdiavgift i vederlag for EO069.

5.8 Vederlag under Finansieringsavtalen – IBMs påstand post 2 Til sammen 44 142 824 kroner av vederlaget under Leveranseavtalen ble tatt inn under Finansieringsavtalen ved tre leveringsattester datert henholdsvis 7. juli 2014, 5. september 2014 og 11. desember 2014. (FU 26283,

26291 og 26298) IBM har i påstand post 2 krevd dette beløpet med tillegg av finansieringsgodtgjørelse og merverdiavgift, samt renter. Det er ikke bestridt at IBM skal gis medhold i kravet om vederlag under Finansieringsavtalen i det tilfelle at SVVs heving av Leveranseavtalen var urettmessig, forutsatt at vederlaget som er utmålt etter Leveranseavtalen er større enn 44 142 824 kroner. Det er tilfellet her. Beløpet som ble overført til Finansieringsavtalen skal tillegges finansieringsgodtgjørelse og merverdiavgift. Beregningen av finansieringsgodtgjørelsen er ikke bestridt. Finansieringsgodtgjørelsen utgjør 4 658 789 kroner. Med tillegg av merverdiavgift blir vederlaget under Finansieringsavtalen 61 002 016 kroner. Det er ulike datoer for beregning av forsinkelsesrenter. Lagmannsretten har derfor, som tingretten, delt beløpet under Leveranseavtalen og Finansieringsavtalen, i tråd med IBMs påstand.

5.9 Ubetalte fakturaer IBM har krevd kompensasjon med 411 821 kroner inkludert merverdiavgift for to ubetalte fakturaer for tilleggstjenester. (FU 25284 og FU 24225) Kravet er ikke bestridt.

5.10 Oppsummering – IBMs vederlagskrav Oppsummert er IBMs krav på vederlag som følger: Vederlag under Leveransekontrakten Fastpris (programvare)

33 324 643
+ Utført arbeid opp til 130% av målpris
98 738 185
+ Arbeid utenfor målpris (EO064 og EA069)
641 001
+ Inntatt under Finansieringsavtalen
(44 142 824)
= Delsum
88 561 005
+Merverdiavgift 25 prosent
22 140 251
+Ubetalte fakturaer inkludert mva
411 821
= Sum
111 113 078

Vederlag under Finansieringsavtalen Inntatt under Finansierings avtalen

44 142 824

+ Finansieringsgodtgjørelse

4 658 789

= Delsum

48 801 613

+ Merverdiavgift 25 prosent

12 200 403

= Sum

61 002 016

5.11 IBMs krav om erstatning/avbestillingskompensasjon 5.11.1 Erstatning/avbestillingskompensasjon etter Leveranseavtalen I tillegg til betaling for utført arbeid, har IBM krevd erstatning/avbestillingskompensasjon etter Leveranseavtalen punkt 6.4.2, jf. 6.4.1. (FU 8478) Staten har gjort gjeldende at IBM ikke har krav på avbestillingsvederlag etter Leveranseavtalen. Kontrakten ble avsluttet gjennom en heving fra IBMs side. IBM har da rett til å kreve erstatning etter Generelle kontraktsbestemmelser punkt 6.4.1, men IBM har ikke lidt noe tap da hevingen medførte av IBM unngikk kostnader for langt over 100 millioner kroner. Lagmannsretten mener at IBM har krav på erstatning/avbestillingskompensasjon etter Leveranseavtalen punkt 6.4.2, jf. 6.4.1 Bestemmelsene gir den skadelidende part ved heving, krav på «vederlag for [...] sannsynliggjort kostnader og tap som eventuelt ville blitt dekket ved avbestilling, ref. punkt 7.3». Etter punkt 7.3 første avsnitt har leverandøren ved avbestilling krav på:

• ikke betalt, men opptjent vederlag for de deler av Leveransen som er dokumentert utført,
• vederlag for dokumenterte, direkte kostnader knyttet til avvikling av Kontrakten og et avbestillingsvederlag for dokumentert tapt fortjeneste, begrenset til den prosentsats som fremgår av Bilag D.

IBMs avbestillingsvederlag var i Bilag D begrenset til «5 prosent av gjenstående Målpris». (FU 9280) Målprisen er imidlertid overskredet, og IBM har ikke krevd avbestillingsvederlag. Derimot har IBM krevd 7 972 024 kroner for «dokumenterte, direkte kostnader knyttet til avvikling av Kontrakten». Lagmannsretten mener at 1 796 076 kroner av kravet er «dokumentert» gjennom ti betalte fakturaer til Basefarm AS. (FU 26065, FU 26068, FU 26137, FU 26141, FU 26142, FU 26197, FU 26198, FU 26414, FU 26415 og FU 26416) Ytterligere 768 969 kroner av kravet er dokumentert gjennom en betalt fakturaer til SugarCRM INC. (FU 26468) Disse kravene tas derfor til følge.

Resten av kravet er estimerte utgifter til nedbemanning i IBM etter hevingserklæringen (2 490 000 kroner) og estimerte utgifter som følger av at lokale ressurser i Norge ikke hadde arbeid i august måned 2015 (2 916 979 kroner). I likhet med tingretten kan lagmannsretten ikke utelukke at disse kostnadene har oppstått. Lagmannsretten viser til sammenligning at staten har anført at SVVs avviklingskostnader høsten 2015 var på ca. 8,7 millioner kroner. IBMs krav er imidlertid ikke på noen måte underbygget med bemanningslister, timelister eller annen form for beregning. Kravet anses ikke for å være dokumentert, og tas ikke til følge. Lagmannsretten konkluderer etter dette med at IBM har krav på erstatning/ avbestillingskompensasjon etter Leveranseavtalen tilsvarende 2 565 045 kroner.

5.11.2 Avbestillingskompensasjon i medhold av avtalene om vedlikehold og drift IBM har gjort gjeldende at SVVs urettmessige heving av avtalene om vedlikehold og drift (SSA-V og SSA-D), må likestilles med en avbestilling, som gir krav på betaling av avbestillingsvederlag. (FU 9498 og FU 9732) IBM har vist til lagmannsrettspraksis vedrørende bustadsoppføringsloven § 52 jf. § 58, hvor entreprenøren ved urettmessig heving fra forbrukerens side har krav på oppgjør som om forbrukeren hadde avbestilt på hevingstidspunktet. Staten har bestridt at IBM kan kreve avbestillingsvederlag i medhold av avtalene om vedlikehold og drift. Staten har gjort gjeldende at avtalene ble avsluttet gjennom en heving fra IBMs side. IBM har da etter Leveranseavtalens Generelle kontraktsbestemmelser punkt 6.4.1 rett til å kreve erstatning, men IBM har ikke lidt noe tap.

Lagmannsretten mener at verken staten eller IBM gir uttrykk for en riktig forståelse. Som nevnt hevet SVV ikke bare Leveranseavtalen, men også «alle de øvrige inngåtte avtaler om drift, vedlikehold og videreutvikling av AutoPASS Grindgut». (FU 26028 på 260343). SVVs urettmessige heving av disse avtalene, er å betrakte som et vesentlig mislighold. Virkningen av kundens vesentlige mislighold er regulert i SSA-V punkt 12.4 jf. 12.5 og SSA-D punkt 12.4 jf. 12.5 (FU 9511 og FU 9748). Etter disse bestemmelsene har leverandøren ved kundens vesentlige mislighold rett til å heve avtalene og kreve erstatning for «direkte tap som med rimelighet kan tilbakeføres til misligholdet». IBM har ikke krevd erstatning. Slik lagmannsretten ser det, må leverandørens beføyelser ved kundens mislighold anses for å være uttømmende regulert i avtalenes punkt 12.4 og 12.5. Også på dette punktet må avtalene tolkes objektivt. Det er ikke holdepunkter for at leverandøren ved kundens heving kan kreve oppgjør som om kunden hadde avbestilt på hevingstidspunktet, slik som er tilfellet etter bustadoppføringslova § 58.

Rettspraksis fra bustadoppføringslova § 58 som IBM har vist til, er derfor, etter lagmannsrettens syn, ikke relevant og kan ikke forstås slik at uberettiget heving i alminnelighet må likestilles med avbestilling. Det kan heller ikke være avgjørende at løsningen innebærer at kunden kan komme bedre ut av en urettmessig heving enn av en rettmessig avbestilling. Hvis kontraktspartene hadde ment at leverandøren ved kundens urettmessige heving kunne kreve oppgjør som om kunden hadde hevet avtalene ved hevingstidspunktet, måtte dette ha kommet tydelig til uttrykk. Lagmannsretten konkluderer med at IBM ikke har krav på avbestillingskompensasjon etter avtalene om vedlikehold og drift.

5.12 Renter IBM har krevd forsinkelsesrenter på vederlag og erstatning/avbestillingsvederlag under Leveranseavtalen, fra 14. september 2015 til betaling skjer. For vederlaget under Finansieringsavtalen har IBM krevd forsinkelsesrenter på 7 964 072,21 kroner av beløpet fra 7. august 2015 til betaling skjer, og på 53 037 944 kroner av beløpet fra 4. september 2015 til betaling skjer. Rentekravene er ikke bestridt, og forsinkelsesrenter tilkjennes som krevd. Med forsinkelsesrenter i domsslutningen, mener lagmannsretten lovens til enhver tid gjeldende forsinkelsesrente.

6 Sakskostnader IBM har vunnet saken, jf. tvisteloven § 20-2 andre ledd. Tyngdepunktet i saken har vært om SVVs heving var rettmessig. IBM har vunnet frem med at hevingen var urettmessig og at statens anke skal forkastes. Videre har IBM i det vesentlige nådd frem med sin avledede anke i og med at staten dømmes til å betale vederlag og erstatning med til sammen 174 680 138 kroner. IBM har også nådd frem med at statens krav på forsinkelsesrenter skulle avvises, jf. lagmannsrettens kjennelse 3. januar 2022 [LB-2020-82571-1]1 IBM har krav på full erstatning for sine sakskostnader etter hovedregelen i tvisteloven § 20-2 første ledd. Lagmannsretten har vurdert, men ser ikke at det foreligger tungtveiende grunner som gjør det rimelig å frita staten, helt eller delvis, for sakskostnadsansvaret etter unntaksregelen i § 20-2 tredje ledd. IBM har krevd sine sakskostnader for lagmannsretten erstattet med i alt 36 797 258 kroner med tillegg av rettens gebyrer og utgifter til fagkyndige meddommere. Siden IBM har refusjonsrett for merverdiavgift, skal det ikke regnes merverdiavgift.

Salærkravet utgjør 35 750 715 kroner og bygger på at IBMs advokatteam har brukt i alt 7 652 timer til forberedelse og gjennomføring av ankesaken. Resten av sakskostnadskravet, 1 046 543 kroner, består i korthet av vitnekostnader. Staten har protestert på salærkravet og gjort gjeldende at det er for høyt. Staten har holdt frem at det er for stor forskjell på timeprisene i IBMs og statens salærkrav når det tas i betraktning at IBM krever dekket om lag 1 500 flere timer for lagmannsretten enn det staten gjør. Timeprisen skal gjenspeiles i effektivitet. Staten har brukt 6 162,25 timer og krevd 14 343 520 millioner kroner eksklusive merverdiavgift for lagmannsretten. IBM har holdt frem at forskjellen i timetallet har sammenheng med forskjell i størrelsen på advokatteamene. IBM organiserte advokatteamet med reservekapasitet for at teamet ikke skulle slite seg ut. Ved sammenlikning av partenes timeforbruk må dessuten instansene ses under ett. Staten har også avtalt en lav timesats med sitt advokatteam. Salærkravet er ikke uproporsjonalt.

Lagmannsretten mener at kravet er rimelig og nødvendig, jf. tvisteloven § 20-5. Det følger av forarbeidene til tvisteloven at domstolene skal ha en mer sentral rolle med å styre kostnadsnivået, jf. HR-2020-1515-U avsnitt 21 med videre henvisninger til Ot.prp.nr.51 (2004–2005) side 447 til 448 og redegjørelsen til Clement Endresen og Gjermund Aasbrenn i LoR side 353 til 378. Det skal foretas en proporsjonalitetsvurdering, jf. HR-2020-1515-U avsnitt 20 med videre henvisning til HR-2020-611-A avsnitt

67. Det er de totale kostnadene som må vurderes opp mot proporsjonalitetsbegrensningen; i tvister om økonomiske verdier må kostnadene vurderes opp mot tvistegjenstandens verdi, «men det må også ses hen til betydningen av saken ut over dette», jf. HR-2020-1515-U avsnitt 22. Vurderingen av salærkrav må omfatte både timepris og antall medgåtte timer, jf. HR-2020-1515-U avsnitt 23. En høy timepris forutsetter at arbeidet er utført av advokater med solid erfaring på det aktuelle rettsområdet og som derfor kan utføre arbeidet mer effektivt enn andre, jf. HR-2021-1320-U.

IBMs salærkrav for tingretten og lagmannsretten til sammen utgjør 77 171 727 kroner, 41 421 012 kroner for tingretten og 35 750 715 kroner for lagmannsretten.

Tvistesummen er høy. Basert på at tingretten dømte staten til å betale vederlag og erstatning til IBM på til sammen 139 millioner kroner og at staten i ankeerklæringen oppga at SVV har lidt et økonomisk tap på minst 300 millioner kroner, er tvistesummen 439 millioner kroner, jf. tvisteloven § 17-2 første ledd og HR-2021-206U avsnitt 14. Salærkravet for tingretten og lagmannsretten utgjør således 17,5 prosent av tvistesummen. Saken har vært svært viktig for begge parter. I prosedyren har staten gjort gjeldende at SVV har lidt et tap på 446 millioner kroner. Hvis IBM hadde tapt, ville de direkte økonomiske konsekvensene for selskapet ha vært store. IBM ville også lidt et indirekte økonomisk tap i form av tapt renommé. Både de økonomiske og kommersielle realitetene tilsier at det var nødvendig for IBM å legge ned omfattende arbeid for å få fremstilt sin sak. Saken krevde utvilsomt også spesialkompetanse, både rettslig og faktisk. Timeprisen for slik kompetanse er høy. Det var med andre ord nødvendig for IBM å gi prosessoppdraget til en advokat som måtte bruke mange timer og som tok en høy timepris.

På den andre siden går det en grense for hva som kan anses som nødvendige og rimelige kostnader som kan belastes motparten også i slike saker, jf. HR-2020-611-A avsnitt 69. Det er i denne sammenhengen av betydning om det er brukt samme prosessfullmektig i begge instanser og om saken i stor grad sto i samme stilling for instansene.

IBM har brukt samme prosessfullmektig i tingretten og lagmannsretten. Advokatteamet har bestått av fem advokater i begge instansene, men to er nye for lagmannsretten. Saken har i stor grad stått i samme stilling i de to instansene slik at arbeidet som ble lagt ned i tingretten må kunne forventes gjenbrukt i betydelig grad. Samtidig er saken så omfattende og kompleks at det bare av den grunn må forventes en del dobbeltarbeid. I IBMs sakskostnadsoppgave for tingretten er det spesifisert til sammen 12 412 advokattimer til en gjennomsnittlig timepris på om lag 3 337 kroner. I oppgaven for lagmannsretten er det spesifisert til sammen 7 652 advokattimer til en gjennomsnittlig timepris på om lag 4 672 kroner. Antallet advokattimer i lagmannsretten inkluderer rettsmekling over fem dager. IBM krever med andre ord 20 064 timer for begge instanser.

At antallet advokattimer gikk ned med 4 760 timer fra tingretten til lagmannsretten, taler for at det i betydelig grad skjedde gjenbruk av arbeid mellom instansene. Økningen i den gjennomsnittlige timeprisen mellom instansene er ikke forklart, men antas et stykke på vei å ha sammenheng med lønns- og prisstigning, jf. HR2020-611-A avsnitt 72, jf. 71. En gjennomsnittlig timepris på 4 672 kroner må sies å være høy, men ikke høyere enn det som må regnes som markedspris for forretningsadvokater. I HR-2020-611-A hadde Høyesterett «isolert sett [...] ikke noe å si på» en timepris på 4 100 kroner uten merverdiavgift i en sak med tvistesum på nesten en halv milliard kroner, jf. avsnitt 72, jf. avsnitt 68. Denne timeprisen er ikke formulert som noen øvre grense.

Til sammenlikning er det i statens oppgave for tingretten spesifisert til sammen 17 431 advokattimer til en gjennomsnittlig timepris på 1 760 kroner, mens det i statens oppgave for lagmannsretten er spesifisert 6 162 advokattimer til en gjennomsnittlig timepris på 2 327 kroner. Staten krever med andre ord 23 593 timer for begge instanser. Timeprisen til statens prosessfullmektig reflekterer ikke markedsprisen, og det er inngått en særskilt avtale om salærsats i saken.

Størrelsen på motpartens sakskostnadskrav har imidlertid ikke betydning i seg selv; det kan derimot motpartens prosessopplegg ha, jf. HR-2020-1515-U avsnitt 24.

Slik lagmannsretten ser det, var saken lagt svært bredt og detaljert opp fra statens side. At staten brukte hele 17 431 timer for tingretten, 5 019 timer mer enn det IBM brukte der, signaliserte med tydelighet hvilket nivå staten la arbeidet på. At IBM har brukt 1 490 flere timer enn staten i ankeomgangen, ser lagmannsretten likevel først og fremst i sammenheng med at IBMs prosessfullmektig organiserte seg med et større advokatteam enn statens prosessfullmektig. IBMs team besto av fem advokater, mens statens besto av tre. Alle advokatene var til stede under ankeforhandlingen. Dersom det kreves sakskostnader «for arbeid utført av flere, må det vurderes om dette fremstår som nødvendig eller hensiktsmessig for å få utført oppdraget på en effektiv måte, eller om de nødvendige kostnadene kunne vært lavere dersom det bare hadde vært benyttet én advokat», jf. HR-2020-1515-U avsnitt 26. For lagmannsretten fremstår organiseringen med fem advokater som både nødvendig og hensiktsmessig for å få utført oppdraget med saken på en effektiv måte. Saken er svært omfattende og komplisert. Det er lagt frem faktiske utdrag på tilsammen 36 000 sider.

Saken reiser mange ulike spørsmål av både faktisk og rettslig art. Arbeidet med de fleste spørsmålene ser ut til å ha krevd inngående detaljkunnskap om både faktum og juss. Det ville vært for krevende for en advokat å ta prosessoppdraget alene. Det lot seg dessuten gjøre å dele arbeidet med saken opp i naturlige bolker som kunne tildeles de forskjellige advokatene i teamet. Organiseringen bidro til å forbygge mot at advokatene slet seg ut under både forberedelsen og gjennomføringen av den lange ankeforhandlingen. Om advokatteamet hadde blitt redusert til fire eller tre, måtte arbeidet fortsatt ha blitt gjort. Lagmannsretten ser det som mest sannsynlig at effektiviteten til advokatene som sto igjen, ville blitt redusert. Organiseringen bidro også til reservekapasitet. For eksempel kunne teamet håndtere de nye sakkyndigrapportene som staten la frem kort tid før avsluttet saksforberedelse, uten forsinkelser i behandlingen. Som nevnt må timetallet ses i sammenheng med timeprisen; en høy timepris forutsetter høy effektivitet.

Sett på bakgrunn av at IBMs timeforbruk gikk betydelig ned fra tingretten til lagmannsretten og at IBMs timeforbruk for begge instanser ligger 3 500 timer under statens, ser ikke lagmannsretten holdepunkter for at det har vært noe å utsette på effektiviteten til IBMs advokatteam. Lagmannsretten legger etter dette IBMs salærkrav til grunn. Rettsgebyret for IBMs avledede anke utgjør 28 128 kroner. Etter dette må staten erstatte IBMs sakskostnader med 36 825 386 kroner. Staten må etter det resultatet som lagmannsretten er kommet til, også dekke utgiftene til de fagkyndige meddommerne etter regning fra lagmannsretten, jf. tvisteloven § 20-2 første og andre ledd og rettsgebyrloven §

2. Utgiftene fastsettes i en egen avgjørelse etter regning fra meddommerne, jf. domstolloven § 105 a. Dommen er enstemmig.

Dommen er ikke avsagt innen lovens frist. Dette skyldes i hovedsak sakens betydelige omfang og kompleksitet.

DOMSSLUTNING

I anken: Anken forkastes. I den avledede anken:

1. Staten ved Samferdselsdepartementet betaler til International Business Machines AS, 111 113 078 – etthundreogellevemillioneretthundreogtrettentusenogsyttiåtte – kroner i vederlag under Leveranseavtalen med tillegg av forsinkelsesrente fra 14. september 2015 til betaling skjer.
2. Staten ved Samferdselsdepartementet betaler til International Business Machines AS, 61 002 016 – sekstienmillionertotusenogseksten – kroner i vederlag under Finansieringsavtalen med tillegg av forsinkelsesrente fra 7. august 2015 til betaling skjer av 7 964 072 – syvmillionernihundreogsekstifiretusenogsyttito – kroner, og fra 4. september 2015 til betaling skjer av 53 037 944 – femtitremillionertrettisyvtusennihundreogførtifire – kroner.
3. Staten ved Samferdselsdepartementet betaler til International Business Machines AS, 2 565 045 – tomillionerfemhundreogsekstifemtusenogførtifem – kroner i erstatning med tillegg av forsinkelsesrente fra 14. september 2015 til betaling skjer.
4. Oppfyllingsfristen i domsslutningen post 1 til 3 er to uker fra forkynnelse av dommen. I både anken og den avledede anken:
5. I sakskostnader for lagmannsretten betaler staten ved Samferdselsdepartementet til International Business Machines AS, 36 825 386 – trettiseksmillioneråttehundreogtjuefemtusentrehundreogåttiseks – kroner innen to uker fra forkynnelse av dommen.
6. Staten ved Samferdselsdepartementet er ansvarlig for utgiftene til de fagkyndige meddommerne etter regning fra lagmannsretten. 2 Rettes til 12 Rettet i medhold av tvisteloven § 19-8 Jannicke Johannesen 3 Rettes til 19 Rettet i medhold av tvisteloven § 19-8 Jannicke Johannesen