Does change management work for doc teams?

We technical writers are frequently very good with tackling new subjects – but not so much with tackling new processes. That sounds paradox, but it’s quite understandable: The reason we’re so good and flexible about what we describe is often that we’ve refined how we describe it. So changing how we write is a challenge, for writers  – and their managers, too, as Scriptorium’s Alan Pringle points out:

Without good management, the implementation of new processes will likely fail. (I’ve seen bad management kill an implementation, and it’s ugly.)

So how can you employ change management to improve and advance the way tech writers work? Alan explains three specific action points that are especially valuable when you’re moving to an XML-based model, but I’m looking for a more comprehensive angle…

Enter John Kotter

So I turn to John Kotter, who wrote a standard book on change management, Leading Change. Here’s a PDF with the gist of Kotter’s ideas in 7 pages. He lists common errors that impede organizational change  and maps them to a sequence of an “Eight-Stage Process of Creating Major Change”. It addresses problems that are probably familiar to writers and managers:

• Establishing a sense of urgency to overcome complacency
• Creating a sufficiently powerful guiding coalition
• Generating short-term wins
• Anchoring changes firmly in the corporate culture

I think these are good general management tools. But do they work for documentation departments? I find that Kotter’s recipe is frequently undermined by the low profile that documentation often has: I can make a good case that documentation is important and often undervalued. But frequently, its quality and scope are not seen as mission-critical for the success of a product or its manufacturer. Then how do you establish a sense of urgency strong enough that “most managers honestly believe that the status quo [in documentation] is unacceptable” (Kotter, p. 48), so a guiding coalition can be created and sustained?

Managing change with writers

So I try Richard Hamilton’s Managing Writers, one of the very few books about, well – you’ve read the title. Hamilton sounds a bit wary of Kotter’s idea to create a sense of urgency. He calls it the “burning platform” (p. 64f.) which will only stir people into changing if the platform is real and the writers are actually on it. Instead, he suggests Pip Coburn’s The Change Function from which he quotes:

Users will change their habits when the pain of their current situation is greater than their perceived pain of adopting a possible situation. (Hamilton, p. 63)

That sounds reasonable and more tangible, more on the level of writers who ultimately do the changing or not. The danger here is to give in to the evil you know, so you can avoid the evil you don’t know. Also, major change in documentation teams will often require migrating legacy contents or rewriting it, and either one adds tremendously to the perceived pain of the solution which impedes change.

Your turn

What are your experiences with change management in documentation? Do Kotter’s top-down ideas work? Can you give Coburn’s idea the right spin, so the perception leans toward change?

Advertisement

DocTrain West 2009: Richard Hamilton on “Managing the Move to Structured Content”

Richard Hamilton ran a session to talk about managing the move to structured content. Richard is a really pragmatic guy, so he talked about the why, what and how of managing the transition.

He started with several reasons of why and when not to transition:

• When there’s neither a benefit for the bottom line nor for the customers/users
• When it leaves you without a productive and operable documentation environment at any stage
• When you cannot commit to the new process (i.e., you’re afraid to burn your bridges behind you)
• When you cannot train or run a pilot project

To select what to carry over, he advocated converting only the used, required contents – and when in doubt to leave it out. He also said to carry over all the existing semantics, but not to add any new semantics, unless they add a proven value at reasonable cost: Don’t let the perfectionists run wild and build a more perfect solution – it’s difficult enough as it is.

For the “how”, he suggested to get outside help, esp. with the actual conversion – though that may require to clean up legacy content to get it ready for sensible conversion.