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: Re: Best Documentation From:"David Slonosky" <David_Slonosky -at- i2 -dot- com> To:techwr-l -at- lists -dot- raycomm -dot- com Date:Wed, 9 Feb 2000 14:39:45 -0500
>And, the older I get, the more I believe in the old saying, "Believe none of
what you hear and only half of what you see."
Unless you are a special class of entity, this of course applies to your own
anecdotal evidence, compiled as it may have been over fifteen years. :)
I think the real crux here is by what you are using to measure the success of a
writing project. In Tony's case, it seems to be that the project model flow was
adhered to and a product delivered at the end. In other peoples' cases, it seems
to be that the quality of the end output of the writing cycle is the determinant
I don't think you can categorically state that a perfect process always leads to
a document or other deliverable that is useful to the end group of users. Just
as you cannot state that the lack of a perfect process leads to a sloppy
disorganized mass of writing. There are too many variables in any project to be
able to state things with this sort of absolute finality.
I think a good process definitely makes the documentation process much easier.
But if it takes forever to set up a good process because of lack of cooperation
from groups that you have no control over, then a less than good process might
still enable you to deliver something that is worthwhile for your users. In my
opinion, the problem with stating that Process Is All implies that you will
always be able to get buy-in from people who have no direct investment in or
gain from a clean and well-written final document.
"Anthony Markatos" <tonymar -at- hotmail -dot- com> on 02/09/2000 11:30:19 AM
Please respond to "Anthony Markatos" <tonymar -at- hotmail -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
cc: (bcc: David Slonosky/Markham/CA/i2Tech)
Subject: RE: Re: Best Documentation
Corinne Backer said:
Okay, now we've lost sight of reality. Come on. Of COURSE it happens!
Projects DO fail due to lack of [writing] skill ........You can't Plan and
Standardize an unintelligible sentence into helpful instructions; you've
gotta have someone at the keyboard who can write.
Tony Markatos responds:
In fifteen years of technical communications experience (both as a TW and as
a Systems Analyst), I have never see a project run into significant problems
because of poor writing technique. And, the older I get, the more I believe
in the old saying, "Believe none of what you hear and only half of what you
Don't get me wrong, I have see all kinds of failure (i.e., lack of skill).
It is just that writing technique has not been a major issue.
Sponsored by Weisner Associates Inc., Online Information Services
Training & consulting for RoboHELP, Dreamweaver, HTML, and HTML-Based Help.
More info at http://www.weisner.com/train/ or mailto:training -at- weisner -dot- com -dot-
Your web site in 32 languages? Maybe not now, but sooner than you think.
Contact ForeignExchange for the FREE paper, "3 steps to successful
translation management" (http://www.fxtrans.com/3steps.html?tw).
You are currently subscribed to techwr-l as: David_Slonosky -at- I2 -dot- COM
To unsubscribe send a blank email to leave-techwr-l-7459V -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.