This section will examine how changes in organizational distance can be expected to affect project contingencies and, in turn, how those expected changes in project contingencies are expected to influence the choice of project mechanisms used to monitor, control and coordinate a software development project.
To begin, a model of the relationships between organizational distance (Table 19, Section 3.1), project contingencies (Section 2.6.2) and project management mechanisms (Table 9, Section 2.3.4) is shown in Figure 8. Using the device of project management contingencies allows greater flexibility than a model that only considers the direct effect of organizational distance on
Page 82
the choice of project management mechanisms. It allows investigation into the relationship between contingencies and the choice of project management mechanism, and investigation into the relationship between organizational distance and project management contingency. Such an interface is a common design feature in software development to protect a component from changes in its external environment and results in a flexible, modifiable system. In the same way, the interface of project management contingencies between organization distance and the choice of project management mechanism allows organizational distance to be replaced by a different environmental factor, such as software development technology, whose relationship to the project management contingencies can be investigated more easily than their relationship with the choice of project management mechanism. The model potentially allows predictions to be made about the effect of any number of environmental factors on the choice of projectmanagement mechanisms through considering their effect on project management contingencies. For these reasons, this model of the relationships between organizational distance, project management contingencies and the choice of project management mechanisms is considered to be a significant contribution of this thesis.
Organizational Distance construct Project management contingencies Project management mechanisms Task programmability Cultural distance
Affect Task visibility Influence the choice of Monitoring • Automatic • Formal • Ad hoc • Informal monitoring Output Measurability Structural distance Risk Control • Output • Behaviour • Input • Clan control Relational Quality Administrative distance Costs Coordination • Standards based • Plan Based • Formal Mutual Adjustment • Informal Mutual Adjustment
Figure 8: Relationships between organizational distance factors, project management contingencies and project management mechanisms.
The effect of increased organizational distance on each of the project management
contingencies will be examined in turn to gain some insight into how this is likely to influence the choice of project monitoring, control and coordination mechanism.
Page 83
3.3.1 Cultural distance.
3.3.1.1 Task programmability
Task programmability is an attribute of the task, independent of the environment in which the task is performed. In describing task programmability, Ouchi (1979) and Eisenhardt (1985; 1989a) did not consider whether the task description was as comprehensible to the agent as it was to the principal. In the context of single organizations, comprehension was assumed. Although it has been claimed that software developers throughout the world largely share a common view of software development tasks (Carmel, 1999 p73), cultural differences do appear to influence views of how the tasks should be carried out, hence programmability. Borchers (2003) described the effect of three of Hofstede’s (1991) cultural dimensions in projects
involving American, Indian and Japanese software developers. He reports that some differences affected social aspects of project management but at other times the culture affected technical aspects. This echoes Herbsleb’s view that architecture is influenced by organization structure or, in this case, culture (Herbsleb and Grinter, 1999a).
3.3.1.2 Task visibility
There is little research available that investigates relationships between cultural distance and task visibility. Experience reports (Dube and Robey, 1999; Nicholson and Sahay, 2001; Borchers, 2003) imply that visibility into a task is not improved but, since the issue is not addressed directly, it is difficult to conclude that reduced visibility is due to cultural distance and not geographical distance.
Two studies that involved teams distributed across at least two continents highlighted a number of problems that arose but none of the problems concerned visibility into one party’s task by another party (Cramton, 1997; Vogel et al., 2001).
Lientz and Rea (2003) acknowledge the difficulties of communication on international projects and, although they recommend that the project manager travel to the remote location to meet informally, their recommendation is based on avoiding misunderstanding and misleading reportage rather than lack of visibility into the remote tasks.
Thus, task visibility does not appear to be significantly affected by cultural distance. 3.3.1.3 Output measurability
Hamilton and Kashlak (1999) propose that increased cultural distance between the parties will favour input control. They reason that the degree of cultural distance will influence a
multinational company’s parent-subsidiary performance ambiguity and task definition. As a result, it is reasoned, task programmability and output measurability will decline. Roth and O’Donnell (1996) point out that, with increased cultural distance, complete and accurate
Page 84
information becomes more difficult and expensive to attain, making it harder to verifyconformance to expected behaviour or to verify that expected outputs have been achieved. Thus, despite the number of available methodologies that detail exactly how to develop software and the commercial QA audit industry devoted to ensuring that an organization follows the
development process, there are those who argue that software development is essentially ungovernable.
Although large cultural differences should favour input controls, software development is one of the few industries where the product is readily transportable and readily measurable making the task of verifying outputs comparatively easy. This is especially so when that output is a
relatively small and transportable artefact like a specification, design or executable program. When the output is less transportable, an installed large system for example, remote verification is more difficult but not impossible. The principal can ask the agent to verify that the required outputs have been achieved or they could do the verification themselves.
Where cultural difference may matter is in understanding which outputs to measure and
specifying how to measure them. For example, Borchers (2003) relates how the Japanese do not classify defects by severity nor do they sequence them in the order in which they are to be resolved. The Japanese view is that all defects must be resolved so the sequence in which this is done does not matter. Classifying defects and ordering them by severity is useful when there is an understanding that the most significant must be fixed before the product ships. Cosmetic defects or defects with marginal impact on the customer are not the kind of things to hold up an income stream from delivered product. But the Japanese in Borchers’ experience believed that the product should be defect free before shipment so did not understand the need to classify defects.
3.3.1.4 Risk
Hamilton and Kashlak (1999) specifically included cultural distance as a contributor to project uncertainty and then propose that smaller cultural distance between the two parties will favour behaviour controls while larger cultural distance will favour input control. This matches the general thrust of Eisenhardt’s proposals arising from considering outcome uncertainty within agency theory (Eisenhardt, 1989a).
While neither Lientz and Rea (2003) nor Carmel (1999) identify cultural distance as a separate risk, they both reference several circumstance that have the general effect of increasing
uncertainty. Most of the increased uncertainty seems to arise through different ways of working (Carmel, 1999 p76) or general communication difficulties.
Page 85
In the absence of compelling evidence, it will be assumed that cultural differences may increase project uncertainty to some degree but the increase will likely be small compared to other project risks.3.3.1.5 Relational quality
When developing a model of relational quality, Arino et al. (2001) consider demographic attributes as part of a relationship’s initial conditions. The initial conditions determine the level of relational quality that is later modified by experience. The context of their paper is
international corporate alliances rather than software development projects, so that initial levels of relational quality may be set by corporate risk averseness and start out low.
Logically cultural diversity should make it impossible that everyone believe in the same values and share the same goals. Indeed, both Carmel (1999 p144) and Lientz and Rea (2003)
recommend some effort be made to create a team. This is an attempt to overcome differences at the national or organizational culture level with a team culture. Carmel reports that high context cultures, such as Asian cultures, are slower to develop trust than low context cultures, such as Australia. This would normally make team forming a difficult, slow affair except that in practice teams form comparatively quickly. This has given rise to the theory of swift trust in which team members assigned a common task of finite duration assume that the other team members are reliable and competent, just like themselves (Jarvenpaa and Leidner, 1998; Gallivan and Depledge, 2003).
In an interesting experiment testing swift trust theory on global virtual teams, Jarvenpaa and Leidner (1998) found that culturally diverse teams could establish trust quite quickly even though restricted to asynchronous electronic communications. Trust was not established in all teams. Some started with low trust and stayed low, some started low and became high, some started high and became low and some started high and remained high. Although this was not a test of clan control, it relied on clan control to get the task completed. There was a prescribed but vague outcome of proposing and developing a web site of interest to IS practitioners. Behaviours were neither prescribed nor monitored although some teams did develop some rules of conduct. What remains is clan control - belief in common goals and values.
Overall, cultural distance appears to have little effect on relational quality in dispersed software development teams.
3.3.1.6 Costs
If, as Constantine (cited in Carmel, 1999 p73) argues, the computer subculture is stronger than national culture then both the fixed and variable costs of software development team
Page 86
example, should be little affected by cultural differences. But that is not the view of Chevrier (2003) who found that teams needed to make cultural adjustments when working together for the first time. It is quite possible that people who have experienced working with different cultures have less need for adjustment than people who have not.Informal mutual adjustment, which incurs higher variable costs, is used for matters that require precise communication and clear understanding between the different parties. Kraut and Streeter note that informal, interpersonal communication tended to be used all the time but was favoured when the project was certain and in the planning stages (Kraut and Streeter, 1995). Difficulties experienced by cross cultural teams reported by Cramton (1997) were partly attributable to the geographical separation and partly attributable to cultural misunderstandings. Although some of the problems may have been resolved faster if the teams had been co-located, many of the problems only arose because of cultural differences and many took longer to resolve due to different expectations on how they should be resolved. Thus cultural distance is expected to increase variable costs.
However, an empirical study by Gomez-Mejia and Palich (1997) did not find significant difference in market measures of performance for a number of Fortune 500 organizations over the ten year period 1985 - 1994. In their discussion, Gomez-Mejia and Palich note that a
laboratory study by Watson et al. (1993) found that, initially, culturally diverse teams performed better but that this effect was short-lived. Both culturally diverse teams and homogenous teams performed at about the same level after 9 weeks on solving complex business problems. Thus it can be deduced that cultural distance may have significant effect on team performance, and therefore project cost, for a short duration project or a short duration relationship but is not significant in the longer term.
3.3.2 Structural distance
3.3.2.1 Task programmability
Various strategies for task distribution are reported to affect the way in which tasks must be programmed (Grinter et al., 1999). Although this is applying the term “task programmability” to the wider context of the task environment rather than the narrow context of the task itself, from the point of view of a project manager, the programmability of the task has been affected. This may affect coordination more than monitoring or control.
While it may be reasonable to expect that structural distance may affect the ability of an organization or project manager to enforce conformance to particular work practices, citable evidence of this is difficult to find. Lientz and Rea (2003) point out that people at a remote site
Page 87
have their own concerns and agendas, making them less likely to perform tasks precisely as directed. Carmel (1999) notes some of the problems of working with global softwaredevelopment but does not identify a problem that could be classified under the heading of “task programmability”.
3.3.2.2 Task visibility
The effect of structural distance on task visibility is well illustrated in an anecdote by Herbsleb and Grinter (1999a) in which a reported defect was only solved when a developer visited the site from which the defect was reported. Essentially, the defect occurred because the developer had imperfect visibility of the tester’s actions. Structural distance makes it that much more difficult for a project manager to directly observe task performance.
Structural distance normally affects the principal’s, or project manager’s, visibility into the transformation processes. They are less able to pick up on chance remarks and less able to walk about monitoring the team’s efforts and progress. In agency theory terms, the information system must compensate for the distance by substituting some other means of gathering information. Lacking a different information system that provides sufficient information to enforce behaviour control, a principal will favour outcome control (Eisenhardt, 1989a). Microsoft moved some development projects from Japan to their headquarters because the Japanese tended to try to hide what was going on from the people at headquarters (Cusumano and Selby, 1995 p286). Microsoft clearly found this lack of visibility a problem and located major product development projects at a single site where “project personnel get together physically on a regular basis and explore ideas interactively.” As with Herbsleb and Grinter (1999a), the lack of visibility into each others’ work allows small problems to develop into large problems. While it is possible to argue that the example of Microsoft’s problem with
development in Japan could be attributable to culture rather than structural distance, the same reported anecdote notes that the multi-site development of OS/2 encountered the same problems. Within the examples of coordination processes typically used to resolve Malone and Crowston’s different dependency types (Malone and Crowston, 1994), all are potentially affected by task visibility. Of them, the most obvious would be concurrent engineering which seems to depend on increasing participation and visibility of selected tasks (Shina, 1991; Liker et al., 1996). While some of the dependencies can be resolved using such methods as schedules and common interfaces, those mutual dependencies that require a high level of communication would seem vulnerable to reduced task visibility.
Page 88
3.3.2.3 Output measurability
Authors on the subject of software measurement generally concern themselves with the measurements themselves rather than the methods of measurement (Fenton, 1994; Kitchenham et al., 1995; Kitchenham, 1996; Fenton, 2000; McGarry et al., 2002). Even when writing on quantitative project management, the subject of measurement logistics is not dealt with adequately (Kitchenham and Walker, 1989; Shumate and Snyder, 1994; Atkinson et al., 1998; Loch and Tapper, 2002). This could reflect the comparative recency of distributed and
outsourced software development. Whatever the reason, specific difficulties in measuring the outputs of software development are not yet known and it is left to infer such difficulties, and their possible solutions, from more general information on distributed projects.
Although software products themselves may be readily measurable, performing the measurements, that is testing the product, may not be so easily performed at a distance. In general, software systems would be more difficult to measure when they are installed at a remote site for three reasons. The first is that it is more difficult and more expensive to deploy the entire test team to the remote site. The second reason is that the installation site may lack the means to create specific circumstances required by the testing. They may lack specific
configurations or specific equipment. The third reason is that customers may be reluctant to spend the time testing the product when, in their view, it should already have been tested. Once the product is installed any delay in putting it into production represents lost revenue.
However, if the task output is readily transmitted around the world, as most software development artefacts are, then increased structural distance is unlikely to affect its measurability.
3.3.2.4 Risk
Distance creates delays (Herbsleb et al., 2001) and they, in turn, increase uncertainty. The distant team are subject to differing agendas, being less directly responsive to the project manager (Lientz and Rea, 2003) creating uncertainty over task outcomes.
Wallace et al. (2004) found that risk increased for both team risk and for control and planning risk in outsourced projects. The remaining four dimensions of risk from their
model - organizational environment, requirements, user and complexity risk - did not display statistically significant differences between outsourced and non-outsourced projects. This suggests that structural distance arising from outsourced projects contributes to the project uncertainty associated with the project team and from the ability to develop or keep to a schedule.
Page 89
Other authors on outsourced or distributed software development don’t treat risk as a separate factor but simply acknowledge that outsourced projects will entail risks, suggesting that risk management is important (Carmel, 1999 p182; Lientz and Rea, 2003 p17).Motorola’s experience with global software development exposed many issues related to project risk (Battin et al., 2001). However, this was not a quantitative study and no single issue was identified as having contributed more toward project risk or outcome uncertainty than any other. Risk increased, and it was managed.
3.3.2.5 Relational quality
The very nature of relational quality transcends distance to a large degree. Organizations develop relational trust through working with each other over time (Kadefors, 2004) and while it may be initially more difficult to form a relationship at a distance, the end result should be the same. Arino et al. (2001) document examples where relationships over a distance have failed but the reasons given for their failure were attributed to culture rather than distance.
We can therefore conclude that structural distance is expected to have little effect on relational quality.
3.3.2.6 Cost
A study into multi-site development (Herbsleb et al., 2001) found that distributed work teams took about two and a half times longer to complete similar work items than did co-located teams. The study concluded that delays were related to the size of the network of people who worked on the item. Part of the reason for the larger networks and delay was that each site tended to duplicate the collection of expertise needed to solve the problem instead of collaborating across the separation. People tend to seek advice and assistance from those close to them, thus creating a network of expertise at each site. This seems to be a natural outcome from Allen’s finding that communication drops off precipitously after a distance of only 30 metres separation (Figure 7) (Allen, 1977; Allen, 2000).
Many software development researchers have identified that informal communication among the team seems to be an essential part of software development (Kraut and Streeter, 1995; Herbsleb et al., 2000). If informal communication is hindered, then it is expected that