I'm working on a process improvement initiative for a client that integrates Systems Engineering, Program Management, Systems Architecture and Product Development. One of the topics of discussion is how to develop a Work Breakdown Structure. The motivation for the WBS to collect all the work being do, assign responsibility for cost and schedule, and distribute the funding in a manner visible to senior management.
Since this is a product centered effort, the WBS is organized for:
- Project and technical planning and scheduling
- Cost estimation and budget formulation. Cost collected in a product-based WBS can be compared to historical data. This is the primary use of a WBS.
- Defining the scope of Statements of Work and specifications
- Project status reporting, including schedule, cost, workforce, technical performance, and integrated cost/schedule views like Earned Value
- Plans, such as a Systems Engineering Management Plan
All this sounds straightforward but there are three common errors in building a WBS:
- The WBS describes functions, not products. This makes the project manager the only one formally responsible for the products
- The WBS has branch points that are not consistent with how the WBS elements will be integrated. In this instance there are hardware and software elements that will be integrated and verified at lower levels in the WBS. It would be inappropriate to separate hardware and software as if they were separate systems to be integrated at the higher system level. This would make it difficult to assign accountability for integration and to identify the cost of integrating and testing these components.
- The WBS is inconsistent with the Product Breakdown Structure (PBS). This make it possible that the PBS will not be fully implemented, and generally complicates the management process.
Developing the WBS
A good WBS starts with the development of the systems architecture to a point where the Product Breakdown Structure (PBS) can be created. One approach is to develop the PBS and WBS level by level starting at the top. A project level systems engineer can finalize the PBS at the project level and provide a draft PBS for the next level. The WBS is derived by adding management services and systems engineering.
A second approach is to define all the levels of the PBS, then develop the WBS. Care is needed to assure all product elements are included in the PBS and the assembly and verification branches are correct.
If the WBS is used to collect costs and describe the map between work and the product structure, then it becomes a powerful tool for project management, even Agile Project Management.
