Why Software Development Projects Fail, Part V: Distributed Teams - Page 2

Apr 15, 2009

Drew Robb

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

Page 2 of 2


0 Comments (click to add your comment)
Comment and Contribute

Your comment has been submitted and is pending approval.



 (click to add your comment)

Comment and Contribute

Your name/nickname

Your email


(Maximum characters: 1200). You have characters left.