Two Types of Outsourcing Risks

When you sit with an outsourcing provider, the conversation typically turns toward Technical Risks. These include discussions about technologies, delivery processes, compliance issues, staffing, etc. These are the down-and-dirty details that ultimately determine how well a team can manage their deliverables.

For a supplier, these are highly relevant.

For you, however, there are a number of other risks to consider, which your suppliers will rarely bring up. These are Business Risks that include:

1. Business process impacts, ability of your market to absorb the changes you propose
2. Ability of your end users to adapt to proposed changes
3. The overall network of suppliers and internal resources needed to deliver your products and services.

Most outsourcing initiatives typically fail because of Business Risks.

The reason is that decisions and money are controlled by the people who look primarily at these risks.

I remember sitting in a meeting with a large government organization while the strategy for a $400 million project was being developed. This project would involve16 major outsourcing suppliers, dozens of sub-contractors, and would impact over 150,000 people. At the time, I was deeply involved with process improvement concepts and felt that I knew a lot about how to make this kind of project work.

The discussion, however, never even touched on my area of specialization. All technical risks were brushed aside by one comment, made by the senior-most manager in the room: "Our assumption is that you can make the technical details work. If you can't do your job, then you shouldn't be in this meeting."

Guess what? I never said much for the rest of the meeting :)

What I witnessed in that, and later in other, projects was that the big decisions that make or break an outsourcing initiative are those that relate to business risks. If you can manage these, then your project will have a much better chance of success.

Another example to illustrate the power of managing business risks is a different project for another government organization that I worked on. In this case, the outsourcing service provider was unable to deliver on time.

The timeline for the project, however, was immovable. Commitments had been made, publicity had already started, and many organizations inside and outside government were gearing up for on-time delivery of the software. Business risks included: loss of credibility, financial loss from media and other public programs, and potential legal liabilities from non-governmental groups that depended on timely delivery.

In response, with less than 2 weeks before the deadline, the government's project manager convened a war-room to define a course of action. We decided that the technical side of the project would need to improve. Key people were fired, a new management team was hired, and a new timeline was created. At the same time, the business objectives of the program were slightly modified, wording of some of the public communications were slightly changed, and a restricted set of functionality was identified as "Phase I" of the project.

Two days before the deadline, the smaller set of deliverables in the new Phase I were delivered. The project was declared a success. The new team then delivered what was promised, on a timely basis. And the government's project manager ended up looking like a hero.

This was a vivid case where the business risks were clearly identified and managed. Doing so allowed the project to be declared a success while giving the technical side time to do what they needed to do. And the project survived what may have been very ugly repercussions.


In the next article, we will look at ways to identify business risks, including a simple technique to mitigate them before the outsourcing project starts.

I'm back --- with new direction and information

Hi, everyone. Sorry for the long gap between articles, but I was thinking.

The response to the earlier articles was great. Many people called or e-mailed me with positive comments. Some were willing to work with me professionally. So, everything seemed to be good.

But my purpose in writing these articles was to provide concrete value to managers who are responsible for outsourcing. In this respect, I was not satisfied with the depth of information provided. The question, however, was: how do I provide this depth without being too technical?

So began my 6-month hiatus. The good news is that I now have what I was looking for. The following series of articles should provide strong, usable information, presented in a business context that can be understood (and hopefully applied) by anyone involved in an outsourcing engagement.