At CayugaSoft we’ve decided to focus on Dedicated Offshore Development Teams, combined with Agile development methods.  It’s really the best approach for successful software development over the long haul.  The offshore team augments the onshore team, allowing the company to expand resources cost-effectively while building up the business, technology, and development process knowledge of the offshore team.  So as opposed to a project-by-project approach to offshore development, where the team scatters to the winds once a project is complete, with a dedicated team approach you are looking to build up your team’s knowledge and leverage this knowledge over time.  The result is a cost-effective expansion in resources, with much better productivity than you’d get with project-oriented offshore development.

Anyone who’s actually managed a successful software operation knows how difficult yet important it is to build a functioning process and a great team, and what a great competitive advantage it is once you’ve achieved those things. Yet for some reason, traditionally, offshore development was seen as a kind of “overflow” capacity, rather than a long-term asset for the onshore company.  This, despite that fact that it goes against all that we know about successful software development management—that having a great, committed team is the most important thing you can have.

You may know some people who’ve tried offshore development and had problems.  As I talk to people in the IT and software worlds, I hear stories like this: “My brother-in-law’s company outsourced development and it sucked.  They had to throw away all the code.”  So that apparently proves what, exactly?  That offshore development doesn’t work?  Look, just because you can find someone that couldn’t get offshore development to work, that doesn’t mean it can’t work.  That’s a bit like saying: “I’m overweight and slow, and can’t walk up a flight of stairs, so therefore nobody can run a marathon.”  Plenty of companies are having tremendous success developing software offshore.  So I don’t accept it when people tell me it’s impossible.  I’ve done it and it works. 

It’s hard enough to get a successful software development team up and running in the US.  So yeah, it’s even harder to do it offshore.  Luckily there are some best practices we can observe and learn from.  And some common pitfalls we need to avoid.  First, let’s talk about common pitfalls when attempting offshore software development:

  1. Inability to gain acceptance from the onshore team: Frequently, the existing onshore development team will resist the idea of offshore development.  It’s natural since it’s new to them.  They may feel that their jobs are threatened.  They may have legitimate concerns, such as “how are these offshore developers going to understand what to do, sitting so far away from the business”.  They may resist openly, or in a passive-aggressive fashion.  Either way, if you don’t figure out how to get them on board, it will be very difficult for the offshore team to succeed, unless they are working on something completely independently from the onshore team.
  2. Inability to set up a working onshore/offshore development process – Without a functioning onshore/offshore development process, you’re going to have two teams working at cross-purposes, and have difficulty pulling it all into coherent software products.  You might find that the onshore and offshore teams will end up with competing technical approaches to accomplishing the same thing.  And they’ll waste a lot of time arguing about why their technical approaches are better.  In fact, the reservations that the onshore team may have about offshore development (see point 1, above) are actually best addressed in a process context.  In other words, you say to the onshore staff, “Yes, I understand you are concerned about how the offshore developers will understand the business requirements, sitting thousands of miles away from here, so that’s why it’s vital we get this onshore/offshore Agile process working really well.  If we can get all of our requirements defined as bite-sized user stories, then don’t you think our offshore staff could accomplish at least some of these requirements?” 
  3. Managing by “remote control”: When I meet people who’ve had problems getting offshore development to work well, often they were treating it as if you could bid the whole thing out to the offshore provider, and somehow everything would work by magic.  They wouldn’t travel to visit the offshore provider.  And they wouldn’t take an active interest in the staff the provider was hiring, and their skills sets.  Is that how you’d manage your onshore operations?  I understand that you’re outsourcing for a reason, and you expect your service provider to provide good service and manage this stuff for you,  but if you act like it’s all just going to happen, with little involvement from you, then you are going to be sorely disappointed.
  4. Requirements requirements requirements – If you ask an offshore service provider why a project went bad, or why they lost a customer, they’ll usually say that their customer didn’t know what they wanted, and wouldn’t take the time to define it properly.  But as we’ve discussed in prior blog posts, requirements are always “wrong” to some degree.    So again, this comes down to your development process and your approach to team communications and decision making, and whether these provide approaches to resolving requirements issues promptly, and getting everyone’s agreement, in a world where the requirements are never known with certainty.

So now, having talked about the common pitfalls of offshore development, next we’ll wrap up this series of blog posts by talking about some best-practices for managing offshore software development.  Hopefully, those best-practices will help you avoid the above pitfalls.


Mike Sadowski,
CEO, CayugaSoft Technologies LLC