ESTIMATING TECHNIQUES BY MICHAEL MILCH, PMP®. Estimating Definition Project Impact Bottom Up...
-
Upload
isiah-brimm -
Category
Documents
-
view
237 -
download
3
Transcript of ESTIMATING TECHNIQUES BY MICHAEL MILCH, PMP®. Estimating Definition Project Impact Bottom Up...
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