Lær hvordan du estimerer projekter

Lær hvordan du estimerer projekter

Indholdsfortegnelse

Det at skulle estimere projektet kan uanset størrelsen være en langhåret proces. 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 ressourcer, som skal allokeres til den opgave. Men fordi disse gråzoner skifter fra projekt til projekt, så kan det ofte være svært at få bygget et fast estimat for projekter.

Før du kan lave et brugbart estimat, skal du først kende projektgruppen, både deres styrker og svagheder. Du skal også gerne kende ønsket med projektet (Vision‐statement), og du skal have et godt overblik over projektet. Det er alt sammen det, som jeg vil fortælle lidt om i dette indlæg.

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.

En projektleder forstår sin egen rolle og kan let opbygge en projektplan lave en kommunikationsplan, lavet en proces for arbejdsopgaverne, og klargør 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 været logget ind i. Det er jo et problem af flere grunde.

Hvordan vil du eksempelvis kunne estimere opgaver, hvis du ikke ved noget om opgaven? Så det er vigtigt, at du involverer dig i opgaverne. Det er klart, at du ikke skal tage for meget på dine skuldre, dit primære ansvar er jo stadig ressourceallokering og budget osv. Men det er vigtigt, at du er med ind over nogen af opgaverne, så du ved bare en smule om det.

Det vil samtidig også stille dig bedre til statusmøder, hvor projektgruppen ikke er til stede, hvis du selv kan svare på praktiske spørgsmål som: “Hvordan gør vi det, når vi får det nye system?” Og du der kan forklare den nye arbejdsgang eller proces, som er ved at blive bygget.

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 apps. Jeg har aldrig set mig selv som hverken designer 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.

For 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 alle nye programmeringssprog, som kommer hele tiden, eller skal kende de mange software‐virksomheder som popper op hist og her med nye lovende redskaber, der kan gøre projektet endnu bedre. Jeg vil 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. På den måde kan du holde dine programmører oppe på tæerne ved eksempelvis at sige, hjemmesiden skal være en PWA (Progressive Web App) eller en anden nyere teknologi, der forbedrer brugeroplevelsen.

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 opgaver, og så vidt også at kunne drive projekter. Så jeg vil altså råde dig til at bruge de første 30 min hver dag på, at du læser de udvalgte nyhedskanaler igennem for at se, hvad der er kommet af spændende nyheder siden dagen før.

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.

Lær alt hvad du kan om dem, du arbejder sammen med

Hvem arbejder du egentlig sammen med på dine projekter? Kender du dem virkelig? Hvad er deres styrker og svagheder? Hvordan arbejder de bedst sammen med andre? Hvilke opgaver elsker de at lave, og hvilke opgaver vil de helst være fri for?

Det er vigtigt, at du kender dem, du arbejder sammen med, for det er ultimativt, sådan at du sikrer dig, at opgaverne bliver løst korrekt og til tiden. Mange er under den overbevisning, at alle kan gøre alt lige godt, og at folk der “sjusker” med nogle opgaver, bare er dovne. Men realiteten er, at vi er alle forskellige og har hver vores specialitet. Jeg er eksempelvis rigtig dygtig til at lave meget teknisk komplekse løsninger, hvor jeg skal gå i dybden med tingene, da jeg har en meget logisk og evidensbaseret fremgangsmåde, i og med min personlighedstype er “INTJ“, samtidig er jeg også det, der hedder en “Shaper», som gerne vil have tingene fra hånden, og som gerne vil lede folk, hvilke jo er perfekt for mig, når jeg arbejder som projektleder.

Men det er jo mine styrker, men man skal ikke tage sådan test kun for at se ens egne eller andres styrker, det er lige så vigtigt at kigge på, hvad er man ikke så gode til. For mig er set eksempelvis (fordi jeg er INTJ) svært for mig at opfange folk hints til, hvad de egentlig gerne vil, fordi min hjerne er så logisk, så forventer jeg bare, at folk fortæller mig direkte, hvad de gerne vil, og læser aldrig mellem linjerne, når folk siger noget. Andre personlighedstyper bruger meget “mellem linjerne” kommunikation, og kan derfor blive irriteret på INTJs, når de føler sig ignoreret. Så jeg skal personlig arbejde på at fortolke mere på, det folk siger end jeg normalt bare ville. En anden svaghed jeg har, fordi jeg er en “Shaper” er, at jeg elsker at starte projekter tegne og tilrettelægge dem, men jeg synes også de bliver kedelige, når vi er lige ved at være i mål. Så jeg skal være meget skarp i slutningen af projekterne på at have fokus på at få projektet helt i mål, fordi mit hjerte nu nok er lagt i et andet projekt. Men igen, fordi jeg nu ved dette, så kan jeg nemmere sætte et system op, der sikrer, at projektet stadig bliver leveret til tiden, og af høj kvalitet.

Så dette var bare et eksempel på, hvorfor det er vigtigt at vide, hvem folk er, og hvad de godt kan lide at arbejde med. En opgave, som jeg har haft tidligere, som jeg var forfærdelig dårlig til på grund af min personlighedstype var eksempelvis at skrive produkttekster for mere “følelsesmæssige” produkter som blomster og vine. Min logiske hjerne listede blot, hvor mange roser der var, og hvilken pynt der var omkring. Jeg tilføjede endda vægten af buketten. Man skal helst gerne have fokus på noget andet, når man skriver om buketter, det skal gerne være mindre logiske, og mere følende tekster der bliver skrevet. Så husk på dette i fremtiden, hvis en I din projektgruppe leverer noget, som ikke er super godt, så er det ikke sikkert, det er fordi han er doven eller dum, det kan sagtens være, at du bare har givet ham en forkert opgave til at starte med.

Men hvad kan du så gøre? Jamen det er meget enkelt, tag et opstartsmøde med dit team, hvor I tager to personlighedstests. Jeg vil anbefale, at I tager en Myers briggs test samt en Belbin Team Role test. Det er de to tests, som jeg snakkede om lige før (INTJ/Shaper). På den måde får du et mentalt overblik over, hvilke opgaver folk er gode til, og hvilke det ville trives med. Du kan endda gå så vidt at lave en form for baseball kort med folks styrker/svagheder, som Alexa Diehl har gjort, og dele dem med de andre, så de også ved, hvem der er god til hvad.

Når du først ved, hvad folk er gode til, så bliver det pludselig meget nemmere at delegere opgaver, og det bliver nemmere at estimere opgaver, når du ved, om det vil være en let eller kompleks opgave for personen.

Kig tilbage på, hvad der gik galt sidst

Det er vigtigt, at du studerer tidligere projekter, uanset om du, eller andre i virksomheden kørte dem. Der er uden tvivl noget historisk data, der kan hjælpe dig med dit kommende projekt. Det kunne være processor 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 fejl estimere 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 ad 100 lignende opgaver er gået over tid. Så kan du allerede ved nr. 4 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 retrospektiv feedback‐loop.

Husk at stille en masse spørgsmål

Du er nødt til at stille en masse spørgsmål, uanset om du skal estimere et projekt baseret på en uddybende kravsspecifikation, en kort email med en ide, eller efter at have snakket med en ved kaffemaskinen. Det er vigtigt, at du ved så meget som muligt om projektet, inden du kommer med dine estimater. Snak gerne med dem, som er kommet med forslaget, og snakke med de ansatte/kunder, som kommer til at blive påvirket af projektet. For du kan ikke komme med et realistisk estimat før det meste er afdækket.

En af de største grunde til de fejl estimeringer, som jeg har lavet, har simpelthen været, når jeg har antaget, at det skulle være på en måde, men at det så senere (typisk ret sent i projektet) har vist sig at skulle være på en helt anden måde. Jeg var nemlig i starten ikke så glad for at booke møder med salgsstyrken eller ringe til kunderne for at spørge dem omkring uklarheder omkring projektet. Jeg var bange for, at de ville tro, at jeg ikke forstod det. Men i dag, selv om jeg er 99% sikker på, hvordan det skal være, så spørger jeg alligevel folk omkring alle aspekter af projektet. For gang på gang viser det sig, at der er mere, bare den oprindelige beskrivelse af projektet, der er typisk mange bagvedliggende processorer, som kunderne eller ansatte ikke tænker over, men som først kommer frem, når du stiller disse “dumme spørgsmål”.

Mange gange inden for digitale projekter er det sådan noget som integrationer med andre systemer, som ikke er med i det oprindelige opdrag. Sådan noget, som integrationer ind i ERP eller CRM‐systemet er sjældent med, da mange ikke tænker over, at ordre i den nye eshop ikke bare på magisk vis finder vej til deres ERP system. Så ved eshop projekter har jeg tit stillet spørgsmålet: “Skal ordrene komme direkte ind i SAP, eller vil I taste dem manuelt?” Og det er forskelligt, hvad virksomheden ønsker. Nogen vil gerne gøre det manuelt, og andre vil gerne have det automatisk.

Hvad skal du spørge om?

Det ville være dejlig nemt, hvis du bare kunne tage det projekt, der er fremlagt for dig, og bare estimere det direkte. Men som jeg skrev ovenfor, så er det desværre sjældent, at man bare kan det. Så nedenfor har jeg lavet en liste af spørgsmål, som jeg næsten altid stiller i starten af projekter for at estimere projektets størrelse.

  • Hvad er målet med projektet? Hvad vil I gerne opnå?
  • Hvordan måles succesen af projektet? Antal besøgende? Antal ordre? Højere omsætning? Lavere omkostninger
  • Hvor mange og hvem vil deltage i projektet? Både interne og eksterne ressourcer.
  • Hvad skal det nye kunne som det nuværende ikke kunne?
  • Hvad kan det nuværende, som det nye ikke skal kunne?
  • Kan du beskrive, hvordan du gerne vil have, at det skal virke, eller hvordan det skal se ud?
  • Er der en sat fast deadline for projektet allerede nu?
  • Har I snakket med kunderne, som skal bruge det efterfølgende?
  • Hvem vil være en del af styregruppen, som skal være med til at tage de overordnede beslutninger i projektet?

Denne liste kunne være uendelig lang, men disse er nok de vigtigste spørgsmål, som jeg ville stille, inden jeg startede med et projekt. Jeg har flere gange oplevet, at svaret var: “Det ved jeg ikke, det må da være dit ansvar at finde ud af det”. Men det vil jeg godt understrege, det er ikke dit job som projektleder. Det er dem, som kommer med projektet til dig, der skal kunne svare på disse spørgsmål, dit primære fokus er i stedet på at komme godt fra start og holde momentum under projektet. En projektleder skal egentlig helst ikke tage så mange beslutninger selv, men derimod gøre det nemt for andre i virksomheden eller kunderne at tage beslutningen.

Skab et visuelt overblik over projektet

Efter at have stillet alle disse spørgsmål giver det dig mulighed for let at kunne visualisere projektet. Grunden til, at du gerne vil 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 Photoshop, selv om det selvfølgelig kræver, at man er øvet deri. Men den mest enkle ville klart være at visualisere det ved hjælp af et Flowchart‐værktøj. Jeg anbefaler altid folk at bruge Lucidchart, det er i mine øjne en af de mest alsidige og enkle Flowchart‐værktøjer på markedet.

Lav en Work Breakdown Structure for dit projekt

At lave en Work Breakdown Structure (WBS) for projektet er noget, som jeg ser mange projektledere spring let og elegant henover nu til dags. 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. Det er heller ikke noget, som de mere agile metoder ligger vægt på længere, da de arbejder mere efter MVP‐tankegangen.

Men der meget værdi at hente i sådan en WBS, 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 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.

I eksemplet ovenfor ville projektet eksempelvis være en ny webshop. De fire første niveauer ville eksempelvis være “Produktoversigt”, “Produkt side”, “Kurv & Betaling” og “Blog”. Dette er de overordnede kategorier. Derunder (Level 2-4) opremser du derefter alle de muligheder, du gerne vil have på den nye webshop. Det kunne eksempelvis være “Avanceret filtrering af produkter” under “Produktoversigt” i Level 2. Under “Avanceret filtrering af produkter” tilføjer du så derefter “Filtrering på pris” i Level 3 og så videre.

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

Klar – Parat – Estimer

Nu har du fået styr på, hvad projektet skal indeholde ved at spørge andre omkring projektet, hvordan de forestiller sig det, når det er færdigt, og hvilket de mener, der skal med i projektet, og hvad der ikke skal med. Du har også lært de personer, som skal med i projektet at kende, hvilke opgaver de nemt og hurtigt kan klare, samt hvilke de vil have det svært med at klare. Du har også undersøgt, hvordan projekter tidligere har kørt i virksomheden, og fundet ud af, hvad det typisk er, som trækker projekterne ud. Og til sidst har du fået struktureret og visualiseret opgaverne. Nu mangler du “blot” at estimere opgaverne, og hertil har jeg en lille gave, nemlig det excel-ark, som jeg bruger til at estimere mine opgaver.

Projektestimerings Excel-ark

Klik for at downloade mit projekt estimerings Excel-ark. Alt hvad du skal udfylde er, hvor mange timer, som du mener, en given opgave vil tage, og hvor sikker du er på, at det vil tage den tid. Hvor sikker du er på dit estimat, kommer helt an på, hvor sikker du er på at have forstået projektet, og hvor sikker du er på, at virksomhedens processor ikke står i vejen for projektet. Samt om opgaven passer til den person, som den er givet til. Er du usikker på alle tre ting, ville jeg nok sidde en opgave til høj risiko, og er du helt sikker på alle ting ville jeg nok sætte den til lav risiko. Generelt sidder jeg de fleste til mellem risiko, også selv om jeg tror, de er lav risiko, for det ender tit med at tage lidt ekstra tid alligevel.

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.

Værktøjer som jeg arbejder med til dagligt:

AGIL PROJEKTLEDELSE

EN TRIN-FOR-TRIN GUIDE TIL EFFEKTIV PROJEKTLEDELSE

EN SKRIDT-FOR-SKRIDT GUIDE TIL EFFEKTIV PROJEKTLEDELSE

Jeg har lavet denne guide til at hjælpe dig med at drive dine projekter mere succesfuldt. Der er mange bevægende dele i de fleste projekter, og man kan hurtigt overse nogle dele af projektet. Jeg har derfor lavet denne trin-for-trin guide til effektiv projektledelse. 

Du kan med andre ord bruge denne guide til dit næste projekt og dermed sikre dig, at du husker alt. Jeg har tilmed inkluderet links til uddybende beskrivelser af de forskellige dele af projektet. 

Grunden til, at jeg lavede guiden var, at jeg gerne ville lave, en mere håndgribelig guide til projektledelse. En som var knap så teoretisk som SCRUM eller Prince2. Så du vil nok finde denne guide lettere at implementere i praksis, end de mere traditionelle projektledelses metoder.