Define the Deliverables on Your Projects

Here is a practice that is very simple, but very powerful.

Whenever you have a new project (either created/identified by you or assigned to you), one of the first things you should do is define the deliverables for the project.

The deliverables on a project are the specific work products that you have to produce in order to complete the project.

For example, if the project is to create a new policy on this or that, the deliverables might be (1) collected research of the various policy options and then (2) a completed policy document. If the project is to set up a new room in your house, the deliverables might be (1) furniture (2) stuff for the walls and (3) a room that is arranged and put together.

Defining the deliverables is really just a component of asking “what’s the intended outcome?” It helps to clarify what the project means and, therefore, how to complete it.

Now, here’s the most important thing about this: Defining the deliverables directs your attention to outcomes rather than activities.

Activities are not necessarily productive. Many of the activities we do are not necessary. When you think about your projects, if you think first in terms of “doing activities” to get them done, your mind will probably create a lot of unnecessary work. This is only natural — if you think that doing a project means doing activities, that’s where your focus will go and your mind will have no shortage of ideas.

On the other hand, if you think first of deliverables, your mind is directed right away to outcomes instead. This will immediately filter out a whole bunch of activities and cause you to identify and focus in on only the activities that are actually essential to the project.

This will save you time and provide you with better results.

March 20, 2009 | Filed Under Planning | 6 Comments 

Comments

  • Duncan

    Matt -

    nice post – My only comment is along w/defining the deliverables expectation of what those more “untangentialble” deliverables should be defined…

    I guess this applies more to a written report or something that a physical deliverable is not presented to the person…

    being a consulting engineer – i found that defining just deliverable has failed me more times then i care to admit… now i define the expectation of how the deliverable can/will be used…

    hope that makes sense…

  • Matt

    Duncan,

    Defining (at least in your head) how the deliverable can/will be used makes a lot of sense. That has an effect on the nature of the deliverable.

    Defining the “non-delivered deliverables” — that is, the work products that aren’t passed on, but are inputs in your process of creating those that are — is also essential.

    Matt

  • http://www.shanticonsulting.com TJ

    This issue is painfully relevant to us. Even the non-deliverable deliverable must be outlined and projected clearly, else the scope or client expectations run amok. Can you recommend some basic tools for guiding the defining of deliverables, particularly in multinational projects where English is the trade language?

  • Matt

    TJ: I’ve found these two books especially helpful on project management, each of which gives some treatment to the concept of deliverables: The Art of Project Management (now called Making Things Happen) and Teach Yourself Project Management in 24 Hours. Also, the Project Management Professional Study Guide by Kim Heldman, et. al. (it’s basically an 800 page textbook, but it reads very well).

    I can’t think of any resources off hand that focus in very much on multinational projects, although the PMP Study Guide mentioned above does hit on the multinational side of things off and on.

  • Pingback: Define the Deliverables « Ever Heard of It?

  • Pingback: How Much Is A Memorable Logo Worth? | GROWMAP.COM