November 2006 Newsletter R2 Conference
Getting Stuff Published Quicker
by Ant Davey
Well that's my take on Associate Fellow Geoff Hart's presentation at the recent Region 2 conference: Improving speed and accuracy of technology transfer: a case study of process re-engineering.

I was looking forward to this because, as the programme described it, this all happened in an R&D environment, which is where I now find myself. Not only was it about an R&D situation, but it wasn't in the software industry either. (I'm VP2 this year, be forewarned the theme for my presidency of the UK chapter will be: TC, it isn't all about software.)

As Geoff presented his case study it became more and more apparent just how closely the situation he was describing matched my own. About 30 SMEs, who really aren't writers, taking far longer than necessary to get research reports published. Except that he had the luxury of a graphic designer and a DTP specialist in his 'communication team'; I have me, CS2 and Frame!

The main issues were: an old, organically developed reviewing system, too many types of document, no deadlines, paper reviewing, and a manual document tracking system which required Geoff to do a physical check on people's desks to find folders. The prime cause of delays was a repetitive review process, in which it wasn't unheard of for authors to see up to 50 iterations of one document. If the author saw a document too many times he would bypass the department editor (Geoff) in order to avoid another round of reviews.

What Geoff first did to improve the process was to conduct a review of the process as it stood. This produced some metrics with which problems could be identified and quantified. A team then brainstormed potential solutions to the problems. A solution was then implemented and tested. If it worked it was kept, if not it was revised. Change was implemented by consensus.

While there are many methods by which change can be implemented, Geoff's team chose Kaizen. This Japanese word translates into English as continuous, or continual, improvement. Kaizen needs a management champion, someone who will speak on its behalf and can push implementation when needed; an outsider who will challenge your assumptions; representatives of all the stakeholders, to achieve consensus; and data which can be analysed and discussed.

The Kaizen identified a number of issues for which solutions were proposed, which included:

Everything that was done was done to make the processes of writing and reviewing easier. The authors actually liked that fact that they had deadlines to work to, and the document outlines - with prompts as to what type of information to write where - proved both popular and useful.

The greatest change was in the number of reviews that were allowed. Geoff, the department's editor, got involved in the writing process at the planning stage, along with other stakeholders, so consensus was gained as to what a report would look like before the writing started. These guidelines made it much easier for the authors to decide what information to include and what data to omit. Those writers that needed it were given personal coaching in how to do on-screen editing, making the review process that much more efficient, and documents easily trackable.

A workflow system was introduced that allowed documents to be tracked accurately. Editing proved far more efficient on-screen, and all documents being stored on the network meant that they could not get lost. As well as retaining previous versions of documents, the workflow system provided information about what went wrong - allowing issues to be identified and reviews to take place so that better ways of working could be identified. There was never any thought of allocating blame when things went wrong, simply a collective will to make it work better.

The introduction of pre-writing planning meetings minimised subsequent changes to documents, eliminating time-consuming reworking. Editing documents before they were sent for review made the review process both quicker and more efficient.

The bottom line results for the project were that production times for reports fell from 6-12 months to under two months. The 'many, many hours' saved allowed SMEs to concentrate on doing what they were best at, rather than struggling to create research reports.

Personally Geoff's many months of experience are going to help me enormously in the remarkably similar challenge that I'm facing at the moment.

Ant Davey
Senior Technical Writer