One of the most difficult tasks for a project manager is creating a baseline that will be used to manage a project's development effort. Even with a correct estimate of effort and time, it's easy to forget tasks, incorrectly allocate effort among tasks or fail to allot enough resources for maintenance. Software estimating is a science that can be learned; it is possible to accurately and consistently estimate development costs and schedules for a wide range of projects, then quickly create a project plan. These articles have provided you the tools you need to understand step-by-step approaches to estimating the cost and schedule for your projects.
In the first article, "Estimating Software Costs" (Project & Process Management, Oct. 2000), I covered the various methods of estimating the size of a program (called program volume). I discussed the traditional measures of Lines of Code and Function Points, in addition to introducing other approaches, and, finally, I revealed how to prepare a preliminary, unadjusted estimate using that infor-mation. In "Project Cost Adjustments" (Project & Process Management, Nov. 2000), I reviewed the concept of project cost adjustments for variations in the project environment and illustrated how to create an accurate estimate of the time and cost required to develop a new application. "Calculating for Reuse" (Project & Process Management, Dec. 2000) explained how to quantify the impact of software reuse and commercial components and libraries on your estimate. Finally, this article describes how you can use your new insight into projectcost and schedule to create a complete project plan
The Work Breakdown Structure
The most fundamental building block of a project plan is the work breakdown structure (WBS). The WBS contains a list of tasks to be accomplished, and you can implement a template WBS in a spreadsheet as a list of task names, task percentages of effort and task descriptions. A simple WBS template applicable for many e-commerce jobs is recreated in Table 1.
Once you've determined the correct total effort for the job using the approach and information described in the first three articles in this series, you can use the percent of effort to quickly and easily allocate that effort among all of the tasks in your WBS.
The Deliverable Plan
On most projects, you will be required to create technical documentation.
Typically, this facilitates communication during development, assists in maintenance and provides milestones for payment.
The first step is to create another template, this time of document titles and descriptions. Templates of documentation are often referred to as standards; however, we can go beyond this initial step. It's valuable to include an estimate of the page count for each document in your project plan. This information helps set client expectations, defines the document scope for the developers who will write the documentation and acts as an estimate of review time.
I've found that the correct number of pages of documentation can be predicted using the staff months of development effort as the input. This is accomplished using the following formula:
Pages = A * B (Person MonthsC)
To apply this formula, you raise the person months of effort to a variable (C), multiply the results times another variable (B), then add a third variable (A).
Table 2 contains a sample deliv-erable planning standard applicable for many e-commerce development projects.
Using the standard, illustrated in Table 2, let's calculate the estimated page count for Software Design Description (SDD) on a 50 person month of effort project.
Begin by noticing that the values for A, B and C are 0.00, 8.00 and 0.91 respectively. The calculation is as follows:
Pages = A + B (EffortC) = 0 + 8 (500.91) = 8 * 35 = 280 pages
Estimating Maintenance Effort
It's often necessary to estimate maintenance effort as part of your planning process. You may need to plan for an adequate maintenance staff, or you may need to provide a warranty on the software. Both tasks require you to estimate the effort required to provide these services.
First and foremost, you must ensure that you share a common understanding of maintenance work with your customer. At the CostXpert Group, we divide maintenance activities into three categories: corrective, adaptive and perfective. Standard bug fixes are considered corrective maintenance, while adaptive fixes involve modifications to the software required by such changes in the operating environment as database or operating system upgrades, compiler version changes and so on. Perfective maintenance is the most complex, in that it involves changing the code to allow the software to meet the same requirement but in a significantly more acceptable manner. The largest example of perfective maintenance is modifications of the code to improve performance in trouble spots. Note that not all changes to the code to add new functionality are considered maintenance, nor are any changes that are based strictly on user preference.
Figure 1. Distribution of Maintenance Effort
|
Figure 1 shows the approximate distribution of maintenance effort based on one study by Capers Jones (see Estimating Software Costs, McGraw Hill 1998). Table 3 also illustrates the proper categorization of each maintenance activity based on the approach detailed in this series.
I've found that steady state maintenance annual effort is proportionate to development effort (this conclusion was initially proposed by Barry Boehm, then confirmed by numerous researchers). The range varies between 3 and 20 percent of development effort. The vast majority of projects fall in the more narrow range of 12 to 17 percent of original effort.
For example, suppose you have a project that requires 50 person months of development effort. You estimate that the maintenance effort will be 15 percent. The annual budget for maintenance then needs to be 50 * .15, or 7.5 person months of effort.
I qualified this statement by saying "the steady state maintenance." At the CostXpert Group, we've found that it takes four years of maintenance following delivery to reach the steady state for a typical system. During this period, the maintenance effort will be greater than the steady state effort. The optimum maintenance effort actually drops off exponentially from a value roughly twice the steady state value immediately following delivery to the steady state value at the start of the fourth year. During this time, the additional effort is spent on corrective and perfective maintenance.
This concludes this series, which has covered all aspects of developing a software project baseline. Though everyone has a favorite theory as to why software failures occur, my experience and work while with the Mitre Corporation, the Cost Xpert Group and Booz, Allen & Hamilton has taught me that more projects are doomed by poor cost and schedule estimates than by technical, political or team problems. Capers Jones's extensive research, found in his book Estimating Software Costs, makes a similar claim. It's no surprise, therefore, that so few companies and individuals understand that software estimating is not just an art, but a science that can be learned.