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