TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Proposal Writing for Large Corporations -- LONG From:Avi Jacobson <avi_jaco -at- NETVISION -dot- NET -dot- IL> Date:Tue, 15 Apr 1997 12:19:12 +0300
Several people have recently posted articles describing the woes of the
proposal writer. Particular emphasis was given to issues like
- The 7x24 stress which gets worse as the deadline approaches
- Intrusion upon privacy (one poster mentioned a client who "popped in"
to collect a document at 1 in the morning and followed him down the
hall to his family's bedrooms)
As a freelance Marketing Technical Writer for a large (~ 2,000 software
professionals), international software firm incorporated in the US but
based in Israel, I would like to comment on three difficulties inherent in
the proposal-writing process. One (I call it the Traffic Cop Syndrome) is
probably fairly common among technical proposal writers for large firms;
the second (the English Teacher syndrome) is specific to tech writers
working with large numbers of programmers and engineers whose native
language is not English; the third (The Derriere-Covering Syndrome) is
probably fairly familiar to all freelance proposal writers.
The Traffic Cop Syndrome
As many of you know, it is often the case that an RFP will include a
questionnaire (often called "Vendor Evaluation Criteria" or "Questions to
Vendor") consisting of anywhere between a dozen and a thousand (or more)
questions regarding the proposed solution and the vendor. These questions
are often highly technical and can require responses of several pages EACH.
This is often complicated by the fact that the customer requires that the
responses be typed into a ready-made matrix which is part of the RFP. (A
favorite variation on this diabolical theme is when the matrix has been
prepared as an Excel spreadsheet -- Excel supports 256 characters per cell,
tops, and most responses are thousands of characters long).
The company's usual methodology for dealing with these questionnaires is to
divide the questions among as many as a dozen "subject matter experts".
Each expert writes his/her own responses to the questions to which he/she
has been assigned. The responses are then forwarded one-by-one to the
proposal writer by their respective authors (for editing and inclusion in
the matrix) before they have been checked by a team leader or other senior
programmer, so several corrected versions of each answer may be
forthcoming. The tech writer, in addition to making sure the answers are
clearly written and properly formatted and that they address the questions
they purport to answer, must spend inordinate amounts of time and effort
keeping track of which of hundreds of questions have been assigned to which
experts, who has answered what, and which version has been included in the
response matrix.
This is inevitably complicated by experts who "trade off" unannounced and
answer each other's questions, duplicate (but different and contradictory!)
responses to the same questions, and urgent telephones and emails saying
"I've been told we're not to mention this recently-developed functionality;
please revert to the version I gave you the day before yesterday." Some of
the responses are received in illegible handwriting with scribbled drawings
and flowcharts -- at times, not even in English (remember: the subject
matter experts are Israeli). Others have been typed by programmers who
insist on placing an <ENTER> at the end of each line ,or on adopting
punctuation conventions taken from the world of C++ ,like the commas in
this sentence.leaving out spaces after a period or forgetting to use
upper-case are equally infuriating.
The process reaches its climax at about midnight or 1:00 am on the night
before deadline, with the tech writer sitting across the table (or at the
other end of a fax line) from a senior team member who is frantically
improvising scribbled answers to questions which for some reason have not
been answer by the appropriate experts.
The English Teacher Syndrome
As I have already mentioned, this particular company's development team
consists of some 2,000 software professionals -- most of them native
Israelis or immigrants from the former Soviet Union with varying levels of
proficiency in English. Often, they will refuse to accept even the most
obvious corrections of their grammar. Characteristically, terms like "fault
rectification" get uncorrected back to "faults rectification". In other
cases, subject matter errors refuse to accept substitutes for such
expressions as "errored messages" or "functionalities" which are extremely
common in internal documentation but are not English.
The Derriere-Covering Syndrome
Most infuriating, in an environment highly charged with the back-biting and
finger-pointing of corporate politics, is the need to write endless memos
and "status reports" (a code word for a document designed to place on
record the fact that someone else -- and not you -- has not done his/job).
These usually center around the fact that someone has not submitted his/her
answers on time, or that the tech writer has received conflicting
instructions from RFP response team members of equal rank, or that the tech
writer cannot possible complete all of the tasks expected of him/her before
deadline time. In other cases, they serve to clarify that someone else --
and not the tech writer -- is responsible for a glaring error or omission
in the response.
- o -
I would be interesting in reading responses by technical writers who have
encountered these problems and found productive ways of dealing with them,
thus improving the efficiency of the organizations they work for and
safeguarding their own sanity.
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
