Managing offshore work.

Published On: Dec 21, 2011

"Many hands make light work." - Origin Unknown 

  "This statement is false" - Liars Paradox 

There is an excellent lesson to be learned in working with others, and even greater lesson when working with people of a different culture. As you should be learning to spot business speak, you can tell that this ended horribly.  Otherwise there wouldn't be a lesson involved. So I landed at my clients office for the first time and I was settling down into my new desk, the project manager came in and talked with me about the project. The project was simple for the most part there were a couple of office documents that would need to be automated.  They needed to be tied up to a database so that the information could be reused across the departments.  To me this sounded like it shouldn't be a problem.  I had done things like this before so there shouldn't be anything difficult about it.  I was also informed that we had a very short deadline to work against but that this would be alleviated by adding two resources from off shore. Enter Alice and Bob (not their real names). So as we started, the management figured out that source control was too expensive so there was no budget for that, and that we were to transfer code from the US to offshore by email (Mistake #1, cost is never an excuse for not using source control).  In the beginning this was not a problem I would make my code changes during the day then would ship the offshore team our project by email, then they would return their updates from over night and I would review and integrate their changes.  This worked for about the first week then there were a couple of days where emails had gotten kicked back.  The resulting of this was that I had to spend a full day reviewing one set of changes and review the second set another day. Bobs code for the most part looked good but childish, like someone who had never really programed in C# before. Alice's code often contained compiler errors and required reworking to even be functional, a topic that we talked about on several occasions.  However since they were on lend from another department I couldn't get them removed and I had to work through their work (Mistake #2, if someone is creating a hindrance and your direct management won't solve the problem. Find some one who will). It finally go to the point where I was spending 8 hours working with their code and another 8 hours working on mine.  Then came the point where the real problem crept in. Knowing that I had to have certain elements of the code that needed to function and work by a certain date I started cutting back the time that I was spending reviewing the code, switching it from working 4 hours on their code and 12 on the code that I was responsible for. (Mistake #3, don't leave children alone in the garden).  Because of this code that contained inherent bugs started slipping into the code and there were hacks to fix the hacks in the hopes that this would eventually get to a point where the code was functional. It never got there,  in the end I had a client that was upset with me.  A team that was upset with me, and I loathed being in that situation. The project completed from my side about a month and a half after it was planned to, and it counts as one of the black marks in an otherwise good year.  I'm offering this up as a cautionary tale about the lessons I learned in the hopes that others won't have to experience them.

Comments