Non-technical problems

Norm Walsh has posted a provocative discussion of DITA and DocBook on his blog (a writeup of a presentation he delivered at the recent DITA 2006 conference).

My favorite part, though, is an explanation of a typical consulting sales process. The technical part of an XML implementation is difficult — but the real challenge lies elsewhere, as Norm explains:

The non-technical problems […] were the fact that writing reusable documents is different, often very different, from the way the authors had been writing. And authoring within a strict structure is different, often very different, from the way authors had been writing. And different means change and change is hard. In other words, training authors to write reusable documentation and training them to write correctly structured documentation, usually in a totally different kind of editing tool, is really, really hard.

Indeed. Managing expectations, change resistance, and learning to work in a structured authoring environment are much more challenging than the technical issues. I disagree, though, with Norm’s concluding sentence:

And there was basically nothing we could do to help them with [the non-technical] problem.

There’s quite a lot we can do to help with the non-technical side of the implementation:

• We deliver introductory classes on structured authoring and XML concepts.
• We assess the gap between current authoring practices and XML-based authoring. There’s a big difference between a group that has and uses templates and a group that practices “as long as it looks good on paper, nobody cares what’s in the file.”
• We help managers and technical leads develop a strategy to educate authors about the upcoming changes.
• In some situations, we have done phased implementations to give authors more time to adjust.

What are your thoughts? Are there solutions to the “non-technical problem”?