Over the last few years, there have been a lot of failed offshore projects. Many reasons:
- Time zone misalignment (and little if any staffing schedule overlap)
- Takes a long time to reach an offshore development location (>36 hours travel time one-way)
- Lack of attention paid to cultural differences (both sides)
- Lack of attention paid to business differences (both sides)
- Lack of visibility / transparency and ultimate trust (both sides)
- Lack of attention paid to the importance of over communicating (both sides)
How is Nearshore any different?
- Time zone misalignment isn’t drastic, so there is greater opportunity for staffing schedule overlap.
- It takes less time to reach a Nearshore location: (one-way is <16 hours), so it’s easier to get people face to face.
- And at times there are more familiar cultural references.
It’s tempting to think that Nearshore offers an easy answer to the problems that have plagued offshore. But in my experience, it does not provide a sliver bullet .
Let’s face it. A co-located, full life-cycle team incorporating business members is a superior model in a perfect world. But there are considerations regarding cost, talent location, and the allocation of scarce skill sets which must be addressed. This drives distribution of teams sometimes between US based offices, within the Americas, or extended through-out the world.
Nearshoring is not the ultimate answer. It’s generally a robust combination of communication and technical best practices that brings the ball over the goal line. At ThoughtWorks, I have been witness to some of the most amazing, large-scale enterprise application development work ever, all performed 100% by geographically distributed, offshore teams.
So what is the secret? Simply put, there are really two main areas to pay strict attention to. The rest will likely sort themselves out over time.
Building team unity is the first step in the process.
– Over communicate. Remove all barriers for written and spoken conversation. Accommodate the distant office with times that make your personal schedule shudder a bit. Work on their schedule. Establish clear communication plan upfront and stick with it.
– Make the investment of time into your new team. (Yes, they are your team now.) If you are nearshoring development, make use of the time-zone advantage through video-conferencing, virtual meeting-rooms, and collaboration software.
– Bring team members from distant locations to your corporate office. Better yet, travel to distant office locations. Nothing like immersing yourself in the local culture to better understand your growing team’s social and work culture
– Crank the project visibility knob to 11
Building an optimal and automated project technical framework is second.
– Institute the proper use of software tools for team collaboration and business case communication
– Employ established build management and deployment best practices.
– Establish automated testing practices
So getting back to the title of the blog “Nearshoring: Our friend or lesser evil?”, which is it? At the risk of not answering the very question I raised at the beginning, my assertion is this……. Distributed development (what I prefer to call it) is a lot of work. Near or far you will be met with challenges, but like with all things, challenges often times precede the greatest rewards. Furthermore, a Nearshore team can fail for all the same reasons as an Offshore team because where your people are geographically situated is less a critical success factor than how effectively you are able to get them to work as a team.
Sid Pinney is an Offshore/Nearshore Principal at ThoughtWorks. In his current role, Sid focuses on successful distribution of development work to ThoughtWorks’ multiple offices spanning Asia and South America. Sid can be reached at email@example.com.