Outsourcing exec urges: 'Stop outsourcing your software development'

Outsourcing exec urges: 'Stop outsourcing your software development'

Summary: IT outsourcing head points to risks and hidden expenses of outsourcing. There is one underrated practice that can make a difference, however.

SHARE:

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

PVaihansky

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. 

Topics: Outsourcing, IT Priorities, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

17 comments
Log in or register to join the discussion
  • Inconvenient Facts

    None of the issues about experience, competency, or productivity matter in a world of short-term bottom line budgets. Until someone in upper management is held accountable for the failures of these projects, the outsourcing will continue.
    HackerJ
    • yup

      I couldn't agree more. Oh the horror stories I could tell about people who outsourced.
      fldbryan@...
  • Outsourcing is about the bottom line

    I presented this same argument as a layman nearly 20 years ago -- I worked with one systems analyst and a small tight knit group of coders to deliver a completed project with a two year timeline in 7 months. When management decided to get rid of the in-house team and outsource projects, deadlines were never met, but no-one got the blame -- it was too late to reverse course.

    That's when I knew the organisation was on a steep one-way decline, and left.

    When you're top-heavy with management who don't understand anything other than the balance sheet and the bottom line, you get outsourcing.
    sip01
  • Involve the support teams

    Outsourcing firms don't come in with background knowledge your operational standards and procedures. So if you have to outsource, make sure the support teams are heavily involved in dictating how an app is to be operationalized. Nothing worse than to have a support team be handed something that they're not comfortable running with.
    Shan Gu
  • I totally disagree

    I totally disagree with these arguments. While I do agree that outsourcing is not a panacea, it is certainly the solution for some of the challenges faced by the companies in today's world. All the problems you listed with the outsourced developer/firm overseas will be present irrespective of the new team member being a contractor or an employee. An outsourced developer will provide a greater flexibility in terms of hiring and firing. Try downsizing the employees in your team by 25%. Try downsizing the outsourced contractors by 25%. The latter is unbelievably easy compared to the former.

    Moreover, outsourcing firms come with a specialized knowledge of skills which are sometimes simply too difficult/too expensive to obtain. Outsourcing makes sense in those cases.

    My observation has often been that developers live in a dream world that the code they write is rocket science and that no one else in the world is capable of doing it. Taking pride in one's work is good but more often than not, it leads to complacency. Outsourcing service companies have a business need to be not complacent. That makes it meaningfull for companies to outsource software development.

    If you think Scrum is usefull in outsourcing but not waterfall then it means that you are not implementing waterfall properly. As an employee of an outsourcing services company, I can say that Scrum is more challenging than waterfall. I have 10+ years of experience with Waterfall and have not yet seen a failure. Scrum is equally successfull but has the benefit of increased customer satisfaction.

    Software outsourcing earns a bad rap only because Software specifications can become vague. Imagine a hardware OEM outsourcing his component manufactuing with requirements as vague as the ones used in software. Wouldnt' that be a disaster? Similarily with software. The better your specification, the better the output. Garbage in, garbage out.
    Gopi Krishna Nuti
    • About failure of California court management system

      Even with institutional project the significant amount of costs and risks are outside of research & development at all. So that saying that CCMS project has failed because the development team not used Scrum it is a wrong point. If there are 70 different home grown systems to merge it is hard to agree even a single line of specification for the new system with all potential stakeholders.
      Andrey Lartsev
    • Downsizing

      "Try downsizing the employees in your team by 25%. Try downsizing the outsourced contractors by 25%. The latter is unbelievably easy compared to the former."

      That's very fortunate, since (if you go the outsourcing route) you'll be doing it quite a lot.
      mr_eking
    • "ease of firing"... really?

      " An outsourced developer will provide a greater flexibility in terms of hiring and firing. Try downsizing the employees in your team by 25%. Try downsizing the outsourced contractors by 25%. The latter is unbelievably easy compared to the former. "

      So your very first (and presumably best) argument for outsourcing is the EASE OF FIRING PEOPLE? I find your attitude utterly reprehensible.

      The employees, the PEOPLE you hope to so gleefully toss aside on the faintest whim are human beings, with lives and families. Everytime you would use your desired 'unbelievably easy' manner of firing a person, that person's life is horribly disrupted, their families put at risk, and faith in the economy as a whole suffers just a little more. But what the heck, why not, right? As long as YOU are still making money -- who cares about anyone else, right?

      Make no mistake -- there's nothing inherently wrong with making lots of money -- I aspire to do that myself. However, it can be done "the hard way" by diligently planning your projects and PRUDENT hiring so that you can ethically and respectfully bring employees onboard, or it can be done the "easy" slipshod way via callous disregard for your fellow man -- just bring a lot of 'resources' onboard (it helps the ol' conscience not to call them 'people', doesn't it?), knowing full well that its "unbelievably easy" to just start pressing the big red "layoff" button when YOUR lack of intelligent planning is revealed.

      You obviously prefer the latter.
      SbySW
      • Valid

        Its a valid point that people are humans and they have families. Firing in countries like India is quite different, than it is in USA. While there were extreme cases during the peak recession, usually when a company in US says that they don't want the team in India, they get dismantled and allocated to different projects or put on a hold, popularly called as 'bench' in India; which means the person is paid without a project, and he has to hurry up finding other projects internally in the company. Indians understand Indians (while they bitch too!) and the manager's one of the top responsibility is to make sure the employee is placed into a different project. So in a couple of months new projects come in or an existing project needs a new resource or so, the person gets in there...

        So its not always the 'fire' in US.
        Aston Martin
    • Good one

      Good one Gopi, as a person who observed Indian services company I can validate your points.
      Aston Martin
    • Outsourcing

      In 10 years you haven't seen any project failures!? Really!? And you say you have 10+ years of experience. Why don't you just admit that you are on the Indian end of the equation and that is why you are trying to present everything as Kosher?

      Any honest PM will tell you that he/she has been through a project failure.

      Otherwise, one of the replies below tells straight how good your planning or client expectations management is if you hiring and firing people like they are ports in a network switch to enabled or disabled.

      The reality is that outsourcing requires a lot of work. I managed teams in India remotely from Cupertino, CA for the last 6 years. Even with all the experience I had, I still needed to handhold a lot of these developers. Most of the problems were language related. There were of course technical challenges in about 3 months they were easily overcome, not without the help of our experienced in-house staff!!!

      The gentleman who wrote the article is an outsourcer. That is why he is dishing out this initial negative spin followed by the salvation of Scrum. Any critically thinking person will see this clearly.

      The truth is that you should target for outsourcing TECHNICAL, and I repeat, TECHNICAL tasks that your internal people are way to busy to deal with. This way they will have a chance to focus on the ones that really make your business competitive. So:

      1. Outsource only technical, well documented work - a kid 22 years old with keyboard should be able to do it. The work "kid" was not arbitrarily chosen. Don't send full spec with business and functional requirements. You will only cause confusion and faulty work as the spec will no doubt be interpreted differently.

      2. Dedicate culturally-versed managers to run a tight ship - you need at least two, with one in-house and one in the remote office. The remote manager MUST be trained in-house first. This is additional cost but it is well worth it.

      3. Never allow the remote team to perform Architecture tasks, participate in you meetings in-house, or talk to your customers directly for gathering requirements or creating design documents. You will fall months behind with your development and customers will give you the boot very soon.

      4. Leave Architecture, Design, and main system component development in-house. Invest in the people who perform these tasks and once they are super at what they do UNDER NO CIRCUMSTANCES let them leave!!! Use bonuses, praise, promotions, exciting work with partner companies, and all other carrots to keep them from even thinking about quitting.
      kovachevg@...
  • Risk of project failure

    Could you share please the source of statistics: between 30% and 50% of outsourced projects fail outright
    Svetlana1
  • disagree

    Just one more article about Saving_Costs_With_Outsource (INC.com) http://www.inc.com/gene-marks/small-business-confessions-of-an-outsourceaholic.html Or what people say on Forbes: http://www.forbes.com/sites/quickerbettertech/2012/08/27/outsourcing-fuels-ukraines-it-boom/

    We worth what we charge here in Eastern Europe and a lot of projects from really large companies including Misr>>soft, Sk...pe, Haffi...ton post run their projects here.
    We have great skill set for very fair market price, follow SCRUM, Agile and some companies already got certifications for CMMI and ISO for some products , so you want to say that all that giant companies do not know HOW TO SAVE COST ON DEVELOPMENT? and IF WERE SO BAD _ would they ever come on our market?? never ever.
    So please stop saying that - because it's not true at all
    JennyZor
    • Outsourcing isn't for everyone

      Sure, huge projects with large companies may be able to silo off pieces of development that are well defined. Smaller projects that are specific to a certain business domain require that the development collaborate closely with the business subject matter experts. That just doesn't work well with offshoring.
      bmonsterman
  • prices

    Just compare rates from locals with rates for the same skill set/ o complete the same scope overseas - and it would be obvious how to save your dev cost (from 15K with locals to $3-4k for the the same scope with off-shore provider from Europe).
    JennyZor
  • Outsourcing In benificial..

    I have couple of years outsourcing experience and It's nice experience working with my outsourcing partners, It might be possible some time people face Lot of problem just because wrong partnership but we can't say Stop Outsourcing.
    OTS Solutions
  • Yes, outsourcing is not a panacea

    ...and is not for everyone. But the risks can be mitigated if you use such approaches as Agile or Agile dedicated teams like ones described at http://www.acceptic.com/articles-and-reviews/agile-dedicated-development-teams.html . Our experience shows that Agile teams are quite efficient and much more a risky way to outsource.
    Acceptic