Dealing with Input: A Critical Ingredient for Content Management Success

Home/Publications/Best Practices Newsletter/2006 – Best Practices Newsletter/Dealing with Input: A Critical Ingredient for Content Management Success


February 2006

Dealing with Input: A Critical Ingredient for Content Management Success

CIDMIconNewsletter Barry Schaeffer, X.Systems, Inc.

The near-explosive growth of technology has created unprecedented opportunities for improved information value. It has not, however, erased all of the challenges associated with achieving that value, in many cases actually upping the bar for acceptability of final output.

Even in our evolving technological world, we still face

  • limited funding, staff, and infrastructure.
  • increasing rate of technology obsolescence and required replacement.
  • demand schedules and development windows.
  • volume and variability of source data.
  • legacy content, procedures, organizations, and technology.
  • that cross organizational lines, requiring consensus.
  • uncontrolled (uncontrollable) input sources and providers.

None of these problems is more potentially vexing than the last, dealing with the sources of the content to be managed and delivered. With the rise of XML, a new set of problems has surfaced between those who provide information source materials and those who design, manage, and deliver them. XML allows us to anticipate information products that capture and deliver a dramatically higher percentage of what the author knows, delivering the resulting content in dramatic new information products. We are also facing the fact, however, that while technology can evolve exponentially, human information providers and the organizations within which they work cannot.

At its most valuable, it is usually human generated. The most valuable information in today’s world is that created by human subject matter experts (SMEs) through research, analysis, collaboration, and critical thinking. The increasing importance of human providers runs counter to traditional IT philosophies that see the computer system as the core resource with providers as engineered system components. Indeed, SMEs and IT staff often have little experience with one another because their paths to automation, servers, and office suites respectively, are often deployed and supported in different worlds. The rise of XML has moved these distinct fiefdoms toward mergers, requiring that IT and text people become reacquainted.

Most XML content is generated by existing human sources. Unlike business systems in which the data entry staff are hired to work with the computer systems, subject matter experts have usually been around for a while and often bring a different view of their responsibilities. If they happen to be highly skilled, highly paid, and not easily replaced, they may carry strong feelings about the extent to which they must mold to system requirements.

Human authors normally have a preferred tool. It sounds almost trivial, but when authors have worked in Word or Word Perfect or troff or whatever, getting them to change can be difficult and messy. This is especially true if the change involves both new software and a new way of organizing and recording their thoughts. Indeed, the cultural changes associated with situations like these can be downright gut-wrenching.

The system needs XML, but the authors need (and often demand) consistency and flexibility. Authors must perceive that the new system will provide them with an environment they can work with. If they do not, they will resist. Systems developers routinely believe that the new system will indeed improve conditions for everyone who deals with it, including the authors. While potentially true, the improvements may be difficult to demonstrate at the beginning, and the beginning is where impressions that will impact how the entire effort are formed. This “crisis of confidence” cannot be fully dealt with in technical terms.

System developers face a dilemma while the authors deal with an irritant. Authors are, and usually stay, focused on their intellectual duties, viewing the pending XML system as thunder over the horizon, a fact difficult for developers to fathom, steeped as they are in the XML and IT worlds. Regardless of fault, this detachment is the breeding ground for indignant howls from authors when many a new system is unveiled. Whatever their reasons, the content authors want to be part of the process and want a say in the outcome. Developers who ignore this often find themselves facing an implacable foe with more power in the boardroom. Projects finding themselves at this point are in real trouble.

Potential Approaches

Given all of these potential potholes, how do you reach consensus and cooperation? Reaching consensus and encouraging cooperation isn’t easy, and it doesn’t respond well to window dressing, but it can be done. Here are some suggested approaches that work.

Contrary to what one might expect, success in bringing your information life cycle into the XML sphere hasn’t all that much to do with technology. Indeed, technology is usually way ahead of what our organizations and procedures can deal with. Equally unintuitive, the truth is that success lies largely in getting people to accept a new way of thinking and a new set of tools with which to record that thinking. The following thoughts may help.

Goals—how XML content should be authored
All things being equal, it is arguable that the products of human thought, regardless of the subject, should be captured in the form most capable of expressing them. Today, this means XML, and XML means XML-based software. Word processors were not designed to capture the logic of thought separately from its appearance, aiming instead at creating a coherent visual impression so that the human reader may use the content productively.

While word processing to XML conversion can be useful as an interim solution, the full potential of many information-development processes cannot be realized until the capture, management, and delivery process is fully based on XML.

Challenges—more than meets the eye
To ask authors to accept new tools and new ways of organizing their thoughts is to change more than software and procedures. Confronting the resulting resistance, more than a few IT folks just forge ahead, assuming that everything will smooth out on its own. Often it does not, and the project can find itself facing an increasingly implacable foe in its own authoring population.

The reason for this miscalculation may be partially rooted in the fact that professional SMEs view their tools and procedures as fundamental parts of their working environment, even of their own thinking processes. Change tools or procedures in such an environment, and you are changing a person’s entire working life. Justified or not, the reaction is often immediate and negative.

Options—a light touch is critical
Merely redoubling the effort to force XML authoring on recalcitrant SMEs and their managers usually fails, often spectacularly.

Capitulating to the authors by taking anything they create, no matter how messy, often fails to meet even the most basic system goals.

So what’s left? Actually several paths are still open, but all require some changes in the authoring procedures to get the XML you need.

  • You can let them keep their word processing tools and give them a template to add some discipline to their capture process. This minimizes but does not avoid asking them to change, and it caps the level at which you can expect richly tagged XML from them.
  • You can ask them to use an XML editor in one of several technical architectures, local to their desktop via a web plug-in or a web-based session on your server. The salient point here is that they are giving up word processing for XML authoring, a painful step for most SMEs. This is not a simple process and it should be undertaken only under the right circumstances.

A Concurrent Engineering Approach

Once you have decided to move to XML authoring, you will be dealing with the intense cultural issues described above. In this case,

standard IT development techniques won’t help you much. What tends to work best is a technique, drawn from manufacturing, known as Concurrent Engineering (CE). CE is a philosophy designed to take all factors in the design and manufacturing of a new product into account. It was also designed to deal with the sometimes intense antagonism and distrust that historically existed between product designers and manufacturing engineers. While XML content is hardly the equivalent of toasters or Buick automobiles, it shares many cultural and human characteristics with these more tangible products and their human participants.

We will focus here on the two most important parts of CE as they relate to information design.

The Project Team
The space between the project development group and its authoring population can be a no-man’s land in which virtually every action is perceived by the other side as hostile and suspect. Unless you have faced the anger, distrust, and sheer venom of such a dysfunctional organization, it is difficult to fully comprehend its full fury. A key to these two groups working together is the establishment of a mutually acceptable buffer between them.

The Project Team, a major tenet of CE, provides this buffer and an effective communications vehicle as well. The team should be managed by a capable, trusted manager acceptable to both sides. The manager is important because the team will be asking both sides to do things that are counter-intuitive and thus likely to be suspect. To make the team and its activities acceptable to both sides, it should be given broad powers to investigate, evaluate, and recommend new approaches but should not be empowered to implement anything that will impact the operating groups. Implementation decisions are reserved for the entire management team to guarantee to the authors that they will not face changes to which they do not subscribe.

Within the team, staffed by representatives from all operations and technology groups, a series of appropriate task groups should be charged with the research, prototyping, and recommendations appropriate to their areas. The groups must work closely together so that the lessons learned by each are immediately infused into the others’ activities. This is important because the team will attempt to conduct as much of its component activities in parallel to shorten total time to completion. Typical task groups cover subjects like: composition, content modeling, content management, authoring support, technology evaluation and selection, and so on.

The Authoring Lab
The most critical question on most SMEs’ minds is, “What are they going to do to my workplace?” Indeed, improperly designed and configured, the impact of an XML content effort can be a nightmare for providers. They find themselves with more work, more complex requirements, tighter schedules, and tools that get in their way more than they help. If fear of such an impact gets loose in an authoring group, it spreads quickly, grows with each retelling, and provokes intense reactions. The Authoring Lab allows new authoring approaches and tools to be tested and evaluated by project developers and SME groups. The lab also helps to break down the fear present in many authoring groups that the IT people have only their own interests at heart and will not take authoring concerns seriously. Once SMEs see that developers will listen to their concerns and ideas and attempt to meet those concerns and adjust their tools if they miss the mark, the emotional level drops considerably and the SMEs become partners instead of resisters.

An effective authoring lab, working within the Project Team, can be the key point of engagement between the project and its intended providers. Carefully managed, it can literally develop the new XML authoring environment with the approval of everyone concerned. Having reached that point, the project is poised to take the critical step to full XML content creation and the many enhancements that will follow from it.

Project Operation
Once the project has been properly constituted and the Project Team assembled with its component task groups, the entire effort may proceed at a pace that everyone involved can support. It is important that however long it takes to complete the effort, no arbitrary deadlines are set. While there are a number of ways to speed up the project, setting unrealistic dates is not one of them. Indeed, working against a date that everyone knows is unreachable merely makes the entire effort seem futile.

As the effort proceeds, the Project Team must use every opportunity and vehicle to keep the operating groups apprised of its activities and decisions. The updates may be done formally or informally, but communications must be high on the Project Manager’s list of important goals. Providers will not support a project in which they are not a substantive part, and providers have much to contribute to the effort, once they come to believe that their contributions are accepted as valuable.

Everyone assigned to the project must fully understand the goals and should have a shared vision of their importance, including executive management, who will be called upon to pony up the funding when it is time to start buying software and hardware.


It has been said that if the people can agree, any tool will work, but if they cannot, no tool will work properly. Surely, this maxim applies to the information evolution on which we are now embarked. History reminds us that major cultural changes take time and are not accomplished without a certain level of pain. However, if we recognize and respect the critical role of information providers and if we take the actions necessary for them to participate fully in the process, that bright new information future we have been hearing about for the past half-century or so may have actually appeared on our horizon. CIDMIconNewsletter