A work breakdown structure serves many critical purposes, the most important of which is defining the work to be performed and breaking it into manageable components.
For systems integrators, a Work Breakdown Structure (WBS) provides the building blocks for successful Project Management.
In the 1950s, the U.S. Department of Defense came up with a common-sense project management concept that most construction and systems integration-based companies should use today.
Back then, according to the Journal of Defense Software Engineering, the Navy began using something called the Program Evaluation and Review Technique (PERT) in support of the Polaris missile program – and this concept is considered the starting point for the work breakdown structure methodology.
At its inception, the work breakdown structure (WBS) was a deliverable-oriented grouping of project components that helped to organize and define a project’s total scope of work.
Effectively, the WBS described a project’s product or service through a “what-goes-into-what” process and it related each of the deliverable / product components to one another and to the total product or service as a whole. This “noun-based” system was primarily used in large construction / product development projects.
With the advent of Information Technology and Systems Integration projects, the paradigm shifted to more of a Phased / Function-based structure – taking into account the phased progression of the project lifecycle. This “waterfall” approach followed the project through predictable phases –
- Design,
- Build,
- Integrate,
- Test,
- Train, etc.
The goal was / is still a deliverable which meets the Customer’s performance requirements, but the project management focus has shifted to phases / milestones interdependencies.
The current WBS paradigm follows an “Apples-to-Apples” structure, where the way a project is designed, is how it is estimated, is how it is planned and scheduled, is how it is implemented, is how it is tracked and its performance measured – finally to how it is analyzed to close the lessons learned loop.
Typically, a company will determine between 8 – 12 major “buckets” which comprise a standard project. An example of this might be:
- Project Management
- Engineering
- CAD – Drawing / Drafting
- Rack Fabrication
- Programming / IT
- Installation (Rough / Final)
- Commissioning
- Training
- Transition / Closing
- Travel (extended)
- Contingency
These phases are often assigned to functions / labor with the skills to match the phase.
Often a majority of an integrator’s projects will share this structure – the primary differences being the amount of effort within and duration of each phase.
When the phase and the skill(s) are aligned, the company has the opportunity to take advantage of the “apples-to-apples” paradigm and begin to arrive at some heuristics, or “rules of thumb”.
Examples may be:
- Project Management on large projects consumes 8% of total labor, whereas on small projects it consumes 20% – 25%.
- Engineering takes roughly 5%,
- Programming takes roughly 8%, etc.
When a company sells and manages hundreds of integration projects a year, the amount of data captured can be mined for incredibly useful information.
When everyone follows a common mental structure, and when integrators also detail a project’s assumptions and risks and factor them into the equation, the work breakdown structure helps create “common sense” among all stakeholders. (Client, sales, project managers, technicians, vendors, general contractors, etc.).
The WBS serves many critical purposes, the most important of which is defining the work to be performed and breaking it into manageable components.
Developing a work breakdown structure generates a number of other planning benefits, such as:
- A greater ability to determine the types of resources needed,
- A better comprehension of their roles, and
- A more accurate understanding of the skill levels required to manage the pieces of the project.
Creating a detailed WBS also improves a sales/account manager’s and/or project manager’s ability to define, quantify, measure, and estimate the costs and effort required to deliver each component of the project. Doing so also enables you to better identify, document, and control changes.
A well-crafted WBS also helps a project manager define the performance-measurement baseline from which he or she can judge a project’s status.
When the status of the project is asked at its summary level (“How’s project XYZ going?”), we often hear answers such as “Fine”, “Great”, and “Moving along”. However, when the project’s status is judged at the phase level — instead of at the summary level — the judgment will likely be far more accurate because the questions are more binary in nature.
A well-crafted WBS also helps identify how a change in one aspect ripples across the product and project.
In the absence of a WBS, change notification is typically limited to those who deal with the particular piece or part of the project that’s being changed. A WBS visually demonstrates the product and project-wide ramifications of making a change in one component and therefore gives the project’s stakeholders a more global understanding of the interrelationships among all phases / components.
Conclusion
At the end of the day, a phase-based work breakdown structure is a powerful planning, estimating, learning, communicating, status/progress reporting and change-control tool.
Every project should have one.
And the good thing is, once a company has built a WBS, it has a template for future similar projects, which ultimately saves time and helps avoid potential mistakes and oversights.
