Hur skriver man en riskanalys? apr 29, 2020 Av Michelle Nordqvist En riskanalys skrivs för att på ett proaktivt sätt hålla koll på de risker som finns, gradera dem efter hur allvarliga de är samt skaffa en plan för hur man eventuellt kan behöva lösa de problem som uppstår. Riskanalyser kan appliceras på många delar av verksamheten och kanske används de inte i den utsträckning de faktiskt borde. Det är ett utmärkt sätt att hålla koll på rörliga risker i ett webbprojekt och det är oftast upp till projektledare, produktägare och/eller styrgrupp att ansvara för denna. En riskanalys kan användas under hela projektets gång. Särskilt viktig är den vid planeringen av projektet och inför milstolparna. Med hjälp av riskanalysen kan man vara observant på de viktigaste riskerna och stämma av dessa löpande för att säkerställa att läget inte förvärrats och i så fall vara redo att sätta in eventuella åtgärder. När man skriver en riskanalys brukar man utgå ifrån tre delar, att; hitta riskerna, beräkna riskerna och åtgärda riskerna. 1. Vilka risker finns? Det första man gör i en riskanalys är att hitta riskerna. Här listar man alla de risker som kan tänkas finnas kring projektet. Som en hjälp kan man utgå ifrån följande kategorier: Personella Risker kan vara individbaserade. Vad händer om produktägaren blir sjuk/säger upp sig. Vad händer om vår expert på ämnet försvinner ur projektet? Finns det eventuell kompetensbrist på något område? Kundrelaterade Vilka risker kan drabba kunderna? Processuella Vad händer om det uppstår förseningar någonstans i leveranskedjan? Till exempel ett beslut från ledningen dröjer eller att innehåll och översättningar inte är på plats i tid? Tidsberoende En lösning visar sig vara svårare att bygga än beräknat eller försening av beslut flyttar fram leveransdatum. Vilka risker finns det som kan försena leveranstiden? Finansiella Vilka faktorer kan påverka att budgeten springer iväg? Eller finns det risker med att budgeten minskas om det sker förändringar någon annanstans i företaget? Är man beroende av räntor eller avgifter någonstans? Tekniska Finns det tekniska förutsättningar att ta hänsyn till? Ska man till exempel bygga nytt eller uppgradera befintligt? Vilka risker finns förenat med detta? Miljömässiga Finns det saker i samhället som kan vara en eventuell risk? Naturkatastrofer eller sjukdomsutbrott i samhället? Hur påverkar det vårt projekt? Politiska Kan det komma politiska beslut som påverkar projektet eller kan ett regeringsskifte påverka? 2. Hur allvarliga är riskerna? När riskerna är listade är det dags att ta reda på vilka risker som är viktigaste att bevaka. Detta görs genom en uträkning som multiplicerar konsekvensen det får på projektet med sannolikheten att risken blir ett reellt problem. riskvärde = konsekvens * sannolikhet Man kan sätta olika graderingar men ett vanligt sätt är att gradera från 1 till 5. För att göra det enklare att förstå ska vi göra en beräkning på en fiktiv risk. Risk: Vi har brist på kompetens/erfarenhet inom webbprojekt och det kan potentiellt försena projektet. Konsekvens: 5 (vi måste lansera på utsatt datum och om risken påverkar projektet får det stora negativa konsekvenser) Sannolikhet: 2 (det är i nuläget ganska låg sannolik att det inträffar, vi tror att vi har koll på det) riskvärde = konsekvens * sannolikhet = 5 * 2 = 10 Det är vanligt att man också väljer att färgkoda riskerna för att ha bättre kontroll på dem. Det kan till exempel göras enligt bilden nedan. I vårt exempel skulle vår risk vara gul. En grön risk kan ses som att man vet att den finns, men sannolikheten att den ska inträffa är låg och konsekvensen om den inträffar inte särskilt stor. Beroende på projekt kanske man väljer att stämma av de gröna riskerna en gång i månaden. Gula risker ska man hålla under uppsikt utifall att konsekvens eller sannolikhet av olika anledningar ändras. Gula risker har en låg sannolikhet/hög konsekvens, hög sannolikhet/låg konsekvens eller medelstor sannolikhet och konsekvens. Beroende på projekt kan man välja att stämma av de gula riskerna en gång i veckan. Röda risker är de mest kritiska, det är både stor sannolikhet att de inträffar och har en stor konsekvens på projekt/verksamhet. Dessa risker skall hållas under ständig bevakning och åtgärdsplan ska aktiveras. Beroende på projekt kan man vilja stämma av de röda riskerna en gång om dagen. När man stämmer av riskerna är det viktigt att analysera om läget har förändrats sedan man senast tittade på riskerna. Av olika anledningar kan en eller båda parametrarna sannolikhet och konsekvens ha ändrats. Vi tar vårt fiktiva exempel igen. Konsekvensen av att ha en kompetensbrist i projektet med en försening av lansering som följd är fortfarande en 5:a. Men efterhand som projektet fortskrider får man bättre insikt i hur stor kompetensbrist man har och dess eventuella konsekvens. Därför väljer man vid sin veckoavstämning att höja sannolikheten från 2 till 3. Detta ger oss följande uträkning: riskvärde = konsekvens * sannolikhet = 5 *3 = 15 Vår fiktiva risk har därmed gått från en gul till en röd risk och åtgärder för att förhindra att projektet påverkas måste kopplas in skyndsamt. 3. Hur åtgärdar vi riskerna? Den sista delen av riskanalysen är att sätta upp ett riskdokument och lista åtgärder för respektive risk. Detta gör man för att undvika att pressa fram lösningar på problem under en stressad eller pressad situation. Då fattar man sällan de bästa besluten. I god tid innan situationen uppstår listar man istället potentiella åtgärder på de risker man ser. Här går det bra att lista flera möjliga åtgärder för att kunna välja den mest lämpade åtgärden beroende på vilken situation eller tid man befinner sig i. Relaterade artiklar Så skriver du ett business case Med ett business case lägger du grunden för din kommande digitala lösning. Så blir du en bättre beställare av webblösningar En hög andel av alla digitala projekt fallerar. Hur kan du bli en bättre beställare? Användartester - och varför Google Analytics inte talar hela sanningen Varför borde man arbeta mer med att testa av sina produkter eller tjänster direkt mot användarna?
Så skriver du ett business case Med ett business case lägger du grunden för din kommande digitala lösning.
Så blir du en bättre beställare av webblösningar En hög andel av alla digitala projekt fallerar. Hur kan du bli en bättre beställare?
Användartester - och varför Google Analytics inte talar hela sanningen Varför borde man arbeta mer med att testa av sina produkter eller tjänster direkt mot användarna?