STC Conference Proposals

["Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <geoff-h -at- MTL -dot- FERIC -dot- CA>]

Steve Murray wondered about how to get approved to go to the STC
conference. I'm not providing my proposal from last year, because
it's too contextual to be useful to most people. Instead, I'll
provide a suggestion that's broadly applicable, and that makes
for a really good practice exercise in audience analysis and
technical writing. So even if you lose, you win.

The audience analysis part: Most managers are more concerned
with the bottom line than with intangibles such as "staff
development", so focusing on that aspect of the conference is
usually the most productive approach. (Managers who actually
have an enlightened and proactive approach to training might approve
you simply based on a conversation and a verbal sales pitch. Even
brass tacks managers will generally react most favorably if you
broach the topic in person before submitting a proposal. Start with a
conversation, then...) Which of the problems that _your company_ is
currently facing do you intend to solve through your attendance? Go
through the preliminary program and identify all the sessions that
specifically and directly address those problems, and explain how and
why they'll help you to solve the problems. If you can provide cost
alternatives (e.g., for local training sessions on these subjects) to
demonstrate that the STC conference (including travel and
accomodation costs) is a better deal--which it often is--add those
details too. Intangibles such as "helps me keep up to date in my
field" and "provides valuable information on how others have already
solved our problems" are helpful, but generally work better in an
appendix than as part of the main text of the proposal. Gather all
this information into at most 2 pages, written as concisely and
clearly as you can achieve, and use all the good layout and
rhetorical tricks you've used in your documentation to make the sales
pitch. Then sit back and hope... Accept the fact that attending
simply may not be in the cards, particularly if your department's
budget is under pressure. But if you keep submitting proposals over a
few years, the odds are good you'll eventually be approved. The
squeaky wheel... <grin>

Re. Engineers/programmers and usability: I haven't been following
this discussion very closely, but it seems to me that one thing has
been missed. That's the notion that usability is a discipline unto
itself, and one that is just as complex and involved as technical
communication. Just as some engineers can become decent writers with
coaching and practice, techwhirlers can become decent seat-of-the-
pants usability workers... but we're not going to become experts
without putting in the time and obtaining the training that a full
usability expert acquires. Simplistically, it's a matter of
practice: the more you do it, the better you get at it. That being
the case, it's not logical to expect programmers and engineers to
become usability experts given the challenges that they already face
just keeping up to date on their own field and meeting deadlines for
(relatively) bug free code or glitch-free hardware.
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca