Gode råd for bedre IT-prosjekter

Aktualitet - mål

• Mange IT-prosjekter får store kostnadsoverskridelser og

forsinkelser. Dårlige ressursutnyttelse for både kunder og

leverandører. Store muligheter for forbedring.

• Min bakgrunn:

Jurist i 1994 og «IT-advokat» fra 1998

Både kunde- og leverandørsiden, små og store prosjekter, i alle

faser fra avtaleinngåelse, prosjektoppfølging, krisestadiet med

reforhandling, samt krav om heving og erstatning

• Mål:

– Flere bedre IT-prosjekter!

– Hovedfokus på implementering av standardsystemer, men

relevans utover det.

Elementene i en IT-leveranse

• Standard programvare (lisens/bruksrett/disposisjonsrett)

• Maskinvare, ev. krav til maskinvare eller infrastruktur

• Tjenester (implementering):

• Konfigurering: Innstillinger og oppsett

• Tilpasninger/modifikasjoner (bransje- eller kundebasert)

• Integrasjoner/grensesnitt med andre systemer

• Konvertering/datamigrering

• Testing og godkjenning

• Opplæring

• Idriftsettelse/oppstart

• Garanti med rettelser

• Vedlikehold/drift m/rettelser, oppdateringer, ev. videreutvikling mv

Mer om tjenesteelementet

• Langvarig tett samarbeid i prosjektperioden og driftsfasen

• Mennesker som skal jobbe med andre mennesker

• Store eksterne og interne kostnader

• Behov for forventningsavklaringer, innledningsvis og underveis

• Kundens behov og ønsker oppstår/klargjøres sent og det blir

fristende å undervurdere konsekvenser av endrede krav

• Høy grad av personavhengighet

• Behov for prosjektoppfølging

• Store krav til kundens prosjektdeltakerne - kunnskap, formidle og

foredle/forankre

• Leverandøren får en monopollignende posisjon

• Behov for samtidige organisasjonsendringer

• Behov for å prioritere: Tid - Kost - Kvalitet

TilfredshetskurvenGrønn: Kundens tro og leverandørens håp?

Gul: Et vanlig prosjekt

Rød: Et ikke uvanlig prosjekt

Tilfredshet

Kontraktpunkt,

Godkjennelse og

Drift

Tid

Kontraktsregulering – utg.pkt.

Lov:

• Ingen særlig lov eller forskrift om IT-avtaler/prosjekter…

• Ulovfestet kontraktsrett som er vanskelig tilgjengelig, og som

normalt kan fravikes ved avtale

Avtaletyper:

• Lisens-/bruksrettavtale

• Kjøps-/prosjektavtale

• Vedlikeholdsavtale og brukerstøtteavtale

• Driftsavtale

• Skytjenester: Tjenesteavtale, ev. prosjektavtale for

implementeringsstøtte

• Databehandleravtale vedr. personvern

Kontraktsarbeidet: Hva bør gjøres?

• Sett av tid!

• Velg korrekt kontraktstype og mal

• Tre «grupper» standardkontraktsleverandører:

Difi (SSA-avtalene) - IKT Norge - Dataforeningen

• Dekker mye av de samme, men også forskjellige leveransetyper

• Balansen og ansvar/risiko er noe ulikt fordelt

• SSA-avtalene ble revidert i 2015 etter leverandørdialog

• Malenes innhold:

• Generell avtaletekst som på et overordnet nivå angir avtalens omfang,

gjennomføring av leveransene og partenes plikter, samt sanksjoner.

• Bilag med noe forslag til tekst og innholdselementer.

Kontraktsmalene (I)

• Kjøp: Standard programvare og utstyr, uten tilpasninger og/eller

utvikling. Benyttes til standard IT-systemer (nesten) uten tjenester.

Eks: SSA-K, IKT Norge Kjøp.

• Kjøp/tilpasning: Standard programvare og utstyr, tilpasninger

og/eller noe utvikling av programvare, samt tjenester som

konfigurering, oppsett, konvertering og opplæring. Benyttes til

anskaffelse og implementering av IT-systemer.

Eks: SSA-T (inkl. tjenester), IKT Norge Kjøp.

• Konsulentoppdrag: Konsulenten får et selvstendig ansvar for å

levere et ferdig produkt, definert av kunden, til avtalt tid og pris. Kan

brukes til større og mindre IT-prosjekter. Eks: SSA-O.

• Konsulentbistand: Kjøp av konsulenttimer under ledelse av kunden.

Konsulentens ansvar er, innenfor avtalt tid og pris, begrenset til å

yte faglig bistand i aktiviteter styrt av kunden. Eks: SSA-B.

Kontraktsmalene (II)

• Systemutvikling m/ulike prosjektmetodikk: Prosjekter for utvikling

av programvare med varierende grad av ansvar, styring og

overvåking. Eks: SSA-T og SSA-S.

• Vedlikehold: Regulerer feilretting, brukerstøtte, forebyggende

vedlikehold, programoppdateringer. Kan gjelde både standard og

spesialutviklet programmer. Eks: SSA-V.

• Drift: Levering av driftstjenester over flere år. Eks: SSA-D.

• Sky-tjenester: Levering av funksjonaliteten i programvare som

løpende tjeneste fra leverandørens driftssted/over internett.

Eks: IKT-SaaS og SSA-L for Software as a Service (SaaS)

Eks: DFs skytjenesteavtale for tilpasning, utvikling og integrering

Eks: Leverandørens standardavtale med SSA-O/B

Kontraktsskriving

• Med utgangspunkt i korrekt valgte kontraktsmal …

• Jobb med bilagene!

Innhold i enkeltbilag og sammenhengen mellom bilagene.

Ikke skriv «det samme» flere steder, men henvis ved behov.

• Ensartet bruk av begreper - ikke tilbudsspråk - bruk av definisjoner

• Prosjektmetodikk- og styringsmekanismen: Hvordan skal veien være

fra start til mål?

• Sammenhengen mellom kundens behov og krav til løsningen, og

det leverandøren skal levere (konfigurering, tilpasninger,

integrasjoner mv), tester og godkjenning, samt garanti

• Hvordan kunden skal bidra? Samhandling/samarbeid?

• Hvem bør skrive kontrakten? Involvering av prosjektledere

• Uklarheter gir fare for konflikter og tillegg …

Kundens kravspesifikasjon

• Kundens behov og krav må presenteres

• Overordnet: Bakgrunn, mål og føringer

• Funksjoner - snarere enn program eller komponenter

• Husk også funksjoner som fungerer i dagens løsning

• Brukerhistorier som beskriver en eller flere prosesser

løsningen bør dekke

• Brukeropplevelse: Hvem er brukerne og hva «krever» de,

responsivt design.

• Tilgjengelighet (oppetid og responstid)

• Lov-/myndighetskrav til løsningen og arbeidsprosessene

• Sikkerhet og personvern

• Beskrivelse av teknisk plattform og systemlandskap m/grensesnitt

Leverandørens løsningsbeskrivelse

• Primært et svar på kundens krav/behov:

• Svar pr. krav/behov:

Dekkes i standard - Dekkes ved tilpasning - Dekkes ikke - Dekkes

delvis/uklart - Kommentar/forbehold

• Besvarelse av Brukerhistorier: Beskrivelse av hvordan løsningen vil

dekke prosessene

• Opplisting av programvare og moduler

• Angivelse av maskinvare, ev. krav til maskinvare, og krav til

infrastruktur og andre forutsetninger

• Ta bort «tilbudsspråk»

Rettigheter

• Hvilke rettigheter har partene behov for?

• Bruksrettigheter:

• Hvem skal bruke? Samarbeidspartnere? Sluttkunder?

• Hvordan beregnes bruken? Antall navngitte personer,

attestanter? Opp-/ og nedjustering

• Lisensvilkår: Tungt tilgjengelige lisensvilkår. Del av avtalen,

motstrid/forrang?

• Andre rettigheter:

• Opphavsrett vs begrensninger i salg til andre?

• Rett til å gjøre endringer og videreutvikling? Feilretting?

• Praktisk mulig? Deponering av kildekoden (escrow avtale)

Rev. spesifikasjon

• Fruktbart med revidert spesifikasjon med rettighetsavklaring etter

en innledende fase

• Aktiviteter i den innledende fasen

• Kunden utdyper, klargjør og konkretiserer behov og krav

• Leverandøren viser muligheter, forklarer og stiller spørsmål

• Dokumentasjon

• Omfang og detaljnivå

• Funksjon/virkning av at noe er glemt/feil

• Det eneste som skal være grunnlag for test, godkjenning og

garanti innenfor avtalt kalendertid og kostnad?

• Endringer av «scope» og rettigheter, gir ofte behov for endringer av

estimater/pris og fremdrift. Uthopp?

Prosjektaktiviteter

Beskriv oppgaver og mål m/estimat for begges ressursinnsats!

• Analyse og design av løsningen

• Installasjon av programvare, database, test- og driftsmiljø mv

• Detaljering av løsningen med

– Konfigurering/parametersetting

– Utarbeidelse/utvikling av rapporter og spørrefunksjoner

– Integrasjoner/grensesnitt

– Modifikasjoner/tilpasninger/utvikling

• Konvertering/migrering

• Test

• Opplæring av prosjektdeltakere og ev. sluttbrukere

• Dokumentasjon av løsning og driftsrutiner

• Bistand under oppstart

Hvordan jobbe i prosjektet?

- Arbeidsmetodikk

• Leverandørens arbeidsmetodikk anbefales normalt, ev. nedskalert

• Graden av kundeinvolvering.

Særlig viktig ved større arbeidsendringer – digitalisering.

• Forutsetter at metodikken passer kontrakten, og forklares i kontrakten

med redegjørelse for sammenhengen med kontraktens faser/tester

• Prosjektverktøy

• Viktig at kundens prosjektdeltakere får opplæring i metodikk og verktøy

• Hvordan dokumentere arbeidsmøter/WS og annen enighet? Språk?

• Rutiner for referat

• Varslingsplikt dersom forventninger ikke innfris (noe annet enn

reklamasjon)

Hvordan jobbe i prosjektet?

- Utviklingsmetode

• To diametralt ulike utgangspunkter

• Fossefall vs. Smidig utvikling...

• Fossefall («klassisk»): «Alt» spesifiseres før utviklingen starter og

partene har ikke kontakt før godkjenning

• Smidig/agile («nyere» f.eks Scrum): Kunden har en funksjonsliste

(produktkø) som løpende prioriteres og utvikles i korte iterasjoner

(sprinter) og demonstreres før neste produktkøelement velges.

Endringer/forbedringer legges i produktkøen.

• Mulig å hente elementer fra begge metodene

• Det beste fra begge...

• Bevissthet og klarhet gir det beste!

Hvordan jobbe i prosjektet?

- Organisering og roller

• Prosjektorganisasjon – styringsmodell

• Rollebeskrivelser med mandat (oppgaver og fullmakt)

• Kunden speiler leverandørens roller

• Styringsgruppe for overordnet styring og konfliktløsning

• Ikke detaljstyring

• Bør være andre personer

• Nøkkelressurser: Navngis, bytterett?

• Også kundens nøkkelressurser bør kontraktsfestes

• Opplæring av sluttbrukere

Innføring av ny måte å jobbe på hos kunden – involvering av

leverandøren, del av kontrakten??

Fremdriftsplan

• Estimert tjenesteomfang planlagt til kalendertid

• Overordnet med «faste» sentrale kontraktspunkter (milepæler)

• Detaljert plan knyttet til aktiviteter og ressurser som «lever»

• Oppstart i en eller flere faser (funksjonelt eller lokasjoner)

• Bør det planlegges med «dø-perioder»?

• Hva bør skjer dersom et tidspunkt ikke nås?

• Milepæler vs andre tidspunkter

• Forskyvning vs forsinkelse med sanksjon (dagbot, ev. heving)

• Dokumentasjon

• Viktig med en faseoppdeling m/milepæler som stemmer både med

kontraktens og leverandørens metodikk

Endringshåndtering

• Det vil komme endringsbehov… Så avtal en prosess og følg den!

Passer en annen prosess bedre enn avtalemalen?

• Hva kan være en endring som skal endringshåndteres?

• Hva gjelder hvis ikke avtalt endringsordreprosess er fulgt?

• Punkter som bør vurderes i en endringsordreprosess:

• Endringsanmodning (EA) - utredning og tilbud - undertegnet

Endringsordre (EO)

• Hvem kan signere, rammer? Frist?

• Samme prosess uansett hva og hvem som ønsker endring?

• Begrensinger for hva leverandøren må akseptere av endringer?

• Omtvistede endringsordre («scope» eller prisdiskusjon) –

hoppeplikt?

Endringsordre (EO) – innhold

• Ofte «for tynt», «for sent», «usignet», «feilnummeret» og «uarkivert»

• Hva endringen består i

• Omfang/tidsforbruk for alle roller (ikke bare utviklingstid)

• Virkning på kontraktsprisen, inkl. prismodell

• Krav til kunden i form av nye tekniske krav eller medvirkning

• Konsekvensvurdering/avhengigheter: fremdriftsplan, testplaner,

lisens/vedlikeholdskostnad (inkl. økt grunnlag), annet?

• Endringer som berører tid:

• Re-planleging av når alle ressursene skal bidra, husk kunden og

tredjepartsleverandører

• Konsekvenser for dagbot (og andre forsinkelsessanksjoner)

• Sammenhengen med kontrakten og andre EOer

Test og godkjenning

• Testgrunnlag:

– Hva skal løsningen testes opp mot? Hvilke krav og beslutninger?

Ansvar for feil i standardprogramvare?

• Testregime og plan:

– Hva skal testes av hvem, når og hvordan? Ansvar for testcaser

– Krav til leverandørens tester og rapportering før kundens test?

– Konsekvenser av aksepterte tester? Nye feil?

• Melde- og feilrettingsrutiner: Hvor og hvordan skal feil meldes og

følges opp med klargjøring og retesting, inkl. dokumentasjon

• Testkriterier: Antall feil og feilkategorier

• Rettetider i testfasene, og konsekvenser ved fortsatt feil

• Godkjenningsdag: Ofte dagbotsanksjonert og betalingsmilepæl

Garanti og vedlikehold

• IT-systemer har feil... Også etter driftsettelse. Legg en plan.

Godkjennelsesperiode eller Garanti og vedlikeholdsavtale.

• Innhold:

Retting av alle feil som meldes etter godkjenning/oppstart, ev.

begrensninger for feil som burde vært meldt før.

Frister for melding?

Krav til meldingsinnhold?

• Prismodell:

Inkludert i prosjektvederlaget/forhåndsbetalt, eller løpende

timer/målpris

• Varighet av de ulike forpliktelsene

• Sammenheng med vedlikeholds-/forvaltningsavtale el

• Oppdateringer og videre samarbeid mellom kunden og leverandøren

Valg av prismodell• Hovedtyper: Løpende timer (T&M) - fastpris - målpris - enhetspriser

• Målpris: Leverandøren estimerer sannsynlig tidsforbruk og kunden

betaler iht. medgått tid, men til en rabatert timepris dersom

estimatene overskrides.

• Kombinasjon av prismodeller. Ulike faser og oppgaver. Hva vil man

oppnå? Viktig å avklare hva som er hva, inkl. endringer.

• Eks på målprismodell («bratt kurve»):

Forutsetning Godtgjørelse

Tjenestevolum er redusert med mer enn 10 %

av estimat

Gevinsten av redusert tid deles 50 / 50

Tjenestevolum er redusert med 0-10 % av

estimat

Gevinsten av redusert tid går til Kunden

Tjenestevolum opp til 110 % av estimat Godtgjøres etter de oppgitte timepriser

Overskridelse på 10-25 % av estimat Godtgjøres med fratrekk av 30 %

Overskridelse på 25-50 % av estimat Godtgjøres med fratrekk av 50 %

Overskridelse på over 50 % av estimat Godtgjøres med fratrekk av 75%

Fakturering og forfall

• Lag en samlet oversikt over de ulike elementene i leveransen og

tjenestene, ev. også oppdelt pr. fase

• Mulig å rapportere på slik at vi har kontroll

• Også kostander etter GD/i Garantiperioden? Levetidskostanden

• Flere modeller

• Løpende (etterskuddsvis), ev. med tilbakeholdt del

• Betaling oppdelt etter fremdrift/milepæler

• Detaljeringsgrad – oversikt og detaljer

• Lisens:

• Forfallstidspunkt?

• Hva skjer ved terminering av prosjektet?

Sanksjoner/krav ved kontraktsbrudd

• Avhjelp/retting: «Gjøre om igjen»

• Dagbot: Kompensasjon for forsinkelse for avtalt(e) milepæl(er).

Prosentsats av kontraktssummen i et definert antall dager.

• Prisavslag: Kompensasjon for en mangel

• Erstatning: Krav om (dokumentert) tap. Direkte / indirekte tap?

Ansvarsbegrensning.

• Heving:

• Krav om vesentlig kontraktsbrudd.

• Ofte først etter utløpet av dagbotperioden.

• Helt eller delvis heving:

• Deler av leveransen/løsningen

• For det leverte eller for fremtidige ytelser

• Særlig problemstilling vedr. standard programvare

• Bruk av sanksjoner krever reklamasjon/formelle krav

Prosjektoppfølging

• Kontrakten et viktig prosjektverktøy

• Rapportering og avsjekk av oppgaver for å unngå misforståelser, ha

kontroll og styring:

• På flere nivåer og former – bruk av maler

• Prosjektøkonomi med status forbrukte timer vs estimater og

gjenstående omfang - oppdelt pr. tjeneste/element

• Fremdrift – milepælsplan/detaljert plan og metodikkens faser

• Samarbeidsklima: overordnet og pr område

• Beslutninger for løsningen og annet - grensen mot endringer

• Risikovurderinger av definerte elementer: Grønt, gult og rødt

• Møter og samtaler – den menneskelige faktor

• Prioriteringer av tid, kostnader og kvalitet, og ev. annet

• Prosjektledernes roller

Et hvert IT-prosjekt bør ha en «prest»,

en «psykolog» og en «stand-up

komiker»

Håndtering av faresignaler

• Fang opp faresignaler tidlig, før de er virkelige «farer»

• Håndtering på prosjektledernivå (ev. med utvidede fullmakter)

• Involvering av styringsgruppen som ressurs til å styre

• Reklamasjon? Behov - formen - oppfølging

• Snakk sammen – ikke bare brev/eposter

• Husk å dokumenter enighet om endringer

• Eksempler på faresignaler:

• Lav terskel for krav om endringsordre/tilleggsbetaling og

nedprioritering av endringsønsker

• Diskusjon om hvem som ikke har gjort det de skal , hvem som

har uttrykt seg uklart, ev. burde /ev. ikke gjort noe

• Stans i betaling – varsel om dagbøter og ev. erstatningsansvar

Andre virkemidler enn sanksjoner

• Vær åpen for at alt ikke er «svart/hvit», og at det kan finnes bedre

alternativer enn «sanksjonsveien»

• Prosess for å avklare «scopediskusjoner» og «fremdrift» underveis

• Bytte av ressurser, styrking av noen roller

• (Del)avbestilling / midlertidig (del)stans

• Oppdeling av prosjektet

• Bruk / endring av prismodell mv: Målpris eller bonus

• Økt dagbot og/eller økt mulighet for heving senere

• Se kostnader i prosjektfasen sammen med levetidskostanden, ev.

andre oppdrag

• Garantier fra morselskap/eiere

• Tilgang til kildekoden (ev. escrow avtale) som gir trygghet for senere

utvikling

• Bytte/støtte av ny implementeringspartner / konsulent

Takk for oppmerksomheten!

Kontaktdetaljer:

Grete F. Stillum - Brækhus Advokatfirma DA

Web: www.braekhus.no

Epost: stillum@braekhus.no

Mobil: 990 90 710