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 Six: Quantify Risks and Risk Analysis
The best managers of software projects seem to have an uncanny ability to anticipate what can happen to their projects and devise just-in-time mitigation approaches to avoid the full impacts of the problems. In reality, this ability is simply the skillful application of well known risk management techniques to the well known problems of software management. Unfortunately, too many software managers are skilled in seeing potential risks and then ignoring them outright.
Before we explore the risk management process and how to apply it to the risks associated with sizing and estimation, it is important to understand what a risk is and that a risk, in itself, does not necessarily pose a threat to a software project if it is recognized and addressed before it becomes a problem.
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
Barriors to Adopting Estimation Technology & Applications
A reader requested I chime in on The biggest barriers I see to adopting estimation technologies and tools. So here goes the first draft.
- Not Invented Here: Some people think that their environment is so unique that it cant be estimated… or that estimation applications like SEER can’t handle their unique scenarios. I have never seen a case where this was true once the organization tried. Or sometimes an expert has their own spreadsheet and they don’t want to let go of that control.
- Don’t Want To Know: Sometimes the answers from estimation technology are longer or more costly than stakeholders want to hear. Read more
Code is Poetry?
As I was writing a BLOG entry I saw a new version of the blogging software was available. Being somewhat of a geek myself I went to look at the change list.. i wanted to see if some of the things that drive me crazy have been fixed. At the bottom of the page i saw the phrase “code is poetry” Having a background in software development this comment put a smile on my face. I have worked with all types of developers. Some say “if it is working it is good, don’t change it” While there is some truth to that… changing code often introduces new defects, there is certainly some risk as well. As code may be error prone or unmaintainable, or can be made to execute more quickly (such as the latest release of SEER which writes to the database an order of magnitude faster.) But should good code be changed just to make it read better? Using SEER for Software I can see a potential of 20 to 50% of development or more just to ensure we have made anything go wrong.
Yet re-factoring old systems can sometimes product great improvements in maintainability.
I bagan to think of the analogy of code to electronic circuitry. Is electronics poetry? I don’t think so. It is sound (hopefully) engineering. i think the same is true for software. Code is an engineering product, not poetry.
SEER for IT: The Making of a New Product and Lessons learned
Measurement certainly requires looking to the past to learn of the future. But there is a huge amount to be learned from the lessons learned themselves. Looking back on the SEER for IT development there are several lessons learned that go beyond just the measurements. Read more
Software Development Metrics At Galorath: Co-located Teams Are Still Most Efficient
Our Development Vice President, Karen McRitchie and myself had an interesting review of development productivity in our own organization. Very interesting, but no surprises.
She found that the most productive projects are those where the team is co-located. There is a productivity hit when the team is geographically disbursed. Of course SEER for Software estimates reflect this with their multiple site parameter. But some people, even within Galorath, attempt to deny this phenomenon. Read more
