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 ( http://www.itworld.com/Career/3656/ITW899/>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 ( http://www.itworld.com/Career/3655/ITW1325/>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.

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine