The University of Sheffield Risk Assessment of Individual ...dagda.shef.ac.uk/dispub/dissertations/2002-03/External/Hira_Ritesh... · Ritesh Hira September 2003 MSc Dissertation 1

The University of Sheffield

Risk Assessment of Individual Industrial Information System Projects: A Case Study

A Study Submitted in Partial Fulfilment of the Requirement for the Degree of Master of Science in Information Management

Ritesh Hira

September 2003

MSc Dissertation 1

Abstract

The use and development of Information Systems (IS) within organisations

has increased substantially in the last decade. At the same time so has the

failure rate of unsuccessful systems implementation. The success or failure

rate of systems developments such as Therac 25, London Ambulance Service

or the IS development conducted by large telecommunications companies

can be significantly improved. This can be achieved if organisations make use

and apply a formal Risk Management method before, during and after a

systems development. Using Risk Management techniques enables a

structured method of identifying and controlling threats to a projects success

to be achieved.

The area of risk identification is viewed as being problematic within IS

developments. This has been the case with a large telecommunications

company within the UK who undertook a large-scale systems development.

This company will be used as a case study to identify and analyse the

problems that occurred during the development of this system. The causes

that contributed to these risks occurring will be determined and analysed

together with the risks that occurred within this project that are associated with

the problems that occurred. Based on this ontology of project risks are defined

for this type of project.

The inductive approach was adopted where 4 extensive interviews were

conducted with key systems development members. The findings are

analysed using concept-mapping techniques.

The findings outlined that Quality, User Resistance, Time, Cost, Project

Failure, Staff Pressure, Staff Isolation and the Success/ Failure risks were

taken during this development. This is because requirements related

problems, limited use of project management techniques and formal

processes were not used in this systems development.

MSc Dissertation 2

Acknowledgements

I would firstly like to express my deepest gratitude to my project supervisor Dr

Miguel Baptista Nunes for his encouragement, guidance and assistance

throughout this project which gave me the confidence to complete the task.

This thesis could not have been completed without his support.

I would like to thank all my family especially my Mum, Dad, Nina, Dinisha and

Grandparents (late) for all their immense support throughout my education

which has given me great strength and determination.

I thank the almighty for the grace of making all this possible, without their

blessings this would have never been possible. To them I dedicate this work.

Thank you all

MSc Dissertation 3

List of Contents Ritesh Hira

LLiisstt ooff CCoonntteennttss

____________________________________________________________________________________________________________________

Title Page 1 Abstract 2 Acknowledgements 3 List of Contents 4 List of Figures 10 List of Tables 11 List of Charts 11

Chapter One Introduction 12

1.0 Background of Study 12

1.1 Problem Statement 13

1.2 Research Motivation 14

1.3 Objectives of the Study 15

1.4 Research Methodology 16

1.4.1 Research Instruments 16

1.4.2 Data Research Collection 17

1.4.3 Target Population 17

1.5 Dissertation Outline 17

1.5.1 Information Systems in Organisations 19

1.5.2 Failure of Information Systems Projects 19

1.5.3 Information Systems Project & Risk Management 19

1.5.4 Risk Management 20

1.5.5 Discussion of Results 20

1.5.6 Recommendations 20

1.5.7 Conclusion and Future Research 20

MSc Dissertation 4


Chapter Two Information Systems in Organisations 21 2.0 Organisations and Information Systems 21

2.1 Nature of Information Systems 23

2.2 Importance of Information Systems 24

2.3 IS Problems, Factors Affecting Success 25

2.4 IS Development Considerations 27

2.5 Organisational Forms 28

2.6 Information Use in Organisations 29

2.7 Organisations and Components of IS 31

2.8 IS Development Methodologies 32

2.8.1 Methodology Requirements 33

2.8.2 Types of IS Methodologies 35

2.9 Impact of IS within Organisations 36

Chapter Three Failure of Information Systems Projects 38

3.0 Failure of Information Systems projects 38

3.1 Reliance upon Information Systems 39

3.2 Threats to Information Systems Survival 41

3.3 Information Systems Failure 42

3.4 Forms of Information Systems Failure 43

3.5 Information Systems Developments 44

3.5.1 London Ambulance Service CAD System 46

3.5.2 Taurus London Stock Exchange System 47

3.5.3 Therac 25 48

3.5.4 The Performing Right Society PROMS 49

3.5.5 Confirm Reservation System 50

3.5.6 Swanwick Air Traffic Control System [ATCS] 51

3.6 Information Systems Development Success 52

3.7 Problem Areas in IS Development 53

3.7.1 Technical 53

3.7.2 Human 54

MSc Dissertation 5


3.7.3 Human Resource Management 55

3.7.4 Quality Assurance 55

3.7.5 Social 56

3.7.6 Business 56

3.8 Summary - Lessons to be learnt 57

Chapter Four Information Systems Project & Risk Management 59

4.1 Project Management 59

4.2 Steps of Project Management 61

4.3 Project Control Techniques 62

4.4 Project Management Methods 63

4.5 Project Feasibility 65

4.6 Human Resource Allocation and Management 65

4.7 Estimating Project Resources 66

4.8 Quality Assurance 67

4.9 Systems Specification Design 68

4.10 Development & Implementation 69

4.11 System Testing 70

4.12 Systems Review and Maintenance 70

4.13 Introduction to Risk management 71

Chapter Five Risk Management 72

5.0 Risk Management 72

5.1 Importance of Risk Management 73

5.2 Forms of Risk 73

5.3. Steps of Risk Management 76

5.3.1 Risk Identification 79

5.3.2 Risk Assessment 80

5.3.3 Risk Categorisation 81

5.3.4 Risk Control 85

5.3.5 Risk Monitoring 85

5.4 Risk and Reward 87

MSc Dissertation 6


5.5 Risk Management Frameworks 88

5.6 Organisational Levels of Risk Management 89

Chapter Six Research Methods 90 6.0 Research Methods 90

6.1 Research Strategy 90

6.1.1 Interview Strategy 93

6.1.2 Case Study Research 95

6.1.3 Information Systems Specific Research 96

6.1.4 Information Systems Research Methodologies 96

6.2 Research Method Applied 98

6.2.1 Data Collection Methods 99

6.2.2 Data Analysis Methods 100

6.3 Risk Identification Specific Frameworks 100

6.4 Limitations of the Research Method 103

Chapter Seven Analysis of Data 105

7.0 Analysis of Data 105

7.1 The Empirical Study 105

7.2 Informe Development Problems – Interview One 107

7.2.1 Development Agendas 108

7.2.2 Functional Requirements 108

7.2.3 Project Management 109

7.2.4 Organisational Issues 111

7.2.5 Systems Development 112

7.2.6 Risk Consideration 113

7.2.7 Interview Summary 114

7.3 Informe Development Problems – Interview Two 114


7.3.2 Development Plans 118


7.3.4 Systems Development 121

MSc Dissertation 7


7.3.5 Risk Consideration 122


7.4 Informe Development Problems – Interview Three 123

7.4.1 Management Support 124



7.4.4 Formal Processes 128


7.5 Informe Development Problems – Interview Four 129

7.5.1 Management Involvement 129

7.5.2 Informe Systems Implementation 131



7.5.5 Communications 134

7.5.6 Risk Assessment 135


7.6 Summary of Informe Problems 136

Chapter Eight Discussion of Results and Recommendations 138

8.0 Results and Recommendations 138

8.1 Quality 139

8.2 User Resistance 142

8.3 Time 145

8.4 Cost 151

8.5 Project Failure 153

8.6 Staff Pressure 155

8.7 Success Failure Factors 158

8.8 Staff Isolation – Low Morale 159

8.9 Summary of Recommendations 160

MSc Dissertation 8


Chapter Nine Conclusions and Future Work 161

9.0 Objectives 161

9.1 Process Summary 161

9.2 Summary of Results 162

9.3 Summary of Methods 164

9.4 Future Research 165

Glossary 166

References 168

Appendices 181

Word Count 247

MSc Dissertation 9

List of Figures Ritesh Hira

List of Figures

Figure 1 Classification of Information Systems 22

Figure 2 Components of an Information System 23

Figure 3 Impact of Information Systems within Organisations 25

Figure 4 The Information Systems Development Triad 26

Figure 5 Information use at the 3 Management Levels 30

Figure 6 Information Systems Purpose at the 3 Management Levels 31

Figure 7 Components of an IS 32

Figure 8 Investment & Dependence on Information Technology 40

Figure 9 Performance, Cost, and Time Project Targets 61

Figure 10 Project Management Process 62

Figure 11 IT Risk Management Framework 77

Figure 12 Risk Management Framework 79

Figure 13 Risk Monitoring Process 86

Figure 14 Risk Identification and Assessment Framework 91

MSc Dissertation 10

List of Tables and Charts Ritesh Hira

List of Tables

Table 1 Risk factors Effecting Commercial and MIS Projects 75

Table 2 Risk Identification within the Three Level IT Environments 78

Table 3 Three Broad Styles of Research 97

Table 4 Taxonomy of Research Approaches 97

List of Charts

Chart 1 Concept Map of Interview One Project Risks 107

Chart 2 Concept Map of Interview Two Project Risks 115

Chart 3 Concept Map of Interview Three Project Risks 124

Chart 4 Concept Map of Interview Four Project Risks 130

Chart 5 Global Informe Project Problems, Events and Risks 246

Chart 6 Risk Map: Quality Problems and Events 139

Chart 7 Risk Map: User Resistance Problems and Events 142

Chart 8 Risk Map: Time Problems and Events 146

Chart 9 Risk Map: Cost Problems and Events 152

Chart 10 Risk Map: Project Failure Problems and Events 153

Chart 11 Risk Map: Staff pressure Problems and Events 157

Chart 12 Risk Map: Success or Failure Problems and Events 158

Chart 13 Risk Map: Staff Isolation Problems and Events 159

MSc Dissertation 11

Chapter One: Introduction Ritesh Hira

CChhaapptteerr OOnnee IInnttrroodduuccttiioonn ________________________________________________________________________________________________________________

1.0 Background of Study

Organisations that have adopted the use of a formal risk management method

will improve the success rate of their Information Systems (IS) project

developments. The advantages of having such measures in place will allow for

a structured method of identifying and controlling threats to a project’s success

to be achieved (Nunes and Annansingh, 2002).

If an organisation does not have a formal risk management approach in place

then it may not be possible to identify potential risks in a timely and efficient

manner, completed as planned or prove to be effective (University of Sheffield,

2001). Ultimately risk management should be used by companies who are

undertaking IS development so that unforeseen problems can be avoided late

in the project, improving the success rate of meeting project goals and

commitments on time.

Risk management all but starts with identifying the potential risks associated

with a given project, this is done by making a list of risks and detailing their

potential impact upon the project (Baker, 2000). Baker (2000) suggests the

best method in order to identify risks is to ‘learn from past projects, the

failures of past projects will be a good source of risk control information’.

Looking at the critical relationships or resources in the project can further

identify risks and assessing what could occur if these factors change (Baker,

2000).

Once the risks, which may affect the project, are outlined an assessment of

the probability of its potential impact should be undertaken. Baker (2000)

defines one method which can be used to analyse risk probability, to do this

MSc Dissertation

12


a number should be assigned to each risk on a scale of 1 for the lowest

probability to 10, which indicates highest probability or impact. This is the first

part of the assessment, following this; multiplying the probability number by

the impact number assesses the severity or importance of each risk. This

calculation will define the severity measure as to which risks should be

considered for further analysis. In most circumstances a risk threshold with a

risk severity of 40 or more will distinguish the important risks which need to

be investigated further, from the risks which are of little threat to the project

(Baker, 2000).

1.1 Problem Statement

Section 1.0 discusses the importance of risk management during the

management and successful delivery of a given project (Redmill, 1991).

Many organisations use a formalised process which teams have to follow in

order to create development projects (Frosdick, 1997). One such process

that may be followed during the management of systems development is risk

management, which involves following a risk management cycle of risk

identification, risk analysis, risk control and risk reporting (Olson, 2001).

Together with following the four steps of risk management the probability,

frequency, impact and importance and exposure are necessary factors in

analysing the potential risks in a project (Kliem & Ludin, 1997).

Even if the steps discussed are carried out it is not possible to identify all

possible risks that occur in the project as some may occur as the project

develops and therefore cannot be anticipated during the early stages of risk

analysis (Sherer, 1997. Although with continuous iterations of the risk life

cycle risks can be identified and managed as development progress reducing

any major problems that could result in the project failing or its development

being hindered (Sherer, 1997.

A consequence of IS developments failing is due to the lack of risk

management being conducted during the development of a system.

MSc Dissertation

13


Therefore potential problems that could have been managed initially may

escalate and spin out of control resulting in additional problems or failure of

the project (Charette, 1998).

The limited use of risk management techniques can have profound effects

upon system development and this has been the case with the case study

that is being used in this research project. Major problems during

development occurred within the case study in question, As a result the

problems which occurred within this development will be detailed in

subsequent sections allowing the researcher to gain an insight in what risks

occurred during the project causing its development to be hindered. Details

about the system that has been developed by the telecommunications

company is detailed in subsequent sections of this chapter as well.

1.2 Research Motivation

Undertaking a preliminary review of literature relating to risk management it

should be noted that most authors focus on the process of risk assessment.

The purpose of this thesis is to assess a large industrial Information Systems

(IS) project that has been undertaken by a large telecommunications

company within the United Kingdom (UK). Throughout this thesis the

company name of the telecommunications company that was used to carryout

this risk assessment will not be detailed and will only be identified as a “UK

Telecommunications Company”. The overall aim of this project is to assess

the risk impact, which may have affected an individual industrial, IS project.

The approach of formulating a case study based on data collated from a large

telecommunications company has been done to achieve this.

Hence the title of this research question is:

“Risk Assessment of Individual Industrial Information

Systems Projects: A Case Study”.

MSc Dissertation

14


The research question posed has been delved as a consequence of the

research topic and the methodology (see sections 1.2 & 1.4). The case study

in question is an IT project called Informe that has been carried out by a large

telecommunications company that will provide an intelligent single log on,

Intranet gateway, which is tailored to an individuals requirements and reflects

their position within the company and is meant to be a one-stop shop for

everything they need and removes the need for multiple passwords or access

requirements. Potentially this system will have 60,000 users when it is rolled

out although initially 16,000 users will operate the system. This system is now

operational and the pilot tests have been successfully completed.

1.3 Objectives of the Study

This research project has been initiated as the identification of risk is seen as

being problematic within IS projects. This has been the issue with the

telecommunications company that has developed an IT system, which is

scheduled for completion in February 2004. This research project will be

carried out using the case study approach. The case study approach will be

formulated using an external industrial organisation that has developed the IT

system in question.

The primary research title, which has been defined in section 1.1, needs to

have some specific objectives that will be addressed within this research

project. As a result the following objectives will be addressed and it will be

expected that the following objectives be achieved within this project:

1. Identify and analyse the problems that may have occurred during

the implementation of the Information Systems project.

2. Identify and analyse the causes that may have contributed to

these problems from emerging.

3. Identify and analyse the possible risks that may be associated

with the causes that contributed to the problems occurring

MSc Dissertation

15


4. Propose ontology of the identified risks, which are associated with

this type of project.

1.4 Research Methodology

The methodology for this study follows an inductive approach. It is based

upon mainly collating qualitative data in the form of one to one interviews with

key members of the development team. Throughout this thesis the name of

the interviewees will not be stated due to confidentiality purposes and

therefore the individuals that were interviewed as part of the investigation

purpose will be referred to as Person 1, Person 2 etc. The one to one

interviews that are to take place will be undertaken to identify the problems

which took place during the systems development process. Following this

stage the risks will be categorised in relation to a risk identification framework

that has been used to highlight which types of risks occurred. The risks will be

assessed and recommendations will be provided to prevent the risks from

occurring in future development projects.

An overview about the research methodology that is to be used for this project

has been provided in this section. However a more comprehensive account of

the research methodology will be discussed in Chapter 6: Research Methods.

1.4.1 Research Instruments

The instruments that are to be used to source the data within this study are a

combination of primary and secondary sources although primary information

is pre-dominant within this project. The primary sources of data shall be in the

form of one to one interviews, telephone conversations and email exchanges

with the key identified members of the development team. The secondary

sources shall be derived from the analysis of publications about risk

management and in particular risk identification and risk assessment

methods. Furthermore an examination of user and systems documentation

will be carried out together with a focus on analysing systems development

MSc Dissertation

16


documentation that may have been done during the development of this

system.

1.4.2 Data Research Collection

As mentioned the data collation process consisted of pre-dominantly

qualitative methods. A total of four extensive and in depth interviews were

undertaken using people from different levels of the development team. The

individual members interviewed represented different sections of the

development team. The four people that were interviewed was viewed as

being adequate and also provided substantial base for validating the research

question and increasing the applicability of the findings.

1.4.3 Target Population

The primary sample of people that were to be used in this investigation

process was identified at an initial meeting that took place between the

telecommunications company and me. The 4 people selected represented

were heavily involved within the particular project from an early stage and

represented different sections of the development team.

1.5 Dissertation Outline

This thesis has extracted available literature from published journals, books

and reports from academic sources and literature from the

telecommunications company including primary data in the form of interviews.

The interview data will be used to identify the risks that occurred during the

systems development based on the problems that were experienced by

members of the development team who were interviewed as part of the

investigation process. The objective of this thesis is fourfold and has been

defined within this chapter. This chapter the introduction defines the

background for the motivation of this study and presents a detailed argument

as to why risk management is an essential step that needs to be

MSc Dissertation

17


undertaken as part of the project management process before, during and

after the systems development process (Sherer, 1997).

The introduction also specifies the research question and the objectives which

this research project aims to achieve. Finally the section provides an overview

of the research methodology and data collection methods and instruments

that are to be used within this project, which concludes this chapter.

The second part of this thesis reviews the existing body of knowledge in

relation to information systems in organisations and examines past

Information Systems (IS) developments that have been conducted but have

failed. These failed projects have been analysed to assess the contributing

factors that led to the projects failure in project management terms. This part

of the thesis examines the common problems which contribute to IS

development problems, these problems have been categorised using the risk

identification framework devised by Cadle and Yeates (2001). The project

problems, which could lead to risks that contribute to the systems failure, have

also been categorised in a more generic nature within this section of the

thesis.

The latter section of the literature survey outlines information about the

different stages of project management and then delves into the area of risk

management extensively. The third section of the thesis provides an analysis

into the findings from the investigation process together with discussions and

recommendations as to how the identified risks can be avoided in similar

future projects. This thesis will be concluded with the conclusions of this

research being defined together with a review of the objectives to ensure that

the conclusions address the objectives that were initially set. Within this

section a short summary of future research that could be undertaken will be

detailed.

Sections 1.5.1 to 1.5.7 are areas that are regarded, as the prime areas’

relating to assessing risks of individual IS projects in industrial organisations:

MSc Dissertation

18


1.5.1 Information Systems in Organisations

This section describes how and why information systems are used in

organisations together with the different levels of information use within the

organisation. The benefits of such systems to the different levels of

management are discussed within this section.

1.5.2 Failure of Information Systems Projects

This section details how IS fails and the threat levels that can impact the

survival of these systems. Frameworks that have been developed to identify

risks are discussed in this section together with details of various systems

development case studies that have failed. The risk categories from Cadle

and Yeates (2001) risk identification framework has been used to identify the

problems that contributed to systems development failures that have been

identified using documented case studies.

A summary of the problem areas in IS developments is detailed in this section

as a basis of its conclusion. These steps can be used to prevent similar

problems occurring in future IS developments.

1.5.3 Information Systems Project & Risk Management

Theory behind the concept of project management is detailed in this section

together with the fundamental aspects of project management, which need to

be addressed in all development projects. The different issues that need to be

addressed by project managers are detailed in this section together with an

introduction a fundamental aspect of project management which is Risk

Management.

MSc Dissertation

19


1.5.4 Risk Management

The importance of risk management is discussed in this chapter together with

the forms of risk and the different risks that could affect the different levels of

the organisation. Finally this section will detail the different steps that should

be followed when undertaking the risk management process.

1.5.5 Discussion of Results

This section will present the findings that have been collated from the

investigation, including the identification of the risks that took place during

systems development. The results will be represented using data analysis

methods such as concept maps.

1.5.6 Recommendations

Ways of avoiding the risks that occurred in this project will be defined in a

series of recommendations that will be defined for each risk. This is so that

measures can be taken in future projects to prevent similar problems

occurring again.

1.5.7 Conclusion and Future Research

This section describes the overview of the research, conclusions and my

personal views for further research that could be carried out.

MSc Dissertation

20

Chapter Two: Information Systems in Organisations Ritesh Hira

CChhaapptteerr 22

IInnffoorrmmaattiioonn SSyysstteemmss iinn OOrrggaanniissaattiioonnss

____________________________________________________________________________________

2.0 Organisations and Information Systems

The use of Information Systems (IS) within organisations is vital in the modern

day organisation where decision-makers at all levels need access to vital

information in order to make business critical decisions (Brooks et al, 1982).

Information Systems can also provide management with details as to how well

the organisation is doing at present, variables such as production rates; cash

flows and profit and loss (Forza, 1995) will provide management with enough

information as to where key decisions need to be made.

IS cannot solely be regarded as being computer based systems as many

other systems such as a sales order information systems may be manual

based where data can be kept in a physical location such as a filing cabinet

(Brooks et al, 1982). In the last 30 years Information Systems and the

organisation has developed in many unique ways. IS has developed as a

result of the way hardware and software has evolved over time. Whereas the

organisational structure has developed and modified itself in line with the

strategic requirements of the business which it is attempting to deliver

(Mukherji, 2002).

The earliest forms of IS were mainframe hosted centralised systems; these

were supported by dumb terminals that allowed information processing

activities in the form of transactions to take place (Leifer, 1988). Although in

recent times the user’s role in Information Systems is becoming more

decentralised this is also referred to as ‘peer networks’ (Durr, 1987). Using

decentralised methods allow greater flexibility in communications to occur, as

users would be responsible for their own IS (Mukherji, 2002).

MSc Dissertation

21


In order to gain an understanding of an Information System and what it

encompasses, a definition is provided by Avison and Shah (1997) whom

defines a system as:

‘A grouping of people, objects and processes’ (Avison & Shah, 1997)

The same authors define an Information System as:

‘A grouping that provides information about the organisation and its

environment. This information should be useful to members and clients of the

organisation’ (Avison & Shah, 1997).

Figure 1 provides taxonomy of the different forms of Information Systems that

are in use within an organisation. Some of the systems that are in use include

informal systems that are used by employees to communicate with one

another and automated systems that enable general office tasks to be carried

out automatically (Avison & Fitzgerald, 1998).

Figure 1: Classification of Information Systems (Avison & Shah, 1997)

The definition of an IS has been defined within this section. A definition of

data is that “data is unstructured facts” (Avison & Fitzgerald, 1988). Data can

be transformed into information when the data has a specific meaning to the

recipient (Ritchie et al, 1998).

MSc Dissertation 22


Having provided an overview of Information Systems and its origins, this

section will detail the nature and importance of Information Systems within the

organisation. Furthermore this chapter will also outline development

methodologies and the types of methods that are used to develop Information

Systems with.

2.1 Nature of Information Systems

Information Systems are made up of a number of components or modules

(Brooks et al, 1982). These components and modules will be connected with

one another, an example of how these components and modules can be

connected is shown in Figure 2. Brooks et al (1982) explains data enters the

system by a means of an input function which is processed; this processed

information can then be made available to the outside world through the

output module as shown in Figure 2.

Figure 2: Components of an Information System (Brooks et al, 1982)

The structure of Information Systems shown in Figure 2 will have components

that allow the initial data entry to be carried out, this data will then be

processed, as organisational needs require. Once the data has been

processed it would be stored for future use for when the user required. The

required information can be requested in a specified report format aiding the

decision-making process (Adekeye, 1997).

MSc Dissertation 23


As previously mentioned Information Technology (IT) systems have evolved

to such an extent that humans are more reliant upon IT systems to help solve

complex problems that were solved using human intuition in organisations a

few years ago (Adekeye, 1997). The dynamic organisation requires data to be

accessible conveniently, quickly and economically. Therefore a system such

as Management Information Systems (MIS) needs to be created to aid the

decision-making process as well as supporting basic operations of an

organisation and its management (Adekeye, 1997).

2.2 Importance of Information Systems

Brooks et al (1982) state information within systems must be relevant to the

person who is in need of it and the information should be unknown to the

recipient to allow improved decision-making. Using Information Systems

within an organisation carries many expectations such as economic or

performance related benefits (Forza, 1995). These key benefits can be

achieved using an IS to identify where reduced working-capital needs could

be undertaken and how prime planning targets could be achieved. These

factors can contribute to increase economic or performance related benefits

that are expected from the use of information systems.

Business environments are now operating in different cultural settings on a

global basis. Due to this Information System use is made to scan the global

business environment, this information will provide valuable feedback to the

individual in regards to business opportunities as well as cultural and political

information (Yasin & Quigley, 1994). Organisations are now operating more

dynamically and have adopted a Just-In-Time philosophy (JIT) where much of

the work is done during the last minute (Daniels, 1998). Due to the JIT

environment that is being used, information systems are very important as;

organisations need to communicate with vendors to ensure that products are

received, as required in a timely manner (Yasin & Quigley, 1994).

MSc Dissertation 24


Doke and Barrier (1994) outline reasons as to why the use of IS plays a

crucial role within organisations, these include:

Efficient operations, organisations obtain maximum benefit from

minimal use of resources that has been allocated to the task.

Effective management allows management to define using IS,

how well the products meet client needs.

Competitive advantage, information systems can be used to find

new ways of working in order to improve business performance.

The organisational impact of information systems has increased since the

1950s where data processing was the main use of IS. Although by the 1990s

this has changed and these systems are now used for strategic purposes to

aid management decision-making, see Figure 3 (Avison & Shah, 1997).

Figure 3: Impact of IS within Organisations (Avison & Shah, 1997).

2.3 IS Problems, Factors Affecting Success

Figure 4 represents an Information Systems Development Triad, during IS

development communication between general management, IS management

and user department management needs to be effective and efficient for an IS

development environment to be established and maintained (Brooks et al,

1982).

MSc Dissertation 25


Figure 4: The Information Systems Development Triad (Brooks et al, 1982)

The diagram in Figure 4 provides details as to why it is important for the three

management areas to communicate with one another. Brooks et al (1982)

outlines the importance of executives, in playing an active role in setting the

scene within which IT projects are selected and developed for the enterprise.

Surveys undertaken have identified a strong relationship between IT project

success and management involvement (Mukherji, 2002). Therefore it is

essential for management involvement within IT projects to increase the

success of IS development. Management are reluctant to get involved with

technical concepts of the system although it is important for those users who

will be operating the system once it goes live to take an active participation in

the systems development stage (Brooks et al, 1982).

An article published by Gupta & Collins (1997) has identified that

organisations are reluctant to invest in employee training or the expenditure

invested in training is insignificant compared to the technological change that

is carried out. Gupta & Collins (1997) further states poor training has serious

repercussions in that new technologies fail due to the lack of training or that

the system never reaches its full potential within the organisations, as users

do not know how to fully operate it.

MSc Dissertation 26


The history of IS developments has seen more IS failures than success

(Whyte & Bytheway, 1996). Lyytinen (1988) states that one in two information

systems development projects will not lead to a successful implemented

system. The common problems affecting Information Systems development

success have been identified by academics, these include:

Over-optimistic estimates that lead to the system being delivered late

and over budget (Brooks et al, 1982).

The project objectives are ill defined which arise from uncertainty

regarding what business needs is to be satisfied (Lyytinen, 1988).

Poor communications between development staff and users (Illes, 1990).

Lack of user involvement to the project and system (Keen, 1987).

Using inexperienced project staff during the development process (Illes,

1990).

The common problems that effect Information Systems development success

should be avoided in order to try and deliver a system to the client

successfully. To increase the prospect of delivering a system to the client on

time an IS plan should be developed (Avison and Shah, 1997). This plan

should be organised and executed in a systematic and coherent method,

doing this will ensure that the system can be developed methodically.

Furthermore the information system can be aligned to the corporation’s

objectives and goals allowing the system to be integrated into the business

(Avision & Shah, 1997).

2.4 IS Development Considerations

When an Information Systems development is being carried out there should

be a great deal of flexibility as to how the system should be developed.

Although as development progresses the possibilities of changing the system

are reduced especially after the system has been implemented (Ritchie et al,

1998). Ritchie et al (1998) defines a major source of dissatisfaction is

associated with the loss of flexibility as systems development progresses.

MSc Dissertation 27


Information systems are no longer regarded as being developed to support

the operation of the business but they are required to contribute to the

companies’ revenue as well (Williams, 1997). As systems are required to

contribute to the company’s revenue the error of investing in the wrong

technology or systems development should be avoided. This is because

investing in the wrong technology will have major negative impacts upon the

long term strategic planning of the organisation. Therefore consideration

needs to be given to the benefits and limitations of using technologies within

the business and whether they will contribute to the companies’ revenue

(Williams, 1997). The major aim of developing an IS project is to ensure that:

Important business needs are met.

The IS development is consistent with the corporate strategy.

The system leads to the attainment of specific goals and objectives.

The level of risk associated with the project is acceptable.

(Avison & Shah, 1997)

2.5 Organisational Forms

An organisation is classed as an individual or a group of people who are

united for some purpose. These individuals or groups will have specific

responsibilities to carry out in order to meet the purpose of the organisation

(Avison & Shah, 1997). Hicks (1993) identified four organisational forms as:

Functional – organisational structure is aligned with managerial

functions, responsibilities are allocated within this organisational form.

Product – activities are grouped together by outputs and products

where each division is organised internally by functions such as

Marketing or Design.

Bureaucratic – within this type of organisation individuals cannot be

entrusted to perform their tasks to a satisfactory standard and

therefore rules and procedures are enforced upon job roles.

MSc Dissertation 28


Matrix – the dual nature of systems authority and information

reporting is identified.

(Hicks, 1993)

The organisational structure will vary between companies, therefore it is

important for analysts to understand the organisational structure so that the

appropriate information system is designed and implemented (Avison &

Fitzgerald, 1998).

2.6 Information Use in Organisations

The use of information systems will eliminate routine work, at the same time

the need for clerks and supervisors will be significantly reduced enabling an

increase in work productivity to be achieved (Brooks et al, 1982). Brooks et al

(1982) outlines using IS within organisations allows for information reporting

at mid management level to be conducted more quickly and importantly data

can be used from a number of sources in order to base a report upon.

Information within the organisational context is classed as a basic resource

like materials and its personnel. It can also be considered as a commodity in

the form of letters and reports (Adekeye, 1997). Essentially like many

organisational resources Adekeye (1997) suggests information has become a

critical resource for organisations and its personnel in order for them to carry

out operations efficiently. Gupta & Collins (1997) have determined financial

institutions as being one of the largest investors of IS. It has been estimated

that in 1994 alone banks had invested US$20 billion on IS and technologies in

an effort to improve efficiency and to enhance client services. Lederer &

Mendelow (1988) enforces the point made by Gupta & Collins (1997) as many

financial institutions have demonstrated that the use of IS and technology can

be a powerful competitive weapon capturing market share, improve customer

service and creating new products and services.

MSc Dissertation 29


Information use within organisations takes place at the strategic, tactical and

operational levels. Williams (1997) defines the information use at the three

levels as:

Strategic – information at this stage is required by senior managers to

direct the organisation as a whole. Information at this level is obtained

from external sources. IS at this level are expensive and are orientated

around demographic analysis.

Tactical – mid management use information at this level to implement

strategies and select appropriate tactics. The information use at this

level is concerned with current performance, utilising company

resources and short term forecasting.

Operational – the detail level of information at this stage will be high

and can be derived from operational data mainly from the system itself.

Junior managers for the day-to-day running of the functions normally

require this information.

The information used and required at the three levels of management varies

from one level to another; this has been detailed in Figure 5. Figure 6

provides an overview of the purpose of each information system within the

three management levels together with examples of systems that are used at

the three management levels (Avison & Shah, 1997).

Information Type and Use

E IS

M IS

D a y to da y

opera tiona l system s

T P S

S tra teg ic L ev el

E xecu tive In fo rm atio n S ystem s (E IS )

M an agem en t L eve l

M anagem en t In fo rm atio n S ystem s (M IS )

O p era tion a l L evel

Functiona l system s

T ransac tion P rocessing system s (T P S )

E IS

M IS

D a y to da y

opera tiona l system s

T P S

S tra teg ic L evel





Fun ction a l system s


S tra teg ic L evel





Fun ction a l system s


Trend, Pattern, Decision-Making

Summary, Production & control

Detailed, short range, real time use

Figure 5: Information use at the 3 Management Levels (Avison & Shah, 1997)

MSc Dissertation 30


Figure 6: IS Purpose at the 3 Management Levels (Avison & Shah, 1997)

2.7 Organisations and Components of IS

Changing organisations and evolving computer architectures have undergone

similar evolution patterns in that both have evolved from a centralised to a

decentralised design (Mukherji, 2002). Both centralised and distributed

systems require a different degree of central control and authority where

distributed systems have far higher levels of communication. Using

decentralised systems enables independent communications and resource

share to be undertaken with a high degree of freedom (Mukherji, 2002).

Information systems within organisations are now classed as competitive

weapons. Wiseman (1985) states that as technology has changed so has the

way IS are used within organisations. Initially IS technology was used for

management information and decision support but they are now used as

Strategic Information Systems (SIS). Using a combination of SIS together with

organisational structures has proved a competitive weapon for an

organisation against its competitors (Mukherji, 2002).

Figure 7 details the four essential components that exist within an IS. These

include:

People are required to operate the system and include end users and

Information Systems specialists like programmers and operators.

MSc Dissertation 31


Hardware such as physical devices and materials that are used in

information processing, this includes peripherals and computers.

Software, this details the information processing instructions such as

computer programs

Data a component of IS, this is the informational aspect of an IS and

therefore a key element of any system.

Data - About organizational activities e.g. employee products and services

People - End users - Information Systems Specialists

Software - Systems Software - Application Software

Hardware - Computers - Peripherals

Figure 7: Components of an IS (Avison & Shah, 1997).

2.8 IS Development Methodologies

The systems lifecycle can be a good framework in which to base systems

analysis and design process although in order to undertake the tasks within

development a methodology would be required (Brooks et al, 1982). Brooks et

al (1982) suggest without the use of an adequate methodology inexperienced

developers will find it difficult to determine which part of the project should be

worked on at any given time.

The first methodology to be developed was in the 1960s by IBM, since then a

wide range of development methods have been introduced to the industry.

Prior to this systems were implemented without the aid of an explicit IS

methodology and therefore user needs were not well established, as a

consequence the IS design was frequently inappropriate (Avison & Fitzgerald,

1988). These methods are based on a series of detailed steps and subtasks

MSc Dissertation 32


that should be performed in each of the Systems Development Lifecycle

(SDLC) phases (Avison, 1995).

Avison & Shah (1997) outlines that the SDLC can be classed as a project

management tool which is used to plan, execute and control systems

development projects. Using a methodology enables the overall project to be

broken down into a number of phases. This is so that an early phase of the

lifecycle considers the organisation and its activities and the latter phase’s

focuses upon technology that will support organisational activities (Ritchie et

al, 1998).

2.8.1 Methodology Requirements

In the early days of systems development the focus of systems development

was upon programming and therefore user needs were largely disregarded. In

addition to this system developers were technically trained however their

communication skills were limited (Avison & Shah, 1997).

Prior to using a formal methodology within IS developments Ritchie et al

(1998) have defined some of the common IS development problems which

occurred:

IS design was frequently inappropriate for the application.

Programmers would use the rule of thumb technique and rely on

experience when estimating project schedules.

Developers spent a great deal of time correcting problems with the

application.

Changes that were required by the system had knock on effects with

other parts of the system.

MSc Dissertation 33


To counter some of the problems with IS developments the role of the

Systems Analyst grew of great importance and IS development methods were

introduced which are defined as:

‘A collection of procedures, techniques, tools and documentation aids which

will help systems developers in their efforts to produce a new system. The

methodology will consist of phases, themselves consisting of sub-phases’

A methodology will detail a way to develop information systems

systematically; methodologies do differ from one another. For instance some

methods emphasise humanistic aspects of developing IS whereas others

attempt to be scientific in their approach (Avision & Fitzgerald, 1988). Tools

and techniques feature in each methodology although specific techniques

may feature in a number of methodologies (Avison & Shah, 1997). A key

purpose of IS development methodologies is to make effective use of IT and

tools and techniques which are available within methodologies (Avison &

Fitzgerald, 1988).

The development of a system must evolve through a consistent and logical

process where phases must not be omitted (Avison & Shah, 1997). Systems

development is carried using information Systems Development Lifecycle

(SDLC). This lifecycle comprises of the following phases:

Feasibility Study

Systems Investigation

Systems Analysis

Systems Design

Implementation

Review and maintenance (Forza, 1995)

Methodologies such as SSADM, Rapid Application Development (RAD) and

Soft Systems Methodologies (SSM) address different parts of the SDLC,

Avison (1995) argues not all structured methods address each phase of the

SDLC, however most address the analysis and design phases of the lifecycle.

MSc Dissertation 34


This suggests that there is no single methodology that can be used to develop

an IS development with, to cover the phases of the lifecycle within a

development a number of methodologies may have to be used.

It is important to use a development methodology during IS projects as Whyte

& Bytheway (1996) outline advantages that could prevail with the use of such

methods, these include:

Systems requirements can be specified in a way that both the

developer and users can understand so that user needs are met.

A systematic development can be achieved where the projects

progress can be monitored.

Methodologies allow the system to be well documented and easy

to maintain.

Systems can be developed within an appropriate time limit and at

an acceptable cost.

(Whyte & Bytheway, 1996)

2.8.2 Types of IS Methodologies

Systems development methodologies can be classified as formal methods

where the method has a clear structure, rule based and technique orientated.

Mathematical precision is used in the specification and design stages (Avison

& Fitzgerald, 1988) using this method will produce a workable solution as the

requirements will be correct as they will be expressed mathematically.

Examples of formal methods are Jackson Systems Design (JSD) and Vienna

Development method.

Development methods are also known as structured methodologies that are

based on functional decomposition. This entails breaking the problem down

into manageable units (Avison, 1995). Techniques that are used within this

development method include functional decomposition, decision trees and

tables and Data Flow Diagrams (DFD).

MSc Dissertation 35


2.9 Impact of IS within Organisations

Forza (1995) states the use of IS within organisation has improved the way

production, management and co-ordination of activities is undertaken within

an organisational operations. Studies carried out by Forza (1995) indicate

information systems contribute to the achievement of high quality

performance together with achieving low deficiencies.

Even though information systems are being developed and implemented

within organisations, a degree of sceptism exists amongst Chief Executive

Officers (CEOs) of organisations. Surveys conducted by Gupta & Collins

(1997) conclude that managers of mid size organisations are questioning the

role and impact of IS to the organisation. They feel the returns from

Information Systems are disproportional to the investment made. These

findings have been further enforced by Gurbaxani & Whang (1991) whom

suggest organisations continue to request new advanced systems however

documentation about the value returns from present systems is non-existent

and questionable. As a result top managers are increasingly asking for

evidence to show that existing systems are being used to their full capacity

before investment is made for new systems (Lederer & Mendelow, 1988).

Reluctance to investing more money in new systems is evident within

organisations. However Information Systems Executives (ISE) regard IS in

the form of decision support systems, expert systems and strategic planning

systems as contributing significantly to organisational effectiveness (Yasin &

Quigley, 1994). The findings by Quigley & Yasin (1994) indicate that ISEs

regard information systems as being effective within organisations but CEOs

do not share this view. CEOs feel investing in information systems did not

result in strategic competitive advantage being achieved.

Findings from academics have identified differing viewpoints in regards to how

effective information systems are towards the organisation. Some academics

have identified IS as being highly effective within organisations but others do

MSc Dissertation 36


not share this view. Whichever viewpoint is shared amongst academics

information systems should be viewed as an asset rather than a cost to the

organisation. The business environment has become highly automated and

therefore the existence of computerised systems is needed for the survival of

an organisation in a modern day dynamic world (Quigley & Yasin, 1994).

MSc Dissertation 37

Chapter Three: Failure of Information Systems Projects Ritesh Hira

CChhaapptteerr 33

FFaaiilluurree ooff IInnffoorrmmaattiioonn SSyysstteemmss PPrroojjeeccttss

______________________________________________________________________________________

3.0 Failure of Information Systems projects

Computerised Information Systems are at the heart of all modern

organisations where these systems are used to obtain competitive advantage

or to re-engineer the business processes of the company (Flowers, 1997).

Even though there is great importance in the existence of IS within

organisations the total or partial failure of these systems is endemic

throughout the business world (Mitev, 1996). Flowers (1997) states millions of

pounds are wasted each year on systems that do not perform as expected do

not work at all or is abandoned before they are implemented.

In recent times the increased public interest in IS failures has increased

substantially. This is due to spectacular IS failures such as the London

Ambulance Service (Watts, 1993), Taurus at the London Stock Exchange

(Willcocks, 1997) and the alleged £77 million write off at the foreign office and

a project abandoned at the Ministry of Defence at a cost of £10 million

(Kelsey, 1993).

Flowers (1997) define an Information Systems and Information Systems

failure as:

‘an information system is some combination of computer hardware,

communication technology and software designed to handle information

related to business processes such as personnel systems or airline booking

systems’

‘the failure of an IS occurs when the system as a whole does not operate as

expected or its performance is sub-optimal, there are several degrees of

MSc Dissertation 38


failure which range from flawed but usable to totally unusable, unused or

absolute disaster’.

Poor management, ignorance of Information Technology (IT), human error or

lack of human considerations are some explanations which are commonly

placed forward to determine why IS failures occur (Mitev, 1996). This chapter

will examine why there is a growing need for IS within organisations and will

determine the failure causes that contributed to the failure of system

developments such as:

London Ambulance Service Computer Aided Dispatch System

(LASCAD)

Taurus London Stock Exchange System

Therac 25

The Performing Right Society (PROM)

Confirm Reservation System

Swanwick Air Traffic Control System

This chapter will be concluded by detailing the lessons that can be learnt from

IS development failures which have occurred and ensuring that similar

mistakes are not repeated.

3.1 Reliance upon Information Systems

Computer systems have a significant role within organisations as they provide

a great supporting role for the companies’ decision-making, without such

systems companies would continue to trade at most a few days before they

lost control of the business (Amadahl, 1990). In the modern day,

organisations turn to Information Technology if they need to solve a business

problem. In turn there is a requirement to deal with such problems

immediately without considering the potential benefits and problems that may

occur as result of such decisions being made (Holmes, 2001). Holmes (2001)

suggests the growing reliance upon IS within organisations is driven by the

MSc Dissertation 39


companies attempt to remain competitive. In order to remain competitive

organisations need to develop systems quickly using up to date technology.

This factor may result in the wrong system being developed as a result of

wrong decisions being made in relation to developing systems.

Since the 1980s and especially during the 1990s the level of IT investment

within companies has increased, for example from 1.8% to 2.75% of turnover

between 1993 and 1998 (Price Waterhouse Technology Review, 1999).

Furthermore desktop computers have been implemented on computers with

enterprise wide systems which are costly to implement. However an

organisation continues to implement IT and IS as they felt they were unable to

maintain their competitive edge or operational efficiency without using such

technology (Holmes, 2001).

Figure 8: Investment & Dependence on Information Technology (Holmes,

2001)

Figure 8 shows how investment and dependence on IT has increased from

the 1950s to the 1980s. The diagram represents an increased dependence

and investment in IT from 1988 to the present day. Although between 1950-

1985 the investment and dependence on IT was low (Holmes, 2001).

MSc Dissertation 40


3.2 Threats to Information Systems Survival

Developing and maintaining an Information System can be hindered through a

number of means which include human error, deliberate human action and

natural threats (Amadahl, 1990). The natural threats classified by Amadahl

(1990) include fire, loss of essential services and “acts of gods” and human

threats to information systems could include malicious action, errors and

negligence and loss of key staff.

This chapter will discuss in great depth the reason why IS development fails,

these failure factors will be illustrated using case studies outlined in section

3.0. To give the reader an understanding of IS development failure

contributors which lead to projects continuing to fail, the following

development factors need to be considered in order for a project to be

implemented successfully:

Obtaining top management support for the project (Amadahl, 1990).

Effective planning of risk strategies and contingency measures

(Amadahl, 1990).

An effective, clear reporting and communication structure as to how

well the project is being developed (CIO Magazine, 1998).

Effective project management techniques and methods should be used

to carryout IS developments (Flowers, 1997).

The above list is not exhaustive but a select few to provide an understanding

as to what contributes to IS development failure, subsequent chapters will

provide a deeper understanding of factors that lead to systems failure.

MSc Dissertation 41


3.3 Information Systems Failure

It is difficult to inform chief executives of organisations of the growing

importance of IT to the modern organisation, and of the problems which exists

in trying to use IT effectively (Mitev, 1996). Mitev (1996) justifies the case for

this by stating that this information is available but tends to be inaccessible

and too wrapped up in specialist methods and tools.

To resolve IS project failure there is a requirement to understand the problem

in broader terms. The problems that cause the project to fail or the risks to

occur need to be understood so that a more comprehensive solution can be

derived (Holmes, 2001). Holmes (2001) outlines six concerns which effect IS

success or failure:

The issue of high investment but low return.

The problem of a culture gap between business and IT.

Problems of information politics.

Over-commitment to IS projects.

Lack of accountability for failure and poor software.

Attempting to deliver a solution which addresses all the problems

of a business.

To attempt to resolve project failure a three-step process can be followed

which involves:

1. Understand the problem context

2. Derive individual solutions to the problems which are identified

3. Bring the individual problems together and solve them

collectively to optimise the delivery of IS projects

(Holmes, 2001)

MSc Dissertation 42


If the above three steps are followed then the risk of IS failure can be

reduced, this can only be done if the three step mentioned are undertaken

effectively and sequentially.

3.4 Forms of Information Systems Failure

Chapter 5 of this thesis examines and details the concept of Risk

Management in some depth together with risk categories that have been

formulated by academics such as Hughes and Cotterell (1999), Kliem & Ludin

(2000), Pressman (1997) and Cadle and Yeates (2001). The risk categories

defined represent failure factors that can contribute to a project failing. For

instance the framework that has been developed by Cadle and Yeates (2001)

has been selected for use within this project. This is because of the

shortcomings of the other risk categories and the comprehensiveness of the

framework devised by Cadle and Yeates (2001). It should be noted that the

list is not exhaustive but provides a comprehensive starting point in order to

identify the possible failure factors that may contribute to IS failures.

The risk categorisation developed by Cadle and Yeates (2001) is:

The Commercial Background The Contract

The Customer The Users

Acceptance The Functional Requirement

The Technical Requirement Performance, Reliability & Availability

The Project Plan The Developer’s Skills

Project Staffing The Development Environment

System Software Tools & Methods

The Target Architecture Bought-In Items

MSc Dissertation 43


The risk categories detailed in this section and within chapter 5.0 will be used

to identify the problems and risks which occurred with projects such as the

London Ambulance Service, Confirm and Swanwick Air Traffic Control

System. The case studies detailed in section 3.5 will be used to identify the

possible risks that may have occurred with development which led to the

system ultimately failing.

3.5 Information Systems Developments

Unanticipated problems during the lifecycle of IS developments can lead to

delays, overspending and the development of ineffective systems (Iacovou,

1998). Iacovou (1998) acknowledges the use of formal project management

approaches and CASE tools will improve the process and outputs of IS

developments. Such methods and tools will significantly contribute to the

success of IS developments although the risk of failure is not diminished.

This section will provide the reader with an outline of IS development failures

that will be discussed in this chapter outlining the contributors that led to the

systems development failing. The case studies to be discussed include:

In the early 1990’s the British Performing Rights Society (PRS) began the

implementation of an integrated Performing Right On-line Membership

System to manage the administrative processes of the organisation. The

new system was to replace a number of proprietary, legacy applications

using open-systems architecture. After a number of delays, the project

was abandoned in 1992. During its two and a half years of the project,

PRS spent $17 million on the development of the system (Flowers, 1997).

In the late 1980’s, the London Ambulance Service, which is the largest

ambulance service in the world, initiated its first computerisation project

that would allow dispatchers to transmit information to the vehicles. After

spending $11.25 million on its development, the service abandoned the

project because it was not able to handle its daily load. Within a year,

MSc Dissertation

44


another project was initiated to introduce a more sophisticated, computer

aided dispatch system. The system went live on October 26, 1992 and

was shut down the next day because of massive “exception reports” and

“lost emergency calls”. After attempting to operate the system in a semi-

manual mode for a few weeks, the system was totally abandoned

(Flowers, 1997).

In 1988, a consortium comprised of Hilton Hotels, Marriott, and Budget

Rent-A-Car Corporations subcontracted to AMRIS (a subsidiary of

American Airlines), the development of a leading edge travel industry

reservation system (CONFIRM). Originally, the system was expected to

cost $55.7 million. During the life of the projects, various delays and cost

re-estimates were announced. Three-and-half years after the project had

begun and a total of $142 million had been spent, the project was

cancelled. This led to multi million-dollar legal battle between the partners

(which led to an out-of-court settlement in 1994) and the firing of many top

Chief Executives by AMRIS. (Oz, 1994; Flowers, 1997).

The collapse of the Taurus project, the London Stock Exchange’s £500

million IT venture rocked the city of London and the stock exchange itself.

A high profile project in the UK and the largest in Europe were to

revolutionise share trading yet it failed at a cost of millions of pounds.

The £623m Air Traffic Control System development in Swanwick was

dogged by problems which led to the disruption of many flights and placed

great risks upon human life. The implemented system caused the

grounding of UK flights due to a malfunction in the system which led to its

breakdown.

Computers are increasingly being introduced into safety-critical systems

and, as a consequence, have been involved in accidents. Some of the

most widely cited software-related accidents in safety-critical systems

involved a computerised radiation therapy machine called Therac-25.

Between June 1985 and January 1987, six known accidents involved

MSc Dissertation 45


massive overdoses by Therac-25 with resultant deaths and serious

injuries. They have been described as the worst series of radiation

accidents in the 35-year history of medical accelerators (Rawlinson, 1987).

It is beyond the scope of this report to examine all the problems that led to the

failure of each of the cases described. The problems that contributed to the IS

failures have been identified using Cadle and Yeates (2001) Risk

Identification framework. Discussions about this framework have been

detailed within this section. Examples of problem areas which contributed to

the IS failure to occur within the case studies will be detailed in chapters 3.5.1

to 3.5.6. However a comprehensive identification of project related problems

using Cadle and Yeates risk identification framework has been developed and

can be viewed in Appendix 1.

3.5.1 London Ambulance Service CAD System

Using the Risk Identification framework by Cadle & Yeates (2001), it has been

identified using this case study example that the London Ambulance Service

(LAS) encountered problems within the Commercial Background category. An

example of this was that the appointed members of the LAS board were not

fully aware of their positions of responsibility and what their role was within

this IS development. This was especially the case when setting the £1.5m

budget in which an informed discussion was not taken and was only agreed

based on the recommendations of external contractors (Beynon-Davies,

1995). Cadle and Yeates (2001) outline a counter strategy where the risks

associated with the commercial background can be avoided. This can be

done by having a pre-project review in place where commercial issues such

the one identified using the LAS case study can be avoided. At the review

stage the contract terms can be agreed between all parties (Cadle and

Yeates, 2001).

When determining which vendor should be awarded the development of the

LAS Computer Aided Dispatch (CAD) system, an external contractor and a

MSc Dissertation 46


non-technical manager were given responsibility with no internal LAS staff

being involved (Flowers, 1997). Furthermore the deadline date and budget for

which the LAS development was scheduled was far too rigid, tight and

unrealistic (Beynon-Davies, 1995). To avoid such problems from occurring an

approach that can be used is to document any assumptions and ask senior

management to approve them; resultant discussions can provide an

opportunity to remove uncertainties (Cadle and Yeates, 2001).

The system design was based on a perfect world design where the

technology was perceived to work as it is supposed to do, users do as they

are told and unexpected things never happen (Flowers, 1997). The real world

problems were not taken into consideration when developing this system. It

was viewed that the system would provide a technological fix for poor

performance and automates staff problems (Computer Weekly, 2002). The

system failed due to limited attention to design being paid to real world

scenarios. A complete design considering both social and technical elements

need to be in place before proceeding to the detailed design stage of

components so that all technical requirements are met.

3.5.2 Taurus London Stock Exchange System

During the Taurus development the role of senior management was limited;

the important committee members that were given responsibility in managing

the projects progress were unable to discover the true state of development

(Drummond, 1998). Certain groups who were monitoring development met for

a mere 90 minutes a month. Communication between the development team

was difficult as the team were split over two sites geographically remote from

each other (Flowers, 1997).

The problems outlined have been classified under the Customer category,

these could be minimised if the Taurus project manager had anticipated such

problems occurring with members of the Taurus development. The project

manager can then get to know the various managers and committee

MSc Dissertation 47


members whom were responsible for the Taurus development and get them

‘onside’ with the project (Cadle & Yeates, 2001).

A functional problem, which occurred with this project, was that the systems

requirements were never signed-off formally and due to the number of

stakeholders that had a vested interest in the system. Additional requirements

were continually requested by stakeholders causing systems re-working,

schedules and costs to escalate (Price Waterhouse Technology Review,

1999). Cadle & Yeates (2001) specifies someone whom is not involved with

the project should review the functional requirement of the system using a

formal review technique such as a walkthrough. This will aid identification of

differences that may exist between the customer and the developers’

expectation of the system.

3.5.3 Therac 25

The computer terminal used to treat patients presented a “Malfunction 54”

message; the clinic in response to this could not find anything wrong with the

system. They continued treating patients again this error message occurred

eventually killing two individuals due to a lack of training and unfamiliarity of

the system (Jacky, 1996).

The poor user interface encouraged operators to operate the system in a

haphazard manner; error messages that occurred were cancelled due to the

poor operational training provided by the system developers (Jacky, 1996).

Every effort needs to be made to involve users during the development of the

project which may involve user training enabling them to familiarise

themselves with the system. Project managers must ensure that users of the

system are involved during the project even if they are reluctant to do so

(Cadle & Yeates, 2001).

Users of the system questioned the performance of Therac-25 however the

system was not withdrawn from service but a makeshift temporary fix was

MSc Dissertation 48


recommended (Jacky, 1996). The performance standards of the system can

be thoroughly tested by building and testing prototypes of critical functions in

order to identify where areas of additional effort will be required (Cadle &

Yeates, 2001).

3.5.4 The Performing Right Society PROMS

The organisation found itself struggling to cope with the demands of an

ambitious down sizing project. The project was deemed ambitious as the

requirement of downsizing successfully a demanding Online Transactional

Processing (OLTP) application is few and far between. The size of a project

like this requires early problem identification. However it appears the serious

problems associated within the PROMS development were not identified

resulting in re-working and project plans needing to be changed. Of the £11m

spent over the duration of the PROMS project, £8m was wasted, the delivery

schedule was delayed due to software difficulties, and as a result a 10-week

delay was announced. Following this the March 1992 implementation date

was abandoned with a new date being scheduled for September 1994.

Budget and timescales can escalate beyond control within a project and

therefore the project manager needs to be involved from the initiation of a

project through to delivery and should be involved when the projects initial

plan is created (Cadle & Yeates, 2001). Cadle and Yeates (2001) suggests if

the project manager is not involved in the bid phase then they should re-visit

plans as soon as possible and raise any issues concerns and possible risks.

As well as this contingency measures should be in place to deal with any

problems that may occur.

A further problem that contributed to the PROMS project failure was the lack

of effective control overseeing the project team. The reporting of the projects

progress was infrequent and inadequate (Flowers, 1997). Staff attitude within

the PROMS development encompassed of non-conductive to the successful

conduct of this project. This took place in the form of staff and managers not

MSc Dissertation 49


being open about mistakes and failures and to learn from them. (Flowers,

1997). The project manager must ensure that effective control is achieved and

maintained during the project by endorsing open communications within the

development team. Together with these holding regular project meetings

involving the project team throughout the projects life will increase

communications (Cadle & Yeates, 2001).

3.5.5 Confirm Reservation System

Systems design within the Confirm development was carried out using a

CASE tool resulting in a database structure being designed by the system that

entailed minimal influence from the developer (Oz, 1994). The CASE

technology used was unfamiliar to the developer and therefore resulted in

development problems when fixes need to be made (Flowers, 1997). To

rectify this problem and prevent it from turning into a risk, which leads to the

project failing, training should be provided to members of the project team so

that the team understand the advantages and limitations of the system

software. Consultancy groups can prove cost beneficial in the long run in

terms of time saved when attempting to exploit the software (Cadle & Yeates,

2001).

The CASE tool used to create the database structure for Confirm was initiated

based on poor decisions made by managers, this led to the development staff

not being fully acquainted with the technology that was being used (Oz,

1994). To counter this problem from occurring within IS projects the

development team must be made familiar with programming languages and

tools such as CASE. If necessary it maybe advisable to use part of the project

as a pilot to gain experience of tools that can be passed over to the rest of the

development team (Cadle & Yeates, 2001).

MSc Dissertation 50


3.5.6 Swanwick Air Traffic Control System [ATCS]

In order for an IS development to be successful the project manager should

attempt to make use of staff when required and try and avoid a high levels of

staff turnover occurring (Cadle & Yeates, 2001). Within Swanwick’s Air Traffic

Control system development many project leaders continually changed during

the project (BBC, 2002a, BBC, 2002b). This would have caused cost and time

over-runs as project leaders joining the project would require training and

familiarisation as to where development is at within the project (Hughes &

Cotterell, 1999). Retaining the same project leaders from start to finish within

the project should be paramount within the project in order for timescales to

be met. To counter the risk of project leaders leaving the project a

combination of senior and junior project leaders should be appointed within

the development team. If project leaders do leave the project then this can be

compensated, as other project leaders will be available to lead or manage the

systems development (Cadle & Yeates, 2001).

IBM who was chosen to develop the new system carried out the Swanwick

development. The system was based on one that was being developed in

America (BBC, 2002b). This meant designing the system using new hardware

and original software. Off the shelf components and software should have

been purchased rather than developing unique software (BBC, 2002c). If

Information Systems developments are to use an environment that has been

developed elsewhere then testing should be conducted on this target

environment as soon as possible. This is so that any software problems can

be highlighted and rectified (Cadle & Yeates, 2001). A Cost benefit analysis of

the target environment should be conducted, as costs could be substantial if

changes to the software environment are needed.

MSc Dissertation 51


3.6 Information Systems Development Success

To deliver systems effectively Holmes (2001) outlines four cornerstones that

should be given consideration prior to reaching a decision as to whether to

proceed with an IS development:

1. A balanced viewpoint is required where IT presents both risks and

benefits. This needs to be understood so that over-exuberance is replaced

with a more realistic perception of IS development.

2. Technological developments can present risks and therefore project teams

need to carefully consider the investment that is to be placed upon a

development. Both the IT and business needs of a development can be

considered in collaboration rather than isolation.

3. The best project manager should be appointed to manage the project not

someone who is a good technician. Managing IS project requires a focus

on project management not technology management. Managers who have

skills in dealing with less tangible, political and behavioural aspects should

equip the project manager to recognise and manage early warning signs

of failure.

4. Excellent project management decisions need to be applied throughout

the project so that cost overruns and project failure is avoided or

minimised.

The steps outlined above will increase the chances of project success

significantly, but this will only be the case if the four steps are executed

adequately. Collins (1998) explains that by reducing the complexity of a

system will greatly improve IS development success. This was the case with a

Customer System developed by Barclays Plc, steps that were taken to ensure

that the system was delivered successfully included:

User expectations were lowered solely because the lower the user

expectation is of a given system; the level of user disappointment will

also is reduced.

MSc Dissertation 52


Clearly written communications to all users of the system enables for

them to be kept fully aware of the development status and what to

expect from the new system.

Steps were taken to reduce project risks significantly.

Extensive training had taken place throughout development rather

than being rushed through at the end.

(Collins, 1998)

These are some of the main steps that were taken by Barclays Plc in order to

ensure that the system was developed successfully. It is not possible to detail

all the steps that were taken to ensure that Barclays Plc achieved project

success due to the time constraints of this project. Although the key concepts

that should be addressed when developing information systems have been

defined within this chapter to enable future projects to be implemented

successfully or with minimal problems occurring.

3.7 Problem Areas in IS Development

Sections 3.1 to 3.6 have discussed the contributing factors that led to the

project failures of the Taurus, Confirm and London Ambulance Service IS

developments. Subsequent sections of this chapter will provide an overview of

the common problem areas that effect development of information system

projects. It is these problems that will be outlined in sections 3.7.1 to 3.7.6

providing the reader with an insight into the types of problems that can occur

in projects. This will enable the readers to become knowledgeable with these

problems allowing them to monitor and remove similar problems which

become a risk to the project if they occur in future IS developments.

3.7.1 Technical Developments such as the London Ambulance Service CAD system are an

example of where the project was pursued solely as a technical focused

project (Flowers, 1997). The key problem with technology focused projects

MSc Dissertation 53


leads to limited organisational issues being addressed within the IS

development (Collins, 1998). Collins (1998) further outlines as the degree of

technology focus on developments grow any suggestions or objections are

likely to be viewed as trouble making rather than doubt upon the system. A

classic example of where this occurred was within the LAS development as

control room and ambulance crew staff issues were largely ignored by the

development team (Beynon-Davies, 1995).

The rational world, technology focused developments would be consistent

and feasible although this is not enough. Holmes (2001) summarises for

developments to be successful a triple focus on development needs to be

done with a focus on organisational, human resources and technical spheres

needing to be addressed in which the systems operates.

3.7.2 Human

Senior management involvement is needed during IS projects however in

many of the project discussed in this chapter senior management were not

aware of the projects status on a continual basis (Flowers, 1997). The

reasons why this maybe so is due to the time-length of the project, which is,

needed a systems completion. IS projects can take months or years to

complete which may also include complex technical detail and therefore few

senior managers may have the expertise or time to take any special interest in

the project (Markus, 1983). Once this step is carried out senior managers will

have given away their responsibility to developers and would be reliant upon

these people to provide status reports which may or may not be accurate. It

maybe likely that senior management may only find out the true status of the

project once the system development has failed or the project is abandoned

(Oz, 1994). This was especially the case with the CONFIRM development.

Senior management involvement in the projects development is essential

throughout the development process. This involvement is needed to allow

senior managers to take action if the project goes off course (Holmes, 2001).

MSc Dissertation 54


3.7.3 Human Resource Management

During a project additional human resource maybe required to deal with any

additional work that may have arisen. In turn staff within a project may also

leave the project. Normally this should be planned at the beginning of the

project however staff turnover is expected within projects (Computer Weekly,

2002). This is normal as long as the staff turnover is relatively low, this should

be manageable and not affect the progress of a systems development

(Flowers, 1997).

During a project if there is a recurring staff turnover then action should be

taken to investigate whether there is nothing wrong with the project, staff

morale is okay and that the project is on time and within schedule. These

contributing factors all lead to high staff turnover taking place and therefore it

would be worth investigating these initial areas as to why staff turnover is high

(Hughes and Cotterell, 1999).

3.7.4 Quality Assurance

Quality assurance procedures are essential for systems development to be

successful primarily due to checks that need to be made to ensure that the

system being developed is being done so using the correct methods and

processes (Ince, 1993). Although some projects avoid the additional burden of

quality checks as extra costs are incurred. Furthermore in a high pressure

situation such as chasing unrealistic deadlines software checks will also be

minimal. This will have severe impacts upon the systems success as

computer bugs which could have been detected using Quality Assurance

(QA) checks will not be done so as these checks may not be in place

(Flowers, 1997).

Due to limited software QA being in place during development the software

will be developed in a haphazard manner. This can have profound effects on

systems and to the environment which it is operated within. The LAS and

MSc Dissertation 55


Therac 25 IS developments both faced problems due to limited formal QA

procedures being in place (Flowers, 1997. Jacky, 1996). QA procedures will

allow for software to be developed in a formalised manner ensuring that

system errors are minimised resulting in minimal defects occurring when the

system goes live (Holmes, 2001).

3.7.5 Social

As the project progresses those involved with the project will become the

most important contributor to the decision making process. At the same time

these same people will become personally identifiable with the success or

failure of a project (Oz, 1994). These factors will contribute to the cancellation

of projects being delayed further until it is beyond the control of individuals;

the projects status will be concealed preventing senior managers from

identifying what the projects true status is and causing situations where hasty

decisions are made. A culture may develop where staff may not be willing to

voice concerns and opinions as managers may not welcome this form of

information (Poulymenakou & Holmes, 1996).

The concealment of information from managers and the erratic human actions

that maybe taken during the systems development may result due to the

simple desire to save face from fellow workers (Markus, 1983). An external

manager or a project champion should be appointed who would take an

objective viewpoint of the project. This person should be on hand to oversee

development and decisions that are made (Flowers, 1997). This is so that

action can be taken on any hostile cultures that develop or to prevent people

within the development team to become to attach to the IS development

(Holmes, 2001).

3.7.6 Business

The success of IS projects will depend on the culture that exists at the

organisational/ project level. Fear based cultures may cause a lack of

MSc Dissertation 56


reporting to senior managers to take place together with news about the

project being moderated or not being passed on (Collins, 1998). As a result of

this the true status of the project will not be known only until the project has

spiralled out of control and the project team has no alternative but to abandon

the project. The project manager should attempt to enforce a clear reporting

strategy so that communications about the project is active and open at all

times allowing for senior managers to be made aware of the projects status

continuously.

3.8 Summary – Lessons to be learnt

The IS developments described in this chapter consisted of a combination of

organisational, financial, technical, human and political factors. It is a

combination of these factors that led to the failure of IS developments such as

Taurus, Confirm and the PROMS project (Flowers, 1997; Oz, 1994; Computer

Weekly, 2002). The terms failure and disaster are relative (Flowers, 1997).

The cost of the LAS dispatch system was relatively low but the implications it

had upon the people of London of its collapse mean that it can be classed as

a IS disaster (Beynon-Davies, 1995). Whereas the Confirm development can

be classed as a failure as it was not central to any of the organisations

involved.

IS failure and an IS disaster can be classified as IS failures having an impact

upon at the departmental or organisational level whereas an IS disaster will

have impacts on a much broader base such as customers and will have

strategic implications for the organisation involved (Flowers, 1997). The

problems that contributed to the failure of IS developments have been

detailed within this section. In order to strive for systems success it is

important to consider ways of countering the problems that have been

discussed using the case studies outlined. A clear reporting structure should

be established enabling all development members, managers and senior

managers to be made aware of development at all times (Computer Weekly,

2002).

MSc Dissertation 57


The success of an IS development is the commitment of management

responsible for the project (Flowers, 1997). The avoidance of over

commitment to a project should be avoided, as this factor results in the delay

of early cancellation of failed IS developments. To avoid over commitment an

open reporting culture should be developed where team members can openly

discuss project issues. Furthermore an impartial review of the projects

progress should be taken so that senior management are made aware of the

project ‘real’ status rather than a fabrication of what managers who are over

committed to the project want them to know (Holmes, 2001).

IS developments should be a combination of technology and human

considerations although the LAS case is an example of where more efforts

were placed upon technology rather than human factors (Beynon-Davies,

1995). Technology focused projects tend to cause problems as user issues

would not be addressed within the system which will result in the user being

unfamiliar with the system when they operate it (Computer Weekly, 2002).

Other issues that need to be considered when developing IS projects include

adequate user/ management consultation (Collins, 1998), assessing the

competency of vendors and suppliers (Flowers, 1997), continual assessment

of project budgets and deadlines ensuring that they are not being exceeded

(Holmes, 2001) and ensuring that adequate testing and training is carried

prior to systems implementation (Flowers, 1997). A number of Critical

Success factors (CSF) have been detailed in this section as to how IS

developments can be implemented successfully. Although it is beyond the

scope of this thesis to document all the methods that prevent the failure of

systems developments. This is because failure or success factors can differ

for different projects but a generic list of considerations has been detailed in

this section. These considerations need to be addressed within projects to

ensure that they are a success.

MSc Dissertation 58

Chapter Four: Information Systems Project and Risk Management Ritesh Hira

Chapter Four Information Systems Project & Risk Management

______________________________________________

4.1 Project Management

Information Systems (IS) projects come in all sizes and involve a degree of

output from a variety of sources (Olson, 2001). Olson (2001) provides an

example of an IS project that can be regarded as an impressive

accomplishment although from a project management viewpoint this

development can be viewed as a failure. This is because the projects budget,

timescale and performance is questionable and was heavily criticised in the

press during its development (Flowers, 1996). Projects are designed to

accomplish something for the organisation; this could include improving the

working practices of the organisation. Although projects are created to

improve working practices for the organisation they will involve a degree of

uncertainty and risk (Burke, 1999). This uncertainty and risk could occur in the

form of the project not being completed on time or within budget.

Many projects that are developed are unique and normally involve new

activities with lower degrees of efficiency making the projects accomplishment

more uncertain (Olson, 2001). Olson (2001) goes onto suggest due to the

high degree of project uncertainty, this will make the estimation of project

resources and timescales required for the project more difficult for the project

manager to carryout.

The term project management will be defined within this section. There are

many definitions that exist to define project management, although Turner

(1993) defines the term ‘project’ as:

‘An endeavour in which human, material and financial resource is

organised in unique way that allows the work scope to be undertaken,

MSc Dissertation

59


of a given specification. This should be undertaken within the

constraints of budgets and timescales. This allowing the beneficial

changes to be defined by qualitative and quantitative objectives.’

When a system is developed the project manager will be required to manage

the change whether this is socially or technological, therefore management

can be classified as:

‘the process of planning, organising, leading and controlling the efforts

of personnel as well as other resources in order to achieve the

organisational goals.’

Stoner (1992)

If some form of management is not undertaken during a projects

implementation then it is likely that the project will go off schedule, purpose

and anarchy will prevail (Handy, 1985). Effective project planning is required

when the situation in which the system is being delivered is unfamiliar, the

software is complex and a substantial use of resource will be required

(Turner, 1993). Mantel et al (2001) outlines the purpose of project

management as delivering systems on time, within budget, to a quality

standard where the system can be modified in the future, as business needs

require. More importantly the system should be delivered within the limits of

the terms of reference.

The purpose of project management outlined by Mantel et al is represented in

Figure 9 which shows the performance, cost and time targets of a project.

Primarily the client sets one of the goals however the client will agree upon all

three targets when agreeing contracts with the vendor or project manager

(Mantel et al, 2001).

MSc Dissertation 60


Figure 9: Performance, Cost, and Time Project Targets (Mantel et al, 2001)

Project planning should normally be conducted at three levels, the three levels

described by Yeates and Cadle (1996) are the strategic level which is long

term plans where the system must conform to the company’s strategic plan.

The tactical level is a yearly plan where the purpose will be to identify the

resource allocation and budgets for the project. Finally the operational level

could be a plan that has a time span of 1 – 3 months, at this stage the

manager will allocate tasks to individual team members and will define the

timescales in which the tasks have to be completed.

This chapter will detail the fundamental aspects of how project management

can be carried out effectively together with academic theory and viewpoints of

Information Systems Project Management. The chapter will be concluded with

an introduction to Risk Management which will be discussed in-depth in

chapter 5.0.

4.2 Steps of Project Management

Project management involves a 5-stage process, which should be continually

monitored and repeated to ensure that planning, and controlling the project is

done effectively (Lewin and Rosenau, 1988). Figure 10 represents a project

management process devised by Lewin and Rosenau (1988) who suggests

that the stages of defining, planning, leading, monitoring and completing a

project need to be undertaken during an IS development. An iterative

MSc Dissertation 61


approach of re-planning the project should be undertaken in order to control

the project ensuring that it is not going of course.

Define Monitor

Lead

Complete Plan

Re-plan

Figure 10: Project Management Process (Lewin and Rosenau, 1988)

4.3 Project Control Techniques

When a project is being developed and during its course of delivery a

fundamental technique that needs to be carried out by project managers is to

monitor the projects delivery timescale. Control techniques can be used to

monitor and control the projects progress (Lock, 1988) and furthermore

provide valuable information informing the project manager as to whether the

IS development is on schedule or not. These techniques will also provide the

manager with an indication as to how much the project, costs to date (Lock,

1988). Such control techniques are discussed in this chapter.

Youll (1990) explains some of the project control techniques that can be used

to control and monitor the project, these include:

Gantt Charts – this is a simple planning tool where the tasks are listed

down the left hand side and the duration of each task is represented

using a block. This visual tool is used for communicating schedules to

the project team.

Milestone Charts – these charts show significant events or deliverables

in a project rather than specific tasks that are to be undertaken. The

milestones will represent a specific point in the project where an answer

MSc Dissertation 62


of yes or no is required. Remedial action can be undertaken if slippage

was to occur.

Networks – Critical Path Analysis (CPA) focuses upon the time span of

a projects task and will identify if interrelationships exist between tasks.

In order to create the CPA it is necessary to identify the tasks, estimate

their duration and determine which tasks are pre-requisites of other

tasks.

PERT Techniques – Programme Evaluation and Review Technique

(PERT) can be used to consider timescales, costs and resource

schedules

(Youll, 1990)

4.4 Project Management Methods

The software lifecycle is used to provide a structured method of developing IS

developments (Downs, 1988). This can be initiated when the management of

an organisation recognises that a business system needs improvement or that

an individual has a vision that will improve the working practices of the

organisation (Avison & Fitzgerald, 1988). Avison & Fitzgerald (1988) state the

lifecycle can end when management decides that the system is obsolete or

unused. They further state that at this stage two things could take place where

the system could be shelved or the lifecycle could be initiated again as one

lifecycle has ended.

Many methodologies have been devised within industry and academia for

system analysis and design to take place (Downs, 1988). The different

methodologies that have been developed will have a number of procedures

that should be followed during the development process and tools and

techniques that can also be used during the IS development process (Avison

& Fitzgerald, 1988).

Project methodologies have been developed to cover whole or part of the

project lifecycle. Some methodologies solely focus upon the earlier stages of

MSc Dissertation 63


the project lifecycle such as analysis whereas other methods may cover the

systems lifecycle from analysis, design, programming and testing

(Hawryszkiewycz, 1991). The stages within the lifecycle can be executed in a

number of ways, for instance the Waterfall Model executes each lifecycle

stage in a waterfall manner where each stage is stopped for a period of time

before the next stage is continued (Jones, 1990).

The Linear Model has a number of phases that can only proceed when the

previous one has been complete and at the end of each stage a report is

expected (Hawryszkiewycz, 1991). As previously discussed there are a

number of methodologies that have been developed in order to aid IS

development, these include:

Prototyping

Structured Systems Analysis and Design Method (SSADM)

Information Engineering (IE)

Soft Systems Methodology (SSM)

Yourdon Systems Method (YSM)

The methodologies highlighted do not cover the whole lifecycle nor do they

provide a total encompassing system, as shortfalls do exist with each of the

system methodologies described (Avison & Fitzgerald, 1988). However

Avison & Fitzgerald (1988) do state that a methodology can provide better

end products with documentation, improved management and control over the

projects development with a standardised process.

This section will only outline IS development methodologies and the

underlying principles associated with them. This has been done as it is

beyond the scope of this thesis to go into the technicalities of the different

methodologies due to time constraints.

MSc Dissertation 64


4.5 Project Feasibility

The feasibility study is a tool used in project management to evaluate and

identify the probable cost and effectiveness of developing or modifying an

existing process (Yeates, 1986). In order to undertake the feasibility study the

problem will need to be identified together with a definition of the projects

scope, cost estimation, identifying the functional and non-functional aspects of

the project. The overall purpose of the report is to recommend whether the

system’s proposal should progress Fitzgerald & Fitzgerald (1987) whom state:

‘The feasibility study is undertaken to determine the possibility or probability of

either improving the existing system or developing a totally new system’.

These recommendations from the Feasibility Study will be based on the

information described in this chapter. Feasibility studies can also be used to

screen out projects that may not be consistent with the business objectives as

they are operationally unacceptable or economically unprofitable (Daniels &

Yeates, 1986).

4.6 Human Resource Allocation and Management

During IS developments many different people with a diverse range of

specialities will be involved within the project, because of this, project

management also involves the management of people (Bee & Bee, 1997). In

order for a project to be successful Bee and Bee (1997) suggests

management needs to ensure that information that is communicated to team

members is done so on a regular timely basis and more importantly

accurately. Such information that may be communicated to team members

may encompass of goals for project productivity. During each of the

development stages developers or analysts that may be affected by the

project need to be kept informed about the development progress (Yeates &

Cadle, 1996).

MSc Dissertation 65


Leadership styles can be executed using three styles which include

autocratic, democratic and laissez-faire (Adair, 1986). The three leadership

styles can be used depending on the working environment at a specific time.

Although the managers’ personality will also contribute to the way their

leadership style is executed (Adair, 1986). When the manager is forming the

team they must choose the right team as the team must consist of both

experienced and inexperienced people who have had practical experience in

developing IS projects. Bee and Bee (1997) indicate Human Resource

Management (HRM) involves getting the most efficient usage of the team that

has been formulated by the project manager. In turn the project manager’s

resource should also be used to maximum effect so that the project is

delivered to the customer on time and within budget.

4.7 Estimating Project Resources

One of the fundamental problems associated with project management is that

projects are delivered late and are over budget causing contractual problems

for the client and vendor (Cadle & Yeates, 2001). One of the main causes of

not delivering the system on time and within budget to the client is due to the

ineffective or limited estimation of development resources that is undertaken

by managers (Ould, 1990). Ould (1990) outlines projects in the past have

been estimated based on an individual’s previous experience where the

estimates are based on guesswork.

These estimates may not be accurate and therefore estimation techniques

have been developed to try and obtain a greater degree of accuracy within the

estimation process. This section will outline some of the estimation techniques

that exist within industry. Estimation involves estimating cost, resources and

time scales. This activity should be done on an on-going activity throughout

the project (Ould, 1990). Two areas that need to be estimated accurately is

firstly cost estimation as the major cost in developments is analyst and

developer wages, due to labour costs increasing development time must be

estimated accurately (Brooks, 1975). Secondly Brooks (1975) outlines that

MSc Dissertation 66


staff requirements need to be estimated in advance so that adding additional

staff resource if the project falls behind schedule can be avoided.

Undertaking estimates can be conducted using past experiences where

managers use real world events to make predictions for the future or use

mathematical formulae to quantify or manipulate past experience (Boehmn,

1981). In order to produce an accurate estimation a number of estimates

should be obtained using a number of techniques where the estimation results

are compared to identify the differences (Boehmn, 1981).

Estimation techniques include estimating Lines of Code (LOC) where the size

of each software component is estimated with historical data to develop

estimates for effort and cost (Sommerville, 1992). Furthermore maintaining

information about cost, LOC, human resource or cost records about past

projects will improve the estimation process.

A tool developed by Boehm (1981) is the Constructive Cost Model

(COCOMO) that exists in three forms of basic, intermediate and detailed

forms. The COCOMO model can provide estimates for number of person

months required to complete the project in accordance to the number of lines

of source code that need completion (Sommerville, 1985).

4.8 Quality Assurance

Software Quality Assurance (SQA) needs to be carried during an IS

development to validate that developers are building the right product and

verify that the product being built, is right (Boehmn, 1979). SQA is essential

within development so that the amount of re-working after implementation can

be reduced; this is because re-working costs could escalate once the system

has been implemented. As well as this the software being developed maybe

life threatening or may cause problems if found to be faulty. Due to this

systematic checks need to be conducted to satisfy client expectations

(Cooper & Fisher, 1979).

MSc Dissertation 67


It is essential to build quality into the design process from the projects

initiation to its delivery. It is difficult to incorporate quality into the system at a

latter stage in development if it is not done throughout (Hetzel, 1988). SQA

can be carried out using a number of activities and tasks; the sole purpose of

SQA is to evaluate the quality of a project. This will be based on the level of

quality previously agreed (Pressman, 1987). The tasks classified by

Pressman (1987) that can be carried to aid SQA include:

Formal Technical Reviews

Record Keeping and Reporting

Measuring Progress

Software Testing

Enforcing Standards and Procedures

4.9 Systems Specification Design

The project manager in collaboration with the analyst must understand what

the requirements of a clients system are. In order for them to do this they

need to understand the difference between what the clients wants and what

they think they need (Flynn, 1992). The end user is the person who is to use

the system and therefore it is essential for them to be involved in the

development process especially at the requirements gathering and design

stage (Fitzgerald & Fitzgerald, 1987).

The system requirements will allow the analyst to gain an insight into the

inputs, outputs, operations and what resources will be required for the new

system (Flynn, 1992). The requirements can be identified using a number of

means such as interviewing, sending questionnaires to end users of the

system, observe users in their work and recording requirements, interviews or

questionnaire results onto standard documentation (Flynn, 1992).

MSc Dissertation 68


4.10 Development and Implementation

The implementation phase of a project involves a change in ownership within

the lifecycle of a project. At this point the old system is replaced by a new

system of hardware, software and processes (Laudon, 1996). The common

stage at which projects could fail is at the implementation stage where the

system may not perform as expected or is not operational at a specified time

(Flowers, 1997). Examples of case studies where projects have failed in this

manner include the London Stock Exchange (LSE) Taurus development

(Drummond, 1998) and London Ambulance Service Computer Aided Dispatch

System (LASCAD) failure (Beynon-Davies, 1995).

As previously mentioned the role of users is a key factor in determining

whether implementation is successful (Currie, 1995). Other factors described

by Currie (1995) that will impact implementation success include:

The degree of management support for the implementation process.

The degree of risk and complexity associated with the project.

Management impact during the implementation process.

These factors whether done effectively can have positive or negative effects

upon the IS development. Involving users can build a commitment to change

as the user will feel more empowered and in control (Laudon, 1993). In order

for the implementation to be successful project managers need to decide

upon the type of conversion strategy that will be adopted these could include

Direct, Parallel, Phased or Pilot conversion (Currie, 1995).

The hardware and people implementation plan needs to be defined

establishing how the system is to be implemented. The key aspects to

consider within these plans are program conversions, training methods for

users and communicating the benefits of the new system to the users

(Ennals, 1995).

MSc Dissertation 69


4.11 System Testing

During the project development stage the system can also be rejected by

users if the system is faulty due to the lack of testing that may have taken

place (Flowers, 1997). Project managers needs to allocate time for adequate

testing to be carried. This is an area where limited time is allocated and as a

result systems like the LASCAD development were implemented with errors

within them.

The testing phase involves identifying the actual and expected outputs and

comparing both results. It is very difficult to remove all errors that are in the

system because many errors may not appear during the testing phase

(Schach, 1996). The testing phase should be to reduce the errors to an

acceptable and manageable level for both developer and client.

4.12 Systems Review and Maintenance

Once the system is implemented errors are likely to emerge as a result of

users using the system and finding faults with it (Boehmn, 1975). The

maintenance process may entail carrying out corrections to the system that

maybe required. The corrective maintenance that is needed maybe for

coding, design or requirements errors that may have occurred.

The maintenance stage can be an on-going process depending on the

Service Level Agreement (SLA) contracted between the client and software

vendor. However after a period of time the new system needs to be reviewed

to determine whether the new system is meeting the objectives defined in the

earlier development stages. The findings from this investigation should be

documented in a Post Implementation Review (Sallis, 1995).

MSc Dissertation 70


4.13 Introduction to Risk management

This chapter has outlined fundamental issues that needs to be addresses by

project managers when undertaking an IS development. Each of the issues

addressed in chapter 4 carry equal importance towards successfully

managing a project implementation. Although a key area within IS project

management is risk management which is the “occurrence of an event that

has consequences for, or impacts on, project” (Kliem and Ludin, 2000). The

key emphasis of this project is to assess the risks associated with an IS

development conducted by a large telecommunications company. As the

projects subject area is to do with Risk Management, this subject will be

discussed in some depth in chapter 5.

MSc Dissertation 71

Chapter Five: Risk Management Ritesh Hira

CChhaapptteerr FFiivvee

RRiisskk MMaannaaggeemmeenntt

____________________________________________________________________________________

5.0 Risk Management

In all walks of life humans are vulnerable to risks of all kinds (Frosdick, 1997).

This is no exception for Information Systems (IS) projects. Kleim & Ludin

(2000) suggests ‘risks are intrinsic to any IS project’. They define the concept

of risk as ‘the occurrence of an event that has consequences for, or impacts

on, projects (Kleim & Ludin, 2000).

Projects such as the London Ambulance Service Computer Aided Dispatch

System – LASCAD (Flowers, 1997) and London Stock Exchange TAURUS

system (Drummond, 1998) are all examples of projects, which may have

failed as a result of poor analysis, and identification of risks. These IS

developments are discussed in some detail in Chapter 3.0. This assertion has

been further re-enforced by Nunes and Annansingh (2000) who suggest ‘poor

risk management often leads to failure, these failures have been linked to

inadequate business and risk strategies which are implemented’.

The points outlined by Nunes and Annansingh (2000) have been further

emphasised, who have carried out investigations using the case study

approach. Their findings suggest ‘identifying and evaluating potential risks will

enable better management and control of risks to take place in the future’.

Mobey and Parker (2002) also suggests ‘to increase the chances of a

proposed system succeeding it is necessary for the organisation who is

undertaking such IS developments to have a good understanding of the

potential risks which the project could encounter’.

In order to understand the potential risks, which can impact a project, it is

important to systematically and quantitatively assess these risks, anticipating

MSc Dissertation 72


possible causes and effects. From thereon select appropriate methods or

mitigation strategies that can be applied to deal with such risks (Mobey and

Parker, 2002). The steps and techniques that are used in the Risk

Management process will be discussed in detail within this chapter.

5.1 Importance of Risk Management

Organisations have realised the growing importance of Risk Management due

to the increased Information Technology (IT) expenditure and use that has

steeply risen in the last few years (Bandyopadhyay et al, 1999). In the present

day organisations have become more dependent on technology and as a

result have become more vulnerable to the risks of IT failure. Bandyopadhyay

et al, (1999) further emphasises that ‘IT risk management is one of the most

important issues facing IS executives today’ where the primary objective of IT

risk management entails the following:

Protect IT assets such as data, hardware and software from

external threats such as natural disasters.

Avoid or lessen total losses by selecting and implementing the

best combination of security measures.

Protect against internal threats such as technical failures,

sabotage and unauthorised access.

(Bandyopadhyay et al, 1999)

5.2 Forms of Risk

A proven method that can help the project manager to identify all the possible

risks that could occur in a given project is to undertake a series of

brainstorming activities with the help of their project team (University of

Sheffield, 2001). A further process that can be used to identify the potential

risks that could affect a project is by consulting a risk factor chart which shows

a list of identified risks that have been accumulated from similar projects in the

past (University of Sheffield, 2001). This is also known as a Risk Register

MSc Dissertation 73


detailing risks that have occurred in similar past projects (Chapman & Ward,

1997).

Carr (1993) suggests ‘the Software Engineering Institute has assembled a

taxonomy of hierarchically organised risks in 13 major categories, with about

200 questions that will help the project manager to identify and monitor the

potential risks which may affect the development process’. This enforces the

growing importance of risk management within IS projects as institutions like

the Software Engineering Institute have developed frameworks and

techniques that will assist project managers in detecting project risks easier.

Although risk categories have been defined McConnell (1996) emphasises

that there is no precise or correct solution in order to deal with these risks. In

light of this organisations are heavily reliant upon people with past experiences

and management practices to control these risks (McConnell, 1996).

Risk categorisation will be summarised in this section to provide the reader

with an insight into what groups, risks have been categorised. Section 5.3.3

will provide an account of the risk types which have been categorised by

academics. Jones (1996) has identified the top five risk factors that affect a

projects progress in the commercial sector and Management Information

Systems (MIS) sector. Jones (1996) highlights these two examples where an

example of risk within the MIS category is cost overruns and inadequate

configuration control. An example of risks within the Commercial category may

comprise of low user satisfaction or excess in time to market occurring. Table

1 outlines the top five risk factors which effect projects within the MIS and

commercial sector. It should be noted that these risks are not just associated

with these project sectors solely but are also inherent in many projects that are

developed within other sectors with other sectors

MSc Dissertation 74


Table 1: Risk Factors Effecting Commercial and MIS Projects (Jones, 1996)

Table 1 shows the percentage of projects that are developed which are at risk

from a particular risk factor. For example 80% of projects are at risk from

creeping user requirements occurring and 70% of projects are at risk because

inadequate user documentation is delivered to the user (Jones, 1996). These

figures shown in Table 1 re-emphasise that these common problems are

inherent in a large proportion of projects that are developed. This suggests

that attention needs to be focused upon these risk areas so that they can be

eradicated to ensure that the project is implemented with minimal problems

occurring which could potentially turn into risks that may affect the project.

In order to combat the risks which occur in a project, mitigation strategies are

put in place to help reduce the impact that risks may have upon the project

(Tchankova, 2002). Tchankova (2002) states ‘such strategies are

implemented because of the dependencies that are inherent to projects’.

These dependencies are normally from a projects external environment and

may comprise of external agencies or factors (Wiegers, 1998). Wiegers (1998)

has classified such typical dependency related risk factors as the availability or

in-availability of trained or experienced people and internal and external sub-

MSc Dissertation 75


contractor relationships. Wiegers (1998) further suggests ‘external

dependencies cannot usually be controlled and therefore mitigation strategies

are needed which will involve contingency planning’. This is so that any

components from a third party can be acquired from a second source. By

working with the source of dependency will allow for the status or detection of

any potential problems to be identified well in advanced (Kleim and Ludin,

2000).

As mentioned in the previous paragraph by working with the source of the

dependency will enable the earlier detection of potential risks which may occur

from a project dependency. This principle can also be shared for any project

throughout its lifecycle. This assertion has also been re-enforced by University

of Sheffield (2001) who have stated ‘many projects face some kind of

uncertainty during the projects development. This uncertainty is acceptable at

the early stages of the projects progress but would need to be resolved as

early as possible’. The same issues apply to risks where the threats should be

dealt with as early as possible so that they are controlled and minimised with

minimal impact occurring for a given project.

Wiegers (1998) states ‘one form of risk is the requirements gathering risk. If

this form of risk is not controlled then it is likely that the wrong product maybe

built or the right product developed badly’. If this occurs then customer

satisfaction will not be achieved. The results of the system being created badly

or wrong maybe due to the project not having a clear product vision, non-

prioritised requirements, rapidly changing requirements or ineffective

requirements change management processes (Boehm, 1991).

5.3 Steps of Risk Management

As previously stated the risk management method comprises of four main

activities. These activities can be carried out in isolation from one another or in

a sequential manner; this will be dependent upon the project that is being

undertaken (Frosdick, 1997). Nunes and Annansingh (2002) have identified

MSc Dissertation 76


and developed a proactive risk management framework which allows risk

management to be broken down into a number of steps that include assessing

the risk and then controlling the risk itself’.

The four steps of risk management identified by Nunes and Annansingh

(2002) are also similar to the framework which has been developed by

Bandyopadhyay et al (1999). Figure 11 and 12 presents an illustration of the

risk management framework which should be followed by people who

undertake the Risk Management process within their systems development.

Figure 11: IT Risk Management Framework (Bandyopadhyay et al, 1999)

The risk management framework defined by Bandyopadhyay et al (1999)

focuses risk management at three levels, which include the Application,

Organisational, and Inter-organisational level. Table 2 outlines the types of risk

which could be identified at the three levels enabling the reader to gain an

understanding of the forms of risks that could occur in each of the Information

Technology (IT) environments.

MSc Dissertation 77


Table 2: Risk Identification within the Three IT Environments

(Bandyopadhyay et al, 1999).

The essential purpose of risk management is to improve project performance

using a systematic process of identification, appraisal and management of

project related risks (Chapman & Ward, 1997). Chapman & Ward (1997)

regard risk management as a fundamental part of conventional project

planning where the chances of a smoother IS development is higher if an

effective risk management strategy is carried out by project managers. Kliem &

Ludin (2000) state within risk management not all risks are of equal

importance, for example some risks have greater importance than other risks.

This will depend on the type of IS development that is being carried out and

what outcome managers perceive the project to take.

Figure 12 shows a risk management framework adapted from Kliem and Ludin

(2000). They outline the vital steps in risk management which include risk

identification, risk analysis, risk control and risk monitoring. Within each of

these steps the probability, frequency, impact, importance and exposure

factors need to be analysed to determine the overall importance of one risk

over another (Kliem & Ludin, 2000).

MSc Dissertation 78


Figure 12: Risk Management Framework (Kliem & Ludin, 2000)

Frameworks such as the ones represented in Figures 11 – 12 can be used to

undertake a proactive decision making process. An assessment can be

undertaken continuously to assess what could possibly go wrong with a

project if the risks that have been identified occur (Redmill, 1991).

Furthermore this framework can allow decisions to be made as to which risks

are important to deal with and what strategies need to be implemented to deal

with identified and unidentified risks (Redmill, 1991).

Sections 5.3.1 – 5.4 will examine each of the risk management steps and also

the categorisation of risks which has been developed by academics.

5.3.1 Risk Identification

Risk identification is the process of examining a project and identifying areas

of potential risk. This can be done by carrying out brainstorming sessions with

the project team or by researching company databases of previously identified

risks that have been identified from previous projects. Risk Identification is the

identification of potential hazards. Hazards are classed as an event that might

occur and if it occurs, create a problem for the projects success (Hughes &

Cotterell, 1999). Hughes & Cotterell (1999) suggest by identifying and

analysing risks, managers will distinguish between the hazards cause, the

MSc Dissertation 79


problem it creates, the risks effect and the overall risk it will pose to the

project.

The purpose of risk identification outlined by Kliem & Ludin (2000) is for:

Project managers to identify personnel who can play a significant role

within the risk management process such as clients, senior managers

and core team members.

Identify the inherent risks that occur in almost any project.

Understand and identify the system or project being studied will

determine the components or processes of the project and its risks or

goals.

5.3.2 Risk Assessment

Risk analysis is the examination of how the project’s outcome may alter with

the modification of risk input variables. Once the risks have been identified, an

assessment of their importance should be conducted. The importance level of

a risk will depend upon its impact upon the projects progress (Hughes &

Cotterell, 1999). At this stage the risks would be categorised. This method will

help the project manager in detecting which of the risks are most severe by

assessing its risk exposure (University of Sheffield, 2001).

A document by University of Sheffield (2001) determines the risk exposure of

a given risk as the ‘product of the probability of incurring a loss due to the risk

and the potential magnitude of that loss’. The risk prioritisation can be done in

a quantitative manner by estimating the probability (0.1 – 1.0) and the risks

relative loss, on a scale of 1 to 10 (University of Sheffield, 2001).

Risk analysis is conducting using the following formulae:

Risk exposure = risk likelihood x risk impact

MSc Dissertation 80


Risk likelihood is the probability of a hazard occurring, risk impact is the affect

the resulting problem will have upon the project and risk exposure or risk

value is the importance of the risk to the project (Hughes & Cotterell, 1999).

Risk impact is estimated in monetary terms and the likelihood of the risk

occurring is measured as a probability. The calculation between risk likelihood

and impact will provide the monetary figure for risk exposure. As a result the

calculation from the risk exposure can then be compared with each other to

define the relative importance of each risk and to find out whether contingency

plans will work as a result of assessing the relative risk (Hughes & Cotterell,

1999).

The important risks that have been identified can be plotted on a risk map

(Yeates & Cadle, 1996). The risk map can be used to plot the impacts of each

risk on one axis and their likelihood along the other. The risks that are plotted

onto this map can then be monitored by management to ensure that risks,

which have a high occurrence and impact, are prevented from occurring

(Yeates & Cadle, 1996).

5.3.3 Risk Categorisation

Risks can be classified in many ways, Kliem & Ludin (2000) have categorised

risks into the following risk forms:

Acceptable vs. Non-acceptable risks

Short term vs. long term risks

Positive vs. negative risks

Manageable vs. non-manageable risks

Internal vs. external risks

The above categorisation method is generic for many projects; however

Pressman (1997) has categorised risks into Project, Technical and Business

risks.

MSc Dissertation 81


Project risks are associated with budgets, schedules, personnel, and

customer and requirement problems. The risks associated with these

elements should be investigated to identify what their impacts will be upon

the IS development.

Technical risks involve identifying potential design, interfacing, and

verification and maintenance problems. Furthermore technical obsolesce

and leading edge technology can lead to technical risks occurring.

Business risks are the identification of business, suitability and validity

problems. Strategic, management or budgetary risks can cause these

risks.

Pressman (1997)

During the risk identification process risks can be considered in a series of

categories (Hughes & Cotterell, 1999). There are many areas in which risks

could occur, as a result it is difficult for the project manager to be sure that all

possible risks have been identified. A way to deal with this problem is to gain

a second opinion from experienced project managers who have dealt with

similar projects in the past (Yeates & Cadle, 1996). Once the risk has been

defined they should be described clearly so that a decision can be made as to

what contingency measures should be implemented. The identified risk could

be made clear if it is broken down into clear statements (Yeates & Cadle,

1996).

Hughes & Cotterell (1999) have defined a risk category framework that can be

used to categorise risks into, these are:

Application factors

Staff factors

Project factors

Project methods

Hardware/ software factors

Changeover factors

Supplier factors

Environmental factors

Health & Safety factors

A description of these risk factors will be presented in section 5.3.3.

MSc Dissertation 82


For the purposes of this research project the risk identification categories

devised by Yeates & Cadle (1996) will be used within the investigation

process due to shortcomings of the other risk categories. It should be noted

that the list is not exhaustive but provides a comprehensive starting point for

risk identification within an IS project. Each of the categories will be detailed in

this section followed by typical risks that could occur in each of the categories.

The Commercial Background – business case for the project maybe

unclear. The contract type maybe inappropriate for the type of work that

is to be undertaken. There maybe immovable end dates or price ceilings.

The Contract – typical risks that could occur within this category is that

the scope of the work is ill defined or not agreed between parties. No

formal arrangements in terms of signed contracts exist all of which could

cause risks when problems occur within the project as it will be difficult

for parties to obtain compensation from one another.

The Customer – Client management structure maybe unclear. Gaining

access to key staff maybe difficult, decision-making could be difficult to

carryout within projects.

The Users – User commitment to the project maybe limited. User

resistance to change may also occur.

Acceptance – the acceptance criteria may be ill defined and not linked

to specific demonstrations of performance. Acceptance mechanisms

may not have been defined into the contract.

The Functional Requirement – requirements may be incomplete,

vague, varying levels of detail or may not be formally signed off before

development proceeds.

The Technical Requirement – the system maybe complex technically.

The developer may not be familiar with hardware and software or a high

level of innovation maybe needed.

Performance, Reliability & Availability – high degree of reliability or

availability maybe required, difficult to simulate performance in advance.

The Project Plan – lack of project management involvement, project

may have to be delivered within tight timescales. Inadequate project

plans may have been drafted and the estimates may not be based on MSc Dissertation

83


solid metrics. They’re maybe too much reliance on a few staff.

Furthermore milestones may be too far apart and deliverables may not

be defined tightly enough.

The Developer’s Skills – the team maybe inexperienced in the business

area or in the technology that is being used. People may have

undertaken analysis and design work with limited experience in this

work.

Project Staffing – staff may not be available when required or could

have other commitments that divert them from the project. There maybe

unproven customer or contract staff involved.

The Development Environment – the environment itself maybe new to

the developer and the development environment may not match the live

environment closely enough. The hardware maybe unreliable or poorly

documented.

System Software – the software being used may be unproven or may

not be available at present resulting in a degree of unfamiliarity for the

developer. Furthermore technical support may not be available.

Tools & Methods – programming languages maybe unfamiliar to

developers or it maybe unsuited to the particular project requirement.

Tools may not be available for matters such as configuration

management, project planning or testing.

The Target Architecture – hardware maybe new or unproven or may

not have been used before for the purpose it serves. Different pieces of

hardware from various suppliers may exist which may cause integration

problems.

Bought-In Items – If third party products are bought-in then it may be

hard to define whether they have adequate experience in developing the

hardware or software that is required.

(Adapted from Yeates & Cadle, 1996)

The above risk categories devised by Yeates & Cadle (1996) can be used as

a method to identify and categorise risks by. The above category will be used

MSc Dissertation 84


as basis to identify the risks within the investigation process. At the same time

attempts will be made to identify additional risk categories.

5.3.4 Risk Control

Risk control is the process of managing risks to achieve the desired outcomes

(Kliem & Ludin, 2000). This includes risk avoidance as one way to deal with

the risk. This process also includes developing a risk management plan which

outlines a production plan for dealing with each significant risk that has been

identified in risk identification and analysis stage. This stage also includes the

development of mitigation strategies to counter the risks. Once the plan has

been devised, risk control also includes risk resolution where the plans to deal

with each risk will be carried out (Burke, 1999). During the risk control phase

the risk management plan is executed, Burke (1999) defines that this is the

stage that is most often ignored within IS developments.

The risk management tool can be used as a learning curve for managers.

This can only be done effectively if the plan is updated and monitored on a

regular basis to understand risks that have occurred and to ensure that they

do not occur again (Burke, 1999). Risk control is normally done once risk

identification and analysis has been undertaken. Strategies are used to

implement risk control methods, these methods could include risk avoidance,

sharing, transfer and risk acceptance (Kliem & Ludin, 2000). The strategy that

is used to control these risks will be dependent on the type of risk which

affects the project.

5.3.5 Risk Monitoring

This step involves the tracking of progress towards the resolution of each risk

item. This task must be undertaken on continual basis and the risk should

only be discarded if the mitigation strategy implemented as part of the risk

management process shows that the risk has been reduced to an acceptable

level (Nunes and Annansingh, 2002).

MSc Dissertation 85


Risk identification, analysis, control and risk monitoring are the fundamental

aspects of risk management and should be undertaken in a logical way (Kliem

& Ludin, 2000). However tools have been developed for specific risk

management stages which allow certain stages of the risk management

process to be carried out in isolation, successfully (Frosdick, 1997).

Frosdick, (1997) outlines examples of techniques which have been developed

for the risk identification stage. Examples of such techniques are Failure

Modes and Effects Criticality Analysis (FMECA). This technique follows a

step-by-step procedure for identifying failure modes or design weaknesses

and the criticality of the consequences of failure (Frosdick, 1997). A further

technique specified by Frosdick (1997) is the Fault Tree Analysis which

depicts the way in which a particular system failure might occur.

Wiegers (1998) has defined a risk-monitoring framework which shows the

steps that should be taken to monitor and manage each of the identified risks

(see Figure 13). Within the risk monitoring framework the risk is continually

analysed and prioritised in accordance to its potential impact upon the project

(Wiegers, 1998). Following these steps, strategies to minimise or eliminate

the risk is taken so that the project progress is not hindered.

Figure 13: Risk Monitoring Process

MSc Dissertation 86


The top ten identified risks needs to be highly visible to the project team. Any

mitigation strategies that have been developed should be monitored to define

its effectiveness (Wiegers, 1998). Wiegers (1998) states as the priority risks

are eliminated; new risks may replace these as the priority risks. Therefore

risks are not regarded as being controlled just because the selected mitigation

strategy has been completed thus risk monitoring is a continuous process.

5.4 Risk and Reward

Acceptable levels of risk can be determined using a simple risk assessment

tool such as a risk quadrant. One notable framework has been devised by

Redmill (1991). The least appealing scenario for a systems development

would be when the risk is the greatest and reward is minimal, even due to this

organisations seem fail to notice that their operations expose them to risk with

little reward to compensate them (Sadgrove, 1996).

The risk and reward levels within a project can be assessed using the

following formula:

Risk = Probability occurrence of the incident x Consequence of the incident

To derive a value for risk a numeric value needs to be assigned to the

variables outlined (Redmill, 1991). As well as the numeric approach

qualitative methods can also be used where probability and consequence of

risks can be given a value of either high or low, these values are then placed

on a risk assessment tool. By plotting the figures onto a risk assessment map

will provide an indication of whether the probability is high, medium or low and

whether the consequence of the risk is negligible, medium or catastrophic

(Redmill, 1991).

MSc Dissertation 87


5.5 Risk Management Frameworks

Several IT risk management frameworks have been developed,

Bandyopadhyay et al (1999) identifies a number of authors who have

developed IT risk management frameworks but suggests ‘that they are not

comprehensive in that they only describe a sub set of the four areas of risk

management which are:

Risk identification

Risk Analysis

Risk Reducing Measures

Risk Monitoring

Some frameworks that have been developed by academics encompass Vitale

(1986) who proposes a framework for identifying the strategic risks of IT.

Rainer et al (1991) proposed a risk analysis process for IT combining

qualitative and quantitative methodologies. Furthermore Eloff et al (1993) have

addressed the issue of risk monitoring to ensure effective implementation of

risk control measures. One would presume that the frameworks outlined are

effective for the purposes that they have been developed for. However the

proposed framework developed by Bandyopadhyay et al (1999) focuses upon

all four components of risk management as specified in this thesis and gives

the project manager an understanding of how the four components are

sequentially linked to make up the entire risk management process.

Although what maybe a biased viewpoint, Bandyopadhyay et al (1999)

suggests that their ‘IT risk management framework is an improvement

compared to other approaches as other approaches address one or more of

the risk management components in an isolated manner’. However the

purpose of this framework aims to counter some of the flaws that have been

detected in earlier attempts. This IT Risk Management framework attempts to

address shortfalls identified in academic frameworks that do not cover the

entire risk management process.

MSc Dissertation 88


The four stages of risk management together with the methods and

techniques that should be used to successfully execute each stage of risk

management have been discussed in chapter 5.

5.6 Organisational Levels of Risk Management

Risk management can be undertaken at different levels within the

organisation, these are at an application, organisational and inter-

organisational level (Bandyopadhyay, 1999). Bandyopadhyay (1999) defines

these three levels by stating ‘risk management at the application level focuses

upon the technical risks or the implementation failure of IT applications. These

risks can occur from both internal and external sources’ (See Figure 5).

At the organisational level the focus of risk will be aimed at the impact which IT

will have throughout all functional areas of the organisation rather than on any

isolated applications. Organisations are likely to be susceptible to risks due to

the increasing reliance which they have on IT. Bandyopadhyay (1999)

suggests ‘IS success could eventually contribute to an organisations failure,

this is because as the organisation is already heavily dependent on IT. For the

company to remain competitive they may have to continue investing capital

into cutting edge IT. At this point they may become vulnerable to competitors

who have more resources and may have exploited leading edge technologies

(Bandyopadhyay, 1999).

Within the inter-organisational level many companies operate in a networked

environment where the use of IT enables companies to operate beyond

organisational boundaries (Bandyopadhyay, 1999). Bandyopadhyay (1999)

goes onto suggest that companies who operate within this networked

environment are likely to be faced with both internal and external risks.

MSc Dissertation 89

Chapter Six: Research Methods Ritesh Hira

CChhaapptteerr SSiixx

RReesseeaarrcchh MMeetthhooddss

____________________________________________________________________________________________

6.0 Research Methods

This chapter outlines the process that was carried out in order to undertake

the investigation for this thesis. The chapter will discuss the elements of the

inductive approach that was used, the objectives of this study, the methods

applied together with frameworks that have been used within the dissertation.

Finally this chapter will conclude by examining the limitations of this project

together with any hindrances that occurred whilst undertaking the actual data

collation from the research process.

6.1 Research Strategy

Figure 14 details the steps that have been adopted to undertake the research

strategy for this project. The initial stages of the research strategy begin with

identifying the problems that occurred during the projects development. This

is done using the inductive approach based on a survey method using both

quantitative and qualitative methods. Initially key members of the

development team from the IS department will be interviewed on a one-to-one

basis identifying the problems that occurred during the Informe development

process.

During the interview the comments made by individuals were recorded on

tape solely for the purpose of ease of understanding, for the researcher. The

interviews were also recorded in order to clarify any misunderstandings that

the researcher may have had. In collaboration with the tape recordings, notes

were also made to aid the researchers understanding further. This was

especially the case at certain points during the interview where the

interviewee was informed that if at anytime during the interview they were

MSc Dissertation

90


uncomfortable with what was being communicated or wanted to inform the

researcher of project details off the record then this could be done. At this

point the recording was temporarily paused and discussions continued. It was

continually emphasised during the course of the interviews that comments

made by the individuals would be kept strictly confidential and they would not

be linked to any comments that were made. This was done in order to gain as

much information from the interview as possible and this could only be done if

the interviewee was truthful about what problems took place during the

project. In order to achieve this, the researcher continually re-assured them of

the confidentiality levels that would be up held.

At the end of the interview to ensure that the interviewee was happy with the

information provided, they were asked to sign a consent form which

permission for the researcher to use the information collated during the

interview. This information would then be used in the thesis preparation and

for any other written reports, presentations and published papers that would

be developed based on this research. During this stage all interviewees were

happy with this to take place.

At the same time users who took part in the trial user testing will be identified

Figure 14: Risk Identification and Assessment Framework

Categorise Select Risks

Critical, Acceptable and Unacceptable Risks

Interviews Questionnaires

Risk

Assessment (Frequency,

Impact & Cost)

Identify Risks

Problems

together with other individuals that had some involvement with this IS

development. It will be these people who will be interviewed, either using

questionnaires or focus groups to ensure that all problems, which occurred

MSc Dissertation 91


during development, are either re-enforced or to identify further problems

which the respondents may identify. The initial interviews will form the first

stage of research followed by the questionnaire or focus groups that will

comprise of the second stage of the research process.

Once the first and second stages of the investigation process has been

completed the risks from these projects will be identified using IS specific

frameworks. A separate section detailing the frameworks that were used

within this project will be detailed in section 6.4 [Information Specific

Frameworks]. These risks will be categorised and cognitive maps will be used

to represent, analyse and classify risks in terms of its frequency and potential

impact upon the project. The process described has been summarised in the

diagram represented in Figure 14.

Chapter 1 detailed the reasons behind this study together with the research

question and the objectives this project aims to achieve. To reiterate the

content of this thesis it is worth re-visiting what the objectives of this project

are. The following objectives are expected to be achieved within this project,

these include:

1. Identify and analyse the problems that may have occurred during

the implementation of the Information Systems project.

2. Identify and analyse the causes that may have contributed to

these problems from emerging.

3. Identify and analyse the possible risks that may be associated

with the causes that contributed to the problems occurring.

4. Propose ontology of the identified risks, which are associated with

this type of project.

Once the objectives have been successfully achieved, it is hoped that

the findings from the objectives will help answer the initial research

question that is:

MSc Dissertation 92


“Risk Assessment of Individual Industrial Information Systems Projects: A Case Study.”

Information about the system that has been developed has been documented

in chapter one and therefore will not be re-iterated in this section. For the

readers convenience the research objectives and question has been re-

emphasised in this section.

6.1.1 Interview Strategy

Section 6.1 discussed how the research was undertaken; this section will

provide the reader with an insight into how the interviews were precisely

carried out. As mentioned in earlier sections the interviewees were informed

of confidentiality agreements that were to be upheld throughout the course of

this research project and beyond. Together with this the entire interview would

be recorded although at anytime the interviewee had the right to stop the tape

recording if they were not comfortable with proceedings or wanted to make a

comment of the record.

Prior to the interviews being conducted the key development personnel that

was to be interviewed was identified by senior managers from the

telecommunications company. The individuals that were to be interviewed

during the investigation stage included the Project Manager, Developer,

Systems Development Analyst and Information Technology (IT) Solutions

Manager.

These people identified were regarded as being the most knowledgeable

people in relation to the systems development that has taken place. During

the planning stages of the interview it was planned that the IT Solutions

Manager would be interviewed initially followed by the other identified

individuals. Once this stage of the interview process had been completed the

IT Solutions Manager would be re-interviewed. This was done to clarify and

confirm findings that had been derived during the initial interviews that were

MSc Dissertation 93


conducted with members of the development team. Due to staff availability

and time constraints this was not possible to undertake and therefore the

results are based upon one round of interviews that took place.

It was also proposed during the interviews that field users who were involved

in this systems development would be interviewed using focus groups as the

second stage of the interview process. This was to be done to gain an

understanding of the problems that occurred from a user level allowing a

broader understanding to be achieved about this systems development. This

has not been possible and the reasons behind this have been discussed

within this chapter.

During the actual interview the interviewee was informed of the rationale

behind this project and how this project would be progressed. They were also

informed about the form of information that was required from this interview

and that they should reflect their comments in relation to the IS development

that is being investigated. In order to provide some structure to the interview a

series of interview questions were devised and can be viewed in Appendix 2.

These questions have been devised based on an identified risk identification

framework by Cadle and Yeates (2001). Questions were directed at the

interviewees based on this IS specific framework.

As well as asking questions based on this framework the researcher asked

additional questions to gain an understanding of the interviewees job role, the

department they work in, how IT projects are developed in this department

and how the project in question was developed. Asking such questions

allowed the interviewee to be gradually phased into the actual interview

process. From this stage a definition of risk was defined to the interviewee so

that they could relate this terminology to the problems of the project that was

being discussed.

Following this process questions relating to the problems of the Informe

development were discussed relating the questions asked to the risk

identification framework. To aid deeper understanding of the problems

MSc Dissertation 94


associated with this project, follow-up questions were also asked in addition to

the generic questions that were posed to all interview participants. Once the

interviews had been completed data about the problems, which occurred

during the Informe development, were transcribed.

6.1.2 Case Study Research

This study is based upon the case study approach which enables the capture

of reality in considerably greater detail than is possible compared to other

approaches such as field experiments or surveys (Galliers, 1992). Although

the disadvantage of using the case study approach is that it will be based on a

single project or event and therefore making generalisations from these

individual cases will be difficult (Galliers, 1992).

Case study research is the most common qualitative method used in

information systems (Orlikowski and Baroudi, 1991; Alavi and Carlson, 1992).

Although there are numerous definitions, Yin (1994) defines the scope of a

case study as follows:

A case study is an empirical inquiry that:

Investigates a contemporary phenomenon within its real-life

context, especially when the boundaries between phenomenon

and context are not clearly evident" (Yin, 1994).

Clearly, the case study approach is particularly well suited to IS research,

since the objective of this discipline is the study of information systems in

organisations. "Interest has shifted to organisational rather than technical

issues" (Benbasat et al. 1987). Case study research can be positivist,

interpretive, or critical, depending upon the underlying philosophical

assumptions of the researcher.

MSc Dissertation 95


6.1.3 Information Systems Specific Research

Ackoff (1967) explains the critical examination of Information Systems began

two decades ago. Since then academics have strongly debated as to where

IS research should progress. Academics such as Dearden (1970) has

questioned the ability of IS to improve decision making in organisations. This

assertion proves that the research undertaken up until this time had not

determined exactly what benefits and purpose information systems bought to

the organisation.

Research within IS has focused on a broad area with the theme of cost

benefit analysis being a highly researched area (Galliers, 1992). Together

with this research has moved away from non-empirical work to empirical

studies. The topics of design and management of IS, Human Computer

Interface (HCI) and Decision Support Systems (DSS) have been the popular

research themes that have been conducted.

6.1.4 Information Systems Research Methodologies

IS research has been criticised by academics as being overly conceptual,

lacking rigour and being non-cumulative (Dickson et al, 1980; Turner, 1980;

Keen, 1980). Different research strategies exist but their usefulness in

answering particular questions differ (Galliers, 1992). Alternative research

methods for conducting IS research have been defined, illustrated and

compared by many authors (Galliers, 1992). For instance Van Horn (1973)

has examined the case study, field study, field test and laboratory study

research methods.

As mentioned there are different styles of research which include theoretical

research that focuses on the development and refining issues and

occurrences. Empirical research is concerned with examining events that

occur and then trying to make sense of the observations (Robson, 2002).

MSc Dissertation 96


Before the author looks at the different types of research methods it should be

noted that three styles of research exist, these have been summarised in the

Table 3 below.

Style of research Key characteristics of the research method

Constructive Research Method

Refining the concept of technical development.

Devising conceptual development.

Nomothetic Research method

Focuses on empirical data that searches for general

laws and theories.

Field studies, surveys and experiments.

Formal-mathematical analysis.

Idiographic Research Method Exploring causes or events that provides the richest

picture of what happens.

Case studies and action research is also

undertaken within this style of research.

Table 3 Three broad styles of research (Cornford & Smithson, 1996)

Wetherbe (1999) produced taxonomy of styles of research methods;

analysing published research. This is shown in table 4 below.

Case Studies – involves the in depth exploration of the situation, the data from this research

strategy is rich in knowledge and the data can be obtained from a number of means.

Surveys - This method can be used to provide a picture of affairs at a certain point of time;

this is a basic technique that can be in the form of a questionnaire or interview.

Laboratory experiments - the research activity is carried out in controlled conditions, under

this form of research the researcher will manipulate variables and then observe the results.

Reviews and tutorials - this area of research looks at historical information rather than

forward ideas, doing this will develop a chart of ideas. This is done by the majority of projects

as this method maybe the principal objective of a research project.

Action Research - this approach is also known as collaborative research, this approach is

when the researcher takes part with the development team in order to find the solution rather

than just observing the events that occur. The researcher may work with the development

team however this may only be appropriate if the researcher has a specific skill that can be

offered.

Table 4 – Taxonomy of Research Approaches (Wetherbe, 1999)

MSc Dissertation 97


For the purposes of this research project a combination of the case study and

survey approach will be used, as these approaches are most suitable for the

investigation that is to be carried out.

6.2 Research Method Applied

Section 6.1 outlined the proposed research strategy that is to be used in order

to conduct this project. The instruments that are to be used to collate the data

encompass both primary and secondary data. The primary data will consist of

interviews, questionnaire approach using focus groups consisting of 3-4 field

users, email exchanges and telephone conversations. The secondary sources

shall be derived from examining published documentation relating to the

implemented system such as user, systems and project documentation.

Together with this information sources such as published journals about Risk

Management and case studies where IS developments have failed. These will

be used to analyse the key failure factors which contributed to the systems

failure primarily from a IS project management perspective.

As mentioned the Triangulation Strategy (Robson, 2002) is to be used within

this project in order to gain multiple perspectives of the research namely in the

form of initial interviews and then followed by focus groups. Although this was

proposed at the initial meeting, which took, place between myself and the

telecommunications company when defining the scope for the project. It later

emerged that the second stage of the research process (i.e. focus groups)

would not be feasible to undertake. It should be noted that the author aimed to

interview 3-4 users of the system using focus groups who were involved in the

initial requirements capture process. These Field Users would have been

randomly selected from a sample of 60 although the telecommunications

company did not permit this and the following response to the request was

provided:

“I would love to help you by arranging to put you in contact with a few

of our Field users. But I am afraid the field will not allow for us to take

MSc Dissertation 98


resource out of the work stack for this type of activity. It cannot take place I’m

afraid. Sorry, FS IT Solutions Manager”. [2/7/2003]

As a result of this the dissertation and its findings are based on four interviews

that were conducted at great length and detail between four development staff

and myself. These individuals will not be named in this dissertation and

comments made by the interviewees will not be made identifiable to specific

individuals due to strict confidentiality agreements.

The data was collated using a structured approach where interview questions

were pre-defined and formulated using the criteria from an IS framework

developed by Cadle and Yeates (2001). The details about this framework

have been discussed at length in both chapters Five and Six. A justification as

to why frameworks and this particular framework has been used in this

research project will be detailed in section 6.4.

The four individuals that were selected to undertake the interviews were done

so, prior to consultation with senior managers from the telecommunications

company. It was felt that the people to be used to carry out the data collation

process were regarded as being the most knowledgeable in terms of how

systems development was conducted. Therefore it was felt that these

individuals would be most informed about the problems that occurred with the

Informe development.

6.2.1 Data Collection Methods

Data was collected using the qualitative approach, it had been anticipated that

the quantitative approach (questionnaires) would be carried out in this

research but this has not been feasible due to restrictions in accessibility to

users of this system. Therefore data was collated using the interview

approach together with the analysis of project documentation and published

theory relating to this research area.

MSc Dissertation 99


Using this research method to collect data would have enabled the researcher

to alter the data collection strategy. Here the researcher could have carried

out a number of iterative interviews to clarify misunderstandings and use the

triangulation strategy to check the credibility of the findings (World Bank

Group, 2002). These options have been made available to the researcher if

required proving this method of data collection to be successful. Although this

has not been possible due to restricted accessibility to the system users of

Informe.

6.2.2 Data Analysis Methods

Once the data collection method had been carried out the data had been

analysed using cognitive concept maps. This technique was used to identify

the problems that occurred during the development process and what factors

contributed to these problems occurring. Based upon these problems the

potential risks that occurred during development will be identified. Using these

mapping techniques will also allow for the recommendations, as to how these

risks which occurred within this development could be avoided in similar

projects that are conducted in the future.

Concept maps aims to address the cognitive structures using alternative ways

in order to get a mutual validation with other results from interview

transcriptions that have been derived as a result of the interviews (Fischler &

Peuckert, 2000). A concept map will be devised for each of the interviews

conducted in order to identify the central ideas concerning the topic that is

being investigated.

6.3 Risk Identification Specific Frameworks

This and previous sections have discussed the Risk Identification framework

created by Cadle and Yeates (2001) which has been used within this project

to formulate the interview questions. This framework has also been used as a

method of categorising the problems that occurred within this systems

MSc Dissertation 100


development. Frameworks such as these were used as it provides a rigorous

structure to the way the interview processes is undertaken (May, 2001). In the

context of this research project the framework was used to formulate a series

of interview questions in a logical manner. Further to this the framework that

was used, comprised of Risk Identification criteria which enabled the

researcher to identify risks using a simpler method rather than creating a new

criterion.

The framework devised by Cadle and Yeates (2001) was favoured over

others such as Hughes and Cotterell (1999). This is because the framework

devised by Cadle and Yeates (2001) was regarded as being more

comprehensive as the criterion covered areas such as the customer and

users, technical and systems issues together with project staffing, planning

and resource issues.

During the data collation process it was decided that a broad spectrum of

problems should be identified and the best method to do this would be to use

a framework which addressed a number of possible risk areas. Something

which Cadle and Yeates (2001) framework does.

The Risk Identification criteria specified by Cadle and Yeates (2001) provided

a structure to how the interview format would take place. Initially the interview

comprised of the following steps which were undertaking in a chronological

method:

1. Understanding the department which the interviewee worked in.

2. How Information Technology projects are developed.

3. Information about the Informe project that was developed.

4. Determining whether any formal risk assessment was undertaken prior

to development.

5. Determining the problems/ events, which disrupted the project.

6. Identifying whether risks and problems described in step 5 were

apparent in past projects that were developed.



Steps 1 - 6 detailed above provide an overview of the types of questions that

were posed to the interviewee’s. The questions described in steps 1-6 can be

viewed together with a breakdown of sub-questions in Appendix 2. It should

be noted to aid the researchers understanding additional follow-up questions

were also asked during interviews to clarify any misunderstandings. Although

primarily the major element of the interviews consisted of following a

framework specified in this and earlier sections.

Following the completion of the research process the problems were

categorised and grouped in accordance to the framework by Cadle and

Yeates (2001). At the same time to re-enforce understanding of the problems

that were associated with this development cognitive mapping techniques

were used in order to provide an ontology of identified risks which are

associated with this type of project. The framework that has been used within

this research is discussed extensively in other chapters of this thesis but for

the reader’s knowledge Cadle and Yeates (2001) Risk Identification

framework consists of:

Commercial background [inappropriate/ unclear contracts or business

case unsound]

Contract [work scope not agreed by stakeholders]

Customer [Access to customer staff difficult/ hard to get decisions made,

different customer’s perspectives or commitment levels]

User [lack of commitment, unfamiliar with technology, inadequate user

time spent]

Acceptance [test plans, implementations, was system accepted?]

Functional requirements [completeness, signed-off? too high level, low

level]

Technical requirements [familiarity of hard/software to the developer.

Sufficient technical expertise?]

Performance, availability, maintainability [Did these 3 cause

problems, what was the performance requirement?]

Project plan [was an initial plan created, timescales? Estimates,

Contingency plans, milestones & deliverables defined?]



Developer’s skills [Mgr/ team leader maybe new to the their role]

Project staffing [Staff availability, staff turnover, and inexperienced staff]

Development environment [lack of access to the development

environment, developer inexperience]

Systems software [new/ unproven software, performance overheads]

Tools and methods [Programming language insufficient to project

requirements, unfamiliarity. Standard, method & language maybe

unfamiliar to developers]

Target architecture [hardware maybe new or unproven]

Bought in items/third party [Limited experience of suppliers]

The above criterion is representative of Yeates and Cadle (1996) Risk

Identification framework; a brief description about what each criterion is about

is also discussed above. Although an in depth description is provided in other

sections of this thesis (See Chapter 5.3.3).

6.4 Limitations of the Research Method

Like most research projects the findings of this research may have been

limited by some factors. Although every effort has been made to reduce these

limitations but some still do exist and are detailed in this section.

Questionnaires/ Focus Groups

It has not been possible to undertake the second level of the research

process which would have consisted of undertaking a focus group with a

select number of Field Users who took part in the requirements capture

process. An explanation as to why this occurred has been documented in

section 6.3.

The one-to one interviews that were conducted proved to be highly successful

as it allowed the researcher to plan questions in advance. Further probing

questions were also asked that enabled a deeper understanding to be



achieved of the problems that occurred during the development process. A

consent form was issued to the interview respondents specifying

confidentiality to the information that was provided. Even though this was

done it can be felt that not all information has been derived from the

interviewees due to their reluctance in providing the information. The

researcher had to continually re-emphasise the confidentiality of information

to respondents, stating that this exercise would be useful for their department

and may also bring changes, which would improve their working processes.

Making the use of focus groups would have allowed for familiar problems to

be re-enforced and for new problems to be further identified.

Time

The timescales available for undertaking this research was another limiting

factor which became critical by the geographical distance and diverse

locations between the researchers school and the telecommunications

company. The availability of key development staff caused unforeseen

problems which contributed to timescales becoming ever tighter.

Sample Size

Even though a high degree of information was collated from the four

individuals who took part in the investigation process. It is difficult to

determine whether further interviews with other members of the development

team would have contributed anything further to the research process. The

selected sample however is viewed as being representative for this research

exercise. The key limitation of this particular research is not being able to

have access to the field users of this system whom took part in the

requirements collation.


Chapter Seven: Analysis of Data Ritesh Hira

CChhaapptteerr SSeevveenn

AAnnaallyyssiiss ooff DDaattaa

__________________________________________________________________________________________

7.0 Analysis of Data Chapter 6 described the methods that were used to collate the data and the

methods that were used to analyse the data which was collated for this

research project. To re-emphasise the use of cognitive maps in the form of

concept maps were used to analyse the information. The data collated was

analysed to identify the various problems which occurred throughout the

project and the events, which contributed, to these problems occurring. Based

on this an assessment, the risks which occurred during development will be

defined. This section will present an analysis of the data that was collated.

The four interviews that were carried out will each be analysed in-depth within

this chapter identifying the problems, events and risks of the project. At the

end of each interview analysis a summary of the problems, events and risks

will be given and the chapter will be concluded with a summary of the

problems which took place within this project based on the analysis of all four

interviews.

7.1 The Empirical Study

One to one interviews were used for the investigations of this study. It was

proposed that the interviews would form the first part of the research process

where select members of those extensively involved with the Informe

development would be interviewed. Following this part of the research

process, focus groups were to take place with a randomly number of selected

system users [three individuals] who would be asked questions based on their

views of the Informe development process. It was not possible to undertake

the latter part of this research process due the restrictions that were placed

MSc Dissertation

105


upon this project by the telecommunications company as the project was

being investigated. An explanation as to the reasons why the second phase of

this project was not possible is given in Chapter Six.

The research as mentioned was conducted by carrying out four extensive

interviews with key members of the development team. These people were

regarded as being the most knowledgeable people in relation to how the

systems development was carried out and the problems that this project

faced. Different viewpoints have been obtained within the interviews from a

development, management and analytical perspective that have provided in

depth accounts of the issues which have faced this project. The interview

questions that were asked can be viewed in Appendix 2.

The questions that were asked in each of the interviews were formulated

using literature on Risk, Information Systems, Risk Identification frameworks,

Project Management and IS project failures. The research undertaken was to

study the problems that occurred during the IS project that has been carried

out by the telecommunications company. Identifying the potential risks that

could have occurred within this development due to the problems arising and

the impact of these risks will be assessed within this investigation. The study

area described contributed to the research objectives of this project. The

overall objective for this project is to assess the contributing risk factors of this

type of industrial IS project.

This chapter will examine each of the interviews that have been carried out

and will detail the problems which occurred from the viewpoint of the four

interviewees. This chapter will follow an in depth analysis of the interviews

with a summary of the problems which impacted the Informe development

together with a cross analysis of what each interviewees perception was of

the problems which occurred.

Due to confidentiality issues this section of the thesis will identify the

individuals that were interviews solely as Interview 1, Interview 2 etc. A

transcription of the interviews can be seen Appendix 3 - 6.



7.2 Informe Development Problems – Interview One

Informe Project Risks

Project failure

Lack of communicationswith client

Not clear what the benefitsof Informe are

No cost/ benefit analysisundertaken

User resistance

Inadequate understanding ofrequirements, Developed system not in line

with user expectations

Cost

Work allocationdone verballyQuality

User resistance

Low levels of IT literacyin the organisation

Users not willing to work withthe technology

No formal record of whowas doing what

Limited representation of usersin the requirements collation

process

System does not representrequirement of the field

Time User resistance

User felt that thesystem was to close their

department down

Project had serious organisationalimpact

Not decided as towhat requirements would be

delivered in each version

Inadequate implementation plans

User Resistance

Functional requirementsnot clear

Developed system not in linewith user expectations

No version control

User resistance

System continually changing

Functional Requirements notsigned-off

Impossible to compare systemrequirements to implemented system

Success/ failure of systemcan be determined

Development agendas

Additional requirements weredelivered when not asked for

TimeUser resistance

Cost

No Project Manager

Time

Development notbeing overseen

Lack of clear Project Plan

Development progress notbeing controlled

Infrequent Communications

Communications done mainly by telephoneconferences every three weeks

Limited reporting

Time

No considerationof risk

Time

Unanticipated problems willdirectly effect the project

Lack of clearrequirement sign off

Time

Wrong solutiondeveloped

Limited knowledge ofmethods used

Quality

Project developed withlimited structure

Cost

Quality

Cost

Cost

Time

Cost

Cost

Time

Quality

Time

Time

Informe Project

Problems

Events

Risk

Key

Chart 1 - Concept Map of Interview One Project Risks



It has been identified from this interview that the following problems occurred

during development:

7.2.1 Development Agendas

Members of the development team had personal development agendas

where additional requirements were delivered when they were not asked for

by the users. The interview respondent stated that the development team felt

that users would require additional requirements that had not been requested

(see Chart 1). The risk incurred here is that user resistance may have

occurred as users would have seen things in the system that they did request

for which in turn would have had impacts on time and cost. Due to the

additional requirements being provided the development time and cost would

have increased. The researcher has been informed that no costs are incurred

within the team until external resource is requested, external to the

department. Although costs would still be incurred in terms of developer’s

wages and therefore as additional development time is taken up whilst

delivering extra requirements, so will development costs.

7.2.2 Functional Requirements

During the project there was a lack of communications with the client of

Informe. In this case the client was a senior manager who were used in order

to understand what their requirements of the system were. Due to the lack of

communications, which took place, the functional requirements were not

understood adequately and a system was developed which was not in line

with user expectations. The impacts of this problem is that the users would

not be willing to use the system as it was not what they asked for and

therefore the developers time and cost would have been incurred as time

would have been wasted developing a system that was not required. Due to

this a 3-4 month time delay occurred with the re-working of Informe, this

disappointed the development team and client as delays also had impacts

upon the initial trial release.



A further problem that contributed towards the 3-4 month time delay, which

resulted in re-working of the Informe project, was also down to the functional

requirements not being signed-off prior to development. Had this been done

then both the client and development team would have had a contract stating

what requirements would be implemented within this systems development.

As this was not done cost and time overruns would have occurred, as re-

working the system in line with what the client actually required, needed to be

done. Due to this factor a risk that the development team took was that the

success or failure of development can be determined. In this case, this

particular Informe version was deemed a failure as the client rejected the

system due to it not meeting their initial requirements.

Analysing the data collated, it would seem that the client was only consulted

during the initial requirements capture in June 2002. This was done early on

and from there on users were not consulted as to whether the requirements

collated were what they required or if they required the system to do anything

further. These requirements related problems all contributed to significant re-

working as limited user communications and no formal requirements sign-off

took place during the Informe development.

As a result of the requirement gathering related problems users are now

consulted to a greater degree and formal requirements sign off is undertaken

prior to development being carried out.

7.2.3 Project Management

No formal project manager was appointed to oversee the Informe

development from the beginning of the project. This individual was only

appointed five months into the project and therefore prior to the project

manager’s appointment development was not being overseen in a formal

project management perspective. Due to this time and costs estimations

would not have been made at the beginning of the project but only when a

project manager had been assigned. This would have been problematic, as



the project would have had to be reviewed to assess how much time and

resource had already been allocated to the development prior to the plan

being developed and how much time and resource would now be required.

Logically as no project manager was involved from the beginning of the

project nor was a project plan created for which the development team could

work on in terms of achieving milestones, deliverables and project targets. No

formal monitoring process was being conducted, as project plans were not in

existence. This would have had implications on time and project costs, as

they would not have been controlled in any formal project plans. A project

manager was appointed 5 months into the project and this is when a formal

project plan was created. However the interview respondent stated that the

development team were not communicated this information when the plan

had been drafted. This would further suggest that the development team

would not have been informed of when deadlines and milestones were due at

the very outset when the project plan was created.

The Informe development experienced user resistance primarily due to the

lack of communications between developers and with customers. The user

requirements that were delivered were not in line with user expectations.

Although it was also not agreed with the users as to which requirements

would be implemented in the different versions of Informe as inadequacies

remained with the implementation plans. As users were not aware of what

was to be delivered this would have led resistance due to the lack of

communications which also took place between the development team and

the client.

The Informe development was developed with limited structure as no

development methodology is used within this department and was used for

the Informe development. Due to the limited use of methods within

development the quality levels of development would be hindered, as different

developers would be using their own methods in order to develop Informe.

This had caused inconsistencies with the application environment as different

methods are and were used by the development team in order to create the



system. This resulted in extensive re-working needing to be done as

inconsistencies occurred due to developers using different methods to create

Informe.

As mentioned developers do use different methods in order to create systems

although the interview respondent was not aware that any development

methodology was used within the department or within projects. This would

re-enforce that IS developments are carried out in an inconsistent manner

within the development team.

7.2.4 Organisational Issues

User resistance was a key problem and a risk that was taken during the

Informe development as users of the system felt that Informe was to close

their department down. The interviewee informed that the thought process

regarding the benefits of Informe were not in place and this caused some

resentment towards Informe. This would have resulted in user resistance

occurring due to the fact that they would not have been informed fully as to

why the concept of Informe had arisen and what benefits it had. If the benefits

of Informe had been introduced to the users through continuous active

communication then mistrust towards this system would have been

eradicated.

A further contributor to the issue of user resistance is that not all users of

Informe were IT literate in that different levels of IT literacy existed within the

organisation. Due to this factor users would not be willing to use this

technology as they had only been introduced with Laptop computer

technology and would be trying to learn this technology. The timing of

introducing Informe was inappropriate as users were learning one technology

and another technology was being given to them which resulted in user

resistance occurring.



Prior to the development of Informe commencing no formal cost benefit

analysis was undertaken by the development team or management. This

should have been done to identify whether the benefits of this development

were worthwhile and whether it outweighed the cost and time implications of

such development. As there was no clear vision at the initial stages as to what

benefits Informe would bring, the development was at risk from being a failure

from the outset. This is because the benefits had not been presented and

therefore users were not willing to get involved with the system.

Furthermore without formal analysis taking place in terms of cost benefits it

would have been difficult to identify whether the benefits had been achieved

within the implemented system. If a cost benefit analysis had been

undertaken then the risk of project failure would have been reduced as

management would have identified the benefits of this system if there were

any and could have formally decided to pursue or stop the project going

ahead.

7.2.5 Systems Development

The developed version of Informe was continually changing, this was a result

of Informe being continually tweaked and changed. The new version releases

were also based upon the requirement changes that took place. As new

versions of Informe was continually being introduced to users the risk of user

resistance occurring would have increased because users would have had to

learn new features of the system continually. But the major reason as to why

different versions were being implemented was due to the requirements not

being fully understood. Therefore the development team would have

implemented the wrong system which was not in line with user expectations,

this would have frustrated key users causing resentment towards the system.

A key problem, which occurred within the development team, was that

communications and face-to-face communications were infrequent as the

development was spread geographically. Team meetings were mainly



conducted using conference calls every 3 weeks which would have caused

problems as development issues would not have been cleared up instantly

causing the risk of time delays to occur to the project. Together with this the

limited reporting of the projects progress would have resulted in the

development team and project manager not being aware of how development

was progressing both in terms of time and resource.

The limited face to face contact which the team was experiencing meant that

no formal records existed as to what work was being allocated to which team

member as this was done verbally. The key problem here is that team

members could have changed their minds as to what was required after the

work had been allocated resulting in risks such as quality and time factors to

occur. Time overruns would have occurred as developers had to undertake

re-working, as development instructions were not always understood resulting

in the wrong work being carried out.

The quality levels of the way this project was developed would have also been

low as formal methods of communication and task allocation was minimal

throughout development. This led to members of the development team doing

what they thought was correct even though development instructions

contradicted this.

7.2.6 Risk Consideration

During this interview it was outlined that no risk assessment was undertaken

prior to the Informe development but it may have been done so sub-

consciously. Due to the limited risk considerations that took place any

problems that may have affected the project, would not have been

anticipated. This would have resulted in additional cost and time slippages to

occur, as risks, which should have been identified, had not. If these risks

occurred then re-planning may have been required to deal with the impacts

that may arise. The quality levels of how development had progressed would



also remain low, as no formal process would have been followed to undertake

development.

7.2.7 Interview Summary

The lack of communications with the client and the requirements not being

signed off or being clear was the key contributors to the problems

experienced during the Informe development. IS development methods,

project management techniques and limited cost benefit analysis being

undertaken is key problem areas which occurred from this interviewee’s point

of view.

7.3 Informe Development Problems – Interview Two

The second interview conducted identified the following problems which

occurred during the Informe development (See Chart 2). It should be noted

that some of the problems that may be detailed in this section might resemble

the problems that were identified in interview 1.


The functional requirements that are collated from users were not done to a

detailed standard during the Informe development. The interview respondents

outlined that developers would go to the customer and collate the

requirements from them. The requirements would then be “written on a bit of

paper, no documentation”. The collation of requirements for the Informe

system had not gone into significant detail for example “I want a pre figure

report” was as detailed as it got. The interview respondent felt that the detail

of these requirements was too high level and not understandable.




Functional Requirementsnot signed off by customers

Users reject system as itsnot what they asked for

Time

No FormalSpecification

Difficult to assess final systemagainst requirements documents

Success or failure dependenton this factor

Additional RequirementsRequested

Additional stakeholders identifiedresulting in more requirements

being requested, system became morecomplex

Time

Requirements notdetailed enough

Requirements not collatedfrom users adequately, system

not in linewith user expectations

Time

Different user levels notinformed of the system

User feedback as to theusefulness of the system

not understood.

User resistance

No Formal Testing

Users see errors with the system,expect it to be bug free

User Resistance

No Development Plans

Plans as to which requirementsare to be implementedare not documented

ProjectFailure

Project Failure

No specisliasedAnalysis Staff

Inadequate requirementscollation

Cost

User resistance

Systems PerformanceProblems

Lack of Systems ScalabilityPlanning

User resistance

No project plan

Important stage of projectmanagement missed out

No monitoring strategy

No Schedule

Development rushedthrough

Quality

Time

No set deadline Staff use guestimateas to when they can deliver

No formal estimation

Staff pressure

Deadlines slip Staff pressure

No formal reporting structure Staff isolation/ low morale

Development staff do notcommunicate progress

Lack of communications Exact project statusnot known Time

No System specification

Difficult to define what hasbeen delivered in the system

Development carried out on twodifferent versions of the same system

Duplicate work

Time

No FormalMethodology used

Development process taking longer tocomplete

Quality

Limited consideration ofadopted development method QualityNot all developers

use same method

Development & user environmentdiffer

Resistance

Users unhappy withperformance of the system

No considertaionof risk

TimeUnanticipated problems will

directly effect the project

User resistance

User Resistance

Quality

Qulaity

Project Failure UserResistance

Quality

Cost

Cost

Cost

Time

Time

Staff pressure

Time

Cost

Informe Project

Problems

Events

Risk

Key

Chart 2 - Concept Map of Interview Two Project Risks

The requirements capture caused significant problems which resulted in

extensive re-working needing to take place as the requirements that were

collated were not in line with user expectations. The interview respondent

stated



“the requirements collation has not worked well with Informe as people don’t

know what they want, so they don’t get it”.

An instance where this problem occurred was that users would state that they

want a messaging system and that is all the state in the requirement which is

then produced. When this is presented to the user, it is then discovered that

this is not something they required suggesting that the requirements were not

fully understood or exploited by the development team.

The risks, which the development team took when not detailing the

requirements clearly, enough is that users would not be willing to use the

system [User Resistance], as the system will not be in line with user

expectations. This will lead additional time lapses to occur to the project as

additional time would be required to re-work and re-collate the user

requirements from users in an attempt to re-deliver a system which is

required. A further risk that is associated with this problem is that project

failure could have occurred because if the requirements are not fully

understood then the wrong system will be delivered to the user which will

result in systems rejection. Analysing the data collated suggests that this is

exactly what occurred with this part of systems development.

As mentioned it is apparent that the requirements were not fully understood

although these misunderstandings could have been confirmed had the

requirements been signed-off with the user and client. This was never the

case with Informe although it should be noted that the functional requirements

are signed-off and checked with the clients now. As the functional

requirements were not signed off the system would be rejected, as it is not

what they asked for. This was the case with Informe and therefore risks such

as time and cost slippages would have occurred. Together with this as

mentioned in previous paragraphs users would not be willing to use the

system and there is a high chance the system could fail in light of the

requirements not being understood or signed-off.



An explanation as to why action was not taken to check the accuracy of the

requirements with users may lie with the fact that additional user requirements

were requested once the requirements capture had been completed.

Timescales were shortened as deadlines had to be met with additional

requirements having to be implemented without timescales being re-

negotiated. These factors placed undue pressure on staff which they have

had to cope with as the interview respondent stated that

“we don’t want to be seen as failing or not meeting the timescales”.

In light of this Quality risks may have occurred as the development team may

have used less formal methods in order to develop the system within the tight

timescales specified. Examples of this could include not obtaining formal sign

off, of user requirements as staff pressures to deliver on time would preside

which can be classed as a risk as the way the system is developed may

cause the wrong system to be delivered. This will contribute to additional time

and costs being incurred for the project, as re-working would be required.

The interview respondent felt the requirements capture was not done

comprehensively. Analysing the data suggests that the requirements were

collated at a high level which were not analysed formally to identify if the

requirements had any cost benefits associated to them. Due to the limited

formal process that was used to collate the requirements no formal system

specification was developed or maintained to reflect what the delivered

system consisted of. This document if developed would have formed a

contract between the development team and the client stating what is to be

delivered within this system so that there is no confusion between either

party’s when the final system is delivered. This will reduce the risk of user

resistance occurring which is evident within this development as inaccurate

requirements were delivered in a system that was rejected by the client.

The developers are also responsible for collating the user requirements from

users. As a result no specialised analysis staff are used within the

requirements collation as developers are expected to take on a dual role of



both developer and analyst. The dual role taken on by the development team

has been regarded as being problematic as the requirements collated have

been inadequate. The respondent emphasised that the customer will ask for a

number of requirements which are developed, they then mention a series of

further requirements which are also developed. This process will impact the

timescales and costs of the project as more time will be taken up getting the

requirements correct, as developers may not have the specific skills in order

to conduct such a demanding role. This was expressed by the respondent

who stated that the role of developer and analyst should be separate in order

to make development more successful.

7.3.2 Development Plans

The development plans, which should have been used as a basis to develop

Informe upon, were not documented in any manner. Any documentation

created would have allowed the user and client to determine what was to be

implemented within the system, however this was not the case. It should be

noted that development plans were created using unconventional methods

where the interview respondent stated that

“development plans are created in my head, not documented”.

This problem would have ultimately led to the possibility of project failure

occurring as the wrong system could have been developed leading to users

resisting to operate the system.

Quality, Time and Cost risks were significantly present within the Informe

development as no formal methodology was used in order to create Informe.

Using formal methods would allow for the project to achieve a degree of

structure, which allows the chances of successful systems development to be

delivered within the timescales, and budgets set. As no development methods

were used within this project development would have taken longer to

complete. The interview respondent provided an explanation as to why the



development team did not want to use development methods, this was

because:

“We do not use methods as we don’t want the rigid structures and processes

or boundaries; we want to fiddle about with the program as to how users want

it. Developers then go back and fiddle about with it some more and so on. We

then go to the customer and then adjust it further which I think is a more fun

way to do it this way.”

This quote provided by the interview respondent suggests that timescales and

costs to the project can escalate as processes are not followed which would

result in development not being carried out successfully first time round. Using

informal processes could lead to overruns as the development team may

spend more time continually adjusting the system when one iteration may

suffice.


Interview 1 informed that no project plans were created until the latter stages

of development where a project manager had only been appointed 3-4

months into the project. This view was also shared by this interview

respondent who stated that no deadlines were set, estimation was not carried

out and that the development team had no project plans to assess their

progress against. No deadlines were set within the Informe project.

The interview respondent stated the estimation that was adopted within the

development team consisted of the “rule of thumb” approach where “if asked

by management I will come up with a figure out of my head, I don’t follow any

planning procedures in order to come up with this date”. “This method has

caused extreme staff pressure as to meet deadlines we have to cut corners in

order to rush development through. Parts of the messaging system were not

fully specified which resulted in 2-3 attempts being made to this system hence

extensive re-working was required during development”.



The risk of staff pressure occurred as limited processes had been used to

determine when parts of the project could be. Therefore development has to

be rushed through, as the planning process of when the project could be

realistically delivered is not undertaken resulting in corners being cut during

development. The interview respondent informed that there is no deadline

date due to limited formal processes being used. Instead “three deadline

dates for example in the Informe Version 2 project, we have the best date, the

real date and the fail sort of date to work to”. To enforce the point relating to

estimation and deadlines, this could not have been possibly done effectively

without a project plan being created by the project manager. A project plan

was only developed 4-5 months into the project and this is a factor as to why

no formal estimation or deadline date was enforced upon the project causing

development to be rushed through.

The quality levels as to which the project should have been developed by

would have been minimal as limited control would have been in place to guide

how the project should be developed. Instead development was undertaken

with minimal control which would have resulted in corners being cut by the

development team reducing the overall quality levels.

During the analysis process it has been identified that the limited reporting

structure and lack of communications between the development team

members was a significant problem. The respondent informed:

“we didn’t communicate well at all as a team, the individuals of the team are

not very good communicators, and this is because egos are involved where

we are not prepared to listen to others point of view. We don’t talk to one

another within the team well because the development team are spread

around the country”.

Due to this problem the development team would not be aware exactly how

the project is progressing which may result timescales slipping, as team

members would not be aware of where development is. The limited status

reporting to management would lead to the risk of staff isolation/ low morale



occurring within the team. This may cause a degree of staff de-motivation to

occur where team members may not be willing to complete the work which

would lead to time slippages.

7.3.4 Systems Development

The limited use of formal processes within this development is evident in the

testing stage where no formal testing is carried out on the system prior to it

being implemented. Any testing which needs to be done is done when the

user comes face to face with the system. The user expects the system to be

error free and if any bugs are detected then these need to be repaired within

this particular version. The risks posed at this stage include Resistance, as

errors in the system will dissuade users from using the system which will lead

to additional time being needed to rectify the problems that are detected with

the present system.

The software and hardware that was used to develop Informe upon was not

planned to identify whether it would operate upon the demands placed on it.

More and more queries and functions were placed upon the system due to

user, internal and management feedback. As no formal planning was carried

out to examine the scalability of the Informe system performance problems

occurred where the system had to be redesigned and re-coded to make sure

these performance problems were removed. This problem would have

impacted the timescales of the project, as additional time would have been

needed to rectify these unperceived problems which occurred. The

performance problems which occurred would have generated some

resistance to Informe as users would not be willing to use the system due to

its associated problems.

The performance problems mentioned could be associated with the fact that

the development and user environment was different in that development was

carried in an environment that was different to the user’s environment. This

was not viewed as a problem initially but it is likely that the system developed



may not operate fully in the user environment causing user resistance

problems, as the developed version would differ operationally in the users

environment.

The quality levels of system development would have been poor as the

development methodology used for Informe was neither inconsistent between

developers nor is one universal methodology standard used within this

department. Due to this problem, additional time would be used to re-work the

application so that it fits in together with the way developers develop the

system. The inconsistencies with the development method have also caused

problems with the system itself, which would have affected its quality, and the

timescales which it is developed within.

7.3.5 Risk Consideration

During this interview it was outlined that no risk assessment was undertaken

prior to the Informe development. Due to the limited risk considerations that

took place any problems that may have affected the project would not have

been anticipated resulting in additional cost and time slippages to occur as

risks, which should have been identified, had not. If these risks occurred then

re-planning may have been required to deal with any risk occurrences that

may arise. The quality of how development had progressed would also remain

low during the project, as no formal process would have been followed to

undertake development with.


The requirements not being detailed enough or signed off by the client were

the key problems defined by this interviewee. Furthermore during this

development no formal specification was developed aiding the understanding

of the systems functional specification for the developer. This interviewee felt

the limited use of formal procedures like testing, estimation, system



development methodologies and project management techniques further

contributed to the problems that affected this development project.

Technical aspects such Informe being developed on a different environment

to the user’s environment and no specialist analysis staff existing within this

department affected the project. The interview respondent felt that members

of team did not have the skills to equip them to carry out the role of analysis

and developer in combination. It was felt that this was one of the reasons as

to why developers had to keep going back to the user to define and

understand the requirements which were not fully understood initially.

7.4 Informe Development Problems – Interview Three

Chart 3 provides the results to the analysis that was undertaken in order to

identify the events which led to the various problems which occurred during

the Informe project. The problems to be outlined in this section are viewpoints

from a management perspective.



Co

y


No Formal CostBenefit Analysis

Difficult to define whether the finalsystem is cost effective

and beneficial

User resistanceTime

Informe not onmanagementobjectives

Client not aware of keydevelopment stages, don’t feel

ownership

User resistance

Lack of usercommunications

Limited involvementof client/ management

Limited Project Managementinvolvement

Important element of projectmanagement overlooked

No monitoringstrategy

Difficult to identify ifproject has met its objectives

Time

Limited clarification of requirementsbefore development (PRD / CRD)

Difficult to determine systemscope against requirement

Success/ failure of finalsystem can be based upon

this factor

Project team notaware of development

status

Cannot define whetherproject is meeting objectives

Cost

No formal requirementssign-off

Inadequate requirementsdefined

User resistanceSuccess or failurewill be dependentupon this factor

No deadline date, milestonestimescales

No monitoringstrategy

Difficult to identify ifproject has met its objectives

Cost

Limited Project Managementdocumentation

Managers cannot evaluate howdevelopment has or is progressing

Project schedules not carriedout comprehensively

Cost

No Business Caseundertaken

Decision not formally madeby management whether

Informe should be developed

Project Failure

Guess on project status

Tine

Internal Politics

No formal processfollowedImportant stage

of project managementignored

Project team unable to learnfrom the present project

Quality

st

QualityQuality

Quality

Quality

Cost

Cost

Cost

Time

User Resistance

Cost

Project Failure

Staff Pressure TimeTime

Time

Time

Informe Project

Problems

Events

Ris

Ke

Chart 3 - Concept Map of Interview Three Project Risks

k

7.4.1 Management Support

Prior to the Informe project being commenced it is evident that a limited

amount of formal process was used. An example of this is that no cost benefit

analysis or business case was presented to senior management explaining

what benefit this system would have to the organisation. As a result the

interview respondent stated that managers from other departments were not

willing to get involved with this project as no business case had been

developed. These two events would have contributed to User Resistance



taking place, as people would not be willing to get involved with the project.

The Time and Cost risk factors would have occurred automatically due to no

cost benefit analysis being defined. The Cost and especially the Time factors

of the project would not have been realised leading to cost and time overruns

to occur which would have further dissuaded users from using the system.

For a project to be successful senior management support needs to be

achieved at the outset although within the Informe development this was not

the case as this development was not part of management objectives. This

may have been due to senior managements perception of Informe being less

important compared to other developments that were to take place. As limited

client involvement occurred during the development they would not have been

aware of projects status increasing the likelihood of user resistance. Users

would also not be willing to use the system as they would have seen that

management are not involved with this development influencing their decision

not to be committed to the system as well.

The limited management support could have initiated the risk of the system

failing as without their support the system would not have been introduced to

the organisation. Had this occurred then the system would have to been

abandoned causing the time spent of this project to be wasted.


A project manager for the Informe development was appointed 4-5 months

into the project, prior to this no formal project manager had been involved with

this project. The major problem, which took place here, is that if any problems

occurred then a project manager would not be available to push things along.

For a period of time the project was being developed with limited or no formal

project monitoring taken place and it would have been difficult to assess

whether the project was meeting its objectives as no plans would have been

developed in the first instance.



The quality of this development would have been low, as development would

have been carried out with minimal structure and process being carried out.

Time and costs would have also escalated as limited project management

involvement would have caused time and cost to slip as these variables would

not have been monitored.

No project manager was involved within this systems development at the

projects initiation resulted in limited documentation being created causing

problems when trying to assess how the project had been progressing or was

progressing. Understanding the project without documentation would have

proved further difficult for an individual who is trying to manage the project

and who has limited knowledge of what has occurred within the project to

date.

Limited information on the projects progress would have made it difficult for

the manager to plan the remaining development process, as they would not

know what has taken place so far. As the newly appointed project manager is

gaining an understanding of the project, slippages could occur in the form of

time and cost. This is because the project managers scheduling may not be

accurate due to the limited information that they have been provided with. The

interviewee re-emphasises this analysis as:

“the project had a blurred vision of what we perceived the solution to be, the

project was well on its way by the time I got involved and thereupon we were

playing catch up”.

This statement indicates that staff pressure would have occurred during the

project, as development staff would continually be playing catch up with the

project causing unforced errors to occur. Due to the shortfalls of evaluating

the projects progress due to the limited documentation would have forced

project managers to guess on the projects status. Guessing the projects

status would have caused significant problems as the development team

would not have known if the project was on track or not. If development was

not on track then action might not have been taken until the problem had



escalated impacting timescales and costs of the project. Furthermore

guessing the projects status would have fabricated the projects true status

and would have presented a status report that is not reflective of the projects

development.

Guessing the projects status also took place as the project team itself was not

aware of the developments status and therefore it was difficult to define

whether the project was meeting its objectives. Due to this it would have been

difficult to assess whether the project was on schedule and whether it was

meeting its milestones, as the team did not know precisely at what stage

development was. The lack of communications within the development team

could be classed as a key contributor as to why the projects status was not

known by team members.

Internal politics within the development team escalated and caused a lack of

communications within the team which would have affected the developments

progress in terms of time and possible project failure, as problems would have

escalated remaining unresolved. The escalation of problems may have also

brought a delay to timescales as management would not have been aware of

them and therefore they would not have been able to act to resolve issues

due to the lack of communications.

Deadline dates, milestones or timescales were not set for this project and

therefore not having such dates in place will have been difficult to determine

whether the project was meeting its objectives as overall objectives were

limited. As dates were not enforced upon the project from the outset informal

processes would have had to be taken where pressure on staff to deliver

quickly would have required. Working to known set deadlines would have

controlled development as the team would know what their targets are but in

this case the risks posed as a result of this problem occurring is that

timescales could have overrun due to limited deadlines and milestones being

set.




The requirements collation process did not follow any formal process where

requirements were not defined using Project Requirements Definition (PRD)

or Client Requirements Definition (CRD) documents. Due to the limited use of

these formal documents it was difficult to assess whether the systems scope

was met by the requirements. An apparent risk here is that the success or

failure of a project can be determined based on whether the requirements

have been understood and implemented within the systems development, as

the user requires.

If the requirements have not been understood then what has been understood

can be confirmed by asking the user or client to sign off the requirements

indicating that they are happy with the implementation of the defined

requirements. If this is done then the risk of user resistance or the project

failing due inadequate requirements being defined will be reduced. This was

not the case and formal requirements sign-off was not achieved resulting in

the wrong requirements being developed within the Informe system.

7.4.4 Formal Processes

During the development process no formal process were being followed and

therefore an important stage of project management was not being followed

within this project. The interviewee stated that it was felt that “processes were

not being used to deliver the technology but the technology was driving the

process”. The limited use of processes would have led to a system being

developed that was being pursued using inferior quality methods. Cost and

time resource would have escalated, as the structure of development would

have been wayward. Timescales and resources could have been better

planned accurately had processes been used providing an accurate picture of

what Informe activity required.




The three key problem areas, which occurred within this development, were

that a lack of communications took place between the development team and

the client and user. Customer communication was done mainly at workshops

where requirements collation was done early on and these requirements were

not then re-checked with the customer to ensure that they were accurate and

what they required.

No formal process or structure was applied to the development and therefore

the project was pursed using limited methods and processes. Finally the

limited communications within the development team contributed to the

project status not being known at all times.

7.5 Informe Development Problems – Interview Four

Chart 4 provides the results of the analysis that was undertaken in order to

identify the events which led to the various problems which occurred during

the Informe project. The problems to be outlined in this section are the

viewpoints from a management perspective.

7.5.1 Management Involvement

A key problem as mentioned in previous sections of this chapter is that no

formal cost benefit analysis was undertaken. Although the interview

respondent stated “most costs are absorbed within the team and it is not until

I talk to another line of business where they may need to alter their system to

work with the developed system. This is when costs will begin to occur”.



Time Quality


No Formal Cost Benefit Analysis

Difficult to define whether the finalsystem is cost effective

and beneficial

User resistance

Cost

Limited involvement ofsenior management

Senior management buy in maynot be achieved

Project Failure

No formalconsideration of risk

Cost


Un-comprehensive trainingplan

Field engineers unable to undertaketraining at specified time

TimeUser resistance

Technical skill level ofusers limited

Engineers notaware technically

User Resistance

Not all users trained withInforme

Users don’t understandsystem

User resistance

Internal Politics Management not willing toembrace Informe idea

Cost

Inadequate implementationPlan

System implemented to userswhilst they were learning

laptop technologyUser resistance

Cost

No formal requirementssign-off

Inadequate requirementsdefined

User resistance

Success or failurewill be dependentupon this factor

Inadequate Systemspecification

Development changesun-recorded does not relate

to final system

User resistance

User problems notdocumentedSame problems re-occur

Tim

No Schedules

Staff are put underpressure

to meet deadlines

No timescales, deliverables& milestones developed

at the projectimplementationProject Plan

developed lateCost

Internal politics

Failure to agree adequatetimescales for development

InadequateCommunications

Team members not awareof project status

Time

No deadline date

Development teamgeographically spread

Team membershave different work

commitments to projects

Key members of the teamtemporarily leave to do other

projects or suffer work overload

Informe Project

Problems

Events

Risk

Key

Quality

Staff Pressure

Time

Cost

Quality

Time Quality

Time

Time

Cost

Chart 4 - Concept Map of Interview Four Project Risks

e

It can be acknowledged that costs maybe absorbed within the team but costs

in terms of developer times, wages will be experienced. Together with this

and the benefits of the system, these need to be realised to determine

whether development should, progress. This was not done in the case of

Informe leading to risks such as user resistance occurring as users would not

be convinced as to what actual benefits the system would bring.

Unanticipated time and costs overruns may occur that may not have been

planned for leading to surprises occurring within the project.



The involvement of senior management was not fully achieved at the

beginning of the project, as they were not willing to embrace the Informe

system. The lack of management involvement at the beginning of the project

could have led to the project failing as for the project to be successful, senior

management involvement is needed. Time and costs overruns would have

occurred at this stage as 6 months had passed during the time it took to get

people to accept Informe. Although the interview respondent stated

“schedules are non-existent until senior management involvement is

achieved”. This maybe the case but the fact remains that timescales have

slipped during the time when attempts were being made to gain management

support. Had management support been achieved earlier then development

would have moved quickly than experienced.

7.5.2 Informe Systems Implementation

The training of users was done at a high level where 60 people who

participated in focus groups were trained within the systems operation. The

individuals who took part in the focus groups consisted of managers who were

then responsible in training their staff. A critical problem that occurred here is

that the quality of training delivered to managers may not have been adequate

for them to train their staff within Informe. It maybe possible, that not all

training will have been communicated to the users. This would have led to

user resistance occurring, as they may not be knowledgeable with parts of the

system dissuading them to use Informe.

The way the training was delivered would have contributed to user problems

occurring. These problems would have been dealt with at the time of

notification but these problems were not documented so that they could be

fixed in latter versions of Informe. If the problems re-occurred time would be

required to deal with the problems, which could have been completely dealt

with, when it was initially raised. Users would not be willing to use the system

if these problems re-occurred and therefore a Problem Log would assist in

reducing the system related problems which initially took place.



The training plans that had been developed did not consider the potential

risks which may affect the plans that were created. The training plans that

were created remained incomplete, as alternative methods had not been

planned. Due to this problem and due to a surge in work demand, engineers

could not undertake training when required, as work commitments would not

allow this. This affected training plans and as a result time overruns and

training costs were incurred resulting in re-planning needing to be carried out.

This would not have happened had contingency measures been in place to

counter any training related problems which could have occurred.

The actual implementation of Inform was not planned correctly which resulted

in timescales being affected. The system was implemented whilst users were

learning a new technology [laptops] that was introduced to them. As a result

of this users would not be willing to learn two different technologies at the

same time causing significant levels of user resistance to occur. If the Informe

implementation had been planned comprehensively then the system could

have been implemented when no other technology was being introduced to

users allowing for the implementation process to be executed smoothly.

The implementation of Informe would have been further hindered because of

the various technical skill levels of users. Not all users of Informe were as

technically aware as other users and therefore the development team had the

problem of deciding what was to be implemented in different versions of

Informe. As engineers are not as technically aware as each other, user

resistance may occur where users would not be willing to use the system due

to their personal limitations. Constant communication of the delivered system

will allow for user resistance to reduced as users who may have reservations

about using the system will be lessened making the implementation smoother.


The requirements that were collated were not signed-off with the user to

check that the development team had understood the requirements. The



requirements that were collated were inadequate and not defined clearly

resulting in a system that was not in line with user expectations. This factor

may result in the wrong system being developed leading to its failure. The

requirements that were delivered were done so based on the experience of

the development staff and what their perceptions of what the user required

were. This maybe a contributing factor as to why the user requirements sign-

off was not achieved because the development team delivered what they

perceived the user required from the Informe system rather than asking the

users what they really required. The increasing chances of user resistance

would be high because of this as the system developed would not be what the

user asked for resulting in users not using the system [User Resistance].

Once the system has been developed the developer will discuss any

modifications that may need to be made to the system with users. These

changes that are required will be done so instantly or will be informally

recorded. Limited use of informal recording taking place will lead to the final

system not being reflected in the user and systems documentation. If users

have any problems that they cannot solve using the support manuals then

resistance will occur where they will not use the system. Any changes to the

system should be documented so that they can be reflected in the user

documentation enabling users to understand the system better reducing User

Resistance levels.

Pressure on staff to deliver work quicker during the Informe development is

evident where development staff was asked to deliver parts of the system

quicker than what they estimated it would take to deliver the system. These

internal pressures would have forced staff to cut corners in order to develop

the system by the specified date. Due to staff pressures presiding errors could

have been possible where the system developed required re-working. This

would have impacted upon timescales and staff costs as additional time would

have been needed to solve unforced problems that occurred as a result of

staff pressure due to tight timescales.




The previous interview respondents specified that project plans, schedules,

and deadlines dates were non-existent for the first 5 months of the project as

the project plan was developed late. It was only when a project manager was

appointed to manage the project was any project plans created together with

delivery dates and milestones. The limited use of project plans would have led

to a project being developed that had no milestones or deliverables being set.

Therefore there would be no way of measuring whether the project to be

delivered was on schedule, impacting time and cost overruns.

This development did not follow any formal methods in order to set deadlines

dates or schedules and therefore staff would be placed under significant

pressure to deliver Informe in timescales that are not feasible. This would lead

to reduced quality levels as to which the system is developed by and time

overruns could have occurred because work schedules have not been

formally planned or scheduled.

7.5.5 Communications

The communication levels within the development team caused development

to lapse and fall behind, this was primarily due to the lack of effective

meetings that the team had. The development team members were not aware

of what each individual was doing causing problems such as the project

status not being known by the development team. A contributor of the

inadequate communications was due to the development team being spread

around the country and not within one location. Face to face meetings were

infrequent and the main form of communications was a weekly conference

call, which was viewed as being ineffective as issues, and problems were not

being cleared up.

The communication problems described would have caused time lapses to

occur because project issues were not being cleared up causing delays to the



development. The quality of the development process would have been

hindered, as the development process would have been impacted by the lack

of communications taking place.

Individual members of the development team work on more than one project

at a time and therefore would need to leave the Informe development

temporarily to work on alternative projects. This problem would have affected

the timescales of the project as developers maybe required to work on other

projects effecting development quality. The development quality levels would

be reduced, as consistent and continuous work would not be taking place on

Informe, as a result of different work commitments.

7.5.6 Risk Assessment

No formal risk assessment was undertaken during the Informe development

which would have led to unanticipated problems affecting the project causing

implications for the timescales, cost and quality of the Informe development.

These risk areas would be implicated during the project as no formal risk

assessment had been undertaken to determine whether these risks could

occur.

Even though no formal risk assessment was undertaken, a risk assessment

was undertaken to assess the risk of implementing or not implementing

specific requirements which the user requested. This assessment was

undertaken during the Informe development which would suggest that not all

requirements specified by users have been implemented. This assertion is

based on the risk analysis that was undertaken by the IT department prior to

development being commenced where requirements were assessed to define

if they should be implemented or not.




Analysing the problems that were identified from this interview suggests that

the way the training plans were developed and executed caused significant

problems which led to significant re-planning of schedules to take place. The

lack of communications within the development team and resource conflicts,

which occurred during development, caused the project to go off schedule.

This resulted in significant re-planning to take place in order to bring the

Informe development back on track.

7.6 Summary of Informe Problems

The lack of communications with the client and the requirements not being

signed off or being clear was key contributors to problems experienced during

the Informe development. Customer communication was done mainly at

workshops where requirements collation was done early on and these

requirements were not then re-checked with the customer to ensure that they

were accurate and what they required. Information Systems development

methods, project management techniques and limited cost benefit analysis

being undertaken are the key problem areas which occurred from this

interviewee’s point of view.

The requirements not being detailed enough or signed off by the client were

the key problems during the Informe development. Furthermore during this

development no formal specification was developed which would have aided

the understanding of the systems functional specification, for the developer.

The interviewees felt that the limited use of formal procedures like testing,

estimation, system development methodologies and project management

techniques further contributed to the problems that affected this development

project.

Informe was being developed on a different environment to the user’s

environment and no formal specialist analysis staff existing within this



department affected the project. The interview respondent felt that team

members did not have the skills to equip them to carry out the role of analysis

and developer in combination. It was felt that this was one of the reasons as

to why developers had to keep going back to the user to define and

understand the requirements which were not fully understood initially.

No formal process or structure was applied to the development and therefore

the project was pursed using limited methods and processes. Finally the

limited communications within the development team contributed to the

project status not being known at all times causing the project to go off track.

Chart 5 within Appendix 7 shows an integrated model of all the Events,

Problems and Risks that occurred during the Informe development.


Chapter Eight: Discussion of Results and Recommendations Ritesh Hira

CChhaapptteerr EEiigghhtt

DDiissccuussssiioonn ooff RReessuullttss aanndd RReeccoommmmeennddaattiioonnss

____________________________________________________________________________________________

8.0 Results and Recommendations

Chapter Six of this thesis explained the strategy that was used to collate the

research from the interviews, which were conducted during this project.

Chapter Seven analysed the problems and events, which caused the

problems to occur, and the potential risks that effected the Informe

development. Based on the analysis conducted in Chapter Seven this chapter

will detail a series of recommendations that the telecommunications company

should consider adopting. These recommendations should be adopted for

similar future projects which are conducted, as the possibilities of these

problems that occurred within the Informe development will be significantly

lessened in future projects that are undertaken.

The risks that were identified based on the analysis have been classified into

Quality, User Resistance, Time, Cost, Project Failure, Staff Pressure,

Success Failure Factors and Staff Isolation – Low Morale risks. The

subsequent sections of this chapter will provide a brief description of the risk

areas identified during the analysis stage. This will be followed by a series of

recommendations that this organisation should consider adopting so that

events, problems and risks like the ones identified within this project are

prevented from occurring in future projects.

The recommendations outlined have been formulated based on the analysis

of data collated using concept maps as an analysis tool. These concept maps,

which provide the recommendations, can be viewed in charts 6 – 13.

MSc Dissertation

138


8.1 Quality

The manner in which Information Systems (IS) developments are developed

can affect the overall quality level of the deliverable. An example of this is that

the chances of a high quality product being developed will be significantly

improved if a formal structured process is used compared to informal,

unconventional processes that were applied to the Informe development. The

following Quality risk factor affected the Informe project but in future

developments the following risks should be avoided as identified in Chart 6:

M

Quality

Additional stakeholders identifiedresulting in more requirements being

requested, system became more complex

Additional requirementsrequested

Development processtaking longer to complete

No formal Methodologyused

Not all developers usesame method

Limited consideration ofadopted development method

Development rushed through


No schedule No MonitoringStrategyNo Project plan

Risk

Events

Problems

Key Team members notaware of project

status

Inadequatecommunications

Key members of the teamtemporarily leave to doother projects or suffer

work overload

Team members have differentwork commitment to projects

Staff are put under pressureto meet deadlines

No schedules

Unanticipated problemswill directly effect the project

No formal considerationof risk

Difficult to define whetherthe final systemis cost effectiveand beneficial

No formal cost benefit analysis

Difficult to identify if projecthas met its objectives

Limited Project ManagementInvolvement

Important stage of projectmanagement ignored

No formal processfollowed

Requirements not collated fromusers adequately, system not in line with user expectations

Requirements not detailedenough

No formal record ofwho was doing what

Work allocationdone verbally


Limited knowledgeof methods used

Chart 6 - Risk Map: Quality Problems and Events

Sc Dissertation 139


During the planning stages of a project a formal process of risk

management should be undertaken to identify possible problems that may

occur during the project so that these problems can be anticipated and

resolved before they cause significant problems to development. The risks

that are identified should be continually assessed to see whether their

impact levels to the project have changed since they were identified

initially assessed.

A formal development methodology should be used to develop future

systems with. This will allow the development process to be structured and

follow a more formalised process which will deliver systems quicker than,

using informal methods. Adopting a formal development methodology will

ensure that all developers develop the system using one method enabling

a consistent development approach to be achieved. Within this

investigation development was undertaken using a number of different

methods causing inconsistencies within the system.

If additional requirements are requested once the requirements scope has

been set then timescales should also be modified according to the new

work levels. The development team should not be expected to deliver

additional requirements within the same time period. If this is done then

the quality as to which development will be carried out will be low as

corners maybe cut to accommodate timescales which was the case with

Informe.

The requirements specification and collation process should be defined to

pseudo code level so that they are fully understood by the development

team. This will enable them to deliver a system which is in line with user

expectations. To do this both high and low level requirements should be

defined and documented.

A project manager should be appointed to manage the project from the

very start of development rather than 5 months into a project. This way the

manager can enforce a structured process to development ensuring that



schedules; project plans are monitored and met. Carrying out this method

will easily identify whether the objectives of the final system are achieved.

Enforcing schedules to the development process will allow staff to work to

set targets which will enable them to plan their time effectively eliminating

the pressure to meet deadlines at the last minute. Rushing development

may result in a system being developed that is not of high quality and not

in line with user expectations

A cost benefit analysis should be undertaken prior to development to

determine whether the development is beneficial to the organisation

compared to the costs which are expected for the system.

If work allocation is done verbally then it is likely that people will change

their minds as to what was required initially. To counter this problem a

formal documented record of work allocation should be developed so that

development members know exactly who is doing what. This document

will contribute to reviewing the projects status when the projects status is

reviewed according to the objectives enabling active communication to

take place continuously.

Effective project planning if carried out will allow for plans to be made to

cope with team members leaving the team to work on other projects.

These plans will allow managers to identify when additional resource is

required to carryout development for absent development members. The

plans will also contribute to work allocation planning so that team

members are not overloaded with work or at the same time have limited

work to do.



8.2 User Resistance

The Informe development experienced significant user resistance which

resulted in extensive re-working needing to take place. This had impacts upon

the timescales for the project. Chart 7 provides an account of User Resistance

risks that affected the Informe project. The following recommendations

provide steps that may be taken to reduce User Resistance:

The requirements specified by users should only be delivered, if it is felt

that users need additional requirements they should be asked first rather

than it being assumed that they will require them.

All user levels within an organisation should be informed of development

so that their feedback can be integrated into the systems development

process. With Informe senior managers were used to collate the

requirements, but to obtain the ideas of users at operational level, these

people should be included within the development process.

Key

Ev

UserResistance

Inadequate requirements definedUsers reject the system

as its not what they asked for

Functional requirements notsigned off by customers


not understood


Users see errors with the system,expect it to be bug free

No formal testing

Plans as to which requirementsare to be implemented are not

documented

No development plans

Users felt that the systemwas to close their department

down

Project had seriousorganisational impact

System continuallychanging

No version control

System implemented to users whilst theywere learning laptop technology, training could not be

delivered at specified time

Inadequate implementationplan

Same problemsre-occur

User problemsnot documented

Users unhappy with performanceof the system


Users not willing towork with the technology

Low Levels of It literacyin the organisation


Limited representation of usersin the requirementscollation process

Systems performanceproblems

Lack of system scalabilityplanning

Inadequate Requirementscollation

No specialised analysisstaff

Decision not made by seniormanagement as to whether

development should go ahead


Engineers not awaretechnically


Not decided as to whatrequirements would be delivered

in each version

Inadequate implementationplans

Inadequate understandingof requirements, developed

system not in line withuser expectations

Lack of communicationswith the client

Additional requirementswere delivered when not

asked for

Development Agendas

Field engineers unable to undertaketraining at specified time

Un-comprehensivetraining plan

Users don’t understandthe system

Not all userstrained with Informe

Development changesunrecorded does not relate

to final system

Inadequate systemspecification

Risk

ents

Problems

Chart 7 - Risk Map: User Resistance Problems and Events



Senior management should make the decision as to whether a

development should progress further. An informed decision based on a

formal cost benefit analysis being created will enable for this to occur. Not

doing this will cause problems for the project, as support from senior

managers will not have been achieved.

The functional requirements that are collated should be reviewed with the

user or client ensuring that the requirements have been understood fully.

These requirements should be formally signed off by the client indicating

their approval for the requirements to be implemented.

At present the role of requirements analysis and developer is done in

collaboration within the Informe development. Specialist analysis staff

should be appointed within the team so that the requirements, which are

collated from the user, can be fully defined to an understandable standard.

The current situation with team members taking a dual role is regarded as

problematic as they have limited skills to carryout both roles.

Training plans should be developed comprehensively checking with users

of their availability to undertake training at specified times. These plans

should be complemented with contingencies. If at the last minute users are

not available to carryout training due to workloads then contingencies can

be executed.

Formal testing should be carried out before the system is implemented

and not after implementation which was the case with Informe. Any errors

that are detected can be removed enabling implementation to be

smoother. This will allow users to become familiar with the system without

having to deal with system errors that maybe present due to limited testing

being conducted.

A low level of IT literacy is an example as to why user resistance may

have occurred for the Informe system. To counter this active

communication and comprehensive user training plans should be



executed so that users are more confident to use the system. At the same

time the timings of training and implementation should be carefully

considered so that it does not clash with the implementation of other

technological developments. The problem here would be that users would

not be willing to work with the implemented system as they would be in the

process of learning a previously implemented system.

Client/ user communications should be active throughout development so

that requirements are understood correctly and their support is achieved

and maintained throughout the development process allowing the

implementation process to take place efficiently and effectively.

User training should be conducted with different user levels and not just

with senior managers of departments as it is possible that the training may

not be communicated effectively by senior managers increasing the

number of user problems associated with the system.

The different versions of a system that are implemented need to be

controlled. The requirements, which are to be delivered, should be

documented so that their implementation can be planned effectively.

Furthermore plans as to how the requirements will be developed should be

created so that users can be informed of what each version or system will

deliver. This awareness will enable different elements of the system to be

learnt more efficiently.

The users should be informed of the benefits of the system and what it will

attempt to do. This method will reduce any qualms that users may have

about the threat that the system may close their department down which

certainly may not be the case. Any organisational issues related to the

project should be dealt with effectively so that user support is achieved.

After implementation user problems are likely to occur these should be

dealt with but at the same time these should be documented so that

modifications can be made to the system or to future implementations.



This method will remove the same problem from occurring again reducing

this risk level from increasing.

The platform that is to be used to develop the system should be assessed

to ensure that the system that is to be implemented on this platform would

support the system even if additional functions were added to it. This is so

that it can be ensured that the final system will perform as required even if

additional functions are added.

The performance of systems can be affected if the system is developed

upon an environment that is different from the user environment. This will

cause major problems when the system is implemented. By ensuring that

both the development environment and user environment is the same will

ensure that minimal problems are experienced during implementation

when users begin to operate the system.

8.3 Time

The timescales that are set for a project can stringent in that they have to be

met in order to satisfy user expectations for the delivery of a product by a

specified deadline date. Although this may not always be the case as

timescales may slip prompting the need for of re-planning. In order to avoid

timescales from slipping the following Time related risks should be avoided in

future developments [See Chart 8]:

Active communications should take place with users so that the

requirements can be fully understood and implemented as requested by

users with minimal re-working being required.

Additional stakeholders maybe identified during development and possibly

after the user requirements have been scoped. These stakeholders may

have further requirements for the system. If this is the case then

timescales may need to be re-planned so that development staff is not



placed under pressure to deliver additional requirements within the same

time period.

Time

Informe not on managementobjectives & not willing to embrace

Informe

Limited involvement ofclient/ management

Additional stakeholdersidentified resulting inmore requirements

being requested, systembecame more complex


Guess on Project Status




Same problems re-occur

User problems notdocumented


Limited Project managementdocumentation


No consideration ofrisk



process

Additional requirementswere delivered when not asked for

Development Agendas

Exact project status notknown as team geographically

spread

Lack of communications

Failure to agree adequate timescalesfor development

Internal Politics


No specialisedanalysis staff

Development notbeing controlled

Lack of clear projectplan


Functional requirementsnot signed off by customers

Development process takes longerto complete

No formal methodologyused

System implemented to users whilst they werelearning laptop technology, training could not be

delivered at a specified time


No schedule No MonitoringStrategy

No Project plan

Decision not made by senior managementas to whether development

should go ahead


Impossible to compare systemrequirement to implemented

system

Functional requirements notsigned off

Developed System notin line with user

expectations


Development progressnot being overseen

No project manager


Limited knowledge ofmethods used.

Limited reporting

Communications done viaweekly conference calls


Lack of clearrequirements sign off

No formal record of who isdoing what

Work allocation done verbally

Inadequate understandingof requirements


System performanceproblems

Lack of systemscalability planning

Duplicate work

Development carriedout on different versions

of the same system

Key members of the teamtemporarily leave to do other

projects or suffer work overload


commitments

Risk

Events

Problems

Key

Chart 8 - Risk Map: Time Problems and Events



The functional requirements need to be signed off so that developers can

be sure that the requirements that they are implementing are reflective of

what the user requires. Doing this will prevent users from rejecting the

system causing significant re-working of timescales. This method will also

allow for the implemented system to be reviewed determining if the project

has met its objectives and prevent the wrong system being developed.

Appointing specialist Requirements Analysis staff will enable the

requirements to be defined accurately enabling development staff to

implement the requirements in a timely manner. Using this method will

allow for the requirements to be fully understood first time round allowing

the developed product to be delivered on time with minimal re-working

taking place saving resource.

It should be ensured that the platform that is to be used to develop the

system is scalable and that it will perform just as well with additional

functions being implemented. This judgement should be made prior to

development begins so that alternative platforms can be purchased in

which development can be undertaken. This was not initially done with the

Informe development and therefore system performance problems

occurred. This would have affected timescales, as these problems would

have had to be rectified before development could continue.

Proposed developments should be placed on management objectives so

that their involvement and commitment is achieved. Management

involvement will also result in other user levels being committed to the

project. Importantly senior management support can be used to resolve

any major problems that may affect the project.

A project plan should be developed to monitor and control the

developments progress so that any time related problems that may occur

could be detected and dealt with accordingly before significant impact

occurs upon the project.



The Project Manager should be made responsible for creating project

management documentation so they the project can be reviewed as to

how well it has been or is progressing. Furthermore the exact status of the

project can be communicated to managers and the development team so

that guessing the development status can be avoided.

Future developments should be carried out using formalised development

methods so that the development can be carried out using a formalised

structure. This process will allow development to be undertaken in an

efficient manner where this would not be the case if development was

undertaken using informal methods.

For effective timely project management to be carried out a project

manager should be appointed from the start of a projects development to

oversee development and control the resource and timescales of a project.

Controlling the development progress using a formal project manager will

increase the chances for the project to be delivered on time and within

cost.

The project team for Informe was spread out on a geographical basis

presenting serious communication flaws as communications between the

team only took place once a week using conference calls. Every 3 weeks

was a face-to-face meeting-taking place. The limited communications

within a team can cause the project to go off course leading to time

overruns. For a project to be developed effectively and efficiently the team

should be situated within one geographical location so that issues are

resolved in a timely manner. If the project team members have to work in

different locations then management needs to ensure that weekly or daily

communications or project reporting is taking place so that team members

are aware of the projects status throughout development.

Political situations such as failing to agree on project timescales should be

avoided. Timescales for the delivery of the system should be done using

two-way communications where consideration for the developer’s



workload should be taken into account. Based on existing work schedules

timescales for work delivery should be made to ensure that staff pressure

is reduced.

The limited consideration of risk management will have an impact upon the

timescales of the project, as unanticipated risks will affect the project. The

effects of these risks may result in timescales being pushed back which

may cause project re-scheduling needing to be carried out. This problem

can be removed if adequate consideration is given to the project risks at

the outset and monitoring these risks during the projects execution.

Development work that is carried out; should be done on one system. The

process of carrying out the same work on two different versions of the

same system should be avoided, as more time and resource will be

required when this is not necessary. Duplicate development should be

avoided by focusing on one version and making sure that the system

being developed is up to standard. This is so that the implemented system

addresses the limitations of the implemented system ultimately saving time

as duplicate work can be avoided and problems can be eradicated which

may exist within the current system.

User problems should be documented and addressed within the present or

future developments of a system. This so that users do not experience

similar problems as these can be eradicated as users raise them. Not

doing this will simply cause the same problem to re-occur resulting in time

being wasted dealing with the same user problems that have already

surfaced.

The timing of system implementations should be carried out when users

are not learning new technologies. This maybe difficult to do as technology

continually evolves but planning effective implementation schedules will

allow training to be carried out effectively reducing the impact on

timescales. Having contingencies plans in place will ensure that



timescales are not disrupted too much in case implementation plans are

hindered.

A formal record of what work the development staff are undertaking or

have been allocated should be adopted as this method will allow for a

record to be kept of what work is required. Re-working can be avoided

using this process as customers or development staff cannot say that this

is not what they required as a formal record will exist.

The development of Inform was rushed through with limited project

management being used to control development in terms of schedules,

monitoring strategies or project plans being developed. This aspect, which

was missed out, is vital for a project to succeed and it is imperative that

future projects are developed using project management techniques

providing a structured process to development.

A decision should be made by senior management as to whether

development should be carried out. If the decision made is not in favour of

development being carried out then time will be saved developing a

system which will not be implemented in the view of senior managers.

The requirements specified by users should be implemented. The

development staff may feel that users need additional requirements but

this should only be done in collaboration and agreement with users.

Additional time would be spent in delivering requirements that will not be

used by users which would result in un-necessary time and resource being

wasted.

Timescales will be impacted by development staff temporarily leaving a

project to work on other projects. This is a risk that will affect most projects

but the risk can be countered by planning for additional resource to be

available so that they can take over development when development staff

leaves to work on other projects. The risk can also be countered by



allocating time within project plans to accommodate staff leaving the

project.

8.4 Cost

The risks and recommendations that have been highlighted in the Time risk

factor in section 8.3 have direct impacts upon the Cost risk factor. Therefore

the recommendations that have been highlighted in section 8.3 also apply to

the Cost risk factor as well (See Chart 9). As well as the recommendations

outlined in section 8.3, two additional recommendations have been identified

which are related to the Cost risk but not to the Time risk. These are:

Project plans were developed late into the project for the Informe

development. To monitor costs from the start of a project, project plans

need to be devised allowing cost monitoring to take place effectively.

Training plans should be developed to the last detail countering any

problems that may arise. If this is not done then costs will occur where

training facilities and resource will be wasted, as users will not be

available to undertake such training at a specified time.



Cost

Informe not on managementobjectives & not willing to embrace

Informe

Limited involvement ofclient/ management

Additional stakeholdersidentified resulting inmore requirements

being requested, systembecame more complex


Guess on Project Status







Limited Project managementdocumentation


No consideration ofrisk



process

Additional requirementswere delivered when not asked for

Development Agendas

Exact project status notknown as team geographically

spread


Failure to agree adequate timescalesfor development

Internal Politics


No specialisedanalysis staff


Functional requirementsnot signed off by customers

Development process takes longerto complete

No formal methodologyused

System implemented to users whilst they werelearning laptop technology, training could not be

delivered at a specified time


No schedule

No MonitoringStrategyNo Project plan


should go ahead


Developed System notin line with userexpectations


Development progressnot being overseen

No project manager


Lack of clearrequirements sign off

Inadequate understandingof requirements


Project Plan developedlate

No timescales, deliverables & milestonesdeveloped at the projects initiation

Same Problemsre-occur


Field engineers unable toundertake training at specified

time

Un-comprehensive trainingplan

Risk

Events

Problems

Key

Chart 9 - Risk Map: Cost Problems and Events



8.5 Project Failure

Chart 10 provides a graphical representation of the problems, which

contributed to the possibility of the project potentially failing due to the risks

that were taken during the Informe development. Project failure could have

occurred due to the following factors; as a result the following

recommendations should be adopted to prevent future projects from facing

the risk of project failure:

M

ProjectFailure

Users reject systemas its not what they asked for

Functional requirementsnot signed off by client

Requirements not collated from usersadequately, system not in line

with user expectations

Requirements not detailedenough

Plans as to which requirementsare to be implementedare not documented

No developmentplans


should go ahead



No formal specification(PRD/ CRD)

Guess on projectstatus

Limited project Managementdocumentation

Senior management buy-inmay not be achieved

Limited involvementof senior management

Not clear what the benefitsof Informe are

Risk

Events

Problems

Key

Chart 10 - Risk Map: Project Failure Problems and Events

The requirements need to be detailed to both a high level and low level

standard so that the development team can understand what is required

from the new system. These requirements should be defined using

documentation methods such as Project Requirements Documentation

[PRD] and Client Requirements Documentation [PRD]. This way a system

will be developed that will be in line with user expectations. Not doing this

Sc Dissertation 153


will lead to development failing as it will not be in line with what was

requested. Making use of documentation will allow the development team

to have proof that the requirements defined are the one specified by the

user.

A formal requirements sign-off should be obtained before the requirements

are implemented. This will allow the user or client to confirm that the

requirements specified are reflective of what they require which will

eliminate any confusion which may arise when the system is implemented.

Using this method the user will not be in a position to reject a system that

they have agreed to.

Prior to development, development plans should be created to show which

requirements are to be delivered within each version of the systems

implementation. This should be agreed with users so that they are made

aware of what is to be delivered in the final system. Producing

development plans will aid the development of user and systems

documentation something that can only be done if documents are

produced during development to support the development. At present

development plans are created in the minds of developers or on some

paper which is then disposed.

Senior management [client support] should be obtained at the very

beginning of the project rather than mid way through development. This

way the project can be supported by senior management showing that it is

part of their strategic objectives. Their support will allow for the project to

be moved along if it was to face difficult issues or problems. Furthermore it

was discovered that without management support Informe would have had

to be abandoned and therefore it is imperative that this level of support is

achieved at the projects initiation.

A formal Business Case or Cost Benefit Analysis should be submitted to

senior management indicating what benefits a system will bring and what

costs it will entail. This process will allow for management to make an



informed decision as to whether development should go ahead. Not doing

this will lead to minimal management support being achieved.

The projects status needs to be known by all the development team at all

times so that reporting on the projects status can be done in an accurate

and timely manner. Communicating each individual’s weekly work

progress can contribute to this taking place efficiently. Due to limited

project management documentation being created for the Informe project

this led to the status being guessed rather than being communicated

accurately.

8.6 Staff Pressure

During systems development pressure on staff could lead to periods of high

staff turnover where members of the development team leave the project, are

absent due to illness or maybe required to work on more than one project at a

time (Olson, 2001). During the Informe project high degrees of staff pressure

were applied to the development team which included limited communications

taking place between members of the development team. The limited

communication within the team led to the projects progress not being

discussed. No formal reporting structure was applied to this project leading to

staff feeling isolated causing team morale to be low.

Communication took place on a weekly basis using conference calls but this

was viewed as being inadequate as issues were not cleared up using this

method. Rather than this face to face meeting should take place in future

projects, this will allow for the team to bond together better allowing for issues

and problems to be solved instantly. A weekly reporting structure to

management reporting on the project progress will allow for staff isolation to

be eradicated, as the development team will know the projects status on a

more regular basis which was not the case with the Informe development.



This is one of the fundamental risks [Active Communication] that needs to be

addressed in future projects, although other Staff Pressure risks [See Chart

11] that need to be addressed include:

Formal estimation techniques such as estimating the size of a project in

terms of Line of Codes should be carried out so that members of the

development team can make an informed estimate as to how long

development will take. Guessing the time it will take them to deliver a

project should be avoided as this will lead to additional staff pressure

when they cannot deliver the product as initially estimated. A project

needs a deadline even though it is perceived that development will

evolve as business needs require. Enforcing deadlines will allow for the

development to work towards a common deadline ensuring that effective

planning is undertaken. For a detailed discussion on estimation please

see section 4.7.



Staff Pressure

Development staff use guesstimateas to when they can deliver

No set deadlines

Deadlines slip


Development staff do not communicateprogress and feel isolated/ low morale

No formal reportingstructure

Risk

Events

Problems

Key

Additional stakeholders identified resultingin more requirements being requested leading to

system complexity



Internal politics




Chart 11 - Risk Map: Staff pressure Problems and Events

The requirements that are collated should be scoped and agreed with the

user as to which requirements will be delivered within the different

versions of the system. If the system to be implemented is a one off

implementation and no versions are to follow then requirements scoping

should be carried to decide which of the requirements should be

implemented within the timescales and budgets of the project. To reduce

staff pressure further requirements should not be added to this

development but saved for future versions. However if this is not possible

then timescales should be altered to allow time for the additional

requirements requested to be delivered without excess being applied.



Project schedules should be devised at the initiation of a project and be

closely monitored to ensure that schedules are being achieved with this

information being communicated to the development team. This process

will allow the project manager to assess the development progress

effectively without having to make guesses. Documentation of the project

monitoring process should be developed to evaluate the project when

required and if managers leave the project then a formal handover can be

carried out. During the Informe development no such documentation

existed.

8.7 Success Failure Factors

Projects that are developed need to be delivered, which is reflective of what,

the user requires. Therefore this can defined using requirement collation

documents such as PRD or CRD. Having a formal process which captures the

requirements in a clear, structured and formal manner will enable an

assessment to take place as to whether the implemented system met its

objectives, that the user or client set out (See Chart 12).

M

Success or failuredependent on this factor

Difficult to assess final systemagainst requirements document

No formal specification(PRD/ CRD)

Risk

Events

Problems

Key

Chart 12 - Risk Map: Success or Failure Problems and Events

Sc Dissertation 158


This would be difficult to conduct if requirements were not signed-off by users

or if they were not collated using formal methods. This was the case with

Informe.

8.8 Staff Isolation – Low Morale

In order for the project manager, department managers and the development

team to know what the status of the project is, a formal weekly reporting

structure should be enforced on all development projects undertaken.

Development staff should be required to update their work schedules so that

managers can determine where the project is at and whether it is meeting its

schedule and objectives. More importantly the customer can be informed of

how the project is progressing. It will also allow the development staff to

communicate their progress with one another increasing communications

within the team.

Staff IsolationLow Morale

Development Staff do notcommunicate progress

No formal reportingstructure

Risk

Events

Problems

Key

Chart 13 - Risk Map: Staff Isolation - Low Morale Problems and Events



This method will reduce any feelings of low staff morale or isolation which

would occur when communications within the team is limited or virtually non-

existent. The development progress of a project can be significantly improved

if active communication takes place within the team potentially improving the

teams working spirit.

8.9 Summary of Recommendations

The recommendations that have been outlined for the Quality, User

Resistance, Time, Cost, Project Failure, Staff Pressure, Staff Isolation – Low

Morale and Success or Failure risk areas all in some way impact one another.

This has been highlighted and is easily identifiable in each of the sections

within this chapter. The recommendations outlined are based on the findings

of the four interviews conducted and are reflective of the information provided

by the interview respondents during the interviews. The interview transcripts

of the four interviews can be viewed in Appendix 3 - 6.


Chapter Nine: Conclusions and Future Work Ritesh Hira

CChhaapptteerr NNiinnee

CCoonncclluussiioonnss aanndd FFuuttuurree WWoorrkk

______________________________________________________________________________________________________

9.0 Objectives

This empirical study has assessed and identified the risk factors which

occurred during the development of a large industrialised telecommunications

IT project that has been developed within the United Kingdom. The research

project has identified and analysed many of the problems which occurred

during this development, identifying and analysing the events that may have

potentially contributed to the Informe problems initially occurring [See Chapter

Seven]. The possible risks that occurred as a result of the problems occurring

are identified and analysed together with a series of recommendations that

should be adopted to prevent such problems and risks occurring in similar

future projects.

The above objectives outlined have been successfully completed enabling the

researcher to address the overall research question which is to assess the

“risks of industrial Information Systems projects” like the Informe

development. An overview of this project will be provided within subsequent

sections of this chapter.

9.1 Process Summary

This project has been conducted by initially carrying out a comprehensive

literature survey of established literature in relation to Risk Management

[Chapter 5], IS in Organisations [Chapter 2], IS Project failures that have

occurred in the past [Chapter 3] and theory about IS Project Management

[Chapter 4]. Once a comprehensive understanding of the theory associated

with Information Systems, Project and Risk Management had been achieved

the investigation process was undertaken. The investigation process was



undertaken by carrying out four in depth interviews with key members of the

development team. These interviews although highly structured using

questions derived from risk identification frameworks by Cadle and Yeates

(2001) also allowed the interviewees to explain further any other problems

that occurred during the project. This enabled for a comprehensive account of

the Informe problems to be outlined.

Once the data had been collated it was analysed to identify the problems of

Informe which occurred due to various events taking place that ultimately

caused the potential risks to occur within this project. The risks that have been

identified were further analysed using concept mapping techniques to

determine the recommendations that should be adopted to prevent similar

problems, events and risks occurring within future IS developments.

9.2 Summary of Results

It was difficult to predict what the results and conclusions of this research

would be initially as the topic area was something new to the author. Once the

literature survey had been conducted the author was able to make informed

predictions. These predictions were in relation to what the conclusions of this

investigation would be and whether the same problems and risks undertaken

in past IS developments would still be evident in projects undertaken in

today’s world. The conclusions obtained provide stimulating knowledge in that

the worst fears have been confirmed as development problems that were

highlighted, as taking place in the 1990s (Johnson et al, 2001) are still

occurring in IS developments like the Informe project.

The results indicate that within this project limited communication took place

within the development team and also with the client and user. This led to the

project status not being identifiable by management or within the development

team. Extensive literature has been published by authors about requirements

collation in that poor requirements engineering is often quoted as the cause of

IT project failures (Lawrence, 2003). This was the case within the Informe



development where the requirements were too high level and were not signed

off by the client to ensure that the requirements were correct.

Further conclusions that have been derived from this study suggest that the

dual role undertaken by staff in being the developer and analyst contributed to

inadequate requirements being collated. This was due to the limited skill set of

developers who felt that they did not have the skills to carryout such a

demanding role. It can be appreciated that the dual role was being done

within the department so that developers could understand what users

require. However using specialised requirements analysts will enable the

requirements to be defined quickly and precisely (Lawrence, 2003),

something that has not been achieved within this development as this thesis

and conclusion portrays.

The use of formal methods or project management techniques were limited in

this development as formal processes such as cost estimation, system

scalability, formal reporting structures and testing were not carried out

exhaustively in this development. Testing was primarily done when the

system was implemented and estimation had been conducted using

unconventional methods such as the “rule of thumb approach”. The research

further concludes that for a project to be successful formal processes should

be used in order for a project to be developed using a structured method. This

can only be done if a formal project manager is appointed from the projects

initiation to manage the project. This was not the case for this development as

the project manager was appointed to manage the development effort five

months into the project.

Limited project management involvement at the beginning of the project

contributed to a lack of project plans being created. Had project plans been in

place then it would have enabled for effective project monitoring to take place

for any schedules that were set.

An important process that was limited within this development is the

consideration of risks that could impact this development. Due to the limited



risk assessment being undertaken in this project the following risks have been

identified as having occurred with the Informe development:

Quality

User Resistance

Time

Cost

Project Failure

Staff Pressure

Success or Failure dependent on this factor

Staff Isolation – Low Morale

Similar projects, which are conducted in the future, should be monitored to

ensure that problems described within this chapter and within this thesis are

minimised or removed to ensure that development is carried out effectively

and efficiently. This can be done by following and adhering to

recommendations specified in Chapter 8.

9.3 Summary of Methods

This investigation has been executed using the inductive approach where 4

extensive interviews have been conducted. The questions that were asked

within these interviews were formulated based on an extensive literature

review being conducted and also by selecting academic risk identification

frameworks. The framework that was used covered a diverse range of risk

areas but to ensure that all areas were covered the interviewee was

encouraged to detail further problems that may not have been covered within

the framework ensuring that a thorough investigation was undertaken. The

data collated was then analysed using concept-mapping techniques which

allowed for the problems, events and risks to be identified. Following this

stage, recommendations for the possible elimination of these risks in future

projects were defined using concept maps and are documented in Chapter 8

of this thesis.



9.4 Future Research

This research project has paved way for a number of potential studies to be

undertaken. Assessing project risks in other industrial sectors to determine

whether the risks experienced in this project has any resemblance on other

industrial projects that are carried out. The findings of these studies can then

be examined to this study to define any correlations that may exist.

A risk assessment could be undertaken of the different user levels (Strategic,

Management and Operational) within organisations to determine exactly

where problems, event and risks first occur. This study will enable the

containment of project risks to occur preventing it from spreading to other

areas of the organisation.


Glossary Ritesh Hira

GGlloossssaarryy

____________________________________________________________________________________________ ATCS Air Traffic Control System

BBC British Broadcasting Corporation

CAD Computer Aided Dispatch

CASE Computer Aided Software Engineering

CEO Chief Executive Officers

CIO Chief Information Officer

COCOMO Constructive Cost Model

CPA Critical Path Analysis CSF Critical Success Factors

CPD Client Requirement Definition

EIS Executive Information Systems

FMECA Failure Models And Effects Critically Analysis

HRM Human Resource Management

ISE Information Systems Executive IS Information Systems

IT Information Systems

JAD Joint Application Development JIT Just In Time JRP Joint Requirements Planning

JSD Jackson Systems Design

KM Knowledge Management

LAS London Ambulance Service

LASCAD London Ambulance Service Computer Aided Dispatch System

LOC Lines Of Code

LSE London Stock Exchange

MI Management Information MIS Management Information Systems

OTLP Online Transactional Processing

PLC Public Limited Company PRD Project Requirement Definition

MSc Dissertation

166

Glossary Ritesh Hira

PROMS A Systems Development undertaken by the Performing Rights

Society PRS Performing Rights Society

RAD Rapid Application Development SDLC systems Development Lifecycle SIS Strategic Information Systems SLA Service Level Agreement SoR Statement of Requirements

SQA Software Quality Assurance

SSADM Structured System Analysis & Design Methodology

SSM Soft Systems Methodologies

TPS Transaction Processing Systems

VDM Vienna Development Method

YSM Yourdon Systems Method

MSc Dissertation

167

References Ritesh Hira

RReeffeerreenncceess

____________________________________________________________________________________________

Ackoff, R. L. (1967). “Management Misinformation Systems”. Management

Science, 14, 4, December, pp. 147-156.

Adair, J. (1986). The Skills of Leadership Gower Press. Aldershot.

Adekeye, A. (1997). “The Importance of Management Information Systems”,

Library Review, Vol. 46, No. 5, pp. 318-327.

Alavi, M. Carlson, P. (1992). "A review of MIS Research and Disciplinary

Development," Journal of Management Information Systems (8:4), pp. 45-62.

Amadahl. (1990). Computer Disasters and Contingency Planning. Amadahl

Executive Institute.

Avison, D. E. (1995). Information Systems Development: Methodologies,

Techniques and Tools. 2nd Edition, McGraw-Hill.

Avison, D.E. Fitzgerald, G. (1988) Information Systems Development,

Blackwell, Oxford.

Avison, D. E. Fitzgerald, G. (1998). Information Systems Development:

Methodologies, Techniques and Tools. Blackwell Scientific Publications.

Avison, D. Shah, H. (1997). The Information Systems Development Life

Cycle: A First Course in IS. McGraw Hill.

Baker, S. Baker, K (2000). The Complete Idiots Guide to Project

Management. 2nd Edition. Alpha Books.

MSc Dissertation

168


Bandyopadhyay, K. Mykytyn, P, Mykytyn, K (1999). “A Framework for

Integrated Risk Management in Information Technology”. Management

Decision 37 (5) pp.437 - 444.

BBC. (2000a). “Air Traffic Centre Plagued by Glitches”. BBC [Online]. 10

August. http://news.bbc.co.uk/1/hi/uk/873765.stm [Accessed 24 Jan. 03].

BBC. (2002b). “Computer Breakdown Disrupts Flights”. BBC [Online]. 10

April. http://news.bbc.co.uk/1/hi/uk/1920527.stm [Accessed 24 Jan. 03].

BBC. (2002c). “Swanwick: Dogged by Problems”. BBC [Online]. 19

December. http://news.bbc.co.uk/1/hi/uk/1993586.stm [Accessed 24 Jan. 03].

Bee, R. Bee, F. (1997). Project Management – The People Challenge Institute

of Personnel and Development. London.

Behren, J. R. (1996). “The Failure of the London Ambulatory Dispatch

System”. Berkeley [Online]. 4 July.

http://www.cs.berkerley.edu/~jrvb/classes/fault_tolerent/las.html04/07/2003

Benbasat, I., Goldstein, D.K. and Mead, M. "The Case Research Strategy in

Studies of Information Systems," MIS Quarterly (11:3) 1987, pp. 369-386.

Beynon-Davies. (1995). “Information Systems ‘Failure’ and Risk Assessment:

The Case of the London Ambulance Service Computer Aided Despatch

System”. Proceedings of the 3rd European Conference on Information

Systems. Athens/ Greece, June 1-3 1995, 1153 – 1161.

Boehm, B.W. (1979). Software Engineering: R&D Trends and Defence Needs

Research Directions in Software Technology, Cambridge MA, MIT Press.

Boehm, B.W. (1981). Software Engineering Economics. Prentice Hall


http://www.cs.berkerley.edu/~jrvb/classes/fault_tolerent/las.html04/07/2003


Boehm, B. W. (1991). Software Risk Management. Los Alamitos. IEEE

Computer Society Press.

Brooks, C. P. Grouse, P. J. Jeffery, D. R. (1982). Information Systems

Design. Prentice Hall.

Brooks, F.P Jr. (1975). “The Mythical Man-Month”, Datamation, December.

Burke, R. (1999). Project Management: Planning & Control Techniques. 3rd

Edition. Wiley.

Cadle, J. and Yeates, D. (2001) Project Management for Information Systems

3rd Edition. Financial Times/Prentice Hall: Harlow.

Chapman, C. Ward, S. (1997). Project Risk Management: Processes,

Techniques and Insights. Wiley.

Charette, R. N. (1998). Software Engineering Risk Analysis and Management,

McGraw Hill.

CIO Magazine. (1998). “Lessons Learned: To Hell and Back”. CIO Magazine

[Online]. http://www.cio.com/archive/120198/turk.html [Accessed 7 January

2003].

Collins, T. (1998). Crash Learning from the Worlds Worst Computer

Disasters. Simon & Schuster.

Computer Weekly (2002). “Learn from the Worst IT Mistakes” [Online].

Computer Weekly Ltd. http://www.computerweekly.com/itmistakes/ [Accessed

12 December 2002].

Computer Weekly. (2003a). “IT Management: Race to Fix Air Traffic Bugs”

[Online]. Computer Weekly Ltd.

http://www.computerweekly.com/Article23410.htm04/07/2003



Computer Weekly. (2003b). “A Brief History of an Air traffic Control System”

[Online]. Computer Weekly Ltd.

http://www.computerweekly.com/Article109436.htm04/07/2003

Cooper, J.D. Fisher, M.J. (1979). Software Quality Management. Petrocelli.

Cornford, T. Smithson, S. (1996). Project Research in Information Systems: A

Students Guide. Macmillan Press Ltd.

Currie, W. (1995). Management Strategy for IT: An International Perspective.

London: Pitman.

Daniels, A. Yeates, D. [ed.] (1986). Basic Systems Analysis Pitman, London.

Daniels, S. (1998). “The Strategic Use of Information Systems”, Work Study,

Volume 47, No. 5, pp.167-171.

Dearden, J. (1970). “MIS is a Mirage”, Harvard Business Review, 50, 1,

January – February, pp. 90-99.

Dickson, G. W., Benbasat, I., King, M. R. (1980). “The Management

Information Systems Arena: Problems, Challenges and Opportunities”.

Proceedings of the First International Conference on Information Systems,

Philadelphia, pp. 1-8.

Doke, E. R. Barrier, T. (1994). “An Assessment of Information Systems

Taxonomies: Time to Re-evaluate?” Journal of Information technology. 9, pp

149-157.

Downs, E, et al. (1988) Structured Systems Analysis and Design Method:

Application and Context, Prentice-Hall.

Drummond, H. (1998). “Riding a Tiger: Some Lessons of Taurus.”

Management Decision, 36 (3), 141-146.



Durr, M. (1987). “Peer Networks Gain Ground”, Computerworld, Vol. 21 No. 4,

pp. 39-44.

Eby, M. (1999). “An Investigation of the Therac-25 Accidents” [Online].

University of California.

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html [Accessed 1

July 2003].

Eloff, J.H.P., Labuschagne, L., Badenhorst, K.P. (1993). “A Comparative

Framework for Risk Analysis Methods”, Computers & Security, Volume. 12,

Number. 6, pp. 597-603.

Ennals, R. (1995). Executive Guide to Preventing Information Technology

Disasters. Springer-Verlag, London.

Finkelstein, A. Dowell, J. (1994). A Comedy of Errors: The London Ambulance

Service Case Study. School of Informatics, City University, UK.

Fischler, H. Peuckert, J. (2000). “Concept Maps as a Tool for Investigating

and Analysing the Development of Student Conceptions”, [Online]. Free

University of Berlin Physics Education. http://www-old.physik.fu-

berlin.de/physikdidaktik/Coma.pdf [Accessed 7 August 2003].

Fitzgerald, J. & Fitzgerald, A. (1987). Fundamentals of System Analysis,

Wiley, USA.

Flowers, S. (1997). Software Failure: Management Failure, Amazing Stories

and Cautionary Tales John Wiley & Sons.

Flynn, D. J. (1992). Information Systems Requirements: Determination and

Analysis. McGraw Hill International Ltd.


http://www-old.physik.fu-berlin.de/physikdidaktik/Coma.pdf

http://www-old.physik.fu-berlin.de/physikdidaktik/Coma.pdf


Forza, C. (1995). “The Impact of Information Systems on Quality

Performance: An Empirical Study”, International Journal of Operations &

Production Management, 15, 6, pp. 69-83.

Frosdick, S. (1997). “The Techniques of Risk Analysis are Insufficient in

themselves”. Disaster Prevention and Management. 6 (3) pp. 165 - 177.

Galliers, R. (1992). Information Systems Research: Issues, Methods and

Practical Guidelines. Blackwell Scientific Publications.

Greenfield, T. (1996). Research Methods: Guidance for Postgraduates.

Arnold.

Gupta, U. G. Collins, W. (1997). “The Impact of Information Systems on the

Efficiency of Banks: An Empirical Investigation”, Information Management &

Data Systems, January, pp. 10-16.

Gurbaxani, V. Whang, S. (1991). “The Impact of Information Systems on

Organisations and Markets”, Communications of the ACM, January, Vol. 34

No. 1, pp. 59-68.

Handy, C. B. (1985). Gods of Management: the Changing Work of

Organisations. London: Pan Books.

Hawryszkiewycz, I.T. (1991). Introduction to Systems Analysis and Design.

Prentice Hall, London.

Hetzel, W. (1988). The Complete Guide to Software Testing QED Information

Sciences, Wellesley, Mass.

Hicks, J. O. (1993). Management Information Systems: A User Perspective,

West, Minneapolis.

Holmes, A. (2001). Failsafe IS Project Delivery. Gower.



Hughes, B. Cotterell, M. (1999). Software Project Management. Second

Edition, McGraw Hill.

Hussain, Z. (2001). “Singapore TRADENET: Successful IT Through Good

planning, Design & Requirements Analysis”. Sheffield Hallam University.

Iacovou, C. L. (1998). IS Problems and IS Failures: A Crisis Management

Perspective. University of British Columbia.

Illes, M. (1990). “Methods Vs People”, Software Management Magazine,

June.

Ince, D. (1993). Introduction Software Project Management and Quality

Assurance. London: McGraw Hill.

Jacky, J. (1996). “Safety-Critical Computing: Hazards, Practices, Standards

and Regulation”, in Kling, R., Computerisation and Controversy (2 Edition)

San Diego: Academic Press, p. 775.

nd

Johnson, J. Boucher, K. D. Connors, K. Robinson, J. (2001). Collaboration

Development & Management: Collaborating on Project Success. Software

Magazine and Wisener Publishing.

Jones, G.W. (1990). Software Engineering, Wiley, New York.

Jones, R. (1996). Accident and Design: Contemporary Debates in Risk

Management. London: UCL Press.

Keen, P.G.W. (1980). “MIS Research: Reference Disciplines and a

Cumulative Tradition”. Proceedings of the First International Conference on

Information Systems, Philadelphia, pp. 9-18

Keen, J. (1987). Managing Systems Development, (2nd Edition). Wiley.



Kelsey, T. (1993). “The Great Computer Catastrophe: Technology has Cost

us Millions but we are Still Waiting for the Promised Revolution”, The

Independent, 15 March.

Kleim, R. L. Ludin, I. S. (2000). Reducing Project Risk. Gower.

Kling, R. (1990). “Information Systems, Social Transformations, and Quality of

Life”. Communications of the ACM, 76-84.

Laudon, K. C (1993). Business Information Systems: A Problem-Solving

Approach. 2nd Edition. Fort Worth: Dryden Press.

Laudon, K. C (1996). Management Information Systems: Organisations and

Technology. 4th Edition. Prentice Hall.

Lawrence, M. (2003). “Are You Up to It”, The Computer Bulletin, Vol. 45, No.

2, pp. 22 – 23.

Lederer, A.L. Mendelow, A.L. (1988). “Convincing Top Management of the

Strategic Potential of Information Systems”, MIS Quarterly, December, pp.

525 - 534.

Leifer, R. (1988). “Matching Computer-Based Information Systems with

Organisational Structures”. MIS Quarterly, Vol. 12, No. 1, pp. 63-73.

Lewin, M. D. (2002). Better Software Project Management: A Primer for

Success. Wiley.

Lewin, M. Rosenau, M. D. (1988). Software Project Management: Step by

Step, 2nd Edition. Lewin Associates Inc.

Lock, D. (1998). The Gower Handbook of Management. 4th Edition. Aldershot:

Gower.



Lyytinen, K. (1988). “Expectation Failure Concept and Systems Analyst View

of Information Systems Failure: Results of an Exploratory Study”, North-

Holland Information Management, Vol. 14, pp. 45-56.

Mantel, S. J. Meredith, J. R. Scott, S. M. Sutton, M. (2001). Project

Management in Practice. Wiley.

Markus, L. M. (1983). “Power, Politics and MIS Implementation”.

Communications of the ACM, 26 (6), 430-444.

May, T. (2001) Social Research: Issues, Methods and Process 3rd Edition,

Open University Press.

McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules.

Redmond Wash: Microsoft Press.

McCrossan, L. (1984). A Handbook for Interviewers. Social Survey Division.

Mitev, N. (1996). “More than a failure? The computerized reservation systems

at French Railways”. Information Technology & People, 9 (4), 8-19.

Mobey, A. Parker, D. (2002). “Risk Evaluation and its Importance to Project

Implementation”. Work Study. 51. (4) pp.202-206. MCB UP Limited.

Mukherji, A. (2002). “The Evolution of Information Systems: Their Impact on

Organisations and Structures”, Management Decision, 40, 5, pp. 497-507.

Nunes, M. B. Annansingh, F (2000). “The Risk Factor”. IMIS Journal 12 (6),

pp 10 - 12.

Olson, D. L. (2001). Introduction to Information Systems Project Management.

Irwin: McGraw-Hill.



Oppenheim, A.N. (2000). Questionnaire Design, Interviewing and Attitude

Measurement. London. Continuum.

Orlikowski, W.J. Baroudi, (1991). J.J. "Studying Information Technology in

Organizations: Research Approaches and Assumptions", Information Systems

Research (2), pp. 1-28.

Ould, M. (1990). Strategies for Software Engineering: The Management of

Risk and Quality. Wiley: New York.

Oz, E. (1994). “When Professional Standards are Lax. The Confirm Failure

and its Lessons”. Communications of the ACM, 37 (10).

Patton, M.Q. (1990 or 2002). Qualitative Research and Evaluation Methods.

3rd Edition, London: Sage.

Poulymenakou, A. Holmes, A. (1996). “A Contingency Failure for the

Investigation of Information Systems Failure.” European Journal of

Information Systems, 5, 34-46.

Pressman, R.S. (1987). Software Engineering: A Practitioners Approach

McGraw-Hill

Pressman, R. S. (1997). Software Engineering for Information Systems.

Blackwell Scientific Publications, Oxford.

Price Waterhouse Technology Review. (1999). “The Big Spenders”,

Information and Strategy, December 1998/1999.

QinetiQ. (2003). “Case Study: Swanwick Air Traffic Control Centre”. QinetiQ

Ltd.



Rainer, R.K., Snyder, C.A., Carr, H.H. (1991). “Risk Analysis for Information

Technology”, Journal of Management Information Systems, Volume 8,

Number 1, pp.129-147.

Rawlinson, J.A. (1987). "Report on the Therac-25," OCTRF/OCI Physicists

Meeting, Kingston, Ont., Canada, May 7.

Redmill.F. (1991). “Risk Management is for everyone”, Part 1.Volume 1. Issue

1, pp 58-60.

Ritchie, B. Marshall, D. Eardley, A. (1998). Information Systems in Business.

International Thomson Business Press.

Robson, C. (2002) Real World Research: A Resource for Social Scientists

and Practitioner-Researchers, 2nd Edition, Blackwell Publishers.

Sadgrove.K. (1996). The Complete Guide to Business Risk Management.

Gower, Aldershot.

Sallis, P. et al. (1995) Software Engineering, Practice, Management,

Improvement. Addison-Wesley Publishing.

Schach, S. (1996) Software Engineering 2nd Edition. Richard D. Irwin, Inc.

Sherer, S. A. (1992). Software Failure Risk: Measurement and Management.

Plenum Press: New York and London.

Sherer, S. A. (1997). “The Risky Business of Managing Information Systems”

[Online] http://hsb.baylor.edu/ramsower/ais.ac.97/papers/sherer.htm

[Accessed 6 August 2003].

Sommerville, I. (1985). Software Engineering. 2nd Edition. Addison Wesley.

Sommerville, I. (1992). Software Engineering. Addison-Wesley, Wokingham.


http://hsb.baylor.edu/ramsower/ais.ac.97/papers/sherer.htm


Youll, D. P. (1990). Making Software Development Visible. Wiley.

Stamoulis, D. S. Martakos D. I. (2000). “Accommodating the Business

Context of the Information Systems into the Requirements Engineering

Process: the Need for an Interpretive Method and Research Issues”.

Department of Informatics, University of Athens.

Standing, C. (1998). “Myths and the Art of Deception in Information Systems”.

Work Study, Vol. 47, No. 1, pp.5-13.

Stoner, J. A. F. (1992). Management, 5th Edition. Prentice Hall.

Tchankova, L (2002). Risk identification - Basic Stage in Risk Management.

Environmental Management and Health. 13 (3).

Turner, J. A. (1980). “Improving the Quality of Information Systems

Research”. Proceedings of the First International Conference on Information

Systems, Philadelphia, pp. 91-97.

Turner, R. J. (1993). The Handbook of Project Based Management. McGraw

Hill.

University of Sheffield (2001). Risk Management. Module 3 Unit 8. M3G2001.

Van Horn, R. L. (1973). “Empirical Studies on Management Information

Systems”. Database, 5, pp. 172 – 180.

Vitale, M. R. (1986). “The Growing Risk of Information Systems Success”,

MIS Quarterly, Volume. 10, Number 4, pp.327-334.

Warner, T. (1996). Communication Skills for Information Systems. Pitman.

Wetherbe, J. (1999). Information Technology for Management: Making

Connections for Strategic Advantage. New York: Wiley.



Watts, S. (1993). “Report Prompts Resignation of Ambulance Boss”. The

Independent, 26 February, 1.

Whyte, G. Bytheway, A. (1996). “Factors Affecting Information Systems’

Success”. International Journal of Service Industry Management, Vol. 7, No.

1, pp. 74-93.

Wiegers, K. (1998). “Know Your Enemy: Software Risk Management”.

Software Development Magazine, October 1998.

Willcocks, L. P. Feeny, D. F. (1997). Managing IT as a Strategic Resource.

London: McGraw Hill.

Williams, L.T. (1997). “Planning and Managing the Information System - A

Managers Guide”. Industrial Management & Data Systems, 97, 5, pp.187-191.

Wiseman, C. (1985). Strategy and Computers: Information Systems as

Competitive Weapons. Dow Jones-Irwin, Homewood, IL.

World Bank Group. (2002). “Data Collection Methods”, [Online]. The World

Bank Group. http://www.worldbank.org/poverty/impact/methods/datacoll.htm

[Accessed 7 August 2003

Yasin, M. M. Quigley, J. (1994). “The Utility of Information Systems: Views of

CEOs and Information Systems Executives”. Industrial Management & Data

Systems, 94, 5, pp. 25-29.

Yeates, D. (1986) Systems Project Management Pitman, London.

Yeates, D. Cadle, J. (1996). Project Management for Information Systems, 2nd

edition. Pitman.

Yin, R. K. (1994). Case Study Research, Design and Methods, 2nd Edition.

Newbury Park, Sage Publications.


http://www.worldbank.org/poverty/impact/methods/datacoll.htm

Appendices Ritesh Hira

AAppppeennddiicceess

____________________________________________________________________________________________

Appendix 1 Identification of Project problems using

Cadle & Yeates Risk Identification Framework 182

Appendix 2 Interview Questions 196

Appendix 3 Interview 1 Transcripts 200




Appendix 7 Global Events, Problems and Risks

of the Informe Development 246

MSc Dissertation

181

Appendix 1: Identification of Project problems using Cadle & Yeates Risk Identification Framework Ritesh Hira

Categories London Ambulance Service

Computer Aided Dispatch System Taurus London Stock Exchange Therac 25

Commercial background (inappropriate/ unclear contracts or business case unsound)

The people appointed on the LAS board to make decisions were not sure of their responsibility (Health Service journal, 1993). This was especially the case when setting the £1.5m budget. At this stage an informed discussion was not taken and was only agreed based on the recommendations of external contractors.

Contract (work scope not agreed by stakeholders)

The same team [outside contractor and non technical manager] that carried out the systems requirement specification also undertook the technical evaluation of tenders for the contract to build the system. No internal LAS staff or specialists were involved at this critical stage of development to ensure that all key requirements were covered or that the most suitable vendor had been selected to carry out development. The CEO of LAS set the deadline date for final implementation and the outline budget without prior consultation with the LAS board. The deadline date was far too tight and rigid and furthermore it has emerged that the chosen vendor was selected on their ability to deliver by the chosen date rather than its technical ability.

MSc Dissertation

182


London Ambulance Service Categories Computer Aided Dispatch System Taurus London Stock Exchange Therac 25

Customer (Access to customer staff difficult/ hard to get decisions made, different customers perspectives or commitment levels

LAS had undergone many changes that led to a corporate culture being developed, the culture developed was one of fear of failure in which the pressure to succeed outweighed virtually any other consideration. This would have placed undue pressure on management concerned with CAD to ensure that the system was implemented to timetable and budget. There was a lack of effective control at the top and an inability to manage lower down resulting in doubts and problems being discussed.

The role of senior management in the Taurus development was limited; the important committee members that were given responsibility in managing the projects progress were unable to discover the true state of development. Certain groups who were monitoring development met for a mere 90 minutes a month. Communication between the development team was difficult as the team was split over two sites geographically remote from each other.




User (lack of commitment, unfamiliar with technology, inadequate user time spent)

The LAS operators due to a lack of formal training faced a rising tide of unanswered new calls, exception messages and declining number of resources that were know to the system. The systems faults caused increased pressure on staff as they attempted to make the system work for a day and a half. The new system was introduced when there had been staff restructuring, staff redundancies, poor industrial relations and a lack of confidence in management. Staff training was based around competence to perform specific job which was viewed as being inadequate and low quality of user training. Training was inconsistent as the system was constantly being changed as modifications to the system were taking place.

Until two years into the development of this system the overall project did not have a project director in order to actually control what was taking place with the Taurus development.

The computer terminal used to treat patients presented a "Malfunction 54" message; the clinic in response to this could not find anything wrong with the system and continued treating patients again. This error message occurred again eventually killing two individuals due to a lack of training. The poor user interface encouraged operators to operate the system in a haphazard way; error messages that occurred were cancelled due to the poor operational training provided.

Acceptance (test plans, implementations, was system accepted?)




Functional requirements (completeness, signed-off? too high level, low level)

The systems requirements were never signed-off formally and due to the number of stakeholders with a vested interest in the system additional requirements were continually demanded by stakeholders causing systems re-working, schedules and costs to escalate.

Technical requirements (familiarity of hard/software to the developer. Sufficient technical expertise?)

The system design was based on a perfect world design where the technology was perceived to work as it is supposed to do, users do as they are told and unexpected things never happen. The real world problems were not taken into consideration when developing this system. It was viewed that the system would provide a technological fix for poor performance and automates out staff problems. Prior to implementation the CAD system was not tested fully in anything like the live conditions under which it would operate. At the same time the communications system or the procedure to fall onto the back-up system was untested.

The Siscot committee representing the major interests of the Taurus development. This committee had a number of stakeholders and therefore each stakeholder required different things from the system, the conflicting interests made for a torturous design process which produced for a highly complex system. The design itself was seen as replicating the structural inefficiencies that exist.




Performance, availability, maintainability (Did these 3 cause problems, what was the performance requirement?)

The performance of Therac 25 was questioned however the system was not withdrawn from service but a makeshift temporary fix was recommended.

Project plan (was an initial plan created, timescales? Estimates, Contingency plans, milestones & deliverables defined?)

Timetable for development was viewed as being unrealistic.

Continual requirement changes had an effect on final implementation dates where deadline dates were extended significantly at least 6 times over the life of the project. The movement of deadlines would have resulted in the likelihood of further deadlines not being met. The cost-benefit analysis of Taurus was only carried out only after the final design of the system had been completed. It was estimated that the system would make savings of £250 million over ten years and cost between £45-£50 million to develop. This was not the case; the abandoned system cost the Stock Exchange itself £75 million and made no savings at all.




Developer’s skills (Mgr/ team leader maybe new to the their role)

Systems Options were regarded as a well-established software house however they were not experienced in developing a system of this complexity within the timetable set. A more experienced supplier would have identified the dangers of developing a system of this sort in order to undertake some form of action, clearly something the selected vendor sis not do.

When it was announced that the Taurus development was to be abandoned the Financial Times (1993) reported that there was a self-delusion among the project team that stopped them from recognizing the scale of the problems with the system at an early stage of the development. The development became too technology focused and ignored the wider political and organisational issues that surrounded development.

Designers and programmers failing to address critical user issues during systems development such as operators switching from x-ray to electrons at the last minute therefore contingency was handled badly.

Project staffing (Staff availability, staff turnover, inexperienced staff)

The central control room was re-organised and had eliminated the paper based allocation boxes thus making it difficult for staff to identify incorrect systems decisions due to inadequate staff training. The software house was given the tender to develop LASCAD had no experience in developing mission critical systems nor were checks made to ensure that the proposed vendors were capable of creating such systems. The role of project management was confused and was passed around from Apricot to Systems Options. The LAS project team had no experience of project management and Systems Options had no experience of using the PRINCE methodology. Deadline set was unlikely to be met due to its rigid ness and tight timescales.




Development environment (lack of access to the development environment, developer inexperience)

The system was not designed in a real world environment. Here data such as vehicle location, status information, dispatching resources to calls from known locations was not carried out. The ideal scenario information was fed into the system and therefore the performance levels of the system was unknown together with how the system would behave in the real world was also unknown. There was no independent checks of QA procedures being in place, it later emerged that the root cause of the LAS system crash was poor software QA.

Systems software (new/ unproven software, performance overheads)

Problems associated with the vehicle tracking system and Data terminals knew the location of an ever-decreasing number of ambulances causing exception messages to increase and slowing the system down.

A decision to purchase and modify the existing US designed Vista package was problematic. This US package required 70% modifications and was designed to comply with US regulations rather than UK regulations. The continual requirement changes made it further difficult to modify the system as required. When the project was abandoned the cost of the still unfinished modifications was £14 million.




Tools and methods (Programming language insufficient to project requirements, unfamiliarity. Standard, method & language maybe unfamiliar to developers)

Vendors and regulators had overlooked computer system safety. The software was being devised in a haphazard, unsystematic fashion and receiving little meaningful review from external regulators.

Target architecture (hardware maybe new or unproven) Bought in items/third party (Limited experience of suppliers)



Categories The Performing Rights Society Confirm Reservation System Swanwick Air Traffic Control

System

Commercial background (inappropriate/ unclear contracts or business case unsound)

A detailed report on the PROMS system was presented to managers. The report was reviewed by the same external consultants who were used for the preparatory work prior to the business case being sent to the General Council. This would have caused a degree of impartiality within the reports.

AMRIS a partner of within the Confirm development also acted as both partner and prime developer within the Intrico partnership. The structure of the partnership gave the Intrico board rather than AMRIS final authority over the project causing conflicting interests as they attempted to balance their dual roles of developer and client. By 1992 the problems of Confirm had been made public and the Intrico partnership had all but collapsed with partners of the project wanting to pull out of the project

In 1994 IBM sold the project to another company, Loral and then in 1996 the project was effectively placed in someone else’s hands as Lockheed Martin bought Loral.

Contract (work scope not agreed by stakeholders)

The £1m assigned to the project definition stage was used up and IBM and Thomson were unwilling to invest further sums themselves leading to a substantial number of requirements to remain undefined.

Customer (Access to customer staff difficult/ hard to get decisions made, different customers perspectives or commitment levels

The General Council was placed responsible for controlling the organisation although the executive management prevented the General Council from taking control.

Conflicting positions of interest occur when the developer is also the end user. The design by committee approach was adopted for the Confirm development where the committee composed of members that were competitors in other areas resulting in members pursuing their own interest rather than the committees.

MSc Dissertation

190


Swanwick Air Traffic Control Categories The Performing Rights Society Confirm Reservation System System

User (lack of commitment, unfamiliar with technology, inadequate user time spent)

The senior managers involved did not understand the needs of large development projects or the needs of IT and acted, as nothing was wrong. Staff within the development had a high degree of emotional ties with the system where they clung onto the project hoping that the system will be a success even though this was not the case.

Allegations were made that the staff morale was low during the systems development although this was denied. Furthermore the number of operators was 40 controllers short of their ideal quota indicating an undue level of pressure was placed upon existing operators at the time of implementation.

Acceptance (test plans, implementations, was system accepted?)

The National Air Traffic Service (NATS) due to the scheduling of conducting these tests rejected the acceptance test plans. NATS wanted the acceptance tests done by June 1997 rather than August 1997.

Functional requirements (completeness, signed-off? too high level, low level)

The requirements were not in a form that could be understood and checked by ordinary people.

All partners did not agree systems functionality as to what was to be delivered. The number of change requests was overwhelming resulting in the system being continually changed, re-worked and modified.

Demands for system requirements changed in response to advances in surveillance technology, communications and the amount of data pilots can access from the cockpit. Requirement collation was done by a small set of air traffic controllers which was considered as not being representative of all traffic controllers.




Technical requirements (familiarity of hard/software to the developer. Sufficient technical expertise?)

A coherent design of the system was not produced for the whole system. The information required to design the database was inadequate and assumptions were made by the contractor when developing physical designs of the database.

The development was an ambitious undertaking involving the building of a computerised system more advanced than any other in the world.

Performance, availability, maintainability (Did these 3 cause problems, what was the performance requirement?)

In 1992 beta testing was conducted, at this point technical experts identified major problems with the system. Two main parts of the system were created separately and when it came to connecting these two systems together they would not work with each other. The communications between the two systems was slow and information was inaccessible.

The system containing 2 million lines of code contained 1400 bugs at one stage which more than a year to complete. In August 2000 200 bugs remained and they had to be eradicated by December of that year ready for operation causing pressure on development staff to get the system ready. The system when it went live experienced several problems which included radio communications between the ATCS and aircrafts were cutting out erratically suggesting inadequate testing that took place prior to implementation.




Project plan (was an initial plan created, timescales? Estimates, Contingency plans, milestones & deliverables defined?)

The organisation found itself struggling to cope with the demands of an ambitious down sizing project. The project was deemed ambitious as the requirement to downsizing successfully a demanding Online Transactional Processing (OLTP) application is few and far between. The size of a project like this early problem identification would be needed although it appears the serious problems associated within the PROMS development were not identified resulting in re-working and project plans needing to be changed. Of the £11m spent over the duration of the PROMS project, £8m was wasted, the delivery schedule was delayed due to software difficulties, as a result a 10-week delay was announced and then the March 1992 implementation date was abandoned with a new date being scheduled for September 1994.

The implementation date was delayed for 18 months due to systems problems that occurred.

IT problems delayed the opening of the Air Traffic Control System (ATCS) by 6 years. Repeated delays occurred wherein 1992, it was planned to be operational in 1996, and in 1997 it was 1999. There was an over confidence from Chief Executives that bugs within the system could be fixed by December 2000 even no formal assessment was undertaken to define if this would be possible. The Swanwick centre was due to open in 1996 at a cost of £350m but costs have spiralled to £623m.

Developer’s skills (Mgr/ team leader maybe new to the their role)




Project staffing (Staff availability, staff turnover, inexperienced staff)

There was a lack of effective control overseeing the control of the project team. The reporting of the projects progress was infrequent and inadequate. Staff attitude within the PROMS development encompassed of non-conductive to the successful conduct of this project. This took place in the form of staff and managers not being open about mistakes and failures, to learn from them, to be open about mistakes and failures and to learn from them.

A fear based culture developed where AMRIS employees were discouraged from speaking their minds from fear of management wrath. An optimist effect prevailed as development members only communicated to managers when there was good news and therefore senior managers did not know the true status of development at anytime. 28 IS managers left their posts during the development causing disruption to the project.

Project leaders continually changed during this development. Development was undertaken across two sites in America and the UK causing communication problems.

Development environment (lack of access to the development environment, developer inexperience)

Systems software (new/ unproven software, performance overheads)

Systems design was carried out using a CASE tool resulting in a database structure being designed by the system that has minimal influence from the developer. In the case of a system failure it was discovered that the system was irrecoverable after the failure.




Tools and methods (Programming language insufficient to project requirements, unfamiliarity. Standard, method & language maybe unfamiliar to developers)

A series of poor decisions by managers relating to systems design and technology use led to staff not being fully acquainted with the technology that was being used.

Target architecture (hardware maybe new or unproven)

The complexity of the system was underestimated resulting it not working in the way it was required to.

IBM was chosen to develop the new system although the system was based on one that was being developed in America. This meant designing the system using new hardware and original software. Off the shelf components and software should have been purchased rather than developing unique software.

Bought in items/third party (Limited experience of suppliers)


Appendix 2: Interview Questions Ritesh Hira

Appendix 2: Interview Questions

The following questions were asked to all of the selected interview respondents in a

chronological manner apart from the questions which are titled “Additional Questions

which were asked to Informe Managers”

Confidentiality and Interview Instructions

Inform Interviewee of Confidentiality arrangement (data will be made anonymous)

Tape recorder (Switch-off at anytime if she/ he is not comfortable with anything or

wants to make comments off the record.

Explanation of project (What you are planning to investigate).

Purpose of the interview (the department, general projects, Informe – risks)

Interview Questions

Could you tell us about your department?

What kind of IT department do you run?

How is the IT department structured?

How does your department fit in with other departments of BT

Who are the people that work in the IT department and what are their roles?

What is your role within the department?

Can you tell us how you go about developing new IT projects?

Did you use a BT design/ development methodology? (Does any

documentation exist? Can we have access?)

If not how do you develop IT projects?

What are the main stages which are involved in developing an IT project?

(For example Feasibility, Investigation, Analysis, Design; Build, Test,

Implement & Maintenance).

What are the main roles in developing projects

What is your role



Could you tell us about the Informe project? For example:

Prior to commencing projects were any project plan created to show when

milestones and deliverables were due?

Were these schedules communicated to the project team?

Were the schedules met?

If not then was re-working of project plans needed. Were these

communicated to the management and staff?

What was the feedback that you received to these project plans? Methodology the same? (If it was different how)

Who was in the team? (Who should I send questionnaires too)

What was their role? (What was your role)

Who were the main stakeholders? (Did these people have an impact upon the

project)

Have any project specific documents been created, if so could we have

access to them?

(Risk Definition: risk is the occurrence of an event that has consequences for, or

impacts on, projects.)

Was any kind of formal risk assessment undertaken prior to the project? What risks did you take that you were aware of? What risks did you identify and what did you do to prevent them from occurring?

What problems/events disrupted the project? (Why, what, where, when, who)

At what stage in the project did these problems/ events first occur?

Was any measures taken to deal with these problems?

Why do you think these problems occurred?

Did these problems re-occur once they were dealt with or if they were dealt

with?

Who dealt with these problems, was management made aware of them?



Were these risks documented in anyway, if so can I have access to this

document?

Who was responsible for the project when the problems first occurred?

Were these risks and problems similar to past projects?

Would you be happy to complete a questionnaire for me as part of this project at a later date?

Additional Questions which were asked to Informe Managers

Prior to commencing projects were any project plan created to show when

milestones and deliverables were due?



If not then was re-working of project plans needed. Were these

communicated to the management and staff?

What was the feedback that you received to these project plans?

Did you undertake a risk assessment of the project prior to commencing the

project? If so how was this done?

What risks did you identify and what did you do to prevent them from

occurring?

Checklist of Areas Covered

Criteria Description of Criteria

Commercial background

Inappropriate/ unclear contracts or business case

unsound

Contract Work scope not agreed by stakeholders



Criteria Description of Criteria

Customer Access to customer staff difficult/ hard to get decisions

made, different customer’s perspectives or commitment

levels

User

Lack of commitment, unfamiliar with technology,

inadequate user time spent

Acceptance Test plans, implementations, was system accepted?

Functional requirements

Completeness, signed-off? Too high level, low level

Technical requirements

Familiarity of hard/software to the developer. Sufficient

technical expertise?

Performance, availability, maintainability.

Did these 3 cause problems, what was the performance

requirement?

Project plan Was an initial plan created, timescales? Estimates,

Contingency plans, milestones & deliverables defined?

Developer’s skills Mgr/ team leader maybe new to the their role

Project staffing Staff availability, staff turnover, and inexperienced staff

Development environment

Lack of access to the development environment,

developer inexperience

Systems software New/ unproven software, performance overheads

Tools and methods

Programming language insufficient to project

requirements, unfamiliarity. Standard, method & language

maybe unfamiliar to developers

Target architecture Hardware maybe new or unproven

Bought in items/third party

Limited experience of suppliers


Appendix 3: Interview One Transcripts Ritesh Hira

Interview 1 Transcript - Date: 29/5/2003

Could you tell us about your department?

Run a team called IT solutions, deliver solutions from a computer based arena to

field operations unit within this organisation. This is mainly based around statistical

information and applications that allow management to discuss with their people

issues that effect their performance, issues such as barriers that engineers face on a

daily basis; they discuss these with their managers. We supply applications to

managers that allow them to record the issues, which engineers have. The system

will allow them to get round the barriers which engineers have on 1:1 basis. Allow

managers to record information about how managers have suggested that engineers

can develop themselves. Way of recording information about people. Also day-today

running of their (manager) jobs. Data stored on MS SQL server database. Have 10

servers storing information where it is maintained at one location.

How is the IT department structured? User Support - support team will provide advice upon any users problems users

may have with the system or will advise users on how to use the system. They will

also do the initial investigations of problems that users may have with the system.

Support team will act as an interface between end user and the development team.

Knowledge Management (KM) Team - providing the field users who use

applications with an interactive knowledge system, for example if a field user wants

to know how he should undertake a process within his job role then the knowledge

system will tell him exactly how it is done. 2-3 field coaches produce web pages;

these coaches have the knowledge of how things should be done such as putting up

a wire. These people have the knowledge and have written how procedures should

be done within the knowledge management system; IT solutions then publish this

and make the end users aware of this information.

Have close ties with the support team, they are dealing with customer issues and

problems. Customer feedback, the support team suggest to the development team

ways in which the final system could be fine-tuned to help end users to understand

applications more clearly. Have close ties with the KM team, in that there are going to

be links between the KM team and Informe. At present we are in the process of

MSc Dissertation

200


tuning the Knowledge Management system in a way that allows the interactive links

between Informe and the KM system to work.

The reporting structure goes to the manager ultimately, she has an overview of how

everything fits together, the development team is a self contained unit, it sort of runs

itself. The support team, KM team are also self-contained and sort of runs itself. They

are lead people within the teams that pull the little teams together but the IT Solutions

Manager has ultimate authority over the team and how it fits together.

How does your department fit in with other departments of this Organisation?

Main department we work for is field service. We fit into field service as an

exploitation team where we exploit technology. Our second line team is responsible

for the delivery of the laptop, all engineers have a laptop, and field users were given

laptops three years ago. Many field users embraced the laptop easily; our second

line team is responsible for researching potential opportunities.

Who are the people that work in the IT department and what are their roles?

12 people in the team: manager, 6 developers, 4 front-end support team and 2-3 in

KM team. Not all of above were involved in the development team.

I Manage the requirements, capture what the customer wants the application to do,

so what I’ve done in 6-9 months is to develop an application that allows us to record

what the requirements are and prioritise the requirements and manage them to

delivery.

How are requirements prioritised and what can wait till the next stage??

A lot of direction comes from manager’s, certain areas of the business use sort of

dictate the priority of the way or order in which we do things. We try to fit the

requirements that the client gives us in to the areas that senior managers have said

are of priority. Everything is done on a business needs basis

MSc Dissertation

201



Involved in dealing with people who produce MI and MIS, involved with system

owners and lot of people who produce statistics. Informe is about providing

information on a personal basis; I suggest changes to the way MI is being built so

that it can interface with Informe easily. Through Informe there are approx 36

systems to integrate at present, have multiple systems to integrate. I also manage

requirements that have been specified by the user.


After we go through the initial stages of capturing the user requirements, we move

onto systems/ database design then onto web design. We use a thing called

Fusebox or Coldfusion Fusebox which is a methodology of delivering modular web

pages. It allows us to split up the development into different modules. This allows us

to have 2 developers working on 2 different modules or project discretely and when

complete they can come together we can plug them into Fusebox creating joining the

different modules together. Fusebox is purely used to create web outlook, just a way

of writing a code, doesn’t capture or reflect the use of the SDLC, it doesn’t address

the lifecycle.

What are the main stages, which are involved in developing an IT project? (For example Feasibility, Investigation, Analysis, Design; Build, Test, Implement & Maintenance).

We used fusebox heavily for the development of Informe; previous projects were

written in traditional HTML graphics using Colfusion, Coldfusion is an interface

between HTML web browsers and Windows NT

Could you tell us about the Informe project? For example:

The project became big very quickly because we found out that the idea we had had

a lot of potential. Was going to grow exceptionally. At this point we felt that we

needed to get more people involved, as the potential was so great that Informe was

going to influence many people and other systems. Therefore we undertook so

requirements collation from senior managers to make sure the way Informe was

being developed was going to fit the customer’s requirements. BM played a big role

MSc Dissertation

202


in determining what information should be seen certainly from an mgt point of view

within Informe. This was the early stage of how Informe was developed.

We then held 3-4 workshops around the country to capture the detail of what end

users wanted us to supply through Informe. These meetings was used to write the

SoR, this is where I got involved at the early stages and I produced a document

which captured all the requirements from the workshops held with management

users. This document was used a starting point for where development began.

Informe would make their job easier and help them to do their job. We discovered

that some teams spent a lot of time ringing engineers up telling them to remind them

that they have their vehicle service coming up, so we decided to design a alert

system in Informe which looks forward at the moment this is 7 days and will flag to

individuals when they have got a vehicle service coming up, this acts as a reminder

until the service is due.

When the stakeholders and users were informed regarding the system, what was their reaction to the system?

Initially mistrust occurred, people felt that Informe was there to close their department

down. That was not the case. Informe aims to bring the different business areas that

people work in together and to other people’s attention. This make teams more

powerful and the role of departments is more fulfilling as what it should do. Once this

thought process is in place then people accept this way of working or the reason why

Informe is there and is the best way for the business.

To get people on our side the way to do this is sell benefits to users, one of the

benefits is that Informe will make individual and team jobs easier. Takes a lot of

legwork and manual work out of the job role. Brings information to users rather than

them having to physically obtain it or look for it. In the case of vehicle maintenance,

vehicles were due for maintenance but were not turning up as required costing the

business money.

MSc Dissertation

203


What improved through Informe?

Difficult to measure this as we are in the early stages of development, what’s easy to

see is that issues and problems are displayed to people rather than having to go and

find it. As a manager you can spend a lot of time trying to find a problem of some

form only to find there is no problem. More efficient, Informe pulls problems to

manager for example managers and individuals can be informed about any repeat

report they or their staff have. Until it has been fully exploited and used by users it is

difficult to measure its impact, its potential impact is immense.

The Informe system is continually being changed and tweaked, the versions that are

released are based upon the major requirement changes that take place as the

business needs or requirements change or what we have delivered does not fitted

with what the customer wanted so we have to go away and re-design the system to

capture these new requirements or the requirements we did not fully understand.

These are the main reasons for the different versions and version change.

Version 2 of Informe has a completely different communications package built into it

as the business needs a change and we didn’t think of everything when we initially

designed the system. The business will dictate that we go on developing the Informe

project forever, they’re maybe a cut off point for Informe but it’s along way off. “Said

to Val this will keep us in the job for a while.” I don’t see an end date

Was any kind of formal risk assessment undertaken prior to the project?

One of the big risks is to deliver or develop the application that does not meet the

customer’s needs or does not do, as they required.

The plan we had to counter this was version control and version delivery. If Version 1

didn’t fit the customer’s requirement then Version 2 would deal with this and make

sure problems in Version 1 were addressed in Version 2.

Problem: User commitment, a lot of people especially at the engineer level not

always fully familiar with computer technology, not always prepared to run with it. To

counter this especially with Version 1 and the initial release of Informe is that we

went round the country holding road shows, training or familiarity events where we

MSc Dissertation

204


show the manager of the team the Informe application and we sell them the concept,

we show the coaches of the team the application and concept of Informe.

At the end when we finish we asked the managers to inform their staff of the benefits

of the project and sell the concept, benefits and product to the team. Telling them

what benefits they could get from the product. That was the plan and counter plan to

reducing user commitment.

We have also provided an information pack to users and managers of the team

telling them about Informe. Consists a document of the application, an overview of

Informe and its benefits of the application, and user’s benefits that can be derived.

The interviewee was not aware of using any risk assessment framework during this

project but is conscious that such generic frameworks do exist in this company, “we

may have used it sub-consciously but I’m not aware. Couldn’t answer fully.

What risks did you take that you were aware of?

Whilst we were capturing the customers requirements for the application we felt that

there were certain things that the users needed to know and that did not always

reflect in what they asked us to develop the application to tell them (can’t think of a

specific example). We felt that there were certain things that the users need to be

aware of, that were perhaps a risk as we are telling people things that they don’t want

to hear. To counter this sometimes the thing that people don’t want to hear are things

as managers they are expected to deal with. For example if a user asks for annual

leave and the way the business is structured annual leave can be flatly refused and

then they may decide to take a sick day anyway, this is something managers need to

deal with, this was something that was not asked for with this application but the

development team felt that this was something they needed to deal with and

therefore we provided this through Informe anyway give the user what they don’t

want A risk here is that users have not asked for this but we have provided it.

Interview could not think of that many risks at the time of the interview

What risks did you identify and what did you do to prevent them from occurring? See response in this document

MSc Dissertation

205


What problems/events disrupted the project? (Why, what, where, when, who) Early on when we were designing the initial stages of the application we got involved

with the MI section of Informe, we went to see senior managers about what they

thought should be delivered as far as MI was concerned through Informe, we

captured management requirements, and management was highlighted as

representing management within his level of the organisation. Went away, designed

the system to fit what management requirements were, came back some months

later presented to management what we had developed, management was happy

with it. We then continued to develop the remaining interfaces or parts of the system,

we then got to version 1 of the Informe trials and management team was the first

people we conducted the trials with. The system was presented to management

team they stated that it did not do what was required; at this point we had to start all

over again. As a result we had a delay of 3-4 months to the initial trial release, were

disappointed to this and people like management were disappointed with the delay.

Very difficult to identify why problems like this happen, my thoughts are we recorded

the requirements accurately and delivered the system based upon these

requirements. However when it came to the trails for the users either I feel the user

requirements had moved on during the interim period, we recorded the requirements

wrong or we delivered the wrong thing. Difficult to identify which of three it was.

I suspect it was a mixture of all three. To counter this problem from now on what will

happen once the user requirements have been captured they will be documented

detailed the requirements that have been requested. This document will be circulated

around the users of the system and they will be asked to sign-off the document

asking that the requirements that they have asked for is definitely what they asked for

and want. At this stage the application will be built based on this document and

requirement.

With Informe we developed a dummy application which is an application that is a

concept, a flat HTML document or web page that has all of the elements that Informe

can do. This is used to demo to users what Informe will deliver. That model is used

during the familiarisation stage or the training period. User feedback is gained during

training events when we use this model. We also have a bolt in application to Informe

which is designed to catch online feedback, this online feedback is used to constantly

MSc Dissertation

206


modify and tweak the system. This online feedback tool was used to capture some of

the initial requirements early on with the development

Lack of communications between our team and people like management. It has

happened on many occasions where its not clearly communicated what will be

delivered and what want. The lack of communications has been a problem not just

with Informe but with other developments I have worked in. There is a lack of clear

communications hierarchically, this may be because people are too focused on their

own area and are busy doing their own thing and not focusing on the bigger picture

all the time.

We got the requirements wrong when dealing with management requirements in

terms of MI. We went back and totally clarified what management requirements were

and started again. This problem was a collective fault of the team as our

responsibility was too clearly communicates to management what we were delivering

and management responsibility was to clearly communicate to us whether it matched

his requirements. I think this broke down in both areas. This cause = a lack of

communications between both parties.

How’s it improved: we have a plan in place now to alleviate in place where we

document the requirements clearly what was agreed by the clients and have this

document available to the interested people. There is facility to sign off this document

off as required but this does not always happen but there is this facility. If its not

signed off then customers can continue to state that they did not request such

requirements causing re-working at a later stage. This is possible and is a problem.

The business needs change and so will the requirements and we can’t afford to get

tied up in red tape and accurate systems development. Development needs to be

fluid allowing us to react quickly without working to red tape. This is what feeds the

lack of sign off and clear Statement of Requirements (SoR).

I think we need to use the backdoor method with systems development in order to

reduce the time it takes to complete certain parts of the development, this way

development methods aren’t used, formal communications, sign off and clear SoRs

are not carried out. Things can be done quicker using the informal methods however

I know it carries risk. I think this is where we went wrong in the case of management,

where we got it wrong. If we used formal rigid methods like sign off etc I’m not sure

MSc Dissertation

207


whether we would have saved those 3-4 months re-working or would have done it

quicker in that were lost in re-working Informe? I think it would have ended up the

same way had we used formal methods or not.

Problem: Lack of clear project plan, a project plan was not created or there wasn’t

one that any one of us was aware of. A project plan was not created prior to starting

one, none of us was aware of such plans being in existence. “Management would

love me for saying this but I’m sure the manager had a project plan in her head.”

Extracting this information from her head is difficult. Not until a Project Manager got

involved a plan was developed, this plan was not seen by any us which was created;

don’t think it was communicated to the rest of us. Actual plan not seen by team,

suspect the Project Manager had a project plan.

If a certain piece of work was required to be done a certain time then this was

communicated via email or verbally. This did not work well as things that are done

verbally people change their mind which is a risk. However if things are done on

paper and signed-off then this will be done according to the document, more

formalised. People did change their mind about work schedules and delegation

during the Informe project.

At present we have a system which records the requirements, they are given a

delivery date, people can update the delivery of requirement as to how its

progressing and flag up any issues, create dependent issues that are to happen as a

result of requirements being implemented, more formalised process now. DM owns

the system.

The PM was loaned in as a P mgr, not the case anymore and therefore for the last 3-

4 weeks we have no P mgr for the Informe project. It has been discussed with the

team that a project manager is needed; this will be appointed to a person in the team

or someone external. If it were an external person who is new to the project then they

would have to be fully briefed about the project. This won’t take up much time as we

all do some form of project management, if we had a formal project manager then it

would be in an overview role.

A centralised document does not exist which shows all the decisions that have been

made, problems discussed and issues flagged up as this has been done using email

which is regarded as a primary communication tool, use this as documentation as to

MSc Dissertation

208


what has been discussed but no overall document which outlines all the problems we

have had. Not sure if Val has a document in relation to this.

Informe was the first project which we have been involved in which was heavily

dependent on user input. Prior we were feeding the users imagination rather than the

user asking us for things. Prior we were leading development from the front but this

was the first time with Informe we were faced with problems that we have not

experienced before. 2nd time I have been involved in a project of this sort.

Management and bottom end users whom share a general apathy have affected the

Informe project. These people are stuck in their ways and don’t want change. These

people are not visionary and won’t accept new technology.

Were these risks and problems similar to past projects? Yes, have worked on other projects were I have suffered similar problems

Would you be happy to complete a questionnaire for me as part of this project at a later date? Yes

MSc Dissertation

209

Appendix 4: Interview Two Transcripts Ritesh Hira

Interview 2 Transcript - Date: 29/5/2003


Developer/ system architect – have two roles, I liaise with other software

development teams, some customers, I take some of the requirements from such as

Dave Mills and I create a plan and carry out the plan into the programming. These

plans are created in my head not documented. To relate a similar concept for the

Informe project Val Lewis had an idea in her head and I had to extract this idea out of

her head together with requirements that she had discussed with people such as Bob

and get that into some sort of plan and create a Mock up and move that along into

working product.

Requirements have been documented, things like I want it to show me a message

system or repeat reports for example were as detailed as it ever got. Dave Mills was

the person who was in charge of requirements collation. We got these requirements

and created a static webpage top present to users telling them what Informe looked

like. In previous project carried out we haven’t done much user requirement

documents. We don’t do a great deal of user documentation.

Static websites are presented which in turn generate further requirements which

Dave then collates. The requirement collation hasn’t worked in the Informe project,

as “people don’t know what they want so they won’t get it”. For example people will

say that I want a message system and that’s all they will say, we go and produce

this, when we come back and present it its not what they want, they wanted

something else.

My role within Informe is ‘jack of all trades’ at the moment, all developers have to

carry out a role of SA and developer, this happens with all projects.

The procedure is that as developer he will go to the customer and collate the

requirements from the user, design the system in his head or a bit of paper, no

documentation.

MSc Dissertation

210


Why are you taking on a dual role/ why are you being asked to carry out so many roles? Where does the buck lie? “Wouldn’t like to say” The need is that we have to get the applications out as fast as

possible; therefore the solution is quick and dirty. We were asked to do this by all

lines of management, management see us as a cost overhead, we have to be seen

as continually producing and producing quickly or the axe may come down, this is the

feeling I am getting.

What is being done if anything by management to reduce your workload?

Not a lot I see as being increased, as well as a SA and developer role I have a DBA

role as well. I’m not trained in this role but when other developers are not here I do

their job.


The processes we have done are written the requirements down on “the back of a

fag packet” and go away and produce roughly something what the client wanted. We

add our own little things which the customer has not asked for, such as a security

system for example. The users doesn’t get to okay the requirements they come to us

and say we want one of these and one of these and we go away and produce it.

They then say I want this; this and this we go away and do this, which results in a hell

of a lot of re-working. The customer feedback is that they will eventually get what

they ask for.

What about costs?? That’s another problem that we have, we work internal to BT

so the cost is hidden from the customer. We are aware of the timescales but the

projects are taking longer than they have ever needed to be. Why?? I think this is

because we have never used any formal process.

In the case of Informe we have had to change the whole underlying structure of

Informe because someone wanted a special type of messaging, rather than send

messages to all engineers they wanted to send a particular message some

engineers. In my opinion I don’t think that the requirements were done well enough in

the beginning and therefore all requirements were not captured resulting in re-

working and this has always been the case we don’t do enough systems analysis

MSc Dissertation

211


work other than what we do ourselves as there is no one in the team who does

system analysis work. As we have not systems analysis done, we do the

programming and when we present to the customer they want it changing.

The system is not provided to us as what is required exactly. The developers are also

responsible for SA, Dave also a developer’s now has taken up a customer interface

role. Dave collates the requirements for the Informe project however this is not going

into significant details for example “I want a pre report figure” is a requirement that is

passed to me and is not detailed enough.

I have a dual role in that the SA and developer role as addressed in the SDLC, I feel

should be separate, however I am taking on a dual role. I feel the SA role should

base the requirements out at Pseudo code level where I develop the system but this

is not taking place and nor has done.

Figure 1 - Systems Development Stages within IT Solutions

acceptance

testing.

Trial Areas users expect systems to be working at this time. Numbers kept toa small audience

Development

Small user base for customer

Develop code & system.

"This is plannedin the head"

SOR Client requirement

Collation

System Analysis

Did you use a design/ development methodology? (Does any documentation exist? Can we have access?)

Not all developers develop in the same methodology. I try to use Fusebox which is

the way we develop applications. Fusebox is a coding standard but not all developers

use Fusebox as they don’t understand it and are still learning it.

MSc Dissertation

212


This methodology is not documented in house but is on the web where we refer.

Developers have had knowledge shortfalls in this area and have purchased books

out of their own pocket; we haven’t been training in the development methods.

Have long have you been using Fusebox? .

I’ve been using it the longest 3-4 years. We used this methodology as prior we were

using Cold fusion. I looked at Fusebox after reading the magazine and I could see

the benefits of using it, there was no formal review as to whether we should use it

and there are no standards within our team that we have to follow, no development

lifecycles.


Fusebox: I use it, Vince does but struggles with it a lot of the time, and other

developers use their own method and won’t use Fusebox. The different methodology

use between one developer and the other has caused problems if one developer was

working on one part of the project and if another developer took over, using different

methods has caused problems.

Why are people using different methods??

This is based on personal preference; there is no standard way of working. Managers

have enforced no standards. People are still learning to use methodologies, we have

to accommodate this. The training of methods is done learn as you go along. If you

have a problem here is how you solve it, no formal methods. Buddying sort of

training.

What are the main stages which are involved in developing an IT project? (For example Feasibility, Investigation, Analysis, Design; Build, Test, Implement & Maintenance).

When we develop projects we don’t use a formal methodology.

MSc Dissertation

213


Why don’t you use standards?? Purely opinion but I think some of the people don’t want to learn it, don’t want the

rigid structures and processes or boundaries; they want to fiddle about with the

program as to how they want it. They then go back and fiddle about with it some

more and so on. They then go to the customer and then adjust it further which I think

is a more fun way to do it this way.

Using this method does this impact upon the timescales, would you deliver on time?

Yes we can but the customer doesn’t always get what they want, we have to take

some requirements out and deliver these at a later stage.

How well do you communicate as a team? As a team we don’t communicate well at all as a team, the individuals of the team are

not very good communicators, this is because ego’s are involved where we are not

prepared to listen to others point of view. We don’t talk to one another within the

team well because the development team are spread around the country.

How effective was P Management,

They manage the issues we inform them of and processes. They have a goal but

don’t know how to achieve this goal. Project managers don’t get involved with the

development lifecycle. There is no plan with key dates, no project plan, we have

been with Informe for 2 years and we’re going to get a plan now.

To meet deadlines we have had to cut corners, for the Informe project, the version 1

that is out there now was rushed, we had to get the quickest and dirtiest version out

there, for example the messaging system was not fully specified properly, it took 2-3

attempts to get this system remotely right, this resulted in a lot of re-working.

Reporting: Management knows that I’m working on Informe but she doesn’t know

which part of Informe I am working on only until I tell her, I don’t tell other developers

what I’m doing just management when I tell her or when she asks.

MSc Dissertation

214


Do you inform Management on a weekly basis as to where you are with the development of Informe?

This has come out at group team meeting where we have to write a report as to what

we have done on a weekly basis, this is seen as time consuming and takes you away

from your work. General consensus at the meeting was that we couldn’t be bothered

to do status reporting.

I am creating the Version 1 and Version 2 where modifications are being done to

Version 1 and a new structure is being developed in Version 2 causing duplicate

work as both systems need to be updated and modified at the same time, the focus

is on Version 1 than Version 2.

We don’t follow standards and therefore we just meet the deadline. Here we have

three deadline dates for example in the Informe version 2 projects we have the best

date, the real date and the fail sort of date. NO SET DEADLINE

Version 2 is a complete re-design of version 1 because of all the corners we cut with

Version 1. All the extra requirements of Version 1 have been placed in the

requirements scoping of Version 2.

Testing: we do some testing in house but there is no formal testing that takes place

this is carried out when the users come face to face with the system, when it comes

to customer acceptance testing they expect it to be bug free, any vigorous testing is

done with users when it goes live, they don’t expect the system failing. Any problems

that occur will need to be fixed in Version 1.

Implementation is done by the trainers the trainers these people roll out to the users.

I do maintenance but I don’t get involved with the implementation stage this is done

by the trainers. Any bugs are fed back to me by the trainers via email, verbally,

phone call, these problems have been documented but not all of the trainers have

done this and the problems are only as good as what they type in. I have had

problems documented “saying Informe is faulty, fix it.”

Communication big problem from start to finish, not enough done by the project

teams, nor was they’re any clear reporting mechanism in place.

MSc Dissertation

215


Who were the main stakeholders? (Did these people have an impact upon the project) Level 2 managers for trail areas - BM teams were the customers.

Suppliers - Data mart/ Launch pad these caused a few problems

Employee Comms people had an impact on the design of communications tools, the

messaging system. These people have had major impacts upon development; they

have placed some requirements that have caused a major structure change to

Informe. The project was impacted by Employee Comms significantly; Employee

Comms requirements cause radical re-design of the system. Additional requirements

have placed the timescales further back as we have to re-design the system to

accommodate these additional requirements.

All of this re-working had to be done because we didn’t go to these stakeholders in

the first place or we didn’t get enough detail initial from them to find out what they

exactly wanted. We develop the system based on what they specify, go away and do

it and then go back to them to find out that they want something else causing re-

design. Cutting corners did this had we spent more time on the initial requirement

and finding out what they wanted then we would have got it right in the first place

Have any project specific documents been created, if so could we have access to them?

We have created user docs to show how to operate web interface, help files exist but

not populated. We have view lets which is little animation to show the user how to do

certain things. People don’t use help files because they fiddle about with the system.

When they have had enough they will ring the implementations up to ask how to

operate the system. System doc has been attempted but the system is changing so

rapidly that its difficult to do, furthermore there were multiple versions of the same

documents, this caused problems as we couldn’t agree upon the documentation.

The code continually changed and therefore this was not documented in the system

spec, therefore system is not reflected in the system spec as its not been updated.


No formal risk assessment taken, we were aware of some risks that we were taking.

MSc Dissertation

216



We were committing ourselves to a timescale without a formal project plan, key

stages to hit for example.

We didn’t get the requirements from the customer bottomed out before we moved

onto the next stage, caused re-working, timescales were affected. We only realised

this as we went along with development. We thought we got it right but we didn’t.

The hardware, which we used and still do, wasn’t planned or scaled, we just hoped it

would work. We didn’t assess the impact of the hardware and software and what it

would have on development, although there has been no problems so far.

We were developing the system in an environment that was not the same as the

functional environment. The platforms where different at the beginning of the

development, to rectify this we bought the same platform as the one which users

would use.

We weren’t aware of the buy in which we would have from customers, the idea was a

concept. It been accepted on the whole. We asked key customers but we didn’t

approach user at the grass roots level whether they wanted the system. At the outset

this was case but since then we have asked for feedback. The risk here was did they

want the system in the first place, we just assumed that they did. We consulted

management level regarding the Informe project but not at the bottom user level.

The feedback to Informe was that they liked the concept, when it came to introducing

the system its not what they wanted after all, this maybe because the old system,

toolkit was still live and therefore people were using this, people didn’t want change.

We had performance issues with Informe due to the lack of planning and scalability

most likely. We were asked to add more and more queries and more and more

functions onto the original design of the page The concept evolved to a great extent

to what it was before, this involved more designing and coding. This is all based on

user feedback, internal feedback and management.

MSc Dissertation

217


How do you decide what feedback to integrate into the system?

Based on a committee of people who work on the project plus certain key customers

like senior managers. We decided to base the feedback on the work scope that we

had and input from the team and management.

Did not know about these risks at the start but became aware of them as time went

on.

The lack of formal methodologies and standards was a risk the team took.

What risks did you identify and what did you do to prevent them from occurring?

600 risks have been documented on 6 pages of paper which suggests that they are

not well detailed, nothing done to rectify this apart from DM being appointed to look

after the requirements but still they are not detailed enough


The big one is the requirements capture process, we didn’t do it very well which

resulted in re-work which was pushed timescales further as we had a date for when

we had to deliver. The groundwork for the requirements capture was not done using

a lifecycle before we got to the coding stage. We went from high-level requirements

capture to coding.

What about now?

The problems will re-surface unless we use some sort of processes like SDLC.

These decisions need to be made by management; they see it as a barrier to

development.

The problems lie within the team, as they won’t use one consistent methodology

within the team. A lot of them don’t know any other methodology apart from what

they have developed in their head which is an anarchistic approach; this is probably

due to the lack of formal training.

MSc Dissertation

218


I don’t think the manager is aware of what programming is involved; she’s not

technically minded. Manager has a lack of technical expertise and thinks that

programming is simple, developers don’t dissuade her from this and if she sets a

deadline then it will be delivered regardless of faults. If there are faults with the live

system so be it, it will be fixed at a later date. Management is informed of these

errors but due to a lack of knowledge she does not understand this information.

The requirements capture part is not done fully; as a result timescales are shortened,

as deadlines have to be met. Additional requirements have to be developed within

the timeframe causing undue pressure. The managers, self-pressure and the team

do this. The team tries to deliver the requirements, as you don’t want to be seen as

failing or not meeting the timescales. I have approached management about these

problems but not much has been done to rectify the problem, I just have to work

additional hours to make up the lost time.

When asked about when Version 2 would be developed I just come up with a figure

out of my head I don’t follow any planning procedures in order to come up with the

date, I just use the rule of thumb approach. We don’t that much planning into

schedules Val will ask when it will be done by and we provide her with a date. I have

a number of projects on the go if I give them a date then as time goes on the

pressure will be on to deliver the Informe Version 2, this will have knock on effects on

other projects like schedules will be affected.

Informe project entailed more and more work and less time in which I had to say yes

to the work due to the peer pressure because if I didn’t do it then the next person will

say yes and it comes back to me anyway so I agree to do it.

During the informe projects I and other developers have had to say yes we will get

this done and will produce what is required to safeguard a job for the future, it has

been mentioned quite a bit where if we don’t do this then we might not have a job.

FEAR FACTOR, this has been mentioned by managers higher up. We have been

told that we need to keep producing or this could happen [might not have a job].

Managers from different department have been telling their users not to use Informe

but use the old system ‘tool kit’ which is also operational. Need to shut tool kit down

to get everyone to use Informe but this is not the case at present.

MSc Dissertation

219


During Informe I have had to do a lot of overtime, we have 4 hours overtime a week

and that’s it, anymore and we don’t get paid for it, caused personal problems. I

wasn’t happy with it.

During requirements collation management provided a series of requirements that

were implemented however after this management changes the requirements. The

sign-off was not done verbally. System had to be re-worked due to this.

I don’t think we had enough time to quiz the users in order to understand the

requirements.

The JRP & JAD workshops were never long enough or frequent enough to make

sure that system that was being developed was adequate. Cost estimation was done

on a rule of thumb basis with the finger in the air technique based on experience, this

estimation was way off. If an estimate is made and is way of the ark then no one will

know about it. No one has got a handle on how much a project costs and what

savings are made, this has been the case with Informe.

Were these risks and problems similar to past projects? The problems defined for the Informe project have also occurred identically in past

projects, no difference. Management have been made aware of problems that have

occurred in past projects but I wouldn’t say this is the case for all of them, they have

been made aware of some but they haven’t sunk in as we are still making the same

mistakes. Why do you think this is?? This because we haven’t had a catastrophic

failure as yet. Till this occurs we will carry on as we are doing. We have always

managed to deliver by the “skin of our teeth.” We have managed to make any

changes to the system based on user feedback and deliver in time. We are a disaster

waiting to happen, till this occurs there will be no change.

There is no PIR where after the system is delivered we sit down with the user and

learn from any problems, issues that may have arisen from this project and try not to

do it next time. “We carry out a review within the team but this isn’t formalised or

agreed by other parties. The development team don’t agree on how to develop or run

the project some of team like the anarchist approach, some people prefer boundaries

and some prefer a rigorous methodology.

MSc Dissertation

220


If a formal SDLC were introduced to the development team would it be used?

No, as we are so used to working in an anarchist mode, it’s hard to go back to a

rigorous process. Management would need to enforce this within the team. We are

stuck in our ways from top to bottom.

What’s the way forward?

Specialise jobs more, don’t have one person have so many roles like SA, developer

etc. Agree the way we should do things and stick to the same process. This can only

be done through discipline. Need to agree to the same standards, use documentation

more.

Managers are aware that standards, processes do exist and should be used in the

development of Informe but they won’t admit to this.

If the Informe system failed who would get the blame? The developers and me would be pinpointed and would get the blame, management

would not be pinpointed. To avoid this we do as management says.

Would you be happy to complete a questionnaire for me as part of this project at a later date? Yes

MSc Dissertation

221

Appendix 5: Interview Three Transcripts Ritesh Hira

Interview 3 Transcript

What was your role in the Informe project?

I wasn’t really a Project Manager for this project was just a dog’s body that

coordinated work, arranged events. I just added a bit of structure into the project.

What was IT Solutions Management role?

Val so an opportunity and kicked it off which was being driven by the organisation

She just set the project off, we didn’t investigate what the benefits could be of doing

this, it was just go away and do it. As development progressed and as the project

was getting big she thought of getting a Project Manager in.

When PM role was changed was there a handover?

No handover, no project plan, there was nothing, there was documents for me to look

at. We had workshops where we were told about the concept; this is when I

understood what was being done. We did have an idea as to how this would be done

but a blurred vision of what we perceive to be a solution. The project was well on its

way when I got involved and from there we were always playing catch up after that.

When you took on the role where did you know where to pick up the project from?

I was interested not in the design of this product but how we were to deliver this

system to the field, is it going to be the right formed map, what are their

requirements. My role was to make sure the product was right, wasn’t interested in

the technical side of things, my role was to get it rolled out to the field.

I’m no longer the project manager and no one was appointed after I left. There was

no process being used to deliver the technology, it felt as if the technology was

driving the process hence my involvement. It was felt that Val was going of on a

tangent and therefore I was involved to make sure the project was developed using

BT processes and format.

MSc Dissertation

222


Basic steps of Project Management was not followed, there was no client, the

requirements were established in the eyes of the developers, this is what we want to

do, lets just make sure with the people that its what they want.

I also managed the requirements capture of the project which included organising the

resource for the project.

There was no client and within 6 months on in the project there was no real client.

Within this time I didn’t really liaise with anyone. The client should have been a senior

manager within the organisation.

So how did you get the requirements if there was no client?

Requirements collated from the customer (field engineers), people who were to use

the system. We arranged focus groups where we sat down with managers, engineers

explaining the platform and what we were gong to do. The focus groups gave us a

list of requirements. From there my role was to look at the requirements and from my

knowledge of the business and the way the processes work streaming the

requirements (which of the requirements would have the most value). These

requirements were phased into groups, phase 1,2,3 etc. The requirements were

implemented based on what Information people would want to see. The requirements

capture done in three locations consisting of different user groups who may have had

different ideas, views and requirements. The users consisted of a mixture BMs team

down to engineers.

The information that you had to date with the progress of Informe, what did you do with it?

Project plan was based around getting Informe to the implementation phase, training

events; the project plan was placed in a public folder on email together with

milestones. All the main milestones to date were based around implementation (i.e.

when are London going live, when is Sheffield going live etc). We had a top 10

deliverables, which were things that we had to get into this phase 1. I wasn’t happy

with development because things were being developed on a wing and a prayer,

whatever developers felt like doing they just did it. Therefore I created a development

log which showed each of the things that would be on Informe, the rationale of why it

was to be on Informe and the benefits together with when it should be done and who

should be involved in the development of this.

MSc Dissertation

223


There were no process or steps of developing the project. We were in danger of

developing stuff that was easy and not what the customer wanted. Hence this caused

extensive re-working as management said do this but then turned round and said no

we want this now.

The requirements were not documented or signed-off by the customer, although this

is now being done.

What was the requirement collation process?

We had a SOR, big document that consisted of requirements that came out of the

initial meeting with the focus groups such as management. I found this document

unworkable, as it was unstructured, as it didn’t show which of the requirements we

were going to do. As a result we as a team listed the top 12 requirements that we felt

were important for the business needs and then asked the customer is this what you

want, this was done in a structured way. We had a weekly conference call but this

wasn’t done effectively, there was a lack of communications between the developers

and myself and therefore I didn’t know what was happening with development on

Informe from one week to another.

What if senior management asked for a status report on the development of Informe?

Guess on the status, senior management never really asked about the development,

as at that time we were not actually implementing the system. They wasn’t

interested, senior management may have been interested in the project but they

didn’t have much input into the project because he didn’t have time, was not on his

agenda or objectives.

Management vision had to be shared by all, not saying it was the wrong vision but

the process that was used to initiate it was wrong. Someone needed to get hold of it

from day one and not half way through.

The project was not placed as an objective. Management were aware of the Informe

development but priority was low as it wasn’t on the objectives. Senior Managers

were not happy with the way Informe was being developed, he discussed with Ken

Griffiths and that’s the reason why I was put on the project.

MSc Dissertation

224


Why wasn’t this project on the objective list?

Management didn’t see this project as something he wanted to get involved in, they

wasn’t going to stop the IT solutions manager, they should have done so possibly. It

was decided to work on Informe and then try to feed the idea into senior

management, no feasibility study was done into the project, and no cost benefit

analysis was done justifying the costs over benefits.

The system we were developing was far too complex and the system grew and grew

it would have been better to develop a smaller system less complex. We were

developing a Ferrari when an Escort would have done.

Lack of communications as developers didn’t know what he was doing from one

moment to another. No cost benefit was done to define how long we should spend on

the project, there are no costs to the company as its internal but timescales could

have been defined. No Project Requirement Definition (PRD) or Client Requirement

Definition (CRD). No business case undertake prior to the project commencing.

There were no actual Budgets for this development hence all the work was done in

Val’s team, there’s no actual money going out to the organisation.

People were asking to see the Business Case but there wasn’t one and therefore

managers and suppliers and external departments were not willing to get involved.

How about timescales, were any planned?

The only timescales that were planned was that we implemented by April 2003, it

was 80% successful the reason it wasn’t fully successful was because the

organisation was faced with industrial action threat. We would have met the initial

time scale had this not happened, this was my goal to get the system implemented.

Did you have contingencies in place?

If we don’t do it in April, we’d do it in the first quarter, the client would have made this

decision but there wasn’t a client to make these decisions earlier on.

MSc Dissertation

225


Root cause of the project problems?

If basic Project management processes had been followed from day 1 then we

wouldn’t be in this mess that we are now, I think the root problem lies with the person

who was involved with Change Delivery from Day 1.

As no costs are involved management can go away and just do it and no one would

really know what they are doing.

Products design changed, as users got used to the system so did the design of the

system as more feedback was received.

How do you think the project was managed?

Crap due to management problems and because I was put on it half way though and

saw the way it was going I didn’t really want to be involved in it because I could see

the problems that could surface. I saw it as a position challenge; I was concerned as

to what impact I could have upon the project or what value I could have as it was a

done deal.

I voiced concerns about costing, timescales and discussed them with my line

manager and Val but they were never taken on board but this did not bother me to be

honest as it was not going to effect me personally. This is because I don’t like to be

involved in a project which has not got the foundations in place.

I wasn’t comfortable with working on a project half way though, I’d be happy if there

was someone who was doing the work prior but there was no project manager prior

to me, which was a nightmare.

We had conference calls on a Friday with the development team, and myself. We

discussed what we were doing and issues; problems and the status of the project, all

minutes and actions were communicated over email. Actions were eventually done

but not straight away, the conference calls were effective I feel when we focused on

problems rather than solutions. We identified the problem and then someone would

be delegated to identify the solution to it ready for the next conference call. This

provided more structure to the conference calls.

MSc Dissertation

226


We met about once a month, which was ok, but due to geographical location this was

not always possible instead we used available technology.

Was communication a problem within the project?

Yes, management was aware of the developers In-ept, During development I raised

a concern that if the developer was run over by a bus who would take over

development as it seemed as if the developer was the only one who knew the system

inside out as he developed most of it.

Problems within the team as team members felt that there was just one person doing

all the work and having sole knowledge of the system. MB complained of workload

but then reluctant to let anyone in because they couldn’t code to the same standard.

Management were aware of these issues between DM & MB. MT discussed the

situation with them and told them to let the other have access to the system, if any

problems occur then discuss ideas. The instructions were taken on board as access

was given for him to do that work but then shut access down after that.

Internal politics occurred within the development, management let is escalate; my

role was not to get involved with the politics of the team. I was concerned as it was

impacting upon the timescales but management should have taken charge of this.

The lines of communication was not adequate were developers and management

weren’t sorting issues out between developers, management were aware of

problems but they weren’t acting upon them as they didn’t want to rock the boat. I

tried to tell team members to let everyone know what they have done on a weekly

basis. For example developers was complaining of increased workloads so I told him

that these requirements were priority, I prioritised 10 requirements and told the

developer that this is what you have to do, this way the workload cannot increase

unless you set it as he wouldn’t be doing anymore work till those 10 were completed

or if he to additional work. But still after this the developer complained of work

overload.

The system deign was not adequate, documented or did not follow a process as they

had the mentality that lets get as much functionality onto the system as possible

before the launch date and launch it.

MSc Dissertation

227


The customer communication was only done at workshops where the initial

requirements capture was done fairly early on in the development the requirements

were done in June 2002 (12 months ago) just before and after I started on the

project. We didn’t talk to people about other requirements that they may have had as

we were so busy implementing existing requirements, we just felt lets get this system

up and running. We should have checked with the customer to make sure that we

have developed the right system with the right requirements, I think that’s a problem

that was done by me where I didn’t communicate with the customer more often. I

should have spoken to customers about the requirements, I felt the requirements at

an early stage had been done and customer involvement at this stage was complete.

When something new come along, getting people to change to an alternative system

is difficult, in to Informe, the system before this was the tool kit which BM team was

instrumental in developing in the toolkit, they get it to how they want. When

something new like Informe came along users would say ‘we like the tool kit, why

have we got this [Informe] now?’ Customers in the form of managers were shown the

system but rigorous communication at lower management levels wasn’t done, which

should have been.

3 things that went wrong with it.

Big mistake lack of communications between development team and customer

during the system project within the development team. Good to start of with then

declined.

Not having a structure at the very beginning of the project no client [senior manager

involvement], no PRD.

Lack of communication between developers, customers and myself

Why did customers reject the system initially?

I feel the developers designed the system and had a view of how the system should

look and they try and enforce those others. The process should dictate development

not other way round; this wasn’t the case with Informe.

MSc Dissertation

228



Developing IT projects there is no formal structure that I’m aware of, in relation to

project management we have a project management handbook detailing processes

that should be followed. We don’t follow the method rigidly but do follow all basic

project management techniques that should be followed.

Did you use a design/ development methodology? (Does any documentation exist? Can we have access?)

I came in half way though the project was not aware that any methodology was being

used to develop the system. I wasn’t made aware about whether they were using

Fusebox to develop the system. I don’t think I need to be made aware of this as the

way they go about developing the system I don’t mind.


Speak to client >> collate requirement. >> Business Case developed >> Project Plan

would be in place >> Business Case/ Requirements are sign off >> development >>

Implementation. Documentation extensively is carried out this process was not done

within Informe. Within IT solutions team no money is going out, all development done

in house therefore she doesn’t need to justify her costs, as there aren’t any.

Informe was just developed without a business case, a business case should have

been developed and then the go ahead for the system should have been agreed Val

was allowed to do the former. Costing should have been done at day 1not day 60,

half way through the project. Not cost allocation was done for the project to define

how much Informe would have cost.

What is your role?

Informing the customer of the development status, what they should prior to

development and after implementation, let them know when implementation is

staring, coordinating the management of meeting milestones.

With the Informe development there was no requirement by the company to get it in

by a date, a deadline date would have caused project resource to be allocated to it,

milestones might have been set to get the work done on time, no set deadline will

have impacts upon timescales as they will escalate.

MSc Dissertation

229


I got involved at the implementation stage of Informe and to add some structure to

the development process hoping that this structure would continue on in the project. I

have handed the work over to Val but at present there is no project manager for

Informe.

There is a danger that the development team will carry on doing their own thing and

the development will face the same problems again. There is no end date for this

project, nor was there an end date for the tool kit either.

Prior to commencing projects were any project plan created to show when milestones and deliverables were due?

Prior to the Project Manager joining the Informe development there was no project

plan in place but the manager did create one for the Implementation part of the

development where he was involved in Informe.


Yes


More or less, some dates were not met due to industrial action, our work is dictated

by the weather, the worse the weather the more work we get.


None formally done remembering that I took over the project late on in the project.

Do you carryout any Risk Assessment?

Risks around access time myself carried out for example downloading times of

WebPages where I examined how long it would take to download a page because if

a page took along time to download users would get bored with it and would not use

Informe.

Rationale for Informe was point and click and download the information quickly and

as simply as possible. No formal risk assessment was taken in this project.

MSc Dissertation

230



Personal risks, my credibility of delivering this project. I was concerned about how

long it would take to complete the system, how much would it cost.

The system was fed to people and the acceptance of this system by users was

questionable. No brainstorming of potential risks were taken.]

The risk of implementation was zero as development had been going on prior and I

felt that the system would be implemented, communications had gone out about

Informe being the saviour so I think the problem here would have been high user

expectations, people would have got fed up about waiting for the project. However

myself prior working on the project undertook no formal risk assessment.

There was no documentation available at all for me to look at when I took over the

management of the project.

What risks did you identify and what did you do to prevent them from occurring?

There was no real consideration as how Informe would effect other systems such as

Work Allocation systems, this should have been on day 1 but wasn’t the case.

People knew about these risks but Val have re-assured them that they will sort it out

and it will be ok but this was not the case and the risk and problems still continue.


Lack of communications with customer and industrial action via external factors.

Consideration as to finding out whether what we are doing should be done was never

considered by IT solutions team, consideration as to whether we should continue

with this project was never done even after 6 months into the project.

Lack of structure in the project, no dedicated project manager in this project from the

start, I wasn’t even dedicated to the project when I was managing the project.

No driver [client] within the project - senior manager who can be referred to by a

Project manager if required.

MSc Dissertation

231



A previous development the Toolkit was developed and it has been modified for the

last 5 years, in terms of its development cost no one knows this figure. No one knows

the cost benefit for this; Informe is going the same way as the Toolkit development.

Internal politics has been occurring in past projects for years prior to Informe, same

problems have occurred in the Informe project.

Would you be happy to complete a questionnaire for me as part of this project at a later date?

Yes

Where do we go from here with Informe?

Stop development as soon as people have access to the system

Avoid or eliminate worker objectives

Developers should work in the office not home

Allocate timescales, budgets

Work out costs and benefits

Inform customer at all times, ask them is this what they want, do you require

anymore.

MSc Dissertation

232

Appendix 6: Interview Four Transcripts Ritesh Hira

Interview 4 Transcript 1/7/2003

What is your role within the department and each project?

We have 10-20 projects on the go at anytime and therefore I try and ensure that

there is no conflict with the projects. These projects require developers time, support

time, training time etc and my basic role is that nothing conflicts in terms of resource

allocation overlap. I spend a lot of time fighting off conflicts for developers within the

Field Service. The field service managers will say that my project is important than

yours and therefore I'm protecting my staff from work overload. At the start of the

project it will be my say so whether a project is carried out or if it’s worth doing and

therefore I don most of the Feasibility Study. I also hands on manage the people

rather than the project; my role is the people manager. I make sure that the

developers for example has the skills to deliver the project, technical skills and

negotiating skills with the customer.

What if they haven't got the skills do you draft in someone to work alongside them??

Part of my role is to make sure that they have the skills necessary to do the job as

my role of people manager.

You say that the developer is also the analyst and project manager or point of contact at anyone time for the project, do you think people have the relevant skills to take on such a diverse and big role?

Part of my job is to make sure that the development team have the right skills to

conduct such a role like the one you mention. We find that this sort of role works

better because most of the development team have come from field jobs; they tend

to know the job that they are developing the solution for. The analysis part will come

in from a job specific history which the developers have worked in the past. The

developers career skills and their knowledge of the problems that field engineers

were going through help them more than their analysis skills.

MSc Dissertation

233


What is the general response when you ask developers to take on such a role?

They like to be involved at all stages so that they can see what the customer

requires. The major problem in the past has been that they [developers] have

developed systems in the past that have not been fit for use by the customer. Getting

them to work with customers enable them to understand and deliver what the

customer wants. The major problem for the team is that as they spend more and

more time working within the team as a developer they then become detached from

the everyday processes and the customer and fail to keep up to date with changes in

business that occur.


Rapid development orientated. Varies from solution to solution, I sit on many forums

where we look at different IT solutions for projects. They will use me as a consultant

asking me whether it’s worth looking at a technical solution to the problem. I then go

back and discuss with developers and ask them whether we can improve things by

developing a system. If so then we go to the customer and find out what they want.

1st step is to find out what the statement of requirements are, we get their ideas on

board as to what they expect from the final system. We then put up a mock up which

gives the customer a look and feel of what the system is supposed to do, like a

dummy model.

Prior to developing a system do you carry out any cost benefit analysis?

Yes but vaguely as most of the costs are absorbed within my team, its not until when

I talk to another line of business where they need to alter their system to talk to my

system that's when costs start to occur. This is one of my risks when I have to go

back to a customer and say that they maybe some cost involved to the solution that I

provide, as I need to talk to department. Initial stages I would assume nil costs if all

development is done within my team. All I incur is day-to-day costs/ overheads.

MSc Dissertation

234


You say the organisation develops systems using a methodology whereas IT solutions develop systems much more quickly, could you tell us about the two different approaches taken.

The organisation develops big mainframe systems, one of the biggest I can think of is

the Customer Service System [CSS]. They also look after the network if we wanted

to have any work done then we would have to approach them and then there would

be a very detailed SoR as they hire in resource such as developers, contractors etc.

They will work out the potential man hours needed based on the SoR. If we have

been hired for 6 months but it takes 9 months then we will be charged for the extra

months incurred and they will only deliver what is on the SoR and no other, there is

little time to alter the system spec so what we ask we get. If we wanted additional

requirements to the one already specified then we would have to pay again following

the requirements process etc. So it’s a lengthy process to follow. The organisation

follows a more rigid approach to estimation and is more deadlines orientated. Rigid

codes of practice, strict coding security levels, can't do changes without lengthy

approaches.

One of the reasons why IT solutions exist is because business changes so much

these days that we can't wait around for the lengthy processes that are conducted by

people like IT Exact. We are the "quick fit fitters" where we keep paperwork to a

minimum cut out the administration as much as possible. We sit with the customers

rather than document the customer needs that are the big difference. The team will

sit with the customer, create a dummy product and then ask the customer whether

this is what they want. Then we incorporate the customers feedback based on their

feedback. At this stage the developer who also undertakes the analyst role will sit

with the customer and determine what changes if any the customer requires.

What level of documentation will occur from these meetings?

It varies from developer to developer. Some developers will write something down on

paper, others will use the dummy model as their documentation. The changes will be

made to the system there and then by the developers. If they can't make the changes

there and then, then will be some supporting documentation. From here we will

carryout some user testing to other people saying that this is the system and they

may have additional requirements as Scotland's requirements may differ to

Cornwall's. We have a number of forums and one of these is a regional manager

forum where they are representative of the different forums that exist and we will ask

MSc Dissertation

235


them that we have got this solution and does this solution fit with what you would like

to see in the system, they then might make additional requirements to the system.

We then get a broader picture and that finalises the specification. We then create a

full system which goes back to the forum they will do the customer acceptance

testing, say yes. We will then have a trail site and then roll out will occur from there

on. The requirements, which are collated, would be signed off during the forum.

You say you keep documents to a minimum what documents do you create, are these formalised in anyway. Projects plans etc?

This depends on the size of the project, like for Informe. The Project Manager

produced a project plan with milestones and targets and to keep us on track, as

Informe was a big project. The Project Manager is not involved with the project but

we are using his project plan. The project plan developed was up to implementation,

another Project Manager is now needed for Version 2.

The managers were trained and then they in turn trained their staff was this effective?

This depended on the managers training skills and their willingness to do this job.

Some managers are slow at doing the training, some do it on a one to one basis,

others in a team-meeting format, and it depended on the individual. If managers

haven’t done the training then I will escalate this to senior level until they do it as it

has been agreed by managers that they will do this.

A brochure is issued together with a disc to users, which shows them how to use the

system; this clarified any points that were not understood. This documentation

reduced the pressure on the helpdesk as people referred to the manual rather than

ringing the help desk.

Had users had any problems they would have contacted the helpdesk who would

then help resolve them. But these were not documented in anyway so that the

problems can be eradicated from future implementations of Informe. No problem

document log existed to record user problems that may have occurred.

MSc Dissertation

236


What would happen if a developer left?

We would have had a handover of work; it would take the whole development team

to leave before Informe runs into trouble.


We have a brainstorming session with each requirement identifying whether the

requirement will bring any value add to the business and this form an element of risk

assessment for each requirement. Therefore we weighed up the risks of

implementing a requirement and the risk of not implementing a requirement. The

same form of risk assessment was undertaken with the Informe system what are the

risks of implementing the system and what are the risks of not implementing the

system.


The risk of starting a development and then it being rejected, then you might waste

resource and money and find that nobody wants it. It was then a balancing act as I

had to be continues that I was developing this system but it might be rejected by

management therefore I had to decide how far I should go before getting

management buy in.

The risks that you identified, how did you prevent these risks from escalating?

One risk is that there is no money and therefore we might promise a lot and then

failed to deliver what we said we would due to the lack of money. Therefore attempts

were made not to raise expectations to far at this stage. Let’s see if we can develop to

those expectations once these expectations have been delivered then review your

expectations again. Deliver to expectations again using the process described, when

money becomes available raise expectations further. I sat down with the team to

discuss what we would do if risks occurred, there were always alternatives for

example if a third party couldn’t deliver then we would have alternative suppliers on

hand. Each risk would be reviewed at the weekly conference call and face-to-face

meetings to identify whether the problems occurring have been dealt with.

MSc Dissertation

237



We were late in developing a project plan and a project plan was not created until the

Project Manager was involved with the project.

The first problem was that we tried to implement content management* which

Informe is developed upon. We tried to implement this [Informe] too soon. The

customer was not ready for the technology [Informe] that we were to implement.

* Content management systems are systems, which recognises an engineer with a

certain grade or job role, and they will collate the information which the engineer

needs to know to do his job and present that information using the Content

Management systems. Therefore Informe was developed to manage the content of

your job role for you. This was the basis of the Informe project. Informe in integrating

different systems and websites into one system.

How was Informe initiated?

Our team initiated ourselves, the engineer had a problem in that he had too much

information to look at he did not know where to go to collate the relevant information

about how I should be doing a specific job. Informe has bought products and services

into one place eradicating the manual process into an automated process. Many

problems were being thrown at us prior to Informe development. For example there

were so many MI information sites which contradicted one another. Informe

developed MI which was to solve this problem of contradicted MI reports and place

the MI statistics into one system namely Informe. People had to manually maintain

their own systems, which were seen as problem prior to Informe.

We developed Informe as a solution to the problems we were hearing about, 75% of

the problems we were hearing have been solved through the development of

Informe. The remaining 25% will be dealt with as Informe evolves. Informe is

developed on a business needs basis and therefore the system will continually

evolve as the business changes. Therefore features added to the system this year

might not be needed next year as the business changes. There is no end date for

this systems development where the Informe system is developed in house.

MSc Dissertation

238


With the Informe system had did you get potential users on board?

We collated the problems that were taking place and we came up with the idea of

Content Management, I then did a marketing job with senior managers informing

them that you have said that there are these problems, I can offer you this solution.

This was a difficult period, as a lot of the managers could not grasp what the solution

would give them. We had problems getting people on my side at this time and we

were too early in introducing this technology as the engineers had only got laptops,

they weren’t familiar with laptops, their training in laptops was not complete at this

time. They were not familiar with one system and I’m coming along and introducing

another system to them before they have learnt the earlier one.

One of the problems was to get the timing right for the implementation of the new

system.

How was this countered? You say that senior management were not supportive of your idea?

I was disappointed with the reaction I initially received and at the same time I knew

that this was the solution. We approached this situation from a different angle where

we informed them that the organisation has over 300,000 websites of which 250,000

are not relevant. I informed managers that I can bring this solution [Informe] to you

and I can cut costs of managing all these websites into one site. At this point people

starting coming on board. Rather than just presenting the soft benefits of making the

job easier I could also save you money as well.

People at this stage said that yeah this solution could work, but by then the time had

lapsed and users were becoming familiar with technology and were ready for the

Informe implementation and therefore were more ready for the system, therefore time

had not been lost that much.

From my understanding you were getting people to accept this system and developing the system. Is this correct? Yes

MSc Dissertation

239


What would happened if people managers had not still accepted the system even after the marketing effort?

The system would have been shelved if this had been the case. The development

would have been halted until the business was ready for this system to be

implemented. For example when the problems escalated people would have come to

us and said that the system you recommended, we’d like it now. That’s when the

system, would have implemented.

Was the Informe development a bit of a gamble in that you were hoping that it would be implemented?

The only gamble we had was that of time, 6 months had passed during the time that I

was trying to get people to accept the system. However schedules had not slipped,

as we don’t have schedules until senior managers buy into the system and that the

project can go ahead.

Prior to the Project Manager joining the team who was the Project Manager and were any plans created prior to the Project Manager joining the team?

The IT Solutions manager was the PM prior to a formal Project Manager, once

development had been given the go ahead and because the system was so big I had

to get a formal development team together including a formal Project Manager.

Prior to the Project Manager joining the team carried out no project plans, timescales,

deliverables or milestones.

Prior to Matt joining the team what was taking place?

There was more marketing of the solution taking place on paper, up until we got the

go ahead from senior management the project was based on theory however

development was taking place at the same time. Prior to implementation the Project

Manager was managing development in terms of what customer requirements were

needed, security levels needed and what the system was to consist of.

The customer is a field user. The client is a senior manager; every project has to

have a senior manager/client overseeing development that is also consulted

throughout development with the projects status.

MSc Dissertation

240


One of the problems faced is the skills of the users, the skill level of users differed in

terms of some people being skilled technically and others not being so technically

minded. Therefore decisions needed to be made as to what was to be delivered.

Should we deliver everything and put the user off because Informe is such as big

system. Therefore with Version 1 we implemented a skeleton system and when the

user became more familiar with the system we began to add more functions to the

system.

Steps taken to introduce the system:

Initially I went to 3 regions and informed users of the problems and the solution to the

problem (i.e. Infome) we are proposing, we asked them whether they required any

additional features to the system which would help resolve their problems which they

were experiencing with the present system. We did a series of focus groups

explaining that these are the problems but what do you want delivering first within

version 1 of the system. We asked the customer and users to prioritise the

requirements; these people consisted of 1st, 2nd line managers and engineers. We

carried out focus groups in the North, Central and Southern areas in order to collate

the requirements and issues from all areas. We then developed and used the focus

groups as our trail sites. At these trial sites we presented the system and asked the

users and customer whether we had interpreted their requirements correctly. The

system version changed as further requirements were added to the system.

As we work with users of the system we deliver what they ask for and they also feel

involved with the systems development in the design process.

During the Project Manager role as Project Manager, how was this role undertaken, did any problems occur?

At one stage we had regular one to one meetings and the Project Manager decided

that these meeting was slowing development down due to the different geographical

locations that we were based in. This was replaced with a weekly conference call

which took place on a Friday. It didn’t work as the conference calls weren’t clearing

up issues and we weren’t having the day out from development. Issues were being

addressed and you think you have resolved it but then Mick would find that he hadn’t

got the answer and then he would have to wait another week for the next conference

call to take place. Whereas the face-to-face meetings would have dealt with issues

and people would be clear about what needs to be done. Geographical problem

occurred here.

MSc Dissertation

241


To some extent solve this I get everybody together in one location for a week. To get

them back on track with the project so that we are all up to speed on the

developments progress. To prevent this problem from occurring again with combine

conference calls with face-to-face meetings and people are more familiar with their

roles. Conference calls take place every week and face-to-face meetings take place

every third week. This level of communication has worked better now as prior we

were falling behind.

How was deadlines and deliverables welcomed within the team?

They were treated positively as the development team had input to them, developers

were asked how long development would take and they would provide a timescale

for delivery. The developer would provide me a date but there would be some debate

about the timescale, as I’d ask whether we could get it done any quicker.

We were aware that not all decisions would be in our control for example as this

project was big and there was a requirement to liaise and collate data from other

systems, we had to negotiate timescales for this data and therefore I had no control

as to when the data would be supplied by.

To store the user requirements as to what will be delivered the development team

designed a development log which showed the team the important requirements that

had to be delivered and so that developers know that what’s in the development is a

job that they have to tackle.

What goes in the development log, how is it decided what to deliver and what not?

This is based on experience as most development staff has worked in the filed and

they know what users will require. The Project Manager was also the process owner

and he was asked whether certain requirements would help users do their job

properly. If the Project Manager said no then it wasn’t delivered as part of Informe.

The developer would be at these meetings when it would be decided which of the

requirements were to be delivered and which were not. Furthermore the

requirements that had higher priority were judged on how much value the

requirements could bring to the system however the resource availability in terms of

developer’s time might knock down the requirements priority timing.

MSc Dissertation

242


The requirements that are to be delivered in the system will be agreed and

communicated to the client together with the development status of where systems

development is. Now within the system we have a coming soon status box which tells

you what we are to deliver within Informe and things that we are working on.

During development I was going to lose two members of my team, which would have

impacted the Informe development, and the timescales of the project. I then had to

place a business case for that resource (developers) to the client to stay within my

team. Mark then negotiated for that resource to stay, there was some uncertainty to

the project but I dealt with it quickly however on the whole the problem did not

significantly have an impact upon development. So no real delays occurred.

We were falling behind because we weren’t having effective meetings [this has been

mentioned earlier on in the interview]. We had gone through the design stages and

were in the development stage. The training, testing, support and help screens had

to be brought together and we discovered that we were well off course. We were not

communicating effectively as a team and therefore I got the whole team to work

together in one building so that everyone got their relationships established and their

job role. Who was doing what, when and how. The communication problem occurred

within the team.

One major problem was that our users were the field engineers and we came along

and said that I want to take you all out for a day and train you on this system. We are

taking them away from their day-to-day job of installing phone lines. This days

training would impact the customer who pay us to do phone line installations. Fault

volumes can increased substantially at times and this was the case during the time

training was scheduled and therefore the field would not allow for engineers to be

released from the field to undergo this training. We had everything booked for the

training right down to accommodation and then we don’t have anyone to train.

Training plans were thrown out of the window.

To counter this we had to review training plans and re-schedule the plans. We

examined where the major faults levels were and decided to do the training last there

and carryout training where fault levels were less. The training plan was fluid rather

than set in concrete and we had to continually assess the training plan to make sure

that it could be implemented within the schedules set.

MSc Dissertation

243


The key to the successful project was that we knew our audience [engineers] we

extensively consulted users informing them that this system will save you time. We

gave them a system which they wanted and therefore during the training they were

more willing to receive the training. The system was based on what the users wanted

and therefore the system resembles their needs more than anything. The marketing

process was devised and conducted by me to senior managers and also in a top

down and bottom up manner so that field users are not felt to be made inferior. This

way both parties get their say as to what they want in the system. This method of

marketing is used in other projects as well within IT solutions.

Conflicts within the team caused problems at times. This included different work

commitments as there are different projects going on and therefore the same

developer maybe needed on a different project. This impacted the timescales as the

team are overloaded with work and therefore this is where I come in. I approach

senior managers and ask them which of the developments are of more priority than

others.

My team are very technical but their communication and negotiation skills need

development and this is what I take care of so that they have the right skills to do

their job effectively.

You say the developer is the analyst and therefore communications skills, which they have, may not be adequate for them to interpret the requirements correctly; do you think this is the case?

No because there is always someone who checks the requirements like me with the

customer hence the workshop. The developer will create a dummy model and he will

check with the customer to make sure that he ahs interpreted the requirements

correctly and improve his understanding of what’s required. Allow the customers to

state if he wants something different to the system.

You were the manager for the project for a time and then Matt cam along, would you say that there were 2 managers managing the project.

No I left the Project Manager and he reported to me and this worked well as roles

were defined explicitly between the Project Manager and myself.

MSc Dissertation

244


Summary of problems:

Training plan and re-doing the plan this was the biggest problem

for us.

Conflicts of the team having other projects at the same time

caused problems.

The skill of your audience, until they were receptive to Informe we couldn’t implement

and the implement date was pushed back until they were trained up.

There was no budget for the system as costs are incurred in the department. To date

if costs are incurred then I have to do a business case asking for money for

development. Up till now 2K has been spent on the Informe development.

The system implementation was well received as it improved working practices for

field users


Yes they have occurred but we know that these risks are to occur and they can

happen and therefore we try and avoid it. For example the bad weather issue where

at certain times of the year we should plan for training to be carried out at certain

locations due to bad weather resulting in engineers being more busy as a result. We

know these risks as a team but have not documented them anywhere, its based on

experience.

The development style within the team is based upon experience from the past rather

than process and procedures. This is a good thing because this way they will know

their audience.

Your development style is quick and easy with minimal processes being used. Would you be willing to use project management techniques and processes to create projects in the future?

It would depend on whether it would bring additional value to the projects

development. If the tools that we are using were regarded as inadequate then we

would look to use other processes such as project management. If the project we

were developing was complex and we couldn’t keep track of it using the current tools

then we would use something else.

MSc Dissertation

245

Appendix 7: Chart 5 - Global Events, Problems and Risks of the Informe Development Ritesh Hira


Functional Requirementsnot signed off by customers


Cost

No FormalSpecification (PRD/ CRD)


Project Failure

Additional RequirementsRequested

Additional stakeholders identifiedresulting in more requirements

being requested, system became morecomplex

Cost

Requirements notdetailed enough

Requirements not collatedfrom users adequately, system

not in linewith user expectations

Quality



not understood.

User resistance

No Formal Testing

Users see errors with thesystem, expect it

to be bug free

UserResistance

No Development Plans

Plans as to which requirementsare to be implemented

are not documented

ProjectFailure

Project Failure

No specialisedAnalysis StaffInadequate requirements

collation

Cost

User resistance

Systems PerformanceProblems

Lack of Systems ScalabilityPlanningUser resistance

No project plan


No monitoring strategy

No Schedule

Development rushedthroughQuality

Time

No set deadline

Staff use guestimateas to when they can deliver


Staff pressure

Deadlines slip

No formal reporting structure

StaffPressure

Development staff do notcommunicate progress, feel isolated

morale low


Exact project statusnot known as team geographically

spread

Development carried out on twodifferent versions of the same system

Duplicate work

Time

No FormalMethodology used

Development process taking longer tocomplete

Quality

Limited consideration ofadopted development method QualityNot all developers

use same method


UserResistance

Users unhappy withperformance of the system

No considerationof risk TimeUnanticipated problems will

directly effect the project

User resistance

Quality

Quality

Project FailureUser

Resistance

User resistance Low levels of IT literacyin the organisationUsers not willing to work with

the technology

Development agendasAdditional requirements weredelivered when not asked for

Cost

User resistance

Project failure Decision not made by seniormanagement as to whether development

should go ahead



processSystem does not represent

requirement of the field

User felt that thesystem was to close their

department down

Project had seriousorganisational

impact

No version control

User resistance

System continuallychanging

No Project Manager

Cost

Development notbeing overseen

Work allocationdone verbally

No formal record of whowas doing what

Project developedwith limited structure




Cost

Guess on project status

Internal Politics

Informe not onmanagement

objectives & not willingto embrace Informe

Limited involvementof client/ management


User resistance



Time

Inadequate implementationPlanSystem implemented to users whilst they were learning

laptop technology, training couldn’t be delivered at specified time

Time


commitments to projects

Key members of the teamtemporarily leave to

do other projects or sufferwork overload

Quality


Engineers notaware technically

Cost

Time

Time

Cost

Time

Time

Cost

Cost

Time

Informe Project

Problems

Events

Risk

Key

MSc Dissertation

246

Word Count Ritesh Hira

Total Word Count: 39, 098

Ayae Hanumante Bira Ji Yae

MSc Dissertation

247

Documents

The University of Sheffield Risk Assessment of Individual ...dagda.shef.ac.uk/dispub/dissertations/2002-03/External/Hira_Ritesh... · Ritesh Hira September 2003 MSc Dissertation 1