The document discusses improving software project estimates by putting more effort into understanding project scope, gaining experience in the relevant domain and technology, and accounting for unanticipated work. It notes that estimates are often too optimistic due to the "planning fallacy". Better approaches include basing estimates on past actuals, recording time ongoing, and communicating lessons learned beyond just hour estimates. The goal is to provide more accurate and useful information to decision-makers while acknowledging estimates will always have some uncertainty for large projects.

1. Better Estimates
Jane Prusakova
@jprusakova

2. 2Viasat Proprietary
Every developer and every line manager everywhere

3. 3Viasat Proprietary
›More accurate
›More confident
›Less effort to deliver
Defining better

4. 4Viasat Proprietary
› Estimates happen early in the project life cycle
– Little is known about the project – including scope, requirements, technical details and
resources.
– With software development every project is different. Often there is little experience in the
domain, technology and resource management.
– Anticipated work and risk gets estimated. Unanticipated work is typically left out from the
estimating effort.
Facts about estimates

5. 5Viasat Proprietary
Put more effort into learning
the scope, requirements,
technical details and
resources.
What we do
Little is known about the
project – including scope,
requirements, technical
details and resources
Increase time and effort for creating estimates.

6. 6Viasat Proprietary
Gain experience in the
domain, technology and
resource management. Seek
help from experts.
What we do
Every project is different.
Often there is little experience
in the domain, technology and
resource management
Time and effort that may go more directly toward getting the project done. Pushes
out estimate delivery timeline, but also improves accuracy.

7. 7Viasat Proprietary
Put more effort into
discovering the work needed
for the project.
What we do
Anticipated work and risk
gets estimated. Unanticipated
work is typically left out from
the estimating effort.
Takes time and effort, produces valuable knowledge.
Results are hard to convert to a date or time line.

8. 8Viasat Proprietary
Software projects report 1994 - 2004
• 16% … 29%
Successful
• 53% … 53%
Challenged
• 31% …18%
Aborted

9. 9Viasat Proprietary
Software projects report 1994 - 2004
• 16% … 29%
Successful
• 53% … 53%
Challenged
• 31% …18%
Aborted
›Success is defined as “delivered as
estimated”
›Anything less than successful can be due
to poor execution – or bad estimate

10. 10Viasat Proprietary
› Sydney Opera house was estimated to take 6 years and
$7mln to build. It was completed after 16 years and
$102mln.
› Denver International Airport was estimated to take
– 4 years and $2.6bln.
– It started operating after 5.5years, having spent $4.8bln, with
reduced scope. Baggage handling was never implemented
as originally designed.
› Home Redecorating/Remodeling for kitchens and
bathrooms
– Redecorating projects were over budget 35% of the time
– Remodeling projects were over budget 53% of the time
What others do

11. 11Viasat Proprietary
› Past effort is consistently underestimated
› Future effort is estimated optimistically
– Consistently
– Despite having good information about past performance of same tasks
– Estimating larger efforts with deadline farther out in the future exacerbates the effect of too-optimistic predictions
› Work by others is estimated more realistically
– Applies to both past effort and future work
Studies looked at filing taxes, completing a college thesis, writing a book.
Behavioral science: planning fallacy

12. 12Viasat Proprietary
Random events are skewed to introduce additional cost and delay
Not evenly balanced between positive and negative results
Larger efforts take longer to react to unexpected events
Increasing the cost of delay as unexpected events arise
Consequences of disruption are non-linear, i.e. small delays compound into larger schedule slips over life of larger
projects
Error effect in estimates: more on planning fallacy

13. 13Viasat Proprietary
› Estimate other people’s work and let others estimate yours
– to avoid optimistic bias
› Consider past estimates, use logged time for work already done, and calculate actual
effort involved
– Keep records of on-going work. Consult those records when working on future estimates
– Calculate appropriate multipliers and apply to future estimates
› Learn to live with low-confidence estimates on larger efforts
– Improve ROI by limiting time & effort spent on early estimates
› Focus estimation effort on smaller and more familiar projects for higher-confidence
estimates
What can we learn from science and history?

14. 14Viasat Proprietary
The Mythical Man-Month: Essays on Software Engineering
by Frederick Phillips Brooks
Originally published in 1975
Later editions come with additional essays

15. 15Viasat Proprietary
`

16. 16Viasat Proprietary
Programmers are optimists
› In the upper left of Fig. 1.1 is a program.
› It is complete in itself, ready to be run by the
author on the system on which it was
developed. That is the thing commonly
produced in garages, and that is the object
the individual programmer uses in
estimating productivity.
› In the bottom left is a programming product.
› This is a program that can be run, tested,
repaired, and extended by anybody. It is
usable in many operating environments, for
many sets of data. It must be written in a
generalized fashion. Must be thoroughly
tested, so that it can be depended upon.
Finally, it requires its thorough documentation,
so that anyone may use it, fix it, and extend it.
A

17. 17Viasat Proprietary
Programmers are optimists (contd.)
› Top right: programming system component
› every input and output conforms in syntax and
semantics with precisely defined interfaces.
The program must also be designed so that it
uses only a prescribed budget of resources.
Finally, the program must be tested with other
system components, in all expected
combinations. This testing must be extensive,
for the number of cases grows
combinatorially. Subtle bugs arise from
unexpected interactions of debugged
components.
› Bottom right: programming system product
› Many components working together. Cost
may rise further with more components,
tighter dependencies, and moving
dependencies.

18. 18Viasat Proprietary
›Estimates inform business decisions
– Is this project feasible?
– How long until we realize any benefit, a sizeable benefit, all the expected benefit from
success?
– What will we have to give up in order to make this project happen?
– What is worth giving up for this project?
– What do we lose in case of failure? What do we lose in case of time overruns?
Better estimates: purpose

19. 19Viasat Proprietary
› There is typically a need for projected delivery dates in order to coordinate with other teams working in
the same problem space
› There is also a need to allocate resources over time based on expected progress of the project
› In addition, estimate is often used as a measuring stick for project success (i.e. CHAOS reporting
metrics)
› The goal of estimates that get created should be to satisfy a tangible business need.
Can we live with no estimates?

20. 20Viasat Proprietary
› Estimate often
› Record actual spent
– Calendar time
– Effort
› Work from past history when creating future estimates
– Check your optimism
› Communicate learning
– Share more than the # of hours estimated
Better approach to estimating

21. Better Estimates
Jane Prusakova
@jprusakova

22. 22Viasat Proprietary
› Estimating is discovering and sharing useful information about a body of work
– Usually focused on work not done
– Occasionally about work that has been done, but no records are available
› Estimates are assumed to be a fictional number of man-hours
Estimating != estimates