The validate scope process, in its simplest form, is the formalized acceptance of project deliverables. Scope validation is sometimes confused with other processes:
- it is not verification, which is better understood as an evaluation of whether the deliverable complies with project specifications;
- it is not an opportunity to include additional scope, though many end-user reviewers often attempt to do so;
- it is not the acceptance of what will be included in the scope (that was established in the Define Scope activity of the planning process).
Put succinctly, scope validation ensures that the deliverable meets the needs of the customer and complies with the project specifications for that deliverable. It is conducted by the client organization. The deliverable is either formally rejected or accepted based on the client’s review findings.
A rejected deliverable requires formal notice of the defects that must be resolved. An accepted requires formal sign off by an authorized stakeholder to help ensure compliance with the statement of work and to allow the project to proceed.
The validate scope activities are part of the Monitoring and Controlling process group. They are the culmination of many of the activities in other process groups. As such, scope validation activities should be conducted frequently throughout the project, and not left to the end of the phase or the project.
For large deliverables (e.g. Requirements deliverable(s), Design deliverable(s), and others), it is good practice to conduct informal scope validations as the deliverables are being developed. It is not uncommon for reviewers to reject large and complex deliverables for issues that could have been easily caught during the activities that created them. For activities that span several months, such rejection at the end of the process can be disastrous for timelines and budgets.
Scope validation begins with planning
Scope validation can be a very successful process if planned from the outset. It really begins in the Planning process, not when the deliverable is submitted for formal review and acceptance. In fact, scope validation is the end result of the several preceding, integrated project activities:
- Develop Project Management Plan – One of the essential components of the Project Management Plan is the Scope Management Plan. This sub-plan details how project scope will be managed throughout the project, including how it will be defined, developed, monitored, controlled, and validated.
- Plan Stakeholder Engagement – Additionally, the Stakeholder Engagement Plan identifies the primary stakeholders who are responsible for deliverables review and deliverables acceptance.
- Plan Communications Management – The planning of project communication establishes formal and informal communication processes, meeting types and cadence, media usage, distribution lists and channels, and other aspects of communication. The intent is to prevent miscommunication and misunderstanding throughout the project.
Communication regarding scope validation is essential
What if the deliverable is rejected? How will that be communicated? What if the deliverable is not rejected, but has serious defects? How will its correction and update occur? What if the deliverable reviewers request changes? How will such requests be handled?
The planning of communication management early in the project allows the Project Manager and his or her team manage client expectations throughout the project. For example, detailed processes that communicate how to handle questions such as those above will prevent many of the issues that can stall a project during scope validation.
- Collect Requirements/Define Scope – Requirements gathering is the core activity in any IT project. Get these right and the rest of the project will typically proceed smoothly. All deliverables that follow the approved statement of requirements will reference back to the requirements. Many, if not all, subsequent deliverables will be validated based on their adherence to the approved requirements and project scope.
- Direct and Manage Project Work – This is the set of activities where the project requirements are transformed into a working system. Each deliverable within this body of work must be true to the requirements. Each must be accepted if the project is to proceed according to plan. Each is a steppingstone to the final implemented system.
- Monitor and Control Project Work – These activities go hand-in-hand with Direct and Manage Project Work. It is prudent to establish informal scope reviews with the client staff on the project during this process to help ensure that the requirements are being met correctly and completely. Misunderstandings and miscommunications can be caught and corrected early rather than waiting until the formal validation process at the end of the phase. These periodic informal walk-throughs increase the likelihood that the formal validation will result in acceptance.
- Control Quality – The quality control process is often confused with the scope validation process. However, quality control precedes scope validation (or at least conducted in parallel). Deliverables are first verified through the project team’s quality control process before being submitted for validation by the client’s scope review and acceptance process. (More on this in the weeks to come.)
- Perform Integrated Change Control – The question was asked earlier: what if the deliverables reviewers request changes? The reviewers should not be discouraged from requesting changes. They now are able to review the entire deliverable that one time. Seeing the deliverable as a whole, rather than in parts, often prompts the reviewer to add or change requirements. Not to worry – the project will have a formal process to handle change control.
And finally, Validate Scope! Validate scope does not exist without the preceding activities. Nor can it proceed smoothly unless these activities are well-defined, well-planned, and well-executed. This process helps improve the final product through the formal review and approval of project deliverables.
While this article seems to focus on process, it in fact is very much concerned with the people aspects of project delivery. So many of the activities that precede the deliverables review and acceptance (i.e. scope validation) exist to enhance team members’ productivity on the project.
After all, why do we formalize communication?
Why do we request periodic informal deliverables reviews? Why do we prepare detailed documentation of the deliverables review process? Because project work is people working, and people work best when processes are put in place to eliminate ambiguity and help them succeed.
The validate scope process provides the client (and the project team) with visible evidence that the project is on track. Or, if not on track, it provides them with an indication of how to manage the problem. Accepted deliverables provide satisfaction that the project is progressing well. Deliverables sent back to the project team for correction provide satisfaction that defects were caught early.
Often changes or issues are found during the validation process. This is preferable to (and much less costly) to being surprised by problems at the end of the project. Scope issues can then be corrected quickly before their effects are propagated to the end product.
Simply put, the validate scope process is the formalized acceptance of project deliverables. But for scope validation (i.e. deliverables acceptance) to be successful, it must rely on excellent execution of the many upstream activities.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.