Large multisite or multiorganization projects have existed for many decades. One of the first problems tackled by organizational researchers starting back in the 1950s was how best to organize work. Researchers such as Galbraith, March, Simon, and Thompson argued that interdependencies among tasks in a project or in an organization should be minimized. In those cases where coordination needs are unavoidable, they showed that if we know a priori (a) all the steps involved in a task and (b) the different interdependencies among tasks in a project, we can use mechanisms such as standard operating procedures to manage the interdependencies and efficiently coordinate work. However, when exceptions to the rules occur or uncertainty surrounds a task, we need more flexible coordination mechanisms, such as direct interaction among project members or meetings.
More recently, Malone and Crowston [1994] suggested additional coordination approaches using traditional software problems such as shared resources or producer/consumer relationships as analogies for ways to manage work dependencies.
In the technical domain, work on modular system designs has suggested very similar ideas. For instance, Parnas was one of the first to argue that systems should be decomposed into units (e.g., modules) and that dependencies among them should be minimized [Parnas 1972]. In this context, dependencies are represented by the interfaces exposed by each unit or module. As long as those interfaces are clearly defined at the beginning of the project and they remain stable, development of each unit can move forward in parallel. If changes are required, coordination can be managed by mechanisms such as meetings, where the relevant parties discuss and agree upon the modifications to the interfaces.
The approaches to coordination discussed in the previous paragraphs are commonplace mechanisms that we see today in any type of organization, including software development projects. However, software development presents unique and very difficult challenges in terms of coordination, stemming primarily from a complex interrelationship between the technical and social dimensions of software development projects.
We all know that knowledge and understanding of project requirements typically grow and change over the life of a project. As requirements change, the structure of a system under development changes and evolves. The uncertainty and complexity that stems from changes and evolution represent quite a challenge to understanding the dependencies among the various project members and how to manage them.
For instance, de Souza et al. [de Souza et al. 2004] and Grinter et al. [Grinter et al. 1999] studied several development projects and found that developers had major difficulties identifying how changes they were making could affect other parts of the system and the corresponding development tasks. Those coordination failures usually resulted in problems, sometime quite significant ones, during integration and testing.
The impact of coordination challenges in software development is severely augmented in global projects [Herbsleb and Mockus 2003] for several reasons:
Physical separation prevents project members from easily walking down the hallway and interacting with other project members to discuss problems or find out about changes.
The exchange of information and effective coordination are also hampered by time zone differences.
The lack of opportunities for synchronous interaction (e.g., conference calls) forces project members to exchange information in an asynchronous way (e.g., email) which increases the chance for mistakes and misinterpretations.
The more departments or locations are in involved in a project, the higher the chances are for organizational barriers (e.g., different management styles, incentive mechanisms, and goals) to interfere in a project member’s ability to efficiently and effectively communicate and coordinate.
In sum, understanding with whom and when to coordinate in software development projects is not a trivial issue. Furthermore, the inherent characteristics of GSD settings magnify the problem.