Eight (previously seven) 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 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 better understanding of a disease is not a good deliverable. It's an excellent objective. A dataset and an analysis report on the mechanism of disease are good

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 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 standard that can be used to align everyone around a common protocol and thereby enabling better comparison of results is exciting. It is exciting if what you care about is innovation

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.

8. Deliverables are strategic: I have heard from individuals who review grant funding proposals that the first thing they do is flip to the deliverables table. They then read the deliverables list without knowing anything else about the proposal. If they can't understand what you are proposing from the deliverables they downgrade their assessment. They are also strategic in that they can form the basis of the discussion around intellectual property.

This last point is the most important.

Aside from making sure you have met all the first seven points it underscores the importance of communicating your deliverables clearly. It is, for example, a good idea to organize your list of deliverables in different ways such as grouping them by deliverable type. You could list datasets, manuscripts, biomarkers etc.

Clear deliverables make it is easier to discuss who is going to contribute to a deliverable and how much ownership they will share with the others. The real opportunity is then being able to 'horse trade' intellectual property.

What the strategic nature of deliverables tells us about innovation

What I have learned over the 15 years since my first encounter with deliverables is that their strategic importance is a reflection of the fact that innovation requires more than good science.

Innovation is about effectively translating good science into impact whether that be a product, a piece of technology, or in the case of the life sciences a new therapy or a whole new way of understanding a disease that is put into practice. It is not just a good idea published in a high impact journal. It is a change in the way individuals who are suffering from a disease are treated and managed.

Moving from excellent science to innovation requires leadership. It requires leaders who do the hard work of thinking about what is really needed to make a real difference. Thinking about deliverables as part of a strategy that translates science into benefits for patients is what leaders do. And by the way that is what reviewers also want to see in a proposal.

Together

I am always delighted to see the power of thinking together. If you have ideas to thoughts on this post you can join the conversation on Linked In, or Twitter #Deliverables

If you believe that we need more leaders focused on accelerating healthcare innovation through collaboration check out our Vision-Driven Leaders in Healthcare community.

The post was updated on 13/12/21 with some additional text and revisions.