Contracts, responsibility, liability, risks in Systems development

Advokat Arve Føyen

FØYEN advokatfirma DA

2

Tema

• Prising av ikt-leveranser• Fokus på risikohåndtering • Kontraktsregulering av betydning for prising• Noen  praktiske utfordringer knyttet til

– Organisering– Samhandling– Underleverandører– Endringskontroll

3

Faser i anskaffelsesprosessen

PlanleggingKravspesifikasjon

Forberedelseavtilbud

BestillingstidKlargjøringInstallasjon

Forespør.om

tilbudAvtale

VurderingForhandlingerValg lev.

DriftGodkjennings-periode

Garantiperiode

Tilbud

KundeKonsulent

LeverandørerKundeLeverandørKunde

LeverandørKundeLeverandør

Levering

Kunde/Lev.Kunde

Godkjenning

Kunde

Ordinær drift

Mil

epæ

ler

Akt

ører

Fas

er

4

Faser i anskaffelsesprosessen

PlanleggingKravspesifikasjon

Forberedelseavtilbud

BestillingstidKlargjøringInstallasjon

Forespør.om

tilbudAvtale

VurderingForhandlingerValg lev.

DriftGodkjennings-periode

Garantiperiode

Tilbud Levering Godkjenning Ordinær drift

Mil

epæ

ler

Fas

er

Kontraktsoppfølging

5

Hva er en kontrakt?

• Hvem gjør hva• Til hvilken tid • På hvilken måte • Til hvilken pris• Og hvilke øvrige vilkår

6

To regelsett gjelder sammen

• Avtalen• Bakgrunnsretten

– Alminnelig kontraktsrett bl. a. uttrykt i avtaleloven og i kjøpsloven

– Spesialregler (NS 3430 osv.)

– Bakgrunnsretten for øvrig (rettspraksis, juridisk metode)

7

Konsekvenser av dette

• Kontrakten som rettesnor– I gode og onde dager

• Ta hensyn til bakgrunnsretten– Gir den ønskede løsninger?

• Skolemesterklausuler - pedagogikk

8

Kundens rolle

Kunden er svært ofte ”underleverandør”• Bidrar med personer i prosjektgrupper• Har laget spesifikasjoner • Oppgi parametere, tilrettelegging for

leveranse etc. • Stiller infrastruktur, lokaler og andre

ressurser til rådighet

9

Kundens medvirkningsplikt

• Manglende oppfyllelse kan medføre ansvar for:– Leverandørs rentetap som følge av forsinket

fakturering

– Omkostninger til retting og omlevering

– Konsekvenstap for selger

• Leverandøren kan få rett til:– Utsettelse

– Tilleggsbetaling

– Heving og erstatning

10

Manglende oppfølging av mislighold

• Kan medføre rettstap• Kan endre innholdet i avtalen• Kan påvirke tolkningen av

avtalen

11

Betydning for kontraktsutforming

• Avtalen må angi tydelig:– Kommunikasjonslinjer

– Skriftlighet for alle endringer

– Frister, prosedyrer

– Hva som skal gjøres for å følge opp kontrakten

12

Praktisk kontraktsoppfølging

• Avtalen er et sentralt styringsdokument

• Analysér avtalen– Hva skal følges opp

– Hvem skal gjøre det

– Når?

– Utarbeid rutiner

13

Sørg for at de som skal følge opp:

• Forstår hele leveransen

• Forstår kontrakten

• Vet hva de skal gjøre dersom ikke alt går som det skal

14

Overordnet hjelpedokument for kontraktsstyring• Oversikt over milepæler, varslingsfrister og datoer av

betydning

• Oversikt over hendelser som gir handlingsplikt– Betalingsfrister– Frister for feilmelding– Behandling av endringsmeldinger etc.

• Beskrivelse av andre forhold under kontrakten vedr rettigheter og forpliktelser– Rapporter, dokumentasjon, endringer, oppsigelse etc.

15

Oversikt over hjelpedokumenter i ordinær driftsfase

Hjelpedokument for kontraktsstyring

Standardbrev for endringsordre Standard reklamasjonFeilmelding under drift

16

Oversikt over hjelpedokumenter ved utvidelser av leveransen

Sjekkliste for installasjon

Standardbrev for feil Og avviksmelding

før levering

Godkjennelses-protokoll

Standard godkjennelsesbrev

Avvisning av leveransen

17

Passe særlig på ved kritiske punkter

• Når noe går galt• Ved levering/

overtakelse/akseptanse etc.• Ved frigivelse av

forskudd/betaling av avdrag frigivelse av garantier

• Milepéler

18

Taktiske grep når ting skjærer seg

• Prosessen frem til konflikt– Posisjonering meget viktig

• ”Red Flags”– Krangel om kontraktsforståelse– ”Forslag” om forskuddsbetaling,– Endring med uoverskuelige

konsekvenser eller lignende– ”Bekreftelser” fra motparten på

overenskomster du ikke kan huske

19

Hovedhensyn for kunden:

• Sørge for kontraktsmessig levering• Posisjonere seg best mulig for utøvelse

av misligholdsbeføyelser

– Sørge for at uklarheter avklares

– Konsekvenser må gjøres kjent for motparten

– Begrense skadevirkninger

20

Praktiske tiltak

• Sikre bevis– Fysiske bevis– Elektroniske bevis

• Skriftlige avtaler!• Gi skriftlig uttrykk for bekymring

– Pek på konsekvenser og ta forbehold

– Be leverandøren ta ansvar, samt rapportere hyppig

21

Vurdere sannsynlig utfall

• Varsle egen organisasjon og evt medkontrahenter som berøres

• Anføre force majeure i forhold til medkontrahenter

• Passe på utbetalinger/frigivelser

Risiko og prising - Konseptuelt

Sammenhenger mellom • Kostnadsestimering• Contingency (sikkerhetsmargin for uforutsette forhold)• Prising

23

Prinsipielt

Estimering/costing og prising er i utgangspunktet to atskilte prosesser.

En leverandør må i alle tilfelle ha nødvendig trygghet for sine basis estimater og de ulike kostnadselementene forbundet med den jobben som skal gjøres.

Hvordan et konkret prosjekt skal prises er imidlertid annen vurdering – time & material, fatspris, verdibasert, strategisk, transaksjonsbasert etc.

Det viktige budskapet her er at kostnadsestimatet ikke under noen omstendighet bør endres, dersom det foreligger en prismessig utfordring

Skal kostnadsestimatet endres må man også endre på Forutsetninger og/eller Scope for den jobben som skal gjøres

24

Costing

Additional considerations (client, team, schedule…)

Business Process Layer{documentation =

}

CollectionController

Business Process Layer

Business Entity Layer{documentation =

}

Frameworks Layer{documentation =

}

Business Entity Layer

Frameworks Layer

Adapters{documentation =

}

Interfaces

Reports{documentation =

}

Screens{documentation =

}

Reports

Screens

ValidationController

EditsController

CurrencyConverter

FeesProcessor

Matcher

ReportFramework

WorkflowFramework

Storehouser

SettlementController

BatchFramework

DeliveryControllerRoutingController

TranslationController

ReportController

BillingController

LoggingService

ProfileSynchroniser

TCEditRules VMLEditRules

Advice

Transaction

File

Batch

Currency

Fee

BINStream

TransactionException

Return

MemberProfileFeeRules

Bill

BillingRules

SchemeProfile ClearingWindow

FormatDefinitionMapping

Report

1..*

0..1

1..*

0..1

*

*

*

*

*

*

*

*

**

*

1

1

*

*

1

0..* 1

0..*1

1

0..*

0..*

1

1

0..*

1

0..*

0..*

0..*

1..*0..*

0..*

1..*

1..*

0..*

1..*

0..*

BatchOnLineSynchroniserService

ArchivingController

ReconciliationService

BackupController TimestampService

ReferenceDataCacheService SystemProfileService PersistenceService

ErrorManagerService

ClearingReport SettlementReport QualifierReport

FeeReport ReclassificationAdvice

OnlineFramework «interface»TapeAdapter

«interface»EnterpriseManagementAdapter

«interface»FTPAdapter

«interface»MQAdapter

«interface»FeeInterface

«interface»CMLSInterface

«interface»FERISInterface

«interface»TransactionFileInterface

«interface»IBInterface

«interface»EditRulesInterface

«interface»VFTSInterface

«interface»User Screens

«interface»ExceptionScreens

«interface»FileDetailScreens

«interface»CollectionWindowScreens

«interface»FeeScreens

«interface»MemberProfileScreens

«interface»CONFIGInterface

«interface»SettlementSchemes

«interface»EditRulesScreens

«interface»CurrencyRateScreens

«interface»BillingScreens

«interface»MonitoringScreens

TC-VMLMapping ASCII-EBCDICMapping TXT-PDF-XLSMapping ReportTemplate

SecurityService

«interface»RefDataInterface

BatchAcknowledgement DebitRevBridgeMessage

CustomEditRules

*

*

«interface»RefDataScreens

«interface»HelpScreens

«interface»HouseKeepingScreens

«interface»SystemTableScreens

Payroll

SolutionContingency

Direct Non-Payroll

Other Costs

Cost

Application Blueprint

Business Process Layer{documentation =

}

CollectionController

Business Process Layer

Business Entity Layer{documentation =

}

Frameworks Layer{documentation =

}

Business Entity Layer

Frameworks Layer

Adapters{documentation =

}

Interfaces

Reports{documentation =

}

Screens{documentation =

}

Reports

Screens

ValidationController

EditsController

CurrencyConverter

FeesProcessor

Matcher

ReportFramework

WorkflowFramework

Storehouser

SettlementController

BatchFramework

DeliveryControllerRoutingController

TranslationController

ReportController

BillingController

LoggingService

ProfileSynchroniser

TCEditRules VMLEditRules

Advice

Transaction

File

Batch

Currency

Fee

BINStream

TransactionException

Return

MemberProfileFeeRules

Bill

BillingRules

SchemeProfile ClearingWindow

FormatDefinitionMapping

Report

1..*

0..1

1..*

0..1

*

*

*

*

*

*

*

*

**

*

1

1

*

*

1

0..* 1

0..*1

1

0..*

0..*

1

1

0..*

1

0..*

0..*

0..*

1..*0..*

0..*

1..*

1..*

0..*

1..*

0..*

BatchOnLineSynchroniserService

ArchivingController

ReconciliationService

BackupController TimestampService

ReferenceDataCacheService SystemProfileService PersistenceService

ErrorManagerService

ClearingReport SettlementReport QualifierReport

FeeReport ReclassificationAdvice

OnlineFramework «interface»TapeAdapter

«interface»EnterpriseManagementAdapter

«interface»FTPAdapter

«interface»MQAdapter

«interface»FeeInterface

«interface»CMLSInterface

«interface»FERISInterface

«interface»TransactionFileInterface

«interface»IBInterface

«interface»EditRulesInterface

«interface»VFTSInterface

«interface»User Screens

«interface»ExceptionScreens

«interface»FileDetailScreens

«interface»CollectionWindowScreens

«interface»FeeScreens

«interface»MemberProfileScreens

«interface»CONFIGInterface

«interface»SettlementSchemes

«interface»EditRulesScreens

«interface»CurrencyRateScreens

«interface»BillingScreens

«interface»MonitoringScreens

TC-VMLMapping ASCII-EBCDICMapping TXT-PDF-XLSMapping ReportTemplate

SecurityService

«interface»RefDataInterface

BatchAcknowledgement DebitRevBridgeMessage

CustomEditRules

*

*

«interface»RefDataScreens

«interface»HelpScreens

«interface»HouseKeepingScreens

«interface»SystemTableScreens

Technology Blueprint

Estimating Model

Sourcing

3rd Parties

Business Process Blueprint

Training & Performance Support Blueprint

Jan Feb Mar200y

Oct Nov Dec200x

Apr May Jun Jul Aug Sep Oct Nov Dec

Customer Readiness

Organisation Readiness

Product Readiness

Implementation Date

(Value Date 17/11)

Technical Design

Build / Unit Test

System Test

BAT

Conceptual Readiness Phase

Preparation Task Execution

Line TrainingOp. Test

Initial Customer Visits

Release Brochures

Info Roadshows

Account Opening

SimulationTraining

Jan Feb Mar200y

Oct Nov Dec200x

Apr May Jun Jul Aug Sep Oct Nov Dec

Customer Readiness

Organisation Readiness

Product Readiness

Implementation Date

(Value Date 17/11)

Technical Design

Build / Unit Test

System Test

BAT

Conceptual Readiness Phase

Preparation Task Execution

Line TrainingOp. Test

Initial Customer Visits

Release Brochures

Info Roadshows

Account Opening

SimulationTraining

Sammenhenger mellom kostnadsestimering, contingency og prising

25

Payroll

SolutionContingency

Direct Non-Payroll

Other Costs

Costing, contingency and pricing

Cost

MinimumMargin

AdditionalValue

NegotiatingContingency

Cost

Solution Contingency is a budget allocation added to a solution estimate to cover risks that may or may not arise during delivery of the solution. Risks that need to be covered by solution contingency fall into two broad categories:

• Estimate Variability - Represents contingency to cover the variability of estimates for known tasks, e.g.:

• Uncertainty linked to new technology/application

• Estimating assumptions incorrect

• Limited detail or specificity of business or technical requirements

• Skills and experience of staff lower than previous experience

• Delivery Risks - Represents contingency to cover expected outcomes of events that impact the ability to deliver the effort on time and budget. This covers events such as:

• Dependent effort(s) not delivered on time

• Sign-offs not achieved on time• Resources not available when

required or with the right skills• Rework due to quality issues

Price range

26

Betraktninger knyttet til risiko En leverandør må gjøre risikovurderinger langs

mange dimensjoner i forbindelse med estimering av utviklingsprosjekter og prissetting

Typisk må følgende aspekter vurderes: Selve estimatet (arbeidsomfang fordelt på ulike kategorier

og de ulike kostnadselementene) Avtalen og dens betingelser Varighet av avtalen og mulighet for tilpasninger av avtalen

over tid Kunderelasjonen – styrke og varighet/erfaring Underleverandører Endringskontroll

27

Selve estimatet og de ulike kostnadselementene• Hvor sikker er leverandøren i det konkrete tilfellet på

kostnadsestimatet og på sin egen evne til å levere i henhold til estimatet?

• Har leverandøren den nødvendige forståelsen av løsningen som skal leveres, forvaltes og/eller driftes?

• Omfangsdefinisjon og avgrensning, kompleksitetsforståelse og forutsetninger er viktige elementer i denne sammenheng

• Et annet sentralt forhold er i hvilken fase estimatet blir utarbeidet.– Vanskelig å estimere med høy presisjon i en tidlig fase. Her

brukes ofte en top-down estimeringstilnærming, der estimeringsusikkerheten er stor. I praksis ikke mulig å gi en fast pris på dette stadiet.

– I senere faser – typiske etter analyse og/eller design, er det mulig å benytte en bottom-up tilnærming, der estimeringsusikkerheten er lavere, og der det kan være grunnlag for å gi en fastpris

28

Avtalen og dens betingelser• Her er spennet stort – alt fra det enkle og oversiktelige

for et isolert utviklingsoppdrag til store og komplekse kontrakter

• Både kostnads- og prisvurderinger må vurderes konkret i lys av betingelsene i kontrakten,

• Sentralt at Leverandøren forstår innholdet i og konsekvensene av de ulike betingelsene i Kontrakten

• Typisk må Leverandøren klare å skille ut de betingelsene som er kostnadsdrivere, og som det eksplisitt må tas høyde for i Leverandørens estimering.

• Krav til kvalitet ved go-live er et typisk eksempel på dette – strenge krav til utestående feil ved sluttstilt test påvirker test-estimatet direkte

29

Avtalen og dens betingelser (forts)• Et annet eksempel er SLA-krav eller

godkjenningskriteria – Leverandøren må være sikker på at enkelthetene i

SLA-regimet/godkjenningskriteria er analysert og vurdert, slik at det kan tas høyde for dette i estimatene.

• Typisk vil man i sammenheng med SLA-krav/godkjenningskriteria skille mellom – Den innsatsen som i et normaltilfelle må legges inn

for å kunne opprettholde SLA eller oppfylle godkjenningskriteria

– Estimat som må legges til for å dekke eventuell straff dersom SLA-krav eller godkjenningskriteria ikke nås (må sees i lys av antall SLA’er, SLA-nivå og nivå på strafferegime)

30

Avtalen og dens betingelser (forts)

• Et annet viktig forhold er hvordan tolkningsrommet i kontrakten vurderes. – I en omfattende og kompliserte kontrakter vil gjerne

tolkningsrommet være forholdsvis stort på flere områder

• Systemet med Kundens funksjonelle kravspesifikasjon som styrende og leverandørens løsningsspesifikasjon med trinnhøyde tolkningsmessig etter kundens spesifikasjon, som i SSA-U, skaper noen utfordringer

– Dette må Leverandøren ta med i vurderingene når arbeidet skal estimeres og prises – hva er risikoen for disputter på kontraktssiden, og hvor smidig er konflikthåndteringsregimet?

31

Noen sentrale avtalebetingelser (SSA-U)• Leveranseomfang – Pkt 1 og 2 og Bilag 1-7• Tolkning – Rangordning Pkt 1.3• Pkt 8, jfr bilag 7 Pris, Samlet vederlag og betalingsmåte• Akseptansetest, Idriftsetting og levering pkt 2.4 og kriteria for

godkjennelse pkt 2.4.5• Godkjenningsperiode og Leveringsdag pkt 2.5• Avbestilling – midlertidig stansing Pkt 2.6• Endringsregime Pkt 3• Garantiperiode pkt 4• Kundens ansvar og medvirkning – pkt 6 jfr Bilag 6 –

Sanksjonsmuligheter ved ikke-oppfyllelse?• Leverandørens Mislighold Pkt 11.• Kundens Mislighold – Pkt 12• Rettsmangler – Pkt.13

32

Akseptanse og godkjenning

1. Sign off spesifikasjonsfase2. Akseptansetest plan oversendt fra kunde (xx virkedager før oppstart av

akseptansetest)3. Tilbakemelding akseptansetest plan (xx virkedager)4. Gjennomføring av planlagt akseptansetest iht. omforent plan5. Retting av innmeldte feil etter endt akseptansetest (xx virkedager)6. Retest av rettelser før Akseptansedag (xx virkedager)7. Akseptansedag8. Oppstartsdag9. Leveringsdag

Spec.

fase

Godkjennings-

periode

(3 mnd)

Design,

utvikling,

systemtest

1

24

7 93

6

8

5

Akseptansetestperiode

Forberedelser til produksjonssetting

(xx virkedager)

33

Varighet av kontrakten og mulighet for tilpasninger av kontrakten over tid• Hvor låst er kontrakten og hvilke tilpasninger kan gjøres underveis? • Er det rom for re-forhandlinger underveis og hvilken

forhandlingsposisjon vil det da være mulig å ta som leverandør? • Hvilke prisreguleringsmekanismer finnes i kontrakten?

– Det utgjør en stor forskjell for leverandøren om han kun justerer ut fra KPI eller om man benytter for eksempel Tekna indeks eller IKT Norge indeks

– Ved offshoring etc – er det tatt høyde for COLA-justeringer lokalt• I en kompleks langtidskontrakt som favner bredt med få muligheter for

tilpasninger underveis, er det viktig for leverandøren å vurderer den helhetlige kontraktsrisikoen. – Det er ofte vanskelig å gjøre dette vitenskapelig – erfaringer,

rimelighetsvurderinger og vurdering av kundeforholdet er viktige parametre

• I estimeringssammenheng må Leverandøren i tillegg sørge for å ha tatt nødvendig høyde for management kapasitet i ulike dimensjoner, – Contract management– Juridisk bistand over kontraktens løpetid.

34

Kundeforhold

• Når Leverandøren vurderer risiko, er vurdering av styrken og varigheten av kundeforholdet svært viktig – Er kundeforholdet i stor grad et partnerskap der

relasjonene er tette og gode

– Er det et kunde/leverandør-forhold der det er en profesjonell distanse og der kunden i stor grad agerer kontraktuelt?

• Heller ikke her finnes noen fasitsvar på hvordan man kvantifiserer risiko,

• Helhetsvurderingen er svært ulik i de to ytterpunktene.

35

Underleverandører• Risikovurderingen i denne sammenheng kan deles i to:

– Avtaleforhold, avtalens betingelser, fleksibilitet i kontrakten og leverandørrelasjon på samme måte som mot kunde på den ene siden og

– Vurdering av underleverandørens evne til å levere som avtalt på den andre siden

• Bruk av back-to-back mekanismen kan i stor grad fungere som en sikkerhet– I noen tilfelle kan det imidlertid være aktuelt for

underleverandøren å legge inn begrensninger på øvre ansvar eller mulige straffereaksjoner som gjør at back-to-back ikke gjelder fullt ut – eksempelvis SLA-ansvar ifm. tilgjengelighet på en tjeneste som Hovedleverandøren har totalansvar for

– Problemet med standard programvare fra 3. part som del av leveransen og totalansvar for hovedleverandøren

36

Underleverandører (forts)• Det er også noen ganger slik at hovedleverandøren må ta over

oppgaver helt eller delvis fra underleverandør der underleverandøren ikke evner å utføre oppgavene – Dette resulterer ofte både i mer operativt arbeid og

prosessarbeid i tilknytning til avtaletolkning (hvem har ansvaret osv.).

– Erfaring viser at det skal mye til før man klarer å løfte denne typen kostnader over på underleverandøren pga. krav til ’bevis’ og dokumentasjon

• I mange tilfelle er det ikke god kost/nytte for Leverandøren å kreve dette– Med mindre man har en krystallklar sak, så ender denne

typen disputter i beste fall med et kompromiss, og kostnadene ved å drive frem kompromisset er høye

• Derfor blir tydelig avgrensning av ansvar, governance struktur og underleverandørens evne til å leve opp til sine forpliktelser viktige parametere i en risiko- og kostnadsvurdering

37

Samhandling og koordinering• Ved flere sidestilte leverandører i større prosjekt

– Egen samhandlingsavtale med betydelig krav til koordinering ansvarsavklaring og konfliktløsing på leverandørnivå

– Kunden velger ofte å stille seg utenfor og etablerer en egen samhandlingsavtale der leverandørene selv må sørge for avklaringer uten å involvere kunden

– Kostnadene for samhandling må kalkuleres inn• I hovedkontrakt • Alternativt i samhandlingsavtalen

– Svært vanskelige vurderinger og rom for ”fingerpeking”– Viktig med fall-back og konfliktløsing/eskalering– Kontroll med valg av samhandlingspart

Risiko ved endringer

39

Initierings-fase

Planleggings-fasen

Gjennomføringsfasen

Forpliktede kostnader

Påvirkningsmulighet

Påvirkningsmulighet vs endringskostnad

40

Størst påvirkningsmulighet i tidlig fase

Tid

Bemanning

Initiering Planlegging

Gjennomføring

ProsjektStart

ProsjektSlutt

41

Endringskontroll

• For å sikre mot risiko initielt og underveis, er endringskontroll svært viktig– For det første må det foreligge dokumentert et avgrenset

scope og en enighet med kunde om at endringer skal håndteres som nettopp det – som endringer

– Underveis må Partene sørge for å ha et strengt regime på hvordan endringer – og ikke minst gråsone tilfeller – håndteres

– Vesentlig mye viktigere innenfor en fastpriskontrakt enn i en time&material basert kontrakt

– Men også innenfor T&M er endringskontroll viktig for å kunne sikre

• leveransekvalitet • overholdelse av avtalt leveringstid, • og for å etablere et bevisst forhold til kostnadspådrag hos

begge parter

Spørsmål?

arve.foyen@foyen.nowww.foyen.no