Estimering er en af de discipliner i projektledelse, der mest direkte påvirker både tillid, prioriteringer og beslutninger. Et estimat er sjældent “bare et tal”. Det er en aftale om forventninger, og ofte også en styringsmekanisme.
Alligevel ser man tit, at teams skændes om metodevalg: Skal vi starte oppefra med et hurtigt overslag, eller nedefra med detaljerede timeforbrug pr. aktivitet?
Valget mellem top-down og bottom-up estimering handler i praksis om timing, modenhed i scope, og hvad estimatet skal bruges til.
— Du kan få dem tilsendt herunder! —
Hvorfor estimering næsten altid bliver sværere end planlagt
Et projekt bliver ikke usikkert, fordi folk er dårlige til at regne. Det bliver usikkert, fordi informationen er ujævn fordelt: Sponsor vil have et tal nu, teamet kan først give et godt tal senere, og kravene flytter sig, mens man taler om dem.
Derfor giver det mening at tænke i to spørgsmål, før man vælger metode:
Hvad skal estimatet bruges til lige nu, og hvor stor er prisen ved at ramme ved siden af?
Top-down estimering: hurtigt overblik og tidlige beslutninger
Top-down estimering starter med et samlet overslag for hele projektet og fordeler det bagefter ud på faser, leverancer eller større “klumper” af arbejde. Det kan være baseret på erfaringstal, historiske projekter, ekspertvurdering eller simple nøgletal.
I en organisation med porteføljestyring er top-down ofte det første, der sker. Man skal kunne svare på “ligger det her i størrelsesordenen 200.000 kr. eller 2 mio. kr.?” før man bruger tid på detaljer.
Top-down fungerer bedst, når projekter ligner hinanden nok til, at erfaringstal giver mening. Det gælder også, når man er i en idéfase og stadig mangler krav, design og afhængigheder.
Fordele ved top-down
Top-down kan give tempo i de tidlige faser og mindske spildtid, hvis projektet alligevel ikke bliver godkendt.
Det skaber også en tydelig ramme: Et budgetloft eller en tidsramme, som teamet efterfølgende kan planlægge indenfor.
Ulemper ved top-down
Udfordringen er, at top-down nemt skjuler det arbejde, der ikke råber højt: interne koordinationsopgaver, test, dataoprydning, compliance, overlevering, driftsforberedelse, møder og feedbackrunder.
Et top-down estimat kan også blive politisk. Hvis tallet kommer som et direktiv, kan det blive brugt som plan i stedet for som et tidligt pejlemærke, og så starter projektet med en skjult gæld.
Bottom-up estimering: detaljer, ejerskab og bedre styring
Bottom-up estimering starter med at bryde leverancer ned i mindre dele, helt ned på work packages eller konkrete opgaver. Hver del estimeres, og summen bliver projektets total.
Metoden kræver typisk en Work Breakdown Structure (WBS) eller en tilsvarende opdeling. Du får til gengæld et estimat, der kan forklares: “Vi lander her, fordi vi har disse aktiviteter, med disse antagelser, med disse ressourcer.”
Det er sjældent tilfældigt, at bottom-up ofte bruges, når der er fast pris, hårde deadlines, ekstern leveranceforpligtelse eller høj risiko ved budgetoverskridelser.
En enkel sidegevinst: Teamet får bedre fælles billede af, hvad der faktisk skal leveres.
Fordele ved bottom-up
Når man estimerer på lavt niveau, bliver huller i scope synlige. “Hvem laver migreringen?”, “Hvem skriver brugervejledning?”, “Hvem sætter monitorering op?” dukker op, før det bliver dyrt.
Bottom-up gør det også lettere at styre undervejs, fordi opgaverne allerede ligger i en struktur, der passer til opfølgning på fremdrift.
Ulemper ved bottom-up
Det tager tid. Og det koster fokus fra eksekvering, hvis man går for tidligt i detaljen.
Metoden kan også give falsk tryghed: Mange små tal kan se præcise ud, uden at være det. Hvis antagelserne er svage eller teamet mangler erfaring, ender man med et detaljeret gæt.
Sammenligning, der giver mening i hverdagen
Den mest nyttige sammenligning er sjældent “hvilken metode er bedst?”. Det er “hvilken metode giver den rigtige samtale lige nu?”
| Dimension | Top-down estimering | Bottom-up estimering |
|---|---|---|
| Startpunkt | Ét samlet overslag | Små opgaver og work packages |
| Hastighed | Hurtig at producere | Langsommere, kræver forberedelse |
| Typisk præcision | Lavere, afhænger af analogi og antagelser | Højere, hvis scope og kompetencer er på plads |
| Krav til input | Overordnet scope og erfaringstal | WBS, opgavebeskrivelser, ressourcer, antagelser |
| Styringsværdi | God til tidlig rammesætning | God til plan, opfølgning og prioritering |
| Risiko | Skjulte opgaver opdages sent | Estimeringsarbejdet kan blive tungt og dyrt |
Hvornår vælger du hvad? En praktisk beslutningsmodel
Det rigtige valg kan skifte flere gange i samme projekt. Et tidligt top-down tal kan være nødvendigt for at få grønt lys. Senere skal du bruge bottom-up for at kunne styre sikkert.
Efter en kort afklaring med sponsor og team kan du bruge disse tommelfingerregler:
-
Tidlig screening: Når du skal vurdere om projektet er værd at starte
-
Budgetloft: Når der er en fast økonomisk ramme, som planlægningen skal passe ind i
-
Uklart scope: Når krav, løsning og afhængigheder stadig er åbne
-
Fast pris eller bindinger: Når du skal kunne stå på mål for tallet udadtil
-
Kompleks leverance: Når mange teams, systemer eller leverancer skal koordineres
-
Høj risiko ved fejlestimat: Når en overskridelse får tydelige konsekvenser for drift, kunder eller compliance
Læg mærke til, at de to sæt ikke er modsætninger. De beskriver bare, hvad du optimerer for.
En hybrid, der ofte virker: top-down først, bottom-up når det kan betale sig
Mange projekter lykkes bedst med en bevidst kombination. På BlivProjektleder.dk anbefaler vi ofte at tænke i “rullende detaljering”: Estimér groft, når du ved lidt, og skru op for detaljen, når du ved mere.
Her er en enkel proces, som kan bruges i både klassiske og agile forløb:
- Lav et top-down overslag for hele initiativet baseret på erfaringstal og antagelser, og skriv antagelserne ned.
- Sæt et foreløbigt budget og en tidsramme, og aftal hvor stor usikkerheden må være på dette tidspunkt.
- Bryd kun den næste del af projektet ned (nærmeste fase, de næste 4-8 uger, næste release) og lav bottom-up på den del.
- Brug læringen fra de detaljerede dele til at opdatere det samlede overslag og justér plan, scope eller bemanding.
Det er sjældent nødvendigt at bottom-up estimere et helt år frem, hvis du alligevel ved, at kravene ændrer sig undervejs.
Typiske faldgruber, når man estimerer top-down
Top-down går galt, når det bliver behandlet som et løfte i stedet for et tidligt bud.
Det sker især, når man springer samtalen om antagelser over. Et overslag uden antagelser er svært at justere senere, uden at nogen føler, at planen “skred”.
Efter et afklarende møde, så tjek om du kan genkende nogle af disse faresignaler:
- Udtalte tal uden at nævne datagrundlag
- Sammenligning med et “lignende projekt”, som ikke var så lignende endda
- Budget sat før scope er afklaret
- Ingen reserver til kendte risici
- Planen låser teamet tidligt
Hvis du ser flere af dem, så brug top-down som ramme, men planlæg hurtigt en overgang til mere detaljeret estimering på de mest risikofyldte leverancer.
Typiske faldgruber, når man estimerer bottom-up
Bottom-up kan blive for tungt, hvis man gør det til en regneøvelse i stedet for en planlægningsøvelse.
Den klassiske fejl er at gå alt for dybt: Opgaver på 15 minutter, uendelige estimeringsworkshops og gentagne re-estimater, fordi scope stadig flytter sig.
Det er ofte bedre at stoppe opdelingen, når du kan styre opgaven: Du kan tildele ansvar, du kan følge fremdrift, og du kan se afhængigheder. Alt under det niveau giver sjældent mere styringsværdi.
Gør estimatet anvendeligt: antagelser, buffer og opfølgning
Et brugbart estimat består af mere end summen af opgaver. Det består også af den kontekst, der gør tallet retvisende.
Sørg for, at dit estimat altid følges af:
- En kort liste over antagelser (hvad skal være sandt, for at tallet holder)
- En definition af “færdig” pr. leverance, så alle estimerer det samme
- En synlig reserve, der matcher usikkerheden og risikobilledet
- En plan for opfølgning, hvor estimater opdateres, når ny viden kommer til
Når du kan pege på antagelser og risici, bliver estimering mindre følelsesladet. Det bliver en styringsdialog.
Og det er i den dialog, forskellen mellem top-down og bottom-up for alvor bliver nyttig: Top-down sætter retning og ramme, bottom-up gør planen styrbar.
Relaterede indlæg
— Du kan få dem tilsendt herunder! —