In order to create a project schedule, I need to create a WBS first. What’s the best way to do this?
Specifically, how should the WBS be structured, and how should I work with the project team to create a comprehensive and accurate WBS that faithfully captures the full scope of work for the project, so that I may ultimately create a project schedule?
A WBS serves as an excellent alignment and communication tool among the project stakeholders, in addition to its other very practical use, defining the phases and deliverables that encompass the scope of the project. However, it can be notoriously difficult to create a high-quality WBS. Getting started is easy: whatever tool you choose to use, draw a box with the name of the project in it. That represents level 1 (L1) of your WBS.
To create the second level, draw child boxes that connect up to the L1 box. Each child should be named in accordance with your project’s life cycle. This, too, is pretty easy. Many companies with project management offices (PMO’s) have standards that define a life cycle that they recommend be used for all projects. For instance, the medical center associated with one top-tier university in the United States uses:
- Go Live; and
- Ongoing Support.
There are many possible life cycle phases to use in a WBS. It could be as simple as using the Rational Unified Process’s (RUP) four:
- Construction and
One temptation may be to not use life cycle phases, but the names of the various departments represented by the members of your project team, such as:
- Networking and Security
- Database Systems
- Enterprise Applications Development
- Patient Financial Services
- Legal; and PMO.
Although you can do this in order to help the various stakeholders concentrate on defining their work, from a WBS purist’s perspective, this conflates a work breakdown structure with an organizational breakdown structure, which, in addition to complicating the purpose of a WBS as a tool for defining and chopping up into ever smaller pieces (to a manageable level of granularity) the deliverables that a project needs to produce, reinforces silos of work and obscures the inter-departmental, team-oriented nature of creating deliverables. For these reasons, it’s better—and easier on the PM—to use L2 of your WBS to contain the phases in your project’s life cycle.
Guideline: Use your WBS to define what deliverables are to be created, and not who is to create them. The what is part of creating a WBS. The who part is about resource planning.
Once you’ve gotten levels 1 and 2 defined, it’s time to define the actual deliverables in level 3.
(To be continued…)