Completing the DefinitionBut what about features, customer appeal, value for money, exceeding expectations, and all that other complicated, multi-dimensional subjective stuff we have been told means quality? Though I contend that much of this is something other than product quality, there is an evident need for the product to meet general customer requirements. That must be addressed, perhaps by a reference to Deming's "fit for purpose" quality goal. Adding this to our draft view of quality leads to my proposal for a more useful and specific definition of quality that should provide more guidance to PMs than such as can be found in the PMBOK® Guide. Here is my proposed definition: "Product quality is the degree to which quality factors proven by analysis are incorporated into the product through the natural development and application of a project quality model, and thus the extent to which the product meets its purpose".
New project modelNow we are left with the need to explain the "project quality model". As this post is really a back-to-basics analysis, I am thinking that the best approach is to first re-establish a basic project model, one that captures the elements of a project under the control of the PM. If these elements do indeed represent the essence of a project, then the PM's job during project design is to deploy techniques and methods to ensure they carry the attributes of quality. What project model should we use? The problem is that the triple constraint model[2] is too simple, and the PMBOK and PRINCE2 models are too complex. What I suggest is a modest enhancement to the triple constraint that gives us a platform for the analysis of intrinsic project quality. The new project model substitutes Scope with Objectives, Deliverables, and Activities. Trade-offs are added explicitly, to keep the model in balance.
Does this represent the essence of projects? Well, a good test is to ask the analyst's three favorite questions: Why? What? and How? The generic answer from most experienced PMs would be something like: "The project must meet objectives through the development of deliverables created by the activity of the team." This statement clearly identifies the significance of objectives, deliverables, and activities. A more colloquial expression might be "doing the right thing and doing it right". If these are our project essentials, possessing a naturalness of belonging, then we can speculate that project quality is achieved when each element possesses the [required?] attributes of quality — and is complete and correct.
2. Editorial note: The "triple constraint model" is considered long since obsolete for the very reason that it does not recognize quality as a cost element similar to scope.
| 
Dispelling the Myths
