PROPOSALS/PRESENTATIONS

["Parker, Cassandra M. (EXCH)" <CMPARKER -at- INTERMEDIA -dot- COM>]

TO:  List readers and Kristen,

A few weeks back I had a question about PROPOSALS and some readers asked
me to consolidate and share the responses with them.  Well, here they
are as I received them.

Kristen also asked a question on the list about presentation (maybe some
info. can be gathered from these responses.)


Cassandra

==================================================================

#1 -
There is a proposal writing list. To subscribe send email to
MAJORDOMO -at- GOVSOLUTIONS -dot- COM with SUBSCRIBE PROPOSAL-L in the body. The
group recently (within the last 2-3 weeks) had a series of messages
concerning good books for the beginning proposal writer. You may be able
to search the archives. Also try DejaNews.Com (hope I'm spelling that
correctly) and search there about proposals.

Also try your local public library. Believe it or not our public library
in Sacramento has a non-profit resource center. They have a lot of
material about grant writing which is related to (but not the same as)
proposal writing.

Hope this helps.

------------------------------------------------------------------------
--------------------------------------------------------------

#2 -
I've been doing proposals for quite a while as a writer/editor for a
consulting engineering company and as a free-lance writer.

Proposals are a sort of subset of technical documentation. Similar in
many ways, yet different. There's a lot of carryover from what we do but
there needs to be some unique treatment as well. If you can possibly
spare the time, I'd recommend getting a couple of books at the library
or buying them if you'll be doing much of this sort of work.  They are
The Consultant's Guide to Proposal Writing by Herman Holtz, and The Art
of Winning Contracts, by J. B. Roberts. I'm sure there are others. Also,
STC, in their magazine, has had several good articles about proposals.
Finally, there's a proposal mailing list called PROPOSAL-L run by Carl
Dickson (proposal-l -at- govsolutions -dot- com) that's very good.

Best regards,

------------------------------------------------------------------------
--------------------------------------------------------------

#3 -
I found some useful articles in the STC 44th Annual Conference 1997
Proceedings. Please post your responses cuz I'm interested in learning
more, too. Thanks!

------------------------------------------------------------------------
--------------------------------------------------------------

#4 -
When writing proposals, it's helpful to remember that they are SALES
documents: you're selling someone on the ideas and plans in the
document, i.e., you want them to commit to it, and provide necessary
funding or resources. Proposals are more emphatic when you write as if
the product exists or will in the near future. I use a lot of "will"
rather than "would", as in "XX software will provide users with a simple
means of searching and retrieving their documents across a network", or
whatever.

Be specific, positive, upbeat and honest. If there are areas that are
shaky in the conceptualization of the ideas, address them and show how
you'll overcome them. Be sure to acknowledge and demonstrate how you'll
deal with any risk factors. It's good to include a worst-case scenario
(terrible cliche, but quite useful) as well as an optimum scenario and a
most likely case.

Any business book that deals with proposals (there are many) should help
you out all you have to do is reframe the headings for your particular
product.

------------------------------------------------------------------------
--------------------------------------------------------------

#5 -
Interesting question--haven't seen it on the list before.

When I write proposals, I make a point of using can and will as opposed
to could or would.  I always feel the tone sounds more positive,
confident, eliminated the sense of the unspoken "if you pick us".

So, I wrote:

CCM takes raw data and puts it into a format you can browse at will.  In
the proposed application, human resources personnel will be able to pull
up an employee file and explore data as desired, following a trail of
information without having to run constant queries to retrieve new
information.  Supervisors can access a project file...


------------------------------------------------------------------------
--------------------------------------------------------------
#6 -
I have always found that writing in a proposal about the design or
equipment (whatever it may be) in the present tense is best.  This
allows the reader to get that warm fuzzy feeling that the thing is just
sitting there waiting for him to come get it.  Obviously things such as
test, meetings, etc. to be held in the future belong in the future
tense, as things of an historical nature go in the past.  But what
you're promising to build and deliver should be in the present tense
even if it's still just a good idea.  Make it real to the reader. This
comes from more than 14 years of proposal work of all kinds.  Be glad to
help if you have any other questions.

Hope this helps.

------------------------------------------------------------------------
--------------------------------------------------------------

#7 -
The MOST IMPORTANT THING ABOUT PROPOSAL WRITING is simply

 READ THE RFP/RFQ and follow the RF* EXACTLY.

Second most important thing: work six days then take a day off. You'll
come back with a clear head ready to see/act on the stupid mistakes you
made on Days 5 and 6. Do NOT NOT NOT work 7 days -- and I mean 0 hours
on Day 7. Your proposal will be better and so will your health.

Been there/done that.

------------------------------------------------------------------------
--------------------------------------------------------------

#8 -
I've had a decade or so of experience, if that helps.  Typically, you
are given proposal guidelines in the RFP if that's the process to which
you are responding.  If not, the guidelines depend on the kind of
proposal you are writing.  If it's a business, financing, or marketing
proposal, there are several good books on the subject from Upstart
Press.  They deal with small businesses for the most part but their
guidelines could apply across the board.

If you need more input, please feel free to get in touch.


Proposals I've worked with contain the following:

1.      You must have a cover letter that briefly covers the purpose of the
proposal, the recommendation, and price; and, of course, anything else
necessary to convey that you're the company/person for the job. But
don't be long-winded, most of this info will be in the proposal.

The proposal itself should be bound in a folder/binder/or some other
professional package (preferably). I've seen the cover letter attached
to the outside front cover, but most often bound into the package as the
very first page.

2.      Title Page - including Proposal for (blah, blah), company name,
author/company principal, and the date the proposal is submitted.

3.      Table of Contents, especially if it is a fairly substantial proposal.

4.      Executive Summary or Abstract (often a "higher up" at the company
reviewing the proposals only wants to know the basics and final
recommendation--they refuse to read all the detail).

5.      Introduction - stating the purpose, your view of the situation
requiring work to be done, and your conclusions/recommendations.
Perhaps, you can include limitations of your report and methods for your
information gathering, if it's appropriate. And, you should include a
glossary of terms if appropriate.

6.      The Discussion is the main body of your proposal, which states your
case with appropriate details of how you will complete the work and the
processes that led you to your conclusion.
In many of the proposals I've worked on, a section was included with
each person who would be working on the project from President (as
overseer), Project Manager, Actual staff doing the nuts and bolts of the
project, and often even support staff. Actual names may or may not be
included. Each position included a brief para or two describing the
experience/skills/ and their intended work on the project. This was
further broken down in a following table as to the costs        of each
resource. Full resumes are included in an appendix of each person.
Don't forget to include your estimated timeline/schedule for the
project. I don't believe it has to be real detailed at this point, but
give them and idea of what you'll do and when.  Depending on the
proposal, you might include such things as materials and methods to be
used, benefits that will be gained by using your company, that will be
gained by your product, etc.

7.      Conclusion. Sum up your findings, etc. and how your company is the
best for the job-unique skills, etc.

8.      Recommendation describes how you will put your conclusions into
action.

9.      Bibliography, if appropriate.

10.     Appendixes.

11.     Index (some books recommend this, but I've never seen it done).

Hope this helps let me know how it goes. This format was the one used at
environmental companies, but there's no reason why the same principles
can't be applied to bidding on a software job.

Aside: In my experience proposals are pretty difficult to write and you
should get input from as many knowledgeable people as possible as to the
content. Sometimes, it is even reviewed from a legal perspective. Plus,
most I've worked on must be done and submitted under extremely tight
deadlines. If you're late getting it in, it won't be looked at, in many
cases. I've often driven across town to deliver it by 2:00 p.m., because
the final binding and signing was done at 1:30!!!  Have fun :-)

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html