Lær hvordan du estimerer dine projekter

Introduktion

Det at skulle estimere et projekt kan uanset størrelse være en langhåret proces, derfor har jeg skrevet dette indlæg for at hjælpe dig med denne proces. 

Men inden du begynder at estimere projektet, så er det vigtigt, at du allerede har styr på projektets målsætninger og fået lavet en udførlig kravspecifikation. 

Disse to dokumenter er vigtige for estimeringen af projektet, og uden disse kan det være svært at gå i gang med at estimere projektet. 

Alle projekter kommer med hver deres nuancer, og alle projekter har gråzoner, der kan være svære at estimere i forhold til budget, tidsplaner, og de ressourcer, som skal allokeres til den opgave.

Du skal derfor vide på forhånd, at din estimering netop kun er det, nemlig en estimering. Det er ikke muligt at komme med et 100% sikkert tal for, hvad det vil kræve at lancere et projekt. 

Men gør du et godt stykke forarbejde, så kan du komme tættere på sandheden. Så du vil i dette indlæg få flere estimeringsmetoder, som du kan bruge alt efter, hvor præcist dit estimat skal være.

Men prøv til at starte med at se denne video fra TeamGantt, den guider dig igennem det at estimere projekter, og kommer med en masse gode råd.

Jeg har også nedenfor skrevet lidt om, hvordan jeg personligt estimerer mine projekter. Den metode, jeg bruger, kræver en smule mere arbejde, men det er nok en af de mest præcise metoder at bruge til estimering af projekter.

Skab et visuelt overblik over projektet

Det er en rigtig god ide at starte estimeringen af projektet ved at visualisere det ud fra den viden, du har fra idébeskrivelsen og kravspecifikationen.

Grunden til, at du vil gøre dette, er at det bliver meget nemmere at få folk til at nikke godkendende til projektets omfang, så snart at det er visualiseret. 

En anden grund er, at der ofte er mindre chance for misforståelser, når det er visualiseret korrekt. 

Jeg har nogle gange oplevet, at folk sagde “Ah, det fik jeg nok ikke sagt klart nok, det jeg mente, var at…” efter jeg havde tegnet tingene op og vist dem, hvordan jeg havde forstået det.

Der er mange måder at gøre det på, det kunne eksempelvis være ved hjælp af wireframes, selvom dette ikke altid er lige nemt at lave. 

Men den mest enkle ville klart være at visualisere det ved hjælp af et Work Breakdown Structure. 

At lave en Work Breakdown Structure for projektet er noget, som jeg ser mange projektledere spring let og elegant henover. 

Det er ikke så tit, at man får taget sig tiden til det længere. Men jeg har en generel regel, som hedder: En times ekstra forberedelse sparer typisk 10 timers eksekvering. 

Men en anden fordel er også, at den tvinger dig til at tænke lidt mere over opgaverne, og får dig til at udpensle dele af projektet. 

Så det er altså med til at give dig et bedre billede af projektet og gør dig derfor også bedre i stand til at kunne estimere projektet.

Et større projekt kan hurtigt give en stor Work Breakdown Structure, men så snart, at du har fået lavet det fulde overblik, så kan du gå i gang med at estimere opgaverne.

Sådan laver du en Work Breakdown Structure

Trin 1: Opret projektets leverancer

En Work Breakdown Structure starter altid med at dele projektet op i de overordnet leverancer, som projektet skal udvikle. Hvis du har fulgt min guide til, hvordan du laver en kravspecifikation, så vil dette være en samling af de funktionelle krav til projektet. Alle kravene til produktoversigten kunne eventuelt samles under “Produktoversigt & Sortiment” 

Dette kunne eksempelvis for et webshop projekt være:

• Wireframes & Design
• Opsætning af systemer & integrationer 
• Produktoversigt & Sortiment
• Produktside og produktinformationer
• Kurv & Betaling
• Blog & Marketing

Trin 2: Samle projektets opgaver under en leverance

Når du har lavet oversigten over de forskellige leverancer, der er i projektet, så skal du under disse samlinger opremse alle funktionelle krav fra kravspecifikationen. 

Det kunne eksempelvis være “Avanceret filtrering af produkter” under “Produktoversigt & Sortiment”. 

Disse er opgaverne, som skal løses i projektet, men det er ikke dette niveau, som skal estimeres på, det er typiske på underopgaven, at du vil lave de endelige estimater. 

Du vil tit finde nogle nye krav til løsningen, når du er i gang med at lave en Work Breakdown Structure, så det er ikke ualmindeligt, at du kommer til at gå tilbage og opdatere kravspecifikationen efter at have lavet denne øvelse. 

Huske på kravspecifikationen er ikke et statisk dokument, det kan sagtens ændre sig undervejs i projektet især her i starten af projektet. 

Trin 3: Del opgaverne op i underopgaver

Til sidst skal du granulere opgaven helt ned til separate underopgaver. 

Disse underopgaver skal være meget specifikke, og de skal være meget uddybende for, præcis hvad den overordnet opgave skal kunne løse. 

Så under “Avanceret filtrering af produkter” tilføjer du så derefter “Filtrering på pris”, “Filtrering på tilbudsvarer” og “Filtrering på størrelse” som underopgaver. Disse er opgaverne, som du vil estimere i projektet.

Du skal gerne helt ned på dette niveau for at sikre dig, at du får gjort det klart, hvad den overordnede opgave består af.

Trin 4: Skab dig et overblik – Får det visualiseret

Der er mange måder at gøre dette på, og det er lidt forskelligt, hvordan jeg gør det fra projekt til projekt. 

Enten smider jeg det ind i et flowchart ligesom mit eksempel nedenfor, der bruger jeg typiske Lucidchart til at lave det. Dette tager en smule tid at lave, men det er helt sikkert den tid værd i større projekter, som har mange interessenter.

Ellers laver jeg oversigten direkte i mit Excel estimerings ark. Denne mulighed er lidt mindre visuel, men er hurtigere at lave. Det sparer mig også lidt tid, da jeg alligevel skal lave den når jeg skal lave den endelige estimering. Nedenfor kan du se et eksempel nedenfor her.

Du kan også oprette din Work Breakdown Structure direkte i TeamGantt. Se eventuelt et eksempel nedenfor. Det gør jeg typisk på mindre projekter, hvor jeg kun vil lave et ballpark estimat for projektet. For jeg laver alligevel altid mine Gantt diagrammer ud fra min Work Breakdown Structure.

Men jeg vil generelt råde dig til at tage tiden til at lave et flowchart på de større projekter, da det kan være med til at du spotter noget I har glemt, så snart at det bliver visualiseret. Men for mindre projekter kan du sagtens nøjes med at oprette det direkte i Excel eller TeamGantt.

Trin 5: Gennemgå din Work Breakdown Structure

Når du er færdig med at oprette alle leverancer, opgaver og underopgaver, og har fået skabt et komplet overblik over det, jamen så er det på tide at gå dem igennem en sidste gang. 

Så sæt dig ned med dine kollegaer, og kig på hver underopgave sammen. Her skal I særligt kigge på, hvor besværlig en opgave vil være at lave. 

I skal både kigge på, hvor lang tid det vil tage at lave denne opgave selv eller estimere, hvor meget det vil koste at få en ekstern konsulent til at hjælpe med dette. 

I næste afsnit vil jeg gå forskellige metoder igennem, så du får et værktøj at bruge. Du vil også i næste afsnit kunne download det estimerings Excel-ark, som jeg bruger, når jeg skal estimere projekter. 

Gå i gang med at estimere projektet

Nu skal du til rent faktisk at lave estimeringen. Ovenfor fik du styr på projektets opgaver og underopgaver, og nu er det på tide, at vi får dem estimeret. 

Jeg kommer i dette afsnit til at skrive lidt om de forskellige metoder, du kan bruge, og hvornår de hver især er brugbare.

En estimering af projektet kan ske på forskellige tidspunkter, det kan ske under idébeskrivelsen, mens man sætter projektets målsætninger, mens man laver kravspecifikationen, og når man skal til at lave en business case for projektet og søge om budget. 

Det er klart, du kan ikke komme med noget præcist estimat på projektet under udarbejdelsen af idébeskrivelsen eller fastsættelsen af projektets målsætninger, der skal du bare lave et ballpark estimat. 

Men når du skal til at lave en business case, så skal du kunne være ret specifik og kunne lave, det der hedder et budget estimat, som efter en endelig raffinering bliver til det endelige estimat.

Du undre dig måske over, hvorfor jeg tilføjer 20% til mit endelige budget. Men det gør jeg ikke så meget på grund af fejl estimeringer, men mere fordi jeg ved, at projekter ændre sig tit undervejs, så det er rart at have en buffer at kunne arbejde med, hvis det er. 

Nu ved du lidt om de forskellige estimater, du kan blive bedt om at lave, nu skal vi kigge på, hvordan du kan lave dem. 

Her skal vi kigge på nogle af de mest populære estimeringsmetoder, og dem som jeg bruger. Dette er for eksempel top-down metoden, datadrevet estimering, trepunktsestimering og bottom-up estimering.

En anden stor grund til, at du helst skal bruge bottom-up metoden til dit endelige estimat er, at fordi du ved at have lavet estimaterne på underopgaverne i stedet for leverancerne, så kan du meget hurtigere se, om estimeringen er korrekt eller ej. 

Du kan derfor rette estimeringen til meget hurtigere i projektet, og allerede tidligt i projektet opdage, om der skal tages hensyn til noget i forhold til budget og tidsplan. 

En anden stor fordel ved bottom-up estimering er også, at den tvinger dig til at have styr på projektets målsætninger, kravspecifikation og den tvinger dig til at lave en Work Breakdown Structure. 

Hvilket i sidste ende, bare det i sig selv vil sikre dig, at projektet kører meget mere gnidningsfrit. 

Ved øvrige metoder, som starter med at estimere leverancerne, og ud fra det allokerer budget til opgaverne og underopgaverne, der er det tit alt for sent, at man opdager, at budgettet for leverancen var alt for lavt.

Download mit projekt estimerings Excel-ark

Nedenfor kan du downloade mit Excel-ark, som jeg bruger til estimering af projekter. 

Alt, hvad du skal udfylde er, hvor mange timer, som du mener, en given underopgave bør tage (Most likely), kunne tage hvis I var hurtige (Best case), og kunne tage hvis alt gik galt (Worst case). Så regner arket automatisk ud, hvor mange timer du bør forvente, at underopgaven vil tage. 

Du kan også skrive ind, omkostninger der vil være forbundet med at lave denne underopgave. Det kunne eksempelvis være hvis der var en licens, eller en ekstern konsulent skal hjælpe med opgaven.

Du kan nok ikke forvente at få skrevet alle dine omkostninger i estimerings-arket, der er tit nogle uforudsete omkostninger forbundet med et projekt.

De uforudsete omkostninger er selvfølgelig noget svære at håndtere, og de kan variere meget fra virksomhed til virksomhed og fra projekt til projekt. Men du kan spotte mange af dem ved grundigt at gennemgå projektets kravspecifikation og omfang/afgrænsning.

Kig på det, og tjek om alt er en del af din estimering. Det kan godt tage en del tid at gennemgå alle delelementerne i projektets kravspecifikation, men brug gerne den tid nu.

Det, du skal kigge efter, er selvfølgelig at estimere, hvor mange timer det vil tage at lave en given opgave. Men der hvor “uforudsete” udgifter ofte gemmer sig, er ikke i timerne, men eksempelvis i licens og abonnementer til softwares som skal bruges til projektet.

Kig derfor på, hvad der skal bruges til at løse projektet, og hvad de koster. Det er disse indirekte udgifter, som kommer bag på mange projektledere under projektet, da de ikke direkte fremgik i projektets specifikation. 

Andre gode råd omkring estimering af projekter

Herunder vil jeg komme med lidt generelle råd til, når du skal estimere projekter. 

Disse har ikke så meget med estimeringen at gøre i sig selv, men handler lidt mere om, hvad du som projektleder skal have i tankerne under estimeringsprocessen. 

Hvad går det typisk galt?

Først og fremmest skal det lige siges igen, at det kun er en estimering, du laver. Det er ikke en eksakt videnskab at estimere projekter. Men, herunder er der nogle af de typisk fejl, en projektleder laver, når de estimerer projektet.

Mangel på erfaring med lignende projekter

Nøjagtigheden af din estimering stiger, i takt med at du får mere erfaring med en specifik type projekter. Jeg har personligt drevet en del hjemmeside og webshop‐projekter, så bare alene mine Ballpark estimater er ved at være rimelig nøjagtige.

Men hvis jeg derimod skulle til at lave et større machine learning eller AI projekt, så ville mine ballpark estimater igen være lidt af et gætteværk, da jeg ikke har drevet så mange projekter med dette. 

Derfor kender jeg ikke de typiske fejl i sådan projekter, og jeg kender ikke eventuelle organisatoriske begrænsninger i virksomheden, som jeg arbejder for. Mere om det længere nede. 

Mine endelige projekter ville også være mere unøjagtige, da det er svært for mig at få listet alle underopgaverne i projektet, og det er også svært for mig at estimere de underopgaver, som jeg får listet. 

Projektet har en alt for lang tidshorisont

Jo længere ud i fremtiden du estimerer, jo mere usikker bliver din estimering. Jeg ser tit projekt‐estimeringer på projekter, der løber over 2 år eller mere. Og det er som sådan også helt okay. Man skal bare vide, at de første tre måneder og de sidste tre måneders estimering ikke er lige sikre. 

En medarbejder kan eksempelvis pludselig stoppe, og I er nødt til at hente en ekstern konsulent ind til at hjælpe. Eller en beslutning tidligere i projektet ændrede omfanget af en opgave senere i projektet, så en opgave nu er langt mere omfattende og så videre. 

Der er intet galt i dette, og det er helt naturligt, men du skal bare være sikker på, du kommunikerer dette, når du laver lange estimeringer, og at du løbende overvåger og opdaterer dine estimeringer. 

Projektlederen forstår ikke projektet

Dette taler jeg mere om længere nede i dette indlæg. Men en typisk fejl er også, at projektlederen ikke forstår projektet, og derfor ikke kan estimere opgaver, eller stille de kritiske spørgsmål til sine kollegaer, der skal til for at estimere en opgave. 

Projektlederen estimerer med, at projektgruppen vil arbejde fuldtid på projektet

Du skal passe på med at estimere, at folk arbejder fuldtid på et projekt. Selv hvis en person skal dedikeres 100% til et projekt så kan det stadig være farligt at gå ud fra, at personen arbejder 37 timer på et projekt om ugen. 

Selv når jeg har en person dedikeret til et projekt, og han/hun intet andet skal lave, så regner jeg typisk med 5 timer om dagen, det vil sige 25 timer om ugen. 

Dette gør jeg, fordi personen også kommer til at sidde i møder, snakke med kollegaer ved kaffemaskinen, og tit også får nogle små ad-hoc opgaver her og der.

Så pas på med at regne med 37 timer, jeg har fundet 25 timer om ugen for dedikerede personer som værende rimelig præcist.

Projektlederen opdaterer ikke estimering, efter projektets omfang er ændret

Jeg har også set eksempler, hvor omfanget af projektet har ændret sig, men projektlederen ikke har været inde at estimere projektet med det nye omfang. 

Det vil i sidste ende gøre, at estimeringen ikke længere er valid. 

Dette kan jo selvfølgelig både være en god og en dårlig overraskelse. Nogle gange bliver projektets omfang større, andre gange bliver det mindre. Men uanset hvad bør du estimere projektet igen med det nye omfang. 

Projektlederne laver en ballpark estimering og bruger det som endeligt budget

Det er helt okay at lave et ballpark estimat, men det må ikke blive dit endelige estimat. 

Jeg har selv været i en situation, hvor jeg blev holdt oppe på mit ballpark estimat, som viste sig at være for usikkert, og projektet viste sig at være en smule større, end jeg havde estimeret. 

Og det er jo også okay, da det kun var et ballpark estimat. Men det er vigtigt, at du gør det meget klart for folk, at dette estimat er meget usikkert, og at der kræves en del mere arbejde, inden at det endelige budget kan lægges.

Der bliver ikke sikret en buffer til det endelige budget

Mit råd er altid at tillægge 20% til det endelige estimat. Denne buffer skal ikke være en del af udbudsprisen, og må ikke bruges inden projektstart. 

Den skal bare være der til, hvis projektets omfang skulle ændre sig, eller uforudsete udgifter skulle komme undervejs i projektet. Såsom hvis en medarbejder stopper midt i et projekt, og i skal ud at hyre en ekstern konsulent til at komme ind for at overtage hans rolle. 

Det er ikke altid, jeg får brug for den buffer, men den er rar at have ved hånden, når man har brug for den, så man ikke skal igennem den helt store budget‐ansøgning midt i et projekt, det kan tit godt være stressende. 

Start med at forstå projektet

En af dine største udfordringer som projektleder vil være at forstå projektet og folk, som er med i projektgruppen. Det er derfor vigtigt, at du dykker ned i projektet og studerer de folk, som du skal arbejde sammen med under projektet. Du har allerede gjort meget af dette arbejde, hvis du har lavet en idébeskrivelse. 

En projektleder forstår sin egen rolle og kan let opbygge en projektplan lave en kommunikationsplan, lavet en proces for arbejdsopgaverne, og klargøre en statusrapport.

Men en dygtig projektleder kan alt det, og mere til. For at du kan nå dette niveau, skal du nemlig ud at have noget skidt under neglene. 

Du må som projektleder ikke falde i “det er ikke mig der skal det, jeg er jo projektleder”-fælden. Alt for ofte ser jeg projektledere drive projekter, som de absolut intet ved om. Det er eksempelvis ved at lancere et system, som de aldrig selv har brugt, og de måske endda aldrig selv har prøvet at logge ind i. Det er jo et problem af flere grunde.

Hvordan vil du eksempelvis kunne estimere opgaver, hvis du ikke ved noget om systemet? Så det er vigtigt, at du involverer dig i problemstillingerne, der skal løses. Det er klart, at du ikke skal tage for meget på dine skuldre, dit primære ansvar er jo stadig ressourceallokering, budget og så videre. Men det er vigtigt, at du forstår projektet og ved, hvad det er, I ønsker at opnå med projektet, hvorfor projektets målsætninger er så vigtige.

Lær alt, hvad du kan inden for det, du arbejder med

Jeg arbejder selv primært med digitale projekter som nye hjemmesider, webshops eller mobile apps. 

Jeg har aldrig set mig selv som hverken webdesigner eller programmør, men jeg bruger stadig en del tid på at læse op på begge ting. For jeg mener, det er vigtigt, at projektlederen kan tale med, når grafikeren eller programmøren “nørder” og kan snakke deres fagsprog. Alt for få tager sig tid til at lære noget nyt og holde deres viden up-to-date.

Det er vigtigt, fordi hvis du har denne grundviden om de opgaver, som projektgruppen sidder med, så kan du nemlig begynde at stille de kritiske spørgsmål, som hjælper dig med at afværge mange risici, og som hjælper dig med at estimere opgaverne korrekt.

Som projektleder skal du også sikre dig, at du kender de seneste trends i markedet, så arbejder du med digitale projekter skal du eksempelvis sikre dig, at du kender de nye programmeringssprog, som kommer hele tiden, eller du skal kende de mange software‐virksomheder som popper op hist og her med nye lovende redskaber, der kan gøre projektet endnu bedre. 

Arbejder du med IT-projekter, som jeg primært gør, så vil jeg derfor anbefale dig at begynde at følge forskellige nyhedskanaler som Kommunikationsforum eller TheNextWeb’s Design and Development sektion er gode steder at starte. 

Med disse kanaler kan du få et indblik i, hvad der lige er kommet i markedet, hvad der kommer inden for det næste års tid, og hvad der kommer inden for det næste årti. 

Det tager selvfølgelig noget tid at skulle holde sig up-to-date på de seneste nyheder, men det er en vigtig del af at kunne estimere projekter, og så vidt også at kunne drive projekter. 

Så jeg vil altså råde dig til at bruge minimum 30 min hver uge, på at du læser de udvalgte nyhedskanaler igennem for at se, hvad der er kommet af spændende nyheder siden sidst.

Pengene er også rigtig godt givet ud for at tage på forskellige konferencer inden for dit felt. 

Så sidder du tit med opgaver inden for website, e-shops og så videre, så find nogle konferencer/events omkring dette at tage til. Konferencer giver dig ikke bare en masse spændende information, men det giver dig også mulighed for at møde folk i samme position som du kan dele erfaringer med. 

Det at have et netværk, som man kan trække på, er mange gange bedre end blot at have en masse viden selv, og jeg bruger tit mit netværk til at hjælpe mig med rådgivning omkring mine projekter.

Kig tilbage på, hvad der gik galt sidst

Det er vigtigt, at du studerer tidligere projekter, uanset om du, eller andre i virksomheden var projektleder på dem. 

Der er uden tvivl noget historisk data, der kan hjælpe dig med dit kommende projekt.

Det, som du skal kigge efter, kunne være processer i virksomheden, som kom på tværs af projektet, tit er det afdelinger som IT-afdelingen, som har nogle faste principper, som kan være begrænsende for det, marketingafdelingen gerne ville lave på hjemmesiden. 

Så hvis du ikke kigger tilbage og ser, at tidligere projekter blev forsinket på grund af disse principper, så vil du igen i dette projekt fejlestimere.

Tjek op på dine estimater undervejs i projektet

En anden god ide er løbende at bede folk om at tage tid på, hvor lang tid de forskellige opgaver tog dem. På den måde kan du nemt se, hvilken type opgave som tager kortere eller længere tid end forventet. 

Du kan så løbende rette projektplanen ind efter det, som du lærer undervejs, og du kan tidligt i projektet se, om det er ved at gå galt, når 3 ud af 100 lignende opgaver er gået over tid. Så kan du allerede efter nr. 3 stoppe op at se på, hvordan kan vi gøre dette smartere ved de næste 97. 

Det samme kan du gøre, når der er 90 tilbage, det kan godt være teamet nu, er blevet hurtigere end ved de tre første, men kunne I gøre det bare 10% hurtigere endnu, så er der hurtigt meget tid at spare igennem hele projektet. 

Dette hedder inden for SCRUM et retrospektivt feedback‐loop, og det er en vigtig del af det at køre agile projekter.

Opsummering

Det blev et lidt længere indlæg end forventet, men estimeringer er også en langhåret proces, som man ikke bare kan hoppe let over. 

Men nu har du fået styr på, hvordan du estimere projektet på baggrund af projektets kravspecifikation. Det er vigtigt, at netop kravspecifikationen og projektets målsætninger er lavet, inden du begynder at estimere for uden dem er I endnu ikke klar til at gå videre med projektet. 

Jeg vil også råde dig til at bruge bottom-up og trepunktsestimeringen til at estimere dine projekter. Det er den metode, jeg har brugt til at lave mit estimerings Excel-ark. Så bare download skabelonen nedenfor, og følg mine råd ovenfor.

Mangler du mere inspiration, så tag eventuelt et kig på disse sider:

• Three-point estimation – Wikipedia
• What Is a Work Breakdown Structure? – TeamGantt