ps2000 - en innføring for leverandørens prosjektleder

1

- En kort innføring for leverandørens prosjektledere

Computasdagen 19-10-2012

2

Kontraktstyper og modeller

• Vanlige standardavtaler i offentlig sektor:o PS2000o SSAo IKT-Norges standardavtaler

• Vanlige avtaletypero Kjøpsavtaleo Utviklings- og tilpasningsavtaleo Vedlikeholdsavtaleo Driftsavtale

• Vanlige gjennomføringsmodellero Fossefallsgjennomføringo Iterativ gjennomføring / smidig gjennomføring


3

PS2000 kontraktsmodell


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.


04/10/2023Footer Text 5

Styret i faggruppen for IT-kontrakter

• Består av (pr oktober 2012):o Jørgen Petersen, Promis AS (styreleder)o Erik Bollestad, DSSo Haakon Brandtzæg, Capgemini Norge ASo Frithjof Frederiksen, Bekk Consulting ASo Anne-Lise Monsen, Computas ASo Jan Erik Ressem, Statens lånekasse for utdanningo Frode Sæter, Advokatfirmaet Haavind ASo Trine Vabog, Simonsen Advokatfirma DAo Eivind Kåresen, NAVo Jan Sandtrø, Evry ASAo Kathrine Breistøl, Timeboxo Bent J. Syversen, Direktoratet for forvaltning og IKT (Difi)

6

FASIT-rapporten

- hvorfor IT-prosjekter skjærer seg

7

Kontrakten som styringsverktøy


RessurserKvalitet

TidIntegrasjonsstyring

RisikoOmfang

Kostnad

VisualiseringKommunikasjon

PS 2000

8

PS2000 gjennomføringsmodell


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

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).


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.

12



13

Løsningsbeskrivelsen


3.3 Løsningsbeskrivelse3.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.

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?


15

Del II pkt. 3.3.2

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


3.3.2 Endring i omfang

16

Del II pkt. 3.6


Endringsanmodning skal fremsettes av Leverandøren uten ugrunnet opphold, ellers vil retten til å påberope seg endringen bortfalle.

17

…tilbake til LBF, Del II pkt. 3.3.3


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.

3.3.3 Løsningsbeskrivelsens konsekvens for Kontrakten

18

Konstruksjonsfasen - ansvarsforhold

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.


3.4.1 Detaljplanlegging / Analyse og design

19

Konstruksjonsfasen - ansvarsforhold


3.4.2 UtviklingLeverandø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.

20

Del II, pkt. 3.4.3


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.

3.4.3 Testing

21

Spørsmål:


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.

- Vi oversender testspesifikasjoner til kunden og «hører aldri noe fra dem»

Hva gjør vi?

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.


23

Feil


* 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.

3.4.4 FeilFeil kategoriseres i Konstruksjonsfasen og etterfølgende faser slik:

24

Kontrollpunkt


3.4.5 KontrollpunktKunden 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.

25



26

Godkjenningsprøven


27Computasdagen 19-10-2012

3.5 Godkjennings- og avslutningsfase3.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.


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.


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.

30




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.

32

Endringshåndtering

RUTINE A RUTINE B RUTINE CKunde anmoder om endring

Leverandøren (vi) anmoder om endring på eget initiativ (f. eks fordi vi mener noe kan gjøres på en bedre/mer effektiv måte)

Vi anmoder om endring fordi Kunden krever utført arbeid som vi hevder faller utenfor kontrakt

Kunde fyller ut avtalt skjema og sender til vår prosjektleder

Vi oppdaterer register over endringsanmodninger

Vi gjennomfører konsekvensutredning innen X dager(vanligvis er dette 10 dager, men tidsfrist følger av kontrakten)

Vi sender konsekvensutredning til Kunden

ALT 1:Kunde aksepterer konsekvensutredningen, og ønsker arbeidet utført:

• Kunden utsteder endringsordre (EO), signerer, og oversender til oss for signering

• Vi signerer og returnerer til Kunden

• Vi oppdaterer register over endringsordrer (EO-register)

• EO iverksettes i neste trinn med mindre annet avtales

ALT 2:Kunden aksepterer ikke konsekvensutredningen:

F. Eks fordi de er uenig i vår estimering av oppgaven.

Kunden setter endringsanmodningen (EA) til «omtvistet» og prosedyre for konfliktløsning i kontraktens pkt. 8.5 følges

Vi anmoder om endring på avtalt skjema.Sendes til kundens bemyndigede representant


ALT 2:Kunden ønsker ikke utredning

ALT 1:Kunden ber om konsekvensutredning fra oss innen X dager (sjekk kontrakten)

RUTINE AVSLUTTES

Vi anmoder om endring på avtalt skjema.Sendes til kundens bemyndigede representant uten ugrunnet opphold


ALT 1:Kunden endrer standpunkt og er enig i at det er utenfor kontrakt

ALT 2:Kunden fastholder at arbeidet er innenfor kontrakt og gir melding til oss om dette innen X dager

RUTINE A BENYTTES

ALT 2.1Vi endrer standpunkt og er enig i at det er innenfor kontrakt

RUTINE AVSLUTTES

ALT 2.2Vi opprettholder standpunkt om utenfor kontrakt og gjennomfører konsekvensutredning innen X dager

Kunde aksepterer konsekvensutredningen, men ønsker ikke endringen gjennomført (f. eks fordi det blir for dyrt)

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.

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»


37

Kort om målpris


Målpris

Øvre tak

Nedre tak

38

PS2000 kontraktsmodell


39

Husk dette• Bruk kontrakten som styringsverktøy.

• Skriftlig materiale blir ofte en del av selve kontrakteno E-postero Statusrapportero 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.


04/10/2023 40

Ta gjerne kontakt for en PS2000-prat!

Anne-Lise [email protected]

no.linkedin.com/in/annelisemonsen

mailto:[email protected]





http://www.linkedin.com/in/annelisemonsen

http://www.linkedin.com/in/annelisemonsen

ps2000 - en innføring for leverandørens prosjektleder

Lifestyle