Outsourcing Tasks Does Not Transfer Responsibility For Those Tasks
President Obama quipped in an interview with CNN. On May 14, 2010 "you had executives of BP and Transocean and Halliburton falling over each other to point the finger of blame at somebody else...The American people could not have been impressed with that display, and I certainly wasn't." The legal wrangling continues and will take considerable time and expense to resolve. We need not go into the gory details of dollar numbers too big to even fully comprehend, but from our perspective in this Chapter three key points stand out:
- When you outsource a task, service or suite of services, you could still retain significant responsibility for its full and proper execution.
- Brand-names, size of the company or even their experience is no guarantee of performance of the outsourcing service contracts.
- No matter how close the 'partnership' is at the start, the test of a successful outsourcing contract is how it ends.
While these 3 key take-aways are still relevant to our discussion here, what is more relevant is the fact that all the companies in question will have to continue to outsource (and insource). So the practice of outsourcing itself will continue unabated. What will change after this learning experience is that the practice will be carried out in a much more sophisticated manner. That is the whole point of this book.
Before more on to newer, more sophisticated models of outsourcing that are emerging and examining them in more details in the next few chapter, let us consider the evidence on the satisfaction from current outsourcing arrangements.
Data, anecdotes and case histories abound on the misapplication of information technologies for supply networks. Not too many years ago, a very large corporation operating worldwide, made news with the downgrading of their earnings expectations due to supply chain system’s implementation setbacks. The expectation was that the new system would reduce the new production cycle from 1 month to 1 week. Furthermore, it would better match the demand and supply of its products to place the correct products in the right locations and quantities, all at the right time - a very lofty goal. The company spent an enormous amount of money, exceeding US $400 million in order to achieve its aim. However, the software system 'never worked right'. It caused the factories to crack out too many unpopular products and not enough of the trendier ones in high demand. While making the earning downgrade, the CEO asked the rhetorical question, ‘is this what we get for $400 million?’
The market analysts were not surprised. One respected market analyst [AMR] commented, ‘fiascos like this occur all the time but are usually kept quiet unless they seriously hurt the bottom line.’ Another respected market analyst commented that while the CEO made it sound like it was a surprise for him, if he did not have checkpoints for the projects, he does not have control over his company. A third analyst commented that companies are confused by escalating market hype and too often underestimate the complexity and risks. Another [Forrester Research] commented 'when the software projects go bad companies are more likely going to scurry up and cover it up because they fear that they are the only ones having trouble. But far from it; our conversation and research reveals this company was not unique or the only one having this kind of trouble'.
Despite their lofty goals, many of the large information technology deployment projects derail. It takes time for the word to filter out because, in most cases, the executives involved in the process are far too embarrassed to talk about what happened. They do mutter among themselves; after several similar instances the mutterings become more vocal and a trend emerges where a number of people start talking about the shortcomings of the system itself or the implementation process or of the time taken for implementation. Because the cost of this failure is so high – greater than $400 Million in the above case – it is instructive to understand the real root causes of this failure. I am not looking to apportion the fault or apportion the blame in this chapter.