The Background
Before RIM started using DITA, they were using FrameMaker along with Perforce to keep track of their documents, and paid a premium to their Localization Service Provider for desktop publishing as well as the translation of their documents. These are the classic elements for a solid R.O.I. argument to move to DITA XML. At this point the writing team consisted of roughly 20 technical writers and support personnel, who produced six different types of output types in 18 languages.
So RIM moved to using DITA back in 2005, not long after it became a public standard. They were hitting the technical limits of their existing tools, localization costs were climbing ever higher while at the same time there was increased demand for additional output formats for a rapidly increasing number of products. They picked a first-generation documentation CMS that was based in XML but was not specifically DITA-aware – back then, no such product existed. Thanks to their early adoption of DITA they were able to meet increasing demands for content while reducing production costs, and they now support 45 different types of documents formats in up to 51 languages (the latest addition being Ukrainian).
Moving from One DITA CMS to Another
By the end of 2010 their DITA-based processes were mature: the writing and related support/account staff had grown to meet the demand for more content, but by this point the original CMS was beginning to show its age. Since it was not natively DITA-aware considerable work had to be done to ensure that it behaved with content in a way that conformed both to the DITA specification and to the way that their writers expected it to. It was also proving to be insufficiently capable of meeting the increased demand for localized output in a timely manner. Last but not least was that the company that owned the CMS software was sunsetting the product. So in 2011 RIM started the search for a new DITA CMS.
Since the presentation was hosted at the Ixiasoft DITA CMS conference, there’s no prize for guessing which DITA CMS they ended up moving to. 😉 What was interesting was hearing about the advantages and the lessons learned from moving from the legacy DITA CMS to the new one.
Their suspicions that their old CMS was underperforming were correct, especially when it came to the time needed to produce output. Their User Guide consists of ~1,600 topics, which took the old CMS 50-60 minutes to produce output for each language. Using the Ixiasoft DITA CMS it only took 3-5 minutes, a roughly 90% time saving. This matters to RIM who are make this document available in 33 languages. What used to take a total of 27.5-33 hours (roughly 3-4 days) under the old system now takes only 1.65-2.75 hours (less than half a day) using the Ixiasoft DITA CMS. The new CMS is also DITA-aware, making it considerably more robust and easier-to-use.
There were considerable challenges RIM had to overcome in moving to the new DITA CMS. For one thing they changed their existing workflow to better fit the model that the Ixiasoft DITA CMS uses. Training was given to the writing staff, but in hindsight it was not properly aligned to their content migration process, and the writers took it too early, so they forgot what they had learned when they actually needed to put it into practice. When migrating their legacy localized content they discovered that their localized maps sometimes had a different number of topics in them depending on the language. This issue had lain undiscovered under the old system and was only revealed when RIM moved to the new CMS. This took time and effort to sort out. There was also a significant one-time cost in moving to the more-efficient XLIFF-based translation process, as most of their content from the old system equated to less than 100% matches in the new CMS.
What Was Learned
Much was learned in the transition process to the new CMS, and their advice to other firms contemplating a similar move includes:
• Knowing that on-paper decisions will likely change after experiencing the system, so be flexible
• Expect growing pains but mitigate negative sentiments
• There’s no such thing as over-communication, but be smart about it and don’t “email bomb” everyone with minor updates
• Ensure that decisions made reflect the entire user base and not just the early adopters
• Ensure that users feel involved in the decision-making process
• Document your system and how your teams will use it.
RIM’s future documentation plans (at least at the time of the conference in June) are to move forward with Acrolinx integration to further improve the consistency of their terminology usage, implement DITA for their training content, and work to eliminate any outstanding pain points arising from moving from one CMS to another. They are also looking forward to getting better production metrics which are easier to obtain in the new CMS, and to integrate with their internal bug-tracking software in order to close the loop on documentation bugs.
To prove the point that greater efficiencies were needed and the move to the new CMS was a necessity, the presenter concluded by saying that it took about five years to produce a million topics in their old CMS. They expect to hit that same number of new topics by the end of only their first year of production in the new CMS.
If you are interested in reading the presentation for yourself, you can find a copy of it on the Ixiasoft site here, along with links to all of the other presentations that were made at the conference.
