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…
Scope Verification: The Forgotten Process
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.
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 is concerned with two simple questions:
- Is every item in the scope statement included in the WBS?
- 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.
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.
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 firstname.lastname@example.org. Andy is also on Twitter at RoffensianPM.
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 !!!