Is IT Offshoring Worthwhile?
Posted by Kevin Brady on Sun 10th December 2006 at 11:12 AM, Filed in Outsourcing
So what do we mean by the term Offshoring for the Newbie Project Manager?
“It is the relocation of business processes to a lower cost location, usually overseas”.
In theory this looks an almost “too good to be true” opportunity to increase profits through reduced production costs via the exploitation of cheap foreign labour. The expectation with respect to IT software development is a promise of cost reductions in the region of 30% to 40%. The management consultants convince clients that all you needed to do in order to encapsulate this cost saving into your balance sheet, is to carry out, with their help, an IT staff change-over similar to changing out an old car engine and replacing it with a new one made in India or China. Make this happen and “he presto you’re in the money”.
In addition, the road to Elderado is promised not to be at the expense of quality as the new people employed would all be similarly qualified to the ones targeted for redundancy.
“Just seems to get better and better”
“No brainier” you might think.
Well, I visited a client (software house) last week, to discuss the problems they were experiencing with their project management when the subject of their offshoring arrangements (Indian - Java J2EE coding capacity) was brought up over lunch, and how they have turning out to be more trouble than they were worth.
Originally they had hoped to achieve all the expected benefits of offshoring mentioned above, along with the use of this new found “on tap” development capability as a means of flexibly handling peak-load related project works. The latter expected benefit was of particular interest to my client because, up to this point in time, they had not been able to quote effectively for larger project opportunities. Larger projects typically involve considerable business risks such as taking on large numbers of extra staff in short timescales, accompanied by significant and expensive facility upgrades.
However, once my client had signed up with their new Indian offshore vendor they had found to their cost /alarm that they had been largely chasing a mirage. There issues ran as follows:-
1. Their Culture
The biggest problems they faced seemed to be cultural. Very often countries with highly skilled workforces, which are under utilised, are in this situation for a good reason, and foreign investors, looking to exploit this reservoir of cheap labour, need to be very very careful. Quite often, the economic and cultural environment of such countries have acted as barriers to business and foreign investment for decades, and as such, offshoring your IT development (coding resource) can be like injecting Polonium into the heart of your business. The only defence against this is to enter into such arrangements with your eyes wide open by always making sure you carry out proper due-diligence (please click for FREE check list).
My clients referred to their relationship with their Indian offshore vendors as akin to having a “milestone around their necks”. I asked for specific details of the cultural issues, which were dragging down their business:-
• “Never Say No Culture”. In India it is unheard of for staff to stick their noses out and say something might be wrong, or technically unfeasible, for fear of upsetting the client and their bosses. This results in an inability to run effective risk and issue management resulted in mission critical software bugs and increases in costs related to the rework of unfeasible system designs.
• “Dated work Practice”. The Capability Maturity Model (CMM) can be an important measure of a company’s ability to deliver quality systems. Many consultants (including myself) consider that for an offshore vendor to deliver effectively, it is important for them to have a standardized, and repeatable, development /management model, which must be in the region of CMM Level 5. My clients felt that their Indian offshore vendor was only worthy of a CMM Level 1. This gap (between level 1 and 5) was compensated for by their vendor engaging additional resource, thus killing the original offshore cost advantage they were seeking in the first place.
However, I have to credit my clients with trying to make the best of a bad situation, by trying to help this huge Indian offshore resource provider with advice on what CMM level 5 is all about, and how it could greatly benefit their business. The advice fell on deaf ears because, in the vendors view, 70% of their local competitors were operating at CMM Level 1 and doing just fine in growing their business. Therefore they couldn’t see the need for increases in management overhead (also lack of local management resource) and lower revenue through reduced staff numbers when there were so many potential clients suffering from “Gold Fever”.
The symptoms of this “fever” seemed to take the form of client engagements with local vendors on the basis of little, if any, due diligence assessment, because the potential cost savings as mentioned earlier were supposed to be a “no brainer” i.e “The Gold IS up der in dem der hills just for the taking”. This “Gold Fever” seems to have been further reinforced by the belief that the whole Global IT Industry is moving towards the offshoring model, and with so many people in favour of it, surely they can’t all be wrong (Klondike Gold Rush).
Does all this mean that many UK and US companies who engage in offshore systems development are “Suckers” and “Lemmings” ?
2. Overheated labour markets
My client also stated that the local labour market, which looked so ripe for exploitation, had been exploited by the time they got there (Just as in the Klondike Gold Rush).
They believed that the situation was so serious that, following project audits, they reckoned that their vendor was experiencing a 30% staff turnover rate as staff shuttled between employers looking for the best salaries and bonus rates. My client felt this had a huge impact on the quality of their work:-
• The Indian vendor, faced with such huge turnover rates, was plugging the gaps with more and more rookie programmers who only had the ability to “code for England” and not much else. More and more they were seeing the changeover of unintelligible code out.
• Furthermore, much of the in-depth knowledge acquired in the early stages of a system build was going out of the door before project completion impacting deadlines and the overall quality of the build.
3. Stealing of Intellectual Property
My clients were also engaged in development of some cutting edge, supply-chain software, which they felt couldn’t be trusted with their offshore vendor. They were concerned that the local legal systems were corrupt, or inefficient, and as such intellectual property rights protection clauses in service contracts were worthless and no deterrent to these vendors selling on their domain knowledge to other third parties.
4. Massive increase in management overhead costs
With vendor resistance to the adoption of modern management /work practices within their business, my client was forced to engage in frequent face to face meetings, audits, and lots of out-of-hours conference calls, putting a heavy strain on their management team. Running project plans and risk /issue management via remote control, really hovered up lots of key management capacity.
5. Massive increase in QA activities.
With so much poor code being generated by their offshore vendor, my clients had to make sure that code was shipped electronically to my clients own in-house analysts and tech architects for review and unit testing. The time and effort involved in making this activity work (taking into account unhelpful time zone issues) became an unexpected cost to the business in respect of in-house development resource being tied up on never ending code review activities.
In conclusion, the offshore software development model turned out for my clients to be a costly mistake, with the internal running costs of maintaining the relationship (additional Management & QA work) combined with the local inefficiencies of the vendor eating up all their expected cost savings.
In fact, my client felt that the relationship was making software development more expensive for a poorer quality outcome than compared to a do-it-yourself scenario.
This entry has been viewed 6776 times.
READER COMMENTS:
)
All contents copyright © 2006, Kingsmead Internet Investments. All rights reserved.
Hi,
nice post. You point out very well the problems arisen when you outsource to India. What you miss to mention, is that there are other countries where you can outsource that might produce better results.
Countries like Argentina (yes, I’m advertising ) have a closer timezone to US (EDT +1), much similar culture, excellent IT resources (many of my classmates are in US or Europe now) and a very convinient change rate.
One thing I disagree with you in, is in the statement that companies should have CMM level 5 capacity. Level 3 assures you enough control over the process, and bears a lot less documentation. Anyway, I think TDD and agile methodologies can achieve much better results than writting as much docs as the CMM requires.
Well, JM2C.
Regards,
Pablo.
Posted by Pablo on Mon 11th December 2006 at 12:34 PM | #