Re: Sanity Check

[GFHayhoe -at- AOL -dot- COM]

Yesterday, Janet Renze asked for a sanity check after a recent experience
with proposal writing in which her company asked her to spin gold from . . .
well, this is a family listserve, so I won't specify the substance.

Janet, there's certainly nothing wrong with your sense of how a proposal
should be written. I'd say the major problem is that your company's
leadership seems to be studying project management out of "Dilbert" strips.
(In fact, if Scott Adams is reading, he's probably gotten an idea or two from
what you've told us.)

After your company loses this bid, how can they correct the problem and
ensure that you add value to the project the next time out?

Well, first they have to realize that for a technical communicator to ADD
value, there must be value to the project to begin with. The situation you
describe is nothing more than wasted effort on the parts of all concerned.
You can't write a proposal without information.

You should have been involved in the proposal effort from the get-go,
attending the meetings and participating in the discussions (AFTER all of you
on the team had read and analyzed the RFP in advance). You would have been
able to help them identify the questions they needed to ask the prospective
client to obtain the information needed to respond adequately to the RFP.

I can't tell you how many proposals I've read (in an earlier life as an
employee of a government contractor) that failed to respond to specific
points of an RFP and were thus excluded from consideration. A technical
communicator worth his or her salt would always prevent that problem. It's
hardly rocket science. Those evaluating a proposal are looking for specific
information on which to base their decisions. When that information is not
provided, the proposal is deep-sixed. It's as simple as that.

Before talking to your management, I'd suggest you read Denise Pieratti's
case study "How the Process and Organization Can Help or Hinder Added Value"
in the Value Added special issue of _Technical_ _Communication_ (42:1,
February 1995). It should provide additional insight on how to fix the
problem.

--George Hayhoe
  Editor, _Technical_Communication_