Outsourcing exec urges: 'Stop outsourcing your software development'

IT outsourcing head points to risks and hidden expenses of outsourcing. There is one underrated practice that can make a difference, however.
Written by Joe McKendrick, Contributing Writer

The following is a guest post from Peter Vaihansky, general manager-Americas for First Line Software, who urges IT executives to consider alternatives before outsourcing code development.

By Peter Vaihansky, GM Americas, First Line Software

Do not outsource your software development.
Yes, you read that right. I work for a software development outsourcing firm, and I am telling you not to outsource.
But why not? Everyone's doing it, and everyone can't be mistaken, right? The common perception is that outsourcing saves money based on labor arbitrage. There may be other factors, but mainly companies do it in order to get more software, probably faster, for less money.
However, the economics of outsourcing are far less straightforward than the labor rates comparison suggests. There really is no such thing as "labor arbitrage" in software development. Unlike copper or wheat, all developers are not created equal, so you are not exactly trading commodities. Furthermore, outsourcing is definitely not without risk, as discussed below. So the concept of arbitrage doesn't apply, and with it goes the whole proposition.
Losing financial ground: First of all, are we comparing apples to apples? Yes, that overseas firm only charges you $20/hr for a developer. But how much value are you getting in that hour? How competent is that developer? Are you getting strong people on your team, or mostly recent college grads with questionable skill levels? What experience do they have? One experienced $100/hr in-house developer may well produce more value for you than five or even more junior $20/hr people overseas.
Also, remember that you need to train external resources. Initially, they don't know your product, they don't know your process, and you haven't worked together before, so it takes time before they can begin to produce value. While necessary, the investment in a learning curve definitely eats into projected savings. And that senior in-house developer who is fully up to speed will be outperforming them again.
Now let's say you are beyond the initial knowledge transfer. Are you realizing those savings yet? Hardly. With software development, communication is key. It's hard enough at times to explain to an experienced person in the same room what you want them to build. Imagine doing the same with someone who is thousands of miles away, relying mostly on email and IM, and sometimes on voice and video Skype calls. Software development is a highly involved social process, with people sharing complex ideas and abstract concepts.

And no, documentation won't completely remedy this: you can't really document everything about a system up front, and any written text is always subject to multiple interpretations. Plus, the market changes so quickly that, by the time your documentation is complete, it's typically obsolete and new requirements are driving a different system. Software development deals with tacit knowledge and emergent understanding. Again, hard enough in-house and even more challenging with an outsourcing supplier (think cultural differences, accents, communication barriers, etc.).
What about the ability to put more bodies on a project? For example, you are late in your release schedule and tempted to add cheaper offshore resources to meet deadlines. Unfortunately, if you do, "Brooks' Law" is likely to take effect. This famous principle states that adding resources to a late project will make it later or, as formulated more colorfully by its author Fred Brooks, "Nine women can't make a baby in one month." Even when a project is not late, more people does not equal more value. With the complexities of communication, a larger team moves more slowly, sometimes significantly so, and productivity is consequently lost. Your investment may buy you more developers overseas, but not necessarily more value in the form of marketable software for your dollar.
Also, don't forget the extra management costs you'll expend communicating with and monitoring the performance of your supplier. Aberdeen Group's research shows that over 76% of customers report project administration and vendor management costs to be far higher than expected, which won't come as a surprise to anyone who has done any outsourcing.
Finally, consider the overall risk of project failure. The stats vary but, depending on the source, between 30% and 50% of outsourced projects fail outright: they are either abandoned completely (and the work is brought back in-house at additional cost), or fall radically short in terms of the functionality and business value they deliver. Granted, not all in-house projects are completed either but, with outsourcing, the risk of project failure is higher.
So please, do not outsource your software development.
Unless you absolutely have to. And unless you do it with Agile. More specifically, Scrum.  Sometimes keeping a project in-house is not an option. For example, you may need to ramp up your development team quickly to ship a product by a specific date or risk of the window of opportunity closing, but you know you can't hire enough high quality people in your geographical area. If you are going distributed, you are essentially outsourcing and at least some of the difficulties inherent in traditional software development apply.

Outsourcing to a company using Scrum, however, will help you overcome the obstacles that make the traditional approach unwieldy and inefficient, and that cause endemic project failures.  How so? Unlike the traditional "waterfall" approach, where all software is delivered once, at the tail end of the project, Scrum focuses on providing a continuous flow of value to the customer, which minimizes project risk and increases return on investment. With Scrum, catastrophic project failures like the recent California Court Management System (CCMS) $500 million debacle are impossible by definition.
Inspired by the Toyota Production System (TPS), Scrum was first introduced in a conference paper by Dr. Jeff Sutherland and Ken Schwaber in 1995. Scrum is designed around several foundational principles and practices, including development in short iterations, incremental delivery of potentially shippable software after every iteration, prioritization of features around business value, and direct customer involvement in planning, elaboration and acceptance.
Sutherland's research shows that, when run properly, Scrum can help achieve -- even on a large, globally distributed project -- the type of hyperproductivity/extreme velocities only thought possible in small co-located teams, velocities that are several multiples of the productivity typically seen in waterfall teams, in-house or offshore. Applied in the context of outsourced, distributed software development, Scrum acts as a catalyst of communication and as a powerful spotlight shining onto every aspect of the client-vendor relationship, forcing accountability on the one hand and unleashing tremendous productivity on the other.
Sutherland, who currently advises the investment team at Boston-based OpenView Venture Partners and coaches OpenView's portfolio companies in the use of Agile development techniques, explained to me that he counsels OpenView's portfolio companies with this exact advice: either outsource to Scrum companies or don't outsource at all.
Steve Denning at Forbes calls Scrum a major management discovery and, in fact, contends that its founders should receive a Nobel Prize in management, if there was one. Can it in fact help you add people, including offshore, and go faster rather than slower? Can it help you reliably deliver software when working with outsourcing vendors? My own answer to these questions is an unqualified "Yes," but please investigate and find out for yourself. Especially if you are outsourcing, I don't think you can afford not to. 

Editorial standards