Reflections on my background in the area of interest

I was first involved with outsourcing when I became director of IT for a medium sized mobile phone company in the Netherlands in May 2001. My predecessor in the role had been encouraged by our Board of Directors to look at how we could bring more efficiency and focus to our IT operations. The solution chosen was to make an outsourcing contract with a large international IT services company. Outsourcing, he and our CEO argued, would bring much needed expertise into our organisation. IT was not our speciality, we were a mobile phone company after all. The company we planned to engage was recognised as expert and experienced in the field, much better placed than our own people for helping us in an uncertain future. By using an outsourcing strategy we could focus our management resources on the real

156

competitive challenges we faced in marketing a new product against fierce competition.

The chosen vendor would take responsibility for managing the IT hardware,

networks and internal communication systems that our organisation used. It would also be responsible for all the desktop workstations. It would even buy all the IT assets from us, providing a useful boost to the cashflow of a young organisation in a rapidly growing market. This was only a part of the IT work, we would carry on doing IT application development and management internally using the hardware platforms and networks that would now be managed by the vendor.

So taking over the new role was for me, at the time an experienced product and financial manager but one with little direct IT experience, an attractive proposition. The staff who would be affected by the outsourcing had agreed to the change, all the messy HR related negotiations were resolved. The outsourcing vendor had started to manage operations. I just had to manage the more interesting and forward looking parts of the IT operation with expert support from a major global player. This turned out to be a hopelessly optimistic view to take. Within months our parent company had decided to split our firm in two, meaning that the IT and the

outsourcing contract also had to be split. This change was completely unexpected at the time the agreement was signed. Fights broke out between my internal IT

developers and the people who had moved to the vendor, some things that could be done before seemed now to be impossible, this was put down to short sighted power games between middle managers. In one meeting I had to step in physically to avoid fists being thrown. I had daily calls from other senior managers, including the CEO, complaining about poor response from the newly outsourced helpdesk, people who had been prepared to bend the rules to get them what they needed before, now would not play the game.

After some initial fumbling around a new relationship manager was put in place by the vendor. He turned out to be practical, hard-headed but avuncular, gaining respect among my middle managers as well as his own. He and I soon became good colleagues and friends. Between us we gradually reshaped the relationship and the way that services were designed and managed. We renegotiated the contract to take account of the split, a tricky and time consuming process. We

157

managed the interests and relationships between our more senior colleagues and within our corporate parents. This was a stressful but ultimately satisfying project, gradually the benefits of efficiency and standardisation of our IT infrastructure services began to be seen.

Two years later there was more corporate turbulence, too complicated and irrelevant to this story to describe here. I was asked by Board members if we could do more outsourcing to the same vendor. I recommended not to. Rapid introduction of new services, forced by the competitive markets we worked in, had led to a set of IT applications that were unstable and in a state of continuous change. Documentation was poor and we relied on a body of loyal experts, many of whom were contracted to the organisation rather than employed, for the knowledge that supported our

innovation and that we needed to fix things when they went wrong. Despite my recommendation, a decision was made to go ahead. I was replaced as IT Director by another manager more compliant to the Board’s wishes and moved to a new role in the organisation. Two further waves of outsourcing took place over the following two years. First the application management roles were moved, then the tricky area of application development. Both went to the same vendor that we were already using for the infrastructure. For the latter deal, it was agreed that cost savings could be made by moving some of the work to the vendor’s offshore site in Mumbai.

By 2006 another three years had passed and much had changed. The company had been sold to a new owner and many of the original Board members had moved on. The new managers were frustrated by slow progress with IT, especially with its ability to support the new products they needed to launch. It seemed that very little work could be delivered by the outsourced teams. The company by this time had a very small IT organisation, responsible only for architecture, design and project management. Almost all of the experts we had relied on a few years earlier had moved on, or been moved out. My replacement as IT Director left too.

In the intervening years I had worked on another outsourcing project within the company which we had stabilised and put on a good footing, following the

relationship discipline learned in my IT infrastructure experience. The Board asked me to come back and look into what had happened with IT. A number of questions were buzzing around. Should we continue with the outsourcing relationship and try

158

to make it work? Should we end it and go our own way? Should we have a day in court with the vendor?

My conclusions were mixed. The further outsourcing had been messy, many activities that should have happened to document and understand the relationship, to move knowledge from our people to the vendor in an orderly way had simply not happened. It was not clear why this had come about. People pointed fingers. We were however a demanding client, with poor ability to specify stable requirements for change and frequent changes in our priorities. The management processes for specifying, agreeing and tracking work were clumsy and unreliable. Project delivery would fail, too often at the last minute. I took a trip to Mumbai and met a committed and talented team, but they felt that they did not get clear enough direction, they were not helped to help us.

I concluded that we had no option but to carry on. We had lost the knowledge we once had, and that we would need to go it alone. Our case for poor behaviour by the vendor was weak with little formal evidence that we could present to a judge. As an organisational that was now profitable, with a large customer base in a competitive market, the risks of the radical change that breaking our relationship with the vendor would represent, were too great.

A few months later, I too left the organisation for a completely different role with a new employer in the UK. I will write no more about this case, as my further learnings about it are based on hearsay. It served however to give me a keen interest in IT outsourcing and how to make it work effectively in real situations. I soon started to look at the phenomenon in a more academic way, starting a path that would lead to this research project and thesis. Two aspects of outsourcing especially fascinated me: the way that knowledge can be at least preserved or at best improved within it and the mix of social and formal relationship structures that are needed to make it work effectively. My personal case experience had given me insights into the good and bad side of each.

We had managed to lose much (not all) of our internal knowledge base but had made a long term relationship with another organisation that had all the knowledge we needed and more. We were simply unable to release this and use it to our advantage. On reflection after the event, we needed to move our knowledge base

159

from one grounded in the technology to one based more on the process, taking all its social aspects into account. Poor levels of trust between my company and the

vendor meant that we would tend to hang on to knowledge, believing that this could help us in some future fight. This caused problems that eventually appeared as a weaker innovation competence. Outsourcing had given us IT platforms that were cost efficient, (generally) stable and allowed the company to do what it needed for our customers at that time. It was just difficult to change these.

I learned about the importance of personal relationships alongside formal

agreements in making complex deals work. A formal contractual agreement might be able to take some account of ‘known unknowns’ in the future but it cannot deal with the ‘unknown unknowns’ like our need to split the company in two. In the presence of a contract, these can only be addressed by good relationships between the parties. Both types of ‘unknown’ are surprisingly common, especially in complex technological markets ridden with product, price and distribution changes. There is also quite a low level of IT understanding inside organisations; it is simply hard to describe to an external party how a complex operation or interacting technology and process actually works. Failing to explain, or just getting an explanation wrong, creates new ‘unknowns’ that will cause the outsourcing vendor no end of problems when it tries to deliver the services the client expects. This lack of understanding is also not limited to the technological or operational fields, how should a helpdesk operator be told to react when the CEO’s PA comes on the line with a non-standard request?

I have tried in this section to explain and reflect on my background in this topic area and to indicate the preconceptions that this gave me as I approached the fieldwork and interpretation of its results. In the following sections I will give specific examples of how I addressed this and explain how it supported me in the development of an analytical framework.