Can you offshore business analysis (part 1)?

This article starts with a definition of what offshoring means. It continues with an exploration of the arguments for and against.

The second part of this article will define the circumstances when offshoring is a good idea and when it is a bad idea.

This article was conceived as a result of a fascinating and impassioned debate on LinkedIn (Members follow this link to see the original debate).

What does offshoring mean?

The normal definition is tied in with outsourcing an activity to a third party in a different country which, typically, provides resources on a more cost effective basis and has greater capacity. There may be other criteria especially as the global sourcing model matures, becomes more sophisticated and less of a simple debate over cost saving.

In this article, it also considers where business analysis is conducted by a party in a different country and these other criteria may not apply. This is a real situation for projects that often span several different countries (or even continents!).

In particular, we are describing the situation when the business analyst and one or more of the stakeholders are located in different countries. I am also assuming that there is not an unlimited travel budget and people are not available to devote enough time to the project to allow for travelling to  a single destination. As a result, none of the stakeholder communication takes place face to face but utilises all the usual comunication mechanisms - telephone, email, IM chat, web presentations, shared workspaces (e.g. SharePoint) etc.

Why should you not offshore?

There are many obvious problems with offshoring, not least the quality of the analysis that arises and risks that arise (see Requirements Engineering for an explanation of costs incurred by poor analysis).

The main objection is that communication that is not face to face is inferior as much communication is non verbal.

Professor Albert Mehrabian’s communication model for verbal interaction states that for describing feelings and attitudes to something (taken, with apologies, from original LinkedIn discussion from Paul Anderson’s comment):

• 7% of meaning is in the words that are spoken.




• 38% of meaning is paralinguistic (the way that the words are said).




• 55% of meaning is in facial expression.

The immediate (possible) cost saving can be outweighed by costs that will emerge arising from poor analysis which will significantly outweigh the original cost savings.

There are also other more practical problems which include the fact that the business analyst and the stakeholders work in different time zones and cultural differences can result in misunderstanding with different expectations.

The ‘ideal’ business analysis engagement has the following characteristics and these are less likely to be satisfied in an offshoring scenario:

• common language




• familiar with business and stakeholders (has established relationship/trust and/or shared understanding of business)




• familar with business sector (if the above is not true)




• ability to act effectively on behalf of project stakeholders (i.e. sponsor)
  Business analysts are required to manage stakeholders expectations and control scope. This negotiation is best done face to face (Thanks to Marc Thibault for your comment on LinkedIn).




• same working hours
  Working in different time zones introduces extra difficulties in a challenging job




• familiar with country/regional culture where relevant. This includes accent and cultural norms.
  Less important, depending on the project, will be familiarity as an end user. For example, where the project delivers a product to the market which is familiar to the business analyst, this will not prove an obstacle to the analysis.

I would suggest these are listed in order of importance. Clearly it is critical that the the business analyst and stakeholders share a language. In certain circumstances, it is helpful that the business analyst understands the local market as a consumer and it is often, indeed, assumed this is the case.

Why should you offshore?

There are several reasons why you should offshore, both in the traditional sense, and, in this article, where the BA and stakeholders are geographically distributed:

• Cost saving (thought I should get that one out the way first!)
  Costs can be saved by simply reducing the cost of each business analysis resource. Travel costs can also be avoided where stakeholders are geographically dispersed.




• Insufficient local resources




• Resourcing flexibility
  This refers to the ability to maintain a core level of BA capability and respond to increases in demand without increasing your cost base. This also increases the capacity of the organisation.
  Note: this is one of the main benefits to offshoring design, build and test. Does this match your experience or is this a fallacy?




• Specialist/experience skills
  This is really a variation of insufficient local skills. It may be that the experience needed for success are in short supply in the local market. This would be true where, for example, it relates to new regulations.




• Geographically dispersed stakeholders
  In these circumstances, you can either take on a large travel budget and a greater commitment of time from the stakeholders (due to travel time) or manage the project with an ‘offshore’ business analyst.




• Greater objectivity and professionalism
  Before you get too upset, I am playing devil’s advocate! You could argue that literal distance between the BA and the stakeholders creates professional distance and objectivity. Obviously, there is the opposite argument where having a relationship is actually a huge benefit. Just adding a little controversy to generate debate!

As you can see there are reasons for offshoring other than simply cost saving. Over time, the cost saving benefits will be reduced so this should never be the sole reason. The reasons that justify further investigation and have the most compelling ‘business case’ are resourcing flexibility and specialist experience.

Thanks for reading this article. It has explained what is meant by offshoring for the purposes of the article and the case for and against business analysis.

The second part will explore this in more detail and explain when offshoring could be used and when it should not be used.

This article is only my opinion and ‘analysis’ of the situation - I would really value your opinions, especially any that are borne out of experience.