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”?
Indeed, Sarah, you’re absolutely right that that there are things we can do to help users with the non-technical problems. In fact, we did those things when I was consulting.
But whereas the technical problems can be “fixed”, the non-technical ones require the things you suggested: managing expectations, helping people overcome resistence to change, education and practice. Those are’t “fixes” of the same kind at all.
Ah. Good point. The technical stuff is generally fixable; the non-technical stuff can be mitigated but not eliminated. We tell potential customers that problems such as change resistance are far more likely to present serious obstacles than any technical issues. Motivated writers can work through bad structure, bad tools, and lousy implementation. Unmotivated writers can break very nearly anything.