Many companies are attracted by the benefits of moving their
development offshore, but is it really a good idea? Chris Youett
outlines some of the pros and cons
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:
- Rapid access to high quality, numerous and readily-available IT
professionals
- Wide range off technology skills available
- Stringent quality control
- Shorter project delivery times
- Using the time difference to your favour, especially where the
offshore company provides support or maintenance
The main disadvantages are:
- The customer needs to be prepared to invest in the initial
phase
- The infrastructure of the country the work is sent to may not
be as strong as that in the UK