Conrad Weisert, August 3, 2011
The following describes a composite of several real projects from decades ago. But everything described actually happened.
I inherited an application development project that was of top importance to our manufacturing company. Here's what I knew:
I don't have to tell today's reader the painful and politically sensitive tale of what ensued, but I'll just comment on the impact of the geographically disperse team.
Those four locations were where the client organization had factories or other facilities that were going to use the new application system. Someone had assumed that securing the participation of programmers from the client organizaion's own staff would strengthen the clients' commitment to the success of the project.
No one had thought to confront the differences in skills and abilities between a mainstream data-center programmer in Chicago and a peripheral support programmer in South Carolina. Furthermore, I was warned that by now any attempt to diminish the roles of the programmers in outlying locations would be taken as an insult by local management. We were committed to the equal status of all team members.
Few of the programmers is different locations had ever met, and every delay or misunderstanding in passing work among them was received with derisive comments about "those idiots" in the other location. In those days, long-distance telephone calls had to be booked though the company operator, and E-mail (we called it "message switching") required filling out a form. We all knew the names of the other team members, but we rarely communicated with them in real time.
Well, we survived, barely. I brought the two New York programmers to Chicago for the duration. Then I appointed the Indianapolis programmer to be the project "module administrator". That caused an uproar—no one knew what a module was! I managed to explain the critical need for the function I didn't dare call "librarian".
From then on I spent my time doing project planning and control (and remedial design work) in Chicago, visiting Indianapolis and South Carolina infreqeuently. With a few changes we formed an excellent team in Chicago. The project, after mutltiple "slippages" and acrimonious disputes, was eventually viewed as a marginal success.
I swore off geographically dispersed project teams for a long time.
Of course today's experienced project manager would never make the naïve mistakes described above. At the very least we'd expect to review the qualifications of prospective team members.
Today's project manager, however, is under even more pressure to form geographically dispersed teams. That pressure comes from two sources:
Modern communication technology, some claim, including E-mail, conference calls, and video conferencing, has rendered physical location almost irrelevant. We may never meet our teammates in the flesh, but we can still form close working relationships with them.
That's a comfortable theory. Does it work in practice? The answer is sometimes, and the burden of proof falls on those who claim it does.
If your project needs five programmers, there's no point in using offshore personnel. Communication problems and skill evaluation would swamp any possible labor-cost saving.
But if your project believes that it's going to need two hundred programmers, the temptation to engage most of them in cheap-labor countries can be irresistable. You may or may not be able to deliver high-quality on-time results, but you'll never form the bonds within the team that assure ongoing enthusiastic commitment. You don't know your overseas team members, they don't know you, and they may not even know one another. Every senior-level team member is just a voice on a midnight conference call, and you rarely communicate with the junior members directly.
Even when the whole project team lives in the same area, members may want to avoid coming into the office every day. Commuting time, especially in newer cities that lack transportation infrastructure, keeps expanding to a greater portion of our workday. The distractions of working at home may be more than offset by the saving in unproductive and tiring driving.
Such flexibility is attractive and may yield improved individual productivity. However, it also contributes to a sense of unfamiliarity and distance within the team, sometimes edging into distrust and suspicion. We work most effectively with people we see every day.
A sensible compromise is to designate two days a week in which the entire project team is working in the office. Although the purpose is to foster familiarity and mutual trust, the emphasis is still on getting work done, and the facilities and atmostphere must be strongly supportive of that.
A co-location risk
A reader pointed out one possible downside to everyone's being in the same place at the same time.
Sometimes team members may be tempted to substitute casual conversation and oral agreements for rigorous documentation, leading to potential miunderstandings and serious problems later in the project. Naïve team members who are recent over-zealous converts to the so-called agile methodologies are especially likely to succumb to such temptation.
A combination of attentive project management and sensible development methodology can avoid that pitfall.
I'm eager to collect information about real experiences, both good and bad, with dispersed
teams and telecommuting. Send me (
your experiences and opinions, and I'll pass them on to readers.
Last modified 7 August 2011
Return to management articles .
Return to IDI home page.