Succesfulde projekter har alle en ting til fælles. De havde en konkret projektplan fra starten. I nogen tilfælde ændres planen undervej 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 hvordan 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 mindre brugbare projektplaner tidligere, og har også selv lavet nogle som var mindre brugbare. 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. 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 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 de mulige løsninger er kunne være.
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. Men 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”. Direktøren i dit firma ved måske ikke hvad en REST API er. Men han 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 definere den overordnet 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ægnings væ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 projekter, netop fordi at 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, nogen 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 vigtig 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 estimere 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 sidde dig ned med projektgruppen for at oversætte disse estimater til en projektplan. Du er nød til at 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 nogle ferie eller fridage uden for industriferien. Det er derfor vigtig 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, 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 hun 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 kunne kommenteret 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 process 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 og 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 projekteteamet 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 projektledelses værktøjer.
Det en projektplan altid bør indeholde
Ingen projektplaner er ens, de variere 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æsentere 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 have 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.
