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: System Lifecycle Management methodology From:Nancy Hayes <nancyh -at- PMAFIRE -dot- INEL -dot- GOV> Date:Wed, 20 Dec 1995 18:15:58 GMT
In article <DJLvIp -dot- 2vE -at- eskimo -dot- com>, Ned Bedinger <qwa -at- eskimo -dot- com> wrote:
Before I start, I've never seen SLM. My experiences come from writing
operations procedures at a chemical processing plant.
>centering around how the methodology doesn't do one thing or
>another very well
Do they have specific complaints, or is it just general gritching? I
know we run into trouble from the "I've done it this way for twenty
years" crowd.
>Has anyone else been in this situation before? Is there a sensible
>way to look at it?
Yes, and I don't know. We have a group analysis of the systems our
procedures are written about. When they first started trying to sell
structured analysis as a benefit, they ran into the same trouble you're
having. It wasn't that people objected to the idea of the analysis so
much as they hated the format of the structured analysis. The analysis
technique was very time-consuming. You had a group of SMEs sit around
and go through every possible scenario about the system. The end result
was a series of "spider-grams"--a flowchart that most people felt needed
Divine translation to make sense of it. We got talking with people and
found out what they actually didn't like about SA: mostly level of detail
and the spider-gram. When we did the analysis but used a more
traditional flow-chart format, people didn't have near as much trouble
with it. We've also allowed for a graded approach: maybe one system
only needs an outline; maybe a more complex one needs the full structured
analysis.
>developers right, that methodologies like SLM are not up to real-world
>documentation tasks?
I think they are, but whether you'll convince them of that is anyone's
guess. I'm assuming you have some before-after type examples that show
why doing SLM saves time, money, review times, etc. If not, maybe you
need to have some examples. Or maybe you're unfortunate enough to have a
group of people who don't like new techniques and won't, regardless of
how logical they are.
Good luck.
Nancy Lynn Hayes | "May your dreams be merry and bright
(nancyh -at- pmafire -dot- inel -dot- gov) | and may all your Christmasses be white."
(OV: NHAYES) | -- White Christmas
