\Pet Project Peeve On

Please stop including tasks in your WBS

First, a disclaimer: there are indeed situations, industries, and projects in which a task-based work breakdown structure is appropriate. Second disclaimer: I hate those projects, indeed.

Look, a WBS is supposed to define the scope of a project. The deliverables. Scope are the products, services, or results that are created or provided during the project. Note that I didn’t say “tasks” or “activities.” Instead, we’re talking about deliverables, period. Nouns. In contrast, tasks and activities are verbs, the type of things that belong in your schedule. Not your WBS.

Of course, these things don’t live in little standalone silos. There is an inherent relationship between scope and tasks (and costs, too) that you should know. These are shown in the simple diagram below. 

The Bottom Line:

• We always, always, always start with scope. What are we going to build, create, provide, or deliver on the project? These are the project nouns that belong in a WBS.

• Then we assign some agreed-up acceptance criteria to that scope. A/k/a “quality.” These include requirements like form, fit, function, performance, safety, accessibility, yada, yada, yada…

• Then, after defining the deliverables, and how good those deliverables have to be, can we create a schedule built around acquiring those things.

• And then—and only then—can we estimate the cost of all of this. 

Keep your tasks and activities in the schedule, where they belong, not in your WBS.

\Pet Project Peeve Off.