Experts Show Us How To Create Successful Offshore Software Development Projects

There is always a lot of concern with offshoring software development. This blog post will address issues and recommendations from a paper on offshoring custom software development projects. We don’t want to bore you by reviewing a paper but we are always looking for advice to improve the offshoring experience.

The authors give some of their own recommendations but also pull a lot from previous research.

Reasons for Success and Failure in Offshore Software Development Projects

Before we look at the authors’ project and findings, we need to define what failure is for a software development project. The authors have cited another paper (Linberg, 1999) where failure is defined as such:

[A] project that is cancelled or that does not meet budget, delivery objectives and or business objectives. Delivery objectives and business objectives include scope, quality and time. Therefore, an unsuccessful CSD project can be defined as being cancelled, or failing on one of the four success aspects: delivering software that does not meet the requirements, not meeting the expected quality, not being completed on time, or exceeding its total budgeted costs[.]

Background
For this paper, 19 offshore customer software development projects were analyzed. The onshore component was in the Netherlands and the offshore components were in Malaysia, Romania and India. The size of the projects ranged from €30,000 to €60,000,000.

Findings
In their analysis, about half of the projects were successful as a whole. Over half the projects were successful based on scope and quality but less than half were successful based on costs and timing.

Let’s look at some of the specifics.

Experience:

The more experienced teams had more successful software projects. Project teams that knew each other beforehand also had more success. That’s not a surprise. But it does suggest that new teams should have an introductory period get to know each and their work/code styles.

That’s probably too many people on one project.

Project Size:

Smaller projects (less than 25 people) with a shorter timeline (less than 9 months) were also more successful. Once again this is not a surprise. But it does suggest large projects should be broken down into smaller pieces. This would allow large projects to gain some of the efficiencies of smaller projects.

Comments from Project Participants
The authors gathered comments from participants in all the software development projects. Somewhat surprising was that lack of standards was not indicative of failure. Having clear responsibilities was stated as a big reason for success.

Participants in successful software projects mentioned informal mutual adjustment as a major reason for success. This has to do a lot with constant communication, which is essential for any software project, onshore or offshore. Constant communication allows the project manager, the developers and the client to be on the same page and address issues when they arise. Those issues could include poor quality, a communication problem with one of the developers, or lack of direction by the project manager. Sharing of all documents was also indicated as an important factor for success.

Participants of unsuccessful projects blamed poor planning for the failure of their projects. This is not a huge surprise. It shows the importance of writing detailed and understandable requirements at the beginning of the project. It also suggests the importance of setting expectations with all the parties involved, including the client.

Here’s a great chart from the paper listing what made for successful and unsuccessful offshore software development projects.

So, how can an offshore project be successful? Project management and coordination must adapt to new dynamics with offshoring. The authors recommend the following five coordination areas that are key to a successful project:

1. Standards: all methodologies, rules and procedures should be documented and followed.
2. Planning: Schedules and milestones should be understood by all participants.
3. Formal mutual adjustment: This measures the quality of formal communication. Is there a daily scrum?
4. Informal mutual adjustment: This measures informal communication like skyping or a daily lunch.
5. Team selection: How does the team work together?

The paper then states that it’s also important that an offshore team’s schedule has some overlap with the onshore team.

What About Diversity of Staff?
Linberg (1999) stated that offshoring can increase diversity leading to a stronger team and better quality. In several follow-up papers, (Chan & Chung, 2004; Paasivaara & Lassenius, 2006; Layman et al., 2006), the authors found that diversity can lead to poor communication. We have been involved in both types of projects. For those projects that had poor communication, it was likely due to poor planning and execution and not diversity. On a number of projects we have found that diversity is a strength.

Offshore software projects need to be carefully planned and executed. Offshoring can increase innovation at a company because they can do more with less. But it needs to be carefully done. Did I already say that?