I was at a PMI chapter event last week and the presenter asked how many people in the room had heard the term work breakdown structure. Only about a 3rd of the hands went up. I have to admit I was surprised at how many people hadn’t heard of it, we were all project managers after all. I did wonder, though, of the third who had heard of it, how many had used it.
When I started in project management, I had to do a lot of research on the terminology, tools, and processes. I came into it from line management and so a lot there were a lot of techniques that I didn’t understand, both what it was and why it was useful. It didn’t take me long to learn what a WBS was, but it did take me a few years to understand the value, and then even more time to really understand how to lead people through the process.
Let’s start with what a WBS is all about. It’s the process of identifying the work that needs to be done at a level that can be managed – the work package. It looks like an organization chart of your project, and that’s more or less what it is.
Here’s a simple representation of a PMO development project (ah, if it was only this easy).
WBS for a PMO
The project team and any stakeholders who have an understanding of what it will take to get it done create it. I generally start with a brainstorming session to identify the work packages and then group them together. Until we have a structure that captures the right grouping. The right grouping? – that depends on your project. You may want the first layer to be phases, or major deliverables, or something that relates to your organization. The important aspect of this level is that it forms the groups. Then each layer below will logically fit into the group. In the example, the top row is phases, and the next row is work that fits into that phase. You can see from the example that the bottom row is not consistent in each group. The work package is the lowest level, whether that’s one or ten layers down.
A work package is a group of tasks that have one logical leader and result in a deliverable. As the PM, you manage at the work package level and you may want to limit the length of the work package to allow you control. For instance, if you have a three-month project, any work package over 2 weeks in duration can get behind without you knowing. How do you know when you’ve got it all? One thing to remember – if it’s not on the WBS it’s not in scope. So, check the scope statement to see if everything is listed. What will also happen is new scope will appear as you and the team develop the WBS, if you work to get clarity on the details of the new information, you’ll capture the full extent of the new scope.
What’s the process after you have created the WBS? You need to review the scope with your sponsor to get approval for anything new. You need to work with the work package leaders to develop the estimates for duration and resources. As the PM, you need to pull the WBS into a project schedule and add dependencies and milestones. Here’s the Gantt of the WBS with dependencies.
Gantt from WBS for PMO development
The question that usually comes up about here is why can’t I just do this in MsProject, or other software? I wondered that myself. There are 3 benefits to creating the graphic.
For your stakeholders and team – it is reassuring for them to see the project scope laid out this way. It is easy to see what’s included in this format.
For you as the PM – it will remove the temptation to put every detail into the plan. Each work package has a whole list of activities that the work package leader will coordinate and you manage a shorter list of deliverables and milestones. I was able to reduce a 1200 line merger project to 160 work packages. I could manage that because I didn’t need updating on the small details of a deliverable.
For everyone’s peace of mind – creating a WBS is not done linearly, it is a brainstorming session. That means you are less likely to forget a steam of work because you are following a deliverable through its logical process.
There are a few tools I’ve discovered that will help with the process.
For the meeting to develop the work packages – Post It notes are great. Numbering the notes and entering them into the Gantt chart by hand is a good manual process.
Using MsProject with Visio. You can link from the Gantt to a Visio WBS. It’s static and you work only from Project to Visio.
Using MsProject with WBS Chartpro. WBS Chartpro is the tool I used to create the graphic. It allows you to work back and forth between Chartpro and Project.
Tip of the week try a WBS session for your project.
