Planning the coordination of globally distributed projects
Carnegie Mellon University
Globally distributed projects are increasingly common as businesses strive to take advantage of talent pools and favorable cost structures wherever they can be found. These advantages often prove very elusive in practice, as distributed work takes two or three times to complete as compared to co-located work (Herbsleb & Mockus, 2003). Distributed work is often susceptible to numerous project risks, including such difficulties as missed deadlines, substandard quality, inefficient performance, and failed outcomes (Carmel, 1999).
At the heart of these difficulties is coordinating project work. In any sort of project, the work performed by different teams and organizations must fit together in a timely way so as to create the desired result. Individuals working on co-located project teams have the enormous advantage of meeting face-to-face, of enjoying ready access to people and common resources, of sharing a common physicl and cultural context, and of communicating frequently and informally. Only when these factors are absent can one understand and appreciate the advantages that these factors provide.
To compensate for lacking such advantages, geographically distributed project teams rely on other established practices for coordinating project work, practices such as developing project plans, monitoring project status, defining project processes, specifying component interfaces, and communicating—laterally— over distances, while traveling, and with management. One can think of such coordination practices as dimensions, which can include tracking project status at shorter-than-typical intervals and developing project plans and process that are more detailed and more uniform than is the usual standard. These dimensions can increase cost, but these also help project managers reduce the project's risk of coordination breakdowns.
These dimensions of coordination are typically considered only implicitly in most distributed projects. As Senge (1994) pointed out, there are significant advantages to making such implicit processes explicit: One can then think about the process as a whole and in a context; and one can think more readily about changing and adapting the process. In the context of distributed projects, it is important to think explicitly about a project's risks and about its two kinds of coordination tradeoffs. By explicitly evaluating a project's coordination needs, one can consciously decide how much to invest overall in coordination. It is an investment based on an evaluation of project characteristics; it also enables project managers to consider the tradeoffs they must make. How much should one invest in order to reduce risk? Should one invest in, for example, refining component interfaces, or should one increase their activity in a particular practice, such as—among others—project communication?
In addition to thinking explicitly about coordination as an element of project planning, it is helpful to explicitly monitor coordination during project execution. To some extent, this can be done through the usual status reporting channels, such as those using a number of typical metrics, including percent complete, earned value, and results of tests and inspections. Poor coordination is likely to show up, for example, as a failure to deliver on time, as a failure to deliver what is needed, or as a problem encountered while integrating the components. These indicators are not very specific because there are many different sorts of problems that can influence the process of using—and the results derived from—metrics.
Collecting specific coordination-focused metrics can provide an early notice of problems. From this, project managers can diagnose the problem's source. Unplanned communication is often the coordination mechanism of last resort, meaning that when other coordination mechanisms break down, people naturally start to communicate to resolve problems and re-establish coordination. Project teams can take advantage of this by monitoring their communication channels, using such means as distributing brief surveys periodically and tracking the project team's travel. When actual communication does not match what is expected (Sosa, Eppinger, & Rowles, 2004), it is often an early indication of a coordination problem.
Carmel, E. (1999). Global software teams. Upper Saddle River, NJ: Prentice-Hall.
Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally-distributed software development. IEEE Transactions on Software Engineering, 29(3), 1 – 14.
Senge, P. M. (1994). The fifth discipline: The art and practice of the learning organization. New York: Currency Doubleday.
Sosa, M. E., Eppinger, S. D., & Rowles, C. M. (2004). The misalignment of product Architecture and organizational structure in complex product development. Management Science, 50(12), 1674 – 1689.
©2006 Project Management Institute