Planview-bloggen

Din väg till smidighet i affärsverksamheten

Hantering av projektutbud

Riskbedömning av affärsidén: Hur man skriver en risklogg

Publicerad By Team AdaptiveWork

När ett problem eller en möjlighet har identifierats skapas en affärsidé som beskriver hur det kan lösas eller utnyttjas, hur mycket det kommer att kosta, hur det kommer att göras och vilka de sannolika resultaten kommer att bli. En information som ofta hamnar i bakhuvudet är riskbedömningen. Detta tillvägagångssätt är faktiskt en risk i sig självt, eftersom att erkänna, bedöma och planera för de risker som projektet står inför är avgörande för om projektet ska lyckas eller misslyckas.

Att skapa en riskbedömning är en oälskad del av affärsidén eftersom det är just i det skedet av projektet som man vill framhäva alla positiva aspekter, som hur stor förändringarna kommer att bli och vad en framgång kommer att innebära för organisationen och för den egna personen. Men vi är här för att hjälpa dig att inse att riskbedömning kan stärka din affärsidé, inte skada den.

Riskloggen

För att se till att din riskbedömning håller en standard som både redovisar och planerar för potentiella risker och som vinner projektintressenternas förtroende och stöd, är det viktigt att ha en omfattande risklogg av hög kvalitet (även kallad riskregister). Om du är osäker på hur en effektiv risklogg exakt ska se ut, går vi igenom de viktigaste delarna här.

Funktioner i en risklogg

  1. Referensnummer: Denna kolumn kommer att användas för att spåra och hänvisa till risken.
  2. Riskbeskrivning: Här ges en kort beskrivning av vad risken är. Det rekommenderas att du använder ett standardformat som t.ex: X kan uppstå på grund av Y, vilket orsakar Z. Testning av API kan fördröjas på grund av bristande tillgänglighet, vilket gör att tidsfristen för leverans inte hålls.
  3. Datum för uppkomsten: När risken identifierades, en nödvändig detalj för senare projektanalyser och till och med rättsliga åtgärder.
  4. Status: Här beskrivs vilket tillstånd risken befinner sig i, t.ex. Öppet, stängt, pågående eller under granskning.
  5. Sannolikhet: Hur sannolikt det är att risken inträffar. En standardskala bör användas, t.ex. Låg - hög eller 1 - 10.
  6. Allvarlighet: Hur stor risken är, vanligtvis beräknad genom att multiplicera sannolikheten med konsekvenserna (vilket innebär att en skala 1 - 10 i båda fallen ger en snygg "allvarlighetsgrad %").
  7. Konsekvens: Hur skadlig konsekvensen blir om den inträffar.
  8. Förmildrande åtgärder: Vad kan göras för att förhindra att risken uppstår. Detta kan omfatta risköverföring, t.ex. införa klausuler om ekonomiska sanktioner i säljarens kontrakt eller teckna en försäkring. I exemplet med API-testningen skulle en mildrande åtgärd vara att anställa tillfällig personal eller omfördela resurser.
  9. Beredskap: Hur risken kommer att hanteras om den inträffar. Om till exempel den tidigare nämnda API-testningen försenas måste kunden informeras och projektplanen ändras.
  10. Ägare: Den person som har det övergripande ansvaret för riskområdet.
Öka din affärsmässighet med Planview AdaptiveWorks programvara för projekthantering

Det är viktigt att viktiga projektdokument, som riskloggen, sprids brett, är tillgängliga och kan uppdateras av relevanta gruppmedlemmar och intressenter. Molnbaserad projektledningsprogramvara för flera användare, som Planview AdaptiveWork, gör detta enkelt att uppnå. Om du vill veta hur vi kan hjälpa din organisation att planera och hantera risker, kontakta oss idag för att organisera en kostnadsfri demonstration.

Relaterade inlägg

Skrivet av Team AdaptiveWork