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

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

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

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 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

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

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

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

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

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

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

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

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

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

2.5 Metodekritikk 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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):

x Gi veiledning i hvordan prosjekter av en viss type skal gjennomføres, og

innarbeide en felles terminologi og begrepsbruk.

x Ø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.

x Sikre at prosjektdeltakerene har en felles forståelse for hvor i

prosjektforløpet de til enhver tid befinner seg.

30

x Bidra til å sikre at nødvendige beslutninger for prosjektets retning og

fremdrift blir tatt i rett tid og av de riktige beslutningstakerne

x 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

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):

x Søke etter forenklinger

x Omfavne endringer

x Samlokaliserte team

x Klargjøring og fokus på neste utfordring

x Inkrementell endring

x Maksimere kundeverdi

x Lederskap ut ifra behov, stille spørsmål ved handlinger

x Raske tilbakemeldinger til interessenter

x Fokus på kvalitet på hver enkelt leveranse

x 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

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

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

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

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

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

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

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

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

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

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

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

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

- Små og store prosjekter.

- Grad av teknisk kompleksitet

- Om prosjektet er egnet til smidig gjennomføring.

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

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

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

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

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

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

· 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