Defining Your Deliverables

Part 2 of the “How to Plan Successful Projects” series

IntroductionSeven Steps to (Objective) Heaven - Defining Your Deliverables

There are many different kinds of Deliverable: product prototypes, software developments, documentation, training and so on. Which ones you need will depend on the nature of your Objectives.

In the first instalment in this series we discussed how to create a solid foundation for your project in terms of identifying objectives and using their costs and benefits to build an outline business case. The next step is to use those objectives to define project deliverables and refine the project costs.

Identify Deliverables from Objectives

The aim of this instalment is to help you to work out a list of tangible deliverables that between them fully and exactly meet the objectives. If you do not deliver all the objectives, your project will not be a full success. Conversely, if you deliver beyond the project’s objectives, you will push up cost without contributing to the project’s overall aims.

Combined, the deliverables will set the full scope of the project: if they do not exactly deliver the objectives, either the project will fall short of expectation or the costs will be too high.

Of course, if you identify potential further objectives during this stage, discuss them with the stake-holders – they may have been missed, or they may form a useful phase two.

Finally, cross-reference the deliverables back to the objectives to show exactly how each objective will be met – this will show the project team why they are doing things and will make it much easier to get their buy-in when the time comes. Tables along the following lines work well as a starting point:

Objective
1. To increase sales revenue by 25% over the next three years without increasing costs
2. To improve customer satisfaction feedback from "OK" to "Great" in two years 
3. etc., etc.

 

DeliverableContribution
1. Revised sales process to remove existing bottlenecks and improve responsiveness Contributes to Objective 1
2. New IT system to support revised sales process and reduce staff needed by 2 Contributes to Objective 2
3. Trained and reallocated saved staff-members to direct sales Completes Objective 1
4. etc., etc.

How to Define a Deliverable

This sounds pretty straightforward but poorly defined deliverables are one of the most common causes of issues that we come across. If you do not accurately define what you are going to deliver to your customer, your expectations will be different and you leave yourself open to all sorts of problems later on.

We have found that the key things to record for each deliverable are its Name (something unambiguous that you can refer to it by later on), its Description (telling you what it is) and its Acceptance Criteria (defining when it is “done”).

Name

The name of each deliverable will form part of the common project vocabulary between you and the other stake-holders so it should be short, unambiguous and hold meaning in its own right. "New System" is ambiguous; "New IT system to help reduce sales overhead costs" is too long; "New Sales IT System" works well.

Description

You should be able to describe each deliverable in a single sentence or short paragraph. If you cannot, you are really thinking about a complex system and need to break it down into a number of smaller deliverables.

Examples of complex systems could include a new website (you would probably need to break this down into functional areas) or an office move (desking, other furniture, decoration, IT infrastructure and so on).

Acceptance Criteria

Perhaps the most often overlooked part of the project scope, yet possibly the most important, is the acceptance criteria. The acceptance criteria define how you will prove to your customer that you have delivered what you said you would.

Stating them at this stage of the project sets a concrete expectation between you and the customer and gives a solid foundation for the rest of the project – the suppliers know exactly what it is they need to supply, the testers can build detailed test plans and so on, all on the back of good acceptance criteria.

A good format for acceptance criteria is "GIVEN ... WHEN ... THEN...". For example, "GIVEN I am an authorised user, WHEN I try to log in THEN I am presented with a welcome message" or, for a higher level deliverable, "GIVEN I am a customer, WHEN I see XYZ item in the store THEN I am able to add it to my shopping cart".

This is not going to work for every single acceptance criteria but the large majority can be described in this way.

Watch the Detail!

When defining a deliverable and, in particular, its acceptance criteria, make sure you do not get dragged into too much detail.

Each deliverable should define what needs to be achieved but NOT how it should be achieved unless there is a very particular reason why something must be done in a certain way.

For instance, it is fine to say that a new office must have space for 500 people and that each person should have a certain minimum size or type of desk but it is usually not fine to say what the layout of the desks should be.

Similarly, it is fine to say that a website user must be able to access Customer Services’ details easily (even something like “within 2 clicks from any page” is OK) but it is not OK to specify where that link should be or what it should look like – the obvious exception is if you need to stick to corporate identity (“look and feel”) guidelines.

Too much detail restricts your options later on and will lead to multiple change requests that erode the customer’s confidence in you.