En RAID-logg är ett projekthanteringsverktyg som används för att dokumentera eventuella problem som uppstår under ett pågående projekt. Det är ett verktyg som hjälper teamet att hålla sig organiserat samtidigt som eventuella problem dokumenteras under projektets gång. Ta reda på varför RAID-loggar är bra verktyg att använda för projekt och hur de kan hjälpa ditt team genom projektets livscykel.
Projekthantering är enkelt när allt går smidigt. Men så är det inte alltid. När det blir tufft är det viktigt att dokumentera de förändringar som sker i projektet. Det kan hjälpa teamet att spåra ändringar, lära sig av utmaningarna och tillämpa informationen i nästa projekt.
I den här artikeln förklarar vi vad en RAID-logg är och varför dessa loggar är värdefulla verktyg för projekthantering.
En RAID-logg är ett projekthanteringsverktyg som används för att dokumentera eventuella problem som uppstår under ett pågående projekt. Det här verktyget skapas under projektplaneringsfasen och används konsekvent under hela projektet för att dokumentera risker, åtgärder, antaganden, problem, beslut och beroenden när projektet fortskrider. Förutom att spåra ändringar och öka synligheten kan du använda den här loggen under ett utvärderingsmöte för att ta reda på hur du kan förhindra liknande problem och utmaningar i framtida projekt.
Skapa en mall för en RAID-loggRAID-akronymen står för:
Risker är alla potentiella problem som kan ha en negativ inverkan på projektet. Det är viktigt att proaktivt identifiera projektets risker innan ett projekt inleds. På så sätt kan du identifiera lösningar på dessa risker innan de inträffar och ge teamet de verktyg de behöver för att förstå vad de ska göra om de stöter på risker under projektets gång. Att proaktivt implementera projektriskhantering kan förhindra att större problem utvecklas senare i projektet.
Det här avsnittet i en RAID-logg liknar ett riskregister, som syftar till att identifiera, analysera och lösa risker i förväg. Om teamet använder ett riskregister kan du lägga till riskerna i avsnittet ”risker” i RAID-loggen. Förutom proaktiv riskhantering kan du också använda riskavsnittet i RAID-loggen för att dokumentera eventuella oväntade risker när de uppstår. När teamet identifierar en risk bör de utse en tydlig ägare som ska hantera problemet om det dyker upp senare i projektet.
Läs: Riskhanteringsprocessen för projekt i 6 stegBeroende på hur ditt team ställer in din RAID-logg kan A i RAID stå för antingen åtgärder (actions) eller antaganden (assumptions). Du kan använda båda dessa alternativ i din RAID-logg, eller så kan du välja ett av dem. Om du undrar vilken typ som fungerar bäst för ditt team kan du välja:
Åtgärder om projektet har många rörliga delar.
Antaganden om det är ett långsiktigt projekt som kräver mycket förutseende.
Åtgärder – eller saker att göra – är allt som behöver göras under projektets gång. Att göra-punkter bör alltid ha en tydlig ägare så att alla vet vem som är ansvarig för varje specifik punkt. Om det finns flera ägare av en punkt som ska göras ska du tydligt identifiera vem som är ansvarig för vilken leverans. Projektledare bör regelbundet kontrollera öppna projektuppgifter eller punkter att göra för att säkerställa att projektet fortsätter att utvecklas.
Antaganden är saker som teamet förväntar sig ska gå på ett visst sätt under planeringsprocessen. När det gäller projekthantering är antaganden faktorer som teamet redan är säkert på. Det kan bero på antingen erfarenhet eller expertis. Ett bra exempel på ett antagande inom projekthantering är att anta att en viktig del av en maskin kommer att levereras säkert och i tid.
Eftersom du inte kan planera för allt måste dina teammedlemmar göra antaganden längs vägen. Det är viktigt att dokumentera de antaganden du gör på en central plats. På så sätt kan du snabbt använda din lista över antaganden som referens om ett oväntat hinder eller en oväntad projektrisk uppstår. Om du gjorde ett antagande som ledde till risken eller hindret kan teamet snabbt identifiera grundorsaken till problemet genom att proaktivt ta reda på om antagandet är sant eller inte.
Problem är oväntade händelser som inträffar under projektets gång. Problem skiljer sig från risker eftersom du inte förväntar dig att de ska uppstå. Risker är potentiella problem som du förväntar dig, medan problem dyker upp oväntat. Det är viktigt att spåra problem när de uppstår så att teamet kan gå tillbaka till hur problemen löstes. Om framtida problem uppstår på grund av det här första problemet kan dokumentationen hjälpa teamet att identifiera grundorsaken.
Precis som ”A” i RAID kan ”D” stå för antingen beslut (decisions) eller beroenden (dependencies). Om ditt projekt är mer fritt kan ditt team vilja lyfta fram de beslut som fattats för att komma fram till lösningen. Om projektet har många komplicerade uppgifter som är beroende av varandra är beroenden ett mer relevant val.
Beslut är alla de konkreta val som görs längs vägen. Det är de sista tankarna och idéerna som driver ett projekt till fullbordande. Det är viktigt att dokumentera vilket beslut som fattades, vem som fattade det och varför det beslutet valdes. Om teamet använder en iterativ process såsom kaizen kan den här dokumentationen vara till hjälp för att göra förbättringar för framtida projekt.
Ett beroende inom projekthantering är en uppgift som är beroende av att en annan uppgift slutförs. Om det finns stora beroenden i ett projekt som kan hindra projektet från att gå vidare bör du dokumentera dem i RAID-diagrammet. Att visualisera beroenden kan hjälpa teammedlemmarna att förstå vilka uppgifter som behöver slutföras först, innan de går vidare till nästa steg. Du kan ofta hitta beroenden organiserade i ett Gantt-diagram.
RAID-loggar är bra verktyg att använda när du börjar planera ditt projekt. Det är också bäst att använda dem konsekvent under projektets gång, så att du kan dokumentera viktiga åtgärdspunkter som behöver kontrolleras, eventuella beslut som fattas eller stora problem som uppstår.
En RAID-logg är användbar för snabba punkter, men det här verktyget bör inte vara din enda form av projekthantering. Tänk på en RAID-logg som en incidentlogg för projekthantering – om det sker en större händelse i projektet kan du dokumentera den i RAID-loggen. Se till att du kombinerar en RAID-logg med ett mer robust projekthanteringssystem som håller allt ditt teams arbete, uppgifter och projekt i fas.
Skapa en mall för en RAID-loggEn RAID-logg är ett användbart verktyg att ha i din projekthanteringslåda. Här är några anledningar till varför.
En av de största fördelarna med att använda en RAID-logg är möjligheten att snabbt katalogisera viktig information på en central plats. Så snart ett problem uppstår eller ett beslut fattas kan en projektledare snabbt anteckna åtgärden i motsvarande avsnitt i RAID-loggen.
Teamet bör dokumentera processer och beslut som fattas under projektets gång. På så sätt kan de ändringar du gör under ditt nuvarande projekt hjälpa till att fatta beslut om framtida projekt. På så sätt kan RAID-loggar hjälpa dig att lära dig och använda din erfarenhet för framtida utmaningar.
Läs: Hur man drar lärdom av erfarenheterna inom projekthanteringDet är enkelt att skapa en RAID-loggmall som passar teamets behov. Om en ny projektledare kommer in i teamet eller om du lär upp någon i teamets viktiga processer är det enkelt att förklara det allmänna konceptet för en RAID-logg. RAID-loggar är utformade för att användas upprepade gånger. Det enklaste sättet att göra det på är att skapa en mall som bäst passar teamets behov och använda samma mall för varje projekt.
Read: Process documentation: The ultimate how-to with examplesRAID-loggar ger teamet en central plats där de kan hitta information om ett projekt. Om en teammedlem behöver diskutera ett problem med rätt intressenter kan RAID-loggen hjälpa till att hitta rätt person.
Den dokumenterar inte bara vem som äger vad, utan fungerar också som en översikt på hög nivå över projektets process. Teammedlemmar kan enkelt ta en titt på alla åtgärder som för närvarande pågår eller beslut som fattats nyligen. Eftersom varje avsnitt är tydligt märkt kan teammedlemmarna hitta den information som är mest relevant för dem.
Read: The role of an incident commander: Real-time crisis controlÄven om RAID-loggar är ett användbart verktyg finns det några nackdelar med att använda dem.
Din RAID-logg bör inte vara den enda sanningskällan när det gäller projekthantering. Det är ett användbart verktyg för att notera viktiga beslut, viktiga beroenden och eventuella problem som dyker upp längs vägen. Men om du letar efter mer detaljerad information om projektets specifika egenskaper kan det vara bättre att använda något såsom en projektplan.
Se till att teamet förutom en RAID-logg också har ett centraliserat verktyg där all arbetsinformation finns. På så sätt kan varje teammedlem – oavsett avdelning eller funktion – få tillgång till den projektinformation de behöver. Det bästa sättet att göra det är att använda ett arbetshanteringsverktyg.
En RAID-logg är bara uppdaterad när en projektledare uppdaterar den. Om en projektledare inte konsekvent lägger till ny information i realtid blir RAID-loggen föråldrad. Det kan vara utmanande om en projektledare inte kan uppdatera loggen regelbundet. Föråldrad information kan skapa förvirring för andra intressenter, så det är viktigt att ha konsekventa meddelanden i alla kommunikationsformulär.
Läs: Varför en tydlig kommunikationsplan är viktigare än man trorOm du dokumenterar varje beslut som fattas i en RAID-logg, ända ner till det minsta enskilda valet, kan loggen snabbt bli rörig och det kan bli svårt att hitta information. Att komma överens om detaljnivån är en viktig skillnad för ditt team för att upprätthålla sin RAID-logg. Innan du börjar skapa en RAID-logg bör du se till att teamet har en tydlig förståelse för vilka beslut och problem som ska eller inte ska inkluderas.
För att förhindra oreda bör teamet bestämma vilken information som är viktigast att dokumentera i en RAID-logg. På så sätt finns bara den viktigaste informationen i loggen, vilket gör det lättare för projektintressenter att hitta den information de behöver.
En RAID-logg kan vara så enkel som ett papper med fyra kvadranter för varje del av akronymen, men den är mest effektiv när alla i teamet kan komma åt informationen på ett och samma ställe.
Följ de här fyra stegen för att skapa en RAID-logg:
Identifiera det bästa sättet att presentera din RAID-logg. Som nämnts ovan kan en RAID-logg vara så enkel som ett papper indelat i fyra avsnitt. Det är dock kanske inte det mest effektiva sättet för ditt team att få tillgång till den här informationen. Bestäm tillsammans med teamet om ni vill skapa loggen i ett dokument, ett kalkylark eller en annan typ av programvara.
Diskutera initiala risker, antaganden och beroenden. Genom att vara proaktiv kan du se till att alla i teamet är medvetna om potentiella problem och hur man kan förebygga dem.
Uppdatera loggen regelbundet. RAID-loggen är bara korrekt när den uppdateras regelbundet. Använd loggen i takt med att projektet fortskrider och uppdatera motsvarande avsnitt på lämpligt sätt.
Reflektera när projektet är över. När ditt team har ett projektutvärderingsmöte kan du använda RAID-loggen för att hjälpa till i konversationen om hur ni kan förbättra er inför nästa projekt.
Att skapa en RAID-logg med en programvara för arbetshantering som Asana kan hjälpa dig att organisera alla dina loggpunkter på ett konsekvent sätt. Genom att tydligt definiera deadliner, intressenter och åtgärdspunkter kan teamet återgå till att göra det de gör bäst.
Skapa en mall för en RAID-logg