Outsourcee

This is the other side of the story. The other side of all those jobs that disappeared from the US of A, the ones people debate over endlessly on Slashdot. I'm one of the people who do those jobs. When I read those debates on Slashdot, on CNN, on the Indian Express, I wonder if they know what it feels like to be the guy who's taken those jobs. Here's what it's like...

Name:
Location: Karnataka, India

My writing tries to do the one thing I'd like to be able to do : Express emotion in the restricted vocabulary of language. Besides that, I find I'm an outsider to the human world, constantly trying to catch and analyze thinking patterns, adding them to my psyche when I can.

Monday, October 25, 2004

Division of Labour

Over the past couple of months, I've been detailing some of the problems that come up in the outsourcing process. There are many more such issues, and I'll get to them as we go on. But I wanted to put in some thoughts on what conditions actually support outsourcing. We all know from newspaper reports and net articles how many companies are saving oodles of money by outsourcing, how the fiendishly intelligent and hardworking Indian workers are stealing US jobs. The underlying assumption now is that any white collar job can be outsourced (see http://blogs.law.harvard.edu/philg/2004/09/19#a6113 for a far out example). That is not true. There are very specific criteria that need to be met to achieve successful outsourcing.

Most of the problems I've outlined in my previous posts come up due to some wrong factor somewhere in the setup. I know it's impossible to get an completely perfect situation, but let me try explains the one most important factor (IMHO) that goes towards creating that situation : Neat demarcations of work. Organized division of tasks into in-housed and outsourced sections. If you can just do this one thing properly, your outsourcing project has a chance of going through.

Let me explain with a recent example from my company. The Development team of a project in the US has a pool of about 15 people. There are about 4 codeline branches, and the allocation of these people into these branches is fluid. The managers for each codeline are mostly fixed. When a customer requires a set of features or some bug fixes, URGENT, in a new patch for its installation, this info goes to the manager for that codeline. He looks to see who from the pool is free. There may be two or three 'regulars' for this codeline, and if they can handle this demand, all is fine. Else, he gets a few people from other branches allocated temporarily to his branch, and they all chalk out warplans, and roll out the new features in a couple of weeks time. During this period, inputs from the customer keep coming in, and temporary solutions which they propose to the customer keep getting rejected or modified, so each of the team could come to work the next morning to find himself working on something totally different - or even that he's now on another, even more urgent, codeline. Entire team is pumped up, totally into the code, and the manager is right there with them, co-ordinating everything. [Sadly, this is a pretty common situation in product companies]

Now these guys think, 24-hour productivity would be great, we could handle client requests even faster. Let's outsource some of our work. So, they hire 3 or 4 guys from a consultancy company in India, bring them to their office for a few weeks until they understand the bare basics of the code, then send them back. The outsourcers think, We'll start these guys working on small bugs initially, then move them onto bigger and bigger issues, until they're as good as we are. All set, right?

Wrong. Note that we're missing the most important piece here - the neat distribution of work. That means, even though our Indian team member has been given his work to do, the job is still controlled by the manager on the US side to an alarming extent. What happens is that, the manager, while going home, goes over the set of tasks he has, selects a few of them, and mails the Indian guys to do overnight.

The next morning he comes to work and finds his clients now want the team to do task Y instead of X, as scheduled yesterday. Hurriedly he IMs the Indian guys to say, "Stop the work you were doing yesterday, start work on this Y now." The Indians give him the status on the tasks they've been working on all day (Indian Time), which he duly notes. They are to go back to these tasks when things quieten down.

Except things never do quieten down in bleeding-edge product companies, do they? Over the next weeks and months, the co-ordination between the client's changing demands and the tasks allotted to the outsourcee team takes up more and more of the managers time. He's spending like half his day in clearing the outsourcee people's doubts and making sure they're up to date with the client's requirements - since they cant deal with the client themselves. If there's a manager devoted to the outsourcees, then the time is taken up in co-ordination between this manager and the other managers.

In short, the co-ordination and teamwork that is possible when an entire team sits in one office, in one time zone, is impossible if you have some people sitting at the other end of the world. Time and again, this simple factor has frustrated people on both sides of the globe, and led to the end of otherwise good outsourcing efforts.

The only solution here is to reduce the amount of co-ordination itself. And this can be achieved by proper division of work. Ideally, the work should be split such that the people in the outsourcee company do not depend on the outsourcer for any input - they only need report their status periodically, and present the outsourcer with the finished program when done. This is where software processes come into play - if properly used. They help define the work exactly, so that both sides can read the documentation and know exactly how much work is being passed on, how much effort is going to be needed to do it, how many people, etc. etc. This should be the only time when the manager frantically calls up the outsourcee people - to clear up doubts about the work assignment. Thereafter, the manager just keeps reading the status reports to make sure things are going right, and co-ordinates scheduling changes if the original schedule wasn't accurate enough. So the manager, at times, does spend hours of his time talking to the outsourcees. But that's when things go wrong, not in the normal course of things.

In precis form : The less the normal day to day co-ordination needed between outsourcer and outsourcee, the more chances are that the project will succeed.

An example: The famous Call Center jobs being transferred to India. Think about this a bit : How often does your normal call center operator get his routine changed through intervention of the American management folks? Hardly, hardly ever. The call center operation is almost self contained, all that goes from there to the outsourcer is a weekly report giving statistics. The American manager only works at a macro level, chalking out overall strategies.

Now go back to the URL above and see the idea the author proposes : Outsourcing University administration. Can this task be neatly demarcated so as to require minimal interaction with clients? Hardly. The task consists entirely of interaction with clients and other wings of administration. The idea is doomed even before it begins.

0 Comments:

Post a Comment

<< Home