Posts Tagged ‘Offshore’

Three Absolute Requirements for Successful Offshore Application Development, Part 3

November 2nd, 2007 by lorne cooper
Share|

 

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:

  1. Asking a remote team to solve a complex problem the customer might not understand; or
  2. 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!

8 comments »

Posted in Best Practices

Tags:

Three Absolute Requirements for Successful Offshore Application Development, Part 2

October 31st, 2007 by lorne cooper
Share|

 

Requirement 2: Business Interests Must be Aligned

There’s an old saying about the game of poker: if you look around the table and can’t figure out who’s the fish, it’s you.

Let’s face it: they’re doing it for the money. Just like you. But you’d better understand how they make money in the business relationship or you’re going to feel like you’re the only one not making out.

There are lots of companies that reward late projects and punish early ones. Not intentionally, of course. Maybe you know can recognize who this is:

When projects were late they would respond by creating special incentives, adding people to the project, and increasing the project visibility. When the project was doing well, they’d pull people off to fight other fires, take the best people away from the project leader to work on other projects, and management would stop attending the project review meetings.

Next project comes along, and the offshore project leader comes in with an optimistic schedule. You do the math.

Hey, if you’re reading this blog, you’re a smart person. You know you’re not going to change their culture, so maybe you should spend some time to learn to deal with it. Sure, people are people, and application developers in Moscow, in my experience, have more in common with application developers in New York than they do with factory workers in Minsk, but when people get in groups their behavior changes. That “group dynamic” differs depending on their cultural background.

In the US and northern Europe, senior application developers can follow a technical career ladder and get increasing career respect and satisfaction from being architects and CTOs. At least that’s the theory. In much of Asia, career status is all based on the number of people that report to you in the hierarchy. It’s an up-or-out philosophy that makes it hard for an Indian engineer to explain to his mother why after five years with the company he’s still not a manager.

When working with an outsourcing company, if you don’t figure out their model and how they get paid, it’s like playing poker blindfolded. Many companies build a model based on rotating junior people through their company on standard projects. If you need junior engineers to implement an e-commerce Web site, it’s probably something they will do many times and can do with the talent on hand. If you need people to figure out how to do something unique, your outsourcer might have all the brains in the world, but it just isn’t going to make business sense for them to put their technical leads on the project, when they could be running other e-commerce Web site apps. It makes as much sense as buying a French car or a German perfume.

One of the hardest problems in assessing professional job productivity is identifying the impact of quality. If the reward system is around requirements trace-ability and meeting schedules, quality is going to suffer. If you try to make quality a hurdle to be overcome, you’re going to spend such a long time in requirements specification you are never going to get a payback from offshoring the application development.

There are two things smart companies do to deal with this alignment dilemma:

  1. Short iterations, e.g. a two-week Agile process
  2. Remember Requirement #1, and bring the remote team lead back to corporate frequently to maximize alignment with the leader.

In Part 3, Don’t Annoy the Pig.

3 comments »

Posted in Best Practices

Tags:

Three Absolute Requirements for Successful Offshore Application Development – Part 1

October 25th, 2007 by lorne cooper
Share|

 

Failure teaches a man many things: don’t mix beer and tequila, dates don’t want to hear about your ex, and good software isn’t developed offshore. But success can be a better teacher, and a little failure combined with some success is best of all. After fifteen years doing projects in India, England, Israel, Canada, Moscow and the Ukraine, I’ve got the scars to prove I’ve learned a few basic requirements.

Requirement Number 1:

Leadership is everything. In case you missed it, Leadership is EVERYTHING. And I don’t mean sitting on the phone in the corporate office. I mean the person who represents everything you want to achieve and sits in that remote office having to drill the corporate mission into people who have little respect for corporate, and strongly suspect that the feeling is mutual.

The Roman Empire lasted for a thousand years, which might be longer than your project is going to last. The job with the most difficult requirements in the Roman Empire, tougher than Senator, tougher than General, was Governor of a remote province. Romans knew that the Governor had the toughest job. He had to convert his provincials into people who wanted what Rome wanted, people who would profitably grow Rome’s Empire, not people who would revolt and suck up Roman resources.

There are few application development jobs tougher than managing a remote development group. And there are precious few people that can do it. It takes great leadership, as well as management ability, which is hard to find.

Next, in Part 2, if you can’t identify the fish at the table, the fish is you.

Lorne Cooper

2 comments »

Posted in Best Practices

Tags: