Finding a Path to Collaboration


August 2015

Finding a Path to Collaboration

CIDMIconNewsletter JoAnn Hackos, Comtech Services, Inc.

I’m convinced that Collaboration is one of the best theme topics we could have selected for the September 2015 Best Practices conference. So much to be learned about doing it right—so much to be learned about doing it wrong.

In thinking about the collaboration success stories, I was reminded of Laura Readdy’s (Siemens PLM Software) superb presentation at Best Practices and her follow-up article in April 2009. Laura’s story demonstrated how training and documentation could successfully work together to develop common content. Their goal was to achieve “direct reuse of a topic across two or more deliverables without change,” and they succeeded.

The goal at Siemens, as it is for information developers everywhere, is to deliver the highest quality content and enable customers to successfully use their products. That means providing customers with real-world tasks and relevant concepts. Once customers have been through training, they need to find the same supporting content again as they work with the product. To achieve those goals meant that writers, instructional designers, and trainers had to learn to work together—to collaborate.

Laura describes the work of one Siemens PLM team of documentation and courseware writers. Her team was, at the time, responsible for 100 documentation guides, 12 instructor-led courses, and a growing number of self-paced training modules. By 2009, they were sharing content between a subset of the documentation and 25 percent of the training materials.

A key ingredient to collaboration is a shared focus, avoiding the “not invented here” barrier. This barrier often springs up when the participants work for different organizations. That was true at Siemens. To overcome the barrier, they chose what was probably the most direct approach. They placed the writers and training developers under the same manager. The restructuring sent a very strong message—collaboration is a requirement.

Added to the team of writers and training developers were an information architect and a content designer and subject-matter expert. These specialists were tasked with guiding the process. They also decided to store all of the content in their content management system (CMS).

The underpinning of their success at collaboration was a common set of principles, based on user profiles and task analysis. Both documentation and courseware were developed for the same set of users and a common understanding of the required tasks. The team developed a content plan that identified common content, as well as content that would differ. They also learned that to increase shared content, some of the legacy content needed to be rewritten.

In prototyping the new process with a carefully selected team they learned that they had to train writers to develop content in a new way, develop resources to support the translation, schedule the work to meet multiple requirements, and deal with tools and technology issues.

None of this story proved to be easy. The Siemens PLM collaboration team had executive support but those executives also demanded quality improvements and measurements of the Return on Investment. The writers and training developers had to learn to work together and focus on customer needs, not product descriptions. They needed to follow a common process with constant support from management. Their technical experts (information architect and content designer) were critical to the success of the project. The success of the collaborative required everyone to share expertise and abilities and focus on the quality and cost goals.

Modern Management Discourages Collaboration

Note that the Siemens PLM collaboration success was strongly influenced by the move to place both training and documentation under the same leadership. In most organizations I work with, training and documentation are not managed together. Rather, because training is often viewed as a profit center, it operates independently.

In fact, most large organizations today are decentralized. Individual business units or profit centers have complete responsibility for operations, products, and business decisions. Each profit-center manager is evaluated based on the profits and losses of his or her organization. The rewards go to the managers who deliver the best results. This decentralized system delivers good returns, unless business units need to work together to achieve a goal.

Siemens PLM chose to battle decentralization by centralizing, at least for the training and documentation teams. Most other decentralized organizations I work with would be reluctant to formally join forces. The reluctance to collaborate takes on all the characteristics I discussed in my June 2015 article on the barriers to collaboration, in “Getting Collaboration Wrong” <>.

These independent organizations are often reluctant to use ideas from other organizations (not-invented-here), they can develop an insular culture in which they mainly work with people in the same organization, and they believe they should be able to solve their own problems, often because they fear having problems exposed.

I’ve often found that competing organizations are reluctant to collaborate because they want to demonstrate just how capable they are (hoarding information). The instructional designers and trainers, for example, distrust the technical writers. They believe that the writers are not technical enough and don’t really understand the customers. The writers distrust the instructional designers and trainers because they believe they are not close enough to the product to appreciate the complexities. In either case, the lack of collaboration results in a duplication of effort and the inability to benefit from each organization’s strengths. The weaknesses, rather than the strengths, are allowed to prevail.

As training developers and information developers move toward delivering information on mobile devices, we are also likely to see another barrier to collaboration: competition. Technical writing groups are adding videos and interactive presentations to their content delivered online. Training organizations are adding videos of the user interface. Clearly these initiatives are increasingly competitive, particularly as customers move away from instructor-led classroom training and PDFs of long manuals.

As training and documentation move closer together with respect to the delivery methods for content, they need to increase, not decrease collaboration. Both groups have less time than ever to accomplish all that needs to be done, especially if they continue to work independently. Collaboration would make everyone more productive.

I was once asked to coach an organization that wanted to foster collaboration between documentation and training. We started the project with a big team meeting. Everyone from both teams was invited to a large meeting room. I felt as if I were the chaperone at a junior high school dance. The instructional designers and trainers were on one side of the room and the technical writers were on the other side. My first group activity was to get people to move, combining them into small cross-functional teams. The result was the beginning of a collaboration project. Rather than competing, the small groups found that by working together they were more successful than they could possibly be alone.

Foster Collaboration by Understanding the Barriers in Your Organization and Finding Ways to Overcome Them

If your goal is to foster collaboration between training and information development, first examine the barriers and be certain that you know exactly what is going on. Your solution must include ways of overcoming these barriers and developing a successful collaborative project.

The most common barriers to collaboration are

  • Not-invented-here
  • Hoarding
  • Search
  • Transfer

Once again, read “Getting Collaboration Wrong” for the details.

Not everyone is capable of using the mechanism that Siemens PLM discovered—merging the two organizations under the same management. Rather, managers need to find ways to reduce intergroup rivalries and work hard to unite people around common goals. Then they need to provide incentives to support teamwork and speak the language of collaboration.

Morten Hansen, in Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results, explains that leaders need to work hard to create a unified environment among people who do not report to the same management. To create a unified environment, leaders must

  • Create a goal that unifies the collaborative team members
  • Help the team members understand the value they are able to produce with teamwork
  • Continually communicate using the language of collaboration

It’s definitely not easy to create a unifying goal that brings everyone together, facing in the same direction. Hansen points out that Airbus was successful because everyone in the company was aligned with one unifying goal: Beat Boeing. A good unifying goal is simple and concrete, gets people passionately involved, and invokes the competition. To bring together a training and a documentation organization might require a goal that invokes the need to ensure that customers are more successful getting the exact information they need, in the format they prefer, than they would if they purchased the competitor’s product. But that goal statement would have to be carefully honed to elevate it to something truly aspirational.

To help team members understand the value of collaboration, it must be practiced across departmental units. If teamwork is only ever practiced inside a department, no one learns to work effectively at an enterprise level. Teamwork must also be an important component of the work of the leadership. If the leaders preach collaboration, but never practice it themselves, the efforts of team members are likely to be undermined. And leaders must remember that the point of teamwork is not teamwork but getting great results.

Finally, leaders must continually use the language of collaboration with every team member and at every opportunity. One CEO spent 20 percent of his time talking about the importance of collaboration. Keeping the message strong and highly visible helps keep everyone focused.

So—how does a manager bring together those reluctant instructional designers and technical writers in a collaborative effort to design the best information for the customer and design it together?

First, articulate a clear and compelling goal that expresses the value of a collaborative effort. The goal might include the value of saving everyone’s time, getting to market faster, decreasing costs, and producing content that best meets the needs of the customer.

Second, the leaders of each team and the senior manager who is the project champion must themselves demonstrate the importance of collaboration by collaborating to articulate the goals, measure performance, and clear a path to success for the team members.

Last, the leaders must continually talk about the value of the collaborative effort, explaining to everyone in earshot just how important the collaboration is to the company and to beating the competition.

If training and documentation collaborate, they can create exactly the core content that customers need to get started, to solve problems, and to take full advantage of product capabilities. They can avoid duplicating effort by designing, developing, and sharing units of content that become the building blocks of instructional information, whether that information is delivered as topics or videos or slide sets or in instructor-led classes. They can ensure that customers are able to find the right information, in the right place, at the right time, and without confusion.