Proposal writing: The key to getting business

ITworld.com –

Developing proposals is something that most new consultants dread. It is an intimidating task with no clear roadmap, but it is key to obtaining business. With the right approach, a proposal doesn't have to be time consuming. Even if you don't get the business, the process can help establish a relationship that may bear fruit in the future.

I've described previously (Clients: How to get them) the process of finding work, so our starting point is a client who has a need. If a client's need just doesn't match your skills, rather than turning down the job outright, consider referring the work to another consultant to develop goodwill with both the client and the other consultant.

Even if you think you know what your client needs, you need to probe deeply to make sure there aren't any hidden agendas. Clients have asked me for an analysis of a technology when they actually wanted to kill a project but wanted an objective person to give it the deathblow. By understanding the real need, you can structure your proposal accordingly. So engage your client in a detailed initial discussion, whether by phone or meeting. Remember the old adage that you aren't learning if your mouth is moving. Sometimes the client has only a vague need whereas other times the client already has prepared a work statement. Obtain whatever information you can, including related reports or specifications that the client may be willing to give you.

Armed with that information, you still don't want to rush into a detailed proposal. Use a phased approach instead. Begin with a preliminary proposal of one or two pages that clearly spells out the deliverables to the clients. State everything in terms of what the client will receive, not what you will do.

For example, "I will research this market" is weak compared to "you will receive a list of competitors and their current market position." You may need to include a price quote at that stage, but generally I try to defer that to the next phase. Indicate to your clients that the purpose of the preliminary proposal is to articulate your understanding of their needs and that you need their feedback to fine-tune and expand your proposal. By involving your clients that way, they will develop a sense of equity in and take ownership of the project.

Now you can develop a more comprehensive proposal. But don't go to the trouble unless you receive a positive indication from your client. The beauty of that approach is that you only invest the time to write a detailed proposal when the chances for its acceptance are good. If you've listened well along the way -- and with some luck -- the preliminary proposal may be all you need.

As for the actual format of the final proposal, there are no strict rules. Given how busy people are, it's probably best to minimize verbiage and to deliver the key information in concise bullets or in outline format. I usually have an introductory paragraph that states the situation and the general problem to be solved. If the deliverable is a report, I include an outline of the report. If the project is research oriented, I summarize my intended sources of information, the questions I will address, and the methods I will use.

If the project is on a fixed fee basis, I articulate the deliverables clearly so that if the client asks for additional items later, I can indicate that those are beyond the scope of the original project. But to keep the proposal friendly, I don't actually include language saying that any changes will require a renegotiation of the fee. As discussed in a prior column on rates (Setting rates: How high should you go?), I build buffers into fixed fee quotes to allow a little additional work without charging more. That does wonders in developing client loyalty.

Including a cover page and a table of contents, most of my final proposals run about five to ten pages, with more time-consuming projects meriting longer proposals. I don't include any disclaimers or legal boilerplate and simply refer to my Website for background information about my consulting services. My last paragraph contains my terms and conditions, which I keep brief, mentioning only the fee and delivery dates. I put other items such as invoicing details in another document called the agreement, the topic of our next column.

Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies