Ledelse av store komplekse prosjekter

Størrelse: px
Begynne med side:

Download "Ledelse av store komplekse prosjekter"

Transkript

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 informasjonsinfrastrukturteori(ii) kunne supplere, eventuelt erstatte, tradisjonell prosjektledelsesteori 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 prosjektledelseslitteraturen 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 IIlitteraturen tar høyde for det menneskelige aspektet i mye større grad enn prosjektledelseslitteraturen. 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 Bakgrunn for studien Motivasjon Problemstilling Oppgavens disposisjon Litteratur Prosjektledelse Prosjektledelsesrammeverk PRINCE De syv prosessene Informasjonsinfrastruktur Tilpasning av II-litteraturen Store komplekse prosjekter Hva er et vellykket prosjekt? Prinsipper for koordinering Prosjektledelse Informasjonsinfrastruktur Plan Prosjektledelse Informasjonsinfrastruktur Organisering Prosjektledelse Informasjonsinfrastruktur Oppfølging Prosjektledelse Informasjonsinfrastruktur Oppsummering Metode Paradigme Metode Innhenting av caser

8 INNHOLD 3.3 Teknikk Litteraturstudie Dokumentanalyse Intervju Analyse Unntak Validitet Etikk Personvernombudet Lydopptak Oversikt over informanter og bedrifter Anonymisering Case Prosjekt A Prosjekt B Prosjekt C Prosjekt D Prosjekt E Prosjekt F Funn Generelt Prinsipper for koordinering Standardiserte prosesser Tekniske standarder Resultat Plan Prosjektplaner Planer for organisk vekst Resultat Organisering Hierarkisk ledelse Ledelse for innovasjon Resultat Oppfølging Prosjektoppfølging Kultivering Resultat Funn

9 INNHOLD 7 Diskusjon Forventet mønster og observert mønster Pattern Matching Prinsipper for koordinering Plan Organisering Oppfølging Svar på problemstilling Konklusjon Bidrag til prosjektledelseslitteraturen Hva bidrar til et vellykket prosjektresultat? Eventuelle forbedringer Videre arbeid Referanser 86 A Appendix A 91 A.1 Sammendrag Prosjekt A A.2 Sammendrag Prosjekt B A.3 Sammendrag Prosjekt C A.4 Sammendrag Prosjekt D A.5 Sammendrag Prosjekt E A.6 Sammendrag Prosjekt F B Appendix B 113 B.1 Intervjuguide B.2 Kvittering fra personvernombudet B.3 Samtykkeskjema B.4 PRINCE2 Prosessmodell

10 INNHOLD

11 Figurer 1.1 Tradisjonelt prosjekt Stort komplekst prosjekt Vippepunkt for innføring av standarder Forholdet mellom plan og kaos Tabeller 2.1 Oppsummering litteratur Prinsipper for koordinering oppsummert Plan oppsummert Organisering oppsummert Oppfølging oppsummert Funn Oppsummering diskusjon Forventet mønster Observert mønster

12 TABELLER

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. Dersom 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 nettverk. Et slikt nettverk er det man kan beskrive som komplisert altså et nettverk bestående av mange like, men sammenhengende komponenter (Oxford Dictionaries 2015a). Så fort man involverer menneskelige aktører i et komplisert nettverk, vil det finnes mange ulike, men sammenhengende komponenter og man har derfor et komplekst nettverk (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 oftere 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 integrasjonsarkitektur, 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 kompleksitet 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 2 KAPITTEL 1. INTRODUKSJON 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 oppfatning 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 prosjektleder 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 prosjektledere 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 prosjektene i stor grad handler om å effektivisere og optimalisere eksisterende løsninger, 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 enn informasjonsinfrastrukturprosjekter.

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 enkeltstå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 gjennomfø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, altså 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 snakke 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 ITprosjekter, tilsier teoriene innen både prosjektledelse og IIer at store komplekse prosjekter bør styres annerledes.

16 4 KAPITTEL 1. INTRODUKSJON 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 leverer 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 aktivitetene 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 prosjektgjennomføring, ville det være hensiktsmessig å kunne avgjøre om de to ulike formene for oppfølging sammen kan bidra til et vellykket prosjektresultat.

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 prosjektledelse 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 6 KAPITTEL 1. INTRODUKSJON

19 Kapittel 2 Litteratur I dette kapittelet vil jeg ta for meg fagfeltene prosjektledelse og informasjonsinfrastrukturer(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, nemlig standardisering, planlegging, organisering og oppfølging. I henhold 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 oppsummert 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 Management 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 hensikten 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 organisasjonen 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 8 KAPITTEL 2. LITTERATUR nomføres i. En tommelfingerregel kan være at et prosjekt er midlertidig, men sluttproduktet 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 prosjektene 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 Group mener 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 prosjekt, 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 koordinering 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 menneskelige problemer. Prosjektlederen må jobbe proaktivt ved at han til enhver tid må identifisere og planlegge for potensielle endringer (Cadle og Yeates 2004, s. 1) Prosjektledelsesrammeverk Avhengig av hva slags prosjekt man ønsker å gjennomføre, finnes det ulike prosjektledelsesrammeverk 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 tradisjonelle 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 brukes 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 tidog 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) PRINCE2 PRINCE2 er et generisk prosjektrammeverk basert på best practice innen prosjektledelse. 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 rammeverket 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 ) 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 10 KAPITTEL 2. LITTERATUR prosessene, ved at det er temaene som illustrerer hva som er de essensielle ledelsesoppgavene, 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 ) 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 benytter. 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 prosjektet er 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 i oppstart av prosjektet er: 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 ).

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 fasen eierstyring av prosjektet med en forespørsel om initiering. Hensikten med denne prosessen er å gjøre prosjektstyret i stand til å ta de viktige avgjørelsene og utøve overordnet kontroll overfor prosjektlederen (Office of Government Commerce 2009, s ). Den viktigste aktiviteten i eierstyring 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 prosjekteieren typisk være IT-direktøren. Seniorbrukerne representerer sluttbrukerne av løsingen og er ansvarlige for å presisere deres behov og ønsker. Seniorleverandører er representanter for de som designer, utvikler og implementerer prosjektets produkter (Office of Government Commerce 2009, s ). Initiere prosjektet Når prosjektstyret har autorisert initiering og faseplan for initieringen, går man over i fasen initiere 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 i initiere prosjektet er: Utforme usikkerhets-, konfigurasjons-, kvalitets- og kommunikasjonsstrategien Opptrette prosjektplan Forfine business case Samle initieringsdokumentasjonen Det er i denne prosessen prosjektlederen inntar sine ansvarsområder og utarbeider prosjektforslaget, initieringsdokumentasjonen, arbeidspakkene og fase- /unntaksplaner (Office of Government Commerce 2009, s ). 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 prosessen kontrollere en

24 12 KAPITTEL 2. LITTERATUR fase er å tildele arbeid, rapportere fremdrift til prosjektstyret og gjøre korrigerende tiltak (Office of Government Commerce 2009, s. 168). De viktigste aktivitetene i kontrollere en fase er: 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 teamleder også er prosjektleder. Hensikten med styre produktleveranser er å kontrollere koblingen mellom prosjektleder og teamleder og sette krav til utførelse av arbeidspakkene (Office of Government Commerce 2009, s. 186). Den viktigste aktiviteten i styre produktleveranser er: Akseptere, utføre og levere arbeidspakke Lede faseovergang Mot slutten av hver fase går man over i prosessen lede faseovergang. Hensikten med prosessen er å gi prosjektstyret tilstrekkelig med informasjon for å kunne evaluere suksessen av den aktuelle fasen, godkjenne neste faseplan og bekrefte kontinuerlig forretningsmessig forankring. (Office of Government Commerce 2009, s. 194). De viktigste aktivitetene i lede faseovergang er: 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. Dersom 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 ). De viktigste aktivitetene i avslutte prosjektet er:

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 produktene 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 ). 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 brukergrupper. 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 epostserver. 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 epostklienten 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 fleksible 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 heterogen 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 elementene 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 14 KAPITTEL 2. LITTERATUR En viktig egenskap ved IIer er at de aldri vil kunne bygges fra grunnen av (Hanseth 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 regelmessig 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 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 eksempel ubegrenset fri vekst og åpenhet ikke nødvendigvis passer i alle sammenhenger hvor IIdefinisjonen 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 som lokale og sentrale tilpasning kunne 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 kontekst 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 resultat, 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 i store komplekse prosjekter. Et stort komplekst prosjekt kjennetegnes ved at det består av et stort antall aktører, både tekniske og ikketekniske, som skaper spenninger på tvers av prosjektet. Spenningene bunner ut i den kontinuerlige brukertilpasningen som gjøres for å sørge for at prosjektresultatet 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. Spenninger 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 kompliserte. I tillegg var ikke protokollene kompatible med de som allerede fantes i OSI-modellen, noe som gjorde det vanskelig å inkludere dem med andre protokoller. Å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 spenninger 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 effektivisering 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 eksisterende systemer, som skiller de store komplekse prosjektene fra de tradisjonelle.

28 16 KAPITTEL 2. LITTERATUR Hva er et vellykket prosjekt? Selv om det i PRINCE2 er utarbeidet syv prosesser, temaer og prinsipper for gjennomføring av prosjekter, sier disse ingen ting om hva som utgjør et vellykket prosjekt. 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 vinkler 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 prosjektet. 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 prosjektresultat 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 subjektivt 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 interne 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åleenhetene 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 arbeidsoppgaver. I samsvar med store komplekse prosjekter vil standardene være tilknyttet bruk av standardiserte prosjektledelsesrammeverk og innføring av standarder i bedriften som en del av koordineringen av et prosjekt. Standardiseringsbegrepet er likevel er veldig vidt begrep som vil være ulikt avhengig 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 datakommunikasjon Prosjektledelse Som en måte å koordinere og organisere prosjekter på, er det vanlig å benytte ferdig utarbeidede prosjektledelsesrammeverk. Disse rammeverkene har gjerne en logisk 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 suksessraten 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 18 KAPITTEL 2. LITTERATUR til å kunne gjennomføre et vellykket prosjekt. Likevel er det kun til et visst punkt at standardisering øker suksessraten, altså til vippepunktet. Dersom det innføres flere standardiserte prosesser enn vippepunktet tilsier, risikerer man at suksessraten senkes. Hvor vippepunktet befinner seg vil variere fra organisasjon til organisasjon, noe som derfor gjør det vanskelig å avgjøre hvor mange og hvilke standardiserte prosesser som bør innføres for å oppnå ønsket effekt (Milosevic og Patanakul 2005, s ). 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 standardiserte 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 prosjektledelsesrammeverk. 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 mennesker som deltar i prosjektet og prosjektleders evne til å utnytte deres erfaringer, har vel så mye innvirkning på suksessraten som et standardisert prosjektledelsesrammeverk (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 ), 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) Informasjonsinfrastruktur Innen IIer benyttes innføring av standarder som et tiltak for økt styring. Utfordringen 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 innfø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 vanskelig å foreta seg endringer ved senere anledninger. Dette fenomenet kalles lock-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 utarbeidelsen 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 standardisering 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 annerledes 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 standarden 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 20 KAPITTEL 2. LITTERATUR 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 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 gjennomføres på en så effektiv og smidig måte som mulig (Office of Government Commerce 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 paraplybegrepet plan. De vanligste plantypene innen PRINCE2 er: Prosjektplan Faseplan Unntaksplan I en prosjektplan beskrives prosjektets omfang, tid, kostnad og kvalitet og hvordan man skal gå frem for å nå disse målene. Prosjektplanen er derfor en mer overordnet plan for hele prosjektet i motsetning til faseplanen, som har et annet detaljnivå 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 gjennom hele prosjektet og da typisk i prosessen lede 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 denne for faseplanen (Office of Government Commerce 2009, s ).

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 detaljnivå 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, risikerer man at man ikke kan levere det resultatet kunden ønsker (Office of Government Commerce 2009, s ). 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 Management 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 fremgangsmå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 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 22 KAPITTEL 2. LITTERATUR 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 utarbeidet 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 utarbeidet med internett som utgangspunkt, men med noen enkle tilpasninger kan de benyttes på mer styrte IIer. Både prinsippene og reglene tar utgangspunkt i å utarbeide et enkelt design slik at kun det mest essensielle i funksjonaliteten dekkes. På denne måten vil funksjonaliteten enklere kunne implementeres i den installerte 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 planlegge 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 innfø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 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 tradisjonell prosjektledelse og derfor noe som går i igjen i de fleste store prosjektledelsesrammeverkene. 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å ytterpunktene kan man ofte si at smidige metodikker slik som scrum gjerne har en flatere hierarkisk struktur enn for eksempel PRINCE2 og andre fossefallsmetodikker. 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 som top-down eller bottom-up, kan det være nyttig å skille mellom selve ledelsen av prosjektet og hvem som tok initiativ 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 hierarkiske egenskaper slik som prosjektgruppe, prosjektleder og styringsgruppe (Office of Government Commerce 2009, s ). 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 bottomup 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 uttrykkene top-down og bottom-up er i mye større grad benyttet innen organisasjonsledelse, og kan derfor være litt misvisende å benytte i prosjektsammenheng. Graden av hierarkisk struktur vil være et mer passende uttrykk for å illustrere hvordan 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 24 KAPITTEL 2. LITTERATUR 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 organiseringen 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 å avgjø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 Informasjonsinfrastruktur Tradisjonelt sett har det vært vanlig at endringer og omstruktureringer i organisasjoner 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. Hvilke 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 fokus 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 beslutninger 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 ). Derfor mener Grisot et.al (2014, s. 214) at beslutninger bør tas bottom-up fordi 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 kontinuerlig. Å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, samsvarer dette godt med Henfridsson og Bygstad (2013) som fant ut at sentrale beslutninger 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 dersom 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 Constantinides (2014, s. 3) kommet frem til det de omtaler som Polysentrisk ledelsestilnærming. Denne ledelsestilnærmingen beskriver hvordan man kan organisere flere organisatoriske 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 ledelsestilnæ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 Constantinides 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 avhengig 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 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

38 26 KAPITTEL 2. LITTERATUR å ha mer tid til gode enn man tror, slik at man jobber saktere og antageligvis også gjør mindre. Optimistiske derimot har effekten at mennesker blir stresset, fordi det faktisk er estimert for lite tid for å gjennomføre en arbeidsoppgave (McConnell 2006, s ). Til tross for at realistiske estimater legger til rette for god oppfølging, påpeker Jørgensen(2005, s. 3) at det er viktig å skille mellom plan og estimat. Dette fordi planer og estimater har ulike formål, ved at planer har som hensikt å definere hva som skal gjøres og i hvilken rekkefølge, mens estimater sier noe om hvor lang tid noe vil ta. Ved å skille dem fra hverandre blir man «tvunget» til å være bevisst på hva som inngår i en prosjektplan og hva estimater innebærer, slik at de kan bidra til oppfølging på best mulig måte. I PRINCE2 benyttes det også teknikker for oppfølging av et prosjekt som kan minne om ressursestimering, men som er mer direkte knyttet til prosjektresultatet. Estimatene i PRINCE2 omtales som toleranser og har som hensikt å beskrive hvor mye avvik man kan tolerere i både positiv og negativ retning sett i lys av kostnad, tid og kvalitet. De beskriver derfor et spekter som angir hva man kan godta for at resultatet skal stå til kundens forventinger (Office of Government Commerce 2009, s. 101). Toleranser benyttes derfor på samme måte som estimater ved at de fungerer som referanseverdier prosjektlederen forholder seg til for å måle fremgangen på prosjektet. Ettersom toleransene er mer knyttet opp mot prosjektresultatet gjør det også at prosjektlederen kan bruke dem til å sikre at produktet er levedyktig i henhold til prosjektmandatet. Noe som er definert i PRINCE2, men ikke i generell ressursestimering, er hvordan man går frem dersom man ikke overholder estimatene eller toleransene. I PRINCE2 eskaleres dette til et endringsråd, og om det besluttes at toleransene er overskredet for mye, settes det i gang korrigerende tiltak. Dette fungerer i prinsippet på samme måte som ved risikohåndtering ved at prosjektleder foreslår ny faseplan for resterende del av fasen. På denne måten kommer prosjektet i balanse igjen og prosjektlederen har en konkret plan som gjør at han kan fortsette oppfølgingen (Office of Government Commerce 2009, s. 101) Informasjonsinfrastruktur Ettersom IIer ikke har en avgrenset levetid og at deres vekst kan sammenlignes med en evolusjon, vil planlegging og ledelse av IIen være en pågående og kontinuerlig prosess. På grunn av den begrensede planleggingen som foregår i en IIs evolusjon, snakker man ofte om at teknologien kultiveres fremfor å bygges. Når en II kultiveres tar man utgangspunkt i den installerte basen og benytter den til å gjennomføre inkrementelle og gradvise endringer. Endringene som gjennomføres har som hensikt å dyrke de egenskapene ved IIen som fungerer godt, og å fase ut de mindre vellykkede delene. Grisot et.al(2014, s ) beskriver tre karakteristikker ved anvendelse av en kultiveringsstrategi:

39 2.7. OPPFØLGING 27 Prosessorientering Mobilisere brukere Læring Prosessorienteringen handler om at man bør gå forsiktig frem når man skal inkludere ny teknologi i institusjonaliserte omgivelser, slik som i en organisasjon. Karakteristikken om mobilisering av brukere beskriver hvordan styring av en II ikke er gitt til et lite antall personer, men en rekke brukergrupper. Dette betyr derfor at brukere må bli mobilisert og motivert for å ta i bruk ny teknologi. Egenskapen om læring er knyttet til muligheten til å lære underveis og skaffe seg kjennskaper til hvilke deler av IIen som er mest funksjonelle og ikke (Grisot, Hanseth og Thorseng 2014, s ). Kultiveringen handler derfor i stor grad om måten man følger opp en II på, både teknisk og sosialt. Hanseth og Aanestad(2003) bruker bootstrapping som en måte å gjennomføre vellykket kultivering på. Bootstrapping kan knyttes opp mot mobiliseringsaspektet ved kultivering, fordi det handler om hvordan man på best mulig måte går frem for å motivere brukere til å ta i bruk nye funksjonaliteter i en II. Når man dyrker frem de egenskapene ved en II som allerede er vellykkete, er det nærliggende å gjøre dette ved å utvide med nye funksjonaliteter. For å sørge for at funksjonaliteten blir adoptert i IIen, beskriver Hanseth og Aanestad en gruppe mennesker som tar ny funksjonalitet i bruk tidlig etter implementasjonen og er avgjørende for at de andre brukerne også tar den i bruk. Denne gruppen beskrives som den kritiske massen og er avgjørende for at resten av brukergruppen tar den nye funksjonaliteten i bruk (Hanseth og Aanestad 2003). Det er derfor avgjørende å motivere og overbevise den kritiske massen for at IIens evolusjon skal kunne fortsette. Noe som kan påvirke kultiveringen, er hvordan arkitekturen administreres. Dette ved løsninger som kun baseres på arkitekturen hvor det kreves at all funksjonalitet er på plass allerede fra starten av, har en tendens til å skape en kompleksitet som gjør det vanskelig å gjøre endringer i fremtiden. I slike tilfeller kreves det en helt annen grad av koordinering av brukergruppene og at det kan bli svært dyrt å gjøre fremtidige endringer. Årsaken til dette er at arkitekturen vil bli for stiv til å kunne gjøre uforutsette endringer (Grisot, Hanseth og Thorseng 2014, s. 213). Typiske eksempler på dette ser man der hvor beslutninger om endringer tas med mål om at de skal omfatte hele IIens levetid. Ved å gjøre dette fokuserer man kun på den tekniske delen av IIen og glemmer hvordan menneskelige aktører kontinuerlig påvirker IIen. Dersom man ikke tar hensyn til dette risikerer man at de tekniske funksjonalitetene ikke lenger tas i bruk og IIen vil til slutt dø.

40 28 KAPITTEL 2. LITTERATUR 2.8 Oppsummering Med bakgrunn i litteraturen som er presentert over, vil jeg oppsummere dette slik: Prinsipper for koordinering Plan Organisering Oppfølging Prosjektledelse Standardisert metodikk gir vellykket resultat (Milosevic og Patanakul 2005, s. 189) (Office of Government Commerce 2009, s. 31) Detaljert plan bidrar til god styring av et prosjekt (Office of Government Commerce 2009, s ) (Cadle og Yeates 2004, s. 120) Hierarkisk prosjektledelse gir vellykket resultat (Office of Government Commerce 2009) (Cadle og Yeates 2004) Kontrollert oppfølging av bidrar til et vellykket prosjektresultat (DeMarco 1982, s. 1) (Office of Government Commerce 2009, s. 101) Informasjonsinfrastruktur Tekniske standarder støtter koordinering indirekte (Hanseth og Braa 2001, s ) (Hanseth og Bygstad 2015) En kompleks II utvikles organisk over tid og kan ikke planlegges i detalj (Hanseth og Lyytinen 2010) (Greenhalgh, Hinder, Stramer, Bratan og Russel 2010) Prosjekter med innovasjon bør besluttes desentraliert Prosjekter uten innovasjon bør besluttes sentralisert (Henfridsson og Bygstad 2013) (Grisot, Hanseth og Thorseng 2014) Kontinuerlig oppfølging bidrar til effektiv kultivering av IIen (Grisot, Hanseth og Thorseng 2014) Tabell 2.1: Oppsummering litteratur

41 Kapittel 3 Metode I dette kapittelet vil jeg presentere studiens filosofiske perspektiv, valg av forskningsmetode og hvilke teknikker som er benyttet for innsamling av data. Hvordan analysen ble gjennomført og hvordan jeg har gått frem for å gjennomføre en studie med høy validitet, vil også bli beskrevet. 3.1 Paradigme Kvalitativ forskning deles opp i ulike paradigmer som beskriver forskningens filosofiske perspektiv. Hvilke inndelinger den kvalitative forskningen er delt inn i, varier noe avhengig av hvilke forskningsteorier man velger å følge. De mest kjente filosofiske perspektivene innen kvalitativ forskning kalles positivisme, fortolkende paradigme og kritisk paradigme (Chua 1986). Denne studien er gjennomført innenfor det positivistiske paradigmet, og kjennetegn ved positivisme er at forskeren har et objektivt syn på verden som beskrives av målbare enheter som er uavhengig av forskerens egne tanker og oppfatninger (Myers 2015). Innenfor dette paradigmet er det vanlig å gjennomføre hypotesetesting og kvantifiserbare målinger av data. Det fortolkende paradigmet handler om å forstå sosiale relasjoner og fenomener gjennom intersubjektive relasjoner. Dette betyr altså at forståelsen en forsker får dannes ved han henter inn informasjon om menneskers tanker og erfaringer rundt et gitt fenomen. Forskerens egne tanker og forkunnskaper er en naturlig del av forskningen og er med på å forme den forståelsen som dannes i relasjon med andre mennesker (Orlikowski og Baroudi 1991, s. 13). Mens det positivistiske og fortolkende paradigmet handler om å kartlegge eller beskrive et fenomen, handler det kritiske paradigmet om å kritisere eksisterende sosiale systemer ved å avsløre konflikter og ulikheter. Dette gjøres for å skape forståelse og bevissthet omkring sosiale relasjoner (Orlikowski og Baroudi 1991, s. 19). Med utgangspunkt i refleksjonene omkring de tre paradigmene, mener jeg at det positivistiske paradigmet hadde den mest passende vinklingen for gjennomføring av denne studien. 29

42 30 KAPITTEL 3. METODE 3.2 Metode Studiens valgte metode er case studie. En case studie er en grundig og detaljert kvalitativ forskningsmetode hvor man benytter en eller flere caser for å belyse et fenomen eller tema. Det finnes flere teoretikere innen kvalitativ forskning og case studier som hver har sine vinklinger på hvordan en case studie best kan gjennomføres. Robert E. Stakes tolkning av case studier er vinklet mot det fortolkende paradigmet, hvor forskerens posisjon i studien er en viktig faktor (2005, s. 444). Robert K. Yins tolkning av case studier er vinklet mot det positivistiske paradigmet og kan på mange måter regnes som den mest kvantitative måten å gjennomføre en kvalitativ studie på. Yin deler case studier opp i tre varianter: forklarende (engelsk: explanatory), beskrivende (engelsk: descriptive) og utforskende (engelsk: exploratory), noe som gjør metoden svært allsidig (1994, s. 4). En forklarende case studie har som hensikt å forklare hvordan eller hvorfor noe er som det er, og brukes gjerne i studier hvor man ser på et fenomen over lengre tid. Dette fordi det i slike studier kan være mer hensiktsmessig å se på historiske data fremfor å se på frekvensen av forekomster eller indekser. Et eksempel på en forklarende case studie er å finne årsakene til at et samfunn hindret utbyggingen av en motorvei. En beskrivende case studie har som hensikt å beskrive hyppigheten eller utbredelsen av, eller å forutsi utfallet ved et fenomen. Et eksempel på en slik studie kan være å se på spredningen av en sykdom. I motsetning til de nevnte variantene av case studier, har en utforskende case studie som hensikt å utarbeide en hypotese samt å legge til rette for videre undersøkelser. En egenskap ved denne metoden er at hypotesen er konkret og målbar, slik som "hvilke trekk vedeller "hvor mange/mye"(yin 1994, s. 5-6). Ettersom problemstillingen hadde som hensikt å identifisere konkrete teorier i IIlitteraturen som kan supplere til prosjektledelseslitteraturen, var det nærliggende at studien ble gjennomført som en utforskende case studie. For planleggingen av gjennomføringen av case studien tok jeg utgangspunkt i hvordan analysen skulle gjennomføres. Analysen skulle gjennomføres ved hjelp av pattern matching som går ut på at man sammenligner en rekke antagelser, forventet mønster (engelsk: expected pattern), med dataene fra datainnsamlingen, oberservert mønster (engelsk: observed pattern). Dette er en strukturert måte å gjennomføre teoritesting på som gjør det enkelt å organisere kvalitative data. Det finnes to varianter av pattern matching kalt avhengig (engelsk: dependent) og uavhengig (engelsk: independent), hvor avhengig pattern matching handler om at alle påstandene er strengt avhengige av hverandre slik at dersom en av dem er usann, er alle usanne. Dersom resultatet er som antatt, kan man trekke en solid slutning om at påstandene stemmer. Ved uavhengig pattern matching er påstandene uavhengige av hverandre og resultatene trekkes basert på hvor stor grad av overlapp det er mellom forventet og observert mønster (Yin 1994, s ). Ettersom det teoretiske grunnlaget for studien baserer seg på forskning fra to ulike fagfelt, ble begge disse benyttet i pattern matchingen. Ettersom fagområdene på mange måter er rake motsetninger til hverandre, bidrar dette til at man får to konkurrerende mønstre i pattern matchingen. Dette kan gjøre pattern matchingen

43 3.2. METODE 31 noe mer komplisert, men Yins prinsipper omkring metoden er fortsatt gjeldende. Ved bruk av konkurrerende patterns, må man gjennomføre en uavhengig pattern matching. Dette fordi man ikke kan ha avhengighet på tvers av observerte mønstre, ettersom hver av casene i studien er uavhengige av hverandre (Yin 2014, s. 146). Det ville uansett ikke vært relevant å gjennomføre en avhengig pattern matching med flere caser, da jeg mener at det ville være mulig å trekke slutninger knyttet til ledelse av store komplekse prosjekter uten av det var fullstendig overlapp mellom forventet og observert mønster. Yin påpeker en feil mange forskere gjør er å ikke utarbeide en plan for analyse før datainnsamlingen. På denne måten risikerer man å ende opp med en masse data man hverken vet hvordan man kan bruke eller analysere. Dette problemet løses ved bruk av pattern matching ved at man blir nødt til å definere påstandene som legges til grunn for studien i forkant av analysen og datainnsamlingen. Hypotesene man utarbeider i forkant av datainnsamlingen vil fungere som en veiledning når dataene samles inn(yin 1994, s. 106). Dette var også et av argumentene for å ikke velge Stakes variant av case studier, fordi han ikke har noen ferdig definert måte å skulle analysere dataene på. Ved å benytte pattern matching skapes det en trygghet vet at dataene målrettet samles inn for å svare på ferdigdefinerte hypoteser og påstander. Case studie som metode får ofte mye kritikk og anses gjerne som en ufullstendig forskningsmetode. Dette fordi mange mener den kun kan brukes til kartlegging av studier fordi den ikke kan gi pålitelig informasjon. Selv om case studier kan brukes til pilotstudier for å generere hypoteser, er den også en fullverdig forskningsmetode. En case studie er spesielt hensiktsmessig for å falsifisere eller verifisere påstander, slik som i pattern matchingen. Dette kan gjøres ved at man har en påstand "alle svaner er hvite", for så å falsifisere den ved å finne en case med en sort svane. På denne måten har man fullført en fullverdig case studie ved å avkrefte en påstand (Flyvbjerg 2006, s. 220 og ). Et argument for å ikke benytte case studier som forskningsmetode blir det ofte sagt at teoretisk, kontekstuavhengig kunnskap er mer verdifull enn konkret, praktisk og kontekstavhengig kunnskap. Når Flyvbjerg forteller om fem vanlige misforståelser ved case studier, avkrefter han denne påstanden ved å si at fellestrekket for alle eksperter er at de har konkret kontekstavhengig kunnskap. Med dette sier han derfor at man aldri kan bli mer enn middelmådig om man kun tilnærmer seg teoretisk kunnskap, og at man først kan bli en ekspert på noe dersom man tilegner seg praktisk erfaring (Flyvbjerg 2006, s. 222). Med dette vil jeg trekke linjer til min egen case studie hvor jeg gikk inn og hentet ut informasjon om andres erfaringer knyttet til ledelse av store komplekse prosjekter. Siden disse prosjektlederne har lengre erfaring med denne typen prosjekter, vil jeg derfor anta at de har opparbeidet seg mye konkret, praktisk og kontekstavhengig kunnskap som gjør dem dyktige innenfor sitt fagområde. Selv om jeg ikke fikk tilegnet meg min egen praktiske erfaring under denne studien, brukte jeg derfor andres til å kunne bekrefte eller avkrefte mine teoretiske hypoteser.

44 32 KAPITTEL 3. METODE Innhenting av caser For å finne caser til studien benyttet jeg relasjoner i tilknytning til min egen arbeidsplass og familie. Ettersom jeg hadde som mål å finne prosjekter som var relativt ulike, ble ledet av forskjellige prosjektledere og gjennomført i ulike organisasjoner, måtte jeg legge en del arbeid å i finne caser som levde opp til disse kravene. Ikke minst måtte de også ha en kompleksitet som gjorde at jeg kunne karakterisere dem som store komplekse prosjekter. Det er av flere grunner at jeg valgt å benytte denne typen relasjoner for å skaffe caser, og det er blant annet fordi det vil gi en mye mer direkte tilgang til de rette personene enn om man må henvende seg til en organisasjon man ikke har noen kontaktperson i. Dette var tidsbesparende, slik at jeg slapp å bruke mye tid på å vente på svar og finne rett kontaktperson. I tillegg kunne jeg få raskt svar på om personene jeg kontaktet hadde mulighet til å gjennomføre et intervju med meg. En annen grunn er at det er vanskelig å vite hvilke prosjekter som blir gjennomført i hvilke organisasjoner. Dersom man ikke har innsyn i en organisasjon vil det være vanskelig å ha informasjon om dette, med mindre det er en stor statlig organisasjon hvor det kreves at denne typen informasjon publiseres. Ved å benytte familiære relasjoner, kunne jeg få innsyn i organisasjoner jeg selv ikke hadde tilknytning til, slik at jeg kunne finne passende caser for studien. Jeg endte opp med totalt seks caser, som jeg mener var med på å gi både nok dybde og bredde til denne studien. 3.3 Teknikk Som en basis for datainnsamlingen benyttet jeg Yins fire prinsipper om datainnsamling. Prinsippene fungerer som veiledende retningslinjer som kan være nyttige å ha i bakhodet underveis i datainnsamlingsprosessen. Yin mener at prinsippene er essensielle dersom man ønsker å gjennomføre en case studie av høy kvalitet, ved at de legger til rette for validitet og pålitelighet. Prinsippene kan anvendes sammen med de fleste datainnsamlingsteknikkene, noe som gjør dem enkle å implementere i nesten alle case studier (Yin 2014, s. 105). 1. Bruk flere kilder som bevis Ved å benytte flere kilder sammen styrker man validiteten til bevisene man presenterer, fordi de underbygger den samme påstanden. I tillegg vil studien oppfattes som mer overbevisende og nøyaktig når man har benyttet flere teknikker som til slutt kommer frem til samme resultat (Yin 2014, s ). 2. Opprett en case studie database Yin foreslår at man oppretter en database for organisering av rådataene fra studien, slik at man har en mellomlagring av dataene før de skrives inn i sluttrapporten. På denne måten kan man enkelt kan gå tilbake til dataene og hente ut den informasjonen man trenger underveis i arbeidet (Yin 2014, s. 123).

45 3.3. TEKNIKK Vedlikehold kjeden av bevis For å sørge for at leseren kan følge bevisene i studien og for å øke påliteligheten til informasjonen i caset, er det viktig å føre en oversikt over dataene som er benyttet og hvor de er hentet fra. På denne måten er man åpen om hvilke kilder som benyttes i tillegg til at man ikke tar kredibilitet for andres arbeid. Oversikten bør oppdateres til enhver tid, slik at leseren har mulighet til å følge kildene gjennom hele sluttrapporten (Yin 2014, s. 127). 4. Vis forsiktighet når du bruker bevis fra elektroniske kilder Dersom man henter data fra elektroniske kilder, slik som observasjon av en chat-historikk eller gjennomføring av intervjuer elektronisk, bør man vise ekstra forsiktighet fordi man ikke nødvendigvis kjenner validiteten til informasjonen (Yin 2014, s. 129). Prinsippene ble derfor aktivt benyttet gjennom hele datainnsamlingsprosessen, for å prøve å skape høyest mulig grad av validitet og pålitelighet omkring dataene som ble hentet inn. Dette var viktig for å danne et solid grunnlag for slutningene som skulle bli trukket i tilknytning til studiens problemstilling. For gjennomføring av studien benyttet jeg følgende teknikker for datainnsamling: Litteraturstudie Dokumentanalyse Intervju Litteraturstudie For å få god teoretisk bakgrunn i forkant av studien, gjennomførte jeg en grundig litteraturstudie med fokus på de to fagområdene informasjonsinfrastrukturer og prosjektledelse. Dette var hensiktsmessig først og fremst for å få en teoretisk oversikt og for å kunne utarbeide en konkret problemstilling. Ved å ha et godt teoretisk grunnlag i forkant av en studie, stiller man ofte bedre forberedt både for planleggingsprosessen, men også underveis i gjennomføring av datainnsamling og i skriveprosessen. Med et slikt overblikk, er det enklere å se naturlige relasjoner mellom dataene man har samlet inn og de teoretiske påstandene og konklusjonene man har definert. I tillegg til dette var jeg avhengig av å ha gode teoretiske kunnskaper for å kunne utarbeide det forventede mønsteret i pattern matchingen. Dersom man har teoretiske mangler, tror jeg det vil være vanskelig å formulere konkrete påstander og utsagn, og er derfor på mange måter avgjørende for å kunne gjennomføre en vellykket pattern matching. Yin sier i sin bok om case studier at den voldsomme tilgjengeligheten på informasjon på internett kan gjøre det vanskelig å hente ut den litteraturen som passer best med studiens tema. Overfloden av informasjon kan gjøre at en mister oversikt og overser litteratur som ville gitt gode kunnskaper om det gitte fagområdet. For å sørge for at man finner relevant informasjon forslår han blant annet å benytte lokale biblioteker, nisjebiblioteker, slik som et informatikkbibliotek, eller en annen

46 34 KAPITTEL 3. METODE kilde som tilbyr mer begrenset informasjon (Yin 2014, s ). For å sørge for at informasjonen jeg benyttet meg av var så passende som mulig, brukte jeg blant annet pensum fra relevante fag undervist på Universitetet i Oslo. Ved å benytte litteratur fra fag jeg selv hadde gjennomført, hadde jeg den fordelen av at jeg allerede visste hvilke av disse studiene som var relevante. I tillegg til dette visste jeg at pensum fra universitetskurs er nøye utvalgt av foreleser, noe som gjorde meg trygg på at litteraturen viste til grundig gjennomførte studier. Veiledning om utvalg av relevant litteratur fra faget Ressursestimering, usikkerhetsvurdering, planlegging og budsjettering av IT-prosjekter (INF5520), er også blitt flittig benyttet for å gjøre en kritisk evaluering av kilder på nett Dokumentanalyse Ved gjennomføring av en case stude, mener Yin (2014, s. 107) at relevante dokumenter spiller en sentral rolle for datainnsamlingen. Dette fordi dataene fra en dokumentanalyse kan fylle ut der hvor det forekommer mangler ved andre datainnsamlingsteknikker. Likevel nevner han at enkelte er kritiske til måten forskere lener seg til informantenes dokumenter på, fordi forskere har en tendens til å gjøre den feilen å tolke dokumentene som rendyrket sannhet. Ut ifra dette bør man derfor vise forsiktighet og lese dem med et kritisk blikk, og ta hensyn til at dokumentene som regel er skrevet med en spesifikk hensikt og et annet publikum enn forskere (Yin 2014, s. 108). Dersom noe virker uklart eller motsigende sammenlignet med data hentet inn ved hjelp av andre datainnsamlingsteknikker, kan det være lurt å forhøre seg med informanten om tolkningen man har gjort er korrekt. Dette gjelder også dersom skriftlige kilder har rom for tolkning, noe som gjør at misforståelser kan oppstå. Før gjennomføringen av hvert intervju, forespurte jeg alltid informanten om det var mulig å få tilsendt prosjektdokumentasjon tilhørende det gitte prosjektet. På denne måten kunne jeg sørge for å være så forberedt som mulig til intervjuet, samtidig som at denne informasjonen kunne være nyttig i underveis i skriveprosessen. Dersom jeg manglet noe informasjon fra det gjennomførte intervjuet, hadde jeg mulighet til å hente ut data fra prosjektdokumentasjonen (Yin 2014, s. 107). Man skal selvsagt være kritisk til dette, men etter å ha gjennomført intervjuer syntes jeg at jeg hadde fått en såpass god oppfatting av hvordan hvert prosjekt var styrt, at jeg med stor sikkerhet kunne avgjøre hvilken informasjon fra dokumentene jeg kunne stole på Intervju Intervju som datainnsamlingsteknikk kan benyttes i mange ulike kontekster innen kvalitativ forskning og er en av de viktigste kildene til informasjon i case studier. Dette fordi de kan gi mye og mer variert informasjon sammenlignet med for eksempel spørreundersøkelser (Yin 2014, s. 110). Intervjuer finnes i ulike former, hvor ustrukturerte og semistrukturerte intervjuer er de vanligste innen kvalitativ

47 3.3. TEKNIKK 35 forskning. Strukturerte intervjuer blir sjeldent brukt i case studier, da denne formen for intervju i de fleste tilfeller produserer kvantitative data (DiCicco-Bloom og Crabtree 2006, s. 314). På mange måter kan man si at et intervju aldri er helt ustrukturert, fordi man alltid vil ha en agenda for hvilken informasjon man ønsker å få fra informanten. Likevel kan man sammenligne et ustrukturert intervju med en veiledet samtale, ved at forskeren har en grov plan over hva han eller hun ønsker å få ut av samtalen, uten å ha planlagt noen spørsmål eller retning på hvor samtalen skal bevege seg. Ustrukturerte intervjuer er mye brukt innen etnografi, da denne teknikken gjerne kan kombineres med deltakende observasjon (DiCicco-Bloom og Crabtree 2006, s. 315). Semistrukturerte intervjuer er bygget opp av noen ferdigdefinerte og åpne spørsmål som sikrer at forskeren får hentet inn all nødvendig informasjon. Ettersom kun noen av spørsmålene er definert i forkant, legger man til rette for fleksibilitet underveis som gjør at intervjuet kan ta uventede vendinger. De uventede vendingene kan være med på å gi ny og spennende informasjon som kan gi forskeren en bedre forståelse av fenomenet som undersøkes. Dette gjør semistrukturerte intervjuer svært sentrale innen kvalitativ forskning, fordi de er fleksible og åpner opp for at intervjuprosessen kan endres underveis for å kunne hente inn mer variert informasjon (DiCicco-Bloom og Crabtree 2006, s. 315). Semistrukturerte intervjuer kan gjennomføres både individuelt og i gruppe. Dersom man gjennomfører et individuelt intervju kan man hente inn grundig informasjon slik som personlige erfaringer og oppfatninger, mens ved et gruppeintervju er det mer naturlig å hente inn et bredere spekter av erfaringer fremfor å dykke inn i hvert enkelt individs personlige meninger. Hvor mange intervjuer som gjennomføres med hver enkelt informant eller fokusgruppe, avhenger av hvor dyptgående informasjon man ønsker. Dersom man kun ønsker å «skrape i overflaten» på en rekke informanter, kan det være nok med ett intervju per informant. Om man ønsker mer dyptgående informasjon fra et lite knippe informanter, kan det være nyttig å gjennomføre flere intervjuer per informant for å sørge for at man får hentet ut så mye data som mulig. Crang og Cook (2007, s ) beskriver et kjennetegn for å avgjøre om man har hentet ut nok informasjon som de kaller teoretisk metning(engelsk: theoretical saturation). Teoretisk metning oppstår når informasjon i datainnsamlingsprosessen blir gjentakende og på denne måten vet man at man har hentet ut all tilgjengelig informasjon fra informanten. Når teoretisk metning oppstår må forskeren så avgjøre om han har tilstrekkelig med data eller om det bør gjennomføres flere intervjuer med en annen vinkling eller annen informant. For å samle inn data til denne studien benyttet jeg semistrukturerte intervjuer som var utarbeidet med bakgrunn i det forventede mønsteret. Ved å ha spørsmål som dekket påstandene og utsagnene i det forventede mønsteret, sørget jeg for å få svar på det jeg ønsket for å kunne gjennomføre pattern matchingen samtidig som at spørsmålene var såpass åpne at det tilrettela for fleksibilitet. Jeg gjennomførte individuelle intervjuer med kun ett intervju per informant hvor hver av dem varte i

48 36 KAPITTEL 3. METODE omtrent en time. Dette gav tilstrekkelig med informasjon for å fylle ut tabellen for pattern matchingen, noe som gjorde det overflødig å gjennomføre flere intervjuer. Crang og Cook (2007) nevner i sin bok Doing Ethnographies at det kan være vanskelig å holde seg konsentrert gjennom et helt intervju, og at det derfor kan være nyttig å gjøre lydopptak. Av den grunn gjorde jeg lydopptak av alle intervjuene jeg gjennomførte, slik at jeg kunne gå tilbake og sørge for at jeg ikke hadde mistet noe informasjon, samt at jeg kunne hente ut ordrette sitater. 3.4 Analyse I etterkant av de gjennomførte intervjuene har jeg skrevet lange sammendrag fra hver case med utfyllende informasjon om alle feltene fra det forventede mønsteret. Ved å ha slike sammendrag har jeg kunnet gå tilbake og hente ut informasjon, fremfor å måtte høre på lydopptakene. Jeg oppfattet det som mye mer lønnsomt å ha gode sammendrag fra datainnsamlingen fremfor for eksempel transkripsjoner. Transkripsjoner er også nyttig i den grad at man kan hente ut ordrette sitater, men de gir ikke en enkel beskrivelse av hvordan en case forholder seg til et bestemt tema. Ettersom jeg ikke transkriberte intervjuene, hørte jeg derimot på lydopptakene der hvor jeg var ute etter et godt sitat. I utgangspunktet visste jeg da hvilket sitat jeg var ute etter, slik at jeg ikke trengte å bruke masse tid på å høre gjennom alle opptakene. Sammendragene er lagt ved som vedlegg. Sammendragene ble godt brukt gjennom hele analysen og dannet grunnlaget for funnene. Ettersom Yin ikke sier noe om hvordan man metodisk bør gå frem i en pattern matching, og spesielt ikke ved bruk av konkurrerende mønstre, ble jeg nødt til å utarbeide min egen fremgangsmåte. For hvert tema i det forventede mønsteret tok jeg for meg hver enkelt case i lys av påstanden tilknyttet prosjektledelse, og deretter det samme for informasjonsinfrastrukturer. På denne måten kunne jeg utarbeide en detaljert beskrivelse av hvordan hver enkelt case forholdt seg til den gjeldende påstanden i det forventede mønsteret. Dette oppsummerte jeg så i en tabell hvor jeg graderte fra 1 til 3 for hvor godt påstanden i det forventede mønsteret stemte overens med den enkelte casen. 1 viser at informanten er uenig i påstanden, 2 er hverken eller og 3 er at informanten er enig. Denne tabellen er presentert mot slutten av hvert delkapittel av analysen under resultat. For å kunne trekke konkrete funn ut fra analysen, benyttet jeg hver av de oppsummerende tabellene som ble presentert under sitt tilhørende kapittel for å avgjøre hvorvidt casene var enige i påstanden fra det forventede mønsteret. Dersom majoriteten av casene enten var svært enige eller uenige, var det åpenbart at funnet ville illustrere enten enig eller uenig i påstanden. Om resultatene derimot var sprikende, måtte jeg gjøre avveininger for i hvor stor grad det var enighet eller uenighet. I tilfellene der hvor dette har oppstått, har jeg skrevet en grundig beskrivelse av hvordan jeg kom frem til det gitte funnet og hva som er bakgrunnen for beslutningen. Dersom jeg har besluttet at casene er enige i påstanden, er dette illustrert som JA, ved uenighet er dette illustrert som NEI. Dette er så oppsummert i en tabell mot

49 3.4. ANALYSE 37 slutten av funn-kapittelet Unntak Underveis i analysen dukket det opp tilfeller som enten ikke passet direkte sammen med det forventede mønsteret eller caser som ikke kunnes tas med i regningen for utarbeidelse av funnene. Disse tilfellene er presentert under, med grundig beskrivelse av hendelsen og hvordan dette er blitt løst. Organisering I kapittel om organisering av prosjekter, er påstanden om desentralisert beslutning er dataene noe sprikende og ikke minst vagere enn ved sentralisert beslutning. Årsaken til dette er at det er tatt mye hensyn til sluttbrukere og interessenter i de fleste av prosjektene, men at selve beslutningen om det avsluttende resultatet er tatt sentralt. Det er kun i Prosjekt C hvor man ser at de lokale enhetene faktisk har en total beslutningsmakt for det avsluttende resultatet av prosjektet. For å kunne si noe om evnen til muligheten for lokal beslutningsevne i hver av casene, har jeg valgt å gradere resultatene med hensyn på hvor stor innvirkning de ulike brukergruppene hadde på det avsluttende resultatet, til tross for at de ikke satt på den avsluttende beslutningen. Dette gjør at man får en illusjon av hvor stor påvirkning sluttbrukerne hadde for utformingen av prosjektresultatet. Et eksempel på dette er Prosjekt B hvor brukernes meninger og behov stod sentralt for å kunne utarbeide et vellykket journalsystem. Brukerne hadde derfor stor innvirkning på resultatet, men hadde ikke total beslutningsmakt og fikk derfor tildelt verdien 2 i oppsummeringen. I det prosjektet som har fått tildelt verdien 1, har ikke deltakerne hatt noen innvirkning på det avsluttende resultatet, mens i det prosjektet som har fått tildelt verdien 3 har brukerne hatt stor beslutningsmakt og derfor stor innvirkning på det avsluttende resultatet. Kultivering I kapittel om kultivering av IIer, var det vanskelig å si noe om hvordan organisasjonene har gått frem for å dyrke frem eller luke vekk vellykkete og mindre vellykkete deler av prosjektresultatene. Dette har gjorde det noe utfordrende å si noe om dette i de prosjektene som nylig har blitt gjennomført. Jeg prøvde likevel å gjøre noen tolkninger i henhold til dataene fra datainnsamlingen for å danne et grunnlag for diskusjonen. Dette betyr derfor at usikkerheten rundt dataene knyttet til kultivering er noe større enn dataene tilknyttet de andre delene av studien. På denne måten vil det ikke bli lagt like mye vekt på disse som de andre dataene jeg har hentet inn. Ettersom det finnes innebygde begrensninger ved den implementerte løsningen i Prosjekt F som gjør at de selv mister muligheten til å dyrke og luke bort de ulike delene av systemet, har jeg valgt å utelate dette casen fra tabell 6.4. Dette er antagelig en reell problemstilling som dukker opp i andre lignende prosjekter, men ettersom dette ikke var representativt for denne studien, valgte jeg å se bort i fra

50 38 KAPITTEL 3. METODE denne casen. Dersom casen skulle blitt med som en del av grunnlaget for å avgjøre hvordan oppfølging påvirker kultivering av en II, burde det vært flere lignende case med samme begrensinger som i Prosjekt F slik at man kunne sett på hvordan man kan gå frem når denne typen begrensinger oppstår. 3.5 Validitet For å skape validitet ved en case studie, beskriver Yin fire tester som går fra hvordan man skaper validitet ved planleggingen av studien til gjennomføring av analysen (Yin 1994, s ). Han starter med å beskrive hvordan forskeren kan skape validitet under planleggingsfasen ved å velge ut ulike kilder for bevis, og da i dette tilfellet, flere ulike caser. På denne måten vil man derfor ha et bredere grunnlag for å kunne generalisere, fordi man har mest sannsynlig har flere tilfeller som kan vise til de samme dataene (Yin 1994, s ). Ved å velge ut seks ganske ulike caser som alle går under kravene om et stort komplekst prosjekt, mener jeg at jeg i forkant at analysen la til rette for et godt grunnlag for å kunne generalisere. Dette tatt i betraktning at dette kun er en masteroppgave, slik at det finnes begrenset med både tid og plass i den avsluttende rapporten. Ettersom intervjuene var grundige, mener jeg derfor at de seks casene var et bredt nok utvalg av ulike kilder. For validitet ved analysen av data, beskriver Yin det han omtaler som intern validitet. Det kan være vanskelig å oppnå full intern validitet, fordi det omfatter at man tar høyde for alle mulige utfall og årsaker til hendelser ved utarbeidelsen av funnene fra studien. Til tross for dette, foreslår Yin bruk av pattern matching og grundige beskrivelser av hvordan man har gått frem i analysen, som måter å gå frem på for å skape så høy intern validitet som mulig (Yin 1994, s ). Dette mener jeg at jeg har gjort i denne studien, ved å skrive grundige beskrivelser av både hvordan jeg valgte ut studiens caser og hvordan jeg gikk frem gjennom analysen. I tillegg mener jeg at bakgrunnen for alle valgene som ble tatt i analysen er detaljert beskrevet, slik at leseren har mulighet til å følge alle stegene som er blitt gjort. Ekstern validitet beskriver Yin at skapes der hvor man etablerer et domene for hvor studien kan generaliseres (Yin 1994, s. 33). Dette tolker jeg som hvilket fagfelt studien hører innenfor og i hvor stor grad man kan generalisere i forhold til tidligere studier. Slik som beskrevet i litteraturkapittelet, hører denne studien inn under både prosjektledelses- og II-litteraturen. Studiens problemstilling tar høyde for dette, og på denne måten har jeg derfor kunnet trekke linjer til begge fagfeltene for å se i hvor stor grad det er samsvar mellom mine caser og tidligere forskning. Ettersom studien hadde som hensikt i å finne ut om det fantes deler av II-litteraturen som kunne supplere til prosjektledelseslitteraturen, gav dette rom for at det potensielt ikke var samsvar mellom funn og II-litteratur. Dette betyr derfor ikke at det er noen lavere ekstern validitet, fordi det da i stedet vil være samsvar med prosjektledelseslitteraturen.

51 3.5. VALIDITET 39 Som den fjerde testen for å evaluere validiteten på, beskriver Yin pålitelighet. Dette handler om at andre forskere skal kunne følge min fremgangsmåte og komme frem til de samme resultatene (Yin 1994, s. 36). Ettersom jeg selv mener at jeg har grundig beskrevet hvordan jeg har gått frem gjennom hele prosessen, mener jeg at andre forskere har mulighet til å følge fremgangsmåten min og komme frem til de samme resultatene. Likevel skal det legges ved at til tross for at noen følger fremgangsmåten, er det ikke sikkert de sier seg enig i hvordan verdiene jeg har gitt de ulike casene under pattern matchingen og derfor det avsluttende resultatet. Men dette mener jeg ikke har noe med muligheten til å kunne gjenskape funnene på, men derimot hvorvidt de er enige i hvordan jeg har forstått og vektlagt de ulike informantenes meninger og oppfatninger. På bakgrunn av dette mener jeg at validiteten av denne studien er høy, men som i de fleste andre studier tror jeg nok det finnes rom for forbedring som kan høyne validiteten ytterligere.

52 40 KAPITTEL 3. METODE

53 Kapittel 4 Etikk I en studie hvor mennesker involveres, vil det alltid finnes etiske aspekter man som forsker må ta hensyn til. Hvor mye informasjon personlig som hentes ut fra informanten varierer fra studie til studie, men det er likevel viktig å være oppmerksom på dette for å kunne beskytte informantens identitet i størst mulig grad. I dette kapittelet vil jeg derfor beskrive hvordan jeg har gått frem for å skjerme mine informanter og etiske problemstillinger jeg har måttet ta hensyn til underveis i studien. Til tross for at denne studien i all hovedsak ikke hadde som hensikt å kartlegge sensitiv informasjon slik som politisk ståsted eller etnisitet, finnes det likevel noen etiske aspekter ved studien som gjør at den holder på sensitiv informasjon. Jeg vil derfor beskrive disse for å kunne informere leseren om at jeg har hatt et bevisst forhold til disse gjennom hele prosessen. 4.1 Personvernombudet I forkant av datainnsamlingen ble studien meldt inn til Personvernombudet for forskning. Bakgrunnen for dette var at Personvernombudet kunne vise at studien jeg skulle gjennomføre ville hente inn informasjon om mennesker som kunne oppfattes som identifiserende, noe gjør studien pliktig til å meldes inn. Tilbakemelding og klarsignal om gjennomføring av studien mottok jeg 19. februar Kopi av dette finnes som vedlegg i rapporten. 4.2 Lydopptak Som nevnt i metode-kapittelet ble det gjort lydopptak av alle intervjuene. Lydopptakene ble lagret lokalt på min maskin, men på grunn av automatisk synkronisering mot skytjeneste gjorde dette at filene også var tilgjengelig via nettleser. Til tross for at disse var beskyttet i en personlig profil, er det likevel et usikkerhetsmoment at dataene også er lagret på nett. Sett fra en annen vinkel sørger dette for en økt sik- 41

54 42 KAPITTEL 4. ETIKK kerhet for meg som forsker, ved at jeg alltid har en ekstra kopi om noe skulle skje med min private maskin. I tillegg til usikkerhet omkring oppbevaring av filene, vil lydopptak også kunne identifisere informanter på bakgrunn av stemme. Navn vil også kunne bli nevnt i lydopptak som dette. 4.3 Oversikt over informanter og bedrifter For å holde en strukturert oversikt over alle informantene og deres tilhørende prosjekter og bedrifter, ble det opprettet et regneark hvor dette ble notert. På denne måten kunne jeg sørge for at all identifiserende informasjon om informanter ble lagret kun ett sted. Regnearket inneholdt også informantenes respektive pseudonymer, som en måte for meg å holde oversikt over hvilke informanter og bedrifter som var blitt tildelt hvilke navn. I en studie som dette med seks caser, en informant og et prosjekt per case samt minimum en organisasjon per case, var det viktig å opprette et system for at pseudonymene ikke skulle forveksles. Denne filen ble på samme måte som lydfilene synkronisert mot en skytjeneste. 4.4 Anonymisering Alle informantene er blitt tildelt tilfeldige navn og vil bli omtalt som han uavhengig av kjønn. Dette gjøres for å forhindre at informanter blir identifisert på bakgrunn av kjønn og for at hvilket kjønn informanten har ikke skal stjele fokus fra casene. Organisasjoner, samarbeidspartnere og eventuelle systemer har fått tildelt navn hentet fra det greske alfabetet for å kunne referer til disse på en enkel og ryddig måte.

55 Kapittel 5 Case Dette kapittelet beskrives de ulike casene som ble benyttet som datagrunnlag for denne studien, og hver case består av en informant og ett prosjekt. På denne måten danner prosjektet basen for casen, mens informanten skaper vinklingen mot prosjektledelse. Beskrivelsene tar kort for seg informanten og hans bakgrunn samt bedriften prosjektet ble gjennomført i. I tillegg til dette gis det en grundig beskrivelse av prosjektets hensikt, omfang og hvorfor nettopp disse går inn under kategorien store komplekse prosjekter. Lengre sammendrag fra hver av intervjuene samt beskrivelse av prosjektene og informantene finnes som vedlegg. 5.1 Prosjekt A Organisasjon: Kappa Informant: Jonas Beskrivelse av casen: Jonas er en erfaren prosjektleder etter mange år i IT-bransjen. Prosjekt A er et av de mest omfattende prosjektene han har ledet, noe grunnet at prosjektet ikke var et rent teknisk prosjekt. Prosjektet handlet om å forvalte menneskers kunnskap til de rette områdene i bedriften, Kappa. Prosjektets hensikt var å flytte to tredjedeler av Kappa til et indisk selskap kalt Alfa, som en måte for bedriften å senke kostnadene på for å kunne overleve på lang sikt. Kappa er en privat bedrift bestående av omtrent 450 ansatte som leverer datakommunikasjon til bedrifter både i offentlig og privat sektor. Bakgrunnen for prosjektet lå i at bedriften ønsket å kunne øke kvaliteten på de tjenestene de leverer, noe de ikke har hatt nok ressurser eller kompetanse til å gjøre i Norge. De ansatte som tidligere hadde ansvar for disse tjenestene før prosjektet, ble reansatt i Alfa, men ble værende i Norge og fortsatte å gjennomføre de samme arbeidsoppgavene som tidligere. Som en tilrettelegging for de ansatte som ble flyttet, fikk de mulighet 43

56 44 KAPITTEL 5. CASE til å slutte på dagen da de mottok kontrakt for reansettelse, dersom de ikke ønsket å jobbe for Alfa. Kompleksiteten til prosjektet ligger hovedsakelig i håndtering av en enorm mengde menneskelige aktører samtidig som at man må ha en detaljert oversikt over hvordan disse interagerer med en rekke systemer. Ved å så skulle overføre flere tjenester og menneskene som har ansvar for dem, står man overfor en oppgave bestående av svært mange elementer som alle på en eller annen måte avhenger av hverandre. Jonas var en av fire prosjektledere. Prosjektet var delt inn i tre deler, hvor Jonas var leder for en av disse og den fjerde prosjektlederen hadde ansvar for prosjektet i sin helhet. Planleggingen av prosjektet startet i begynnelsen av 2015, men Jonas ble satt inn som prosjektleder under sluttforhandlingene og spesifiseringene av avtalen med det indiske selskapet. Dette betyr at han ikke tok del i utvelgelsen av leverandør, men hadde ansvar for transisjonsfasen, som gikk fra da kontrakten med Alfa var skrevet til den fullstendige overføringen av ansatte skulle være ferdig. 5.2 Prosjekt B Organisasjon: Lambda Informant: Mathias Beskrivelse av casen: Mathias er en erfaren prosjektleder med bakgrunn fra både privat og offentlig sektor, og har gode kjennskaper til gjennomføring av store komplekse prosjekter. Han har også gjennomført flere sertifiseringer innen prosjektledelse som han benytter aktivt i prosjektene sine. Prosjekt B hadde som mål å innføre et felles journalsystem for alle sykehus innenfor en gitt region. Hensikten med dette var å komme nærmere planen om at enhver norsk innbygger har en journal uavhengig av hvilken institusjon han eller hun har vært pasient ved. Slik det har vært før gjennomføringen av Prosjekt B, har en pasient hatt en journal for hver avdeling eller institusjon som han eller hun har vært pasient ved. På denne måten kunne man risikere å ha flere journaler selv innad i ett sykehus. Ved å ha en felles journal vil helsepersonell kunne få et mer helhetlig bilde av pasienten og derfor kunne utføre bedre behandling. Det som gjør Prosjekt B så komplekst er hvordan prosjektlederne var nødt til å ta hensyn til alle de ulike brukergruppenes behov samtidig som at det skulle utvikles et felles system som kunne kommunisere med en rekke ulike leverandørers systemer. Dette gjorde derfor prosjektet til både et teknisk og sosioteknisk prosjekt bestående av mange og ulike aktører. Prosjektet ble gjennomført av organisasjonen, Lambda som er ledende i Norden på innkjøp, leveranse og drift av tjenester innen helsesektoren. Lambda har omtrent 1300 ansatte og har fokus på å levere fremtidsrettede og effektive løsninger som tilrettelegger for god pasientbehandling.

57 5.3. PROSJEKT C 45 Prosjekt B startet våren 2012 og ble avsluttet høsten 2014 og Mathias er en av to hovedprosjektledere i prosjektet. 5.3 Prosjekt C Organisasjon: Beta Informant: Andreas Beskrivelse av casen: Andreas har jobbet mange år i organisasjonen, Beta, som prosjektet ble gjennomført i, men dette er det første prosjektet han har ledet. Han har vært med på å bygge opp gruppen som jobber med førstelinje support i organisasjonen i dag og har nå hatt ansvar for prosjektet som skulle reorganisere strukturen i førstelinjen for å gi økt kvalitet på brukerstøtte ved hjelp av bedre samarbeid på tvers av grupper og seksjoner. Slik Beta er organisert i dag, finnes det markante skiller mellom første-, andreog tredjelinjesupport, noe som gir lite flyt og fleksibilitet på tvers av linjene. Prosjektets hensikt var derfor å gjøre disse skillene mindre synlige ved å innføre et driftssenter. Driftssenterets oppgave er å tilrettelegge for læring og samarbeid på tvers i organisasjonen, for å sørge for at brukeres henvendelser blir fulgt av den samme gruppen mennesker fra start til slutt. Som forarbeid til prosjektet ble det sett på andre eksisterende og vellykkede driftssentre i andre organisasjoner, slik som Hydro og NRK. Det var i tillegg ønskelig å tilrettelegge for bedre overføring av tjenester, slik at det frigjøres ressurser i driftsavdelingene ved at den operative driften overføres til driftssenteret. Ettersom prosjektet involverte store deler av organisasjonen samt alle systemene hver av gruppene og seksjonene benytter, kan det kategoriseres som et stort og komplekst prosjekt. Dette bunner i alle de ulike aktørene, både menneskelige og tekniske, som prosjektlederen har måttet ta hensyn til for å ende opp med en enhetlig løsning tilpasset organisasjonen som en helhet. Prosjektet hadde i alt fire prosjektledere, hvor Andreas er en av disse og er ansvarlig for prosjektet i sin helhet. For å skape konsistens i prosjektet er det delt opp i tre underprosjekter og Andreas oppgave har derfor i stor grad vært å koordinere disse. Underprosjektene omfatter etablering av driftssenterlokale, opprettelse og utarbeidelse av hjemmevaktordning, gjøre endringer i saksbehandlingssystem som understøtter driftssenterets behov og føringer, og utarbeidelse av avtaleverk for tjenesteoverføring.

58 46 KAPITTEL 5. CASE 5.4 Prosjekt D Organisasjon: Omega Informant: Kristian Beskrivelse av casen: Kristian er både teknisk prosjektleder og virksomhetsarkitekt, og har derfor bred og lang erfaring fra IT-bransjen. Han startet sin karriere innen programvareutvikling og har gradvis beveget seg over i roller innen drift og prosjektledelse. Dette gjør at han har personlige kjennskaper og erfaringer om flere av rollene som inngår i et prosjekt, noe som er fordelaktig i en prosjektlederrolle. Kristian har deltatt i flere store prosjekter, men Prosjekt D er hittil det største og mest komplekse. Prosjektet handlet om å omstrukturere og standardisere prosesser som tar for seg meldings- og informasjonsutveksling mellom flere aktører. Dette ble gjort ved hjelp av innføring av et nytt system kalt Gamma. Dette har tidligere foregått over papir, men gjennom Gamma har systemet delvis blitt digitalisert og skal over tid fullt og helt ta over for den papirbaserte løsningen. Kristian beskriver Prosjekt D som et spesielt komplekst prosjekt, på grunn av dets mange aktører og deres tilknytninger til hverandre. Prosjektet var avgrenset, men var en del av en større omstrukturering og effektivisering. På grunn av den høye kompleksiteten kan det derfor være vanskelig å skille prosjektet fra den overordnede omstruktureringen. Dette gir en klar indikator på at Prosjekt D faller innenfor betegnelsen store komplekse prosjekter, fordi det er vanskelig å trekke linjer som avgrenser omfanget av den totale informasjonsinfrastrukturen. Organisasjonen som hadde ansvar for gjennomføring av prosjektet, Omega, er en statlig organisasjon med omtrent 50 ansatte. De ansatte har bakgrunn fra ulike fagfelt som gir stor tverrfaglighet, noe som er svært nyttig i prosjekter dette. I tillegg til dette jobbet de tett sammen med andre aktører som var med på å påvirke den totale omstruktureringen. 5.5 Prosjekt E Organisasjon: Delta Informant: Markus Beskrivelse av casen: Markus har lang erfaring innen ledelse av IT-prosjekter og har jobbet i organisasjonen Delta i flere år. Han startet sin karriere innen konsulentvirksomhet, beveget seg over i en stilling som CEO og er nå seksjonssjef og prosjektleder i Delta. Han har i all hovedsak ledet rene softwareprosjekter i både store og små bedrifter, og de skiller seg tydelig fra Prosjekt E som er det mest omfattende prosjektet han har ledet. Dette fordi Prosjekt E ikke bare var et rent IT-teknisk prosjekt, da tok også for seg sosiotekniske aktører som gjør det stort og komplekst.

59 5.6. PROSJEKT F 47 Delta er en IT-organisasjon med omtrent 200 ansatte fordelt på tre avdelinger som igjen er delt inn i ni seksjoner. Den fungerer som IT-avdeling for en stor statlig organisasjon, Theta, som igjen består av omtrent 6000 ansatte. Tidligere fantes det ikke noen vedtatt og helhetlig integrasjonsarkitektur i Theta, prosjektet hadde derfor som mål å utarbeide en felles integrasjonsarkitektur for hele organisasjonen. Det fantes opprinnelig en integrasjonsarkitektur utviklet og benyttet av en seksjon i Delta. Alle har hatt mulighet til å benytte seg av denne, men den var hverken helhetlig gjennomført eller vedtatt av IT-organisasjonen. Den fungerte derfor mer som et tilbud i stedet for å være en standard. På grunn av manglende føringer for integrasjon av systemer, har det vært vanlig å benytte leverandørens retningslinjer og forslag. Ved å innføre en felles integrasjonsarkitektur vil man skape mer struktur og oversikt over de systemene som finnes og hvordan de bør integreres med hverandre. Det har vært en svakhet for Theta å ikke ha standardiserte og definerte måter å integrere systemer på, og det ble derfor pålagt fra flere holdt om å gjennomføre prosjektet. Markus mener utarbeidelse og innføring av en integrasjonsarkitektur er et godt sted å starte for kunne skape mer orden Thetas tekniske arkitektur i sin helhet. Prosjekt E var i utgangspunktet ikke et stort prosjekt da det var bemannet med totalt seks årsverk, men fordi det påvirket mange av de ansatte i Theta i tillegg til mange tekniske komponenter, ble det et komplekst prosjekt. 5.6 Prosjekt F Organisasjon: Epsilon Informant: Tobias Beskrivelse av casen: Tobias har vært ansatt i organisasjonen Epsilon i omtrent 30 år og har hatt IT-rettede stillinger gjennom hele sin karriere. Han har hatt flere ulike roller gjennom alle disse årene og har blant annet vært driftskonsulent, driftssjef, gruppeleder, IT-sjef og nå nestkommanderende for IT i Epsilon og rapporterer jevnlig til organisasjonens CEO. Til da var dette det mest omfattende prosjektet han hadde deltatt i, men er nå prosjektleder i et prosjekt han mener er enda mer komplekst og omfattende. Epsilon er en stor organisasjon med omtrent 2000 ansatte og over medlemmer fordelt over hele landet. Organisasjonen har gjennomgått flere oppkjøp og fusjoner som til slutt førte til en veldig brokete og oppdelt infrastruktur på telefoni. Dette startet som en av faktorene som ble pågangsdrivere for gjennomføring av prosjektet. Med mange ulike softwareløsninger ble det etter hvert vanskelig å håndtere dem rent driftsmessig samtidig som en del av utstyret de hadde, hadde begynt å gå ut på dato og derfor burde byttes. En annen faktor som med på å påvirke gjennomføringen av prosjektet, var at Epsilon tidligere hadde innført Microsofts kommunikasjonssystem, Lync som i dag

60 48 KAPITTEL 5. CASE heter Skype for Business. De hadde tidligere innført Lync med noen få funksjoner slik som chat og skjermdeling, og de hadde derfor et ønske om å fortsette å bruke denne tjenesten ved å utvide med mer funksjonalitet. Funksjonaliteten de ønsket var lyd og video slik at de kunne overføre hele telefonidelen i organisasjonen til Lync. Etter grundige analyser ble det derfor avgjort at organisasjonen ble nødt til å fornye seg og innføre en ny og helhetlig telefoniløsning og Prosjekt F ble derfor satt i gang. Prosjektet ble delt inn i fire deler, hvor en av disse var prosjektet i sin helhet. De tre andre delene tok for seg det organisatoriske knyttet til omstruktureringen, den rene tekniske endringen og innføringen av Lync og selve leveransen av tjenesten fra tjenesteleverandøren, Zeta. Dette betydde også at de hadde fire prosjektledere som alle skulle samarbeide og koordinere hver av delprosjektenes aktiviteter. Mye av bakgrunnen for kompleksiteten i prosjektet, var fordi det angikk alle brukerne i hele Epsilon. Det var et stort inngrep å ta ut kjent teknologi slik som telefoni er og mange ble derfor nødt til å lære seg å bruke et helt nytt system. Det skaper til slutt et veldig komplekst bilde når et nytt og moderne system skal fungere med like stor selvfølgelighet som når man løfter av røret som på en vanlig telefon.

61 Kapittel 6 Funn I dette kapittelet vil jeg presentere dataene fra datainnsamlingen og analysere dem i lys av teoriene om spenninger, som ble beskrevet i litteraturkapittelet. Årsaken til at jeg har valgt nettopp denne teorien, er fordi den fremstår som en veldig sentral «kraft» og er en av de viktigste egenskapene som kjennetegner store komplekse prosjekter. Dette vil derfor være en logisk og naturlig vinkling å strukturere kapittelet på, samt at det kan være med på å gi en dypere forståelse av funnene som er blitt gjort. Først vil jeg starte med å presentere noen generelle funn som vil danne basen for store deler av analysen. Deretter vil resten av kapittelet være delt inn i kategoriene prinsipper for koordinering, plan, organisering og oppfølging som også danner strukturen for pattern matchingen. Mot slutten av hver kategori vil jeg presentere en detaljert oversikt som viser hvordan hver av informantene stiller seg til påstandene som ble presentert mot slutten av litteraturkapittelet. Avslutningsvis vil jeg så presentere en sammenfattet og helhetlig tabell som illustrerer funnene fra analysen. Ved bruk av sitater i teksten har jeg fjernet «fyllord» slik som «jo», «da», «ehm», og så videre for å gjøre sitatene mer lesbare. Dette er blitt gjort på en slik måte at det ikke skal påvirke meningsinnholdet, men gi leseren bedre flyt og forståelse for det som ble sagt. I sitater der «[... ]» forekommer, illustreres det at informanten har sagt noe mellom to setninger som ikke er av relevans for emnet som omtales. 6.1 Generelt Etter gjennomføring av datainnsamlingen, oppdaget jeg et gjennomgående trekk i de undersøkte casene: alle prosjektene ble gjennomført med et hovedfokus på høy kvalitet. De fleste informantene mente at det ville være bortkastet å gjennomføre prosjektene med fokus på tid eller penger. Tid og penger var selvfølgelig viktige faktorer for å avgjøre omfanget av prosjektene, men det skulle aldri gå på bekostning av kvaliteten til det avsluttende resultatet. Tobias fra Prosjekt F tror heller at de hadde avsluttet prosjektet dersom de ikke kunne overholdt det ønskede nivået 49

62 50 KAPITTEL 6. FUNN av kvalitet. Jeg synes fokuset på kvalitet i prosjektene er viktig å presisere på grunn av dets innvirkning på hvordan spenninger oppstår mellom interessenter og prosjektleder. Målet om å alltid skulle opprettholde høy kvalitet, gjør at prosjektlederen må bruke mye tid på å gjøre interessentene til lags samtidig som at han sørger for at det gjennomføres et prosjekt som er i henhold til det opprinnelige mandatet. Ledelse av store komplekse prosjekter med et ønske om høy kvalitet, er derfor en krevende jobb hvor prosjektlederen kontinuerlig trekkes mellom de ulike partene i prosjektet. 6.2 Prinsipper for koordinering Standardiserte prosesser I fire av de undersøkte casene ble det benyttet en form for standardisert prosjektledelsesmetodikk. Metodikkene hadde en klar likhet ved at de alle stammet fra fossefallsmodellen og bygget på prosjektledelsesrammeverket PRINCE2. I tillegg til dette var det personlig viktig for informantene fra tre av disse casene å benytte et rammeverk som er bygget opp etter best practice. Dette bunner i at de opplever en trygghet ved å gjennomføre prosjekter på en måte hvor det er bevist at metodikken har fungert i flere tidligere tilfeller. Både Markus fra Prosjekt E og Tobias fra Prosjekt F mener det er veldig nyttig å benytte et standardisert prosjektledelsesrammeverk, slik at de slipper å være kreative når det kommer til fremgangsmåte i prosjektet. På denne måten kan de bruke mer tid på selve prosjektets innhold og legge til rette for et vellykket prosjektresultat. Jonas fra Prosjekt A fortalte at det var uvisst om det ble benyttet et kjent standardisert rammeverk, men at det ikke var umulig om organisasjonen selv hadde utarbeidet og standardisert sin egen metode. Han mener at det ikke er nødvendig å benytte et prosjektledelsesrammeverk som er best practice, da man ofte kan få like gode resultater om man selv har utviklet sin egen standardiserte metodikk. Om det er en dokumentert, kjent metodikk eller om personen som styrer prosjektet er strukturert og har sin måte å gjøre det på det tror jeg ikke utgjør noen forskjell. Det må ikke hete PRINCE2 eller en av de andre metodikkene, men man trenger struktur i prosjektet som har et mål, at man kan måle underveis og alle de små tingene som er i en metodikk - det er viktig - Jonas Prosjekt A Likevel påpekte han at de standardiserte metodikkene absolutt har noe for seg og at han ser stor nytte i å benytte dem. I Prosjekt D derimot, ble det ikke benyttet noen form for prosjektledelsesrammeverk. Årsaken til dette bunnet ut i at det opprinnelig ble startet som et program og ikke et prosjekt, noe som gjorde at det ikke ble tatt et aktivt valg om hvordan prosjektet skulle gjennomføres. Om man går prosjektet i sømmene og ser over hvordan det faktisk ble gjennomført, finnes en rekke likhetstrekk til smidig metodikk. Prosjektets oppbygning og fremgangsmåte

63 6.2. PRINSIPPER FOR KOORDINERING 51 ble basert på de deltakende prosjektledernes tidligere erfaringer, og prosjektlederen Kristian mener at det ikke er umulig at flere av teknikkene som ble brukt egentlig stammer fra standardiserte prosjektledelsesrammeverk. Prosjekt D skiller seg mye fra de andre prosjektene som ble styrt etter en plandreven struktur. Kristian mener at det ikke hadde vært mulig å opprettholde den ønskede kvaliteten dersom de hadde brukt en metodikk som baserer seg på fossefallsmodellen. Årsaken til det er at de var avhengige av å kunne jobbe inkrementelt ved å planlegge nøye for en avgrenset bit av prosjektet, utføre planene og deretter gjennomføre omfattende tester for å sørge for at det riktige nivået av sikkerhet ble overholdt. Til tross for at det i majoriteten av prosjektene ble benyttet et standardisert prosjektledelsesrammeverk, er alle informantene enige om at dette ikke er synonymt med et vellykket prosjektresultat. De mener det er avgjørende at prosjektlederen har evnen til å tilpasse rammeverket som benyttes til det enkelte prosjektet, slik at det utnytter både rammeverket og prosjektets potensiale til det fulle. Markus fra Prosjekt E mener at det er evnen til å kunne tilpasse et standardisert rammeverk som avgjør om det er en profesjonell og erfaren prosjektleder. Fra Markus påstand kan man derfor trekke linjer til Andreas fra Prosjekt C, som er noe mindre erfaren enn de andre informantene. Han synes at bruk av standardisert prosjektledelsesrammeverk på mange måter er betryggende ved at det gir en god støtte underveis i prosjektet, men samtidig oppfatter han det som tungvint og til dels litt for omstendelig i forhold til prosjektets omfang. I tilfeller som dette kan nok et standardisert rammeverk oppfattes som begrensende fremfor muliggjørende, og derfor lite fleksibelt for prosjektlederen. Ettersom de andre informantene har lengre og bredere erfaring, kan det tyde på at de bruker denne kunnskapen aktivt for å tilpasse rammeverkene. På denne måten fungerer rammeverket som et hjelpemiddel fremfor et hinder. Om det derimot benyttes et kjent standardisert prosjektledelsesrammeverk eller om organisasjonen selv har utarbeidet en egen metodikk, ser ikke ut til å ha noen betydning så lenge prosjektlederen har evnen til å gjenbruke tidligere prosjekterfaring. Som en rød tråd kan man derfor trekke frem at for å gjennomføre et vellykket prosjekt, er man avhengig av å kunne bruke tidligere erfaringer og gjøre tilpasninger underveis. Både Prosjekt A og D viser at man ikke trenger kjente, standardiserte rammeverk for å gjennomføre vellykkete store komplekse prosjekter, men at evnen til å bruke tidligere prosjekterfaringer er essensielt for å kunne håndtere kompleksiteten som finnes i denne typen prosjekter. Rammeverkene fungerer derfor heller som veiledende og ikke som en nødvendig faktor for å gjennomføre et vellykket prosjekt Tekniske standarder Ved gjennomføringen av Prosjekt B ble det innført en rekke tekniske standarder da det ble utarbeidet et nytt journalsystem. Dette var med på å påvirke brukernes bruksmønster, fordi de gikk fra å forholde seg til en rekke ulike journalsystemer opprinnelig tilhørende ulike apparater og den avdelingen de jobbet ved. På den-

64 52 KAPITTEL 6. FUNN ne måten hadde brukerne innarbeidet seg et bruksmønster for bruk av alle disse spesialsystemene. Ved innføringen av det nye journalsystemet var det utarbeidet en helhetlig standard som skulle dekke basalbehovene til hver av brukergruppene, slik at den på en enkel måte kunne ta over for alle de ulike journalsystemene. På denne måten kunne brukerne nå forholde seg til ett system i stedet for mange ulike. Likevel betyr dette at brukerne var nødt til å endre sine arbeidsrutiner for journalføring. I Prosjekt D ble det innført tekniske standarder på den måten at de gikk fra en papirbasert til en delvis digital løsning. Løsningen har som hensikt å bli helt og holdent digital over tid, men dette avhenger av de ulike brukergruppene tar den i bruk. Dette har gjort at både de ulike kunde- og brukergruppene har måttet endre sine bruksmønstre for å ta i bruk tjenesten. Dette har vært spesielt utfordrende for års tilkomne kunder, som kanskje har mindre kjennskap til digitale tjenester enn yngre kunder. Den samme prosessen ved at brukerne måtte endre sine bruksmønster, forekom også i Prosjekt F hvor de gikk fra å bruke tradisjonell telefon til Microsofts kommunikasjonssystem, Lync. Brukerne ble da nødt til å endre sine vaner for kommunikasjons totalt, ved at de måtte sette seg inn i et nytt teknisk system. Mange av brukerne hadde kjennskap til systemet fra før av, men likevel var det en del som oppfattet det som noe utfordrende. Likevel mener Tobias at innføringen av den tekniske standarden gikk veldig bra og at de aller fleste klarte godt å komme inn i nye bruksmønstre. Med utgangspunkt i de innførte tekniske standardene, var det kun Tobias fra Prosjekt F som mente at standardene kunne være med på å skape fremtidige begrensinger. Han tror innføring av denne typen standarder kan være med på å gjøre organisasjonen stiv og lite fleksibel, fordi man ofte binder seg til produsenter som gjør det vanskelig å videreutvikle og tilpasse løsninger utenfor deres satte rammer. Dette kan gjøre det vanskelig å opprettholde et konkurransefortrinn. Likevel påpekte han at det viktigste er å innføre standarder som er muliggjørende og som skaper verdi for dem det angår. Tobias tror likevel mer på å se løsninger fremfor å fokusere på begrensningene ved standardene, slik at de kan fokusere på å jobbe seg rundt og forbi potensielle problemer. Informantene fra Prosjekt B og D derimot, mener at standarden de har innført har såpass god brukertilpasning at den mest sannsynlig ikke vil dette fremtidige begrensninger. De andre informantene kunne ikke se noen åpenbare begrensinger ved de tekniske standardene slik de opptrer i dag. Ved innføring av standarder som dette, befinner alltid prosjektlederen seg i limbo mellom de ulike brukergruppene og organisasjonen som en helhet. Han trekkes til enhver tid mellom disse og det må gjøres avveininger om det er hensiktsmessig å tilpasse standarden til en enkelt brukergruppe eller om den bør tilpasses hele organisasjonen. I alle de undersøkte casene har prosjektlederne jobbet mye med å finne denne balansen, og det er her de har brukt mye av tiden sin. En utfordring ved at spenningene oppstår, er å sørge for at man ender opp med ønsket prosjektresultat samtidig som at sluttbrukerne blir fornøyde med løsningen. Det er et gjennomgående trekk i majoriteten av casene at det har blitt gjennomført mye bakgrunnsarbeid

65 6.3. PLAN 53 i forkant av prosjektene. Ved å gjøre dette har de sørget for at brukernes ønsker og forventninger har blitt en del av planene, slik at de kunne gjennomføre prosjekter som tok hensyn til brukerne allerede før de ble satt i gang. For å begrense så mange spenninger som mulig kunne Mathias fra Prosjekt B fortelle at de gjennomførte mange og dyptgående intervjuer med alle de ulike brukergruppene for å sørge for at de fikk en så tilpasset teknisk standard som mulig. Likevel påpekte han at det er vanskelig å skulle tilfredsstille alle, men at det var viktig å holde fokus på brukertilpasning allerede før utarbeidelsen av det nye systemet ble satt i gang. Som et gjennomgående trekk for de prosjektene hvor det ble innført tekniske standarder, kan det derfor tyde på at alle prosjektlederne har tatt høyde for brukertilpasning tidlig i prosjektet, for å få en så smidig og fleksibel standard som mulig. I prosjekt A, C og E ble det ikke innført noen tydelige tekniske standarder, derimot ble det innført standardiserte prosesser som har en mer direkte koordinerende rolle enn de tekniske. Noe av årsaken til dette er at prosjektene i all hovedsak omhandlet omstrukturering av bedriftenes organisatoriske oppbygning, noe som ikke nødvendigvis krever at man innfører tekniske standarder Resultat Funnene jeg har gjort i henhold til prinsipper for koordineringer er illustrert i tabellen under. I henhold til den første påstanden viser det at det spriker en del mellom empirien og litteraturen, ved at de fleste til helt eller delvis er enig i påstanden om at en standardisert prosjektmetodikk bidrar til et vellykket resultat, mens en informant er helt uenig i denne påstanden. I påstanden om at en teknisk standard har en indirekte koordinerende effekt kan man se at forekommer i tre av de undersøkte casene, mens i de tre andre ble det ikke innført noen tekniske standarder. Dette gjør at det også her er noe sprikende resultater, men at der det ble innført tekniske standarder hadde de en indirekte koordinerende effekt. A B C D E F Standardisert prosjektmetodikk gir vellykket resultat Tekniske standarder støtter koordinering indirekte Tabell 6.1: Prinsipper for koordinering oppsummert 6.3 Plan Prosjektplaner At et grundig planlagt prosjekt bidrar til et vellykket resultat, er noe alle informantene er enige i. Dette bunner i at alle de undersøkte prosjektene var svært grundig planlagt uavhengig av hvilken prosjektledelsesmetodikk de benyttet. I både Prosjekt B, C og E ble det også gjennomført et forprosjekt i forkant av hovedprosjektet

66 54 KAPITTEL 6. FUNN for å sørge å identifisere om det faktisk var hensiktsmessig å igangsette prosjektene og for å kartlegge hva de ønsket å oppnå. Dette gjorde derfor at de sørget for å igangsette prosjekter som ville skape verdi i omgivelsene de ble gjennomført. Andreas fra Prosjekt C kunne fortelle at de hadde begynt å tenke på å utarbeide en løsning for et driftssenter allerede ti år før prosjektet ble satt i gang og at de brukte omtrent ett år på å planlegge det. Som en del av planleggingen kikket de på andre driftssenterløsninger for å kunne hente ut ideer og benytte andres erfaringer i sin egen løsning. Ved å gjøre dette kunne de øke sjansen for en vellykket driftssenterløsning, fordi de kunne prøve å unngå å gjøre feil som andre hadde gjort eller sørge for å fokusere på deler som var ekstra verdiskapende for organisasjonen. I Prosjekt B som antageligvis er det største av de undersøkte prosjektene, ble det gjennomført et omfattende forprosjekt. Årsaken til dette ligger i den enorme kompleksiteten til prosjektet samt at det tidligere er blitt gjennomført flere lignende prosjekter, men med et mindre vellykket resultat. Dette gjorde det derfor ekstra viktig å sørge for at det ble tilrettelagt for et så vellykket prosjektresultat som overhodet mulig. For å sørge for at de kunne utarbeide et godt tilpasset journalsystem, ble det gjennomført grundige intervjuer med de ulike brukergruppene. På denne måten kunne de identifisere de basale behovene hver enkelt brukergruppe hadde og deretter bruke dette til å utarbeide en universell løsning. På bakgrunn av den grundige datainnsamling ble det lagt svært detaljerte planer, for å ende opp med et godt tilpasset og utviklet resultat. På grunn av prosjektets størrelse, var det delt inn i flere underprosjekter, som hver hadde sine planer. Dette betyr derfor at prosjektet hadde flere nivåer av planer som totalt var med på å danne en detaljert prosjektplan. I et prosjekt som dette finnes det åpenbart svært mange ulike aktører som hver og en har en mening om hvordan systemet best mulig bør være utformet. Dette viser tydelig prosjektlederens stilling ved at han til enhver tid må gjøre kompromisser og tilpasninger som gjør majoriteten av brukerne til lags samtidig som at det utarbeides et system som står til de opprinnelige kravene som ble satt i forkant av prosjektet. Ettersom Prosjekt D på mange måter kan ligne på Prosjekt B, ser man de samme trekkene gå igjen med spenningene som oppstår mellom aktørene og prosjektlederen. For å håndtere disse, uttalte Kristian følgende: Det som er veldig viktig oppi alt dette her er forventningsstyring. Det som er forskjellen på om man lykkes som prosjektleder eller ikke, er om man klarer å innfri forventningene. Man kan lage verdens beste system på mange måter, men hvis de ikke innfrir forventningene så er det game over. Så forventningsstyringen her er viktig og at man tar med seg viktige stakeholders - Kristian Prosjekt D Ved å forventningsjustere både kunden og prosjektdeltakerne, sørget de for at forventningene som var satt var realistiske for det gitte tidspunktet. På denne måten trengte ikke prosjektlederne å legge unødig mye press på prosjektdeltakerne samtidig som at det ble dannet en realistisk forventing om hvordan resultatet burde være.

67 6.3. PLAN 55 Ved å gjøre dette kunne de planlegge prosjektet i henhold til de forventningene som var satt. Til tross for at det ble benyttet en form for smidig prosjektledelsesmetodikk i Prosjekt D, kan man likevel si at det var et grundig planlagt prosjekt. De hadde et overordnet mål om hvordan løsningen avslutningsvis burde se ut, men utførte den grundige planleggingen inkrementelt gjennom prosjektprosessen. Ved å legge grundige planer på denne måten, kunne de enkelt følge opp hvert enkelt inkrement i prosjektet uten å måtte ta så mye hensyn til hva som skulle skje da sprinten var over. Som nevnt kunne de også overholde den ønskede kvaliteten, ved at de planla for en avgrenset periode av prosjektet, utførte planene og deretter gjennomførte grundige tester. På denne måten kunne de avgjøre om det de hittil hadde utarbeidet hadde det rette nivået av kvalitet og at funksjonaliteten fungerte slik den skulle, før de gikk videre i prosjektet. Markus fra Prosjekt E er også tilhenger av å planlegge prosjekter på denne måten, selv om det i dette prosjektet ble strengt planlagt i forkant. Likevel oppfattet han det som svært utfordrende å planlegge et så komplekst prosjekt som dette, fordi de var usikre på hva slags løsning de egentlig ville ende opp med. I tillegg til dette var det ikke blitt gjennomført noen lignende prosjekter i organisasjonen tidligere, slik at de ikke hadde mulighet til å hente frem noen tidligere erfaringer. Likevel ble prosjektet relativt grundig planlagt, men ikke med det samme detaljnivået som i prosjektene som ble presentert over. Noe av grunnen til dette var at prosjektet foregikk på tvers av flere deler av organisasjonen, slik at prosjektet i sin helhet ble planlagt av hovedprosjektlederen(markus). Planene for gjennomføring av de ulike arbeidspakkene ble lagt av de som utførte dem, slik at hovedprosjektlederen ikke hadde noe med disse å gjøre. Ved å gjøre det på denne måten var det noe ulikt detaljnivå på planene, men så lenge leveransene var ferdige til avtalt tid så ikke Markus noen problemer med å legge planer på denne måten. I motsetning til Prosjekt E var Prosjekt A et svært detaljert planlagt prosjekt. Det hadde en omfattende tidsplan som tidvis kunne oppfattes som litt for stram, fordi det ikke var gjort plass til å foreta endringer eller forekomst av uforutsette hendelser. I tillegg til dette hadde ikke de som planla prosjektet gjort en tydelig prioritering av de ulike aktivitetene, slik at alle delene av planen var like viktige. Dersom det ikke gjøres prioriteringer av de ulike oppgavene kan det være vanskelig å være fleksibel underveis, og Jonas var derfor tydelig på at dette måtte gjøres dersom de skulle komme i mål med prosjektet. Likevel tror han at årsaken til at det ble utarbeidet en så detaljert plan lå i at de som stod for planleggingen hadde gjennomført denne typen prosjekter før. På denne måten har de gjort seg mange erfaringer om hva som fungerer og ikke og antakeligvis hva som er de mest kritiske punktene i et prosjekt som dette. Til tross for at planen har vært svært detaljert, mener Jonas likevel at en grundig plan er essensielt for å kunne følge opp prosjektet. Ved å ha en plan detaljert plan er det lettere å måle fremgangen, fordi man har en referanseverdi å forholde seg til. For å kunne ende opp med ønsket resultat mener Jonas at man må ha et tydelig mål for hva man ønsker å oppnå i den nærmeste tiden.

68 56 KAPITTEL 6. FUNN Når Jonas tenker tilbake på Prosjektet ser han likevel at han kunne ønske at det var lagt inn litt mer «slack» i prosjektplanene. Dette fordi han tror at de stramme planene til dels har gått på bekostning av kvaliteten på det avsluttende resultatet, og at de med en litt mer fleksibel plan kunne endt opp med høyere kvalitet. For planleggingen av Prosjekt F brukte de over halvannet år og Tobias anser det som et høyst detaljert planlagt prosjekt. Det var viktig å ta seg god tid å gjøre gode vurderinger underveis for å kunne komme frem til en så god løsning som mulig. Han mener at det er relativt enkelt å ha styring på de store tingene i prosjekter som dette, men at det er detaljene som kan være vanskelig å håndtere. Dersom man ikke inkluderer detaljene som en del av prosjektplanen, risikerer man at helt trivielle ting kan være med på å forsinke prosjektprosessen. Med dette mener han at suksessfaktoren til et prosjekt ligger i detaljene og at nøkkelen til et vellykket prosjekt ligger i planene. Om prosjektet som skal gjennomføres er stort eller lite, mener Tobias ikke har noen betydning for hvor mye planlegging det trenger. Et lite prosjekt kan være mye viktigere og mer kritisk enn et stort og vil derfor trenge grundige planer. Hvis du først kaller noe et prosjekt, så fortjener alle prosjekter en god plan - Tobias Prosjekt F Planer for organisk vekst I tillegg til at prosjektplanen i Prosjekt A var grundig planlagt, ble det også lagt detaljerte planer for de organisatoriske endringene i bedriften. Jonas tror de detaljerte planene er med på å skape mer struktur i bedriften og at de på lang sikt ikke vil ikke begrense den videre veksten og utviklingen. Som en del av planene ble det utarbeidet rutiner for endringer, slik at det finnes fremgangsmåter dersom det er ønskelig å foreta endringer i IIen. På samme måte ble det gjort i Prosjekt B hvor Mathias mente at de var nødt til å planlegge endringen detaljert for å kunne utvikle en fleksibel løsning som ikke var stiv og begrensende. Han mener at det ikke ville vært mulig å utarbeide en så kompleks løsning som dette uten grundige og detaljerte planer. Markus fra Prosjekt E tror heller ikke at planene de har lagt vil ha noen fremtidige begrensinger for organisasjonen. I dette prosjektet ble det derimot lagt mye mindre detaljerte planer og det ble tidlig innført rutiner for hvordan man skal gå frem dersom man ønsker å vike fra de opprinnelige planene. Årsaken til dette var at de ikke ønsket å tvinge brukere til å ta del i den nye løsningen, men derimot å få dem til å se fordelene av den og selv føle lyst til å endre arbeidsrutinene sine for integrasjon av nye systemer. Dette er med på å gjøre integrasjonsarkitekturen svært fleksibel og tilpasningsdyktig. Ettersom det allerede ikke fantes noen integrasjonsarkitektur i organisasjonen, var det ikke slik at den nye løsningen skulle ta over for en eksisterende. Dette gjorde at planene for den nye arkitekturen ikke ble påvirket av kontinuerlige endringer i IIen, men derimot hadde som hensikt å kun utarbeide planer for en så fleksibel integrasjonsarkitektur som mulig.

69 6.3. PLAN 57 Ved planleggingen av IIen i Prosjekt C var det svært viktig å ha fokus på å legge planer uten altfor høyt detaljnivå. Årsaken til dette ligger i at prosjektet hovedsakelig hadde som hensikt å utarbeide en grunnmur for videre utvikling. Dette gjorde det unødvendig å fokusere mye på detaljer, fordi det ikke var en del av målet med gjennomføringen av prosjektet. Derimot var de opptatt av at de planene som ble lagt, var klare og tydelige, for å kunne gi et godt bilde på hvordan den nye grunnmuren skulle se ut. I tillegg til at planene for det nye driftssenteret var tydelig utformet, var det i tillegg utarbeidet en pågående prosess for tilpasning og endring av løsningen. I tillegg til at driftssenterløsningen er utarbeidet for å være smidig og fleksibel, tror ikke Andreas at arbeidsoppgavene i organisasjonen kommer til å endre seg drastisk. Dette betyr derfor at han ikke tror at planene vil kunne være begrensende for den videre veksten i organisasjonen. I Prosjekt D derimot ble ikke den nye løsningen planlagt for videreutvikling, noe de oppdaget da det ble behov for å gjøre endringer og tilpasninger. De ble da nødt til å gjøre en rekke omstruktureringer for å gjøre det nye systemet mer fleksibelt og tilpasningsdyktig til nye aktører. Systemet fra Prosjekt D er et system hvor det typisk skjer mange endringer kontinuerlig, slik at de derfor hadde et behov for å gjøre seg mer tilpasningsdyktige til nye aktører. For å få til dette ble det derfor utarbeidet en modul som fungerer som et bindeledd. Denne er derfor ikke strengt planlagt på den måten at det skaper begrensinger for den videre veksten. Tobias fra Prosjekt F tror at planer kan være begrensende dersom man ikke har et bevisst forhold til hvordan de påvirker fremtiden. Dette gjelder typisk i vanlige kunde-leverandør-forhold hvor man ofte legger mye av ansvaret hos leverandøren. Han mener derimot at det er kunden selv som må ta dette ansvaret, da det er kunden som vet hva han trenger og vil ha. Med dette vil han derfor illustrere at det er enkelt å gå i en del feller om man ikke har kjennskap til hvilken påvirkning planer har. Ved innføring av Lync prøvde de å planlegge det slik at det skulle bli smidig i den grad det er mulig å gjøre tilpasninger i Microsofts produkter Resultat Jeg vil oppsummere dataene slik: A B C D E F Detaljert plan bidrar til god styring av et prosjekt En kompleks II utvikles organisk over tid og kan ikke planlegges i detalj Tabell 6.2: Plan oppsummert At en detaljert plan gir økt styring viser seg å være gjennomgående for alle prosjektene, noe som antageligvis kan knyttes opp mot målet om høy kvalitet. Derimot kan det se ut til at de fleste mener at grundige planer ikke vil påvirke den videre veksten og utviklingen av organisasjonen i noen særlig grad.

70 58 KAPITTEL 6. FUNN 6.4 Organisering Hierarkisk ledelse I Prosjekt A ble det benyttet en streng hierarkisk struktur for gjennomføringen av prosjektet. Dette kan man blant annet se på oppbygningen hvor prosjektet var delt inn i tre underprosjekter og deretter omsluttet av hovedprosjektet. I tillegg til dette påpekte prosjektlederen Jonas at Prosjekt A var styrt med en streng hierarkisk struktur og at dette var avgjørende for å kunne få god nok oversikt og styring i et så omfattende prosjekt. Han mistenker at bakgrunnen for den bratte hierarkien ligger i gjennomføringen av prosjektet sammen med det indiske selskapet, Alfa, hvor bratt hierarki står mye sterkere enn i Norge. Til tross for at dette var viktig for å kunne gjennomføre et vellykket prosjekt, oppfattet han det til tider som ubehagelig når enkelte av prosjektdeltakerne ble bedt om å vise til hva de hadde gjort foran ledelsen eller lignende. Sett sammen med det svært detaljerte planene som var lagt for prosjektet, var det derfor veldig viktig å ha et godt overordnet blikk slik at prosjektplanen ble fulgt. Likevel kunne nok noe av den bratte hierarkien vært dempet for å skape en bedre prosjektkultur, uten at dette hadde gått på bekostning av hverken prosjektprosessen eller det avsluttende resultatet. Mye av den samme hierarkiske strukturen finner man også igjen i Prosjekt B, som har en lignende fysisk oppbygning med flere underprosjekter og derfor også flere underprosjektledere. Årsaken til at det var så viktig med en streng hierarkisk struktur lå i målet om å kunne utarbeide et helhetlig og generisk journalsystem. Dette ville ikke være mulig å få til dersom ingen hadde et overordnet blikk og hadde koordinerende ansvar for de ulike delene av systemet. Hvordan prosjektet ble styrt var også et krav fra kunden, som en sikkerhet i at det ble lagt til rette for en så vellykket prosjektgjennomføring som mulig. Prosjekt C derimot hadde en noe flatere hierarkisk struktur, fordi prosjektdeltakerne hadde en aktivt deltakende rolle sammen med prosjektlederen, og prosjektlederen stod ikke ene og alene om ansvaret for koordinering og organisering av prosjektet. Han hadde gjennom hele prosjektet mye støtte fra både prosjekteier og resten av prosjektgruppen. Likevel fantes det også i dette prosjektet hierarkiske trekk i prosjektets oppbygning, ved at det var delt inn i fire underprosjekter og deretter omsluttet av hovedprosjektet. Likevel har selve gjennomføringen av prosjektet og dets sosiale oppbygning større betydning for graden av hierarkisk struktur enn den strukturelle oppbygningen, slik at man kan si at Prosjekt C ble gjennomført med en relativt flat hierarkisk struktur. I Prosjekt D var det også en ganske flat hierarkisk struktur, men likevel ikke i samme grad som i Prosjekt C. Ettersom prosjektmetodikken som ble brukt i prosjektet ble utarbeidet av de ulike deltakerne, kan man på mange måter si at strukturen var ganske flat fordi det var rom for å komme med innspill for hvordan prosjektet best mulig burde gjennomføres. Ettersom gjennomføringen av prosjektet hadde en stor koordinerende jobb for å sørge for at de ulike aktørenes ønsker og behov ble møtt, vil jeg tolke dette som at prosjektet hadde en middels flat/bratt hierarkisk

71 6.4. ORGANISERING 59 struktur som gav nok styring og oversikt til å gjennomføre prosjektet på en vellykket måte. Det var et gjennomgående trekk ved hele prosjektet å jobbe tett sammen med de ulike interessentene, men for å sørge for at alle ble hørt og at det ble utarbeidet en helhetlig løsning på tvers av alle brukergruppene, var det avgjørende en viss overordnet styring for å kunne få til dette. Selv om Prosjekt E var et noe mindre prosjekt sett i forhold til Prosjekt A, B og D, ble det styrt med et ganske strengt hierarki. I forkant av prosjektet ble det foreslått å samkjøre prosjektet med andre lignende prosjekter innenfor samme sektor, men dette mener prosjektlederen Markus hadde blitt altfor komplisert og at prosjektet ene og alene var så komplekst at det var vanskelig å gripe over. På grunn av prosjektets kompleksitet var det derfor viktig med en hierarkisk struktur for å kunne få oversikt på en måte som gjør prosjektet med angripelig. I Prosjekt F finner man igjen mange av de samme strukturelle trekkene med oppdeling av prosjektet i flere underprosjekter, og selve styringen og koordineringen av prosjektet kom fra toppen av. Ettersom prosjektet omfattet hele bedriften, var det viktig å jobbe tett mot sluttbrukerne. For å koordinere dette var det derfor viktig med en hierarkisk struktur med god forankring hos prosjektets styringsgruppe. Ut ifra dette ser det derfor ut at det er et stort behov for en hierarkisk struktur ved ledelse av store komplekse prosjekter for å kunne koordinere både de ulike prosjektdeltakerne, men også på grunn av de ulike brukergruppene og legge til rette for et resultat som er tilpasset så mange som mulig Ledelse for innovasjon Ettersom bakgrunnen for gjennomføringen av Prosjekt A var for at bedriften skulle kunne overleve på sikt, kan man si at dette var et prosjekt som var besluttet å gjennomføre fra toppen i organisasjonen. Beslutningen for hvilken bedrift som skulle ta over Kappas tjenester ble også tatt sentralt i organisasjonen, da det kun var ledelsen som hadde myndighet til å avgjøre hvilken avtale som ville være den beste for organisasjonen. Da prosjektet ble satt i gang var det et tett samarbeid mellom de ulike brukergruppene i både Kappa og Alfa, som skulle ta over Kappas tjenester, ved at de fysisk satt sammen for å lære om hvordan ulike arbeidsoppgaver opprinnelig ble utført og hvilke muligheter som fantes for å gjøre disse på en mer effektiv måte. Ettersom et annet mål med prosjektet også var å kunne tilby enda flere tjenester enn de kunne i forkant av prosjektet, var det derfor nyttig at de lokale delene i organisasjonen fikk ta en aktiv del i prosjektgjennomføringen. Dette bidro derfor til at ansatte som ikke satt sentralt i bedriften aktivt fikk ta del i innovasjonsdelen av prosjektet. For å kunne utarbeide et journalsystem som sluttbrukerne faktisk ønsker å bruke samtidig som at det har de funksjonene man er avhengig av for å kunne gjøre jobben sin, gjorde derfor at prosjektgruppen i Prosjekt B måtte jobbe tett sammen med sluttbrukerne for å hente ut så mye informasjon som mulig. Her som i Prosjekt A ble beslutningen om gjennomføringen av prosjektet tatt sentralt, men tilpasningen og utarbeidelsen av systemet ble gjort med en bottom-up-tilnærming.

72 60 KAPITTEL 6. FUNN Dette var avgjørende for å ende opp med et resultat som var nyttig for sluttbrukerne, da det var sluttbrukernes bedømmelse av resultatet som var avgjørende om det var vellykket eller ikke. På denne måten kan man derfor si at sluttbrukerne hadde stor betydning for hvordan det avsluttende resultatet ble, men at det opprinnelige initiativet for gjennomføringen av prosjektet ble tatt sentralt. I tillegg til den flate hierarkiske strukturen i Prosjekt C, hadde også sluttbrukerne mye de skulle si for hvordan den nye driftssenterløsningen ville bli seende ut. De lokale enhetene i organisasjonen hadde stor beslutningsmakt under denne prosessen da det den avsluttende driftssenterløsningen ville påvirke de lokale enhetene i lang tid etter prosjektets gjennomføring. Det ble lagt mye tid på å komme frem til avtaler på tvers av avdelingene i organisasjonen, noe som derfor viser hvor stor makt de lokale delene hadde under prosjektgjennomføringen. Det ble også gjennomført omfattende intervjuer og brukerundersøkelser slik at løsningen skulle bli så tilpasset som overhodet mulig. Dette var spesielt viktig fordi dette ikke var et teknisk prosjekt, men en omstrukturering av arbeidsflyt i organisasjonen. Likevel skal det legges ved at selve beslutningen for gjennomføringen ble tatt sentralt i organisasjonen, men at beslutningene for muligheten for innovative endringer ble tatt lokalt. I Prosjekt D var det under hele prosjektprosessen et tett samarbeid med interessentene for å få en så tilpasset løsning som mulig. I dette prosjektet hadde ikke interessentene den samme beslutningsmuligheten som i for eksempel Prosjekt C, selv om det var fokus på å ta hensyn til alle parter i den grad det var mulig. Ut ifra dette kan man derfor si at beslutningene for lokale tilpasninger og innovasjon på sett og vis var sentrale, men at de sentrale beslutningene ble gjort på bakgrunn av et ønske om best mulig brukertilpasning. Initiativet for igangsetting og gjennomføring av prosjektet kom også fra sentralt i sektoren. I Prosjekt E finner man igjen mange av de samme trekkene som i de andre beskrevne prosjektene, ved at beslutningen om gjennomføringen av prosjektet kommer fra sentralt i organisasjonen. I dette tilfellet kommer det fra et krav i sektoren om innføring av en enhetlig integrasjonsarkitektur. Til tross for at det også her var et tett samarbeid med de ulike brukergruppene, hadde de ingen beslutningsmakt for å tilpasse og tilrettelegge for innovative løsninger. Dette betyr derfor at integrasjonsarkitekturen ble utarbeidet med hensyn til sluttbrukerne, men at selve beslutningene ble tatt sentralt. Ettersom Prosjekt F angikk hele organisasjonen, var det også her et tett samarbeid med interessentene. Her jobbet prosjektet sentralt med både ledelsen og regionsjefene som igjen jobbet tett mot sine ansatte. På denne måten hadde denne prosessen en hierarkisk struktur hvor informasjonsflyt om tilpasninger og ønsker beveget seg opp og ned langs den hierarkiske oppbygningen. Tobias mener at denne typen tilpasninger ikke kunne blitt tatt sentralt i et prosjekt som dette, fordi den så aktivt påvirket hver enkelt ansatt i organisasjonen. Det var derfor en god løsning å bruke organisasjonens organisatoriske struktur, slik at de som jobbet lokalt kunne dele sine erfaringer og ønsker med sine nærmeste ledere, slik at denne lederen kunne sende dette videre oppover i systemet. Likevel ble beslutningen om gjennomføringen av prosjektet tatt sentralt, fordi de så et behov for å bytte ut den

73 6.5. OPPFØLGING 61 eksisterende, utdaterte og brokete løsningen de hadde med ett enkelt og helhetlig system. Den sentrale beslutningen ble derfor tatt på bakgrunn av ønsket om en teknisk endring, men at beslutninger for lokale tilpasninger som kunne bidra til innovasjon, hadde de lokale delene stor mulighet til å påvirke. Likevel skal det legge ved at de lokale enhetene ikke hadde en total beslutningsmakt Resultat Jeg vil oppsummere dataene slik: A B C D E F Hierarkisk prosjektledelse gir vellykket resultat Prosjekter med innovasjon bør besluttes desentralisert Prosjekter uten innovasjon bør besluttes sentralisert Tabell 6.3: Organisering oppsummert 6.5 Oppfølging Prosjektoppfølging Prosjekt A var et svært styrt prosjekt, da det ble gjort grundig oppfølging gjennom hele prosjektprosessen. Oppfølgingen ble i all hovedsak gjort ved hjelp av de detaljerte planene som gjorde at de til enhver tid kunne avgjøre hvordan prosjektet lå an. Ettersom det var selskapet Alfa som hadde stått for både planlegging og estimering, kunne ikke informanten si noe om hvordan de hadde det var gått frem for utarbeidelse av planer og estimater. Som nevnt under avsnittet om planer, syntes informanten at det kom tydelig frem av planverket Alfa hadde gjennomført lignende prosjekter før. Til tross for at planen var stram, var det enkelt å følge opp prosjektet, fordi det var svært konkrete planer for hva som skulle gjøres når. Prosjekt B var også er veldig styrt prosjekt, og prosjektlederen Mathias mener at dette var essensielt i et prosjekt som dette på grunn av dets omfang og kompleksitet. Ettersom Prosjekt B var et strengt planlagt prosjekt, bidro dette til at Mathias enkelt kunne følge prosjektet steg for steg gjennom hele prosessen. Andreas fra Prosjekt C anser ikke prosjektet som veldig styrt i den grad at det var streng oppfølging underveis i prosjektprosessen, men det var styrt ved at det ble stilt en del krav til prosjektet fra sentralt i organisasjonen. På denne måten ble de nødt til å følge opp prosjektet underveis for å sørge for at de kunne levere det ledelsen ønsket, men prosjektet ble ikke styrt med jernhånd på samme måte som i Prosjekt A og B. Årsaken til at Prosjekt C ikke var like styrt som Prosjekt A og B kan ligge i at prosjektet ikke hadde like harde tidsfrister for når prosjektet skulle være avsluttet. Det var viktigere å levere et funksjonelt og vel gjennomtenkt driftssenter enn å overholde harde tidsfrister, slik at ønsket og behovet for kvalitet

74 62 KAPITTEL 6. FUNN ble overholdt. Kvalitet var som nevnt viktig i alle prosjektene, men Prosjekt C var nok ikke like bundet av tiden som for eksempel Prosjekt A og B. Til tross for at fasene ble planlagt inkrementelt i Prosjekt D, var hver av fasene svært styrt. Dette viser tilbake til både behovet for høy kvalitet som ble reflektert i inkrementell planlegging og detaljerte planer. For å sørge for at sikkerheten i prosjektet ble overholdt var det avgjørende at hver fase var sterkt styrt, slik at planene ble fulgt til punkt og prikke. Dersom prosjektet ikke hadde blitt grundig fulgt opp, hadde det vært stor risiko for at feil som kunne lekke data, forekom. Dette hadde vært en skandale for prosjektet, ettersom systemet som ble utarbeidet holdt på en rekke sensitiv informasjon. Som en del av oppfølgingen ble det foretatt kontinuerlige risikoanalyser, slik at de til enhver tid kunne ligge i forkant av potensielle utfordringer og risikoer. Dette var med på å skape en trygghet gjennom prosjektets gang som også bidro til at man kunne følge opp prosjektet på en kontrollert og sikker måte. Prosjekt E var i utgangspunktet ikke strengt styrt fra prosjektlederens og organisasjonens side, men fordi de hadde fått tildelt porteføljemidler var dette med på å legge et press om å levere. Dersom prosjektet ikke hadde levert en integrasjonsarkitektur som stod til forventningene, hadde de vært nødt til å betale tilbake de tildelte midlene. Selv om dette var med på å presse prosjektet, kan ikke informanten se noen ulemper ved å styre prosjektet på denne måten. Dette gjorde at de var nødt til å følge opp prosjektet mer underveis, for å sørge for at de leverte et resultat som stod til mandatet. Prosjekt F var også et strengt styrt prosjekt, ved at det ble grundig fulgt opp gjennom hele prosjektet. Prosjektlederen Tobias mener at prosjektet til tider var litt for styrt ved at det ikke var noe rom for å kunne gjøre endringer underveis. Samtidig var det nyttig med god styring i et prosjekt som dette fordi menneskene stod så sentralt i både prosjektprosessen og prosjektresultatet. Tobias mener det er vanskelig å finne det rette nivået av styring i et prosjekt som dette, fordi det er svært individuelt hvilken grad av styring man mener er passende Kultivering Som nevnt over, ble det avsluttende resultatet i Prosjekt A utarbeidet på en måte som gjør at det er tilrettelagt for senere vekst og endringer. På denne måten tilrettela de for å kunne gjøre endringer dersom deler av løsningen ikke var så optimal som først forventet, eller at de kunne jobbe videre med de delene som fungerte ekstra godt. I Prosjekt B hvor prosjektresultatet var noe mer endelig enn i Prosjekt A, men informanten mener at det ville være mulig å gjøre tilpasninger underveis, men at det burde være en relativt høy terskel hvor man gjør grundige vurderinger før endringene inntrer. Dette var viktig for å sørge for at kompleksiteten ikke øker unødig mye i en allerede kompleks struktur, slik at de endringene og utvidelsene som ble innført, var godt gjennomtenkte. På denne måten kunne de også prøve å unngå at nye endringer ikke ville sette begrensninger for systemet i senere tid.

75 6.6. FUNN 63 Driftssenteret i Prosjekt C var utarbeidet på en måte som hadde som hensikt å til enhver tid vokse og tilpasse seg organisasjonen, og prosjektlederen Mathias mener det vil være en pågående og evigvarende prosess i etterkant av prosjektet som handler om å gjøre tilpasninger og forbedringer. På denne måten kan man si at fundamentet i hele driftssenteret handler om å dyrke frem de delene som er de mest funksjonelle og å prøve å endre eller fjerne de delene som ikke er like vellykkete. I løsningen i Prosjekt D blir det kontinuerlig jobbet med å forbedre den. Dette blant annet ved at den enda ikke har blitt heldigitalisert, men at dette forhåpentligvis vil skje i nærmeste fremtid. Digitaliseringen av løsningen har vært svært vellykket og forenklet bruken av løsningen for både kundene og brukerne. Dette viser at de har dyrket frem den de vellykkete delene av systemet, som er den digitale løsningen, og gradvis dysser ned og etter hvert fjerner den papirbaserte versjonen. I integrasjonsarkitekturen i Prosjekt E foregikk denne dyrkingen av de vellykkete egenskapene på en litt annen måte enn i de andre prosjektenes resultater. Til tross for at brukerne ble motivert til å ta i bruk arkitekturen, var ikke dette et formelt krav. Slik at det ble tilrettelagt for å kunne gjøre tilpasninger i de tilfellene hvor arkitekturen ikke ble benyttet. I hvor stor grad det ble lagt vekt på videreutvikling av den nye arkitekturen er noe usikkert, da informanten var mest opptatt av at den var utarbeidet etter best practice. I Prosjekt F var det også fokus på å videreutvikle og tilpasse den nye Lyncløsninger, men på grunn av begrensinger som allerede finnes i Microsofts produkter var det vanskelig å gjøre endringer utover det Microsoft tilbyr. På denne måten blir muligheten for å dyrke de vellykkete egenskapene og luke vekk de mindre vellykkete egenskapene, begrenset, fordi man selv ikke har råderett over dette Resultat Jeg vil oppsummere dataene slik: Kontrollert oppfølging gir bidrar til et vellykket prosjektresultat Kontinuerlig oppfølging bidrar til effektiv kultivering av IIen A B C D E F Tabell 6.4: Oppfølging oppsummert 6.6 Funn Som et resultat av analysen har jeg kommet frem til funnene som er presentert i tabell 6.5 Prinsipper for koordinering For å kunne identifisere i hvor stor grad et standardisert prosjektledelsesrammeverk

76 64 KAPITTEL 6. FUNN Prinsipper for koordinering Plan Organisering Oppfølging Prosjektledelse Standardisert metodikk gir vellykket resultat Detaljert plan bidrar til god styring av et prosjekt Hierarkisk prosjektledelse gir vellykket resultat Kontrollert oppfølging bidrar til et vellykket prosjektresultat JA JA JA JA Informasjonsinfrastruktur Tekniske standarder støtter koordinering indirekte En kompleks II utvikles organisk over tid og kan ikke planlegges i detalj Prosjekter med innovasjon bør besluttes desentralisert Prosjekter uten innovasjon bør besluttes sentralisert Kontinuerlig oppfølging bidrar til effektiv kultivering av IIen JA NEI NEI JA JA Tabell 6.5: Funn påvirker prosjektresultatet, viser analysen at informantene fra Prosjekt A, B og F var nøytrale til påstanden, mens informantene fra Prosjekt C og E var enige. Informanten fra Prosjekt D var uenig i påstanden. Dersom man sammenligner de seks prosjektene basert på bruk av standardisert prosjektledelsesrammeverk, kan man se at Prosjekt D er det prosjektet som skiller seg mest ut og er derfor ikke representativt for det totale utvalget i denne studien. Basert på dette har jeg kommet frem til at påstanden om at et standardisert prosjektledelsesrammevek bidrar til et vellykket prosjektresultat, er gyldig. Fra analysen om innføring av tekniske standarder, viser det svært sprikende resultater. Dette bunner hovedsakelig ut i at det i Prosjekt A, C og E ikke ble innført noen tekniske standarder, noe som derfor gjorde at de ikke var kvalifisert til å kunne svare på påstanden. I prosjektene hvor det ble innført tekniske standarder, kunne man se at alle hadde en indirekte koordinerende effekt på de ansatte i organisasjonene. Dette er derfor med på å gjøre påstanden om at tekniske standarder er indirekte koordinerende, gyldig. Plan Dataene fra kategorien om plan viser jevnt over at alle informantene er enige om at en detaljert prosjektplan gir god styring på prosjektet. Det var kun informanten fra Prosjekt E som sa seg noe uenig i dette, men ettersom resten av informantene var enige i påstanden, vil jeg anse den som gyldig. Ved planlegging av IIer var resultatene noe mer sprikende, da tre av informantene stilte seg relativt nøytrale til påstanden. Derimot var både Prosjekt A og B enige om at strenge planer ikke ville forhindre organisk vekst, men derimot bidra til økt kontroll og struktur. Det var kun informanten fra Prosjekt C som sa seg helt enig i påstanden. Til tross for at resultatene er noe utydelige, vil jeg konkludere med at påstanden er ugyldig fordi resultatene viser at de fleste er uenig eller nøytrale til utsagnet.

77 6.6. FUNN 65 Organisering Ettersom dataene fra analysen viser at fire av seks caser viser at hierarkisk prosjektledelse bidrar til et vellykket prosjekt, tolker jeg dette som et gyldig svar for påstanden. Til tross for at Prosjekt C er uenig og Prosjekt D befinner seg et sted midt imellom, mener jeg at fire av seks caser er et representativt utvalg for denne studien. I påstanden om sentralisert beslutning ved gjennomføring av prosjekter uten innovasjon, er det fullstendig enighet blant alle de undersøke casene og jeg vil derfor anse påstanden som gyldig. I påstanden om desentralisert beslutning er dataene både sprikende og vage. I tillegg til dette valgte jeg å gjøre noen modifikasjoner i henhold til påstanden, slik at dataene ikke lenger er direkte overførbare i henhold til Henfridsson og Bygstads funn om at beslutninger bør tas desentralisert om beslutningen har som hensikt å føre til innovasjon (Henfridsson og Bygstad 2013). På bakgrunn av dette samt at gjennomsnittet av dataene er på omtrent 2, vil jeg anse funnene som ugyldige i henhold til påstanden. Oppfølging I påstanden om at styrt oppfølging bidrar til et vellykket prosjektresultat, er det fullstendig enighet blant alle de undersøkte casene og jeg vil derfor anse påstanden som gyldig. I påstanden om at kontinuerlig oppfølging bidrar til effektiv kultivering av IIen, var flertallet av de undersøkte casene enige i påstanden. Selv om Prosjekt B fikk tildelt verdien to, er det åpenhet for kultivering av det nye journalsystemet, men terskelen for gjennomføring av endringer er noe høyere enn i de andre casene. Jeg vil ut ifra dette anse påstanden som gyldig.

78 66 KAPITTEL 6. FUNN

79 Kapittel 7 Diskusjon I dette kapittelet vil jeg starte med å kort presentere det forventede og observerte mønsteret og deretter bruke disse til å gjennomføre pattern matchingen. Pattern matchingen vil bli delt opp i henhold til de utarbeidede kategoriene fra forventet og observert mønster, slik at sammenligningen mellom litteratur og empiri vil foregå på en så oversiktlig måte som mulig. Innenfor hver kategori vil det også bli presentert et forskningsspørsmål som jeg vil prøve å svare på mot slutten av det tilhørende temaet. Avslutningsvis vil jeg prøve å svare på studiens overordnede problemstilling. Tabell 7.1 oppsummerer resultatet etter endt pattern matching: Prinsipper for koordinering Plan Organisering Oppfølging Hovedfunn Et standardisert prosjektledelsesrammeverk vil ikke kunne bidra til et vellykket prosjektresultat med mindre prosjektlederen har nok prosjekterfaring til å kunne gjøre tilpasninger av rammeverket til det enkelte prosjektet. Detaljerte planer i et stort komplekst prosjekt bidrar til et vellykket prosjektresultat. Hierarkisk ledelse av et stort komplekst prosjekt bidrar til et vellykket prosjektresultat Kontrollert oppfølging av et stort komplekst prosjekt bidrar til et vellykket prosjektresultat Bidrag fra II-litteraturen Ved bruk av standarder i store komplekse prosjekter er det viktig å se omfanget av en den og hvordan den påvirker omgivelsene den innføres i. Store komplekse prosjekter kan planlegges detaljert så lenge fleksibilitet i prosjektresultatet er en del av planverket. Kontrollert oppfølging vil kunne være med på å dyrke frem de delene av prosjektresultatet som er spesielt vellykket og luke bort de mindre vellykkete. Tabell 7.1: Oppsummering diskusjon 7.1 Forventet mønster og observert mønster På bakgrunn av litteraturen som ble presentert i litteraturkapittelet har jeg kommet frem til det forventede mønster som er vist i tabell 7.2. Hver av påstandene er basert på flere ulike studier hvor hver av disse er lagt ved som referanse under 67

80 68 KAPITTEL 7. DISKUSJON den tilhørende påstanden. Ettersom både det forventede og det observerte mønsteret er utarbeidet på bakgrunn av litteratur- og funn-kapitlene, vil jeg ikke gi noen grundigere beskrivelse av dem her. Prinsipper for koordinering Plan Organisering Oppfølging Prosjektledelse Standardisert metodikk gir vellykket resultat (Milosevic og Patanakul 2005, s. 189) (Office of Government Commerce 2009, s. 31) Detaljert plan bidrar til god styring av et prosjekt (Office of Government Commerce 2009, s ) (Cadle og Yeates 2004, s. 120) Hierarkisk prosjektledelse gir vellykket resultat (Office of Government Commerce 2009) (Cadle og Yeates 2004) Kontrollert oppfølging av bidrar til et vellykket prosjektresultat (DeMarco 1982, s. 1) (Office of Government Commerce 2009, s. 101) Informasjonsinfrastruktur Tekniske standarder støtter koordinering indirekte (Hanseth og Braa 2001, s ) (Hanseth og Bygstad 2015) En kompleks II utvikles organisk over tid og kan ikke planlegges i detalj (Hanseth og Lyytinen 2010) (Greenhalgh, Hinder, Stramer, Bratan og Russel 2010) Prosjekter med innovasjon bør besluttes desentraliert Prosjekter uten innovasjon bør besluttes sentralisert (Henfridsson og Bygstad 2013) (Grisot, Hanseth og Thorseng 2014) Kontinuerlig oppfølging bidrar til effektiv kultivering av IIen (Grisot, Hanseth og Thorseng 2014) Tabell 7.2: Forventet mønster Etter gjennomføringen av analysen har jeg kommet frem til det observerte mønster som er vist i tabell 7.3. Prinsipper for koordinering Plan Organisering Oppfølging Prosjektledelse Standardisert metodikk gir vellykket resultat Detaljert plan bidrar til god styring av et prosjekt Hierarkisk prosjektledelse gir vellykket resultat Kontrollert oppfølging bidrar til et vellykket prosjektresultat JA JA JA JA Informasjonsinfrastruktur Tekniske standarder støtter koordinering indirekte En kompleks II utvikles organisk over tid og kan ikke planlegges i detalj Prosjekter med innovasjon bør besluttes desentralisert Prosjekter uten innovasjon bør besluttes sentralisert Kontinuerlig oppfølging bidrar til effektiv kultivering av IIen JA NEI NEI JA JA Tabell 7.3: Observert mønster

81 7.2. PATTERN MATCHING Pattern Matching Jeg vil her gjennomføre pattern matchingen ved å sammenligne det forventede og observerte mønsteret Prinsipper for koordinering Basert på hvordan bruk av standarder påvirker store komplekse prosjekter, har jeg kommet frem til følgende forskningsspørsmål: På hvilken måte bidrar standarder til et vellykket prosjekt? Direkte koordinerende standarder I Milosevic og Patanakuls studie fra 2005, så de på hvordan standardiserte prosjektledelsesrammeverk påvirker prosjekter og om de er med på å øke den totale suksessraten. I forarbeidet til studien, kunne de vise til flere andre lignende studier med noe varierende resultater. Selv kunne de vise at et standardisert prosjektledelsesrammeverk ville være med på å øke suksessraten frem til et visst punkt, og at dersom man valgte å standardisere flere prosesser enn dette, ville suksessraten begynne å synke igjen, slik som illustrert i figur 2.1 (Milosevic og Patanakul 2005). Dette stemmer godt overens med funnene fra denne studien, hvor det også kom frem at en standardisert prosjektmetodikk legger til rette for et vellykket prosjektresultat. Likevel var informantene enige i at rammeverket må tilpasses det enkelte prosjektet for at det virkelig skal kunne skape verdi. Ved tilpasning av et prosjektledelsesrammeverk, mener Wells(2012) at prosjekterfaring er avgjørende for å kunne fastslå hvilke deler av et rammeverk som er hensiktsmessig å benytte i det enkelte prosjektet. Dette ser man også i denne studien, hvor det i majoriteten av casene som benyttet standardisert prosjektmetodikk, var erfarne prosjektledere. Derimot kom det frem at Andreas fra Prosjekt C, som var en noe mindre erfaren prosjektleder, oppfattet det som utfordrende å tilpasse et slikt rammeverk. Til tross for at Wells mener at prosjekterfaring er viktig i denne sammenhengen, antyder han at mange av de kjente rammeverkene har en altfor komplisert oppbygning. Dette gjør rammeverkene i utgangspunktet ekstra vanskelige å tilpasse (Wells 2012, s. 44). Man kan derfor undres om det er rammeverkenes evne til tilpasning eller prosjektlederes mangel på prosjekterfaring som gjør at et standardisert prosjektledelsesrammeverk ikke nødvendigvis er synonymt med et vellykket prosjektresultat. Her kommer man derfor tilbake til at de standardiserte rammeverkene ikke er beregnet på den uerfarne prosjektlederen, men derimot den erfarne som selv kan avgjøre hvilke deler av rammeverket som er passende for det gitte prosjektet. Ettersom prosjektlederens erfaring er så avgjørende for gjennomføring av et vellykket prosjekt, i hvor stor grad spiller da bruken av et kjent standardisert prosjektledelsesrammeverk for prosjektets suksessrate? I denne studien kom det frem

82 70 KAPITTEL 7. DISKUSJON i flere av casene at det ble benyttet egenutarbeidede prosjektrammeverk spesielt tilpasset prosjektet det ble benyttet i. Her ble prosjektledernes egne erfaringer benyttet for å avgjøre hvordan prosjektene burde gjennomføres best mulig. Fellesnevneren er at prosjektledernes egne erfaringer ble benyttet til å utarbeide den fremgangsmåten som ville være med på å bidra til et så vellykket prosjekt som mulig. I følge Milosevic og Patanakul (2005, s. 189) er det prosjektrammeverkenes evne til å tilby en strukturert og oversiktlig måte å gjennomføre prosjekter på, som legger til rette for et vellykket prosjekt. Man kan derfor tolke dette som at dersom prosjektlederen har evnen til å strukturere et prosjekt på en logisk og oversiktlig måte, vil dette kunne bidra til et vellykket prosjekt. Det kan da virke som irrelevant om man benytter et kjent standardisert prosjektledelsesrammeverk eller ikke, fordi det er prosjektlederens evne til å benytte sine egne erfaringer som er avgjørende for utfallet av prosjektet. Det man derimot man gå nærmere inn på er om en kjent standardisert prosjektmetodikk bidrar til økt suksessrate for prosjektprosessen eller prosjektresultatet. Ettersom en prosjektmetodikk hovedsakelig har som hensikt å tilby prosjektlederen en logisk fremgangsmåte for gjennomføring av prosjektet, kan man anta at den legger til rette for en vellykket prosjektprosess. Likevel ønsker et standardisert prosjektrammeverk å bidra til et mer kostnadseffektivt prosjekt og resultater med høy kvalitet som står til kundens forventninger (Milosevic og Patanakul 2005; Office of Government Commerce 2009). Dette betyr derfor at det legger til rette for et vellykket prosjektresultat, men slik jeg oppfatter det er prosjektresultatet nærmest en effekt av effektiv bruk av et standardisert prosjektledelsesrammeverk fremfor hva rammeverket har som hensikt å legge til rette for. Med dette mener jeg at dersom man har den rette mengden erfaring til å kunne gjøre gunstige tilpasninger av en prosjektmetodikk, vil metodikken legge til rette for en vellykket prosjektprosess. Indirekte koordinerende standarder I henhold til Hanseth og Bygstad (2015) innføres standarder som et tiltak for økt styring, som en måte å skape mer orden og struktur i en II. Til tross for at standardene hovedsakelig er tekniske, kommer det frem i denne studien at standardene også har en indirekte koordinerende effekt. Det samme fenomenet kan man også finne igjen i flere andre studier hvor det er innført tekniske standarder, slik som innføringen av Lotus-applikasjoner i Norsk Hydro (Hanseth og Braa 2001). Den indirekte koordinerende effekten handler om hvordan den tekniske standarden påvirker de menneskelige aktørene den omfatter, slik som de ansatte i en bedrift. I alle de undersøkte casene i denne studien hvor det ble innført en teknisk standard, hadde den en indirekte koordinerende effekt på brukerne. Dette ved at de ble nødt til å endre sine arbeidsrutiner og bruksmønstre slik at de var i henhold til den nyinnførte standarden. I denne studiens undersøkte caser, kan det se ut til at alle de innførte standardene i all hovedsak hadde en positiv koordinerende effekt på brukerne. Dette ved at omveltningen fra gammel til ny løsningen gikk relativt smidig og at brukerne had-

83 7.2. PATTERN MATCHING 71 de god forståelse for endringene. Om man derimot ser på casen med Norsk Hydro, hvor det ble innført en lite tilpasset standard, ble standarden oppfattet som stiv og begrensende, noe som var til stor frustrasjon for de ansatte (Hanseth og Braa 2001). I begge eksemplene hadde standardene en indirekte koordinerende effekt, ved at de i stor grad påvirket brukerne og spesielt deres arbeidsrutiner. Hovedforskjellen ligger derimot i hvilken måte de ble påvirket og om de var med på å lette arbeidet for brukerne. Dette viser derfor at en teknisk standard vil ha en indirekte koordinerende effekt på både godt og vondt. Slik at en dårlig tilpasset standard vil ha negativ innvirkning på brukerne, ved at arbeidsoppgavene må gjøres på en mindre effektiv måte, eller omvendt ved at standarden bidrar til en mer effektiv hverdag for brukerne. Uansett utfall vil standarden være indirekte koordinerende. Det som derimot Hanseth og Bygstad skriver en del om, er dette med å finne det rette nivået av styring for innføring av standarder. Dersom en standard er svært sterkt styrt, risikerer man å begrense muligheten for innovasjon fordi det ikke er tilrettelagt for lokale tilpasninger i IIen. Det er derfor avgjørende å finne det nivået som bidrar til innovasjon ved at standarden bidrar til å være muliggjørende for brukerne (Hanseth og Bygstad 2015, s. 646). Det kan derfor tyde på at de undersøkte casene i denne studien innførte standarder med et nivå av styring som sørget for lokale tilpasninger samtidig som at den overordnede styringen ble overholdt. Dette kan man se i de casene hvor gammel funksjonalitet ble byttet ut med ny. I disse tilfellene fulgte det også med en rekke nye funksjonaliteter som var med på å utvide bruksområdene i IIen. Måten standardene indirekte koordinerer brukerne på, viser at en teknisk standard ikke kun er en enkeltstående teknisk enhet. Det betyr derfor at tekniske standarder på mange måter ikke lenger kan kalles rent tekniske, fordi de er en del av et komplekst aktør-nettverk (Hanseth og Monteiro 1997; Star og Ruhleder 1996). Jeg tror derfor at ved å anse en teknisk standard som noe mer enn en rekke tekniske retningslinjer, kan det være lettere å gjøre tilpasninger med brukeren i fokus. For å finne det rette nivået av styring, er det derfor avgjørende å ha et bevisst forhold til de indirekte konsekvensene og effektene en teknisk standard har, slik at man ser helheten i den tekniske endringen. Enkelte mener at det er standardenes opprinnelige struktur som er problemet når det kommer til tilpasning i komplekse omgivelser, fordi de ikke er bygget for raske endringer og økende vekst (Braa, Hanseth, Heywood, Woinshet og Shaw 2007, s. 385). For å løse dette må man gå grundig til verks og endre standardene fra bunnen av. Dette er svært omfattende arbeid og jeg tror ikke at dette er noe som kommer til å skje i nærmeste fremtid. Jeg har mer tro på å heller se på en standard som noe mer enn kun en teknisk enhet fremfor å legge «skylden» på at standardene har en dårlig utarbeidet struktur. Svar på forskningsspørsmål Ved bruk av direkte koordinerende standarder legger dette til rette for både en vellykket prosjektgjennomføring og prosjektresultat. Bakgrunnen for dette ligger i at en standard prosjektmetodikk skaper en form for struktur som bidrar til å kun-

84 72 KAPITTEL 7. DISKUSJON ne gjennomføre en kontrollert prosjektprosess. Dersom selve gjennomføringen av prosjektet er vellykket, øker sjansen for at det avsluttende resultatet også blir vellykket, fordi prosjektet er blitt gjennomført etter en rekke retningslinjer som er bevist har ført til vellykkete prosjektresultater tidligere. Likevel kommer det frem av denne studien at bruk av standarder krever et visst nivå av erfaring, slik at standardiserte metodikker i seg selv ikke kan bidra til et vellykket prosjekt. Standardens struktur ene og alene er med på å skape orden og oversikt, men dette avhenger av at den som benytter den har erfaring nok til å kunne avgjøre hvilke komponenter i et prosjekt som bidrar til vellykket prosjektgjennomføring og resultat. Kravet om erfaring er vel så gjeldene der hvor tekniske standarder innføres som en del av prosjektresultatet. Likevel kommer det frem av denne studien at tekniske standarder kan bidra til et vellykket prosjektresultat dersom man ser på dem som komplekse aktør-nettverk, fremfor rene tekniske standarder. På denne måten er man da tvunget til å forstå omfanget en teknisk standard har i organisasjonen. Ut ifra dette kan man derfor si at standarder i seg selv ikke vil bidra til et vellykket prosjekt, med mindre man har nok kunnskaper om hvordan sosiotekniske nettverk arter seg og at man har erfaringer til å kunne gjøre tilpasninger som gjør standardene muliggjørende for dem de omfatter Plan På bakgrunn av planers påvirkning på både gjennomføring av prosjekter og det avsluttende prosjektresultatet, har jeg kommet frem til følgende forskningsspørsmål: Bidrar grundige planer til et vellykket prosjektresultat? Prosjektplaner Prosjektledelseslitteraturen mener at detaljerte planer er nøkkelen til gjennomføring av et vellykket prosjekt. Årsaken til dette er at planene bidrar til økt styring som gjør at prosjektlederen til enhver tid kan følge progresjonen i prosjektet (Globerson og Zwikael 2002, s. 58). Dette samsvarer godt med funnene fra denne studien, hvor det viser seg at detaljerte planer bidrar til en form for styring som skaper ro og orden for alle prosjektdeltakerne. Et prosjekt kan likevel vær hektisk ved at det er omfattende arbeid som skal gjøres, men så lenge planene er realistiske med et passende detaljnivå, vil prosjektprosessen kunne oppfattes som kontrollert for både kunde og leverandør. Som nevnt innledningsvis i funn-kapittelet var det et gjennomgående fokus på høy kvalitet i studien, noe som gjør at en kan trekke paralleller til behovet for detaljerte planer og god oversikt. Dette kan man se i alle de undersøkte casene, hvor det var gjennomgående detaljerte planer. Sett i sammenheng med prosjektledelseslitteraturen ville det vært vanskelig å overholde den høye kvaliteten dersom planene ikke var detaljerte. Årsaken til dette ligger i at planene er basert på kravene til det

85 7.2. PATTERN MATCHING 73 kommende prosjektresultatet som er satt i forkant av prosjektprosessen (Globerson og Zwikael 2002; Cadle og Yeates 2004). På denne måten er det derfor avgjørende at planene er utarbeidet med et detaljnivå som sørger for at kravspesifikasjonen blir oppnådd. Ergo, detaljerte planer er svært viktig for å ende opp med et vellykket prosjektresultat. Likevel er det viktig å passe seg for at planene ikke blir for detaljerte. Da risikerer man at prosjektplanen blir stiv og man mister muligheten for å kunne gjøre endringer og tilpasninger underveis. I et av de undersøkte prosjektene skjedde nettopp dette, ved at de stramme planene avslutningsvis hadde en negativ påvirkning på prosjektresultatet. Til tross for at dette kun forekom i ett av studies caser, vil jeg likevel generalisere og si at en for detaljert prosjektplan kan virke negativt på prosjektresultatet. Dette fordi det er et kjent problem at en tidlig definert og altfor detaljert prosjektplan kan gjøre det vanskelig å være fleksibel underveis i prosjektprosessen. Selv om planene har sitt opphav i kravene fra kunden og har som hensikt å lede til et ønsket prosjektresultat, vil de også være med på å påvirke prosjektprosessen. PRINCE2 bruker som argument for utarbeidelse av gode og detaljerte planer, at det er med på å minke usikkerhet i prosjektet og at det bidrar til klarhet om hva man faktisk skal gjøre (Office of Government Commerce 2009, s. 61). Ut ifra dette kan man derfor si at detaljerte prosjektplaner har en kontrollerende effekt på prosjektprosessen, fordi de er med på å danne struktur og orden for prosjektdeltakerne. Som bakgrunn for resultatet om at detaljerte planer gir god styring på prosjektet, lå det til grunn at de grundige planene gjorde det enkelt å følge opp underveis i hele prosjektprosessen. Dette sammen med prosjektledelseslitteraturen viser derfor at et godt planlagt prosjekt også tilrettelegger for en vellykket prosjektprosess i tillegg til vellykket prosjektresultat. Planlegging av IIer I denne studien kom det frem at detaljerte planer ikke vil påvirke den organiske veksten i organisasjonen. Dette bunner ut i at informantene mener at planene vil være med på å skape struktur og oversikt som på lang sikt vil være fremmende for videre vekst. Dette står i stor kontrast til Hanseth og Lyytinen som mener at planlegging for endringer av en II skal holdes til et minimum for å sørge for at planene ikke er begrensende på noen måte. Bakgrunnen for denne påstanden ligger i at det skjer hyppige og kontinuerlige endringer i en II som gjør at planer som legges et år i forveien av en endring, potensielt kan være utdaterte når planene trer i kraft. Dette ved at enten har brukernes behov endret seg eller at de planlagte endringene ikke er kompatible med IIen som en helhet (Hanseth og Lyytinen 2010, s. 7). I de aller fleste organisasjoner forekommer ikke komplekse endringer på samme måte og i samme tempo som Hanseth og Lyytinen beskriver, noe som gjør at utsagnene deres ikke nødvendigvis er like gjeldende for denne studiens undersøkte caser. Likevel skal designprinsippene de presenterer være passende for alle typer IIer, slik at i all hovedsak også skal kunne benyttes på casene i denne studien.

86 74 KAPITTEL 7. DISKUSJON Ut ifra funnene jeg har gjort, vil jeg si at de ni designprinsippene ikke er kompatible med dagens organisasjoner sett som IIer. Dette fordi, som nevnt i litteraturkapittelet, de har en helt annen grad av styring som ikke tillater veksten og endringsraten som Hanseth og Lyytinen snakker om (Hanseth og Lyytinen 2010, s. 7). Det er nettopp dette som gjør at funnene og II-litteraturen om planer ikke stemmer overens. Til tross for at II-litteraturen i utgangspunktet er utarbeidet for internett som en II, har den i stadig større grad blitt anvendt på andre mer styrte IIer, slik som helsesystemer. For at litteraturen skal være mer kompatibel, bør det derfor gjøres noen justeringer slik at den blir mer anvendbar. På grunn av de styrte omgivelsene som de fleste organisasjoner og bedrifter er, vil det ikke være mulig å gjøre raske, men dyptgående endringer uten en form for detaljert plan. Til tross for funnene jeg har gjort, finnes det likevel andre tilfeller hvor detaljert planlegging har gått på bekostning av IIens fleksibilitet og mulighet for lokale tilpasninger, slik som i studien til Greenhalgh et.al.(2010). På denne måten ligger det derfor noe i både Hanseth og Lyytinens og Staceys uttalelser om at for detaljerte planer vil kunne ha negative konsekvenser for IIen, men at nivået av detaljer de foreslår antageligvis er ikke er helt passende for relativt styrte IIer (Hanseth og Lyytinen 2010; Stacey 1996). Tanken om å finne det nivået av planer hvor man er på kanten til kaos, slik som Stacey beskriver, er en interessant måte å fremme innovasjon på, men ut ifra funnene i denne studien vil det antageligvis skape mer usikkerhet enn innovative løsninger. En annen årsak til at funnene i denne studien ikke stemmer overens med påstanden i det forventede mønsteret, er at til tross for relativt detaljert planlegging, var endringene i IIene også planlagt for fleksibilitet. I flere av casene var det også utarbeidet rutiner for kommende endringer, slik at det finnes definerte måter å tilpasse seg nye behov og forandringer på. Spesielt denne biten er med på å understreke at detaljerte planer ikke påvirker en IIs smidighet og vekst, fordi endringshåndtering er en del av de detaljerte planene. Samtidig skal det legges ved at planer for endring må være en del av de detaljerte planene for at de ikke skal være begrensende for IIen. Svar på forskningsspørsmål Basert på diskusjonen over kan man si at detaljerte planer vil kunne legge til rette for et vellykket prosjektresultat, fordi det bidrar til at man leverer et produkt som står til kundens krav og forventninger. Detaljerte planer vil også kunne bidra til en mer styrt prosjektprosess, fordi det vil skape konsistens og oversikt gjennom hele prosjektet. Til tross for at store komplekse prosjekter har en annen kompleksitet enn de tradisjonelle prosjektene, vil det fortsatt være hensiktsmessig å overholde den samme graden detaljerte planer, fordi det skaper oversikt og struktur i komplekse omgivelser. For å forhindre at planene setter begrensninger for prosjektresultatets videre vekst, er det avgjørende at utarbeidelse av rutiner for endring og vekst er en del av planverket. Dette gjør at man allerede i planleggingsfasen tar høyde for at endringer vil kunne forekomme og at man har et bevisst forhold til at det tidlig i

87 7.2. PATTERN MATCHING 75 prosessen må finnes måter som disse kan håndteres på. Til tross for at planverket tar høyde for fleksibilitet og endringer i prosjektresultatet etter prosjektets avslutning, kan likevel prosjektplanen være stiv og lite fleksibel. Dette ved at det er lite rom for endring underveis i prosjektprosessen, men på bakgrunn av diskusjonen over vil planer med et realistisk detaljnivå likevel kunne bidra til et vellykket prosjektresultat. Det er derfor viktig å skille mellom planlegging av fleksibelt prosjektresultat og fleksibel prosjektplan. Ut ifra dette kan man si at detaljerte planer bidrar til et vellykket prosjektresultat i store komplekse prosjekter så lenge det planlegges for et fleksibelt prosjektresultat. Hvorvidt planene for prosjektgjennomføringen er fleksible eller ikke, vil ikke ha så mye å si for det avsluttende resultatet da dette har mer med prosjektlederens evne til å effektivt bruke planene som oppfølging underveis, fremfor hvordan det aktivt påvirker resultatet Organisering På bakgrunn av hvordan hierarkisk struktur påvirker både prosjekter og utforming av IIer, har jeg kommet frem til følgende forskningsspørsmål: Bidrar streng hierarkisk ledelse til et vellykket prosjektresultat? Hierarkisk ledelse I henhold til funnene i denne studien, bidrar en hierarkisk struktur til gjennomføring av et vellykket prosjekt. Dette samsvarer godt med prosjektledelseslitteraturen som beskriver at en hierarkisk struktur er med på å skape styring og oversikt (Office of Government Commerce 2009; Cadle og Yeates 2004). Det interessante i dette tilfellet er derfor hvor bratt strukturen må være for at det skal kunne bidra til et vellykket prosjekt. Hverken PRINCE2(2009) eller Cadle og Yeates(2004) sier noe om hvor bratt hierarkien bør være for å tilrettelegge for vellykket prosjekt. Likevel kan det tolkes som at man bør finne den balansen som er mest passende for det enkelte prosjektet. Under analysen kom det frem at en for bratt hierarkisk struktur kan oppfattes som hemmende for det sosiale miljøet i prosjektgruppen. Dette er et kjent psykologisk fenomen ved hierarkiske strukturer i organisasjoner (Cole og Bruch 2006, s. 585), og derfor noe man bør ta hensyn til ved gjennomføring av prosjekter. På bakgrunn av funnene som ble gjort i denne studien, kan det virke som at den rette graden av hierarki finnes der hvor man opprettholder de hierarkiske egenskapene som prosjektgruppe, prosjektleder og styringsgruppe, samtidig som at det er åpenhet for at prosjektgruppen kan komme med innspill. Innspillene kan være knyttet til selve prosjektgjennomføringen og hvordan det rent metodisk bør gjennomføres for at prosjektprosessen skal bli så smidig som mulig, samt komme med forslag direkte knyttet til kunden og prosjektresultatet. Dette var gjennomgående egenskaper ved flere av prosjektene i denne studien, og det kan derfor se ut til å

88 76 KAPITTEL 7. DISKUSJON være en logisk måte å finne en hierarkisk balanse på. Ved å tilrettelegge for en slik åpenhet i prosjektet, tror jeg man kan unngå å skape en hierarkisk struktur som har negativ innvirkning på det sosiale miljøet prosjektgruppen samtidig som at den ønskede graden av styring opprettholdes. Hierarkien stod svært sentralt i alle de undersøkte prosjektene, men graden av det var noe varierende. Likevel kan dette se ut til å være et gjennomgående trekk i store komplekse prosjekter. Dette kan potensielt knyttes opp mot både den aktive bruken av standardiserte prosjektledelsesrammeverk som stammer fra fossefallsmetodikken og de detaljerte planene for økt styring og oversikt, slik som beskrevet i avsnittene over. Som nevnt i litteraturkapittelet finnes det en strengere hierarkisk struktur i metodikkene som stammer fra fossefallsmetodikken i forhold til andre smidigere metodikker (Office of Government Commerce 2009; Sommerville 2011). Dette kan derfor være en av grunnene til den naturlige hierarkiske oppbygningen i casene i denne studien. Som beskrevet over bunner behovet for detaljerte planer ut i et ønske om god oversikt. Dette kan man også knytte opp mot hierarkisk struktur, slik at detaljerte planer og standardisert metodikk sammen danner et naturlig hierarki i prosjektene. Disse egenskapene kan være beskrivende for mange ulike typer prosjekter uavhengig om de inngår i kategorien store komplekse prosjekter eller ikke, likevel ser de ut til å være noen av de mest grunnleggende trekkene ved nettopp store komplekse prosjekter. Årsaken til dette ligger antageligvis i hvordan prosjektene påvirker organisasjoner på tvers av avdelinger, slik at behovet for oversikt og styring øker. En hierarkisk struktur har naturlig den egenskapen at det gir et overblikk som bidrar til at man enklere skal kunne koordinere de ulike enhetene i organisasjonen. På denne måten virker det derfor ikke tilfeldig at standardisert prosjektmetodikk og detaljerte planer står svært sentralt i store komplekse prosjekter for å skape en hierarkisk struktur, som igjen gir den graden av styring man trenger for å kunne koordinere prosjektene. Med bakgrunn i dette kan man derfor si at strenge, detaljerte planer og en fossefallsinspirert prosjektmetodikk bidrar til den graden av hierarki man trenger for å kunne gjennomføre en vellykket prosjektprosess og produsere et vellykket prosjektresultat. Samtidig må graden av hierarki tilpasses på en måte som bidrar til åpenhet på en måte som ikke går på bekostning av hverken prosjektprosessen eller prosjektresultatet. Ledelse for innovasjon I henhold til Henfridsson og Bygstad (2013) bør beslutninger tas sentralt i organisasjonen dersom resultatet av beslutningen ikke har som hensikt å føre til innovasjon. Dette stemmer godt overens med funnene som ble gjort i denne studien, da alle beslutninger for prosjekter uten innovasjon ble besluttet sentralt. Om derimot prosjektene var med på å indirekte legge til rette for innovasjon, er noe usikkert da jeg ikke gjorde noen større undersøkelser for hvordan prosjektresultatene hadde påvirket organisasjonene i etterkant av prosjektene. Det var et gjennomgående

89 7.2. PATTERN MATCHING 77 trekk at bakgrunnen for at beslutningene ble tatt sentralt, var for å skape økt styring og oversikt, da prosjektene gjerne var svært komplekse og omfattet store deler av organisasjonene. Om man derimot ser på de beslutningene som hadde som hensikt å legge til rette for innovasjon, viser denne studien at disse også best tas sentralt i organisasjonen. Dette strider mot både Henfridsson og Bygstad og Grisot et.al. sine funn om at denne typen beslutninger bør tas lokalt i organisasjonen (Henfridsson og Bygstad 2013; Grisot, Hanseth og Thorseng 2014). Likevel skal det legges ved at de lokale enhetene i organisasjonene hadde stor innvirkning på det avsluttende resultatet, men at de ikke hadde den totale beslutningsmakten til å kunne ta avgjørelsen for hvordan prosjektresultatet skulle se ut eller at prosjekter skulle bli satt i gang. Selv om dette ikke stemmer overens med tidligere forskning, sier heller ikke Henfridsson og Bygstad eller Grisot et.al. noe som hvor omfattende de innovative endringene bør være når de besluttes lokalt. I store komplekse prosjekter er endringene gjerne svært omfattende og dekker store deler av organisasjonene som de blir gjennomført i. I slike tilfeller vil det antageligvis være vanskelig å gjøre slike beslutninger lokalt, da beslutningen også vil omfatte flere av avdelingene i organisasjonen. Ved å gjøre slik som Henfridsson og Bygstad foreslår vil man risikere at enkelte avdelinger begynner å ta beslutninger på vegne av andre avdelinger, hvor det potensielt ikke vil bidra til innovasjon. På denne måten risikerer man at beslutninger som er tatt på bakgrunn av en avdelings behov og ønsker, kan sette begrensinger for en annen. For at beslutninger for gjennomføring av prosjekter med innovasjon skal kunne gjøres lokalt uten at det er med på å sette åpenbare begrensinger for andre deler av organisasjonen, kan man benytte en polysentrisk ledelsestilnærming (Barrett og Constantinides 2014). På denne måten kunne man delt opp organisasjonen på en måte som bidrar til at man kan ta lokale beslutninger for tilrettelegging uten at det påvirker mer enn det området man har «beslutningsrett» for. Med bakgrunn i denne studien og hvor omfattende prosjektene var, ville det ikke være mulig å benytte Henfridsson og Bygstads (2013) funn direkte uten en strengt definert struktur for hvem som kan beslutte hva i de ulike tilfellene. Dette fordi innovasjonen man da potensielt skaper, høyst sannsynlig vil ha en negativ effekt på andre deler av organisasjonen. Om derimot prosjektet man vil gjennomføre er lite og kun omfatter det området man har beslutningsrett for, mener jeg at lokale beslutninger kan være vellykkete. Dette fordi denne typen prosjekter ikke har den samme kompleksiteten som prosjektene som er undersøkt i denne studien, og antageligvis vil ligne mer på tradisjonelle prosjekter. Sett i et perspektiv av store komplekse prosjekter som går på tvers av organisasjonen, vil det derimot ikke være hensiktsmessig å ha lokal beslutningsevne for gjennomføring av prosjekter for innovasjon, fordi man ikke får den ønskede oversikten som man trenger for å koordinere alle delene av organisasjonen, slik at man får et resultat som er tilpasset majoriteten av brukergruppene. Et annet viktig poeng for hvorfor prosjektene ble besluttet sentralt, til tross for at de ville kunne føre til innovasjon, var fordi behovet for prosjektgjennomføring

90 78 KAPITTEL 7. DISKUSJON ble oppdaget sentralt i organisasjonene. Et eksempel på dette er Prosjekt B, hvor det ikke ble oppfattet som noe lokalt behov for innføring av et felles journalsystem, fordi systemene de opprinnelig benyttet løste deres arbeidsoppgaver på en god nok måte. Behovet ble derimot oppdaget sentralt på grunn av dårlig informasjonsflyt på tvers av de ulike enhetene. Til tross for at slike prosjekter vil kunne føre til innovasjon for hver av de ulike enhetene, er det vanskelig å identifisere dette behovet når man ikke ser helheten på tvers av organisasjonen. I tilfeller som dette vil det være utenkelig at beslutningen tas lokalt, fordi behovet mest sannsynlig ikke vil bli identifisert. Dette viser derfor at beslutninger for gjennomføring av prosjekter med innovasjon kan tas lokalt dersom beslutningen kun omfatter det området av organisasjonen man har definert beslutningsrett for. Dette gjelder derimot sjelden for store komplekse prosjekter hvor endringer foregår på tvers av enhetene i en organisasjon, slik at beslutninger for innovasjon i organisasjonen som en helhet bør tas sentralt. Svar på forskningsspørsmål Basert på diskusjonen over kan man si at hierarkisk ledelse bidrar til et vellykket prosjektresultat, fordi det er med på å skape den oversikten man trenger for å kunne styre og koordinere et stort komplekst prosjekt. Bakgrunnen for dette er at store komplekse prosjekter ofte har en mye mer koordinerende rolle enn tradisjonelle prosjekter, fordi de typisk foregår på tvers av enhetene i en organisasjon. På denne måten er det derfor avgjørende med en hierarkisk struktur for å oppnå det rette nivået av styring, slik at man får en strukturert og vel organisert prosjektgjennomføring. Den hierarkiske ledelsen sørger også for at endringene som prosjektet innfører, bidrar til innovasjon i alle enhetene prosjektet omfatter. På denne måten bidrar det til et helhetlig og vellykket resultat for hele organisasjonen, fordi organiseringen av prosjektet tar hensyn til at resultatet skal være så tilpasset de ulike brukergruppene som mulig. Det er også vanlig at behovet for gjennomføringen av et stort komplekst prosjekt kommer fra sentralt i organisasjonen, slik at det er naturlig at prosjektet også styres derfra. I slike tilfeller vil det ikke nødvendigvis anses som et behov lokalt i organisasjonen å fore ta noen endringer, og det er da viktig med en hierarkisk ledelse som kan legge til rette for og opplyse om hvorfor de kommende endringene vil være hensiktsmessige for organisasjonen som en helhet. Ut ifra dette kan man derfor si at hierarkisk ledelse legger til rette for suksess i store komplekse prosjekter, fordi det skaper oversikt og styring på en måte som omfatter og bidrar til å kunne skape innovasjon i hele organisasjonen Oppfølging På bakgrunn av hvordan kontinuerlig oppfølging påvirker det avsluttende resultatet i et prosjekt og hvordan det kan bidra til effektiv kultivering av en II, har jeg

91 7.2. PATTERN MATCHING 79 kommet frem til følgende forskningsspørsmål: Hvordan bidrar kontrollert oppfølging til et vellykket prosjektresultat? Prosjektoppfølging Ettersom den største årsaken til at prosjekter mislykkes er at det ikke er blitt satt realistiske forventninger til hverken prosjektprosessen eller prosjektresultatet (De- Marco 1982, s. 1-4), kan dette være en av årsakene til at majoriteten av prosjektene i denne studien var svært detaljert planlagt og fulgt opp. Flere av prosjektene var relativt kritiske, og det var derfor viktig at resultatet stod til mandatet og at prosjektets gang foregikk i henhold til planene. I et av de mest sikkerhetskritiske prosjektene, ble det tidlig lagt fokus på å sette realistiske forventinger til både det avsluttende resultatet og prosjektets gang. Forventningene ble da satt både ved hjelp av detaljerte planer og nøye beregnede estimater, men også en muntlig kommunikasjon som kunne forklare kunden hva som var realistisk å kunne forvente. I henhold til prosjektledelseslitteraturen benyttes detaljerte planer og realistiske estimater for å få kontrollert oppfølging på et prosjekt og legge til rette for at man ender opp med et resultat som står til det godkjente mandatet (Office of Government Commerce 2009, s. 101). Dette samsvarer godt med funnene som ble gjort i denne studien, da majoriteten av prosjektene ble grundig fulgt opp. Bakgrunnen til den kontrollerte oppfølgingen ligger antageligvis i behovet og ønsket om høy kvalitet, noe man best får til dersom et prosjekt får kontinuerlig oppfølging underveis. Ved at et prosjekt kontinuerlig følges opp er det lettere å oppdage uregelmessigheter tidlig i prosjektet, slik at man kan gjøre korrigerende tiltak tidlig og at prosjektet da blir satt tilbake på rett kjøl igjen. Uten denne formen for styring vil det være vanskelig å sørge for at man ender opp med ønsket prosjektresultat. Dette stemmer godt overens med Globerson og Zwikaels(2002, s. 58) resonnement om at styring er den mekanismen som sørger for at både planlegging og gjennomføring gjøres på rett måte. Dette viser også at den kontinuerlige oppfølgingen vil kunne avdekke om planer og estimater er realistiske eller ikke. Dersom prosjektet til enhver tid henger etter tidsplanene til tross for god oppfølging, kan det være et tegn på for stramme planer og/eller optimistiske estimater, slik som i Prosjekt A. I slike tilfeller kan det derfor være hensiktsmessig å gjøre korrigerende tiltak slik at forventningene blir mer realistiske (DeMarco 1982, s. 1). I henhold til DeMarco(1982, s. 3) kan man ikke kontrollere det man ikke kan måle, noe som derfor gjenspeiler viktigheten av å ha konkrete planer for å kunne følge opp et prosjekt. Dette var noe alle informantene var enige i, men fokuset lå i all hovedsak på planer som den styrende enheten i et prosjekt og ikke på estimatene. Årsaken til dette kan ligge i at flere av prosjektene var ganske store og at informantene i studien hadde et overordnet og koordinerende ansvar. På denne måten hadde de kanskje ikke den samme direkte kontakten med for eksempel programmerere eller andre personer med mer utøvende roller i prosjektet, som vanligvis står for estimeringen.

92 80 KAPITTEL 7. DISKUSJON Ut ifra dette kan man derfor si at det er godt samsvar mellom litteratur og empiri, ved at kontrollert oppfølging av et prosjekt bidrar til et vellykket prosjekt resultat. Kultivering I henhold til II-litteraturen kultiveres en II på best mulig måte ved hjelp av kontinuerlig oppfølging. Dette stemmer godt overens med funnene fra denne studien, hvor det viser seg at i flere av de undersøkte casene ble det lagt vekt på å dyrke de sidene ved prosjektresultatet som viste seg å være spesielt vellykket. Noe som ikke samsvarer med litteraturen er hvordan Grisot et.al.(2014) og Hanseth og Aanestad(2003) beskriver hvordan mobilisering av brukere og bootstrapping brukes til å få nye brukere til å ta i bruk ny funksjonalitet i et system. Ettersom dette antageligvis, som så mye annet i II-litteraturen, er basert på internett som en II, vil det være frivillig for brukerne å ta i bruk den typen endringer som forekommer ved kultivering. I en organisasjons- eller bedriftssammenheng er brukerne i mye større grad pålagt å benytte et gitt sett av systemer for å gjøre arbeidsoppgavene sine. På denne måten er det svært få av systemene de har tilgjengelig som er valgfrie å benytte, i motsetning til andre mer åpne IIer. Dette viser derfor at graden av mobilisering og bootstrapping ikke vil være like synlig i organisasjoner som er brukt i denne studien, fordi ledelsen i mindre grad trenger å jobbe for å motivere brukerne til å ta ny funksjonalitet i bruk. Derimot kan jeg se for meg at kunnskaper om mobilisering og bootstrapping kan være nyttig dersom man ønsker å eksperimentere med nye funksjonaliteter i en organisasjon. Ved et eksperiment som dette kan man fokusere på å motivere brukerne til å ta funksjonaliteten i bruk og deretter kan gruppen som tester løsningen først, avgjøre om den er verdt å implementere permanent. På denne måten vil ikke brukerne «tvinges» over i nye systemer slik det ofte gjøres når organisasjoner innfører et nytt system eller en ny funksjonalitet, slik at de brukerne får være en del av kultiveringen av organisasjonen. Den egenskapen som derimot står mest sentralt knyttet til kultivering av organisasjonene i denne studien, er læring(grisot, Hanseth og Thorseng 2014, s ). Ettersom det i flere av prosjektene tok høyde for fremtidige endringer, var det derfor et fokus på å hele tiden identifisere hvilke deler av prosjektresultatet som fungerte spesielt godt, men også de delene som ikke var like vellykkete. Et godt eksempel på dette er Prosjekt C hvor fundamentet for prosjektresultatet var å hele tiden utvikle og tilpasse den nye driftssenterløsningen. Dette stemmer godt overens med det Grisot et.al(2014) beskriver som kjernen av kultivering, ved at man til enhver tid jobber mot å forbedre IIen. Til tross for at prosessorientering også er et viktig trekk ved kultivering, vil jeg på bakgrunn av funnene i denne studien ikke anse den som like sentral som egenskapen om læring. Bakgrunnen for dette ligger i at det ikke virket som at noen av prosjektene hadde som hensikt å være spesielt forsiktige når det kom til kultivering av IIen. Fokuset lå derimot på å innføre funksjonalitet som ville skape verdi for både brukerne og organisasjo-

93 7.2. PATTERN MATCHING 81 nene som en helhet, uten noen bekymring for at noen faktisk ville ta endringene i bruk. Dette viser tilbake til mobilisering og bootstrapping, noe som derfor kan bety at prosessorientering for kultivering av IIer, kanskje ikke er like gjeldene i organisasjoner som er tydeligere avgrenset enn for eksempel internett. På bakgrunn av dette kan man derfor si at kontinuerlig oppfølging og fokus på å hele tiden forbedre IIen, allerede under gjennomføringen av prosjektet, vil kunne bidra til et vellykket prosjektresultat så vel som en smidig og fleksibel II. Svar på forskningsspørsmål Basert på diskusjonen over kan man si at kontrollert oppfølging av et prosjekt tilrettelegger for et vellykket prosjektresultat. Ettersom planene man benytter som referansepunkt for oppfølgingen er basert på kundens forventinger og krav til produktet, vil dette bety at dersom man følger opp planene kontinuerlig i prosessen, vil man ende opp med et vellykket prosjektresultat. Likevel skal det legges ved at for å kunne følge opp et prosjekt på en effektiv måte, er man avhengig av at man har gode planer og realistiske estimater å forholde seg til. På denne måten er man derfor avhengig av planene for at oppfølgingen skal kunne bidra til et vellykket resultat. Oppfølgingen av prosjektresultatet som en del av IIen, vil foregå etter prosjektets gang, men evnen til kultivering vil likevel være påvirket av planene og oppfølgingen av prosjektet. Dette viser denne studien ved at de casene hvor det var best muligheter for kultivering, var kultivering en del av grunnmuren til prosjektresultatet. Dette viser derfor den tette tilknytningen mellom planer og oppfølging, ved at planene beskriver hvordan noe til slutt skal se ut og at oppfølgingen sørger for at dette skjer. Samtidig bidrar oppfølging av IIer til dyrking av nye planer ved at nye behov og muligheter for innføring av forbedringer identifiseres. Ut ifra dette kan man si at kontrollert oppfølging bidrar til et vellykket prosjektresultat og prosjektgjennomføring, fordi det både bidrar en form for styring som sørger for at planer følges, men også at oppfølging av IIer kan gi opphav til nye planer som igjen kan skape vellykkete endringer forbedringer av IIen Svar på problemstilling Med forankring i funnene fra diskusjonen, vil disse kunne brukes til å svare på studiens overordnede problemstilling: I hvilken grad kan II-teorien supplere, eventuelt erstatte, tradisjonell prosjektledelsesteori i store komplekse prosjekter? I henhold til koordinerende standarder, viser denne studien at standarder ene og alene ikke vil kunne bidra til hverken en mer vellykket prosjektgjennomføring

94 82 KAPITTEL 7. DISKUSJON eller prosjektresultat. Både prosjektledelses- og II-litteraturen påpeker at en standard må tilpasses sine omgivelser for at den skal være verdiskapene for brukerne den omfatter (Office of Government Commerce 2009; Braa, Hanseth, Heywood, Woinshet og Shaw 2007). II-litteraturen legger også stor vekt på viktigheten av å forstå omfanget av en standard og hvordan den påvirker brukerne den omfatter (Hanseth og Monteiro 1997). Ut ifra dette kan man si at II-litteraturen supplerer til prosjektledelseslitteraturen med teori om at standarder må tilpasses i store komplekse prosjekter på en måte som tar høyde for at standarder er sosiotekniske aktør-nettverk og ikke er rene tekniske enheter. Sett i lys av planer viser denne studien at detaljerte planer vil bidra til både en vellykket prosjektgjennomføring og prosjektresultat (Cadle og Yeates 2004). IIlitteraturens bidrag til prosjektledelseslitteraturen vil i denne sammenhengen være at de detaljerte planene må omfatte fleksibilitet i prosjektresultatet, slik at det legger til rette for videre vekst og kultivering av IIen (Hanseth og Lyytinen 2010). For ledelse av store komplekse prosjekter, viser denne studien at en hierarkisk prosjektstruktur skaper god oversikt som bidrar til å kunne gjennomføre et vellykket prosjekt (Office of Government Commerce 2009; Cadle og Yeates 2004). Dette strider mot det meste av II-litteraturen som sier at beslutninger om denne typen prosjekter bør gjøres lokalt i organisasjonen (Henfridsson og Bygstad 2013). Ettersom disse teoriene ikke beskriver innovative endringer som forekommer på tvers av en organisasjon, har ikke II-litteraturen noe å bidra med i tilknytning til organisering av store komplekse prosjekter. For oppfølging av store komplekse prosjekter, viser det seg at styrt oppfølging bidrar til en vellykket prosjektgjennomføring og prosjektresultat (DeMarco 1982). Som et bidrag fra II-litteraturen bør det være en aktiv oppfølging av prosjektresultatet i etterkant av prosjektets avslutning, slik at man kan identifisere hvilke deler av prosjektresultatet som kan videreutvikles og hva som eventuelt bør tas bort (Grisot, Hanseth og Thorseng 2014). På bakgrunn av dette kan man si at II-litteraturen kan supplere til prosjektledelseslitteraturen innenfor kategoriene prinsipper for koordinering, plan og oppfølging. Likevel står den tradisjonelle prosjektledelseslitteraturen sentralt selv i store komplekse prosjekter, men at innspill fra II-teorien kan bidra til et mer tilpasset prosjekt. Dette viser derfor at de aller fleste konseptene fra tradisjonell prosjektledelse også vil kunne benyttes i store komplekse prosjekter, men dersom man supplerer med enkelte av konseptene fra II-litteraturen, vil man kunne ende opp med et prosjekt som er mer tilpasset komplekse omgivelser enn hvis teoriene ikke blir benyttet. På denne måten kan man derfor si at II-litteraturen ikke kan erstatte den tradisjonelle prosjektledelseslitteraturen, fordi den ikke vil skape den samme graden av overordnet oversikt som er så sentral i ledelse av store komplekse prosjekter, men være et fint supplement for å skape økt suksess i store komplekse prosjekter. Som vist innledningsvis i diskusjonen, viser tabell 7.1 en forenklet og mer konkretisert versjon av svaret på problemstillingen.

95 Kapittel 8 Konklusjon 8.1 Bidrag til prosjektledelseslitteraturen Hovedbidraget med denne oppgaven er en oversikt over hvilke deler av II-litteraturen som kan supplere prosjektledelseslitteraturen ved gjennomføring av store komplekse prosjekter. Bidragene er knyttet til de fire mest sentrale delene av et prosjekt, som er standardisering, planlegging, organisering og oppfølging. Ut ifra dette har jeg kommet frem til at II-litteraturen har følgende bidrag til den tradisjonelle prosjektledelseslitteraturen: Standardisering: For å kunne innføre standarder i store komplekse prosjekter, må man se omfanget av standarden og i hvilken grad den vil påvirke brukerne den omfatter. Ved å gjøre dette vil man kunne forstå hvor kompleks en standard kan være og hvilke mulige konsekvenser som kan oppstå dersom det menneskelige aspektet ikke tas i betraktning (Braa, Hanseth, Heywood, Woinshet og Shaw 2007). Plan: Dersom detaljerte planer skal benyttes ved gjennomføring av et stort komplekst prosjekt, må planverket omfatte fleksibilitet i prosjektresultatet for at det skal bli vellykket (Hanseth og Lyytinen 2010). Oppfølging: Tilrettelegging for oppfølging også i etterkant av et prosjekt vil kunne bidra til kontinuerlig forbedring av prosjektresultatet, fordi man kan dyrke frem de mest vellykkete delene og luke vekk de mindre vellykkete (Grisot, Hanseth og Thorseng 2014). II-litteraturen har ikke noe bidrag til delen om organisering av store komplekse prosjekter. Dette av to grunner, først fordi dataene fra denne studien viser at store komplekse prosjekter bør ha en sentralisert styring og hierarkisk struktur. Den andre grunnen er at studiene jeg har funnet i tilknytning til organisering av endringer i komplekse omgivelser, kun illustrerer lokale endringer som kun omfatter en avgrenset del av IIen (Henfridsson og Bygstad 2013; Grisot, Hanseth og Thorseng 2014). På denne måten er ikke disse studiene dekkende for denne typen prosjekter, 83

96 84 KAPITTEL 8. KONKLUSJON og på bakgrunn av mine funn mener jeg derfor at II-litteraturen i dette tilfellet ikke har noe bidrag. På bakgrunn av dette kan man derfor si at II-litteraturen supplerer med teorier som mer aktivt tar hensyn til det menneskelige aspektet ved gjennomføring av prosjekter og hvordan det er med på å skape økt kompleksitet. 8.2 Hva bidrar til et vellykket prosjektresultat? Som en måte å bygge opp til problemstillingen på, ble den delt opp i fire konkrete forskningsspørsmål som hver og en hadde som hensikt å identifisere hvorvidt standardisering, planlegging, organisering og oppfølging var med på å bidra til et vellykket prosjektresultat. Med dette kom jeg frem til følgende: Standardisering: Standardisering vil ene og alene ikke bidra til at et prosjekt blir noe mer vellykket, men det kan bidra til struktur og oversikt dersom prosjektlederen har erfaringer som gjør at standarden kan tilpasses til det gitte prosjektet. I dette tilfellet viser det seg at det er prosjektlederens erfaringer som er nøkkelen til et vellykket prosjektresultat og ikke bruken av standarder. Plan: Detaljerte planer vil kunne bidra til et mer vellykket prosjektresultat, så lenge fleksibilitet i prosjektresultatet er en del av planverket (Hanseth og Lyytinen 2010). Dette kommer av to årsaker, for det første at planene har som hensikt å reflektere kundens krav, slik at når planer følges bidrar det til at kunden får det han har etterspurt. Det andre er at når fleksibilitet er en del av planverket, bidrar det til at prosjektresultatet kan tilpasses og utbygges på en smidig måte etter prosjektets avslutning. Organisering: Organisering av store komplekse prosjekter bør ha en hierarkisk struktur for å få den oversikten man behøver for at prosjektresultatet skal bli vellykket. Dette for å kunne koordinere prosjekter som går på tvers av enhetene i organisasjonen (Office of Government Commerce 2009; Cadle og Yeates 2004). Oppfølging: Store komplekse prosjekter bør ha en strengt kontrollert oppfølging slik at prosjektlederen til enhver tid kan sørge for at prosjektet leverer et produkt som står til kundens krav og forventinger. På denne måten bidrar kontrollert oppfølging til et vellykket prosjektresultat i store komplekse prosjekter (DeMarco 1982). Med hensyn til forskningsspørsmålene kan det derfor være mulig å påstå at dersom man supplerer med II-litteratur til prosjektledelseslitteraturen i store komplekse prosjekter, vil det være med på å bidra til et mer vellykket prosjektresultat enn om man ikke supplerer. Dette viser også at flere av elementene som supplerer til prosjektledelseslitteraturen også er det som bidrar til at denne typen prosjekter kan bli vellykkete.

97 8.3. EVENTUELLE FORBEDRINGER Eventuelle forbedringer Ved eventuelle forbedringer ved studien, kunne jeg økt validiteten av dataene dersom jeg hadde sendt de detaljerte sammendragene fra hver av casene tilbake til de tilhørende informantene. På denne måten kunne de bekreftet eller avkreftet at jeg hadde forstått informasjonen på rett måte. Ved å gjøre dette ville jeg redusert muligheten for feiltolkninger av informantenes innspill og utsagn. Likevel skal det legges ved at på den tiden hvor jeg hadde sluttført hver av sammendragene, var det lite tid igjen til å sende informasjonen tilbake til informantene for kontroll. I tillegg til dette syntes jeg at jeg allerede hadde fått mye av informantenes oppmerksomhet, ved at hver av dem hadde satt av en til to timer for intervju. På denne måten ville jeg følt det som kravstort å skulle forvente at de leste over tre til fire siders lange sammendrag, for så å gi meg et utfyllende svar på hvilke deler som jeg hadde forstått rett og ikke. Et alternativ for å få informantene til å kunne bekrefte informasjonen på en rask måte, er om jeg hadde utarbeidet et kort spørreskjema med en rekke påstander som enkelt kunne sammenlignes med dataene som var innhentet under datainnsamlingen. Ved å gjøre dette kunne de enten bekreftet eller avkreftet påstandene i lys av prosjektene de hadde gjennomført. På denne måten kunne jeg da brukt dataene fra hver av undersøkelsene og krysskontrollert opp mot sammendragene jeg hadde utarbeidet, og ut ifra dette bekreftet eller avkreftet at jeg hadde forstått informasjonen på rett måte. Dersom jeg ikke hadde forstått informasjonen, kunne jeg antageligvis brukt svarene informantene hadde gitt fra spørreundersøkelsen til å se på dataene fra en ny vinkel og forhåpentligvis forstått hva de egentlig hadde ment å si. En annen mulig forbedring hadde vært om jeg hadde benyttet enda flere caser, slik at datagrunnlaget mitt hadde blitt mer solid. Til tross for at de gjennomførte intervjuene var detaljerte og dyptgående, tror jeg det ville være lettere å generalisere om jeg hadde hatt enda flere caser å jobbe med. Ved kun å basere studien på seks caser, vil det kunne være vanskelig å trekke bombastiske slutninger, fordi jeg ikke vet om casene jeg har valgt er et representativt utvalg for store komplekse prosjekter. Likevel skal det legges ved at dette kun er en masteroppgave, slik at dens omfang setter naturlige begrensninger for hvor mange caser man har tid og plass til. I tillegg tror jeg også at diskusjonen kunne blitt enda grundigere dersom jeg hadde benyttet flere referanser fra tidligere studier. Ved å gjøre dette ville jeg hatt flere kilder til å kunne underbygge påstandene mine, slik at resultatene hadde enda blitt enda mer troverdige. 8.4 Videre arbeid For videre arbeid med denne studien ville jeg foreslå å gjøre en enda mer omfattende datainnsamling med flere antall caser. På denne måten kunne man generalisert mye mer for å kunne avgjøre om funnene jeg har gjort fortsatt er gjeldende. I til-

98 86 KAPITTEL 8. KONKLUSJON legg ville det også kunne være mulig å finne enda flere trekk som karakteriserer et stort komplekst prosjekt. Dette kunne man så brukt til å komme frem til en konkret definisjon, slik at store komplekse prosjekter blir et mer håndfast begrep.

99 Referanser Atkinson, R. (1999). Project management: Cost, time and quality two best guesses and a phenomenon, it s time to accept other success criteria. International Journal of Project Management 17(6), Barrett, M. og P. Constantinides (2014). Information Infrastructure Development and Governance as Collective Action. Information Systems Research (November), Braa, J., O. Hanseth, A. Heywood, M. Woinshet og V. Shaw (2007). Developing Health Information Systems in Developing Countries : the flexible Standards Strategy. Management Information Systems Quarterly 31(Special Issue), Cadle, J. og D. Yeates (2004). Project Management for Information Systems (4 utgave). Gosport: Prentice Hall. Chua, W. F. (1986). Radical Developments in Accounting Thought. Accounting Review 61(4), Cole, M. S. og H. Bruch (2006). Organizational identity strength, identification, and commitment and their relationships to turnover intention: Does organizational hierarchy matter? Journal of Organizational Behaviour 27(5), Crang, M. og I. Cook (2007). Interviewing. I Doing Ethnographies, Kapittel 5, s Great Britain: SAGE Publications. DeMarco, T. (1982). Controlling Software Projects: management, measurement & estimation. New York: Prentice Hall PTR. DeVries, H. J. (2013). Standardization: A Business Approach to the Role of National Standardization Organizations. Springer Science & Business Media. DiCicco-Bloom, B. og B. F. Crabtree (2006). The qualitative research interview. Medical Education 40, Flyvbjerg, B. (2006). Five Misunderstandings About Case-Study Research. Qualitative Inquiry 12(2), Globerson, S. og O. Zwikael (2002). The Impact of the Project Manager on Project Management Planning Processes, Bind

100 88 REFERANSER Greenhalgh, T., S. Hinder, K. Stramer, T. Bratan og J. Russel (2010). Adoption, non-adoption, and abandonment of personal electronic health record: case study of HealthSpace. BMJ 341(c5814). Grisot, M., O. Hanseth og A. A. Thorseng (2014). Innovation of, in, on infrastructures: Articulating the role of architecture in information infrastructure evolution. Journal of the Association of Information Systems 15(4), Hanseth, O. (2000). The Economics of Standard. I C. Ciborra, O. Hanseth, K. Braa, A. Cordella, B. Dahlblom, F. Angelo, V. Hepsø, J. Ljungberg og K. A. Simonsen (Red.), From Control to Drift: the Dynamics of Corporate Information Infrastructures, Kapittel 4, s Oxford University Press. Hanseth, O. og M. Aanestad (2003). Design as Bootstrapping. On the Evolution of ICT Networks in Health Care. Methods of Information in Medicine 42(4), Hanseth, O. og K. Braa (2001). Hunting for the treasure at the end of the rainbow: Standardizing corporate IT infrastructure. Computer Supported Cooperative Work 10(3), Hanseth, O. og B. Bygstad (2014). Generative Information Infrastructure Architectures. A Longitudal Study og ehealth Infrastructure in Norway. (1), Hanseth, O. og B. Bygstad (2015). Flexible generification: ICT standardization strategies and service innovation in health care. European Journal of Information Systems Online Fir(6), Hanseth, O. og K. Lyytinen (2010). Design theory for dynamic complexity in information infrastructures: in case of building internet. Journal of Information Technology 25, Hanseth, O. og E. Monteiro (1997). Inscribing Behaviour in Information Infrastructure Standards. Accounting, Management and Information Technologies 7(4), Hanseth, O. og E. Monteiro (1998). Understanding Information Infrastructure. Hanseth, O., E. Monteiro og M. Hatling (1996). Developing Information Infrastructure: The Tension Between Standardization and Flexibility. Science, Technology & Human Values 21(4), Hanseth, Ole (2014). Design and complexity introduction. http: // inf5210-introduction.pdf. Lest Henfridsson, O. og B. Bygstad (2013). The Generative Mechanisms of Digital Infrastructure Evolution. MIS Quarterly 37(3), Jørgensen, M. (2005). Practical guidelines for expert-judgment-based software effort estimation. Software, IEEE 22(3),

101 REFERANSER 89 McConnell, S. (2006). Software Estimation. Redmond, Washington: Microsoft Press. Milosevic, D. og P. Patanakul (2005). Standardized project management may increase development projects success. International Journal of Project Management 23(3), Monteiro, E., N. Pollock, O. Hanseth og R. Williams (2012). From Artefacts to Infrastructures. Computer Supported Cooperative Work: CSCW: An International Journal 22(4-6), Myers, M. D. (2015). Qualitative Research in Information Systems. Office of Government Commerce (2009). Styring av vellykkede prosjekter med PRINCE2 (2009 utgave). London: The Stationery Office. Orlikowski, W. J. og J. J. Baroudi (1991). Studying Information Technology in Organizations: Research Approaches and Assumptions. Source: Information Systems Research 2(1), Oxford Dictionaries (2015a). Complex. definition/english/complex. Lest Oxford Dictionaries (2015b). Complicated. com/definition/english/complicated. Lest Phil, Roger (2015). Just in time. Lest Project Management Institute (2011). IEEE Guide Adoption of the Project Management Institute (PMI R ) Standard A Guide to the Project Management Body of Knowledge (PMBOK R Guide) (4 utgave). Nr November. Sjøberg, D. I. K., A. Johnsen og J. Solberg (2012). Quantifying the Effect of Using Kanban vs. Scrum : A Case Study. IEEE Software (September/October), Smeds, R. og P. Haho (2003). Bottom-up or top-down? Evolutionary change management in NDP processes. International Journal of Technology Management 26(8), Sommerville, I. (2011). Software Engineering (9 utgave). Boston, Massachusettes: Pearson Education Inc. Stacey, R. D. (1996). Complexity and Creativity in Organizations (1. utgave). San Francisco: Berrett-Koehler. Stake, R. E. (2005). Qualitative Case Studie. I N. Denzin og Y. Lincoln (Red.), Handbook of Qualitative Research, Kapittel 17, s Sage Publications. Star, S. L. og K. Ruhleder (1996). Steps Toward an Ecology of Infrastructure: Design and Access for Large Information Spaces. Information Systems Research 7(1),

102 90 REFERANSER Tilson, D., K. Lyytinen og C. Sørensen (2010). Digital infrastructures: The missing IS research agenda. Information Systems Research 21(4), Wells, H. (2012). How effective are project management methodologies? An explorative evaluation of their benefits in practice. Project Management Journal 43(6), Whitty, S. J. og H. Maylor (2009). And then came Complex Project Management (revised). International Journal of Project Management 27, Yin, R. K. (1994). Case Study Research: Design and Methods, Bind 5. United States of America: SAGE Publications. Yin, R. K. (2014). Case study research: Design and Methods (Fifth utgave). SAGE Publications.

103 Tillegg A Appendix A Alle intervjuene er bygget opp på en slik måte av de skal kunne bekrefte eller avkrefte alle antagelsene fra det forventede mønsteret. Sammendragene fra alle de gjennomførte intervjuene er derfor bygget opp etter samme struktur som i det forventede mønsteret, for å enklere kunne hente ut funnene fra studien. A.1 Sammendrag Prosjekt A Informanten i Prosjekt A er en prosjektleder med mange års erfaring, men forteller at dette er et av de mest omfattende prosjektene han har ledet. Årsaken til dette er fordi det ikke er et rent teknisk prosjekt, men et prosjekt som omhandler det å forvalte menneskers kunnskap til de rette områdene i bedriften, Kappa. Prosjektets hensikt var å flytte to tredjedeler av Kappa til et indisk selskap kalt Alfa, som en måte for bedriften å senke kostnadene på for å kunne overleve på lang sikt. Kappa er en privat bedrift bestående av omtrent 450 ansatte som leverer datakommunikasjon til bedrifter både i offentlig og privat sektor. Bakgrunnen for prosjektet lå i at bedriften ønsket å kunne øke kvaliteten på de tjenestene de leverer, noe de ikke har hatt nok ressurser eller kompetanse til å gjøre i Norge. De ansatte som tidligere hadde ansvar for disse tjenestene før prosjektet, ble reansatt i Alfa, men ble værende i Norge og fortsatte å gjennomføre de samme arbeidsoppgavene som tidligere. Som en tilrettelegging for de ansatte som ble flyttet, fikk de mulighet til å slutte på dagen da de mottok kontrakt for reansettelse, dersom de ikke ønsket å jobbe for Alfa. Informanten i dette caset er en av fire prosjektledere. Prosjektet er delt inn i tre deler, hvor min informant var leder for en av disse og den fjerde prosjektlederen hadde ansvar for prosjektet i sin helhet. Planleggingen av prosjektet startet i begynnelsen av 2015, men min informant ble satt inn som prosjektleder under sluttforhandlingene og spesifiseringene av avtalen med det indiske selskapet. Dette betyr at informanten ikke tok del i utvelgelsen av leverandør, men hadde ansvar for transisjonsfasen, som gikk fra da kontrakten med leverandøren var skrevet til den fullstendige overføringen av ansatte skulle være ferdig. 91

104 92 TILLEGG A. APPENDIX A Prinsipper for koordinering Prosjektledelse Om det ble benyttet et standardisert prosjektrammeverk, har ikke informanten kjennskap til, men han mener at det er høyst sannsynlig at de har utviklet sin egen prosjektmodell. Dette fordi Platon er et stort selskap med omtrent hundre tusen ansatte som har gjennomført flere lignende prosjekter, og at det derfor ville være naturlig om de utviklet sin egen modell delvis basert på andre standardiserte prosjektrammeverk og sine egne prosjekterfaringer. Likevel observerte han at mange av Platons prosjektdeltakerne virket litt lite rutinerte i bruk av metodikk. Dette var med på å skape en del usikkerhet hos de norske prosjektdeltakerne, fordi de var usikre på hvorvidt de disse hadde de rette kompetansen for gjennomføring av prosjektet. På mange måter kunne det fremstå som at Platons representanter måtte lære seg prosjektrammeverket underveis i prosessen. Informanten ble bedt om å ta stilling til følgende påstand: Standardisert prosjektledelsesmetodikk gir vellykket prosjektresultat". Informantens tanker rundt dette er at bruk av en standardisert ledelsesmetodikk vil sjansen øke for å ende opp med et vellykket prosjektresultat, men at det er viktig at fokuset ligger på prosjektet og ikke nødvendigvis metodikken. Dette fordi man lett kan bli veldig firkantet om man velger å fokusere mer på metodikk enn å benytte sunn fornuft. Han synes at en standardisert prosjektmetodikk er veldig lite verdt om man ikke vet hvordan man anvender den i praksis. Informanten så ingen problemer med å bruke Platons metodikk fremfor en av de kjente best practice metodikkene. Han mener at utfordringen heller var at prosjektdeltakerne ikke hadde utarbeidet dokumentasjon og produkt- og prosessbeskrivelser på samme måte som det ble gjort i Prosjekt A. Dette gjorde derfor at de ble nødt til å jobbe annerledes enn hva de opprinnelig var vant til. Informasjonsinfrastruktur For koordinering og strukturering av prosesser, definerte og innførte prosjektet en rekke standarder gjeldende for både Alfa og Kappa. Standardene ble hentet fra det standardiserte prosessrammeverket ITIL, men selve rammeverket i sin helhet ble ikke innført. Prosessene som ble definert for de tre områdene i bedriften er change, incident og problem. Disse la grunnlaget for det videre arbeidet med å standardisere flere arbeidsprosesser samtidig som de fungerer som et grensesnitt mellom hver av avdelingene, men også innenfor avdelingen de er innført. Standardiseringen av prosessene var en del av målet om å øke kvaliteten på tjenestene som tilbys, fordi det tidligere har vært for mye kunstnerisk frihet blant de ansatte. Først med en enhetlig måte å arbeide på kunne man øke kvaliteten. Informanten ser ikke ulemper ved innføring av disse standardene på lang sikt, og tror heller de ville skape mer orden som gjør at en vil få bedre tid til å utvikle informasjonsinfrastrukturen. På kort sikt tenker han at det kan være frustrerende for enkelte å skulle innrette seg etter definerte rutiner.

105 A.1. SAMMENDRAG PROSJEKT A 93 Plan Prosjektledelse Informanten anser dette som et svært nøye planlagt prosjekt, men informerer ved at det er Alfa som har stått for planleggingen. Dette ble gjort ved at Alfas ansatte utarbeidet alle planer for overføringen av de norske ansatte, mens prosjektlederne i Kappa hadde ansvar for å følge opp og koordinere. Informanten mener at det finnes mange fordeler med en nøyaktig prosjektplan, fordi grundige planer er lettere å følge opp ved at man hele tiden kan ha oversikt over hva som er gjort og hva som gjenstår. En ulempe ved prosjektets nøyaktige prosjektplan er at den til dels var litt for stram. Det ble lagt inn lite slack i planen og derfor tatt lite høyde for uventede hendelser som kan forsinke forløpet. Dette gjorde at de ble nødt til å endre noen av datoene, for å kunne ta seg inn på planer som ikke er blitt gjennomført til prosjektert tid. Informanten synes Alfas prosjektledere kunne vært tydeligere på hvilke områder som hadde høyest prioritet i de ulike periodene, for å kunne avgjøre hvilke deler av planen som var viktigst. På denne måten hadde det vært lettere å vite hvilke aktiviteter som var mest kritiske og hvilke som kunne utsettes. Noe av grunnen til at Alfa har kunnet utarbeide en så stram prosjektplan, tror informanten kan være fordi de har mye erfaring på dette området og derfor har god kjennskap til hva et slikt prosjekt innebærer. Dette er også til hjelp for å identifisere og potensielt eliminerer risikoer ved prosjektet, fordi en erfaren bedrift som Alfa vil kunne ha oversikt over hva som typisk er de vanligste risikoene ved denne typen prosjekter samt at de har planlagt nøye, noe som gjør at gjør så mye som mulig for å identifisere flest mulig risikoer. Informasjonsinfrastruktur Som ved innføring av standarder tror informanten ikke at grundig planlegging vil virke hemmende for bedriftens vekst i etterkant av prosjektet. Her som ved standarder mener han at det vil kunne være med på å skape mer struktur og målrettet vekst. Informanten mener at å grundige planer for god og fleksibel struktur er bra, men at man må passe på at rammene blir så strikte at man ikke får noen frihet. Organisering Dette prosjektet stod litt i en særstilling, fordi det er et skille mellom organiseringen av prosjektet og den daglige driften. Prosjektet ble styrt med streng top-downtilnærming ved at avgjørelsen for gjennomføringen av prosjektet er tatt av ledelsen i Kappa. I tillegg ble prosjektet styrt med en streng hierarkisk kultur, som informanten mener kan knyttes til den hierarkiske arbeidskulturen i India. Det ble lagt stort press på prosjektdeltakerne til enhver tid for å kunne vise prosjektlederne hva de har gjort og det var lite rom for andre til å komme med innspill. I motsetning til dette er Kappa svært opptatt av å ta hensyn til de ansatte i den daglige driften, ved å tilrettelegge for deres arbeidsoppgaver. På denne måten er derfor den daglige driften bottom-up, mens prosjektet var top-down. Informanten tror det er viktig at dette prosjektet styres på denne måten, fordi det er såpass omfattende at det er viktig at prosjektet styres strengt.

106 94 TILLEGG A. APPENDIX A Oppfølging Informanten mener at streng kontroll er avgjørende i dette prosjektet for å sørge for at man kommer i mål. Han synes ikke det er noen ulemper ved dette. Annet Dersom informanten skulle gjennomført prosjektet på en annen måte ville han gitt det mer tid og fokusert mer på kvalitet, fremfor å overholde strenge tidsfrister. Han mener den strenge prosjektplanen til fordel kunne vært litt smidigere slik at de kunne sørget for at resultatet fikk en høyere kvalitet. Dette er ikke mulig med de planene de har i dag. A.2 Sammendrag Prosjekt B Informanten i Prosjekt B har lang erfaring innen prosjektledelse både i offentlig og privat sektor, og har derfor gode kjennskaper til gjennomføring av store komplekse prosjekter. Informanten har også gjennomført flere sertifiseringer innen prosjektledelse som benyttes aktivt i gjennomføringen av prosjektene. Prosjekt B hadde som mål å innføre et felles journalsystem for alle sykehus innenfor en gitt region. Hensikten med dette var å komme nærmere planen om at enhver norsk innbygger har en journal uavhengig av hvilken institusjon han eller hun har vært pasient ved. Slik det har vært før gjennomføringen av Prosjekt B, har en pasient hatt en journal for hver avdeling eller institusjon som han eller hun har vært pasient ved. På denne måten kunne man risikere å ha flere journaler selv innad i ett sykehus. Ved å ha en felles journal vil helsepersonell kunne få et mer helhetlig bilde av pasienten og derfor kunne utføre bedre behandling. Prosjektet ble gjennomført av organisasjonen, Lambda som er ledende i Norden på innkjøp, leveranse og drift tjenester innen helsesektoren. Lambda har omtrent 1300 ansatte og har fokus på å levere fremtidsrettede og effektive løsninger som tilrettelegger for god pasientbehandling. Prosjekt B startet våren 2012 og ble avsluttet høsten 2014 og informanten er en av to hovedprosjektledere i prosjektet. Prinsipper for koordinering Prosjektledelse Prosjektet benyttet en tilpasset variant av PRINCE2 som prosjektledelsesmetodikk, for økt kontroll og konsistens. Informanten mener det er nyttig å benytte en velutprøvd og kjent metodikk for å sørge for at prosjektet er vel planlagt samt at planene følges. Med dette kan man derfor si at informanten stiller seg bak påstanden om at en standardisert prosjektledelsesmetodikk gir et vellykket prosjektresultat, men at metodikken må tilpasses hvert enkelt prosjekt.

107 A.2. SAMMENDRAG PROSJEKT B 95 Informasjonsinfrastruktur Ved innføringen av journalsystemet ble det innført en det en hel del standarder for å sørge for at pasientdata samles inn på en og samme måte. Journalsystemet skal være generisk, men på samme måte være tilpasset de ulike avdelingene på hver av sykehusene. For å få til dette gjennomførte de prosjektet mange grundige intervjuer for å sørge for at alle ble blitt hørt. Ved å utarbeide et system på denne måten, sørger man for at det innføres et standardisert system som er tilpasset sine bruksområder. Informanten tror derfor at journalsystemet ikke vil være begrensende ved senere anledninger fordi, det er så godt tilpasset brukerne av systemet. Informanten nevnte også at det kontinuerlig innføres ny teknologi i helsesektoren, som hver ofte har sine egne journalsystemer. Utfordringen da er å avgjøre om det er hensiktsmessig å inkludere disse i journalsystemet og i så fall, hvordan. For å avgjøre hvilke systemer som skal integreres fortalte han at det er viktig å skille mellom hvilke systemer som benyttes til behandling og hvilke som benyttes for testing og forskning. Ettersom forskningsrelaterte systemer ikke nødvendigvis er direkte tilknyttet vanlig pasientbehandling, vil det derfor være slik at de ikke skal inkluderes i journalsystemet før de eventuelt inngår som en del av pasientbehandlingen. Journalsystemet er utarbeidet på en smidig måte som gjør det mulig å innføre nye systemer slik at man ikke begrenser videre vekst. Plan Prosjektledelse Prosjekt B var et grundig planlagt prosjekt med gjennomføring av et forprosjekt i forkant av hovedprosjektet. Informanten mener det er viktig at prosjektet er grundig planlagt for å sørge for at journalsystemet er så tilpasset brukerne som overhodet mulig. Utforming og innføring av et så stort og omfattende system ville være vanskelig om det ikke var grundig planlagt. Ettersom prosjektet var svært kostbart, er det derfor viktig med grundige planer slik at man ender opp med ønsket resultat og at man ikke overstiger et allerede stort budsjett. Informanten påpekte også at det er viktig med nøyaktige planer for å kunne følge opp prosjektet så godt som mulig, men det gjelder å finne en balanse for å ikke henge seg opp i unødige detaljer. Ettersom prosjektets oppbygning ble basert på PRINCE2 sin prosjektmodell, betyr dette at prosjektlederne har vært nødt til å planlegge for å identifisere så mange risikoer som overhodet mulig, da dette er en av grunnsteinene i prosjektrammeverket. Informasjonsinfrastruktur Informanten fortalte at de grundige planene mest sannsynlig ikke vil hemme fremtidig vekst, fordi journalsystemet er bygget opp på en fleksibel måte som tilrettelegger for endring og tilpasning. Ettersom journalsystemet er et stort system som skal tilpasses mange ulike brukere som er plassert på ulike steder, er det hensiktsmessig med en grundig plan for utforming for å sørge at systemet er så smidig og tilpasset som mulig. Selv om planene for utarbeidelse av journalsystemet var strenge i Prosjekt B, mener derfor informanten at planene er strenge for å kunne utvikle

108 96 TILLEGG A. APPENDIX A en funksjonell løsning og ikke en som er stiv og begrenset. Organisering Prosjektledelse Prosjekt B ble styrt med en top down ledelsestilnærming for økt kontroll og konsistens i prosjektet. Årsaken til at prosjektet ble organisert på denne måten var fordi samkjøring av innsamling av pasientdata gjøres på tvers av både sykehus og avdelinger, og det var derfor hensiktsmessig med en slik ledelsestilnærming for å kunne koordinere alle aktørene. I tillegg til dette kom behovet for innføring av et felles journalsystem fra sentralt i sykehusledelsen, noe som gjorde det naturlig å lede prosjektet deretter. Til tross for at selve prosjektet ble ledet med en top down ledelsestilnærming, har brukerne mye å si i forhold til prosjektresultatet. Dette betyr at selve prosjektet er ledet top down, men input for prosjektresultatet er hentet bottom up. Oppfølging Informanten mener at nøye oppfølging er essensielt for å kunne komme i mål med et så stort og omfattende prosjekt. A.3 Sammendrag Prosjekt C Informanten i Prosjekt C har jobbet mange år i organisasjonen, Beta, som prosjektet gjennomført i, men dette er det første prosjektet han har ledet. Han har vært med på å bygge opp gruppen som jobber med førstelinje support i organisasjonen i dag og har nå hatt ansvar for prosjektet som skulle reorganisere strukturen i førstelinjen for å gi økt kvalitet på brukerstøtte ved hjelp av bedre samarbeid på tvers av grupper og seksjoner. Beta er en statlig IT-organisasjon med omtrent 200 ansatte fordelt på tre avdelinger som igjen er delt inn i ni seksjoner. Organisasjonen har lange tradisjoner innen drifting av systemer, og det er i all hovedsak dette de gjør mest. Likevel gjennomfører de en rekke prosjekter både in-house og mot kunder utenfor organisasjonen som kan være alt fra utvikling av en mindre web-basert tjeneste til innføring av nytt epost- og kalendersystem. De siste årene er det blitt gjennomført flere effektiviseringsprosjekter lignende Prosjekt C, for å kunne forbedre fleksibiliteten i Beta og øke kvaliteten på tjenestene de leverer. Slik Beta er organisert i dag, finnes det markante skiller mellom første-, andreog tredjelinjesupport, noe som gir lite flyt og fleksibilitet på tvers av linjene. Prosjektets hensikt er derfor å gjøre disse skillene mindre synlige ved å innføre et driftssenter. Driftssenterets oppgave er å tilrettelegge for læring og samarbeid på tvers i organisasjonen, for å sørge for at brukeres henvendelser blir fulgt av den samme gruppen mennesker fra start til slutt. Som forarbeid til prosjektet ble det sett på andre eksisterende og vellykkede driftssentre i andre organisasjoner, slik

109 A.3. SAMMENDRAG PROSJEKT C 97 som Hydro og NRK. Det var i tillegg ønskelig å tilrettelegge for bedre overføring av tjenester, slik at det frigjøres ressurser i driftsavdelingene ved at den operative driften overføres til driftssenteret. Prosjektet har i alt fire prosjektledere, hvor min informant er en av disse og er ansvarlig for prosjektet i sin helhet. For å skape konsistens i prosjektet er det delt opp i tre underprosjekter og min informants oppgave har derfor i stor grad vært å koordinere disse. Underprosjektene omfatter etablering av driftssenterlokale, opprettelse og utarbeidelse av hjemmevaktordning, gjøre endringer i saksbehandlingssystem som understøtter driftssenterets behov og føringer, og utarbeidelse av avtaleverk for tjenesteoverføring. Prinsipper for koordinering Prosjektledelse I prosjektet ble det benyttet et standardisert prosjektrammeverk som er Betas egen prosjektguide. Rammeverket er basert på Difis prosjektveiviser, som igjen er basert på prosjektstandarden PRINCE2. Når prosjekter gjennomføres i organisasjonen, er det som regel alltid dette rammeverket som benyttes, men informanten fortalte at organisasjonen ikke har som hensikt å pålegge prosjektlederne bestemte rammeverk dersom disse ikke er passende. Han sa at prosjektene ofte står fritt til å velge andre metodikker dersom dette er mer passende for det enkelte prosjektet. Selv om Beta har utarbeidet sin egen prosjektguide, blir også denne tilpasset til hver av prosjektene, noe som gjør at de har et fleksibelt og tilpasningsdyktig rammeverk. Likevel tror han ikke nødvendigvis at et standardisert prosjektrammeverk vil gi et vellykket prosjektresultat, men at det i veldig mange sammenhenger kan fungere som en støtte og gi struktur i prosjektet. Noe som også vil gjøre at risikoen for at man feiler blir mye mindre. Likevel mener han at det finnes mange gode prosjektledere som ikke nødvendigvis følger metodikker og likevel får gjennomført vellykkete prosjekter, noe som viser at et standardisert prosjektrammeverk ikke kan garantere et vellykket prosjekt. Prosjekt C har vært et prosjekt med høy prioritet, noe som har vært med på å legge stort press på prosjektdeltakerne om å levere til avtalt kvalitet innen rimelig tid. Informanten mener at ledelsen til en viss grad har satt noen urimelige frister for prosjektet, ved at de ikke har vært realistiske i forhold til hvordan prosjektet har utartet seg i praksis. Ettersom prosjektresultatet vil reflekteres tilbake til arbeidet i hele underavdelingen for IT-drift, var det derfor avgjørende å sørge for å overholde kvaliteten fremfor å presse prosjektet på tid. Dette var noe ledelsen fikk bedre forståelse for etter hvert som de ble kjent med kompleksiteten omkring prosjektet og hvor store konsekvenser det ville hatt om ikke kvaliteten ble overholdt. Informasjonsinfrastruktur Det ble innført en hel del standarder under prosjektet både rent tekniske, men også standarder som påvirker handlings- og bruksmønster. Dette er blitt gjort via innføring av prosessrammeverket ITIL, men på samme måte som ved bruk av standardiserte prosjektrammeverk, er dette rammeverket blitt tilpasset organisasjonens

110 98 TILLEGG A. APPENDIX A behov og ønsker. Informanten velger å kalle standardene definerte prosesser, hvor disse prosessene ble utviklet i tråd med den ønskede kvaliteten. Noen av de prosessene som er blitt definert er hvordan saker fra brukere skal mottas og hvordan tjenester skal overføres fra driftsavdelingene til driftssenteret. Ved overføring av tjenester ble det utarbeidet avtaleverk (SLA) (engelsk: service level agreement) for hvordan en tjeneste skal settes i drift og hvordan den kan overføres til driftssenteret. Dette gjør at det stilles krav til tjenesteeierne, slik at tjenester ikke kan overføres med mindre et sett av krav er oppfylt. En av visjonene omkring utarbeidelse av driftssenteret har vært å ikke lenger anse hver tjeneste som en separat enhet, men derimot som en komponent i en helhetlig tjeneste. For å definere den gjensidige avhengigheten mellom driftssenteret og tjenestene, har det vært fokus på å utarbeide en grundig driftsavtale (OLA) (engelsk: operational-level agreement). Til tross for gjennomtenkte og grundige prosessbeskrivelser, tror informanten at disse på lang sikt kan føre til begrensinger for vekst og utvikling av driftssenteret. I enkelte av prosessene det blitt innført strenge retningslinjer, noe informanten tror kan påvirke de ansattes evne til å tenke selv i enkelte situasjoner. Dette fordi det kan bli enklere for enkelte å bare lene seg mot standarden fremfor å gjøre en vurdering av om det er passende for det enkelte tilfellet. Dette kan gjøre en mindre tilpasningsdyktig i enkelte situasjoner. Plan Prosjektledelse Informanten forteller at de brukte omtrent ett år på å planlegge og sette rammene til prosjektet, men at ideen og tanken om å utarbeide et driftssenter er noe organisasjonen har hatt i mange år. Dette skyldtes at førstelinjen tidligere satt plassert sammen med driftsavdelingene, slik at de enkelt kunne samarbeide og stille spørsmål underveis i arbeidet. På denne måten hadde de derfor tidligere en form for driftssenter som hadde mange av egenskapene Prosjekt C ønsket å gjenskape. Forskjellen mellom nåtidens og datidens driftssenter er at gjennom prosjektet vil driftssenteret bli innført med mer konkrete rammer og retningslinjer for hvordan hele strukturen skal være bygget opp. Informanten fortalte at dette er et prosjekt hvor det ikke ble bevilget ekstra midler eller stillinger, slik at prosjektdeltakerne har vært nødt til å finne tid blant sine opprinnelige arbeidsoppgaver. Dette har ført til en del utfordringer for informanten, fordi enkelte prosjektdeltakere han opprinnelig hadde ønsket å ha med i prosjektet, ikke hadde anledning. Når slike ressursavtaler ikke kommer i havn, stopper prosjektet raskt opp. Som en løsning på dette fikk de i flere tilfeller tildelt prosjektdeltakere av ledelsen, slik at prosjektet ikke ble stående på stedet hvil for lenge. Dette mener informanten har vært utfordrende, fordi man risikerer å få tildelt personer med mindre erfaring enn hva som er ønsket i prosjektet. Han tror at dette har kunnet å senke kvaliteten på sluttresultatet av prosjektet, men på grunn av manglende kunnskaper og erfaringer fra enkelte har de kompensert med å jobbe mer enn avtalt for å sørge for en løsning som er god nok.

111 A.3. SAMMENDRAG PROSJEKT C 99 Gjennomføringen av prosjektet ble flere måneder forsinket, men årsaken til dette beskriver informanten er på grunn av mangelen på etablert prosjektgruppe. Dette var i utgangspunktet et risikomoment, fordi det ikke ble tildelt dedikerte prosjektdeltakere eller midler for å dekke dette. Likevel har informanten erfart at grundige planer er svært nyttige da de legger til rette for oppfølging underveis i prosessen. Likevel mener han at det er vanskelig å finne det rette detaljnivået av planene, men at dette er noe man oppdager underveis i prosessen. Informasjonsinfrastruktur For å planlegge for et fleksibelt og smidig driftssenter har de prøvd å ikke bli for detaljfokusert, men heller prøvd å se på helheten. I tillegg til dette har de prøvd å planlegge frem i tid ved å definere tydelige stillingsbeskrivelser, hvem som har disse stillingene på nåværende tidspunkt og lignende. På denne måten kunne de skape en god struktur som forhåpentligvis ikke vil virke begrensende for senere vekst. De prøvde også å være tydelige på hva de faktisk var ute etter å oppnå, for å få klare beskrivelser av hva som er hensikten med prosjektet. Slik prosjektet var planlagt, tror ikke informanten at planene vil være sette begrensninger for fremtiden, fordi arbeidsoppgavene mest sannsynlig ikke vil endres drastisk. Likevel la han ved at selv i etterkant av prosjektet vil det være en løpende prosess som gjør at driftssenteret kan tilpasses underveis, og at hensikten med prosjektet var i all hovedsak å utarbeide en grunnmur for den videre utviklingen. Organisering Prosjektet var styrt bottom up og det var interessentanalysen som la grunnlaget for hele prosjektet, og mange ulike perspektiver ble lagt til grunn for de ulike forslagene for utformingen av driftssenteret. Dette fordi prosjektet og dets resultat ville påvirke store deler av organisasjonen, noe som gjorde det viktig å involvere så mange som mulig. Måten de gikk frem på for å strukturere å organisere interessentenes meninger og oppfatninger på var å utarbeide en skjematisk oversikt. På denne måten ble det mulig å se mønstre for hva som var gjentakende på tvers av seksjonene og gruppene i Beta. Informanten synes det var viktig å kategorisere informasjonen på denne måten, for å kunne gå tilbake til det som var blitt sagt og for å finne tilbake til sin egen argumentasjon når avgjørelser ble tatt. Oppfølging På mange måter var dette et sterkt kontrollert prosjekt, mye på grunn av føringene og presset som ble lagt fra ledelsen. Likevel hadde prosjektgruppen mye frihet til å gjøre de endringen som passet for å få så vellykket prosjektresultat som mulig. Informanten tror at mye av årsaken til dette er den grundige interessentanalysen. Med denne som base for prosjektet hadde de all informasjon som var nødvendig fra interessentene, og på denne måten ble det mulig å gjøre endringer underveis uten at det brøt med sluttbrukernes ønsker og behov.

112 100 TILLEGG A. APPENDIX A Annet Dersom informanten skulle gjort noe annerledes, ville det vært å ha enda tydeligere rammer for prosjektet før de satte i gang. Dette ville gitt dem et enda tydeligere bilde på hvor de ville med prosjektet og hvilke begrensinger som fantes. I tillegg til dette kunne han ønske at han hadde lest seg enda mer opp på prosjektledelseslitteraturen, for å stå sterkere i forhold til metodikken. Likevel refererte han tilbake til at metodikk ikke nødvendigvis gir et vellykket prosjektresultat, men at det kunne vært nyttig å være enda litt mer forberedt. Han tror også at dette kunne gjort at en del av dokumentasjonen hadde kommet på plass tidligere i prosessen, som igjen hadde gjort at prosjektet kunne startet før. A.4 Sammendrag Prosjekt D Informanten fra Prosjekt D er både teknisk prosjektleder og virksomhetsarkitekt, og har derfor bred og lang erfaring fra IT-bransjen. Informanten startet sin karriere innen programvareutvikling og har gradvis beveget seg over i roller innen drift og prosjektledelse. Dette gjør at han har personlige kjennskaper og erfaringer om flere av rollene som inngår i et prosjekt, noe som er fordelaktig i en prosjektlederrolle. Informanten har deltatt i flere store prosjekter, men Prosjekt D er hittil det største og mest komplekse. Informanten beskriver Prosjekt D som et spesielt komplekst prosjekt, på grunn av dets mange aktører og deres tilknytninger til hverandre. Prosjektet var avgrenset, men er en del av en større omstrukturering og effektivisering. På grunn av den høye kompleksiteten kan det derfor være vanskelig å skille prosjektet fra den overordnede omstruktureringen. Dette gir en klar indikator på at Prosjekt D faller innenfor betegnelsen store komplekse prosjekter, fordi det er vanskelig å trekke linjer som avgrenser omfanget av den totale informasjonsinfrastrukturen. Organisasjonen som hadde ansvar for gjennomføring av prosjektet, er en statlig organisasjon med omtrent 50 ansatte. De ansatte har bakgrunn fra ulike fagfelt som gir stor tverrfaglighet, noe som er svært nyttig i prosjekter som Prosjekt D. I tillegg til dette jobbet de tett sammen med andre aktører som var med på å påvirke den totale omstruktureringen. Prosjektet handlet om å omstrukturere og standardisere prosesser som tar for seg meldings- og informasjonsutveksling mellom flere aktører. Dette ble gjort ved hjelp av innføring av et nytt system kalt Gamma. Dette har tidligere foregått over papir, men gjennom Gamma har systemet delvis blitt digitalisert og skal over tid fullt og helt ta over for den papirbaserte løsningen. Man kan dele inn brukerne av Gamma inn i to kategorier: de som benytter Gamma i arbeidssammenheng og de som benytter Gamma i privat sammenheng. For å overholde anonymiteten velger jeg å kalle den første gruppen brukere for brukere og den andre gruppen for kunder.

113 A.4. SAMMENDRAG PROSJEKT D 101 Prinsipper for koordinering Prosjektledelse Det ble ikke benyttet en standardisert prosjektledelsesmetodikk ved gjennomføringen av prosjektet, men derimot en form for smidig metodikk som informanten mener kan minne om scrum. Dette ble gjort ved at prosjektet ble delt opp i flere mindre faser, hvor planleggingen ble gjort i forkant av hver av disse. For å sørge for at de nådde målene sine til tross for manglende metodikk, var det utarbeidet noen grove mål i forkant som fungerte som veiledende holdepunkter. Som bakgrunn for disse var det gjennomført store bruker- og interessentanalyser som kartla hvilken grad av kvalitet som var nødvendig og hvordan systemet best ville fungere. Årsaken til at det ikke ble gjort et bevisst valg av metodikk, var fordi prosjektet i utgangspunktet ble startet som et program bestående av mange mindre prosjekter. Det var derfor ikke naturlig å velge et passende prosjektrammeverk, fordi det i utgangspunktet ikke var ment som et prosjekt. Likevel kan man på mange måter kan man si at de utarbeidet sin egen metodikk basert på prosjektets behov og deltakernes kunnskaper og erfaringer om gjennomføring av prosjekter. Ettersom Gamma inneholder mye sensitiv informasjon, var hovedfokuset i prosjektet kvalitet. For å overholde dette ble det gjennomført grundige risikoanalyser, da det ikke var rom feil som kunne offentliggjøre eller forveksle informasjon. Ved å utarbeide en så sensitiv løsning, mener informanten at det var viktig å ikke la tiden være en avgjørende faktor, men heller la prosjektet ta den tiden det trengte for å kunne levere en løsning med god nok kvalitet. Noe av det som kunne satt kjepper i hjulene for prosjektet var om sensitiv informasjon ble forvekslet eller offentlig publisert. Dette var også en av grunnene til å utvikle systemet smidig, fordi de kunne overholde en bedre kontroll ved å jobbe sekvensielt og sørge for kompromissløs kvalitet gjennom hele prosessen. Informasjonsinfrastruktur Prosjektet innførte en hel del standarder ved innføringen av Gamma som sørger for konsistens og økt sikkerhet i informasjonsutvekslingen. Informanten mener at standardene kan være med på å sette begrensinger for enkelte av kundene ved at bruk av Gamma blir mer utfordrende. Dette gjelder typisk eldre kunder, hvor bruksmønsteret endres fra en velkjent papirbasert til digitalisert løsning. Ved å gjøre dette risikerer man at kunden blir usikker og kan miste tiltro til systemet når han/hun ikke lenger har en fysisk relasjon til det. På en annen side setter standardene informasjonen i system, noe som gjør arbeidet mer oversiktlig for brukerne av Gamma. Dette tilrettelegger for bedre samarbeid på tvers av brukerne ved at den samme informasjonen er oppdatert og tilgjengelig for alle. Selv om det settes strenge standarder for kvaliteten på informasjonsflyten, tror ikke informanten at dette vil begrense videre vekst, noe som blir beskrevet under planer. Plan Prosjektledelse

114 102 TILLEGG A. APPENDIX A Prosjekt D var ikke nøye planlagt i den forstand at det var grundig planlagt i forkant av prosjektprosessen, men var grundig planlagt ved at det ble gjennomført store risikoanalyser for å eliminere risikoer samt at det ble lagt grundige planer for hver fase. Informanten nevnte flere ganger at det han ikke kjenner til, er det som skremmer han. Noe som derfor var et ekstra insentiv for å risikostyre prosjektet for å overholde kvaliteten. Han nevnte at dette var et prosjekt hvor det ikke var hensiktsmessig å legge grundige planer i langt forkant for å ende opp med ønsket resultat. På grunn av den store kompleksiteten, tror informanten at grundige planer hadde kunne virke hemmende for prosjektet. Han legger ved at koordinerende planer derimot er viktigere for å skape struktur og orden i et komplekst nettverk. Informanten mener også at å gjennomføre prosjekter slik som Prosjekt D i stor grad handler om å forventningsjustere både deltakerne i prosjektet og kunden. På denne måten vil det ikke forventes mer enn det man faktisk kan prestere, og kunden og prosjektdeltakerne vil heller ikke bli skuffet fordi de vet hva som er realistisk å forvente etter hver fase eller av sluttresultatet av prosjektet. Informasjonsinfrastruktur Gamma ble i utgangspunktet ikke bevisst planlagt for å utarbeide en smidig og fleksibel løsning, men allerede kort tid etter gjennomføringen av Prosjekt D, ble det oppdaget et behov for å utvide systemet. Ettersom systemet i utgangspunktet ikke var godt planlagt for videre utvidelse, har de blitt nødt til å gjøre noen endringer som gjør at de kan jobbe videre med løsningen. Gamma har også vært nødt til å tilpasse seg andre leverandørers tjenester, samt at de andre leverandørene også har nødt til å tilpasse seg til Gamma. Dette har vært mulig fordi det ble utarbeidet en modul som fungerer som et bindeledd mellom blant annet Gamma og de andre leverandørene sine tjenester. Modulen fungerer også som en sluse for å kontrollere all informasjonen som utveksles mellom de ulike systemene. På grunn av at modulen har en såpass sentral rolle i informasjonsinfrastrukturen, har mange av de andre leverandørenes systemer vært nødt til å tilpasse seg til modulen. Organisering Prosjekt D var styrt i det informanten mener er en kombinasjon av top down og bottom up ledelsestilnærming. Dette ble gjort ved at Gamma ble tilpasset brukere, interessenter og andre aktører som har innvirkning på hvordan det ferdige resultatet bør være. Samtidig kom den formelle forespørselen om gjennomføring av prosjektet fra et ledelsesnivå. Ut ifra dette kan man si at Gamma er utviklet med fokus på brukere av systemet, altså en bottom up tilnærming, mens selve ledelsen og koordineringen av prosjektet er gjort top down. Informanten mener at det er viktig å ha med de rette interessentene gjennom hele prosessen når man gjennomfører et prosjekt på en smidig måte slik som i Prosjekt D. Oppfølging

115 A.5. SAMMENDRAG PROSJEKT E 103 Til tross for at prosjektet ble planlagt underveis i prosessen, betyr ikke dette at hver av fasene ikke var kontrollert. Med et så stort fokus på kvalitet og risikohåndtering, er det avgjørende å ha et visst nivå av kontroll for å ende opp med ønsket resultat. Prosjektet totalt sett har derfor vært nøye kontrollert for å tilrettelegge for brukerne samt å overholde den sikkerheten som er nødvendig for å forhindre at informasjon kommer på avveie. Annet Dersom prosjektet skulle vært gjennomført på en annen måte ønsker informanten at ledelsen i organisasjonen hadde hatt bedre forståelse for viktigheten av å ha rett ressurser tilgjengelig til rett tid. Han kunne derfor ønske at prosjektgruppa hadde åpnet opp for at han kunne si ifra når det var mangel på ressurser og at prosjektgruppa hadde hatt tillit til dette. Informanten påpekte viktigheten av at prosjektlederen føler seg trygg gjennom prosjektet og at prosjektgruppa fungerer som en støtte i stedet for å kun sette krav, slik at det blir et samarbeid. Han kunne også ønske at kompetansepersoner ble værende lenger i prosjektet. Dette ved at kompetansepersoner gjerne ble leid inn for å gjennomføre en jobb, for så å forsvinne ut igjen da jobben var gjort. Informanten mener at dette kan gjøre prosjekter sårbare fordi disse personene senere kan være utilgjengelige, og andre må da settes inn i deres plass. Disse personene må da settes inn i prosjektet, noe som kan ta tid. A.5 Sammendrag Prosjekt E Informanten i Prosjekt E har lang erfaring innen ledelse av IT-prosjekter og har jobbet i organisasjonen Delta i flere år. Han startet sin karriere innen konsulentvirksomhet, beveget seg over i en stilling som CEO og er nå seksjonssjef og prosjektleder i Delta. Han har i all hovedsak ledet rene softwareprosjekter i både store og små bedrifter, og de skiller seg tydelig fra Prosjekt E som er det mest omfattende prosjektet han har ledet. Dette fordi Prosjekt E ikke bare var et rent IT-teknisk prosjekt, da tok også for seg sosiotekniske aktører som gjør det stort og komplekst. Delta er en IT-organisasjon med omtrent 200 ansatte fordelt på tre avdelinger som igjen er delt inn i ni seksjoner. Den fungerer som IT-avdeling for en stor statlig organisasjon, Theta, som igjen består av omtrent 6000 ansatte. Delta har lange tradisjoner innen drifting av Thetas systemer, og det er i all hovedsak dette de gjør mest. Likevel gjennomfører de en rekke prosjekter både in-house og mot kunder utenfor organisasjonen som kan være alt fra utvikling av en mindre web-basert tjeneste til innføring av nytt epost- og kalendersystem. Ettersom det ikke fantes noen vedtatt og helhetlig integrasjonsarkitektur i Theta, hadde prosjektet som mål å utarbeide en felles integrasjonsarkitektur for hele organisasjonen. Det fantes opprinnelig en integrasjonsarkitektur utviklet og benyttet av en seksjon i Delta. Alle har hatt mulighet til å benytte seg av denne, men den

116 104 TILLEGG A. APPENDIX A var hverken helhetlig gjennomført eller vedtatt av IT-organisasjonen. Den fungerte derfor mer som et tilbud i stedet for å være en standard. På grunn av manglende føringer for integrasjon av systemer, har det vært vanlig å benytte leverandørens retningslinjer og forslag. Ved å innføre en felles integrasjonsarkitektur vil man skape mer struktur og oversikt over de systemene som finnes og hvordan de bør integreres med hverandre. Det har vært en svakhet for Theta å ikke ha standardiserte og definerte måter å integrere systemer på, og det ble derfor pålagt fra flere holdt om å gjennomføre prosjektet. Informanten mener utarbeidelse og innføring av en integrasjonsarkitektur er et godt sted å starte for kunne skape mer orden Thetas tekniske arkitektur i sin helhet. Prosjekt E var ikke et stort prosjekt da det var bemannet med totalt seks årsverk, men fordi det påvirket mange av de ansatte i Theta i tillegg til mange tekniske komponenter, ble det et komplekst prosjekt. Prinsipper for koordinering Prosjektledelse For gjennomføring av prosjektet ble Deltas egen prosjektguide benyttet. Denne er basert på Difis prosjektveiviser, som igjen er basert på PRINCE2. Informanten kunne fortelle at måten prosjektet ble gjennomført på var en variant av iterativt fossefall som gir noe mer smidighet enn den tradisjonelle fossefallsmodellen. Dette ble gjort ved at prosjektet i sin helhet benyttet prosjektguiden, mens de som var ansvarlig hver av underleveransene stod fritt til å velge hvordan de styrte hver sitt «underprosjekt». Her var det da vanlig å benytte smidige metodikker fordi hver delleveranse hadde lav kompleksitet. Informanten mener man kan kjøre store komplekse prosjekter med smidig metodikk, men at de fort mister smidigheten fordi det blir så mange elementer at det blir vanskelig å overholde enkelheten fra metodikken. Det er viktig for informanten å bruke velutprøvde prosjektledelsesmetodikk, da han er tilhenger av å benytte teknikker som er bevist at fungerer. Han sa også at det er viktig for Theta at det gjennomføres vellykkete prosjekter fremfor å være kreative knyttet til bruk av metodikk. Likevel tror han ikke nødvendigvis at standardisert prosjektledelsesmetodikk gir vellykket prosjektresultat. Han mener det er viktigere å ha profesjonelle prosjektledere fremfor å fokusere på hvilken metodikk som benyttes, fordi det ikke er metodikken som avgjør hvor vellykket prosjektet er, men hvordan prosjektlederen benytter kunnskapene sine. Informanten understrekte at prosjektledelse er et eget fag som krever mye fokus og trening, men at en prosjektguide kan være veldig nyttig om man er en fersk prosjektleder. Informasjonsinfrastruktur Prosjektet innfører en rekke standarder som pålegger brukerne retningslinjer for hvordan systemer skal integreres i arkitekturen. Informanten mener disse er med på å skape mest orden og struktur og ser veldig få ulemper ved å innføre disse. Dette fordi integrasjonsarkitekturen er så fleksibel at han tror hverken den vil forhindre vekst eller vil være begrensende for brukerne. At integrasjonsarkitekturen skulle

117 A.5. SAMMENDRAG PROSJEKT E 105 være tilrettelagt for videre vekst var et av målene i forkant av prosjektet. En mulig utfordring er de ansatte i Theta som sitter svært isolert og ikke er opptatte av helheten i organisasjoner. For disse kan det kanskje oppfattes som begrensende og unødvendig å utarbeide retningslinjer for integrasjon. Det kan muligens også føles kompliserende for de som tidligere har hatt utfordringer med integrasjon av systemer, men som har funnet en måte å gjøre det på. De da blir nødt til å forholde seg til den nye integrasjonsarkitekturen og på nytt måtte tilpasse seg og endre vanene de har skapt. Likevel mener informanten at disse ulempene er små i forhold til hvilke gevinster en integrasjonsarkitektur vil gi. For å sørge for en så fleksibel arkitektur som mulig hentet de løsninger som er ansett som best pracitce. På denne måten sørget de for å få en arkitektur som var kompatibel med så mange systemer som mulig. Plan Prosjektledelse Prosjekt E er et prosjekt som ble planlagt over lang tid og det ble gjennomført et forprosjekt i forkant som hadde som mål å sette rammer for og kartlegge prosjektets struktur. Mye på grunn av prosjektets kompleksitet, var det vanskelig å planlegge fordi de selv ikke visste hvilken vei prosjektet ville ta. Mye av grunnen til dette tror informanten er fordi det ikke finnes en kultur for gjennomføring av slike prosjekter i Delta, som gjør at de ikke kan hente frem tidligere lignende prosjekterfaringer. Til tross for at Prosjekt E var et nøye planlagt prosjekt, tror ikke informanten at man kan planlegge alt i forkant av et prosjekt som dette. Han mener det bør være en iterativ prosess hvor man planlegger mer etter hvert som man forstår omfanget av prosjektet. I tillegg mener han at man aktivt bør involvere interessenter i planleggingen. Dette gjør det derfor nesten litt på kanten å si at prosjektet ble styrt etter fossefallsmodellen fordi målet med prosjektet var veldig uklart, noe som ble gjenspeilet i planleggingsprosessen. Informanten er i utgangspunktet skeptisk til gjennomføring av rene arkitekturprosjekter, fordi de i seg selv ikke gir noen gevinst. Da det er først når den tas i bruk at gevinsten blir synlig. Han fortalte at mange raskt får store forventninger når et prosjekt som dette gjennomføres, men at de fort blir skuffet fordi de ikke får noe synlig raskt resultat. På denne måten mener han at det heller kunne vært nyttig å knytte innføring av ny integrasjonsarkitektur opp mot et mer konkret prosjekt. Da ville integrasjonsendringen kun vært en del av det totale resultatet og ikke vært i like stort fokus som i dette prosjektet. For å identifisere og eliminere risikoer ble det benyttet tradisjonelle verktøy fra fossefallsmetodikkene, slik som risikoanalyse, interessentanalyser oppfølging av interessenter og en kommunikasjonsplan. Til tross for bruk av alle disse verktøyene tror informanten at det er vanskeligere å gjøre en god risikoanalyse i et prosjekt som dette, fordi prosjektet i seg selv var et stort usikkerhetsmoment. Likevel understreket han at det viktigste er en god kommunikasjonsplan, fordi et prosjekt som dette kan bli litt abstrakt og lite forståelig for veldig mange. Informanten tror prosjektet ble vellykket på grunn av grundige planer, men la

118 106 TILLEGG A. APPENDIX A ved at det er mye man kan planlegge, men at det også er mye som ikke kan planlegges. Dette betyr at et vel planlagt prosjekt ikke nødvendigvis gir vellykket resultat, men at det kan gjøre veien dit tydeligere. Han mener også at prosjektledere som kan avgjøre hvilke detaljnivå på planene som er riktig for det gitte prosjektet, er de som er eksperter innen faget. Informasjonsinfrastruktur At grundige planer kan hemme veksten til Deltas integrasjonsarkitektur, tror informanten er svært lite sannsynlig. Årsaken til dette er at arkitekturen vil være veldig fleksibel og tilpasningsdyktig, samtidig som at de ikke hadde som noe mål å tvinge brukere over til denne løsningen. Måten de planla å få brukere til å benytte integrasjonsarkitekturen var å være åpne og tydelige på hvilke fordeler den ville gi, slik at de får et insentiv til å endre vanene sine slik at det ikke oppleves som tvang. Informanten mener insentiver er den beste måten å overtale mennesker til å endre vanene sine på. Ved innføring av den nye integrasjonsarkitekturen, ble ikke de gamle integrasjonene fjernet og deretter integrert på den nye måten. Informanten mener det hadde blitt altfor dyrt å gjøre det på denne måten, og at hver enkelt systemeier selv må overveie om det er lønnsomt å endre nåværende integrasjoner. Å forberede en slik omstrukturering mener informanten hadde vært et fryktelig komplisert prosjekt å forberede, og tror derfor det er bedre at nye integrasjoner i etterkant av prosjektet begynner å benytte løsningen fremfor å flytte over de gamle. Dette betyr at gammel og ny arkitektur vil leve side om side i lang tid fremover. Han legger likevel ikke skjul på at en slik omstrukturering antageligvis ville gitt tydelige gevinster raskt. Etter en bestemt dato avgjorde prosjektgruppen at integrasjonsarkitekturen var gjeldende og alle ansatte i Theta måtte forholde seg til denne. I enkelte tilfeller finne det likevel smutthull for å omgå arkitekturen, men det må derfor gis en god grunn dersom man ønsker å avvike. Et typisk eksempel er dersom man ønsker å kjøpe inn et system hvor dette systemet er det eneste fornuftige på markedet, men som ikke passer inn i integrasjonsarkitekturen. Organisering Prosjektet ble styrt top down fordi initiativet om gjennomføring av prosjektet kom fra Difi og ledelsen i Theta. Selv om prosjektet hadde fokus på å tilrettelegge for brukerne og videre vekst, mener informanten likevel at prosjektet var top down. Det ble foreslått å synkronisere flere lignende prosjekter i den samme sektoren som Theta befinner seg i, noe IT-direktøren var stor forkjemper for. Informanten mener dette bare ville vært kompliserende og at prosjektet allerede var stort og uoversiktlig nok. Han ser mange fordeler ved å ha en samkjørt arkitektur med flere av aktørene i sektoren, blant annet god informasjonsflyt, men at prosjektet i seg selv hadde blitt for omfattende at det hadde blitt vanskelig å få oversikt. Oppfølging Prosjektet var i utgangspunktet ikke strengt kontrollert fra prosjektlederens og Del-

119 A.6. SAMMENDRAG PROSJEKT F 107 tas side, men fordi de hadde fått tildelt porteføljemidler var dette med på å legge et press om å levere. Dersom prosjektet ikke hadde levert en integrasjonsarkitektur som stod til forventningene, hadde de vært nødt til å betale tilbake de tildelte midlene. Selv om dette var med på å presse prosjektet, kan ikke informanten se noen ulemper ved å kontrollere prosjektet på denne måten. A.6 Sammendrag Prosjekt F Informanten fra Prosjekt F har vært ansatt i organisasjonen Epsilon i omtrent 30 år og har hatt IT-rettede stillinger gjennom hele sin karriere. Han har hatt flere ulike roller gjennom alle disse årene og har blant annet vært driftskonsulent, driftssjef, gruppeleder, IT-sjef og nå nestkommanderende for IT i Epsilon og rapporterer jevnlig til organisasjonens CEO. Til da var dette det mest omfattende prosjektet informanten hadde deltatt i, men er nå prosjektleder i et prosjekt han mener er enda mer komplekst og omfattende. Epsilon er en stor organisasjon med omtrent 2000 ansatte og over medlemmer fordelt over hele landet. Organisasjonen har gjennomgått flere oppkjøp og fusjoner som til slutt førte til en veldig brokete og oppdelt infrastruktur for telefoni. Dette startet som en av faktorene som ble pågangsdrivere for gjennomføring av prosjektet. Med mange ulike softwareløsninger ble det etter hvert vanskelig å håndtere dem rent driftsmessig samtidig som en del av utstyret de hadde, hadde begynt å gå ut på dato og derfor burde byttes. En annen faktor som med på å påvirke gjennomføringen av prosjektet, var at Epsilon tidligere hadde innført Microsofts kommunikasjonssystem, Lync som i dag heter Skype for Business. De hadde tidligere innført Lync med noen få funksjoner slik som chat og skjermdeling, og de hadde derfor et ønske om å fortsette å bruke denne tjenesten ved å utvide med mer funksjonalitet. Funksjonaliteten de ønsket var lyd og video slik at de kunne overføre hele telefonidelen i organisasjonen til Lync. Etter grundige analyser ble det derfor avgjort at organisasjonen ble nødt til å fornye seg og innføre en ny og helhetlig telefoniløsning og Prosjekt F ble derfor satt i gang. Prosjektet ble delt inn i fire deler, hvor en av disse var prosjektet i sin helhet. De tre andre delene tok for seg det organisatoriske knyttet til omstruktureringen, den rene tekniske endringen og innføringen av Lync og selve leveransen av tjenesten fra tjenesteleverandøren, Zeta. Dette betydde også at de hadde fire prosjektledere som alle skulle samarbeide og koordinere hver av delprosjektenes aktiviteter. Mye av bakgrunnen for kompleksiteten i prosjektet, var fordi det angikk alle brukerne i hele Epsilon. Det var et stort inngrep å ta ut kjent teknologi slik som telefoni er og mange ble derfor nødt til å lære seg å bruke et helt nytt system. Det skaper til slutt et veldig komplekst bilde når et nytt og moderne system skal fungere med like stor selvfølgelighet som når man løfter av røret som på en vanlig telefon. Mange var i utgangspunktet komfortable med å benytte Lync som programvare,

120 108 TILLEGG A. APPENDIX A men utfordringen var å bruke det som et aktivt kommunikasjonsmiddel slik som en telefon. Dette var ikke en selvfølgelighet for alle og det var derfor stor forskjell mellom de som forstod konseptet og ikke. Det ble derfor en viktig del av prosjektet å være åpne og forklarende for å få med seg brukerne på endringen. Prinsipper for koordinering Prosjektledelse Ettersom det var Zeta som leverte tjenesten, var det de som i utgangspunktet skulle ta ansvar for planlegging og organisering av prosjektet. Zeta benyttet allerede PRINCE2 som sin standardiserte prosjektledelsesmetodikk og ettersom Epsilon følte seg noe umodne på området, syntes de at dette var en grei løsning. De senere årene har de sett nytten av å innføre standardiserte prosjektledelsesrammeverk og IT-avdelingen i Epsilon har derfor innført PRINCE2 som sin faste prosjektmetodikk. Prosjekt F var det første store prosjektet Epsilon gjennomførte hvor de faktisk benyttet en definert metodikk. Dette opplevdes uvant for enkelte og det ble en bratt læringskurve for de fleste. Informanten mener det er viktig for han å benytte et standardisert prosjektledelsesrammeverk, men likevel at det er stor forskjell mellom teori og praksis. For å gjennomføre et vellykket prosjekt mener han at man trenger god prosjektledelse med mye kompetanse på metodikk, forretningen og det som skal kjøpes inn/ utvikles etc. Først da vil man ha nok kunnskaper til å gjennomføre omfattende prosjekter slik som Prosjekt F. Hovedfokuset i prosjektet var å levere en løsning med høy kvalitet. Informanten synes det ikke ville vært hensiktsmessig å gjennomføre et prosjekt som dette med fokus på enten pris eller tid, og han tror at kvaliteten er viktigere jo mer komplekst prosjektet blir. Informasjonsinfrastruktur Hele løsningen med Lync er standardisert fra leverandørens side og hvordan dette systemet tok over for den tradisjonelle telefoniløsningen, ble også etter hvert en standardisert prosess. Fordelen ved å standardisere prosesser på denne måten er at systemene blir enklere å vedlikeholde. I tillegg mener informanten at standarder gjør det enklere å bygge videre på det man har, i forhold til om prosessene og systemene ikke var standardisert. Her som overalt ellers i et stort komplekst prosjekt, påpekte han viktigheten av å være tydelig overfor hvorfor endringene blir gjort og hvilke fordeler de vil bringe. Til tross for at standarder innføres, er man også avhengig av at brukerne faktisk følger dem, og dette kan man først forvente når de forstår hvorfor endringene er blitt gjort. Informanten påpekte at det er ofte slik at mange ansatte mener at de har spesielle tekniske behov som organisasjonen bør dekke. Dette er utfordrende sett i lys av innføring av standarder, men de fleste er likevel villige til å tilpasse seg mengden. Det er vanskelig for en stor organisasjon som Epsilon å være fleksibel nok til å være tilpasset alle. Mulige ulemper ved standarder som ble innført i Prosjekt F er at man blir bun-

121 A.6. SAMMENDRAG PROSJEKT F 109 det til leverandørens definerte standarder. Man har fortsatt mulighet til å videreutvikle de løsningene som benyttes sett at det er innenfor leverandørens grenser. Dette kan være utfordrende dersom man ønsker å opprettholde et konkurransefortrinn. Likevel ønsker ikke informanten å se på dette som spesielt problematisk, fordi han mener det er mulig å jobbe seg rundt utfordringer som dette. Plan Prosjektledelse Prosjekt F var et nøye planlagt prosjekt og de brukte omtrent ett og et halvt år fra de begynte å planlegge til at kontrakten var signert. Informanten synes at et prosjekt fortjener god planlegging når man først kaller det et prosjekt, og han er derfor lite tilhenger av smidig prosjektmetodikk. I prosjektet var det mange risikoelementer på grunn av den åpenbare kompleksiteten. For å forberede seg på dette utarbeidet de en risikomatrise i forkant av prosjektet som var tilstrekkelig til å håndtere de viktigste risikoene underveis. Likevel lærte informanten i etterkant at denne matrisen var litt i det enkleste laget tatt prosjektet i betraktning. Det ble også ført en logg over risikoer underveis i prosjektprosessen, slik at de på en oversiktlig og tydelig måte kunne håndtere risikoer fortløpende. Til tross for disse tiltakene dukket det fortsatt opp en del uventede hendelser, men på grunn av gode rutiner knyttet til risikohåndtering fant de løsninger relativt raskt. Informanten mener at dette også kunne skyldes at de hele tiden hadde et bevisst forhold til at uventede hendelser kunne oppstå. I tillegg til dette har han tro på at planlegging er nøkkelen til vellykket prosjektgjennomføring, og at deres gode planleggingsrutiner var med på å forberede dem til å håndtere uventede hendelser. Informanten nevnte at det som regel er slik i denne typen prosjekter at man har god kontroll på de store, fundamentale elementene i prosjektet. Men at det ofte er «limet» mellom de store elementene som avgjør i hvilken grad man lykkes å håndtere risikoer. Disse detaljene kan være alt fra reiseruter for ansatte som skal delta i prosjektet eller fergeforbindelser til et område hvor en leveranse skal rulles ut. Suksessfaktoren ligger derfor i å kunne se og gjøre detaljene til betydelige elementer i prosjektet. Hvor mye man faktisk trenger å planlegge i forkant av prosjektet mener han derimot ikke avhenger av størrelsen. Et lite prosjekt kan være viktigere for en organisasjon enn et stort, og man må derfor tilpasse seg til hvert enkelt prosjekt. Ettersom prosjekt F var et viktig prosjekt for Epsilon, var det derfor viktig med grundige planer. Informasjonsinfrastruktur Informanten tror at til en viss grad kan planer virke begrensende på fri vekst dersom man ikke har et bevisst forhold til hvordan planer påvirker ulike faktorer. Et eksempel på dette kan være at man ønsker å bytte ut et system man allerede har med en løsning en annen leverandør tilbyr. Dersom kunden da ikke er tydelig nok på hva han ønsker, risikerer man at man ender opp en tilsvarende løsning som man

122 110 TILLEGG A. APPENDIX A allerede har, men i ny drakt. Det kan være vanskelig å forhindre problemer som dette og det er her informanten mener det er avgjørende at man har kompetente prosjektledere og prosjektdeltakere. At kunden er bevisst er også veldig viktig, da det vil være vanskelig for leverandøren å avgjøre hva kunden trenger. En mulig måte å forhindre å havne i slike feller mener informanten at er å planlegge for å gjøre prosjektdeltakerne bevisste på slike problemer. Dette ble ikke gjort under Prosjekt F, men noe han har sett har vært viktig i senere prosjekter han har deltatt i. Ved innføring av Lync var ikke prosjektgruppen spesielt opptatt av å legge til rette for videre utvikling, fordi det i utgangspunktet var lite rom for tilpasninger i Microsofts produkter. Det viktigste var derimot å utnytte de funksjonalitetene som allerede eksisterte på best mulig måte. Organisering I utgangspunktet mener informanten at prosjektet ble styrt med bottom up ledelsestilnærming, men med forankring i styringsgruppen som bestod av toppledelsen. Sluttbrukerne hadde veldig mye å si for prosjektresultatet ved at den organisatoriske delen av prosjektet var nært knyttet til de ulike regionssjefene i Epsilon. Regionssjefene igjen hadde nær tilknytning til sine underavdelinger og på denne måten var det mulig å ha en dialog mellom sluttbrukerne og prosjektgruppen. Informanten kunne fortelle at denne delen av prosjektet etter hvert ble veldig omfattende. Et viktig poeng ved Prosjekt F er at det som nevnt, angikk alle de ansatte i hele organisasjonen. Dette betydde derfor at til tross for at ledelsen hadde en sentral rolle i prosjektet, ble det ikke bare tatt avgjørelser som påvirket andre, men også dem selv. Så til tross for at initiativet til å gjennomføre prosjektet kom fra toppledelsen, mener fortsatt informanten at prosjektet ble ledet bottom up på grunn av sluttbrukernes deltakelse. Oppfølging Prosjektet var sterkt kontrollert, og til tider litt for kontrollert ifølge informanten, og indirekte tror han dette kan ha begrenset prosjektet noe. Dette oppstod muligens fordi prosjektet var så komplekst, slik at enkelte av prosjektlederne overkontrollerte for å kompensere for manglende oversikt. Likevel mener han at det er vanskelig å treffe akkurat når det gjelder kontroll fordi et prosjekt som dette har med mennesker å gjøre. I tillegg er det personavhengig hvor mye kontroll man synes er hensiktsmessig. Annet I hovedtrekk ville ikke informanten gjort prosjektet på noen annen måte, men han ville gjerne sørget for at roller og ansvarsområder var tydeligere definert tidligere i prosjektet. Dette var ting de hadde antatt ble forstått, noe som skapte en del forvirring. En konsekvens av dette kunne være at de ble sittende og vente på leveranser som ikke kom fordi den som hadde ansvar for den, selv ikke visste det. Utenom

123 A.6. SAMMENDRAG PROSJEKT F 111 dette synes informanten at det var et vellykket prosjekt.

124 112 TILLEGG A. APPENDIX A

125 Tillegg B Appendix B B.1 Intervjuguide Kan du fortelle litt om deg selv? Hvor lenge har du jobbet som prosjektleder? Kan du fortelle litt om hovedtrekkene rundt prosjektet? Hvor lang tid i forkant av prosjektet har dere brukt på å planlegge? Har du ledet lignende prosjekter tidligere? Hvilke? Hvordan skiller dette prosjektet seg fra de tidligere? (Tid? Pris?) Koordinering Prosjektledelse Benyttes det noen form for standardisert prosjektledelsesmetodikk i dette prosjektet? Hvis ja: hvilken og hvorfor akkurat denne? Er det viktig for deg å bruke en velutprøvd metodikk? Hvis nei: Hvorfor ikke? Hvordan sørger du da for å få gjennomført et vellykket prosjekt? Hvordan sørger du for å få dekket alle aspektene av prosjektet (risikovurdering, estimering etc)? Hva tenker du om utsagnet «Standardisert prosjektledelsesmetodikk gir vellykket prosjektresultat»? Informasjonsinfrastruktur I dette prosjektet, innfører dere noen tekniske standarder i bedriften som de ansatte må følge? 113

126 114 TILLEGG B. APPENDIX B Hvis ja: Hva er fordelene og ulempene ved dette? Tror du disse standardene kan sette begrensinger ved en senere anledning? Hvis nei: Hvorfor ikke? Hvordan sørger dere da for at de ansatte jobber mot de samme systemene? Plan Prosjektledelse Er dette et veldig nøye planlagt prosjekt? Hvis ja: Hvilke fordeler vil dette ha? Hvis nei: Hvorfor velger dere å ikke planlegge et så stort prosjekt grundig? Et stort prosjekt som dette har åpenbart mange risikoer, hvor nøye planlegger dere for å identifisere og eventuelt eliminere disse? Hvordan tenker du at et nøye planlagt prosjekt vil tilrettelegge for vellykket resultat i et så omfattende prosjekt som dette? Tror du planleggingsfasen ved prosjekter som dette er viktigere enn i mindre omfattende prosjekter? Tror du at nøye planer gjør det lettere å følge opp et prosjekt? Hvor nøye kan planene være før det blir for nøyaktig? Hvordan finne balansen? Informasjonsinfrastruktur Kan nøye planlegging ved denne typen prosjekter kan virke hemmende for utviklingen av bedriften? Når denne typen prosjekter planlegges, hvor mye vekt legges det på at omstruktureringen skal være fleksibel og lett å videreutvikle? Er dette noe du som prosjektleder legger mye vekt på? Organisering Styres dette prosjektet top-down eller bottom-up? Hva er årsaken til dette valget?

127 B.1. INTERVJUGUIDE 115 Hvor har sluttbrukerne å si i et prosjekt som dette? Oppfølging Den tradisjonelle prosjektlitteraturen mener at et strengt kontrollert prosjekt blir mer vellykket, hva tenker du om dette? Hva er fordelene og ulempene ved et strengt kontrollert prosjekt? Diverse I store komplekse prosjekter, blir man som regel pålagt av bedriften som prosjektleder hvilken metodikk man skal bruke. Hvilket nivå av kontroll og planer synes du personlig er nødvendig prosjekter som dette? Synes du at dere har valgt er nivå som er passende for prosjektet? Hvor strenge retningslinjer har bedriften pålagt deg for styring av prosjektet? Tror du det kunne vært gjort på noen annen måte?

128 116 TILLEGG B. APPENDIX B B.2 Kvittering fra personvernombudet Bendik Bygstad Institutt for informatikk Universitetet i Oslo Postboks 1080 Blindern 0316 OSLO Vår dato: Vår ref: / 3 / BGH Deres dato: Deres ref: TILBAKEMELDING PÅ MELDING OM BEHANDLING AV PERSONOPPLYSNINGER Vi viser til melding om behandling av personopplysninger, mottatt Meldingen gjelder prosjektet: Ledelse av store komplekse prosjekter Behandlingsansvarlig Universitetet i Oslo, ved institusjonens øverste leder Daglig ansvarlig Bendik Bygstad Student Sandra Nilsen Personvernombudet har vurdert prosjektet og finner at behandlingen av personopplysninger er meldepliktig i henhold til personopplysningsloven 31. Behandlingen tilfredsstiller kravene i personopplysningsloven. Personvernombudets vurdering forutsetter at prosjektet gjennomføres i tråd med opplysningene gitt i meldeskjemaet, korrespondanse med ombudet, ombudets kommentarer samt personopplysningsloven og helseregisterloven med forskrifter. Behandlingen av personopplysninger kan settes i gang. Det gjøres oppmerksom på at det skal gis ny melding dersom behandlingen endres i forhold til de opplysninger som ligger til grunn for personvernombudets vurdering. Endringsmeldinger gis via et eget skjema, Det skal også gis melding etter tre år dersom prosjektet fortsatt pågår. Meldinger skal skje skriftlig til ombudet. Personvernombudet har lagt ut opplysninger om prosjektet i en offentlig database, Personvernombudet vil ved prosjektets avslutning, , rette en henvendelse angående status for behandlingen av personopplysninger. Vennlig hilsen Katrine Utaaker Segadal Belinda Gloppen Helle Kontaktperson: Belinda Gloppen Helle tlf: Vedlegg: Prosjektvurdering

129 B.3. SAMTYKKESKJEMA 117 B.3 Samtykkeskjema Forespørsel om deltakelse i forskningsprosjekt Ansvarlig Student ved masterprogrammet Programmering og Nettverk ved Institutt for Informatikk, Sandra Nilsen sandratn@ifi.uio.no Bakgrunn og formål Formålet med studien er å hente inn informasjon om ledelse av store komplekse prosjekter og hvordan ledelse av denne typen prosjekter skiller seg fra mindre og enklere prosjekter. Kjennetegn ved store komplekse prosjekter er at de ofte omfatter effektivisering og omstrukturering av bedrifter, på en slik måte at de ikke bare er rent tekniske, men også sosiotekniske ved at menneskelige faktorer spiller inn. Denne informasjonen skal benyttes i en masteroppgave ved Institutt for Informatikk ved Universitetet i Oslo. Hva innebærer deltakelse i studien? Deltakelsen vil innebære omtrent en times langt intervju og spørsmålene vil være knyttet opp mot prosjekt Dataene vil registreres ved hjelp av notater og lydopptak for å best mulig kunne gjenbruke informasjonen fra intervjuet. Hva skjer med informasjonen om deg? Alle personopplysninger vil bli behandlet konfidensielt, slik at personnavn, bedriftsnavn og andre henvisninger vil anonymiseres både underveis i studien og i sluttrapporten. Dataene vil ikke deles med andre enn studentens veileder, Bendik Bygstad, og ved studiens avslutning vil alle lydopptak og notater slettes. Studien skal etter planen avsluttes 2. mai Frivillig deltakelse Det er frivillig å delta i studien, og du kan når som helst trekke ditt samtykke uten å oppgi noen grunn. Samtykke til deltakelse i studien Jeg har lest og forstått informasjonen og ønsker å delta (Prosjektdeltaker, dato) (Prosjektansvarlig, dato)

130 118 TILLEGG B. APPENDIX B B.4 PRINCE2 Prosessmodell

Presentasjon av veileder for tidligfase BA2015-konferanse

Presentasjon av veileder for tidligfase BA2015-konferanse Presentasjon av veileder for tidligfase BA2015-konferanse 2016-01-26 B A 2 0 1 5 - E N B A E - N Æ R I N G I V E R D E N S K L A S S E Innholdsfortegnelse Introduksjon Bakgrunn Prosjektmodell Faser og

Detaljer

Prosjektoppgave INF3290 høsten 2016

Prosjektoppgave INF3290 høsten 2016 Prosjektoppgave INF3290 høsten 2016 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

Detaljer

Prosjektoppgave INF3290 høsten 2018

Prosjektoppgave INF3290 høsten 2018 Prosjektoppgave INF3290 høsten 2018 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

Detaljer

Prosjektoppgave INF3290 høsten 2017

Prosjektoppgave INF3290 høsten 2017 Prosjektoppgave INF3290 høsten 2017 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

Detaljer

Prosjektoppgave INF3290 høsten 2015

Prosjektoppgave INF3290 høsten 2015 Prosjektoppgave INF3290 høsten 2015 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere som studenter. Samtidig vet vi at aktiv deltakelse i prosjektarbeidet

Detaljer

Prosjektoppgave INF3290 høsten 2017

Prosjektoppgave INF3290 høsten 2017 Prosjektoppgave INF3290 høsten 2017 I kurset INF3290 er prosjektarbeid en viktig arbeidsform. Prosjektoppgaven vil kreve mye av dere. Samtidig vet vi av erfaring at aktiv deltakelse i prosjektarbeidet

Detaljer

UiO-admin prosjektrammeverk & opplæring per V Kort oppsummert

UiO-admin prosjektrammeverk & opplæring per V Kort oppsummert UiO-admin prosjektrammeverk & opplæring per V2016 - Kort oppsummert Prosjektrammeverk og prosjektlederkurs m. eiermodul Små og mellomstore administrative prosjekter Sist endret 21.4.16 EKM Hva er i fokus

Detaljer

Programbeskrivelse. Versjon Program for administrativ forbedring og digitalisering

Programbeskrivelse. Versjon Program for administrativ forbedring og digitalisering Programbeskrivelse Versjon 1.5 28.05.2018 Program for administrativ forbedring og digitalisering Behandlet dato Behandlet av Utarbeidet av 12.02.2018 Programstyret Jan Thorsen 25.05.2018 Programstyret

Detaljer

Profesjonalisering av prosjektledelse

Profesjonalisering av prosjektledelse Profesjonalisering av prosjektledelse Ingar Brauti, RC Fornebu Consulting AS Software2013, IT-ledelse i fremtiden Onsdag 13. februar 2013 ingar.brauti@fornebuconsulting.com I fremtiden vil IT funksjonen

Detaljer

PROSJEKTVEIVISEREN LARS NOKKEN ELIN KRISTINE FJØRTOFT DIFI

PROSJEKTVEIVISEREN LARS NOKKEN ELIN KRISTINE FJØRTOFT DIFI PROSJEKTVEIVISEREN LARS NOKKEN ELIN KRISTINE FJØRTOFT DIFI NOKIOS 27.10. 2015 FINN VEIEN http://lesesal.difi.no/mod/scorm/player.php?a=9& scoid=18&currentorg=org- D2A3C776099E5ED802454C818B1BF9DC&mo de=&attempt=1

Detaljer

PRINCE2 (Projects in Controlled Enviroments) kommer opprinnelig fra Storbritannia, hvor metoden er utbredt i både offentlig og privat sektor.

PRINCE2 (Projects in Controlled Enviroments) kommer opprinnelig fra Storbritannia, hvor metoden er utbredt i både offentlig og privat sektor. PRINCE2 whitepaper PRINCE2 er en anerkjent sertifisering for effektiv prosjektledelse. Metoden er internasjonal, og kan skreddersys og tilpasses de fleste organisasjoner, bransjer og prosjekter. PRINCE2

Detaljer

Introduksjon BETTER PROJECTS THE KNOWLEDGE TO GET YOU THERE

Introduksjon BETTER PROJECTS THE KNOWLEDGE TO GET YOU THERE Utvidet foilsett. Settet inneholder foiler som ikke ble benyttet på presentasjonen. Introduksjon NOKIOS 30.10.2012 PRINCE2 is a registered trade mark of the Cabinet Office The Swirl logo is a trade mark

Detaljer

SSBs rammeverk for prosjekt- og porteføljestyring. DIFIs storsamling 29. januar 2013 Seksjonssjef Marit Rønning

SSBs rammeverk for prosjekt- og porteføljestyring. DIFIs storsamling 29. januar 2013 Seksjonssjef Marit Rønning 1 SSBs rammeverk for prosjekt- og porteføljestyring DIFIs storsamling 29. januar 2013 Seksjonssjef Marit Rønning 1 Behov for forbedret prosjektstyring i SSB 1. Utarbeide en samlet oversikt over prosjektstyringsrutiner

Detaljer

Erfaringsdokumentasjon fra. gjennomførte e-handelsprosjekter

Erfaringsdokumentasjon fra. gjennomførte e-handelsprosjekter Erfaringsdokumentasjon fra gjennomførte e-handelsprosjekter Formålet med vårt samarbeid med Difi Dele erfaringer Øke forståelsen for omfanget av et e-handelsprosjekt Hva kan vi lære av tidligere erfaringer?

Detaljer

Derfor er forretningssystemet viktig for bedriften

Derfor er forretningssystemet viktig for bedriften Innhold Derfor er forretningssystemet viktig for bedriften... 2 Når er det på tide å bytte forretningssystem?... 2 Velg riktig forretningssystem for din bedrift... 3 Velg riktig leverandør... 4 Standard

Detaljer

UiO Saksbehandling og arkiv:

UiO Saksbehandling og arkiv: UiO Saksbehandling og arkiv: Styringsgruppen og prosjektledere roller, interesser, forventninger og samspill 50 minutter med speed-dating og plenumsdialog Sist oppdatert 17.9.2018 av EKM Speed-date 1:

Detaljer

Overordnet planlegging

Overordnet planlegging Overordnet planlegging Betydning av planlegging Prosjektmandat Milepæler Milepælsplan Suksessfaktorer og suksesskriterier Nettverksanalyse Jon Lereim Polfareren Roald Amundsen Flaks er resultat av fremragende

Detaljer

Hvordan håndterer du anskaffelser i IT-prosjekter? Bente Hagelien Mari Vestre Jannicke Klepp Tryggestad Lars Nokken

Hvordan håndterer du anskaffelser i IT-prosjekter? Bente Hagelien Mari Vestre Jannicke Klepp Tryggestad Lars Nokken Hvordan håndterer du anskaffelser i IT-prosjekter? Bente Hagelien Mari Vestre Jannicke Klepp Tryggestad Lars Nokken PROGRAM: Kl. 09.30 Kaffe/te - nettverking Kl. 10.00 Hvorfor har vi laget veilederen?

Detaljer

Sesjon 2 Motiver dine medarbeidere gjennom internkontroll. Mona Stormo Andersen Kai Roger Jensen Hege Brinchmann

Sesjon 2 Motiver dine medarbeidere gjennom internkontroll. Mona Stormo Andersen Kai Roger Jensen Hege Brinchmann Sesjon 2 Motiver dine medarbeidere gjennom internkontroll Mona Stormo Andersen Kai Roger Jensen Hege Brinchmann Hvordan motivere gjennom internkontroll uvant å tenke, lettere å få til! 1. Hva er kontroll?

Detaljer

Tema 1 - Prosjekt som arbeidsform. Hva er et prosjekt? Prosjektets livssyklus

Tema 1 - Prosjekt som arbeidsform. Hva er et prosjekt? Prosjektets livssyklus Tema 1 - Prosjekt som arbeidsform Innledning: I kapittel 1 i KG og kapittel 2 i BHG møter du prosjektbegrepet, typiske kjennetegn ved prosjekter og ulike prosjekttyper. Sentralt er beskrivelsen av prosjektets

Detaljer

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055 UKE 9 Prosesser og prosessmodeller inkludert smidige metoder Gruppetime INF1055 Hva skal vi i dag? Introduksjon til modul B - systemutvikling (kap. 1, 2 og 3) Prosesser og prosessmodeller + smidig utvikling

Detaljer

Introduksjon til 3290

Introduksjon til 3290 Introduksjon til 3290 Magnus Li magl@ifi.uio.no INF3290 29 / 30.08.2017 Gruppetimene Presentasjon og diskusjon av ukens tema, pensum og begreper. Tirsdager 14:15-16:00 Onsdager 12:15-14:00 Dere kan møte

Detaljer

Fra data til innsikt. Om prosjektet

Fra data til innsikt. Om prosjektet Fra data til innsikt DEFINERE FOKUS Om prosjektet De store produksjonsselskapene innen olje og gass må hele tiden strebe etter å effektivisere drift og øke sikkerheten på sine installasjoner. For å støtte

Detaljer

Hvordan lage et suksessprosjekt Prosjekter i drift, 18 november 2013 Timm Sanders Director Consulting. CGI Group Inc.

Hvordan lage et suksessprosjekt Prosjekter i drift, 18 november 2013 Timm Sanders Director Consulting. CGI Group Inc. Hvordan lage et suksessprosjekt Prosjekter i drift, 18 november 2013 Timm Sanders Director Consulting CGI Group Inc. Hvem er jeg? CGI Norway, Director Consulting EVRY Consulting, Vice President, Governance

Detaljer

Risikostyring Intern veiledning

Risikostyring Intern veiledning Risikostyring Intern veiledning Versjon 1.0 Dette dokumentet er basert på «Risikostyring i staten, håndtering av risiko i mål og resultatstyringen», desember 2008 og «Risikostyring og intern kontroll i

Detaljer

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

Detaljer

ELIN-metoden. Elektronisk informasjonsutveksling

ELIN-metoden. Elektronisk informasjonsutveksling ELIN-metoden Elektronisk informasjonsutveksling www.kith.no Hva er ELIN-metoden? Metode for å utvikle gode løsninger og sørge for at de blir tatt i bruk Prinsipper mer enn kokebok Metoden alene kan ikke

Detaljer

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer.

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer. KURSBESKRIVELSE Del 1: Grunnleggende kurs, 3 dager Del 2: Prosjektoppstart med fokus på IT-prosjekter, 2 dager Del 3: Utviklingsfaser innenfor IT integrasjonsprosjekter, 2 dager Del 4: Prosjektavslutning

Detaljer

OM Å LØSE OPPGAVER I PROSJEKT ELLER MIDLERTIDIGE ORGANISASJONER

OM Å LØSE OPPGAVER I PROSJEKT ELLER MIDLERTIDIGE ORGANISASJONER OM Å LØSE OPPGAVER I PROSJEKT ELLER MIDLERTIDIGE ORGANISASJONER BIBLIOTEKSJEFMØTE 15.9.11 Dr. philos HVA ER ET PROSJEKT ELLER EN MIDLERTIDIG ORGANISASJON? EN UNIK OPPGAVE TIDSBEGRENSET HAR ET KLART MÅL

Detaljer

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

UKE 15 Prosjektledelse, planlegging og teamarbeid. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski UKE 15 Prosjektledelse, planlegging og teamarbeid Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski Hva skal vi i dag? Se på oblig 5 Prosjektledelse og teamarbeid (kap. 22) Prosjektplanlegging og

Detaljer

Canon Business Services

Canon Business Services Canon Business Services Utvikle virksomheten din Canon Business Services Kunders endrede adferd påvirker hvordan alle virksomheter må drive i fremtiden, derfor endres måten organisasjoner bygger og selger

Detaljer

HVA ER DET SOM SÆRPREGER DET Å ARBEIDE MED PROSJEKT?

HVA ER DET SOM SÆRPREGER DET Å ARBEIDE MED PROSJEKT? HVA ER DET SOM SÆRPREGER DET Å ARBEIDE MED PROSJEKT? Felles forståelse for prosjekt som metode - en kritisk faktor for prosjektets suksess! Spesialrådgiver Bjørg Røstbø, Prosjektledersamling 20.08.08 Kompetanseutvikling

Detaljer

Estimert lesetid 5 minutter. Bli en god PROSJEKTEIER og ta kontroll over PROSJEKTET.

Estimert lesetid 5 minutter. Bli en god PROSJEKTEIER og ta kontroll over PROSJEKTET. Estimert lesetid 5 minutter Bli en god PROSJEKTEIER og ta kontroll over PROSJEKTET www.adire.no FUndamentet Det er noen grunnleggende prinsipper som gjelder for alle prosjekter - uansett prosjektfaglig

Detaljer

Introduksjon til prosjektarbeid del 1. Prosjektet som arbeidsform Begrep, fundament og definisjoner

Introduksjon til prosjektarbeid del 1. Prosjektet som arbeidsform Begrep, fundament og definisjoner Introduksjon til prosjektarbeid del 1 Prosjektet som arbeidsform Begrep, fundament og definisjoner For å lykkes i konkurransen Er innovasjon viktig Nye produkter, markedsføring, produksjonsmåter, opplæring,..

Detaljer

Forskningsmetoder. INF1050: Gjennomgang, uke 13

Forskningsmetoder. INF1050: Gjennomgang, uke 13 Forskningsmetoder INF1050: Gjennomgang, uke 13 Kompetansemål Forskningsmetoder Hva? Hvorfor? Empiriske forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Systematisk litteraturstudie

Detaljer

INF3290 Takk for nå! Margunn Aanestad og Petter Nielsen

INF3290 Takk for nå! Margunn Aanestad og Petter Nielsen 15.11.2013 INF3290 Takk for nå! Margunn Aanestad og Petter Nielsen Eksamen For å bestå kurset må dere bestå eksamen Følg de formelle kravene Diskuter gjerne, men individuell besvarelse Ikke bruk mye plass

Detaljer

INTRANETT FOR DEN NORSKE KIRKE. Kristine Ekeberg-Andersen, Prosjektleder Kirkerådet Ingebjørg Holm Vogt, Prosjektleder Making Waves

INTRANETT FOR DEN NORSKE KIRKE. Kristine Ekeberg-Andersen, Prosjektleder Kirkerådet Ingebjørg Holm Vogt, Prosjektleder Making Waves INTRANETT FOR DEN NORSKE KIRKE Kristine Ekeberg-Andersen, Prosjektleder Kirkerådet Ingebjørg Holm Vogt, Prosjektleder Making Waves «Vi har troen på at en arbeidskultur med stor grad av kunnskapsdeling

Detaljer

MODUL C Prosjektorganisering og Teamutvikling BETTER PROJECTS THE KNOWLEDGE TO GET YOU THERE

MODUL C Prosjektorganisering og Teamutvikling BETTER PROJECTS THE KNOWLEDGE TO GET YOU THERE MODUL C Prosjektorganisering og Teamutvikling Morten A. Torp Version 1.3 24.08.2017 Organisering av Virksomheter Side 2 Organisering av Prosjekter Typiske kjennetegn for prosjekter: - Har min. 2-3 deltakere

Detaljer

Gruppetime INF3290. Onsdag 23. september

Gruppetime INF3290. Onsdag 23. september Gruppetime INF3290 Onsdag 23. september Dagens plan 1. Gå gjennom ukens artikler a. Reflexive integration in the development and implementation of an Electronic Patient Record system (Hanseth, Jacucci,

Detaljer

Universitetet i Oslo Enhet for lederstøtte

Universitetet i Oslo Enhet for lederstøtte Universitetet i Oslo Enhet for lederstøtte Notat Til: AMU Dato: 16. mai 2019 Orientering om BOTT 1.1 Bakgrunn, hva er BOTT? BOTT-samarbeidet har som formål å styrke de deltakende organisasjonenes evne

Detaljer

Evaluering som prosjektarbeid. Engangsoppgave med gitte betingelser

Evaluering som prosjektarbeid. Engangsoppgave med gitte betingelser Evaluering som prosjektarbeid Engangsoppgave med gitte betingelser Egenskaper ved en evaluering Engangsoppgave Ett bestemt IT-system skal evalueres Skal gi et troverdig resultat Vi skal kunne stole på

Detaljer

VKE Årskonferanse. Hva gjør de beste prosjektvirksomhetene, de som leverer gode resultater hver gang? Halvard Kilde, Adm. dir.

VKE Årskonferanse. Hva gjør de beste prosjektvirksomhetene, de som leverer gode resultater hver gang? Halvard Kilde, Adm. dir. VKE Årskonferanse Hva gjør de beste prosjektvirksomhetene, de som leverer gode resultater hver gang? Halvard Kilde, Adm. dir. Metier OEC Innhold i presentasjonen 1. Dele erfaringer hvorfor feiler for mange

Detaljer

KommITs lederkurs i gevinstrealisering

KommITs lederkurs i gevinstrealisering KommITs lederkurs i gevinstrealisering Økonomiforum i Skien 4. juni 2015 Grete Kvernland-Berg, PA Consulting Group Liza Nienova, PA Consulting Group Plan for dagen 13:30 Introduksjon 13:50 14:20 14:30

Detaljer

Gevinstrealisering i program Felles Infrastruktur og Arkitektur (FIA)

Gevinstrealisering i program Felles Infrastruktur og Arkitektur (FIA) Gevinstrealisering i program Felles Infrastruktur og Arkitektur (FIA) For liten grad av realisering av gevinster i offentlig sektor Forvaltningen gjør enorme investeringer i IKT, men nytteeffektene av

Detaljer

Kontrakter. INF1050: Gjennomgang, uke 12

Kontrakter. INF1050: Gjennomgang, uke 12 Kontrakter INF1050: Gjennomgang, uke 12 Kompetansemål Kontrakter I plandrevet utvikling I smidig utvikling Behov for smidige kontrakter Kontraktsmodeller PS2000 Del I: Kontrakter Grunnleggende: Hva? Plandrevet

Detaljer

UTVIKLINGSSAMTALER SOM FUNGERER En håndbok for HR-avdelingen

UTVIKLINGSSAMTALER SOM FUNGERER En håndbok for HR-avdelingen UTVIKLINGSSAMTALER SOM FUNGERER En håndbok for HR-avdelingen INNHOLDSFORTEGNELSE INNLEDNING Les denne håndboken og bli en ekspert på utviklingssamtaler 3 1. UTVIKLINGSSAMTALER SOM VERKTØY for å skape motivasjon

Detaljer

Studieplan 2017/2018. Verdiskapende prosjektledelse (vår 2018) Studiepoeng: 15. Målgruppe. Opptakskrav og rangering. Arbeids- og undervisningsformer

Studieplan 2017/2018. Verdiskapende prosjektledelse (vår 2018) Studiepoeng: 15. Målgruppe. Opptakskrav og rangering. Arbeids- og undervisningsformer 1 / 5 Studieplan 2017/2018 Verdiskapende prosjektledelse (vår 2018) Studiepoeng: 15 Målgruppe Prosjekt som arbeidsform anvendes i stor utstrekning i dagens arbeidsliv og en forståelse for fenomenet og

Detaljer

Møtedato: 27. februar 2013 Arkivnr.: Saksbeh/tlf: Sted/Dato: Hilde Rolandsen, 75 51 29 00 Bodø, 15.2.2013. forbedringsprosser

Møtedato: 27. februar 2013 Arkivnr.: Saksbeh/tlf: Sted/Dato: Hilde Rolandsen, 75 51 29 00 Bodø, 15.2.2013. forbedringsprosser Møtedato: 27. februar 2013 Arkivnr.: Saksbeh/tlf: Sted/Dato: Hilde Rolandsen, 75 51 29 00 Bodø, 15.2.2013 Styresak 15-2013 Nasjonalt samarbeid om innkjøp og forbedringsprosser Innledning/bakgrunn Bakgrunnen

Detaljer

EVU KURS PROSJEKTERINGSLEDELSE 2014/15

EVU KURS PROSJEKTERINGSLEDELSE 2014/15 EVU KURS PROSJEKTERINGSLEDELSE 2014/15 Formål Formålet med kurset er å kvalifisere deltakerne innenfor fagområdet prosjekteringsledelse (Building Design Management), gi deltakerne en teoretisk bakgrunn

Detaljer

Løsningsforslag oppgavesett 18

Løsningsforslag oppgavesett 18 Løsningsforslag oppgavesett 18 OPPGAVE 1 a) Prosjektets effektmål uttrykker grunnen til at prosjektet er igangsatt, dvs. hvorfor eller hensikten med prosjektet. Det handler om hvilke effekter og gevinster

Detaljer

Etableringsplan. Internkontroll for informasjonssikkerhet og personvern

Etableringsplan. Internkontroll for informasjonssikkerhet og personvern Etableringsplan Internkontroll for informasjonssikkerhet og personvern Innholdsfortegnelse 1 Innledning... 2 2 Formål... 2 3 Informasjonssikkerhet og personvern... 2 4 Etableringsaktiviteter... 3 5 Lenker...

Detaljer

Uke 7. Magnus Li INF /

Uke 7. Magnus Li INF / Uke 7 Magnus Li magl@ifi.uio.no INF3290 17/18.10.2017 Innlevering 1 Innlevering 1 Gjør det enkelt for leser å følge med! - Struktur - Språk - Figurer - Tabeller Et mål er å vise at dere har lest og forstått

Detaljer

Foreløpig innholdsfortegnelse

Foreløpig innholdsfortegnelse Foreløpig innholdsfortegnelse 1. Prosjekter og deres betydning 1.1 Hva er egentlig et prosjekt? 1.2 En moderne prosjektforståelse 1.3 Prosjekters mangfold i arbeidslivet 1.4 Prosjekt er svaret på endringsbehov

Detaljer

The Optimizer - Hvor gode er dere?

The Optimizer - Hvor gode er dere? The Optimizer - Hvor gode er dere? Ville det ikke vært fint om noen analyserte dokumentbehandlingen i ditt firma og fant løsninger for effektivisering og reduserte kostnader? 2 3 Det er akkurat det Konica

Detaljer

Ledelsesprinsipper i nye Stavanger kommune

Ledelsesprinsipper i nye Stavanger kommune Nye Stavanger Klikk her for å skrive inn tekst. Ledelsesprinsipper i nye Stavanger kommune 1. Ledelse Gir det merverdi for innbyggerne at akkurat du er leder i Stavanger kommune? Å finne sin vei som leder

Detaljer

Ledelsen lar stort sett ansatte ta sine egne beslutninger. Ledelsen holder streng kontroll med arbeidet til de ansatte

Ledelsen lar stort sett ansatte ta sine egne beslutninger. Ledelsen holder streng kontroll med arbeidet til de ansatte NOCM Dimensjoner og ledd Autonomi Ledelsen lar stort sett ansatte ta sine egne beslutninger Ledelsen har tillit til at folk kan ta arbeidsrelaterte beslutninger uten å innhente tillatelse først Ledelsen

Detaljer

Prosjektevaluering. Referanse til kapittel 9

Prosjektevaluering. Referanse til kapittel 9 Prosjektevaluering Referanse til kapittel 9 Skjemaet for prosjektevaluering er utviklet etter Erling S. Andersen og Svein Arne Jessen. 2000. «Project Evaluation Scheme». Project Management 6(1), s. 61

Detaljer

Making IT your winning asset

Making IT your winning asset Erfaringer med nyttestyring på styringsgruppenivå i et smidig utviklingsprosjekt Smidig digitalisering 2017 André Vogt, Scienta Making IT your winning asset Klikk for å redigere tittelstil Innhold Kort

Detaljer

Lean IT + ITIL = sant?

Lean IT + ITIL = sant? Lean IT + ITIL = sant? Hva er Lean IT, og hvordan benytte dette i ITIL-miljøer Oslo 30. mai 2012 Monica Strand Seniorkonsulent Steria Steria Hva er Lean? Lean handler om å skape kundeverdi VA Verdiskapende

Detaljer

Endringsledelse i Drammen Taxi BA 2011. Glenn A. Hole

Endringsledelse i Drammen Taxi BA 2011. Glenn A. Hole Endringsledelse i Drammen Taxi BA 2011 Glenn A. Hole Trender i arbeidslivet Organisasjonsutvikling Organisasjonsutvikling er: basert på en planlagt innsats, styrt fra toppen av organisasjonen, som omfatter

Detaljer

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør www.steria.com Stein Aarum Leder for arkitekturfagområdet Steria www.steria.com Innhold Hva vi mener med arkitektur Vår viktigste rolle

Detaljer

Forord Kapittel 1 Prosjektbeskrivelsen Kapittel 2 Bruk av metaforer for å illustrere oppgaveskriving... 16

Forord Kapittel 1 Prosjektbeskrivelsen Kapittel 2 Bruk av metaforer for å illustrere oppgaveskriving... 16 Innhold 5 Forord... 9 Kapittel 1 Prosjektbeskrivelsen.... 11 Kapittel 2 Bruk av metaforer for å illustrere oppgaveskriving... 16 Kapittel 3 Hensikten med å skrive en bacheloroppgave.... 20 Kapittel 4 Råd

Detaljer

Prosjektledelse. Napha konferanse, Gardemoen 11. nov 2011. Kari Hauff. Prosjektleder / Klinisk spesialist psykiatrisk sykepleie

Prosjektledelse. Napha konferanse, Gardemoen 11. nov 2011. Kari Hauff. Prosjektleder / Klinisk spesialist psykiatrisk sykepleie Prosjektledelse Napha konferanse, Gardemoen 11. nov 2011 Kari Hauff Prosjektleder / Klinisk spesialist psykiatrisk sykepleie 1 Hva er prosjekt? Prosjekt = latin prosjectum = kastet frem en utkast eller

Detaljer

Statsansatteundersøkelsen. Temahefte: Opplevelsen av digital tilstand

Statsansatteundersøkelsen. Temahefte: Opplevelsen av digital tilstand Statsansatteundersøkelsen 2018 Temahefte: Opplevelsen av digital tilstand Arbeidet med digitalisering nå og fremover Den digitale utviklingen påvirker virksomhetene i staten og den endrer arbeidshverdagen

Detaljer

Fra teori til praksis

Fra teori til praksis Fra teori til praksis Hvor modne er virksomhetene til å tenke helhetlig styring? Ingar Brauti, RC Fornebu Consulting AS Temamøte nr. 3 NFP 19.9.2014 ingar.brauti@fornebuconsulting.com Torodd Ingar Jan

Detaljer

Tjenesteinnovasjon og gevinstrealisering

Tjenesteinnovasjon og gevinstrealisering Tjenesteinnovasjon og gevinstrealisering Kristin Standal, prosjektleder Nasjonalt program for velferdsteknologi KS forskning, innovasjon og digitalisering «En selvstendig og nyskapende kommunesektor» Når

Detaljer

Lærestiler. Vi mennesker lærer best på ulike måter. Her er fire lærestiler basert på Peter Honey og Alan Mumfords teorier.

Lærestiler. Vi mennesker lærer best på ulike måter. Her er fire lærestiler basert på Peter Honey og Alan Mumfords teorier. Lærestiler Hurtigguider - rammeverk Sist redigert 19.04.2009 Vi mennesker lærer best på ulike måter. Her er fire lærestiler basert på Peter Honey og Alan Mumfords teorier. Marianne Nordli Trainer og coach

Detaljer

Kartlegging av innovasjonstyper

Kartlegging av innovasjonstyper Kartlegging av innovasjonstyper Referanse til kapittel 12 Analysen er utviklet på basis av Keeleys beskrivelse av 10 typer innovasjoner (Keeley, L. 2013. Ten Types of Innovation. New Jersey: John Wiley

Detaljer

Løsningsforslag oppgavesett 2

Løsningsforslag oppgavesett 2 Løsningsforslag oppgavesett 2 OPPGAVE 1 Drøft følgende påstand: Om et prosjekt blir vellykket eller ikke, avhenger først og fremst av god planlegging samt griseflaks. I denne oppgaven kan det gis mange

Detaljer

Konsernrevisjonen Rapport 7/2019. Revisjon av Program for standardisering og IKT-infrastrukturmodernisering (STIM) 2. tertial 2019.

Konsernrevisjonen Rapport 7/2019. Revisjon av Program for standardisering og IKT-infrastrukturmodernisering (STIM) 2. tertial 2019. Konsernrevisjonen Rapport 7/2019 Revisjon av Program for standardisering og IKT-infrastrukturmodernisering (STIM) 2. tertial 2019 Sykehuspartner HF 16. september 2019 1. Introduksjon Revisjonens formål

Detaljer

PROSJEKTVEIVISEREN LARS NOKKEN ELIN KRISTINE FJØRTOFT DIFI

PROSJEKTVEIVISEREN LARS NOKKEN ELIN KRISTINE FJØRTOFT DIFI PROSJEKTVEIVISEREN LARS NOKKEN ELIN KRISTINE FJØRTOFT DIFI NOKIOS 1.11. 2016 FINN VEIEN http://lesesal.difi.no/mod/scorm/player.php?a=9& scoid=18&currentorg=org- D2A3C776099E5ED802454C818B1BF9DC&mo de=&attempt=1

Detaljer

Evalueringsrapporten. Rapporten kunden mottar Sluttproduktet Forteller hva som er gjort

Evalueringsrapporten. Rapporten kunden mottar Sluttproduktet Forteller hva som er gjort Evalueringsrapporten Rapporten kunden mottar Sluttproduktet Forteller hva som er gjort Rapportere og formidle resultatene Lage en sluttrapport som beskriver hele evalueringsprosessen Beskrive prosjektgjennomføringen

Detaljer

Arbeidsgiveres erfaringer med døve ansatte

Arbeidsgiveres erfaringer med døve ansatte Arbeidsgiveres erfaringer med døve ansatte Sluttrapport En undersøkelse av arbeidsgiveres erfaringer med døve ansatte sammenlignet med de døve arbeidstakernes oppfatninger, som grunnlag for tiltak for

Detaljer

Hvordan vi arbeider med søknader i HØKH

Hvordan vi arbeider med søknader i HØKH Hvordan vi arbeider med søknader i HØKH Norges forskningsråd 15. mars 2011 Pål Gulbrandsen Tre ting Vi leser utlysingen grundig Vi tenker og arbeider med søknader over måneder som team Vi jobber med å

Detaljer

Avdekke virksomhetens kunnskap, velge systemet fornuftig og unngå marerittene. ERP ABBATE UK LIMITED 1

Avdekke virksomhetens kunnskap, velge systemet fornuftig og unngå marerittene. ERP ABBATE UK LIMITED 1 Avdekke virksomhetens kunnskap, velge systemet fornuftig og unngå marerittene. ERP ABBATE UK LIMITED 1 CRM, Customer Relationship Management, fokuserer på utvikling og opprettholdelse av stabile kunderelasjoner

Detaljer

Innhold. Forord Innledning... 13

Innhold. Forord Innledning... 13 Innhold 5 Forord... 11 Innledning... 13 1 Hva er et prosjekt?... 17 1.1 Prosjektbegrepet og kjennetegn... 18 1.2 Prosjektkonseptets historie... 22 1.3 Prosjektets livssyklus og faser... 24 1.4 Prosjektgjennomføring...

Detaljer

Innhold. Bruk av boken og hjelpefigurer Hva er egentlig prosjektsuksess? Dere må jobbe etter flere suksesskriterier...

Innhold. Bruk av boken og hjelpefigurer Hva er egentlig prosjektsuksess? Dere må jobbe etter flere suksesskriterier... Innhold Kapittel 1 «Hurra, jeg har blitt prosjektleder!»... 13 Du som prosjektleder... 14 Prosjekter vi ønsker suksess... 16 Prosjekt begreper og prosesser... 17 Prosjektroret hjelp til å navigere ditt

Detaljer

NYTTESTYRING GJENNOM HYPPIGE LEVERANSER OG TVERRFAGLIGE TEAM

NYTTESTYRING GJENNOM HYPPIGE LEVERANSER OG TVERRFAGLIGE TEAM NYTTESTYRING GJENNOM HYPPIGE LEVERANSER OG TVERRFAGLIGE TEAM Prosjekt 2018 7. november 2018 Rune Danielsen Bakgrunn - Om SPK Norges største pensjonsforvalter Forvalter rettigheter for 530 milliarder kroner,

Detaljer

Velkommen til INF3290!

Velkommen til INF3290! 23.08.2013 Velkommen til INF3290! Margunn Aanestad og Petter Nielsen Praktisk om kurset: Forelesinger fredag 12-14 (rom 1416 Smalltalk) Kursansvarlige: Margunn Aanestad og Petter Nielsen Epost: {margunn,

Detaljer

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10

Prosjektledelse, planlegging og teamarbeid. INF1050: Gjennomgang, uke 10 Prosjektledelse, planlegging og teamarbeid INF1050: Gjennomgang, uke 10 Kompetansemål Prosjektstyring og prosjektledelse Hva og hvorfor? Risikohåndtering Ledelse av mennesker og motivasjon Teamarbeid og

Detaljer

Hva er Lean Sterkere effekt av Lean i Bygg-Team Erik J. Holm, Tekna frokostseminar 27. okt 2016

Hva er Lean Sterkere effekt av Lean i Bygg-Team Erik J. Holm, Tekna frokostseminar 27. okt 2016 Hva er Lean Sterkere effekt av Lean i Bygg-Team Erik J. Holm, Tekna frokostseminar 27. okt 2016 REELL PROSESS IDEEELL PROSESS Største utfordringer i større byggeprosjekter? Hvor vil dere ønske dere forbedringer?

Detaljer

Erfaringer fra offentlige anskaffelser

Erfaringer fra offentlige anskaffelser Erfaringer fra offentlige r Oddrun Lyslo Kristiansen og Bjørn Børresen 15.03.2012 20.03.2012 www.a-2.as Om A-2 Oddrun Lyslo Kristiansen, seniorkonsulent, A-2 Bjørn Børresen, seniorkonsulent, A-2 Forretningsområder

Detaljer

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort NCEI Teknologifrokost 25. Mars 2015 Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort Del 1: Are Hellandsvik Forsker ved SINTEF IKT Kommunikasjonssystemer Del 2: Terje Frøysa Forsker

Detaljer

LEAN ER en arbeidsmåte som tar

LEAN ER en arbeidsmåte som tar LEAN ABC Andre utgave INNHOLD HVA ER LEAN LEAN STIKKORD FASER I INNFØRINGSPROSJEKTENE LEAN I DAGLIG DRIFT Lean A B C er under kontinuerlig forbedring K:\Bølgen innføringsprosjekt\verktøykasse 2012\Fra

Detaljer

IDRI3001 Bacheloroppgave i Drift av datasystemer

IDRI3001 Bacheloroppgave i Drift av datasystemer IDRI3001 Bacheloroppgave i Drift av datasystemer Kjell Toft Hansen, 15.04.2015 Bachelor Informatikk Drift av datasystemer Sammendrag Her er noen studiespesifikke retningslinjer for veiledning og vurdering

Detaljer

Bilag 1: Beskrivelse av Bistanden

Bilag 1: Beskrivelse av Bistanden Bilag 1: Beskrivelse av Bistanden Bakgrunn Alle Norges fylkeskommuner og Oslo kommune har gått sammen om anskaffelse av nytt skoleadministrativt system. Vigo IKS er en sammenslutning av fylkeskommunene

Detaljer

Business Intelligence og Datavarehus

Business Intelligence og Datavarehus Business Intelligence og Datavarehus Gode råd på veien Avfall Norge onsdag 16 januar, 2018 Kort om Webstep Webstep hvor er vi? Noen kundeeksempler BI i Webstep 70 teknologieksperter innen det utvidede

Detaljer

Oppfølging av forvaltningsrevisjonsrapport "Næringsutvikling i Hedmark fylkeskommune

Oppfølging av forvaltningsrevisjonsrapport Næringsutvikling i Hedmark fylkeskommune Saknr. 17/7353-1 Saksbehandler: Kari Louise Hovland Oppfølging av forvaltningsrevisjonsrapport "Næringsutvikling i Hedmark fylkeskommune Kontrollutvalgets innstilling til vedtak: Kontrollutvalget legger

Detaljer

Prosjektarbeid og oppgaveskriving

Prosjektarbeid og oppgaveskriving Prosjektarbeid og oppgaveskriving Prosjekt Definisjon og historisk utvikling Prosjekt typer Arbeidsmetodikk Oppgave skriving Tema: Forskjellen mellom åpne og lukkede prosjekter. Hvordan teorien behandle

Detaljer

Business Process Re-engineering (BPR)

Business Process Re-engineering (BPR) 1 Business Process Re-engineering (BPR) Strategirådgiver 2 Business Process Re-engineering BPR konsept og praktisk prosjektledelse Forstå, kommunisere og forankre pågående forbedringsprosjekter Praktisk

Detaljer

Et nytt perspektiv på prosjektledelse

Et nytt perspektiv på prosjektledelse Et nytt perspektiv på prosjektledelse Tiltredelsesforelesning 15. mai 2007 Erling S. Andersen erling.s.andersen@bi.no Erling S. Andersen 1 Hvorfor skal vi være opptatt av prosjekt? En stor del av verdiskapningen

Detaljer

ALPROLED Gruppe_1: Spørsmål 1: Hva skiller et prosjekt fra andre typer arbeidsformer? [s ]

ALPROLED Gruppe_1: Spørsmål 1: Hva skiller et prosjekt fra andre typer arbeidsformer? [s ] 30.10.2012 ALPROLED Gruppe_1: Spørsmål 1: Hva skiller et prosjekt fra andre typer arbeidsformer? [s. 38-39] Den skiller seg fra det rutinemessige. Mål og rammer kan angis for den. Den er ofte tverrfaglig.

Detaljer

FITS Tilgjengelighets- og kapasitetsstyring

FITS Tilgjengelighets- og kapasitetsstyring FITS Tilgjengelighets- og kapasitetsstyring Becta 2004 Utgitt på norsk av Senter for IKT i utdanningen i 2012 FITS tilgjengelighets- og kapasitetsstyring Innhold TKS 1 Introduksjon... 1 TKS 2 Oversikt...

Detaljer

UiO Økonomi og lønn: Sist oppdatert av Ellen Koyote Millar

UiO Økonomi og lønn: Sist oppdatert av Ellen Koyote Millar UiO Økonomi og lønn: Roller, samarbeidsform og gjensidige forventninger i styringsgruppen & prosjektledelsen. 90 minutter med speed-dating og plenumsdialog. Sist oppdatert 13.11.2018 av Ellen Koyote Millar

Detaljer

Guide. Valg av regnskapsprogram

Guide. Valg av regnskapsprogram Guide Valg av regnskapsprogram Trenger du et regnskapsprogram for din bedrift? Det er mye å tenke på når man sammenligner ulike tilbud. Hva er dine faktiske behov, hva er sluttprisen for en løsning, og

Detaljer

Uke 4. Magnus Li INF /

Uke 4. Magnus Li INF / Uke 4 Magnus Li magl@ifi.uio.no INF3290 19/20.09.2017 Repetisjon av begreper Oppgave Radiologisystem Økonomisystem Administrasjonen Radiologisk avdeling Avdeling for rehabilitering Pasientjournal Pasient

Detaljer

Workshop 1: Strategi, kontraktmodell og anbud

Workshop 1: Strategi, kontraktmodell og anbud Workshop 1: Strategi, kontraktmodell og anbud Velkommen Bakgrunn for workshopserie: // Felles innsats kreves // «Å sikre at alle starter på samme side i boka» Konseptets bakgrunn og motivasjon: //arbeid

Detaljer

RAMMEVERK FOR DESENTRALISERT KOMPETANSEUTVIKLING FOS

RAMMEVERK FOR DESENTRALISERT KOMPETANSEUTVIKLING FOS RAMMEVERK FOR DESENTRALISERT KOMPETANSEUTVIKLING FOS Modellen (fig 1) er å forstå som et utgangspunkt for langsiktig arbeid med et godt og inkluderende læringsmiljø i skolen. Selv om modellen kan forstås

Detaljer

VERDIER OG ETIKK I CRAMOOG VERDIER I CRAMO

VERDIER OG ETIKK I CRAMOOG VERDIER I CRAMO VERDIER OG ETIKK I CRAMOOG VERDIER ETIKK I CRAMO ETIKK OG VERDIER I CRAMO Kjære kollega, Vårt varemerke og omdømme er våre viktigste eiendeler. Vi har alle et ansvar for å opprettholde våre interessenters

Detaljer