DER Management

October 20, 2006

Offshoring Lessons Learned

Filed under: Consulting, Lessons Learned, Offshoring — daver @ 5:06 pm

Several project management lessons learned have been recorded over our past three years of exposure to the use of Offshore development teams for US-based projects.  I offer some insight into common traps, easy tricks, and where reality meets expectations.

In the interest of a dialogue-style discussion, let’s first visit some common expectations about Offshoring first and then see if they meet with reality.

Offshoring Goal #1: Save Money on pure hourly labor cost

Typically the “list price” for onshore development resources versus offshore development resources is going to be provided in a ratio of no less than 3:1, perhaps even getting to 4:1 or greater the leverage of possible cost savings.  This leverage on the project dollar normally creates a great deal of exictement with buyers of such services.

Offshoring Goal #2: Same quality of resources

Several offshoring firms will represent their resources as fully trained, and perhaps even certified, in the use of specific tools, techniques, or other technical solutions that are relevant to the project.  The perception of getting the same quality at a lower price (see #1) creates quite a bit of enthusiasm.

Offshoring Goal #3: We can leverage our onshore team for higher-value work

A sensible objective of taking work out of the hands of your employee or contractor onshore staff would be have them focus upon yet higher-value work.  This paradigm is common amongst all business practices - pay less for lower risk/value/complexity work and pay more the higher risk/value/complexity work.  One would expect that the onshore staff would be able to do more without the development cycle encumbrances of more menial development tasks that get sent offshore.

And now for something completely different…”

– John Cleese, Monty Python’s Flying Circus.

There are certain realities around working a development project.  These tend to be true irrespective of whether you offshore or stay onshore, or if you blend your team.

  • Choice of overall approach, Waterfall or RAD, will significantly influence the project’s team dynamics
  • Degree of “from scratch” work will influence the amount of time spent on requirements gathering and prototyping to reach the necessary level of knowledge transfer
  • Degree of past familiarity with the business logic and objectives of the project will influence how quickly the technical resources “get it”.

These may seem terribly obvious statements, but let’s consider how they impact the project when offshoring is introduced, particularly where the team has onshore and offshore technical team members.

Lesson Learned #1: Savings are not always there!

The low hourly cost of offshore workers is often countermanded by several possible sources of “savings leakage”:

  • Additional project management oversight and management layers
  • Additional procurement and contracts time
  • Additional requirements elicitation to establish understanding
  • Additional integration effort between onshore and offshore project activity
  • Additional software licenses, computing resources, and security concerns
  • Additional project delivery time due to time zones for working time 
  • Sometimes it just takes the offshore team more time to do the same work!

The net reality is that the offshoring cost savings targets of 3:1 or 4:1 don’t materialze to be much more than 1.5:1 due to the additional costs to support the offshoring engagement and the other factors that create more expense.  Do NOT underestimate the effort spent to ensure that requirements are fully developed and clearly restated by the offshore team.  Even prototyping only goes so far in assuring that business rules are being implemented to expectations.

Lesson Learned #2: Perception of quality

The perception of the quality of the resources can easily be managed by the offshoring partner.  The offshore team are often drawing from a large pool of skilled resources.  While the opportunity may be given to review resume’s, certifications, and years of experience of the offshore team, it’s important to note that the actual team performing the work will not necessary have full visibility to the onshore team.  Thus, the real perception of quality comes from the offshore provider’s account management and team leader roles.

The account management team and team leaders are typically the “faces” of the offshore team - even if you never see them.  They are normally more proficient in the business acumen that are desired by the onshore team and the Customer.  These roles can be leveraged by the onshore and Customer team to ensure that quality stays high.

The offshore account management team needs to be involved in regular status, satisfaction, and progress checks with the onshore project team.  This would not be to dig into development details, but to ensure that issues that require finesse or translation (or that cross cultural bounds) are addressed using the appropriate internal business feedback channels at the offshore partner’s local organization.

The team lead(s) are the real faces of the offshore team to the onshore team.  They typically provide the demystification of the “black box” of development work taking place offshore.  A great deal of time and effort should be invested with ensuring that this role “gets it” and that they feel comfortable using an open feedback channel with the onshore team.  A strong recommendation for projects with a meanginful degree of risk or value would be for the offshore team lead to be onsite for a period of time early in the project - often during requirements elicitation, for example - in order to build relationships, understanding, and comfort for all parties.  A poor team lead - or poor understanding by the team lead - will assuredly result in poor results.

Lesson Learned #3: The onshore team still has integration work to do.

Not surprising by now, hopefully, is that the onshore team - who probably have as much talent and possibly more local knowledge - are working to integrate responsibilities and work product with the offshore team.  Assuming that the onshore team are Subject Matter Experts, one would tend to invest more responsibility for overall delivery with the onshore SME’s.  They must, therefore, provide some integration time to bring together the offshore work product, smooth the documentation and perform early stage system and integration testing before the product ever sees the light of day for User Acceptance Testing.

 

Other lessons were learned in the course of performing development work with offshore partners.  In short form, here are some possible “gotchas”:

  • Be aware of cultural differences and use care to educate all sides of the project when holidays, religious obligations, or other cultural differences may arise.  They are not to be feared, but must be approached in a professional context.
  • Every assumption that is NOT stated will all but assuredly go against the project.  This is Murphy’s Law etched in stone.  Stated assumptions are fine, but they need to be actively tracked and pursued to closure.
  • Differences in work product quality are often perceptible as different developers embrace different aspects of the system.  While this is not inherently an offshore problem, one must anticipate that expansion of the team’s geography and composition will exacerbate the issue.
  • Time zone differences will often limit available working time for the project teams to work simultanously.  This is advantangeous if you can work a “follow-the-sun” model to progress the efforts of the day.  This is a disadvantage if extended length conversations about topics need to be held.  Someone has to suffer either working early or working late.  Create agreements early on working times and safe working day lengths to prevent illness or injury due to fatigue.
  • When working projects with a Waterfall model, I strongly recommend that a time and budget buffer of around 10% of the overall development expense be held as a buffer for final enhancements, tweaks, and “resumptions of understanding” from what you thought you’d receive and what is actually implemented.  This is as much an issue of the Customer not stating everything as it is a product of incorrect understandings.
  • Don’t be surprised if a foreign land has a little civil strife every now and then that impacts your offshore team’s ability to work.

 

3 Comments »

  1. Great lessons learned for offshoring! In my experience managers tend to forget the additional overhead involved on projects with geographically-disbursed teams. Achieving cost savings in these situations is entirely possible, but only when communication barriers are broken down. Thanks for the article!

    Comment by David M. Anderson — January 11, 2007 @ 7:36 pm

  2. Nice hints. I was searching for some lessons learned to complete my risk assessment document, and found here some interesting points.

    In my case, it is a bit harder because a lot of documentation must be consolidated, then translated to English.

    Thanks.
    VC

    Comment by Vincenzo Carabillo — August 4, 2008 @ 1:45 am

  3. Its a great article Daver. All the facts have been approriately dealt with and presented. I Would just like to add that Offshoring experience in terms of ‘cost’ can be significantly enhanced by moving towards agile methods and open source technologies. It would not only provide ‘required’ quality but also improve cost effectiveness and time to market.

    Comment by Ujjwal Trivedi — August 4, 2008 @ 3:29 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress