The work breakdown structure is one of the most important project management tools you have as a project manager. It’s the foundation for estimating, budgeting, sequencing and scheduling of activities, reporting, and controlling a project. In short, it’s the basis for nearly everything that goes on in project planning.

A work breakdown structure isn’t a static document—you’ll continue to refine and revise it along the way—but it serves as a consistent, general structure for moving forward so it’s important that you do it well. And while there’s no one right way to do it, there are some common traps you should avoid.

Breaking it Down

You‘re probably aware of the technique of decomposition, which is used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. Here’s how decomposition typically plays out in the work breakdown structure.

On projects that are familiar and have a consistent methodology for completing them, the first level of the work breakdown structure is segmented into phases, and each phase has a set of associated deliverables.

For less familiar projects, the first level will be the deliverables, and then each deliverable will be broken down into smaller sub-deliverables. This decomposition continues, with sub-deliverables broken down into smaller sub deliverables, until you reach the stage where breaking it down any further wouldn’t deliver any additional benefit.

This is the pivotal point at which the work breakdown structure switches from sub-deliverables to the workflow required to produce the sub-deliverable. This workflow will be comprised of activities that will have resources assigned to them, durations determined, and sequencing established.

Creating a Work Breakdown Structure: Part Science, Part Art

But how do you know when you’ve reached that point?

Well, there’s no set formula. Determining this level of decomposition is an art. But it’s important to find the right balance. Break it down into sub-deliverables that are too small, and it becomes almost too difficult to describe them. Switch to the workflow too early, and you can end up with a 500-step process.

As an example, let’s say a house is the deliverable that needs to be produced. A house can be broken down into smaller sub-deliverables such as wall and roof framing, plumbing, electrical, sheetrock, roofing, and fixtures.

Electrical can be broken down into the breaker panel and rooms. Rooms can be broken down into lights and outlets. Outlets can be broken down into sides of the wall.

But wait a minute. We’ve crossed the line of value. We could have stopped at rooms and started our workflow there, with activities such as: purchase components, install breaker panel, install lights and outlets on first floor, install lights and outlets on second level, and test all lights and outlets.

Breaking it down too much is one of the most common traps in a creating a work breakdown structure. As a project manager, it’s your job to recognize when the decomposition has lost its purpose and doesn’t provide any additional benefit.

Using Work Breakdown Structure Templates

The good news is, many projects will be familiar to the organization, and those often have a work breakdown structure template that either a person or a committee within the department already created. Because this template will contain all of the deliverables, sub-deliverables, and activities that are typically part of the project, it’s a great shortcut and time saver. All you’ll need to do is customize it to your specific project.

But when you don’t have a work breakdown structure template to start with, the art of finding the balance between decomposing sub-deliverables and creating a workflow that makes sense comes down to you.

It’s important to note—and as you saw in our house example—when you describe deliverables and sub-deliverables, the names are often nouns. Workflow activities, on the other hand, are named with verbs and nouns. They describe action. They’re the point where things get done.

So, as you’re trying to determine where that switch should happen, ask yourself: have I gotten detailed enough in the sub-deliverables to describe for someone else what they’re supposed to do so they can be sure to do it right?