16 August 2005

Breaking down the WBS

I am undertaking a course of study - Project Management Techniques and an assignment calls for the creation of a WBS for a theoretical project. I am working in a team on the activities. Working as a team is one of the competencies demanded from this course.

An early discussion we had was whether a WBS should be broken down oriented towards product deliverables, or by functional or skill groups. I guess the answer is probably dependent upon what type of project it is.

My thoughts are that a top level breakdown by product makes a lot of sense from a scope, time and cost management perspective. If you need to reduce the work due to constraints the easiest way is by looking at what the end products you are aiming for and assessing what can be scaled back at he product/deliverable level.

  • Wikipedia has this to say about building a WBS.
  • Max Wideman also addresses this topic at his website.

"...The contention arises over whether that decomposition should be in terms of the activities of the project or of its deliverables. If activities, then the WBS is expressed by sentences commencing with verbs, but if deliverables, then the entries are expresses as nouns. The distinction is not trivial because activities speak to the work involved in the project, while deliverables speak to end results."

and more

"...The most useful first step in managing a project of any size is to start by breaking down its scope, as defined above, according to a well-established and logical sequence. This sequence looks something like this: First according to geographically discrete components, if this is applicable; Second according to time based phases and stages, where each has a clear deliverable; Third according to intermediate or final major deliverables; Fourth according to discrete structural, process, system or device components. Finally, into deliverable elements that can be associated with distinctive types of people-skills or resources."

Max Wideman is a 'leading thinker' on project management theory. Max goes on to discuss how the scope should be broken down prior to work activities. His thoughts above align with my own experience. The scope in our instance is the delivery of certain information packages to the client. The way we go about that is less important that the result - ie the client gets the materials on or before the due date. As a result my belief in a deliverables focus we have taken in the WBS is reinforced.

For a practical example of how this could affect a project - imagine if due to cost or time constraints the online help package was removed from scope - how would that affect the WBS if we didn't define the WBS at the first level by deliverable?

1 comment:

  1. I know this is an old post but I have a comment anyway. For me, the WBS should always be about deliverables and should be a decomposition. The activity definition and sequencing stages are where all the dependencies should be built-in. If the WBS is strictly "nouns" and the activities are strictly "verbs", there is less confusion and the focus of the WBS is purely on delivery of the scope. Where the scope seems to call for an activity, I usually frame that as an event for the WBS.