Best Practice: Change Management and Writer/Artist User Groups
The implementation of a new information development strategy is a major undertaking for any organization. From selecting and installing new software tools to inventing new department processes and redefining department roles and responsibilities, the changes are non-stop. It can take years to fully implement a new system. A critical component of any implementation or change management process is building the user perspective and user participation into the project. If the users don’t get it, don’t like it, and don’t stay on board, the project may launch, but never reach the final destination. During the past year, our department discovered the value of forming a writer user group to kick-start a stalled implementation process.
Background: Implementing Single Sourcing at Medtronic
The December 2002 issue of CIDM Best Practices included a case study of our implementation of the Medtronic Advanced Publishing System (MAPS), a database publishing system. MAPS was designed to
satisfy requirements for auditable design control of regulated product documentation
control translation costs and reduce translation cycle time through reuse of content
automate layout and composition of documentation
The 2002 study included promising findings that supported Medtronic’s $3 million investment in the project. By early 2003, the results were even better. In addition to increasing the auditability of information development, MAPS significantly reduced the cost and
time to translate and publish product documentation. Despite the impressive statistics and production of hundreds of deliverables in MAPS, the department was struggling to integrate the English information development process with the goals and design of the database publishing system. We hadn’t reached an important part of our original vision for single sourcing: implementing an information development strategy called domain-based writing.
The Original Vision: Domain-Based Writing
In a domain-based writing environment, writers specialize in several domains or topic areas. For example, in the world of medical device documentation, a writer may own the following domains: hazards, indications and contraindications, and regulatory. Domain owners take responsibility for all information modules in the database in his or her domains. They become the go-to person on selected topics; are expected to research and understand past, present, and future issues related to their domains; and ensure that domain content is accurate and written to support reuse. Domain writers work collaboratively with each other and a project coordinator to produce technical documentation deliverables. Domain-based writing ensures that someone is watching over every piece of content in the database, which supports a well maintained, high-quality repository of information.
The Problem: Three Barriers to Change
At first glance, domain-based writing seemed like a clear-cut proposition: just figure out the domains, assign the domains to writers, and get going. However, as the department began the process of implementing domain-based writing, it encountered several barriers.
First, this is really hard work. Adopting domain-based writing in a regulated environment presents interesting challenges. Figuring out the nitty-gritty of how things could, would, or should work gets very complicated, very fast. Domain-based writing adds a level of cognitive complexity to an already technically challenging task: writing documentation for regulated, sophisticated medical devices. For example, medical device documentation is heavily reviewed. In the old system, a writer could quickly make suggested changes and move on. In a domain-based environment, the writer makes changes to individual modules and changing one module may impact dozens of regulated deliverables. Incorporating a single change can develop into a significant research project.
Second, we don’t really have to change. It was possible to use the old “silo” information development process-one or two writers creating an entire book-with the new software tools. This allowed the department to delay shifting to domain-based writing without impacting production in the near term. It also supported the hope that “it will all work out someday” and sustained a “maybe it will all just go away” attitude. Yet the results of using the “silo” process meant that the database was filling up with redundant, badly named and maintained content.
Third, the no-man’s-land of tools versus process. The MAPS software tools were custom developed by a small team of Technical Communication department employees. While this solution offered numerous advantages, building your own system comes with its own set of risks. The development team brought years of technical writing experience to the project and was able to actively involve the department in the design of the tools. However, it’s hard to manage user expectations during the software development period-version 1.0 and even 2.0 are bound to be less than perfect; and while it feels good to be the only user group of the software, you are the only user group. When the software developers are your colleagues and sit in the next cubicles, it’s more difficult to establish and maintain business and operating boundaries that exist between an external system vendor and customer. When issues arise, the questions multiply. Is this a process issue? A tool issue? A people issue? Or a combination, a process-tool-people issue? If so, who’s responsible for resolving the issue?
Medtronic’s Writer/Artist User Group: MUGs
In late 2003, the department launched a user group called MUGs. MUGs provides an ongoing forum for the people in the trenches-the writers and artists-to articulate, discuss, and address information development tool and process issues. This includes working with MAPS and other software tools, as well as working in a collaborative database publishing environment. The goals of MUGs are to
improve the effectiveness and productivity of the information development process by uncovering and addressing workflow and process issues
develop and document best practices and strategies for authoring in the new environment
improve communication and morale in the department regarding the change to the new authoring environment
What does MUGs mean?
The acronym MUGs stands for MAPS User Group. While MUGs does not limit itself to working on issues related to MAPS software, the name MAPS has come to represent the shift to a new authoring environment. While the MAPS software team sends representatives to the MUGs meetings, the group operates independently of MAPS.
Basic operation of MUGs
The MUGs coordinating team, a small group of non-management department employees, plan monthly 90-minute meetings.
Each member of the coordinating team takes responsibility for a given aspect of the information development process:
- software tools (MAPS, company manufacturing database, FrameMaker, Acrobat)
- authoring process issues (editing, style guide, best practices for reuse, collaborative writing, working with the European translation group)
- training needs and resources
- graphic artist tools and process issues
The coordinating team members also present topics and facilitate large and small group discussions at meetings.
Typical MUGs meeting agenda
A typical MUGs meeting agenda includes
- MAPS database reports
- Update on database activity: number of module check-ins, reuse of content, new domains, number of unused modules resolved
- several 5 to 15 minute presentations on various subjects. Sample topics include
- style guide/editing changes and reminders
- tool and process tips
- individual writers present special activities, techniques, or projects
- MAPS software design input
- intensive, small group discussion on a selected topic. Examples include
- best practices: working with European translations group
- best practices: evaluating writer performance in new authoring environment
- best practices: working with regulatory affairs
- best practices: deciding whether to clone or revise a module
- MAPS tool issue: taking graphics out of text modules idea
Impact of MUGs
During the past year, MUGs has been instrumental in reviving the department’s implementation of single sourcing. In response to issues initially raised at MUGs meetings, the MAPS team incorporated several tool suggestions into recent releases, and the department managers have launched efforts to address several process issues. Issues included a recent reorganization of department management and writer roles to support the domain writing environment. In addition to opening up communication on difficult issues, MUGs has created a sense of fun and community for writers and graphic artists.
Check out the photo of our official MUGS coffee mug.
Change management and user groups
Forming a writer/artist user group aligns closely with recommendations found in change management literature. During the final session of the October 2004 CIDM Best Practices conference, members of the 2003-2004 Innovator’s Forum described how they leveraged strategies found in John Kotter’s Heart of Change to effect a significant change in their organization. At some level, developing a writer/artist user group intersects with each of the eight steps found in Kotter’s model of change. A user group is a particularly valuable resource for getting through the final phases, Steps 7 and 8, of a major change process.
Step 7 is the Don’t Let Up phase. This is the moment when it’s tempting to prematurely declare victory. Kotter warns, “You’re not done until the change has been entrenched in the very fiber of the organization.” User groups help to keep the momentum going, allowing managers and writers to keep their fingers on the pulse of the change process.
Step 8 is the Make Changes Stick phase. Kotter calls for building “a supportive structure that provides roots for new ways of operating.” An ongoing user group provides a forum for writers and artists to work on best practices, identify unmet needs, and take ownership of the changes.
Kotter argues, “The heart of change is in our emotions. The flow of see-feel-change is more powerful than the flow of analysis-think-change.” Yes, it’s necessary to do the rational analysis and build the logical business case for change, but leading change is “less a matter of giving people analysis to influence their thoughts than helping them to see a truth to influence their feelings.” Whether using commercial or internally developed tools, the implementation of a new information development environment is difficult. A writer/artist user group offers a powerful place for people to feel and share their way through major changes in technology and process.
About the Author