Planning For Quality

Planning For Quality

Here is a question: Which is of higher quality, an expensive luxury sedan or a cheap economy car? How does a finely tooled Swiss timepiece with a gold wristband compare with an all-plastic digital watch? If you chose the luxury sedan and the Swiss watch, you will have problems managing quality on your projects because you are confusing quality with rank.

Quality is an increasingly important part of project management. Some authorities claim that it is at least as important as the traditional three measures of project success: budget, schedule, and scope. But quality is one of the most misunderstood characteristics of a product because the commonplace usage of the word is vastly different from the professional use.

If you ask people what quality means, you will get a list of adjectives such as excellent, first-class, expensive, and distinctive. Accordingly, the luxury car and the Swiss watch clearly are of higher quality than the compact car and the digital watch. In the professional sense, however, quality means "conformance to specifications." If a product meets the requirements defined for it, it is a quality product. Otherwise, it is not. Therefore, a compact car that provides cheap, reliable transportation is a quality vehicle, and a luxury car that is always being serviced is not. As far as the watches are concerned, the one that keeps better time is of superior quality, regardless of its cost. It is true that the luxury car and the Swiss watch rank higher than their low-cost counterparts, but their quality depends solely on the degree to which each meets its requirements.

Conformance to specifications for information systems projects has two aspects: (1) The product arising from the project must conform to the requirements or specifications that were stated for it normally handled by managing scope and customer expectations; (2) errors should be kept to a minimum. It is this second aspect that quality management is intended to address. Briefly stated:

The purpose of quality management in information systems projects is to minimize errors.

The most familiar computer systems errors are programming bugs, but there are many others. Exhibit 4.8 lists some of the more common errors that can occur, along with their cost consequences to the project. Costs incurred reflect either increased labor or additional expenses. In this exhibit, the cost consequences represent the additional effort beyond what would be expected if there were no errors. For example, one of the cost consequences of programming bugs is unit-test and debugging time. True, all programs require effort for unit testing, but the presence of programming bugs increases that effort.

place. However, unless you can measure the number of bugs that occur after you intervene and compare that count to a baseline, you will never know the extent to which your efforts have worked. To tell you how successful you were, you need to know two things: the baseline error rate and the error rate after your intervention.

Exhibit 4.9 lists a set of cost consequences for different types of error. Each of these cost consequences, such as number of programming bugs, can be measured. However, in order to determine if your quality efforts are successful, you need a baseline for each measurement. It is not enough to know that a system contained seventeen bugs; whether that is good or bad depends upon the size of the system and the severity of the bug. While seventeen severe bugs in a small system may be unacceptable, the same number of minor bugs in a large complex system could be praiseworthy. Your measurement system, therefore, needs to include a baseline error rate. Exhibit 4.9 suggests measurements that could apply to each of the cost consequences listed in Exhibit 4.8. Your goal in managing quality is to reduce the value of each of these measurements.