NINE offshoring advices

 

During my professional experience, I have offshored several projects. I had some bad and good experiences.

 

One of the main goals of the offshoring process is to build trust.

 

Here are 9 advices if you want to offshore a development project.

 

1.Always take care of your local workers

Most offshore projects require a certain level of interaction with local workers. As a matter of fact, offshore workers are often replacing in one way of another your local workers. Taking care of local workers should always be of high priority when starting and managing an offshore process. What is especially important is to communicate a right and sensible message to local workers of why and how offshore process is taking place.

 

Management from both sides should focus on integrating local and offshore teams. This will be developed later in communication chapter.

 

In fact, you should not only take care of your local workers but also of any process, organization changes offshoring projects will bring to your company. In one sentence: "prepare your company to offshore a project"

 

From this 1^st concern, then comes the question of what to offshore.

 

 

2.Focus on core competencies

You should focus on your core competencies and also let the offshore team focus on its core competencies.

 

It is usually wise not to offshore what is belonging to your core competencies...

 

 

3.The right partner is the one you can trust

 

Offshoring a project to an offshore company implies that you must trust this company.

 

If you are already working with a company that you trust, continue working with this company.

 

3.1 It is safer to start working with big companies

If you are starting to offshore a project and you don't have any offshoring experience, there are 2 reasons for chosing big companies (more than 1000 of developers):

• They have already successful experiences of working with western companies.

• They have a clear vision of where they want to go in terms of business. I have seen a western company working with a small very competent offshore company. The project went so well, that the offshore company decided to shift its priorities and try to sell a copy of the product itself. This should not happen with a big company as if it tries to be a competitor of its client, they will lose their already significative offshoring business with other clients.

Just FYI: this "It is safer to start working with big companies" statement is the one which is the most disagreed upon by offshore service providers. Keep in mind that the most important is to trust your partner. This is not always related to its size.

 

 

3.2 Start to offshore a pilot project to test and build the relationship

 

Another way to start an offshore relationship if you have enough time and wish to build a long term relationship, is to start with a small pilot project just for testing this relationship and build trust.

 

A quicker way is to give offshore team a requirement/design document that include flaws (obvious and not so obvious). If flaws are detected or questioned, that would give you a good feeling of offshore team competencies. By the way, they might even discover flaws that were not intentionally included :-). This "test" would also test the degree of knowledge of the western culture as shown in chapter beware of cross cultural issues

 

3.3 Some offshore companies propose to share risk

Some offshore companies also propose to share the risk of developing with them by being paid through a royalty scheme rather than cash.

 

3.4 miscelleanous considerations

Offices outside India: if a company does have offices abroad, it is an indication of its success and the fact that it has exposure to foreign work cultures. To an extent, this contributes to bridging the culture gap that I’ll write on later.

 

Beware of high offshore turn-over. "Always take car of the offshore personnel" is a statement similar to "Always take care of your local workers". Offshore engineers know they are paid 4 times less than your local engineers and may dream of doing whatever it takes to come working in western countries.

 

 

4.Ease communication as much as possible but rely on it as less as possible

 

This is best achieved by offshoring some activities which requires minimal interfaces / requirements management.

 

An example of a project that require minimal interfaces is "port this existing software on that new platform".

 

When handling complex projects, it is vital that local company has a very solid requirement management process and/or level of trust / ease of communication between local and offshore company is high.

 

When the requirement management is not solid and the project is complex, a solution is to split it in 2 steps:

• 1^st step/task is defined in a few words (minimal interfaces) and is 80% of the work.

• 2^nd step/task requires a lot more communication but understanding between offshore and local has been improved during the 1^st phase.

 

It is also important to have a manager, not a programmer, leading the communication process. It is a vital specific job in itself and should require extended skills and dedicated focus.

 

 

5.Process is a help to build trust, but cannot replace trust

Beware of project performance metrics masking problems. Here is a usual scenario:

1. It is written in the statement of work: “every release must be tested by the offshore team before delivery”.

2. Western local team asks for an engineering release, just to get a feeling of what’s going on.

3. If offshore team says “we don’t want to send you an engineering release now because it is not fully tested yet, most of the time it means wait for another week before you discover that we’re going to deliver poor quality”.

Another danger is to work under a contract signed as a fixed bid rather than a time and materials bid. Theoretically fixed bid contracts are perfect except that you need to have a flawless requirement management technical capability.

 

Working in a "fixed bid" manner is a kind of  "fire and forget management". A sizeable part of collaboration failures occur because the client did not spend enough time and attention on the work being done.

 

 

5.1 Basic Project Management topics that should appear in the contract

1. have a unique focal point
2. offshore team agrees to follow your development processes
3. offshore team agrees to provide as much work details as you require
   1. scope and deliverables (defined by you, including test reports)
   2. WBS, responsability Matrix
   3. Schedule detailed enough for an accurate tracking
4. offshore team and/or focal point agrees to attend regular status meetings

 

5.2 Quality Assurance

 

In my offshoring experiences, I regret not to have to have put enogh attention on the QA issues. It is as important to trust the offshore QA as it is to trust their developers. Do not have the developers test their own work. I strongly advise you to have 2 clear distinctive teams and 2 distinctive chapters in the statement of work.

 

Here is a good practice that I recommend following Test Driven Development (TDD) technique: ask for delivery of a test plan, before the development even actually starts. You will then have a good idea if the offshore team got the right requirements and have the same understanding.

 

A complementary way to build trust is communication which brings me to my next advice.

 

 

6.Beware of cross cultural issues

 

Having grown in different cultures, client and offshore team do not always speak the same languages. Words do not always have the same meaning and expectations are not the same.

 

As a westerner you will have the feeling that offshore team members are often eager to please the client. This is a natural feeling except that it becomes problemetic when dealing with a relationship focused on delivering output with tight constraints. I remember once where offshore engineer noticed a problem in the specification we wrote but did not ask for any precision and the problem resurfaced later. This is one major difference, where a western engineer would have noticed and ask for clarification.

 

Offshore team members can be often seen as eager to please you quickly. And as a result they sometimes do not go deep enough on certain subjects and try to answer you as fast as possible.

 

Another cultural difference to be also taken into account is that in asian societies, older managers/elders are often more respected (and consequently more effective) than younger ones.

 

Efficient ways of overcoming these communication issues during phone calls are:

• have at least one of the team send an agenda and status before the confcall meeting.
• to have both teams rephrase with their own words what has just been said. this is valid for both the local and offshore teams.
• have at least one of the team send meeting minutes after the confcall meeting if new items arose during the confcall meeting.

 

Have face to face meetings regularly both offshore and locally.

 

Offshore people should be able to travel to Europe or USA.

 

As a general "communication" advice, as I wrote it previously: ease communication as much as possible but rely on it as less as possible.

 

7.Read some offshoring articles

7.1 News and trends

 

7.2 Articles for reference

•  
• Why does offshoring failed:
  • Avoiding 'Gotchas' in Outsourcing Contracts : http://www.itbusinessedge.com/item/?ci=33144
  • Debunking Myths of Offshoring Failures : http://www.ecommercetimes.com/story/35308.html
  • The Case for Back-Shoring : http://www.sandhill.com/opinion/editorial.php?id=87&page=1
  • Offshore Outsourcing Failure Case Studies : http://www.ebstrategy.com/Outsourcing/cases/failures.htm
  • Offshore failure : http://www.linkedin.com/answers/international/offshoring-outsourcing/INT_OFO/158065-15559873
• Best practices:
  • What could be the best practices for outsourcing ? : http://www.linkedin.com/answers/technology/software-development/TCH_SFT/23725-1090830?browseIdx=4&sik=1173781739605
  • Using an Agile Software Process with Offshore Development : http://www.martinfowler.com/articles/agileOffshore.html
• Miscelleanous:
  • How to Evaluate the Communication Abilities of a Vendor : http://www.outsource2india.com/why_india/articles/communication.asp
  • Seven Myths About Outsourcing: http://online.wsj.com/article/SB118166189129632603.html
  • Software Outsourcing Issues : http://www.tatvasoft.com/software-outsourcing-central/outsourcing_issues.asp
  • The Hidden Costs of Offshore Outsourcing : http://www.cio.com/archive/090103/money.html
  • Some interesting offshoring theory from MIT : http://esd.mit.edu/people/dissertations/fuchs_erica.pdf
  • Why are you outsourcing? http://www.levi9.com/en-US/Pages/News.aspx?itemID=90

 

 

7.3 Understand the offshore job market (India)

This is also a good idea to wander in offshore related forums to get a better feeling of who you are working with.

• Get a view of the indian job market and the industrialization degree it reached:
  • http://groups.google.com/group/grkist?hl=en
  • http://groups.google.com/group/chetana_freshers?hl=en
  • http://groups.google.com/group/lookhere?hl=en
• Get a more specific view on how some engineers are recruited:
  • http://www.kyapoocha.com/
  • http://www.mywalkin.com/

 

You will soon notice the word "walk-in" or "walkin": Indian walkins / walk-ins

 

7.4 Listen to your partners concerns

Here are some concerns listed by offshore service providers reacting to this article:

• Client's goal are not clear enough and the big picture is not given. Offshore team is considered more as a 3rd party than a partner, which hinders good collaboration and understanding.
• Expectations are not quantified at project's start. That generates a lot of misunderstanding later in the project.

 

This may be the fault of local management or because local workers withhold some crucial information. That is why "1. Always take care of your local workers" is so important.

 

7.5 "Listen to cultural differences"

Listen  to indian classical music and you will get a feeling how western and indian cultures are so far apart and so close at the same time.

wikipedia

 

 

8.Evaluation using eSCM

 

Most of offshoring issues can be formally assessed and imporoved through evaluating offshoring processes using eSCM  eSourcing Capability Model which applies to both Provider and Client:

• What is the performance of the outsource/offshore provider?
• How are we handling outsource/offshoring process as a client?

 

Read more information here:

• Provider/Outsource/Offshore side named eSCM-SP The eSourcing Capability Model for Service Providers (eSCM-SP) v2 : http://itsqc.cs.cmu.edu/default.aspx?currentDDState=escmForSP&m=theModel
• Client side named eSCM-CL http://itsqc.cs.cmu.edu/default.aspx?currentDDState=escmForClients&m=theModel&spage=eSCM_C_overview

 

9.Conclusion

 

As a rule of thumb: An offshored project will cost 4 times less but will take twice the time to complete. But there is room for improvement... Improvement will come through building trust, trust and trust.

 

10.About Eric Mariacher

Eric Mariacher has held various positions in embedded software development, coder, architect, project manager at IBM and now functional manager for wireless keyboards, mice and receivers at Logitech. For each of these projects he chooses the best organizational solutions to achieve its goals: internal, local outsourcing or offshoring, in one word best-shoring.

 

Eric Mariacher main centers of interest are to set-up the right environment for software developers to deliver products, and also to give management the best visibility on software development process from requirement phase to field support phase. Setting up the right software development often requires reengineering software development processes. Eric Mariacher enjoys driving these software development processes.

 

In parallel to those activities, Eric Mariacher is heavily involved in the professional social networking area. He regularly writes articles, give advices and connect people so that he and his connections can find new exciting opportunities.

 

Eric Mariacher can be reached at eric.mariacher@gmail.com. http://www.linkedin.com/in/mariacher

 

Recent Visitors  :

You now

 

3/26/2007 Page 1 © 2007 Eric Mariacher. All rights reserved.