Estimating Frequently Asked Questions
This is the beginning of a growing list of FAQs.
-
What is the difference between and estimate and accounting?
An estimate has uncertainty and is qualified by a set of assumptions. A well formed estimate is a range.
Feel free to submit your questions (or answers)
Make or Break: Why Accurate Cost Estimation Is Key
A recent article from executivebrief.com sent to me By Dr. Ricardo Valerdi of MIT discusses how the accuracy of the cost estimation process can make or break a project’s success.
“When it comes to controlling costs, it is a critical first step to make appropriate estimations at the outset of a project. Being able to control costs is largely a matter of adhering to established guidelines, oftentimes by learning from previous projects and reacting to current circumstances efficiently and effectively.”
It is amazing to me how simple this concept is, yet how many CEO’s don’t even know it is possible. Accurate estimates (of course with risk and uncertainty factored in) yield viable project plans which can then be successfully monitored and controlled. In fact the application of techniques such as earned value management, as powerful as they are, crumble when the baseline plan is unachievable.
Step Ten: Track Project throughout Development
Refining Estimates throughout Project
Estimating software size, cost, and schedule should be an ongoing process. Preliminary estimates may be required to bid a job or to initiate the development process, or you may need to conduct a cost-benefit or return-on-investment (ROI) analysis to evaluate a project’s feasibility.
Preliminary estimates are the hardest to develop and are the least accurate because of the incomplete nature of the information available and the other factors discussed.
You can improve the accuracy of a preliminary estimate by using the sizing methodology identified in Step 4 or by using two different estimation techniques and having your analysts normalize the differences. There will still be a significant risk in using the preliminary estimate to structure a project or to evaluate risk in the early stages of a project life cycle.
Once a project has started, you will need to complete more detailed estimates to accurately plan the project and throughout the conduct of the project you will need to monitor the actual effort and duration of tasks and/or phases against planned values to ensure you have the project under control.
Summary
Software cost estimation is a difficult process but a necessary part of a successful software development. You can help ensure useful results by adopting a process that is standardized and repeatable. Several of the steps we have discussed, particularly those that do not result directly in the production of the estimate (Steps 1, 6, and 7) are often deferred or, worse still, not performed at all, often for what appear to be good reasons such as a lack of adequate time or resources or a reluctance to face the need to devise a plan if a problem is detected. Sometimes you simply have more work than you can handle and such steps don’t seem absolutely necessary. Sometimes management is reluctant to take these steps, not because the resources are not available, but because managers do not want to really know what they may learn as a result of scoping their estimates, quantifying and analyzing risks, or validating their estimates. This can be a costly attitude, because in reality every shortcut results in dramatic increases in project risks.
Previous:
Step Nine: Document Estimate and Lessons Learned
Step Nine: Document Estimate and Lessons Learned
Each time you complete an estimate and again at the end of the software development, you should document the pertinent information that constitutes the estimate and record the lessons you learned. By doing so, you will have evidence that your process was valid and that you generated the estimate in good faith, and you will have actual results with which to calibrate your estimation models. Be sure to document any missing or incomplete information and the risks, issues, and problems that the process addressed and any complications that arose. Also document all the key decisions made during the conduct of the estimate and their results and the effects of the actions you took. Finally, describe and document the dynamics that occurred during the process, such as the interactions of your estimation team, the interfaces with your clients, and trade-offs you had to make to address issues identified during the process. Cost models, which are based on the actual costs of past projects, can be calibrated and their accuracy can be demonstrated by comparing the costs of your current estimates with both past project data and the actual costs of your completed project, thereby adjusting the model input parameters to improve future accuracy.
Step Eight: Generate A Project Plan
The process of generating a project plan includes taking the estimate and allocating the cost and schedule to a function and task-oriented work breakdown structure. Models such as SEER Client for Microsoft perform this function automatically. The eight major software development phases
are: (1) concept, (2) acquisition, (3) requirements, (4) design, (5) code and unit test, (6) integration, (7) acceptance, and (8) post deployment.
Determining Costs from Effort Estimates
At this point in the estimation process, you should have a reasonably accurate projection of your project’s size and required effort, that is, an estimate of the number of person-hours by component and a sum of these projections, and you can now begin to price the estimate. As software estimation models generally account only for costs related directly to development, you may need to translate the required effort to a cost and finalize the estimate by adding in essential nonlabor costs. You can do so by answering the following questions:
What types of individuals do I need and when do I need them?
Identify the specific personnel requirements by task area (direct software management, software systems engineering, design, programming, configuration management, quality assurance, etc.). Develop a strawman schedule from the work breakdown structure or a staffing plan such as the one produced by SEER-SEM.
How experienced do they have to be? Assign specific staff levels to the task requirements and identify the level of experience required to satisfy the task. Some of the automated cost models will identify the tasks and develop a task-based schedule, which will minimize but not eliminate all of the work required to produce the software development plan.
Step Seven: Estimate Validation and Review
Step Seven: Estimate Validation and Review
At this point in the process, your estimate should already be reasonably good-but it may not be as good as you think. It is important to verify your methods and your results in a step called validation, which is simply a systematic confirmation of the integrity of an estimate. By validating the estimate, you can be more confident that your data is sound, your methods are effective, your results are accurate, and your focus is properly directed.
It may be tempting to skip this review due to a lack of time, personnel or budget, and there is the unappealing possibility that a close examination may reveal faults in the logic of your process. Nevertheless, the costs involved in performing a proper validation will be dramatically less than the cost overruns that are likely to develop during a poorly managed software project.
There are many ways to validate an estimate. Both the process used to build the estimate and the estimate itself must be evaluated. Ideally, the validation should be performed by someone who was not involved in generating the estimate itself, who can view it objectively. The analyst validating an estimate should employ different methods, tools and separately collected data than were used in the estimate under review.
Step Five: Prepare Baseline Estimate
Budget and schedule are derived from estimates, so if an estimate is not accurate, the resulting schedules and budgets are likely to be inaccurate also. Given the importance of the estimation task, developers who want to improve their software estimation skills should understand and embrace some basic practices. First, trained, experienced, and skilled people should be assigned to size the software and prepare the estimates. Second, it is critically important that they be given the proper technology and tools. And third, the project manager must define and implement a mature, documented, and repeatable estimation process.
To prepare the baseline estimate there are various approaches that can be used, including guessing (which is not recommended), using existing productivity data exclusively, the bottom-up approach, expert judgment, and cost models.
Software Productivity Laws
These laws of software productivity help explain the dynamics of an engineering development project, and they illustrate some of the reasons that just using productivity to estimate is inadequate.
Law 1 - Smaller teams are more efficient. The smaller the team, the higher the productivity of each individual person.
Law 2 - Some schedule compression can be bought. Adding people to a project, to a point, decreases the time and increases the cost as larger teams work together.
Law 3 - Every project has a minimum time. There is an incremental person who consumes more energy than he or she produces. Team size beyond this point decreases productivity and increases time. (Law 3 is also known as Brooks’ law.)
Step One: Establish Estimate Scope and Purpose
Establish Estimate Scope and Purpose
Define and document expectations. When all participants understand the scope and purpose of the estimate, you’ll not only have a baseline against which to gauge the effect of future changes; you’ll also head off misunderstandings among the project group and clear up contradictory assumptions about what is expected.
Documenting the application specifications, including technical details, external dependencies and business requirements, will provide valuable input for estimating the resources required to complete the project. The more detailed the specs, the better. Only when these requirements are known and understood can you establish realistic development costs.
An estimate should be considered a living document; as data changes or new information becomes available, it must be documented and factored into the estimate in order to maintain the project’s integrity.
Previous:
Ten-Step Project Estimation Process Introduction
Coming Next:
Step Two: Establish Technical Baseline, Ground Rules, and Assumptions
Ten-step Project Estimation Process
Software Estimation Concepts
Many project managers and project management offices have unrealistic expectations about estimates. The definition of the verb estimate is to produce a statement of the approximate value of some quantity. Estimates are based upon incomplete, imperfect knowledge and assumptions about the future. For these reasons, many estimates of software costs tend to be too low due to omissions of important product functions and project activities. Most importantly, however, all estimates have uncertainty. There is no such thing as a precise, single-value estimate. Managers should always ask how large the uncertainty of an estimate is! A manager can use the size of this uncertainty in conjunction with other factors such as perceived risks, funding constraints, and business objectives to make decisions about a project.
How can projects address the uncertainty of poor estimates? How can the risks associated with initial estimates be identified, managed, and controlled? The answer is straightforward: by defining, establishing, planning, and applying a consistent, repeatable, and effective estimation process.
A software estimation process that is integrated with the software development process can help projects establish realistic and credible plans to implement the project requirements and satisfy commitments. It also can support other management activities by providing accurate and timely planning information. Realistic plans will also describe how the resources that are required to undertake the initiative in accordance with the schedule will be secured. The planning process, as critical as it is, is difficult and takes time to perform correctly. Managers often truncate the planning process by using “easily available” information that is often inadequate; by employing whoever has the time, even if those individuals are not qualified to perform the estimate; and by using only one estimation method to save time.
Successful software engineering requires the application of engineering principles guided by informed management. The principles must them-selves be rooted in sound theory. While it is tempting to search for miracles and panaceas, it is unlikely that they will appear. The best course of action is to stick to age-old engineering principles. There simply are no silver bullets.
Cost estimates are projections of required effort, time, and staffing levels. Because all estimates, particularly those made at the beginning of a project, are based on assumptions, they should be considered probabilistic. Cost estimates in particular should provide a range with an indication of accuracy, i.e., least, probable, and most, with the least and most values representing the upper and lower bounds of the projected cost.
Project Estimation Process
Ideally an estimate should be produced using the ten-step process.
During October we will cover each step on this blog.
Figure 1 Ten-step project estimation process
- Establish estimate scope
- Establish technical baseline, ground rules & assumptions
- Collect data
- Size software
- Prepare baseline estimates
- Quantify risks & risk analysis
- Review, verify, validate estimate
- Generate a project plan
- Document estimate & lessons learned
- Track project throughout development
10 Step Estimation Process Sample Checklist
10 Step Estimating Process Checklist
This should be tuned to the individual companies needs
10 Step Summary
|
Estimation Step |
|
|
1. Define Scope & Purpose |
|
|
2. Identify Technical Baseline and GR&A |
|
|
3. Collect Data |
|
|
4. Software Sizing (new and reused) |
|
|
5. Prepare Baseline Estimate |
|
|
6. Identify Risk items |
|
|
7. Estimate Validation and Review |
|
|
8. Build a Project Plan |
|
|
9. Document Estimate |
|
|
10. Track Project |
|
