Quality Perspectives in Project Management

In Managing for Quality and Performance Excellence, Evans and Lindsay point to 5 distinct perspectives when defining quality. They are transcendent, product-based, user-based, value-based, and manufacturing-based. The authors discuss the topic in terms of defining quality within organizations and products. I see parallels to defining quality when running projects.

Transcendent Quality

This perspective makes a judgment as to quality in comparison to a “standard of excellence”. This is a highly qualitative measure of quality, and is normally a function of all aspects influencing the perception of quality combined. On projects, this is your complete package, and could be judged by whether or not sponsors want you to manage their projects, customers ask for you by name, or team members love to work with you on your projects.

Product-Based Quality

Are the details taken care of? In manufacturing, product-based quality could be the thread count in textiles, or well things fit together. In a project, I interpret this perspective as looking at:

(1) Did the project manager do a great job of managing the details (communications, risk planning, resource planning, etc.) and

(2) Did all the solutions satisfy the requirements fully, or did some of the solutions only solve the problem 80%?

User-Based Quality

The customer is always right. Or at least from this perspective, quality is based on whether or not the customer got what they wanted. Suppose the exact same IT solution is implemented for two groups. For group A, this is the perfect solution for their needs and so it represents high quality. Group B is impacted by limitations that don’t matter to group A, and so they perceive this as a low quality solution.

Additionally, this relates to how well the requirements are written and implemented. Do they truly address the customer needs? Poorly written requirements can be executed on perfectly and still represent a poor quality job from the user-based perspective. This would happen if the requirements were poor to begin with and did not accurately reflect the customer needs.

In short, the user-based perspective all comes down to the accuracy and precision of requirements, and how well they are executed.

Value-Based Quality

Many times people jump towards a custom-built or proprietary solution to a problem when there are commercially available alternatives that would meet the same needs for much less cost. Project A and Project B solve the same problem and have comparable value added when finished, but Project B costs twice as much. Project A has twice the level of quality from this perspective.

This could also play into resource allocation. When people and tools are used in the right place at the right times, they work more efficiently and cost less than disorganized, adhoc projects. Whether it’s the solution or resources involved, this perspective is all about return on investment.

Manufacturing-Based Quality (or Specifications-Based Quality)

In business, this is defined as the level of conformance to specifications. A tolerance specification of .236cm +- .003cm is a standard of quality. In projects, I see this as conforming to the original scope and plan. Scope creep reflects poor quality in this regard, and so does being over (or under) budget or time constraints set forth in the beginning. EVM practitioners and project controllers may be able to relate with this very well. If you stick to your original plan, then you’ve got high quality on your project from this perspective.

Another angle on this might be how closely the actual solution matches up to the requirements. Although the User-Based perspective speaks to requirements also, it is geared more towards what the stakeholders actually want. This perspective assumes that if the stakeholders signed off on their requirements, and you provided solutions that address those requirements, you have high quality. This could result from taking a pre-conceived solution from a customer and running with their requirements, without worrying about what business problem you are actually trying to solve, and if there is a better way. In that case you could end up with poor user-based quality, but high specifications-based quality.

I'm looking forward to delving into the rest of this book. So far it is very promising and I believe it will provide many insights into how to create and manage quality projects.