Making Geographically Dispersed Development Work


If you manage software engineers, or software product development, sooner or later, you will be faced with a vexing problem: not all the people are in one place, or even in one time zone. This paper analyzes the problems associated with geographically distributed product development, and discusses possible solutions to reduce project risk. Real world examples are used to understand how these solutions will fit your project situation.


The good news is that management understands that big projects have a much smaller chance of succeeding than small projects [3]. The bad news is that by breaking big projects into smaller, more independent projects, the people needed to complete the project are no longer in the same geographical area. Geographical distribution of people working on the same project or related projects is fast becoming the norm, rather than the exception. Unfortunately, the problems with co-located projects are magnified when not all people are in the same place. There are basic needs to address for every geographically distributed project for people, process, and technology. This paper discusses some of the people, process, and technology issues requried for successful geographically distributed software development.


Software product development is a people-centric process. No matter what the manager does with the process and technology, people will either make projects succeed or fail.

Understanding One Another

As a people or project manager you have the challenge and opportunity to merge different cultures and communications styles. It is critical for people to understand what the deliverables are and how to know when those deliverables have been achieved. For example, a software project manager in Boston described his frustrations working on a joint project with a software group based in Los Angeles:

“I had been told in the project team meetings that everything was on track. The first milestone (feature freeze) date was met. But, when we started to complete the implementation on the way to code freeze, it was clear the low level design was not complete— in fact, not even the high level design was complete. I called the West Coast technical lead and asked if there was a problem. The technical lead’s answer was that feature freeze was an East Coast thing, and as long as they made code freeze, what was the problem?”

There are two issues here: communicating the need for the milestones and what the milestones mean to the project team. In this case, the low level design completion (feature freeze) was necessary to verify that the module interfaces were complete, before coding completed.

For international situations, the issue of understanding is both easier and harder. It is easier in the sense that people all over the world understand we have different cultures. It is harder when you cannot see the other person/people to see if your communication is successful.

A Boston-based product development team was dependent on a German subsidiary for an independent, but necessary part of the software product. During the project planning, the German project lead had repeatedly told the Boston project lead that the German August vacation schedule effectively meant that no one was working on the project for the first three weeks of August. The original schedule had the product ship date in mid-July. Sure enough, the schedule slipped. The German technical lead explained that no one from the German team would be able to help with integration during August, they may as well slip the project from mid-August to mid-September. The German lead was aghast that the Boston lead expected the German team to give up their vacation:

“Why should we give up our vacations because they can’t keep to a schedule? We can’t take vacation four weeks later— our children are all in school then. Postponing vacation is not an option, and I repeatedly told him that. Why didn’t he make his team meet their dates?”

Understanding what is important to people as human beings is critical. As a software development manager said about distributed development: “In order for it to work, it takes a lot of work, like a marriage.” [4] In this case, the Boston project leader did not understand the importance of vacation to the German team.

Trust and Values

The previous two examples show that the project teams must understand and trust each other. They must respect each other’s values. As the entire team evolves, it must create common values around what is important to the product under development.

One way to develop trust and common values is to train all team members on the product development process and on the tools necessary to carry out the process.


Regular and frequent communications help make the team solidify as a team, rather than an indepedent group of people working on the same thing. Project team meetings can help create a team. However, face-to-face communications are also necessary. This was brought home to me when I was the leading a cross-functional team and we had a new member:

“The first time I heard you on the phone, I thought you were a straight-laced witch with no sense of humor. It wasn’t until I met you, a month after I started, that I realized you were serious about the schedule and the deliverables, but that you had a sense of humor. And, what I thought was straight-laced witchiness was really sarcasm!”

For a month, this poor soul was dreading coming to my team meetings, and couldn’t understand why the people on the Other Coast were enjoying themselves. As a manager, I did not fully “engage” [6] all the people on the team. Engagement is critical to understanding the real project state.

Face-to-face meetings allow people to really understand each other. The manager should expect to travel to all the “remote” (where the manager is not based) sites at the beginning of the project, and at some frequency during the project. In fact, holding at least one team meeting at every site can be a powerful incentive to the people working on the project. Moving the team meetings around help the team see that they are part of a team.

As a team works together, the people on the team learn from one another. [1] They learn technically from one another by working through the specifications, design, and implementation of the project. The manager needs to ensure that this learning takes place, and is facilitated by frequent communications, not stopped by inadequate communications.

After the people issues, successful distributed product development efforts develop common processes.


Common, or at least complementary product development processes are necessary for all project sites to succceed with distributed product development. A common process helps with common terminology, reporting and understanding of project state, and the ability of the people with the problem to make decisions.

Common Terminology

Each developer must understand the project milestones, and the criteria by which the milestones are met. In addition, each person must understand the project status questions. The best way to make this happen is for the entire development team to define their product development process.

The team should agree on the key milestones and deliverables at those milestones. They need to agree on the project review strategy (what gets reviewed, inspected, or walked-through, by whom, and when). The team needs to understand the criteria by which work products are declared done.

When the team defines this for itself, they have bought into how the project is managed. These are comments from a Boston-based software developer working primarily alone on a project with teams in Atlanta and Boston:

“When I first started working on this project, I had no idea why they wanted to inspect my code. I thought they were picking on me. But, once I sat in on some inspections from the San Francisco team, I understood what they wanted. Since I was trying to do the Right Thing myself, it was a much bigger help to implement the design right the first time. I just wish they had told me why they wanted to have code inspections.”

In this case, the team did not include all team members when determining the way of working. However, they were able to draw in the remote individual to work with them in the way they wanted to work.

Reporting and Understanding of Project Status

It is critically important to the project to be able to quickly understand the project state. That requires regular reporting of appropriate project status. Miniature milestones (McConnell) is a reliable method of developing the project task list to avoid the 90% syndrome. When everyone understands the list of weekly tasks, and they are accomplishing those tasks, the team starts to perform as a team.

Most managers would rather have bad news than surprises. To encourage people to give regular and appropriate status, they must have a method to report on how their work is going. In addition, they must be able to escalate problems without fear to the appropriate manager.


Decisions about the product or project should be made at the lowest possible level, and then inform management.

This all adds up to a common defined product development process. Defining the process does not have to be a large protracted effort, nor does an organization need a “BHB” (Big Honking Binder) (Browne). It may be as simple as defining the four to six important milestones for the organization and the criteria to know when those milestones are achieved.

Everyone likes knowing what is expected of them, and when they have succeeded.

The last risk addressed here, technology, is necessary for successful geographically distributed product development.


Technology can allow a team to succeed. Alone, it cannot make a team fail, but inadequate technology can get in the way of success.

Development tools

When separate groups of people work on a project, common tools are important. The configuration management and defect tracking systems are two prime candidates for a common project tool used across the project. If they are not, pieces of the project or problems can get “lost”.

The tool users must be able to access the tools in a timely fashion. Users will not use a common configuration management system if it takes 15 minutes to open or save a file.

Communications tools

The project sites must have adequate communications mechanisms. Basic speaker-phone and voicemail systems, email and intranets are now the minimum communications mechanisms. In addition, low cost video-capable meeting solutions are now available.

Video makes face-to-face communications more possible. Even without the physical ability to touch someone, the people involved in the decisions can engage each other.

Tools training

If the project team does not know how to use the tool, the tool is useless. If training is required for all project sites, make sure all the team members everywhere get training. This applies to techniques, such as code inspection or requirements management, as well as to hard tools.

Technology is an enabling substrate for distributed product development. It is not the answer to making numerous sites work together.


Adequate technology is required to make geographically distributed product development work. Many organizations have the initial technology in place (email and intranet), but not enough of the interactive-enabling technology.

Each project must define its hand-offs, so that everyone understands their roles in the project. This is a defined product development process, developed by all the technical people who will use it, not handed down from one set of management or another.

If people can talk to one another, understand what each other is saying, and trust each other to deliver on the hand-offs, then the communications issues are solved. Then, management can make distributed product development work.

It is possible for virtual teams to work together successfully. The project and people management requirements are the same as for a collocated team, just intensified. Additional tools are required to overcome the distance barrier.


1. Abdel-Hamid, Tarek and Stuart Madnick. Software Project Dynamics, An Integrated Approach. Prentice Hall, Englewood Cliffs, NJ. 1991.

2. Browne, Marsha. Private communication. 1997.

3. Jones, Capers. Assessment and Control of Software Risks. Yourdon Press, New York. 1994.

4. McConnell, Steve. Rapid Development, Taming Wild Software Schedules. Microsoft Press, Redmond, WA. 1996.

5. Purchia, Barbara. Private communication. 1995.

6. Weinberg, Gerald M. Quality Software Management, Vol. 4, Anticipating Change. Dorset House Publishing, New York. 1997.


© 1997-1998 Johanna Rothman. This article was the basis for a number of talks I delivered in 1997-2000 at the Software Development conferences and elsewhere.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply