Improving Documentation ROI: Part 5 - Saving Yourself Time

In Part 1 we looked at what ROI is, and how to calculate it.
In Part 2 we looked at the broad area of improving ROI by improving costs.
In Part 3 we looked in a bit more detail at direct costs, and specifically direct financial costs.
In Part 4 we looked at reducing direct time costs for other areas of the business.

In Part 5, we're going to look at ways to save you and your writers some time.  Specifically, we're going to talk about the following areas:

• Passive income (templates, single sourcing, etc) 
• Production line efficiency (procedures, standards, etc)
• Personal efficiency (time/task/email management, saying no, etc)

So as not to confront you with a wall of text, I'll split this up into 3 articles, starting in this one with passive income.


One of the ways to increase your revenue is to have what is known as a passive income.  This is where you create something once and it makes money for you 24 hours a day without you having to do anything.  An example would be writing an e-book that people can buy from anywhere in the world 24 hours a day, 7 days a week, 365 days a year, without you having to do anything except file your tax return once a year.  The same principle can be applied to reducing time costs by the one-time creation of things that will save you time in the future.   Anywhere you have to perform a documentation task more than once is an opportunity to create something that will save you time in the future. Consider it a passive time income, if you will.  Examples for Technical Writers might include:

 - Templates - If you create the same type of document on a cycle (e.g. every sprint, every release, etc) then consider creating templates.  These will save you, and anyone else in your team who creates the same kind of document, time in every cycle.  There is also the added benefit of ongoing consistency and a single place to make changes for all future versions of the document.

 - Single sourcing - Some documentation, or parts of a document, can be used in multiple places (e.g. information in the release notes will also go in the help file, or instructions in the installation notes will also go in the configuration guide) or at multiple times (e.g. multiple minor release notes can be rolled up into a single major release notes document).  Single sourcing can be done by using help authoring tools like MadCap Flare to create individual pages that can be added to or subtracted from whatever target (i.e. document output) you specify. In these circumstances single sourcing will prevent you having to rewrite/copy the information, and all the attendant review processes that are implied by what is essentially the production of new documentation if you have to write it again.

 - Variables in your help authoring tool - All help authoring tools have the concept of variables (or something similar) which are used to place text in multiple places in your documents.  Changing the master variable will change it in every place in the topics you've used the variable in.  This is extremely useful for things like release numbers, company details, support desk contact information, etc.  Not only do variables prevent you having to do a search and replace across one or more documents, they also ensure consistency of text, so you know that as long as the variable is correct then that text will be correct everywhere that the variable is used. As an added bonus, you can usually set up a master project with variables and other elements in it, and import this data into new or existing projects so you don't have to set everything up each time.

These are a small sample of the possible ways you can reduce your time costs by using the "Create once, use many" principle, so inspect and adapt to fit your situation.  

The ROI for this kind of future time saving is as follows:

Cost = Time taken to create template/variable/whatever;
Gain = (Number of times the template/variable/whatever is used) x (Amount of time it would take to create the template/variable/whatever from scratch).

Example:

Time to produce a blank release notes document ready for the release cycle: 15 minutes.
Number of release cycles per product per year: 6
Number of products: 4
(i.e. 24 blank release notes documents are created each year)

Time to produce a blank release notes document template: 60 minutes
Time saved per template usage: 10 minutes (it still take 5 minutes to copy the template, add the release number, remove unwanted sections, etc)

Therefore:

Cost = 60 minutes
Gain = 24 x 10 = 240 minutes

ROI = (240 - 60)/60 = 3 = 300%

Bear in mind, as ever, that if your templates can be used each year with minimal or no tweaking you'll keep reaping the rewards year after year.

The simple maths indicates that you will save 3 hours a year, which might not seem like a massive amount.  But there is an economy of scale here, and the more documents you can create templates for, and the more writers who use them, the greater the saving.  There is also a hidden reward in that as long as the templates are right, your review process will be slightly shorter, and the number of errors that you need to fix will be lower.  (There are also the benefits of consistency for both the writer and the reader, but as this post is specifically about saving time I won't dwell on that).



Use the passive income technique to save your future self time in any situation where you could simply clone something, by creating the clone.  In part 6, we'll look at the time that can be saved by using some production line efficiency.