Flowchart for risikostyring i projekter (fra risikolog til lukning)
Flowchart for risikostyring i projekter: log risikoen, vurder sandsynlighed og konsekvens, eskaler, vælg en håndteringsstrategi, revurder ved hver gennemgang, og luk risikoen eller opret et issue.
Sådan fungerer det
Omdøb banerne, så de passer til jeres styringsmodel
Erstat Projektteam, Risikoejer, Projektleder, Styregruppe og PMO med de roller og fora, I reelt har. Hold risikoejeren adskilt fra projektlederen: den ene bærer risikoen, den anden kører processen. Har I ingen PMO, så læg banen ind under projektlederen frem for at lade et forum stå i diagrammet, som aldrig gør noget — og er styregruppe og projektejer samme person hos jer, så skriv det.
Skriv eskaleringsgrænsen som tal
'Over eskaleringsgrænsen?' er tom, indtil I hænger tal på. De fleste projekter sætter et beløb, der følger projektlederens bemyndigelse til at disponere, og et tidsmæssigt tal knyttet til buffer eller en kontraktlig milepæl, og lader den, der brydes først, være udløseren. Tilføj en vej, der ser helt bort fra scoren ved sikkerheds-, juridisk, regulatorisk eller omdømmemæssig eksponering — de eskalerer på deres art, ikke på deres score.
Fastlæg risikologgens obligatoriske felter
Beslut, hvad 'Log risikoen i risikologgen' skal fange: årsag, hændelse og virkning som hvert sit felt, dato for oprettelse, foreslået ejer, den berørte arbejdspakke eller milepæl, sandsynlighed og konsekvens med datoen for scoringen, den valgte strategi, handlingerne med frister og den aktuelle status. Alt, der gøres valgfrit, står tomt inden for en måned, og en risiko skrevet i tre ord kan ikke revurderes af nogen, der ikke sad med i lokalet.
Læg gennemgangskadencen fast — og hvad der trækker den frem
Løkken drejer kun, hvis der er en planlagt gennemgang. Hæng den op på projektets eksisterende rapporteringsrytme frem for at opfinde et nyt møde, gennemgå højt scorede risici oftere end resten, og navngiv de begivenheder, der udløser en revurdering før tid: et leverandørskift, en overskredet milepæl, en ny afhængighed, en scopeændring, en hændelse eller en mitigering, der skrider. En risikolog, der kun røres før styregruppemødet, er retvisende én dag om måneden.
Gør mitigeringshandlingerne virkelige
'Tildel handlinger med ejer og frist' betyder én navngiven person pr. handling, en deadline og en linje i projektplanen med timerne i. Handlinger, der kun lever i risikologgen, konkurrerer med det arbejde, alle bliver målt på — og taber. Følg dem der, hvor teamet i forvejen kigger, og lad risikoejeren rapportere fremdrift på gennemgangen frem for at rapportere, at risikoen er uændret.
Aftal reglen for risiko til issue, og udgiv en version
Definer, hvad der tæller som indtruffet, hvem der må erklære det uden at vente på et møde, og hvordan krydshenvisningen bæres begge veje, så historikken overlever konverteringen. Gå derefter det færdige diagram igennem med projektlederen, en risikoejer og den, der leder styregruppen, ret det til det, de faktisk gør, og udgiv den revision — behold de tidligere, så enhver, der åbner den senere, kan se, hvilken version de læser.
Ofte stillede spørgsmål
Hvilke trin består risikostyring i et projekt af?
Identificer risikoen, log den med årsag og virkning, få en navngiven ejer til at acceptere den, vurder sandsynlighed og konsekvens, afgør om den bryder eskaleringsgrænsen, vælg en strategi blandt undgå, reducer, overfør og accepter, tildel mitigeringshandlinger med ejer og frist, revurder risikoen ved hver gennemgang, konverter den til et issue, hvis den indtræffer, og luk den, når dens vindue er passeret. Metoderne bruger forskellige ord om den samme rygrad — PRINCE2 beskriver en risikoprocedure, der løber fra identifikation og vurdering over planlægning og gennemførelse af tiltag med kommunikation ved siden af, og de tidligere procesbaserede udgaver af PMBOK-guiden skilte planlægning af et tiltag fra gennemførelsen og overvågningen af det. Det, der fejler i praksis, er sjældent listen. Det er vejen tilbage til fornyet vurdering.
Hvad er forskellen på en risiko og et issue?
En risiko er usikker: den kan indtræffe eller lade være, så den beskrives som årsag, hændelse og virkning og har en sandsynlighed. Et issue er allerede sket eller er nu sikkert. De håndteres forskelligt, og derfor er skellet værd at håndhæve. En risiko får en strategi og mitigeringshandlinger før hændelsen; et issue får inddæmning, en genopretningsplan og ofte en ændringsanmodning på den tid eller de penge, det koster. Holder man begge dele i én liste, fyldes risikologgen med ting, der ikke længere kan mitigeres, og de reelt usikre poster forsvinder i mængden. I dette diagram er konverteringen en eksplicit gren: 'Er risikoen indtruffet?' opretter et issue i projektet, posten i risikologgen lukkes som indtruffet, og krydshenvisningen bæres begge veje.
Hvad er de fire strategier til risikohåndtering?
Undgå, reducer, overfør og accepter. Undgå fjerner årsagen, som regel ved at ændre scope, rækkefølge eller fremgangsmåde, og det er den eneste, der tager risikoen helt af loggen frem for at skrumpe den. Reducer sænker sandsynlighed, konsekvens eller begge dele, og det er der, de fleste mitigeringshandlinger lander. Overfør flytter konsekvensen til en anden part gennem en fastpriskontrakt, en ansvarsklausul eller en forsikring, og det er den mulighed, der oftest overvurderes: den flytter typisk den økonomiske konsekvens og efterlader leveringskonsekvensen hos projektet. Accepter betyder at bære risikoen bevidst, med en navngiven godkender, en afsat reserve og en revurderingsdato — en risiko, ingen har afsat penge til, er ikke en accepteret risiko. Behandler jeres metode muligheder som positiv risiko, har de spejlvendte strategier: udnyt, forstærk, del og accepter.
Hvem bør eje en risiko i et projekt?
Én navngiven person, tæt nok på årsagen til at opdage, at den ændrer sig, og højt nok placeret til at kunne gøre noget ved den. I praksis er det som regel en delprojekt-, fag- eller leverandøransvarlig frem for projektlederen, der ejer processen og ikke hver enkelt post i den. To mønstre giver de fleste problemer: ejerskab lagt på et team eller en afdeling, hvor ingen revurderer risikoen, fordi ingen bestemt blev bedt om det, og alle risici ejet af projektlederen, hvilket gør risikologgen til en personlig to-do-liste, der holder op med at blive scoret. Derfor er 'Accepter ejerskab af risikoen' et selvstændigt trin før vurderingen i dette diagram — en ejer, der aldrig har sagt ja, møder ikke op til gennemgangen.
Hvordan adskiller siden sig fra et flowchart for risikovurderingsprocessen?
De dækker forskelligt terræn. Et flowchart for risikovurderingsprocessen er metoden: hvordan kriterier og skalaer aftales, hvordan risici beskrives, hvordan iboende og residual score fremkommer, hvordan de eksisterende kontrollers effekt bedømmes, og hvordan et tiltag vælges. Den skrives én gang og gælder på tværs af organisationen. Denne side er den projektnære driftscyklus, der bruger de skalaer — rejs, log, ejerskab, vurder, eskaler, håndter, handl, gennemgå, konverter eller luk — hen over ét projekts levetid, med en styregruppe, en PMO og en issue-log i sig. Skal I definere, hvordan risici scores, så brug skabelonen for risikovurderingsprocessen. Skal I definere, hvordan jeres projekt driver sin risikolog uge for uge, så brug denne.