Offshoring Product Development: The Proximity Conundrum

The biggest ingredient of successful off-shoring has got to be how well business requirements get translated in a way the technical development fraternity understands it. This rather low level need grows up into understanding business drivers, customer needs and market segmentation later as the off-shoring matures (I hope to write about that some other time). It all starts with the translation bit, though. There are three models (two-and-a-half actually, but more on that later) that should lead to effective off-shoring.

All the models have three components:

  • Business: They bring home the bacon and write the pay-checks. They spend most of the time understanding customers, the competition, emerging trends and finding out innovative ways of satisfying customer wants. All requirements originate from this group though asking them to provide granular detail would be a criminal waste of their time. This function is never “out-sourced” though it can be off-shored to captive centers
  • Technical Development: They build the software code. Included in this are software architects, designer, programmers and testers. Oh yes, project managers too.
  • Translators: They are reason for this post. Translators are those who understand the business requirements in whatever shape and form business articulates and converts that to whatever shape and form Technical Development understands.

The question is where should the Translators reside.

Both 1 and 2 above are valid models of placing the Translators. And the mistake people make is choosing one model over the other. The trick lies in starting with 1 and then replacing it migrating the model to 2. Here is why

  • Businesses that have never dealt with Translators don’t know how to. And if that team is a few oceans away, they never will. The endeavor here is to inculcate a behavioral change with Business and for that to happen it is imperative the the Translators are in closer proximity to them. At least initially
  • The communication load between Business and Translators initially will be very heavy. It is a risk to experiment with asynchronous communication methods then
  • Over time Business will become more at ease with Translators (and vice versa) and the communication flow will slowly begin to skew towards Translators and Technical Development. At around that time, the Translator function should be migrated towards proximity to Technical Development

There is a third model as well, usually taken up by companies with deeper pockets.
I personally do not subscribe to this one because it has one arrow too many for my comfort.

Communication is the most critical aspect of off-shoring and adding one more arrow adds significant risk of exploding (and [hence] breaking down) communication channels (Immortalized in The Mythical Man-Month by Fred Brooks).

Technorati Tags: , , , , ,

2 thoughts on “Offshoring Product Development: The Proximity Conundrum

  1. […] Now take the legal world. Legal practices tend to significantly differ across the world. Low market democratization makes it necessary that legal products products for say the American legal industry is built pretty close to the market – somewhere in America. The alternative is a bit messy. Keep business close to the consumption and development close to where development talent is abundant. Managing this divide, especially across continents, is a challenge. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s