Understanding the project scope is one of the key things that leads to success in the project later on. After all, if you don’t know what you are supposed to deliver, you can’t deliver it! The Work Breakdown Structure (WBS) is a tool that we teach on our project management training courses to help teams understand what work is required to get the project done. You might also come across product breakdown structures, that describe the deliverables needed on the project.
Putting the WBS together should be a team effort. Get the core project team in a room together and start decomposing the work into smaller and smaller components. Together, you should be able to work out what needs to be done, although if you have to park something and get more subject matter expert input, that’s fine too. It’s better that the diagram is correct, even if that takes another round of review and edit.
However, something we’ve seen from time to time is teams spending a lot of effort on the WBS and still ending up with something that isn’t the practical, helpful document it should be. Here are five reasons why that might happen and what you can do to put them right.
1. Trying to sequence the work
Sometimes teams get caught up in the discussions and end up trying to sequence the work. People add arrows to the WBS, or start to map out the order of tasks on a different sheet, or in a note-taking tool, or even writing dates on the sticky notes as you put them up on the wall.
This is a hard one, because ultimately the WBS is an input to your project schedule. You will be using it to help you with sequencing tasks… just not right now.
Fix it by: Don’t let teams talk about task sequencing. This is a facilitation issue. Be strict on the purpose of the session and park any discussions about the order of work.
2. Going into too much detail
The amount of detail needed in your WBS is a judgement call. Too many levels and you’ll end up with work packages for every review meeting.
A common rule of thumb is that you want the last level of decomposition to be a work package you could hand off to a workstream or team leader. They’d know what to do, and the work itself would standalone. If you don’t know where to start, try getting your WBS down to where the final level is activities that will take about a week. That’s good for when you come on to scheduling.
Fix it by: Strong facilitation (again). Don’t let people decompose the work beyond the level that makes sense for the team and the schedule.
3. Not going into enough detail
If going into too much detail causes problems, so does not having enough detail on the WBS.
The point of the WBS is to give you a head start with the project schedule. You’ve documented the work that needs to be done, and now you can create a timeline for the tasks. But if you haven’t got enough detail about the tasks, your plan will be full of activities like ‘Build product’.
Too little detail and you won’t be able to schedule or estimate the work effectively.
Fix it by: Ask questions to get deeper into the structure if the team is stuck and not decomposing enough.
There’s a good degree of professional judgement when it comes to getting the level exactly right. That’s why it’s helpful to have training in how to produce a WBS and perhaps an external facilitator in the room to help keep everyone on track.
4. Not sticking to tasks
A product breakdown structure is something different, and we’re going to assume that’s not what you need to create. You can’t schedule from a list of deliverables, at least, not as easily as you can from a breakdown of task elements. So make sure the conversation and planning sticks to activities.
The easiest way to do this is to make sure the description of each WBS element starts with a verb. ‘Develop homepage’ is a task. ‘Homepage’ is a deliverable.
This might feel like a small distinction, and as your team gets better at doing WBS creation, you may slip into shorthand, and use ‘homepage’ when you really mean ‘design, develop and test homepage’. If everyone knows what you are talking about, and that tasks are being referred to, then you can accept it. However, make sure that there genuinely is that clarity, and you don’t end up with a WBS with a mix of phrasing: some activities listed and the rest being deliverables.
Fix it by: Make sure the facilitator gets clarity on what is written on a sticky note or on a WBS block. Remind people how to phrase activities. Set expectations about the WBS, with a clear introduction about what it is and what you are trying to achieve in the session. Provide examples of previous WBS from other projects so the team can see how it is put together.
5. Letting strong voices dominate
Putting together a WBS is not a one-person job. You need the subject matter expertise from the whole group in order to truly decompose the work into relevant elements. What you think of as a simple task might breakdown into three or four elements for the person doing the work. Let them decide how it should be represented on the structure.
The challenge comes when you have a couple of strong voices in the session. These are people who dominate the discussion, and don’t let others speak.
Fix it by: Use your facilitation skills to make sure everyone has a chance to contribute. If you think that won’t happen – perhaps because you’ve got senior executives in the room and no one wants to be seen contradicting them – then consider having a couple of sessions with different groups and combining the results for everyone to see and comment on.
An external facilitator can also help, especially if you expect there to be conflict in the room. Often people behave differently when there is a third-party present!
A WBS can be a very useful tool to kickstart your project planning, but it needs to be useful, and also a good use of everyone’s time. Watch out for these challenges and create a WBS that becomes a practical tool for the team to schedule the work.