PS2000 - en innføring for leverandørens prosjektleder

967 views
781 views

Published on

Published in: Lifestyle
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
967
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Når vi snakket om «PS2000» er det mange som kun tenker utviklingskontrakt. Men PS2000 er faktisk en hel avtaleportefølje. I denne presentasjonen er PS2000 utviklingskontrakten hovedtema.
  • Fra 1998 – like aktuell i dag!
  • «Vanlige» IT-kontrakter dekker kun ytterste sirkel. PS2000 har en bredere regulering, og er derfor ikke bare en kontrakt, men et prosjektgjennomføringsverktøy.
  • Fasene i en PS2000
  • * Men husk at veiledningen ikke kan legges til grunn som juridisk dokument.
  • Fakturering er typisk knyttet til disse fasene
  • Det er altså VI som har ansvaret for at det er fremdrift i LFB-fasen, men den skal lages i fellesskap. Når vi mener vi er i mål, er det kundens PLIKT å godkjenne LBF innen en viss frist.
  • Vent på svar
  • Men dette kommer vi tilbake til.
  • OBS – «ved motstrid» krevet at Bilag A og LBF er uenig. Dersom LBF er taus vil Bilag A fylle inn.
  • Plikter for begge parter her.
  • Kontrakten gir oss noen holdepunkter for å dytte litt i kunden for å se om de våkner.
  • F. Eks 0 A-feil5 B-feil20 C-feilDette kan alle – men for kronologiens skyld er det med. Det vi gjør nå, er å gjennomgå kontrakten punkt for punkt. Den er faktisk ganske pedagogisk oppbygget!
  • Forbered dere på verdens verste foil
  • - Gode prosjekter med erfaring fra kontrakt? Gi beskjed hvis du vil holde foredrag om det.
  • PS2000 - en innføring for leverandørens prosjektleder

    1. 1. - En kort innføring for leverandørens prosjektledereComputasdagen 19-10-2012 1
    2. 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. 3. PS2000 kontraktsmodellComputasdagen 19-10-2012 3
    4. 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. 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. 6. FASIT-rapporten- hvorfor IT-prosjekter skjærer seg 6
    7. 7. Kontrakten som styringsverktøy Ressurser Kvalitet Omfang Risiko Visualisering PS 2000 Kommunikasjon Integrasjonsstyring Tid KostnadComputasdagen 19-10-2012 7
    8. 8. PS2000 gjennomføringsmodellComputasdagen 19-10-2012 8
    9. 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. 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. 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. 12. PS2000 gjennomføringsmodellComputasdagen 19-10-2012 12
    13. 13. Løsningsbeskrivelsen3.3 Løsningsbeskrivelse3.3.1 UtarbeidelsePartene skal etter kontraktsinngåelsen i fellesskap, men under ledelse og styring avLeverandøren gjennomgå Bilag A og Fremdriftsplanen. Gjennomgangen av dissedokumentene skal som et minimum omfatte en vurdering av Kundens premisser forBehovsanalysen, herunder organisasjonsmessige forhold, beskrivelse av de prosesser somskal håndteres av Leveransen og en presisering eller utdypning av de i Bilag A beskrevnebehov og den grove løsningsbeskrivelsen.På bakgrunn av denne gjennomgangen skal Leverandøren innen en frist, som er definert iFremdriftsplanen, utarbeide en Løsningsbeskrivelse. Løsningsbeskrivelsen skal dannegrunnlag for gjennomføringen av Konstruksjonsfasen, ref. punkt 3.4.Løsningsbeskrivelsen skal gjennomgås og godkjennes av Kunden innen en frist som erdefinert i Bilag C. Dersom Kunden ikke godkjenner Løsningsbeskrivelsen, må Kundeninnen fristen skriftlig påpeke hvordan den er i strid med Leverandørens forpliktelser etterKontrakten eller utstede en Endringsanmodning i henhold til punkt 3.3.2.Computasdagen 19-10-2012 13
    14. 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. 15. Del II pkt. 3.3.23.3.2 Endring i omfangLeverandøren skal utstede en Endringsanmodning dersom Leverandørenunder utarbeidelse eller i forbindelse med godkjenning avLøsningsbeskrivelsen vil hevde at oppfyllelse av krav Kunden har fremsattinnebæ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. 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. 17. …tilbake til LBF, Del II pkt. 3.3.33.3.3 Løsningsbeskrivelsens konsekvens for KontraktenDet skal fremgå av Løsningsbeskrivelsen hvilke deler avBehovsanalysen som erstattes av Løsningsbeskrivelsen. Degjenværende deler av Behovsanalysen i Bilag A anses inkorporert iLøsningsbeskrivelsen.Løsningsbeskrivelsen blir det bindende grunnlag for Leveransen, oginngå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. 18. Konstruksjonsfasen - ansvarsforhold3.4.1 Detaljplanlegging / Analyse og designPartene skal sammen, men under Leverandørens ledelseog styring, legge en detaljplan for hvert trinn iKonstruksjonsfasen, innenfor rammene avFremdriftsplanen. Med mindre noe annet fremgår av BilagC, skal detaljplanleggingen av hvert trinn tilrettelegge foriterative prosesser.Ytterligere krav til hvordan detaljert analyse og design skalgjennomføres, fremgår av Bilag C. Computasdagen 19-10-2012 18
    19. 19. Konstruksjonsfasen - ansvarsforhold 3.4.2 UtviklingLeverandøren skal gjennomføre arbeidet med å utvikle, integrere og tilpasse Komponentenei Leveransen trinnvis i henhold til Løsningsbeskrivelsen og den detaljplan som er lagt forarbeidet. Med Komponenter menes avgrensede eller selvstendige deler av enprogramvare, som kan utvikles eller baseres på standard programvare eller del av ettilgjengelig programvarebibliotek. Eventuelle leveranser fra Kunden skal integreres iLeveransen. Hvert trinn avsluttes med testing og et Kontrollpunkt. Et Kontrollpunktrepresenterer i motsetning til en Milepæl ikke nødvendigvis en avslutning eller et oppnåddresultat, men er et beslutningspunkt som danner grunnlag for det videre arbeidet.Leverandøren skal gjennomføre utviklingen av Komponenter i et begrenset antalliterasjoner, slik det fremgår av Bilag C. Dersom Kunden ønsker å øke antall iterasjoner, kandet fremsettes en Endringsanmodning. Videre fremgår det av Bilag C hvilke metoder, verktøyog standarder som Leverandørens utvikling skal baseres på. Øvrige krav til utviklingenfremgår også av Bilag C.Leverandøren skal minimum foreta en enhetstest av all funksjonalitet som er et resultat avpågående trinn, før overlevering til testing, ref. punkt 3.4.3.Computasdagen 19-10-2012 19
    20. 20. Del II, pkt. 3.4.33.4.3 TestingLeverandøren skal, i samarbeid med Kunden, for hvert trinn teste den del av Leveransensom er utviklet, integrert og tilpasset. Det fremgår av Bilag C hvordan testingen skalgjennom-føres. Leverandøren skal som en avslutning av Konstruksjonsfasen, eventueltogså etter trinn som i henhold til punkt 3.4.6 medfører at Kunden skal overta deler avLeveransen, gjennomføre en samlet integrasjons- og systemtest, for å dokumentere atLeveransen fungerer i henhold til Løsnings-beskrivelsen. Krav til den samledeintegrasjons- og systemtest fremgår av Bilag C.Testingen skal gjennomføres i henhold til forhånds-utarbeidede testspesifikasjoner ogLeverandø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 tilLøsningsbeskrivelsen. Testspesifikasjonene kan etter Kundens valg også benyttes iKundens Godkjenningsprøve. Eventuelle krav til tidspunkter og frister for utarbeidelse avtestspesifikasjoner fremgår av Bilag C. Computasdagen 19-10-2012 20
    21. 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. 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. 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. 24. Kontrollpunkt3.4.5 KontrollpunktKunden skal evaluere gjennomføringen av et trinn i et Kontrollpunkt som etterfølger testing av trinnet. Kunden kanmed 5 arbeidsdagers skriftlig varsel, kreve det pågående trinn avsluttet med gjennomføring av et Kontrollpunkt. Kundensskal fremsette krav om slikt avbrudd i form av en Endringsanmodning og avbruddet skal for øvrig håndteres i henhold tilpunkt 7.2.Eventuelle Endrings-anmodninger som har vært utstedt og utredet i gjennomførte trinn, skal eventuelt besluttesgjennomført ved utstedelse av Endringsordre for iverksettelse i et etterfølgende trinn. Partene skal i Kontrollpunktetgjennomgå og oppdatere den foreliggende usikkerhets-matrisen.Leverandøren skal utarbeide en plan for etterfølgende trinn basert på overordnet Fremdriftsplan og erfaringerfra gjennomført trinn. Arbeidet med etterfølgende trinn skal først igangsettes når Kunden innen en frist som er definerti 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 enEndringsanmodning.Kunden kan beslutte å gjennomføre færre trinn enn planlagt, noe som også innebærer at Godkjennings- ogavslutningsfasen 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 ihenhold til punkt 3.4.4, skal Leveransen regnes som ferdig utviklet og gå over i Godkjennings- ogavslutningsfasen. Computasdagen 19-10-2012 24
    25. 25. PS2000 gjennomføringsmodellComputasdagen 19-10-2012 25
    26. 26. GodkjenningsprøvenComputasdagen 19-10-2012 26
    27. 27. 3.5 Godkjennings- og avslutningsfase3.5.1 GodkjenningsprøveNår Leveransen regnes som ferdig etter siste ledd i punkt 3.4.5, skal Kunden gjennomføre en prøve med støtte fraLeverandøren, heretter kalt Godkjenningsprøven.Godkjenningsprøven skal gjennomføres i form av funksjonelle tester, ytelsestester og andre tekniske tester som dokumenterer atLeveransen oppfyller Kontraktens krav. Slike tester skal være dokumentert i form av en prosessbeskrivelse oggodkjenningskriterier 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 tilenhver 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 å kreveavbrudd i Godkjennings-prøven. Kunden skal da skriftlig dokumentere hvilke Feil eller mangler som er årsak til krav omavbrudd. Godkjenningsprøven kan først gjenopptas når Leverandøren har dokumentert utbedring av det antall Feil eller manglersom kreves for gjenopptakelse. (…)Dersom Leverandøren bestrider en meldt Feil eller mangel, må Leverandøren uten ugrunnet opphold utstede enEndringsanmodning. Leverandøren må for å kunne kreve tilleggsvederlag for Endringsanmodningen, dokumentere at detKunden anfører som Feil eller mangel ikke er en Feil eller mangel. Computasdagen 19-10-2012 27
    28. 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. 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. 30. PS2000 gjennomføringsmodellComputasdagen 19-10-2012 30
    31. 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. 32. Endringshåndtering 32
    33. 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ørerKunde kontrakt konsekvensutredningaksepterer ALT 1: ALT 2: innen X dagerkonsekvensutre Kunde aksepterer Kunden aksepterer ikkedningen, 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 setterblir 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. 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. 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. 36. Når kan leverandøreneventuelt 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. 37. Kort om målpris Øvre tak Målpris Nedre takComputasdagen 19-10-2012 37
    38. 38. PS2000 kontraktsmodellComputasdagen 19-10-2012 38
    39. 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. 40. Ta gjerne kontakt for en PS2000-prat! Anne-Lise Monsen aym@computas.comno.linkedin.com/in/annelisemonsen 10/29/2012 40

    ×