Traced to Chicago: Developing a Partnership Between Information Development and Training

Home/Publications/CIDM eNews/Information Management News 07.07/Traced to Chicago: Developing a Partnership Between Information Development and Training

JoAnn Hackos, PhD
CIDM Director
www.infomanagementcenter.com

“I don’t know anything about the training that is offered for the product. I think the training organization is somewhere in Chicago.” So explained an information-development (ID) manager in North Carolina when I asked if the training courses reused any of the information her team developed. Not only was the training organization not reusing any of the documentation, the ID manager had no opportunity to learn from the trainers and instructional designers.

In the best circumstances, instructional designers and technical writers are both considered part of the information-development team. The addition of the classroom instructors to this partnership increases its ability to deliver to customers the best information possible.

In the worst circumstances, the various groups not only fail to work collaboratively, but they may even be competitive and antagonistic toward one another. The training organization seeks to increase its course attendance and revenues by ignoring the self-learning material in the form of product documentation and help. The ID organization argues that trainers are PowerPoint addicts. Instructional designers consider the documentation verbose and written with little understanding of customer behaviors and needs. The writers prefer to work closely with the product developers rather than interact with customers and customer surrogates, a role that the trainers play well. Under these conditions, the clear loser is the customer, not to mention the corporate bottom-line.

Clearly, such antagonism is counter-productive. However, failing to take advantage of the rich experiences, knowledge, and expertise of both groups leaves us saddened over the loss.

I hear many reasons given for lack of collaboration between ID and training:

  • The groups belong to organizations with different reporting structures. You would have to go up to the CEO to find a common organizational leader.
  • Training is (documentation is) outsourced to a company that prefers to control all the content it produces. Reusing material decreases revenues.
  • Documentation must be released with the product. Training often comes much later in the customer-support cycle, making collaboration difficult.
  • Training is a profit center, focused on earning revenue from attendees (butts in seats). Documentation is a cost center, focused on being as efficient (and invisible) as possible.
  • Trainers are experts in the way the products are used in the real world. Documentation is focused on how the product works.
  • All the writers have to do is throw the documentation over the wall to the instructional designers. They use what they need, when they need it.
  • The trainers ignore the documentation. They do not even tell the customers that there is a help system or manuals.
  • Customers prefer to use their training materials as reference, even if they’re terribly out-of-date.

I am sure that you can come up with even more excuses for the absence of a collaborative environment. Even in organizations that include both training and documentation, the same lack of respect and mutual cooperation occurs.

Are there solutions?

“Enough of the bad news,” you say. Somebody must be doing something right.

Indeed, we find many organizations in which collaboration is the norm. People with expertise in instructional design, information development, and instruction share their knowledge and, as a result, develop an environment that builds on strengths and offers a better solution to the customer. At the same time, a collaborative environment increases efficiencies and decreases costs for everyone.

To pursue an effective collaboration between training and information development, consider

  • Combine forces in a single organization under a unified management
  • Launch joint development projects that define all deliverables from a common source
  • Jointly manage projects or alternate management to foster cooperation
  • Gather user profiles based on a common understanding of user needs
  • Decide on the role of training, documentation, and help during the project design phase

Combine forces under a unified management structure

In many organizations, training and information development report to different managers and through different reporting structures. An information development team might report to an engineering, development, or marketing manager. A training team might report to a support or services organization or directly to a senior member of the leadership team. Different reporting structures often make collaboration difficult.

More organizations, however, have considered the advantages of the joint development of training and technical documentation. In these organizations, instructional designers and technical writers report to the same management, greatly increasing their ability to work collaboratively on projects. In some organizations, the classroom trainers are also part of a single organization, especially when the trainers are also the instructional designers, preparing their own materials.

However, reporting to the same management is not a panacea. In one organization I consulted with, the teams were merged but still maintained their fiercely separate identities. The first joint meeting we sponsored felt like a junior high dance. All the trainers were on one side of the room, and all the writers were on the other side.

To bring the dance partners together, we first had to foster an environment of mutual respect. It was most helpful for individuals to relate their experience and education to the group. Although the trainers had more direct experience with the products, the technical writers had years of work with the product developers. Clearly, both sides of the team could learn from the other.

Launch joint development activities

A unified management structure is only a starting point. Without active participation in joint projects, the two teams are likely to continue on their separate paths.

A joint project begins with planning and design phases as soon as a go-ahead is received from the product managers. During the planning phase, the instructional designers, technical writers, and trainers work together to define the scope of work (new, updates, large, small, and so on) and the required schedules and deadlines. During the design phase, the team arrives at a common understanding of the audience and plans the deliverables. With deliverables outlined, the team members can more easily collaborate on the work and avoid duplication of effort. For example, if the team completes a task analysis and outlines all the tasks that the user has to complete, both technical writers and instructional designers can produce the tasks.

In many cases, development of task instructions can be shared between documentation and training materials. In one group, the instructional designers decided that they could develop separate worksheets with the data needed for tutorials rather than embedding the tutorial data in the task. That change allowed them to reuse task instructions developed by the technical writers.

The technical writers learned from the instructional designers and the trainers that the users did not require basic software navigation instructions but preferred minimalist steps accompanied by troubleshooting insights in complex tasks.

The instructional designers provided more insight into the users need for background knowledge in support of the tasks, helping all team members focus on useful knowledge rather than generalities.

Manage team jointly

Because of a history of distrust between training and information development professionals, I recommend that joint teams be managed jointly by representatives from both groups with equal authority and responsibility. If that is not possible, then some collaborative teams should be managed by an information developer and others by a trainer or instructional designer. It is important to avoid the appearance that one part of the organization is always in charge and has the upper hand on all decisions.

The best team I worked with had a senior instructional designer and a senior writer, with me in the mediator role. Our joint assignment was to develop an introductory course in the new product, accompanied by an introductory manual. We argued a lot but quickly came to appreciate each person’s point of view and expertise. The result was well received by the customers. Each participant in the project gained knowledge of the customers’ needs and avoided creating redundant content.

Develop a unified set of user profiles

Because they work regularly with actual users, classroom trainers can be an invaluable source of the information needed to build in-depth user profiles. The only caveat is that companies often send only more experienced people to training, in effect, training the trainers. Trainers, instructional designers, and information developers each need to participate in analyzing the users and constructing mutually agreed upon profiles. Without that agreement, numerous disconnects creep into the source materials.

Take, for example, the technical writer who assumes that the software administrator needs instruction in navigating a menu tree. Detailed, step-by-step procedures that explain how to expand pluses and contract minuses take considerable time to produce, especially if accompanied by screen shots. With information from the trainers, the writer learned that the typical administrator is knowledgeable about software and operating systems. The menu tree is ubiquitous and requires no explanations. As a result, pages of explanation that the users would find useless and insulting were eliminated.

Decide on the role of each information deliverable

I have often commented that technical documentation should emphasize infrequently performed procedures and training materials should emphasize the tasks that people perform every day. After users are trained, they rarely look up information about ordinary tasks. They are more likely to use documentation to solve problems and to learn about a task they perform occasionally.

For example, we learned in one customer study that accounting professionals were more likely to look up procedures performed at year end, especially if year-end procedures were updated in response to regulatory changes. The information developers had learned to issue new year-end procedures a few months before the closing dates. The Year-end Quick Guides proved useful and popular among customers. They were used in conjunction with year-end refresher courses offered by the training department.

Too often, print manuals, help systems, and training materials all cover the same ground. And, the ground they cover is often the easiest to learn and write about. The hard things, especially the troubleshooting procedures to solve difficult problems, are either never documented or casually treated. Classroom trainers often learn about troublesome tasks and difficult concepts as they interact with users. If they bring this knowledge back to instructional designers and information developers, everyone learns. The information developed in response is often the best information anyone creates.

Summary

Training and information development are ideal partners—if only they can find common ground, develop mutual respect, and create a collaborative working environment. The suggestions I have offered here are only a start.

For additional reading, please refer to: Integrating Training and Documentation.

CIDM members have asked that we create a listserv of people interested in exchanging information about a training/documentation collaboration. If you would like to participate, please send an email message to anne.bovard@comtech-serv.com.

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close