Hacks til projektledelse (med Natalie Semczuk)

Læs transskriptionen:

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

Ben Aston:

Hej alle sammen, og velkommen til den seneste udgave af podcasten Digital Project Manager. I dag har jeg Natalie med mig, og jeg er meget begejstret for den første af vores podcasts, hvor vi taler med de mennesker, som faktisk har skrevet noget af indholdet og artiklerne på siden.

Natalie har for nylig udgivet en artikel hos os på Digital Project Manager, Hacks til projektledelse, og alle elsker hacks. Hvis du kan lide hacks, udgav vi for et stykke tid siden en artikel om hacks til Slack, som blev enormt populær. Natalie har udarbejdet en liste med ti forskellige hacks, som hun har brugt gennem årene som digital projektleder. De spænder fra det meget praktiske til det mere filosofiske og handler også om, hvordan vi griber projektledelse an. Det vil vi tale om i dag.

Lad mig først give Natalie mulighed for at præsentere sig selv. Natalie, vil du ikke give os et overblik over, hvem du er, hvilken type projekter du arbejder med, og lidt om dig selv?

Natalie Semczuk:

Selvfølgelig, tak. Det er dejligt at være her. Jeg er freelance digital projektleder. Jeg arbejder hovedsageligt på afstand med små og mellemstore virksomheder, typisk inden for webdesign og -udvikling og nogle gange apps. Jeg arbejder med teams for at hjælpe dem med at få succes med deres projekter, jeg arbejder med projektkunder, og jeg rådgiver også om operationelle processer og om at gøre dit fjernteam endnu bedre.

Ben Aston:

Fedt. Vil du give os et hurtigt overblik over nogle af de projekter, du har arbejdet på for nylig, hvis du kan tale om dem? Hvilke typer projekter arbejder du med, og hvilken form for digital projektledelse beskæftiger du dig med? Er det mere strategisk, kampagnearbejde, marketingkampagner eller opbygning af websites? Hvilken slags digital projektleder er du?

Natalie Semczuk:

Det er som regel opbygning af websites eller mere omfattende webudvikling og den slags. Lige nu arbejder jeg på to aktive projekter. Det ene er en lille folkeskole, en privatskole, som opgraderer en stor del af deres backend-system. Det handler blandt andet om, hvordan de kategoriserer og sorterer elever. Jeg fører tilsyn med projektledelsen, udviklingsarbejdet samt genopbygningen og integrationen, der henter alle elevdata fra eksisterende systemer og placerer dem i en ret skræddersyet webløsning, hvor lærere kan logge ind og se deres elever, og forældre også kan logge ind og følge deres barns udvikling gennem året.

Jeg arbejder også på et ret ligetil webdesign- og genopbygningsprojekt, eller egentlig bare en websiteopbygning, for en lille startup med base i San Francisco, som har nogle spændende produkter på vej. Jeg tror ikke, jeg kan fortælle mere om det, men det er en af de typiske design- og udviklingsfaser med lidt strategi blandet ind i det. Det har været rigtig sjovt indtil videre.

Ben Aston:

Fedt. Godt. Lad os gå i dybden med dine ti hacks. Vi kommer nok ikke til at gennemgå hvert enkelt i detaljer, men kan du først give os et overblik over, hvordan du fandt frem til dem? Vi har nogle, der er ret handlingsorienterede og praktiske, og nogle, der virker mere filosofiske i forhold til, hvordan vi bør arbejde med projektledelse. Hvordan fandt du frem til disse hacks?

Natalie Semczuk:

Jeg tror, det er en blanding af at se, hvad andre projektledere har gjort, som jeg har arbejdet sammen med, se hvad der fungerede rigtig godt for dem og så erfaring. Meget kommer fra at arbejde på afstand, hvor man både har lidt mere og lidt mindre kontrol over sine omgivelser. Mindre kontrol over det team, man arbejder med, og mere kontrol over sit personlige miljø. Jeg tror, at vi som digitale projektledere alle bruger mange værktøjer, og at vi kommunikerer hele tiden. Det er en stor del af vores arbejde, og det er meget let at glemme detaljerne i at finjustere disse værktøjer og denne kommunikation, så de fungerer godt for os. På den måde bruger vi mindre tid på gentagne og kedelige ting og mere tid på det, vi faktisk har brug for at bruge tid på.

Ben Aston:

Fedt. Det er en god overgang til hack nummer et: “Automatisér dine projektledelsesværktøjer så meget som muligt.” Kan du fortælle os om de projektledelsesværktøjer, du kan lide at bruge, og hvordan du er kommet frem til at vælge dem?

Natalie Semczuk:

Selvfølgelig. Jeg bruger forskellige værktøjer afhængigt af den virksomhed, jeg arbejder med. Næsten altid Slack, Gmail eller Googles produktpakker. Når det gælder selve projektledelsesværktøjerne, har jeg brugt Basecamp 3 meget, Trello og en interessant blanding af de to, et værktøj der hedder Breeze.pm. Den slags typiske arbejdsgangsværktøjer samt en masse Slack og Google og de programmer.

Ben Aston:

Ja, fedt. I nogle af de automatiseringer, du talte om i din artikel, virker det, som om du har sat ting op, så du får beskeder, når folk gør bestemte ting, eller når bestemte ting sker, og så opstår magien. Kræver det, at hele dit team er enige og arbejder på samme måde? Hvordan har du fået dit team til at få det til at fungere for dig?

Natalie Semczuk:

Det meste af tiden, ja. Nogle af hacksene kan jeg styre fra min side. De er til min egen fordel, for eksempel beskeder og de værktøjer, jeg bruger, samt hvordan jeg modtager dem, om det er en ugentlig opsummering eller i realtid. Integrationerne mellem værktøjer, for eksempel GitHub og Slack eller Trello og Slack, kræver, at mit team følger en bestemt proces, fordi de bruger de pågældende værktøjer. Jeg synes, det er ret let at få selv det mest uorganiserede team til at forpligte sig til et arkiv eller lignende. Det er bestemt en fordel at have disse integrationer sat op, uanset hvilken proces der følges.

Ben Aston:

Fedt. Hvis folk kun skulle lave én automatisering, hvilken enkelt automatisering er så den, du hver dag takker dig selv for, når du ser den udføre sin magi?

Natalie Semczuk:

For mig er den bedste, at jeg bruger Slack som chatværktøj med næsten alle teams. Det er utrolig nyttigt at integrere det projektledelsesværktøj, jeg bruger på et projekt, i en Slack-kanal, fordi det giver mig oplysninger, for eksempel når nogen opdaterer en opgave, der er tildelt dem, markerer et problem på opgaven eller flytter opgaven til en kolonne for afsluttede opgaver. Det giver mig øjeblikkeligt indblik i, hvad der bliver gjort. Jeg behøver ikke logge ind i et andet program eller tjekke min e-mail. Jeg synes derfor, at den slags integration er den letteste automatisering at have. Når det er sagt, så elsker jeg at sende opsummeringer af oplysninger til min e-mail, hvis man ikke bruger den slags værktøjer. Det er rart at have ét sted, hvor man hurtigt kan se et overblik over alt, hvad der foregår, uden at skulle ind i seks forskellige programmer for at tjekke status på noget.

Ben Aston:

Godt. Har dine automatiseringer nogensinde fejlet katastrofalt, så du endte i en situation, hvor noget ikke skete, selv om det skulle?

Natalie Semczuk:

Ja, jeg tror, det kan gå begge veje, hvor integrationer som den slags fejler af den ene eller anden grund. Noget bliver opdateret, og jeg opdager det først for sent. Eller det modsatte sker: Integrationen fungerer så godt, at man bliver bombarderet med beskeder det ene sted, hvor man har samlet dem, hvilket bestemt ikke er ideelt.

Ben Aston:

Ja, fedt. Lad os gå videre til nummer to: “Brug en RACI-matrix på hvert projekt, du leder.” For dem, der ikke kender RACI, kan du så fortælle lidt om, hvad de er, og hvorfor du kan lide dem?

Natalie Semczuk:

Ja, jeg må indrømme, at jeg bruger dem lidt utraditionelt på mine projekter, men den grundlæggende idé er at skabe overblik over alle ansvarsområder, roller og ejerskaber i et projekt og gøre det meget tydeligt, hvilken person eller hvilket team der forventes at interagere på en bestemt måde og træffe beslutninger i projektet. Mange udarbejder dem ved projektopstarten. Jeg synes, det er en rigtig god måde at skabe klarhed på. Projektkunden har for eksempel ansvaret for at beslutte, hvilken type indhold deres team går videre med, men samtidig har vores team brug for indsigt i det på tværs af bestemte afdelinger. Det handler grundlæggende om at fordele de forskellige ansvarsområder mellem projektets involverede parter.

Ben Aston:

Fedt. I artiklen har du et eksempel på en RACI. Hvordan når du frem til beslutningen om, hvem der skal stå i hvilken kolonne? Hvem skal høres, hvem skal blot informeres, hvad betyder det at være informeret, og hvad betyder det at være ansvarlig?

Natalie Semczuk:

Jeg tror, det afhænger af projektet. Jeg følger som regel en tidligere praksis eller proces for de overordnede dele af et projekt. På tværs af forskellige faser eller milepæle er der normalt en typisk proces i bureauer, hvor man ved, at kunden skal involveres på et bestemt tidspunkt, og at design eller udvikling skal involveres på et andet. Man udpeger de vigtigste involverede personer og følger den proces, man allerede kender. Der er dog en hårfin grænse, hvor man som projektleder er nødt til at fastlægge det, hvis projektet er komplekst eller har mange interessenter. Man skal også skabe opbakning, hvis teamet arbejder mere samarbejdsorienteret, og I sammen beslutter, hvem der skal informeres, og hvem der er ansvarlig. Der kan selvfølgelig være overlap, men det er langt mere nyttigt at angive præcist, hvilken person der passer ind hvor.

Ben Aston:

Ja, helt sikkert. Noget, der ofte er udfordrende ved en RACI, er at vide, hvor mange detaljer man skal tage med. Hvor langt nedbryder du det? Gør du det efter faser, opgaver eller leverancer?

Natalie Semczuk:

På små projekter vil jeg helt sikkert basere det på faser og større leverancer. På større projekter, som er mere komplekse, varer længere eller involverer flere mennesker, kan ordet “stort” betyde mange ting. Jeg kan godt lide at bryde det mere detaljeret ned, men jeg kan også godt lide idéen om at bruge en RACI-matrix til ting, folk normalt ikke tænker på. For eksempel hvordan arbejdsgangen for indhold eller opdateringer skal se ud efter lanceringen. Det hjælper virkelig kunden eller interessenterne med at forstå arbejdsmængden og antallet af personer, der skal involveres. Det får alle på samme side og hjælper generelt med at styre forventningerne.

Ben Aston:

Godt. Lad os tage nummer tre: “Sig hej til dit team og dine kolleger hver dag.” Umiddelbart lyder det, som om man ikke siger hej til dem på arbejdet. Hvordan ser du det fungere på afstand sammenlignet med på et kontor, især når du bruger Slack så meget? Hvordan bygger du bro mellem virtuel og personlig kommunikation?

Natalie Semczuk:

Der er bestemt en balance. Det er svært at sige, hvor meget interaktion fra person til person der er bedst for et team. Når man arbejder på afstand, er interaktionen mere tvungen, hvis man deltager i et opkald eller videoopkald, fordi man ikke ser hinanden hver dag. Men jeg synes, det er så nyttigt at opbygge en god relation til folk og vise dem, at man ved, at de stadig er der. Jeg kan godt lide at variere det. Jeg sender en besked til teammedlemmer individuelt for at stille et bestemt spørgsmål, høre om de har en blokering eller bare spørge, hvordan de har det. Eller jeg skriver i kanalen og spørger projektgruppen som helhed: “Hej, hvordan går det med alle? Er der nogen problemer?”

Det er fantastisk at have den interaktion på en mere afslappet måde og ikke altid have et slutmål om at indhente oplysninger, få en status eller afklare noget. Det får folk til at slappe lidt mere af.

Ben Aston:

Godt. Nummer fire er: “Lær at sige nej til et projekt. På en venlig, men bestemt måde.” Fortæl lidt mere om det.

Natalie Semczuk:

At sige nej var bestemt noget, jeg havde svært ved som yngre projektleder. Det er svært, når man normalt arbejder med mennesker og gerne vil være venlig, men jeg ser det som noget, man gør for at beskytte sig selv, sit team og projektet. Det er vigtigt at lære, hvornår det er passende at sige nej eller gøre indsigelse, hvad enten det handler om ændringer i omfanget, at beskytte tiden på et projekt eller at afklare ting, så man ikke reagerer for hurtigt på en kunde, der beder om mere. Det kan være, at det ikke er det bedste valg, men måske mener kunden faktisk noget andet. Det er vigtigt at kunne sige nej på en eller anden måde til ønsker, der vil skabe problemer med stress, tid eller budget, og samtidig vide, hvordan man bedst håndterer situationen.

Ben Aston:

Kan du gennemgå en situation, hvor du var nødt til at sige nej, og hvordan du gjorde det på en måde, der holdt alle så tilfredse som muligt?

Natalie Semczuk:

Et trick er, at nej ikke altid er et direkte nej. For nylig arbejdede jeg med et team, hvor vores sprintforløb var blevet forskudt. Vi var nødt til at flytte alle vores demomøder, retrospektiver og planlægning. Jeg var nødt til at sige nej til et teammedlem. Vi diskuterede, om tidspunktet for et bestemt møde skulle ligge den ene eller den anden dag. Jeg pressede på for ikke at have vigtige møder om mandagen, fordi det er en rodet dag at holde møder på. Alle vender tilbage efter weekenden og skal lige lande, men han var overbevist om, at mandag var den bedste dag.

Jeg sagde: “Hør, jeg forstår, at det er et team på ti personer. Du er én person, og jeg tror ikke, det vil påvirke dig negativt. Men jeg forstår godt din bekymring. Det er bare nødt til at ske tirsdag. Jeg genovervejer det, hvis det ikke ser ud til at fungere de næste par uger, men efter min vurdering er det den bedste beslutning, og vi er nødt til at gå videre med den, så vi kan fortsætte vores arbejde.”

Det var et blødt nej. Jeg havde overvejet det, og i denne konkrete situation vidste jeg, hvad der var bedst for teamet. Det var dog vigtigt at erkende, at yderligere diskussion ikke ville fungere for nogen af os.

Ben Aston:

Ja. Bestemt, men retfærdigt.

Natalie Semczuk:

Ja, jeg prøver.

Ben Aston:

Jeg tror, det nogle gange er nødvendigt som projektleder at kunne sige til sit team: “Det her er spillereglerne og rammerne, vi arbejder inden for.” Når det gælder at sige nej til en kunde, kan det være, når kunden forsøger at udvide projektets omfang, tilføje unødvendige ekstra funktioner, fremrykke deadline eller skære omkostningerne ned. Hvilke teknikker bruger du, når du håndterer det med en kunde og samtidig forsøger at bevare relationen og holde projektet på sporet?

Natalie Semczuk:

Jeg forsøger virkelig at omdirigere samtalen og forstå, hvor kunden kommer fra. Uddannelse kommer man langt med. Hvis kunden for eksempel vil fremrykke en deadline, er det vigtigt at forklare konsekvenserne: Omkostningerne kan stige betydeligt, funktioner kan blive skåret væk, og kvaliteten bliver måske ikke den samme. Man skal også tydeliggøre grænsen. Jeg vil sige nej, forklare hvorfor og for eksempel sige: “Vi kan ikke fremrykke deadlinen så meget, fordi det vil kompromittere kvaliteten. Som virksomhed arbejder vi inden for et bestemt kvalitetsniveau, og vi mener ikke, at dette vil leve op til det.”

Eller: “Med alt det, vi har på vores bord lige nu, er vi nødt til at reducere funktionaliteten, men den reduktion, der kræves for at nå den deadline, vil faktisk gøre websitet ubrugeligt. Derfor kan vi ikke nå det.” Man skal være forholdsvis bestemt. Jeg bryder mig ikke om at efterlade en smutvej eller undskylde så meget, at det kan forhandles til: “Hvis vi bare gør dette, kan vi nå det.” Man skal være bestemt, informerende og samtidig forstå konsekvenserne af beslutningen.

Ben Aston:

Ja. Når vi siger nej, er det vigtigt at være helt tydelige. En udfordring kan være, at vi forsøger at sige nej, men bruger formuleringer som “Vi tror ikke, vi vil kunne nå det”, “Vi kan måske ikke nå deadlinen” eller “Jeg er ikke sikker på, om vi kan inkludere det”. Hvis sproget ikke er klart, eller hvis man ikke følger op med “Bare for at bekræfte det: Vi vil ikke kunne nå den deadline, I har bedt om”, kan det skabe uklarhed.

Det er derfor vigtigt med et klart sprog omkring nej. Det er også vigtigt at give muligheder. Vi vil så vidt muligt give kunderne mulighed for selv at træffe den rigtige beslutning i stedet for at presse dem op i en krog. Kunder vil gerne føle, at de har kontrollen, så giv dem valg: “I kan vælge mulighed A eller B. Mulighed B tager længere tid og koster flere penge, men kvaliteten bliver bedre, eller I får det, I ønsker. Her er nogle muligheder; jeg siger ikke bare nej.” Det kan virkelig hjælpe at give dem en følelse af valgfrihed.

Natalie Semczuk:

Ja, det er jeg helt enig i.

Ben Aston:

Det næste er: “Se dine projekter som læringsmuligheder.” Hvad har du lært for nylig?

Natalie Semczuk:

Jeg har lært mere om udvikling. Jeg har arbejdet på nogle udviklingstunge projekter, og det har været fantastisk at se noget, jeg ikke forstår fuldt ud, og bruge tid på at bede mit team om at forklare det bedre, når de har mulighed for det. Fordelen er, at jeg forstår det bedre fra et projektledelsesperspektiv, og måske kan dele det med dem, hvis der er noget, de kunne have interesse i at lære. Jeg kan også uddanne kunden mere, når jeg fortæller om disse ting, og det er altid vigtigt.

Jeg kan også godt lide at lære om mine kunders virksomheder, deres tankegang og deres strategier. På hvert projekt, jeg har arbejdet på, især fordi jeg arbejder med webudvikling, er der meget at lære kunderne om nettet. Det handler om at forstå, hvordan de bruger websites, hvordan de opdaterer dem, og hvilke problemer de oplever, når de besøger et website. Det er nærmest indbygget brugeroplevelsesresearch. Projekter er også et godt tidspunkt at afprøve nye teknikker eller kommunikationsmønstre og justere det, man har gjort før, for at se, om det gør en forskel.

Ben Aston:

Du talte i din artikel om retrospektiver og om at bruge dem som læringsmuligheder. Hvordan bruger du retrospektiver med dit team, og hvordan skaber du faktisk forandring som følge af et møde?

Natalie Semczuk:

Selve processen med at holde et retrospektiv er sund for et team. Jeg har været på projekter, hvor der foregik meget brok og frustration bag kulisserne, og hver gang kom det fra et grundlæggende problem i selve projektet, kunden, processen eller måden, projektet eller teamet blev ledet på. Man lærer altid noget af den slags. Ved at tage det med ind i et retrospektiv kan man både se tilbage på det, der var vanskeligt, og det, der fungerede. Det er nyttigt at få det hele frem, fordi man ikke nødvendigvis spontant siger: “Denne proces var fantastisk.” Når noget ikke fungerer, har vi en tendens til at brokke os eller gå rundt med frustrationerne i hovedet.

Jeg kan godt lide at dokumentere de vigtigste punkter og konklusioner, mens vi taler. Fordi jeg arbejder på afstand, deler jeg typisk min skærm og tager noter, mens vi taler. Det kan gøres ved en tavle, hvis man er fysisk sammen. Jeg kan godt lide, at vi alle bliver enige om én eller to ting, der skal forbedres fremover. Det hjælper at skabe bevidsthed om problemet og om, hvad vi ønsker at forbedre.

Ben Aston:

Godt. Det næste er: “Tag kontrol over dine beskeder.” Hvilke beskeder finder du mest og mindst nyttige, når du beslutter, hvad du skal slå fra?

Natalie Semczuk:

Generelt stresser ulæste beskeder eller det røde mærke mig. Jeg vil altid rydde dem væk, håndtere dem og læse dem, men hvis jeg læser dem uden at gøre noget ved dem med det samme, glemmer jeg dem. Derfor slår jeg næsten alt fra, der giver mig en ulæst besked, hvis det ikke er direkte relateret til mit projekt eller en direkte besked. Jeg lader altid beskeder fra personer være slået til, fordi det er vigtigt, at fjernteams kan få fat i mig privat. Jeg slår beskeder fra tom snak eller bots fra, afhængigt af værktøjet.

Jeg bruger også filtre og filtre for ulæste beskeder i Gmail, så jeg ikke straks ser alt, der er ulæst, men i stedet får en opsummering af, hvad der er sket på Basecamp den dag. Det har hjulpet mig meget at vide, hvad der udløser min reaktive adfærd, og håndtere det.

Ben Aston:

Det næste er: “Uddan så meget som muligt.” Fortæl lidt om, hvordan du lærer og udvikler dig som digital projektleder i øjeblikket, og hvad andre måske kan få gavn af.

Natalie Semczuk:

Jeg ved, at jeg altid har sagt til juniorer, at de skal være tydelige om det, de ikke ved. Man skal være ærlig om, hvad man ikke ved, og hvad man skal undersøge sammen med teamet. Det handler ikke kun om personlig udvikling. Når jeg ikke forstår noget, mit team arbejder med eller taler om, skal jeg selvfølgelig ikke være ekspert i alt. Det er derfor, der er et projektteam. De udfører arbejdet, ved hvordan det skal gøres og er eksperter.

Hvis der er noget, jeg er særligt nysgerrig på, eller som ofte forvirrer mig, for eksempel udvikling, DNS, hosting og servere, er jeg typisk den, der på kundesiden beskriver, hvad vi har brug for, hvilken information vi skal bruge fra kunden, og hvad problemet er, hvis der opstår et problem. Det var meget nyttigt for mig at forstå, hvordan tingene ser ud på backend, hvad begreberne betyder, og hvordan det hele hænger sammen, fordi det gav mig kontekst og en ramme til at tale med kunden om det.

Ben Aston:

Er der websites, blogs eller andet, du læser i øjeblikket, som du finder nyttigt?

Natalie Semczuk:

Jeg googler som regel ting. Jeg kan også godt lide at lytte til podcasts uden for mit specifikke fokusområde, for eksempel om design eller indholdsstrategi. Der findes mange podcasts om frontend og backend, og det hjælper mig med at føle mig mere fortrolig med terminologien og forstå, hvad der foregår.

Ben Aston:

Som digitale projektledere forsøger vi ikke bare at administrere et projekt, men at lede det. For at lede effektivt skal vi vide mere end blot, hvordan man administrerer et projekt. Vi skal udvikle ekspertise inden for strategi, UX, design, udvikling, kvalitetssikring og de fremskridt, der sker inden for de forskellige discipliner. Det gør os i stand til at sikre, at teamet anvender dem i projektet, og det giver os mulighed for at lede projekterne mere effektivt, fordi vi har en bedre forståelse af, hvad folk gør, eller hvad de bør gøre. Det næste punkt på din liste er nummer ti: “Notér altid tallene.” Hvilke tal er vigtige for dig i et projekt?

Natalie Semczuk:

Jeg arbejder hovedsageligt med teams, der fakturerer efter tid og materialer, så det er vigtigt at hente tidsrapporter. Ikke bare for at forstå, hvor budgettet bliver brugt, eller hvor mange timer der bruges, men også fordi jeg godt kan lide at læse beskrivelserne i tidsregistreringerne. De kan vise, hvor der er en blokering, et læringspunkt eller et samarbejde, jeg ikke kendte til. Især fordi jeg ikke sidder på et kontor, ser jeg ikke altid, hvordan folk interagerer.

Det er vigtigt at vide, hvordan folk bruger deres tid, ikke for at dømme dem, men for at forstå, hvad der foregår. Det giver indsigt i kommunikation, arbejde og ting, der sker på et projekt, som man måske kan hjælpe med eller lære af. Jeg tjekker regelmæssigt de projektledelsesværktøjer, jeg bruger, for at se, om der foregår andre samtaler, om jeg skal involveres, og hvor mange opgaver der er afsluttet, blokeret eller gået i stå.

Det er også vigtigt at forstå bemandingen på projekterne, hvor mange timer folk arbejder eller forventes at arbejde om ugen, og hvornår de holder ferie. Alle disse tal indgår i det samlede budget, tidsplanen, projektets fremdrift og alt det arbejde, der bliver lagt i projektet.

Ben Aston:

Der var en kommentar på dit indlæg fra en person, der skifter fra en rolle som kundeansvarlig til projektleder i et marketingbureau uden meget struktur omkring rollerne. Har du anbefalinger til, hvordan man bedst rapporterer på et timebudget? Regneark eller værktøjer, du vil anbefale?

Natalie Semczuk:

De fleste teams, jeg har arbejdet med, bruger Harvest eller lignende tidsregistreringsværktøjer, hvor teamet registrerer deres tid hver dag eller på hvert projekt, og hvorfra jeg kan hente rapporter. Jeg kan hente daglige, månedlige eller ugentlige rapporter. Det vigtige er at forstå, hvordan teamet fordeler og registrerer deres timer, og derefter opbygge et system. Hvis jeg rapporterer til en kunde, kan man i Harvest og mange andre værktøjer eksportere til en CSV-fil, et Excel-regneark eller et Google Drev-regneark. Så kan jeg rydde op i posterne og opsummere dem, hvis kunden har brug for en detaljeret oversigt.

Hvis det er en rapport til kunden eller mit team, kan jeg også selv hente tallene fra det sted, hvor de registreres, og rapportere dem mundtligt eller i en e-mail.

Ben Aston:

Hvordan afstemmer du så tallene? Folk udfører arbejdet og registrerer timerne, men hvordan ved du, om du er på rette spor? Hvor ofte skal timerne afstemmes med estimatet?

Natalie Semczuk:

Jeg gør det som regel ugentligt. Hvis det er en meget travl uge, tjekker jeg flere gange om ugen i det værktøj, der bruges. Jeg har også arbejdet på projekter, hvor tiden ikke registreres så detaljeret. I de tilfælde sørger jeg for, at fordelingen af folks dage i værktøjet stemmer overens med det, de arbejdede på den pågældende uge, baseret på det, jeg hører i projektlederrapporten.

For at afstemme timerne henter jeg en ugentlig eller halvugentlig rapport, hvis der er travlt, sikrer mig, at al tid er registreret, og sammenholder den med estimatet eller budgettet. Jeg ser også på tid, der er afsat til interne aktiviteter, uddannelse eller læring. På den måde får jeg et ugentligt overblik, og det er typisk også sådan, jeg opdaterer kunderne om deres projekter. Det giver mig en god fornemmelse af, hvor langt vi er, og det ændrer sig normalt ikke voldsomt, når jeg kun ser på tallene ugentligt.

Ben Aston:

Tak, Natalie, fordi du ville være med. Det har været virkelig nyttigt at forstå lidt mere om den måde, du arbejder på, og nogle af de hacks, du har samlet, så vi alle kan lære af dem. Hvis du lytter til podcasten og gerne vil bidrage til samtalen, vil vi meget gerne have, at du deler dine tanker som kommentarer til Natalies indlæg på thedigitalprojectmanager.com. Vi har også et Slack-team. Hvis du klikker på fællesskabssektionen på Digital Project Manager-websitet, kan du tilmelde dig Slack og fortsætte samtalen der.

Tak, Natalie, fordi du ville være med. Vi glæder os til endnu en podcast med dig snart. Det har været fantastisk at have dig med.

Natalie Semczuk:

Tusind tak.