Ever wonder how converting to a DITA/XML content management system would play out in real life? What if we added globalization? What if it showed nearly $100,000 savings for the first two deliverables (in 9 languages)? This step-by-step plan, by Jennifer Linton of CaridianBCT (formerly Gambro BCT), tells us exactly how it played out for them. In Part One you'll learn how this multi-national, regulated medical device company planned its migration to a DITA CMS by identifying stakeholders and defining personas, establishing a high-level process and system requirements, developing a content model, and figuring out what to do with legacy documents. In an upcoming Part Two we'll cover future concerns, how they calculated cost savings, and the lessons learned.

As I sit writing this article, it excites me to think about the potential growth opportunities for technical documentation departments across the world to implement standard and robust business processes and tools that improve efficiency, deliverable quality, and of course reduce costs. I started working at CaridianBCT about a year and a half ago and we have come a long way toward embracing these opportunities. This article is an overview of our journey into a structured authoring and translation environment.

CaridianBCT is a highly regulated medical device company, and our Technical Communications Department is implementing a content management system, translation management system, and DITA authoring environment. The Technical Communications Department is responsible for authoring and translating all labels for CaridianBCT equipment, Operator's Manuals, Instructions for Use (IFUs); kit, case, and bag labels; service manuals, preventive maintenance procedures, schematics, installation procedures, spare parts instructions, training materials, protocols, Standard Operating Procedures (SOPs), and more.

Managing an increasing deliverables load while maintaining consistency

Not only does the authoring and translation part of our process take time, but CaridianBCT is also heavily regulated globally, requiring an intensive document control and release process. Some of the regulated bodies the company abides to include the USA FDA, the EMEA Medical Device Directive (MDD), the Canadian Health Canada and Canadian Standards Association (CSA), the APAC International Electromechanical Commission (IEC) and International Standards Organization (ISO), as well as our internal SOPs and MDD definitions. Because each region and country has specific standards, parts of each deliverable may need to be specific to that country while the majority of the content is the same.

"About three years ago, CaridianBCT asked the question, "How are we going to manage the increasing number of deliverables we have to maintain because of all the different customer needs in each country?"

About three years ago, CaridianBCT asked the question, "How are we going to manage the increasing number of deliverables we have to maintain because of all the different customer needs in each country?" The number of labels increases each year and the content must remain consistent between each of the deliverables. Our customers continue requesting paper and electronic-based deliverables with the same content. Not to mention, the cost to translate each of these deliverables can be extremely costly.

Our solution to these questions was to implement a content management system integrated with a translation management system, and use a structured authoring (DITA) environment. We call this the Globalization and English Management System (GEM). DITA allows us to create reusable and consistent content to produce our deliverables. The Content Management System (Astoria On-Demand) allows us to have a central storage location accessible to all authors and departments. And, the Translation Management System (World Server) allows us to manage our translation projects, our translation memory, and improve term consistency. It seems like this is all we would need right? Wrong.

Identifying the steps

In order to implement these tools, technologies, and new processes, the Technical Documentation Department prepared thoroughly to get to where we are now. The topics we discussed to prepare for the new environment include:

• Identifying all stakeholders
• Defining personas
• Establishing a high-level process
• Developing system requirements
• Creating an information model, a localization style guide, CMS and TMS (Translation Management system) user guides
• and, documenting business processes, procedures, and best practices

"For each of these stakeholders, we planned various informational/introductory meetings, formal trainings, and brainstorming sessions to ensure everyone had some level of comfort with our changes."

Of course, when identifying stakeholders, there are some that are obvious. Upper management, authors, and reviewers are some that come to mind immediately. In our department, we also identified those responsible for translations as a major stakeholder. Not only do the translation project managers need to be aware of the changes, but those outside our company need sufficient training and change management as well. These groups include our localization service providers (LSPs), translators, and our in-country reviewers. We also needed to discuss our changes with our regulatory department to establish an approval process for individual DITA topics. For each of these stakeholders, we planned various informational/introductory meetings, formal trainings, and brainstorming sessions to ensure everyone had some level of comfort with our changes.

Developing the future environment persona descriptions was critical to the group. These descriptions identified the roles, responsibilities, and training plans within the department. The personas don't identify anyone in particular by name, but rather identify on a high level what each role should need to know moving forward for a successful implementation. This helped identify where our department may have lacked resources. The personas we identified include writer/content contributor, editor, project manager, reviewer/approver, production coordinator, information architect, tools super user, and localization project managers and coordinators. Each of these roles may be filled by multiple people, and a single person may wear many hats to satisfy multiple persona roles. We did discover that some responsibilities needed to shift among the group, but most roles were already established.

Mapping out the process

"When developing this process it was important to keep in mind the environment that we wanted in the future rather than the old document-based environment…."

Our high level process was also very important to the rollout of the new environment. When developing this process it was important to keep in mind the environment that we wanted in the future rather than the old document-based environment, so we had to factor in quite a few changes to accommodate topic-based DITA authoring, content management, and translation management. The process set the stage for how we wanted the future environment. This process, which consists of power point flow charts and a more detailed swim lane definition of the process, is a powerful change management tool to refer to when bringing new people into the environment. Our process consisted of eight phases including:

• Plan/Design - Authors create a project plan specification, master topic list, and initial shell DITA Map (TOC) for initial review and approval
• In Development - Authors create topic content (tasks, concepts, and references) and initiate a workflow to send groups of topics to their subject matter experts (SMEs) for review
• Review/Validate - Reviewers add annotations to the content using the online review tool
• Approve - This was a major change to our process (which we are still working on). Previously we didn't need to send content for approval before translation because we waited until the entire English manual was completely approved before translating it. Now we built an approve phase into our process where authors and approvers approve individual topics to "freeze" the content before sending it to translation. This helps reduce mid-translation project changes, lowers translation costs, and streamlines the translation timeline so that there is less of a bottleneck.
• Translate - Send groups of topics where the English source content changes are sent for translation. This management of the relationship between the English and translated content provides a large cost saving because now we don't have to send an entire manual to translation again when most of the content had already been translated.
• Assemble/Produce - Automatically apply stylesheets to produce deliverables to deliver to different media including PDF, HTML, RTF (Word), and PDA/Mobile Devices.
• ECO (Engineering Change Order) - Content approvers review the deliverable as a whole to approve the final output. Much of the content approval is complete at this stage due to the new approve phase. This phase is a regulatory step needed to approve the final output.
• Publish/Deliver - Technical Communications department sends the final output to the printer or web publishing groups.

Developing system requirements

The next step in our planning was to develop system requirements. Items to think about when implementing a content management system for a DITA XML topic-based environment are different than if you were to implement a companywide content management system. Our department initially started to implement Documentum until we discovered that, at the time, we could not use the technology to handle our XML topics robustly enough. Before identifying a system, we had to make sure we knew the different features of DITA before intelligently applying those features to how they should work in a content management system. For example, using the DITA conref feature is something that may be significant to content management systems that fully support DITA. We actually conducted some proofs of concept on our individual file systems and researched DITA significantly before developing our system requirements. These requirements also had guidelines that followed our "new" process including translation management functionality, automatic publishing, online review and more. As mentioned before, it was critical to these next steps in our planning to already have discussed and documented our future process.

Identifying a content model

Our information model defines the CaridianBCT-specific guidelines for using DITA. In this document we identify specific DITA elements to use while authoring such as the information types, content units, map elements, body elements, and inline elements we use. It also identifies the metadata, CMS and TMS folder structures, and naming conventions.

The CMS/TMS user guides document the specific tasks we perform when using the CMS or TMS. Each system provides general help documentation, but in some instances, we had to identify workarounds or more detailed steps for how to accomplish a task. Also, because the CMS and TMS are separate systems, the user guides identify how to use the integration between the two systems. Some of the tasks we identified include Producing a Deliverable, Adding a Content Reference, Conditionally Filtering a Deliverable, Sending Topics to Translation, and Sending Updates to a Translation Project Already in Progress. These user guides provide ongoing learning tools for people to reference as well as new people coming into the department to learn the environment.

Documenting business processes

Along with these more technical procedures, we documented business processes. The business processes deal more with how to work in a topic-based environment. Some example include Planning a DITA Project, Performing QA on Topics and Deliverables in all Languages, Identifying Stylesheet Errors, Updating the Terminology Database, and Sending Topics to the Subject Matter Experts for Review. These tasks are more process oriented and relate back to the high level process we developed when preparing for the new environment while also including details about the granular parts of the process.

"Within a year, we will have the majority of major deliverables in the content management system..."

So, we are still developing some of these tools and of course they are live documents that can change as needed. However, this preparation has helped us ramp up our implementation quickly. Within a year, we will have the majority of major deliverables in the content management system, and we are utilizing the reuse capabilities to produce multiple location- and revision-specific deliverables to different media.

What to do with legacy content

"In order to get our content into our content management system and DITA authoring environment quickly, we decided to use an automated conversion process."

In order to get our content into our content management system and DITA authoring environment quickly, we decided to use an automated conversion process. We worked with Data Conversion Laboratory to develop specifications that mapped our current FrameMaker templates to our DITA Information Model. Fortunately our authors already wrote in a fairly topic-oriented way in our FrameMaker manuals making the conversion easier than not. We still do need to do some cleanup on our content after we get it back from conversion, but for the most part, it helps move our content into our future authoring environment quickly.

DCLnews Editorial
September 2008