The Big Debate: Do I go offshore or stay close to home?
Over the last few decades, companies have been faced with a difficult decision. Do I outsource my technology and/or product development? Do I send it offshore or keep it close to home?
The answer is multi-fold and depends heavily on how mature your System/Product Development Life Cycle is and what stage you are in. There is often confusion between the different decisions of outsource/insource and onshore/offshore. There are multiple combinations that should be thoroughly evaluated – again depending on criticality and maturity. When exploring the options, we strongly encourage clients to keep their development onshore (whether insourced or outsourced) while development efforts are still in prototype mode. Platforms that require extensive interaction with business users that all too often have ill-defined parameters should remain close to the business.
Once thorough design has been completed, and clear parameters have been set, offshore may become an option. Unfortunately, few firms have the time and discipline to complete this analysis correctly up front; Interaction with end users in this stage is of vital importance. An offshore model can present a variety of complications including communication barriers on either side, not to mention time zone issues.
At The Intersect Group, we also encourage companies to look at total cost of ownership as well as the entire lifecycle of the platform. Will there be a substantial cost savings without potentially losing confidence with key business users?
Companies must first optimize their process with key business users and devote time to building and maintaining trust before shipping anything out of house and/or overseas. Only then should the sourcing model be evaluated. For example, different resources are needed for building platforms versus simply maintaining them. Once in maintenance mode, it can be cost advantageous and efficient for a company to host offshore. Beware here too; many times, there is not extensive documentation to give an offshore partner a base code of where things currently stand and thus they risk breaking one thing while developing or fixing another.
One example of how a combination can work: One of our global clients needed a complicated analytics application related to pricing across multiple products and service lines. Because the specific expertise did not exist in house, they outsourced the design and prototype build to us. We ran very short term sprints in an agile framework interacting almost daily with the business users to get the algorithms and functionality down. Then we had to work with multiple databases on the backend to ensure clean and accurate sources of information – again working with the business outputs. Once we got the prototype up and running consistently and well documented, maintenance can be now be evaluated for outsource or in house/off-shore and phases 2 and 3 of development are being carried forward by in house onshore resources with supplemented staff expertise.
The critical decisions are really when and how to source. Whether one combination is better than another completely depends on criticality, maturity and timeframe. What we know works well is when something is mission critical, ill-defined, and time sensitive, keep it close to the business with very rapid loops – don’t outsource to an offshore partner introducing time and communication barriers risking extreme frustration with the business “customer.” Get it well developed, functional and documented before you ship it off. If that happens to soon, you might save money but you will most certainly trade short term gain for long term pain.