How to manage an outsource vendor that is executing an internal transition to India.

How to manage an outsource vendor that is executing an internal

transition to India.

An UPC Broadband case study.

Management summary

UPC is currently facing an internal outsource transition with one of their outsource vendors. Accenture, the outsource vendor, will move one of their offices from Madrid (Spain) to Hyderabad (India). Even if this concerns an internal transition at one of UPC’s vendors, it comes with benefits and drawbacks for UPC. In order to ensure that UPC can benefit from this transition, all possible drawbacks should be avoided, while the benefits could lead to new opportunities for UPC. To make sure that UPC will benefit, the following research question is formulated:

“How to deal with factors caused by the internal Accenture outsource transition of the development department from Madrid to Hyderabad”?

In this research the “Plateau Planning” model will be used to structure factors found in literature, on the Internet and from UPC inputs. Finally the plateau planning will also be used for giving an advice on 3 plateau maturity levels and how to overcome impacting factors. To create these plateau levels a delta analysis will be performed with the factors found. The factors will be evaluated leading to the conclusions which are relevant for UPC. The following three levels can be distinguished:

Plateau 1, at this plateau UPC and Accenture continue the current relationship with only a change in the outsource location. This plateau is characterized by low cost resources but less flexible compared to plateau level 0 (Current Situation). Unfortunately, this plateau will come with impacting factors as: “process changes”, “communication” and “cultural understanding”. Plateau 2, at this level UPC does not communicate directly with IDC, UPC and Accenture use an interface instead, as originally agreed in the contract. This is only possible when the interface is having the right skills, avoiding necessary back-up from IDC. It is therefore important for UPC and Accenture to bring the technical skill level of the on-site team to the right level. As a result of the interface, UPC can avoid all the impacting factors from the first plateau.

You cannot have all chiefs; you got to have Indians too

.

Preface

After a lot of researching, reading, interviewing and stress, I finally finished my Master thesis. With the knowledge and experience gained during this project, I am sure that I will outsource my next thesis, if I ever need to do it again.

Fortunately, many people helped me to finish this project. I would like to use this occasion to thank these people.

First, I would like to thank some people from UPC Broadband. I would like to thank Steve Bull for given me the opportunity to do this project, help and his experiences during the project. Pedro Sousa and Marcel de Leeuw for their support and help. I would especially like to thank Marcel for helping transforming my “Dunglish” into English. Beth Houthuijzen for her help and being a nice and noisy roommate. Besides these people I would like to thank all other UPC personnel for their support and the nice time I had at UPC.

Second, I would like to thank some people from the University of Groningen. Especially, Pieter Buijs as the representative and mentor of the project. He really helped me structuring and finishing this project. I look back with pleasure on the meetings we had, were Mr. Buijs took the time and patience to explain things with his knowledge and experiences. I also would like to thank Mr. Wortmann, he made it possible that Pieter Buijs could be my mentor during this project.

I would like to thank my girlfriend Leonie for her support and being nice to me at home even when I was stressed during my study.

Outline

1. Introduction ... 7 1.1 UPC Broadband. ... 8 2. Research Question... 10 2.1 Methodology ... 10 3. Transition Process ... 15 3.1 Development Process ... 16

4. Research Framework (Literature) ... 19

4.1 Outsourcing ... 19

4.2 Model ... 21

4.3 The plateau Planning Model ... 21

4.4 Literature & Internet Input ... 23

4.5 People & Culture ... 24

4.6 Management & Organisation ... 28

4.7 IT ... 30 4.8 Process ... 31 5. Collecting Data ... 33 5.1 Input UPC ... 33 5.2 Factors overview ... 35 6. Delta analysis ... 36

6.1 People & Culture ... 36

6.2 Management & Organisation ... 38

6.3 IT ... 40

6.4 Process ... 40

6.5 Summary of factors that need extra attention... 43

7. Managing Impacting Factors ... 44

7.1 Plateau 1, Managing the Core ... 46

7.2 Plateau 2, Managing the Interface ... 50

7.3 Target Plateau, Improving Maturity of Relationship. ... 51

8. Conclusion ... 53

9. Epilogue ... 55

9.1 Generalization & Recapitulation ... 55

Literature ... 57

Appendix 1, Abbreviations List ... 60

Appendix 3, Interview Reports. ... 62

Appendix 4, Relationship Maturity Model ... 69

Appendix 5, Process and Involvement of Departments... 71

Appendix 6, As IS, UPC Organization Roles on Project Deliveries RACI Model. ... 72

Models and Tables overview Model 1.1, Project Overview. ... 7

Model1.2, Liberty Global Structure. ... 8

Model 1.3, UPC Broadband Structure. ... 9

Table 2.1, Five phases of the “Classsical Research Approach” from De Leeuw. ... 11

Model 2.2, Scientific Research ... 12

Model 2.3, Project Method. ... 12

Model 2.4, Project Method including Plateau Planning. ... 13

Model 3.1, Black box approach. ... 15

Model 3.2, The Development Process. ... 17

Table 4.1, Outsourcing benefits. ... 20

Model 4.2, Plateau Planning. ... 22

Model 7.1, How to manage Accenture + Impact. ... 44

Model 7.2, Managing the Interface. ... 45

1.

Introduction

This Thesis is written as final assignment of the “Master” study “Technology Management” at the “Rijksuniversiteit Groningen”. In this thesis project an outsource transition project at UPC has been researched, as can be seen in model 1.1 (Project Overview).

UPC is currently facing an internal outsource transition with one of their outsource vendors. Accenture, the outsource vendor, will move one of their offices from Madrid (Spain) to Hyderabad (India). Even if this concerns an internal transition at one of UPC’s vendors, it comes with benefits and drawbacks. In order to ensure that UPC can benefit from this transition, all possible drawbacks should be avoided, while the benefits could also lead to new opportunities for UPC.

During this project multiple input sources will be used for locating factors that could positive or negatively impact the transition project at UPC. Information sources used are: literature, internet forums, experiences from earlier transitions at UPC and the UPC employees’ experiences. Next to this input all the knowledge gained during the study ‘technology management” has been utilized, in specific the course “IT Management & Consulting”. This course had many links to this outsources project at UPC. When using the words “this project” in the text, this thesis will be referred.

During the project, different literature will be used to develop a proper methodology to structure the process of this thesis.

P

ROJECT OVERVIEW

T

RANSITION

P

ROJECT

UPC

OUTSOURCE TRANSITION

T

HESIS

(T

HIS

P

ROJECT

)

Factors & Impacts

1.1 UPC Broadband.

The Accenture outsource transition project will be executed at UPC Broadband (later referred to as UPC). UPC is a strategic part of Liberty Global and provides services to the European market. Liberty Global is a leading international cable operator with its head office in Denver (USA), delivering services in 14 countries. Liberty Global offers the following main services: advanced video, telephony and internet.

Model 1.2 provides an overview of the Liberty Global corporate structure.

Model1.2, Liberty Global Structure.

UPC provides services to 9.1 million customers whilst as 13.9 million homes are passed (potential customer based) in Europe. Recently UPC has acquired Unity Media in Germany with 8.8 million homes passed and 4.6 million customers. The head quarters of UPC are located at Schiphol Rijk.

Model 1.3, UPC Broadband Structure.

The transition project will be lead by the Corporate Information Office (CIO). This office is one of two technology departments (the other department is the “Corporate Technology Office” (CTO)) which will enable UPC to provide the services to the affiliates.

To be more precise, the project will occur at the Business Support Systems (BSS) Department, which is part of CIO. The BSS department is responsible for the following areas: Project Management, Customer Management, Revenue Management, Order management and Vendor Management. In Appendix 2 these area’s are more elaborated.

2.

Research Question

Were the goal of the transition project of UPC is: “reducing costs”. The main goal of this project is: “to support the transition, to assure UPC to benefit as much as possible from cheaper resources in India”.

To achieve this goal, the following research question is formulated:

− How to deal with factors caused by the internal Accenture outsource transition of the development department from Madrid to Hyderabad?

Sub-research questions:

− Which outsource factors are indicated by the literature and internet that will impact the performance?

− When applying the outsource factors to the current situation, what are the outcomes and how to deal with these?

2.1 Methodology

With the use of the research question a project methodology is created. To make the approach of this project/ thesis (See model 1.1, Project Overview) clear, the methodology used within this project will be described.

In the model 2.3 “Project method” a graphical overview of the project methodology is displayed. In this picture two projects can be found. In the blue colored boxes this research project/ thesis is mentioned and in the green colored box the transition project from UPC can be found. The relation between these two projects becomes clear. The outcome of this research project should help UPC in their transition from Madrid to Hyderabad.

process during this transition. UPC is informed bi-weekly meetings between Accenture and UPC, where the progress to date is being discussed.

The Project Method used (Model 2.3, Project Method) is the outcome of a number of discussions between different parties, namely: UPC, the Rijksuniversteit Groningen and the author of this research project. During this process, the problem has been approached in a logical way. All parts of the model (excluding “Recapitulate & Generalize”) support the model to solve the problem. However, when the developed model is compared to the literature from De Leeuw (1995), there are two items that require further clarification.

First, the whole project method is comparable to the “Classical Research Approach” from De Leeuw (1995. p85). The “Classical Research Approach” consists of five phases as can be seen in table 2.1.

Five phases of the “Classsical Research Approach” − The problem statement,

− Developing a (theoretical) framework, − Collecting data,

− Analyze, − Report.

Table 2.1, Five phases of the “Classsical Research Approach” from De Leeuw. (1995. P85)

When comparing both models, it becomes clear that the problem statement is similar to the introduction of this research. This phase is not mentioned in model 2.3 but is part of the whole research/ thesis. The developing of a (theoretical) framework is similar to the “Literature Study”/ “Internet Research” and “Selection & Ordering” in this research. “Collecting data” phase is similar to the “UPC Input” phase. The “Analysis phase” from De Leeuw (Table 2.1) is called “Delta Analysis” in this research. And finally the report phase is similar to “Managing Impacting Factors”.

used in this research including the “Recapitale & Generalize” Phase is similar to another model of De Leeuw; the model for “Scientific Research”. This model is displayed below (Model 2.2).

Model 2.2, Scientific Research (De Leeuw, 1995, P.72)

In this model it is important that the outcome of this research is again compared with the literature input at the beginning of the research. In the Project Method (Model 2.3), this comparison will occur in the “Recapitulate & Generalize” phase. In the short-term the outcomes of this discussion are not interesting for UPC, but they could be in the long-term.

Model 2.3, Project Method.

Input”. This “Input” could for instance consist information from interviews or internal reviews from earlier internal transitions.

UPC has indicated that they would like to use the information from internet forums and internet sites. This information is not scientific but can be very helpful to avoid pitfalls during the transition project. On these internet sites, similar outsource transitions are being described and discussed. The information from these transitions is most of the time: up-to-date and clearly described. This “Internet” information can be used as an addition to the “literature study”.

The literature study will start with a search for a model, which can structure the information that will be found. This model must be able to structure the input from the literature study as well as the input from the internet. In addition, input should be structured in such a way that it is useable in future phases of this research model.

When the literature model, the Plateau Planning, is integrated with the “Project Method” model, the following model as displayed below in model 2.4 will appear. The reason why the Plateau Planning is used in this research and the explanation of the “Planning” itself can be found in paragraph 4.3.

P

ROJECT METHOD LITERATURE STUDY DELTA ANALYSE / UPC RECAPITULATE & GENERALIZE INTERNET/FORUM INPUT

T

RANSITION

P

ROJECT

UPC

OUTSOURCE TRANSITION INPUT UPC MAN. & ORG. PROCESS IT PEOPLE& CULTURE ORDER/ SELECTION MAN. & ORG. PROCESS IT PEOPLE& CULTURE

MANAGING IMPACTING FACTORS

MAN. & ORG. PROCESS IT PEOPLE& CULTURE FACTORS

Model 2.4, Project Method including Plateau Planning.

the UPC transition/ situation. As a result of this comparison some factors will be eliminated, because they are not relative to this project. The usable outcomes of this delta analysis will be used for describing all possible impacts.

The factors that remain after the comparison and elimination will be used for further research. The remaining factors will influence and impact the development process. These impacting factors will be elaborated in “Managing Impacting Factors”. To prevent mistakes and avoid pitfalls solutions will be provided. These impacting factors and solutions are the input for the transition project from UPC.

3.

Transition Process

At the end of 2008 UPC requested Accenture to reconsider their consultancy rates as UPC needed to lower their costs for the development projects. These development projects were being handled by the Accenture Solution Center in Madrid (SCM). Accenture claimed that there where no possibilities to lower their rates when doing business from Madrid, therefore another option for cost reduction was offered by Accenture. Accenture proposed to migrate from Madrid to the Accenture Indian Delivery Center (IDC), in Hyderabad. Due to the lower prices used in India it would be possible for Accenture to offer these services at lower costs for UPC. UPC was already familiar with the delivery center in Hyderabad as all maintenance projects had previously already been transferred to this center.

UPC accepted the “India” proposal and the associated rates and started together with Accenture this transition project.

In theory there should be no changes for UPC. UPC will still submit their “Statements of Requirements” to Accenture, regardless if this is Madrid or Hyderabad. What is happening behind the “doors of Accenture”, does not concern UPC as long as their requirements are being met. With this construction UPC treats Accenture as a black box: UPC sends their requirements to Accenture and after sometime the requirements will be processed and a “Statements of Work” (SoW) is sent back.

Model 3.1, Black box approach.

Somewhere between UPC and Accenture an exchange of information occurs. In the new situation there will be information transition again. Where and how this is will happen is unknown.

A comparison with the maintenance transition can only partially been made. The maintenance and the development process are too different from each other. The maintenance requests can be classified as small changes. These changes are incidents and errors in the UPC application landscape. At the beginning of a maintenance change, it is known which part of the system is not working properly and what this part of the system is doing under normal circumstances. As a result of this clear situation, it is possible to define more easily the scope of the change. A normal maintenance change will take 1 to 7 days on average.

A development change is much more complex and can be classified as a (small) project. The project time could even run up to more than one year, as a result of this length the upfront scope is less clear. The clarity of the project will be come clear over time rather than it is known upfront. For these reasons (length & complexity) the scenarios for the transition of the maintenance department cannot be re-utilized. However UPC could benefit from the “lessons learned” from the maintenance transition. This can be found in paragraph 5.1 “Input UPC”.

At this moment Accenture personnel, working for UPC, can be found in three different locations: the on-site team’s at the affiliates who also work at UPC headquarters at Schiphol Rijk and at Madrid (Madrid Solution Center). During the first stages of the development process the requirements and architecture are being described in close cooperation by UPC and Accenture. The on-site teams and Accenture at Schiphol Rijk have a leading role during these stages. The Madrid Solution Center has a reviewing function during these stages and provides feedback, to avoid problems at a later stage in the process.

3.1 Development Process

As mentioned before in this chapter, in the current situation the “Statements of Work” (SoW) are processed at Madrid Solution Center. The word “Solution” in the name of MSC is already telling something about the work process of Accenture Madrid. Accenture is delivering “Solutions” in Madrid. The delivering of solutions is related to the quantity of the delivered flexibility. The process Accenture is using in Madrid is very flexible. UPC can send any kind of SoW to Madrid on any moment.

Model 3.2, The Development Process.

that it is not possible. Their process is not capable to process those kinds of change requests. To link this metaphor to the situation of UPC, MSC can be seen as Rolls Royce and IDC can be seen as Renault. And when you really want a roof window at the end building process of your Renault, you will pay a lot of extra money to get it”.

4.

Research Framework (Literature)

In this chapter a literature framework about “Outsourcing” will be build. But before a framework can be build the term “Outsourcing” must be clear first. The first section of this chapter will be used to define “outsourcing”. Together with the benefits and pro’s of outsourcing. Finally, the use of the model implicated in the “Project Method” model (model 2.3) and literature study will be explained.

Unfortunately, the results of an outsource project are not always positive. “Outsourcing investments do not guarantee automatic returns” (lee, Huynh and Hirschheim, 2008). To avoid this, the cons and drawbacks of outsourcing will be defined in the framework. This framework will be build with input form the internet and input form literature, by using the model. From these two inputs, factors will be formed. This will be done in a manner that these cons and drawbacks can be used for further research. The framework combined with the input from UPC will ultimately be faced with the transition project of U, as shown in the model 2.3 “Project Method”.

4.1 Outsourcing

Ever since Kodak’s landmark decision to outsource the bulk of its IT functions in the late 1980’s, IT outsourcing has been a widely publicized practice” (Narayanaswamy and Henry, 2005). More and more companies are outsourcing business processes. The processes that are outsourced can be very diverse. For instance the canteen or facilities of the building can be outsourced. But it is also possible to outsource more “strategic” business processes as IT processes. “The trend toward offshore software outsourcing has been growing steadily since the 1990s” (Hanna and Daim, 2009).

firms that engage in this activity for the reasons of cost reduction and improved performance do not always realize these benefits” (Korrapati, 2009).

To get better results, companies try to focus on their core business. “Concentrate the firm's own resources on a set of "core competencies" where it can achieve definable pre-eminence and provide unique value for customers” (Quinn and Hilmer, 1995). This “Concentration-on-core-businesses-strategy” is only possible when employees are not bothered with not-core-processes.

A company should only focus on the value adding process as Quinn and Hilmer (1995) mention in their article: “Companies maximize returns on internal resources by concentrating investments and energies on what the enterprise does best”. In order to ensure that staff can focuses on the core processes; the company could execute non-core processes to a third company. This third company could be for instance specialized in the companies’ non-core processes. So, this third party can do this process much better than when the company is doing it by itself. Besides, they can do it most of the time for less money. But as mentioned before, there are more win’s possible than only “reducing costs” in an outsource model. The results of outsourcing processes to third companies are very diverse. “Naturally different organizations in different circumstances will expect different benefits” (Kremic, Tukel and Rom 2006).

Outsourcing Benefits − Reducing costs,

− Increased flexibility, − Increased productivity, − Higher quality of service,

− Access to new technology and best talent,

− Ability to re-focus scarce resources onto core functions, − Better accountability and management.

Table 4.1, Outsourcing benefits (Herath and Kishore 2009, Kremic, Tukel and Rom 2006 and Klien 2004).

4.2 Model

Now the definition of “outsourcing” is given and explained, a model should be found/ made to assess and order the factors found in the literature to the input from UPC. This model should be able to include input from the literature as well the input from the internet research.

During the course “ICT Management & Consulting” a couple of maturity models were given and discussed, namely: CMMI, Relationship Maturity Model, COBIT (Control Objective for IT) and Plateau Planning Model. These models confronting the requirements, the Plateau Planning Model came out as most useful. Compared to the other models, the Plateau Planning Model is simple, clear and is capable to adopt inputs from multiple sources. These characteristics are decisive to use this model in this research. In the section below, the Plateau Planning Model will be discussed and explained how it will be used for further research.

4.3 The plateau Planning Model

The plateau planning can be used for controlling and planning changes in processes. The model consist four aspects, which have influence the performance of the organisation. These four aspects: People & Culture, Management & Organisation, Information Technology and Process have to be balanced to get good performance of the organisation. In figure 4.2 the Plateau Planning Model can be found. When there is no balance between these aspects, it will influence the performance and it is not possible to bring the whole organisation to the next level. For example: When a small supermarket wants to start an internet shop, they can use the plateau planning to get all four aspects on the required level. When all four aspects are the right level the shop can launch the internet shop. The shop needs new processes, new (IT) equipment, people who can do the job and the whole new process need to be managed and controlled. In the end, the shop could use the model as an instrument to bring there organisation to a higher level. To better explain this example, the following metaphor can be used: When a puppy grows, all four legs should grow equally. But for example when one of the four legs grows longer or shorter than the other ones, the dog can not perform properly. These legs are comparable to the four aspects in the Plateau Planning. So when there is no balance between the four aspects, there will be no performance.

be used. First the model will be used to structure the outcomes from the literature study and the internet research. Second, the input from UPC must be structured for farther research. By using the same model for both inputs, the execution of the delta analyse should go easier.

Finally, the plateau planning will be used after the Delta Analyse to structure the outcomes. And to find out if there are any factors/ Impacts that unbalance the model.

Model 4.2, Plateau Planning.

As mentioned above the plateau Planning model consist four aspects, these aspects will be elaborated in the following paragraphs.

4.3.1 People & Culture

The people/ Staff of an organisation need to have the right knowledge and skills to run the processes properly. For example, when the staff is not qualified to do the job properly, this will impact in the performance of the organisation. Besides, the Staff should have responsibilities to improve the processes and achieve the prescribed standard.

4.3.2 Management & Organisation

Middle management monitors the process and initiates process improvements where possible. Next to that, the processes are in line with the organisational structure.

4.3.3 Information Technology

The “IT-design” is part of the organisation; therefore the IT-design must be in line with the organisation process. Besides, the IT system(s) deliver management information about the system and the process.

4.3.4 Process

The processes how an organisation act and how it works should be clear. And these processes should be clearly described. When the processes are clear, then everyone knows where the stand. So when there are uncertainties, it is possible to revert to the determined process.

Besides a clear process, critical success factors must be clear as well and should be part of the process.

Now all aspects are given and explained, the plateau planning can be imported into the project method model, as given in paragraph 2.1 “Methodology” (Model 2.4, Project method including Plateau Planning).

4.4 Literature & Internet Input

To avoid double text, the input from the literature and internet will be combined in one chapter.

Information from internet sites or internet forums is not scientific. This could be a problem in a scientific research. However, this information will used as support next to the information from the literature study.

The use of information from the internet also has benefits. The information is most of the time clear and up-to-date. Besides, the information comes most of the time from practical example of real life stories. The biggest problem of non-scientific input is the exposure of emotion. This could impact ability of the information. But combined with literature it is certainly useful.

4.4.1 The searching procedure

keywords have been used or combined: outsourcing, offshore, onshore, India, culture, communication, success factors, benefits, risks and IT.

Besides the literature found by the search engines, other literature was found in the references lists of this literature. Outsourcing exists now for about thirty years, where the last fifteen are more appealing. It is attempted to use only up-to-date or latest literature in this research. Despite that, old literature showed to be usable as well.

A lot of articles were checked for factors which could impact the performance of UPC. Based on relevance’s for the UPC transition project, factors where selected from the literature. The selection of a factor or not selecting a factor was made by the author of this thesis, based on the relevance. The author of this thesis also tried to make the list of impacting factors as complete as possible. It could always be the case that a factor is has been over looked. Besides, the relevant factors could change over time, so reuse of the impacting factors for future transition project is not possible.

The internet research was not that structured as the literature research, as result of links used on the different internet sites. During this internet research Google has been used to find interesting internet sites. To find these sites, the same keywords were used as during the literature study. Very different kinds of information about outsourcing was found on the internet, where some information was comparable to scientific information other information was not usable by influences of emotion. For that reason is chosen to use only internet articles with a good structure and background references and no discussions where emotion predominates.

The use of internet resources are indicated by a numbers, this number refers to a number in the literature list in the appendix that shows the internet site.

4.5 People & Culture

This aspect will be divided in to two paragraphs: “People” and “Culture”.

4.5.1 People

factors with humanitarian characteristics will be discussed, followed with impacts on the culture side.

“While it may be typical to have English as a second language, in many countries it is not the case everywhere” (Hanna and Daim, 2009). This is not really the problem in India. “English is widely popular in India, the main issue is the accent they speak with” (1). Despite the major investments from outsource vendors in India to improve the English of the employees; this is still a big issue. In one of the internet stories (2) the following quote came up: “There was one Indian fellow no one could understand him over the phone. It took us months to figure out what he was saying”. Even if they speak the same language, for example English in the case of UPC, it is possible that people do not understand each other. As a result of this wrong or non understanding, it could possible result in mistakes and failure. As Hanna and Daim (2009) mention: “Good communication between the two parties is essential to progress”

The risks of poor communication in an offshore outsource situation can be found in the example below. In this example, the problems arose, when the call center agents from Dell did have a lack of English speaking abilities.

After an onslaught of complaints, computer maker Dell stopped using a technical support center in India to handle calls from its corporate customers. Some U.S. customers complained that the Indian technical-support representatives were difficult to communicate with, because of thick accents and scripted responses.

CNN, November 25, 2003

The example above again indicated the importance of good communication. In this example the call center agents were even supposed to communicate with people from the U.S. and probably recruited based on their knowledge and language skills. And even here problems arose.

Face-Face contact can be very important to improve the communications. This face-to-face contact can be very hard to organise, when it is difficult to travel between two locations. For example, this can be caused by: the long distance, multiple time-zones causing jetlags, visa procedures and expansive flights. However: “The ability to identify a face with a voice fosters better communication” (Hanna and Daim, 2009).

Next to the communication skills of the Indian employees, the professional IT skills are important too. Lucky enough, there are enough people in India who have good professional skills. “No matter what skills you are looking for, there will be at least 10,000 people who have it. The supply if IT talent in India is Outstanding (1)”. But on the client side of the project, in this case UPC, the employees should have some professional skills, so they can deal with the new outsource situation. According to Herath and Kishore (2009) this is one of the outsource risks: “degree of expertise in outsourcing and IT operations on both client and vendor side”.

4.5.2 Culture

“Culture plays a role in both the quality of the delivery and the ease of process management” (Hanna and Daim, 2009). “When outsourcing to another country, it is essential that management plan for and indentify potential risks associated with cultural differences and geographic barriers” (Johnston and Johnston, 2006).These cultural differences and geographic barriers could causes problems. According to a survey from the internet forum “Outsource Center” (4), 5 % of all outsource failure are caused by poor cultural fit. Because of this, impacts related to these subjects are getting more important. “While cultures change slowly, the effect of cross culture issues on “Information System Development” projects have quickly become more important” (Narayanaswamy and Henry, 2005). But how can culture be defined? Hofstede (1980) defined culture as: “a collective programming of mind which distinguishes the members from one group or category of people from another”. During the literature study and internet research the following problems/ factors came up.

People from India are known humble behaviour. This behaviour will impact the working relation with employees from UPC.

client. The client will in fact use this information for planning and controlling his side of the project.

A similar problem is delaying of bringing bad news. In many occasions, negative announcements will be obvious when the client and vendor are facing a deadline. On that moment the vendor has to come up with the actual project status. At that time, it is already too late and as a client you will face a new problem or the project will delay. “While the times of chopping off bad news heads are over, the habit is still there. So if you do not hear about bad news, it doesn’t at all mean that everything is going well, it just simply means that you do not hear/ do not know what is going on (1)”. In an earlier quote, Grosse (2002) already mentioned the importance of asking clarifications. On this point there is an overlap with the aspect “Process”, because getting the right clarifications should be part of the process.

It is clear that these problems should be avoided. According to Narayanaswamy and Henry (2005): “It is vital to understand the cultural differences for Offshore Outsources IT Projects to be successful”. But this cultural understanding should not only be known at higher management. “All team members need to understand how cultural differences affect team dynamics and individual ideas about how teams should function” (Grosse 2002). When cultural differences are known at all levels of the organisation, all employees should know how to handle with these differences.

Unfortunately, it is not possible to change the culture of the employees of the vendor on short notes. “Forcing people to go against their culture will be met with resistance and conflicts” (Johnston and Johnston, 2006). Given that it is not possible to change it, it is necessary to manage it. This is for instance possible by putting the right people on the case. “Involve people who bridge the cultures. For example, people originally from India, but with higher education and long-term residence in a western country, have been reposted to India as expatriate managers for outsourcing projects” (Hanna and Daim, 2009).

Besides the disagreements between India and Pakistan, terrorism is a major risk in this region. In 2008 there was a big terrorist attack on Mumbai. In these attacks 173 people were killed (11). Such incidents could happen again in the future and disrupt development processes. And it seems likely that these problems are not resolved in the near future. In the time the tensions were high between India and Pakistan, it impacted the software sector. “Reports at the time confirmed the hardest hit sectors in India were software services and tourism” (Rai, 2002).

Factors

− Language/ Accent/ Communication (level of English speaking skills). − Professional skills of vendor and client employees.

− Check for understanding and clarifications during communication. − Understanding of cultural differences.

− In possession of people with knowledge of both cultures. − Political stability.

4.6 Management & Organisation

When a company outsource a process to another company, even if there is a very good relation with this vendor, it does not mean that it does not need to be managed and checked. “It cannot be assumed that a trust-based relationship always leads to successful results in outsourcing” (lee, Huynh and Hirschheim, 2008). A good and trust-based relation can off course contribute to the success of an outsource project. The basis for a good cooperation between client and vendor would be a good contract. In the end, a poor contract affects both sides, the vendor and the client. “In general, outsourcing contracts are designed on the basis of certain assumptions and hence carry inherent risks owing to a limited understanding about the future” (Das Aundhe and Mathew 2009). On the moment an outsource deal is signed, the relation between the two parties could be very good and trustful. But during the project this relation could chance. On that moment a proper contract can be very useful. According to Johnston and Johnston (2006), a poor written contract is responsible for many failures. “The contract should be as complete as possible, incentive based for the vendor, balanced, and flexible” (Johnston and Johnston 2006).

When the contract is clear, both sides should have the same expectations about the project. The expectations should be know in advance of the project. 23 % of all outsource projects fail on the clients’ unclear expectations up front (4).

For manager an outsource project can be very difficult and complex to manage. There are so many things/ factors that influence the success of an outsource project. A good example is this literature study; it shows many factors that impact the process. Since all these factors can impact the project they should be managed by the manager. Herath and Kishore (2009) mention management complexity as one of the many pitfalls during an outsource project: “management is inherently difficult in the complex offshore process with multiple development centers in different time-zones, continents, and cultures”. So management should have the personal capabilities managing a project like this (here is an overlap with the aspect “people”) and besides, management should have the possibilities to manage the project. Therefore control mechanisms and good governance are necessary. These control mechanisms should be adjusted to every individual project. “Creating a fit between culture differences and control mechanisms will help managers in successfully managing OOISD (Offshore Outsource Information System Development) projects” (Narayanaswamy and Henry, 2005).

Good governance is very important and should be managed properly. According to “Outsource Center” (4) 13 % of all outsource projects fail on poor governance.

A giant telecommunication company failed in there outsource transition because they did not consider the fact that the new outsource provider did not understand their business side of there organisation. “The contract was executed from a business perspective, where it looked great, but not enough thought was given to how to programmatically mote to the new environment”. What happened: a lot of processes where moved to India, but what was left behind in the USA was the knowledge. As a result of this, the time spent on developing new applications increased, just as the costs. In the end, the company cancelled half way the transition and moved it back home. As a result of this failure they lost millions of Dollars (2).

Factors

− Good and complete contract.

− Possibilities to manage and the ability to give direction of the project. − Well organized governance system.

− Knowledge on the right place.

4.7 IT

Working on more locations requires a proper working infrastructure. “When data from different global locations are accessed and consolidated, it requires well-defined and highly compatible global data standards. Furthermore, issues may arise due to lax or primitive legal systems regarding data sharing”(Herath and Kishore, 2009). Coward (2003) makes distinguishes between two kinds of infrastructures; intangible infrastructure and physical infrastructure.

The first kind of infrastructure, communication/ software infrastructure, contain items as: internet connectivity and standard software. The second kind of infrastructure divided by Coward, physical infrastructure, contains: desktops, server, network and power supplies.

It is obvious that all components should meet an agreed quality. Each independently component could impact the end result. For that reason, it is necessary that both infrastructures guarantee at least the same quality as in the current situation, or even better.

To achieve this quality costs could rise. For example, a reliable power supply in western European countries is common. In many other countries this is not the case. To avoid problems additional solutions needs to be provided, what could end up in extra costs for the customer. ”Private companies’ build the expense of generators into the cost of doing business, so ultimately is does have an impact on the price they can offer” (Coward, 2003).

Besides, proper working infrastructures today could be insufficient in the future. Increasing demand and use of the IT network in the future should take into account. “Current outsource needs could be fulfilled by substandard telecommunications services, future outsourcing tasks will likely require higher levels of service and greater bandwidth” (Coward, 2003).

Factors

4.8 Process

The IT development process consists most of the time common stages, as: setting Requirements, Higher Level Solution Architecture & Definition, Functional & Technical Design, Building and testing. The first stage setting requirements can be very important; all the following stages depend on this stage. Poorly articulated requirements and inadequate requirements definition are a risk for outsourcing failure (Herath and Kishore, 2009, Kremic, tukel and Rom, 2006). “Ambiguities in requirements capture may alter the scope of the project and thus affect schedules and budget” (Das Aundhe and Methew, 2009).

Client employees should not hesitate in sharing information with the vendor employees in general, but especial at the beginning of a new project. “Reluctance on the part of the client employees in sharing context related information at the beginning of a project poses considerable risk for the service provider in offshore projects” (Das Aundhe and Methew, 2009).

In an outsource project, the (strategic) information that is shared with the outsource vendor should be safe and protected from other companies/ competitors. “A major risk of outsourcing, whether domestically or offshore, is revealing confidential information and competitive strategies” (Johnston and Johnston, 2006). The process can very important to secure this information. Besides there is an overlap with the aspect “Management & Organisation”, how strictly this process is managed and controlled. The example below shows the risks of having bad agreements with the vendor.

In the 1980s when IBM was developing its personal computers, it decided to outsource the production of its microprocessor and the development of its personal operating system to Intel and Microsoft, respectively. Although IBM did not know at the time, giving up control of these two components allowed competitors, like Dell and Compaq, to purchase the components and duplicate them. The result is that IBM today is only the third-largest maker in an industry that it created.

(Johnston and Johnston, 2006)

vendor is developing something new in the time the vendor is working for your company. It must be clear who is the owner of this new property.

Time differences could have impact on the process. The use of new techniques does not solve always this problem. “The difficulty of working across time zones is yet further evidence that the Internet does not entirely dissolve time and distance” (Coward, 2003).The following example shows the impact of time differences. A marketing company, MakretingHelpNet, moved some of their processes to an offshore vendor in the Philippines. The president of the company tells the following story (2): “We weren’t able to communicate directly, only through Instant Messenger. And as a small startup at the time, we couldn’t support multiple shifts at home to get overlap with the Philippines, nor ask the staff to work 20 hours a day to cover both time zones”. To avoid problems with time differences many companies avoid outsourcing vendors in a different time zone. “The impracticality of 24-hour development cycles helps explain the growing demand for “near shore” outsourcing” (Coward, 2003).

Factors

− Inadequate requirements definition. − Intellectual property rights protection. − Time differences.

5.

Collecting Data

In this chapter the input from UPC will be elaborated. Finally a factor overview will be given. In this overview the factors from the literature and internet study will be combined with the factors from the Input of UPC.

5.1 Input UPC

The input from UPC will come from two sources: Review from the maintenance transition and from the current process.

5.1.1 Review Maintenance Transition.

Since 2008 Application Maintenance (AM) is processed in India at India Delivery Center (IDC). As mentioned before these “Statements of Work” are less complicated comparison to the ones from Application Development (AD). As a result of these differences, the transition scenarios are not re-usable. Nevertheless, UPC wanted to learn from a year outsourcing to India. For this reason there has been made a review. These outcomes could be useful for the Development transition as well, for this reason the outcomes of this review will take into account.

The important outcomes of this review were:

− Low IDC knowledge of Affiliates business processes.

The employees in India do not know what is happing in Europe. As a result of this, they do not understand the business processes. In the case of the nearshore engagement / the situation before the transition, when the assignments were processed in Madrid, it was possible for developers/ analysts from Accenture to travel to UPC affiliates. This resulted in more knowledge about the affiliates business processes. The most problems that arise by this imperfection are solved by the Accenture supervision team located at the headquarters of UPC in Amsterdam.

− Strict Process orientation.

IDC is providing UPC with a very processed orientated service. This way of work has advantages and disadvantages. The most important disadvantage is the restriction of flexibility it caused.

− Nominal time zone impact on day2day business.

India. On the other hand it is possible to test patches and faster turnaround on scheduled fixeses in the early morning.

5.1.2 Impacts transition on development process

Besides the lessons learn from the maintenance transition another factor was found through analyzing the current and new process in chapter 3.

− Loss of flexibility

Accenture will change their process from a “solution oriented” process in to a “factory oriented” process/ “Strict Process orientated” process, as can be found in paragraph 3.1, “Development process”. This process change will probably impact the UPC process. Trough a loss of flexibility UPC is not capable to change the SoW when these are already sent to IDC. But when these SoW need to be changes, it will be more likely that it costs will be higher then in the Madrid situation. These extra costs could annul the reduced costs of the transition to India.

As a result UPC should take this Accenture process change into account. Besides, the requirements set by UPC should not be changed after the SoW is sent to India.

5.1.3 UPC input factors summary:

With the discussed input from UPC, the factors summary below can be given. Between the brackets it is indicated at which aspect of the “Plateau Planning Model” the factor is located.

− Low IDC knowledge of Affiliates business processes (Management & Organisation). − Strict Process orientation (Process).

− Nominal time zone impact on day2day business (Process).

5.2 Factors overview

When the factors from the literature study, internet study and the UPC input factors are structured along the four aspects of the “Plateau Planning Model”, the following plateau overview will arise:

5.2.1 People & Culture

Language/ Accent/ Communication (level of English speaking skills). Professional skills of vendor and client employees.

Check for understanding and clarifications during communication. Understanding of cultural differences.

In possession of people with knowledge of both cultures. Political stability.

5.2.2 Management & Organisation Good and complete contract.

Possibilities to manage and the ability to give direction of the project. Well organized governance system.

Understanding of the business side of a company. Knowledge on the right place.

5.2.3 IT

Proper intangible infrastructure. Proper physical infrastructure.

5.2.4 Process

Adequate requirements definition. Intellectual property rights protection. Loss of strategic information.

Time differences.

The ability of (direct) communication.

Loss of flexibility through a different process (Solution orientated process vs. factory oriented process)

6.

Delta analysis

In this chapter the factors mentioned in the previous chapter will be evaluated leading to the conclusions which are relevant for UPC. This is done by interviewing people from UPC and Accenture. The results of these interviews are used to cover all the factors. Some factors will not impact the transition project, these factors are already covered in the new situation and do not need extra attention. Other factors could impact the transition project and will be elaborated in the following chapter, so they can be covered in the future. These impacting factors will be given in a summary at the end of this chapter.

Some factors are highly related, to avoid double texts, some factors are combined.

6.1 People & Culture

6.1.1 Language/ Accent/ Communication (level of English speaking skills).

Communication between UPC and IDC will be difficult. The problems will mainly arise during direct communication by example communication through telephone. Written communication by example email will not be a problem, these skills are on a good level.

During the transition to Madrid, UPC employees faced difficulties related to English speaking skills form MSC personnel as well. It will cost some time to learn how to communicate directly. Accenture will try to improve the English speaking skills of their IDC employees by giving them English courses. The UPC employees working on maintenance changes know that they have to speak very slowly. And that they need to tell the people from IDC do the same. By speaking slowly most communication problems will be avoided.

6.1.2 Check for understanding and clarifications during communication.

People from India are known by their humble behaviour. It is very difficult for them to say “no”, this behaviour could cause problems. To prevent problems the process should contain steps where UPC is checking for understanding and clarification. On this moment, UPC did not change the process compared to the process used with MSC.

asking clarification. Besides, this could be very strange for other parties/vendors involved, for example during a conferences call.

6.2.3 Understanding of cultural differences/ In possession of people with knowledge of both cultures.

On the side of Accenture (on-site team) there are a couple of people with a background in India. Beside, all the employees from Accenture working with people from IDC had courses to understand cultural differences. In these courses they learn about the differences in cultural and business. Besides, they learn how to deal with these differences.

On the side of UPC, there are currently not a lot of employees with knowledge about cultural differences. Senior management visited India a couple of times. All the other UPC employees dealing with IDC have never visited IDC.

Besides, there are no employees from UPC who have a background or origin in India. This ignorance could lead to failure, problems or miscommunication. UPC should be aware of these problems and should train their employees or start sending employees to India for short period or hire people with knowledge of cultural differences.

6.2.4 Professional skills of vendor and client employees/ Knowledge on the right place.

In preparation to the transition, Accenture is training the employees in India. The Employees in Madrid are part of this training. There are two “Waves” in this training. During the first wave employees from India move to Madrid to learn from the employees in Madrid. During the second wave the employees from Madrid move to India to train and help the employees there.

It is possible to train the people in India to an IT knowledge level comparable to the level of the employees in Madrid. But, besides the level of IT knowledge, experiences from previous SoW are missing. These experiences can be very important to avoid mistakes in the future. So, there must be a way to save these experiences for the future. For example, MSC could participate for the time being during the first stages of the development process. They could review the work of IDC till IDC is having the same skills as they have at MSC.

6.2.5 Political stability

The internal political stability of India is in generally stable. However, the increasing of terrorism action in the area in and around India could be a problem. The political tension between India and Pakistan could blaze up in the future. Besides, the instability in Pakistan caused by the disagreement of the fight against terror could result in more terrorist activity. Hyderabad the location of IDC is located in the middle of India. This has an advantage comparison a location close to the coast or border. As in Mumbai were terrorist enter the country from the sea. The process in Hyderabad is unlikely to be impacted by any terrorist action. But a terrorist attack some where else in India could impact the travel to India. Fortunately, there will not be much travelling between Europe and India, so the impact will be negligible.

All the employees of IDC are provided with laptop, so they can work from home when travelling to the office is not possible. So, during any occasion of trouble, the process will minimum been impacted.

6.2 Management & Organisation

6.2.1 Good and complete contract.

The contract UPC and Accenture have agreed, meets the requirements mentioned in the literature study. Besides, when there is a disagreement, UPC and Accenture are so integrated and dependent to each other, that they will first find another way to solve the problem before they will take the contract to sue each other.

The contract is already signed for the development transition. As a result it is not possible to make changes in the contract when that would be necessary according this project.

6.2.2 Possibilities to manage and the ability to give direction of the project.

As known, the process on Accenture side will change in the new situation. The process of Accenture will change from a solution orientated process to a factory orientated process. As a result, no changes can be made during the build stage. This will impact the whole process. The previous stages of the building stage will be more important, during these stages there should be more abilities to manage and control the process, to avoid problems in the building stage.

6.2.3 Well organized governance system.

UPC will use the same governance system as using for MSC. Accenture will keep on updating UPC on the progress of the project. This will be done by reporting status rapports and conference calls.

The governance system is also responsible for the way UPC is managing Accenture. According to the contract, UPC should only have to deal with the on-site team. This on-site team from Accenture should be the interface between UPC and Accenture (MSC and IDC).

UPC should officially not communicate with MSC or IDC, but all the communication should go through the on-site team (OST) from Accenture. And the OST should manage and communicate with MSC or IDC.

Unfortunately, (as mentioned in the factor ‘Knowledge on the right place”) due to a lack of technical skills in the OST, UPC is forced to communicate directly with MSC or IDC. UPC needs to do this to get answers on technical questions that cannot be answered by the OST. This direct form of communication is necessary in certain “very technical” cases and is currently being tolerated by UPC. The alternative “refusing direct communication” or “improving the technical skills” could result in errors in communication or increasing of costs for the OST. These increased costs will in the end be passed on to UPC; undermining the benefit of the cheaper resources in India.

This Lack of technical knowledge could result in strengthening of some factors; where UPC normally could communicate with the OST it is necessary to communicate with IDC, with associated consequences.

6.2.4 Understanding of the business side of a company.

IDC employees will find difficulties to understand what is happening at UPC in Europe. This is a result of doing limited and small assignments of the whole project. This problem could result in a lack of understanding of the business side and understanding of the big picture (overview). Which could result in less quality, because the employees can only give feedback on their part of the project but not on the whole project.

training. According to Accenture, these trainings should be sufficient to avoid problems. But according UPC and Accenture personnel, the best way to cover this factor is to bring over IDC personnel to experience UPC in Europe.

6.3 IT

6.3.1 Proper intangible infrastructure.

IDC will work with the same standard software and programs used in MSC. So there will be no changes at this area. IDC personnel are trained for these applications and programs during the training waves between India and Madrid.

The internet connectivity in India is reliable; this is a result of more connection cables between India and the “world”. What will work as a back-up when there is a problem with an one of the other cables. The situation in India is comparable to the situation in Madrid, so it will not impact the process.

6.3.2 Proper physical infrastructure.

The IDC employees will have their own laptop. These computers will meet the requirements necessary to do the job. This will also apply for the server and network used at IDC.

Electric failure is very common in India. To avoid problems caused by an electric failure, Accenture have a back-up, consisting several generators located at the office.

6.4 Process

6.4.1 Changes in process

In this paragraph it is possible to combine two factors; Loss of flexibility through a different process, (“Solution orientated process” vs. “factory oriented process”) and the factor ‘Strict Process orientation”.

any request or document made during the stages: requirement setting, HLSA, HLSD, FD and TD, on the moment the SoW is sent to IDC.

The development process is one process. As known, in this process there are two parties involved; UPC and Accenture. Both parties are responsible for different pasts of the process. As a result, both companies’ processes are very integrated. Accenture and UPC are so integrated that when one of them changes their process the other party should act on that. So, if UPC does not react on changes at Accenture, UPC could face problems when the transition is made.

The consequences of the reduced flexibility are that the next factor, “Adequate requirement definition”, will have a crucial role and needs extra attention. When the first stages are correctly completed, no change during the build stage should be necessary. Besides after the technical design there should be an important approval from all the involved departments. This to avoid any changes during the build stage as well.

6.4.2 Adequate requirements definition.

As can be seen in model 3.2, “The Development Process” there are more stages before the building stage than only setting requirements. All these stages should ensure that requests from the affiliate are well defined. These proper definitions should avoid changes later in the process. During this process the HLSA (High Level Solution Architecture) is used at UPC as the central document which maps the “Business Requirements” and the “Business Scenarios” into the “Application Architecture”.

The goals of a HLSA are:

− Provides a synthesised view of the new/ changed system − Define a workable solution architecture (High Level)

− Provide an overview of which “Business Requirements” and “Business Scenarios” are covered in the solution

− Provide an overview of the impacted Application Architecture

− Provide the vendors with enough information to write their functional and technical designs.

technical design. During this process information from the affiliate is lost in the process. Resulting in a SoW sent to MSC that is not conform the requirements set by from the affiliates. When these “not conforming” requirements are noticed during the building stage, the SoW needs to be changed.

6.4.3 Intellectual property rights protection/ loss of strategic information.

Accenture is a big and important outsource vendor in the communication branch. They provide many clients with their services. It is possible that Accenture employees are working for more clients. In this situation there is always a possibility to lose important strategic information. Or the SoW processed for UPC are re-used for another client with a similar SoW. In the case of UPC, any developed SoW produced by Accenture for UPC is owned by UPC. This is stated in the contract between UPC and Accenture. This should avoid re-use of intellectual property of UPC. Unfortunately, UPC can not avoid that Accenture employees re-use there experience gained during UPC SoW.

Accenture is using internal processes that avoid any loss of strategic information of one of their customers. For Accenture it is important that they are not involved in a case where they are suspected from losing strategic information. This could result in a loss of costumers. Besides, the employees involved in such a case surely losing their jobs.

The work processed by Accenture is specialized for UPC. It is already difficult to reuse software for the different affiliates; they all have too many exceptions. As a result of exceptions between affiliates or other companies, it is not possible to copy the work and reuse it.

6.4.4 Time differences.

To avoid problem related to time differences, IDC is going to work European times. This will mean that there are always people in Hyderabad at work during normal European office hours. These office hours at India should avoid “time difference” problems and not impact the process. Besides, the workday at IDC could be extended when there a morning crew as well. Resulting in longer working day what could end in quicker deliveries.

6.4.5 The ability of (direct) communication.

high. Next to that, there are problems with time differences (jetlags) and visa issues. These restrictions will limit the amount of travel to and from India.

This non-travel situation will not benefit to the understanding of the cultural differences, early mentioned. But, there is always direct communication possible by phone. So when ever it is necessary to have direct communication it is possible, also referring to the factor above.

To avoid problems concerning the ability to communicate, UPC should look for new techniques to overcome this problem.

6.5 Summary of factors that need extra attention.

As a result of the “Delta Analysis” the following factors need extra attention:

− Communication.

− Understanding of cultural differences.

− Checking for understanding and clarifications during communication. − Knowledge on right place.

7.

Managing Impacting Factors

In the previous chapter all the factors have been mapped with the transition situation within UPC. As a result of the Delta analysis, some factors are already covered or do not impacts the transition project, where other factors need extra attention. In this chapter the remaining factors will be examined further to find out “How the unbalance of the factors should be restored”. Three of the aspects of the Plateau Planning are out of balance, respectively: “People & Culture”, “Process” and “Management & Organisation”. Within the aspect “Information Technology” no factors are found which could impact the transition, therefore these factors have not been detailed further.

With the knowledge gained from the “Delta Analysis”, it is possible to provide an advice on multiple Plateau maturity levels, as is displayed in model 7.1 below. Plateau 0 is the current situation, where Accenture is using the delivery center in Madrid. This plateau is characterized by high flexibility and relatively high costs. The outsource transition is forcing UPC to go to a higher and more mature plateau. In order to achieve at a higher plateau level, it is necessary that there is a balance in the four aspects.

P

LATEAU

P

LANNING

M

ATURITY

PROCESS Performance of the Organisation INFORMATION TECHNOLOGY MANAGEMENT & ORGANISATION PEOPLE& CULTURE PROCESS Performance of the Organisation INFORMATION TECHNOLOGY MANAGEMENT & ORGANISATION PEOPLE& CULTURE PROCESS Performance of the Organisation INFORMATION TECHNOLOGY MANAGEMENT & ORGANISATION PEOPLE& CULTURE PROCESS Performance of the Organisation INFORMATION TECHNOLOGY MANAGEMENT & ORGANISATION PEOPLE& CULTURE PROCESS Performance of the Organisation INFORMATION TECHNOLOGY MANAGEMENT & ORGANISATION PEOPLE& CULTURE

Ma

tur

ity

Plateau 0, Current situation

Plateau 1, Managing the “Core”

Plateau 2, Managing the “Interface” Plateau X

Plateau .