[an error occurred while processing this directive]
Back to newsletter 092 contents | All Javva's articles
A couple of month's back I listed some chats from our outsourcers that showed a level of competence I would only have previously associated with demented sparrows running a manure spreading service. Following that, I decided to do some research. Well, I say research, but being lazy I don't actually do any research myself - instead I use other people's research. More specifically, I asked a few questions of the person in charge of outsourcing at a large organisation I know. Wow, I almost sound like a journalist!
Mr. McBig has been in charge of the outsourcing strategy and implementation at a fortune 500 company for several years. He has directly analysed dozens of outsourcing projects of many sizes, small and large, both successful and unsuccessful, and has learned a number of lessons, which I extracted from him under skillful interrogation (some beers).
And so, I am now able to impart this invaluable knowledge to you, my reader. Are you bating your breath?
There are some things that are ideal to outsource. Cost savings are almost immediate, and continue throughout the outsourcing - probably indefinitely or at least until we run out of much cheaper outsourcers. When we started our discussion, Mr. McBig didn't really have any shorthand way to describe exactly which projects and services are ideal for outsourcing. He just knew from experience. But my brilliance - and possibly the beer - helped him come to an epiphany on this. If you could write a 'bot to do the job, given enough time (say up to a year without distractions), but you don't have the time or budget or resources to do it, so you have to keep on doing whatever it is by hand, then it's probably ideal for outsourcing. Password resetting comes to mind. As does disk space management, and lots of admin tasks. Small development projects that are really just form creation, and interfacing to other systems. Things that are all essential to get done, but really take very little imagination, just time. It's the "taking out the garbage" of the I.T. world. Not particularly pleasant, not at all difficult, but has got to get done and someone's got to do it.
Overall, we settled on the 'bot analogy. If a sophisticated 'bot could do it, but you can't afford to write that 'bot - then outsource it.
BTW, this has an interesting consequence. It suggests two things. Firstly, there is a huge potential market in software to do what a lot of these outsourcers are doing. After all, software doing it is still going to be cheaper than some guy in Timbuktu even though he's being paid a tenth of what you earn. And secondly, it suggests that all these "cheap outsource" organisations have a limited lifetime, basically until that market starts being supplied. Could be decades though.
The successfully outsourced projects were micromanaged. Daily meetings with the distant staff were needed, the managers needed to be aware of what everyone was doing at all times, needed to be aware of and set clearly defined milestones with progress towards the milestones clearly monitored, the managers had to be very interactive. You couldn't give the outsource staff free reign to "just get on with it", they needed clearly defined specs, targets and guidance, and constant checking. It's not that they were not up to the job, or slacking or anything, it's just that without this level of oversight the team could very quickly get diverted into wrong alleyways, and they didn't have the luxury of just "popping over" to your desk to set things straight, the way a normal project would go. So basically, all this was needed to cover the changed communication circumstances.
And there was one other thing that was important to know. The outsourcing team were almost never proactive. Everything was reactive, work done in response to specifically directed tasks. Where an experienced employee programmer might note that some type of design or implementation could cause issues further down the road, and flag that for review, probably with a few suggestions, the outsourcers almost never provided this kind of service level feedback.
If you want quality software, you have to pay for it. If you are using cheaper sourcing, the management of the project seems to cost so much more to get full quality, that you may as well have just hired quality in the first place. Telling the outsourcing organisation that "this project needs top quality people on it" just puts the price up without seeming to make much difference. It's not that they are trying to cheat you. It's just that the quality people at outsourcing organisations are in such demand that they just can't afford to keep them on your project to make enough of a difference.
So basically, if you have an important project which needs to be achieved with top quality, just don't outsource it - you won't save any money if you do, but you will generate a huge headache if you do. Combined with Rule 2, it's clear that complex projects that are at all important are ones that you shouldn't outsource at all.
So there we have it. Outsourcing wisdom from Mr. McBig, distilled down to the three rules that may make your life easier. Or may inspire you to improve our industry.
BCNU - Javva The Hutt.
Back to newsletter 092 contents