I dette indlæg vil jeg give et eksempel på, hvordan du kan lave en optimal projektplan. En god projektplan kan hjælpe med at få dine kollegaer eller kunder til at forstå projektet, uanset hvor kompliceret projektet er.
Det er derfor ikke altid lige nemt at lave en god projektplan, da det kan være svært at finde ud af, præcis hvilke opgaver, som skal defineres direkte i projektplanen, og hvilke der skal bundles sammen under en overordnet opgave.
I dette indlæg går jeg i dybden med alt dette, så tag dig gerne tiden til at læse det helt igennem. Jeg har inkluderet både video og en masse billeder i dette indlæg, så det er utrolig nemt at følge med trin-for-trin, og du vil med disse råd have en projektplan klar for dit projekt, hvis du følger med undervejs i indlægget.
Hvad er en projektplan?
En projektplan er et dokument, typisk et Gantt diagram, som viser hvert skridt, der skal tages for at gennemføre et projekt fra A til Z. Det viser samtidigt projektlederens tilgang til projektet, projektets slutprodukter eller leverancer, samt projektets fremdrift.
Hvorfor skal man lave en projektplan?
Succesfulde projekter har alle en ting til fælles. Nemlig at de har en konkret projektplan fra starten. I nogle tilfælde ændres planen undervejs i projektet, hvilket er okay, hvis det viser sig, at den oprindelige plan ikke var korrekt, eller at der var bedre muligheder end oprindeligt specificeret.
Hvordan laver man en projektplan?
I dette afsnit vil jeg starte med at vise, hvor nemt det er at oprette en projektplan. I de øvrige afsnit nedenfor vil jeg så på et mere konceptuelt niveau snakke lidt om, hvad jeg vil råde dig til at inkludere i din projektplan, og hvad du bør tænke over, når du laver en projektplan.
Nedenfor kan du se en video lavet af Office Timeline, som gennemgår, hvordan du laver en projektplan fra bunden. Så tag eventuelt et kig på den, har du ikke mulighed for dette, så kan du sagtens bare følge min guide nedenfor.
Dette afsnit bliver med andre ord en trin-for-trin guide til, hvordan du opretter en projektplan, og vi starter helt fra begyndelsen og tager alle skridt, det kræver for at lave en fyldestgørende projektplan.
Til denne guide bruger jeg Office Timeline som eksempel, Office Timeline kan du teste helt gratis i 14 dage. Så start med at hente Office Timeline ned, så kan du nemmere følge guiden.
Opret projektets opgaver
Det første vi skal gøre er at oprette opgaver I vores projektplan. Dette kan vi gøre manuelt, eller vi kan lave det i Excel om du ser ovenfor på billedet. Det er klart nemmest lige at bruge Excel til at liste projektet op, på den måde får du hurtigere op rettet projektet.
Så snart alle opgaverne er oprettet, som du ser ovenfor skal du bare markere alle opgaver og kolonner, og kopiere indholde.
Husk at du skal taste både opgavens navn, start og slut dato. De andre data er valgfrie.
Lav projektplan i PowerPoint
Det næste du gør er at åbne PowerPoint og sætte din data ind, derefter til Office Timeline automatisk lave en projektplan for dig. Denne plan kan du meget nemt ændre både designet på, men også den data du har sat ind.
Du behøver med andre ord ikke gå tilbage til Excel for at lave ændringer til opgaverne, det kan du nu nemt lave i Office Timeline.
Hvis du går over i Timeline view, så vil du meget hurtigt kunne ændre på designet af din projektplan, det kan du med en enkelt drag-n-drop editor hvor du kan skifte position på elementerne eller skifte farve på dem.
Det er utrolig nemt at ændre farver og meget mere. Du kan lave dine helt unikke projektplaner der passer lige til din organisation eller dine projekter.
Det var det! Så let er det altså at lave en projektplan med Office Timeline. Jeg håber, at du kan se hvorfor det er at jeg altid bruger Office Timeline til mine projekter. Der findes ikke et projektstyringsværktøj på markedet som er mere simpelt at bruge end dette.
Nedenfor kan du ellers læse mine gode råd, når du skal lave en projektplan. Her kommer jeg ind på, hvad du skal tænke over, når du laver den, samt hvad de gerne skal indeholde.
Hvad er der i en god projektplan?
Hvad indeholder en projektplan?
En projektplan indeholder typisk følgende: De forskellige faser i projektet, opgaverne og milepælene i projektet, start- og slutdatoerne for alle opgaver og projektet som helhed, afhængigheder mellem opgaver og milepæle i projektet og hvilke ressourcer eller personer som er en del af projektet.
Hvad skal man ikke have i en projektplan?
Jeg har set mange dårlige projektplaner tidligere og har også selv lavet nogle, som var dårlige. En projektplan mister nemlig hurtigt sin værdi, hvis den indeholder alle små opgaver, og hvor opgavernes længde måske kun er 1-2 dage, og hvor listen af opgaver bliver næsten uendeligt lang i større projekter.
Samtidig kan en projektplan også hurtigt miste sin værdi ved kun at have de overordnet faser i projektet, hvor der eksempelvis kun er Opstart, Udvikling og Lancering som punkter, og hvor den måles i antal uger eller måneder i stedet for dage. Sådan planer er enten for specifikke eller for overfladiske til at give nogen noget værdi.
Hvilke fordele er der ved at have en projektplan?
En projektplan hjælpe dig som projektleder med at kommunikere omkring projektet. Den er med til at visualisere hele projektet, samt vise hvilke opgaver, som er forbundet. Den sikre derfor, at alle har samme opfattelse af projektet, men det kan også være med til at identificere flaskehalse ude i horisonten.
Projektplanlægningen siger meget om dig som projektleder, uanset industri, type af projekt eller mængden af erfaring. En projektplan fortæller nemlig folk, hvordan du forstår og takler et givet problem. Samtidig med, at det fortæller folk, hvor godt du sætter dig ind i problemstillingen, og hvad de valgte løsninger er.
Alle projekter skal have en projektplan, da det er den primære måde at kommunikere projektets fremdrift, samt at det holder alle projektets interessenter informeret omkring projektet. En projektplan er nemlig meget mere end bare opgaver og deadlines. En projektplan skal gerne kunne kommunikere det følgende:
Hvad er de største leverancer i projektet?
En projektplan skal ved blot et glans kunne kommunikere de største leverancer i projektet. Man skal gerne kunne se fordelen i projektet alene ved at bruge 10 sekunder på at skimte ned over projektplanen. Du skal derfor i projektplanen bruge sprog, som interessenterne ville kunne forstå.
Er du eksempelvis i gang med at lave en ny app til din virksomhed, så hold projektplanen mindre nørdet. Skal appen integreres med jeres hjemmeside, så kald den opgave “Integrer appen med hjemmesiden” i stedet for “Outbound REST API”. Folk i styregruppen ved måske ikke, hvad en REST API er. Men de kan derimod hurtigt se, at en leverance bliver, at appen er integreret med hjemmesiden.
Dette er et ret vigtigt punkt, for hvis interessenterne ikke kan se værdien af projektet, og det bare er en lang række meningsløse opgaver som “Outbound REST API”, så kan det være svært at komme til dem i nødsituationer og bede om flere ressourcer eller højere budget, da de ikke kan se værdien i projektet.
Hvordan og hvornår vil du levere disse leverancer?
Opret under de største leverancer nu de opgaver, som det vil kræve at komme i mål med dette. I eksemplet ovenfor kunne det eksempelvis være:
- Map datafelter mellem systemerne
- Tjek datakvaliteten på hjemmesiden
- Undersøg integrationsformer
- Udvikle integrationen
- Test integrationen
- Lancer integrationen
- Opfølgning på integrationen
Hver af disse opgaver skal så have en start- og slut‐dato. Det er disse start- og slut-datoer, som definerer den overordnede leverances start og slut‐dato, og derfor definere deadlinen for hvornår “Integrer appen med hjemmesiden” kan være klar.
Jeg vil råde dig til at finde et projektplanlægningsværktøj, som gør dette automatisk. Det er desværre ikke alle, som kan gruppere underopgaver, og automatisk rette datoer til som beskrevet her. Jeg bruger selv Office Timeline til at lave projektplaner, fordi den gør det helt automatisk.
Hvem er med i projektet, og hvad er deres rolle i leverancerne?
En anden ting som en projektplan hurtigt viser, er hvem er med i projektet, og hvad er deres rolle i leverancerne. Ud for hver af de ovenstående opgaver skal du sætte en person på opgaven, nogle gange er personen den samme på alle opgaver under en leverance, men der er ofte flere forskellige personer på en given leverance.
Det er vigtigt, at der er sat en person på alle opgaverne, da det kan hjælpe dig med at kommunikere flaskehalse til interessenterne. Jeg har eksempelvis, tit skulle forsvare det, at jeg brugte en kollega meget til et af mine projekter.
Med min projektplan kunne jeg hurtigt forklare hans/hendes leder, hvad det var han/hun sad med, og hvilke konsekvenser det ville have, at han/hun blev trukket ud af projektet. Det alene har mange gange sikret mig, at projekterne har kørt som planlagt, da det er svært for en leder at sige “Jeg kan godt se, projektet bliver forsinket, men jeg vil ikke have, at han/hun er med i projektet mere”. Og selv hvis de udmelder det, så har du en valid grund til at ændre projektplanen for at reflektere det, hvor du skubber deadlinen.
Havde du ikke en projektplan at tale ud fra, kunne du ikke kommunikere denne risiko og konsekvens effektivt til folk uden for projektet.
Du kan også bruge denne information til at hente flere ressourcer ind i projektet. Du kan let vise, at en given person har for meget at skulle klare i projektet, og kan derfor hurtigt rationalisere det, at projektet kræver endnu en ressource for at kunne blive færdigt til den givne deadline.
Dette skal du gøre, inden du laver en projektplan
Hvis du har drevet projekter før, så har du nok oplevet det, at så snart at projektets omfang er blevet fastsat, forventer folk ret derefter at se en projektplan.
Men, der vil jeg råde dig til blot at sige “Der er vi ikke helt endnu, jeg skal lige have styr på nogle småting først.” Mens en projektplan er relativt let at lave, så er der bare et problem. Du er nemlig ikke den eneste som med i projektet, og du ved ikke, hvor længe det bør tage at lave arbejdet involveret i projektet.
Start med at lave en grundig estimering af projektet
Du kan først gå i gang med at lave projektplanen, efter du har estimeret projektet. I mit indlæg “Lær hvordan du estimerer projekter” skrev jeg omkring det, du bør undersøge, inden du kan komme med et retvisende estimat på projektet. Hvis du ikke allerede har estimeret projektet, så er det første skridt at tage, efter projektets omfang er vedtaget.
Tag en snak med projektgruppen
Efter at have estimeret opgaverne skal du sætte dig ned med projektgruppen for at oversætte disse estimater til en projektplan. Du er nødt til at inkludere dem i projektgruppen, da de igen gerne skulle verificere estimaterne samt give input til, hvornår det vil være muligt at lave de forskellige opgaver.
Ofte har folk mere at se til, end blot det projekt du sidde med, og ofte har folk nogen ferier eller fridage uden for industriferien. Det er derfor vigtigt at få styr på det fra starten og få det til at fremgå af projektplanen, hvornår folk er utilgængelige på grund af ferie eller lignende.
Jeg havde eksempelvis et projekt med en mand, som skulle på barsel 3 måneder senere, men projektet var over 10 måneder langt. Så havde jeg ikke haft denne snak med alle i projektgruppen, så havde jeg lavet en projektplan med store afvigelser fra virkeligheden.
På grund af denne viden kunne jeg sætte fokus på det, han skulle bidrage med i starten, selv om jeg normalt nok ville have klaret dette senere i projektet. Jeg kunne også fra starten sætte datoen lidt senere, da vi jo var en mand mindre i de sidste to-tredjedele af projektet.
Der er også et psykologisk aspekt bag det, at alle i projektgruppen har været med til at lave projektplanen. Det er nemlig sådan at så føler folk en form for ejerskab, og de sætter derfor mere fokus på at nå deadlines end hvis en projektplan bare bliver præsenteret for dem, hvor de uden at have kunnet kommentere på den skal tilpasse deres hverdag for at kunne nå deadlines.
Ved at gennemgå estimaterne og snakke omkring projektet med folk i projektgruppen kan du også udfordre dem på, om den proces i tidligere har brugt i virksomheden, om den stadig er korrekt, eller om vi kan effektivisere den en smule. Kan flere processer eksempelvis køre sideløbende? Og derved skære signifikant ned på tiden det tager at lave projektet.
Ting du skal huske, når du laver projektplanen
Nu har du alt, hvad du skal bruge for at kunne lave en projektplan. Du ved hvad den gerne skulle indeholde, og hvad den gerne skulle kommunikere til læseren. Du har en god ide om, hvad det vil tage at gennemføre projektet, og har vendt estimaterne med folk i projektgruppen. Så nu er det bare at få det konverteret om til en projektplan.
Der er ingen tvivl om, at en projektplan hurtigt kan gå hen at blive lidt langhåret og kedelig. Husk på, at man skal kunne forstå projektet og tolke, hvordan projektet går ved blot hurtigt at skimte ned over projektplanen.
Dette kan du eksempelvis gøre ved at opdele opgaver under sektioner for hver leverance, farvekode de forskellige folk i projektteamet en specifik farve, og ved at vise afhængigheder mellem opgaver. Alt dette er lige til at klare i Office Timeline, men kan være mere langhåret i andre projektledelsesværktøjer.
Det som en projektplan altid bør indeholde
Ingen projektplaner er ens, de varierer fra projekt til projekt og fra virksomhed til virksomhed. Men der er nogle helt grundlæggende ting, som alle projektplaner skal indeholde:
- Projektnavn
- Folk i projektgruppen
- Version af projektplanen (eksempelvis v1.2 efter projektets navn)
- Deadline for projektet
- En ansvarlig for hver del-opgave
- En start og slut‐dato for hver del-opgave
- En klar kommunikation af afhængigheder mellem opgaver
Få læst korrektur på din projektplan
Jeg vil råde dig til at få en til at læse korrektur på din projektplan, det kunne jo sagtens være, at du har fået tastet forkert, eller at der måske er sneget sig en misforståelse igennem hele processen, som først blev synlig nu, hvor du lavede den endelige projektplan. Tag derfor lige at send projektplanen ud til folk i projektgruppen, og bed dem kigge den igennem for dig og vende tilbage, hvis de spotter noget.
Man kan tit godt blive ivrig efter at få den kommunikeret til alle interessenter, så snart den er lavet, men det er nu bedst lige at sikre sig, at alt er, som det skal være, inden man begynder på det.
Send projektplanen til interessenterne uden for projektgruppen
Når først projektplanen er helt klar, og der er læst korrektur på den, så er det på tide at dele den med projektets interessenter. I større projekter kan det give mening at indkalde folk til et møde, hvor du præsenterer projektet for dem. Men ofte er det nok bare at sende en mail ud, hvor du vedhæfter en projektplan i mailen, og hvor du kortfattet i mailen beskriver de vigtigste dele af projektet.
Det ville eksempelvis være en kortfattet beskrivelse af metodikken, som I bruger for at komme i mål med projektet, hvilke folk som er med i projektet, hvilke antagelser, som I har lavet for at kunne holde den nuværende deadline, og en kort beskrivelse af hver leverance og værdien, at det vil have for virksomheden.Så snart denne mail er sendt, så er projektet officielt i gang.
Og har du fuldt mine råd i dette indlæg, samt mine råd omkring estimering af projekter, så kommer du allerede der bedre fra start end de fleste andre projekter.
