The Wisdom of the WBS
April 6, 2010 | Author: PM Hut | Filed under: Project Plan Development
The Wisdom of the WBS
By Barry Otterholt
The Work Breakdown Structure is a tool most of us have heard of but few of us use. That should change.
At the start of a project, when the WBS should be created, we are all anxious to deliver some showcase results to reassure our sponsors and stakeholders they picked the right people for the job. Time is of the essence and we’re biased for delivery. There’s a sense that too much planning is just stating what we already know, adding bureaucracy, and delaying delivery.
Too often however, when we gain the burden of hindsight, we recognize that stronger leadership in the early stages would have prevented many of the problems that are consuming us now. One of the least imposing and most revealing planning tools we have available in the early stages of a project is the WBS.
The WBS lines up the deliverables, and breaks down the work into manageable packages. It’s conceptually simple, and can be facilitated with very little training.
Amongst several benefits, these are a few that stand out in my experience:
- It aligns our understanding of expectations with those who are doing the expecting
- It causes us to think about what’s needed before we tackle it
- It’s preventive, preferring to avoiding risks rather than react to them when they happen
- It biases the project for results, by tying all work to deliverables
- It fosters healthy working relationships between customers and solution-providers
If we have a hard time creating the WBS, it’s very likely because we don’t know what people expect of us, or how we’re going to get it done. Why then, would we willingly proceed on a path of certain trouble? A respected colleague once put it this way:
Planning will happen…whether at the onset of the project, or in response to troubles throughout the project
Take time to plan. Use the WBS. It will save time and a whole lot of grief.
Barry Otterholt, CMC, PMP
Barry Otterholt has been a project management specialist and coach for the past 30 years. He is a Certified Management Consultant (CMC) and a Project Management Professional (PMP). He works with both public and private sector companies in the USA, Europe and Scandinavia. Mr. Otterholt was a Director with Microsoft, a senior consultant with Deloitte Consulting, and a COO with a nationwide consumer electronics enterprise. In 1988 he founded Public Knowledge, LLC to provide independent management and operational support to the public sector. More recently, he founded Stouffer & Company, LLC to provide as-needed project management services to fill an obvious skills gap in both private and public sectors.
Mr. Otterholt is an adjunct professor teaching project management at Northwest University. His essays on project management have been published in PMI newsletters. His runs a blog, Project Management Essays, where he muses about various project management topics.
Mr. Otterholt is a member of the Institute of Management Consultants (IMC) and the Project Management Institute (PMI). He has a BA in Accounting and Computer Science and an MBA in Business Administration. He lives in the beautiful Pacific Northwest.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.











1 person has left a comment
Thank you for the article and I agree whole heartedly. Seeing the deliverables organized helps to facilitate the answer to the question “what needs to be delivered to the end users, stakeholders, team members, and sponsors for the project to be considered done”. In software development I’ve seen project teams think only of the “system” being built and easily forget user education, transition to operations, reports requirements, not to mention all of the deliverables that go into good system and database design.
The WBS helps to demonstrate the true size and complexity of the puzzled call “the project” when you breakdown the deliverables needed before the project team can “deliver” the expected results.
As for getting it done, I’ve used a facilitated team discussion (or breakout groups with a large team) starting with the high level WBS and drilling down with leading questions of:
1) What do you need to deliver to help see this deliverable “done”?
2) What do you need to be delivered to you?
Thank you for posting and giving me an opportunity to get on my WBS soap box.
—————————————————–
Vicki M. James, PMP
vicki@professionalprojectservices.com
Linked In - http://www.linkedin.com/in/professionalprojectservices
Web site - http://www.professionalprojectservices.com