In praise of technical proposal writing

Subject: In praise of technical proposal writing
From: "Stitzel, Ken" <kstitzel -at- itc -dot- nrcs -dot- usda -dot- gov>
To: " (techwr-l -at- lists -dot- raycomm -dot- com)" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 5 Feb 2004 17:24:59 -0700

I worked for the better part of a year in a small group that wrote technical
proposals for engineering hardware and software and networking. I liked it
much better than "standard" tech writing. Here's a few observations:

* It calls for a different _style_ of writing. So much of tech writing is
typical procedural stuff, information mapping, etc., which can make you feel
like you're Mr. Roboto sometimes. Proposal writing calls for you to be both
cautious and subtly persuasive, even when describing technical details.

* You are basically writing a contract. Our proposals were legal documents
that the customer could sign, thus obligating our company to do a whole
lotta stuff. Our legal team reviewed every proposal to avoid expensive
overpromises. Again, you had to be very careful about what you said.

* The RFP always gives you your outline. You tailored your response to
exactly match all the questions and requirements in the RFP. Each one was
different, so no two proposals were exactly alike, even though we had lots
of standard stuff for each. (We had a good library of previous proposals, so
sometimes we could find one that was similar to our current effort and do a
makeover on it.)

* The RFP always gives you your schedule. The submittal deadline (less
delivery time) was the absolute deadline, and you worked backward from there
to set up your process.

* Things went smoothly because I had a great, smart boss. Even worse than
any tech writing job I'd ever had, people would try to get things written
into proposals at the last minute. This had created huge spikes in the
workload for the writers, lots of late nights. So, Da Boss had worked very
hard to set up hard-and-fast intermediate deadlines for the rest of the
company: a go/no-go decision meeting; deadlines for getting technical
content to the writers; deadline for technical reviews; deadlines for legal
review; deadline for final editing; deadline for delivery. If any of these
deadlines weren't met, we would not guarantee that the proposal would go

* Management bought into our process because there was a clear advantage to
the bottom line for a winning proposal.

* Because RFPs have a fairly short fuse, tools didn't matter so much. We did
everything in Word because it was quick, but we did each chapter/section of
the proposal as individual files and created a table of contents manually.
It was the only time in my career that I've felt Word was a good tool for a
big document (really just small docs flying in formation).

* Variety was one nice thing about proposals. Once they're done, they're
done. You take your best shot, and you get the bid or you don't. Then it was
too late. Other than occasionally being able to do a complete makeover, you
never had to revisit an old proposal. (This seemed quite refreshing after
doing some years-long maintenance projects on some ultra-boring manual set.)

* I think it was partly due to our writing department that our smallish
company was right in there competing with some of the biggest shots there
were (e.g., IBM).

* I also liked writing proposals because it gave you a better view of the
Big Picture--how stuff was put together, the full range of services the
company provided, how we were perceived by customers, etc.

* Drawback: we were part of marketing, and I had to wear a tie! :)


Previous by Author: Re: Where does Documentation belong?
Next by Author: Re: Best idea of the week, make that year. Yeah, yeah, I know the year just started
Previous by Thread: Usability of candidates' Web sites
Next by Thread: Road Rage vs. MS Word Rage, is there a difference?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads