Offshoring – the business consultant's best friend. It's often used as "the grass is greener" answer to many large software development team's senior management. After seeing this sold in some way at nearly every role I've had for the last 10 years, the one question I don't often see asked alongside is what problem this solves and if there's other answers. Like many legitimate leadership questions this is overlooked not because managers are unintelligent, but because it's often a hard question to answer. Digging deeper delivers answers that can save a lot of time, stress and money.

I preface this post by stating that I am not a detractor to offshoring software development – I've seen it work and be an amazing value add to a business when done right. What I've also seen is the use of it as a silver bullet to greater problems within an organisation that outsourcing nearly always exacerbates rather than solves.

Solve the easy problems first

Nearly every reason put forward to offshore your development team gains more value from first reviewing and addressing other areas within your business that need real attention before considering offshoring.

When you opt to send some of your development team offshore, you should be at the point that there's not much left to do. You get there after all the easy stuff has been done first and you're still looking for answers.

Here's something the tech news doesn't shed much light on when talking about offshoring: sending part of a business (especially something as conceptual and need driven as software development) to a country with a better exchange rate isn't an easy journey, so set off in the knowledge that your list of easier wins is slim.

Nearly every business problem you face in software has a hierarchy of approaches you can take to solving it and they scale upwards in effort, complexity and cost to do.

Take the following statement:

"We need to outsource our dev team so we can lower delivery cost"

Then think about all of the tools you could use to solve this problem.

• Lower cost local outsourcing – maybe simpler parts of your application could be done by smaller local partners often eager for work.
• A review of your delivery process – maybe you waste a lot of time through scope miscommunications or mismanagement.
• Restructuring – are the right people in the right roles. Do you have experienced or expensive resources doing simple tasks that can be done by more cost effective ones?
• …*insert some other less sexy, but oh-so common development team streamlining approach*

There are many things you can do to address the way a team delivers software applications cost effectively but I hear and see so many often overlook them in the rush to "outsource like IBM/Apple/*some big company* did; I heard they saved millions". What you don't hear about this are all of the other things they did before setting up shop overseas.

The graphic below illustrates what I'm trying to get across – don't place too much importance on the "solutions" in the pyramid, that's not the point.

Journey of discovery

When thinking about offshoring the real question you should be asking is whether your team is really at the point where offshoring solves any deficiencies in their output now.

Because the frustrating thing that can occur by teams that decide to offshore without enough forethought is simple, but usually only applies in hindsight

When you move your dev team offshore your delivery model changes:

• Your developers are remote, so you need better ways/processes/tools to communicate.
• You often have less visibility over them, so you implement better time management processes and team member accountability. Maybe you introduce a different project methodology like scrum or Kanban, or maybe you just tighten up the way you're putting it into practice.
• Your new offshore employees or supplier needs a longer runway, so you put structure in place to ensure your project planning and project governance is more thought out ahead of time and maybe to a higher resolution.
• To ensure your remote developers fully understand the brief for any work you send their way, you implement better streamlined requirements gathering and better wire framing or mock-ups to communicate your deliverables to remote employees before development begins.
• As offshore resources often need more cultural leadership on how your business or brand delivers in a way that differentiates you, you document company and development process better leading to less mistakes and a better understanding of how you do business.

And at this point you look at the list above, and realise that if you'd just done even a few of the items listed (badly) before you offshored your development team you probably would have delivered an acceptable solution to one of your team's original problems without any of the stress or wasted time.

Long story short save yourself the effort of swinging that big hammer unless you need to – look to streamline your current process long before pulling the offshoring trigger.

Your organisation and team will be better for it.