Scope Verification: The Forgotten Process

Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at andy.jordan@roffensian.com. Andy's new book Risk Management for Project Driven Organizations is now available.

The concept of the work breakdown structure is well understood by project managers, and it’s one of those tools that seems to be readily accepted and embraced by PMs regardless of industry, experience or location--it just works. And yet one of the scope management steps that can help to ensure that the WBS is as effective as possible in controlling the project’s scope is routinely ignored as unnecessary. I’m referring to scope verification, and it’s about time that it got the credit that it deserves.

Scope basics
Let’s start with the basics of scope to help understand where scope verification fits. Scope starts with scope planning and quickly (sometimes too quickly, but that’s a different article) moves on to scope definition--the process of determining what is in scope for the project, and just as importantly what isn’t. This process generates the scope statement, which is the vital driver of the WBS. To build the WBS, we take the scope statement and break it out into a number of different areas, adding greater levels of depth until we have reached the work package level that represents the lowest point in the WBS.

At this point, many (perhaps most) project managers will move forward with the next elements of project planning--sequencing tasks, developing estimates for each work package and assigning resources. At the same time, there will be formal scope control put in place that will help to identify and manage any changes to the scope. So what’s the problem? Well, there is one step missing from this that can save considerable time and effort later in the initiative…

Scope verification
Scope verification is concerned with two simple questions:

  1. Is every item in the scope statement included in the WBS?
  2. Is every item in the WBS included in the scope statement?

In other words, does the WBS accurately reflect every element of the scope, and only those elements? This is vital because it provides a process for confirming that the WBS accurately reflects the scope that has been defined, that the project structure that we have just created meets the needs of the defined initiative. This is so fundamental that it amazes me when it is ignored so frequently, but ignored it is.

ADVERTISEMENT

Trending Articles

PMXPO 2014 Schedule

10:30 a.m. ET -- PMXPO 2014 opens!
11-12:15 a.m. ET – Keynote Presentation: Unleash Your Inner Superhero by Bill Rosemann
12:15-12:35 ET – Keynote Sponsor: The Ultimate Guide to Business-Driven PMO Success by Oracle
12:35-1:00 ET – Booth Time
1:00-2:00 ET – Session 1: 2014 Redefining the PMO: Top 10 Tips for Building a PMO that Matters
2:00-2:15 -- Session Sponsor: RIght Sizing Your PMO to Maximize Business by Upland
2:15-2:30 – Booth Time
2:30-3:30 ET – Session 2: Choose Wisely: When is Agile the Right Approach?
3:30-3:45 ET – Session Sponsor: Project Management 2.0: The Future of Project Management by IIL
3:45-4:00 ET – Booth Time
4:00-5:00 ET – Session 3: Doing it Right with Project Portfolio Management
5:00-5:15 ET – Session Sponsor: How Does Technology Help You Do It Right? by Bamboo Solutions
5:15-5:30 ET – Booth Time
5:30-6:30 ET – Session 4: Hacking the Gantt: Visual Tools for Tracking Agile Work in a Waterfall Organization
6:30-6:45 ET – Booth Time
6:45-7:45 ET – Session 5: Planning IT: Scenarios, Strategies and Second-guessing
7:45-8:10 ET – Booth Time
8:10-8:20 ET – Closing Remarks: PMXPO 2013 in Review
8:30 ET – Show Closes

Topic Teasers Vol. 31: Change Rests On You!

by Barbee Davis, MA, PHR, PMP, PMI-ACP

Question: We have a massive internal change coming, and lucky me…I get to head the project! We have tried this before and had to pull back because of negative employee reactions. I know that this time we need some change management processes, too, but who is responsible to do that part of the project?
A. The good news is, it’s you. You need to take the responsibility and coordinate the change processes in with your usual team activities.
B. The good news is, it’s not you. Focus on the project and on meeting your metrics of time, cost and quality as usual. Corporate management is responsible to make sure employees accept and use these new changes.
C. The PMO is “where the buck stops” when endeavors move from simple projects to create products or software and billow out to vague objectives like “employee acceptance” and “corporate compliance”..
D. Ask your manager. Your project charter is limited to producing the usual product or services and your team is not skilled or experienced in change management processes. Your manager can deal with getting the changes accepted and getting them to stick.
Pick your answer then Test Your Knowledge!

Portfolio Management: The Last Resort of the Powerless

by Mark Mullaly, PMP

The advocates for the implementation of portfolio management are dissatisfied with how decisions are currently being made. They wish to bring about a change to this decision process. They are not, therefore, likely to have much influence in how decisions are currently being made. What to do about this conundrum?

The verification process is fairly straightforward and involves a step-by-step review of both the WBS and the scope statement. It’s good practice to use a numbering convention for both the scope statement and the WBS, and while it’s pretty much standard practice for the WBS it doesn’t always happen in the scope statement. If you can encourage your organization to adopt a numbering convention for scope, it makes verification easier.

I always start with the scope statement itself and will take each section of the scope and identify the elements of the WBS that specifically address that scope item. This is simply mapping the WBS item numbers for work that supports that item to the scope document. We are looking to confirm that every scope item has WBS work mapped to it, and that collectively those WBS items accomplish the defined scope element--in other words, that nothing has been missed.

The second step is to repeat the process for each WBS item, this time mapping each WBS element to one or more scope items (you can see why a numbering convention on the scope helps) that the WBS element maps to. The goal here is to ensure that every piece of the WBS maps to at least one scope item--that none of the work in the WBS is superfluous. These two simple steps deliver tremendous benefit by ensuring alignment between the scope and the WBS. From the outset, they act as an early warning system for any issues that might otherwise not become apparent until much later in project execution, when the costs to correct are higher and the impact more severe.

Conclusion
Scope and WBS definition are two areas of project management that have improved considerably in the last decade or so as people have recognized the importance of clearly defining what is required and how that work will be structured. At the same time, projects continue to experience problems around scope uncertainty or changes to the project structure part way through the execution of the work. The simple and quick step of incorporating scope verification within your project isn’t a surefire way to eliminate all of these issues, but it will reduce the number and severity of the issues--and that’s never a bad thing.

Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at andy.jordan@roffensian.com. Andy is also on Twitter at RoffensianPM.


Related Content

comments

Network:6



This is correct Andy. Very often it happens to miss the scope verification process in both directions Scope Statement->WBS and WBS->Scope Statement. I see it several time happening in IT projects where requirements are very fuzzy and in scope/out of scope is really border line. Without the scope verification phase you can notice something going wrong when it is too late. Good article !!!

ADVERTISEMENTS

"Maybe this world is another planet's hell."

- Aldous Huxley

ADVERTISEMENT

Sponsors