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: Walk-throughs From:Steven Jong <SteveFJong -at- AOL -dot- COM> Date:Thu, 4 Jun 1998 15:17:10 EDT
In describing an up-front walk-through meeting with representatives of other
organizations (such as engineering, product management, support, and
marketing), several people have complained that the group is easily
sidetracked, and that "doc" issues often are not addressed. Coming from a
background of using structured documentation methodology, I have a different
perspective on this: this is not a problem, it's an opportunity!
Three critical things we need to do as technical communicators are: (1) to
participate as full-fledged members of the product team, (2) to work as
efficiently as possible, and (3) to add value to the product. I think an
early, cross-functional meeting accomplishes all three things. (The emphasis
here is on "early"--a meeting late in the cycle that goes astray is a problem
for sure.)
1. To be a member of the team, you have to be with the team and support the
team's goals. Just convening such a meeting is a victory in this regard. As
for the "side discussions," *they're not side issues to the participants.*
I've never conducted a user-topic brainstorming meeting (which in the
structured doc process is an early milestone) without having fundamental
design issues come up. The time to get these issues out in the open in early
in the development cycle; and the participants will thank you for it.
2. Inefficiency is scrap and rework. To me, the most inefficient thing you can
do is to write something that shouldn't be written. Better that design issues
come up at the beginning of the cycle than over the corpse of your final
draft! I say let them argue as much as they want, and document what's left.
3. If the documentation meeting turns into a design review, that's a good
thing for the product, and you are adding considerable value by providing the
forum. By conducting yourself professionally and focussing on users and their
needs, you are laying a sound foundation for good user information, and that
adds value as well. (The fact that you're doing it right in front of the major
players on the project doesn't hurt either!)
-- Steve
=========|=========|=========|=========|=========|=========|=====
Steven Jong, Documentation Team Manager ("Typo? What tpyo?")
Lightbridge, Inc, 67 South Bedford St., Burlington, MA 01803 USA mailto:jong -at- lightbridge -dot- com -dot- nospam 781.359.4902 [voice]
Home Sweet Homepage: http://members.aol.com/SteveFJong