PS2000 Kontraktsstandard for leveranse av programvare m. m.
PS2000 Kontraktsstandard for leveranse av programvare m. m.
Veiledning for kontraktsutarbeidelse
DEN NORSKE DATAFORENING
Versjon : 3.0
Dato oppdatert : 30.04.2007
INNHOLDSFORTEGNELSE
5
1.1 Målsettingen for PS2000-kontraktsstandarden 5
1.3 HOVEDENDRINGER I VERSJON 3 7
1.5 Beskrivelse av gjennomføringsmodellen 8
9
11
3.5 Milepæler og fremdriftsplan 13
3.6 Andre forhold knyttet til forarbeidet 13
3.7.2 Kvalifisering av tilbydere 14
16
17
5.2 Resultat av behovsfasen 17
5.3.3 Trinnvis konstruksjon 21
5.3.3.1 Detaljplanlegging / Analyse og design 21
5.3.3.3 Testing og feilretting 22
5.4 Godkjennings- og avslutningsfase 23
25
6.2 Incentiv- og sanksjonsordninger 27
6.2.1 Incentiver og sanksjoner knyttet til vederlaget 27
6.2.2 Incentiver og sanksjoner knyttet til tid 30
31
7.3 Deponering av kildekoden 31
32
8.1 Leverandørens mislighold 32
8.3 Fellesregler om inntruffet eller forventet mislighold 33
34
34
10.2 Overdragelse av kontrakten 34
35
1 Innledning
Dette dokument er en veiledning for prosessen rundt kontraktsinngåelse basert på ”PS2000 Kontraktstandard for leveranse av programvare m. m.” (også kalt PS2000- kontraktsstandarden). Kontraktsstandarden er utarbeidet for prosjekter innen systemutvikling eller systemleveranser hvor det ikke er hensiktsmessig eller mulig å fastsette nøyaktige eller detaljerte spesifikasjoner.
1.1 Målsettingen for PS2000-kontraktsstandarden
I IT-bransjen har gjennomføring av større og komplekse prosjekter i henhold til iterative og etter hvert agile (smidige) prosesser etablert seg som den mest resultatorienterte fremgangsmåten. PS2000-kontraktsstandarden er den første norske kontraktsstandard som regulerer gjennomføring etter iterative prosesser. PS2000-kontraktsstandarden er utformet slik at den kan benyttes både av private og offentlige aktører.
Denne veiledningen er en rettledning for bruk av PS2000-kontraktsstandarden ved leveranse av programvare med stor grad av utvikling og/eller tilpasning. Kontraktsstandarden tar utgangspunkt i en trinnvis gjennomføringsmodell hvor selve konstruksjonen og sammensetningen av programvaren i hovedsak skjer ved iterative prosesser.
Kontraktsstandarden legger opp til at komponenter av programvare skal utvikles og tilpasses i sekvensielle eller parallelle trinn i konstruksjonsfasen. Den trinnvise utviklingen skal skje med bakgrunn i en behovsanalyse som skal være bearbeidet til en løsningsbeskrivelse i første fase av konstruksjonen. Løsningsbeskrivelsen vil være relativt grov sammenlignet med tradisjonelle IT-utviklingsavtaler. Det kompenseres for dette ved at partene ved gjentatte kontrollpunkter evaluerer de erfaringer som er gjort i tilbakelagte trinn av konstruksjonsfasen.
Kontraktsstandarden vil være spesielt egnet for alle systemutviklingsprosjekter og systemleveranser som preges av usikkerhet, der det forutsettes at begge parter analyserer og i fellesskap dokumenterer erkjent usikkerhet. Usikkerheten avspeiler seg i denne sammenheng primært i at det er vanskelig å utarbeide nøyaktige og komplette spesifikasjoner. Ved å tilpasse incentivordninger ut fra dokumentert og erkjent usikkerhet, vil forutsetningene for gjennomføringen kunne ivaretas og reflekteres i kompensasjonsformatet. Ved høy usikkerhet vil incentivordningene normalt være svakere, det vil si mer gå i retning av betaling for løpende timer, mens ved lav usikkerhet vil incentivene kunne være sterkere og mer gå i retning av fast pris.
Kontraktsstandarden skiller seg vesentlig fra andre standarder i markedet. Spesielt kan følgende trekkes frem:
- Kontraktsstandarden er utviklet av kunder og leverandører i samarbeid, slik at begge parters interesser er ivaretatt og balansert.
- Kontraktsstandarden tilrettelegger for å fange opp den læring som foregår under gjennomføring av prosjektet. Gjennomføringsmodellen består av 4 faser (behovsfasen, løsningsbeskrivelsesfasen, trinnvis konstruksjonsfase og godkjennings- og avslutningsfasen).
- Det er tilrettelagt for utstrakt bruk av motiverende økonomiske modeller i form av incentivordninger, slik at eventuelle tids- og kostnadsbesparelser kommer begge parter til gode og vice versa. Det skal utarbeides en usikkerhetsanalyse som legges til grunn ved valg av spesifikke incentiver.
- Kontraktsstrukturen med forhåndsutfylte bilag og veiledning gjør det enklere å utforme spesifikke kontrakter tilpasset ulike behov. Alle referanser i de generelle kontraktsbestemmelsene er utdypet i bilagene.
De ovennevnte særtrekkene er vektlagt ut fra den dokumenterte ”beste praksis” i en rekke større IT-prosjekter som er hentet frem gjennom forskningsprogrammet ”Prosjektstyring år 2000” i årene 1997 til 2000.
1.2 Bakgrunn
Programdeltakerne i forskningsprogrammet Prosjektstyring år 2000 (PS2000) etablerte i 1996 en IT-gruppe, som utarbeidet 1. versjon av kontraktsstandarden (utgitt i september 1999).
Denne IT-gruppen bestod av representanter fra:
- Bull A/S
- Cap Gemini Norge
- IFS Norge AS
- TietoEnator Consulting
- Statskonsult
- Aetat Arbeidsdirektoratet
- Telenor 4tel
- Statoil
- Xxxxxxxxxxxxxx Xxxxxx DA
- PROMIS AS
PROMIS var faglig ansvarlig for prosjektet og har stått for utarbeidelse av kontrakts- og veiledningsteksten. De generelle bestemmelsene, som er den sentrale delen av kontraktsteksten, er utarbeidet i nært samarbeid med Xxxxxxxxxxxxxx Xxxxxx, som har hatt rollen som juridisk ansvarlig. Forøvrig har representanter for alle deltagerne i IT-gruppen deltatt aktivt i arbeidsmøter og høringer.
Etter at forskningsprogrammet ble avsluttet, overtok Den Norske Dataforening (Dataforeningen), gjennom Faggruppen for prosjektledelse og kvalitetssikring, ansvaret for videre utvikling og forvaltning av kontrakten. I regi av Dataforeningen har det nå vært gjennomført en revisjon av kontraktsstandarden, med en referansegruppe der både leverandører og kunder var representert. Referansegruppen bestod av representanter fra:
- Accenture
- CapGemini Norge
- IFS Norge AS
- TietoEnator Consulting
- Computas AS
- EDB Fundator
- Norske Skogindustrier AS
- Statskonsult
- Aetat Arbeidsdirektoratet
- Rikstrygdeverket
- Xxxxxxxxxxxxxx Xxxxxx DA
- PROMIS AS
Resultatet av dette arbeidet var at det forelå en versjon 2 av PS2000-kontraktsstandarden i 2001.
Arbeidet med å revidere PS2000-kontraktsstandarden, basert på erfaringer med bruk fra 1998 og frem til 2005, er ferdigstilt, slik at versjon 3 ble utgitt i januar 2007. Revisjonen er foretatt av Dataforeningens styre for Faggruppen for IT-kontrakter, som i perioden har bestått av representanter fra både kunde- leverandør- og rådgiversiden:
- Xxxxxxxxxxxxxx Xxxxxxx Xxxxxx AS
- Bekk Consulting AS
- Capgemini Norge AS
- Computas AS
- Forsvaret FLO/IKT
- Gartner Norge AS
- Gjensidige Forsikring
- NAV Arbeids- og velferdsdirektoratet
- Simonsen Advokatfirma DA
- PROMIS AS
Mer informasjon om Dataforeningen og faggruppens arbeid kan fås ved henvendelse til Den Norske Dataforening (xxx.xxxxxxxxxxxxxx.xx) eller PROMIS AS (xxx.xxxxxx.xx).
1.3 Hovedendringer i versjon 3
Basert på erfaringer med bruk av kontraktsstandarden i perioden fra den ble utgitt første gang i 1998 og frem til 2005, ble det definert følgende liste med forbedringsområder som nå er ivaretatt:
- Prismodellen er endret slik at det kun er løsningsbeskrivelses- og konstruksjonsfasen som er underlagt en målpris
- Godkjenningsfasen prises som et fast tillegg
- Det avtales et separat vederlag for garantiperioden for å synliggjøre påslaget samtidig som lengden på garantiperioden kan avtales mellom partene
- Det er presisert at målprisavregning skal gjennomføres med bakgrunn i en dokumentert, gjennomsnittlig timerate
- Det er presisert at usikkerhetsmatrisen skal oppdateres etter løsningsbeskrivelsesfasen
- Det er definert krav til innhold og gjennomføring av systemtest
- Godkjenningskriterier er forenklet og gjort mer beskrivende
- Det er åpnet for fleksibilitet i forhold til voldgifts- eller domstolsbehandling ved konflikt
- Reglene for overdragelse til annet rettssubjekt er endret
- Bilag D (vederlag) er betydelig utvidet og presisert, bl.a. er tilleggstjenester som ikke inngår i målpris, lagt inn i en egen pristabell
- Bilag E (garanti- og vedlikeholdsbetingelser) er revidert og forenklet
- Eksempeltall er fjernet fra del III (bilagene); i den grad det er behov for slike, er de tatt inn i veiledningen
Ellers er det kun foretatt noen mindre korreksjoner og justeringer.
1.4 Leserveiledning
Veiledningen er strukturert slik at hvert kapittel består av uthevete hovedpunkter ( ) som er beskrevet nærmere. Hensikten med dette er å gjøre veiledningen mer brukervennlig.
Dette dokumentet er en veiledning til ”Kontraktstandard for leveranse av programvare m. m.” (også kalt PS2000-kontraktsstandarden)
KPn
Detaljplanlegging / Analyse og design
KP2
KP1
Iterativ konstruksjonsfase
Løsningsbes- krivelsesfase
Testing
Utvikling
Progresjon
1.5 Beskrivelse av gjennomføringsmodellen
Behovsfase
Godkjennings- og avslutningsfase
HMP 0
Kontraktsinngåelse
HMP 1
Godkjent løsnings- beskrivelse
HMP 2
Leveranse klar til godkjenning
HMP 3
Godkjent leveranse
Den trinnvise gjennomføringsmodellen tilpasser seg erfaringer og endrede rammevilkår underveis i prosjektet
Gjennomføringsmodellen er egnet for større IT-systemutviklings- og systemleveranse- prosjekter
Leverandøren har leveranseansvaret også i en integrert samarbeidsmodell
Kontraktsstandarden som følger denne veiledningen, tar utgangspunkt i en trinnvis gjennomføringsmodell. Den forutsetter det som praksis ofte har vist; at rammebetingelser, behov og muligheter endres underveis. En slik gjennomføringsmodell ivaretar disse endringene, ved at prosjektet evalueres ved avslutningen av hvert trinn eventuelt for hver iterasjon, samtidig som neste trinn og iterasjon planlegges. Det forutsettes dermed et integrert
Gjennomføringsmodellen er basert på fire hovedfaser med tilhørende milepæler, hvor den første fasen definerer forutsetninger og rammebetingelser forut for kontraktsinngåelse, mens kontraktsfasene er oppdelt slik at det først utarbeides en løsningsbeskrivelse før selve arbeidet med leveransene utføres i iterasjoner med evaluering i kontrollpunkter. Deretter følger en overtagelsesfase for kunden, kalt godkjennings- og avslutningsfase. Gjennomføringsmodellen vil utgjøre et rammeverk som skal kunne anvendes uavhengig av verktøy og metode som benyttes for selve systemutviklingen.
Gjennomføringsmodellen er dokumentert i kontrakten for å sikre et enhetlig rammeverk for arbeidet med leveransen. Gjennomføringsmodellen legger opp til en samlet behandling av endringer, slik at de vurderees og eventuelt godkjennes i forbindelse med igangsetting av ny iterasjon. Leverandørens vederlag er basert på en avtalt målpris som kombineres med incentiver og sanksjoner tilknyttet leverandørens gjennomføring av prosjektet.
Kunden forplikter seg til aktivt å delta i arbeidet med leveransen og skal stille til rådighet ressurser og leveranser i henhold til en nærmere beskrivelse i kontrakten. Xxxxxx har videre ansvar for at egne leveranser ikke medfører at tredjeparts rettigheter blir krenket.
Det skal være mulig å benytte den omtalte gjennomføringsmodellen både for enkeltleveranser og samlede IT-systemleveranser, hvor både utstyr, utviklet programvare og standard programvare med tilpasninger inngår. Ved enkeltleveranser er kontraktsmodellen normalt kun aktuell når kriteriene for bruk av gjennomføringsmodellen er som beskrevet nedenfor.
Dersom slike leveranser innebærer oppdeling i separate delleveranser eller inkrementer, kan det tilrettelegges for en delvis overtagelse, for å muliggjøre innføring og implementering av disse før den avsluttende godkjenningsfasen. Etter slik delvis overtagelse må det spesifikt avtales hvilke forpliktelser, herunder ytelsesnivå, som skal gjelde utover utbedring av feil, frem til avsluttende godkjenning.
2 Kontraktsstruktur
2.1 Hovedstruktur
Kontrakten er delt inn i
Del I Kontraktsdokument
Del II Generelle kontraktsbestemmelser Del III Kontraktsbilag
Strukturmessig følger denne veiledningen samme rekkefølge som hovedkapitlene i de generelle kontraktsbestemmelsene. Veiledningen vil således være mest hensiktsmessig å lese sammen med disse. Enkelte underpunkter er ikke berørt der det anses at ytterligere forklaring ikke er påkrevet.
Kontraktsdokumentet som er forsiden med nøkkelinformasjon om kunde, leverandør og inngått kontrakt, er skilt ut som en egen del for å gi partene frihet til å velge form og innhold på dette overordnede dokumentet. Som et minimum må alle deler av kontrakten refereres og rangordningen mellom disse må beskrives. Kontraktsdokumentet utarbeides når partene har oppnådd enighet om kontraktsbestemmelsene.
Kontraktsbilagene, unntatt de to siste som er valgfrie, inneholder ferdigutfylt tekst som gir kontraktsmessige føringer for gjennomføring av arbeidet frem til en kontraktsleveranse.
Primært skal spesifikke forhold legges inn i forhåndsdefinerte tabeller. Der det ikke er hensiktsmessig med tabeller, er behov for utfylling markert med <kursiv og klammeparenteser> og eventuelt forslag til tekst.
Bilagsteksten må utfylles og gjennomgås grundig for å kunne benyttes til å regulere spesifikke kontraktsforhold. Merk at bilagsteksten på enkelte områder primært fungerer som en kryssreferanse fra de generelle kontraktsbestemmelser og som eksempel (i kursiv) for mulig innhold, ikke som en standard.
2.2 Bilagsstruktur
Følgende bilag er definert for å regulere spesifikke forhold knyttet til leveransene:
Kontraktsbilag | Tittel |
Bilag A | Behovsanalyse Inkluderer beskrivelse av kundens krav, behov og egne leveranser. I tillegg inkluderes leverandørens grove løsningsforslag, forutsetninger og forbehold, samt en usikkerhetsmatrise. |
Bilag B | Administrative bestemmelser Inkluderer beskrivelse av organisasjon, roller og nøkkelpersonell. I tillegg inkluderes krav til oppfølging og rapportering samt prosedyre for konflikthåndtering. |
Bilag C | Gjennomføring Inkluderer de sentrale, spesifikke forhold knyttet til gjennomføring, herunder metoder, verktøy, standarder og utviklingsmiljø i tillegg til detaljering av gjennomføringsmodellen. Fremdriftsplanen skal dokumenteres i dette bilaget. Videre inkluderes spesifikke forhold knyttet til endringsprosedyren. |
Bilag D | Vederlag Inkluderer kontraktsprisen, incentiv- og sanksjonsordninger og videre spesifikke betalingsbetingelser. |
Bilag E | Betingelser for garanti og vedlikehold Inkluderer forutsetninger og forpliktelser knyttet til garanti og senere vedlikehold. Avtale om vedlikehold skal være definert som en opsjon. |
Bilag F | Betingelser for rettigheter til programvare Inkluderer regulering av hvilken part som skal ha opphavsrett til den programvare som utvikles under denne kontrakten. Dersom kontrakten inkluderer levering av standard programvare, skal bruksrett for slik programvare være regulert i bilaget. |
Tittel | |
Bilag G (opsjon) | Betingelser for kildedepot av programvare Eventuelt kildedepot (ESCROW) skal være beskrevet med omkostninger og ansvar, eventuelt med avtaleregulering, signert av partene og depotagenten. |
Bilag H (opsjon) | Opsjoner Eventuelle opsjoner (utover vedlikehold) skal være beskrevet med eventuelt vederlag og skal være angitt med frist for utløsning. |
3 Forarbeid
3.1 Generelt
3.2 Behovsanalyse
Kunden må avklare mål, både i form av produktmål og gevinstmål (hva kunden ønsker å oppnå med kontraktsleveransen)
Kunden må deretter dokumentere behovene, helst slik at de kan benyttes som godkjenningskriterier
Kunden forutsettes å ha vært gjennom en måldefineringsfase hvor kunden har skissert hva som ønskes oppnådd med kontraktsleveransen og hvilke områder som bør inngå. Det forutsettes at de formål og krav som fremkommer av dette arbeidet, blir nedfelt i en behovsanalyse som kan inngå i Bilag A, ref. Del II punkt 3.1.
Behovene bør utformes slik at de også utgjør overordnede godkjenningskriterier, ref. Del II punkt 3.5.2. Generelle godkjenningskriterier bør involvere brukeraksept, brukergrensesnitt, beståtte funksjons-, system-, stress- og ytelsestester og lignende. Slike generelle godkjenningskriterier kan suppleres med å presisere hva som er absolutte krav og hvor alternative forslag er mulig i forhold til det behov som er beskrevet.
For å få definert fornuftige rammer bør kunden gjennomføre en ”kost/nytte”-analyse, eventuelt også utarbeide en plan for gevinstrealisering. Dette danner grunnlag for å definere de mest sentrale milepælene og avgrense funksjonalitet.
3.3 Usikkerhet
Usikkerhet blir definert og ansvar og tiltak blir fordelt mellom kunde og leverandør
Kunden bør vurdere hvilke leveranser som skal inkluderes under en og samme kontrakt
Kunden bør gjennomføre en usikkerhetsanalyse, som kan suppleres og kommenteres av leverandøren
Kunden oppdaterer usikkerhetsanalysen i hvert kontrollpunkt, som et grunnlag for detaljplanleggingen av neste trinn
Som et utgangspunkt bør leverandøren kunne ta hovedansvar for usikkerheten knyttet til gjennomføringen, mens kunden bør ta ansvar for usikkerheten knyttet til rammebetingelsene. Spesielt bør kunden vurdere hvilke leveranser som skal inkluderes under en og samme kontrakt. Ved å samle alle leveranser, både utstyr, lisenser og utviklet programvare, vil ansvar flyttes over på leverandøren som da vil måtte påta seg en koordinering og misligholdsrisiko på vegne av flere underleverandører, hvilket har en kostnadskonsekvens.
Dette må sammenholdes med kundens mulighet til å behandle de ulike leveranser uavhengig av hverandre.
Videre avklares hvilke tiltak som kan være aktuelle, i tillegg til hvem som har best forutsetning for å kunne håndtere de enkelte usikkerhetselementene. Den part som har best forutsetninger for å håndtere usikkerhetselementene, er den som har evne til å påvirke og kontrollere, men også den som kan fordele videre og iverksette tiltak for å redusere konsekvensene. I praksis er det også slik at den som har best forutsetninger for å håndtere usikkerhetselementene, kan beregne lavest tilleggskostnad for å ta risikoen.
De sentrale usikkerhetselementene avdekkes ved å gjennomføre en usikkerhetsanalyse. Selve usikkerhetsanalysen kan enten gjennomføres ved at leverandøren fyller ut en usikkerhetsmatrise, ref. Del II punkt 3.2.2, basert på kundens opprinnelige analyse, eller at analysen gjennomføres av partene som en avklaringsrunde i forkant av kontraktsinngåelsen. I usikkerhetsmatrisen skal de 10-15 viktigste usikkerhetselementene beskrives, kvantifiseres og mulige tiltak identifiseres.
Risikoer knyttet til bruk av denne kontraktsstandarden antas primært å være knyttet til:
- Evne til å etterleve prinsippene i kontraktene, herunder spesielt krav til oppfølging og samarbeid mellom partene
- Nivået på behovsanalysen og tilbyderes evne til å estimere på dette grunnlag
- Endringer i forhold til antall trinn og iterasjoner og derigjennom omfanget av gjenstående arbeid
- Finne riktig nivå på incentivmekanismene slik at de i praksis blir balanserte og hensiktsmessige
- Partenes tidligere kjennskap til og erfaring med kontraktsstandarden
Etter løsningsbeskrivelsesfasen utgjør ikke usikkerhetsmatrisen grunnlag for endringer til kontrakten, men manglende oppfyllelse av tiltakene kan fortsatt gi grunnlag for en endringsanmodning.
3.4 Utviklingsmiljø
Fordeler og ulemper knyttet til valg av ansvar for utviklingsmiljø må vurderes
Kunden må vurdere fordeler og ulemper med selv å tilby utviklingsmiljø, ref. Del II punkt
3.2.3. Fordelene er ofte knyttet til tettere og bedre kommunikasjon mellom kunde og leverandør i tillegg til bedre tilretteleggelse av testmiljø. Ulempene er potensielt et mer uklart ansvar for problemer i utviklingsmiljøet. Leverandøren kan da ikke holdes ansvarlig for svakheter eller mangler i utviklingsmiljøet. Dette må i så tilfelle beskrives nærmere i Bilag C.
3.5 Milepæler og fremdriftsplan
Kunden avklarer prosjektets hovedmilepæler, inkludert tidspunkt for når leveransen skal være klar til godkjenning
Det er nødvendig at kunden i tillegg til å vurdere sine behov og krav, analyserer tidsaspektet i et ”kost/nytte”-perspektiv. På denne bakgrunn kan milepæler defineres tidsmessig og legges inn i Bilag C, noe som bidrar til å klarlegge rammebetingelser for leveransene. Kunden må foreta en overordnet planlegging av hovedmilepæler som kan inngå i en tilbudsforespørsel og danne grunnlag for leverandørenes fremdriftsplan. Det anbefales normalt at relative datoer benyttes i perioden frem til kontraktsinngåelse.
Første hovedmilepæl vil være godkjenning av løsningsbeskrivelsen, ref. Del II punkt 3.3.1, jf. Bilag C. Neste hovedmilepæl er den som avslutter den trinnvise konstruksjonsprosessen og innebærer overgang til kundens godkjenningsprøver. Siste hovedmilepæl er kundens godkjenning og formelle overtagelse av leveransene, ref. Del II punkt 3.5.2. En mulig variant som kan være en følge av inkrementell utvikling, kan fordre at komponenter blir produksjonssatt underveis, det vil si før endelig godkjenning, men etter et gitt antall trinn, i forbindelse med et kontrollpunkt. Dette er benevnt som delvis overtagelse, ref. Del II punkt
3.4.6. Eventuelle krav til tidspunkter for delvis overtagelse og krav til omfang og kvalitet av leveransen, må da reguleres i Bilag B, C og D.
Det er ikke realistisk at alle trinn og iterasjoner er detaljplanlagt før kontraktsinngåelse, da omfanget og innhold i kommende trinn og iterasjoner skal justeres med bakgrunn i erfaringene slik de er evaluert i kontrollpunktene. Det bør derfor holde at leverandøren blir bedt om i Bilag C å legge frem en detaljert plan for førstkommende iterasjon i tillegg til at leverandøren må fremlegge en plan for førstkommende fase eller trinn (som etter kontraktsinngåelse er løsningsbeskrivelsesfasen).
3.6 Andre forhold knyttet til forarbeidet
Kunden må vurdere omfang og krav til incentivordninger
Kunden bør vurdere behovet for å få overdratt hele eller deler av opphavsretten til leveransen
Kunden må også vurdere å formulere eksplisitte krav i forbindelse med de valgfrie elementene i utkastene til bilag. Blant annet gjelder dette bruk av ekstern kvalitetssikring, betalingsbetingelser, lengde på garantiperioden, ytelsesnivå i garantiperioden, ansvar for installasjon og krav til eventuell vedlikeholdskontrakt.
3.7 Tilbudsprosessen
Kunden bør sende ut kontraktsbestemmelser med bilag sammen med tilbudsforespørselen for å få sammenlignbare og komplette tilbud
PS2000-kontraktsstandarden kan benyttes både av private og offentlige aktører.
Offentlige anskaffelser er regulert gjennom lov om offentlige anskaffelser med tilhørende forskrifter, som igjen er basert på EØS-rettslige bestemmelser, ref. forskrift om offentlige anskaffelser (xxx.xxxxxxx.xx/xxx-xxxx/xxxxx?xxxx/xx/xx/xx-00000000-0000.xxxx). Uavhengig av regelverket er det fordelaktig for alle parter at tilbud innhentes på et så komplett grunnlag som mulig. Dette løses best ved at kunden, sammen med tilbudsforespørselen, sender ut kontraktsbestemmelser med bilag som er utfylt så langt kunden har mulighet til. På denne måten vil leverandørenes tilbud bli lettere å sammenholde og forhåpentligvis mer komplette.
De utkast til bilag som er vedlagt PS2000-kontraktsstandarden, er i utgangspunktet forsøkt utfylt så komplett at kunden i første omgang kan nøye seg med å spesifisere og utdype de forhold som er behandlet i utkastene. I neste omgang skal tilbydere i liten grad behøve å gi ytterligere, separat informasjon, men konsentrere seg om å besvare spørsmål og krav direkte i bilagene, i tillegg til å planlegge, bemanne og prissette leveransen.
Flere av deltagerne i Dataforeningens faggruppe har for øvrig utarbeidet forespørselsdokumentasjon tilpasset PS2000-kontraktsstandarden og tilhørende underlag for anskaffelsesstrategi, evalueringsmodell og grunnlag for forhandlinger. Nedenfor følger noen anbefalinger som kan vurderes ved utarbeidelse av forespørsler.
Det finnes ingen spesifikk anvendelig bakgrunnsrett for systemutviklingsprosjekter. Det kreves derfor en god avtaleregulering
Bakgrunnsretten ved anskaffelser utgjøres i det alt vesentlige av den alminnelige avtale- og kjøpsrett. Imidlertid dekkes eksempelvis ikke systemutvikling av de samme regler som gjelder for kjøp av utstyr. Dette medfører et større behov for avtaleregulering enn hva tilfelle hadde vært dersom bakgrunnsretten hadde vært dekkende. Dette har bidratt til relativt omfattende forslag til bestemmelser i Del II.
3.7.2 Kvalifisering av tilbydere
Vurdér om kvalifisering er nødvendig. Dette er først og fremst aktuelt for å sikre at kun leverandører med relevant kompetanse, kapasitet og erfaring innleverer tilbud.
I henhold til forskrift om offentlige anskaffelser, skal interesserte tilbydere gis et visst antall dager på å melde sin interesse etter kunngjøring av kvalifiseringen.
Bruk mal for selve forespørselsdokumentet, og still krav til form og innhold på tilbudsdokumentet
Kriterier for valg av leverandør skal fremgå av forespørselsdokumentet Evalueringsprinsipper skal være fastsatt før tilbudene evalueres
Utarbeidelse av forespørsel i forbindelse med tilbudsinnhenting bør tilpasses valgt kontraktsstrategi. Det anbefales at det utarbeides og benyttes en mal for selve forespørselsdokumentet, slik at alle sentrale elementer blir ivaretatt. Kriterier for valg av leverandør skal fremgå av forespørselsdokumentet, eventuelt med prioritering. Det bør også stilles krav til form og innhold på de deler av besvarelsen som ikke direkte skal inngå som kontraktstekst, slik at tilbudene blir lett sammenlignbare.
For det offentlige vil det normalt gjelde visse frister for besvarelse av utsendt tilbudsinnbydelse. Inntil 6 dager før fristens utløp kan kunden sende ut eventuell tilleggsinformasjon. Slik tilleggsinformasjon skal ikke rokke ved de substansielle forhold ved tilbudsinnbydelsen.
De mottatte tilbud evalueres ut fra de definerte kriterier, og rangering av tilbudene foretas på dette grunnlag. Evalueringsskjemaer og rangeringskriterier bør være fastlagt før tilbudene evalueres. Pris bør vurderes separat, eventuelt av et eget evalueringsteam. Eventuelle nødvendige avklaringer anbefales foretatt med 2 til 3 av de best rangerte tilbyderne, avhengig av konkurransesituasjon og tidspress. Muligheten for å benytte reelle forhandlinger er behandlet nedenfor.
Åpent eller begrenset anbud gir ikke rett til forhandlinger, kun avklaringer
Konkurranse med forhandlinger; anbefales for større systemutviklingsprosjekter når spesifikasjonene ikke kan fastsettes nøyaktig
Forskriften om offentlige anskaffelser innebærer at muligheten til å forhandle med tilbyderne er begrenset, slik det er beskrevet i det følgende. Rett til forhandlinger med tilbyderne er utelukket dersom åpen eller begrenset anbudsform i utgangspunktet er valgt, med det unntak som oppstår dersom ingen av de mottatte tilbud kan aksepteres.
For at det offentlige skal kunne benytte kjøp etter forhandlinger, må tjenestene, dvs. spesifikasjon av systemet, ikke kunne beskrives så nøyaktig at valg av leverandør basert på en åpen eller begrenset anbudsrunde kan benyttes, det vil si at:
”Tjenesteytelsene som skal leveres er av en slik art at det ikke i tilstrekkelig grad kan fastsettes nøyaktige spesifikasjoner til at kontrakten kan tildeles gjennom valg av det
bestemte tilbud, i samsvar med reglene som gjelder for åpen eller begrenset anbudskonkurranse.”
I hvilken grad denne begrunnelsen kan benyttes, må vurderes i det enkelte tilfelle, men i praksis vil det være slik at det ofte er aktuelt å benytte PS2000-kontraktsstandarden nettopp i situasjoner hvor det er nødvendig med kjøp etter forhandling.
Informer tilbydere som ikke ble valgt Ajourfør anskaffelsesprotokoll
Kontrakten inngås mellom partene når beste tilbyder er valgt ut fra forhåndsdefinerte kriterier, eventuelt etter avsluttede avklaringer og forhandlinger. Det bør utarbeides to originaler hvor alle sider paraferes av en representant fra hver av partene. De tilbydere som ikke ble valgt, skal informeres om utfallet og har på forespørsel rett til en begrunnelse. I henhold til forskrift om offentlige anskaffelser skal i tillegg valg av leverandør kunngjøres.
Det føres en anskaffelsesprotokoll slik at hele prosessen og foretatte valg og prioriteringer kan dokumenteres i etterkant.
4 Organisering og arbeidsform
Arbeidet organiseres som et prosjekt med deltagere fra begge parter, men hovedansvaret er tillagt leverandøren
Leverandørens prosjektleder rapporterer til kundens prosjektleder, som igjen rapporterer til en koordineringsgruppe med representanter fra begge parter
Koordineringsgruppen skal bestå av partenes prosjektansvarlige og ledes av kundens prosjektansvarlige
Partenes prosjektledere har møterett og møteplikt i koordineringsgruppen
Løpende, intern kvalitetssikring skal inngå i oppdraget, mens ekstern kvalitetssikring kan avtales i tillegg
Leverandøren og kunden skal samarbeide for å oppnå en mest mulig effektiv prosess, ved at det opprettes en organisasjon for gjennomføring som beskrevet i det følgende.
Arbeidet organiseres som et prosjekt. Det vil si at det etableres en koordineringsgruppe med ansvarlige representanter fra begge parter og som ledes av kunden, ref. Del II punkt 2.1.1. I tillegg utpeker hver av avtalepartene en prosjektleder som gis ansvar, myndighet og ressurser til å gjennomføre prosjektoppdraget på vegne av parten i henhold til beskrevet mandat, med referanse til kontrakten og annen underliggende styrende dokumentasjon, ref. Del II punkt 2.1.2 og 2.1.4.
Erfaringer fra komplekse IT-leveranseprosjekter viser at aktiv kundemedvirkning (både administrativt personell og brukere) er en forutsetning for et vellykket prosjekt. Ved et integrert samarbeid arbeider kunde og leverandør innenfor samme prosjektorganisasjon. Faremomentet ved dette er at ansvars- og oppgavedelingen kan oppleves som uklar. Kundens medvirkning skal foregå på en slik måte at ansvaret for leveransen fortsatt ligger hos leverandøren.
I tillegg til en slik felles koordineringsgruppe, vil ofte både kunden og leverandøren ha interne styringsgrupper. Disse brukes til å behandle forhold som partene har styringsrett over
og bør derfor avholdes separat fra, men gjerne i tilknytning til, møtene i koordineringsgruppen.
Modellen legger opp til et integrert samarbeid på to nivåer; på koordineringsgruppenivå og på prosjekt- og arbeidsgruppenivå. Brukermedvirkning er en sentral suksessfaktor i iterativ eller trinnvis systemutvikling, og det vil derfor være behov for å etablere arbeidsgrupper som vurderer spesifikasjoner, prototyper og testresultater. For at dette skal kunne fungere godt, må deltagerne i slike grupper kjenne prosjektets målsetting og rammebetingelser, samt gjennomføringsmodellen og egne ansvarsområder og oppgaver.
Koordineringsgruppen kan ikke påvirke rettigheter og forpliktelser i forhold til kontrakten, men kan fungere som en møteplass for kontraktens parter, hvor gjennomføring, fremdrift, kostnader og kvalitet i leveransene behandles. Endringsordre kan også behandles her, men beslutning om endringsordre skal formelt tas av kunden (for eksempel gjennom dennes interne styringsgruppe). Dette gjelder dersom koordineringsgruppen ikke har en eksplisitt fullmakt.
Ved at koordineringsgruppen møtes jevnlig og på bakgrunn av statusrapporter fra prosjektet, vil den kunne fungere som en effektiv pådriver for prosjektet.
Løpende kvalitetssikringsaktiviteter skal fremgå av Bilag B og skal inngå i leverandørens ansvar. Partene kan bli enige om i tillegg å utnevne en person eller et selskap som ekstern kvalitetssikrer for å ivareta ansvaret for overordnet kvalitetssikring. Vedkommende skal rapportere til koordineringsgruppen, ref. Bilag B.
5 Gjennomføring
5.1 Innledning
Gjennomføringsmodellen som ligger til grunn for kontrakten innebærer at leveransen deles i 4 faser. Behovsfasen er den innledende fasen (før kontraktsinngåelse) hvor kunden skal analysere og spesifisere behov for, formål med og krav som skal dekkes av leveransen. Etter inngåelse av kontrakten igangsettes fasen for utarbeidelse av løsningsbeskrivelsen. Når løsningsbeskrivelsen er godkjent, gjennomføres konstruksjonsfasen i form av trinnvis utvikling, sammensetning og brukertilpasning av leveransen. Leveransen avsluttes med godkjenningsfasen ved gjennomføring av godkjenningsprøver for å dokumentere at leveransen dekker de definerte behov og spesifikasjoner.
5.2 Resultat av behovsfasen
Krav og behov skal prioriteres og listes i Bilag A Usikkerhetsanalyse skal gjennomføres og dokumenteres Utviklingsmiljø skal avklares
Overordnet fremdriftsplan skal inkluderes
Prosessen knyttet til punktene nedenfor er behandlet under punkt 3 om forarbeid. I dette kapittelet blir primært resultatet av arbeidet behandlet, da dette er grunnlaget for selve kontraktsgjennomføringen.
Godkjennings- og avslutningsfase
KPn
Detaljplanlegging / Analyse og design
KP2
KP1
Iterativ konstruksjonsfase
Testing Utvikling
Behovsfase
Løsningsbes- krivelsesfase
Progresjon
HMP 0
Kontraktsinngåelse
HMP 1
Godkjent løsnings- beskrivelse
HMP 2
Leveranse klar til godkjenning
HMP 3
Godkjent leveranse
Kundens behov for, formål med og krav til leveransen fremgår av behovsanalysen som skal inngå i Bilag A, ref. Del II punkt 3.2.1. Prosessmodellering vil være et hensiktsmessig utgangspunkt for å beskrive hvilke funksjoner leveransen skal støtte. Prosessmodellene bør som et minimum være supplert med beskrivelse av brukssituasjoner. Det er også hensiktsmessig at de overordnede og de spesifikke kravene er prioritert og ført inn i en tabell i bilaget. Dette muliggjør definering av overordnede godkjenningskriterier i tillegg til at mulige leverandørers svar eller kommentarer på eventuell tilbudsforespørsel enkelt kan inkorporeres i kontrakten.
Leverandørens eventuelle utdypende kommentarer skal i tillegg til forutsetninger og forbehold som leverandøren tar, tas inn i Bilag A. Slike utdypende kommentarer bør tas inn i en grov løsningsbeskrivelse fra leverandøren. Denne grove løsningsbeskrivelsen bør være en del av det tilbud som leverandøren utarbeider, ref. punkt 3.7.3, og som kunden kan benytte til å evaluere leverandørens forståelse av kundens behov. Denne løsningsbeskrivelsen skal deretter kunne bearbeides etter kontraktsinngåelse i løsningsbeskrivelsesfasen.
Både kundens og leverandørens vurderinger og evaluering av usikkerhet skal være inkludert i kontraktens usikkerhetsmatrise, ref. Del II punkt 3.2.2. Som et minimum bør følgende elementer være vurdert:
- Partenes forståelse av målsettinger, behov og krav
- Partenes kjennskap til hverandre
- Forutsigbarhet og avgrensning
- Kompleksitet; både teknologisk og integrasjonsmessig
- Avhengighet til tredjeparter
- Tilgjengelig tid i forhold til omfang
- Fleksibilitet og smidighet
- Kompetanse innenfor aktuelle fagdisipliner
- Risikovillighet og -mulighet
Eventuelle kostnader til anskaffelse og drift av maskin- og programvare (utviklingsmiljø) må avklares både i forhold til ansvar for drift og kostnadsdekning, ref. Del II punkt 3.2.3. Videre må det settes en grense for hvor stor andel nedetid som er akseptabelt for leverandøren. En grense på 2-5 % vil være innenfor normalen.
På bakgrunn av de hovedmilepælene, kontrollpunktene og øvrige milepæler som fremgår av Bilag C, må leverandøren utarbeide en fremdriftsplan som beskriver hovedaktivitetene i prosjektet, med avhengigheter og ressurser knyttet til disse, ref. Del II punkt 3.2.4.
5.3 Gjennomføringsfasen
Partene skal under ledelse av leverandøren først utarbeide en løsningsbeskrivelse
Deretter gjennomføres utviklingsarbeidet i iterasjoner og/eller inkrementer (heretter kalt trinn)
Trinn og iterasjoner muliggjør stadige forbedringer i konstruksjonsfasen
Endringer og beslutninger om gjennomføring av neste trinn, vurderes i hvert kontrollpunkt hvor utført arbeid evalueres
KPn
Detaljplanlegging / Analyse og design
KP2
KP1
Iterativ konstruksjonsfase
Behovsfase
Løsningsbes- krivelsesfase
Testing
Utvikling
og
avslut
ningsfase
HMP 0
HMP 1
HMP 2
HMP 3
Godkjent løsnings- beskrivelse
Leveranse klar til godkjenning
Godkjent leveranse
Gjennomføringen består av en innledende fase for utarbeidelse av løsningsbeskrivelse og deretter selve konstruksjonsfasen som utføres i trinn med et minimum antall iterasjoner og/eller inkrementer, definert i Bilag C.
Prioriteringen av krav og behov i behovsanalysen skal medvirke til at sentral funksjonalitet blir realisert i de første iterasjoner.
En løsningsbeskrivelse for hele leveransen utarbeides i første fase etter kontraktsinngåelse for å gi større trygghet rundt den behovsanalysen som kunden har lagt frem, ref. Del II punkt
3.3.1. Løsningsbeskrivelsen innebærer en grundig gjennomgang av kundens behovsanalyse. Spesifikasjonen kan utarbeides i form av utdypning av brukssituasjoner, eventuelt supplert med objekt- og klassemodeller eller lignende. Løsningsbeskrivelsen skal bygge på den grove løsningsbeskrivelsen som er inntatt i Bilag A, men må likevel først og fremst verifisere at behov og krav i behovsanalysen lar seg dekke på en tilfredsstillende måte.
Her kan for eksempel regulering av overordnet design, prototyper, oppdatering av datamodell, etablering av prioriteringslister og revurdering av oppdeling i trinn inngå.
Arbeidet med løsningsbeskrivelsen kan medføre behov for endringer som kan håndteres i tråd med andre endringer til kontrakten, ref. Del II punkt 3.3.2, men gir også kunden mulighet til å avbestille hele leveransen dersom løsningsbeskrivelsen avviker mer enn en definert grense fra definerte behov og krav og øvrige rammer i kontrakten. En normal grense for slike endringer vil være 4-6 %, hvor andelen bør være lavere jo større omfanget er. Med unntak av ved mislighold, vil leverandøren da kunne kreve betaling, begrenset av estimatene i Bilag D.
Det ovenstående innebærer at resultatet av løsningsbeskrivelsen reguleres av de samme mekanismer som kontrakten for øvrig, men med en egen avbestillingsregulering. Dette vil igjen si at dersom omfanget av arbeidet endres som følge av løsningsbeskrivelsen, må endringsmekanismene benyttes.
Godkjenning av løsningsbeskrivelse bør formaliseres, minimum i form av strukturerte gjennomganger av hele løsningsbeskrivelsen, med representanter både fra kunden og leverandøren til stede. Løsningsbeskrivelsen erstatter deretter tilsvarende deler i behovsanalysen og kontrakten for øvrig, så fremt dette fremgår eksplisitt av løsningsbeskrivelsen, med spesifikk henvisning til opprinnelig kontrakt.
Progresjon
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. Med tilleggskostnader menes investeringer som leverandøren har foretatt, og som er en direkte og nødvendig kostnad knyttet til arbeidet med å oppfylle kravene i kontrakten. Slike tilleggskostnader skal kunne dekkes dersom kostnadene fremgår av kontrakten, og leverandøren ikke kan gjenbruke disse investeringene i andre sammenhenger, ref. Del II punkt 3.3.2.
Leverandøren lager en detaljplan for forestående trinn Detaljert analyse og design foretas på nødvendige områder
Prototyper og ferdige komponenter presenteres for kunden i henhold til kontraktens krav og leverandørens metodikk
Leverandøren tester den delen av leveransen som er utviklet i trinnet i samarbeid med kunden
Kontrollpunkt benyttes for å kunne justere kursen og sikre måloppnåelse Konsekvenser ved delvis overtagelse må avklares
5.3.3.1 Detaljplanlegging / Analyse og design
Da det kun foreligger en grovplan fra forrige trinn (med unntak av ved første trinn) er det nødvendig med en gjennomgang og detaljering av arbeidet for hvert trinn, ref. Del II punkt
3.4.1. Detaljplanleggingen må reflektere prinsipper for utviklingen slik det er dokumentert i Bilag C.
Videre må partene gjennomgå og analysere de områder som i løsningsbeskrivelsen ikke er detaljert nok beskrevet. Der det er nødvendig, må det utarbeides et detaljert design. I tillegg må det tas høyde for utvikling av objekt- og klassemodeller i den grad det er nødvendig og ikke utført i tidligere fase.
Leverandøren må i Bilag C få anledning til å utdype hvordan arbeidet med leveransen skal gjennomføres, ref. Del II punkt 3.4.2. Leverandøren kan her dokumentere hvordan egnede utviklingsmetoder og -verktøy skal benyttes.
Prototyper og komponenter som utvikles bør demonstreres og/eller presenteres kunden straks de foreligger. Utviklingen kan skje ved å benytte beskrivelse av brukssituasjoner. Eventuelt foretas brukertilpasning på dette grunnlag. Arbeidsgruppene som er opprettet skal muliggjøre dette. Etter tilbakemeldinger og eventuelle justeringer skal nye forslag legges frem, eventuelt avtales løst gjennom ny iterasjon.
For kvalitetssikring av resultatene benyttes leserunder, strukturerte gjennomganger eller lignende teknikker, eventuelt også brukervennlighetstester, som da bør være beskrevet i Bilag
C. Leverandøren må i tillegg gjennomføre kodegjennomganger som bør være beskrevet i Bilag C.
5.3.3.3 Testing og feilretting
Leverandøren skal, som avslutning av hvert trinn, gjennomføre en test av den del av leveransen som er utviklet i trinnet i samarbeid med kunden, ref. Del II punkt 3.4.3. Detaljeringsgrad på testingen skal i utgangspunkt være økende for hvert trinn.
Leverandøren skal i siste trinn minimum gjennomføre en integrasjons- og systemtest basert på utarbeidede testspesifikasjoner og fremlegge en protokoll som viser resultatet av systemtesten. Antall avdekkede feil følges opp og skal loggføres, da omfang og status knyttet til feilsituasjonen kan ha kontraktsmessige konsekvenser. Krav til integrasjons- og systemtest må være beskrevet i Bilag C, herunder hvilke krav det skal være til maksimalt antall gjenstående feil. Dette er i Bilag C beskrevet som inngangskriterier til godkjenningsprøven, ref. punkt 5.4.1. Plan for utbedring av de gjenstående feilene skal også utarbeides av leverandøren.
Leverandøren skal utarbeide testspesifikasjoner som kunden skal godkjenne. Kunden kan nekte å godkjenne dersom testspesifikasjonene er ufullstendige eller feilaktige i forhold til løsningsbeskrivelsen. Kunden kan velge å bistå leverandøren i arbeidet med testspesifikasjonene for å bidra til bedre bruksforståelse hos leverandøren. Det er likevel viktig at leverandøren fortsatt beholder fullt ansvar for gjennomføringen og resultatet av testene.
Som siste aktivitet i hvert trinn skal kunden evaluere gjennomføringen av trinnet og legge en grov plan for neste trinn, ref. Del II punkt 3.4.5. Generelt bør partene legge opp til et fast, avtalt mønster for kontrollpunktperioden, slik at begge parter har klare oppgaver i perioden og bidrar til at den kan gjennomføres med minst mulig tidstap.
Beslutninger om eventuelle endringsordre skal tas på dette tidspunktet på bakgrunn av oppsamlede endringsanmodninger. I denne sammenheng er nedprioritering av kontraktsinnhold, i den forstand at deler utelates, også å regne som endringsordre med negativt omfang. For ikke å forsinke kontrollpunktperioden, er det viktig at forberedelser i form av behandling av endringsanmodningene har pågått i parallell, det vil si i løpet av trinnet, selv om endelig godkjenning formelt sett ikke bør skje før i kontrollpunktet.
Fremdriftsplanen skal oppdateres i forhold til eventuelle godkjente endringsordre. Videre skal partene i fellesskap gjennomgå og oppdatere usikkerhetsmatrisen, uten at dette skal påvirke pris og incentiver, det vil si gi grunnlag for endringsordre. Kunden skal godkjenne planen for kommende trinn.
Det er viktig å arbeide effektivt både på kundens og leverandørens side i forbindelse med kontrollpunktet, slik at det ikke oppstår forsinkelser og unødig dødtid for prosjektets personell. I størst mulig grad bør kundens evaluering av gjennomført trinn og leverandørens planlegging av neste trinn gå i parallell.
Kunden kan i kontrollpunktene velge å avslutte arbeidet før alle trinn er gjennomført ved å fremsette en avbestilling. Dette gjelder kun mens det fortsatt gjenstår arbeid med leveransen, slik at leveransen ikke vil bli komplett levert og godkjent i henhold til kontrakten.
Enkelte trinn kan representere komponenter som kan regnes som ferdig utviklede og som kunden kan ønske å produksjonssette. Dette er spesielt aktuelt i forbindelse med inkrementell systemutvikling. Kunden har rett til å gjennomføre deler av godkjenningsprøven knyttet til slike komponenter, uten at dette skal regnes som en endelig godkjenning, ref. Del II punkt
3.4.6. Spesielle krav knyttet til slik delvis godkjenning må da fremgå av Bilag B, C og D. Særlig må utbedring av feil og videreutvikling knyttet til produksjonssatte komponenter vurderes. I tillegg må bruk av maskinmiljø, spesielt i forbindelse med konfigurasjonsstyring, vurderes i en slik situasjon.
Disse tjenestene kan leveres både i og utenfor konstruksjonsfasen, selv om de i forhold til innholdsfortegnelsen i Del II inngår som øvrige ytelser under konstruksjonsfasen.
Kunden er ansvarlig for å klargjøre og vedlikeholde test- og driftsmiljø slik at installasjon kan foretas i dette miljøet.
Leverandøren plikter å gi kunden den nødvendige opplæring
Leverandøren skal utarbeide systemdokumentasjon og annen dokumentasjon
Kunden er ansvarlig for å klargjøre og vedlikeholde test- og driftsmiljø slik at installasjon kan foretas i dette miljøet, ref. Del II punkt 3.4.8.1. Ansvaret for installasjoner må avklares.
Leverandøren plikter å gi kunden opplæring slik at kunden kan utnytte leveransen, ref. Del II punkt 3.4.8.2. Opplæringen bør foretas i forbindelse med testfasene slik at kunden selv blir i stand til å gjennomføre tester og evaluere utført arbeid.
Leverandøren skal utarbeide systemdokumentasjon og overordnet bruker- og driftsdokumentasjon, ref. Del II punkt 3.4.8.3. Med overordnet dokumentasjon menes den struktur og det innhold som leverandøren er best egnet til å beskrive. Brukerdokumentasjonen bør også være tilgjengelig i form av ”on-line”-hjelp på skjerm. Kunden må i Bilag A ha vurdert krav som skal stilles til dokumentasjonen.
Eventuell konvertering av data fra andre IT-systemer hos kunden skal avtales i Bilag A, eller som en opsjon i Bilag H, ref. Del II punkt 3.4.8.4. Behov for opprydning i eksisterende data for å sikre korrekt konvertering må være vurdert av kunden og være beskrevet eller avtalt separat.
5.4 Godkjennings- og avslutningsfase
Når leveransen regnes som ferdig og komplett utviklet, skal kunden gjennomføre godkjenningsprøver med støtte fra leverandøren
Leveransen skal avsluttes med en prosjektevaluering som begge parter er forpliktet til å delta i
KPn
Detaljplanlegging / Analyse og design
KP2
KP1
Iterativ konstruksjonsfase
Løsningsbes- krivelsesfase
Testing
Utvikling
og
avslu gsfase
tnin
HMP 0
HMP 1
HMP 2
HMP 3
Progresjon
Kontraktsinngåelse
Godkjent løsnings- beskrivelse
Leveranse klar til godkjenning
Godkjent leveranse
Kunden skal gjennomføre godkjenningsprøver med støtte fra leverandøren, ref. Del II punkt
3.5.1. En godkjenningsprøve skal omfatte funksjonelle tester, ytelsestester og andre tekniske tester som sikrer at leveransen oppfyller kravene i løsningsbeskrivelsen, slik at den kan overtas og settes i produksjon av kunden. Kriterier for antall avdekkede feil og antall gjenstående feil må være definert for objektivt å kunne avgjøre om leveransen skal kunne godkjennes eller ikke, ref. Del II punkt 3.5.2. Disse kriteriene kan kontrolleres på ulike stadier i godkjenningsprøven, og er definert som inngangskriterier, avbruddskriterier, forlengelseskriterier og avsluttende godkjenningskriterier. Det er også avgjørende at det er kvalitet på leverandørens feilretting, noe som håndteres underveis gjennom avbruddskriteriene. Kriteriene kan detaljeres ytterligere etter kontraktsinngåelse, men da må det avtales en frist for når slike mer spesifikke kriterier skal foreligge.
I den grad det i løsningsbeskrivelsesfasen er utarbeidet krav til løsningen som også kan fungere som operative godkjenningskriterier, er dette en fordel, da det vil forenkle verifikasjonen av leveransen.
Leverandøren skal utover avtalt dokumentasjon, gi kunden innsyn i all informasjon som er produsert som et resultat av leveransen, herunder korrespondanse som kunden kan ha nytte av for å dokumentere leveransen, ref. Del II punkt 3.5.3.
Leveransen skal avsluttes med en prosjektevaluering som begge parter er forpliktet til å delta i, i form av et avsluttende møte, uten at dette skal medføre noe krav om tilleggsvederlag.
Referat fra et slikt avsluttende møte skal signeres av begge parter, eventuelt med forbehold.
Leverandøren skal i en avgrenset periode, etter at leveransen er godkjent og overtatt av kunden, garantere for at leveransen fungerer i henhold til de avtalte godkjenningskriterier, ref. Del II punkt 3.5.4. I denne perioden har leverandøren ansvar for å rette alle feil som avdekkes, ref. punkt 8.2. Denne fasen er også separat priset, ref. punkt 6.1. Vederlaget for garantiperioden vil være avhengig av lengden, som normalt vil være fra 3 til opp mot 12 måneder.
Det er verdt å merke seg at dersom kunden enten ønsker en annen form for garantiperiode eller har ytterligere betingelser og krav knyttet til leveransen etter godkjenning, må det inngås en vedlikeholdskontrakt, eller avtales slike betingelser og krav i Bilag E, som premisser for den fremtidige vedlikeholdskontrakten. Slike krav kan også inneholde sanksjoner knyttet til et definert antall feil avdekket i garantiperioden.
5.5 Endringshåndtering
Kun mindre endringer (endringer uten konsekvens for tid og kostnader) håndteres innenfor et trinn
Større endringer samles opp og håndteres i kontrollpunktet. Iverksettelsen av godkjente endringsordre vil skje i et senere trinn
Omtvistede endringsordre følger en avtalt prosess, slik at fremdriften i oppdraget sikres
Endringshåndtering er gitt en omfattende regulering i kontrakten da det erfaringsmessig oppstår en rekke problemer knyttet til endringer, ref. Del II punkt 3.6. Hovedpunktene knyttet til denne kontraktsstandardens endringshåndtering er derfor kun listet opp ovenfor. Partene må avtale en generell frist for hvor raskt endringsanmodninger bør konsekvensutredes og besvares av leverandøren. Normalt vil en slik frist være 1-2 uker.
Behandling av endringsanmodninger under kontrollpunktene er behandlet i punkt 5.3.3.4.
6 Økonomiske vilkår
6.1 Generelt
Incentivordninger bør benyttes for å regulere konsekvensene av usikkerheten som er avdekket gjennom foretatte usikkerhetsanalyser, som er dokumentert i Bilag A. I tillegg er intensjonen at incentivordninger vil virke motiverende og således bidra til raskere og billigere gjennomføring. Det er i kontraktsbestemmelsene lagt opp til ulike incentivordninger på ulike områder, basert på gitte forutsetninger. Forutsetningen for å oppnå incentiver er primært knyttet til at oppdraget gjennomføres uten å bli avbrutt eller avbestilt.
Figuren nedenfor viser noen av begrepene i sammenheng. Forklaringer er gitt under. Denne figuren fokuserer på hvordan et helhetsbilde av kostnadene i prosjektet er bygd opp.
Sannsynlighet
A: Leverandørens kostnadsestimat
B: Målpris (M) (A+påslag for usikkerhet) C: Nedre tak (M-X)
D: Øvre tak (M+X)
100%
Kostnader
Kurven viser akkumulert sannsynlighet for ikke å overskride kostnadene. Den kan således benyttes til å fastlegge forventede kostnader og til å vurdere størrelsen på marginene.
Leverandørens anslag bør være en basiskalkyle uten påslag for usikkerhet, kalt kostnadsestimat (A) for løsningsbeskrivelses- og konstruksjonsfasen. Dette kostnadsestimatet skal være basert på leverandørens mest realistiske anslag for antall timer som vil medgå til å gjennomføre leveransen, eksklusive arbeid i godkjennings- og garantiperioden, utregnet med angitt gjennomsnittlig timerate. Utarbeidelse av løsningsbeskrivelsen inngår da i kostnadsestimatet. Andelen for slik utarbeidelse bør være lav, slik at leverandøren ikke spekulerer i å tre ut av kontrakten etter denne fasen i tilfelle det avdekkes at omfanget er større enn forventet.
Målprisen er leverandørens kostnadsestimat pluss påslag for usikkerhet (B). Målprisen representerer således kostnader som forventes å påløpe, gitt at konsekvensen av usikkerheten inntrer. Normalt vil en slik målpris være på et nivå som med minst 50 % sannsynlighet vil være den faktiske kostnaden. Dette blir håndtert ved et prosentpåslag for usikkerhet, hvor størrelsen på påslaget avhenger av hvilken usikkerhet som knytter seg til kalkylen. Størrelsen på påslaget skal være begrenset til å tilsvare den usikkerhetsmargin som er en direkte følge av manglende presisjonsnivå i behovsanalysen i Bilag A, kombinert med den usikkerheten som er synliggjort gjennom usikkerhetsmatrisen i samme bilag.
I området mellom ”Nedre tak”(C) og ”Øvre tak” (D) kan eventuelle underskridelser eller overskridelser fordeles etter en på forhånd avtalt fordelingsnøkkel. Denne fordelingsnøkkelen er beskrevet nærmere nedenfor.
I perioden fra kunden overtar ansvaret for oppfølgingen av arbeidet, det vil si i godkjenningsprøven og etterfølgende garantiperiode, er det valgt en fastprismodell, beregnet
Det er videre viktig å være klar over at større leveranser kan gå over flere år og at det da i Bilag D kan være avtalt en regulering av timerater i kontraktsperioden. Regulering av timerater innebærer at det må foretas foreløpige avregninger basert på timeforbruk frem til regulering foretas, multiplisert med gjeldende timerater. Målprisen må i forbindelse med en slik regulering justeres tilsvarende for den andel av arbeidet som gjenstår.
6.2 Incentiv- og sanksjonsordninger
Leverandørens vederlag skal i Bilag D være skilt i fastpriselementer og elementer som skal være underlagt incentivordningene, det vil si de deler som skal utføres som timebasert arbeid, ref. Del II punkt 4.1. Det er de sistnevnte delene som inngår i beregning av målpris.
Målprisen skal kombineres med økonomiske incentiver og sanksjoner basert på resultatet av usikkerhetsmatrisen som er beskrevet i punkt 3.3. Målprisen er i utgangspunktet å betrakte som en fast pris for utførelse av leveransen og som vil bli endret ved incentiver, sanksjoner og eventuelle endringsordre. Prisnivået kan, slik det er vist nedenfor, endres betydelig ved å bruke ulike fordelingsnøkler.
Prinsippene for økonomiske incentiver og sanksjoner som er beskrevet i det etterfølgende, er todelt; henholdsvis knyttet til kostnad (vederlaget), ref. Del II punkt 4.2.1, og tid, ref. Del II punkt 4.2.2.
6.2.1 Incentiver og sanksjoner knyttet til vederlaget
Gevinstdeling ved besparelser kan være en motivasjon til økt innsats
Incentivordning kan gi økte indirekte kostnader i form av økt behov for oppfølging av kvaliteten på leveranser og delleveranser
Ulike incentivordninger som kan etableres ved å benytte ulike fordelingsnøkler slik det er beskrevet i Bilag D, er illustrert i følgende figur:
Ince n tiv (L evera ndør)
c*
b*
a* N e dre ta k (M -X )
Ko stnad se s tim a t base rt på t im e r
Må lp ris (M )
Øv re ta k (M + X )
L e verandøre ns reelle kostnad
a basert på tim efo rbruk
Påslag
S anksjon (L e verandør)
b
F astprislinje
c
Den vertikale aksen angir størrelsen på leverandørens incentiv/sanksjon, mens den horisontale aksen angir leverandørens kostnader basert på timeforbruk. Utgangspunktet for incentivene er målprisen (M) som er summen av leverandørens kostnadsestimat, basert på forhåndsberegnet gjennomsnittlig timerate, pluss et påslag for usikkerhet som er avdekket gjennom usikkerhetsanalyser og dokumentert i Bilag A. Overskridelser og underskridelser fordeles mellom partene etter en avtalt fordelingsnøkkel, eventuelt innenfor en grense/tak (X) i forhold til målpris (M).
Kunden må i tilbudsforespørselen, blant annet på bakgrunn av sin initielle usikkerhetsanalyse, ref. punkt 3.3, ta stilling til hvor grensen (X) skal gå, eksempelvis i prosent i forhold til målpris og videre hvordan fordelingsnøkkelen bør være. Avhengig av valgt fordelingsnøkkel vil grensen være en indikator for usikkerhet. Fordelingsnøkkelen er utdypet nedenfor.
Dersom fordelingen er 0/100 for henholdsvis leverandør og kunde, vil kompensasjonsformatet være i henhold til medgåtte kostnader (langs horisontal akse). Dersom fordelingsnøkkelen er 100/0 for henholdsvis leverandør og kunde, vil kompensasjonsformatet være fastpris (illustrert ved den stiplede fastprislinjen). Ved å definere eventuelle tak og fordelingsnøkler vil ulike incentivordninger kunne realiseres, illustrert ved linjen b*-b, med variantene a og c. Fem av disse variantene av incentivordninger er regnet som de mest realistiske og er følgelig eksemplifisert i et vedlegg til dette dokumentet.
Som det fremgår av figuren deles underskridelser og overskridelser mellom partene etter en avtalt delingsnøkkel (her antatt til 50/50, linje b). Incentiver og sanksjoner er her i utgangspunktet balansert, men når en avtalt grense for overskridelse er nådd (M+X), er det lagt opp til 3 ulike alternativer:
- Overskridelsene antas å skyldes uklare eller vanskelig oppnåelige mål, noe som da ikke lenger kan lastes leverandøren. Leverandøren får derved dekket alt overskytende timeforbruk til normal timepris. Det blir således satt en tapsgrense for leverandøren.
- Overskridelser deles fortsatt etter samme nøkkel, dvs. at det ikke er definert noe tak eller grense (b).
- Leverandøren får ikke dekket noen kostnader for gjenstående arbeid på leveransene, da det antas at leverandøren ikke har oppfylt sine forpliktelser med det arbeid som er utført. (M+X) blir dermed en øvre grense og således en fastpris (c).
Tilsvarende er det lagt opp til 3 ulike alternativer for incentivordninger for tilfeller der Leverandørens reelle kostnad er lavere enn (M-X):
- Underskridelsen antas å skyldes forhold som ligger utenfor leverandørens ansvar, slik at incentivene begrenses til et nivå (a*).
- Underskridelsen deles fortsatt etter samme nøkkel, dvs. at det ikke er definert noen grense for incentiver (b*).
- Leverandøren får utbetalt (M-X) selv om reelle kostnader er lavere. Dette blir dermed en nedre fastpris (c*).
Konsekvenser ved incentivordninger knyttet til kostnader kan være:
Positive:
- For leverandøren: Mulighetene for gevinstdeling ved besparelser kan i seg selv være en motivasjon for økt innsats.
- For kunden: Muligheter til å spare kostnader i forhold til målpris.
Negative:
- Økte indirekte kostnader i form av økt behov for oppfølging av kvaliteten på leveranser og delleveranser.
Dersom målprisen viser seg å være vanskelig å oppnå, kan incentivordningen virke mot sin hensikt. Incentivordningen er derfor avhengig av et realistisk anslag av målprisen.
I det ovenstående og i de vedlagte eksempler er det vektlagt å beskrive ulike utfall av incentivordninger basert på en fast timerate. I realiteten kan leverandørens kostnad endres ved at reell gjennomsnittlig timerate avviker fra den forhåndsberegnede gjennomsnittlige timeraten. Det vil si at ved å benytte ressurser med lavere timerater, vil leverandøren kunne bruke et tilsvarende høyere timeantall før sanksjonene slår til og vice versa. Årsaken til dette er at avregningen skjer i forhold til kostnad (timer multiplisert med timerate) og ikke timer. Dette er for øvrig spesielt presisert i versjon 3.01 av kontraktsbilagene (Bilag D).
Avregningen skal baseres på virkelig kostnad. Virkelig kostnad kan beregnes ut fra godkjent timeforbruk for timer knyttet til målprisen multiplisert med reell gjennomsnittlig timerate.
Alternativt kan virkelig kostnad beregnes ved at godkjent timeforbruk innenfor hver av de ulike personellkategoriene multipliseres med aktuell timerate og at man deretter summerer resultatene fra hver kategori.
Virkelig kostnad sammenholdes så med fastsatt målpris. Fastsatt målpris er basert på timeestimat, inkludert påslag for usikkerhet, multiplisert med forhåndsberegnet gjennomsnittlig timerate, ref. punkt 6.1. På denne bakgrunn kan avviket mellom virkelig kostnad og målpris beregnes. Den delingen som er beskrevet ovenfor, i form av en prosentsats, benyttes da for å komme frem til tillegget eller reduksjonen i vederlaget i forhold til målprisen.
Dersom oppdraget avsluttes i forbindelse med et kontrollpunkt før alle avtalte iterasjoner er gjennomført og uten at godkjennings- og avslutningsfasen blir gjennomført, åpnes det for at incentivbeløp ikke kommer til utbetaling. Det må da avtales delvise incentiver og sanksjoner ut fra andel av leveransen som er godkjent, ref. Del II punkt 4.2. Faktisk tilgodebeløp bør da heller knyttes opp til kundens mulighet til og behov for å overta opphavsrett på de leveranser som er gjennomført. Dette er hensyntatt under punkt 9.
6.2.2 Incentiver og sanksjoner knyttet til tid
Tidsincentiver gir en sterk fokus på ferdigstillelsen som er lett å kommunisere i prosjektet Det tilrettelegger en tidlig gevinstrealisering for kunden
Tidspress kan føre til redusert kvalitet
I tillegg til incentiv- og sanksjonsordninger knyttet til vederlag, bør det også vurderes mekanismer knyttet til tid, slik at ferdigstillelse innenfor gitte tidsrammer prioriteres. Det er i kontraktsbestemmelsene også knyttet noen tilleggsordninger til tidsaspektet som ikke er fanget opp av incentivordningene. Partene bør påse at de ulike incentivordninger både er balansert i forhold til hverandre og mot totalt kostnadsnivå.
En incentivordning knyttet til tid bør definere en prosentandel som skal utgjøre en bonus ved tidligere ferdigstillelse, og en tilsvarende sanksjon ved senere ferdigstillelse i forhold til den kontraktsfestede godkjenningsdatoen. Dagbotsstørrelsen er normalt 0,15 %, men kan tilpasses leveransens størrelse og kritikalitet. Sanksjonen er begrenset til et tak på maksimum 100 dager avvik. Incentivet vil normalt være knyttet til en mye kortere periode, da det sjelden gir positiv effekt eller er realistisk å ferdigstille mye tidligere enn planlagt.
Konsekvenser ved incentivordninger knyttet til tid kan være:
Positive:
- For leverandøren: De skaper sterk fokus på ferdigstillelsen som er lett å kommunisere i prosjektet. Incentivordning knyttet til tid (evt. kombinert med incentivordning knyttet til kostnad) kan dermed være bedre egnet som intern motivasjonsfaktor i forhold til incentivordning knyttet til kostnad alene.
- De legger press på leverandøren til å bruke de best kvalifiserte ressursene.
- For kunden: De muliggjør en tidlig gevinstrealisering av leveransen.
Negative:
- Incentivordning knyttet til tid alene krever økt kvalitetskontroll fra kundens side. Leverandøren kan ha en tilbøyelighet til å kvalitetssikre og/eller teste for lite.
- Tidspress kan generelt føre til redusert kvalitet på leveransen.
6.3 Betalingsbetingelser
Kunden må foreta et valg om det er akseptabelt med løpende timebetaling i målprisperioden. Det bør da uansett settes et tak når grensen for målpris er nådd. Overskytende skal først kunne utbetales når godkjenning er foretatt.
I utgangspunktet er det foreslått en modell hvor en fast prosentutbetaling følger hovedmilepælene i kontrakten og hvor endelig utbetaling først kan foretas etter godkjenning og eventuelt etter garantiperioden, dersom det også er avtalt. Uansett bør det gjenstå en utbetaling knyttet til godkjenningsperioden som først faktureres etter godkjenning, og tilsvarende for garantiperioden.
7 Rettigheter til programvare
Begge parter bør nøye vurdere hvilket fremtidig behov de har for rettigheter til programvaren, og for tilgang til kildekoden.
PS2000-kontraktsstandarden skiller i utgangspunktet mellom ”standard programvare”, ”komponenter fra Leverandørens standard programvarebibliotek” og ”øvrig programvare som inngår i leveransen”. I kontraktens Xxx XX er det foreslått ulik regulering av partenes rettigheter knyttet til de tre typene. Partene kan justere dette i Bilag F.
7.1 Opphavsrett
Opphavsretten er utgangspunktet for videresalg av programvaren og gir rettighetshaveren både kontrollen og potensiell fortjeneste ved videresalg. Ofte er det slik at programvaren består av utviklede deler, som for kunden må regnes som forretningskritiske, og av moduler og biblioteker som allerede er utviklet av leverandøren eller en tredjepart. For de sistnevnte er det neppe aktuelt å overdra den fulle opphavsretten til kunden, ref. Del II punkt 5.2. For de deler som er utviklet for kunden og av denne regnes som forretningskritiske, er det nødvendig at opphavsretten overdras til kunden, ref. Del II punkt 5.1. For de deler som leverandøren har utviklet separat og hvor leverandøren kan ha nytte og interesse av ytterligere gjenbruk, er det ofte hensiktsmessig å la leverandøren beholde opphavsretten.
7.2 Disposisjonsrett
Disposisjonsretten, ref. Del II punkt 5.2, beskriver i hvilket omfang kunden har rett til å benytte programvaren.
I og med at det er snakk om programvare som enten skal utvikles eller integreres med hverandre, er det ikke naturlig at det legges noen begrensninger i kundens disposisjonsrett, herunder eksemplarfremstilling. Dersom kunden får full disposisjonsrett, kan det i tillegg være nødvendig å regulere retten til videresalg av programvaren. Dette er spesielt aktuelt dersom en tredjepart overtar kundens virksomhet.
7.3 Deponering av kildekoden
Dersom kunden ber om det, plikter leverandøren å inngå avtale med tredjepart (depotagent) om kildedepot (ESCROW avtale) som sikrer kunden rett til videreutvikling og vedlikehold av den gjeldende programvare, dersom leverandøren ikke er i stand til oppfylle sine forpliktelser, ref. Del II punkt 5.4.
8 Mislighold
Mislighold oppstår når en av partene ikke overholder sine forpliktelser i henhold til kontrakten
8.1 Leverandørens mislighold
Sanksjoner ved forsinkelse knyttet til leverandørens leveranser i denne kontraktsstandarden er inkorporert i incentiv- og sanksjonsordningene, slik de er beskrevet ovenfor. Sanksjonen innebærer at leverandøren vil bli belastet med dagbot til en fastsatt størrelse per dag i inntil 100 kalenderdager, ref. Del II punkt 6.1.1.1. Dagbot løper ofte bare i forhold til forsinket leveringsdag, men i PS2000-kontraktsstandarden er det lagt opp til at også andre milepæler kan dagbotsanksjoneres. Dersom leverandøren er forsinket ved en slik milepæl vil han i enkelte tilfeller allikevel kunne overholde avtalt leveringstidspunkt. I et slikt tilfelle skal leverandøren i stedet for dagbot dekke kundens eventuelle tap tilknyttet den forsinkede milepæl, begrenset til dagboten leverandøren skulle betale, ref. Del II punkt 6.1.1.1. Dette for er å opprettholde et insitament for å hente inn en forsinkelse, samtidig som kunden må få en kompensasjon for et tap ved en forsinkelse. Tapet kan for eksempel være knyttet til ekstra kostnader knyttet til en leveranse fra en annen leverandør som da må utsettes.
Ytterligere sanksjoner mot leverandøren er kun mulig etter utløpet av 100 dagers-perioden, ref. Del II punkt 6.1.1.2. Da har kunden anledning til å heve kontrakten og kreve ytterligere erstatning. Dagboten fungerer dermed som en begrensning av leverandørens ansvar for forsinket leveranse, mens leverandøren er erstatningsansvarlig opptil den avtalte erstatningsbegrensning ved heving. Begrunnelsen for dette er å skape balanse og konsekvens mellom incentiver og sanksjoner.
Ethvert avvik mellom det som er avtalt (i kontrakten eller ved senere endringer) og det som er levert er en feil eller mangel.
Feil eller mangler kan gjøres gjeldende som grunnlag for forskjellige sanksjoner innen en reklamasjonstid på 12 måneder, ref. Del II punkt 6.1.2.1. PS2000-kontraktstandarden opererer imidlertid også med garantiperiode, ref. Del II punkt 3.5.4 og Bilag E. I denne periode garanterer leverandøren for at leveransen fungerer i henhold til godkjenningskriteriene.
I de fleste tilfellene vil forpliktelsene etter Xxxxx E erstattes av en vedlikeholdskontrakt for programvaren. Ettersom det ikke er noen plikt til å ha slik kontrakt og kontrakten ofte vil bli benyttet også til levering av mer enn bare programvare, er det nødvendig med en reklamasjonsrett utover garantiperioden.
Utover det som er dekket av garantiforpliktelsen skal leverandøren ved feil eller mangler utbedre disse ”med den hurtighet feilen eller mangelens art tilsier”, ref. Del II punkt 6.1.2.2. Det er med andre ord ingen presis frist, men en plikt knyttet til hvor alvorlig situasjonen er.
I enkelte tilfeller vil utbedring av en mangel innebære et betydelig arbeid, selv om mangelen i seg selv ikke er svært alvorlig. Da har leverandøren rett til å motsette seg utbedring og i stedet gi kunden et prisavslag, ref. Del II punkt 6.1.2.2.
Vanhjemmel kan oppstå dersom en av partene inkluderer utstyr eller programvare fra en tredjepart uten å ha sikret seg rett til dette fra angjeldende tredjepart. Leverandøren skal sørge for å avhjelpe virkningene av eventuelle tvister om vanhjemmel, ref. Del II punkt 6.1.3. I tillegg er det tatt inn reguleringer som skal sikre at kunden raskest mulig kan fortsette å benytte leveransene.
8.2 Kundens mislighold
Leverandøren kan kreve erstatning fra kunden i forbindelse med de tap som påføres som følge av forsinket eller manglende betaling, manglende medvirkning fra kunden og eventuelt annet brudd på kundens forpliktelser etter kontrakten, ref. Del II punkt 6.2.
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.
8.3 Fellesregler om inntruffet eller forventet mislighold
Kontrakten inneholder regulering i tråd med alminnelige kontraktsrettslige prinsipper om at en part ved den annens mislighold kan holde egen ytelse tilbake, for eksempel betalingen.
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.
8.4 Erstatning
Ved mislighold som beskrevet ovenfor fra en part, kan den andre part kreve erstatning til dekning av tap som er en direkte følge av den annen parts mislighold.
Leverandørens erstatningsansvar skal være begrenset til et definert beløp og skal ikke omfatte ansvar for indirekte tap, ref. Del II punkt 6.4.1.
Kundens erstatningsansvar er eksplisitt begrenset til de direkte kostnader og tap som leverandøren har som en følge av kundens mislighold. I tillegg skal leverandøren ha dekket det han ville ha fått ved en avbestilling.
8.5 Heving av kontrakten
Ved hevingsrett slik det er beskrevet ovenfor, knyttet til forsinkelse og vanhjemmel, kan den annen part gi misligholdende part en siste frist til å bringe forholdet i orden. Dersom dette ikke gjøres av den misligholdende part, kan Kontrakten heves med umiddelbar virkning.
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
9 Avbrudd og avbestilling
Hensynet til leverandøren: Skal sikres betaling for utførte tjenester og erstatning for direkte kostnader knyttet til en avbestilling
Hensynet til kunden: Skal sikres muligheten til å avbryte et prosjekt som ikke gir de forventede resultater
Hensikten med å regulere en avbestillingsrett, ref. Del II punkt 7, er å gi retningslinjer for avslutning av kontrakten før den er oppfylt, men uten at det er oppstått noen misligholdssituasjon. På den ene siden skal leverandøren sikres betaling for utførte tjenester og erstatning for de direkte kostnader som påføres ved avbestilling. På den annen side har kunden en mulighet til å komme ut av et prosjekt som ikke ser ut til å gi det forventede resultat. I utgangspunktet er det bare kunden som gis en slik avbestillingsrett, da det ikke er akseptabelt at leverandøren skal kunne fraskrive seg sitt leveranseansvar, i hvert fall ikke uten å kompensere kunden.
Vederlaget ved avbestilling skal fastsettes i Bilag D og vil normalt være 4-6 % av kontraktssummen. Dette skal dekke leverandørens forventede fortjeneste ved avtalen, eller i det minste en del av denne.
Dersom kontrakten avbestilles, vil leverandøren måtte stanse arbeid som utføres av sine eventuelle underleverandører. Disse vil kunne fremme krav om kompensasjon fra leverandøren som igjen vil overføre det til kunden som avbestillingskostnader. Leverandøren skal i utgangspunktet ha tilsvarende avbestillingsrett overfor sine underleverandører. Dersom det er lagt opp til omfattende underleveranser, bør kunden passe på at slik rett til avbestilling faktisk foreligger.
10 Øvrige vilkår
10.1 Taushetsplikt
Partene skal bevare taushet om all informasjon som er definert som konfidensiell, ref. Del II punkt 8.1. Slik taushetsplikt gjelder uten tidsbegrensning, det vil si også etter at kontrakten er opphørt og uavhengig om det blir inngått en vedlikeholdskontrakt.
10.2 Overdragelse av kontrakten
Overdragelse av kontrakten krever samtykke fra den annen part, med unntak av situasjoner som oppstår som følge av fusjoner og fisjoner av partene (definert som rettssubjekter), det være seg både kunde og leverandør.
10.3 Forsikringer
Partene må ha tegnet en alminnelig ansvarsforsikring, som kan dokumenteres på forespørsel fra den annen part, ref. Del II punkt 8.3. Partene skal dekke sine egne omkostninger ved slike forsikringer.
10.4 Rettsvalg
Kontraktsstandarden er utviklet i samsvar for norsk rett og er kun tilpasset slik bruk. Den finnes også i en engelsk versjon, men denne er fortsatt kun beregnet for bruk i samsvar med norsk rett.
10.5 Konfliktløsning
Uavhengig ekspert benyttes for objektiv vurdering og megling dersom forhandlinger i koordineringsgruppen ikke fører frem
Kontraktstandarden legger opp til bruk av voldgift dersom forhandlinger og bruk av ekspert ikke fører frem
Det skal benyttes en uavhengig, uhildet ekspert som kan foreta en faglig vurdering av de kontraktskonflikter som eventuelt oppstår, ref. Del II punkt 8.5.2. Hensikten er å objektivisere grunnlaget for kontraktskonfliktene, men også å skille ut konfliktområder og behandle dem separat fra prosjektet. Eksperten skal forestå en megling mellom partene.
Dersom partene ikke kan akseptere ekspertens forslag til løsning, må saken bringes inn for domstolsbehandling eller voldgift dersom partene er blitt enige om det, ref. Del II punkt 8.5.3.
Tre områder er spesielt aktuelle for anvendelse av konfliktløsningsprosedyren og er derfor spesifikt trukket frem i de generelle kontraktsbestemmelsene:
- Omtvistede endringer
- Tvist om utskiftning av personale
- Tvist knyttet til feilsituasjoner
Frister for prosessen knyttet til konfliktløsning må avtales og fylles inn. Normalt bør eksperten få rundt 1 måned på å avgi sitt forslag til løsning. Dersom det ikke skal gjennomføres megling, bør partene ha minst 2 ukers frist før tvisten kan bringes inn for voldgiftsbehandling. Dersom det skal gjennomføres megling, bør normal frist for meglingen være ytterligere 1-2 måneder.
11 Om vedlikeholdskontrakt
Ytelsesnivå og forutsetninger for en fremtidig vedlikeholdskontrakt bør defineres i kontrakten, som en opsjon, slik at de kan legges til grunn for ytelsene i garantiperioden
Det er sentralt å få avtalt ytelsesnivå og hvilke forutsetninger som skal gjelde for en fremtidig vedlikeholdskontrakt, da disse betingelsene også skal benyttes for å regulere forpliktelser i garantiperioden. Videre må prisnivå, normalt i form av prosentandel av målpris, for det faste vedlikeholdet angis.
Det er blant annet viktig å avklare om alle definerte krav, for eksempel ytelseskrav fortsatt gjelder i garantiperioden. Dette fordi miljøet som systemet driftes i kan avvike fra testmiljøet som gjerne er utgangspunktet for referansemålinger.
Ved vurdering av vedlikeholdskontrakt, bør kunden inkludere følgende momenter:
- Finnes det retningslinjer i gjeldende IT-strategi/virksomhetsplan?
- Hva finnes av egne ressurser?
- Hva slags kompetanse har egne ressurser?
- Ønsker kunden å bygge opp egen kompetanse?
- Skal deler av/eller hele vedlikeholdet utføres av egne ressurser?
Dersom det er utarbeidet en IT-strategi/virksomhetsplan, vil denne kunne gi svar på disse spørsmålene.
Dersom vedlikeholdskontrakten ikke inngås samtidig med utviklingskontrakten, må det settes en frist for når opsjonen må innløses for at kravene til vedlikehold skal kunne gjøres gjeldende.
VEDLEGG
FORUTSETNINGER FOR DE ULIKE MODELLENE | |||||||
Målpris (kr) 10 000 000 Gj.snittlig timepris 1 000 Avtalt tid i måneder 12 Bonus/sanksjon pr. dag (tid), max 100 dager 0,15 % | |||||||
MODELL A (tak på leverandørs fortjeneste/tap) | Leverandør | Kunde | |||||
Risikofordeling (kostnad) | 50 % | 50 % | |||||
Øvre tak | 30 % | ||||||
Reelle kostn. | Incentiv | Reell tid | Incentiv | Sum | SUM | Gj.snitt | |
Ulike eksempler på reell tid/forbruk | iht .timer | kostnad | dager(+/-) | tid | incentiv | kostnad | pr.time |
Ferdig etter 9 mnd, 70% av forbruk | 7 000 000 | 1 500 000 | -90 | 1 350 000 | 2 850 000 | 9 850 000 | 1 407 |
Ferdig etter 11 mnd, 90% av forbruk | 9 000 000 | 500 000 | -30 | 450 000 | 950 000 | 9 950 000 | 1 106 |
Ferdig etter 13 mnd, 120% av forbruk | 12 000 000 | -1 000 000 | 30 | -450 000 | -1 450 000 | 10 550 000 | 879 |
Ferdig etter 18 mnd, 150% av forbruk | 15 000 000 | -1 500 000 | 180 | -1 500 000 | -3 000 000 | 12 000 000 | 800 |
Ferdig etter 24 mnd, 200% av forbruk | 20 000 000 | -1 000 000 | 000 | -1 500 000 | -3 000 000 | 17 000 000 | 850 |
MODELL B (intet tak) | Leverandør | Kunde | |||||
Risikofordeling (kostnad) | 50 % | 50 % | |||||
Reelle kostn. | Incentiv | Reell tid | Incentiv | Sum | SUM | Gj.snitt | |
Ulike eksempler på reell tid/forbruk | iht .timer | kostnad | dager(+/-) | tid | incentiv | kostnad | pr.time |
Ferdig etter 9 mnd, 70% av forbruk | 7 000 000 | 1 500 000 | -90 | 1 350 000 | 2 850 000 | 9 850 000 | 1 407 |
Ferdig etter 11 mnd, 90% av forbruk | 9 000 000 | 500 000 | -30 | 450 000 | 950 000 | 9 950 000 | 1 106 |
Ferdig etter 13 mnd, 120% av forbruk | 12 000 000 | -1 000 000 | 30 | -450 000 | -1 450 000 | 10 550 000 | 879 |
Ferdig etter 18 mnd, 150% av forbruk | 15 000 000 | -2 500 000 | 180 | -1 500 000 | -4 000 000 | 11 000 000 | 000 |
Ferdig etter 24 mnd, 200% av forbruk | 20 000 000 | -5 000 000 | 360 | -1 500 000 | -6 500 000 | 13 000 000 | 000 |
MODELL C (tak på kundens kostnad) | Leverandør | Kunde | |||||
Risikofordeling (kostnad) | 50 % | 50 % | |||||
Øvre tak | 30 % | ||||||
Reelle kostn. | Incentiv | Reell tid | Incentiv | Sum | SUM | Gj.snitt | |
Ulike eksempler på reell tid/forbruk | iht .timer | kostnad | dager(+/-) | tid | incentiv | kostnad | pr.time |
Ferdig etter 9 mnd, 70% av forbruk | 7 000 000 | 1 500 000 | -90 | 1 350 000 | 2 850 000 | 9 850 000 | 1 407 |
Ferdig etter 11 mnd, 90% av forbruk | 9 000 000 | 500 000 | -30 | 450 000 | 950 000 | 9 950 000 | 1 106 |
Ferdig etter 13 mnd, 120% av forbruk | 12 000 000 | -1 000 000 | 30 | -450 000 | -1 450 000 | 10 550 000 | 879 |
Ferdig etter 18 mnd, 150% av forbruk | 15 000 000 | -3 500 000 | 180 | -1 500 000 | -5 000 000 | 10 000 000 | 667 |
Ferdig etter 24 mnd, 200% av forbruk | 20 000 000 | -8 000 000 | 000 | -1 500 000 | -10 000 000 | 10 000 000 | 500 |
For sammenligningens skyld: | |||||||
MODELL D (fast pris) | Leverandør | Kunde | |||||
Risikofordeling (kostnad) | 100 % | 0 % | |||||
Reelle kostn. | Incentiv | Reell tid | Incentiv | Sum | SUM | Gj.snitt | |
Ulike eksempler på reell tid/forbruk | iht .timer | kostnad | dager(+/-) | tid | incentiv | kostnad | pr.time |
Ferdig etter 9 mnd, 70% av forbruk | 7 000 000 | 3 000 000 | -90 | 1 350 000 | 4 350 000 | 11 350 000 | 1 621 |
Ferdig etter 11 mnd, 90% av forbruk | 9 000 000 | 1 000 000 | -30 | 450 000 | 1 450 000 | 10 450 000 | 1 161 |
Ferdig etter 13 mnd, 120% av forbruk | 12 000 000 | -2 000 000 | 30 | -450 000 | -2 450 000 | 9 550 000 | 796 |
Ferdig etter 18 mnd, 150% av forbruk | 15 000 000 | -5 000 000 | 180 | -1 500 000 | -6 500 000 | 8 500 000 | 567 |
Ferdig etter 24 mnd, 200% av forbruk | 20 000 000 | -10 000 000 | 360 | -1 500 000 | -11 500 000 | 8 500 000 | 425 |
MODELL E (timebasert) | Leverandør | Kunde | |||||
Risikofordeling (kostnad) | 0 % | 100 % | |||||
Reelle kostn. | Incentiv | Reell tid | Incentiv | Sum | SUM | Gj.snitt | |
Ulike eksempler på reell tid/forbruk | iht .timer | kostnad | dager(+/-) | tid | incentiv | kostnad | pr.time |
Ferdig etter 9 mnd, 70% av forbruk | 7 000 000 | 0 | -90 | 1 350 000 | 1 350 000 | 8 350 000 | 1 193 |
Ferdig etter 11 mnd, 90% av forbruk | 9 000 000 | 0 | -30 | 450 000 | 450 000 | 9 450 000 | 1 050 |
Ferdig etter 13 mnd, 120% av forbruk | 12 000 000 | 0 | 30 | -450 000 | -450 000 | 11 550 000 | 963 |
Ferdig etter 18 mnd, 150% av forbruk | 15 000 000 | 0 | 180 | -1 500 000 | -1 500 000 | 13 500 000 | 900 |
Ferdig etter 24 mnd, 200% av forbruk | 20 000 000 | 0 | 360 | -1 500 000 | -1 500 000 | 18 500 000 | 925 |