Slutt å peke fingre – bruk et RACI-diagram (med Suze Haworth)

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.

Ben Aston:

Noe av det vanskeligste ved å lede prosjekter er kanskje at vi må jobbe med … vel, mennesker. Og mennesker varierer utrolig mye. Vi er inkonsekvente, egoistiske, upålitelige og utrolig lunefulle – og jeg snakker bare om meg selv. Så jeg lurer på om prosjektene dine ligner på mine. Når de går galt – og det gjør de selvfølgelig på et eller annet tidspunkt – kan det raskt utvikle seg til en fryktelig øvelse i å peke fingre, der alle ser ut til å anklage alle andre for ikke å gjøre jobben sin ordentlig. Så hvordan i all verden kan vi håndtere et prosjekt når vi må forholde oss til alt dette? Det skal du få vite i dag.

Takk for at du lytter. Jeg heter Ben Aston, og dette er Digital Project Manager-podkasten. Denne podkasten presenteres av Clarizen, lederen innen programvare for virksomhetsstyring av prosjekter og porteføljer. Besøk Clarizen.com for å lære mer. I dag har jeg med meg Suze Haworth, en av våre faste DPM-eksperter hos Digital Project Manager. Suze, tusen takk for at du blir med i programmet.

Suze Haworth:

Takk, Ben. Takk for at jeg fikk komme.

Ben Aston:

La meg introdusere Suze ordentlig, siden hun er ny. Dette er, tror jeg, vår aller første podkast sammen.

Suze Haworth:

Ja.

Ben Aston:

Suze er frilansende digital prosjektdirektør i London, og hun har mye erfaring. Hun har vært i bransjen i over 13 år, begynte innen kundeansvar, omtrent som meg, og gikk deretter over til prosjektledelse. Men i stedet for at du bare leser opp biografien din, Suze, kan du fortelle litt om hva slags prosjekter du jobber med akkurat nå?

Suze Haworth:

Akkurat nå? Vel, i fjor gikk jeg faktisk over til frilans, så jeg har jobbet i flere år på tvers av ulike byråer, slik du sa, men i fjor begynte jeg som frilanser. For øyeblikket har jeg en rolle i et byrå i London, og jeg jobber med to store prosjekter. Det ene er et designsystem for en ganske stor detaljhandelskjede, og i det andre leder jeg et arbeidsprogram for en annen detaljhandelsaktør. Det er alt sammen ganske interessant arbeid.

Ben Aston:

Er detaljhandel ditt område?

Suze Haworth:

Det er egentlig litt av hvert. Jeg har mye detaljhandel, en kringkaster, en veldedig organisasjon og alle mulige slags kunder. Men ja, det er et tydelig fokus på detaljhandel i kontoene jeg nevnte, så det kan du kanskje si.

Ben Aston:

Kult. I frilansrollen din, hva synes du er vanskeligst? Hvilke større utfordringer håndterer du akkurat nå?

Suze Haworth:

Jeg tror den største utfordringen, og dette gjelder alltid for prosjektledere, er at du har så mange forskjellige ting å håndtere og gjøre, som du har ansvaret for. Du skal ikke bare levere et prosjekt på en vellykket måte, men også håndtere tidsplaner, budsjett, teamets leveranser, de enkelte teammedlemmene – og dermed også mange teamproblemer – i tillegg til kundekontakten. Det er rett og slett vanskelig å balansere så mange ting innenfor tiden du har. Ofte føles det som en konstant kamp å få plass til alt på én dag.

Ben Aston:

Ja. Synes du det er vanskeligere fordi du tidligere var fast ansatt og nå har en slags kontraktørrolle? Opplever du det som annerledes?

Suze Haworth:

Ja, det er litt annerledes fordi du som frilanser har større ansvar for din egen tid, blant annet når det gjelder hva du fakturerer byrået. Du kan ikke havne i en situasjon der du føler at du ikke kan si nei til ting. Jeg har lært å bli bedre på å si at hvis du har for mye på tallerkenen, kan du bare gjøre en begrenset mengde, og du må gjøre det ordentlig. Derfor er det bedre å kjenne sine egne grenser enn å bare si ja til alt.

Ben Aston:

Ja. Da jeg var kontraktør, opplevde jeg også at det stemte. Det er faktisk noe veldig fint ved å være kontraktør, fordi du ikke nødvendigvis prøver å få forfremmelse. Du vil selvfølgelig beholde kontrakten og fortsette å jobbe med dem, men du prøver ikke å imponere folk på helt samme måte som når du er fast ansatt og tenker: «Jeg bør nok si ja, ellers ser dette dårlig ut.»

Suze Haworth:

Ja, nettopp. Du vil selvfølgelig fortsatt gjøre et godt inntrykk. Bransjen er liten, så alle kjenner alle. Men det er godt å kunne trekke seg litt tilbake på slutten av dagen og si: «Ok, arbeidstiden min er over», i større grad enn når man er fast ansatt.

Ben Aston:

Siden du begynte som kontraktør, hvor mange forskjellige steder har du jobbet?

Suze Haworth:

Bare et par så langt, faktisk, siden jeg ikke har holdt på så lenge. Det har vært ganske bra, fordi jeg faktisk har rukket å tilbringe litt tid i byrået jeg er i nå, så jeg kjenner folk ganske godt. Jeg kjenner kundene bedre også, fordi man får litt mer tid på prosjektene og kontoene.

Ben Aston:

Jobber du internt, eller jobber du hovedsakelig eksternt?

Suze Haworth:

Internt. Jeg snakker faktisk varmt om fordelene ved fjernarbeid til alle jeg snakker med om det, fordi jeg mener det er viktig og kan gjøre mange mer produktive. Men mange av byråene, særlig i London hvor jeg har jobbet mye, arbeider hovedsakelig internt.

Ben Aston:

Interessant. Jeg vet at du, i tillegg til frilans- og kontraktarbeidet ditt, også skriver. Du har skrevet ting for DPM, og du skal også delta på DPM Summit senere i år. Kan du fortelle litt om det?

Suze Haworth:

Ja. Jeg gleder meg veldig. I fjor snakket jeg på DPM Summit i Las Vegas, og i år skal jeg faktisk holde en workshop. Det er et ganske interessant tema, for som prosjektledere er vi alle litt besatt av metoder, særlig agile-metoder. I workshopen skal jeg snakke om å kombinere ulike tilnærminger, spesielt noe jeg har innført i et arbeidsprogram jeg jobber med nå: Dual-Track-tilnærmingen. Den bruker enkelte aspekter fra Agile, men kombinerer dem på en litt annen måte. Jeg skal snakke om dette, Kanban, Lean og hvordan man kan kombinere ulike tilnærminger i prosjektene sine – ikke nødvendigvis ren Agile eller én enkelt metode, men hvordan man tilpasser eksisterende metoder.

Ben Aston:

Ja, det er bra. Og jeg synes det er så viktig. Suze er faktisk en av DPM-ekspertene våre, og hun skal også delta i kurset vårt Mastering Digital Project Management. Hvis du ikke vet hva jeg—

Suze Haworth:

Jo, det gjør jeg.

Ben Aston:

Det skjer faktisk førstkommende fredag, så dette blir Suz​es første opptreden. En av tingene vi snakker om på kurset, er å ikke henge seg for mye opp i navnet på metoden eller hva—

Suze Haworth:

Ja, nettopp.

Ben Aston:

Til syvende og sist handler det om å levere arbeid og finne bedre måter å gjøre det på – på en måte som fungerer for teamet, prosjektet og kunden. Man bør være pragmatisk i stedet for dogmatisk og si: «Dette er ikke Scrum, så vi må gjøre det på Scrum-måten.» Det spiller egentlig ikke så stor rolle. Vi må bare levere prosjektet.

Suze Haworth:

Nettopp. Jeg har alltid opplevd at folk blir så opptatt av prosessen og av å følge en bestemt prosess, men egentlig må man se på prosjektet eller produktet man lager og spørre: «Hva vil fungere for dette?» Det varierer så mye mellom prosjekter, så man må tilpasse eller kombinere.

Ben Aston:

Ja, helt klart. Noen kan være litt nedlatende overfor det å svekke metodens renhet, men jeg har aldri opplevd at de fungerer slik.

Suze Haworth:

Nei, nettopp. Det finnes mye snobberi rundt foretrukne tilnærminger, men jeg er ganske åpen for å bruke dem. I de fleste tilfeller, særlig i byråverdenen, må man bruke en kombinert prosess fremfor noe rent, ganske enkelt på grunn av situasjonene man befinner seg i.

Ben Aston:

Ja. Bortsett fra konferanseturneen, artikkelskrivingen og arbeidet – har du satt deg noen mål for året, eller er det noe du prøver å bli bedre på?

Suze Haworth:

Å, det var et vanskelig spørsmål. Jeg er så fokusert på det som skjer nå, både på jobb og utenfor jobb, at det noen ganger er vanskelig å tenke på den langsiktige fremtiden. Men én viktig ting jeg snakket om tidligere, er å lære å si nei. Jeg prøver å bli mye bedre på å delegere og faktisk gi slipp på litt ansvar, noe jeg alltid har syntes har vært vanskelig. Som prosjektleder blir man litt kontrollfreak, så det er definitivt et langsiktig mål for meg.

Ben Aston:

Ja, delegering er vanskelig. Særlig når du er kontraktør og ikke vet om personen du delegerer til kommer til å ta deg seriøst fordi du bare er kontraktør, eller fordi du ikke har noen historikk med å jobbe med dem, slik at du ikke vet om de faktisk kan gjøre det du prøver å delegere.

Suze Haworth:

Nettopp.

Ben Aston:

La oss snakke litt om verktøy. Når du har jobbet ulike steder, får du jo innblikk i forskjellige ting. Har du nylig funnet noe som gjør livet ditt bedre, eller noe du tenker at «alle burde kjenne til»?

Suze Haworth:

For å være ærlig får man som frilanser, og etter å ha jobbet i mange ulike byråer gjennom årene, eksponering for svært mange forskjellige verktøy. Man må vanligvis bruke det selskapet bruker. Jeg vil derfor aldri si at jeg har funnet det ideelle verktøyet som gjør alt jeg ønsker, uten vanskeligheter eller problemer som må håndteres. Jeg tror derfor ikke jeg vil si at det finnes ett ideelt verktøy jeg bruker. Jeg har brukt mange verktøy for ressursstyring og timeregistrering, og med hvert eneste verktøy har jeg funnet både gode og dårlige sider. Det eneste verktøyet, hvis man kan kalle det et verktøy, som jeg virkelig liker, er Google Regneark. Det er fordi du kan bruke det til nesten alt, eller i hvert fall til veldig mange forskjellige ting.

Ben Aston:

Har du prøvd Monday.com?

Suze Haworth:

Nei, det har jeg faktisk ikke.

Ben Aston:

For en som liker å håndtere ting i regneark, tror jeg Monday kanskje kan være—

Suze Haworth:

For en nerd.

Ben Aston:

Det fine med regneark er at de er gratis, eller i hvert fall at Google Regneark er det, og at de er utrolig fleksible. Men Monday legger til et ekstra lag med automatisering og mer kraft i filtrering og styring. Du burde prøve det. Det er som regneark på steroider.

Suze Haworth:

Da skal jeg absolutt se på det. Det høres ut som noe for meg.

Ben Aston:

Kult. La oss gå videre til artikkelen din. Det er en stund siden du skrev den, men hvis vi går tilbake til utgangspunktet: Hvordan håndterer vi mennesker som enten ser ut til å ville ta over et prosjekt, eller som ikke vil ta noe ansvar i det hele tatt? Suz​es artikkel handler om hvordan vi kan bruke et RACI-diagram til å gjøre dette. For dem som ikke har lest artikkelen ennå: Fortell oss om RACI-diagrammer. Hva betyr «RACI»?

Suze Haworth:

RACI står for ansvarlig utfører, ansvarlig beslutningstaker, konsultert og informert. Det er i utgangspunktet et diagram der du setter opp oppgaver eller leveranser for et prosjekt mot interessentene eller de interne teammedlemmene i prosjektet, og tildeler én av de fire bokstavene til hver rolle og oppgave. Det betyr at noen er ansvarlig utfører, noen er ansvarlig beslutningstaker, noen blir konsultert i prosjektet, og noen blir informert. Det er en god måte å fordele ansvar for hver oppgave eller leveranse på, samtidig som man sørger for at ikke for mange personer deltar i alle beslutninger, og at det er tydelig hvem som skal arbeide med hva gjennom prosjektet.

Ben Aston:

Kult. Jeg tror noe av det folk vanligvis blir mest forvirret av, ikke handler om hvem som skal informeres eller konsulteres. Det er ofte ganske rett frem. Forvirringen handler om forskjellen mellom å være ansvarlig utfører og å være ansvarlig beslutningstaker. Hvordan skiller du mellom disse, og hvordan håndterer du personer som ønsker å være ansvarlige utførere, men ikke beslutningstakere?

Suze Haworth:

Jeg tror dette faktisk er den vanskeligste delen av RACI, og noe jeg selv har slitt mye med tidligere. Derfor kan det være krevende å lage et RACI-diagram, fordi man bruker så lang tid på å forstå hva rollene faktisk betyr, og hva de betyr for personen som får rollen. Enkelt forklart er den ansvarlige utføreren personen som faktisk gjør oppgaven, lager en leveranse eller driver den fremover. Den ansvarlige beslutningstakeren er personen som godkjenner oppgaven og følger den opp, uten nødvendigvis å gjøre selve oppgaven.
En annen utfordring er at man lett kan tildele prosjektlederen eller produkteieren beslutningsansvaret fordi de leder prosjektet og er det sentrale kontaktpunktet. Men man må forsøke å skille prosjektlederen fra ansvaret for alt og spørre hvem som faktisk er mest senior for den aktuelle oppgaven eller leveransen. Hvis det gjelder design, er det en kreativ leder? Er det den kreative lederen på deres side eller kundens side? Man må unngå å legge beslutningsansvaret på prosjektlederen eller produkteieren hver eneste gang.

Ben Aston:

Ja, det er helt sentralt. Feilen vi lett kan gjøre, er å gjøre alle ansvarlige utførere og alle ansvarlige beslutningstakere – ikke bare prosjektlederen, men alle. «Alle må ta ansvar for dette. Vi trenger kollektivt ansvar.»

Suze Haworth:

Ja, nettopp. Det er vanskelig, fordi man tenker at flere teammedlemmer også skal gjøre oppgaven, og at kanskje fem personer derfor er ansvarlige utførere. Men man må forsøke å strømlinjeforme og begrense dette. Hvis man sprer rollene over alle, får man ikke oppnådd det RACI er best på: å definere ett eller noen få tydelige kontaktpunkter eller godkjenningsnivåer. Det er det RACI-diagrammet skal brukes til.

Ben Aston:

Det som er nyttig, er at det vanligvis ikke er komplisert å finne ut hvem som faktisk gjør arbeidet. Det som kan være vanskelig, er forskjellen mellom konsultert og informert, og særlig forskjellen mellom ansvarlig beslutningstaker og konsultert. Vi ønsker vanligvis én person som har det endelige ordet om hvorvidt resultatet holder mål. Det ligner på kvalitetskontroll. Samtidig kan vi ha flere personer som konsulteres, og enda flere som informeres. De får bare vite: «Forresten, dette er det vi kom frem til.»
De konsulterte kan likevel avspore prosjektet, fordi de har en stemme og en mening. De er ikke nødvendigvis ansvarlige for å levere riktig resultat til rett tid, men de har innflytelse. Derfor ligger den virkelige spenningen mellom ansvarlig beslutningstaker og konsultert, og i maktkampen mellom personer som ønsker å hevde posisjonen, myndigheten eller meningen sin, uten å ha det endelige ansvaret for at leveransen blir riktig.

Suze Haworth:

Ja, og en annen spenning er at den konsulterte nesten må ha en stemme når du sier at personen skal konsulteres. Derfor er rollen som ansvarlig beslutningstaker så viktig: Personen må eie leveransen eller oppgaven og sørge for at de konsulterte bidrar uten å avspore hele prosjektet med side på side med tilbakemeldinger.

Ben Aston:

Men vær ærlig: Bruker du et RACI-diagram i alle prosjekter, og hvordan holder du det enkelt? Hvis du går ned på mange detaljeringsnivåer, kan det ta lang tid å lage. Hvordan unngår du at det bare blir enda en arbeidsnedbrytningsstruktur med navn ved siden av?

Suze Haworth:

Jeg er veldig opptatt av å ikke lage dokumentasjon bare for dokumentasjonens skyld. Hvis du lager et RACI-diagram, må det være nyttig og faktisk brukes. Du skal ikke bare lage det i begynnelsen av prosjektet og la det dø på en server. Du må bruke det som referanse når du går gjennom leveransene. På slutten, i prosjektevalueringen, bør du også se på hvordan det ble brukt, om det fungerte og om det var riktig slik dere satte det opp i utgangspunktet. Du må bruke dokumentet for at det skal ha verdi.

Ben Aston:

Fortell meg om en situasjon der du tar frem RACI-diagrammet. Bruker du det i statusmøter når dere planlegger uken som kommer, og sier at disse personene er beslutningsansvarlige, disse er ansvarlige utførere, og disse skal konsulteres og informeres? Hvordan bruker du det fra uke til uke?

Suze Haworth:

Jeg bruker det ikke nødvendigvis i statusmøter. Det forteller deg hvem du bør kontakte, hvem du bør involvere, hvem du bør dele leveranser med og hvem du bør tildele oppgaver til. Jeg bruker det mer som et internt referansepunkt, for å sjekke hvem som er involvert i en leveranse, hvem som skal få den tilbakemelding på den og hvem som skal informeres når den er levert. Det er først og fremst et internt referanseverktøy, men du bør ta opp saken hvis ting ikke utvikler seg slik.
Hvis du for eksempel har tildelt noen rollen som konsultert, og alle på kundesiden eller blant interessentene plutselig vil involvere seg, kan du snakke med den direkte kundekontakten eller den du jobber tettest med, og si: «Dette laget vi sammen i begynnelsen. Vi må følge det, fordi hensikten er å skape effektivitet, holde kommunikasjonen strømlinjeformet og unngå ekstra lag med arbeid og tid.»

Ben Aston:

Slik jeg forstår deg, bruker du et samlet RACI-diagram som omfatter både byrået og kunden, eller har du to separate?

Suze Haworth:

Jeg har brukt ulike tilnærminger. Det avhenger virkelig av prosjektet. Hvis du har to store team, ett på din side og ett på kundens side, kan det være bedre å lage to diagrammer. Nylig har jeg laget et diagram for kundesiden når de har hatt mange interessenter, fordi det viktigste var å vite hvem på deres side som skulle involveres og når. Vi hadde et mer strømlinjeformet team på vår side, så jeg samlet byrået som én enhet. Der det var bestemte oppgaver, tok vi ansvar, men mye ansvar lå også på deres side. Derfor laget jeg et litt større diagram for dem. Det avhenger altså av prosjektet.
Det viktigste med RACI er å sørge for at det faktisk gir noe nyttig. Prosjektet ditt trenger kanskje ikke et diagram. Hvis du har et lite prosjekt med få teammedlemmer og én kunde, kan det være meningsløst å bruke ett. Vurder behovet og hva du prøver å oppnå. Hvis du har mange interne eller eksterne interessenter og trenger å håndtere dem og avklare hvem som er involvert, lager du et diagram. Det må tilpasses prosjektet.

Ben Aston:

RACI er godt egnet til å forhindre at ting faller mellom sprekkene, og til å hindre at noen på slutten av prosjektet sier: «Hvorfor fikk jeg ikke anledning til å gi tilbakemelding?» eller «Jeg trodde designteamet skulle annotere trådrammene.»
Men etter min erfaring trenger vi ikke nødvendigvis å vise kunden alt som skjer internt – hvem som gjør hva, hvem som er ansvarlig, hvem som har beslutningsansvaret og hvem som konsulteres. Det kan skape forvirring. På kundesiden er det likevel nyttig når vi må håndtere en stor gruppe, særlig i en politisk organisasjon eller når det er vanskelig å ta beslutninger. Da kan vi finne én person med beslutningsansvar og si: «Husker du at du skulle ha dette ansvaret da prosjektet startet? Gjelder det fortsatt? Hvis ikke, må vi endre prosessen eller forlenge tidsplanen – og kanskje øke budsjettet fordi alt blir mer komplisert.»

Suze Haworth:

Ja, nettopp. Derfor er det viktig å involvere kundene eller det interne teamet når du fordeler roller som ansvarlig utfører, ansvarlig beslutningstaker eller konsultert. Få dem med på å lage diagrammet. Det er ikke noe du bør gjøre alene og bare sende til noen for godkjenning. De tenker kanskje ikke gjennom tingene og sier bare: «Ja, det ser greit ut, la oss fortsette.» Hvis du involverer dem i beslutningene fra begynnelsen, avklarer du linjene og gjør det lettere å komme videre med en felles forståelse av hvem som gjør hva.

Ben Aston:

Når slutter RACI å fungere? Når bryter det sammen? Dere har laget dokumentasjonen i begynnelsen og forsøkt å bli enige, men når begynner ting å rakne? Hvilke faresignaler bør folk se etter?

Suze Haworth:

Tre ting er særlig viktige. For det første må alle bli enige på forhånd. Hvis du lager diagrammet alene, tildeler ansvar til et teammedlem som ikke kjenner til det eller er enig, eller antar at kunden er ansvarlig beslutningstaker eller ansvarlig utfører, vil det ikke fungere. Du må få alles tilslutning, særlig fra dem som skal ha ansvar for oppgavene.
Det er også viktig å bruke diagrammet. Referer til det gjennom prosjektet, sjekk at ting går som de skal, og at de riktige personene er involvert. Hvis du lar det ligge, blir det bare en avkrysningsboks du fyller ut i starten. Etter prosjektet bør du evaluere om det var nyttig og om oppgavene var riktig kartlagt. Det kan gi læring til fremtidige RACI-diagrammer.

Ben Aston:

Når ting faktisk bryter sammen – roller er definert og dokumentert, men pekingen på hverandre begynner, ting faller mellom sprekkene og folk blir opprørte – hvordan strammer du opp situasjonen igjen?

Suze Haworth:

Det kan være fristende å holde diagrammet opp foran folk og si: «Du godtok dette i begynnelsen.» Men det er ikke egentlig hensikten. Det handler mer om å si: «Dette var det vi var enige om. Vi forsøkte å skape effektivitet og avklare forventninger. Nå følger noen det ikke, og handlingene deres tilfører prosjektet mer tid og arbeid.»
Snakk gjennom konsekvensene med dem som avsporer prosjektet, eller med dem som er involvert i det. Forklar hva det betyr for prosjektet, hvorfor dere opprettet diagrammet, og hvorfor dere ble enige om at bestemte personer skulle involveres eller ha ansvar. De må forstå hva som kan skje hvis situasjonen fortsetter.

Ben Aston:

Det hjelper å minne folk på hvorfor ting er slik de er, eller hvorfor de ble definert slik i starten. Det kan hjelpe dem tilbake i rollen sin. «Ja, det er en grunn til at jeg ikke har beslutningsansvar for dette – jeg har faktisk ikke kompetansen til å kommentere det.»

Suze Haworth:

Det fører også tilbake til å gjøre dokumentet nyttig. Det må finnes en grunn til at det er der. Kanskje dere må skape effektivitet fordi tiden eller budsjettet er begrenset. Hvis du ikke lager RACI-dokumentet med en tydelig hensikt, er det nærmest verdiløst, fordi du ikke har noe å knytte det til. Det er derfor viktig å se klare fordeler ved å lage det og å faktisk skape effektivitet.

Ben Aston:

Hvis du vil laste ned en RACI-mal, har Suze laget en til oss, i tillegg til et nyttig eksempel med «Ringenes herre» som viser hvordan dette kan brukes i et prosjekt. Da vi sendte ut en e-post om artikkelen og eksempelet, svarte noen: «Jeg kan ikke tro at dere kaster bort alles tid på dette.» De skrev en ganske spydig e-post. Jeg tror ikke jeg svarte, men jeg ble overrasket. Dagen etter skrev de: «Jeg leste artikkelen, og den var flott. Jeg liker bare ikke Ringenes herre.»

Suze Haworth:

Jeg vet. Det er ganske spesifikt. Da jeg laget matrisen for «Ringenes herre», tenkte jeg: «Jeg kommer sikkert til å ta noe av dette feil.» Så alene gjorde jeg akkurat det jeg sier at man ikke skal gjøre. Men hensikten var å gjøre det levende på en måte folk kunne kjenne seg igjen i.

Ben Aston:

Det som var bra, var at noen i det minste ville ha en forståelse av prosjektet med å få tak i ringen. Men ja, det er selvfølgelig litt splittende. Jeg synes likevel det er flott. Suze, tusen takk for at du ble med. Det har vært veldig hyggelig å ha deg her.

Suze Haworth:

Takk.

Ben Aston:

Hvis du vil bidra i samtalen, kan du kommentere innlegget eller gå til ressursseksjonen på TheDigitalProjectManager.com for å bli med i Slack-teamet vårt, der det foregår mange interessante samtaler. Hvis du vil høre mer fra Suze, kan du gå til kursseksjonen på TheDigitalProjectManager.com og melde deg på neste kurs i digital prosjektledelse, der Suze deltar. Men frem til neste gang: Takk for at du lyttet.