Note: In the Spring of 2007 I was invited to Dublin to learn how the government uses technology to create its laws and regulations, and to see, up-close-and-personal, how government ministers were able to move 6,500 civil servants from traditional document creation processes to structured XML authoring, something many of the most advanced technical publications departments have been unable (or unwilling) to do.
As organizations increasingly make the move to structured XML authoring, one might expect that tech publications departments—often overwhelmed with the need to produce more content with fewer resources—would lead the way. However, a 2005 survey by the consulting/software firm Information Mapping indicated an amazing 69% of respondent from technical publication departments had no plans to execute an XML strategy for content management. Those who were moving to XML cited regulatory requirements, improved documentation, and enterprise information architectural initiatives as drivers. In short, except for those respondents who were moving for improved documentation, technical publications departments were being pulled into structured XML authoring by regulators or the enterprise.
To allow things to take place this way is to lose a tremendous opportunity, not only to improve our technical documentation business processes, and return on investment, but also to take a leadership role in this important enterprise migration towards treating document content as a business asset, worthy of being efficiently managed.
What is interesting is that the same reasons given by survey respondents for not adopting XML, are the very challenges that organizations are overcoming as they adopt XML for non-technical documents:
- Insufficient XML talent pool
- Shortage of mature XML authoring tools
- Lack of stable standards
- Numerous customizations required to make software solutions work
- Reduced IT budgets
The number of enterprise XML authoring initiatives is growing and taking place across many industries as well as in the public sector. Let’s look at one example, from government, that overcame these challenges and delivered structured authoring to more than 6,500 people in less than one year.
Real World Example: The Irish Government Adopts XPress Author for MS Word
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 absolutely mandatory that every government department officially review each memorandum submitted to determine how the memorandum 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 (The Taoiseach) began researching how they might use internet technology and structured documents to join together all departments of government 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. 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 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 had not always met with success in the past. 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 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 a mandate that the entire system 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.
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.
For example, preparing documents for 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.
Managing Fear of Change
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 introduces. The project team also minimized the fear of change by using easy-to-understand language instead of industry-laden jargon.
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 Invision 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 Others
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.