Renee Boucher Ferguson reports in eWeek this week that companies are finding that offshoring might not be all it's cracked up to be. She cites research from AMR that only one-third of companies outsourcing are satisfied with the cost savings.
Some of the challenges companies experience are the language barriers, time-zone differences, and generic cultural differences. In my opinion, it is these cultural differences that sometimes become the key. As one person in the article said mentioned, the offshore developers may be good programmers, but they aren't very good at the business logic. This is very consistent with my experience as well.
Offshoring worked in some of the Y2K conversions. You could send a box over to India and say: "send me back exactly this software but with four-digit dates. Don't change anything else." It worked well most of the time. It was highly repetitive work with very clear boundaries. It also isn't work that a good programmer could really do much faster than a poor one, it was rote.
Based on that success some companies started to shift business system development abroad. In addition to incurring additional costs to manage those supplier relationships, they started to find that communicating business requirements and getting appropriate solutions back can be a challenge. What went wrong?
We take a great deal of tacit knowlege for granted in business, and much of that knowledge is culturally anchored. I know of no other culture where the fundamental concepts of business are so deeply, really unconsciously, embedded into the minds of its citizens.
Although software development is a technical task, the technical side of business application development is not usually where the complexity lurks; even when genuinely innovative business software is built, it is not the technology that is innovative, it is the application of that technology to a business problem. If you've ever worked directly with a software team, you've probably found that getting them to understand what the software needs to do is the hardest part of the process.
You've probably also found that best software people are the ones who can actually understand why you want to do it, understand the root problem you are trying to solve. If they understand that, and the're smart, they can come back with ideas about the how and even the what that deliver the results. The worst ones never really "get it" and the software they produce tends to show it.
Now if you thought trying to explain business concepts to an American or Western European developer could be a little challenging, even with their cultural knowledge of basic business practices, imagine stripping that knowledge away. One of the first things companies doing offshoring found was that extremely (sometimes excruciatingly) detailed requirements were critical, because sometimes "obvious" isn't obvious to everyone. Of course, this does improve things, but step back and think about the problem.
The first problem is that even with fairly detailed requirements, developing new software inherently carries with it myriad tiny decisions, implementation judgements. The second is that there is significant incremental cost associated with detailing requirements at a greater and greater level of detail. I have seen detailed requirements documents that literally took more time to produce than actually implementing those requirements, and these were not confusing requirements at all. In one case that comes to mind, I believe the substantially same system could have been created by a good developer (in about the same amount of time) based on 10-bullet point outline and a couple hours of meeting with the business process owner.
The third problem is that these costs frequently get externalized out of the development account. When a business process owner has to spend more time communicating, correcting and clarifying requirements, not only are they are distracted from doing their other work that presumably adds value to the company, but often, even the basic cost of their time is not attributed to the accounted cost of the project. And there is also the opportunity cost of the additional duration added to the overall lifecycle of the project. If a project can be done in six months, but it takes nine because of additional time spent on requirements, the business is deprived of the cost-saving or revenue-producing value of that software for an extra three months. When you start to add things up, the difference between "cheapest" and "best value" starts to grow.
Of course, many companies will continue dip into offshoring for the first time and others will try to improve their processes to make it work better, but I think companies would be advised to look more broadly at their IT development strategy and reexamine the assumptions and cost models related to offshore development. Offshoring may be an answer in some cases, but policies requiring a certain level of IT dollars to be spent offshore, "because it's cheaper," as I have found at a couple of very large enterprises, will ultimately prove penny-wise and pound-foolish.
If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.
Comments