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.
>If you were involved in establishing standards for either a re-write of
>an existing system or the development of an entirely new system for a
>Windows OS, this email is for you. How long did it take your team
>(assuming that these standards were created with a cross-section of
>programmers and end-user advocates (QA, TW) to come to agreement with
>the following?
I spent nearly three years, nursemaiding the Windows version of a very large
program from a shaky beginning to a steadier conclusion.
1. In any group discussion, you can bet that everyone will have at least
five minutes of something to say on each subject discussed.
2. If you have an hour and a half, the group will probably spend forty-five
minutes discussing the first item: agree that they must move on more
quickly: spend thirty minutes discussing the second item: agree that they
must move on more quickly: and spend fifteen minutes discussing the third
item: and agree that future meetings must be more productive.
= Split your group of six up into three groups of two. Have each of the
three groups spend time discussing the list and making concrete decisions.
Have each group send their results to a *small* group empowered to decide on
the options offered, rather than trying to discuss the whole range of
options at the meeting. = (We did this - eventually - and it worked well.)
3. If your company isn't used to Windows OS, a manager or a bunch of
managers can get themselves locked into doing things one way when after
three months the people actually developing the system can tell it isn't
going to work.
= Don't let this happen. I spent over a year locked into a system and
protesting about it, and I kept getting told: But it's too late to change
*now*. When we eventually did change, it took much more time and was much
more trouble than if we'd changed back when I first suggested it. =
Jane Carnall
When all else fails, read the manual.
If that doesn't work, do what it says.
