By Barry Schaeffer
Copyright Barry Schaeffer, 2005, all rights reserved
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
· Overlapping demand schedules and development windows
· Growing volume and variability of source data
· Legacy content, procedures, organizations and technology
· Requirements 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 contemplate 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. This increasing importance of human providers runs counter to traditional IT philosophies that see the computer system as the core resource with providers as an engineered system component. 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 remerging and toward the need for IT and text people to 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, however, this is
difficult to demonstrate at the beginning, and the beginning is where
impressions that will impact 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 rigor of the IT world. Regardless of fault, this detachment is the breeding ground for indignant howls from providers when many a new system is unveiled. Whatever their reasons, the content providers 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.
Given all of these potential potholes, how do you reach consensus and cooperation? It isn’t easy and it doesn’t respond well to window dressing, but it can be done. The following paragraphs suggest one approach that works.
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 the organization to accept a new way of thinking and a new set of tools with which to record that thought. The following thoughts may help.
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 often means XML, and XML means XML-based software. Word processors were not designed to capture the logic of thought separate 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 life cycles cannot be realized until the capture, management and delivery process is fully based on XML.
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.
Another unfortunate approach often taken by IT groups is based on the assumption that authors are just undisciplined and will respond when they are forced to. This approach often runs afoul of the fact that in many organizations, the authoring population has a bigger budget and more clout than IT when the chips are actually down. More than one IT-based authoring project has completed its work and much of its development only to be sent back to the drawing board by a recalcitrant authoring group whose management weren’t consulted until the new system was ready for installation.
Merely redoubling the effort to force XML authoring on recalcitrant SMEs and their management 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 in order to get the XML you need.
1. 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.
2. 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 via 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.
Once you have decided to move to XML-based processing, you will be dealing with the intense cultural issues described above. Here, standard IT development techniques won’t help you much and the veiled contempt for those flaky authors, present in many IT groups, will be an important negative. What often works best is a technique, drawn from manufacturing, known as Concurrent Engineering or 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. This 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 to the entire management team to guarantee the editorial groups that they will not face changes to which they do not subscribe.
Within the team, staffed by representatives from all groups, operations and technology, 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, etc.
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, 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, 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. This may be done through formal and informal means but it must be high of the Project Manager’s list of important goals. There are two reasons for this; 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 thoughts 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.
Conclusion: 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 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.
http://www.mne.psu.edu/lamancusa/html/ConcEng.htm
http://www.newproductdynamics.com/FldGd1998/FldGd1998.pdf