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:RE: Good Enough From:"Blount, Patricia A" <Patricia -dot- Blount -at- ca -dot- com> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 1 Oct 2008 09:06:34 -0400
Hi, Craig,
<grin> Man, does THAT bring back memories...
When I first started here in 2001 (education department, now
outsourced), we were tasked with defining quality. That was the
definition our management team came up with - "Can it teach?"
I think by nature, tech writers tend to be perfectionists...always
looking for the perfect word, the right grammar rule, the best tool, and
so on. To a great degree, that tendency is evident on this list, right?
Back in those days, our process was linear and the tech writers got the
hand-off at the very end of the development process. Guess what? Their
time was always cannibalized by other team members along that linear
path. Frustration was always high and palpable, particularly since 90%
of the content was coming from other sources. The writers had to format,
polish and force it into our standards and when they looked at the
effort required to do so, often in as little as a week or two, emails
used to flare.. ("This is impossible!")...
Ah, the good old days <tear>.
As time went on, the process changed, the team changed, the standards
changed and even the schedule changed. Naturally, the definition of
quality had to change, too. I remember my boss on a conference call
explaining the old adage, Good, Fast or Cheap - pick any two.
He told us we could have all three if we tech writers just let go of our
perfection. <growl, hiss>
Once my feathers unruffled, I conceded he had a (small) point. We used
to get so passionate about things like serial commas (to be or not to
be??), split infinitives and the proper use of collective nouns that we
often lost sight of the bigger picture: Lots and lots of money was on
the table for these finished courses. We can't take months to write them
or we'll lose that opportunity. Customers can forgive these various
slights of grammar and usage provided they walk out of that classroom
knowing how to use the software we sell better than they could before
they went in.
Every project, not just writing projects, has certain constraints and
business goals. I think good writing (including grammar rules) should be
among those objectives but the truth is no customer has ever contacted
tech support at any of my employers to compliment us on our
grammatically perfect manuals and probably never will. I think the best
we can hope for is no complaints. They will, however, complain loudly
about faulty procedures, missing steps, poor examples and the like.
Those are the things we had to focus on to make the course "good
enough."
And that's how "good enough" was born. The writers were responsible for
peer editing each other's work, putting on the polish and making sure it
was grammatically good, but no more debates on whether Arial or Courier
should be used for code. Pick one, stay consistent, move along, do not
hold up a project on trivial matters. Reviews evolved to focus on
technical quality and yes, our smile sheet scores did improve
significantly because the customers cared more about learning the right
tasks than they did about fonts, commas and grammar rules.
I think "good enough" quality has negotiation room. There are various
things that need to be included in documentation for compliance or
government regulation purposes. I used to do a lot of "before & after"
proposals. Someone would send my boss something, I would take it and do
nothing more than format it to our standards and a light grammar pass.
At the end, I added a conclusion paragraph explaining the things that
were missing ("Where's the customer benefit to doing this? Where's the
risks of NOT doing this? What triggers the user to do this?? If we
change this, this and this, we can ALSO use this text in the
website...") and most of the time, my questions were answered.
That manager has retired and boy, I still miss him. We butted heads a
lot but overall, he made me a better writer.
ComponentOne Doc-To-Help gives you everything you need to author and
publish quality Help, Web, and print content. Perfect for technical
authors, developers, and policy writers. Download a FREE trial. http://www.componentone.com/DocToHelp/
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
