While my blogs here are mine, and not my employer's, and are always quite independent, this one is even more so. And I'm not even certain I have an opinion yet on this topic, I'm just kinda thinking out loud. Ok?
I was reading an article in the Economist, "New Georgraphy of the IT Industry" (for which I don't have a URL, sorry), talking about cost savings in moving tech workers offshore (eg. to India). The way the article lays it out, the workers and their local infrastructure in India cost about 25% of those in Silicon Valley, and even after factoring in the additional remote infrastructure costs (telecoms and data connections) there is a saving of around 30% on loaded labour costs.
But there are additional costs that aren't addressed by this article, nor in any other source I've read.
A small additional cost is some amount of international travel for business folks bidding jobs, and leads of the teams that eventually do the work.
But more significant is that while all discussions focus on labour and infrastructure cost (savings), little appears on productivity. Agreeing for sake of argument that remote and local personnel are equally productive individually (since if they weren't that would be a different sort of problem), what about the direct impact of remoteness on team productivity?
My own experience is mixed on the subject. I've been involved in a handful of projects over the past 15 years in which teams were split between local and offshore. But in this very anecdotal sample size of 1, trends (if we can call them that) have emerged:
Offshore works well for extremely well defined projects or portions, where they can run full speed with few remote consultations.
Offshore works poorly when the project involves any notion of research, as in:
- we're not precisely sure what the problem is; or
- how it will be solved; or
- whether changes for a customer will involve changes to design.
This leads to a few minor draft conclusions. One is that, absent unusually well developed communications skills or remote team paradigms, remote (and especially offshore) splits are not particularly appropriate for startups, or for new product teams in established companies.
Another is that remoteness should work better when teams adopt some sort of formal design methodology. This means nailing down interfaces between different subprojects, but it also means thinking through problems more completely early on in the project to codify the design so there is less need for churn later. This worked well in one of the remote projects I've been involved in.
It will be interesting to see, over the next few years, how web services will help or hinder this notion of formalism. On the one hand, they allow that nailing down of interfaces. On another, the mindset surrounding web services is that the interfaces can and will change, but since they self-describe the users of the interfaces can tailor more easily. So perhaps web services as a formalism is really about assisting in the remoteness decouple. Don't know. It'll be interesting to watch things evolve.
For completeness, just because my stream of thought got me to thinking about web services and team productivity via the remote and offshore path (only because I started from the Economist article), doesn't mean remoteness or offshore are necessary to thinking about the two. Quite the opposite, actually. So on reading this, please don't think I'm slamming remote teams - I've worked with several, and those projects have at times been very successful. As have local projects.
I'm quite interested to hear other opinions on the productivity issue, and on whether web services will help this problem. Feel free to comment below, or send me a personal email to glen at glen-martin dot com.
Another is that remoteness should work better when teams adopt some sort of formal design methodology. This means nailing down interfaces between different subprojects, but it also means thinking through problems more completely early on in the project to codify the design so there is less need for churn later. This worked well in one of the remote projects I've been involved in.
It will be interesting to see, over the next few years, how web services will help or hinder this notion of formalism. On the one hand, they allow that nailing down of interfaces. On another, the mindset surrounding web services is that the interfaces can and will change, but since they self-describe the users of the interfaces can tailor more easily. So perhaps web services as a formalism is really about assisting in the remoteness decouple. Don't know. It'll be interesting to watch things evolve.
For completeness, just because my stream of thought got me to thinking about web services and team productivity via the remote and offshore path (only because I started from the Economist article), doesn't mean remoteness or offshore are necessary to thinking about the two. Quite the opposite, actually. So on reading this, please don't think I'm slamming remote teams - I've worked with several, and those projects have at times been very successful. As have local projects.
I'm quite interested to hear other opinions on the productivity issue, and on whether web services will help this problem. Feel free to comment below, or send me a personal email to glen at glen-martin dot com.
[Comments from my previous blog]
1. a reader left...
I'm thinking Y2K. Go make my 2 digit four digits.
> Offshore works poorly when the project involves any notion of research
Requirements such as go build me a booking or pricing engine are a little more complex and require considerable analysis and communication. I couldn't agree more with your statements.
Jason
Wednesday, 30 July 2003 6:26 pm
> Offshore works well for extremely well defined projects or portions, where they can run full speed with few remote consultations. I'm thinking Y2K. Go make my 2 digit four digits.
> Offshore works poorly when the project involves any notion of research
Requirements such as go build me a booking or pricing engine are a little more complex and require considerable analysis and communication. I couldn't agree more with your statements.
Jason
No comments:
Post a Comment