The guidelines for action itemized in this chapter were developed by CTG in collaboration with the XML Testbed teams based on findings from the project. Throughout this Testbed, it was found that in addition to the training and workshop framework, each of the teams needed to be supported differently based on four specific dimensions.

• Readiness, which is a team’s ability to act. Did the team have a shared vision? Did the team have a project lead who took responsibility for managing the work and expectations of the team? Did the team have the right members participating? Did they have representation from the appropriate areas? Did they have time to learn and experiment? Was the team knowledgeable about the work processes they were investigating?
• Confidence, which is the team’s collective expectation that they would be successful in achieving their goals. Did they have the executive support they needed to devote time and resources to the project? Did they have a champion to assist them in gaining the necessary support? Did they have an evangelist who would assist them in garnering the organizational support? Did they feel they had the skills required or a plan to acquire the skills necessary to complete their task?
• Communication, which is the team’s ability have open communication among its members as well as with its executive sponsor and champion. Did they have a communication plan? How were they going to keep their executive sponsor advised of their progress? How were they going to gauge or evaluate their progress?
• Knowledge, which includes the team’s technical, organizational, and political skills. Did the team have the specific knowledge set within the team? If not, did they have a plan for acquiring those skills or supplementing their knowledge with outside resources? Did they have the organizational knowledge or programmatic knowledge to understand the bigger picture of how this project fit into the larger organizational strategy or scheme?

These capability dimensions provide a framework for an organization when taking the recommended actions described in this chapter to help mitigate the barriers. Many of the recommendations apply to any innovation; some are specific to XML for Web site management. All of them are intended to help other organizations apply the lessons learned from the XML Testbed to their own environment in a practical manner. The final guideline in this chapter, “Use Comprehensive Prototyping within a Testbed Approach,” encompasses most of the findings of the XML Testbed project and serves as the major recommendation.

Unfortunately, XML for Web content management does not always provide the tangible results needed to easily demonstrate progress. Having a more effective and efficient workflow is not as flashy as a new widget or application. Each team needed to determine for themselves what they would need to provide their management to show progress. A technical staff member from a large agency explained how they used frequent meetings to maintain support: “We’ve always had our management’s backing for this ... We have meetings with our management and the different project areas [to continue this support].”

The teams also found the business case they developed as a part of the Testbed to be very helpful in this process. Each team also developed a communication plan that the project manager followed to keep executives informed of progress. In each of the agency teams that were part of this project, executive support shifted due to the nature of the world in which government operates. It was through this communication plan that they were able to maintain executive sponsorship and support, even when executive sponsorship changed. The business case and communication plan provided them with a consistent and effective way to provide new leadership with the information necessary to garner their support.

As stated earlier, reviewing the workflow processes that content follows from creation to Web will help identify bottlenecks, inefficiencies, and potential areas for improvement. As a Webmaster of a large agency mentioned, “We needed to fix what was broken first, and then make it a lot easier to succeed. Instead of just using the XML and putting all these fixes, just look for the problem in the first place. And not only will that help with [one] process; it’s going to help with many, many other projects along the way.”

Analyzing the workflow process identifies inter-organizational hand-offs and helps individual units see beyond their own boundaries. As one member of the Testbed stated, “I never knew exactly what happened once it left our office. I am amazed at the work they [the other unit] have to do with it once we think it is final.” This acknowledgment helps organizational units see all the parts in a larger picture. It also removes the emotional connection or ownership many have to the final product. Through this analysis, the individuals involved saw how their roles fit within the larger organization. This factor alone can help eliminate or reduce the number of turf conflicts and ownership issues that can and do occur.

In addition, it is an opportunity to reflect on the current processes and think about ways to improve them. A public information officer from a medium-sized agency clearly highlighted this opportunity: “Whenever you have an initiative like this and you’re starting a process, a new one, it forces you to reexamine where the old processes have developed faults or developed problems ... So it would be beneficial, because the agency as a whole would have to kind of undergo a self-examination ... So this would give us an excuse to take a closer look and see where improvements might be made.”

There are many different types of stakeholders to any process. However, not all stakeholders are created equal—they vary in power, legitimacy, and urgency. They each pull different weights. Regardless of this fact, each of them needs to be considered in your analysis. If your focus is too narrow, or you only focus on the most powerful stakeholders, other important stakeholders can and will be overlooked. One way to mitigate this is by considering the workflow process as a way to identify potential stakeholders.

Involvement of those stakeholders can then take many forms—from active engagement to keeping them informed of your progress. This not only helps to ensure a well-informed design, but also mitigates many of the barriers identified by Testbed team members, such as lack of understanding and cooperation among participating departments. A technical staff member working for a medium agency said, “So if you can get everyone, if you can get the right people in ... if you can sell them on what the concept is, we’re going to get support all the way through. And I think by doing that, obviously by identifying your stakeholders, having your stakeholders involved to the point where they’re very receptive to this move, it benefits everybody.”

Redesigning a Web site is a daunting task, not only for the technical team but for the program and executive staff as well. However, in its research, CTG has found that by breaking tasks down into actionable components and focusing a project on “doable” subsets, the overall objective becomes obtainable.

Each of the five Testbed teams found that by narrowing the focus of their initial project to one publication or one static content page, they were afforded the time and energy needed to learn and explore the possibilities of XML. Once they achieved this incremental step, they start thinking more globally. The smaller project provided them with valuable information to help guide a larger project. They were able to consider the changes necessary to the workflow process in order to accomplish this task.

• How does this information become transferable or scaleable for the larger endeavor?
• What are the training and support issues learned in the smaller project?
• What are the organizational changes that need to be addressed before moving forward with the larger more complicated project?

This approach also afforded them the opportunity to gain knowledge that can and will be applied to other projects. XML becomes a new “club in the bag or tool in the toolbox,” as one team member stated.

As stressed throughout this report, adopting and implementing XML for Web site management is not just a concern for the technical staff. All the individuals involved in the process need to understand how XML works and how it may change their individual processes and job functions. That is why training was more broad-based in the Testbed and not restricted to one topic, format, or group.

Without this broad-based training, key players may be left out of the process or not actively engaged in the activities surrounding workflow improvements. A shared understanding by all affected parties also helps to diminish the tendency for turf conflicts and communication problems. That is why the Testbed provided some level of technical XML training to all staff, not just the programmers, and required everyone to attend and participate in project management and business process analysis sessions. Everyone benefits when knowledge is shared.

As one program person stated, “I had not ever really been formally through a process like that. So for me, it helped me a lot. A business case was something I had heard of, but I really didn’t know the pieces that all went together to make a business case. So that to me, all the pieces, once they kind of jived in my head, they were all really useful. I did go to the one training for XML, only stayed like two-thirds of the day because, again, while I’m not a programmer I got enough to understand what they were trying to do but it certainly wasn’t my job to have to do that, so I didn’t have to be an expert in it, I just needed enough of an understanding to be able to contribute to the discussion that did impact me, which was the content development portion.”

Organizational readiness is a dimension that is often overlooked by analysts when they consider moving forward with an initiative, whether it is an IT initiative or an organizational change initiative. CTG has found through past projects and research that organizations must first assess and address their capability for change before attempting to enact a change, if they wish to succeed.

In the Testbed, CTG found that agencies with a strong IT technical staff needed to focus more on support for organizational change, since they already had the technical capability. On the other hand, agencies with limited technical staff needed to focus on obtaining IT support, since that was a critical first need.

During the Testbed, CTG was able to supplement the organizational readiness of the agencies with CTG staff—whether that was in IT knowledge and training, project management knowledge or support, or business analysis and organizational change support. In other situations, project sponsors need to consider their level of organizational readiness and make arrangements to obtain the necessary support—whether it was internal or external to the organization.

The need for open and constant communication forms an essential component of all the recommendations outlined here. However, communication is such a critical factor, it merits additional mention on its own.

Perhaps the most important and most often overlooked component of communication is listening. The XML Testbed project devoted a great deal of time and energy towards creating opportunities for individuals from different departments and organizations to listen to one another and to outside sources for help on improving processes and creating better products and services.

The message must be communicated in terms that the audience will understand and in ways that emphasize its benefits to them. Staff then need the confidence and tools to communicate their message through the rest of the organization so that the project succeeds. It cannot just be assumed that everyone will know what’s going on, why it’s important, and support it.

As one Testbed member summarized, “You really have to make those issues clear as to what it will do for the users on the other end, and then they’ll go along with you. I mean, as long as they know that it is a problem, they talk to the people and it’s confirmed, they’ll go along with this stuff. But you really need to explain to them what you’re doing for the users out there, and it makes it easier to get your point across and to get the projects raised in priority and get the manpower to do them.”

There will always be competing priorities in any organization or unit. The best way to accommodate this situation is to understand those priorities and communicate among each other to ensure effective decisions can be made for the entire organization. Competing interests often became shared goals when a broader understanding (beyond individual silo perspectives) is achieved. Ignoring the competing priorities or focusing only on one perspective more often leads to the turf conflicts and other barriers identified by the Testbed teams.

A Testbed member from a program area expressed the real advantages of addressing all the organizational priorities: “It opened up a good rapport [with the IT unit]. And I think that they see things from a different perspective on their end too, that it isn’t just about the technical end; it is about the content.” And a technical team member echoed that sentiment as well: “The willingness of people to examine those ideas and change their policies on that, is probably the number one hurdle for getting things done the cleanest, easiest way.”

Traditional prototypes provide programmers and program staff the ability to explore concepts and test assumptions. What prototypes and pilots do not provide is a way to look beyond the technical application to the social and organizational challenges. Expanding the traditional concept of prototyping to the comprehensive prototyping model within a Testbed approach allows for the exploration of technical, organizational, and policy implications.

In this project, comprehensive prototyping within the Testbed model enabled the teams to grow into the project by balancing capability with support. If a team had lower capability at the start (based on the four dimensions of readiness, confidence, communication, and knowledge outlined at the start of this chapter), they may have needed more outside support from CTG staff in the beginning. As they progressed through the Testbed and their capabilities increased, the need for support dropped off. The Testbed framework provided each team with additional support:

• through knowledge gained in training and the workshops;
• by alleviating project management responsibilities through the external framework of the Testbed model and the CTG teams; and
• by providing an environment where the teams could meet and work on their individual projects.

As seen throughout this report, a project such as implementing XML for Web site management impacts organizations, workflow processes, technical resources, and willingness to innovate. What at first may appear to be a purely technical task (XML) is seen on closer examination to involve much more. Due to this complexity, traditional training and system development approaches may not be sufficient to carry the project through to successful implementation.

The Testbed model, which can be implemented within a single agency, is specifically designed to fill the gaps left by the traditional methods and provide the additional levels of needed support. Training, for example, is delivered in the context of a specific product development or process improvement. More importantly, the training is delivered across organizational units and encompasses technical and business process areas (so-called “hard skills” and “soft skills”). Project teams are given time and support to apply what was learned in the training directly to the prototypes and business cases they develop. Executive support is procured at the start and nurtured throughout the process.

The Testbed teams provided the most convincing validation of the value of the approach, primarily in their prototypes and business cases, but also in their reflections on the process. Some saw value in the cross-organizational team makeup of the Testbed:

“A real benefit in just going through this entire exercise was the team. In a lot of ways, it was a real eye opener for [the other units] in terms of what we’ve got to go through ... what it takes for us to do this.”

Others stressed how the Testbed created the work environment that they needed to make their case: “[The Tested] certainly convinced me that technically it’s doable and technically it’s a great thing. We had suspected, but I wanted to actually prove that; I wanted proof of that theory.” That proof of concept enabled the teams to take the next step forward: “Without this project, I don’t think that we would’ve had the confidence to put a business case forward ... I think it gave us the confidence; it gave us the tools.”

The Testbed environment also allowed the teams to investigate all aspects of the innovation more thoroughly, “to look at the whole thing, to take it and break it down step by step” as one participant put it. The outcome, according to this person, was that “we changed a lot, we really did. We thought our problem was one thing and in reality it was something different.” Another participant saw benefits beyond this one project: “I think the business case development was a good exercise, not just for this particular focused area but for anything that’s coming down the road; those were good skills to learn.”

And even though the Testbed focused on a prototype development, not a full-fledged system implementation, that did not diminish the impact of the work. As one team member remarked, “I think we actually went above and beyond what we thought we were going to do ... And so just by looking at [the prototype] and just like seeing what we could do with it, I think it was just such a positive; it was just such a great feeling. And I think everybody on our team was really happy with it.” Or, as another said: “I’m always amazed in looking back at how much we did accomplish in such a short time.”