RAID-logger: Definisjon, mal, eksempler og veiledning
En RAID-logg er et dokument som brukes av prosjektledere, forretningsanalytikere, risikostyrere, teamledere og ledere for å hjelpe med risikostyring i prosjekter ved å oppsummere følgende nøkkelinformasjon:
- Risikoer
- Antakelser eller aktiviteter
- Iproblemer
- Dependenser eller beslutninger
Som prosjektleder kan du bruke en RAID-logg for å holde interessentene dine – og deg selv – oppdatert på de siste detaljene i prosjektet. Når loggen brukes på en god måte, kan den fungere som et viktig strategidokument for å oppsummere prosjektets status på ledernivå.
RAID-logger brukes ofte sammen med programvare for risikostyring.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Hva er en RAID-logg, og hva står «RAID» for?
RAID står for: risiko, antakelser (eller aktiviteter), problemer og avhengigheter (eller beslutninger).
| Definisjon av komponentene i RAID-loggen | Eksempler |
|---|---|
| Risikoer. Identifiser og kategoriser risikoer og muligheter, sannsynligheten for at de oppstår, hvilken innvirkning/alvorlighetsgrad de vil ha dersom de oppstår, samt planen og aktivitetene for å redusere risikoen | -Risiko: Dårlig vær forsinker tidsplanen for datainnsamling |
| Antakelser eller Aktiviteter. Dokumenter prosjektparametere for å forhindre omfangsutvidelse; oppretthold en «oppgaveliste» basert på pågående prosjektarbeid | -Antakelse: nødvendige ressurser er tilgjengelige for å utføre prosjektarbeidet -Aktivitet: ta kontakt med økonomiavdelingen for en kostnadsoversikt over eksisterende tredjepartsleverandører |
| Iproblemer. Dokumenter hendelser som har oppstått og som påvirker prosjektets fremdrift, og forklar veien til en løsning | -Problem: Et sikkerhetsbrudd svekker integriteten til kundedata |
| Dependenser eller Deslutninger. List opp aktiviteter som ikke kan startes eller fullføres uten at en annen aktivitet startes eller fullføres; dokumenter tidligere avtalte handlingsforløp og begrunnelsen for å følge eller ikke følge dem | -Avhengighet: gjennomfør en analyse av alternativer før anskaffelse av et nytt system for leverandørstyring -Beslutning: bygg et system for talentstyring internt for å opprettholde fokuset på en prestasjonsorientert kultur, selv om dette vil bli dyrere på kort sikt |
Du vil se at definisjonen av RAID inkluderer noen doble akronymer: antakelser eller aktiviteter, avhengigheter eller beslutninger. Her er mine tanker om hvordan du kan forholde deg til disse:
- Antakelser kontra aktiviteter. Jeg kan ikke fortelle deg hvor mange ganger det å ha en liste over antakelser har stoppet omfangsutvidelse før den fikk utvikle seg. Hvis du ønsker å holde loggen rettet mot et seniorpublikum, vil jeg anbefale å holde aktivitetspunktene i et separat dokument med fokus på taktisk gjennomføring.
- Beslutninger kontra avhengigheter. Etter min erfaring husker ingen noen gang hvorfor beslutninger ble tatt: spesielt ikke hvilke alternativer som ble vurdert, men forkastet, og hvorfor. For å unngå sirkulær tenkning gjennom et langvarig oppdrag vil jeg anbefale å dokumentere beslutninger i RAID-loggen i tillegg til avhengigheter.
Når bør du opprette en RAID-logg?
En RAID-logg bør opprettes i starten av et prosjekt under oppstarts- eller planleggingsfasen, når man vet nok om omfang, interessenter og mål til å identifisere innledende risikoer og antakelser. Deretter bør den gjennomgås på nytt ved viktige milepæler, når omfanget endres, eller når en betydelig risiko eller et problem oppstår. I smidige prosjekter er starten på hver sprint et naturlig tidspunkt for oppdatering.
RAID-logg kontra risikoregister
Selv om det er noe overlapp mellom disse to dokumentene, er forskjellen at en RAID-logg er mer omfattende enn et risikoregister. I tillegg til å dokumentere risikoer inkluderer en RAID-logg også antakelser eller tiltak, en problemlogg samt avhengigheter eller beslutninger.
Mal for RAID-logg
Jeg har inkludert en nedlasting av en RAID-logg mal i Microsoft Excel (du må være DPM-medlem for å få malen). Du kan bruke denne malen til å dokumentere risikoer, antakelser, problemer og avhengigheter. Kolonne M og N holder oversikt over beslutninger og datoen for beslutningen.
Eksempel på RAID-logg
I tillegg til malen for RAID-loggen har jeg også inkludert en eksempellogg i Excel, slik at du kan få et inntrykk av det ferdige produktet (du må også være medlem for å få tilgang til denne).
Her er et annet eksempel som viser hvordan RAID-logger kan brukes i et prosjekt der man planlegger en campingtur.
Slik oppretter du en RAID-logg
Nå som du har malen klar, hvordan går du egentlig frem for å fylle den ut? I løpet av prosjektplanleggingsfasen vil du kunne hente innhold til følgende komponenter i RAID-loggen:
- Risikoer
- Antakelser
- Avhengigheter
Tiltak, problemer og beslutninger blir først aktuelle etter at prosjektet har startet.
For hvert element du fører inn, bør du som minimum registrere disse feltene:
- Beskrivelse — en kort oppsummering av risikoen, antakelsen, problemet eller avhengigheten
- Ansvarlig — personen som er ansvarlig for å håndtere eller løse det
- Prioritet — høy, middels eller lav
- Status — åpen, pågår eller lukket
- Måldato — når det må være løst eller gjennomgått
- Tiltaksplan — trinnene som tas for å håndtere det
Ved å bruke konsekvente felter for hver oppføring blir loggen enklere for interessentene å skanne og lettere å vedlikeholde over tid.
Mulige kilder til innhold for en RAID-logg
Du kan hente innhold til loggen fra flere kanaler:
- Interessentintervjuer
- Gjeldende eller tidligere prosjektdokumentasjon
- Eksempler: mal for lærdommer, retrospektiver, etteranalyser, prosjektmandater, prosjektplaner, prosjektplaner
- Tidligere erfaring med å gjennomføre lignende prosjekter
- Åpent tilgjengelig kildemateriale på nettet
- Kritisk tenkning basert på informasjonen du har hentet fra kildene ovenfor (f.eks. at interessentene dine ikke sier direkte at noe er et problemområde, men at motviljen deres mot å ta opp temaet tyder på at dette området vil ha nytte av ytterligere kartlegging.)
Beste praksis
Når prosjektet har startet og du har RAID-loggen klar i utkast, bør du ha følgende beste praksis for bruk av loggen i mente mens du leder prosjektet:
- Tilpass detaljnivået til målgruppen. Interessenter er avhengige av RAID-loggen for å forstå konteksten for dette prosjektet og eventuelle risikoer eller problemer som kan true prosjektets suksess. Hold fokus på forretningsmessige konsekvenser, fremfor taktiske oppdateringer som kanskje ikke er meningsfulle for noen som ikke er involvert i det daglige arbeidet.
- Følg med på og oppdater loggen gjennom hele prosjektets livssyklus. Dette artefaktet er ubrukelig hvis du ikke oppdaterer det og fører informasjonen videre til annen dokumentasjon, for eksempel en beslutningslogg. Det er enda en grunn til å holde innholdet kortfattet, slik at dokumentet ikke blir tungvint å vedlikeholde. Mesteparten av tiden bør brukes på å fjerne hindringer, ikke på å dokumentere dem.
Fordeler
RAID-logger er nyttige for interessenter, prosjektteammedlemmer, virksomheten og deg som prosjektleder.
- Det er et samlet sted for relevant prosjektinformasjon som enkelt gir innsikt i prosjektets helsetilstand i sanntid
- Den gjør det mulig å følge opp risikoer før de blir til problemer, og deretter raskt prioritere og håndtere problemer hvis risikoene blir realisert
- Prosjektledere kan dokumentere antakelser og beslutninger for å redusere risikoen for å måtte gå tilbake til diskusjoner som kan forsinke prosjektet.
Hvordan brukes RAID-logger i smidige prosjekter?
Vanligvis har smidige prosjekter en tendens til å unngå dokumentasjon til fordel for å utvikle et fungerende produkt. Når det er sagt, vil jeg hevde at det er verdt den ekstra innsatsen å utvikle en RAID-logg.
Grunnen? Smidige prosjekter følger vanligvis en iterativ tilnærming til prosjektgjennomføring som legger til rette for mer eksperimentering. Denne tilnærmingen er god for å mislykkes raskt, slik at man kan trekke lærdom raskere.
Men når man gjør det mindre stigmatiserende å mislykkes, introduseres ytterligere risikoer som kan sette prosjektet på avveie. Og en organisasjon kan bare lære av feil hvis den dokumenterer antakelsene og beslutningsprosessen som lå til grunn for hvert eksperiment.
Hva skjer nå?
Hvis du trenger mer hjelp med risikostyring, kan du vurdere å ta vårt kurs i digital prosjektledelse. I tillegg til risikostyring lærer du også om å lede prosjekter gjennom hele prosjektets livssyklus, fra oppstart til prosjektavslutning.
