One of the biggest issue in offshore software outsourcing projects is communication.
Usually you have teams located in different cities, regions, countries, or even different time zones. The new age of solving the work related problems through an app / tool is here and in the case of long distance teams, we can pretty much count a few of them that are good and efficient (mostly, few of them used together): Slack, Trello, Skype, Google Drive, Atlassian HipChat, Podio, Quip, and so on.
OK, so it’s great that we have all these tools to use internally, on our company’s offshore software outsourcing projects, but what if we want a customer to participate in our team collaboration, in order to have a more flexible, easy to check status and progress way to communicate and collaborate? Well, at ConturSoft, we are kinda integrating the customer in parts of our internal team collaboration processes but we don’t quite have a specific, targeted, customized solution for this (at least not one — good one — that I could find, anyway).
Make it part of your “process” to involve the client at every step of the way. Finding out something cannot be done late in the delivery cycle is more painful than finding out shortly after seeing the initial prototype.
If you can work with your client in a more agile fashion, you can make many small changes and trade-offs more often, fine tuning the implementation as you go along. Before either of you know it the feature will be done, and there will not be any shock that it does not meet expectations.
Another way to help with this problem might be to focus more on the value that your client wants to achieve from some particular feature, rather than the implementation (prototype). Consider capturing the requirements in the form of user stories or use cases, each with a clear goal or expected end result. Make sure your client agrees with those expected results. This helps to direct the focus of requirements validation away from the specific implementation details and onto the end result. The downside to a prototype is that if the end product does not look just like the prototype the client may see that as a failure, or view it as incomplete, even if the desired goal is achieved. A mix of both prototypes and stories or use cases is probably necessary; just don’t expect to capture all of the requirements in a prototype.
Being agile is not to say that you do not need to understand the big picture early on and, being offshore software outsourcing projects, is not an excuse for ignoring things such as performance or architecture requirements that must typically be built in from the very beginning. However, for either you or the client to understand and document “all” of the requirements up front is not realistic. Have regular conversations, make decisions and trade-offs on a regular basis, and hopefully you can avoid delivering a sudden surprise to your client, when it does not turn out just like the recipe said it would.
Next big thing? Automatizing this process of communication and collaboration, all the way!
