Re: Copy of: Tec Pub's Reporting Structure

Subject: Re: Copy of: Tec Pub's Reporting Structure
From: Karen Gwynn/Datatel <Karen_Gwynn -at- DATATEL -dot- COM>
Date: Tue, 23 Jan 1996 09:52:34 EDT

I sent this to Bob Boeri in response to his original posting. Since there was
someone else with a similar interest, I decided to post to the list.


I work for a software development company. About a year ago our structure
changed. Previously the documentation specialists (the technical writers at the
company) reported to a single manager and who reported to a director in our
Services division. Under this structure each doc specialist was assigned an
area of responsibility that roughly corresponded to one of the major areas of
our product line. However, it was very common for a writer to "project hop" as
resources were needed. In other words, even though I was responsible for area
"S," if that product line did not have an immediate release (note: this is not
the same as immediate development!), I could be assigned to work on
documentation for area "P." This in fact, happened often.

Now, however, each documentation specialist reports directly to a technical
product manager. Under this structure we remain assigned to the documentation
projects associated with that product only. So now I am on the development team
for area "S," and that's all I concentrate on (and in my current assignment we
have just delivered the beta software for a release that is scheduled for
general delivery in July 1996. I have been working on this project--and this
project only-- since November 1994.

Overall, the new reporting structure is much better. We are able to concentrate
on a single software product (although this is not to say a single
documentation product!) and have the opportunity to begin planning and writing
our documentation earlier in the product life cycle. In addition, as part of
the development team, documentation is less likely to get caught out of the
loop, since we are on the same team as the development staff, reporting to the
same manager.

However, this structure is not utopia. One of our biggest concerns/issues is
quality control across product lines. We do not have a corporate editor (one or
more individuals dedicated to editing technical--or other--documents). Editing
is done as peer edits, usually by the writers on the same team. This poses a
major problem for teams with only one writer (this situation exists).

General writing and design standards are, so far, handled fairly well. We had a
good set of standards before we moved to the product development teams, and all
writers are part of what we call the Documentation Coordination Committee. As a
group we decide standards issues and resolve other issues that affect all
writers (for example, hiring and training new writers).

Despite the drawbacks, I feel that, at least for our company, this structure is
the best way to go.

(FYI, a colleague and I will be presenting this very topic at the 1996 STC
convention in Seattle!)

Karen Gwynn
kwg -at- datatel -dot- com


Previous by Author: Re: Impressions of Information Mapping
Next by Author: Re: Quality/validation (long)
Previous by Thread: Copy of: Tec Pub's Reporting Structure
Next by Thread: Impressions of Information Mapping


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads