Gør dine statusrapporter nyttige (med Robyn Reynolds)

Læs transskriptionen:

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

Ben Aston:

Tak, fordi du lytter med. Jeg hedder Ben Aston, og dette er Digital Project Manager-podcasten. Denne podcast præsenteres af Clarizen, den førende leverandør af software til virksomhedsprojekt- og porteføljestyring. Besøg Clarizen.com for at få mere at vide. I dag har jeg selskab af Robin Reynolds, en af vores faste DPM-eksperter hos Digital Project Manager og brevkasseredaktør for Kære DPM, hvor vi besvarer spørgsmål fra digitale projektledere. Robin, mange tak, fordi du er med igen.

Robin Reynolds:

Hej Ben. Jeg er så glad for at være tilbage. Jeg nyder altid at tale med dig.

Ben Aston:

Godt. Har du nogensinde befundet dig i en knibe, fordi du var ret sikker på, at du gjorde et virkelig godt stykke arbejde med at holde kunden opdateret om alt i projektet, men så rammer katastrofen projektet en dag, og alle de e-mails, beskeder og sms'er, som du troede, du havde sendt kunden om projektet, pludselig ser ud til på magisk vis at være forsvundet? Det, mine venner, er grunden til, at I har brug for en statusrapport. Så i dag taler vi om de frygtede statusrapporter. Er de virkelig nødvendige? Og hvis de er, hvad skal vi så have med i dem? Hvordan kan vi gøre dem mindre besværlige, og hvad kan vi gøre for rent faktisk at gøre dem nyttige?

Hvis du endnu ikke har mødt Robin, vil jeg gerne introducere hende ordentligt. Robin bor lige nede ad vejen fra mig – eller det er i hvert fald sådan, jeg godt kan lide at tænke på det – og hun bor i Portland, hvor hun kan lide emojis, lister og hvalpe. Vi taler mere om det om lidt, men som en af vores DPM-eksperter medvirker Robin også på vores kommende kursus, som hedder Mastering Digital Project Management. Hvis du ikke er sikker på, hvad jeg taler om, og du har brug for projektlederuddannelse, så kig på det.

Det er et syv ugers lynkursus, der omfatter interaktive videosessioner, ugentlige lektioner, opgaver, gruppediskussioner og også mulighed for coaching-sessioner. Gå til digitalprojectmanagerschool.com og tilmeld dig. Vi har kun få pladser tilbage.

Men Robin, du har for nylig skiftet job. Fortæl mig om dit nye arbejde.

Robin Reynolds:

Ja, jeg er netop ved at afslutte mine første par uger i det såkaldte nye job, og det har været helt fantastisk. Jeg arbejder nu for 10Up, og det, vi grundlæggende gør, er at gøre internettet bedre ved at skabe websites og værktøjer til indholdsskabere med stor præcision.

Det, der er rigtig sjovt ved 10Up, er, at alle arbejder på afstand – 100 % af os. Og vi arbejder med blandt andre AMC, NBC Universal og Time Inc.

Ben Aston:

Fedt. Hvis alle arbejder på afstand, hvilken tidszone arbejder du så i? Er det bare Nordamerika, eller er det også andre lande?

Robin Reynolds:

Heldigvis er vi organiseret sådan, at vi er opdelt i forskellige grupper og teams. Jeg er teknisk set i et team, der kun arbejder efter Pacific Time. Derefter er der et europæisk team og så videre.

Nogle dage har jeg måske et møde lidt tidligere, end jeg bryder mig om, men det sker ret sjældent.

Ben Aston:

Får du så mulighed for at skifte team, hvis du tænker: »Vent, jeg vil gerne tage til Europa hen over sommeren«? Kan man bytte team?

Robin Reynolds:

Det sjove er, at en af vores teamledere netop har gjort det. Nu er hun i Europa, hvor hun nyder livet og rejser, samtidig med at hun leder sit team.

Ben Aston:

Sådan. Det lyder ret fedt. Hvilke udfordringer er der så? Du har tidligere arbejdet med projektledelse på afstand, men har du arbejdet i et miljø, hvor alle arbejder på afstand hele tiden? Er der nogle særlige udfordringer ved det?

Robin Reynolds:

Ja, jeg arbejdede på afstand i mit tidligere job, men det virkelig gode ved 10Up er, at de opfordrer alle til at arbejde inden for deres egne tidszoner, og vi er store fortalere for at bruge Zoom som videoværktøj. Det er virkelig godt, når man arbejder med kunder og forbinder sig med sit team, fordi video er forventningen – det er ikke kun telefonen.

Ben Aston:

Det er ikke bare en valgfri ekstra mulighed.

Robin Reynolds:

Nej, præcis.

Ben Aston:

Og folk gør det faktisk? Det virker virkelig?

Robin Reynolds:

Indtil videre, ja. Helt sikkert. Men jeg er stadig i begyndelsen og er den nye pige. Lige nu prøver jeg bare at acceptere, at jeg ikke ved alt, og jeg forsøger virkelig at lære, lytte, lære mine teams og kunder at kende og opbygge relationerne.

Ben Aston:

Er der noget, du har opdaget efter at være begyndt i den nye rolle, hvor du tænker: »Det skal jeg virkelig blive bedre til«?

Robin Reynolds:

Jeg tror, det handler om at acceptere, at man har udført jobbet før. Når man starter i en ny rolle, er der altid lidt bedragersyndrom, hvor man tænker: »Åh gud, har jeg gjort det her før?« Og så er svaret: »Ja, selvfølgelig, det er bare et andet miljø.« Så jeg prøver bare at være mere sikker på mig selv og tage ejerskab over mine projekter.

Ben Aston:

Ja, jeg synes, det er så rigtigt. Når man starter et nyt sted, tænker man pludselig: »Åh gud, jeg ved ikke, hvordan man gør noget som helst her.« Hvordan gør man …

Robin Reynolds:

Ja, som om jeg er den dummeste person.

Ben Aston:

Jeg ved ikke, hvordan jeg får ressourcer til mit projekt. Det er interessant. Hvordan foregår ressourceallokeringen? Hvilken værktøjskasse bruger de?

Robin Reynolds:

Vi bruger en kombination af 10 Thousand Feet, og vi har også vores eget interne planlægningsværktøj. Mellem de to ting fungerer det hele godt, og jeg plejer at få de ressourcer, jeg har brug for til mine projekter. Vi laver også en masse fremadrettet planlægning flere måneder frem, så vi kan undgå konflikter i god tid.

Ben Aston:

Det lyder meget voksent. Hvilke typer projekter arbejder du egentlig på? Kan du fortælle om nogle af dem?

Robin Reynolds:

Jeg kan ikke fortælle præcis, hvad kunderne hedder, men jeg kan sige, at det er en blanding af løbende vedligeholdelse af websites og komplette redesigns og genopbygninger af websites ved hjælp af WordPress.

Ben Aston:

Fint. Så det er hårdt? Det lyder meget generelt. WordPress-ting. Lad os tale om statusrapporter. Har du skrevet din første statusrapport hos 10Up endnu?

Robin Reynolds:

Det har jeg bestemt. Vi har vores eget format og vores egen tilgang, ligesom alle bureauer, virksomheder og personer kan gøre det på forskellige måder.

Ben Aston:

Hvad er så din holdning? Du har netop skrevet en artikel om statusrapporter, men overbevis os. Hvorfor synes du, at statusrapporter er værd at lave?

Robin Reynolds:

Lad os være ærlige, Ben. Ingen kan lide statusrapporter eller at udarbejde dem. Det er næsten den værste del af jobbet, ikke? Det er ikke særlig sexet. Mange ser det som: »Åh, jeg skal gøre det her, men ingen kommer til at læse det.«

Men de er så vigtige. De bedste projektstatusrapporter skaber ansvarlighed og ejerskab i teamet. De håndterer problemer, reducerer risici og sikrer først og fremmest, at du er på rette spor i forhold til projektets mål.

De skaber værdi både for dine interne teams og især for kunderne. De giver kunderne tillid til, at deres penge leverer resultater i projektet, og de kan få kunderne til at se godt ud over for deres chefer, fordi de kan videresende rapporten til forskellige interessenter.

Endelig kan statusrapporter virkelig redde dig, fordi du har et dokumentationsspor, hvis tingene løber af sporet. Du kan sige: »Ja, vi gjorde dig opmærksom på denne risiko. Her er vores afværgeforanstaltning, og her er, hvad vi har gjort for at rette op på den.« På den måde forhåbentlig undgår man, at det bliver: »Det her havde været på vej længe, og vi glemte at tale om det.«

Ben Aston:

Jeg tror, fristelsen, når vi laver statusrapporter, kan være at tænke: »Jeg springer bare over i denne uge, for jeg tror ikke, kunden læser dem alligevel. Sidste uge sendte jeg den til dem og inkluderede en lille overraskelse, hvor jeg skrev: ’Jeg tror, vi overskrider budgettet.’ Og de sagde ikke noget. Så nu, hvor jeg skrev det sidste uge, vil jeg ikke opdatere dem denne uge, hvis de nu læser den.«

Robin Reynolds:

Præcis. »Jeg har fortalt dem det, så nu er det overstået.«

Ben Aston:

Ja.

Robin Reynolds:

Det handler virkelig om at afstemme forventninger regelmæssigt.

Ben Aston:

Hvad er så det vigtigste? Mit perspektiv på statusrapporter er: »Lad os gøre dem så enkle som muligt.« Man ønsker ikke, at det skal tage to timer at opdatere dem, og hvis man arbejder med fire forskellige kunder, kan det tage en hel dag bare at lave statusrapporterne. Hvad er efter din mening det absolut nødvendige, der skal med?

Robin Reynolds:

Jeg er helt enig. Jo enklere en statusrapport er, desto bedre. Man kan bruge rigtig meget tid på dem og forvandle dem til projektplaner eller blot gentagelser af projektplanen. Men det vil jeg ikke anbefale. Det vigtigste er projektnavn, kundenavn, projektets vision eller resumé – det bør være én sætning – samt projektets status. Det er meget vigtigt, som du nævnte. Der er mange forskellige måder at gøre det på i statusrapporten, og du kan læse mere om det i artiklen. Den skal helt sikkert indeholde timer eller vise, hvordan projektet udvikler sig, og om du er på rette spor med hensyn til tidsplan og budget.

Du skal også have med, hvad der for nylig er blevet afsluttet i projektet. Jeg plejer typisk at linke til alle de seneste opgaver, jeg har afsluttet, og derefter henvise til projektstyringsværktøjet, hvis kunden har adgang til det.

Derefter skal du skrive, hvad du planlægger at afslutte som det næste. Det kan være i løbet af den næste måned eller måske den næste uge, men det giver kunden besked om de kommende prioriteter og om, hvad I vil tage fat på. På den måde kan kunden vende tilbage og sige: »Det er faktisk ikke længere en prioritet.« Eller: »Lad os prioritere denne i stedet.«

Endelig skal statusrapporten indeholde problemer og forhindringer. Det er her, du beskriver potentielle risici og forsøger at finde løsninger sammen med kunden under statusgennemgangen.

Ben Aston:

Fint. Hvis det er det vigtigste, lyder det stadig som en masse.

Det er selvfølgelig alt sammen vigtigt. Måske er en tredjedel af det statisk fra uge til uge. Nogle ting ændrer sig ikke, men hvor meget detaljer er nok? Jeg kan godt lide det, du siger om afsluttede og kommende opgaver og om at linke til værktøjerne, så rapporten bare bliver et øjebliksbillede, hvor man kan dykke længere ned, hvis man vil. Men hvor mange detaljer tager du med om status og risici, så rapporten bliver nyttig uden at tage flere timer at færdiggøre?

Robin Reynolds:

Jeg sørger for, at mine projektstatusrapporter ikke tager mere end cirka 20 minutter. Den første tager naturligvis lidt længere tid. Men som projektledere bruger jeg også tiden til virkelig at reflektere over projektet og sikre mig, at jeg forstår, hvor alting står.

Jeg laver ofte et første udkast tidligt om morgenen eller måske dagen før, jeg vil sende rapporten, og skriver alle mine idéer, tanker og noter ned. Derefter vender jeg tilbage og redigerer alt det overflødige væk, så den bliver meget præcis.

Kan du sige det enklere? Kan du bare linke til opgaven? Og så tale om den på et møde. Du skal sikre dig, at du ikke forsøger at løse alle problemerne i statusrapporten. Identificér dem blot, henvis videre, og diskutér dem.

Ben Aston:

Det er et virkelig godt punkt. Man kan se statusrapporter som noget, man skal lave, fordi kunden beder om dokumentation, men aldrig læser den. Den anden måde at se det på er: »Det her er faktisk et virkelig vigtigt værktøj for os, når vi prøver at holde fingeren på projektets puls.«

Det er nyttigt regelmæssigt at tage sig tid til at gå i dybden med, hvad der sker, revurdere risiciene og strategien for at håndtere dem, tænke over, hvad vi har gjort i denne uge, og hvad vi skal gøre i næste uge. På den måde kommer man et skridt foran teamet. Det er en virkelig nyttig øvelse i den løbende projektplanlægning, vi skal udføre for at holde projekterne på sporet og vide, hvor projektet står.

Ellers kan et projekt nogle gange bare fortsætte uden retning, og vi kan glemme at se det større billede af, hvor projektet er på vej hen. Oplever du også det?

Robin Reynolds:

Helt sikkert. Hvis man tænker på RACI, er det projektledernes ansvar at udarbejde statusrapporten. Men vores team og kunder er ansvarlige for at holde sig informeret, læse rapporten og stille spørgsmål eller bede om uddybning på baggrund af den.

Ben Aston:

Hvad er jeres metode hos 10Up? Er det mere vandfaldsbaseret, eller kører I sprint og arbejder mere agilt?

Robin Reynolds:

Vi gør begge dele. Det afhænger af projektet. Vi er ikke bundet til den ene eller den anden metode.

Ben Aston:

Jeg har set, at fristelsen i mere agile projekter med sprint kan være at tænke: »Vi behøver ikke lave statusrapporter, for alle ved jo, hvad der foregår.«

Men det er én ting, at folk er engagerede i projektet og ved, hvad der sker fra dag til dag. Noget andet er at træde et skridt tilbage og spørge: »Ved I, hvor mange timer vi har tilbage? Ved I, hvor budgettet står? Hvor meget mangler vi egentlig at lave?«

Robin Reynolds:

Præcis.

Ben Aston:

Et scrum-møde er godt, hvis man gennemgår et burndown-diagram, men det er meget nyttigt at give kunden alle oplysningerne og samle projektets detaljer på én eller to sider – også selvom man driver agile projekter.

Robin Reynolds:

Det er jeg helt enig i. Som jeg nævnte tidligere, kan kunden også dele rapporten med sin chef eller andre vigtige ledere eller interessenter, som potentielt kan tilføre din virksomhed flere penge.

Ben Aston:

Altid nyttigt. Lav jeres statusrapporter!

Når du har lavet statusrapporten, hvad gør du så med den? Sender du den i en e-mail? Fristelsen kan være at afslutte statusrapporten fredag klokken 16 og tænke: »Jeg lægger den bare i en e-mail og forsvinder. Sender den til kunden og håber på det bedste.«

Hvad gør du med dine statusrapporter, når du har lavet dem?

Robin Reynolds:

For det første prøver jeg ikke at sende dem fredag eftermiddag, for så er det næsten garanteret, at ingen læser dem. Jeg er heller ikke særlig begejstret for at modtage en vigtig e-mail fredag eftermiddag. Så er jeg mentalt gået på weekend, og mandag morgen virker det ikke særlig rart at begynde dagen med den.

Jeg sender typisk mine statusrapporter midt på ugen. Måske har jeg den interne rapport klar tirsdag, udarbejder den kundevendte statusrapport og sender den onsdag. Når jeg sender statusrapporten, vil jeg normalt gennemgå den på et statusmøde med kunden eller teamet.

Jeg sender den eventuelt inden mødet eller under mødet, deler min skærm og gennemgår det hele med dem. Derefter følger jeg op med rapporten og handlingspunkterne.

Du er ikke sammen med kunden for at læse rapporten højt. Den fungerer snarere som en ramme for dialogen. Du kan sige: »Her er, hvad vi gjorde, og det gik rigtig godt. Her er, hvad vi skal gøre, og her står vi i tidsplanen. Lad os tale om det – det ser ud til, at vi er foran tidsplanen.«

Ben Aston:

Er det sket for dig?

Robin Reynolds:

Teoretisk set.

Ben Aston:

Fint. Det er et rigtig godt råd. Jeg kan godt lide idéen om at dele skærmen og styre, hvad kunden ser, i stedet for bare at sende rapporten og håbe, at de kigger på den del, du gerne vil have dem til at se.

Fra mit perspektiv er statusmødet også en mulighed for at være sammen med kunderne, opbygge en god relation og skabe tillid. Det handler ikke kun om at dele information og afstemme, hvor projektet står, men også om at tale lidt om ting uden for projektet, så man opbygger mere tillid og venskab. Så er det ikke, som om man ikke har noget at bygge på, når man skal dele dårlige nyheder.

Det er nok sværere, når man arbejder på afstand. Hvordan opbygger du relationer med kunderne, når du arbejder på afstand?

Robin Reynolds:

Hvis kameraet er tændt, kan man se hinanden, og der foregår meget gennem kropssprog. Man taler stadig om de samme ting. Vi spørger også, hvad de lavede i weekenden og den slags.

Så jeg synes stadig, det er lige så effektivt. Du mindede mig også om, at jeg tidligere holdt interne statusmøder med mit team, hvor jeg bogstaveligt talt printede statusrapporten ud til dem. Set i bakspejlet virker det ret ekstremt.

Men jeg lærte af mit team, at det var den eneste måde at få dem til at læse den på: at lægge den foran dem og derefter gennemgå den sammen.

Ben Aston:

Ja.

Robin Reynolds:

Der findes altså ikke én perfekt måde at gøre det på. Der er nogle få forkerte måder, men det er vigtigt at forstå, hvad kunden foretrækker, og tilpasse sig det – ligesom man skal tilpasse sig sit interne team.

Ben Aston:

Har du nogle tips til at sikre, at kunden rent faktisk læser dine statusrapporter?

Robin Reynolds:

Helt sikkert statusmødet. Og så har jeg lært, at man aldrig må springe en statusrapport over. Når man først gør det, er det lidt som en dårlig restaurantanmeldelse. Man kan have én dårlig anmeldelse, men det kræver mange positive anmeldelser at rette op på det. Kunden vil altid huske den ene uge, hvor du ikke sendte rapporten.

Ben Aston:

Ja.

Robin Reynolds:

Sørg derfor for altid at være til tiden, være forberedt og sikre, at statusrapporten indeholder noget væsentligt. Den skal afspejle det arbejde, I udfører, så lad være med at haste den igennem. Sørg for, at den er fri for fejl, og lad være med at hænge nogen ud for dårligt arbejde i rapporten.

Ben Aston:

Du nævnte, at man skal tilpasse rapporten til kunden. Jeg har været i situationer, hvor kunden går amok og beder om alle mulige detaljer i statusrapporten.

Især når man arbejder på et projekt efter medgået tid og materialer, og kunden ønsker en oversigt over hver time, hver person har arbejdet på projektet, og hvordan hvert øjeblik er brugt. Det var meget besværligt at udarbejde, fordi man også skulle redigere alles kommentarer. Hvor går grænsen for, hvor meget man skal tilpasse rapporten til kunden? Hvornår bliver det for mange detaljer?

Robin Reynolds:

Jeg sidder her og nikker, for det har jeg også oplevet. Ofte er man nødt til at følge sin intuition. Hvis det for eksempel er en lille kontrakt efter medgået tid og materialer, er det måske ikke effektivt at registrere alle timer og opgaver, samle dem og udføre en masse omfattende regnearksarbejde.

Så må man forklare kunden, hvorfor man ikke gør det. Hvis kunden stadig insisterer, kan der være forretningsmæssige grunde til, at de har brug for det. Så må man samarbejde med dem om potentielt at øge finansieringen. Alternativt betyder det, at I måske ikke kan nå lige så mange opgaver, fordi I bruger tiden på rapporten i stedet for det egentlige projektarbejde.

Ben Aston:

Det er et godt råd. Hvis kunden ønsker noget, skal det behandles som arbejde. Nogle kunder bryder sig måske ikke om at se produktionen af statusrapporter som arbejde, og jeg har faktisk arbejdet for kunder, hvor kontrakten på en eller anden måde betød, at de ikke betalte for udarbejdelsen af statusrapporter. Det er vanvittigt.

Men kunderne skal forstå, at hvis vi skal producere mange detaljer i statusrapporterne og al denne ekstra rapportering, som ikke er nødvendig for at levere projektet godt, så skal de betale for det. Det bør være en ændringsanmodning, hvis de begynder at bede om flere detaljer, eller også må vi sige, at noget andet skal udgå af omfanget.

Ellers vil det hurtigt spise vores budget op.

Robin Reynolds:

Helt sikkert. Jeg vil blot tilføje, at man altid skal bede kunden og teamet om feedback på statusrapporterne. Nogle gange skriver jeg noget i min skabelon, som giver fuldstændig mening for mig, men mine udviklere kan måske sige: »Jeg aner ikke, hvorfor du har formuleret det sådan.« Eller: »Hvorfor har du dette afsnit med?«

Ben Aston:

Ja.

Robin Reynolds:

Eller: »Kan du tage dette med i stedet?« Man skal altså tilpasse rapporten, men ikke på en meget ineffektiv måde. Stol på din mavefornemmelse.

Ben Aston:

Det var virkelig nyttigt. Tak, Robin. Hvis du går til Robins indlæg på thedigitalprojectmanager.com, finder du ikke kun et eksempel på en statusrapport for en fiktiv kunde, Killikum Bucher – et fantastisk brandnavn, hvis nogen leder efter et ledigt domænenavn.

Der er også en eksempelstatusrapport, du kan bruge, samt en skabelon, du kan downloade. Gå ind og se den, og begynd at lave statusrapporter.

Så har vi gennemgået statusrapporter. Før vi slutter, Robin, ville jeg lige tale med dig om vores Kære DPM-sektion hos Digital Project Manager, som vi nu har drevet i næsten

Robin Reynolds:

Et par måneder.

Ben Aston:

Næsten seks måneder.

Robin Reynolds:

Wow, så længe?

Ben Aston:

Ja, næsten så længe. Vi har netop offentliggjort et nyt spørgsmål. Robin, du rådede nogen til at sige deres job op. Var det klogt?

Robin Reynolds:

Det gjorde jeg. Det lyder meget drastisk, når du formulerer det sådan, men personen skrev meget velformuleret om en ret belastende situation, hvor vedkommende havde det svært på arbejdet og ikke fik den støtte, ledelse eller vejledning, der var nødvendig for at udvikle sig i rollen.

Hvis man læser spørgsmålet, er det ret tydeligt, at personen bør søge en ny mulighed. Det var straks den retning, min mavefornemmelse gik i. Men man kan ikke bare sige sit job op og forsvinde. I mine stillinger kan man normalt ikke bare gøre det, og jeg har en familie. Jeg gav derfor nogle råd om, hvad personen kunne gøre i mellemtiden. Det handler om at kanalisere sin energi og frustration et andet sted hen, for eksempel i fitnesscenteret. Det handler også om ikke at engagere sig i forsøget på at løse situationen med en bestemt person på kontoret. Lad være med at forsøge at få dem til at samarbejde, hvis de ikke vil.

Og selvfølgelig gav jeg nogle råd om HR. Mens du leder efter din næste mulighed, skal du sørge for at skrive ned, hvornår disse situationer opstår, hvis der bliver behov for at eskalere sagen til HR.

Ben Aston:

Alvorlige sager. Det var vel ikke dig, der skrev ind, Robin?

Robin Reynolds:

Nej.

Ben Aston:

Du har netop fået et nyt job. Det er mistænkeligt.

Robin Reynolds:

Nej. Jeg føler, at jeg kan genkende mig selv i alle de spørgsmål, der kommer ind, så jeg ved ikke. Jeg kan …

Ben Aston:

Undskyld.

Robin Reynolds:

De handler alle sammen om mig.

Ben Aston:

Det hele handler om dig. Hvis du har et spørgsmål, du brænder efter at stille anonymt, så gå til ressourceafsnittet hos Digital Project Manager, hvor du finder en sektion, der hedder Kære DPM. Du finder den næsten øverst på siden, og der kan du stille alle de spørgsmål, du ønsker. Dit spørgsmål bliver måske udvalgt til at blive besvaret. Fortæl os, hvad du kæmper med, eller hvad du har brug for hjælp til, så vil vi meget gerne give dig nogle råd. Robin er fantastisk til den slags.

Robin, mange tak fordi du var med. Det har været dejligt at have dig med.

Robin Reynolds:

Tak, Ben. Det har været sjovt.

Ben Aston:

Hvis du vil bidrage til samtalen om statusrapporter eller stille et spørgsmål til Kære DPM, så gå til thedigitalprojectmanager.com og sørg også for, at du tilslutter dig vores Slack-team. Gå til ressourceafsnittet, hvor du finder mere end 1.000 andre projektledere, der taler om denne slags ting. Der foregår mange interessante samtaler, som du bør være en del af.

Ben Aston:

Tak fordi du lyttede med. Vi høres ved næste gang.