It seems that everywhere you look, companies are looking to create near-shore and off-shore partnerships, to increase their software development capacity and reduce costs. Interestingly, this is not limited to large companies; more and more SMEs are joining in. At the same time, we now have over a decade of experience with this topic in the industry, and have learned some hard-earned lessons. It seems not that long ago that companies were pulling back from off-shoring due to a significant number of challenges in making the partnerships effective. In general, it seems that the odds of failure are higher than the odds of success, and that some managers swore off the topic completely. Personally, I have a mixed track-record, with some notable successes and some notable failures. In my experience, a big reason for the high failure rate is a set of pitfalls that are only obvious after you know about them. I list here the pitfalls that were the most significant in my projects, in the hope that others can avoid them.

Logistics

A surprising number of partnerships get into trouble because of mere logistics. While all points in this category appear obvious once you know them, many also appear simple, and managers often ignore them under the idea that the teams will somehow adapt and overcome them without an explicit effort. Unfortunately, in my experience, this is almost never the case. The teams are often used to doing things without having to invest the effort into these kinds of logistics, so to them it often feels like problems they shouldn't have to deal with. If they are already not inclined to embrace the off-shoring or near-shoring partnership, they will view this as a sign that the partnership was a mistake, instead of working through the problems. Either way, logistics can create significant headwinds that you need to plan for and actively ameliorate, otherwise the will degrade they effectiveness of the whole effort.

Timezones

It may sound simple, but a significant difference in timezones means a significantly reduced amount of overlap between the teams during a work-day. This limits both the communication bandwidth, as well as the flexibility in scheduling necessary ad-hoc communication (when there are unforeseen issues, for example). The overlap between Europe and India is down to 3-4 hours a day. This means that it only takes a few meetings to consume all available bandwidth. If, for example, you are a Product Manager attending the demos of 3 different Scrum teams, you will either consume the entire block for a day, or you will force the teams to have staggered sprints. Another common problem is that communication becomes highly inflexible, so things often spill into the next day. Imagine having your support and operations in Europe, with the engineering teams in India. If a production issue shows up in the afternoon in Europe, the engineering teams are already away for the evening. The issue either has to be dealt with without involving the engineering team, with the associated loss of effectiveness, or has to be deferred until next morning, with the associated loss in response time. Incidentally, it's worth noting that the overlap between the US and India is essentially non-existent. This means that there is no time to schedule meetings without someone working off-hours, and that everything unplanned spills into the next day.

The timezone issue is the one factor where near-shoring has a distinct advantage. Timezone differences are by definition smaller in near-shore partnerships, and the problem is significantly reduced. This is one of the primary reasons to pick near-shoring over off-shoring.

My first piece of advice is to maximize overlap as much as possible. This can be achieved primarily by picking the location, but also by shifting the work hours of the teams. Most engineers I know would even prefer to come to work later, so if you can have an India team that starts work later in the day and stays at the office until later, it can make working with a European team much easier. My second piece of advice is to plan as much communication and coordination as you can. Certainly all the regular meetings (planning, backlog grooming, demos, retrospectives, etc.) should be planned well in advanced and the plans should be adhered to. In addition, plan short meetings with no defined purpose, that you can use if there is something to discuss, or cancel if not. Also, plan events that can result in unforeseen issues, such as major releases, for the beginning of the overlap window.

Language

By definition, near-shoring and off-shoring involve teams in different countries, and therefore involve a language barrier. In general, the working language becomes English, and most people in the field speak it to some degree, but often with the result that it is not the native language of either location. This tends to create headwinds in communication. To begin with, team members that are uncomfortable with the working language tend to avoid direct communication, and either opt for indirect communication (telling a local colleague and hoping the message propagates to where it needs to), or defer communication altogether. In addition, people often resort to written communication, email in particular, which tends to be less interactive and less flexible. There is also the subtle effect that, whenever various options are being discussed, there is an inherent bias that favors the opinions of those that are comfortable with the working language, and against the opinions of those that are not. This means that, all else being equal, it is not the case that the best option will be the one chosen.

My advice is to treat language as a requirement when staffing both the local as well as the remote team. I tend to put it on the same level as the technical requirements, especially for the senior members of the team that have the most impact. In addition, I would recommend that major discussions (e.g., architecture sessions, system design, etc.) are facilitated and/or moderated by someone who ensures that options get discussed on the basis of their merit, rather the ability of their sponsor to explain them in the working language. Also, encourage people to draw on the white-board, or type sample pseudo-code to explain concretely what they mean. This tends to reduce the criticality of language skills.

Communication Infrastructure

I tend to believe that this is the most commonly under-appreciated of the logistics factors. Your communication infrastructure can add a significant amount of friction to the entire process. Communication is already difficult enough given the other factors, so make sure you are enabling any mode of communication that may help. Do not rely on just email and voice; I would add chat, video-conference, and remote presentation capabilities at a minimum. I would generally recommend strong screen sharing capabilities, and a document collaboration system (Confluence, SharePoint, GoogleDocs, etc.) in addition. This is an area where small investments can provide a significant return in terms of effectiveness, so exercise that option. There is no lack of tools - pick one (or more) that work for everyone involved, and use it heavily.

Also, be careful with the quality of your infrastructure. The reliability of the underlying technology is not the same in all parts of the world. Do not assume that a tool that works reliably within your home location will work as well over the Internet to the remote location. You may need to invest in dedicated communication infrastructure if you have a significant remote site, otherwise you may find yourself occasionally having to cancel meetings because the tools refuse to cooperate.

And one final piece of advice: put in place some way of transferring large files (10s of GBs) between sites; while you will not use this every day, you will save a day every time you need to use it (and you will need to use it).

Travel

We all know that teams need to spend time with each other in order to be effective. Time interacting face to face tends to reduce the impact of all the other headwinds, especially the cultural ones. This, of course, means travel, which is costly and burdensome. Besides the direct costs, there are also indirect costs (loss of working time while in transit, loss of effectiveness due to jet-lag, etc.). The burden of travel is probably something that everyone who is reading this article is personally familiar with. That being said, it is essential, so just plan to make the most of it. Travel is the other major factor where near-shoring tends to do better than off-shoring, but this is highly location dependent and does not happen automatically. It is worth paying attention to this when picking the partner at the remote location. Kaunas (in Lithuania) is only one timezone ahead of Zurich, but traveling there I first had to fly to Copenhagen, then to Vilnius, and then take a 90 minute taxi to Kaunas, making the trip essentially last a full-working day.

Make sure to invest in reducing the burden of travel, otherwise you will find that your teams tend to resist traveling. It's worth it to not go for the cheapest options in hotel and flights, if it makes a significant difference in how burdensome the travel becomes. For example, I would be OK with spending a bit more on flights if they didn't require people to travel at ridiculous hours, or have very long layovers. Having a routine (including ground transportation) ready can make a significant difference, as it reduces the associated stress dramatically. Not everyone views business travel to a new location as an exciting adventure.

I also find that having less frequent and longer trips tends to be both more effective and less costly. Traveling once every other month for two weeks gives you the same time on location as traveling every month for just one week. This time, however, is more effective because of the reduced impact of the indirect costs (time lost during transit, plus the effects of jet-lag). It also saves on a set of flights. At the same time, it all depends on the locations - I would not plan a two week trip for travel to a destination that is two hours away.

Also a lesson learned the hard way: don't over-plan the trips. Make sure you leave a significant amount of time uncommitted. First of all, unplanned things will come up. If nothing else, people often leave complicated or sensitive topics for when they will meet in person, when they know a trip is coming up. Second, a key reason for bringing the teams together is for them to get to know each other and build (and maintain) working relationships. This is unlikely to happen if you have already committed all available time to operational activities.

Alignment in Objectives

A misalignment in objectives is one of the major reasons for failure in near-shore and off-shore projects. Quite often this is because of the contractual agreement being structured the wrong way. Sometimes, it is because the partners are not clear on what the objective of the partnership is.

Contract Structure

The contract contains a definition of success and failure, and as a result tends to create both intentional and unintentional incentives. Business necessities (especially cash flow) can make these incentives extremely powerful drivers of behavior; when this is intentional then that is a good thing, but when unintentional it can effectively sabotage a project. The easiest example to think about is the standard, fixed-price contract. At the top level view, this type of contract emphasizes delivery of a single, fixed, unit of work at a specific time. Changes are not welcome! This means that such contracts are unsuitable for anything that contains significant amounts of uncertainty. If the uncertainty manifests itself as changes in requirements or scope, these translate to change requests, implying a high overhead process with long lead times, and significant additional cost. If the uncertainty manifests itself as a risk that implementation will take longer, there will be a strong tendency to take shortcuts, especially towards the end of the project. At the same time there will be a tendency to rationalize (post facto) these shortcuts, which means that they will not be reported as risks or technical debt. That, combined with the fact that delivery is focused towards the end of the project, means that you will never have good visibility on whether a project is on track until it is too late. Furthermore, in a fixed price contract, the risk is assumed completely by the implementation partner, making them more risk averse. This means that they will resist any attempt at innovation, or even just technology choices and designs that push them outside their comfort zone. Overall, unless the project is for something that is very well defined in scope, of low technological risk, and where you might not wish to exercise any significant design control, you should avoid fixed-price contracts. When you do opt for a fixed-price contract, make sure you create many intermediate milestones, each of which requires a fully deployable and testable piece of the software to be delivered, and tie intermediate payments to successful completion of the milestones. The goal is to be able to assess how the project is progressing from each individual milestone. Therefore, you should focus on milestones that span the complete set of activities and non-functional requirements as the entire software - they should be fully tested (with automated tests included, if that's part of the deliverables), performance and resource tuned, deployable with your final deployment mechanism on your final environments, etc. If you allow the milestones to defer these requirements, you are likely to find that there is a mass of complexities that will only become visible towards the end of the project, and you will, therefore, never have a good understanding of the true status.

If the project is not suitable for a fixed-price contract, then you will probably need to fall back to Time & Materials (T&M) or Reserved Capacity. For all intents and purposes these are the same, except that for Reserved Capacity there is generally the expectation that your implementation partner will take all reasonable measures to ensure that the team members are not moved to other projects (there is no such expectation by default in the case of T&M). Make sure that you explicitly state in the agreement what level of control you expect to assert, and what the implications are. For example, you will typically want to control the scope, with the understanding that estimates may change as you make changes. Depending on your needs, however, you may also wish to exercise architectural and design control, with the possibility that either the teams will have to be trained, or team members will be exchanged if you introduce technologies and practices that are not familiar to the current team. Again, detail who is responsible for the impact of these decisions: if the partner is responsible for retraining the team at their cost, don't be surprised if they resist changes that require significant additional training. If you undertake the cost (by paying for the re-training time), then make sure you include the cost and time in your cost-benefit analysis as you make design decisions. An additional issue in T&M or Reserved Capacity contracts is how to measure the performance of the team, and possibly remediate any deficiencies. In essence, the client is generally accepting the lion's share of the risk in these contract types, in exchange for the extra flexibility, control, and visibility. The implementation partner now has an incentive to take greater risks, possibly reducing the overall performance of the team. There are no good canned answers for how to address this; it's best to simply discuss it openly with the partner, and jointly come up with an approach that works for both sides.

Note that you may, at some point in time, find yourself executing multiple projects with a partner, each of which may have different characteristics, and therefore requires a different type of agreement. Therefore, I am inclined to only put the basics in the Master Service Agreement (MSA), and leave most of the factors discussed above for the specific Statements of Work (SoWs).

One final note, in case it was not obvious already: if you are planning to use Agile methodologies with your partner, avoid fixed-price contracts!

Setting the right objectives for the partnership

Before you can even determine the correct structure, you must decide on what objective you are trying to fulfill. For most partnerships, this falls into one of the following:

• Prototype Development: Usually involving one, or a series of prototypes, none of which are committed to for the long term yet. By their very nature, these tend to emphasize flexibility and agility. The scope is quite unclear, and there is a need to evolve it as the projects moves forward. In general, you want a flexible contract structure, a team that is willing to experiment, the ability to have significant control over scope, and you should be willing to leave architecture and technology up to the team in order to gain speed. Non-functional requirements are not particularly important (with the possible exception of quality, and sometimes security) as there is no plan for the prototype to see significant use in the field.
• Long-term development and maintenance: Almost diametrically opposite from prototype development, this involves a long-term effort to enhance, further develop, and maintain a particular product. The scope is on-going, with new items coming into the backlog as older items are completed. Agility is often required in order to create a great user experience. There is less of a need to experiment on the architecture and technology side, although there might still be significant experimentation on the functionality side. Non-functional requirements are extremely important, as the impact will be felt across a large user base. You will generally desire to have control over architecture and design, as you will eventually be responsible for operating the software. Overall, this generally requires Reserved Capacity agreements, with the partner assuming significant ownership of the product. It is important to have a stable team in order to retain acquired knowledge as the product evolves.
• Develop to transfer: these are projects where the partner develops the software, but then transfers it to the client for long-term operation, enhancement, and maintenance. Depending on the nature of the project, the scope may be fixed or flexible: for projects that involve the first production implementation of a product (often after successful completion of a prototype), the scope will still be quite variable. Another common scenario, however, is re-engineering existing products to reduce technical debt and/or change technology stacks. In this case, the scope is fairly well-defined. In both scenarios, a certain level of flexibility is required: in the first implementation case in order to accommodate the loose scope, and in the re-engineering case in order to accommodate technical uncertainty and compatibility risk. In addition, since the target is to explicitly transfer the software ownership back to your teams, you will generally want to control architecture, design, and technology choices. Overall, this requires one of the more flexible contract structures, but without a need for a long-term commitment to keep the team the same.
• One-time projects requiring foreign expertise: these are projects that require expertise that you as the client do not have, and do not plan to acquire because it is not an on-going part of the product. A classic example is implementing an ERP or CRM, or an integration into an ERP or CRM, in cases where this is not part of the product offering. In these cases, the need for the expertise in question tends to be sporadic, so there is little sense in building and maintaining it in-house. Instead, one can simply outsource this to a partner. Generally the scope is fairly well-defined. Since the client does not have the expertise, there is no need to maintain control over architecture, design, and technology decisions. At the same time it is often beneficial for the client to be able to contain the associated risk, since they do not have the expertise to assess and manage it well. As a result, these projects tend to favor fixed-price contracts.

Note that at any given point in time, you may have multiple projects (with the same partner) falling in different categories. It is also not uncommon for projects to move across categories, especially prototypes moving across to either long-term development or develop to transfer.

The important thing to take away is that, not only the contractual agreement, but also the way the local and remote teams work together, and the expectations for, and composition of, the remote team(s) will be different in each category. It is, therefore, critical that both sides of the partnership are clear on what the objective is, and what the expectations are. If not, the teams could easily find themselves working towards different targets! The best advice I can give, is to have a joint kick-off at the beginning of the project and lay the objectives and expectations out explicitly in the kick-off.

Encouraging team acceptance

It is very common for the local teams to feel like a near-shore or off-shore partnership is a slight to them, completely unnecessary, and a greedy attempt to replace them with lower-cost workers. After all, if it wasn't for the lower cost, why would such a partnership make sense (keep in mind that engineering teams rarely, if ever, think in terms of capital expenditure, risk management, balancing exposure to revenue in foreign currencies, non-resident expertise, etc.)? In short, more often than not, the local team comes into a partnership with a bias against the effort, and a lack of understanding as to why they should contribute positively to it. Needless to say, this is a serious headwind that needs to be tackled, and cannot be allowed to fester.

In my experience, this can be best be done by undertaking the following:

1. Presentations where the sponsors explain what objectives the company is trying to accomplish with the partnership, what other options were considered, what the expected outcomes are, what the role of the local and remote teams will be, and what the future holds. Expect to hold multiple sessions, as people will need time before they are ready to engage with the topic.
2. A question and answer session where people are allowed to ask their questions about the need, the rationale behind the partnership, the future of the local teams, etc.
3. Opportunistic communication within context, as the effort becomes the topic of conversation as a side-topic in other meetings, or around the coffee machine. Generally these informal communications seem to be the ones where people are most receptive, as they (rightfully so) feel that they are engaging in a bilateral discussion instead of listening to a formal communique.

That being said, different teams respond to different techniques, and any form of communication that works within your company culture is fair game. I just can't emphasize enough how important it is to gain the acceptance of the local teams.

Culture differences

Everyone who is reading this probably already knows that differences in culture can significantly complicate teamwork between teams in different locations, so I will not waste time describing how cultural differences play out. I do, however, want to point out the two most common and harmful modes of failure:

1. Mistaken Expectations: these are cases where cultural conventions in one location would lead someone to believe something, whereas in the other location the same belief would not be held as justified. To explain by example: the phrase “I am fairly certain the project will be completed by date X” would automatically imply a certain level of commitment in some locations. In the US, where I spent quite a few years, this would effectively be considered a promise, if given by a partner. The same level of commitment, however, is not reasonable to expect in other locations. Without naming specific countries to avoid stereotyping, there countries both in Europe as well as in Asia, where someone saying the above sentence would not reasonably imply a commitment to deliver by date X. The same sentence means two different things to people from different locations, however, we are naturally so used to making the assumption that corresponds to our location, that we often never think to ask what exactly our partner meant. My advice would be to practice recognizing when you are making assumptions, and always explicitly ask. Since this approach can itself be misunderstood as a lack of trust, I recommend that you explain the reasoning behind it to your partner, and encourage them to do the same. At any rate, never miss an opportunity to turn an implicit expectation into an explicit one.
2. Attributing cultural differences to flaws in character or approach: this is one of the most dangerous effects, as it tends to poison the working relationship between the local and remote teams. To once again illustrate by example: some cultures tend to speak very direct. People in cultures where it is common to be more circumspect, tend to attribute this to the character of the person (often declaring the individual to be impolite or disrespectful), instead of a different but equally valid style of communication. Ironically, it goes both ways: people from cultures that tend to speak directly, often attribute the circumspect style of communication to evasiveness on behalf of the person, often declaring them to be disingenuous. The effect extends into all sorts of attributes that are dictated by cultural convention, including communication tone, punctuality, willingness to put forward one's own opinion, level of gesturing, and even how people dress. My advice here is two-fold. First of all, provide some cultural awareness training for your team. Second, it is incumbent upon you as a leader to (respectfully) point this effect out when you see it in your team, and to gently correct it. Your partner is most likely already doing both for her teams.

Note, by the way, that although we have so far spoken about culture in ethnic or regional terms, both of the effects highlighted above can also occur with workplace culture. For example, teams that are generally used to working on short-term, fixed-price projects, will generally assume that on-time delivery takes precedence over refining the requirements to get a better problem-solution fit. Conversely, people that have been continuously improving and maintaining the same product for 10 years will find any emphasis on milestones and deadlines (over better user experience) distressing. The same effects and the same advice from the points above applies to workplace culture differences as well.

Involvement

Last, but certainly not least, I'd like to highlight one of the most common mistakes I have seen in partnerships in the field: insufficient involvement on behalf of the client. The assumption that, to varying degrees, one can throw a project at a partner and disengage, only coming back together for status calls and steering committee meetings, is surprisingly common. And of all the failed projects that I experienced first hand, all but one had this factor in common. I believe that with the exception of one-time projects where the partner brings the expertise, the client has to be deeply involved in order for the project to succeed.

To begin with, for the first three categories we described above, prototype development, long-term development, and develop to transfer, the client is the party with the domain expertise. Also, the client has access to the user base, and therefore the user feedback. The client must remain deeply engaged with the teams in order to make sure they have available to them the best knowledge possible on what to build. My recommendation is that the Product Manager and the Product Owner (PO) belong to the client, and work with the teams on a daily basis (especially the PO). I often recommend that the remote team have their own deputy PO in order to reduce the effects of timezones and limited communication bandwidth, but if you plan to have only one PO, it should be the one on the client side, and that person should spend as much time as possible engaged with the remote teams.

Similarly, in the case of long-term development, and develop to transfer, the client is responsible for operating the software, and accountable to the end-users for it. It is imperative, therefore, that the client maintains control of architecture and design - the main architecture and design decisions should be taken by the client's architect, and architecture guidance and leadership should be provided by the client's architect. While not as intensive as the involvement of the PO, architecture and design tends to be heavily front-loaded, which means that at the beginning of the project, one or more architects from the client should be expecting to be working full-time with the remote teams. At later phases the required involvement tends to go down significantly, but it still remains substantial. As with the case of the POs, I recommend that the remote teams contain a local deputy architect to take advantage of the much more effective local communication. Nonetheless, the client's architect should expect to have frequent and regular involvement, including for activities such as design reviews, occasionally code reviews, consulting on technology and implementation choices, etc.

Finally, client-side Project Management and Project Sponsors should expect significant involvement as well. No software project goes as planned, and sooner or later trade-offs will have to be made that directly impact the objectives set by Project Management and the Project Sponsor(s). These decisions can only reasonably be made at that level, but QBRs (Quarterly Business Reviews) and Steering Committee meetings are not frequent enough to accommodate the required timing. Even more importantly, the experience to recognize when the objectives are at risk is generally only available at that level of stakeholders, and if they are not regularly involved, it is possible that risks might not be recognized until it is too late.

Overall, with the rare exception of projects that can be completely defined a-priori in a specification document, the client must invest significant amounts of time from multiple people in her organization in order for the partnership to be successful.