Any organization that has experienced change, knows that change can be difficult and met with resistance, doubly so when introducing an XML authoring environment. Who can blame the authors, really, when IT folks and executives start talking about "tag" this and "XSLT" that. The last words a busy technical publications department wants to hear are "new software." But some savvy members of the Irish government and some XML industry experts found a way to introduce workers to XML by talking less about tools and technologies and more about fixing what needed to be fixed in order to make their jobs easier.

Tom Kitt, Irish Government Minister of State accessing meeting documents through a Tablet PC. Because the documents are in XML, each minister can be given a personalized view of the content in the manner that is most relevant to them.

Each week, the 16 Departments of the Irish government submit legislative and other memoranda to the Prime Minister's Cabinet for inclusion in the upcoming Cabinet meeting agenda. It is mandatory that every government department officially review each memorandum submitted to determine how it affects the aspects of Irish life that the department oversees. This process requires extensive collaboration between the departments; including more than 1,000 document routings to individuals who may render opinions on the memoranda in preparation for each weekly Cabinet meeting.

In 2000, the Office of the Irish Prime Minister began researching how they might use internet technology and structured documents to join together all departments of government together in order to improve how the cabinet processes worked. They dubbed the project eCabinet, a fully-electronic, secure, collaborative knowledge sharing application that would support over 6,500 workers at all levels of the Irish government.

Addressing Challenges that Hinder all Content-laden Organizations

The challenges being addressed by the Irish Government were similar to those found in many other content-heavy organizations and they are directly relevant to technical writing teams of all sizes:

• Information silos hindered enterprise processes - The nature of 16 distinct departments and offices of government, each with their own legacy infrastructure and internally-designed business processes, posed a significant challenge for enterprise collaboration and information exchange. Silos made sharing knowledge between departments difficult.
  
  
• Information was trapped in word processing documents - While the use of word processing was ubiquitous among the departments, no single file format or version was universal. Even with the majority of departments standardizing on Microsoft Word, content was locked in .doc files with none of the data transparency available through XML.
  
  
• Occasional users needed to be able to participate without specialized skills - Although the system needed to serve thousands of users, many of them would engage in a Cabinet-oriented knowledge activity on a very occasional basis-for some, only once in a career. With any large system, usability is a key to success. When the system also has a large number of occasional users, a simple and intuitive authoring experience becomes the critical success factor.

After researching various solutions and performing rigorous technology trials the government selected In.vision Research, a US based developer of off-the-shelf XML content tools, to deploy eCabinet.

In.vision worked with the government to identify the challenges that might negatively impact project success. They learned as much as they could about the ways government workers performed their duties in hopes of avoiding solutions that might intensify problems rather than solve them.

Making the Change Less Scary

Business process change is risky, even when it carries huge potential benefits. The Irish government was aware that moving to XML authoring involved major technology and process changes, and that similar projects in the past had not always been met with success. Their solution for managing change was both simple and in some ways different-which might explain the overwhelming success of the project. Their approach covered both the design and the marketing of the system.

From a design standpoint, while addressing many enterprise issues, they recognized the importance of usability.

"In this industry, we have seen more projects fail due to usability (problems) than architecture," said lead project architect, Michael Boses. "As an industry, we almost always get the implementation of a content management framework right, but way too often fall short in making that framework usable for knowledge workers who need to create or review content."

Usability was measured not only with stakeholder feedback, but also with "the 4 hour test"; the entire system was to be accessible to department users after a 4 hour "familiarization session" as opposed to detailed training. As it turned out, the project team far surpassed this goal, and familiarization is now achieved with the web-based delivery of a brief tutorial. It's amazing and it works.

One reason the project was such a success is because the team identified one of the major obstacles: fear of learning new tools. They tackled this challenge by adopting XPress Author for Microsoft Word, a tool that provides XML authoring capabilities to authors using Word, without changing the familiar user interface or common feature set.

Eliminating Unnecessary Tasks and Jargon

Beyond usability, the project team focused on eliminating the tasks that knowledge workers most disliked, and focused on usability by finding software that allowed authors to create documents without being exposed to the complexity of XML.

Users could not help but like the fact that they were ensured their documents would conform with Cabinet regulations.

For example, preparing documents for the Cabinet is a complicated process, with extensive rules that are not intuitive to department workers. These rules have historically been spelled out in a Cabinet Handbook, and reconciling the rules with what a department worker actually needed to do was a daunting task for anyone who was collaborating on Cabinet documents on an occasional basis. The eCabinet project got rid of the rule book by incorporating the rules into the system and the XML definitions that controlled document creation. Users could not help but like the fact that they were ensured their documents would conform with Cabinet regulations.

Fear of the unknown can cripple an organization and its knowledge workers. Many an information technology project has failed due to a lack of attention paid to the challenges change can introduce. The project team also minimized the fear of change by using easy-to-understand language instead of industry-laden jargon.

"(So) we replaced jargon and technology buzz words with the word 'thing'."

Assistant Secretary of the Irish Government, Peter Ryan, explains: "To get buy-in," Ryan said, "we needed to focus on the improvements we were making in the process and not the new tools and technologies we were rolling out. Government workers don't need to understand the nuances of XML -- nor any other technology -- in order to do their jobs better. So, we replaced jargon and technology buzz words with the word 'thing'. And, when we explained the changes we were going to make, we took great pains to explain them using plain English."

Ryan's team and In.vision visited government workers in each of the ministries and offices impacted by the changes. They spoke to workers about the "things" that didn't work well, the "things" that needed to be fixed. They promoted the idea that this new "thing" (XML authoring) would make their work lives easier and allow them to get more "things" done with fewer resources. And, they promoted the idea that the "things" each worker hated about their jobs would be replaced with more efficient ways of working.

"It's a big, paradigm-shifting change," says performance and change management specialist Emma Hamer of Strategy A Consulting Group, a firm that specializes in helping content-heavy organizations improve their content creation, management, and delivery processes.

"XML authoring is scary to those who are accustomed to working in a document-centric world. XML authoring requires new ways of thinking," says Hamer. "And, new ways of thinking require changes to the way we do things today. While some folks love change, many are fearful of it."

In order to be successful, Hamer says, changes need to be introduced in ways that minimize the impact to those we're asking to change. To be really successful, Hamer says, an XML authoring project should also aim to create evangelists of key users in affected areas of the organization. And that's just what the Irish government did.

Learning From the Irish Government's Success

Technical documentation and training managers can learn a lot from the Irish Government's success. First of all, it's important to minimize change in situations where employees don't need to understand the underlying technology in order to perform their jobs. Most technical writers and training developers can be protected from the technical details by selecting authoring tools that allow them to concentrate on their core competency - creating content. This approach helps reduce fear of change and helps get buy-in from those on your staff who might otherwise balk at changes.

Second, it is equally important to adopt a "guided authoring" approach, again to provide authors with the tools they need to do the job without allowing them to get mired in the details. Software tools like XPress Author for MS Word that protect the users from the underlying XML technology, can also be programmed to provide visual cues and written instructions to users. Templates can be pre-populated with instructional content designed to help guide the authors to success, instead of relying on each author to figure out how to use a totally new authoring environment.

There is good reason to utilize these tools and address these issues in technical publication departments today; and it is not just for the short-term benefits. It will likely not be long before people in your organization who are outside of the technical publications department will be looking to you for guidance as XML authoring becomes an enterprise initiative.

DCLNews Editorial
December 2007