Tips för projektledning (med Natalie Semczuk)
I det här avsnittet samtalar Ben Aston med Natalie Semczuk om knep för projektledning och går på djupet med detaljerna kring automatisering som du kan konfigurera, verktyg du kan använda, tekniker du kan tillämpa och filosofier du kan ta till dig – sådant som gör ditt liv som DPM mycket enklare.
Läs transkriptet:
Vi provar att transkribera våra poddar med hjälp av ett datorprogram. Ha överseende med eventuella stavfel eftersom boten inte är korrekt hela tiden.
Ben Aston:
Hej allihop och välkomna till det senaste avsnittet av podden Digital Project Manager. I dag har jag Natalie med mig, och jag är mycket glad över att göra det första av våra poddavsnitt där vi pratar med personer som faktiskt har skrivit en del av innehållet och artiklarna på webbplatsen.
Natalie publicerade nyligen en artikel hos oss på Digital Project Manager, Tips för projektledning, och alla älskar tips. Om du gillar tips publicerade vi för ett tag sedan en artikel om tips för Slack som blev mycket populär. Natalie har skapat en lista med tio olika tips som hon har använt under åren som digital projektledare. De sträcker sig från mycket praktiska råd till mer filosofiska idéer om hur vi närmar oss projektledning. Det ska vi diskutera i dag.
Först vill jag låta Natalie presentera sig själv. Natalie, kan du ge oss en överblick över vem du är, vilken typ av projekt du arbetar med och berätta lite om dig själv?
Natalie Semczuk:
Absolut, tack. Det är roligt att vara här. Jag är frilansande digital projektledare. Jag arbetar främst på distans med små och medelstora företag, vanligtvis inom webbdesign och webbutveckling, men ibland även med appar. Jag arbetar med team för att hjälpa dem att lyckas med sina projekt, arbetar med projektkunder och ger även råd om operativa processer och hur man gör sitt distans team ännu bättre.
Ben Aston:
Bra. Kan du ge oss en snabb överblick över några av de projekt du har arbetat med nyligen, om du kan prata om dem? Vilka typer av projekt och vilken typ av digital projektledning arbetar du med? Är den mer strategisk, eller handlar det om kampanjer, marknadsföringskampanjer eller webbbyggen? Vilken typ av digital projektledare är du?
Natalie Semczuk:
Det handlar oftast om webbbyggen eller mer omfattande webbutveckling och liknande. Just nu arbetar jag med två aktiva projekt. Det ena är en liten grundskola, en privatskola, som uppgraderar en stor del av sitt backend-system. Det handlar bland annat om hur de klassificerar och sorterar elever. Jag ansvarar för projektledningen, utvecklingsarbetet samt ombyggnaden och integrationen som hämtar all elevdata från befintliga system och lägger in den i en ganska specialanpassad webbplatslösning där lärare kan logga in och se sina elever och föräldrar också kan logga in och följa sina barns utveckling under året.
Jag arbetar också med en ganska enkel webbdesign och ombyggnad, eller ett webbbygge i allmänhet, för ett litet nystartat företag i San Francisco med några spännande produkter på gång. Jag tror inte att jag kan berätta mer om det, men det är en typisk design- och utvecklingsfas med lite strategi inblandad. Hittills har det varit väldigt roligt.
Ben Aston:
Bra. Då går vi på djupet med dina tio tips. Vi kommer förmodligen inte att gå igenom vart och ett i detalj, men kan du först ge oss en överblick över hur du kom fram till dem? Vi har några som är ganska praktiska och genomförandeinriktade och andra som verkar mer filosofiska kring hur vi bör arbeta med projektledning. Hur kom du fram till de här tipsen?
Natalie Semczuk:
Jag tror att det är en blandning av att se vad andra projektledare som jag har arbetat med har gjort, se vad som fungerade väldigt bra för dem och helt enkelt erfarenhet. Mycket kommer från att arbeta på distans, där man både har lite mer och lite mindre kontroll över sin omgivning. Mindre kontroll över teamet man arbetar med, men mer kontroll över sin personliga miljö. Jag tror att vi digitala projektledare använder många verktyg och kommunicerar hela tiden. Det är en stor del av vårt arbete, och det är lätt att glömma detaljerna kring hur man förfinar verktygen och kommunikationen så att de fungerar bra för oss. På så sätt lägger vi mindre tid på repetitiva och tråkiga saker och mer tid på det vi faktiskt behöver fokusera på.
Ben Aston:
Bra övergång till tips nummer ett: ”Automatisera dina projektledningsverktyg så mycket som möjligt.” Kan du berätta om de projektledningsverktyg du tycker om att använda och hur du har valt dem?
Natalie Semczuk:
Absolut. Jag använder olika verktyg beroende på vilket företag jag arbetar med. Nästan alltid Slack, Gmail eller Googles produktpaket. När det gäller själva projektledningsverktygen har jag använt Basecamp 3 mycket, Trello och en intressant blandning av de två som heter Breeze.pm. Den typen av vanliga arbetsflödesverktyg, tillsammans med mycket Slack och Google.
Ben Aston:
Ja, bra. I några av automatiseringarna du berättar om i artikeln verkar det som att du har ställt in saker så att du får meddelanden när människor gör vissa saker eller när vissa händelser inträffar. Kräver det att hela teamet är överens och arbetar på samma sätt? Hur har du fått teamet att arbeta på ett sätt som gör detta möjligt?
Natalie Semczuk:
För det mesta, ja. Vissa tips kan jag styra från min sida. De är till för min egen skull, till exempel aviseringar och vilka verktyg jag använder, hur jag tar emot dem och om de kommer som en veckosammanfattning eller i realtid. Integrationer mellan verktyg, till exempel GitHub och Slack eller Trello och Slack, kräver att teamet följer en viss process genom att använda verktygen. Jag tycker att det är ganska lätt att få även det mest oorganiserade team att börja använda ett kodförråd eller liknande. Det är definitivt bra att ha integrationerna på plats oavsett vilken process som följs.
Ben Aston:
Och om människor bara skulle genomföra en automatisering, vilken är den enda automatisering som du varje dag är tacksam över att ha?
Natalie Semczuk:
För mig är den bästa att integrera projektledningsverktyget jag använder i ett Slack-utrymme. Då får jag information om någon uppdaterar en uppgift som tilldelats dem, markerar ett problem eller flyttar uppgiften till en kolumn för slutförda uppgifter. Det ger mig omedelbar insyn i vad som blir gjort. Jag behöver inte logga in i ett annat program eller kontrollera e-posten. Det är den enklaste automatiseringen att införa. Om man inte använder sådana verktyg tycker jag om att skicka sammanfattningar av information till min e-post. Det är praktiskt att ha en enda plats där man snabbt kan se en överblick över allt som händer utan att behöva kontrollera sex olika program.
Ben Aston:
Har dina automatiseringar någon gång fallerat katastrofalt och lett till problem eftersom något som skulle ha hänt inte gjorde det?
Natalie Semczuk:
Ja, integrationer kan misslyckas av olika orsaker. Något kan uppdateras utan att jag märker det förrän det är för sent. Eller så fungerar integrationen så bra att man överöses med aviseringar på den enda plats där man samlar dem, vilket inte heller är idealiskt.
Ben Aston:
Bra. Då går vi vidare till nummer två: ”Använd en RACI-matris i varje projekt du leder.” För den som inte känner till RACI, kan du berätta lite om vad det är och varför du tycker om att använda det?
Natalie Semczuk:
Grundidén är att skapa insyn i alla ansvarsområden, roller och ägarskap i ett projekt och göra det tydligt vilken person eller vilket team som förväntas agera på ett visst sätt och fatta beslut. Många tar fram sådana matriser vid ett projektuppstartsmöte. Jag tycker att det är ett mycket bra sätt att skapa tydlighet. Det handlar i grunden om att fördela de olika ansvarsområdena mellan parterna i ett projekt.
Ben Aston:
I artikeln har du ett exempel på en RACI-matris. Hur kommer du fram till vem som ska stå i vilken kolumn? Vem ska konsulteras, vem ska informeras och vad betyder det att vara ansvarig?
Natalie Semczuk:
Det beror på projektet. Jag utgår vanligtvis från tidigare arbetssätt eller processer för projektets övergripande delar. Mellan olika faser eller milstolpar finns det ofta en typisk process på byråer där man vet när kunden ska vara involverad och när design- eller utvecklingsteamet ska vara involverat. Sedan finns det en gräns där projektledaren behöver bestämma, särskilt om projektet är komplext eller har många intressenter. Om teamet arbetar mer samarbetsinriktat kan man också komma överens tillsammans om vilka som ska informeras och vilka som är ansvariga. Det går alltid att ha överlappningar, men det är mycket mer användbart att tydligt ange vilken person som hör hemma var.
Ben Aston:
En utmaning med RACI är ofta hur detaljerad den ska vara. Bryter du ner den per fas, uppgift eller leverans?
Natalie Semczuk:
I mindre projekt tycker jag om att utgå från faser och större leveranser. I större projekt, som är mer komplexa, pågår längre eller involverar fler personer, bryter jag ner den mer detaljerat. Jag tycker också om att använda en RACI-matris för sådant som människor vanligtvis inte tänker på, till exempel hur innehållsflödet eller uppdateringsflödet ska se ut efter lanseringen. Det hjälper kunden eller intressenterna att förstå hur mycket arbete och hur många personer som krävs. På så sätt hamnar alla på samma sida och förväntningarna hanteras bättre.
Ben Aston:
Nästa punkt är nummer tre: ”Hälsa på teamet och kollegorna varje dag.” Hur fungerar det på distans jämfört med på ett kontor?
Natalie Semczuk:
Det finns en balans att hitta. Det är svårt att säga hur mycket personlig interaktion som är bäst för ett team. När man arbetar på distans blir interaktionen mer tvingad, genom samtal eller videomöten. Men det är så hjälpsamt att skapa en relation med människor och visa att man vet att de finns där. Jag brukar variera mig. Jag kan skriva direkt till teammedlemmar för att ställa en fråga, se om de har något hinder eller bara fråga hur de mår. Eller så skriver jag i projektkanalen och frågar hela gruppen hur alla har det och om det finns några problem.
Det är bra att ha en mer avslappnad interaktion utan att alltid ha ett konkret mål att hämta information, få en status eller reda ut något. Det får människor att slappna av lite.
Ben Aston:
Nummer fyra är: ”Lär dig att säga nej i ett projekt – vänligt men bestämt.” Berätta lite mer om det.
Natalie Semczuk:
Att säga nej var något jag hade svårt för när jag var yngre projektledare. Det är svårt när man arbetar mycket med människor och vill vara trevlig, men jag ser det som ett sätt att skydda mig själv, teamet och projektet. Det är viktigt att lära sig när man ska säga nej eller invända, oavsett om det gäller en förändring av omfattningen, att skydda tid i projektet eller att klargöra något innan man reagerar direkt på en kunds önskemål. Att kunna säga nej till önskemål som orsakar stress, tidsproblem eller budgetproblem är viktigt, liksom att förstå hur man bäst hanterar situationen.
Ben Aston:
Kan du berätta om en situation där du behövde säga nej och hur du gjorde det på ett sätt som höll alla så nöjda som möjligt?
Natalie Semczuk:
Ett knep är att nej inte alltid behöver vara ett rakt nej. Nyligen arbetade jag med ett team där vår sprintcykel hade hamnat ur fas. Vi behövde flytta våra demo- och retrospektivmöten samt planeringen. Jag behövde säga nej till en teammedlem som ville ha ett möte på en måndag. Jag ville undvika viktiga möten på måndagar eftersom alla kommer tillbaka efter helgen och behöver landa.
Jag sa ungefär: ”Jag förstår att det här är ett team på tio personer och att du är en person. Jag tror inte att detta påverkar dig negativt, men jag förstår din oro. Det här måste ändå ske på tisdag. Jag omprövar beslutet om det inte fungerar under de kommande veckorna, men enligt min bedömning är det här bäst för teamet och vi behöver gå vidare.”
Det var alltså ett mjukt nej. Jag hade övervägt frågan och visste vad som var bäst för teamet i den situationen, men det var viktigt att inse att ytterligare diskussion inte skulle hjälpa någon av oss.
Ben Aston:
Bestämt men rättvist.
Natalie Semczuk:
Jag försöker.
Ben Aston:
Som projektledare har vi ibland mandat att säga till teamet vilka grundregler och ramar vi ska arbeta inom. När det gäller att säga nej till en kund kan det handla om att kunden vill utöka omfattningen, lägga till mer än vad som behövs, tidigarelägga deadline eller minska kostnaderna. Vilka tekniker använder du för att hantera sådana situationer och samtidigt bevara relationen?
Natalie Semczuk:
Jag försöker omdirigera samtalet och förstå var kunden kommer ifrån. Utbildning hjälper långt. Om kunden vill tidigarelägga en deadline förklarar jag konsekvenserna: kostnaden kan öka kraftigt, funktioner kan behöva tas bort och kvaliteten kanske inte blir densamma. Sedan förklarar jag tydligt var gränsen går och varför. Jag försöker vara bestämd, informera om konsekvenserna och samtidigt förstå vad beslutet innebär.
Ben Aston:
Det är viktigt att vara tydlig när man säger nej och även ge kunden alternativ. Kunden vill känna att den har kontroll. Om man erbjuder alternativ, där ett tar längre tid och kostar mer men ger bättre kvalitet, säger man inte bara nej utan ger kunden möjlighet att fatta ett informerat beslut.
Natalie Semczuk:
Ja, jag håller helt med.
Ben Aston:
Nästa punkt är: ”Se dina projekt som möjligheter att lära.” Vad har du lärt dig nyligen?
Natalie Semczuk:
Jag har arbetat med flera utvecklingstunga projekt och det har varit bra att möta sådant jag inte helt förstår och ta mig tid att be teamet förklara det bättre. Då förstår jag mer ur ett projektledningsperspektiv och kan kanske dela den kunskapen med teamet. Jag kan också utbilda kunden bättre när jag pratar om de här sakerna.
Jag tycker också om att lära mig om kundernas verksamheter, tankesätt och strategier. I webbutvecklingsprojekt finns det mycket att lära om hur kunder använder och uppdaterar webbplatser och vilka problem de har när de använder dem. Projekt är också bra tillfällen att prova nya tekniker eller kommunikationsmönster och se om de fungerar bättre.
Ben Aston:
Du nämner retrospektiv som lärandemöjligheter. Hur använder du retrospektiv med teamet och hur skapar du förändring efter mötet?
Natalie Semczuk:
Själva processen att ha ett retrospektiv är hälsosam för ett team. När människor klagar eller muttrar bakom kulisserna kommer det ofta från ett grundproblem i projektet, till exempel kunden, processen, projektledningen eller hur teamet arbetar. Man lär sig alltid något av det. I ett retrospektiv kan man reflektera både över det som var svårt och det som fungerade.
Jag tycker om att dokumentera de viktigaste punkterna och slutsatserna medan vi pratar. Eftersom jag arbetar på distans delar jag vanligtvis skärm och antecknar under mötet. Sedan försöker vi enas om en eller två saker att förbättra framåt. Det hjälper alla att förstå problemet och vad vi vill förbättra.
Ben Aston:
Nästa punkt är: ”Ta kontroll över dina aviseringar.” Vilka aviseringar tycker du är mest och minst hjälpsamma?
Natalie Semczuk:
Olästa aviseringar och röda märken stressar mig. Jag vill rensa bort dem, hantera dem och läsa dem, men om jag läser något utan att hantera det direkt glömmer jag det. Därför stänger jag av nästan alla olästa aviseringar som inte gäller mitt projekt direkt eller är ett direktmeddelande. Jag låter direktmeddelanden vara aktiverade eftersom det är viktigt att distansteamet kan nå mig privat.
Jag använder också filter och filter för olästa meddelanden i Gmail, så att jag inte genast behöver se allt som är oläst. Jag försöker förstå vad som gör mig reaktiv och hantera det.
Ben Aston:
Nästa punkt är: ”Utbilda så mycket som möjligt.” Hur lär du dig och utvecklas som digital projektledare?
Natalie Semczuk:
När jag började, och när jag pratar med juniora personer, betonar jag alltid vikten av att vara tydlig med vad man inte vet. Det är viktigt att vara öppen med vad man behöver kontrollera med teamet. Man ska inte vara expert på allt. Det är därför man har ett projektteam; de utför arbetet och är experter på sina områden.
Jag har till exempel lärt mig mer om utveckling, DNS, webbhotell och servrar. Jag behöver ofta förklara för kunden vilken information vi behöver och vad ett problem innebär. Att förstå backend bättre och veta vad termerna betyder gav mig ett sammanhang och en struktur för samtalen med kunden.
Ben Aston:
Finns det några webbplatser, bloggar eller andra saker du läser just nu som du tycker är hjälpsamma?
Natalie Semczuk:
Jag googlar oftast saker. Jag tycker också om att lyssna på poddar utanför mitt eget fokusområde, till exempel om design eller innehållsstrategi. Det finns många poddar om frontend och backend, och att lyssna någon gång ibland hjälper mig att känna mig mer bekväm med terminologin och förstå vad som händer.
Ben Aston:
Som digitala projektledare behöver vi veta mer än hur man administrerar ett projekt. Vi behöver utveckla kunskap om strategi, UX, design, utveckling och kvalitetssäkring så att vi kan leda projekt mer effektivt och förstå vad teamet gör.
En annan punkt på din lista är ”Notera alltid siffrorna.” Vilka siffror är viktiga för dig i ett projekt?
Natalie Semczuk:
Jag arbetar främst med team som baserar sig på tid och material, så det är viktigt att ta fram tidsrapporter. Jag vill inte bara förstå vart budgeten tar vägen eller hur många timmar som läggs på arbetet, utan även läsa beskrivningarna i tidsregistreringarna. De kan visa var det finns ett hinder, en möjlighet att lära eller ett samarbete jag inte kände till.
Jag följer hur människor använder sin tid utan någon illvillig avsikt. Det handlar om att förstå vad som händer, få insyn i kommunikation och arbete samt upptäcka var jag kan hjälpa till. Jag tittar också på hur många uppgifter som är slutförda eller blockerade och hur resurserna används.
Det är viktigt att förstå hur många timmar människor arbetar per vecka, hur många timmar de förväntas arbeta och när de har semester. Alla dessa siffror bidrar till den större bilden av budget, tidsplan, arbetstakt och arbetsinsats.
Ben Aston:
Hur rapporterar du mot en timbudget? Använder du kalkylblad eller andra verktyg?
Natalie Semczuk:
De flesta team jag arbetar med använder Harvest eller liknande tidsspårningsverktyg där teamet registrerar sin tid varje dag eller för varje projekt. Därifrån kan jag ta fram dagliga, månatliga eller veckovisa rapporter. Det viktiga är att förstå hur teamet fördelar och registrerar sina timmar och sedan bygga ett system utifrån det.
Om jag rapporterar till en kund kan jag exportera informationen till CSV, Excel eller ett kalkylblad i Google Drive, städa upp posterna och sammanfatta dem om kunden behöver en detaljerad vy.
Ben Aston:
Hur stämmer du av siffrorna och vet om projektet ligger i fas?
Natalie Semczuk:
Jag gör det vanligtvis varje vecka. Om det är en mycket intensiv vecka kontrollerar jag flera gånger i veckan. Jag tar fram en rapport och ser till att all tid är registrerad. Sedan jämför jag den med uppskattningen eller budgeten och kontrollerar även tid som lagts på internt arbete, utbildning eller lärande. Det ger mig en bra bild av hur långt vi har kommit.
Ben Aston:
Tack så mycket, Natalie, för att du var med. Det har varit mycket hjälpsamt att förstå mer om hur du arbetar och om tipsen du har samlat, så att vi alla kan lära oss av dem. Om du lyssnar på podden och vill bidra till samtalet får du gärna dela dina tankar som kommentarer på Natalies inlägg på thedigitalprojectmanager.com. Vi har också ett Slack-team. Via communitysektionen på Digital Project Manager kan du registrera dig och fortsätta samtalet där.
Tack för att du var med, Natalie. Vi ser fram emot att ha en ny podd med dig snart.
Natalie Semczuk:
Tack så mycket.
