 |
 |
 |
 |
| |
|||||
|
|
|
 Collaboration Technology Insertion Disruptive Technologies Challenge Conventional Wisdom By John Davidson Collaboration is key to building agile business processes. Over the last three years, a relatively small team working out of a Defense Department intelligence organization has built and maintained the largest online multimedia collaboration service in daily use by the United States Government. The service supports more than 3,000 users at over 50 sites around the world. This represents a tremendous success, and a significant challenge to conventional wisdom. Conventional wisdom would have one believe that successful technology insertion must follow six hypothetical guidelines:
None of the above guidelines proved entirely true in our experience. The Collaborative Virtual Workspace (CVW)-based virtual communities supported by the Community-Wide Enterprise Facility (CWEF) have become extremely valuable, and this article addresses several key reasons for their success. We offer these as lessons learned for others attempting to modernize a large organization's business practices using collaboration technologies. Guideline 1: The organization's culture must naturally support collaboration. Intelligence analysts have been trained to produce world-class technical intelligence products in a culture that rewards closely held ownership of information. The analytic work force is compartmentalized, with the rationale that the more segregated key aspects of a classified truth can be made, the less likely it will become known to those without the "need to know." Agency downsizing has led to the loss of senior analysts and managers, and to increased "outsourcing" and decentralization of many critical functions in the production process. There is a growing awareness that working smarter, not harder, means working together, and breaking the dependence on historical linear processes (stovepipes) in favor of a non-linear and more agile business model (see illustration above). Intelligence agencies respond daily to a wide range of national security and humanitarian crises in support of national decisionmakers. We knew that if we could support crisis operations, we could gain access to the most committed analysts/managers, and enlist their help in revolutionizing the agency's business. On balance, the community's culture of inward-looking analysis and secrecy worked against us, but we were able to leverage the agency's ability to rally in a crisis to our advantage. Once we experienced some real operational successes, we were able to keep up the momentum. Lesson Learned: All large organizations are feeling "market pressures" to react to a rapidly changing world, particularly the larger intelligence agencies. In such cultures, the need to change is a powerful ally in addressing substantive cultural barriers to collaboration, but you have to highlight the compelling business arguments supporting that change. In our case it was crisis support. Find the part of your enterprise that can leverage the technology to produce real results, and work there. Guideline 2: Exhaustive requirements analysis is needed to ensure success. While it is important to know what problem it is you are trying to solve with technology deployments, it is equally important not to lose sight of the ultimate goal. Because collaboration technologies are changing so rapidly, any effort at detailed requirements analysis will be quickly overcome by events. Offices insisting on having all the answers in such a dynamic environment end up endlessly studying the problem and never reaching the deployment stage. The CWEF sought to avoid this trap because we knew we lacked the knowledge and experience to make complete judgments, and that we could only gain such knowledge through experience. We decided to take a first step with CVW, which met the basic requirements. The CWEF deployed it, formed some communities, gained some operational successes, and revisiting the tool selection decision later as needed. One can fill out the capability matrices later after one knows what the specific capabilities mean to the success of the mission. In short, CVW was introduced not because of its innovative technology, but rather to try to break specific intelligence processing flow bottlenecks. This is a fundamental difference in approach. By maintaining our focus on the near-term intelligence mission, everything we did with collaboration became a mission support activity. We trained users using mission scenarios, we added mission-application mime-types into the collaboration document server, we co-opted mission support resources to support the system rollout, and most of all, we defended our work on the basis of potential (and then demonstrated) benefits to the operational mission. Lesson Learned: It's not the technology, or the process, but rather its application that is the key to success. Guideline 3: You need broad high-level management support. It's good when you can get it, but the nature of collaboration systems as a disruptive technology (The Innovator's Dilemma-When New Technologies Cause Great Firms to Fail, Clayton M. Christensen, Harvard Business School Press, Boston, MA, 1997) means that broad management support is probably unattainable early on. Instead, we prepared for broad opposition, and enlisted one senior manager willing to defend the effort at critical junctures. We worked with teams willing to risk change, and focused on building mission successes. We saw senior management become converts when presented with capabilities that made a difference. Early resistance to deploying collaboration technologies was overcome when it was realized that, out of all the software programs and networks supported, CVW was the only package in constant and urgent demand. To address fears of network impacts, we documented network loads with CVW use and found them to be minimal. We enlisted the support of the network engineering team so that our results would be viewed as unbiased. Lesson Learned: The root of most management opposition is fear. You have to overcome fear with documented test results, overwhelming customer demand, persistence, and a generous supply of "get out of jail free" cards from at least one senior manager. Guideline 4: The IT infrastructure must be accommodating. This is the one guideline we agree with. The agency's enterprise architecture was indeed well prepared for wide deployment of a collaboration application. The agency maintains a worldwide computing network; its users have high-quality desktop workstations, reliable networks, and they have become accustomed to this level of support. Without such an infrastructure, we would have been severely constrained. Even so, the network infrastructure was not prepared for the IP/Multicast protocol required by CVW for its streaming audio and video channels. We took particular care to create an IP/Multicast backbone, or MBONE , on top of the physical network layer, because we knew the network infrastructure support teams could easily stop the deployment effort if it was suspected that the collaboration system posed a threat to the stability of their extensive networks.
We overlaid the MBONE on the physical network topology to maximize performance and minimize impact on other applications. We spent months researching the physical networks, working with the network modernization teams and others to make sure our MBONE would not cause unnecessary network loading. In the end, we gained the trust and respect of the network engineers who are responsible for the health of the agency networks. Lesson Learned: The critical aspects of any collaboration system lie in its supporting network communications technologies. If you want to fit the system into your enterprise structure, get a good network engineer on your team from the beginning, and make your initiative fit the infrastructure. Guideline 5: Build it and they will come. This argues that standing up the capability is all one need do, and that once in service, it will draw users in. This couldn't be further from the truth. We had to build compelling business cases and publicize them to the work force through their peers in order to win over skeptics. This is organizational change in action, and it's painful. No organization changes on its own accord without a compelling reason to do so. Rather than deploying the capability widely, we made a conscious decision to be highly selective, working only with senior analysts and managers who knew they had a need for advanced collaboration capabilities, or had exhausted all other means at their disposal (secure phones, e-mail, newsgroups, IRC chat, etc.). They were willing to participate either because they had rare foresight or because they had a mission to perform that could not be supported by traditional means. This process became enshrined in the CWEF motto: "A desperate analyst is our best customer." Lesson Learned: Go where you are needed and leverage that need to gain operational momentum before you spread yourself too thinly. Wider is not better, at least in the early stages. Reaching critical mass can be slow, but is the only sure way to demonstrate a compelling business case. Guideline 6: You need a lot of money to deploy collaboration technologies. This was not our experience. We wish we had had the benefits of deep pockets, but instead had almost no money to spend. The CWEF is a very small facility, with a correspondingly small budget. It was established as a technology discovery and risk mitigation facility on the premise that if it failed, the damage would be small. If it succeeded, however, the potential payoff would be (and has been) immense. When we began this effort, we had no server, no virtual network, no client distribution facility, no headsets, microphones, video cards, or any other hardware supportive of desktop collaboration systems. We had to "liberate" the equipment. After our first pilot activity proved the concept while running on a small work group server, we noticed that one of the SUN Enterprise Servers at the agency was not yet assigned an operational support role. We made an unsolicited proposal to use this server as our home collaboration server, and in negotiations agreed to split its use with another service for a year. That was two years ago and we now control this server and apply it exclusively to CWEF initiatives. Having a large server with considerable excess capacity has enabled us to provide collaborative services to a growing audience without concern over computing resources. We needed hundreds of software router hosts for our virtual MBONE and we had no money with which to purchase them, so we liberated them. We found a cache of several hundred surplus Sparc IPX machines in the excess equipment warehouse. Because they had no remaining utility as user desktops, they were waiting to be decommissioned, but were perfectly suited as multicast routers. Lesson Learned: Sometimes you have to appropriate the needed resources in nontraditional ways. Summary Conventional technology transfer wisdom is written to address evolutionary technologies, which provide improvements to current business practices. These technologies do not generally pose threats to the culture or structure of large organizations. Disruptive technologies, on the other hand, offer previously unforeseen means of reforming an organization's business model, with concomitant changes to structure and culture. Collaborative systems are disruptive by their very nature, because their application forces a redefinition of existing business practices and the associated organizational structures and cultures that support them. This often means that those elements most committed to sustaining the current business model can be effective obstacles to the introduction of collaboration frameworks. In large organizations, it is the IT support elements that sometimes are most committed to the status quo, and surprisingly not the line organizations they support. Perhaps this is because IT elements do not themselves perform core mission functions and they can often miss the potential value that such disruptive technologies can provide. By starting small with a core of dedicated analytic leaders who do perform those core functions, we were able to achieve mission success without making a large financial investment. Building on that success, we were able to innovate, adapt, and appropriate resources, while clawing our way into the mainstream IT enterprise structure. Had we tried to get there any other way, the structure itself would have effectively blocked our progress. These lessons will be useful to other technology insertion efforts underway in similar settings within the Government, and that through their application, the national good can be served.
For more information, please contact John Davidson using the employee directory. |
Solutions That Make a Difference.® |
|
|
