Can you offshore Drupal work?
The trend of offshoring IT work started during the 90s. Moving labour intensive programming tasks to low cost countries like India or China was considered as a great idea. It provided huge savings on projects that had millions of lines of code. Programmers were considered to be a factory: they just implemented designs done by architects. The way of working was identical if the programmers were sitting in the same room with architects, project managers and customers or on the other side of the world. Biggest issues with offshoring were communication problems, quality and managing the developers. These issues were at least partially solved by professional offshoring organizations and heavy layer of project management.
The world has changed since then. There are two primary drivers for the change: Much more efficient technical platforms and agile development.
Highly productive systems like Drupal require much less programming to implement functionality and much higher percentage of effort goes to working with the user experience. User experience boils down to well designed processes and details. Process models can, in most cases, be tested and retested with quick prototypes. Details can, and should, be implemented and iterated in the real system instead of designing them first on "paper".
It turns out even the best business analysts, concept designers, art directors and software architects will not produce as good results on "paper" as working with the real product does. Not designing everything up front means agile development. This also means developers have to understand the business case behind customer requirements and choose the right tools for the job. It also means constant communication with the customer and even with the end users in many cases. Service design is no longer only a separate specialty role, it's something every developer has to know.
These two changes together make offshoring Drupal work difficult. For optimal results, time should be spent in working on details in iterations, not just implementing detailed paper based plans. If the developer can't understand the end user of the system then he will need a lot of support from somebody who does. This somebody is usually a project manager, business analyst or software architect either from a vendor or from the client. Much higher amount of work required from somebody on site means more costs. These costs can easily be high enough to make total cost of building a system more expensive than doing it locally.
To make things even worse this means different implementation paths will not be considered by a developer who doesn't fully understand the business case behind requirements. Not considering different implementation paths can be a major extra cost in a Drupal project since there are always multiple ways to implement practically anything.
Impementation of details by a developer who can't relate to end user will in most cases cause weaker quality as well. Even the most detailed plans will not include all details required for the implementation and these have to be decided by the developer. If the developer doesn't have enough information for these decissions the result is either low quality or a ton of work for somebody to test (and instruct how to change) everything.
I'm not saying offshoring or nearsourcing Drupal work is impossible, I'm just saying it's difficult. We do some nearshoring internally at Mearra. We do limit it to developers who are near by to the customer both physically and culturally. We also try to limit it to things that are easy to specify, for example integrations, data migration, overall theming (not working on the details) or module updates. We also only use people we know and have met face to face frequently, in our case our own employees from other offices. We find that this makes a huge difference in quality of nearshored work.
Our way of working is that developers have a huge role in projects and they work very closely together with the customer. I'm sure many offshoring companies disagree with my point of view. Counter arguments for why offshoring Drupal work is a good idea are welcome.