What is a Work Breakdown Structure? (Part 1 of 3)
Introduction
Company owners and project managers use the Work Breakdown Structure (WBS) to make complex projects more manageable. The WBS is designed to help break down a project into manageable chunks that can be effectively estimated and supervised.
Some widely used reasons for creating a WBS include:
- Assists with accurate project organization
- Helps with assigning responsibilities
- Shows the control points and project milestones
- Allows for more accurate estimation of cost, risk and time
- Helps explain the project scope to stakeholders
A work breakdown structure is just one of many project management forms.
Constructing a Work Breakdown Structure
To start out, the project manager and subject matter experts determine the main deliverables for the project. Once this is completed, they start decomposing the deliverables they have identified, breaking them down to successively smaller chunks of work.
"How small?" you may ask. That varies with project type and management style, but some sort of predetermined “rule” should govern the size and scope of the smallest chunks of work. There could be a two weeks rule, where nothing is broken down any smaller than it would take two weeks to complete. You can also use the 8/80 rule, where no chunk would take less than 8 hours or longer than 80 hours to complete. Determining the chunk size “rules” can take a little practice, but in the end these rules make the WBS easier to use.
Regarding the format for WBS design, some people create tables or lists for their work breakdown structures, but most use graphics to display the project components as a hierarchical tree structure or diagram. In the article Five Phases of Project Management, author Deanna Reynolds describes one of many methods for developing a standard WBS.
What is a Work Breakdown Structure Diagram?
A WBS diagram expresses the project scope in simple graphic terms. The diagram starts with a single box or other graphic at the top to represent the entire project. The project is then divided into main, or disparate, components, with related activities (or elements) listed under them. Generally, the upper components are the deliverables and the lower level elements are the activities that create the deliverables.
Information technology projects translate well into WBS diagrams, whether the project is hardware or software based. That is, the project could involve designing and building desktop computers or creating an animated computer game. Both of these examples have tasks that can be completed independently of other project tasks. When tasks in a project don’t need to be completed in a linear fashion, separating the project into individual hierarchical components that can be allotted to different people usually gets the job done quicker.
One common view is a Gantt chart. In a recent article, Joe Taylor, Jr. discusses the Top Ten Benefits of a Gantt Chart.
Simple WBS Examples
Building a Desktop Computer - Say your company plans to start building desktop computers. To make the work go faster, you could assign teams to the different aspects of computer building, as shown in the diagram E-1 shown below. This way, one team could work on the chassis configuration while another team secured the components.
Creating an Animated Computer Game – Now we switch to software project managment, where you startup a computer animation company. To be the first to get your computer game on the market, you could assign teams to the different aspects of writing, drawing and building animated computer games, as shown in diagram E-2 below. Perhaps your key programmer is also a pretty good artist. Rather than have him divide his time and energy by trying to do both tasks, you will realize faster results if the programmer concentrates on programming while his cousin Jenny draws the scenery.
Conclusion
At the risk of sounding melodramatic, the efficacy of a project’s Work Breakdown Structure can determine that project’s success. The WBS provides the foundation for project planning, cost estimation, scheduling and resource allocation, not to mention risk management.
WBS Basics
A work breakdown structure (WBS) is a project management tool designed to capture project tasks in a visual, organized manner. The WBS was originally developed by the US Department of Defense, which mandated their use across the DoD. Today work breakdown structures are widely used for projects of all types, both business and personal.
On the most basic level, you decompose the project scope in order to create the work breakdown structure. This takes time in beginning, but ultimately it affords the project manager better control of costs and deadlines, thus saving time. When you use the decomposition process to create your WBS, you are less prone to adding items that are outside of the project scope.
A WBS is Not a To Do List
The example shown below is a simple, task-oriented WBS that resembles a graphical To Do list. A To Do list like the example below may work for a wedding party, but in the corporate world there is more to developing and using a WBS than simply creating an expanded To Do list.
At the beginning of a project, the WBS can serve as a coordinating medium to secure buy-in from stakeholders, supervisors and team members. As the project progresses, the WBS can give visibility to important efforts and foster clear ownership by managers and supervisors. At project completion, the WBS can provide data for performance measurement. That’s more than a To Do list can do.
Example
Considerations When Building a Work Breakdown Structure
There are some aspects of the WBS development to consider before you start, which include:
- As you set up your project WBS, think about how you will want to use it later in the project. For instance, pay close attention to the indents in your WBS because these eventually end up being the indent structure in your Gantt schedule.
- Intuitively we gravitate toward developing task-oriented work breakdown structures because they are easy to understand, and because we tend to think of a project as a collection of tasks. It usually takes more effort to develop a deliverable-oriented WBS because they include multiple levels of detail. Yet, taking the time to develop a deliverable-oriented WBS may better serve the project, especially if extensive project management controls are used.
- Determine whether you want to build a WBS that is process oriented or product oriented. What’s the difference? If the results you want from your project can be defined in verbs, then you want a WBS that is process oriented. If you want a WBS that is built on nouns, then it will be product oriented.
- Remember that our brains can simultaneously comprehend only 7 to 9 items at a time. When a project involves hundreds of tasks, they need to be broken into chunks that we can readily understand and use. The process of creating a WBS helps break down the project, which makes it easier to manage – and master.
- Be sure there is no overlap in scope definition between two elements of your WBS. Not only would this result in duplication of effort, but would likely cause confusion regarding responsibility, authority and cost accounting. To help alleviate this problem, create a WBS dictionary to describe each component in detail.
The Building Process
Not only do you need the project scope to create your WBS, you need the input from the project managers and team leaders. Generally, the WBS-building process finds all these people in a room with plenty of white boards and markers, or pads of paper and sticky notes. Out of this brainstorm session should come a first draft of the project WBS. It should be one that will foster “buy in” because the core project personnel participated in its development.
Creating a quality WBS can take a substantial amount of time, but is usually worth the effort because of the additional clarity it provides for the project manager.
Some WBS Resources
Generating a WBS from Microsoft Project – If your project has already been entered in MS Project, you may want to consider a third-party add-on for MS Project from Critical Tools (http://www.criticaltools.com). Their WBS Chart Pro add-on converts a Gantt chart task list with indents into a standard WBS graphic.
Military Standard for WBS - For comprehensive instructions on how to build a work breakdown structure, check out the complete military standard for work breakdown structures on the EverySpec website (http://www.everyspec.com) - just search for Work Breakdown Structures.
This is the second article in a three-part series about Work Breakdown Structures. Read the next article in this series to learn some common WBS pitfalls.
Work Breakdown Structure Pitfalls to Avoid (Part 3 of 3)
Introduction
A work breakdown structure (WBS) is a project management tool designed to capture project tasks in an organized way. Although the WBS is meant to be a useful tool for managers as well as employees, if care is not taken, it can be ill-designed and misused. To help avoid common mistakes made during the design of a WBS, I have compiled a list of the eight common pitfalls, and how to avoid them.
Some WBS Pitfalls
1. Neglecting to create a WBS dictionary
Creating a WBS dictionary is not always necessary, especially if the acronyms and category content in the WBS are obvious. This ia a common misconception. A WBS dictionary helps keep track of all of the summary and detailed activities, including a short description of what is – and what is not – included in a WBS element. Neglecting to create a WBS dictionary can cause “ownership” dilemmas that can ultimately threaten project success.
2. Expecting More than 100% from your WBS
An important WBS design principle is the 100% rule, which states that the WBS includes 100% (or everything) of what is in the project scope. However, we often hear people say that they have given a project or a task 110%. That's fine for an individual, but a project is doomed to failure if the WBS includes more than 100% of what is in the project scope. A quality, 100% WBS is a good measure against “scope creep," and we are all aware of the problems scope creep can cause.
3. Why bother with Formal Change Control?
Companies use change management to control both internally generated and customer-driven changes in the scope of projects. Any update to a WBS, other than an elaboration of details that already exist, should require formal change control. To ignore this step invites changes in scope that can spell doom for the project.
4. Method Orientation
The WBS should be outcome oriented and not prescriptive of methods. Methodology can change without any change to the planned outcomes. Planned outcomes or deliverables (which should be fairly rigid) should not be closely blended with actions and methods (which can be flexible).
5. To Do List Mentality
The To Do list approach to WBS construction stems from a manager’s belief that the WBS is actually a step-by-step procedure for doing everything. This approach can lead to the concept that managers walk around with a detailed checklist they use to check off each item as it is completed. Ultimately this leads to micro-management, which is not generally attractive to team members.
6. Adding Requirements in Lieu of Tasks
When you place a deliverable on your WBS, you can break down the deliverable into the activities required to create it. What doesn’t work is breaking down the deliverable into the requirements that describe it. Deliverables and tasks do belong in the WBS, but requirements do not.
7. Skipping the Buy-In Process
Your project team possesses all the expertise, experience, and creative thinking that will be needed to get down to the specifics of each deliverable, so naturally the WBS should be drafted with input from all team members. If the project manager creates the WBS with limited input from other project team members, they people may in turn offer little to no support for the WBS. It may be time-consuming, but in the long run it pays to engage all of the core project leaders in WBS development.
8. Too Many Tasks
Team members are generally more productive if they are held accountable for reaching measurable achievements rather than completing a laundry list of tasks. When the WBS is broken down to tasks that take just a couple of hours to complete, workers spend so much time reporting on these small tasks, and managers spend so much time keeping track of them, everyone may lose sight of the desired end result. As a general rule, WBS tasks should have durations between 1 week and 8 weeks long.
没有评论:
发表评论