Tips og triks for prosjektledelse (med Natalie Semczuk)

Les transkripsjonen:

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

Ben Aston:

Hei alle sammen, og velkommen til denne nyeste episoden av Digital Project Manager-podkasten. I dag har jeg Natalie med meg, og jeg er veldig glad for å gjøre den første av podkastene våre der vi skal snakke med personene som faktisk har skrevet noe av innholdet og artiklene på nettstedet.

Natalie publiserte nylig en artikkel hos oss på Digital Project Manager, Tips og triks for prosjektledelse, og alle elsker tips og triks. Hvis du liker tips og triks, publiserte vi for en stund siden en artikkel om tips og triks for Slack som ble svært populær. Natalie har laget en liste med ti ulike tips og triks som hun har brukt gjennom årene som digital prosjektleder. De spenner fra det svært praktiske til det mer filosofiske, og handler også om hvordan vi tilnærmer oss prosjektledelse. Det skal vi snakke om i dag.

La meg først la Natalie introdusere seg selv. Natalie, hvorfor gir du oss ikke en oversikt over hvem du er, hva slags prosjekter du jobber med, og litt om deg?

Natalie Semczuk:

Selvfølgelig, takk. Det er flott å være her. Jeg er frilansende digital prosjektleder. Jeg jobber for det meste eksternt med små og mellomstore virksomheter, vanligvis innen webdesign og -utvikling, og av og til med apper. Jeg jobber med team for å hjelpe dem med å lykkes med prosjektene sine, jeg jobber med prosjektkunder, og jeg gir også råd om operative prosesser og hvordan du kan gjøre det eksterne teamet ditt enda bedre.

Ben Aston:

Flott. Vil du gi oss en rask oversikt over noen av prosjektene du har jobbet med i det siste, hvis du kan snakke om dem? Hva slags prosjekter jobber du med, og hva slags digital prosjektledelse driver du med? Er det mer strategisk, eller handler det om kampanjer, markedsføringskampanjer eller utvikling av nettsteder? Hva slags type digital prosjektleder er du?

Natalie Semczuk:

Det handler vanligvis mer om utvikling av nettsteder eller mer omfattende webutvikling og lignende. Akkurat nå jobber jeg med to aktive prosjekter. Det ene er en liten barneskole, en privatskole, som oppgraderer mye av systemet på baksiden. Det gjelder blant annet hvordan de klassifiserer og sorterer elever. Jeg har ansvar for prosjektledelsen, utviklingsarbeidet samt gjenoppbyggingen og integrasjonen som henter alle elevdataene fra eksisterende systemer og legger dem inn i en ganske spesialtilpasset nettsteds løsning, der lærerne kan logge inn og se elevene sine, og foreldrene også kan logge inn og følge elevens utvikling gjennom året.

Jeg jobber også med et ganske enkelt nettsteddesign og en gjenoppbygging, eller en generell utvikling, for en liten oppstartsbedrift basert i San Francisco med noen spennende produkter på vei. Jeg tror ikke jeg kan si mer om det, men det er en av de typiske design- og utviklingsfasene, med litt strategi blandet inn. Det har vært veldig morsomt så langt.

Ben Aston:

Flott. Bra saker. Ja, la oss gå i dybden på de ti tipsene og triksene dine. Vi kommer sannsynligvis ikke til å gå gjennom hvert enkelt i detalj, men kan du først gi oss en oversikt over hvordan du kom frem til disse? Vi har noen som er ganske gjennomføringsorienterte og praktiske, og noen som virker mer filosofiske når det gjelder hvordan vi bør drive prosjektledelse. Hvordan kom du frem til disse tipsene og triksene?

Natalie Semczuk:

Jeg tror det er en blanding av å se hva andre prosjektledere har gjort, som jeg har jobbet med, se hva som fungerte veldig godt for dem, og erfaring. Mye kommer fra å jobbe eksternt, der du både har litt mer og litt mindre kontroll over omgivelsene dine. Mindre kontroll over teamet du jobber med, men mer kontroll over ditt personlige miljø. Jeg tror vi som digitale prosjektledere bruker mange verktøy, og vi kommuniserer hele tiden. Det er en stor del av jobben vår, og det kan være lett å glemme detaljene ved å forbedre disse verktøyene og denne kommunikasjonen slik at de fungerer godt for oss. På den måten bruker vi mindre tid på det repetitive og kjedelige, og mer tid på det vi faktisk trenger å bruke tid på.

Ben Aston:

Flott. Det leder fint over til tips nummer én: «Automatiser prosjektstyringsverktøyene dine så mye som mulig.» Kan du fortelle oss litt om prosjektstyringsverktøyene du liker å bruke, og hvordan du har kommet frem til å velge disse verktøyene?

Natalie Semczuk:

Selvfølgelig. Jeg bruker en rekke ulike verktøy, avhengig av hvilket selskap jeg jobber med. Nesten alltid Slack, Gmail eller Googles produktpakker. Når det gjelder selve prosjektstyringsverktøyene, har jeg brukt Basecamp 3 mye, Trello og en interessant blanding av de to, et verktøy som heter Breeze.pm. Slike typiske arbeidsflytverktøy, samt mye Slack og Google og de programmene.

Ben Aston:

Ja, flott. I noen av automatiseringene du snakket om i artikkelen din, virker det som om du har satt opp ting slik at du får varsler når folk gjør bestemte ting eller når bestemte ting skjer, og så skjer magien. Krever det at hele teamet ditt er på samme side og jobber på samme måte? Hvordan har du fått teamet ditt til å få dette til å fungere for deg?

Natalie Semczuk:

Som oftest, ja. Noen av tipsene og triksene kan jeg kontrollere fra min side. De er til min fordel, for eksempel varsler og verktøyene jeg bruker, hvordan jeg mottar dem, om de kommer som et ukentlig sammendrag eller i sanntid, og lignende. Integrasjonene mellom verktøy, for eksempel GitHub eller Slack, eller Trello og Slack, krever at teamet mitt følger en bestemt prosess, ganske enkelt ved at de bruker disse verktøyene. Jeg tror det er ganske enkelt å få selv det mest uorganiserte teamet til å forplikte seg til et kodearkiv eller noe lignende. Det er uansett svært nyttig å ha disse integrasjonene satt opp, uavhengig av hvilken prosess som følges.

Ben Aston:

Flott. Hvis folk bare skulle gjennomføre én automatisering, hvilken enkelt automatisering er det du setter mest pris på hver dag, fordi du liker å se den gjøre noe av magien sin?

Natalie Semczuk:

For meg tror jeg det beste er at jeg bruker Slack som chatteverktøy med nesten alle team. Derfor er det svært nyttig å integrere prosjektstyringsverktøyet jeg bruker i et prosjekt, i en Slack-kanal. Det gir meg informasjon, for eksempel hvis noen oppdaterer en oppgave som er tildelt dem, markerer et problem med en bestemt indikator på oppgaven eller flytter oppgaven til en kolonne for fullførte oppgaver. Det gir meg umiddelbar innsikt i hva som blir gjort. Jeg trenger ikke logge inn i et annet program for å se det, og jeg trenger ikke sjekke e-posten. Jeg tror derfor denne typen integrasjon er den enkleste automatiseringen å ha. Når det er sagt, hvis du ikke bruker slike verktøy, liker jeg å sende sammendrag av informasjon til e-posten min. Det er nyttig å ha ett sted der jeg kan se en rask oversikt over alt som skjer, uten å måtte gå inn i seks forskjellige programmer for å sjekke statusen på noe.

Ben Aston:

Veldig bra. Har det noen gang skjedd at automatiseringene dine har sviktet katastrofalt, slik at du har endt opp med en katastrofe fordi noe som skulle skje, ikke skjedde?

Natalie Semczuk:

Ja, jeg tror det kan gå begge veier når slike integrasjoner av en eller annen grunn svikter. Noe blir oppdatert, og jeg oppdager det ikke før det er for sent. Eller det motsatte: Integrasjonen fungerer så godt at du blir bombardert med varsler på det ene stedet du har samlet dem, noe som absolutt ikke er ideelt.

Ben Aston:

Ja, flott. La oss gå videre til nummer to. Det er «Bruk en RACI-matrise i hvert prosjekt du leder». For de som ikke kjenner RACI, kan du fortelle litt om hva det er og hvorfor du liker det?

Natalie Semczuk:

Ja, jeg må innrømme at jeg bruker dem litt utradisjonelt i prosjektene mine, men grunntanken er å få oversikt over alle ansvarsområdene, rollene og eierskapet i et prosjekt, og gjøre det svært tydelig hvilken person eller hvilket team i prosjektet som forventes å samhandle på en bestemt måte og ta beslutninger. Mange lager disse ved prosjektoppstart. Jeg synes det er en veldig god måte å skape tydelighet på. For eksempel har prosjektkunden ansvar for å bestemme hva slags innhold teamet deres skal gå videre med, men samtidig trenger teamet vårt innsikt i dette på tvers av bestemte avdelinger. Det handler altså i bunn og grunn om å fordele de ulike ansvarsområdene mellom partene i et prosjekt.

Ben Aston:

Flott. Jeg vet at du har lagt inn et eksempel på en RACI-matrise i artikkelen. Når det kommer til stykket, hvordan kommer du frem til beslutningen, eller fortell meg om beslutningsprosessen din når du bestemmer hvem som skal stå i hvilken kolonne. Hvem skal konsulteres, hvem skal bare informeres, hva betyr det å være informert, og hva betyr det å være ansvarlig? Hvordan kommer du frem til punktet der du bestemmer: «Ok, du er ansvarlig, og du skal bare informeres?»

Natalie Semczuk:

Jeg tror det varierer avhengig av prosjektet. Jeg bruker vanligvis en presedens eller prosess for de overordnede delene av et prosjekt. Når man går mellom ulike faser eller milepæler, finnes det vanligvis en typisk prosess i byråer, der man vet at kunden skal involveres på et bestemt tidspunkt. Man vet at design eller utvikling skal involveres på et bestemt tidspunkt. Derfor velger man ut de overordnede personene som skal involveres, og følger det man allerede vet er prosessen. Jeg tror likevel det finnes en grense der du som prosjektleder må fastsette dette, hvis prosjektet er forholdsvis komplekst eller har mange interessenter. Du kan også innhente støtte hvis teamet ditt er mer samarbeidsorientert, slik at dere sammen bestemmer hvem som skal informeres og hvem som skal være ansvarlig. Selvfølgelig kan det også være overlapp. Det er bare langt mer nyttig å spesifisere hvilken person som hører hjemme hvor.

Ben Aston:

Ja, absolutt. Noe jeg ofte synes er utfordrende med en RACI, er å vite hvor detaljert man skal være. Hvor langt bryter du det ned? Bryter du det ned etter faser, oppgaver eller leveranser? Hvordan tar du den beslutningen, og hvor detaljert liker du å være?

Natalie Semczuk:

For små prosjekter liker jeg absolutt å basere det på faser og større leveranser. På større prosjekter, som enten er mer komplekse, varer lenger eller involverer flere personer – ordet «stort» kan beskrive mange ting – liker jeg å bryte det mer detaljert ned. Jeg liker også tanken på å bruke en RACI-matrise på ting folk vanligvis ikke tenker på, for eksempel hvordan arbeidsflyten for innhold eller oppdateringer skal se ut etter lansering. Det hjelper kunden eller interessentene med å forstå arbeidsmengden eller antallet personer som må involveres, og å tenke gjennom dette. På den måten kommer alle på samme side og forventningene styres bedre generelt.

Ben Aston:

Bra. La oss ta nummer tre: «Hils på teamet og kollegene dine hver dag.» Ved første øyekast høres det ut som om du ikke hilser på dem på jobb. Hvordan fungerer dette, og hvordan ser du for deg at det fungerer eksternt sammenlignet med på et kontor? Du har nevnt flere ganger at du bruker mye tid på Slack. Noe jeg har opplevd, er at Slack er et fantastisk verktøy som jeg elsker, men samtidig kan vi ende opp med team som jobber med samme del og skriver til hverandre selv om de sitter rett ved siden av hverandre. Hvordan bygger du bro mellom virtuell kommunikasjon og kommunikasjon ansikt til ansikt, og gjør dette levende?

Natalie Semczuk:

Ja, det er absolutt en balanse som må finnes. Det er vanskelig å si hvor mye direkte menneskelig interaksjon som er best for et team. Når man jobber eksternt, blir det selvsagt en mer tvungen interaksjon. Hvis man deltar i en samtale eller videosamtale, ser man ikke de andre hver dag. Men jeg synes det er svært nyttig å bygge en god relasjon til folk og la dem vite at du vet at de fortsatt er der. Derfor liker jeg å variere. Jeg sender en melding til teammedlemmer enten individuelt for å stille et bestemt spørsmål, se om de har en hindring eller bare spørre hvordan de har det. Eller jeg skriver i kanalen. Jeg nevner vanligvis ikke alle i kanalen, for jeg synes det er en dårlig praksis, men jeg skriver generelt til prosjektgruppen: «Hei, hvordan går det med alle? Hvordan har dere det? Er det noen problemer?»

Jeg synes det er flott å ha denne interaksjonen på en mye mer uformell måte, og ikke alltid ha et sluttmål om å innhente informasjon, få en status eller avklare noe. Det får folk til å slappe litt mer av.

Ben Aston:

Bra. Neste punkt, nummer fire, er «Lær deg å si nei i et prosjekt. På en høflig, men bestemt måte.» Fortell oss litt mer om det.

Natalie Semczuk:

Å si nei var definitivt noe jeg slet med som yngre prosjektleder. Det er vanskelig når man generelt er imøtekommende og hyggelig, men jeg ser på det som noe jeg gjør for å beskytte meg selv, teamet mitt og prosjektet. Jeg synes det er svært viktig at vi lærer når det er riktig å si nei eller protestere, enten det gjelder en endring i omfang, som vi alle kjenner til, å beskytte tid i et prosjekt, eller å avklare ting slik at det ikke oppstår en umiddelbar reaksjon når en kunde ber om mer. Kanskje er det ikke det beste valget, men kanskje mener de egentlig noe annet. Det er viktig å kunne protestere og si nei på en eller annen måte til forespørsler som vil føre til stress, tidsproblemer eller budsjettproblemer, og også å forstå når disse situasjonene oppstår og hva som er den beste måten å håndtere dem på.

Ben Aston:

Fortell oss om en situasjon der du måtte si nei, og hvordan du gjør det på en måte som holder alle så fornøyde som mulig.

Natalie Semczuk:

Jeg tror et triks er at nei ikke alltid er et direkte nei. Denne uken jobbet jeg med et team der sprinten vår hadde kommet ut av rytme. Vi jobber i sprinter, og sprintsyklusen vår hadde blitt forskjøvet, så vi måtte flytte alle demonstrasjonene, retrospektivene og planleggingen. Det var faktisk et teammedlem jeg måtte si nei til. Han og jeg diskuterte om tidspunktet for et bestemt møte burde være den ene eller den andre dagen. Jeg ønsket å unngå viktige møter på mandager. Jeg synes det er en rotete dag for møter. Alle kommer tilbake fra helgen og trenger å lande, mens han var fast bestemt på at mandag var den beste dagen.

Jeg måtte bare si: «Hør her. Jeg forstår at dette er et team på ti personer. Du er én person, og jeg tror ikke dette vil påvirke deg negativt. Men jeg forstår bekymringen din. Det er bare slik at dette må skje på tirsdag. Jeg vurderer det på nytt hvis det ikke ser ut til å fungere de neste ukene, men etter min vurdering er dette den beste løsningen, og vi må gå videre med den slik at vi kan fortsette med dagene våre.»

Det var altså et mykt nei. Jeg hadde vurdert det, og jeg visste hva som var best for teamet i denne situasjonen. Men det var viktig å erkjenne at videre diskusjon ikke ville fungere for noen av oss.

Ben Aston:

Ja. Bestemt, men rettferdig.

Natalie Semczuk:

Ja, jeg prøver.

Ben Aston:

Jeg antar at det å si nei til teamet sitt … Noen ganger har vi som prosjektledere mandat til å si til teamet: «Dette er spillereglene og rammene vi skal jobbe innenfor.» Når det gjelder å si nei til en kunde, vet jeg at typiske situasjoner er når en kunde prøver å øke omfanget, forsøker å overforfine noe, fremskynde fristen eller kutte kostnader på en eller annen måte. Hvilke teknikker kan du bruke når du håndterer dette med en kunde, samtidig som du prøver å opprettholde relasjonen og holde prosjektet på rett spor?

Natalie Semczuk:

Jeg prøver virkelig hardt å omdirigere samtalen og forstå hvor de kommer fra. Jeg tror jeg nevnte dette i artikkelen også: Opplæring kommer man langt med. Hvis de for eksempel fremskynder en frist, er det svært viktig for meg å forklare ulempene ved å flytte fristen frem. Kostnadene kan for eksempel øke betydelig, funksjoner kan bli kraftig redusert, og kvaliteten blir kanskje ikke den samme. Samtidig må jeg vise hvor grensen går. Jeg har identifisert at jeg skal si nei, og jeg forklarer hvorfor. For eksempel: «Vi kan ikke flytte fristen så langt frem, fordi det vil svekke kvaliteten. Som selskap arbeider vi med et bestemt kvalitetsnivå, og vi mener ikke at dette vil oppfylle det.»

Eller jeg kan forklare: «Med alt vi har på arbeidslisten akkurat nå, må vi redusere funksjonaliteten. Men mengden vi måtte redusere for å nå den fristen, ville faktisk gjort nettstedet ubrukelig. Derfor kan vi ikke nå den fristen.» Jeg liker ikke å etterlate et smutthull eller en for stor unnskyldning som gjør at det kan forhandles frem en løsning som: «Hvis vi bare gjør dette, kan vi klare det.» Man må være bestemt, informativ og samtidig forstå konsekvensene av beslutningen.

Ben Aston:

Ja. Jeg synes det er viktig at vi er tydelige når vi sier nei. En utfordring kan være at vi prøver å si nei til kunden, men ender med å bruke formuleringer som «Vi tror ikke vi vil klare det», «Vi kommer kanskje ikke til å rekke fristen» eller «Jeg er ikke sikker på om vi kan ta det med». Når språket ikke er tydelig, eller når vi ikke følger opp med «Bare for å bekrefte: Vi kommer ikke til å klare fristen du har bedt om», kan det bli uklart.

Derfor er tydelig språk rundt nei så viktig. Det er også viktig å gi alternativer. Så langt det er mulig ønsker vi å sette kundene i stand til å ta den riktige beslutningen selv, i stedet for å presse dem inn i et hjørne og få dem til å føle: «Vent litt, jeg mistet kontrollen.» Kunder vil vite at de har kontroll. Derfor kan det hjelpe å gi dem valg: «Du kan velge alternativ A eller alternativ B. Alternativ B tar lengre tid og koster mer, men kvaliteten blir bedre, eller du får det du ønsker. Jeg sier ikke bare nei; dette er et alternativ for deg.» Å gi dem en følelse av at de har valgmuligheter kan ofte hjelpe.

Natalie Semczuk:

Ja, jeg er helt enig. Det var veldig godt sagt.

Ben Aston:

Neste punkt er «Se på prosjektene dine som læringsmuligheter». Hva har du lært i det siste?

Natalie Semczuk:

Jeg tror jeg har snakket litt om å lære mer om utvikling. Jeg har vært med på noen utviklingstunge prosjekter, og det har vært flott å se noe jeg ikke forstår fullt ut, og ta meg tid til å be teamet mitt forklare det bedre når de har anledning. Fordelen er at jeg forstår det bedre fra et prosjektlederperspektiv, og jeg kan kanskje dele dette med dem hvis det er noe de også kunne ha nytte av å lære. Jeg kan også forklare kunden mer når jeg forteller om disse tingene, noe jeg synes alltid er viktig.

Det andre jeg liker svært godt, og som jeg tror er grunnen til at jeg trekkes mot prosjektledelse, er at jeg lærer mye om virksomhetene, tankegangen og strategiene til kundene mine. Det er tydelig i hvert prosjekt jeg har jobbet med, spesielt siden jeg jobber med webutviklingsprosjekter, at kundene våre har mye å lære om nettet. Det handler om å forstå hvordan de bruker nettsteder, hvordan de oppdaterer dem, og hvilke hovedproblemer de har når de åpner et nettsted. Det er en slags innebygd brukeropplevelsesforskning. Det er alltid en læringsmulighet. Jeg synes også prosjekter er et godt tidspunkt for å prøve nye teknikker eller nye kommunikasjonsmønstre. Selvfølgelig ikke i ekstrem grad, men på en måte der vi justerer litt på det vi har gjort før og ser om det gir en forskjell.

Ben Aston:

Ja, noe du snakket om i artikkelen, er retrospektiver og hvordan man bruker dem som læringsmuligheter man kan bygge videre på. Fortell meg hvordan du bruker retrospektiver med teamet ditt. Noe jeg har opplevd, er at folk kan gå gjennom prosessen med å ha et retrospektiv, men hvordan skaper man faktisk endring som følge av et møte?

Natalie Semczuk:

Jeg tror selve prosessen med å ha et retrospektiv er svært sunn for et team. Jeg har definitivt vært med på prosjekter der det har vært mye klaging og misnøye i kulissene, og hver gang vi har gjort det, har det kommet fra et grunnleggende problem i selve prosjektet. Det kan være kunden, prosessen, selve prosjektet, hvordan det ble ledet eller hvordan teamet mitt jobbet med det. Vi lærer alltid noe av tilfeldig klaging og misnøye. Derfor er det nyttig å ta det inn i et retrospektiv, der man ikke bare kan reflektere over det som var vanskelig, men også over det som faktisk fungerte. Da får man alt frem i lyset. Jeg tror ikke dette vanligvis skjer naturlig i et prosjekt, i hvert fall ikke på teamsiden.

Vi sier vanligvis ikke: «Denne prosessen var flott, den fungerte så godt for meg.» Når vi finner noe som ikke fungerer, har vi en tendens til å klage eller bygge opp frustrasjonen i hodet. Det er nyttig å få dette ut. Jeg liker å dokumentere de viktigste punktene og lærdommene fra alt som blir sagt, mens vi snakker. Siden jeg jobber eksternt, deler jeg vanligvis skjermen og tar notater mens vi snakker. Dette kan gjøres med en tavle når man møtes fysisk, eller noe tilsvarende. Jeg liker at alle blir enige om én eller to ting som skal forbedres fremover, enten på det samme teamet hvis vi skal jobbe sammen igjen, eller på et mer overordnet nivå der alle er klar over det. Uansett om noe formelt blir endret fra et prosjektleder- eller bedriftsperspektiv, er det svært nyttig å ha en felles forståelse av problemet og hva vi ønsker å forbedre fremover.

Ben Aston:

Veldig bra. Neste punkt er «Ta kontroll over varslene dine». Dette er kanskje selvforklarende, men det er tydeligvis viktig nok til at du tok det med. Hvilke typer varsler synes du er mest og minst nyttige når du prioriterer og bestemmer om du skal dempe dem eller ikke?

Natalie Semczuk:

Mhm. Generelt synes jeg alle typer uleste varsler, eller den røde markeringen, er stressende. Jeg bruker Mac, så jeg ser mange røde markeringer. Jeg vil alltid fjerne dem, håndtere dem, lese dem og ta tak i dem. Men hvis jeg leser dem uten å håndtere dem med én gang, glemmer jeg dem. Derfor demper jeg nesten alt som gir meg et ulest varsel, og som ikke er direkte knyttet til prosjektet mitt eller en direktemelding. Jeg lar alltid varsler for direktemeldinger stå på, fordi jeg jobber så tett med eksterne team og synes det er viktig at de kan få tak i meg privat. Men jeg demper alt som er tilfeldig prat eller kommer fra en robot, avhengig av verktøyet. Noen ganger kan man automatisere dette, eller endre innstillingen.

Jeg bruker også ofte filtre og filtre for uleste meldinger i Gmail, slik at jeg ikke umiddelbart ser noe som er ulest, men heller får et sammendrag av det som har skjedd på Basecamp den dagen. Hvis jeg vet at det ikke kommer fra en kunde, trenger jeg ikke se på det, håndtere det og slette det med én gang. Det har hjulpet meg mye å vite hva som utløser en reaktiv respons hos meg, og håndtere dette.

Ben Aston:

Veldig bra. Det neste punktet synes jeg er veldig interessant: «Lær opp så mye som mulig.» Vi snakket tidligere om opplæring, men fortell litt om hvordan du personlig lærer og utvikler deg som digital prosjektleder for tiden, på en måte som andre kan dra nytte av.

Natalie Semczuk:

Jeg tror at når jeg tenker på da jeg startet, og når jeg snakker med personer som er juniorer, understreker jeg alltid at man må være tydelig på hva man ikke vet. Det er faktisk også et av poengene i artikkelen: Vær åpen om hva du ikke vet, og hva du må avklare med teamet. Men jeg tror ikke det alltid bør ses på som en mulighet for personlig utvikling. Når jeg vet at jeg ikke forstår noe teamet mitt arbeider med eller snakker om, kommer jeg selvsagt ikke til å være ekspert på alt. Det er derfor vi har et team, et prosjektteam. Det er de som utfører arbeidet, de vet hvordan det skal gjøres, og de er ekspertene.

Hvis det er noe jeg er spesielt nysgjerrig på, eller noe som stadig forvirrer meg, bruker jeg ofte utvikling, DNS, drift og servere som eksempler i artikkelen. Jeg er vanligvis personen på kundesiden som beskriver hva vi trenger, hvilken informasjon vi trenger fra kunden ved DNS-endringer, og hva problemet er hvis vi faktisk får et slikt problem. Det var svært nyttig for meg å forstå mer av hvordan dette ser ut på baksiden, hva begrepene betyr og hvordan alt henger sammen. Det ga meg kontekst og et rammeverk for å snakke med kunden om det, og var direkte relevant for mange av samtalene jeg hadde.

Ben Aston:

Flott. Er det noen nettsteder, blogger eller andre ting du leser for tiden som du synes er nyttige?

Natalie Semczuk:

Jeg googler vanligvis ting, og jeg liker å lytte til podkaster utenfor mitt spesifikke fokusområde. Det kan være podkaster om design eller innholdsstrategi, eller noe annet jeg synes er interessant. Det finnes mange podkaster om frontend eller backend, og bare det å lytte én eller to ganger når jeg har tid, gjør at jeg føler meg mer komfortabel med terminologien og forstår litt mer av det som skjer.

Ben Aston:

Ja, jeg synes det er svært viktig. Som digitale prosjektledere prøver vi å lede et prosjekt; vi bare administrerer det ikke. For å lede effektivt må vi vite mer enn bare hvordan man administrerer et prosjekt. Det er viktig at vi utvikler ekspertise, ikke nødvendigvis i den grad at vi kan utføre arbeidet selv, selv om det ikke er noe galt med å gjøre litt skissearbeid nå og da. Det er viktig at vi forstår strategi, UX, design, utvikling, kvalitetssikring og fremskrittene som skjer innenfor disse fagområdene, slik at vi kan sørge for at teamet vårt bruker dem i prosjektet, og slik at vi kan fremstå som kunnskapsrike overfor kundene våre. Det gir oss også muligheten til å lede prosjektene våre langt mer effektivt når vi har bedre oversikt over hva folk gjør, eller hva de bør gjøre. Så jeg synes det er flott.

Et annet punkt på listen din, nummer ti, er «Følg alltid med på tallene». Det synes jeg er svært viktig. Fortell oss om hvilke tall som er viktige for deg i et prosjekt.

Natalie Semczuk:

Ja, selvfølgelig. Jeg jobber for det meste med team som fakturerer etter tid og materiell, så det er svært viktig å hente ut tidsrapporter. Ikke bare for å forstå hvor budsjettet går eller hvor mange timer som brukes på arbeidet, men også fordi jeg liker å lese beskrivelsene i tidsregistreringene. De viser ofte hvor det kan finnes en hindring, eller kanskje et læringspunkt eller en samarbeidsmulighet jeg ikke var klar over. Det er fint å forstå dette ut fra sporene som ligger igjen, særlig siden jeg ikke sitter på et kontor og ikke alltid ser hvordan folk samhandler.

Det er viktig å vite hvordan folk bruker tiden sin. Jeg gjør dette uten onde hensikter, ikke for å dømme, men for å forstå hva som foregår. Selvfølgelig trenger man også tall basert på budsjettet. Jeg synes det gir god innsikt i kommunikasjon, arbeid og ting som skjer i et prosjekt, som du kanskje kan bidra til, lære av eller legge til rette for i fremtiden. Dette er viktig for meg, så jeg sjekker jevnlig prosjektstyringsverktøyene jeg bruker, for å se om det foregår andre samtaler. Ofte jobber jeg med verktøy der kunden er invitert inn, så jeg tar en rask titt for å se om andre har en samtale jeg bør involveres i, og for å se hvor mange oppgaver som er fullført eller kanskje blokkert eller fastlåst hvis vi jobber oppgavebasert.

Jeg synes også det er viktig å forstå ressursbruken i prosjekter: hvor mange timer folk bruker eller er satt opp til å bruke per uke, og når de skal ha ferie. Dette er på en måte tallbasert, men alt inngår i de større tallene for budsjett, tidsplan og fremdrift i et prosjekt, samt alt arbeidet som legges ned.

Ben Aston:

Ja, flott. Det var en kommentar til innlegget ditt fra en person som nylig gikk over til en prosjektlederrolle fra en kundeansvarlig rolle i et markedsføringsbyrå, der det ikke var så mye struktur rundt rollene. Personen lurte på om du hadde anbefalinger for hvordan man best rapporterer mot et timebudsjett. Excel-regneark, verktøy du vil anbefale – hvordan gjør du selve rapporteringen? Hva bruker du?

Natalie Semczuk:

De fleste teamene jeg har jobbet med, bruker Harvest eller lignende tidsregistreringsverktøy, der teamet registrerer tiden de bruker hver dag eller på hvert prosjekt, og jeg kan hente rapporter fra dette. Jeg kan hente daglige, månedlige og ukentlige rapporter. Det viktige er å forstå hvordan teamet fordeler timene sine og hvordan de registrerer dem, og deretter bygge et system ut fra dette. Hvis jeg rapporterer til en kunde, finnes det en fin funksjon i Harvest, og jeg tror også andre verktøy har den, der du kan eksportere til CSV, et Excel-regneark eller et Google-regneark. Da kan jeg rydde opp i registreringene og oppsummere dem hvis kunden trenger en detaljert oversikt.

Hvis det er en rapport til kunden eller teamet mitt, henter jeg ellers tallene selv fra stedet der de registreres, og rapporterer dem muntlig eller på e-post.

Ben Aston:

Ja. Hvordan avstemmer du disse tallene? Folk gjør arbeidet og registrerer timer mot det. Hvordan vet du om du ligger i rute? Hvor ofte må du avstemme mot estimatet, og hvordan fungerer prosessen?

Natalie Semczuk:

Jeg gjør det stort sett ukentlig. Hvis det er en svært travel uke, sjekker jeg flere ganger i løpet av uken i det verktøyet som brukes. Jeg har også jobbet med prosjekter der tiden ikke registreres så detaljert. Da er folk satt av til å jobbe en hel dag. I slike tilfeller går jeg inn i verktøyet vi bruker for å fordele folks dager, og sørger for at det stemmer med det folk faktisk jobbet den uken, basert på det jeg hører i prosjektlederrapporten.

For å avstemme timer generelt henter jeg en rapport ukentlig, eller to ganger i uken hvis det er travelt, og sørger for at all tid er registrert. Så sammenligner jeg den med estimatet eller det vi arbeider mot, altså budsjettet. Jeg passer også på å se på hva som kan være satt av til intern tid, opplæring eller læring. Det skjer ikke så ofte, men det forekommer. Jeg får altså en oversikt fra uke til uke, og det er vanligvis også så ofte jeg oppdaterer kundene mine om prosjektene deres. Det gir meg en god følelse av hvor langt vi har kommet, og vanligvis varierer ikke bildet voldsomt hvis jeg bare ser på det ukentlig.

Ben Aston:

Ja, bra. Tusen takk for at du ble med oss, Natalie. Dette har vært svært nyttig for å hjelpe oss med å forstå litt mer om hvordan du jobber og noen av tipsene og triksene du har satt sammen, slik at vi alle kan lære av dem. Hvis du lytter til podkasten og ønsker å bidra til samtalen, hadde det vært flott om du kunne dele tankene dine som kommentarer til Natalies innlegg på thedigitalprojectmanager.com. Vi har også et Slack-team. Hvis du klikker på fellesskapsseksjonen på Digital Project Manager-nettstedet, kan du registrere deg og bli med oss på Slack, og fortsette samtalen der.

Takk for at du ble med oss, Natalie. Vi ser frem til en ny podkast med deg snart. Det har vært flott å ha deg med.

Natalie Semczuk:

Tusen takk.