Chapter 7: Quantitative management

Overview

Imagine that you are the PO manager, and that you've just asked a project manager if he or she is going to meet a deadline set for next week. Which of the following answers will provide you with the best information in order to make a decision as to whether something needs to be done?

• "We are a little bit off, but we are going to make it. Don't worry."

• "By this time we had planned to execute 200 test cases of a total of 300, but we were only able to execute 180, so we are a little bit off. However, with 1 week left to go, I think we can recover. Don't worry."

I don't know about you, but to me, the first response would make me more concerned than I'd been before asking the question. The second response, on the other hand, not only provides the information needed to appreciate the current situation but it does so based on an agreed scale known to both the sender and the receiver of the message, which provides the basis for a more objective communication, less prone to errors and misunderstandings. Furthermore, we can manipulate the information received to create new knowledge, such as how long it takes on the average to run a test case, or to forecast a tentative date of completion from the progress so far.

Although a very important aspect of quantitative management, measuring alone is hardly enough. In order to make sense of what we are measuring we need to attach meaning to it. In his book Quality Software Management, Gerald Weinberg [1] gives the example of an unusual noise coming from the engine compartment of a car while it is being driven. Such information is accurate, timely, and objective but what does it indicate? Weinberg proposes three possibilities:

1. The driver doesn't hear the noise because he or she is distracted, listening to or thinking about other things.

2. The driver perceives the noise as ominous, but a mechanic would know that it is just the washer fluid vessel that needs to be tightened.

3. The driver perceives the noise as irrelevant, but a mechanic would know that the car is about to run out of oil, damaging the engine.

The driver and the mechanic may have the same information, but the mechanic, based on his knowledge of how engines work, will know what to do with it. He knows what meaning to attach to the noise. Without the meaning, a person can't know what the appropriate response should be.

Projects have a way of making noise. They produce a considerable amount of data, such as the number of hours spent on a task, the number of errors found during testing, the amount of time spent in rework activities, the amount of overtime, and the number of people that requested to be transferred out of the project. Such "noise" can give one insight into what is really going on. But just as in the case of the car, hearing the noise is not enough. To manage based on metrics, we need to supplement the measurements with models that allow us to understand how the project behaves as a system.

As shown in Figure 7.1, forecasting task outcomes and steering the project is just one of the ways we can utilize information collected through measurements. Other uses include employing historical data to estimate and plan new projects, correlating two sets of measurements to understand how processes interact with each other, and producing descriptive and inferential statistics to compare the capabilities of one organization with the capabilities of others for process improvement purposes.

Figure 7.1: Measurements and the multiple purposes they serve.

Although we mention some specific metrics and describe them, the purpose of this chapter is not to enumerate everything that could possibly be measured in a project, but to lay the groundwork necessary to establish a fact-based management PO.