fbpx

Reply: Why shall I 'validate the project deliverables' again in the CLOSE process group? Isn't it done in validate scope?

Name
E-mail
Your e-mail address will never be displayed on the site.
Subject
Message

Topic History of : Why shall I 'validate the project deliverables' again in the CLOSE process group? Isn't it done in validate scope?

Max. showing the last 6 posts - (Last post first)
5 years 10 months ago #14187

Eric Lundahl

Eric Lundahl's Avatar

There are 3 main areas where you are going to be checking your deliverables:
1. Control Quality where you or your team internally verify that that an item has been completed as dictated specified by the requirements documentation and to the quality specifications according to your quality management plan. This creates “Verified Deliverables"

2. In Validate Scope you take the "verified deliverables" and get formal sign-off from your customer on the deliverable. This creates an output of an "Accepted Deliverable"

3. In Close Process or Phase you take ALL the "Accepted Deliverables" and present them to the customer along with any issues the customer had with those and get a final sign off on the entire package, this is more of a confirmation that all the work has been done as the customer asked. And can be found in” Domain 5 - Task 1: Obtain final acceptance of the project deliverables from relevant stakeholders to confirm that project scope and deliverables were achieved.

Real World Example:
I work in the software industry and in my projects, we act primarily as a seller of software enchantments. Early in the project my customers and I will create specifications for specific features they want added to the project.

As each feature is finished it will go to our QA department for testing, they may find issues which they submit back to the dev team, at some point the item will pass through the QA team into my hands where I will give it a final run through and verify that it's what the customer wanted - All of this is occurring in Control Quality at the end I'll have my verified deliverable.

Next, I install the feature in the customer's Test environment. There they run through a series of tests or a UAT in which they may find issues, report those issues back to me where I then must fix them and get a new release out to their test environment. Once the customer is satisfied (or satisfied enough) they will sign off on that feature either in an email or formally (depending on the process we are using) - This is the Validate Scope process where the customer is formally signing off on a specific feature.

Finally, my customer will go through a Go-Live on the system we've created. There may be issues they report after the Go-Live or items they find were that scope element is not working quite like they envisioned...Or perhaps there is a feature that I've missed when I review our Agreements. So, while they may have accepted most of the features, they may have newly discovered problems with the features, want changes, or find missing elements. Think of this as a holistic review of all project deliverables by both you and the customer to ensure or confirm that your obligations have been met satisfactorily as specified in the Agreement rather than an interim sign-off on a specific deliverable.

Hope this helps!
5 years 11 months ago #13836

Daniel Blossey

Daniel Blossey's Avatar

- In which of the following phases should quality control be used?
A.) Executing
B.) Executing and Closing

Correct answer: B

A. is wrong because "Although quality control could be used in executing to identify causes of poor quality or performance [(= me: perform quality assurance)], it is not the best answer as it should be also applied in the closing phase to validate the project deliverables before releasing to the customer for final acceptance.".

Question: The verified deliverable from control quality is validated in validate scope against the acceptence criterias (requirments documentation) which is part of the M&C process group. Why shall I validate the project deliverables again in the CLOSE process group?

Thanks!

OSP INTERNATIONAL LLC
OSP INTERNATIONAL LLC
Training for Project Management Professional (PMP)®, PMI Agile Certified Practitioner (PMI-ACP)®, and Certified Associate in Project Management (CAPM)®

Login