The Successful Adoption of Web-Based Collaborative Software (2005)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

PART 3: CONCLUSIONS AND BEST PRACTICES

57 CHAPTER 8 CONCLUSIONS AND BEST PRACTICES THE BENEFITS OF WEB-BASED COLLABORATIVE SOFTWARE All three cases experienced certain benefits from web-based collaborative software. All three were enthusiastic about these benefits even though the implementation is still new enough that the benefits are difficult to quantify. The software pro- vided the following: • Enhanced productivity. In Chicago, on the Douglas Blue Line Construction project, CTA senior technical personnel were able to process 260% as many RFIs per business day per person with the implementation of web-based collaborative software. At the PANYNJ, proj- ect managers were able to audit the expenses on their projects in a much more thorough and consistent way. At Raytheon, employees can work on a project 24/7 as it travels around the globe. • More accurate information to decision makers. All three organizations reported that although decisions may be made by the same people in the hierarchy as before, the web-based tools created an opportunity for more people to see the information and to give input about it to decision makers. We can assume this leads to higher- quality decisions and fewer unpleasant surprises. • Enhanced speed for information exchange. The CTA has been able to quantify that its RFIs are processed 20% faster with the web-based collaborative software. At the PANYNJ, RFIs have been processed 18% faster. These gains in speed translate to reduced delays in con- struction, which, in turn, translate into cost savings. • Role enhancement for project managers. In Chicago, people appreciated the opportunity to have input into many new decisions. At the PANYNJ, easier access to cost information has begun to turn project managers into able financial managers. • Enhanced accountability throughout the system. In a web-based system, everything is time and date stamped, and the whole system is transparent. Anyone looking in can see the status of an RFI or change order request and can see where the delays are. Initially, this trans- parency is what people are afraid of, but once the sys- tem is operating, they come around to appreciate the heightened accountability. This accountability is equally shared across workers, managers, and outside contractors. THE BARRIERS TO IMPLEMENTATION The three case study systems experienced different barri- ers to implementation of the web-based tools, including • Reluctance to give up paper and wet signatures, • Reluctance to locate data off-site, • Difficulty in agreeing on a single process to be followed, • Difficulty scanning documents and reading oversized documents that have been scanned on a regular-sized computer screen, • Difficulty supporting a web-based system with users who are not part of your own organization (e.g., contractors and subcontractors in the field), and • Reluctance to show work in progress to peers. BEST PRACTICES The following best practices were gleaned from the case studies: • Think carefully about what kind of implementation model will be successful for you. Table 1 in the sum- mary applies our nonlinear model to consider the differ- ences between two kinds of implementation, “Mandated Change” and “Opportunity to Change.” If widespread change must happen quickly and you choose to take a Mandated Change approach, then you must have com- mitted leadership at the top of the organization that is willing to force the terms of the change on others. You will also need adequate resources for excellent training and dedicated technical support. If you have the luxury of more time, you may be better off with the Opportu- nity to Change approach, which was exemplified by the PANYNJ and Raytheon. This approach encourages “pull” for the new ideas from within the organization. It, too, requires leadership, training, and technical support, but it relies on attraction rather than enforcement and can be highly successful at circumventing resistance.

58 • Notice where there may be opportunities to intro- duce collaborative software in the midst of other sys- tems initiatives. For example, when the PANYNJ saw many departments taking up new technology and the new intranet, the PANYNJ seized the opportunity to introduce collaborative software. • Think of technical support people as change agents who can advance your agenda. For example, in Chicago the KFA technical people would go to contractors’ offices to set up their computer systems and trouble- shoot. The presence and support of the KFA technical people served to strengthen the collaborative relation- ship between the CTA and its contractors. At the PANYNJ, the power users who were fully trained on P3e worked side by side to support the engineering depart- ment’s 120 project managers. These technical power users became powerful change agents in the system. • Don’t overcustomize the product. All of our case study organizations argue in favor of using an off-the-shelf technology initially and then tailoring the system more after the initial adoption phase. There are trade-offs between speed and customization. All three organiza- tions advise against engaging in a long, drawn out pro- cess of trying to get agreement on a customized product. Instead, they suggest using an off-the-shelf application to limit the input of users. Initial implementation of something that is “good enough” is preferable to a long process that may activate long-standing differences between groups. • Think creatively about process redesign. Sometimes an urgent deadline will enable you to do “good enough” process redesign before the new technology is imple- mented. Or sometimes the experience of working with the new technology in a pilot location will highlight problems in the system that you can address with a pro- cess change. • Use pilot experiences and early forays. These initial efforts will capture lessons learned about process rede- sign and about the technical challenges you will need to address. The PANYNJ’s lesson fits here: “experience is more important than analysis.” Pilots and early forays help you learn and improve the technical system and work processes, validate the benefits of taking up the new technology, and gain acceptance for the new technology. • Think carefully about your criteria for selecting a pilot site. Select a site with people who can be flexible and open to change and who have credibility in the orga- nization. The pilot experience must also have marketing value; therefore, you need to select a site where you are confident of success. Once the pilot is established suc- cessfully, these early adopters can help spread the word that the new technology is helpful. The pilot site partici- pants will therefore also need to be good “sales represen- tatives” for the new technology and communicate its ben- efits with enthusiasm to people who haven’t tried it yet. • Focus your implementation efforts on the middle managers in the organization. Both Raytheon and the PANYNJ believe that middle managers have the most power, the most work, and possibly the best perspective, linked as they are to the strategic view of the top exec- utives and the operational wisdom of the workers. Mid- dle management’s acceptance and feedback are crucial to success. • Don’t train every user on all aspects of the new tech- nology; instead, differentiate the training by role. CTA training represents a best practice; not only did the CTA differentiate the training by role, it also trained people on how to do their work with the new technol- ogy, rather than just training them on the software itself. The goal was to have every user using the tool in the same way. The PANYNJ used the same principle in a different way by thinking about what kinds of informa- tion workers with different roles would need to see in order to do their jobs. The PANYNJ gave workers with each role different levels of information and access accordingly. Information technology can fail because people are overwhelmed with data. By differentiating data for people and determining what people do and don’t need to see or know, you can help them to turn all the data into information that is relevant for them. • Keep training simple for the majority of users. In every site, we heard that initial training was kept as sim- ple as possible. Raytheon exemplifies this approach by choosing a web product that requires no training at all and can be learned with simple experimentation. Train- ing on Primavision for casual users at the PANYNJ takes 1 hour. At the CTA, the initial training is a little longer, but can be done online at a person’s convenience with a training CD-ROM. • Plan to offer a refresher training course after 3–6 months. Once people begin to actively use the new tool in their work, they will have a much better idea of what they need to know, and their questions will be more informed. If you retrain them at this point, they will become much more powerful users of the technology. • Don’t underestimate the technical challenge that may arise with the scanning of documents. This is often the weak link in the implementation of knowledge manage- ment systems and collaborative software systems. Either provide additional training around this feature, as the CTA did, or designate and train specialists to handle paper flow, as the PANYNJ did. • Align the evaluation, incentive, and compensation systems to support the adoption of new technology. This is particularly important if you are moving quickly with a Mandated Change model. At Raytheon, although it was not explicitly stated that managers needed to take

59 sions of the hierarchy. To be effective, these groups need to have clear purposes, clear authority for their work, clear deliverables that they are held accountable for producing within a clear time frame, a good base of face-to-face interaction before you ask the team to be effective online, and two to four face-to-face meetings each year to maintain the connection. • Make a long-term commitment to the technology to push through the initial resistance. The collaborative tools are so good and generally easy to use that if you stick with them for a year or two, even the people who resist in the beginning will be won over as converts. It will take time, so in order to succeed you need a long- term commitment to bringing the technology into the organization and adequate resources to support it. the Raytheon Six Sigma training, the message was clear: get on board with this effort to advance in your career at Raytheon. In Chicago, the commitment to ProjectNet was clear for contractors—getting on the system was a requirement of working on the capital program. • Recognize the problems of microcosm and tempo- rary groups. When you create a group that cuts across different organizations or departments, you create a microcosm group for the purpose of doing a particular piece of work. In the case of a construction project, this temporary system may last for years and become quite stable. Organizations create these groups for many good reasons—they facilitate knowledge sharing, they can come together to accomplish a particular piece of work, and they can be more creative than the traditional divi-