Some programs start with just a few measures, which don’t provide much value to the participants. This might lead the participants to conclude that the metrics effort isn’t worthwhile so they terminate it prematurely. Another obstacle to getting adequate and timely data is the resistance many software people exhibit toward measurement. Participants who are more comfortable working undercover might drag their feet on collecting data. They might report only a few of the requested measures, report only data that makes them look good, or turn in their data long after its due date. If your metrics effort is having trouble getting off the launch pad because of some resisters, you may be a victim of this trap.

A metrics program has the potential to do actual damage if you are measuring too few dimensions of your work. People sometimes change their behavior in reaction to what is being measured, which can have unexpected and unfortunate side effects. This is the phenomenon known as dysfunctional measurement (see Trap #7: Using Metrics to Motivate, Rather Than to Understand) (Austin 1996).

As with Trap #2, the balanced set of metrics is critical to success. Measure several aspects of your product size and quality, work effort, and project status. You don’t need to start with all of these at once. Choose a small suite of key measures that will help you understand your group’s work better and begin collecting them right away. Software metrics are often a lagging indicator of what is going on. The later you start, the farther off-track your project might stray before you realize it. Avoid choosing metrics that might tempt program participants to optimize one aspect of their performance at the expense of others.