Har du någonsin lyckats genomföra ett superkort projekt? Lär dig praktiska tips för korta projekt i det här avsnittet, där PM Jenna Trunzo berättar om fallstudien hon genomförde efter att ha lett ett tvåveckorsprojekt. Lär dig vad som fungerade och varför – och vad hon behövde ändra för att kunna leverera ett projekt inom en så kort tidsram.
Den här podden är en del av en artikel som publicerats på The Digital Project Manager.
Du kan läsa artikeln här.
Den här podden presenteras av Clarizen, ledande inom programvara för företagsprojekt och projektledning.
Relaterade länkar:
- DPM-fallstudie: Att leda ett tvåveckorsprojekt
- Clarizen | Programvara för projektledning
- Så uppskattar du projekt: Den kompletta guiden till projektbudget och kostnadsberäkning
- Bli projektledare (så här gör du!)
- 7 viktiga färdigheter inom projektledning
- Agilt eller vattenfall. Vad bör du använda för ditt projekt?
- Expertgranskning: 10 av de bästa verktygen för projektledning
- Gå med i vårt Slack-team för projektledare
Läs transkriptet:
Vi testar att transkribera våra poddar med hjälp av ett datorprogram. Ursäkta eventuella stavfel eftersom boten inte är korrekt till 100 procent av gångerna.
Ben Aston:
Välkommen till DPM-podden, där vi går bortom teorin för att ge expertråd till projektledare som vill leda bättre digitala projekt. Tack för att du lyssnar. Jag är Ben Aston, grundare av The Digital Project Manager. I den digitala vilda västern som vi kallar hem är det inte särskilt överraskande att få ett projekt med en liten budget, ett ganska otydligt omfång och en snäv tidsplan. Men vad gör man om den där korta tidsplanen bara är två veckor? I dagens podd ska vi gå igenom hur du effektivt kan planera och genomföra ett projekt när det, ärligt talat, inte finns tillräckligt med tid för att göra det ordentligt. Fortsätt lyssna om du vill ta reda på vad du kan skära bort och vilken typ av genvägar som kan sänka projektet.
Ben Aston:
I dag har jag med mig Jenna Trunzo. Jenna är certifierad ScrumMaster, även certifierad produktägare och projektledare på Globant – åtminstone tror jag att det är så man uttalar det. Det är ett företag i Raleigh i North Carolina. Vi ska prata lite om hennes väg till att bli projektledare, något hon beskriver som en lycklig slump. Vi ska ta reda på vad den olyckan var. Nu använder hon sina kunskaper för att driva team framåt på denna byrå, som pratar mycket om agilt arbetssätt. Det vill jag också prata om, men hej Jenna. Trevligt att ha dig med i programmet i dag.
Jenna Trunzo:
Hej Ben, tack så mycket för att jag fick komma, och bra jobbat – du uttalade det korrekt. Det är Globant.
Ben Aston:
Globant. Vet du vad Globant betyder? Är det bara ett namn som liknar globalt, eller vad betyder Global?
Jenna Trunzo:
Jag skulle gärna hitta på en tjusig historia som fick det att låta intressant, men jag vet faktiskt inte.
Ben Aston:
Jag brukade arbeta på en byrå som hette FCV och folk ville alltid veta vad FCV stod för.
Jenna Trunzo:
Just det.
Ben Aston:
Sanningen var att det inte stod för någonting. Det hade tidigare stått för False Creek Ventures, men det låter inte som … A, det låter inte bra, och B, det låter egentligen inte som en byrå.
Jenna Trunzo:
Så ni hittade bara på historier?
Ben Aston:
FCV var det. Ja. Tyvärr låter FCV som alla möjliga saker när man säger det i telefon, bland annat STD.
Jenna Trunzo:
Just det, vilket inte är särskilt trevligt.
Ben Aston:
Nej, så man måste vara försiktig.
Jenna Trunzo:
Absolut.
Ben Aston:
Nåväl, nog om namn. Berätta lite om vad du gör på Globant.
Jenna Trunzo:
Visst. Jag är projektledare här på Globant. Vi gör allt från datamigrering till artificiell intelligens. Allt är projektbaserat och det beror verkligen på projektet. Jag har arbetat med allt från mycket små projekt till det projekt jag arbetar med nu, som är ganska stort. Det finns en stor variation här. Vi är ungefär 8 000 personer totalt i företaget. Jag sitter här i Raleigh. Vi är omkring 150 personer på det här kontoret.
Ben Aston:
Bra. Berätta först lite om din historia. Du beskriver den som en lycklig slump. Vad var det som hände? Du var grafisk designer, blev marknadschef och sedan projektledare. Vad var den lyckliga slumpen?
Jenna Trunzo:
Ja. Jag är säker på att det finns människor där ute som tidigt arbetar inom kreativa områden. När jag gjorde det outsourcades mycket arbete och det fanns inte särskilt många lediga jobb. Jag kommer ursprungligen från Pittsburgh i Pennsylvania, och det var där jag arbetade inom det området. Det fanns helt enkelt inte så mycket. När jag flyttade till North Carolina tog jag ett jobb som marknadschef för ett fastighetsteam och ägnade större delen av tio år åt det. Jag tyckte verkligen om det, men i grunden arbetade jag faktiskt med projektledning – vi kallade det bara inte så.
Ben Aston:
Just det.
Jenna Trunzo:
Jag kände några personer som arbetade på det här företaget och hade berättat för dem att jag var lite missnöjd där jag befann mig då. De sade: ”Du borde verkligen titta närmare på det här företaget. Vi anställer projektledare just nu. Det låter väldigt likt det du gör.” Jag sade: ”Jag har ingen erfarenhet av teknikbranschen. Jag vet inte. Jag vet inte.” Jag sköt upp det ett tag, men till slut övertalade de mig och jag sökte jobbet. Det har faktiskt varit ett av de bästa besluten jag har fattat, så det var en lycklig slump.
Ben Aston:
Fantastiskt. Du har sagt att du i praktiken arbetade med projektledning redan tidigare, men när du började på Globant – vad upptäckte du då i en stor byrå? Vilka var de stora sakerna du behövde ställa om till eller anpassa när det gällde hur du arbetade?
Jenna Trunzo:
På den mest grundläggande nivån arbetade jag hemifrån. Jag arbetade på distans tidigare. På det här jobbet kommer jag in till ett kontor, vilket också har varit fantastiskt, men det fanns många olika processer att anpassa sig till och många olika typer av arbete beroende på vilka kunder jag arbetade med, vilka krav jag försökte uppfylla och så vidare. Det var definitivt en omställning att gå från fastighetsbranschen till teknik. Det finns, tro det eller ej, vissa likheter, men också mycket ny terminologi på den mest grundläggande nivån, många nya processer och nya sätt att driva projekt som skiljde sig åt. Det var en ganska stor omställning, men en väldigt bra sådan.
Ben Aston:
Jag såg att Globant pratar mycket om agila poddar. Många pratar om agilt arbetssätt och försöker införa det på olika sätt. Poddar är ett av de sätt som verkar fungera. Berätta hur poddarna fungerar. Vilken typ av podd ingår du i och hur fungerar det? Hur leder du din podd?
Jenna Trunzo:
På en övergripande nivå arbetar Globant med flera olika typer av poddar. Det kan till exempel finnas en utvecklingspodd eller en strategipodd. Jag tror att det finns fem totalt. För den här diskussionens skull ingår jag dock i en hybridpodd. I grunden innebär det att man hittar kompetens inom varje roll som passar det projekt man arbetar med och därefter bygger en podd. Det är i princip ett projektteam, men skillnaden är att vi hela tiden utvärderar våra egna mål och vårt ansvar. Utifrån det skapar vi våra egna metoder och mätvärden för att uppnå målen. När podden mognar är tanken att de starkaste medlemmarna, som har levt upp till de här utvärderingarna, ska skapa nya poddar inför nästa projekt. De leder nästa podd.
Ben Aston:
Okej. Hur många personer ingår totalt i podden?
Jenna Trunzo:
Det varierar. Det kan vara allt från tre till tjugo personer. I den jag arbetar i just nu är vi åtta.
Ben Aston:
Hur bemannas podden då? Kommer ett projekt in och tilldelas en podd, som sedan måste komma fram till när eller hur projektet ska levereras?
Jenna Trunzo:
Det är projektet som avgör när och vad vi levererar. Podden skapas i princip för det projektet, såvida den aktuella podden inte arbetar så effektivt att den går direkt från ett projekt till ett annat projekt eller en annan kund. Så fungerar det inte alltid, men i en idealisk värld skulle det göra det. Man skulle stanna kvar i sin podd tills den mognar och delas upp, men tanken är att man ska gå från projekt till projekt.
Ben Aston:
Okej. Poddarna utvecklas alltså hela tiden.
Jenna Trunzo:
Ja.
Ben Aston:
Du sade att du ingår i en hybridpodd. Vanligtvis är projektledare inte en roll inom agilt arbetssätt, särskilt inte Scrum.
Jenna Trunzo:
Nej.
Ben Aston:
Berätta om din roll i podden. Vilka funktioner har du?
Jenna Trunzo:
Det finns mycket traditionell projektledning. Jag tycker att agilt arbetssätt ibland används ganska löst, eller hur?
Ben Aston:
Ja.
Jenna Trunzo:
Jag arbetar med mycket av det traditionella, från budget och omfång till leveranser och sådant. I relation till poddarna handlar det mer om teamets och projektets hälsa, att ansvara för att underhålla podden, dess utvärderingar, mognad och liknande egenskaper.
Ben Aston:
Berätta om utvärderingarna och mognaden. Är det tester som människor gör?
Jenna Trunzo:
Inte nödvändigtvis tester. Det är mer en form av samarbete där man träffas och diskuterar: ”Har vi uppnått de mål vi satte upp för oss själva i början av den här podden?” När vi tillsammans som grupp och team tar fram vår konstitution utvärderar vi var tredje till var sjätte månad ungefär: ”Lever vi upp till detta? Gör vi det på rätt sätt? Behöver vi justera något?” Jag vill tillägga att detta är ett relativt nytt koncept för oss eftersom vi inte har varit en del av Globant särskilt länge. Vi blev uppköpta av Globant för inte så länge sedan och håller därför på att ställa om till deras arbetssätt.
Ben Aston:
Spännande tider väntar alltså.
Jenna Trunzo:
Ja.
Ben Aston:
Jag frågar alltid människor vilka verktyg de använder, om de använder några, eftersom jag tror att projektledare alltid är intresserade av att upptäcka nya och bra verktyg. Vad finns i din verktygslåda som projektledare som du verkligen gillar?
Jenna Trunzo:
Advil, definitivt Advil. Jag skojar bara. Jag har väldigt goda förutsättningar. Jag arbetar i en mycket samarbetsinriktad miljö. Mina kollegor är faktiskt mitt bästa verktyg. Vi bollar hela tiden situationer och projektarbete med varandra för att få en andra åsikt. ”Fungerade det här i ditt projekt? Fungerade det där i ditt?” och så vidare. Men på ren verktygsnivå är det ganska traditionellt. Vi använder Jira mycket. Vi använder Confluence. Google Drive är vår huvudsakliga samlingsplats, och sedan använder vi olika kompletterande verktyg som designerna skickar över eller vill att vi ska arbeta med. Men de tre är våra viktigaste verktyg.
Ben Aston:
De gamla klassikerna.
Jenna Trunzo:
Ja, klassikerna.
Ben Aston:
Bra. Låt oss prata om ditt inlägg. För er som inte har läst det ännu: som jag nämnde i början var det ett projekt på två veckor som Jenna fick ta över. Berätta först hur projektet hamnade hos dig, för för de flesta skulle det räcka att få en mindre hjärtattack om de fick höra: ”Du måste leverera det här projektet, och du har två veckor på dig.” Hur hamnade projektet hos dig och varför tog du dig an det i stället för att avvisa det?
Jenna Trunzo:
Lite av båda. Jag hade möjlighet att ta det, vilket var bra. Ett av mina projekt hade nyligen avslutats, så jag var tillgänglig. Samtidigt arbetar jag på ett företag där man respekterar om man verkligen inte vill arbeta med något. Då flyttar de projektet till någon annan. Men jag tycker om projekt som innehåller lite kreativitet och lite utmaning, så jag hade inget emot att göra det. Jag tänkte att på två veckor kan det väl inte gå alltför illa.
Ben Aston:
Vad skulle kunna gå fel?
Jenna Trunzo:
Vad skulle kunna gå fel på två veckor? Precis.
Ben Aston:
Varför var tidsplanen två veckor? I inlägget berättar du att det fanns användartester planerade. Var det ett godtyckligt datum, eller var det verkligen viktigt att det bara var två veckor?
Jenna Trunzo:
Det var mycket viktigt att det bara var två veckor. Företaget hade planerat in användartester och utgick från att de skulle hinna färdigställa det som behövdes till dess. De var bundna till och hade låst in sig på de användartesterna. Jag känner inte till alla detaljer, men de hade inte lyckats göra det de behövde. De behövde att vi kom in och skapade klickbara prototyper på två veckor, så att de säkert skulle vara redo för de planerade användartesterna.
Ben Aston:
Bra. Projektet löpte alltså över två veckor och ni skapade en fungerande prototyp för användartester. De kunde inte flytta testet. Kan du berätta lite mer om det ni prototypade? För att bygga en verkligt fungerande prototyp som ger bra insikter från användartester måste den vara ganska välutvecklad. Vad var det ni byggde?
Jenna Trunzo:
Företaget ville undersöka hur användargränssnittet på deras apparat uppfattades. Vi skulle ta deras nuvarande gränssnitt på en specifik apparat och prototypa det så att det i princip efterliknade hur en konsument skulle interagera med apparaten. Varje prototyp motsvarade ett helt användarflöde. Det innebar att varje knapp som användaren tryckte på ledde vidare längs en bestämd väg. Vi behövde se till att prototyperna faktiskt ledde användaren genom den vägen.
Ben Aston:
När du säger apparat menar du alltså inte programvara, utan till exempel en ugn?
Jenna Trunzo:
Precis. En varmluftsugn, till exempel.
Ben Aston:
Okej. Ni skapade alltså prototyper. Vad bestod de av? Var det bara bilder av ugnens display?
Jenna Trunzo:
Ungefär. Det var alla tillgängliga knappar och de displayer som visades när man interagerade med knapparna. Om jag till exempel ville automatisera något utifrån en viss typ av mat skulle jag trycka på knapp X, och displayen skulle visa A, B, C, D och E. Men om jag tryckte på knapp Y – vad skulle displayen då visa och hur skulle det uppfylla konsumentens behov?
Ben Aston:
Jag förstår. Wow, användarupplevelse för ugnar.
Jenna Trunzo:
Ja.
Ben Aston:
Var den slutliga prototypen klickbara skisser, eller vad var slutleveransen efter de två veckorna?
Jenna Trunzo:
Det var i grunden klickbara skisser, med lite fler designspecifikationer enligt kundens önskemål. De innehöll mer exakta typsnitt, avstånd och designparametrar som den faktiska apparaten skulle använda. Men ja, i grunden var det klickbara skisser.
Ben Aston:
Var det i Envision?
Jenna Trunzo:
Jag tror att de gjorde det i Envision.
Ben Aston:
På två veckor gick ni alltså från att ha … Det var inte helt från början, eftersom ugnens gränssnitt redan fanns, eller hur?
Jenna Trunzo:
Precis.
Ben Aston:
Ni arbetade bara fram olika flöden på två veckor, så att ni kunde testa om människor förstod ugnen när de använde den?
Jenna Trunzo:
Precis. En av utmaningarna var att kundens designteam hade gett oss fel designspecifikationer från början. Det blir ett problem när man bara har två veckor på sig att producera något och producerar fel sak utifrån deras önskemål. Det var minst sagt ett hinder.
Ben Aston:
När insåg ni att specifikationerna var fel?
Jenna Trunzo:
En sak jag tar upp i min artikel är att man i ett så kort projekt måste ha dagliga avstämningar och demonstrationer. Det gjorde vi, eftersom vi ville upptäcka så tidigt som möjligt om något inte stämde. Det var precis vad som hände. Vi hade dagliga avstämningar med kunden och dagliga uppdateringar om framstegen. De flesta var demonstrationer eller visuella avstämningar. Det blev mycket tidigt uppenbart att de hade gett oss fel information. Som tur var kunde vi korrigera det så snart som möjligt, men det hade vi inte kunnat göra utan den täta kontakten.
Ben Aston:
Tidsplanen och budgeten beskriver du som helt fasta, men hur mycket flexibilitet hade ni i omfånget? Användartesterna skulle uppenbarligen genomföras och det fanns flöden som kunden ville att ni skulle utveckla, men hur flexibla var ni när det gällde hur många skärmar och flöden ni skulle ta fram?
Jenna Trunzo:
Inte särskilt mycket. Vi skulle göra, tror jag, sex flöden och sex fullständiga prototyper. Problemet var att om vi inte producerade alla skulle testningen påverkas, eftersom det ena flödet hängde ihop med nästa. Om vi inte producerade allt, eller om omfånget ändrades över huvud taget, förändrade man hela användarupplevelsen.
Ben Aston:
Fast omfång och fast tidsplan alltså.
Jenna Trunzo:
Ja …
Ben Aston:
Hur planerade ni då? Efter den första dagen insåg ni förstås att designen var fel, men ni hade sex flöden att göra på tio dagar. Hur planerade ni arbetet?
Jenna Trunzo:
I den mån man kan planera något sådant. Det handlade mycket om inledande samarbete med hela teamet. I sådana situationer måste man verkligen utmana sig själv som projektledare, anpassa sig och bryta den traditionella modellen. Som projektledare tenderar vi att låsa in oss i en viss process som vi känner oss bekväma med. Det här slår undan benen på hela den modellen. Man måste hitta sätt att bli effektiv av ren nödvändighet, och det blir en väldigt bra läroupplevelse. Den grundläggande planen kom till genom att vi tittade på kundens material, vad vi behövde ha klart i slutet och kalendern, och sade: ”Okej, i genomsnitt vet vi att vi kan göra ungefär ett flöde på två dagar.” Om man slår ut det fungerade det, eftersom vissa flöden var lite kortare och andra lite längre.
Ben Aston:
Jag förstår.
Jenna Trunzo:
Det var i princip: ”Det här måste göras.” Det fanns inte särskilt mycket variation.
Ben Aston:
Ni hade alltså tio dagar, men arbetet skulle egentligen ta tolv dagar. Ni valde att tidsbegränsa utvecklingen av varje flöde. Det är en utmaning när tidsplanen är snäv, eftersom människor gärna förfinar det första flödet tills det är perfekt och sedan försvinner tiden. Ni planerade ungefär två dagar per flöde.
Jenna Trunzo:
Ja.
Ben Aston:
Tog ni höjd för att det skulle ta längre tid i början och att arbetet sedan skulle gå snabbare?
Jenna Trunzo:
Vi visste att det skulle gå lite snabbare när de grundläggande delarna var på plats. När vi hade fått till en bra demonstration – den första riktigt bra demonstrationen för kunden – visste vi vilken feedback de skulle ge och kunde anpassa oss därefter. Vi kände också till våra utvecklares arbetstakt och hur mycket tid vi hade tilldelats. Det var definitivt en risk, men det är ju det som kännetecknar något så kort.
Ben Aston:
De gjorde alltså inte bara skisserna, utan utvecklade också något?
Jenna Trunzo:
Utvecklarna gjorde den helt klickbar, men det var inte en fullständig utveckling.
Ben Aston:
Efter den första dagen insåg ni alltså att ni hade fått fel specifikationer. Det kostade er en dag, eller åtminstone åt upp en del av planen. Hur anpassade ni planen efter det bakslaget?
Jenna Trunzo:
Vi hade lite budgetflexibilitet i vår marginal. Vi kunde ta in en extra utvecklare under en eller två dagar för att hjälpa till där det behövdes. Det fungerade perfekt. Det påverkade inte våra kostnader särskilt mycket och vi kunde fortfarande leverera inom tidsplanen.
Ben Aston:
Fungerade planen?
Jenna Trunzo:
Ja.
Ben Aston:
Var det tillräckligt med planering?
Jenna Trunzo:
Jag tycker att det var tillräckligt med planering eftersom det inte fanns särskilt mycket utrymme att röra sig på. Arbetet blev klart och blev korrekt, och vi hade en mycket bra relation med kunden när allt var över. Jag tycker att planen fungerade. När jag ser tillbaka på det hade jag försökt få en bättre förståelse från vår tekniska ledare för vilka flöden som skulle kräva mer tid. Då hade jag kanske kunnat hjälpa teamet att justera vilka flöden de arbetade med olika dagar. Han ansvarade dock för utvecklarna och hade mycket god känsla för deras arbetstakt. Jag litade mycket på honom. Det är en del av arbetet – att lita på sitt team.
Ben Aston:
Vilka delar av planen fungerade inte? Var det någonstans som planen föll samman när ni hade planerat två dagar för något?
Jenna Trunzo:
Jag måste säga att jag är väldigt nöjd med hur många saker som kunde ha gått fel men inte gjorde det. Jag är mycket nöjd med resultatet. Jag tycker ändå att jag i början skulle ha hållit kunden lite mer ansvarig och sett till att vi hade exakt det vi behövde innan vi började arbeta. Det verkade som om vi hade det, men om jag fick göra om det skulle jag be dem dubbel- och trippelkolla att det verkligen var exakt det vi skulle arbeta med. Det hade definitivt kunnat spara en dag i projektet.
Ben Aston:
Vilka lärdomar tar du med dig inför nästa projekt av det här slaget? Skulle du planera det annorlunda?
Jenna Trunzo:
Jag tycker att vi gjorde många riktigt bra saker, men det finns tydliga nackdelar och saker man måste offra på vägen. Jag försöker tänka tillbaka och se om det finns något jag verkligen skulle ha …
Ben Aston:
Fanns det några genvägar ni försökte ta, men som ni ändå var tvungna att gå tillbaka och göra ordentligt? I en sådan här situation kan man tänka: ”Vi har inte tid med en ordentlig projektbrief”, och i stället bara samla teamet och prata med dem.
Jenna Trunzo:
Precis.
Ben Aston:
Sedan kommer teamet tillbaka två timmar senare och säger: ”Kan du skriva ner en brief?”
Jenna Trunzo:
Precis.
Ben Aston:
Det finns sådant som att säga: ”Vi kommer inte att ha dagliga Scrum-möten eftersom vi inte har tid”, och sedan inser man att man ändå har dagliga Scrum-möten. Fanns det några genvägar ni försökte ta, men som ni sedan var tvungna att göra ändå?
Jenna Trunzo:
Vi hade ingen formell projektstart, så att säga. Vi satte oss inte ner och gick igenom rollfördelningen. Jag är inte säker på att vi absolut behövde det, men jag tror att det hade varit till stor hjälp att ha mer struktur för hur teamet arbetade, i stället för att alla bara försökte göra det de kunde så snabbt som möjligt.
Ben Aston:
Jag förstår.
Jenna Trunzo:
Inte nödvändigtvis ett uppstartsmöte, utan snarare ett möte för att tydliggöra rollerna – något mycket grundläggande. Det var något vi valde bort, men som vi hade haft nytta av.
Ben Aston:
Ja, för när man arbetar med projekt med så snäv tidsplan vet man att varje minut räknas.
Jenna Trunzo:
Precis.
Ben Aston:
Särskilt den första morgonen när man tänker: ”Okej, vi har två veckor på oss. Vi måste bara börja.” Det svåra är att ge teamet tillräcklig tydlighet så att de vet vart de ska, och så att de kommer överens om stegen på vägen, utan att gå in i minsta detalj. Balansen handlar om att teamet verkligen måste förstå vad som ska göras, varför det ska göras och vad som kommer att göra projektet framgångsrikt.
Jenna Trunzo:
Och vem som ska göra det.
Ben Aston:
Ja, och vem.
Jenna Trunzo:
Exakt.
Ben Aston:
Det kan göra enorm skillnad för teamets effektivitet under resten av tiden, men det är ofta något man missar. Man tänker: ”Vi förstår det, så teamet förstår det säkert också, eftersom det inte är så komplicerat.”
Jenna Trunzo:
Exakt. Det är också något man måste vara försiktig med i relation till kunden, eftersom kunden inte nödvändigtvis har samma kunskaper som vi. De kanske tror att de helt förstår vad vi ska göra, men när vi levererar det säger de: ”Vänta, jag förstår inte alls det här.” Även här tror jag att vi hade kunnat lägga en timme på att definiera saker lite bättre.
Ben Aston:
Bra. Jenna, tack så mycket för att du var med. Det har varit fantastiskt att ha dig här.
Jenna Trunzo:
Tack så mycket. Jag uppskattar verkligen att få prata med dig.
Ben Aston:
Jag undrar vad du tycker. Har du någonsin drivit ett projekt med en vansinnig tidsplan? Hur gick det? Berätta vad du tycker, hur du hanterade det, vilka genvägar du tog och vilka genvägar du försökte ta men som inte fungerade. Gå sedan till TheDigitalProjectManager.com och gå med i vårt Slack-team. Där pågår alla möjliga intressanta samtal om allt som rör digital projektledning. Om du gillade det du hörde i dag får du gärna prenumerera och ta ett par minuter till att lämna en ärlig recension. Vi läser alla recensioner och de hjälper oss verkligen att anpassa programmet och göra det bättre. Det uppskattar vi mycket. Men tills nästa gång: tack för att du lyssnade.
