Control Quality vs Validate Scope

4 minute read    Updated:    Harwinder Singh

Control Quality vs Validate Scope Most PMP aspirants get confused between Control Quality and Validate Scope. If I had to list the top 5 most-confused topics for the PMP Exam, this topic would be on that list. This article aims to clear the confusion by bringing out on the key differences between the 2 processes and reinforcing the concepts with examples. I suggest that you refer to the PMBOK® Guide and a good PMP Exam Prep book or course material for a more comprehensive explanation of all the inputs, tools and techniques and outputs of these processes.

What is the difference between Control Quality and Validate Scope?

Let's look at the 2 processes closely.

  1. Control Quality is about ensuring that the deliverables meet the quality requirements defined in the Quality Management plan. Validate Scope is about formalizing the acceptance of deliverables.
  2. Control Quality belongs to Project Quality Management knowledge area, whereas Validate Scope is under Project Scope Management.
  3. Control Quality is focused on correctness of the deliverables whereas Validate Scope is focused on acceptance of deliverables.
  4. Control Quality is usually done by the Quality Control department, whereas Validate Scope is done by customer or sponsor. In Validate Scope process, the project manager holds several meetings with the customer or sponsor to review the deliverables to ensure that the deliverables are completed satisfactorily.
  5. Control Quality is usually done before Validate Scope, but these processes can be performed in parallel.
  6. Validated deliverables, which are an output of Control Quality, are an input to Validate Scope. The output of Validate Scope are Accepted Deliverables.
  7. Both Control Quality and Validate Scope are done as part of Monitor and Control process group, but Validate Scope can also be done at the end of each project phase to validate the deliverables of each phase.
  8. Both Control Quality and Validate Scope processes can result in change requests.

Examples of Control Quality and Validate Scope

Take the example of IT Systems project. Code (or peer) review, Unit Test, System Test, Functional Test, Regression Test fall under Control Quality. User Acceptance Test falls under Validate Scope.

Let’s take another example to drive home the point. Suppose you want to get your house renovated. You hire a contractor for the job, provide all the requirements and sign the contract. Now as the contractor is doing the job, it is the contractor’s responsibility to ensure that the work or deliverables are meeting the quality standards established for the project. The contractor ensures that the floors are leveled, the paint is uniform, the electrical switches work, the locks work etc. This is an example of Control Quality.

As different sections of the house (such as the living room, bedrooms and kitchen) are getting complete, the contractor invites you to inspect the work and make sure it meets your requirements. This is an example of Validate Scope.

Let’s say when you inspect the first bedroom, you find that the paint finish on the wall is glossy, but you had requested matte finish. You discuss it with the contractor and the contractor agrees to fix it according to your requirements (change request). Now imagine what would have happened if you had waited until the whole house had been renovated, before making the inspection. It would have been a huge deal to repaint the entire house.

Think of Validate Scope as checkpoints during the course of the project to ensure that the project is on-track from the customer’s point of view. If you wait until the final acceptance of the project in the “Close Project” process, it might be too late to make any changes. The Validate Scope process reduces the project risk.

I hope you can appreciate the difference between Control Quality and Validate Scope better and see how they fit into Project Management.

Image credit: Flickr / blvesboy

You May Also Enjoy

Functional Organizational Structure

8 minute read

In a functional organization is the most common form of organization structure where staff members are grouped by specialty, such as engineering, manufacturi...

Pareto Charts and the 80/20 Rule

8 minute read

A Pareto Chart or Diagram, one of the Seven Basic Quality Tools, is a specific type of Histogram ordered by frequency of occurrence.

Leave a Comment

Please select the checkbox

34 Comments

Missing Avatar

One thing to keep in mind with the house example. One could say at the point he glossy paint was installed, it met the QC standards by protecting the wall. (i.e. same function as flat paint).

Thus in that example the painted room would pass QC, but NOT pass Verify scope.

Reply to Brian E
Harwinder Singh Avatar

@ Anonymous:

Product Quality, as the name suggests, focuses on the quality of the "product" of the project. It is measured in terms of the degree to which the product conforms to customer's requirements.

Whereas, Project Quality focuses on the quality of "project management processes". It is measured in terms of the degree to which the project meets its objectives (scope, time, cost, quality etc.).

Thanks.

Reply to Harwinder Singh
Missing Avatar

Hi Harwinder,

I have recently become aware of your blog. Brilliant! I should say! All the confusing terminologies of project management are well explained with easy to understand examples.

Well done! Any PMP aspirant who visits your blog will definitely get a chance to deepen his/ her understanding of the subject and will certainly gain confidence to approach the PMP exam.

Thank you so much!

Best Regards,
ShK.

Reply to Tanjore Doll
Missing Avatar

For the PMP exam, do you have to know the names of the people who developed QA theories (Duran, Demming, etc.) or just the theories themselves. My course went over both but my practice book only covers the theories and says that's all you need.

Reply to Sir Chawlz
Missing Avatar

Sorry, that's about as linear as the PMBOK, which has the consistency of oatmeal with raisins in this area. PMBOK convolutes verbs and adjectives verify, verified, validate, and validated. For example, the Verify Scope process aligns with the definition of 'validation'. Look it up in the Glossary! One input to Perform Quality Control is 'validated' products, meaning products that satisfy the requirements, which aligns with the definition of 'verification.' I need an explanation that untangles these paradoxes rather merely reinforces them. Could you straighten this out, and diagram the full procession of these terms for those of us who learn better from block diagrams than from stories? Thanks.

Reply to Poorhouse Dad
Missing Avatar

Hello Harwinder,
I am getting confused on why 'Verify Scope' does not output the PMP updates and OPA updates.
When there is a CR raised internally, there needs to be a work done. That would change our current plans - Cost Management Plan, Project Schedule, Quality Management Plan and Risk.
We may also ponder over why we did Glossy when the customer asked for Matte. Do we need to document the Lessons learned of OPA?
Why has PMBOK missed this two for 'Verify Scope' when they are output for the rest of the Monitoring and Control process?

Regards,
Rajesh

Reply to Anonymous
Missing Avatar

Just a point in case - "Verify Scope" should be substantiated with "with Actual Deliverables".

I would rather verify the scope with my customer - ( Matte / Gloss paint in this case ) even before I have implemented it.

Hence I would verify the scope usually before Performing Quality Control.

Reply to Anonymous
Harwinder Singh Avatar

Hello Rajesh,

Technically speaking, you can update the Project Management Organizations Process Assets any time during the project.

Similarly, EEFs, and OPAs should be taken into account in all processes (even PMBOK Guide 4 says so).

Now why Project Management Plan Updates and OPA Updates are listed as Outputs on some processes and not others, can only be explained clearly by people who helped draft the standard. I can only try to explain the way I understand it.

Verify Scope is about getting customer sign-off on deliverables. If you find that you did Glossy, when customer wanted Matte, then you have Quality Control and Assurance issues, and it should have been caught in Quality Control. If you still find problems during Verify Scope, you'll raise Change Requests. Based upon the outcome of the Change Requests, you may update Project Management Plan, lessons learned etc.

Hope that helps.

BR.

Reply to Harwinder Singh
Harwinder Singh Avatar

Usually QC comes before Verify Scope. QC is about keeping the defects from reaching the hands of the customer.

Speaking from my IT experience, we do unit testing, functional testing, etc. (Quality Control), before we invite the user for User Acceptance Testing (Verify Scope). Any UAT issues will result in change requests. When UAT is successfully completed, the customer gives a formal sign-off on the deliverables.

However, sometimes we do invite customers for "early exposure", for getting early feedback on the system even before QC is done, but that's not Verify Scope. At the end, there's still a formal User Acceptance Testing (Verify Scope).

Feel free to share your own experience.

BR.

Reply to Harwinder Singh
Missing Avatar

Hi good explanation! From your examples, I understood that we do the unit testing, funtional testing (QC) after the implementation to verify the deliverable fulfill the stakeholders expectation. But my question is how do we test (QC) the scope/requirement that have not implemented yet?

Reply to Anonymous
Missing Avatar

Harwinder-
Great explanation. I have another question along similar lines. Does that mean that quality is a sub-set of scope? In other words, it is possible to meet quality without meeting scope but it is not possible to fulfill scope without meeting quality requirements. In the above paint example, if the definition of quality is functioning switches / gates / doors & glossy paint, it was an implicit requirement (even if it was not included in scope formally). Furthermore, the very fact that quality control should happen prior to verify scope also means that verify scope is the next step in the validation chain that is inclusive of quality check as well (a quality failure noticed here will push the project back to quality fix). What do you think?

Reply to Falcon
Missing Avatar

There is a very thin line between change request and defect, so in one of your example above where you requested Matte Paint and during verify scope you found it to be glossy, this is defect and doesn't needs to go in as change request, since it is not changing any scope ? Thoughts ?

Reply to Rahul Juneja