by Robert Delwood
The virtues of automation seem to be above reproach. Everyone agrees that better, faster, or cheaper is good. It is curious, then, that communicators are slow in adopting computer automation. By automation, I am referring mostly to Microsoft Office suite automation, commonly seen as macros, although there’s more to it than that.
Writers face a dizzying array of tasks, which can vary daily. These tasks can be broadly categorized as follows.
- Simple but time-consuming tasks that are purely procedural, such as formatting tables, removing comments, accepting revision marks, and checking footers. Many writers just “brute-force” their way through.
- Tasks that require decision making. These tasks are also highly procedural but require conditional text, collecting a subset of information from selective criteria, or “man-in-the-loop” decision making.
- Tasks for creating new information. These tasks can be compiled from the document itself (for example, collecting all the comments in a separate document or assembling a list of parts numbers) or from an outside source (for example, collecting error numbers from the development team, compiling last month’s revenue figures from the sales department, or creating lists from the company database).
Microsoft Office provides a profound amount of automation, especially in the form of macros. Macros can solve many problems by performing repetitious and stultifying tasks reliably and consistently. They can also leverage knowledge skills by sharing these macros among team members, saving time, and gaining consistency. Yet, many writers do not enthusiastically embrace this opportunity. So how do you encourage them to do so?
A common and obvious opportunity is an automation project. The task is large, comprehensive, and complex. Usually, a manager initiates a request to solve an overbearing problem. Programmers are likely needed to create an independent tool, perhaps running as a double-clickable application, complete with menus and buttons. This is an excellent start, but the real goal here is to empower individuals so they can create their own solutions.
Think small. Introduce the notion of automation by starting small. Automation can be as simple as using the F4 key to repeat the last action.
Think local. Automation doesn’t have to be fancy or elaborate. Quite the opposite. Start by becoming aware of mundane and repetitive tasks, such as formatting text, creating and formatting tables, extracting part numbers, and adding section headers. That’s where the low-hanging fruit with the highest payback can be found.
Another task is making sure that certain types of items, such as part number, are bold. In this case, part numbers ranged in format from six to eight characters, some had alphanumerics, others had hyphens, but all were in the same document, and the process was virtually manual, if not page-by-page. Within 15 minutes, literally, a macro was created to catch all the part numbers and make them bold. What had been a half-day process per document was reduced to less than five seconds.
Think easy. The act of automation doesn’t have to be elaborate. For Office, use the built-in macro recorder. Record the sequence as a macro, and save it. Automation was never intended to be only a programmer’s tool. Automation can belong equally to the writers.
Automation audit. Writers may need help in finding automation candidates. While the payoff in the part number example was large, the writers themselves did not identify that process. It was discovered while tracking down an unrelated problem. So consider an automation audit in which the automation programmer meets with writers and walks through their procedures. During this walkthrough, opportunities for automation can likely be spotted. The meeting can be informal and as short as 30 minutes.
However, planning walkthroughs can become tricky. The writer’s manager might not allow such a strategy for several reasons. The manager might be unaware of automation. He or she might see it as an intrusion into his or her authority or even as a threat. Even if management allows the discussion, the writer may be reluctant for similar reasons.
Either way, without openness or flexibility, the bottom line is that there is no automation. To be clear, automation will never replace writers or make them obsolete. Instead, the goal is to let the writer spend time on tasks that require their expertise, rather than on performing acts of mechanical repetition.
Since writers don’t often get helpful and relevant tools, they aren’t used to asking for them, especially on a individual basis. Yet, after they see what one automation project can do, they might generate ideas for the next round of automation. With ever-expanding features and requirements, automation can be a good friend.
Robert has been a technical writer for more than ten years, specializing in programming-writing. He believes that automation is necessary for communicators to thrive, and spends much effort evangelizing that message. Technology for technology sake is not the point, but rather the selective application of the right technology.
