Rhyous

Technical documentation is critical to the success of any software. However, most creators of software struggle to provide adequate documentation for their product. Rare is the software that is praised for its documentation. When documentation is praised, it is often only praised for having some documentation, which is more than most, but in reality documentation is usually still inadequate.

So what constitutes adequate documentation? Well, if a user wants to do something with your software and the documentation helps them succeed in a timely manner, then the documentation is adequate. However, accomplishing this is not as easy as it sounds.

Why most companies fail to document properly

Most companies do not document their product thoroughly for a few reasons.

• Lack of a defined list of all types of documentation
• Lack of understanding of each type of documentation
• Documentation is not made a priority and lacks of funding

Lack of a defined list of all types of documentation

Many cannot name more than one or two forms of documentation. To be successfully with documentation, a software company must first enumerate the types of documentation. Then it must learn about each type of documentation and understand the role that each type of documentation plays. It is also critical to understand the different target audiences each type has. Also, what are the common mistakes made when trying to create each type of documentation so these mistakes can be avoided.

Attempts are made to document software in different ways. However, because a complete documentation set is not defined, success is nearly impossible. To make matters worse, there is little to no reporting or visibility into the level of documentation a given piece of software has. I have never encountered software that has reached a 100% documentation level.

In order to succeed there must be an understanding of the types of documentation.

1. Step-by-Step Walk-thrus – Also called Guides, How to’s, or Examples, Quick Start Guides
2. Product feature documentation – This is lists all the features and settings without really any real world examples. Often the help button inside the software points to sections of this document.
3. Troubleshooting Documentation – What to do when a failure occurs. Where are the logs and how to read them. How to turn on or increase logging and debugging.
4. Knowledge-base (Problem, Cause, Resolution), Frequently Asked Questions (FAQ), and Forums
5. Code, API, or SDK Documentation
6. Internal Development Documentation – Such as code and development documentation, internal only features use by developers and/or testers, architecture documentation (Note: For open source projects this information is usually public)
7. Real life customer implementations – Examples of how a company has a product implemented in real life
8. Marketing documentation – Basic over views of the value the software has for the company, ROI claims, general feature lists, costs, etc…

The worst documentation of all is of course the absence of documentation. However, most software companies are unaware that there are entire areas of documentation that are lacking. To have complete documentation you must provide it in all of these areas.

Lack of understanding of each type of documentation

Since most software companies are unaware of the list above, it makes sense that they don’t understand the items on the list. This is why they have no direction and their documentation is a sporadic combination of the different documentation types, never fully succeeding to accomplish the primary goal of documentation, which is to enable the reader to succeed.

In order to create excellent documentation, a full understanding of each type of documentation is requisite. Without this understanding, documentation your documentation will continue to be lacking.

The lack of understanding also leads to assumptions that are not true. Some think that if they try to document every setting their software has they will have complete documentation. Usually when this is done, there is so much effort put into this that providing a simple example is forgotten. Often I hear this question:

Why would an example be needed, every feature is documented?

I would answer this question as follows:

Information overload. Now there is so much documentation in one white paper that someone who wants to do something simple is unsure that it is simple. They don’t know which features they must setup and which are unnecessary or should remain as defaults.

I often find this with Open Source documentation and unfortunately when a user asks for an example they are often rudely told to “Read the Manual” or RTM. However, the manual is usually hundreds of pages and they probably need to read one page of the manual but just don’t know where to start.

If have seen documentation using only examples as well. However, when an attempt is made to deviate from the examples, there is nothing left in the documentation to provide the guidance necessary to succeed.

Some documentation is better defined, such as that created from the results of support calls, forums, or mailing lists. Because this type of documentation is completely reactionary, this is one area of documentation that is better defined. The documentation is created after a problem is experienced and has to be dealt with. However, once created, it exists to benefit others. As this documentation type is better defined you might not be surprised to know that it has its own acronym: KCS or Knowledge Centered Support.

The goal of this article is to raise awareness of all types of technical documentation and make them all as well-defined as support documentation.

Documentation is not made a priority and lacks of funding

Investing in documentation is expensive. But it is usually and expense that pays off. If an analyst has to choose between two competing software applications and one is well documented and one is not, the well documented software application is likely to be chosen. Many organizations fail to see the ROI in documentation and therefore choose not to invest.

It is obviously that lack of funding for documentation is an industry wide phenomenon. While technical writing has been around since even before software, a standard for documentation whether it be creating documentation, updating documentation, managing documentation, and reporting on documentation has yet to formally exist. However, I did find this link, which shows I am not the only one who has identified this problem: http://www.hci.com.au/iso/

So lets get back to our list. Below I will go through each type of documentation and provide some information on it.

Type 1 – Step-by-step Walk-thrus – Also called Guides, How to’s, or Examples, Quick Start Guides

Description

This type of documentation is nothing more than actions that the reader will take to accomplish something with your software. This documentation, when done right, could be followed by the most computer illiterate. If they read and follow each step, even if they have no idea what they are doing, they should succeed.

You may also want to read: Your project’s ‘Getting Started’ tutorial sucks – Why time to success matters

Role

To provide the most common, most tested, most successful, and best overall example of how to accomplish some particular task from start to finish with your software.

Audience

Most commonly, trainees and new or evaluation users. However, anyone who wants to achieve the results the step-by-step guide leads to is included. This is most often, but is not limited to, users of your software. It includes deployment engineers, configuration specialists, support engineers, and demo or sales engineers.

Common Article Names

• Quick Start Guide
• Step-by-step Guide for setting up “Software X”
• How to configure “Some Feature” of “Software X”

Common mistakes

There are many common mistakes

• Not clearly defining the starting point of the walk-thru. Think of the starting point of a software that installs on Windows. What version of Windows, what other software must be installed, etc…
• Defining the starting point clearly, but using a starting point most people don’t know how to get to. For example, you starting point should probably not say “have SQL Server installed and a database created with credentials” without providing steps.
• Assuming the reader knows how to accomplish a task, so the documentation simply states to “do task x” instead of walking the reader through doing the task.
• Skipping steps or forgetting steps.
• The development department changes the steps just before release but the documentation is not updated to match.
• Trying to simultaneously provide Product Feature Documentation in the middle of your steps. A link or note is acceptable for steps or settings that customers commonly customize.
• Trying to provide comprehensive troubleshooting documentation after each step. It is great to have a link or a reference to troubleshooting documentation but it shouldn’t interfere with the walk-thru.
• Only creating step-by-step guides for a couple common features of your software.
• Failing to add documentation after use. For example, when a consultant, support engineer, or other employee struggles to set up a not-well-documented feature and once successful, they still don’t document it.

Type 2 – Product feature documentation

Description

This type of documentation is a description of every feature and setting. What it is used for, when and why one would use the feature or setting.

Role

This is for users who need to stray from the common walk-thrus and need to know what alternate and uncommon settings are used for so they can determine which they need in their particular environment.

Audience

Any customer/user who needs more than the most common features. Your own support representatives and architect or professional services teams. Consultants who recommend your product or are trusted to determine if your product meets a feature set for potential customers/users.

Common Article Names

• The Software X Handbook
• Software X: The Complete Reference
• Understanding Feature Y of Software X

Common mistakes

• Burying the features in other documentation, such as walk-thrus.
• Not including at least a comment about when the feature would be used.
• Not being aware of the features your customers/users are aware of and using. There are lots of “unintended features” and you should capture them in documentation.
• Not letting customers contribute to this documentation in some way, even if it is just comments (this is the best way to solve the above issue, too).

Type 3 – Troubleshooting documentation

Description

This documentation describes steps to diagnose problems. It includes information on logs files. It includes information on the behind the scenes business your software is doing, such as process/thread work, file or data interaction, etc…

If the users tries to do some task with your software and it fails, to them, a single task failed. However, to fix it, one might need to know that behind the scenes ten different processes occurred. It is important to be able to diagnose which background processes worked and pinpoint which one failed, so you don’t troubleshoot all ten background processes when only maybe the seventh is the problem.

Role

To help customers/users get pasts unexpected issues and to help support engineers diagnose issues. These don’t have to always be public, but should be in the hands of your support engineers.

Audience

This is for support engineers more than customers, though the more experienced and “get your hands dirty” customers/users will use it. Engineers who do on site installation or on site configuration may need this information for when they run into bumps.

Common Article Names

• Feature X: The complete troubleshoot guide
• Troubleshooting Feature X

Common mistakes

• Confusing “Problem, Cause, Resolution” documentation (also called Knowledge Base articles) with Troubleshooting documentation.
• Not creating this documentation because you assume product feature documentation covers this. It doesn’t.
• Providing this documentation but not providing complete troubleshooting steps for whatever reason. Especially if troubleshooting is done with 3rd party software and outside your own product it is assumed outside the scope when it is not. For example, a product that requires a DNS server, should provide steps to make sure that a DNS server is configured as the product expects. You may not have to write such documentation if the 3rd party vendor has some, but you should link to/reference it in your own documentation.
• Writing documents that have lists of “fixes to try”. This documentation should almost never include “fixes”, but instead should diagnose the issue or pinpoint the problem so precisely that the fix becomes obvious whether the fix currently exists or not.

Type 4 – Knowledge-base (Problem, Cause, Resolution)

Description

This documentation is most commonly the result of customer support tickets/cases. It lists a specific problem, a specific cause of the problem, and a single resolution to that problem. As mentioned early this is one of the more well-defined areas of documentation. Read more here about KCS or Knowledge Centered Support.

Role

To make it so an issue only has to be troubleshot and fixed once. Once an issue is fixed, the Problem, Cause, Resolution can be documented and the fix can be applied without troubleshooting when the same Problem and Cause occurs.

To keep knowledge in-house. Tech Support is a high turnover position so keeping knowledge in-house is not always the easiest task.

Audience

Customers who experience a problem. Support engineers or other employees to whom the problem is reported.

Common Article Names

Frequently Asked Questions or FAQ.

Common Issues.

Common mistakes

• Providing multiple Problems, Causes, or fixes in the same article.
• Providing a problem and a list of fixes with no way to determine which fix is the correct fix.
• Having an article that recommends a fix even when a customer is not really having that problem.
• Failing to provide a good search for the knowledge base articles.

Type 5 – Code, API, or SDK Documentation

Description

This documentation describes how others use your code or libraries to write add-ons, plugins, integration, or otherwise customize your application through code. Do not confuse this with Internal Development Documentation. This type is for external users or resellers or middle-ware companies.

Role

This documentation helps others code with your code and libraries. Software that a customer/user takes the time and expense to modify to fit their environment becomes “sticky”, meaning the customer/user is likely to be loyal.

Audience

Systems Analyst / Developers / Integration Engineers / Middle-ware companies / Resellers. Customers who need to extend your product to meet a business need. Or in an open source environment, how others can use your code to extend their own project.

Common Article Names

• Software X SDK Documentation
• Class or Function Reference for Software X API

Common mistakes

• Providing zero documentation on this
• Providing incorrect documentation about a function
• Updating code but not updating the documentation
• Deprecating code but not informing the consumer
• Not providing the first type of documentation: Samples, walk-thrus, etc…

Type 6 – Internal Development Documentation

Description

This is used for internal developers continue future enhancements and otherwise maintain a piece of software.

Role

To help developers work with a piece of code. To overcome turnover so new developers can pick up code another developer created. To provide architecture and design of each piece of code. To give UML (usually the classes and their methods),

Audience

Internal developers. Sometimes support.

Common Article Names

There are really no common names, but usually these types of documentation are internal only.

Common mistakes

• Not writing such documentation at all.
• Not documentation all parts of the code: Classes, Functions, design and architecture, supported features, etc…

Type 7 – Real life customer implementations

Description

This is documentation about customers success stories. About how they implemented your software in their environment (which is usually as messed up as everyone else’s environments).

Role

To demonstrate that the software can be successful and has proven itself in real life customer environments.

Audience

Other customers / System Analysts / Internal Employees in charge of future enhancements and road maps

Common Article Names

• Product X Success Stores
• How Company Y succeeded with Product X

Common mistakes

• Not providing any customer success stories.
• Providing success stories from unhappy customers who when contacted, speak poorly of your product

Type 8 – Marketing documentation

Description

This is documentation that doesn’t really say much more than is needed to let a customer know about a software solution.

Role

To acquire more customers. To help potential customers determine features sets quickly.

Audience

Systems Analysts / Consultants / Sales Engineers / Evaluation customers.

Common Article Names

• Product X
• The Product X Feature Set
• What Product X can do for you business

Common mistakes

I don’t know a lot of the mistakes made in this documentation type, as my exposure to marketing is limited. I almost forgot this documentation type.

• Too complex, including information or overly complex images or diagrams that are hard to understand

Conclusion

Hopefully after reading this article, you have a greater understanding of documentation.

Now that you know all the types of documentation, there are other problems to address. How to write the documentation. How to choose the priority for writing these types of documentation. How to balance the cost of documentation against the opportunity cost of not having documentation.

Some day, I will also have to write a post on how to deal with “versioning” documentation including updating documentation when Software versions change. I think there is a market for a piece of software that does nothing but track documentation. Hopefully it is well documented. 🙂