Beslutningstræ for risikoeskalering

Hvad er beslutningstræ for risikoeskalering?

Eskalering går galt i to retninger. Risici, der burde være løftet op, ligger en måned i registret, fordi ingen følte sig berettiget til at rejse dem, og risici, ejeren selv kunne have håndteret, lander på et styregruppemøde, fordi det føltes mere sikkert at rejse dem end at beslutte. Begge fejl kommer af det samme hul: kriterierne findes i hovederne på folk frem for på et stykke papir. Et beslutningstræ for risikoeskalering lukker hullet ved at gøre hver test eksplicit og besvarbar ud fra dokumentation, så den samme risiko får den samme vej, uanset hvem der står med den.

Denne side er et beslutningstræ, ikke et procesdiagram. Den svarer på, hvilken mulighed der er den rigtige, og hvem der har beslutningsretten, så spørgsmålene løber ned gennem midten, og grenene ender forskellige steder. Et procesdiagram svarer på, hvad der sker nu, og hvem der gør det, så trinnene løber fra venstre mod højre og samles i én afslutning. Vil I have hele forløbet, der følger efter, at en eskalering er rejst, så brug flowchartet for incident management-processen på /da/templates/incident-management-proces, som dækker registrering, prioritering, erklæring af major incident, SLA-brud og lukning. Dette diagram stopper ved beslutningen om vejen; det andet tager over derefter.

Skabelonen bruger lette swimlanes, der navngiver, hvem der svarer på hvert spørgsmål, frem for at kortlægge afdelinger: Risikoejer, Projektleder, Styregruppe og Ledelsens risikoudvalg, fordelt på fem faser fra Registrering til Eskaleringsvej. Otte beslutninger ligger på rygraden, og kriterierne er skrevet ind i kommentarerne på de fire, der bærer reelle tærskler: screeningen for sikkerhed, jura og regulatoriske forhold, tolerancetesten, testen af budget og mandat samt konsekvenstærsklen. Fem navngivne slutpunkter erstatter den ene lykkelige sti, et procesdiagram ville bruge.

Hvad dette flowchart dækker

I denne skabelon

• Fire baner efter beslutningsret frem for et afdelingskort (Risikoejer, Projektleder, Styregruppe og Ledelsens risikoudvalg) fordelt på fem faser: Registrering, Screening, Tolerancetest, Tærskel og timing samt Eskaleringsvej.
• To screeningsspørgsmål, der springer scoringen helt over: 'Er risikoen allerede indtruffet?' og 'Sikkerhedsmæssig, juridisk eller regulatorisk eksponering?'. Et Ja på et af dem kan føre videre til 'Er skade eller brud nært forestående?', hvis Ja-gren kører 'Aktiver incident-proceduren' og ender i 'Eskaler straks som incident'.
• Den lokale gren: 'Inden for ejerens risikotolerance?' fører til 'Kan aktiv risikohåndtering betale sig?', hvor Nej ender i 'Accepter og registrer risikoen', og Ja fører til 'Håndtering inden for budget og mandat?': Inden for ender i 'Håndter lokalt med overvågning', mens Uden for sender risikoen op, selv om eksponeringen i sig selv var acceptabel.
• Fordelingen på 'Er konsekvensen over eskaleringstærsklen?': Over går direkte til 'Orienter formanden for risikoudvalget', mens Under falder ned til timingtesten frem for at eskalere på beløb alene.
• Timingtesten, der skiller de to eskaleringsveje ad: 'Skal der besluttes før næste styregruppemøde?' sender Ja uden for mødekadencen til formanden for risikoudvalget, og Nej videre gennem 'Udarbejd eskaleringsnotatet' til 'Eskaler til styregruppen'.
• Fem forskellige slutpunkter i stedet for én tragt: håndter lokalt med overvågning, accepter og registrer, eskaler til styregruppen, eskaler til ledelsens risikoudvalg, og eskaler straks som incident.

Hvornår du skal bruge skabelonen

• I skriver eskaleringsafsnittet i en risikostyringsplan, hvor kriterierne skal stå eksplicit frem for at være underforståede.
• I sætter nye projekt- eller risikoansvarlige ind i arbejdet, så eskalering styres af nedskrevne tests frem for af den enkeltes temperament.
• I skal afgøre en uenighed om beslutningsret: banerne siger, hvem der svarer på hvert spørgsmål, og det er som regel den reelle strid.
• I skal levere dokumentation til revision eller ledelse på, at eskaleringskriterierne findes, er aftalt og faktisk blev anvendt på en konkret risiko.
• I holder en post mortem på et forløb, hvor en risiko blev eskaleret for sent, og vil kunne spore, hvilken test der burde have udløst noget, men ikke gjorde det.

Sådan fungerer det

1. Omdøb banerne, så de matcher jeres reelle beslutningsret

   Erstat Risikoejer, Projektleder, Styregruppe og Ledelsens risikoudvalg med de organer, der faktisk har mandatet hos jer. Hold banerne til, hvem der svarer på hvert spørgsmål. Findes der ikke et risikoudvalg, så læg den bane sammen med styregruppen og skriv det, frem for at lade et organ blive stående i diagrammet, som aldrig mødes.

2. Skriv eskaleringstærsklen som et beløb og en varighed

   'Er konsekvensen over eskaleringstærsklen?' er død tekst, indtil I hæfter tal på. De fleste organisationer sætter et beløb bundet til det delegerede indkøbsmandat og et tidstal bundet til bufferen eller en kontraktlig milepæl, og lader så det, der overskrides først, være udløseren. Skriv begge på noden, så enhver kan anvende testen uden at spørge.

3. Definér tolerance særskilt for hver ejer

   'Inden for ejerens risikotolerance?' forudsætter, at tolerancen er delegeret og skrevet ned. Fastsæt den pr. ejer eller pr. risikokategori (ikke én gang for hele projektet), og angiv den i de samme enheder, som I scorer risici i. Er der ikke skrevet noget ned for en ejer, er det ærlige svar Nej, og risikoen går op.

4. Skil budget fra mandat

   'Håndtering inden for budget og mandat?' er bevidst to tests. En løsning kan være til at betale og alligevel kræve en beslutning, ejeren ikke har mandat til at træffe: for eksempel at ændre en kontrakt, opsige en leverandør eller acceptere en forsinkelse. Sæt navn på begge grænser, så grenen Uden for udløses af den rigtige grund.

5. Fastlæg incident-udløseren, og hvem der må trække i den

   Beslut, hvad der gør 'Er skade eller brud nært forestående?' til et Ja, og sæt navn på, hvem der må erklære det uden at vente på nogen. Det er den eneste gren, der springer governance over, så kriterierne skal være objektive nok til at kunne anvendes uden for arbejdstid, og den skal overlevere direkte til jeres eksisterende incident-procedure frem for at beskrive en ny.

6. Aftal vejen uden for mødekadencen, gå den igennem, og udgiv en version

   'Skal der besluttes før næste styregruppemøde?' virker kun, hvis der findes en reel vej uden for kadencen: en navngiven formand, en svartid og en måde at registrere beslutningen på. Test det færdige træ på tre-fire risici fra jeres eget register, ret de grene, der sender dem et åbenlyst forkert sted hen, og udgiv det derefter som en godkendt version, så folk ved, hvilken revision der gælder.

Ofte stillede spørgsmål

Hvad er forskellen på et beslutningstræ for risikoeskalering og en eskaleringsproces?

Et beslutningstræ svarer på et vejvalg: givet denne risiko, hvilken af mulighederne er den rigtige, og hvem har ret til at vælge. Formen er en kæde af tests, der ender i flere forskellige udfald. En eskaleringsproces svarer på, hvad der sker, når vejen er valgt: hvem der orienteres, hvilket materiale der forberedes, hvad det modtagende organ gør, hvordan beslutningen kommer tilbage, og hvordan den registreres. Formen er en kæde af trin, der samles i én afslutning. I har brug for begge dele, og de er nemmere at vedligeholde som to diagrammer. Brug dette træ til at vælge vejen, og flowchartet for incident management-processen til forløbet derefter.

Hvornår skal en risiko eskaleres frem for at blive håndteret lokalt?

Dette træ eskalerer på fire uafhængige udløsere, hvor én er nok. Eksponeringen ligger uden for ejerens nedskrevne tolerance. Håndteringen koster mere end det delegerede budget eller kræver en beslutning uden for ejerens mandat. Konsekvensen overstiger den aftalte økonomiske eller tidsmæssige tærskel. Eller risikoen har en sikkerhedsmæssig, juridisk eller regulatorisk dimension, og så forlader den den lokale vej uanset beløb, fordi tolerancen for netop den slags eksponering reelt er nul. Alt andet kan håndteres lokalt med overvågning eller accepteres og registreres, hvis ingen håndtering kan betale sig.

Hvad er forskellen på risikoappetit og risikotolerance her?

Appetit er den mængde og type risiko, organisationen overhovedet vil påtage sig; tolerance er den grænse, en konkret ejer må arbejde inden for, før andre skal involveres. Træet tester tolerance, fordi det er det operationelle spørgsmål, en risikoejer faktisk kan svare på en tirsdag eftermiddag. ISO 31000 fastsætter ikke tærskler for nogen af delene: standarden forventer, at organisationen selv definerer sine risikokriterier og holder dem konsistente med sine mål, så tallene på disse noder skal komme fra jeres risikostyringsplan og ikke fra en standard.

Hvad sker der, hvis risikoen allerede er indtruffet?

Så er det ikke længere en risiko. En risiko er en mulig fremtidig hændelse med en ejer og en håndtering; når den er indtruffet, er det en issue, og hvis skade eller brud er nært forestående, en incident. Derfor er 'Er risikoen allerede indtruffet?' det første spørgsmål i træet: et Ja forlader risikovejen helt, aktiverer incident-proceduren og ender i 'Eskaler straks som incident' uden at vente på en scoringsøvelse eller det næste styregruppemøde. PRINCE2 trækker den samme streg og behandler en indtruffet risiko som en issue frem for at blive ved med at styre den i risikoregistret.

Skal enhver eskalering vente på et planlagt styregruppemøde?

Nej, og træet gør det til en eksplicit test frem for en improvisation. 'Skal der besluttes før næste styregruppemøde?' tager en risiko, der ligger under konsekvenstærsklen, men er tidskritisk, og sender den uden for kadencen til formanden for risikoudvalget i stedet for at holde den tilbage, til mødekalenderen indhenter den. Værdien af at skrive testen ned er, at den også legitimerer det andet svar: kan beslutningen reelt vente, udarbejdes eskaleringsnotatet, og risikoen går til næste planlagte styregruppemøde, uden at nogen skal diskutere, om det var rimeligt.