• No results found

Ledelse av store komplekse prosjekter

N/A
N/A
Protected

Academic year: 2022

Share "Ledelse av store komplekse prosjekter"

Copied!
130
0
0

Laster.... (Se fulltekst nå)

Fulltekst

(1)

Ledelse av store komplekse prosjekter

Sandra Therese Nilsen

Masteroppgave våren 2016

(2)
(3)

Sammendrag

Denne studien hadde som hensikt å kartlegge i hvor stor grad informasjonsinfra- strukturteori(II) kunne supplere, eventuelt erstatte, tradisjonell prosjektledelses- teori i store komplekse prosjekter. Ettersom store komplekse prosjekter har sin bakgrunn i II-teorien, har disse prosjektene en annen grad av kompleksitet enn tradisjonelle IT-prosjekter. Det ville derfor være nyttig å kartlegge hvor sterkt den tradisjonelle prosjektledelsesteorien står i disse prosjektene, og om II-teorien burde være et supplement som en måte å håndtere kompleksiteten på. Studien er vinklet opp mot de fire mest sentrale delene av et prosjekt: standardisering, planlegging, organisering og oppfølging.

På grunn av en økende teknologisk vekst, vil dette være med på å skape en form for kompleksitet i organisasjoner og bedrifter som ikke har funnets tidligere. Dette gjør at store komplekse prosjekter i økende grad bli mer aktuelle, som en måte å håndtere kompleksiteten på. Det vil derfor være hensiktsmessig å forstå hvordan denne typen prosjekter bør styres og om den tradisjonelle prosjektledelseslitteratu- ren fortsatt er aktuell.

Studien ble gjennomført som en case studie hvor seks store prosjekter med en høy grad av kompleksitet ble undersøkt. Casene var svært varierte og omhandlet alt fra rene tekniske endringer til organisatoriske omstruktureringer. Fellesnevneren var at de omfattet et stort antall aktører, både tekniske og ikke-tekniske.

Resultatene fra studien viser at den tradisjonelle prosjektledelseslitteraturen fortsatt står sterkt i store komplekse prosjekter, men at supplement fra II-litteraturen kan bidra til å skape et mer vellykket prosjektresultat. Bakgrunnen for dette er at II- litteraturen tar høyde for det menneskelige aspektet i mye større grad enn prosjekt- ledelseslitteraturen. Ettersom det er det menneskelige aspektet som i aller størst grad er med på å skape kompleksitet, kan man si at II-litteraturens supplement i store komplekse prosjekter håndterer det aspektet av prosjektene som gjør dem mer komplekse enn de tradisjonelle IT-prosjektene.

(4)
(5)

Forord

Arbeidet med denne oppgaven har vært både interessant og lærerikt, men også en svært krevende prosess. Jeg føler meg ekstremt heldig som har fått muligheten til å skrive en masteroppgave om noe som så genuint interesserer meg. Jeg har lært veldig mye om store komplekse prosjekter og det å skrive en lang akademisk tekst, men også mye om meg selv. Det å jobbe alene med et så stort prosjekt er en kjempeutfordring, men likevel føler jeg at jeg har vokst mye og fått enda bedre kjennskaper til mine egne styrker og svakheter.

Først og fremst vil jeg rette en stor takk til min veileder, Bendik Bygstad. Takk for at du har hatt troen på meg gjennom hele prosessen og at du har delt av dine kunnskaper. Jeg har satt stor pris på dine konstruktive tilbakemeldinger som gjorde at jeg kom i mål med oppgaven.

Jeg vil også takke mine seks informanter som tok seg tid til meg og delte av sine kunnskaper og erfaringer om store komplekse prosjekter. Uten dere ville det ikke vært noen masteroppgave.

Jeg vil også rette en stor takk til mamma og pappa som har støttet meg gjennom hele studietiden og oppmuntret meg når motivasjonen har vært på bunnen. Og ikke minst, kjære Amund, takk for din tålmodighet og kjærlighet gjennom hele denne prosessen. Du har vært en uvurderlig støtte for meg.

Sandra Therese Nilsen Oslo, 2. mai 2016

(6)
(7)

Innhold

1 Introduksjon 1

1.1 Bakgrunn for studien . . . 1

1.2 Motivasjon . . . 3

1.3 Problemstilling . . . 4

1.4 Oppgavens disposisjon . . . 5

2 Litteratur 7 2.1 Prosjektledelse . . . 7

2.1.1 Prosjektledelsesrammeverk . . . 8

2.1.2 PRINCE2 . . . 9

2.1.3 De syv prosessene . . . 10

2.2 Informasjonsinfrastruktur . . . 13

2.2.1 Tilpasning av II-litteraturen . . . 14

2.3 Store komplekse prosjekter . . . 15

2.3.1 Hva er et vellykket prosjekt? . . . 16

2.4 Prinsipper for koordinering . . . 17

2.4.1 Prosjektledelse . . . 17

2.4.2 Informasjonsinfrastruktur . . . 19

2.5 Plan . . . 20

2.5.1 Prosjektledelse . . . 20

2.5.2 Informasjonsinfrastruktur . . . 21

2.6 Organisering . . . 23

2.6.1 Prosjektledelse . . . 23

2.6.2 Informasjonsinfrastruktur . . . 24

2.7 Oppfølging . . . 25

2.7.1 Prosjektledelse . . . 25

2.7.2 Informasjonsinfrastruktur . . . 26

2.8 Oppsummering . . . 28

3 Metode 29 3.1 Paradigme . . . 29

3.2 Metode . . . 30

3.2.1 Innhenting av caser . . . 32

(8)

3.3 Teknikk . . . 32

3.3.1 Litteraturstudie . . . 33

3.3.2 Dokumentanalyse . . . 34

3.3.3 Intervju . . . 34

3.4 Analyse . . . 36

3.4.1 Unntak . . . 37

3.5 Validitet . . . 38

4 Etikk 41 4.1 Personvernombudet . . . 41

4.2 Lydopptak . . . 41

4.3 Oversikt over informanter og bedrifter . . . 42

4.4 Anonymisering . . . 42

5 Case 43 5.1 Prosjekt A . . . 43

5.2 Prosjekt B . . . 44

5.3 Prosjekt C . . . 45

5.4 Prosjekt D . . . 46

5.5 Prosjekt E . . . 46

5.6 Prosjekt F . . . 47

6 Funn 49 6.1 Generelt . . . 49

6.2 Prinsipper for koordinering . . . 50

6.2.1 Standardiserte prosesser . . . 50

6.2.2 Tekniske standarder . . . 51

6.2.3 Resultat . . . 53

6.3 Plan . . . 53

6.3.1 Prosjektplaner . . . 53

6.3.2 Planer for organisk vekst . . . 56

6.3.3 Resultat . . . 57

6.4 Organisering . . . 58

6.4.1 Hierarkisk ledelse . . . 58

6.4.2 Ledelse for innovasjon . . . 59

6.4.3 Resultat . . . 61

6.5 Oppfølging . . . 61

6.5.1 Prosjektoppfølging . . . 61

6.5.2 Kultivering . . . 62

6.5.3 Resultat . . . 63

6.6 Funn . . . 63

(9)

INNHOLD

7 Diskusjon 67

7.1 Forventet mønster og observert mønster . . . 67

7.2 Pattern Matching . . . 69

7.2.1 Prinsipper for koordinering . . . 69

7.2.2 Plan . . . 72

7.2.3 Organisering . . . 75

7.2.4 Oppfølging . . . 78

7.2.5 Svar på problemstilling . . . 81

8 Konklusjon 83 8.1 Bidrag til prosjektledelseslitteraturen . . . 83

8.2 Hva bidrar til et vellykket prosjektresultat? . . . 84

8.3 Eventuelle forbedringer . . . 85

8.4 Videre arbeid . . . 85

Referanser 86 A Appendix A 91 A.1 Sammendrag Prosjekt A . . . 91

A.2 Sammendrag Prosjekt B . . . 94

A.3 Sammendrag Prosjekt C . . . 96

A.4 Sammendrag Prosjekt D . . . 100

A.5 Sammendrag Prosjekt E . . . 103

A.6 Sammendrag Prosjekt F . . . 107

B Appendix B 113 B.1 Intervjuguide . . . 113

B.2 Kvittering fra personvernombudet . . . 116

B.3 Samtykkeskjema . . . 117

B.4 PRINCE2 Prosessmodell . . . 118

(10)
(11)

Figurer

1.1 Tradisjonelt prosjekt . . . 2

1.2 Stort komplekst prosjekt . . . 3

2.1 Vippepunkt for innføring av standarder . . . 18

2.2 Forholdet mellom plan og kaos . . . 22

Tabeller

2.1 Oppsummering litteratur . . . 28

6.1 Prinsipper for koordinering oppsummert . . . 53

6.2 Plan oppsummert . . . 57

6.3 Organisering oppsummert . . . 61

6.4 Oppfølging oppsummert . . . 63

6.5 Funn . . . 64

7.1 Oppsummering diskusjon . . . 67

7.2 Forventet mønster . . . 68

7.3 Observert mønster . . . 68

(12)
(13)

Kapittel 1

Introduksjon

Informasjonsinfrastrukturer(II), ofte kalt store komplekse systemer, kjennetegnes for sin frie vekst og kontinuerlige tilpasning til dens brukere (Monteiro, Pollock, Hanseth og Williams 2012). Bakgrunnen for dens kompleksitet ligger i at den er et sosioteknisk nettverk bestående av både tekniske og menneskelige aktører. Der- som man utelukkende ser på de tekniske komponentene og hvordan de er knyttet sammen, vil det i de fleste tilfeller betraktes som et strukturert og organisert nett- verk. Et slikt nettverk er det man kan beskrive somkomplisert – altså et nettverk bestående av mangelike, men sammenhengende komponenter (Oxford Dictiona- ries 2015a). Så fort man involverer menneskelige aktører i et komplisert nettverk, vil det finnes mangeulike, men sammenhengende komponenter og man har derfor etkomplekstnettverk (Oxford Dictionaries 2015b). Hvert enkelt menneske har sin egen personlighet og erfaringer som gjør at vi alle skiller oss fra hverandre. Dette gjør at hver person som inkluderes i et stort komplekst system, vil fungere som en ny type komponent.

1.1 Bakgrunn for studien

En stadig økende digitalisering har gjort det til en selvfølgelighet at bedrifter ofte- re kjøper inn nye digitale komponenter for å tilpasse bedriften til de ansatte. Dette gjør bedriftene avhengig av å utarbeide og opprettholde en smidig og fleksibel inte- grasjonsarkitektur, som gjør at innføring av nye systemer ikke setter begrensninger for fremtiden. For å sørge for dette er det helt avgjørende å ha et bevisst forhold til kompleksiteten som finnes i store komplekse systemer, hva som skaper økt kom- pleksitet og hvordan det kan håndteres.

Når nye systemer innføres i en bedrift arrangeres dette ofte som et prosjekt. Det nye systemet integreres som en del av systemene som allerede finnes i bedriften og prosjektet har som oppgave å sørge for en så smidig integrasjon som mulig.

Brukere læres opp, og på samme måte som at systemene integreres med hverandre, må brukerne integreres med systemene. En avgjørende faktor i et slikt prosjekt, er at brukerne ser nytten av å innføre en ny måte å utføre arbeidsoppgaver på ved å

1

(14)

implementere et nytt system. Avhengighet og interaksjon mellom menneskelige og tekniske komponenter gjør disse prosjektene omfattende, og man kan derfor stille seg spørsmålet om de kan regnes som helt vanlige IT-prosjekter.

Et tradisjonelt IT-prosjekt består som oftest av et kunde-leverandør-forhold hvor kunden etterspør et prosjekt til en avtalt pris og kvalitet innenfor et bestemt tidsrom, og leverandøren leverer så produktet i henhold til disse kriteriene. Blant både kunde og leverandør finnes det gjerne flere interessenter som har en oppfat- ning av hvordan prosjektet best kan gjennomføres og hvilke kriterier som skal veie tyngst i det avsluttende resultatet. I tillegg til dette finnes det gjerne en prosjekt- leder på leverandørsiden og en på kundesiden, som har som ansvar å sørge for at prosjektet kommer i havn for begge parter. Uavhengig av hvor mange prosjektlede- re og interessenter som finnes, er det likevel som oftest bare to parter i tradisjonelle IT-prosjekter, nemlig kunde og leverandør slik som illustrert i figur 1.1.

Figur 1.1: Tradisjonelt prosjekt

II-prosjekter skiller seg fra de tradisjonelle prosjektene på den måten at det ikke finnes noe tydelig skille mellom kunde og leverandør, men derimot finnes det en rekke interessenter som prosjektlederen trekkes mellom. Årsaken til dette er at pro- sjektene i stor grad handler om å effektivisere og optimalisere eksisterende løsnin- ger, som gjøres ved hjelp av fokus på god brukertilpasning og fleksibel integrasjon mellom systemene (Hanseth og Bygstad 2014). Det er bedriften selv som etterspør prosjektet samt leverer den nye løsningen, og inntar derfor rollen som både kunde og leverandør. Prosjektene omfatter ofte også veldig mange og ulike systemer, og totalt sett er dette med på å skape en kompleksitet som ikke finnes på samme måte i tradisjonelle IT-prosjekter. Prosjektlederens posisjon i store komplekse prosjekter er illustrert i figur 1.2.

Ut ifra disse prosjektbeskrivelsene, mener jeg derfor at mange av de store og omfattende prosjektene som gjør store strukturelle endringer i en organisasjon , ikke lenger kan kalles et alminnelig IT-prosjekt, men derimot et II-prosjekt. For å gi denne typen prosjekter et mer beskrivende navn, velger jeg i stedet å kalle dem store komplekse prosjekter. Jeg mener dette er et mer illustrerende navn og et mer allment kjent begrep enninformasjonsinfrastrukturprosjekter.

(15)

1.2. MOTIVASJON 3

Figur 1.2: Stort komplekst prosjekt

1.2 Motivasjon

Som min personlige motivasjon som gjennomføring av studien, syntes jeg det ville være interessant å se i hvor stor grad II-litteraturen kan bidra til den tradisjonelle prosjektledelseslitteraturen i store komplekse prosjekter. Jeg har stor interesse for prosjektledelse, og synes det derfor er ekstra interessant å kunne se på prosjekter som er mer sammensatte og har en høyere grad av kompleksitet enn mindre en- keltstående prosjekter. I tillegg til dette mener jeg at store komplekse prosjekter er høyst aktuelle ved at den digitale kompleksiteten er stadig økende. Ved gjennom- føring av forskning på ledelse av denne typen prosjekter, legger man til rette for at oppmerksomheten vendes mot at ikke alle prosjekter ikke nødvendigvis kan styres på samme måte og at man i økende grad må fokusere på å håndtere kompleksitet og planlegge for fleksibel integrasjon mellom menneskelige og tekniske aktører.

Innen både prosjektledelse og IIer finnes det mye forskning som beskriver alt fra teoretiske konsepter til hvordan de fungerer i praksis. Det som det derimot finnes svært lite forskning på er hvordan disse fagfeltene fungerer sammen, alt- så hvordan prosjektledelsesteoriene benyttes for å utvikle velfungerende IIer. Jeg mener derfor at gjennomføring av en studie som dette vil være med på å legge til grunn for videre forskning på denne typen prosjekter. I en hverdag hvor stadig flere arbeidsoppgaver blir digitalisert, får man flere systemer som skal kunne snak- ke sammen. Det er derfor nyttig å få en god forståelse for hvordan denne typen prosjekter bør gjennomføres for å ende opp med et så vellykket prosjektresultat som mulig. Selv om det finnes mye forskning omkring ledelse av tradisjonelle IT- prosjekter, tilsier teoriene innen både prosjektledelse og IIer at store komplekse prosjekter bør styres annerledes.

(16)

1.3 Problemstilling

Studiens problemstilling er følgende:

I hvilken grad kan II-teorien supplere, eventuelt erstatte, tradisjonell prosjektledelsesteori i store komplekse prosjekter?

Ved hjelp av denne problemstillingen vil det være mulig avdekke hvilke deler av den tradisjonelle prosjektledelseslitteraturen som fortsatt er gjeldende ved store komplekse prosjekter, og eventuelt hvilke deler av II-litteraturen som kan tilføres for å bidra til et vellykket prosjekt.

For å konkretisere problemstillingen, har jeg definert fire forskningsspørsmål som hver har sitt opphav i de fire delene av et prosjekt som jeg anser som de mest sentrale; standardisering, planlegging, organisering og oppfølging:

1. Bidrar standarder til et vellykket prosjektresultat?

Ettersom valg av standardisert prosjektledelsesmetodikk danner fundamentet i et prosjekt og at tekniske standarder er en av de grunnleggende måtene å håndtere IIer på, var det en viktig del av den overordnede problemstillingen å avgjøre om bruk av standarder kunne bidra til et vellykket prosjektresultat.

2. Bidrar grundige planer til et vellykket prosjektresultat?

Bruk av planer i et prosjekt er en kjent teknikk for å sørge for at man leve- rer det produktet kunden har etterspurt, men derimot noe som er lite brukt innen II-litteraturen. På denne måten ville det være interessant å finne ut om detaljerte planer fra prosjektledelseslitteraturen ville være med på å bidra til et vellykket prosjektresultat i store komplekse prosjekter.

3. Bidrar streng hierarkisk ledelse til suksess i store komplekse prosjekter?

Hierarki står som ett av de mest sentrale trekkene ved prosjektledelse, men er kjent for å kunne bidra til komplekse og stive IIer. På denne måten ville det derfor være elementær del av studiens problemstilling å kunne avgjøre om streng hierarki vil kunne bidra til et vellykket prosjektresultat selv i store komplekse prosjekter.

4. Fører tett oppfølging til et vellykket prosjektresultat?

Ved at tett oppfølging av et prosjekt anses som et av de viktigste aktivite- tene for å sørge for et vellykket prosjektresultat, benyttes oppfølging også innen IIer for å kunne videreutvikle de mest vellykkete funksjonalitetene. I henhold til studiens problemstilling og de mest sentrale delene av en pro- sjektgjennomføring, ville det være hensiktsmessig å kunne avgjøre om de to ulike formene for oppfølging sammen kan bidra til et vellykket prosjektre- sultat.

(17)

1.4. OPPGAVENS DISPOSISJON 5 På grunn av kompleksiteten i denne studien, er forskningsspørsmålene definert som ja/nei-spørsmål. Dette er for å kunne trekke avsluttende konklusjoner for hver av spørsmålene, slik at det er mulig å hente ut konkrete svar for hver av temaene de omfatter.

For å kunne svare på problemstillingen og forskningsspørsmålene ble studien gjennomført som en case studie med utgangspunkt i flere ulike prosjekter som hver oppfylte kriteriet om høy kompleksitet. Prosjektene handlet i utgangspunktet om effektivisering og omstrukturering av bedriftene de ble gjennomført i. På denne måten fikk jeg et godt innblikk i hvordan hver av prosjektlederne gikk frem for å styre og koordinere prosjektene. Ved å gjennomføre studien på denne måten ville det være mulig å kunne si noe om hvilke deler av prosjektledelseslitteraturen som fortsatt stod sentralt i prosjektene og om det var mulig å supplere med teori fra II-litteraturen.

1.4 Oppgavens disposisjon

Oppgaven er delt inn i åtte kapitler, hvor innledningskapittelet er inkludert som et av disse. I andre kapittel vil tidligere forskning og litteratur tilknyttet prosjekt- ledelse og IIer presenteres, da disse teoriene danner det teoretiske grunnlaget for studien. Tredje kapittel beskriver valg av metodikk for gjennomføring av studien samt hvordan dataene ble analysert i etterkant av datainnsamlingen. Kapittel fire handler om de etiske aspektene omkring studien og hvordan jeg har forholdt meg til disse. I femte kapittel vil de undersøkte casene beskrives, slik at leseren får en overordnet oversikt over hva de ulike prosjektene handlet om, hvor mye erfaring hver informant har og hvorfor nettopp disse kategoriseres som store komplekse prosjekter. I sjette kapittel presenteres funnene fra analysen, mens kapittel syv er en diskusjon som drøfter de empiriske funnene fra kapittel seks i lys av litteraturen som ble presentert i kapittel to. Der vil også forskningsspørsmålene og studiens problemstilling besvares. Til slutt studiens funn oppsummeres i konklusjonen.

(18)
(19)

Kapittel 2

Litteratur

I dette kapittelet vil jeg ta for meg fagfeltene prosjektledelse og informasjonsin- frastrukturer(II) som danner den teoretiske basen for studien. Jeg vil starte med å beskrive hva prosjektledelse er og hvilke ledelsesrammeverk som brukes mest.

Deretter vil jeg gå nærmere inn på hva som er en II og hvordan den skiller seg fra enkeltstående informasjonssystemer. Dette vil så bli brukt til å definere hva store komplekse prosjekter er og hvordan de skiller seg fra tradisjonelle prosjekter. Til tross for at begrepet store komplekse prosjekter er beskrevet innledningsvis, vil det her bli gitt en grundigere beskrivelse som har forankring i forskning fra de to nevnte fagfeltene.

Deretter vil jeg gå nærmere inn på de fire delene som danner grunnlaget i et prosjekt, nemligstandardisering,planlegging,organiseringogoppfølging. I hen- hold til hver av disse vil jeg se på hva både prosjektledelses- og II-litteraturen sier, for å kunne avdekke likheter og ulikheter i de to fagområdene. Dette vil bli opp- summert skjematisk mot slutten av kapittelet.

2.1 Prosjektledelse

Et prosjekt er en midlertidig organisasjon etablert med hensikt i å produsere et unikt produkt, tjeneste eller resultat. Hvert enkelt prosjekt er særegent og utfører ikke de samme rutineoppgavene som ved den daglige driften i organisasjonen (Project Ma- nagement Institute 2011, s. 5). Et prosjekt har alltid en definert start og slutt med et fastsatt mål om hva som skal gjøres i det avgrensede tidsrommet. Målet og hen- sikten for gjennomføringen av prosjektet defineres som oftest i et mandat (Office of Government Commerce 2009, s. 113), men hvor detaljert denne beskrivelsen er vil variere fra prosjekt til prosjekt. Dersom mandatet foreslår et prosjekt som orga- nisasjonen anser som hensiktsmessig, gis det et klarsignal for at gjennomføringen kan starte.

At et prosjekt er definert som en midlertidig organisasjon er ikke det samme som at et prosjekt er kortvarig. Prosjekter kan vare i lange perioder avhengig av hva sluttproduktet skal være og hvilken prioritet det har i organisasjonen det gjen-

7

(20)

nomføres i. En tommelfingerregel kan være at et prosjekt er midlertidig, men slutt- produktet er ment som et varig resultat (Project Management Institute 2011, s. 5).

Eksempler på dette kan være et byggeprosjekt hvor resultatet er et nytt rådhus eller et prosjekt som innfører et nytt timeføringssystem i en bedrift. Begge prosjekte- ne ender med resultater som vil bli værende inntil det eventuelt gjennomføres nye prosjekter.

Prosjektledelse handler om hvordan man kan bruke kunnskaper, erfaringer, verktøy og teknikker til komme i mål med et prosjekt som møter kravene som er satt.Project Management Groupmener at dette gjøres via fem definerte prosesser som alle finner sted i et prosjekt, uavhengig av hvilken metodikk som er valgt:

• Initiere

• Planlegge

• Gjennomføre

• Overvåke og kontrollere

• Avslutte

(Project Management Institute 2011, s. 6).

De fem prosessene vil bli grundigere beskrevet under avsnittet om PRINCE2.

I prosjektledelseslitteraturen har det lenge vært vanlig at prosjektene har hatt svært sentralisert ledelse. Cadle og Yeates mener dette ikke fungerer i praksis, da prosjektets viktigste verktøy er prosjektdeltakernes kunnskaper. Dette gjør at man er nødt til å involvere deltakerne aktivt for å kunne gjennomføre et vellykket pro- sjekt, og prosjektlederen må slippe noe av styringen for kunne å slippe de andre deltakerne til. Prosjektlederen blir derfor avhengig av at de andre i prosjektet gjør jobben som avtalt, ettersom han ikke lenger står alene om ansvaret for koordine- ring og planlegging av prosjektet (Cadle og Yeates 2004, s. 395). Likevel påpeker de at prosjektlederen har en essensiell rolle for håndtering av uforutsette hendelser og fremgang, og at problemene han håndterer i stor grad handler om menneske- lige problemer. Prosjektlederen må jobbe proaktivt ved at han til enhver tid må identifisere og planlegge for potensielle endringer (Cadle og Yeates 2004, s. 1).

2.1.1 Prosjektledelsesrammeverk

Avhengig av hva slags prosjekt man ønsker å gjennomføre, finnes det ulike pro- sjektledelsesrammeverk som er utarbeidet på en slik måte at de skal kunne gi best mulig utbytte for det gitte prosjektet. Normalt står valget mellom en tradisjonell metodikk, ofte kalt fossefallsmetodikk, eller en smidig metodikk. Av de tradisjo- nelle metodikkene finner man standardiserte rammeverk som PRINCE2 og av de smidige finnes blant annet Scrum og Kanban. PRINCE2 er bygget opp slik at det skal kunne brukes i alle typer prosjekter, mens Scrum og Kanban normalt sett bru- kes i prosjekter tilknyttet programvareutvikling. Denne rapporten vil være vinklet mot prosjektledelsesrammeverket PRINCE2, da dette er et av de mest aksepterte og brukte metodene i verden (Office of Government Commerce 2009, s. 4). I tillegg

(21)

2.1. PROSJEKTLEDELSE 9 mener jeg det er en fin måte å illustrere fossefallsmetodikk på, som er mye anvendt i praksis. De to andre nevnte metodikkene vil likevel bli kort beskrevet under.

Kanban er en flytbasert prosessmetode som handler om å dele opp oppgaver i mindre bokser slik at oppgavene flyter uten avbrudd. Når man bruker Kanban som prosjektmetode jobber man mot just in time-prinsippet ved at man sikrer at alle delene i prosessen er ferdig til rett tid og sted. Dette gjør prosjektdeltakerne ikke allokerer ressurser før det er absolutt nødvendig, noe som gjør prosessen veldig tid- og kostnadseffektiv (Phil, Roger 2015). Ved at man opprettholder en kontinuerlig arbeidsflyt vil man hindre en del flaskehalser fordi færre oppgaver gjøres i parallell (Sjøberg, Johnsen og Solberg 2012, s. 48).

Scrum handler om å dele opp prosjektprosessen i mindre iterasjoner fremfor å jobbe mot bestemte tekniske milepæler. Scrum deles inn i tre faser hvor den første tar for seg planlegging og etablering av mål og design for prosjektet. Andre fase er en rekke sprinter, hvor hver sprint danner et inkrement av systemet. Dette betyr at hver sprint har et bestemt antall mål som man jobber mot og som gjør prosjektprosessen mer håndterbar. Når siste iterasjonen nærmer seg slutten går man over i fase tre hvor dokumentasjon samles inn og prosjektet avsluttes (Sommerville 2011, s.72 -73)

En fordel med scrum er at man mot slutten av hver sprint presenterer arbeidet for kunden, slik at man er sikker på at det man utvikler er i henhold til det kunden ønsker. På denne måten sparer man tid på å rette opp feil tidlig i prosessen og sikrer at kunden blir fornøyd med produktet (Sommerville 2011, s. 31).

2.1.2 PRINCE2

PRINCE2 er et generisk prosjektrammeverk basert på best practice innen prosjekt- ledelse. Rammeverket er bygget opp av syv prinsipper, syv temaer og syv prosesser som bidrar til at prosjekter får det riktige nivået av styring og at alle har mulighet til å bidra og påvirke prosjektet. Til tross for at ett av de syv prinsippene handler om å tilpasse rammeverket til hvert enkelt prosjekt, er prinsippene det eneste i ramme- verket som ikke kan endres eller tilpasses. Så dersom prosjektet skal gjennomføres i tråd med PRINCE2, må følgende prinsipper følges:

• Kontinuerlig forretningsmessig forankring

• Lære fra erfaringer

• Definerte roller og ansvar

• Styre i faser

• Avviksledelse

• Fokus på prosjektets produkter

• Tilpasse prosjektomgivelene

(Office of Government Commerce 2009, s. 11-14)

Temaene beskriver aspekter av prosjektledelsen som må håndteres kontinuerlig gjennom hele prosjektprosessen. De er bygget inn som en naturlig del av de syv

(22)

prosessene, ved at det er temaene som illustrerer hva som er de essensielle ledelses- oppgavene, mens prosessene organiserer hvilken rekkefølge de bør gjøres i. Dette er de syv temaene:

• Business case

• Organisering

• Kvalitet

• Planer

• Usikkerhet

• Endring

• Fremdrift

(Office of Government Commerce 2009, s. 17-18) 2.1.3 De syv prosessene

Hver prosess en strukturert serie av aktiviteter satt sammen for å oppnå et definert mål (Office of Government Commerce 2009, s. 113). Prosessene vil bli beskrevet en del grundigere enn prinsippene og temaene, fordi dette er prosjektprosesser som normalt finnes i alle definerte prosjekter uavhengig av hvilket rammeverk man be- nytter. Som vedlegg i rapporten er det lagt ved en oversikt som viser hvordan de syv prosessene posisjonerer seg i forhold til hverandre og de ulike ledelsesnivåene.

Oppstart av prosjektet

Oppstart av prosjekteter den første prosessen i et prosjekt og handler om å avgjøre om prosjektet er levedyktig og lønnsomt (Office of Government Commerce 2009, s. 122). For å bruke så lite penger og ressurser som mulig, er målet med prosessen å gjøre så lite som mulig før man beslutter initiering. På den måte bruker man ikke tid på et prosjekt som ikke er levedyktig. De viktigste aktivitetene ioppstart av prosjekteter:

• Utnevne prosjekteier og prosjektleder

• Forberede grov business case

• Sette sammen prosjektforslag

• Planlegge initieringsfasen

Prosjekteieren er den som har det endelige ansvaret for prosjektet og sikrer fokus på kvalitet og produktene som skal leveres. Prosjektlederen har den daglige ledelsen av prosjektet på vegne av prosjekteieren og har som ansvar å passe på at det produseres et resultat som oppnår gevinstene definert i business casen (Office of Government Commerce 2009, s. 270-271).

(23)

2.1. PROSJEKTLEDELSE 11 Eierstyring av prosjektet

Når det har blitt utarbeidet en grov business case i oppstart av prosjektet, går man over i faseneierstyring av prosjektetmed en forespørsel om initiering. Hensikten med denne prosessen er å gjøre prosjektstyret i stand til å ta de viktige avgjørel- sene og utøve overordnet kontroll overfor prosjektlederen (Office of Government Commerce 2009, s. 136-137). Den viktigste aktiviteten ieierstyring av prosjektet er:

• Autorisere initiering, prosjektet, faseplan og prosjektavslutning.

Slik som vist i oversikten over prosessene er denne prosessen gjennomgående gjennom hele prosjektet. Hver gang en fase avsluttes og en ny planlegges, må dette gjennom prosjektstyret og eierstyring av prosjektet. Dette henger nøye sammen med prinsipp nr 4.

Prosjektstyret består av prosjekteieren, seniorbrukere og seniorleverandører.

Ved et internprosjekt i en bedrift vil den som har den øverste makten og ansvar for pengestrømmen være prosjekteieren. Dersom det er et mindre IT-prosjekt kan pro- sjekteieren typisk være IT-direktøren. Seniorbrukerne representerer sluttbrukerne av løsingen og er ansvarlige for å presisere deres behov og ønsker. Seniorleveran- dører er representanter for de som designer, utvikler og implementerer prosjektets produkter (Office of Government Commerce 2009, s. 270-271).

Initiere prosjektet

Når prosjektstyret har autorisert initiering og faseplan for initieringen, går man over i faseninitiere prosjektet. Her etableres det et robust grunnlag for prosjektet slik at det blir klart hva som må gjøres for å kunne levere produktene (Office of Government Commerce 2009, s. 149). De viktigste aktivitetene iinitiere prosjektet er:

• Utforme usikkerhets-, konfigurasjons-, kvalitets- og kommunikasjonsstrate- gien

• Opptrette prosjektplan

• Forfine business case

• Samle initieringsdokumentasjonen

Det er i denne prosessen prosjektlederen inntar sine ansvarsområder og ut- arbeider prosjektforslaget, initieringsdokumentasjonen, arbeidspakkene og fase- /unntaksplaner (Office of Government Commerce 2009, s. 271-272).

Kontrollere en fase

En prosjektplan er som regel delt opp i mindre mer håndterbare deler, altså faser. En faseplan er en del av prosjektplanen og omhandler et mindre avgrenset tidsrom hvor man skal kunne avslutte med en leveranse. Hensikten med prosessenkontrollere en

(24)

faseer å tildele arbeid, rapportere fremdrift til prosjektstyret og gjøre korrigerende tiltak (Office of Government Commerce 2009, s. 168). De viktigste aktivitetene i kontrollere en faseer:

• Autorisere og motta fullførte arbeidspakker

• Gå gjennom fasestatus og rapportere høydepunkt

• Gjøre korrigerende tiltak Styre produktleveranser

For hver fase finnes det et sett med arbeidspakker som skal gjennomføres. Disse er som regel en del av leveransen til prosjektet og må derfor kontrolleres. I større prosjekter er det vanlig at mindre team tar seg av arbeidpakkene hvor hvert team har en teamleder. Ved mindre prosjekter finnes det ofte bare ett team hvor teamle- der også er prosjektleder. Hensikten med styre produktleveranser er å kontrollere koblingen mellom prosjektleder og teamleder og sette krav til utførelse av arbeids- pakkene (Office of Government Commerce 2009, s. 186). Den viktigste aktiviteten istyre produktleveranserer:

• Akseptere, utføre og levere arbeidspakke Lede faseovergang

Mot slutten av hver fase går man over i prosessenlede faseovergang. Hensikten med prosessen er å gi prosjektstyret tilstrekkelig med informasjon for å kunne eva- luere suksessen av den aktuelle fasen, godkjenne neste faseplan og bekrefte kon- tinuerlig forretningsmessig forankring. (Office of Government Commerce 2009, s.

194). De viktigste aktivitetene ilede faseoverganger:

• Planlegge neste fase

• Oppdatere prosjektplanen

• Rapportere faseavslutning

• (Produsere unntaksplan)

Produksjon av unntaksplan skjer kun dersom det har oppstått en hendelse som gjør at man ikke kan følge den opprinnelige faseplanen. Når slike hendelser oppstår må prosjektleder rapportere til prosjektstyret og opprette en unntaksrapport. Der- som rapporten godkjennes, utarbeides det en unntaksplan som erstatter faseplanen.

Avslutte prosjektet

Når prosjektet så avsluttes aksepteres prosjektproduktene og anerkjenner at målene som ble satt i initieringsdokumentasjonen eller godkjente endringer er oppnådd (Office of Government Commerce 2009, s. 205-206). De viktigste aktivitetene i avslutte prosjekteter:

(25)

2.2. INFORMASJONSINFRASTRUKTUR 13

• Forberede planlagt avslutning

• (Forberede avslutning før plan)

• Overlevere produkter

• Evaluere prosjektet

Dersom man velger å avslutte prosjektet tidligere enn planlagt, må man også forberede en plan for avslutning. Dette for å sikre at man ikke sitter igjen med noen løse tråder og at prosjektet ble avsluttet på korrekt måte. Overleveringen av produk- tene til brukeren må gjøres før prosjektet avsluttes. Det bør gjøres avtaler med de som skal vedlikeholde og drifte produktet(Office of Government Commerce 2009, s. 207-208).

2.2 Informasjonsinfrastruktur

En informasjonsinfrastruktur (II) defineres som en delt, muliggjørende, åpen og heterogen installert base (Monteiro, Pollock, Hanseth og Williams 2012, s. 576) I mange tilfeller vil en II omtales som et stort komplekst system bestående av både tekniske og ikke-tekniske enheter hvor hver av dem er avhengig av hverandre.

At en II er delt betyr at den deles mellom en større mengde brukere eller bru- kergrupper. Med dette menes at brukerne jobber mot det samme objektet selv om oppgavene de utfører kan være ulike. Et eksempel på et delt objekt er en epostser- ver. Denne kan ikke deles opp i mindre separate deler eller brukes uavhengig av andre brukergrupper (Hanseth 2000, s. 57). Dette gjør at den kan brukes av mange ulike brukere og samtidig tilpasses deres behov ved at de kan bruke den epostkli- enten de selv ønsker.

En II er muliggjørende ved at den skal kunne tilpasses og åpne opp for nye bruksområder og støtte ulike aktiviteter, som gjør dem til komplekse og fleksib- le nettverk. Det handler derfor ikke bare om å skulle forbedre det som allerede eksisterer, men å utvide med nye funksjonaliteter. Dette kan være alt fra å utvide epostklienten med en kalenderfunksjon eller å innføre en felles database

En viktig egenskap ved IIer er at de er utviklende. Dette er ikke en del av definisjonen som er henvist til over, men en del av Hanseths tidligere definisjon (Hanseth og Monteiro 1998, s. 40). At en II er utviklende handler derfor om at den alltid vil være i kontinuerlig vekst.

En II vil alltid være åpen ved at den ikke er begrenset til et bestemt antall brukere, interessenter eller tekniske elementer, noe som kan gjøre det vanskelig å sette et klart skille mellom hva som er en del av en II og ikke. Dette betyr i teorien at nærmest alt kan være en del av en II dersom man ikke klarer å avgrense den.

Hanseth mener derfor at alle de nevnte egenskapene er med på å gjøre IIen he- terogen ved at den er et sosioteknisk nettverk (Hanseth 2000, s. 58). Med det mener han at den består av alt fra de helt tekniske elementene til de sosiale relasjonene i tilknytning til systemene. For å illustrere dette kan man si at de tekniske elemente- ne ikke vil kunne fungere optimalt dersom de ikke vedlikeholdes, og de vil heller ikke kunne yte optimalt dersom de ikke brukes på rett måte (Hanseth 2000, s. 59).

(26)

En viktig egenskap ved IIer er at de aldri vil kunne bygges fra grunnen av (Han- seth 2000, s. 60). De vil alltid bestå av noen grunnleggende elementer som sammen danner den installerte basen. Et kjent eksempel på dette er når man skal bygge en vei. Det vil alltid finnes en eller annen indikatorer på at veien skal bygges akkurat der, enten det er en sti eller at det er en naturlig kobling mellom to byer. Stien eller koblingen vil da være den installerte basen. Dette fungerer som en grunnmur for IIen som kontinuerlig utvikles uten å ha en livssyklus. Til tross for at en II regel- messig tilpasses nye bruksområder og brukere, må den kontinuerlige utviklingen styres, kunsten er da å finne en balanse mellom streng styring og utvikling på en måte som gjør at de ikke forhindrer hverandre (Tilson, Lyytinen og Sørensen 2010, s. 754).

Det som skiller en II fra et informasjonssystem (IS), er at et IS er en enkeltstå- ende enhet designet for en bestemt brukergruppe og er derfor en motsetning til en II. Et IS designes fra bunnen av for å kunne tilpasses den gitte brukergruppen og vil derfor ha begrenset funksjonalitet i forhold til en II (Hanseth, Ole 2014, s. 17).

På en annen side vil man kunne bygge en II ved å sette sammen flere ISer slik at man får flere bruksområder for ulike brukergrupper.

2.2.1 Tilpasning av II-litteraturen

Definisjonen av en II er hovedsakelig utarbeidet for å beskrive internett som et stort komplekst system. Dette gjør derfor at begreper som for eksempelubegren- set fri vekst og åpenhet ikke nødvendigvis passer i alle sammenhenger hvor II- definisjonen benyttes. Fri vekst slik som Hanseth beskriver det, vil man sjelden finne i organisasjoner og bedrifter på samme måte som på internett. Dette fordi veksten i de fleste andre store komplekse systemer, alltid vil være styrt på en eller annen måte. Derimot, hvordan og i hvilken grad man ønsker å styre, vil variere fra organisasjons til organisasjon. Beskrivelsen om en IIs åpenhet, er i de fleste tilfeller heller ikke direkte overførbar. Dette fordi en II i organisasjonssammenheng kun vil være åpen for de ansatte i organisasjonen. Det er også stor sannsynlighet for at den er tilgangskontrollert, slik at man kun har tilgang til de systemene man behøver for å gjennomføre de arbeidsoppgavene man har. Ut ifra dette er IIen åpen i den forstand at den kun er åpen for dem som har behov for det. Dette er derimot ikke gjeldende for internett, fordi alle har mulighet til å aksessere internett dersom man ønsker det.

Ettersom II-definisjonen legger til grunn for resten av teoriene knyttet til IIer, vil det i mange tilfeller være hensiktsmessig å gjøre tilpasninger slik at teoriene vil passe for IIer som har en høyere grad av styring enn internett. Dette gjør teoriene mer anvendelige samt at uttrykk som åpenhet og fri vekst vil få en annen og mer passende betydning for konteksten de blir benyttet i. I denne studien vil uttrykk somlokaleogsentrale tilpasningkunne benyttes i stedet for fri vekst, som en mer deskriptiv måte å beskrive brukertilpasning i vekst på.

I tillegg til dette må det legges ved at det finnes flere motsetninger i II-litteraturen, som til dels kan gjøre den utfordrende å tolke. Dette gjør at den er nødt til å gjøre

(27)

2.3. STORE KOMPLEKSE PROSJEKTER 15 vurderinger av hvilke studier man oppfatter som mest representative for sin kon- tekst og gjøre avveininger om hvordan de ulike studiene stiller seg i forhold til hverandre. Å måtte forholde seg til en teori som til tider er inkonsistent kan være utfordrende og skape en del ekstra arbeid, men det viktigste er nok derimot å ha et bevisst forhold til at utfordringene finnes.

2.3 Store komplekse prosjekter

Definisjonen av et prosjekt som ble presentert i begynnelse av kapittelet, gir et tydelig bilde av at det er en midlertidig organisert enhet som har som hensikt å produsere et unikt og varig resultat. Definisjonen sier ingen ting om prosjektets rammer, hva det omfatter eller hvordan forholdet mellom kunde og leverandør er.

Definisjonen av en II gir derimot en bred og overordnet beskrivelse av et stort komplekst system bestående av både tekniske og ikke-tekniske aktører som alle har en relasjon til hverandre. IIen bygges aldri opp fra bunnen av og har som oppgave å tilrettelegge for brukerne av den.

Teoriene beskriver på mange måter to klare motsetninger, hvor prosjektledelse handler om å styre en prosess som til slutt ender med et definert og planlagt re- sultat, mens IIer handler om en friere og ikke tidsbegrenset vekst som kontinuerlig tilpasses alle dens brukergrupper. Likevel finnes det konkrete eksempler hvor de fungerer sammen, nemlig istore komplekse prosjekter. Et stort komplekst prosjekt kjennetegnes ved at det består av et stort antall aktører, både tekniske og ikke- tekniske, som skaper spenninger på tvers av prosjektet. Spenningene bunner ut i den kontinuerlige brukertilpasningen som gjøres for å sørge for at prosjektresul- tatet er tilpasset så mange av aktørene som mulig, uten at det går på bekostning av det opprinnelige målet for gjennomføringen av prosjektet. Hanseth et.al. (1996) beskriver spenningene som oppstår i relasjonen mellom endring og stabilitet, og som eksempler på dette benyttes internett og innføringen av OSI-modellen. Spen- ninger i dette tilfellet oppstod blant annet på grunn av mangel på kommunikasjon, noe som gjorde at det ble utarbeidet protokoller som viste seg å være altfor kom- pliserte. I tillegg var ikke protokollene kompatible med de som allerede fantes i OSI-modellen, noe som gjorde det vanskelig å inkludere dem med andre protokol- ler. Årsaken til at dette skjedde var at de som utarbeidet protokollene, ikke var de samme personene som implementerte dem. På denne måten oppstod det spennin- ger mellom de som utarbeidet og implementerte protokollene, samt de hadde det overordnede koordineringsansvaret (Hanseth, Monteiro og Hatling 1996, s. 413)

Spenninger oppstår i mange prosjekter, men er et svært sentralt trekk ved store komplekse prosjekter. Denne typen prosjekter handler i de fleste tilfeller om ef- fektivisering eller omstrukturering av en allerede eksisterende løsning, slik som innføring av et nytt epostsystem i en bedrift. Det er derfor mengden aktører og prosjektlederens posisjon i prosjektet samt måten det jobbes ut ifra allerede eksis- terende systemer, som skiller de store komplekse prosjektene fra de tradisjonelle.

(28)

2.3.1 Hva er et vellykket prosjekt?

Selv om det i PRINCE2 er utarbeidet syv prosesser, temaer og prinsipper for gjen- nomføring av prosjekter, sier disse ingen ting om hva som utgjør et vellykket pro- sjekt. Tradisjonelt sett har man tatt utgangspunkt i de tre faktorene tid, kost og kvalitet for å avgjøre om et prosjekt har vært vellykket eller ikke. Basert på hva kunden ønsket, skulle man da levere et prosjekt til avtalt tid og kostnad til ønsket nivå av kvalitet for å kunne si at prosjektet var vellykket (Globerson og Zwikael 2002, s. 58).

Ved gjennomføring av et prosjekt kan man se på prosjektet fra to ulike vink- ler for å avgjøre hvor vellykket det har vært. På den første og antageligvis mest åpenbare er prosjektresultatet. Dette er produktet man leverer til kunden etter å ha gjennomført prosjektet. Den andre vinklingen handler om hvor vellykket selve gjennomføringen av prosjektet har vært. Dette handler derfor om i hvor stor grad prosjektlederen har kunne legge realistiske planer, følge opp og koordinere pro- sjektet. Ved å dele opp et prosjekts suksess på denne måten, kan man få en bedre forståelse av hva ved et prosjekt som har vært vellykket. Et eksempel på hvor denne oppdelingen ville være nyttig er dersom prosjektet ble levert til avtalt tid, pris og kvalitet, men at prosjektlederen har tatt lite ansvar for koordinering av prosjektet og overlatt oppgavene sine til de andre prosjektdeltakerne. I et slikt tilfelle vil det være et vellykket prosjektresultat, men med mislykket prosjektgjennomføring. Til tross for at dette ikke påvirker kunden direkte, vil det oppleves som frustrerende og krevende for prosjektdeltakerne. Sett fra motsatt side kan prosjektet være både realistisk estimert og planlagt, slik at gjennomføringen foregikk uten noen større problemer. Likevel kan det være slik at da kunden mottok produktet, var det flere aktører som er misfornøyd med resultatet. Dette kan typisk forekomme dersom det gjennomføres et stort komplekst prosjekt med mange ulike aktører. Ut ifra dette kan man trekke linjer fra vellykket prosjektledelse til PRINCE2 og vellykket pro- sjektresultat til IIer. Hvor vellykket prosjektledelse et prosjekt har hatt, avhenger av at man utført prosjektprosessene i henhold til visse retningslinjer som sørger for en smidig prosjektgjennomføring. Disse retningslinjene kan for eksempel være hentet fra PRINCE2. På samme måte kan man trekke linjer mellom prosjektresultat og IIer, fordi man er nødt til å ta hensyn til de ulike aktørene for å få et vellykket prosjektresultat.

På grunn av den todelte vinklingen av et prosjekt, vil bruk av måleenhetene tid, kost og kvalitet være noe begrenset for å kunne dekke alle aspektene ved et prosjekt. I tillegg mener Roger Atkinson (1999, s. 337) at kvalitet er et subjek- tivt fenomen som ofte endres over tid, gjerne underveis i prosjektets gang. Dette gjør derfor kvalitet til en noe vag måleenhet som lett kan misforstås. Dersom man skal kunne ha nytte av kvalitetsbegrepet, er man avhengig av å utarbeide grundige kravspesifikasjoner som beskriver kvaliteten som ønskes av produktet.

For å få «måleenheter» som er mer dekkende kan man det være en idé å dele dem inn i interne og eksterne måleenheter. De interne måleenhetene omfatter i all hovedsak tid, kost og kvalitet, mens de eksterne omfatter for eksempel fordelene

(29)

2.4. PRINSIPPER FOR KOORDINERING 17 prosjektresultatet skaper for organisasjonen, kundetilfredshet og organisasjonens markedsandel (Milosevic og Patanakul 2005, s. 183). Dette betyr derfor at de in- terne målene kan knyttes opp mot selve gjennomføringen av prosjektet, mens de eksterne kan knyttes opp mot prosjektresultatet og dets effekt på organisasjonen det er en del av. I tillegg kan det være nyttig å ha et kritisk blikk på de måleen- hetene man bruker og gjøre en vurdering av hvor nyttige de er. Atkinson mener at dersom det rapporteres at enten prosjektresultatet eller prosjektledelsen har vært mislykket, bør man revurdere måleenhetene man har benyttet. På denne måten kan man prøve å sørge for at man ikke gjentar den samme feilen flere ganger (Atkinson 1999, s. 337).

2.4 Prinsipper for koordinering

En standard defineres som en rekke løsninger relatert til faktiske eller potensielle problemer som gagner partene som er involvert. Det er forventet at løsningene blir jevnlig benyttet i en bestemt periode av en bærekraftig del av partene standarden er ment for (DeVries 2013, s. 13). Med dette kan man derfor si at en standard er en etablert norm eller krav som har som hensikt å skape struktur og orden for dem den gjelder for. En standard kan være alt fra innføring av et standardisert system til standardiserte prosesser som definerer hvordan en person gjør en rekke arbeids- oppgaver. I samsvar med store komplekse prosjekter vil standardene være tilknyttet bruk av standardiserte prosjektledelsesrammeverk og innføring av standarder i be- driften som en del av koordineringen av et prosjekt.

Standardiseringsbegrepet er likevel er veldig vidt begrep som vil være ulikt av- hengig av konteksten det benyttes i. I denne studien hvor det parallelt fokuseres på både prosjektledelse og IIer, vil standardisering være to svært ulike prinsipper for koordinering. Standardisering i prosjektledelsessammenheng handler om definerte prosesser som sørger for at noe gjøres på en bestemt måte i en planlagt rekkefølge, mens i II-sammenheng handler standardisering om tekniske standarder, slik som innføring av en epostløsning eller utarbeidelse av protokoller for datakommunika- sjon.

2.4.1 Prosjektledelse

Som en måte å koordinere og organisere prosjekter på, er det vanlig å benytte fer- dig utarbeidede prosjektledelsesrammeverk. Disse rammeverkene har gjerne en lo- gisk oppbygning som sørger for at alle aspektene av prosjektet blir dekket. Det har de siste årene blitt svært vanlig at organisasjoner innfører bruk av standardiserte prosjektledelsesrammeverk som et tiltak for å bedre prosjektkulturen og øke suk- sessraten på prosjektene. Dette gjøres enten ved at organisasjonen selv utarbeider sitt eget standardiserte rammeverk basert på tidligere prosjekterfaringer, eller tar i bruk en generisk metodikk basert på best practice, slik som PRINCE2.

Flere studier viser at bruk av et standardisert prosjektledelsesrammeverk bidrar

(30)

til å kunne gjennomføre et vellykket prosjekt. Likevel er det kun til et visst punkt at standardisering øker suksessraten, altså tilvippepunktet. Dersom det innføres flere standardiserte prosesser enn vippepunktet tilsier, risikerer man at suksessraten sen- kes. Hvor vippepunktet befinner seg vil variere fra organisasjon til organisasjon, noe som derfor gjør det vanskelig å avgjøre hvor mange og hvilke standardiser- te prosesser som bør innføres for å oppnå ønsket effekt (Milosevic og Patanakul 2005, s. 183-186). Vippepunktet for standardisering av prosesser er illustrert i figur 2.1. X-aksen har som hensikt å vise antall standardiserte prosesser og y-aksen er suksessraten i prosjektet. Den røde, stiplede linjen illustrerer da det antallet stan- dardiserte prosesser som gir den høyeste suksessraten, altså vippepunktet.

Figur 2.1: Vippepunkt for innføring av standarder

Bakgrunnen for påstanden om at et standardisert prosjektledelsesrammeverk øker suksessraten til prosjekter, er at man utarbeider mer punktlige planer og at prosjektene gjerne er mer kostnadseffektive enn prosjekter uten standardisert pro- sjektledelsesrammeverk. Dette bidrar til at man kan levere løsninger som er av høyere kvalitet som igjen bidrar til fornøyde kunder (Milosevic og Patanakul 2005, s. 189). Likevel påpekes det at til tross for vel utarbeidede rammeverk, er det ikke rammeverkene ene og alene som avgjør om prosjektet blir vellykkete. Hvilke men- nesker som deltar i prosjektet og prosjektleders evne til å utnytte deres erfaringer, har vel så mye innvirkning på suksessraten som et standardisert prosjektledelses- rammeverk (Office of Government Commerce 2009, s. 39).

En annen viktig faktor for at et standardisert prosjektledelsesrammeverk skal være verdiskapene, er at det tilpasses det enkelte prosjektet. For å kunne gjøre dette er man avhengig av at prosjektlederen har et visst nivå av prosjekterfaring for å kunne avgjøre hvilke deler av prosjektrammeverket som er nyttige og ikke. I mange rammeverk finnes det retningslinjer for tilpasning til hvert et prosjekt (Office of Government Commerce 2009, s. 213-231), men med lite erfaring kan det likevel være vanskelig å avgjøre hvilke deler av rammeverket som er viktig å ha med.

Dersom man ikke har erfaringer til å tilpasse rammeverket til prosjektet, risikerer man å oppleve prosjektprosessen som altfor omfattende. Dette skjer fordi de fleste rammeverkene er utarbeidet på en måte som gjør at de skal være passende for alle typer prosjekter (Wells 2012).

(31)

2.4. PRINSIPPER FOR KOORDINERING 19 Til tross for at standardisert metodikk kan bidra til et vellykket prosjektresultat, er det viktig å ikke bli slave for metodikken (Milosevic og Patanakul 2005, s. 189) 2.4.2 Informasjonsinfrastruktur

Innen IIer benyttes innføring av standarder som et tiltak for økt styring. Utford- ringen er derimot å finne det rette nivået av styring slik at IIen fortsetter å være muliggjørende samtidig som at kompleksiteten forblir håndterbar. En avveining som må tas ved innføring av standarder, er hvor vidt den vil avgrense IIen den inn- føres i og på hvilken måte det vil være begrensende ved senere anledninger. En vel planlagt og fleksibel standard kan være med på å fremme innovasjon og vekst, og på samme måte kan en smalt definert standard raskt setter stopper for innovasjonen i IIen den innføres i (Hanseth og Bygstad 2015, s. 646). Smalt definerte standarder har en tendens til å låse IIen til et gitt antall regler eller normer som gjør det vans- kelig å foreta seg endringer ved senere anledninger. Dette fenomenet kalleslock-in og er med på å øke kompleksiteten i IIen (Hanseth 2000).

Tradisjonelt sett har standardene vært utarbeidet og tilpasset omgivelsene via komiteer hvor alle relevante interessenter er representert. Dette har ført til en top down-tilnærming for innføring av standarder, noe som står i stor kontrast til ut- arbeidelsen av kanskje verdens største II, nemlig internett. Internett har en enorm kompleksitet og som en måte å håndtere dette på, har det foregått en lagvis standar- disering hvor hvert lag fungerer som en plattform. Når standardene på plattformen stabiliserer seg, kan man bygge videre på disse (Hanseth og Bygstad 2015, s. 648).

Dette er kunnskap som er nyttig å ta med seg ved innføring av standarder i bedrifter og organisasjoner fordi man daglig står overfor en kompleksitet som ikke kommer til å avta. Hanseth og Bygstad (2015) mener derfor at det er på tide å tenke an- nerledes når det kommer til håndtering og styring av store komplekse systemer, og at fremveksten av internett kan være til inspirasjon ved innføring og tilpasning av standarder. Likevel må man ta i betraktning at internett som II alltid vil oppføre seg annerledes enn de fleste bedrifter og organisasjoner, slik at man må ta hensyn til den enkelte II og finne det nivået av standarder som er mest passende.

Hva slags standard som innføres og hvordan man velger å gjøre det, avhenger av den gitte IIen og hvilke fremtidige mål som er satt. Det finnes en rekke ferdig definerte standarder som kan implementeres, men for å den fulle nytten av stan- darden er det viktig at den tilpasses. Dette gjør at en standard som opprinnelig er universell, slutter å være universell i det øyeblikket den er tilpasset og implementert (Hanseth og Braa 2001, s. 288).

Til tross for at standardene som beskrives i II-litteraturen er tekniske standarder, viser det seg at de også kan ha en indirekte koordinerende effekt. Et eksempel på dette er innføringen av Lotus SmartSuite-applikasjoner i Norsk Hydro som gjorde at hele organisasjonen ble bundet til å benytte Lotus sine produkter (Hanseth og Braa 2001, s. 268). Dette var koordinerende på den måten at alle ble bundet til å benytte de samme programmene og derfor mistet friheten til å kunne velge de systemene de selv foretrakk. På denne måten kan man derfor til dels anse dette

(32)

som standardiserte arbeidsprosesser, fordi alle brukerne ble låst til et bestemt utvalg applikasjoner som hver og en er utarbeidet med et visst bruksmønster.

[Sosiotekniske standarder]

2.5 Plan

2.5.1 Prosjektledelse

Ved gjennomføringen av et prosjekt, er et av de viktigste aktivitetene å planlegge.

God planlegging av et prosjekt er avgjørende for at det skal kunne bli vellykket, noe som gjelder uavhengig av prosjektets størrelse og kvalitet (Globerson og Zwikael 2002, s. 58). Hensikten med å planlegge er å forenkle kommunikasjon og styring gjennom å definere hva som skal gjøres, hvordan det skal gjøres og hvem som skal gjøre det. I tillegg estimeres det hvor lang tid hver oppgave tar og settes en frist for når en oppgave eller aktivitet skal være ferdig. I følge prosjektledelsesrammeverket PRINCE2, vil ikke et prosjekt kunne kontrolleres uten en plan og at dårlige planer forårsaker frustrasjon, sløsing og arbeid som må gjøres om igjen. Dette er derfor gode grunner for at grundige planer bør utarbeides, slik at prosjekter kan gjennom- føres på en så effektiv og smidig måte som mulig (Office of Government Commer- ce 2009, s. 61). For å kunne utarbeide planer som bidrar til et vellykket prosjekt, er man avhengig av å ha en forståelse av hva som kreves av prosjektet og hva man ønsker å oppnå. Dette gjøres ideelt sett ved hjelp av en detaljert kravspesifikasjon som beskriver funksjonalitetene til det avsluttende resultatet. Prosjektlederen har derfor ansvaret for at det utarbeides en kravspesifikasjon med det rette detaljnivået før man kan sette i gang med selve prosjektplanleggingen (Cadle og Yeates 2004, s. 121).

For å sørge for at alle deler av et prosjekt dekkes, finnes det ulike typer planer som befinner seg inn under paraplybegrepetplan. De vanligste plantypene innen PRINCE2 er:

• Prosjektplan

• Faseplan

• Unntaksplan

I en prosjektplan beskrives prosjektets omfang, tid, kostnad og kvalitet og hvor- dan man skal gå frem for å nå disse målene. Prosjektplanen er derfor en mer over- ordnet plan for hele prosjektet i motsetning til faseplanen, som har et annet detalj- nivå og beskriver kun en avgrenset bit av prosjektet. En faseplan er hensiktsmessig for at man skal kunne legge planer for mer håndterbare deler av et prosjekt. Likevel er det viktig at den samsvarer med prosjektplanen, slik at man til slutt kan leverer det produktet kunden har etterspurt. Nye faseplaner utarbeides kontinuerlig gjen- nom hele prosjektet og da typisk i prosessenlede faseovergang. En unntaksplan opprettes kun dersom det forekommer avvik som gjør at den aktuelle faseplanen ikke lenger kan benyttes. Dersom prosjektstyret godtar unntaksplanen, overtar den- ne for faseplanen (Office of Government Commerce 2009, s. 62-63).

(33)

2.5. PLAN 21 Ut ifra påstanden om at et godt planlagt prosjekt bidrar til et vellykket resultat, reflekteres derfor i planene presentert overfor og deres detaljnivå. Hvilket detalj- nivå man velger å legge planene på, må prosjektlederen avgjøre og se an i forhold til hva som er hensiktsmessig for det gitte prosjektet. Dersom man velger å legge seg på et for detaljert nivå, risikerer man at planene blir stive og det er vanskelig å gjøre endringer underveis. Og dersom man legger planer med for få detaljer, risike- rer man at man ikke kan levere det resultatet kunden ønsker (Office of Government Commerce 2009, s. 61-62).

Hvordan planer utarbeides og hvilke verktøy man velger å bruke vil avhenge av prosjektlederens preferanser, likevel påpeker Whitty og Maylor (2009) at man ikke trenger komplekse verktøy for å planlegge og håndtere et stort komplekst prosjekt.

Derimot mener de at man bør benytte en evidensbasert tilnærming for planlegging av denne typen prosjekter, fordi man da kan benytte teknikker som har bevist god effekt fra andre studier (Whitty og Maylor 2009, s. 304). PRINCE2 og Project Ma- nagement Institute sier derimot ingen ting om dette og gir prosjektlederen frihet til å gjennomføre planleggingen på den måten han selv ønsker. Likevel legges det ved at det bør gjøres avtaler innad i prosjektgruppen om hvilket nivå av detaljer planene skal ha og hvordan de best kan utformes for det gitte prosjektet (Office of Government Commerce 2009, s. 64). Ved å skape en felles enighet om frem- gangsmåte for planlegging, er det stor sannsynlighet for at deltakerne henter frem tidligere prosjekterfaringer som gjør at man forhåpentligvis utelukker potensielle feiltrinn som kan stikke kjepper i hjulene for fremdriften i prosjektet.

2.5.2 Informasjonsinfrastruktur

I følge Hanseth og Lyytinen (2010, s. 2) kan ikke en II designes kun basert på en rekke bestemte krav og deretter forvente at den blir vellykket. Dette bunner ut i IIens dynamiske vekst som gjør at den kontinuerlig er i endring og at krav som ble utarbeidet på ett tidspunkt kanskje ikke vil være aktuelle på et annet. Til tross for at de aller fleste IIer vil ha en mye mer begrenset dynamisk vekst enn for eksempel internett, vil de likevel være dynamiske ved at brukergrupper endres og nye behov skapes. Dette gjør det vanskelig å skulle utarbeide en langsiktig og detaljert plan for design av IIer.

Dersom det legges for strenge planer veldig tidlig i designprosessen, vil dette kunne hindre at potensielle brukere tar i bruk løsningen . Dette skyldes at løsningen enten er for strengt planlagt ved at den faktisk ikke er tilpasset de brukerne eller at den er planlagt på en slik måte at det ikke er rom for lokale tilpasninger underveis når brukerne oppdager nye behov og ønsker (Greenhalgh, Hinder, Stramer, Bratan og Russel 2010, s. 10). En annen utfordring ved å legge for strenge og detaljerte planer, er at IIen som den nye løsningen skal implementeres i kan ha endret seg, slik at den ikke lenger er kompatibel slik som først antatt. På denne måten vil den grundige planleggingen være bortkastet og mye av arbeidet må gjøres om igjen når implementasjonen nærmer seg (Hanseth og Lyytinen 2010, s. 7). Et eksempel på dette er innføringen av den digitale helsejournalen, HealthSpace, i England, hvor

(34)

store deler av de nye systemet ble planlagt lang tid i forveien av prosjektet. Da brukerne skulle ta i bruk systemet oppdaget de at det var store mangler som gjorde at det ikke var hensiktsmessig å benytte systemet likevel. Dette gjorde derfor at det kun var et fåtall som benyttet løsningen (Greenhalgh, Hinder, Stramer, Bratan og Russel 2010).

Som en løsning for å designe IIer på en måte som opprettholder dynamikken samtidig som at et visst nivå av styring overholdes, har Hanseth og Lyytinen ut- arbeidet ni designprinsipper med 19 tilhørende designregler. Prinsippene har som hensikt å bidra til økt stabilitet i IIen, noe som oppstår når det finnes en balanse mellom variasjon og orden samt at det tillates raske og dype endringer i store deler av systemet (Hanseth og Lyytinen 2010, s. 7). Prinsippene var hovedsakelig utar- beidet med internett som utgangspunkt, men med noen enkle tilpasninger kan de benyttes på mer styrte IIer. Både prinsippene og reglene tar utgangspunkt i å ut- arbeide et enkelt design slik at kun det mest essensielle i funksjonaliteten dekkes.

På denne måten vil funksjonaliteten enklere kunne implementeres i den installer- te basen samtidig som at det tilrettelegger for tilpasning til brukerne. Det vil også være enklere å gjøre tilpasninger i et enkelt design fremfor et komplekst. I tillegg til dette påpeker de at det er essensielt at man utarbeider designet i henhold til den installerte basen. Dersom den nye funksjonaliteten krever mer støtteinfrastruktur enn det som allerede finnes, kan terskelen for at løsningen tas i bruk øke (Hanseth og Lyytinen 2010, s. 10). Prinsippene fremstår derfor som enkle retningslinjer som i store og det hele handler om å gjøre det enkelt og ikke planlegge mer enn det som er nødvendig for å kunne gjennomføre implementasjonen.

Stacey (1996) påstår at tilpasningen blir optimal når man befinner seg på kanten av kaos der hvor det finnes en balanse mellom muligheten til å generere variasjon og modularitet. Dette underbygger Hanseth og Lyytinens utsagn om å kun planleg- ge det som er nødvendig for å kunne gjennomføre endringene. Da vil man kunne komme så nær punktet for kaos som overhodet mulig i en planlagt tilværelse.

Figur 2.2: Forholdet mellom plan og kaos

Figur 2.2 beskriver forholdet mellom planer og kaos. Ved å kun planlegge ak-

(35)

2.6. ORGANISERING 23 kurat det man trenger for å beskrive funksjonaliteten til endringen som skal inn- føres, tillater man også et visst nivå av kaos. I henhold til Staceys utsagn ønsker man derfor å befinne seg i det skraverte området i figuren for å sørge for så god tilpasning av nye funksjonaliteter som mulig.

2.6 Organisering

2.6.1 Prosjektledelse

I henhold til PRINCE2 vil sterkt hierarkisk prosjektledelse være med på å bidra til et vellykket prosjekt. Dette fordi den strenge top-down tilnærmingen vil være med på å skape god oversikt for prosjektlederen slik at han på best mulig måte kan koordinere de ulike aktivitetene i prosjektet (Office of Government Commerce 2009). Hierarkisk struktur er et av de mest grunnleggende trekkende ved tradisjo- nell prosjektledelse og derfor noe som går i igjen i de fleste store prosjektledelses- rammeverkene. Hvor «bratt» eller «flat» strukturen i prosjektet er, vil variere fra prosjekt til prosjekt og det vil i stor grad avhenge av størrelsen på prosjektet. Dette vil også kunne avhenge av hvilken prosjektledelsesmetodikk man velger å benytte, da de ulike metodikkene har en ulik grad av hierarkisk struktur. For å se på yt- terpunktene kan man ofte si at smidige metodikker slik som scrum gjerne har en flatere hierarkisk struktur enn for eksempel PRINCE2 og andre fossefallsmetodik- ker. Dette er ikke noe som eksplisitt nevnes i noen av de nevnte metodikkene, men tatt utgangspunkt i hvordan de strukturelt er bygget opp (Cadle og Yeates 2004;

Office of Government Commerce 2009; Sommerville 2011).

For å avgjøre om et prosjekt gjennomført somtop-downellerbottom-up, kan det være nyttig å skille mellom selve ledelsen av prosjektet og hvem som tok ini- tiativ til oppstart og gjennomføring. På denne måten skiller man mellom hvordan endringen ble gjort, altså prosjektgjennomføringen, og hvem i organisasjonen som hadde et ønske om å få gjennomført en endring ved hjelp av et prosjekt. Årsaken til at dette kan være nyttig, ligger i at et prosjekt alltid har en rekke hierarkis- ke egenskaper slik som prosjektgruppe, prosjektleder og styringsgruppe (Office of Government Commerce 2009, s. 29-43). Dette gjør derfor at et prosjekt aldri vil kunne defineres som et rent bottom-up-prosjekt, fordi det alltid vil være en grad av hierarkisk struktur. Likevel finnes det ulik grad av hierarkisk struktur som gjør at et prosjekts gjennomførelse kan helle mot enten top-down eller bottom. Derimot kan initiativet for gjennomføring av et prosjekt komme både fra sentralt og lokalt i organisasjonen. Dersom initiativet kommer fra lokalt ansees det som et bottom- up initiativ, og dersom det kommer fra sentralt i organisasjonen ansees det som et top-down initiativ (Smeds og Haho 2003). Det skal likevel legges ved at bruken av uttrykkenetop-downogbottom-uper i mye større grad benyttet innen organisa- sjonsledelse, og kan derfor være litt misvisende å benytte i prosjektsammenheng.

Graden av hierarkisk strukturvil være et mer passende uttrykk for å illustrere hvor- dan prosjektet ble gjennomført, men at top-down og bottom-up lettere kan knyttes opp mot hvem som tok initiativet for gjennomføringen av prosjektet.

(36)

Ettersom initiativet til gjennomføring av et prosjekt i de fleste tilfeller handler om et ønske om å foreta en endring, kan dette lett knyttes opp mot organiserin- gen av IIer og hvem som har muligheten til å ta denne typen beslutninger, slik som beskrevet i neste avsnitt. På denne måten vil ikke dette være knyttet opp mot prosjektet i seg selv, men derimot behovet og ønsket om en endring. Slik at for å av- gjøre hvordan et prosjekt er organisert, må man se på graden av hierarkisk struktur og hvordan dette påvirker muligheten de ulike prosjektdeltakerne har til å komme med input underveis i prosjektprosessen.

2.6.2 Informasjonsinfrastruktur

Tradisjonelt sett har det vært vanlig at endringer og omstruktureringer i organisa- sjoner har vært besluttet med en top-down ledelsestilnærming. Dette innebærer at beslutninger blir tatt sentralt i organisasjonen ved hjelp av et utvalg interessenter sammen kommer frem til en passende løsning for den kommende endringen. Hvil- ke interessenter som velges ut vil variere og derfor være en påvirkende faktor for hvor tilpasset det avsluttende resultatet vil være for organisasjonen. Normalt sett har det vært slik at når beslutninger tas sentralt gjøres dette med et sentralisert fo- kus ved at det legges lite til rette for lokale tilpasninger. Dette fordi beslutningene har som hensikt å omfatte hele IIens livssyklus, slik at den blir stabil og at det ikke forekommer noen videre endringer. Likevel har det vist seg at sentrale beslutnin- ger har en negativ effekt på innovasjon av IIer, fordi det ikke tas hensyn til den sosiotekniske kompleksiteten en II har. Dette betyr derfor at IIen kun blir ansett som en teknisk enhet uten at dens evolusjonære vekst og menneskelige aspekt tas i betraktning (Grisot, Hanseth og Thorseng 2014, s. 199-200).

Derfor mener Grisot et.al (2014, s. 214) at beslutninger bør tas bottom-up for- di det bidrar til innovasjon, da det tilrettelegger for muligheten til å kunne gjøre lokale tilpasninger i IIen. Når dette er mulig kan de ulike brukergruppene gjøre tilpasninger som gjør IIen muliggjørende for dem, slik at den kan vokse kontinu- erlig. Årsaken til at beslutninger som tas lokalt bidrar til innovasjon handler om det dannes en kunnskapsspiral som gjør at en løsning bidrar til dannelse av en ny, slik at det til enhver tid kan gjøres endringer og tilpasninger som åpner opp for nye muligheter (Smeds og Haho 2003, s. 889). Likevel finnes det her som ved sentrale beslutninger, utfordringer som kan gjøre det vanskelig å få nye brukere til å ta i bruk løsningen eller å implementere den som en del av den installerte basen. Dette bunner i at de tilpassede løsningene kan være veldig spesifikke, slik at det kan være utfordrende å få nye aktører til å ta den i bruk eller å inkludere den sammen med de andre eksisterende løsningene (Grisot, Hanseth og Thorseng 2014, s. 200).

Ved at sentrale beslutninger vil kunne være hemmende for innovasjon, samsva- rer dette godt med Henfridsson og Bygstad (2013) som fant ut at sentrale beslut- ninger bør tas i de tilfellene hvor det gjennomføres prosjekter som ikke har som hensikt å føre til innovasjon. Og på motsatt måte, bør beslutninger tas lokalt der- som det skal gjennomføres et prosjekt som har som hensikt å bidra til innovasjon i IIen. På denne måten sørger man for at prosjekter planlegges og gjennomføres på

(37)

2.7. OPPFØLGING 25 en måte som legger til rette for å gjøre lokale tilpasninger i de tilfellene der det er nødvendig. Ettersom ikke alle endringer av en II trenger å være muliggjørende og bidra til innovasjon, kan det derfor være nyttig å skille mellom hva slags prosjekter som skal gjennomføres og hvem som bør være beslutningstakeren (Henfridsson og Bygstad 2013).

Som en mellomting mellom top-down og bottom-up har Barett og Constanti- nides (2014, s. 3) kommet frem til det de omtaler somPolysentriskledelsestilnær- ming. Denne ledelsestilnærmingen beskriver hvordan man kan organisere flere or- ganisatoriske enheter på en måte som gjør at en får selvstendig autoritet til å kunne ta beslutninger for et spesifisert organisatorisk område. Ved å benytte en ledelses- tilnærming som dette distribueres beslutningsevnen jevnt over i organisasjonen slik at det både tilrettelegges for sentralisert og overordnet styring, samtidig som at det er mulighet til å gjøre lokale tilpasninger uten at det tas en sentral beslutning om det. Dette gjør derfor at man får det beste fra begge verdener (Barrett og Constanti- nides 2014). Til tross for at man benytter en polysentrisk ledelsestilnærming betyr ikke dette at man har angitt hvilke deler av organisasjonen som bør ta hvilke typer avgjørelser, slik som Henfridsson og Bygstad foreslår. For å kunne få fullt utbytte av denne ledelsestilnærmingen sett i perspektiv av utfordringene som finnes ved både bottom-up og top-down, bør man i tillegg til å distribuere beslutningsevnen i organisasjonen definere hvem som skal kunne ta hvilke typer beslutninger av- hengig av om beslutningen vil lede til innovasjon eller ikke (Grisot, Hanseth og Thorseng 2014; Henfridsson og Bygstad 2013).

Selv om den polysentriske ledelsestilnærmingen på mange måter løser en del problemer ved å finne en middelvei mellom top-down og bottom-up, krever den blant annet at IIen er av en viss størrelse slik at man enkelt kan dele den inn i ulike organisatoriske enheter. Ut ifra dette bør man derfor gjøre en avveining av hvordan beslutninger best mulig kan tas avhengig av den enkelte II og dens behov.

2.7 Oppfølging

2.7.1 Prosjektledelse

Den største årsaken til at prosjekter mislykkes er at det ikke er blitt satt realistiske forventninger til hverken det avsluttende resultatet eller prosjektprosessen. Dette fordi det ikke finnes noe konkret referansepunkt som man kan måle progresjonen til prosjektet mot eller som sier at man leverer et produkt som kunden ønsker. Ved å unngå å utarbeide realistiske forventninger, er derfor prosjektet dømt til å feile.

DeMarco mener at vellykket prosjektledelse handler om prosjektlederens evne til å håndtere kvantitative parametere på en måte som bidrar til å skape oversikt og struktur i et prosjekt(1982, s. 1-4).

Godt utarbeidede estimater legger til rette for grundig oppfølging av et prosjekt, fordi man har konkrete holdepunkter underveis i hele prosjektprosessen. Man bør likevel være bevisst på hvilken effekt estimater kan ha på mennesker når et prosjekt estimeres. Pessimistiske estimater ser ut til å ha den effekten at man får følelsen av

Referanser

RELATERTE DOKUMENTER

En åpning for salg av e-sigare er kan gi økt bruk både blant ungdom og unge voksne, en parallell til den økte snusbruken som først startet blant menn fra årtusenskiftet og

Dersom materialet er et tilfeldig utvalg, synes den økte innleggelsesrisikoen å være signifikant for gruppe II (p<0,05) og gruppe II (p<0,01) menn.. Det er mulig at denne

Imidlertid er det viktig å understreke at selv om de fleste per- soner med schizofreni er uten psykotiske symptomer mesteparten av tiden, vil en del være preget av følelsesmatthet

markedstilpasning ikke går på bekostning av kvalitet, eller stenger for mer overordnet tenkning. Ny teknologi, en global økonomi, økt turisme og innvandring fører til

personvernlovgivningen så fremt den gjennomføres i tråd med det som er dokumentert i meldeskjemaet med vedlegg den 31.10.2019, samt i meldingsdialogen mellom innmelder

Hvis individer med høyt evnenivå eller høy avkastning av utdanning tenderer til å velge lengre utdannelser enn andre, vil observerte forskjeller i inntekt mellom per- soner med

Fire i en-systemet (4i1) og strengere befolkningskontroll er nok det mest åpenbare. Det er allikevel flest likheter, som ansvarsforhold mellom politisk ledelse og

Vi kan registrere store avvik mellom partene (ledelse, verneombud og fagforening), når det gjelder gjennomføring av tiltak som kartlegging av ulike