Har du nogensinde gennemført et meget kort projekt? Få tips fra virkeligheden til korte projekter i denne episode, hvor projektlederen Jenna Trunzo gennemgår det casestudie, hun udførte efter at have ledet et 2-ugers projekt. Lær, hvad der virkede, og hvorfor – og hvad hun var nødt til at ændre for at kunne levere et projekt inden for så kort en tidsramme.
Denne podcast er en del af en artikel, der er udgivet på The Digital Project Manager.
Du kan læse artiklen her.
Denne podcast præsenteres af Clarizen, den førende leverandør af software til virksomhedsprojekter og projektstyring.
Relaterede links:
- DPM-casestudie: Sådan ledes et 2-ugers projekt
- Clarizen | Projektstyringssoftware
- Sådan estimerer du projekter: Den komplette guide til projektbudgetter & omkostningsestimering
- Bliv projektleder (sådan gør du!)
- 7 vigtige færdigheder inden for projektledelse
- Agil eller vandfald? Hvad skal du bruge til dit projekt?
- Ekspertvurdering: 10 af de bedste projektstyringsværktøjer
- Bliv medlem af vores Slack-team for projektledere
Læs transskriptionen:
Vi prø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:
Velkommen til DPM-podcasten, hvor vi går videre end teorien for at give ekspertrådgivning til projektledere, så de kan lede bedre digitale projekter. Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager. I det digitale vilde vesten, som vi kalder vores arbejdsplads, er det ikke ligefrem overraskende at få et projekt med et lille budget, et ret uklart omfang og en stram tidsplan. Men hvad gør du, hvis den korte tidsplan kun er to uger? I dagens podcast gennemgår vi, hvordan du effektivt kan planlægge og gennemføre et projekt, når der ærligt talt ikke er tid nok til at gøre det ordentligt. Lyt med, hvis du vil finde ud af, hvad du kan skære væk, og hvilken form for genveje der kan få dit projekt til at mislykkes.
Ben Aston:
I dag har jeg Jenna Trunzo med. Jenna er certificeret ScrumMaster, certificeret produktejer og projektleder hos Globant – i hvert fald tror jeg, det er sådan, man udtaler det. Det er en virksomhed i Raleigh, North Carolina. Vi skal tale lidt om hendes vej til at blive projektleder, som hun beskriver som et lykkeligt tilfælde. Vi finder ud af, hvad det tilfælde var. Nu bruger hun sine kompetencer til at drive teams fremad i dette bureau, hvor de taler meget om Agile. Det vil jeg også gerne tale om, men hej Jenna. Det er dejligt at have dig med i programmet i dag.
Jenna Trunzo:
Hej Ben, tusind tak fordi du inviterede mig, og godt gået – du udtalte det korrekt. Det er Globant.
Ben Aston:
Globant. Ved du, hvad Globant betyder? Er det bare et navn, der minder om global, eller hvad?
Jenna Trunzo:
Jeg ville gerne opfinde en smart historie, der kunne få det til at lyde interessant, men jeg ved det faktisk ikke.
Ben Aston:
Jeg arbejdede tidligere for et bureau, der hed FCV, og folk ville altid vide, hvad FCV stod for.
Jenna Trunzo:
Nemlig.
Ben Aston:
Sandheden var, at det ikke stod for noget. Det havde tidligere stået for False Creek Ventures, men det lyder ikke som noget… For det første lyder det ikke godt, og for det andet lyder det ikke rigtig som et bureau.
Jenna Trunzo:
Så du fandt bare på historier?
Ben Aston:
FCV var navnet. Ja. Men når man siger FCV i telefonen, kan det desværre lyde som alle mulige ting, blandt andet STD.
Jenna Trunzo:
Ja, og det er ikke særlig rart.
Ben Aston:
Nej, så man skal passe på.
Jenna Trunzo:
Helt sikkert.
Ben Aston:
Nå, nok om navne. Fortæl os lidt om, hvad du laver hos Globant.
Jenna Trunzo:
Jeg er projektleder her hos Globant. Vi laver alt fra datamigrering til kunstig intelligens. Alt er projektbaseret, og det afhænger virkelig af opgaven. Jeg har arbejdet på alt fra meget små projekter til det projekt, jeg arbejder på nu, som er ret stort. Der er stor variation her. Vi er omkring 8.000 medarbejdere i virksomheden i alt. Jeg sidder her i Raleigh, hvor vi er omkring 150 på kontoret.
Ben Aston:
Fedt. Fortæl os først lidt om din historie. Du beskriver den som et lykkeligt tilfælde. Hvad var tilfældet? Du var grafisk designer, blev marketingchef og derefter projektleder. Hvad var det lykkelige tilfælde, der skete? Fortæl os om det.
Jenna Trunzo:
Ja. Jeg er sikker på, at der er mennesker derude, som tidligt i deres karriere arbejder inden for kreative fag. Da jeg arbejdede med det, blev meget arbejde outsourcet, og der var ikke mange ledige stillinger. Jeg kommer oprindeligt fra Pittsburgh i Pennsylvania, og det var dér, jeg arbejdede inden for det felt. Der var simpelthen ikke ret meget. Da jeg flyttede til North Carolina, fik jeg et job som marketingchef for et ejendomsteam, og jeg brugte det meste af de næste ti år på det. Jeg nød det virkelig, men i bund og grund lavede jeg faktisk projektledelse – vi kaldte det bare ikke det.
Ben Aston:
Okay.
Jenna Trunzo:
Jeg kendte nogle mennesker, der arbejdede i denne virksomhed, og jeg havde fortalt dem, at jeg på det tidspunkt var lidt utilfreds med mit arbejde. De sagde: »Du burde virkelig undersøge denne virksomhed. Vi ansætter projektledere lige nu. Det lyder meget som det, du allerede laver.« Jeg sagde: »Jeg har ingen erfaring fra teknologiverdenen. Det ved jeg ikke rigtig.« Jeg skubbede det lidt foran mig, men til sidst fik de overtalt mig, og jeg søgte. Det har været en af de bedste beslutninger, jeg har truffet, så det var et lykkeligt tilfælde.
Ben Aston:
Fantastisk. Du har fortalt, at du reelt lavede projektledelse i forvejen, men da du kom til Globant, hvad opdagede du så i et stort bureau? Hvad var de vigtigste ting, du skulle omstille dig til eller tilpasse i forhold til din måde at arbejde på?
Jenna Trunzo:
På det helt grundlæggende niveau arbejdede jeg hjemmefra. Jeg arbejdede allerede på afstand. I dette job kom jeg ind på et kontor, hvilket også har været fantastisk, men der var mange forskellige processer, jeg skulle tilpasse mig, og meget forskelligt arbejde i forhold til de klienter, jeg arbejdede med, de krav jeg skulle imødekomme og den slags. Det var bestemt en omstilling at gå fra ejendomme til teknologi. Der er, tro det eller ej, nogle ligheder, men der er også meget ny terminologi på det helt grundlæggende niveau, mange nye processer og nye måder at arbejde med et projekt på. Det var en ret stor omstilling, men en rigtig god en.
Ben Aston:
Jeg ved, at Globant taler meget om Agile-teams. Mange taler om Agile og forsøger at implementere det på forskellige måder. Teams er én af de måder, der ser ud til at fungere. Fortæl os, hvordan de fungerer. Hvilket team er du en del af, og hvordan arbejder det? Hvordan leder du dit team?
Jenna Trunzo:
På et overordnet niveau arbejder Globant med flere forskellige typer teams. Der kan for eksempel være et udviklingsteam eller et strategiteam. Jeg tror, der er fem i alt. I denne sammenhæng er jeg i et hybridteam. Det betyder grundlæggende, at man finder de rette talenter til hver rolle ud fra det projekt, man arbejder på, og derefter opbygger man et team. Det er i bund og grund et projektteam, men forskellen er, at vi løbende vurderer vores egne mål og vores ansvarlighed. På baggrund af det skaber vi vores egne metoder og målepunkter for at nå målene. Efterhånden som teamet modnes, er tanken, at de stærkeste medlemmer, som har levet op til disse vurderinger, skal danne nye teams til det næste projekt. De leder det næste team.
Ben Aston:
Hvor mange mennesker er der i teamet i alt?
Jenna Trunzo:
Det varierer. Det kan være alt fra 3 til 20. I det team, jeg er i nu, er vi otte.
Ben Aston:
Hvordan bliver teamet så bemandet? Kommer der et projekt ind, som bliver tildelt et team, der derefter skal finde ud af, hvornår og hvordan projektet skal leveres?
Jenna Trunzo:
Det er projektet, der afgør, hvornår og hvad vi skal levere. Teamet bliver oprettet til projektet, medmindre det pågældende team arbejder så effektivt, at det går direkte fra det ene projekt eller den ene klient til den næste. Sådan sker det ikke altid, men i en ideel verden ville det være sådan. Man bliver i sit team, indtil det modnes og deles op, og derefter går man videre fra projekt til projekt.
Ben Aston:
Så teams udvikler sig hele tiden.
Jenna Trunzo:
Det gør de.
Ben Aston:
Du sagde, at du er i et hybridteam. I Agile, og især i Scrum, er projektleder normalt ikke en rolle.
Jenna Trunzo:
Nej.
Ben Aston:
Fortæl os om din rolle i teamet. Hvilke funktioner varetager du?
Jenna Trunzo:
Der er meget traditionel projektledelse. Jeg synes nogle gange, at Agile bruges lidt løst. Jeg arbejder med alt fra budget og omfang til leverancer og den slags, men i relation til teamet handler det mere om teamets og projektets sundhed. Jeg har ansvaret for at vedligeholde teamet, dets vurderinger, dets modenhed og den slags egenskaber.
Ben Aston:
Fortæl os om vurderinger og modenhed. Er det tests, som folk tager?
Jenna Trunzo:
Ikke ligefrem tests. Det er mere en form for samarbejde, hvor man samles og taler om, hvorvidt man har nået de mål, man satte for sig selv i begyndelsen af teamets arbejde. Når vi som gruppe og team udarbejder vores grundlag, vurderer vi hver tredje til sjette måned, om vi lever op til det, om vi gør det på den rigtige måde, og om noget skal justeres. Jeg vil dog understrege, at dette er et forholdsvis nyt koncept for os, fordi vi blev opkøbt af Globant for ikke så længe siden, og derfor er vi i gang med at overgå til deres måde at arbejde på.
Ben Aston:
Det bliver spændende tider.
Jenna Trunzo:
Ja.
Ben Aston:
Jeg spørger altid folk, hvilke værktøjer de bruger, fordi jeg tror, at projektledere altid er interesserede i at høre om nye og spændende værktøjer. Hvad har du i din værktøjskasse som projektleder, som du er stor fan af?
Jenna Trunzo:
Ibuprofen, helt sikkert ibuprofen. Jeg laver bare sjov. Jeg er meget heldig. Jeg arbejder i et meget samarbejdsorienteret miljø. Mine kolleger er faktisk mit vigtigste værktøj. Vi vender hele tiden situationer og projektarbejde med hinanden for at få en ekstra vurdering. »Fungerede det på dit projekt? Fungerede det dér på dit?« og så videre. Hvis vi taler om konkrete værktøjer, er de ret traditionelle. Vi bruger Jira meget. Vi bruger Confluence. Google Drev er vores primære samlingspunkt, og derefter bruger vi forskellige andre værktøjer, som designerne sender over eller har brug for, at vi arbejder med. Men de tre er vores vigtigste værktøjer.
Ben Aston:
De klassiske.
Jenna Trunzo:
Ja, de klassiske.
Ben Aston:
Lad os tale om dit indlæg. For dem, der ikke har læst det endnu: Som jeg nævnte i begyndelsen, var det et projekt på to uger, som Jenna fik tildelt. Fortæl os først, hvordan projektet overhovedet endte hos dig. For de fleste ville det være nok til at give et mindre hjerteanfald at få at vide: »Du skal levere dette projekt, og du har to uger.« Hvordan endte projektet hos dig, og hvorfor tog du det på dig i stedet for at afvise det?
Jenna Trunzo:
Lidt af begge dele. Jeg havde tid til rådighed, så det var godt. Et af mine projekter var netop afsluttet, så jeg var ledig. Samtidig arbejder jeg i en virksomhed, hvor de respekterer, hvis man virkelig ikke ønsker at arbejde på noget. Så flytter de det til en anden. Men jeg kan godt lide projekter, der rummer lidt kreativitet og lidt udfordring, så jeg havde ikke noget imod at gøre det. Jeg tænkte: »Hvor galt kan det gå på to uger?«
Ben Aston:
Hvad kunne dog gå galt?
Jenna Trunzo:
Hvad kunne dog gå galt på to uger? Ja.
Ben Aston:
Hvorfor var tidsplanen to uger? I indlægget taler du om, at der var planlagt nogle tests. Var datoen tilfældig, eller var det virkelig vigtigt, at det kun var to uger?
Jenna Trunzo:
Det var meget vigtigt, at det kun var to uger. Virksomheden havde planlagt brugertests ud fra en antagelse om, at de kunne nå det, de skulle nå inden da. De var bundet til disse brugertests, selv om jeg ikke kender alle deres betingelser. De var ude af stand til at gøre det, de havde brug for, og derfor skulle vi komme ind og lave disse klikbare prototyper på to uger, så de var klar til de planlagte brugertests.
Ben Aston:
Så I havde to uger til at skabe en funktionel prototype til nogle brugertests. Kan du fortælle lidt mere om, hvad I prototypede? For at kunne bygge en funktionel prototype, der virkelig fungerer, og som kan give gode indsigter fra brugertests, skal den være ret gennemarbejdet. Hvad byggede I?
Jenna Trunzo:
Virksomheden undersøgte, hvordan brugergrænsefladen på deres husholdningsapparat fungerede. Vi skulle tage den aktuelle grænseflade på et bestemt apparat og lave en prototype, som efterlignede den måde, en forbruger ville interagere med apparatet på. Hver prototype svarede til et komplet brugerflow. Den knap, man trykkede på, skulle føre brugeren videre til det næste trin. Vi skulle sikre os, at prototyperne faktisk førte brugeren gennem den rigtige vej.
Ben Aston:
Når du siger et husholdningsapparat, taler du så ikke om software, men om for eksempel en ovn?
Jenna Trunzo:
Korrekt. Ja, for eksempel en varmluftsovn.
Ben Aston:
Så prototyperne var billeder af ovnens display?
Jenna Trunzo:
Noget i den retning. Alle knapperne var tilgængelige, og derefter viste displayet forskellige ting, efterhånden som man interagerede med knapperne. Hvis jeg for eksempel ville automatisere tilberedningen baseret på en bestemt type mad, kunne jeg trykke på knap X, hvorefter displayet viste A, B, C, D og E. Hvis jeg trykkede på knap Y, hvad skulle displayet så vise, og hvordan opfyldte det forbrugerens behov?
Ben Aston:
Wow, ovn-brugeroplevelse.
Jenna Trunzo:
Ja.
Ben Aston:
Var den endelige prototype klikbare wireframes, eller hvad var det endelige resultat efter de to uger?
Jenna Trunzo:
Det var grundlæggende klikbare wireframes med lidt flere designspecifikationer efter klientens ønske. De indeholdt de præcise skrifttyper, afstande og designparametre, som det faktiske apparat skulle bruge, men ja, grundlæggende var det klikbare wireframes.
Ben Aston:
Var det i Envision?
Jenna Trunzo:
Jeg mener, at de lavede det i Envision.
Ben Aston:
I løbet af to uger gik I altså fra at have en eksisterende grænseflade til at udvikle forskellige flows, så I kunne teste, om folk forstod at bruge ovnen?
Jenna Trunzo:
Ja. En af udfordringerne var, at klientens designteam havde givet os de forkerte designspecifikationer fra begyndelsen. Det er en udfordring, når man kun har to uger til at producere noget, og man producerer det forkerte i forhold til deres ønsker. Det var mildest talt en blokering.
Ben Aston:
Hvornår opdagede du, at specifikationerne var forkerte?
Jenna Trunzo:
En af de ting, jeg taler om i min artikel, er, at man i et så kort projekt skal sørge for at have daglige statusmøder og demonstrationer. Det gjorde vi netop, fordi vi ville opdage problemer så hurtigt som muligt. Det var præcis, hvad der skete. Vi havde daglige check-ins med klienten og daglige opdateringer om fremskridt. De fleste var demonstrationer eller visuelle check-ins. Det blev meget tidligt tydeligt, at de havde givet os de forkerte oplysninger. Heldigvis kunne vi rette det hurtigt, men det havde vi ikke kunnet uden den konstante kontakt.
Ben Aston:
Tidsplanen og budgettet var faste, men hvor meget fleksibilitet havde I med hensyn til omfanget? Brugertesten skulle gennemføres, og der var nogle flows, de ville have uddybet, men hvor fleksible var I med hensyn til antallet af skærme og flows?
Jenna Trunzo:
Ikke særlig fleksible. Vi skulle lave, tror jeg, seks flows og seks komplette prototyper. Problemet var, at hvis vi ikke producerede dem alle, ville det påvirke testen, fordi det ene flow var afhængigt af det næste. Hvis omfanget ændrede sig, ændrede man hele brugeroplevelsen.
Ben Aston:
Så fast omfang og fast tidsplan.
Jenna Trunzo:
Ja.
Ben Aston:
Hvordan planlagde du det? Efter dag ét opdagede I naturligvis, at designet var forkert, men I havde seks flows på ti dage. Hvordan planlagde du arbejdet?
Jenna Trunzo:
Så godt som man kan planlægge sådan noget. Det krævede meget indledende samarbejde med hele teamet. I en situation som denne skal man virkelig udfordre sig selv som projektleder, tilpasse sig og bryde med den traditionelle model. Som projektledere har vi en tendens til at låse os fast i en bestemt proces, som vi føler os trygge ved. Dette vender det hele på hovedet. Man er nødt til at finde måder at blive effektiv på af nødvendighed, og det bliver en rigtig god læringsoplevelse. Den grundlæggende plan kom af at se på klientens materialer, på det, vi skulle ende med, og på kalenderen. Vi sagde: »Okay, vi ved, at vi i gennemsnit kan lave ét flow på to dage.« Når man regnede det sammen, fungerede det, fordi nogle flows var lidt kortere og andre lidt længere.
Ben Aston:
Okay.
Jenna Trunzo:
Det var grundlæggende: »Det her skal gøres.« Der var ikke meget variation.
Ben Aston:
I havde reelt ti dage, selv om det ville have taget tolv dage, men I valgte at tidsafgrænse udviklingen af hvert flow til cirka to dage. Det er en af udfordringerne ved en stram tidsplan: Efter det første flow vil folk gerne finpudse det, så det bliver helt rigtigt, og så forsvinder tiden. Planlagde I med, at det ville tage længere tid i begyndelsen, hvorefter teamet ville arbejde hurtigere?
Jenna Trunzo:
Ja. Vi vidste, at de resterende flows ville gå lidt hurtigere, når de grundlæggende ting var på plads. Da vi havde gennemført den første rigtig gode demonstration med klienten, vidste vi, hvilken type feedback vi ville få, så vi kunne tilpasse os. Vi kendte også vores udvikleres arbejdshastighed og de timer, vi havde til rådighed. Det var helt klart en risiko, men det er vilkårene for noget, der er så kort.
Ben Aston:
De lavede altså ikke kun wireframes, men udviklede også noget?
Jenna Trunzo:
Udviklerne gjorde det helt klikbart, men der var ikke tale om en fuld udvikling.
Ben Aston:
Efter dag ét opdagede I, at specifikationerne var forkerte. Det satte jer en dag tilbage eller spiste i hvert fald af planen. Hvordan tilpassede du planen efter det problem?
Jenna Trunzo:
Vi havde en smule budgetfleksibilitet i vores margin. Vi kunne hente en ekstra udvikler ind i en dag eller to for at hjælpe, hvor der var behov. Det fungerede perfekt. Det påvirkede ikke vores egne omkostninger særlig meget, og vi kunne stadig levere inden for tidsplanen.
Ben Aston:
Fungerede planen så?
Jenna Trunzo:
Ja.
Ben Aston:
Var det en tilstrækkelig plan?
Jenna Trunzo:
Jeg synes, det var en tilstrækkelig plan, fordi der ikke var meget spillerum. Det blev færdigt, det blev gjort korrekt, og vi havde et rigtig godt forhold til klienten bagefter. Jeg synes, planen fungerede. Når jeg ser tilbage, ville jeg have forsøgt at få en bedre forståelse fra vores tekniske leder af, hvilke flows der ville kræve mere tid. Så kunne jeg måske have hjulpet med at tilpasse, hvilke flows teamet arbejdede på de enkelte dage. Men han havde ansvaret for udviklerne og havde en rigtig god fornemmelse for deres hastighed. Jeg stolede meget på ham. Det er en del af det: at stole på sit team.
Ben Aston:
Hvilke dele af planen fungerede ikke? Hvor gik tingene i stå undervejs?
Jenna Trunzo:
Jeg må sige, at jeg er meget tilfreds med, hvor mange ting der kunne være gået galt, men ikke gjorde det. Jeg er meget tilfreds med resultatet. Jeg synes dog bestemt, at jeg i begyndelsen skulle have holdt klienten lidt mere ansvarlig og sikret, at vi havde præcis det, vi skulle bruge, før vi begyndte at arbejde. Det virkede, som om vi havde det, men hvis jeg kunne gøre det igen, ville jeg få dem til at dobbelttjekke og tredoble tjekke, at det virkelig var det, vi skulle arbejde med. Det kunne have sparet en dag på projektet.
Ben Aston:
Hvad lærte du af projektet, og hvad ville du gøre anderledes næste gang?
Jenna Trunzo:
Jeg synes, vi traf mange gode beslutninger, men der er klare ulemper og ting, man er nødt til at ofre undervejs. Jeg prøver at tænke tilbage på, om der var noget, jeg virkelig ville have gjort anderledes.
Ben Aston:
Var der nogle genveje, I forsøgte at tage, men som I alligevel måtte gå tilbage og gøre ordentligt? Når tidsplanen er stram, kan man tænke: »Vi har ikke tid til en ordentlig projektbeskrivelse«, så man samler bare teamet og taler med dem. To timer senere kommer teamet tilbage og siger: »Kan du ikke skrive en projektbeskrivelse?« Var der noget, I forsøgte at skære væk, men alligevel måtte gøre?
Jenna Trunzo:
Vi havde ikke et formelt opstartsmøde. Der var ikke en egentlig samtale om rollefordeling. Jeg er ikke sikker på, at vi absolut havde brug for det, men jeg tror, det havde været en hjælp at have mere struktur for, hvordan teamet arbejdede, i stedet for at alle bare forsøgte at få deres del færdig så hurtigt som muligt.
Ben Aston:
Så det var ikke nødvendigvis et opstartsmøde, men mere en session om rollefordeling – noget helt grundlæggende. Det var noget, I skar væk, men som I kunne have haft brug for.
Jenna Trunzo:
Ja.
Ben Aston:
Når man arbejder på projekter med meget stramme tidsplaner, tæller hvert minut. Især den første morgen kan man tænke: »Vi har to uger til det her. Vi skal bare i gang.« Det vanskelige er at give teamet nok klarhed til at vide, hvor de skal hen, og blive enige om trinnene undervejs uden at gå ned i alle detaljer. Man skal være helt sikker på, at teamet forstår, hvad der skal gøres, hvorfor det skal gøres, og hvad der gør projektet vellykket.
Jenna Trunzo:
Og hvem der gør det.
Ben Aston:
Ja, og hvem der gør det.
Jenna Trunzo:
Præcis.
Ben Aston:
Det kan gøre en enorm forskel for effektiviteten resten af tiden, men det er ofte noget, vi springer over. Vi tænker: »Vi forstår det, så teamet må også forstå det, for det er jo ikke så kompliceret.«
Jenna Trunzo:
Præcis. Det er også noget, man skal være opmærksom på i forhold til klienten, fordi de ikke nødvendigvis har samme forståelse som os. De tror måske, at de forstår fuldstændigt, hvad vi skal gøre, men når vi leverer det, siger de: »Vent, jeg forstår slet ikke dette.« Igen tror jeg, vi kunne have brugt en time på at definere tingene lidt bedre.
Ben Aston:
Fedt. Jenna, tusind tak fordi du var med. Det har været fantastisk at have dig med.
Jenna Trunzo:
Tusind tak. Jeg har virkelig sat pris på samtalen.
Ben Aston:
Hvad tænker du? Har du nogensinde gennemført et projekt med en vanvittig tidsplan? Hvordan gik det? Fortæl os, hvad du synes, hvordan du håndterede det, hvilke genveje du tog, og hvilke genveje du forsøgte at tage, men som ikke fungerede. Gå derefter til TheDigitalProjectManager.com og bliv medlem af vores Slack-team. Her finder du alle mulige interessante samtaler om digital projektledelse. Hvis du kunne lide det, du hørte i dag, må du meget gerne abonnere og bruge et par minutter på at skrive en ærlig anmeldelse. Vi læser dem alle, og de hjælper os virkelig med at tilpasse programmet og gøre det bedre. Det sætter vi stor pris på. Men indtil næste gang: tak fordi du lyttede.
