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?

The WBS Basics

In the WBS, use nouns for deliverables and work packages;  use verbs to name tasks.

-          Danu M. Kothari, Managing Successful IT Projects with the basic “Tools of the Trade,” PMI ISSIG Webinar, July 20, 2006

I have talked about TheTask and Deliverables.  We now have the background to drill into the Work Breakdown Structure (WBS).  The WBS is a “deliverable- oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.  It organizes and defines the total scope of the project.”  (PMBoK v4, p452).  Other than being a circular definition, this is consistent with what I said in “Deliverables as Revenue Agents.”  The stars of this definition are “hierarchical” and “deliverables.”   “Decomposition” and “scope” are supporting cast members.

Since Deliverables define the total scope, the structure starts like this:

Project WBS Example

·         Deliverable 1

·         Deliverable 2

·         Deliverable 3

We now have a decomposition of the total scope for a three deliverable project.  Is this a WBS?  No, the work (each Deliverable) has to be decomposed to the lowest level of work.  As I described in The Task, that level of decomposition is the task.  A well-formed task has one owner and one work product.  We can now show our example project structure as:

Project WBS Example

·         Deliverable 1

o   D1 Task 1

o   D1 Task 2

·         Deliverable 2

o   D2 Task 1

·         Deliverable 3

o   D3 Task 1

o   D3 Task n

This, in fact, is a simple well-formed WBS.  It has a hierarchical structure, is decomposed to the individual task, all tasks are contained within deliverables, and the deliverables (and tasks) define the total project scope.

In my next post, we’ll build on this foundation to explore variations on the basic WBS structure.

Are you ready for more advanced WBS concepts?

Deliverables as Revenue Agents

Muda (non-value-added [wastes])… includes the seven wastes of the Toyota Production System and their lean product development counterparts….  Any activities that lengthen lead times and add an extra cost to the product, for which the customer is unwilling to pay, are considered muda.

-          Morgan, James M. and Liker, Jeffrey K. (2006).  The Toyota Product Development System: Integrating People, Process, and Technology. New York: Productivity Press, p74.

Back in January one of my posts was on The Task.  Building on that foundation, I’d like to state some axioms:

1.       Every task in the WBS should roll up to a Deliverable.

2.       The collection of all project Deliverables defines the high-order scope (the Tasks define the low-order scope).

I’m not yet ready to defend or prove these axioms;  that comes later.  First we have to understand and agree on what a Deliverable is.  Certainly, I have referenced the term often enough in my previous posts.

Over the course of a project, the team will produce some number of – generally many – tangible and intangible results.    These results are called Work Products.  Every well-defined task should produce a Work Product.

What distinguishes a Work Product from a Deliverable?  A Deliverable is a special kind of Work Product (and therefore Deliverables are a subset of project Work Products).  The specific characteristic distinguishing a Deliverable from a Work Product is that a Deliverable has an (ideally formal) acceptance or approval.  Some examples:  a meeting minutes is a Work Product, but (generally) not a Deliverable;  a draft Requirements Document is a Work Product, but the final Requirements Document submitted for acceptance is a Deliverable.

Deliverables have special meaning for Consultancy PMs and for project management consulting firms because they represent well-defined Earned Value boundaries and, for accrual accounting, a point where revenue can be recognized.  All of the project revenues are represented by individual Deliverables spread over time so that revenues are evenly spread over the life of the project, not bunched at the end.  The customer is getting value from the project from the completion of each Deliverable and the consultancy is getting recognizable revenue.  A mutual benefit.

In addition to the economic value to this approach, it is also an indicator of a well- or poorly developed project schedule.  If the Deliverables (costs and revenues) are not evenly spread over the life of the project, that should be a red flag to re-think the project approach, because it means that you as the PM and also your employer are not getting regular feedback on the quality of the project product.

Now we can return to the axioms.  I’ll start with the second axiom.  If you can get the client to accept each Deliverable, and there is no work that is not contained within a Deliverable, then getting final project acceptance is an academic exercise – you’ve accepted all of the individual project components, so sign that the overall work is complete.  Therefore, the consultancy is motivated to make sure all project work is contained within individual Deliverables.  Thus, the project scope is equivalent to the collection of project Deliverables.

Now for the first axiom.  If something is a cost that doesn’t increase revenue, it should be eliminated.  Only Deliverables represent revenue.  Tasks represent costs.  Any task that is performed that doesn’t roll up to a revenue component is wasted money.  Removing these tasks improves the project margin and thus the organization’s margin.  Removing waste is a significant way to improve both quality and margin.  Therefore, any task not included in a Deliverable should be removed from the project WBS and thus, also, the schedule.  Every task remaining rolls up to a Deliverable.

So I can hear you now:  “All of your arguments apply only to Consultancy PMs;  what about P&SD PMs?”  My only practical response is that there’s a reason consultancy PMs have a much better track record at project performance!

When you’re running a project in a P&SD shop, how do you prevent  operational and production tasks from creeping into your project?  Is it based on a philosophical approach, rules, or serendipity?

The Task

“Is the PaRC Coding task complete?” asked Evelyn, the PM.  “Yes,” responded Jeff, one of the best programmers, who then continued “I completed all of the coding yesterday.”  “But what about the unit
testing?” Evelyn followed up.  “No, I’ll get to that tomorrow,” replied Jeff.  “But the task includes coding and unit testing,” Evelyn noted exasperatedly.  “It isn’t done until both are done and it’s ready for turnover to the test group.  You know that.  Why do you tell me it’s done?”

I’m trying to build some of the context for presenting best practices, but PM best practices are difficult to document, in this case, because everything is so integrated.  You can’t really discuss one thing being a “best practice” until you have a context for that practice to be best in.  For example, you can’t comprehensively discuss estimating without also including risk management.  You can’t discuss reporting best practices without addressing stakeholder management.  You can’t address acceptance management without addressing scope management, which also has to involve change management.

So I’m going to start with a fundamental and see if I can build a base sufficient to start expanding into more complex topics.  The Work Breakdown Structure (WBS) is a core project management document and the task is the atomic element of the WBS.

Typically a task should be a single component of work delivered by one person.  This would generally be a best practice.  I have frequently made exceptions to this practice, but that doesn’t prevent this from being a best practice.  And knowing when to make exceptions is part of the pragmatic, flexible responsibility of the good PM.

The task should have clear transitions.  The inputs, outputs, and hand-offs (in- and out-bound) should be clearly understood.  This is one of the main areas where I frequently experience problems, when I assume that team members clearly understand their tasks, including Done.

I’ve developed some techniques to address this problem.  PMBoK v4 references the WBS Dictionary, what used to be called the task dictionary.  The WBS dictionary is without question the appropriate reference for this situation.  But who has the time and budget to include one in the project?  What I’ve found that I can do for key project tasks is sit down with the task owner (Owner A) and the owner of the next (successor) task (Owner B).  In this facilitated discussion with Owner A and Owner B, we discuss what is included in the task, what is expected as inputs and outputs, and what constitutes done.  This often identifies differences in expectations by the owners which, without the conversation, would’ve left  some ball dropped.

The key point I make sure to include in the discussion:  Owner B has to accept the results before the task can be closed for Owner A.  Universally the task owners know more about their jobs than I do, so I don’t have to impose the general task scope, all I have to do is make sure each successive owner is clear about the task boundaries.  It’s amazing how many problems this little discussion has prevented.

Call it a dynamic WBS Dictionary, maybe.

Do you have any experience with a WBS Dictionary, or problems with not having one?