Estimating Techniques

1. Estimating Techniques By Michael Milch, PMP®

2. Agenda • Estimating • Definition • Project Impact • Bottom Up Estimating. • Top Down Estimating. • Artifacts • Parametric • Other • Reviewing the Estimate • Estimating Flow Chart

3. 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: • No estimate can be guaranteed to be wholly accurate. After all… it is an estimate! It helps to place the estimate within a range. • When doing an estimate, more than one approach should be used.

4. 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.

5. 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

6. Estimates are linked to lifecycle phases and verified throughout the project’s life. Project Lifecycle. First/Early/Preliminary estimates Final Estimate /Perfect hindsight Estimate. Detailed Estimate (baseline) Re-Estimates ........................... Development & Unit Test User Test Implementation Planning Pre-Concept Concept If estimates are always inaccurate we must re-do them to confirm our initial view.

7. Examples of estimate ranges. 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%

8. Bottom-Up Basic Method • 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. Tasks are defined as the bottom level of the Work Breakdown Structure. Project Sum all effort at task level from the work breakdown structure. Next Phase Phase Phase Activity Activity You can obtain a WBS from: • Organization standard WBS • Generic project management tools: MS Project, etc. • Estimating tools • From past projects. Task Task Task Bottom up estimating cannot be carried out without a task list (e.g., a WBS).

9. Define the parameters. • 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 estimateshould not include integration testing. • The project manager will ensure to include all thevariables. 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.)

10. Estimates from one phase can be extended to other phases using Work Distribution Models. Waterfall: For different kinds of projects there are different models. RAD:

11. Expand the effort of one phase to the other phases. Suppose the estimate for the Concept Phase came to120 days, using the Task by Task method: Example: Total Project Estimate: 400 days + Project Support + Contingency Work Distribution Model (WDM): A generic or historical effort distribution by phase.

12. Work Distribution Models are available for project support efforts. 400 work days + In addition we must include nontechnical efforts: Total Project Estimate: 500 days + Contingency

13. 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. Total Project Estimate: 559.5 days

14. 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.).

15. 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.

16. 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. Page 16 | April 2004

17. 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. Note: You could automate the estimating process by building tools (i.e., spreadsheets).

18. 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.

19. 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.

20. 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.

21. 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.

22. Experienced individuals can provide very accurate estimates. A formal process for estimate creation is advisable. • 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. The Delphi Method. PM BA ‘Experts’ nth ESTIMATE Final ESTIMATE • 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.

23. 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.

24. 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.

25. Estimating Flow Chart PLAN Start Top Down Establish the Estimating Objectives Select Appropriate Model Determine Project Details Develop Estimating Strategy and Plan DO Task-by-Task Generate Estimate Estimate the Technical Details Determine Project Team Size and Duration Estimate Project Management Hours CHECK ACT Validate and Finalize the Estimate Finished A best practice is to standardize the estimating process as a reproducible set of tasks to develop the estimates for the projects.