Scope verification is defined in the PMBOK as “the process of obtaining the stakeholders’ formal acceptance of the completed project scope and associated deliverables.”
I’ve been thinking about this process recently, and would like to share a few thoughts on the matter. When you start thinking about the details for how this will work on a project, some questions arise.
What is scope verification anyway? Are we only making sure that specified deliverables have been completed? Often, the related but seperate activity of quality control is confused with scope verification. Quality control should be a check before scope is signed off as complete, but that process should measure quality against the quality baseline established at the onset.
Scope verification has to be written. Otherwise, it’s not really scope verification. A status meeting where you talk about the state of the project is a status meeting, not scope verification. Even if you list accomplishments, there needs to be a formal sign-off. Otherwise, what’s to stop the stakeholder from coming back in 6 months to revisit something and say they didn’t like it?
No related posts.
{ 4 comments… read them below or add one }
Josh I think this is a real tricky part of the PMBOK and an area ripe for improvement.
Verification is an important thing for any plan, and also in achieving a final sign-off to close the project, but what is it you are asking people to verify?
Are you focusing on the scope of work activity or the scope of the outcomes. Different PMs can focus on this issue differently, and so can stakeholders. In general stakeholders are probably more interested in outcomes that your processes (except as far as the time and budget go.)
So usually your stakeholders are expecting you to be asking them to agree that you delivered what you set out to deliver; the new product, system, process, etc.
In fact most PMs seem to focus on “we did the activities we said we would.”
Given that projects are largely about unveiling uncertainty they always have to adapt their work plan to accommodate the unexpected. Working to plan is almost a guarantee of failure in the context of delivery of outcomes.
It’s a critical misalignment at a critical point in the project.
Josh I think this is a real tricky part of the PMBOK and an area ripe for improvement.Verification is an important thing for any plan, and also in achieving a final sign-off to close the project, but what is it you are asking people to verify?Are you focusing on the scope of work activity or the scope of the outcomes. Different PMs can focus on this issue differently, and so can stakeholders. In general stakeholders are probably more interested in outcomes that your processes (except as far as the time and budget go.)So usually your stakeholders are expecting you to be asking them to agree that you delivered what you set out to deliver; the new product, system, process, etc.In fact most PMs seem to focus on “we did the activities we said we would.”Given that projects are largely about unveiling uncertainty they always have to adapt their work plan to accommodate the unexpected. Working to plan is almost a guarantee of failure in the context of delivery of outcomes.It’s a critical misalignment at a critical point in the project.
Josh,
If you’re using an Agile method for delivery, then scope is reviewed with the business at the start of each iteration. The people from the business are able to change what will be worked on and in what order, with the input from the development team on how much they are able to deliver in that iteration. If the business wants to add functionality owing to changed priorities, then something already scheduled must be bumped to a later iteration. Similarly, if the business wants to change something and it affects the time required to deliver that functionality, then something has to give.
From a release perspective, the business also determines what is the minimum set of features that it makes sense to deliver. Development determines how long it will take to deliver those features.
This constant monitoring and re-evaluation allows scope to be effectively managed. It requires, though, a true partnership between development and the business. There can’t be an attitude from the business of “asking for the stars so that we’ll get the moon”. There also can’t be an attitude from development of “we’ll try” when faced with unrealistic scope and schedule demands.
In a nutshell, true scope management is about “getting real” and continuously re-evaluation what “real” is!
Regards,
Dave Rooney
Mayford Technologies
Josh,
If you’re using an Agile method for delivery, then scope is reviewed with the business at the start of each iteration. The people from the business are able to change what will be worked on and in what order, with the input from the development team on how much they are able to deliver in that iteration. If the business wants to add functionality owing to changed priorities, then something already scheduled must be bumped to a later iteration. Similarly, if the business wants to change something and it affects the time required to deliver that functionality, then something has to give.
From a release perspective, the business also determines what is the minimum set of features that it makes sense to deliver. Development determines how long it will take to deliver those features.
This constant monitoring and re-evaluation allows scope to be effectively managed. It requires, though, a true partnership between development and the business. There can’t be an attitude from the business of “asking for the stars so that we’ll get the moon”. There also can’t be an attitude from development of “we’ll try” when faced with unrealistic scope and schedule demands.
In a nutshell, true scope management is about “getting real” and continuously re-evaluation what “real” is!
Regards,
Dave Rooney
Mayford Technologies