In the past few years I’ve had the opportunity to work with a number of clients on projects that have involved collaboration between onshore design and offshore development teams. A couple of areas that have struck a chord are how rarely the onshore/offshore relationship is managed effectively and even more so, how long it can take a project to fine-tune this model to the point where it really starts to provide tangible, positive impact on the delivery.

Offshoring development is not something Deloitte Platform Engineering is interested in offering, so I won’t try to argue the pros and cons of adopting such a model. We concede that the viability of such an approach depends on particular circumstances, so when a large project involves offshore work, here's some common pain points and strategies to overcome them.

Talk, Talk, Talk

An obvious and most important point - opening the communication channels early and properly. ‘Early’ meaning getting your onshore and offshore teams communicating as soon as the teams have been established, introducing team members and building relationships. ‘Properly’ meaning make sure the appropriate communication media is available and being used effectively. The benefits of having access to a good all-in-one communicator (Instant Messaging, desktop sharing, video/audio conferencing) such as a Microsoft Lync or Google Hangouts should not be underestimated. If you don’t have access to a unified communications tool like this, other good options include Webex, join.me, Skype and a myriad of other free and bundled IM clients available on the market.

Call me old-fashioned, but there is simply no substitute for the human element. If you have access to tele-conferencing or even better video-conferencing facilities, make use of them. Regular - ideally daily - calls between teams should form a crucial part of the project.

Track Everything

Using a good issue tracking system (such as Atlassian’s JIRA) to allocate and track tasks across teams is an important first step. Even more important is making sure it’s being used effectively and consistently. Simple behaviours such as ensuring everyone is updating the status of allocated tasks at the end of each day can reduce a lot of confusion and time-wasting. Add comments and questions directly to a task rather than emailing – that way the history and status of that task is clear to anyone who works on it.

Don’t Skimp on Design

‘A stitch in time saves nine’ – or in development terms ‘effort spent in design is time saved manyfold in development’. This is never more apt than when working with an offshore team. Agile methods may have made detailed design seriously un-cool but, particularly if there are time differences involved, wasting long periods hurling emails across the globe because of poor or under-detailed designs can be a major cause for headache. It is crucial to ensure designs are detailed, accurate and consistent across components.

Detailed design doesn't have to mean heaps of boiler-plate documentation. Centrally documented naming and coding standards, reference models and design patterns can slim down component designs without sacrificing clarity. For example Deloitte Platform Engineering's SODA methodology provides a unified design model without much overhead. Investments in unambigious design models pay significant dividends as projects push through development and testing.

Lead by Example

If you’re going to ask your offshore team to do something, make sure the same standards are adhered to elsewhere. The use of templates, sample code and other physical artefacts is generally a far more effective way of defining standards and best practices than endless piles of 'do-this, do-that' documentation.

Don’t Assume

It’s unrealistic to assume that an offshore team will be able to make informed inferences in cases where a design is either under-detailed, or simply not explicit - particularly if they have had little or no direct involvement in its generation. Given that resources for offshore teams can often be taken on-demand from large pools of staff, personnel are likely to rotate in and out regularly and skill levels will often vary and change throughout the team from time to time. It’s important that designs are at the appropriate level of detail to cater for this.

Keep the Team Busy

In the early phases of a project you don't want a large offshore team sitting idle so consider a staged ramp-up of resources while you proceed with design, defining templates and standards and building test frameworks. Alternatively, the onshore and offshore teams may collaborate on the development of this infrastructure - but you need to "own" the standards. However you do it, early attention to these artefacts will pay off in the long term as they are notoriously neglected activities that if done well, can greatly improve offshore productivity.

This all might seem like pretty obvious stuff but past experience shows that without the appropriate measures, working efficiently and producing quality work in an onshore/offshore environment can be a major headache for all parties. With a bit of planning and a few simple tools and principles, creating the right balance early on is very much achievable.