Aarti VermaExecutive Director| JPMorgan ChaseArdmore, Pa, United States
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)? Saving Changes...
Keyvan RafieiDirector, Project Implementation & Control| PHSALangley, British Columbia, Canada
Jul 17, 2020 7:12 AM
Replying to Sergio Luis Conte
...
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.
100% agree. Saving Changes...
Keyvan RafieiDirector, Project Implementation & Control| PHSALangley, British Columbia, Canada
Jul 17, 2020 7:12 AM
Replying to Sergio Luis Conte
...
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.
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... Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Well, think the sequence in PMBoK has a simple reason. They did not want to preclude a logical sequence.
There is a table in PMBoK standard part listing all processes in their process group and knowledge area. The control or monitor process always is mentioned as the last process. So this may be a undisclosed document standard.
From the sequence in real life most what has been said is true. Scope validation is formal acceptance of the deliverables, so it is the last process before closing a project or phase. If you have for example a phase called design, the validation will approve the design deliverable early in the project life cycle. Saving Changes...
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?
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. Saving Changes...
