Scope versus Quality

One defines the fundamental “What” of a project, the other defines the “How Good”

The difference between scope and quality can be a little confusing for new project managers. But it shouldn’t have to be. In this post, I discuss the differences—and relationships—between these two fundamental elements of a project’s golden triangle.

Let’s Start With Some Definitions:

Scope and Quality are related—but they are, in fact, two distinctly different things. To help clarify, let’s start with some simple definitions:

• Product Scope: At the very heart of every project is its Scope. This is why Scope is located at the center of the iron triangle. Scope is the “what” that your project is tasked with delivering. Often called the “deliverable,” product scope is the key product, service, or result that you’re ultimately going to create/provide and hand over to your customer at the end of the project. The definition of a project always begins with defining its scope.

• Quality Requirements: Quality is a measure of “how good” the product scope will be when completed. I.e., quality requirements are essentially bounding constraints that are placed on the delivered scope. This is why quality surrounds scope (like Time and Cost) in the iron triangle. Typically, quality requirements fall in categories like form, fit, functional, and performance specifications. These are requirements to which the scope and its constituent pieces must be constructed.

A common source of confusion is determining where scope ends and quality begins. Some engineering project managers treat Quality as a subset of Scope. Others act as if they are essentially the same thing. While both of these approaches can be made (awkwardly) to work, I prefer the traditional formal approach of considering the two as separate, but related, elements of the golden triangle of project management.

An Example of the Difference Between Scope & Quality:

To help better understand the difference between Scope and Quality, let’s image that you’re tasked with designing and constructing a new bridge across a body of water. The scope of work includes the bridge itself, its foundations, and perhaps the on- and off-ramps that connect the bridge to the adjoining roadways on either side. 

Quality requirements for the bridge would include specifications that can be tested and verified. These might include the load capacity of the bridge, what color it is to be painted, what its design lifespan is, and so on.

Two vastly looking bridges can have nearly identical scope but radically different quality requirements. For instance, the scope of a project to construct the Golden Gate Bridge is relatively similar to that of a simple covered wooden bridge across a creek. The quality requirements, however, will be significantly different.

Some Simple Tests:

A simple test to determine if something is Scope or Quality is this: Ask yourself whether the thing in question belongs in a work breakdown structure (WBS) or not. Is it a product, service, or result? If so, it does belong in the WBS. If it’s not, it doesn’t.

For example, if our project is to construct a house, things like the plans, foundations, walls, roof, flooring, and plumbing would naturally be included in the WBS. Conversely, requirements such as the building size (e.g., 3000 square-feet), type of flooring (e.g., marble), and the final color of the building (e.g., green with white trim) do not make sense to include as individual elements of a WBS; these are clearly Quality requirements, not Scope. 

Another simple test is to consider Scope to be things that can best be described by nouns. For example: bridge structure, foundations, on-ramp, off-ramp, toll-collection system, and so on. In contrast, Quality elements are things that are best described by adjectives and adjectival statements or numbers, such as: Orange color, 100-year lifespan, 110,000 cars/day capacity, etc.

The Bottom Line:

Scope and Quality are two strongly related, but still quite different, iron triangle elements that must be managed on a project. Understanding the difference is the first step toward planning the management of each on a new project.