Mar 23

SAP Upgrades & Offshore Resources

It looks like it is official: 2010 is the year of the upgrade.  A little validation is good for my self-esteem. Now that’s out of the way and I’m polishing my attaboy trophy let’s get on with it.

In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources.  My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post.  Now that you’ve found these customizations, what do you do next?  Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.

What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming.  This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.

I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through.  This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly.  Let me digress.

SAP Offshore Development Resources

I’ve heard many complaints regarding offshore resources, but the two biggest complaints that are trotted out as a serious offset to the expected cost savings are:

  • The time difference makes turnaround time longer than projects plan for or like.  For example, if you work with resources in India you have to synchronize working schedules and often this means team members either work way late or very early in the day.
  • The accuracy and completeness of what you ask for determines the quality of what you get back (a.k.a. you get what you ask for, not necessarily what you want): the difference in time zones makes it difficult to get clarifications and address questions quickly.  Consequently, development life cycles can be extended even if the hourly cost is lower.

A straightforward way to address the first issue is to work with an offshore partner in a time zone closer to yours.  In this respect I’ve worked with development partners in South America where the offset with US time zones is small.  This helps address the second complaint: by being in similar time zones it is much easier to either pick up the phone and address questions or send e-mail and get a quick response to a question.  I’ve been on projects where a quick answer to a question had to wait a day because of time zone and work schedule difficulties.  There may be a slight premium for using an offshore team in South America, but the turnaround time and responsiveness usually makes it worthwhile.

How does this digression help your upgrade?

Once you’ve sorted your bag of development rocks you can go through another level of review to rank the objects in terms of complexity and/or difficulty of remediation for the upgrade.  In general, I’d recommend keeping the most difficult work items close at hand and have onshore resources work them.  Any questions about what the object is supposed to do, any business process impacts can be addressed readily with end users and business analysts.  Objects that are less complex can be worked by the offshore team: you stand a good chance of getting what you need by providing clear documentation (all those project artifacts you maintain) and explicit instructions around what you think the remediation entails.  You should also set expectations around what comes back from your offshore partner: code that is free from syntax errors isn’t going to be enough, some level of testing and documented results are more likely what you want.

SAP Upgrade Onshore and Offshore Resource Balancing

I can’t tell you or even estimate how many onshore and offshore resources to engage in an upgrade project without knowing more about your environment and object analysis.  However, I would definitely recommend two key onshore roles:

  • Development Object Remediation Lead: an individual who has responsibility for coordinating and prioritizing the objects sent to the offshore team and managing the associated sign out and sign in process.  This person also has the unenviable task of serving as the quality control checkpoint and enforcer of expectations with the offshore team.  There should be a corresponding role in the offshore team, too.
  • Development Object Remediation Senior Consultant: one or more individuals with the expertise to address the complex objects

Smart use of offshore resources has the potential to reduce development object remediation cycle times and that should lead to direct cost savings.  Any steps that accelerate your overall upgrade project time line and contain costs should be viewed as a good thing.  Try it – you just might like it!


About The Author


  1. […] Off-Shore Technical Resources […]

  2. […] this entry I’ll pull together a few threads from previous posts (testing, documentation, upgrades and offshore development) and throw in some Solution Manager (SOLMAN) functionality.  These pieces can be fitted together […]

Leave a reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

This site uses Akismet to reduce spam. Learn how your comment data is processed.