NEWS

In the grand scheme of project priorities, quality ranks high. Once we get past the iron triangle of scope, cost and schedule as the priorities that defined project success, quality is right there as a fourth horseman, framing the limits of whatever project apocalypse we happen to be responsible for at the time.

On the face of it, that is a hard concept to argue, at least theoretically. We want to do quality work. We want our results to be seen as being quality, as well. We do not want to be judged as not having met the mark as far as quality goes.

The challenge is, what does that actually mean? And how do we test for it? How can we satisfy for ourselves—and demonstrate to others—that we have delivered on expectations in terms of quality? That is a conceptually loaded proposition.

Where this problem starts, is how we are taught—and tested—on quality management principles. For anyone certified in or around quality, you will have been drilled on the fact that there are seven tools of quality assurance, and seven tools of quality control. More specifically, you should be quite confident in the premise that quality assurance is about prevention, and quality control is about inspection. And that does not even begin to wade into the differences about quality versus grade.

Let’s go back to the basic principles. The fundamental first principles. First, “What does quality mean?” Take a moment to research it, you find that there are a variety of definitions and interpretations. “Quality” can refer to a nature, property, role, grade, rank or characteristic. Quality is a flexible word, partly by design, because we use it in a variety of circumstances.

When we think about what quality means in a project management context, though, the closest that we come up with is “grade.” In other words, comparing the inherent characteristics and exploring the relative degree of fit and finish that is delivered. If we are really biased, quality means “better.” It is the interpretation that says one brand is better than another.

The problem is that this is specifically and precisely the opposite of what some of us are taught. The whole “quality versus grade” debate deliberately tries to place the “fit and finish” dimension as being separate from and having nothing to do with quality.

Where did our current interpretation of “quality” come from, if it is not the definition that we find in the dictionary?

Starting with the “quality versus grade” debate, “grade” is supposed to be about fit, finish and finesse; it is stated to answer the question, “How refined is the thing that has been produced, and to what degree is it better?” Quality, on the other hand, is supposed to focus on the degree to which the result actually meets requirements. And this is where much of how we think about quality goes very sideways.

“Quality” as “conformance to requirements” is a relatively new concept. Its origins derive from the work of Philip Crosby, and is defined and articulated in his book Quality is Free. In particular, it derives from a creative interpretation of quality as meaning “zero defects,” which is where conformance to requirements got introduced to the whole conversation.

This interpretation of quality in turn has its roots in quality control, and the idea that improving quality should result in reductions of rejection, rework, waste and scrap. Crosby, in seeking to shift the focus to prevention rather than inspection, took an entirely general word and gave it a different—and much more specific—meaning. In other words, our current understanding of “quality” is pretty much the result of a re-branding exercise.

If we go back to the essence of what Crosby was talking about, though, much of project management is in fact all about quality management. The idea that “Quality is Free” (the title of his very popular but not always fully understood book) is not that quality has no cost. It’s more appropriately framed as a realization that investing in quality up front results in significantly less costs being incurred as a result of repair, rework, redundancy and scrap. Ensuring quality is not about plowing through and hoping for the best. It is about getting it right the first time, and not having to go back and fix what was wrong.

The challenge is that getting it right the first time takes work. It requires preparation, planning, follow-up and verification. It requires ensuring that the requirements that we start with are correct, that the resulting design is reasonable and that what gets built and implemented follows through on expectations. It also requires ensuring that we appropriately prepared people for the results that were to come, and then used the results in the manner and for the purpose that was originally intended.

What that means is that what is “right”—what represents quality—depends. We need to understand requirements, avoid defects, ensure fit for purpose, assess the delivery of value, evaluate usability and relevance, and determine actual application and use of what our projects produce. Moreover, what is important on each of these dimensions will vary depending on the particular project we are taking on. While each can be relevant, what each aspect represents—and how it is assessed—will be different from project to project.

The reality is that the tools of quality assurance and quality control are all about operational processes and practices. Projects by their nature are unique and varied. There are few consistencies and predictable dimensions that lend themselves to control charts or any of the other tools of quality management.

What we need to focus on is the particular requirements of each specific project. For example, a recent project I was involved with emphasized the automation of a process that had historically been manual, ad hoc and inconsistent across the affected organization. What “quality” represented was the degree to which cases were managed in the new environment. It involved assessing whether staff accepted and worked with the new solution, and whether the organization had a full and complete appreciation of their workload and commitments to clients. None of the traditional quality control or quality assurance tools could help in answering those questions.

Much of what mattered in this project had little to do with the solution that got created. More important was what people actually did with that solution; the degree to which they adopted and embraced the results, and whether they used them for the purpose that was intended. That places a different emphasis on the project, and identifies a different dimension of the project as being important. Some projects are about prevention; they care about ensuring that results matter, avoiding the cost of repair and rework and ensuring the sustainability and value of what is delivered.

Other projects, though, place their emphasis on inspection. They simply try to catch errors as they happen. When time is of the essence, cost is an issue, solutions are stop-gap measures or when progress simply needs to happen now, inspection is going to be what matters. Any time you encounter a situation where the imperative is “Get it done; we’ll fix any errors afterwards,” getting it right the first time is not a priority. Implicitly, that means that there is an allowance and acceptance of failure and rework. The challenge is that this acknowledgement needs to be explicit.

Once we know what is most important for our project, we can figure out what to actually measure. Much of that will in turn be dependent upon our appetite and tolerance for risk. How much risk we are prepared to take on in the project—and how much risk we are prepared to accept in the results—will have a significant influence on how we approach and manage the project. The less risk we accept—and the more risk that we try to mitigate, transfer or avoid—the more work we need to do and the higher costs we will take on.

Quality is an essential dimension of any project. Delivering quality is fundamental to our success as project managers. The problem is that how we think about quality—and the tools we use to manage it—are different than what we get taught.

What defines quality on any given project depends. How we measure quality depends as well. There is no one right way to assess quality, and what matters most for each project is what ultimately determines what we need to assess, and what we need to focus on. Quality does matter, but what it depends on comes back to a fundamental assessment of what matters most, and what a good solution for that particular project actually looks like.

Let’s discuss how we can partner to improve quality for your organization. Call 615-953-1907 or 574-232-5400.

Mullay, Mark. (2019). “Quality Doesn’t Work the Way You Think it Does”. Retrieved from https://www.projectmanagement.com/articles/552289/Quality-Doesn-t-Work-the-Way-You-Think-It-Does.