PMP and CAPM Exam Prep Simplified!

BrainBOK - PMP and CAPM Exams, ITTOs, Flashcards, Formulas, Quizzes, Contact Hours
Deep Fried Brain PMP CAPM PMI-ACP Certification Blog

  Perform Quality Control vs. Verify Scope

Perform Quality Control vs Verify Scope Most PMP aspirants get confused between Perform Quality Control and Verify 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, Fourth edition 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 Perform Quality Control and Verify Scope?

Let's look at the 2 processes closely.

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

Examples of Perform Quality Control and Verify Scope

Take the example of IT Systems project. Code (or peer) review, Unit Test, System Test, Functional Test, Regression Test fall under Perform Quality Control. User Acceptance Test falls under Verify 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 Perform Quality Control.

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 Verify 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 Verify 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 Verify Scope process reduces the project risk.

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

Related articles
Last Update:
Image credit: Flickr / blvesboy


  1. Thanks. Very well explained.

  2. @ Anonymous: Thanks for your feedback. A small encouragement like this keeps me going :)

  3. Very Well written and presented....BW you are mindblowing

  4. 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.

  5. Dear Sir,

    Your explnation is great. I read your blog regularly and also recommended to my friends.


  6. Excellent..pretty much clear on both process

  7. Sir,
    Please can you explain with example fpr difference between product quality and project qaulity

  8. A good article on difference between standarad and regulation

  9. @ 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.).


  10. Thanks, it has explained things well.

  11. 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,

  12. Thanks ShK and others for your feedback. Such comments keep me motivated :)

  13. 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.

  14. Hello Sir Chawlz,

    Sorry for the late response. I've been busy with some personal matters for the last few weeks.

    I think it would be good to know the names also.

    Good luck.

  15. 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.

  16. Hello Poorhouse Dad,

    Thanks for your feedback.

    I tried my best to explain the way I understood it, but there's always room for improvement.

    Best regards.

  17. Harwinder,
    Really useful and excellent. Simply superb


  18. So much positive feedback and appreciation. I'm overwhelmed. Thanks everyone.

  19. Thank you so much. Explanations are very simple and anybody can easily understand in the first attempt itself

  20. amazing explanation

  21. Hi there Harwinder,

    Godbless u for sharing.Your explanation on perform quality control and verify scope was just excellent!

  22. Point # 2- A small typo..Quality and scope management are knowledge areas and not process groups,

  23. Good catch, Thumbelina :)

    It has been corrected now.

    Thanks for pointing it out. I guess most people don't bother to .. that's probably the reason that it has been reported after 2 years!

    Thanks again.

  24. 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?


    1. 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.


  25. 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.

    1. 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.


  26. 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?

    1. Hi,

      QC is performed on the deliverables. So, you need to have those first.


  27. Thanks for the good write-up article, have been reading up the course material for the pass one week, yours really made it easy to understand.

    Will continue to read the rest...

  28. 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?

  29. 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 ?


Please do not include URLs (links) in your comments as any comment with links would be deleted automatically.

Other interesting posts