Distributed Development (Part 2)

By Bruce F. Webster  |  Posted 2008-07-17 Email Print this article Print
 
 
 
 
 
 
 

Bruce F. Webster's advice on how to have the most success in a distributed team environment for IT projects.

Last time, I talked about all the challenges that surface when you attempt distributed software development, that is, having an IT project team being spread out over a wide geographical area. Simply put, it’s tough to do well, if at all, for a variety of reasons, including problems with communications among developers, maintaining conceptual unity of the system itself and managing a dispersed team.

Nevertheless, you may have strong reasons to do distributed development; in some circumstances, you may have no other choice economically, politically or otherwise. So if you’re doing to do it, how can you increase your chances of success and quality?

Besides my own experience on several projects with distributed development, ranging from a software startup to the global Iridium satellite telephone project, I solicited feedback from two long-time colleagues—Bruce Henderson and Deirdre Poeltler—and also got comments on the same subject on one of my Web sites. Here’s a summary of the key factors for achieving success in distributed development.

1. Use your best IT engineers for remote development.

I have written elsewhere about the attributes that make up an outstanding IT engineer: talent; education; professionalism; experience; and skill (“TEPES”). If you have individuals or small teams that are working remotely, you want to be sure these are your best people. Note from the list of attributes that “best” doesn’t necessarily mean “brightest” – it means most disciplined, trustworthy and self-motivated. You want people who can get the job done with a minimum of supervision and management, and who have a desire to do well and look good.

2. Small is beautiful.

As a commenter on my Web site noted, overall project staffing size is a key factor in success: The fewer people involved, the more likely the project will succeed. Of course, the irony is that the smaller the team, the more feasible it would be to relocate them to all work under one roof in the first place, but still, keep the size factor in mind.

3. Bring the team(s) together as often as needed.

Building a cohesive development team is difficult enough when all the members are under the same roof; it’s that much harder when there’s significant physical separation. Set a regular schedule to gather everyone at one location, and make sure that there’s time for socialization; you want your team members to like and trust one another as much as possible. If the project is too large to truly bring everyone together, then make sure you bring key personnel from each team together. Note that in the relatively short period—less than six months—that I worked on the worldwide Iridium project, I attended two such meetings: one in Phoenix for representatives of all North American teams and one in Hong Kong for representatives of the entire global effort. 



12>
 
 
 
 
Webster is Principal and Founder at at Bruce F. Webster & Associates LLC. He works with organizations to help them evaluate troubled or failed information technology (IT) projects, or to assess IT systems and products for possible investment/acquisition. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan.
 
 
 
 
 
 

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters



















 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date