September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Quality control is process driven. Changes to the quality control process require approval, just like changes to a project.
To control quality you need to do it again the latest change to the project requirements. You probably prefer to receive the approved change instead of searching for them in an updated document.
It's very logical if you think it logically. Approved CR's changes the deliverables. You have to validate deliverables based on the quality premises then logically Approved CR's is an input of QC process.
It was a hugh debate in the past about this topic. If you modify a deliverable then you have to send it to Control Quality process. To see if the change was made as defined you need the deliverable and the approved change because the approved change is the document or the artifact where the description of the change was stated so is the source to assure that the change was made in the deliverable as needed.
Because you have to check the result/product with the latest design/plan.
"The implementation of approved changes should be verified, confirmed for completeness, retested, and certified as correct." PMBOK® Guide, p. 301
Thank you all for your inputs. Relying on the approved CR's to do Control Quality in my opinion is not a best practice. That could lead to deliverables specs scattered accross project documents and all approved CR's.
The PMBOK mention the configuration management plan which defines how to manage effectively the changes to the deliverables among other components of the project.
In my opinion using the configuration management plan is better than relying on the approved CR's. The configuration management plan is an input to 2 processes : Perform Integrated Change Control and Control Scope. It is however not used in the Control Quality process.
I'm curious to know what was the debate about and the different point of views that were shared.
But you do need the CR in order to apply the Control Quality process to ensure that what was agreed to be changed actually gets changed. That starts with making the appropriate changes to the scope, schedule, and cost baselines, and the quality plan, and the quality control process, and whatever else needs to be changed so that the deliverables specs are NOT scattered across project documents and approved CRs.
Control Quality is needed to keep this mess from happening. That's why it's an input to Control Quality.
In my view, approved change request is another kind of scope, no much different from original defined scope.
Please login or join to reply