Flow of Software Estimates on a Well-Established ProjectChapter 16

Poorly estimated projects• No focus on estimating size of the software• Instead, focus is on estimating cost, effort and schedule

Based on what?• Lots of re-estimating as project schedule slips

Flow of Software Estimates on a Well-Established ProjectChapter 16

Poorly estimated projects• No focus on estimating size of the software• Instead, focus is on estimating cost, effort and schedule

Based on what?• Lots of re-estimates as project schedule slips

Flow of Software Estimates on a Well-Established ProjectChapter 16

Poorly estimated projects• No focus on estimating size of the software• Instead, focus is on estimating cost, effort and schedule

Based on what?• Lots of re-estimates as project schedule slips

Flow of Software Estimates on a Well-Established ProjectChapter 16

Poorly estimated projects• No focus on estimating size of the software• Instead, focus is on estimating cost, effort and schedule

Based on what?• Lots of re-estimates as project schedule slips

Poorly estimated projects• Inputs, the estimation approach, and outputs (the

estimates) not well defined• Effort at better definitions is usually focused on making

the estimate smaller(to make it smaller)

TIP: Don’t argue over the output (the estimate)… change the output only by changing the inputs

A well-estimated Project• Adjust the inputs until to you get an acceptable

outcome• The approach/process should not be designed to

create a specific estimate

Focus on estimating Size firstFig. 6.3Flow of a single estimate on a well-estimated project.Effort, Schedule, Cost & Features are computed from a

Size estimate

Schedule

Size Effort Cost

Features

Fig. 16-4 Summary: Matching estimation techniques to the project phase

Iterative ProjectSmall Sequential ProjectLarge Sequential Project

Kind of Technique Pre-

Requ

irem

ents

Dur

ing

Req't

s

Dur

ing

Des

ign

Dur

ing

Cons

truct

ion

Dur

ing

Initi

al P

lann

ing

Dur

ing

Cons

truct

ion

Dur

ing

Initi

al P

lann

ing

Dur

ing

Cons

truct

ion

Computing

Counting

Historical Data from Organization

Historical Data from Sam Project

Decomposition

Analogy

Proxy-Based Estimation

Complex Algorithm

Automated Estimation Tool

Expert Judgment

Estimates by Skilled Estimators

Estimates by Contributors

Bottom-up, Task-Level Estimation

Group Estimates/Reviews

Estimation FlowLarge projects• At the start, nothing to count• Use algorithms, SW tools, etc.• Refine with group reviews• Later stages, move to historical-based approaches & bottom-up

task estimationSmall projects• Same approach at the start• As soon as people are assigned, estimate tasks (work packages)

(bottom-up)

Estimation refinementWhat to do when you “slip” (miss a milestone)?Options (which to choose):1. Assume you can make up the lost time later in the schedule2. Add the time slipped to the total schedule3. Multiply the whole schedule by the magnitude of the slip (e.g.

50%)Most common approach: Option #1

Seldom the best choice1991 survey: 300 projects, time is not made-up

Option #2 assumes that the slip was an anomaly, the rest of project will be “right on”Typical slips represent systemic problems (they will happen again)

Unlikely that the entire estimate is correct. With rate exceptions Option #3 is the it.

Re-estimation

Single point estimate:When First Interim Release takes 18 months, management goes ballistic!Panic: behind schedule and over budget

EstimatePoint in Project (Staff Months)

Initial concept 10Approved product definition 10Requirements complete 13User interface design complete 14First interim release 16

FINAL 17

Re-estimation

Range estimates:Allows for tightening up the estimate as the project progressesWhich means, narrowing the rangesBeing honest about the 90% confidence level

EstimatePoint in Project (Staff Months)

Initial concept 3-40Approved product definition 5-20Requirements complete 9-20User interface design complete 12-18First interim release 15-18

FINAL 17

When to present re-estimates(the tightening of the ranges)

A Well-estimated ProjectDot represents the actual project outcome.

Poorly estimated Project

Dot represents the actual project outcome.