Abstract
Global teams involve key stakeholders from multiple countries. Virtual teams are formed when the stakeholders are physically not co-located. Inadequate consideration of its complexity leads to troubled projects and failure. The key success factors are discussed with examples. Project management processes and tools are summarized.
Project Highlights
The projects described in this paper were conducted in the IBM Technology Division and its partners, in the field of semiconductor chip engineering and production. The extended teams included project sponsors, customers, team members, and contractors. Project management was performed in a highly matrixed environment.
The cross-functional project team consisted of between 30 and 40 members working in several different companies and countries, such as the United States (New York, Vermont, Minnesota, Colorado, California, and Arizona), Singapore, France, the United Kingdom, Germany, and Korea (Exhibit 1). Clearly, different corporate cultures and national differences existed within the team, including different mother languages such as English, French, German, Chinese, and Korean. Another factor that complicated team cohesion was time zone differences (as much as 12 hours between Asian and U.S. teams).
Physical project deliverables were semiconductor integrated circuit chips on 300-mm silicon wafers. In addition, the team needed to manage triple constraints of budget, time-to-market, and product quality and performance. The chips were used for communication and personal digital assistant (PDA) applications. The customer took advantage of the common platform (CP) model (Chartered Semiconductor Manufacturing, Samsung, and IBM), which offered a multisourcing foundry option, where a customer could build a single product in three companies and locations without requiring redesign. This model allowed any customer to balance demand among the sources and to drive cost via competitive bidding. This model was unique in the industry in its advantages to the customer, but also offered significant benefits to the CP member companies. The partner fabricators extensively shared lessons learned with each other to speed up the common yield ramp.
The common platform offering required that all participating factories have fully compatible and synchronized processes. Semiconductor wafer manufacturing employed sophisticated wafer processing tools and for state-of-the-art manufacturing processes (e.g., the 65-32nm processes employed in these projects) required hundreds of steps during wafer production. Typically, a production run additionally included further steps such as design release (Zhou, 2008), mask build, and wafer testing and shipment logistics. If any one of these productions steps was out of sync between the factories involved, the end product could potentially exhibit functional differences unacceptable to the customer. Therefore, CP production runs were preceded by a stage at which process synchronization was driven to an acceptable level. Complicating this task was the procurement freedom that each member company enjoys (to optimize local infrastructure and capital investment constraints), which led to equipment differences across the CP member factories. These deltas needed to be carefully assessed for impacts on the electrical and physical equivalence of the devices' built and any differences were rigorously eliminated.
The customer required an aggressive build plan, resulting in a tight project schedule that needed to include factory synchronization among the CP members. Furthermore, key technical specifications were changed by the customer several times during the execution phase, driving engineering effort to response to the change and requiring project management effort to contain the triple constraints.
Challenges and Best Practice
Customer and Market Demand
As in any business, high-tech business customers and markets were demanding. Additional pressures in these projects arose from the competitive product sourcing strategy, making for a unique competitive/cooperative team environment. Customers compared suppliers to drive quality and timelines and to reduce price. Balancing customer demands and internal business constraints was therefore a constant challenge. Failure to meet project financial goals would obviously jeopardize the project and the cooperation between the partners. It was effective to have the customer be part of the solution to their demand, and frequent customer interlock meetings were instituted between the CP partners and the customer technical as well as executive teams. Because the customer was directly involved in many decisions and benefited from the solution, they assumed ownership and readily supported executing the solution.
Project Manager's Authority
The core project skills required for these projects included project management, finance, sales, technology development, design, material science, manufacturing, reliability, product engineering, and supply chain. Each functional area was represented in the project team. For these projects to succeed, it was imperative to establish the project manager's authority at the project onset. The senior executives responsible for the project personnel in each geographic location were therefore formally requested to endorse the project. A project charter was issued and communicated to the executive stakeholders and the involved management teams. This allowed the project manager to build a strong alliance and support.
Exhibit 1: Location of the cross-functional team members.
Reward was a powerful tool for project managers to enhance their team leadership. IBM had various internal award programs for internal employees. In addition, there was a Partner Recognition Program for IBM employees to recognize external team members. Both reward programs were used to praise extraordinary efforts in our projects. The monetary value of the awards was nominal, but the appreciation went a long way to building a good team.
Implementation of Matrix Management Structure and Project Management Process
In our global projects, the critical skill sets were diverse and the team members were not co-located. The resources were often shared with other projects. A matrix management structure leveraging resources from multiple functional areas therefore was the best choice.
The implementation of the matrix management structure was somewhat different from one geographic location to another. Factors influencing implementation included executive commitment, employee's perception, and critical mass of project managers. Strong executive commitment sent a clear signal to the entire functional organization that these projects were matrix managed. Within IBM, project management training courses had historically been provided to establish a culture supportive of a project-based organization. Through the training, functional managers were familiarized with project management methodologies, advantages, and terminologies.
Within the organization, projects were driven by project managers. A critical mass needed to be reached in order to successfully implement matrix management across the business unit. In IBM, a formal project management infrastructure exists in which project managers support each other and share lessons learned. Because project managers had the same systemic training on project management, they followed a well-defined and consistent process to implement the matrix management. Some basic project management training was offered to project members to bring them up-to-speed on the roles and responsibilities of the team members, project manager, and functional managers.
Within IBM development and manufacturing operations, projects followed the Integrated Product Development (IPD) process. The IPD process consisted of five project phases: concept, plan, develop, qualify, and launch. The phases developed and qualified were similar to the PMI executing phase. The launch phase was similar to the PMI closing phase. IBM had internal IPD training courses open to all employees on global scale such that there was general awareness of the process.
The project manager had the responsibility of highlighting priorities and making the team move coherently towards the common goal. Measurement metrics as part of the project management process were defined: technical performance was measured by yield; schedule measurement was measured by wafer movement vs. target; cost was measured by person-hours and process yield. Due to the multisource nature of the projects, an additional metric was the degree of convergence between the three factories. Where appropriate, these metrics were discussed with and agreed to by the customer.
Exhibit 2 shows the matching performance step up as a function of time. Matching was tracked for an extensive set of wafer acceptance criteria to a specific, customer-defined set of specifications within 1-sigma and 3-sigma limits. The 1-sigma limit ultimately gauged the process convergence most closely, while the 3-sigma limit was used for mass production disposition and production control. This convergence metric abstracted large numbers of detailed technical data into a simple and easy-to-present form and allowed key technical issues and progress to be communicated concisely. Of course, drill-down to more detailed levels was available for in-depth review to aid problem solving.
The example of a schedule metric in Exhibit 3 was measured by comparing the actual against the planned dates during the mask build stage. Photo masks were key components of the wafer manufacturing process, as they define lithographically the structures to be built on the wafer, and their timely delivery was critical during the initial stage of design verification (DV). Design verification was typically done using a small prototype wafer lot (DV lot) that ran at expedite speed through the manufacturing process. For this lot to have a high likelihood of successful manufacturing execution, it was preceded by a dummy lot (a.k.a., pipe cleaner or mine sweeper) that was used for process set up. Mask stock dates must be earlier than the pipe cleaner lot date or the lot would have to be put on hold waiting for the mask to arrive (RTM – data released to mask build). In the schedule shown in the Exhibit 3, the lower the data point on the chart, the earlier the task occurred. The example shows that mask stock dates rarely gated lot movement. Such charts were tracked during the design release in all three factories and key dates were shared among the factories.
Exhibit 2: Technical metric measured by matching performance.
Exhibit 3: Schedule metric.
Change Control
The project baseline was established with the agreement of multiple companies. Any change to the baseline required sign off from all the companies. An electronic product change notification (PCN) system was developed to support the global virtual projects. It utilized the Lotus Notes environment and tightly integrated with other Lotus Notes business applications. A key feature of this system was that it could be made compatible with other companies' firewalls, therefore allowing change review board members from other companies to participate in the change review process. The PCN was replicated to and from the project sites in different countries. The records across all global sites were synchronized on an hourly basis. The PCN system automatically notified the affected parties of the request. When the change requests were overdue, the PCN system automatically sent out daily reminders to the responsible parties. The entire change review history was tracked and retained according to the company record retention policy. The access to PCN was controlled by a local system administrator at each project site. The PCN system enabled the global virtual team to collaborate on change control 24×7.
Communication IT Tools
Our projects involved a large number of team members. Clearly there were hundreds of possible communication paths within the project team. In addition, communications with the vendors and customers could impact the underlying statement of work (SOW). Therefore, the project manager needs to clearly define the official communication channels. Those were defined during the concept and planning phases and exercised throughout the project life cycle. The channel for communicating with the customer on business topics was sales. The channel for communicating with the customer on technical specification was the lead engineer. The channel for communicating with the project management council (stakeholders) was the project manager. The channel for communicating with the vendor was procurement. These definitions were discussed and closed with customers and vendors.
To address the geographic diversity and cultural and company infrastructure differences, a variety of communication tools were employed. E-mails were frequently used and worked best for delivering simple and short messages. It was observed, however, that a team discussion on e-mail etiquette was required to avoid e-mail traffic overload. For project documents, a central project data and file repository was established. The repository was a pull process as opposed to e-mail, which was a push process, so it was less intrusive than e-mail. The additional benefit of the repository was that the records in the repository could be retrieved whenever they were needed by any authorized team members no matter where they were geographically. IBM Lotus Notes software supports several types of project repositories. Document libraries offered simple templates allowing such a repository to be set up quickly and to support view of records in organized tree structures. Team rooms were geared to provide more collaboration functions. They enabled documents to be edited by several authors, supported review cycles, allowed calendar and meetings set ups, and provided multiple views of the records.
Dedicated Lotus Notes repositories and team rooms were set up for the projects (Exhibit 4) and were integrated into the Lotus Notes e-mail and other process flow systems. This allowed the record to be generated easily by copying from other systems and pasting into the repositories in rich text form without losing the original format. File attachments could also be moved between repositories and other systems through copy/paste actions.
Exhibit 4: Lotus Notes Team Room.
To complement e-mail and databases, instant messaging allows rapid communication of time-critical short messages. Within IBM, an internal of instant messaging (Sametime) was a popular IT tool to support our communication. The projects were in fast-paced environment, and getting real-time collaboration from other team members expedited problem solving. However, as with e-mail, a brief discussion on etiquette was required to avoid overuse. To aid this, Sametime offers a feature enabling communications with a list of predefined team members, while staying offline for others. This helps the team members to stay focused on project priorities without frequent interruptions.
In an environment with limited travel budgets and a globally diverse team, team building needed to explore alternatives to social gatherings to allow team members to make more than purely professional contacts. It helped team cohesion if members could relate to each other to the extent that team members were willing to share private information. Social networking Web 2.0 applications, such as IBM Beehive, were used on a strictly voluntary basis to facilitate building personal connections. Beehive was the IBM internal version of Facebook but with enhanced security, allowing embeds of confidential information. Outside of the company firewall, team members started being active on sites such as linkedin.com, in order to network with customers and vendors. Such sites also allow recommending a team member, adding the option of individual rewarding.
Another communication tool was the web-based application, such as IBM Customer Connect (ICC). This application was open to employees, customers, and suppliers after vetting. ICC facilitated security communications and documentation. Team members accessed ICC from various project sites to exchange technology manuals, design models, design data, or any large files that at times exceed gigabytes.
Time Zones
A particular challenge in the projects was the limited overlap among team members' routine work hours. With the Asian and U.S. teams, interlock meetings could only be scheduled either in the earlier morning or late evening. Having European teams on board put an additional constraint on the time slot, reducing the options to morning EST/PST. Especially when Pacific Time Zone team members participated, long work hours resulted, particularly for the Asian team members. This limitation put strong emphasis on the effective use of the above-mentioned electronic communication tools.
On the positive side, global virtual teams provided an opportunity to work on tasks on a 24-hour-day schedule. For a global project with project sites in the United States, Europe, and Asia, project tasks can be worked on continuously. The Asia team could start the work in the morning, and when they finished for the day, then pass it over to the European team. The European team could continue work on the task and then, at the end of their day, pass it on to the American team. The American team could then pick up the task where the European team had left off, and at the end of their day, pass it back to the Asian team, completing the circle. Then the cycle started over again; the work never stopped. In addition, different nations may have their major holidays on different dates. For example, July 4th is a major holiday in the United States, but not in Europe and Asia, and Chinese New Year is a major holiday in Singapore but not in Europe and the United States. Therefore, when the unique characteristics of the global virtual team were leveraged, they benefited the project schedule.
Lessons Learned and Conclusion
This paper presents the success factors of managing global virtual teams in dynamic environments. It is based on IBM worldwide high-tech projects. To achieve a successful project, the project manager should establish authority and deploy a rigid project management process across all project sites. Having customers contribute to the solution is a successful model to contain the project triple constraints. A change control system supporting external customers on a global scale is needed to keep the integrity of the project baseline. Communication channels and etiquette should be clearly agreed to by all team members and followed rigorously. A variety of IT tools should be extensively used in the project to overcome the communication hurdles associated with a worldwide project in a travel constrained environment. Time-zone and holiday differences put constraints on communication but can also be leveraged to benefit project schedule.
Acknowledgments
The authors would like to thank Chartered Semiconductor, STMicroelectronics and Samsung for their partnership and collaboration in the projects.
