1. - En kort innføring
for leverandørens prosjektledere
Computasdagen 19-10-2012 1

2. Kontraktstyper og
modeller
• Vanlige standardavtaler i offentlig sektor:
o PS2000
o SSA
o IKT-Norges standardavtaler
• Vanlige avtaletyper
o Kjøpsavtale
o Utviklings- og tilpasningsavtale
o Vedlikeholdsavtale
o Driftsavtale
• Vanlige gjennomføringsmodeller
o Fossefallsgjennomføring
o Iterativ gjennomføring / smidig gjennomføring
Computasdagen 19-10-2012 2

3. PS2000 kontraktsmodell
Computasdagen 19-10-2012 3

4. PS2000 – litt historie
• Forskningsprogrammet PS2000 var Europas største
forskningsprogram innen prosjektledelse, under ledelse
av NTNU og SINTEF.
• DND har siden år 2000 hatt forvaltningsansvaret for
PS2000-kontraktsstandarden gjennom faggruppen for IT-
kontrakter.
• Faggruppen består av representanter fra
kundesiden, leverandørsiden og av uavhengige
rådgivere.
• Innspill, kommentarer eller forslag til forbedringer
behandles av gruppen. Kontraktene revideres jevnlig, og
alle innspill behandles - så gi DND tilbakemelding ved
erfaringer/forbedringsforslag.
Computasdagen 19-10-2012 4

5. Styret i faggruppen for IT-
kontrakter
• Består av (pr oktober 2012):
o Jørgen Petersen, Promis AS (styreleder)
o Erik Bollestad, DSS
o Haakon Brandtzæg, Capgemini Norge AS
o Frithjof Frederiksen, Bekk Consulting AS
o Anne-Lise Monsen, Computas AS
o Jan Erik Ressem, Statens lånekasse for utdanning
o Frode Sæter, Advokatfirmaet Haavind AS
o Trine Vabog, Simonsen Advokatfirma DA
o Eivind Kåresen, NAV
o Jan Sandtrø, Evry ASA
o Kathrine Breistøl, Timebox
o Bent J. Syversen, Direktoratet for forvaltning og IKT (Difi)
Footer Text 10/29/2012 5

6. FASIT-rapporten
- hvorfor IT-prosjekter skjærer seg
6

7. Kontrakten som
styringsverktøy
Ressurser
Kvalitet
Omfang Risiko
Visualisering PS 2000
Kommunikasjon
Integrasjonsstyring
Tid
Kostnad
Computasdagen 19-10-2012 7

8. PS2000
gjennomføringsmodell
Computasdagen 19-10-2012 8

9. Struktur i kontrakten
• DEL I: Kontraksdokument, definerer partene og
kontraktsinnhold.
• DEL II: Generelle kontraktsbestemmelser. Dette er
standardtekst som legger alle generelle føringer.
Det gjøres sjelden/aldri endringer i del II uten at
dette uttrykkelig fremgår. Du kan derfor lære den
«en gang for alle»!
• DEL III: Bilag. Det er denne delen av kontrakten som
gir oss opplysninger om den spesifikke leveransen.
• Det finner også veiledninger på DNDs hjemmeside.
Computasdagen 19-10-2012 9

10. Bilagsstruktur
• Bilag A: Behovsanalyse
• Bilag B: Administrative bestemmelser
• Bilag C: Gjennomføring
• Bilag D: Vederlag
• Bilag E: Betingelser for garanti- og vedlikehold
• Bilag F: Betingelser for rettigheter til programvare
• Bilag G: Betingelser for kildedepot (ESCROW)
• Bilag H: Eventuelle opsjoner (utover vedlikehold).
Computasdagen 19-10-2012 10

11. Bilag A
A.1 Innledning
Dette Kontraktsbilag inneholder en behovsanalyse som skal være grunnlaget for
gjennomføring av Leveransen. Behovsanalysen er dokumentert i form av en kravtabell som
gir en grov spesifikasjon av Kundens behov, krav og egne leveranser.
Videre inkluderes Leverandørens utdypning av forutsetninger og forbehold i et grovt
løsningsforslag.
I tillegg inkluderes en usikkerhetsmatrise som er et underlag for ansvarsdeling og vederlag
slik det blir dokumentert i øvrige bilag.
Computasdagen 19-10-2012 11

12. PS2000
gjennomføringsmodell
Computasdagen 19-10-2012 12

13. Løsningsbeskrivelsen
3.3 Løsningsbeskrivelse
3.3.1 Utarbeidelse
Partene skal etter kontraktsinngåelsen i fellesskap, men under ledelse og styring av
Leverandøren gjennomgå Bilag A og Fremdriftsplanen. Gjennomgangen av disse
dokumentene skal som et minimum omfatte en vurdering av Kundens premisser for
Behovsanalysen, herunder organisasjonsmessige forhold, beskrivelse av de prosesser som
skal håndteres av Leveransen og en presisering eller utdypning av de i Bilag A beskrevne
behov og den grove løsningsbeskrivelsen.
På bakgrunn av denne gjennomgangen skal Leverandøren innen en frist, som er definert i
Fremdriftsplanen, utarbeide en Løsningsbeskrivelse. Løsningsbeskrivelsen skal danne
grunnlag for gjennomføringen av Konstruksjonsfasen, ref. punkt 3.4.
Løsningsbeskrivelsen skal gjennomgås og godkjennes av Kunden innen en frist som er
definert i Bilag C. Dersom Kunden ikke godkjenner Løsningsbeskrivelsen, må Kunden
innen fristen skriftlig påpeke hvordan den er i strid med Leverandørens forpliktelser etter
Kontrakten eller utstede en Endringsanmodning i henhold til punkt 3.3.2.
Computasdagen 19-10-2012 13

14. • Vi jobber med løsningsbeskrivelsen sammen med
kunden, og kunden ber oss gjøre noe som vi mener
ikke kan leses ut av kundens behovsspesifikasjon
(bilag A)
Hva gjør vi?
Computasdagen 19-10-2012 14

15. Del II pkt. 3.3.2
3.3.2 Endring i omfang
Leverandøren skal utstede en Endringsanmodning dersom Leverandøren
under utarbeidelse eller i forbindelse med godkjenning av
Løsningsbeskrivelsen vil hevde at oppfyllelse av krav Kunden har fremsatt
innebærer leveranser og/eller arbeid utover det som er omfattet av Bilag A.
(…)
Endringsanmodningen skal behandles i henhold til punkt 3.6 
Computasdagen 19-10-2012 15

16. Del II pkt. 3.6
Endringsanmodning skal fremsettes av Leverandøren
uten ugrunnet opphold, ellers vil retten til å
påberope seg endringen bortfalle.
Computasdagen 19-10-2012 16

17. …tilbake til LBF,
Del II pkt. 3.3.3
3.3.3 Løsningsbeskrivelsens konsekvens for Kontrakten
Det skal fremgå av Løsningsbeskrivelsen hvilke deler av
Behovsanalysen som erstattes av Løsningsbeskrivelsen. De
gjenværende deler av Behovsanalysen i Bilag A anses inkorporert i
Løsningsbeskrivelsen.
Løsningsbeskrivelsen blir det bindende grunnlag for Leveransen, og
inngår etter godkjenning som et tillegg til Bilag A.
Løsningsbeskrivelsen skal ha rang foran Bilag A ved motstrid.
Computasdagen 19-10-2012 17

18. Konstruksjonsfasen -
ansvarsforhold
3.4.1 Detaljplanlegging / Analyse og design
Partene skal sammen, men under Leverandørens ledelse
og styring, legge en detaljplan for hvert trinn i
Konstruksjonsfasen, innenfor rammene av
Fremdriftsplanen. Med mindre noe annet fremgår av Bilag
C, skal detaljplanleggingen av hvert trinn tilrettelegge for
iterative prosesser.
Ytterligere krav til hvordan detaljert analyse og design skal
gjennomføres, fremgår av Bilag C.
Computasdagen 19-10-2012 18

19. Konstruksjonsfasen -
ansvarsforhold
3.4.2 Utvikling
Leverandøren skal gjennomføre arbeidet med å utvikle, integrere og tilpasse Komponentene
i Leveransen trinnvis i henhold til Løsningsbeskrivelsen og den detaljplan som er lagt for
arbeidet. Med Komponenter menes avgrensede eller selvstendige deler av en
programvare, som kan utvikles eller baseres på standard programvare eller del av et
tilgjengelig programvarebibliotek. Eventuelle leveranser fra Kunden skal integreres i
Leveransen. Hvert trinn avsluttes med testing og et Kontrollpunkt. Et Kontrollpunkt
representerer i motsetning til en Milepæl ikke nødvendigvis en avslutning eller et oppnådd
resultat, men er et beslutningspunkt som danner grunnlag for det videre arbeidet.
Leverandøren skal gjennomføre utviklingen av Komponenter i et begrenset antall
iterasjoner, slik det fremgår av Bilag C. Dersom Kunden ønsker å øke antall iterasjoner, kan
det fremsettes en Endringsanmodning. Videre fremgår det av Bilag C hvilke metoder, verktøy
og standarder som Leverandørens utvikling skal baseres på. Øvrige krav til utviklingen
fremgår også av Bilag C.
Leverandøren skal minimum foreta en enhetstest av all funksjonalitet som er et resultat av
pågående trinn, før overlevering til testing, ref. punkt 3.4.3.
Computasdagen 19-10-2012 19

20. Del II, pkt. 3.4.3
3.4.3 Testing
Leverandøren skal, i samarbeid med Kunden, for hvert trinn teste den del av Leveransen
som er utviklet, integrert og tilpasset. Det fremgår av Bilag C hvordan testingen skal
gjennom-føres. Leverandøren skal som en avslutning av Konstruksjonsfasen, eventuelt
også etter trinn som i henhold til punkt 3.4.6 medfører at Kunden skal overta deler av
Leveransen, gjennomføre en samlet integrasjons- og systemtest, for å dokumentere at
Leveransen fungerer i henhold til Løsnings-beskrivelsen. Krav til den samlede
integrasjons- og systemtest fremgår av Bilag C.
Testingen skal gjennomføres i henhold til forhånds-utarbeidede testspesifikasjoner og
Leverandøren skal fremlegge en protokoll som viser resultatet av testene.
Testspesifikasjonene skal gjennomgås og godkjennes av Kunden. Kunden kan nekte å
godkjenne testspesifikasjonene dersom disse ikke er dekkende eller i henhold til
Løsningsbeskrivelsen. Testspesifikasjonene kan etter Kundens valg også benyttes i
Kundens Godkjenningsprøve. Eventuelle krav til tidspunkter og frister for utarbeidelse av
testspesifikasjoner fremgår av Bilag C.
Computasdagen 19-10-2012 20

21. Spørsmål:
- Vi oversender testspesifikasjoner til kunden og «hører aldri noe fra dem»
Hva gjør vi?
1.3 Generelt om Kundens plikter
Kunden plikter å samarbeide med Leverandøren som beskrevet i Kontrakten, slik at
Leverandøren ikke blir forsinket eller på annen måte forhindret i å oppfylle sine
forpliktelser.
2.3 Oppfølging, rapportering, møter og meddelelser
(…)
Alle varsler, krav eller andre meddelelser knyttet til Kontrakten skal gis
skriftlig, eventuelt per epost, til den annen parts prosjektleder, eventuelt med kopi til
partens representanter i Kontraktsdokumentet dersom denne er ulik. Alle
meddelelser skal gis uten ugrunnet opphold. Angitte tidsfrister regnes fra det
tidspunkt meddelelse er mottatt.
Computasdagen 19-10-2012 21

22. … Men hva gjør vi egentlig?
• Bruk fornuft og folkeskikk.
o En e-post til kunden hvor vi spør hyggelig om de har glemt oss.
o Å «slenge kontrakten i bordet» gjør sjelden underverker for
samarbeidsforholdet.
• Men kjenn dine rettigheter og plikter fra kontrakten.
Bruk dem hvis du trenger dem.
Computasdagen 19-10-2012 22

23. Feil
3.4.4 Feil
Feil kategoriseres i Konstruksjonsfasen og etterfølgende faser slik:
* A-Feil er Feil som er så alvorlig at driften stanser eller må
stanses for en kritisk gruppe av brukere av Leveransen og
feilen ikke kan omgås,
* B-Feil er Feil som kan omgås, men som forsinker driften,
* C-Feil er Feil som det ikke er nødvendig å utbedre for å
igangsette eller opprettholde driften.
Antall gjenstående Feil eller mangler skal etter utløpet av
Konstruksjonsfasen ikke overstige det antall Feil av hver
kategori som fremgår av Bilag C.
Computasdagen 19-10-2012 23

24. Kontrollpunkt
3.4.5 Kontrollpunkt
Kunden skal evaluere gjennomføringen av et trinn i et Kontrollpunkt som etterfølger testing av trinnet. Kunden kan
med 5 arbeidsdagers skriftlig varsel, kreve det pågående trinn avsluttet med gjennomføring av et Kontrollpunkt. Kundens
skal fremsette krav om slikt avbrudd i form av en Endringsanmodning og avbruddet skal for øvrig håndteres i henhold til
punkt 7.2.
Eventuelle Endrings-anmodninger som har vært utstedt og utredet i gjennomførte trinn, skal eventuelt besluttes
gjennomført ved utstedelse av Endringsordre for iverksettelse i et etterfølgende trinn. Partene skal i Kontrollpunktet
gjennomgå og oppdatere den foreliggende usikkerhets-matrisen.
Leverandøren skal utarbeide en plan for etterfølgende trinn basert på overordnet Fremdriftsplan og erfaringer
fra gjennomført trinn. Arbeidet med etterfølgende trinn skal først igangsettes når Kunden innen en frist som er definert
i Bilag C, har godkjent planen og den oppdaterte usikkerhetsmatrisen. Dersom Kunden ikke godkjenner planen, må
Kunden enten innen fristen påberope seg at den er i strid med Leverandørens forpliktelser eller utstede en
Endringsanmodning.
Kunden kan beslutte å gjennomføre færre trinn enn planlagt, noe som også innebærer at Godkjennings- og
avslutningsfasen ikke blir gjennomført. Dette skal i så tilfelle reguleres som en avbestilling i henhold til punkt 7.3.
Når alle trinn er gjennomført og Leverandøren kan dokumentere testing i henhold til punkt 3.4.3 og et resultat i
henhold til punkt 3.4.4, skal Leveransen regnes som ferdig utviklet og gå over i Godkjennings- og
avslutningsfasen.
Computasdagen 19-10-2012 24

25. PS2000
gjennomføringsmodell
Computasdagen 19-10-2012 25

26. Godkjenningsprøven
Computasdagen 19-10-2012 26

27. 3.5 Godkjennings- og avslutningsfase
3.5.1 Godkjenningsprøve
Når Leveransen regnes som ferdig etter siste ledd i punkt 3.4.5, skal Kunden gjennomføre en prøve med støtte fra
Leverandøren, heretter kalt Godkjenningsprøven.
Godkjenningsprøven skal gjennomføres i form av funksjonelle tester, ytelsestester og andre tekniske tester som dokumenterer at
Leveransen oppfyller Kontraktens krav. Slike tester skal være dokumentert i form av en prosessbeskrivelse og
godkjenningskriterier utarbeidet av Kunden, basert på kravene i Bilag C og det som eventuelt fremgår av Løsnings-beskrivelsen.
Kunden skal fremlegge forslag til slik dokumentasjon for Leverandørens uttalelse senest innen den frist som er angitt i Bilag C.
I Bilag C er det definert en grense for det antall Feil eller mangler av de forskjellige kategorier, ref. punkt 3.4.4, som til
enhver tid kan være avdekket og gjenstående, ikke utbedret, i Godkjennings- og avslutningsfasen. (…)
Dersom en eller flere av grensene for antall Feil eller mangler overskrides i Godkjenningsprøven, har Kunden rett til å kreve
avbrudd i Godkjennings-prøven. Kunden skal da skriftlig dokumentere hvilke Feil eller mangler som er årsak til krav om
avbrudd. Godkjenningsprøven kan først gjenopptas når Leverandøren har dokumentert utbedring av det antall Feil eller mangler
som kreves for gjenopptakelse. (…)
Dersom Leverandøren bestrider en meldt Feil eller mangel, må Leverandøren uten ugrunnet opphold utstede en
Endringsanmodning. Leverandøren må for å kunne kreve tilleggsvederlag for Endringsanmodningen, dokumentere at det
Kunden anfører som Feil eller mangel ikke er en Feil eller mangel.
Computasdagen 19-10-2012 27

28. 3.5.2 Godkjenning
Når antall Feil eller mangler i Godkjenningsprøven er innenfor de i Bilag
C avtalte grensene, kan utbedring av gjenstående Feil eller mangler
foretas i etterfølgende Garantiperiode, i henhold til punkt 3.5.4. Kunden
kan angi en rimelig frist for utbedring i Garantiperioden. Dersom også
de øvrige godkjenningskriteriene er oppfylt og avtalt periode for
Godkjenningsprøve er utløpt, ref. Bilag C, skal Kunden uten ugrunnet
opphold godkjenne Leveransen ved skriftlig melding til Leverandøren.
Dette betegnes som Godkjenning.
Dersom vilkårene for Godkjenning ikke oppnås innen den tidsfrist som
fremgår av Fremdriftsplanen, skal Kunden innen 3 arbeidsdager varsle
Leverandøren om at misligholdsbeføyelser for forsinkelse i henhold til
punkt 6.1.1 gjøres gjeldende. Dersom Kunden ikke gir Leverandøren slikt
varsel, har Kunden plikt til å foreta Godkjenning, men kan likevel
fastsette en frist for utbedring av utestående Feil eller mangler.
Computasdagen 19-10-2012 28

29. 3.5.3 Avslutning
Etter Godkjenning skal det under ledelse av Kunden gjennomføres en
prosjektevaluering, hvor begge parter er forpliktet til å delta i et avsluttende
møte. Prosjektevalueringen skal ikke kunne medføre noe krav om
tilleggsvederlag. Referat fra det avsluttende møtet skal signeres av begge
parter, eventuelt med forbehold.
Computasdagen 19-10-2012 29

30. PS2000
gjennomføringsmodell
Computasdagen 19-10-2012 30

31. 3.5.4 Garantiperiode
Etter Godkjenning har Kunden en Garantiperiode med den varighet
som fremgår av Bilag E.
I Garantiperioden har Leverandøren plikt til å påse at Leveransen
fungerer i henhold til de godkjennings-kriterier som var gjeldende
for Godkjenning.
Dette innebærer at Leverandøren plikter å utbedre Feil eller
mangler på de vilkår som fremgår av Bilag E. Vederlag for
Garantiperioden fremgår av Bilag D.
Computasdagen 19-10-2012 31

32. Endringshåndtering
32

33. RUTINE A RUTINE B RUTINE C
Leverandøren (vi) anmoder om Vi anmoder om endring fordi
Kunde anmoder om endring endring på eget initiativ (f. eks Kunden krever utført arbeid som vi
fordi vi mener noe kan gjøres på en hevder faller utenfor kontrakt
bedre/mer effektiv måte)
Kunde fyller ut avtalt skjema og
sender til vår prosjektleder Vi anmoder om endring på avtalt skjema.
Sendes til kundens bemyndigede
representant
Vi oppdaterer register over Vi anmoder om endring på avtalt skjema.
endringsanmodninger Vi oppdaterer register over Sendes til kundens bemyndigede
endringsanmodninger representant uten ugrunnet opphold
Vi oppdaterer register over
Vi gjennomfører ALT 1: endringsanmodninger
ALT 2:
konsekvensutredning innen X Kunden ber om
Kunden ønsker ikke
dager konsekvensutredning fra oss
utredning
(vanligvis er dette 10 innen X dager (sjekk ALT 2:
ALT 1:
dager, men tidsfrist følger av kontrakten) Kunden fastholder at
Kunden endrer
kontrakten) arbeidet er innenfor
standpunkt og er enig
i at det er utenfor kontrakt og gir melding til
RUTINE AVSLUTTES kontrakt oss om dette innen X dager
ALT 2.1 ALT 2.2
Vi sender konsekvensutredning
Vi endrer Vi opprettholder
til Kunden
RUTINE A BENYTTES standpunkt og standpunkt om utenfor
er enig i at det kontrakt og
er innenfor gjennomfører
Kunde
kontrakt konsekvensutredning
aksepterer ALT 1: ALT 2:
innen X dager
konsekvensutre Kunde aksepterer Kunden aksepterer ikke
dningen, men konsekvensutredningen, og konsekvensutredningen:
ønsker ikke ønsker arbeidet utført:
endringen F. Eks fordi de er uenig i vår RUTINE AVSLUTTES
• Kunden utsteder estimering av oppgaven.
gjennomført
endringsordre
(f. eks fordi det
(EO), signerer, og Kunden setter
blir for dyrt)
oversender til oss for endringsanmodningen (EA) til
signering «omtvistet» og prosedyre for
• Vi signerer og returnerer konfliktløsning i kontraktens
til Kunden pkt. 8.5 følges
• Vi oppdaterer register
over endringsordrer (EO-
register)
• EO iverksettes i neste
trinn med mindre annet
avtales

34. Kort om forsinkelse
• Det foreligger forsinkelse når vi ikke følger
fremdriftsplanen som planlagt.
o Hvem sin skyld er det at forsinkelsen har oppstått?
o Vår feil?
• Hvis dagbotsanksjonert milepæl – dagbøter påløper automatisk
• OBS – dobbel dagbotsanksjonering kan oppstå hvis etterfølgende
milepæler forsinkes som følge av den opprinnelige forsinkelsen! Uklart
hva som er «rett» her, har partene ment å sanksjonere dobbelt?
o Dersom partene ikke har en intensjon om eventuell dobbel
dagbotsanksjonering så bør frister tilknyttet hovedmilepæler
være «X uker/måneder etter godkjent HMPX». På den måten
flytter milepælene seg parallelt med forsinkelsen.
o Kundens feil at vi er forsinket?
• Hvis Kunden selv er årsak til forsinkelsen må vi utstede en
endringsanmodning, slik at vi kan få justert fremdriftsplanen.
Computasdagen 19-10-2012 34

35. Kort om kundens
mislighold
• Kunden har betalingsplikt, og vil være i mislighold dersom
faktura ikke er betalt ved forfall (forutsatt at faktura er korrekt)
o Ved forsinket betaling kan leverandøren holde tilbake sin
ytelse.
• Dersom kunden misligholder «øvrige plikter etter
kontrakten», herunder plikten til å medvirke ved oppfyllelse av
leveransen, har leverandøren krav på justering av
fremdriftsplan og/eller vederlag, ved utstedelse av en
endringsanmodning.
• Tap leverandøren påføres som følge av kundens
mislighold, som ikke kan kompenseres for ved
endringsanmodning, kan kreves erstattet.
Computasdagen 19-10-2012 35

36. Når kan leverandøren
eventuelt heve kontrakten
• Hvis kunden er i vesentlig mislighold.
• Kunden er i vesentlig mislighold hvis:
o Betalingsmisligholdet fra kunden er «vesentlig»
o Hvis kunden misligholder medvirkningspliktene sine eller øvrige plikter i
«vesentlig grad»
Computasdagen 19-10-2012 36

37. Kort om målpris
Øvre tak
Målpris
Nedre tak
Computasdagen 19-10-2012 37

38. PS2000 kontraktsmodell
Computasdagen 19-10-2012 38

39. Husk dette
• Bruk kontrakten som styringsverktøy.
• Skriftlig materiale blir ofte en del av selve kontrakten
o E-poster
o Statusrapporter
o Etc.,
• Minn kunden på egne plikter – det kommer begge parter til
gode!
• Husk at straks det oppstår avvik, må dette endringshåndteres.
Uten ugrunnet opphold!
• Utnytt statusmøtene skikkelig. Dette er en god
kommunikasjonskanal til kunden.
o Referatfør alltid statusmøtene, og dersom det lar seg gjøre, bør referatet omforenes av
partene.
• Dette kan bli en viktig kilde til tolkning av kontrakten i fremtiden.
• Dersom det ikke lar seg gjøre å omforene referatet, kan referatet blir stående med
begge parters kommentarer vedlagt.
Computasdagen 19-10-2012 39

40. Ta gjerne kontakt for en PS2000-prat!
Anne-Lise Monsen
aym@computas.com
no.linkedin.com/in/annelisemonsen
10/29/2012 40