Re: Maintaining Documentation

[Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>]

You don't mention the kind of products you work with, but a strategy 
that mirrors the way they are maintained might be of some use to you. 
With software, for example, I follow a change control/maintenance 
methodology similar to what the software product goes through. Bugs, 
i.e., error correction and rewrites, are prioritized for subsequent 
editions of the documentation (releases); new content is scoped and 
integrated as necessary to fit the release. When someone asks for a 
change that doesn't match am upcoming feature or function, then I plan 
out what is required and how I'll make that documentation change, and go 
through the same process as the developers do for a new feature.

If you don't know the plans for product development, this is a good 
reason to invite yourself into that process. You can tell them that you 
need to be included in the development so that you can develop the 
updates to the documentation. If you can get your product creation 
people to see your role as parallel to theirs, it's easier for them to 
understand how you work and what you need.

Another idea is to brainstorm, yourself or with other knowledgeable 
people, the kinds of changes that might be necessary to your 
documentation. Then you can plug those into your strategy. Will you need 
to write release notes, for example, for only a few customers to cover a 
limited-release fix? Will you need to customize documentation for a 
particular market? How will you handle changes that are common to both 
documents versus the ones that are unique to each document? Most of this 
will end up being whatever you decide is the right thing to do for your 
situation.
--Beth

Kimberly McClintock wrote: