JoAnn Hackos, Comtech Services, Inc.

Lately, I’ve been working with a few organizations that are genuinely afraid of change. The writers argue that their tools are broken and are fairly vocal about their frustrations in getting their jobs done with the existing technology suite. At the same time, they seem not able to envision that their own processes are also broken. Consequently, they believe that if they fix the tools, everything will be OK.

We know that it is difficult to drive change from the bottom of the corporate hierarchy. Even if the team members are aware of some of the problems, they often are reluctant to face up to the changes they need to make personally. Often, some of the most significant problems are found in the work practices the team members find familiar and comfortable. Acquiring new tools rarely fixes the problems with work practices.

I’ve seen too many projects that fail because buying a new tool is viewed as the sole solution to the problems with productivity and information quality. The new tool is implemented but the unproductive practices continue.

Take the case, for example, of conditional publishing. Writers working in unstructured FrameMaker grow accustomed to using conditional publishing to include more than one set of product information in a master document. Conditional publishing delivers a great benefit by allowing writers to reuse the same content in more than one deliverable, with variations. Unfortunately, conditional publishing quickly is overused. So many conditions are set on so many words, sentences, steps, and paragraphs that the source is no longer understandable.

So what happens? The writers and the managers decide to move to DITA, thinking that the problems with overly complex conditional publishing will be solved. DITA must be better because it is anchored in XML and enforces structured authored. Problem solved.

Then, the writers discover that DITA also supports conditional publishing, along with other more difficult to understand reuse mechanisms. But, heh, why not just use conditional publishing? As a result, the practice of loading content with conditional text doesn’t change. New tool, old practice. After a brief interlude of cleaned up content, the old problems of convoluted source content continue.

Leadership is Essential When a Team Has Lost Its Way

The conditional publishing scenario is typical of a team that does not know what to do to improve its practices. In fact, such a team rarely recognizes that it’s practices are at the heart of the problem. They’ve lost their perspective about the nature of the change that’s needed. The tools aren’t the problem; the work practices are the problem. But they’re difficult to change and face greater resistance.

The critical factor missing from the change initiative is leadership. A leader must identify the path to move forward, creating a “teaming” environment to change the process assumptions that are at the heart of the problem.

Amy Edmondson in our 2013 conference theme book Teaming points to leadership as the most important ingredient to a change initiative. In our scenario, change is unlikely to happen because the team members don’t recognize the source of the problem. At the same time, they’re unhappy. They work hard, are constantly frustrated by their tools, are pressed with unreasonable deadlines, and do not see that a major part of the problem is in the way that they work.

It’s important to remember that most people do not want to work ineffectively. In fact, they believe they’re doing the best they can under the circumstances. It’s just that they don’t recognize that their own “tried and true” practices are major contributors to the problem.

The leader’s role is to communicate a burning platform around change, a compelling reason for the writers to come together in a “collaborative team” to recognize and solve the work practices problem.

Framing the Problem

The first responsibility of a leader in managing a change initiative is to frame the problem. Framing means clearly stating the goal: to change the way the organization creates and manages content so that it can be used effectively across deliverables and across different business units in the organization.

Consider writers in an organization who are solely responsible for their end products (the manuals). They handle the cross-product reuse opportunities individually. There are no teams, especially when possible collaborators are in different physical locations, different time zones, and speak different languages.

Despite all the basic issues, the writers seem ready to work together. Some small groups are already functioning as collaborative teams, although their solutions are only partial. Others are open to the possibilities of working more collaboratively. But they need management support.

The leader’s responsibility is to get the writers to understand the problem and communicate that a solution is clearly within their capabilities to design. At the same time, the leader must ensure the writers that the new tools would support the direction they need to go to increase productivity and deliver a higher quality product.

Developing a Plan

With the right leadership and a clear sense of the goal, the collaborative team can take off. Their first decision is to redesign the roles and responsibilities of the writers. Rather than being responsible for a set of products and their manuals, they assign responsibilities according to subject areas. Writers are asked to become specialists in certain aspects of all the products. For example, a small group takes over all the brake systems across the product lines. As a result, these brake specialists learn exactly what systems were the same, which were nearly the same, which were somewhat different, and which were significantly different.

Each team is given a domain specialization to analyze and arrive at a plan to create master topics into which variations can be delivered, using the many reuse mechanisms available to them in DITA 1.2. However, before they can apply the reuse mechanisms to handle variations, the direction they get from the leader and the collaborative leadership team is to pursue normalization.

Normalization means comparing similar but not exactly the same content and deciding if the variations are necessary. Variations crop up in technical content because of minor changes made by different writers over time. Or, they may be the result of out-of-date practices like naming the product in every sentence. Normalizing means removing as many of the variations as possible, especially those that do not affect the meaning or are not necessary for the readers to be successful in reaching their goals.

The team members are first trained in normalization and then asked to apply the learning to their domain-specific content. As a result,, variations are significantly reduced, resulting in fewer variations to be handled by the new reuse mechanisms.

Sponsoring Successful Change

A teaming approach can yield great results to a change initiative but it requires strong leadership. The leader must frame the challenge in terms that are compelling for the team members. The team members must work collaboratively to reach the goals outlined by the leader. And, the team members must be well prepared through training in new methods and in collaborative work practices to solve the problems that they have learned to recognize.

Dr. JoAnn Hackos is the CIDM Director.