Date post: | 07-Jan-2016 |
Category: |
Documents |
Upload: | nnigeltaylor |
View: | 14 times |
Download: | 0 times |
of 93
iStephen Rowlands 2005 BSc Business Information Systems
A Study Of Change Control And How ItCan Intervene In Scope Creep, ToReduce The Risk Of Project Failure
Submitted By: Stephen Rowlands
Submitted In Partial FulfilmentOf The Requirements For The Degree
BSc (Hons) Business Information Systems
Leeds Metropolitan UniversityMay 2005
This document is Copyright of the author and Leeds Metropolitan University and protectedunder UK and international law. The UK Copyright Service and Leeds Metropolitan Universityrefuses permission for this information to be reproduced for personal and educational useprovided all copies, extracts or adaptations Copyright The UK Copyright Service and LeedsMetropolitan University. Commercial publication, copying, hiring, lending and reproduction isstrictly prohibited and constitutes a breach of copyright. This document is protected by copyrightlaw.
Document Distribution Tracker: DDT-450034-EE
ii
Stephen Rowlands 2005 BSc Business Information Systems
Acknowledgements
I would like to thank the following people for their assistance and help throughout thecompletion of this study.
My initial point of contact and personal supervisor Paul Smith, for his help andguidance which enabled me to complete this project.
My case study organisation and it respective employees, who have been extremelyaccommodating and helpful in aiding me with my primary research.
My parents and family for their support.
iii
Stephen Rowlands 2005 BSc Business Information Systems
Plagerism Disclamer
I certify that all material in this individual project which is not my own work has beenidentified and properlyattributed.
Signed:
Date:..
iv
Stephen Rowlands 2005 BSc Business Information Systems
Abstract
This project focuses on IT project failure, as many IT projects are still continuing to failtoday. It will discuss the causes of project failure and particularly look at prior researchon scope creep and the escalation of commitment to a failing course of action. Thesehave been identified as two significant causes of project failure. The secondary researchwill look at how these two causes of failure may be managed, and recommend using achange control system to do this. Qualitative primary research will be gathered from acase study organisation by the use of interviews. These will look at the case studyemployees opinions and features of their change control practices. This evidence canthen be compared to the existing research, to try to satisfy the projects aim andobjectives.
vStephen Rowlands 2005 BSc Business Information Systems
Table of contents
Chapter One: Introduction
1.0 Background 2
1.1 Aim and Objectives 4
1.1.1 Discussion of the aim and objectives 4
1.2 Indication of the following chapters 5
Chapter Two: Methods
2.0 Introduction 8
2.1 Secondary Research 8
2.2 Primary Research 9
2.2.1Ethics and considerations when conducting primary research 102.2.2 Quantitative or qualtative research methods 102.2.3 Sample for primary research 12
2.3 Limitations and critical analysis 13
2.4 Conclusion 14
Chapter Three: Literature Review
3.0 Introduction 16
3.1 Project Failure 17
3.1.1 Reason for Project Failure 183.1.2 Reducing Project Failure 21
vi
Stephen Rowlands 2005 BSc Business Information Systems
3.2 Scope Creep 22
3.2.1 Defining Scope Creep 223.2.2 Why scope creep occurs 233.2.3 Understanding scope creep 233.2.4 Controlling scope creep. 243.2.5 Summary of scope creep 253.2.6 Scope creep and relations to project escalation 25
3.3 Project escalation 26
3.3.1 Recent examples of escalation 273.3.2 Reasons why Escalation happens 273.3..3 De-Escalation. 30
3.4 Change control. 34
3.4.1 Benefits of Using a Change Control System 353.4.2 Features of a Good Change Control System and best practice 36
3.5 Conclusion 39
Chapter Four: Findings
4.0 Introduction and background 42
4.1 Perceptions of Change Control 43
4.2 Discussion of findings 44
4.2.1 The structure of Pharmas change control 444.2.2 The importance of formality in a change control system 474.2.3 Deviations to change and emergency procedures 494.2.4 ERP and the need for controls 504.2.5 Soft and hard controls of a change control system 514.2.6 Change control and effects on scope creep 53
Chapter Five: Conclusion and Reccomendations
5.0 Introduction 56
vii
Stephen Rowlands 2005 BSc Business Information Systems
5.1 Evaluation 56
5.1.1 Secondary research 565.1.2 Primary research 57
5.2 Reflection of the aims and objectives 59
5.3 Conclusion 60
Bibliography 62
Appendices 67
Appendix A, Proposal 68
Introduction and background 68Aim 69Objectives 69Research Methods. 70Schedule of key tasks. 74Bibliography 75
Appendix B, Interviews 76
Appendix C, Change Request Form (GAMP4, 2002) 85
Appendix D, Change control system. (Maylor, 1999) 86
1Stephen Rowlands 2005 BSc Business Information Systems
Chapter One
Introduction
1.0 Background 2
1.1 Aim and Objectives 4
1.1.1 Discussion of the aim and objectives 4
1.2 Indication of the following chapters 5
2Stephen Rowlands 2005 BSc Business Information Systems
Introduction
1.0 Background
Due to the fast pace of changing technology in todays world, many organisations find
themselves at a stage where they may have to introduce, update and sometimes replace
their existing IT / IS (information technology / information systems), to maintain their
status and continue to be effective in todays competitive business environment.
The existence of an organisation crucially depends on the effective applicationof information Technology (IT). With the emergence of e-commerce, the use oftechnology is becoming just an accepted, indeed expected, way of conductingbusiness. Consequently organisations are increasingly looking towards theapplication of technology not only to underpin existing business operations butalso to create new opportunities that provide them with a source of competitiveadvantage. (Ward and Peppard 2002 p.1).
Due to this, companies will find themselves at a stage where they have to manage an IT
project to successfully implement a new system, or make changes to an existing system.
Therefore, you would expect large companies to manage their IT projects and
implement their IT systems effectively. However many of these projects are still
continuing to fail and enduring the worst failure rate of any industry, costing far more
than agreed (Watton, 2003). There are many reasons why IT projects are continuing to
fail, but it appears that projects running over budget, over schedule, and increasing
project scope are some of the major reasons of project failure (Hallows 1998 and Holt
2003).
This study will look at the area of project failure and how scope changes described by
Hallows (1998) and Holt (2003), contribute to the high failure rate of IT projects. This
3Stephen Rowlands 2005 BSc Business Information Systems
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.
4Stephen Rowlands 2005 BSc Business Information Systems
1.1 Aim and Objectives
Aim
To study the area of project failure, to asses why projects are still continuing to fail. It
will also look at scope creep and highlight any links that it may have to project
escalation. It will then use a case study to help understand how change control can be
used to intervene in scope creep, and therefore reduce the risk of project failure.
Objectives
1. To discuss why many IT projects continue to fail.
2. To investigate the factors of scope creep and highlight any links to project
escalation, which is a cause of project failure.
3. To analyse how change control systems can reduce project scope creep.
4. To analyse Pharmas change control process in relation to recommended best
practices and evaluate if change control can help reduce scope creep.
1.1.1 Discussion of the aim and objectives
The aims and objectives have been structured to allow the reader to gain an
understanding of the topic of project failure, and then focus on a cause of project failure
called scope creep. It will discuss what links scope creep has to other areas of project
failure, such as project escalation. Upon the understanding of how scope creep occurs
and ways in which it can be reduced, the final objective is to consider change control as
a method for controlling scope creep, to reduce the risk of project failure.
5Stephen Rowlands 2005 BSc Business Information Systems
Objectives one to three are unchanged from the individual project proposal in appendix
A. However objective four has changed slightly from the original proposal. Objective
four initially proposed that the study would evaluate the effectiveness of Pharmas
change control system in relation to project scope creep, and it would also highlight any
other benefits of using a change control system. Therefore, it was decided that a
framework would be needed to evaluate the effectiveness of Pharmas change control
system. As the researcher doesnt have any experience or knowledge of any known
frameworks to do this, the objective was too complex for the researcher to undertake
and therefore the objective had to be tailored to best suit the individual project. It was
decided that the researcher would look at authors recommended best practices of change
control, and analyse Pharmas change control processes in relation to these
recommendations. Following this the researcher would also evaluate if Pharmas change
control helped reduce scope creep.
1.2 Indication of the following chapters
Chapter 2: Methodology
This chapter looks at how both the primary and secondary research was conducted. It
also highlights the limitations and complexities that was found during the research
phase of this study.
Chapter 3: Literature review
This chapter discusses the secondary research findings.
6Stephen Rowlands 2005 BSc Business Information Systems
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.
7Stephen Rowlands 2005 BSc Business Information Systems
Chapter Two
Methodology
2.0 Introduction 8
2.1 Secondary Research 8
2.2 Primary Research 9
2.2.1Ethics and considerations when conducting primary research 102.2.2 Quantitative or qualtative research methods 102.2.3 Sample for primary research 12
2.3 Limitations and critical analysis 13
2.4 Conclusion 14
8Stephen Rowlands 2005 BSc Business Information Systems
Methodology
2.0 Introduction
This section describes the research methods that have been conducted to achieve the
projects individual objectives.
The research was from both primary and secondary sources. The findings from these
were cross checked and compared to achieve the aims and objectives of this project.
This multi method approach is known as triangulation, and is used to produce a full
and balanced study (Bell, 1999).
2.1 Secondary Research
A literature review was carried out, in order to provide secondary research for the
project. This was done to gain a greater understanding and familiarity of the research
topic. Also to gain an insight of the previous research that has been carried out in the
topic area, also to help plan the primary data collection (Hart, 2001). The secondary
information was collected from the Leeds Metropolitan University learning centre and
from the British library. The sources used for this was books, as there was a great
amount of material on effective project management. A disadvantage of using these
texts is that many may be dated. Also, due to IT being a fast changing industry, some of
these texts may be out of date and irrelevant in relation to todays business environment.
To compensate for this, literature from current journals was also examined. These
included case studies of organisations that have encountered project failure. These were
used to back up any claims the older literature made. All of the sources used to conduct
9Stephen Rowlands 2005 BSc Business Information Systems
the literature review were personally evaluated in regards to its respectability and
reliability. This was to ensure that a quality literature review was produced.
By completing a literature review the first three objectives had been met. It highlighted
the issues that should be taken into account for when the primary research was
conducted (Bell, 1999).
2.2 Primary Research
As objective four was focusing on a real-life situation, a case study was used to fulfil
the objectives requirements. Yin (1993), describes a case study as looking at a real life
program whose complexity can not be captured by surveying, and that a case study is
used illuminate how, and why things take place. The type of case study that will be used
is known as an individual case study which focuss on antecedents, contextual factors,
perceptions and attitudes. This is used to explore processes and experiences (Robson,
2002). This method will be used as the researcher is trying to understand the case
studies change control processes and the users experience of those process. It must be
recognised that this case study will not be holistic (represent a global level) as it is only
focusing on one organisation (Yin, 1994).
The researcher is familiar with the company that was used for the case study. He has
contacts within the company, due to completing a years work placement there. Due to
this, a more open and reliable response would be obtained from the research, as trust
had been built up with the company in the past (Bell, 1999).
10
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
questionnaire would have been non-effective in receiving a qualitative response. The
researcher had chosen to interview to show a willingness and commitment to the
company. This enabled him to utilise his relationship with the organisation. This was
done as it was believed that a richer response would be obtained, as the interviewer was
present when the questions were asked.
2.2.3 Sample for primary research
The sample interviewees were chosen in relation to their expertise of the research topic,
as they all extensively interacted with Pharmas change control system. Change control
is a very specialised area and many people do not understand its full scope or purpose.
Therefore there were only a limited number of candidates available for interview. The
following describes why each interviewee was chosen for the primary research.
Change control manager: Due to their extensive knowledge of Pharmas
change control processes. They understand the importance of having a change
control system in place. The change control team manager must ensure that the
change control system is working correctly to comply with the Food and Drug
Administration (FDA), who authorises Pharma to sell its products.
Project manager: Responsible for the running of selected IT projects within
Pharma and depends on the change control system to place controls upon the
project.
System controller: This person relies on the change control system to enable
changes that the users may request, to be made to the current system. The
system controller requires a successful change control system to ensure the daily
running of the business activities, and is responsible for the testing of any
change made to the system.
13
Stephen Rowlands 2005 BSc Business Information Systems
Security project team member: They rely on the change control system to
ensure that all their changes are successfully tested, ensuring the integrity of the
system is kept. They also must work with the change control system in their
daily working activities.
These people were interviewed on the same day, using the same interview method. One
to one semi structured interviews with open ended questions. This was to ensure that
there was consistency and integrity between the interviews (Bell, 1999). The questions
were also constructed in such a way that would allow the correlation and comparison of
answers between each interviewee, to contrast each of the interviewees views.
2.3 Limitations and critical analysis
A data triangulation method was used in order to gain confirmation of the findings
(Denzin, 1970) and to provide completeness (Jick, 1983). This was also used to reduce
bias and improve validity (Denzin, 1989). However, Fielding and Fielding (1986) have
challenged this view of data triangulation, arguing that it only allows a fuller picture of
the problem, by gaining depth and understanding but does not offer a greater accuracy.
The researcher still felt that by using a triangulation method, the findings would be
strengthened. It was therefore felt more beneficial to use this method, than not to.
As the researcher had his own experiences and observations from his experiences
working at Pharma, the researchers views and interpretations may have been biased
from his experiences (Bell, 1999). The researcher was aware of this and worked to
prevent any bias that may have existed, from entering the study.
14
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
Chapter Three
Literature Review
3.0 Introduction 16
3.1 Project Failure 17
3.1.1 Reason for Project Failure 183.1.2 Reducing Project Failure 21
3.2 Scope Creep 22
3.2.1 Defining Scope Creep 223.2.2 Why scope creep occurs 233.2.3 Understanding scope creep 233.2.4 Controlling scope creep. 243.2.5 Summary of scope creep 253.2.6 Scope creep and relations to project escalation 25
3.3 Project escalation 26
3.3.1 Recent examples of escalation 273.3.2 Reasons why Escalation happens 273.3..3 De-Escalation. 30
3.4 Change control. 34
3.4.1 Benefits of Using a Change Control System 353.4.2 Features of a Good Change Control System and best practice 36
3.5 Conclusion 39
16
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
3.1 Project Failure
This section of the review will look at the causes of project failure, and discuss why
many IT projects are continuing to fail. This will complete objective one of the
individual project.
The investments made by many companies in Information Technology (IT) and
Information Systems (IS) are continuing to increase. These investments are without
doubt the most significant that many companies and organisations make today (Cule,
2000). According to the research company Optima Media, these investments now
amount to more than half of most large companies annual capital expenditure (EIU
Business Europe, 2003). Many of these projects are still continuing to fail today (Cule
2000, EIU Business Europe 2003). These projects dont meet their requirements and are
often late and over budget, resulting in low user satisfaction, cancellation or
abandonment of the project (Cule, 2000).
An example of project failure is that of the Taurus project. The Taurus project was a
London stock exchange, stock trading settlement system project. This was cancelled in
1993, after ten years. The project was estimated to cost six million pounds but ended up
costing over 400 million pounds. Other examples include, Prudential Europes Internet
marketing system project called Unite. This project was estimated to cost around fifty
million pounds. However, it was cancelled after three years at a cost of one billion
pounds (EIU Business Europe, 2003).
IS project failure is not a new problem. It has existed since information systemsmoved beyond simple automation. (Cule, 2000 p.65)
18
Stephen Rowlands 2005 BSc Business Information Systems
There are many different figures and statistics why IT/ IS projects fail. These projects
may not be delivered on time, be over budget, cancelled or abandoned. Most of these
figures and statistics show that at least 50% of projects are seen to be a failure (Cule
2000, Biggs 2000, EIU Business Europe 2003). Bennett (2003) argues that failure rates
havent gone up, just that it is more expensive when projects do fail. Which seems a
valid point, as IT forecasts show that IT budgets are continuing to increase each year
(Albright, 2003).
3.1.1 Reason for Project Failure
According to recent research among European companies, businesses are stillmaking expensive but avoidable mistakes when it comes to key IT projects.(EIU Business Europe, 2003 p.1)
The EIU Business Europe (2003) comments that despite the vast research done on IT
project failure, there is still disagreement on the main causes of failure. It warns that
much of the research is subject to bias, especially in surveys, as people believe that
responsibility lies outside of their control. However, there is a wide spread belief that
management is responsible for project failure rather than technology. Some of these
reasons for project failure are discussed in terms of the following.
Poor management of projects, as discussed by EIU Business Europe (2003) is one of the
major causes of project failure. It needs to be recognised that poor project management
is a major cause of failure. It is a contributing factor in its own right, but may also lead
to other causes of project failure. An example of this is if there is no proper ownership
of the problem within management, this can lead to project failure. A senior company
officer must take ownership of the problem and therefore should take responsibility for
19
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
business is not able to challenge the supplier. This could also be a result of continuous
changing technology or if the project team is lacking in the skills of IT procurement or
project capabilities. This may occur if a finance director is in charge of the IT
department (Bywell, 2003). Related to is a lack of resource allocation, or commitment
from the management towards the project. This is where the amount of resources
assigned to a project is not enough or in shortage. This is most likely to be a result of
poor project planning or just that the project has gone out of control. Biggs (2000)
indicates that you need to evaluate what resources you need for your project, and if you
need more, get external help. If the project is important enough then the budget should
allow enough allocation of talent to complete the project or a trade off may have to be
made to ensure the completion of the project.
Scope creep is described by Murray (2000) as a cause of failure. Murray points out that
scope creep needs to be managed, as it is a common occurrence in many IT Projects.
Scope creep is where the project size and complexity is allowed to expand as the project
moves forward. Bywell (2003) sees scope creep as a common contribution to project
failure.
3.1.2 Reducing Project Failure
Failure is a real risk to most projects. Managers must be aware of the causes and work
to reduce the risks. There are many articles on how to run a successful project, such as
Biggs (2000) 12 golden rules of project management success. To ensure a successful
project, all that needs to be done is to identify the risks of the project, then work to
control and manage those risks effectively (Cule, 2000).
22
Stephen Rowlands 2005 BSc Business Information Systems
As well as the common practices to achieving project success, other authors suggest
alternative methods such as Murray (2000). Murray suggests that instead of managing
the risks, you should in fact reduce the complexity of your project, to make it as simple
as possible. He takes into account that different companies are effectively capable of
handling different size projects. Therefore, the size and amount of complexity that a
project needs to be reduced to will depend on the characteristics of the individual
company. His theory is that if you reduce the complexity of the project then the risk
areas will be removed, rather than managed. This is where scope creep can be an
effecting factor. If it is tolerated, then the projects size increases and additional
complexity is added to the project. Although Murrays (2000) method may be valid, it
doesnt take into account that some projects need to be complex, and many projects
often are.
3.2 Scope Creep
In the previous section of this review some of the causes of project failure were
discussed. In the next section, the researcher will investigate scope creep, as it was one
of the contributing factors of project failure, indicated by Ulfelder (2004). Thus
satisfying part of the individual projects second objective.
Like a malignant cancer, 'scope creep' is one of the most significantcontributors to project failure. (Business Line, 2001, p 4)
3.2.1 Defining Scope Creep
Scope creep occurs during a projects development lifecycle and often occurs in IT
projects. Comerford (2000) and Adshead (2003) indicate that enterprise resource
23
Stephen Rowlands 2005 BSc Business Information Systems
planning (ERP) packages are prone to scope creep. It happens when new features and
functions are added during the development lifecycle. This can result in projects being
over budget and prone to run over their deadlines. This often puts them out of line to
their original business requirements. All this costs money and time, and can seriously
consume projects resources. Therefore affecting your projects chances of success (
Zimmerman 2000, Liebmann 2001). It is important to also distinguish between scope
creep and requirements creep. Scope creep is where additional functionality is not
planned for within the budget of the project. Requirements creep is where the additional
functionality is planned and the budget has to accommodate for these changes.
3.2.2 Why scope creep occurs
Scope creep is a very common occurrence, and is present in almost every project. In an
article by Schulz (1999) he describes how he had a home micro-project, swapping
around two computers in his basement. This project went $17 over his estimated budget,
and lasted three and a quarter times his original estimated time. This example may seem
trivial, but it stands to show that even the smallest project can be affected by scope
creep. Keeping this in mind, scope creep is simply amplified by the size of a project.
Vowler (2003) argues that so many government projects go wrong due to their size.
This results in the amplification of scope creep, causing projects to overrun and change
specification. Vowler (2003) argues that if these projects were broken up into smaller
ones it would reduce the effect of scope creep.
3.2.3 Understanding scope creep
Project teams are often bombarded with requests to add new requirements. Zimmerman
(2000) categorises these requests into two types, the first being new requirements, the
24
Stephen Rowlands 2005 BSc Business Information Systems
second being modifications of existing requirements. He explains how each of these
requirements must be analysed and goes through design and implementation. This
results in the requirements taking up time effort and precious resources. Liebmann
(2001) highlights how these consequences of scope creep can put a project team under
pressure, as they will be receiving these requests and will want to deliver their best to
the business. Unfortunately they are restricted by a budget and time constraints and
cannot afford to stretch these to any unnecessary new requirements or enhancements.
It must be acknowledged that some of these new requirements or modifications may be
essential to the projects success. As mentioned earlier, the business requirements often
change during the different project stages. This must be monitored or the project may
fall out of step with the business activities or requirements. We must understand that
scope creep is where the additional requirements dont benefit the projects objectives
(Liebmann, 2000). Liebmann (2000) summarises factors of scope creep as follows.
Additional features that dont fit the business drivers.
Features that add a low cost benefit ratio.
Features that overstretch the business allocated resources.
Features that add risk.
3.2.4 Controlling scope creep.
Now we understand what scope creep is, we must recognise that it needs to be
controlled, not prevented as previously mentioned. This is because some added
requirements are necessary during a project lifecycle. Zimmerman (2000) indicates that
communication is the key to solving this problem. A formal request for changes process
should be set up as each change needs signing off by both the project team and
customer. He recommends introducing a change request process where all requests
25
Stephen Rowlands 2005 BSc Business Information Systems
would be viewed by a panel consisting off the project manager (in part 2.1 it is
recommended that somebody has overall responsibility for the project, this is the project
manager), technical lead and customer to approve or disapprove the request. This is
formally known as a change panel who will deal with each request in the same way,
allowing for a benefit-to-cost ratio to be carried out on every change request. As
Liebmann (2000) has described, only things that benefit the project are allowed to
proceed, therefore eliminating scope creep. This way of controlling scope creep by
ensuring all change requests go through a change control process will be analysed later
on in this literature review.
3.2.5 Summary of scope creep
In this section we have looked at scope creep. We have seen how it can be present in
many different sized projects, and realised that the bigger the project the greater scope
creep is amplified. We now know that scope creep relates to additional requirements
that do not benefit the business and differentiate between the requirements that may
arise in changes from within the business strategy changing, or the additional
requirements that benefit the business. Due to scope creep being a major contributing
factor of project failure it must be controlled. We have considered using change control
to restrict scope creep as recommended by Liebmann (2000).
3.2.6 Scope creep and relations to Project Escalation
We have looked at scope creep and defined it as being where additional requirements
that are added during the projects design or implementation phase, that dont benefit the
business requirements. If not controlled it may lead to runaway projects. There is also
another factor that may lead to runaway projects, called project escalation. Scope creep
26
Stephen Rowlands 2005 BSc Business Information Systems
can sometimes be an indication of project escalation. Even though one may assume that
scope creep and project escalation are similar things, they are in fact two very different
things. They have a similar outcome, being out of control projects which can lead to
project failure.
This next section will satisfy the second part of objective two as it looks at projects
escalation and discusses any links it may have to scope creep.
3.3 Project Escalation
There is limited research on the escalation theory. Most of the previous research that has
been carried out focuses on individual cognitive decision making in relation to project
escalation. This has left a need for research to be carried out at an organisational level.
There is also more limited research that has been carried out on de-escalation of
commitment to a failing project (reducing and controlling escalation) (Keil and Mixon
1995).
Escalation refers to the following.
Escalation of commitment to an ineffective course of action (Brockner andHouser 1986 p1).
The term escalation is often used by many authors and refers to committing resources
to, and supporting failing projects when termination or redirection of the project would
be a more suitable course of action. (Drummond 2000, Sharp and Slater 1997, Keil
1999). Project escalation is not an uncommon phenomenon. Keil and Mann (1997)
conducted a survey of several hundred information systems auditors. Through their
survey, they found that one or more out of five projects had encountered project
27
Stephen Rowlands 2005 BSc Business Information Systems
escalation. This concluded in a summary that escalation occurs in 30-40 percent of all
IS projects (Keil and Robey, 1999).
3.3.1 Recent examples of escalation
1. The Taurus project was a London stock exchange stock trading settlement
system project. This was cancelled in 1993 of after ten years. The project was
estimated to cost 6 million pounds, receiving over 80 million in its first three
years, and ended up costing over 400 million pounds. (Keil and Robey, 1999)
2. Prudential Europes Internet marketing system project called Unite, was
estimated to cost 50 million pounds. It was cancelled after three years at a cost
of 1 billion pounds. (EIU Business Europe, 2003)
3. CONFIG, an expert system designed by the company CompuSys. This project
started out with lack of sponsorship and unrealistic time lines and goals, and
therefore experienced difficulties from the outset. As a result, it led to rejection
by the companies sales representatives. This led to a long effort in trying to
adapt the system so that it would be accepted. This used up valuable resources
even though the project was classed as a failure (Keil, 1995).
3.3.2 Reasons why Escalation happens
This next section will look at reasons why companies continue to commit to a failing
project rather than abandoning it, abandoning it too late or turning them round.
Keil (1995) and Staw and Ross (1987) agree that the causes of project escalation can be
grouped into four different categories being, project factors, psychological factors,
social factors, and organizational factors. Following are some theories why people
escalate to failing courses of action.
28
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
whether a troubled project ultimately succeeds or fails depends on theeffectiveness of managerial actions taken to turn around or redirect suchprojects (Keil and Robey 1999. p.63)
In his study on escalation and knowing when to pull the plug on troubled software
projects, Staw and Ross (1987) highlight that managers need to initially recognise they
are a cause of escalation of commitment to troubled projects. They can often have a bias
to the project with the attitude that any problems will resolve themselves and assume
the projects will pull through. He concludes that this may be due to the fact that in large
bureaucratic organisation it is initially very hard to get the go ahead to start a project in
the first place. Staw and Ross (1987) say that project managers need to ask themselves a
set of preset questions, if a manager answers yes to one or more of these questions then
they may be over-committing to a project.
Once it is recognised that a project or failing project is subject to escalation of
commitment, action needs to be taken to reduce the escalation. Keil and Robey (1999)
describe this action as de-escalation. Staw and Ross (1987) recommend that the first
action should be to take a fresh view of the project which can be done by setting up
decision circles. Decision circles are made up of key members of staff that should
periodically evaluate the projects status. This action is also backed up by Keil and
Robey (1999) who says that regular evaluation of the projects progress can lead de-
escalation. This initial action may have an effect on Sharp and Slaters (1997) theory on
sunk cost, by taking a fresh view on the project all previous sunk costs are ignored as
Whyte (1993) pointed out that they should not affect future decisions.
Staw and Rosss (1987) second recommendation is that the organisation needs to
realise that it can be a contributor to escalation. If this is the case, they need to look at
32
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
3.4 Change control.
This section will look at how change control systems work and how they may help
reduce scope creep, in order to complete objective three of the individual project
objectives, and set a grounding of knowledge which will help complete the forth
objective.
All custom developed software projects such as an ERP software needs changes to them
or additional requirements to be added. This may be due to bugs, errors, new
requirements, changing requirements, or due to the client or environment changes,
future versions of the software (Field & Keller 1998, Lamond 2002). As we have
previously established if these additional requirements are not controlled, they can lead
to factors such as scope creep which can result in runaway projects (Bocij et al 1999,
Stedman 1999). If the controls are not tight enough it may allow escalation to happen,
which should be controlled by limiting the number of resources available to the project
(Keil and Robey1999). To control these changes they need to be managed by ensuring
that all requests for changes are recorded and evaluated so the numbers of requests dont
become unmanageable. This is done by using a process known as change control, it is
also known as change management or scope management. In this study it will be
referred to the process of change control (Bocij et al, 1999 Field Keller 1998, Lamond
2002, Hallows 1998, Wateridge 1999).
All projects are subject to scope changes at some time during their life cycle.The scope change control system or configuration management is a systemdesigned to effectively manage the change of scope. (Burke, 2003, p105).
35
Stephen Rowlands 2005 BSc Business Information Systems
3.4.1 Benefits of Using a Change Control System
Burke (2003) describes change control as a framework to monitor, evaluate and approve
changes to make sure that the integrity of the system is maintained. Change control
allows a means for proposing change to a system (Field and Keller 1988, Halows 1998).
It also ensures that a projects baseline plan of scope, schedule, and cost and resource
allocation is maintained by the use of change control as it allows any changes to be
monitored and compensated for (Edward and Douglas, 2000).
Managers need to devise a strategy for change and employ change managementas a way of controlling any changes (Wateridge, 1999. p238)
Hallows (1998) states that an escalation path should be designed in which certain
problems should be escalated to certain people, Bocij et al (1999) state that an
escalation path ensures that the problem is sent to the person that is responsible for
fixing it, who resultantly may raise a request for a change. These proposed changes
should be prioritised by the requestor of their importance with a high, medium and low
importance assigned to them (Maylor 1999, Bocij et al 1999), high priority is usually
system critical, with Burke (2003) stating that there should be automatic approval in
place for emergencies. This may go against the purpose of a change control system as it
is there to allow the valuation of change to ensure system integrity, it would be assumed
that all requests for change are evaluated no matter how important. A change request
system also allows a cost benefit and impact analysis to be done on each request taking
into account cost and time constraints on a project (Maylor 1999, Field and Keller 1998,
Moreton, 1990). This is where change control can have an effect on controlling scope
creep as the numbers of changes are carefully controlled. Burke (2003) sees change
control as a tool for controlling scope overall other uses. Change control can be also
36
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
make the changes in, and another to test the changes, and a third which is the live
system that the client will use. This ensures that system integrity is kept, and there are
no changes directly in the live system. An example of using these different libraries is
used by the ERP software SAP which explains how there are different libraries (clients)
within the system, one to develop the program, another to test and finally a live system
(SAP labs inc., 1999). Once the changes have been completed it is formally tested in the
test library usually by somebody outside the project department such as quality control
or people from the business. Wateridge (1999) argues that people from the business
need to complete the testing to ensure that the project achieves their expected
outcomes.. Due to the fact that only changes were allowed in the development library,
the tested versions in the tested library are the changes which will go into the live
library. This will ensure that the version control remains intact. Once the testing is
complete, the change is then approved to move into the live production library. This is
recorded on the change request (Lamond, 2002). The only deviation that may occur to
the change control process is that of if an emergency arises. This may be a change
request that has come in as high priority. Burke (2003) states that there should be a
procedure to allow stating automatic approval in place for emergencies, this may leave
the change control process open to abuse and allow unmonitored changers to be made to
the production system. Lamonds (2002) views are different to Burkes (2003), he says
that if there is an emergency and you need to get changes into the production system to
keep it running smoothly then change control still applies to emergency fixes.
The objectives of a program change control still apply to emergency fixes, buttemporary compromises may be necessary (Lamond, 2002 p.27).
39
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
Chapter Four
Findings
4.0 Introduction and background 42
4.1 Perceptions of Change Control 43
4.2 Discussion of findings 44
4.2.1 The structure of Pharmas change control 444.2.2 The importance of formality in a change control system 474.2.3 Deviations to change and emergency procedures 494.2.4 ERP and the need for controls 504.2.5 Soft and hard controls of a change control system 514.2.6 Change control and effects on scope creep 53
42
Stephen Rowlands 2005 BSc Business Information Systems
Findings
4.0 Introduction and background
This chapter aims to complete objective four by looking at the primary research and
picking up on the key themes and opinions that was raised by it. Where possible it
relates these back to the literature previously reviewed. The primary research consisted
of a set of tailored questionnaires for each interviewee, as described in the methodology.
These interviews focused on the opinions of Pharmas employees on their change control
system. The findings from the primary research can be seen in appendix (B), typed in a
transcript format. These findings will then be discussed and compared to the findings
from the secondary research, and draw on the key issues raised.
Pharmas change control system appeared to be a standard change control system, and
contained all the features that you would expect of a change control system, as
described by authors in the literature review. Pharma is a global pharmaceutical
company currently employing over 58,000 people worldwide, and over 10,000 people
in the UK. It has major production, sales and marketing sites within the UK, which
despatch to customers within the UK and to over 100 export markets. The systems used
by these sites are mainly made up of SAP systems.
These SAP systems require a change control system to ensure their successful daily
running, or to keep control of any project work that concerns the systems. This change
43
Stephen Rowlands 2005 BSc Business Information Systems
control systems is also used to bridge across other applications, such as Pharmas HR
system and drug trial systems, thus indicating how important it was that Pharma has an
effective change control system. Pharma has always had a form of change control as
their systems are regulated by the Food and Drug Administration (FDA). All
pharmaceutical companies must comply with this to be able to sell their products. Their
change control system started off as a paper based system, and as errors were made and
issues were raised it developed into a Microsoft Access database. This has matured into
a very complex Microsoft Access database. Pharmas change control system now stands
on a sequel server and is hoping to progress into an ERES (Electronic records electronic
signature) compliment system. Pharmas change control system is growing and changing
all the time, as Pharmas change control manager states that if it sits still they must be
failing somewhere.
4.1 Perceptions of Change Control
Change control affects people in different ways. This is due to people interact with the
change control system in different ways, depending upon their job role. Therefore it
appeared that the aspects and uses of change control were perceived slightly differently
between each of the interviewees. This had to be initially recognised before the findings
were looked at. For example the change control manager seemed to perceive change
control as a way to comply with the FDA and to ensure the changes taking place were
controlled in respect to configuration management and testing requirements. Also
ensuring the changes made to the system had been approved. The project manager saw
change control as a control mechanism to control lower level changes to the system.
Due to the need to comply with the FDA it meant that the IS, quality assurance and a
business representatives needed to sign changes off to approve them. This ensured a
44
Stephen Rowlands 2005 BSc Business Information Systems
greater effectiveness with the control of scope creep. The system controller viewed
change control as means to ensure that any requests for change were thoroughly
considered in relation to their business impact and cost benefit, before the requests
formally interact with the change control system. It would seem that change control is
used as almost a deterrent to users considering making change request, which ensured
that only the important changes are put forward. Ensuring that these changes were
carefully thought about, forcing the users to get the change right at the start. The system
controller also saw the change request system as a way to ensure that testing was
completed to a user satisfactory standard. This would ensure that the user was happy
with the end product. The project team member saw change control as a process to give
them confidence, the work they are putting into live production system was error free,
and that the systems integrity and security was therefore maintained. Even though
peoples perceptions of the uses of change control slightly differed there was a common
understanding that there was a need for a change control procedure for any project or
live system.
4.2 Discussion of findings
4.2.1 The structure of Pharmas change control
Pharmas change control system contained the standard features that authors had defined.
These features were described by Pharmas change control manager. They included
features such as having an escalation path, a formal request process by raising a
problem log which will have estimates put upon it. This will then go to a change panel
which consists of a quality assurance member, SAP architect and business process
owner. They decide if the change can be approved, upon which the problem log is
45
Stephen Rowlands 2005 BSc Business Information Systems
changed into a change request. The change request is then assigned to a work package
which is classed as release management, then work is completed. This then follows the
V model for testing, using libraries as described by Lamond (2002). The final change is
signed off by COMVAL (computer validation) and QA (quality assurance) before the
change can go into the live production system.
In the interviews, some of the interviewees were questioned about the use of libraries, as
the researcher was interested to see how important Lamonds (2002) recommendation
was in respect to how necessary it is to have different libraries when using a change
control system. This also seemed appropriate as Pharmas SAP systems make use of this
library functionality. The change control managers response was that the use of libraries
was important. It allowed the management of risk within the system and it allowed a
separate place for the user to train in, also a separate place for production and testing,
which should be a minimum requirement in any system that is properly managed. She
stated that the key thing is that any reasonable system should have landscapes, with a
size and complexity relevant to the system.
It allows you to maintain control of your system (Pharmas Change controlmanager)
The project team member also agreed that the use of libraries was important, stating that
that it ensured that things were tested properly. Which meant that the user was happy, as
they saw during testing is what they would get in the production environment. The
importance of the user doing the testing was backed up by the system controller. He
insisted that it was the user who did the testing, as they were the one that uses the
change on a daily basis. The system controller explained how this ensured that the
change looks and behaves how the user wants. This is described by Wateridge (1999).
46
Stephen Rowlands 2005 BSc Business Information Systems
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
Stephen Rowlands 2005 BSc Business Information Systems
company needed people who could make proper decisions and have their decisions
respected.
On projects you need key representations on there, to make sure you arefocusing on what really needs doing (Pharmas Project manager).
Therefore it appeared that Pharmas approving body is a formal one and consists of
people who are perceived to have authority and experience, this is in order for any
decision made about a change to be immediately respected and accepted.
4.2.2 The importance of formality in a change control system
A point of interest that was explored was to how important the formality of a change
control system was to Pharma. The system controller explained how formality is good
with large changes, forcing them to get things right up front. The formality makes them
properly record what they want to do, and how they are going to get there in the end,
stopping users changing their minds half way through the change, which ensured that
they considered all the options at the start. The project team member also felt that the
formality the system is important. The change control manager views Pharmas change
control system as very formal, and states that it needs to be if you are producing drugs
and their systems are validated. She states that in other systems that doesnt have a
formal change control, tend to fall over regularly, and that formality stops this.
Because we formalised the approval process, it makes them properly recordwhat they want to do, how they want to do it and how they are going to get therein the end. If we didnt have that formal process we would get people saying wewant then and the halfway down the line changing their mind (Pharmas systemcontroller).
The system controller described that before the formal change control system was
introduced, there were just user controls in place and people would just make changes
as they wanted. This would allow scope creep to thrive, as Burke (2003) explained that
48
Stephen Rowlands 2005 BSc Business Information Systems
change control is needed to control the scope of a project. As the formality of Pharmas
change control has increased significantly from the past when user controls was used.
The system controller felt that now the amount of formality was spot on, with the
culture of a formal change process now present within the company. Both the change
control manager and the project team member, felt that sometimes there was too much
formality, and getting a right balance of formality for different systems was more
important. They explained that currently the formality of the change control for live
systems support and projects sometimes conflicted and the processes needed to be more
flexible.
I think that formality is important, getting a balance right and a workablechange process is as important (Pharmas project team member)
The system controller may not have picked up on this as his work is mostly centred on
live system support as he does not work full time with projects. The change control
manager explained how Pharma is going to alter their change control system to tailor it
to a risk based approach of change management, to make it more flexible to the various
different areas it covers. If that was to happen she feels that the change control process
will be a lot slicker. This method would be a progression of Edwards and Douglas
(2000) recommendation, who recommended that that verbal authorisation is sufficient
on small projects but larger projects need a formal authorisation process.
It would appear the formality of a change control system is important to make people
follow the correct change processes and increase the chances of successful change. As
this change control system is used across multi applications and is used in both business
and project environments, it is just as important to provide flexibility within a change
control systems to accommodate for this.
49
Stephen Rowlands 2005 BSc Business Information Systems
4.2.3 Deviations to change and emergency procedures
During the literature review there was a disag