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. Så et succesfuldt projekt behøver ikke nødvendigvis ende præcist sådan, det startede med at blive solgt ind som, så længe at det følger projektplanen, uanset hvad den er, eller ændre sig til undervejs i projektet.
En projektplan skal ses som en simpel løsning til et kompleks problem. Med det skal det forstås, at en god projektplan kan hjælpe interesseret i 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.
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.
I dette indlæg vil jeg derfor give et eksempel på, hvordan du kan lave en optimal projektplan. Men kort fortalt, så er målet med en projektplan at vise din fremgangsmåde for at løse et givet problem.
Hvad er der i en god projektplan?
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 interessenter 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 del-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 TeamGantt 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 del-opgaver skal du sætte en person på opgaven, nogle gange er personen den samme på alle del-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 del-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 opfang 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 del-opgaver under sektioner for hver leverance, farvekode de forskellige folk i projektteamet en specifik farve, og ved at vise afhængigheder mellem del-opgaver. Alt dette er lige til at klare i TeamGantt, 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 del-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.
