Creating a Project Work Breakdown Structure

How do you develop a Project Work Breakdown Structure (WBS) and why?

Why is a Work Breakdown Structure important? When your project is first defined, it's defined in terms of goals and objectives. Once you get down to defining deliverables with materials, labor, and task definitions, you can create the project work breakdown structure to define the workload in enough detail to predict costs and resource requirements.

Start with a clear statement of the project scope. With this, you can begin planning how your project is going to produce the results and deliverables. You'll need to create a work breakdown structure (WBS), a tool used for categorizing the work to be performed and the precursor to building a scheduled task list. There are three commonly used approaches for building the task schedule. 

You'll use your project work breakdown structure to group the tasks logically either by work category, by deliverable, by time phase, or some other grouping so that they can be managed more effectively.

Using a Categories Focus. Think of the tasks as a hierarchy that if diagrammed would look like an outline or an organization chart. The major task categories are on top at the first level, with each broken down into sub-tasks and sub-sub-tasks until a level is reached where the work can be assigned to individuals. This approach is most often used where the work requirements are well-known and have been used before on similar projects.

One example is when a software reseller implements a new off-the-shelf software system that is pre-written, but that may need some configuration or customization. The work breakdown structure might start off like the one below. Bold Items will become Tasks on the schedule.

Using a Deliverables Focus. Another way is to think of the deliverables that must be produced for each objective. Remember, the objective may suggest one or more deliverables, events or results. If you list these first in the order that they'll be delivered, then for each deliverable, decide what work and how much effort is needed to produce it, you'll have the breakdown of one or more jobs or tasks. Your major categories then become: Produce deliverable No. 1, Produce deliverable No.2, and so on. You would use this approach when the requirements are clearly defined in terms of results, but the tasks are not immediately obvious.

Brainstorming

Decide how you want to Represent you Work Breakdown Structure. Once you've developed your work breakdown structure (WBS) you'll need to decide how you want to present it. You can use the outline format or the organization chart format. Other layouts less commonly used include the Bubble chart format or the Mind map layout.

In any case you'll need to label the elements of the WBS consistently. The most commonly used labeling scheme is the structured number format. It appears in the form: Level ID (.) Component ID  An example in outline layout is shown below.

The Org chart format can also be used. Some find it easier to work with but it does take up a lot more display space. An example is shown below. Blue Items become tasks on the schedule

Work Breadown Structure in Orgchart Format

Keep your team involved. You want to make sure the WBS is accurate and clearly describes the task breakdown. Further, you want to be sure that your project team and stake holders agree with the breakdown.  If you have WBS data from an earlier, similar project, use that as a guide. Do anything you can to be as comprehensive and as accurate as possible.

Remember that with your project work breakdown structure, what you have now is just a list of tasks broken down into manageable segments. Your next step is to estimate and plan the work and build the task schedule.

Getting the terminology right. The term work breakdown structure is sometimes listed in project plans as a work structure breakdown -- this is incorrect. A work breakdown structure is a process of decomposing a large body of work into small, measurable tasks. A work structure breakdown is a tool used to define the allocation of a workflow across functional units, a completely different concept.

- Jake Alexander