Stacks of old documentation; who maintains yours?

The user education team in our organization has had and is having varied experiences regarding maintenance of documentation. The biggest questions are who does it and who should do it.

In my situation to this point, I own the files and go back to make changes as needed.

Others have encountered the situation where the department they are writing for wants to own the documentation once the development project ends. They want to maintain it going forward using their own writers or other staff.

Which is better?

The answer isn’t as simple as the question due to various considerations. And don’t forget the situation where you’re a contractor and there’s no one to follow in your footsteps except another contractor down the road.

  • Domain knowledge. After working on the project, you have some and can carry that forward. Fortunately, people in the customer organization have it too. But if a contractor is brought in later to make updates, that person will probably have to start from scratch (unless they hire you again).
  • Documentation skills. One of technical writers’ worst nightmares could be for a non-writer to come along behind and not keep up the level of quality we established in a documentation project. It scares us in a sense to be replaced by non-writers. I created a website for the Utah State University Writing Center while working there as a student, and I was nervous about someone else picking it up where I left off. I had to keep the source files for my portfolio rather than point to the website itself as an example because things would inevitably change. At least it would be maintained by an English major—I assume, though our tutors consisted of students from various programs. You may never know who will be asked to maintain your documentation after you’re gone.
  • Consistency. Will the next person follow your conventions and style? If the organization has a style guide, some consistency is assured. But your successor may not make the same decisions as you do regarding how small to break up procedural tasks, how granular to make a step, and so on.
  • Tool expertise. You probably have a tool or suite of choice for documentation projects. This may not be as big a problem if another technical writer follows you, since the employer will look for someone with knowledge of those same tools. But if they intend to give the content to a non-TC to maintain, chances are that person won’t have a clue how to use your help authoring tool or graphics program. And if they make it a requirement that you use tools that their people can use later, you may be stuck with something like Word.
  • Workload. As time goes on, if you’re maintaining the documentation yourself but you’re also taking on other projects, you can end up with an extensive vault of projects to maintain. You may start to be pulled in many different directions. That’s the possibility I’m faced with. I don’t think the department we are developing for has its own writers. I’m not sure how I would feel if they did and wanted to take doc maintenance off my hands. Maybe I would be relieved.

Each approach has its positives and negatives.

What approach do you take? If you’re a contractor, how do you pave the way for others to pick up where you left off and keep the level of quality up?

Related entries (auto-generated):

Six Things to Remember in Your Documentation Usability Testing

Usability vs. Maintainability in Technical Documentation

Minimizing Confidential Content in Documentation Images

Working on Multiple Projects: Positives and Negatives

Five Skills for Managing Documentation Projects in an Agile Environment