Vejledning til risikostyring · Et andet vigtigt element er kommunikationen mellem projektlederen og styregruppen; i særdeleshed projekt- og gevinstejer. Projektlederen skal fokusere

-

Vejledning til risikostyring

September 2018

Statens it projektmodel, Digitaliseringsstyrelsen version: 1.0

...........................................................................................................................................

Indhold

1. Indledning 3 1.1 Definition og formål ....................................................................................................................................... 3 1.2 Sammenhæng til statens it-projektmodel..................................................................................................... 3

2. Principper for risikostyring .................................................................................................................5 2.1 Beskrivelse af risici .......................................................................................................................................... 5 2.2 Brug af risikolog .............................................................................................................................................. 5 2.3 Ansvar for risikostyring .................................................................................................................................. 5 2.4 Brug af advarselslamper for risici..................................................................................................................6 2.5 Kommunikation om risici .............................................................................................................................. 7

3. Proces for risikostyring........................................................................................................................8

4. Identificering.......................................................................................................................................9 4.1.1 Identifikation af projektets rammeforhold.................................................................................................. 9 4.1.2 Identificering af risici i projektet ................................................................................................................... 9 4.1.3 Risikotyper......................................................................................................................................................10

5. Vurdering............................................................................................................................................11

6. Planlægning /revurdering................................................................................................................. 12

7. Håndtering ........................................................................................................................................ 13

8. Case om risikostyring........................................................................................................................ 14 8.1 Identificeringsprocessen............................................................................................................................... 14 8.2 Vurderingsprocessen..................................................................................................................................... 15 8.3 Planlægning..................................................................................................................................................... 16 8.4 Håndtering......................................................................................................................................................18

1. Indledning

Dette afsnit indeholder definition af risici og formålet med risikostyring. Derudover beskrives de orga-nisatoriske perspektiver, hvori risikostyring indgår.

1.1 Definition og formål

En risiko defineres som værende en mulig hændelse, der, hvis den opstår, vil have indvirkning på opfyldelsen af målene i projektet. En hændelse kan være en trussel, som kan have en negativ indvirkning på projektets mål. En risiko angives som en kombination af sandsynligheden for at hændelsen indtræder og omfanget af dens indvirk-ning på målet (konsekvens).

Definition: Risiko

En risiko defineres som en t russel, der kan p åvirke et projekts mål til det værre.

Bemærk, at der i statens risikostyringsmetode som udgangspunkt ikke anvendes positive risici (muligheder). Hvis projektet ønsker at registrere og følge muligheder gennem risikostyringen, skal myndigheden selv tilpasse risiko-loggen og de dertilhørende processer.

I et projekt anvendes risikostyring som en ramme for forvaltning af risici på tværs af alle dele af projektet. Risi-kostyringen indeholder alle de aktiviteter, der kræves for at identificere og kontrollere eksponeringen for enhver form for risiko, som kan have en indvirkning på opnåelsen af organisationens forretningsmæssige mål.

Der er en række fordele ved at anvende risikostyring, blandt andet:

• Bedre leverancer • Reduktion i tid brugt til brandslukning • Større sandsynlighed for at gevinster kan realiseres • Bedre grundlag for udarbejdelse af strategiske indstillinger • Øget mulighed for at forandringsinitiativer lykkes • Mere effektiv udnyttelse af ressourcer • Mere værdi for pengene

Risikostyring er et væsentligt styringselement for it-projekter. It-projekter bør ud over projektets egne risici have kendskab til strategiske risici og operationelle risici i den daglige drift, da disse typisk har en indflydelse på projek-tets succesfulde gennemførsel.

1.2 Sammenhæng til statens it-projektmodel

Alle projekter skal udarbejde en risikolog og benytte den aktivt igennem projektets levetid. Der findes en skabe-lon til risikolog i statens it-projektmodel som bilag til Projektgrundlaget, men myndigheden kan benytte deres egen skabelon, hvis den har samme detaljeringsgrad. For mere information, kontakt Ministeriernes projektkon-tor.

Det er obligatorisk at have en risikolog i statens it-projektmodel, og den indgår i Statens It-råds risikovurdering. Risici identificeres og estimeres i risikologgen. Projekterne skal herefter indarbejde væsentlige risici i business casen, som beregner projektets risikopulje.

Vejledning til risikostyring Side 3 af 18

Forelæggelse for Statens It-råd

For projekter, som skal risikovurderes i Statens It-råd, skal risikologgen el ler tilsvarende redskaber med s amme detaljeringsniveau indgå i materialet til risikovurderingen som produktbilag til projektgrundlaget. Hvis myndigheden a nvender andre risikostyringsværktøjer end r isikologgen i statens it-projektmodel, bør dette aftales med M inisteriernes projektkontor før risikovurderingen.

Risikologgen opdateres løbende; for eksempel når en risiko ændrer sig, eller når der identificeres nye risici. Der-udover vil en løbende risikostyring medføre, at risikologgen kan benyttes ved den halvårlige statusrapportering til Statens It-råd.

For en nærmere beskrivelse af håndtering og indbudgettering af risikopuljen henvises der til vejledning til brug af business case i staten.


2. Principper for risikostyring

Følgende afsnit præsenterer fem principper for risikostyring i statens it-projektmodel, herunder beskri-velse af risici, brug af risikolog, ansvar for risici, brug af tolerancer og kommunikation om risici.

2.1 Beskrivelse af risici

For at operationalisere beskrivelsen af risici opdeles de i tre komponenter:

Risikoårsagen er den bagvedliggende grund til, at risikoen eksisterer. Det kan for eksempel være forhold i orga-nisationen eller vilkår i omverdenen, der betyder, at projektet er risikabelt.

Risikohændelsen er den konkrete trussel, som projektet står overfor. I praksis kan det være svært at skelne mellem årsag og hændelse, og i risikologgen er disse felter derfor slået sammen.

Risikokonsekvensen beskriver hvad der sker, hvis hændelsen indtræffer. Det kan være en fordel at overveje, om konsekvensen har indflydelse på projektets proces – tid, økonomi og ressourcer – eller på projektets mål – kvalitet, gevinster eller formål.

2.2 Brug af risikolog

Til at understøtte risikostyringen er der udarbejdet et værktøj – Risikologgen. Risikologgen findes som bilag til projektgrundlaget. I forhold til projektets anvendelse af risikologgen i projektets levetid anbefales det, at:

• Opdatere loggen løbende, så det har værdi for projektet i alle faserne. Det kan med fordel aftales med sty-regruppen, hvor ofte registret skal opdateres - for eksempel hver 14. dag eller månedligt. Det er vigtigt at få aftalt i projektet, hvordan nye risici eller ændringer til risici skal opsamles fra projektdeltagere, ledelsen, leverandører og interessenter.

• Afrapportere om risici til styregruppen løbende. • Indtrufne hændelser håndteres separat, da de typisk vil influere på andre produkter, såsom projektplanen

eller beredskabsplanerne. Der kan eventuelt oprettes en issuelog for risici, der er indtruffet.

Når risici er beskrevet i risikologgen og projektgrundlaget, skal de væsentligste risici (som regel de risici med størst økonomisk konsekvens) overføres til business casen til beregning af risikopulje. De beregnede økonomiske konsekvenser vil herefter fremgå af business case grundlaget. Projektet skal foretage løbende vurdering af risiko-puljens størrelse, når der sker ændringer i projektets risikobillede.

2.3 Ansvar for risikostyring

Ansvaret for risikostyring er placeret i styregruppen. Styregruppeformanden har det overordnede ansvar for risikosty-ringen og for at sikre, at risici bliver afdækket og håndteret.

Alle risici delegeres til en risikoejer, som har ansvaret for at følge op på risikoen og på de besluttede mitigerende tiltag.

Projektlederen har ansvar for at holde risikologgen opdateret og løbende rapportere om risici samt holde øje med tidlige advarselsindikatorer for risici. Projektlederen har derudover ansvar for at igangsætte besluttede bered-skabsplaner.


Derudover har de øvrige roller i projektet et ansvar for at bidrage til risikostyringen. Ansvaret er beskrevet i tabel 2.1 herunder. Denne rolle- og ansvarsfordeling har til formål at sikre, at der er ledelsesinvolvering gennem hele processen.

Tabel 2.1: Roller og ansvar i risikostyring i en projektkontekst.

Roller Ansvar

Ledelse for projekt eller myndig-hed (typisk direktionen)

Fastlægger politikken og rammerne for risikostyring for projektet: organisationens risikovillighed, tolerancer og eskaleringsprocesser.

Styregruppeformand Overordnet ansvarlig for: • Risikostyringen • At alle risici afdækkes • Eskalering

Seniorbruger/gevinstejer Identificering af risici i forhold til brugerne og forretningen. Seniorbruger/gevinstejer med deraf følgende ansvar for risikostyring i realiserings-fasen.

Seniorleverandør Identificering, vurdering og kontrol af risici i forhold til leverancerne. Bidrag til udarbejdelse af risikolog. Afdækning af risici.

Projektleder Identificering, vurdering og kontrol af risici gennem hele processen i projektet. Derudover er projektlederen blandt andet ansvarlig for at:

• eskalere afvigelser af toleranceniveauer for risici • modtage information om uforudsete hændelser og meddele dem til styre-

gruppe (tid og omkostninger) • aftale toleranceniveauer og relaterede advarselslamper og eskaleringsproce-

durer med styregruppen, for eksempel baseret på: – stigninger i risikoværdien – den absolutte risikoværdi – konkrete tidlige advarselsindikatorer – tidspunkt for rapportering ift. hvornår en given risiko forventes at kun-

ne indtræffe

PMO eller lignende Gennemgang af risikostyringens udførelse og sikre, at den er i overensstemmelse med strategien.

Projektsupport Assisterer projektlederen med vedligeholdelse af risikoregistreringen.

2.4 Brug af advarselslamper for risici

Til at understøtte rollerne i risikostyring kan der aftales advarselslamper, som er en prædefineret og kvantificeret indikator på, at en risiko er nært forestående eller udvikler sig i en uhensigtsmæssig retning. Dette muliggør en informeret og forberedt tilgang til at håndtere hændelsen eller at eskalere den til et andet styringslag. Advarsels-lamper kan for eksempel baseres på følgende:

• Risikoværdien er over 10 • Risikoværdien er stigende • Tidspunktet for en risiko kan indtræffe nærmer sig

Advarselslamper er en operationel måde at arbejde med tolerancer for risici. Hvis myndigheden arbejder mere struktureret med tolerancer for risici, kan dette erstatte advarselslamperne.


2.5 Kommunikation om risici

Kommunikation om risici er en central del af risikostyring, og der bør være tilstrækkelig kommunikation gennem hele risikostyringsprocessen, både om potentielle risici og om projektet som helhed. Det er vigtigt at sikre, at de ansvarlige for styring af risici, og dem der påvirkes af risici, forstår det grundlag som beslutningerne træffes på, samt hvorfor bestemte tiltag er nødvendige. Internt i organisationen skal risikooplysninger kommunikeres på en nyttig og meningsfuld måde på tværs af forskellige operationelle områder af organisationen. Eksternt rettes kommunikationen mod kunder og interessenter, som kan være involveret i eller berørt af et projekts beslutninger og handlinger. Kommunikation om risici bør derfor indgå i projektets kommunikationsplan.

Ved fastlæggelsen af kommunikationsaktiviteter indenfor risikostyring kan projektet afklare følgende spørgsmål:

• Hvilken type oplysninger skal kommunikeres på forskellige stadier? (Hvilken type oplysninger har interes-serenter og påvirkede parter brug for, og hvilken type ønsker de?)

• Hvad er målgruppen for de forskellige typer af oplysninger? (internt personale, ledelse, eksterne interes-senter, herunder offentligheden etc.)?

• Hvilken kommunikationskanal bør anvendes til at kommunikere oplysninger til den tiltænkte målgruppe?

Et eksempel på intern kommunikation om risici er for eksempel projektgruppemøder, hvor nye og allerede kend-te risici gennemgås som en fast del af møderne.

Et andet vigtigt element er kommunikationen mellem projektlederen og styregruppen; i særdeleshed projekt- og gevinstejer. Projektlederen skal fokusere sin kommunikationsindsats på de største risici, så styregruppen hele tiden er på linje med projektets risici og kan agere derudfra. Dette muliggør også, at styregruppen får truffet be-slutninger om de største risici, såfremt de overskrider de givne tolerancer.


3. Proces for risikostyring

Dette afsnit beskriver processen for risikostyring. Derudover beskrives de organisatoriske perspektiver, hvori risikostyring indgår

Projekter arbejder med risici i fire procestrin, som angivet i Figur 3.1 herunder. Processen fortsætter igennem hele projektets levetid, sådan at der løbende foretages identificering, vurdering, planlægning og håndtering af risici. Risikostyringen starter allerede i idefasen med indledende overvejelser om projektets risikobillede. Herefter følger en grundig risikoanalyse i analysefasen. Risikostyring fortsætter i de følgende projektfaser

Figur 3.1: Risikostyringens fire trin

Processen indledes med identificering af risici. Her identificeres risikoelementer og deres indhold klarlægges.

Herefter vurderes sandsynlighed, konsekvens, tidspunkt for at risikoen kan indtræffe og potentielle tidlige advar-selsindikatorer fastsættes.

Dernæst skal risikohåndteringen planlægges ved at angive mitigerende handlinger, som typisk vil minimere sandsynligheden eller konsekvensen af risikoen. Hvis risici er meget store, kan det også være nødvendigt at re-vurdere projektet i sin helhed på baggrund af de identificerede risici.

Endelig håndteres projektet risici, og det sikres at der bliver fulgt op på denne håndtering.

Processen beskrives mere indgående i de følgende afsnit.


4. Identificering

Identificeringen af risici er det første trin i firetrinsprocessen for risikostyring. Identificering består af to delprocesser: 1) Identificering af risici i projektets rammeforhold og 2) identificering af risici. Derud-over listes risikotyper til brug ved identificering af risici.

4.1.1 Identifikation af projektets rammeforhold

Det primære mål med denne delproces er at identificere hvilke rammeforhold, der påvirker projektets risikopro-fil. Det kræver typisk en besvarelse af følgende spørgsmål:

• Hvor vigtigt er projektet for organisationen og for det politiske lag? • Hvilke politiske bindinger er der på projektet? • Hvilket modenhedsniveau har organisationen i forhold til at implementere ny it? • Hvor store ændringer medfører projektet for brugere og borgere? • Har projektet tilstrækkelige ressourcer til at levere leverancerne? • Er projektets tidsplan realistisk?

Hvis projektet ønsker at dykke yderligere ned i projektets rammevilkår, kan følgende teknikker bruges til at ana-lysere rammevilkårene:

• Projektets risikotjekliste • SWOT-analyse, som giver et samlet overblik over svagheder/styrker og trusler/muligheder, og hermed et

godt udgangspunkt for at træffe beslutninger omkring det samlede risikobillede. • PESTLE-analyse, som er en forkortelse for politiske-, økonomiske-, sociale- og teknologiske faktorer, der

hjælper med at finde uopdagede risici. • RACI-Diagram, som beskriver deltagernes roller og ansvar i virksomheden og/eller en aktivitet i forhold

til at levere aftalte bidrag. Diagrammet giver et overblik over, hvem der er udførende og ansvarlige, og som skal høres eller informeres.

• Interessentanalyse, som har til formål at sikre, at projektlederen ved hvilke personer, i eller udenfor organisationen, der har interesse i projektet.

Identifikation af rammeforhold bruges som ramme for at identificere konkrete risici og vil ofte indgå som risiko-årsager i risikologgen.

4.1.2 Identificering af risici i projektet

I denne proces identificeres de risici, som vil reducere eller fjerne sandsynligheden for, at organisationen når sine mål.

Det anbefales, at projektet afholder en eller flere risikoidentifikationsworkshops. Identificeringsprocessen i en workshop kan drage nytte af en almindelig brainstorm, eller projektet kan benytte Delphi-metoden, der bygger på et panel af eksperter, som besvarer et spørgeskema i to eller flere runder, hvilket giver bredere og bedre fun-derede svar på, hvilke risici der kan opstå og hvorfor.

Når risici er identificeret, beskrives de i risikologgen. Her skrives både selve risikoen (risikohændelsen) samt en beskrivelse af mulige effekter og årsager til risikoen.


Risikoidentificeringen skal vigtigst af alt trække på den erfaring og viden, der allerede findes i organisationen. Hvis projektet ønsker at sikre sig en bredere funderet identificering, kan projektet benytte følgende teknikker og tjeklister:

• Risikoliste baseret på organisationens egne erfaringer. Hvis organisationen ikke allerede har sin egen risi-koliste, bør en sådan udarbejdes. Listen skal bestå af de in-house risici, som blev identificeret eller indtraf under tidligere organisatoriske aktiviteter såsom programmer eller projekter. Den må dog ikke ses som en udtømmende liste over potentielle risici for et givent projekt.

• Informationssikkerhed. Det anbefales at identificere potentielle risici i forhold til it-sikkerhed ved at vur-dere projektets leverancer ud fra de af myndigheden fastlagte sikkerhedsstandarder.

• Konsekvensvurdering for privatlivet. En privatlivsimplikationsanalyse er en teknik, hvor risici vurderes i projektet i forhold til beskyttelse af privatlivets fred. Analysen skal anvendes af projekter, der omhandler personfølsomme informationer eller brugerteknologier, som indvirker på privatpersoner. Analysen er rele-vant for både drift og udvikling.

• Årsag-virkning-diagram (cause and effect). Et fish-bone-diagram, der illustrerer årsagerne til forskellige hændelser, som fører til en eller flere konsekvenser og giver overblik over sammenhængene.

• Risk Breakdown Structure. En teknik med udgangspunkt i WBS til at afdække kilden til risici. • Risiko Taxonomy. En tjekliste, der organiserer virksomhedens kendte risici i almindelige klasser opdelt i

elementer og karakteristika og giver udgangspunkt for eksponering, måling, styring og rapportering. • Individuelle interview. Typisk interviewes personer, der har konkrete erfaringer med projektet, den om-

kringliggende forretning, leverandørstyring eller lignende.

Det anbefales, at projektet etablerer procedurer for at gennemføre risikoidentificering med passende mellemrum.

4.1.3 Risikotyper

Statens it-projektmodel og risikologgen benytter sig af en inddeling af risici i fem risikokategorier, der er defineret i nedenstående boks.

Fem risikokategorier

Forretningsmæssige forhold: – Potentielle hændelser, der omhandler det forretningsmæssige grundlag for projektet, herunder øko-

nomiske estimater, fraset hændelser, der falder under de andre kategorier. Projektets tilrettelæggelse:

– Potentielle hændelser, der omhandler det projekttekniske setup, scope, organisationens modenhed ogplanlægning af projektet.

Markedsafklaring og teknisk løsning: – Potentielle hændelser, der omhandler markedsafklaringen og den tekniske løsnings opfyldelse af kva-

litetskrav og sikkerhed. Interessenter:

– Potentielle hændelser, der omhandler interessenters ageren og interessevaretagelse. Slutbrugere og slutprodukt:

– Potentielle hændelser, der omhandler slutbrugernes inddragelse og slutproduktets opfyldelse af slut-brugernes behov.


5. Vurdering

Når risici er identificeret, skal de vurderes. Vurderingen af risici er det andet trin i processen for risiko-styring.

I vurderingsprocessen ses på sandsynligheden for, at en risiko indtræffer, samt hvad konsekvensen heraf er. Det er vigtigt at pointere, at der vil være tale om bedste gæt baseret på faglig ekspertise samt analyser og teknikker til vurdering. Formålet er ikke at give et endeligt svar på, om en risiko indtræffer, eller hvordan det helt præcist vil påvirke projektet.

Følgende skal vurderes:

• Sandsynligheden for, at de identificerede trusler hænder. Vurderes på en 5-punktsskala, hvor 1 er 1-20 % sandsynlighed, og 5 er 81-99 % sandsynlighed.

• Konsekvenserne af forskellige trusler i forhold til projektets mål. Vurderes for risiciens konsekvenser for hhv. projektets proces – tid, økonomi og ressourcer – eller for projektets mål – kvalitet, gevinster eller for-mål – på en 5-punktskala, hvor 1 er ubetydelige konsekvenser, og 5 er meget store konsekvenser.

• Risikoens nærhed, som er det tidspunkt, hvor hændelsen sandsynligvis vil materialisere sig på. Nærhed an-giver, hvor hurtigt risikoen forventes at indtræffe, såfremt der ikke handles – og dermed hvor tidsmæssig kritisk risikoen er.

Den samlede risikoscore udregnes som sandsynligheden ganget med den højeste konsekvensscore.

Det anbefales, at der afholdes en eller flere vurderingsworkshops med fagpersoner og andre projektdeltagere, risici vurderes. Hvis projektet har behov for at arbejde mere i dybden med vurderingen, kan følgende tek-er assistere med at skabe et bedre grundlag for vurderingsprocessen:

Paretoanalyse: en analyse, der fokuserer på de risici, der har størst effekt. Skaber fokus på de risici, der på-virker mest.

Probability Impact Grid: hver risiko gives to sæt kriterier, som derefter ses på i en sandsynligheds- og på-virkningsmatrix. Hver potentiel hændelse vurderes ud fra sandsynligheden for, at den vil forekomme. Herefter vurderes konsekvensen. Probability Impact Grid matrix anvendes, fordi det giver mulighed for at flette begge komponenter på den samme skala og skabe overblik.

Risk Map: en klassificering af risici, der giver overblik over betydningen af de forskellige risici. CRAMM: en formaliseret sikkerhedsrisikoanalyse og styringsmetode oprindeligt udviklet af CCTA (nu en

del af Office of Government Commerce) i samarbejde med en række private organisationer. Probability Trees: En grafisk oversigt over følgevirkninger af en beslutning. Oversigten giver mulighed for

at vurdere eventuelle beslutninger og estimere deres konsekvenser.

et hvilke teknikker og analyser der anvendes til vurderingen af sandsynlighed og konsekvenser, er det cen- at den rette faglige ekspertise inddrages, da det giver den mest retvisende vurdering og dermed også det retvisende risikobillede.

som med identificeringen anbefales det, at projektet etablerer procedurer for at opdatere risikovurderinger passende mellemrum.

hvornikk

•

•

••

•

Uanstralt,mest

Ligemed


6. Planlægning /revurdering

Når risici er identificeret og vurderet, planlægges hvordan risici håndteres.

Planlægningsprocessen har to formål. For det første skal den sikre, at der bliver iværksat mitigerende tiltag for risici, der kan påvirke projektet væsentligt. For det andet skal planlægningsprocessen bruges til at planlægge be-redskabsplaner for de største risici for projektet, så projektet ved hvad der skal ske, hvis risikoen indtræffer.

Både mitigerende handlinger og håndtering af indtrufne risici kræver ressourcer, og det er derfor vigtigt, at pro-jektlederen prioriterer de rigtige tiltag. Prioriteringen bør baseres på resultater fra vurderingsprocessen. Ligesom med identificering og vurderingen anbefales det, at projektet etablerer procedurer for at opdatere planlægningen med passende mellemrum og regelmæssigt revidere planlægningen.

De mitigerende tiltag skal ideelt set kunne fjerne eller reducere truslerne. Samtidigt skal det også sikres, at der er klare procedurer for, at de planlagte tiltag gennemføres, hvem de gennemføres af, hvornår tiltagene skal være gennemført, og hvordan effektiviteten af tiltagene overvåges. Således kan der iværksættes afhjælpende foranstalt-ninger, hvis tiltagene ikke modsvarer forventningerne.

De mitigerende tiltag skal indgå i projektets planer og budget. Når de mitigerende tiltag er blevet gennemført, bør projektet revurdere risikoens sandsynlighed og konsekvens, sådan at det bliver tydeligt, om der er behov for yderligere handlinger.

I visse tilfælde vil indtrufne risici have så store konsekvenser eller kræve så uhensigtsmæssigt mange ressourcer at håndtere, at der med fordel kan udarbejdes en beredskabsplan for, hvad der konkret skal gøres, hvis risikoen indtræffer. Det drejer sig om de højest prioriterede risici, som:

• har en relativ høj sandsynlighed for at indtræffe • har alvorlige konsekvenser • ikke i tilstrækkelig grad kan forebygges for rimelige midler

De økonomiske konsekvenser af beredskabsplanerne skal indarbejdes i projektets business case under risikopul-jen.

Risici, der indtræffer, er ikke længere risici, men issues. Det betyder, at risikoen, som nu er et issue, skal håndteres eksternt fra risikostyringen og lukkes i risikologgen. Herudover skal udgifterne til handlingerne i beredskabet indarbejdes i projektudgifterne i business casen efter risikoen er indtræffet.


7. Håndtering

Håndtering er det sidste procestrin i risikostyringen og skal sikre, at håndtering af risici bliver gennem-ført.

Det primære mål med håndteringsprocessen er at sikre, at de planlagte foranstaltninger bliver ført ud i livet. An-svaret for at følge op på dette ligger både hos projektlederen og hos de enkelte risikoejere:

Risikoejeren følger op på de risici vedkommende er ansvarlig for og sikrer, at de bliver håndteret.

Projektlederen sikrer, at risikologgen angiver det korrekte risikobillede for projektet, og at styregruppen er be-kendt med dette.

Projektlederen skal også sikre, at de rigtige beredskabsplaner bliver iværksat, hvis risici indtræffer. Beredskabs-planer skal ofte iværksættes hurtigt, hvorfor det er vigtigt, at projektlederen har overblik over risici og deres nær-hed.


8. Case om risikostyring

Gennemgang af case om risikostyringens fire faser.

Projektlederen for it-projektet ”Indførelse af et landsdækkende ESDH-system” (Elektronisk Sags- og Doku-menthåndtering) i Fritidsstyrelsen skal til at starte risikostyring for sit projekt, da det er kommet ind i analysefa-sen. Projektlederen skal påbegynde udfyldelsen af Projektgrundlaget, herunder risikologgen og risikotjeklisten. Anskaffelsen af ESDH-systemet vil koste omkring 100 mio. kr.

Projektlederen er nyansat i Fritidsstyrelsen, men personen har flere års erfaring med projektledelse.

8.1 Identificeringsprocessen

Efter projektlederen har læst Fritidsstyrelsens egen risikoliste og udvalgt de risici, der er relevante for ESDH-projektet, indkalder projektlederen projektgruppen til et møde vedrørende projektets risici (Risikoidentifice-ringsworkshop).

Projektlederen har god erfaring med at anvende brainstorming til at få identificeret risici ved sådanne møder -også undervejs i projektet - så projektlederen beder projektdeltagerne om enkeltvis at skrive risici i projektet ned på post-its fordelt på risikoårsag, risikohændelse og risikoeffekt (se afsnittet vedrørende skabelonen for nærmere definition).

Efter 20 minutter er energien ved at ebbe ud, og projektlederen beder projektdeltagerne om enkeltvis at sætte post-its op på en tavle og forklare indholdet. Efter 2-3 fremlæggelser begynder der at tegne sig et billede af pro-jektets risici, og der kommer forskellige afarter af samme risici. Projektlederen begynder at spørge ind til, om denne risiko ikke hører til en anden risiko, hvorved risici begynder at bliver grupperet i forhold til risikohændelse.

Resultatet af brainstormingen er, at der identificeres 30-50 relevante risici i projektet.

Projektlederen indkalder styregruppen til en tilsvarende seance. For projektlederen er det vigtigt at få det ledel-sesmæssige og strategiske perspektiv på de allerede identificerede risici. Derudover beder projektlederen styre-gruppen om at identificere de 5-10 mest kritiske risici med det formål at fokusere på effektive, reducerende hand-linger på disse.

Tabel 8.1: Risikologgens risikobeskrivelse - identificeringstrinnet.

Risi-ko ID

Dato For-fatter

Risikotype Risikoårsag og hændelse Risikokonsekvens

1 23/5 PL Forretningsmæssige forhold

Projektets bemanding og afhængig-hed til nøglepersoner Omprioritering i myndighedens projektportefølje trækker ressourcer ud af projektet

Forsinkelse af leverancer til leverandøren og der-med også potentiel risiko for projektets fremdrift

2 23/5 PL Projektets tilrettelæg-gelse

Uklare aftaler om, hvordan leveran-cen skal udvikles og leveres Risikoen for at leverancen fra leve-randøren ikke bliver leveret til aftalt tid

Projektet får ikke til-strækkelig overblik over fremdriften og kvaliteten af leverancen

3 23/5 PL Markedsafklaring og teknisk løsning

Et mangelfuldt grundlag for dimen-sionering af produktionsmiljøet

Antal brugere på syste-met kan blive begrænset


Risi-ko ID

Dato For-fatter

Risikotype Risikoårsag og hændelse Risikokonsekvens

Risiko for at afprøvning af det kommende produktionsmiljø ikke kan honorere kravene til kapacitets-udvidelse

4 23/5 PL Interessenter Manglende deltagelse i styregruppen fra de decentrale Fritidsenheder Risiko for manglende forankring i den enkelte decentrale Fritidsenhed

Manglende opbakning til systemet fra ledelserne i de decentrale Fritidsen-heder kan give en lang og besværlig implementering

5 23/5 PL Slutbrugere og slutpro-dukt

Forretningens manglende informa-tioner til at understøtte systemet Risiko for at nødvendige informati-oner fra de kommende brugere af løsningen ikke kan opnås pga. travl-hed i forretningen

Systemet understøtter ikke de behov, som for-retningen har efterspurgt

Ved mødet diskuterer projektlederen og styregruppen hvilke retningslinjer, der skal være for eskalation til styre-gruppen, såkaldte advarselslamper, som kan sikre, at styregruppen løbende får indikatorer på projektets sundhed.

I Tabel 8.1 ovenfor ses et udpluk af de identificerede risici fra projektets identificeringsproces, som er lagt ind i risikologgen og efterfølgende hvilke advarselslamper, som projektet har fået aftalt med styregruppen.

Tabel 8.2: Advarselslamper – vurderes på månedsbasis.

Advarselslamper Grænse for eskalering til styregruppe og/eller kraftige-re tiltag

Antal nye risici der er identificeret siden seneste rapportering 3 eller flere nye risici med risikoværdier på 2 eller derover.

Antal indtrufne risici (hændelser) siden seneste rapportering 1 eller flere indtrufne risici med risikoværdier på 2 eller der-over.

Ændring i samlet risikoværdi i forhold til seneste rapporte-ring

Stigning i risikoværdi på 1 eller mere.

Absolut risikoværdi Nye eller gamle risici med en risikoværdi på 10 eller derover.

Potentiel indtræffen af risici Identificerede risici der kan indtræffe i indeværende rappor-teringsperiode.

8.2 Vurderingsprocessen

Efter projektlederen har identificeret projektets risici sammen med projektgruppen, vurderer projektlederen sandsynligheder og konsekvenser for de identificerede risici. Projektlederen vælger i første omgang at inddrage projektdeltagerne og kontorchefer fra Fritidsstyrelsens driftsenhed i processen, da de har stor viden om Fritids-styrelsen og de decentrale fritidsenheder. De indkaldes alle til en workshop, hvor der foretages vurdering af risici.

Først vurderer gruppen sandsynligheden for, at risikoen indtræffer, herefter analyseres og vurderes konsekvenser for projektudgifter, tid, kvalitet og gevinster.

For at opnå en effektiv proces beder projektlederen projektdeltagerne om at vurdere sandsynligheden for, at risikoen indtræffer i forhold til 5-punktsskalaen (hvor 1 svarer til, at der er 1-20 % sandsynlighed, og 5 svarer til 81-99 % sandsynlighed). Projektgruppen finder deres sandsynlighedsscore, og det viser sig, at der er stor enighed. Men for at sikre at niveauet er korrekt, beder projektlederen de to, der har vurderet sandsynligheden højest og


lavest, om at argumentere for deres beslutning, hvorefter alle får muligheden for at vurdere sandsynligheden igen. Herefter viser det sig, at sandsynligheden bliver en score lavere, da argumentationen for en lavere sandsyn-lighed har flyttet projektgruppens opfattelse af situationen.

Ud fra projektlederens erfaring kan konsekvenser være svære at sætte tal på. Derfor er der hjælpetekster til værdi-erne. Der opereres med en værdi fra 1-5 for de negative konsekvenser. Skalaen går fra 1, ubetydelige konsekvenser, til 5, meget store konsekvenser.

Efter at sandsynligheden og konsekvensen for de enkelte risici er fastsat, bliver der beregnet en risikoværdi. Pro-jektlederen dokumenterer arbejdet i risikologgen

Tabel 8.3: Risikologgens risikobeskrivelse - identificeringstrinnet.

Risiko ID

Risikoårsag og hændelse Risikokonsekvens Sandsynlig-hed

Konsekvens Risikoværdi

1 Projektets bemanding og afhængighed til nøglepersoner Omprioritering i myndighedens pro-jektportefølje trækker ressourcer ud af projektet.

Forsinkelse af leve-rancer til leverandø-ren og dermed også potentiel risiko for projektets fremdrift.

4 2 8

2 Uklare aftaler om, hvordan leverancen skal udvikles og leveres Risikoen for at leverancen fra leve-randøren ikke bliver leveret til aftalt tid

Projektet får ikke tilstrækkelig overblik over fremdriften og kvaliteten af leveran-cen

2 4 8

3 Et mangelfuldt grundlag for dimensi-onering af produktionsmiljøet Risiko for at afprøvning af det kom-mende produktionsmiljø ikke kan honorere kravene til kapacitetsudvi-delse

Antal brugere på systemet kan blive begrænset

3 4 12

4 Manglende deltagelse i styregruppens fra de decentrale Fritidsenheder Risiko for manglende forankring i den enkelte decentrale Fritidsenhed

Manglende opbak-ning til systemet fra ledelserne i de decen-trale Fritidsenheder kan give en lang og besværlig implemen-tering

3 5 15

5 Forretningens manglende informatio-ner til at understøtte systemet Risiko for at nødvendige informatio-ner fra de kommende brugere af løs-ningen ikke kan opnås pga. travlhed i forretningen

Systemet understøtter ikke de behov, som forretningen har efterspurgt

4 4 16

8.3 Planlægning

Projektlederen har identificeret og vurderet risici, så næste trin er at få planlagt mitigerende tiltag til at håndtere dem. Projektlederen vurderer, at flere risici er så store, at det er nødvendigt med en betydelig indsats for at mi-nimere sandsynligheden for, at de indtræffer. Derfor lægger projektlederen de mitigerende tiltag ind i projektpla-nen og business casen samt notificerer de deltagere i projektgruppen, der har ansvaret for at udføre de mitige-rende handlinger. Derudover kontakter projektlederen de udpegede risikoejere og sikrer, at de er opmærksomme på, at de har det overordnede ansvar for risici i projektet.


Projektlederen vurderer, at der er flere risici, som kræver, at der udarbejdes konkrete beredskabsplaner. Projekt-lederen estimerer de økonomiske konsekvenser, hvis risiciene indtræffer, og lægger omkostningerne til dette i business casen. På næste styregruppemøde drøfter projektlederen hvor stor andel af den økonomiske konse-kvens, som projektet skal budgettere i en risikopulje. Dette opdateres ligeledes i business casen.

Risikologgen ser herefter sådan ud:

Tabel 8.4: Risikologgen

Ris

iko

ID

Ris

ikoe

jer

Miti

gere

nde

tilta

g

Udf

ører

miti

-ge

rend

e til

tag

Lagt

i pr

ojek

t-pl

an

Lagt

i bu

dget

Sand

synl

ighe

d ef

ter t

iltag

Kon

sekv

ens

efte

r tilt

ag

Ris

ikov

ærd

ief

ter t

iltag

Ber

edsk

abs-

plan

, hvi

s ris

i-ko

indt

ræffe

r

Ber

edsk

abs-

plan

lagt

iris

ikop

ulje

1 Intern seniorleve-randør

Der udarbejdes indstilling til porteføljeboardet, der flager nødvendigheden af ressourcerne

Projekt-leder

Ja Nej 3 2 6 Der hyres eksterne konsulen-ter

Ja

2 Styregrup-peformand

Der udarbejdes kvalitets-plan for projektets leveran-cer, og dette skrives som krav i udbudsmaterialet

Projekt-leder

Ja Nej 2 2 4 N/A Nej

3 Intern seniorleve-randør

Der udarbejdes dimensio-neringsanalyse som indgår i udbudsmaterialet

Medar-bejder hos IT-afdelin-gen

Ja Ja 1 4 4 N/A Nej

4 Styregrup-peformand

Der afvikles roadshow om det nye system hos de decentrale enheder, og der placeres gevinstejerskab hos den enkelte enhed

Projekt-lede-ren/styre gruppen

Ja Ja 1 4 4 Hvis projektets imple-mente-ring bliver forsinket, vil det udskyde gevinst-realise-ringen med et halvt år (vurderet)

Ja

5 Seniorbru-ger

Projektet afholder intensive arbejdsdage om krav til løsning, så forretningen kun bliver påvirket i få dage

Projekt-lederen

Ja Ja 2 3 6 N/A Nej

Projektlederen følger løbende op på, om de mitigerende tiltag er blevet udført, når projektplanen bliver opdate-ret. Ligeledes følger projektlederen op på den økonomi, der er tiltænkt de mitigerende tiltag.

Når de mitigerende tiltag er gennemført, foretager projektlederen en revurdering af risikoen for at sikre, at sand-synligheden er blevet minimeret i det omfang, der blev forudsat. Projektlederen kan konstatere, at to af risiciene har fået den forudsatte lavere sandsynlighed, og dette opdateres i risikologgen uden at føje yderligere mitigerende handlinger til. Den sidste risiko har ikke fået lavere sandsynlighed, og derfor planlægger projektlederen nye miti-gerende tiltag.


8.4 Håndtering

Projektlederen har planlagt sine mitigerende tiltag og har identificeret, hvem der skal håndtere de mitigerende tiltag.

En række risici har projektlederen selv ansvaret for at håndtere. Projektlederen iværksætter arbejdet med at ud-færdige en indstilling til porteføljeboardet, udarbejde en kvalitetsplan og planlægge de intensive arbejdsdage med forretningen. Projektlederen sikrer sig, at styregruppen kender til fremdriften på disse opgaver.

For de opgaver der er uddelegeret, følger projektlederen op på fremdriften ift. projektets samlede tidsplan, for at sikre at risikoen er håndteret. Projektlederen opdaterer løbende risikologgen med ny information om risikoen.


Documents

Vejledning til risikostyring · Et andet vigtigt element er kommunikationen mellem projektlederen og styregruppen; i særdeleshed projekt- og gevinstejer. Projektlederen skal fokusere