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?

Topcoder.com

A future history is a postulated history of the future and is used by authors in the subgenre of speculative fiction (or science fiction) to construct a common background for fiction. Sometimes the author publishes a timeline of events in the history, while other times the reader can reconstruct the order of the stories from information provided therein.
                                                                           From Wikpedia (retrieved 11/09/2011)

I plan to someday post on the Future History of project management.  In the meantime, we might be able to catch a glimpse of what the future holds by looking at one of the more innovative approaches to project delivery that I’ve seen.

I learned about Topcoder.com from an article in Harvard Business Review (“The Age of Hyperspecialization,” Thomas W. Malone, Robert J. Laubacher, and Tammy Johns, July-August 2011, vol 89, pp 56-65).  I apologize to the people of Topcoder.com in advance that my description will certainly not do their service justice.  In a nutshell, if you want a software solution you contract with them.  The solution is presented as a contest (or series of contests) and qualified contestants compete to deliver your solution.  Further, the contest is decomposed into a standard Software Development Lifecycle (SDLC):  Ideas, Planning, Prototypes, Build, Testing, Problems/Problems/Problems, and Deployment.

Project Management is superfluous in their context.  Think about what we Project Managers do:  plan, estimate, monitor & control, communicate, eliminate blockages, herd cats.  Topcoder.com’s methodology and tools eliminate the need for all of these.  On traditional projects, PMs are necessary to assure a meaningful methodology is used and that resources stay focused on their responsibilities.  PMs aren’t necessary when the development methodology is enforced and practiced by all practitioners and where the resources are already fully engaged and motivated (or they lose the competition).  The methodology itself and all the participants enforce the methodology.

Some will respond to this commentary that what Topcoder is doing is different, it’s not project management, and it won’t displace us (i.e., it’s not a competitive threat).  I refer these skeptics to “In Praise of Dissimilarity” (Michael Gibbert and Martin Hoegl, MIT Sloan Management Review, Summer 2011, Vol 52 No. 4, pp 20-22).  Some of the biggest competitive threats originate from where we’re not expecting them.

What do you see bulldozing the project management profession?

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?