Thanks to Y2K compliance programmes, it is now perfectly acceptable for a firm to consider moving all or part of its systems development and support offshore. While many senior managers will immediately think of India (which is probably the world's leader in this type of IT work) there are growing offshore industries in the former Comecon countries in eastern Europe - especially Hungary and Russia - Pacific Rim countries such as Malaysia and the Philippines, Mexico and so-called "near-shore" locations like Malta.
Tales of cut-price development and support are likely to make the average executive's mouth water. However is offshore development as simple as it sounds?
According to a number of senior figures in IT, unless you really know what you are doing it can create more problems than trying to do the work in-house.
Ian Rickwood is chief executive of Imis, which represents the professional side of the computer industry. He warns, "If you just want coding doing, it is probably OK. The problems start when you put all the parts of the system together. From my own experience, I know that, in a major project, coding is only 25% of the tasks in hand. You have to deal with all the other things like documentation, relations with the customer or end users, project management, systems analysis and design, etc.
His advice for anyone who wants to move development and support offshore would be to appoint a UK project manager who will be close to the client and ensure that all problems are transparent.
"This is often where a mature member of staff will be ideal. All the system analysis needs to be done on-site. You can do the design work off-site, but this requires close co- operation with your analysts," he says.
"Before you start any coding, all IT managers should have a good quality systems specification which the client signs off. This will, of course, cover documentation," Rickwood adds.
His views are echoed by IT guru John Elsden who is chairman of IT trouble-shooters Allied Powers and director of a dozen computer suppliers. Elsden was a pioneer of offshore development in the 1970s and warns that any site going down this road needs to double-check that it has the right mix of management skills. He says, "When I first got involved in offshore development in the late 1970s I quickly found out that good management skills (especially on the communications side) were vital. This is why many offshore projects failed to deliver any tangible benefit.
Elsden believes the reasons why offshore development can be a reality for almost anyone isn't necessarily to do with saving money. His view is that many projects will go offshore because the board wants them moved on quickly, and that this is achievable because of a change in management culture that allows projects to be run offshore.
"Most countries in the world have at least the Internet available - and you would be surprised just how good radio comms are in many far eastern countries.
"There is also a much greater willingness by senior managers to manage people they can't see. In the 1970s, it was difficult to sell offshore projects to boards because they couldn't 'touch' the team."I have people working at The Electric Software Co who I have never met - we judge them on their results," he adds.
IT management also need to agree with their boards how much control they want.
David Lane, research and development director at Corby-based food distribution site Pauleys, believes people are easier to manage when they are based in the UK.
He says, "Don't underestimate the difficulties of remote management and dealing with time differences. If you send e-mails you must allow for different cultures as well as time differences. You also need to check just what your offshore developer will be outsourcing. In India, for example, you can end up with everyone outsourcing to everyone else. If you want people from the offshore operation to work in the UK , allow time to organise work permits. It is supposed to be easier now, but it took me nearly six months to get a permit for one Java specialist."
Cost is obviously a big issue. IT management should not always assume there are no overheads and should ask what sort of savings can be made.
Simon Denison-Smith is chairman of the Computing Services Software Association's Overseas Forum and managing director of Rave Technologies. He points out, "There is always some overhead associated with offshore development."
Most of Rave's clients are software houses who are sharp on productivity issues. So they have to cost in having local project management offshore as well as UK management.
Generally specifications have to be written to a lower level of detail.
"This is the way that UK development used to be done - and many UK developers are guilty of sloppy work in this respect. This is why many dotcom start-ups can't deliver," says Denison-Smith.
"However it does impose quality standards on both the client and developer, so this is a benefit. We also tell clients that they will need to share some of the life cycle of the project with the offshore developers, either over there or in the UK.
"Typically you will get 30 to 40% savings in costs. About 20% of the overall budget will go in offshore overheads," he adds.
The next thing to consider is how to go about selecting an offshore developer. The advice from Allied Power's Elsden is to choose them as you would a UK developer.
"You want proof of their track record, reference sites and what skills they have available. Any reasonable firm won't mind providing samples of work either," he says.
"If it is a single developer, you probably know who he or she is. I expect that IR35 will see a lot more contractors moving to near-shore sites like Gibraltar, Malta and Cyprus which have strong historic links with the UK.
Denison-Smith says, "It is essential for both sides to have the same goals, timescales and clear views about how the project will proceed. The client should not assume that handing over the project is all they have to do. Without client involvement the project will fail.
"Face-to-face contact should never be under-estimated and time on-site in the UK during the project helps to create a closer relationship and a high degree of trust," he points out.
So how should the project be managed on a day-to-day basis? Geoff Petherick, a director of RS Software and GSoft, recommends breaking it up into month-long chunks where possible. This makes it easier to pull out or identify where problems are.
He says, "We have staff in Calcutta and customers throughout the UK, US and Europe. The project must have the look and feel of a UK company, so it is up to the UK end to iron out cultural and language differences. This could mean you will have to handle your overseas developers differently from your UK people."You should also use agreed comms methods and technologies to communicate with the offshore developers.
"This may mean investing in ISDN or tied lines. For example, we recently upgraded Unix systems at Asda in Leeds. Code was transmitted over a comms link for user acceptance testing, which I strongly advise should be done in the UK.
"We have already found that trying to do user acceptance overseas can present major communication problems," he says.
Companies who may be looking to bring overseas developers over to the UK need to do their homework.
Petherick says, "You need to check CVs very carefully unless you know the developers. Although wages are typically only a third of those in the UK it can get very expensive if you have to start putting people up in hotels for long periods."If you do want to bring developers over for, say, six months or more - this is only realistic for long-term contracts as you will probably have to pay UK wages and living costs."
Asda looks to India for promise of project fulfilment
A major project involving the use of offshore developers in India was completed at Asda's Leeds site last year. This involved upgrading all its IBM RS/6000 systems to the latest version of AIX and ensuring all applications and databases were Y2K compliant.
IT systems manager Doug Cliffe said: "The aim was to bring this site into line with all our other systems within the group. We also took the opportunity to upgrade our library management. Initially we set up a small project management team using GSoft's people. This included some of its developers. We were very meticulous at the planning stage and set clear milestones for the project team and offshore developers. This included carefully planning for testing. The offshore people did unit testing and we did overall system testing at the Leeds site.
"We ranked all components in order of importance and went for phased delivery, rather than a Big Bang approach. Problems were normally escalated to GSoft's people onsite in Leeds. This minimised the risks."
So how were day-to-day management and problems resolved? Geoff Petherick, a director of both GSoft and RS Software, says, "Before each component was started, we flew over the relevant team leader from India. We were able to get most of the problems ironed out at an early stage.
"If there were problems, we found that the developers in India had a good command of English - and being four hours behind allowed them to be resolved during the UK's night," he says.
Cliff adds, "We had regular project reviews, which helped to resolve any problems quickly. We also set up a comms link for transmitting the code to and from India. If there was an opportunity to move a major project offshore, I would certainly do so."
Offshore versus onshore
The Computing Services Software Association, which represents the computer industry's manufacturing and services sides, recently set up an Offshore Forum headed by Simon Denison-Smith of Rave Technologies to advise members of the pros and cons of moving development offshore.
It has compiled six major benefits that, Denison-Smith advises, must be weighed carefully against the six major disadvantages that any supplier and its customers will have to deal with if they do decide to go offshore.
The major benefits are:
The main disadvantages are: