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:Writer : Developer Ratio (Summary) From:"Dawn C. Lindley" <DLINDLEY -at- ECS-INC -dot- COM> Date:Fri, 2 May 1997 10:40:39 -0400
Good day:
Here is a summary of responses in reply to my plea for cold, hard facts
that I could use for convincing management to add one or more writers to
our documentation team. I posted this request because the project
manager asked me if there was any such animal as a "writer to
developer" ratio he could use.
RATIO-RESPONSES
Half of the responses suggested a specific ratio. Almost all of the
ratio-suggesters said that 1 writer for every 5 developers was plenty.
One said that 1 writer for every 3 developers was "ideal." Another said
that a ratio of 1 writer for every 7 developers was "nosebleed-high."
Several people said that the ratio depended on how well the project was
managed. The more chaotic the project, the more technical writers
needed.
One person mentioned that staffing would vary depending on what the
developers are coding (are they fixing bugs? are they changing the
functionality?) Another said to keep in mind that it takes more time to
write to a technical audience than it does a typical user.
PROJECT MANAGEMENT RESPONSES
A majority of the responses urged me to map out concrete time estimates
for the remaining activities. Estimating methods included:
o Using this formula from Steve McConnell's _Rapid Development_
# developers * # months = X
# techwriters * # months = Y
(20% * X) - Y = # of techwriters needed for project.
o Keeping metrics.
o Reviewing the labor hours it has taken me this far per manual and
using that to project future manuals.
o Putting the labor hours in MS Project.
o Contracting temporary writer(s) until the need lessened or was
clearly determined.
Several people suggested that it might help if the development team used
a methodology to control their releases. One person wrote: "If new
releases are constantly being thrown at them willy-nilly, the customer
has to spend too much time trying to figure out what has changed."
BIBLIOGRAPHY
JoAnne Hackos has a real fan club out there. Her book _Managing Your
Documentation Projects_ was recommended several times.
Also: _Rapid Development_ by Steve McConnell
and: _The Business Side of Writing_ by ?? Schultz
THANKS
These people provided terrific input that's going to rock my world for the
better: Jane Pilsworth, David Locke, John Wilcox, Barbi Harrison, Keith
Soltys, Bill Sullivan, Dan Roberts, Chris Hamilton, Steve Shewchuk, John
New, Doreen M, and Erik Harris.
----------------------------------------------------------------------------
Dawn C. Lindley
dlindley -at- ecs-inc -dot- com (work)
lindley -at- usa -dot- net (home)
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
