In the last decade, outsourcing became a powerful force in the software industry.  Motivations behind outsourcing vary, but the reason our clients mention most is that of cost savings.  Unfortunately, all too often our clients also mention that previous attempts at outsourcing failed to deliver the desired efficiencies, or perhaps failed to deliver anything at all.

So, is outsourcing some siren on rocky project shores, luring to doom the captains of IT who dare to listen to the siren’s song?  Not at all, but outsourcing is not without its risks.  Over the last twenty years, I’ve worked on both sides of the outsourced IT relationship, and have seen it work.  Let’s examine what successful outsourced efforts have in common.

Successful outsourcing involves planning and handling the unique logistical details of outsourcing.  For example, e-mail and intranet communication, synchronized software lifecycles, procedures for file transfer, effective configuration management, support for development, test, and staging environments, sufficient test data, common tool usage, and compliance to applicable standards are necessary for success on many software projects.  Project teams must understand the tactical details of how the work will get done, day-by-day, person-by-person, and resolve any logistical obstacles that could occur in advance.  Good project logistics are like air and water: You don’t notice them until they’re bad or, worse yet, completely missing.  However, outsourcing logistics are complex and often span organizational areas of responsibility (or even falls into gaps in areas of responsibility), problems happen often, and cause many outsourcing difficulties and failures.

Successful outsourcing also involves good working relationships with mutual trust and open communication. Studies show that simply locating people on separate floors in the same building can dramatically reduce communication and relationship building.  Having people located thousands of miles and half a dozen or more time zones away is even harder on relationship building and maintenance.  However, successful outsourcing requires that people actively nurture good working relationships across the organizational and geographical boundaries.  If relationships are weak, trust is missing, and communication is infrequent, every project challenge becomes harder to deal with.  In the long term, relationships sour and morale suffers.  In addition to creating an emotionally-unpleasant working situation for everyone, quality and efficiency both go decrease.

Successful outsourcing requires understanding what CMMI does—and doesn’t—tell you about an outsource vendor’s capabilities.  Properly applied, CMMI will lead to more orderly, consistent practices, which can increase quality and efficiency.  We have clients who use CMMI to improve their processes, reduce costs, and deliver better software.  That said, the jury is still out on whether there is a statistically valid and reliable correlation between CMMI levels and: 1) the cost per delivered KLOC (or Function Point); or, 2) the reliability or defect density of the delivered software. If that seems to contradict what I said about some of our clients, my point is that it is a logical fallacy to say that, since some companies have success with CMMI, therefore every company that achieves a high level of CMMI maturity will produce better, cheaper software than another company with a lower level of maturity.  In addition, even Bill Curtis of the Software Engineering Institute, one of the fathers of CMMI, admitted (at the ASM/SM 2002 conference) that, when used purely as a marketing device, CMMI does not significantly improve quality or efficiency.  So, if an organization says they are CMMI accredited (at whatever level), dig further to see exactly what that means in terms of their daily practices, and look at solid metrics for efficiency and quality.

This brings us to the final factor for successful outsourcing: selecting the right outsource service provider.  As I mentioned above, just looking at CMMI levels won’t suffice, but even if you satisfy yourself that a vendor is mature, efficient, and delivering quality, remember, as an investment prospectus would say, past results are not necessarily an indicator of future performance.  In other words, just because a vendor has had good results on past projects doesn’t mean they will succeed on your projects.  Here are some other questions to consider:

• Who are the specific people who will work on your projects, how long have they been with the vendor, and what measures are in place to prevent turnover?
• Does the vendor have experience with technologies, business domains, and projects similar to yours?
• Does the company have sufficient infrastructure to handle your projects?
• If you anticipate growth in your use of the vendor, do they have the ability to scale up their staff without compromising the quality of their work?
• Are the technical and managerial leaders of the company well-established in the field, with a good reputation and perhaps even a record of thought-leadership?
• Are the vendor’s corporate culture, work habits, and ethical standards consistent and compatible with your own?
• Does the vendor have competencies in specialized areas such as testing or requirements engineering or should you consider using specialist vendors for those elements of the project?

If all this seems difficult and complex, keep two things in mind.  First, even relatively small projects can have significant costs, especially opportunities costs, if they fail, so outsourcing is always a decision to be made with care.  Second, in most cases the real efficiencies of outsourcing will only kick in after a few projects, so organizing for outsourcing success is worth doing well, because, if you do it right, you only have to do it once.  Once you have established a successful working relationship with an outsourcing vendor, you will find yourself reaping the benefits, project after project.