That was not a question that was part of our initial survey, but for the Mekon case study example, where we have detailed information, stakeholders were given education with frequency and depth according to their 'closeness' to the project. The pilot team was getting conceptual introductions and even complete DITA training courses up to 24 months before the actual implementation (which is possibly what you mean by "effort to move"?) began. There was also some major sessions of training or education at least every six months and less formally in between those. The authors not directly involved in the pilot were given conceptual and process educational sessions (usually webinars and presentations of 30-90 minutes every three months or so from 24 months out).

The less directly involved stakeholders, like service and support staff, were given briefs on how the processes might differ and what feedback was requested from them, also from about 18 months out, as part of the requirements development process. Again, their education was in the form of web presentations and a few onsite workshops to review current issues and future requirements.

Pagination and image placement are inherent issues in automation, since computers don't do very well with the aesthetic issues that are largely subjective. You may have set up a document with page-breaks as you want them, then when someone changes a shared topic somewhere in the middle of a chapter, that throws off the pagination again. In a collaborative DITA environment, page breaks are often the kids who suffer when we divorce content from format.

There are a few parts to the resolution of this issue. First, the speed and economic benefits of a "lights out" publishing process outweigh these aesthetic imperfections for many kinds of documents; what we call the "good enough" solution. DITA can save organizations hundreds and often thousands of man-hours a year and also speeds up production and improves deliverables for end users; but, yes, the page breaks aren't as nice.

Second, depending on how your content and team are set up, and what publishing tool you use, maybe you can cheat. We have implementations where, instead of a fully automated 'black box' XSL:FO system which takes in DITA and spits out a PDF, we use FrameMaker. This allows you to 'cheat' by capturing the FM files on the way out and manually adjust them. This also lets you automate web/alternative formats completely, but fudge the print to your liking. We don't fully recommend this as it's not the best practice, but it is an option for when a page break is make-or-break.

Several companies in our surveys reported that for those materials in which the aesthetics and layout precision are more important, they use a post-process to compose those portions.

There are comparatively few CCMSs (Component Content Management Systems) that can do DITA properly. In our survey the CMSs utilized included (in alphabetical order):

• Astoria
• Ixiasoft DITA CMS
• Really Strategies DocZone
• SDL Trisoft (and Content@)
• Vasont

In our survey the WYSIWYG XML editors utilized included (in alphabetical order):

• Arbortext Epic
• JustSystems XMetaL
• Oxygen
• Syntext Serna XML

The companies in DCL's survey all reported having teams of technical writers, with non-techwriters providing materials at some level.

In the Mekon case, like many of the projects, there was significant SME-generated content. It was being generated in the offices where there were a smaller number of professional authors; therefore more content creation was pushed out onto the SMEs. In this particular case, the intention is that additional author resources will be added to start re-writing content according to very strict content standards, with SMEs as reviewers. To try to bridge the gap between SMEs and authors, they were trained in Technical Simplified English to help them write in a more minimalist and standardized way. Then, when the content got to authors, it was less work to move it to DITA. In other projects, we've put MS Word-based XML tools out to the SME group so that they could author directly into DITA. We have also pushed out templates that are designed to round-trip content from Word to XML to streamline the process. This can be suitable in cases where installing XML authoring tools or providing guidance/training for SMEs is not practical.

See answer to Q5.

In general we encourage that you look at:

1. Typical CCM baseline functions:
   1. Check in/out, versioning and roll-back, state-based workflow that can trigger automation scripts, etc.
2. Scalability (how many concurrent users you anticipate)
3. Pricing model (some favor smaller or larger roll-out heavily)
4. Quality of implementation of conref and DITAmap editing
5. Handling of DITA prolog metadata and the expense of using DITA prolog metadata, and/or easily customizable metadata model
6. Handling of DITA conditional attributes and reporting on them (seeing condition used in a map for example)
7. Allow support for dynamic (always update with the latest content) or static content reuse (don't update my content unless I explicitly ask for the latest versions of everything)
8. Reputation among industry experts and/or reference customers with whom you have been able to make contact

It is also nice to have:

1. Pre-checking of broken links without having to build the output
2. The authoring tool of your choice integrated
3. Sensible reviewing features (most don't have these!)
4. SME contributor tools/licenses with appropriate lower price-points
5. References in your industry (this is one our clients like but as long as the functions are there, it's not always as relevant as one might think).

Regarding the two cases in the DCL survey, the needed change seemed to be because the system was 'sold' without sufficient piloting and requirements development. In retrospect, they didn't do a full analysis and jumped straight into tools and implementation. What then happens is that someone realizes that they need something that the system either can't do, or the company involved is not willing to support them in developing.

This is very much a question of your situation and business. Without understanding more about it, any advice we give here is simply what do 'most companies' get their DITA value from. You want to be focusing on where you might get your value. DITA may be equally good at content management and flexible publishing, but content management is harder than automatic publishing, as it involves changes to workflows, collaboration paradigms and mindsets. So, most organizations probably realize the publishing benefits because they're easier. That doesn't mean they're better benefits - I'd argue that they're not - but they're the lower-hanging fruit. An organization can invite a consultant to convert their content, implement a system, and get three outputs at the end of the process instead of one, but that is only scratching the surface of the potential.

What DITA does for them or us is not really important; what you and your business need, and whether or not DITA can do that, is. I've sort of assumed that by saying 'flexible' publishing you meant only multi-format or single-source publishing. Real content repurposing and dynamic publishing could mean something quite different, in which case, unless you do both, you're not going to achieve the end goal. If you want really 'flexible' content, you're going to have to manage your creation and management processes properly or else you'll end up with Franken-docs that don't read properly when content is reassembled in new ways.