The thing with outsourcing (or offshoring) is that on hindsight, it’s obvious that your business should’ve done it a long time ago. But when it was first introduced, no one really wanted to give it a shot. Why? Because it’s not safe. It’s not tested (by other people). It’s not well understood.
And then when it becomes well-established, you give it a go. Because if something goes wrong, it can’t be because of the outsourcing, it’s because the person/company you outsourced to didn’t deliver, or the person in charge of the outsourcing didn’t do a good job. Basically, it’s not your fault.
In the initial phase, you can blame the concept for not working. When it’s established, you can blame whoever’s implementing the concept for the concept not working.
The meeting where 20 people stared at me
I remember it was a dreary morning. I received an email “inviting” me to attend a meeting. My supervisor was away (I can’t remember if she’s on leave or simply at another meeting or otherwise off-site), so I was to attend the meeting on behalf of the team (which was a joke, since the team only consisted of my supervisor and me). Little did I know the meeting in that afternoon would soon turn drearier.
After lunch, I went back to my desk to finish up some coding. And was surprised that my associate director and my senior manager came down to my workplace (they work at headquarters). They were attending the meeting too.
So what’s the meeting about? To discuss how to move forward on a fairly big operation to be handled by the offshore team in China. I’m involved because one of those legacy programs I maintain was in that big operation. By proxy, my associate director and senior manager were involved (though not directly, since my department wasn’t really involved in that operation). Have I mentioned my supervisor wasn’t around?
Near the appointed time, I wrapped up my work, took a pen and notepad, and went to the meeting room. I arrived in the room, with a couple of people already there, and chose a seat that’s as inconspicuous as possible. Don’t choose the corner seats or seats right at the back. They’re at the extremes, and people notice extremes. I chose a seat that’s near the end of the meeting room table, but not at the end. Close enough to the action that people acknowledge you, but invisible enough that people don’t notice you unnecessarily.
Presently, the attendees arrived. My associate director and senior manager (henceforth referred to ADSM. Ok, that sounds weird… never mind) chose seats at the back. All in all, there were perhaps close to 20 people in that meeting.
The meeting proceeded wonderfully, with me casting a powerful magic veil of moderate genuine interest and blending successfully into the background. And then it happened.
[conversation made up, but the essence is there]
“So what is slowing down the project?”
“Oh, we’re waiting on [my legacy program] for the progress.”
([my legacy program] henceforth referred to as MLP)
“Who’s in charge of MLP?”
“Uh, I am.”
20 pairs of eyes turned to look at me.
“Where’s [my supervisor]?”
“She’s on leave.”
(obviously, my boyishly good looks fooled no one that I’m actually in charge of anything)
My associate director and senior manager didn’t speak up. Good move. I don’t blame them. That was a big project, and the uppers really wanted that to move along and succeed.
“Why is MLP so slow? The people at Cheng Du are complaining that it’s so slow they can’t do their work.”
“And they have lots of problems logging into MLP.”
I can’t remember what answer I gave, but it seemed to mollify the person. I’ll explain the technical difficulties in a bit. No one else came to my defense. Not the users of MLP (who had a representative there, but she also found MLP slow at times. *sigh*), not superiors of the users of MLP, and not my associate director and senior manager. The meeting continued, and apparently, everything was going smoothly. Other than MLP being the bottleneck. Schedules were displayed, training sessions to be coordinated, business reference materials to be created and sent to China. Etcetera, etcetera, etcetera.
The meeting concluded, and I breathed a sigh of relief. That was a good 3 hours (or so) of productive coding gone, with a dash of mild insult, condescension and blame sprinkled on top.
The technical difficulties
So let me talk a little about the technical difficulties, without giving away confidential information. First of all, MLP was a Windows program. The platform wasn’t really the problem. It’s that MLP wasn’t designed to be scalable. It was originally designed to be used only by a small number of people. Like maybe 2 or 3. Database connections became a battle of who logged in first. Seriously, I knew of users who logged in first thing in the morning, just in case they had to do something in the afternoon. I know, because of sp_who.
Which is also the second problem. The database administrators of MLP (I’m not pointing fingers, ok?) decided they couldn’t afford to buy the license to increase the capacity of the database. Which I agree. The cash cow of database companies? Not the database software. It’s the support, licensing and training. Just so you know.
Third problem was that it’s a Windows program. Ok, maybe the platform is a problem… MLP was an archaic program, written on an IDE that I’m not familiar with (and sometimes hairpullingly difficult to use), in a proprietary language, connecting to a database that’s tightly coupled with that proprietary language. Installing the program required me to fiddle with the Windows registry (never a good thing), and half a dozen steps (that I painstakingly came up with) that if done wrongly, meant the computer would explode. Or at least, that’s what it felt like to me.
Fourth problem (oh yes, there’s a fourth) was about restrictions. You see, MLP allowed the user to perform any action on a particular screen, once the person was authenticated. The big offshoring task required MLP to restrict the kinds of information available, depending on whether the user was based here in Singapore, or there in Cheng Du. Well, roughly, but the nuance is irrelevant for our purposes.
As an example, MLP allowed the user to enter information on customers. Information on confidential customers (such as government agencies or the Singapore military) were only accessible by Singapore users. That information was strictly off limits to Cheng Du users. This meant I had to go through every single SELECT query, every UPDATE/DELETE statement to make sure that only the correct user accessed the correct information. Those SQL statements were embedded everywhere throughout MLP. And at that point in time, I was the only one who knew how to use the IDE associated with MLP. I doubt anyone in the entire company knew how to use the IDE. People were having way more fun working with Microsoft’s SQL Server, or Oracle, or IBM’s DB2, together with ASP.NET or some modern technology.
Fifth problem (ohhohohoho yes, there’s a fifth) was about firewalls. I’m not talking about the Great China Firewall, but it might have had something to do with it. I’m talking about internal firewalls. The database server was located in Singapore, but the Cheng Du staff had to access it. Not through the Internet, but through internal firewalls. The Singapore side had to open up, the Cheng Du side had to open up, they had to open the right ports, they had to grant access (I learnt that I cost my department $375 in internal charges just to open up network ports and grant access).
All in all, I feel that particular offshore project was a big waste of my time. On the whole, the project might have made financial sense. But the cost of making it happen trickled down to me. I hope it’s worth it to the company.
Oh right, moral of the story. People tend to blame anyone except themselves. If someone blames you wrongly about something, be graceful about it. Don’t automatically defend yourself on the principle that it’s wrong. Choose your battles. I’m not saying it’s right. I’m saying it’s not easy.