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.
“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,” says Lane.
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,” says
Petherick.
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.”