Learning Curve: What is the cost of the learning curve of your prospective outsourcing partner? In other words, where does the knowledge sit, with you or with the contractor? For knowledge that sits with you, what evidence do you have that the contractor can acquire and retain knowledge in your problem domain? Contrast this with your own costs of training in-house IT staff.
Staff Turnover: What is the cost of contractor personnel turnover? Does the contractor have access to more resources, and a greater capability to hire skilled workers? Is the turnover rate higher or lower than you might expect? Contrast this with your own ability to hire and retain skilled professionals.
Service Level Agreements (SLAs): What is the cost to your business if your partner doesn't meet your requirements? How critical to your business is the system you are outsourcing? What is the likelihood that you will meet service level agreements with an in-house vs. outsourced solution?
Skill Sets: Does your prospective partner bring skills to the table that you don't have in-house? Is your in-house team, assuming you have one, better at supporting existing systems, or at building new systems? What can be said regarding that about your prospective outsourcing partner? What costs are involved in assembling and training the team that you require?
Distributed Teams: What is the impact of geographic time zones on your operation? If your prospective outsourcing partner is in a different time zone, does that necessitate shift work? How does communication occur across the different time zones, and what costs are involved? Can your business benefit from a 24h work cycle?
Each of these factors are related with one another, in that all involve the cost of retaining the requisite skill sets and meeting service level agreements with the business.
Whether you are building a new system, or supporting an existing system, there will be requirements for a certain amount of responsiveness from your outsourcing partner or conversely from your in-house team should you choose not to outsource. Prioritization of goals, available resources, service level agreements, staff turnover, and learning curve all factor in to how responsive your chosen team can be during critical moments of the project. Assembling an in-house team if you don't already have one can be a daunting task that carries the risk of employing people who may never have worked together before, and therefore have no track record of success as a team. If you have an in-house team already, is there a formalized process for the business to interact with the team, or is it an informal sneaker net approach? What is a fair assessment of the SLA track record using your current approach, and does it require more formalization in order to deal with a 3rd party? It's important to use one set of criteria for judging performance, and not judge an external provider more harshly simply because they are not part of the family. That said, it pays to understand thoroughly how your outsourcing partner intends to meet your objectives. Will they provide a team that is experienced in working together according to an established discipline? Does the team have a solid development culture? Does the management fully understand modern software development techniques? Most outsourcing partners will profess that they have all these things, so it's important to do third party reference checks to vet these claims. A special case that occurs frequently enough is where you hire an outsourcing partner to develop a new system, with the intention of supporting it internally with an in-house team when the system is in production. This may occur when you have an in-house team, but it doesn't contain the requisite number of skilled resources to complete the build. In this case, turnover of the completed system becomes a priority that will likely involve some cross training, and availability of some resources from the outsourcing partner on a temporary basis until that training is complete.
The Product Owner does not spend time on team-specific meetings, so the role is really not an operational one any more. Team-specific activities are delegated and co-located with the development team, and therefore are not subject to the issues raised by critics regarding the impact of offshoring. Redefining the Product Owner role is just one example of decreasing coupling between teams, and increasing cohesion within teams, which is necessary in order to scale to multi-site geographically distributed teams. For more information on scaling Agile see The Onshore-Offshore Model, Adapting Process to Projects, and Scaling Agile Development.
Historically, there have been few legal restrictions placed upon onshore companies contracting out work to offshore companies. Legal concerns have arisen in connection with the use of Intellectual Property (IP), including enforcement issues, particularly in offshore countries that have historically shown little interest in abiding by contractual IP obligations. The IP issue is particularly of interest to software product developers, since the bulk of software piracy is related to hacked copies of commercial OS's and applications. The use of counterfeit and pirated software in the workplace costs enterprises more than $114 billion each year, according to a study conducted by analyst firm International data Corp. for software maker Microsoft. Software piracy is quite prevalent in China, where, according to the BSA, approximately 90 percent of the software in use is counterfeit. Organizations such as WIPO keep records on IP related legislation by country in order to help track and promote the protection of IP throughout the world. If you are building or maintaining commercial OS's or applications, or otherwise have concerns about IP, it pays to be aware of that legislation and it's enforceability in the country of interest.
Commercial software product development aside, how concerned should we be about outsourcing the development of a custom system that we intend for our own corporate use. In many cases these systems are branded, and likely of use only within the corporation. However, they may contain proprietary algorithms that contribute to the competitive aspect of the business, and therefore require IP protection, including copyright and perhaps patent protection. Perhaps even more importantly, what access to proprietary sensitive data is given to the outsourcing partner. For example, will your custom system contain sensitive data such as credit card numbers, medical data, or other sensitive identity related data? If so, what steps and techniques are necessary to ensure that data is not compromised, and how will those steps affect the implementation of your project? Where sensitive data is involved, will it be exported for local use at the outsourcing site, or accessed remotely by your outsourcing partner through secure VPN. What considerations, if any, should be taken to sanitize the sensitive data so as not to expose it to third parties? In some cases, the original sensitive data may be required to test the functionality of the system. That may require changes to how system testing and bug fixing is performed.
Few companies can do everything well. It's important to remember what business you are in, and to excel at that. Trying to wear too many hats may mean that you do less than what is necessary in some cases. On the other hand, not all outsourcing companies excel at what they do, so it's important to deal with one that does excel. Relying on old style high quality references from other companies both inside and outside your own line of business is still a good indicator of the experience you might expect from dealing with a particular outsourcing provider. Have your prospective partner describe their approach to outsourced software development to ensure that it addresses any specific concerns you may have. Of particular importance is how the communications process will work with multi-site geographically distributed teams.
Determine whether the systems that you are contemplating outsourcing are a critical competitive component to your business. Commodity items such as accounting systems can benefit from shared marketplace knowledge that leads to packages that are supported by niche software providers. There is no need to build or support commodity software in-house. Competitive software on the other hand may not have its equivalent in the marketplace, or may have different features than competitive offerings (hence the competitive factor). In this case you are less likely to find an outsourcing partner who is fully knowledgeable in the problem domain that the software addresses. Here it is more important to either support the software in-house, or find a partner that is willing to become a long term partner in your problem domain. A long term partner will invest in the training required to become competent in your problem domain, and will ensure that trained resources remain allocated to your account.
Building a new system is different than supporting an existing system. An outsourcing partner may be more skilled in one versus the other. Supporting an existing system requires ticketing, prioritization, service level agreements, and metrics to determine whether support levels are being met. Building a new system requires strong knowledge of system architecture, project management, and an in-depth understanding of the goals of the project. Understand which, if any, of those skills your organization excels at and what your prospective outsourcing partner excels at.
We hope that by considering the points discussed above you will be better placed to make your outsourcing decision with greater confidence.