Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Scope Management
Validate Scope vs Control Scope?
Why does Validate Scope come before Control Scope in PMBOK? Shouldn't it be the other way around as Validate scope is the final step before Closing a project and before entering Validate scope process one would control the scope (until confirmed that all requirements of the project are met)?
Sort By:
Page: 1 2 next>
Validating the scope happens both at the beginning and at the end of projects.

Validating the scope at the beginning of the project is ensuring that the defined scope completely, correctly, and clearly defines the boundaries of the project. This is validating that the problem statement is right.

Validating scope at the end of the project is to ensure the project delivered everything within the scope of the project (complete), the deliverables work as expected (correct), and that the customer understands how the solution works. (clear). This is validating that the provided solution adequately addresses the problem statement.
...
1 reply by Aarti Verma
Jul 17, 2020 8:33 PM
Aarti Verma
...
Thanks Keith for your response. Although I understand what you are explaining here but I am not able to find any reference to using Validate Scope at the beginning of the project (I am studying for my exam to sticking with PMBOK) Per definition given, Validate scope is the process of formalizing acceptance of the 'completed project deliverable', indicating it being performed at the end (towards closure) of the project. Not sure if I am missing something here?
Remember that inside the PMBOK is not a project life cycle defined then is not right to say that something comes before the other. The project life cycle will determine that. PMI explicit said that the numbers assigned to process were giving just to facilitate the reading (in the understanding of the PMI) but they do not define precedence. So, the important thing, is to understand what it does mean each ones. Validate Scope is the formal acceptance. Is when you as project manager goes to the stakeholder that requested the solution you are creating and you say "ok, let us review that all you request is all you get". Control Scope are actions you take to avoid things like scope creep.
...
2 replies by Keyvan Rafiei
Jul 18, 2020 1:24 AM
Keyvan Rafiei
...
100% agree.
Jul 18, 2020 2:07 AM
Keyvan Rafiei
...
I would also add that "Manage Quality" process has "validated deliverables" as an output..... so really, one shouldn't see these as precedents, but rather part and parcel of managing scope...
Aarti -

Monitoring & Controlling Processes can be executed at any time over the life of a project and there is generally not a linear flow to the PMBOK processes. Validate Scope does usually come after Control Quality for a given deliverable as we want to have our stakeholders accept verified deliverables, but Control Scope could happen at any time once we have defined the scope of the project.

Kiron
...
1 reply by Aarti Verma
Jul 17, 2020 8:35 PM
Aarti Verma
...
Hi Kiron, Yes I agree the flow of Control Quality into Validate scope. I think I am overthinking here ? I did put me thoughts in the post above to clarify where I am coming from.
Project Management processes aren't a rigid line that must be followed in a certain order. Processes are iterative and could be performed many times throughout the life cycle. Validate scope occurs when a deliverable is done and passes a validating and verifying process prior to enter to finish stage. Control scope can be executed at any time in the life cycle of the project to execute adjustments as required.
...
1 reply by Keith Novak
Jul 17, 2020 2:46 PM
Keith Novak
...
Be careful not to confuse the terms verification and validation. This is one of if not the most common misunderstandings I see related to PM, BA, and Syst Eng terminology used in practice.

Verification is the process of evaluating whether something meets individual requirements, such as through a test or analysis. Validation is the process of auditing the full set of requirements to ensure that it is the appropriate set to completely define the solution and that at the end, verification is complete for the entire set of requirements.

You can verify that your product meets a set of requirements such as performance, but if you did not capture all the right requirements to begin with such as you missed safety, you do not have a valid solution.

In the past I have reviewed everywhere the PMBOK uses these terms, and although they define them correctly, they use them somewhat interchangeably and sometimes incorrectly within the text.
Aarti,

I'm of the same view as Kiron Bondale and Veronica Ruiz. Additionally, depending on the project type and industry, Validate and Control scope processes may be done concurrently and/or interchangeably. The PMBOK is a guide to ensure that the processes are followed and not necessarily that the processes are done in a specific flow.
Jul 17, 2020 11:29 AM
Replying to Verónica Elizabeth Pozo Ruiz
...
Project Management processes aren't a rigid line that must be followed in a certain order. Processes are iterative and could be performed many times throughout the life cycle. Validate scope occurs when a deliverable is done and passes a validating and verifying process prior to enter to finish stage. Control scope can be executed at any time in the life cycle of the project to execute adjustments as required.
Be careful not to confuse the terms verification and validation. This is one of if not the most common misunderstandings I see related to PM, BA, and Syst Eng terminology used in practice.

Verification is the process of evaluating whether something meets individual requirements, such as through a test or analysis. Validation is the process of auditing the full set of requirements to ensure that it is the appropriate set to completely define the solution and that at the end, verification is complete for the entire set of requirements.

You can verify that your product meets a set of requirements such as performance, but if you did not capture all the right requirements to begin with such as you missed safety, you do not have a valid solution.

In the past I have reviewed everywhere the PMBOK uses these terms, and although they define them correctly, they use them somewhat interchangeably and sometimes incorrectly within the text.
Thank you all for your responses. I truly appreciate this discussion & you sharing the knowledge. I understand that each process has its own role to play and depending on life cycle, can be iterative in nature and can be performed as needed (not necessarily as defined in PMBOK). I have personally experienced that too. But keeping what happens in real world aside, and going by PMBOK way of things, there is a logic to why certain process come before or after another process, e.g. ideally you should not or cannot not
- Create WBS without Collecting Requirements,
- Plan Risk Response without correctly Identifying Risks
- Develop/ Manage Team without Acquiring Team.
In the same breath, ideally we cannot/should not present anything to customer (Validate scope) unless it has been through Control Scope. Again I fully understand the functionality of both processes but like other Process groups following an order, I personally feel it just makes more sense that Validate scope (final step before closure) should happen after Control Scope (managing changes to scope baseline).
...
1 reply by Sergio Luis Conte
Jul 17, 2020 10:18 PM
Sergio Luis Conte
...
Control Scope is about lot of things including what you do when Validate Scope. In fact, you need to Validate Scope to update your Control Scope registers. But always it will depends on your life cycle.
Jul 17, 2020 12:32 AM
Replying to Keith Novak
...
Validating the scope happens both at the beginning and at the end of projects.

Validating the scope at the beginning of the project is ensuring that the defined scope completely, correctly, and clearly defines the boundaries of the project. This is validating that the problem statement is right.

Validating scope at the end of the project is to ensure the project delivered everything within the scope of the project (complete), the deliverables work as expected (correct), and that the customer understands how the solution works. (clear). This is validating that the provided solution adequately addresses the problem statement.
Thanks Keith for your response. Although I understand what you are explaining here but I am not able to find any reference to using Validate Scope at the beginning of the project (I am studying for my exam to sticking with PMBOK) Per definition given, Validate scope is the process of formalizing acceptance of the 'completed project deliverable', indicating it being performed at the end (towards closure) of the project. Not sure if I am missing something here?
...
1 reply by Keith Novak
Jul 18, 2020 12:29 PM
Keith Novak
...
For the exam it is wise to go by what the PMBOK says. It isn't always completely correct however.

The meaning of validation becomes much more clear in a discussion of requirements management, but that is mostly outside the scope of the PMBOK. The PMBOK and the SEBOK (Systems Engineering) are very closely related but on the SE side they cover the product side in much more depth. If you look up the classic "Systems Engineering V" model, it describes how a product is defined iteratively at increasing levels of fidelity. You start with the product, break it into logical pieces like peeling an onion as you add more and more detail or "remove ambiguity from the solution space". At each level of decomposition, you have to look at all the pieces and see if they define a complete product. That is validation. Validation works top down on the left of the Vee, and verification works bottom up on the right.

The same applies with scope. As others have pointed out, the PMBOK process groups don't occur in a single linear timeline. They may occur over and over. In the beginning, you must establish that you have the right scope before you begin planning. Is this what the customer wanted? Is it everything the customer wanted? That's validation.

As the project progresses and changes occur, it is important to ask, "Do we still have the right scope, and did we include everything?" The customer expectations may have changed. New discoveries may have revealed something needs to be added or is unnecessary. That's still validation and is a big function of major milestone reviews.

At the end of the project where the PMBOK at least appears to place Validate Scope, that is ensuring that your solution did indeed cover the entire scope. This is your closeout process. Have all the requirements been met? Have all the functions been included? Are all the lifecycle phases that are within the project scope covered? Does the finished product as delivered meet the intent of the project?

Although it's much more clear in the requirements world, validation with respect to scope means the same thing. It begins with ensuring you have all the right pieces in your project to address the customer's needs. As it evolves, you must continue to ask, "Did we include everything and are we including unnecessary stuff?" At the end where the PMBOK at leas *appears* to place it, you are asking, "Did we successfully deliver everything we said we would in the plan?" For the exam, remember where PMI puts it, but in practice remember that is it an ongoing activity.
Jul 17, 2020 8:12 AM
Replying to Kiron Bondale
...
Aarti -

Monitoring & Controlling Processes can be executed at any time over the life of a project and there is generally not a linear flow to the PMBOK processes. Validate Scope does usually come after Control Quality for a given deliverable as we want to have our stakeholders accept verified deliverables, but Control Scope could happen at any time once we have defined the scope of the project.

Kiron
Hi Kiron, Yes I agree the flow of Control Quality into Validate scope. I think I am overthinking here ? I did put me thoughts in the post above to clarify where I am coming from.
Jul 17, 2020 8:24 PM
Replying to Aarti Verma
...
Thank you all for your responses. I truly appreciate this discussion & you sharing the knowledge. I understand that each process has its own role to play and depending on life cycle, can be iterative in nature and can be performed as needed (not necessarily as defined in PMBOK). I have personally experienced that too. But keeping what happens in real world aside, and going by PMBOK way of things, there is a logic to why certain process come before or after another process, e.g. ideally you should not or cannot not
- Create WBS without Collecting Requirements,
- Plan Risk Response without correctly Identifying Risks
- Develop/ Manage Team without Acquiring Team.
In the same breath, ideally we cannot/should not present anything to customer (Validate scope) unless it has been through Control Scope. Again I fully understand the functionality of both processes but like other Process groups following an order, I personally feel it just makes more sense that Validate scope (final step before closure) should happen after Control Scope (managing changes to scope baseline).
Control Scope is about lot of things including what you do when Validate Scope. In fact, you need to Validate Scope to update your Control Scope registers. But always it will depends on your life cycle.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to."

- Lewis Carroll