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.