Slik lykkes du med it-kontrakter: Hva som skal ytes etter avtalen

Bilde: Blogtrepreneur

Det sies at 70 prosent av alle feil ved it-ytelser skyldes upresise eller manglende krav i kontrakten. Kostnadene for å utbedre feil øker også proporsjonalt desto lenger ut i leveransen man er kommet. Dette er andre del i en artikkelserie på fem artikler hvor gås det nærmere gjennom hvordan du lykkes med it-kontrakter. I denne delen gjennomgås det nærmere gjennom hva som bør og skal reguleres i kontrakten. 

Partenes beskrivelse av ytelsen

En presis og klar beskrivelse av ytelsen ved avtaleinngåelsen er en god investering. Dette er dessverre ikke så enkelt, og en utfordring ved it-kontrakter er gap mellom kundens og leverandørens forventninger og reell ytelse. Dette kan ha mange årsaker, men én hovedgrunn er mis-/ikke-forståelse av kundens behov og utilstrekkelig eller uklar beskrivelse av behovene.

Som nevnt i forrige artikkel i denne serien vil den reelle reguleringen av ytelsen gjøres i bilagene til kontrakten. Spesielt kundens beskrivelse av kravene til ytelsen (kravspesifikasjonen) og leverandørens beskrivelse av hvordan dekke kravene (løsningsbeskrivelsen) er da vesentlige. Men også fremdriftsplan og annen beskrivelse av gjennomføring av leveransen er viktig.

Kundens beskrivelse av behov og krav

Kunden må beskrive behovet slik at leverandøren kan konkretisere hvordan ytelsen skal dekke behovene. Det kan også benyttes prosjektmetodikk som smidig (agile) utvikling hvor leverandøren arbeider sammen med kunden for å avdekke behovene og hvordan disse skal dekkes. Dette kan bidra til økt forståelse av kundens behov og hvordan best dekke dette.

Behovsbeskrivelsen bør gjøres funksjonelt basert på de behov kunden erfarer, og ikke komponentbasert (eksempelvis at kunden ønsker en spesifikk applikasjon). Videre bør kravene være individuelt tilpasset kunden og dennes behov, og tilstrekkelig konkretiserte slik at det gir leverandøren veiledning for den forestående leveransen, og kan også benyttes av kunden ved senere vurdering av om leveransen er mangelfull, herunder i testfasen.

Kunden må klargjøre hvilke krav som er minimumskrav og forutsetninger for ytelsen, og som må dekkes av leverandørens beskrivelse. Sterkt ønskelige krav («bør-krav») kan inntas, men disse bør prises (og eventuelt hensyntas i fremdriftsplan) individuelt, slik at kunden kan velge om dette skal være en del av ytelsen. «Kan-krav» som er ønskelige, men pris-ømfintlige, bør også prises individuelt, og eventuelt inntas som opsjoner.

Spesifisering av ytelsen er en tid- og ressurskrevende prosess, og denne fasen i leveransen legger grunnlaget for leveransens suksess. Det bør derfor settes av nok tid og ressurser i prosjektet til å sikre at kravspesifiseringen blir best mulig.

Leverandørens beskrivelse av hva som skal leveres

«Better a friendly refusal than an unwilling consent». Leverandørens beskrivelse av hvordan kundens krav skal dekkes må adressere kravene slik disse fremkommer i kundens beskrivelse. Uklarheter bør leverandøren ta opp med kunden, og forhold i kundens beskrivelse som medfører uforholdsmessig arbeid, teknologiske utfordringer og forhold som kan påvirke leveransen ellers bør avklares med kunden.

Leverandøren bør gi anbefalinger på hvilke krav som ikke kan eller bør dekkes ut fra hva som er til kundens beste. Som nevnt ovenfor kan det være et forventningsgap mellom den ytelsen kunden forventer og den reelle ytelsen, og en god beskrivelse av ytelsen kan avstemme partenes forventninger og forhindre senere misforståelser og eventuelle tvister. Også det forhold at leverandørens beskrivelse vil være sentral dersom det senere skulle oppstå en tvist, tilsier at leverandøren bør investere tid og ressurser i beskrivelsen av ytelsen.

Det kan avtales at partene skal utarbeide ytterligere detaljert beskrivelse som en del av leveranseprosjektet sammen, for eksempel som et forprosjekt. Det bør da inntas forutsetninger for slik utarbeidelse, om det skal gjelde rammer for utarbeidelsen, hvem og hvordan spesifikasjonen skal god-kjennes med videre.

I tillegg til beskrivelsen av hva som skal leveres bør det også inntas dokumentasjon som skal utarbeides, herunder krav til format og oppdatering. Også andre forhold som vedrører hovedleveransen som eventuell opplæring, konvertering av data, sikkerhet ved avtalegjennomføringen, ansvar for sikkerhetskopiering og annet må reguleres.

Hvilken kontrakt?

Som nevnt i forrige artikkel er de mest benyttede standardavtalene for it-ytelser i Norge er laget av Difi (tidligere Statskonsult) med Statens standardavtaler, IKT-Norge og Dataforeningen. Det er en rekke ulike it-ytelser, men i hovedsak er det maskin- og programvare og tjenester. Avtalene dekker en rekke ulike typer ytelser som:

  • Bruksrett (lisens), tilpasning og utvikling av programvare og kjøp av maskinvare
  • Vedlikehold og videreutvikling av maskin- og programvare
  • Drift av programvare og applikasjoner
  • Konsulenttjenester

Det er også i tillegg enkelte standardavtaler for mer spesialiserte ytelser.

Som tidligere nevnt er det et kjent problem at det ofte benyttes feil standardavtale, som for eksempel at en standardavtale for anskaffelse av maskin- og programvare benyttes for tjenesteanskaffelse. Avtaler som man er usikker på passer med ytelsen eller som må tilpasses i større grad bør derfor ikke benyttes.


Dette er del av en artikkelserie som tidligere er publisert i Computerworld som består av følgende artikler:

Bli den første til å kommentere på "Slik lykkes du med it-kontrakter: Hva som skal ytes etter avtalen"

Legg inn en kommentar

Ikke gå glipp av noe!

Motta nyhetsbrev fra Teknologirett: