The Work Breakdown Structure (WBS) is a key tool for project managers. It’s the first time that you really map out in detail what you are going to be doing. It lists all the task involved in the project and gives you a very visual understanding of the scale of the work ahead. It’s also an easy tool to use and not beyond team members starting out in projects for the first time. Everyone can get on board with creating and using it.
However, it’s also surprisingly easy to spend a morning plotting out your WBS and still find that you’ve got nothing usable at the end of it. Here are 5 WBS creation problems and what you can do to make sure they don’t stop you producing a practical and useful WBS.
1. Not Knowing When To Stop
When you’re in the flow, adding a few more sticky notes here and there seems like a good idea. Everyone’s bought into the concept of the project and they’re getting excited about adding the detail. But too much detail and you’ll find yourself typing up 52 sticky notes that all say ‘run project team meeting’, one for every week of the year.
It’s important to stop working on your WBS when it gets to a suitable level. The activities described on it should feel as if they would last about a week, maybe longer if your project is running over a year or more. You don’t need to take your WBS down to a level where the activities represented only last a few hours unless your project is extremely short.
Conversely, you don’t want to stop before you get to that level. Documenting a WBS at too high a level will mean you lack the information required to put together your project schedule. It becomes a pretty diagram for your project sponsor, but not the useful work tool that it should be.
How to overcome it: The WBS is complete when the activities described on it are detailed enough to let you schedule, budget and delegate the work. Stop when you get to that level. Any more detail is a waste of time. Any less detail and you won’t be able to do the next step in the project planning process which is taking the information from here and building out your schedule.
2. Dealing With Group Dynamics
The WBS is a team activity. That means using strong facilitation skills to keep the discussion on track and everyone participating. It doesn’t take much for a quieter member of the team to feel as if they aren’t able to contribute and the knowledge that they could have brought to the discussion is therefore lost.
How to overcome it: If you feel as if you cannot facilitate the group and take part representing the function of project management, then consider bringing someone else in to keep the meeting participants on a path that doesn’t involve too much uncomfortable conflict.
The WBS is a graphical representation of the activities required on a project. It informs the project schedule but it is not the project schedule. Your WBS does not include lines that link task dependencies in time or even dates scribbled on the sticky notes themselves.
The process of putting the WBS together can derail when the conversation turns to discussing what is going to happen when. At this point all you are doing is noting down activities.
How to overcome it: Be strict with your facilitation! Stop all discussions about timings as they arise and deal with the scheduling later.
4. Talking About Deliverables
The WBS is not a list of deliverables. Much of what you do will generate a deliverable, but the actual deliverables themselves are not the focus of this document. The process of coming up with the WBS is all about the work that needs to be done (hence the name Work Breakdown Structure…).
Each item on the WBS should be a definite action. It’s a task that you can give to someone to do. It should be detailed enough for them to be able work out how long it is going to take them and what resources they need to do it, but that happens after you’ve completed the WBS. If you can’t delegate activities from your WBS, then you haven’t created a very good WBS.
How to overcome it: Watch what you write down. Each activity on the WBS should be described by a noun and a verb. Don’t write ‘user manuals’ when you mean ‘write user manuals’.
The typical WBS creation process goes like this:
- Write down as many tasks you can on sticky notes
- Stick the notes on a wall
- Move them around to create the WBS.
It will really help you to add another step here before you create the final WBS: group the activities. It doesn’t take long to put clusters of common tasks together. You can group them by department affected, stakeholder, location, phase or anything else that makes sense when you look at all the activities.
The purpose of grouping the activities before you move them into their final WBS location is to see the themes. This will save you time structuring the WBS because the large groups and sub-groups will become apparent. If you don’t spend time on this step you may find yourself moving large amount sticky notes around when you find the one task that doesn’t fit in anything else and you decide to rethink the whole structure for the fifth time.
How to overcome it: Group your sticky notes before moving them into their final locations and see what clusters emerge. Name your groups: this will help when you come to put your schedule together later and also for the structure of the WBS.
The WBS is a powerful and useful tool that done well will save you and your team a lot of time during the initial stages of a project. Avoid these 5 problems and take advantage of the time-saving and structure that a good WBS brings to a project!