I continue to be surprised at the continuing flight many firms are making to offshore development, even as many of the early adopters of offshoring are returning to domestic sourcing of more services (See "Return to Sender"). I think much of the pressure for offshoring comes from flawed assumptions and possibly flawed logic, both of which merit discussion.
Possibly the most pernicious situation with offshore development is the preordination or blanket directives for using offshore development. As an example, about three years ago I was in discussions with a global manufacturer about contracting with my firm to build a reasonably complex software application. I knew what the complexity of the system was because my firm had already built a very, very similar application. As we are able to do with most of our engagements, I suggested that we could do this for a fixed fee, and ballparked a fixed fee cost of approximately 1/2 of the next best (primarily offshore) development estimate they had on the table. Seems like a no-brainer, right?
Wrong. The buyer inquired: what percentage of your labor is offshore? I said zero. He said that the firm had a hard and fast policy, directed by their CTO, of using 50% offshore labor. I inquired as to the motivation for this. His response: cost savings. My response: but onshore development will actually save you around 50% on this project (bear in mind that a 50% savings on this project was about a million dollars, or about 1/4 cent EPS for a market cap impact of $20 million * ). His reply, it doesn't matter, we have to use 50% offshore labor. Why again? It saves money. There was simply no getting around the rule, even though violating the rule in this case would have better served the intent of the rule.
If you're curious what happened with that project: they used the offshore firm, which was true to their estimates on cost, but turned out to not really be able to deliver on the project. The individual I spoke with, two levels of his superiors and all of his peers were let go as the project faltered and the intrapreneurial initiative failed. Sadly, it was none of their faults: the requirement to use offshore labor was imposed by the global organization's senior management, several hundred miles away.
The fundamental problem creators of such rules and guidelines make is evaluating the cost using the wrong unit of measure. As a business person, do you value your IT purchase by the hourly cost of the labor effort, or by the aggregate value or cost of the system, including lifecycle? Presumably it's the latter, certainly it seems most logical to operate on the assumption that you want a system for X dollars, not simply having a system constructed for Y dollars per hour.
The premium placed on the labor cost per hour in evaluating the cost-efficiency of software development alternatives relies on a fundamentally flawed assumption, namely that IT labor is fungible, that is to say, that individual IT professionals have nearly equivalent productivity per hour of work.This might be true in some areas, such as testing (and testing and validation is a great use of offshore labor), but is definitely not true of designing and writing software. That is as true today as it was back in 1975 when Fred Brooks wrote the seminal book on managing software development, The Mythical Man Month. I have recommended it to many business people, as it is one of those true classics, in the same way that Drucker from the 60's is more valuable than 95% (or even 99%) of the business books that have come out in the past 5 years.
One of the things that Brooks points out in his book is that the best software developers aren't simply 20 or 50% more productive than the average developer, not even twice as productive. Brooks' assessment is that exceptional developers are an order of magnitude more productive than average developers. While not everyone can recognize this, it is very much true. I think this is often not recognized for a variety of reasons, one is that a weak team can destroy the productivity of the strongest developers. Often, a team of four developers would be more productive if three of them just didn't show up, or confined themselves to the more tedious tasks delegated by the best programmer. In fact, this is the "surgeon" approach largely endorsed by Brooks. I would be happy to elaborate more on this if there is further curiosity.
And it certainly does appear that the fixation on dollars-per-hour results based on this flawed assumption seems to be behind the offshoring movement. I was recently looking at some IDC research from May, in which they surveyed 27 firms using offshore development. They asked about the top criteria for determining offshore company attractiveness: #1 was low wages, #3 was high quality technical talent. Fourth was English competency (which is both intuitively and practically a key consideration in the area of translating business requirements into functioning software).
I would encourage buyers to think about the one key metric that matters in buying software development services: the money spent getting the desired application functionality. Sometimes offshoring may be a component of this, sometimes a package application offers an efficient route to success, sometimes i means in-house development and sometimes it means locally-contracted expertise. Look for things like fixed fee development and a good track record at translating business requirements into software. Those are the ways you can maximize your ROI on software, not simply buying the cheapest labor.
Think about it this way: would you ever base your choice of an attorney or accountant primarily on price?
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