The Root Cause of Most Project Failures: Not Using a Work Breakdown Structure

When I advise my clients or teach a project management course, the first question I ask is what types of problems they experience when managing projects. The typical answers include:
  • Completed past deadline
  • Overbudget
  • Unrealistic schedules
  • Team member frustrations
  • Unclear roles
  • Resource constraints
  • Lack of accountability
It is normal for these issues to be perceived as problems, as they cause organizational ‘pains’ when they occur. As with most problems, the first step is to assume they are likely symptoms with some underlying root causes. If you or your organization does not follow a project management methodology (meaning everyone manages projects their own way), then you should expect these types of systemic problems. A variable process will always yield variable outcomes no matter how hard you try.
For the folks who do have a project management methodology (or realize they need one), I have found one tool is often missing from their toolkit. For organizations with strategic plans, but who fail to achieve their organizational goals, this same tool is often also missing. The tool is called a work breakdown structure (WBS). While a WBS is not complicated, it does take some time to properly plan a project or strategic initiative.
I will use the following example to explain what a WBS is and why they are necessary.
Situation: ACME, Inc. makes test stand machines that require software. Each machine they make is different and requires unique software. Every time the schedule says it’s time to load the software, the project is not finished and is delayed. This often leads to late finishes and cost over-runs.
Background: ACME has a high-level list of what the deliverables are for each machine they make. A high-level project schedule is developed (see below) and time is always allotted for software.
Example ACME Project Plan
In this example, ACME has committed 70 days to design, build and run a complete test stand machine. As you can see, software development is allotted 45 days, it should start on February 14 and is due on March 31.
The above project plan is inherently flawed because it is being managed at the deliverable level. This means each big chunk of work is due by a certain date. When work is scheduled in these big chunks, it is sometimes referred to as a shish kebab schedule. If it is critical that the software be completed on time, and it rarely is, we probably need more detail to stay on top of its progress.
Other flaws in this schedule are that it is not clear exactly who is doing what (by name). It is also not clear if there are dependencies within each section or if there are opportunities to perform tasks in parallel (or at the same time).
A proper WBS for the 45 days of software development would be as follows:
While it would take slightly more time to break the 45 days of software development down into these eight lines of detail, there are several benefits to managing at the task (versus deliverable) level.
The WBS shown above has several benefits. It displays that the plan is to complete the software development on the day it is due for the machine trial run (March 31). This may be risky as there is no extra time in the software schedule for unknown circumstances. This situation should be discussed before the project starts. It also indicates who is doing what by name so accountabilities are clear and highlights which resources may be overloaded.
The WBS also shows that the outputs and inputs must be defined in the first seven days at the same time. This is called running in parallel (usually to save time). To ensure an on-time project start, two different people must start on February 14, or the whole project might start late. These two tasks should be reminded and watched very closely.
In addition, the WBS documents the six-step breakdown with start to finish dependencies, meaning no one can move on to the next step before the prior task is completed.
  1. Write the code
  2. Compile the code
  3. Dry run
  4. Debug software
  5. Re-compile software
  6. Final test
Finally, the WBS gives a much clearer picture of where this project stands at any point in time, which is a Project Manager’s main responsibility. Examples using the above WBS:
  • If today is February 15, a project manager should verify that Todd and Sara have started their work packages.
  • If anyone suddenly gets sick, it is clear what work must be reassigned.
  • Since there are dependencies on everything beyond the first two work packages, it is a good idea to make sure all task due dates are being met as the project progresses.
  • If this project needs to be handed-off to a different Project Manager, it is clear what the plan is and where we should be as of today’s date.
As mentioned earlier, a WBS is not complicated, but it will take a little more time to develop than a big chunk, or shish kebab schedule. In addition to the benefits mentioned above, the time spent to develop a WBS is usually recouped by re-using them on future projects. In this example, if the company will continue to develop software for their testing equipment the steps are likely the same or similar for every future project. The only thing that would need updating is the new cast of characters and the work package start/due dates.
In today’s ever-changing business landscape, companies are taking on an increasing number of projects to remain competitive and reduce the changes of losing market share. The Center is here to help you gain the fundamental project management tools that will allow you to effectively manage and complete projects. Register for an upcoming class here.
MEET OUR EXPERT: Rob Stauffer, Senior Lean, Costing & Project Management Consultant
stauffer_r-web.jpgRob Stauffer has been a Program Manager in The Center's Lean Business Solutions program for 15 years. He has trained and mentored Michigan companies in the entire portfolio of Lean Sigma strategies and methods specializing in financial analysis, costing, strategic planning, and project management. He also works with clients on product development, product launches, transactional office processes and sales of technical programs.
Since 1991, the Michigan Manufacturing Technology Center has assisted Michigan’s small and medium-sized businesses to successfully compete and grow. Through personalized services designed to meet the needs of clients, we develop more effective business leaders, drive product and process innovation, promote company-wide operational excellence and foster creative strategies for business growth and greater profitability. Find us at

Categories: growth, Leadership/Culture, Lean Principles, Manufacturing, The Center