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: At what point do you grow a dept.? From:Chris Knight <knight -at- ADA -dot- COM> Date:Mon, 13 Jul 1998 16:11:30 -0700
Rowena Hart wrote:
> How did you determine it was time to grow?
> Was it...
>
> Because you could not supply "deliverables"
> to project managers within the time frame(s)
> they demanded?
>
> Because project managers were demanding
> "deliverables" in areas you were not trained in,
> or that it would take too long to become pro-
> ficient in? ie. page layout and design, online
> help, marcomm, HTML and web page design,
> technical diagrams and graphics...
>
> Because you were working too much overtime
> and getting burned out?
>
> Because the company saw a growth spurt ahead
> and actually planned to hire another technical writer?
Any one of the above would be a good-enough reason. More than one would
mean do it yesterday.
I'll add a couple more:
Because your customers are complaining about the quality or timeliness
of your publications.
Because your customer-support people or field-service people can't find
what they need in the documents within 10 seconds.
Because your technical people are complaining that it takes too much
time to explain things to the tech writers.
In other words, quality is an issue, and quality takes time and
resources. You may have competent writers, but never enough time to go
beyond "just make sure it's accurate". Quality includes accuracy, and
timeliness, but it also includes consistency between manuals (one of the
first thing to suffer when ther isn't enough time). It also includes
organization and accessibilty, and this is often lacking when writers
are hurried, or don't have sufficient technical knowledge to model the
users properly.
Hope that helps.
--
Chris Knight
Consultant, Technical Communication Architect
Vancouver BC, Canada
(currently at Applied Digital Access,
E-mail: knight -at- bcg -dot- ada -dot- com Phone: 604-415-5886 Fax: 604-415-5900)
Opinions expressed are my own, not ADA's