Beslutningstræ for risikoeskalering
Beslutningstræ for risikoeskalering med tolerance, konsekvenstærskel, mandat og hastegrad — og navngivne udfald fra lokal håndtering til øjeblikkelig eskalering som incident.
Sådan fungerer det
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.
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.
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.
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.
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.
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.