"Validation" is ensuring the requirements are complete and correct. When you validate scope, you are ensuring that you have properly defined the extents of the project with sufficient detail to execute it. (Have we adequately defined the expectations of the project?)
When accepting a deliverable you "verify" that the deliverable meets the specified requirements for the deliverable. (Do the project deliverables meet the defined expectations?) Saving Changes...
Validation of scope is usually done internal to the team whereas deliverable acceptance is a formal acceptance by the customer of the product or service.
...
1 reply by Keith Novak
Apr 24, 2019 5:34 PM
Keith Novak
...
I would certainly hope that the customer is in agreement that the scope is correct.
Validation of scope is usually done internal to the team whereas deliverable acceptance is a formal acceptance by the customer of the product or service.
I would certainly hope that the customer is in agreement that the scope is correct. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Validate Scope is made on deliverables after Control Quality is performed (see page 131 on PMBOK). When deliverables are validated and accepted in Validate Scope you can close a phase or close the project. So, there is no difference. You always have accepted deliverables after performing Validate Scope and depending on the point into your project life cycle you can close a phase or close the project. Saving Changes...
I stand corrected. I checked the PMBoK and they only have Validate Scope at the end of the project, and have nothing I can find that validates the scope is correct before embarking on the project.
That is a major omission as far as I'm concerned. I don't see how you can have a process for how the scope will be approved and maintained without including validation that it is complete and correct first.
...
2 replies by Sergio Luis Conte and Thomas Walenta
Apr 25, 2019 8:03 AM
Thomas Walenta
...
Keith,
the PMBoK provides for approving the scope baseline, which is developed during project planning by the project. Some organization split the project into a design pre-project and a implementation project, but I found that creates other issues, e.g. if people change.
The scope baseline is seen as the promise of the project team, not something that has been developed outside. The input the project team needs are requirements, they are gathered from stakeholders and selected by the project team. Not all requirements can be considered in the scope, as some will contradict each other and in sum they may not be balanced out within the given constraints of cost and schedule.
So the sequence is stakeholders requirements scope deliverables
Apr 25, 2019 9:47 AM
Sergio Luis Conte
...
@Keith please let me comment something about your comment. Perhaps I did not understand your post but when you wrote "I checked the PMBoK and they only have Validate Scope at the end of the project," remember that PMBOK do not follow a sequence because the sequence is defined when the project life cycle is defined. So, validate scope can be done fom the very begining you have defined the project scope. In fact, the best practice is to do that before the project exists. Obviously, if you follow the PMBOK you will not find that. But if you take documention about business analysis you will find that a high level project scope is included inside the Business Case (at least as best practice). On the other side, if you take PRINCE2 (i know, is not PMI) those activities are included as pre-project activities which in the dynamic of PMI are done by the business analyst working in collaboration with the project manager.
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Validate scope is concerned with the deliverables, and there may be multiple in one project or phase. The term might be confusing because the process does not validate the scope but validates that the deliverables meet requirements and acceptance criteria as laid out in the scope statement. Change requests may occur. It can be done multiple times during a project/phase. The deliverables should be verified before they are validated, this means they are tested and considered correct - this is done by the control quality process.
Close project/phase is concerned with all deliverables as a package, the final product. No change requests are expected. It is done normally once per project/phase, as the last process.
Both validate scope and close project require customer signoff, so both are external.
In Scrum, the sprint product increment accepted by the PO during sprint review would be like a scope validation. The acceptance of a final product or release by the PO after a series of sprints would be the close process. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Apr 24, 2019 8:17 PM
Replying to Keith Novak
...
Interesting!
I stand corrected. I checked the PMBoK and they only have Validate Scope at the end of the project, and have nothing I can find that validates the scope is correct before embarking on the project.
That is a major omission as far as I'm concerned. I don't see how you can have a process for how the scope will be approved and maintained without including validation that it is complete and correct first.
Keith,
the PMBoK provides for approving the scope baseline, which is developed during project planning by the project. Some organization split the project into a design pre-project and a implementation project, but I found that creates other issues, e.g. if people change.
The scope baseline is seen as the promise of the project team, not something that has been developed outside. The input the project team needs are requirements, they are gathered from stakeholders and selected by the project team. Not all requirements can be considered in the scope, as some will contradict each other and in sum they may not be balanced out within the given constraints of cost and schedule.
So the sequence is stakeholders requirements scope deliverables Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 24, 2019 8:17 PM
Replying to Keith Novak
...
Interesting!
I stand corrected. I checked the PMBoK and they only have Validate Scope at the end of the project, and have nothing I can find that validates the scope is correct before embarking on the project.
That is a major omission as far as I'm concerned. I don't see how you can have a process for how the scope will be approved and maintained without including validation that it is complete and correct first.
@Keith please let me comment something about your comment. Perhaps I did not understand your post but when you wrote "I checked the PMBoK and they only have Validate Scope at the end of the project," remember that PMBOK do not follow a sequence because the sequence is defined when the project life cycle is defined. So, validate scope can be done fom the very begining you have defined the project scope. In fact, the best practice is to do that before the project exists. Obviously, if you follow the PMBOK you will not find that. But if you take documention about business analysis you will find that a high level project scope is included inside the Business Case (at least as best practice). On the other side, if you take PRINCE2 (i know, is not PMI) those activities are included as pre-project activities which in the dynamic of PMI are done by the business analyst working in collaboration with the project manager. Saving Changes...
Alfred HortonCEO & President| AOC Connect, LLCLovettsville, Va, United States
A very similar task, but Validation is more of an internal process whereas the acceptance process is more external or customer driven. Saving Changes...
