Defining and measuring project quality

Using a standardized methodology to define project quality ensures deliverables fit customer specifications and receive high customer satisfaction when managing projects.

By Jay Steinman May 5, 2017

Using a standardized methodology to define project quality ensures deliverables are fit for their intended purpose with high customer satisfaction.

Quality is often described in vague terms that are difficult, if not impossible, to make quantitative measurements. Quality is apparent to the customer, especially when lacking, but what exactly is quality? Quality may have different meanings to various project stakeholders, and it’s important to figure out what that meaning is for each.

The idea of quality, on the surface, is abstract, ambiguous and difficult to define and measure. Measuring and managing quality in the context of project-based work further complicates matters as individual projects are often unique making it difficult to develop a set of criteria to measure against.

Project quality relies on identification of the customers and of their requirements. At the early phases of a project, requirements might be vague and unmeasurable. As the project progresses, requirements must be refined into specifications that are measurable. The definition of quality as it relates to the project should be determined up front and well-defined with customer input so that at the end of the project the customers perceive the deliverables as being high quality.

Defining quality

To manage project quality, it is imperative to understand what quality is and how it relates to the project. Joseph M. Juran, widely-held to be the father of quality, defined quality as “fitness for use” which was later revised to “fitness for purpose” in the 6th edition of “Juran’s Quality Handbook.” Juran also emphasized two components of quality that are critical to managing it: features that meet customer needs and freedom from failures.

In the context of project quality, it is important to meet the customer’s needs while not “gold plating” the deliverables with expensive features that add little or no value to the customer. The Project Management Institute defines quality as “the degree to which a set of inherent characteristics fulfills requirements.” While it is important not to gold plate the deliverables, it is also important not to simply meet the bare minimum of requirements as specified in the project contract. Kenneth Rose, author of “Project Quality Management: Why, What and How,” describes a simple set of statements related to project specifications:

  • If you don’t meet the specifications, you are in breach.
  • If you want to complete the current contract, meet the contract specifications.
  • If you want to win the next contract, meet or exceed the customer’s expectations.

Exceeding the minimum requirements is important so the customer is satisfied. However, this must be done in a way that exceeding the project requirements adds value to the customer and not adding features that won’t benefit them.

Quality assurance versus quality control

Quality assurance and quality control are terms that are often used interchangeably but have different meanings. Quality assurance focuses on the process and preventing defects before they occur. Quality control focuses on the products and identifying  and correcting defects after they have been produced.

Another way to compare the two is that quality assurance is performed by people that need to understand the quality of a product but are external to the production. Quality control is performed by those responsible for producing the product.

Understanding the customers of a project is very important when trying to define quality as it relates to a project. The most obvious customer of a project is the person or organization that is paying the bills. However, this is often not the only customer.

Customers can include multiple organizations and multiple people within each of those organizations. The client commissioning the project is often different from the end user for the project. Regulatory bodies are also customers as applicable requirements that apply to the project have to be met. Some customers may be difficult to identify for a project as some may not be readily apparent or may not appear to later on in the project.

The cost of project quality

Quality is often misunderstood as an additional cost to the project, which is incorrect. When quality is integral to the project from the beginning, the time required to maintain quality is covered by the savings produced.

For quality to produce savings, it is important that it is included in the project from the beginning. If quality is ignored during a project, the defects will be discovered at the end of the project by the customer. (See Figure 1). Letting defects exist to this point are not only very costly to correct, but can cause extreme damage to reputation.

Often, quality is thought of as a process that occurs at the end of a project prior to shipping or turning over a product. Discovering defects during the testing /inspection phase is better than letting the customer find them, however, this still results in costly rework to correct the defects.

Identifying and correcting defects during the implementation phase of the project is an improvement, but may result in some degree of rework. Ideally, quality plans are created upfront during the specification/design phase of the project. At this phase of the project, correcting potential defects produces the least amount of additional cost and rework.

For quality, there is a rule known as the 1:10:100 rule that explains this concept: what costs $1 to correct in the specification and design phase would cost $10 to correct in the implementation phase and $100 to correct in the testing and inspection phase. During the project’s customer turnover phase, the cost of a dissatisfied customer or damaged reputation is impossible to measure.

Quality and project constraints

Projects tend to follow the triple constraint: scope, schedule, and budget. When considering quality, this is still a triple constraint. At no time, should quality be traded off in favor of scope, schedule, or budget.

Practicing project quality management is important for maintaining the project scope. Proper quality assurance during the project ensures that all of the project scope items will be met adequately. Quality control during the project inspects each scope item to ensure the requirements are met without defect, or remedies scope items that are found to have defects.

Scope and quality should not be confused. If tradeoffs during a project occur, as a member of the project team, you may feel that only the scope is being reduced. However, to a customer of the project, they may feel that the quality of the deliverable(s) is being reduced.

A project often may have an aggressive and tight schedule for implementation. Even in this case, it does not mean that quality should be compromised. The old adage, “There is never enough time to do it right, but always enough time to do it over,” applies here. A project that maintains its schedule, but cannot perform what it is intended to do, provides little value to anyone. Correcting the project defects at the end of the schedule will not only require costly rework, it will still be late.

For the project budget, quality is not an item that should be restricted by a budget. When properly implemented, a quality project will pay for itself by reducing waste, defects, and rework.

In the 4th edition of the Project Management Body of Knowledge (PMBOK) Guide, quality was added as a project constraint in addition to the traditional triple constraint along with risk and resources, shown in Figure 2. While quality is a constraint of the project, it remains imperative that it is not omitted in favor of scope, schedule or budget.

Project quality management methodology

The PMBOK Guide lists three processes for project quality management: quality planning, quality assurance, and quality control. Juran did not distinguish between quality assurance and quality control, but he did add one more important process: quality improvement.

Good project quality starts with planning for quality during the early stages of a project, and not relying on inspection near or at the end.

Quality planning is a three-step process:

  1. Identify customers
  2. Identify quality requirements
  3. Develop specifications.

Identifying all the customers of a project is the first step. This is important to consider any potential customers that may not be readily apparent at the start of a project but may appear during or after the project is over. Identifying these customers earlier in the project will result in a smoother project with fewer surprises at the end.

With the customers identified, the next step is to identify the quality requirements. This step will involve working with the customers to identify what the requirements are. Some requirements may also be implied, such as using industrial grade components and not consumer grade components.

Requirements now can be used to formulate specifications. A requirement is generic in nature, such as “the coffee will be hot.” A specification, on the other hand, is specifies what will be measured and how to measure it. The specification for the coffee requirement might be “the coffee will be a minimum of 180°F for 30 seconds after it has finished brewing.”

Fulfilling quality requirements

Quality assurance provides confidence that the quality requirements will be fulfilled. This process is the link between quality planning and quality control. It involves auditing the quality requirements and results from quality control to ensure appropriate quality standards and operational definitions are used.

A quality assurance plan should be developed for tracking quality activities. This provides a manageable list of quality activities and results for future reference. A quality assurance plan should contain the following information:

  • Task/work breakdown structure (WBS) reference
  • Requirement
  • Specification
  • Assurance activity
  • Schedule
  • Responsible party.

This plan contains the necessary information to define what will be done (assurance activity), when it will be done (schedule), and who will perform it (the responsible party).

Auditing the project quality may be performed by a member of the project team but should be someone removed from the actual development of what is being audited. Regardless of how honest and objective a person may be, trying to audit one’s own work may not identify every defect.

Quality control and improvement

Quality control is the process of accessing the products and validating the scope of the project. Products are checked against the specifications for conformance. If a product is out of spec, then quality control is the process in which it is corrected.

The second part of quality control is recommending updates for quality assurance to correct the process and reduce defects. This is the last part of the quality process, improvement. Quality is a constant process of change and improvement—not a destination.

Effective quality management is a tool to increase competitiveness and performance as it relates to the project. While difficult to define, quality management is an essential aspect of the broader topic of project management. A systematic approach to quality should be used as a method to identify customers, define requirements and specifications, and perform quality planning, assurance, and control.

Jay Steinman is a mechanical engineer at CSIA Certified system integrator, Huffman Engineering. Edited by Emily Guenther, associate content manager, Control Engineering, CFE Media, eguenther@cfemedia.com.

MORE ADVICE

Key Concepts

How to define project quality.

What to consider when measuring project quality.

The differences between quality control and quality assurance.

Consider this

How should a quality assurance plan be tailored for a particular industry or particular products?

ONLINE extra

More about the author: Jay Steinman is pursuing a master’s degree in engineering management at the University of Nebraska-Lincoln.