In this article, part of my series explaining better ROI from software development, I’d like to share my thoughts on Outsourcing.
Outsourcing has been seen for many years as a cheap alternative to local staff. While many business over the last few years have learnt that this isn’t the nirvana they believe it to be, there are still plenty out there that see this as a viable cost saving.
Generally this expected saving is misplaced.
This article was inspired by an article by Troy Hunt which can be found here. I’d definitely recommend a read of that first as this article builds on it.
Troy is a greatly respected IT security expert. He is regularly used as an authority voice by the media – having made appearances for BBC, CNN, The New York Timers & the Wall Street Journal.
In the article, Troy talks about why people look to China, India & the Philippines for outsourcing their development work. He then talks about the cultural differences he has personally encountered. And he finishes with his own opinions on why the experience doesn’t always turn out as expected.
“if you're looking at hourly rate as a metric for outsourcing success, you're doing it very, very wrong!” Troy Hunt
I have numerous experiences working with outsources in my career. Some very good …. Some less so.
I’ve worked with outsourced teams – both located locally and remote. I’ve managed some. I’ve introduced some to organisations. I’ve even worked for one during a transition phase of outsourcing an entire operation.
I’ve had the pleasure of working with some wonderful, capable individuals.
I’ve also felt the pain of dealing with a faceless organisation where the staff are treated little more than interchangeable component parts (very similar to the Anvi story in Troy’s post).
And for anyone that has read a number of my articles, it probably won’t come as great surprise that for me the individuals – the people – are the key to success much more than the organisation.
So from my experience, there are some fairly common pitfalls. Generally these are misunderstanding when and why to outsource.
Cost savings. As Troy talks about in his article – doing with the express view of cost savings can be very much as false economy. Yes there are potential savings, but unless carefully managed you are likely to find that it is actually more expensive.
Not understanding the problem. I’m a great believer in only outsourcing what you know. If you don’t understand what you are outsourcing, how can you be confident that you can explain it to the outsourcer? I’ve seen this in prior organisation where they felt that the outsourcer would solve their problem for them. This may be true if the outsourcer is an expert in the particular service – you are effectively paying for their knowledge. But if they don’t – all you’ve done is make a problematic situation much more complex (thus expensive) by adding another layer in indirection.
Outsourcing your uniqueness. If you are outsourcing the essence of what makes your organisation stand out, then effectively you’ve just given away your business. I’m not even talking about your intellectual property rights being abused – I’m talking about the reduced engagement in that uniqueness – greatly impacting flexibility and agility when required.
Not understanding the additional costs. Troy talks a bit about the additional costs coming from misunderstanding – along with the long term costs of poor code. There are also costs of increased communication between sites (not just the telco cost – but the lost efficiency of not having face-to-face). You will likely need to put additional processes and training in place.
Profit driven relationships. Any time that both parties are just focusing on the bottom line, there will be losers – generally on both sides. I’ve seen it before where an organisation “under-sold” the effort with the outsourcer trying to maximise their profit margin – it didn’t bode well for a good working relationship. I’m a firm believer in relationships over contracts – when you resort to the contract you are already in a really bad place (I’ll have to write an article on that).
I have a number of personal preferences … ones that I will take into any future outsourcing engagement.
Having any external staff (outsourcer or otherwise) as an extended part of your internal development team generates a lot of benefits.
If they are part of that extended team they get a clearer idea of what is expected, relationships are built and everything is just much more effective. It removed a fair amount of the “us” & “them” (see below).
It allows you to work in much more agile manner. If they are a part of the team, then they just work on the current work.
If you are treating them like a supplier, then you really want to make sure that the work in very clearly documented and expressed before presenting to them.
With augmentation, you are adding additional known members to your team. They pretty much are part of your consistent staff.
Like any change ... the smaller you start, the easier it is to manage.
It can be tempting to go full bore (especially if there is considerable pressure for results) – but that really increases the risks. And the potentially financial impact of getting it wrong.
Start small, monitor, review, adjust and repeat. Overtime increase the numbers (if needed), but deal with the pain points as you find them – otherwise they will simply escalate with volume.
Ok, you have your relationship in place. Ok, you have a handful of good developers integrated with your own development team and ways of working.
You are working in a nice steady manner.
Then there is a massive spike in work.
Easy you think, I’ll just ramp up the outsourced staff – they’ll be in place this time tomorrow.
Hopefully at this point your outsourcer says “no” (if they say yes, then start to worry).
You have a working team – they are productive – you have to add additional members (even temporary ones) to it carefully. No different than if you recruited a permanent member of staff. Throwing numbers at it will not help.
You need to throw the right people at it.
Don’t get me wrong, having an outsourcer can help here. They are likely to have accessibility to more available pool of developers than you do. They may be able to temporarily move relevant people into your project – but don’t expect it to be instant. They need to be brought up to speed. Hopefully this is handled by your regular outsourced staff (avoiding effort by your "staff" development team) – but it will have an impact.
Basically, plan ahead of the spike as much as possible. Give the team time to find the right person and get them in place and productive.
If however, you have an immediate need, I would probably recommend local contract market. While undoubtedly more expensive, you have the advantage of physical proximity (face-to-face) and similar cultural characteristics. Having the contractor sat with your development team will be much more cost effective and productive than just throwing remote bodies at the problem.
Ok … big one to watch out for here …
You need to consider the impact on your local development team.
You are introducing a big scary thing to them and really don’t be surprised if you are met with a huge level of negativity.
Ask me how I know …
Yep, been there, done that, got the t-shirt.
The situation;
I have a really good effective development team (really, really good team) – but the business had a lot of spike activity upcoming (and it was expected to be the pattern to continue).
I’d planned to introduce an outsourcer – 2 guys as a “permanent” augmentation and then use their wider pool for spike work. All seemed sensible and the outsourcer I had approached seemed like a really good fit for technology, culture, etc.
Before I took the idea much further than a speck of an idea, I sat the team down to discuss my proposal. Ok, I was expecting some push back …. But not to the level I received.
(To this day however I’m really happy I had the conversation. I’m really happy the guys felt safe enough to push back. I’m really happy we got it out on to the table. It really helped to address it. Like I said, really good team).
Two main concerns came through – job security and past experience.
Job security was always going to be first in their mind. As mentioned above, my job has previously been “outsourced”, so I’m acutely aware of the implications. We went through the pipeline and my rational.
The second problem was past experience. Some of them had worked with outsourcers previously and had the problems description in Troy’s article – if not worse. It was common for work to go offshore, come back 3 months later, be nothing like what was requested and of such poor quality they would just have to do the work again locally. A completely demoralising (and expensive) waste.
In this case, I went through the concerns with them in detail. Provided answers where I could over the course of the coming weeks. And when appropriate invited the outsourcer to come in to answer their remaining questions face-to-face.
In taking their concerns seriously, not rushing them, they came on board with the plan. Without that, any attempt to use the outsourcer would almost certainly have been doomed to failure.
I’ve briefly touched on Contractors above.
Depending on your requirements, a short term contractor maybe better for you if you have an immediate need.
There are other reasons why I would favour contractors over outsourcers – such as specific capabilities, not having the physical distance, etc – every situation is different.
A key lesson that I will always come back to is that Developers are not a mechanical part that can be swapped in & out without impact.
Developers are not all equal.
Thus treating them as a simple commodity is a recipe for disaster.
Beware the promise of cheap resource. All that glitters is not gold.