CASE STUDIES

Week 6 - Chapter 8 - Managing Project Quality (PMBOK 8)

Contents Managing Project Quality - PMBOK 8 1 On Quality, Measurement, and Monitoring 2 Module Highlights, Commentary, and Lecture - Managing Project Quality - PMBOK 8 3 A few notes about quality 3 QM, QA, and QC 4

Week 6 - Managing Project Quality - PMBOK 8

Figure 1 Olympic judges and awards

Screen Beans Art © A Bit Better Corporation Used by permission under license

Managing Project Quality includes Project Quality Management (QM), Project Quality Assurance (QA), and Project Quality Control (QC).

Quality is obviously critical to a project (and to most other things in life). If the project comes in on time, on budget, meeting specs, but with such low quality that nobody wants to use it, then it is a failure. (I think we've all seen Web sites that must meet that definition. They're so hard to navigate, use, or find information that they're not worth using. Presumably, however, they met specs.) For this reason, many people would add quality as a 4th or 5th element of the triple constraint (cost, schedule, scope, and possibly risk).

"You can't control what you can't measure."

-- Tom DeMarco Controlling Software Projects: Management Measurement and Estimation

"Quality is free."

-- Philip Crosby Quality is Free: The Art of Making Quality Certain, 1980

"Quality is free, but only to those who are willing to pay heavily for it."

-- Tom DeMarco Peopleware: Productive Projects and Teams, 1987

"People under pressure don't work better: they just work faster."

-- Tom DeMarco Peopleware

"It's not what you don't know that kills you: It's what you know that ain't so."

-- Tom DeMarco after Will Rogers or Mark Twain (attribution unclear)

"You cannot inspect quality into a product."

-- Harold S. Dodge

"Testing shows the presence, not the absence, of bugs."

-- Edsger W. Dijkstra

Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.

-- William A. Foster

"If you don't have time to do it right, when will you have time to do it over?"

-- John Wooden

"Large programs are never more than 90% debugged. Never. No way."

-- Prof. Larry K. Flannagan, c.1971

"You can pay me now, or you can pay me later."

-- Fram oil filter commercial, c.1981

Note: Recognizing your heavy life load and not wanting you to duplicate your effort, these lectures do not repeat what is in the textbook, but add on, and occasionally emphasize, in order to give you everything we expect you to know about this topic. In order to comprehend the subject matter, it is necessary to read both the textbook selections and these lectures. Every effort has been made to give you a quality educational opportunity without wasting your time.

First of all, quality -- like security -- needs to be built in, engineered in from the beginning, in fact. It cannot be slapped on at the end. Some places try that for both quality and security, but it doesn't work.

Don't cut corners. If the project is worth doing at all, then it's worth doing right, i.e., with quality. If it isn't worth doing right, then we might as well not do it at all. If we don't do it with quality, nobody will be happy and we will damage our own reputation, too.

As I mentioned above, quality is critical to a project. If the project comes in on time, on budget, meeting specs, but with such low quality that nobody wants to use it, then it is a failure. I think we've all seen Web sites that must meet that definition. They're so hard to navigate, use, or find information that they're not worth using.

Project Quality has a lot to do with requirements. A common definition of Project Quality is, "the degree to which a set of inherent characteristics fulfill requirements." However, it goes beyond requirements (which are a project scope issue), and among other things also includes processes as well. Consider again that horrible Web site. While it's hard to navigate, use, or find information, it presumably met its stated requirements or they probably wouldn't have gone live with it. Also consider the problems that Toyota has been having recently. While their accelerators didn't fulfill their requirements, the underlying cause was that their processes, previously famous for quality, had gone wrong. Also consider Nordstrom's and (in the past) Sears. They are/were famous for their quality of service, which is primarily a process issue not a requirements issue. Finally, quality is a value; hopefully, a key organizational value. So quality goes far beyond requirements.

Ford Motor Co. used to say "quality is Job One." While we may wonder about automobile manufacturers' quality these days, it is a very valid point that quality -- like risk management -- is everybody's business. Nobody can pass the buck. Even delegating quality (and security) to someone else doesn't get us off the hook. Everyone is responsible.

Agree on quality up front and early. That is, the customer, stakeholders, developers, and PM must be in agreement on what quality is and how to recognize it, or there will be problems later on. It can be tough to reach an agreement, but it's worth the trouble to do so.

Quality is like IT security in that it must be designed-in rather than added-on later. Designing an IT system then trying to slap on some security at the end doesn't work well. Neither does trying to slap on some quality to a poorly-designed and -built system later on.

What's the difference between Quality Management (QM), Quality Assurance (QA), and Quality Control (QC)? They sound alike but they're not the same. The difference is … Well, … actually, I think I'll save that for a discussion question.

--------------------------