National Academies Press: OpenBook

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

Chapter: Part 1 - Three Case Studies

« Previous: Chapter 1 - Introduction
Page 16
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 16
Page 17
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 17
Page 18
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 18
Page 19
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 19
Page 20
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 20
Page 21
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 21
Page 22
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 22
Page 23
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 23
Page 24
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 24
Page 25
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 25
Page 26
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 26
Page 27
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 27
Page 28
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 28
Page 29
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 29
Page 30
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 30
Page 31
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 31
Page 32
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 32
Page 33
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 33
Page 34
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 34
Page 35
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 35
Page 36
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 36
Page 37
Suggested Citation:"Part 1 - Three Case Studies." National Academies of Sciences, Engineering, and Medicine. 2005. The Successful Adoption of Web-Based Collaborative Software. Washington, DC: The National Academies Press. doi: 10.17226/23304.
×
Page 37

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 1: THREE CASE STUDIES

19 CHAPTER 2 CHICAGO TRANSIT AUTHORITY: MASTERING THE INTEGRATION OF DESIGN AND CONSTRUCTION OVERVIEW The CTA is the nation’s second largest transportation sys- tem. The bus and rapid-transit rail system serves Chicago and 40 surrounding suburbs. On the average weekday, 1.5 mil- lion riders travel 1,900 route miles and 289 miles of track. The CTA was created as a public body in 1945 as a result of chronic financial problems among private companies that had previously operated the transit service and had been con- tinuously in and out of bankruptcy. The CTA began opera- tions in 1947, but the majority of its physical infrastructure was built between 1892 and 1920. In 1971, the federal government began a program to fund the renewal of public mass transportation systems. The state of Illinois established a program to assist the CTA to meet requirements for nonfederal matching funds; finally, in 2000, federal and state funds for capital projects to shore up the CTA’s aging infrastructure became available. The deteriorat- ing infrastructure and slow trains needed major rehabilitation. As former CTA Executive Vice President of Construction, Engineering and Facilities, Jack Hartman, said of the Douglas Branch of the Blue Line, “If we didn’t do this, within a year or two we’d have to shut the whole line down.” The focus of the CTA’s capital improvement program (CIP) is to build and rehabilitate facilities to extend their life by four decades. According to Hartman, one of the CIP’s goals for achieving this was to “further the use of technology, particularly in the area of online communications, collaboration and project management.” With an initial capital improvement budget of $2.2 billion for the next 5 years, there was a massive influx of resources. The CIP was created under the direction of CTA President, Frank Kruesi, and Executive Vice President of Construction, Engineering and Facilities, Jack Hartman. In this chapter, quotations without attribution were taken from interviews with CTA employees or people who have worked with the CTA. UNDERSTAND THE IMPERATIVES: SPEED IS OF THE ESSENCE The $2.2 billion in transportation funding that the CTA received was far more than it had the internal resources to manage. The organization was not adequately staffed, and it did not possess the resources appropriate for the scale of the project. Because part of the annual funding came from the federal government, the CTA needed to use all of the fund- ing or risk nonrenewal of funding the following year. The CTA’s in-house professional construction and man- agement services were already extremely busy, and the scale of design and construction was about to explode—70 proj- ects ranging from less than $1 million up to approximately $500 million. To appropriately manage the CIP, the CTA needed to augment its staff. In 2000, the CTA hired a pro- gram management team composed of 13 firms and led by URS Construction Services. The program management team spent the first year with the CTA in an intense planning process, cul- minating in a program master plan. A matrix organization, the team of “insiders and outsiders” became so integrated at the CTA that the lines between owner, consultant, and subconsul- tant blurred significantly with respect to getting the job done. The CTA Board of Directors established four quantifiable goals for the CIP team: • 80% of the funds committed within 5 years, • Majority of benefits realized within 5 years (construc- tion underway), • Progress toward bringing the system to a state of good repair, and • Equitable distribution of benefits throughout the CTA service area. In addition to bringing additional resources to the agency, outsourcing program management enabled the CTA to speed up the acquisition of new information technology. The pro- gram managment team could move more quickly with its own procurement than CTA could with public procurement, allowing program managers to get things up and running for the CTA and themselves more quickly. The CTA wanted to achieve transparency to improve cred- ibility with funding authorities and the public at large. Tradi- tionally, integrating the Project Management Oversight Con- tractors (PMOCs) into the project had been problematic, especially when the PMOCs were geographically dispersed. At the CTA, the PMOC team was trained on the web-based

project management system so that team members could have access to all capital information from anywhere in the coun- try via the Internet. Additionally, the CTA was committed to achieving ISO 9001:2000 quality registration, which required • Correct versions of controlled documents available in a single location, • Prevention of unintended use of obsolete controlled documents, • Maintenance of records providing conformity to quality requirements, and • Legible records that were readily identifiable and retrievable. WHAT KIND OF PROJECT MANAGEMENT TOOL DO WE NEED? Jack Hartman, the former CTA Executive Vice President of Construction, Engineering and Facilities, pushed for a web- based approach to project management. He strongly believed that this web-based, collaborative approach would be neces- sary if the CTA were to manage its capital projects success- fully. Hartman kept informed of emerging technology and explored web-based project management tools. In the end, this led him to require the program manager to implement a web-based project management system for the CIP. URS selected Kristine Fallon Associates, Inc. (KFA), to join the program management team and charged KFA with the selec- tion of a web-based system as well as with implementation of the system and ongoing training and support for it and all of its users. 20 The Importance of Design KFA spent its first two months performing a CTA needs analysis. As Kristine Fallon stated, it is “important to really understand the source applications and classic problems in communications and look for products that can solve them.” The project management team quickly realized that it needed a tool that could support both design and construction phase business processes equally. In an interview, Kristine Fallon explained why it was so important to include design in the solution: Design quality controls your construction costs. While the construction phase is where the lion’s share of the total project costs are expended, poorly coordinated design drawings are what lead to contract change orders and additional expense in the construction phase. KFA likened the cost structure to a “creeping slope”— illustrated in Figure 2. As the design phase moves into con- struction, the project costs increase but the ability to control them decreases. Therefore, you want to identify problems as early in the process as possible, where your ability to influence them is still high. If there is poor coordination in the design phase, the cost will escalate during construction. Thus, the system selected had to have strong design phase communication, collaboration, and document management capabilities, with the same capabilities for the construction phase plus the automation of construction phase business processes. The system would also need to meet three key goals as defined by KFA. The goals came to be known as “the three A’s”: Figure 2. Ability to influence construction cost over time.a aHendrickson, C. “Project Management for Construction: Fundamental Concepts for Owners, Engineers, Architects, and Builders.” PA: Carnegie Mellon University, 1998. http://www.ce.cmu.edu/pmbook/

• Access. Project information is accessible to authorized project team members from virtually anywhere with a personal computer, browser, and Internet connectivity. • Accountability. The system tracks who is responsible for what task and when the task is due or overdue. • Audit trail. The system logs who did what and when they did it. Choosing an Application Service Provider KFA believes that “If it’s not part of your core business, don’t do it.” KFA recommended Cephren, Inc. (which later merged with Bidcom, Inc., to form Citadon, Inc.), based in San Francisco, because Cephren had a track record with large construction projects and because its web-based project man- agement system, ProjectNet, supported design phase docu- ment management as well as the construction phase document and business process management. Citadon is an application service provider (ASP). ASPs provide access to software that is hosted remotely and that is accessed by the customer via the Internet. Customers pay a subscription fee for the use of the software. Benefits to using an ASP are as follows: • Reduced cost. Since the ASP provides hosting, data storage, backup, and disaster recovery for the system, no expensive on-site management information systems (MIS) staff needs to be hired by the customers. Also, the customers only pay for the capacity they use as they use it. In-house systems must be sized to accommodate esti- mated future needs. • Unlimited users. Citadon’s licensing scheme for Project- Net allows for unlimited users. The CTA pays only for active projects on a project-by-project basis and for addi- tional storage if needed. KFA believes that a license that allows an unlimited number of users to access the sys- tem is preferable to licensing schemes that charge “per user” (or per number of users). Limiting the number of users who can access the system vitiates the system’s effectiveness. • Product updates. The ASP pushes software to the user via the Internet, allowing software product updates to occur transparently. KFA believes that this is particu- larly beneficial to large companies and public agencies where deployment of software updates by internal MIS staff can be problematic and costly. • Scaleability. An ASP provides capacity on demand. The customer does not need to worry about accurately pro- jecting needs or planning procurements. • Redundancy, backup, and disaster recovery. All ser- vices are provided by the ASP. The customer does not need to procure, configure, support, or maintain the system. 21 • High reliability. ASPs provide high levels of system availability. As Jack Hartman said, “Since Citadon uses Exodus [the Internet data service company that is now Cable & Wireless], the same Internet data facility that MasterCard, Sun Microsystems, MSN and American Airlines uses, it wasn’t hard for me to convince our staff about the reliability and security of such a service.”i Some people are wary of ASPs because ASPs are not plat- form independent, but most web-based project management systems are not platform independent, either, requiring a Win- dows desktop. In addition, KFA believes that in-house systems are more expensive to support and maintain than ASPs are. UNDERSTAND THE RESOURCES: COST VERSUS BENEFIT KFA believes that it is important to tie the cost of the ASP solution to the program’s overall value. For example, the cost of using ProjectNet over the 5-year life of the CIP was approx- imately 0.1% of total construction costs—roughly the cost of hiring a single senior-level manager for the 5 years. ProjectNet allowed for some customization of the business process, but customization was limited. ProjectNet function- ality was based on best practices for design and construction and was thus a more “out of the box” approach. Though some- what limiting, the implementation team saw value in this “out of the box” approach because it would save time in imple- menting the system. System implementation takes more time the more complex the product is and the more customization it allows. A high degree of product customization also is more likely to result in more errors and miscommunication of requirements. A good “out of the box” solution contributes to a good system implementation, allowing everyone to benefit from the technology more quickly. Citadon’s next-generation tool—Citadon CW (Collaboration Workspaces) allows for much greater business process customization. ProjectNet works both like an electronic file cabinet and like a series of logs that allows team members real-time access to project information—from design drawings and bid documents to requests for information (RFIs) and submittal packages. ProjectNet allows the ability to search, sort, and filter project information based on the user’s preference. For example, one team member may want to view all open RFIs, while another may want to view only open RFIs that are over- due, while yet another may want to view only RFIs that per- tain to a specific section. Having all project information orga- nized in one place allows project participants to collaborate in their own styles based on their roles on the project. i Cyon Research Corporation. “Cyon Research Study Analyzes Web-Based Project Management Implementation at Major Transportation Agency.” 2002. http://www. cyonresearch.com/press/?20020826.

WHAT KIND OF IMPLEMENTATION IS SUITABLE? At the CTA, time was of the essence because the agency needed to move aggressively forward with its CIP, which was orders of magnitude larger than anything the CTA had attempted in the past. The CTA did not have the option to consider a more gradual, incremental implementation of the new technology. Under these circumstances, the implemen- tation and transition to ProjectNet needed to happen quickly and comprehensively. Therefore, compliance with its use needed to be mandated from top-level management and rig- orously enforced. The CTA requires every company with a CTA contract to use its web-based project management system. “In terms of propagation of system use, having the owner in control is very helpful. We can and do require everyone—construction managers, general contractors, and designers—to use the system. Without access, you are off the project.”ii Today, ProjectNet has over 800 users (nearly 900 users trained) from approximately 90 organizations for over 50 dif- ferent projects. Two key facts proved important for success- ful implementation: (1) that top management was fully behind the implementation of the web-based project management system and the enforcement of its use and (2) that the imple- mentation team understood the CTA’s business processes and procedures. The project management team, particularly KFA, under- stood the importance of a good product roll-out for the suc- cessful adoption of the new system. Meetings were hosted by top-level CTA and program management personnel for all Construction, Engineering, and Facilities Department employ- ees. The meetings stressed the importance of adopting the new way of working toward realizing the CTA’s goals—fail- ure was not an option. Within 4 months of procurement of Citadon’s services, the project management team had its first construction phase proj- ect website up and running—the Douglas Blue Line Recon- struction Project, one of the largest capital projects in the pro- gram. ProjectNet was next used for the design phase of the Ravenswood Brown Line project and is currently being used on the Dan Ryan Red Line Reconstruction project. It took the CTA about 2 years to fully adopt the technology as part of its culture. During this time, many CTA procedures that were not clearly defined before ProjectNet was implemented were re-evaluated and revised to incorporate the way the web-based system was being used. EXPLORE WITH PROBES AND PILOTS: PROCESS REDESIGN KFA clearly understood the importance of streamlining procedures at the outset of system implementation and then 22 automating them using the system’s features and functional- ity. KFA found that although this technology might not trans- form a process itself, it could aid in streamlining the process workflow. Concurrent with the implementation effort of ProjectNet, the CTA engaged in a commitment to achieve ISO 9001 quality registration for their Construction, Engineering, and Facilities Departments. This commitment required docu- mentation of all CTA and CIP management procedures. How- ever, the ProjectNet implementation was on a much faster timetable. To understand how procedures would need to change with the adoption of the new system, KFA planned to understand the CTA’s current procedures, document them, and then adapt them to indicate how ProjectNet should be used to support these procedures. KFA went through each defined business procedure, met with key stakeholders, and solicited feedback until all were in agreement on how the process should work on ProjectNet. In cases where procedures were ill defined or nonexistent, KFA took the lead in meeting with stakeholders to define them. Having key stakeholders involved in defining the process resulted in stakeholders buying into using the new tool the way it was meant to be used. The Website Imple- mentation Team then wrote detailed work instructions on exactly how team members were required to use ProjectNet to do their work. These instructions became the ProjectNet Web-Based Project Management User Manual, the basis for training. According to Kristine Fallon, “If you introduce a new tool and don’t show people how to get their jobs done, they’ll each use it in a different way.” However, key stakeholders could not agree upon all ill- defined or nonexistent procedures. The more complex proce- dures, typically requiring contract changes and the routing of paper for multiple hand-written, or “wet,” signature approvals, rather than electronic signature approvals, were not readily adaptable to the ProjectNet environment. These types of work- flow processes have tended to remain in hard copy and off- line. When documentation has been finalized, it is scanned and uploaded to the project website for record. Thus, the access, accountability, and auditability that ProjectNet pro- vides are lost on these business processes. Mike Poynton, program management’s website manager (and employee of KFA), stated the following in an interview: While trying to document a business process, such as who may create a proceed order, to whom it may be forwarded for review, and by whom the proceed order is closed, I met with several key stakeholders, all of whom gave me a different story. There would be 10 of us in the room, I would diagram the process and someone would say “No, that’s not the way we do it!” Consequently, we went through three revisions of the ProjectNet User Manual. It took us months to create, review and revise flow diagrams of the many CTA proce- dures . . . it was extremely tedious, time consuming and frus- trating. Eventually we were faced with the imminent notice to proceed with the construction phase of the Douglas Blue Line Reconstruction project. Some procedures were still inii Ibid.

flux—we punted on getting procedures approved and went on our instinct and professional experience so that we could get the project up and online. Some things changed dramatically at the CTA as a result of the implementation of the web-based technology, but many others did not. While RFIs and submittals were being resolved and processed more quickly and efficiently, the processes themselves were nothing new. “We didn’t invent new pro- cesses for submittal and RFI reviews . . . we’re building things the way we built them 100 years ago—the only difference is that the information is being routed and exchanged on a web- site via the Internet.” It should also be noted that the system has not fundamen- tally changed the approval hierarchy that was in place before it was implemented. “The people who have the final say still have the final say. The hierarchy is the same. You might have 10 people making public comments on an RFI, and in that sense it’s more democratic, but the final resolution is still made by the boss.” UNDERSTAND THE RESOURCES: ROLE-BASED TRAINING Training was tailored to the team member’s role on the project and was focused on the process rather than on the technology. The staff was trained on how to do their own jobs using ProjectNet, rather than on how to use all of its fea- tures. The philosophy behind this approach was to help peo- ple to recognize that ProjectNet was a different tool for them to use to get the same job done, but more quickly and effi- ciently with less miscommunication. KFA offered initial train- ing tailored to various design and construction phase project roles. For instance, there were classes targeted toward design architects and engineers, construction managers and general contractors, subcontractors, oversight agencies, contract com- pliance, and so forth. Training focused on using ProjectNet as it pertained to each person’s roles and responsibilities on the project. Introduction to ProjectNet training is offered both as a hands-on course and as a computer-based training course on CD-ROM. The computer-based training, which is preferred over the hands-on course, can be completed at the trainee’s pace and on his or her own time, taking approximately 3 to 4 hours. The CD-ROM includes quizzes that trainees must complete for each chapter. Upon completion of the introduc- tion course, trainees are invited to complete an advanced, role-based class, as described above. In the initial 2 years of ProjectNet’s implementation, KFA recognized a need for more follow-up and refresher training because people didn’t always absorb all of the information the first time. Produc- tivity refresher training is available on a regular basis, con- centrating on the most frequently asked questions regarding the use of ProjectNet. A class on document scanning is also offered. 23 Though it took a while for people to stop relying so much on paper copies, users attested to the fact that the more they used ProjectNet, the easier it became to do their jobs, as par- ticipants gradually realized that the benefits of using the sys- tem far outweighed the drawbacks of having to change. As one of the Brown Line design engineers put it, “What’s dif- ferent now is you don’t live and die by the fax machine. I haven’t used a fax machine for 3 years.” Even people who had never used email adjusted because of the existence of excellent training and support and because of top-level man- agement’s commitment to this way of doing work. UNDERSTAND THE RESOURCES: WHAT’S MISSING AT CTA? Though the CTA Construction, Engineering, and Facili- ties Departments have largely adopted web-based project management, the CTA has not been able to integrate the tool throughout the entire organization. Some departments still cling to wet-signature approvals and a paper-based sys- tem. This is especially true of the Field Memo, Proceed Order, and Change Order processes for which no CTA or pro- gram management procedures exist. The ProjectNet “Issues” module, however, is being used in parallel with the paper process by the construction manager to track the progress of wet-signature approvals, with some success. Any busi- ness process that directly affects the project budget is still very slow because of the wet-signature approval paper pro- cess associated with contract changes, which does not com- pletely leverage ProjectNet’s accountability and auditability. Business processes involving wet signatures rather than elec- tronic approvals are typically offline processes that, once completed, are documented on paper, scanned, and uploaded to the project website. SOCIAL RESISTANCE TO CHANGE The implementation process was not easy. The project man- agement team faced some information technology issues, a tight schedule, and resistance to adopting ProjectNet; the team learned a great deal about both technology barriers and corporate culture’s resistance to change. Technical Challenges: Internet Access The CTA’s commitment to giving all CTA users access to the system meant that the CTA needed to commit to giving almost everyone Internet access from his or her desktop. The CTA had traditionally resisted giving all CTA employees Internet access. The program manager had to push the CTA hard to give users email accounts and Internet access so that they could access their project websites and communicate with each other.

Additionally, the issue of getting contractors and subcon- tractors online to use the system became problematic. Kristine Fallon said, A contractor comes in and sets up an office near the con- struction site and chooses a place where they can park trucks, not a place with great Internet connectivity options. We had to bring in T-1 lines . . . contractors are about caring for their trucks, not caring for their PCs . . . we had to make sure that everyone had the right technology and make sure that hard- ware and software requirements got written into contracts so that general contractors and construction managers were clear on exactly what they needed to use ProjectNet. Technical Challenges: Scanning Documents The reality of design and construction is that each phase still heavily relies on paper documents, regardless of whether team members use an electronic, web-based system. Because paper cannot be uploaded to a website, anything that was not created electronically in the first place needs to be scanned and uploaded to the project website. Document scanning proved to be a larger problem than expected. It was discovered rather quickly that people did not know how to scan documents properly, nor did they know what kind of scanner was appropriate for professional document scanning. People were scanning black and white documents on $150 flatbed scanners, one page at a time, at 800 dpi in full color, resulting in wasted staff hours and enormous file sizes (8 MB per page rather than 35 KB per page). This man- ifested itself in user frustration at long upload times for cre- ators of the files and long download and view times for the other project participants who were trying to access the uploaded information via the project website. To address this issue, KFA created a “How to Scan” training course that went over scanner settings and offered recommendations on what types of professional document scanners were best suited for the type of work being done. Subsequently, recommendations for document scanners were included in both the ProjectNet User Manual appendix and contract documents so that designers, general contractors, and construction managers could budget for the equipment and get started quickly after their notice to proceed. Recom- mendations for the outsourcing of scanning—especially for large-format scanning—were also included in the training curricula. Social Challenges: Adequate Support The CTA acknowledges that this system requires dedi- cated support and excellent in-house training resources to function smoothly. As one user put it, Managing the website is a full-time job for a full department. Without our three people who make up the Website Imple- mentation Team, it would be chaos, impossible. You need to 24 have your website management available. How does it change the way contractors do things? The CTA has dedicated web guys, and the contractor has dedicated web people, but our web guys function de facto as the contractors’ web guys, too. They’ve never gone out to the Blue Line contractors’ office and found a computer properly configured yet. Social Challenges: Resistance Psychological and cultural barriers to the adoption of web- based project management were also evident. Initially, CTA personnel resisted the ASP concept of having electronic data hosted on servers physically located outside of the offices of the CTA, rather than on servers located within the walls of the CTA. To counter this obstacle, KFA had to educate these people and prove to them that, in fact, it was better for the websites to be hosted by the ASP because redundancy, backup, and disaster recovery for the system were provided by the ASP. Additionally, support of the ASP approach by the executive vice president sent a message to concerned employees that the executive vice president trusted the sys- tem and that this was the way the CTA would manage all of its design and construction projects in the future. The contractor work philosophy also affected the initial adoption of the system. As one contractor said, “construction folks would rather build a computer than use one.” For the general contractors, the initial training seemed overwhelm- ing. The CTA contractors talked about the initial attraction of ProjectNet for all that it professed to do, but it quickly faced two key “panic” issues. First, even though the hard- ware and software requirements and the scanner recommen- dations were written into the contract documents, the CTA contractors had not budgeted properly for the requirement that they use the web-based project management system. Second, contractors generally admit, with good humor, that they are not technologically savvy. Even though the contrac- tors understood the CTA requirement to use the web-based system, they admitted that for the first project, they didn’t quite understand the challenges of using the system. This barrier is common with initial roll-outs. The subsequent proj- ects have shown greater success because general contrac- tors gain experience and the Website Implementation Team implements solutions to problems that arise. However, in the CTA case, the executive vice president and program management enforced the discipline from the top down. The executive vice president showed that the CTA was serious about change and that people needed to conquer psy- chological, cultural, and technology barriers. For example, a 50+ year old field superintendent who had never used a computer or mouse was trained and not only learned the system, but became one of its most enthusiastic and fre- quent users. Initially, people resisted the much higher level of account- ability that the new system provided. With ProjectNet, it is easy to see (or for others to see) how many RFIs a team mem-

ber has opened and how quickly RFIs or issues are dealt with. This gives the organization valuable metrics for measuring productivity. It also makes the system transparent. For exam- ple, the president of the CTA, Frank Kruesi, wanted to be trained on the system. While the trainer was with him in his office, they went through an RFI example. Looking into the system, the president chose an RFI that had been created that day and that had been commented on and resolved within 2 hours. He was able to see what every person who “touched” the RFI did and when they did it. Having seen the results of the system on his desktop computer, he became convinced of its power. With time, however, team members began to real- ize that the accountability had benefits for them, too, because the system not only allowed others to see what they were doing, but it allowed them to keep track of what others were doing, making accountability a two-way street. As one Brown Line architect described it, “People like being able to eavesdrop on other people’s work—it’s a peer pressure, self-policing environment—improving quality and responsiveness. Every- one can see what everyone is doing and they’re talking about it. It’s like living in a small town.” Technically, subcontractors to the general contractor are not required to use the web-based project management sys- tem because there is no contract between the subcontractor and the CTA. However, the KFA approach to implementa- tion was to provide benefits to all project participants using the system. Therefore, KFA created a subcontractor training curriculum and special areas on project websites where the general contractor and some of its subcontractors adopted the system immediately. Some contractors—particularly the small shops—did not use the system at all. Not having every single subcontractor on the system has not appeared to adversely affect the construction phase because the general contractor is responsible for coordinating its subcontractors regardless of whether they use the web-based project management system. There will always be people who resist training and adop- tion of new technologies. For example, while the majority of the construction manager’s team uses ProjectNet, some team members still go back to using the fax machine. Doing so may cause miscommunications because the communication is not happening within the web-based system where all the other team members are communicating and collaborating. EVALUATION: THE DOLLAR VALUE OF SPEED Early in the construction phase of the Douglas Blue Line Reconstruction project, the program manager sponsored a partnering meeting with the project’s key stakeholders. One of the mandates that came out of that meeting was to imple- ment a web-based project management system. Not all par- ticipants initially supported the mandate. Although there were cynics, most participants believed that the partnering meeting really helped the contractors embrace 25 ProjectNet more fully as they realized that the tool could aid in reducing construction claims later. The first construction project that used ProjectNet—the Douglas Blue Line Recon- struction project—is still under construction, and it will be another year before the CTA can test whether the system accountability and auditability functionality will help the CTA minimize contractor claims. Additionally, many contractors and construction managers believe that the higher quality of easily retrievable informa- tion available to them on the project website and the speed at which the information, such as an RFI, is processed will result in fewer misunderstandings and contract change orders. Socially, having the Website Implementation Team person- nel in the contractors’ offices to support them may also help to create an ongoing collaborative relationship. Thus, part- nering meetings become the point of departure for a rela- tionship that is constantly being reinforced. Benefits from web-based project management tools are not easily measured because they are not necessarily quan- tifiable. Many of the benefits, such as providing designers and contractors with both a central clearinghouse on a web- site and immediate access to more information than they would typically have otherwise, are difficult to measure in dollar savings. By 2002, 699 users from 65 companies had been trained and were using ProjectNet. Before the end of the 5-year con- tract, KFA expects the number of trained users to increase to 2,000. KFA believes that speed and quality drive cost savings. ProjectNet focuses on quality and efficiency, which in turn help to control costs. As stated previously, mistakes made during the design phase of a project will adversely affect the construction phase of the project, resulting in costly change orders. With web-based project management systems, the entire project team has ready access to project data. Survey feedback from users indicates that access to information is the greatest benefit provided by the system. Increased Speed and Productivity The Website Implementation Team could report on a cou- ple of ProjectNet modules to quantify increased productiv- ity and, thus, cost savings. One of these modules was the RFI module. RFIs are a means of asking a question that needs an answer before work can proceed any further. KFA found that 9 months into the Douglas Blue Line Recon- struction project, CTA senior technical personnel were pro- cessing 260% as many RFIs per business day per person as, and responding in 18% less time than, people who were not using the web-based system on a comparable construction phase project that was managed without a web-based system. This increase in efficiency translated into a savings of $152,000 per year, or $760,000 for 5 years, as a result of decreased time spent by senior engineers processing RFIs. It also

reduced cycle time and eliminated multiple iterations in work processes. Storage Costs ProjectNet also saved the costs of physical document stor- age. The Website Implementation Team estimated that the CTA would require approximately 1,200 square feet of ded- icated paper document storage for its capital projects. The fact that this space was no longer required saved the CTA approximately $24,000 per year, or $120,000 over the pro- gram’s 5-year duration. Other measurements of success are evidenced by the CTA’s gaining ISO 9000:2001 registration. ProjectNet enabled the CTA to meet the ISO registration criteria for document man- agement and retrieval. This ISO 9000 registration for the agency’s quality management system for engineering and con- struction operations gives the CTA greater competitive stand- ing among other transit agencies vying for federal funding. 26 Awards In 2003, the CTA won the Richard H. Driehaus Public Innovator in E-Governance award for its implementation of ProjectNet, and the FTA has publicly announced that the CTA’s approach should be replicated by others. KFA received the 2002 Illinois Road and Transportation Builders Associ- ation Technology Advancement Award for contribution to technology improvements in transportation design and con- struction. The case study was presented at the American Pub- lic Transportation Association’s 2003 Rail Transit Confer- ence in San Jose. In 2004, KFA and the CTA were recognized by Constructech Magazine for the successful use of advanced technology to improve business performance. The CTA was awarded the Gold Award in the Transportation Category for the execution and use of Citadon’s ProjectNet for the CTA’s 5-year, $2.2 billion CIP. KFA received the Technology Enabler Award for its contribution to the successful imple- mentation and continued support of the ProjectNet project management and collaboration system.

27 CHAPTER 3 PORT AUTHORITY OF NEW YORK AND NEW JERSEY: MASTERING PROJECT CONTROL OVERVIEW The PANYNJ has an $8.7 billion, 5-year CIP. Though many people think first of New York’s bus system when they think of the PANYNJ, the authority’s scope is much broader. There are different “line units”: • Aviation (four airports, including John F. Kennedy [JFK], La Guardia, and Newark); • Tunnels, bridges, and terminals (TBT), including the Lincoln and Holland tunnels and the George Washing- ton Bridge and the PANYNJ Bus Terminal; • Ports at Newark and Elizabeth, New Jersey; and • The PATH subway system connecting New York and New Jersey and the Downtown Restoration Program (which includes the restoration of train stations at the site of the World Trade Center). The PANYNJ supports this massive span of operations with its 5-year, $8.7 billion capital budget. Its engineering department has a full-time staff of 650 engineers, supple- mented with about 600 outside consultants. The mission of the engineering department is to support this capital program with most of the work done in-house. The engineering depart- ment awards and supervises 100–150 contracts per year. The PANYNJ houses its employees in 30 facilities in New York and New Jersey. In addition, four or five office sites now house the PANYNJ employees who used to work at the World Trade Center. On 9/11, the PANYNJ lost 84 employ- ees in those offices. The attack has influenced the agency in other ways, as well. Since 9/11, challenging fiscal constraints have forced a more rigorous prioritization between projects. There have also been significant increases in expenditures for security. The agency has traditionally been conservatively managed when it comes to taking risks with data security. Since 9/11, that commitment has only grown. This case study will focus on the engineering department’s use of Primavera’s P3e software to manage its portfolio of 600 active and planned projects, emphasizing the classic proj- ect controls—scheduling and cost. All 600 projects in the engineering department are managed with Primavera’s P3e Enterprise cost and schedule management software. DESIGN THE SOLUTION: WHAT KIND OF PRODUCT DO WE NEED? A leadership team composed of Deputy Chief Engineer Peter Zipf, Assistant Director of the Capital Program Bill Radinson, Manager of Project Controls Pradip Mehta, Assis- tant Chief Engineer Achille Niro, and Manager of Engineer- ing Financial Services Joe Garcia, among others, strongly believed that technology could enhance existing work pro- cesses and provide a tool to manage information through a project’s life cycle. This team guided engineering services’ move toward technology-enhanced collaboration. The team’s selection and implementation of various technologies, includ- ing Primavera Expedition and P3e software, took place over several years. Although the team did not foresee all of the issues involved with selecting and implementing the tech- nologies, it successfully managed the change. In an interview, Peter Zipf said, “We were naive. But it all worked very well.” As various departments performed technology self- assessments, it became clear to the team that the many dif- ferent initiatives taking place at the agency represented an opportunity. Zipf said, Our goal was to keep the momentum going and keep pro- gressing. We weren’t mature enough to just adapt the tech- nology to suit us. We needed to break our effort down into unique critical components. We myopically looked at several initiatives and then one day they all were able to be inte- grated. CAD [computer-aided dispatch], scanning, project scheduling, document control—there were several hot things going on. Within the agency, we were also moving towards SAP and PeopleSoft and it all lined up to create a great time to take advantage. Gradually, the PANYNJ adopted an agencywide network that was accessible via a web-interfaced intranet. Zipf encouraged a free-form discussion of users from various divisions to discuss which existing systems worked, which ones needed replacement, and which ones needed enhancements. In the discussion, the PANYNJ learned the importance of using off-the-shelf technology. Joe Garcia said, Go for off-the-shelf as much as possible and get the best prod- uct in each class. Get the stuff that most people use rather than some homegrown concoction. It may not technically be the

best for you, but if it is what everyone else is using, then you are much more likely to find support. The team decided that its new project control system would have to be able to integrate with the team’s existing technologies. UNDERSTAND THE IMPERATIVES: A MUCH GREATER NEED TO MANAGE CONSTRUCTION EXPENSES AFTER 9/11 The PANYNJ has always emphasized fiscal accountabil- ity. Achille Niro described the agency as follows: “We are not a not-for-profit; we’re a public-sector service provider but we are self-sustaining financially. We don’t get money from the government so we have to make money from our own services.” From the mid-1990s on, there has been ongoing analysis to find out where the projects go wrong. The issues would be familiar to any transit agency—cost management, scope management, and, most of all, schedul- ing. Initially, the agency did not have comprehensive sched- uling; it had one system for design and another system for construction. Achille Niro told us the following: Timing became the crucial element—the longer it takes, the more we lost income and business opportunities, and the costs continue to escalate. We bond our projects, so finan- cially we have to stop that clock. We would constantly rein- force the message, “The greatest engineering job that is not completed in time renders little benefit. Great design and great construction delivered a year late is not good.” This was our message. The need to transform the PANYNJ’s talented technical engineers into informed business people accelerated after 9/11. Pradip Mehta said, After 9/11, there was more pressure to say, “We can’t afford to continue at this rate of spending” because revenues dropped, and revenues support the Port Authority’s Capital Improvements Program. There were also significant new demands on the budget: heightened demands for security at all Port Authority sites and a need to integrate the approach to security across the agency. In addition to enhancing project control, the engineering department and chief operating officer needed a system that would help the agency prioritize the 600 projects that it had in various stages of development. For years, the department had been moving in fits and starts toward a robust and integrated environment that would be mature enough to support web-based collaboration. It began in the late 1990s, when it was discovered that some systems were not Y2K compliant. At that time, the agency made a commitment to build up the agency’s network. The engineering department introduced Livelink for electronic 28 document management. This small step created a much more robust network and encouraged other divisions to do self- assessments about how technology might enhance their work, such as scanning drawings. The self-assessments, in turn, led to many different initiatives happening at the same time within different areas. The PANYNJ wanted to move from a stand-alone solution to an enterprise solution so that units would be more inte- grated. Most important, the system needed to strengthen the cost controls on the agency’s capital projects. Financially, the existing system did not allow project man- agers to understand what was happening with costs on their projects. The old process to understand expenses on a project involved the project manager sitting down to compare sepa- rate spreadsheets, code by code, between the budgets in Excel and the actual charges from the finance office’s SAP system. Most PANYNJ project managers are responsible for 10–15 different projects in various stages of development; the hard copies of these reports might run to hundreds of pages. Check- ing within each expense category might require the input of several different managers. Only the most egregious discrep- ancies were addressed; then the project manager initiated an SAP investigation with finance to understand the charge. Joe Garcia said, “It was pretty tedious, and a lot of people didn’t do it. . . . We had horror stories about people coming to us [and saying] . . . ‘I have a $60,000 project—little one—but I have $90,000 in miscodes!’” Project managers either spent a great deal of time struggling with the system to understand the costs on their projects or didn’t bother to understand it at all. Given the new financial pressures on the agency, engi- neering services needed a solution that could integrate and enhance the project control processes. Selection: Primavera’s P3e The engineering department recognized that it didn’t make sense to choose a scheduling package that was different than the construction package. The department wanted something that could take the PANYNJ from inception of a project to closure. The departmant also wanted something that could be integrated with SAP and something that the construction and engineering industries were comfortable with and had already embraced. This would make interfacing with one another easier. The team also recognized that P3e had a very robust cost control module that it could use to provide the cost control information to project managers in a palatable and practical manner. This was one of the driving factors behind the selection of P3e. The PANYNJ studied what others in the industry were using and found that over 90% of the engineering and con- struction industry and the top 400 contractors used Primavera Scheduling. The department decided to use Primavera. Prima- vera could be customized to the agency’s needs and was flex- ible enough to integrate with the agency’s existing systems.

Figure 3 illustrates how the PANYNJ uses its Primavera software in concert with other software packages to orches- trate the management of its projects. The PANYNJ Chose to Keep Its Data In-House Rather than using an ASP, the PANYNJ houses everything internally with a sophisticated backup system. The department trained both Primavera experts and the agency’s own technol- ogy services department to manage the network and supervise the data security. However, because the PANYNJ already had existing server infrastructure and a robust intranet sys- tem, it wanted to use what it already had. Further concerns of keeping the data in-house because of the owner-centric phi- losophy of the agency and security concerns made in-house servers the more attractive option. Data Are Downloaded into P3e Primavera’s P3e functions as a kind of umbrella system that incorporates other software. To accomplish the systems inte- gration with other departments, there are extensive monthly downloads from both the budgeting system and SAP. The downloads integrate actual costs into P3e. These downloads are broken down by actual costs, costs by each stage (e.g., design, program management, and construction manage- ment), costs by division (e.g., engineering and architect), costs by function (e.g., mechanical and electrical), and costs by employee who charged the codes. 29 Role-Based Reporting Scheduling and cost information is entered into Prima- vera’s P3e system. This information is tightly regimented— only the information that each project manager needs to do his or her job is given. For example, each project manager sees only information relating to his or her projects. The PANYNJ determined that only some people in the engineering department would need to be fully trained on P3e. These people, called “power users,” are technical resources for the department’s 120 project managers. Project managers are described as “casual users” and see a higher-level interface of P3e called Primavision. Zipf said, “Primavision is a superb project control tool. Project team members can come into the environment and find schedules, and we set up reports that enable them to find information.” Primavision makes a lot of data available to project managers to determine trends, but project managers cannot go into the system to make changes. Achille Niro said, We made a conscious decision that project managers should not be experts on P3e; their role is to manage the projects. Let’s provide technical experts to help them crank out any scenario the project manager needs, but let us give some executive summary–level data as well as detail to the project manager that he or she can easily access and use. Power users, such as project control engineers, use P3e extensively and are trained to understand the nuances of scheduling mechanics and its other modules. These users can update and maintain the information. Primavision Training Engineering Management Services Division (by Project/ Stage/Division/ Functional Unit/ Employee) Costs Stage Budgets (by Project/ Stage/Division/ Functional Unit Engineering Budget Proposals EPS Construction Information CONTRAK P3e/Primavision/Cost Schedule Control Interactive Report s Expanded Integration Flowchart Standard Reports (EOL) Total Construction Cost for contracts to be awarded ESTIMATING Cost Reports Authorized Budgets, Schedules, CIP, Forecast Figure 3. Expanded integration flowchart.

Casual users use Primavision, the “window” into P3e. The idea is not to overwhelm the casual users with too much detail, but to give them a visual way to access the data that would help to facilitate their decision-making processes. However, casual users cannot change the data. This restric- tion helps to maintain the integrity of the information. Con- sultants, who have been assigned to a particular project and essentially become an extension of the PANYNJ staff, also have access to Primavision. Training on Primavision takes only 1 hour. There is often a refresher session after 3 or 6 months. UNDERSTAND THE RESOURCES The PANYNJ’s engineering department did not set out to reengineer its processes when it implemented Primavera’s P3e and Primavision, but it did need to think very carefully about what information needed to be presented to the project managers. Rather than give each project manager an SAP license, which would have been expensive and would have flooded the project managers with too much information, the department instead downloads some summary and relevant detail information into P3e once a month. This information then “rolls up” further into Primavision. Joe Garcia said, We were very careful not to overburden P3e with all the financial information at the level of every journal entry. We reflected those costs and schedule parameters that drive the project management decisions. If you need more detail, you can always go get it from SAP. The engineering department recognized that real-time inte- gration would be not only complicated, but also expensive to maintain. With such a dynamic link, any changes would require modification into the system. Because SAP is currently on a client server, monthly downloads are more appropriate than a dynamic link. P3e has monthly interfaces with existing systems that are not now web based, including SAP (actual costs), ConTrak (construction management system) and EPS (Engineering Proposal System). The department is exploring the use of hyperlinks between Primavision and project draw- ings posted on the intranet. The highly trained project control specialists (i.e., power users) also became change agents. Joe Garcia said, “It was a great vehicle to introduce this stuff. It’s his [Mehta’s] change agents, stationed right next to the project manager’s. There is no better way to do it.” To integrate the system into the agency’s existing technol- ogy, the PANYNJ took great care to understand what infor- mation from System A needed to be downloaded to System B. The engineering leadership team’s project-mapping pro- cess allowed the team to configure only the essential infor- mation that would enhance project managers’ ability to make decisions. 30 The agency uses Primavera Expedition software to track its shop submittals and RFI turnaround time for all projects with budgets of $3 million or more. For example, all submittals flow through the agency’s project managers, who are respon- sible for disseminating the required information to Expedi- tion specialists, who, in turn, enter the tracking information into Expedition. Once the information is in the system, the shop submittal log and the RFI log can be printed out at any time. The system will show who has opened the RFI log and looked at it, where an answer has been given, and where an answer is still pending. Pradip Mehta said, “You can clearly see who is holding it up.” Once a week, the resident engineer meets with the contractor and reviews all RFIs and shop sub- mittals to confirm which ones have been answered and which ones are not yet answered. EXPLORE WITH PROBES AND PILOTS The philosophy behind the engineering department’s approach was not to exhaustively redesign its processes for- mally, but instead to quickly test the new technologies with pilot projects. The department thought carefully in advance and sought input about what the project managers needed from the system, but the department wanted to avoid a lengthy redesign process before introducing the technology. Pradip Mehta said the following about the technology: We had to make sure we configured it in a way that was easy for [users]—we didn’t have formal committees but continu- ous informal feedback from diverse small groups. We felt the danger of a committee of 50 people—we didn’t want to detract from our vision because we knew what we wanted. We wanted to avoid elaborate review processes driven by formal committees. It would take a long time to get everyone to agree. The PANYNJ created a pilot using Primavera’s Expedi- tion starting in 2000 for an $82 million parking lot construc- tion project at Newark Airport. In that job, the PANYNJ had 450 RFIs and 3,500 submittals. Four months into the work, the agency had a claim from a contractor for an extension of 3 months because the contractor claimed the agency was delinquent in answering RFIs and submittals. Because of the Expedition software, the department was able to provide a rebuttal to the claim in 2 days, demonstrating that the depart- ment was not the cause of the delays. The claim was with- drawn by the contractor. The engineering department took an organic and evolution- ary approach to introducing P3e to gain greater acceptance from users. Its implementation model uses pilot projects to validate benefits and gain acceptance from staff. When select- ing pilots, the department’s leader thought about which peo- ple would be good at offering constructive feedback. The

leader chose to focus on the middle managers in the agency, believing that they had the institutional power. Rather than redesign processes completely prior to imple- menting a pilot, the PANYNJ allowed itself to learn from the experience of the pilots, which in turn led to changes. For example, after implementing Expedition, the engineering department was able to see that the initial delay in the sub- mittal and RFI process was because of the project managers, who had lengthy submittals and drawings languishing on their desks. In response, the department retrained three sup- port people, and then hired two more, to become document distribution specialists. They helped the project manager route the shop submittals and eliminate the delay. As Peter Zipf said, “The construction industry will always be paper. The issue is how you distribute it.” Today, all PANYNJ projects with budgets of $3 million or more are tracked with Primavera’s Expedition to improve and log the submittal and RFI processes. This totals about 200 projects, involving 50,000 submittals and 6,000 RFIs. The total is independent of the Primavera P3e Enterprise, which is used to do scheduling and cost management for all 600 of the PANYNJ’s projects. Pradip Mehta supports the 20-60-20 rule, which says that 20% of the people in a given organization are optimistic about accepting change, 60% are skeptical but open-minded, and 20% are pessimistic. Given this distribution, it would be a waste of time and money to convince the pessimists. The idea, therefore, is to implement change organically by tar- geting the 20% of potentially early adopters and enlisting their help with a pilot project. Once the early adopters have had a positive experience with the new technology, they will then appeal to the 60%. Mehta explained, “We didn’t spend too much time trying to attack the 20% pessimists. We did attack on the 60%-skeptical middle ground—did some pilots with people there—they are now the salesmen for us.” It is a firm part of the PANYNJ’s approach to implemen- tation that experience is more important than analysis. Pradip Mehta said, Put a system out there, and it will illuminate the facts, and it will help you. You have to make a very careful, intelligent decision to what degree you’re going to solve your business problems—I knew that if I had to wait to solve our work order tracking problems, [the new technology] would have taken me 3 more years to implement. You have 10 different entities involved! It is what it is. Just put it out there and get everyone to see the problems—otherwise we’d still be sitting here with our process flow charts. The PANYNJ’s gradual implementation began with P3 in 2000 and then shifted to P3e in July 2002. From July to Octo- ber 2003, the PANYNJ brought Primavision to its casual users such as project managers, functional leads, and line department project managers. There are currently more than 350 users. 31 Gradual Adoption Achille Niro said, If you are an outside contractor, we do have certain require- ments, but we don’t require that you be online because that would be too restrictive. That is a pretty bold position for a public agency to take. We can easily put down a mandate and force everyone. . . . [But] to make it a directive would shut out a lot of people’s ability to work for us, and I don’t think policywise we would be able to support that. Even with the larger and more sophisticated organizations. . . . In my view the construction industry has been very slow to embrace technology. The next phase is to move to an extranet and integrate it with Expedition to enable outside consultants to readily access information via the web. Because the data are stored on the PANYNJ’s own server, the PANYNJ must deal with firewall issues. The Transformation of the Project Manager’s Role Although the hierarchy and approval structure at the PANYNJ is essentially unchanged since the adoption of this technology, there have been two significant shifts. The first shift is in the way that broad access to the information enables a much more collaborative work process. Achille Niro said the following about broad access: What it does is open up the whole process to the entire team, so you get collaboration. Multiple people have input to the sit- uation and quickly resolve differences in opinions, whereas previously, it took a longer time and you might miss some- one’s input. Now we have team-based communication— much more open and collaborative. The second and more significant shift has been in the way project managers have embraced their role as financial managers as well as engineers. Joe Garcia, a member of the engineering department’s financial services group, which works in a decentralized way in each of the line departments, has seen a “really big leap” since Primavision has been implemented: I’ve seen steady improvement over time in the amount of information engineers have regarding financial performance and a steady improvement in attitude. The old attitude has been “I’m engineering, my job is to get the project in on time, don’t bother me with financial details.” Financial information was just so hard to find. Even though they thought they didn’t have to think about this stuff, they do. Too often in the past, they had to find out the hard way they didn’t have the money. Roles have been enhanced with tremendous workflow improvement. The hierarchy is the same, but P3e has given

engineers and project managers more time and information to identify and fix problems rather than handling paper and finding numbers. With an enterprise solution, the focus has shifted from administrative detail to forward-thinking analy- sis across the board. The shift is representative of a mature organization. Project managers have not changed in their decision-making abilities, but their roles have been enhanced. Before Expedi- tion was implemented, for example, project managers were responsible for copying and distributing shop submittals to functional unit leaders. Because of their other responsibili- ties, project managers did not always have time to do the actual distribution, thus holding up the entire process. The agency recognized that the project managers needed help, and once Expedition was implemented, the agency refined this process. The agency hired Expedition specialists (ESs) and document specialists for support. Each unit has an ES who enters the submittals. The ES monitors and follows up on these documents so that the documents don’t get lost, as had happened before. An ES typically monitors about 30–40 construction projects within one program. Large engineering programs also have document specialists who do the actual distribution of documents. Because the specialists have now taken over the responsibilities of entering, distributing, and following up, the project manager can now look to where the submittal is and easily find out where the delay is and con- tact that particular department or individual. SOCIAL CHALLENGES: RESISTANCE TO CHANGE One of the major advantages of a web-based collaborative system and the reason such a system enhances productivity and speed is the increase in accountability. However, like a double-edged sword, this aspect of the system can also cause fear in some people. Because the system is so transparent and because upper-level managers have access to look across all of the projects, people can feel that there is a “big brother” aspect to the system. Joe Garcia, acknowledging this dynamic, said, “The project managers have no excuses. The data is all out there. There is nothing to hide behind. Now you have to look at it or someone else will.” Another social challenge is that people who were raised in a paper-based world traditionally feel more secure with paper and less secure with electronic documents. Achille Niro said, We have not yet reached the maturity where we do every- thing online. Part of that is due to the fact that the system isn’t fully built out and part due to a cultural thinking shift—a level of comfort that our people still need to touch and feel paper. That’s the barrier that we are starting to hit. How do you get them comfortable and convince them that this is more efficient for them? For the most part, however, because the PANYNJ has used an evolutionary and incremental approach to implementing 32 the system and relied on the power of pilot programs to reach out and convince people of the value of the new technology, resistance to the system has been minimal. For the most part, the word of mouth from people who have experienced the changes has been very positive. LINE DEPARTMENT’S PERSPECTIVE The majority of this case study deals with the implemen- tation of collaborative software in the engineering depart- ment. However, the line department that manages the opera- tions of the facility and oversees the capital program used the software differently. Assistant Director of the capital pro- gram Bill Radinson said, The line department’s role is one of oversight and strategic planning for the agencywide capital plan. Its role is to coor- dinate the capital plan and to make the decisions about which investments take precedence. . . . Even though the Port Authority is a financially self-sustaining organization, it is accountable to many external stakeholders, including the governor offices of New York and New Jersey. Many of the investments have large implications for other potential developments that the team must take into account. Many of these priorities have been determined by strategies set years ago. For example, the political decision that New York and New Jersey’s ports would become a hub on the East Coast has had major implications for terminal configu- rations and developments. Because of these pressures on the agency, the agency has historically placed more focus on cost management than scheduling issues; it has continuously refined the process by which projects are developed. This process includes a careful initial cost estimation based on historical data and experien- tial knowledge from different line units and the engineering department. The initial costs are made up of many assump- tions and often require going back to historical tapes (e.g., actual construction costs from past projects, now archived) over the last 10 years for data. This information is not easily accessible, however. With a move toward building an agency- wide estimating discipline, the operations team has recog- nized the need to coordinate this information and make it eas- ily accessible in one place. Moreover, the team understands that its project investments are not discreet but must be treated as a portfolio of assets. To get a fuller picture of pre- vious investment decisions, project costs and schedules, and investment flows and to make proper investment allocation decisions for such a diversified portfolio necessitate easily accessible and coordinated information. Integrating P3e with SAP with the cost control module enabled the PANYNJ to prioritize projects. In engineering, budgets are done in four stages: (1) conceptual design, (2) pre- liminary design, (3) detailed design, and (4) construction. With P3e, the engineering department can take a holistic

view of the all the proposed budgets and see how many bud- gets are in each stage. While the projects in Stage 4 (con- struction) are too far along to be canceled, those in Stage 1 may be able to be adjusted to save costs. Not every project that the operations team oversees is solely made up of engineering services. Many of the projects require outside approvals, which requires the team to create a master schedule, which may include, but is not limited to, engineering service schedules. The operations team recog- nizes that it lacks a robust technological tool to create and maintain such a master schedule. Currently, the closest thing to such a tool is an in-house mainframe system developed in 1990 called CapTrak. CapTrak captures actual cost break- downs of projects, total spending, and current actuals by month and year, but does not provide a way to holistically examine and compare actual costs with schedule-dependent estimates across a portfolio of projects. Given the schedule limitations of CapTrak, some line departments are using P3e to do overall master planning of their capital program. Bill Radinson said, Seeing the success of using applied technology to enhance business performance by the engineering department, [the operations team] is currently seeking the next generation of technology with EPMS [enterprise project management sys- tem] to get total costs, estimated costs, and project schedules into one place. This would not only include projects that involve engineering, but would also include those that need external approvals from outside stakeholders. The system would be integrated with engineering’s P3e system. Unlike the engineering department, which mapped its work- flow and sought out technology that could enhance the exist- ing processes, the operations team has been working to change its business processes to make it easier to go from the current information system to an enterprisewide system that incor- porates everyone. Currently, there are many redundancies because information exists in several places. The operations team recognizes that the processes are far more complex than they need to be because everyone tries to generate the same information. The difference in approach from the engineering depart- ment reflects the complexity of the agency. Within the line 33 operations, convincing five different line units that they face similar problems and would benefit from a more streamlined work process is difficult, particularly because streamlining the process will change people’s roles. However, the team wants to take advantage of the momentum created by the engineer- ing department with applied technology and convince new departments that, with appropriate workflow redesign and an enterprise solution, technology, too, can improve workflow, transparency, and ability to manage a portfolio of investments. The line operations department will take lessons from the engi- neering department and will continue to search for ways that technology and business intersect. EVALUATION: THE VALUE OF PROJECT CONTROL Zipf has asked the leadership team to think about quanti- fying the cost savings. In 2002 and 2003, the PANYNJ mea- sured its turnaround time for processing RFIs and submittals and saw a 20% reduction. The PANYNJ also believes that its project managers are able to be much more analytical now. Achille Niro said, “We’re already achieving benefits—better information for intervention. Better accounting. Certainly a heightened level of information. That part of the investment alone makes it worthwhile.” AWARDS In 2003, the department won the Primavera Excellence Award for Outstanding Achievement in the Engineering Industry for its strength of vision, demonstrated commitment to industry leadership, overall system configuration and inte- gration with other in-house systems, scope and breadth of sys- tem implementation, and added business value. Given this industry recognition, there are many outside organizations like the state of New York’s Metropolitan Transportation Author- ity (MTA), Keyspan, Johnson and Johnson, Wyeth Pharma- ceutical, La Farge (a French conglomerate), and Amtrak that have visited the PANYNJ’s premises to review the PANYNJ’s Enterprise implementation.

34 CHAPTER 4 RAYTHEON: RE-ENGINEERING THE SOCIAL SYSTEM OVERVIEW Raytheon is a global defense and aerospace systems sup- plier with 77,500 employees worldwide and $18.1 billion in sales for 2003. As an industry leader in defense and govern- ment electronics, space, and information technology; techni- cal services; and business aviation and special mission air- craft, it provides integrated mission systems for defense and nondefense needs. Established in 1922, Raytheon is now pres- ent in 70 countries. In the mid-1990s, the defense and aerospace industries began to consolidate as defense budgets were cut drastically. Raytheon began to acquire companies in 1997 and ultimately merged with E-Systems, Texas Instruments, Hughes Aircraft, and Beechcraft. Together, these companies made up “the new Raytheon.” As one Raytheon supply chain manager explained, “Each company had a corporate office, each one of the com- panies had several different businesses—each made up of previous acquisitions and divestiture, each one of them prob- ably had one or two legacy systems in each zone.” For exam- ple, the new company had 69 different purchasing systems. It also had four distinct cultures, databases, and corporate languages. UNDERSTAND THE IMPERATIVES: WHAT KIND OF PROBLEMS ARE WE TRYING TO SOLVE? Compounding the problem of consolidating these busi- nesses, Raytheon’s stock price dropped precipitously from $70 per share to $17 per share, and shortly afterward the stock market declined. This was their “burning platform.” There was a clear need to change the “old Raytheon,” which was noted for its traditional, hierarchical structure, into a “new Raytheon” that was more fluid and capable of collaborating and learning across many diverse boundaries. Another problem that Raytheon faced was that team mem- bers typically worked across different time zones and geo- graphic locations. Getting face-to-face meetings was some- times nearly impossible. Because many projects had tight time constraints and were complex, team members needed a better way to get quick answers and reduce the potential for miscommunication and mistakes. UNDERSTAND THE RESOURCES The Raytheon case study contains three distinct components: • The companywide adoption of Raytheon Six Sigma, a change that was mandated top down by chief executive officer (CEO) Bill Swanson, which helped to create a common language and culture across the four merged companies. • Raytheon’s choice of low-cost web applications rather than enterprise solutions to support these efforts. • The adoption of a community of practice model, which enabled Raytheon to share best practices and collaborate across organizational boundaries. This chapter specifi- cally examines the experience of Raytheon’s supply chain management team, which evolved from the Logis- tics Council to become Raytheon Integrated Logistics Community of Practice (RILCOM). The following sections describe these components in detail. The Companywide Adoption of Raytheon Six Sigma A Raytheon Leadership Forum was called in January 1999, and its participants decided that Raytheon Six Sigma would affect all company procedures. Over the next 2 months, Bill Swanson flew around the globe to reach 56,000 employees on three shifts. He himself was trained as a Raytheon Six Sigma specialist. At one meeting, union workers in the front row challenged Swanson, and he threatened to “go six rounds” in the parking lot with anyone who did not believe how pas- sionately he believed in the importance of Raytheon Six Sigma to the company’s future. Later, a videotape about Raytheon Six Sigma was made with Swanson at the beginning donning boxing gloves and repeating his commitment to the program. Clearly, the implementation of Raytheon Six Sigma was mandated from above. In addition to creating the boxing videotape, Raytheon tied Raytheon Six Sigma goals to the per- formance evaluation of all of the company’s top executives. Even with this degree of top-level commitment, Raytheon Six Sigma was not implemented everywhere at once. Initially, Raytheon Six Sigma was implemented in selected pilot areas

35 that were handpicked to make sure that the people involved were flexible enough to take up the new processes and lan- guage and make them successful. Then the successful results of these efforts were widely publicized during the first year of the program. This handcrafted approach at the beginning helped to ensure better acceptance, and, by the second year, the program had started to pick up momentum. By the end of 2000, Raytheon Six Sigma was fully deployed at different levels of maturity throughout Raytheon. Raytheon also focused particular attention on winning the support of its middle managers, believing that middle man- agers are typically the slowest to adopt change because they have the most work to do. Also, middle managers have a harder time justifying collaborating with people in other busi- nesses. Whereas senior leaders are compensated for how well the corporation does, middle managers are rewarded for how well their own businesses do. Raytheon customized Raytheon Six Sigma for Raytheon’s particular method of work. One Raytheon employee said, Each company had its own flavor of process improvement— one of them even had Six Sigma already. But we had the same language problem, so we said, “Whoever had Six Sigma before, erase the slate—it’s Raytheon Six Sigma.” So rather than calling people “Black Belts”—old Six Sigma ter- minology—we call them “Experts.” Raytheon also hired consultants to help design a 6-week training program tailored for team members to understand that the new corporate strategy from the merger meant a com- mitment to enhanced learning and the sharing of knowledge. Raytheon Six Sigma set a unified standard across the divi- sion and readied Raytheon for collaborative work processes. Raytheon’s Choice of Low-Cost Web Applications Simultaneous with the advent of Raytheon Six Sigma and communities of practice, Raytheon’s CIO recognized the need to adopt collaborative software to enable teams to work together across geographies. One Raytheon employee said, “We were going to have a need for desktop collaboration any- way—the whole world is going that way—the need for these tools is common, as people are working more geographically dispersed but need to collaborate as if they are in the same building.” This software needed to support a wide range of teams—from a small number of employees putting together an event somewhere in the country or developing a Power- Point presentation to huge, multiyear programs such as a mis- sile program that involved thousands of employees from dif- ferent businesses. Raytheon sent a few of its staff members to research and rank the top solutions that were compatible with Lotus Notes, the system that Raytheon was already using. The staff decided to spend “zero dollars developing something” and instead to leverage Raytheon’s existing software license. The staff also wanted a tool that would require no training at all, believing that requiring people to attend an hour-long training course would slow down adoption of the technology considerably. One Raytheon manager said, We needed one enterprise system, but when we looked at the price tag, it was upwards of half a billion dollars. We had just spent $7–8 billion buying these companies and did not have the cash to put into a common system. We had to find a dif- ferent way to collaborate that would allow us to work around all these different systems. We are just now implementing a common financial system and next will implement an enter- prise planning system. QuickPlace and eRoom were chosen because they are intu- itive and easy to use. They also required the purchase of only one corporate license. Raytheon understood that people had little time to take additional training. One Raytheon employee said, “These products were simple enough that when some- one says, ‘I don’t have time to learn something new.’ You can say, ‘You just have to go on it and start using it—you’ll make a mistake or two, but it doesn’t blow up.’” QuickPlace was the first solution Raytheon used, but Raytheon is now replacing QuickPlace with eRoom. With both systems, the user enters a collaborative space that is described as a “virtual room.” The user can bring other tools into the virtual room, such as Primavera scheduling software. The collaborative software will track revisions, assign time and date stamps, and note who made the revisions. One Raytheon employee said, “The beauty of this environment is that you can collaborate asynchronously. . . . You can basi- cally crunch on something around the clock if you are col- laborating with Europe and Asia.” QuickPlace and eRoom also provide chat room features if two or more users happen to be online at the same time, with no time delay. The dissemination of this technology has been grassroots, very gradual, and incremental. Raytheon believes that it is offering people a tool—an opportunity for people to use some- thing—but the users have to want to use it. One Raytheon employee said, If you force it on them, you have to have an infrastructure to make it stick—a training platform to create experts and spe- cialists, force people to come back and get new elements of the training because it drives the performance of the com- pany. If you force it on them, you’re back to needing to do lots of training. Technical Challenges and Social Challenges With the grassroots campaign style of implementation, there have been very few technical problems because the software itself is so intuitive. In fact, Raytheon managers believe that one of the lessons they can share is that if you are

36 trying to enhance learning and knowledge sharing between people, you want the simplest tools that the least technical person can use, not complicated tools that only the most tech- nical person can use. Complexity is a barrier to adoption. One Raytheon executive reflected on the different meth- ods of implementation that Raytheon used, including the mandate from the top that Raytheon Six Sigma received and the more gradual approach being taken with eRoom and col- laborative communities of practice: It is effective to legislate what you want to have happen— change can happen very quickly, if I have a billion dollar pro- gram and a lot of subs [subcontractors] want to participate on it—it’s the only way they’re going to do business on my pro- gram. We haven’t done that yet. When you don’t legislate it, you have to live through the pace and be willing. . . . We decided to make eRoom a grassroots activity—more cultural adaptation and less resistance—and the result is that it has less of an impact to the organization. But the change is less likely to be rejected with the strategy we’re following now. This same employee later said, Raytheon believes that the best way to disseminate this tool is by having people drawn to its ease and the value it can add. It’s not a corporate strategy to drive communities of practice but to develop a technology and an ease of being able to use it—if they don’t have a reason to use it, it won’t work—it’s easier than e-mail. The main problem with adoption has been the occasion- ally frustrating pace with which the old engineering culture takes up the flexibility of a more collaborative culture. Engi- neers want to be very precise and very sure of themselves before they answer a question, so the act of putting something “half baked” into a collaborative system and allowing others to help shape it can be very, very difficult. One Raytheon employee said, Some people don’t like to show an unfinished product—they won’t even contribute in a meeting because it will look like they don’t have a well-formed thought—they want to wait until the end and then critique it. . . . That’s how you know [the collaborative system is] starting to work, when people feel comfortable [making suggestions], and you don’t take anything personal when people reject your idea. Evaluation Raytheon believes it is still early in the adopter phase of technology introduction; only about 1,000 people use its col- laborative software. QuickPlace and eRoom allow all team members on a proj- ect to view each other’s changes, comments, and sugges- tions. They also allow project collaboration to happen 24/7, thus cutting down on costs, misinterpretations, and time. QuickPlace and eRoom enhanced the culture of sharing that Raytheon Six Sigma was promoting. As mentioned before, these tools have a chat room function that enables people to talk in real time about their ideas, suggestions, and comments on a particular project. It allows immediate revisions in one place and keeps all comments, changes, etc. These programs allow team members to tweak the work and allow everyone to see who made the changes and why without having to email a document back and forth. Because others can look at changes prior to finalization, team members must be com- fortable and willing to work in real time. Being web based also allowed the programs to easily interface with members. The programs’ simplicity fit the technical needs of team members, making sharing and collaboration easy, accessible, and practical. The Adoption of a Community of Practice Model Raytheon needed a mechanism to support collaboration across all its boundaries—across the newly merged compa- nies, across geographic and time differences, and across dif- ferent functions. Raytheon decided to develop a collabora- tive process as well as a technology—in effect, to redesign its roles and processes first before venturing into a new, enter- prisewide IT system. The company worked closely with the American Productivity and Quality Center (APCQ) in Hous- ton and licensed its community of practice methodology for use within Raytheon. Contact information for APQC is in Appendix D, Vendor Choices. What are communities of practice? They are well known by anthropologists as one of the oldest elements of organiza- tional life, defined as “groups of people who share informa- tion, insight, experience and tools about an area of common interest.”i Communities of practice have traditionally been part of the informal structure of organizations, forming spon- taneously as people seek help, solve problems, and develop new ideas or approaches. Many people believe that sponta- neous communities of practice are the real vehicles through which technical knowledge spreads in organizations. How- ever, if you try to reproduce these communities by sharing data or documents, you will invariably discover that the real value in knowledge management lies in sharing ideas and knowledge that are not documented and hard to articulate. This type of knowledge is called “tacit knowledge”ii and has usually been shared in person, often by watching someone do something or listening to someone think through a problem. One Raytheon CIO said, Communities of practice existed long before we had any of these [technology] tools—what I saw happen, we always had communities of practice—pods of software experts, and i Wegner, Etienne. Communities of Practice. Cambridge University Press, 1998. ii Polanyi, Michael. Personal Knowledge. University of Chicago Press, 1958.

mechanical—that came together around paper-based docu- ments. Then the technology came along. After the intranet was introduced we saw all these great tools to help us work more geographically dispersed and we said, “What do we do with them? Gee, how can we apply them? Can we share the tacit knowledge? Raytheon embarked upon a benchmarking study to under- stand how other best practice companies deployed their knowledge management activities and communities of prac- tice. One of the critical success factors Raytheon learned is well documented: face-to-face group contact is necessary throughout the year if the community is to be successful online. The standard seems to be anywhere from one to four meetings a year. One to two times a year seems to be a min- imum. One Raytheon employee said, The reason you need face-to-face contact with these groups is what you’re after is building trust. If I don’t trust you, I don’t care what you say. That social networking is the first level of trust—I can call you on Monday morning at 11:00 a.m. and you will answer the call and give me your undivided atten- tion. And I’ll respond when you call me, too. The second level of trust is—does that person really know anything? Can I trust the data that they give me? There are really only two levels of trust that need to be built. The need to supplement electronic collaboration with per- sonal contact is well established. In his article, “Knowing in Community: 10 Critical Success Factors in Building Com- munities of Practice,” Richard McDermott describes the work of Shell Oil’s Turbodudes community, which is devoted to sharing technical information about a particular geological structure, turbidites. The Turbodudes are able to meet weekly and use a coordinator who helps them to stay connected to one another. McDermott notes that communities thrive on trust: Contact—and the social connection and obligation that comes with it—is the key to ongoing community success. The coordinator of one of our most vibrant global communi- ties said, “This is all about relationships. People don’t really contribute to the community because it is good for the com- pany. They do it because I ask them to.” Successful coordi- nators visit community members, . . . they keep the commu- nity energy up by building one-on-one relationships among community members strong. The Turbodudes’ coordinator tracks the number of people who attend meetings and has found that the strongest predictor of high attendance is how much time he spent the previous week walking the halls. Suc- cessful coordinators build and maintain these personal con- nections outside official community meetings.iii Raytheon communities of practice can be either informal or formal. The two have quite different expectations and requirements, as summarized in Table 3. An Informal Community of Practice: Raytheon Missile Systems At Raytheon’s Missile Systems (RMS) in Tucson, Arizona, engineers are assigned to various programs, each with its own separate contract. Although the engineers are located in the same Raytheon location, that location has 12,000 employees, so it was as if the engineers lived in separate worlds. After the knowledge management leaders at Raytheon completed benchmarking work, they shared what they had learned with the RMS vice president of engineering, who got enthusiastic about finding a way for engineers to share knowledge across these programs. He appointed a steering committee and told the members, “This is important. I need you to work on this.” One Raytheon employee explained that if two engineers in dif- ferent programs are both trying to solve problems with fuses, In RMS, these people don’t even know the other ones exist, let’s introduce them to one another. The output should be that we have old gray beards, sharing knowledge on fuses, with new engineers that can barely spell “fuse,” and that will help us share our core knowledge as we bring new people on. Initially, the vice president of engineering appointed six people who had passion, knowledge, and interest to lead the charge. Because they had content knowledge about different engineering areas, they had a good feel for where Raytheon needed to share knowledge to gain competitive advantage. They started by creating some pilot groups that they thought would be successful. Because these groups are informal com- munities of practice, their membership is open—one Raytheon employee said, “Come if it’s fun, if you’re getting anything out of it.” Good leadership of an informal community of prac- tice is less about being a project manager and more about being an excellent facilitator. The community of practice leader needs to let the community lead rather than directing it. One barrier that Raytheon discovered as it began to put together the RMS communities was that engineers are accus- tomed to charging their time to a specific contract rather than to overhead. One Raytheon employee said, We are a company of projects, and our projects come directly from contracts, and that’s very bureaucratic. How do you get out of your silos when that’s not a contract requirement? You can execute your contract, you just can’t do it as well or as rapidly. . . . We’re very bureaucratic in each program, and this is a horizontal overlay across programs and across businesses. The company had to establish clear ground rules that made it easy for people to attend community of practice meetings. Engineering leadership suggested that the groups meet at noon and provide pizza and soda for these meetings. It was diffi- cult initially to draw attendance into these meetings and help the engineers get outside of their project orientation. It is more difficult to measure the success or progress of an informal community of practice because of the absence of a concrete deliverable. Raytheon measures participation and iii McDermott, Richard. “Knowing in Community: 10 Critical Success Factors in Building Communities of Practice.” Community Intelligence Labs (CoIL), 2000. http://www.co-i-l.com/coil/knowledge-garden/cop/knowing.shtml 37

38 ened its mandate to include a wider definition of logistics enterprisewide. The RILCOM team began with the baselining process that was critical to understanding what the company spent and where the opportunities could be realized. Next the team iden- tified best practices from all its businesses and asked, “If we replicate these best practices across all of our businesses, what will the impact on the bottom line be?” This questioning cre- ated a solid business case for the enterprisewide changes that the RILCOM team wanted to recommend. Individual busi- ness leaders saw the value of the team more clearly once these impacts were quantified; team members could then much more easily get permission to do RILCOM’s work during paid business hours, which raised the status of RILCOM membership. By analyzing the payback data, the team was able to identify two projects it wanted to focus on in 2003–2004: • Powertrack. This project converted 38 different freight payment methods to one standard web-enabled process and eliminated multiple and manual processes. • Mtrak. This project, which is a web-based self-service inventory system, automates and simplifies manual pro- cesses and makes material and property assets visible to internal customers. This solution has drastically reduced material losses and freed up logistical resources. RILCOM holds quarterly face-to-face meetings as a result of its belief that communities of practice need this time together in order to create the strong relationships that build trust. The group has weekly electronic meetings and even has its own mascot, Lonnie, one of the logistics leaders who dresses as a hobo and rides to their meetings on a bicycle, claiming to have no web access or telephone access at all. The RILCOM team was recently invited to present its experience in partnership with the American Productivity and Quality Center at Supply Chain World. also surveys those who attend to see how they feel about the community. One Raytheon employee said, “Are we doing good? Are we doing bad? You have to keep your finger on the pulse to see if the patient is still alive.” A Formal Community of Practice: Raytheon RILCOM One of the most promising areas for consolidation between the four companies of the new Raytheon was con- solidation of suppliers, which numbered 44,000 across all the different businesses. The engineers are in charge, and they all have their favorite suppliers. Although the companies had merged, the databases remained separate, and there might be the same part inventoried in four different places. Initially, Raytheon formed a logistics council with repre- sentatives from each of the businesses. This group focused on spend leverage but had very limited cross-business knowl- edge sharing. One manager said, We had limited cross-business sharing—didn’t talk about our processes, stayed stove-piped, didn’t standardize our processes. We were fragmented, we have these different busi- nesses—players on the team kept changing. At the enterprise level for logistics, we didn’t have a common focus, no one to lead. . . . We were communicating as this organization, but we were still just stove pipes. Everyone was still thinking, “I’m only going to do what is good for my business.” Then, in 2003, Raytheon transformed its logistics council into RILCOM to adopt a one-company strategy for the logis- tics organization. Business representatives were still included, along with knowledge management champions, subject mat- ter experts, and peer assistants. In fact, the hierarchy didn’t change, but a new leader of the group was brought in, George Ellis. Ellis had no staff of his own but reported instead to the corporate staff, and, under his leadership, the group broad- Variable Formal Community of Practice Informal Community of Practice Purpose Create bottom-line impact Create social network Expectation Produce deliverable Share knowledge Leadership Skills Directive, project management based Facilitative, influence based Membership Closed membership—by invitation only Open membership—anyone can show up Sponsorship Must be formally sponsored May be formally sponsored TABLE 3 Formal versus informal communities of practice

EVALUATION: INCREASED USE OF COLLABORATIVE TOOLS Adoption of Raytheon Six Sigma has continued to drive the performance of the company. Raytheon currently has 675 certified Raytheon Six Sigma experts, and 1,400 employees have received training. By 2004, an estimated 13,000 full- time people were qualified as Raytheon Six Sigma special- ists. Raytheon Six Sigma has become the way that people think about work and processes at Raytheon. The enterprisewide adoption of Raytheon Six Sigma sug- gests that Raytheon has been transformed from a hierarchical organization to a collaborative organization. As word has spread, more businesses within the company are using Quick- 39 Place and eRoom. Without top management forcing the prod- ucts on employees, adopters have recognized the value of the tools through experience and sharing with peers. The increased use has led to easier facilitation of information sharing, improved efficiency, and increased speed of work. QuickPlace and eRoom are proving to be elegant solutions that did not require a great deal of investment, training, or customization. There is also increased use of the communities of practice, which is indicative of the growing norm for people to share knowledge. Currently, Raytheon estimates there are 65 for- mally sponsored communities of practice and about 65 more that are not yet registered. The company believes it may even- tually have up to 1,000 communities.

Next: Part 2 - The Theory You Need »
The Successful Adoption of Web-Based Collaborative Software Get This Book
×
 The Successful Adoption of Web-Based Collaborative Software
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s Transit Cooperative Research Program (TCRP) Report 84 e-Transit: Electronic Business Strategies for Public Transportation Volume 7, The Successful Adoption of Web-Based Collaborative Software presents case studies of three organizations that have successfully used web-based collaborative software: the Chicago Transit Authority, the Port Authority of New York and New Jersey, and Raytheon.

The declining costs of communications, data storage, and data retrieval are accelerating the opportunities spawned by the Internet and other information and communications technologies. Choosing and sequencing investments in technologies, processes, and people to reduce costs and increase productivity present challenges to the transit manager, who must weigh the costs, benefits, and risks of changing the ways services are delivered. To assist in meeting such challenges, the TCRP Report 84: e-Transit: Electronic Business Strategies for Public Transportation series documents principles, techniques, and strategies that are used in electronic business for public transportation.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!