Project Failure Rowlands

iStephen Rowlands 2005 BSc Business Information Systems

A Study Of Change Control And How ItCan Intervene In Scope Creep, ToReduce The Risk Of Project Failure

Submitted By: Stephen Rowlands

Submitted In Partial FulfilmentOf The Requirements For The Degree

BSc (Hons) Business Information Systems

Leeds Metropolitan UniversityMay 2005

This document is Copyright of the author and Leeds Metropolitan University and protectedunder UK and international law. The UK Copyright Service and Leeds Metropolitan Universityrefuses permission for this information to be reproduced for personal and educational useprovided all copies, extracts or adaptations Copyright The UK Copyright Service and LeedsMetropolitan University. Commercial publication, copying, hiring, lending and reproduction isstrictly prohibited and constitutes a breach of copyright. This document is protected by copyrightlaw.

Document Distribution Tracker: DDT-450034-EE

ii

Stephen Rowlands 2005 BSc Business Information Systems

Acknowledgements

I would like to thank the following people for their assistance and help throughout thecompletion of this study.

My initial point of contact and personal supervisor Paul Smith, for his help andguidance which enabled me to complete this project.

My case study organisation and it respective employees, who have been extremelyaccommodating and helpful in aiding me with my primary research.

My parents and family for their support.

iii


Plagerism Disclamer

I certify that all material in this individual project which is not my own work has beenidentified and properlyattributed.

Signed:

Date:..

iv


Abstract

This project focuses on IT project failure, as many IT projects are still continuing to failtoday. It will discuss the causes of project failure and particularly look at prior researchon scope creep and the escalation of commitment to a failing course of action. Thesehave been identified as two significant causes of project failure. The secondary researchwill look at how these two causes of failure may be managed, and recommend using achange control system to do this. Qualitative primary research will be gathered from acase study organisation by the use of interviews. These will look at the case studyemployees opinions and features of their change control practices. This evidence canthen be compared to the existing research, to try to satisfy the projects aim andobjectives.

vStephen Rowlands 2005 BSc Business Information Systems

Table of contents

Chapter One: Introduction

1.0 Background 2

1.1 Aim and Objectives 4

1.1.1 Discussion of the aim and objectives 4

1.2 Indication of the following chapters 5

Chapter Two: Methods

2.0 Introduction 8

2.1 Secondary Research 8

2.2 Primary Research 9

2.2.1Ethics and considerations when conducting primary research 102.2.2 Quantitative or qualtative research methods 102.2.3 Sample for primary research 12

2.3 Limitations and critical analysis 13

2.4 Conclusion 14

Chapter Three: Literature Review

3.0 Introduction 16

3.1 Project Failure 17

3.1.1 Reason for Project Failure 183.1.2 Reducing Project Failure 21

vi


3.2 Scope Creep 22

3.2.1 Defining Scope Creep 223.2.2 Why scope creep occurs 233.2.3 Understanding scope creep 233.2.4 Controlling scope creep. 243.2.5 Summary of scope creep 253.2.6 Scope creep and relations to project escalation 25

3.3 Project escalation 26

3.3.1 Recent examples of escalation 273.3.2 Reasons why Escalation happens 273.3..3 De-Escalation. 30

3.4 Change control. 34

3.4.1 Benefits of Using a Change Control System 353.4.2 Features of a Good Change Control System and best practice 36

3.5 Conclusion 39

Chapter Four: Findings

4.0 Introduction and background 42

4.1 Perceptions of Change Control 43

4.2 Discussion of findings 44

4.2.1 The structure of Pharmas change control 444.2.2 The importance of formality in a change control system 474.2.3 Deviations to change and emergency procedures 494.2.4 ERP and the need for controls 504.2.5 Soft and hard controls of a change control system 514.2.6 Change control and effects on scope creep 53

Chapter Five: Conclusion and Reccomendations

5.0 Introduction 56

vii


5.1 Evaluation 56

5.1.1 Secondary research 565.1.2 Primary research 57

5.2 Reflection of the aims and objectives 59

5.3 Conclusion 60

Bibliography 62

Appendices 67

Appendix A, Proposal 68

Introduction and background 68Aim 69Objectives 69Research Methods. 70Schedule of key tasks. 74Bibliography 75

Appendix B, Interviews 76

Appendix C, Change Request Form (GAMP4, 2002) 85

Appendix D, Change control system. (Maylor, 1999) 86

1Stephen Rowlands 2005 BSc Business Information Systems

Chapter One

Introduction

1.0 Background 2

1.1 Aim and Objectives 4

1.1.1 Discussion of the aim and objectives 4

1.2 Indication of the following chapters 5


Introduction

1.0 Background

Due to the fast pace of changing technology in todays world, many organisations find

themselves at a stage where they may have to introduce, update and sometimes replace

their existing IT / IS (information technology / information systems), to maintain their

status and continue to be effective in todays competitive business environment.

The existence of an organisation crucially depends on the effective applicationof information Technology (IT). With the emergence of e-commerce, the use oftechnology is becoming just an accepted, indeed expected, way of conductingbusiness. Consequently organisations are increasingly looking towards theapplication of technology not only to underpin existing business operations butalso to create new opportunities that provide them with a source of competitiveadvantage. (Ward and Peppard 2002 p.1).

Due to this, companies will find themselves at a stage where they have to manage an IT

project to successfully implement a new system, or make changes to an existing system.

Therefore, you would expect large companies to manage their IT projects and

implement their IT systems effectively. However many of these projects are still

continuing to fail and enduring the worst failure rate of any industry, costing far more

than agreed (Watton, 2003). There are many reasons why IT projects are continuing to

fail, but it appears that projects running over budget, over schedule, and increasing

project scope are some of the major reasons of project failure (Hallows 1998 and Holt

2003).

This study will look at the area of project failure and how scope changes described by

Hallows (1998) and Holt (2003), contribute to the high failure rate of IT projects. This


project will also look at a case study to analyse the complexities of change control and

how the case study organisation uses change control as a method to control scope creep,

to help contribute to the success of a project.

The researcher will use a leading worldwide pharmaceuticals company for the

individual projects case study. This company will be referred to as Pharma throughout

the study. The researcher has worked for the companys SAP Security team during his

Industrial placement, helping develop SAP systems for their marketing and

manufacturing business areas. During his time spent with Pharma the researcher worked

alongside their change control process. During this time he realised how a good change

control system contributed to the success of an IT project implementation.


1.1 Aim and Objectives

Aim

To study the area of project failure, to asses why projects are still continuing to fail. It

will also look at scope creep and highlight any links that it may have to project

escalation. It will then use a case study to help understand how change control can be

used to intervene in scope creep, and therefore reduce the risk of project failure.

Objectives

1. To discuss why many IT projects continue to fail.

2. To investigate the factors of scope creep and highlight any links to project

escalation, which is a cause of project failure.

3. To analyse how change control systems can reduce project scope creep.

4. To analyse Pharmas change control process in relation to recommended best

practices and evaluate if change control can help reduce scope creep.

1.1.1 Discussion of the aim and objectives

The aims and objectives have been structured to allow the reader to gain an

understanding of the topic of project failure, and then focus on a cause of project failure

called scope creep. It will discuss what links scope creep has to other areas of project

failure, such as project escalation. Upon the understanding of how scope creep occurs

and ways in which it can be reduced, the final objective is to consider change control as

a method for controlling scope creep, to reduce the risk of project failure.


Objectives one to three are unchanged from the individual project proposal in appendix

A. However objective four has changed slightly from the original proposal. Objective

four initially proposed that the study would evaluate the effectiveness of Pharmas

change control system in relation to project scope creep, and it would also highlight any

other benefits of using a change control system. Therefore, it was decided that a

framework would be needed to evaluate the effectiveness of Pharmas change control

system. As the researcher doesnt have any experience or knowledge of any known

frameworks to do this, the objective was too complex for the researcher to undertake

and therefore the objective had to be tailored to best suit the individual project. It was

decided that the researcher would look at authors recommended best practices of change

control, and analyse Pharmas change control processes in relation to these

recommendations. Following this the researcher would also evaluate if Pharmas change

control helped reduce scope creep.

1.2 Indication of the following chapters

Chapter 2: Methodology

This chapter looks at how both the primary and secondary research was conducted. It

also highlights the limitations and complexities that was found during the research

phase of this study.

Chapter 3: Literature review

This chapter discusses the secondary research findings.


Chapter 4: Findings

This chapter explains the background of the case study organisation used for the

primary research, and discusses the key themes and opinions that were obtained during

the primary research.

Chapter 5: Conclusion and recommendations

This chapter will look to what extent each of the individual objectives was achieved. It

will also highlight any possible weaknesses within the research and draw on the

findings from the primary and secondary research, to make an overall conclusion of the

study.


Chapter Two

Methodology

2.0 Introduction 8

2.1 Secondary Research 8

2.2 Primary Research 9

2.2.1Ethics and considerations when conducting primary research 102.2.2 Quantitative or qualtative research methods 102.2.3 Sample for primary research 12

2.3 Limitations and critical analysis 13

2.4 Conclusion 14


Methodology

2.0 Introduction

This section describes the research methods that have been conducted to achieve the

projects individual objectives.

The research was from both primary and secondary sources. The findings from these

were cross checked and compared to achieve the aims and objectives of this project.

This multi method approach is known as triangulation, and is used to produce a full

and balanced study (Bell, 1999).

2.1 Secondary Research

A literature review was carried out, in order to provide secondary research for the

project. This was done to gain a greater understanding and familiarity of the research

topic. Also to gain an insight of the previous research that has been carried out in the

topic area, also to help plan the primary data collection (Hart, 2001). The secondary

information was collected from the Leeds Metropolitan University learning centre and

from the British library. The sources used for this was books, as there was a great

amount of material on effective project management. A disadvantage of using these

texts is that many may be dated. Also, due to IT being a fast changing industry, some of

these texts may be out of date and irrelevant in relation to todays business environment.

To compensate for this, literature from current journals was also examined. These

included case studies of organisations that have encountered project failure. These were

used to back up any claims the older literature made. All of the sources used to conduct


the literature review were personally evaluated in regards to its respectability and

reliability. This was to ensure that a quality literature review was produced.

By completing a literature review the first three objectives had been met. It highlighted

the issues that should be taken into account for when the primary research was

conducted (Bell, 1999).

2.2 Primary Research

As objective four was focusing on a real-life situation, a case study was used to fulfil

the objectives requirements. Yin (1993), describes a case study as looking at a real life

program whose complexity can not be captured by surveying, and that a case study is

used illuminate how, and why things take place. The type of case study that will be used

is known as an individual case study which focuss on antecedents, contextual factors,

perceptions and attitudes. This is used to explore processes and experiences (Robson,

2002). This method will be used as the researcher is trying to understand the case

studies change control processes and the users experience of those process. It must be

recognised that this case study will not be holistic (represent a global level) as it is only

focusing on one organisation (Yin, 1994).

The researcher is familiar with the company that was used for the case study. He has

contacts within the company, due to completing a years work placement there. Due to

this, a more open and reliable response would be obtained from the research, as trust

had been built up with the company in the past (Bell, 1999).

10


2.2.1Ethics and considerations when conducting primary research.

The researcher had to take into consideration the ethics of using a case study when

obtaining primary data. Therefore, the companys name was not disclosed and the name

Pharma was used in its place. All of the participants of the study also remained

anonymous as recommended by Sapsford and Evans (1984), they were referred to by

their job role.

The researcher had to obtain authorisation to use the company as a case study for the

research project, therefore permission was sought early in the study. The company has

been informed of any information disclosed in this study. Also the intentions of this

study have been fully explained to all concerned. The researcher must also not to keep

records of any of the interviews or company information for longer than is needed to

comply with the data protection act (Hart, 2002).

2.2.2 Quantitative or qualitative research methods.

For the primary research qualitative research methods were chosen over quantitative

research methods. They provide a greater detail of peoples understandings and feelings

than quantitative methods can attain (Arksey and Knight, 1999). To obtain this

qualitative data the researcher chose to perform a number of interviews. Arksey and

Knight (1999) describes how choosing an appropriate interviewing approach is a skilled

and difficult activity. The interview approach chosen for this study, were one-to-one

semi structured interviews. These interviews were conducted as they provide a more

exploratory and qualitative response than a structured interviews. King (1994) refers to

semi structured interviews as qualitative research interviews. This exploratory approach

11


allowed the researcher to follow a set of questions but also probe into areas of interest to

the research topic (Bell, 1999). The interviews were audio taped. These were then typed

up using a transcript methodology which can be seen in appendix B. This ensured that

the interviewer could give his full attention to the respondent and make sure that there

was no loss of data. This would also enable any claims made by the researcher, to be

effectively backed up.

The interviews were constructed to follow the themes and findings that were brought to

light by the secondary research, focusing on the main arguments that occurred. The

questions were structured to allow correlation between the primary and secondary

research. They were also asked to more then one interviewee, which allowed the

comparison of opinions and feeling between each of the interviewees. The answers form

each interview was discussed, compared and contrasted, in relation to each of the

relating set questions. These findings were triangulated with the secondary research

from the literature review, using a data triangulation method (Arksey and Knight, 1999),

in order to gain confirmation of the findings (Denzin, 1970) and provide completeness

(Jick, 1983). By using a data triangulation method it helped to reduce bias and improve

the validity of the research (Denzin, 1989).

An alternative research method to interviewing, to collect primary data, may have been

the use of questionnaires. This method was not chosen as it only allows limited answers

to the given for each question. This is therefore not as flexible as a semi structured

interview and does not enable the researcher to clarify ambiguous answers and

misunderstandings (Robson, 2002). There were also only a limited number of people

within the company that had expertise in this area of the study. Therefore, a mass

12


questionnaire would have been non-effective in receiving a qualitative response. The

researcher had chosen to interview to show a willingness and commitment to the

company. This enabled him to utilise his relationship with the organisation. This was

done as it was believed that a richer response would be obtained, as the interviewer was

present when the questions were asked.

2.2.3 Sample for primary research

The sample interviewees were chosen in relation to their expertise of the research topic,

as they all extensively interacted with Pharmas change control system. Change control

is a very specialised area and many people do not understand its full scope or purpose.

Therefore there were only a limited number of candidates available for interview. The

following describes why each interviewee was chosen for the primary research.

Change control manager: Due to their extensive knowledge of Pharmas

change control processes. They understand the importance of having a change

control system in place. The change control team manager must ensure that the

change control system is working correctly to comply with the Food and Drug

Administration (FDA), who authorises Pharma to sell its products.

Project manager: Responsible for the running of selected IT projects within

Pharma and depends on the change control system to place controls upon the

project.

System controller: This person relies on the change control system to enable

changes that the users may request, to be made to the current system. The

system controller requires a successful change control system to ensure the daily

running of the business activities, and is responsible for the testing of any

change made to the system.

13


Security project team member: They rely on the change control system to

ensure that all their changes are successfully tested, ensuring the integrity of the

system is kept. They also must work with the change control system in their

daily working activities.

These people were interviewed on the same day, using the same interview method. One

to one semi structured interviews with open ended questions. This was to ensure that

there was consistency and integrity between the interviews (Bell, 1999). The questions

were also constructed in such a way that would allow the correlation and comparison of

answers between each interviewee, to contrast each of the interviewees views.

2.3 Limitations and critical analysis

A data triangulation method was used in order to gain confirmation of the findings

(Denzin, 1970) and to provide completeness (Jick, 1983). This was also used to reduce

bias and improve validity (Denzin, 1989). However, Fielding and Fielding (1986) have

challenged this view of data triangulation, arguing that it only allows a fuller picture of

the problem, by gaining depth and understanding but does not offer a greater accuracy.

The researcher still felt that by using a triangulation method, the findings would be

strengthened. It was therefore felt more beneficial to use this method, than not to.

As the researcher had his own experiences and observations from his experiences

working at Pharma, the researchers views and interpretations may have been biased

from his experiences (Bell, 1999). The researcher was aware of this and worked to

prevent any bias that may have existed, from entering the study.

14


The researcher was aware that Pharmas change control process or business practices

would not be representative of all companies. A single case study does not provide a

holistic view (Yin, 1994). Using multiple case studies would have been a better way of

conducting the primary research. Due to time limitations and lack of budget, the

researcher was restricted to using only one company for this case study.

2.4 Conclusion

Each of the research methods used was chosen in respect to their effectiveness in

completing the criteria for each of the projects individual objectives. Considerations

about the experience of the researcher and the availability and ease of use had also to be

considered when choosing the research methods. This chapter has justified the use of

each of the chosen methods, and explained how the researcher utilised each of these

within this study.

The methods mentioned in the proposal that were not used in this study were that of

completing a SWOT analysis of Pharmas change control, also drawing a rich picture to

gain a greater understanding of the literature reviewed. It was felt by completing the

literature review and participating in the interviews, the researchers understanding of the

study would not benefit any further from applying these methods to the study.

15


Chapter Three

Literature Review

3.0 Introduction 16

3.1 Project Failure 17

3.1.1 Reason for Project Failure 183.1.2 Reducing Project Failure 21

3.2 Scope Creep 22

3.2.1 Defining Scope Creep 223.2.2 Why scope creep occurs 233.2.3 Understanding scope creep 233.2.4 Controlling scope creep. 243.2.5 Summary of scope creep 253.2.6 Scope creep and relations to project escalation 25

3.3 Project escalation 26

3.3.1 Recent examples of escalation 273.3.2 Reasons why Escalation happens 273.3..3 De-Escalation. 30

3.4 Change control. 34

3.4.1 Benefits of Using a Change Control System 353.4.2 Features of a Good Change Control System and best practice 36

3.5 Conclusion 39

16


Literature Review

3.0 Introduction

Information Technology (IT) trends within the US show there was an estimated 45%

budget rise for IT expenditure for 2003 and an estimated 53% rise for 2004. With

Enterprise Resource Planning systems estimated to take up 31% of the total IT

expenditure and with figures rising for the future (Albright, 2003). Since these

investments are the most significant that companies and organisations make today

(Cule, 2000), companies need to consider project failure as a very serious threat.

Projects are continuing to fail, with figures showing that at least over 50% of projects

are currently seen as a failure (Cule 2000, Biggs 2000, EIU Business Europe 2003).

There are many causes of IT project failure, ranging from a lack of ownership of the

project (Gibson 1998, Bywell 2003) to scope creep (Murray, 2000). Even some

companies continue to work on these failing projects despite the obvious signs that they

are failing (Keil and Robey, 1999), which is known as escalating commitment to the

failing course of action.

To satisfy objective one, in this literature review, we will look at the different theories

surrounding reasons for project failure. Secondly take scope creep as a cause of failure

and examine it in greater detail, to highlight any links it may have with project

escalation. This will satisfy objective two. To complete objective three of the individual

project and also provide a base for understanding objective four, we will then look at

ways in which these risks may be reduced and consider change control as method to

reduce these.

17


3.1 Project Failure

This section of the review will look at the causes of project failure, and discuss why

many IT projects are continuing to fail. This will complete objective one of the

individual project.

The investments made by many companies in Information Technology (IT) and

Information Systems (IS) are continuing to increase. These investments are without

doubt the most significant that many companies and organisations make today (Cule,

2000). According to the research company Optima Media, these investments now

amount to more than half of most large companies annual capital expenditure (EIU

Business Europe, 2003). Many of these projects are still continuing to fail today (Cule

2000, EIU Business Europe 2003). These projects dont meet their requirements and are

often late and over budget, resulting in low user satisfaction, cancellation or

abandonment of the project (Cule, 2000).

An example of project failure is that of the Taurus project. The Taurus project was a

London stock exchange, stock trading settlement system project. This was cancelled in

1993, after ten years. The project was estimated to cost six million pounds but ended up

costing over 400 million pounds. Other examples include, Prudential Europes Internet

marketing system project called Unite. This project was estimated to cost around fifty

million pounds. However, it was cancelled after three years at a cost of one billion

pounds (EIU Business Europe, 2003).

IS project failure is not a new problem. It has existed since information systemsmoved beyond simple automation. (Cule, 2000 p.65)

18


There are many different figures and statistics why IT/ IS projects fail. These projects

may not be delivered on time, be over budget, cancelled or abandoned. Most of these

figures and statistics show that at least 50% of projects are seen to be a failure (Cule

2000, Biggs 2000, EIU Business Europe 2003). Bennett (2003) argues that failure rates

havent gone up, just that it is more expensive when projects do fail. Which seems a

valid point, as IT forecasts show that IT budgets are continuing to increase each year

(Albright, 2003).

3.1.1 Reason for Project Failure

According to recent research among European companies, businesses are stillmaking expensive but avoidable mistakes when it comes to key IT projects.(EIU Business Europe, 2003 p.1)

The EIU Business Europe (2003) comments that despite the vast research done on IT

project failure, there is still disagreement on the main causes of failure. It warns that

much of the research is subject to bias, especially in surveys, as people believe that

responsibility lies outside of their control. However, there is a wide spread belief that

management is responsible for project failure rather than technology. Some of these

reasons for project failure are discussed in terms of the following.

Poor management of projects, as discussed by EIU Business Europe (2003) is one of the

major causes of project failure. It needs to be recognised that poor project management

is a major cause of failure. It is a contributing factor in its own right, but may also lead

to other causes of project failure. An example of this is if there is no proper ownership

of the problem within management, this can lead to project failure. A senior company

officer must take ownership of the problem and therefore should take responsibility for

19


the project (Gibson 1998, Bywell 2003). There needs to be somebody on the project

who has a responsibility for the projects success. Ideally this person should have the

final word on all project decisions. Other factors are that of poor risk management, as

all projects do contain some sort of risk and these risks needs to be managed. Cule

(2000) sees risk as managing odds to achieve a favourable outcome. He says you need

to categorise the risks and manage them separately. If the risks are not managed then a

project will be much more vulnerable to failure. Another cause of project failure,

identified by EIU Business Europe (2003) in a recent KPMG report is poor project

planning. This is also backed up by Bywell (2003), stating that the project requirements

need to be provided in full detail. Biggs also agrees with Bywell (2003), stating

incomplete requirements planning are one of the major causes of project failure. If the

requirements planning are incomplete, then the company may not need all the

functionality that a new system may provide. Likewise there may be not enough

functionality with in the system. Bad planning may also relate to the project working to

unrealistic goals and timelines as a reason for failure, therefore during the planning

stages of the project, realistic goals and timelines must be set (Biggs, 2000). Otherwise

the project may be seen to overrun and not be able to meet the unrealistic goals that

have been set.

Another reason for project failure is if the project is technology focused rather than

business focused. Gibson (1998) highlights how some companies can be too

technological focused rather than business mission focused, possibly trying to plan too

far ahead. If this happens the companys business processes fall out of alignment with

the technology and the project therefore fails. This also relates to changing business

requirements as a reason for failure. Changing business requirements is pointed out by

20


Gibson (1998) and Cule (2000). They state that some projects dont fail as they meet the

initial business specifications that were set. During their implementation the business

specifications are subject to change. In these cases the projects results in not meeting the

new business specifications, and therefore the project may not be seen as a success. This

point highlights the difficulty in defining project failure, as failure is defined in many

ways. Cule (2000) shows this effect in a case study, where during the development of a

system designed to give a strategic advantage over its rivals, the competitors developed

similar systems which was superior to the initial system. This led to the initial system

not providing the desired strategic advantage over the competitors. Even though the

system met all of its requirements, was on time and within budget it was still classed as

a failure. This highlights the need to monitor the business objectives throughout the

project lifecycle. This will ensure the project keeps in line with business strategy.

Corporate culture is also a culprit of failing projects. Bennett (2003) uses the example of

when a customer does not have the culture of timely decision making. This will lead to

there being no tie between the business and IT. This may also be a cause of projects

moving out of line with the business strategy. Another common reason for failure, at the

design and development stage, is a lack of end-user input (Biggs, 2000). Berry (1999)

backs this up by stating this as a major cause of project failure, and Bennett (2003) also

agrees. He states that the users need to be included in the project from the planning

stages, into the development stages. They also must be involved in user acceptance

signoff throughout the project. They must agree that they are happy with the final

product and they have been given what they expected. If the project team lacks skills in

the required technologies during the development and design stages of a project, this

could be cause for project failure (Biggs, 2000). A consequence of this may be that the

21


business is not able to challenge the supplier. This could also be a result of continuous

changing technology or if the project team is lacking in the skills of IT procurement or

project capabilities. This may occur if a finance director is in charge of the IT

department (Bywell, 2003). Related to is a lack of resource allocation, or commitment

from the management towards the project. This is where the amount of resources

assigned to a project is not enough or in shortage. This is most likely to be a result of

poor project planning or just that the project has gone out of control. Biggs (2000)

indicates that you need to evaluate what resources you need for your project, and if you

need more, get external help. If the project is important enough then the budget should

allow enough allocation of talent to complete the project or a trade off may have to be

made to ensure the completion of the project.

Scope creep is described by Murray (2000) as a cause of failure. Murray points out that

scope creep needs to be managed, as it is a common occurrence in many IT Projects.

Scope creep is where the project size and complexity is allowed to expand as the project

moves forward. Bywell (2003) sees scope creep as a common contribution to project

failure.

3.1.2 Reducing Project Failure

Failure is a real risk to most projects. Managers must be aware of the causes and work

to reduce the risks. There are many articles on how to run a successful project, such as

Biggs (2000) 12 golden rules of project management success. To ensure a successful

project, all that needs to be done is to identify the risks of the project, then work to

control and manage those risks effectively (Cule, 2000).

22


As well as the common practices to achieving project success, other authors suggest

alternative methods such as Murray (2000). Murray suggests that instead of managing

the risks, you should in fact reduce the complexity of your project, to make it as simple

as possible. He takes into account that different companies are effectively capable of

handling different size projects. Therefore, the size and amount of complexity that a

project needs to be reduced to will depend on the characteristics of the individual

company. His theory is that if you reduce the complexity of the project then the risk

areas will be removed, rather than managed. This is where scope creep can be an

effecting factor. If it is tolerated, then the projects size increases and additional

complexity is added to the project. Although Murrays (2000) method may be valid, it

doesnt take into account that some projects need to be complex, and many projects

often are.

3.2 Scope Creep

In the previous section of this review some of the causes of project failure were

discussed. In the next section, the researcher will investigate scope creep, as it was one

of the contributing factors of project failure, indicated by Ulfelder (2004). Thus

satisfying part of the individual projects second objective.

Like a malignant cancer, 'scope creep' is one of the most significantcontributors to project failure. (Business Line, 2001, p 4)

3.2.1 Defining Scope Creep

Scope creep occurs during a projects development lifecycle and often occurs in IT

projects. Comerford (2000) and Adshead (2003) indicate that enterprise resource

23


planning (ERP) packages are prone to scope creep. It happens when new features and

functions are added during the development lifecycle. This can result in projects being

over budget and prone to run over their deadlines. This often puts them out of line to

their original business requirements. All this costs money and time, and can seriously

consume projects resources. Therefore affecting your projects chances of success (

Zimmerman 2000, Liebmann 2001). It is important to also distinguish between scope

creep and requirements creep. Scope creep is where additional functionality is not

planned for within the budget of the project. Requirements creep is where the additional

functionality is planned and the budget has to accommodate for these changes.

3.2.2 Why scope creep occurs

Scope creep is a very common occurrence, and is present in almost every project. In an

article by Schulz (1999) he describes how he had a home micro-project, swapping

around two computers in his basement. This project went $17 over his estimated budget,

and lasted three and a quarter times his original estimated time. This example may seem

trivial, but it stands to show that even the smallest project can be affected by scope

creep. Keeping this in mind, scope creep is simply amplified by the size of a project.

Vowler (2003) argues that so many government projects go wrong due to their size.

This results in the amplification of scope creep, causing projects to overrun and change

specification. Vowler (2003) argues that if these projects were broken up into smaller

ones it would reduce the effect of scope creep.

3.2.3 Understanding scope creep

Project teams are often bombarded with requests to add new requirements. Zimmerman

(2000) categorises these requests into two types, the first being new requirements, the

24


second being modifications of existing requirements. He explains how each of these

requirements must be analysed and goes through design and implementation. This

results in the requirements taking up time effort and precious resources. Liebmann

(2001) highlights how these consequences of scope creep can put a project team under

pressure, as they will be receiving these requests and will want to deliver their best to

the business. Unfortunately they are restricted by a budget and time constraints and

cannot afford to stretch these to any unnecessary new requirements or enhancements.

It must be acknowledged that some of these new requirements or modifications may be

essential to the projects success. As mentioned earlier, the business requirements often

change during the different project stages. This must be monitored or the project may

fall out of step with the business activities or requirements. We must understand that

scope creep is where the additional requirements dont benefit the projects objectives

(Liebmann, 2000). Liebmann (2000) summarises factors of scope creep as follows.

Additional features that dont fit the business drivers.

Features that add a low cost benefit ratio.

Features that overstretch the business allocated resources.

Features that add risk.

3.2.4 Controlling scope creep.

Now we understand what scope creep is, we must recognise that it needs to be

controlled, not prevented as previously mentioned. This is because some added

requirements are necessary during a project lifecycle. Zimmerman (2000) indicates that

communication is the key to solving this problem. A formal request for changes process

should be set up as each change needs signing off by both the project team and

customer. He recommends introducing a change request process where all requests

25


would be viewed by a panel consisting off the project manager (in part 2.1 it is

recommended that somebody has overall responsibility for the project, this is the project

manager), technical lead and customer to approve or disapprove the request. This is

formally known as a change panel who will deal with each request in the same way,

allowing for a benefit-to-cost ratio to be carried out on every change request. As

Liebmann (2000) has described, only things that benefit the project are allowed to

proceed, therefore eliminating scope creep. This way of controlling scope creep by

ensuring all change requests go through a change control process will be analysed later

on in this literature review.

3.2.5 Summary of scope creep

In this section we have looked at scope creep. We have seen how it can be present in

many different sized projects, and realised that the bigger the project the greater scope

creep is amplified. We now know that scope creep relates to additional requirements

that do not benefit the business and differentiate between the requirements that may

arise in changes from within the business strategy changing, or the additional

requirements that benefit the business. Due to scope creep being a major contributing

factor of project failure it must be controlled. We have considered using change control

to restrict scope creep as recommended by Liebmann (2000).

3.2.6 Scope creep and relations to Project Escalation

We have looked at scope creep and defined it as being where additional requirements

that are added during the projects design or implementation phase, that dont benefit the

business requirements. If not controlled it may lead to runaway projects. There is also

another factor that may lead to runaway projects, called project escalation. Scope creep

26


can sometimes be an indication of project escalation. Even though one may assume that

scope creep and project escalation are similar things, they are in fact two very different

things. They have a similar outcome, being out of control projects which can lead to

project failure.

This next section will satisfy the second part of objective two as it looks at projects

escalation and discusses any links it may have to scope creep.

3.3 Project Escalation

There is limited research on the escalation theory. Most of the previous research that has

been carried out focuses on individual cognitive decision making in relation to project

escalation. This has left a need for research to be carried out at an organisational level.

There is also more limited research that has been carried out on de-escalation of

commitment to a failing project (reducing and controlling escalation) (Keil and Mixon

1995).

Escalation refers to the following.

Escalation of commitment to an ineffective course of action (Brockner andHouser 1986 p1).

The term escalation is often used by many authors and refers to committing resources

to, and supporting failing projects when termination or redirection of the project would

be a more suitable course of action. (Drummond 2000, Sharp and Slater 1997, Keil

1999). Project escalation is not an uncommon phenomenon. Keil and Mann (1997)

conducted a survey of several hundred information systems auditors. Through their

survey, they found that one or more out of five projects had encountered project

27


escalation. This concluded in a summary that escalation occurs in 30-40 percent of all

IS projects (Keil and Robey, 1999).

3.3.1 Recent examples of escalation

1. The Taurus project was a London stock exchange stock trading settlement

system project. This was cancelled in 1993 of after ten years. The project was

estimated to cost 6 million pounds, receiving over 80 million in its first three

years, and ended up costing over 400 million pounds. (Keil and Robey, 1999)

2. Prudential Europes Internet marketing system project called Unite, was

estimated to cost 50 million pounds. It was cancelled after three years at a cost

of 1 billion pounds. (EIU Business Europe, 2003)

3. CONFIG, an expert system designed by the company CompuSys. This project

started out with lack of sponsorship and unrealistic time lines and goals, and

therefore experienced difficulties from the outset. As a result, it led to rejection

by the companies sales representatives. This led to a long effort in trying to

adapt the system so that it would be accepted. This used up valuable resources

even though the project was classed as a failure (Keil, 1995).

3.3.2 Reasons why Escalation happens

This next section will look at reasons why companies continue to commit to a failing

project rather than abandoning it, abandoning it too late or turning them round.

Keil (1995) and Staw and Ross (1987) agree that the causes of project escalation can be

grouped into four different categories being, project factors, psychological factors,

social factors, and organizational factors. Following are some theories why people

escalate to failing courses of action.

28


The self justification theory for why people escalate is where decision makers continue

with failing projects, thereby risking even greater negative outcomes. They may be

trying to justify previous actions and by doing this it may cover up their past mistakes

(Drummond, 1998). This is because people dont like to admit their past decisions were

wrong and they are not willing to admit they are working to a failing project. This factor

may fall under the social category of reasons for escalation (Brockner, 1992). Staw

(1976) explains how people who have a large responsibility to previous commitment to

a failing project are more likely to escalate commitment than those who dont. Also

those who have had previous commitment to a project are more likely to commit further

resources to a failing project. Another reason that falls under the social category of why

project escalation may occur is that of fear of failure.

As the decision makers are responsible for a project, if they were to end the project

prematurely it may be seen as a failure and damage the project managers reputation.

Therefore the project manager would not want to be seen as a failure as it may damage

his future career prospects (Kanodia, Bushman and Dickhaut, 1989). Not only do people

fear that the project they have been working on may fail, but many may get an

emotional attachment to project. Keil (1995) discusses that people can get emotionally

attached to a project. For example, if somebody has worked on the project for many

years, they dont want to discard their work. This may relate to the self justification

theory with managers not wanting to admit that the time spend working on the project

was unjustified. These causes of project escalation seem to be caused by unconscious

irrational decisions, with the decision maker unaware of the consequences, of their

actions. Sharp and Slater (1997) suggest that one cause of escalation that may arise from

29


a conscious decision, is that if the decision maker was to carry on with the failing

course of action it would be in the decision makers self-interest. A manager is more

likely to escalate if it is seen to be in his self interest despite how it may affect the

business, if there is incentive to do so. For example, if it is seen that escalating a course

of action could recover previous losses and reinstate the managers reputation (Sharp

and Slater, 1997).

Another reason for escalation, that may arise from conscious decision making, is that of

poor resource management decisions. Keil and Robey (1999) highlight how troubled or

failing projects attract additional resources despite obvious signs of failure, even though

one would have thought that successful projects should attract additional resources.

Therefore, IS managers must allocate resources much more carefully. Keil (1995)

describes this as throwing good money after bad. This cause also falls under Keil

(1995), Staw and Ross (1987) organisational factors for causes of escalation. Sharp and

Slater (1997) also highlight an organisational cause, that different cultures act in

different ways in their study on sunk costs and international generalisation. In their

studies, they found that Asian groups are more willing to take operational risk and not

financial risks, unlike North American culture groups. They found Asian groups are

overconfident in general knowledge tasks and are more likely to escalate commitment to

a hazardous project

It would seem that the main reasons why people commit to escalation can be classed as

the cognitive theory of individual decision making. The theory which explains this

phenomenon is called the Prospect theory (Sharp and Slater, 1997) which is also known

as the framed effect and the Sunk cost theory (Kanodia, Bushman and Dickhaut 1986,

30


Staw and Ross 1987). The prospect theory is where individuals over perceive the losses

of terminating a project (this is called negative framing), due to this they are more

willing to avoid these over perceived losses (also known as sunk costs). They then risk

carrying on with the project to recover these losses. This effect can also work in

opposite ways, where the rewards of continuing with the project and it succeeding are

seen greater than the losses of terminating the project. (Sharp and Slater, 1997). This

effect depends on the individual perceptions of the decision maker and links to poor risk

and benefit analysis. Keil (1995) points out that this factor is more likely to occur if the

decision taken involved had a large potential payoff at stake. The sunk cost effect

described by Staw and Ross (1987) occurs when assessing the situation of a project to

decide whether to commit further resources. People tend to concentrate on previously

spent resources which are known as sunk costs. They say that in an ideal world

people should treat these losses as sunk costs, also Whyte (1993) says that sunk costs

should not concern decisions made about the future.

3.3.3 De-Escalation.

Projects that are experiencing escalation of commitment should be abandoned or

redirected. Staw (1976), Keil and Robey (1999) all agree that managers need to first

learn how to recognise over commitment in order to take the correct action towards the

problem. Keil and Robey (1999) use the coined term de-escalation to describe the

withdrawal of commitment, to turn troubled projects around, ultimately redirect them or

abandon them. Keil and Robey (1999) also insist that to be able to turn a troubled

project around, realisation of committing to escalation and action taken upon it must

occur in the early stages of a projects life cycle, otherwise the chances of turning a

troubled project around becomes hindered.

31


whether a troubled project ultimately succeeds or fails depends on theeffectiveness of managerial actions taken to turn around or redirect suchprojects (Keil and Robey 1999. p.63)

In his study on escalation and knowing when to pull the plug on troubled software

projects, Staw and Ross (1987) highlight that managers need to initially recognise they

are a cause of escalation of commitment to troubled projects. They can often have a bias

to the project with the attitude that any problems will resolve themselves and assume

the projects will pull through. He concludes that this may be due to the fact that in large

bureaucratic organisation it is initially very hard to get the go ahead to start a project in

the first place. Staw and Ross (1987) say that project managers need to ask themselves a

set of preset questions, if a manager answers yes to one or more of these questions then

they may be over-committing to a project.

Once it is recognised that a project or failing project is subject to escalation of

commitment, action needs to be taken to reduce the escalation. Keil and Robey (1999)

describe this action as de-escalation. Staw and Ross (1987) recommend that the first

action should be to take a fresh view of the project which can be done by setting up

decision circles. Decision circles are made up of key members of staff that should

periodically evaluate the projects status. This action is also backed up by Keil and

Robey (1999) who says that regular evaluation of the projects progress can lead de-

escalation. This initial action may have an effect on Sharp and Slaters (1997) theory on

sunk cost, by taking a fresh view on the project all previous sunk costs are ignored as

Whyte (1993) pointed out that they should not affect future decisions.

Staw and Rosss (1987) second recommendation is that the organisation needs to

realise that it can be a contributor to escalation. If this is the case, they need to look at

32


ways they can change the organisation. One way this can be achieved is to rotate staff

working on the project. Staw and Ross (1987) say it is a possibility but can demoralise

staff. But by doing this it may reduce Keils (1995) theory of getting emotionally

attached to a project which can lead to escalation. Keil and Robey (1999) also

recommend changing the project manager and champions to reduce escalation which

agrees with Staw and Rosss (1987) second recommendation about changing the

organisation.

Staw and Rosss (1987) third recommendation is to reduce the risk of failure, which

correlates directly to Kanodia, Bushman and Dickhauts (1989) fear of failure as a cause

of escalation. Therefore a tolerance to failure needs to be introduced into the

organisation. This will then allow managers to be able to discard failing projects instead

of continuing to over commit to try to save their job prospects (Keil and Robey 1999).

Staw and Ross (1987) recommend a penalty scheme which allows managers a chance to

redeem themselves.

The fourth recommendation by Staw and Ross (1987) is for the company to have better

information reporting at hand This could be done by employing an outside consultant to

report as nobody wants to deliver bad news about the status of a project. This also

allows people to see the spiralling costs of the project. Keil and Robey (1999) also have

a similar method to reduce escalation by allowing the visibility of project costs to be

seen which may shock people into de-escalation. This better information reporting may

be obtained by increasing the honesty of reporting (Staw and Ross, 1987), which will

increase the awareness of the project problems and enable people to deescalate their

commitment to a failing project. Keil and Robey (1999) recommend these reports are

33


used to show managers what funds are being spent and that they should asses if these

funds can provide better cost benefit if they were allocated to other projects, thus

reducing escalation of commitment by committing to other projects. Keil and Robey

(1999) also recommend if a project is seen to be having escalating commitment towards

it, then a project limit for resources should be stated to stop it running out of control.

This action may not stop escalation as it is just reducing the resources available and may

lead the project to a dead-end. Keil and Robey (1999) remind us that many projects start

with a limit but this does not stop escalation in the first place and may not stop it after it

has been recognised. Keil and Robey (1999) state that the problem of escalation lies at

poor resources allocation and recommends that segregating the responsibilities for

approving and allocating resource may solve the problem, as many of the original

decision maker who have the power of control of resources or budgets may be

committed to escalation and if the duty is shared it is likely to lead to de-escalation.

There are many causes of project escalation and therefore many ways in which it can be

reduced, controlled, diverted or withdrawn by recognising a project is receiving

escalating commitments and taking action upon escalation in ways as described above.

As well being able to recognise when there is escalation of commitment to an

ineffective course of action in order to deal with the problem, managers should have

methods in place to prevent escalation by putting controls on the amount of

commitment a project receives, whether it is resources, funding, time or the scope

allowance of the project. One of the factors of CompuSyss expert system project

CONFIG project escalated and failed was due to slack resources and loose management

controls (Keil, 1995) which may have been controlled more effectively if a formal

change control procedure was used.

34


3.4 Change control.

This section will look at how change control systems work and how they may help

reduce scope creep, in order to complete objective three of the individual project

objectives, and set a grounding of knowledge which will help complete the forth

objective.

All custom developed software projects such as an ERP software needs changes to them

or additional requirements to be added. This may be due to bugs, errors, new

requirements, changing requirements, or due to the client or environment changes,

future versions of the software (Field & Keller 1998, Lamond 2002). As we have

previously established if these additional requirements are not controlled, they can lead

to factors such as scope creep which can result in runaway projects (Bocij et al 1999,

Stedman 1999). If the controls are not tight enough it may allow escalation to happen,

which should be controlled by limiting the number of resources available to the project

(Keil and Robey1999). To control these changes they need to be managed by ensuring

that all requests for changes are recorded and evaluated so the numbers of requests dont

become unmanageable. This is done by using a process known as change control, it is

also known as change management or scope management. In this study it will be

referred to the process of change control (Bocij et al, 1999 Field Keller 1998, Lamond

2002, Hallows 1998, Wateridge 1999).

All projects are subject to scope changes at some time during their life cycle.The scope change control system or configuration management is a systemdesigned to effectively manage the change of scope. (Burke, 2003, p105).

35


3.4.1 Benefits of Using a Change Control System

Burke (2003) describes change control as a framework to monitor, evaluate and approve

changes to make sure that the integrity of the system is maintained. Change control

allows a means for proposing change to a system (Field and Keller 1988, Halows 1998).

It also ensures that a projects baseline plan of scope, schedule, and cost and resource

allocation is maintained by the use of change control as it allows any changes to be

monitored and compensated for (Edward and Douglas, 2000).

Managers need to devise a strategy for change and employ change managementas a way of controlling any changes (Wateridge, 1999. p238)

Hallows (1998) states that an escalation path should be designed in which certain

problems should be escalated to certain people, Bocij et al (1999) state that an

escalation path ensures that the problem is sent to the person that is responsible for

fixing it, who resultantly may raise a request for a change. These proposed changes

should be prioritised by the requestor of their importance with a high, medium and low

importance assigned to them (Maylor 1999, Bocij et al 1999), high priority is usually

system critical, with Burke (2003) stating that there should be automatic approval in

place for emergencies. This may go against the purpose of a change control system as it

is there to allow the valuation of change to ensure system integrity, it would be assumed

that all requests for change are evaluated no matter how important. A change request

system also allows a cost benefit and impact analysis to be done on each request taking

into account cost and time constraints on a project (Maylor 1999, Field and Keller 1998,

Moreton, 1990). This is where change control can have an effect on controlling scope

creep as the numbers of changes are carefully controlled. Burke (2003) sees change

control as a tool for controlling scope overall other uses. Change control can be also

36


used to aid in configuration management, where documents of the current system are

kept and all previous models of the system configuration are also stored. This allows

any audit trail to be carried out on the system, and is particularly useful if the system is

a validated system (Bocij et al 1999, Burke 2003). Change control also aids in testing of

the software changes by allowing a consistent test plan to be in place ensuring all

changes endure the same degree of testing before the changes are released (Bocij et al

1999). Other benefits of change control include security of the system, ensuring that no

unauthorised changes are allowed in the system, this means that change control can also

protect a system from malicious abuse (Hulme, 2002). Please see appendix (D) for a

diagram of a change control system.

3.4.2 Features of a Good Change Control System and best practice.

There are many forms a change control system can take. A small project might have a

very basic informal structure as a large project may have strict rules and formal

processes to follow (Field and Keller, 1998). Between authors there seems to be a

common agreement of what the best practices are and what features a good change

control system may have which is discussed in the following.

Hallows (1999) describes how when a problem arises it must follow an escalation path.

This is recommended by raising an issue log so the log has to be reviewed by the

appropriate manager. If the problem is then to be seen as some concern then action must

be taken to solve the issue. Lamond (2002) agrees with Hallows (1999) indicating that

there should be a system owner from the business department where issues are sent to.

When an issue is established as a problem, a change control system needs a means for

submitting a proposal to solve the issue (Field and Keller, 1998). The usual way of

37


doing this is by submitting a change request form. A change request form is a document

which should allow space for, a unique identifier, a description of the problem and

reason for change. A priority rating of the request, a section to allow approval of the

change, the owner of the problem (requester), the test user, if quality control approval is

needed, estimate of resources, consequences of the change, name of the programmer

responsible and a desired implementation date (Lamond 2002, Field and Keller 1998,

Burke 2003, Bocij et al 1999, GAMP4 2002). See appendix (C), change request form.

Field and Keller (1998) and Hallows (1999) describe how there needs to be an authority

to approve or reject the change request. Edwards and Douglas (2000) state that this

approval may be just verbal authorisation on smaller projects, but insist that larger

projects need a formal authorisation process.

Once the change is approved it needs to be accounted for in the plans and budget.

During this approval stage of change, the change coordinators, who will consist of

member of the project team and from the business departments, will use methods for

evaluation of impact of the change, resources and effects on the project in order to

approve or reject the change request. Edwards and Douglas (2000) indicate that both the

client and project team need to be committed to change management to ensure the

changes are beneficial. This explains why the change coordinators consist of member of

the project team and from the business departments. If the request is approved changes

may be made, a rejection may happen because the changes are felt to be inappropriate or

the approval board may need further information on the change request, in which it may

be submitted for approval a second time once amended (Hallows 1999, GAMP4 2002).

Upon the approval of the change request the proposed changes may be made and tested.

Lamond (2002) describes how software projects should have different libraries, one to

38


make the changes in, and another to test the changes, and a third which is the live

system that the client will use. This ensures that system integrity is kept, and there are

no changes directly in the live system. An example of using these different libraries is

used by the ERP software SAP which explains how there are different libraries (clients)

within the system, one to develop the program, another to test and finally a live system

(SAP labs inc., 1999). Once the changes have been completed it is formally tested in the

test library usually by somebody outside the project department such as quality control

or people from the business. Wateridge (1999) argues that people from the business

need to complete the testing to ensure that the project achieves their expected

outcomes.. Due to the fact that only changes were allowed in the development library,

the tested versions in the tested library are the changes which will go into the live

library. This will ensure that the version control remains intact. Once the testing is

complete, the change is then approved to move into the live production library. This is

recorded on the change request (Lamond, 2002). The only deviation that may occur to

the change control process is that of if an emergency arises. This may be a change

request that has come in as high priority. Burke (2003) states that there should be a

procedure to allow stating automatic approval in place for emergencies, this may leave

the change control process open to abuse and allow unmonitored changers to be made to

the production system. Lamonds (2002) views are different to Burkes (2003), he says

that if there is an emergency and you need to get changes into the production system to

keep it running smoothly then change control still applies to emergency fixes.

The objectives of a program change control still apply to emergency fixes, buttemporary compromises may be necessary (Lamond, 2002 p.27).

39


He states that all formal testing should be completed and approval should still be carried

out by quality control, before the move to the production library. If an emergency

change is made, auditors should review the process to ensure that all documentation is

correctly in place, and that all steps of the change control process have been followed.

This indicates the need for any change control system to have a previously agreed

emergency plan for any emergency changes that may be required.

3.5 Conclusion

In this study we have identified that project failure is a real and dangerous influencing

factor on many companies and organisations IT / IS projects. We have looked at reasons

given by existing literature why these projects fail, and have established that managers

must be aware of the reasons of failure. They need to work to combat these risks to IT

projects. We then took scope creep as a reason for failure (Ulfelder, 2004) and

examined it in more detail. We established a need for a process to control scope creep.

Then we looked at project escalation and compared it to scope creep; the result is that

they are two very different things have similar effects on a project. We then looked at

literature on change control as a means of controlling scope creep and project escalation

(Keil and Robey1999). There is limited literature on change control, with most of the

available literature describing the process of change control, which has been described

as good features of change control and best practice. Once a change control system has

been established, it is easy to see how it can aid in the control of scope creep and project

escalation. It allows all changes to the scope of a project to be reviewed and therefore

controlled, resulting to the resource allocation to a project also to be controlled and

40


monitored. During the literature search it has been quite interesting to see that there is a

general agreement between issues around this study with very few conflicting articles.

41


Chapter Four

Findings

4.0 Introduction and background 42

4.1 Perceptions of Change Control 43

4.2 Discussion of findings 44

4.2.1 The structure of Pharmas change control 444.2.2 The importance of formality in a change control system 474.2.3 Deviations to change and emergency procedures 494.2.4 ERP and the need for controls 504.2.5 Soft and hard controls of a change control system 514.2.6 Change control and effects on scope creep 53

42


Findings

4.0 Introduction and background

This chapter aims to complete objective four by looking at the primary research and

picking up on the key themes and opinions that was raised by it. Where possible it

relates these back to the literature previously reviewed. The primary research consisted

of a set of tailored questionnaires for each interviewee, as described in the methodology.

These interviews focused on the opinions of Pharmas employees on their change control

system. The findings from the primary research can be seen in appendix (B), typed in a

transcript format. These findings will then be discussed and compared to the findings

from the secondary research, and draw on the key issues raised.

Pharmas change control system appeared to be a standard change control system, and

contained all the features that you would expect of a change control system, as

described by authors in the literature review. Pharma is a global pharmaceutical

company currently employing over 58,000 people worldwide, and over 10,000 people

in the UK. It has major production, sales and marketing sites within the UK, which

despatch to customers within the UK and to over 100 export markets. The systems used

by these sites are mainly made up of SAP systems.

These SAP systems require a change control system to ensure their successful daily

running, or to keep control of any project work that concerns the systems. This change

43


control systems is also used to bridge across other applications, such as Pharmas HR

system and drug trial systems, thus indicating how important it was that Pharma has an

effective change control system. Pharma has always had a form of change control as

their systems are regulated by the Food and Drug Administration (FDA). All

pharmaceutical companies must comply with this to be able to sell their products. Their

change control system started off as a paper based system, and as errors were made and

issues were raised it developed into a Microsoft Access database. This has matured into

a very complex Microsoft Access database. Pharmas change control system now stands

on a sequel server and is hoping to progress into an ERES (Electronic records electronic

signature) compliment system. Pharmas change control system is growing and changing

all the time, as Pharmas change control manager states that if it sits still they must be

failing somewhere.

4.1 Perceptions of Change Control

Change control affects people in different ways. This is due to people interact with the

change control system in different ways, depending upon their job role. Therefore it

appeared that the aspects and uses of change control were perceived slightly differently

between each of the interviewees. This had to be initially recognised before the findings

were looked at. For example the change control manager seemed to perceive change

control as a way to comply with the FDA and to ensure the changes taking place were

controlled in respect to configuration management and testing requirements. Also

ensuring the changes made to the system had been approved. The project manager saw

change control as a control mechanism to control lower level changes to the system.

Due to the need to comply with the FDA it meant that the IS, quality assurance and a

business representatives needed to sign changes off to approve them. This ensured a

44


greater effectiveness with the control of scope creep. The system controller viewed

change control as means to ensure that any requests for change were thoroughly

considered in relation to their business impact and cost benefit, before the requests

formally interact with the change control system. It would seem that change control is

used as almost a deterrent to users considering making change request, which ensured

that only the important changes are put forward. Ensuring that these changes were

carefully thought about, forcing the users to get the change right at the start. The system

controller also saw the change request system as a way to ensure that testing was

completed to a user satisfactory standard. This would ensure that the user was happy

with the end product. The project team member saw change control as a process to give

them confidence, the work they are putting into live production system was error free,

and that the systems integrity and security was therefore maintained. Even though

peoples perceptions of the uses of change control slightly differed there was a common

understanding that there was a need for a change control procedure for any project or

live system.

4.2 Discussion of findings

4.2.1 The structure of Pharmas change control

Pharmas change control system contained the standard features that authors had defined.

These features were described by Pharmas change control manager. They included

features such as having an escalation path, a formal request process by raising a

problem log which will have estimates put upon it. This will then go to a change panel

which consists of a quality assurance member, SAP architect and business process

owner. They decide if the change can be approved, upon which the problem log is

45


changed into a change request. The change request is then assigned to a work package

which is classed as release management, then work is completed. This then follows the

V model for testing, using libraries as described by Lamond (2002). The final change is

signed off by COMVAL (computer validation) and QA (quality assurance) before the

change can go into the live production system.

In the interviews, some of the interviewees were questioned about the use of libraries, as

the researcher was interested to see how important Lamonds (2002) recommendation

was in respect to how necessary it is to have different libraries when using a change

control system. This also seemed appropriate as Pharmas SAP systems make use of this

library functionality. The change control managers response was that the use of libraries

was important. It allowed the management of risk within the system and it allowed a

separate place for the user to train in, also a separate place for production and testing,

which should be a minimum requirement in any system that is properly managed. She

stated that the key thing is that any reasonable system should have landscapes, with a

size and complexity relevant to the system.

It allows you to maintain control of your system (Pharmas Change controlmanager)

The project team member also agreed that the use of libraries was important, stating that

that it ensured that things were tested properly. Which meant that the user was happy, as

they saw during testing is what they would get in the production environment. The

importance of the user doing the testing was backed up by the system controller. He

insisted that it was the user who did the testing, as they were the one that uses the

change on a daily basis. The system controller explained how this ensured that the

change looks and behaves how the user wants. This is described by Wateridge (1999).

46


The importance of the users completing a user acceptance test was highlighted by

Bennett (2003), stating the lack of user involvement is a major cause of project failure.

Therefore it would appear that change control encouraged user involvement within the

project, which combated project failure. The system controller also highlights that if a

user is the one who did the testing, they would have to be the one to take time out to test

the change, which meant they needed to be committed to the change. This ensured that

the change would be of importance to the user, as if it wasnt the user would not have

had time to test the change. Thus ensuring that the users dont request changes they

dont need.

Another feature of change control, discussed by authors, was that of an approving body.

Edwards and Douglas (2000) indicated that this approval may be just verbal

authorisation on smaller projects but they insist that large projects needed a formal

authorisation process. As Pharmas change control system spans across multi

applications, the project manager was questioned about their approving body. He was

asked if he felt the authority on the approving body was correct. He stated, how on

Pharmas approving body there are three people. The project manager or information

system lead, quality assurance who took a GMP perspective and a business process

owner who the change originated from. They needed to ensure that their processes

didnt deviate from the norm. The make up of Pharmas approving body is consistent

with Douglas (2000) and Edwards and Douglas (2000) recommendation, who states that

both the client and project team need to be on the approving body. The change control

manager stated that their approving body worked well, as it consisted of key

representations of each of the individual area. He explained that this approving body

was more effective with managing change than their governance structure, as the

47


company needed people who could make proper decisions and have their decisions

respected.

On projects you need key representations on there, to make sure you arefocusing on what really needs doing (Pharmas Project manager).

Therefore it appeared that Pharmas approving body is a formal one and consists of

people who are perceived to have authority and experience, this is in order for any

decision made about a change to be immediately respected and accepted.

4.2.2 The importance of formality in a change control system

A point of interest that was explored was to how important the formality of a change

control system was to Pharma. The system controller explained how formality is good

with large changes, forcing them to get things right up front. The formality makes them

properly record what they want to do, and how they are going to get there in the end,

stopping users changing their minds half way through the change, which ensured that

they considered all the options at the start. The project team member also felt that the

formality the system is important. The change control manager views Pharmas change

control system as very formal, and states that it needs to be if you are producing drugs

and their systems are validated. She states that in other systems that doesnt have a

formal change control, tend to fall over regularly, and that formality stops this.

Because we formalised the approval process, it makes them properly recordwhat they want to do, how they want to do it and how they are going to get therein the end. If we didnt have that formal process we would get people saying wewant then and the halfway down the line changing their mind (Pharmas systemcontroller).

The system controller described that before the formal change control system was

introduced, there were just user controls in place and people would just make changes

as they wanted. This would allow scope creep to thrive, as Burke (2003) explained that

48


change control is needed to control the scope of a project. As the formality of Pharmas

change control has increased significantly from the past when user controls was used.

The system controller felt that now the amount of formality was spot on, with the

culture of a formal change process now present within the company. Both the change

control manager and the project team member, felt that sometimes there was too much

formality, and getting a right balance of formality for different systems was more

important. They explained that currently the formality of the change control for live

systems support and projects sometimes conflicted and the processes needed to be more

flexible.

I think that formality is important, getting a balance right and a workablechange process is as important (Pharmas project team member)

The system controller may not have picked up on this as his work is mostly centred on

live system support as he does not work full time with projects. The change control

manager explained how Pharma is going to alter their change control system to tailor it

to a risk based approach of change management, to make it more flexible to the various

different areas it covers. If that was to happen she feels that the change control process

will be a lot slicker. This method would be a progression of Edwards and Douglas

(2000) recommendation, who recommended that that verbal authorisation is sufficient

on small projects but larger projects need a formal authorisation process.

It would appear the formality of a change control system is important to make people

follow the correct change processes and increase the chances of successful change. As

this change control system is used across multi applications and is used in both business

and project environments, it is just as important to provide flexibility within a change

control systems to accommodate for this.

49


4.2.3 Deviations to change and emergency procedures

During the literature review there was a disag

Documents

Project Failure Rowlands