Outsourcing Impact on Technology Choice
I find LinkedIn to be a good idea generator for blog topics, for example a question from Vinay Joshi “.Net OR Java what technology projects you outsource — Does technology matter for making decision to whether outsource or not? …” deserves substantial discussion, beyond my brief answer on the site; especially considering that the rest of answers are more about religious war of .Net vs. Java rather than about the question itself.
Of course the answer depends on the context, if you are a technology company that already has the technology selected or a vendor that has a large team with specific expertise in place the discussion has little relevance. For those about to outsource it could be quite important decision though.
If you are planning on outsourcing but have not selected the technology yet, here are a few tips to consider:
- Flexibility offered by technology is not your friend. The more discipline the technology offers / requires the easier it is to control it, the less are the chances on-shore and off-shore teams drift apart. In particular using Java vs. .NET discussion – Java offers great flexibility and far less commonalities in solving even basic development task. There is always 10,000 ways to achieve the same objectives. It offers multiple schools of thought and competing technologies. .NET offers more disciplined approach, while it offers some flexibility it’s far less the focus or the modus operandi, typically in .NET there is “the right” way of dealing with majority of tasks.
- Emerging technologies are not made for outsourcing. That seems like a no-brainer, yet I’ve seen many companies moving projects using cutting edge technologies offshore, typically with painful consequences. So just in case, there are many reasons not to do so: lack of experienced resources, blind spots in understanding the technology on the both sides of the ocean, insufficient supporting community and documentation, undeveloped best practices, etc. Each of these issues by itself can destroy the engagement, when the issues combined the failure is guaranteed. Both Java and .NET by themselves are established technologies, however there is always something new being pitched by the respective camp.
- Close doors to Open Source. Well, that might be too strong of a statement. As a matter of fact I did quite well outsourcing development using Open Source technologies and products and so many people I know. Caveat emptor! If you go for Open Source make sure that you do not stray off the beaten track and stick to very stable and mature products with strong development community. Too frequent release cycle, fluctuating quality of products, unstable supporting community can add insult to injury when combined with inevitable issues of outsourcing.
- Don’t let the tail wag the dog. Some advanced technologies come with very costly or complex development tools. Some technologies require you to invest heavily in workstations or development environment. Some technologies require extremely high investment in training. And so on. Unless you have extremely compelling reason to do so, do not consider such technologies. Investing into a partner or their environment is not what you want to do especially in the early stages of the partnership. What if the partner already has it all in place? Well, do you want to be locked into using a specific partner? I don’t think so…
- You can only find free cheese in a mouse trap. In development today there are a plenty of “very simple” technologies. Those technologies could be quickly learned, and superficial or even spurious expertise sold to a naïve buyer. That usually attracts gazillions of providers and inevitably drives the price down. Have you heard about PHP freelancers for $4 an hour? Just go to elance.com or guru.com – you will find a plenty. The chances are you will get what you paid for. The main point here is while the technology at question could be extremely solid it doesn’t mean that any code monkey can operate it. Finding good providers in such technologies could be a challenging task due to the high pollution of the field. Unfortunately PHP today falls into that category, and I am certain tomorrow that will be the case with RoR.
Pros and Cons of Outsourcing to India
India offers the most developed, experienced and sophisticated outsourcing community. No surprise – embedded advantage of ESL, huge supply of IT talent, and low standards of living made it a top destination for IT outsourcing long time ago. Y2K and management talent solidified the success creating multi-billion dollar giants and changing ethnic landscape of many cities in the USA. As I mentioned in Offshore Vendor Selection: Choosing the Destination “if your risk tolerance is low and/or your organization is new to outsourcing go to India, you can not get fired for hiring IBM. Go to India if you have to choose on a spot, or have little knowledge of outsourcing, or have to deal with large scope ERP implementation, or … as a matter of fact if you have to ask this question chances are you should consider India as your top destination.” Now let me put a few bullets here supporting my statement:
Infrastructure. Unless your partner is tiny and located in a 3rd tier city you won’t have any problems with infrastructure. Well, you may have to deal with some irregularities in connectivity due to some natural disasters, it gets quite rainy during monsoon season out there, but I tell you that: we use AT&T as our internet provider in our San Francisco office and once in a while they drop connectivity despite blue sky and sun outside. With a huge supply of IT services in India you can find infrastructure that would cater to most ridiculous demands.
Operating Environment. Flying to India is far from fun especially from the west coast, in particular if your company doesn’t cover first class travel. 30 hours in transit plus you arrive there in the middle of the night. Unless you time your trip well the nature would great you with heat and humidity. Flying back could be so much better if you did not need to deal with airport lines and crowds. The good part, that’s pretty much the extent of the adversities. Chances are you will be staying in a good hotel, will have a personal driver, eat in good restaurants, and even corruption is wide spread in India at all levels you most like won’t need to deal with it.
Skills Availability. That’s is one of the strongest Pros of the country. No matter what skill you are looking for there will be at least 10,000 people who have it. Well, more seriously, the supply of IT talent in India is outstanding, some areas more than others of course. Mainstream technologies of today and yesterday – Java, .NET, C/C++, ERP, Cobol, etc. – have substantial oversupply. You also can find a lot of talent even on a cutting edge of the technology. The quality of the talent follows the bell curve and nowadays the median has gone up comparing to late 90th.
English Skills. Well, that’s a hidden gem isn’t it? Of course with English being widely popular in India the main issue you would need to deal with would be an accent. Maybe some idiomatic expressions, some speech forms, etc. but generally it is not an ever a showstopper and forms a huge Pro of the country.
Cultural Compatibility. While there are a plenty of cultural differences between India and USA I would put the Cultural Compatibility in a category of Pros, here are a few reasons:
- The cultural differences on business side were not so dramatic to begin with considering history of British influence on legal and business system of India.
- Resources from India have been in this country in large numbers and for a long time. People in the USA learned the differences, behavioral patterns, and idiosyncrasies to a pretty good degree.
- Many Indian vendors invest a great deal into cross-cultural training as well as in accent training. As a result the gap between cultures is narrowing considerably.
There are of course cultural differences that are deeply embedded in people’s psyche, here are a few most notable:
- “Never say No” or “Yes to Death” – while working with Indian resources you always need to keep in mind that they might have a very difficult time say “No” in any shape or form. “Can you do that? – Yes, we will do Nick.”, “Do you have access? – Yes we do Nick”. That doesn’t mean that they can cater to any need or demand, they just can’t say NO.
- No bad news is a no-news. While the times of chopping off bad news barer heads are over, the habit is still there. So if you do not hear about bad news, it doesn’t at all mean that everything is going well, it just simply means that you do not hear / do not know what is going on.
- Motivational hierarchy. Of course Maslow’s Pyramid rules. But there is a plenty of subtle differences in how its upper levels translate for a specific culture. Not bad / not good – just different. For example, personal success in India outsourcing is often measure in number of people the person supervises. “I have 100 people under me…” That pushes good developers away from the technical track towards managerial with inevitable profound negative impact on technical abilities of the organization.
Rates. India rates fall neither into Pro nor into Con category. They are benchmark against which other rates are compared. And I guess that makes for a nice segue into Cons discussion:
Resource Turnover. Turnover is very high, it is high to a degree that it almost outweighs all pros of the region. See my earlier post Myth for more thoughts on the subject.
Resource Quality / Technical Capability. IT Outsourcing proved to be a rather lucrative business for many social groups in India – entrepreneurs, engineers, education providers, etc. Millions of people moved into the field in the Golden Rush of the century. As a result average quality of resources started going down to a degree that even time-proven trademarks of quality do not work anymore. Not long time ago I was stunned when I had to fire a consultant for incompetence; the stunning part came from the fact that he had a master degree from IIT.
One more Con related to the Golden Rush is worth mentioning: huge number of companies with a large number of low quality fly-by-night vendors makes it extremely difficult to find a right provider. It’s very much like looking for gold – you have to go through the tons of dirt to find the right substance. However, you are looking for gold, and one thing I am certain of is that you can find that gold in India.
Pros and Cons of Outsourcing QA
I saw a question on LinkedIn early this morning on a topic I was planning to cover “Pros and Cons of QA Outsourcing” – I jumped to the answer and typed up an answer while on BART, ironically it turned out to be too big for LinkedIn and so I decided to put it here. The answer is not complete and I am planning to come back to it some time. In meanwhile here are my thoughts:
1) Outsourcing QA is often a meaningful thing to do, an easy way to start and a potentially very dangerous trap. In particular companies that shed internal QA resources and move their QA operation abroad typically pay the price in knowledge loss and ultimately in degradation of the product quality. I have seen it on numerous occasions. QA engineers in well run teams often have better product knowledge than any other part of the organization, and offshoring that knowledge falls in a category of “outsourcing crown jewels”.
2) Companies in US often consider outsourcing QA for all wrong reasons, like for example “Cost”. Cost advantage is just a myth, see my earlier post for details Outsourcing Myths: cost advantage. And going offshore for wrong reasons is guaranteed to give your wrong results.
3) QA as a subset of IT field offers a few interesting dynamics
a. It’s one of the most important areas of SDLC which typically is given the least attention.
b. The average quality of talent pool is dreadful, independently of geography. There are many reasons for that, for example here in SF Bay Area one of the main reasons is huge pollution of the pool by fraud and mediocrity – I met 100s of people who fake their QA background or think that a couple months of homegrown education makes them top notch professionals.
c. A perception of QA skills/occupation as a substandard one. It takes as much IQ to become a solid QA engineer as a Java developer, maybe more, but what can you do about perception? As one the best QA guys I’ve eve met put it talking about his resume “going to QA is like going to morgue – there is no way back”. And why don’t developers enjoy testing? Because it’s hard, it takes serious effort to put together a decent test harness, to organize your code, etc. Yet look at the average salaries, at layoff patterns, offshore dynamics – the trends are obvious.
4) Good QA engineers, automation specialists, functional testers, etc. like any other good resources are not easy to find, considering the quality of the pool, much harder. So it’s no surprise that that many organizations after interviewing a couple dozens of key-punchers who can’t tell the difference between priority and severity and ask for $90K move to offshore. The problem with such decision is obvious – it is as difficult to find good testers in Bangalore, Kiev or Beijing as it is in Boston. Of course a large supply of IT talent in countries like India and China makes it so much easier, yet the vendors in these countries have a plenty of own issues and challenges. Outsourcing the problem will not eliminate the problem, it only passes it to a different organization which is hopefully is better equipped to deal with it… But is it? Is your perspective vendor better equipped to do your job? How do you know it? By their brochures? Having interviewed hundreds of engineers in Asia, Eastern Europe, and Latin America I can tell you with certainty – far not ever vendor is equipped to do so, many of them are squarely in a business of selling mediocrity in bulk, and the quality of the resources is far less impressive comparing to what you can extrapolate based on what you see locally.
5) Having said all that I have to state that I still outsource a lot of my development and QA activities and get great results from my partners. There are a few ingredients to that success story, here are the most important:
a. Rigorous vendor selection process with the focus on “the match” between my organization and vendors’. Search for the match on multiple dimensions.
b. Resource augmentation and joined teams rather than complete outsourcing.
c. Abundant communications in all forms with fair portion of face-to-face meetings and on-site / offshore swaps
d. Control and ongoing preventive maintenance in all aspects of the engagement.
e. Adjusting SDLC to accommodate for idiosyncrasies introduced by offshore.
f. A “disposal outsourcing” model that I worked out with my one my partners – augmentsoft panned out quite well in QA arena.
g. Working with nearshore partners was much easier in many aspects especially when running agile projects.
Outsourcing Myths: Turnover Ratio
The impact of turnover on the total cost of outsourcing is difficult to overstate. Of course you know that and put a turnover question as one of the most important ones in the beginning of your RFP. You look at the proposal that just came back from your vendor and see 18% as the response, “whew, I think we found our guys!”… Welcome to the murky world of turnover ratios. The sad part is that this answer may mean very little; being the most infamous curse of offshore engagements the turnover ratio comes with a few extra traps.
The most frequently overlooked issue strangely enough is the meaning of the “turnover ratio”. When your prospect vendor tells you that their turnover ratio is lower than the country’s average (high changes that’s exactly what you are going to hear) what does the vendor mean?
On one of my recent engagements with a reputable company in Noida, India the staff on the project changed at an amazing rate – while working with 10 member team for about 1 year we saw over 20 people, and only one person stayed on the project from the beginning to the end. No matter what formula I tried apply to that situation it did not seem to align with 18% stated in vendors proposal. And yet every account review my vendor pushed the idea that the turnover ratio was not out of bounds. Ah? ‘Well, Nick:
- We moved Rajiv and Venkat off the project because they were not performing job well enough;
- Ramki’s mother got sick and he had to quit to do the right thing;
- Shushma got married and moved to Hyderabad…
And so on and on and on…
As it turned out my valued partner had a completely different view of the turnover ratio. My guess is that they calculated the ratio based only on the number people who’d left the company for competitors.
Another trap worth mentioning is an internal transfers. What difference the company’s average turnover rate makes if your project turnover exceeds it by two or three times? I’ve seen that numerous times and in a large degree it’s unavoidable. The vendor will move people around to increase their utilization, to appease the loudest customer, and to keep employees motivated.
And one more trap to mention is key resource turnover. If your team has an average turnover of 20% (you lose and have to retrain 2 people a year on a 10 member team) it might not be so bad if these two are junior QA engineers. What if these two spots both belong to the tech lead on the project? You find a great TL, he comes to your site for knowledge transfer and after two months go back to India just to resign the next week, two months and countless meetings later another one comes to your office, goes through K-transfer and goes back, and then gets hit by a typhoid fever?
Recognizing that there is much more to turnover than just a percentage sign is a huge step forward. Dealing with turnover is a much more complex issue and a rather large topic, so I’ll cover it in the next post.
Ready to Outsource?
Organization outsourcing maturity is one of the most important ingredients for an outsourcing initiative. Attempts to force outsourcing to an organization that is not prepared / not ready for it are likely to fail and chances are with a lot of collateral damage. That is true for any outsourcing initiative, not only for offshore; well, it applies to pretty much any organizational change, but my focus is on specifics of offshore though. What does it mean to have your organization ready for offshore outsourcing? Here is a high-level checklist to consider:
- Solid justification / objective reasons for outsourcing. Jumping into outsourcing following the lemming instinct would end up with pretty much the proverbial result. The industry is full of examples when organizations went after outsourcing just because it was “the best practice” and ended up with massive losses – financial, customer satisfaction, knowledge, etc. Take a look at “reasons for outsourcing” or “my reasons”, go through your own list, and make sure that you have solid objective reasons to even consider offshore. Go through a thorough and very conservative what-if analysis and unless you see a substantial ROI set the idea aside.
- Sufficient budget. You most likely heard about a hockey-stick or a J-curve – a curve / a pattern of success in business. Look at the budgets you have in-hand with the same perspective. Success requires initial investment and ability to sustain negative cash flow for some time, you need to survive that dip, before you start realizing ROI.
- Executive commitment / sponsorship. Lack of executive commitment is certain to ruin your offshore strategy. If your executives do not accept the realities of offshore savings, if they are not prepared to wait through a negative stage of the J-curve you are certain run out of budgets prior to getting offshore initiative on the path to success. It’s even worth if your executive team doesn’t buy into offshore idea due to political or personal preferences. The last thing you want to do is spear head an initiative that’s only purpose is to show a bad example.
- Team understanding, support and commitment. Chances are you can’t do it alone and through out all stages of outsourcing you will need to rely on support of your team. I do not think I need any mountaineering metaphors here. However, strangely enough, I have seen many times when offshore initiatives were driven down the thought of a core team, at the expense of the employee morale and wellbeing, without support and consideration. In my view that results at best in malicious compliance, more frequently in clever or blatant sabotage.
- Processes and procedures. Often undermined in small organizations immature processes and procedures, in particular in SDLC / project management, are almost certain to result in offshore failure. Large process-savvy organizations are also not immune as the need for the processes is proportional to organization’s size. The most important aspect of the processes is communication channels and their efficiency, inter-departmental handovers, and internal roles and responsibilities definitions.
Offshore Developer Rates
What is a fair rate for a mid-level Java developer working offshore? Seems like a simple question, yet the answer you are likely to receive from anyone familiar with the subject is “It depends…” A fair rate you need to negotiate towards to with your supplier depends on many attributes and circumstances. Here are the most important:
- Location. Almost like in the real estate business location plays utmost important role in the cost of the product (rates in this case). Location granularity is roughly at a city level, meaning that in a single city you will have roughly the same rates for specific position. Large cities such as Bangalore, Beijing, and Moscow may have some pockets / districts with higher / lower rates, those differences are not as dramatic. Raising level of granularity to a country level skews the results significantly unless you limit your horizon to only “first tier” cities.
- Other geopolitical factors. In countries experiencing explosive growth or political turmoil standards of leaving fluctuate greatly and that inevitably leads to dramatic changes in rates. Rates of vendors from Eastern Europe and China have been growing at the highest rate recently. It’s no surprise considering major improvements in standards of leaving of these countries and weakening dollar as well.
- Competency. That’s an interesting phenomena I have observed over the years. It appears that engineering community competency has very notable local preferences. For example there is a great deal of skills in mobile development in Russia, Vietnam developers seem to prefer to speak .NET, you find many developers working with OS cores in Israel.
- Company size. Unlike in the food industry where large chains offer lower prices s/w outsourcing has opposite trend – typically you will be able to negotiate better rates with smaller shops.
- Vendor business model. In high-level view there are several business models which offshore organizations operate on:
- “Body shop” – under this model the vendor is focused on billable hours / resource utilization and is typically in the business of selling mediocre resources in bulk. This not the business model you will find presented in RFP or website of the vendor, however you will see it between the lines of the proposal, in general practices, etc. This model scales well and you can see body shops ranging from Krishna’s Shack to multi-nationals of colossal proportions.
- “Consulting Organization” – same as above but with vigorous attention to the quality of resources. These organizations are typically smaller and have much higher quality of the resources.
- “Boutique shop” – I use this term for small sized high-end consulting firms which offer top quality resources often in a very narrow field / niche.
Rates naturally would be the lowest for first model and the highest for third. The questions of course is appropriate analysis as most of body shops present themselves as consulting organizations and some smaller one pretend to run “boutique” operations.
- Engagement model. There are plenty of models you can elect to work with offshore, for example resource augmentation on T&M basis, fixed bid engagements, Built-Operate-Transfer, Managed ODC, etc. Each model will offer slight adjustment to the actual rates.
- Contract details. Rate can vary greatly depending on the details of your contract, with each element being a double edged sward though. For example you can reduce the rate by committing to large number of the resources or longer term of the engagement, by agreeing with termination fees, etc.
Here are a couple links for more detailed view on this subject:
Offshore outsourcing statistics for services in 2007
Global Services Location Index (GSLI) for 2007
Choosing the Right Country for IT Offshoring
And finally, the rate table, take it with a huge grain of salt though
| Group of Countries | Outsourcing sweet spot | Rate Guideline, USD an hour |
| Canada, Israel, Ireland some Eastern European countries such as Hungary, Romania | R&D activities, Java/.NET, mainframe, product development | 35 + |
| Most of Eastern European countries such as Russia, Ukraine, Czech Republic, Poland, some South American countries such as Brazil, Argentina | Mobile development, some R&D, C/C++, Java/.NET, product development | 25 - 45 |
| India | ERP, maintenance, mainstream development, Java / .NET, QA | 20 - 35 |
| China, Philippines | Java / .NET, QA | 15 - 25 |
| Pakistan, Malaysia, Vietnam, Chile, Bolivia and many new outsourcing players | TBD | 10 - 20 |
Offshore Risks: Team and Personal Impacts
Transferring even a small portion of your development offshore has inevitable impacts on your team and yourself. The impact could be dramatic to a degree that it defeats the purpose of outsourcing. Each of the dimensions of the impact should be considered a risk that needs mitigation plan and is dealt with efficiently through out the lifecycle of outsourcing. I’ll touch upon most significant areas:
- Loss of team support / respect / relationships with the team. Even the most open minded employees on your team will be concerned with offshore introduction. And they should, the practice of outsourcers replacing the sheer fabric of the company, it’s all too familiar. As an instigator of the process you are likely to become a target of negativity. It comes in all shapes and forms with essence being “you are a traitor of ”. I remember well one of my key architects giving me an ultimatum “it’s me or them”. I do not know of any bullet proof shield here, the chances are some percentage of loss will happen no matter what you do. For me the best risk mitigation strategy in this case has always been transparency and honesty – when you can afford it. I do my best to personally deliver the message to every member of the team or alternatively setup a process which ensures consistent and accurate delivery of the message.
- Loss of team spirit / internal unease. Mutual trust even in small teams has some level below 100%. Even a perfectly delivered message will be taken with a grain of salt and generate negativity. So only medicine here is reinforcement of the message – positive reassurance is like food – you can not get enough for life time in one seating.
- Decrease in team’s productivity / commitment. Loss of key personnel / technology and business knowledge loss. Loss of team spirit / internal unease even if managed well is likely to result in tangible losses. You need to plan for them in advance of introducing the idea into your organization. Do you have sufficient redundancy in your organization to deal with inevitable loss of key personnel? Are your schedules have sufficient padding to cover for loss of productivity? Are your knowledge transfer / retention devices in place? If answer to any of these and similar questions is ‘No” you need to deal with closing the gap first and searching for vendor after that.
On a personal front the risks are substantial as well. What would championing an offshore initiative would do to your career? What’s your organization’s risk tolerance? What is its failure tolerance? How would the failures of the vendor affect your position in the organization? And so on – there are countless questions to ask here.
But even more important set of questions is around lifestyle impact. Are you prepared to shift work hours? Are you ready to deal with the never ending stress? What is your own failure tolerance?
I remember welcoming Paul Lake (an outstanding account manager for a prominent IT outsourcing company) to a role of AM on an offshore engagement. While no stranger to IT outsourcing he had never dealt with offshore side of the house. “That’s the end of the life as you know it…” - I told Paul – “You will now need to learn how to start every call with “I am sorry, I have to apologize…” I wish I was at least somewhat wrong…
Offshore Vendor Selection: Site Visits
The idea of this post partially came from Offshore Visits. Tom’s post is about visits to an existing vendor, the visits during vendor selection process are quite different though.
I am fairly convinced that the unwritten rule – “must visit perspective vendor site to make a selection” was originated by offshore sales force. This is a well known closing technique similar to test driving the car (“must drive before you buy”) a.k.a. “puppy close”. The goal of the salesperson is to build your commitment to purchase and getting you involved, getting you to invest the time paves the road to closure.
From vendor’s standpoint on-site visits help tremendously in many other dimensions, for example having you on their territory (care salesperson would take you to his office “just to discuss some details”), playing one of the strongest powers of persuasion – reciprocity, etc.
Does it mean that to avoid high pressure of sale you should avoid on-site visits? Not at all. You just need to keep your eyes on the ball and counter the pressure. Shear understanding of the role the site visits play in the selection process will help a great deal. Also here a few simple techniques that should help you counter the pressure:
- Visit several vendors on the same trip.
- Separation of duties may help a great deal – if it’s at all possible use people not involved in the final decision making to go on the trip.
- Be the driver of the agenda for all meetings on the trip.
- Concentrate on your needs and things you should accomplish on the trip.
- Take a few days off after the trip to do some personal travel and enjoy the scenery which you may never have a chance to see again.
The main goal is to make progress in your vendor selection in a way beneficial to you and not helping vendor to close the deal. In that light I find site visits extremely helpful and educational. My typical agenda would include:
- Interview with perspective team (I usually go for marathon interviews – 20-30 people per company, 20-30 min per person)
- Informal interview of managers, executives, etc. – I do not interview them per se, instead get a chance to see them in action
- Review infrastructure, take a pick in server rooms, see desktop environment
- Check out employee lifestyle – workstations, libraries, transportation, food, break rooms, wallpapers, etc.
- Assess physical and other aspects of security
I do my best to avoid:
- Meetings with large participation and no purpose
- Sales presentations in any shape or form
- Any optional activities that do not pass sniff test
Top 10 Technology Tasks to Outsource
If you listen to an offshore vendor you will quickly learn the top 10 or 1000 tasks you should outsource. The chances are anything and everything that you do will be on that list. And that would be the list of things the vendor wants you to outsource. Take a look for example at Top 100 Projects You Can Outsource. The real question is about what is good for you, and of course it depends on your specific needs and challenges. My first outsourcing item does not currently land itself well in offshore model so I did not include it in top 10 - Data Center / Hosting. That covers hardware / networking equipment / etc. for range of systems – production, staging, development, etc. environments. The “degree” of outsourcing may vary greatly and depends on the maturity of your staff, you demand dynamics, etc. You may only take the space, bandwidth and power; expand it to fully managed infrastructure or even consider grids such as Amazon elastic cloud.
Taking a viewpoint of a midsized software developments company here are 10 items I found to be on the top of list of tasks to outsource in technology.
1. Security / Availability Monitoring. In my experience I found that achieving aggressive service level benchmarks while maintaining high level security and privacy is practically impossible for a small or midsized company without use of Managed Security Monitoring. The scope of outsourcing may vary greatly depending on your needs. In my current place I outsource security monitoring and use third parties for security testing including ethical hacking.
2. Database Administration. I found outsourcing of DBA tasks, in particular related to supporting uptime of critical systems, extremely cost effective. Currently I use third party to monitor my production databases on 24×7 basis and use consulting from the same vendor on tough DBA design tasks.
3. Black Box Testing. I found that outsourcing some of QA tasks, in particular Black Box testing gives me great flexibility and has good price performance. In my view the key is to outsource appropriate portion of testing leaving sufficient portion in-house for acceptance, cross checking, knowledge retention and many other key elements of the development process.
4. Usability Testing. In my view Usability Testing is a perfect task to outsource due to many reasons with most important being an independent / objective feedback which is difficult to achieve with captive resources, other reasons include lack of in-house expertise and high cost of tools and infrastructure.
5. Graphical Arts, Writing and other Creative tasks. Assuming that Creative tasks are not the core of your business you may find outsourcing of it to offer dramatic price performance. With huge supply of freelance and offshore talent you can find high quality resources at a fraction of the price of high end firms and even in-house resources.
6. Tech Support. If you have to support your products the front line of Tech Support is one of the areas that can greatly benefit from outsourcing. Of course you have to be very careful in outsourcing any customer facing activities, and tech support is one of those arrears that got particular strong negative rap.
7. SEO. Search Engine Optimization could be quit laborious and requires in-depth knowledge of the techniques, latest trends, and subtle differences. Some offshore shops specializing on SEO offer performance based approach to compensation.
8. Software Maintenance and Sustenance. I found outsourcing of those “less glorious” tasks relatively meaningful, especially when I had a large legacy product to support. One of the value add items in outsourcing of maintenance task is potential morale boost for the local team. A word of caution here – as outsourcing of these tasks only pays off in a long run.
9. Reporting. Developing of a large variety of reports for internal and external clients often could become a considerable burden on technology team. Using offshore resources to produce and support custom reports in experience paid off quite well in many cases.
10. Technology Migration. Migration tasks could be perfect candidates for outsourcing, for example moving your database from MS SQL to Oracle, an app server from WebSphere to JBOSS, or migrating code from VB to VB .NET. The word of caution – some migration tasks could be IQ-demanding heavy lifting and require a lot of in-house efforts before they could be moved offshore.
I said earlier that these 10 items are on the top of my list. Well, in many cases they formed the list in its entirety. You may consider outsourcing all these items before you move on onto more challenging and riskier outsourcing tasks.
Selling offshore concept to your organization
Let’s assume that you are sufficiently sold on the idea of using offshore. If you are not, stop right there. You will not be able to sell your organization on any idea unless you believe it 100% yourself. There will be a plenty of people wildly against offshore and unless you are true champion of the idea it will be an uphill battle. More so there is a good chance that there will be a plenty of people supporting and even promoting the idea for all wrong reasons. Unless you know and believe in what you’ll be doing you will be stuck with delivering on wrongly set expectations against unachievable goals, and the time to update resume will come sooner than you think.
The next step is introducing offshore into your organization. Unless your organization has history of success in using offshore that will be a complex long-cycle process of selling the team on the concept itself, its benefits, and your abilities to mitigate the risks.
Your initial introduction may follow the traditional pattern, for example:
General state of the organization
- Strong foundations
- Budget cuts
- Competitive pressure
Challenges / pain points
- High attrition
- Recruiting failures
- Time to market pressure
Solutions considered
- Local subcontractors
- Internal structure changes
- Offshore
Why offshore
- Local subcontractors
- Pros
- Cons
- Decision
- Internal structure changes
- Pros
- Cons
- Decision
- Offshore
- Pros
- Cons
- Decision
Expected returns
- Goal 1 – SMART Success Criteria
- Goal 2 – SMART Success Criteria
- Goal 3 – SMART Success Criteria
Risks & Risk Mitigation
- Risk 1 – Mitigation Plan
- Risk 1 – Mitigation Plan
- Risk 1 – Mitigation Plan
Control mechanism
- Governance / Oversight
- Metrics / Feedback
- Exit strategy
You may have to sell to different groups and audiences such as execs, your team, and investors. – tune your presentations for each audience.
Couple words of caution:
- Do not overuse “negative sales approach” (something you might have learned from Sandler Training). You need to get your audience to support the idea for a long time, you need them jazzed up enough to get over the hump of initial rejection and even more important through the turbulence of establishing the relationship.
- At the same do not oversell – that’s a self death sentence. Remember that offshore is likely to fail your lowest expectations.
- Do not delegate selling to offshore account managers and/or sales execs. They will offer you that and will gladly act on your behalf. They will probably do a decent or maybe a marvelous job and you will lose control over the situation. Most likely they will over commit and you will be the one to under deliver.
Unlike in a traditional “hunter” selling model with a sole target of closing the deal you have to prepare yourself for never ending “farmer” selling process. As inevitable issues creep up and buyers remorse overwhelms some of the stakeholders you will need to manage the expectations and continue showing benefits of the offshore … of course if you see any.
Vendor Selection in China
This post is a summary of vendor selection trip to China made for a purpose of s/w outsourcing initiative for a midsized product company. The main focus of the trip was “profiling” of the vendors that made on a short list after a rather involved RFP process.
Profiling involved in-depth interviews of employees ranging from Sr. PM to Jr. QA analysts. I had a chance to interview over 60 people, and I believe that I had a chance to work with a somewhat fair sampling. I would expect that if employees were selected for interview completely randomly I would have the same professional skills ratings but English skills ratings would be substantially lower.
The table below presents a summary of my view on the software teams I’ve seen during the trip. Professional skills are rated from 0 to 10; 0 means no knowledge of the key subjects, 10 means exact or above expectations for the position. English skills are rated from 0 to 10, 0 means no knowledge, 10 means fluent (strong accent, minor grammar mistakes, etc. acceptable).
| Position | Professional Skills | English Skills | Comments |
| Account Management | 5-8 | 6-9 | I did not interview AMs per se, I had a plenty of time to observe their work though. Skills / understanding of AM practices were not at all impressive. While the hospitality was truly commendable understanding of AM activities was far from what I would expect from professional AM / sales / presales team. In particular the ability to listen and concentrate on my needs versus out of the box presentations and sales pitches was not demonstrated. |
| Project Management. | 4-6 | 5-8 | I interviewed 2 PMs, 2 were dreadful, one good, the rest were semi-decent but junior. Most of the PMs had almost no theoretical knowledge and border-line acceptable hands-on skills; only one was PMP certified, unfortunately he needed an interpreter to communicate. Real hands-on PM experience was ranging from 2 to 6 years. Most of the PM in US terms could probably be ranked somewhere between a Project Coordinator and Junior PM. |
| Business Analysis. | 3-5 | 3-7 | Unacceptable. I interviewed at least 8 of them and the only one I would possibly consider was a junior Indian girl. Most of them had moderate English skills, but still far less than you would expect from a BA. Their skills in written English were notably better but they really straggled in spoken language; understanding them was a challenge as well. Their domain expertise was not impressive even for the projects they worked on. Functional skills such as ability to gather requirements were very poor. Technical skills such as data modeling skills were practically non-existent. |
| Junior Developers (“coders”). | 3-8 | 4-8 | Developers range from very bad to pretty good. Most of them offered very poor theoretical skills and narrow and shallow practical. Need to be hand-picked, but there is a large pool to draw from. I would expect a hit ratio of 1 out of 4. I saw great deal of desire to succeed and multitude of signs of superb work ethics. |
| Senior Developers (“architects”) | 3-6 | 3-5 | Very poor, most of them at best would qualify for mid-level developers. English skills are notably worse than juniors. The more senior the person is the more difficult s/he is to understand. The only good guy I met (would rate highly in Silicon Valley) required an interpreter. |
| Technical
Leads |
5-6 | 4-7 | Mediocre. Probably not self sufficient on tasks requiring dealing with complex technical issues. They seem to be generally a combination of a mid-level developer with a junior PM. I would say on both PM and technical accounts they are a notch lower than I would expect in the USA. On the other hand I saw a very strong drive / desire to succeed which could possibly compensate to some degree for the lack of knowledge. |
| Junior QA, Black Box | 6-9 | 5-10 | Testing skills ranging from good to very good. English at pretty decent level (most of them came from English studies or had lived in English speaking countries). Most of the QA analysts I interviewed seemed to have a great personality to position match. |
| Junior QA, Automation | 4-5 | 5-7 | Very small pool, most of them were mediocre at best with very limited exposure to tools. Typical “record and play back” skill set. Most of them had a career path of black box tester to an automation engineer (no development background). |
| Senior QA, Automation |
4-5 | 3-5 | Bad. I saw only four of them though; both skills and language were below mediocre. |
| QA Lead | 7-8 | 5-8 | I saw 9 QA leads and all were OK, nothing spectacular but very focused, detailed oriented, well organized, etc. Good grasp on QA process (very specific to the company’s process though). Understanding / grasp of QA automation at very basic level. |
| General Management | 5-10 | 6-10 | Very strong business leaders with outstanding work ethics and commendable drive. Mostly ex-pats / returnees from Western countries / Hong Kong / Singapore. However some of them were not professionally strong as they seem to be able to get the jobs on the raising wave of outsourcing mainly due to their western credentials. For example one of the execs I met was a Ph.D. in theoretical physics with no prior consulting / sales / software experience, very smart guy with very little experience / exposure / understanding… |
Idiot Savant
It’s been almost two years since the story below shook up my organization yet it’s still quite fresh in my memory. This story stands out as rude reminder of how complex IP protection is and how many traps you need to consider. Even though the story is a bit old I still changed the names of the participants to protect the innocent…
Ravindra Gupta a senior java architect from a well respected local high-end consulting firm ThinkBig impressed us the first time we met him. He seemed to be exactly the person we’d been looking for a long time. With little hesitation we assigned him a challenging task in a user management and administration (UMA) space. He flew in our SF location and spent a couple weeks going through the analysis of the issue, discussions with our staff and me.
I consider UMA tasks some of the most challenging and was happy to have a very impressive guy deal with them. We spent days educating Ravi on functional aspects of the UMA, its issues, technical challenges, and numerous tricks and traps. I was very impressed with Ravi grasp and progress with it. After a few weeks in the office Ravi took off to work from home at the East Cost.
The year end frenzy took my mind of UMA and Ravi’s work. Ravi’s brief status reports and scant communications did not bother me much especially considering that he was apparently making good progress and we were expecting detailed technical review session right after the holidays. Unfortunately though the meeting never not took place, instead one of the first emails of ’07 was one from Ravi:
From: Ravindra S. Gupta [mailto:rgupta@thinkbigconsulting.com]
Sent: Saturday, January 06, 2007 1:33 PM
To: Nick Krym
Subject: U.M. Design Copyright
Hello Nick,
In the chaos of the holidays, I was fortunate to find some time to myself. This yielded an insight: I have to stop selling my copyright for the price of a copy. “R.S.G. Consulting” was therefore founded (finally) on 1/1/2007.
Consequently, the existing contract (made with ThinkBig) is no longer acceptable, and I want to proceed forward under the following general agreement:
I own the copyright to all parts and whole of the generic Access Control System (RACS) that I am creating. Medem does not pay for the development of RACS, but may buy a very favorably priced license. However, it is under no obligation to do so.
To demonstrate suitability-of-use, I will configure the RACS to support up to five (5) use-cases chosen by Medem, at no cost to Medem.
Should Medem then buy a license (still no obligation), it may buy my professional services to fully or partially configure the RACS for use with the new Medem system. All work done towards this task will belong to Medem (i.e. will bear Medem’s copyright), with exception of any modifications made to the RACS (which will bear my copyright). However, Medem may instead choose to have its own developers or other consultants configure the RACS.
The attached document describes the Pricing model, Availability, etc.
The design that’s taking shape is beautiful in its simplicity and power of expression. It will more than accommodate Medem’s needs for years to come.
Please feel free to contact me at any time.
Sincerely,
Ravi
R.S.G. Consulting
I red the email and picked up phone calling Mike, CEO of ThinkBig.
A month later, after the dust settled, legal bills were paid and separation agreement signed Mike and I were seeping coffee at our favorite spot at Montgomery and Bush. Mike was going in rounds about the fact that someone he’d been working for over ten years would do anything like that. In my mind there was just one answer, an expression that I had recently learned: “Idiot Savant”
Pros and Cons of doing business in China
From 30,000’ view Pros and Cons of giving your outsourcing business to China could be summarized as
Pros
- Comparatively low rates
- Low attrition rates
- Large pool of talent in many areas
- Superb work ethics of the workforce
- Well organized / highly disciplined organizations
- Staff’s desire to succeed (learning and becoming stronger professional rather than pure career move)
- Flexibility of the contract arrangements
Cons
- Poor English skills
- Weak grasp on western communications style, wide cultural gap
- Poor theoretical knowledge in many key areas
- Weak technical skills in comparison to the mainstream Silicon Valley resources
- Limited access to resources in several key areas (e.g. business analysis, architecture)
For most outsourcing initiatives that I managed and consulted on Cons outweighed the Pros. Yet I hope that sooner or later I find the right project and a team in China to match, more so I believe that the balance of Pros and Cons is changing as we speak; in particular
- Poor English skills – Chinese government and outsourcing companies are making very significant investments in English training.
- Weak grasp on western communications style, wide cultural gap – A large number of expatriates returning to China with their families after living in the USA and other countries is reshaping culture of Chinese outsourcing.
- Poor theoretical knowledge in many key areas – I am not seeing notable changes there; possibly due to the fact that majority of service buyers are not concerned with that issue.
- Weak technical skills in comparison to the mainstream Silicon Valley resources – Using an old joke as a metaphor – Chinese vendors do not need to outrun Silicon Valley they just need to outrun Indian vendors.
- Limited access to resources in several key areas (e.g. business analysis, architecture) – Influx of expatriates and attention to the issue should eventually take care of it.
| Of course as Cons are being addressed China may lose some of its competitive advantage in Pros category – attrition rates, cost, etc. That remains to be seen.
I always thought that China was destined to win, and if I ever had any doubts they were eliminated after my trip to Shenzhen. When you see what a combination of strong hand of the government and grass root entrepreneurship can do to transform a small fishing village into a megapolis in just 35 years you start to believe that there is nothing that China can not achieve. |
 |
Cost-reduction expectations
Establishing high cost-reduction expectations is one of the most serious traps a technology leader can get him/herself into. If the only reason you are going offshore is cost savings – my best advice would be – stop right there! If you are very good at utilizing offshore you may realize 30% savings on somewhat sizable initiatives, and you still will need a lot of luck. That’s aside even if you do understand the paradigm of cost savings you still have to establish appropriate expectations with your execs / peers / team. Failure to establish correct expectations results in insufficient budgets, often in a collapse of the entire outsourcing initiative with a serious ripple effect.
I receive emails from one of Beyondsoft (China) sales execs on a pretty much monthly basis. While his tenacity is commendable his message is totally ludicrous, here is one of his emails:
Dear Nick,
I know your schedule is very tight, but I really hope we have an opportunity to share our ideas on how to help you decrease cost by 300% in next 12 months.
I thought that’s a good opportunity coz you are in Beijing now, and our meeting would make you more impressive.
Looking forward to your early reply.
Best regards,
George Tong
300% wow! where do I sign!? Think about your execs who are continuously spammed with such messages. Direct mail, articles, whitepapers, case studies and so on conveniently delivered to your boss’s ear scream about potential saving from offshore. Setting appropriate expectation on your part will be a balancing act of delivering a bad news without sounding like a sandbagger. Here is a presentation approach I found somewhat successful in setting my audience’s expectations at a reasonable level.
Start with debunking the Myth of Cost Savings
- What vendors are telling us
- Couple genuine offshore horror stories
- Rates vs. True Cost of Outsourcing
Change audience focus to specific challenges / reasons for outsourcing, e.g.
- Time to market
- Access to specific resource type
- Refocusing internal resources
Setup SMART (specific measurable actionable result-oriented and time-bound) goals for outsourcing, e.g.
- Move 100% maintenance of product X to Worksoft team by 5/15/210
- Deliver 50 functional points by ZenSar’s team by 9/20/2009
Another pointer – my recommendation is to setup an expectation that there are NO cost savings and work in terms of alternative delivery benefits rather than cost. For example:
- The project Odessa requires 5 FTE for 10 months.
- While we do have a budget for it we do not have the resources.
- Finding skilled developers and QA engineers is likely to take us over 3 months and we will need to train them for about 2 months.
- To save the ramp up time we are going to us MindTree team.
- The budget allows us enough resources to deliver the project under 12 months.
There is another trap here – what if the team you recommended can not deliver on time? Well, that’s not at all inconceivable, yet easier to control and deal with.
Top outsourcing risks
Putting development of your product or any other aspect of technology in the hands of a third party is certainly a risky proposition. To properly mitigate the risks of outsourcing one needs to understand the outsourcing landscape quite well. The top offshore outsourcing risks fall in several main categories. There is much to be said about each of the categories; I am planning to add more substance / clarifications /examples to each of the bullets below, as well as some ideas on risk mitigation. For now, here is the high level list:
Geopolitical
- Government regulations, on the both sides of the equation
- Political stability
- Legal maturity
Security
Internal – Organization
- Cost-reduction expectations
- Organizational commitment
- Organizational maturity – multiple aspect of being ready to outsource
- Loss of team support / respect / relationships with the team
- Loss of team spirit / internal unease
- Loss of key personnel / technology and business knowledge loss
- Decrease in team’s productivity / commitment
- Career impact
- Lifestyle impact
Vendor capabilities
- Financial Stability
- Organizational maturity
- Organizational commitment
- Infrastructure (macro / micro view)
- Technical capabilities
- Ability to deliver
- Personnel turnover
Joint responsibilities
- Process confluence
- Scope management
- Geographical dispersion
- Cultural differences
- Knowledge transfer
- Communications
My reasons to outsource
I mentioned already the top reasons for offshore outsourcing typical for many organizations; let me list some of my own:
- Diversity. Diversity in terms of bringing individual contributor with different background into the team often means a tremendous increase in productivity. A healthy portion of resources with different education, practical background, and way of operating could bring a fresh breath of air in stagnating organization. Also “diversifying” your portfolio of resources might help a great deal to deal with micro factors affecting employment / recruitment landscape of a specific geography.
- Education. In countries such as India, Russia, China you find many people who value education to much higher degree than we do in the states. On one of my teams from St. Petersburg a majority of developers had at least MS and over 40% had Ph.D. That including QA engineers! Needless to say the brain power of the team was absolutely amazing.
- Work Ethics. That doesn’t go across all geographies and companies, but fortunately you still can find outsourcing organizations with resources who’s work ethics are far superior to what you find for example in corporate America.
- Talent Pool. Some outsourcing organizations instead of typical “selling mediocrity in bulk” build their team with top notch experts and people with exceptionally high IQ. Building such a team, no matter in which area of the world takes very long time.
- Processes. Getting process right is time consuming and costly. When ISO or CMM processes are a requirement it’s often much easier to build relationship with a subcontractor who already has those in place.
- Project Management. Project and program management is often something that a small software organization can not afford (or more often VPE can’t sell his execs / team on the need for it). Many, especially Indian vendors have that in perfect shape.
- Cost. While I do not believe that offshore guarantees cost savings I do believe that there is a huge potential there especially with careful execution of multi-sourcing or/and micro-sourcing strategies.
Not yet ready for China
I love travel and visit new places, even if that’s on a business trip. Needless to say that living “5 to 7” lifestyle (by 5 am Monday you are on a plane to the client and ~7 pm on Friday are back on your way home) grows old quickly, but my engineering leadership role delivers travel in just the right amount. So I was quite excited when I got a chance to go to China to meet with a few promising offshore outsourcing companies. Impressed by meetings with vendors’ execs I was looking forward to starting with one of their teams in China.
Jumping ahead, I have to tell you that out of my top three impressions of China one was far above the expectations, one was at par, and one was way below. The first one was food – sorry Chef Chu, Dragon Well, and Yank Sing – there is no better place for Chinese food than China. The impression that was exactly at par with my expectations was my prospect resources’ command of English – it was dreadful. That was not a big deal for me though – English is a second language and work in progress for me as well, plus quoting Clarence Darrow, “Even if you do learn to speak correct English, whom are you going to speak it to?”. The thing that fall way below my expectations and to large degree ruined the trip was technical skills of engineers I saw.
Having spent the last 10 years of my life in Silicon Valley I’ve been conditioned to be surrounded by people much smarter than I. A great majority of them came from Asia. So I was expecting to see people like Bhaskar H, John B, Mark Dao, Shao Fang, Harshal Deo, Michelle Sue, Ashish Mangla… I was expecting maybe not the same level of intelligence, grasp on technology, and knowledge of foundations but at least somewhat close. Instead, my vendors paraded in front of me dozens of engineers who could not explain what a polymorphism is, project managers who did not know how to use MS Project, business analysts with nothing but a desire to be one. A few days into my interview process going through at rate of ~20 30-min interviews per day I met only one decent PM who did not speak English at all, one good yet quite junior business analyst (she was an IIT grad and just moved to China with her husband), and a handful of barely acceptable engineers. My interviewing stats were:
Project Managers – 1 out of 9
Business Analysts – 1 out of 11
Senior Developers – 0 out of 6
Mid Level Developers 2 out 14
Junior Developers – 4 out of 9
QA Leads – 1 out of 4
Blackbox Testers – 4 out of 6
Automation Testers – 0 out of 7
After visiting four companies my mind was set and I switched to enjoying tours to Forbidden City, Bird’s Nest and Summer Palace; I climbed the Great Wall, took many pictures, and bought a bunch of souvenirs. I knew that would be a while before I see China again.
Having spent some time thinking through the reasons behind my failure to find the vendor I could probably attest to those commonly known:
- China is relatively new to the IT outsourcing, in particular for US projects. There is a great deal of skills, experience and understanding that has not yet been built up.
- Language is a natural and serious obstacle which China outsourcing companies need to invest a great deal.
- Chinese outsourcers need to learn how to deal with a large variety of cultural differences to successfully compete (and not only on cost). I believe that they need to find their own style. While a lot could be taken from success of Indian vendors, just “cut and paste” would not work.
On my trip to China I also discovered a few things that I had not heard of before:
- In Chinese education system getting an English major ranks bottom low vs. engineering or CS degrees. Inevitably it attracts the least talented students. However, in a race to address language handicap outsourcing companies recruit English major students for key development positions – project managers, business analysts, etc. No wonder none ob the BA I interviewed heard of UML…
- While checking out offices of many outsourcing companies I noticed one thing in common: developers’ desks were perfectly clean – not a single book anywhere. I guess one of the reasons is in lack of relevant literature in native tongue. Reading O’Reilly in English is an uphill battle for many of engineers.
- Most of the engineers I talked with gained all their knowledge on the projects they worked on, which is a great way to learn when it is one of the methods, not the only. Result is extremely narrow scope of knowledge / expertise.
So I guess I am not ready to send my work to China yet, while I really do want to. Why? That would be a great topic for another post.
Offshore productivity: developers
Why is offshore developer’s productivity so much lower than one from your local employees? You would expect that for positions that require high communication overhead or for those tightly linked to difficult to acquire domain expertise, but why developer? Java, C#, C/C++ know no borders and far more international than Esperanto ever aspired to be. So why do we habitually see offshore developers offering productivity at fraction of what we expect in-house. I think there are many reasons for that, some transient some foundational. Here are just some of them, specifically applicable to India outsourcing:
- Bangalore is a beautiful vibrant city; in some strange way it reminds me of San Francisco. No wonder it has become the heart and a synonym for IT outsourcing, one would be hard pressed to find a better place for India’s Silicon Valley. One of the parallels between Bangalore and SF Bay Area is abundance of technical jobs. Everyone and their brother are there from giants like Microsoft, IBM, and Siemens to small progressive engineering companies. Just look at a very small subset at http://en.wikipedia.org/wiki/List_of_IT_companies_in_Bangalore. So if you are a decent developer your job choices are practically unlimited. And let me ask you that – if due to your exceptional talents you had a choice of working for any software company in the world would you pick someone like Google or Infosys Technologies? It’s tough to get into someone’s mind yet I am sure that a choice between Google and Quadwave Consulting Pvt. Ltd. is statistically obvious. The corollary here is obvious as well: when it comes to pick of the litter even very successful outsourcers are in a long line behind a very large group of “the best companies to work for”.
- One of the interesting phenomena is how cultural environment affects building the skills. What I have observed in several geo areas is that the culture is “against” the learning progress; that is especially true for consulting companies. For example, many consulting companies have a business development track vs. expert track, the first one being compensated substantially better. In that case a bright person is pushed either to take a biz dev track or bail out of the company when his / her earnings come hits the ceiling. Broader cultural issues have even more profound effect, for example I noticed that in India one’s personal success is measured in number of people working “under you”, most of the time that means that one’s skills would be used mostly on management tasks and not tuned to acquiring new skills / knowledge / etc. Very much a cliché – promoting a good engineer to a manger means losing a good engineer and gaining a bad manager. The impact of that trend is quite devastating for buyer especially with smaller sized teams – how can you get a solid tech lead for your team if it is only 3-4 people while someone with 5 years experience could be managing a team of 30? That trend is exacerbated by scarcity of high-level resources every consulting company faces: if a practice gets their hands on great resource, he or she must be leveraged across large group of mediocre resources.
- I realized another angle to the topic when building my own consulting / outsourcing teams. Managing engineers is not an easy task, managing bright engineers is extremely complex. So if your main goal is generating a revenue stream (a.k.a. “putting buns in seats”) you may take an “expert” route and deal with celebrity personalities and never-ending need for motivation or build your team with “a middle of the road” resource in mind and live happily ever after. The later seems like a much easier route and that’s why many offshore resource augmentation companies are in the business of “selling mediocrity in bulk”. What is the difference in productivity between star and mediocre software developer? Some say that it’s order of several magnitudes, and I can attest to it.
Outsourcing Myths: cost advantage
On a surface that seems obvious: even with dollar fall, rising cost of living in India, China and especially eastern Europe the hourly rates continue to be much lower than those you have to pay in the states. For example, a mid level java developer would roughly cost you:
SF Bay Area, full time $60/hr
SF Bay Area, contractor $80/hr
Bangalore, India $25/hr
St. Petersburg, Russia $30/hr
Shenzhen, China $20/hr
So for every contractor in your San Mateo office you can put 4 in Shenzhen or 2 in St. Petersburg. Or, looking from savings angle, instead of paying a team of 8 engineers roughly $80K a month you can pay less than $30K in China and get yourself a hefty raise.
However, let’s take a look at real cost of outsourcing. The first rate killer is productivity: in my experience on average productivity of resources in India would be 50% of what you would get with local mid level resources, for senior developers it would be at best 75%, and for juniors you could potentially see it as good as 80%. To achieve that level of productivity you would need to put above average efforts in shaping your team and have considerable amount of luck. Typically getting a good senior developer is only possible if s/he is managing is at least 20-25 resources. Also be prepared that understanding of seniority may greatly vary from what is considered a norm locally, and in that light delivering another productivity hit. Let’s imagine that you are planning to outsource a 5 member team that includes one tech lead, two mid-level java developer and relatively junior ones. Your cost for the team would be roughly:
| Role | Level | Experience | QTY | Salary | Aprox Rate | Monthly Cost |
| Tech Lead | Senior | 10+ | 1 | $140,000.00 | $ 82.60 | $ 14,537.60 |
| Developer | Mid | 7+ | 2 | $100,000.00 | $ 59.00 | $ 20,768.00 |
| Developer | Junior | 3+ | 2 | $ 75,000.00 | $ 44.25 | $ 15,576.00 |
|
Total: |
$ 50,881.60 | |||||
What would it cost you in Noida? Let’s assume that you got lucky in finding a tech lead for the team and the rest of the members were typical developers you could find out there.
| Role | Level | Experience | QTY | Salary | Aprox Rate | Monthly Cost |
| Tech Lead | Senior | 10+ | 1 | N/A | $ 32.00 | $ 5,632.00 |
| Developer | Mid | 7+ | 2 | N/A | $ 28.00 | $ 19,712.00 |
| Developer | Junior | 3+ | 2 | N/A | $ 25.00 | $ 17,600.00 |
| PM | Mid | 5+ | 1 | N/A | $ 30.00 | $ 5,280.00 |
|
Total: |
$ 48,224.00 | |||||
Note that team in India also includes full time PM which is not surprising for a team of 9. The result is a staggering 5% of cost savings. Your actual numbers could be different based on your negotiating skills, but the dynamics won’t change.
I am sure that many outsourcing companies would dispute my assessment of productivity. Well, let me give you a couple examples:
- We stopped a development project (CICS adapter) being developed by team of five “very senior engineers” from Mastech after ~3 months due to unacceptable quality of deliverables. 2 months later the adapter was developed by a single developer we had on staff.
- We had to stop and take in-house a handheld development project (.NET) being delivered by a senior developer and several mid-level ones from MindTree due to low quality of code and extremely low productivity. This project was later delivered by a single mid-level developer with oversight from a senior developer in time shorter than it had taken us to ramp up the team in Bangalore.
The list of examples can go on and on, they are just examples, however, considering that I could not offer any examples of an opposite nature, there is possibly a trend here. The question is why offshore developer’s productivity is so low? I’ll put my thoughts on in a separate post.
Top reasons for outsourcing
Whenever I have to introduce using offshore to executives I start with a slide with has title “Good reasons for going offshore”. The slide is otherwise empty. With all the headache it will cause why would I go offshore if I do not absolutely have to? I have been using offshore vendors since ‘92 and there is no place on my body which doesn’t have scars left by that experience – from grotesque stabs on the back to burned fingers. And yet again and again I find myself using offshore vendors and recommending them to my clients and partners. So what are the main “bad” reasons for using offshore? What typically drives companies to consider offshore outsourcing? For many companies those reasons could be roughly grouped into 3 categories:
Reducing operations cost, some most obvious examples would be:
- Lower resource cost; this topic deserves a separate discussion but for now let me just say that if you are good at utilizing offshore you may realize 25-30% savings;
- G&A savings (benefits, office space, utilities, etc.);
- Other resources related savings (reasonable severance, resource add-on acquisition cost, training cost, etc.).
Reducing time to operations / time to market, some examples include:
- Access to existing pool of resources vs. hiring; I will need to touch upon that subject in more details, for now let me just say that that in some cases that is true;
- Establishing development / operations infrastructure vs. using existing or building upon existing;
- Access to specific skills / domain expertise / methodology, etc.
Solving specific organizational issues, a lot of diverse and unique items here, here are just a few common examples:
- Outsourcing legacy maintenance to motivate developers by moving them onto more glorious tasks. That is a well known double-edged sward though.
- Dealing with sawmill of resource demand. Need for resources goes up and down if you staff at the top level your resource utilization suffers, if you target the bottom you can not react to market needs. Proper offshore supplement can help alleviate the issue.
- Risk mitigation, for example: should you hire for dealing with substantial spike in demand? Is the change permanent or when the novelties ware off you will be facing RIWFs? Outsourcing could be a better way to handle the spike.
- In some way the same idea as above but put into terms very clear and dear to hearts of CFOs – eliminating fixed cost
- Using third party operational expertise, existing processes, certifications, etc.
While in a way each of the reasons above could be enough to consider offshore in my view you need more than one reason to actually go offshore. The risks and penalties are just too high. And that deserves a separate discussion.
About
The price one pays for pursuing any profession or calling is an intimate knowledge of its ugly side. [James Baldwin]
In IT outsourcing one does not need to go too far to get ultimately familiar with its ugly side. However, despite all disappointments and failures I honestly believe in offshore capacity and its positive impact on the industry. I’ve seen enough success stories to continue using offshore resources myself and recommend it to others. Offshore outsourcing is one of most powerful weapons in technical leaders arsenal. And like any other powerful weapon it requires careful handling and great deal of knowledge in its use and application. Ugly enough even slight mistakes in its utilization could cost companies enormous pain and expense and technical leaders their reputation and career.
The goal of this blog is to bring to everyone involved in offshore outsourcing my 5 T’s – Thoughts, Tools, Tips, Tricks, and Traps of outsourcing. I hope you find it helpful.
-
Tools & Links
