Why Software Development Projects Fail, Part V: Distributed Teams

By Drew Robb

(Back to article)

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.”

Establishing strong, ongoing communication between the client and the outsourcer is critical to making the customer comfortable. “Transparency about what is going on and how far along we are brings down uncertainty so the customer doesn't feel the need to micromanage the project,” said Tata's Neemuchwala.

Beware of the Assumptions

Throughout the project, you need to be on the watch for any unstated requirements or cultural differences between the customer and the developers.

“There are different requirements and expectations of customers in different parts of the world,” said Neemuchwala. “We have customers in Japan, Korea and China who have a very different expectation on requirements, what they need to specify and what they can expect from a provider compared to American customers.”

Ten years ago, Tata developed a Web-based application for the Thai subsidiary of a U.S. company. TCS had already built such an application for the parent company. The contract called for creating a similar application that was attuned to the Thai market and Thai business processes. But, the contract, the requirements, the documentation and all communications throughout the process were in English ... oops.

“We were able to take the best practices and lessons from the parent and we expected it to be a very smooth delivery,” said Neemuchwala. “But when we delivered an English-language website, there was a big shock. Though it had never been mentioned, they expected by default that anything delivered in Thailand would be delivered in Thai.”

Since that time, TCS always clarifies what language will be used as part of the requirements process. Neemuchwala also said that early prototyping is a good way to discover any unstated ideas the users have that are different than what the development team may have. It all goes back to an earlier article in this series: getting the requirements right. If you don't have good requirements, development scenarios and test cases may not align with what the customer expects.

“Different development teams and cultures may not agree in their interpretation of what is needed, which creates problems for everybody,” said Brian Cook of Cook Enterprise Corporation. “If your requirements are unambiguous, you at least have a fighting chance.”