Viewing risks in IT offshore outsourcing from an unsuccessful software project


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.


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.


[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.

Response to article “Design Patterns: are they so difficult to understand?”

This is a response to the article “Design Patterns: are they so difficult to understand” posted by s0943644 [1].

In the article, the author talks about the importance of using design patterns in software development and presents a problem that people are still arguing about the best way to study these patterns. Then the author covers single responsibility principle and factory pattern that he used in real project development and explains the steps he took to understand them.

Yes, the essential part to understand design patterns is to code with them.

I totally agree with the author on this point. For my own case, I ever took the course Software Engineering with Objects and Components. In the course, we covered concepts of design principles as well as several design patterns like factory pattern, singleton pattern, composite pattern, etc. I have to admit that as a student with little experience on software development, it was so difficult for me to understand these abstract concepts.

At that time, I was also developing a game using Java. In the game, users collected gems in a house with several rooms. Players could move between rooms and turn left or right, and were shown with photos from different perspective of the room as if they were in it.

At first, I wrote all the functions in one class and it worked well. However, when I tried to add a new ‘’room’’ to the ‘’house’’, I had to change almost all methods in the class. It was a disaster because the project was in low extensibility and was also hard to read for others. Then I compared the design principles I learnt from SEOC course and reviewed the code. No doubt I found no design pattern was used nor design principle was obeyed. And I also realized that I could use all these principles in my project to make it a better one. For example, one principle is single responsibility, to achieve this, I separated the class into several ones and each was responsible for only one purpose. Another example is, for open/closed principle, I used interfaces and let the class with similar functions implement the interface so that they were open for extension and close for modification. To be specific, one function of the project was to retrieve photos from different sources like Flickr [4], deviantART [5] and use these photos to build the ‘’house’’. After modifying the code, I implemented the function by using a PhotoFinder interface, several classes like FickrPhotoFinder, devianARTPhotoFinder that enable our project to retrieve photos. And letting the class MyPhotoController that implemented the interface decide which class to instantiate. And I realized that this satisfied factory method pattern.


Figure 1: UML diagram (*if you cannot see it clearly, please click it and view the large one)

After re-developing the project, the quality of the code was highly improved. And I had a much better understanding on how SOLID works in software development and how design patterns are used.

More things to discuss on learning design patterns through coding.

Sometimes people say they don’t have the opportunity or experience to develop large-scale software, and this is a barrier for them to practice and understanding design patterns. However, I think even small projects with few functions can be developed using different patterns. For example, when we write a UI using Java Swing, observer pattern is used when adding a button and registering the button with an action listener.

Another thing I want to mention is, we should not change our design so that it satisfies some certain pattern just because we want to use that pattern. Instead, we use patterns because after taking SOLID principles into consideration, we find our design satisfies some certain patterns. In fact, the principles are easy to remember, and as for beginners with little experience, it would be helpful if we think through all the principles at project designing stage.

Back to the discussion of the effective way in learning design patterns.

Other than coding practice the author mentioned in the article. I would like to talk about another effective way for beginners to learn design patterns, or at least helpful to me-—using real life examples.

Examples are always useful in understanding the concepts. And I think real life examples are more helpful than programming examples. For instance, when studying singleton pattern in the lecture, a given example was that, sometimes the data is required to be held consistently in one version [2]. This is easy to understand, but not intuitive enough. I refer to Wikipedia webpage [3]. It mentions several examples on how to implement singleton pattern and an example on Java Abstract Window Toolkit (AWT). For learners who are not quite familiar with AWT, this was not easy to understand as well.

Don’t we have other good examples? Wait! I thought of one when I was learning this pattern. Thinking about the president in the USA, there is only one person in that position (at least for now). In this example, president is the single instance, getPresident() method ensures that only one president can be instantiated. This example is vivid, it’s easy to understand and is helpful in understanding singleton pattern. In fact, I tried to learn all the patterns in this way and found it was really interesting and helpful.


Figure 2: Singleton pattern


Based on similar experience of learning design patterns by coding, I definitely agree with the author that coding is an essential part to learn these patterns. Besides, real life examples regarding to these patterns are also helpful for us to understand these patterns.






Easy facts about LOC used in software measurement

“If you cannot measure it, you cannot manage it.–Peter Drucker, management consultant

Measurement is an essential step to achieve effective management. People are aware of it and they use metric sets to measure projects. Compared with the elements that are hard to measure like qualitative information, they tend to focus on quantitative information like numeric quantity which can be measured easily. However, easily measured elements might not be as important as or more important than harder ones in terms of its contribution to project evaluation.

This is the same with software development. When we measure a software project, we need to first find a quantifiable metric. A most intuitive answer is to use the code line by line. In fact, lines of code (LOC) are widely used to measure the size of software and sometimes to evaluate the productivity of developers [1]. However, before we use it, we might need a minute to think carefully whether this is a good metric.

Is it an easy thing to count code lines?

If we use LOC to measure our software project, first we need to count how many lines of code are there. It seems that this is quite an easy thing, just by counting the lines of each file or each module. Here, question is how could we count precisely? In a large-scale software project, code is modified as requirement changes or bugs found and it may happen during development stage or even after the project is released. Which pieces of code are written in the development stage? Which pieces are added or deleted when we deal with bugs? People may suggest using simple maths computation to solve this problem: to count how many lines of code are changed, how many lines are newly added and then add them together. But for the “changed code”, we have to notice that it happens because developers add some new functions or modify bugs. So it is difficult to count exactly how many lines of code are there especially for those who are not quite familiar with the project.

Another problem with LOC…

There are several methods to calculate how many lines of code are there, for example, counting executable lines of code, data declarations, lines that are not null, etc. Different corporations or even different teams might not use the same counting rule. It’s meaningless to compare size of the projects or productivity of developers by using LOC when they are calculated on different standards.

Okay, assuming we could count code lines precisely and using the same counting method.

With the precious number of lines, companies could use it to evaluate the productivity of a programmer. Banker and Kauffman put up with a formula to compute the productivity after they did some research on software life cycle productivity [2].

Productivity = (Size of application developed) / (Labour consumed during development)

However, in real life, developers might be working in two projects in the same time; some of them might be responsible for only half or one quarter of the whole project. For these developers, the productivity calculated using the formula mentioned above would be much lower than those who work full time on one project. But we cannot simply come to the conclusion that they have lower productivity compared with others.

Another fact we need to notice is that there are thousands of programming languages. When LOC was first introduced as a metric, the most commonly used languages are FORTRAN, COBOL and Assembly language. For these languages, it is easy to count the lines. Later, high-level languages like JAVA, C++ appeared. In these languages, a single statement generally results in many machine instructions. It means that high-level languages might use fewer lines of code to implement a function. And it is also not meaningful to compare the number of lines of code developed using structured languages versus object oriented techniques [3]. For example, a system could be implemented with 6000 lines of Assembly code or 3000 lines of C++ code. Suppose a developer using assembly language writes 600 lines of code per month while a C++ developer writes 300 lines of code per month. It seems that the former developer has high productivity over the latter one. But when the two developers are developing the project mentioned above, they might finish it using the same amount of time. Advanced programming languages have strong expressive power. The more powerful the language is, the lower productivity it shows for its developers. So we can’t simply decide which developer has higher productivity simply based on these numbers.

What about clients? Is LOC meaningful to them?

Some corporations especially multinational ones would prefer to outsource different parts of the system like designing, coding and testing to different organizations. Clients care about the function [4]. Only the business value brought by these function is meaningful. LOC is not a metric that could be used to evaluate how meaningful the function is. More code does not necessarily suggest that the function is robust or the business value is large. In contrast, it might mean that there is code redundancy in the project. Besides, standard template library, class library, and software development kit like visual programming language are widely used today. As a result, many pieces of code are generated automatically. There also might be automatic configuration script and user profile in the code. As a result, it’s meaningless to measure the projects using LOC.


Every coin has two sides, so is the metrics used in software measurement. On one hand, metrics can be used to control and adjust development processes. On the other hand, developers might pay more attention to the elements that can be easily measured while ignoring the elements that are important but hard or impossible to measure. LOC is a most intuitive metric used in measuring both the size of the project and the productivity of the developers. However, there are several problems with it including LOC is difficult to measure, there is no agreed standard, and LOC is dependent on programming language, etc.

To achieve effective measurement, we should ask ourselves what is the final goal for the project? Is it to implement functions on time and within budget, to deploy the product massively and serve large amount of clients or something else? Based on the answer, we need to think about what metrics should be used to measure part of the project, what should be used to measure the whole project, what about the short term metrics, and what for the long-term goal. LOC is definitely not a good one, but what about others? World changes rapidly, are other metrics always good ones? Probably not, and those are all things that we need to explore.


[1] Clapp, J. (1993). Getting started on software metrics. Software, IEEE10(1), 108-109.

[2] Sudhakar, P. G., Farooq, A., & Patnaik, S. (2012). Measuring productivity of software development teams. Serbian Journal of Management7(1), 65-75.

[3] Boegh, J., Depanfilis, S., Kitchenham, B., & Pasquini, A. (1999). A method for software quality planning, control, and evaluation. Software, IEEE16(2), 69-77.

[4] Jeffery, R., Curtis, B., & Metrics, T. (1997). Status report on software measurement.