Hva er en RAID-logg (og hvordan integrerer du den i prosjektarbeidsflyten din)?

Les transkripsjonen:

Vi prøver ut et dataprogram for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Galen Low: Du leter febrilsk gjennom innboksen igjen. Denne gangen leter du etter e-posten fra sjefen som bekrefter en beslutning om prosjektet ditt. Hva het personen? Hva var beslutningen? Alt står stille til du finner den, så du setter på en kanne kaffe og fortsetter letingen. Dette blir en lang natt.

Vi skal utforske det praktiske ved RAID-logger og hvordan du kan integrere dem i prosjektarbeidsflyten din, slik at du kan drive samtaler med interessentene dine, enkelt kommunisere statusen for prosjektet og aldri mer må bruke timevis på å lete etter den e-posten fra sjefen.

Hei, folkens, og takk for at dere lytter. Jeg heter Galen Low og kommer fra Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et oppdrag om å hjelpe hverandre med å bli dyktigere, tryggere og bedre knyttet sammen, slik at vi kan øke verdien av prosjektledelse i en digital verden. Hvis du vil høre mer om dette, kan du gå til thedigitalprojectmanager.com.

I dag snakker vi om RAID-logger og den krevende kunsten å følge opp prosjektrisikoer, tiltak, problemer og beslutninger for å styre prosjekter mot suksess.

Med meg i dag er Kim Essendrup, tidligere fra Kolme Group – en organisasjon som er fast bestemt på å hjelpe virksomheter med å bygge datadrevet beslutningstaking inn i prosessene sine. Mange av dere kjenner ham imidlertid som en av de to grunnleggerne og programlederne for den svært populære podkasten PM Happy Hour.

Velkommen, Kim!

Kim Essendrup: Hei, Galen! Takk for invitasjonen.

Galen Low: Takk for at du er med. Å, herregud, dette er et kjendisøyeblikk for meg. PM Happy Hour er så morsomt. Hver episode jeg har hørt, har vært hysterisk morsom.

Uansett, jeg er misunnelig på podkasten din. Jeg synes den er fantastisk. Til de av lytterne våre som ikke kjenner den: Gå og hør på den. Den har en veldig god dynamikk. Jeg lurte faktisk på om jeg kunne starte med et skikkelig fanboy-spørsmål: Hva fikk deg til å starte PM Happy Hour i utgangspunktet?

Kim Essendrup: Først må jeg si at jeg faktisk også er stor fan av deg, så vi er gjensidige fans. Men ja, jeg drev mye med coaching av prosjektledere. Jeg oppdaget at jeg stadig gjentok de samme rådene, og tenkte: Vet du hva? Jeg legger dette ut på bloggen, så leser folk bloggen, og det blir flott. Så oppdaget jeg at folk egentlig ikke liker å lese blogginnlegg på 10 000 ord om prosjektledelse.

Det er ikke særlig morsomt. Jeg drev også med en liten oppstartsvirksomhet innen et annet tema, og konsulenten sa til meg: Vet du hva? Du bør lage en podkast. Så jeg jobbet meg gjennom hele prosessen med å finne ut hvordan man gjør det og skaffe en mikrofon. Jeg gjorde det for den andre oppstartsvirksomheten, som egentlig ikke kom noen vei, bortsett fra at jeg ble kjent med podkastverdenen.

Jeg kom inn i det og klarte å finne ut av det. Da tenkte jeg at jeg kanskje kunne ta noen av blogginnleggene og gjøre dem interessante. Og jeg tenkte: Hvem er den ene personen jeg kunne få med på en podkast, som til og med kunne gjøre prosjektledelse interessant?

Det var selvfølgelig Kate. Så jeg kontaktet Kate og sa: Hei, vil du gjøre dette sprø prosjektet? Og Kate var helt med. Siden da har det bare blitt morsommere og morsommere.

Galen Low: Jeg elsker det. Dynamikken er virkelig god. Jeg føler nesten at jeg hører på morgenradio, på skikkelig god morgenradio. Det er morsom småprat, men det handler også om prosjekter.

Jeg bare: Ja, dette er min greie. Dette er min greie. Uansett, jeg er stor fan. Stor fan. Så folkens, hvis dere ikke har hørt den, finner dere PM Happy Hour, eller Project Management Happy Hour, på nesten alle podkastapper jeg har sett.

Kim Essendrup: På alt vi kunne finne.

Galen Low: Nettopp. Flott. Flott. Da setter vi i gang.

I dag skal vi nerde litt om RAID-logger. For å gi lytterne våre et felles utgangspunkt: Kan du definere hva en RAID-logg er for deg, og hvorfor den er viktig?

Kim Essendrup: Ja. For å si det så enkelt som mulig er RAID-logg et akronym for Risikoer, Aktiviteter, Issues og Decisions – altså risikoer, tiltak, problemer og beslutninger. Noen organisasjoner foretrekker antakelser og avhengigheter i stedet for tiltak og beslutninger, men det kan vi snakke om senere.

Hovedideen er at dette er risikoregisteret og tiltaksregisteret – alle disse registrene du lærer at du skal ha, særlig hvis du følger en metode fra PMI. Historisk har vi fulgt disse elementene opp i det samme regnearket. Det var gammeldags allerede da jeg begynte med prosjektledelse for flere tiår siden.

Det har altså eksistert for alltid, og det er et uunnværlig operativt verktøy som hjelper prosjektledere med å drive prosjektene sine. I undersøkelsene våre ser vi at omtrent halvparten til to tredeler av prosjektlederne har brukt eller kjenner til det, og det er et virkelig kritisk verktøy. Derfor evangeliserer vi for det nå.

Galen Low: Veldig kult. Ja, jeg var en av dem som ikke hadde innsett det, men jeg satt i en økt der vi snakket med folk om RAID-loggen vår. Jeg hadde lært modellen med risikoer, antakelser, problemer og avhengigheter. Så rakk noen opp hånden og sa: Er du sikker på at det ikke er denne modellen? Og vi bare: Hvilken foretrekker du, og hvorfor?

Kim Essendrup: Jeg liker tiltak og beslutninger. Tenk på en antakelse. En antakelse er en planleggingsantakelse: Jeg skal gjennomføre dette prosjektet. Hvilke antakelser har vi om omfanget, eller hvilke antakelser har vi når vi utvikler planen? En antakelse er noe som fungerer mer som et innspill i begynnelsen.

En antakelse blir egentlig en risiko, for hvis antakelsen din var ugyldig, skaper det en risiko. Derfor faller antakelser naturlig inn under R for risiko. Avhengigheter gjør det samme. Hvis du har en ekstern avhengighet i prosjektet, er den enten en risiko, eller den hører kanskje hjemme i selve prosjektplanen fordi den har tidsaspekter, forgjengere og etterfølgere.

Den havner vanligvis på ett av disse to stedene. Noen ganger er eksterne avhengigheter så skremmende at de fortjener en egen fane. Da blir det vel RAIDD. Men jeg synes at hvis du holder fokus på tiltakene og beslutningene, er dette mer operative ting. Det er ting du må følge opp gjennom leveransen av prosjektet. Da blir RAID-loggen din et operativt verktøy du bruker fra dag til dag for å styre deg selv og holde orden.

Galen Low: Nei, jeg liker det. Jeg liker den fremdriften, og jeg er helt enig. Jeg slet med tanken på at alle antakelsene og avhengighetene mine egentlig var risikoer. Alt ble formulert som risiko i prosjektene mine, og jeg tenkte: Jeg vet ikke om jeg gjør dette riktig.

Kim Essendrup: Ja. Den beste måten å starte risikologgen på er kanskje å begynne med alle antakelsene og avhengighetene som hele planen din bygger på.

Galen Low: Og når du avkrefter eller bekrefter noen av antakelsene, kan de fjernes. Det liker jeg. Vi snakket om hvor viktig en RAID-logg er, og jeg setter særlig pris på beslutningsdelen.

Det å ha alt samlet i én logg, i stedet for å ha åtte forskjellige dokumenter som folk må kontrollere og holde oppdatert – og som de egentlig ikke ser på gjennom prosjektet – er veldig nyttig.

Kim Essendrup: Enten det, eller så må du søke gjennom Outlook: Å, herregud, hvor er den e-posten? Jeg vet at det finnes en e-post her et sted.

Galen Low: Jeg er kongen av Outlook-søk fordi jeg er kongen av å ikke organisere innboksen min i det hele tatt. Men ja, det gir absolutt mening. En av tingene vi snakket om tidligere, er at dette selvfølgelig handler om risiko, men også om å hindre at prosjektet havner i katastrofale situasjoner. Ikke for å høres skremmende ut, men det hjelper virkelig med å holde ting på rett spor. Kan du fortelle hvordan du funksjonelt ville brukt en RAID-logg til dette?

Kim Essendrup: Jeg liker å tenke på den som et verktøy for å holde et prosjekt i gang eller redde det. «Holde i gang»-delen er viktig, for hvis du ikke gjør dette, ender du sannsynligvis med å måtte redde ditt eget prosjekt.

Tenk på verktøyene du bruker til å styre prosjekter. Du har planen eller oppgavelisten, alle tingene du gjør som direkte bidrar til eller skaper leveransene dine. Det er flott, og det er det vi gjør. Men en RAID-logg handler om hvordan du sørger for at disse tingene faktisk blir gjort riktig.

RAID-loggen er ikke planen. Den er måten du sørger for at planen blir gjennomført på. Og hvem har vel et prosjekt som går perfekt? Hvis du har det, er du veldig heldig. Du kommer til å få problemer og utfordringer. Ting kan gå galt, og ting går galt.

Hva bruker du til å håndtere det? Du bruker ikke tidsplanen; du bruker RAID-loggen til å identifisere hva som kan gå galt, hvilke tiltak du må følge opp for å hindre at du og teamet ditt havner bakpå, hvilke problemer som har oppstått, og hvordan du får dem løst raskest mulig slik at prosjektet holder seg så godt på sporet som mulig.

Hvilke beslutninger må du forvente og planlegge for, eller iverksette og reagere på, eller få tatt, som du ikke tenkte på i starten av prosjektet? Dette er alle tingene vi må gjøre for å holde prosjektplanene på sporet og levere dem vellykket.

Når du ikke gjør dette – når du ikke tenker på risiko, planlegger og får beslutninger tatt og dokumentert – er det planen begynner å falle fra hverandre. Det handler egentlig om å styre det grunnleggende. Det er der prosjekter går galt: når du ikke passer på det grunnleggende og følger det opp. Det er magien med en RAID-logg for meg. Den er utrolig enkel, men svært viktig for å hjelpe oss med å ha kontroll på det grunnleggende.

Galen Low: Du nevnte coaching i bakgrunnen din. Har du noen historier om situasjoner der ting holdt på å spore av, og du tenkte at dette faktisk kunne løses med noe så grunnleggende som en RAID-logg?

Kim Essendrup: Ja. For noen år siden tok jeg over en PMO som var basert i Europa. Det var flott, siden jeg fikk firmabetalt reise til Europa. Jeg bodde fortsatt i Phoenix-området, så jeg dro dit omtrent én gang i måneden, og det var en veldig interessant organisasjon.

Når du tar over rollen som PMO-leder, har du også ansvaret for alle brannene. Det var fredag. Og når du får en telefon om et prosjekt på en fredag, er det aldri en god telefon. Det var midt på dagen hos meg, og sen ettermiddag eller kveld i Storbritannia.

De sa at prosjektet gikk så dårlig at kunden truet med å kreve betaling for problemene og deretter kansellere kontrakten. Mandag morgen var jeg ikke lenger i Phoenix. Jeg var i Midlands i Storbritannia. Jeg måtte få kontroll på prosjektet. Kunden var rasende.

Jeg var der sammen med hele teamet vårt, og de gikk gjennom alle problemene de hadde og alt de mente. Jeg tenkte: Dette høres legitimt ut. Jeg ville også vært opprørt. De gikk gjennom alle utfordringene og problemene sine, og jeg tenkte: Wow. Så jeg så på min side av bordet og sa: Har dere noen problemer?

De lyste opp. Kunden ga oss ikke dette. Dere ga oss ikke dette. Vi kunne ikke lykkes fordi dere ikke ga oss alt vi trengte for å lykkes. Kunden sa: Det fortalte dere meg ikke. Jeg visste ikke det. Så jeg ba alle vente til det ble stille.

Jeg sa: Kan dere vise meg RAID-loggen deres? Det ble stille. Jeg visste ikke om de ikke visste hva en RAID-logg var og var for flaue til å spørre, eller om de innså at de ikke hadde en RAID-logg og derfor var for flaue til å si noe. Jeg åpnet PC-en og hadde en RAID-logg klar.

Jeg begynte å gå gjennom den: La oss registrere alle problemene. Fortell meg om problemene deres. Så fikk alle lufte frustrasjonen sin på kundesiden. Jeg hadde loggen på projektoren og skrev inn alt. På den måten kunne jeg anerkjenne alle bekymringene og problemene deres. De følte at de endelig ble hørt, fordi de kunne se at jeg skrev det ned.

Så så jeg på min side av bordet og spurte teamet mitt: Hva med dere? Hva er problemet deres? Det var det samme. Jeg dokumenterte alt. Deretter begynte vi å se på punktene og sa: Dette virker som mange avhengigheter. Dere forventet dette, og vi visste ikke at vi skulle gjøre det.

Da begynte vi å dokumentere alle avhengighetene – hva vi var avhengige av hos dere, og hva dere var avhengige av hos oss. Det som var flott, var at vi i løpet av ettermiddagen gradvis vendte stolene våre mot projektoren. I stedet for å krangle med hverandre, kjempet vi mot problemene.

Det viser virkelig at en RAID-logg kan brukes til å rette opp problemer. Når du setter deg ned med et enkelt verktøy som en RAID-logg, får du en god plattform for å skape enighet, sørge for at alle forstår hverandre og lage en felles oversikt over problemene som teamet kan samarbeide om å løse. Det kan virkelig snu slike situasjoner, eller i det minste hjelpe deg med å få kontroll.

Galen Low: Jeg elsker den historien, og jeg liker også kroppsspråket. I stedet for å sitte ansikt til ansikt i en konfronterende situasjon begynner alle å vende seg mot samarbeid.

Én ting vi alltid undervurderer ved prosjektledelsesteknikker, taktikker og prosesser, er at alt skal hjelpe kommunikasjonen og samarbeidet. Jeg likte det du sa om avhengigheter. Det kan gå begge veier.

Hvis du ikke gjør dette, kan vi ikke gjøre det. Men på mange måter er det også: Du gjør dette, slik at vi kan gjøre det. Hvis folk ikke har oversikt over dette, er det vanskelig å forstå hvorfor de må gjøre noe. Kanskje utsetter de det, ingen sier noe, og plutselig er prosjektet langt unna der det må være.

Noen ganger handler det bare om å ha et spor av tingene vi må følge opp. Jeg vet at det kan virke som omfattende dokumentasjon, men jeg synes ikke det er noe skamfullt i å ikke klare å holde styr på hundrevis av ting gjennom prosjektet.

Det er vanskelig å huske alle beslutningene vi tok denne uken i hver eneste samtale.

Kim Essendrup: Det er det virkelig. Det er én ting å sitte i et møte og snakke med folk om en beslutning, en avhengighet eller en risiko. Men når du skriver det inn i et dokument – særlig hvis det er et delt dokument på Zoom eller en projektor – og skriver navn på det, blir det plutselig virkelig.

Hvis navnet mitt står der, begynner jeg å følge med. Det er derfor også et godt kommunikasjons- og ansvarliggjøringsverktøy. Jeg driver mye med coaching og veiledning av prosjektledere, og vi har et fellesskap rundt podkasten. Et råd vi stadig kommer tilbake til, er at hvis du begynner i et nytt miljø eller tar over et prosjekt, må du skaffe deg en RAID-logg hvis du ikke har en.

Du må forstå hvordan du skal drive og styre planen. Et av mine favorittuttrykk er, særlig hvis du jobber med et offentlig prosjekt: Behandle RAID-loggen som om den kan bli gjenstand for et rettslig pålegg om utlevering, for en dag kan den bli det. Da vil du være glad for at RAID-loggen er oppdatert.

Galen Low: Hundre prosent. Jeg har vært med på et par prosjekter som ble revidert av ulike årsaker. Det er ikke bra å mangle riktig dokumentasjon lett tilgjengelig, selv om dataene finnes et sted. Det er en hel jobb å grave dem frem. En ryddig dokumentasjon av hva som skjedde, hvor det var risiko, og hvordan vi snakket om risikoene, kan være utrolig nyttig.

Kim Essendrup: Jeg tipper det vekket deg den morgenen du oppdaget at du skulle ha revisjon samme dag.

Galen Low: Å, herregud. Åpne tidsregistreringen, alle sammen.

Du tok opp et godt poeng om det praktiske ved å bruke en RAID-logg. Mange tenker at det virker som mye arbeid. Du fikk to team til å snakke sammen ved hjelp av en projektor, men hvordan ser det ut å faktisk beholde loggen som sannhetskilde etter dette?

Kim Essendrup: Jeg tror prosjektlederen virkelig må leve etter den. Du kan se på den og tenke at dette er mye mer oppfølging og styring enn du må gjøre.

Og det er det. Du kan la være å bruke RAID-logg og håpe at det går bra, på samme måte som når du kjører gjennom et gult lys: Du kan lukke øynene, trykke på gassen og håpe at du ikke krasjer. Det kan fungere mange ganger. Men i alle mislykkede prosjekter jeg har måttet redde, har svaret alltid vært nei når jeg spør om å få se RAID-loggen.

Når prosjekter jeg har hatt begynner å komme ut av kurs, innser jeg at vi er på vei i grøfta. Da oppdager jeg at jeg ikke har fulgt opp RAID-loggen, eller at jeg ikke har laget en RAID-logg for prosjektet.

Etter at du har opplevd dette mange nok ganger, skjønner du at du må gjøre det. Hvis vi ser på det fra et overordnet perspektiv, finnes det mange analyser av hvor ofte prosjekter lykkes eller mislykkes.

Tallene varierer fra år til år og fra studie til studie, men man ser ofte at rundt 70–80 % av prosjektene ikke når de viktigste målene. Et sted mellom 19 og 20 % mislykkes fullstendig. Vi vet dette. Vi er prosjektledere.

Vi vet at problemer oppstår, at ting blir utsatt, og at ting koster mer enn forventet. Hvis du vet at det sannsynligvis vil oppstå et problem i prosjektet ditt, gjør du da deg selv og prosjektet en bjørnetjeneste hvis du ikke bruker litt tid på å unngå det?

Det er jobben vår. Vi er prosjektledere. Vi er heltene som får dette til. RAID-loggen er superheltverktøyet vi må bruke for å holde prosjektene på sporet.

Galen Low: Jeg synes statistikken er morsom også, fordi den kan gå begge veier. Det gjelder statistikk generelt, ikke bare prosjektledelse. Vi hører at én av tre kommer til å oppleve noe, og tenker: Det gjelder ikke meg. Når det skjer, tenker vi: Det måtte jo skje, siden én av tre opplever det. Det gir oss en unnskyldning for ikke å møte problemet direkte og være proaktive.

Vi kan lukke øynene og kjøre gjennom et gult lys. På den andre siden kan du bli helt lammet fordi du tenker at prosjektet sannsynligvis kommer til å mislykkes. Men slik du beskrev det tidligere, handler det egentlig om å ta tøylene.

Du har en plan, som et kart med en linje på. Men selve styringen av prosjektet fremover, og det å sørge for at det ikke ruller ut i grøfta, er ting som en RAID-logg. Jeg liker at alt er samlet og tydelig.

Folk kan samarbeide om den i et møterom. Men det får meg til å tenke på noe du sa tidligere: RAID-loggen min har alltid vært et regneark, og mange sier at de ikke trenger enda et regneark.

Hvilke verktøy finnes for å håndtere en RAID-logg i et prosjekt som ikke nødvendigvis er Excel eller Google Sheets?

Kim Essendrup: Det er morsomt. Det finnes selvfølgelig mange prosjektstyringsverktøy på markedet. Da jeg drev PPM-konsulentselskapet mitt i Kolme Group, implementerte teamet vårt prosjektstyringsverktøy i over 650 organisasjoner.

Det er fantastisk å ha startet et konsulentselskap som har fått gjøre slikt arbeid på tvers av selskaper av ulike størrelser og i ulike bransjer. Men det interessante er at verktøyene vi implementerte, egentlig ikke var særlig gode på RAID-logger.

Mange verktøy gjør ikke noe i nærheten av dette. De prøver ikke engang, og det er greit. De er laget for å være den ultimate programvaren for oppgavestyring, eller for ressursplanlegging og prognoser, og ressursstyring. Dette er verdifulle bruksområder som organisasjoner trenger for å fungere.

Men vi så at verktøyene enten var laget for ledelsens perspektiv – for planlegging på virksomhets- eller porteføljenivå – eller for teamet, med et svært enkelt og brukerstyrt grensesnitt.

Da ble prosjektlederen stående utenfor. Hvilke verktøy er laget spesielt for å gjøre prosjektlederens liv enklere? Gjennom implementeringene våre oppdaget vi et tomrom. Noen verktøy håndterte litt RAID, kanskje noen risikoer eller problemer, eller du kunne sette sammen noe selv.

Du kan lage en Kanban-tavle med risikoer og problemer, men da mister du mye av enkelheten og verdien i en grunnleggende RAID-logg. Vi snakket med noen av programvarepartnerne våre og sa: Dere må lage RAID-loggen vår.

De svarte: Vet du hva, Kim? RAID-logger finnes ikke i Gartners magiske kvadrant, så det kommer ikke på tale. Vi prøvde å få dem til å gjøre det, men de ville ikke. Til slutt sa vi at vi bare måtte gjøre det selv, fordi vi var lei av regneark.

Regneark fungerer, men de er de samme som alltid og har begrensninger. Det kan være vanskelig å dele dem, følge versjoner og samarbeide. Hvis du vil følge alle hendelsene rundt en bestemt risiko, blir det fort en lang rulling nedover i arket.

Det er vanskelig å styre, og du får ikke all verdien du burde kunne få fra et slikt verktøy. Derfor laget vi en skybasert RAID-logg som en tjeneste: raidlog.com. Den er enkel å huske. Vi er fortsatt i en tidlig fase, men målet vårt er å lage det ultimate verktøyet som hjelper prosjektledere med å lykkes.

Prosjektledere er superheltene. De har ansvaret for 1,7 billioner dollar i kapitalutgifter i USA hvert år. La oss gi dem verktøyene de trenger for å lykkes.

Galen Low: Jeg liker det. Det du sa om at programvare går i to retninger, er fascinerende. Du har virksomhetsperspektivet, og så har du teamet som bare prøver å få ting gjort. Verktøyene er enkle å bruke og krever lite opplæring.

De stammer sannsynligvis fra konsepter som Microsoft Project, men prosjektlederen blir likevel stående utenfor. Jeg bruker noen verktøy og tenker at de er laget slik hjernen min fungerer – statusoppdateringer, oppfølging av oppgaver, påminnelser og så videre. Men jeg har aldri funnet en RAID-funksjon i dem.

Kan du fortelle litt om hvordan løsningen fungerer? Kobles den til annen programvare, eller fungerer den alene?

Kim Essendrup: Det er en frittstående programvare. Den har RAID-loggen din og et brukergrensesnitt som ser ut som et regneark. Det er raskt, enkelt og effektivt. Hvis du er vant til RAID-logger, vil den ikke sinke deg.

Du blir ikke tvunget til å klikke, tabbe, tabbe, tabbe. Men vi har også et mer visuelt grensesnitt som er mer intuitivt hvis du er ny med RAID-logger, eller hvis du vil dele et kritisk problem med en leder. Du trenger ikke bare fremheve én rad i risikologgen; det kan være vanskelig å vise hva som foregår.

De visuelle komponentene lar deg åpne en detaljert visning av et problem eller en beslutning og presentere den på en måte som gjør det mulig å ha en forretningssamtale med interessenter og sponsor. Vi legger også til flere brukervennlige funksjoner som veileder deg gjennom prosessene.

Hvis du kjenner til et T-diagram, kan du for eksempel sette opp fordeler, ulemper og alternativer når du tar en beslutning. Dette har vi bygget inn i beslutningsmodulen. Det er ikke enkelt å gjøre i et regneark. Vi skal også legge til varmekart og andre funksjoner, som Monte Carlo-analyser og avansert analyse.

Senere får vi også AI-drevne funksjoner. Alt dette blir en frittstående RAID-logg. Men RAID-loggen er ikke det eneste verktøyet du bruker til å styre et prosjekt, så vi bygger integrasjoner. Vi har allerede en integrasjon med Planview AdaptiveWork, skal integrere med Jira og vil koble oss til så mange verktøy som mulig.

Vi er også koblet til Zapier, som igjen kobler seg til nesten alt i verden. Visjonen vår er å gjøre den regnearkbaserte RAID-loggen overflødig, ved å tilby en bedre løsning som alle kan bruke. Vi skal ha en kraftig gratisversjon for dem som bare ønsker en enkel og grunnleggende RAID-logg, og avanserte funksjoner for superbrukere.

Galen Low: Det jeg liker best, er at dette går langt utover en logg. For meg handler en logg om å registrere noe som har skjedd eller kan skje. Men dere har dybde: analyse, T-diagrammer og mer.

Det er egentlig RAID-styring mer enn bare en RAID-logg.

Kim Essendrup: Det er enda mer enn det. Vi kaller det raidlog.com fordi RAID-loggen er det viktigste operative verktøyet. Men RAID-logger har egentlig ikke utviklet seg særlig de siste tiårene, fordi vi har vært begrenset av verktøyene vi bruker.

Visjonen vår er å hjelpe prosjektledere ved å gi dem de verktøyene de trenger for å drive et prosjekt. Vi stopper ikke med RAID-elementer. Vi skal ta med lærdommer og andre ting, og integrere møtereferater, slik at du kan ta møtereferatet og oppdatere RAID-loggen samtidig. Da kan du spare mange timer hver uke.

Målet er å bli det foretrukne verktøyet. Uansett hvilket planleggingsverktøy, tidsplanleggingsverktøy eller oppgaveverktøy du bruker, skal vi kunne koble oss til det som et tillegg. Vi vil fjerne smerten fra prosjektledelse.

Galen Low: Jeg liker at det integreres med andre løsninger og er åpent. Zapier-integrasjoner gjør det mulig å hente inn og sende ut informasjon. Det blir nesten som risikaanalyse, risikostyring og beslutningsstyring. Det er et samarbeidslag som ofte mangler, enten på virksomhetsnivå eller helt ute i teamet.

Kim Essendrup: Vi vil være mer enn et verktøy. Med all opplæringen og coachingen ønsker jeg ikke bare å si: Her er et verktøy, lykke til. Vi vil bygge kunnskap, opplæring og utdanning inn i løsningen.

Hvis du er ny innen risikostyring, skal løsningen være intuitiv nok til at du kan forstå hva du skal gjøre, hva sannsynlighet og konsekvens betyr, og hvordan du bruker det. Vi vil ha kontekstbasert hjelp, men også avanserte funksjoner.

Jeg nevnte Monte Carlo-analyse, forventet økonomisk verdi og andre ting du kanskje har hørt om eller sett, men aldri brukt. Du skal slippe å sette opp alt i et regneark. Vi gjør arbeidet for deg. Du kan legge inn dataene, klikke på en knapp og få et forslag til hvilken reserve du bør planlegge for.

Galen Low: Jeg liker det. Jeg har laget flere risikoregistre fra bunnen av, og det er mange formler. Jeg skulle ønske jeg slapp.

Kim Essendrup: Det gjør du. På et tidspunkt tenker du: Dette er godt nok. Nå må jeg få prosjektet i gang. Jeg kan ikke holde på med dette hele dagen.

Galen Low: Bare sett av 15 % reserve og kjør på.

Det siste spørsmålet mitt handler om noe du sa: Noen verktøy mangler prosjektlederens funksjoner, som RAID-elementene. Men er RAID bare for prosjektledere?

Og hvis ikke, hvordan kan hvem som helst bruke dette til å bygge en teamkultur med ansvar for risikoer, tiltak, problemer og avhengigheter – og gjøre det mer til en lagidrett?

Kim Essendrup: Det er et godt spørsmål. RAID har selvfølgelig sitt opphav som et litt esoterisk prosjektstyringsverktøy som gamle prosjektledere lærte om.

Men egentlig handler det om hvordan du får planen gjennomført. Planen trenger ikke være et tradisjonelt fossefallsprosjekt. Den kan være smidig utvikling, produktutvikling eller arbeid for en produkteier.

Hvordan håndterer jeg risikoene for produktet mitt? Hvilke beslutninger må tas? Når en beslutning er tatt, eller noen tar en beslutning for meg, må jeg dokumentere og følge den opp. Det passer også inn i en smidig verden.

Hvis jeg er en Scrum Master som driver et team, hvordan tar jeg vare på teamet og sørger for at det kan være effektivt? RAID-loggen handler ikke først og fremst om produktet, men om teamet: Hvordan får jeg teamet til å lykkes, og hvordan støtter jeg det?

Hvis jeg går tilbake til prosjektledelse og er PMO-leder, og ønsker å veilede prosjektlederne mine, finnes det noen bedre måte å gjøre det på enn å si: Vis meg RAID-loggen din? Da kan jeg se hvordan de styrer prosjektene, tilby forslag og kontrollere at de faktisk gjør noe for å styre prosjektene.

Fra prosjektlederens perspektiv kan du også styre oppover i organisasjonen. Hvis du trenger tid med PMO-lederen, sponsorer eller interessenter, tar du med RAID-loggen og filtrerer den. Ikke vis hele listen – det blir for mye. Filtrer den ned til de tre eller fire viktigste punktene du trenger at de skal ta ansvar for. Da kan du si: La oss snakke om dette.

Det viser at du har kontroll, og det engasjerer de andre. RAID er derfor mye mer enn et operativt prosjektverktøy. Det er en arbeidsmåte og en måte å samarbeide på. Ikke bare en måte å holde orden på selv, men en måte å holde teamet organisert og motivert, og kommunisere og samarbeide med det.

Galen Low: Jeg liker alle disse poengene. Det er ikke mange som ikke håndterer risikoer, tiltak, problemer eller beslutninger i arbeidet sitt.

Dette kan være et hvilket som helst samarbeidsverktøy. Jeg er glad for at du nevnte filtreringen. Som prosjektledere bygger vi opp en høy kapasitet til å håndtere enorme mengder informasjon, og så viser vi frem Gantt-diagrammene våre. Alle andre bare: Nei.

Vi må begrense det. Det er avgjørende for RAID-logger. Du må få informasjonen inn i et format som kan presenteres og diskuteres med en interessent fra virksomheten, ikke nødvendigvis en annen prosjektleder. Du kan bruke den til å styre et team av prosjektledere og håndtere forventninger hos ledelsen. Det er en sannhetskilde som kan brukes til mange ting og gjøre arbeidet mye smidigere.

Kim Essendrup: Det er det. RAID er bare begynnelsen. Ofte utvides dette med for eksempel lærdommer. Det er ille å ha problemer, men enda verre å ha det samme problemet igjen og igjen. Ved å legge til lærdommer i RAID-loggen kan du håndtere problemene og gjøre livet enklere neste gang.

Galen Low: Jeg liker det, og jeg er også spent på AI-funksjonene.

Jeg synes dette er veldig interessant. Hvor kan folk finne ut mer om RAID-logg?

Kim Essendrup: På raidlog.com. Det er et enkelt domene å huske. Jeg håper folk prøver produktet og gir oss tilbakemeldinger, for vi vil lage et godt verktøy for prosjektledere. Ta gjerne kontakt med meg på LinkedIn.

Jeg liker å snakke med alle. Hvis du har tilbakemeldinger om produktet eller podkasten, eller bare vil nerde om prosjektledelse, vil jeg gjerne høre fra deg. Hvis du er helt ny med RAID-logger og lurer på hva dette er, skrev jeg faktisk en bok. Merkelig nok fantes det ingen bok om RAID-logger, så jeg tenkte at dette måtte jeg rette opp. Søk etter "Ultimate Guide to RAID Log" på Amazon, så finner du boken min. Jeg tror det er den eneste boken om RAID-logger.

Galen Low: Det er utrolig. Det visste jeg ikke. Jeg legger alle lenkene i shownotatene for lytterne. Jeg skal også undersøke det, for dette er fascinerende. Jeg har alltid tenkt: Det er bare et regneark. Nå skal jeg absolutt se nærmere på det.

Kim Essendrup: Flott.

Galen Low: Flott. Kim, tusen takk for at du var med i dag. Jeg setter stor pris på innsikten din. Jeg elsker alltid å nerde om prosjektledelse, særlig slike ting – prosjektledelsens tradisjoner, RAID-logger, risikoregistre og alt som virker nesten ugjennomtrengelig. Når vi begynner å snakke om det, viser det seg egentlig å være ganske grunnleggende og fornuftige ting å ha.

Jeg setter stor pris på perspektivet ditt. Dette var virkelig flott.

Kim Essendrup: Tusen takk for invitasjonen, Galen.

Galen Low: Da har dere det, folkens. Som alltid: Hvis du vil delta i samtalen med over tusen likesinnede forkjempere for prosjektledelse, kan du bli med i fellesskapet vårt. Gå til thedigitalprojectmanager.com/membership for å lære mer.

Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com. Til neste gang: Takk for at du lyttet.