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.
