The company I'm currently employed by attempted to offshore (outsource) the majority of their support work. The experience has taught me a few things. Things about them, and things about us. It was all interesting to watch.
First, people become software engineers for different reasons. At one end of the spectrum you have the people who become software engineers because they love the work. These are the people who run servers at home, write their own software, and generally love computers. At the other, you have people who become software engineers because it's a job with great pay and good job security. They don't have computers at home. They are pure 9-5'ers, and actually have lives outside of work and World of Warcraft.
The engineers we dealt with in the other company were at the "good job" end of the continuum. This isn't necessarily a bad thing, but it did filter into their work product, when they regularly took the easy way out.
Next, outsourcers are out to make a profit! If you are expecting them to do the best thing for your company, you are in for a nasty surprise! For example, bug fixes were as small as possible. Not necessarily a bad thing, except that they were lazy small fixes instead of pretty small fixes. Yes, entirely subjective, but people out there will hopefully understand. They would consistently ignore other problems with the same piece of code, comment out code instead of removing it, put the fix in the easiest place, rather than the correct place, that sort of thing. Refactoring code to remove problems? Never going to happen. Making recommendations back up the chain on where problems were commonly happening? In your dreams! This is one of the reasons they are cheaper, they don't provide any free extras. Don't worry, even if you do decide to outsource, this can be good for your organisation, it will help flush out any hidden jobs that people used to "just do".
Another way they reduce costs to make a profit is through their staffing selections. The internal team that was being outsourced was staffed with senior engineers, the external team was staffed with predominantly junior engineers. The problem was that we had to keep the internal team around to both monitor the work of the external team, and to fix the really important faults. The external team simply wasn't ready to fix the nasty faults.
CMM Level 5 doesn't mean quality. They may have been CMM Level 5, but they couldn't ship a patch that worked. They would do all of the standard beginner mistakes. They shipped from dirty build trees. They failed to tag the code they shipped. They failed to document the tags, etc... All things that are already documented in my employer's existing processes.
Generally they worked differently to us. If they could ask a question to make the problem go away for a week, they would. If they thought no one was looking, they would skip steps. This is probably more a perception thing than anything else. If we had kept up the project, I feel that they would have figured out how we wanted them to work, and come around.
Finally, at the end of it all, they weren't any cheaper!
So, the work is being pulled back in. This seems to be very popular at the moment.
Don't think for a second that the failure of the project was entirely their fault, that we didn't fail here too. This could have been an extremely successful project.
There were several problems inside the company that caused the failure. First, senior management failed to communicate why the company was performing the outsourcing in the first place. At first, the reason was cost, then it was scalability, after that it was silence. Since they hadn't specified why they were outsourcing the team, they couldn't tell if it succeeded or not.
That lack of goals caused problems inside the company. Since the company is dominated by engineers, they saw it as a threat, and perceived the project as an effort by the senior management to reduce their power in the company. The relationship between support and engineering was already problematic (frequently adversarial), outsourcing just made it worse. The engineering team implemented what was effectively their own internal support team. They changed development practices that were (at the beginning) unworkable for support. Generally, they increased the costs for the support team.
People on the internal team weren't interested in seeing it succeed either. It is very easy to kill something when you are on the team. People don't realise that most projects can be killed simply by inaction. Here, we just assumed that the external team was doing their jobs properly, we didn't check. That way, when they inevitably failed in their deliveries, it was obviously their fault. At the first sign of trouble, we should have started checking all of their work, but we didn't, letting them sink or swim by their own abilities. Hardly behaviour you see when you want something to succeed.
Inevitably, political support evaporated. There was a merger with a third party, and most of the senior management were removed from their jobs. The new management team was more engineering focused than the last. This resulted in support reporting into the engineering team. The first thing the new manager did was cancel the outsourcing project.
Was outsourcing a good thing? I wasn't sure at first, but now I am. They gave easy scalability. They kept us honest - it's impossible to hand software to a third party without proper documentation, let alone code that doesn't compile. They exposed hidden costs, and made people accountable who previously weren't. As a shareholder, I had initial concerns about loss of institutional knowledge, but saw the final result as a necessary step to growing the company past it's existing cash cows.
A final thought... If all of your engineers are busy providing ongoing support for your existing products, who is writing the new ones? To create a new product, you would have to hire and create a new team with all of the risks inherent in that. If a product isn't in active development, do you really need to worry about institutional knowledge loss?
I'm looking forward to seeing what happens next.
