An article by Nakis Papadopoulous asserts that offshoring does not work for business intelligence applications, though he spends little time discussing why. Off-shoring has clearly moved beyond the pioneering days. My first experience with it was a project when I was at Exxon back in the 1980s, which in itself tells you that ideas often take a long time to really catch on. With the likes of TCS and Wipro now huge companies in their own right, off-shoring has become fairly mainstream, is it ought to be possible to look at some lessons.
While perhaps any project can be off-shored, there is a spectrum of risk that you need to consider. The big Indian companies have developed a high level of process quality, many of them certified to CMM level 5, which is more than can be said for most western IT outfits (about three quarters of CMM Level 5 IT companies are in India), so there is a major focus on quality. However in order to really feel the benefits of this you are going to need a stable, high quality specification; the CMM process is big on repeatable, documented processes. On a conventional project, questions about the specification can be dealt with by someone wandering across a corridor, but this is more difficult many time-zones and thousands of miles away. Hence the more stable and well understood the requirements, the better the chance of success. A perfect example would be an interface program between two systems. This can (and must be) tightly defined, so there is minimal ambiguity. As IT systems (unlike human beings) always behave consistently, there is a high degree of stability where each “user” is an It system. This type of application would be a low-risk one to outsource.
Building transactional systems with a well-documented set of needs should be only moderately risky, provided the requirements are well-defined, which in many cases they will be. Similarly, testing is something that requires a series of well-documented cases and responses, so again can work well in an off-shore environment.
Even with interfaces, are not guaranteed, though. We had a recent project at a very large company where the extract-transform-load was off-shored. In principle this should be relatively low risk, but it turned out badly since, among other reasons, some of the systems to extract from had complex business rules that required a lot of explanation, and because the target system was a data warehouse, where there can be a lot of changes in the data needs as users refine their understanding for what they can do. Much of this work was brought back on-shore and the project is now live, but only after a scary phase.
At the high-risk end, building user-interfaces where a lot of prototyping is needed would clearly be awkward many time-zones away, as would systems where the requirements are rather loose. This is frequently the case in business intelligence, where the users often are only partly aware of what they can get out of a system until they have seen the actual data. Here it is rare to see bullet-proof functional specification documents, so an off-shore team is at an inherent disadvantage compared to one camped out next to the business users. This is above all the reason why business intelligence projects are some of the least suitable to be off-shored.
I’d be interested to hear of any experiences, good or bad, out there with respect to off-shoring. Does you own experience match that of the above, or not?