Lær hvordan du estimerer projekter

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. 

Hvorfor er det vigtigt at estimere et projekt?

En estimering af projektet hjælper dig med tre ting. Den hjælper dig til at estimere budgettet for projektet, hvor mange interne ressourcer der skal bruges, og hvor lang tid det vil tage at udvikle det endelige slutprodukt. Disse tre estimater er vigtige at have en idé om, inden du starter projektet, ellers vil det være svært at få en virksomhed til at acceptere projektet.

Hvordan estimerer man et projekt?

Der findes mange forskellige metoder, men de mest kendte er top-down eller bottom-up estimering, datadreven estimering eller trepunktsestimering. Der er fordele og ulemper til dem alle. Du kan læse mere om dem længere nede i dette indlæg.

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. 

Hvad er en Work Breakdown Structure?

En Work Breakdown Structure er en visuel repræsentation af projektet. Den hjælper dig til at bryde projektet ned i leverancer, opgaver og underopgaver. Det er en simpel metode, der hjælpe dig med at bryde større projekter ned i mindre og mere håndterbare delelementer.

Hvorfor skal jeg lave en Work Breakdown Structure?

Der er meget værdi at hente i at lave en Work Breakdown Structure. Den primære er selvfølgelig at visualisere projektet og kunne vise, hvilke dele af projektet der hænger sammen, samt hvilken rækkefølge som opgaverne i projektet skal løses. Men den giver dig samtidig en skabelon, som du kan bruge til estimering af projektet.

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.

Hvad skal et estimerings dokument indeholde

Det skal indeholde navnet på projektet, projektlederens navn, projektets leverancer, opgaver og underopgaver, en kolonner med, hvor mange interne ressourcer en given underopgave vil tage, og til sidst en kolonne med, hvilke omkostninger der vil være i forbindelse med denne underopgave.

Hvilke værktøjer kan man bruge til estimering af projekter?

Ofte bruger man bare Microsoft Excel eller Google Sheets. Der findes betalte værktøjer, der kan hjælpe dig med det, som BrainLeaf og Price&Cost, men synes ikke, de er pengene værd, når Excel og Google Sheets klarer opgaven fint nok.

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.

Hvad er et ballpark budget estimat?

Et ballpark estimat er en meget grov estimering, typisk med en afvigelse på -25% til +25% i budget og ressourceforbrug fra det faktiske forbrug. Disse bruges tit allerede før estimering processen går i gang, og det er typisk dette man vil give helt i starten af projektet. Så det er en meget overfladisk estimering, som med stor sandsynlighed ikke er korrekt.

Hvad er et budget estimat?

Dette er en mere præcis estimering, typisk med en afvigelse på -10% til +10% i budget og ressourceforbrug fra det faktiske forbrug. Denne estimering skal du bruge til at kunne søge om budget til projektet. Så en lidt mere specifik estimering, men der er stadig med lidt usikkerhed, så et godt råd er at skyde lidt for højt. Estimeringen kræver her lidt mere arbejde for at komme helt ned på det endelige estimat, som bruges i den endelige business case.

Hvor præcist skal det endelige estimat være?

Det endelige estimat er det, du bruger i din business case, dog skal du inkludere en buffer på typisk 20% til, hvis noget skulle gå galt undervejs i projektet. Så det ville eksempelvis være “En ny webshop vil koste 300.000 kr. + 60.000 kr. til uforudsete udgifter eller ændringer”

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.

Hvad er top-down estimering?

Top-down estimering er en god metode til at lave ballpark estimeringer. Her kigger du på leverancerne defineret i dit Work Breakdown Structure, og allokere både interne ressourcer og budget til hjælp fra en ekstern konsulent på hver af leverancerne. Fordelene ved denne metode er, at den er hurtigt overstået, især hvis projektet kun har 5-10 leverancer, så vil det ikke tage lang tid at komme med et gæt på, hvad det vil koste. Ulempen ved denne metode er, at den er meget upræcis, du kigger måske på opgaverne, men nok ikke helt ned på underopgaverne, og basere dit estimat på en arbitrære leverance som “Ny produktside” uden at vide, hvad dette betyder.

Hvad er datadreven estimering?

Datadreven estimering er også en god metode til at lave ballpark estimater. Her kigger du ikke på det nuværende projekt. Du kigger i stedet på andre projekter, som du har drevet, kørte du eksempelvis et lignende projekt sidste år? Var det lige så stort? Jamen, så er budget og ressourcer måske det samme? Er dette projekt dobbelt så stort? Så skal budget og ressourcer nok, også være dobbelt så stort. Eller du bryder projektet ned i små stykker og laver en test. Skal du oprette 4.000 varer på en webshop, så opretter du en vare og tager tid og tager det 30 minutter, så ganger du de 30 minutter med de 4.000 varer. Fordelen ved denne metode er ligesom med top-down metoden, at den er rigtig hurtig at lave. Ulempen er også den samme som ved top-down metoden, den er ikke særlig præcis. Selv om to projekter minder om hinanden, så kan der godt være stor forskel på dem.

Hvad er trepunktsestimering?

Trepunktsestimering er en god metode til at lave en budget estimering. Ved trepunktsestimering beregner du et forventet budget og tidsforbrug ved at sætte dit estimat for, hvad du mener, er Best case, Worst case og Most likely på en opgave i projektet. På den måde afdækker du dine bekymringer. Eksempelvis kunne “Lave wireframe for ny produktside” blive sat til 5 timer i base case, 10 timer i worst case og 7 timer i most likely. Derefter kan du beregne det forventede estimat ved at tage (Best + Worst + 4*Most likely)/6 = Forventede estimat, eller i dette eksempel (5 + 10 + 4*7)/6 = 7,16 timer. Nedenfor kan du se mit Excel ark til trepunktsestimering. Fordelene ved denne metode er, at det minimere risikoen for at estimere forkert. Ulempen ved denne metode er, at den tager lidt længere tid.

Hvad er bottom-up estimering?

Bottom-up estimering er en god metode til at estimere det endelige budget. I modsætning til de andre estimeringsmetoder fokusere bottom-up ikke på leverancerne eller opgaverne, den kigger udelukkende på underopgaver i projektet. Måden, hvorpå man estimere projektet på er så ved at summere alle dine underopgaver sammen. Denne metode virker rigtig godt sammen med metoden for trepunktsestimering, hvor du i stedet for projektets opgaver bare kigger på projektets underopgaver. Fordelen ved denne metode er, at den er den mest præcise metode. Ulempen er, at den tager meget mere tid. Der kan være rigtig mange underopgaver i større projekter, og det kan derfor være en ret langhåret. process finde realistiske estimater for dem alle.

Hvilken metode skal du vælge?

Der er ikke et entydigt svar på dette, og der findes mange flere metoder end dem, jeg har skrevet om her. Men jeg bruger top-down eller datadreven estimering til mine ballpark estimeringer. Og jeg bruger typisk bottom-up sammen med trepunktsestimering til at lave mine budget estimeringer og endelige budgetter for projektet.

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.

Hvor tit skal man opdatere sin estimering?

Du skal holde øje med din estimering af projektet løbende, og rette til, hvis det kræves. Mange vælger at gøre det på månedsbasis, eller hvis de driver agile projekter med definerede MVP‐leverancer, så gennemgår de estimeringen efter hvert leveret MVP. Frekvensen er ikke så vigtig, det er bare vigtigt, at du løbende holder øje med, om din estimering var korrekt, og griber ind tidligt, hvis du kan se, at du har underestimeret projektet.

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. De 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, Forbes’ Innovation sektion 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:

Mark Guldbrandsen
Mark Guldbrandsen
Erfaren projektleder med speciale i digitale projekter. Rig på erfaring med udvikling og udrulning af hjemmesider, webshops, CRM systemer og meget andet.

Indholdsfortegnelse

GUIDE TIL PROJEKTLEDELSE
EN TRIN-FOR-TRIN GUIDE TIL EFFEKTIV PROJEKTLEDELSE

Jeg har lavet denne guide til at hjælpe alle mine læsere med at drive deres projekter mere effektivt. Mange af mine læsere har ikke en formel projektlederuddannelse og har ikke tiden eller muligheden for at tage en. Derfor har jeg lavet denne trin-for-trin guide til effektiv projektledelse, som du kan følge undervejs i dit projekt. 

Måske du også er interesseret i disse indlæg:
gantt projektplan

Sådan laver du en god projektplan

Introduktion 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

Læs mere
Forstå det nye behov

Sådan laver du en god idébeskrivelse

Introduktion til Idébeskrivelsen En god idébeskrivelse vil gøre det muligt for dig at vurdere forskellige idéer op imod hinanden, så du nemmere kan træffe beslutning om, hvilke idéer du skal afsætte ressourcer og tid til

Læs mere
Disse værktøjer bruger jeg til mine projekter:

Projektledelse i sig selv er kompliceret nok. Så hvorfor døje med komplicerede værktøjer også? Nedenfor kan du se de værktøjer, som jeg bruger til dagligt, samt mit review af dem.

teamgantt logo
Review:
5/5

Det kan være en langhåret proces at holde Microsoft Projects opdateret. Men det er det ikke med TeamGantt, de har lagt al deres fokus på brugervenligheden.

Review: Læs her
Pris: Gratis

trello logo
Review:
4.5/5

Jeg bruger Trello til alt, hvad jeg kan slippe af sted med. Både på arbejde og i privaten. Det inkluderer såvel projekter, som generelle arbejdsopgaver.

Review: Læs her
Pris: Gratis

Lucidchart logo
Review:
4/5

Lucidchart er et visuelt arbejdsværktøj, som jeg bruger til at lave diagrammer, Work Breakdown Structures, Flowcharts og andre projekt visualiseringer.

Review: Læs her
Pris: Gratis