Introduction | Never, Never, Never Give Up 
Dispelling the Myths | Completing the Definition | The Takeaway

Dispelling the Myths

To help get on top of this, it is very important to understand that PMs are actually faced with two distinct quality conversations. The first is the quality of the product; second, the quality of the project. The myth of today's thinking on quality is that project quality, currently interpreted as the add-on implementation of QA/QC processes at the project level, and expensive Six Sigma or ISO9000 at the corporate level, will automatically lead to the desired product quality.

I call this the faith-based approach to quality. A reliance entirely on process presumes that the processes are correct, and then supports that presumption by deploying techniques and methods to detect deviations. This approach to quality is supportive, and not inherent in the development of the product. Support is important; I am not saying dispense with your QC procedures, but they only cut-in when the product is already built. That's a bit late, isn't it?

A fresh view of quality

Let's start with noting the ideal attributes all PMs would like to see in a quality system. I think the list would include intrinsic, observable, immediate, controllable, scalable, and inexpensive.

Intrinsic needs more explanation. Intrinsic product quality means that the product possesses discernable and tangible quality factors that ensure defined objectives are achieved. Intrinsic project quality requires a model to support tasks and project attributes that demonstrate essentiality and a naturalness of belonging, and are designed to create a product that includes the specified quality factors. Quality is not a sprinkle of fairy dust.

So, as a draft summary, product quality is the degree to which quality factors that serve objectives are incorporated into the product through the application of a project quality model.

Phew! I wish I could have put that simpler. A partial analogy suggests we are using stepping stones to cross the river and not relying on the lifesaver to haul us to the bank when we fall in.

An example

As a simple example of how quality factors are developed from subjective needs following an intrinsic quality model, let's assume the client stated that he wanted a "robust" system. Discussion then established reliability as a quality objective. Using one of the techniques described in Commercial Project Management — A Guide for Selling and Delivering Professional Service[1], we worked with the client to quantify this objective in terms of Mean Time Between Failure. Experts from the project team are now needed to establish the quality factors that will achieve this objective. One factor, for example, might be the need for specific critical components to be redundant.

Project quality requires the project quality model be interrogated and the results assessed to ensure product quality is coming into being. The requirements, design, and implementation phases are monitored to ensure the progressive development of our component redundancy factor, and indeed all other factors. The feedback is immediate — no waiting for the test phase. Changes are naturally controllable through the normal change control system. And there are no out-of-the-ordinary expenses being added to existing project costs.

Never, Never, Never Give Up

Completing the Definition

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page