The concept of ‘Deliverables Management’ has been present during much of my Project Management life but I’ve (almost) never seen any detailed codification of what this means or how to use the concept in anything more than a superficial way in my projects.  The one reference that went further than the tautological is Chocron & Krolicki’s paper called “Deliverables Management: Managing Project Complexity” (1997) presented to the PMI’s 28th Annual Seminars & Symposium Chicago, Illinois on September 29 to October 1, 1997.  You will see this referenced repeatedly in the book the Art and Science of the Deliverable (Alpha Book)

In much of Project Management literature, the term ‘deliverable’ seems to have an obvious stand-alone meaning and doesn’t seem that it was ever properly described with process or usage, and therefore never properly leveraged as an effective tool in Project Management.  In Project Management’s ‘conventional wisdom’ it appears that the idea of a deliverable and its management is so obvious that nothing else is required.

In my mind, ‘deliverables’ are the outcomes of projects.  And yet, in most discussions about ‘deliverables’ that I’ve heard or read, the word is simply a stepping stone to a discussion about work and tasks, not outcomes.  A mere mention of the word and off we go talking about tasks instead of outcomes, thereby, at least to me, negating the whole value proposition of the outcome focus, and further propagating the problems around a work-based perspective.

This seemed to be a waste: there had to be more than a self-defining term that ‘everyone’ understood but few could explain – a “deliverable” is something that “gets delivered”, and how it gets delivered is the subject of other techniques and processes.

I spent a fair bit of time in the process of research and cogitation to find a better use for this term and to codify it as a useful model for software project development. I researched existing publications, I mostly found more of the redundant, self-referential definitions and equally self-referential articles and little else; Fortunately there was the Chocron and Krolicki paper and the od interesting viewpoint buried in some magazine and blog articles that helped frame some detail.

I’ve now been using Deliverables Management as an enabler to my own project management activities over the last 10 years or more, and progressively codified this usage. But I have never been able to comprehensively put that knowledge into a coherent manner that can be shared.

In this series of posts I will provide some summary perspectives drawn from my (work in progress) book, “the Art and Science of the Deliverable” published now in Alpha release on (see references below).  Also its worth noting that the deliverables concept is a key component of Project Action Principle #1 – see below also in the references section.


  1. Project Action Principles #1: Achieve Outcomes, Rapidly
  2. the Art and Science of the Deliverable (Alpha Book)
  3. Principle-Based Project Leadership (Beta Book)