(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.
Howdy very cool web site!! Guy .. Excellent ..
Amazing .. I will bookmark your web site and take the feeds additionally?
I am happy to find numerous useful info right here in the
submit, we’d like work out extra techniques on this regard, thank you
for sharing. . . . . .