Topic: Managing those far away

Compiled: 3/10/2005

The Situation:

I’m about to start development with an offshore group of three developers and one project lead. The project lead is based in India but will travel to my office in the US at various milestones. The project is a website redesign for an external client and requires connectivity to their existing database. Beyond my specific situation, what are some of the common traps of working with people who are far away, either in other office locations, or in foreign countries? How can I manage this project so that I avoid as many of them as I can?

– Anonymous manager person, somewhere unknown

Advice:

The less frequent your communication with someone, the more time you need to invest in it. Specifications and e-mails need to be written with a level of craft and care uncommon among those who share the same hallway.

The list of to-do’s for managing remote work:

• Have well defined points of communication at least weekly, if not daily. (Someone, probably you, will have 5am or 10pm phone calls).
• Use screenshots and layout things specifically.
• Use prototypes or demos to demonstrate flow.
• Make sure that your screenshots/prototypes exactly match your spec.
• Make sure that your error conditions, messages, and flows are all spec’ed
• Make sure that you don’t have big assumptions in your spec like “of course, all standard windows semantics will be supported (minimize, resize, restore, etc.) and they will all be run on a separate UI thread so they are responsive”.
• Make sure that you have performance goals specified in the spec.
• Watch cultural issues. Some cultures are very reluctant to bring up issues or complaints.
• You will be frustrated by your inability to take the common shortcuts you take with people down the hall.
• For foreign workers, the definition of test & development is less formal. Your testers may have no formalized test training (Test plan? what’s a test plan?). Check your assumptions and expectations early.

Turn around time

Colburn pointed out that the communication cycles are much longer than most team leaders are used to:

Day 1, you identify the issue, craft a response
Day 1 eve., India gets the message, asks some questions Day 2, you review the questions or initial implementation, and provide feedback
Day 2 eve., India reacts to the clarifications
Day 3, you review the final implementation

This means your response time to crisis/change is much slower than you’re used to. This is another reason for daily phone calls. You are not driving a porsche anymore: you’re now in a Ford Mustang that’s hitched, via a long cable, to a mid-sized trailer.

Contributors

Mark Colburn, Neil Enns, J Kremer, Scott Berkun (editor)

PM Clinic discussion group

General info
How to join
Full archives
Other web forums