Thursday 28 May 2015

Improving Documentation ROI: Part 2 - Cost Areas

There are only 2 things that will improve your documentation ROI:

1 - Reduce costs
2 - Increase income.

That's it.  You can - and we will - break this down further, but in the final analysis to determine if you've been successful, costs must have gone down or income must have gone up, otherwise you haven't improved your ROI.  This is how any venture is measured, so don't kid yourself that documentation is somehow different.  When you're pitching your ideas to the people in charge of the budget, don't sell a dream, or a vision, or a future potential.  Sell the numbers.  That's all they'll want to see, and all you should need to give them.

If that sounds harsh, don't be disheartened.  I say these things because the long history of documentation, as wearily told round the LinkedIn camp fires and the forum watering holes by those old-timers who started working when computers were the size of rooms, is this: Not enough resources, not enough support, not enough belief from the higher-ups that documentation was worth the investment.  Some - many - companies buck this trend, but not that many.  If you want to buck that trend, and if you're reading this then I'm guessing you do, then go into the budget meeting with the hard figures that support your position.  That means calculating ROI.

Ok, </cynical-old-writer warning>, let's crack on.

In Part 1 we looked at how to calculate ROI.  In Part 2, we're going to look at the broad area of improving ROI by reducing costs.

There are 4 primary ways to reduce costs:

1 - Do the same with less.
2 - Do more with less.
3 - Do more with the same.
4 - Do more with more.

I'm not going to talk much about 1 and 2, because these generally indicate people losing their jobs, and I'm not a fan of that.  I write this blog to share knowledge, not to help people find ways to reduce staff. 
Also, there are, unfortunately, some managers who think that "doing more" means flogging their staff into the ground in order to get more out of them.  That's a woefully counter-productive strategy that just increases staff turnover and sick leave, and reduces motivation and productivity.  This series will hopefully show any of those managers who read it that there is a better way.

I'm going to focus on 3 and 4 - doing more with the same and doing more with more - because my hope is that you, dear reader, are interested in expanding your documentation world, not contracting it.

It might seem odd to suggest "doing more with more" is a way to cut costs, because surely if you hire an additional team member then your costs will go up, won't they?  Well, yes, superficially.  But if that additional team member gives you the resource you need to write documentation that saves other people in your company more than the cost of the hire, your cost per action across the company will actually go down.  To explain this more clearly, let's talk about that wonderful 80's power phrase, "Time is Money".

Although this phrase is most often associated with brash young City men with red braces and a Porsche, it actually first appeared in print via the pen (quill?) of Benjamin Franklin in a letter called Advice to a Young Tradesman, Written By an Old One:

"Remember that Time is Money. He that can earn Ten Shillings a Day by his Labour, and goes abroad, or sits idle one half of that Day, tho’ he spends but Sixpence during his Diversion or Idleness, ought not to reckon That the only Expence; he has really spent or rather thrown away Five Shillings besides."  

In modern economic parlance, "Time is Money" is known as an opportunity cost, which you're welcome to explore if you wish.  But for us economic novices, it's enough to understand that the cost of using a resource must factor in the value of what it could be used for instead. 

As an example, your company has 10 help desk consultants, each of whom cost the company £24000 a year.  Your new Technical Writer will also cost £24000 a year.  If that new Technical Writer can provide documentation that saves each of those help desk consultants 11% of their time, then that means a cost saving to the company of (10 x (11% of £24000)) - £24000 = £2400 (an ROI of 10%).  That cost of £2400 can then be "spent" by the help desk consultants using their time on other activities.  Hence your costs have superficially gone up, but your investment in that resource returns more than the cost of that resource.  The caveat, of course, is that your new Technical Writer must continue to provide a positive ROI every year, otherwise in year 1 your costs will be higher and your cost per action will be lower, but in year 2 your costs will be higher, and your cost per action will also be higher.

So what are the broad areas in which you can do more with the same or more with less?  Let's take a look:

1 - Reducing department costs (e.g. cost of tools)
2 - Reducing company costs (e.g. lowering the number of support calls)
3 - Improving department efficiency (e.g. single sourcing, homogenous documentation suites)
4 - Improving company efficiency (e.g. centralised documentation management using taxonomies)

There is a clear split here between direct costs (1 and 2) and indirect costs (3 and 4).  If you don't know the difference between direct and indirect costs, then for the sake of this series it's enough to understand that direct costs are related to a specific project or team (e.g. the cost of writing a help file for a product), and indirect costs are spread over a broad number of projects or teams (e.g. creating a centralised documentation management system that includes documentation for all of your products).  By their very nature, the ROI of direct costs is easier to measure than the ROI of indirect costs because the impact of an indirect cost can be difficult to trace and measure.  Nonetheless, we will try to find ways to measure indirect cost savings as we meet them.

In Part 3 we'll look in more detail at these types of cost.

Tuesday 19 May 2015

Improving Documentation ROI: Part 1

There are many ways to improve your documentation ROI, so much so that this topic will be covered in multiple posts.  In the first of the series, I'm going to focus on calculating ROI and explaining why I'm using ROI.  Future posts will cover the basic areas in which you can improve your documentation ROI, and specific ideas and practises that can be used to achieve this aim.

ROI - Return on Investment - is a measure of the gains a thing brings you, against the cost of that thing.  In the case of documentation, ROI is predominately measured as the gains provided by a Technical Writer, against the cost of employing that Technical Writer.  The maths of ROI is simple, and as follows:

ROI = (Gain from Investment - Cost of Investment) / Cost of Investment

For example, If the Gain is £100 and the Cost is £10, the maths would be:

        100 - 10 = 90
        90 / 10 = 9

        ROI = 9

When calculating ROI, an answer of 1 is an ROI of 100%.  In the example above, the ROI would therefore equal 900%, which, you'll not be surprised to hear, is a phenomenal return. A more concrete and realistic example would be as follows:

Cost of hiring a Technical Writer, including tax, benefits, salary, etc: £50,000
Net Gain of hiring a Technical Writer in reduced costs and increased sales: £75,000

        (75000 - 50000) = 25000
        25000 / 50000 = 0.5         ROI = 0.5 = 50%

The percentage makes it easier to comprehend the reality of the gain  An ROI of £100,000 sounds fantastic compared to an ROI of £10,000, but if it cost you £50,000 to return £100,000 (an ROI of 100%), and only £1000 to return £10,000 (an ROI of 900%), it turns out that the ROI of £10,000 is 9x better. 

There are many other ways of calculating the gain of a thing, be it an employee, a machine, a piece of software, a marketing event, or anything else you can think of.  The Wikipedia article on ROI has some examples if you're interested.  I'm using ROI because a) it's simple to understand and calculate for those of us that aren't accountants, and b) ROI is a commonly-used calculation by non-finance professionals to work out the potential benefit of an investment before investigating that investment further.  This makes it ideal for anyone looking to persuade the powers-that-be to provide funding for additional documentation (or any other) resources.  Top tip: Speaking in the language of the people you are trying to persuade is often a pre-requisite for success in persuading them, and ROI is the language of a lot of decision-makers.

At this juncture it's probably worth explaining that things that can't be quantitatively measured are always, always, always harder to defend and/or justify than things against which you can put numbers. Although the lack of quantitative measurement is one of documentation's hard problems, I will try to provide possible ways of measuring ROI in future posts as I go through ideas and practises that you can use.  Some of these measurements will be more quantitative than others, so, for example, you can measure support calls before and after implementing a documentation improvement, and use those figures to measure the amount of time saved by your help desk against the amount of time it has taken to implement the improvement. 

However, some of the measurements will necessarily be less precise because they'll rely on estimates and sensible assumptions.  An example of this would be improvements that increase customer satisfaction or improvements that reduce the amount of time that your consultants need to spend looking up information.  This kind of measurement will be more or less precise depending on your company's attitude and approach towards measuring customer satisfaction or recording employee time.  But even if there is no formal measurement, you can, for example, ask a representative sample of consultants to give you an estimate of how much time they spend looking up information, and make the reasonable assumption that you can extrapolate that over the whole number of consultants.  You've then got a dependable baseline from which to start calculating your ROI.

Hopefully this series will help you both prioritise the work that gives you the biggest gains, and also persuade the people you need to persuade to back you with the resources you need to make a difference.

Friday 15 May 2015

What are the Benefits of Documentation?

To us writers, the benefits of good documentation are both legion and obvious.  Unfortunately, us writers are not normally the people who make the budget decisions, so we have to make our case along with everyone else who wants a slice of the pie.  One of the big problems with making this case is that documentation is often seen as having a cost rather than having a value, as mentioned in a previous post:

Documentation is seen as an inherently qualitative activity and as such most people think that it can't be measured.  If you can't measure something, you can't compare it to other things, even of the same type.  If you can't compare it, you can't do any quantitative analysis on it.  If you can't do any quantitative analysis on it, you can't put a standardised value on it.  If you can't put a value on something, it's a cost.

Personally, I'm of the opinion that at least some of the value can be fairly easily translated into measurable figures, but that's not much good if you can't enunciate exactly what the value of documentation is in the first place.  So rather than think of it in terms of "value", which can be quite a vague and nebulous term, try breaking the value down into a list of discrete, individual benefits.  Once you have this list you'll see that some benefits are more amenable to quantitative analysis than others and you can focus your attention on measuring the value of those benefits, rather than the more qualitative ones. 

You can then use this to help convince the powers-that-be to invest more in documentation.

A starting list might include some or all of the following:

Good documentation:

  • Helps users understand and use the product, thus increasing customer satisfaction;
  • Prevents customers looking to another provider for functionality you already offer;
  • Lowers the number of help desk calls;
  • Reduces time spent by help desk looking for answers;
  • Removes burden of documentation from development;
  • Validates product design and usability;
  • Removes one aspect of technical debt;
  • Provides training material for new starters;
  • Assists trainers when producing user training material;
  • Prevents single points of failure where information is only retained in people's heads;
  • Improves organisational memory;
  • Increases internal information flow and reduces staff frustration;
  • Provides information for partners and independents to further develop your products and create an ecosystem around them;
  • Demonstrates that the company cares about quality;
  • Highlights the company as mature and professional;
  • Increases IP value of the company;
  • Keeps the company compliant with legal/regulatory requirements and audited standards for certifications (like CMMI and ISO);
  • Provide a coherent narrative across product suites;
  • Provides terminology guidelines/glossary that allow all areas of the business to use a consistent, common voice when talking about products;
  • Drives sales by showing customers they'll have the information they need to fix their own problems;
  • Provides Marketing and Sales with easy "compare and contrast" information about the product's strengths.

In other words, documentation acts as an internal multiplier to increase efficiencies, lower costs, improve customer satisfaction, and help make sales.  Why WOULDN'T you invest in it?

If there is something missing from this list, feel free to add it by leaving a comment!

Sunday 10 May 2015

Agile vs Dirty Agile

In my last post I mentioned that there was a dearth of simple "agile vs non-agile" comparison graphics, and presented one of my own.  I'm now happy to present the first - and currently only - Agile vs Dirty Agile comparison graphic:


Agile vs Non-Agile

A Google image search for "agile vs non-agile" returns surprisingly few simple comparisons, so a fresh attempt at capturing the salient points of difference won't go amiss.  And without further ado, here's my attempt:

Agile vs Non-Agile

What's missing? What can be better described?  Let me know in the comments.

Tuesday 5 May 2015

4 Hard Problems in Technical Writing

A representative sample of common technical writing problems could include:
  • Day-to-day challenges around tools, processes and methodologies;
  • Getting the correct information from the right people in a sensible time frame;
  • Lack of experienced API writers;
  • Transitioning to DITA and/or entirely electronic documentation.
Let's not pretend that I couldn't have chosen a hundred other problems instead!  But these will do as good examples of day-to-day problems that can be dealt with on a tactical basis as and when encountered.  

Struggling to get information from the developers in a timely fashion?  
Kick the development manager to get the team to do their job.  

Struggling to hire a full-time API writer?  
It's a supply and demand skills shortage, so either do it 
yourself or suck it up and pay for a contractor.

Struggling to move from hard-copy-using-templates 
to DITA-with-electronic-delivery-only?
Join the club, it's a right slog.

These are problems that basically require more resources, more procedures, or simply better management.  They're not heavy structural issues that will defeat the finest minds in the business, they're part of what it is to have responsibility for documentation.  So there are problems like these, and then there are problems.  This article is about the latter - the hard problems of documentation.

What is a "hard problem" in this context?  Well, there's no maths involved, which rules out NP-Hard problems (if that doesn't ring any kind of bell with you, don't click the link.  Life's too short. Literally.), and we're not at the level of the hard problem of consciousness, so you don't need to start reading Descartes.  Our problems are somewhat less studied than these big beasts, but they have proven to be no less intractable for our profession.  In short, they are the big, structural, strategic problems that cannot be solved by one person or one team, and they are:

1 - How to objectively measure documentation output.
2 - How to document the Internet of Things, especially the ever growing number of integration points.
3 - The lack of standardised writing certifications.
4 - An industry culture that assumes a documentation cost rather than a documentation value.

Each of these 4 problems has one thing in common: The requirement for a recognised, standardised global model that allows people to track and measure success (or failure).  I said that there was no maths involved, but that may have been slightly presumptuous; measurement by definition involves some form of maths, and perhaps there lies the rub.  Documentation is seen as an inherently qualitative activity and as such most people think that it can't be measured.  If you can't measure something, you can't compare it to other things, even of the same type.  If you can't compare it, you can't do any quantitative analysis on it.  If you can't do any quantitative analysis on it, you can't put a standardised value on it.  If you can't put a value on something, it's a cost.

There are possible solutions to all 4 of these problems, but any viable solution requires a recognition within the industry that solution x is the correct answer to problem y.  For example, there are some good providers of technical writing training, but there is no definitive qualification which says "This person is a competent technical writer".  We need the technical writing equivalent of "Certified Scrum Developer", "Microsoft Certified System Engineer", "Project Management Professional", and so on, qualifications that everyone recognises and which enable recruiters to sort the wheat from the chaff.  Otherwise we are like the world of boxing, where there are 7 or more "World Champions" in every weight division and no-one is really sure who is good, and who's just had good management. 

Similarly, being able to apply some agreed forms of measurement to documentation would enable a meaningful comparison between the work of different writers, or the output for different products, or between different companies.  Critically, it would also allow a clear understanding of the strengths and weaknesses of the documentation so that improvements can be identified and prioritised appropriately. 

I'm not suggesting that this can't be done, but there is no globally recognised, objective measurement system.  This is a close sibling of the problem we face when understanding how to document the Internet of Things and the functionally limitless number of integration points.  A good example of a question within this space would be "Which side do we document from, and do we need to document from both sides?", i.e. where product A can be integrated with product B and vice versa, do we document the integration from the perspective of product A or from product B, and should we document from both sides?  Having a variable, mix-and-match approach to this kind of question only sows seeds of confusion that sprout into feelings of annoyance with inconsistent or apparently incomplete documentation.

It is only when we have answers to these hard problems that we can properly call for a cultural shift towards one that sees the value rather than the cost of what we do.  Any individual can make the effort to change the culture of their current organisation, and they might well succeed, but as long as documentation lacks agreed quantitative metrics and methods, the default attitude of many decision-makers will remain as one that sees documentation as nothing but a cost.

I don't know what the answers to these questions are, although I have some thoughts that I'll share in future posts.  But I do know that the answers that we agree on as a profession will have long-lasting ramifications for all of us.