The Old Joel on Software Forum: Part 4 (of 5) - Offshore: how long does it take to make it work.

Offshore: how long does it take to make it work.

There has been a lot of discussion here about outsourcing and offshoring; mostly in terms of is it good or bad "in theory". I would like to find out how it's worked for the contributors here in practice. Especially: how long does it take to make an outsourcing deal work ? How long does it take for the outsource/offshore developers to blend in with your processes. Do you ever get to 100% of in-house quality & delivery ? If not what is the bottom line ? Has anyone got better quality &/or delivery than in-house work. More importantly, what is the curve like ? Does it take a long time to get results or do you get results quickly and then struggle for the last 25% to match in-house results.

What about the offshore developers ? Do you get support or resistance from your new colleagues ? Are you held back ? Are you pushed too hard ?

Ian Sanders
Monday, March 1, 2004

What if an offshore house gets infiltrated with terrorist developers and they leave back doors to your apps?

Yo
Monday, March 1, 2004

Hmm, spaces before punctuation...

Monday, March 1, 2004

Well, you do realize that you'll be cursed for even *thinking* that outsourcing works and saying it out loud on this forum?

RP
Monday, March 1, 2004

"What if an offshore house gets infiltrated with terrorist developers and they leave back doors to your apps? "

Don't worry. The gang that has already infiltrated your inhouse setup will fight them off in a teritorial dispute.

Just me (Sir to you)
Monday, March 1, 2004

You know the answer. It's "it depends". Depends on the quality of the management both at your company and the outsource company. And the quality of the developers at the outsource company.

We've had two successful outsourcing efforts and two less sucessful. Both times it came done to the quality of the people at the other end. Where they were professional developers who understood our processes, it worked great. Where they were a bunch of engineers that just started getting involved managing programming projects it floundered.

To answer your question directly. Imagine you put the people doing the outsourcing in the next office. How long would it take for them to be productive?

pdq
Monday, March 1, 2004

Disclaimer -- I think Off-shoring can work, but in my experience, the numbers are often "helped" to make it look more economical than it is. In addition, I contract so this is a view from outside the company.

To your specific questions:
How long to blend?
- Onshore staff of the organization will blend within a few months. Use the three month rule and you are good. (_They_ will tell you a few weeks.) The offshore staff never really does in my experience. Instead they operate as their own organization, like the post office. You box it and drop it off, the deliver it. Which I think leads to:
How long until they and you are one big team?
- Never, and they choose not to be. They are looking for "coding to specification" work. You spec it out, hand it to them, they give it back to you.

Do you ever get to 100% of in-house quality & delivery ?
Absolutely. I will even say, sometimes better. What you don't get is deliverables without specifications.

For example: Assume Part A requires 2 part Bs to be usable. Other areas of the system know we do not count as "available" any unit if all three pieces are not there. If someone did not spec it for the work being done offshore, the resultant code may say If A>1 then...
Today "Sue" knows that A+2Bs must be present, and the "NewGal" may not. But for her to fix it takes a couple of minutes. To fix it off-shore requires:
- Updated specs ($2000 - minimum for changes)
- Spec review and approval (2 hours minimum times number of On-shore over-site team @ $100-$200/hour) [BTW - I have been offered the on-site job. I was told they find clients are more receptive to Americans/whites holding that position.]
- Off-shore transfer of spec (1 hour)
- Off-shore review of spec (minimum of 2 off shore and one onshore resource)
- Spec change (1 - 3 hours)
- Transfer back to on-shore (1 hour)
- testing by local team
- normal integration
Even at $30/hour, this went from a 1-3 hour on shore change to a 8+ hour change. Also, most of that communication was "scheduled" so it was not one day, but three or four to complete.

A trivial example that shows the need to define absolutely everything. _If_ your organization does not include this in their budget, they are grossly underestimating the true cost.

This is my experience from three different off-shore experiences. In a nutshell, if you are paying more than 20% for offshore developers, compared to on-shore, you are probably losing money.

It reminds me of the Razorfish days, http://www.wired.com/wired/archive/8.09/razorfish_pr.html where companies convinced each other to listen to these guys, and if you did not then you were "old school."

Now, if you don't find Off-shoring saving a large part of the IT budget, it must be _you_. Once again, the emperor has not clothes, but everyone is afraid to admit it.

MSHack
Monday, March 1, 2004

> Especially: how long does it take to make an outsourcing deal work ?
Outsourcing a project begins *after* signing contract.

> How long does it take for the outsource/offshore developers to blend
> in with your processes. Do you ever get to 100% of in-house quality
> & delivery ? If not what is the bottom line ? Has anyone got better
> quality &/or delivery than in-house work.

This is very important from the client's point of view since customers' business processes differ. For example our development circle is requirements-design-development-testing-production, and we not use XP technique, which by the way has no design phase. So, ask your outsourcing provider how they work. It can take about 3 months to learn and be ready to follow your specific processes, if very differ.

Yes, if you contact a really highly experienced/knowledgeable outsourcing team, you will get better ROI, may be at the same expence as your in-house team.

Evgeny Gesin /Javadesk.com/
Monday, March 1, 2004

"Even at $30/hour, this went from a 1-3 hour on shore change to a 8+ hour change."

But management will use the 8 hour figure when they claim how much was saved. They'll calculate the difference between 8 hours locally and 8 hours offshore, hiding the fact that it would have taken 1-3 hours to do it locally. If the offshore vendor took 20 hours to do the same job, they could spin that to make it look like they saved even MORE!

T. Norman
Monday, March 1, 2004

I really must try and loose those spaces before the question mark.

Ian Sanders
Tuesday, March 2, 2004

Looks like the numbers have been crunched, but you may (IMHO) be missing some things that will blow up any such numbers. Speaking from experience, beware of perceived vs. real value. You may end up paying a lower rate, but is the contractor (or employee) even close to as motivated as internal talent? I had contracts with several SWdevs from India and it turned out that their agent made 70-80% of the hourly rate - the worker only made a pittance. One of the end results was that every schedule was drastically overrun because the workers felt like just a worker instead of a key member of a team with important responsibilities.

Compare this to internal workers who were paid more (even relative to a high cost of living), felt more directly connected to the project, had a similar work ethic, and who were more likely to be enthused about the company. And I can tell you, an ounce of enthusiasm can cut through an entire bundle of design, communication, code management and testing challenges. Don't underestimate the value and power of a smaller team where each person views their responsibility as challenging (personal growth) and exciting (prideful).

In general I found that by going "outside" I ended up with teams that were 2x, 3x or even more times larger than an internal team, and with all the negatives such scale imposes on you. By keeping my teams as small as possible and tightly communicating, I could amaze my peers, supervisors and critics - as well as the engineers - by creating synergy within the team - and letting the genius in each of them come out.

E.g. one time I had to create a 24x7 worldwide highly technical customer service team. Instead of the typical larger pool of hierarchically skilled employees (start at the help desk, and gradually work up the skill chain if your problem is hard) - instead of this in 2-3 global locations, I achieved it with a small, balanced team of senior engineers plus some clever tools to optimize communication and CRM.

*The key* was finding the right mix of senior engineers who were highly motivated (having a blast in this job). After some exploration during the interview process I found that there were many top engineers who were tired of coding and adding features - they wanted to do systems engineering and solve more complex customer-level problems for a change - even get involved in the sales process occasionally. That's what they got, and I got an amazingly streamlined yet super high quality customer service team at a super bargain price.

BTW - I can't overemphasize how important this"key" is. If you focus on designing a group whith positions that are fun and great learning experiences, you can do huge amounts with less. And if you just keep your eye on everyone's *career path* and move folks around before they get bored, you will have a sustainable source of motivated, high quality workers who (as I found out) can do things you never imagined possible.

And as easy as this is to do compared to hiring a large team (especially abroad), if your boss is pressuring you to outsource, it's not hard to ask for a small amount of time to "try out" this sort of approach. I guarantee it's a hell of a lot faster to build and measure success than any external approach. And these employees are YOURS. In the customer service example above, my engineers had great career paths into sales, marketing, development or test, so this group became a farm organization for many other groups.

Jeffers
Saturday, March 6, 2004