Project Management Institute

Measuring progress in software development

Taming the “second 90 percent” of the schedule takes attention to detail up front of the first 90 percent.

by Brad Kiewel, PMP

SOFTWARE DEVELOPMENT TENDS to suffer from the “Ninety Percent Syndrome”; that is, the first 90 percent of the project takes 90 percent of the schedule and the last 10 percent of the project takes the other 90 percent of the schedule. During our project—a major revision to a commercial software product, composed of new features and enhancements to existing features—we established several procedures using work breakdown structure and work packages that allowed us to more accurately measure progress during development and to predict schedule completion.

Work Breakdown Structure

As with any project, we started with the WBS. A work breakdown structure is a product-oriented family tree, composed of hardware, software, services, and data, that completely defines the project. The work breakdown structure provides a framework whereby:

All tasks to be performed can be identified and resources allocated to them.

img

Task duration can be estimated once resource levels have been allocated to the task.

All costs and resource allocations can be totaled to develop the overall project budget.

Task durations can be used in developing a working schedule for the project.

Performance can be measured against the cost, schedule, and resource allocations.

Responsibility can be assigned for each element.

We used the WBS to document the changes to the existing product. Once the WBS was complete, each developer generated work packages for the changes in their domain.

Work Package. The lowest level of each element in the WBS is a work package, which provides a detailed definition and scope of work at the task level. The work package defines the resources required and budget available for the task, the detailed plan and milestones for accomplishing the task, and a method for reporting progress to the project manager. The work package usually has a short time span schedule (40 to 100 hours), is limited to one performing department, and has defined completion criteria (The work package is complete when …).

The lowest level of each element in the WBS is a work package, a detailed definition and scope of work at the task level. The work package defines the resources required and budget available for the task, the detailed plan and milestones for accomplishing the task, and a method for reporting progress to the project manager. Using a spreadsheet program to generate the work packages allowed us to have a “living” picture of the state of the project and document “forgotten” tasks for better estimation on the next project

Exhibit 1. The lowest level of each element in the WBS is a work package, a detailed definition and scope of work at the task level. The work package defines the resources required and budget available for the task, the detailed plan and milestones for accomplishing the task, and a method for reporting progress to the project manager. Using a spreadsheet program to generate the work packages allowed us to have a “living” picture of the state of the project and document “forgotten” tasks for better estimation on the next project.

The work package serves three distinct roles in the planning and execution of the project:

During the estimation phase, the work package is the lowest level at which estimation occurs. The work package contains a description of, and all assumptions about, the activities required to complete the work package. This provides a baseline of how the estimate was developed, what was included in the estimate, and assumptions about how the work would be done.

During planning and execution, the work package is the negotiated commitment (or contract) between the project manager and the people who have the responsibility and authority for performing the work package. The work package defines the scope of work, the schedule for completing the package, completion criteria, and the method for reporting progress to the project manager. The work package should be updated to reflect the results and decisions of preceding tasks that affect the package. The work package documents changes in the work from when it was estimated until the work was performed.

The work package is the repository for the actual effort expended and time required to accomplish the task. Any unplanned activities performed to complete the work should be described. Documenting the actual time and effort provides a feedback mechanism for improving and refining the estimation process.

We used a spreadsheet program to generate the work packages (Exhibit 1). The developers entered a list of activities they would perform to complete the work package and estimated the number of hours for each activity. If a developer discovered additional activities during execution of the work package, the extra activities were added to the work package. This allowed us to have a “living” picture of the state of the project and documented “forgotten” tasks for better estimation on the next project.

Project Reporting. Each individual kept track of their hours in a work package. Work packages were updated at least weekly to show hours worked on tasks, new estimate of hours remaining for tasks in progress, and tasks completed. Again, we used the spreadsheet program to dynamically gather the data from the work packages and keep a week-by-week summary of the progress.

We used the following metrics:

Original Estimate (Hours)—Initial estimate of hours for all activities in the work package. Original estimates for each work package can be summed to create estimate for entire project.

Total Actual Hours—Running total of actual hours expended against any activity in a work package whether the activity is complete or not. Actual hours for each work package can be summed to create actual hours for entire project.

Estimate to Complete (ETC)—Estimated hours to complete work package based on developer's estimates for remaining activities. ETC for each work package can be summed to create ETC for entire project.

Estimate at Completion (EAC)—Estimated hours at completion of work package is the summation of the actual hours expended to date plus the estimate to complete remaining activities. EAC for each work package can be summed to create EAC for entire project.

Estimate at Completion = Actual Hours + Estimate to Complete

Work Package Percent Complete—Percent complete is the quotient of Actual Effort to Date divided by the Estimate at Completion (EAC).

Percent Complete = Actual Effort to Date / Estimate at Completion

Weighted Percent Complete—Summation of percent complete for group of work packages based on their contribution to Estimate at Completion.

Weighted Percent Complete = Σ ((Actual Effort to date for group) / Project Total)

Splat—Indication of how close the original estimate matches the current estimate. A splat of 1 is the goal. A splat greater than 1 means the effort is taking longer than estimated. A splat less than 1 means the effort is taking less time than estimated.

Splat = Estimate at Completion / Original Estimate

Equivalent Staff—Measure of how many staff resources are being applied against activities for the project.

Equivalent Staff = Actual hour for week / 30 hours

Actual Hours Weekly Delta—How many hours worked on a work package since the previous week's report. Use this data to see which work packages are being addressed.

EAC Weekly Delta—How much the EAC for a work package changed from the previous week's report. Use this data to flag any work packages where the EAC is not decreasing on a week-to-week basis.

We produced three separate reports using the data collected from the work packages. The first was a status chart showing project percent complete (Actual/EAC) compared to the baseline plan (Report 1; see Exhibit 2). The second report was a table showing a historical summary for each week since the project started (Report 2; see Exhibit 3). The third was a table summarizing the individual work packages for that week (Report 3; see Exhibit 4).

Data collected from the work packages was used to create three separate reports. The first was a status chart showing project percent complete (Actual/EAC) compared to the baseline plan

Exhibit 2. Data collected from the work packages was used to create three separate reports. The first was a status chart showing project percent complete (Actual/EAC) compared to the baseline plan.

img
The second report was a table showing a historical summary for each week since the project started. This report provided an overview of the progress

Exhibit 3. The second report was a table showing a historical summary for each week since the project started. This report provided an overview of the progress.

The third report was a table summarizing the individual work packages for that week. This provided a good graphical view of project status as well as an overview of each work package

Exhibit 4. The third report was a table summarizing the individual work packages for that week. This provided a good graphical view of project status as well as an overview of each work package.

Report 3 provided a good graphical view of the project status. We could do a quick linear extrapolation of the progress to estimate a completion date. Report 2 provided a historical view of the progress. Report 3 provided an overview of each work package. The last two columns, Actual Hours Weekly Delta and EAC Weekly Delta, provided a quick way to see if any work packages were in trouble. We would take a close look at any work package that had an increasing EAC.

An Interesting Side Effect

Executive management was very impressed with our ability to accurately measure project progress and address schedule problems much earlier in the development cycle. However, the executives cooled to the process once they discovered they couldn't impose unrealistic product development schedules. When the executives would set a date for a new release, the developer would develop the work packages to document the effort required. Most times, the work packages would show the release date to be highly “success oriented” and would require heroic efforts to meet. After several such occurrences, the executives stopped asking for the work packages and simply directed the developers to begin.

THE WORK BREAKDOWN STRUCTURE and work package methodology provided a good way to measure progress on the project. We were able to quickly react to problems and more effectively apply resources. The developers liked the structure since we were able to provide them help sooner. The process is built on core project management principles, so it should be applicable to any project situation. ■

Brad Kiewel, PMP, has over 18 years of experience in software development and project management. He can be reached at bkiewel@willinet.net.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network • January 1998

Advertisement

Advertisement

Related Content

Advertisement