PRINCE2

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

• Kontinuerlig forretningsmessig forankring

• Lære fra erfaringer

• Definerte roller og ansvar

• Styre i faser

• Avviksledelse

• Fokus på prosjektets produkter

• Tilpasse prosjektomgivelene

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

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

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

• Business case

• Organisering

• Kvalitet

• Planer

• Usikkerhet

• Endring

• Fremdrift

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

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

Oppstart av prosjektet

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

• Utnevne prosjekteier og prosjektleder

• Forberede grov business case

• Sette sammen prosjektforslag

• Planlegge initieringsfasen

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

2.1. PROSJEKTLEDELSE 11 Eierstyring av prosjektet

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

• Autorisere initiering, prosjektet, faseplan og prosjektavslutning.

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

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

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

Initiere prosjektet

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

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

• Opptrette prosjektplan

• Forfine business case

• Samle initieringsdokumentasjonen

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

Kontrollere en fase

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

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

• Autorisere og motta fullførte arbeidspakker

• Gå gjennom fasestatus og rapportere høydepunkt

• Gjøre korrigerende tiltak Styre produktleveranser

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

• Akseptere, utføre og levere arbeidspakke Lede faseovergang

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

194). De viktigste aktivitetene ilede faseoverganger:

• Planlegge neste fase

• Oppdatere prosjektplanen

• Rapportere faseavslutning

• (Produsere unntaksplan)

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

Avslutte prosjektet

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

2.2. INFORMASJONSINFRASTRUKTUR 13

• Forberede planlagt avslutning

• (Forberede avslutning før plan)

• Overlevere produkter

• Evaluere prosjektet

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

2.2 Informasjonsinfrastruktur

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

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

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

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

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

Hanseth mener derfor at alle de nevnte egenskapene er med på å gjøre IIen he-terogen ved at den er et sosioteknisk nettverk (Hanseth 2000, s. 58). Med det mener han at den består av alt fra de helt tekniske elementene til de sosiale relasjonene i tilknytning til systemene. For å illustrere dette kan man si at de tekniske elemente-ne ikke vil kunelemente-ne 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).

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

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

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

2.2.1 Tilpasning av II-litteraturen

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

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

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

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

2.3 Store komplekse prosjekter

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

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

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

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

2.3.1 Hva er et vellykket prosjekt?

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

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

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

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

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

2.4 Prinsipper for koordinering

En standard defineres som en rekke løsninger relatert til faktiske eller potensielle problemer som gagner partene som er involvert. Det er forventet at løsningene blir jevnlig benyttet i en bestemt periode av en bærekraftig del av partene standarden er ment for (DeVries 2013, s. 13). Med dette kan man derfor si at en standard er en etablert norm eller krav som har som hensikt å skape struktur og orden for dem

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

In document Ledelse av store komplekse prosjekter (sider 21-0)