Notes from 55th International STC Conference
Philadelphia, Pennsylvania, June 1-4, 2008

Implementing On-Screen Editing: A Four-Step Process

Geoff Hart

An independent consultant since 2004, Hart worked previously for IBM, the Canadian Forest Service, and the Forest Engineering Research Institute of Canada. He works primarily as a scientific editor but also does technical writing and French translation. An STC Fellow, he’s published more than 300 articles (most now available at www.geoff-hart.com) as well as the book Effective Onscreen Editing.

Session Description: Whether you’re a manager looking for ways to increase the efficiency of your documentation review process, an editor trying to cope with impossible workloads, or a writer trying to find ways to make peer review work more smoothly, the tools provided by on-screen editing can help. The problem is that implementation is never easy. The presenter showed how to overcome resistance to on-screen editing and outlined a four-step process for designing an implementation process that meets the specific needs of an editor’s workplace and makes the problem as painless as possible.

• Process outlined here can be applied to any situation involving change in the workplace
• Presenter described barriers to implementing on-screen editing and how to overcome them
• Four technological or organizational barriers (former are easier than latter)
   
• Inertia: Step 1. Get permission to try (proposal)
• Lack of perceived value: Step 2. Demonstrate the benefits (test case).
• Fear of known problems: Step 3. Plan to solve certain expected problems.
• Fear of unanticipated problems: Step 4. Plan for the unexpected.

Step 1: Get permission to try

• Before proceeding, you must develop a proposal that earns you permission to proceed.
   
• List the benefits you hope to achieve – and any drawbacks. (Honesty is critical.)
• Explain how you’ll eliminate or minimize any adverse consequences.
• Prepare a staff time and resources budget.
• Each workplace is unique and requires various modifications to the approach.
• List the potential benefits. Implementing on-screen editing typically provides the following benefits:
   
• Improved editing and revision accuracy lead to improved document quality
• Fewer missed deadlines and faster cycle times:
• Decreased editing times through automation (decreased repetitive labor)
• Decreased revision times through use of automated review tools (e.g., no retyping)
• Often, relationship between authors and editors improve.
• Explain how you will eliminate or minimize bad consequences
• Identify potential consequences by obtaining input from everyone affected by the change:
   
• Your employer, represented by managers of groups affected by the change
• Authors, the “victims” of the editing process
• Editors, the people who will do the lion’s share of the editing
• Other affected staff: secretaries, desktop publishers, SMEs, internal and external reviewers, QA, safety officers, lawyers, etc. Involve all stakeholders up front; pre-sell the idea.

Step 2: Develop a test case

• A test case proves you can achieve the proposed benefits. To create a test case:
   
• Pick a team who work well together.
• Pick an appropriate project
• Collect data (metrics) to quantify the results
• Support your testers throughout the test to help them succeed
• Document the results for management and for subsequent adopters
• Change is as much about motivating people as it is about technology.
• Pick a suitable author-editor pair. An ideal author-editor pair:
   
• Has a history of working well together.
• Is willing to try something new.
• Has at least average proficiency with the tools.
• Has time to do the required work and patience to work through obstacles.
• Will be willing to evangelize your success to encourage others to adopt the technology.
• Pick appropriate projects. Perform a short try run to “test the test”; then a long job to provide useful statistics. It should:
   
• Encompass typical editing challenges.
• Exclude intractable challenges (solve them later)
• Have a reasonable deadline with room for slippage.
• Be sufficiently important to justify editing.
• Not be so critical that delays or problems have serious consequences
• Clearly demonstrates the potential payback.
• Obtain good numbers (metrics).
   
• Managers have different standards for proof, but most request two categories of metric:
   
• Productivities, which support scheduling. For example: time per 1,000 words or Help topic.
• Error rates, which demonstrate quality. For example; numbers of typos, grammatical errors, inconsistencies, or unclear sentences.
• Each stakeholder may propose different classes of error to track (e.g., formatting errors for layout specialists).
• Define your metrics before proceeding!
• Once you’ve defined your metrics, choose a benchmark (i.e., on-paper editing)
   
• Collect statistics on the benchmark too if you don’t already have this information (e.g., # words divided by minutes of editing)
• Keep separate records for different types of document, project, or author (to estimate variation in your results)
• Keep separate records for different types of document, projects, or author (to estimate variation in your results)
• Record data on (1) the learning curve and (2) after your testers become proficient.
• Include qualitative, subjective data (“feelings”); nobody embraces an uncomfortable process. Feelings are important.
• Support the testers. Find ways to ease fears and provide motivation:
   
• Emphasize that the new process is being evaluated, not them.
• Plan so that problems have minimal impacts on the organization and the testers.
• Offer incentives (e.g. time off, a new computer) to try the new approach.
• Help them to preserve or develop friendly, efficient working relationships.
• Listen to and work with them throughout the test – without becoming a pain in the ASCII.
• Provide adequate time. Testing always adds “overhead,” so budget additional time for:
   
• Completing each tester’s usual daily work.
• Designing the initial process.
• Discussing and testing alternatives (i.e., revising the process).
• Recording and analyzing data.
• Solving problems, and documenting the solutions for future adopters.
• Keeping everyone apprised of your progress.

Step 3. Plan to solve certain expected problems

• Plan to detect and solve predictable problems. You can expect to encounter problems in three main categories:
   
• Organizational and bureaucratic barriers.
• Human nature (fear of change),
• Technological problems (this are the easy ones)
• Document any problems you encounter along the way, how to avoid them in the future, and how to solve ones you can’t avoid.
• Organizational and bureaucratic barriers. To overcome resistance to change, harness the energy of existing processes rather than trying to fight them. These include:
   
• Record-keeping (e.g., audit trails)
• Accountability: identifying error sources so you can avoid repeating that error.
• Work location: do editors need portable solutions (e.,g., laptop computers) or long-distance support (e.g., conference calls)?
• Time requirements: track times to facilitate future project scherduling.
• Human nature. Anticipate common objections so you can address them right from the start:
   
• Provide at least basic training, plus more advanced training for those who need it.
• Provide time to practice new skills so they aren’t forgotten.
• Provide ad hoc training for those who use the tools too infrequently to retain their skills.
• Teach everyone how to customize the software so it fits their work style.
• Combine on-screen edits with a final on-paper edit to detect blind spots, then find ways to correct the problem. Keep time metrics as you do this.
• Empower authors and editors; editing must be collaborative dialogue, not unilateral dictation.
• Develop shortcuts (e.g., macros) to automate repetitive tasks and improve productivity.
• Provide high-quality equipment and education to prevent repetitive stress injuries.
• Anything else? Always! Ask and you’ll find out.
• Use macros to insert repetitive comments with just a couple keystrokes.
• Use macros to execute common stylistic corrections (format)
• Technological problems. Some you can expect to encounter at some point:
   
• Software incompatibilities (e.g., software and operating system versions).
• Workflow issues (e.g., lack of revision tracking tools in publishing applications)
• Fonts and special characters (especially across language families).
• The phrase “repetitive stress injury” reveals its solution: automate to minimize repetition, minimize stresses, and avoid injury.

Step 4. Plan for the unexpected

• Take measures to detect and respond to surprises:
   
• Create audit trails to detect any problems (often on paper)
• Create a standard workflow that avoids known problems or makes them easier to solve.
• Phase in the new process gradually.
• Provide ongoing support for those who don’t use the tools daily.
• Technology permits communication, but does not encourage it. Stay alert for complaints.
• In closing, relax a little! This overall approach is surprisingly robust, but:
   
• I’ve exaggerated the potential difficulty.
• Each workplace and group of people is unique: stay flexible
• Demonstrating honest concern for all stakeholders make things go more smoothly
• Resist pressure to move faster than you are comfortable with: haste makes waste
• Full payback takes time to appear, so keep everyone informed of your victories as you go.

Contact: ghart@videotron.ca