by David Kelly
Presented by Keith Schengili-Roberts from AMD, Inc., this session told the story of a successful implementation of a DITA/CMS solution. And that’s always a good kind of story to hear.
I don’t think there was anything unusual about the problem they were trying to solve. One thing it had in common with all the successful implementations I’ve heard about is that they had to translate their documentation into a lot of different languages — 25 or so. At lunch I asked the folks sitting at my table whether they were aware of any CMS implementations that had been justified by anything other than localization savings. No takers.
One analysis presented was why the addition of more writers was not going to solve the problem. I don’t have all the details of the analysis at hand, and this is a blog, where brevity is a virtue (though I do love to write in Russian novelist mode), so you’ll have to take his word for it. It doesn’t.
Some keys to their success:
* Meeting customers, getting their requirements for documents and delivery.
* Buy-in from management
* Working with the writers on the cognitive change to topic-based writing (training, etc.).
* Providing time for the writers to handle the extra overhead.
* Clear definition of roles. Engineers became responsible for correctness and completion of content, writers became responsible for clearness and consistency of content. To this point he mentioned that DITA allows tagging in multiple ways; editors are needed for tagging style.
He enumerated a large number of advantages that DITA provided, which I won’t repeat here. They chose Ixiasoft for the CMS, who later productized the customer DITA solution they developed for AMD (hope AMD got a price break). He did not mention they reasons for choosing Ixiasoft as far as I recall.
For an editor he began with the statement, “WYSIWYGs are detrimental to DITA.” This brought a rousing cheer of approval from Bruce Nevin, a Cisco Information Architect who was sitting right behind me. Keith said they chose oXygen, which I should have cheered since that is my own personal XML editor of choice. But then I do a lot of XSL development and I’ve always thought it was a little geeky for the average tech writer. Maybe Keith’s tech writers are like the folks in Lake Woebegon, Minn., who Garrison Keilor claims are all “above average.” Although when they had WYSIWYG editors, Keith said they were spending as much as 50% of their time on formatting. Whew, and I thought I was picky.
Keith presented several statistics to substantiate his claims of success. He was able to do this by relying on the reporting tools from the CMS, which he stated were significant aids to management in general. The statistics he presented were, for the most part, fairly abstract, but a couple stuck. One was the savings of 10% to 13% in localization costs. He admitted this was conservative, and it is indeed low compared to other claims I have heard, but he had included the purchase of Unicode fonts (Unicode in general was a big help) and the original conversion costs.
One success that he did not expect was that they doubled their output and halved the median project time. The localization savings were expected, but not the development savings.
In general this was a clear, astute, nuts and bolts presentation that gave a lot of information about the inner workings of a CMS/DITA implementation. Mr. Schengili-Roberts is obviously fond of metrics and objective data, so I suspect his claims were not exaggerated.