Vad är en RAID-logg (och hur integrerar du en i ditt projektarbetsflöde)?

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.

Galen Low: Du söker febrilt igenom inkorgen ännu en gång. Den här gången letar du efter mejlet från chefen som bekräftar ett beslut om ditt projekt. 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 kring RAID-loggar och hur man integrerar dem i projektarbetsflödet, så att du kan driva samtal med dina intressenter, enkelt kommunicera projektets status och aldrig mer behöva lägga timmar på att leta efter det där mejlet från chefen.

Hej allihop och tack för att ni lyssnar. Jag heter Galen Low och arbetar med The Digital Project Manager. Vi är en community för digitala yrkesverksamma med uppdraget att hjälpa varandra att utveckla kompetens, bygga självförtroende och skapa kontakter, 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, i dag pratar vi om RAID-loggar och den finstämda konsten att följa upp projektrisker, åtgärder, problem och beslut för att styra projekt mot framgång.

Med mig i dag har jag Kim Essendrup, tidigare från Kolme Group – en organisation som är helt inriktad på att hjälpa företag att bygga in datadrivet beslutsfattande i sina processer. Många av er känner honom förmodligen som en av de två grundande programledarna för den mycket, 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å roligt. Varje avsnitt jag har lyssnat på har varit hysteriskt kul.

Jag är faktiskt avundsjuk på din podd. Jag tycker att den är fantastisk. För de av våra lyssnare som inte känner till den: gå gärna och lyssna. Den har en väldigt bra dynamik. Jag undrade faktiskt om jag kunde börja med en riktig fanboy-frå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å vi är ömsesidiga fans. Jag coachade många projektledare och upptäckte att jag upprepade samma råd om och om igen. Jag tänkte: vet du vad, jag lägger det här på bloggen så kan folk läsa bloggen och allt blir bra. Sedan upptäckte jag att människor verkligen inte tycker om att läsa blogginlägg på 10 000 ord om projektledning.

Det är faktiskt inte särskilt roligt. Jag hade också ett mindre nystartat företag som jag arbetade med, inom ett annat område, och konsulten sa till mig: vet du vad, du borde starta en podd. Så jag tog mig igenom hela processen – lärde mig hur man gör, skaffade en mikrofon – och gjorde det för det andra nystartade företaget, som inte riktigt ledde någonstans, förutom att det fick in mig i poddvärlden.

Jag kom in i det och lyckades förstå hur det fungerade. Då tänkte jag att jag kanske kunde ta några av blogginläggen och göra dem faktiskt intressanta. Och jag funderade på vem den enda personen var som jag kunde få med i en podd och som till och med kunde göra projektledning intressant.

Och det var självklart Kate. Så jag kontaktade Kate och sa: Hej, vill du göra den här galna grejen? Kate var helt med på det. 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 hysteriskt roligt småprat, men samtidigt handlar det om projekt.

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

Kim Essendrup: Alla vi kunde hitta.

Galen Low: Där har ni det. Fantastiskt. Okej, låt oss börja.

I dag ska vi nörda ner oss i RAID-loggar. Jag tänkte att vi kanske kunde börja med en gemensam grund för våra lyssnare: kan du 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-loggen en logg där RAID är en akronym för Risker, Åtgärder, Problem och Beslut. Vissa organisationer föredrar antaganden och beroenden framför åtgärder och beslut, men det kan vi prata om lite senare.

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

Så den har funnits för evigt och är verkligen ett oumbärligt operativt verktyg som hjälper projektledare att driva sina projekt. I våra undersökningar är det ungefär hälften till två tredjedelar av projektledarna som har använt eller känner till den, och det är ett mycket viktigt verktyg. Därför försöker vi sprida kunskap om den just nu.

Galen Low: Väldigt intressant. Jag var en av dem som inte faktiskt hade insett det, men jag deltog i ett möte där vi pratade med människor om vår RAID-logg. Jag hade fått lära mig modellen med risker, antaganden, problem och beroenden. Sedan räckte någon upp handen och sa: är du säker på att det inte är den här modellen? Då frågade vi: vilken föredrar du och varför?

Kim Essendrup: Jag föredrar åtgärder och beslut eftersom ett antagande är ett planeringsantagande. Jag ska genomföra det här projektet – vilka antaganden har vi kring omfattningen eller när vi utvecklar planen? Ett antagande är alltså något som främst fungerar som en ingång 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 projektschemat, eftersom det är kopplat till tidpunkter, föregångare och efterföljare.

Det hamnar vanligtvis på någon av de två 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ärdspunkterna och besluten är det mer operativa saker – sådant du behöver hålla koll på under projektets genomförande. Då blir din RAID-logg ett operativt verktyg som du använder dagligen för att hantera dig själv och hålla ordning.

Galen Low: Nej, jag gillar det. Jag gillar den här framåtdrivande aspekten och håller helt med dig. Jag fastnade hela tiden i tanken att alla mina antaganden och beroenden faktiskt var risker. Alla var formulerade som risker i mina projekt och jag tänkte: jag vet inte om jag gör rätt.

Kim Essendrup: Ja. Det kanske bästa sättet att börja med sin risklogg är att börja med alla antaganden och beroenden som hela planen bygger på.

Galen Low: Och när du motbevisar eller bekräftar vissa av antagandena kan de tas bort. Det gillar jag. Vi pratade om hur viktig en RAID-logg är, och jag uppskattar särskilt beslutssidan.

Att ha allt samlat, särskilt i en logg, i stället för å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: Alternativet är att söka igenom Outlook och tänka: herregud, var är det där mejlet? Jag vet att det finns någonstans.

Galen Low: Jag är kungen av Outlook-sökningar, eftersom jag är kungen av att inte organisera min inkorg över huvud taget. Men ja, det är helt logiskt. En sak vi pratade om tidigare är att det uppenbarligen handlar om risk, men också om något som kan hindra projektet från att hamna i katastrofala situationer. Inte för att låta överdrivet skrämmande, men det hjälper verkligen till att hålla saker på rätt spår. Kan du berätta hur man praktiskt använder en RAID-logg för det?

Kim Essendrup: Jag brukar tänka på den som något man använder för att driva eller rädda vilket projekt som helst. Driv-delen är viktig, för om du inte gör det kommer du förmodligen att behöva rädda ditt eget projekt senare.

Om du tänker på verktygen du använder för att hantera dina projekt har du planen eller backloggen – allt du gör och alla punkter som direkt bidrar till eller skapar dina leveranser. Det är bra och det är det vi gör. Men RAID-loggen handlar om hur du ser till att sakerna faktiskt blir rätt utförda.

RAID-loggen är alltså inte planen, utan sättet du säkerställer att planen genomförs. Och vilket projekt går egentligen helt perfekt? Om ditt gör det är du en väldigt lyckligt lottad person. Du kommer att få problem och utmaningar. Saker kan gå fel och saker går fel.

Vad använder du för att hantera det? Du använder inte schemat, utan RAID-loggen för att identifiera vad som kan gå fel och vilka små åtgärdspunkter du måste hålla koll på för att se till att du och teamet inte hamnar efter. Du följer också upp vilka problem som har uppstått och hur du löser dem så snabbt som möjligt för att hålla projektet på rätt spår.

Vilka beslut behöver du förvänta dig och planera för, genomföra och reagera på – eller få fattade – som du inte tänkte på i början av projektet? Det är sådant vi behöver göra för att hålla projektplanerna på rätt spår och leverera dem 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 när man inte tar hand om grunderna och håller sig uppdaterad som projekt går fel. För mig är det magiska med en RAID-logg att den är så otroligt enkel, men samtidigt så viktig för att hjälpa oss att hålla koll på grunderna.

Galen Low: Du nämnde att du har coachat människor. Har du några berättelser om situationer där saker verkligen höll på att spåra ur och du tänkte: det här kan faktiskt lösas med något så grundläggande som en RAID-logg?

Kim Essendrup: Ja. För några år sedan tog jag över en PMO som var baserad i Europa, vilket var väldigt trevligt eftersom jag fick företagsfinansierade resor dit. Jag bodde fortfarande i Phoenix-området, så jag åkte dit ungefär en gång i månaden, och det var en fantastisk organisation.

Men när man tar över rollen som PMO-chef blir man också ansvarig 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 ett bra samtal. Det var mitt på dagen för mig och sen eftermiddag eller kväll i Storbritannien.

De sa att projektet gick så dåligt att kunden hotade att debitera oss för problemen och sedan 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 och kunden gick igenom alla problem de hade. Allt de sa lät legitimt. Jag tänkte att jag också skulle vara upprörd. Sedan tittade jag på min sida av bordet och frågade: har ni några problem?

De vaknade till liv. Kunden gav oss inte det här. Ni gav oss inte det där. Vi kunde inte lyckas eftersom ni inte gav oss allt vi behövde. Kunden svarade: det berättade ni aldrig för mig. Jag visste inte det. Jag tittade på alla och väntade tills det blev tyst.

Sedan frågade jag: kan ni visa mig er RAID-logg? Det blev helt tyst. Jag visste inte om de inte visste vad en RAID-logg var och var för generade för att fråga, eller om de insåg att de inte hade någon RAID-logg och därför var för generade för att säga något. Jag öppnade min bärbara dator och hade en RAID-logg klar.

Jag började gå igenom den: låt oss dokumentera alla problem. Berätta era problem. Vi fick ur oss allt och lät alla på kundsidan ventilera. Jag hade loggen uppe på projektorn och skrev ner allt. Då kunde jag bekräfta varenda oro och vartenda problem. De kände att de äntligen blev hörda eftersom de kunde se att jag skrev ner det.

Sedan tittade jag på min sida av bordet och frågade teamet: hur är det med er? Vad är ert problem? Det var samma sak. Jag dokumenterade allt. Sedan började vi titta på punkterna och insåg att många verkade vara beroenden: ni förväntade er det här, medan vi inte visste att vi behövde göra det.

Där kan beroenden ibland ha en plats i RAID-loggen, så jag bryter min egen regel. Vi dokumenterar alla dessa beroenden – vad vi är beroende av hos er och vad ni är beroende av hos oss. Det fina var att vi under eftermiddagens gång gradvis vände våra stolar mot projektorn.

Vi bråkade inte längre med varandra, utan med problemen. Det visar verkligen hur en RAID-logg kan användas för att lösa ett problem. När man sätter sig ner och använder ett enkelt verktyg som en RAID-logg får man en bra plattform för att skapa samsyn, se till att alla förstår varandra och skapa en gemensam lista över problem som teamet kan lösa tillsammans. Det 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 jag älskar också kroppsspråket. I stället för att vara konfrontativa ansikte mot ansikte börjar alla luta sig mot samarbete.

Jag tror att vi ofta underskattar att alla projektledningsmetoder, taktiker och processer finns till för att underlätta kommunikation och samarbete. Jag gillar det du sa om beroenden. Det kan gå åt båda hållen.

Om du inte gör det här kan vi inte göra det där. Men på många sätt handlar det om att du gör det här så att vi kan göra det där. Om människor inte ser det är det svårt för dem att förstå varför de behöver göra något. Då kanske de skjuter upp det, ingen säger något och plötsligt är projektet långt från där det behöver vara.

Ibland handlar det bara om att ha någon form av spårbarhet för sådant vi måste följa upp. Det kan kännas som omfattande dokumentation, men i slutändan tycker jag inte att det finns någon skam i att inte kunna hålla koll på de hundratals saker som du måste bevaka under projektets gång.

Kim Essendrup: Nej, verkligen inte. Det är en sak att sitta i ett möte och prata om ett beslut, ett beroende eller en risk, men när du skriver ner det i ett dokument – särskilt ett delat dokument på Zoom eller en projektor – och alla kan se det, blir det plötsligt konkret.

Om mitt namn står bredvid punkten börjar jag automatiskt att uppmärksamma den. Därför är RAID-loggen också ett utmärkt kommunikations- och ansvarsverktyg. När jag coachar och mentorerar projektledare brukar jag säga att om du kommer in i 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 du ska behandla RAID-loggen som om den kan bli föremål för ett domstolsföreläggande – särskilt om du arbetar med ett myndighetsrelaterat projekt. En dag kan den faktiskt bli det, och då kommer du att önska att den var uppdaterad.

Galen Low: Hundra procent. Jag har arbetat med ett par projekt som granskades av olika skäl. Att inte ha rätt dokumentation lättillgänglig, även om informationen finns någonstans, innebär att man måste leta fram allt. Det blir ett helt projekt i sig. Men en tydlig dokumentation av vad som hände, var riskerna fanns och hur vi pratade om dem kan vara enormt användbar.

Kim Essendrup: Jag kan tänka mig att det fick dig att vakna snabbt på morgonen när du upptäckte att du skulle granskas samma dag.

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

Jag tycker att du tog upp en viktig praktisk aspekt av att använda en RAID-logg. Många tänker att det verkar vara mycket arbete. Jag förstår att du satte upp den på projektorn och fick två team att prata med varandra, men hur ser det ut att faktiskt behålla den som en gemensam källa till sanning efter den stunden av samsyn?

Kim Essendrup: Projektledaren måste verkligen leva efter den. Du kan titta på den och tänka att det är mycket mer uppföljning och hantering som måste göras.

Och det är det. Du kan välja att inte använda en RAID-logg och hoppas att det går bra, ungefär som när du kör mot gult ljus. Du kan blunda, trycka på gasen och hoppas att du inte krockar. Det kan fungera många gånger. Men av de misslyckade projekt jag har behövt gå in och rädda är svaret alltid nej när jag frågar om de kan visa sin RAID-logg.

När projekt börjar spåra ur brukar jag inse att jag själv inte har hållit RAID-loggen uppdaterad, eller att jag inte har skapat någon RAID-logg alls. Efter att ha gått igenom den smärtan tillräckligt många gånger inser man att man måste göra det.

Om man tar ett steg tillbaka och ser på helheten finns det många analyser av projektens misslyckande- och framgångsfrekvens. Siffrorna varierar mellan år och studier, men ofta ser man att ungefär 70–80 procent av projekten inte når sina viktigaste mål. Omkring 19–20 procent misslyckas helt.

Vi vet det här eftersom vi är projektledare. Problem uppstår, saker skjuts fram och kostnaderna blir högre än väntat. Om du vet att det sannolikt kommer att uppstå ett problem i projektet, gör du då dig själv och projektet en otjänst genom att inte lägga lite tid på att försöka undvika det?

Det är vårt jobb. 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: Jag tycker också att statistiken är intressant. Den kan fungera åt båda hållen. Man hör att en av tre personer kommer att drabbas av något och tänker: inte jag. När det sedan händer tänker man att det var väntat eftersom en av tre drabbas. Vi använder det som en ursäkt för att inte ta itu med saker proaktivt.

Vi kan blunda och köra genom ett gult ljus. Å andra sidan kan man bli helt paralyserad och tänka att projektet förmodligen kommer att misslyckas. Men det du beskrev tidigare liknar att ta tyglarna. Du har en plan, som en karta med en linje på. Men ratten som faktiskt styr projektet framåt och ser till att det inte kör ner i diket är sådant som en RAID-logg.

Jag gillar att den är samlad och tydlig. Människor kan titta på den och samarbeta kring den i ett mötesrum. Det får mig också att tänka på något du sa tidigare: för både dig och mig har RAID-loggen alltid varit ett kalkylblad. Många tänker att de inte behöver ännu ett kalkylblad.

Vilka verktyg finns för att hantera en RAID-logg i ett projekt om man inte vill använda Excel eller Google Sheets?

Kim Essendrup: Det är roligt. Det finns förstås många projektledningsverktyg på marknaden. När jag arbetade med min PPM-konsultverksamhet på Kolme Group implementerade vårt team projektledningsverktyg i över 650 organisationer.

Det är fantastiskt att ha startat en konsultverksamhet som har kunnat göra sådant arbete inom företag av olika storlek och i olika branscher. Men det intressanta är att de verktyg vi har implementerat ofta inte hanterar RAID-loggar särskilt bra.

Många gör inte ens något i närheten av det. De fokuserar på exempelvis att vara den bästa programvaran för uppgiftshantering, eller på resursplanering och prognoser samt resurshantering. Det är värdefulla användningsområden som organisationer behöver.

Men verktygen är antingen utformade för företagsledningen och portföljplanering, eller förenklade för teamet – med få administrativa funktioner och enkel uppsättning. Problemet är att projektledaren hamnar utanför.

Vi upptäckte ett tomrum. Vissa verktyg kunde hantera en del av RAID-arbetet, kanske risker eller problem, eller så kunde man bygga en egen Kanban-tavla. Men då förlorade man enkelheten och mycket av värdet i en vanlig RAID-logg.

Vi tröttnade på kalkylblad. De fungerar, men de har begränsningar. Det kan vara svårt att dela dem, följa versioner och samarbeta. Om du vill följa alla händelser kring en viss risk blir informationen snabbt svår att hantera.

Därför skapade vi en SaaS-baserad RAID-logg på raidlog.com. Vi är fortfarande i ett tidigt skede, men vår ambition är att skapa det ultimata verktyget för projektledare.

Galen Low: Jag gillar det. Programvaran verkar gå i två riktningar: en företagsvy och en enkel teamvy. Projektledaren lämnas ofta utanför. Jag har använt verktyg där jag tänkt att de är byggda på samma sätt som min hjärna fungerar, med statusuppdateringar, påminnelser och uppföljning. Men jag har aldrig hittat en riktig RAID-funktion.

Kan du berätta hur det fungerar? Integreras det med annan programvara eller fungerar det fristående?

Kim Essendrup: Det är en fristående programvara. Den har en RAID-logg med ett användargränssnitt som liknar ett kalkylblad, så den är snabb och effektiv. Om du är van vid RAID-loggar saktar den inte ner dig.

Vi har också ett mer visuellt gränssnitt som är intuitivt för nya användare eller när du behöver visa en kritisk fråga för en chef. I stället för att markera en enda rad kan du öppna en detaljerad vy av ett problem eller ett beslut och presentera det på ett sätt som möjliggör ett affärssamtal med intressenter och sponsorer.

Vi lägger till användarvänliga funktioner som vägleder dig genom olika processer. Om du känner till en T-tabell kan du använda den för att väga fördelar, nackdelar och alternativ när du fattar ett beslut. Vi har byggt in det i beslutsmodulen. Vi kommer också att lägga till värmekartor och avancerad analys, som Monte Carlo-analys, sådant som är svårt att göra effektivt på egen hand.

Senare kommer vi även att ha AI-drivna funktioner. RAID-loggen är fristående, men den är inte det enda verktyget i projektledning. Därför bygger vi integrationer. Vi har redan en med Planview AdaptiveWork, ska integrera med Jira och kommer att ansluta till så många verktyg som möjligt.

Vi är också anslutna till Zapier, som i sin tur kan ansluta till nästan allt. Vår vision är att göra kalkylbladsbaserade RAID-loggar överflödiga genom att erbjuda en bättre lösning. Vi kommer att ha en kraftfull gratisversion och avancerade funktioner för vana användare.

Galen Low: Det jag gillar mest är att det går långt bortom en logg. En logg fångar något som hänt eller kanske kommer att hända, ungefär som en anteckning. Men här finns djupet: analys, T-tabeller och verklig RAID-hantering.

Kim Essendrup: Det är ännu mer än så. Vi kallar det raidlog.com eftersom RAID-loggen är ett viktigt operativt verktyg, men RAID-loggar har inte utvecklats särskilt mycket under de senaste decennierna eftersom vi varit begränsade av verktygen.

Vår vision är att ge projektledare de verktyg de behöver för att driva projekt. Vi kommer inte att stanna vid RAID-punkter. Vi ska även integrera 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 vara det självklara verktyget som kan fungera som ett tillägg till det schemaläggnings-, planerings- eller backloggverktyg du använder. Vi vill ta bort smärtan ur projektledning.

Galen Low: Jag gillar att det integreras med andra öppna lösningar och att ni har Zapier-integrationer. Det blir nästan ett lager för riskanalys, beslutshantering och samarbete – något som ibland saknas på företagsnivå eller i det dagliga teamarbetet.

Kim Essendrup: På grund av all utbildning och coachning vill vi vara mer än ett verktyg. Vi vill bygga in kunskap och utbildning. Om du är ny inom riskhantering ska det vara tillräckligt intuitivt för att du ska förstå vad du ska göra, vad sannolikhet och påverkan betyder och hur funktionerna används.

Vi vill också erbjuda mer avancerade funktioner som Monte Carlo-analys och förväntat monetärt värde. Du kanske har hört talas om dem men aldrig använt dem eftersom det är svårt att bygga in dem i ett kalkylblad. Vi gör arbetet åt dig, så att du kan beräkna vilken reserv du egentligen bör planera för.

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

Kim Essendrup: Precis. Till slut tänker man att det här får duga och att man måste komma igång med projektet. Man kan inte fortsätta leka med verktyget.

Galen Low: Säg bara 15 procent reserv och kör.

Min sista fråga handlar om projektledarens roll. Är RAID bara till för projektledare? Om inte, hur kan vem som helst använda det för att bygga en teamkultur med ansvar för risker, åtgärder, problem och beroenden – och göra det till ett lagarbete?

Kim Essendrup: RAID har förstås sitt ursprung som ett specialiserat projektledningsverktyg, men i grunden handlar det om hur man får planen genomförd. Planen behöver inte vara ett traditionellt vattenfallsprojekt. Den kan handla om en produkt, en produktägare eller ett agilt team.

Som produktägare behöver du hantera riskerna för produkten och se till att beslut fattas och dokumenteras. Som scrum master behöver du ta hand om teamet och se till att det kan arbeta effektivt.

RAID-loggen handlar därför inte bara om produkten, utan om teamet: hur får jag teamet att lyckas och hur stöder jag det? Om jag är PMO-chef och vill coacha projektledare är det ett utmärkt sätt att be dem visa sin RAID-logg. Då kan jag se hur de hanterar projekten och ge förslag.

Ur projektledarens perspektiv är loggen också användbar när man hanterar organisationen uppåt. Om jag behöver tid med PMO-chefen, sponsorer eller intressenter tar jag RAID-loggen och filtrerar den. Jag visar inte hela listan, utan de tre eller fyra viktigaste punkterna som jag behöver deras hjälp med.

Därför är RAID 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å att hålla teamet organiserat, motiverat och informerat.

Galen Low: Jag gillar alla de punkterna. Nästan alla hanterar risker, åtgärder, problem eller beslut i någon form. Det kan vara vilket samarbetsverktyg som helst.

Jag är glad att du nämnde filtreringen. Som projektledare bygger vi upp en hög kapacitet för att hantera enorma mängder information och visar sedan våra Gantt-scheman för andra, som bara vill komma undan. Vi måste begränsa informationen.

Det är avgörande för RAID-loggar. Man måste få informationen i ett format som går att presentera och diskutera med en affärsintressent, inte bara med en annan projektledare. Du kan använda den för att leda ett team av projektledare eller hantera förväntningar hos ledningen. Den blir en tillförlitlig källa till sanning.

Kim Essendrup: Precis. RAID är bara början. Det kan utökas med lärdomar. Problem är jobbiga, men det är ännu värre att ha samma problem om och om igen. Genom att lägga till lärdomar i RAID-loggen kan du hantera problemen och göra livet enklare nästa gång.

Galen Low: Jag gillar det och ser fram emot AI-funktionerna. Det här är verkligen fascinerande. Var kan människor läsa mer om RAID-loggen?

Kim Essendrup: På raidlog.com. Det är enkelt att komma ihåg. Jag vill gärna att människor testar 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 inom RAID-loggar och undrar vad det handlar om har jag faktiskt skrivit en bok. Märkligt nog fanns det ingen bok om RAID-loggar, så jag tänkte att det måste jag åtgärda. Sök på Amazon efter "Ultimate Guide to RAID Log" så hittar du min bok. Jag tror att det är den enda boken om RAID-loggar.

Galen Low: Det är otroligt. Jag hade ingen aning. Jag lägger med alla länkar i programanteckningarna för lyssnarna. Jag ska också kolla upp det, eftersom jag tycker att det är fascinerande. Det hade aldrig slagit mig att det kunde vara mer än ett kalkylblad.

Kim Essendrup: Fantastiskt.

Galen Low: Kim, stort tack för att du var med i dag. Jag uppskattar verkligen dina insikter. Jag älskar att nörda ner mig i projektledning, särskilt sådana här delar av projektledningens historia – RAID-loggar, riskregister och annat som kan verka ogenomträngligt men som egentligen är väldigt enkelt och vettigt att ha.

Tack för ditt perspektiv. Det var fantastiskt.

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

Galen Low: Då har ni hört det. Som alltid är ni välkomna att delta i samtalet med över tusen likasinnade projektledningsentusiaster genom att gå med i vår community. Besök thedigitalprojectmanager.com/membership för att läsa mer.

Om du gillade det du hörde i dag får du gärna prenumerera och hålla kontakten på thedigitalprojectmanager.com. Tills nästa gång – tack för att du lyssnade.