Vad är en RAID-logg (och hur integrerar man en i projektets arbetsflöde)?

Läs transkriberingen:

Vi provar att transkribera våra poddar med hjälp av ett program. Ursäkta eventuella stavfel eftersom roboten inte har rätt 100 % av gångerna.

Galen Low: Du söker maniskt i inkorgen igen. Den här gången letar du efter mejlet från chefen som bekräftar ett beslut om projektet. Vad hette personen? Vad var beslutet? Allt står stilla tills du hittar det, så du sätter på en kanna kaffe och fortsätter leta. Det här kommer att bli en lång natt.

Vi ska utforska det praktiska med RAID-loggar och hur man integrerar dem i projektets arbetsflöde, så att du kan driva samtal med dina intressenter, enkelt kommunicera projektets status och aldrig mer behöva tillbringa timmar med att leta efter det där mejlet från chefen.

Hej allihop, tack för att ni lyssnar. Jag heter Galen Low och arbetar med Digital Project Manager. Vi är en gemenskap av digitala yrkesverksamma med målet att hjälpa varandra att bli skickligare, tryggare och mer sammanlänkade, så att vi kan förstärka värdet av projektledning i en digital värld. Om du vill höra mer om det kan du gå till thedigitalprojectmanager.com.

Okej, idag pratar vi om RAID-loggar och den balanserade konsten att följa upp projektrisker, åtgärder, problem och beslut för att styra projekt mot framgång.

Med mig idag är Kim Essendrup, tidigare verksam inom Kolme Group – en organisation som är fast besluten att hjälpa företag att bygga in datadrivet beslutsfattande i sina processer. Många av er känner honom säkert också som en av de två grundande programledarna för den mycket populära podden PM Happy Hour.

Välkommen, Kim!

Kim Essendrup: Hej, Galen! Tack för att jag fick komma.

Galen Low: Tack för att du är med. Herregud, det här är ett kändisögonblick för mig. PM Happy Hour är så rolig. Varje avsnitt jag har lyssnat på har varit ett enda stort skratt.

Jag är faktiskt avundsjuk på din podd. Jag tycker att den är fantastisk. För de lyssnare som inte känner till den: gå och lyssna. Den har en väldigt bra dynamik. Jag undrade om jag kunde börja med en riktig fanfråga: vad fick dig att starta podden PM Happy Hour från första början?

Kim Essendrup: Först måste jag säga att jag faktiskt också är ett stort fan av dig, så känslan är ömsesidig. Jag coachade många projektledare och märkte att jag upprepade samma råd om och om igen. Jag tänkte att jag kunde lägga allt i bloggen och att folk skulle läsa den. Sedan insåg jag att människor verkligen inte tycker om att läsa blogginlägg på 10 000 ord om projektledning.

Det är inte särskilt roligt. Jag arbetade också med ett annat litet nystartat företag inom ett annat område, och konsulten sa: du borde göra en podd. Jag tog mig igenom hela processen, lärde mig hur man gör, skaffade en mikrofon och gjorde det för det andra företaget. Det ledde egentligen inte så långt, förutom att jag kom in i poddsvängen.

Jag lärde mig hur allt fungerade och tänkte att jag kanske kunde göra några av blogginläggen intressanta på riktigt. Sedan funderade jag på vem som var den enda personen jag kunde få med i en podd som till och med kunde göra projektledning intressant.

Det var självklart Kate. Jag kontaktade Kate och frågade om hon ville göra den här galna grejen, och Kate var helt med. Sedan dess har det bara blivit roligare och roligare.

Galen Low: Jag älskar det. Dynamiken är verkligen bra. Det känns nästan som att lyssna på morgonradio, riktigt bra morgonradio. Det är roligt småprat, men samtidigt handlar det om projekt.

Jag tänker: ja, det här är min grej. Hur som helst är jag ett stort fan. Så om ni inte har lyssnat på PM Happy Hour, eller Project Management Happy Hour, finns den på nästan alla poddappar jag har sett.

Kim Essendrup: Alla vi kunde hitta.

Galen Low: Där ser man. Fantastiskt. Okej, då dyker vi ner i ämnet.

Idag ska vi nörda ner oss i RAID-loggar. Kan du börja med att definiera vad en RAID-logg är för dig och varför den är viktig?

Kim Essendrup: Ja. Om man ska uttrycka det så enkelt som möjligt är RAID-logg ett akronym för Risker, Åtgärder, Problem och Beslut. Vissa organisationer föredrar antaganden och beroenden i stället för åtgärder och beslut, men det kan vi prata om lite senare.

Huvudidén är att det handlar om riskregistret, åtgärderna och alla de register som man lär sig att skapa, särskilt om man följer någon PMI-metod. Historiskt har vi följt upp de här sakerna genom att samla dem i samma kalkylblad. Det var gammaldags redan när jag började arbeta med projektledning för flera decennier sedan.

Det har alltså funnits länge och är ett oumbärligt operativt verktyg som hjälper projektledare att driva sina projekt. I våra undersökningar ser vi att ungefär hälften till två tredjedelar av projektledarna har använt eller känner till det. Det är ett mycket viktigt verktyg, och därför försöker vi sprida kunskap om det.

Galen Low: Väldigt intressant. Jag var en av dem som inte riktigt hade insett det, men jag satt i ett möte och pratade med människor om vår RAID-logg. Jag hade lärt mig modellen med risker, antaganden, problem och beroenden. Då räckte någon upp handen och frågade om det verkligen var rätt modell. Vi började diskutera vilken variant man föredrar och varför.

Kim Essendrup: Jag föredrar åtgärder och beslut. Om man tänker på ett antagande är det ett planeringsantagande. Jag ska genomföra det här projektet – vilka antaganden har vi om omfattningen eller när vi utvecklar planen? Ett antagande är något som fungerar som en indata i början.

Ett antagande blir egentligen en risk, eftersom ett ogiltigt antagande innebär en risk. Därför faller antaganden naturligt in under R för risk. Detsamma gäller beroenden. Om du har ett externt beroende i projektet är det antingen en risk eller något som hör hemma i själva projektplanen, eftersom det är kopplat till tid och kanske har föregångare och efterföljare.

Det hamnar vanligtvis på någon av de platserna. Ibland är externa beroenden så skrämmande att de förtjänar en egen flik, och då blir det kanske RAIDD. Men om du fokuserar på åtgärder och beslut handlar det om mer operativa saker – sådant du måste hålla koll på under projektets genomförande. Då används din RAID-logg i det dagliga arbetet för att styra dig själv och hålla ordning.

Galen Low: Jag gillar det. Det handlar om att driva arbetet framåt, och jag håller helt med. Jag fastnade vid tanken att alla mina antaganden och beroenden faktiskt var risker. I mina projekt var de alla formulerade som risker, och jag visste inte om jag gjorde rätt.

Kim Essendrup: Det kan faktiskt vara det bästa sättet att börja riskloggen: utgå från alla antaganden och beroenden som hela planen bygger på.

Galen Low: Och när du motbevisar eller bekräftar vissa av antagandena kan du ta bort dem. Jag gillar det. Vi pratade om hur viktig en RAID-logg är, särskilt när det gäller beslut. Att samla allt i en logg i stället för att ha åtta olika dokument som människor måste granska och hålla uppdaterade – och som de egentligen inte tittar på under projektets gång.

Kim Essendrup: Annars måste du söka igenom Outlook och undra var det där mejlet tog vägen.

Galen Low: Jag är kungen av Outlook-sökningar eftersom jag är kungen av att inte organisera inkorgen alls. Men det låter helt rimligt. Du nämnde tidigare att detta förstås handlar om risk, men också om att förhindra att projektet hamnar i katastrofala situationer. Hur använder man praktiskt en RAID-logg för att åstadkomma det?

Kim Essendrup: Jag brukar tänka att man använder den för att driva eller rädda ett projekt. Drivdelen är viktig, för om du inte arbetar förebyggande kommer du förmodligen att behöva rädda projektet senare.

Om du tänker på verktygen du använder för att hantera projekt har du planen eller backloggen – alla aktiviteter som direkt bidrar till eller skapar leveranserna. Det är bra, och det är det vi gör. Men RAID-loggen handlar om hur du ser till att de sakerna faktiskt blir gjorda på rätt sätt.

RAID-loggen är inte planen; den är sättet du säkerställer att planen genomförs. Och vem har egentligen ett projekt som går helt perfekt? Om du har det är du mycket lyckligt lottad. Du kommer att få problem och utmaningar. Saker kan gå fel och saker går fel.

Vad använder du då för att hantera det? Inte tidsplanen, utan RAID-loggen. Den hjälper dig att identifiera vad som kan gå fel, vilka åtgärder du måste hålla koll på för att inte hamna efter, vilka problem som har uppstått och hur du löser dem så snabbt som möjligt.

Den hjälper dig också att se vilka beslut du måste förvänta dig, planera för, genomföra eller reagera på – även sådana du inte tänkte på i början av projektet. Det är sådant som hjälper oss att hålla projektplanerna på rätt spår och leverera framgångsrikt.

När du inte tänker på risker, planerar för beslut eller dokumenterar dem börjar planen falla sönder. Det handlar egentligen om att hantera grunderna. Det är ofta där projekt går fel: när man inte tar hand om det grundläggande och håller koll. Det är magin med en RAID-logg. Den är otroligt enkel, men mycket viktig för att hjälpa oss att hålla ordning på grunderna.

Galen Low: Du nämnde att du har arbetat med coachning. Har du några exempel där något höll på att spåra ur och du insåg att det kunde lösas med något så enkelt som en RAID-logg?

Kim Essendrup: Ja. För några år sedan tog jag över en PMO-organisation i Europa. Det var roligt eftersom jag fick företagsfinansierade resor dit, men jag bodde fortfarande i Phoenix-området och åkte dit ungefär en gång i månaden.

När man tar över rollen som PMO-chef ansvarar man också för alla bränder. Det var en fredag, och när man får ett telefonsamtal om ett projekt på en fredag är det aldrig goda nyheter. De sa att projektet gick så dåligt att kunden hotade att kräva ersättning och säga upp avtalet.

På måndagsmorgonen var jag inte längre i Phoenix utan i Midlands i Storbritannien. Jag var tvungen att få kontroll över projektet. Kunden var fullständigt rasande.

Jag var där med hela vårt team. Kunden gick igenom alla problem och jag tänkte att det lät berättigat. Jag hade också varit upprörd. Sedan frågade jag vårt team om de hade några problem.

De började genast berätta att kunden inte hade gett dem saker de behövde och att vi inte hade fått all information för att lyckas. Kunden svarade att de inte hade fått veta något av detta. Jag väntade tills alla hade tystnat och frågade om de kunde visa mig sin RAID-logg.

Det blev helt tyst. Jag visste inte om de inte visste vad en RAID-logg var eller om de skämdes över att de inte hade någon. Så jag öppnade datorn och skapade en RAID-logg.

Jag började dokumentera alla problem. Alla fick berätta och avreagera sig. Jag visade loggen på projektorn och skrev ner allt. På så sätt kunde jag bekräfta alla deras bekymmer. De kände att de äntligen blev hörda eftersom de såg att jag skrev ner det.

Sedan frågade jag vårt team vad deras problem var. Det visade sig vara samma sak. Jag dokumenterade allt och vi började se att mycket handlade om beroenden – saker som den ena parten förväntade sig av den andra.

Under eftermiddagen slutade vi gradvis att sitta vända mot varandra och argumentera. I stället vände vi stolarna mot projektorn. Vi kämpade inte längre mot varandra, utan mot problemen.

Det visar verkligen hur en RAID-logg kan användas för att lösa ett problem. Den skapar en plattform för samsyn, hjälper alla att förstå varandra och ger oss en gemensam bild av problemen som vi kan arbeta tillsammans med att lösa. Den kan verkligen vända sådana situationer eller åtminstone hjälpa dig att få kontroll över dem.

Galen Low: Jag älskar den berättelsen och också kroppsspråket. I stället för att vara konfrontativa och sitta mittemot varandra börjar alla luta sig mot samarbete.

En sak vi ofta underskattar i projektledningens tekniker, metoder och processer är att allt ska underlätta kommunikation och samarbete. Om du inte gör detta kan vi inte göra det där, men ibland handlar det om att du gör detta så att vi kan göra det där. Om människor inte ser sambanden blir det svårt att förstå varför en uppgift är viktig. Då skjuts den upp och plötsligt är projektet långt från där det behöver vara.

Det handlar ibland bara om att hålla reda på det vi behöver följa upp. Det är inte konstigt att man inte kan komma ihåg hundratals saker under ett projekt.

Kim Essendrup: Nej, verkligen inte. Det är en sak att prata om ett beslut, ett beroende eller en risk i ett möte. Men när du skriver ner det i ett dokument, särskilt ett delat dokument på Zoom eller en projektor, och dessutom skriver dit människors namn, blir det plötsligt verkligt.

Om mitt namn står där börjar jag automatiskt vara uppmärksam. Därför är det ett utmärkt kommunikations- och ansvarighetsverktyg. När jag coachar projektledare brukar jag säga att om du kommer till en ny miljö eller tar över ett projekt ska du skaffa en RAID-logg om det inte redan finns en.

Ett av mina favorituttryck är att man ska behandla RAID-loggen som om den kan bli föremål för ett föreläggande att lämna ut dokumentation. En dag kan det faktiskt hända, och då önskar du att loggen var uppdaterad.

Galen Low: Absolut. Jag har varit med i projekt som granskats av olika skäl. Att inte ha rätt dokumentation tillgänglig, även om informationen finns någonstans, innebär att man måste lägga tid på att hitta den. En tydlig dokumentationskedja över vad som hände, vilka risker som fanns och hur vi pratade om dem kan vara enormt värdefull.

Kim Essendrup: Jag kan tänka mig att det fick dig att vakna snabbt den morgonen när du fick veta att det skulle bli revision.

Galen Low: Herregud, ja. Öppna tidrapporteringssystemet, allihop.

Jag tror att du tog upp en viktig praktisk aspekt. Många tänker att det verkar vara mycket arbete. Hur ser det egentligen ut att fortsätta använda RAID-loggen som en gemensam källa efter den första avstämningen?

Kim Essendrup: Projektledaren måste verkligen leva efter den. Det är mer uppföljning och mer hantering, så det är faktiskt mer arbete.

Man kan förstås välja att inte använda en RAID-logg och hoppas att det går bra, ungefär som att köra genom ett gult trafikljus med slutna ögon och hoppas att man inte krockar. Det kan fungera många gånger. Men i de projekt jag har behövt rädda har svaret alltid varit nej när jag frågat om de kan visa RAID-loggen.

När projekt börjar gå fel inser jag ibland att jag inte har hållit RAID-loggen uppdaterad eller att jag inte har skapat någon för projektet. Efter att ha upplevt det tillräckligt många gånger förstår man att man måste göra det.

Om man tar ett steg tillbaka finns det många analyser av projekts misslyckande och framgång. Statistiken varierar, men ofta ser man att ungefär 70–80 % av projekten inte når sina viktigaste mål och att omkring 19–20 % misslyckas helt.

Vi vet att problem uppstår och att kostnader eller tidsplaner förändras. Om sannolikheten är hög att ett problem kommer att uppstå, gör du då dig själv och projektet en otjänst genom att inte lägga lite tid på att förebygga det?

Det är vårt arbete. Vi är projektledare och hjältarna som får saker att hända. RAID-loggen är ett slags superhjälteverktyg som hjälper oss att hålla projekten på rätt spår.

Galen Low: Statistik kan vara rolig. När man hör att en av tre kommer att drabbas tänker man ofta att det inte gäller en själv. När det sedan händer tänker man att det var väntat. Statistiken ger oss ett utrymme att inte hantera problemet direkt och förebyggande.

Man kan förstås också bli helt paralyserad av den. Men som du beskrev det handlar det egentligen om att ta kontrollen. Du har en plan, ungefär som en karta med en linje på. Men ratten som styr projektet framåt och hindrar det från att köra ner i diket är sådant som en RAID-logg.

Jag gillar att allt är samlat och tydligt. Människor kan titta på loggen och samarbeta kring den. Men många vill inte ha ännu ett kalkylblad. Vilka verktyg finns för att hantera en RAID-logg utan att använda Excel eller Google Kalkylark?

Kim Essendrup: Det finns naturligtvis många projektledningsverktyg på marknaden. Kolme Group, där jag arbetade med PPM-konsulttjänster, har infört projektledningsverktyg hos över 650 organisationer.

Det intressanta är att verktygen där ute ofta inte hanterar RAID-loggar särskilt bra. Många gör ingenting alls som liknar en RAID-logg. De fokuserar på uppgiftshantering, företagsresursplanering, prognoser eller resurshantering. Det är värdefulla användningsområden, men verktygen lämnar ofta projektledaren utanför.

Vissa verktyg riktar sig mot ledningens perspektiv, portföljplanering och leveranser på företagsnivå. Andra är mycket förenklade och riktar sig mot teamet: uppgifter, Kanban-tavlor och uppföljning av hastighet.

Det skapade en lucka. Vissa verktyg kunde hantera risker eller problem, eller så kunde man bygga en egen Kanban-tavla. Men då förlorade man mycket av enkelheten och värdet i en grundläggande RAID-logg.

Till slut bestämde vi oss för att skapa en egen lösning eftersom vi var trötta på kalkylblad. Kalkylblad fungerar, men de har begränsningar. Det kan vara svårt att dela dem, hålla reda på versioner och samarbeta. Om du vill följa alla händelser kopplade till en viss risk blir det dessutom snabbt svårt att hantera.

Därför skapade vi en molnbaserad RAID-logg, raidlog.com. Vi är fortfarande i ett tidigt skede, men vår ambition är att skapa det ultimata verktyget som hjälper projektledare att lyckas.

Galen Low: Det är fascinerande att programvaran går i två riktningar: företagsnivån och teamet som bara vill få saker gjorda. Projektledaren hamnar ofta utanför. Jag har aldrig hittat en riktig RAID-funktion i de projektverktyg jag använt.

Hur fungerar er lösning? Integreras den med annan programvara eller är den fristående?

Kim Essendrup: Den är fristående. Den har ett användargränssnitt som liknar ett kalkylblad, så om du är van vid RAID-loggar kommer den inte att sakta ner dig.

Vi har också ett mer visuellt gränssnitt som är intuitivt för den som är ny på RAID-loggar eller vill presentera ett kritiskt problem för en chef. Du kan öppna en detaljerad vy av ett problem eller beslut och visa det på ett sätt som gör ett affärssamtal möjligt.

Vi bygger in funktioner som hjälper användaren genom olika processer. Om du känner till en T-tabell kan du till exempel jämföra fördelar och nackdelar när du fattar ett beslut. Det har vi byggt in i beslutsmodulen.

Vi kommer också att lägga till värmekartor och avancerad analys, exempelvis Monte Carlo-analyser. Senare kommer vi även att ha AI-drivna funktioner.

RAID-loggen är inte det enda verktyget för projektledning, så vi bygger integrationer. Vi har redan en integration med Planview AdaptiveWork och kommer att integrera med Jira och så många andra verktyg som möjligt. Vi är också anslutna till Zapier.

Vår vision är att göra kalkylbladsbaserade RAID-loggar överflödiga. Vi kommer att ha en kraftfull kostnadsfri version för den som bara vill ha en enkel RAID-logg, samt avancerade funktioner för vana användare.

Galen Low: Jag gillar att det går längre än en logg. En logg fångar något som har hänt eller kanske kommer att hända. Men här finns analys och T-tabeller. Det är mer RAID-hantering än bara en RAID-logg.

Kim Essendrup: Det är ännu mer än så. RAID-loggar har inte utvecklats särskilt mycket under de senaste decennierna eftersom vi varit begränsade av verktygen.

Vi vill ge projektledare de verktyg de behöver för att driva projekt. Vi kommer att lägga till lärdomar och mötesanteckningar, så att du kan uppdatera RAID-loggen samtidigt som du skriver mötesanteckningarna och spara många timmar varje vecka.

Målet är att bli det självklara verktyget. Oavsett vilket planerings-, tidsplanerings- eller backloggverktyg du använder ska vi kunna fungera som ett tillägg. Vi vill ta bort en del av smärtan i projektledning.

Galen Low: Jag gillar att lösningen integreras med andra system och är öppen. Det blir som ett lager för riskanalys, beslutshantering och samarbete.

Kim Essendrup: Vi vill också bygga in kunskap, utbildning och coachning. Om du är ny inom riskhantering ska du kunna förstå vad du ska göra och vad sannolikhet och konsekvens betyder.

Vi vill ha hjälp direkt i sammanhanget och även mer avancerade funktioner som förväntat monetärt värde och Monte Carlo-analys. I stället för att själv bygga komplicerade kalkylblad gör systemet arbetet åt dig.

Galen Low: Jag älskar det. Jag har byggt flera riskregister från grunden och det kräver många formler. Jag önskar att jag slapp.

Kim Essendrup: Till slut tänker man att det får vara tillräckligt bra och att man måste komma vidare med projektet.

Galen Low: Sätt bara 15 % reserv och kör.

Min sista fråga: RAID verkar ibland saknas i verktyg som är till för projektledare. Men är RAID bara till för projektledare? Om inte, hur kan man använda det för att bygga en teamkultur med ansvar för risker, åtgärder, problem och beroenden?

Kim Essendrup: RAID kommer ursprungligen från ett ganska specialiserat projektledningsverktyg. Men egentligen handlar det om hur man genomför sin plan. Planen behöver inte vara ett traditionellt vattenfallsprojekt.

Det kan handla om agilt arbete och produktägarskap. Hur hanterar jag riskerna för produkten? Vilka beslut måste fattas? När ett beslut har fattats måste det dokumenteras och följas upp.

Om jag är scrum master och leder ett agilt team handlar RAID-loggen om teamet. Hur hjälper jag dem att lyckas och bli effektiva?

Om jag är PMO-chef och vill handleda projektledare kan jag be dem visa RAID-loggen. Då ser jag hur de hanterar sina projekt och kan ge förslag.

Ur projektledarens perspektiv kan man också använda loggen för att hantera arbetet uppåt i organisationen. Om du behöver tid med en PMO-chef, sponsor eller intressent kan du filtrera loggen och visa de tre eller fyra viktigaste punkterna. Då blir det lättare att starta ett relevant samtal.

RAID är alltså mycket mer än ett operativt projektverktyg. Det är ett arbetssätt och ett sätt att samarbeta – inte bara ett sätt att hålla ordning på sig själv, utan också på teamet, motivationen och kommunikationen.

Galen Low: Jag gillar alla de perspektiven. Nästan alla hanterar risker, åtgärder, problem eller beslut i någon form.

Det kan vara vilket samarbetsverktyg som helst. Och filtreringen är viktig. Projektledare bygger ofta upp en hög tolerans för stora mängder information och visar sedan alla sina Gantt-scheman för andra, som bara vill fly.

Man måste komprimera informationen. RAID-loggen måste kunna presenteras och diskuteras med en affärsintressent, inte bara med en annan projektledare. Den kan användas för att leda ett projektledarteam eller hantera förväntningar hos ledningen. Den blir en gemensam källa till sanning.

Kim Essendrup: Precis. RAID är bara början. Ofta utvidgar man det med lärdomar. Det är illa nog att ha problem, men ännu värre att ha samma problem om och om igen. Genom att lägga till lärdomar kan du hantera dem och göra nästa projekt bättre.

Galen Low: Jag gillar det och ser fram emot AI-funktionerna också. Var kan människor läsa mer om RAID-loggar?

Kim Essendrup: På raidlog.com. Det är lätt att komma ihåg. Jag vill gärna att människor provar produkten och ger feedback, eftersom vi vill skapa ett bra verktyg för projektledare. Du kan kontakta mig på LinkedIn.

Om du är helt ny på RAID-loggar skrev jag faktiskt en bok eftersom det märkligt nog inte fanns någon bok om RAID-loggar. Sök på Amazon efter "Ultimate Guide to RAID Log" så hittar du den.

Galen Low: Det är otroligt. Jag hade ingen aning. Jag lägger till alla länkar i programanteckningarna och ska själv undersöka det. Jag har alltid tänkt att RAID bara var ett kalkylblad, så det här ska bli intressant.

Kim Essendrup: Fantastiskt.

Galen Low: Kim, tack så mycket för att du var med idag. Jag uppskattar verkligen dina insikter. Jag älskar att nörda ner mig i projektledning, särskilt sådant som RAID-loggar och riskregister – saker som kan verka svåra men som egentligen är enkla och praktiska.

Kim Essendrup: Tack så mycket för att jag fick vara med, Galen.

Galen Low: Då har ni hört det. Om du vill delta i samtalet med över tusen likasinnade projektledningsentusiaster kan du gå med i vår gemenskap. Besök thedigitalprojectmanager.com/membership för mer information.

Om du gillade dagens avsnitt kan du prenumerera och hålla kontakten på thedigitalprojectmanager.com. Tack för att du lyssnade.