Main Menu
Home / ITMPI Insights / Managing Distributed Projects

Managing Distributed Projects

Projects are increasingly distributed across different sites. But distributed teams and suppliers complicate communication and create numerous frictions. Over half of all distributed projects do not achieve their intended objectives and are then canceled. Traditional labor cost-based location decisions are replaced by a systematic improvement of business processes in a distributed context. Benefits are tangible, as our clients emphasize: Better multi-site collaboration, clear supplier agreements, and transparent interfaces are the most often reported benefits. There is a simple rule: Only those who professionally manage their distributed projects will succeed in the future.

We will summarize here experiences and guidance from industry in a way to facilitate knowledge and technology transfer. Our experiences are based on many industry projects worldwide. We present state of the practice to ensure direct transfer and applicability to distributed projects. For more information please read our book Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing. Wiley, USA, 2012.

Distributed Projects and Teams

Today practically all Software and IT projects are distributed across sites, teams and companies. Successfully managing distributed software projects has rapidly become a key need across industries. However, a majority such distributed projects do not deliver according to expectations [1,2]. Distributed software development poses substantial risks to project and product management. As companies turn to globalized software, they find the process of developing and launching new products becoming increasingly complex as they attempt to integrate skills, people and processes scattered in different places. Many companies realize after a while that savings from outsourcing or offshoring are much smaller and problems are more difficult to cure than before. Disillusioned many abandon their global software engineering (GSE) activities.

Distributed projects, IT outsourcing, and business process outsourcing during the past decade have showed growth rates of 10-20 percent per year [1,2,5]. While market proximity, cost advantages and skill pool still look advantageous, distributed development and outsourcing bears a set of risks that come on top to the regular project risks. Not knowing them and not mitigating means that soon your project belongs to the growing share of failed global endeavors. Global software engineering is as natural for the software business as is project management or requirements engineering. Going global with software is a means of effective work split and managing skills and competences. To be successful with software we need to take advantage of continuous collaboration around the globe.

The share of offshoring or globalization depends on the underlying business needs and on what software is being developed. While for mere IT applications or internet services the distributed development is fairly easy, embedded software still faces major challenges to distributed development. A study by found that only 30 percent of all embedded software is developed in a global or distributed context, while the vast majority is collocated [1,4,5]. Similarly the amount of quality deficiencies and call-backs across industries has increased in parallel to growing distributed development and sourcing.

The journey has begun but it is far from being clear what the stable end positions will be. Clearly some countries will come to saturation because distributed development essentially means that all countries and sites have their fair chance to become a player and compete on skills, labor cost, innovativeness and quality. Software engineering is based upon a friction-free economy with any labor being moved to the site (or engineering team) that is best suitable amongst a set of constraints. No customer is anymore in a position to judge that a piece of software from a specific site is better or worse compared to the same software being produced somewhere else in the world. In essence the old-economy labeling of “made in country x” has become a legacy thinking that does not relate to software industries. What counts are business impacts and performance, such as resource availability, productivity, innovativeness, quality of work performed, cost, flexibility, skills, and the like.

Offshoring and outsourcing are two dimensions in the scope of globalized software development. They do not depend on each other and can be implemented individually. All distributed software development formats allow to more flexibly managing operational expenses because resources are allocated at places and from regions where it is most appropriate to flexible needs and ever-changing business models. Fig. 1 summarizes the reasons for distributed software engineering based on data from software companies in Europe and North America [1,2].

Cost reduction is still the major trigger for globalization, though its relevance has been decreasing over the past years. This reasoning is simple and yet so effective that is today mainstream for most companies and media. Labor cost varies across the globe. For the similar skills and output companies pay in different places of the world a different amount of money per working hour or per person year. Looking to mere labor cost for comparable skills of educated software engineers, several Asian countries offer a rate of 10-40 percent of what is paid for the same work time in Western Europe or USA. Salary differences theoretically allow reducing R&D labor cost by 40 to 60 percent [2,3,4,5]. Obviously insufficient competences, hidden costs and many additional overheads severely reduce this potential.

Fig. 1: Reasons for outsourcing and offshoring

Other factors therefore start to influence the decision for distributed software engineering. Increasingly distributed software development and offshoring is about proximity to markets, sharing the benefits of resources from different cultures and background, and flexibility in skill management. Managers want access to on-demand specialist know-how with less forecasting and provisioning which often contains lots of fixed cost that in today’s competitive environment is not anymore bearable. Increasingly, the target is quality improvement and innovation; both related to blending cultures and thus achieve internal competition and new stimulus for doing better.

Risks and Hidden Cost

To our experiences with clients around the world 20 to 25 percent of all outsourcing relationships fail within two years and 50 percent fail within five years [1]. This is supported by a recent study who reports a trend towards localization and insourcing [3,5].

One-fifth of the executives in a recent survey say that they are dissatisfied with the results of their outsourcing arrangements, while another fifth of the respondents see no tangible benefits [2,3,4]. Deloitte considering responses from 22 primary industries in 23 countries found that almost half of respondents have terminated an outsourcing agreement early for cause or convenience. More importantly, one third of those who terminated a contract for these reasons chose to bring the work back in-house. In fact, insourcing has emerged as a viable option, particularly when outsourcing does not meet expectations [3]. A Forrester study focusing on sourcing and vendor management sees “an ongoing level of dissatisfaction with outsourcing,” citing Forrester’s 2012 services survey of some 1,000 IT services professionals, where nearly half the respondents listed “poor service quality” as a challenge and one third stated they were looking to bring work back in-house [5].

Working in a distributed project means overheads for planning and managing people. It means language and cultural barriers. We will share best practices from projects of different type and size that involve several locations in different continents and cultures.

The business case of working in a low-cost country is surely not a simple trade-off of different cost of engineering in different regions. Many companies struggle because they just looked to the perceived cost differences in labor cost and not enough on risks and overhead expenses. Twenty percent of all distributed projects are cancelled within the first year [1,3]. 50% are terminated early [1,3]. In many cases, the promise of savings hasn’t matched the diminishing returns of unsatisfied customers.

Big savings in distributed software engineering have been reported only from (business) processes which are well defined and performed already before offshoring started, and which need not much control [5,7]. This includes maintenance projects (under the condition that the legacy software has some type of description) where some or all parts could be distributed, technical documentation (i.e., creation, knowledge management, packaging, translation, distribution, maintenance) or validation activities. Development projects have showed good results in all cases where tasks have been well separated so that distributed teams would have direction and ownership.

In many companies around the world I had seen distributed development projects failing when tasks were broken down too much, such as asking a remote engineer to do the verification for software developed concurrently in another site [1]. In such cases distance effects and lack of direct communication slow down development rather than help it. The single biggest source of difficulties in outsourcing/offshoring is related to communication across sites, bad communication hindering both coordination and insufficient management processes.

For example, continuous integration of insufficiently verified and encapsulated software components fails if done remote to the parallel ongoing software development. Distributed teams working on exactly the same topic (e.g., the famous follow-the-sun pattern of developing a piece of software in different time zones) posed highest challenges for coordination and often resulted in severe overheads that would be measurable or tangible only later (e.g., features misinterpreted, insufficient quality, lack of ownership and responsibility, etc.).


The challenges in distributed software projects can be summarized as follows:

Lack of strategy and shared values resulting in insufficient collaboration, unclear work split and ownership. Roadmaps might be fragmented or insufficient visibility provided on the strategy that both contribute to insecurity of teams and cause sub-optimal results. A clear sign for lack of strategy is the senior manager announcing, “We will work in India because it is cheaper” or the engineering lead explaining, “Any work can be done by virtual teams”. A major underlying reason for dysfunctional global work is different values and underlying society factors. We often label this superficially as “culture issues” or even worse as “soft factors”, claiming that we cannot handle it with our limited management and software education. For instance time perception in a society has profound impact on many behaviors such as insufficient planning and monitoring which cannot be cured only as symptoms. A culture deeply rooted in the present will always be portrayed as lazy and unfocussed by a society rooted into the future and therefore demanding accurate planning. The same applies to societies that value entrepreneurship and spontaneous (re)actions to events as opposed to those that prefer clearly outlined roles and responsibilities. Such differences must be recognized, considered and dealt with. A shared value system and continuous team building activities will help as well as rotating employees across these different societies.

Insufficient communication due to distance, time zones and cultural barriers. Note that distance impacts start at around 10-15 meters, i.e., far earlier than what one would usually assume. People talk and share only if they are close to each other and frequently run into each other without this being planned. Lucent and others did extensive studies on communication in global teams and found that 15 percent of software development is informal communication [1]. Distributed teams are less effective than a collocated team working on the same task.

Dispersed work organization. The global nature of project and product work obscures a holistic view of project success factors. More sites add cost due to overhead management, separated and dysfunctional processes, tools and teams. Tools help but will not be enough to build a distributed team. Process immaturity is a key roadblock and cause of inefficiencies and rework. Forrester, Gartner, BCG and Standish report 10 percent management overhead, i.e. 1 person to synchronize for 10 persons allocated an offshore task [1,2,5]. Our own experiences in many distributed projects over the past decade show that having two sites working on the same development project immediately adds 10-20 percent cost while reducing visibility and impacts of management [1]. Overall effort overheads are ca. 35 percent if working in two places due to interface control, management, replication, frictions, etc. [1].

Inadequate global management resulting in micromanaged tasks or lack of visibility. Often project managers would fear the lack of control and establish very small fragmented tasks to stay in control. Micromanagement creates a lack of buy-in from the teams as they expect that the manager would interfere anyway, so they don’t have to pay attention. On the other end is insufficient visibility starting with estimates and continuing with change management and progress tracking. Global team management often suffers from biased attitudes. Functional and regional rivalries exacerbate the tendency to claim credit for success and shift blame for failures. We experienced in several such global product lines that roadmaps and features are overly volatile because of local optimization on per regional customer basis. Our experiences show that change rate of requirements will in consequence be much higher than industry average (1-3 percent per month). Alcatel-Lucent reports 30-100 percent delays for multi-site change requests and overall project delays if a project is distributed across sites. Shell underlines the relevance of strong global management for such global software projects [6].

Inadequate global management resulting in micromanaged tasks or lack of visibility. Often project managers would fear the lack of control and establish very small fragmented tasks to stay in control. Micromanagement creates a lack of buy-in from the teams as they expect that the manager would interfere anyway, so they don’t have to pay attention. On the other end is insufficient visibility starting with estimates and continuing with change management and progress tracking. Global team management often suffers from biased attitudes. Functional and regional rivalries exacerbate the tendency to claim credit for success and shift blame for failures. We experienced in several such global product lines that roadmaps and features are overly volatile because of local optimization on per regional customer basis. Our experiences show that change rate of requirements will in consequence be much higher than industry average (1-3 percent per month). Alcatel-Lucent reports 30-100 percent delays for multi-site change requests and overall project delays if a project is distributed across sites. Shell underlines the relevance of strong global management for such global software projects [6].

Isolated learning. Improvements derived from past experiences are rarely applied beyond the originating organizational silo. We found that in global software engineering individual sites – even if working in the same product line – often have their own mostly organically grown tools and processes. It is not that they don’t like corporate standards; it is rather the desire of local management to optimize locally – because it is easier and faster than trying to convince headquarters in another region of the world. Different countries or regions would launch independent infrastructure optimization in order to differentiate. This is often amplified by dysfunctional regional competition as many companies have established to challenge “high-cost” countries with “low-cost” countries. For that reason the parent organization would hesitate to provide all necessary support due to fears that work would be taken away. Additional obstacles in sharing experiences arise from insufficient risk mitigation related to intellectual property or third party access to tools and knowledge repositories. SAP reports, “Distributed development is slower and less forgiving in case of mistakes. We need to communicate more but we have less capacity to communicate. Effects of mistakes are not easily apparent and tend to be hidden by regional owners longer than possible in a centralized development.” [1]

Less agility compared to collocated teams. On one hand workflows, monitoring and engineering processes must be strengthened to assure that different stakeholders collaborate well. On the other hand, baselining reviews across sites, agreements on plans, stepwise synchronization of work products, multisite project reviews etc. all add to this very concrete overhead situation. Such tasks are normal and necessary as soon as an integrated activity is done in different sites. But they are perceived as overhead by the teams and if not well-trained they try to escape causing major trouble during development. Therefore, engineering and management workflows and tools must be as agile and seamless across interfaces and sites as possible. Modern product life-cycle management tools certainly reduce such overheads.

Insufficient contract management. Contracts are absolutely crucial for managing external suppliers. They must include defined and measurable SLAs (Service Level Agreements) to assure appropriate quality levels. For captive offshoring it might be wise, depending on organization structure, to govern by means of internal contracts and SLAs. They have the big advantage that targets and measurements are agreed upfront and would not need continuous debates with senior management if some delivery is late. Certainly such internal contracts and SLAs together with a culture of accountability and clearly assigned responsibility also avoid the political game of finger pointing to “the others” that did not do their job well.

Unknown legal environment. This is a major trap for any global activity; independent of whether it is sales or engineering. To mitigate legal risks and exposure both local as well as central management must get very familiar with local laws, such as contracts, liability, intellectual property or human resource management. If you do not yet have enough experience with global development and specific regulations, we strongly recommend using consulting to ramp up your competencies and processes before you actually engage in global development. Never ever rely on the legal support from a supplier in the host country to which you want to expand your engineering teams.

High employee turnover rate. Turnover rates are higher in offshore centers than onshore – with same job content [1]. Reasons are manifold, but can be reduced to three factors, namely reduced motivation, culture clashes, and insufficient management. We see different local patterns of employee turnover rates across the world. Given the many opportunities for brilliant engineers, low motivation and insufficient rewards from their day-to-day work environment makes them search for another job. Often it is simply the job content (e.g., doing only legacy repair, having only scattered assignments with low personal commitment and ownership) and lack of career paths which makes engineers move to another company. For instance India’s software industry is in so fast growth that many engineers are continuously approached from other companies with even more interesting offers. But, with additional effort and skilled management, turnover rates can be reduced. We have experienced that it is feasible to manage an Indian engineering team with turnover rates similar to those in Europe over many years [1]. It all depends on management, culture, responsibilities and ultimately motivation.

With these challenges, reported cost reduction from global software engineering is much less than the above-mentioned potential of 40-60 percent savings if the same process is split across the world with changing responsibilities [7]. Successful companies reported from their global software projects a 10-15 percent cost reduction after a 2-3 year learning curve. Initially outsourcing demands up to 20 percent additional efforts [1,2,7].

Fig. 2 shows the average contribution of this hidden cost to the overall cost of R&D. For mere IT outsourcing, overheads are lower, specifically for management.

Fig. 2: Cost comparison including hidden cost

To externalize insufficient engineering processes creates extra cost and learning curve driven delays – on both sides. These additional costs sum up to 20-40 percent of regular costs of engineering [1,5].

The learning curve for transferring an entire software package to a new team (e.g., location) takes 12 months [1,6]. The effectiveness for software design and coding grows in a learning curve with 50 percent effectiveness reached after 1-3 months and 80 percent after 3-5 months. This obviously depends on process maturity and technology complexity. Each of the following bullets accounts for a 5-10 percent increase to regular onshore engineering cost in the home country [1]:

  • Supplier and contract management
  • Coordination and interface management
  • Fragmented and scattered processes
  • Project management and progress control
  • Training, knowledge management, communication
  • IT infrastructure, global tools licenses
  • Liability coverage, legal support.

Surviving in Distributed Projects

Global engineering will evolve towards a standard engineering management method that must be mastered by each R&D manager. Processes and product components will increasingly be managed in a global context. Suppliers from many countries will evolve to ease start-up and operations of global software engineering even for small and mid-sized enterprises in the high-cost countries. Brokers will emerge that help find partners in different parts of the world and manage the offshoring overheads.

Cost per headcount will further increase due to rising standards of living in the emerging countries contributing to outsourcing and offshoring. Global software engineering has a strong contribution in improving living conditions around the world. Bridging the divide is best approached with sharing values and understanding cultures. Such increasing standards in today’s low-cost countries will generate hundreds of millions of new middle class people that will demand more information technology.

Distributed IT and software engineering is the consequence of the rather friction-free economic principles of the entire software industry. Basically any code can be developed at any place in the world and made visible and accessible to any other place in the world at virtually the same time. There are not many overheads in distribution or industrialization as long as source code is shared. Many companies start global development due to perceived cost differences. Achieved cost reductions are further delivered to customers, which means competitive pressure for those enterprises not yet embarking on global development.

To survive distributed software and It projects we recommend a clear layout of the specific activities and necessary competences in the distributed teams (Fig. 3). These best practices are further outlined in our resources such as webinars and white papers [1].

Fig. 3: Risk management across the life-cycle

Further advantages appear when intensifying global software engineering, such as more flexible work hours of engineers and a demand-oriented provisioning of skills. Starting with smaller chunks of work, outsourcing/offshoring intensifies towards globalizing the execution of entire business processes or products. Innovative products are created due to having more capacity and more efficient workflows. Product life-cycles and technology growth will further accelerate due to this increasing innovation driven by global software engineering. The principle as such is amplified and will not allow any enterprise to exit.

We see four major drivers fueling the need for outsourcing and offshoring, namely efficiency, presence, talent and flexibility. Fig. 4 shows these drivers: efficiency, presence, talent and flexibility.

1. Presence. Global R&D and software engineering has become part of companies’ growth strategies, because they are closer to their markets and they better under-stand how to cope with regional needs, be it software development or services. Such global growth is a self-sustaining force, as it demands increasing capacities in captive or outsourced software engineering centers.

2. Talent. Computer science and engineering skills are scarce. Many countries do not have enough resources locally available to cope with the demand for software products and services. Fueling this trend, many younger people got nervous with media-driven perceptions about the danger of outsourcing/offshoring for the entire field of software, which they decided to rather engage in fully different fields. The consequence is a global race for excellent software engineers. Outsourcing/offshoring is the instrument to provide such skills and handle the related supplier-processes.

3. Flexibility. Software organizations are driven by fast changing demands on skills and sheer numbers of engineers. With the development of a new and innovative product many people are needed with broad experiences, while when arriving in maintenance, these skill needs look different and manpower distributions are also changing. Such flexible demand cannot anymore be handled inside the enterprise. Outsourcing/offshoring is the answer to provide skilled engineers just in time and thus allows building flexible eco systems combining suppliers, customers with engineering and service providers.

4. Efficiency. Software companies need to de-liver fast and reliably while at the same time the competition is literally a mouse click away. Hardly any other business has so low entry barriers as the software business and therefore stimulates an endless fight for efficiency along the dimensions of improved cost, quality and time-to-profit. Outsourcing/offshoring clearly helps in improving efficiency due to labor cost differences across the world, better quality with many well-trained and process-minded engineers especially in Asia and shorter time-to-profit with following the sun and developing and maintaining software in two to three shifts in different time zones.

Distributed IT and software projects need to facilitate speed, organization, and collaboration. They must leverage investments fast because of the ever-growing risk of IP loss. The new product life-cycle is determined by the time it takes to copy and compete. Implement processes that provide agility and efficiency. Companies need to balance time-to-profit with time-to-copy. They need to develop an organizational and management strategy for offshoring, along with developing an economic business case. Collaboration will further grow across disciplines, cultures, time, distance, organizations. This demands new competences, such as managing in difficult situations, teamwork across distance and cultures, sharing without losing, etc. which many students so far do not learn in their classroom projects.

Fig. 4: The way ahead: Four drivers fuel future globalization
Fig. 4: The way ahead: Four drivers fuel future globalization

Unfortunately (for the expensive western countries) these changing conditions will not have sustainable positive impact for today’s highly paid software engineers. On the opposite, an increasing amount of competing software companies will evolve and further push for global alignment of engineering cost (but this time cutting down the top salaries). What looks healthy from a global perspective has negative impacts on those of us who will not adjust fast enough to a new work split.

To be successful in a global market, a company should manage the risks of global software development, and should utilize the positive aspects as driver to shape the software engineering processes in detail and the culture in general. The challenge is to continuously improve processes, innovativeness and productivity. Software engineering has low entry barriers and a global resource pool. Engineers will have to assess their own competitive value frequently and change gears and functions opportunistically to stay employable. That is the task of all of us software engineers in the future. Those of us who stagnate will be out of business faster than we might think.

History has shown time and again that mixing genes is the best thing that can be done in the path of evolution. Or in the words of Charles Darwin, who was one of the first truly globally acting scientists: “It is not the strongest of the species that survive, or the most intelligent, but the ones most responsive to change.” Globally distributed It and software teams are about the same concept.


  1. Ebert, C.: Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing. Wiley, USA, 2012
  2. PWC: Global Software 100 Leaders. Annual Report.
  3. Greengard, S.: Is Outsourcing Losing Its Appeal? Deloitte study report. .
  4. Chui, Michael et al: The social economy: Unlocking value and productivity. McKinsey Global Institute, Jul. 2012.
  5. Forrester’s Forrsights Services Survey, annual.
  6. De Loof, L.: Managing IT transformation on a global scale. .
  7. Rivard, S., B. A. Aubert: Information Technology Outsourcing. M E Sharpe, New York, 2008.

Further Reading

Ebert, C.: Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing. Wiley, USA, 2012. Description: Based on the author’s first-hand experience and expertise, this book offers a proven framework for global software engineering. Readers will learn best practices for managing a variety of software projects, coordinating the activities of several locations across the globe while accounting for cultural differences. Most importantly, readers will learn how to engineer a first-rate software product as efficiently as possible by fully leveraging global personnel and resources. This book provides more sources for data used in this short version.


Christof Ebert will be presenting a free webinar with ITMPI on March 14! Sign up here: 9 Steps to Success with Distributed Teams and Projects

About Christof Ebert

Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to improve product strategy and product development and to manage transformations, such as optimizing global IT organizations. Prior to that, he held global management positions for ten years with a global IT market leader. A trusted advisor for companies around the world and a member of several of industry boards, he lectures at the University of Stuttgart and at the Sorbonne in Paris. He authored several books including his most recent one entitled Global Software and IT published by Wiley. He received the IEEE distinguished visitor award. Contact him at

Check Also

How to Identify and Manage Secondary Risks

Have you ever created a problem in trying to solve one? Secondary risks, or risks …

Leave a Reply

Your email address will not be published. Required fields are marked *

Sorry, but this content
is for our subscribers only!

But subscribing to ACCELERATING IT SUCCESS is FREE and only one click away!
Join more than 40,000 IT Professionals and get the best IT management articles to your mailbox with Accelerating IT Success!

Unsubscribe at any time