Rethinking the deliverable in projects

The term ‘deliverable’ is used throughout project management literature but often as a bit-player, never the star. It seems that the idea of a deliverable and its management is so apparent that no other explanation or definition is required.

We can do much better. Here are five ways to rethink the deliverable concept and integrate it into our day-to-day practical project management activities.

1. Deliverables involve a hand-off between producer and consumer(s)

A deliverable involves a dynamic relationship between its producer and consumer.

The conventional definition frames the producer with the output of a task. What happens outside this is vague. To reframe this concept, let’s think of a deliverable as:

• Firstly, something to be consumed. A deliverable enables another party (person, group or organisation) to begin or complete work for themselves.
• Secondly, a ‘hand-off’ from producer to consumer. The consumer has a dependency on the hand-off that we must clear to make progress.*

This focus shift anticipates gaps that the consumer would otherwise only find after using the deliverable. In my experience, poor understanding and management of these hand-offs create many project problems.

2. The deliverable has a core and a wrapper

A deliverable must be more than the work product of a task to enable the smooth hand-off. A deliverable must have both a ‘core’ and a ‘wrapper’.

• The core of a deliverable is the product, result or capability.
• The wrapper is how the deliverable becomes available to be used by the consumer.

The wrapper includes form, location and quality settings that fully describe how the consumer(s) can put it to work. Without the wrapper, the hand-off will not fully enable the consumer. Project managers often miss the wrapper in their planning. The deliverable wrapper guides the producer to better tune the deliverable to their consumer’s needs, which leads us to the next point.

3. The consumer determines usability

The consumer, not the producer, determines a usable deliverable.

Usually, the emphasis for deliverable creation is on the producer. The producer typically controls how and what they produce, but the practical scope is what the consumer uses, not what the producer wants to develop.

Anything that is created and not consumed is waste. Anything that needs to be used but is missing is a gap.

As an example, let’s consider a specification document. The producer usually selects a template, defines the activity scope, and populates its content to produce a document that meets its quality standards. But if the consumer also needs a spreadsheet to load into a management application – there’s a gap. If all they want is the spreadsheet, then the document is a waste; any section that the consumer doesn’t read is a waste.

It doesn’t matter how much or little effort is put into the deliverable; it only matters what the consumer uses.

4. Deliverables help intangible products and processes become more tangible

Managing by deliverables provides an overlay of tangibility onto the intangible elements of project planning and execution.

Software development projects are challenging because they sit at the nexus of an intangible product (software) and intangible processes (human cognition and social interaction). Projects with tangible products still must still deal with the intangibility of human judgement at the hand-off point, for example ‘is this deliverable aesthetically pleasing?’.

Team members and stakeholders can understand intangible project elements only through visible results or hands-on experience, for example during integration with other components.

The core of a deliverable may be tangible or intangible, but the wrapper is primarily intangible –the wrapper deals with, amongst other things, subjective assessments of quality and utility.

This approach provides both consumer and producer with a more objective and verifiable reality in advance, thus reducing friction or blockages at the hand-off point.

5. Projects consist of a network of deliverables

A project is a network of deliverable hand-offs between multiple producers and consumers. It ends with the ultimate hand-off of the entire project to its customer. Modelling this hand-off network end-to-end is critical to successful project planning. Project managers can implement this hand-off network model using existing tools.

For example, you can define your Microsoft Project schedule using deliverable dependencies, not task dependencies. If you use a programme evaluation and review technique, try using deliverable hand-offs, not task completion.

Even more simply, Chocron and Krolicki* describe a model of the deliverable and two dates; the date required by the consumer and the date forecast by the producer. You can quickly implement this in a spreadsheet to track deliverable-level date buffer and overruns.

Using deliverables in your plans makes them more straightforward and more effective.

A simple example

Let’s take a generic example to illustrate these concepts: cooking for my two sons—numbers in brackets which of the above five points is relevant.

After I order groceries, a courier delivers them: they consider this job done. The ‘core’ of their deliverable is the groceries. (2) Their version of the ‘wrapper’ is to put them on my doorstep, packed into bags. (2)

But, when I cook, I select ingredients from my cupboard or fridge. If I’ve ordered bulk items, I need them packaged into meal-size portions. So there’s a gap between my needs and the courier’s hand-off. (1)

Thus, I need to create a ‘bridging’ deliverable to move those groceries, sort, and pack them away. Usually, I outsource this, ‘hey boys… I need a hand’. But if I do it myself, I notice the random packing of items into bags: I have to search across multiple bags to find what needs to go into the cupboard. (3) This intangible aspect of the ’wrapper’ is failing my tacit acceptance criteria. (3)(4)

This example shows a small deliverable network (5): the supermarket delivery service hands-off to my boys who hand-off to the cupboard, which later hands-off to me. Upstream and downstream are other deliverable networks.

We can also see that there will be gaps in your project if you don’t consider the deliverable ‘wrapper’ (2). Better you anticipate and remove those gaps than have to create ‘bridging’ deliverables on the fly.

The bottom line

These five ways of rethinking the concept of a deliverable make it more precise and valuable. You can quickly implement this idea in your project management processes and tools.

Sign up today and enjoy the latest project management articles delivered straight to your inbox

_{* Reference: E Chocron and J Krolicki, Deliverables Management: Managing Project Complexity, Project Management Institute - 28th Annual Seminars & Symposium, Chicago, Illinois: Papers Presented September 29 to October 1, 1997}