Red dit projekt med et projektopstartsdokument (med Maik Stettner fra FCV Interactive)
Nogle gange løber projekter af sporet, simpelthen fordi vi går for hurtigt i gang med dem. Ben Aston taler med Maik Stettner om, hvordan vi kan bruge et projektinitieringsdokument eller et projektoplæg til at sikre, at alle er på samme side ved projektets start, så projektopstarter bliver mere effektive.
Denne podcast er en del af en artikel, der er udgivet på The Digital Project Manager.
Du kan læse artiklen her.
Læs transskriptionen:
Vi er i gang med at afprøve transskription af vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.
Ben Aston:
Tak, fordi du lytter med. Jeg er Ben Aston, og dette er The Digital Project Manager-podcasten. Denne podcast er bragt til dig af Clarizen, som er førende inden for software til virksomheds-, projekt- og porteføljestyring. Besøg clarizen.com for at få mere at vide.
Hvis der er én ting, man kan være sikker på med et projekt, er det, at det aldrig kommer til at gå helt efter planen. Men hvorfor kører projekter af sporet? Nogle gange skyldes det ganske enkelt, at vi går i gang med projekter for hurtigt. Vi ser projektets deadline nærme sig, og så ender vi med at starte projektet i en form for blind panik. Men når tingene begynder at gå galt, undrer vi os over hvorfor.
Selvom vi som regel har hele projektets baggrund, strategi, detaljer, krav og succeskriterier gemt et sted i baghovedet, begår vi ofte den fejl at tro, at alle andre også bør kende det hele. Men virkeligheden er, at hvis det ikke er dokumenteret, er der stor sandsynlighed for, at vores team ganske enkelt ikke ved det.
Så i dag skal vi tale om et værktøj, vi kan bruge til at få alle på samme side ved projektets begyndelse. Det er et projektopstartsdokument, eller det, der måske mere almindeligt kaldes et projektbrief. Vi vil derfor give dig indblik i, hvordan du kan oprette et projektopstartsdokument og bruge det til at gøre dine projekter mere effektive.
I dag har jeg selskab af Maik Stettner, en af mine venner og kolleger. Maik er en af vores faste DPM-eksperter hos The Digital Project Manager. Velkommen, Maik.
Maik Stettner:
Hej. Hvordan har du det?
Ben Aston:
Jeg har det godt. Det er dejligt at have dig med. Lad os begynde med at tale om dig og fortælle alle lidt om din historie. Vi arbejder jo sammen, og vi har nu arbejdet sammen i — er det fem år?
Maik Stettner:
Ja, det er mellem fire og fem år nu.
Ben Aston:
Da jeg ansatte Maik, husker jeg, at jeg tænkte: »Jeg ved ikke, om den her fyr kan klare det.« Du kommer nemlig fra en lidt anderledes baggrund end den traditionelle bureauverden. Fortæl os om din historie. Hvordan blev du projektleder i et digitalt bureau?
Maik Stettner:
Jeg har omkring ti års erfaring fra forskellige områder. Jeg begyndte oprindeligt inden for spil og udgivelse, hvor jeg håndterede udgivelser af spil i Europa og Nordamerika. Derefter bevægede jeg mig over i andre områder som medicinske databaser, men generelt altid inden for softwareudvikling og ting, der har med projektledelse, forskellige teams og den slags at gøre. I løbet af min karriere fik jeg også en vis bureauerfaring med appudvikling og lidt indledende webudvikling. Da vi havde vores første samtale om at arbejde sammen, skiftede jeg stort set til fuldtids-webudvikling og bureauarbejde.
Ben Aston:
Ja.
Maik Stettner:
Jeg har nu arbejdet hos mit nuværende firma, FCV, i omkring fire år. Jeg leder projektledelsesteamet i bureauet og er grundlæggende ansvarlig for den samlede levering af projekter og for at sikre, at kunderne er tilfredse med de resultater, vi leverer.
Ben Aston:
Godt. Til dem, der lytter og tænker, at de måske står i en lignende situation — og det hører vi faktisk ret ofte — altså personer, der siger: »Jeg er projektleder, jeg har erfaring med at lede softwareprojekter, men nu overvejer jeg at skifte til et bureau og blive digital projektleder.« Hvordan var den overgang for dig? Hvilke var de vigtigste forskelle, da du gik fra mere af en softwareverden til en verden med digital projektledelse i et bureau? Måske især i måden, man skal lede mennesker eller projekter på?
Maik Stettner:
Først og fremmest er der mange ligheder. Ting, man møder i andre softwareudviklingsbureauer eller inden for andre projektledelsesrelaterede områder, møder man også i et bureau. Man har forskellige teams, projekter kører af sporet af mange forskellige årsager, og man kan bruge de samme taktikker til at få dem tilbage på sporet.
En af de største forskelle for mig, da jeg begyndte, var at forstå og anvende hele idéen om at være meget fokuseret på tid og materialer og mindre arbejdsinkrementer i stedet for større leverancer. Kunder, især inden for det område jeg arbejder med, ønsker mere gennemsigtighed og mere kontrol over de mindre dele af arbejdet. Det kræver mere detaljeret rapportering og generelt en større indsats for at være transparent og forklare kunden præcis, hvad man gør, for at skabe den nødvendige tillid. Det krævede lidt mere arbejde og tilpasning fra min side end i en produktvirksomhed, hvor man arbejder hen imod en lancering, som måske er intern.
Det var den største forskel for mig. Men det var også interessant at se, at når man arbejder — selv inden for et helt andet område — er det ikke afgørende, om man arbejder på et databaseprojekt, et spil eller et websted. Man støder på forholdsvis ens problemer, som kan overføres fra det ene område til det andet. Hvis man bruger de erfaringer, man måske har fået i sit tidligere job, for eksempel god kommunikation og nogle af de almindelige bedste praksisser som projektleder, er der gode chancer for, at man får succes, uanset hvad man bygger.
Ben Aston:
Det er godt. Fortæl os så — du talte om nogle af de udfordringer, man møder igen og igen. Hvilke typiske udfordringer håndterer du i din nuværende rolle, hvor du ikke kun leder projekter, men også leder teams og hele projektledelsesteamet? Når du ser på porteføljestyring og ledelse af en hel række forskellige projekter med modstridende ressourcekrav, hvad møder du så typisk i rollen som leder af PMO-teamet?
Maik Stettner:
Min rolle er mere helhedsorienteret på dette tidspunkt. Jeg sørger grundlæggende for, at alt bliver ved med at bevæge sig, og et af mine primære fokusområder er ressourcer — at sikre, at vi har de rigtige personer til den rigtige opgave og i den rigtige periode.
Ofte må man indgå kompromiser, når ting tager længere tid, men man allerede har et andet projekt planlagt. Så skal man håndtere nogle af de nødvendige justeringer og sikre, at kunderne har en åben kommunikationslinje til mig. Risikoen ved at have en mere helhedsorienteret rolle på et højere niveau er, at man i praksis bliver den eneste anden person, der er ansvarlig for eskaleringer. Det er ikke en rolle, man kun ønsker at have, for så får man grundlæggende kun opkaldene, når folk er vrede.
Det er dog altid godt at spille en mere aktiv rolle i forskellige projekter for at opbygge tillidsfulde relationer og samtidig sikre, at organisationen er ordentligt sat op. Det gælder både ressourcer, drift og generelt samarbejde på tværs, fordi vi har flere kontorer.
For os er det vigtigt at sikre, at medarbejdere fra vores kontor i Toronto kan arbejde godt sammen med vores kontor i Victoria og omvendt. Det er størstedelen af mit fokus. Jeg har stadig nogle kunder, som jeg arbejder tæt sammen med, og jeg laver fortsat en del projektledelse, fordi det stadig er dér, min passion ligger. Jeg kan virkelig godt lide at arbejde for mennesker, så det vil jeg ikke give slip på.
Ben Aston:
Lad os vende tilbage til udfordringen med ressourcestyring. Det er noget, alle, der leder et projektledelsesteam eller arbejder som ressourceansvarlig, kommer til at møde. Hvis du har modstridende projekter, to projektledere på teamet, som begge har deadlines fredag, og de begge har brug for de samme ressourcer — hvad er så din proces for at prioritere? Hvordan beslutter du, hvilket projekt der vinder?
Maik Stettner:
Først ser jeg typisk på projektets prioritet. Har vi deadlines, vi skal nå? Har vi lovet kunden noget? Skal projektet gå i luften på en bestemt dato? Jeg undersøger grundlæggende, om der er noget spillerum med hensyn til tidsplanen.
Det spiller også en rolle, om noget for eksempel er fastlagt i kontrakten. Vi skal sikre, at alt bliver færdigt. Er det bare et projekt, der gerne vil videre og gøre kunden en tjeneste? Det er fint, og det gør vi gerne, hvis vi har tid. Men hvis det andet projekt går i luften om tre dage, kan vi sandsynligvis ikke tage nogen fra det projekt.
Det er udgangspunktet. Ideelt set sker situationen ikke, fordi projektlederen bør forudse bestemte overskridelser og indbygge buffere. Det lyder måske mærkeligt, men jeg forventer også, at mit team kæmper for de ressourcer, de har brug for.
Ofte er de for flinke og siger: »Du kan få den person i en dag.« I sidste ende betyder det, at alles arbejde bliver skubbet. Jeg bryder mig ikke om at stjæle ressourcer, og det er helt uacceptabelt, men på ressourcemøder forventer jeg, at nogen står fast på den tid, de har brug for, og sender problemet videre til den ressourceansvarlige, så det kan blive løst, der kan hentes hjælp ind, eller man kan finde ud af, hvordan det kan balanceres.
Ben Aston:
Måske er det et canadisk ressourceproblem.
Maik Stettner:
Et canadisk dødvande, helt sikkert.
Ben Aston:
Canadiere er for flinke, og det kan vi europæere vist godt sige. Eller er det kun canadiere, der må joke om de degenererede?
Maik Stettner:
Præcis. Jeg ser bestemt også anderledes på dem i Europa.
Ben Aston:
Jeg er altid interesseret i værktøjer. Er der nogle værktøjer, du for nylig har opdaget eller er begyndt at bruge, hvor du tænker: »Det her er fantastisk. Hvorfor begyndte vi ikke at bruge det tidligere?« Hvilken værktøjskasse synes du fungerer godt?
Maik Stettner:
Tænker du på ressourcestyring?
Ben Aston:
Ressourcestyring eller projektstyringsværktøjer generelt.
Maik Stettner:
Vi bruger faktisk en forholdsvis standardiseret værktøjskasse til tidsstyring, og MS Project er ofte overvældende for kunden. Vi eksperimenterer meget med cloudbaserede produkter nu. Project findes for eksempel i en Office 365-version. Vi kigger også på andre løsninger inden for tids- og ressourcestyringssoftware. Jeg har ikke fundet den perfekte løsning, fordi vi har en ret skræddersyet proces, som desværre også delvist er manuel.
Personligt synes jeg ikke rigtig, at det ideelle værktøj til vores behov findes. Mit mål ville være at bygge eller anskaffe noget og derefter tilpasse det til de individuelle behov.
Ben Aston:
Hvad skulle det være? Der er jo mennesker, der laver værktøjer og lytter med. Hvilke ting savner du i værktøjerne, som ville gøre dem brugbare? Eller er processen simpelthen så kringlet eller kompleks, at værktøjerne endnu ikke kan rumme den?
Maik Stettner:
Ikke nødvendigvis. Det er faktisk ret enkelt. Jeg leder grundlæggende efter et værktøj, der kan forbinde simpel tidsstyring og registrering af timer — altså medarbejdernes timesedler — med ressourceplanlægning. Noget som Resource Guru eller andre værktøjer, der gør det muligt at kortlægge, hvad man har brug for, men som også kobler det til økonomien. Især når man arbejder efter tid og materialer, er den enkle beregning antal timer gange faktureringssats. Derefter skal hele rapporteringsforløbet kunne sættes op gennem det.
Det lyder enkelt, men der er mange ting at tage hensyn til, når det gælder sandsynligheden for, at projekter ændrer sig, og hvordan systemerne håndterer det. Det kan forvrænge rapporteringen og tilføre så meget ekstra manuelt arbejde, at målingerne ikke stemmer overens. Jeg har endnu ikke fundet den perfekte løsning.
Ben Aston:
Lad os tale om den artikel, du skrev om projektopstartsdokumenter, eller projektopstartsdokumenter som forkortet PID. Som jeg nævnte i introduktionen, går projekter galt, og jeg tror ofte, at det skyldes, at vi ikke starter dem ordentligt. Vi antager, at teamet ved bestemte ting, eller giver dem en bunke dokumenter og siger: »Gå ind på det fælles drev og læs dokumenterne. Det hele står der.« Vi tror, de vil gennemgå materialet og komme ajour, og når de så fejler spektakulært, ved vi ikke hvorfor. Men i virkeligheden skyldes det, at de ikke forstår projektet.
Lad os tale om, hvordan vi kan gøre det bedre, skrive bedre projektbriefs eller — for at bruge projektledelsessprog — oprette et projektopstartsdokument. Kan du sætte scenen lidt og fortælle om din proces for at starte projekter? Hvor passer projektopstartsdokumentet eller projektbriefet ind? Hvornår opretter du det, og hvad gør du for at komme frem til det punkt, hvor du kan skrive dokumentet?
Maik Stettner:
Lad os antage, at du har en ny kunde. Du er begejstret, fordi den overordnede kontrakt er underskrevet. Det er måske en overordnet rammeaftale eller noget tilsvarende, der siger, at din virksomhed og den anden virksomhed skal begynde at arbejde sammen. Det næste skridt for mig er altid at finde ud af, hvordan vi omsætter det til mere konkrete skridt og konkrete vilkår.
Et arbejdsomfangsdokument er typisk det, man kommer til at tænke på. Problemet er, at alt meget tidligt i projektet er på et ekstremt højt niveau. Det er kun et skøn over, hvad man i sidste ende kommer til at lave. Projektopstartsdokumentet og opstartsmøder er gode værktøjer til at lære kunden at kende og høre, om der er andre faktorer, som ikke blev taget i betragtning i de første arbejdsomfangsbriefs.
Når det indledende arbejdsomfangsdokument er udarbejdet — og det kan stadig være et udkast — beslutter teamet sig internt i bureauet. Vi holder en intern opstart for at få alle med på, hvad vi laver, og derefter en ekstern opstart med kunden på et mere overordnet niveau. Her forklarer vi: Det er det, vi skal lave. Dette er teamet. Sådan samarbejder vi. Dette er det omfang, vi har defineret indtil videre.
For mig er projektopstartsdokumentet eller projektbriefet det næste skridt mod at gøre tingene mere konkrete. På det tidlige tidspunkt i processen skal man dog behandle det som et levende dokument, fordi det endnu ikke er helt klart, hvor man ender i alle detaljer. Det er et fremragende værktøj til at skabe forretningsmæssig kontekst og sikre, at de mest grundlæggende projektparametre er tydelige — ikke kun for kunden, men også for det interne team.
Ben Aston:
I begynder altså med et overordnet arbejdsomfangsdokument eller en form for juridisk aftale mellem jer og kunden. Det er det punkt, hvor grundlaget for arbejdsomfangsdokumentet og rammeaftalen er fastlagt, og hvor projektbriefet ligger oven på dette eller arbejder sammen med det for at definere nogle ting mere tydeligt.
I din artikel beskriver du nogle af de ting, det bør indeholde. Du taler om at skabe kontekst, projektspecifikke parametre, projektets nedbrydning, hvem der er hvem på projektet og risikostyring. Lad os begynde med konteksten. Når du samler dette dokument og giver projektteamet kontekst, hvordan gør du det uden at forvirre folk eller overvælde dem med information? Hvordan afgør du, hvad der er støj i forhold til det faktiske projekt, og hvad der rent faktisk er nyttigt?
Maik Stettner:
Jeg tror, det handler om, hvorfor kunden gennemfører projektet, og hvilke problemer der skal løses på et overordnet niveau. Er der forretningsmæssige drivkræfter bag? Vil de øge salget, eller vil de oplyse en målgruppe om, hvad de laver? Er der tale om en rebranding? Og det centrale spørgsmål er: Hvordan defineres succes? Hvordan ved vi til sidst — og husk, at vi stadig befinder os på et ret højt niveau — om vi er lykkedes?
Det kan være så enkelt som bedre salgssamtaler eller for eksempel et selvbetjeningswebsted, der henter alt indhold ind i et indholdsstyringssystem. Det er vigtigt at sætte scenen for teamet og sikre, at de ved, hvad de arbejder hen imod. Selvom trinnene måske ikke er beskrevet i detaljer på dette tidspunkt, hjælper det med at indramme den samlede aktivitet.
Hvis du for eksempel arbejder på et rebrandingprojekt, og målet er at repositionere en virksomhed, og nogen ved projektets afslutning spørger: »Hvorfor steg mit salg ikke?«, kan du gå tilbage og sige: »Det var ikke rigtig projektets mål eller konteksten for projektet. Der kan være resultater, som påvirker det positivt, men det var ikke projektets fokus.«
Det er altid godt at have en dokumenteret oversigt over, hvad der oprindeligt blev drøftet, og at være enige med kunden om det overordnede mål.
Ben Aston:
Det er virkelig nyttigt. Projektets kontekst er altid god at have, medmindre der reelt er tale om vedligeholdelsesarbejde, hvor man ikke behøver kende den overordnede strategi for at vedligeholde eller reparere noget. Men hvis vi skaber noget nyt, er konteksten — hvorfor kunden gennemfører projektet, hvad vi forsøger at løse, forretningsmålene og hvordan succes ser ud — afgørende for at give teamet den baggrund, der hjælper dem med at forme løsningen.
Lad os tale om projektparametre. Du nævnte, at konteksten på én måde handler om projektparametre: Vi indrammer, hvordan projektet passer ind i det større billede af det, kunden strategisk forsøger at opnå. Men i selve briefet, hvilke parametre forsøger du at definere? Du begrænser i bund og grund teamet. Hvad forsøger du at afgrænse, og på hvilke måder er det godt at begrænse teamet?
Maik Stettner:
Man ønsker ikke at begrænse eksperterne. Problemet er, at hvis man giver dem fuldstændig frihed, kan de komme til at arbejde på et helt andet projekt end det, man forestillede sig. Det er vigtigt at give dem en ramme og de grundlæggende begrænsninger — blandt andet budget, tidslinje og den overordnede tidsplan. Ideelt set har man vurderet dette sammen med en del af teamet, så det ikke bør være nyt for dem, og de bør vide, at kunden har et bestemt budget.
Det er meget værdifuldt at gennemgå disse ting. Teamet skal også forstå, at det ikke er en begrænsning, men det, der er aftalt: Hvad skal leveres til kunden for et bestemt budget? Hvis noget ændrer sig fra teamets perspektiv, fordi nogen tænker: »Jeg har brug for mere tid til det her«, er det teamets opgave at finde ud af, hvordan det stadig kan lade sig gøre.
Det er godt at tage denne overordnede teamdiskussion og ikke give teamet indtryk af, at du gør deres liv sværere, men i stedet sætte dem i stand til at gøre det, de skal. Sørg for, at de forstår, at du støtter dem, når det gælder potentielle budgetforøgelser, risici, du måske allerede kan se, og ændringer i tidsplanen.
I sidste ende skal teamet være trygt ved leverancen og begejstret for at begynde på projektet — ligesom kunden — fordi de også gerne vil have tingene gjort.
Ben Aston:
Lad os tale om nogle af de andre ting, man bør inkludere. Vi vil ikke afsløre hele artiklen for dem, der endnu ikke har læst den, men én sidste ting, jeg gerne vil tale om, er at inkludere en projektnedbrydning, en arbejdsnedbrydningsstruktur og en form for ressourceplan i projektopstartsdokumentet eller projektbriefet. Når tingene i begyndelsen er ret udefinerede, hvordan laver du så en foreløbig plan? Hvordan når du frem til en grov plan, før projektet er begyndt, når du endnu ikke ved, hvordan det reelt kommer til at forløbe?
Maik Stettner:
For at være ærlig er det nok et kvalificeret gæt på det tidspunkt. Man baserer det sandsynligvis på arbejdsomfangsdokumentet, det der allerede findes, eller det estimat, teamet har udarbejdet. Der er stadig mange ubekendte. Er kunden hurtig til at svare? Har vi brug for et antal revisioner? Har vi defineret tingene tilstrækkeligt? Der er mange muligheder, og den plan, man lægger, kommer måske ikke til at holde præcis som den er.
Men som jeg sagde tidligere, er det også grunden til, at jeg mener, at selv en tilnærmet plan hjælper bureauet og de andre projektteams med at sikre de rigtige ressourcer og holde teamet stabilt. Det er nyttigt at lave en indledende plan, selv hvis den er ambitiøs og stadig kræver kundens accept. Kunden kan måske sige efter det første eller andet møde: »Vi har brug for mere tid. Det er ikke realistisk.« Uanset hvad hjælper det med at kortlægge tingene fra dit perspektiv og forstå nogle af de detaljer, teamet skal igennem.
Har du for eksempel brug for en designer, du ikke havde tænkt på? Hvis du får teamet til at tale om den slags tidligt, forstår du som projektleder, hvad der skal til for at levere projektet. Det hjælper dig med at stille de rigtige spørgsmål og styre kunden i den rigtige retning. Selv en grov plan eller en tilnærmelse er bedre end ingen plan, fordi folk kan tale om den, og tingene vil sandsynligvis blive mere detaljerede og afspejle virkeligheden bedre, efterhånden som tiden går.
Ben Aston:
Det beskriver i det mindste perspektivet: En eller anden plan er bedre end ingen plan, fordi man altid kan udvikle den. Når man starter et projekt og sætter sig sammen med teamet om projektbriefet, men der ikke er nogen egentlig plan for leveringen, og ingen har tænkt afhængighederne eller kundens rolle i projektet igennem, starter man med meget lidt fremdrift. Man sidder og siger: »Okay team, hvordan får vi det her gjort?«
Hvis du kommer til dem med en plan, har de i det mindste noget at reagere på og sige: »Maik, du er vanvittig. Hvordan i alverden skal vi gøre det?« Det giver et udgangspunkt for en diskussion i stedet for et blankt stykke papir, hvor alle bare kigger på hinanden og tænker: »Hvordan i alverden skal det her leveres?« Selv hvis planen er forkert, er en eller anden plan bedre end ingen plan.
Vi har talt om projektbriefet og projektopstartsdokumentet, som lyder som et meget alvorligt dokument. Men det behøver vel ikke nødvendigvis at være et stort, formelt dokument? Grundlæggende giver vi kontekst, parametre og en plan. Hvilke andre former kan projektbriefet have, og hvordan ser du dets rolle udvikle sig gennem projektets livscyklus?
Maik Stettner:
Den guide, jeg har lavet, er grundlæggende et eksempel på ting, man kan inkludere. Der er bestemt et minimum af information, som bør være i et projektopstartsdokument eller projektbrief, men der er naturligvis andre måder at gøre det på. Man kan for eksempel have en separat risikostyring og koble den sammen med noget andet. Eller et RACI-diagram, der kobles til statusrapporter og så videre.
Det behøver ikke altid være ekstremt formaliseret. Det vigtigste er, at alle er enige om det. Det kan være lagt på SharePoint eller BaseCamp, og det kan godt blive ændret undervejs, mens man har samtaler om det. Hvis projektet for eksempel når til et punkt, hvor alle er enige om: »Da vi afgrænsede dette, glemte vi salgsaspektet, så vi skal inkludere det og sikre, at det bliver dokumenteret«, har det naturligvis betydning for omfanget, som skal ændres.
Så længe det er et dokument — selv en formaliseret e-mail — altså noget skriftligt, som folk kan blive enige om, og som bliver anerkendt, er det efter min mening tilstrækkeligt. Det behøver ikke nødvendigvis at være underskrevet og stemplet af alle parter, men som minimum skal det anerkendes, og alle skal være indforståede med det, fordi det er det, der skal leveres, og det, arbejdet udføres efter.
Ben Aston:
Den gode nyhed er, at hvis du stadig sidder efter at have lyttet og tænker: »Det lyder godt, men hvor begynder vi?«, så har Maik lavet en rigtig god skabelon, du kan bruge til dit projektbrief eller projektopstartsdokument. Gå ind på artiklen for at downloade den. Maik, mange tak for i dag. Det har været dejligt at have dig med.
Maik Stettner:
Tak, fordi jeg måtte være med.
Ben Aston:
Det var så lidt. Som en af vores DPM-eksperter kan du være glad for at vide, at Maik medvirker på vores kommende kursus, der starter i september, og som hedder Mesterlig digital projektledelse. Hvis du ikke ved, hvad jeg taler om, men ved, at du har brug for projektlederuddannelse, så kig på det. Det er et intensivt syvugerskursus med interaktive videolektioner, ugentlige opgaver, gruppediskussioner og mulighed for coaching. Gå til digitalprojectmanagerschool.com, og tilmeld dig, før kurset bliver fyldt op.
Hvis du vil bidrage til samtalen om projektopstartsdokumenter eller projektbriefs, kan du gå til ressourceafsnittet på digitalprojectmanager.com og deltage i vores Slack-team, hvor du finder alle mulige interessante samtaler. Husk også at kommentere på artiklen og dele den. Men indtil næste gang: Tak, fordi du lyttede med.
