Outsourcing has been gaining momentum for years, primarily because of the cost-reduction benefits. Industry analysts indicate the focus on lowering IT costs is accelerating the use of offshore services, and forecasts include such predictions as offshore outsourcing will grow more than 20 percent annually to become a $10 billion market by 2005.
While some companies are contemplating outsourcing entire departments, others are choosing to outsource individual projects. Companies not currently engaged in outsourcing should at least evaluate it as a strategy.
Aside from cost considerations, here are 10 factors to help you determine whether offshore outsourcing will work for your organization.
1. What types of functions or projects make good candidates for offshore outsourcing?
Data conversions and system migrations are typical projects taken offshore. Usually, requirements and specifications are well defined, and end-user interaction with the development team is minimal. Naturally, the company must be willing to allow its application code to be located offsite during development. Data conversion often involves file and field changes, coding changes to support the revised data formats, and regression testing of existing functionality. It may be accompanied by enhancements to the system or by the installation of a new software package. System migrations are similar in that the primary goal is to maintain current functionality while the underlying software, database, or technology platform is upgraded as quickly as possible. Examples of this include upgrading legacy applications and converting from one platform to another.
Application development projects also are good offshore candidates. From a standard Solution Development Life Cycle (SDLC) perspective, offshore work is most beneficial in the construction and testing phases where, just as in data conversion, end-user interaction is limited, and the task is well defined.
For stable applications, most maintenance activities can be performed remotely, so application maintenance also is a good candidate for offshore outsourcing. Many large companies already centralize system support, making maintenance a remote activity for most of the end-users. In cases where users may be located overseas, moving the maintenance operations closer to these locations could have added benefits. For 24/7 maintenance requirements, the support infrastructure must be up to the task and some local support will be needed.
With the right communication infrastructure and a clear understanding of your companys business language requirements, call center or help desk functions also can be moved offshore.
2. How big does the project need to be to make significant savings?
In absolute terms, assuming a mix of offshore and U.S.-based resources, a 5- to 10-person engagement is needed to justify taking a project offshore. It could be a single project, function, or series of smaller projects managed together. A smaller project may serve as a low-risk pilot, providing both you and your offshore partner are prepared to underwrite it as an initial investment that will bring benefit from later endeavorsassuming the pilot is successful. You can expect to incur one-time costs just evaluating your options, including possible travel to prospective offshore locations.
On a per-project basis, the offshore option may provide a reasonable alternative in the current economic climate. If your IT department has a staff of 1,000, you should plan for at least 50 positions of your headcount moving offshore to generate noticeable, long-term savings.
3. Is the project well defined?
Well-defined projects that allow the project team to work independently and autonomously are ideal. For example, projects like data conversions and system migrations work well because little or no user interaction is required until user acceptance testing. Likewise, development tasks such as remote construction are good candidates if you and your offshore partner have a sound development methodology in place and reasonably firm requirements and design.
Offshore testing with a properly constructed software product is another function to consider. Lower offshore rates make rework or changes less expensive, but changes also will involve extensive communication and management overhead. In addition, with excellent electronic communication and clearly defined roles and responsibilities, maintenance works well.
4. Are the right resources readily available?
Does the offshore staff have the necessary experience with your particular software? For example, there may be a very small installed user base of SAP or PeopleSoft in that part of the world, so there will be very few local resources. But keep in mind the local installed user base may tell only part of the storyin some cases, the local talent pool may be enriched by temporary workers returning home. For example, the number of available resources in the Philippines with SAP and PeopleSoft knowledge has increased in recent years as Filipino nationals have returned home after assignments in such places as Australia and Singapore. If offshore resources are unavailable in sufficient quantities for your needs, staff will have to be trained, so the anticipated savings may not be realized as quickly.
5. Is your environment easily learned?
If you are considering a development project, take into account whether your offshore partner wrote the requirements or created the design. If you are considering either maintenance or testing projects, did your partner develop the application? If so, the learning curve should be short. If not, you may have to keep your existing staff in place while your new offshore partner learns your environment.
6. Does the vendor have good processes?
Being SEI or ISO rated often is used as a selection criterion. However, both these quality measures have been changing. In the last four years, the SEI Capability Maturity Models (CMM) have been upgraded, and the new CMMI models (I=integrated) improve upon the best practices of previous CMM models in many important ways. Look at the rating but also beyond it. SEI requires specific processes for software service providers but does not require regular reassessments. So ask when and how the company was assessed and by whom.
If the assessment occurred several years ago, ask how the vendors processes have changed since that time. ISO requires regular recertification, but historically ISO has not been as concerned with the actual process itselfso be sure to inquire about the process and what processes will be followed on your project specifically. In addition, remember you now are becoming part of that process, so your existing procedures have to match the vendors. If they dont, then one (or both) of you has to change.
7. What project support will the vendor provide on-site?
The ratio of off-site to on-site people will range anywhere from 2:1 to 10:1, depending on the project type or phase. Even though the bulk of the work may be done offshore, its likely some component will need to remain onshore. The onshore contingent will be the people you see at your site every day, so they will be the more senior team members. Some of the offshore team may need to visit your site initially, incurring travel and expense costs. Offshore projects also bring an overhead in both infrastructure and effort expended in communication. Even if the on-site staff is working at a discounted rate, the big savings are found in the more junior offshore team, so the offshore team has to be large enough and the project long enough for labor savings to offset other costs. Overall, a good rule of thumb is to expect an average of one person onshore (on-site) for every four people offshore.
8. What reporting mechanism applies?
Appointing a single manager or contact to manage the vendor relationship is a good step. Likewise, your offshore partner also should provide a single point of contact as your projects go-to representative. Both sides will have higher-level contacts in place for regular meetings, escalation of issues, and change control. You will need to agree on what measurements will be used to track progress. For a project, this may be project milestones. If milestones are too far apart, consider setting interim goals for better control. For a testing function, you could measure test cases written and tests executedbut its hard to make a vendor responsible for completing the test if its your code and it still doesnt work. For a maintenance or help-desk function, track time to respond to issues and resolve problems. In all cases, keep it simple, at least at first. Ideally, measurement will be a by-product of the process, rather than an end-of-week activity that might consume significant time and effort.
9. What sort of exit clause do you have?
If it all goes bad, or if you just want to bring it back in-house, how do you escape? How much will it cost you to take your system back? Simple arithmetic tells you the painful answer. If you were lucky enough to save 60 percent in costs on a past project, it would be difficult to accept any increases for the same function in the future. This could be very significant when a large IT functionlike a help deskis involved. Even worse, if a project has a critical deadline, it could affect cost and schedule. You need to have contract language that protects you.
10. Should you choose company or country first?
Selecting a country first helps you remove one more variable from the equation and may help you make your decision sooner. On the other hand, working with a contact you know should go a long way toward leveling the playing field. If you already have identified companies youre comfortable with, the local representatives usually will be directly accountable to you and will have a vested interest in your mutual success. If your needs are large enough, perhaps you should look at outsourcing to more than one country in order to mitigate riskas several companies have done over the last year.
Offshore outsourcing can be a powerful force, if the selection is done correctly. You may get 60 percent savings on an offshore technical conversion with little on-site support, but you wont get it on a badly defined project that requires a lot of user interaction. In all cases, do your homework. Give the vendor a trial run on a low-risk project, and measure the results.
Roy Garrad is a national director of solutions for RCG Information Technology, a global IT professional services firm based in Edison, N.J., specializing in IT strategy and design, application development, integration, and project management. He can be reached via e-mail at rgarrad@rcgit.com.
The content of Inside Track is the responsibility of each columns author. The views and opinions are those of the author and do not necessarily represent those of Tech Decisions.
We welcome contributions to Inside Track from industry consultants. Articles should deal with industry issues only (no product pitches, please) and offer advice on solving insurance IT challenges. E-mail contributions to insidetrack@tdmag.com. You will receive a reply only if your submission is chosen for publication. The editors reserve the right to edit for space and clarity.
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.