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

Debunking Myths about Product Managers

by Ken Whitaker

Project teams quite often assume that the product manager is a true partner--and when a project is under scrutiny or stress, the product manager can transform into a very tough adversary and oftentimes a combative stakeholder. Put yourself in a product manager’s shoes for a change! Let’s explore a couple of myths about product managers that should hopefully spark a new level of collaboration and success…

The Economics of Compassion in the New Economy

by Mike Griffiths

Being nice is not a courtesy or even a basis for competitive advantage anymore. In today’s connected workplace with a less loyal and more mobile workforce, the economics of compassion are very real. See what smart companies are doing to recruit and retain the best talent.

Topic Teasers Vol. 42: Persona Problems

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

Question: We are creating personas for our projects just as we were taught in our agile classes. However, the end products aren’t selling as well as the earlier version. To be honest, people seem to be boycotting them or changing brands. I just don’t understand the disconnect between what we are developing and what the customers appear to want once it is released.
A. Customers are fickle, so it may have nothing to do with the product you have created. If you used the agile team steps as shown on the Agile Alliance website, just keep doing what you are doing.
B. Perhaps you are working your agile processes in good faith, but creating the wrong personas for whom to design your product. Find a more realistic way to model what the real customer wants.
C. Your product owner is the person who is responsible for setting out the features for new or upgraded products and deciding which ones should be included with any release to the marketplace. Just worry about your team metrics and leave the business decisions to those with more power than you.
D. Personas have proven to be an unsuccessful way to ascertain what customers want. Create databases to capture customer feedback on service calls and set a person to spend full-time scanning social media sites for comments or suggestions about your products. Include each customer suggestion in the next update of that item.
Pick your answer then Test Your Knowledge!

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

If you haven't got anything nice to say about anybody, come sit next to me.

- Alice Roosevelt Longworth

ADVERTISEMENT

Sponsors