Stop med at pege fingre – brug et RACI-skema (med Suze Haworth)

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da robotten ikke er korrekt 100 % af tiden.

Ben Aston:

Noget af det vanskeligste ved at lede projekter er måske, at vi er nødt til at arbejde med … ja, mennesker, og mennesker er utroligt forskellige. Vi er inkonsekvente, egoistiske, upålidelige og utroligt omskiftelige, og jeg taler bare om mig selv. Så jeg spekulerer på, om dine projekter minder om mine. Når de går galt, og det gør de selvfølgelig også på et tidspunkt, kan det hurtigt udvikle sig til en forfærdelig omgang fingerpegen, hvor alle tilsyneladende beskylder alle andre for ikke at udføre deres arbejde ordentligt. Så hvordan i alverden kan vi styre et projekt, når vi skal håndtere alt det? Det finder du ud af i dag.

Tak fordi du lytter med. Jeg hedder Ben Aston, og dette er podcasten Digital Project Manager. Denne podcast er sponsoreret af Clarizen, førende inden for software til virksomhedsprojekt- og porteføljestyring. Besøg Clarizen.com for at få mere at vide. I dag har jeg selskab af Suze Haworth, som er en af vores faste DPM-eksperter hos Digital Project Manager. Suze, mange tak fordi du vil være med.

Suze Haworth:

Tak, Ben, og tak fordi jeg måtte komme.

Ben Aston:

Lad mig præsentere Suze ordentligt, for hun er ny. Det er, tror jeg, vores allerførste podcast sammen.

Suze Haworth:

Ja.

Ben Aston:

Suze er freelance digital projektdirektør i London, og hun har masser af erfaring. Hun har været i branchen i over 13 år, begyndte inden for account management ligesom jeg og gik derefter over til projektledelse. Men i stedet for bare at læse op fra din biografi, Suze, kan du så fortælle os lidt om, hvilke typer projekter du arbejder på lige nu?

Suze Haworth:

Lige nu? Altså, sidste år gik jeg faktisk freelance, så jeg har, som du siger, arbejdet i en række år hos forskellige bureauer, men sidste år blev jeg freelancer. I øjeblikket har jeg en rolle hos et bureau i London, hvor jeg arbejder på to store projekter. Det ene er et designsystem for et forholdsvis stort detailhandelsbrand, og på det andet leder jeg et arbejdsprogram for et andet detailhandelsbrand. Det er alt sammen ret interessant arbejde.

Ben Aston:

Er detailhandel så dit område?

Suze Haworth:

Det er faktisk lidt af hvert. Jeg har meget detailhandel, en broadcaster, velgørenhed og alle mulige andre ting, men ja, der er et ret stærkt fokus på detailhandel i de konti, jeg nævnte, lige nu, så det kan man godt sige.

Ben Aston:

Fedt. I din rolle som freelancer, hvad synes du så er sværest? Hvilke større udfordringer arbejder du med lige nu?

Suze Haworth:

Jeg tror nok, at den største udfordring – og sådan er det altid for projektledere, tror jeg, hvis jeg taler ud fra min erfaring – er, at man har så mange forskellige ting, man skal styre og udføre, og som man er ansvarlig for. Man forsøger ikke bare at levere et projekt succesfuldt; man styrer også tidsplaner, budget, teamets resultater, de enkelte teammedlemmer og en masse forskellige teamproblemer. Og så er der selvfølgelig også kontakten med kunden. Det er virkelig svært at jonglere med så mange ting inden for den tid, man har. Jeg føler ofte, at det er en konstant kamp at få alt presset ind på én dag.

Ben Aston:

Ja. Synes du, det er sværere, fordi du tidligere var fastansat og nu er i en slags konsulentrolle? Føles det anderledes, eller hvordan fungerer det for dig?

Suze Haworth:

Ja, det er lidt anderledes, i den forstand at man som freelancer i højere grad selv er ansvarlig for sin tid, blandt andet for den tid, man fakturerer bureauet. Man kan ikke ende i en situation, hvor man føler, at man ikke kan sige nej til ting. Jeg tror, det er noget, jeg er blevet bedre til: Hvis der er for meget på ens tallerken, kan man kun nå en vis mængde, og man er nødt til at gøre det ordentligt. Så i stedet for bare at sige ja til alt, er det bedst at sætte nogle grænser, så man kan sige nej til flere opgaver.

Ben Aston:

Ja. Da jeg var konsulent, oplevede jeg det samme. Der er faktisk noget rigtig rart ved at være konsulent, fordi man ikke forsøger at få en forfremmelse. Man vil selvfølgelig gerne beholde sin kontrakt og fortsætte samarbejdet, men man forsøger ikke at imponere folk på helt samme måde, som når man er fastansat og tænker: “Jeg må hellere sige ja, ellers ser det dårligt ud.”

Suze Haworth:

Ja, præcis. Man vil selvfølgelig stadig gerne gøre et godt indtryk. Branchen er lille, så alle kender alle, men jeg synes, det er rart at kunne træde lidt tilbage sidst på dagen og sige: “Okay, mine timer er gået,” i lidt højere grad end som fastansat.

Ben Aston:

Hvor mange forskellige steder har du arbejdet, siden du begyndte som konsulent?

Suze Haworth:

Kun et par stykker indtil videre, faktisk, fordi jeg ikke har gjort det så længe. Det har på en måde været godt, fordi jeg faktisk har opbygget en del tid hos det bureau, jeg er hos nu, så jeg kender folk ret godt. Jeg kender kunderne bedre, fordi man får lidt mere tid på projekterne og kontiene.

Ben Aston:

Arbejder du internt, eller arbejder du primært på afstand?

Suze Haworth:

Nej, internt. Jeg fremhæver faktisk fordelene ved fjernarbejde over for alle, jeg taler med om det, fordi jeg synes, det er virkelig vigtigt og kan gøre mange mennesker langt mere produktive. Men jeg oplever, at mange bureauer, især i London, hvor jeg har arbejdet en del, primært arbejder internt.

Ben Aston:

Interessant. Jeg ved, at du ud over at være freelancer og arbejde på kontrakt også skriver. Du har skrevet ting for DPM, og senere på året skal du også være med på DPM Summit. Kan du fortælle lidt om det?

Suze Haworth:

Ja, det kan jeg. Jeg glæder mig virkelig meget. Sidste år talte jeg på DPM Summit i Las Vegas, og i år afholder jeg faktisk en workshop. Det er et ret interessant emne, for som projektledere er vi vist alle ret optagede af metoder, især agile-metoder. På workshoppen taler jeg om at kombinere tilgange, nærmere bestemt en tilgang, jeg har implementeret i et arbejdsprogram, jeg arbejder på nu: Dual-Track-tilgangen. Den bruger nogle aspekter fra agile, men kombinerer dem på en lidt anderledes måde. Jeg taler om det, Kanban, Lean og om, hvordan man kan kombinere forskellige tilgange i sine projekter – altså ikke nødvendigvis ren agile eller én enkelt ren metode, men om at tilpasse de eksisterende metoder.

Ben Aston:

Ja, det er fedt. Og jeg synes også, det er så vigtigt. Suze er faktisk en af vores DPM-eksperter, og hun medvirker på vores kursus i digital projektledelse. Hvis du ikke ved, hvad jeg-

Suze Haworth:

Ja, det gør jeg.

Ben Aston:

Det finder faktisk sted på fredag, så det er Suzies første optræden. Noget af det, vi taler om på kurset, er, at man ikke skal hænge sig for meget i metodens navn eller i, hvad-

Suze Haworth:

Ja, præcis.

Ben Aston:

Det handler i sidste ende om at levere arbejdet og finde bedre måder at gøre det på, på en måde der fungerer for teamet, projektet og kunden – og om at være pragmatisk i stedet for dogmatisk. Det handler ikke om at sige: “Det her er ikke Scrum, så vi er nødt til at gøre det som Scrum.” Det betyder ærligt talt ikke så meget. Vi skal bare levere projektet.

Suze Haworth:

Præcis. Jeg har altid oplevet, at man bliver så optaget af processen og af at følge en bestemt proces, men man er faktisk nødt til at se på projektet eller det produkt, man skaber, og spørge: “Hvad fungerer for dette?” Det er så forskelligt fra projekt til projekt, så man må tilpasse eller kombinere.

Ben Aston:

Ja, helt sikkert. Nogle mennesker kan være lidt nedladende over for at udvande metodernes renhed, men jeg har aldrig oplevet, at de fungerede på den måde.

Suze Haworth:

Nej, præcis. Jeg ved, at der er meget snobberi omkring foretrukne tilgange, men jeg er ret åben over for at bruge dem. I de fleste tilfælde, især i bureauverdenen, er man nødt til at bruge en kombineret proces frem for noget rent, simpelthen på grund af de situationer, man befinder sig i.

Ben Aston:

Ja, bestemt. Ud over din konference, dine artikler og dit arbejde – er der så noget, du har sat som mål for dig selv i år, noget du arbejder på eller forsøger at blive bedre til?

Suze Haworth:

Åh gud, det er et svært spørgsmål. Lige nu er jeg så fokuseret på nuet og på det, jeg laver både på og uden for arbejdet, at det nogle gange er svært at tænke på den langsigtede fremtid. Men én vigtig ting, som jeg nævnte tidligere, er at lære at sige nej. Jeg forsøger at blive meget bedre til at uddelegere og faktisk give lidt slip på ansvaret, hvilket altid har været svært for mig. Som projektleder bliver man let lidt af en kontrolfreak, så det er bestemt et langsigtet mål for mig.

Ben Aston:

Ja, delegering er svært. Især når man er konsulent og ikke rigtig ved, om den person, man delegerer til, vil tage en alvorligt, fordi man bare er konsulent, eller om man har nogen historik med personen, så man ikke ved, om vedkommende faktisk kan gøre det, man forsøger at delegere.

Suze Haworth:

Præcis.

Ben Aston:

Lad os tale lidt om værktøjer, for når man arbejder forskellige steder, bliver man naturligvis eksponeret for forskellige ting. Har du fundet noget for nylig, der gør dit liv fantastisk, eller noget hvor du tænker: “Det her bør alle kende”?

Suze Haworth:

For at være ærlig får man som freelancer, og når man har arbejdet i mange forskellige bureauer gennem årene – også i faste stillinger – indblik i så mange forskellige værktøjer, og man er som regel nødt til at bruge det, virksomheden bruger. Derfor vil jeg aldrig sige, at jeg har fundet det ideelle eller perfekte værktøj, der kan alt det, jeg gerne vil have, uden vanskeligheder eller problemer, som man skal håndtere. Så jeg vil nok ikke sige, at der er ét ideelt værktøj, jeg bruger. Ressourcestyringsværktøjer og værktøjer til timesedler – jeg har brugt en enorm række, og som sagt har jeg fundet gode og dårlige ting ved dem alle. Det eneste værktøj, hvis man kan kalde det et værktøj, som jeg virkelig elsker, er Google-regneark. Det skyldes, at man kan bruge dem til alt muligt eller i hvert fald til rigtig mange forskellige ting.

Ben Aston:

Har du prøvet Monday.com?

Suze Haworth:

Nej, det har jeg faktisk ikke.

Ben Aston:

For en, der godt kan lide at styre ting med regneark, tror jeg, at Monday måske lige er-

Suze Haworth:

Sikke en nørd.

Ben Aston:

Det gode ved regneark er jo, at de er gratis – eller Google Sheets er i hvert fald – og at de kan være utroligt fleksible. Men jeg synes, Monday tilføjer et ekstra lag af automatisering samt større styrke i filtrering og kontrol. Du burde prøve det. Måske vil det … Det er som regneark på steroider.

Suze Haworth:

Så vil jeg bestemt kigge på det. Det lyder lige som noget for mig.

Ben Aston:

Fedt. Lad os tale om din artikel. Det er et stykke tid siden, du skrev den, men hvis vi går tilbage til udgangspunktet: Hvordan håndterer vi mennesker, der enten ser ud til at ville overtage et projekt eller slet ikke vil tage noget ansvar? Suzies artikel handler om, hvordan vi kan bruge et RACI-skema til netop det. For dem, der endnu ikke har læst artiklen, kan du så fortælle os om RACI-skemaer? Hvad betyder “RACI”?

Suze Haworth:

RACI står for ansvarlig, ansvarshavende, hørt og informeret. Det er grundlæggende et skema, hvor man kortlægger opgaver eller leverancer for et projekt i forhold til projektets interessenter eller interne teammedlemmer, og tildeler ét af de fire bogstaver til hver rolle og hver opgave. Det betyder, at nogen er ansvarlig, nogen har det endelige ansvar, nogen høres i projektet, og nogen informeres. Det er en god måde at placere ansvaret for hver opgave eller leverance på, sikre at for mange mennesker ikke deltager i alle beslutninger, og skabe et klart billede af, hvem der arbejder på hvad gennem hele projektet.

Ben Aston:

En af de ting, folk typisk er mest forvirrede over, handler ikke om, hvem der skal informeres eller høres. Det plejer at være ret ligetil. Forvirringen opstår mellem, hvad det betyder at være ansvarlig, og hvad det betyder at have det endelige ansvar. Hvordan håndterer du det – og hvordan håndterer du mennesker, der gerne vil være ansvarlige, men ikke vil have det endelige ansvar?

Suze Haworth:

Det er faktisk det vanskeligste område i RACI-modellen, og noget jeg selv har kæmpet meget med tidligere. Derfor kan et RACI-skema ende med at blive et stort arbejde at udarbejde, fordi man bruger så lang tid på at overveje, hvad det egentlig betyder, og hvad det betyder for den person, der får rollen. Men helt enkelt kan man se den ansvarlige som den person, der rent faktisk udfører opgaven, for eksempel skaber en leverance eller driver den igennem. Det er altså den person, der gør arbejdet. Den ansvarshavende er den person, der er ansvarlig for at godkende opgaven og føre tilsyn med den, men som ikke selv udfører opgaven.
En anden udfordring med ansvarlig og ansvarshavende er, at man let kan have en tendens til at tildele det endelige ansvar til projektlederen eller produktejeren, fordi de leder projektet og er det centrale omdrejningspunkt. Men man skal faktisk forsøge at adskille projektlederen fra ansvaret for alt og overveje, hvem der reelt er mere senior i forhold til den pågældende opgave eller leverance. Hvis det handler om design, er det så en kreativ direktør? Er det en kreativ direktør hos jer eller hos kunden? Man skal forsøge ikke altid at lægge rollen som ansvarshavende på projektlederen eller produktejeren.

Ben Aston:

Det er vigtigt, ikke? For en fejl, vi let kan begå, er at gøre alle ansvarlige og alle ansvarshavende. Ikke kun projektlederen, men alle. Man tænker: “Alle skal være ansvarlige for det her. Vi har brug for et fælles ansvar eller et fælles endeligt ansvar.”

Suze Haworth:

Ja, netop. Det er svært, fordi man tænker, at teammedlemmerne også kommer til at udføre opgaven, så måske er der fem personer, der laver den, og derfor er de alle ansvarlige. Men man er nødt til at strømline det og indsnævre det, for hvis man spreder rollerne ud over alle, opnår man aldrig det, RACI-modellen er bedst til: at definere et enkelt kontaktpunkt eller nogle få kontakt- eller godkendelsespunkter tydeligt. Det er det, RACI skal bruges til, så det handler om at bruge den rigtigt.

Ben Aston:

Det, der er nyttigt, er, at det normalt ikke er kompliceret at finde ud af, hvem der er ansvarlig og rent faktisk udfører arbejdet. Men det kan være svært at skelne mellem hørt og informeret. Jeg tror, folk især forveksler ansvarshavende og hørt. Som du siger, vil vi som regel bare have én person, der har det endelige ansvar og afgør, om resultatet rammer plet. Det er lidt som kvalitetskontrol. Vi kan have flere personer, der høres, og endnu flere, der informeres. De får bare beskeden: “Hej, det her er det, vi nåede frem til.”
Men de personer, der høres, kan efter min mening faktisk afspore projektet, fordi de har en stemme og indflydelse. De er ikke nødvendigvis ansvarlige for at levere til tiden eller levere det rigtige, men de har bestemt en stemme. De største spændinger opstår derfor mellem den ansvarshavende og de personer, der høres – og i magtkampen mellem mennesker, der vil håndhæve deres position, autoritet eller mening, men som ikke i sidste ende er ansvarlige for, at leverancen bliver rigtig eller leveret ordentligt.

Suze Haworth:

Ja, og en anden spænding er, at de personer, der høres, naturligvis vil føle, at de skal have en stemme, fordi man har fortalt dem, at de skal høres. Derfor er rollen som ansvarshavende så vigtig. Den person skal eje leverancen eller opgaven og sikre, at de personer, der høres, bidrager uden at afspore hele projektet med lange rækker af feedback eller hvad det nu er, de skal høres om.

Ben Aston:

Men helt ærligt, når det gælder et RACI-skema: Du har givet et godt eksempel på, hvordan “Ringenes Herre” kunne se ud som et RACI-skema. Er det dokumentation, du bruger i alle projekter, og hvordan holder du det enkelt? Hvis man går ned på mange detaljeringsniveauer, kan det tage evigheder at udarbejde, så hvordan undgår man, at det bare bliver endnu en arbejdsnedbrydningsstruktur med folks navne ved siden af?

Suze Haworth:

Jeg er meget optaget af ikke at skabe for meget dokumentation bare for dokumentationens skyld. Jeg vil ikke indføre eller foreslå dokumentation, som i sidste ende ikke bliver brugt. Men hvis man laver et RACI-skema, skal man gøre det nyttigt og faktisk bruge det. Man skal ikke bare oprette det i begyndelsen af projektet og derefter lade det dø på en server. Man skal henvise til det og bruge det, når man arbejder med sine leverancer. Og ved projektets afslutning bør man se på, hvordan man brugte det: Var det vellykket? Var det rigtigt i forhold til det, man oprindeligt satte sig for? Man er nødt til at bruge dokumentet for at gøre det nyttigt.

Ben Aston:

Fortæl mig så om en situation, hvor du tager RACI-skemaet frem. Bruger du det på statusmøder, hvor du siger: “I den kommende uge gør vi det her, det her og det her, så lad os se på vores RACI-skema. Disse personer har det endelige ansvar, disse personer er ansvarlige, og vi hører og informerer disse personer undervejs”? Eller hvordan bruger du det fra uge til uge?

Suze Haworth:

Jeg bruger det ikke nødvendigvis på statusmøder. Det fortæller selvfølgelig, hvem du skal gå til, hvem du skal involvere, hvem du skal dele leverancer med, og hvem du skal tildele opgaver. Men jeg ser det mere som et internt referencepunkt, som man kan vende tilbage til, hvis man skal minde sig selv om, hvem der er involveret i en leverance, hvem der skal have den til feedback, og hvem der skal informeres, når den er leveret. Det er mest et internt opslagsværk, men man skal selvfølgelig gøre opmærksom på det, hvis tingene ikke udvikler sig sådan.
Det er også her, man virkelig kan bruge det. Hvis man for eksempel har tildelt rollen som hørt til en opgave eller leverance, og alle på kundesiden eller blandt interessenterne pludselig vil involveres, kan man gå til den direkte kundekontakt eller den person, man primært arbejder med, og sige: “Se, det her skabte vi sammen i begyndelsen. Vi er nødt til at følge det, fordi formålet er at skabe effektivitet, holde kommunikationen enkel og undgå at tilføje lag af unødvendigt arbejde og tid til projektet.”

Ben Aston:

Sådan som jeg forstår det, bruger du et samlet RACI-skema, der dækker både bureauet og kunden, eller har du to separate?

Suze Haworth:

Jeg har brugt forskellige tilgange. Det afhænger virkelig af projektet. Hvis man har to meget store teams – ét hos jer og ét hos kunden – kan det potentielt være bedre at oprette to skemaer. For nylig har jeg ofte oprettet et skema for kundesiden, når kunden har mange interessenter, fordi det vigtigste er at vide, hvem der skal involveres hos dem og hvornår. Vi havde et lidt mere strømlinet team hos os, så jeg samlede bureauet i én gruppe. Hvor der var bestemte ansvarlige opgaver, tog vi ansvaret for dem, men mange opgaver var også placeret hos kunden. Derfor lavede jeg et lidt større skema for deres side. Det afhænger altså virkelig af projektet. Jeg ved, at det er det klassiske svar på alt, men man er nødt til at tilpasse det til projektet.
Det vigtigste ved RACI er også at sikre, at man gør det for at skabe noget nyttigt. Dit projekt har måske ikke brug for et skema. Hvis du har et lille, enkelt projekt med få teammedlemmer og én kunde, er det sandsynligvis meningsløst at bruge et. Man skal vurdere behovet og formålet. Er det for at sikre, at man kan håndtere mange interessenter på kundesiden eller internt og skabe klare forventninger til, hvem der er involveret? Så laver man et. Man skal virkelig tilpasse det til projektet.

Ben Aston:

Det, RACI er god til, er at forhindre, at ting falder mellem stolene, og at nogen ved projektets eller leverancens afslutning kan sige: “Vent, hvorfor fik jeg ikke mulighed for at give feedback på det her?” Eller: “Jeg troede, at designteamet annoterede wireframes.”
Men efter min erfaring behøver vi ikke nødvendigvis give kunden et fuldt indblik i alt det, der foregår internt, for eksempel hvem der gør hvad, hvem der er ansvarlig, hvem der har det endelige ansvar, og hvem der høres. Det er som regel ikke nødvendigt og kan faktisk skabe forvirring. Men på kundesiden er det bestemt nyttigt, når vi overvejer, hvordan vi styrer kunden gennem processen, især når der er et stort team, eller når vi ved, at organisationen er meget politisk eller har svært ved at træffe beslutninger.
Man skal finde den ene person, der har det endelige ansvar, og sige: “Kan du huske, at vi i begyndelsen af projektet sagde, at du skulle have det endelige ansvar? Gælder det stadig? Hvis ikke, er vi nok nødt til at tilpasse processen, forlænge tidsplanen eller måske også øge budgettet, hvis det bliver mere forvirrende.”

Suze Haworth:

Ja, præcis. Derfor er det så vigtigt at involvere kunderne eller det interne team, hvis man arbejder med kunder, og involvere de personer, man tildeler ansvar, endeligt ansvar eller rollen som hørt. De skal være med til at skabe det. Det er ikke noget, man bør lave isoleret og derefter sende til nogen til godkendelse. De tænker måske ikke tingene ordentligt igennem og siger bare: “Ja, det er fint, lad os fortsætte projektet.” Men hvis man involverer dem i beslutningerne fra begyndelsen, skaber man klare linjer, kan komme videre med projektet og sikrer, at alle ved, hvem der gør hvad.

Ben Aston:

Hvornår holder RACI så op med at fungere efter din erfaring? Hvornår falder det fra hinanden? Man har skabt dokumentationen i begyndelsen og forsøgt at blive enige om alt, men hvornår begynder tingene at gå skævt? Hvilke ting skal man være opmærksom på, og hvilke advarselstegn skal man se efter, hvis noget ikke er helt rigtigt?

Suze Haworth:

Jeg tror, det især er tre af de ting, jeg allerede har berørt. Først og fremmest skal man få alles accept fra begyndelsen. Hvis man opretter det isoleret, tildeler en teammedarbejder ansvar, og personen ikke kender til eller accepterer det, eller hvis man antager noget på kundens vegne og siger: “Jeg tror, de har det endelige ansvar, og jeg tror, de er ansvarlige,” hvorefter man opretter skemaet, fungerer det ikke. Man skal have alles opbakning, især fra de personer, der får det endelige ansvar eller bliver ansvarlige for ting.
Det er også afgørende at bruge det. Man skal henvise til det gennem hele projektet, kontrollere at tingene er på rette spor, og sikre at de rigtige personer er involveret. Hvis man bare lader det ligge, er det spild af tid; så bliver det næsten bare et afkrydsningspunkt i begyndelsen. Efter projektet er det godt at gennemgå det og se, om det var nyttigt, om det var rigtigt, og om man kortlagde tingene korrekt. Det vil være nyttigt, når man senere opretter nye RACI-skemaer.

Ben Aston:

Vi har talt om, hvordan man opretter det og får opbakning, og om hvornår det kan falde fra hinanden. Men når det falder fra hinanden – for det er jo virkeligheden i projekter – hvor man tror, at rollerne er defineret, og at alle ved, hvad de skal, og man endda har dokumenteret det, men fingerpegen begynder, ting falder mellem stolene, og folk bliver frustrerede: Hvordan strammer man tingene op igen, når de begynder at blive løse?

Suze Haworth:

Det kan være fristende at bruge det som et værktøj, hvor man, hvis tingene går galt, og folk begynder at involvere sig for meget – eller personer på kundesiden, som man ikke havde forventet, bliver for involverede – holder det op foran dem og siger: “I accepterede faktisk dette i begyndelsen.” Men det er ikke meningen, at det skal bruges som: “Se, hvad I accepterede, I følger det ikke.” Det handler mere om at sige: “Se, det var her, vi var enige. Det var her, vi forsøgte at skabe effektivitet i projektet og afstemme forventninger. Nogle personer følger ikke dette, eller deres handlinger tilfører mere tid og arbejde til projektet.”
Man skal tale konsekvenserne igennem med de personer, der afsporer projektet, eller med dem, der arbejder sammen med de personer, der gør det. Forklar konsekvenserne for projektet, og hvorfor man oprettede skemaet i første omgang, og hvorfor man blev enige om, at bestemte personer skulle involveres eller have ansvaret. Det er vigtigt at få dem til at forstå, hvad der kan ske, hvis projektet fortsætter i den retning.

Ben Aston:

Det er en god måde at hjælpe folk på – at minde dem om begrundelsen for, hvorfor tingene er, som de er, eller hvorfor de blev defineret sådan i begyndelsen af projektet. Det hjælper folk med at finde tilbage til deres rolle. “Nå ja, der er en grund til, at jeg ikke har det endelige ansvar for det her. Det er, fordi jeg faktisk ikke har den nødvendige ekspertise til at kommentere på det.”

Suze Haworth:

Og det fører tilbage til at gøre dokumentet virkelig nyttigt og have en grund til at bruge det. Vi skal skabe effektivitet i projektet, fordi tiden eller budgettet er begrænset – der er en grund til det. Hvis man ikke laver RACI-dokumentet med et bestemt formål, er det stort set værdiløst, fordi man ikke har noget at holde det op imod. Så er det spild af tid. Man skal altså sikre sig, at der er klare fordele ved at gøre det, og at man faktisk skaber effektivitet.

Ben Aston:

Det er svært. Hvis du gerne vil downloade en RACI-skabelon, har Suze lavet en til os samt et virkelig nyttigt eksempel med “Ringenes Herre”, der forklarer, hvordan den kan anvendes på et projekt. En interessant lille oplysning: Da vi sendte en e-mail ud og skrev: “Suze har skrevet denne artikel, og vi har et eksempel baseret på ‘Ringenes Herre’,” svarede en person: “Jeg kan ikke tro, at I spilder alles tid med det her.” Personen skrev en meget spydig e-mail. Jeg tror ikke, jeg svarede, men jeg blev overrasket. Dagen efter skrev personen: “Jeg læste faktisk artiklen, og den var god. Jeg kan bare ikke lide ‘Ringenes Herre’.”

Suze Haworth:

Jeg ved det. Det er ret specifikt. Og da jeg lavede den matrix for “Ringenes Herre”, tænkte jeg: “Jeg kommer helt sikkert til at få noget af det her galt.” Så isoleret set gør jeg præcis det, jeg siger, man ikke skal gøre. Men det handler om at gøre det levende på en måde, som folk kan relatere til.

Ben Aston:

Det gode ved det var, at i det mindste nogle mennesker ville have en forståelse af det projekt, det krævede at få ringen. Men ja, jeg kan godt se, at det er lidt kontroversielt. Jeg synes dog, det er fantastisk. Suze, mange tak fordi du ville være med. Det har været en fornøjelse at have dig med.

Suze Haworth:

Tak.

Ben Aston:

Hvis du vil bidrage til samtalen, kan du kommentere på indlægget eller gå til ressourcesektionen på TheDigitalProjectManager.com og tilslutte dig vores Slack-team, hvor der foregår alle mulige interessante samtaler. Hvis du gerne vil høre mere fra Suze, kan du gå til træningssektionen på TheDigitalProjectManager.com og tilmelde dig det næste kursus i digital projektledelse, hvor Suze medvirker. Men indtil næste gang: Tak fordi du lyttede med.