Assembled Chaos

Working together to accelerate innovation in the life sciences

7 things your mother did not tell you about deliverables.


My first encounter with deliverables was immediately after I agreed to support the preparation of an FP-7 proposal. Before reading the call text, I don't think I had ever encountered the word "deliverable". "What the hell is a deliverable?" I was thinking as I drove home from the meeting where I agreed to enter into the hurly burly that is FP-7 grant proposal writing.

As soon I got home I looked up the term "deliverable". I found this on Wikipedia:

"Deliverable is a term used in project management to describe a tangible or intangible object produced as a result of the project that is intended to be delivered to a customer (either internal or external)."

How does that relate to a biomedical research project?

I had recently moved from the U.S. to Belgium and in the U.S., at least in biomedical research the term "deliverable" was not used frequently or at all. At the time, even with a definition at hand I was still befuddled as to what it meant, and I had no idea about the importance of a good list of deliverables.

Now several projects later having struggled with deliverables both in proposal writing and in the implementation phase I have a much greater appreciation for deliverables.

1. A deliverable is something concrete: A good rule of thumb is that you should be able to post your deliverable to someone. Thus a new target for colon cancer is not a good deliverable. A data analysis report on efforts to identify a new target for colon cancer is.

2. Deliverables should be decided upon early in the grant proposal writing process: It is hard to write about how you are going to deliver something when you don't know what that something is.

3. When it comes to the number of deliverables more is not better: Deliverables are what you have to report on - the more you have the more you have to report. It also does not look realistic to a reviewer if everything is a deliverable.

4. You must be able to deliver your deliverables during the course of your project: This is important when you go to write your deliverable. You should not write "published manuscript" since it can take 6 months to a year to get through the reviewing process. You could write submitted manuscript instead.

5. Deliverables should be meaningful: Deliverables are what you are producing in the project. This is what the money is funding. An SOP as a deliverable is boring, a virtual model of the lung is more exciting.

6. A deliverable is not a task or a milestone: A task is an action, a milestone is a judgement on progress, and a deliverable is a noun - something concrete. In my experience this is often a point of confusion.

7. It is paramount to have deliverables that are consistent with the call text:  Read the call text before you start writing, shortly after you begin, 2-3 more times during the preparation process, and once more before you submit. Don't think you can fool the reviewer. Make your deliverables match the call exactly.