Sunday, March 05, 2006

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?

2 comments:

To me, the single most important line in the article was this:"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".

As you point out, if there was no business plan to succeed (at least not an open agenda at any rate) then there was no way of measuring success. Equally there seemed to be no attempt to look at whether the outsourcing was successful once it was in place - it was simply axed as a knee-jerk reaction. Or appeared to be.

If it is the case that a sound business plan existed in either case then the problem becomes one of communication. Why didn't staff know what the drivers were? No wonder they felt threatened. Unless of course that *was* the plan....

If there was no business plan then maybe the company lost out, maybe it didn't. We'll never know without a yardstick to measure the venture by. If we didn't lose out then we were lucky. Fortune may well favour the brave, but then I didn't see too many angels treading our path either.

Of course it would be naive to think that all management action is done for the best benefit of the business. But it should at least appear to be.