Hvordan utvikle et grovt størrelsesoverslag (ROM-estimat)

Et grovt størrelsesoverslag (ROM-estimat) en estimering av prosjektets innsatsnivå og kostnad for å fullføre. Et ROM-estimat finner sted veldig tidlig i et prosjektets livssyklus – i løpet av prosjektvalg og godkjenningsperiode og før prosjektinitiering i de fleste tilfeller. Hovedformålet med ROM-estimatet er å gi beslutningstakere den informasjonen som er nødvendig for å ta en beslutning om det er fornuftig å gå videre med prosjektet basert på estimert innsatsnivå, når det gjelder sluttid og kostnad.

Å utvikle et ROM-estimat er like mye en ferdighet som det er en kunst. Først og fremst bør fageksperter være involvert i estimering av innsatsnivå. For det andre, når du utvikler en ROM, er det viktig å forstå at estimatet er et «Rough Order of Magnitude» estimat som vil ha en nøyaktighet på omtrent pluss eller minus 50%. Avhengig av kilde kan variansen være så mye som 100 %. En avvik på -25% til + 75% er også vanlig for ROM-estimater. Poenget er å gi et «ballpark» -estimat ved hjelp av den tilgjengelige informasjonen på det tidspunktet.

Et ROM-estimats varians er heller stor, men det skal ikke avskrekke deg fra å gjøre et forsøk. Husk at noe informasjon er bedre enn ingen informasjon. Husk også at estimatet er basert på informasjonen som var tilgjengelig da ROM-estimatet ble utviklet. Når prosjektet går fremover, kan du forvente å forbedre estimatet ytterligere, når mer informasjon blir innhentet og kravene blir ytterligere forbedret i løpet av prosjektets initierings- og planleggingsfaser (PMBOK-studenter, husker du begrepet progressiv utdyping?)

Følgende informasjon gir en sammenligning av de tre generelle estimatene når prosjektet går gjennom livssyklusen.

  1. ROM-estimat (avvik på -50% til + 50%, eller -25% til + 75% avhengig av preferanse)
    • Et «ballpark» -estimat som brukes til å gi et startestimat for å komme videre
    • En estimeringsmetode opp og ned
    • Bruk av tidligere ekspertkunnskap og erfaring
    • Det brukes ikke mye tid på å utvikle ROM-estimatet
  2. Budsjettestimat (avvik på -10 % til + 25%)
    • Også en tilnærming til estimering ovenfra og ned
    • Bruk av analoge estimeringsteknikker bidrar til å gi et litt mer nøyaktig estimat enn ROM-estimatet (f.eks. referanse tidligere lignende typer prosjekter for innsats)
  3. Definitive Estimate (Variance of -5% to + 10%)
    • En estimeringsteknikk fra bunnen av og opp som krever en nedbrytning av arbeidet og dets innsatsnivå som oppsummeres for å utvikle et mer nøyaktig estimat
    • Generelt utført i planleggingsfasen og modnet gjennom resten av prosjektet
    • Dette er mest tidkrevende estimeringsinnsats for de tre oppførte

Når du utvikler et ROM-estimat, er det best å prøve å estimere i bøtter med tid og kostnad. Å tilby kategorier kan hjelpe estimatorer som ellers ikke ville være i stand til å oppgi ett nummer på grunn av den begrensede mengden informasjon som var tilgjengelig ved starten av et prosjekt. Eksemplet nedenfor gir kategorier av «Lav», «Medium» og «Høy» innsats. Det kan være enklere å bruke en slik skala enn å prøve å trekke et tall ut av hatten. Det setter også forventningen på begge sider – prosjekt team og klient – at ROM-estimatet har stor avvik og skal gjenkjennes som bare en innledende ROM.

  1. Lav innsats
    • Timer: 40 til 80 timer å fullføre
    • Kostnad: $ 1000 til $ 5000 dollar
    • Varighet: 1 til 4 uker
    • Antall ressurser: 1 til 3 ressurser
  2. Middels innsats
    • Timer: 80 til 480 timer å fullføre
    • Kostnad: $ 10.000 til $ 50.000 dollar
    • Varighet: 2 til 6 måneder
    • Antall ressurser: 4 til 10 ressurser
  3. Høy innsats
    • Timer: 480 til 2080 timer å fullføre
    • Kostnad : $ 100.000 til $ 500.000 dollar
    • Varighet: 6 til 12 måneder
    • Antall ressurser: 11 til 20 ressurser

Ved hjelp av bøtter, eller kategorier som de som er oppført ovenfor, de komponere arbeidet ovenfra og ned til et detaljnivå som gir mening gitt mengden tilgjengelig informasjon. Forutsatt at prosjektet er i veldig tidlige stadier, og interessenters behov og krav er på et høyt nivå, er det trygt å anta at fordelingen av arbeidet ikke vil være detaljert detaljert. Poenget er ikke å utvikle et fullverdig WBS her. Poenget er rett og slett å dele arbeidet opp i et sett med aktiviteter som gir mening og som kan måles.For eksempel ved å utvikle en webapplikasjon, kan arbeidslisten bare være noen få ting som dette:

  1. Utvikle krav
  2. Utvikle databaseskjemaet
  3. Utvikle applikasjonen
  4. Test og distribuer applikasjonen
  5. Prosjektledelsesaktiviteter (Ikke glem å ta med PM-aktiviteter. Det tar tid og ressurser)

Bruk en kategori av innsats på hvert arbeid for å komme til et ROM-estimat. Det er det i et nøtteskall!

Det er mye mer å vite om teknikker for kostnadsestimering og kostnadsestimering (for eksempel anvendelse av læringskurver, kompleksitetsfaktorer og risikofaktorer; PERT-tidsestimering; Programvarestimeringsteknikker som f.eks. funksjonspunktanalyseteknikk og COCOMO – http://cost.jsc.nasa.gov/COCOMO.html). Men dette er en god primer, i det minste på ROM-estimering. De relaterte lenkene nedenfor gir ytterligere tips om kostnadsberegning. Se også Society of Cost Estimating and Analysis (http://www.sceaonline.org/), som er en tankeleder på denne arenaen. Forvent at mye mer kommer på kostnadsestimering!

Vil du dele flere tanker eller informasjon om ROM-kostnadsestimering? Legg dem til kommentarseksjonen nedenfor.

—–

Relaterte lenker:

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *