(Article published first in “The Critical Path”, PMI Sydney, December 2014)
Having a common definition of “deliverable” in both WBS and the schedule network assists project managers to build a common understanding of the project scope and progress amongst stakeholders. This article examines possible causes for the divergence of the schedule network’s definitions and those of the WBS and argues that it is best practice to follow the example of Figure 6-21 in the PMBOK(r) Guide 5th Ed. and include a “Start” and “Finish” milestone in the schedule network for each WBS component. At project scale, implementing this practice requires automation help and a following article will explain a new project management algorithm “Add and Prune Dependencies” which enables this.
The project model has, at its heart, the dual structures of the tree-like Work Breakdown Structure (WBS) and the schedule network. Both the WBS and the project schedule are “maps of the same territory” and use different visual languages to represent the deliverables of the project. In the WBS the top-level component represents 100% of the deliverables or products of the project, and each level below decomposes the same 100% into smaller components that represent part of the deliverables. In the schedule network 100% of the deliverables of the project are represented between the “Start Project” and “Finish Project” milestones. Likewise, smaller deliverables may be represented by pairs of milestones that mark the start and completion of these deliverables.
Outside of domains that rigorously apply Earned Value Management (EVM), it is common for the deliverables defined in the WBS to not be precisely traceable to milestones in the schedule network. Assuming that dependencies are not placed on, so called, “Summary tasks”, the planner will commonly create “Deliverable completed” milestones in the schedule network to represent the availability of interim deliverables and the point where work that depends on those interim deliverables can begin. However, manually created “Deliverable completed” milestones are likely (and with updating over time, inevitable) to not exactly correspond to the completion of any WBS component. There are two main reasons for this. Firstly, the selection of predecessor relationships for the “Deliverable completed” milestone is unlikely to correspond exactly with the set of predecessors required to match the completion of a WBS component, and secondly, the choice of deliverables highlighted by “Deliverable completed” milestones may be dominated by tactical considerations at a detail planning level rather than the set of deliverables already defined in the WBS. As the project progresses, this can result in a widening mismatch between the WBS “map” and the schedule network “map”.
So how can a WBS and schedule network be provably based on the same set of deliverables?
Figure 1 shows the simplest case of a two level WBS with two planning packages at the lowest level and its corresponding schedule network prior to sequencing. Notice that the “House” deliverable is represented in the schedule network by two milestones “Start House” and “Finish House”. In general this is true. The implication is that if we want to have common definitions of “deliverable” in both the WBS and schedule network, each component in the WBS will be mirrored by “Start” and “Finish” milestones in the schedule network.
The thesis of this article is that definitions of deliverables will inevitably diverge if the schedule does not maintain “Start” and “Finish” milestones matching each WBS component, and that their presence in the schedule will create the alignment of definitions that we are looking for. Interestingly, while PMI’s best practice guidance is largely silent on this question, Figure 6-21 on p183 the PMBOK(r) Guide 5th Ed. shows an example of exactly this with “Start” and “Finish” milestones in the schedule network that correspond to WBS components.
Outside of domains that rigorously apply EVM this is not (yet) common practice, but aligning the WBS and the schedule network’s deliverable definitions means that the readers of the WBS and the readers of the schedule network are speaking the same language and that progress information can be trivially mapped back to the completion of WBS components. At project scale this requires automation support and the next article will describe the new “Add and prune dependencies” algorithm which facilitates this.