Here we try to show the importance when we decide to choose one Outsourcing paradigm, like nearshore or Offshore.
Offshoring, whether it be to a distant continent in a completely different time-zone, or a nearby nation that goes to bed when you do, ultimately seeks gains in efficiency and costs. Think about it? If you could achieve developer rates as competitive as those of Asia in your home city, would you send your work abroad? Probably not. Gains in cost are so dramatic that outsourcing offshore is a reality that has come to stay, which begs the question: "with so many destinations to choose from, where should I go?"
Countless studies still have India claiming the top-of-mind outsourcing spot. After all, India's solid technology education and relative availability of English-speaking engineers, coupled with very low costs, allowed the country to give birth to the IT outsourcing revolution in the end of the 1990s and the early 2000's. However, many factors have changed since outsourcing's early days, with alternate destinations becoming more relevant for many types of clients. To begin with, demand for outsourcing to India has overheated the country's market for talent, to the point that it is typical for clients to experience team churn-rates of 20 to 30% a year. Furthermore, competitive pressure coupled with strong economic development has made India's rate increase dramatically over the last five years, reaching parity levels with those of Latin America as well as some Eastern European countries.
The above factors, together with the rise of high-quality (i.e. CMMi 5) vendors in other destinations, have increased the relative weight of other variables when it comes the time to make an outsourcing decision. One aspect of critical importance in choosing a destination country, in our view, is whether one chooses to nearshore or offshore. By nearshoring, we mean choosing to outsource one's IT services to a location that shares a similar timezone. For a US-based player, then, nearshoring might mean sending development work to Canada or Latin America. For a European player, nearshoring might mean sending work to the Ukraine. (Because PSL serves firms mostly in North America, we will speak from our perspective as a Latin American IT services provider).
To understand what is at stake, lets review what undergirds a traditional IT outsourcing process: Born out of the practices that arose in the fulfillment of large contracts (NASA, US DoD, etc), traditional software development tends to rely heavily on formal documentation and the production of Big Requirements Up Front (BRUF). Predictive estimation methodologies such as RUP rely heavily on this approach. Under predictive estimation, before software is coded, it is first fully documented via functional and non-functional requirements. Working within such a model, when offshoring to a different time-zone, the software vendor would: 1) Send engineers to the client' site who would compile all requirements; 2) Return to the offshore site to code the requirements; 3) Deliver the code to the client (in medium to large projects, this cycle would be iterated several times).
In the past, because requirements tended to be heavily specified (i.e. written down), it was easier for developers in distant time-zones to know what exactly they needed to do next, despite having little real-time access to the client, who was asleep when they were awake.
Today, traditional models for software development are highly questioned in their effectiveness. Studies such as those produced by the Standish Group (The Chaos Report) show that a significant percentage (sometimes more than 45%) of projects that are attempted under BRUF deliver highly disappointing results, both in terms of cost, time to market and functionality. Most companies now approach software development under agile methodologies, which seek to be adaptive rather than predictive (see more on the advantages of agile methodologies on our next post).
Agile development starts from the premise that software is an "idea constantly taking form". Therefore, changes will always ensue during the development process. Instead of preventing change or trying to "outguess change from the get-go", agile embraces smart change, and produces a process that incorporates improvements and modifications in an organized and risk-controlled manner. In general, change can be brought about by different factors, including: 1) the market changes so the software has to change; 2) changes in the competitor's business offerings require changes in the software; 3) new ideas arise in the user's mind that justify changing the software; 4) changes in undergirding technology make new business models possible, therefore justifying changing the software.
To manage change and promote adaptability, agile development seeks to replace formal documentation about requirements-which takes a lot of time to write-for constant conversations about requirements. Therefore, in agile SCRUM, say, the developers constantly interact with the client's user groups to understand that nitty gritty of a functionality that was described to them at a high-level, rather than demanding air-tight documentation exist to describe the functionality in high detail. Because conversations are not only faster, but provide for a give and take of ideas and concepts, the software that results in not only written in record time, but is also much richer and smarter in its functionality. Serious empirical compilation show how Agile development can produce the same code with at least 30% less cost, and in at least 30 to 40% less time than traditional approaches.
To undergo an effective Agile process, however, it is important that the developer and the client constantly interact, in real time. Interaction does not imply a face to face presence; it can occur via chat, the telephone or video-conferencing. But because agile groups do not have large backlogs of detailed information, if they are unable to reach the client at a critical juncture, the group might have to stop development temporarily. For this reason, Agile demands that the client and vendor be in a similar time zone, so that questions are asked and responded in as close to real time as it is feasible. Overlaps for an important part of the day (at least 60 to 70% of working hours or more) seem to work best.
US or Canadian software companies that have previously outsourced to India, China or the Philippines, are now approaching Latin America as a preferred destination for outsourcing partnerships, especially after agile projects with such destinations have gone sour. Indeed, under agile, other weaknesses of former vendors come to light, such as the inability to think critically about unforeseen circumstances, the inability to ask clarifying questions with little information to start from, or the complications certain cultural mores create in allowing for creative thinking "on the fly".
If you are a US or Canada company that is thinking about going agile, and do not want to lose the benefits of working offshore, we heavily recommend that you look for software vendors in Latin America that overlap your timezone to an important extent.
Alejandro is a Business Development lead at PSL Software ( http://www.pslcorp.com ), a Latin American nearshore software services firm. He regularly writes for the PSL Software blog.
