"If you don't measure, there is no real way of determining whether you are improving. And if you're not improving, you're lost."

-- Roger S. Pressman

Use Metrics to Manage
 
All world-class software organizations visited by SPMN have an extensive metrics program. These metrics programs provide early indicators of evolving problems on ongoing projects and measure the effectiveness of management and technical practices for improving the bottom line.

A metrics program is a powerful ally in the fight to bring software projects under control. However, to be effective, a metrics program must do more than collect data. It must convert the data to information through analysis and use this information to steer the program to success. The value from a metrics program comes from the actions taken as a result of metrics analysis. Collecting metrics solely for the sake of collecting metrics is not a best practice and is, in fact, counterproductive.

Almost all useful software metrics can be collected at very little additional cost as part of implementing some best management or technical practice. When establishing a metrics program it is imperative that the data collection processes be integrated into the software development process. Often it is better to use data that is collected as a natural part of doing business, rather than installing onerous data collection processes that strain resources.

Since a large volume of data will often be collected, it is important that criteria be established when further investigation is warranted. These criteria are called "triggers". When values fall outside predetermined ranges, predefined actions should be initiated to focus attention on the problem and correct it. Another name for a trigger is a threshold value or a boundary value as used in statistical process control. These values all share the same conceptual foundation-analyze a situation to determine what variance in a value is acceptable, establish some set point which will cause specific attention to be focused on the value and the conditions causing it to fall outside of it's normal range. In a software project these threshold values would be established early in the program, when there is less pressure and "cooler heads" often prevail. It is advisable to actually use several trigger points, each keyed to different levels of attention. For example for a small variance, increased attention might mean increased reporting frequency. At a larger variance, possibly an in depth analysis to determine the cause of the problem might be initiated. At a third, higher, level the action might be reporting the problem to the user to get them involved in solving the problem.

The important feature here is not the number of levels or the specific action taken. Rather it is an objectively thought out, practical plan for applying increased focus on problems before they become serious concerns.

Another key feature of this practice the integral use of metrics as a part of program management. Metrics that are collected should be the basis for program decisions. If not, then the wrong metrics are being collected

top

---