It may be a cheap and exotic alternative, but can outsourcing an IT project to developers 5,000 miles away actually work? Julia Vowler discovers it can.

Any development project is risky business - fighting to bring it in on time, within budget and, of course, with quality. But what about when you cannot even see the developers because they are 5,000 miles away with a six-hour time difference separating you and their mother tongue is not English? For some, the very idea of going offshore for software development is too scary to contemplate.

But can offshore development be safe enough to undertake successfully? Yes, IT directors heard at last week's Computer Weekly 500 Club meeting. However, they were told it requires a realistic understanding of what can and cannot be achieved offshore. You need to know what it will cost and what it will save; how the time, distance and cultural difference will affect you; and, above all, that an offshore development project requires strong, active management, of the right type.

The number one driver for putting development offshore is, of course, cost. Put bluntly, IT skills cost less outside western Europe and the US. In India, for example, they cost on average about a third of the price they do in the UK.

This is, undoubtedly, a compelling argument, but do not get carried away by this basic statistic, warns the 500 Club's Geoff Petherick. Petherick related his own offshore experiences where his software company GSoft, brokered a deal between the supermarket giant Asda and Indian software house RS Software.

Expect the project to come in at about 50% of a UK project, he says, not 30%. The extra 20 percentage points will derive primarily from the cost of your management overhead, as well as the fact that any Indian nationals working outside India, whether in the UK or anywhere else will need to be paid at US domestic rates for those IT skills. Once out of India, Indian developers do not come any cheaper than their US equivalent.

The management overhead is something that must not, on any account, be skimped, warns Petherick. Outsourcing any work requires firm, careful management of the contract and the project and the same is true of offshore outsourcing. However, management must take into account the particularities of the offshore scenario.

Perhaps the number one principle to apply is not to attempt to go it alone. India has a growing number of very large, very experienced software houses but UK companies should employ them via a UK-based partnership. There are two good reasons for this: the UK end of the partnership will know how the Indian software market works, how to set up the project and where the pitfalls might be as well as the prizes; and in a worst-case scenario it will give you someone to sue on your home territory if things go wrong.

As well as selecting your UK-based partner and the offshore software house, you will need to select the project to be outsourced very carefully.

Levels of IT skills in India are very good, says Petherick. The success of the Indian education system has resulted in excellent IT professionals with a wide range of skills and an extraordinarily high level of motivation, he says, means that Indian IT professionals not only work very long hours but will go to great effort to increase their skills. A good level of skills and a very strong work ethic is the norm.

"They start early and finish late - I was paying them for an eight-hour day and I got 12 hours," says Petherick. "And within 48 hours of seeing the Asda code for the first time they had produced an on-site demo for the supermarket. I was staggered."

Many of the Indian software houses have Capability Maturity Model (CMM) qualifications for software development, as well as ISO 9001/2, and some also have the Personnel CMM qualification for education, training and staff development.

For all that, he warns, the Indian software industry is still young compared to the UK, which means that someone with seven or eight years under their belt is considered very experienced by their standards.

Also, warns Petherick, "Do not believe everything in a CV. Check out claims on, say, the Unix experience cited. It is amazing how easy it is to fall into that one."

It therefore makes sense, advises Petherick, especially for first-time offshore projects, not to be too ambitious.

"Do not do highly time-critical, complex projects," he says.

Hold fire on them until you have established, through experience, a long-term partnership with the offshore house.

Joint and rapid application development projects may also not be best suited, since they require a high degree of communication and interaction between developers and business users which will inevitably be more complicated to deliver remotely.

Support work is popular, especially the kind of work and systems that are no longer popular in the UK. UK staff can be glad to ship such tasks overseas and free them up for the more interesting work, like e-commerce (although, points out Petherick, Indian IT professionals are also very keen to do e-commerce projects).

Testing can be an excellent task to outsource offshore, often on the grounds that it is all too easy for it to fall off the project agenda due to lack of time or resources.

It also makes sense, especially for a first offshore project, to ensure that not only are there very clear and measurable deliverables, but that, ideally, they can be divided into smaller chunks so that a very close check on progress can be made. This gives a better comfort factor and helps to mitigate the time, distance and cultural differences.

Whatever the project, setting it up properly in the first place is essential. You will need to have some of the Indian team onsite in the UK, says Petherick, as the "front end" of the Indian side of the project. The front-end staff will need to be the most experienced and most culturally adapted to the UK. In India there will need to be a team leader per project module, plus developers.

What is also advisable, says Petherick, is a trip by the UK end out to the Indian site to meet your team. "I thoroughly recommend it," he says.

Face-to-face contact makes each side of the project real to the other, which will pay off as work progresses. It helps to inspire confidence by the UK side and to make the offshore site less alien. Team building is just as important - if not more so - when a project team is multisite.

"We gave Christmas bonuses and exchanged Christmas cards and tried to make it a two-way thing," says Petherick.

The practicalities of offshore development inevitably entail communication links.

"Set these up from India, not the UK, or it will be a nightmare," urges Petherick. Doing it that way, he says, meant that "we got a 128k line installed in four and a half weeks, rather than four and a half years".

Be prepared as necessary to ship out development boxes - accessing UK boxes will be very heavy on bandwidth, warns Petherick.

The Asda project shipped two Unix boxes to India where, at the project's peak, l5 developers were using them. Because of the extremely strong work ethic, maximal usage of kit is not uncommon in India, with two developers often sharing a screen.

"I even saw one PC where the screen was split into four and had four people working on it," says Petherick.

The six-hour time delay can be an advantage, not a problem, when it comes to turning work around. Indian developers can work while the UK sleeps, squirting their output down the line to the UK to be checked out first thing and returned as necessary.

"Work was almost continuous," says Petherick, of the Asda project.

However, he warns, "The project will not look the same as a project run by UK guys," but Petherick acknowledges that confidence at the onshore end will grow as the project proceeds and the modules "land".

Going offshore with your eyes open, understanding the constraints and opportunities that apply and committing yourself to the necessary management overhead will make the experience a success. And before the closing of the salary gap that must inevitably occur as the rest of the world equalises with the West, offshore development could take the pressure off your all-too-busy systems development department.

Is there any downside to going offshore?

"Do not drink the water" when visiting the Indian site, say Petherick from experience, "not even to brush your teeth in a five-star hotel".

Petherick's guide to offshore contracts

  • Whoever cuts the code, make sure your contract is with a UK company - you do not want to pursue any worst-case disputes in foreign courts

  • Choose a UK partner that knows the offshore software market - do not go it alone

  • Cultural differences can mean that offshore developers are sometimes too deferential to seniority and need to be encouraged to comment freely, if needed, in front of their seniors

  • Cultural differences can mean that "yes" is a favourite word - you may need to check that when they say "yes" they mean "yes"

  • Not all projects are suitable. Especially for a first project, choose one that has clear, measurable milestones and deliverables that can be assessed so you can check progress yourself, not rely on routine reports file from Asia

  • Like it or not, be prepared to comply with non-UK attitudes to greasing the wheels of official bureaucracy by judicious application of unofficial exchange of funds in order to speed up what can otherwise be a painfully slow throughput of things like visas and work permits

  • Rather than being a threat to in-house staff, offshore teams can be used to work on projects that often get ignored onshore, such as legacy and testing. In-house teams can then concentrate on cutting-edge work such as e-commerce

  • Team building is important, even over long distances - sending greetings cards at festival times.

    India is set to enjoy growing software exports

    Size of the market - projected growth

  • Revenues in India were $5.7bn (£3.8bn) for financial year 1999-2000, showing growth of 50% per year for the last 10 years

  • Software exports are now 10% of India's total exports at $4bn

  • A Nasscom (The National Association of Software and Services Companies) and McKinsey & Co IT report (2000) says that software exports from India will be worth $50bn by 2008

  • In the US more than 185 of Fortune 500 companies outsourced at least part of their software needs to India in 1999. Although the UK has not embraced this approach so widely, the interest in outsourcing is growing significantly.

    Quality of deliverables

  • Indian services companies rely on the quality of the deliverables in their last project to act as a reference in winning the next project, so commitment and service are paramount

  • Many Indian software companies have embraced the Carnegie Mellon University's Software Engineering Institute Capability Maturity Model (SEI-CMM) as a means of ensuring continuing and improving quality throughout the organisation

  • One word of warning - make sure your own processes and procedures are up to scratch if working with an SEI-CMM certified company to maximise the potential. This is one reason why projects have failed in the past - because the client was not sufficiently mature in their own organisation.

    Cost advantages enjoyed by clients

  • If the resources remain offshore then savings of up to 65% over UK rates can be enjoyed by clients. If resources are used onsite then anything between 20% and 35% can be saved, depending on the type of resources. The key is to use a combination of onsite and offshore to maximise communication and reduce development time by ensuring that requirements are fully defined and that mid-project changes can be understood and catered for, etc. Generally this results in savings of up to 50% over the use of internal resources.


  • Email Alerts

    Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    This was first published in March 2001

     

    COMMENTS powered by Disqus  //  Commenting policy