1 Introduction

Software engineering is witnessing a transition from the traditional co-located form of development to a format in which global software teams collaborate across national borders. Research increasingly reports about projects developed between the USA and India [8] as well as other continents such as Asia and Europe [3]. Findings emphasise major problems in communication and coordination, activities that are critical during early phases of strategic planning, requirements gathering, analysis and negotiation.

Research has yet to address the requirements engineering (RE) challenges faced by multi-site organisations. Previous reports only describe global projects where the requirements gathering and analysis were performed during face-to-face meetings at the client site, and where the analyst communicates the information back to the development staff [11]. It is equally important to understand the impact of distance in projects where cross-functional stakeholder teams define the software requirements in global structures; global organisations face challenges in enabling effective ongoing communication between headquarters and remote development sites. Organisations often don't have the luxury of arranging face-to-face requirements meetings on an ongoing basis. As a result, distance may exacerbate fundamental RE problems such as poor communication among stakeholders, as well as those problems due to factors of a political, organisational and social nature.

While recent research has investigated distributed requirements negotiations in a controlled setting [6], more evidence needs to be gathered in the software industry about multi-site organisations and RE at a distance. Given the relative novelty of the phenomenon and the paucity of research done in this area, it is important to conduct field investigations to understand the impact of problems of communication and coordination in RE activities, to identify challenges faced by multi-site organisations, and to formulate recommendations to overcome distances.

In this paper we report our findings of RE activities performed at a multi-site development organisation where groups of customers, product management and development collaborate from remote locations. Background information on the organisation and the distributed processes is presented in a later section. All names are fictitious to preserve confidentiality. Empirical findings are further described in the form of a model of the impact of geographical distribution on RE activities. This model is used further in formulating recommendations for improved practice. The paper concludes with future research directions outlined in the last section.

2 The research question and methodology

The research question that motivated this study was "what is the impact of stakeholders' geographical distributions on RE activities in global software development?" The goal was to understand how requirements are developed in multi-site development organisations, and to understand the challenges faced and the strategies and technologies used to overcome these challenges.

The research methodology was grounded theory [14] applied in a case study [16]. The first author spent seven months at the organisation's development site in Sydney, Australia, between July 2001 and February 2002. Data collection methods included inspections of documents, observations of requirements meetings and semi-structured interviews with twenty-four stakeholders ranging from product management, product and development engineering, customer support management, team leaders and software engineers, across four sites in the USA, three in Australia, one in New Zealand, and one in Europe. The interviews were guided by questions such as: "what challenges do you face in managing requirements in the distributed setting?", "which challenge is the most significant and requires urgent improvement?" and "which technologies are used to overcome distance?"

Checkland's soft system methodology (SSM) [4] was used in the analysis of the situation in which requirements were developed. SSM provided a powerful mechanism that considered the wider organisational context in identifying the requirements negotiation space in studies of distributed RE [5]. Work and behaviour in multi-disciplinary teams is complex and distance further contributes to increased complexity in organisational processes. Here, SSM was used as a means of identifying the stakeholders and their objectives, power structures and requirements conflicts in the RE process. Initial interviews were held with senior management in the development organisation in Australia, to learn about project characteristics and relevant stakeholder groups involved in the requirements negotiations, from Australia, US and customer sites worldwide. The project owner and sponsor and relevant actors were identified. The next step was to interview the project owner (a member of the product management group in the USA), and to learn about the project goals and role of the communication with the development group in Australia in specifying and negotiating the requirements. The subsequent interviews with groups of stakeholders in the different functional areas involved in the RE process revealed rich information about the different stakeholders' viewpoints on product requirements; they were analysed and understood in the light of stakeholders' objectives as motivated by belonging to a particular functional group.

Grounded theory techniques [14] were used in a comparative analysis of interview data within each stakeholder group and from different stakeholder groups. Continued investigations over several months prompted a return to certain stakeholders to conduct further interviews to compare "backwards" aspects identified in other interviews. During this period, efforts were made to avoid "going native", and losing an investigator's objectivity. What had to be avoided was the belief that all RE problems observed were due to distance. Often the field investigator had to step back and try to answer underlying questions such as "how is this activity affected by distance?" and "would it be different if stakeholders were co-located?"

3 Company background

Global Development Systems (GDS) is a large, multi-site corporation that has its headquarters in the USA with global teams developing software applications. In this case study, we investigated a project where requirements gathering, strategic planning and requirements negotiation, development, testing and integration occurred in distributed structures. The software produced is product line software, characterised by the delivery of a series of releases. Each release is around 8000KLOC, with a development time between 12–18 months, and with approximately 120 full-time developers involved. The software is an enterprise software, of which customers are themselves developers, using the system for developing software. The features for a new release are derived from an analysis of the current release and ongoing business strategies.

3.1 Stakeholder roles, geographical distribution and power structures

At GDS, key stakeholder groups are scattered across several continents, as illustrated in Fig. 1. The product strategy is directed from the USA, where the product and program management group—referred as the business management (BM) group henceforth—is located across four locations. The development group is located in three Australian locations and one New Zealand location, and customers are grouped in five large market segments across five continents. In addressing the geographical distribution of customers worldwide, the organisation maintains on-site field support centres, to provide services to the diverse market segments.

Fig. 1.
figure 1

A geographical distribution of stakeholder groups. ★ Customer market segment and field support centres; ● Development site; ■ BM members involved in the requirements negotiations

Full size image

Figure 2 illustrates the requirements information flow in the project. BM acts as a "hub" and gathers requirements from multiple sources including targeted customers, field personnel, contents of an in-house developed requirements database and user groups. This information is combined with a knowledge of business strategy, and a document containing marketing requirements (MR) is prepared, representing the object of early strategic planning and requirements negotiations between headquarters in the USA and development management (DM) in Australia. Difficulties in achieving a common understanding and prioritisation of requirements, as described later, led to the development of a detailed requirements specification (RS) which describes the technical requirements associated with each new feature (as suggested in MR); the RS is developed by developers, and sent for review and feedback to BM, as a vehicle in decision making. In these negotiations, the following power groups exist:

Fig. 2.
figure 2

The requirements information flow in the project

Full size image

  • BM in the USA, which provides financial and strategic directions in the project. One project owner, who can cancel the project, and three project shareholders are involved in the requirements negotiations with development management.

  • The development group located in several sites in Australia and New Zealand. One project manager and DM members are involved in the requirements negotiations with the headquarters in the USA, contributing with detailed technical knowledge and feasibility estimates.

  • Field support centres at worldwide locations. They are not involved in the requirements negotiations, although they posses a detailed knowledge of customer requirements and market trends.

Hence, BM became a surrogate customer for the developers in Australia and the need for an effective collaboration with DM emerged as critical in order to meet commitments made to the customers.

In this context, the findings of this field investigation centre around significant difficulties to achieve an effective collaboration of geographically remote stakeholders in negotiating a set of requirements that satisfies a diverse and geographically distributed customer market. Several collaboration technologies were used in overcoming distance and they are described in the next section.

3.2 Collaboration technologies in distributed RE

Global teams cope with distance by using a variety of media, ranging from phone, video conferencing, email and groupware, depending upon what tools are available [3]. GDS uses a mix of synchronous and asynchronous tools in requirements-related communication. Customers and support centres communicate requests for new features via the in-house developed requirements database. Rich synchronous media (bi-weekly teleconferencing calls) are used in the communication across continents of BM between field support centres, between field support centres and DM, and between DM and BM, in decision-making. These formal meetings are complemented by phone calls and email between key stakeholders. It is important to note that the four BM members are located across three locations in the USA, and hence their communication media is phone and email. Furthermore, the developers in Australia use phone and Internet technologies (NetMeeting and Web video broadcasting) in an innovative manner for "requirements capture" sessions on a weekly basis. The use of the latter two is described in detail below.

3.2.1 Simply email

At GDS, email is the dominant asynchronous tool because of the time difference and its role in exchanging documents, e.g., versions of RS. However, email presents both advantages and disadvantages in requirements management.

Advantages included the ability to explain the details of a requirement, and to provide a written record and history of issues related to requirements, together with an increased communication ability for non-fluent English speakers, in particular customers. While email was beneficial in providing input from diverse stakeholders irrespective of geographical location, it also allowed covert communication which led to challenges in managing requirements conflicts, as will be discussed in a later section. Furthermore, email was found weak in managing ambiguous information about requirements. Email's lack of interactivity results in a lowered ability to handle ambiguity, i.e., "in response to a requirement, you may type two pages of an answer, and in fact address the wrong problem"Footnote 1Emails can "get 'lost' or 'forgotten' ... thus issues remain unresolved, and requirements come back later and bite you at the end". Email also provides no indication when an electronic answer will come back, i.e., "you're forced to rely on individual work styles and this may introduce significant delay in resolving requirements issues.".

3.2.2 Rich multimedia for collaborative requirements analysis

The development of technical requirements for each feature is done during "requirements capture" sessions at the development site in Sydney. To support the collaboration of both local and remote developers, an integration of computer technologies is used in these group sessions.

As illustrated in Fig. 3, audio, video and data channels are used in the communication with the remote developers (on average two remote developers at two sites, in Australia and New Zealand). Microsoft PowerPoint is used to construct context diagrams that identify interrelationships that may exist in the system design as a result of implementing the feature, and Excel forms to capture newly developed technical requirements. NetMeeting is used to share these applications across distances.

Fig. 3.
figure 3

Rich communication media for collaborative requirements analysis

Full size image

The electronic documents are created collaboratively, with real time access from the remote sites, while the audio channel is provided through a teleconferencing call; an awareness of the participants at the Sydney site is increased through a video image capturing the Sydney location and displayed on the organisation intranet Web site (see the right side of the screen in Fig. 3). Real-time sharing of work artefacts is challenging in distributed collaborative task activities, and developers (thirty-nine) involved in these group sessions provided an extremely positive response to the use of collaborative technology in this setting.

Together with these generic collaborative technologies, one RE-specific tool used is the Rational Corporstion's RequisitePro. The captured requirements are imported to RequisitePro and an RS is generated. Within the development group, the project members can access the current versions of the RS through a configuration management tool. Furthermore, notices about features being captured are communicated through an intranet tool that serves as a repository for project-related documentation.

4 RE challenges due to distance

Our findings are described in the form of a model of RE challenges due to the geographical distribution of stakeholders, illustrated in Fig. 4. In the model, the top layer describes what we identified to be four major problems of the geographical distribution of stakeholders. They correspond to findings of previous research of global software development [8]:

Fig. 4.
figure 4

A model of the impact and the affected RE activities due to problems of cultural diversity, inadequate communication, knowledge management and time differences in global software development

Full size image

  • Inadequate communication. Distance introduces barriers to informal and face-to-face communication, and the stakeholders' communication is dependent on the quality of using synchronous or asynchronous electronic communication tools. In this study, interest groups (customers, business management, and developers) did not communicate effectively and each sought to exert power and influence over the others.

  • Knowledge management. The sheer quantity of information about requirements from multiple sources at remote customer sites was not appropriately shared with the developers. Moreover, by channeling the information about business strategy requirements to developers through a key stakeholder (a development manager) distance was exploited to strengthen certain positions of power in the organisation.

  • Cultural diversity. Differences in stakeholders' languages and national cultures affect global collaboration. Equally important in this study was the impact of differences in organisational and functional cultures. Not only did remote sites develop their own organisational cultures, but also the distance widened the gap between the different functional departments of the organisation (marketing, business management and development). This had a significant impact on achieving a common understanding and promoting a negotiation of requirements.

  • Time difference. The large distribution of stakeholders across five continents introduced large time-zone differences and allowed little available overlap for synchronous collaboration. Hence, asynchronous channels were predominant in the communication, complemented by teleconferencing calls. Synchronous meetings across continents are always awkward for at least one site—either too early or too late in the day, and involve someone having to compromise on his work schedule.

These "generic" problems had created specific difficulties in conducting RE activities and they are described in the second layer of the model. These "challenges" were arranged and labelled correspondingly to provide a minimal but meaningful array of distinct and yet possibly overlapping categories. They are described in the next sections, one by one (left to right in Fig. 4), together with their impact on RE activities (as outlined in the third layer of the model). The model describes a complex phenomenon, and its arrows show only direct relationships between problems and challenges in the first and second layer, respectively.

4.1 Diversity in customer culture and business

Although managing requirements from a large customer base is a fundamental problem in RE, at GDS geographical distribution exacerbated the problems associated with a large (and conflicting) set of requirements created by the use of the system in diverse markets, and national and organisational cultures.

Firstly, the customers' language is a critical factor that directly impacts activities such as requirements elicitation and validation, since language barriers affect the transfer of knowledge of requirements to field personnel and developers. For example, the field personnel and developers had difficulties understanding and checking back about the meaning of particular requirements, since English was the customers' second language. Additional challenges emerge at several levels: market trends may differ by market segment; differences in national culture often lead to requirements being meaningful only in the context of certain cultural beliefs and values. For instance, customers from some countries valued stability and asked for a requirement only because it was in previous releases, when other clients favoured new features in the system for continuous progress. Furthermore, distance increases the likelihood of diversity in corporate cultures, i.e., system usage in an existing methodology.

These factors contributed to GDS facing a fundamental problem in RE [13]: requirements being expressed using diverse terminologies and diverse levels of detail, thus making the analysis for conflicts and redundancies difficult. This represents one cause for the most significant challenge in this global organisation: the prioritisation and negotiation of customer requirements for a particular release, in the context of specific business and strategy requirements and limited development resources. At GDS, pinning down requirements stands as a real challenge because of the difficulty of making trade-offs on a large list of diverse requirements in the face of uncertainty. Although models of market-driven RE processes that promote good communication with marketing departments in the prioritisation of requirements exist [12], the application of these models at GDS is problematic due to the lack of appropriate communication with field personnel, as described next.

4.2 Achieving an appropriate participation of system users and field personnel

Not only did the geographical distribution of customers encourage a diversity in requirements, but the geographical distribution also represented a significant barrier to interactions between development and system users, affecting the developers' involvement in the gathering, analysis, prototyping and validation of requirements. AT GDS, part of the problem is that the RE process does not require users' active involvement in the specification of requirements. However, distance puts a barrier on removing these organisational problems if there was an interest in the customer's being involved. The large time difference between Australia and most other places in the world puts an additional constraint on any interaction with the customers. For example, one field manager said that his attempts to facilitate a close interaction between developers and system users failed because of the large geographical distance, i.e., "if the engineers were closer to us, I would develop a 'visit your customer' plan".

In this situation developers need to rely heavily on indirect communication with customers in eliciting and examining the current system. This is done through BM and field personnel, creating the fundamental problem of the misinterpretation of, and distorted information about, requirements. Because new features are mostly enhancements to existing functionality and examining the current system in the users' environment is not feasible, indirect sources of requirements lead to a lack of understanding of the rationale behind requirements and the ways in which users are using a particular functionality.

Furthermore, the absence of field personnel is felt in the formal bi-weekly decision-making meetings between BM and DM. Although one BM member is acting as a liaison between engineering and customers, communication problems exacerbate the impact of the differences in functional cultures and causes difficulties in managing uncertainty, requirements prioritisation and negotiation.

4.3 A lack of informal communication and a diminished awareness of the local working context

One of the most striking features of distributed groups is the lack of informal communication, i.e., spontaneous and "corridor talk" conversation [8]. Stakeholders have diminished opportunities to know "what is going on at the other site", because of an insufficient familiarity with the activities of remote group members and background information that make work contexts meaningful.

At GDS, for instance, the reaction to a requirement-related issue is propagated much quicker locally, through informal communication, than across sites. Requirements-related communication between remote sites is mostly done through "formal" channels, i.e., the bi-weekly meetings, when the communication is focused on urgent issues and leaves little room for small talk. Outside these meetings, the communication between BM and development is channeled through one development manager—by email or phone, when improper knowledge management techniques make the communication between developers and BM suffer. Further, a reliance on asynchronous channels allowed the possibility of issues identified at one site, small or big —which may crop up on a daily basis—to go unrecognised at the other site, and to thus stay unresolved for a long time (see the section on the disadvantages of email).

At the same time, informal communication within one site has a positive impact on the local negotiation process. Developers indicated that, whenever there is the need to address requirements-related issues, not only it is easy to walk to someone's desk but also there is more of a minute-by-minute understanding of people's reactions to what one says, so one can easily adjust what is being discussed. Moreover, the knowledge of a local working context provides someone with an indication of someone's position, beneficial in negotiations. The interaction on a daily basis has also a natural effect: the creation of coalitions. Cohesion is more difficult for cross-cultural teams [1], groups at one site developing a shared view and relating more easily to issues being discussed during formal decision–making. At GDS, a psychological separation between the development group and BM occurred, expressed in feelings of "us versus them".

To make matters worse, a lack of informal communication and ineffective knowledge management across sites does not blend well with differences in organisational culture. A direct consequence was the difficulty in having accurate information about roles and expectations in the RE process. For example, a lack of clear guidance on the requirements process at GDS led to the Australian development group following its own customised RE process. Due to inadequate communication between the US and Australian sites, neither this process and terminology, nor the rigor in developing the requirements was fully understood by BM. For instance, when not enough information was communicated following a review of RS, this not only resulted in BM showing an insufficient appreciation of the development's effort and the processes followed to produce the RE artefacts, but also in the developers not fully appreciating the pressures and the business context in which BM operates in the USA. This led to a misinterpretation of actions, due to stereotyping about cultures and working styles. It often generated negative attitudes, exacerbated by existing conflicts due to political struggles, and hence changed the atmosphere of the negotiations. Another example is the use of words in a particular organisational culture; here, the developers used "shall" and "will" differently from BM, a fact that generated misunderstandings in the validation and specification of requirements.

At the same time, findings reveal an interesting effect of distance: as one stakeholder observed, this lack of awareness might in fact have worked in favour of the developers, in that it allowed them to function away from distractions, and at the same time gave them power in the communication on estimates: "if product management was co-located, they would have known better about the feasibility estimates." This example introduces into the picture the aspect of trust between remote stakeholders, and which is treated separately in the next section.

4.3.1 Informal communication within the development group

Based on previous research [7], we expected that a lack of informal communication would also affect the communication within the developers group, where some team leaders were in New Zealand, remote from their team in Australia. However, we did not find supporting evidence. Our findings suggest that work at a distance had no impact on how requirements or changes were communicated and coordinated among the developers in Australia and New Zealand. Factors of success in overcoming the challenges of diminished informal communication in dealing with requirements include high technical competence and expertise, an excellent knowledge of the system gained through long service in the organisation, visits to the main development site in the past, and established working relationships with other developers through frequent interaction, excellent e-communication skills through daily telephone or email—and that the time difference does not restrict the communication window as much as it does with other parts of the world.

The only problem reported in the communication with the remote developers, however minor, was the difficulty to share, with remote developers, drawings on a whiteboard during spontaneous discussions that developers often have near their workspaces.

4.4 A reduced level of trust

While co-located teams can build trust through formal and informal face-to-face interactions, distance is an impediment to building trust relationships [3]. The role of the "coffee talk" is important again, as one stakeholder simply put it "at [a] distance it is harder to become a team... you would like to talk to [other key stakeholders] more often with a cup of coffee; you need to know each other personally to trust each other, to see the value of a person, to become engaged and committed, to follow the same agenda."

Like a co-located team, a distributed team develops trust slowly as it progresses through the evolutionary stages of working together, in the stages of forming-storming-norming-performing [15]. At GDS, while trust relationships existed for some team members due to involvement in past projects, it was a clear challenge for some newly assigned team members. For the latter, for instance, the early stages of group development coincided with the early stages of software development, when the team had to define requirements while managing significant uncertainty in the project, and where the trust relationships were critical.

As a result, cross-site negotiation and prioritisation meetings were characterised by extra caution and consciousness in making commitments, which some described as "guarding themselves against things that may be taken to their disadvantage", as well as by a reduced level of trust in arguments, i.e., "was there a hidden agenda?" Managing uncertainty was difficult because often the information was left deliberately ambiguous. For example, the fear of scrutiny led to restricted information about development estimates being communicated by DM, damaging the level of trust across sites.

Some new members abandoned attending regular requirements meetings, as these meetings were perceived as ineffective in managing uncertainty. Others had no choice but to stay in the game, for example, the project manager. His case presents a clear example of where the lack of personal relationships with the remote stakeholders had a significant effect on the level of trust showed to his work and contributions to the RE process. He was new to the organisation and hence his previous working relationships with the remote stakeholders were completely non-existent; that made it extremely difficult for him to "manage" the diverse demands on the projects and to gain trust in his work and arguments. His attempts to customise the requirements process to both serve the needs of the development team in their analysis of high-level requirements as well as conform to the organisation's process guidelines were received by the BM group with scepticism.

Interestingly, while "trust" was a word often heard in the interviews with the Australian group, for the American stakeholders trust was not an issue. While it is clear that this is due to some sort of cultural difference, one may believe that it is a matter of national or functional culture differences. We leave it to future research to find the answer.

4.5 Difficulties in managing conflict and having open discussions of interests

Distance makes it more difficult to deal with problems of an organisational, political and social nature. As one engineering manager noted: "it's hard to do strategic thinking at a distance, to bring everyone on the same page...if you get all stakeholders on a three-day conference to do strategic planning, you'd save months of bi-weekly requirements calls".

One of the most reported challenges was the ability to deal with the different and most often conflicting interests in the development. While this is a fundamental problem in requirements engineering [10, 13], distance makes it more difficult to manage conflict. At GDS, the context was such that different demands were placed on development, and distance diminished the ability to openly discuss the different stakeholders' interests. For instance, requirements expressed by customers often were not aligned with the business requirements, and decision meetings, unfortunately, did not include a representative sample from these groups to resolve these conflicts.

The negotiation of trade-offs in an open forum is difficult enough in co-located development, and it is significantly dependent on the quality of the stakeholders' communication and knowledge management techniques in distributed structures. At GDS, the problem is largely because of the inadequate channeling and the inadequate management of preferences and expectations. Not only are demands generated from different sources, but also often interests are channeled through lateral communication to key stakeholders. For example, the communication of requirements as a result of some stakeholders' hidden agenda is not done publicly—but by use of private email messages or telephone calls. The large time-zone difference has an impact in that the time window available for phone calls to discuss emergent issues is too short. Most often these issues do not surface during formal decision-making teleconferencing calls (and when they do, the mute button is too often used), making them stay dormant for long time, contributing to even more conflict. As a consequence, there is a perception that unresolved conflicts have perpetuated along the years, only damaging the relationship between the distributed stakeholders. At GDS this had a direct impact on the ability to elicit hidden requirements and to manage inherent uncertainties, ultimately damaging the communication between remote stakeholders.

4.5.1 Difficulty in achieving a common understanding of requirements

Another major problem in the remote stakeholders' collaboration at GDS was the difficulty in achieving a common understanding of requirements. Because BM acted as the "surrogate customer" the project suffered from the classical problem of the communication gap between customers and developers [2, 9]. When asked to provide development estimates based on the early MR, developers found the level of detail provided by BM as insufficient and the MR itself as difficult to use as a vehicle for decision making, prioritisation or negotiation. The difference in functional culture became clear: developers were asking for detailed technical specifications when this information was not available to BM. This triggered the so-called "requirements capture" sessions (described in an earlier section) as part of a customised requirements process, of which the results (technical requirements) were captured in RS and sent for review to BM.

However, documentation became the only communication means between "customers" and developers, when richer interactions were needed for a better understanding of requirements. Problems of ineffective knowledge management were felt throughout the negotiation period. Firstly, developers were not involved in the bi-weekly cross-continental requirements decision-making meetings. This resulted in decisions and information about business requirements being communicated to the developers through one person, a development manager. Furthermore, mainly because of the large time-zone difference between the USA and Australia, members of BM were not involved in these requirements capture sessions. This impacted significantly the examination of the current system that was done during these sessions; the developers noted unanimously that the BM's knowledge of business and user requirements would significantly improve the common understanding of requirements and saved time on trying to guess what the actual rationale or meaning of requirements were. This also resulted in BM finding it difficult to comprehend the sheer quantity of detailed requirements that were developed without their direct involvement.

It is not surprising then, that the specification produced on one side, with the ambitious goal of sharing technical knowledge and expertise, and of aiding in the prioritisation, validation and negotiation of requirements with BM failed.

4.6 Ineffective decision-making meetings

In this project, decisions on requirements were made through formal requirements meetings between BM and DM. What adds to their importance is that they are a valuable resource in the analysis of both the features and technical requirements, and in discussing the current usage of the system. Hence, they are perceived to be equally important and challenging.

Firstly, there is a fair degree of pressure in setting up these meetings. They require the invitation of key decision makers. There is the need to send supporting documents to all stakeholders well ahead of the meeting, and to express yourself concisely and clearly: not do only these people have busy schedules, but also the small time overlap between the continents limits the time available to address issues gathered before (i.e., during at least a couple of weeks). While all these seem like introducing overhead when compared to organising meetings in co-located teams, some participants noted that these issues might be beneficial in the process.

Secondly, communication and knowledge management problems impinge on the effectiveness of these meetings and most of the challenges discussed above are directly related to the quality of these meetings. When asked which of the challenges of distance to address first in our research, the response was almost unanimous: "improve requirements meetings!".

Part of the problem is the communication medium used in these meetings. Unlike the "requirements capture" sessions, less rich collaborative technologies are used here. Teleconferencing is the main medium that bridges four separate locations. The lack of visual contact contributes to a lowered awareness of presence and group behaviour at the remote sites. Participants can join the group at later times and, without a good facilitator, their presence might not be announced. This leads to problems in knowing who can be addressed with regards to a particular issue, and thus effective participation is diminished. The mute button is also naturally used, and adds to the creation of coalitions, damaging the already low possibility of having open negotiations. Furthermore, there is no means of synchronously creating and sharing work artefacts. Access to a whiteboard for sketching ideas is limited to one site with no ability for collaboration. Hard-copy documents such as the RS are used as vehicles for discussion and decisions. However, distance makes it more difficult to detect differences in shared hard-copy documents, i.e., page numbering. This often led to a lowered level of participation in discussions/decisions about requirements (due to attention being paid to locating such requirements!).

Another interesting aspect observed in these meetings was the need to access supporting documents that contained information relevant to requirements, such as email messages or documents received from the customers. Questions such as "what do we know about this requirement?" or "Have we discussed it before?" addressed the information from customers and the market; the lack of a repository storing the history of issues regarding a particular requirement resulted in issues and decisions being revisited and delayed for weeks.

Although the communication and knowledge management aspects of these meetings are critical and exacerbated by distance, there are other aspects that contribute to meetings' effectiveness. They are of a human, social, organisational and management nature: factors such as a timely exchange of documents to allow meeting material reading, an adequate stakeholder preparation for the meetings, dominance by some group members, and, ultimately, following an agenda are as important as those discussed above. As one manager put it, "if you don't have an agenda it is often too easy to attend to the most recent customer complaint or requirement, rather than having a strategic discussion of 'where is the product going?'"

Last but not least, it is important to note the impact of several other challenges described above about the quality of these meetings. Since most of these meetings centre around discussing which requirements to include in the current release, the lack of a common understanding of requirements, the low level of trust between the sites and the difficulty in openly discussing interests all affect the effective negotiation and prioritisation of requirements for the current release. For example, the development group often lacked detailed knowledge of marketing requirements and BM's expressions of preferences in the requirements prioritisation process was often received with a grain of salt; there was a question whether these preferences were genuine concerns for the customers or only serving personal agendas.

4.7 Delay

Speed is regarded as one of the most important success factors in modern high technology businesses, and it is becoming of concern in global software development [7]. At GDS, whenever requirements-related issues arose that required cross-site communication, options included sending an email, making a phone call or waiting for a formal requirements meeting to take place. Although delay was not reported as an impediment to communication across the US sites, it was a major concern for the development site in Australia. One explanation is the difference in time zones. BM members reported that they spend 2–3 hours in a row in discussing requirements. Synchronous communication is good in resolving misunderstandings and small issues before they become bigger problems. Due to a larger time difference, however, this is limited to the communication across continents; development engineers need to rely mostly on asynchronous communication, which leads to situations where "a small issue with a requirement can take days [of] back-and-forth discussions over email to resolve, if not complicated."

A significant impact was observed on the requirements negotiation and prioritisation activity. The ineffectiveness of formal decision-making meetings combined with the use of email in resolving issues led to decisions being delayed and issues remaining unresolved longer than necessary. For instance, at the time of this research report, the list of features being considered in the current release is still being negotiated, six months beyond the proposed deadline.

5 Discussion

This case study identified challenges created by inadequate communication, cultural diversity, ineffective knowledge management and time differences, arranged in a three-layer model. The case study further revealed that distance plays a significant role in exacerbating problems of a human, organisational and political nature.

Examining this model reveals an important result: that the inadequate communication in global structures creates most challenges (Fig. 4). It contributes to seven out of the eight challenges identified in the second layer in the model. This indicates that the practice of aiming to improve the communication between remote stakeholders will have the greatest effect in reducing the impact of global collaboration on managing requirements in multi-site organisations.

Similarly, a closer look at the second layer in the model identifies that the four major problems contribute mostly to the challenge of achieving a common understanding of requirements (associated with the maximum number of arrows, four in Fig. 4). In addition, an interesting finding is that this challenge impinges on the largest number of RE activities, as shown in the third layer in the model. This result indicates that achieving a common understanding of requirements is mostly affected by distance and unless all four major aspects of distance (in the first layer) are addressed, the stakeholders will face this difficulty in RE practice.

A further analysis of this model reveals that the negotiation of requirements is impacted by all the identified challenges (presented in all boxes in the third layer). This is not surprising in the RE domain, since requirements negotiation has been recognised as a major problem in RE [10]. Requirements negotiation is a rich and complex phenomenon involving aspects of a human, organisational and social nature; subsequently, factors of communication, culture, knowledge management and time have a great impact on it in distributed structures. Another possible explanation is that negotiation was loosely defined in this study, to refer to any situation when an issue arose that required a trade-off on resources or requirements.

In summary, these results indicate that distance has a significant impact on the collaboration between geographically distributed functional groups involved in the negotiation of requirements from a diverse customer market. There is a need for research to develop a RE process specifically for system development in multi-site organisations, to address the identified challenges. Furthermore, these findings are relevant to practice, i.e., to multi-site organisations that undertake software projects in structures where different functional groups need to communicate and coordinate requirements activities from remote locations. An additional characteristic is the significant geographical separation between these groups and which introduces large time zone differences. Efforts were made to describe the characteristics of this organisation thoroughly, in a hope that software practitioners are able to determine the similarity between their own organisation and the one described in this paper, and thus decide on the applicability of these results. We expect that a significant number of multi-site organisations find similarities with this description, and thus these findings will find considerable practical applicability in the software industry.

The model developed in this research enables us to take a step further and provide recommendations for improving practice. But the study is not without its limitations.

5.1 Limitations

Although significant, the findings of this study are based on the field investigation in a single multi-site organisation, a fact that threatens their external validity. A further validation of this model in other multi-site organisations is needed in order to gain confidence in these results. To this end, we established industry contacts to conduct more case studies. The active involvement of the first author at the activities of the development group in Australia may constitute another limitation, in that the challenges faced by this site may have been better understood and reported.

6 Recommendations for practice

The model developed in this paper was useful in drawing recommendations for practice that lessens the impact of distance. They are outlined below and address the relationships between the problems identified at the first layer of the model and the challenges outlined in the second layer.

6.1 Addressing the problem of cultural diversity

One way to address the problem of cultural diversity is to enable better and more frequent interaction with field personnel. While better interactions with the customers is a classical recommendation for improved RE practice, at GDS this is not feasible due to distance; however, we recommend that representatives from field support centres worldwide, those who interact with actual users on a daily basis, visit the development site at Sydney for mutual learning about the technology and specific customer needs. This will ease the challenge of diversity of customer culture and business. Language and terminology problems will be more easily dealt with, as well as difficulties in building trust relationships important in future remote communication. Whenever this option does not appear cost-effective, employ collaborative Internet technologies for synchronous activities such as collaborative prototyping and testing.

6.2 Addressing the problem of inadequate communication

These visits would also contribute to easing challenges such as the awareness of the users' local working context and would contribute to a better communication with sources of requirements through a more appropriate participation from field personnel.

Scheduling face-to-face kick-off meetings at the beginning of global projects would help to establish initial personal relationships between key stakeholders and put the bases for strategic planning. The effect of these initial meetings needs to be maintained through ongoing scheduled informal meetings across sites, to help better build personal and trust relationships. As one Australian stakeholder put it, "to have coffee with the BM in the morning on the videoconferencing system". To provide the benefits of informal communication to remote developers, provide electronically equipped rooms for "drop in" purposes, which groups of developers can use to call remote developers and share work artefacts as they would if they started a design discussion near someone's cubicle. However, there is no easy solution to the challenge of delay due to inadequate (asynchronous) communication. This issue is related to human factors and a sensible solution is left to future research. Finally, to address the challenge of difficulty of achieving common understanding of requirements, involve members of the BM group and field personnel in the requirements analysis sessions at the development site in Australia, to foster the mutual learning of business, customer and technical requirements, respectively.

Use a human facilitator (or train a developer) and an integrated, richer communication media that integrates data, video and audio channels, in the decision-making teleconferencing calls. This addresses the challenges of ineffective requirements decision-making meetings and managing conflict. The findings of previous research [6] indicates requirements negotiations supported by human facilitation and such rich media provide an environment conducive to integrative agreements. Until such a RE-specific tool becomes available, Netmeeting is an example of such groupware tool that can be used in meetings. It enables the sharing of applications and thus provides support with knowledge management activities in such meetings as well, as discussed next. The use of a video channel in such a tool would also provide support with maintaining personal and trust relationships—when the use of the mute button would appear as inappropriate and would increase the chance of a more open forum for negotiations.

6.3 Addressing the problem of ineffective knowledge management

Maintain a repository of project artefacts. This repository should include minimally a repository for requirements issues, the processes and terminology used, ongoing work artefacts such as RS and progress information. Rigorous maintenance and sharing across distance of this repository will aid in maintaining trust relationships, in achieving a more common understanding of requirements, and in improving an awareness of a working local context (progress on the development of requirement). Furthermore, using the data channel available in a rich communication tool enables the sharing of this repository during decision-making meetings, together with other supporting documents such as email messages related to a particular requirement. Finally, improve pre-meeting activities such as distribution of relevant documents and elicitation of feedback well in advance prior to the meeting.

6.4 Addressing the problem of time differences

This does not have an easy answer and requires further attention. One possibility is for the multi-site organisation to define work shifts at geographically distributed sites that overlap in Universal time (GMT). That would allow remote groups to combine asynchronous as well as synchronous communication into their collaborative work activities.

7 Future research

We intend to pursue two research directions as identified in this study: (1) the validation of the model developed in this study, through the investigation of other multi-site organisations in the case study; it is important to identify whether variations in the four major problems in the model are reflected in challenges faced by other companies; and (2) the development of an integrated RE tool environment that addresses the challenges of communication and knowledge management as identified in this paper.