The document provides an overview of project estimating. It discusses what estimating is, the objectives of estimating, categories of estimates like rough order of magnitude and definitive estimating. It covers items to estimate like development tasks and risks. Types of estimating like task-based and deliverable-based are presented. The document emphasizes that all estimates involve assumptions and contingencies to account for risks and unknowns. It provides examples of risk and contingency factors. Effective estimating requires experience, making reasonable assumptions, and validation techniques like triangulation of different estimate types.

1. Estimating 101
©2008 Protegra Inc. All rights reserved.

2. Agenda
• What is Estimating?
• Objectives of Estimating
• Estimates are Bad, don’t estimate
• Categories of Estimates
• Items to Estimate
• Types of Estimating
• Estimating Risk
- Budget and Schedule
• Estimating Contingency
- Budget and Schedule
• Estimating Friends
• Workshop
• Next Steps
©2009 Protegra Inc. All rights reserved.

3. What is Estimating?
• “Estimation is the calculated approximation of a result
which is usable even if input data may be incomplete or
uncertain.”
• “In project management (i.e., for engineering), accurate
estimates are the basis of sound project planning.”
©2009 Protegra Inc. All rights reserved. 3

4. Why Estimate?
• Allows you to justify an expense (ROI) or decide not to do it
• Companies or departments don’t get work unless they can
tell clients how much it will cost
- IT, construction, automotive repair, etc.
• Good estimates build trust that you know what you’re doing
• Good estimates allow you to plan a project that executes
smoothly
• The process of getting good estimates help drive system
design
• To facilitate the scheduling of people and resources on a
project to minimize conflicts and issues
©2009 Protegra Inc. All rights reserved. 4

5. Standard Estimating Methods
• Many processes have been developed to aid engineers in
making accurate estimates, such as
- Analogy based estimation
- Compartmentalization (i.e., breakdown of tasks)
- Delphi method
- Documenting estimation results
- Educated assumptions
- Estimating each task
- Examining historical data
- Identifying dependencies
- Parametric estimating
- Risk assessment
- Structured planning
©2009 Protegra Inc. All rights reserved. 5

6. Software Development Estimating
Methods
• Popular estimation processes for software projects include:
- Cocomo - 1981
- Cosysmo - 2002
- Event chain methodology – 2002?
- Function points - 1979
- Program Evaluation and Review Technique (PERT) - 1951
- Proxy Based Estimation (PROBE) (from the Personal Software
Process) - 1996
- The Planning Game (from Extreme Programming) – 2006?
- Weighted Micro Function Points (WMFP) - 2009
- Wideband Delphi - 1950
©2009 Protegra Inc. All rights reserved. 6

7. Estimates are Bad, don’t estimate
©2009 Protegra Inc. All rights reserved. 7

8. Truth
• Estimates aren’t bad, but they can highlight bad
practices/leadership
• For example:
- Expecting the estimate not to change when requirements have
- Expecting the schedule not to change when assumption are
incorrect
- Expecting the schedule not to change when the project is delayed
• To assist is this we need to provide qualified estimates.
- i.e. show your work
©2009 Protegra Inc. All rights reserved. 8

9. More Truth
• All estimates are limited by the experience of the estimator
- The more you estimate, the better you will get
• If you can’t envision the solution, you can’t estimate it
- Use assumptions to help with unknowns
• All estimates will be wrong
- Best you can hope for is you underestimate as much as you
overestimate
- Compensate for incorrect estimates with contingency budgets
- Compensate for risks with contingency budgets
• You need to be able to track actuals to estimate
- You can’t get better until you can measure where you went wrong
and why
©2009 Protegra Inc. All rights reserved. 9

10. Qualified Estimates
©2009 Protegra Inc. All rights reserved. 10

11. Don’t always blame the estimates
©2009 Protegra Inc. All rights reserved. 11

12. Categories of Estimates
• WAG – High Level Experience Based
• Rough Order of Magnitude – Experience Based
• Budget Estimating – High Level Deliverable Based
• Schedule Estimating – Deliverable/Schedule Based
• Definitive Estimating – Task Based
• It is important to set expectations in relation to the Estimate
Category:
- What is required to produce them?
- What is the accuracy of the estimate?
©2009 Protegra Inc. All rights reserved. 12

13. Estimate Category Comparison
Name Based on Expected Typical
Duration Accuracy
WAG Experience 1 person hour -100% to +250%
Rough Order of Magnitude Experience 4-8 person hours -25% to + 100%
Budget Estimating Deliverable 2-3 person days -20% to + 50%
Schedule Estimating Deliverable 5 person days -15% to +25%
Definitive Estimating Task 10-15 person days -5% to +10%
• The Type of Estimate, duration and accuracy are a set!
• i.e. We can’t generate a Definitive Estimate in 1 day just by using
our experience
©2009 Protegra Inc. All rights reserved. 13

14. Items to Estimate
Additive Friction Subtractive
Development Project Management Delays
Analysis Technical Management Vacation
Testing Meetings Sickness
Deployments Reality (6 hours a day) Defects
Planning Documentation Issues/Problems
©2009 Protegra Inc. All rights reserved. 14

15. Types of Estimates
• Task Based
- Technical tasks or processes
• Deliverable Based
- Documentation or solution functionality
• Schedule Based
- Roles by schedule
• All of these estimates can be either:
- Absolute
- Range
- Relative
©2009 Protegra Inc. All rights reserved. 15

16. Additional Estimating Factors
• Risks
- Things that could happen and that can be avoided with mitigation
planning
• Contingencies
- Things that are likely to happen and are unlikely to be avoided with
mitigation planning
• Both will result in additional budget and schedule in the
project plan
©2009 Protegra Inc. All rights reserved. 16

17. Estimating Risks and Contingencies
1. Estimate Risk and Contingencies from a budget point of
view
2. Estimate Risk and Contingencies from a schedule point of
view
• Remember when you estimate Risk and Contingencies to
estimate all the items and not just development
©2009 Protegra Inc. All rights reserved. 17

18. Sample Contingency Factors
• Poorly understood problem (0-30%)
• Knowledge of business people about software development (0-5%)
• Your Knowledge of business domain (0-5%)
• Business clarity of problem(0-10%)
• New Technology (0-10%)
• Solution Complexity (0-5%)
• Inability to accept Change Requests (0-5%)
• Business understanding of Project Methodology (0-5)
• Requirement Clarity (5-20)
• Is there a Data Conversion? (0-10)
• Business Understanding of Testing Process (0-10)
• Has Development Team Worked Together before ?(0-15)
• Small Project (0-15, 15=small number of days, 0= 9+ months))
• Integration Required? (0-5)
• Client Responsiveness / Availability (0-5)
©2009 Protegra Inc. All rights reserved. 18

19. Sample Risk Factors
• Schedule Creation
• Organization and Management
• Development Environment
• End Users
• Customer
• Contractors
• Requirements
• Product/Solution
• External Environment
• People
• Design and Implementation
• Process
• Project Risks.docx
©2009 Protegra Inc. All rights reserved. 19

20. Estimating Friends
Friends don’t let friends estimate alone
©2009 Protegra Inc. All rights reserved. 20

21. Assumptions
• Estimating is rarely done when adequate information in
provided. In this case there are three ways to address the
lack of information:
1. Request additional information before an estimate is provided.
• If this is not possible, there are two additional courses of
action
2. State that an estimate is not possible until the information is
received
3. Assumption it away
• Create assumptions that allow you to create the estimate
• IMPORTANT: The assumptions must be reasonable and realistic
©2009 Protegra Inc. All rights reserved. 21

22. Experience
• Experience with estimating on previous projects are also a
great asset
• I wouldn’t review the estimates before estimating as it may
negatively affect current estimates
• I would use previous estimates as a validation of current
estimates being provided.
• Of course experience of providing estimates previously will
help you to provide better estimates
©2009 Protegra Inc. All rights reserved. 22

23. Triangulation
• The ability to triangulate multiple estimation for validation
and verification in invaluable
• Task, Deliverable, and schedule estimates can be compared
and should generate the same estimate. (within reason)
- Great way to ensure you haven’t missed some factors
©2009 Protegra Inc. All rights reserved. 23

24. Estimating Workshop
• Your extended family just won 2 months worth of trips to
DisneyWorld and you need to determine when to schedule
your flights and how long to book at executive house for. (all
flights/accommodations/Park passes are included) You
don’t want to reserve the house for too long as you may
impact other family members on getting their desired
number of days.
• Please come up with an estimate for your the trip. You will
need to come to a scheduling meeting with the other
members of your family to figure out the final schedule. (So
you may have to provide the rationale behind your estimate.)
It may also be hard to move the dates after they are agreed
to, so it is important that everyone come prepared.
©2009 Protegra Inc. All rights reserved. 24

25. Workshop Questions
• What category of estimate did you do?
- WAG/ROM/Budget/Schedule/Definitive?
- Why?
• What type of estimate?
- Task/Deliverable/schedule?
- Why?
• What terms did you estimate in?
- Absolute/Range/Relative?
- Why?
• What Items did you estimate?
- Additive/Friction/Subtractive?
• Did you estimate for Risk?
• Did you estimate for Contingency?
• What estimating assumptions did you make?
©2009 Protegra Inc. All rights reserved. 25

26. Q&A
©2009 Protegra Inc. All rights reserved.

27. Thank You!
Name: Terry Bunio
Role: Principal Consultant
E-mail: terry.bunio@protegra.com
Main: 204-956-2727
www.protegra.com
©2009 Protegra Inc. All rights reserved. 27