Outsourcing chaos begets more chaos
By Alexander Pozdniakov | July 25, 2012
A recent example of software-related troubles at RBS described in this Computing Magazine article is a good illustration of the GIGO principle (“garbage in, garbage out”). If you have a mess on your hands, outsourcing it won’t solve the problem.
Outsourcing of application development is (understandably) often blamed for problems with software. Sometimes the criticisms are true. However, in certain cases laying the blame at the feet of an outsourcing partner masks the real problems instead of solving them. While software outsourcing does introduce complexities of its own (and hence has the potential to create new problems), my observation is that generally, well-run companies are far more successful at outsourcing than those run poorly.
I certainly don’t know the details of how the situation developed at RBS, but I can imagine something along the following lines:
Long before the decision was made at the bank to go offshore, the signs of chaos were already in place. As with any chaos in IT, it was adding some burden to the normal costs of operations, release management, environment management and testing. In the attempts to fight the costs (resulting from poor management), there were undoubtedly people who tried to improve things locally and introduce some order by using proper processes and procedures. Others started bringing in new partners, including offshore. Once that was done, life became easier because offshore directly reduced some of the costs, which was clearly visible on the balance sheet. The voices of reason calling for making things more organized regardless of where the resources were located were probably drowned out by the cheers at the cost cutting success.
On a separate note, in what I think is a very characteristic example, one of the particular failures at RBS was with testing. I can understand why people would want to treat testing as a commodity. However, as the article sadly explains, it is really not. Unless the testers understand the system from the standpoint of its user, they are almost guaranteed to miss important defects. An integrated team with test engineers ”on board”, working closely with the business users in short iterations (aka Scrum) would eliminate the bulk of the costs of testing and rework…
The good news about offshoring is, you are guaranteed to have a reliable scapegoat. The bad news is, having someone to blame doesn’t really help. Unless organizations go offshore with clearly thought through objectives and expectations that based on a realistic assessment of their situation, we will keep seeing the words “offshore” and “failure” together in similar articles for a long time.
If you are not sure in which direction to lay the new road, adding more bulldozers is likely do more harm than good. It is important to understand that in such cases, offshoring troubles are a symptom rather than the cause, or a magnifying glass that makes existing problems more visible.