Case Study: Globally Distributed Team: FibreNet Project

Directions

When reading this case study, focus on the issues that impact the activities and decisions involved in managing a project team that is globally distributed. In particular, observe how communication, culture, and collaboration complicate the management of schedule, process, and cost in global software development.

Case Summary

Description

FibOptia is developing a network management system (FibreNet) to provide quality-of-service (QoS) features for voice, data, and video transmitted over fiber-optic networks. The development of the FibreNet software system is distributed across three software research and development (R&D) centers that the company selected because of their proximity to collaborating universities, to the needed software engineering expertise at competitive cost, or to markets for their products. The development of some parts of the software system is on schedule, while other parts of the system are behind schedule. Marc Delancy, the senior manager of software development for FibOptia, thinks that development at the project sites is being done in a vacuum rather than in synchronization with each other. In this case study, he determines why the project sites are not collaborating very well and decides how to try to improve the situation.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Better understand the following issues in managing global development:

• Challenges of communication, collaboration, and coordination

• Sharing information and making decisions across a globally distributed team

• Identify the impact of global development on the management of project decisions with respect to scope, time, quality, and cost.

• Explain the problems that occurred in the case scenario, the causes of the problems, some plausible solutions to the problems, and ways to eliminate the problems in the future or to reduce their impact. Relate these to the decisions faced by project stakeholders.

Subjects Covered

Communications between distributed project team members, cultural challenges in global software development, collaboration across a globally distributed project team, and storing and sharing information for global development projects

Setting

The setting involves three software development centers of FibOptia, a company that builds management systems, applications, and services for fiber-optic communications. The centers are located in Hyderabad, India; Toulouse, France; and Montréal, Canada.

Key Concepts

• Managers must consider issues such as communication, culture, collaboration, and trust when making decisions for global software development projects.

• For effective collaboration, software project team members need to understand and follow best practices for communication and cooperation in a global development environment.

• Centralized project planning supported by localized management of project execution helps ensure successful achievement of project objectives across a globally distributed project team.

Terminology

ARCEP: Autorité de Régulation des Communications Électroniques des Postes, an independent agency for regulating the telecommunication and postal services in France.

FTTH: Fiber to the home, also known as fiber to the building (FTTB).

Incremental software release: A model for releasing software as a series of versions that iteratively add more functionality or features. The development of each software version usually involves a cycle with phases such as requirements, analysis and design, implementation, and test. In this way, an incremental model is iterative. The terms iterative and incremental are often used synonymously. An iterative model does differ in that it emphasizes both refinement and augmentation of successive iterations, whereas an incremental model typically focuses only on augmentation of successive iterations. See Larman and Basili (2003) for further discussion of iterative and incremental software development.

IP: Internet protocol.

Iterative software development: A cyclical model in which a software system evolves over a series of development cycles where the system is iteratively refined and augmented. Each cycle includes phases for activities such as requirements, analysis and design, implementation, and test. The final product grows incrementally from iteration to iteration to become the final system. The phases within a cycle are frequently kept short by limiting the scope of the requirements so that an iteration is available sooner for user evaluation and feedback. See Larman and Basili (2003) for a discussion of the history of the formulation of the ideas of iterative and incremental development.

Open System Interconnection (OSI) Reference Model: A standard description or reference model for how messages should be transmitted between any two points in a telecommunication network. Its purpose is to guide product development so that products from different vendors are compatible. The reference model defines seven layers of functions that take place at each end of a communication. Although OSI is not always strictly followed in terms of keeping related functions together in a well-defined layer, many if not most products involved in telecommunication make an attempt to describe themselves in relation to the OSI model. It is also valuable as a single reference view of communication that furnishes everyone a common ground for education and discussion (SearchNetworking.com, OSI).

Packet-switched: The type of network in which relatively small units of data called packets are routed through a network based on the destination address contained within each packet. Breaking communication down into packets allows the same data path to be shared among many users in the network. This type of communication between sender and receiver is known as connectionless (rather than dedicated). Most traffic over the Internet uses packet switching. The Internet is basically a connectionless network (SearchNetworking.com, Packet-switched).

V Model of software development: A software development approach that focuses on the verification and validation (V&V) of a software system at each stage in the software development process. Two objectives to be accomplished by following a V Model are to discover defects in a software system as early as possible and to assess whether the system is usable in an operational situation (Graphical Development Process Assistant).

VoIP: The transmission of voice over packet-switched IP networks (National Institute of Standards and Technology 2005).

The Case

Scenario

Marc is an experienced manager who has led multiple teams in the development and delivery of software products on time and within budget. Marc has led virtual teams but is new to global software development. He faces challenges that he did not have when managing teams located at one site or within the same geographical area. He thinks that he has recently been troubleshooting problems rather than managing decisions to minimize problems in the project execution.

As the senior manager for the FibreNet Project, Marc Delancy is responsible for delivering a new product to manage transmissions over fiber-optic networks. The FibreNet product will enable Internet service providers (ISPs) to provide voice over the Internet (VoIP), data, and video transmissions over fiber-optic networks with differing types and levels of quality of service (QoS). To achieve a product delivery that is on time, within budget, and according to specification, Marc must ensure that project resources are used purposefully and carefully throughout the project. He oversees not only the use of physical resources but also the investment of human effort, time, and capital.

From prior experience, Marc knows that project stakeholders are the most important resource for the successful development of the first version of the FibreNet Manager product. Since the product is to be launched within metropolitan communities in France, the direct stakeholders are the French telecommunication companies and ISPs, the business and marketing planners for FibOptia, and the product development team. Ultimately, the French consumer of telecommunications services will benefit from the availability of higher levels of QoS, which is also a mission of Autorité de Régulation des Communications Électroniques et des Postes or ARCEP (the agency for regulating telecommunications and postal services in France). Through regulation, ARCEP seeks to ensure that French consumers have access to affordable telecommunication services comparable or better than those available in other technologically advanced nations, especially to services emerging within the European Union (ARCEP).

Marc was one of several FibOptia managers who influenced the vice president of engineering’s decision to locate the company’s development sites in strategic but geographically dispersed places to, over time, achieve substantial reductions in development cost and time. Marc had specifically argued that the software engineering expertise available in Hyderabad is strong, versatile, and low-cost compared to the same expertise in Western Europe. As an adjunct faculty, Marc has taught software engineering courses at the local university and has been impressed with the talent and dedication of students who come from undergraduate schools in Hyderabad. Marc had also explained that development potentially could be done around the clock because of the time differences between globally distributed sites.

Another motivating factor for a distributed team approach is that the source of core technology for FibOptia products is not located near the target market of France and Western Europe. A critical component of FibOptia’s products is the underlying network hardware needed to manage QoS via the reservation of fiber bandwidth, packet scheduling, and routing. Other important intellectual property are algorithms to manage QoS in software at the application and lower communication levels in the Open Systems Interconnection (OSI) Reference Model. The company currently funds the needed investigation and laboratory testing at academic and other research institutions in Montréal. Many of the employees at the FibOptia R&D site in Montréal have completed their academic studies at one or more of these institutions. In the heart of the target market, the Toulouse center focuses on QoS policy formulation (driven by business incentives and governmental regulations), on customer studies, and on developing user interfaces for FibOptia products.

Déjà-Vu

Marc is hearing the same comments from his project managers repeatedly. From Marc’s perspective, each site seems to be working in a vacuum. The tasks involving collaboration between the sites are behind schedule, while those that can be done solely within the local sites are on schedule.

The time is 10 p.m., and Marc turns off his laptop. He leans back in the chair at his office and thinks about what he heard this week at his teleconference with Robert Johnson (Montréal), Henri Baroque (Toulouse), and Janet Kumar (Hyderabad). Figure 10-1 shows an organizational chart of the FibreNet software project management.

Figure 10-1: FibreNet software project management

Marc recalls a humorous but strangely insightful movie titled Groundhog Day that he watched on a flight to the United States. In the movie, a disgruntled weatherman relives a particular day in time over and over again. The weatherman decides to use what he learns from one instance of the day to the next instance to his advantage. Ultimately, the character in the story realizes that despite his attempts to improve the situation that repeatedly unfolds, he is doomed to spend the rest of his life in the same place, doing the same things, and seeing the same people every day until he changes the way he looks at life (IMDb.com, Groundhog Day).

Marc suddenly sits straight up in his chair as he realizes that his project managers have been indirectly telling him that global communications and collaboration across the three development sites are not happening. Marc recalls the conversation between the three project managers at the last weekly teleconference. He realizes that there is a recurring pattern to what is being said and how it is being said. Since the three managers and Marc use teleconferencing software that supports face-to-face communications via Web cameras on their desks, Marc remembers the expressions on the managers’ faces even though there were occasional lags in the refresh of the video streams from the different sites.

At the Last Teleconference

Henri smiled and said, “Good news. The design of the architecture for the Network Manager’s user interface layer is still on schedule. We have iteratively prototyped the user-oriented screens and gotten feedback from the customer test group. We specifically included people who oversee and test the network services provided to consumers. These systems administrators are happy with the planned functionality as well as the ease by which they will be able to monitor network performance at the network (packet) and application levels.”

“This is good news,” Marc commented. “Has your group been involved in the development of the interface to the business software layer design? I understand that the Network Manager will consist of a three-layer architecture with a middle layer that contains the QoS policy components.”

Figure 10-2 shows the Network Manager software architecture. This diagram provides only a sample of the functionality to be performed by each layer of the software system. The arrows show the layers that communicate with each other and the directions of the communications. Henri frowned and emphatically replied, “Hyderabad has released no documents describing the architecture for the business layer, or at least no documentation is available in the shared repository.” It seemed that Henri wanted to say more, but he hesitated.

Figure 10-2: Network Manager software architecture

Marc then asked Janet how the design of the architecture for the business layer software is progressing.

Janet explained clearly and succinctly, “We have determined basic components of the architecture for the business layer but cannot complete the design until we receive the specification of requirements for the QoS policies as well as descriptions of the QoS algorithms to be used in managing QoS based upon these policies. We are waiting on Toulouse and Montréal for these specifications.”

When Marc again asked whether there have been joint discussions regarding the interface to the business layer, Henri stared and said that his team has been busy working with potential customers on the user interface. Janet sighed and said nothing.

Robert had a blank look on his face as Henri and Janet were talking. It was obvious that he was not in the loop regarding the interface between the user and business layers. He did seem to come alive when Janet mentioned her group’s need for information about the algorithms for managing QoS. Robert explained, “The QoS algorithms are complete. The reviewers verified that the mathematical models are correct, and our engineers simulated the application of the algorithms in the lab. We have started the patent process and will release the algorithms when this process is further along.”

Marc then asked, “How about the design of the interface to the network layer of the Network Manager? Is your group talking with Janet’s group?”

Robert replied, “We are working on the interface, but the design is evolving. We are not ready to release it.”

Marc now realizes that other than these weekly teleconferences, the three managers probably have minimal communication with each other. The three sites are obviously not collaborating on the design of the interfaces to the different layers of the Network Manager. Marc also noticed, as best that he could tell, that all three of the managers looked tired at the last teleconference. Pulling up a global clock in his Web browser, Marc quickly sees that at the start of the meeting the times in the different locations were 8 a.m. in Montréal, 2 p.m. in Toulouse, and 5:30 p.m. in Hyderabad. The times roughly correspond to the start and end of the working day as well as the time directly after lunch for the participants. This may be why everyone seemed sluggish. Marc wonders how the time differences between the three locations is affecting communications.

In-Person Meetings with the Project Managers

Marc does not think he has acquired “the whole picture” from his weekly teleconferences with the local software project managers. When planning his travel budget for the project, he had decided on traveling to the Hyderabad and Montréal sites every three months. Over the eighteen-month project, he would take six trips to each of these sites. The first three months of the project have passed. Considering the current state of communications between the software managers, Marc decides that this is the time to communicate in person and in private with the project managers at each site. He wants the project managers to feel comfortable in talking candidly.

In a French Café

Marc had observed that Henri seems more relaxed and talkative on Friday afternoons. He invites Henri to join him at a local café for coffee around 3 p.m. to discuss the project.

“Bonjour, Henri. Ca va cet après-midi?” Marc inquires if Henri is doing well this afternoon when he meets him at the café.

“Mais, oui. C’est vendredi.” Henri laughingly replies that of course he is, because it is Friday.

“Henri, at our last meeting, I think you wanted to say more about the interactions between the project groups at Toulouse and Hyderabad. Would you share your thoughts with me now that we are alone?” Marc asks quietly while looking inquisitively at Henri.

Henri knowingly replies, “Certainly. Your observation is correct. I do have more to say, but I did not want to embarrass Janet in our meeting. She is very thoughtful and careful about what she says in our meetings. I think she may be hesitant to say what she is thinking.

“My group has tried to talk with Hyderabad about the interface to the business layer software. Sometimes, we have a difficult time communicating in English on our teleconferences. We do not always understand what each other is saying,” Henry explains.

“Another issue is that the engineers at Hyderabad are not assertive in the discussions that we have had. They do not seem to be comfortable in collaborating with us in real time on the design. They seem cautious about proposing their own ideas and usually respond to our proposals by saying that they will need to think about what we said.”

Henri continues, “We are not trying to dominate the discussions, but they do not seem to contribute openly. They do try to understand clearly the details of our proposals. We also do not know why they are reluctant to release their current design of the business layer architecture even though we have explained that we understand that the design is still evolving. We realize that the design may need further refinement as the QoS policy requirements become more clear.”

Marc explains, “Yes, the final design will not be complete until we make decisions about these requirements, but we do have a specification of representative types of services and service levels. The specifics of these may change depending on how telecommunication companies and ISPs share access to the fiber. As you probably read in the news, ARCEP has decided that telecommunication companies must share access to fiber that they install to the home [FTTH]. Of course, nothing has been decided yet regarding individual ownership of fiber that would be managed using a communal approach such as is done with condominium resources” (Baritault 2009; T-REGS 2008).

He continues by asking, “Have there been discussions about the overall architecture for the business layer?”

Henri replies, “No, we are stuck. We cannot seem to motivate Hyderabad to share a draft of the architecture. But this is not much different from the way Montréal approaches collaboration. Our colleagues there have circulated no preliminary information regarding the QoS service management framework other than their original white paper. We have not been so worried about this, though, since our software does not directly interface with the network management layer software.

On to India

After his meeting with Henri, Marc travels to India to talk with the Hyderabad team members. The team members are very interested in what Marc has to say about the development of the QoS policies and user interface layer in Toulouse. They are also eager to show him the design for the architecture of the business layer that they have been drafting. Apparently, Janet had reassured the team that Marc would be interested in hearing the technical details of their work. They are reluctant to comment on the collaboration with Toulouse and Montréal. Marc observes that information tends to flow down hierarchically within this team. He next meets in private with Janet.

Marc thanks Janet for having her team members share their technical work with him and says that he can see that they are making good progress. After a few comments about how the team seems to respect and appreciate her leadership, Marc says, “Since your group is working on the middle layer of the Network Manager, you have double duty in determining the interfaces to your layer. This requires more communication with your group. How would you describe the communications with other development sites?”

Janet pauses and then asks, “Do you want my frank assessment or a more diplomatic description?”

“I want to know what is working and not working. Tell me as you see it,” Marc reassures her.

“OK. Communications with Toulouse are sporadic and strained. One week, I receive several calls from Toulouse with lots of pressure for us to release the current design of the business layer architecture to the shared repository; then the next week, I receive no responses to my e-mails or calls regarding the state of the business policy requirements,” Janet explains.

“Your team has made good progress on drafting an architecture for the business layer. The team clearly explained the architecture to me. Based on the agreed-upon requirements for QoS management, I think the design is sound thus far but would benefit by having it reviewed by engineers working on the user interface and network interface layers. Do you think that this might be a good time to release the draft documents?” asks Marc.

Janet responds enthusiastically but cautions, “Yes, I have encouraged my team to start the external review process, but the team members are reluctant to have others see ‘half-baked’ designs. They know that the designs may change as the requirements become clearer. They also sense that their designs would be under the microscope and that the value of their participation in the project is being judged.”

Marc then asks, “Why does the team call this an ‘external review’? After all, we are one project team even if we are geographically separated.”

“My team members feel as though they are outsiders. So, I am glad to hear you say that we are one project team. May I share your words with them?” Janet asks.

“Please do, and tell your team members that I will attend their next discussion with Toulouse,” Marc thoughtfully replies. “In fact, I will be looking for their design drafts in the repository.”

“By the way, how is collaboration with Montréal?” Marc inquires.

Janet more quickly replies, “Communications there are subdued and formal. When I inquired about the QoS algorithm development, Robert said that the algorithms cannot be released until the patent process is further along. We certainly understand and appreciate the value of intellectual property, but we are working for the same company. I think we signed nondisclosure forms at the beginning of our employment. I do not understand why there should be a problem with sharing the information within the company in order to accelerate product development.”

“Are there regularly scheduled meetings between your site and other sites to discuss open issues and to make design decisions?” Marc probes.

Janet answers, “No. I tried to establish weekly teleconferences between the people working on the interfaces to the business layer and to the network layer, but many of the meetings were canceled because of low attendance from the Toulouse and Montréal sites. At the meetings that we had, the Toulouse and Montréal people normally explained what they decided and asked whether we had any questions. There was little to no dialogue.”

Last Visit, Canada

After his meeting with Janet, Marc has some ideas about why his team is having problems with communications and collaboration. He hypothesizes that there are issues involving trust among the different sites. Hyderabad is in the middle because the software being developed there must interface with software being developed at both Toulouse and Montréal.

When Marc talks with the project members in Montréal, he commends them on their QoS research and on the innovative results that they have achieved. Marc notes that he is aware that many midnight hours have been spent getting this research into a form that can be commercialized. He explains the need to move quickly in getting the technology into the market place. He asks the team members to be catalysts in getting the interface to the network layer of the Network Manager designed. He also requests that they collaborate with the project members at other development sites who are designing the interface to the business layer.

Back in Robert’s office, Marc directly asks why the Montréal team members are reluctant to release the specifications for the QoS algorithms.

Robert reports, “We want to provide Hyderabad with the specifications but are concerned that the team there will make design decisions that will need to be redone since the description of the algorithms is not yet complete.”

Marc queries Robert regarding any concerns that his group may have about sharing information regarding intellectual property that is to be patented.

Robert emphatically states, “That is not the problem. We do not know what Hyderabad will do with the information. We have not had time to complete the documentation of the QoS algorithms or the instructions on how to incorporate these algorithms into the design of QoS policy management schemes.”

Marc then states that there are several excellent mathematicians on the team who are located in Hyderabad. He suggests that Robert involve these people in the review of the algorithms and preparation of instructions on their use. Marc says that this would help jump-start any learning needed to incorporate the algorithms into the design of the business layer software.

Then Robert says, “It is clear that the business decisions based on governmental policies will not be firm in time to meet the scheduled product release. So, why not fix a set that will work now? Why is Toulouse waiting for the ultimate solution? Couldn’t the India team design a business layer that can be evolved?”

Marc enthusiastically replied, “That is an excellent suggestion. Would you like to pitch this idea to Henri and Janet?” Marc smiles to himself. Apparently Robert was listening to Henri and Janet more closely than he originally thought.

Robert expands upon this idea, “The V Model shows that the software design is dependent on the software system requirements. The model appears to imply that specification and analysis of the software system requirements must be complete before starting the software system architecture.”

Robert continues, “Diagrams of the V Model present ideas that apply in general to particular phases of software development, but they do not illustrate how the ideas can still apply when phases are overlapped. Following the V Model for software development does not preclude decomposition of the system requirements and architecture blocks. We can work on aspects of the architecture that are related to system requirements that are stable. Decomposition along with decoupling of project tasks may allow more parallelism in task scheduling.”

“Yes, I have been wondering whether the tasks in the project’s critical path might be further decomposed and decoupled to reduce the path length,” Marc agrees. Then he adds, “On another note, I hear that the hardware manufacturing unit has held up the release of the hardware-software interface and drivers. What have you heard about this?”

“Yes they have, but this interface has not stopped our work on the architecture for the network software layer,” Robert confirms.

Reflections

On his flight back to Toulouse, Marc thinks about what he has heard from the three project managers. He identifies factors that he thinks may have influenced his team’s problems with communication, collaboration, and coordination. Marc records these factors in his engineering notebook and adds some notes. Next, Marc formulates questions that he needs to answer in order to better understand each factor’s influence. Table 10-2 shows Marc’s notes and questions for each factor. Marc suspects that the influence of each factor would differ if individual team members, rather than groups of team members, were dispersed.

Table 10-2: Marc’s Notes on Factors Influencing His Team’s Communication, Collaboration, and Coordination

Marc recalls the issues that were discussed among the project managers and technical leads early in the project. They had spent most of the time discussing the software system requirements and architecture. In conjunction with marketing, they had agreed upon an iterative and incremental development strategy in which the product would evolve as successive releases. The releases would build upon each other through refinement based upon user feedback and the addition of features. The development of each release would follow the typical progression of requirements, architecture and design, implementation, and test. The hardware product development managers pushed for the verification of the QoS algorithms using simulation rather than hardware prototyping. They said that the additional value provided by verification using hardware prototypes did not warrant the additional cost of building the prototypes or the increase in the time to market.

Marc reflects that they had spent little time discussing issues related specifically to the management of global software development. They had made the following decisions regarding communications across the distributed team.

Prior decisions regarding communications:

• Communications would be in English.

• The communication technologies would be Internet-based: e-mail, video conferencing, VoIP, and instant messaging.

• A central repository for sharing documents, code, and other software artifacts would be located at the Montréal site. The repository would support configuration control.

• The project managers would have Web cameras on their desks and use headsets. Each site would have a meeting room equipped with videoconferencing equipment for group discussions with the other sites.

Marc now realizes that they had not discussed nontechnical issues that affect communication and collaboration such as trust, cultural differences, time separation, and protocols for how to communicate and work together in a globally distributed environment. Everyone seemed to assume that the project task breakdown and schedule would be the primary plan for collaboration across the three sites and that the project managers would provide any other help with coordination that was needed. This assumption did not take into account other key factors that influence global communications and collaboration.

The next section in the case describes Marc’s own analysis of the problems that he must solve. The section also describes Marc’s rationale for the decisions that he makes to try to resolve these problems.

Case Problem

Marc knows that he must determine ways to improve the communications and collaboration across the globally distributed FibreNet Project. He thinks that tasks that require high degrees of collaboration, such as the specification of software interfaces for the layers in the Network Manager, are potential stumbling blocks in the schedule when there are breakdowns in communication and coordination. He realizes that special efforts are needed to ensure the appropriate levels of collaboration on these types of tasks.

Tasks in the critical path that are not on schedule because people do not have the information needed to work on them are alerts that there may be problems with communication or collaboration. For instance, the tasks requiring decisions about business policies dependent on government regulations and hardware interfaces are behind schedule. Some of these tasks could be more independent than shown by the current task breakdown and schedule, thus enabling them to be done in parallel or even in different releases. For instance, the requirements based upon government policies for now could be based on what is currently known, or product features based on these requirements could be incorporated into a later product release. The critical path probably should not contain tasks related to undecided government regulations.

In addition, Marc now knows that some of the team members do not communicate well in English. A change in the language for communicating across the team is not feasible because few of the team members located in Hyderabad speak French, but each site could select team members with the best English language skills to help interpret what is being said during joint meetings across the development sites. He is concerned that the team members at each site feel isolated. He thinks that, because of lack of knowledge, they do not trust what their colleagues at other sites are likely to do or not do with incomplete specifications. How can he guide the teams at different sites to work together more effectively?

First, Marc decides that he wants to talk with the project managers together about the problems that the project team is having with communications and collaboration. Should he spend more of his travel budget for Janet and Robert to come to Toulouse for an in-person meeting, or should he try to have the discussion via teleconference? From his recent experience in visiting each development site, Marc thinks that communications would be more open and that he would be able to lead the discussion more easily if they were to meet in person. In addition, Marc would like the project managers to formulate and adopt project policies for collaboration across development sites. He wants the project managers to enforce weekly meetings between the sites whose software interfaces with each other and expects that by meeting in person they will develop a better understanding of why the team members at each site have been having difficulty in doing this.

If the project managers come to Toulouse, Marc will hold a brainstorming session that includes people from marketing as well as some key customers to discuss the idea of “fixing” the business policies to be incorporated in the first release of the FibreNet product. If he can negotiate an agreement by the project stakeholders to reduce the product scope for this release, then he could work with the project managers while they are together to adjust the task breakdown and schedule to reduce the length of the critical path. Another option would be to postpone the support for policy-based QoS management to a future release of the software.

Based upon what the project stakeholders decide, Marc would like the project managers to analyze the task breakdown and schedule to find ways to get the project back on schedule without a substantial increase in cost. Reducing the scope by postponing the QoS policy management would certainly make this easier because the new hardware would not be needed until the next release of the product. Marc knows from experience that an initial in-person session is critical to these types of negotiations.

Marc decides to bring Robert and Janet to Toulouse for four days. In the meantime, he schedules a meeting between the project stakeholders in the area. Marc is convinced that central planning with local follow-up will help solve the problem that his team is having with communications and collaboration.

In his preparation for the project manager meeting, Marc again ponders the issue of trust. He thinks that there are no immediate solutions to the problems related to trust. Marc rationalizes that trust is established over time as team members work together to accomplish project objectives. Marc decides that a first step would be to get the team members at different development sites to work together to successfully accomplish project tasks. Another step would be to find opportunities to further collaboration so that the team members get to know their colleagues at other development sites. He decides to discuss the trust issue at the meeting and to suggest that the project managers find ways for team members across the development sites to have more interactions in which they get to know each other.

Results

The meetings in Toulouse were successful. The project managers and Marc had an open discussion of communication and coordination issues and were able to pinpoint factors that need to be controlled to facilitate cross-site collaboration. Later, each of the project managers discussed within their groups the importance of working closely with their colleagues at the other development sites. They explained that collaboration depends on the flow of information in both directions between the collaborators. The development sites moved forward with weekly meetings and co-designed the interfaces for the business and network layers. Robert talked with Janet about involving team members across their sites in the collaborative review of design specifications. Improvements in the detection of defects encouraged the two sites to continue this approach for component implementation as well as for the design of test plans.

The customers argued for the incorporation of a few core business policies that could be implemented using existing hardware. The first release was one month behind schedule but still on budget because of the reduction in scope related to the business policies. Communications between Toulouse and Hyderabad are still somewhat strained, but the two sites were able to complete the interface to the business layer on time with respect to a revised schedule.

Case Analysis

Analysis Activity

Analysis Background

Let’s use the PEAK model to analyze the problems related to communication, collaboration, coordination, and trust between the development sites because these are the ones that are particularly challenging for global software development projects. Project managers are likely to identify and understand these problems but may find it difficult to implement their solutions. You are welcome to analyze the problem of project tasks that depend upon information that is incomplete and likely to change.

(P) Problem: The FibreNet Project has encountered the following problems:

• Poor communication, collaboration, and coordination between the geographically distributed development sites has resulted in the delay of tasks involving collaboration on the design of interfaces to the business and network layers of the Network Manager system.

• Because of lack of knowledge about each other, the development sites do not trust what team members at other sites are able and likely to do. This has resulted in the reluctance to share and discuss design specifications that are not complete across the development sites. Each site is working in isolation with minimal collaboration with each other.

• Tasks dependent on decisions regarding business policies related to changing government regulations and hardware interfaces are behind schedule.

(E) Experience: From experience, Marc realizes that there needs to be a standard set of protocols for communication and collaboration that are applied across the development sites. He also knows that putting them into practice requires reinforcement by project leaders local to each site. If a particular means of communication is used most frequently, then these communication channels become critical to the successful completion of project deliverables. For instance, if two development sites coordinate primarily through weekly teleconferences, then it is imperative that these meetings result in the resolution of the critical issues. The meeting planners and moderators must keep the discussions focused on issues and decisions needed to satisfy the project objectives.

(A) Assumptions: Marc assumes that the project managers are able to provide the leadership needed to stimulate communication and collaboration between the development sites. He expects that they will lead the way in promoting collaboration on the designs of the interfaces to the business and network layers of the Network Manager software, once he has talked with them together about the issues related to managing coordination across globally distributed development sites. The options that Marc considers to solve the communication and collaboration problems are all based on his premise that the project managers will work with him to implement the solution to the problem. He also assumes that through in-person discussions the project managers are more likely to develop a camaraderie that will motivate them to work together in solving the communication, collaboration, and trust problems.

(K) Knowledge: From the comments of the project managers during the weekly status meetings and during his talks with them in person, Marc understands that the team members know very little about their colleagues at the other sites. They do not know what the other sites are likely to do with incomplete requirements or design specifications and are therefore reluctant to release specifications until they are complete. They also do not feel comfortable working with the other development sites to develop the specifications because they do not know how the people at the other sites will interpret the information that they contribute during these meetings. In particular, team members in Hyderabad feel as though their value to the project is being judged. They are cautious about contributing ideas during meetings with the other sites. Some of the sites also have difficulty understanding the English spoken by project members at another site.

Solution: Marc decides between an in-person meeting with the project managers in Toulouse and a teleconference. An in-person meeting would be more expensive but would enable Marc to more easily engage the project managers in open discussion of the communication and collaboration problem. Marc wants to impress upon the project managers the need for them to institute planned and timely meetings between the development sites whose project tasks must be accomplished through collaboration. While in Toulouse, the project managers also could help Marc negotiate a reduction in scope of the business policies to be supported in this release of the software and could work together in revising the schedule if the project stakeholders agree to some form of reduction in scope.

Assumed Risk: Marc presumes that the project managers are able and will provide the leadership needed locally to institute the improvements in communication, collaboration, and coordination. He expects the project managers to lead weekly meetings between their development sites to collaborate on project tasks. Marc can monitor the results of these meetings through his own conversations with the project managers, but there is a risk that the project managers may find that working to improve communication, collaboration, and coordination between their groups may take more time and energy than they have available.

Marc also assumes that after the in-person meeting, the project managers will be motivated to work together in promoting collaboration across their development sites. It is possible that the in-person meeting will not inspire the project managers to collaborate in solving the problem. How well the project managers work together in the future may depend more upon incentives that Marc provides as they go forward.

With an in-person meeting, the project managers will be away from their groups for about a week. Depending on the dynamics within each group and the current issues requiring input from the project manager, the absence of a project manager may negatively impact the progress that a group can make while the project manager is away.

Analysis Questions

1. Which factors that Marc listed in the case are affecting the communication, collaboration, and coordination between the global development sites? Describe the impact of each relevant factor.

2. What other factors do you think could be affecting the communication, collaboration, and coordination between the global development sites? Describe how these factors might be contributing to the problem.

3. What experiences have you had in which trust negatively or positively impacted the collaboration among team members? If you were one of the project managers, what would you decide to do to help minimize or resolve the trust issue?

4. What other solutions to the problems involving communication, collaboration, coordination, and trust would you have considered? Use the PEAK model to analyze and explain the value as well as the risks associated with each of your alternatives.

Discussion

Being new to global software development, Marc was not aware that communications, collaboration, and coordination often interfere with the successful achievement of objectives by globally distributed project teams. In the project planning phase, he thought about the means of communication across geographical distances; however, he did not consider the impact that factors such as trust, cultural differences, and geographical and time separation could have on communication, collaboration, and coordination across his globally distributed team. He has learned through firsthand experience that understanding and controlling how these factors affect communication can help project managers minimize the tendency for globally distributed groups to work in isolation rather than to collaborate and coordinate their work.

Marc has decided that the solution to the problem centers on the leadership that the project managers will provide to their teams regarding communication protocols and the need for collaborative and coordinated work across the development sites. Establishing an organizational culture of open communications and collaborative thinking usually starts from the top. Marc’s idea that the project managers will have to lead this effort at the development sites is reasonable since Marc cannot provide the necessary hands-on guidance at three geographically dispersed sites.

One might also expect that training may be needed in addition to leadership to help the team members understand the factors that affect communication and how to apply protocols that the project leaders or organization define for communications and collaborations. Lastly, there is the practical reality that the project managers may not have the time and energy required for effective leadership in this area. Marc should discuss these issues with the project managers at their meeting in Toulouse. The project managers should determine realistically what they can and cannot do and ask for help with training and planning for meetings across the development sites if they think that they need this.

Conclusions

Communication, collaboration, and coordination are essential elements of global software development. Factors such as trust, cultural differences, time separation, communication protocols, and planning are likely to influence communication, collaboration, and coordination more than the selected technology for communication. Project planners must make decisions about how much to spend on communication technology and travel between development sites. They should make decisions at the beginning of the project about the types and amount of communication, collaboration, and coordination that will be needed to complete the specific project deliverables. Establishing protocols for communication are useful but may require training and guidance to put them into practice.

Key Ideas to Remember

• Problems involving communication, collaboration, coordination, and trust are common to global software development.

• Decisions about how to communicate, collaborate, and coordinate in a global software development environment are equally, if not more, important than decisions about communication technologies.

• Planning for global software development projects should include the establishment of protocols for how to communicate, collaborate, and coordinate.

Case Study: Managing Global Software Development at FibOptia

Directions

When reading this case study, focus on the intricacies of managing process and product across global software development projects. Though not necessary, you may want to read “Globally Distributed Teams: FibreNet Project” first to establish more background for this case.

Case Summary

Description

FibOptia is developing the second version of a network management system (FibreNet II) to provide quality-of-service (QoS) for fiber-optic communications. The development of the system software continues to be globally distributed across development centers in Canada, France, and India. Lakshmi Singh, a new senior manager of software development for FibOptia, talks extensively with Marc Delancy, the senior software manager for the first version of the FibreNet product. Marc explains the challenges that he faced in managing globally distributed software development. Lakshmi now faces decisions about how to handle communication, collaboration, and coordination for the new project and about how to standardize the development and management processes used across the team. She is also deciding whether to engage a consultant to assist her team in achieving processes that are defined, established, and subject to improvement over time, a characteristic of an organization that has achieved a Capability Maturity Model Integration Level 3 (CMMI Product Team 2002). Lakshmi’s goal is for the project to serve as a test bed for improving the management of global software development at FibOptia.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Better understand the following issues in managing global development:

• Managing communication, collaboration, and coordination across a distributed team

• Managing process and product in a global development environment

• What it means to improve the management of global software development

• Examine how global development impacts the management of project decisions with respect to scope, time, quality, and cost.

• Explain the problems that occurred in the case scenario, the causes of the problems, some plausible solutions to the problems, and ways to eliminate the problems in the future or to reduce their impact. Relate these to the decisions faced by project stakeholders.

Subjects Covered

Communication and collaboration in global software development and managing product and process in a global development environment

Setting

The setting involves three software research and development centers of FibOptia, a company that develops network systems, applications, and services for fiber-optic communications. The centers are located in Hyderabad, India; Toulouse, France; and Montréal, Canada.

Key Concepts

• Collaboration in a global software development environment requires particular attention to communication and culture.

• Stationing representatives from remote sites with local team members promotes effective communication, cultural integration, collaboration, and coordination between globally distributed project sites.

• Managing process and product across globally distributed projects requires definitions of standard software processes and product quality requirements to be applied at all software development sites. Local control of process execution and product quality is critical.

Terminology

Agile software development processes: A group of software development methodologies that are based on similar principles. Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation; a leadership philosophy that encourages teamwork, self-organization, and accountability; a set of engineering best practices that allow for rapid delivery of high-quality software; and a business approach that aligns development with customer needs and company goals. Beck et al. (2001) describes the mission of agile software development. Fowler (2006) gives an overview of issues involving the use of agile software techniques.

Rational Unified Process (RUP): A software engineering process delivered through a Web-enabled, searchable knowledge base. The process enhances team productivity and delivers software best practices via guidelines, templates, and tool mentors for all critical software life-cycle activities. The knowledge base allows development teams to gain the full benefits of the industry-standard Unified Modeling Language (UML) (Rational 2001).

V Model of software development: A software development approach that focuses on the verification and validation (V&V) of a software system at each stage in the software development process. Two objectives to be accomplished by following a V Model is to discover defects in a software system as early as possible and to assess whether the system is usable in an operational situation (Graphical Development Process Assistant).

The Case

Scenario

The vice president of engineering has asked Marc Delancy, the senior software manager for the first release of the FibreNet product, to lead the planning team for the ongoing evolution of the FibreNet product. The mission of this team is to develop a strategy for the development of a FibreNet product line. One of the team’s deliverables will be a release plan for FibreNet II and FibreNet III. The vice president selected Marc to head this team because of the leadership that Marc demonstrated in negotiating the change in the scope of the first release of FibreNet to better align with changing governmental regulations and market conditions.

The senior software manager for the development of FibreNet II will be Lakshmi Singh. Lakshmi has managed several global software development projects at other companies. She worked in the past on several projects with Janet Kumar, who is currently the project manager for the development of FibreNet software in Hyderabad. Lakshmi and Robert Johnson, the software project manager for the part of the FibreNet team located in Montréal, were classmates in graduate school. Lakshmi met Marc last year at a telecommunications conference and talked with him extensively about FibOptia and the FibreNet product. When they later connected via a professional networking site on the Web, they were pleasantly surprised to find that they both had worked with Janet and Robert. After being asked to head up the product planning team, Marc recommended that Lakshmi be considered for his former position of senior software manager.

Lakshmi traveled to Toulouse to talk with Marc. The purpose of their meeting was twofold:

• To identify and resolve issues related to the smooth transition from one senior manager to another

• To transfer information about the development of FibreNet I that will help Lakshmi to succeed in managing the development of FibreNet II.

Management Transition Meeting

“Welcome to Toulouse!” Marc greeted Lakshmi in his office at FibOptia-Toulouse. “How was your flight?” Marc asked.

“Not bad. The service is still good for international flights,” Lakshmi replied. “I am glad that you suggested meeting on the day after my arrival. I was able to rest when I arrived and then walk around Toulouse to adjust to the time difference.”

“How often did you travel to Montréal and Hyderabad for the FibreNet Project?” Lakshmi asked.

“At first, I planned to visit both sites about every three months,” Marc replied. “But when I found that the development sites were having problems with communications and with the coordination of their work, I started to visit each site once a month until I could see that collaboration was improving. Another purpose of the monthly visits was to boost the team morale at each site,” Marc explained.

“Ah, yes. I too have seen that communication and collaboration can be difficult for software development teams,” Lakshmi commiserated. “You must have found some ways to get around these problems. Your team delivered a product that is doing well in the market. What magical wand did you wave to solve these problems?”

“Nothing magical, I assure you. Here is a list of my decisions that I think helped to solve the problems,” Marc replied and then handed Lakshmi the list.

“After each decision, I listed the results of implementing the decision,” Marc explained. See Table 10-3.

Table 10-3: Marc’s List of Decisions and Results

“It looks as though you made a lot of progress in a short time,” observed Lakshmi.

“Communication, collaboration, and coordination across the development sites had to improve, or we would not have been able to finish the product in time to satisfy the window of market opportunity. Entrepreneurs say that necessity breeds opportunity. In our case, I would say that necessity forced action,” Marc replied.

“Possibly, we can think of collaboration as an opportunity for increased innovation. What do you think that we need to improve in order to produce FibreNet II on time, within budget, and with the desired quality? In fact, what do we need to do better to develop a successful FibreNet product line?” Lakshmi asked.

“That is an insightful question,” Marc replied. He thought a moment and then said, “Let me give this some thought, and I will provide you later with more detail. But for now, how about if we discuss some areas that I have already considered?” Marc then pulled out his engineering notebook.

“This sounds good. I welcome your suggestions.” Lakshmi agreed.

“Effective communication and coordination across globally distributed teams requires local leadership, at least until the team develops its own culture of collaboration. The project managers have talked with their groups and have used the project tasks to motivate planned collaborations. But to establish an effective global development organization that can roll out product innovations in a timely way, we need some process improvements and changes in our development culture,” Marc explained.

“Trust is an ongoing issue. The team members at each site still do not know each other very well. The Hyderabad team members continue to listen but not speak much during their cross-site meetings,” Marc said.

“This may be because of differences in how authority is handled at the various development sites. The Hyderabad team members may think that their responsibility is to gather information and convey this information to their project leads or manager. They may not think that they have the authority to present their own ideas before having these ideas approved by their supervisors. Possibly the software engineers in Toulouse or Montréal feel more empowered to propose ideas without having to have them approved first,” Lakshmi explained.

“In other words, cultural differences with respect to dialogue and decision making may be affecting the way in which the team members across sites collaborate,” Marc summarized.

“Exactly,” Lakshmi confirmed. “In this particular case, the issue is probably not one of trust. It seems as though our team could use some training to understand cultural differences that affect their ability to dialogue and solve problems in a global work environment.” Marc smiled when Lakshmi said “our team.”

After observing a few of the cross-site meetings, I thought that “mixing up” the team would help promote understanding of how team members at other sites work and assist with communication during the group meetings. For example, we could bring some people from India to Canada and France, and so forth. Of course, housing people away from their homes for the duration of a project can be expensive,” Marc commented.

“Maybe we could place a liaison for each site at every other site. In other words, each development site would host one visitor from each other site or a total of two for the duration of the project,” Lakshmi reflected.

“At a minimum, there could be exchanges between Hyderabad and Montréal as well as Hyderabad and Toulouse since the Hyderabad team members need to work on tasks that require high degrees of communication with both sites. This plan would involve four rather than six temporary relocations of staff,” Marc replied.

“What software development processes are being used at each site?” Lakshmi asked.

“At the beginning of the FibreNet Project, we decided to follow a process involving incremental release of the product with iterative development for those parts of the software that we could obtain feedback from users. All of the sites have used the V Model to guide test planning, development, and execution. Different interpretations of this model across the sites did cause some coordination problems,” Marc replied.

“How did the interpretations differ, and what problems did this cause?” Lakshmi inquired.

“Hyderabad engineers thought that they should not have the design specification for the business layer software reviewed by the other sites until it was complete. Also, they were reluctant to work collaboratively on the interfaces to their software because there were decisions to be made regarding the required QoS service policies. The Montréal engineers working on the QoS algorithms were also reluctant to release the algorithms without full documentation because they were concerned that the software engineers working on the business layer software might not know how to interpret the algorithms. There seemed to be a general concern all around that partially complete project deliverables should not be reviewed, released, or even discussed across the development sites until they were complete, including the documentation,” Marc explained.

“How does this reluctance to share partially complete information relate to differing interpretations of the V Model?” Lakshmi inquired.

“In the case of Hyderabad, the software engineers interpreted the blocks in the diagram literally. When the model showed that the software system requirements are done before the software architectural design, they interpreted this to mean that all the requirements were to be specified and released before the architectural design could be reviewed outside the local group. In Montréal, the concern was simply that releasing the QoS algorithms before they were fully documented might lead to misinterpretation. In both situations, the team members did not see the value of reviewing those parts of a specification that are complete and of discussing the parts that are still evolving,” Marc replied.

“Are any of the development sites using the Rational Unified Process or Agile techniques?” Lakshmi asked.

“Yes, the user interface group in Toulouse has applied both of these techniques. These software engineers work directly with customers on the design of the user interface. They have found that use cases are helpful tools for describing requirements in a way that can be discussed with customers. They are comfortable with creating mock-ups of user interfaces that can be quickly modified in response to customer feedback,” Marc explained.

“How familiar are the team members at each site with the processes being used at the other sites?” Lakshmi probed.

“Other than the processes that were outlined in the project plans, such as iterative development and incremental release, no processes have been documented for use across the software development sites,” replied Marc.

“I am interested in helping FibOptia standardize and fine-tune the software product development and project management processes that it uses at the different development sites. FibOptia has made significant investments of capital to establish the three research and development sites, and I think global software development is here to stay. Therefore, we need to understand how to manage global software development effectively. Considering the speed at which new technologies emerge, effective management of global product development may differentiate us from other companies that develop telecommunications products and services,” Lakshmi commented.

“You might start by identifying and documenting the processes that were used to develop the first release of the FibreNet product and then continue with the FibreNet II project,” Marc suggested.

“That is exactly what I was thinking. That engineering notebook of yours will come in handy,” Lakshmi agreed.

“You may want to think about whether process formalization is a good idea for FibOptia at this stage in its organizational development. The people involved in managing product development at each site have not yet standardized the processes that they use for product development. Standardization across sites will be even more challenging,” Marc cautioned.

“That is a good point. As you said, we could start with the identification and documentation of the processes being used at each site. Engineers and managers need to know what their colleagues are doing both locally and globally,” Lakshmi replied.

“This could require significant time of the people who participate in the investigation. I found that planning and making collaboration happen required effort and therefore time. People are more likely to commit their time if the effort appears as tasks in the project schedule or as other organizationally recognized tasks for which they can receive credit. My advice is that you get buy-in for the process investigation from the vice president of engineering as well as budget to pay for the time that people spend on this,” Marc advised.

“Are you interested in submitting a proposal for this investigation with me? We could jointly propose this to the vice president of engineering to get some funds to pay for help that we would need from FibOptia staff and possibly some external consulting,” Lakshmi queried.

“Yes, I am interested in helping to get this effort off the ground; but with my new role as the lead for the FibreNet product-line strategy, I may not be able to commit much time to the investigation. From my experience with the first release of FibreNet, I know that you will be very busy getting the next release out the door. You will need to decide how much time that you think you could commit to this investigation. I recommend that you start small first. Possibly begin with one site such as Hyderabad where you will probably spend most your time, with one process area such as software development, and with only a few project managers and team leads. After managing the software development for a successful product release, you will have more leverage with upper-level management. By then, you will know people who may be willing to help with the investigation,” Marc suggested and then added, “Also, I should have my team organized and the development of the strategy for developing the FibreNet product line well underway. I would probably be able to provide more help at that time. I am going to be traveling frequently between Toulouse and Montréal during the next six months.”

“During my interview with the vice president of engineering, he stated his expectation that the senior manager for software development will lead the way in standardizing the software processes being used across the development sites. He said that you had enlightened upper-level management about the need to pay attention to communication, collaboration, and coordination issues across the development sites. The upper-level management is now interested in knowing how well we coordinate the way in which we do development across the sites. I think that I am expected to shed some light on this issue while being responsible for the development of the software for FibreNet II,” Lakshmi explained.

“I see . . . ,” Marc slowly replied.

No more was said about the process investigation issue. Marc and Lakshmi formulated a plan by which Marc would introduce Lakshmi at each of the development sites. They scheduled a regular meeting between the two of them to work on issues related to the requirements for FibreNet II. Marc reassured Lakshmi that he would help smooth the transition to a new senior software manager. Before Lakshmi flew back to India, Marc invited Lakshmi to dinner. Her comment about the vice president’s expectations had weighed on his mind, and he wanted to reassure her that he would provide whatever help that he could.

Over dinner, Marc told Lakshmi that he would be glad to talk with her about the decisions that she would need to make to handle this issue as well as those that she would need to make in planning for the next release of FibreNet. He explained that he found that it sometimes helped to have another manager’s viewpoint when evaluating decisions.

Reflection on Decisions to Be Made

Back in her new office at the FibOptia site in Hyderabad, Lakshmi reflected on what she had learned from Marc in Toulouse. She will soon be working with other project stakeholders on the schedule and budget for the development of software for the FibreNet II product. To effectively manage this global software effort, she will need to make some decisions to resolve issues that she knows exist.

One ongoing issue has been to improve the communications, collaboration, and coordination across the globally distributed development sites. Trust still seems to be an influential factor. What can Lakshmi do to help resolve or alleviate the impact of this issue for the development of the FibreNet II software? How will her choices affect the budget and schedule?

She brainstormed some ways to help improve communications, collaboration, and coordination across the development sites:

• Exchange project members between sites for the project duration. For example, relocate one project member from Montréal and one from Toulouse to India to help the Hyderabad team members work with the remote sites. Likewise, two team members from India could be relocated to Montréal and Toulouse, respectively. How many relocations would be most effective? Should there be at least one team member from each remote site at each local site (six relocations), or would some other arrangement be most effective from communications/collaboration and budget points of view?

• Eliminate any references to separate teams. The title for the group of staff who work on the FibreNet product could be the FibreNet Group or FibreNet Project for the current release. The names of the staff working in a particular location could be FibreNet Project, Hyderabad; FibreNet Project, Montréal; and FibreNet Project, Toulouse. What would need to be done to institutionalize this formally (upper-level management agreement, letterheads, and so on) as well as informally (in conversation)? What are the associated costs?

• Require project managers to incorporate team members who specify requirements, architecture, and design to participate in the review of acceptance, system, and component test plans and writers of test plans to participate in the review of specifications for requirements, architecture, and component design. How would this decision affect the task breakdown, schedule, and budget?

Which of these solutions, if any, should she select? Are there other ways to resolve this issue? Lakshmi pondered these questions and realized that she may need more information to answer them. Her mind drifted to the issue of the vice president of engineering’s expectation that she help standardize the software processes being used across the development sites. What did he expect her to do? What could she realistically do while managing the development of the software for FibreNet II. She faces multiple decisions that need to be made soon.

Case Problem

Lakshmi Singh will be the new senior software manager for the FibreNet II product development. She recognizes that communications, collaboration, and coordination are not working as well as they need across the globally distributed development sites to ensure the development of products on time, within budget, and with the required levels of quality. There is an ongoing issue of trust among the team members at different development sites. The vice president of engineering has assigned Lakshmi the responsibility for leading the standardization of software processes used across the different development sites. He expects that she will do this while managing the software development for FibreNet II.

Case Analysis

Analysis Activity

Analysis Questions

1. Use the PEAK model to evaluate each of the ways that Lakshmi has considered in order to help improve communications, collaboration, and coordination across the global development sites.

For each way that Lakshmi has considered, do the following:

• Describe any information that you think is missing to be able to fully evaluate it using the PEAK model.

• List any of assumptions that you think Lakshmi has about its usefulness.

• What are the risks, if any, associated with each approach?

• Decide whether you would apply it for the FibreNet II Project. Use your application of the PEAK model to explain your rationale for each decision.

For questions 2 and 3, suppose that Lakshmi decides to relocate team members as liaisons to assist with communication and collaboration at remote sites.

2. Which arrangement of relocations would you consider and why? (For example, each site would host precisely one team member from each of the other sites.) Discuss the pros/cons of each arrangement in terms of trade-offs involving schedule, budget, product quality, and any other issues that you think are important.

3. Which arrangement would you ultimately select?

• Explain the rationale for your decision.

• Discuss other information that you would like to have had (but did not) before making this decision.

• List any assumptions associated with your decision.

• Describe any risks associated with your decision.

4. Discuss any other ways that you think might help to improve communication, collaboration, and coordination across the global development sites.

5. If you were in Lakshmi’s position, how would you handle the vice president’s statement that he expects Lakshmi to lead the standardization of software processes across the development sites?

• Formulate your ideas in terms of problem statements with alternative solutions.

• Use the PEAK model to evaluate each alternative solution.

6. Describe any other problems or decisions specifically related to global software development, rather than to software development in general, that you think Lakshmi will face in the FibreNet II Project.