1. 1
Studentnummer 0219850
Studentnummer 0917681
Studentnummer 0119742
Prosjektoppgave
Arbeid og Velferdsdirektoratet (NAV) - Ny sentral brevløsning
Metodebruk i prosjekter
Fossefall eller smidige metoder.
Ja takk, begge deler?
Konfidensielt
Prosjektoppgave
Master of management
MAN 24341, Prosjektledelse
BI Handelshøyskolen, Oslo
Utleveringsdato: 3.februar 2014
Innleveringsdato: 19. november 2014

2. 2
Forord
Dette er en prosjektoppgave i faget Prosjektledelse utført ved Handelshøyskolen
BI. Studiet er utført i løpet av 2014. Arbeidet med denne oppgaven er tuftet på
nysgjerrighet om metodebruk for prosjekter i store komplekse IT-organisasjoner.
Arbeid og velferdsdirektoratet (NAV) er en stor organisasjon som i dag har ca 14
000 medarbeidere. NAV forvalter rundt en tredjedel av statsbudsjettet og har
nesten hele Norges befolkning blant sine brukere. NAV administrerer over 50
stønader og leverer hundrevis av ulike tjenester. NAV er tilstede i alle kommuner
i Norge.
NAV-IKT har ansvaret for å utvikle datasystemene som blir benyttet i NAV, og
jobber i dag metodisk etter sin egen metode, bygget på en smidig
prosjektmetodikk. Denne metoden heter Systemleveransemetoden referert til i
oppgaven som SLEM 2.0. Vi har i oppgaven plukket ut et prosjekt i NAV og
undersøkt prosjektets erfaringer med NAV IKTs prosjektmetodikk. Denne
oppgaven er ment til å gi et innspill til hvordan metoden bedre kan tilpasses IKT-
prosjekter i NAV. Oppgaven ble utarbeidet i samarbeid med NAV IKT.
Dette har vært en veldig interessant oppgave. Vi har lært mye og håper noe av
dette kan reflekteres videre til lesere av oppgaven. Vi vil rette en stor takk til vår
veileder, Jonas Søderholm, Anne Live Vaagaasaar og Erling S. Andersen for gode
råd. Takk for god veiledning, råd, kunnskap og for å pushe oss til å gjøre alt enda
litt bedre. Vi vil også få rettet en stor takk til alle som har hjulpet oss underveis
med oppgaven.
I NAV takker vi Kjersti Monland, Marte Vidnes Jensen, Hilde Stangnes, Nina
Bremnes, Odd Erik Røste, Hans Petter DeFine og Unn Iren Lothe som har vært
sentrale i å hjelpe oss til å forstå metoden og for å sette av tid til å svare på de
spørsmålene vi hadde, for å stille opp på intervju og for å være tilgjengelig på e-
post når vi trengte hjelp.
Student 0219850,Student 0917681,Student 0119742
BI, Nydalen 18. november 2014

3. 3
Sammendrag
Hensikten med denne oppgaven er å gi et innspill til hvordan systemleveranse-
metoden SLEM 2.0 bedre kan tilpasses IKT-prosjekter i NAV. Vi har gjennom
prosjektet “Ny sentral brevløsning” gått igjennom prosjektets erfaringer med
systemleveransemetoden SLEM, som i NAV går for å være en smidig metode.
Hvis vår oppgave kan bidra til at metoden forbedres eller at organisasjonen rundt
metoden kan få innspill til forbedringer, har vi oppnådd hensikten bak oppgaven.
Dersom forskningsmiljøet finner interesse av oppgaven ser vi på det som en
bonus.
Informantene satte oss på sporet av paradokset mellom behovet for
kombinasjonen av smidig på den ene siden og behovet for fossefallsmetodikk på
den andre og hvordan dette skaper utfordringer for metode og prosjekt. Videre
fant vi at metoden oppfattes som sekvensiell faseinndelt, noe som gir utfordringer
i gjennomføringen og gir uklar rolle- og ansvarsinndeling. Til slutt har vi funnet at
metoden ikke skiller mellom type prosjekter og at det er et behov for dette.
Våre anbefalinger til videre utvikling av prosjektmetode og organisasjon i NAV
IKT:
- Det kan være nyttig å klassifiserer prosjekter i henhold til til for eksempel
teknisk kompleksitet, usikkerhet, grad av brukerinvolvering, kritikalitet,
egnethet til smidig gjennomføring og antall timer.
- Det vil være nyttig å ha forskjellige metoder til ulike prosjekttyper. For
prosjekter med lav kompleksitet, lite omfang eller krav til hurtig
implementering, kan man vurdere en mindre rigid formaliseringsgrad og
mindre byråkratisk kronologisk faseinndeling.
- Større fokus på teamarbeid ved skifte fra fase til fase.
- Klargjøre og sammenstille SLEMs roller med organisasjonens roller.
- Redusere antall roller i metoden fra dagens 19 for en enklere tilpasning til
organisasjonene.
- Bedre metodestyring for endringshåndtering og tilrettelegge for at
elementer som tas ut kan plasseres i senere hovedleveranser.

4. 4
Innholdsfortegnelse
Forord ................................................................................................................................. 2
Sammendrag ....................................................................................................................... 3
Innholdsfortegnelse............................................................................................................. 4
Forkortelser og begrepsforklaringer ................................................................................... 6
Figurer ................................................................................................................................ 7
Tabeller............................................................................................................................... 7
1. Innledning................................................................................................................... 8
1.1 Hensikt og valg av tema ........................................................................................... 8
1.2 Problemstillingen...................................................................................................... 9
1.3Avgrensning............................................................................................................. 10
2. Metode...................................................................................................................... 11
2.1 Valg av metode....................................................................................................... 11
2.2 Primærdata.............................................................................................................. 11
2.2.1 Ustrukturerte intervjuer ....................................................................................... 11
2.2.2 Semistrukturerte intervjuer .................................................................................. 12
2.3 Sekundærdata.......................................................................................................... 14
2.4 Reduksjon av datamengde ...................................................................................... 14
2.5 Metodekritikk ................................................................................................... 15
3. Virksomheten............................................................................................................ 16
3.1 Økonomisk og markedsmessig bakgrunn............................................................... 16
3.2 De involverte avdelingene ...................................................................................... 16
3.4 Systemleveransemetoden SLEM 2.0...................................................................... 18
4. Prosjektet .................................................................................................................. 20
4.1 Mål...................................................................................................................... 21
4.2 Planer.................................................................................................................. 22
4.3 Organisering ....................................................................................................... 23
4.4 Oppfølging.......................................................................................................... 25
4.5 Klimaet i prosjektet............................................................................................. 26
4.6 Faktiske eller forventede resultater..................................................................... 27
5. Teori og litteratur...................................................................................................... 28
5.1 Forskjellige typer prosjekter................................................................................... 28
5.2 Prosjektmetoder...................................................................................................... 29
5.3 Tradisjonelle metoder ............................................................................................. 30
5.4 Smidige metoder..................................................................................................... 31

5. 5
5.5 Kombinasjonen av tradisjonelle og smidige metoder............................................. 31
6. Funn i undersøkelsen................................................................................................ 36
6.1 Funn 1. - Smidighet ................................................................................................ 36
6.2 Funn 2. - Sekvensiell tankegang............................................................................. 36
6.3 Funn 3. - Type prosjekt........................................................................................... 37
7. Analyse og diskusjon................................................................................................ 38
7.1 Funn 1. - Smidighet ............................................................................................... 38
7.2 Funn 2. - Sekvensiell tankegang............................................................................. 40
7.3 Funn 3. - Type prosjekt.......................................................................................... 42
8. Konklusjon................................................................................................................ 45
8.1 Avsluttende ord....................................................................................................... 47
Referanseliste.................................................................................................................... 48
Vedlegg............................................................................................................................. 49

6. 6
Forkortelser og begrepsforklaringer
NAV - Arbeid og velferdsetaten
NAV IKT- Avdeling i Arbeid og velferdsetaten som sentralt vedlikeholder og
utvikler NAVs IKT systemer.
SLEM – Systemleveransemetode (for tiden versjon 2.0). NAV IKT sin
egenutviklede prosjektmetodikk (basert på PRINCE2)
PRINCE2 – Projects in Controlled Environments - Anerkjent rammeverk for
prosjektgjennomføring. Britisk opphav.
Hovedleveranse - NAVs prosjekt for å samtidig utvikle, teste og produksjonssette
mange prosjekter og feilrettinger. NAV har 4 hovedleveranser årlig som hver av
seg har årshjulsinndeling med faser som behovsavklaring, konsekvensvurdering,
konstruksjon, test og produksjonssetting. En hovedleveranse strekker seg over ca.
6 mnd. Omfanget kan strekke seg opp mot 100 000 utviklingstimer totalt.
Tradisjonell prosjektmetode (Fossefallsmetode) - Veletablert metodikk for å
gjennomføre prosjekter som baserer seg på omfattende planlegging før man
sekvensielt begynner gjennomføringen av prosjektet.Eksempler er PMBOK -
Project Management Body of Knowledge.
Agil prosjektmetode (Smidig metode) - Nyere prosjektmetoder som baserer seg
på iterativ modell der man ofte ikke planlegger mye før man begynner utviklingen
av produktet.
JIRA - IT-verktøy i NAV IKT som understøtter prosjektgjennomføring i SLEM
metodikken. Det er et prosjekt og oppgavhånderingssystem.
PROPS - Prosjektmetode utviklet av Ericsson

7. 7
Figurer
Figur 1 Portefølje - og prosjektstyringsmodell (Vedlegg 3 Kommunikasjonsskisse
SLEM 2.0)
Figur 2 Systemleveransemetoden SLEM 2.0s overordnede faser (Vedlegg 3
Kommunikasjonsskisse SLEM 2.0)
Figur 3 Den smidige delen av SLEM 2.0 (Vedlegg 3 Kommunikasjonsskisse
SLEM 2.0)
Figur 4 Prosjektets operative organisering (Prosjektbeskrivelse)
Figur 5 One size does not fit all projects (Shenar, 2001 Management science/Vol.
47, No.3, March 2001)
Figur 6 Domener for Smidig og Tradisjonell prosjektledelse (Barry Boehm and
Richard Turner: Observations on Balancing Discipline and Agility 2003)
Figur 7 Dimension affecting method selection (Barry Boehm and Richard Turner:
Observations on Balancing Discipline and Agility 2003)
Figur 8 Wysockis kvadrant (Wysocki,R. 2006: “Effective Software Project
Management”, Paperback. ISBN-13: 978-0764596360)
Figur 9 Upfront and At end waterfall (M. Cohn, “Succeeding with Agile:
Software Development Using Scrum”, Addison-WesleyProfessional. Boston,
Massachusetts, USA, 2009.)
Tabeller
Tabell 1 Intervjuobjekter ustruktererte intervjuer
Tabell 2 Intervjuobjekter semistrukturerte intervjuer
Tabell 3 Rapportering i prosjektet (Prosjektbeskrivelse)
Tabell 4 Funn 1 (Vedlegg 2 Oppsummert tabell over intervjuresultater)
Tabell 5 Funn 2 (Vedlegg 2 Oppsummert tabell over intervjuresultater)
Tabell 6 Funn 3 (Vedlegg 2 Oppsummert tabell over intervjuresultater)

8. 8
1. Innledning
NAV har tradisjonelt brukt fossefallsmetoden i sine IKT-prosjekter. I de senere
årene er smidig metode innført i systemleveransemetoden (SLEM 2.0).
Litteraturen viser at ingen av metodene er fullkomne, jf. Barry Boehm and
Richard Turner (2003) “No Agile or Plan-Driven Method Silver Bullet“.
Oppgaven vår viser paradokset i at begge metodene lever i beste velgående i NAV
og hvilke konsekvenser dette har for prosjektet “Ny sentral brevløsning”.
Gjennom prosjektet “Ny sentral brevløsning” har vi fått innspill og kunnskap som
kan være med på å forbedre systemleveransemetoden SLEM 2.0 og føre til bedret
prosjektgjennomføring i NAV.
Vi har strukturert denne oppgaven i henhold til etablerte normer. Etter
innledningen så kommer det et kapittel der vi skriver rundt valg av metode og
gjennomføring av datainnsamling. Deretter presenterer vi bedriften,
prosjektmetoden og prosjektet som vi har studert. Deretter presenterer vi utvalgt
teori og resultater fra undersøkelsene som gir grunnlag for neste del; drøfting og
diskusjon. Til slutt er det en konklusjon og oppsummering.
1.1 Hensikt og valg av tema
NAV IKT er en stor organisasjon med tilsammen 493 fast ansatte og 445 innleide
konsulenter som skal arbeide på forskjellige prosjekter samtidig og dette i
samspill behovseierne fra fagsiden av NAV. Man skal bruke mange av de samme
linjeressursene og koordinere prosjektenes gjensidige avhengigheter i en
hovedleveranse. En sentral brikke i dette bildet er NAVs systemleveransemetode -
SLEM 2.0. Metoden favner alt fra behov, konsekvenser, finansiering,
prioriteringer, går igjennom iterative konstruksjonsfaser, til prosjektene blir
produksjonsatt. Metoden definerer samspillet mellom fagsiden som eiere og tre
IKT-avdelinger (Plan og Styring, Prosjekt & forvaltning og Drift), samtidige
prosjekter og hovedleveransen. SLEM er en relativt ny metode (2011) innført i
forbindelse med basisorganisasjonens forberedelser til “Moderniseringsprosjektet”
(FILM). NAV har siden gjort seg noen dyrekjøpte erfaringer med
“Moderniseringsprosjektet” som ble besluttet lagt ned i 2013. I oktober 2014

9. 9
presenterte McKinsey en rapport som medførte til at IKT-direktøren forlot sin
stilling.
Hensikten med denne oppgaven er å kunne bidra til bedret prosjektgjennomføring
ved hjelp av bedret systemleveransemetode. Ved å intervjue sentrale aktører i
prosjektet “Ny sentral brevløsning” og har vi fått verdifull insikt i
problemstillingen. Hvis vår oppgave kan bidra til at metoden forbedres slik at
prosjektene kan gjennomføres bedre, har vi oppnådd hensikten bak oppgaven.
Temaet er valgt på bakgrunn av en av oppgaveskrivernes erfaringer og interesser.
Vi håper at oppgaven kan være interessant for forskningen og da særlig på
forskning rundt kombinasjonen av fossefall og smidige metoder.
1.2 Problemstillingen
Vi ønsket å se på bruken av den smidige prosjektmetoden SLEM i praksis.
Hvordan fungerer metoden i en stor IKT-organisasjon og hvordan oppfattes den
av linjeorganisasjonen? Prosjektet “Ny sentral brevløsning” ble valgt ut på grunn
av stor viktighet for organisasjonen NAV, samt at den hadde passe størrelse og
kompleksitet. Delprosjektleder IKT hadde dessuten erfaring fra å implementere
SLEM 2.0 i organisasjonen, noe som gjorde prosjektet ekstra interessant for oss.
Ved å intervjue sentrale prosjektdeltagere fra prosjektet “Ny sentral brevløsning”
ønsket vi å få perspektiver som belyser hva som fungerer godt i metoden og
hvilke områder som kan forbedres sett med prosjektdeltakerenes øyne.
Problemstilling:
Hvordan kan man bedre tilpasse systemleveransemetoden SLEM 2.0 til IKT-
prosjekter i NAV?
Underproblemstillinger:
1. I hvilken grad er systemleveransemetoden SLEM 2.0 prosjektet smidig i
prosjektet “Ny sentral brevløsning”?
2. Hvorfor trenger prosjektet og NAV IKT en metode som differensierer
forskjellige prosjekttyper?

10. 10
1.3Avgrensning
NAVs utøvelse av prosjektmetodikk omfatter svært mange involverte parter. Vi
har i denne oppgaven valgt å fokusere på prosjektet - “Ny sentral brevløsning” -
erfaringer med metoden SLEM 2.0. Dette gir kun en del av det totale bildet.
Prosjektet er ikke fullført (første del produksjonssettes i desember 2014) og
svarene vi har fått kan bære preg av overdreven positivitet (Andersen, 2003).
Vi har ikke hatt tid til å kvalitetssikre oppgaven med organisasjonen. Det kan
være at intervjuene inneholder feil på grunn av misforståelser mellom intervjuer
og respondent.
Vi har valgt å fokusere på svar intervjuobjektene ga som vi syntes var relevante i
forhold til problemstillingen. Intervjuobjektene ga en rekke innspill som kan være
interessante for andre tema som vi har valgt å ikke kommentere i oppgaven.

11. 11
2. Metode
I dette kapittelet beskriver vi hvilke metoder som er valgt for å fremskaffe
datagrunnlaget for analysen. Vi vil også se på hvordan vi har redusert
datamengden og kritikk av de metodene vi har anvendt.
2.1 Valg av metode
I vår oppgave har vi valgt å benytte oss av intervju som primærmetode for å finne
svar på våre problemstillinger. Dette er en kvalitativ metode som passer godt for
vår problemstilling siden vi har få antall intervjuobjekter. Utformingen av
intervjuene har vært en modningsprosess der vi har gått flere runder for å få
utformet de spørsmålene som vi mener vil kunne fange interessante poeng rundt
vår oppgave.
Metoder som vi anvendte til vår oppgave:
Primærdata:
- Ustrukturerte intervjuer (juni 2014)
- Semistrukturerte intervjuer (august-oktober 2014)
Sekundærdata:
- Innhenting av dokumentasjon fra forskjellige kilder som er beskrevet i
detalj senere i kapittelet.
2.2 Primærdata
2.2.1 Ustrukturerte intervjuer
I tillegg til semistrukturerte intervjuer så utførte vi 5 uformelle samtaler. Dette ble
gjort før sommeren for å få et innblikk i hvordan vi skulle gå videre frem.
Vi planla å utføre noen få intervjuer utstrukturert før vi begynte med utformingen
av intervjuguiden til de strukturerte intervjuene. Disse intervjuene fungerte som en
forundersøkelse. Dette skulle også danne basis for videre valg av retning på
oppgaven og utvelgelse av intervjuobjekter til de semistrukturerte intervjuene.
Årsaken til valg av denne fremgangsmåten er at vi ville finne ut hvor skoen
trykker før vi utformet problemstillingen og spørsmålene til intervjuguiden. Vi

12. 12
ville også her få en pekepinn på hvilke personer som var aktuelle å intervjue samt
bli kjent med organisasjonen og begrepsapparatet.
Bakgrunn for valg av intervjuobjekter
Vi valgt ut intervjuobjekter til de innledende intervjuene på bakgrunn av tips fra
Delprosjektleder IKT. Intervjuobjektene ville dekke de viktigste perspektivene for
å få et solid og bredt inntrykk av prosjektet.
Intervju objekt # Rolle Perspektiv
1 Delprosjektleder IKT Prosjektledelse IKT
2 Delprosjektleder Fag Prosjektledelse Fag
3 Prosjekteier Toppledelse
4 Seksjonssjef IKT Linjeorganisasjon IKT
5 Seksjonssjef Fag Linjeorganisasjon Fag
Tabell 1 Intervjuobjekter ustrukturerte intervjuer
2.2.2 Semistrukturerte intervjuer
Vi valgte å anvende semistrukturerte intervjuer for å kartlegge datagrunnlaget
problemstillingen vår. Vi diskuterte en god del rundt hvordan vi skulle bygge opp
spørsmålstillingen og taktikk for å ikke lede intervjuobjektene alt for mye i den
retningen vi ville (Grennes, 2012).
Intervjuobjektene ble nøye selektert og vurdert for at vi skulle få nødvendig
bredde og perspektiver på området vi skulle undersøke.
Vi ville begrense tidsbruken på hvert intervju til 45-60 minutter. Dette sikrer at
man får godt nok fokus men samtidig ikke blir sliten og at intervjuobjektet føler at
det tar for mye tid av hverdagen. Alle vi planla å intervjue var meget opptatt i en
hektisk jobbhverdag fra før. Intervjuene ble i sin helhet gjennomført på NAV IKT
sine kontorer i Sannergata, Oslo.
Vi har vært bevisst på å lage en intervjuguide som var åpen for de intervjuedes
egne refleksjoner hvor vi som intervjuere kunne fange opp og utdype forhold eller
fenomener vi oppfattet som viktige for den intervjuede.
Målsettingen med intervjuene er todelt:

13. 13
1. Kartlegge prosjektet generelt – Innsamling av materiale til
beskrivelsesdelen av oppgaven.
2. Samle inn materiale til analyse av vår problemstilling.
Bakgrunn for valg av intervjuobjekter
Valg av intervjuobjekter er en omstendelig prosess der innspill fra organisasjonen
og nøye vurdering innad i prosjektgruppa er nødvendig. Vi jobbet en del med
dette og vår målsetting var å mest mulig bredde og variasjon i intervjuobjektene.
Vi ville fange perspektivene til alle fra prosjekteier til utførende konsulent, og fra
fag- og IKT-siden, samt fra planlegging til driftsetting og aktiv bruk.
Vi fikk intervju med sju intervjuobjekter:
Intervju objekt # Rolle Perspektiv
1 Prosjektleder Prosjektledelse
2 Delprosjektleder IKT Prosjektledelse teknisk
3 Delprosjektleder Fag Prosjektledelse Fag
4 Testleder Test
5 Arkitekt Kvalitet
6 Funksjonell rådgiver Utvikling
7 Driftskonsulent Drift
Tabell 2 Intervjuobjekter semistrukturerte intervjuer
Utforming av intervjuguide
For å kunne gjennomføre sammenlignbare intervjuer, så langt som det lar seg
gjøre, har vi utarbeidet en intervjuguide (Vedlegg 1 - Intervjuguide) som beskriver
hvordan vi planla å gjennomføre intervjuene. Vi planla å sette alle
intervjuresultatene inn i en matrise med spørsmål, intervjuobjekter og svar. Dette
ville muliggjøre enkel sammenligning og avdekke ulike eller like oppfatninger fra
intervjuobjektene.
Intervjuguiden vår ble bygget opp etter ønske om at intervjuobjektet skulle først
fortelle litt om hans/hennes oppfatning av prosjektet generelt for så å bevege seg
inn på hva som eventuelt er problematisk eller positivt i prosjektet.

14. 14
Selve intervjuet starter med en innledningsfase der intervjuets lengde avklares –
ca. én time – og bakgrunnen for intervjuet avklares.
Spørsmålsfasen er delt opp i to delfaser: Generelt om prosjektet og detaljert om
prosjektet. Disse fasene gjennomgås i en muntlig form der intervjuobjektet
forteller mest mulig uavbrutt, men veiledes gjennom de valgte temaene av
intervjuer.
2.3 Sekundærdata
Vi brukte følgende kilder for innhenting av sekundærdata:
- Intern NAV IKT prosjektdokumentasjon
- Prosjektdokumentet - Prosjektbeskrivelsen
- Beskrivelse av NAV Systemleveransemetodikk SLEM
- Undersøkelsen “Kompetanse i NAV IKT” - Ukjent 2014
- Undersøkelsen “Kartlegging av NAV IKT” - McKinsey 2014
- Andre prosjektdokumenter og presentasjoner.
NAV har flere ganger tidligere gjennomført undersøkelser som berører vår
undersøkelse. Disse undersøkelsene var spisset mot kompetanse i NAV IKT og
generell organisering av NAV IKT. Vi har anvendt resultatet av disse
undersøkelsene som sekundærdata for vår analyse.
2.4 Reduksjon av datamengde
Etter å ha gjennomført alle de planlagte intervjuene så meldte det seg et behov for
å redusere datamengden og få oversikt over konturene av besvarelsene. Dette viste
seg å være en nyttig øvelse for å heve forståelsen av vår problemstilling. Vi
valgte å sette resultatene av intervjuene inn i en matrise med spørsmålene på Y-
akse og de forskjellige intervjuobjektene på X-akse (Vedlegg 2 - Oppsummert
tabell over intervjuresultater). De forskjellige svarene på spørsmålene ble nøye
diskutert i prosjektgruppen og omarbeidet til å få svarene i stikkordsform. På
denne måten fikk vi et oversiktlig sammenligningsgrunnlag for å begynne
analysearbeidet og identifisere funn.

15. 15
2.5Metodekritikk
Metoden vår baserer seg på semistrukturerte intervju med de involverte i
prosjektet vi studerte. En styrke ved metoden er at den gir et rikt og variert
datatilfang. Intervjuobjektene hadde forskjellige roller på forskjellige nivå i
organisasjonen. Det var også variasjon i om intervjuobjektet var internt ansatt i
NAV eller ekstern leverandør. Ulempen ved måten vi har gjennomført
intervjuene på er at de forskjellige intervjuobjektene alle har forskjellige roller, og
dermed kan man ikke få godt nok grunnlag for å komparativt analysere
synspunkter fra de forskjellige. Dette er også samtidig en styrke at vi hadde
variasjon i rollene til intervjuobjektene og på denne måten fikk dekket forskjellige
perspektiver på de problemområdene som vi undersøkte.
Det er en styrke at en av oppgaveskriverne kjenner prosjektet og organisasjonene
godt. Dette har lettet tilgangen på all nødvendig informasjon og organiseringen av
møter i forbindelse med intervjuer. Det er samtidig en fare for at utvelgelse av
deltagere og utforming av intervjuguide har blitt preget av at enkelte i
prosjektgruppa har god kjennskap til intervjuobjektene. Vi har prøvd å motvirke
dette ved at utvelgelsen ble diskutert blant oppgaveskriverne og konfererte med
sentrale prosjektdeltakere.
Prosjekteier hadde ikke stor kjennskap til og hadde ikke vært involvert i SLEM-
metodikken, og hun uttrykte at hun verken hadde behov eller ønske om dette.
Derfor valgte vi å ikke intervjue prosjekteier under de semistrukturerte
intervjuene.

16. 16
3. Virksomheten
NAV er en organisasjon som i dag har ca. 14 000 medarbeidere. NAV forvalter
rundt en tredjedel av statsbudsjettet, og har nesten hele Norges befolkning blant
sine brukere. NAV administrerer over 50 stønader og leverer hundrevis av ulike
tjenester. NAV er tilstede i alle kommuner i Norge. (Forvaltningsdatabasen
www.nsd.uib.no og NAVs intranett)
3.1 Økonomisk og markedsmessig bakgrunn
NAV driftsbudsjett er på ca. 105 milliarder, hvorav 1,5 milliarder går til IKT.
NAV er i en moderniseringsprosess, og etter den opprinnelige planen skulle den
gjennomgående IT-moderniseringen av NAV koste 3,3 milliarder kroner og være
ferdig i 2018. Dette arbeidet skulle skje i “Moderniseringsprogrammet”, men dette
ble lagt ned i fjor, og en egen organisasjon med 200 ansatte oppløst.
Prosjektet er nå delt opp i mindre prosjekter internt i NAV. Kostnadsrammen er
fortsatt 3,3 milliarder kroner. Prosjektet “Ny sentral brevløsning” var ikke en del
av opprinnelig “Moderniseringsprosjekt”, men anses som en betydelig bidragsyter
til å modernisere NAVs løsninger for effektiv digital kommunikasjon med bruker.
3.2 De involverte avdelingene
NAV Ytelsesavdelingen
Ytelsesavdelingen har ca. 140 ansatte og har hovedansvar for å sikre
forretningsstyrt utvikling og omstilling. Avdelingen har tre seksjoner: Seksjon for
ytelsesfag, seksjon for ytelsessystem, seksjon for fellesfunksjoner. De er eiere av
prosjektet og har spilt inn prosjektforslaget i henhold til NAVs metoder.
NAV IKT
IKT-organisasjonen har 493 ansatte og 445 innleide konsulenter fordelt på tre
avdelinger: Underavdeling for IKT strategi og plan (Plan), Underavdeling for
prosjekt og forvaltning (Build), Underavdeling for drift og produksjon (Run).
Inndelingen henger nøye sammen med systemleveransemetoden Slem 2.0 som vi
har sett nærmere på.

17. 17
3.3 Hvorfor er prosjektet viktig for virksomheten?
Prosjektets formål er å forenkle og forbedre brevproduksjonen og -distribusjonen i
NAV på tvers av fagsystemene og ytelsesområdene, og å sikre en mer enhetlig
brevhåndtering mot brukerne. Det er et omforent ønske at dokumenthåndtering
blir standardisert i NAV. Dette uavhengig av hvilket fagområde
dokumentgrunnlaget kommer fra. Dette initiativet er et viktig skritt for å oppfylle
dette ønsket.
I tillegg vil prosjektet bidra til å innfri målet om å være det digitale førstevalg i
kommunikasjon mellom offentlig forvaltning og innbygger. (Fra
prosjektbeskrivelse)
Prosjektet NSB er delt inn i to delprosjekter:
1) Etablere en felles moderne brevløsning
2) Etablere en kanal til Difis tjeneste for sikker digital post.
Prosjekt som arbeidsform i virksomheten
Prosjektarbeidsformen har i lang tid vært utbredt i virksomheten. Fra tidligere A-
etat og Trygdeetaten finner man prosjekthåndbøker fra tiden før 2006 (da NAV
ble opprettet som en enhet).
Organisasjonen har utarbeidet porteføljestyringsprossess, prosjektstyringsmetode
og systemleveransemetode som henger sammen for total prosjektinitiering, -
gjennomføring og -avslutning.
NAV IKT har en egen prosjektavdeling med 36 interne prosjektledere og
testledere, samt 58 innleide prosjekt og testledere som systematisk gjennomgår
prosjektlederopplæring og opplæring i metode.

18. 18
3.4 Systemleveransemetoden SLEM 2.0
Figur 1: Portefølje - og prosjektstyringsmodell
Skissen over beskriver porteføljestyringsmetoden og prosjektmetoden i NAV.
Slem 2.0 er en metode som som definerer prosessene etter at et IKT-prosjekt er
besluttet i BP 3 til det er produksjonssatt.
Metoden er NAV IKTs smidige metode som skal dekke samarbeid i team,
prioriteringer, dele opp og gradvis forfine, samt dekke leveranseplanlegging og
gjennomføring.
Metodens faseinndeling gjenspeiles i IKT-organisasjonens tre avdelinger Plan,
Prosjekt og Forvaltning og Drift. IKT-verktøyet JIRA understøtter prosessen.
SLEMs 2.0 overordnede faser
Figur 2 Systemleveransenmetoden SLEM 2.0s overordnede faser
Slem 2.0 har seks overordnede faser og følger en logisk kronologisk rekkefølge.
Den er forfinet til 17 forskjellige steg. Det er definert 19 forskjellige utøvende
roller fordelt på fire forskjellige team og 14 forskjellige godkjennende roller i
prosessen (Vedlegg 3 - Kommunikasjonsskisse SLEM 2.0-metoden).

19. 19
Den smidige delen av Slem 2.0
Figur 3 Den smidige delen av SLEM 2.0
Når man er i fasen konstruere, legges det opp til 3 iterasjoner som avsluttes med
demo, test, godkjenning og endringshåndtering. Hovedleveransens årshjul
strekker seg over ca. 4 måneder fra konstruksjon (hvor iterasjonene foregår), via
test til produksjonssetting. Hovedleveransens endringsråd er
koordineringsgruppen som samles en gang per måned. Prosjektene tar initaiv til
endringer. Hvis prosjektene ikke overholder hovedleveransens tidsplaner og
vinduer for konstruksjon er konsekvensen at man blir tatt ut. Dette betyr at en
iterasjon må gjennomføres i løpet av tre uker.

20. 20
4. Prosjektet
Brevløsninger i NAV har tradisjonelt blitt utviklet fagspesifikt og tett knyttet til
fagsystemene som bruker dem. Følgene av dette er at NAV i dag har mange
forskjellige verdikjeder som bare delvis bruker den samme teknologien. Dette
fører til at arbeidet med brev og brevløsninger og endringer av brevmaler og
prosesser oppleves som tungvint og vanskelig. Prosjektet «Ny sentral
brevløsning» skal i løpet av 2014 og 2015 etablere en felles brevløsning i NAV på
tvers av fagsystemer og blir således et viktig første ledd i realiseringen av NAVs
målbilde for dokumentproduksjon og –distribusjon.
Prosjektet NSB er delt inn i to delprosjekter:
1) Etablere en felles moderne brevløsning
2) Etablere en kanal til Difis tjeneste for sikker digital post.
Så hvilken type prosjekt er “Ny sentral brevløsning”? Det finnes mange typer
prosjekter og det finnes ulike typologier for å beskrive dette. Søderlund (2012)
deler inn i de tre prosjekttypene forretnings-, utviklings- og endringsprosjekt
(affärsprojekt, utvecklingsprojekt og förändringsprojekt) som styres av ulike
forutsetninger og som er tilknyttet mer eller mindre ulike problemer. “Ny sentral
brevløsning” kan sies å være et utviklingsprosjekt der mye av fokus er å utvikle
nye systemer i NAV.
Shenar (2001) deler inn prosjektene etter grad av teknologisk usikkerhet og grad
av kompleksitet. I den første dimensjonen mener vi vårt prosjekt vil kunne
karakteriseres som et “Medium Technology Uncertainty Project”, der man baserer
seg hovedsakelig på eksisterende og moden teknologi. Når det gjelder
kompleksitet mener vi det vil være naturlig å klassifisere dette som et “System
Project” der man setter sammen ulike elementer som skal fungere sammen. Vi
skal også være oppmerksomme på at vårt prosjekt er delt opp i to delprosjekter
som har litt ulike karakteristika: Delprosjekt 1 (felles moderne brevløsning) er i
stor grad et programvareuviklingsprosjekt, mens delprosjekt 2 (sikker digital post)
i større grad er en sammenkobling av eksisterende moduler til et system.

21. 21
4.1 Mål
For at et prosjekts mål skal kunne karakteriseres som gode er det flere kjennetegn
som bør være tilstede. Først og fremst er det viktig at man formulerer og skiller
mellom prosjektets formål eller effektmål og prosjektets resultatmål (Andersen,
2005). Effektmål forteller om hensikten med prosjektet og den ønskede fremtidige
situasjonen i basisorganisasjonen. Resultatmål beskriver hva prosjektet skal
levere til basisorganisasjon. Videre kan det være gunstig å etablere en
formålsstruktur med en hierarkisk nedbrytning av prosjektets formål, for å få et
godt beslutningsgrunnlag for å avgjøre hva prosjektet skal gjøre og hva linjen skal
gjøre.
I prosjektbeskrivelsen til “Ny sentral brevløsning” er formålet formulert som “å
forenkle og forbedre brevproduksjonen og –distribusjonen i NAV på tvers av
fagsystemene og ytelsesområdene, og å sikre en mer enhetlig brevhåndtering mot
brukerne”. I tillegg skal prosjektet “bidra til å innfri målet om digitalt førstevalg i
kommunikasjonen mellom offentlig forvaltning og innbygger”. Formålet er brutt
ned i ni effektmål som hver enkelt er koblet mot NAVs virksomhetsstrategi. Når
det gjelder resultatmålene er disse beskrevet i form av 15 prosjektleveranser. For
hver enkelt prosjektleveranse følger det en beskrivelse av hensikt (effektmål), mer
utfyllende beskrivelse av prosjektleveransen, ansvarlige og resultatmålet. Vi ser
altså at det for dette prosjektet er formulert både formål og resultatmål, og at det
er beskrevet en formålsstruktur.
Flere fremhever betydningen av at målene på laveste nivået i hierarkiet må være
godt formulert. Andersen (2005) trekker frem at målene bør være
resultatbeskrivende (dvs. tilstand, ikke aktiviteter), objektivt målbare,
tidsbestemte, utviklende og realistiske. De fleste resultatmålene i
prosjektbeskrivelsen til “Ny sentral brevløsning” er formulert som “Etablere
tjenesten som beskrevet over” eller “Etablere løsningen som beskrevet over”.
Disse resultatmålene og tilhørende beskrivelser fremstår mer som aktiviteter enn
tilstander. Noen av beskrivelsene inneholder formuleringer som “i henhold til
spesifikasjon” eller lignende og har derfor et innslag av målbarhet . Imidlertid er
det flere av målene som ikke har denne typen målbarhet i formuleringen. Tid er
heller ikke tatt med som et element i målene på dette nivået. Når det gjelder
kravene til at målene skal være utviklende og realistiske, er det vanskelig for oss å

22. 22
vurdere i hvilken grad dette er oppfylt. Ser vi dette prosjektets formulering av
resultatmål opp mot teorien på området, kan det se ut til at flere av kravene ikke
blir oppfylt.
Et annet interessant perspektiv er å se på bredden i prosjektets innhold opp mot de
tre elementene i PSO-begrepet (Andersens, 2005). Tanken er at vellykkede
endringer i basisorganisasjonen krever at man balanserer med mål innenfor alle de
tre elementene personutvikling (P), systemutvikling (S), organisasjonsutvikling
(O). Det kan også ofte være formålstjenlig å sette opp egne resultatløp for de tre
elementene. I “Ny sentral brevløsning” ser det ut til at systemutvikling har en
dominerende stilling når det gjelder målformuleringene. Person- og
organisasjonsutvikling har ikke fått en like viktig plass, til tross for at prosjektet
for eksempel organiseres med et eget delprosjekt for innføring og opplæring. Det
kan se ut til at prosjektet med fordel kunne vært mer balansert på de tre
elementene.
4.2 Planer
Planlegging av et prosjekt er sentralt for å sikre prosjektsuksess. Andersen (2005)
understreker betydningen av en nivådeling av planene. Det er viktig å planlegge
hva man skal oppnå før man diskuterer hvordan.
Det første nivået dreier seg om en overordnet, taktisk planlegging, der man lager
milepælsplaner. Andersen (2005) legger vekt på at milepælsplanene bør være
formulert som tilstander på hva prosjektet skal ha oppnådd på et bestemt tidspunkt
og den bør vise de logiske sammenhengene mellom milepælene. På denne måten
vil den kunne være et godt hjelpemiddel for effektiv kommunikasjon mellom
basisorganisasjonen og prosjektet.
I prosjektet «Ny sentral brevløsning» opererer man med 17 hovedmilepæler. Alle
milepælene er formulert som tilstander, som for eksempel «Når 3 brev er
løsningsutformet og estimert», med tilhørende datoer. Rekkefølgen er logisk og
også tidsmessig knyttet opp mot NAVs hovedleveranser slik de er definert i
systemleveransemetoden. Det er ikke synliggjort noen parallelle resultatløp i
planen. Av deltakere i prosjektet oppleves imidlertid tidfestingen av milepælene

23. 23
som lite smidige. Overordnet opererer NAV med en prosjektmetodikk med faser
og beslutningsporter, og for å tilpasse seg denne ble det tidlig satt opp datoer for
milepæler som senere viser seg å være lite hensiktsmessige. Tidsplanleggingen av
prosjektet er i utgangspunktet gjort ved at det er utarbeidet grovestimater av
arbeidet og så lagde man en milepælsplan i februar 2014. På tross av
problematikken rundt tidfesting av milepælsplanen, fremstår den som et godt
kommunikasjonsverktøy og fungerer etter hensikten.
På det andre nivået er man opptatt av å en operasjonell planlegging av aktiviteter.
Denne detaljplanen er viktig for kommunikasjonen mellom prosjektlederen og
prosjektdeltakerne. Ifølge Andersen (2005) er det mest hensiktsmessig å fremstille
disse planene som et Gantt-diagram eller som en nettverksplan. I vårt prosjekt har
de benyttet Gantt-diagram i forbindelse med planleggingen og MS Project blir
benyttet som IT-støtte. Et viktig dilemma som Andersen (2005) tar opp er valget
mellom å synliggjøre en detaljert plan tidlig eller å utsette seg for kritikk på grunn
av manglende planverk. Det synes som om prosjektet «Ny sentral brevløsning»
har klart å avvente detaljplanleggingen. Planleggingen av aktivitetene gjøres 9
uker frem i tid og knyttes opp mot iterasjonene som har tre ukers intervaller.
Det er viktig å ta stilling til usikkerhet i prosjektets planer. Andersen (2005)
mener usikkerhet i prinsippet enten kan være noe positivt eller noe negativt. Vi
kan altså si at vi har både risiko og muligheter. I prosjektbeskrivelsen til “Ny
sentral brevløsning” er det identifisert ni usikkerhetsmomenter, og alle disse er
oppført med årsaksbeskrivelse, konsekvensbeskrivelse med grad av sannsynlighet
(karakter 0-5) og grad av konsekvens (karakter 1-5) og tiltaksbeskrivelse. I
overskriften til usikkerhetstabellen i prosjektbeskrivelsen står det
“Risiko/muligheter”, men ser vi nærmere på usikkerhetsmomentene legger vi
merke til at de alle er risikomomenter og ingen muligheter. Det kunne vært en
styrke om prosjektet også hadde identifisert muligheter.
4.3 Organisering
Prosjektet «Ny sentral brevløsning» er organisert i tråd med etatens
prosjektstyringsmetode. Prosjekter er lagt til Ytelsesavdelingen og eies formelt av

24. 24
Ytelsesdirektør. Prosjektet har en styringsgruppe sammensatt av seksjonsledere
fra Ytelsesavdelingen, Kommunikasjonsstaben, Økonomiavdelingen, IKT-
avdelingen og Tjenesteavdelingen. Figuren nedenfor viser prosjektets operative
organisering.
Fig: Prosjektets operative organisering (Prosjektbeskrivelse)
Når vi ser på hvordan prosjektet organiseres, kan vi skille mellom prosjektets
eksterne og interne organisasjonsstruktur (Andersen, 2005). Den eksterne
organisasjonsstrukturen ser på forholdet mellom basisorganisasjonen og
prosjektet, mens den interne organisasjonsstrukturen ser på forholdet mellom
prosjektlederen og prosjektmedarbeiderne, samt prosjektmedarbeiderne imellom.
Når det gjelder den eksterne prosjektorganiseringen er «Ny sentral brevløsning»
organisert som en matriseorganisasjon der prosjektmedlemmene delvis er overført
fra forskjellige deler av basisorganisasjonen til prosjektet. Andersen (2005) skiller
mellom svak matrise, balansert matrise og sterk matrise (prosjektmatrise), og han
mener en sterk matrise er å foretrekke. I vårt prosjekt ligger ansvaret for
arbeidsutførelsen og leveransene hos prosjektlederen og har dermed
kjennetegnene til en sterk matrise. Ser vi på bemanningsplanen i
prosjektbeskrivelsen finner vi at prosjektmedlemmene er allokert til prosjektet
etter en prosentvis andel. Prosjektleder og to av delprosjektlederne arbeider fulltid

25. 25
i prosjektet, mens øvrige deltakere deltar i varierende grad. Av 19 definerte roller i
bemanningsplanen er hele 10 roller definert til å være tilgjengelig for prosjektet
ved behov eller med en 30 %-andel eller lavere. At så mange deltakere er på så lav
tilgjengeligsandel i prosjektet, mener vi kan ha en del ulemper med hensyn til
tilhørigheten til prosjektet.
Intern organisering i prosjektet kan gjøres på forskjellige måter. Andersen (2005)
er inne på fire aktuelle løsninger: Isomorf, matrise, flatt fellesskap og autoritær
ekspert. I vårt prosjekt kan det se ut til at de hovedsakelig organiserer seg etter en
intern matrisestruktur der prosjektdeltakerne blir fordelt på oppgavene etter sin
ekspertise. Vi har imidlertid ikke nok grunnlag i vår undersøkelse til å entydig
konkludere med dette. Det har imidlertid kommet fram under intervjuene at ikke
alle rollene er like klart definert i SLEM, og dette har skapt noen utfordringer i
prosjektet. Spesielt gjelder dette noen koordinatorroller.
4.4 Oppfølging
I oppfølgingen av prosjektet sier Andersen (2005) det er viktig å få et helhetlig
bilde av prosjektet og kritiske suksessfaktorer, og denne oppfølgingen må
resultere i korrigerende tiltak når det er nødvendig. Han sier videre at milepælene
er viktige kontrollmekanismer i basisorganisasjonens oppfølging av planene.
Prosjektet «Ny sentral brevløsning» har månedlige styringsgruppemøter der
rapport for økonomi og milepæler gjennomgås. Denne rapporteringen baserer seg
på PRINCE2, og rapportene sendes over til styringsgruppen en uke før møtet.
Eventuelle avvik fra milepælene vil dermed fremkomme i rapporteringen og i
styringsgruppemøtet. Etter styringsgruppemøtet blir rapporten oversendt
porteføljestyret. Så langt i prosjektet har det kun oppstått én situasjon der en
milepæl har blitt flyttet, og denne flyttingen har ikke hatt konsekvenser for øvrige
milepæler eller dato for avslutning av prosjektet.
Rapporteringen fra prosjektet er synliggjort på følgende måte i
prosjektbeskrivelsen:
Rapport type Til Fra Når

26. 26
Statusrapport Styringsgruppen Prosjektleder Til hvert SG møte
Statusrapport NAV
Porteføljestyring
Prosjektleder Månedlig iht vedtatte
frister
Evalueringsrapport
og sluttrapport
Styringsgruppen Prosjektleder Ved prosjektavslutning
Tabell 3 Rapportering i prosjektet
Prosjektlederen mottar ukentlige rapporter fra delprosjektlederne og disse
gjennomgås i ukentlige møter mellom prosjektleder og delprosjektledere.
Rapportene blir også sendt til styringsgruppeleder.
Den daglige oppfølgingen av utviklingsoppgaver gjøres av delprosjektlederen for
IKT. Han gjennomfører to statusmøter i uken med prosjektdeltakerne, samt at de
har daglige SCRUM-møter.
Det kan se ut til at deltakerne i prosjektet oppfatter oppfølgingsfrekvensen som
bra. Imidlertid kan det virke som om man kan stille spørsmål til omfanget av
rapporteringen og om rapporteringen gir svar på de viktigste elementene.
4.5 Klimaet i prosjektet
Godt samarbeidsklima har betydning for at et prosjekts suksess (Hoegel og
Gemuenden, 2001).Av intervjuene har vi fått et klart inntrykk fra
prosjektdeltakerne at det er et godt klima i prosjektet. De fleste prosjektdeltakerne
sitter på samme kontoradresse og selv om de ikke sitter ved siden av hverandre
opplever de at det ikke er lang vei til de andre deltakerne. Prosjektet “Ny sentral
brevløsning” består i realiteten av to prosjektforslag som ble slått sammen til ett
prosjekt. Mye av arbeidet i de to delene foregår uavhengig av hverandre. Vårt
inntrykk er at de ulike delene ikke samarbeider mye, men dette føles naturlig for
prosjektdeltakerne selv.
Majoriteten av prosjektdeltakerne jobber med dette prosjektet på en lav
prosentandel eller ved behov. Dette kan potensielt føre til at prosjektdeltakerne
føler en mindre tilhørighet til prosjektet og at det igjen påvirker klimaet negativt.
Så langt i prosjektet ser det imidlertid ikke ut som om dette har vært tilfellet. En

27. 27
refleksjon vi gjør oss er at prosjektet ikke ennå hadde hatt noen leveranser da vi
intervjuet prosjektdeltakerne og at de derfor ennå ikke hadde hatt “kniven på
strupen” når det gjelder måloppnåelsen. Så tidlig i prosjektet er alle positive og
beskriver derfor samarbeidsklimaet som godt.
4.6 Faktiske eller forventede resultater
Når prosjektet de faktiske eller forventede resultatene? For å få et bilde av dette
vil det være naturlig å se på hvordan prosjektet ligger an i forhold til milepælene.
Andersen (2005) betoner betydningen av milepælene som kontrollstasjoner
underveis for måloppnåelsen.
Prosjektet har klart å nå milepælene underveis og det ser derfor ut til at de ligger
an til å nå de forventede prosjektresultatene. Underveis i prosjektet har
styringsgruppen endret tidspunktet for én av milepælene. Dette forklares med at
denne milepælen ble satt unødvendig tidlig, og det er forventet at denne endringen
ikke vil påvirke leveransene.
Det er fortsatt lenge igjen til prosjektet avsluttes (desember 2015), og prosjektet
har ennå ikke hatt noen leveranser. Det er derfor for tidlig å si noe om faktiske
resultater. Et annet aspekt er om prosjektets leveranser oppfyller
basisorganisasjonens formål og oppnår de effektmålene. I forbindelse med
prosjektet har det blitt definert både kvantitative og kvalitative gevinster, men det
er selvsagt alt for tidlig å si noe om denne måloppnåelsen.

28. 28
5. Teori og litteratur
I dette kapittelet vil vi gi en kort oversikt over hvilken teori vi synes er relevant å
presentere for oppgaven. Vi har valgt å bygge opp denne delen med å først si litt
om forskjellige typer prosjekter og klassifisering av disse, deretter litt rundt
prosjektmetoder og anvendelse. Deretter litt teori om bruken av tradisjonell
prosjektledelse basert på fase/sekvens og sammenligne dette med nyere smidig
tilnærming til prosjektledelse. Til slutt presenterer vi nyere teori som omhandler
hvordan man kan bruke både tradisjonell og smidig tilnærming sammen i
prosjektledelse.
5.1 Forskjellige typer prosjekter
Man kan dele inn prosjekter i forskjellige kategorier ut i fra størrelse,
kompleksitet, risiko, strategisk betydning og bransje (Shenar, 2001, samt Shenar
og Dvir, 1996). Det er i de forskjellige variantene stor forskjell på hvordan
arbeidet gjøres, hvordan kommunikasjonen fortoner seg og hvordan effektivt
lederskap utøves (Shenar, 2001).
Variabel Prosjekttype: Teknologisk usikkerhet
Liten Middels Høy Ekstremt høy
Antallet iterasjoner Bare en syklus En til to Minst to To til fire
Frysning av design i
forhold til
gjennomføringsfasen
Før Tidlig frys, ikke
senere enn i første
fjerdedel
Vanligvis i første
eller andre
fjerdedel
Sent, vanligvis i andre
eller tredje fjerdedel
Kommunikasjon og
interaksjon
Mest formell
forhåndsbestemt
kommunikasjon.
Få møter
Økt utveksling av
informasjon
Stor grad av
kommunikasjon
på mange måter,
uformell kontakt
vanlig
Omfattende
kommunikasjon på alle
måter, lagt til rette for
uformell kontakt.
Prosjektlederen Gode adm
kunnskaper
Noen tekniske
kunnskaper
Gode tekniske
kunnskaper
Usedvanlig dyktig
innenfor teknologien
Prosjektdeltakerene Få akademikere Omtrent
halvparten
akademkikere
Mange spesialister
og akademikere
Høyt kvalifiserte
spesiallister, høy andel
akademikere
Ledelsesstil og holdning Fast stil, holder
seg til opprinnelig
plan
Moderat
standhaftig
Moderat fleksibel,
forventer mange
endringer
Svært fleksibel, lever
med kontiniuerlige
endringer.
Figur 5. Forskjellige typer prosjekter (Shenar, 2001, samt Shenar og Dvir, 1996)

29. 29
Prosjekter bør gjennomføres på prinsipielt forskjellige måter avhengig av
teknologisk usikkerhet (Andersen, 2005). En observasjon er at prosjekter med høy
teknologisk usikkerhet gjerne har en mer iterativ arbeidsform. Ledelsen av
prosjektet er mer medmenneskelig istedenfor autoritær og de har også gjerne tung
teknologikompetanse. Man kan i tillegg se forskjell på prosjekter som primært
arbeider med å sette sammen komponenter til en enhet, prosjekter som arbeider
med systembygging av flere enheter eller prosjekter som arbeider med å sette
sammen mange enheter til å fungere sammen (nettverk/program) (Shenar, 2001).
Shenar sammenfatter sin konklusjon i en setning: «One size does not fits all».
Tanken om at alle prosjekter kan behandles på samme måte er ikke realistisk
(Andersen, 2005).
5.2 Prosjektmetoder
De aller fleste store foretak som bruker prosjekt som arbeidsform har en eller
annen form for formalisert prosess for å styre sine prosjekter (Engwall, 2003).
En prosjektmodell kan utvikles fra grunnen av for å dekke spesielle behov, eller
det kan tas utgangspunkt i en eksisterende modell som er tilgjengelig. I begge
tilfeller er det viktig å finne en balanse mellom formalisering og kreativ frihet for
å få de ønskede effektene av prosjektmodellen. En prosjektmodell skal være et
støtteverktøy og ikke en tvangstrøye som skal følges med en teoretisk tilnærming.
Man bør unngå å formalisere og byråkratisere da man kan risikere å miste det som
er prosjektarbeidets styrke; kreativitet, hurtighet og fleksibilitet. (Andersen, 2005).
Et godt eksempel på en velutviklet prosjektmodell er Ericssons PROPS modell
(Engwall, 2003, samt Linde, 2004).
Fordelene med en prosjektmodell er blant annet (Engwall, 2003):
Gi veiledning i hvordan prosjekter av en viss type skal gjennomføres, og
innarbeide en felles terminologi og begrepsbruk.
Øke den enkelte medarbeiders innsikt i hva som skal utføres av det faglige
og administrative oppgaver på de ulike trinn/faser i prosjektet, samt gi støtte i
planleggingsdelen av prosjektet.
Sikre at prosjektdeltakerene har en felles forståelse for hvor i
prosjektforløpet de til enhver tid befinner seg.

30. 30
Bidra til å sikre at nødvendige beslutninger for prosjektets retning og
fremdrift blir tatt i rett tid og av de riktige beslutningstakerne
Gi et verktøy for erfaringsoppsamling ved at modellen løpende oppdateres
på grunnlag av nye erfaringer fra gjennomførte prosjekter.
5.3 Tradisjonelle metoder
Den tradisjonelle prosjektmetodikken baserer seg på en filosofi om at man vet alt
man skal gjøre i starten og at man ikke kan gå tilbake for å planlegge noe på nytt.
Utviklingsprosjekter var før tradisjonelt styrt etter sekvensielle modeller (Engwall,
2003). Dette innebærer at en fase må ferdigstilles før en ny fase kan påbegynnes. I
teknologiske komplekse prosjekter skaper dette mye hodebry siden man ofte ikke
vet eksakt hvordan ting skal gjøres når man planlegger prosjektet. Sekvensielle
modeller er også ofte kalt fossefallsmodeller (Andersen, 2005).
Styrken ved denne metodikken er at den inneholder en struktur som tillater
detaljert planlegging før gjennomføring. (Engwall, 2003). Ved å gi de ulike fasene
godt beskrevne trinn vil man kunne følge opp prosjektet og til enhver tid se
hvordan arbeidet går. Man kan også legge inn beslutningspunkter mellom de ulike
fasene og evaluere verdien av prosjektet mot kostnaden av gjennomføringen og se
hvorvidt det fortsatt er lønnsomt. Ved fullførelsen av hver fase gjennomfører man
en vurdering av status, kvalitet på utført arbeid og endringer i risikobildet.
Svakheten er at prosjekter gjerne er utsatt for uventede hendelser og man sjelden
har all informasjon tilgjengelig ved prosjektoppstart (Engwall, 2003).
Det som ble planlagt i tidlig fase av et prosjekt er antagelig ikke den optimale
leveransen ved prosjektets avslutning. Prosjektet må være lydhørt og åpent for å
endre seg i takt med endringer i dets omgivelse for å kunne levere et relevant
produkt (Kreiner, 1995). En mer nyansert versjon av tradisjonell prosjektledelse
er en videreutvikling av fossefall mot en fontenemodell. Dette innebærer at man
starter flere aktiviteter samtidig istedenfor sekvensielt. Denne retningen appellerer
til komplekse prosjekter som er under sterkt tidspress og kombinerer tradisjonell
og smidig tankesett (Lindkvist, Söderlund & Tell, 1998).

31. 31
5.4 Smidige metoder
Når prosjektmål og løsning er usikre og det er høy sårbarhet så trengs det et
alternativ til tradisjonell prosjektledelse (Fernandez & Fernandez, 2008). Smidig
prosjektmetodikk baserer seg på filosofien om at man ikke vet alt i starten av
prosjektet. Og hvis man har rammer for prosjektet så kan disse sannsynligvis
endre seg underveis (Wysocki, 2006). Metoden omfavner endring og læring
underveis (Meso & Jain, 2006). Smidige prosjektmetoder er strukturert slik at et
team eller organisasjon lærer raskt, får tidlig tilbakemelding og kan luke ut feil
tidlig. Gjennom en kontinuerlig prosess med læring og tilpasning så skapes det
verdi (Takeuchi & Nonaka, 1986).
Kjennetegn ved smidige metoder er (Fernandez & Fernandez, 2008):
Søke etter forenklinger
Omfavne endringer
Samlokaliserte team
Klargjøring og fokus på neste utfordring
Inkrementell endring
Maksimere kundeverdi
Lederskap ut ifra behov, stille spørsmål ved handlinger
Raske tilbakemeldinger til interessenter
Fokus på kvalitet på hver enkelt leveranse
Produsere dokumentasjon der det gir verdi
Styrken til denne metoden er den spenstige dynamikken den gir. Man er på den
ene siden godt rustet til å håndtere usikkerhet ved kontrollerte praktiske forsøk. På
den andre siden er det vanskelig å gi et estimat for hele prosjektets tids- og
ressursforbruk siden prosjekteier kan endre alle forutsetningene mellom
iterasjonene (Fernandez & Fernandez, 2008).
5.5 Kombinasjonen av tradisjonelle og smidige metoder
Tradisjonelle prosjekter er ofte veldokumenterte og spesifiserte. I kontrast til dette
så er smidige prosjekter ofte preget av høy usikkerhet som avtar etterhvert som
iterasjoner gjennomføres. Smidie prosjekter har også større muligheter til å raskt
komme inn på riktig spor igjen ved feilskjær (Fernandez & Fernandez, 2008).

32. 32
Styrker ved en smidig modell er gode endringsmuligheter underveis, men den
mangler disiplin og evnen til å håndtere store, komplekse prosjekter. Tradisjonelle
metoder har fordelen med god dokumentasjon som muliggjør disiplin og felles
forståelse av mål og løsning. Men svakheten er at det er tungt å endre kurs samt at
dokumentasjons-prosessen kan bli for omfattende (Boehm & Turner, 2003).
Tradisjonelle prosjektledere styrer gjerne sitt prosjekt etter tid, kost og kvalitet.
Avvik kan måles opp mot planverket. En tradisjonell prosjektleder vil forsøke å
redusere risiko og holde seg innenfor tid og kost. Den smidige prosjektlederen vil
fokusere først på produksjon av kundeverdi og deretter tid og kost (Fernandez &
Fernandez, 2008).
Tradisjonell prosjektmetodikk egner seg godt til distribuerte team med både
seniorer og juniorer på grunn av omfattende dokumentasjon og spesifikasjoner
som eksisterer (Fernandez & Fernandez, 2008). Noen mener at mye av suksessen
bak bruken av smidige metoder er at man rett og slett anvender mer erfarne
prosjektdeltakere enn i tradisjonelle prosjekter (Fernandez & Fernandez, 2008).
Hvordan kan man kombinere de to metodene? En smidig metode kan dra nytte av
tradisjonell prosjektmetodikk sine klare retningslinjer på prosjektoppstart og
avslutning, kommunikasjon, integrasjon, kost og usikkerhetshåndtering. Likedan
kan tradisjonell prosjektledelse dra nytte av smidig metodes selvstendige team,
fleksibilitet og evnen til å håndtere store endringer. Smidig metode fasiliterer også
sterk involvering av kunden og reduserer dokumentasjonskravet (Frye, 2009).
Bruksområdet for disse to metodene sin originale form er forskjellig, så valget av
metode avhenger av prosjekttype og miljøet rundt (Frye, 2009). Boehm and
Turner (2003) presenterer en inndeling for hvilke typer prosjekter som egner seg
for tradisjonell og smidig metode.

33. 33
Usikkerhetsområde Plandrevet når ex: Smidig når ex:
Teknisk Kjente løsninger. Mange valg og lav
kompetanse i org
Interessenter Mange interessenter og
mye koordinering
Interessenter sitter tett og
integrert med prosjekt
Systemkompleksitet Stor koordinering mellom
mange systemer
Enkle systemer eller
endepunkter man har god
kontroll over.
Kritikalitet på gevinst eller effekt Når høy grad av kritikalitet Enkel test i markedet
Endringsrisiko Når prosjektet har lav
endringsgrad og stort
scope-kontrollbehov
Når det er stor
sannsynlighet for at ny
kunnskap vil komme og at
markedet endrer seg.
Tidsrisiko Når man har behov for
fundamenterte løsninger og
hurtighet ikke er et valg.
Når man har behov for å
komme ut med noe raskt
Figur 6: Domener for Smidig og Tradisjonell prosjektledelse (Boehm & Turner
2003)
De presenterer også en figur for å kunne karakterisere om et prosjekt egner seg for
smidig eller tradisjonell prosjektledelse (Boehm & Turner 2003):
Figur 7 Dimension affecting method selection (Boehm & Turner 2003)

34. 34
Hvis man havner nær sentrum på alle aksene så er prosjektet klart mest egnet for
smidig metode. Hvis man havner ute i periferien så er det tradisjonelle metoder
som antageligvis vil fungere best.
Fernandez & Fernandez (2008) presenterer også en måte å karakterisere prosjekt i
henhold til Wysockis (2006) kvadrant:
Figur 8: Wysockis kvadrant (2006)
Her skiller man mellom lineære, inkrementelle, iterative og ekstreme metoder. Og
kobler disse mot prosjektets klassifisering i henhold til Wysockis kvadrant (2006).
Cohn (2009) foreslår en hybridmodell ved å bruke tradisjonell prosjektledelse “Up
front”, smidig tilnærming i gjennomføringen og tradisjonell prosjektledelse “At
end”. Dette sikrer disiplin i kravspesifikasjon, dokumentasjon og planlegging,
smidig gjennomføring og disiplinert test, overlevering, lukking og
gevinstrealisering.

35. 35
Figur 9 Upfront and At end waterfall (Cohn, 2009)
Trenden er at moderne utviklingsprosjekter innen IT trenger en miks av
tradisjonell og smidig metodikk. Prosjektmetode er viktig i et prosjekt, men vel så
viktig er HR, verdier, kommunikasjon og forventningsstyring. Verken tradisjonell
eller smidig metode er en perfekt løsning til alle prosjekter. Man må alltid se an
type prosjekt og deretter velge metode for å styre prosjektet (Boehm & Turner,
2003).

36. 36
6. Funn i undersøkelsen
Hensikten med denne delen av oppgaven er å presentere hovedfunnene fra vår
undersøkelse. Vi avgrenser presentasjonen til hovedfunnene for å justere
oppgavens lengde i henhold til de tildelte rammer. Det komplette resultatet fra
undersøkelsen kan fremskaffes på forespørsel.
6.1 Funn 1. - Smidighet
Metoden Slem 2.0 er i seg selv smidig, men erfaringer fra prosjektet viser at
metoden møter organisasjonens behov for fossefall.
Fem av syv intervjuobjekter tar opp dilemmaet mellom prosjektets behov for
smidig og den mottakende organisasjonens behov eller tradisjon for fossefall.
1.Prosjekt- leder 2.Delprosjekt-
leder IKT
3.Delprosjekt-
leder Fag og
Prosjekteier
4.Prosjekt-
deltaker
Arkitekt
5.Prosjekt-
deltaker
Testleder
Missing link
mellom milepæl og
agilt
I rene tekniske
prosjekter bør man
avklare behov og
løsningsbeskrive
tidligere og
samtidig.
Milepæler ble satt i
prosjektplanen,
mens SLEM legger
opp til en dynamisk
og iterativ
leveranse av
løsningsbeskrivelse
r.
Milepæl vs smidig.
Smidig SLEM 2.0
metodikk betyr
usikkerhet på hva
som faktisk blir
levert!
Slem 2.0 bør ha
mer fokus på nytte
enn metode
Mangler overbygg
mellom prosjektet
og senere
prosjekter.
Det å ta ut saker (tasks)
er ikke metodestyrt, kun
det å ta inn.
Tabell 4. Funn 1
6.2 Funn 2. - Sekvensiell tankegang
Metoden Slem 2.0 oppfatters som en sekvensiell måte å jobbe på og
sammenlignes med at en stafettpinne beveger seg fra rolle til rolle.
Tre av syv intervjuobjekter tar opp at SLEM-metodikken preges av sekvensiell
tilnærming der man går fra fase til fase uten at man i plenum er enige om at man
skal gå videre. Ansvaret flyttes til neste ansvarlige uten at det nødvendigvis er
enighet om dette. Dette fører til en stafettpinne-tankegang der man av og til må ta
et steg tilbake fordi kvaliteten ikke er bra nok på en gjennomført fase.

37. 37
1.Prosjekt- leder 5.Prosjekt-
deltaker
Testleder
6.Prosjekt-
deltaker
Funksjonell rådgiver
Når man endrer status i metoden
endrer man ansvaret - stafettpinne.
Man burde sitte sammen for å
endre fasene?
Samarbeid og teamfølelse blir ikke
understøttet pg.a stafettpinne tankegangen
og uklare roller.
SLEM 2.0 pulveriserer ansvaret i noe grad.
Ved avvik er det problematisk at ingen vet
med en gang hvem som er ansvarlig for
hva.Mangler ansvarskart og forankring.
Denne versjonen mangler fokus på verdi og
samarbeid i team
Tabell 5. Funn 2
6.3 Funn 3. - Type prosjekt
Metoden SLEM 2.0 skiller ikke mellom type prosjekter
Av totalt syv intervjuer, svarer fire at metoden ikke skiller mellom type prosjekter.
Informantene sier at prosjektet er utpreget teknisk og at metoden ikke tar hensyn
til dette. Svarene er sammenstilt i tabellen under:
1.Prosjektleder 3.Delprosjekt- leder Fag og
Prosjekteier
4.Prosjekt- deltaker
Arkitekt
7.Prosjekt-
deltaker
Driftskonsulent
Metoden skiller ikke på
type prosjekt.
Passer ikke for SDP ( rent
teknisk prosjekt).
Behov for fast track (Eks
politiske beslutninger)
Skille mellom type
prosjekter i metoden
Små saker blir store.
Behov for forenkling for
små saker.
Tabell 6. Funn 3

38. 38
7. Analyse og diskusjon
Vi vil i denne delen av oppgaven diskutere hovedfunnene i undersøkelsen. For
hvert hovedfunn diskuterer vi dette opp mot vår tolking, mot øvrige resultater i
undersøkelsen og mot det teoretiske grunnlaget. I hvert avsnitt er det en
oppsummering og en delkonklusjon.
7.1 Funn 1. - Smidighet
Metoden Slem 2.0 er i seg selv smidig, men erfaringer fra prosjektet viser at
metoden møter organisasjonens behov for fossefall.
Diskusjon
Prosjektleder, delprosjektleder IKT og delprosjektleder fag tar opp
problemstillingen med milepælsplanlegging tidlig i prosjektet kontra behov for
smidig tilnærming senere under konstruksjon prosjektet. Prosjektet har behov for
å jobbe parallelt med behov, konsekvensvurderinger, løsningsbeskrivelser og
konstruksjon, mens metoden er faseinndelt og ser på dette som adskilte
kronologiske faser. Gjennom en kontinuerlig prosess med læring og tilpasning så
skapes det verdi (Takeuchi & Nonaka, 1986).
Cohn (2009) foreslår hybridmodell mellom fossefall og smidig hvor man er
fossefallsorientert “up front”, smidig i konstruksjon og fossefallsorientert “at
end”.
Frye (2009) viser til at bruksområdet for disse to metodene sin orginale form er
forskjellig, så valget av metode avhenger av prosjekttype og miljøet rundt.
Vi tolker SLEM 2.0 til å passe inn i modellen fra Cohn (2009). Metoden har
ulemper som prosjektet påpeker ved at milepæler er fastsatte, og faseinndelingen
tilsier at behovsutredninger, konsekvensvurderinger, løsningsbeskrivelser og
konstruksjon skal foregå i kronologisk rekkefølge. Fordelene er at man på denne
måten kan dekke ledelsens behov for forutsigbarhet og linjeorganiasasjonens
behov for planlegging av mottak av prosjektet.
Ulempen er at prosjektet ser at disse fasene ikke nødvendigvis er kronologiske.

39. 39
Wysocki (2006) viser til at smidig prosjektmetodikk baserer seg på filosofien om
at man ikke vet alt i starten av prosjektet. Og hvis man har rammer så kan disse
sannsynligvis endre seg underveis. Dette illustrerer dilemmaet som prosjektet
opplever.
Prosjekteier uttaler at SLEM 2.0 for henne betyr usikkerhet på hva som faktisk
blir levert. Testleders uttaler at å ta ting ut av leveransen ikke er metodestyrt, noe
som bekrefter prosjekteiers usikkerhet. Arkitekten sier at det mangler overbygg
mellom prosjektet og senere prosjekter, noe vi samlet tolker til at selve problemet
er at man ikke har metode for å ta ut saker og ta det inn igjen i senere leveranser.
Dette medfører at eier er utrygg på om hele leveransen faktisk blir levert. I tillegg
har man i metoden en fase hvor finansiering skal avklares (tidlig fase).
Finansieringen følger budsjettåret og ikke saker i SLEM. Vi tilker dette til å være
medvirkende til at dette er vanskelig å håndtere i metoden.
Fernandez og Fernandez (2008) viser til at styrken ved bruk av smidig metodikk
er gode endringsmuligheter underveis, mens svakheten er manglel på disiplin og
evnen til å håndtere store komplekse prosjekter. Tradisjonelle metoder har
fordelen med god dokumentasjon som muliggjør disiplin og felles forståelse av
mål og løsning. Men svakheten er at det er tungt å endre kurs samt at
dokumentasjonsprosessen kan bli for omfattende (Boehm & Turner, 2003).
Man mangler steg i metoden for å justere prosjektomfanget ned. Man mangler
fase/steg for avvikshåndtering. En observasjon er at SLEM 2.0 beskriver
endringshåndtering etter hver iterasjon i konstruksjon. Prosjektene kan vedta
endringene, men må i tillegg ha hovedleveransens godkjenning. Fra
sekundærmatriale ser vi at Hovedleveransens koordineringsgruppe møtes en gang
i måneden for å beslutte endringer. Dette kan i mange tilfeller være for sent og
understøtter ikke behovet for smidig utvikling.
Et paradoks vi har observert er at intervjuobjektene påpeker at dette er et
komplekst teknisk prosjekt med lange verdikjeder (IKT-Prosjektleder intervju) og
det er behov for en mer iterativ tilnærming, mens teorien (Boehem & Turner,
2003) viser til behov for fossefallstilnærminger når det er behov for stor

40. 40
koordinering mellom mange systemer. Styrken ved denne fossefallsmetodikken er
at den inneholder en struktur som tillater detaljert planlegging før gjennomføring
(Engwall, 2003).
Oppsummering
Oppsummert viser våre funn, relevant litteratur og våre tolkninger at SLEM 2.0 er
en hybridvariant mellom fossefall og smidig metode. Et paradoks er at den
fremstilles som en smidig metode internt i NAV.
Vi ser at prosjektet har behov for å jobbe smidig i fasene behov,
konsekvensvurdering, løsningsbeskrivelse og konstruksjon, hvor metoden er
utpreget faseinndelt og kun smidig i konstruksjonsfasen (med observert
byråkratisk endringshåndtering i hovedleveransen), noe som gir relativt lite verdi
for prosjektet.
Vi ser at organisasjonen på ledelsesnivå har behov for forutsigbarhet, på
hovedleveransenivå behov for planlagt koordinering av mange prosjekter og på
IKT driftsnivå behov for forutsigbarhet. Behovene fra organisasjonen tilsier bruk
av fossefallsmetodikk.
Videre ser vi at metoden mangler steg for å ta ut saker og plassere de i senere
leveranser, noe som også har sammenheng med finansieringsmodellen i NAV.
Dette gjør den byråkratisk og lite tilpasset smidige behov.
7.2 Funn 2. - Sekvensiell tankegang
Metoden Slem 2.0 er preget av en sekvensiell måte å jobbe på og
sammenlignes med at en stafettpinne beveger seg fra rolle til rolle.
Diskusjon
Mange av intervjuobjektene pekte på at metoden SLEM oppfattes som en
faseinndelt metode der det er litt for brå overganger mellom fasene. Og
vedkommende som endrer fase samtidig flytter ansvaret vekk fra seg selv. Noen
peker på at man burde heller sitte samlet under overgangen til en ny fase

41. 41
istedenfor at en prosjektdeltaker tar beslutningen om å ta prosjektet videre i en ny
fase. I forhold til smidig tankegang så bør man sitte samlokalisert og diskutere
status på prosjektet og bli enige om videre fremdrift. Ifølge Cohn (2009) så er et
av kjennetegnene og styrkene med en smidig tilnærming at man jobber i
sammensveisede team.
Flere intervjuobjekter sier at sekvensoppdelingen er bra for enkelte prosjekttyper i
NAV IKT. Dette gjelder spesielt prosjekter der man ikke skal levere kodelinjer
men heller levere en integrasjon av systemer. Dette er i tråd med teori som flere
forskningsartikler presenterer (Boehm & Turner, 2003, samt Shenar, 2003).
Noen peker også på at det er en positiv effekt av stafettpinnetankegangen, siden
man effektivt kan gå videre i prosjektsyklusen og man sikrer at alle blir involvert
og konferert. Men da uten at man slipper å møtes til formelle
godkjenningssesjoner. I teorien om smidige metoder er det nevnt at styrken ved
metodikken er at kommunikasjon, kompetanseoverføring og dokumentasjon av
prosjektets tilstand skjer uformelt. Dette er i kontrast til tradisjonelle metoder der
man investerer mye tid og krefter i dokumentasjon og spesifikasjon, samt at man
kommuniserer mye formelt gjennom møter (Boehm & Turner, 2003). Vi anser det
som en styrke å unngå mye møtevirksomhet.
I forbindelse med sekvensiell tankegang så er det mange som også peker på at
rolle- og ansvarsfordeling er uklar. Det eksisterer ikke et omforent ansvarskart på
tvers av linje og prosjektorganisasjon. Det er også et problem med koordinering
og ansvarsdeling mellom prosjektleder og delleveranseledere. Siden prosjektet er
preget av høy teknisk kompleksitet så viser teorien at det da gjerne er behov for
hyppig koordinering, kommunikasjon og klare roller (Shenar, 2003). Fra metoden
SLEM 2.0s kommunikasjonsskisse ser vi at man opererer med 19 ulike roller. En
observasjon her er at det kan synes hensiktsmessig å begrense antallet roller i
metoden for enklere kobling og grensesnitt mot basisorganisasjon.
Oppsummering
I SLEM metodikken er det mange faser/steg og mange roller. Antall faser/steg og
roller oppfattes av noen som negativt og andre positivt. Dette avhenger av type

42. 42
prosjekt. Ved å ha mange faser/steg og roller så sikrer man at alle de viktige
interessentene blir konferert. Dette er etter vår mening spesielt viktig ved teknisk
komplekse prosjekter som berører mange systemområder og brukere. Svakheten
her er at prosjektdeltakeren ikke sitter mye i plenum og diskuterer oppnådd
kvalitet og progresjon i hvert steg. Man beveger seg heller videre i prosjektet uten
at fasen/steget er gjennomført med tilstrekkelig kvalitet. Her kunne man gjerne
sittet sammen i team og beslutte videre gang i prosjektet. Ved en mer lettere
prosjekttype så vil antall faser/steg og roller føles som unødvendig og byråkratisk.
Det er her etter vår vurdering behov for å differensiere SLEM metoden på type
prosjekt. Vi mener også et behov for å redusere antall roller i metoden.
7.3 Funn 3. - Type prosjekt
Metoden SLEM 2.0 skiller ikke mellom type prosjekter.
Diskusjon
Prosjektleder og delprosjektleder IKT viser til at deler av prosjektet på mange
måter et rent teknisk prosjekt som ikke har noen funksjonell side og at det er
behov for at metoden differensierer dette.
Vår tolkning er at SLEM 2.0 ikke understøtter differensiering av type prosjekt,
størrelse, risiko, strategisk betydning, kompleksitet jamfør klassifiseringen av
Shenar (2001) og Shenar & Dvir (1996). Det er i de forskjellige variantene stor
forskjell på hvordan arbeidet gjøres, hvordan kommunikasjonen fortoner seg og
hvordan effektivt lederskap utøves. Vi finner ikke at Slem 2.0 heller har noen
form for veiledning på prosjekttype nivå. En velutviklet metodikk skal gi
veiledning i hvordan prosjekter av en viss type skal gjennomføres (Engwall 2003).
Ericssons PROPS modell (Engwall 2003) (Anneli Linde 2004) er omtalt som et
eksempel på en velutviklet prosjektmetodikk.
Prosjekteier henviser til at politiske beslutninger kan bety at man må ta snarveier,
eller “Fast Track”, for å komme raskere frem til løsning. Dette gjelder for
eksempel ved lovendringer og ved politiske beslutninger som krever hurtig
implementering. Vi tolker dette i retning av at metoden har behov for en litt
forenklet, mindre byråkratisk og iterativ tilnærming i slike tilfeller. Andersen
(2005) sier dette om formalisering:

43. 43
En prosjektmodell skal være et støtteverktøy og ikke en tvangstrøye som skal
følges med en teoretisk tilnærming. Man bør unngå å formalisere og byråkratisere
da man kan risikere å miste det som er prosjektarbeidets styrke; kreativitet,
hurtighet og fleksibilitet.” Videre sier Andersen (2005) at “Prosjekter bør
gjennomføres på prinsipielle forskjellige måter avhengig av teknologisk
usikkerhet.”
Prosjektets arkitekt ser også behov for å skille mellom type prosjekter i metoden
og nevner at SLEM bør ha mer fokus på nytte enn metode. Vår tolkning er at
metoden har behov for å skille ut enklere prosjekter og stille færre formelle krav
til disse. Prosjektmetode er viktig i et prosjekt, men vel så viktig er HR, verdier,
kommunikasjon og forventningsstyring (Boehm & Turner, 2003).
Driftskonsulenten svarer at små saker blir store i Slem og at man har behov for
forenkling. Det er også et uttrykt behov for å skille mellom prosjekter med høy
grad av brukerinvolvering i motsetning til prosjekter der det kun er snakk om
sammenkobling av tekniske systemer i bakkant av brukergrensesnitt. Dette er
tilfellet med prosjektet vi har studert også, det ene delprosjektet er preget av
brukerinvolvering og det andre er et rent integrasjonsprosjekt.
Oppsummering
Oppsummert viser våre funn og vår tolkning at SLEM 2.0 ikke understøtter
differensiering av type prosjekt, størrelse, risiko, strategisk betydning,
kompleksitet jamfør klassifiseringen av Shenar & Dvir (1996). Dette gir uheldige
konsekvenser for prosjektgjennomføringen i form av unødig bruk av ressurser,
vanskeligheter med enkelt å kunne sette på rett type kompetanse og stort
dokumentasjonskrav for enkle oppgaver. Dette understøttes av funn fra
intervjuene og i litteraturen.
Funn fra intervjuene viser behov for “Fast track” for strategisk viktige prosjekter.
Fast track tolkes av oss som at i enkelte tilfeller må man ha et hurtig ubyråkratisk
måte å løse problemstillingene på.
Dette gjelder også behov for å skille:
- Tekniske og funksjonelle prosjekter

44. 44
- Små og store prosjekter.
- Grad av teknisk kompleksitet
- Om prosjektet er egnet til smidig gjennomføring.

45. 45
8. Konklusjon
I denne delen av oppgaven konkluderer vi først på de to underproblemstillingene,
for så å konkludere på hovedproblemstillingen. Avslutningsvis kommer vi med
noen kommentarer til konklusjonene våre.
Underproblemstiling 1: I hvilken grad er systemleveransemetoden SLEM 2.0
smidig i prosjektet “Ny sentral brevløsning”?
Vår konklusjon er at systemleveransemetoden SLEM 2.0 er i liten grad smidig for
prosjektet.
Analysen vår viser at selve metoden SLEM 2.0 er en hybridvariant mellom
fossefall og smidig metode, men fremstilles som en smidig metode internt i NAV.
For prosjektet “Ny sentral brevløsning” er systemleveransemetoden SLEM 2.0 i
stor grad en fossefallsmetode hvor de mange måneder i forveien må definere
milepæler. Konsekvensen av dette er lite rom for smidig gjennomføring.
Smidigheten i metoden er i fasen konstruksjon. Fasen er tidsmessig låst i
hovedleveranseløpet og forutsetter at løsningsbeskrivelsen er gjort i tidligere
faser, noe som gir lite rom for reell smidighet.
Metoden Slem 2.0 er preget av en sekvensiell måte å jobbe på og sammenlignes
med at en stafettpinne beveger seg fra rolle til rolle. Metoden oppleves som
faseinndelt, noe som ikke er i tråd med smidig tankesett. Vi ser at utviklingsdelen
er smidig, men at det i starten og slutten av fasene benyttes fossefall. Uklar roller
og manglende ansvarskart forsterker opplevelsen av sekvensiell arbeidsmetode.
Prosjektets eier opplever usikkerhet ved om hele leveransen faktisk blir levert som
følge av det smidige elementet i metoden.
Underproblemstilling 2: Hvorfor trenger prosjektet og NAV IKT en metode
som klassifiserer forskjellige prosjekttyper?
Vi ser at det er stor bredde av prosjekter i NAV som alle må gjennom samme
metodikken. Litteraturen og intervjuene viser at en metodikk ikke passer alle
prosjekttyper, og for å bruke ressursene hensiktsmessig og gjennomføre

46. 46
prosjektene med suksess ser vi at NAV IKT vil ha behov for en metode som
klassifiserer forskjellige prosjekttyper.
Vår analyse viser at prosjektet “Ny sentral brevløsning” delvis er en ren teknisk
leveranse hvor metoden til dels er uhensiktsmessig. Metoden SLEM 2.0 skiller
ikke mellom type prosjekter. Prosjektet har ønske om å jobber smidigere enn
metoden tillater i konstruksjonsfasen. Litteraturen viser til gode grunner for å
skille prosjekttyper fra hverandre og behandle disse forskjellig.
Hovedproblemstilling: Hvordan bedre tilpasse systemleveransemetoden
SLEM 2.0 til IKT Prosjekter i NAV?
Våre anbefalinger til videre utvikling av prosjektmetode og organisasjon i NAV
IKT:
- Det kan være nyttig å klassifiserer prosjekter i henhold til til for eksempel
teknisk kompleksitet, usikkerhet, grad av brukerinvolvering, kritikalitet,
egnethet til smidig gjennomføring og antall timer.
- Det vil være nyttig å ha forskjellige metoder til ulike prosjekttyper. For
prosjekter med lav kompleksitet, lite omfang eller krav til hurtig
implementering, kan man vurdere en mindre rigid formaliseringsgrad og
mindre byråkratisk kronologisk faseinndeling.
- Større fokus på teamarbeid ved skifte fra fase til fase.
- Klargjøre og sammenstille SLEMs roller med organisasjonens roller.
- Redusere antall roller i metoden fra dagens 19 for en enklere tilpasning til
organisasjonene.
- Bedre metodestyring for endringshåndtering og tilrettelegge for at
elementer som tas ut kan plasseres i senere hovedleveranser.

47. 47
8.1 Avsluttende ord
Man kan støtte seg til mye teori i prosjektledelse, men man kommer ikke utenom
at prosjektledelse er operativ situasjonsbestemt ledelse der handlinger og
prosesser må tilpasses situasjonen. Prosjektmetodikken skal fungere som et
støtteverktøy og ikke oppleves byråkratisk.
Modne prosjektorganisasjoner evner å bruke metodikken for å skape mer effektive
prosjekter. Umodne prosjektorganisasjoner opplever ofte metodikk som
byråkratisk og tungvint.
Man må se på prosjektets karakter før man velger metode. Både tradisjonell og
smidig metode har sine styrker og svakheter. Hvis man klarer å hente ut de beste
elementene fra begge og samtidig unngå de negative elementene, og tilpasser
dette til type prosjekt, så har man et godt utgangspunkt for en god metodikk.

48. 48
Referanseliste
1. Andersen, E. S. (2005). “Prosjektledelse: et organisasjonsperspektiv”
(Vol. 8). Bekkestua: NKI-forl.
2. Boehm,B. and Turner,R. (2003): “Observations on Balancing
Discipline and Agility”
3. Cohn,M. (2009): “Succeeding with Agile: Software Development
Using Scrum”, Addison-WesleyProfessional. Boston, Massachusetts,
USA, 2009.
4. Engwall, M. (2003): “Mysteriet med den orimliga modellen: Om
utvecklingsmodeller, kunskap och kontroll”, Nordiske
Organisasjonsstudier, 5(4): 28-53.
5. Fernandez, D. J., & Fernandez, J. D. (2008). “Agile project
management – Agilism versus traditional approaches”. Journal of
Computer Information Systems, 49(2), 10-17.
6. Frye, C., (2009) “Can traditional project management and agile
development coexist?” Software Quality News, 18 Feb 2009.
7. Grenness, T. (2012). “Påbyggingskurs i kvalitativ metode” (Vol.
Lørdag 21. januar)
8. Hoegel, M. & H. G. Gemuenden (2001): “Teamwork Quality and the
Success of Innovative Projects: A Theoretical Concept and Empirical
Evidence”, Organization Science, 12(4): 434-449.
9. Johnson, G. (1992): “Managing strategic change: strategy, culture
and action”, Long Range Planning, Vol. 24, No. 1: 28-36.
10. Kreiner, K. (1995): “In search of relevance: Project management in
drifting environments”, Scandinavian Journal of Management, 11(4):
335-346.
11. Linde,A & C.Raisanen (2004): “Technologizing Discourse to
Standardize Prosjects in Multi -Project Organizations: Hegemony by

49. 49
Consensus?” SAGE Publications 2004.
12. Lindkvist, L., J. Söderlund & F. Tell (1998): “Managing product
development projects: On the significance of fountains and
deadlines”, Organization Studies, 19(6): 931-951.
13. Meso, P. &. R. Jain (2006): “Agile software development:
adaptive systems principles and best practices”, Information Systems
Management, 23(3): 19-30.
14. Shenhar, A. & D. Dvir (1996): “Toward a typological theory of
project management,” Research Policy, Vol. 25:607-632.
15. Shenhar, A. J. (2001): “One size does not fit all projects:
Exploring classical contingency domains”, Management Science,
47(3): 394-414.
16. Söderlund, Jonas. (2005). “Projektledning & projektkompetens :
perspektiv på konkurrenskraft”. Malmö: Liber.
17. Takeuchi, H. & I. Nonaka (1986): “The new new product
development game”, Harvard Business Review, January-February:
137-146.
18. Wysocki,R. (2006): “Effective Software Project
Management”, Paperback. ISBN-13: 978-0764596360
Vedlegg
1. Intervjuguide
2. Oppsummert tabell over intervjuresultater
3. Kommunikasjonsskisse - SLEM 2.0-metoden

50. 50
Vedlegg 1: Intervjuguide
Kartlegge prosjektet generelt – innsamling av materiale til beskrivelsesdelen
av oppgaven
Mål
· På hvilken måte er prosjektets formål og mål kommunisert til prosjektgruppen?
· Opplever du formål og mål som tydelige?
Planer
· I hvilken grad opplever du planene som et godt hjelpemiddel/mindre bra
Organisering
· Er rollene klart definert?
· Er det noen roller som mangler eller som ikke fungerer optimalt?
Oppfølging
· Hvordan oppleves rapporteringen? Hva er bra/mindre bra?
· Hvor ofte avholdes det oppfølgingsmøter? Oppleves det som passe/mye/lite?
Klimaet i prosjektet
· Hvordan opplever du klimaet i prosjektet?
· Hvordan samhandler man i prosjektet? Hva fungerer/fungerer mindre bra?
Faktiske eller forventede resultater
· Når prosjektet de forventede resultatene?
· Hvordan håndteres eventuelle avvik? Hvilke utfordringer opplever du med dette?
Kartlegge hvordan de forskjellige oppfatter våre problemstillinger
Kunnskap om metoden

51. 51
· Hvor godt kjenner du til metodikken SLEM 2.0?
· Er det noen deler du kjenner bedre enn andre i metoden? Best/dårligst
· Hvor lenge har du anvendt metoden?
· Hvilken opplæring har du fått i metoden?
· Oppfatter du dette som tiltrekkelig? Hva ønsker du av opplæring?
Bruk av metoden
· Følges metoden i NSB prosjektet? Hvis ikke, hva er årsaken til dette?
Egenskaper ved metoden
· Hvilke positive effekter ser du ved bruken av SLEM 2.0,?
· Hvilke negative effekter ser du ved bruker av SLEM 2.0? Hvorfor, hva fører det
til, forslag til forbedring?
Stegene/Fasene i metoden
· Synes du alle stegene/fasene i metodikken er hensiktsmessige?
· Hvilke faser opplever du som bra? Hva er det som er bra? Og hva bidrar dette til?
· Hvilke faser opplever du som dårlige? Hvorfor, hva fører det til, forslag til
forbedring?
· Hvilke faser opplever du som dårlige? Hvorfor, hva fører det til, forslag til
forbedring?
· Hvilke faser har du ingen forhold til?
Roller og beslutninger i metoden
· Hvordan opplever du at rollene i metoden fungerer? Hvorfor, hva fører det til,
forslag til forbedring?
Avslutning
· Bidrar metoden til at prosjektene blir bedre gjennomført eller er det en negativ
effekt?
· Har du deltatt i NAV-prosjekter før SLEM ble innført?
· Hvordan opplevdes den forrige metodikken ifht SLEM? Er det en forbedring med
SLEM

52. 52