It’s time for part 4 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, we’re looking at the Create WBS process.
You can find the previous parts here:
The point of this process is to move from having the scope statement (from the Define Scope process) to a scope baseline. The Work Breakdown Structure (the WBS of the process name) gives you the baseline for what the project is going to create. It’s scope, but in a lot more detail than a scope statement.
Personally, I don’t often use the full WBS process. If you are on a small project, or leading a project where you have done similar work in the past and are working with an experienced team, or you have a scope that isn’t easy to button down, then approach the WBS process with an open mind. I have lost too much time in the past creating a full WBS and WBS dictionary, with lovely descriptions of everything, only to find that the next week the scope changes due to the whim of senior management, and all my work is rendered pointless. So this is definitely a process where tailoring comes into play, especially if your ‘predictive’ environment isn’t really that predictive!
You need a scope baseline in order to exercise change control, but you might not need to follow this process to the letter to get it. Just sayin’.
Create WBS Process
This is the fourth process in the Knowledge Area. We are still in the Planning process group.
While I might not use the full WBS process and terminology, the overall objective of this process is to break down the work into smaller components that are more manageable to deliver. You take your scope statement and basically turn it into chunks of work that people can actually do.
This is a process you can do at various points in the project so you might not be able to decompose everything at the beginning and that’s fine. Repeat the decomposition effort as you move through the project and more scope is known, or you find out you have to break it down further to get where you want to be.
There isn’t much that has changed from the Fifth Edition with this process, and in fact the only small changes are here with the inputs. The inputs to this process are:
- Project management plan – instead of the scope management plan (the same change as we saw in the Define Scope process).
- Project documents – these were also added to the Define Scope process, and here replace the project scope statement and requirements documentation, which are now out. We’ve seen this trend towards more generic terminology across the whole Fifth-to-Sixth rewrite, and it is to be welcomed. While the scope statement, for example, is no longer specifically mentioned, you would want to refer to it (obviously). However, there’s now the explicit understanding that there might be other documents beyond the requirements documentation and scope statement that could be useful to you at this point.
- Enterprise environmental factors – no change here, it was on the list before.
- Organisational process assets – again, this was previously on the list so isn’t a change.
Tools & Techniques
Nothing has changed with the Tools and Techniques. The list still remains:
- Expert judgment
Although if you want to get picky I think they were listed in the other order in the Fifth Edition. Frankly, I don’t think the order of techniques matters much. I have never thought they were listed in priority order.
Once again, there are no new or changed outputs to this process.
You still end up with the scope baseline, which was the ultimate goal of doing the WBS and ‘project documents updates’, which is so broad it could include anything. However, it’s really talking about updating any documents that need a reference to the final scope.
People often think of the WBS as a diagram, but it’s much more than that. The graphic is useful, but on larger projects they can get so complicated they are difficult to interpret. Also, I’m not a visual thinker – I expect that’s another reason why me and the WBS have never really got on.
The scope baseline includes:
The scope statement – you probably won’t need to amend this much from previously, but you might want to check it over as you work through the detail of the scope, to make sure it remains consistent.
- The WBS
- The work packages
- The planning packages, if you need to describe work without schedules (because the work package should have schedule information in)
- The WBS dictionary – a summary of all the work packages so you can easily reference them.
I do like the idea of work packages, and I do use this concept on my projects. If the language of work package isn’t understood, I create a terms of reference which covers the same main elements as a work package, and this can go to workstream leaders.
Next time I’ll be looking at the fourth process in this Knowledge Area: Validate Scope.
Pin for later reading: