Produktet blir til mens man går

Situasjonen virker sikkert kjent: Et prosjekt med tydelige, definerte krav til sluttproduktet blir gjennomført etter kravspesifikasjonen, men går på en smell både budsjett- og tidsmessig.

Hvorfor blir det ofte sånn? Jo, fordi omfanget av prosjektet låses, og alle uforutsette utfordringer løses med økte ressurser og/eller økt tidsbruk.

I smidig prosjektering kan det gjerne være omvendt. Ikke nødvendigvis fordi budsjettet er hugget i stein, men fordi man innser at kravet til selve produktet må revideres underveis.

Forholdet omfang - ressursbruk - tidsbruk

I prosjektering må man forholde seg til de tre aksene scope (omfang), ressurser og tid.

  • Scope er omfanget av arbeidet som skal gjøres for å lage et produkt.
  • Ressurser er budsjettet og ressurspersonene man har tilgjengelig for å gjøre jobben.
  • Tid er tiden frem til produktet skal leveres.


Waterfall vs agile | Atlassian agile coach

Fig 1: I tradisjonell prosjektering er aksen omfang låst (“Fixed”). I smidig prosjektering

kan man låse ressurser og tid, men da må man la omfang være fleksibelt (“Estimated”)


Alle disse aksene er i seg selv fleksible, men hvis man endrer en av aksene vil én eller begge de to andre også måtte endres for å skape balanse. Hvis du for eksempel ønsker ny funksjonalitet inn i ett produkt (øke omfang), så må øke ressurstilgangen og/eller utvide tidsfristene tilsvarende.

Tradisjonell prosjektering - forhåndsdefinert omfang

I tradisjonell prosjektering, med mye planlegging i forkant, låser man gjerne aksen omfang. Man prøver i praksis å kartlegge terrenget man skal gå opp, uten å ha vært der. Dermed blir ressurser og tid de gjenstående, fleksible aksene. Hvis det viser seg umulig å fullføre det avtalte omfanget innenfor estimert ressursplanlegging og tidsplanlegging, så må man utvide ressurstilgangen og/eller tidsplanen.

"Time and costs are at best, only guesses, calculated at a time when least is known about the project.” [Atkinson]

Smidig prosjektering - fleksibelt omfang

I smidig prosjektering kan man faktisk gjerne låse ressurser og tid, så lenge man holder omfanget fleksibelt. Man kan for eksempel inngå en avtale basert på fastpris, men da må man gå inn i prosjektet og vite at man må være fleksibel i forhold til hvilken funksjonalitet produktet leveres med.

Da er vi inne i kjernen ved smidig planlegging; vi ønsker et fleksibelt omfang fordi vi ikke har all kunnskap om hva brukere trenger av funksjonalitet når vi starter prosjektet. I smidig prosjektgjennomføring innser vi at vi ikke vet hva de endelige kravene til systemet vil være. Dermed blir det en kontinuerlig prosess å utlede krav fra alle interessenter (stakeholders) og prioritere etter hva som gir mest verdi tilbake til produktet som skal utvikles.

La kunden “sette pris” på funksjonalitet

Utgangspunktet kan gjerne være låst budsjett, fleksibelt omfang. Men hvis kunden på en effektiv måte ser verdien i økt funksjonalitet, kan du endre fokus fra økonomiske rammer til prioritering av funksjonene brukeren faktisk ønsker. Slik kan du bidra til å tilføre mest verdi til produktet i form av nytte, sett i forhold til kost. De pedagogiske utfordringene du eventuelt møter, bør kunne løses ved å bedre kundens forståelse av bl.a kost-nytte og forretningsverdi.

Dette innebærer at du kontinuerlig i prosjektet må kunne tallsette forretningsverdi for de kravene og funksjonene du prioriterer.

Teamet som jobber med prosjektet bidrar med estimatene for kostnadene for de funksjonene man ønsker å få på plass. Men det er produkteier i samarbeid med teamet som må vurdere funksjonene opp mot forretningsverdi, f.eks opp mot allerede definerte KPIer (Key Performance Indicator). Dette betyr at all funksjonalitet man mener skal utvikles bør kunne knyttes opp mot en forretningsverdi. I tillegg er det essensielt at man definerer målbare suksesskriterier slik at man kan måle hvor stor effekt funksjonen har i forhold til styrende KPIer. [Radigan]

Målbare suksesskriterier kan for eksempel være

  • adopsjonsraten til funksjonen; hvor ofte brukerne benytter seg av den
  • hvor mye man konverterer av salg i rene kroner og øre gjennom funksjonen
  • hvor mye funksjonen har redusert antallet sikkerhetsbrudd i en gitt periode
  • eller lignende...



Regelmessig evaluering og revidering

Hva ligger i et “smidig” prosjekt? Smidig vil si å dele opp prosjektet i såkalte iterasjoner; to- til treukers perioder med intensiv jobbing. Inn mot hver periode planlegger vi hva vi skal prioritere i nært samarbeid med produkteier og etter hver periode evaluerer vi arbeidet som er gjort. Dermed kan vi justere målbildet, krav og prioriterte funksjoner før hver arbeidsperiode basert på erfaringene vi har gjort oss i tidligere arbeidsperioder. Prosessen i seg selv blir en kvalitetssikring av at man faktisk tilfører produktet mest mulig verdi.

Dette betyr igjen at du som produkteier bør ha fokus på forretningsverdi, mer enn systemets funksjoner. Hvilke løsninger og funksjoner er det som faktisk understøtter organisasjonens eller avdelingens KPIer?

Hvor beveger andre bransjer seg?

Til og med i en tradisjonell bransje som byggsektoren ser man en bevegelse mot fokus på mer fleksibel prosjektplanlegging. Byggsektoren bruker såkalte samspillkontrakter i mye større omfang enn før. Det vektlegges samspill i totalentrepriser, som i praksis betyr at byggherre, entreprenører, kunde og brukere i høy grad samarbeider om planleggingsfasen og forprosjektfasen. Dette bidrar igjen til at alle parter får større eierskap til prosjektet, og man får mer effektiv bruk av kompetanse og ressurser. [Danielsen]

“Samspill har vist seg å gi lavere kostnad, raskere gjennomføringstid og bedre kvalitet, og er spesielt godt egnet for prosjekter som er teknisk utfordrende, i rehabiliteringsprosjekter og i arbeider med kulturminnebygg” [Grepperud]

Innenfor industrien har det i lang tid vært fokus på lean-prinsipper og kontinuerlig forbedring, såkalt “Lean Manufacturing” og Just-In-time manufacturing som har sine utspring fra effektiviseringsprosesser i Toyota og den japanske bilindustrien på 70-tallet. [Wormack, Jones, Roos]

Hvordan utforme forutsigbare kontrakter i en smidig verden?

Når man har mindre fokus på krav og omfang ved oppstart i et prosjekt, kan det også være utfordrende å gjøre formelle avtaler som regulerer prosjektet på en god måte.

  • Man kan bli enige om å gjennomføre prosjektet på timebasis med en gitt timesats i forhold til hvilke ressurspersoner man bruker.
  • Man kan også gå inn i fastpriskontrakter eller målpriskontrakter, men da må begge parter være klare over at omfang og arbeidsmengde er låst og at man kun kan fortløpende prioritere funksjonalitet (Og dermed nedprioritere annen funksjonalitet) innenfor det budsjettet som er satt.


Uavhengig av merkantile bestemmelser i kontrakten, så kan det være nyttig å lene seg mot veletablerte kontraktsverk som allerede er godt utprøvd. Difi (Direktoratet for forvaltning og IKT) har utarbeidet et sett med kontraktsmaler for kjøp av IT og konsulenttjenester. Disse er utarbeidet i samarbeid med bransjen og blir mye brukt til mange ulike typer IT-prosjekter.


  • Smidigavtalen (SSA-S) kan være fornuftig for større smidige prosjekter. Smidigavtalen er omfattende og krever mye av kundens prosjekteier. Prosjekteier har tydelig ansvar for omfang, men får også mye innflytelse i prosjektets gang.
  • SSA-T er et alternativ hvis leverandør involveres etter produktet i seg selv er definert, men det står igjen en del arbeid i forhold til detaljspesifikasjon.
  • Den enkle bistandsavtalen (SSA-B enkel) er et enklere kontraktsverk for små smidig-prosjekter, hvor man kjøper inn ressurser løpende. [Difi]



Hvis du ønsker å lære mer om Statens standardavtaler, kan det være fornuftig å følge Difi sitt eget nettkurs: https://www.difi.no/opplaeringstilbud/difis-opplaeringstilbud/guide-til-statens-standardavtaler-ssa