Vague deliverables make everyone unhappy. They create misunderstandings and
unfulfilled expectations. They tarnish reputations. 

Projects should always have clear deliverables. Too often, the project's deliverables
are so vague that no one can agree that the project is complete.

Take software development for example. If the project's deliverable is the
new version of that software, the project manager should be able to spell out
exactly what constitutes the new version. Is it the Beta version? The Release
Candidate? The Gold Master? The first client installation?

Moreover, it should be clear who accepts the deliverables. Should the
development team decide when they're done? Should QA sign off on the new version?
Should management, sales or customer service have a say in it?

Without a clear deliverable, there's the inevitable gap between what the
project team thinks they should deliver, and what the project's client
expects. 

But how can one get a clear deliverable from the project client? Often, the
project's client, be it management, the market or an actual client, has a hard
time expressing what they want precisely.  It's up to the project manager
to provide a clear deliverables list on which both parties can agree on. 

The project's preliminary task list can serve as a good basis for the
deliverables. Which features should be included in the software? Which bugs
should be fixed? This is a good starting point to answering the who, what,
where, when, why, and how of your project:

Who decides when the deliverable is ready?

What will the deliverable include?

Where will the deliverable be provided? Online? As a hard copy?

When is the delivery planned? Is there any leeway in this date?

Why are we even doing this project? This serves as a good reminder of
the project's objectives.

How will the deliverable be produced?

 

If it's hard to answer all those questions, or if your client refuses to
answer some of them, you should be worried.