Prosjektets risikoregister

Denne artikkelen bygger på serien Praktisk risikostyring og ser nærmere på erfaringer med systemstøtte til prosjektets risikoregister.

Bakgrunn

Som Risk Manager har jeg tatt i bruk ulike verktøy til støtte for risikostyring. I denne artikkelen oppsummerer jeg mine erfaringer med risikoregistre jeg har brukt. Og la det være sagt med en gang, jeg har ikke testet alle risikoregistre og det kan være at andre verktøy er helt «perfekte».

Min generelle oppfatning av verktøyene jeg har benyttet er at de er designet for en engangsanalyse av risiko. For mange anvendelser er dette tilstrekkelig, men i hektiske prosjekter med et dynamisk risikobilde vil det også være nødvendig å følge opp og ta hensyn til utviklingen av risiko over tid. Den gode nyheten er at de fleste risikoregistre har muligheter for konfigurering slik at denne mangelen delvis kan kompenseres med tilpasninger, work-arounds og god hjelp fra IT-avdelingen.

Arbeidstrinn i risikostyringsprosessen

Hva ønsker vi oss fra et risikoregister? Jeg ønsker at risikoregisteret skal støtte de ulike arbeidstrinnene i risikostyringsprosessen. For hvert trinn i prosessen er det litt ulike behov for informasjon. Risikoregisteret inneholder mange dataelementer og utfordringen blir å finne balansen mellom oversikt og detaljer som støtter arbeidet i hvert trinn. Ideelt sett skulle vi gjerne ha tilgang til all informasjonen samtidig, men det må gjøres et utvalg som gir både nødvendig oversikt og samtidig tilgang til detaljene som skal behandles.

1. Identifisere risiko – Dette er en kreativ prosess som skal avdekke nye risikoer. Her er det innledningsvis andre verktøy som støtter en brainstorming bedre enn et formelt risikoregister. Men når det foreligger mange forslag til nye risikoer, delvis overlappende og kanskje motstridende, er det nyttig med et register for å kunne sortere i kategorier. Det er mest hensiktsmessig å sortere i årsakskategorier, også kjent som Risk Breakdown Structure, RBS. Hver kategori inneholder et mer håndterbart antall risikoforslag som kan sammenstilles og omformuleres til entydige og unike risikoer før registrering.
2. Registrere risiko – Når de utvalgte risikoene fra identifiseringen skal registreres kommer risikoregisteret til sin rett. Her registreres alle formaliteter knyttet til den nye risikoen.
3. Analysere risiko – I dette trinnet fastsettes risikoens alvorlighetsgrad ved å vurdere sannsynlighet og konsekvens.
4. Håndtere risiko – Etter analysen vet vi hvilke risikoer som vi trenger å gjøres noe med. Vi velger først en strategi for håndtering, deretter eventuelle tiltak for å redusere trusler eller øke muligheter.
5. Følge opp risiko – Det kreves regelmessig oppfølging av risikoene i et dynamisk prosjektmiljø. Her logger vi alle endringer slik at vi kan spore risikoens utvikling over tid og kanskje sette inn ytterligere tiltak dersom eksisterende tiltak ikke har hatt ønsket effekt.
6. Rapportere risiko – Som et ledd i oppfølgingen velger vi ut risikoer for rapportering og tar disse inn i prosjektets statusrapport, med en utfylt risikomatrise, utvalgte risikoer og deres tiltak.

Tabellen under viser typisk innhold i et risikoregister og hvilke risikoelementer som blir lagt til i hvert trinn av arbeidsprosessen.

«Mine» risikoregistre

Det mest brukte verktøyet som risikoregister er MS-Excel. Ettersom de fleste prosjektledere allerede er drevne Excel-brukere er terskelen lav for å ta Excel i bruk til risikoregister. For mindre prosjekter gjør det god nytte, men når risikoene blir mer sammensatte ved at de utvikles over tid og trenger flere tiltak, trenger man et mer tilpasset verktøy.

Jeg har vært så heldig at jeg har fått være Risk Manager i flere store offentlige programmer og porteføljer. Vi har hatt spesialiserte verktøy til risikostyring. Som nevnt innledningsvis har det, etter min oppfatning, vært noen mangler ved de fleste av disse. Men disse manglene har i alle tilfellene blitt kompensert av et meget godt samarbeid med de lokale IT-avdelingene.

I programmet for Landsdekkende utbygging av Nødnett i DSB ble flere verktøy vurdert innledningsvis. Vi endte opp med å utvikle et risikoregister i en MySQL-database med MS-Access front-end. Verktøymaker var Bjørn Ramberg som utviklet i tråd med mine spesifikasjoner.

Programmet for Nye pass og nasjonale ID-kort (NPID) i Politiet hadde allerede Jira og Confluence som standardverktøy for prosjektstøtte. Jira hadde en sakstype for risiko, men denne dekket ikke programmer med flere prosjekter. Med god hjelp fra verktøytilpasser Tim Kopperud fra IT-avdelingen fikk vi utviklet et meget godt tilpasset risikoregister i Jira med automatisk statusrapportering i Confluence.

I Sykehuspartner er Clarity PPM standardverktøy for prosjektstøtte. I programmet for Standardisering og IKT-modernisering (STIM) benyttet vi risikomodulen i Clarity til risikostyring, både på prosjekt- og programnivå. For å få ønsket støtte fra verktøyet har Clarity-ekspertene Lasse Fjell og Magnus Okkelmo fra PPM-teamet vært svært hjelpsomme. Prosjektene fortsetter å bruke Clarity, mens samlet portefølje har sitt risikoregister i et nytt verktøy, Hypergene, som også har fått min ønskeliste.

Avslutningsvis ønsker jeg å rette en spesiell takk til mine kollegaer i Sykehuspartner, Camilla Skeie Haukeland og Linda M. Gundersen, for meget godt samarbeid i bistand til og oppfølging av risikostyring i prosjektene.