Lær hvordan du estimere 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 at 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 studere 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 process 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 og 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 vigtig at du involvere dig i opgaverne. Det er klart at du ikke skal tage for meget på dine skuldre, dit primære ansvar er jo stadig ressource allokering og budget osv. Men det er vigtig 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 vigtig 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å du skal sikre dig at du kender de 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 forbedre 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 vigtig at du kender dem du arbejder sammen med, for det er ultimativt sådan at du sikre dig at opgaverne bliver løst korrekt og til tide. Mange er under den overbevisning at alle kan gøre alt lige godt, og at folk der “sjusker” med nogen 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 at 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 bliver derfor 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 sikre at projektet stadig bliver leveret til tiden, og af høj kvalitet.

Så dette var bare et eksempel på hvorfor det er vigtig 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 levere 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 gode 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 vigtig at du studere 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 Marketing afdelingen 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 og 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 en 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 retrospective feedback loop.

Husk at stille en masse spørgsmål

Du er nød 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 vigtig 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 snak 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 processor 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øgene? 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 overordnet 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 nogen 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 spare 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 hvilke 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 overordnet 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” du så derefter tilføje “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å igang 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 download 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. Sikker på du er på dit estimat kommer helt an på hvor sikker du er på at du har forstået projektet, hvor sikker på du er på at virksomhedens processor ikke står en vejen for projektet, og 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.

Skriv en kommentar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *

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