RAID-loggar: definition, mall, exempel & guide

RAID Logs Explained in 60 seconds!

Vad är en RAID-logg och vad står ”RAID” för?

RAID står för risker, antaganden (eller åtgärder), problem och beroenden (eller beslut).

Definition av RAID-loggens komponenter	Exempel
Risker. Identifiera och kategorisera risker och möjligheter, sannolikheten för att de inträffar, deras påverkan/allvarlighetsgrad om de inträffar samt planen och åtgärderna för att begränsa dem	-Risk: Dåligt väder försenar tidsplanen för datainsamlingen
Antaganden eller Atgärder. Dokumentera projektets parametrar för att förhindra omfattningsglidning; upprätthåll en ”att göra”-lista baserad på det pågående projektarbetet	-Antagande: nödvändiga resurser är tillgängliga för att genomföra projektarbetet -Åtgärd: samarbeta med ekonomiteamet för att ta fram en kostnadsuppdelning för befintliga tredjepartsleverantörer
Iroblem. Dokumentera händelser som har inträffat och som påverkar projektets framsteg samt förklara vägen till en lösning	-Problem: Ett säkerhetsintrång äventyrar kunduppgifternas integritet
D: beroenden eller D: beslut. Lista aktiviteter som inte kan påbörjas eller slutföras utan att en annan aktivitet har påbörjats eller slutförts; dokumentera tidigare överenskomna handlingsalternativ och motiveringen till att genomföra eller inte genomföra dem	-Beroende: genomför en alternativanalys innan ett nytt system för leverantörshantering införskaffas -Beslut: bygg ett internt system för talanghantering för att behålla fokus på en högpresterande kultur, även om detta blir dyrare på kort sikt

Du ser att definitionen av RAID innehåller några dubbla akronymer: antaganden eller åtgärder, beroenden eller beslut. Här är mina egna tankar om hur du kan hantera dessa:

• Antaganden kontra åtgärder. Jag kan inte säga hur många gånger en lista över antaganden har stoppat omfattningsglidning innan den hunnit ta fart. Om du vill rikta loggen mot en senior målgrupp rekommenderar jag att du håller åtgärdspunkterna i ett separat dokument med fokus på taktiskt genomförande.
• Beslut kontra beroenden. Enligt min erfarenhet minns ingen någonsin varför besluten fattades: särskilt inte vilka alternativ som övervägdes men förkastades och varför. För att undvika cirkulärt tänkande under ett långvarigt uppdrag rekommenderar jag att du dokumenterar beslut i din RAID-logg utöver beroenden.

När bör du skapa en RAID-logg?

En RAID-logg bör skapas i början av ett projekt under initierings- eller planeringsfasen, när man vet tillräckligt om omfattning, intressenter och mål för att kunna identifiera inledande risker och antaganden. Därefter bör den gås igenom vid viktiga milstolpar, när omfattningen ändras eller när en betydande risk eller ett problem uppstår. I agila projekt är början av varje sprint ett naturligt tillfälle att uppdatera den.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Create Free Account

Have an account? Log In

RAID-logg jämfört med riskregister

Även om det finns en viss överlappning mellan dessa två dokument är skillnaden att en RAID-logg är mer omfattande än ett riskregister. Utöver att dokumentera risker innehåller en RAID-logg även antaganden eller åtgärder, en problemlogg samt beroenden eller beslut.

Mall för RAID-logg

Jag har inkluderat en nedladdningsbar mall för en RAID-logg i Microsoft Excel (du måste vara DPM-medlem för att få tillgång till mallen). Du kan använda den här mallen för att dokumentera risker, antaganden, problem och beroenden. Kolumnerna M och N används för att följa upp beslut och beslutsdatum.

Exempel på RAID-logg

Utöver mallen för RAID-loggen har jag även inkluderat en exempellogg i Excel, så att du får en uppfattning om det färdiga resultatet (du måste också vara medlem för att få tillgång till den).

Här är ytterligare ett exempel som visar hur RAID-loggar kan användas i ett projekt där man planerar en campingtur.

Så skapar du en RAID-logg

Nu när du har din mall klar, hur går du egentligen tillväga för att fylla i den? Under projektets planeringsfas kan du samla in innehåll till följande delar av din RAID-logg:

• Risker
• Antaganden
• Beroenden

Åtgärder, problem och beslut blir aktuella först efter att projektet har startat.

För varje post du registrerar bör du som minimum ange följande fält:

• Beskrivning — en kort sammanfattning av risken, antagandet, problemet eller beroendet
• Ansvarig — personen som ansvarar för att hantera eller lösa det
• Prioritet — hög, medel eller låg
• Status — öppen, pågående eller stängd
• Måldatum — när det behöver vara löst eller följas upp
• Åtgärds- eller hanteringsplan — de steg som vidtas för att hantera det

Genom att använda samma fält för varje post blir loggen lättare för intressenter att överblicka och enklare att underhålla över tid.

Möjliga informationskällor för en RAID-logg

Du kan hämta innehåll till loggen från flera olika källor:

• Intressentintervjuer
• Aktuell eller tidigare projektdokumentation
  • Exempel: mall för lärdomar, retrospektiv, efteranalyser, projektstadgar, projektplaner, projektscheman
• Tidigare erfarenhet av att genomföra liknande projekt
• Öppet källmaterial online
• Kritiskt tänkande baserat på information du har samlat in från ovanstående källor (till exempel att dina intressenter inte uttryckligen säger att något är ett problemområde, men att deras ovilja att ta upp ämnet antyder att detta område skulle ha nytta av ytterligare kartläggning.)

Bästa praxis

När projektet har startat och du har din preliminära RAID-logg redo, bör du tänka på följande bästa praxis för hur du använder loggen när du leder projektet:

• Anpassa detaljnivån efter målgruppen. Intressenter förlitar sig på RAID-loggen för att förstå sammanhanget för projektet samt eventuella risker eller problem som kan hota projektets framgång. Fokusera på verksamhetens konsekvenser i stället för taktiska uppdateringar som kanske inte är meningsfulla för någon som inte deltar i det dagliga arbetet.
• Övervaka och uppdatera loggen under hela projektets livscykel. Artefakten är oanvändbar om du inte uppdaterar den och för in informationen i annan dokumentation, till exempel en beslutslogg. Det är ytterligare en anledning att hålla innehållet kortfattat, så att dokumentet inte blir betungande att underhålla. Den mesta av din tid bör ägnas åt att lösa problem, inte åt att dokumentera dem.

Fördelar

RAID-loggar gynnar intressenter, projektteammedlemmar, verksamheten och dig som projektledare.

• Det är en samlad plats för relevant projektinformation som ger lättillgängliga insikter i projektets status i realtid
• Det ger möjlighet att spåra risker innan de blir problem och därefter snabbt prioritera och hantera problem om riskerna förverkligas
• Projektledare kan dokumentera antaganden och beslut för att minska risken för att behöva gå tillbaka till diskussioner som kan försena projektet.

Hur används RAID-loggar i agila projekt?

Vanligtvis brukar agila projekt undvika dokumentation till förmån för att utveckla en fungerande produkt. Med det sagt vill jag hävda att det är värt den extra ansträngningen att utveckla en RAID-logg.

Anledningen? Agila projekt följer vanligtvis ett iterativt tillvägagångssätt för projektgenomförande som uppmuntrar till mer experimenterande. Detta tillvägagångssätt är utmärkt när man vill misslyckas snabbt för att snabbare dra lärdomar.

Att minska stigmat kring misslyckanden medför dock ytterligare risker som kan få projektet att spåra ur. Och en organisation kan bara lära sig av misslyckanden om den dokumenterar de antaganden och den beslutsprocess som låg till grund för varje experiment.

Vad händer härnäst?

Om du behöver mer hjälp med riskhantering kan du överväga att gå vår kurs i att bemästra digital projektledning. Utöver riskhantering får du också lära dig att leda projekt under hela projektets livscykel, från initiering till projektavslut.