Comments on: Three Absolute Requirements for Successful Offshore Application Development, Part 3

By: Three Absolute Requirements for Successful Offshore Application Development, Part 2 « Software Configuration Management

Fri, 11 Apr 2008 01:30:32 +0000

[...] Part 3, Don’t Annoy the [...]

By: Lorne Cooper

Lorne Cooper — Mon, 31 Mar 2008 20:37:22 +0000

Right on, Paul. Note the requirements interchange you discuss is not always a function of outsourcing, but rather a more direct function of the amount of domain expertise in either group… when the guy at the other end of the pipe doesn’t get it, it will take a while, whether she’s in Beijing or Bangor.

That said, the cultural differences between the developer and trader in Manhattan are going to be less than between the developer in Manhattan and the trader in Tashkent, which are going to make it that much more difficult to really understand the requirements. And if they don’t share a primary language, well, that isn’t going to help any.

By: Paul Keeble

Paul Keeble — Mon, 31 Mar 2008 16:16:32 +0000

Finding talent whether it be in a local geography or in India/China/Eastern Europe is always going to be difficult. Its more difficult in India/China just because there are so few people with 5+ years of experience in the market, and time programming makes a big difference to productivity and their ability to solve problems. In my experience its important to consider carefully what you outsource and try and restict it to the following:
1) Make sure the team is going to be fairly sizeable to begin with. There is almost not benefit to outsourcing 2 people because you have the overhead of senior people local and remote and analysts etc, its very hard to do without the go betweens.
2) Anything that is really time critical outsources poorly, unless its very simple (Support teams, QA etc).
3) Make sure that there experienced people in all geographies and plan for double the amount of time talking about requirements as a minimum.
4) Expect queries on requirements, frequently, in volume and allow high latency answers. Every question to the client takes a day and can really hold up development. As such its often good to pair up two activities for a developer, one that is potentially query heavy and one that is technical but requires little client intervention. This way if the client queries are slow your team doesn’t loose time constantly.

By: Sudeep D'Souza

Sudeep D'Souza — Wed, 30 Jan 2008 05:42:01 +0000

The requirements discussed here are very valid and hold true for most offshoring projects. I think one of the key requirements that was not discussed is “Clarity in the requirements” Many a times projects come offshore with a very vague definition. These projects are bound to fail because the person who conceptualised the project is not down the hallway to come and see how things are progressing and then take corrective action.

I have spoken more about this on my blog at the following URL http://sudeepdsouza.blogspot.com/2008/01/rules-for-successful-offshore.html

By: Lorne Cooper

Lorne Cooper — Thu, 29 Nov 2007 22:12:48 +0000

I’m with you Mike. There are three reasons to go offshore: (1) cost, (2) access to talent, (3) leverage alternate time zones.

With poor leadership, you’ll almost certainly have turnover, even here (curse that 13th Amendment ) and high turnover in an organization reduces productivity to the point where it becomes an uneconomical option.

Without access to good talent, it is better to off-shore simple, repetitive tasks. Why give highly leveraged tasks to weak performers? Off-shore or here!?!

Finally, you make another good point on the advantages of having a follow-the-sun environment, especially for technical services. If you can get, and keep, the talent, there are areas where it makes sense to be working while others are sleeping. Examples include customer support, build and release engineering, IT, and (especially in an Agile environment) QC.

By: Mike

Mike — Tue, 06 Nov 2007 02:08:39 +0000

Lorne, I continued to think about this post for a good part of the day – so clearly it’s a good subject. Anyway, I don’t have any axe to grind about off-shoring (in fact I would love to go back to India even for an extended time) I just think we need to be very careful about which things we send overseas. I have to wonder if we couldn’t get more benefit from other activities like remote system admin, packaging and deployment, and QA testing – where the time difference works for us rather than against us – instead of development. You also make a good point on the relative productivity of different developers, and this is a real concern as my impression was that there was a lot of developer churn with folks changing jobs every six months for more money.

By: Lorne Cooper

Lorne Cooper — Mon, 05 Nov 2007 22:09:29 +0000

Good point, and one that we’ve all struggled with. But if we can get a talented, motivated, leader in a geography that costs < 1/3rd what we’re paying stateside, we become much more competitive as an organization.

The common fallacy is to assume that because software development productivity is hard to quantify that there must be little difference in output between people earning $26K and people earning $130K.

I guess if you’re going to fail, you might as well pay less, but most of us start projects in the expectation that they’ll succeed in meeting their business requirements. There’s no savings in spending less to fail than in spending more to succeed. The goal is to find ways to get the probability of success in the lower-cost to an equivalent level as our high-priced people. Then we can invest our time and energy elsewhere on that enormous backlog of projects.

By: Mike

Mike — Fri, 02 Nov 2007 20:13:38 +0000

While I agree wholeheartedly that leadership, cultural/motivational awareness, and project selection will increase the chances for a successful project – offshore or internal; I still wonder if the theoretical economic benefits of offshore development really outweigh the demonstrable risks.

It seems to me that if we have good leadership that understands the motivations of the individual team members and we’re working on an interesting project – well why would we want to send it offshore and keep the soul sucking work for ourselves?

If the work can be sent offshore I can probably find really smart folks that would be happy to telecommute and would also be no more than 2 time zones away. I’m just saying…