Requirement #3: Match the Project to the Team
You can put lipstick on a pig but it doesn’t do much good. It’s not much to look at, and it annoys the pig. You can assign any old set of tasks to the offshore team, but if they CAN’T succeed at the project, or DON’T CARE about succeeding at the project, you won’t get much value and you’ll have ended up annoying the team.
Agile methodologies have taught us all the benefits of keeping the customer tied into the development process. We know the offshore team will have less of a context for managing changes and usually will average less years of experience than the corporate team.
That doesn’t mean you can try to do the “thinking” for them. There are as many smart people in Moscow and Bangalore as there are in Silicon Valley, just fewer Starbucks.
There are two common failure modes in defining projects for the offshore team:
- Asking a remote team to solve a complex problem the customer might not understand; or
- Asking the remote team to grind through endless bug fixes to a stable product line.
In the first, it’s easy to see that the customer isn’t getting any happier with each release. In the second, the failure will be the Dutch Elm Disease of application development: developer turnover.
Developer turnover comes from multiple sources, many of which you don’t control. Given the heavy cost of recruiting and training new hires, it pays to stay on top of the factors you do influence. Everybody wants to be successful, and will stay on a successful project longer than on an unsuccessful one. So pick the project wisely.
Great projects for remote teams are ones that have very well defined deliverables but ambitious long-term goals. Projects like cloning capabilities of one system to another, changing platforms or improving performance of an app, all benefit from clarity of definition and sufficient technical challenge to keep the remote team productive and engaged.
Epilog
In my humble experience, meeting these three requirements eliminates the additional risk created by an offshore development group, and reduces the problem to the same set of risks as an onshore development group. Not that onshore development is easy.
Are three requirements really all it takes? Yes, because all three are meta-requirements that cover the most important challenges of offshoring. In fact, a superstar remote team lead (Requirement #1) can be enough in itself to deliver success. Superstars are so hard to find we can’t count on finding them. That’s why you need to maximize your success rate by meeting requirements 2 and 3 as well.
Bonne Chance, Bueno Suerte, Удачи, and Good luck!
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…
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.
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.
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.
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
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.
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.