Presentation on theme: "ESTIMATING TECHNIQUES BY MICHAEL MILCH, PMP®. Estimating Definition Project Impact Bottom Up Estimating. Top Down Estimating. Artifacts Parametric Other."— Presentation transcript:
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 1Unrealistic Deadlines37% 2Specification Changes from Clients or Management10% 3Lack of Specific Objectives8% 4Lack of Communication between Project Workers4% 5Lack of Labor Resources4%
Estimates are linked to lifecycle phases and verified throughout the projects 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 Planning Development & Unit Test User 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
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? Theexpertassesses 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. PhaseEffort Pre-Concept5% Concept30% Planning15% Develop & Unit Test25% User Test20% Implementation5% 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 Management10%N/A Design / Review20%Analysis20%22% Construct / Review 25%Design20%22% Integration Test10%Code & Unit Test30%34% System Test10%Testing (system, regression and user acceptance) 20%22% BETA (field) Test5%
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: PhaseEffortWork Days Pre-Concept5%20 Concept30%120 Planning15%60 Develop & Unit Test25%100 User Test20%80 Implementation5%20 Total Estimate100%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 EffortAdditional Effort Number of Additional Days Project Management10%40 days Project Administration5%20 days Quality management5%20 days Training3%12 days Other2%8 days Total Estimate100 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 ProbabilityImpactAdditional Effort (Probability) Number of Additional Days The requirements are unstable or liable to change 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 SizeSimpleAverageComplexVery Complex Small3 hrs.9 hrs.15 hrs.30 hrs. Medium8 hrs.16 hrs.32 hrs.64 hrs. Large15 hrs.30 hrs.60 hrs.120 hrs. Very Large20 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 projects 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.
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 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 the Estimating Objectives Determine Project Details Develop Estimating Strategy and Plan Generate Estimate Validate and Finalize the Estimate ACT Select Appropriate Model Top Down Start Determine Project Team Size and Duration Estimate the Technical Details Estimate Project Management Hours Task-by-Task