Hvad er en RAID-log (og hvordan integrerer du den i din projektarbejdsgang)?

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle slåfejl, da botten ikke er korrekt 100 % af tiden.

Galen Low: Du leder febrilsk gennem din indbakke igen. Denne gang leder du efter den e-mail fra din chef, der bekræfter en beslutning om dit projekt. Hvad hed personen? Hvad var beslutningen? Alt står stille, indtil du finder den, så du sætter en kande kaffe over og fortsætter med at lede. Det bliver en lang nat.

Vi skal undersøge det praktiske ved RAID-logge, og hvordan du integrerer dem i din projektarbejdsgang, så du kan drive samtaler med dine interessenter, nemt kommunikere status for dit projekt og aldrig mere behøver bruge timer på at lede efter den e-mail fra din chef.

Hej alle sammen, og tak fordi I lytter med. Jeg hedder Galen Low og er fra The Digital Project Manager. Vi er et fællesskab af digitale fagfolk med missionen om at hjælpe hinanden med at blive dygtigere, mere selvsikre og bedre forbundet, så vi kan øge værdien af projektledelse i en digital verden. Hvis du vil høre mere om det, så besøg thedigitalprojectmanager.com.

Okay, i dag taler vi om RAID-logge og den fine kunst at spore projektrisici, handlinger, problemer og beslutninger for at styre projekter mod succes.

I dag har jeg Kim Essendrup med. Han er tidligere fra Kolme Group—en organisation, der brænder for at hjælpe virksomheder med at opbygge datadrevet beslutningstagning i deres processer. Men mange af jer kender ham sikkert som en af de to grundlæggere og værter af den meget, meget populære podcast PM Happy Hour.

Velkommen, Kim!

Kim Essendrup: Hej, Galen! Tak fordi du inviterede mig.

Galen Low: Tak fordi du er med i programmet. Åh gud, det her er et kendisøjeblik for mig. PM Happy Hour er så sjov. Hvert afsnit, jeg har lyttet til, har været fantastisk underholdende.

Nå, men jeg er misundelig på din podcast. Jeg synes, den er fantastisk. Til de af vores lyttere, der ikke kender den, så gå endelig ind og hør den. Den har en virkelig god dynamik. Jeg tænkte faktisk, om jeg måtte lægge ud med et totalt fanboy-spørgsmål: Hvad fik dig til at starte PM Happy Hour-podcasten i første omgang?

Kim Essendrup: Først må jeg sige, at jeg faktisk også er stor fan af dig, så vi er gensidige fans. Men ja, jeg coachede mange projektledere. Jeg oplevede, at jeg blev ved med at give de samme råd igen og igen, og jeg tænkte: Ved du hvad? Jeg skriver det bare på bloggen, så læser folk bloggen, og så bliver det godt. Men så fandt jeg ud af, at folk faktisk ikke rigtig bryder sig om at læse blogindlæg på 10.000 ord om projektledelse.

Det er ikke særlig sjovt. Og jeg havde en anden lille startupvirksomhed, som jeg arbejdede på, om et andet emne, og konsulenten sagde: Ved du hvad? Du burde lave en podcast. Så jeg arbejdede mig gennem hele processen med at finde ud af, hvordan man gør, og skaffede en mikrofon. Jeg lavede den for den anden startup, som ikke rigtig kom nogen vegne, bortset fra at den fik mig ind i podcastverdenen.

Jeg kom ind i rytmen. Jeg fandt ud af det. Og jeg tænkte: Måske kan jeg tage nogle af de blogindlæg og gøre dem interessante. Og jeg tænkte: Hvem er den ene person, jeg kunne få med i en podcast, som kunne gøre projektledelse interessant?

Og det var helt klart Kate. Så jeg kontaktede Kate og sagde: Hej, har du lyst til at gøre den her vanvittige ting? Og Kate var helt med på den. Så det er bare blevet sjovere og sjovere lige siden.

Galen Low: Jeg elsker det. Det er en virkelig god dynamik. Jeg føler næsten, at jeg lytter til morgenradio, altså virkelig god morgenradio. Det er bare morsom pingpong, men det handler også om projekter.

Jeg tænker: Ja, det her er lige mig. Det her er lige mig. Nå, men jeg er stor fan. Stor fan. Så folkens, hvis I ikke har hørt den, findes PM Happy Hour eller Project Management Happy Hour på, tror jeg, næsten alle podcastapps, jeg har set.

Kim Essendrup: Alle dem, vi kunne finde.

Galen Low: Netop. Fantastisk. Fantastisk. Okay, lad os dykke ned i det.

I dag skal vi være nørdede omkring RAID-logge. Og jeg tænkte, at vi måske lige skulle skabe et fælles udgangspunkt for vores lyttere: Kan du definere, hvad en RAID-log er for dig, og hvorfor den er vigtig?

Kim Essendrup: Ja. Hvis jeg skal sige det så enkelt som muligt, er en RAID-log—RAID er et akronym for Risks, Actions, Issues and Decisions, altså risici, handlinger, problemer og beslutninger. Nogle organisationer foretrækker antagelser og afhængigheder i stedet for handlinger og beslutninger, men det kan vi tale om om lidt.

Hovedideen er, at det er risikoregistret, handlingsregistret—alle de registre, du bliver lært at oprette, især hvis du følger en metode fra PMI. Historisk har vi sporet disse ting ved at samle dem i det samme regneark. Det var gammeldags, da jeg begyndte med projektledelse for årtier siden.

Så det har eksisteret for evigt, og det er et uundværligt operationelt værktøj, der hjælper projektledere med at drive deres projekter. I vores undersøgelser har omkring halvdelen til to tredjedele af projektlederne brugt det eller kender til det, og det er et virkelig kritisk værktøj. Derfor evangeliserer vi for det lige nu.

Galen Low: Meget cool. Ja, jeg var en af de mennesker, der faktisk ikke havde indset det, men jeg sad i en session og talte med folk om vores RAID-log. Jeg var blevet lært modellen med risici, antagelser, problemer og afhængigheder. Og hvis nogen rakte hånden op, sagde de: Er du sikker på, at det ikke er denne model? Og så sagde vi: Hvilken foretrækker du, og hvorfor?

Kim Essendrup: Jeg kan godt lide handlinger og beslutninger, for hvis du tænker på en antagelse, så er det en planlægningsantagelse. Jeg skal gennemføre dette projekt. Hvilke antagelser har vi om omfanget, eller hvilke antagelser har vi, når vi udvikler vores plan? En antagelse er noget, der i højere grad fungerer som input i begyndelsen.

En antagelse bliver derfor reelt til en risiko, for hvis din antagelse var ugyldig, skaber det en risiko. Så antagelser falder naturligt ind under R for risiko for mig. Det samme gælder afhængigheder. Hvis du har en afhængighed i dit projekt, en ekstern afhængighed, er det enten en risiko, eller den hører måske hjemme i selve projektplanen, fordi der er tid knyttet til den, måske forgængere og efterfølgere.

Så den ender normalt et af de to steder. Nogle gange er de eksterne afhængigheder så skræmmende, at de fortjener en særlig fane, og i så fald er det vel RAIDD. Men jeg synes, at hvis du holder fokus på handlingspunkterne og beslutningerne, er det mere operationelle ting. Det er de ting, du skal holde øje med under leveringen af dit projekt, og det gør din brug af din RAID-log mere operationel, så du bruger den dagligt til at styre dig selv og holde dig organiseret.

Galen Low: Nej, det kan jeg godt lide. Jeg kan godt lide den fremdrift, og jeg er helt enig med dig. Jeg blev ved med at snuble over tanken om, at alle mine antagelser og afhængigheder faktisk var risici. De var alle sammen formuleret som risici i mine projekter, og jeg tænkte: Jeg ved ikke, om jeg gør det rigtigt.

Kim Essendrup: Ja. Den bedste måde at starte dit risikoregister på er måske netop at begynde med alle de antagelser og afhængigheder, som hele din plan bygger på.

Galen Low: Ja. Og når du afkræfter eller bekræfter nogle af disse antagelser, kan de fjernes med det samme. Det kan jeg godt lide. Vi talte om, hvor vigtig en RAID-log er, og jeg sætter især pris på beslutningsdelen.

At have det hele samlet, især i én log, i stedet for at have otte forskellige dokumenter, som folk skal gennemgå og holde opdaterede og i praksis generelt ikke ser på under projektet.

Kim Essendrup: Ellers skal du søge gennem din Outlook: Åh gud, hvor er den e-mail? Jeg ved, at der var en e-mail her et sted.

Galen Low: Jeg er kongen af Outlook-søgninger, fordi jeg er kongen af slet ikke at organisere min indbakke. Men ja, det giver helt sikkert mening. Noget, vi talte om tidligere, var, at det selvfølgelig handler om risiko, men også om noget, der kan forhindre dit projekt i at ende i katastrofale situationer. Ikke for at få det til at lyde alt for skræmmende, men det hjælper virkelig med at holde tingene på sporet. Kan du fortælle mig, hvordan du ville bruge en RAID-log til det? Altså funktionelt?

Kim Essendrup: Ja, jeg kan godt lide at tænke på den som noget, du bruger til at drive eller redde ethvert projekt. Driftsdelen er virkelig vigtig, for hvis du ikke gør det, ender du sandsynligvis med at skulle redde dit eget projekt.

Hvis du tænker på de værktøjer, du bruger til at styre dine projekter, har du din plan eller din backlog—alle de ting, du gør, alle dine punkter, der direkte bidrager til eller skaber dine leverancer, og det er fantastisk. Det er det, vi gør, ikke? Det er de ting. Men det, en RAID-log bidrager med, er: Hvordan sikrer du, at de ting faktisk bliver gjort rigtigt?

RAID-loggen er ikke planen. Den er måden, du sikrer, at planen bliver gennemført på. Og helt ærligt, hvem har et projekt, der går perfekt? Hvis du har, er du et meget heldigt menneske. Men du får problemer. Du får udfordringer. Ting kan gå galt, og ting går galt.

Hvad bruger du til at håndtere det? Du bruger ikke din tidsplan; du bruger din RAID-log til at identificere, hvor tingene kan gå galt, og hvilke små handlinger du skal holde øje med for at sikre, at du og dit team ikke kommer bagud. Hvilke problemer er opstået, og hvordan løser du dem så hurtigt som muligt, så du kan holde dit projekt så meget på sporet som muligt?

Og hvilke beslutninger skal du forvente og planlægge for, gennemføre og reagere på eller få truffet, som du ikke havde tænkt på i begyndelsen af projektet? Det er alle den slags ting, vi skal håndtere for at holde vores projektplaner på sporet og levere dem succesfuldt.

Når du ikke gør de ting, når du ikke tænker på risiko, planlægger efter den og får beslutninger truffet og dokumenteret, er det dér, planen begynder at falde fra hinanden. Det handler virkelig om at styre det grundlæggende, og det er dér, projekter går galt: når du ikke holder øje med det grundlæggende. For mig er det magien ved en RAID-log. Den er så enkel, men så vigtig for at hjælpe os med at holde styr på det grundlæggende.

Galen Low: Du nævnte, at coaching er en del af din baggrund. Har du nogle historier om netop det, hvor tingene var ved at løbe af sporet, og du tænkte: Det her kan faktisk løses med noget så grundlæggende som en RAID-log?

Kim Essendrup: Ja. For nogle år siden overtog jeg en PMO, der var baseret i Europa, hvilket var fedt, fordi jeg fik firmabetalte rejser til Europa. Men jeg boede stadig i Phoenix-området, så jeg tog derover cirka én gang om måneden, og det var en virkelig spændende organisation.

Men når du overtager rollen som PMO-chef, er du også ansvarlig for alle brandene. Det var fredag. Og når du får et telefonopkald om et projekt på en fredag, er det aldrig et godt opkald. Det var midt på dagen hos mig, sidst på eftermiddagen eller om aftenen i britisk tid.

De sagde, at projektet gik så dårligt, at kunden truede med at opkræve os for problemerne og derefter opsige kontrakten. Så mandag morgen var jeg ikke længere i Phoenix. Jeg var oppe i Midlands i Storbritannien. Og jeg skulle have styr på projektet. Kunden var rasende.

Jeg var der sammen med hele vores team, og de gennemgik alle de problemer, de havde, og alt det, de sagde, tænkte jeg lød legitimt. Jeg ville også være frustreret. Jeg ville også være vred. Så de gennemgik alle deres udfordringer og problemer, og jeg tænkte: Hold da op. Så jeg så over på min side af bordet og sagde: Har I nogen problemer?

De lyste op. Åh gud, kunden gav os ikke dette. I gav os ikke dette. Vi kunne ikke lykkes, fordi I ikke gav os alt det, vi havde brug for for at lykkes. Kunden sagde: Det fortalte I mig ikke. Det vidste jeg ikke. Så jeg sagde: Okay. Jeg så på alle og ventede på, at der blev stille.

Jeg sagde: Okay, kan I vise mig jeres RAID-log? Stilhed. Jeg vidste ikke, om de ikke vidste, hvad en RAID-log var og var for flove til at spørge, eller om de indså: Åh nej, vi har faktisk ikke en RAID-log, så nu er jeg for flov til at sige noget. Så vi sad der, og jeg sagde: Lad os lave en. Jeg åbnede min bærbare computer, og jeg havde en RAID-log klar.

Jeg begyndte at gennemgå den: Okay, lad os registrere alle problemerne. Fortæl mig om dem. Og så fik vi det hele frem. Alle på kundesiden fik lov til at komme af med deres frustrationer. Jeg havde det vist på projektoren, så jeg skrev alt ind. På den måde kunne jeg anerkende hver eneste bekymring og hvert eneste problem. De følte: Okay, nu bliver vi endelig hørt, fordi de kunne se mig skrive det ned.

Så så jeg over på min side af bordet, på mit team, og sagde: Hvad med jer? Hvad er jeres problem? Det var det samme. Jeg dokumenterede det hele. Derefter begyndte vi at se på punkterne og sagde: Det her ligner mange afhængigheder. I forventede dette, og vi vidste ikke, at vi skulle gøre det.

Så begyndte vi—og det er her, jeg vil sige, at afhængigheder nogle gange hører hjemme i RAID-loggen—at dokumentere alle de afhængigheder, hvor vi var afhængige af kunden, og kunden var afhængig af os. Det, der var virkelig godt, var, at i løbet af eftermiddagen holdt vi op med at råbe ad hinanden på hver sin side af konferencebordet. Vi drejede gradvist vores stole.

Vi drejede stolene, og vi så op på projektoren, fordi vi ikke længere kæmpede mod hinanden; vi kæmpede mod problemerne. Lang historie, det ved jeg, men den viser virkelig, hvordan en RAID-log kan bruges til at afhjælpe et problem. Når du går ind i et problem—det har jeg gjort i forbindelse med mange projektvendinger og et par projekter, jeg har skullet involvere mig i—er en simpel ting som en RAID-log en fantastisk platform til at skabe enighed og sikre, at alle forstår hinanden. Den skaber en fælles oversigt over problemer, som vi kan gå sammen om at løse. Og den kan virkelig vende den slags situationer eller i det mindste hjælpe dig med at få kontrol over dem.

Galen Low: Jeg elsker den historie, og jeg elsker også kropssproget. Alle holdt op med at sidde ansigt til ansigt, konfronterende og direkte over for hinanden, og begyndte at hælde mod samarbejde. Ikke?

For jeg tror, at vi altid undervurderer én ting ved alle disse projektledelsesteknikker, taktikker og processer: De skal alle hjælpe kommunikationen med at fungere. De skal alle hjælpe samarbejdet med at fungere. Jeg kunne godt lide det, du sagde tidligere om afhængigheder. Det kan vel gå begge veje.

Hvis du ikke gør dette, kan vi ikke gøre hint. Men på mange måder er det: Du gør dette, så vi kan gøre hint. Hvis folk ikke har synlighed over det, er det svært for dem at forstå, hvorfor de skal gøre noget. Så udskyder de det måske, og ingen siger noget, og pludselig er projektet langt fra der, hvor det skal være.

Nogle gange handler det bare om at have et spor af de ting, vi skal holde øje med. Jeg ved godt, at det kan virke som tung dokumentation, men i sidste ende synes jeg ikke, der er nogen skam i ikke at kunne holde styr på de hundredevis af ting, du sandsynligvis skal holde øje med under projektet.

Ikke? Nå ja, husk den beslutning. Blandt de hundredevis af beslutninger, vi traf i denne uge. Ja. Det er svært at huske det i enhver samtale.

Kim Essendrup: Det er det virkelig. Det er én ting at være til et møde og tale med folk om at træffe en beslutning eller om en afhængighed eller risiko, men når du skriver det i et dokument—særligt hvis det er et delt dokument på Zoom eller en projektor—og skriver det ned, så alle kan se det, og begynder at sætte folks navne ved det, bliver det pludselig til en konkret ting.

Hvis mit navn står på det, begynder jeg pludselig at være opmærksom på det. Så det er også et fantastisk kommunikations- og ansvarlighedsværktøj. Jeg coacher og vejleder mange projektledere, og vi har et fællesskab omkring vores podcast. Noget, vi ofte vender tilbage til, er: Hvis du kommer ind i et nyt miljø og overtager et projekt, så skaf en RAID-log, hvis der ikke allerede er en.

Så kan du begynde at forstå, hvordan du vil gennemføre og styre planen. Et af mine yndlingsudtryk er, især hvis du arbejder på et projekt relateret til offentligt arbejde: Behandl din RAID-log, som om den kan blive genstand for en stævning, for en dag kan det ske. Du kan komme til at ønske, at du havde holdt RAID-loggen opdateret.

Galen Low: Hundrede procent. Ja. Jeg har været på et par projekter, der blev revideret af forskellige årsager. Og ja, hvis den rigtige dokumentation ikke er let tilgængelig, selv om du har dataene et sted, skal du bruge tid på at grave dem frem. Det er et helt projekt i sig selv. Men en ren dokumentationssti over de ting, der skete, hvor der var risici, og hvordan vi talte om risiciene, kan være enormt nyttig.

Kim Essendrup: Jeg kan forestille mig, at det fik dig ud af sengen om morgenen, da du fandt ud af, at du skulle revideres den dag.

Galen Low: Åh gud, ja. Åbn tidsregistreringen, alle sammen.

Jeg synes, du rejste et virkelig godt punkt om det praktiske ved at bruge en RAID-log. Jeg ved, at mange tænker: Det lyder som meget arbejde. Jeg ved, at du viste den på projektoren og fik to teams til at tale sammen, men hvordan ser det ud faktisk at holde den som den fælles sandhed efter det øjeblik, hvor I nåede til enighed?

Kim Essendrup: Jeg tror virkelig, at projektlederen skal leve den. Du kan se på den og sige: Det er godt nok meget mere sporing og styring, jeg skal lave.

Og helt ærligt, det er det også. Du kan vælge ikke at lave en RAID-log og håbe, at du klarer dig, ligesom når du kører over for gult lys. Du kan lukke øjnene, træde på speederen og håbe, at du ikke kører galt. Og det kan lykkes mange gange. Men blandt de fejlslagne projekter, jeg har skullet redde, er svaret altid nej, når jeg spørger: Kan du vise mig din RAID-log?

Jeg ved personligt, at når jeg har haft projekter, der begynder at komme ud af kurs, tænker jeg: Åh gud, vi er på vej i grøften. Og så opdager jeg: Åh nej, jeg har ikke holdt min RAID-log ajour, eller jeg har slet ikke lavet en RAID-log for dette projekt.

Når man har gennemgået den smerte nok gange, indser man, at det nok er nødvendigt. Hvis vi træder et skridt tilbage og ser på det fra et større perspektiv, har mange analytikere undersøgt fejlrater og succesrater for projekter.

Statistikkerne varierer fra år til år og fra undersøgelse til undersøgelse, men man ser konsekvent, at omkring 70-80 % af projekter ikke når deres vigtigste mål. Et sted omkring 19-20 % fejler helt. Og det ved vi alle sammen, ikke? Vi er projektledere.

Vi gør det her. Vi ved, at der opstår problemer, ting bliver udskudt, eller at noget kommer til at koste mere end forventet. Hvis du ved, at sandsynligheden for, at der opstår et problem i dit projekt, er høj, gør du så dig selv og dit projekt en bjørnetjeneste ved ikke at bruge lidt tid på at forsøge at undgå det?

Det er jo vores arbejde, ikke? Vi er projektledere. Vi er heltene, der får det her til at lykkes. Så det her er vores superheltevåben, som vi skal bruge til at holde projekterne på sporet. Det er det, vi gør.

Galen Low: Jeg synes også, statistikkerne er sjove, ikke? For det føles, som om det gælder begge veje, uanset hvor man ser hen, ikke kun inden for projektledelse. Man siger: Én ud af tre personer får denne ting. Og så tænker man: Ikke mig. Og når det sker for en selv, tænker man: Det skulle jo ske, for én ud af tre personer—uden rigtig at tænke over, at det giver os en mulighed for ikke at tage det op direkte og være proaktive.

Som du sagde, kan vi bare lukke øjnene og køre hurtigt gennem et gult lys. På den anden side kan man blive fuldstændig lammet af det, fordi man tænker: Mit projekt kommer sikkert til at fejle, siger statistikken. Men det, du beskrev tidligere, minder faktisk om at tage tøjlerne.

Du har en plan, fint, det er som et kort med en linje tegnet på. Men det faktiske rat, som styrer projektet fremad og sikrer, at det ikke triller ned i en grøft, er ting som en RAID-log. Og jeg elsker, at den er samlet og tydelig.

Folk kan se på den og samarbejde om den i et mødelokale, og det synes jeg er fantastisk. Men det får mig faktisk til at tænke på noget, du sagde tidligere: For både dig og mig har min RAID-log altid været et regneark. Og mange siger: Jeg har bare ikke brug for endnu et regneark.

Vi har ikke brug for endnu en ting. Hvilke værktøjer findes der til at håndtere en RAID-log i et projekt, som ikke nødvendigvis er Excel eller Google Sheets?

Kim Essendrup: Det er sjovt. Der findes selvfølgelig mange projektstyringsværktøjer på markedet. Hos Kolme Group, hvor jeg havde min PPM-konsulentvirksomhed, har vores team implementeret projektstyringsværktøjer i over 650 organisationer.

Det er virkelig fedt at have startet en konsulentvirksomhed, der har kunnet udføre den slags fantastiske arbejde på tværs af virksomheder i forskellige størrelser og brancher. Men det interessante er, at vi implementerer en række værktøjer, og vi har fundet ud af, at værktøjerne derude virkelig ikke håndterer RAID-logge særlig godt.

Mange værktøjer gør ikke engang noget, der minder om det. De lader, som om de ikke kan. Og det er helt fint. De er bare gode til at være den ultimative software til opgavestyring. Eller de handler om virksomhedsressourceplanlægning, prognoser og ressourcestyring. Det er værdifulde anvendelsesområder, som organisationer er nødt til at have for at fungere ordentligt.

Men vi har set, at værktøjerne enten er målrettet ledelsens perspektiv, så de giver dem overblik og hjælper dem med planlægning på virksomheds- eller porteføljeniveau, eller også går de i den modsatte retning, hvor værktøjet bliver meget forenklet og primært er rettet mod teamet, med fokus på brugeren og uden meget styring eller opsætning.

Det er meget enkelt: Her er min opgave, her er mine Kanban-tavler, spor min hastighed. Det er grundlæggende ting, som man gør på teamniveau, eller som en scrum master gør. Men når værktøjerne skubbes op eller ned, bliver projektlederen udeladt.

Hvilke værktøjer derude er specifikt designet til at gøre projektlederens liv lettere? Ikke mange. Gennem vores implementeringer fandt vi et hul, hvor nogle værktøjer kunne håndtere lidt RAID—måske nogle risici eller problemer—eller hvor man kunne hacke noget sammen.

Jeg kan lave en Kanban-tavle med risici og problemer. Det kan man godt, men man mister meget af enkelheden og noget af den værdi, man får fra en grundlæggende RAID-log. Derfor talte vi med nogle af vores softwarepartnere og sagde: I burde lave vores RAID-log.

De sagde alle: Ved du hvad, Kim? RAID-logge findes ikke i Gartners magiske kvadrant, så det kommer ikke til at ske. Jeg tænkte: Nå, okay. Vi prøvede at få dem til at gøre det, men de ville ikke. Så til sidst sagde vi: Fint, så gør vi det selv, for vi er trætte af regneark.

Regneark fungerer, men de er de samme, som de altid har været, og de har begrænsninger. Det kan være svært at dele dem. Det kan være svært at holde styr på versioner og samarbejde. Hvis du vil spore alle de hændelser, der fandt sted omkring en bestemt risiko, ender du med at skulle rulle langt ned.

Det er svært at styre, og du får selvfølgelig ikke al den værdi ud af et værktøj, som du burde. Derfor skabte vi en SaaS-baseret RAID-log, raidlog.com. Nem at huske. Vi er stadig i de tidlige faser, men vores mission er at skabe det ultimative værktøj, der hjælper projektledere med at lykkes.

De er superheltene. Det er dem, der hvert år har ansvaret for 1,7 billioner dollars i kapitaludgifter i USA. Så lad os styrke dem, så de kan lykkes.

Galen Low: Jeg elsker det. Jeg synes, der er noget fascinerende ved det, du sagde tidligere om, at software faktisk bevæger sig i to forskellige retninger.

Virksomhedsperspektivet og så teamet, der bare forsøger at få ting gjort. Enkelt, nemt at bruge, kort indlæringskurve. Det hele stammer sandsynligvis oprindeligt fra koncepter som Microsoft Project. Og alligevel er det projektlederen, der bliver efterladt. Jeg ved, at nogle værktøjer er bedre end andre.

Der er et par værktøjer, jeg bruger, hvor jeg tænker: Ja, de har lavet denne software på den måde, min hjerne fungerer på. Statusopdateringer og den slags, ikke? At følge op på opgaver, påmindelser og så videre. Men da jeg tænkte over det, indså jeg, at jeg med min begrænsede erfaring med projektstyringssoftware aldrig har fundet en RAID-funktion i et af dem, så det fascinerer mig.

Kan du fortælle lidt om, hvordan det fungerer? Integreres det i software? Fungerer det selvstændigt?

Kim Essendrup: Ja, det er selvstændig software. Den har din RAID-log, og brugerfladen ligner et regneark. Du får altså den grænseflade. Den er hurtig, nem og effektiv. Hvis du er vant til RAID-logge, vil den ikke sænke dig.

Du bliver ikke tvunget til at klikke, tab, tab, tab. Men vi har også en mere visuel brugerflade, som er meget mere intuitiv, hvis du er ny i forhold til RAID-logge, eller hvis du vil sige: Jeg har dette kritiske problem, som jeg skal dele med en leder. Jeg vil ikke fremhæve og vise én række i mit risikoregister, for det er lidt sværere at demonstrere, hvad der foregår.

De mere visuelle komponenter lader dig åbne en detaljeret visning af dit problem eller din beslutning og vise den på en måde, der gør det muligt at have en forretningssamtale. Forestil dig det med dine interessenter og din sponsor. Vi tilføjer flere brugervenlige funktioner, som hjælper dig gennem de forskellige processer.

Hvis du for eksempel kender en T-graf, laver du en lille T-graf, når du skal træffe en beslutning, og siger: Her er fordelene, her er ulemperne, og her er muligheden. Det har vi bygget ind i vores beslutningsmodul. Det kan man ikke gøre særlig nemt i et regneark, så vi tænkte, at det burde vi gøre. Vi tilføjer også varmekort og alle de andre ting, som man nok burde bruge, men som man ikke rigtig kan lave effektivt på egen hånd, såsom Monte Carlo-analyse eller avancerede analyser.

Senere får vi også AI-drevne funktioner. Det bliver altså en selvstændig RAID-log. Men RAID-loggen er selvfølgelig ikke det eneste værktøj, du bruger til at styre et projekt. Derfor bygger vi integrationer. Vi har allerede en med Planview Adaptive Work. Vi kommer til at lave en med Jira og integrere med så mange værktøjer som muligt.

Vi er faktisk koblet til Zapier, hvis du kender Zapier, som kan forbindes med stort set alt i verden. Vores vision er derfor at gøre den regnearksbaserede RAID-log forældet, fordi vi vil have en bedre løsning, som alle kan bruge. Vi får en meget stærk gratis version.

Hvis du bare vil have noget, der er nemt at bruge, en enkel og grundlæggende RAID-log, vil vi tilbyde det. Og hvis du er superbruger, vil vi også have avancerede funktioner til dig.

Galen Low: Ved du, hvad jeg bedst kan lide ved det? I mit hoved går det langt videre end en log. For mig er en log at registrere noget, der er sket eller måske vil ske. Det er bare en note. Sådan har mine RAID-logge normalt set ud: Okay, vi skal tale om denne ting. Men du har faktisk dybden med. Du kan lave analysen, du kan lave T-grafen.

Det er faktisk mere RAID-styring end en RAID-log.

Kim Essendrup: Det er endnu mere end det. Vi kalder det raidlog.com, fordi det er det, vi kender som det vigtigste operationelle værktøj. Men RAID-logge har ikke rigtig udviklet sig meget i de seneste årtier, fordi vi er begrænset af det værktøj, vi har.

Vores vision er at hjælpe projektledere og give dem de ultimative værktøjer, de har brug for til at drive et projekt. Så vi stopper ikke med RAID-elementer. Vi vil også indarbejde erfaringer og andre ting. Vi vil indarbejde mødereferater, så du kan skrive referatet og opdatere din RAID-log samtidig og spare dig selv for mange timers arbejde hver uge.

Målet er at være det foretrukne værktøj, og uanset hvilket planlægningsværktøj eller backlogværktøj du bruger, kobler vi os på som en tilføjelse. Det er vores vision for RAID-loggen. Vi vil fjerne smerten ved projektledelse.

Galen Low: Jeg elsker det. Jeg elsker, at det integreres med andre løsninger, og at det er åbent.

Du har dine Zapier-integrationer. Hent det ind, send det ud. Det er næsten som at gå direkte til risikoanalyse, risikostyring og beslutningsstyring. Grundlæggende er det det samarbejdslag, der nogle gange mangler, når man befinder sig på virksomhedsniveau eller helt nede på jorden.

Kim Essendrup: Ja, og på grund af al træningen og coachingen vil vi være mere end bare et værktøj. Jeg vil ikke bare sige: Her er et værktøj, værsgo. Vi vil bygge viden, træning og uddannelse ind i det. Hvis du er ny inden for risikostyring, skal det være intuitivt nok til, at du kan gå ind og sige: Hvad gør jeg her?

Hvad gør dette? Hvad betyder sandsynlighed og konsekvens? Vi vil have kontekstbaseret hjælp, men også mere avancerede funktioner. Jeg nævnte Monte Carlo-analyse, men vi får også forventet monetær værdi og alle de ting, du har hørt om eller måske set, men aldrig rigtig brugt.

For hvordan skulle du sætte det op i dit regneark? Du gider nok ikke besværet. Vi gør alt arbejdet for dig. Du kan sige: Jeg spekulerer på, om jeg kan beregne en reserve. Hvad siger systemet, at jeg bør planlægge efter? Så indtaster du dataene, klikker på en knap, og så har du svaret.

Galen Low: Jeg elsker det. Jeg har bygget flere risikoregistre fra bunden, og det kræver mange formler. Jeg ville ønske, jeg ikke skulle gøre det.

Kim Essendrup: Det gør det. På et tidspunkt tænker du: Ved du hvad? Det her er godt nok. Nu skal jeg bare have tingene til at fungere. Jeg har et projekt, der skal gennemføres. Jeg kan ikke sidde og lege med det her.

Galen Low: Kald det bare en reserve på 15 %. Lad os komme videre.

Sidste spørgsmål til dig. Jeg vil vende tilbage til noget, du sagde: På nogle måder mangler nogle værktøjer projektlederens ting, altså RAID-elementerne. Men på den anden side: Er RAID kun for projektledere?

Og hvis ikke, hvordan kan alle bruge det til at begynde at opbygge en teamkultur, hvor der er ansvar for risici, handlinger, problemer og afhængigheder, så det bliver mere en holdsport?

Kim Essendrup: Det er et godt spørgsmål. RAID udspringer selvfølgelig af et esoterisk projektstyringsværktøj, som gamle projektledere brugte og lærte på den måde, men.

Det handler egentlig om, hvordan du får din plan gennemført. Og planen behøver ikke nødvendigvis være et projekt i den gamle vandfaldsdefinition. Det kan være agilt, et produkt, eller at du er produktejer. Du har et produkt, der skal udvikles som produktejer i en agil verden.

Hvordan styrer jeg risiciene for mit produkt? Hvilke beslutninger skal træffes? Når en beslutning er truffet, eller nogen træffer en beslutning for mig, skal jeg dokumentere og spore den på en eller anden måde. Så det passer også ind i den verden. Hvis jeg er scrum master, driver jeg et team, og vi arbejder agilt. Hvordan passer jeg på mit team og sikrer, at det kan være effektivt?

RAID-loggen handler altså ikke så meget om produktet, men om teamet. Hvordan får jeg teamet til at lykkes, og hvordan hjælper jeg med at støtte det? Hvis vi går tilbage til projektledelsesverdenen, og jeg er PMO-chef og vil vejlede mine projektledere, hvad er så en bedre måde at sige: Vis mig din RAID-log.

Lad os se, hvordan du styrer dine projekter, for jeg kan se, hvad du gør, og måske komme med forslag eller i det mindste sikre, at du gør noget for at styre dine projekter. Fra projektlederens perspektiv kan man også styre opad i organisationen.

Hvis jeg har brug for tid med min PMO-chef, mine sponsorer eller interessenter, tager jeg min RAID-log og filtrerer den. Jeg viser dem ikke hele listen. Det er for meget. Jeg filtrerer den ned til de tre eller fire vigtigste ting, jeg skal have dem til at tage sig af. Så kan jeg sige: Lad os tale om dette. Det viser, at du har styr på tingene, og det hjælper med at engagere de mennesker.

Jeg synes derfor, at det er meget mere end et operationelt projektværktøj. Det er en måde at arbejde på og en måde at samarbejde på. Ikke bare en måde for mig at holde mig organiseret på, men en måde at holde mit team organiseret og motiveret på samt kommunikere og samarbejde med dem.

Galen Low: Jeg elsker virkelig alle de pointer. Og der er ikke mange mennesker, der ikke arbejder med risici, handlinger, problemer eller beslutninger i det, de laver.

Det kan være ethvert samarbejdsværktøj. Jeg er glad for, at du nævnte filtreringen, for som projektledere opbygger vi en større kapacitet til at håndtere enorme mængder information. Og så siger vi: Se mine Gantt-diagrammer. Alle andre siger: Nej.

Gå væk fra mig. Gå væk fra mig. Vi er nødt til at gøre det mindre. Og jeg synes, det er afgørende for RAID-logge, som du sagde tidligere: Du skal få det ind i et format, hvor du kan præsentere det og have en samtale om det med en forretningsinteressent, ikke nødvendigvis en anden projektleder. Du kan bruge det til at styre et team af projektledere.

Du kan bruge det til at styre forventningerne hos dine overordnede. Det er bare en fin—jeg ville sige besked i en flaske, men det er det ikke helt—det er en fælles sandhed. Hvis du arbejder disciplineret med den, kan den bruges til mange forskellige ting og få tingene til at glide meget bedre.

Kim Essendrup: Det kan den virkelig. Og som jeg sagde, er RAID kun begyndelsen. Vi ser ofte, at den udvides med for eksempel erfaringer. Det er forfærdeligt at have problemer, men det er endnu værre at have det samme problem igen og igen. Du kan udvide din RAID-log ved at tilføje ting som erfaringer, der kan hjælpe med at løse dem og gøre livet lettere næste gang.

Galen Low: Jeg elsker det, og jeg er også spændt på AI-delen.

Jeg synes, det her er virkelig fascinerende. Hvor kan folk finde mere information om RAID-log?

Kim Essendrup: På raidlog.com. Et domæne, der er nemt at huske. Jeg vil også meget gerne have folk til at prøve produktet. Vi leder efter feedback, fordi vi vil gøre det til et fantastisk værktøj for projektledere. Vi vil gerne engagere os med projektledere, og jeg vil gerne høre fra jer. I kan kontakte mig på LinkedIn.

Jeg elsker at tale med alle. Hvis du har feedback om produktet eller podcasten, eller hvis du bare vil nørde projektledelse, vil jeg meget gerne gøre det. Og hvis du er helt ny inden for RAID-logge og tænker: Hvad handler det her om? Så skrev jeg faktisk en bog, fordi der mærkeligt nok ikke fandtes nogen bog om RAID-logge. Jeg tænkte: Det må jeg lave om på. Hvis du går på Amazon og søger efter "Ultimate Guide to RAID Log", finder du min bog, fordi jeg tror, det er den eneste bog om RAID-logge.

Galen Low: Det er utroligt. Det anede jeg ikke. Det er fantastisk. Jeg inkluderer alle de links i shownoterne til lytterne. Og jeg vil også selv gå ind og se på det, for jeg synes, det er fascinerende. Det var aldrig faldet mig ind. Jeg tænkte: Ja, det er et regneark, ikke? Så jeg vil helt sikkert undersøge det.

Kim Essendrup: Fantastisk.

Galen Low: Fantastisk. Kim, tusind tak, fordi du var med i dag. Jeg sætter virkelig pris på dine indsigter. Jeg elsker altid at nørde projektledelse, især sådan nogle ting, ikke? Projektledelsens gamle lærdom, RAID-logge, risikoregistre og alle de ting, der næsten virker uigennemtrængelige. Men når vi begynder at tale om dem, er de faktisk meget grundlæggende og meget fornuftige ting at have.

Så jeg sætter virkelig pris på dit perspektiv. Det var fantastisk.

Kim Essendrup: Tak, fordi du havde mig med, Galen.

Galen Low: Okay, folkens, så har I det hele. Som altid: Hvis du vil deltage i samtalen med over tusind ligesindede fortalere for projektledelse, så kom med i vores fællesskab. Gå til thedigitalprojectmanager.com/membership for at få mere at vide.

Og hvis du kunne lide det, du hørte i dag, så abonnér, og hold kontakten på thedigitalprojectmanager.com. Indtil næste gang: Tak fordi du lyttede.