Sergio,
Your explanation makes the most sense. The PMBoK does say “This process is performed periodically throughout the project as needed.” The section is very awkward however. Verifying deliverables before validating scope would indicate to me that you make sure all the pieces work individually, before you validate that you have a complete solution. If you add loops into that flow diagram however, I can see how Control Quality doesn’t always have to come before Validate Scope.
The SEBoK does a much better job of differentiating verification and validation than the PMBoK which tends to use the terms interchangeably and in some places incorrectly. When I look at the ITTO for Validate Scope and the specific language in the description, it reads much more like it is intending to describe verification (are the individual deliverables acceptable), than validation (do all the deliverables together cover than entire scope). When I consider the SE framework, you always validate that the solution is appropriate and complete first, to avoid developing a detailed solution which does not fit the problem.
...
1 reply by Sergio Luis Conte
Apr 25, 2019 11:52 AM
Sergio Luis Conte
...
Agree with you Keith. Including what you mentioned about SEBok. A liitle comment just in case I did not undestand what you stated in your first sentence. Control Quality must be performed before Validate Scope because Validate Scope is about to formal acceptance of deliverables. You can see that Verfied Deliverables is an input
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 25, 2019 11:39 AM
Replying to Keith Novak
...
Sergio,
Your explanation makes the most sense. The PMBoK does say “This process is performed periodically throughout the project as needed.” The section is very awkward however. Verifying deliverables before validating scope would indicate to me that you make sure all the pieces work individually, before you validate that you have a complete solution. If you add loops into that flow diagram however, I can see how Control Quality doesn’t always have to come before Validate Scope.
The SEBoK does a much better job of differentiating verification and validation than the PMBoK which tends to use the terms interchangeably and in some places incorrectly. When I look at the ITTO for Validate Scope and the specific language in the description, it reads much more like it is intending to describe verification (are the individual deliverables acceptable), than validation (do all the deliverables together cover than entire scope). When I consider the SE framework, you always validate that the solution is appropriate and complete first, to avoid developing a detailed solution which does not fit the problem.
Agree with you Keith. Including what you mentioned about SEBok. A liitle comment just in case I did not undestand what you stated in your first sentence. Control Quality must be performed before Validate Scope because Validate Scope is about to formal acceptance of deliverables. You can see that Verfied Deliverables is an input Saving Changes...
I appreciate the clarification, Sergio, and thank you for your response as well Thomas.
I wound up giving this subject a lot of thought because my fundamental disagreement was that the function of Validate Scope is not only about deliverable acceptance. I realized I was thinking about both technical and project oversight aspects however.
In the PMBoK, scope validation is focused on whether or not the deliverables are closed out. On the technical side, validation is focused more on whether the solution addresses the need. Both are important, but PM vs. engineering development.
...
1 reply by Sergio Luis Conte
Apr 26, 2019 5:14 AM
Sergio Luis Conte
...
I agree with you again. Started for the use of "validation" and "verifying" I do not like the approach. One more comment (i am doing that because i always read you and help me a lot). The role accountable for the solution is the business analyst then thre is an activity inside the business analysis documentation where what you stated is done (solution assessment and validation was the former name). Project Manager is accountable to create the components of the solution as defined and only as defined. That is made into Control Quality process. That is because something mostly forgotten and that have the highest impact when project manager goes to Validate Scope is the acceptance criteria. Most of the times acceptance criteria are not clearly stated when project requirements are stated then Validate Scope is a nightmare. Project Manager is accountable for project requirements definition. So, after validating scope, the business analyst take the deliverables and goes to stakeholders to validate that all created inside the project is what they are expected. The timming and interaction of both roles are determined by the solution life cycle that could be diferent than the project life cycle.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 25, 2019 10:53 PM
Replying to Keith Novak
...
I appreciate the clarification, Sergio, and thank you for your response as well Thomas.
I wound up giving this subject a lot of thought because my fundamental disagreement was that the function of Validate Scope is not only about deliverable acceptance. I realized I was thinking about both technical and project oversight aspects however.
In the PMBoK, scope validation is focused on whether or not the deliverables are closed out. On the technical side, validation is focused more on whether the solution addresses the need. Both are important, but PM vs. engineering development.
I agree with you again. Started for the use of "validation" and "verifying" I do not like the approach. One more comment (i am doing that because i always read you and help me a lot). The role accountable for the solution is the business analyst then thre is an activity inside the business analysis documentation where what you stated is done (solution assessment and validation was the former name). Project Manager is accountable to create the components of the solution as defined and only as defined. That is made into Control Quality process. That is because something mostly forgotten and that have the highest impact when project manager goes to Validate Scope is the acceptance criteria. Most of the times acceptance criteria are not clearly stated when project requirements are stated then Validate Scope is a nightmare. Project Manager is accountable for project requirements definition. So, after validating scope, the business analyst take the deliverables and goes to stakeholders to validate that all created inside the project is what they are expected. The timming and interaction of both roles are determined by the solution life cycle that could be diferent than the project life cycle. Saving Changes...
Tamer Zeyad SadiqAssistant Cost Manager| Turner & TownsendRiyadh, Ar Riyad, Saudi Arabia
I think the workflow goes as follows: The deliverables created as per the Direct and Manage Project Work process, together with the Quality Management plan, Quality metrics, Quality checklist, and test evaluation documents created from the Plan Quality Management and Manage Quality processes, respectively, are fed into the Control Quality process. The outcome will be the verified deliverables (by the internal project team), which are then fed into the Validate Scope process to generate the Accepted deliverables by the customers or any changes requested in case of nonacceptance. Saving Changes...
