JoAnn Hackos, PhD
Collaboration is a hot topic these days in the enterprise content management and knowledge management worlds. Product developers are working on solutions that will make it easier for people to work together to develop content, share ideas, enhance knowledge, and generally contribute to innovative activities. They offer us managed intranet and extranet sites that support the exchange of ideas. They support threaded discussions, instant messaging, check in/check out with version control, and co-authoring of documents. They add in the ability to view each other’s comments on documents in real time.
Investments in collaboration technologies promise significant returns on investment. Vendors predict that collaboration allows us to reduce costs by streamlining development processes internally and externally. They predict that more people will participate in collaborative activities if the processes are extended across the enterprise.
Collaborative techniques, with or without the support of technology, are a necessary ingredient to successful content reuse strategies. I fail to see how we can produce reusable content without teamwork. In the most successful cases, teams of information developers create a comprehensive plan for the content they will produce to support a project. Although individuals are assigned responsibility for developing individual modules, they regularly review one another’s work, share insights and knowledge, and generally contribute to producing an innovative product.
In my own work, I’ve suggested that collaborative development generally produces more innovative results than individual efforts. In our experiments with collaboration at the Colorado School of Mines in the early 1980s, we found that teams that included participants with diverse points of view produced more interesting and more thoroughly examined and tested outcomes than individual students did working alone.
In our work as designers and information developers at Comtech in the 80s and 90s, we learned that collaboration improved productivity and increased the effectiveness of our teams. Writers, editors, and project managers spent a higher percentage of project time on planning and less on rewriting when they worked closely together. Collaborative teams tended to reuse more content and produce better reviewed, more carefully constructed user information. Decreased development costs were routinely accompanied by great improvements in customer-delivered quality.
When collaborative solutions extended beyond the information-development team to the product developers, product managers, usability and marketing specialists, and others, we found that we improved internal communication among teams, extended the reach of innovative ideas, actually reduced costs, and achieved high added value for customers. In one of our earliest projects after starting Comtech in the late 1970s, we collaborated with product developers, training, and management to design an innovative user-centered hospital information management system, accompanied by documentation and training, that was years ahead of the competition.
Formal collaborative techniques are most effective
In every case, I’ve found that managed, formal collaboration works better than informal collaboration when it comes to product or information development. Informal collaboration is perfectly acceptable for short term and ad hoc planning activities. People come together to support one another on an activity for a brief time. But as soon as an activity has a deadline and a deliverable, more formal techniques are required.
Most teams, I find, need to be managed. Someone must be responsible for scheduling tasks and obtaining resources, monitoring task activities, scheduling and preparing notes from meetings, and making sure that everyone contributes to the review process. Central management of collaborative teams appears to be essential to their success.
In our experiment at the School of Mines, we found that teams that developed a natural leader quickly in a group of otherwise equal students were more likely to be successful than ones that lacked leadership. Of course, some groups had too many potential leaders, often leading to conflict.
You might discover that some combination of informal and formal collaboration works best. The team processes are formally managed, but informal groups emerge naturally to solve particular problems and to develop ideas.
Collaborative teams require leadership
Leadership of collaborative groups is a difficult task. The leader of a collaborative team has to work hard to inspire trust and to introduce problems and issues that will spark the creativity of team members. This sort of inspirational leadership is difficult to find in many organizations. A leader of this type is not always easy to work for, but the results of working with the leader are always exciting and often rewarding.
Despite the clear advantages many of us have achieved with collaborative teams and despite the excitement and energy they usually generate, I find that technical communicators are often reluctant team members. Perhaps it’s a matter of personality type. The Meyers-Briggs types INTJ (Introvert Innovative Thinking Judging) and ISTJ (Introvert Sensing Thinking Judging) dominate the technical communication field. A predominantly introverted group, writers often prefer to work alone, experiencing some difficulty when asked to produce ideas and argue about them in fast-moving teams. Most introverts prefer to mull over a problem in private, only offering ideas after they’ve been well worked. Extroverts are more likely to verbalize ideas easily and to use discussion to hone their points of view.
Introverted technical communicators can function very well on collaborative teams, as long as they have opportunities to work out ideas before and after team meetings and introduce some of their thoughts in writing rather than verbally.
But beware the introverted manager. I have long maintained that project managers need to be extroverts, or at least good at acting like extroverts, if they are to be successful in motivating others and reinforcing collaborative behaviors. If the leader hides in his or her office, busy with paperwork or editing, the team is likely to flounder.
Developing a collaborative team
By following a simple plan, you can make rapid progress at developing a collaborative team to plan, design, and develop modular, topic-based information.
- Select team members for your first excursion into collaboration from among those most enthusiastic about topic-based authoring and content management.
- At the initial team meeting, describe your vision for the project and the goals that you hope to achieve. Explain the process you will use to encourage collaboration.
- Begin the process at the planning stage. In many cases, once you describe your vision for the project in terms of topic-based authoring and information reuse, team members will go out to collect information about the project specifications and requirements for information development. Ask them to return in a specified amount of time with their results.
- Meet with team members to review the information requirements for the project. Focus initially on what users will have to learn to do to use the product successfully. Create a comprehensive list of tasks that users will need to perform, including tasks already in the existing information, tasks that must be revised for the new release, and tasks that are new or substantially changed.
- Based on the list of tasks, identify supporting information. You may need conceptual, reference, and other background information to enable users to perform successfully. In identifying all your information types, you will produce a picture of the content that must be created for the project. By involving all team members in this collecting and sorting process, they all gradually become familiar with the universe of project content, rather than knowing only about the content they will develop.
- Your collaborative team will produce a comprehensive content plan for the project. The content plan lists all the modules that will be needed, existing or not, and the list of final deliverables to be produced from the modules. Some groups use large tables or spreadsheets to organize the modules and indicate in which final deliverable they will appear. Assign ownership of the final deliverables to team members.
- With a list in hand, work with team members to make assignments. Add the assignments to the table. Note which modules will be used in more than one deliverable, and ensure that the deliverable owners know when and where they must coordinate efforts. Modules to be reused must usually be negotiated between more than one author to decide upon the appropriate level of content.
- If individual modules will require some variation in content to accommodate different deliverables, team members must decide how to handle the variations. If the variations are extensive, you may want to create more than one version of the module and maintain links between them. If the variations are discrete, you may be able to handle the variations inside the modules.
- With assignments and responsibilities in hand, team members begin authoring, reviewing, and editing. It will be critical that they can review each other’s work, especially for the shared information. Even if you have writing guidelines and a style guide in place, you will still need to ensure that consistency is maintained. Your role as leader is to help resolve differences and make final decisions.
- Once the modular information is in development, work with team members to track the content. Be vigilant about changes in the project that necessitate new modules or different divisions among modules than initially planned. Monitoring project changes will often require that content be reassigned or assigned anew.
- As the project develops, ensure that those responsible for the deliverables begin testing the modular content against the final list of topics. This list may be a Table of Contents for books or content presented in tabular form in help systems or linked form in web sites. All of the outputs must be planned in advance and tested against the plan.
- Finally, focus the team members on their responsibility of getting the integrated content reviewed for continuity. Consistency of your initial design and writing will go a long way toward ensuring the integrity of the content in context, but you still need a review process to spot gaps and overlaps.
Developing modular content will be a significant challenge for an initial collaborative team. The tendency to go off and write something or rewrite rather than reuse will be strong. Keep reminding the team of the original vision. As the leader of a collaborative team, understand that your primary responsibility, in addition to plain project management, is to serve as keeper of the single sourcing and reuse vision.
From more than 20 years of experience with them, I have confidence that collaborative teams not only can and do work, but that they can be remarkably successful. The key to success is constant communication and that communication is the leader’s responsibility. Find strength in the experience of others, especially when the going gets tough. The rewards are worth the struggle.