Add to that the fact that the wrong UI can give rise to the wrong business process altogether. Lots of times people build their processes around technology instead of the other way around.

UI is a big deal!

Sounds like your business requirements were poorly designed and documented – this only makes offshore coding harder.

Try the “Eastern Bloc” next time for a better experience and people who really know how to write and run agile code projects.

Involve your end users in the requirements gathering process.

Map requirements to features then to specs then to test scripts.

Then create a rapid release schedule based around incremental delivery of features and functionality.

Then put twice as much effort than last time at communications and management.

1. One of the team contains the expertise and the other team is the implementation team. This works if the problem domain is well known to the expert team and the expert team has created a very detailed requirement / design document. We’re basically talking waterfall here – all design decisions up front and rigorous. In this case the implementation team has something to build on, but the expert side must follow the day to day development closely. It helps if the implementation team has some experience in a similar problem domain.

2. The distributed team have different roles and/or different expertise. For example, right now I am working on a project for a fairly large operator in the US. We have the development team in Europe, the custom relation part is in the US; product management is handled jointly and in a fairly iterative manner. The domain expertise is distributed and there is quite a bit of overlap between the teams. This is going pretty well, even if the two teams have never actually met face to face.

The most common breakdown in these kind of working relationship is when there is a misunderstanding of what the “other side” knows. The experts think that the other side knows more than they do and / or the implementation team underestimate the complexities of the the domain expertise or overestimate their own understanding of the domain.

I do think that your analysis of why this failed is accurate (i.e. underestimation of the value of the domain expertise) and off-shoring had nothing to do with it, even if it seems to have been poorly managed.

This was an interesting read. I think we sometimes underestimate the value of learning from things that go wrong (for whatever random reason) – even if those stories are often much more valuable than bragging about things that go right (for even more random reasons).