In 2000, offshoring was not a new concept as many large companies had already been offshoring and outsourcing for over a decade. What did change, in the past 10 years was how many companies began outsourcing and how many development tasks were being distributed.
It was not only Texas Instrument and Microsoft sized companies distributing maintenance projects, but it quickly became medium and small sized companies outsourcing or opening their own offshore facilities for varying development tasks, maintenance, new product development, and testing.
This pace of outsourcing has accelerated exponentially over the last decade. The necessity of outsourcing/offshoring has also increased. Whereas most people think of distributing software development offshore as only a cost cutting measure, it is more than that.
For example, there are not as many new U.S. software engineering graduates today. This is causing a shortage of skilled developers and test engineers. There is also the factor of quick ramping up and ramping down of project teams influencing more contracts and distributing resources.
However, the downside of more distributed development is increased management oversight. Visibility into work at remote sites is often a common problem as well as frustration with communication.
In the past 10 years, there have been notable events profoundly impacting global distribution. For instance, the emergence of Agile and Scrum caused many groups to re-think how much and what is distributed. Most Agile teams are co-located for immediate and easy communication, especially verbal discussion on newly developed functionality.
This immediate and easy communication is supposed to lead to leaner product development, e.g., less documentation. This is often difficult for distributed teams. On the other hand, there is also the impact of communication tools. With the introduction of communication platforms such as Skype, Cisco’s UMI telepresence and the full range of instant messaging tools, common communication has become much easier.
In my capacity as a test lead then a test manager at various U.S. companies, I have worked on both sides of outsourcing and offshoring situations. In the late 80s, I worked for a company outsourcing and offshoring software development to Bulgaria, and at another company sending offshored documentation development to the Bahamas. More recently, I am the cofounder of LogiGear where we provide outsourced engineering services mostly based in Viet Nam.
From my experiences─the successes and failures─I will explain what I draw from them. In the following section, I list 10 important lessons learned over the past decade on how to make offshoring a greater success and higher value for you and your organization. For the sake of convenience, I will refer to the various models as distributed or global development.
- Build a Relationship
-
Rome was not built in a day! Neither are good working relationships. Take time and be patient. Think of local/home team issues, problems, misunderstandings—work to avoid these same issues with the offshore teams.
- Governance
- Make sure you manage your vendor with metrics against an SLA
- Make sure you manage the relationship effectively and setup good management in the beginning
- Set up a separate team to manage the outsource vendor
-
Remember to focus on the value the distributed team is providing. Communicate and focus on getting the business value you expect; your attention to goals will transfer to the distributed teams.
-
- Invest in Your Partner
- Invest in Training
-
Deliver training in the test and development process, technologies, domain, tools, communication, reporting, working across cultures, etc
-
- Build trust
-
Don’t think once the process and tools are setup, you’re done. You are only at the beginning! There is much more to offshoring than just setting up the operation.
-
Make time to get to know the new staff. Have the new staff get to know the onshore staff. Take photos. Make a board with everyone’s pictures, names, and role.
-
- Invest in Training
- Focus on Communication Infrastructure
- Build a communication infrastructure and tracking system. Don’t rely on instant messaging.
-
Make a communication plan for methods, days of the week—especially Sunday and Friday—preferred times of communication to make reference easier, boost task tracking, reinforce agenda, task lists, action items, etc.
- Build project wikis and document sharing formats.
- Conduct training in communication skills.
- Visit Your Team
-
Build rapport and trust. Visitations make you and your team human and real instead of merely a headcount and a boss. Visits have profound impacts on working relationships and building bridges of understanding.
-
- ALM- Implement an Application Lifecycle
- Management Tool
-
Implement an application lifecycle management tool or set of tools, including user story/requirements management, change control, test case management, test automation tool interface, issue tracking, source control, ftp, and/or code delivery. This will centralize processes, tools, focus and reduce a lot of uncertainty. It can be a single source location for all answers.
-
- Its human!
- Do not underestimate the power of human connection.
-
It is easy for projects to get off track. If it was all fun and games, software development would be teaming with people. It’s not
-
There are inevitable problems to be resolved. When I have local team members in different locations that I never see, talk to, have lunch with─the interactions may be rough. Expect the same with offshore teams until bonds are built.
-
-
Understand the culture and its differences: “Cross-cultural communication,” “Working with Americans” or “Working with Whomever” training will have a profound impact on teams.
- Soft skill training and work are always the most important.
- Honesty and trust are more important than test case metrics.
-
Human issues run both ways. U.S. teams having late night Sunday phone calls to begin the work week in Asia will lead to job dissatisfaction, retention and political problems. Cultural differences, time zone issues, communication roadblocks need to be talked about, not ignored.
- Do not underestimate the power of human connection.
- Start Small, Do a Pilot
-
Choose a small project to begin the relationship, refine expectation, clarify deadlines, build a regular schedule, and focus on good communication.
- Choose your project to distribute carefully
- You don’t want to send the key to your company’s revenue growth as your first assignment.
- Start with low hanging fruit that might help setup the vendor for success.
- Choose your project to distribute carefully
- Make sure you understand what it takes to do the work before you send it offshore.
-
- Home Team: pay attention to how this is going to be for the employees at home
- The home team may have an altered career path and need different skill training.
-
Training for the home team is often neglected, consequently they will need communication and cross-cultural training as well.
- Be careful what you ask your domestic employees to take on. You don’t want them resentful.
- Do you have employees who want to work into the night with offshore teams?
- Can you stagger their hours so that they can work effectively?
- What about quality of life impact?
- Are the tasks distributed fairly?
- Be Realistic
- Expecting perfection or expecting a miracle can be dangerous.
- Expect glitches at the beginning; it’s how the teams grow and adapt.
- Have patience and work through problems, just as you would with building a team in your home office.
- Build Subject Matter Expertise
-
Home teams are sometimes staffed with subject matter experts or people who will easily relate to and model your users. This is most often not the case for your offshore teams. Make an effort to introduce teams to your target users─their needs, work habits and patterns. Show your competitor’s or similar products. Describe the varieties of users you expect to use the product and what they want. Your life will be easier, your goals will be accomplished, and quality will be higher when you transfer business expertise to your distributed teams.
-
In the end, it’s the relationships and people that matter the most. In all matters, remember the Golden Rule: treat others as you want to be treated. You can’t fail!
Key Words
Offshoring is taking work that used to be done in a home office and sending it to an office of your company’s in another country, most typically moving from a High Cost Center (HCC) to a low cost center (LCC). These offices are sometimes called captive offices if they belong to your company.
There is a newer situation called nearshoring. After 2000, offshoring from the U.S. mainly went to India. That’s about as far offshore as American companies can get with a twelve hour time difference.
An example of nearshoring is an American company sending work to Canada, Mexico, Central America, Brazil or another South American location that is closer in time zone allowing an overlap in normal working hours. These countries may not be as low cost as some Asian or African countries, but the time overlap is seen by some companies for higher productivity and less stressful work.
Outsourced offshoring is the most common situation we read about today. It is a company with a home team taking some of their work and sending it both outside the company and to another country— whether its companies the size of Citibank or a Web2.0 startup with twenty employees—sending their software development to a small boutique outsourcing company in Nicaragua.
Distributed software engineering and global development are commonly used phrases signifying any variety or combination of distribution arrangements: multi-sourcing, combinations of offshoring, outsourcing and multi-site development.
