Distributed Development

From Wikipedia, the free encyclopedia

Distributed Development can be described as a R&D project across locations, where all contributing project members and entities are together responsible for the outcome of the project. A distributed development project builds on common goals, shared information and real collaborative work, supported by means of technology.

The collaborative element of a distributed development project makes it different from an outsourcing initiative, the research element distinguishes it from a virtual team.

[edit] Distributed Development means three things:

  1. Location: People and or teams are distributed across locations and work on the same project or product. The reasons for the distribution do not matter, it could be either the availability of resources in different location, closeness to certain clusters, to customers or cost advanatges. Examples could be the production of an Airbus or Boeing aircraft - those are usually done in multiple locations (though by the same company) and assembled finally in one location.
  2. Collaboration: People might specialize in a distributed development environment, but they actively collaborate together to achieve the common goal. There must be a program lead or project head somehwere, but it is not an environement of an outsourced part of the overall development lifecycle, where people at one location wouldn't know what happens in the other locations. In a distributed environment, project members share ideas, information and resources. To get back to the Aircraft example: The Airbus engineers in Hamburg know exactly what their colleagues in Toulouse are doing and they know this well beyond just the interfaces of the pieces they do.
  3. Responsiblity & Accountability: Everybody feels responsible for the achievement of the overall project goal. Nobody can succeed without everybody else being successful. This is also different from a typical outsourcing project, where every outsourced function just concentrates on (and gets measured against) the actual goals & tasks of that function. This mandatory set-up makes people think about what the "other side" thinks and makes them collaborate and help each other. Again, Airbus in Hamburg can never be successful, if the aircraft doesn't take off. Even if they produce the best fueselage and wings the world has ever seen - the plane is only a success if it flies when assembled.
Requirements Dsitributed R&D

In summary, distributed development is the highest form of collaboration in any engineering and R&D environment. It is difficult to achieve, since it requires high management capabilities and an excellent environment for communication & frequent interaction. It further relies on a well thought through organizational setup, a work atmosphere free of political battles and a highly efficient infrastructure. The top management needs to believe in the set-up and put measures in place to reward compliance and be strict with those who do not comply.

[edit] Success factors

There are three main success factors for a distributed development project:

  1. Select and/or recruit the right people.
  2. Spend some money of face-to-face meetings, specifically initially.
  3. Build an organizational design that supports working in a distributed development, including the right incentive systems

=> By doing that, one gets many advantages beyond pure outsourcing or offshoring, namely much higher motivated employees in all parts of the dirstibuted network, higher retention and certainly one gains from the diversity of the network.

The image below tries to explain how the different pieces fit together. There is a distinction between on-shore, near-shore and off shore and all three can be done eithe routsources (means by anothe rcompany) or by owns subsidiaries. In all cases there ar edifferent levels of work done outside of the own local boundaries, ranging from simple service to high-end R&D.

Distributed Development