Having a common definition of “deliverable” in both WBS and the schedule network.

(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?

Critical Path Article 01.01

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.

“Ready for use” and “Ready to use”

I am prompted to write because of a useful paper: “Perspectives on the Formal Authority Between Project Managers and Change Managers”  in the October/November 2014 Project Management Journal by Julien Pollack and Chivonne Algeo both of the University of Technology, Sydney.

I am in broad agreement with the authors on:

… project management focusing on … issues, including scheduling, managing a budget, change control, and procurement, whereas change management focuses on … activities, such as empowering change agents, developing a senior guiding coalition, ensuring their support, and removing organizational obstacles.

however I would have expressed it a bit differently.

For a project to deliver business value, broadly speaking, two things need to show up simultaneously at a future date:

  1. the technical deliverable (building, IT system, transport system,…) needs to be ready for use by the people, and
  2. the people need to be ready to use the technical deliverable.

The trick is that the disciplines that are involved in each like chalk and cheese.  As project scale increases it becomes difficult for one human mind to stay with both disciplines.  It is about as easy as simultaneously enjoying fine classical music in one ear and fine jazz in the other. So while one person (e.g. let it be a Project Manager) may be responsible for both the technical deliverable and the people side of change, in practice the two sides of the project are “uneasy bedfellows”. As the authors note earlier in the paper, the

These differences suggest that project managers and change managers do not see their managerial roles in equivalent ways.

The implications suggested by the authors for the relationship between project managers and change managers are compelling:

For project managers, the implications of this research suggest a need to find some balance between the need for control and direction that comes with a single point of account ability, and allowing change managers to have a distinct area of responsibility that they can deliver in their own way, while maintaining coordination between the project management and change management aspects of organizational change projects.


Kazakh Notes now free download on Google Play

Back in 1991 in my first year in Kazakhstan, I wrote an introduction to Kazakh Language for English speakers called "Kazakh Notes".  I have just uploaded it and made it free on Google Play: Kazakh Notes. While preparing the manuscript for upload - I … [Continue reading]

Classic moments in automated geolocation


I found this today courtesy of Google's auto geolocation and mapping algorithms! … [Continue reading]

Foundations of Project Management

This is a collection of references to articles and ideas that I refer to constantly to refresh my vision for Project Management. Bent Flyvbjerg on Reference Class Forecasting. Mel Conway on How committees Invent. The collaboration patterns of … [Continue reading]

“Cybersecurity as Realpolitik” by Dan Geer

"Cybersecurity as Realpolitik" by Dan Geer, at BlackHat 2014 is a thought provoking and informative discussion of the behavioural economic interventions that might increase Cyber Security. 8/10 Is there any real difference between a system that … [Continue reading]

Expected % Complete MS Project Custom Column

I attended Angela Chellas' MS Project Advanced workshop today (excellent course) and there was a question about how to figure out what % complete that a task should be if it was on track.  Based on elapsed time, the Expected % Complete for tasks and … [Continue reading]

PRINCE2 Joined-Up

The core of PRINCE2 project governance guidance is summarised in the introduction to the business case ... The ongoing and ever-present decision regarding the Business Case is whether the project can (still) be justified. This is based on whether … [Continue reading]

Portable Bank Account Numbers

As you are probably aware, the Australian telecommunications regulator mandated mobile phone number portability which eliminated a major source of 'lock-in' previously available to phone companies. Today banks enjoy a very similar source of … [Continue reading]

Influence: The Psychology of Persuasion


Cialdini's book is a must read for all sentient beings. The facts on the ground are too numerous for our minds to accommodate so we consistently adopt mental shortcuts that make us vulnerable to the compliance practitioner. Forewarned is … [Continue reading]

Replacing TrueCrypt

If you are a TrueCrypt user then recent events will have given you pause for thought.  What to do? After reviewing alternatives, I have made the switch to BestCrypt. The tool is feature complete and the conversion has been seamless so far. … [Continue reading]

Javascript Concurrency

Every wondered how the javascript concurrency model works? I didn't either .... until tonight, chasing a bug in todotxttdi.com todo.txt HTML client.  In case you are interested, here are the three references that got me across the line: Mozilla … [Continue reading]

Indentifying Configuration Items and MS Project

This post explores a way of using MS Project to automatically allocate a permanent identifying number to a project's configuration items. Within PRINCE2 project management guidance, configuration management depends, in part, on being able to … [Continue reading]

Innovative Todo.txt client

Stay on top of your Todo.txt from any (non-IE) browser anywhere! I am pleased to announce the release of http://todotxttdi.com, a HTML5 Todo.txt app for Dropbox. Let the content of your Todo.txt drive the user interface,' and sort and filter … [Continue reading]


HTML5 Todo.txt app for Dropbox with novel user-centric text-driven user interface. … [Continue reading]