As with the benefits outlined in the previous chapter, the barriers and challenges described in this chapter were also identified by the Tested project teams through the process of developing their prototypes and business cases. CTG administered surveys and conducted personal interviews with all the participants to refine these findings into those categories which exhibited the highest level of consensus and impact. Some of the items that were perceived to be barriers at the start of the project actually turned out not to be barriers at all. The quotations used within the descriptions of the barriers and challenges are taken directly from the Testbed interviews.

Resistance to change is a common barrier to any initiative or innovation. Recognizing and addressing the issue through planning and communication can help to overcome it. Regarding the use of XML, all of the project teams saw individual and organizational resistance to change as a concern.

One program staff member summarized individual resistance to change as a “common problem in any organization. People don’t want change if what they’re currently doing is working, especially because what they’ve currently been doing has been no problem for them.” It’s important to recognize that certain individuals will resist change no matter what, so workarounds or accommodations may be necessary.

On the other hand, some individuals may find an incentive to change due to more efficient processes, better service and products, and less redundant work down the line. Since the changes will be felt throughout the entire organization, change has to be addressed across the organization, not just in the IT or Web unit. As a program staff member explained, you need to understand “how it will affect them [content developers] directly; if they can’t understand this, they are less likely to help implement it.”

Along with the resistance to change, the reluctance to abandon accepted technologies or procedures was also a common barrier. A technical staff member stated, “We’re changing the way we are doing business, so that’s a potential issue. We’re adding software that’s not part of the standard culture so in the infrastructure group, that’s going to be an issue.” If staff have grown accustomed to technologies and procedures that work for them (regardless of how inefficient they may appear to an impartial observer), it is difficult to convince them to change on a promise. Fortunately, because it’s a non-proprietary, open standard, XML does not present an either/or situation. It integrates well with existing technologies and procedures. At the same time, because of the efficiencies it brings to content management and Web workflow processes, XML can offer a strong alternative to accepted practices.

Redesigning a Web site can be a huge undertaking for an organization and involve far more people, areas, and resources than anticipated. One of the respondents explained, “One of the reasons I said before that we’re going to focus on three or four [documents] is the fact that’s manageable. If we tried to do every [document], we’d be in serious trouble. But I think we’re smart enough to know that. But we’d sure like this to work right out of the box and ... have something we can use. But that’s just not a realistic expectation. So managing the ambition, managing the resource, is going to be very important.”

Evaluating the appropriateness of goals is important for two reasons. First, goals that are too ambitious can negatively affect willingness to participate and support the project. A public information officer emphasizes this situation: “When I said that setting goals that are too ambitious, I think that’s kind of a no-brainer, at least for me, because once you do that, you set the bar too high. Then if you don’t meet it, everybody gets annoyed at you. There has to be a willingness; there has to be a buy-in by the people at the top.” By recognizing overly ambitious goals, public managers can scale back plans accordingly to mitigate unrealistic expectations. “I know we struggled,” said one Testbed member regarding this balance, “and I know a lot of the other agencies did too with just having bit off more than we could chew.”

Second, the ambitiousness of the goals should not be confused with the feasibility of the project. XML for Web site management offers good flexibility for scaling back projects to fit an organization’s capabilities, while still delivering benefits. For example, an organization may start a project planning to convert all 10,000 pages of its Web site to XML because of potential benefits. Then, management may see that it is too much to tackle based on available resources and expertise. So they can scale back to just convert the most popular publications and still derive the benefits of single-source and content consistency, while creating a model for future applications of XML. An IT manager of a medium agency explains how they set their goals to work on a more doable project at the beginning: “Instead of taking our Internet site, our public Web site, and making changes to that, we’re going to take our intranet site and convert that first into our content management package, and then convert it to XML, to use XML.” In the end, it can be a positive experience, as summarized by another agency participant: “We went off in the wrong direction a couple of times, but I think [it] was just part of the learning process.”

Many different departments are involved in Web content (e.g., individual business or program units, public information offices, IT, Web unit, etc.) and all these departments have their own priorities. As one liaison between the technical and program units stated, “There mainly is the sort of lack of one defining focus of where we want it to go and what we want it to look like. Everybody from different parts of the agency thinks that whatever they’re doing, it’s the most important thing and needs to be at the top of the page and flashing red letters instead of in an appropriate and logical spot. So they [Web team] deal a lot with the personalities and the priorities.”

In addition, different departments have different understandings of what’s important and the workflow processes involved. The Web unit, for example, may have a goal of getting out of the business of converting 20-page MS Word documents into 20 linked HTML files, while a program unit may have a goal of seeing their documents in different formats and on different devices. Therefore, it’s important to clarify overall goals to balance them among one another and with the overall organizational mission. It may even turn out that two departmental priorities that at first were seen to be in conflict are, on a closer look, supportive. To continue the previous example, XML may get the Web unit out of converting MS Word documents into HTML files by hand while also making these documents accessible in different formats and different devices.

An XML-based Web site may not eliminate departmental conflicts but it can help to align priorities by stressing the single-source content and demonstrating how everyone benefits from keeping the content consistent, timely, and accurate.

A lack of knowledge creates barriers on many levels especially when changes in technology have direct impacts throughout an organization. When looking to adopt and implement XML for Web site management, the following types of knowledge-related barriers are typically encountered.

• Program and service staff generally do not possess in-depth technical knowledge, nor should they be expected to possess this knowledge. However, this lack may hamper a clear understanding of how an unfamiliar technology such as XML can provide benefits, thus making an evaluation or acceptance of it difficult to achieve. They may not even be aware that a problem exists since workflows are isolated in organizational silos. As one Testbed participant from a program area remarked, “I frankly wasn’t sure what XML was ... I didn’t have a complete understanding of the difficulties that our technical people face in terms of putting changes out on the Web.”
• The pace of technology advances often exceeds our ability to keep up, which presents a two-fold problem. First, there can be a reluctance to adopt anything new or different for fear that it’s just a passing trend with no long-term benefit. Second, it feels safer to stick with what the technical staff already know. “Does everyone fear that XML is the latest flavor of the month—absolutely,” is how one technical staff member put it. Fortunately, XML has two advantages in this regard. One, since it’s not really a technology, but rather a text-based specification for formatting content, it can be learned relatively easily. Two, since XML is a non-proprietary, open standard, it is not expected to pass away or be superseded by future software versions. As that same technical staff member concluded regarding the flavor-of-the-month, “From everything that I know, it’s the contrary. XML is how everyone should be moving forward.”

This is a general organizational problem whereby different units or individuals have certain “turf” (programs, people, priorities) that they want to protect and that they may perceive as being threatened by other initiatives. A technical staff member recalled, “When I got here, I said, oh my god, why are you fighting over this? It’d be better to work together, but it just never was the culture to do that, and that’s changing a little bit now.” An IT manager from a medium agency explains, “Getting these people to come to any kind of mutual agreement is extremely difficult ... The different program areas perform extremely different functions with extremely different goals ... It had its fair share of political influences and so everyone is a chief and no one is really willing to compromise. “

Turf conflicts can threaten any innovation because they are not based on any reasonable ground that can be evaluated and argued. Stressing potential benefits may have no impact upon these turf loyalties. On the other hand, some negotiation may be necessary and useful to lessen the impact of the conflicts. At best, XML for Web site management can help to show commonalities throughout a work process and perhaps blur some of the hard and fast lines that lead to turf loyalty and conflicts. But these are still human relations and organizational issues that need to be addressed on their own to achieve the benefits from XML.

A Web site is one component in a publishing process. It may be the final step in the process, or it may direct activity throughout the process. It may provide an alternative form of publication or be the primary communication vehicle. It may be all of these and more. In any case, a lack of standards in the process creates barriers to successful implementation of XML. These barriers are seen in three key areas:

• workflow issues;
• technology that works against common standards; and
• technology that struggles against non-standards-based, proprietary software.

All three of these problem areas trace back to one root cause: the absence of a single source document at the center of the process that can be transformed into multiple publication formats as needed.

In regard to workflow, this lack of a single source document leads to “version control” issues and consistency problems as content is reformatted and manipulated in various steps along the way. Workflow procedures are instituted merely to monitor and check the changes that occur as content moves from one person to another and from one format to another along the chain. No value is added, but time and resources are spent. As one Testbed participant characterized it, “You have a lot of inefficiencies. You have a lot of time issues; you have a lot of checking that has to happen and the checking is just meant to ensure that we don’t have one version on the Web and another version in paper.”

Sometimes, technology is part of the problem, not the solution. Independent, proprietary formats for word processing, spreadsheets, print publishing, and Web pages do not necessarily work well together. What results is a proliferation of standards for the different formats, none of which co-exist easily. From another perspective, content management software attempts to consolidate these divergent formats and impose a uniform standard, but in doing so adds another layer in the process.

Because XML is a specification for defining content structure, it addresses these common publishing and communication standards at the root. The innate structure of XML-based documents lends them to procedures and standards that capitalize on this structure and streamline the publishing flow. Rather than multiple source documents in various formats, XML encourages and demands single-source documents in a standard format.

Initially, funding for Web site management was perceived to be a barrier by virtually all of the team members. However, after the initial workshops, the teams found this to be non-existent. As one program person stated, “I don’t think money really even becomes an issue with us for this thing, because it’s not going to require anything new. We’re not spending any money really of any significant amount on software or hardware or anything else. It’s really just a matter of people doing their job slightly differently and being more efficient at it.”

As another program person said, “I think that the benefits definitely should outweigh any kind of costs if you look at it in the long term. I think that it’s going to decrease the amount of staff time that’s needed to be putting these publications out to the Web site.” By the end of the Testbed project, funding was revealed as more of a perceived barrier than an actual one.

As with any organizational initiative, top executive support is needed to explore new areas and overcome organizational inertia. Despite perceived benefits, departmental enthusiasm, and convincing prototypes, if top management does not want a project to proceed, it will not proceed. In general terms, many of the reasons for lack of top executive support can be traced to the barriers previously itemized. Executive support will not be forthcoming if the concept has not been thoroughly examined before proceeding. Many projects can not even be explored without first demonstrating to executive management the anticipated return or benefit.

Recognizing the importance of executive support, CTG made it a threshold criterion for participation in the Testbed. Agency teams needed executive sign-off in their proposals just to be considered for inclusion in the project. Many of the participants stated that “participation in the Testbed provided them credibility to explore new concepts.” One of the findings from the initial training experience was that the trainees were unable to explore using XML within their agencies due to competing priorities. Participation in the Testbed gave them the mandate to experiment.

However, this barrier goes beyond experimentation. As many of the participants recognized throughout the Testbed, organizational change was the major barrier they faced. They needed executive support to require their organizations to change. A Webmaster remarked, “The big cost, so to speak, not that it would necessarily be financial or anything, would be getting those people on board and getting all the management at various levels to actually demand it, allowing us to say, no you need do it this way from now on.” As one technical staff member stated, “An XML for Web site and content management project, if properly executed, can obviate many of these concerns [resistance to change] by addressing them directly to the executive level.”

Many of the team members initially thought the process of converting to XML would be a long, arduous process. Many saw this as an “all or nothing” endeavor. The CTG XML team shared their experience with the team members in the first workshop explaining how they approached XML “one document at a time.” As the CTG Webmaster said, “We took one report and did our own prototype. We created the XML structure, which met all Section 508 accessibility standards, and found it to be a very easy conversion. Once we saw that much of our Web site was just a series of documents, the structure we employed in our test conversion could easily be applied to all of our publications and to the Web site as a whole.” He continues, “What we thought was going to be a major undertaking turned into a very easy conversion, allowing us to apply what we learned in our prototype to the whole Web site. Now we were not only compliant with accessibility standards, we knew we would never have to double check this again since it was controlled by one style sheet.”

Once the teams saw that they could approach their own Web sites one document at a time they began to see how it could be an incremental process. They did not need to tackle their whole Web site at once. They started to think of their Web sites not in Web pages, but in documents. As they classified what their Web site contained, they were able to look at the work differently. It was not as daunting as they first imagined. Again, a perceived barrier became less imposing as it was better understood.

Although XML is very popular in data exchange applications, it is not in prevalent use for Web site and content management. Many of the tools, training, and other infrastructure for this use are not in place. CTG’s XML Toolkit Web site at http://www.thexmltooklit.org was created as a result of the Testbed to address the need for XML tools, training, and guidelines. The problem, even for individuals and organizations convinced that XML is appropriate for their organization’s Web site management, is that they may have no idea how to implement it on a practical level in their environment. “It would be nice to know of other state agencies that have used XML in a similar way,” said one Testbed member.

This continues to be a problem, even though as XML usage grows, more resources are slowly appearing. Successful organizational experiences can, to a certain extent, mitigate this barrier. One of the respondents explained, “We’re pretty convinced that XML isn’t just the flavor of the month so I don’t think that’s an issue. And the fact that [another] system [in our organization] is built in XML and has been tremendously successful really mitigates that as an issue.”

Likewise, there is at this point a relatively small set of training offerings (online or classroom) that specifically address the use of XML for Web site and content management. Adequate training is always a major issue when implementing any organizational change, especially technical and cross-departmental changes. This absence continues to be a problem, although more training offerings are slowly appearing (both online and in classrooms) as XML usage grows. One program staff member explained, “As it stands right now, we have too many different areas doing different things. So it’s hard to train everybody on everything.”

This barrier identifies a top-down, authoritative approach to project management as opposed to an approach that involves a wider spectrum of affected participants using shared understanding and decision making.

The premise behind XML-based Web site management requires a process or workflow orientation that calls for a more collaborative, inclusive approach in project management style. Every unit that is involved in the process of moving content to the Web needs to be involved in the discussion. This approach results in a management style that cuts across departments; a strictly control-oriented approach to project management would alienate many of the primary stakeholders and threaten the success of the project.

While an XML-based approach to Web site management cannot in itself change or dictate a project management style, it does, by its cross-organizational look at workflow processes, provide an opportunity for participants and team members to look outside of their organization and understand how their work impacts others. In a more traditional project management approach, the focus will be on PERT charts and task lists rather than on understanding the impact a change may have on another organization upstream or downstream from the project. This all inclusive, more collaborative approach, which is in fact a requirement, will result in a more successful XML implementation.

Policy barriers, while initially perceived as being a potential barrier, proved to be one of the least imposing issues the team members faced. The New York State accessibility policy was the only major state policy that the Testbed agencies were required to comply with. They expected that changing to an XML format would actually assist with this compliance. As one program manager states, “Having the state policy has made it much easier for us, because we can say, look, it is not us—it’s NYS. So having the policy in writing has been very helpful.” Since XML can manage multiple output formats with far fewer files, it can also make it easier to “generate more accessible Web documents,” as one Testbed member remarked.