The Activity

In my previous post, The WBS Basics, we developed a simple Work Breakdown Structure (WBS).  In previous posts related to this foundations series, I’ve discussed TheTask and Deliverables.  A WBS is, as previously noted, a hierarchical representation of the complete project scope.  (A list of all tasks without any organization structure would be more confusing that beneficial.)

But with a moment of consideration about the hierarchical nature of this representation, we realize that if we just have tasks at the bottom and deliverables at the top, we really haven’t improved the situation meaningfully.  With no hierarchy, a Deliverable with hundreds of tasks would be just as confusing as a project with hundreds of tasks.

Therefore, it’s easy to determine that for large projects, there could be several layers between the Deliverable and the Task, as represented by this diagram with arbitrary names for the intermediate levels.

A work breakdown structure is like an assembly Bill of Materials – it lists all of the components in the final product and shows graphically how they fit together from individual parts (Tasks), through subassemblies (Activities), to the top level assemblies (Deliverables).  And the WBS developed for project management much like the Bill of Materials developed for assembly and they serve much the same purpose.  Complex BoMs with randomly arranged layers are normal.  Likewise, there is nothing wrong with (defective about) a WBS like this and I’ve certainly seen many PMs comfortable with this (un)structure.

 

As already mentioned, large projects have many (thousands of) tasks and the hierarchical structure is needed to organize the work.  The intuitive choice for organizing the work, as a box is examined and decomposed, is to build the structure into progressively more levels, as shown above.  This is evident to most practitioners and quite obvious.

But this blog is for presenting Best Practices and I’m going to explain why an alternative, not necessarily as intuitive, is the Best Practice.  Let’s say you have a project template that you use that has four deliverables and usually takes a couple of months.  Thus, you produce a deliverable every couple of weeks.  Then you get a request for a really BIG version of this same project that will take two years.  The intuitive approach, as discussed, would be to build out detail within each box (for assemblies, what they would call exploding the BoM).  You would then have your familiar project structure with possibly several additional levels.

But do you really want to have only four deliverables over a two year period?  Do you want to “go dark” for six months at a time?  This is not a Best Practice.  All projects need frequent deliverables to get meaningful feedback on the quality of the work.  Consultancy PMs in particular benefit from frequent deliverables so that they can book the revenue.

As more deliverables are added to the WBS, it naturally flattens out so that a PM only needs a limited number of levels.  Gone are the Assemblies, Subassemblies, and Hemi-Demi-Semi-assemblies.  You can even deduce that a WBS with many layers would be a red flag to review the frequency and distribution of the deliverables.

I have run many large projects with only three hierarchies within the project:  Deliverable, Activity, and Task.  Further, unlike the example above that appears to have evolved randomly, a planned, well-structured WBS is the sign of an organized project.

Have you run a project where you didn’t have control over the WBS?  How did it turn out?