WBS Design and Manageability

Bill at Projects Possible has an post (here) on Creating a Manageable Work Breakdown Structure that links to a post (here) and article (here) by Dick Billows from 4PM.com on WBS design. 

From Dick:

Some people build a work breakdown structure by listing everything they can think of that the project team might do. Others go from office to office assembling wish lists of goodies that people want and make that into a work breakdown structure. Either way, these PMs launch their project with a long “to do” list WBS. Accountability is unclear, performance expectations are vague and the process of gathering more items for the WBS never ends.

Some folks misinterpret the guidance that a WBS contains “all the work” of the project and make it into a “to do” list.  They forget that the deliverables ultimately must be tangible and measurable.  Also, Dick’s article notes that sponsors are often impressed by this level of detail, thereby reinforcing this behavior by encouraging the idea that the project manager is on top of everything.

Good stuff, though I would have emphasized the WBS’s role as a communications vehicle.  Super-deep or work-oriented WBS structures, especially early in the project, obscure understanding.  Even worse is the habit of presenting them in hierarchical (MS Project) rather than graphical formats (Visio).  

From Bill:

In looking at the projects that I work on there could literally be thousands of small little tasks in the jigsaw puzzle we call a project.  The tasks could range from simple little 20 or 30 minute things, to tasks that may require days or even weeks to complete.  At one time, I went down the road of creating a Work Breakdown Structure that would allow me to assign and track all of those thousands of tasks.   What I found is that I was spending more time tracking tasks than some of those tasks even took to complete.   I also found that I was creating an atmosphere in my projects that did not allow my team members the flexibility that they needed to exercise their expertise.  

A critical insight here: an overly elaborate WBS reduces the capacity of the project team, for it stifles the creativity that each sub-team should bring to the table.  It is a fundamental knowledge problem: “local” resources can bring the best insight into the activities required to generate the deliverables and work packages. 

I learned after doing a couple of these extensive WBSs that I needed to trust my team and hold them accountable for their portion of the project but to let them handle the small details that they had control over.  As a result I had a slimmed down WBS that really focused on key components of the project with a few «touch points» within each component that I could effectively monitor and measure.  My team members were empowered to complete their jobs without me hovering on each and every task and instead of me spending hours trying to keep tasks updated I was now able to focus my attention more on the things that really mattered.

This last point is a success differentiator among PMs.  Smart executives aren’t snowed by an attempt to show too much detail; in fact, summarizing and prioritizing is an essential leadership skill.  A tendency to over-elaborate is one way in which PMs undermine how they are perceived by management.

Advertisements

2 Responses

  1. Thanks for the TrackBack… I find I learn more each day with this job and as I approach the credits and hours needed for my PMP I learn something new each day.

    The interesting thing I find about projects is they all have a WBS whether complicated or not but most really seem to be missing the Project definition. Without a clear statement of what the project is going to entail the measurement of success or failure becomes much more difficult because the Outcome is not clearly defined. This is the area I have been focusing my attention as of late.

  2. Hi Bill,
    Your last point is critical. Our experience is that this topic is a differentiator among project managers. PMs on a leadership path understand that projects are only useful when the deliver tangible deliverables that generate outcomes with business benefits. PMs that are always looking “inside > out” — in other words the project comes first, the business second — are engaging in career-limiting behavior.

    Best,
    Paul

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: