Project Failure Rowlands

i
A Study Of Change Control And How It

Can Intervene In Scope Creep, To
Reduce The Risk Of Project Failure
Submitted By: Stephen Rowlands
Submitted In Partial Fulfilment

Of The Requirements For The Degree
BSc (Hons) Business Information Systems
Leeds Metropolitan University

May 2005
This document is Copyright of the author and Leeds Metropolitan University and protected
under UK and international law. The UK Copyright Service and Leeds Metropolitan University
refuses permission for this information to be reproduced for personal and educational use
provided all copies, extracts or adaptations Copyright The UK Copyright Service and Leeds
Metropolitan University. Commercial publication, copying, hiring, lending and reproduction is
strictly prohibited and constitutes a breach of copyright. This document is protected by copyright
law.
Document Distribution Tracker: DDT-450034-EE
Stephen Rowlands 2005
BSc Business Information Systems
ii
Acknowledgements
I would like to thank the following people for their assistance and help throughout the
completion of this study.
My initial point of contact and personal supervisor Paul Smith, for his help and
guidance which enabled me to complete this project.
My case study organisation and it respective employees, who have been extremely
accommodating 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 been
identified and properly attributed.
Signed:
Date:..
iv
Abstract
This project focuses on IT project failure, as many IT projects are still continuing to fail
today. It will discuss the causes of project failure and particularly look at prior research
on scope creep and the escalation of commitment to a failing course of action. These
have been identified as two significant causes of project failure. The secondary research
will look at how these two causes of failure may be managed, and recommend using a
change control system to do this. Qualitative primary research will be gathered from a
case study organisation by the use of interviews. These will look at the case study
employees opinions and features of their change control practices. This evidence can
then be compared to the existing research, to try to satisfy the projects aim and
objectives.
Table of contents
Chapter One: Introduction
1.0 Background
1.1 Aim and Objectives
4
4
1.1.1 Discussion of the aim and objectives
1.2 Indication of the following chapters
Chapter Two: Methods

2.0 Introduction
2.1 Secondary Research
2.2 Primary Research
2.2.1Ethics and considerations when conducting primary research

2.2.2 Quantitative or qualtative research methods
2.2.3 Sample for primary research
10
10
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

3.1.2 Reducing Project Failure
18
21
vi
3.2 Scope Creep
22
3.2.1 Defining Scope Creep

3.2.2 Why scope creep occurs
3.2.3 Understanding scope creep
3.2.4 Controlling scope creep.
3.2.5 Summary of scope creep
3.2.6 Scope creep and relations to project escalation
3.3 Project escalation
22
23
23
24
25
25
26
27
27
30
3.3.1 Recent examples of escalation

3.3.2 Reasons why Escalation happens
3.3..3 De-Escalation.
3.4 Change control.
34
3.4.1 Benefits of Using a Change Control System

3.4.2 Features of a Good Change Control System and best practice
3.5 Conclusion
35
36
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

4.2.2 The importance of formality in a change control system
4.2.3 Deviations to change and emergency procedures
4.2.4 ERP and the need for controls
4.2.5 Soft and hard controls of a change control system
4.2.6 Change control and effects on scope creep
44
47
49
50
51
53
Chapter Five: Conclusion and Reccomendations

5.0 Introduction
56
vii
5.1 Evaluation
56
56
5.1.1 Secondary research

5.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
68
69
69
70
74
75
Introduction and background

Aim
Objectives
Research Methods.
Schedule of key tasks.
Bibliography
Appendix B, Interviews
76
Appendix C, Change Request Form (GAMP4, 2002)
85
Appendix D, Change control system. (Maylor, 1999)
86
Chapter One
Introduction
1.0 Background
4
4
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 application
of information Technology (IT). With the emergence of e-commerce, the use of
technology is becoming just an accepted, indeed expected, way of conducting
business. Consequently organisations are increasingly looking towards the
application of technology not only to underpin existing business operations but
also to create new opportunities that provide them with a source of competitive
advantage. (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
3
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.

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.

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.
5
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.
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
2.2.1Ethics and considerations when conducting primary research

2.2.2 Quantitative or qualtative research methods
10
10
12
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).

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
9
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).

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.

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.

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
18
21

3.2 Scope Creep
22

3.2.6 Scope creep and relations to project escalation
3.3 Project escalation
26
27
27
30

3.3..3 De-Escalation.
3.4 Change control.
34

3.4.2 Features of a Good Change Control System and best practice
3.5 Conclusion
22
23
23
24
25
25
35
36
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 systems
moved 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).

According to recent research among European companies, businesses are still
making 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.

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 significant

contributors to project failure. (Business Line, 2001, p 4)

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.

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.

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.

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.

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 and
Houser 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).

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).

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 the
effectiveness of managerial actions taken to turn around or redirect such
projects (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 deescalation. 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 system
designed to effectively manage the change of scope. (Burke, 2003, p105).
35

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 management
as 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, but
temporary 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
42
43
44

4.2.5 Soft and hard controls of a change control system
44
47
49
50
51
53
42
Findings

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.

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.

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 control
manager)
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 are
focusing 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.

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 record
what they want to do, how they want to do it and how they are going to get there
in the end. If we didnt have that formal process we would get people saying we
want then and the halfway down the line changing their mind (Pharmas system
controller).
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 workable
change 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

During the literature review there was a disagreement in regards to what should be done
if an emergency arises. This disagreement was between Burke (2003) who stated that
there should be an automatic approval process for emergencies and Lamond (2002) who
suggested that change control should be followed and that all the relevant testing be
signed off before the change moved to production. After this, the auditors should review
the change to check all documentation is in place. This argument was explored during
the interviews and the interviewees were asked about their emergency procedures.
Initially when a request for change is made the responsibility of prioritising the change
lies with one of Pharmas system controllers. The system controller states that anything
of low priority will be necessary but have a low impact on the business. Likewise,
something of high priority is a problem. If they get a high priority change they still try
to fit it in the next available work package. Otherwise, as the system controller stated
its undoing all the principles of sitting down and thinking about the problem, this is
where mistakes may be made. If it is not possible to fit the change in the next work
package the change is classified as a fast-track, which is the name for an emergency
change. The system controller tries to avoid fast-tracks as he states that all the soft side
of change control goes out of the window with a fast-track.
The interviewees were questioned if they had a different change control process for fasttracks, as Lamonds (2002) recommends using an emergency plan. The system
controllers response was to say that the actual process is fixed and he would follow it,
the only change there is, that they have to compromise on the soft side of change
control.
50
I wouldnt try to intervene with the change control principles (Pharmas system
controller)
The change control manager had the same response as the system controller, stating that
when an emergency fix is required, the change control process is followed exactly. This
response was backed up by the project team member when asked the same question.
The only difference in the change control process when a emergency occurs is that an
extra signature is required by the system owner as the change has a bigger impact
because it hadnt been planned. This means it has the potential to damage the system
and prove a high risk to the business. The change control manager explained that the
system owners signature is needed as they are very senior, and are able to calculate and
take responsibility to for the risk of letting a fast-track progress to the production
system.
If we get a fast-track call it follows exactly the same procedure as any other
change control, except there is an additional signature that has to be signed by
the system owner (Pharmas change control manager)
These findings correlate with Lamonds (2002) recommendation that all the change
control procedures must be followed in an emergency. In fact the case was that extra
controls are added to compensate for the added risk to the system. Thus providing a
valid argument against Burkes (2003) recommendation, that there should be an
automatic approval process in place for when an emergency occurs.

It would appear that ERP packages such as SAP need tighter change control processes
than smaller systems, as they are more prone to scope creep as highlighted by
Comerford (2000) and Adshead (2003).
51
From a live systems support viewpoint the change control manager explained how their
ERP systems need tight controls due to the fact that it is producing drugs and if the
controls arent tight enough, they potentially threatening lives. But even in a small SAP
installation she states that they would certainly need an approval process that would be
adequate to the business. From a project point of view, the project manager explains
how SAP is a highly integrated system, which is truly linked behind the scenes and that
it is that broad range of functionality that needs the tighter controls than smaller
applications.
With the big systems like SAP it would be very easy to loose it on the change
control front, so its like a funnelling mechanism where everything has to pass
one point so we can have a better handle on what is going on, as it is hard to
keep track of what everybody that is working on the system is doing (Pharmas
project manager).
4.2.5 Soft and hard controls of a change control system.

One of the most significant discoveries from the primary research was that change
control is effective in two ways. Both from the soft controls of having a change control
process in place, and from the hard controls of the features of a change control system.
The term soft control refers to those that are intangible and arise from the way that
people perceive things. The term hard control focuses on controls that are physically in
place and that actually have a direct impact on things. This is felt to be a significant
finding as this aspect of change control had not been found within the secondary
research. The hard controls of a change control system are the actual change control
process, where there is a physical change control mechanism. This is the formal review
and approval process where the changes and therefore scope of a project can be
controlled from a higher level. Here the requests for changes are assessed to whether
they are meeting a genuine business demand.
52
There is also a much softer side to change control where the need for change is managed
before it interacts with the physical and formal aspects of change control. This aspect of
change control was realised during the interview with the system controller. The system
controller explained how he initially challenged back any requests for a system change,
immediately asking if the user had discussed the problem, trying to work around the
problem by using any other means. This may be done by changing their working
practices or by using other functionality of the system. He will also run an estimated
initial cost benefit analysis for hard or softer more strategic benefits.
Ill try and challenge back immediately, why do you want it? Whos impacted?
Have you discussed the change with all the areas that are impacted? Is there a
non system way around this? We challenge the changes immediately. (Pharmas
system controller).
The system controller said by just making users stop and think the problem will be
solved another way, and a formal request to change the system will be avoided. The
soft controls of Pharmas change control a system is also promoted by the formality of
the change control process. As the user who raises the problem must be free to test the
change which ensures that any changes that are raised by users are necessary as they
have to commit themselves to do the testing.
Some of the control mechanisms are down to people such as the system
controllers who know which changes they should be putting through and try to
persuade people to use what is standard (Pharmas project manager).
The system controller explained how this is now part of the companys culture, as the
users know what kind of requests they should be asking for. They now know that any
requests for change have to be justified, and therefore only genuine problems will come
to his attention. This results in less but more justifiable requests for change, which
means that fewer changes actually go to the change control process to be rejected. This
53
has an affect on the number of change requests and the justifiability of those requests.
This results in the reduction of scope creep, as scope creep are changes to the system
that dont benefit the business objectives as explained by Liebmann (2000). The hard
and soft controls of a change control system are summarised in figure 1.
Figure 1.
Soft controls
Hard controls
The initial challenge back of requests for

changes by the system controller.
The problem escalation path.
The automatic consideration of working

around the problem by changing working
practices, than requesting a change to the
system.
The formal review and approval process.
The formality of the change control

system ensures that only necessary
changes are put forward for a formal
request.
Change control is built into the users

working culture. This ensures that the
users should know what type of changes
they should consider to put a formal
request to change the system.

The project manager explained that scope creep is controlled on a number of different
levels. There is a high level control where the huge spend and complexity is concerned.
This is controlled by a top level governance layer consisting of key IS and business
people. The governance layer is known as a steering group, this keeps the project in
scope and on path, by producing project charts and monitoring the projects progress.
54
There is also a lower end of control. This is where the change control system fits in. As
explained above a change control system encourages the requestors of a change to
request changes that are beneficial and justifiable to the business, which will reduce
Liebmanns (2000) definition of scope creep. This lower end of control is where
individual projects and reports are concerned, and where the project expenditure and
change complexity is less. The project manager explains that even though the changes
may be smaller and the cost of the change initially seems small, the cost can sometimes
be enormous, this is described by Zimmerman (2000). Therefore a change request
system ensures that only needed changes, satisfying a genuine business need are
approved and implemented within the system. The project manager stated that any
requests for change must be approved by a formal approving body, which itself is a
method to intervene in scope creep and the direction of the project.
55
Chapter Five
Conclusion and Recommendations
5.0 Introduction
56
5.1 Evaluation
56

56
57
59
5.3 Conclusion
60
56
Conclusion and Recommendations

5.0 Introduction
This concluding chapter of the individual project will look at what extent each of the
individual objectives for the project was achieved and to what extent the aim of the
individual project has been accomplished. It will then critically evaluate the project to
find any weaknesses in the research and the methods used. It will then finally draw on
the findings from the primary research and the secondary research and it will make an
overall conclusion of this study.
5.1 Evaluation
This section will highlight any possible weaknesses found within the research and
evaluate to what extent the individual aims and objectives have been accomplished.

The literature review provided a good grounding of knowledge to enable the researcher
to understand the subject area and the key issues surrounding it. It has looked at the
causes of project failure from a broad point of view and then focused on two key causes
of project failure.These were scope creep and project escalation. These causes of project
failure were then researched. It was found that using change control could help reduce
the risk of project failure in relation to these two causes. During this research it has been
perceived that different authors viewpoints have been taken into consideration and
have all been well argued.
57
A weakness seen of the literature review was the lack of strength of the research on
change control. There was an abundant amount of literature describing the change
control process but the availability of literature describing authors opinions about
change control seemed to be somewhat rare. This made it much more intriguing to
explore the area of change control within the primary research, and also to explore its
links to scope creep and project failure.
As always with researching literature the subject area was vast and it was difficult to
define a boundary to where the scope of the research should stop, but it was felt that all
the research carried out was relevant to each of the project individual objectives.

The primary research was used to explore the opinions of Pharmas employees, who
heavily interacted with and understood Pharma's change control system. The research
method used for the primary research was a set of one-to-one, semi structured
interviews with open ended questions. Each of the interviewees was selected due to
their knowledge of the change control system and their heavy interaction with it. This
research revealed some very intriguing findings, including the discovery of the soft
influence of change control was explored in the findings section of this project.
It was felt that the number of candidates for the interviews was limited, as only four
employees were interviewed. This was due to the specialisation of the subject of change
control. The candidates were chosen due to their greater expertise and knowledge
surrounding change control. It was therefore felt that if other candidates were chosen,
58
their responses may not have been as valid as the ones that were chosen and therefore of
less use. It is felt that it may have proved an advantage to have interviewed a larger
sample of people and the researcher would have liked to have explored how a user
perceives change control, this would enable the further exploration of the findings
relating to the soft controls of change control.
The researcher had looked at qualitative information for the primary research, but had
no qualitative information to back the findings up. The constraints of obtaining
quantitative data were described in the research methods chapter of this project. It is still
felt that if the research had the inclusion of quantitative data and used a larger sample
size the findings would be more justifiable, this is seen as a weakness in the research.
As the findings from the primary research were based on qualitative research, there was
no quantifiable evidence that change control can help reduce scope creep. This may
have been achieved if a pilot study or simulation was carried out with the case study, to
enable the observation of the different phenomena of change control from different
viewpoints (Yin, 1994). This should be done with the use of a control to allow
comparison and justification, to ensure the integrity of any findings (Robson, 2002).
It must also be noted that the case study only looked at the key issues and views of only
a small selection of people from one organisation and from one industry sector that had
an individual company culture (Ward and Peppard, 2003). Change control may be used
differently by different organisations and that the findings may not be universal and
consistent with other studies on change control. The research would have been more
valid if multiple case studies were used to gain a holistic view on the research topic
59
(Yin, 1994), looking at both different industry sectors and sizes of organisation. Due to
time and budget constraints this was not possible.
This section will analyse to what extent the individual objectives have been met. In
regards to objectives one to three, the literature review has looked at a wide range of
causes of project failure and discussed why these projects are continuing to fail. The
literature review has also looked at scope creep and its causes and extensively looked at
project escalation, highlighting any relevant links between the two, thus completing
objective two. The literature review has also looked at change control and how change
control is exercised to place constraints upon a project. This shows how scope creep
may be reduced by change control, which indicates that objective three has been
completed.
In relation to objective four the primary research had explored Pharmas employees
views of their change control system and questioned them about their change control
practices in relation to interest areas raised by authors in the literature review. The
findings of this research were used to back up claims from the existing authors views
or argue against them. There was also an aspect of change control that was discovered
had not been mentioned by any of the literature reviewed and therefore may be a new
research topic of interest. This aspect was that change control can be effective by the
use of formal constraints and also soft informal constraints, which in effect concluded
that these constraints would help reduce scope creep. Thus objective four has also been
completed, but the findings would have been more justified if there was quantitative
60
evidence to back up the claims that change control can reduce scope creep, and
respectively reduce the risk of project failure.
5.3 Conclusion
Areas of interest for further research are to provide quantifiable evidence to show what
extent change control can reduce project failure, which as previously mentioned may be
done by the use of a prototyping study method. It would also be interesting if other
organisations change control systems were analysed to see if change control systems
can be classified, as this research has shown that they seem to be personalised to the
individual business. Each system may be unique, as the change control manager stated
that the tools of change control can be categorised but systems are continuously
changing being shaped by internal and external forces in conjunction with the
continuous learning of the company.
A change control system, whether its used in live systems support or for projects,
offers many benefits to an organisation, not just control over scope creep. If a change
control system is to be successful within a company or project the importance of it must
be recognised and be enforced by its formality. The key is to ensure that the correct
processes are followed. It must be recognised that a change control systems is effective
in two aspects, one being the formal process that changes follow and the other is due to
having a change control process in place. Just by having a change control process in
place ensures that changes are considered much more carefully and taken less granted.
This soft aspect of change control as discussed in the findings had not been identified
during the secondary research, which may even indicate that this is an undiscovered
aspect of change control that may be researched. Once a good change control system
61
had been established the importance and significance of it should be recognised,
especially if its being used in conjunction with an ERP package, as ERP packages are
highly integrated and difficult to keep control of. This needs to be built into the culture
of a company or project team to ensure that correct change control processes are
followed and used appropriately. Change control should be followed at all times and as
the research has shown, must even be followed if an emergency arises to ensure the
integrity of the system or project.
For change control to be effective to the system that it is supporting it must be

individually tailored to the business and therefore the attributes of the businesses
systems. Change control should also allow flexibility to suit the individual systems or
projects that it may support. It is important to note it must be flexible in the processes
concerned, to allow use between different applications it may support, it must never be
flexible in the formality as you still need to keep the integrity of the system and make
sure that every change that is requested is assessed for authorisation. This will ensure
that the change is relevant to the project or business plan. This in turn allows controls to
enable the intervention of scope creep and effectively reduce the risk of project failure.
62
Bibliography
Adshead, A. (2003) Goodyear restates accounts after finding errors in SAP roll-out:
Reed Business Information UK, Computer Weekly, November, pp. 10.
Albright, B. (2003) Are IT budgets beginning to loosen up: Frontline Solutions.

January, Vol. 4 Issue 1, pp25-28.
Arksey, H. Knight, P (1999) Interviewing for social sciences: An introductory resource

with examples. London, Sage Publications.
Bell, J. (1999) Doing Your Research Project: A guide for first-time researches in
education and social science. 3rd ed. Philadelphia, Open University Press.
Bennett, M (2003) Management week How to Steer IT Development. IT Week.
February 2003.
Berry, J. (1999) Bringing some clear thinking to IT projects. Internet Week. September,
Issue 779, p29.
Biggs, M. (2000) Technology won't end project failures; communication is key.

InfoWorld. January, Vol. 22 Issue 5, p70
Bocij, P. Chaffery, D. Greasley, A. Hickie, S. (1999) Business Information Systems,

Technology, Development and Management: Essex. Pearson Education Ltd.
Brockner, J. (1992) THE ESCALATION OF COMMITMENT TO A FAILING

COURSE OF ACTION: TOWARD THEORETICAL PROGRESS. Academy of
Management Review. January, Vol. 17 Issue 1, pp39-62.
Brockner, J. Houser, R. (1986) Escalation of Commitment to an Ineffective Course of

Action: The Effect of Feedback Having Negative Implications for Self-Identity.
Administrative Science Quarterly. March, Vol. 31 Issue 1, pp109-127.
Burke, R. (2003) Project management, Planning and Control Techniques. Fourth

Edition. West Sussex. Wiley
63
Business Line (2001) India: Making IT projects tick: Five simple rules can make all the
difference to an IT project's success, says Brian Katzen. FT Asia Africa Intelligence
Wire, September, pp1-5.
Bywell, M. (2003) Experience counts in IT procurement: Reed Business Information

UK, Computer Weekly, October 2003, p56.
Comerford, J. (2000) Plan the complexity out of ERP implementations. Business

Journal (Central New York), February, Vol. 14 Issue 7, pp26-27.
Cule, P. (2000) Strategies for Heading Off is Project Failure. Information Systems
Management. Spring 2000, Vol. 17 Issue 2, pp65 74.
Denzin, N. K. (1970) The research act in sociology: A theoretical introduction to

sociological method. London. Butterworths.
Denzin, N. K. (1989) The research act: A theoretical introduction to sociological

method 3rd edition. London. Prentice Hall.
Drummond, H. (1998) Is escalation always irrational?: Organization Studies (prior to

2003), Vol. 19 Issue 6, pp911-28.
Edward, E. Douglas III, CCC. (2000) Project Trends and Change Control. 2000 AACE
International Transactions. pp. CSC10 CSC10.5
EIU Business Europe (2003) Europe: Information technology - IT projects can lose
serious money: EIU Business Europe, March.
Field, M. Keller, L. (1998) Project Management. Oxford, The Open University.
Fielding, N. G. Fielding, J. L. (1986) Linking data. London, SAGE Publications.
GAMP4 (2002) Good Automated Manufactures Practice: ISPE.
Gibson, S (1998) Lessons in wasting time and money. PC Week, September, Vol. 15
Issue 37, p74.
64
Hallows, J. (1998) Information system Project Management, How to Deliver Function

and Value in Information Technology Projects: New York. AMACOM.
Hart, C. (2001) Doing a literature search. London, Sage.
Hulme, G.V. (2002) Guarding against threats from within. InformationWeek.

December, Issue 920, p. 20.
Jick, T. D. (1983) Mixing qualitative and quantitative methods: triangulation in action.

London. SAGE Publications.
Kanodia, C. Bushman, R. Dickhaut, J (1989) Escalation Errors and the Sunk Cost
Effect: An Explanation Based on Reputation and Information Asymmetries. Journal of
Accounting Research. Spring, Vol. 27 Issue 1, pp59-77.
Keil, M. (1995) Pulling the plug: Software project management and the problem of
project escalation. MIS Quarterly, December, Vol. 19 Issue 4, pp421- 446.
Keil, M, Mann, J. The Nature and Extent of IT Project Escalation: Results From a
Survey of IS Audit and Control Professionals. IS Audit and Control Journal. pp. 40-48.
Keil, M. Mixon, R. Understanding runaway information technology projects: Results

from an international research program based on escalation theory. Journal of
Management Information Systems. Winter 1994/1995, Vol. 11 Issue 3, pp65-85.
Keil, M. Robey, D (1999) Turning Around Troubled Software Projects: An Exploratory

Study of the Deescalation of Commitment to Failing Courses of Action. Journal of
Management Information Systems, Spring 1999, Vol. 15 Issue 4, pp63 87.
King, N. (1994) The qualitative research interview. London, Sage.
Lamond, B. (2002) Program change control. The Internal Auditor. Altamonte Springs,
June, Vol. 59, Issue 3; pp25-27.
Liebmann, L (2001) Don't Be a Creep. Network Magazine. May, Vol. 16 Issue 5, p. 112.
Maylor, H. (1999) Project Management: Second Edition. London. Pitman.

65
Moreton R. (1990) A process model for software maintenance. Journal of Information

Technology. June, Vol. 5 Issue 2, pp100-104.
Murray, J.P. (2000) Reducing IT project complexity: Information Strategy. The

Executive's Journal. Spring, Vol. 16 Issue 3, pp30 39.
Oliver, P. (2003) The Students Guide to Research Ethics. Maidenhead, Open

University Press.
Robson, C (2002) Real world research: 2 nd Edition. Oxford, Blackwell Publishers Ltd.
SAP labs inc. (1999) Authorizations Made Easy, Generating Authorisation Profiles,
Release 4.5A/B: Palo Alto, CA, SAP AG,
Sapsford, R. J. Evans, J. (1984) Evaluating a research report. London, Harper and

Row.
Schulz , Y. (1999) Home IT projects hold lessons for the enterprise. Computing
Canada. September, Vol. 25 Issue 36, pp21-22.
Sharp, D. J. Slater, S.B. (1997) Project escalation and sunk costs: A test of the
international generalizability of agency and prospect theories. Journal of International
Business Studies 1997 1st Quarter, Vol. 28 Issue 1, pp101-21.
Staw, B. M. (1976) Knee-deep in the big muddy: a study of escalating commitment to a

chosen course of action. Organizational Behaviour and Human Performance. pp. 2744.
Staw, B. M. Ross, J. (1987) Knowing when to pull the plug. Harvard Business Review.
March/April, Vol. 65 Issue 2, pp. 68-74.
Stedman, C. (1999) ERP needs software change management. Computerworld.

February, Vol. 33, Issue. 5, p. 12.
Ulfelder, S. (2004) Avoiding Project Pitfalls. Computerworld. January, P. 40.
66
Vowler, J. (2003) Will IT stand or fall?: Reed Business Information UK . Computer
Weekly. May, p.44.
Wateridge, J (1999) The role of configuration management in the development and

management of information systems / Technology (IT/IS) projects. International
Journal of Project Management. Volume 17. Issue 4. pp. 237-241.
Whyte, G. (1993). Escalating commitment in individual and group decision-making: A

prospect theory approach. Organizational Behaviour and Human Decision Processes,
pp. 430-55.
Yin, R. K. (1994) Case study research: Design and methods. 2nd Edition. California,
SAGE
Zimmerman, E. (2000) Preventing Scope Creep. Manage. February, Vol. 51 Issue 3,

pp. 18-20.
67
Appendices
68
68
69
69
70
74
75
Introduction and background

Aim
Objectives
Research Methods.
Bibliography
76
85
Appendix D, Change control system. (Maylor, 1999)
86
68
Introduction and background.

The existence of an organisation crucially depends on the effective application
of information Technology (IT). With the emergence of e-commerce, the use of
technology is becoming just an accepted, indeed expected, way of conducting
business. Consequently organisations are increasingly looking towards the
application of technology not only to underpin existing business operations but
also to create new opportunities that provide them with a source of competitive
advantage. (Ward and Peppard, 2002 p.1).
Many of the large Information systems used by most organisations will have been
developed via a project. Due to the fast pace of changing technology in todays world,
many of these organisations will have to update, or replace their existing technology to
keep a competitive advantage over their rivals. Or just to keep up with the fast changing
times of todays technology.
In todays ever-changing world, nothing lasts very long, and computer-based
systems are no exception. In our shop, we sometimes find ourselves changing
systems before the old ones even get into production. (Litchfield, 2001p.33)
Therefore, you would expect large companies to be able to manage their projects and
implement their IT systems effectively, but many of these projects are still continuing to
fail. There are many reasons why IT projects are failing, but it appears that projects
running overrunning budget, over schedule and increasing project scope are the major
reasons of failure. (Hallows, 1998) (Holt, 2003).
IT projects will continue to enjoy the worst failure rate of any industry and
continue to cost far more than agreed (Watton, 2003).
Scope changes are probably the major cause of project failures (Hallows, 1998
p.8).
69
The focus of this project is to study the area of project failure, and how increased scope
changes described by Hallows (1998) and Holt (2003), may contribute to the high
failure rate of IT projects. This project will also look at a real-life organisation, and
analyse how it uses change control (a method of change management) as a tool for
controlling scope creep, to help contribute to the success of a project.
The researcher will use a leading Pharmaceuticals company as the real-life organisation
for the means of this study. This company will be referred to as Pharma throughout
this 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 the time spent with Pharma the researcher worked
to a strict change control process, whilst working to this, the researcher realised how a
good change control system contributed to the success of an IT project implementation.
Aim
The aim of this project is to study the area of project failure, and how scope creep has a
major contribution to this. This project will also highlight the need to control project
scope creeps and looks into how a real life organisation uses a change control process to
control this.
Objectives
5. To discuss why many IT projects are continuing to fail.
6. To investigate why project scope can increase and also highlight any links to
project escalation.
7. To analyse how change control systems can help reduce project scope creep.
70
8. To evaluate the effectiveness of Pharmas change control process in relation to
controlling project scope increase, and also highlight any other benefits of using
change control.
Research Methods
This section describes the proposed research methods that will be used to achieve the
projects individual objectives.
The method that will be used to research objectives 1, 2 and 3, will be a literature
review of existing text. Many books on effective project management are available. A
disadvantage of using these texts is that many may be dated, and due to IT being a fast
changing industry sector area some of these texts may be irrelevant in relation to today
business. To compensate for this, literature in current journals will be examined,
including case studies of organisations that have encountered project failure to back up
the theoretical claims made within older texts. (Birley and Moreland, 1998). Many texts
will be considered as Luck (1999) states that all texts need to be read critically and
therefore compared. Even though this is secondary research many of these journals may
have been written using primary research at their time of publication.
An alternative to this would be to look at an organisation whose project has recently

failed, this would be primary research. Due to time constraints, and the fact that many
companies dont like to discuss their failures, as it may put them in bad light to their
share holders, therefore it would prove difficult to find such a company. Also one
company wouldnt represent all industries sector areas. Therefore many of the findings
would be limited, respecting some findings maybe universal.
71
The texts used for this study will be texts that are readily available to the researcher, due
to time and cost constraints.
A Rich Picture will be drawn after the literature review to gain a greater understanding
and overall view of the read literature and issues surrounding this study. Skidmore
(1994) describes this soft systems method in greater detail.
For objective (4) a case study on the company Pharma will be used. This company was
chosen because the researcher has worked for the companies SAP security team during
his university industrial placement, he is familiar with the company and has contacts
within the company. The researcher is aware that this companies change control process
or business practices will not represent all companies, and that using multiple case
studies would be a better way of conducting primary research for this individual project.
Due to time limitations the researcher is restricted to using this one company for his
case study.
The researcher will use a number of semistructured interviews to obtain information

about the companies change control process. This is an example of qualitative research
as described by Silverman (2000). A semi structured interview allows the researcher to
follow a set of questions but also probe into areas of interest to the research topic (Bell,
1999). For the interviews people will be chosen from the company with experienced
knowledge of Phamas change control systems and project management. People such as
members of their change control team and current project mangers. These people will be
used as their experience and knowledge will be able to enrich this study. An alternative
method to interviewing to collect primary data using a qualitative research method may
72
be using questionnaires. This method has not been chosen as it only allows limited
answers to the given questions as the structure of questions will be fixed and does not
allow any probing into the questions unlike that of semi structured interview offers.
Plus, if an answer in a questionnaire is not understood it is hard to obtain any clarity.
There are also only a limited number of people within the company that has expertise in
this area of this study, and a mass questionnaire will be non-effective in receiving a
qualitative response. The researcher has also chosen to interview to show a willingness
and commitment to the company to create a relationship with the organisation, as it is
believed a better response will be obtained if the interviewer is present.
The researcher will also try to obtain documentation on Pharmas change control
process, it needs to be considered that this may prove difficult because of company
confidentiality. The researcher will also use his experience and observations from
working within the company for over a year. The limitations of this are that the
researchers views and interpretations may be biased from his experience (Bell, 1999),
but it is a researchers duty to offer any possible non biased views.
To help Evaluate the effectiveness of Pharmas change control in reducing project scope
creep comparisons will have to be made against literature obtained in the literature
review against finding from the interviews and other information obtained from
Pharma.
The researcher has to take into consideration the ethics of using a case study to obtain
primary data. Therefore the companies name will not be disclosed and the name Pharma
will be given for this company. Also none of the interviewees names will be disclosed.
73
The researcher will also need to be granted permission by the company to use them as a
case study. The company will be well informed of what information will be used
throughout this study and agreements of use of materials and interviews will have to be
obtained. The researcher must not keep records of any of the interviews or company
information, longer than is needed. The ethics that have to be considered are described
by Oliver (2003).
After information on Pharmas change control process has been obtained a SWOT
analysis of their change control system will be completed. This will help to understand
the nature of the environment surround their change control systems by identifying their
strengths, weaknesses, opportunities and threats in relation to their change control
system (Brooks and Weatherston, 2000). This analysis is usually done on organisations
but it may prove useful to understanding the environment surrounding Pharmas change
control system.
The researcher is confident that authorisation will be given by Pharma to use them as a
case study for this project, but if it can not be obtained objective (4) will have to be
reconsidered.
74
Month
Weeks
November
1 2 3 4
December
1 2 3 4
January
1 2 3 4
February
1 2 3 4
March
1 2 3 4
April
1 2 34
May
1 2 34
Proposal.
Obtain authorisation
for case study.
Lit review.
Organise interviews.
Plan interviews.
Draw Rich Picture
Write draft lit. review

for 16th Feb.
Carry out interviews
Analyse interviews
Complete SWOT
analysis.
Write up project.
Proof read / Binding.
Hand in (4th of May).
75
Bibliography
Bell, J. (1999) Doing Your Research Project: A guide for first-time researches in
education and social science. 3rd ed. Philadelphia, Open University Press.
Birley, G. Moreland, N. (1998) A Practical Guide To academic Research. London,
Kogan Page Limited.
Brooks, I. Weatherston, J. (2000) The Business Environment: Challenges and Changes.
2nd Edition. Essex, Pearson Education Limited.
Hallows, J. (1998) Information Systems Project Management: How to Deliver Function
and Value in Information technology Projects. New York, AMACOM
Holt, M. (2003) Why do so many IT projects Fail: Butler Group Review Journal Article.
June 2003, p1.
Litchfield, S. (2001) CRADLE TO GRAVE: Network Computing. August 2001, Vol.12
Issue 17, p33.
Luck, M. (1999) Your Student Research Project. Hampshire, Gower Publishing
Limited.
Oliver, P. (2003) The Students Guide to Research Ethics. Maidenhead, Open
University Press.
Silverman, D. (2000) Doing Qualitative Research: A Practical Handbook. London,
SAGE.
Skidmore, S. (1994) Introducing Systems Analysis. 2nd Edition. Oxford, Blackwell
Publishers.
Ward, J. Peppard, J. (2002) Strategic Planning Information Systems. 3rd Edition.
Sussex, Wiley.
Watton, A. (2003) Managing Information Strategies (MIS) February 2003. p.22-3. UK,
Fairfax Business Media.
76
Project manager
Interviewer: In you opinion do you feel that change control has any influencing factors
upon scope creep?
Project manager: There are different layers to the change control, in big projects where
you can control change and scope creep is at the governance layer, it the interactions
between the project manger and the key IS people and key business people that keeps
projects in scope, laying down the path that they follow by using project charts, with the
governance behind that. This would be the steering group where people have a key
influence over the scope.
Interviewer: How does it effect controlling the scope when requests for changes arise?
Project manager: The top level governance is important in big projects because that is
where you get big change in scope with huge spend and complexity. When you get
down to low level change control down to individual reports, some of the control
mechanisms is still down to people such as the system controllers who know we should
be putting those changes through and try to persuade people to use what is standard, that
have the hard job as they state that they cant have any extras and therefore get the grief.
Not all companies are the same, pharmaceuticals are very regulated with validated
systems and we have a very formal change control system. That formal system does
allow you to put real control in on it, so there has to be a formal request which is
formally reviewed by IS, quality assurance and a business representative. Effectively
then everybody is signing up to that so it is another method to intervene in scope creep
and the direction of the project.
Interviewer: who else is on the change control approving body that you just mentioned?
Project manager: Three signatures are needed which are IS which is usually myself or
the technical manager, quality assurance who are taking a GMP perspective on the
change and the business process owner who have to buy into the change as the change
originates from the people who do not necessarily the managers but they need to make
sure that their processes dont deviate off from the norm or that their findings are spent
on the important things.
Interviewer: In your opinion do you feel that the authority approving the change is
correct?
Project manager: I think that works well, that body does work well. On projects you
need key representations on there, to make sure that you are focusing on what really
needs doing. Because the governance structure are not geared up to making decisions
quickly you need people who can make proper decisions about it, and have that decision
respected, as they are laying down their views for a wider group.
Interviewer: What criteria does the approving authority consider for the approval of
changes?
77
Project manager: Is it satisfying a genuine business demand, is there a proper business

case. As you do find that people put in their pep projects particularly when you get into
big systems, it far easier to slip your pep project in than if it was to stand up on its own
merits. We also check if we will get payback as something that may seem small, the
cost of doing it with the complexity is enormous.
Interviewer: Are those things always considered?
Project manager: They should always be considered, there are sometimes that you may
choose to put something in thats a bit more strategic, that may take me in a direction
that I want to go. We consider both soft benefits as well as hard benefits. We also
consider cross functional impact as SAP is a broad system
Interviewer: Do you feel that using an Enterprise Resource Planning package such as
SAP needs to have tighter controls in place than other systems?
Project manager: Yes, interesting question. With big systems like SAP it would be very
easy to completely loose it on the change control front, so its like a funnelling
mechanism where everything has to pass one point so we can have a better handle on
whats going on, as its hard to keep track of what everybody that is working on the
system is doing. The smaller applications need less formal change mechanisms to keep
track of what is going on, as the changes can be discussed. Things like SAP are that it is
a highly integrated system which is really truly linked behind the scenes. Its that broad
range of functionality that needs tight controls.
Change control manager.

Interviewer: What change control processes are in place and what are the features of
your change control system?
Change control manager: The main features of our change control system are the fact
that it starts off as a problem log, the customer calls their super user with a problem. If
they cant resolve the problem it will be forwarded to the SAP helpdesk. The problem
log is stored on a database and gets sent to the technical lead who allocates it to
somebody with the appropriate skills to give an assessment, it may then go to the
configuration team, the basis team and always to the security team and then it goes to
the change panel. The unique thing about ICON is that the IS run the change panel and
no the business, the IS and business change are on the same change control form and
configuration management is also on that form. After the change panel it is signed by
QA, a SAP architect and the business process owner who has a high level overview of
the direction of the business. This gives approval to proceed from then on its allocated
to a work package which is classed as release management in generic terms, and then
the work begins on it. We have to follow the V model for testing, once its tested we
have a further sign off by quality assurance and the business process owner to confirm
that it is correct then COMVAL actually sign it to make sure everything can go through.
Once its gone in my team move all the code through and then we have a closure
procedure. Once its closed it is then part of a quality audit.
78
Interviewer: How formal is your change control system, do you think that formality is
important?
Change control manager: It is a very formal system that we have currently got and thats
because the system makes our drugs. Its very important that it is formal, before we had
that formality and in systems that dont have that formality because they are not making
drugs or using it for ERP it falls over regularly and they loose data regularly. In our
FDA validated environment its not something we can afford. Sometimes it is a bit anal
retentive and there is a bit too much of it, we are certainly looking at a risk based
approach in the future which is something new that has come out with the FDA, where
change management can be risked based, Once we do that I feel the system will become
a lot slicker.
Interviewer: Why do you feel the use of change control is important for Pharma?
Change control manager: I our business drugs that go out the gate have to be made the
same right first time every time. The recipes for those drugs and how theyre controlled
is within our SAP system and that means if we change it we can potentially kill people.
We need the processes to be tight so its right first time every time to maintain our
licence to operate.
Interviewer: Do you feel that using an Enterprise Resource Planning package such as
SAP needs to have tighter controls in place than other systems?
Change control manager: An ERP system needs tight controls, the tightness of it doesnt
need to be as tight as ours as if youre not threatening lives. A SAP installation in a
factory where you have quite a small turnover but you just want to manage it by the
system, maybe you dont need those tight controls. We have a huge system and I think
it needs to be managed, even if we didnt have change control that would have to be
managed or you will be changing things back and forth and not knowing why you did
something that needs to be controlled. There would certainly need to be approval
process in place that would be adequate to the needs of the individual business.
Interviewer: What are the most common requests for changes that you get?
Change control manager: New reports, the other sort of change we get is config master
data configuration in our case is all controlled, because our business changes so
frequently.
Interviewer: Your SAP systems has different libraries (for example a development
client, a testing client and production), is this important to a projects change control?
Change control manager: Yes, because it allows you to maintain control of you system.
So what ever change you put in your real life system you can have a play with it, and it
fails in the development system and crashed were not really that bothered, so your
managing the risk and the impact from the business. I would expect every reasonable
system that is manage properly to have a landscape of sorts, I would expect the size and
complexity of that to be relevant, that is the key thing is to make it relevant. For
instance you shouldnt be training people in the production client but again you dont
79
want to be training in a testing environment. So it is nice if you do have training, testing
and production as a minimum, it doesnt necessarily have to be on separate servers as
ours are.
Interviewer: What procedures do you have in place if an emergency fix is required? Are
the change control procedures followed and how closely?
Change control manager: Exactly. If we get a fast-track call it follows exactly the same
procedure as any other change control, except there is an additional signature that has to
be signed by the system owner. This is because the impact of the fast track change is
bigger because it hasnt been planned, it has the potential to damage a lot of work that is
going on, its going out of the release management process so its given the business a
higher risk of failure because its not being managed properly and therefore you need
somebody very senior to say theyre happy to calculate and accept that risk. Their wet
ink signatures may not be got on that day, but it would be via a witnessed telephone call
and signed on their behalf, and they would sign it the next working day.
Interviewer: What you your view be to if a change is needed and we will go directly
into the production system make that change, then well do all the relevant paperwork
after.
Change control manager: Id question what risk assessment has gone on, who has sat
down and worked out if thats going to affect the rest of the business. It may solve one
problem but cause forty thousand more, and that is a huge risk. You have no
documentation to trace back what youve done or the way you have changed it. It would
never be done. There are certain configurations we can change directly in production
without change control but it is managed by problem management.
Interviewer: What are the other uses of your change control system, for example
configuration management etc, why are these important?
Change control manager: We use it for configuration management and SAPs transport
management to move the code through as once the code has been put into there by the
developer they cant change the code once its released and its up to us to move it
through the environments and track the changes. We also do resource management
through it with estimates, this includes cost benefit management.
Interviewer: What did you do before you had a change control system?
Change control manager: There has always been some sort of change control system on
SAP, because we were a regulated system. It first started out as a spreadsheet, as errors
have been made and issues raised it has developed into an access database and from this
into a very complex access database, and now into a sequel server and hopefully into an
ERES compliant system. The change control system is growing all the time and process
never sits still its, if it does we are failing somewhere.
Interviewer: Is your change control system designed to any specification?
Change control manager: Its designed to GAMP 5, it cover the GAMP categories for
the FDA. Our change control tool is not yet validated as it is not yet ERES (electronic
80
records electronic signatures) compliant. If it becomes that we would need a whole new
system. The tool are categorised but the systems are unknown. It changes through
continuous learning, and the internal and external forces shape the change control
system.
SAP security project team member

Interviewer: What influences does change control have on your work?
Project team member: change control is a great influence on what we do, especially on
projects and also on business support. Without ridged change control processes you end
up in a situation where you dont have confidence in what goes through the system, you
cant find where errors occur on the system and you also have no control over the
system.
Interviewer: Do you feel that the formality of a change control system is important?
Project team member: I think that formality is important, getting a balance right and a
workable change control process is as important. There are some areas on change
control that work really well on projects and there are some areas on change control that
work well on business as usual, and you need to make sure you get the balance right.
Interviewer: Do you therefore think that change control needs to be tailored differently
from projects to business support?
Project team member: I think so and depending on your project, most fully on how it is
managed on a day to day basis. Business as usual tend to have longer timescales for
getting work and changes into the production environment, where as projects have
issues that need to be undertaken and changed pretty rapidly and you need to make sure
that your change control system is robust enough to cope with both sides.
You need flexibility in the process but not the formality; you still need the sign off and
you need to make sure the correct people authorise the request to go through.
Interviewer: Do you work closely to the change control procedures?
Project team member: From a security perspective very closely, in fact over the past
year the security change control process has been tailored to meet with the system
change control process. We comply with both change control processes but both change
control processes as they are a subset of each other.
Interviewer: When an emergency arises is there another change control procedure to
follow?
Project team member: Yes, when a fast track arises you do need to follow a specific
change control process. Its basically there is extra signoff from a higher level, from the
system owner level that it is correct and business critical and that it could take down the
system and it does need to change immediately. Making sure that any other issues that
arise from a fast-track have been looked into.
81
The fast-track change control process follows the same flow but it has more detail in
and extra signoff.
Interviewer: What risk may arise if this is done or not done?
Project team member: There are problems that can arise initially where by you dont
know where your changes sit, you dont know what order in which your changes have
been done so you could take a part tested change into production, which means you will
have to do that change again.
Interviewer: How does change control affect the security and integrity of a system?
Project team member: You cant guarantee that your system is secure or that its a
correct or compliant system if you havent logged what youre doing on the system.
Interviewer: How does having different libraries affect the work that you do?
Project team member: In order that you can keep integrity on a system you need to
ensure that you undertake work in separate development areas and you also need to
make sure that your change control follows this through. You make sure that they are
unit tested in development then you move them to pre-production and make sure that
you do a full user acceptance test so the users know what they are going to see, whether
it works properly and does everything they want it to do.
System controller
Interviewer: Does having a change control system have affects on budget, if you feel it
does so, what affects does it have?
System controller: Speaking from ICON it doesnt as the business has got a direct
ownership of the process owners, theyre ultimately responsible. Therefore the change
control system doesnt have a direct impact, although thing such as the money spent is
checked at the change panel, they check to say thats a reasonable price for that kind of
work.
Interviewer: How do you control your budget then, from what is spent on changes?
System controller: Thats pretty much on the head of the business process owners, if
they have spent their budget but still need the change, the change control system will
work around that and they will have to find the money from a different area.
Interviewer: So is that assessed before it goes through a change control process?
System controller: Yes, in every case change control is after any analysis to decide if
you really need a change to take place.
Interviewer: So do you perform a cost benefit analysis?
82
System controller: We do now the system has been going for three years, I can imagine
at the start it was completely different. Because the system controllers now know their
areas and their type of change they should be having, I can say that a cost benefit
analysis is run immediately when we hear of a change.
Interviewer: What things do you consider for the cost benefit analysis?
System controller: Initially it will be informal, we will consider if it is the kind of thing
we should be looking at, how many people are impacted. If it just one person it wont be
considered, if its a lot of people we will look at if we can work around it using any
other way. Whether its system wise or change the ways of working that will be the first
thing that we will do before we consider the fact that we need a change. If the business
says we need the system to change to work with us we will put a problem log in and we
would ask for an IS review and cost estimate.
Interviewer: The project manager mentioned that he asses the soft issues for change as
well as the financial benefits, is that something you also tend to do?
System controller: We have to do everything, although we only have a fine amount of
money we also have to consider the impact on other areas of the business, it may benefit
you but not people further down the line. So you have to immediate between the
different business areas.
Interviewer: Do you think that formality of a change control system is important?
System controller: Yes it is, it helps us especially for the large changes. Because we
formalized the approval process, it makes them properly record what they want to do,
how they want to do it and how they are going to get there in the end. If we didnt have
that formal process we would get people saying we want then and the halfway down the
line changing their mind. But now its forcing them to get it right up front, properly to
consider all their options right at the start.
Interviewer: Do you think that formality of a change control system is at a right level?
System controller: I think it is spot on now. I think its taken a while for everyone to get
use to that, especially in the past having 17 different with a lot of them with just user
controls, if they wanted a change they would just do it. So its taken a long time for the
culture of the formal change control system to kick in, but now it has I think that
nobody has a problem with it.
Interviewer: How do you manage requests for changes to the system from the users?
And how do you prioritise the changes?
System controller: If somebody asked for a system change Ill try and challenge back
immediately, why do you want it? Whos impacted? Have you discussed the change
with all the areas that are impacted? Is there a non system way around this? We
challenge the changes immediately.
Interviewer: Is that to control the amount of requests for changes?
83
System controller: Yes because a lot of people initially wont have thought, it just
makes them stop and think. Very often they will say yes, we have thought of all that and
then Ill get together with them and scope out a change and get it costed. Then we will
do it again with the cost benefits. So the first time is around business ideas and then
afterwards it will be a cost and IS head on.
Interviewer: How do you then propose these changes to the project team, and how are
they prioritised in order of importance?
System controller: Thats entirely down to me, If have a change in my area I lead the
project team. A business process owner will be responsible for handling the change,
communications and handling any training being set up.
Interviewer: What are the most common requests for changes that you get for changes?
System controller: It changes the more mature the system is, at the start its people liking
old things that are no longer available any more and want a copy of the report in the
new system to match the one in the old system that was common. As you get an
intermediate system you get people saying wouldnt it be more convenient if that
worked better, little things such as tweaks to reports. At a mature stage the changes
coming through are far more justified, because people are far more use to the system. Its
taken three years though to get people use to a regulated system, but people now know
if they just asked for a tweak they get told to go away. Now you get people with
genuine problems, either something isnt working correctly or they notice the system
could help them out in a better way. So now were getting less change, more varied but
far more justifiable changes. Now we have to reject so much less at an early stage.
Interviewer: what do you consider for prioritising changes?
System controller: Anything of low priority will be something necessary but something
of low impact of number of people. Something of high priority would be a problem,
something that is not working or some data that is corrupted. Traditionally those are
fast-tracked into the systems as soon a possible, which goes against the grain of change
control because your undoing all of those principles of sitting down and thinking about
the problem, we try to avoid that at all costs. We try to follow the same change control
system with everything, so we try to get it the next available change. I try not to look at
them any differently, to give the business time to think about the problem.
Interviewer: Would a different process be followed for a fast-track?
System controller: No! No! The actual process of change control is fixed and we would
follow it. But it is all the soft side, thinking about the change, what you really and
impacts on other areas, that goes out of the window. Therefore fast-tracks are avoided at
all costs, I will try to get it implemented in the earliest available work package I
wouldnt try to get it to contravene with the change control principles.
Interviewer: What involvement do you have with the testing of a change?
System controller: Im responsible for getting the change done correctly, very often it
will be the initial business users who requested the change to test the problem. One
84
good thing is if they dont have time to test the change the change cant be that
important, and they are just asking for something they dont really need. Ill get them to
commit themselves of their users to that change for testing.
Interviewer: Do you therefore feel that it is necessary that somebody from the business
does the testing?
System controller: We insist its from somebody from the business as theyre the ones
that will use the change on a daily basis. This ensures that the change looks and behaves
how the users want, and I can ensure the testing goes through the proper change control
procedure.
85

REQUEST FOR CHANGE
Automated system:
Change no:
Plant:
Date:
Location:
Telephone no:
Originator:
Proposed change:
Reason for change:
Required by date:
CHANGE DISPOSITION & AUTHORIZATION
Disposition:
Authorized / Rejected*
* Delete as appropriate
Signature:
Job title:
Date:
Signature:
Job title:
Date:
Signature:
Job title:
Date:
CHANGE DETAILS
Comments: (Include either reasons for rejections, details of re-testing, Change Plan reference)
Number of Change Notes attached:
CHANGE COMPLETION AND APPROVAL
Completed signature:
Job title:
Date:
Approved by signature:
Job title:
Date:
Signature:
Job title:
Date:
86
Appendix D Change control system. (Maylor, 1999).
Project owner
And is passes to
Which, if agreed,
raises
Cost and
Benefits of
change
Notification of
change acceptance
Who assesses
To inform
Investigator(s)
Who
appoints
Change
coordinator
Who generates
New baselines
for project
Who is passed to
Gives
Go-ahead
to
Change request
Which
compromises
Who generates
Change originator
Description of
change required.
Reasons for the
change.
Its, priority
(mandatory,
essential, desirable).
The benefits of the
change.
Details of the
originator
Authorisation to
raise the change
request

Project Failure Rowlands

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Project Failure Rowlands

Încărcat de

Drepturi de autor:

Formate disponibile

i

A Study Of Change Control And How It

Submitted In Partial Fulfilment

Leeds Metropolitan University

Stephen Rowlands 2005

BSc Business Information Systems

My parents and family for their support.

Stephen Rowlands 2005

BSc Business Information Systems

Stephen Rowlands 2005

BSc Business Information Systems

Stephen Rowlands 2005

BSc Business Information Systems

1.1 Aim and Objectives

1.1.1 Discussion of the aim and objectives

1.2 Indication of the following chapters

Chapter Two: Methods

2.1 Secondary Research

2.2 Primary Research

2.2.1Ethics and considerations when conducting primary research

2.3 Limitations and critical analysis

Chapter Three: Literature Review

3.1 Project Failure

3.1.1 Reason for Project Failure

3.2 Scope Creep

3.2.1 Defining Scope Creep

3.3 Project escalation

3.3.1 Recent examples of escalation

3.4 Change control.

3.4.1 Benefits of Using a Change Control System

Chapter Four: Findings

4.1 Perceptions of Change Control

4.2 Discussion of findings

4.2.1 The structure of Pharmas change control

Chapter Five: Conclusion and Reccomendations

5.1.1 Secondary research

5.2 Reflection of the aims and objectives

Introduction and background

Appendix C, Change Request Form (GAMP4, 2002)

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

Stephen Rowlands 2005

BSc Business Information Systems

1.1 Aim and Objectives

1.1.1 Discussion of the aim and objectives

1.2 Indication of the following chapters

Stephen Rowlands 2005

BSc Business Information Systems

BSc Business Information Systems

Stephen Rowlands 2005

BSc Business Information Systems

1.1 Aim and Objectives

1.1.1 Discussion of the aim and objectives

Stephen Rowlands 2005

BSc Business Information Systems

1.2 Indication of the following chapters

Chapter 3: Literature review

Stephen Rowlands 2005

BSc Business Information Systems

Chapter 5: Conclusion and recommendations

Stephen Rowlands 2005

BSc Business Information Systems

2.1 Secondary Research

2.2 Primary Research

2.2.1Ethics and considerations when conducting primary research