Project based rightshoring

For over twenty years offshoring has been a major part of many UK companies delivery strategy. As you would expect, the industry has matured in that time and has fragmented in to a number of specialised forms

  • Offshoring
  • Nearshoring
  • Rightshoring.
  • In my time at O2 we evolved a fairly sophisticated model for partner offshoring and, while it may not be appropriate for everyone, I feel it would be useful to describe how it worked for us.

    First, though, lets define the three key approaches.

    Offshoring

    Wikipedia defines offshoring as

    the relocation by a company of a business process from one country to another—typically an operational process, such as manufacturing, or supporting processes, such as accounting. … More recently, offshoring has been associated primarily with the sourcing of technical and administrative services supporting domestic and global operations from outside the home country, by means of internal (captive) or external (outsourcing) delivery models.

    For our purposes we are interested in a subset of that concerned with IT development and maintenance. I would also say that offshoring for our purposes involves moving business processes to a country in another continent – typically India, but increasingly China, Philippines, Malaysia and latterly countries in Africa.

    Nearshoring

    Back to Wikipedia and we have nearshoring as

    the transfer of business or IT processes to companies in a nearby country, often sharing a border with your own country.

    Again, lets be a little more specific than nearby, and restrict it to a country in the same continent. Nearshoring for the UK therefore typically means moving business processes to the Eastern Bloc.

    Rightshoring

    Wordspy defines rightshoring as

    Restructuring a company’s workforce to find the optimum mix of jobs performed locally and jobs moved to foreign countries.

    In other words rightshoring means moving some, but not all, business processes offshore (or nearshore) depending on the business process.

    So having defined our terms, what are the advantages and disadvantages of them?

    On the positive side we have

    Cost: Cutting cost and taxes is the main reason behind companies embracing offshoring.
    Time Zone Advantage: Offshoring gives companies the advantage of exploiting the time zone by receiving round the clock benefits.

    Of course it’s not all upside. Problems include

    Differences in work practices and culture. A huge difference always remains in the work practice and culture which are hard to overcome
    Communication Barriers: It is often difficult to communicate with companies in other countries that speak a different native language. Face to face meetings are very expensive to conduct and video conferencing may not always be convenient due to time difference.
    Finding good offshore partners: It can be hard to find a good IT provider based on the reviews on their websites and few teleconferences. It is not easy to make a good judgment without proven track record of working for other international companies and authentic references.

    You can see that rightshoring is an attempt to get an ideal mix of cost and flexibility at the organisational unit level. The problem is that in terms of delivery we want to make that tradeoff at the project level. We don’t want to decide where all projects will be developed and then be stuck with that decision – we want to make it on a per project basis and ideally be able to change it if our needs change halfway through.

    Essentially that is what we did at O2.

    Project based rightsourcing

    We had a team based in UK and another, larger, one based in India. At the initiation stage of a project we would produce a high level estimate based on Agile story points. We also asked the business owners to give us a simple view of the urgency based on H/M/L. All of the H priority projects were developed completely in UK using Scrum. The default for M projects was for an initial detailed impact assessment and design to be carried out in UK and the build to be carried out in India. All L projects were carried out in India completely using a waterfall approach (as it happened they also had a daily standup but it was really just to review progress against the plan).

    Of course to do this we had to put in place a number of processes to make it work. The key ones were:

  • A BA team in UK, a core development team in UK (small) and a core development team in India with a shadow team in India whose role was to work with developers in India and become familiar with the UK projects and infrastructure. The shadow team was typically in training
  • Where possible we shared work between the two core teams, every UK team had at least one India team member attending the standups and working as a productive part of the team
  • Bi-weekly planning meetings looking 6 weeks ahead. All H priority projects were done in UK, but the rest depended on available resource. We tried to balance resource between UK and India while meeting our SLAs for planned work
  • If that could not be done we would move one or more teams from the core group between UK and India as required, then replace them with members of the shadow team
  • An administration group tasked with organising visas and accommodation.
  • The nett result was that we were able to develop systems either on or offshore based on the trade-off between cost and delivery time. The amount of each varied – that was the point, after all – but we found it worked within the below parameters.

    team size

    There were some caveats – you need a certain amount of work in the UK as mentioned – but in general it worked for us.