Last year I was involved in a project where I needed to get an application built quickly with a team of five people based in the UK. This was going to be hard, but I knew that we had a base in Malaysia with some talented guys there, one of whom had worked on-site on one of our previous jobs. As we were delivering a fixed-price project and the guys working in Malaysia would cost a lot less per day than the UK-based team, the decision to use them seemed obvious.
That’s the basic premise around outsourcing and that’s why everyone’s doing it, right?
Of course, the key phrase here is “cost a lot less per day”. If days were code, we’ll all be happy. Well, the shareholders would be happy – programmers in Western Europe and the USA would probably just be poorer.
Funnily enough, that’s not exactly how it all turned out. In retrospect, I’d say it was worth working with our Malaysian colleagues, but I picked up a few key lessons that I’d like to share with you.
We decided that the best way to do the work was for the UK team to do the main architecture and design, and to implement the business logic. We started by creating the user interface prototypes for all of the screens, a state diagram to show the navigation between the screens, and a set of business logic interfaces for the Malaysian guys to code to. Each day we’d send over to Kuala Lumpur the latest specs for the screen we wanted coding that day. The idea was that the guys there would check out the latest version of the UI prototype from source control and then fill in the application logic to connect the UI to the business logic layer.
Here’s where we started to hit the first of the problems which caused us a big drop in efficiency: Timezones.
Kuala Lumpur, the capital of Malaysia, is 7 hours ahead of the UK. That’s great for the support part of our business – coupled with a West-coast US support group we can offer 24 hour support to all of our clients globally. For programming, it’s not so good. Thing is, at the end of hour working day we might send a spec over to Malaysia for a particular screen to be coded. Ideally, while we’re in bed (or leaving a nightclub) at 2am, the guys over there get into the office, read the spec and get coding. Each screen should take about a day, so when they’re done, they check in their code ready for us to pick it up and test it when we get into the office at 9am. The end of their working day is about 10.30am our time, so we can talk on the phone about anything that cropped up. Fine and dandy, bean counters happy, UK programmers checking out the situations vacant at McDonald’s.
But what if the Malaysian guys have a question they need answering before they can start coding? Their first chance to talk to us about it is about an hour before they head home to their families. Suddenly we’ve lost a day’s coding for 2 programmers – not good. And this happens a lot more often than you’d think. Then you’ve got the bug-fix cycle – we find a bug in the UK and email the MY team to let them know. The best we can hope for is a fix the next day – and as I’m sure you’re aware, most pieces of code have a bug or two in their early days. A UK-based team would be able to start on any bugs straight away, and probably get a fix in within the hour.
So here’s the thing: even with programmers overseas who are as good as the home grown variety, you can end up half as productive when writing code, and eight times less productive when testing & debugging. That hurts. It hurts a lot. Even when your overseas developers are working for a fraction of the salary of the on-site team, suddenly the company accountant is getting a bit nervous.
If that wasn’t bad enough, that great labour-saving technology we love so much also gets a look-in. In our case, the source code control system and development server were based at the client’s site, as is common when delivering enterprise systems. The Malaysian guys had to go through a VPN from their office to our company’s office in the UK, and then through another VPN to the client’s systems. The edit/compile/deploy/test cycle was taking them about half an hour on a good day. On a bad day, they’d lose the connection halfway through deploying a large binary to test – frankly, they were working with one hand tied behind their backs.
So what have we learnt here?
First of all, outsourcing can work. We learned a lot of things the hard way, but if we were to do a similar project again we’d be much more successful. The most important thing for managers to learn is that one programmer overseas is not as productive as one programmer on-site with the client no matter how good a programmer they are.
Secondly, time zones matter enormously. If your trying to work as an agile team, then the guys doing the architecture and design should have at least an hour or two overlap at the end of their working day with the guys writing the code. If the overlap is at the beginning of the day (or even worse, there is no overlap) then every question about the spec is potentially costing you a day’s delay.
The corollary of this is that, if you want to use outsourcing to save money, you have to accept that the same amount of work will take longer to do. In my experience, most businesses would rather pay more and get things done sooner. If they’re paying you to develop a solution, then they are feeling a pain and they want that pain to go away as soon as possible.
So here’s when to use outsourcing profitably: use it for reasonably well-defined pieces of work which are well off the critical path for project success. Outsourcing can actually work quite well in large ERP implementations, since the majority of the project work over 6-12 months is to do with gathering business requirements, configuring a 20,000-table behemoth like SAP and getting people used to this new system which will make their lives sooo much better. Delivering a project like this usually involves a number relatively small, focussed developments of things like interfaces to other systems or implementing changes to how SAP does things as standard – perfect for an overseas development team. However, if someone suggests outsourcing for a major piece of development which would take an on-site team a large proportion of the project timeline to develop, it might be a good idea to show them this article.
So, that’s what you need to know – there are some occasions when you can keep the bean-counters happy and give some useful work to overseas developers, but you don’t need to be polishing your burger-flipping skills just yet.