President Obama recently proposed an intriguing solution to deal with his country’s ever-growing debt: a “failsafe” trigger. Here’s roughly how it would work: if the debt as a share of the economy (the debt-to-GDP ratio) does not drop below a certain ratio by a certain date, then spending cuts, tax increases, or both would automatically be implemented.

Politically, it’s a brilliant solution, as it transfer the onus of decision-making from the politicians to the bureaucrats, as they are forced to make the deep but necessary cuts to lower the debt, currently a nightmarish $14 trillion.

A failsafe system can be applied to any process. It is comprised of:

1. a specific, measurable goal to be achieved
2. a date or time period by which the goal must be met
3. a specific, measurable action that will be taken if the goal is not met

A simple example is weight loss. For example, you could set a goal of losing 3 kg. in two weeks. If you fail to meet this goal, you would have to lower your intake by 300 calories, exercise an additional 30 minutes, or both. You would repeat this failsafe system until you have reached your ideal weight. Then comes the tough part: maintenance. A second failsafe system ensures you stay on track.

Could a failsafe system be developed for documentation? It could, if we can define a measurable goal. However, objectively measuring the quality of documentation can be difficult. To obtain an objective, measurable goal requires carefully observing a user interact with the documentation.

Some of the measurements of documentation could include:

• the success rate at which the user finds the relevant topic
• the length of time required for the user to find the relevant topic
• the average rating given a topic by the users

Another measure could be the number of contacts (phone calls or emails) to technical support. This could be broken down further into:

• contacts made due to incomplete or inaccurate documentation – for example, a procedure is missing or a field is not explained clearly
• contacts to report specific documentation problems – this occurs when users give direct feedback on the documentation

After deciding what it is you are going to measure, you can then set a goal based on a specific date or time period, for example:

• improving the success rate by 15% over the next 3 months
• reducing the topic search time by 20% over 6 weeks
• reducing technical support contacts by 10% by August 1

Finally, you need to select an “action item”. That is, what specific action will be taken if the goal is not met?

Ideally, the action would be be implementing a thorough review of the documentation (or portions of it) based on feedback from users or internal staff such as QA, Business Analysts, Product Managers, and so on.  This could include creating a “closed feedback loop” whereby users can directly comment on any topic; the results are then sent to the appropriate writer who will make the necessary changes.

Is this idealistic? Yes. Many technical communicators are already stretched to the limit, so asking them to set aside time to improve their existing documentation is not always realistic. However, for those who are fortunate enough to implement such a failsafe system, the end result is documentation set that actually saves a company money.