Viewing risks in IT offshore outsourcing from an unsuccessful software project

Introduction

Offshore outsourcing refers to a model in which the service provider and outsourcer are in different countries, they collaborate to complete the project. There are two major offshore outsourcing categories: IT outsourcing and business process outsourcing [1].

As for my point of view, three major risks in IT offshore outsourcing are misunderstanding others’ intention which resulted by culture or language difference, lack of communication and feedback is delayed. But these risks can be reduced by taking advantage of modern technology like audio/video conference or sending skilled BridegeSEs to development site, and using agile development. In this article, I will talk about the risks and solutions based on my own experience in an unsuccessful offshore outsourcing project.

What was my experience about?

When I was working in a software development company as an intern, my team was developing a project outsourced by a Japanese company. The requirement analysis process was finished in Japan by the outsourcer. My team was responsible for designing, coding and testing.

Before I left, my team delivered two versions to the outsourcer. We thought we finished the project because all the functions were implemented. However, the Japanese company was unsatisfied with it. They thought we did not understand the intention of the software and what we developed had great difference with what they thought should be.

How did the disaster happen?

Let’s first talk about the project requirement. I do not think it was a good one. The document did not provide much detail for some of the functions but only said what functions the system should have. Besides, the requirement document did not clearly specify the reason for developing this system nor the value that the system could bring to users. As a result, our team did not understand the requirement document clearly.

We understand that it is hard to write a perfect requirement document. Document authors and the developers might have different knowledge background and development experience. What the authors think they have clearly stated might be confusing to or misunderstood by developers.

Communication seems to be a good solution to this problem. Authors and developers should discuss about the requirement effectively, minimize the difference in understanding the documents and make it a completed one by adding some detail.

However, in this case, we did not communicate with the authors effectively. The authors who wrote the requirement document were in Japan while we were in China. We did not communicate directly, not to mention to have a face-to-face one. After we read the requirement document, we wrote a list of questions that we were unsure of and sent it to their Bridge Software Engineer (BridgeSE) in Japan.

BridgeSE is a popular position in some Japanese outsourcing companies. They know both Chinese and Japanese. BridgeSEs act as the interface between outsourcers and service providers. They negotiate with outsourcers about project issues, analyse the requirements and answer development team’s questions related to the projects.

In our case, BridgeSe answered some questions based on his own understanding, and forwarded the question list together with his own answers to the authors who wrote requirement document. The authors answered remained the questions and confirmed or modified the answers provided by BridgeSE. Then BridgeSE sent the answer back to our team in China. Before we delivered the first version, we discussed about the project only once.

Next stage was analysing, designing and developing. Our team delivered the first version which contained only user interface (UI) but did not implement much function. Since the description of UI requirement was specific, there was not much problem with the design. As the functions were not implemented, the outsourcer did not have the idea whether we understand the project in the same way as they did.

After that, we implemented the functions according to our understanding and delivered the new version to the outsourcer. We thought we implemented the functions, next, we need to test. But for the outsourcer, they realized that our design was not what they wanted.

The development team negotiated with document author about project requirement only once, not directly but via another person, and this process took two weeks. Besides, we delivered only two versions to the outsourcer. There are several problems with this development process.

First, all communication was by sending emails, some ideas might not be properly expressed or correctly understood. In this case, the outsourcer and development team were from different nations, there was great difference in language, culture and custom. These factors would bring difficulties to communication and understanding. If a project is designed by outsourcer and coded, tested by service provider, the trouble brings by ineffective communication would not be that serious because development team could coding according to the design. The design usually provides elaboration of functions, software framework in UML, class diagram, activity diagram, etc. These are like a blueprint and development team can implement exactly as the design describes. However, if the service provider needs to design as well as developing and test. The two sides need to discuss about the requirement in detail because they may have different understanding toward a same thing. If both sides depend entirely on document, or do not have face-to-face or audio discussion, the result might be a disaster because of the difference in how they understand the written document.

Second, our team still had some questions over the answers, but we did not negotiate with the BridgeSE because the expected time to deliver the first version was six weeks. The communication took a long time and we did not think the remained four weeks was enough for development. We designed as we thought would be right.  But in fact, the outsourcer was not satisfied with our design.

This problem was mainly resulted by inefficient communication, feedback was delayed for too much time. Instead of writing emails, we can take advantage of modern technology and use better ways to communicate. For example, audio conference, video conference, etc. These are ways that enable two sides to communicate as if they are face-to-face. Even though they are thousands of miles away, questions can be responded immediately.

Besides, the development methodologies our team used was not appropriate. We should use agile development [2]. To be specific, instead of just delivering an UI and an almost finished version, we should deliver in a short period of time or as long as we implemented some functions. Then we need to adjust according to the outsourcers’ responding. The new technology like web-based applications already enables us to set up demonstration system and explain our design to the outsourcer. If we use waterfall development [3], chances are that service providers may think they understand but actually they don’t. They have to redo the whole phase like designing entirely, this wastes time and cost.

Third, as document authors do not come to the development site or conduct a video conference and explain requirement for service providers in most of the Japanese offshore outsourcing projects. BridgeSE is a very important role. They discuss with authors about the project so that they will have almost the same understanding on the requirement as the authors do. Then they answer questions to development team as soon as possible. However, in this case, the BridgeSE did not seem to have enough understanding about the requirement and the discussion process consumed too much time.

This problem could be avoided from two aspects. First, Japanese company should hire BridgeSEs with sufficient development experience. BridgeSEs should be trained about the project and obtain enough information about it, so that they could answer the questions accurately. Second, BridgeSEs should be on the development site or at least communicate every time face to face by video conference.

Conclusion

The original purpose for IT offshore outsourcing is to reduce the development cost. But there are risks like they misunderstand the other’s intention, they do not communicate a lot, the communication is not effective, or the feedback is delayed. These risks might lead to the failure of the project or the raise in cost.

For both service provider and outsourcers, it is very important to agree on an efficient communication way so that time is fully used. For outsourcers, they should hire experienced BridgeSEs who have no barrier understanding language of the two sides and train these people to be familiar with the projects, and BridgeSEs should also be on site or at least respond to the questions in short time. For service providers, they should use proper development methodologies like agile development and deliver versions to outsourcers frequently, so that their product could meet outsourcers’ requirement.

Reference

[1] Aundhe, M. D., & Mathew, S. K. (2009). Risks in offshore IT outsourcing: A service provider perspective. European Management Journal27(6), 418-428.

[2] Thomas, D. (2005). Agile programming: design to accommodate change.Software, IEEE22(3), 14-16.

[3] Petersen, K., Wohlin, C., & Baca, D. (2009). The waterfall model in large-scale development. In Product-Focused Software Process Improvement (pp. 386-400). Springer Berlin Heidelberg.

One thought on “Viewing risks in IT offshore outsourcing from an unsuccessful software project”

  1. Very inspiring article for us Thanks for the great article. ….
    It’s definitely a good idea for me and my friends to learn
    the things that’ll expand their skill set Your ideas and presentation is very
    effactive and useful for all. I am loving all of the in turn you are
    sharing with each one!… Being a user i really like your visible information
    on this pagesoftware development

Comments are closed.