WHAT DO YOU WANT TO ACCOMPLISH WITH MEASUREMENT?

Since all measurement has a purpose, you should start off by deciding what you want to accomplish through measurement:

Do you want to show that your project team really is working at over 100 percent capacity?

Do you want to prove that the product is a quality product, maybe even of higher quality than might be expected given the lack of support you get from senior management and sales?

Do you want to use the data to help change the workload of some of your staff?

Do you want to be able (in some loose sense) to predict whether changes will cause more risk, effort, or cost?

Most likely, you are turning to measurement to help you do one or more of the following:

• Understand what is affecting your current performance.

• Baseline your performance.

• Address deficiencies and get better at what you do.

• Manage risks associated with changes in schedules, requirements, personnel allocations, etc.

• Improve your estimation capabilities.

The one aspect that’s missing from this list and the one you would do well not to forget is bringing visibility to your area. Business executives too often treat software development as a black-box component in their organization. They forget to give it the same attention they give more typical segments of operations like manufacturing, packaging, and shipping. Software development organizations are so used to being treated like some third-party order fulfillment service that they forget that their departments need the same level of attention and involvement from senior management that the operations departments enjoy.

As a result, your measures should help you address both the financial and the political aspects of software development. You’ll need the usual bottom-line measures such as “on time” and “at spec.” But you’ll also want to call attention to the operation of the department within the organization as a whole, showing it as a consumer of the work of some business units upstream in the total workflow, and as a supplier to other business units downstream in that workflow.

Of course, we don’t want our measures to be just demarcations, lines on some corporate ruler used to see if we measure up to the CFO’s or COO’s expectations. We also want our measures to be feedback loops. When we do measure up, we want our measurements to show us what we did right. When we don’t meet expectations, we want our measurements to show us why and where we fell short and what to do about it next time.