Meny
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.
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:
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.
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.
Vad betyder MVP och vad är dess fördelar?MVP är en förkortning för Minimum Viable Product. Det är ett viktigt koncept inom mjukvaruutveckling.
Hur förbättrar man den digitala kundupplevelsen?Hur mäter man och optimerar man CX – Customer Experience?
Fast pris eller agilt arbetssätt?Fast pris känns tryggt men det finns ingen garanti för att man blir nöjd. Med en “agil budget” ligger garantin istället i att slutresultatet kommer att bli bra.
Så skriver du ett business caseMed ett business case lägger du grunden för din kommande digitala lösning.
