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

Les transkripsjonen:

Vi prøver ut transkripsjon av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom roboten ikke er korrekt 100 % av tiden.

Galen Low: Du leter febrilsk gjennom innboksen igjen. Denne gangen ser 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 integrerer dem i prosjektarbeidsflyten din, slik at du kan drive samtaler med interessentene dine, enkelt kommunisere statusen for prosjektet og aldri mer trenger å bruke timevis på å lete etter den e-posten fra sjefen.

Hei, folkens, og takk for at dere lytter. Jeg heter Galen Low og jobber med The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et mål 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 skal vi snakke om RAID-logger og den krevende kunsten å følge opp prosjektrisikoer, handlinger, problemer og beslutninger for å styre prosjekter mot suksess.

Med meg i dag har jeg Kim Essendrup, tidligere fra Kolme Group – en organisasjon som er fast bestemt på å hjelpe virksomheter med å bygge datadrevet beslutningstaking inn i prosessene sine. Mange kjenner ham imidlertid som én 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.

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

Kim Essendrup: Først må jeg si at jeg faktisk også er stor fan av deg, så beundringen er gjensidig. Jeg drev mye med veiledning av prosjektledere. Jeg oppdaget at jeg gjentok de samme rådene om og om igjen, og tenkte at jeg bare kunne legge dem ut på bloggen, så ville folk lese den, og alt ville bli bra. Så fant jeg ut at folk egentlig ikke liker å lese blogginnlegg på 10 000 ord om prosjektledelse.

Det er ikke særlig morsomt. Jeg hadde også en liten oppstartsvirksomhet jeg jobbet med, om et annet tema, og konsulenten sa: «Vet du hva? Du burde 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 ikke kom særlig langt, bortsett fra at jeg ble kjent med podkastverdenen.

Jeg kom inn i det og klarte å finne ut av det. Da tenkte jeg: Kanskje jeg kan ta noen av blogginnleggene og gjøre dem faktisk interessante. Og hvem kunne jeg få med i en podkast som kunne gjøre prosjektledelse interessant?

Det var selvfølgelig Kate. Så jeg kontaktet Kate og sa: «Hei, har du lyst til å gjøre denne sprø greia?» Kate var helt med. Siden da har det bare blitt morsommere og morsommere.

Galen Low: Jeg elsker det. Dere har en veldig god dynamikk. Jeg føler nesten at jeg lytter til morgenradio, virkelig god morgenradio. Det er hysterisk småprat, men det handler også om prosjekter.

Jeg tenker: Ja, dette er min greie. Dette er min greie. Uansett, jeg er stor fan. Så hvis dere ikke har sjekket det ut, finnes PM Happy Hour, eller Project Management Happy Hour, på nesten alle podkastapper jeg har sett.

Kim Essendrup: På alt vi klarte å finne.

Galen Low: Nettopp. Fantastisk. La oss sette i gang.

I dag skal vi bli nerdete om RAID-logger. Kanskje vi kan begynne med en kort avklaring for lytterne våre: 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: En RAID-logg er en logg der RAID er et akronym for risikoer, handlinger, problemer og beslutninger. Noen organisasjoner foretrekker antakelser og avhengigheter fremfor handlinger og beslutninger, men det kan vi snakke om om litt.

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

Det har altså eksistert lenge og er et uunnværlig operativt verktøy som hjelper prosjektledere med å styre prosjektene sine. I undersøkelsene våre ser vi at omtrent halvparten til to tredeler av prosjektledere har brukt eller kjenner til det, og det er et svært viktig verktøy. Derfor arbeider vi for å få flere til å ta det i bruk.

Galen Low: Veldig kult. Jeg var en av dem som ikke egentlig hadde innsett det, men jeg satt i en økt og snakket med folk om RAID-loggen vår. Jeg hadde lært modellen med risikoer, antakelser, problemer og avhengigheter. Da rakk noen opp hånden og sa: «Er du sikker på at det ikke er dette?» Da spør man: Hvilken variant foretrekker du, og hvorfor?

Kim Essendrup: Jeg liker handlinger og beslutninger. Hvis du tenker på en antakelse, er det 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 i større grad fungerer som et innspill i begynnelsen.

En antakelse blir egentlig en risiko, for hvis antakelsen er ugyldig, skaper det en risiko. Derfor faller antakelser naturlig inn under R for risiko for meg. Avhengigheter fungerer på samme måte. Hvis du har en avhengighet i prosjektet, og det er en ekstern avhengighet, er det enten en risiko eller noe som kanskje også hører hjemme i selve prosjektplanen fordi det er knyttet tid til den, med 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, og da blir det vel RAIDD. Men jeg synes at hvis du fokuserer på handlingspunktene og beslutningene, er dette mer operative ting. Det er ting du må holde oversikt over gjennom leveransen av prosjektet, og det gjør at du bruker RAID-loggen mer operativt, som et verktøy du bruker daglig for å styre deg selv og holde orden.

Galen Low: Nei, jeg liker det. Jeg liker denne typen fremdrift, og jeg er helt enig. Jeg støtte stadig på problemet at alle antakelsene og avhengighetene mine egentlig var risikoer. Alt var formulert som risiko i prosjektene mine, og jeg tenkte: Jeg vet ikke om jeg gjør dette riktig.

Kim Essendrup: Ja. Kanskje den beste måten å starte risikologgen på er å 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, spesielt i én logg, i stedet for å ha åtte forskjellige dokumenter som folk må undersøke og holde oppdatert – og som de ærlig talt vanligvis ikke ser på gjennom prosjektet.

Kim Essendrup: Alternativet er at du må søke gjennom Outlook: «Herregud, hvor er den e-posten? Jeg vet at den var her et sted.»

Galen Low: Jeg er kongen av Outlook-søk, fordi jeg også er kongen av å ikke organisere innboksen min i det hele tatt. Men ja, det gir absolutt mening. En av tingene vi snakket om tidligere, var at dette selvsagt handler om risiko, men også om noe som kan hindre prosjektet i å havne i katastrofale situasjoner. Ikke for å høres veldig skremmende ut, men det bidrar virkelig til å holde ting på sporet. Kan du fortelle meg hvordan du ville brukt en RAID-logg til det – funksjonelt sett?

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 veldig viktig, for hvis du ikke gjør det, ender du sannsynligvis med å måtte redde ditt eget prosjekt.

Hvis du tenker på verktøyene du bruker til å styre prosjektene dine, har du planen eller oppgavekøen din – alle aktivitetene som direkte bidrar til eller skaper leveransene dine. Det er flott, og det er det vi gjør. Men RAID-loggen handler om hvordan du sikrer at disse tingene faktisk blir gjort.

RAID-loggen er ikke planen. Den er måten du sikrer at planen blir gjennomført på. Og hvem har egentlig et prosjekt som går perfekt? Hvis du har det, er du svært 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 små handlinger du må følge opp for å sikre at du og teamet ikke blir forsinket, hvilke problemer som har oppstått og hvordan du løser dem raskest mulig, slik at prosjektet holder seg så godt på sporet som mulig.

Hvilke beslutninger må du forvente og planlegge for, gjennomføre og reagere på – eller få tatt – som du ikke tenkte på i begynnelsen av prosjektet? Det er alt dette vi må håndtere for å holde prosjektplanene på sporet og levere dem på en vellykket måte.

Når du ikke gjør disse tingene, når du ikke tenker på risiko, planlegger for beslutninger og får dem tatt og dokumentert, er det da planen begynner å falle fra hverandre. Det handler egentlig om å håndtere det grunnleggende. Det er der prosjekter går galt – når du ikke følger med på det grunnleggende og holder oversikt. For meg er det magien ved en RAID-logg. Den er så enkelt, men samtidig så viktig for å hjelpe oss med å ha kontroll på det grunnleggende.

Galen Low: Du nevnte at du har erfaring med veiledning. Har du noen historier om nettopp dette, der ting var i ferd med å spore av, og du tenkte: Dette kan faktisk løses med noe så grunnleggende som en RAID-logg?

Kim Essendrup: Ja. For noen år siden tok jeg over et PMO som var basert i Europa, noe som var veldig kult fordi 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, er du også ansvarlig for alle brannene. Det var fredag. Og når du får en telefon på en fredag om et prosjekt, er det aldri en god telefon. Det var midt på dagen hos meg og sent på ettermiddagen eller kvelden 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. Så de gikk gjennom alle utfordringene og problemene sine, og jeg tenkte: Jøss. Jeg så over på min side av bordet og spurte: «Har dere noen problemer?»

Da lyste de opp. Kunden hadde ikke gitt dem dette. Vi hadde ikke gitt dem dette. De kunne ikke lykkes fordi de ikke hadde fått alt de trengte. Kunden sa: «Det fortalte dere meg aldri. Det visste jeg ikke.» 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 faktisk ikke hadde en RAID-logg og derfor var for flaue til å si noe. Jeg åpnet den bærbare datamaskinen og hadde en RAID-logg klar.

Jeg begynte: «La oss loggføre alle problemene. Fortell meg problemene deres.» Vi fikk alt ut og lot kundesiden få lufte frustrasjonen. Jeg hadde loggen på projektoren og skrev inn alt. Dermed 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å teamet mitt og spurte: «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, mens vi ikke visste at vi måtte gjøre det.»

Da begynte vi å dokumentere alle avhengighetene – hva vi var avhengige av fra dem, og hva de var avhengige av fra oss. Det interessante var at vi i løpet av ettermiddagen gradvis snudde stolene våre. I stedet for at den ene siden av konferansebordet ropte til den andre, så vi alle opp på projektoren. Vi kjempet ikke lenger mot hverandre; vi kjempet mot problemene.

Det viser virkelig hvordan en RAID-logg kan brukes til å løse et problem. Når du setter deg ned og bruker et enkelt verktøy som en RAID-logg, blir den en flott plattform for å skape enighet, sørge for at alle forstår hverandre og etablere en felles oversikt over problemene som teamet kan samarbeide om å løse. Den kan virkelig snu slike situasjoner, eller i det minste hjelpe deg med å få kontroll på dem.

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

Én ting vi alltid undervurderer ved alle disse prosjektledelsesteknikkene, taktikkene og prosessene, er at de skal hjelpe kommunikasjonen og samarbeidet. Jeg likte det du sa tidligere 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 innsikt i dette, er det vanskelig for dem å forstå hvorfor de må gjøre noe. Kanskje utsetter de det, ingen sier noe, og plutselig er prosjektet langt unna der det burde 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 på slutten av dagen synes jeg ikke det er noe skammelig i å ikke klare å holde oversikt over hundrevis av ting som må følges opp i løpet av 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 å være i et møte og snakke med folk om en beslutning, avhengighet eller risiko. Men når du skriver det inn i et dokument – særlig et delt dokument på Zoom eller en projektor – og skriver navn ved siden av, 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 veileder og lærer opp mange prosjektledere, og vi har et fellesskap rundt podkasten. Noe vi ofte vender tilbake til, er at hvis du kommer inn i et nytt miljø eller tar over et prosjekt, bør du skaffe en RAID-logg hvis du ikke allerede har en.

Da må du begynne å forstå hvordan du skal gjennomføre og styre planen. Et av favorittuttrykkene mine er at du, særlig hvis du jobber med et offentlig prosjekt, bør behandle RAID-loggen som om den kan bli gjenstand for en rettslig stevning – 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 svært nyttig å ha riktig dokumentasjon tilgjengelig, selv om du har dataene et sted. Du slipper å grave dem frem som et helt eget prosjekt, og du får et ryddig spor av hva som skjedde, hvor det var risiko, og hvordan vi snakket om risikoene.

Det kan være enormt nyttig.

Kim Essendrup: Jeg tipper det fikk deg til å våkne skikkelig da du oppdaget at du skulle ha revisjon den dagen.

Galen Low: Herregud, ja. Åpne tidsregistreringen, alle sammen.

Jeg tror du tok opp et veldig godt poeng om det praktiske ved å bruke en RAID-logg. Mange tenker at det høres ut som mye arbeid. Jeg vet at du satte den opp på projektoren og fikk to team til å snakke sammen, men hvordan ser det ut å faktisk beholde den som sannhetskilde etter dette øyeblikket med enighet?

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

Og det er det. Du kan velge å ikke bruke en 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, gi gass 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 har spurt: «Kan du vise meg RAID-loggen din?»

Når prosjektene mine begynner å spore av, og jeg innser at vi er på vei i grøfta, oppdager jeg gjerne at jeg ikke har fulgt opp RAID-loggen eller opprettet en for prosjektet.

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

Tallene varierer fra år til år og fra undersøkelse til undersøkelse, men ofte ser vi 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.

Problemer oppstår, ting blir utsatt, og noe kommer til å koste mer enn du trodde. Hvis du vet at det sannsynligvis vil oppstå et problem i prosjektet ditt, gjør du da deg selv og prosjektet en bjørnetjeneste ved ikke å bruke litt tid på å forsøke å unngå det?

Det er jobben vår. Vi er prosjektledere. Vi er heltene som får dette til. RAID-loggen er et slags superheltvåpen vi må bruke for å holde prosjektene på sporet.

Galen Low: Jeg synes statistikken er morsom også, fordi den kan brukes begge veier. Det gjelder ikke bare prosjektledelse. Når vi hører at én av tre personer kommer til å oppleve noe, tenker vi: «Det gjelder ikke meg.» Og når det skjer, tenker vi: «Det måtte jo skje, siden én av tre opplever det.» Vi bruker det som en unnskyldning for ikke å ta tak i ting og være proaktive.

Som du sa, kan vi 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, handler det egentlig om å ta tøylene.

Du har en plan, som er et kart med en linje tegnet på. Men rattet som faktisk styrer prosjektet fremover og sørger for at det ikke havner i grøfta, er ting som RAID-loggen. Jeg liker at alt er samlet og tydelig.

Folk kan se på den og samarbeide om den i et møterom. Det får meg til å tenke på noe annet du sa tidligere: For deg og meg har RAID-loggen alltid vært et regneark. Mange tenker: «Jeg trenger ikke enda et regneark.»

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

Kim Essendrup: Det er morsomt. Det finnes selvsagt mange prosjektstyringsverktøy på markedet. I Kolme Group, da jeg drev konsulentvirksomheten min innen portefølje- og prosjektstyring, implementerte teamet vårt prosjektstyringsverktøy i over 650 organisasjoner.

Det er fantastisk å ha startet en konsulentvirksomhet som har kunnet gjøre slikt arbeid på tvers av selskaper av ulik størrelse og i ulike bransjer. Men det interessante er at verktøyene vi implementerer, egentlig ikke gjør en god jobb med RAID-logger.

Mange verktøy gjør ikke noe som ligner engang. De later ikke som de gjør det, og det er greit. De fokuserer på å være den beste programvaren for oppgavestyring, eller på virksomhetsressursplanlegging, prognoser og ressursstyring. Dette er verdifulle bruksområder som organisasjoner trenger for å fungere godt.

Men vi ser at verktøyene enten er laget for ledelsens perspektiv, med oversikt og planlegging på virksomhets- eller porteføljenivå, eller for teamet, med svært enkel og brukerstyrt funksjonalitet og lite administrasjon.

Det som skjer, er at prosjektlederen blir stående utenfor. Hvilke verktøy er laget spesielt for å gjøre livet enklere for prosjektlederen? Gjennom implementeringene våre oppdaget vi et tomrom. Noen verktøy håndterte litt av RAID, kanskje risikoer eller problemer, eller lot deg sette sammen et eget oppsett.

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-logg.» De svarte at RAID-logger ikke finnes i Gartners magiske kvadrant, så det kom ikke til å skje.

Til slutt sa vi at vi fikk gjøre det selv, fordi vi var lei av regneark. Regneark fungerer, men de er begrensede. Det kan være vanskelig å dele dem, følge versjoner og samarbeide. Hvis du vil følge alle hendelsene knyttet til en bestemt risiko, ender du kanskje med lange kolonner og mye rulling.

Derfor opprettet vi en skybasert RAID-logg som en tjeneste, raidlog.com. Den er lett å huske. Vi er fortsatt i en tidlig fase, men målet vårt er å lage det ultimate verktøyet for at prosjektledere skal lykkes.

Prosjektledere er heltene. De har ansvar for 1,7 billioner dollar i kapitalutgifter i USA hvert år. La oss gi disse menneskene bedre forutsetninger for å lykkes.

Galen Low: Jeg liker det. Det er fascinerende at programvare faktisk går i to retninger: virksomhetsperspektivet på den ene siden og teamet som bare prøver å få ting gjort, på den andre.

Mange verktøy bygger opprinnelig på konsepter som Microsoft Project, men prosjektlederen blir likevel stående utenfor. Jeg bruker noen verktøy og tenker: «Dette har de laget på samme måte som hjernen min fungerer.» Statusoppdateringer, oppfølging av oppgaver, påminnelser og lignende. Men jeg har aldri funnet en RAID-funksjon i dem.

Kan du fortelle litt om hvordan det fungerer? Kobles det til annen programvare, eller fungerer det selvstendig?

Kim Essendrup: Det er et frittstående program. Det har RAID-loggen din og et brukergrensesnitt som ser ut som et regneark. Det er raskt, enkelt og effektivt. Hvis du kjenner RAID-logger, vil det ikke sinke deg.

Vi har også et mer visuelt brukergrensesnitt som er intuitivt for nye brukere eller når du vil dele en kritisk sak med en leder. I stedet for å fremheve én rad i risikologgen kan du åpne en detaljert visning av problemet eller beslutningen og presentere den på en måte som legger til rette for en forretningssamtale med interessenter og sponsor.

Vi legger til brukervennlige funksjoner som veileder deg gjennom prosessene. Hvis du kjenner en T-tabell, kan du for eksempel sette opp fordeler, ulemper og alternativer når du skal ta en beslutning. Dette har vi bygget inn i beslutningsmodulen.

Vi skal også legge til varmekart og andre funksjoner som du gjerne burde kunne bruke, men som er vanskelige å gjennomføre selv, for eksempel Monte Carlo-analyse og avansert analyse.

Senere skal vi også legge til funksjoner drevet av kunstig intelligens. RAID-loggen blir frittstående, men den er ikke det eneste verktøyet du bruker til å styre et prosjekt. Derfor bygger vi integrasjoner. Vi har allerede én med Planview AdaptiveWork, og vi skal integrere med Jira og så mange andre verktøy som mulig.

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

Galen Low: Vet du hva jeg liker best? I mitt hode går dette langt utover en logg. En logg er bare å registrere noe som har skjedd eller kan skje – som et notat. Det er slik RAID-loggene mine vanligvis har sett ut: «Vi må snakke om dette.» Men dere tilbyr dybde, analyse og T-tabeller.

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

Kim Essendrup: Det er enda mer enn det. Vi kaller det raidlog.com fordi dette er det vi kjenner som det viktigste operative verktøyet. RAID-logger har imidlertid 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 og gi dem verktøyene de trenger for å gjennomføre et prosjekt. Vi skal ikke stoppe ved RAID-elementer. Vi skal inkludere erfaringer og lærdom, møtereferater og andre ting. Du skal kunne ta møtereferatet og oppdatere RAID-loggen samtidig, slik at du sparer mange timer hver uke.

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

Galen Low: Jeg liker at det integreres med andre løsninger og er åpent. Du har Zapier-integrasjoner som kan hente inn og sende ut informasjon. Det blir nesten som et lag for risikoanalyse, risikostyring og beslutningsstyring – et samarbeidslag som noen ganger mangler på virksomhetsnivå eller helt ute i den praktiske gjennomføringen.

Kim Essendrup: Og på grunn av all opplæringen og veiledningen vil vi være mer enn et verktøy. Vi vil bygge kunnskap, opplæring og utdanning inn i løsningen. Hvis du er ny innen risikostyring, skal den være intuitiv nok til at du kan forstå hva du skal gjøre, hva sannsynlighet og konsekvens betyr, og hvordan funksjonene brukes.

Vi vil ha kontekstbasert hjelp og mer avanserte funksjoner. Jeg nevnte Monte Carlo-analyse, men vi skal også ha forventet pengeverdi og andre ting du kanskje har hørt om eller sett, men aldri brukt. Du slipper å bygge alt inn i regnearket selv. Du legger inn dataene, trykker på en knapp, og systemet hjelper deg med å beregne hvilken reserve du bør planlegge for.

Galen Low: Jeg elsker det. Jeg har bygget flere risikoregistre fra bunnen av, og det krever mange formler. Jeg skulle ønske jeg slapp.

Kim Essendrup: Det gjør det. På et visst tidspunkt tenker du: «Dette er godt nok. Nå må jeg få ting til å skje. Jeg har et prosjekt å gjennomføre.»

Galen Low: Bare kall det 15 % reserve og sett i gang.

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

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

Kim Essendrup: Opprinnelsen til RAID er et spesialisert prosjektstyringsverktøy som tradisjonelle prosjektledere lærte om. Men egentlig handler det om hvordan du får planen gjennomført. Planen trenger ikke nødvendigvis være et tradisjonelt fossefallsprosjekt.

Det kan være smidig utvikling, produktarbeid eller rollen som produkteier. Du har et produkt som skal utvikles i en smidig verden. Hvordan håndterer du risikoene for produktet? Hvilke beslutninger må tas? Når en beslutning er tatt, må den dokumenteres og følges opp.

Hvis jeg er smidig teamleder og driver et team, hvordan følger jeg opp teamet og sørger for at det kan være effektivt? RAID-loggen handler ikke bare om produktet, men om teamet: Hvordan får jeg teamet til å lykkes, og hvordan kan jeg støtte det?

Hvis jeg 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 du styrer prosjektene dine og komme med forslag.

Fra prosjektlederens perspektiv kan du også bruke loggen til å styre oppover i organisasjonen. Hvis du trenger tid med PMO-lederen, sponsoren eller interessenter, filtrerer du RAID-loggen. Ikke vis hele listen – det blir for mye. Filtrer den til de tre eller fire viktigste punktene du trenger hjelp med, og inviter til en samtale.

Derfor er RAID 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 også en måte å holde teamet organisert og motivert på og kommunisere og samarbeide med det.

Galen Low: Jeg liker alle disse poengene. Det finnes knapt noen som ikke arbeider med risikoer, handlinger, problemer eller beslutninger i en eller annen form.

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 for å håndtere enorme mengder informasjon, og så viser vi frem Gantt-diagrammene våre. Folk tenker: «Nei takk.»

Vi må begrense det. Det er avgjørende for RAID-logger. Du må få informasjonen inn i et format du kan presentere og diskutere med en forretningsinteressent, 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. Hvis du følger den opp grundig, kan den brukes til mange ulike ting og gjøre arbeidet mye smidigere.

Kim Essendrup: Det er den virkelig. RAID er bare begynnelsen, og vi ser ofte at den utvides med for eksempel læringspunkter. Det er ille å ha problemer, men enda verre å ha det samme problemet om og om igjen. Ved å legge til læringspunkter kan du håndtere problemene og gjøre livet enklere neste gang.

Galen Low: Jeg liker det, og jeg er også spent på funksjonene med kunstig intelligens.

Dette er veldig interessant. Hvor kan folk finne ut mer om RAID-logg?

Kim Essendrup: På raidlog.com. Det er et enkelt domenenavn å huske. Jeg vil gjerne at folk prøver produktet og gir oss tilbakemeldinger, fordi vi ønsker å gjøre dette til et godt verktøy for prosjektledere. Du kan kontakte meg på LinkedIn.

Jeg liker å snakke med alle. Hvis du har tilbakemeldinger på produktet eller podkasten, eller bare vil fordype deg i prosjektledelse, vil jeg gjerne gjøre det. Hvis RAID-logger er helt nytt for deg og du lurer på hva dette handler om, 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 programnotatene for lytterne. Jeg skal også sjekke det ut, for dette er fascinerende. Jeg har alltid tenkt: «Det er jo bare et regneark.» Nå skal jeg absolutt se nærmere på det.

Kim Essendrup: Supert.

Galen Low: Supert. Kim, tusen takk for at du var med i dag. Jeg setter stor pris på innsikten din. Jeg liker alltid å fordype meg i prosjektledelse, særlig i slike ting som RAID-logger, risikoregistre og andre deler av prosjektledelsesfaget som kan virke ugjennomtrengelige. Når vi begynner å snakke om dem, viser det seg at de egentlig er grunnleggende og fornuftige ting å ha.

Tusen takk for perspektivet ditt. Dette var veldig bra.

Kim Essendrup: Takk for invitasjonen, Galen.

Galen Low: Da har dere det, folkens. Som alltid: Hvis du vil bli med i samtalen med over tusen likesinnede forkjempere for prosjektledelse, kan du bli med i fellesskapet vårt. Gå til thedigitalprojectmanager.com/membership for å lese 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.