How do you create and maintain documentation standards and templates?

For me as a software developer the most important is the project document, which is written first of all for developers who didn't worked on the project, but at some point were asked to introduce some change/improvement. The project must include the following: -Purpose. -Description. -Source safe location. -Executable information (including required files to run application). -Log file description and location. -Input, including which DB tables application reads to start. -Output, including which DB tables were updated. -Application components, including ALL DB objects and installation package. -Detailed workflow. -Installation process. -List of all changes and updates since project release. -If necessary, how to monitor the application.

Stakeholder analysis before creating the document helps to plan the document well. Their needs and understanding regarding the requirements or their pain points help to visualize the document and create them accordingly.

When possible, a client site visit can be invaluable. Watching users interact with the current system can reveal a lot. Also look at their notes, post-its, and any cheat sheets they've made. Bring a copy of the manual and ask users to find specific information. Do they flip through? Use the index or ToC? Can they find the right information fast? Focus groups are another useful tool to see what users need, want, use, and consider important. Another tool I've used when it's a new system and there's no end-users yet: trade magazines. There's a publication, site, or organization for almost everything. A little creative sleuthing about your users can go a long way to creating better and more relevant documentation.

Create a central repository for the document for easy maintenance and easy updates. Using version control tools like Git or Bitbucket is useful. Adding visuals in the document is easy to interpret. Draw.io or Lucidchart are tools to look into.

A style guide is a great resource. You can use one that exists, like Microsoft's or Wired's, or create your own. A simple, reusable style "guide" could consist of one good writing reference and a single sheet of paper. Divide the paper into 8 sections (labeled ABC, DEF, GHI, etc) and write in any product names or other info as it should appear in documents. List fonts and colors. Consistent documentation is not only good for the user, but it can also reflect the company's brand. As a judge of technical writing competitions, I've seen how much "style" can vary from one company to the next, all of it unique, and all of it working. I like to say that good documentation helps users get their tasks done so they can go home on time.

Once you have your standards, templates, and style guide, make changes promptly and make sure everyone is aware of the changes. And don't leave old templates scattered around the ecosphere because people will find them, use them, and then waste time when they have to rework it all into the correct template. Delete them or archive them. This goes for logos, too. I was at a company once that had 6 versions of the same logo, going back years, but only one was the current one that could be used - and it was hard to tell which one it was.