Gjør statusrapportene dine nyttige (med Robyn Reynolds)

Les utskriften:

Vi prøver ut et program for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Takk for at du lytter. Jeg heter Ben Aston, og dette er podkasten Digital Project Manager. Denne podkasten presenteres av Clarizen, lederen innen programvare for styring av virksomhetsprosjekter og prosjektporteføljer. Besøk Clarizen.com for å lære mer. I dag har jeg med meg Robin Reynolds, en av våre faste DPM-eksperter hos Digital Project Manager og rådgiver for Kjære DPM, der vi svarer på spørsmål fra digitale prosjektledere. Robin, tusen takk for at du blir med igjen.

Robin Reynolds:

Hei, Ben. Jeg er så glad for å være tilbake. Jeg liker alltid å snakke med deg.

Ben Aston:

Så bra. Har du noen gang havnet i en vanskelig situasjon fordi du var ganske sikker på at du gjorde en god jobb med å holde kunden oppdatert om alt i prosjektet, men så rammet katastrofen prosjektet en dag, og alle e-postene, meldingene og tekstene som du trodde du hadde sendt kunden om prosjektet, så ut til å ha forsvunnet på magisk vis? Det, mine venner, er grunnen til at dere trenger en statusrapport. I dag skal vi altså snakke om disse fryktede statusrapportene. Er de virkelig nødvendige? Og hvis de er det, hva bør vi ta med i dem? Hvordan kan vi gjøre dem mindre plagsomme, og hva kan vi gjøre for å gjøre dem nyttige?

Hvis du ikke har møtt Robin ennå, skal jeg introdusere henne ordentlig. Robin bor like nede i veien fra meg – eller det liker jeg i hvert fall å tenke – og hun bor i Portland og liker emojier, lister og valper. Vi skal snakke mer om det om litt, men som en av DPM-ekspertene våre skal Robin også delta på det kommende kurset vårt, som heter Å mestre digital prosjektledelse. Hvis du ikke vet hva jeg snakker om og trenger opplæring i prosjektledelse, bør du sjekke det ut.

Det er et intensivkurs på sju uker som inkluderer interaktive videoøkter, ukentlige leksjoner, oppgaver, gruppediskusjoner og også muligheten for veiledningsøkter. Gå til digitalprojectmanagerschool.com og meld deg på. Vi har bare noen få plasser igjen.

Men Robin, du har nylig byttet jobb. Fortell meg om den nye jobben din.

Robin Reynolds:

Ja, jeg avslutter nettopp de første ukene mine i den såkalte nye jobben, og det har vært helt fantastisk. Nå jobber jeg for 10Up, og det vi egentlig gjør, er å bidra til å gjøre nettet bedre ved å lage nettsteder og verktøy for innholdsprodusenter med stor nøyaktighet.

Det som er morsomt med 10Up, er at alle jobber eksternt – 100 % av oss. Og vi jobber med blant andre AMC, NBC Universal og Time Inc.

Ben Aston:

Kult. Hvis alle jobber eksternt, hvilken tidssone jobber dere i? Er det bare Nord-Amerika, eller er det også andre land?

Robin Reynolds:

Heldigvis har vi en så god organisering at vi er fordelt på ulike grupper og team. Jeg er teknisk sett i et team som alle følger stillehavstid. Så har vi et europeisk team og så videre.

Noen dager har jeg kanskje et møte litt tidligere enn jeg skulle ønske, men det skjer ganske sjelden.

Ben Aston:

Kult. Får du mulighet til å bytte team hvis du tenker: «Vent litt, jeg vil dra til Europa om sommeren»? Kan du bytte team?

Robin Reynolds:

Vet du hva som er morsomt? En av teamlederne våre gjorde nettopp det. Nå er hun i Europa, har det kjempegøy og reiser rundt samtidig som hun leder teamet sitt.

Ben Aston:

Der har du det. Det høres ganske kult ut. Hvilke utfordringer har du egentlig møtt? Du har jo jobbet med ekstern prosjektledelse før, men har du jobbet i et miljø der alle er eksterne hele tiden? Har du funnet noen unike utfordringer med det?

Robin Reynolds:

Ja, jeg jobbet eksternt i den forrige jobben også, men det som er fantastisk med 10Up, er at de virkelig oppmuntrer alle til å jobbe innenfor sine egne tidssoner, og vi er store tilhengere av å bruke Zoom som videoløsning. Det er veldig bra når man jobber med kunder og knytter kontakt med teamet, fordi video er forventningen – det er ikke bare telefonen.

Ben Aston:

Det er ikke bare et valgfritt tillegg.

Robin Reynolds:

Nettopp, du har helt rett.

Ben Aston:

Og folk gjør faktisk det? Det fungerer?

Robin Reynolds:

Så langt, ja. Absolutt. Men jeg er fortsatt i startfasen og er den nye jenta. Akkurat nå prøver jeg å akseptere at jeg ikke kan alt, og jeg prøver virkelig å lære, lytte, bli kjent med teamene og kundene mine og bygge disse relasjonene.

Ben Aston:

Er det noe du har oppdaget etter at du gikk inn i den nye rollen, som du tenker: «Det må jeg virkelig bli bedre på»?

Robin Reynolds:

Jeg tror det handler om å eie det faktum at du har gjort denne jobben før. Når du begynner i en ny rolle, kommer det alltid litt bedragersyndrom, og du tenker: «Herregud, har jeg gjort dette før?» Og så er svaret: «Ja, selvfølgelig, det er bare et annet miljø.» Jeg tror derfor det handler om å bli tryggere på å ta eierskap til prosjektene dine.

Ben Aston:

Ja, jeg tror det er veldig riktig når man begynner et nytt sted. Plutselig tenker man: «Herregud, jeg vet ikke hvordan jeg gjør noe som helst her.» Hvordan gjør man …

Robin Reynolds:

Ja, som om jeg er den dummeste personen.

Ben Aston:

Jeg vet ikke hvordan jeg skal få ressurser til prosjektet mitt. Det er interessant. Hvordan gjør de det, hvordan foregår ressursplanleggingen? Hvilke verktøy bruker de?

Robin Reynolds:

Vi bruker en kombinasjon av 10 Thousand Feet og vårt eget planleggingsverktøy. Mellom de to fungerer alt bra, og jeg pleier å få ressursene jeg trenger til prosjektene mine. Vi gjør også mye fremtidsplanlegging flere måneder frem i tid, slik at vi kan unngå konflikter i god tid.

Ben Aston:

Det høres veldig voksent ut. Hvilke typer prosjekter jobber du faktisk med? Kan du fortelle om noen av dem?

Robin Reynolds:

Jeg kan ikke fortelle nøyaktig hvem kundene er, men jeg kan si at det er en blanding av avtaler om vedlikehold av nettsteder og fullstendig redesign og gjenoppbygging av nettsteder med WordPress.

Ben Aston:

Hyggelig. Så det er krevende? Det høres veldig generelt ut. WordPress-greier. Kult. La oss snakke om statusrapporter. Har du skrevet din første statusrapport hos 10Up ennå?

Robin Reynolds:

Det har jeg absolutt. Vi har vårt eget format og vår egen tilnærming, slik alle byråer, virksomheter og personer kan ha forskjellige måter å gjøre det på.

Ben Aston:

Hva er synet ditt? Du har nettopp skrevet en artikkel om statusrapporter, så overbevis oss. Hvorfor mener du at statusrapporter er verdt å lage?

Robin Reynolds:

La oss være ærlige, Ben. Ingen liker statusrapporter eller å lage dem. Det er ofte den verste delen av jobben, ikke sant? Det er ikke særlig glamorøst. Mange ser på det som: «Å, jeg må gjøre dette, men ingen kommer til å lese det.»

Men de er svært viktige. De beste prosjektstatusrapportene skaper ansvarlighet og eierskap i teamet. De håndterer problemer, reduserer risiko og sørger fremfor alt for at dere holder kursen mot prosjektmålene.

Ikke bare for de interne teamene, men særlig for kundene, skaper de verdi. De gir kundene trygghet om at pengene deres brukes til å levere prosjektet, og de kan få kunden til å se bra ut overfor sine ledere fordi rapporten kan videresendes til ulike interessenter.

Til slutt kan statusrapporter virkelig redde deg fordi du har et skriftlig spor hvis ting går galt. Du kan si: «Ja, vi eskalerte denne risikoen til deg, her er tiltakene våre, og her er hva vi har gjort for å rette den.» På den måten slipper du forhåpentligvis at noen sier: «Dette har vært på vei lenge, og vi glemte å snakke om det.»

Ben Aston:

Ja, jeg tror fristelsen når vi lager statusrapporter, kan være å si: «Jeg lar det bare ligge denne uken, for jeg tror ikke kunden leser dem uansett. Forrige uke sendte jeg rapporten og la inn en liten skjult beskjed om at jeg tror vi kommer til å gå over budsjettet. De sa ingenting. Nå som jeg sa det forrige uke, oppdaterer jeg dem ikke denne uken i tilfelle de faktisk leste den.»

Robin Reynolds:

«Jeg fortalte dem det, så nå er det over.»

Ben Aston:

Ja.

Robin Reynolds:

Det handler egentlig om å styre forventninger regelmessig.

Ben Aston:

Hva er det viktigste da? Mitt perspektiv på statusrapporter er at vi bør gjøre dem så enkle som mulig. Du vil ikke at dette skal ta to timer å oppdatere, og hvis du jobber med fire forskjellige kunder, kan det ta en hel dag bare å lage statusrapportene. Hva er det aller viktigste som må være med?

Robin Reynolds:

Jeg er helt enig med deg, Ben. Jo enklere en statusrapport er, desto bedre. Du kan bruke mye tid på disse tingene og gjøre dem om til prosjektplaner eller bare versjoner av prosjektplanen. Men det anbefaler jeg ikke. Det viktigste er prosjektnavn, kundenavn, prosjektvisjon eller sammendrag – det bør være én setning – og prosjektstatus. Dette er svært viktig. Det finnes mange måter å gjøre dette på i statusrapporten, og du kan lese mer om det i artikkelen. Den må absolutt inneholde timer eller hvordan prosjektet følges opp, og om dere holder planen når det gjelder tidslinje og budsjett.

Du bør også ta med hva som nylig er ferdigstilt i prosjektet. Jeg liker vanligvis å lenke til alle de nylig fullførte oppgavene og deretter sende dem til prosjektstyringsverktøyet hvis kunden har tilgang til det.

Under dette bør du ta med det du planlegger å fullføre neste gang. Det kan være den neste måneden eller den neste uken, men poenget er å gi kunden beskjed om kommende prioriteringer og hva dere skal ta tak i. Da kan kunden komme tilbake og si: «Dette er faktisk ikke en prioritet lenger», eller «La oss prioritere dette i stedet.»

Til slutt bør du ta med problemer og hindringer. Det er her du løfter frem mulige risikoer og forsøker å finne tiltak sammen med kunden under statusgjennomgangen.

Ben Aston:

Kult. Hvis dette er det viktigste, høres det fortsatt ut som mye.

Alt er selvfølgelig viktig. Kanskje en tredjedel er uendret fra uke til uke. Noen ting kommer ikke til å endre seg, men hvor mye detaljer er nok? Jeg liker det du sier om fullførte og kommende oppgaver og om å lenke til verktøyene, slik at rapporten bare blir et øyeblikksbilde som de kan gå dypere inn i hvis de ønsker. Men i beskrivelsene av hva som skjer og hvilke risikoer som finnes, hvor mye detaljer tar du med for å gjøre rapporten nyttig uten at det tar flere timer å ferdigstille den?

Robin Reynolds:

Jeg liker å sørge for at prosjektstatusrapportene mine ikke tar mer enn omtrent 20 minutter. Den første tar naturligvis litt lengre tid. Men som prosjektledere bruker vi også denne tiden til å reflektere over prosjektet og forsikre oss om at vi forstår hvor alt står.

Ofte lager jeg et førsteutkast tidlig om morgenen eller dagen før jeg skal sende rapporten, og tømmer hodet for ideer, tanker og notater. Så kommer jeg tilbake og redigerer bort alt overflødig, slik at rapporten blir svært konsis.

Kan du si det enklere? Kan du bare lenke til oppgaven? Og så diskuterer du den i en samtale. Du må sørge for at du ikke prøver å løse alle problemene i statusrapporten. Identifiser dem, henvis videre og diskuter.

Ben Aston:

Det er et godt poeng. Én måte å se statusrapporter på er at vi må lage dem fordi de er dokumentasjon kunden ber om, men aldri leser. Den andre måten å se det på er: «Dette er faktisk et viktig verktøy for oss når vi prøver å holde fingeren på prosjektets puls.»

Det å faktisk sette av tid hver uke til å gå grundig gjennom hva som skjer, revurdere risikoene, revurdere tiltakene mot risikoene, tenke på hva vi har gjort denne uken og hva vi må gjøre neste uke, og ligge ett skritt foran teamet, er en nyttig øvelse i den løpende prosjektplanleggingen vi trenger for å holde prosjektene på rett spor og vite hvor de står.

Ellers kan prosjektet bare gå sin gang, og vi kan glemme å se helheten i hvor prosjektet er på vei. Opplever du det også?

Robin Reynolds:

Absolutt. Hvis vi tenker på RACI, er prosjektlederne ansvarlige for å lage statusrapporten. Men teamet og kundene våre er ansvarlige for å holde seg informert, lese rapporten, løfte spørsmål og be om avklaringer basert på den.

Ben Aston:

Helt klart. Hva slags metode bruker dere hos 10Up? Er det mer fossefallsbasert, eller kjører dere sprinter og jobber mer agilt?

Robin Reynolds:

Vi bruker en kombinasjon av begge deler. Det avhenger av prosjektet. Vi er ikke bundet til den ene eller den andre.

Ben Aston:

Jeg tror en av fristelsene i mer agile prosjekter med sprinter kan være å tenke: «Vi trenger ikke statusrapporter, for alle vet jo hva som skjer.»

Men det er forskjell på at folk er engasjert i prosjektet og vet hva som skjer fra dag til dag, og det å stoppe opp og spørre: «Vet dere hvor mange timer vi har igjen? Vet dere hvor budsjettet står? Vet dere hvor mye som gjenstår?»

Robin Reynolds:

Nettopp.

Ben Aston:

Scrum er flott når man gjennomgår for eksempel et burndown-diagram, men det å gi kunden all informasjonen og samle alle prosjektdetaljene på én eller to sider er en svært nyttig øvelse, selv når man driver agile prosjekter.

Robin Reynolds:

Absolutt. Kunden kan også dele rapporten med lederen sin eller andre viktige ledere og interessenter som potensielt kan tilføre virksomheten mer penger.

Ben Aston:

Alltid nyttig. Lag statusrapportene deres!

Hva gjør du med statusrapporten når den er ferdig? Sender du den i en e-post? Fristelsen kan være å gjøre den ferdig fredag klokken fire og tenke: «Jeg legger den bare ved en e-post og forsvinner. Jeg sender den til kunden og håper på det beste.»

Hva gjør du med statusrapportene etter at du har laget dem?

Robin Reynolds:

For det første prøver jeg å ikke sende dem fredag ettermiddag, for da er det nesten garantert at ingen leser dem. Jeg er ikke særlig motivert for å få en viktig e-post fredag ettermiddag. Da har jeg på en måte tatt helg, og mandag morgen virker det ikke særlig hyggelig å starte dagen med den.

Jeg liker vanligvis å sende statusrapportene midt i uken. Kanskje har jeg et internt møte på tirsdag, lager utkastet til den kundevendte statusrapporten og sender den onsdag. Når jeg sender rapporten, liker jeg vanligvis å presentere den i et statusmøte med kunden eller teamet.

Jeg sender rapporten enten før samtalen eller under samtalen, deler skjermen og går gjennom alt sammen med dem. Deretter følger jeg opp med utsendelsen og handlingspunktene etter rapporten.

Poenget er ikke å være der sammen med kunden og lese rapporten høyt. Den fungerer heller som en ramme for dialogen. Du kan si: «Dette gjorde vi, og det var veldig bra. Dette skal vi gjøre videre, og her står vi med tidsplanen. La oss snakke om dette – det ser ut som vi ligger foran planen.»

Ben Aston:

Har det skjedd med deg?

Robin Reynolds:

I teorien.

Ben Aston:

Hyggelig. Det er gode råd. Jeg liker ideen om å dele skjerm og styre hva kunden får se, i stedet for bare å sende rapporten og håpe at kunden ser på den delen du vil at de skal se.

Fra mitt perspektiv jobber du tydeligvis mer med ekstern prosjektledelse. Jeg jobber vanligvis ikke med ekstern prosjektledelse. For meg er statusmøtet en mulighet til å være sammen med kundene og bygge relasjonen. Det handler ikke bare om å dele informasjon og avstemme hvor prosjektet står, men også om å snakke litt om ting utenfor prosjektet, slik at man bygger tillit og vennskap. Da har man noe å støtte seg på når man skal dele dårlige nyheter.

Det er kanskje vanskeligere når man jobber eksternt. Hvordan bygger du relasjoner med kunder når du jobber eksternt?

Robin Reynolds:

Hvis du har videoen på, kan dere se hverandre, og det skjer mye gjennom kroppsspråk. Dere snakker fortsatt om de samme tingene. Vi spør fortsatt hva de gjorde i helgen og så videre.

Jeg tror derfor det er like effektivt. Men du fikk meg også til å huske at jeg pleide å ha interne statusmøter med teamet mitt, og jeg skrev faktisk ut statusrapporten til dem. I ettertid virker det ganske ekstremt.

Men jeg lærte av teamet mitt at det var den eneste måten jeg kunne få dem til å lese den på: ved å legge den foran dem og gå gjennom den sammen.

Ben Aston:

Ja.

Robin Reynolds:

Det finnes altså ingen riktig eller perfekt måte å gjøre det på. Det finnes noen få gale måter. Det er viktig å forstå hva kunden foretrekker og tilpasse seg det, på samme måte som med det interne teamet.

Ben Aston:

Har du noen tips til hvordan man kan sørge for at kunden faktisk leser statusrapportene? Har du funnet noe som fungerer?

Robin Reynolds:

Statusmøtet er definitivt viktig. Det andre jeg har lært, er at du aldri må hoppe over en statusrapport. Når du først gjør det, er det litt som en dårlig restaurantanmeldelse. Du kan ha én dårlig anmeldelse, men trenger kanskje sju gode anmeldelser for å rette opp inntrykket. Kunden vil alltid huske at du hoppet over den ene uken.

Ben Aston:

Ja.

Robin Reynolds:

Sørg for at du alltid er i tide, er forberedt, og at statusrapporten faktisk inneholder noe. Den bør gjenspeile arbeidet dere gjør, så ikke stress den ut. Sørg for at den er fri for feil. Ikke heng ut noen for dårlig arbeid i rapporten, og sørg for at den har substans.

Ben Aston:

En ting du nevnte, var å tilpasse rapporten til kunden. Du skal gjøre den nyttig for dem og gi dem informasjonen de trenger. Men jeg har havnet i situasjoner der kunden går helt av skaftet og ber om alle mulige detaljer i statusrapporten.

Det gjelder særlig når man jobber med et prosjekt basert på tid og materialer, og kunden ønsker en oversikt over hver time hver person har jobbet med prosjektet og hvordan hvert eneste minutt ble brukt. Det var svært tungvint å lage, fordi man også må redigere alles kommentarer. Hva mener du om hvor mye man bør tilpasse rapporten til kunden? Når blir det for detaljert?

Robin Reynolds:

Jeg sitter her og nikker, for jeg har vært der også, Ben. Ofte må du følge magefølelsen. Hvis det for eksempel er en liten tid- og materialavtale og det ikke er effektivt å spore alle timer og oppgaver, samle dem og gjøre masse komplisert regnearkarbeid, må du forklare kunden hvorfor.

Hvis kunden fortsatt insisterer, kan det for eksempel være forretningsmessige grunner til at de må følge opp på den måten. Da må du kanskje samarbeide med dem om å øke finansieringen. Alternativet er at vi ikke får gjort like mange oppgaver fordi vi må bruke tiden på rapporten i stedet for på selve prosjektarbeidet.

Ben Aston:

Det er gode råd. Hvis kunden ønsker at noe skal gjøres, er det arbeid å lage statusrapporter, selv om kunder kanskje ikke liker å se det slik. Jeg har faktisk jobbet for kunder som på en eller annen måte hadde skrevet inn i kontrakten at de ikke betalte for produksjon av statusrapporter, noe som er sprøtt. Men kundene må forstå at hvis vi skal lage mange detaljer i statusrapportene og all denne ekstra rapporteringen, som egentlig ikke er nødvendig for å levere prosjektet godt, bør de betale for det. Det bør være en endringsforespørsel hvis de begynner å be om mer detaljer, eller så må vi si at noe annet må tas ut av omfanget.

Ellers spiser det raskt opp budsjettet vårt.

Robin Reynolds:

Absolutt. Jeg vil bare legge til at du alltid bør be kunden og teamet om tilbakemeldinger på statusrapportene. Noen ganger kan jeg legge frem noe i malformatet mitt og synes at det gir fullstendig mening, mens ingeniørene mine kanskje sier: «Jeg forstår ikke hvorfor du har formulert det slik», eller «Hvorfor har du med denne delen?»

Ben Aston:

Ja.

Robin Reynolds:

Eller: «Kan du ta med dette i stedet?» Du bør altså tilpasse rapporten, men ikke på en svært ineffektiv måte. Stol på magefølelsen.

Ben Aston:

Kult. Dette var veldig nyttig. Takk, Robin. Hvis du går til Robins innlegg på thedigitalprojectmanager.com, finner du ikke bare et eksempel på en statusrapport for en fiktiv kunde, tror jeg, Killikum Bucher. Det er for øvrig et flott merkenavn hvis noen ønsker å kjøpe domenet.

Det finnes også en eksempelrapport du kan se på, og vi har inkludert en mal du kan laste ned. Sjekk den ut og begynn å lage statusrapporter.

Da har vi gått gjennom statusrapporter. Før vi avslutter, Robin, vil jeg snakke litt med deg om delen Kjære DPM hos Digital Project Manager, som vi nå har drevet i, hva er det, nesten

Robin Reynolds:

Noen måneder.

Ben Aston:

Nesten seks måneder.

Robin Reynolds:

Oi, så lenge?

Ben Aston:

Nesten så lenge, og vi har nettopp publisert et nytt spørsmål. Robin, du ba noen om å slutte i jobben sin. Var det klokt?

Robin Reynolds:

Det gjorde jeg. Det høres veldig ekstremt ut når du formulerer det slik, men personen som skrev inn, beskrev på en svært velformulert måte en ganske belastende situasjon. Personen slet på jobb og fikk ikke støtten, ledelsen eller veiledningen som var nødvendig for å utvikle seg i rollen.

Hvis noen leser spørsmålet, blir det ganske åpenbart at personen bør se etter en ny mulighet. Det var umiddelbart dit magefølelsen min gikk. Men du kan ikke bare si opp og forsvinne. I mine jobber har det vanligvis ikke vært mulig, for jeg har familie. Jeg ga derfor noen råd om hva personen kunne gjøre i mellomtiden. Det handler om å kanalisere energien og frustrasjonen andre steder, gå på treningssenteret og slutte å prøve å løse situasjonen med en bestemt person på kontoret. Slutt å prøve å få noen til å samarbeide når de ikke kommer til å gjøre det.

Og selvfølgelig ga jeg noen råd om HR. Mens du ser etter neste mulighet, bør du skrive ned når disse hendelsene skjer, i tilfelle saken må eskaleres til HR.

Ben Aston:

Alvorlige saker. Var det du som skrev inn, Robin?

Robin Reynolds:

Nei.

Ben Aston:

Du har nettopp fått ny jobb. Det er mistenkelig.

Robin Reynolds:

Nei. Jeg føler at jeg kan kjenne meg igjen i hvert eneste spørsmål som kommer inn, så jeg vet ikke. Jeg kan …

Ben Aston:

Beklager.

Robin Reynolds:

Alle handler om meg.

Ben Aston:

Dette handler alt sammen om deg. Hvis du har et spørsmål du virkelig ønsker å stille, og vil stille det anonymt, kan du gå til ressursdelen på Digital Project Manager. Der finner du en del som heter Kjære DPM. Den ligger nær toppen av siden, og der kan du stille akkurat de spørsmålene du ønsker. Spørsmålet ditt kan bli valgt ut og besvart. Still oss et spørsmål, fortell hva du strever med eller hva du trenger hjelp til, så hjelper vi deg gjerne. Robin er svært flink til å gi råd.

Robin, tusen takk for at du ble med. Det har vært flott å ha deg her.

Robin Reynolds:

Å, takk, Ben. Dette var morsomt.

Ben Aston:

Hvis du vil bidra til samtalen om statusrapporter, eller stille et spørsmål til Kjære DPM, kan du gå til thedigitalprojectmanager.com. Husk også å bli med i Slack-teamet vårt. Gå til ressursdelen, så finner du mer enn 1 000 andre prosjektledere som snakker om slike ting. Det foregår mange interessante samtaler der som du bør delta i.

Ben Aston:

Takk for at du lyttet. Vi høres neste gang.