ESTIMATING TECHNIQUES

BY

MICHAEL MILCH, PMP®

Estimating

• Definition• Project Impact

Bottom Up Estimating.

Top Down Estimating.

• Artifacts• Parametric• Other

Reviewing the Estimate

Estimating Flow Chart

Agenda

AN ACCURATE ESTIMATE IS THE GOAL.

Therefore:

An overall estimate process should be used to obtain a reliable, repeatable estimate that can be explained.

The overall estimate process will use acknowledged approaches, techniques, and standards.

Please note:

1. No estimate can be guaranteed to be wholly accurate. After all… it is an estimate! It helps to place the estimate within a range.

2. When doing an estimate, more than one approach should be used.

ESTIMATING ACCURACY INCREASES THROUGH THE PROJECT LIFECYCLE.

The earlier in the cycle the estimate is done the more likely it will be less accurate than estimates

done later.

More knowledge = Better estimates.

Project estimating is a major problem area.

Why Projects Overrun. (Computing, 2 Dec 1999)

Unrealistic initial deadlines and improperly set customer expectation are created due to bad estimates.

A - 01 Customer Expectations not managed A - 12 Inaccurate project estimates A - 06 Poor contract baseline A - 05 Failure to understand proposed solutions A - 02 Fixed Price for combined phases B - 02 Ineffective project startup

1 Unrealistic Deadlines 37%

2 Specification Changes from Clients or Management 10%

3 Lack of Specific Objectives 8%

4 Lack of Communication between Project Workers 4%

5 Lack of Labor Resources 4%

Estimates are linked to lifecycle phases and verified throughout the project’s life.

If estimates are always inaccurate we must re-do them to confirm our initial view.

Project Lifecycle. First/Early/Preliminary estimates

Detailed Estimate(baseline)

Re-Estimates ...........................

Final Estimate /Perfect hindsight Estimate.

Pre-Concept Concept PlanningDevelopment &

Unit TestUser Test Implementation

ROM – rough order of magnitude estimate: is a “ballpark” figure for getting an idea what something may require.

-50% < estimate < +75%

Budgetary estimate: is a more defined estimate at the beginning of a project or phase to setup a budget to acquire needed funding and resources.

-25% < estimate < +50%

Definitive estimate: is the most precise estimate whereby all requirements and risks have been well understood.

-5% < estimate < +10%

Examples of estimate ranges.

- Use a development method to list the individual work products or tasks in the Work Breakdown Structure (WBS).

- Take the individual task effort figures and sum to provide a total effort. Each task estimate is given by the area experts and/or the people who will do the task.

Bottom-Up Basic Method

Tasks are defined as the bottom level of the Work Breakdown Structure.

You can obtain a WBS from:

• Organization standard WBS• Generic project management tools:

MS Project, etc.• Estimating tools• From past projects.

Bottom up estimating cannot be carried out without a task list (e.g., a WBS).

Sum all effort at task level from the work

breakdown structure.

Next Phase

Task

Activity

Task

Activity

Task

Project

Phase Phase

Items required:

Define your process/methodology. (e.g., What WBS best defines your project?).

Refine the tasks to produce a detailed task list. What is needed for the follow-on phases?

The‘expert’assesses the effort for each task (or work product). The ‘expert’ is briefed on what effort is ‘in’ and what is ‘out’ by estimator. An

example could be that the estimate should not include integration testing. The project manager will ensure to include all the variables. Experts will work

with project manager to verify accuracy. Adjustments can be made for projected resource skill levels.

The project manager will sum individual task efforts to provide total effort. The project manager will use work distribution models (WDM) to extend the

estimate for all phases yet to be completed. The project manager will add the overhead efforts (e.g., Project Management,

Contingency, etc.)

Define the parameters.

Estimates from one phase can be extended to other phases using Work Distribution Models.

Phase Effort

Pre-Concept 5%

Concept 30%

Planning 15%

Develop & Unit Test 25%

User Test 20%

Implementation 5%

For different kinds of projects there are different

models.

Waterfall:

RAD: OO Technology Phase

Split of Total effort

Split of Technical effort

Definition / Analysis

30% Project Management 10% N/A

Design / Review 20% Analysis 20% 22%

Construct / Review

25% Design 20% 22%

Integration Test 10% Code & Unit Test 30% 34%

System Test 10% Testing (system, regression and user acceptance)

20% 22%

BETA (field) Test 5%

Expand the effort of one phase to the other phases.

Work Distribution Model (WDM): A generic or historical effort distribution by phase.

Suppose the estimate for the Concept Phase came to 120 days, using the Task by Task method:

Phase Effort Work Days

Pre-Concept 5% 20

Concept 30% 120

Planning 15% 60

Develop & Unit Test 25% 100

User Test 20% 80

Implementation 5% 20

Total Estimate 100% 400

Example: Total Project Estimate: 400 days + Project Support + Contingency

Work Distribution Models are available for project support efforts.

400 work days +In addition we must include nontechnical efforts:

Project Support Effort Additional Effort

Number of Additional Days

Project Management 10% 40 days

Project Administration 5% 20 days

Quality management 5% 20 days

Training 3% 12 days

Other 2% 8 days

Total Estimate 100 days

Total Project Estimate: 500 days + Contingency

This technique can also be used for the inclusion of contingency (aka, risk).

Probability reflected as a % likelihood to occur.

Impact reflected as a % addition to overall effort if it occurs.

Contingency / Risk Probability Impact Additional Effort (Probability)

Number of Additional Days

The requirements are unstable or liable to change

30% 30% 9%(30%*30%=9%)

45 days(500 days*9%=45 days)

The delivered system will contain significant errors

16% 15% 2.4% 12 days

The project will be lacking in resources

5% 10% .5% 2.5 days

Total Estimate: 59.5 days

Total Project Estimate: 559.5 days

A Bottom-up Estimate requires a WBS.

A WBS is required before a bottom up estimate can be developed.

First cut WBS can be obtained from experience, historical data, planning tool templates, estimating tools, etc.

Leads to a project plan/schedule.

Done at the beginning and then revised at the end of each completed phase.

Used to obtain estimates for later phases and overall project.

Should be an iterative process ending with a first (or revised) fully resourced project plan for the next phase of the project.

Use of historical metrics can enable task estimates to be obtained.

Estimate with all known project factors considered. (i.e., Scope,

Technology, Reuse, Resources, Contingency, Legal constraints, etc.).

Artifacts are resultant objects chosen to enable sizing.

Basic Method- Choose a sizing artifact(s). May vary from project to project.

Estimate the effort to produce each artifact type.- Use historical data, tools, etc.- May need to consider size and/or complexity.

Count the number of each artifact type to be produced. Multiply the effort by the count to provide an overall estimate.

- Often the estimate is based on design, build, or test for each artifact.

Convert the artifact count into 'real estimates’- Adjust against the project factors, work distribution models, PM, estimating

tools, historical data, etc.

Page 16 | April 2004

Typical artifacts can be anything that is countable and individually assessable for effort.

Typical Artifacts:

Number of screens required to be built Number of modules to be developed. Number of reports to be written Number of data tables to be defined. Number of data elements. etc. …

Others: Programs, Views, Queries, Forms, Users, Classes, Objects, Use Cases, Package Specific, Test Cases , Function Points ...

Required Artifact Attributes:

Available early in project life cycle. Quick and easy to count. Proportional to effort required to analyze, design, build and

implement.

The effort to build the chosen artifact is estimated and may be expressed as a variety of sizes or complexities.

Use of a matrix for artifact estimating. Develop a matrix for each type of artifact. Be objective in defining the complexity. Use historical data or tests to populate the matrix.

Effort per Artifact (i.e., Module)

Complexity

Size Simple Average Complex Very Complex

Small 3 hrs. 9 hrs. 15 hrs. 30 hrs.

Medium 8 hrs. 16 hrs. 32 hrs. 64 hrs.

Large 15 hrs. 30 hrs. 60 hrs. 120 hrs.

Very Large 20 hrs. 40 hrs. 80 hrs. 160 hrs.

Note: You could automate the estimating process by building tools (i.e., spreadsheets).

Artifact based estimates should consider all the variables which were discussed in bottoms-up estimating.

Make sure the effort per artifact figure is valid for your project’s environment.

The scope of the project should be covered by the artifact count.

You should also consider all the other known project factors.

If such estimates provide for only technical effort (design, build and unit test) then use other techniques (rules of thumb, or phase work breakdown) to complete the estimate.

These tools tend to be developed on site and not generic or standard.

Needs constant reviewing of tools to confirm the relationship between effort and chosen artifacts are still valid. Technological changes need to be constantly monitored for impact to existing methods.

Parameter estimates - this method enables historical or industry data to be used to provide estimates.

Use a standard analysis technique to size the application in the parameter chosen.

- Generally suitable for all project types- Best if it is technology independent.

Convert this size into real estimates using historical data, estimating tools, etc.

- Use work distribution models, PM or estimating tools, historical data, etc.

Typical sizing parameters: Lines of Code, Function Points, Business Function Units, etc.

• Common Parametric measures:• Lines of Code• Function Points• Logical Transactions / Data Entities/Entity References.

• Required Parametric Attributes:• Available early in project life cycle.• Quick and easy to count.• Proportional to effort required to analyze, design, build and

implement.• Choice may be dependent on the methods you have available

for converting the count to 'real estimates'.

• The Choice of Parameter can depend on the application.

Parametric estimates are

technology independent.

Other techniques which may be used to develop estimates when other methods are not be available.

Directly from historical data- Even if the actual size is not available comparisons with ‘old’

projects can be made.- e.g., Previous projects of this type, classification, size

have taken X. May be already existing in a repository. Using Rules of Thumb

- These can be developed from industry and local historical data and used where very little information is available.

Best endeavors of individuals.- Individuals with lots of experience are often very good at

making estimates.

Historical Data and Rules of Thumb can also be developed from the Artifacts.

Guess / Judgment / Experience BUT formal• The more people who provide input the better.• The best people to provide input are experienced Project Managers, Developers, ect.• A more formal version of this is X.

Experienced individuals can provide very accurate estimates. A formal process for estimate creation is advisable.

The PERT technique. • Ask expert(s) to: Estimate for worst case (w), Estimate for best case (b),

Estimate for most likely case (m).• Calculate the estimate(e) whereby e = (w + 4m + b) / 6.

The Delphi Method.PM ‘Experts’

nth ESTIMATE

Final ESTIMATE

BA

A combination of all the approaches and techniques described should be used.

The best estimate is usually the bottom up estimate.

Top down techniques should be used to validate bottom up estimates.

Where bottom up techniques are not possible use a variety of top down techniques.

Document assumptions made in drawing up the estimate.

Start to gather historical data to aid in future estimates.

The techniques from one method may be used in other methods.

Do not just give the answer the boss wants. Give the answer you can explain and stand behind.

Reviewing the Estimate.Checks to ensure estimate completeness.

① More than one method should be used to arrive at the final estimate.

② Confirm what is “IN” the estimate and what is “OUT”.

③ Is the quoted accuracy appropriate? Have the ranges been confirmed?

④ Do you own ROM estimate and then compare that with the given estimate. Trust but always verify.

A best practice is to standardize the estimating process as a reproducible set of tasks to develop the estimates for the projects.

Estimating Flow Chart

Finished

PLAN

DO

CHECK

Establish theEstimatingObjectives

Determine ProjectDetails Develop

EstimatingStrategy and Plan

GenerateEstimate

Validateand Finalizethe Estimate

ACT

Select Appropriate

Model

Top DownStart

Determine ProjectTeam Size

and Duration

Estimate the Technical

Details

Estimate ProjectManagement

Hours

Task-by-Task