At some point, you’ve undoubtedly found yourself following a procedure that didn’t seem to make sense, or that made sense but was hideously inefficient. Such procedures come into being for a good reason: they were created to meet the needs of some specific situation, and in most cases, did a decent job of meeting those needs at the time. But contexts evolve, and procedures gradually drift out of synch with the daily reality employees face. Sadly, most organizations have no formal process for updating their procedures to account for this drift. Even organizations that have embraced the notion of continuous quality improvement often develop a surprising amount of resistance to change. That’s natural; once people get used to something, they tend to resist change unless the discomfort level grows very high indeed.
I’ve encountered resistance to change many times during my 25-year career, with both government and private-sector employers. At my last employer, before I became a freelancer, I was given an opportunity to help implement a large-scale change in our publications process. (Just to be clear: That participation was not the reason for my new freelance career!) The process had evolved over 25 years, and although it produced high-quality publications that were well respected both domestically and internationally, the process of producing those publications was so slow and painful that everyone admitted we needed to change something. By adopting a Japanese process-improvement method known as kaizen, we were able to reduce our time to publication by at least 50%, while simultaneously maintaining or improving the quality of our publications. Not every technical communication organization can achieve such impressive results, but I offer that statistic as proof that what I’ll be describing in this article is more than just theory.
I’ve written at considerable length about the details of this kaizen exercise in an article that will appear in STC’s Intercom magazine in late 2011 or early 2012. I encourage you to look for that article if you’re interested in the full details of the organizational context, of the approach we took, and of the details of the resulting change. Here, I’ve included a reading list from that article of other things I’ve written over the years that are specifically relevant to the challenges of an organization’s communications group. Chapters 15 to 18 of my book Effective Onscreen Editing provide a detailed overview of how to implement onscreen editing that illustrates the key elements of the kaizen approach and that can be easily adapted to other situations. Here, I’ll boil down the Intercom article and those chapters into their essential elements, namely the conditions required for successful organizational change and how you, as a technical communicator, can participate in those changes.
To change an entrenched process, there are certain key requirements:
- Dissatisfaction with the current process.
- A management “champion”.
- An “outsider” who doesn’t share your assumptions.
- Clearly defined problems.
- Involvement of all stakeholders.
- Consensus.
- Careful testing before implementation.
Dissatisfaction with the current process
The wise old phrase “if it ain’t broke, don’t fix it” neatly encapsulates important wisdom about the irresistible desire to tamper with things that work just fine and about the natural human resistance to change. You’ll generally find many people who are happy to complain about an inefficient process, but few who can muster the enthusiasm to change it unless the process is well and truly broken. If something basically works, even if it’s clearly inefficient, you’ll have a hard time persuading anyone to replace it with a new and unproven alternative. Thus, the first step in any process change is to confirm, as objectively as possible, that change is really what the organization requires. Sometimes, rather than throwing out the whole process, all that’s necessary is to grease a few bearings, tweak a few settings, or convince a few managers to be more reasonable in their expectations.
If the process basically works, you’ll have to muster compelling evidence that the process could be better. For example, if your goal is to create a Microsoft Word forms document with most of the standard information already filled in and with macros, menus, or AutoText shortcuts available to help its users create more consistent and error-free documents, you could keep track of the time wasted repeatedly writing or typing the same information on the paper form, track the number of errors per day that must be corrected, and quantify the cost of fixing those errors, both in direct dollar terms and in wasted employee time.
If you discover the process is truly broken, or if you’ve found a way to make a quantum leap forward in improving everyone’s life, it’s easier to make a case for change because the benefits are clear. When a process is truly bad, you’ll also find considerable support for your efforts to eliminate the annoyance. Unfortunately, the support usually comes from those who are afflicted with the process rather than their managers. That support may help you convince their managers that change is necessary, but managers require more evidence than that; they must believe the change will make their lives better and won’t create consequences that jeopardize their next performance appraisal. Since they aren’t directly affected by the process, and it continues to meet their needs, they have little motivation to change. To succeed, you’ll need to convince them the change is both safe for them and effective for their staff. If you can’t persuade a manager that change is necessary, you may need to reconsider whether you’ve done your homework. Managers typically see more of the big picture than you do, and may know things you don’t—including the possibility that change is already underway and would be derailed by your proposal.
Anyone who’s been employed by an organization for more than a year will have developed considerable skepticism about the organization’s ability and willingness to change, and when that skepticism is added to the natural fear that a change may make one’s situation worse, the resistance to change can be formidable. That’s doubly true if the organizational motto is the venerable “beatings will continue until morale improves”. It takes considerable skill to persuade such people to trust you and to make the leap of faith necessary to change. In the rest of this article, I’ll show you how to make your case and build enthusiasm for the change.
A management “champion”
No organizational change can occur without management approval, since managers wield the whip, and will ensure that anyone who tries to change things without approval will pay for their hubris. That’s a dramatic statement, but it helps remind us that managers have the most to lose if a change goes awry, because they have to explain it to their managers, who usually aren’t interested in excuses and who have long since forgotten the work context of those at lower levels of an organization. Thus, before attempting a change, you must obtain a management commitment to support your efforts. Once you have someone who can move mountains out of your way when necessary, you’ll find it easy to move those mountains. Once you have someone who will defend you against others who want those mountains restored to their original position, you won’t have to worry about having a mountain dropped on your head.
From a purely practical perspective, managers are the ones who have the power and authority to remove obstacles to change and negotiate with other managers to avoid creating new obstacles. Managers can rewrite policies, motivate recalcitrant employees, negotiate with other managers who might be affected by the change, and reward those who successfully adopt a new process—not to mention offering protection to their staff if problems arise. One of the most important things they can do is reassure everyone that there will be no adverse consequences if aspects of a process change and problems arise; the fear of punishment may be one of the strongest factors that discourage employees from taking a risk. One of the key points to communicate, particularly when you begin designing a new process using kaizen, is that one goal of the change process will be to identify problems (which usually arise when one or more employees fail at a task) so that those problems can be solved. You may even want to look for ways to reward failures that lead to insights into the process and that lead you to solutions to the underlying problems.
An “outsider”
The problem with any process you’ve been using for a while is that you tend to accept the philosophy behind the process and the assumptions that underlie that philosophy. This is akin to working in a cubicle under a tight deadline: after a while, the outside world stops existing, all you can see are the walls, and it becomes prohibitively difficult to think outside your box. The kaizen approach acknowledges this kind of familiarity-created blindness and wisely suggests that you enlist the aid of an outsider. At a minimum, this person doesn’t share your assumptions and will ask you to justify them. But if the person has experience with other groups who have attempted to change their processes, they will have insights that can guide you through your own evaluation process, helping you to avoid repeating the mistakes the others made.
The ideal outsider is someone with both insight and good human skills, so they can reveal and gently encourage you to examine your assumptions. They should also encourage you to find your own solutions rather than trying to impose their ideas on you. They must also be wise enough to recognize when your knowledge of the situation is truly superior to theirs, and accept that you’re an expert in some things. Their goal should be to push you hard enough that you really do challenge your assumptions, but not so hard that they irritate you and lose your support.
Clearly defined problems
You can’t solve a problem that you can’t define, other than by chance. Thus, before you try to change something, you must try to define it objectively so that, as much as possible (given how subjective we humans are), the problem is defined based on facts rather than opinion. If you can’t find a way to quantify something, this is a clue that you may not be looking at the right problem. For example, in my case, my partners in the kaizen exercise used statistics that we’d collected on how long it took for each class of worker to perform a given type of work. As the group’s editor, I had gathered detailed statistics on my productivity in words per hour, and that let us predict how long a typical manuscript would take to edit. We also had statistics on how long a manuscript remained on my desk before moving to the next stage of the process. We quickly discovered that (like most people) I often postponed a 15-minute task for several days, based on the erroneous assumption that a longer and more urgent task should be done immediately. Our outsider pointed out that by failing to spend the necessary 15 minutes right now, I was creating long delays for others.
Although it’s important to base your decisions on hard facts wherever possible, don’t ignore “soft” facts. It’s surprisingly common to find someone who is deeply dissatisfied with some aspect of a process but who cannot explain why. With your help, they may be able to pin down what bothers them; as in my analogy of thinking outside the box, you may see the world outside their cubicle that they can’t see. When you can’t pin down the real problem, it may be acceptable to report that 90% of your colleagues hate a particular task, even if they can’t say why, or that one key worker without whom the process can’t proceed (typically a manager) has a problem with one step in the process. Even though you haven’t objectively defined the cause of their subjective opinion, you’ve demonstrated the problem is important.
Involvement of all stakeholders
Although “the wisdom of crowds” is an oxymoron, it’s also true that ten opinions will provide more insights than one opinion. Jakob Neilson even coined a phrase for this: “discount usability testing”. Each group of workers who perform a related group of tasks or who interact with a process in a way that differs from other groups will provide insights from their unique perspective. Combine enough of these perspectives and you’ll end up with a clear understanding of the overall process and how it interacts with other processes. Sometimes an idea that makes perfect sense to one group can’t be implemented because it causes problems for another group or runs into immovable constraints that another group faces. In that case, you can’t make that particular change unless you can do it in a way that simultaneously solves the other group’s problems.
Another advantage of involving all stakeholders is that most people are happier adopting a process they had some say in designing. You can’t always involve everyone in defining a problem and proposing solutions, but if you can find a way to please someone each group trusts, that influential person can provide strong encouragement for their colleagues to accept the solution you eventually develop.
Consensus
One of the biggest obstacles to progress is the well-intentioned desire to find a solution everyone agrees with. That’s the holy grail of process change, and although it’s a desirable outcome, it’s something you won’t typically achieve. Kaizen emphasizes that consensus is more important than trying to persuade everyone that you’ve found the best solution: consensus means that everyone is willing to try a change to see whether it works, not that everyone believes you’ve found the best possible solution. After all, one of the key aspects of continuous improvement is the word continuous. If a solution works better than what it replaces but proves to be suboptimal, you can always look for a better solution later; if it doesn’t work at all, those who agreed to test it but had their own preferred solution rejected will then have a chance to test their solution.
Careful testing
The biggest mistake most managers make is implementing a change just because it seems reasonable and all stakeholders agreed to the change. The only way to be sure you’re right is to actually test the proposal under reasonably controlled conditions to confirm that it works. Life holds many surprises, as Murphy noted, and the only way to find them is to dive into the new process and discover where the surprises lie. But that doesn’t mean that everyone in the organization should become your personal guinea pig. Testing with a small group before widespread implementation accomplishes several important things:
- First, it identifies problems you didn’t anticipate so you can solve them while they only affect a few people rather than everyone in the organization.
- Second, it gives you time to practice the new process and learn how it really works (e.g., to discover shortcuts and efficiencies) so that at some future point, you can teach the rest of the organization how it works.
- Last but not least, this approach reassures people that you care enough about their needs to offer them a process that will produce the least possible adverse impact on their daily lives during the learning curve and the greatest beneficial impact once they master the new process. Sometimes showing that you really care about their needs is all you need to gain their support, but if not, you can at least show them you’ve tested the process to the best of your ability and are confident it works.
Implications for technical communicators
If all of these points seem obvious as you read this article, I can assure you that they seem far less obvious when you’re down in the muck with the rest of the staff. That’s precisely why having an outsider to work with you can provide such powerful insights: they’re not blinded by the muck. Achieving the necessary distance purely on your own is difficult at best, and is often impossible. Should you try out the approach I’ve described in this article, never forget that what’s obvious to you won’t be obvious to the people who will be affected by a proposed change.
The ability to identify things that are obvious to you but not to your audience (here, the group that must endure the proposed change) is what adds to your value as a technical communicator. It also reveals your potential role in process change. Organizational change cannot occur without a clear recognition that audience needs are important, without the recognition that you may know things your audience doesn’t know, or without clear communication of the reason for a change (i.e., the tools of rhetoric and persuasion). These are areas where technical communicators are ideally suited to participate and perhaps even to guide the change process.
In some contexts, such as ISO 9000 efforts and compliance with legislation such as Sarbanes-Oxley, there’s also a clear documentation component. But documentation alone is only a small part of what we can contribute. As I noted in my keynote address to STC India’s annual conference, which was subsequently published in their Indus newsletter, taking responsibility for such an active role lets you showcase your abilities and the importance of audience analysis and communication to many people outside your group. This will gradually build respect and appreciation for what you do every day. But once managers see your skills on display, and have proof of your ability to successfully manage change, they may offer you opportunities to apply those skills in other areas, such as interaction or interface design. Having proven yourself in one highly visible role, your options begin to expand. Whether you aspire to move up the management ladder, or merely want opportunities to diversify what you do at work, this is clearly a good thing.
Change is never easy. But with the approach described in this article, I think you’ll find change to be manageable and relatively painless.
Additional reading
- Hart, G.J. 2000. The style guide is dead: long live the dynamic style guide! Intercom, March:12–17. <http://www.geoff-hart.com/resources/2000/dynamicstyle.htm>
- Hart, G.J. 2000. Persuading reviewers to review. Intercom, April:44. <http://www.geoff-hart.com/resources/2000/persuading.htm>
- Hart, G.J. 2000. Why edit on screen? Intercom, September/ October:34–35.
- Hart, G.J.S. 2003. Redesigning to make better use of screen real estate. Pages 337–350 in M.J. Albers and B. Mazur, editors. Content and complexity: information design in technical communication. Lawrence Erlbaum Associates, Mahwah, NJ. 368 p.
- Hart, G.J. 2004. Practical and effective metrics. Intercom February:6–8. <http://www.geoff-hart.com/resources/2004/metrics.htm>
- Hart, G. 2006. Designing an effective review process. Intercom, July/August 2006:18–21. <http://www.geoff-hart.com/resources/2005/reviews.htm>
- Hart, G. 2006. Effective outlining: designing workable blueprints for writing. Intercom, September/October 2006: 18–19. <http://www.geoff-hart.com/resources/2006/outlining.htm>
- Hart, G. 2007. Should we stick to the shadows, or take on a little more heat? Indus, the newsletter of STC’s India Chapter, Vol. IX No. 2, April–May 2007. <http://www.geoff-hart.com/articles/2007/shadows.htm>
- Hart, G. 2010. Effective onscreen editing: new tools for an old profession. 2nd ed. Diaskeuasis Publishing, Pointe-Claire. 507 p. <http://www.geoff-hart.com/books/eoe/onscreen-book.htm>
