From Softjourn's CEO

What this means: As a business supporting clients who are using your product or service on a daily basis, usually 24 hours a day, you will no doubt need 1^st line technical support, i.e. a critical bug is found in the system, perhaps something that is miscalculating payments thus you are undercharging those using your service, or the system crashed due to a set of circumstances which never came up in QA testing.

What they mean? I have a lot of responsibility here in the US, and will most likely need support and people to do tasks at the last minute as we move work in to production or as bugs come up in production. I am concerned about having all of that offshore. 

Actions to take: For many businesses you may definitely need this. Enter in to a frank discussion with your VP of Engineering, operations manager, and other critical personnel who are engaged in serving your clients and in developing the product, and determine your options.  Some possibilities could be the following:
a.  Have a person/s in-house who handle this critical product work. It may be a separate engineer who works with clients and also knows the code.
b.  Have the outsourcing company provide an onshore resource/s for this work, on demand, or an offshore resource that works US hours specifically for these situations.
c.  Ensure that you have a technical support communications plan which includes: For which type of situations will someone be contacted offshore, who will be contacted, and by what means will they be contacted (mobile phone call, text message, etc.). Also include how long the offshore person has to respond to the critical message, i.e. if they do not answer your phone call right away, but it goes to voicemail, how long do they have before they must call you back (within a half hour, etc.). How will they begin working on the problem, are they authorized to do this work from their home computer, must they go in to the office, etc. 

Leaving the decision, whether or not to outsource offshore, to your VP of engineering alone may not get you the results that you need for your company, because you have to understand the easiest thing for them to do is to work with resources that are right next door.  You are not the first CEO to have to deal with having to lead your company through this type of a change. CEOs trying to implement ERP systems even, deal with many of these same issues. Change can be difficult and is not always welcome. You have decided that this is best for your firm; you have to decide if those around you are the right persons to help you move this process forward.

What does this mean: Offshoring only helps the offshore location and won’t help us. 

What do they mean? We are afraid that either our job will be lost, or the jobs of our colleagues.

Actions to take: This is a sensitive issue and needs to be discussed openly with the management and with the rest of the company. It is time to have what could be a difficult, but ultimately a very beneficial conversation. In part whether or not this question arises, and to what extent it arises will depend on the culture of the company. Are we open to working with resources no matter where they are located? It is a good opportunity to engage in a frank discussion with the management about what is necessary for the growth of the company, and to get their opinion about what is the best way to grow the company. If your competitors are working offshore, and are able to do more with their development budget, then find out from your staff what they would like to do in order to be able to compete. Their answers and involvement in a solution will be extremely helpful, and if in the end you all decide that offshoring is best for your company, they will be on board with it and not fighting every step of the way. In the end of course, it is your responsibility as CEO to do what is best for the company for the long-term, but this conversation could do a lot to open you up to other options and to eliminate a lot of unnecessary speculation and worry for your current staff.

What this means: This can mean a variety of things; sometimes it means we do not have anything written down, i.e. any specifications, any definition or the structure of our application is not written down, our code is not solid enough or it could mean we do not know what we want to outsource yet.

What do they mean? We do not have time to do all of this work so that someone else can do work for us, we do not see the value in doing this, and we can do all work ourselves faster.

Actions to take: I have heard this many times from companies, if you hear this from your VP of engineering, always ask what they mean by this. Engage in a working session with your VP of Engineering and the rest of the management team and determine what really the issues are? You may find that, for some of their concerns, you already have answers under reasons already discussed in this dialogue. Additional meanings that often fall under the  “We are not mature enough” reason, I will discuss here. 

We are not mature enough: Our code is not solid enough! If your team is currently in the middle of putting out a new release and it is all hands in, and the plan is going well and the existing team will get the new release out on time, with all client required features, then great. This is a good time to get started with an offshore team, because they will take time to learn your system, and they can be ready then to start doing real work by the time the final release is delivered and you need to start supporting the current release and planning the next one. Waiting until you put out the new release and you have to support the existing release and start working on the next one will mean again your team will not have enough time to better plan their work with an offshore team, and it will be put off again. In this case it can be better to brainstorm how you can get started within your current situation and how an offshore team can be used for the long term.

We are not mature enough: We do not have the structure of our application written down, it will take someone a long time to lean the structure and we do not have time to write something down! This is a typical issue in many companies, coding begins before a design is fully written down, or the product was defined initially but as client validation goes on, the product morphs and documentation never catches up. A good first task for your offshore team can be to have them define the structure of your current application. If they are experienced programmers, they are used to diving in to code and finding out how it works, what it is meant to do, and how modules, libraries, and databases are linked together. Having them write this down at the beginning is a good knowledge transfer process and will benefit both the offshore and the onshore team in the long run.

We are not mature enough: We do not know what to outsource yet! This could mean that your VP of engineering feels they need to define a very special project to outsource and they just do not have time to do it. If you are like most companies, your firm has a number of projects waiting in the pipeline, special requests from clients, features you know you have to add in order to be competitive, in other words, more projects than you can possibly complete. When considering an offshore project, especially the first one, it is important to take care, but it is important to realize that it does not have to be perfect. We have started with some clients with very small printer projects, lasting only a couple of weeks. Normally we recommend that your first offshore project should be around a month, to really give you a good feel for the process and to test the skills of the offshore team, but if a month long project is not available, start with the next best thing. Waiting for that perfect project will just postpone getting started and getting your feet wet. Look for a project with the following features:

• Not mission critical,
• Short, 4 weeks or less,
• Something you have been putting off, but needs to get done,
• One that can be explained verbally to the offshore company and for which they can define the specs.

In other words: Only people from the same country can relate to each other and can successfully work together.

What this really means?  We do not want to outsource or work with offshore resources.

 Actions to take: Engage in a discussion with your VP of engineering and ask the following, “Why do you think this is a requirement?” The most common answers are: “Because they won’t be able to understand the nuances of what we are asking them to do.” or “It is better to have a native speaker of a language speaking to another native speaker.”

While being from the same country has its upside, it does not guarantee success. In our experience if you do not speak the same native language, you will not take communications for granted. You will work harder at not having any misunderstandings. If the onshore and the offshore are from the same country, often times more assumptions are made about the type of work to be done, and the expectations.

I have also seen occurrences of an ‘us versus them’ scenario when the onshore manager or coordinator is from the same country as the offshore team; us being everyone from that country and them being everyone else in the company. These ‘us versus them’ scenarios can lead to the offshore team not integrating in to the company, their work not being seen as important or visible enough and more difficulties in trying to roll out more work to the offshore location from other parts of the company. So while it can be helpful to have people on both sides who speak the same native language, it should not be a requirement for getting started offshoring, as it can bring as much downside as upside.

What this means: Managing persons who work remotely does take effort which can take more time.

What do they mean? This is too much work for me, or I am not familiar or comfortable with managing offshore resources, or I do not want to be up all night managing them.Â

Action to take:  Managing remote resources, no matter where they are located, does take extra work; it would at best be part time work. A good rule of thumb can be, for each five person’s offshore working on two different ongoing projects, approximately 8 hours a week will be needed by someone onshore to write specifications and check in daily with the team, check their progress, answer questions, assign tasks, etc.. At 25-30 people it may take one person full-time to work with this team, depending on how many individual projects they are working on. It may end up that the best solution for your company is to have another member of your in-house team and not the VP of engineering communicate daily with the offshore team, write specifications for them, answer questions, and fully engage them in your development process.

Another option may be to have your outsourcing partner manage the offshore team, doing all of the interface work. This can be a good alternative if in-house resources are stretched thin, it can be a good way to get started. If you do start this way, plan with your outsourcing provider the path towards your company eventually taking over the interface role with your offshore team.

What this means: The concern is that if we are not working the same hours as they are, they will not really be doing any work.

What do they mean? The remote team could not possibly be working during their normal business hours and actually get work done without us being in constant contact with them.  We do not have time to do this, we do not see the value in doing this, and we can do all work ourselves faster.

Actions to take: Engage in a conversation with your VP of Engineering revolving around the following topics: Do you often answer questions every hour for your in-house software engineers? Can they work on their own at all? There should be no questions that should stop a remote team from working entirely. The same as your in-house software engineers are able to grasp concepts and move on and work on their own, you want your offshore engineers to do the same thing, to take initiative and show and independence in their work.

I know persons who think they have to be working at the same time as the offshore staff. I have managed remote teams for years, and I never do this. Why, because it defeats one of the major benefits of having a team working at opposite hours from you. They can be doing work while you are sleeping and vice versa. I do not mean working on the same code, but this could be testing in one location and writing code in the other, or writing requirements in one location and reviewing them in the other location, etc. If you are working opposite hours, you can always have results waiting for you in the morning. It also does not wear you out. It is not easy to keep an overnight schedule in the US and still keep up with your family and the rest of your life. The same goes for the offshore location, do not force them to overlap their entire work day with yours (unless of course it is a call center and they are supporting customers during the work day in the US). You will lose a major advantage in this way.

What this means: Specifications for features, enhancements, etc., should be written down, defined, and diagramed so that the programmers know what to do.

What do they mean? Our application/s are very complicated and take a long time for someone to understand. We do not have time to do this, we do not see the value in doing this, and we can do all work ourselves faster.

Actions to take: Enter in to a discussion with your VP of engineering about how he/she handles it when they bring a new software engineer in-house who is not familiar with the application nor with the code? How does he/she, or someone else in the group, explain what the new feature/s need to do and what needs to be done? Is it just an oral explanation and a couple of words about where to start looking, in what modules to start looking, in order to make any necessary changes? Technically your new team can start in this same manner, even if they are offshore, with the understanding that it will take them as much time to understand the application as it would for a new software engineer that you would bring in-house. A new software engineer to your team may have to hunt around for a while in order to understand the structure of your application and in order to determine where to make changes, how to add features, but they will eventually get it. Often times a good way to get them started understanding your application is to have them perform maintenance tasks, bug fixing, small enhancements to the code. If you begin working with a new team in this manner, very detailed specifications will not have to be done initially.

Make a rough estimate, together with your VP of Engineering, for each project in the pipeline, how much time it will take to write specifications versus the development/testing of each project. Chances are none of them will be exactly equal in the time needed to write specifications versus the time needed to actually do development and testing of the final product. Alternatively, if no one in the company has time to write the specifications for each of the projects, this is work that can be done by many of the outsourcing firms. Many of them have staff in the US as well and can bring a person in to your organizations to gather and write requirements.

What this means: They will start a competitive business on their own or they will sell our source code to our competitors.

What do they mean: We do not have time to explore how to protect ourselves, we do not see the value in doing this, and we can do all work ourselves faster.

Actions to take: If you determined, based on Reason #1, that your source code is your competitive advantage, then discuss with your management team the following:

i) Look at how easy it is to start selling it to your market? Will others be able to start up from scratch to build a reputation? How many competitors do you have? Is this market so small that everyone knows each other? If so, if someone starts up as a new competitor, is it going to be obvious?
ii) Will they be able to sell your code to your competitors such as in the Solidworks case in India (http://www.csoonline.com/read/110103/outsourcing.html?action=print)?  If your competitors are other US companies, would they buy it?
iii) Can your outsourcing provider take your source code and start selling your product or providing a similar type service in the market where they are doing the development? Is there even a market for what you do in that offshore location? Many of the offshore locations do not have mature business markets that need high-end software nor are they demanding it. Discuss the possibility upfront and who would own the local market.

Explore steps to protect your intellectual property with your management team and your outsourcing partner (the same can be followed even if you have your own office in another country):

- Does your outsourcing partner use activity monitoring software, and does someone actually monitor the reporting coming from the software. In this way they can see if code is being copied to flash drives or being sent via email to their own or other web addresses.

- Require that your source code is uploaded to a server in the US, your server, or to a server of the partner companies in the US, at a minimum of once a week, if not more often. This includes all code that is currently in the process of being written. In this way you will always have the latest code available to you even if team members change in the offshore location. Periodically monitor what is actually being uploaded.

- Inquire how intellectual property is viewed within the outsourcing partner’s company. Do they educate on intellectual property and how it should be protected, does this include educating on social engineering.

- Ensure proper legal protection by at a minimum assuring that your offshoring partner signs NDAs directly with each of your team members and that you also sign NDAs directly with each of team members. Look at the contracts between your outsourcing partner and their employees, who owns the work that they are doing for you. How are rights assigned back to you.

What this means: This is necessary so that the outsourcing/offshore company will not have to have access to all of your source code which in turn will cut down on the possibility of their stealing your code.

What do they mean: We do not have time to do this, we do not see the value in doing this, and we can do all of the work ourselves and faster.

Actions to take: Determine what your competitive advantage is. Is your source code your competitive advantage or is it your customer base or your process? If you answered your customer base or your process, you can feel more confident with an offshore team having access to your source code (While still taking steps to protect yourself as you should in any outsourcing situation, whether onshore or offshore.). Your process and your customer base are much harder to replicate if not impossible unless your outsourcing partner sets up a sales and marketing and management structure similar to yours. If you answer that your source code is your competitive advantage, see Reason #2.

For your information: As part of your discussion with your VP of information, in almost every case, it is possible to assign development to a new team of developers that states: this module will call this particular function, send this data to it, and get this data back. The developers should be able to write the code that will call this function, send this data and get this data back, without actually testing the execution of the real function. You can do it in this way so that you do not give access to all of your source code, all of these functions, to a new development team. Final testing then can be done onshore by your in-house team. There is nothing wrong with this, particularly at the beginning when you are testing out how the offshore team performs. Your engineering staff may refer to this as writing a stub.