Presentation is loading. Please wait.

Presentation is loading. Please wait.

Estimating Techniques

Similar presentations

Presentation on theme: "Estimating Techniques"— Presentation transcript:

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. Estimates are undertaken for a myriad of reasons: Organizations and businesses must be ale to provide the clients with proposed schedules and costs. Businesses must be able to obtain accurate estimates for itself, especially if fixed price contracting is to be considered. An SEI CMM(I) level 2 organization must have verifiable estimating processes in place to enable the required “Process Improvement” cycle. Customers need a cost estimate for budgeting purposes even when the requirements are not fully outlined. Project Managers need to plan resource needs and timescales for projects even when functionality and architecture are not fully defined. Estimates CAN be done done, but the accuracy will be suspect.

4 estimating accuracy increases through the project lifecycle.
As a project progresses through its life cycle… the information becomes better defined. Therefore, estimates will become increasing more accurate. 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) 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 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 Development & Unit Test
Estimates are linked to lifecycle phases and verified throughout the project’s life. Project Lifecycle. First/Early/Preliminary estimates Detailed Estimate (baseline) Final Estimate /Perfect hindsight Estimate. Re-Estimates The estimates should be reviewed after the completion of each phase. If adjustments are required then the estimate should be redone and communicated. Any risk mitigation then take place to insure the project’s success. Pre-Concept Concept Planning Development & Unit Test User Test Implementation 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% To give just an estimate, which by definition is not 100% precise, does not tell the full story. Make sure you give a range that you thing is reasonable for the information you have at hand. 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. Next Phase Task Activity Project Phase Sum all effort at task level from 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).

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

10 For different kinds of projects there are different models.
Estimates from one phase can be extended to other phases using Work Distribution Models. Waterfall: Phase Effort Pre-Concept 5% Concept 30% Planning 15% Develop & Unit Test 25% User Test 20% Implementation For different kinds of projects there are different models. OO Technology Phase Split of Total effort Split of Technical effort Definition / Analysis 30% Project Management 10% N/A Design / Review 20% Analysis 22% Construct / Review 25% Design Integration Test Code & Unit Test 34% System Test Testing (system, regression and user acceptance) BETA (field) Test 5% RAD:

11 Expand the effort of one phase to the other phases.
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 Total Estimate 100% 400 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: Project Support Effort Additional Effort Number of Additional Days Project Management 10% 40 days Project Administration 5% 20 days Quality management Training 3% 12 days Other 2% 8 days Total Estimate 100 days Total Project Estimate: 500 days + Contingency

13 Additional Effort (Probability) Number of Additional Days
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% 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: 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. Often artifacts may have different complexity levels. Effort figures should be assumed for each complexity level.

16 Required Artifact Attributes:
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. An artifact is something which provides an indicator of size/effort required depending on how many artifacts need to be produced. The number of artifacts should be proportional to effort required. Page 16 | April 2004

17 Effort per Artifact (i.e., Module)
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 60 hrs. 120 hrs. Very Large 20 hrs. 40 hrs. 80 hrs. 160 hrs. e.g., Types of Project, Enhancements, Custom application development versus an application package. Ensure Objective Complexity by suggesting a weighting complexity factor for: Problem Logic, Code, Data Access, Documentation, File reference complexity... etc. When determining effort figures attempt to break down into stages (i.e., design, build, test, install, etc.). This enables tracking against actuals to indicate where any adjustments are required. 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. The initial decision on effort per Artefact will determine if it is 'only' technical effort.

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. This is typically a software package used to estimate a project by asking questions about the project and then coming up with an estimate. Many of these same packages also list the project’s risks.

20 Typical sizing parameters: Lines of Code, Function Points, Business Function Units, etc.
Parametric estimates are technology independent. 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.

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
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 ‘Experts’ nth ESTIMATE Final ESTIMATE BA 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. Use as many estimating techniques as possible given the information, and time you have. Be as accurate as you can. Too high… you lose, too low… you may have to make it happen. Please remember that YOU ARE SETTING EXPECTATIONS!

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. (1) Look for a Top Down and Bottom up. If it is an early estimate look for 2 top down methods, examples{ sizing along with historical data + use or expert input via a formal process (i.e., Delphi). Look for the use of Estimating tools. Look for the use of a historical repository of projects in the estimate creation. (2) Look for inclusion of : Effort for all appropriate phases/tasks. Use existing models/tools to compare with a ‘typical’ task/phase list. Test effort is often under estimated Effort associated with indirect project tasks (i.e., overhead effort). PM effort, Code/ QA review effort, Project Office effort, metrics support effort. (3) If the accuracy of the estimate is quoted at a higher level than the current lifecycle phase would suggest then confirm how this accuracy has been achieved. (4) You are your own best judge of what is correct. Trust but verify.

25 Select Appropriate Model
Estimating Flow Chart Finished PLAN DO CHECK Establish the Estimating Objectives Determine Project Details Develop 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 Estimate Project Management Hours Task-by-Task Just for fun! A best practice is to standardize the estimating process as a reproducible set of tasks to develop the estimates for the projects.

Download ppt "Estimating Techniques"

Similar presentations

Ads by Google