Topic: Managing those far away
PM Clinic: Week 19 discussion summary
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
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.
Mark Colburn, Neil Enns, J Kremer, Scott Berkun (editor)