Thursday 27 August 2015

Improving Documentation ROI: Part 6 - Production Line Efficiency

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 reducing 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 looked at creating a passive time income to save you time in the future.

In Part 6, we're going to look at ways to save you and your writers some time by using production line efficiency.

I've mentioned previously that the production line ethos of increasing specialisation and efficiency is antithetical to an agile mindset.  However, in line with Agile's "inspect and adapt" mantra, there's no harm in taking the best bits of another system and adapting them if they benefit you. Efficiency is not a bad thing in and of itself, but it can be taken too far (my argument with Waterfall is that it worships efficiency to the point of stifling innovation).  With the caveat that you can have too much of a good thing, efficiency in your documentation process is something to be encouraged.

There is a whole corpus of knowledge about organisational analysis, so I'm not going to cover that kind of process here, but it goes without saying that someone needs to understand the documentation process in your team and company to understand where you can make efficiency gains.  This understanding can be gained incrementally over time, so as long as you understand some of the process you can start to find those gains.

At this point it must be stressed that "efficiency gains" do not cover things like cutting down on toilet breaks or doing time and motion studies to find the quickest path between 2 parts of the building at any given time of the day.  These things are for terrible bosses and people who are normally referred to by swearwords. Productivity is best served by an effective and efficient use of the people and tools at your disposal, and you can't divorce "efficient" from "effective".  Effective staff in an Agile environment are those with a degree of autonomy; it doesn't matter how efficient you make them if they can't be effective.  At some point you're joining the dark side of the production line by producing a command-and-control situation, which is precisely the opposite of an Agile environment.

But that's not to say that waste, in the Lean sense, can't be minimised.  Is there a quicker way to add the standard watermarks to your screenshots? Is there an information transfer process being used by one writer that gives them an edge on all the other writers? Does following a comprehensive check list make a complicated process quicker to complete? Are you doing things in an order that increases the chance of rework?  The list of possible waste in your processes is endless.

Once waste has been identified, and an effective and efficient process developed in place of the wasteful one, it needs to be documented in processes, procedures, policies and standards.  However, this is not necessarily for the reasons you think.  Yes, you need to mandate good practise if necessary, and it's always useful to write things down so you don't have to remember everything all the time (Hello! Documentation benefits 101!), but those aren't the most important time-saving reasons to have comprehensive, and where necessary proscriptive, processes, procedures, policies and standards.

The single biggest time sink is the decision making process.

Should I do it this way or that way?  What are the benefits of doing x instead of y?  What will the stakeholders say if I produce a document with/without ABC? Is it my job or their job to find this information out? Is this the right terminology? And so on, and so on, and so on, ad infinitum (or maybe ad nauseaum), release after release, writer after writer, year after year.  All that time, effort and energy taken up by working things out, second guessing other people's reactions, arguing with colleagues about why, what, when and who, agonising over synonyms, defending one position, attacking another, endless calories burnt in the pursuit of the "right" answer.  And then doing the same thing a year later when you've all forgotten why you made that decision a year ago.

That's waste.  That's serious, pointless waste. It affects everyone, it's completely unnecessary, and it can be prevented through the creation and continual maintenance of processes, procedures, policies and standards.  None of those documents will ever be finished or complete, because no-one can see every possible future, but they can be updated every time a decision is made about "how we do x", or "what we use for y" or "who is responsible for z", and over time they will get closer and closer to being comprehensive.  Decision making can be both difficult and time consuming for a lot of people.  Add in the fear of the cost of making the wrong decision in a work/career context and it can become paralysing.  And although Agile encourages group responsibility, the fact remains that a lot of people don't want the responsibility of making a decision.  Remember, the greatest efficiency of the production line is that the workers know what to do each and every time without making a decision.  We're trying to abstract that benefit away from the conveyor belt and use it to our advantage in a more innovative and autonomous situation.  This benefit is the lack of decision making that has to be done. So proceduralise things instead.  Make the decision once, then write it down, and use it as a guide the next time this situation comes up. If you make decisions based on minimising waste and delivering your responsibility to a high standard then the outcome of every question, every discussion, every debate, can be framed in your processes, procedures, policies and standards for the future.

Now the tricky bit: How do you calculate the ROI on this? 

In general you probably don't need to, because most companies aim to be CMMI/ISO/BS compliant (or whatever standards apply in your locale).  Documentation is no different to any other department in this respect, so you will probably have to have at least minimally compliant standards anyway.  But the kind of comprehensive processes, procedures, policies and standards I'm talking about go above and beyond compliance, and it wouldn't be much use telling you this will improve your ROI if I can't help you find a way to measure that ROI.

There's no getting away from the fact that you will struggle to find a definitive quantitative measurement of ROI in certain circumstances, and this is one of those circumstances. The notion of ROI does include intangible benefits, which are benefits to which a financial value cannot be assigned. Unfortunately for anyone trying to calculate the ROI of comprehensive processes, procedures, policies and standards, these are not intangible benefits, so difficult though it is, you have to do the work and calculate! Therefore, as discussed in
Part 1 of this series, we're going to use estimates and sensible assumptions, and as demonstrated in Part 4, we're going to calculate in units of time rather than money.

We need to estimate the cost of making the decision, and use sensible assumptions to work out the gain that comes from having that decision included in the standards.  For the sake of simplicity, we'll assume that:

1 - The word "standards" covers all processes, procedures, policies and standards documentation;
2 - Basic standards already exist and don't need to be created from scratch;
3 - Adding a decision to the standards (e.g. The process for creating X is A, B, and finally C) is a trivial task that doesn't have a functional ROI cost;
4 - The standards are proscriptive and will be used by all writers who are required to work to them.

The cost of making the decision will be the amount of time that it takes for the team of writers to:

 - Discuss the question;
 - Think of possible choices;
 - Debate those choices, and finally;
 - Make the decision. 


The question is "What should we call this type of field on a Windows form?" - 10 minutes
The choices are dropdown or picklist - 15 minutes
The debate is had, and includes a discussion of the agreed spelling, i.e. dropdown or drop down, and picklist or pick list - 30 minutes
The decision is made that this type of field will be referred to as a dropdown - 5 minutes

Total time taken - 1 hour.

The gain that comes from having that decision included in the standards will be the time it saves each writer on average in a specified time frame.  For the purposes of this we'll use 1 calendar year, but any gain will actually continue for the life of this standard.  The sensible assumptions we'll make are:

1 - Every writer will need to use the term dropdown;
2 - The term will be used moderately often;
3 - Until this decision was made, every writer used one or more of the terms discussed (dropdown or drop down or picklist or pick list);
4 - It took an average of 3 minutes to choose a term every time a writer had to make that decision (by checking with others, looking up previous documentation, etc);
5 - The choosing of a term was then remembered for a short period until it was forgotten, leading to 1 decision a month about this term per writer.

(You may feel that these assumptions are either not very sensible, or not very realistic, in which case you can use whatever assumptions you feel are sensible and realistic in your situation.  The important thing is to understand the logic of getting from the situation of making a decision to a calculation of the ROI.)

The gain is therefore 3 minutes per month, or 36 minutes per year per writer.

On the face of it, this seems like a negative ROI ((36-60)/60 = -40%), but remember that this is only for a single writer.  For 2 writers the ROI is 20%, for 3 writers it's 80%, and so on.  And a single writer would probably take a lot less that 1 hour to make this decision.  Finally, note that this ROI will continue year-on-year, so over 2 years for a single writer the ROI would be 20%, for 3 years 80%, etc. On top of this, there is the added benefit of increased consistency in the documentation, which means a more useful information experience for the reader, and a lower chance of help desk tickets being raised by users who struggle with inconsistent terminology.

This example is used because it is simple, and hopefully familiar to a lot of writers. It covers a standard rather than a process, because no two companies/divisions/departments are the same, and a process that makes sense for one reader will make no sense for another.  But the calculation of ROI will always take the same form - find the costs of discussing and deciding the process, find the gains that proceduralising it it will bring you, and do the maths.  It's worth remembering at this point that the goal of ROI calculation is to provide you with realistic, workable figures that can back up your proposal for more resources.  Aside from giving you more time to work on the things that can dramatically improve the documentation ROI (such as FAQ or Knowledge Base articles for the help desk's most asked questions), this kind of ROI calculation can help show that you've looked home first and made efficiency savings before asking for more resources.

There are a functionally limitless number of decisions to make about your documentation, and the more you proceduralise the more efficiency savings you'll make.  But as ever when you're flirting with the dark side, be careful that comprehensive standards don't tip into a command-and-control situation where the writers become robots, because you'll lose all of the benefits of being Agile, and gain very few of the benefits of a production line.  Documentation is not piece work!  But "efficiency" is not a dirty word, it's just a dangerous word.  Use it wisely.

In the next part of this series we'll look at personal efficiency, and how you can get more time in your day from doing the non-Technical Writing aspects of your job more efficiently.  Yup, that's right, we'll be tackling the beast that is personal productivity......

No comments:

Post a Comment

Note: only a member of this blog may post a comment.