Can you offshore business analysis (part 1)?

world-map2This 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.

About Alex Papworth

11 Responses to “Can you offshore business analysis (part 1)?”

Read below or add a comment...

  1. ?ukasz Pasek says:

    There are some important advantages for Offshore Business Analyst. Alex is devil’s advocate which makes me a devil 🙂
    I am Business Analyst from Poland where salary is 3-4 times less than in US or UK. It is already an advantage as my motivation to do my work fine for US or UK company is very high. I guess that one can hire much better BA for the same money when that person will be offshore.
    There are quite efficient models for communicating requirements between stakeholders: Task descriptions, Warnier-Orr diagrams, data dictionaries, communication related questions and interviews.
    Working hours is not an issue. I can work 1PM-9PM. There always is a work to do that require spending time alone with my computer – modeling functionality, writing requirements, solving problems, researching literature and reports. When there are short deadlines I can work in my mornings also.
    The biggest problem with communication is rather prejudices of people like you.

  2. Colin Quinn says:

    As the author of the original thread on Modernanalyst,com. Here is my view.

    Protectionism doesn’t work. Not to offshore requirements because of politics is a non starter. It’s anti competitive and it lacks imagination. Regulation is protectionism by another name. The work should be done where it is right for the project not out of political allegiance.

    That destination may be the UK. There may be defence projects etc that it makes sense to keep onshore.Then again it may be offshore or it be be remote. To take any other view other than a project/programme/benefits based one is to take a “Canute” like approach to Globalisation.

    In terms of where analysis capabilities aren’t in good shape. Isn’t that exactly why you would get someone else to do the work? Someone with a track record of delivery. Someone that has worked multi site/multi cultural projects?Perhaps i have misunderstood the point being made.

    Analysts(and business in general) face a number of challenges. The idea of “soft skills” was written in a different age for a different time.If anyone needs a reminder of that, think e-mail and the amount of project work that is done via that mechanism.

    At the moment that debate is “can it be done?” I believe in a few years the debate will be “how do we do it?”. Competition will make sure of that.

    Looking forward to the rest of the article.

    • Alex P says:

      Thanks Colin, Maurice and Doug.

      Although I did author this article, this is very much an open debate and I’m just responding to keep the debate continuing rather than providing some ‘definitive’ view.

      In answer to Craig, I agree the location of the developers is an important aspect of this – they are stakeholders equally as valid as the business. Question is, where are they based? Of course, they could well be based offshore so what does that do to the dynamics and the ‘location’ question. I’ll try to cover this in Part 2.

      Maurice, you’ve opened a whole different can of worms. There is a separate debate about protecting local workers and one that will run and run, even for developers and testers where the offshore model is already well established. My view – globalisation is an undeniable fact and I would agree with the ‘Canute’ comment. There is a separate argument regarding bringing offshore contractors into the UK which is less clear and I do not intend to explore that in detail in the subsequent article as I am only looking at ‘pure’ offshoring.

      I would tend to agree with Colin but I think the industry needs to go through a whole lot of ‘maturing’ before it really starts making sense.

  3. Maurice Burnett says:

    A very interesting article and similarly interesting feedback, indeed!
    However, from my viewpoint I think that one perspective that has not been considered is that of the potential effects of off-shoring on the UK’s indigenous skills resources, specifically the:
    (1) immediate effect on the employment prospects of the UK’s own available skilled business analysts. In short, companies that off-shore their analysis work are excluding the UK’s own home-grown resources and putting them out of work.
    (2) potential longer term impact of using off-shore business analysis skills. In particular, passing analysis work out of the UK, makes our own skilled resources have to face redundancy. Under such circumstances, there is a very real risk , surely, that the UK IT developments will become totally dependent upon off-shore monopolies, with all the potential implications. Not a good thing!
    Apart from the increasing practice over the last 2 decades for many UK organisations to off-shore, there has also been the worrying trend that sees the off-shore organisations sending whole project teams of their own workers to work on-site in the UK. This might help to enhance communication between business analysts (imported from off-shore) due to possibility for face-to-face communication, (referring to Professor Albert Mehrabian’s communication model), but it undermines maintaining of the level of employment of the UK’s own work force.
    The question is – ‘to off-shore, or not to off-shore’. Regardless of the G20 summit and its stance against protectionism, in the context of information systems development it seems to be a ‘no brainer’ that if organisations are allowed to export work, that is effectively taking it away from UK’s own information systems resources, and ultimately increasing reliance on off-shore organisation for the long-term.
    So, perhaps the question should be, whether to strictly monitor and control off-shoring across all organisations, in order to make sure that if necessary skills are available at home, off-shoring is not permitted is needs to be justified. Regulation, not protectionism.

  4. Craig Brown says:

    Another dimension to consider…

    Do you want to give your developers good consistent access to the analysts? If so, send the analysts to where the developers are, and bring them back to head office for the discovery sessions.

  5. Alex P says:

    Thanks Scott.
    It’s interesting that you had onsite sessions as well. If this option was available, why wasn’t that the first session with follow ups run remotely? I think face to face for the first meeting is really beneficial for establishing new relationships.


  6. I’ve had to facilitate requirements elicitation remotely – 11PM my time, 9AM their time (Asia). It was pretty difficult, between the lack of visual cues and language barrier challenges. For the same project, we also had elicitation sessions with teams in Latin America (also with language and cultural differences) – where I engaged over the phone, and another team member was on-site and in the room facilitating the session.

    We spent about the same amount of clock time with the two groups. We had more follow-up action items with the on-site facilitated session (presumably, improving the quality of the requirements through follow-on analysis that we discovered needed to be done). And the purely-remote facilitation sessions took 3 weeks on the calendar, versus one week.

    So for us, the perceived trade-off was the cost of travel versus the cost of delay. And the latent trade-off was in (possibly) reduced quality of requirements in the remote-only sessions.

  7. The one resource you can’t get more of is time. Face-to-Face facilitated requirements discovery sessions get results fast. If time is money, then costs of getting people in the same room will be offset many times by speed-to-market and more.

    • Alex P says:

      David, I’d agree with this. This implies that you can’t have a facilitated meeting run remotely. The thought of it makes me break out in a cold sweat – hey, I’m just trying to play devil’s advocate!

  8. DougGtheBA says:

    Since I replied to the original posts, I’ve thought some more about this, and don’t worry…I haven’t changed my mind.

    One of the things that always comes up when I speak to people about offshoring development activities is whether or not their respective IT areas have their analysis and process areas in good shape before that happens. The idea is that if one offshores poor requirements and/or processes, the end result will be more likely to be faulty.

    So I started thinking about this aspect when moving the offshoring part up earlier in the SDLC. Afterall, one cant always assume that a firm has great analysis capabilities when considering offshoring them. In the best-case scenario, I’d say you’ve covered what the potential issues are or could be. Several people have posted that it IS possible to offshore, but there doesn’t seem to be a consensus on how effective it is. But what about situations in which the analysis capabilities AREN’T in good shape? Of those capabilities, what happens when one places additional obstacles into the massive amounts of communications that occurs in the typical requirements phase in a standard SDLC?

    Any analyst can tell you that he or she is often in a position that requries proactive communication amongst many different team members in order to do the job. There are also situations that call for reigning in chaos through communication. Remember that elicitation and management of requirements is not just about sitting in front of the customer. It’s about facilitating communication between members that operate in all phases of the development lifecycle. If analysis gets offshored, it’s not only harder to interact with the customer, but it becomes harder to interact with everyone. Think about all the back and forth communication that occurs with test-driven development and how that will be affected. It’s not that these people CAN’T communicate anymore, it’s that the quality and cahracteristics of the communnication is impacted.

    In the end, I go back to my comments in the original posts. The analyst soft skills are compromised, and that can lead to a systemic breakdown in communication not just with the customers during elicitation, but throughout the life cycle.

    If someone can show me that there is a way to overcome these obstacles, I’m all ears. Until then, I remain skeptical.


    • Alex P says:


      There are definitely many problems. The organisation needs to have a certain level of maturity for offshoring to have a chance. The project itself must be fairly ‘routine’ otherwise the risks are too great. I’ll explore the profile of a project that could work in the nex article.

      Like most things in life, it’s not a simple Yes or No to offshoring. It’s more Yes if the circumstances are right and the reasons for offshoring and preparation are correct.


Leave A Comment...