Why Software Development Projects Fail, Part V: Distributed Teams

This series of five articles takes a closer look at software development, the reasons for failure and how to avoid them.

As we wrap up this series on managing software development projects, one final factor to consider is location. The Internet, messaging, collaboration software and videoconferencing make it easy to unite users and developers into global virtual teams. But, while the networks may operate on the same languages and protocols, people often don’t. Time zone, culture and language differences increase the chance of miscommunication and errors. This even applies when talking about a company’s own internal development team.

Jon Hughes, VP of the Technology Solutions Group for Robbins-Gioia, for example, lives and works in New York, but his developers are primarily in the Washington, DC area. He can access the software configuration management system to see who is working on which files. But it can still be difficult to lock down times to discuss the project with the programmers.

“You would think that technologists who are building these collaborative technologies and are using email, voice and videoconferencing would be the ones who (would) not have a problem with it,” said Hughes. “Building a culture that promotes communication and collaboration is very important. Without that you will be behind before you know it and there will be no way to recover.”

But when software is being developed by an outside vendor, particularly when that vendor is half-way around the world and speaks a different language, the complexity grows significantly.

“Expectation management is key when organizations transition from managing developers sitting in cubicles beside the users to outsourced software development,” said Abid Ali Neemuchwala, VP and head of Global Process Excellence for Tata Consultancy Services (TCS). “When they are local, you can forget to mention something and then just walk over and tell them. That doesn’t work when you are talking to people or managing people that are a few thousand miles away.”

Despite that potential difficulty, billions of dollars of remote software development is completed each year and best practices have been established over the past decade. Let’s look at a few of the primary best practices:

Culture of Communication

The primary factor for overall success is to use whatever means necessary to improve the speed and quality of communication between all participants.

“When you manage a distributed or remote team, the first thing you lose is transparency, and, therefore, control,” said Mikhail Bykov, CTO of Luxoft, an international IT services firm headquartered in Moscow. “Another is team spirit, which is hard to maintain when you are thousands of miles and 11 time zones away. If you don’t care about these issues, you’ll soon see everything falling apart―non-motivated teams, testers not talking to developers, seeing management as an opposite side instead of the same.”

Project management, collaboration and software tools can and should be used on any development project, but they are not a substitute for traveling and meeting the team members in person; particularly as the project gets off the ground. “An initial face-to-face meeting, joint kick-off and project start are crucial,” said Bykov. “Then you need to visit the team at least once every few months.”

Once the team has met, you need an environment that allows all the team members to work in the same system, with the same code and artifacts, have easy IM and voice communication, and have daily status discussions. Bykov also advises having part the development team stationed at the client’s site to ease communications. “When some members work at your client site they can provide a good bridge between the client and remote team as well as simplify time-difference issues. This allows us to successfully practice distributed, agile development, which is a very challenging task.”