(Originally written for and published on Headspring’s blog)

world map

The onshore versus offshore resource debate compares apples and oranges. Most IT decision makers already understand the tradeoffs of working with a team several time zones away for the sake of speed and thrift.

Those same IT enterprise decisions are often less clear, however, when seeking to build an integrated team either through their offshore partners or within their own departments. In this scenario, they’re comparing a small, stealthy and locally embedded team with finite resources against an outsourced army managed locally. Choosing between these two options, on paper, may seem like a tough decision – but depending on the project, it is not.

Enterprise Application Development: When Offshoring Doesn’t Work

It is misguided to think that a group six to 12 time zones away can be managed locally, as an extension of the company, to support enterprise application development.

There may be examples of enterprise business transformative projects being done with this sort of hybrid team, but I’ve never seen it work well in real life – and I should know. The best result I’ve seen is one where all the parties involved are more or less placated, and where those performing the work lack cohesion, scalability and ownership.

For nearly two years, my role (before joining Headspring) was to manage offshore teams on behalf of American business interests. It was my job to be available during both sets of office hours, speak multiple languages (both literally and figuratively – i.e., technical and non-technical) and ensure both teams perform cohesively. These three skills were the most important aspects of the job description – and, ironically, they were also the reason the job was impossible to do. Here’s why:

  • The client-facing people in an offshore team work 12-to-16 hour days. That’s a full day with the embedded team, plus the extra hours required for daily offshore meetings, and dedicated time for code fixes attributed to “lost in translation” or too many engineers tackling a single challenge too quickly: lack of cohesion and scalability.
  • Turnover is very high because people are “resources.” A starting engineer in India makes between $3,000 and $6,000 a year. Even at a bill rate of $50/hour, it takes no more than 3 weeks to recoup the resource calculation of one individual. This business model means: (a) offshore firms have no incentive to grow and retain their people so finding quality team members is extremely challenging; (b) working with the same team for the duration of a project is unlikely; and (c) there’s always a scapegoat – “X was the problem, but we’ve solved that by hiring Y” – and so there’s no ownership or accountability.
  • The onshore Project Manager is accountable to clients, but cannot directly oversee the people responsible for delivery. Managing up in this scenario is about managing expectations while the goal of managing the offshore team is to crystalize expectations in order to bring up quality. In this situation, there is no meeting in the middle, and the project is built in silos where usually one, relatively exhausted, person is doing a dance. Nobody is actually happy with the outcome in this situation; rather, the best-case scenario is that everyone is placated.

The Project Distinction: When Offshoring is Ideal

This isn’t to say that there never times when offshoring makes sense. I’ve seen it be the perfect solution when:

  • The project is low-risk and isn’t time-sensitive
  • You really do need an army to get a lot of work done on a budget
  • The skill set required is commoditized and therefore doesn’t need intense supervision
  • You don’t have an onshore team at all and the business process is simple enough that it is easily communicated and tested

Furthermore, it may be worth saving money and shifting more work to an offshore team if your onshore development resources require your skilled navigation of these challenges:

  • Variable quality – When the project team changes, even just a little, project productivity shifts dramatically
  • Technical debt – Knowing at what point bad code quality and architectural problems need to be fixed at the risk of stopping the progress of the project
  • Trading off management time – Every 20 hours of outsourcing requires an hour of executive management (allocating rework) or high-quality re-working

Business Transformation: Just Say No

Conversely, when it comes to business transformative IT projects, offshoring is never the right answer. The impacts of variable quality, technical debt and management time increase as project complexity does. In other words, tackling “digital business” challenges including re-architecting for the Cloud, analytics and other such issues see the utility of offshoring wane drastically.

Ideally, these projects are managed exclusively by executive leadership and architects and handled by specialists. However, many organizations lack the capacity, resources or skill sets to take on these challenges. In this instance, they should look to business transformation catalysts – firms that specialize in these sort of high strategy, high impact projects.

Another way to evaluate onshore business transformation specialist versus and offshore partner is to consider these two criteria:

  • How important are the results? If the problem you have is solved with staff augmentation, the problem to be solved has little to do with the ROI or business impact of the project. If you are “throwing people” at a project, you are likely fixing something, not revolutionizing a process or the digital business.

  • Do you require accountability for the time and budget going into the project? Most offshore business models are conceptualized as an Operational Expense with ad infinitum contracts. While some onshore organizations offer OpEx contracts, the qualifier are the line items in those contracts. For projects that have intense scrutiny or multiple stakeholders, having a contractual end date and a fixed-bid is important because it forces the vendor to make investments on their end to ensure they reach the goal line successfully.

Firms like Headspring can ensure that highly skilled, communal consultants can help organizations meet their objectives, while allowing them to keep their own staff focused on other business-critical activities that drive immediate goals and revenue. In addition, the advantages of onshoring go beyond a reduction of the pains listed above. A localized braintrust of skilled full-stack developers and well-versed project managers also brings with them an environment that cultivates innovation. In this scenario we see the opposite of placation: delight.

What’s your perspective? Have you had a great offshoring experience? A terrible one? What’s your recommendation for when to use what kind of resource?