Sending software development tasks overseas is the latest cost-cutting phenomenon, but is it a case of 'you get what you pay for'? How can you optimise offshore development?
The buy-or-build decision has long been a part of IT management, and despite suggestions from some quarters that the pendulum is beginning to swing back towards build, emerging export-oriented software development sectors in countries such as India and Russia have added a new dimension to the issue by offering high-quality, low-cost services. Some companies are even pursuing an offshore insourcing strategy by establishing their own development centres in such areas, either independently or in collaboration with a local partner.
On the other hand, there is some political sensitivity to sending skilled work overseas at a time of high unemployment among IT professionals. This could be the reason why we were unable to find local companies prepared to discuss their experiences with overseas outsourcing, or that would even admit they were doing it. This suspicion was confirmed by the outsourcers’ claims that their clients were unwilling to act publicly as reference customers.
Fortunately, outsourcers were able to discuss their operations, and several executives from companies involved in overseas insourcing were prepared to share their experiences.
Projects or products
A distinction should be drawn between outsourcing for projects and outsourcing for products, according to Eyal Aronoff, chief technology officer at US-based Quest Software. If the object is to create software that meets your internal needs then outsourcing is easy, but “the art of building products is different: you have to guess what the user wants” and those guesses can be culturally specific.
By developing some of its software in Australia, Quest benefits from “highly educated people [who are] very brilliant [and speak] English, and we get cost savings” thanks to the exchange rate and other factors, he says.
When producing products for particular markets, having native speaking and culturally attached developers is important. Developing in Australia “works fantastically well for us,” he says. Any potential savings made by going further afield (eg, to India) are nullified because the additional iterations required before a satisfactory result is achieved. For this reason, Australian developers can finish a project in half the time taken by their counterparts in Bangalore, he says, but “over time, that will change” as globalisation proceeds and Microsoft’s standards spread.
Quest’s flagship product, Quest Central, has been built in 14 development labs around the world. “The architectures we have enable us to do that,” says Kim Wenn, director of research and development. Principal software architect Guy Harrison explains that creating the large-scale component architecture that enables new functions to be added as plug-ins was a major hurdle, but once overcome it put the company in a good position. It also makes it relatively easy to add the same new function to multiple products simultaneously.
But architecture alone isn’t sufficient to make distributed development work: management and coordination was also essential. “You have to be in touch,” says Aronoff. “There must be a personal connection between the decision makers” so they are comfortable phoning each other outside normal hours if necessary, otherwise differences in time zones can introduce communication latencies that slow down projects. People are aware of this issue, says Wenn, and they modify their work habits accordingly, “You have to be flexible,” she says.
Innovation is another issue that’s important in product development, says Aronoff. Quest’s Australian staff demonstrate a high degree of innovation and will take risks to generate something different. While this is good for product development teams, it’s not appropriate when building software for in-house use.
The balance between process and innovation is an important consideration when creating products. Stability and quality are necessary, but it’s also important to ship new products before competitors deliver their equivalents. You can get bogged down in communications “and innovation is lost,” says Aronoff.
Outsourcing the internal
Outsourcing the development of internal systems can work, according to its proponents, but they agree these concerns must be addressed. Peter Spring, a director of systems integrator Kanbay, says one of the basic rules of IT development is that you need hands-on management. While offshore outsourcing can provide good time to market, access to expertise, quality, and a different type of innovation, the distance between client and outsourcer scales up the risk.
The best results are achieved when projects are split between local and overseas developers, suggests analyst Bruce McCabe of S2 Intelligence, but it isn’t obvious where the line should be drawn. That said, he believes that local development should be preferred when speed is important because it takes longer to find an overseas partner or outsourcer. Once-off projects can be usefully outsourced, but one involving ongoing development or maintenance is better kept in-house.
Organisations that outsource a project need “a focused, driven project head who takes control and maintains control,” says Ted Johnson, Australia and New Zealand advisor to Indian IT consulting and outsourcing company Tata Consultancy Services (TCS).
Good risk management practices should be applied to any project, Spring says, but it is important to have people from the development centre located on the client’s premises, and for managers to visit the development centre regularly.
Bad experiences occur when clients treat outsourcing as a tactical, cost-saving exercise, but “the ones that work treat it as a strategic partnership,” he says. “The ones that do it properly don’t think of it as a cost-saving venture, but saving time to market.”
Ajay Gidh, head of professional services at NCR India, stresses the strategic nature of offshore development. “We are fully equipped along with local software industry to undertake complete responsibility of software development, customisation, maintenance, and support activities,” he says.
The Indian software industry has created “a new breed of IT managers—infrastructure and process managers—with the agility and flexibility to align requirements of people, skills, processes, and tools to those of client environments and consequently the ability to deliver maximum value to partner organisations that outsource software engineering activities to these organisations.”
Robert Beck, general manager of Kanbay, says cultural issues can be a factor, citing the Indian tradition of respect for elders. This can be manifested in tendency to follow the client’s lead during the high-level design phase even if that course of action isn’t in the client’s best interest. This reluctance to suggest better opportunities is in contrast with the Australian culture of “speak your mind”.
Kanbay uses multi-site activity to deliver what the client needs, he says, and uses local senior business analysts and project managers. Spring adds that Indian staff are encouraged to talk to their colleagues at the point of delivery if they have a concern with the direction of the project but do not want to raise it with the client.
When did it start?
According to Beck, the current interest in overseas outsourcing has its roots in the period from 1998 to 2000. While there were some earlier moves in sending IT work overseas, Y2K and the dot-com bubble meant there were plenty of jobs available in the US and Europe at two to five times local salaries, and “all our elite IT professionals went offshore”. At the same time as this “huge drain of good guys and gals” occurred, local demand was high due to the coincidence of Y2K and the introduction of the GST. The “B team” players remaining in Australia were able to demand high rates, and this allowed Indian firms to gain a beachhead through “bodyshopping” (supplying onsite contractors).
Beck used such people when he was with a previous employer. “They were good—there’s no question about the quality,” he says, but it was up to the client to manage them all as individuals, as they were not supplied as a team. This presented some companies with a problem.
Now, Australia is in an IT recession and there are plenty of people ready to work at lower rates, but many companies are still in a situation where their current budgets are still depleted due to pre-spending on the Y2K and GST projects. The result is that they are risk adverse and looking for ways of getting consistent quality and quick development times at low cost.
“We’re not brought up on quality,” says Beck, but Indian companies are “second to none” in delivering quality services in areas such as IT and accounting, just as Japanese companies revolutionised manufacturing quality.
There is a “political cloud” shadowing overseas outsourcing, he suggests, as local IT unemployment means government departments and enterprises are less likely to hire overseas companies. To counter this, such firms are forming alliances with local firms that bid for the work and then subcontract much of the effort to their overseas partner.
However, large organisations are “concerned with pragmatism,” he says, and seek “quality and commercial advantage” even if it means going offshore.
Spring points out that despite local unemployment, a large bank needs around 100 new staff per year just to cover attrition, and if it outsources locally it would simply increase the competition for particular skills. Overseas outsourcing therefore is about addressing strategic issues, he suggests.
