Veiledning for effektiv usikkerhetsstyring
I tråd med organisasjonens regler og prosesser
Et prosjekt trenger gjerne å være i tråd med regler, standarder og prosesser for virksomheten, programmer eller
porteføljer, i tilnærmingen til usikkerhetsstyring. Herunder:
- tilpasning til sentralt definerte retningslinjer, standarder og tilnærminger for usikkerhetsstyring
- bruk av sentralt definerte teknikker for usikkerhetsstyring
- bruk av verktøy implementert sentralt
- tilpasning til roller eller kompetanserammeverk for sentralt definert usikkerhetsstyring
Mange organisasjoner ønsker en konsekvent, godkjent prosess for de forskjellige prosjektene. Dette er ofte for å kunne sikre seg at de vurderer hvor utsatt organisasjonen er totalt sett for usikkerhetseksponering fra de forskjellige prosjektene. Dette er også tilfellet når organisasjoner ønsker å utvikle modenheten til deres prosjektledelse, ved hjelp av en modenhetsmodell så som P3M3.
Anbefalt prosedyre for usikkerhetsstyring
PRINCE2 anbefaler, men pålegger ikke, en usikkerhetsstyring basert på Management of Risk: Guidance for
Practitioners (Office of Government Commerce (kontor for regjeringsforretninger), 2010).
Prosedyren består av fem trinn, og de fire første er suksessive:
- Identifiser: sammenheng og usikkerheter
- Vurder: estimer og evaluer
- Planlegg
- Gjennomfør
Kommuniser, det femte trinnet, må utføres fortløpende, ettersom resultatet av hvert trinn må kommuniseres til interessenter etter hvert i løpet av hele prosessen.
Alle trinnene kan repeteres. Når ny informasjon blir kjent, er det ofte nødvendig å gjenta tidligere trinn basert på denne nye informasjonen.
Forstå prosjektstyrets holdning til usikkerhet
En viktig avgjørelse som må oppføres innen tilnærmingen til usikkerhetsstyring er prosjektstyrets holdning til
risikotagning. Denne vil bestemme hvor stor usikkerhet som er akseptabel, noe som igjen vil bidra til å
bestemme usikkerhetstoleransen.
Prosjektstørrelse, skala og kompleksitet samt virkning av usikkerhet
Pass på at tilnærmingen til usikkerhetsstyring er passende, ikke bare for prosjektets størrelse, skala og kompleksitet, men også til den sannsynlige virkningen av usikkerhet på prosjektet. Det er viktig at tilnærmingen til usikkerhetsstyring for et prosjekt støtter at avgjørelser kan tas effektivt, og at den ikke skaper en unødvendig byråkratisk byrde. Generelt sett vil mindre, enklere prosjekter trenge tilsvarende enklere systemer for usikkerhetsstyring.
For eksempel vil en prosjektleder kunne utføre det meste av usikkerhetsstyringsaktiviteter direkte på mindre komplekse prosjekter. For mer komplekse prosjekter kan imidlertid dette bli delegert til en egen leder eller et team for usikkerhetsstyring. På samme vis kan et usikkerhetsregister ganske enkelt være en liste på en tavle, på et regneark eller i et eget IT-system. Det som er viktig er at tilnærmingen til usikkerhetsstyringen er hensiktsmessig.
Når man skal avgjøre hvor hensiktsmessig en tilnærming til usikkerhetsstyring er, er det viktig å ta med i betraktningen ikke bare prosjektets kostnad, størrelse, skala og kompleksitet, men også hvor stor virkningen av usikkerheten kan være på prosjektet. Det er mulig for prosjekter å ha virkninger som betydelig overgår deres tilsynelatende størrelse, skala og kompleksitet. For eksempel kan et lite, enkelt prosjekt for å bytte viktig infrastruktur i et IT-nettverk ha den virkningen at det stopper driften til en organisasjon hvis noe går galt.
Leveransetilnærming for prosjektet
Det er viktig at tilnærmingen til usikkerhetsstyring fungerer sammen med og støtter leveransetilnærmingen valgt for prosjektet. For eksempel er det usannsynlig at en tilnærming til usikkerhetsstyring som innebærer månedlige møter kan støtte en god prosjektleveransetilnærming effektivt, hvis resultat skal leveres hver andre uke.
PRINCE2 pålegger ikke en bestemt type produkt for usikkerhetsstyring, ei heller pålegger det en spesifikk tidsramme for usikkerhetsstyringsaktiviteter. Det viktigste er at de er passende for typen prosjekt og tidsrammen det har. Et usikkerhetsregister kan føres opp på en tavle og gjennomgås som del av et daglig informasjonsmøte som del av en smidig leveransetilnærming. I denne sammenhengen er det vel så brukbart som usikkerheter oppført i et eget IT-system som gjennomgås på månedlige møter.
Det er også viktig å innse at prosjektets leveransetilnærming kan både minske og øke bestemte usikkerheter. For eksempel kan en smidig måte å jobbe på sikre at kundene ikke stiller urimelige begrensninger og overdrevne krav ved prosjektets begynnelse, noe som kan være en usikkerhet ved den mer tradisjonelle «fossefall»-tilnærmingen. På samme måte, selv om smidighet er preget av en høy grad av samvirke med
kunden direkte involvert i prosjektet, kan det føre til ukontrollerte endringer i den baseline man er blitt enige om, hvis det ikke håndteres ordentlig. Mer tradisjonelle tilnærminger styrker ofte inntrykket av «kontrollerte endringer», men kan da også fremstå som lite responsive. Det som er viktig er at tilnærmingen til usikkerhetsstyring anerkjenner disse iboende forskjellene.
Kommersielle vurderinger
I en kommersiell sammenheng kan det bli behov for mer enn ett usikkerhetsregister, da noen usikkerheter ved prosjekter kan gjelde kun for én av partene, og det kan være gode grunner til at disse ikke bør være synlige for den andre parten. Når et usikkerhetsregister brukes, må man være nøye med å spesifisere hvem usikkerheten faktisk tilhører og hvem som er utnevnt som usikkerhetseier. For eksempel vil det i en fastpriskontrakt være slik at kostnadsoverskridelser påvirker leverandørens business case, mens tidsoverskridelser typisk påvirker kundens business case.
Opprette et usikkerhetsbudsjett
Det kan være nyttig å identifisere og øremerke et uttrykkelig usikkerhetsbudsjett innenfor prosjektets budsjett. Dette er en pengesum for å dekke bestemte responser fra ledelsen til prosjektets trusler og muligheter (f.eks. for å dekke kostnader ved en reserveplan, skulle en usikkerhet bli en realitet).
Usikkerhetsbudsjettet er basert på den samlede kostnaden av alle prosjektets planlagte usikkerhetstiltak. For enklere prosjekter er det som oftest nok å legge sammen kostnaden til alle usikkerhetstiltakene. For mer komplekse prosjekter er det imidlertid viktig å passe på at den samlede kostnaden av alle beregnede kostnader, ikke blir forskjøvet av et lite antall store usikkerheter. Det er her analytiske teknikker så som Monte Carlosimulering og tilknyttede programvarer kan være til hjelp.
Etter som prosjektet skrider frem, vil noen av usikkerhetene som ble identifisert tidligere inntreffe, og andre ikke. Nye usikkerheter kan bli identifisert i løpet av prosjektets levetid, der responskostnadene ikke har vært inkludert i usikkerhetsbudsjettet. Derfor er det fornuftig å inkludere en allokering for ukjent usikkerhet (ikke ennå identifisert) i usikkerhetsbudsjettet.