Definition of Key Terms

Quality Conformance to requirements

Quality Control (QC) ‘A part of quality management focused on fulfilling quality
requirements’ A corrective tool focused on the quality of
output. Example: Validation/software testing, inspection, peer
reviews.
Quality Assurance (QA) A part of quality management focused on providing
confidence that quality requirements will be fulfilled’ A
managerial tool focused on the process of quality Example:
Verification activities, process checklists, project audits and
methodology and standards development.

Difference between quality assurance and quality control

Quality assurance and quality control are two aspects of quality management. While
some quality assurance and quality control activities are
interrelated, the two are defined differently.

According to ISO 9000:2015: Quality management systems—Fundamentals and

vocabulary:

Quality assurance consists of that “part of quality management focused on providing

confidence that quality requirements will be fulfilled.” The
confidence provided by quality assurance is twofold—
internally to management and externally to customers,
government agencies, regulators, certifiers, and third parties.
Quality control is that “part of quality management focused on fulfilling quality
requirements.”

Inspection is the process of measuring, examining, and testing to gauge one or more
characteristics of a product or service and the comparison of
these with specified requirements to determine conformity.
Products, processes, and various other results can be
inspected to make sure that the object coming off a production
line, or the service being provided, is correct and meets
specifications.
 QA vs. QC, Quality Control vs. Quality Management: What’s the Difference?

In a company organized properly, quality assurance resides independent of

manufacturing and operations, and quality control resides within manufacturing and
operations. But what is the difference?
In theory, the difference is that quality assurance activities are proactive and intended to
prevent the production of non-conforming products. Quality control activities
are reactive, intended to detect and set aside non-conforming products using inspection
and testing mechanisms.
In practice, the difference is that quality assurance sets the rules and standards to
achieve product quality, and quality control inspects and tests the product against those
pre-set rules and standards.
Using the analogy of a college campus representing a medical device / pharma
company, quality assurance would be the city’s government and administration and
quality control would be the assigned police officers that patrol the college campus. The
assigned police officers (i.e. quality control) are tasked with enforcing the laws and
ordinances that the city’s government and administration (i.e. quality assurance) set,
within the territory of the college campus (i.e. company manufacturing operations). If
the city’s government and administration (i.e. quality assurance) was a missing piece
and the laws and ordinances were set and enforced by the police officers (i.e. quality
control) assigned to the territory of each college campus, consistency in the lawfulness
and justice at all college campuses within the city of Chicago would at the least not be
able to be guaranteed, and at the most differ considerably.
There is no such thing as a non-independent quality assurance group. Independence
from manufacturing operations and adequate authority is what validates quality
assurance as quality assurance, according to FDA and ISO 13485
regulations. Organizational freedom or independence does not necessarily require
quality assurance to be a stand-alone group; however, there must not be any conflict of
interest. Typically, it is very challenging to remove all conflict of interest for quality
assurance personnel without separating these individuals into a stand-alone group or
organizational position.
Now that we understand that independence is a must in order for quality assurance
to assure product quality, let’s clarify the responsibilities of both quality assurance and
quality cntrol and how both these functions are intended to successfully interact with the
organization.
Quality assurance is traditionally tasked with the following responsibilities, which are
intended to be proactive and prevent the production of non-conforming products.
Quality control is traditionally tasked with the following responsibilities, which in
practice are reactive and intended to detect and set aside non-conforming products
using inspection and testing mechanisms.
An "Inspection and Test Plan" (ITP) might also be called a "Quality Inspection
Plan".
Inspection and Test Plans set out critical control points or 'hold points' at various stages
within a process. Each control point is a scheduled inspection or verification activity
where you will make sure that things are progressing as they should be.
Inspection and Test Plans are often used as a way to satisfy the requirements of the
ISO 9001 standard related to control of production and service provision.
In ISO9001:2015:
8.5.1 Control of production and service provision
"... c) the implementation of monitoring and measurement activities at appropriate
stages to verify that criteria for control of processes or outputs, and acceptable criteria
for products and services, have been met; ..."
8.6 Release of products and services
"The organization shall implement planned arrangements, at appropriate stages, to
verify that the product and service requirements have been met. ... "
How to prepare an ITP
In general the ITP should follow the sequence of operations and clearly define who is
responsible for signing off each check.
First decide when in the process you want to conduct an inspection or check. Common
hold points are prior to a phase of high cost/ high value work, where any pre-exisiting
problems will create difficulties at the next stage, or will mean a high cost of re-work
when discovered later in the process.
For each check point you need to specify exactly what to look for (perhaps refer to
another document for details), how the check is recorded, and who must perform/signoff
the inspection.
Plan vs. Checklist
An Inspection and Test Plan is not the same as an Inspection Checklist.
An ITP tells you when in the process to perform an inspection. The details of the
inspection are contained in the checklist, and are typically recorded there.
An ITP might refer to different checklists for each inspection point, or could refer to a
code or standard that sets out the requirements for what and how the check must be
performed, e.g. AS1012 - Methods of Testing Concrete. A simple ITP can closely match
the checklist.
The Inspection and Test Plan is like a Work Instruction and the Checklist is a form that
becomes the actual record. Both the ITP and Checklist are documents that must be
controlled.
For Example
A common critical hold point is 'Incoming Goods" - particularly for manufacturers. Before
you start working with the raw materials, you want to be sure that the supplier has
delivered what you asked for. If the wrong material has been shipped, it's better to send
it back at the beginning rather than after you've spent time and money working on it. A
minimal inspection in this case would be to examine the supplied Material Certificates.
In construction, an inspection hold point usually comes after significant work as been
done and prior to covering it all up in the next stage or work. e.g. prior to internal lining
of the walls; prior to tiling going over the waterproofing.
The detailed inspection instructions for each step in this example are contained within
separate checklists. e.g. F-12 is a simple list of all the documentation that must be
present before the site preparation can commence. The Pre-pour checklist, F-72,
includes a space to record any rectification required. Both items are important records
for the project and can help to resolve any later disputes.
Each checklist will also include a header to collect project information, date, final signoff,
and other identifying information.
What's the difference in the "who" in the plan versus the "who" in the checklist? The
plan says which role is responsible for performing the inspection, and the checklist
records the actual person who performed the inspection on the day.
For technical production work, the checklist can include values to be measured and the
range of accepted values - e.g., for a circuit board assembly:
In this case, the "who" and rectification details are contained in the header and footer
sections of the checklist.

Quality Planning for Complex & Variable Work - e.g. a Project Quality Plan

For highly variable and complex work like construction projects you would prepare a
quality plan for each project. The Project Quality Plan sets out the requirements,
acceptance criteria, the methods that will be used to ensure that expectations are met,
and the resources needed.
The Project Quality Plan is to tell the customer how you will manage quality on their
project, reassuring them you have systems in place to deliver on your promises. The
information must be project specific, and will refer to site details, project activities,
contract requirements and applicable codes and standards.

Typical contents include:

 Scope of Work
 Project Contacts
 Deliverables and acceptance criteria
 Resources:
o Personnel and their key responsibilities, authorities
o Subcontractors and how you will control their work
o Equipment required for the project
 Quality Control:
o Verification activities
o Monitoring
o Inspections and Test plans
o Audits
o Managing Non-conformance & corrective actions
 Information Control:
o Communications Plan
o Document Control
o Change Management

Keep records!

No doubt your quality plan will include references to quality control records, e.g., forms
to fill in, checklists to follow, measurements to be recorded or monitored, hold points &
inspections, audits, reviews by senior personnel, etc.

These records are important evidence to demonstrate you have implemented your plan,
and provide data for analysis and improvements
 Control Quality versus Validate Scope

While reviewing my old blog posts I noticed a blog post describing the difference between
the control quality and verify scope processes based on the fourth edition of the PMBOK
Guide.

As you know, the 5th edition of the PMBOK Guide has arrived, and brought with it many
changes. The change which forced me to write this blog post is that the PMI has replaced
the “verify scope” process with the “validate scope” process.

Therefore, I’m rewriting this blog post to accommodate this change and with more depth.

Okay, let’s get started.

Before we start discussing the quality control and validate scope processes, let’s
understand the meaning of “validate” and “verify” and how they differ from each other.

The verification process comes before the validation process. In the verification process,
you inspect the deliverable for its completeness and correctness. Here you will check that
the product is built the correct way. Verification is an internal process performed by quality
control engineers where you make sure that the product meets all stated requirements,
specifications and complies with regulations.

Verification is about building the product correctly.

The validation process comes after the verification process, and it checks if the product
meets customers’ and other stakeholders’ needs or not. Here you will analyze whether
the product performs its intended use as it was envisaged. The validation process does
not involve the project management team. Most of the time, this process involves the
project manager, customers, and other stakeholders.

Validation is about building the right product.

Example

Suppose you plan to build a new demanding product. You design and develop it. Before
launching the product you check that whether it was developed as per the design or not
and if it is developed the right way or not. If the answers to these questions are yes, you
will launch it to the market. This step shows that you have verified the product.

Now, you have launched the product to the market. Your product has gotten good
responses from customers, and good sales were generated as you have expected.

This means that the product is validated because it has satisfied its users’ needs and
expectations.
Now let’s discuss the control quality and validate scope process in detail.

The control quality and validate scope processes may seem to be the same, because
both processes involve the inspection and review of deliverables; however, they are not
the same. The purposes of these two processes are different, and both processes are
performed in a different manner.

Control Quality

The control quality process is performed internally to ensure that deliverables are defect
free, complete, and fulfill all stated requirements. Quality control activities are undertaken
by the quality control people during the project execution.

According to the PMBOK Guide, 5th edition, “Control Quality is the process of monitoring
and recording results of executing the quality activities to assess performance and
recommend necessary changes.”

This means that in the control quality process, you will see the specifications of
deliverables and tally them with the designed specifications. If you find any deviation from
the design specifications, you will recommend a corrective and/or preventive action.

In the control quality process, you inspect the deliverable for its correctness and whether
it meets all its quality requirements specified in the contract.

Example

Suppose you obtain a contract to build 200 km road. You start working on it, and appoint
a quality control engineer to monitor the quality of work. This quality control engineer will
be available all the time on-site. He will check the quality of deliverables at each stage;
e.g. the quality of raw materials, level of the road, slope on turn, alignment of the
footpaths, etc.

The above example shows quality control activities.

Validate Scope

The validate scope process is performed by the project manager with the client after the
deliverable or the product is completed. The purpose of this process is to ensure that the
client accepts the product formally.

According to the PMBOK Guide, 5th edition, “Validate Scope is the process of formalizing
acceptance of the completed project deliverables.”

From the above definition, you can clearly see that the sole purpose of the validate scope
process is to get formal acceptance from the client that the product is acceptable to him.
In the quality control process you verify the deliverables, and once the quality control
department passes the deliverables, you validate it with the client.

Example

Let’s continue with the example given for the control quality process.

You have completed 50 km out of 200 km of the road. You invite the client to come and
inspect the completed part of the road so that they can formally accept it, and you get the
payment.

The client comes and sees if all of his requirements have been met or not. The client will
check whether the width of the road is correct, the footpath is properly aligned, and
whether the length of the road is correct or not. After inspecting these parameters, the
client may also run a few tests to check the strength of the road.

Once the client is satisfied, he signs the acceptance letter, the road is formally accepted,
and you get paid for the completed part of the work.

This process is called the validate scope.

Please note, it is not necessary that the validate scope process be performed at the end
of the project. This process can be performed before the project ends; moreover, this can
also happen with the control quality process, as we can see in the above given example.

In the example, although the client has validated the scope and accepted the 50 km of
road, you are still working to build the rest of the road.

Similarities between Control Quality and Validate Scope

The following are a few similarities between the control quality and validate scope
processes:

 Both processes belong to the monitor and control process group.

 Both processes involve inspection and review of deliverables.

The similarities end here. Now let’s see the differences between these two processes.

Differences between Control Quality and Validate Scope

The following are a few differences between the control quality and validate scope
processes:

 Control quality is performed internally by the project manager with the quality
management team, while validate scope is performed by the client with the project
manager.
  Control quality checks whether the product is produced in the right way, and
validate scope is concerned with producing the right product.
 The control quality process is performed to ensure that product is ready to be
delivered while validate scope process gets the formal acceptance from the client
after delivering the product.
 Control quality is usually performed during the project execution, and validate
scope is performed at the end of the phase or project.
 The objective of the control quality process is to make sure the product is defect
free, and fulfills all its requirements. On the other hand, the purpose of the validate
scope process is to get formal acceptance of the product from the client.

Summary

For many people, control quality and validate scope are the same; however, they are
quite different. Although they involve the inspection of deliverables, their purpose is
different. The control quality process helps you build the correct product in the first place,
and the validate scope process helps you get the formal acceptance from the client that
he has accepted the deliverable or the product. These two processes complement each
other and help deliver a good quality product.

As a project manager, you must understand the difference between these two processes
and manage them accordingly for your project to conclude successfully.

Here is where this blog post on control quality and validate scope ends. Make sure you
understand these terms and the difference between them because PMI words their
questions in such a way that confuses even the best minds. Read this blog post
thoroughly, and if you face any difficulty in understanding, you can discuss it with me
through the comments section.