-
When Reality Hits - Project Managers Roll With It
February 11, 2012
-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
Creating The Project Scope - Creating the Work Breakdown Structure
April 24, 2008 | Author: PM Hut | Filed under: Project Scope Management, Scope Management
Creating The Project Scope - Creating the Work Breakdown Structure (#4 in the series Creating The Project Scope)
By Joseph Phillips
Once the scope statement has been written, it’s time to break down. Well, not you, the scope. A Work Breakdown Structure (WBS) is a deliverables-oriented decomposition of the project. It is not the activities needed to create the project deliverables; it’s the stuff that the activities create.
Gasp!
That’s right. A WBS is not the work, but the deliverables. Some folks in the IT world (I won’t mention them by name, but their initials are Microsoft) have skewed this a bit. If you’ve ever used Microsoft Project, a great tool, you may have been led to believe that the activity list, the default view in Microsoft Project, is the WBS. It isn’t so.
A WBS is not the activities but the actual deliverables that the customer expects from the project work. Suppose that we were going to install a network from scratch in five different locations around the country: northern California, Tacoma, Philadelphia, Atlanta, and L.A. We’d have some major categories of things for our project:
- WAN
- LAN
- Operating systems
- Education
These major categories of things can be broken down again to more things that we’ll be delivering in the project:
| WAN | LAN | Operating Systems | Education |
| ISP contracts | Switches | Workstations | IT professional education |
| Routers | Switches | Wall jacks | End user education |
| Servers | LAN addressing schemes | IP addressing schemes | |
| WAN diagram | Patch panels |
See how the deliverables are decomposed into more things? We’re decomposing the project scope into things that the customer will get as a result of the project. Stuff, not activities. The end result of the WBS is a clear picture of what the customer will and won’t get as part of the project.
So how far should you break down the project deliverables? You could (not that you’d want to) decompose your WAN deliverables down to the nuts and bolts in the rack that’ll house the hardware.
You want to follow the “8/80 Rule” when you break down your project scope. The 8/80 Rule, which really isn’t a rule but a guideline, requests that the smallest deliverable in the WBS, called the work package, equate to no more than 80 hours of work and no fewer than 8 hours of work to create that deliverable. You don’t want to get so granular or so vague with your WBS that it’s uncontrollable and useless.
But why even bother creating a WBS? There are a bunch of reasons why an accurate and complete WBS needs to exist, but there are five prominent reasons why every project needs a WBS (discussed in the next articles in this series).
Joseph Phillips is the author of five books on project management and is a, PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. For more information about Project Management Training, please visit Project Seminars.
Related Articles
No comments yet.
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.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized