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: SUMMARY: If You Were Gonna Teach... From:Tom Murrell <trmurrell -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 8 Mar 2002 17:07:37 -0800 (PST)
--- "Grant, Christopher" <CGrant -at- glhec -dot- org> wrote:
> Thanks, Tom, for posing an interesting question and summarizing the results.
> I wanted to clarify the PURPOSE of this "writing instruction" for SMEs. Is
> it:
>
> A. To improve the quality of materials that SMEs give to technical writers,
> or
>
> B. To improve the quality of materials SMEs generate for their own use, or
> otherwise.
And the answer is...Yes! (I know it's a most unsatisfactory answer, but I'll
try to explain. We have two technical writers in an organization that needs
six. But since the very concept of technical writer was a novelty here when I
joined 4+ years ago, we've made quite a bit of progress. Really.
Within the past 4+ years, this organization has put a software development
lifecycle process in place, built a library of documentation, begun to exploit
the concepts of Requirements Documents and Design Documents. Obviously, two
technical writers cannot do everything that is needed. We can't even restrict
ourselves to an editorial role. So we have documentation information coming at
us from all quarters that we basically publish as is, while we restrict our
activities to "important" documents or documents going to people outside the
department. It ain't a perfect system, but we're making do as best we can.
So, management, which recognizes that we do have some utility but doesn't have
the budget to expand our activities, wants us to help improve the quality of
the writing being produced by Business Analysts, Database Analysts, Developers,
and Project Managers. This improvement would also spill over into documentation
that we two use as source materials for still other documentation.
Make sense? (I didn't think so.)
> Please forgive me if this is already clear - I tried to read over the thread
> and was unable to definitively determine this.
>
> If it's B, then I understand and agree with the results in the summary.
>
> But if it's A, then I totally do not understand the results. If the purpose
> of the instruction is to improve the material given to technical writers by
> SMEs (source material) then.... aren't we basically trying to offload OUR
> job responsibilities onto the SMEs?
I wouldn't agree that we would be trying to offload our responsibilities on
SMEs. I take the generic position that everyone can benefit from improved
communication skills. If the object is to get the information from those who
have it to those who need it in the most productive manner, then whatever we
can do to improve the communication skills of SMEs will benefit the entire
organization. And not just in source materials, either. Heck, if we improved
the email communication that alone would result in a productivity increase.
> Why should a SME care about grammar, passive/active voice, punctuation,
> acronyms, spelling, and styles (their impact on the clarity of the
> information notwithstanding - if the grammar is so bad you can't decipher
> it, then yes, they need to learn a little.) These items are the
> responsibility of the technical writer, not the SME.
When an SME team writes requirements that another SME team has to turn into a
Design (and I'm not involved at all because I'm working on something else
that's more important), both sets of SMEs need to be communicating well. This
is the situation where I'm working. It doesn't fit the archetypal mold of a
Technical Publications Organization. We're nowhere near mature. (I have no
opinion on whether or not that's a good thing.)
> What bothers me most about the summary here is that I don't see on it what
> is, IMHO, the single most important thing that SMEs need to know: PROVIDE
> COMPLETE AND ACCURATE CONTENT. I really don't care if the source material
> is delivered to me on a paper plate and written backwards so I have to hold
> it in front of a mirror to read it, as long as the content is accurate and
> complete.
Actually, I think there were a couple of items relating to improving content.
However, I'm willing to concede that I might not have worded it clearly enough.
(It's also possible that I saw that in the raw posts but somehow left it out of
the summary. In either case, I know it was mentioned, and any oversight in the
summary is mine and not the original posters.)
That said, I too will take content however I can get it. I'm used to doing
whatever it takes. I've even done taped interviews when that was the only way
to get information out of an SME.
> I'm not trying to start up the "are you a writer" debate again,
...and since I didn't READ that frivolous debate after the first couple of
posts, you won't start it up with me, either. <g>
> Again, thanks for asking the question and summarizing the results. I was
> just a little perplexed by it, and wondered what you and others thought.
And, as I said, I knew I had seen such comments. Somehow when I was putting
together the summary, my head was elsewhere. My apologies for the confusion.
You'll never hear me argue against complete and accurate content in technical documentation.
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.
www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
