Is Offshoring Less Expensive? Exposing Another Management Myth

I was in the midst of an assessment when the CIO came to me, and shut the door.

“I have a serious question for you.”

I nodded for him to continue. I put aside my papers to show him I was providing him my undivided attention.

“I’m thinking of offshoring all the testers. What do you think?”

“You can do that. If you do, you will take longer to get a release out the door. Since you brought me in to see why it’s taking you 18 months to get your 9-month releases out, I’m not sure it’s a wise thing to do. Why are you thinking this?”

“All the other CIOs I know are doing this.”

This was in 2002, just as the offshoring/outsourcing boom was starting. Agile had not yet become an accepted way of working. I had recommended working in feature teams and working in timeboxes, with small(monthly) deliverables, with people working on just one project at a time. Yes, you can see my current thinking in that report.

That CIO was not alone. His management and his board was exerting tremendous financial pressure on him to reduce the cost of his projects. At the same time, they were exerting the same pressure to release faster. He was stuck between a rock and hard place.

In another assessment, just a few years ago, I encountered the same situation, where senior management had made the decision to hire developers in New York City and testers in Singapore, a 13 hours time difference.

I’ve met people in my teaching who have developers all over the US and testers in the Far East. Every single time I hear the same story: the delays in the project are overwhelming. Read Lessons Learned from Leading Workshops about Geographically Distributed Agile Teams for more information.

Why does senior management do this? Because they do not realize that software is about design and learning. Design and learning are collaboration efforts. When senior managers think software is like manufacturing, they miss the essence of software: collaboration.

What are the successes? When you hire feature teams in one location. What? You think you can only hire testers in India? Ha! They have developers there, too. Or China. Or Vietnam. There are developers all over the world. Do you need to teach them English, or French, or German, or whatever your project language is? Yes.

That is the subject of this month’s management myth: Management Myth 21: It’s Always Cheaper to Hire People Where the Wages Are Less Expensive.

Wage cost is not project cost. You need to assess the cost of delay in your project. You need to ask yourself what is driving your project (cost, schedule, features, people, something else?).

What if everyone is distributed? You can do that, too. You need a lot less management. You need to be very clear on what a team is going to do, first, second, and third. If you yank a team around and change their goals all the time, you will get nothing out of that team.

Decide on how much management you want. If you are a larger organization and want/need some hierarchy and you want people to come into work every day, go for feature teams in one location or another. If you are smaller and can manage with less management/hierarchy, go for distributed or dispersed teams, where people work anywhere, but are more or less in the same time zone.

But, the more time zones apart people are, the more difficult it is for people to collaborate. That is why geographically distributed teams are so difficult to make work, for agile or any other team.

Can you hire people anywhere in the world and make it work? Of course you can. As I have said before here, you are smart people. You can make anything work. At what human cost?

Read Management Myth 21: It’s Always Cheaper to Hire People Where the Wages Are Less Expensive.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in management and tagged , , , , , , , . Bookmark the permalink.

12 Responses to Is Offshoring Less Expensive? Exposing Another Management Myth

  1. Alex Deborin says:

    Another great post! Thanks Johanna! Software development is not manufacturing. I really like that one. You right, too many execs just dont understand that. How many of them tried to apply six sigma to software development? Same results for the same reason. It is about design and collaboration. Could not summ it up any better.

  2. Alex, thanks. Let’s not blame the execs. If they don’t understand, it’s our job to help them understand.

  3. Pingback: Five Blogs – 13 September 2013 | 5blogs

  4. Jo Davis says:

    Not really, every Exec i have come across is a Dinosaur, they dont belong in this age and cannot adapt or don’t want to. The only thing left for them to do is go extinct and let new blood take over.

    Agile is a very old concept, which us developers had been practising for ages under the radar… until recently. Now ‘Execs’ and ‘Senior’ management is latching on to it because ‘everybody else’ is. They have no brain power of their own. They have turned the Agile concept into something Alien.

    End of the day, they’ll do what it takes to pay the mortgage.

  5. Jo, your cynicism is showing!

    You do have a point. If the managers do not understand the dynamics, the cause and effect–including the effect of delays–of the processes under their control, they screw things up. That’s why I’m writing these myths and will be turning them into a book. If I package them in a way that people can understand, I hope to be able to change things.

    I think I have a shot.

  6. Pingback: New PM Articles for the Week of September 9 – 15 | The Practicing IT Project ManagerThe Practicing IT Project Manager

  7. Pingback: When to Outsource? | Anders Lybeckers Weblog!

  8. Ian Mitchell says:

    > If the managers do not understand the dynamics, the cause and effect–including
    > the effect of delays–of the processes under their control, they screw things up.

    I’m even more cynical; I’d say they screw things up even when they do understand the dynamics. Of course it’s important that they *do* understand, but this is only the first of many barriers to change. We must also consider, amongst other things:

    – The opportunity cost of change. Maintaining the status quo limits both opportunity and, within certain tolerances, risk. Hence managers feel obliged to change not when it is sensible to do so from an organizational perspective, but only when *they* absolutely have to.
    – The tragedy of the commons. Every manager can embrace the status quo until the wheels come off and immediate change becomes unavoidable. By that point the costs and risks are far greater, but they are also shared and no individual is likely to be held culpable.
    – Future discounting. The risk that “something must be done” before the manager retires or has the opportunity to move on is regarded as low. It’s better to take the management rewards available today (status, bonus, expenses, paycheck) than invest in risk-avoidance that will cost the manager now, and which might not prove necessary to him or her at all.

  9. Ian, in larger organizations, managers are rewarded for doing something, even if that something is wrong. Few organizations reward managers for appearing to do nothing.

  10. Ian Mitchell says:

    > in larger organizations, managers are rewarded for doing something,
    > even if that something is wrong

    I agree; my cynical observation is that they are rewarded for maintaining the status quo.

    > Few organizations reward managers for appearing to do nothing.

    Again my cynicism takes hold! Appearing to do nothing is a very low risk for managers skilled in “success theater”, as Eric Ries has termed it.

  11. James Wilson says:

    Hi,
    Thanks for the share.According to me global sourcing is less expensive.

  12. James, if you have managed to make it less expensive, I wish you would share your secrets. When I map the value stream for my clients, it is not less expensive. I have data. The data is:

    – the cost of initial training
    – the cost of delay in asking questions and answering questions
    – the cumulative flow in getting features to done (you can measure this in any project management approach)
    – the total time for a project, estimated and actual

    If you have data, I would love to see it. I bet my readers would love to, also. I’m not trying to be mean, although it probably reads that way. I am saying that every time I have gone into clients, helping them with their projects that have gone astray, when I ask for this data, their offshored projects are not less expensive. They often cost more than the collocated projects, because of the delays. The delays offset the wage differences.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>