Minimize IT Outsourcing Risk with Collaborative Quality - Part One

This is the first of a four part series that summarizes the key points outlined in our paper on Minimizing IT Outsourcing Risk with Collaborative Quality. You can click on the title to get the complete white paper.

In the past ten years we have seen explosive growth in the practice of outsourcing IT functions to SIs (System Integrators) and services firms around the world. One of the fastest growing areas was the practice of outsourcing software testing to overseas teams. How as enterprise systems change from huge monolithic applications to more componentized, services-based solutions, the risk involved in outsourcing testing rises. This series looks at these risks and offers a solution.

First let’s set the stage by looking at four common IT outsourcing models:

1. Single Outsource Vendor where the buyer outsources all IT development and testing functions to a single SI partner. It offers the benefit of a single source for delivery of business applications, and one vendor to call if something goes wrong. However, it can also create high switching costs if you decide to change vendors later.
2. Outsourced Testing appears to be the easiest route if you decide to keep software development close to home. Since testing is by nature the process of “breaking” an application, many organizations find that a removed third party tester can be very valuable and impartial. This model was very easy to adopt when testing was a manual, point-and-click-on-the-screen endeavor that was best done by less costly staff. But times have changed, forcing testing offerings to evolve in sophistication.
3. Development Support. The many companies following this strategy are seeking both cost efficiency for non-differentiating development tasks, and access to developers with specialized skills needed to carry out specific tasks, such as migration between two different integration platforms that they may not have the expertise to pull off in-house.
4. Multi-Vendor is most common when development and testing activities are outsourced to different SIs. In this model, the company hopes to keep costs down, while the multiple providers keep each other "in check" to ensure project success. While you can mitigate some risks associated with a single outsource vendor, it can also be harder to manage multiple firms and get them to collaborate as efficiently.

Now let's look at the risks, as managing risk can be more important than obtaining upfront savings, if these cost reductions come back to haunt you later. After all, what good is a lower cost project if it takes 3 times as long to repair, or if your app fails in front of customers? Your outsourcing partner needs to be incented to build quality into the application, and not simply cut costs and initial project time.

This balance of quality and speed gets more complex when multiple teams are involved. While many larger companies have a multi-vendor strategy of procuring IT services, the more companies and teams that are involved in a project, the more opportunities there are for the information sharing and collaboration to break down.

What is needed is greater team accountability for shared deliverables all the way across the software lifecycle, which includes visibility into problems early, versus later in the deployment where they become significantly more costly. There is also the risk generated by dependencies on unavailable or inaccessible systems. Interdependent teams working together can be constrained by limited access to live applications and components that are not yet completed or available for testing. We see this issue often in the field as reported in our series.

When there is increased contention for shared resources, agility suffers as teams are forced to queue up for access, introducing scheduling delays and project risks. In some cases, teams may attempt to maintain their own test environments by replicating the components they need in a testing lab or custom test harness.

These team-to-team constraints on environments can become very costly to manage, requiring a high level of configuration, licensing costs and maintenance to keep current, even if it is running on virtualized hardware (which also has incremental licensing costs). And of course, some sensitive systems such as ERP mainframes are simply too big and have too much overhead to be replicated by conventional hardware virtualization means. In our next post in this series, we start to look at ways to meet these challenges and make more effective use of IT outsourcing.