assessment of risk management within securities companies oriented systems development company: the...
TRANSCRIPT
1
Assessment of Risk Management within Securities Companies
Oriented Systems Development Company: The Case Study of
Beijing Rewin Network Technology Co., Ltd
A study submitted in partial fulfilment
of the requirements for the degree of
Master of Science in Information System Management
AT
THE UNIVERSITY OF SHEFFIELD
BY
Ying Huang
September 2011
2
ABSTRACT
The dissertation divides into following seven chapters:
Introduction
Introduction generally introduces what the dissertation aiming for and explains
the research questions briefly It also mentions data collection and analysis methods.
Through the introduction, the basic structure of this dissertation can be clarified.
Literature Review: Information systems Using in Securities Companies
This chapter introduces literatures defining information systems. Different
definition of information system will be discussed, and nature of information system
will be represented. Importance of information system will also be shown in this
chapter, followed by failure examples of information systems and listed possible
reasons for failure. After literature review of information system, the chapter will
introduce common concepts about securities markets and companies.
Literature Review: Risk Management
During this chapter, the whole risk management cycle will be introduced, and risk
identification will be discussed in details, as risk identification is the core of research
question.
Case Study
The Rewin Co. will be introduced specifically in this chapter. Firstly the general
organisational structure is clarified, after that the ECSN mode, the core
semi-finished product company has, is explained. General project development
processes of the company will then be represented by flow chart and explained.
Methodology
In the methodology chapter, research approach will firstly be explained. Research
strategy is described in great details, along with data collection and analysis
methods. Why thematic analysis and concept map are fit for this research will be
told. At the end of this chapter, possible ethical issues this research facing will be
3
described, as well as solutions to these issues. Limitations are also mentioned.
Results and Findings
Results and findings chapter identify all risks existing in system development
process of the company by analysing interviews from four interviewees. Risks are
firstly divided into three categories by using thematic analysis. After discussing each
theme, relationships between themes will be explained by using concept map.
Conclusion
In the conclusion chapter, the former chapters will be reviewed, and some
additional discussions will be given to the results and findings chapter.
Recommendations to the company is described as well, and in the end, limitations
and possible further research relate to this research are described.
4
ACKNOWLEDGEMENT
Lots of people provide great helps in ensuring this dissertation is doing its best.
Whilst there are so many people I feel grateful, I wish to especially appreciate my
supervisor, Dr. Miguel Baptista Nunes, who encouraged me all the time and help me
to enhance this work. This dissertation cannot be finished without his help. I also
want to appreciate the contributions of my family, they gave me lots of power to
keep going on.
5
CONTENT
ABSTRACT
ACKNOWLEDGEMENT
Chapter 1 Introduction and Background .................................................................................. 1
1.1 Introduction ...................................................................................................... 1
1.2 Motivation......................................................................................................... 2
1.3 Research Aims and Objectives .......................................................................... 3
1.4 Methodology..................................................................................................... 4
1.5 Data Collection .................................................................................................. 5
1.6 Data Analysis ..................................................................................................... 6
1.7 Structure of Dissertation .................................................................................. 7
Chapter 2 Literature Review: Information Systems Using in Securities Companies ................ 9
2.1 Definition of Information System ............................................................................... 9
2.2 Nature of Information System .................................................................................. 11
2.3 Importance of Information System........................................................................... 12
2.3.1 Strategic Importance ............................................................................. 13
2.3.2 Information Systems as Innovations ..................................................... 14
2.4 Failure of Information System .................................................................................. 15
2.4.1 Changing Views on Information System Failure .................................... 15
2.4.2 Information System Failures .................................................................. 16
2.5 Securities Company .................................................................................................. 17
2.5.1 Introduction of Financial Markets ......................................................... 17
2.5.2 Definition of Securities Market ............................................................. 18
2.6 Securities Markets in China ...................................................................................... 19
2.6.1 Two Chinese Securities Markets ............................................................ 20
2.6.2 Securities Market Institutions ............................................................... 21
6
Chapter 3 Literature Review: Risk Management .................................................................... 23
3.1 Definition of Risk ....................................................................................................... 23
3.2 Definition of Risk Management ................................................................................ 24
3.2.1 Proactive and Reactive Risk Management ............................................ 25
3.2.2 Purpose of Risk Management ............................................................... 26
3.3 Risk Management Cycle ............................................................................................ 27
3.3.1 Risk Identification .................................................................................. 29
3.3.2 Risk Analysis ........................................................................................... 33
3.3.3 Risk Control ............................................................................................ 34
3.3.4 Risk Monitoring ...................................................................................... 35
Chapter 4 Case Study .............................................................................................................. 36
4.1 Introduction .............................................................................................................. 36
4.2 The Organization ....................................................................................................... 36
4.3 General System Development Process ..................................................................... 38
Chapter 5 Methodology .......................................................................................................... 41
5.1 Research Approach ................................................................................................... 41
5.2 Research Strategy...................................................................................................... 42
5.2.1 Strategy in General ................................................................................ 42
5.2.1.1 Phase One: Identify Expected Risks ........................... 43
5.2.1.2 Phase Two: Understand Actual Risks ......................... 43
5.2.1.3 Phase Three: Make Recommendations ..................... 44
5.2.2 Case study Strategy ................................................................................ 45
5.2.3 Interview Strategy .................................................................................. 47
5.2.3.1 Provide Interview Questions ...................................... 47
5.2.3.2 Choose Interviewees .................................................. 50
5.2.3.3 Set Interview Timetable ............................................. 51
5.2.3.4 During Interviews ....................................................... 52
5.3 Research methods .................................................................................................... 53
7
5.3.1 Data collection ....................................................................................... 53
5.3.2 Data analysis .......................................................................................... 55
5.3.2.1 Thematic Analysis ....................................................... 55
5.3.2.2 Concept Map .............................................................. 56
5.4 Ethical Issues ............................................................................................................. 57
5.4.1 Ethical Issues During Design and Gaining Access .................................. 58
5.4.2 Ethical Issues Related to Analysis and Reporting .................................. 60
5.5 Limitation .................................................................................................................. 60
Chapter 6 Results and Findings ............................................................................................... 62
6.1 Presentation of the Results and Findings ................................................................. 62
6.1.1 Introduction of Interviewees ................................................................. 63
6.2 Theme List ................................................................................................................. 63
6.3 Concept Map ............................................................................................................. 65
6.4 Theme One: Contract Issues ..................................................................................... 67
6.4.1 Budget Issue ........................................................................................... 67
6.4.2 Time Length Issue .................................................................................. 69
6.5 Theme Two: External Environment .......................................................................... 70
6.5.1 Communication with Customer............................................................. 70
6.5.1.1 Business Relationship ................................................. 70
6.5.1.2 Requirement Understanding ...................................... 71
6.5.1.3 Customer Attitudes and Behaviours .......................... 73
6.5.1.4 Professional Knowledge ............................................. 74
6.5.2 Customer Processes and Management Culture .................................... 75
6.5.2.1 Project Management .................................................. 75
6.5.2.2 Maintenance and Update........................................... 76
6.5.3 Environment .......................................................................................... 77
6.5.3.1 National and Social Cultures ...................................... 77
6.5.3.2 Business and Personal Relationships ......................... 78
6.6 Theme Three: Internal Management ....................................................................... 79
8
6.6.1 Management.......................................................................................... 80
6.6.1.1 Project Management .................................................. 80
6.6.1.2 Team Restructure ....................................................... 81
6.6.1.3 Resource Scheduling .................................................. 82
6.6.2 Communication...................................................................................... 83
6.6.2.1 Within Team ............................................................... 84
6.6.2.2 Between Teams .......................................................... 84
6.6.3 Technical Aspect .................................................................................... 85
6.6.3.1 Technical Complexity .................................................. 85
6.6.3.2 Knowledge and Experience ........................................ 86
6.7 Discussions and Findings .......................................................................................... 87
6.7.1 In General: External Environment Decides Internal Management ....... 87
6.7.1.1 Environment Decide Internal Management .............. 88
6.7.1.2 Requirement Understanding Decides Technical
Complexity of Projects ............................................................ 89
6.7.2 Within External Aspect .......................................................................... 89
6.7.2.1 Environment, Culture and Relationship ..................... 89
6.7.2.2 Communication with Customer isImportant ............. 90
6.7.2.3 Internal Management in Customer Aspect as A Bridge
................................................................................................ 91
6.7.3 Contract and Its Relationship with External Environment and Internal
Management ................................................................................................... 92
6.7.4 Within Internal Aspect ........................................................................... 93
6.7.4.1 Management Turns to Be Central .............................. 93
6.7.4.2 Technical Capability Limits Progress........................... 94
Chapter 7 Conclusion .............................................................................................................. 96
7.1 Summary ................................................................................................................... 96
7.2 Discussion of Findings ............................................................................................... 96
7.3 Recommendation ...................................................................................................... 98
9
7.4 Limitation of the Research ........................................................................................ 99
7.5 Further Research ....................................................................................................... 99
Bibliography: ......................................................................................................................... 101
Appendix
Appendix One: Risk Checklist ................................................................................................ 107
Appendix Two Interview Questions scripts in English .......................................................... 109
Appendix Three: Interview Questions Scripts In Chinese .................................................... 115
Appendix Four: Consent Form .............................................................................................. 117
1
Chapter 1 Introduction and Background
1.1 Introduction
The concept of information system occurred quite a long time ago, but only from
last thirty years people began to more consider computer-based information
systems than manual ones (Avison & Fitzgerald, 2006). With incredible development
of information technology during last 30 years, majority of organisations in different
fields now have information systems (Ould, 1999).
Stock market is one of the most important fields for information system
development (Kohn, 2004). Within globalisation nowadays, the Stock Exchange
plays important roles in the provision of finance for business (Atrill & McLaney,
2004). Stock market started to develop in China in 1990, and has shown its
incredible increase through years. In Shanghai Stock Exchange, which is the largest
stock exchange in China and also the fourth in the world, has 894 listed companies,
938 listed securities and gathered over five hundred and fifty billion GPCZ in only
2010. This massive volume of trade requires high security level information systems,
not only for stock exchange, but also for securities companies that relate to stock
exchange.
However, even stock exchange systems cannot escape from system failure. In
1993, the London Stock Exchange (LSE) paperless exchange system was shelved at a
cost of approximate £750 million (Miles, 1993). In 2010, the LSE announced to
switch its .NET frame based system to Linux system after suffering extended
downtime and unreliability. Although the example is taken from UK, it is a global
issue around the world. The examples remind system develop companies that
2
failure in the accurate risk identification during system development processes may
also lead systems to fail (Deng, 2005).
The Beijing Rewin Network Technology Co., Ltd is an information system
development company, which provides expert and mature securities companies
oriented information systems and solutions. Based on rich experiences of
developing information systems for 40% securities companies in China, the
organisation believes that they have had mature risk management from developing
and designing period to implementation period. However, whether the Rewin Co.
considers all kinds of risks, it is still unknown.
Risk management cycle has four steps in total (Kleim & ludin, 2000): risk
identification, risk analysis, risk control and risk reporting. Risk identification is
always primarily concerned, as other three processes will have fewer effects if risks
cannot be identified accurately (Tchanakova, 2002). Therefore, the thesis will focus
on risk identification by the case of the Rewin Co.. It will indirectly assess system
security level of one part of securities companies in China, and help the Rewin Co.
to assess risk management of itself.
1.2 Motivation
Risk management turns out to be one of the most important methods during
system development process, whilst risk identification is the start of risk
management. Whether the company can define risk appropriately decides its
attitudes towards risks, and how the company act when facing such risks. Although
it is interesting to research whole risk management cycle, time limits the research
scope.
The reason for choosing the Rewin Co. is the high percentage of market share. For
3
a company with over ten year’s experiences, it is reasonable to believe the company
have comprehensive knowledge and strategies on identifying risks during
development processes. The research is therefore set to evaluate whether the
company have appropriate risk identification or not.
1.3 Research Aims and Objectives
Cadle and Yeates (2001) suggested that risks involved in all projects for some sort
and risk management turn out to be more and more important through years.
However, due to complexity of nowadays system development projects, risk cannot
be identified as easy as before (Cadle & Yeates, 2001). Besides, through preliminary
literature review, it is found that risk identification is always ignored by experts and
academics (Tchankova, 2002). Many risk analysis models can be found but rare risk
identification methods are produced by same authors. As a result, it will be
interesting to have a deep research in risk identification. Moreover, many books and
journals investigate risk within systems such as ERP systems and MIS systems, but
literature can hardly be found with the context of securities companies. It causes
inconvenient to both securities companies and system-develop companies, as they
have to identify risks only by their own experiences instead of with help from
previous projects. Therefore, it is important to set a research to identify clearly what
risks will involve during securities companies oriented system development and
assessing whether the system-develop company has solutions to solve risks. The
research question can be set as:
How will the systems-develop company identifying risks when they occur during
securities system development?
In order to answer the question, the dissertation aims to identify the risks that
4
may occur during the whole system develop process and figure out how the
company will solve them. The objectives of the research are listed as below:
Analysis literatures relate to risk;
Identify risks after analysing literatures;
Gather information from the company to find out system develop processes;
Analysis processes to find out how the company solve risks when they occur.
Although the research will cover the whole Risk Management Cycle (which will
discuss later in literature review), its primary focus is about risk identification. It is
because that risk identification is the first and the most important process of Risk
Management Cycle, as it will decide which area should be focused on during rest
three processes. Failure in identification will cause the failure of the whole risk
management.
1.4 Methodology
This section aims to explain what kind of research approach is going to use during
the research. Besides, ways of data collection and data analysis will also be
explained. Research approach
As research project always involves using theory, it is important to figure out
whether the theory is clear at the beginning of the research, or be found out after
the research (Saunders et al., 2007). The choice of research approach determines
how researchers develop a theory, and what kind of data collection and analysis
methods they want. In this research, deductive approach will be used.
Deductive approach can be described as a top-down approach, which consider
from very general to quite specific (Trochim, 2006). Deductive approach starts from
5
deducing a hypothesis, then expressing the hypothesis and test it. After examining
reliability of the hypothesis and getting feedback, it will go back to the start point
and repeat the cycle, until the hypothesis is specific after testing by specific data.
For this research, because risk identification is built up from former research
papers and books, it is therefore using a theory that has already existed. Therefore,
the research uses deductive approach.
1.5 Data Collection
When consider about data for sociological research, there are two kinds. Primary
data is gathered by surveys, observations or interviews, secondary data is gathered
from documentaries, censuses, government reports or so on (McNeill, 1990).
According to Saunders et al. (2007), there are several advantages to use secondary
data. Using secondary data can reduce the cost to gather data, and huge amount of
information can be directly found in such as censuses. Time can be saved by using
secondary data, and if combine with the use of primary data, comparison can be
made and new discovery might be developed.
To collect secondary data, case study is used as the data collection method.
According to Yin (2003), case studies are preferred strategy when questions are
being posed as “how” or “why”, as case study is always used in explanatory
research.
However, using secondary data also have lots of disadvantages. As secondary data
is always collected for a particular purpose, it not always matches the research’s
need. Because of traditional existing bias, reliability of secondary data may be
affected. Moreover, sometimes secondary data may cost more to access than gather
6
primary data by oneself own.
As a result, primary data is indeed needed in this research. Interview will be used
to gather primary data. Although interviews suppose to be designed as
semi-structured, interviewer will still be free to have any further discussions with
interviewees. Therefore, data gather from interviews will be qualitative data
(Saunders et al., 2007).
1.6 Data Analysis
After gathering primary data from interviews, data will be analysed by two
analytical procedures: thematic analysis and concept map.
Thematic analysis is one kind of analysis which combines a deductive and an
inductive approach to qualitative analysis (Saunders et al., 2007). In the context of
this research, there will first be a list of types and subtypes of risks, which gathered
and categorised from former research papers and books. When analysing interview
record, risks mentioned during interviews will be categorised by the list, which will
help researcher to analysis later. Those risks which were not listed in the risk list will
be added into the list. All interview record will be analysed in this way.
However, thematic analysis will just show simple categories of risks. The common
situation in reality is that one kind of risk may lead to another risk, or this risk is
always caused by other two. Thematic analysis cannot represent relationship
between risks. Concept map, in contrast, can clearly show relationships between
risks (Randon, 2011). It will cover the insufficient of thematic analysis, and help
researcher find out what are main risks within the organisation.
7
1.7 Structure of Dissertation
The dissertation researches in following stages:
Introduction
Introduction generally introduces what the dissertation aiming for; it explains the
research questions briefly, and mentions data collection and analysis methods.
Through the introduction, the basic structure of this dissertation can be clarified.
Information systems Using in Securities Companies
This chapter introduces literatures defining information systems. Different
definition of information system will be discussed, and nature of information system
will be represented. Importance of information system will also be shown in this
chapter, followed by failure examples of information systems and listed possible
reasons for failure. After literature review of information system, the chapter will
introduce common concepts about securities markets and companies.
Risk Management
During this chapter, the whole risk management cycle will be introduced, and risk
identification will be discussed in details, as risk identification is the core of research
question.
Case Study
The Rewin Co. will be introduced specifically in this chapter. Firstly the general
organisational structure is clarified, after that the ECSN mode, the core
semi-finished product company has, is explained. General project development
processes of the company will then be represented by flow chart and explained.
Methodology
In the methodology chapter, research approach will firstly be explained. Research
8
strategy is described in great details, along with data collection and analysis
methods. Why thematic analysis and concept map are fit for this research will be
told. At the end of this chapter, possible ethical issues this research facing will be
described, as well as solutions to these issues. Limitations are also mentioned.
Results and Findings
Results and findings chapter identify all risks existing in system development
process of the company by analysing interviews from four interviewees. Risks are
firstly divided into three categories by using thematic analysis. After discussing each
theme, relationships between themes will be explained by using concept map.
Conclusion
In the conclusion chapter, the former chapters will be reviewed, and some
additional discussions will be given to the results and findings chapter.
Recommendations to the company is described as well, and in the end, limitations
and possible further research relate to this research are described.
9
Chapter 2 Literature Review: Information Systems
Using in Securities Companies
During modern society, information systems in organisations are playing as a
critical part. Daniel Bell (1970) predicts that there will be an information revolution
in the latter part of the twentieth century, and Western societies will become
information societies. It is now coming true, and organisations nowadays heavily
dependent on timely information so as to win strict competitions within markets.
Well designed information systems are therefore required, as Avison and Fitzgerald
(2008) suppose that information system can help the organisations provide usefully
information and process to their customers effectively. In this kind of new situation,
individuals and organisations have become increasingly rely on information systems.
2.1 Definition of Information System
When consider about information system nowadays, it is usually concentrate on
computer-based information system instead of manual systems, for the computer
can process accurate data speedily, and provide latest information in any place it
required, and can deal with large volumes at the same time (Avison & Fitzgerald,
2008). In contrast, manual system can hardly catch up.
Information system can be defined from a variety of aspects by different authors.
Buckingham et al. (1987) defines an information system as:
“…a system which assembles, stores, processes and deliver information relevant
to an organisation (or to society), in such a way that the information is accessible
and useful to those who wish to use it, including managers, staff, clients and
citizens. ”
10
Similarly, Peppard (1993) describes information system as creates, uses and stores
information flow within an organisation and between organisations. Wolstenholme
et al., (1993) mentions information system provide information and promote
information flow. Although these definitions represent brief introduction of
information system, they are seemed too vague to understand.
On the other hand, some academics produce the definition of information system
by more comprehensive and in-depth understanding. Laudon and Laudon (2004)
define information system as combination of interrelated components which collect,
process, store and distribute information, in order to support organisation making
decisions and controlling. Components include input, process, output and
environment around information system (Beynon-Davies, 1993). Besides Laudons
and Beynon-Bavies, Flynn (1992) and Boddy et al., (2001) also propose that
information system provides procedures to record and transform data to available
information, concerning part of an organisation, to assist organisation-related
activities.
Avison and Shah (1997) classify different categories of information system (As
shown in Figure 2.1). It can be found from the figure that some of these systems in
use include informal systems and automated systems. Informal systems are used to
communicate among employees, whilst automated systems enable general office
tasks to be carried out automatically (Avison & Fitzgerald, 2008).
11
Figure 2.1 Different Categories of Information System (Avison & Shah, 1997)
2.2 Nature of Information System
Information systems are built up by a number of components (Laudon & Laudon,
2004; Boddy et al., 2001; Brooks et al., 1982). From Figure 2.2, it can be seen that
components are connected with others by data flow (Brooks et al., 1982), and it
explains how data become useful and valuable information after the whole
information process.
12
Figure 2.2 Components of Information system (Brooks et al., 1982)
When the raw data comes into information system, it will firstly be edited and
validated, and sent to the next component. System turns the valuable data into
readable file, and if system have already stored some relative data, the new input
will be sent to the next process whilst has the selected stored data with it. The
processed information will be updated and store into data storage to wait for next
time use or update, and information user need will be output by output devices
such as printer or monitor. Although other authors may have different descriptions
on components of information system in details (Flynn, 1992; Laudon and Laudon,
2004), they all describe an information flow process from input to output.
2.3 Importance of Information System
13
As the continuing evolvement of computer science and network, it is now
important for organisations to join the informational trend. Information systems for
organisations are no longer just local information storage and calculating tools, but
more power weapon to let organisations compete within the globalisation market
(Hurst, 2006). There are two main aspects establish the core position of information
system within organisations: strategic aspect and innovation side.
2.3.1 Strategic Importance
Information systems are more than computers (Laudon & Laudon, 2004). When
using information system in organisations, it is required to have an understanding of
the organisation, technology and management shaping systems. For organisations,
information systems can be considered as solutions to challenges and competitions
produced by environment, and create profit for the firm (Avison & Fitzgerald, 2008).
The “Three era model” (Ward & Griffiths, 1996, p.10) described the increasing
importance of information systems during recent decades. It suggests that in 1960s
information systems were specifically used for data processing, followed
development of management information system in 1970s, and in 1990s strategic
information systems were created. On the basis of the “Three era model”, Peppard
(1993) has discovered several strategic advantages by using information system:
External focus;
Adding value;
Sharing benefits
Understanding customers’ needs
Exploitation of information to develop business
Incremental development
Business-driven innovation
(Peppard, 1993, p.15-16)
14
Peppard (1993) suggested that organisations can gain extra profits by gaining
strategic advantages from information systems. After analysing customer
information within information systems, organisations can find out potential needs
of customers. E-commerce websites are best examples of implementing strategic
advantages. For example, Amazon.co.uk concentrates highly on external side, which
means investigating customer behaviour. Once customers browse the website and
search for particular product, the information system will immediately store the
information and estimate customers’ favour. The system automatically recommend
some other products that relate to those products customers searched, so as to help
customers to locate what they want to buy and attract customers to buy more
products than they first time considered. After customers bought any products, the
system will remember their choice and send advertise emails periodically to attract
customers to buy new products. This kind of business development tends to be
iterative and incremental.
2.3.2 Information Systems as Innovations
Implementation of an information system will always have elements of innovation
followed (Sauer, 1993). It is because that information system will represent some
new organisational procedures (Swanson, 1994). For organisations which did not
use information systems, the physical implementation of system will be significant
to organisations; new information systems always also involve use of new
equipments and software; even upgrading existing information system will require
rewrite programme code and redesign work procedures relate to the system (Sallis,
1995). What is more, due to the traditional manual management, staffs will need to
have more training on using information systems and have to change their ways to
do their works.
15
Information system innovation requires an effective partnership between IS
develop team or apartment and its users as well as close cooperation with
consultants vendors and providers of outsourced services who are considered
external to the organisation (Attewell, 1992). Therefore, according to Sauer (1993),
information system innovation process should be considered as a flexible process so
as to allow more upgrades and new function implementations in future. Due to
extensive use of information system within organisations, its innovation can be
represented in a wide range, from the use of database design techniques (Nilakanta
& Scamell, 1990) to industry-specific IS technologies such as electronic scanners for
supermarket (Zmud & Apple, 1992).
2.4 Failure of Information System
Computerised Information Systems are now pervasive in all forms of business
organisations (Yeo, 2002). They are considered as core of organisations, as they are
used to achieve competitive advantages or to reorganise the business processes of
the company (Flowers, 1997). However, IT investments are seemed as expensive and
of high risk (Lyytinen & Robey, 1999; Carr, 2003; Fortune & Peters, 2005). According
to the Standish Group’s survey, Fitzgerald and Russoand (2005) point out that only
16% of IS projects are completed on time and within budget. Therefore, in order to
understand and learn from failures (Sauer, 1997), researches on IS failures are paid
continuous interests.
2.4.1 Changing Views on Information System Failure
It is firstly important to understand what causes failure during IS development
before discussing IS failure in details (Sauer, 1997). Although traditional literatures
suppose that technical factor has the highest response on IS failure, advances in
16
development technologies nowadays are not sufficient to improve successful rate of
IS implementation (Lyytinen & Robey, 1999). Failures in social and behavioural
aspects have turned out to be the dominant reason of IS failure (Sauer, 1997).
One of the best example for IS failure should be the sudden cancellation of the
Taurus project on March 11th, 1993, of which the London Stock Exchange had been
developing for almost 7 years. The Stock Exchange invested $130 million for the
project, along with securities companies invested another $600 million (Drummond,
1996), willing to restructure the traditional securities trading mode by setting a
backbone system for the London Stock Exchange. Although the development had
sufficient budget support, massive scale and involvement of latest technologies
leaded to frequent changes of requirements under ineffective project control during
development processes. Unclear technical risk identification and notifications by
management and blind obedience of powerful interests finally caused ill design or
the system.
2.4.2 Information System Failures
Lyytinen and Hirschheim (1987) announce four categories of IS failures, whilst
Sauer (1993) suggests that only three of them can be proved valuable in reality.
They are:
Correspondence failure: It used to be considered that if an IS can be
implemented in time and within budget, then the IS would be considered as
successful implemented (Bartis & Mitev, 2008). However, the IS might not meet its
original design objectives. In this situation, the system is considered a failure.
Process Failure: If an IS cannot be developed within time schedule or allocated
budget, it can be identified as process failure. There are two kinds of outcome of
17
process failure (Yeo, 2002). Firstly, many IS development projects are cancelled so
there will be no workable system produced at all (Buechi, 1982). On the other hand,
a more common outcome is that an IS developed with overspending time or budget,
and this will reduce overall benefits IS can bring.
Interaction Failure: Interaction failure occurs whilst end-users are unsatisfied with
implemented systems. Although Sauer (1993) suggests that IS reach design
objectives and implement within time schedule and cost can hardly fail to satisfy its
users, it seems more common than he thought (Lyytinen & Robey, 1999). Heavy
usage does not equal to high satisfaction, as there might not have any other
alternative system can be chose besides the one using.
The fourth failure Lyytinen and Hirschheim (1987) was expectation failure, which
happens when a system do not meet its stakeholders’ requirements or expectations.
However, Sauer (1993) supposes expectation of a particular group might not meet
the overall benefit of whole organisation, whilst failures of considerable
requirements should be evaluated within correspondence failure.
2.5 Securities Company
2.5.1 Introduction of Financial Markets
Money is sometimes considered as “a lubricant that greases the wheels of
economic activity” (Ritter et al., 1996, p.4). Daily economic during each individual’s
life could be inconceivable difficult without transaction of money. However, it is
needed to point out that money is more than a lubricant. Money itself can be a key
factor influencing economic behaviour as well as performance of financial
institution and markets (Pibeam, 2010). Changing speed of money can also effect
employment, inflation rate or even general grow around the world, of which will
18
effect individuals and institution in return (Ritter et al., 1996; Valdez, 2000).
Financial markets are markets help money channelling between people (Also call
as Lender-Savers) who have surplus funds and people (Also call as
Borrower-Spender) who have a shortage of funds (Mishkin, 1995). Both
Lender-Saver and Borrower-Spender can be households, business firms,
governments or foreigners. Through financial markets and intermediaries, unused
funds from individuals and firms can be transferred to those who have a productive
use, so as to have greater economic efficiency.
2.5.2 Definition of Securities Market
According to Mishkin (1995), Valdez (2000) and Ritter et al., (1996), current
financial markets can be divided into two categories: primary market and secondary
market.
Primary market is a financial market in which new issues of a security are sold by
government or corporation agency to those potential buyers (Blake, 1990). The
primary market for securities is not well known to publics, as the selling of securities
mainly through particular kind of financial institution, investment bank. The normal
selling style for investment bank is underwriting securities, which means guarantee
a price for a corporation’s securities then sell them to public (Ritter, 1996).
Unlike primary market, secondary market refers to a financial market in which
securities within market are second-hand and can be resold (Blake, 1990). The
London and New York Stock Exchanges are well-known as secondary markets.
Besides of stock markets, bond markets and foreign exchange markets are also
known as secondary market. Within secondary market, securities brokers and
dealers are crucial to securities trading. Brokers help investors to match with sellers
of securities, whilst dealers link buyers and sellers by selling and buying securities at
19
stated prices.
Three types of market organisations can be found purchasing and selling
securities (Atrill & McLaney, 2004). Auction Market allows buyers and sellers
centralise together and bargain over price directly; Brokered Market provide employ
service of broker for potential traders to find appropriate participants; Dealer
Market can be considered as combination of dealers, of whom buying and selling
securities from their own accounts and let buyers and sellers buy securities from
dealers.
2.6 Securities Markets in China
China’s securities markets have been developing since the late 1980s in
impressive speed (Su, 2003). By the end of October 1999, 930 companies have been
listed on the Shanghai and Shenzhen Stock Exchanges (Su, 2003), whilst this number
has increased to 1,381 by the end of February 2006 (Neftci & Menager-Xu, 2007).
The proceeds for both A and B share offering before 2006 totalled 912.7 billion yuan.
Total market capitalisation was about 3.34 trillion yuan, whilst almost 1.07 trillion
yuan were tradable shares (Neftci & Menager-Xu, 2007). The huge capitalisation
Chinese financial market created can even hardly be imagined when it was firstly
reformed in 1979, as its economy at that time was just quarter as large as it is today
(Su, 2003).
Although financial market of China has been considered as a “big pie” for western
investors (Krug & Hendrischke, 2007), Chinese financial market cannot be simply
analysed similarly as Western financial market (Neftci & Menager-Xu, 2007). In
Western society, financial markets occur due to the needs of the economy and have
developed along with economy progress. On the other hand, stock markets in China
were born suddenly when the central government needed new financing tools for
20
state-owned business (). As a result, understanding structure of Chinese financial
market is necessary.
2.6.1 Two Chinese Securities Markets
There are two national stock exchanges in China: Shanghai Stock Exchange and
Shenzhen Stock Exchange. No provincial level stock exchange exists, because stock
exchange in China is limited use to government to control economy.
On November, 1990, Shanghai Stock Exchange (SHSE) was established to allow
investors and enterprises to participate in stock trading, of which also becomes the
first government-approved securities market (Su, 2003). By using modern paperless
trading system, SHSE support securities trading at a speed of more than 16,000
transaction per second (Su, 2003; Neftci & Menager-Xu, 2007). Orders transact from
member firms or the floor through computer terminals and are matched together
automatically base on the principle of “Price and time priority”. SHSE had 996
securities and 837 listed companies by 2004, and provide securities products such
as investment funds, corporate bonds along with stocks.
Shenzhen Stock Exchange (SZSE) was established on July, 1991. The SZSE is
located in one of the four Special Economic Zones (SEZs), a city receiving lots of
preferential from central government so as to attracting capitals from Hong Kong. By
the end of 2004, 536 companies were listed on the SZSE, and advanced paperless
trading system can help SZSE support 20 million daily trades. Base on 20 million
trades’ daily capacity, the Exchange offers real-time stock quotations and
transaction confirmation via satellite and optical communication network, and
real-time monitoring of market activities is also performed to ensure timely
detection of irregularities.
21
2.6.2 Securities Market Institutions
Trading of stocks and bonds within securities markets require financial institutions
involve. These institutions include organised exchanges, investment banks, and
securities brokers and dealers. These institutions are not defined as financial
intermediaries, but they are important in the process of trading securities and
transfer money from Lender-Saver to Borrow-Spender.
As discussed above, there are primary and secondary securities markets existing
in the financial market. The main difference between these two securities markets is
that primary market only has new issues of securities sold by corporations or
government, whilst secondary market can trade issued securities between
individuals and corporations (Atrill & McLaney, 2004).
Investment banks sell new stocks and bonds directly from corporations and
governments in primary markets (Blake, 1990). Several investment banks may group
as a syndicate and underwrite new issue jointly. The underwriters sell the securities
to the general public by a guarantee price, and have to take risk that securities may
not sell as much as they expected (Kohn, 2004). Activities of investment banks
within primary market should obey different regulations of securities markets in
different countries.
Securities brokers and dealers and organised exchanges have trades in secondary
markets. Securities brokers act as neutral agents, and help their customers to sell or
purchase securities. They match buyers with sellers without involving securities
trading (Mishkin, 1995). On the other hand, securities dealers buy and sell securities
with their own accounts, and sell securities to public at stated prices. Dealers buy
securities from publics by lower prices and sell them out by higher price. This kind of
price spread turns to be the dominant profit of securities dealers.
22
Organised exchanges can be considered as combination of dealer markets and
auction markets. Both sellers and buyers trade in exchanges with the help of one
particular kind of broker-dealer: specialist. Specialists match purchasing and sale
orders that submitted at the same price so as to provide broker function, or sell
from a personal inventory securities to publics if there is no matching up within
markets. With increasingly globalisation, more and more companies are being listed
in the foreign stock exchanges, and the global securities markets turn to be having
trade internationally, 24 hours a day.
23
Chapter 3 Literature Review: Risk Management
Risks are involved within daily life of every individual in every aspect (Frosdick,
1997). It is therefore no doubt that information system development also has risks
exist. Moreover, most important reasons of information system failure maybe risks
(Wright & Wright, 2001).
Information system projects such as the London Stock Exchange TAURUS system
(Drummond, 1998) and the London Ambulance Service Computer Aided Dispatch
System – LASCAD (Flowers, 1997), are examples of failed projects due to poor risk
management, especially in risk identification. Nunes and Annansingh (2000)
suppose that insufficient risk and business strategies may link to poor risk
management, whilst poor risk management will lead to system failure.
In order to avoid system failure, it is necessary to get good understanding of risks
and identify them properly (Mobey & Parker, 2002; Nunes & Annansingh, 2000). To
achieve this purpose, it is important to assess risks systematically so as to predict
possible effects or risks. Risk Management Cycle will be introduced within this
chapter, and the first process of the cycle – risk identification will be discussed in
details.
3.1 Definition of Risk
The earliest use of the word “Risk” in English occurred in the seventeenth century
(Elaine, 2002). The word was used in particular context, such as ensuing legal
problems of loss and damage. Since then, risk is always related to uncertainty and
lost or damage (Mredith, 2000). For last 30 years, academics paid more and more
attentions on risk and different definitions were given.
24
Ould (1999) suggests that risk includes all threats which affect achieving one or
more aims of the projects. Similarly, Haimes (1998, p.306) states that risk is
“likelihood of adverse events associated with bad consequences”. Lewin (2002)
supposes that risk means a material threat to an entity’s asset. If consider Lewin’s
definition in context of this research, the entity means the company using
information system, the material means information system development, and
during implementation of development, lots of risks will be produced and may bring
bad consequences to the organisation and influence its assets, both intangible and
tangible. Risks cannot be avoided by one hundred percent, which means risk is
“potential variation in outcomes” (Williams, Jr., et. al, 1998, p.4) If risks occur and
cannot be solved in time or correctly, it means cost through whole processes, and
lead to failure in the end.
On the other hand, however, some academics consider risk as positive aspect and
believe that risk will bring opportunities (Hillson, 2001; Teneyuca, 2001). It suggests
that risks could help to achieve objectives (Chapman & Ward, 1997). For example,
an inexperienced project team may have the project time delay, or may have
communication problems with customers. But team members may also give the
project some new ideas from previous experiences and provide some innovation
solutions. Therefore, risks should be identified properly and managed in specific
ways, of which also point out importance of risk management and risk identification
in specific.
3.2 Definition of Risk Management
In 1916, risk management was firstly identified as a separate management
function by Fayol (Remenyi & Heafield, 1996). He defined risk management as
function related to security activities, and recognised the need of loss-control within
25
organisations. Since then, the concept of risk management was introduced and
widely used within economic aspect, especially in the USA. After 1970s, risk
management tend to be more systematic and specific, whilst research of risk
management within information system development occurred (McGaughey et al.,
1994).
Chapman and Ward (1997, p.7) define risk management as:
“…a means to improve project performance via systematic identification,
appraisal and management of project-related risk.”
Similarly, McGaughey et al. (1994) and Kumar (2002) identify risk management as
three steps: understanding existing threats, assessing their possible effects on
objectives, and applying effective methods to avoid negative consequences. Besides,
Chapman and Ward (1997) also suggest that risk management suppose to improve
system development quality and performance by identify, evaluate and manage
potential system risks. It can be then reasoned out risk management is a support
activity rather than direct contribution on information system development
(Tchanakova, 2002; Mobey & Parker, 2002).
3.2.1 Proactive and Reactive Risk Management
According to Smallman (1996), two categories of risk management strategies can
be found: proactive risk management and reactive risk management. Proactive risk
management tends to consider potential risks during planning process in order to
avoid risks even before they occur (Mobey & Parker, 2002). In contrast, reactive risk
management concerns risks only after they happen and is described as
“Fire-fighting” (Thomsett, 1992).
Although it is concerned that both reactive and proactive risk management
26
should be present during information system development and management so as
to manage risks effectively (Chapman & Ward, 1997), research suggests that these
two risk managements do not work so balanced in reality (Jablonowski, 2000).
Despite managing risks before they occur, managers always find themselves busy in
solve problems after they have harmed benefits of company or customers. This
situation is particularly common for the implementation of proactive risk
management strategy on software development process, whilst most of risks are
concerned after the event (Jones, 1994).
Proactive risk management is considered achieve better affects by comparing
with reactive risk management (Pressman, 1992; Thomsett, 1992). Within this thesis,
proactive risk management is mainly concerned, as it has potential financial
advantages for companies on saving risk costs (Pressman, 1992) and is also
systematic in nature as well.
3.2.2 Purpose of Risk Management
As organizations nowadays are more dependent on information technology, they
have therefore become more vulnerable to the risk of failure (Bandyopadhyay et al.,
1999). Effective risk management can assist asset protection of an organisation,
improve its brand image and more importantly, enhance organisation’s operational
efficiency (AIRMIC et al., 2002). Bandyopadhyay et al. (1999) not only notes that risk
management is one of the most important process for organisation benefits, but
also lists out three purposes of risk management in information system
development:
“Protect IT assets such as data, hardware and software from external threats.
Avoid or mitigate complete losses by selecting and implementing the best
combination of security measures.
Protect project from internal threats such as technical failures, sabotage and
27
unauthorized access.”
What is more, Teneyuca (2001) notes that even if any problems do occur, they can
be better solved or organized if control strategies have been considered.
3.3 Risk Management Cycle
To implement the purpose of risk management, it is required by system and
project managers to provide Risk Management Cycle (Figure 3.1) in order to guide
risk management process.
According to Kleim & Ludin (2000), there are four processes within Risk
Management Cycle. Each of them is introduced briefly as below:
Figure 3.1: The Risk Management Cycle. (Kleim & Ludin, 2000, p. 9)
Risk Identification is about examining the whole project and identifying
potential risks in different area. To identify risks, massive pre-research and
28
pre-planning should be done. Identification should also consider about the final
achievement of the project, because different aims lead to different
requirements.
Risk analysis assesses the importance of risks once they have been identified. It
is quite important to have this process, for risks need to be divided by several
priority levels. For example, risk that may lead to server shutting down is much
important than risk that may lead to print one word wrong. Therefore, by using
quantitative or qualitative techniques, risk analysis can transfer data gathered
from risk identification into useful knowledge for next two steps.
Risk control is about to lessen the impact of risk that already have had
happened by using control method prepared during last two steps. Risk control
is important, as it is the assess step of previous preparation during risk
identification and risk analysis. In contrast, the former two steps will have no
use if risk control does not involve.
Risk monitoring gathers feedback from different parts of project after former
three steps. It is about communication between risks and activities which used
to solve risks. Information of risks and solutions and all processes relate should
be kept, in order to let project team check back.
Although other academics such as Cadle and Yeates (2001) suggest three main
risk management stages during risk management process, it is supposed that the
Risk Management Cycle is more appropriate, as the three risk management stages
do not divide identification and analysis of risks clearly.
29
3.3.1 Risk Identification
There are different systematizations for risks from academics. Pressman (1997)
divides software risks into three categories: project risks, business risks and
technical risks:
Project risks:
These risks would include customers, resources, personnel, schedules and budget
and their impacts for the project.
Business risks:
These are threats to the viability of the proposed software, such as loss of
commitment from managers, budget cuts, project is no longer required for the
organisation or is no longer wanted.
Technical risks:
These risks are related to quality and timescale and include leading-edge
technology, obsolete technology, uncertain technology, ambiguity in specifications,
maintenance problems, verification problems, interface problems, implementing
problems and problems with design.
Although the systematization provide helpful description of risks, these
categories seem have reiterations and conflictions from each other. Other
academics provide identification of risks in more details. Han et al. (2006) highlight
six dimensions of IS risks, including 27 risks associated with information system.
These dimensions are:
Users:
Resistant to change
Conflicts with other users
Negative attitudes
Lack of commitment to the project
Insufficient user cooperation
30
Requirements:
System requirements are changed continuously
Insufficient identified requirements for systems
System requirements are unclear
System requirements and not correct
Project complexity:
Adoption of new technology
High technical complexity levels
Poor developed technology
Untested technology not previously used
Planning & Control:
Ineffective project management methodology
Insufficient monitoring or progress
Poor estimation of resources needed
Project planning is insufficient
Undefined project milestones
Project manager lacks experience
Communication weaknesses
Team:
Team members lack experience
Team members are insufficiently trained
Lack of specialised skills within the team
Organizational environment:
Negative effects occur when management is changed
The organizational environment demonstrates instability
Restructuring of an organisation during a project
Corporate politics produce negative effects
Similar as Hen et al., Cadle and Yeates (2001) highlight the importance of the
commercial background, contract, customer, users, acceptance criteria, functional
31
and technical requirements, the performance, reliability, availability, and
maintainability, project plan, developers skill, project staffing, development
environment, software, tools and methods, target architecture and bought in items.
They are detailed as below:
“The commercial background - The business case for the project may be unsound or
the funding may not have been approved. It may be a new business area in which
the supplier has little experience.
The contract - The biggest risk here is that the scope of work is ill-defined or not
agreed between the parties. There may be no signed contract, with work proceeding
on the basis of more informal arrangements.
The customer - The customer management structure might be unclear. Access to
important customer staff may be difficult and it could be hard to get decisions made.
There may be internal political difficulties in the customer’s organisation…
The users - The users may not be committed to the project or be able to devote
sufficient time toit. They may be unfamiliar with the technology and require
additional training. There may be unwillingness to change working practices to fit
in with the new system.
Acceptance - The acceptance criteria, and the acceptance mechanisms, may not
have been defined in the contract. The acceptance criteria may have been drawn
very vaguely and not linked to specific, measurable demonstrations of performance.
The functional requirement - The requirement may not have been formally signed
off before development proceeds. The requirement may not be complete or suffer
from varying levels of detail or internal inconsistency. It may have been defined at
too high a level, making it difficult to implement and operate change control
procedures. The requirements may have been defined in more than one document
with the risk of inconsistencies and ambiguity between them.
The technical requirement - The system may be very complex technically or require
a high degree of innovation. It may require the use of tools, techniques or hardware
not familiar to the developer.
32
Performance, reliability, availability and maintainability - There may be very
stringent performance requirements for the system. A high degree of reliability or
availability may be required. It may be difficult to test the system using realistic
numbers of transactions or users.
The project plan - project manager may not have been involved in the bid phase and
so not have contributed to the initial plan. The project may have very tight
timescales. The plan may not take into account the need to revisit work from
previous phases. There may be excessive reliance on a few key staff. Milestones
might be too far apart, deliverables may not have been defined tightly enough or
work packages may be too large for effective control.
The developer’s skills - Key staff for example, the project manager or team leaders –
may be new to their role. The team as a whole may be very inexperienced in the
business area or technology or both and there may be a lot of training required.
Project staffing - Staff may not be available when required, or may have to join the
project too early, when there is too little for them to do. Staff may have other
commitments that could divert them from the project.
The development environment - The environment may be new to the developer. The
development environment may not match the live environment. The hardware may
be unreliable or poorly documented.
System software - This may be unproven or not yet available. It may be unfamiliar
to the developer and technical support may not be readily available. There may be
excessive performance overheads.
Tools and methods - The programming languages may be unfamiliar to the
developers. It may be unsuited to the particular project requirements. There may not
be adequate tools for such matters as configuration management, project planning,
testing and so on.
The target architecture - The hardware may be new or unproven or used before for
this purpose. Some of the hardware may be customer-built and not available until
late in the development
Bought in items - If third party products – hardware or software – are required,
33
there could be little experience of the suppliers.
Poor previous experience - The suppliers may be in a poor financial condition and at
risk of going out of business. There may be difficulty in establishing tests for
bought-in items.”
(Cadle & Yeates, 2001, p.191-195)
3.3.2 Risk Analysis
After identified and described risks, it is then necessary to analysis risks so as to
figure out what should be done on management so as to avoid those risks (Cadle &
Yeates, 2001). According to Cadle and Yeates (2001), risk analysis always has
considerations on impact and likelihood of risk. In other words, it means through
risk analysis, each risk should be rated by both its impact rate and probability rate.
From Figure 3.2, it can be seen that each risk can be put into different part of the
table so as to divide them by risk rating. Risks which put in left top needs to be
control since the start of project planning, whilst risks put in the right bottom can
sometimes be even ignored.
34
Figure 3.2 Risk Map (Cadle & Yeates, 2001, p.233)
Besides this kind of qualitative risk analysis method, Cadle and Yeates (2001) and
Hughes and Cotterell (2001) suggest quantitative risk analysis method as well.
Sometimes it is not quite possible to analysis the impact or the possibility of risks.
For example, if the amount of risk is quite large, it seems not so possible to rate
each risk one by one. However, it the huge amount of risks has repetition, then the
repeat rate of risks can be calculated through statistic software. By definition
repetition from high to low, researchers can also find out which risk is in high risk
level and which is low.
3.3.3 Risk Control
Hillson (2001), Hughes and Cotterell (199) and Higuera (1995) all discussed risk
control. The model they provide can be divided into four categories:
Avoid. Some risks can be avoided by recreate project plan or progress processes.
For example, the risk of developers having little communication with their managers
can be avoided by having weekly meetings.
Pote
nti
al s
cale
of
imp
act
Smal
l M
od
erat
e La
rge
Likelihood of occurrence
High Medium Low
35
Transfer. Some risks can be passed if the manager of these risks is swift to
another one. For example, having a technology manager in the project team can
help the team leader reduce risks of whole teams.
Mitigate. Mitigate means not avoiding risks but try to reduce their impacts before
they do occur. This kind of method cannot erase risk but just decrease influences.
For example, by changing team members from a delayed project to a new project,
the cost on human resource can be reduced.
Accept. Sometimes there is little harm for some small risks exist, or sometimes
risks cannot be avoided. In this kind of situation, to allow risks exist in the system
may also be fine.
3.3.4 Risk Monitoring
Risk monitoring exists once risks have been identified and can help to avoid or
reduce cost of risks (Kliem & Ludin, 2000). The most important aspect for risk
monitoring is that it must be taken into a continual basis. No risks should be ignored
by risk monitoring, until risks are those have been mitigated to a small impact or
have little impact in nature (Weigers, 1998). Through risk monitoring, risk impact of
those risks which are already known can be minimised, risks which are new
discovered can also be added in monitoring to reduce costs in future.
36
Chapter 4 Case Study
4.1 Introduction
An information system provider which named Beijing Rewin Network Technology
Co., Ltd will be used as a case study in this research. The organization has several
different kinds of products and mainly focuses on making websites and basic
technology platform. This organization has their owned technical platform named
ECSN and all the application and solutions are based on the platform.
4.2 The Organization
The organization was found in 1999 and the scope of business is mainly focus on
E-business. This organization, which is a high-technology enterprise, has dozens of
cooperative enterprises and the organization is also a software enterprise.
Meanwhile, the organization has more than 40% market share of securities websites.
On the other hand, the registered capital of the organization is 15 million RMB and
the organization has obtained ISO9001:2000 quality system approval for seven years.
For the sales aspect, the organization annual sales are more than 15 million RMB
and the company is headquartered in Beijing and the organization has branches in
Shanghai and Shenzhen.
As the figure 4.1 shows the main product of the organization is mainly around
making securities websites and basic technology platform. On the other hand, the
organization also has knowledge product which focus on the investment research,
office automation and working flow. The organization also has management
accounting product for the customer.
37
Figure 4.1 The main products of the Rewin Co.
The main area of the business scope is securities websites and basic technology
platform which focus on unified authentication, content management and product
management. Especially for the ECSN technology platform is the key point of the
organization, the platform could be divide into three parts which are system front
desk, system middle desk and background system. ECSN has experienced COM +,
J2EE and SOA three main stage of development, at the beginning the ECSN platform
is initial business component oriented multi-layer component platform and now the
platform has changed to service oriented business integration platform. This
38
platform realizes the concept of business is a service. At the same time, this
platform can be trusted for enterprise application development and deployment of
infrastructure operation.
In ECSN mode, ESB enterprise service bus is the core of the application. Each
application system can serve as an independent business system and the system can
deployed in the ESB bus. The system through the communication and cooperate
with ESB to construct a complex enterprise application environment. In addition,
ECSN platform also provides many basic services, such as uniform user management,
the unification the authentication/authorized, business process management,
content management, product management, gateway management which can be
greatly reduced the complexity of the upper application development. All the other
products and solutions of the organization are development or construction on the
ECSN platform.
4.3 General System Development Process
The figure 4.2 shows that the working flows of the organization and some
solutions for the problem during project. With descriptions in details, how a project
is set, implemented and final produce system can be clearly seen.
At the beginning, the company will bid a project if they think they can fulfil
requirement from customer, if not, they will find other projects. After bidding and
sign contract, project plan will be set based on the contract. There will be
evaluations on project plan during weekly meeting, by examining whether the
project plan can be fulfilled by enough human resources. If not, the plan has to be
reset. If resources are sufficient for the project, the project team starts to work.
39
There are two different situations: If customer does not need customisation, the
stage will directly jump to system programming; if customisation is needed,
interviews will be held to understanding operational requirement so as to produce
prototype. Prototype will be sent to customer to check whether it provides suitable
functions. During this period, usually one demand analyser and two arts designers
are needed.
There will always have three to five developers programming in one project.
During this stage, the development cycle will be spiral raise. When some parts of
systems have finished, those parts will be sent to customer to evaluate. Internal
evaluation will also be held, so as to prevent misunderstanding of customer
requirement. After all parts have been evaluated and passed, system will be turned
into testing and deployment. Another two testing engineers will join in and one or
two system engineers will have deployment and another system engineer will do
system pressure testing.
If all these have been done and the system is in good situation, it will then be
operated. When customer requires maintenance or update, different amount of
work decides how the maintenance or update going to have.
40
Figure 4.2 General Processes for System Development Project in the Rewin Co.
Can the company falful
requirement from customer?Bid a project
YESSign contract
Plan settingEnough resources
for the plan?
product demand
analysis & design
need customization?require understand
by holding interviewsunderstand requirement
product prototypeArgeement/comfirmation
from customer?programming system
Evaluation Finish programming?Fit requirement?
System testing
& developmentProblem?System operate
Maintenance?
System expired
NO
NO
YES
YES
YESNO
YES
NO
YES
YES
NO
NO
Reconsider
requirement NO
YES
Bug fix/ patch update Huge changes
require for
adding
new model
or update
a new
systemNO
NO
41
Chapter 5 Methodology
This chapter aims to introduce methodology used within this thesis. The chapter
details research approach and research strategy. It also outlines research method
applied during the whole research, including data collection methods and data
analysis methods. In specific, risk identification framework will also be introduced.
At last, limitations of research method will be discussed.
In this dissertation, research approach is considered as deductive. Case study and
interview are used as research strategies, whilst interview is used to collect primary
data; thematic analysis and concept map are both approached to data analysis.
5.1 Research Approach
As research project always involves using theory, it is important to figure out
whether the theory is clear at the beginning of the research, or be found out after
the research (Saunders et al., 2007). The choice of research approach determines
how researchers develop a theory, and what kind of data collection and analysis
methods they want. In this research, deductive approach will be used.
Deductive approach can be described as a top-down approach, which consider
from very general to quite specific (Trochim, 2006). According to Cambridge
Dictionary Online (2008), deductive research represents “reaching an answer or a
decision by thinking carefully about known facts”. Deductive approach starts from
deducing a hypothesis, then expressing the hypothesis and test it. After examining
reliability of the hypothesis and getting feedback, it will go back to the start point
and repeat the cycle, until the hypothesis is specific after testing by specific data.
Therefore, deductive approach is always related with research methods that have
42
hypothesis in first time, such as questionnaire and literature research. Interviews are
mainly used for approaching inductive approach, of which reasons the works from
specific observation s to broader generalisation and theories (Williams, 2002).
Within this dissertation, however, deductive approach is adopted by using
interview as one of research strategy. Although the dissertation uses interview to
collect primary data, it is firstly needed to build up a risk checklist through literature
review, in order to understand what risks are expected to have during information
system development processes.
The risk checklist can be considered as a hypothesis, which suppose the target
company might have those risks listed occur during development, and the deductive
approach is to find out whether these risks occur or not in reality. As the list is
defined base former research papers and books, the hypothesis can be considered
as has already existed. Through interviews with managers and staffs of the company,
the hypothesis will be tested, so as to find out whether these risks do exist. It can
also be evaluated how actually the company identify risks during information system
development process, and how actually the company monitor and control them.
Each interview can be considered as one feedback of the checklist, and the checklist
is tested through interview. After each interview, the risk checklist and interview
questions can be improved for next interview. This kind of process fits in the repeat
cycle of deductive approach well, and the risk checklist can be quite specific after
having all interviews.
5.2 Research Strategy
5.2.1 Strategy in General
This chapter details the phases that have been employed to undertake the
43
research strategy for this dissertation. There are three phases and these stages
provide general introduction on how research has undertaken.
5.2.1.1 Phase One: Identify Expected Risks
During this preliminary stage, it is expected to develop a hypothesis about risks
that might have been faced during information system development. In order to
build up a risk checklist, literature review is considered as the best way to achieve
this mission. The outcome of this stage is a list of possible risks that have been
proved possibly occurred during previous information system development projects.
Literature reviews from authors such as Pressman (1997), Han et al. (2006) and
Cadle and Yeates (2001) have become the core of the risk checklist. This phase was
supported by the use of previous dissertations, books, journals and articles, and
conducts a bridge of comparison between academic literatures and the actual case
study.
5.2.1.2 Phase Two: Understand Actual Risks
In order to understand what actual risks are facing by the company in case study,
interviews were undertaken with individuals involved with information system
development. The outcome of this stage turns to be a new list of risks that have
really occurred during information system development of the company. There are
two steps within this phase: identification and analysis.
The identification step use interview as the major approach. Through interviews
with four individuals in different positions of the company, the researcher has had a
more accurate understanding on what risks actually disrupt system development.
During the interview, the comments from individuals were recorded immediately in
interview scripts on PC so as to help the researcher gain better understanding when
having analysis. Audio of interviews were also recorded and stored in order to clarify
44
any misunderstanding that the researcher might make. If there were any
interruption, such as phone call of interviewee or sudden embarrassment of having
interview, the record was paused in order to let interviewee to finish their works or
relax themselves. After interviews, records and comments were gathered together,
and the researcher could then build up a new risk checklist by identifying risks
discussed during interviews.
Thematic analysis and concept map were then used to analyse risks. Risks
discussed and identified during the interviews were rated as main risks and sub risks.
Thematic analysis can help the researcher to structure theme list which explains
which risks are main risks and which are less important. Concept map is introduced
for showing relationships between different concepts. In this research, concept map
can show links between risks list in theme list.
5.2.1.3 Phase Three: Make Recommendations
The third step involved suggesting available strategies and developing
recommendations which can be carried out to minimise risks happened in future
system development. This was implemented by discussing causes of risks and
defining common issues.
The dissertation aims to identify the risks that may occur during the whole system
develop process and figure out how the company will solve them through these
three phases. Objectives of this research can be achieved, which are listed as
bellow:
Analysis literatures relate to risk and identify risk checklist after analysing;
Gather information from the company to identify actual risks happen during
information system development based on the risk checklist;
Analysis real risks disrupted information system development and find out
possible reasons.
45
Once objectives can be successfully achieved, the research question is hoped to
be answered, which is set as:
How will the systems-develop company identifying risks when they occur during
securities system development?
5.2.2 Case study Strategy
According to Yin (1994, p.1), case study can be used as “a research strategy in
many situations to contribute to knowledge of individual, group, organisational,
social, political, and related phenomena”. Case study has been a common research
strategy in many fields (Gilgun, 1994; Ghauri & Gronhaung, 2002), and even can be
found even in economics.
Generally, case studies are the preferred strategy for “How” or “Why” questions.
Besides case study, there are two other research strategies also focus on “How” or
“Why” research questions: experiment and history. However, case study do not
require control of behavioural events, which means the researcher can be objective
when investigate events. Moreover, case study focus on a contemporary
phenomenon within some real-life context, the researcher can then gain knowledge
from reality instead of history, and use these knowledge in practice.
Strategy Form of Research
Question
Requires Control of
Behavioral Events?
Focuses on Contemporary
Events?
Experiment How, why? Yes Yes
History How, why? No No
Case Study How, why? No Yes
Table5.1: Relevant situations for different Research Strategies
Adopted from Case Study Research: Design and Methods, Yin (2003)
46
Case study research is considered as the most common qualitative research
strategy used in information systems (Alavi & Carlson, 1992; Orlikowski & Baroudi,
1991). Based on the scope of a case study and its technical characteristics, Yin (1994)
provides the definition of a case study as:
“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.
The case study inquiry:
Copes with the technically distinctive situation in which there will be many more
variables of interest than data points and as one result
Relies on multiple sources of evidence, with data needing to converge in a
triangulating fashion, and as another result
Benefits from the prior development of theoretical propositions to guide data
collection and analysis” (Yin, 1994, p.13-14)
It can be seen from the definition that cast study research fits well to information
system research, as the research focused on multiple aspects during information
system development instead of simply concerned technical issues. The researcher
investigated risk management the company actually have during daily system
development. By using case study as research strategy, the research can be positive
and critical.
The Case Using in This Research
The case using in this research is the Beijing Rewin Network Technology Co., Ltd.
The company was set up in 1999, focusing on develop securities company oriented
systems and provide solutions to solve problems existing in securities company. It
has strong development teams, as 80% of its employees are technicians. Based on
its rich experiences, the organisation owns 40% market share on securities company
47
oriented system outsourcing. It is therefore interesting to investigate whether this
professional software outsourcing company really has mature risk management and
control during every development process or not. In Chapter (), the company is
introduced in details.
5.2.3 Interview Strategy
An interview is a discussion with purpose between two or more people (Kahn &
Cannel, 1957). Through interviews, valid and reliable data which relevant to
research questions and objectives can be gathered. There are varies types of
interview, and the form used in this research is semi-structured interview.
For this particular research, semi-structured interview is considered as the most
appropriate method. Whilst the research supposed to understand what risks exist
during information system development by comparing with the risk checklist built
up from literature review, the nature of the interview questions turned to be
open-ended. It is because different interviewees could give different responses, and
therefore had different following questions. Different from questionnaires,
interviews let the researcher communicate with interviewees directly and allow
them ask for explanation for any interview question, which eliminates
misunderstanding of research from interviewees.
Before interviews, prior preparations were needed. There are three steps: Provide
interview questions, choose interviewees and set interview timetable. Every step
was important for have successful interviews.
5.2.3.1 Provide Interview Questions
As discussed in previous section, a formal risk checklist should be built up after
48
literature review, so as to allowed the researcher have a basic structure of interview.
Based on the checklist, interview questions were applied to focus on five aspects.
General structure:
Questions within this part mainly focused on structure of the company. The main
purpose was to understand how the company completing its daily system
development work. There are two categories of questions. The first part of
questions were only asked the CEO, which concerned about organisational structure
of the company. It also concerned about the brief introduction of develop
department and other departments which also involved in development.
The second part wondered about the development department and auxiliary
department in more detail, which acquired role of people who working in the
department. Manager of the department was primarily asked, whilst staff was also
required to describe the role of himself and relationship with others during system
development.
Development in general:
Questions within this part considered about general development process of the
company. There are three categories of questions. For the first category, the most
important information was methodology the company using. The researcher wished
to understand stages and phases the develop department using to provide
information system. Besides methodology, individual role during development is
also important. The researcher wanted to clarify the amount of people involve in
each phase and how they role. The researcher would also discuss with manager
interviewees only, about their control and monitor methods in development, so as
to avoid accidents or risks occur and solve issues after they do happened.
Development in details:
Development process should be discussed in details, as this is where most risks
49
disrupted projects. When identifying what questions should be asked, three types of
information were required to be gained:
Before having actual project or system development, it is firstly needed to make
sure every part of the contract goes appropriate. The researcher should confirm
whether the company has identified who will be responsible to communicate
customer. Customer requirements are also needed to be investigated, as confliction
or misunderstanding on requirement might lead to huge risks during develop period.
Budgets and resources for the development are also required to be prepared during
this period. Any difficulties on communicating with customers could lead to risk of
delay on whole schedule.
Customer is one huge uncertain factor during system development, as customers
are unable be controlled by develop team. Therefore, how customer cooperates
with the team can decide whether the project can be completed on time or not.
Although at the beginning of system development, resources and supports from
customer are all predicted to be enough, it might not be sufficient in reality. The
researcher should concern about risks in this aspect as well.
Even if customers support system development positively, risks could still occur
within other parts. Questions are supposed to be set about develop plan, as an
appropriate plan can help the team finish the project in time and use resources
properly. The researcher also set questions in technical aspect, of which in order to
evaluate software and hardware platform. Although developers are considered of
having abundant professional experience, it is still suggested to ask whether
programming language is familiar to developers and how these technical aspects
could influence risk control during development.
Other aspects:
There are multiple aspects which are not directly relate to system development,
50
but still influence the process and might have risks arise. For example, restructure of
the company or the team might lead to risks of develop delay. Restructure of
customer would also make the same effect. Politics or regulations within the
professional field may change in sudden, and the developing system might also
require to be changed. How to minimise risks when sudden changes come are also
what the researcher supposed to discuss with interviewees.
Risk Management:
After asked detail risks control prior and during development process, the
researcher then concerned about risk controlling plan the company has. Different
from monitor risks in process, the researcher wished to know whether there is a
systematic risk controlling plan exist, so as to help develop team understand well
what risks might have during development at preparation period. The researcher
also willed to assess attitude of interviewees on risks, to find out relationship
between risk controlling effectiveness and importance of risks interviewees
consider.
5.2.3.2 Choose Interviewees
Interviewee choosing is important to the whole research, as data is provided by
interviewees. There are two aspects need to be evaluated when decide what kinds
of interviewee should be chosen.
Firstly, it is best to have interviewees from all managerial level within the
company. The researcher suggested having the CEO, the manager of development
department, the manager of one auxiliary department and one or two developers. It
is because individual from different managerial level can have different opinion on
same events. For example, CEO may consider risk management from organisation
management aspect, whilst department manager only concern risks occur within his
department, and developer just pays attention on risks when they happen during
51
his own system development process. These different comments can help the
researcher build up a well-rounded understanding on risk management of the
company.
Besides, which department interviewees come from is one major concern as well.
Whilst this researcher discuss mainly about system development, the develop
department should have the highest attention. That is why both manager and
developer are supposed to be interviewed. Moreover, it is known that system
development also relates to many other activities, such as communication between
the company and customers, interviews with manager of auxiliary department can
therefore help the researcher understand how other department support
development.
5.2.3.3 Set Interview Timetable
Interview timetable setting in this research seemed to be one difficult mission.
The main reason for this is the time difference between the UK and China. It is
tough to gain response from the company for booking interview, as the researcher
always had to send an e-mail in one day and be replied on second day. This kind of
delay also slows down the progress of dissertation. There was also one cancellation
of interview due to time difference: the CEO sent an e-mail by replying the
researcher could have interviews at 14:00PM. However, because the e-mail was
replied at 5:00AM in UK time, it was not noticed until 9 o’clock, whilst it was already
16:00PM in China. This accident also led to two day delay on having interviews. The
solution for this situation was to contact the CEO directly by phone immediately
after realising interviews were missed. After apologise, the researcher booked time
immediately by suggested interviews begin from 9:00AM in the UK time.
Besides the three sections discussed about, there are also some other notices.
Whilst the researcher stays in Sheffield and the company sets in Beijing, China, the
52
interviews used instant message software. The researcher provided Skype, MSN and
QQ as options for interviewees to choose, in order to let interviewees feel
comfortable on having interviews. What is more, the researcher tried several audio
record software and have test interviews with friends, so as to make sure audio of
formal interviews can be recorded clearly.
5.2.3.4 During Interviews
Before have interviews, interview question script and privacy confidentiality
protection announcement were both sent to the CEO, in order to avoiding any
privacy infringement. The researcher also suggested the CEO send these two files to
other interviewees before interviews, so as to let them make sure about their rights
and get familiar to interview questions.
At the beginning of interviews, the researcher firstly introduced herself to the
interviewee and generally introduced the dissertation, of which let the interviewee
understand what the interview for and helped him to relax. Whilst interviewees
stayed in meeting room alone during the interview, the environment could also
encourage them talk about more risks they concerning of the company. Although
the researcher had sent interview questions to the CEO, during the actual interview
the researcher still informed interviewees what kinds of questions would be asked
before start. These questions were devised based on combined risk identification
frameworks by Pressman (1997), Han et al. (2006) and Cadle and Yeates (2001).
Besides of asking interview questions based on this framework, the researcher
asked additional questions as well so as to gain an understanding of interviewees
job role, especially how themselves role during work. Because of different
personalities of interviewees, the researcher needed add different questions to help
interviewees provide data the research need.
53
There are two kinds of additional questions. The first type is trigger question. For
instance, one of the interviewee was quite introvert and preferred answer questions
by simply “Yes” or “No”. To solve this situation, the researcher tried to guide the
interviewee by asking “When you say yes, do you mean….?” or “You said no for this
question, is there any relationship with what you mentioned…?” The result for these
guidance questions were quite helpful, not only this could encourage interviewees
talk about more, but also made them combine some points they did not notice and
provided more thoughts and comments than expect.
Another type is direct question. In contrast to introvert interviewees, some
interviewees answered so much on one question. Moreover, interviewees felt
nervous or unwilling to talk about negative sides of their company, as they think this
will harm its image. For example, when the researcher asked manager interviewees
what risks might occur during system development of the team, they always spent
more time on complaining disoperation of their customers. To redirect their answer,
the researcher responded as “Sorry to interrupt you, I understand there are risks
from customer aspect, but you mentioned your team member felt difficult on…., is
this also influence the whole project?” This kind of questions forced interviewees
reconsider about the question and gave the information researcher want.
5.3 Research methods
5.3.1 Data collection
When consider about data for sociological research, there are two kinds: primary
data and secondary data. Primary data is gathered by surveys, observations or
interviews, secondary data is gathered from documentaries, censuses, government
reports or so on (McNeill, 1990). These two kinds of data can be used individually or
together in one research by considering what kind of data the research needs.
54
According to Saunders et al. (2007), there are several advantages to use
secondary data. Using secondary data can reduce the cost to gather data, and huge
amount of information can be directly found in such as censuses. Time can be saved
by using secondary data, and if combine with the use of primary data, comparison
can be made and new discovery might be developed.
To collect secondary data, case study is used as the data collection method. As
discussed in Section 5.2.2, according to Yin (2003), case studies are preferred
strategy when questions are being posed as “how” or “why”, which fits the purpose
of this research quite well. Besides of case study, literature review also provided
secondary data for this research. With literature review, formal risk checklist was
built up, of which used as the core of primary data collection.
However, using secondary data also have lots of disadvantages. As secondary data
is always collected for a particular purpose, it not always matches the research’s
need. Because of traditional existing bias, reliability of secondary data may be
affected. For example, the risk checklist was built up from journals and books which
discuss project risk management in general, and these risk management and control
solutions are all based Western country environment, of which do not suit the
situation of the research.
As a result, primary data is indeed needed in this research. Interview was used to
gather primary data. Although interview questions were designed by following risk
checklist, it has discussed in Section 5.2.3 that the researcher asked additional
questions to each interviewee so as to understand his job role during system
development process. Whilst data gathered from interviews is qualitative data
(Saunders et al., 2007), data analysis methods should be fit in qualitative data
analysis. Therefore, thematic analysis and concept map were both used for data
analysis in this research.
55
5.3.2 Data analysis
In order to analysis data accurately, proper analysis methods are needed. For this
research, two methods were used for data analysis: Thematic analysis and concept
map.
5.3.2.1 Thematic Analysis
Thematic analysis is one kind of analysis which combines a deductive and an
inductive approach to qualitative analysis (Saunders et al., 2007). It is considered as
one of the most frequently used methods in qualitative data analysis. However,
seldom literatures discuss how to carry out a thematic analysis, of which means
difficult connection with the method (Howitt & Cramer, 2008).
When using thematic analysis, the researcher needs to identify numbers of
theme in a list. What these themes adequately reflect not only can be textual data,
but also many other forms (Miles & Hurberman, 1994) – photographs, video footage,
interview transcripts or so on. Therefore, the identification of themes is not so easy,
as it is hard to use several particular themes to express the whole picture of
research. In order to provide themes accurately, researchers need to be extremely
familiar to the data they going to analysis. The most effective approach to increase
data familiarisation is to collect data by researchers themselves and transcribe data
themselves as well. In the context of this research, the researcher held interviews by
her own and did data transcription by using Microsoft Word. It had therefore
increased data familiarisation.
Whilst thematic analysis requires researchers code their data and finally build up
theme lists, it also requires researchers have expectation about the direction in
which the analysis will focus (Howitt & Cramer, 2008). In the context of this research,
the researcher firstly developed a risk checklist which gathered and categorised
56
from former research papers and books. When designing interview questions, the
checklist was used as direction and also used in building up theme list. Although
risks mentioned during interviews did not exactly the same as checklist (sometimes
even had some interesting conflictions), the checklist was still acted as guidance.
Those risks which were not listed in the checklist were added into the theme list,
and those were not mentioned or not cared by interviewees were deleted. All
interview records were analysed in this way, and a whole theme list of risks was
built up at last.
Nevertheless, thematic analysis could just show simple categories of risks. The
common situation in reality is that risks in different categories always have
relationships between each other. For example, Risk of insufficient cooperation from
customer may lead to risk of development timetable delay, whilst it might be caused
by risk of lacking professional knowledge on customer side. All these three risks are
from different categories and thematic analysis can hardly represent this
relationship. In order to cover this shortage, concept map was used as the second
data analysis method.
5.3.2.2 Concept Map
Unlike thematic analysis, concept map in contrast, can be used to clearly present
relationships between risks (Randon, 2011). It covered the insufficient of thematic
analysis, and helped the researcher find out how risks relate to each other within
the organisation.
According to Novak & Canas (2008), concept maps are used for organising and
demonstrating knowledge by graphical methods. Concept map uses labels or boxes
to represent concepts, and displays relationships between concepts by using a
connecting line linking them. Words or phrases might also be written above lines, so
as to explain what relationship these concepts have. Concept map uses hierarchical
57
structure to identify relationship and dependence between concepts. It means a
map structure from most general concepts at the top to more specific concepts
arranged below, of which provides clear hierarchical expression of knowledge. On
the other hand, it should be noticed that concept map is appropriate to be used
when there are some situations that researchers are trying to understand in the
form of a concept map after organisation of knowledge (Novak & Canas, 2008).
Therefore, concept map is suitable when there are some focus questions need to be
answered. Besides, one significant character of concept map is the inclusion of
cross-links (Novak & Canas, 2008). Cross-links can link concepts of different
categories, in order to help readers to see how concepts having connections with
others. Moreover, through cross-links, new knowledge might be produced.
In this research, based on result from thematic analysis, concept map tended to
be a whole picture of all risks existing in development process of the company.
Whilst thematic analysis categorised risks and helped the researcher to find out
what risks are Achilles’ heel to the company and what is not, concept map can help
the researcher point out how these vulnerability were born and influenced the
company’s profit. By combining these two data analysis methods, understanding of
risks and risk identification through interviews turned to be quite comprehensive.
5.4 Ethical Issues
Ethical issues are one of the most important parts through the research. Ethics
can be defined as:
“…the moral principles, norms or standards of behaviour that guide moral choices
about our behaviour and our relationships with others.”
(Blumberg et al., 2005, p.92)
58
Therefore, research ethics can be related to all process during the research
(Saunders et al., 2007), and how to avoid ethical issues should be paid extreme
attention. In this section, all possible ethical issues will be discussed as well as
solutions to get rid of potential threaten.
According to Saunders et al. (2007), there are ethical issues: 1) during design and
gaining access; 2) during data collection; 3) associated with data processing and
storage; 4) related to analysis and reporting. Based on the context of this research,
possible ethical issues and their solutions in each phase will be discussed as follow.
5.4.1 Ethical Issues During Design and Gaining Access
When considering about ethical issues during design and gaining access, strategy
of gain access to participants was the first mission. There are some possible reasons
the organisation may refuse to be interviewed: the organisation might be quite busy
during this period so employees do not have sufficient time to have interviews;
organisation cannot see benefits the research can bring to it, or even afraid to
receive bag images after the research; the language of the research may not
suitable for the organisation, as the company is in China and the research was taken
place in UK.
To figure out these potential issues, the researcher firstly sent an email to the CEO
of the company to introduce the whole research in details. Within the email, the
research also provided a Word file about the purpose and general process of
interviews. It highlighted the possible benefits of interviews, which is to allow the
organisation clarify what kind of risks occur in its daily system development process,
and how actually employees monitor and control risks, so as to help the
organisation improve its risk management method. The researcher also informed
that interviews would all be held in Chinese by providing Chinese interview
59
questions before interviews. As the email was sent two months before actual
interviews, it allowed the organisation had fully time to decide interview date. Reply
from the CEO was quite positive, as he soon agreed to have interviews and gave
some suggestions on interview field and question design
.
After having agreement of interview, one dominant ethical issue occurred:
consent to participate. Whilst the researcher had gain promotion of the CEO, it was
possible that participants joined interviews because of pressure. They might not
have clear understanding of the research, so they may feel pressure of their privacy.
To avoid this kind of issues, the researcher sent participants consent form, including
introduction of research and interview purpose, how interview will be taken place,
how data will be stored and used, and how participants’ privacy can be protected.
Ethical Issues during Data Collection and Storage
Multiple ethical principles are needed to adhere during this period. As discussed
in previous section, privacy of interviewees’ should be protected. As Saunders et al.
(2007) suggest, when interviewees agree to participate, they still maintain their
rights. It means that interviewees can ask to quit during interviews and researcher
cannot give them pressure. To ensure this, the researcher announced all ethical
policy again before interviews, so as to make sure interviewees could understand
their rights.
Another ethical principle is related to the objectivity of researcher. It means that
during data collection stage the researcher collects data accurately and avoids any
subjective selectivity of what the researcher record. To avoid this, the researcher
used audio recorder to record interview record, as well as comments in Word file.
What is more, the researcher responded to interviewees as ”What you talked about
is quite interesting, could you explain more on….?”, instead of responses like “I think
what you talked about means…., could you talk more on this field?”. By doing this,
the researcher hoped participants could provide their own ideas, so as to reduce
60
subjectivity to minimum.
Using the Internet during data collection may also lead to serious ethical issues
related to confidentiality (Saunders et al., 2007). For instance, researcher uploads
data to internet and share data to others easily without promotion of participants.
This seriously harms rights of participants. Therefore, although internet allows
researchers collect data from far distance, researcher should be cautious on these
concerns of data storage. The researcher recorded audios and saved these record
files in the same personal computer. Another copy is stored in an USB flash disk to
prevent data lost. All these data was only collected and stored in one computer, in
order to protect information from transmitting on internet.
5.4.2 Ethical Issues Related to Analysis and Reporting
Maintenance of objectivity includes multiple aspects. Researcher should not be
selective about which data to analysis or report, where accuracy might be
misrepresented (Zikmund, 2000). Additionally, confidentiality also turns to be
dominant during the analysis and reporting stage of research. In this research, the
company allows the researcher reporting all data collected during interviews, as a
result there is little worry on confidentiality.
5.5 Limitation
Although the researcher tried to avoid every possible issue during the research,
there are still some limitations.
The first limitation is knowledge of the researcher. Although there are several
courses introduce risk management, the information is quite brief. After read
journals and academic books about project risk management, the researcher could
61
just have brief understanding of this area. However, there are still some difficulties
occurred during literature review and data collection phase.
The second limitation is time for the research, especially for interviews. Although
the whole length of dissertation was sufficient, it took longer time on literature
review than schedule. It was because within literature review, securities market was
what the researcher never learnt. Besides, whilst the Beijing Rewin Network
Technology Co., Ltd had mass of business during the dissertation period, it was quite
difficult to had appropriate time for each side.
The third limitation is language. When interview question scripts and risk
checklist were firstly written, they were produced in English. However, because the
company is an Chinese organisation, all files needed to change into Chinese. It is
therefore unavoidable to have some misrepresentations during translation. Same
situation also occurred when the researcher translated interviewees’ response from
Chinese into English.
62
Chapter 6 Results and Findings
After introducing expected risks in Chapter (), this chapter presents the results of
interviews jointly. The theme list of risks identified during interviews is firstly
introduced, follows by concept map which bases on those themes represent in
theme list. Each category of theme will be discussed separately by using comments
of interviewees, and concept map will be used at last to explain relationship
between categories.
6.1 Presentation of the Results and Findings
The results and findings of interviews are discussed as a narrative, which is based
on the same structure of theme list. The narrative is then summarised in the form of
a whole concept map.
Narrative
The narrative provides description of the key results and findings in text. This
contains comments and quotes form interviewees.
Theme List
The theme list is built up by using thematic analysis. As discussed in section (),
thematic analysis is always used in qualitative data analysis, by identifying important
themes in a list. Broad theme categories are firstly identified, and then under each
category, sub-theme will be put.
Concept Map
Concept map is used to connect concepts into networks. Nodes (represent
concepts or themes) and links (relationships between concepts) are used to form
networks. Whilst in Chapter 5, it has been discussed that concept map allows
researcher to understand the relationships between viewpoints by creating a visual
63
map. To produce irredundant concept map, accurate categorise of themes are
needed.
6.1.1 Introduction of Interviewees
There were four interviewees participated in the research in two days time.
General information of interviews can be found in the following table:
Name Title Interview held time
Mr. Keyi Chen Development leader Thursday 18th August
2011
Mr. Chaodong Liu Manager of product design
department
Friday 19th August 2011
Mr. Rui Shi Development engineer Friday 19th August 2011
Mr. Xiaodong Liu CEO Friday 19th August 2011
Table 6.1 Brief Information of Interviewees
The first and the second interview lasted around 45 minutes, the third interview
lasted about 30 minutes and the last one was held for one hour. Distinction of
interview time length is caused mainly by different position each interviewee staying.
Some questions can only be answered by particular position, whilst some others are
common questions to everyone.
6.2 Theme List
Whilst the research is deductive-based, one expected risk checklist was produced
as hypothesis. The checklist was categorised into seven parts as follow:
64
Contractual and business relationship issues
Communication channel during and after development
Pre-project preparation
Customer sides
Developing System
Technical aspect
Other aspect
It can be seen that the checklist follows system development process, so as to
clarify risks during each stages. Interview questions were then designed in the same
structure. However, because risks in different stages might be caused by one reason,
continue using same framework may cause redundance. Instead of considering risks
step by step, the theme list tries to establish a more distinct framework, which is
represented as follow:
THEME LIST
1. Contract Issues
1.1 Budget
1.2 Time Length
2. External Environment
2.1 Communication with Customer
2.1.1 Business Relationship
2.1.2 Requirement Understanding
2.1.3 Customer Attitudes and Behaviours
2.1.4 Professional Knowledge
2.2 Customer Processes and Management Culture
2.2.1 Project Management
2.2.2 Maintenance and Update
2.3 Environment
2.3.1 National and Social Cultures
2.3.2 Business and Personal Relationships
65
3. Internal Management
3.1 Management
3.1.1 Project Management
3.1.2 Team Restructure
3.1.3 Resource Scheduling
3.2 Communication
3.2.1 Within Team
3.2.2 Between Teams
3.3 Technical Aspect
3.3.1 Technical Complexity
3.3.2 Knowledge and Experience
Compare to the former framework, the new structure identifies four categories of
theme. Contract is separated from other themes, because development cannot start
without an accurate contract. During the interviews all interviewees mentioned how
external environment influence system development; therefore customer aspect
and environment aspect are discussed in details.
6.3 Concept Map
Based on the theme list, the concept map can be built up as Figure 6.1.
66
Figure 6.1: Concept Map Based on Theme List
67
6.4 Theme One: Contract Issues
Contract issues are important in risk identification, as contract is the start of every
project. Without reasonable contract, the organisation cannot produce systems
properly. Interviewees believe their contracts are completely logical without any risk.
For example, when the researcher asked whether any problem occurs associated
with contracts during development, the development leader (DL for short) said:
“I think there is no problem with contracts. If any problems occurred, our selling
department will find them out before sign contracts so as to avoid them. Besides, our
contracts have already been standardised, hence we can prevent many risks on
contracts.”
Additionally, the CEO also explained how contracts are decided before sign:
“After won the bidding (of project), we will make a contract based on customer ’s
requirement. In order to guarantee the contract fulfil customer’s need, we will always
hold a meeting. Members of meeting are those who in charges of the project and me.
We will discuss requirements, and then decide desire budget and time length, as well
as a brief project development plan.”
It seems that risks within contracts can be completely avoided. However, during
interviews the researcher found that those contracts are not as effective as
interviewees thought. Actually, interviewees mentioned two risks within contracts in
two aspects before they realised: budget and time length.
6.4.1 Budget Issue
In fact, budget issue is a common risk within the organisation. Develop teams
68
always have to face risks of insufficient budget which may cause interruption of
project. The CEO mentioned as:
“When discuss about budget with our customers, we always ask for budget which
is 15% higher than the project actually needs. Why? Because in customer aspect, it is
always hard for them to get sufficient budget for a system development project, as
their leaders think develop information system is cheap enough.”
He also said:
“Once there is time delay within a project, cost of producing the system will
certainly rise. However, it is usually quite difficult for customer side gain more budget
during development. They may consider delay as full responsibility of us and refuse to
pay more. But in most cases the reason is completely opposite. Our company have to
reduce cost raise due to delay.”
When the researcher asked if there is any cost control method to avoid budget
insufficiency, the manager of product design department (MPD for short) explained:
“The cost control method is meaningless. In most cases, customers always have
their own ideas on what should be done in developing systems. However, most
customers do not have such kind of knowledge or experiences. Our team usually need
to have more time to communicate with customers than expected. We can control
cost during our development, but we cannot control cost out of development.”
It seems that budget issue is actually influencing a lot during system development.
The most significant characteristic is all three managers underlined that customers
themselves are the dominant reason of budget issue. Besides budget, time length
setting is also a problem when deciding contract.
69
6.4.2 Time Length Issue
As discussed in previous section, budget issue usually cause delay on development,
and delay means insufficient time length. It seems that time length is the result of
budget issue instead of potential risk itself. Nevertheless, time length might now be
sufficient even when the contract was signed. The CEO explained:
“Most of Chinese organisations seem not so care how long the project needs to be.
They always consider in their own ways, even it may not be the real situation. When
discussing length of project, they might think that if we can’t finish in the time they
set, it simply prove we don't work hard enough. They seldom consider about changes
of environment or delay from themselves…They intentionally come up with a tight
time length, so as to force us to increase our efficiency.”
Besides, how time length set is not standardised. Instead, it sometimes depends
on relationship between the organisation and customer. MPD mentioned this point:
“It’s easier for us to gain a reasonable contract if customer already has business
relationship with us. It is because they can understand how long we need to develop
a system. However, if it is the first time we have cooperation, the case may turn to be
quite difficult, and we may have to accept a time length which is not sufficient
enough. Our wide experiences in developing securities system do help us in
persuading customer, but some customers would still resist to their own plans.”
Budget issue and time length issue cannot be ignored when identifying risks during
system development process, because contract decides what the organisation should
do and how to achieve customers’ aim. Although interviewees do not think they have
any risks in contracts, through conversations the researcher found that it is because
they consider these risks as unavoidable. Another feature is the three managers all
mentioned customers’ influence. Therefore, risks cause by external effect will be
discussed in theme two.
70
6.5 Theme Two: External Environment
As discussed in theme one, the researcher found through interviews that there are
risks occur within contracts, interviewees believe these risks are caused by external
environment such as customer. The CEO mentioned that “at least 80% risks come
from customer aspect”; the MPD also considered in the same way, and the DL even
suggested “all those delay of projects are due to customers”. As a result, it is
important to categorise risks from external environment.
6.5.1 Communication with Customer
Communication with customer is the dominant part during system development
process. According to the DL, “we need to communicate with customer in all stages,
in order to find out whether what we do in this stage fits in customers’ desire”.
However, there are always some risks during these communications, and influence
development progress.
6.5.1.1 Business Relationship
As stated in Section (time length), good business relationship can help the
company to finish its works in more comfortable way. The MPD emphasised many
times and said “If you can make your customer happy, you can get everything.”
However, business relationship between the company and their customer are not
easy to build up.
The buyer-seller relationship between the company and its customers brings risk
potentially. Just as the CEO supposed:
“Our customers are very different from us. Our company has varies projects every
year and has gained lots of experiences. On the other hand, most of our customers do
not have such kind of experience. We want to build consciousness in risk
71
management and control or management of customers, but they consider these
reasonable requirements as excuse. It is just because we are buyer-seller relationship
to them. Customer may think, ‘He said this because he wants to escape from his
responsibility.’ Or ‘He sells system to me so he should complete system as I request.’
These kind of inappropriate thoughts prevent the company from having effective
development plan.”
Besides, relationship between the organisation and its customers can be easily
changed due to change of project manager in customer ’s aspect. The MPD
complained about this:
“As I said, it is quite difficult to build up business relationship. However, at
customer aspect, their project manager might change during development process.
This change may cause by demission of former project manager, or the person has
other works to do. This kind of change may cause quite low risk in Western
companies, but in China it is completely different. We all know in many cases business
relationship builds upon the base of personal relationship. If a stranger project
manager comes in the middle of system development, it might take some time to let
him understand what we are doing and take more time to set up sense of trust to our
company.”
Difficulties in gaining good business relationship turn out to be risks of
development projects. As interviewees mentioned, without trust from customer, the
company can hardly complete projects.
6.5.1.2 Requirement Understanding
Even if the company gain a good enough business relationship, there are still some
other risks. Requirement understanding also turns out to be one part needs to be
care.
72
Interviewees find themselves sometimes difficult to catch up customers’
requirement. Customers change their desires frequently, as they always hope they
have the best system by comparing to others’. When the researcher asked whether
there are customers ask for “the best system ever had”, the DL said:
“This situation is quite common within small size securities companies. This kind of
customers always says ‘We want to have the most advanced securities system within
five to ten years time’. However, these requirements can never be achieved. It is
because we can only develop a system for you, and the system is just a platform for
customers to add in information. The system cannot be ‘the best’ without relevant
information.”
The MPD explained this point in advance:
“Here are the common cases: after months we have finished our coding and send
the semi-finished system to customer to check. Customers always response, ‘Actually,
last week I saw a system in another company, I think that is awesome and fit my
needs better. Can we modify this system to that kind as well?’ Maybe the system is
better, but we all know how far technology these days develops. If you want to
always catch up trends of latest technology, it’s possible that you can never catch it.”
Another possible reason for customer misunderstanding requirement is that they
cannot imagine how system can actually be before they see an entity. The MPD has a
deep sense of this:
“Before they see the page prototype, customers always consider they have already
clarify what they want. But once they see the prototype, they will always find out it is
different from their imagines. Then customer will ask for modify prototype. This stage
usually last much longer than customer expected, which finally cause delay. What we
can do is to clarify that the responsibility is customer ’s and change prototype base on
the contract.”
All these misunderstandings on requirement can cause delay and changes in
system development, which turn to be risks of system development process. It
73
cannot be avoided that sometimes misunderstanding on requirement is caused by
development teams. Risks of this part will be discussed in theme three.
6.5.1.3 Customer Attitudes and Behaviours
Positive attitude of customers can help system development more efficient whilst
negative attitude might delay or even make the development fail. In this research,
the researcher found that attitude of customer turns to be a risk for system
development.
It is interesting that different interviewees have distinct feeling on customer
attitude. The difference comes out from the position each interviewee at. The DL has
no worry on negative attitude from customer, as he said:
“If they seem to be unwilling to have the project, then there are must be something
wrong. How can customers ask for a system if they do not really want it?”
It is possibly because the DL is in charge of general management of all projects
instead of in details. The development engineer (DE for short) also has the same
experience, but the reason is a little different:
“When customers have turned to coding stage, they have already given up on
refusing systems (if they want to during first time), because there is no way to change
now. They may feel a little upset, but they all cooperate with us.”
On the other hand, the MPD has quite different feeling. As his department always
need to communicate with customers and finishes demand analysis and design, the
MPD experiences a lot on negative attitude of customers and risks cause from it:
“The most common excuse is ‘I’m busy and have no time to meet you.’ As I told you,
we need to have interviews with customers in different departments so as to
understand their demands. However, in most cases, we will receive excuse as above
for many times. Of course, there are many reasons for negative attitude. Customers
do very busy, so it is not easy to make timetable for interviews. They consider us as
74
disturbing their daily works. Some customers are introvert and don’t want to discuss
with you; some never consider about system development and don’t know what to
talk about. Sometimes customers resist to system development, because they might
lose jobs; sometimes it just because the customer has personal problems with his
colleague. All these reasons cause negative attitudes of customers and we have to
face them every day. What we can do is just communicate with customers without
involving any internal details of customer aspect, but we have to take risks come from
internal details even we have no relationship with them.”
6.5.1.4 Professional Knowledge
As discussed above, attitude of customer could be a huge risk on system
development process. Nevertheless, even if customer has positive attitude and
wishes to participate in system development, there are some other risks appear.
Nowadays, hardware and software platforms become cheaper enough for every
company to build up, therefore no gap exists in this field anymore. Professional
knowledge of customers, especially those who responsible for system development
in customer aspect, turns to be important. The MPD explained how lacking of
professional knowledge of information system becomes risks of system development:
“…Some customers are willing to have systems, and they always want to talk about
their suggestions on how the system should be framed and what services are needed.
Sometimes customers have great idea and quite logical, so we can gather
information smoothly. But many others just talk about whatever they are considering
and have no key point at all. More serious problem is that some customers insist to
their own idea and think their ideas must be suitable for their companies, when for
the most part they are not. This situation is common in private projects as customers
think of course they can understand their own needs.”
However, customers might not that clear about their real needs as they thought so.
The reason is that customers do not have sufficient professional knowledge for
75
information system development. The DL proved as followed:
“It’s quite common and quite reasonable. Most of our customers are specialist of
operations instead of programming; he/she just know how to describe his thoughts.
We all know there are huge differences between real world and system
implementation. What we do is listen to those customers who can provide clear ideas
and do what they want, and use our experiences of producing systems for dozens of
securities companies, to prove those who don’t clear and let them know how the
system can be when it is implemented. Even so, we still need to have adjustment for
many times.”
6.5.2 Customer Processes and Management Culture
It has been said that the company tries to avoid participate in customers’ internal
problems, so as to let the organisation be objective and get rid of troubles. However,
it does not mean there is no consideration on management within customer aspect
when having system development process. Many phenomenons that customers act
are caused by inefficient management of customer aspect, and these inefficiency
cause risks to the company and system development process. To avoid these risks,
management part which relates to the company needs to be understood.
6.5.2.1 Project Management
Interviewees tend to be negative on customer’s project management (PM for
short) capability. They suggest many risks occur because of ineffectiveness of PM. For
example, when talked about insufficient time length, the CEO also mentioned:
“I can understand that our customers also receive lots of pressure from their
organisation, and these pressures force them to raise time length which is not
realistic. However, the most important reason is that they don’t have as much
experience in PM. They just consider the project in idealised state. For instance, in
76
idealised state, one project can be finished in three to four months. The project
manager therefore asks us to produce the system in three to four months, but he
didn't consider any possible risks. They always have little awareness on controlling,
management and risk, but it is hard to build up their awareness in a short period.”
The MPD pointed one characteristic of customers’ project management:
“Many project managers of our customers cannot make their own decisions.
Sometimes we send the page prototype to the project manager and ask for opinions.
If he says yes, then we can start coding and implementing. However, the project
manager always has to ask for permission from his leader, as the webpage or system
represents his company’s image. Then we always need to wait for a month, even
longer than the time we used to make prototype…Sometimes there may also be some
conflictions between their departments. For example, after we have produced the
prototype, customer’s project management team will participate in to check it.
However, as these team members come from different departments, they may have
confliction on which part of their service should be implemented in details and which
part should be simplified. If there is no senior manager makes decision, it will cost a
long time for them to argue.”
6.5.2.2 Maintenance and Update
In most cases, customers require the company to help them maintain and update
systems. However, risks can also come out if customers themselves do not have
relevant plans and methods. Many customers seldom maintenance or update their
systems, as they consider as necessary, or sometimes it is because the system is too
old to update. The DL experienced such kind of events:
“Cycle of maintenance and update depends on customer ’s own situation. Some
systems update every one or two years, while others may update after five or six
years and just have some maintenance every year. It depends on operation principle
of the securities company. For example, securities companies locate at costal city
77
always have more ideas and will to have more changes. On the other hand, securities
companies locate at remote area might even not care about their systems, as they
just used the system to cope with their director ’s demand. In this case, securities
companies of course don’t need any update, as they even don’t know why they have
the system. As I know, there is a system haven’t changed for ten years. As our
products have already updated for several periods through these years, it is difficult
for us to maintain those systems which have already been out of date. What only we
can do is to produce a completely new system.”
Other risks also rise in developer aspect, and these risks will be discussed in theme
three.
6.5.3 Environment
The environment of the company is interesting and full of risks. Different from
western environment, software development in China has its own characteristics.
Within this environment, some specific risks will occur. Based on its own securities
market policy, the company have to concern more than their western colleagues do.
6.5.3.1 National and Social Cultures
It is considered as unhealthy about software development environment in China.
Within this environment, software development companies always have to face
much immature behaviour of their customers. The CEO described the current
situation in China:
“You told me that other interviewees consider some avoidable risks as unavoidable.
I can quite understand this…Some risks do can’t be avoided in current situation, as
the environment is unhealthy. Suggest we are working in an ideal condition: our
customers give us a reasonable time by considering all possible delays and provide
sufficient budget; their project managers have veteran experience in software
78
development and can understand changes within development. Based on these
conditions, we of course can provide sufficient human resources and finish in time.
However, it is not the case in China
…This is the influence of environment, and software development companies in
China can hardly have vigorous growth momentum. We can’t change the
environment, and therefore we cannot avoid many risks that western companies can.
As a result, to survive in this environment, we have to change our operational mode,
and when we produce satisfied systems under this situation, our company’s value can
be presented.
…We are struggling in this environment, and many of us, including other
interviewees you interviewed, have accepted this environment. What we should do is
jump out from the current mode and find out new ways to reduce risks, instead of
simply accept it.”
6.5.3.2 Business and Personal Relationships
Relationship has turned out to be more important in China, and also show
significant influence on software development. As discussed in section 6.4.2, good
business relationship can help the company gain a more reasonable contract. As
opposite, relationship also increase risks on system fail.
Relationship is intangible, and hard to measure and manage. Therefore, it is
difficult for the company to identify whether the company has a “good relationship”
with its customer, so as to address whether there is any risk. Besides, relationship
and position difference between individuals within customer aspect can also increase
risks. The MPD is the person who communicates most with customers, and he
concluded as following:
“It is easier to finish projects when we gain good relationship with customers. We
will choose different kinds of people to communicate with customers in different
development phases. In the product design phase, if we gain understanding or
79
agreement of their senior manager or director, it will be more efficient.”
“As we said, we always have to wait a long time until customers decide whether
the prototype is good enough or not. During this waiting period, we will not stress
those staffs. Instead, we will always stress senior managers or director, so as to force
them decide quicker. After one month, these managers may able to give us the
result.”
However, he also mentioned:
“We can’t say every time this kind of pressure is useful. Sometimes, if the company
desires the system just because they want to cope with their stakeholders, managers
can spend months to decide a single page. What’s more, in some case customer may
ask for several changes, and it will need another long period to wait response.”
From above, it can be seen that environment in China is consider as negative
impact on system development, and intangible relationship between companies and
individuals can also increase risks.
6.6 Theme Three: Internal Management
Although the CEO and the MPD both emphasised that at least 80% of delay causes
by external environment, they also admitted they still have 20% of responsibility.
There are three sub-themes within internal management. Firstly, management
method of the company is still vulnerable, which increase risks on project delay.
Secondly, insufficient communication within development team and between teams
may cause misunderstanding of project, and sometimes even lead to delete and
recreate new modules. Thirdly, knowledge of employees themselves limits their
capabilities, and in some cases rise risks in project delay.
80
6.6.1 Management
What talk about management within the company, there are three fields which
have potential risks. Firstly, although the company is mature for project management,
some processes seem do not follow standards; team restructure is common during
development and easily cause project delay; At last, based on an insufficient
resources background, schedule of resources turn to be much difficult.
6.6.1.1 Project Management
When discussed about project management, the DL described how the company
avoid project issues:
“We hold one meeting weekly, by discussing all projects in progress in last week,
and evaluate whether there are some deviation within projects so as to prevent
bigger issues. All project leaders and senior manager will join in, including the CEO.
By holding the meeting, we can have better understanding of our current progresses,
and we can deploy human resources quickly if there is any need.”
The CEO had additional comments, “Our system developments are basically
following RUP, but we have changed and simplified in some stages. As we have
already passed the ISO9000, we believe our standardisation of document is quite
precise.”
However, the CEO also known well that some standards seem not be implemented
quite well:
“When we have evaluation on projects, there is no actual prove that we can find
out all potential problems within them. It is possible we make some mistakes, and
these mistakes may lead to misunderstanding of projects or wrong coding.
Although we ask employees to follow standards strictly, it can’t always be achieved.
81
If we have high pressure on time or resources, then possibly standards can’t be
followed. For example, we formulate how many steps should have in software testing,
but we may skip some steps if time limits. Another example is when we need
customer to confirm some modules of the product, it is forbidden to use email instead
of signing on paper. But sometimes our time is tight; we can only send an email to
customer for confirmation and ask for signing later.”
Besides issues on standards, frequent changes on project plan within the company
rise risks on system fail as well. The MPD mentioned:
“As you know, we always have delay in our projects, and the time length is
commonly quite long. As a result, we have to change, or sometimes redo a new
project plan for our projects. While we have delay always, we have to have new plans
always. It seems from the external aspect that we ‘have plans execute on time
forever’, but that is just an illusion. These new plans also force us to reschedule all our
works again and again.”
6.6.1.2 Team Restructure
Team restructure is common in the company; it is because of time delay on
previous projects, as people from delayed project may switch to other projects; or
when one project is near deadline, staffs from other teams may change to this
project for help. However, risks which occur because of team restructure cannot be
ignored.
Several risks can be raised. Firstly, because of restructure, there will be some time
delay, as new members need time to clarify their roles. The DE explained:
“There is always some of this kind of situations: we are doing one project, but
suddenly we are asked to switch to another. We need a period of time to understand
how the new project be doing, and what kind of technology this project use. These
two steps all need some time. When we finally start to do the new project, already
82
some time has been delayed.”
The MPD also mentioned risks in team restructure, but he supposed changing
team leader or manager will cause higher risks than team members:
“There are some cases that projects need to handover from one team leader to
another. In this case, customer may feel inapprehensible, and requires for explanation.
This kind of situation may lead to company image reduction, or distrust from
customer.”
Secondly, because the company cannot control delay length of customer aspect,
there is a potential risk for team member leaving current project. For example, the
CEO mentioned:
“We always meet this kind of situation: We produce a home page and send it to
customer. Customer supposes to feedback in one day, but they may delay for one
month. We can’t leave our staffs just in this projects and wait for them, so we
restructure these members to other teams. Just after we done all of these and start to
having new projects, customer suddenly send feedback and require for changes or
start next part. As we can’t stop the new project until some phases, the former
project has to wait and time is then wasted.”
6.6.1.3 Resource Scheduling
Resource scheduling is extremely important in this company, because as the CEO
pointed out: “Resource in our company is insufficient in nature. What we can do is to
use insufficient resources to produce thorough systems. This is our value.” Therefore
in this company, insufficient resource tends to be one risk which cannot be avoided.
With the background of this risk, some other risks are born.
As the main resource of this company is human resource, personnel assignment at
the beginning is important. However, as discussed in previous section, project delay
lead to frequent change of human resource, which cause time waste for project
familiarity.
83
Insufficient resource brings about high risk on system fail, as the company has little
resource to recreate a new one. The CEO argued:
“It’s full of risk during our project development and that’s why we have weekly
meeting. If we get wrong in some parts, for example, misunderstanding customer
requirement and produce wrong product, then we may cost twice as much to fix the
problems. Because we don’t have enough resources, we don't have enough time.”
The MPD also explained the difficulties and risks when scheduling:
“In every Monday’s meeting, we will set timetable for everyone in this week. As
weekly working time is 32 hours, therefore, it needs some time to decide how to use
these limit resource. For example, if we need to have interviews with customers, I
need to decide which one should be sent to which customer. It is very difficult to
manage members if let them work in other place, such as go for interviews, because
you can’t accurately calculate how many time they may need to interview customers.
Therefore, even if we have made a timetable, there are always possibilities we have
to change later. Once the timetable changes, there is a high risk that the plan have to
delay. There are so many uncertainties, and we don’t have enough people to face
these uncertainties.”
6.6.2 Communication
Internal communication is as important as external. The company seems pay a lot
of attentions on it. For instance, it has weekly meeting to allow department
managers and development team leader communicate with each other so as to
understand how to distribute human resource. Nevertheless, some risks still turn up,
and these risks also may influence system development progress as well.
84
6.6.2.1 Within Team
Communication within team seems have some problems and lead to risks, the DE
described:
“Each of us within the team responds for different parts, and everyone may have
more one project at the same time. Therefore, it is not common for us to
communicate with all other members, until there are some connections between the
modules we are doing. The most common situation is I just discuss with one or two
people and finish my work…we may discuss with team leader once a week, for
deciding what to this week and how we did in last week. Besides meetings, however,
we seldom communicate.”
It seems that there are not so many communications between team members,
which possibly cause misunderstanding of customer requirement in particular parts
and have different progress which leads to delay because of particular part. Besides,
lacking communication with team leader leads to indistinct understanding of current
situation of projects. For example, the DE said:
“Well, it is usually difficult to have a perfect plan at the first time. We will consider
in specific about what is going to be done, but some problems still occur then the
plan will be delay. But I don’t quite know how the plan is set, just follow the team
leader and the technical manager… I’m not quite sure about how long we delay,
around ten days, maybe? ”
6.6.2.2 Between Teams
Some risks rise from communication between teams as well. Although team
leaders meet weekly for discussing project progresses, when it comes to team
restructure in particular, risk can be found. The DL argued for this opinion and said:
“We have our own development platform within the company. Through using of
the platform, the difficulties of switch from project to project tend to be quite low.
Besides, we have already produced our core technology into ready-to-use modules
85
and products. We always develop customisation based on the root of our products.
Every project we have is based on our existing project, hence there is no worry on
familiarity, and our engineers seldom need to consider difficulties of this field.”
In contrast, the DE experiences many difficulties in team restructure:
“When I suddenly change to another project, I need some time to clarify how the
new project is progressing and what technology it is using. We don’t have meetings
to handover details in groups. To do this, I always need to communicate with team
members of the new project and handover documents I need. It is done in one to one
format. The platform our company have does help me to produce products quickly,
but it can’t help me on what have been developed base on this. Therefore, we need to
communicate about this part, and sometimes if I misunderstand some parts, then
later there will be some problems during programming.”
From the above, it can be found that managers and team members have different
attitude on internal communication, and managers seem have less regard on this
aspect. This kind of difference may also increase risks.
6.6.3 Technical Aspect
Whilst the company have had more than ten years experience on software
development, there seems to be little concern on technical aspect. However,
technology updates day by day and in some parts risks may still rise.
6.6.3.1 Technical Complexity
Risks may occur if customer requires for a system with high complexity. The DE
said:
“There is sometimes customer requires us to use the latest technology on the
86
system. However, some technology is quite complex and we may even never use that
before. We always prefer to use those technologies which can produce systems
efficiently, but we have to follow customer ’s requirement if he insist.”
The CEO also complained about this situation:
“Those systems our company have produced are all based on our own platform.
However, when customers require systems with high complexity, we have to consider
and try to persuade them. It is not only because sometimes their requirements have
already out of the contract range, but also high complexity means more bugs and
vulnerabilities. Products may have more and more bugs during system development,
and in the end we have to delete it and recreate a new one… When customers ask for
maintenance and update, they may require for adding new modules in latest
technology. We need to consider about the requirement carefully. If technical
complexity is low, we can sign a new contract with customers; if complexity is high,
we will persuade our customer reconsider his requirement in other technology, so as
to reduce any risks in using unfamiliar new technology.”
6.6.3.2 Knowledge and Experience
Different developers have different experiences in development. For those who
enter the company shortly, there may be some difficulties in programming. The CEO
talked about this:
“Before the final implementation, customers are always not so strict and care
about details, which may lead to unclear in details. So when we assign works to our
developers, they will consider their work based on their own work experiences. There
are about four to five developers in one team, those who have less experience tend to
have higher risk. There is no sign can be seen during programming, but problems will
occur during evaluation after two or three weeks, and it’s already too late to modify
small parts and that part has to delete and redo.”
The DE also experienced by his own:
87
“Sometimes I need to study for a new technology to finish project, and this will
cause time delay. Besides, because of unfamiliar to the technology, during
programming there will be more bugs and I have to take more time to check the
programme. Luckily, customer can understand this kind of time delay if they ask for
new technology; they may give us more time to study it.”
6.7 Discussions and Findings
After discussed about each theme, risks during each phase and aspects are
clarified. However, as thematic analysis can only have a list representing simple
categories, concept map is therefore needed to discuss relationship between
different themes. Multiple relationships are shown in section 6.3 and will be
discussed in this section based on former description of theme list.
6.7.1 In General: External Environment Decides Internal Management
Generally, external environment which surrounds the company impact its internal
management. In specific, environment decides how the company management
resources and projects, whilst Chinese cultures influences project management of
the company a lot ; Besides, requirement understanding level of customer can
increase or decrease technical complexity of the project.
From interviews, all interviewees emphasised how external environment increase
risks during daily system development. They consider external environment cause at
least 80% of all risks and have impacts on the rest 20% as well. What is more, some
interviewees (for instance, the DL and the MPD) consider risks from external
environment as unavoidable. It is therefore need to discuss about relationships
between external and internal.
88
6.7.1.1 Environment Decide Internal Management
Managers of the company always have to face influences from environment, even
if they are negative and full of risks. As discussed in pervious sections, the
background in China is not friendly to software development industry. Customers
consider software or system development as buy-and-go, and care little on how
system actually produces and how many costs it really need. This turns to be a quite
high risk, as lack of understanding and knowledge will lead to difficulties in
communications, and finally may cause system fail. Relationship between the
company and the customer relationship in personal have high impacts on
management method of the company, as the company have to pay much time to
build up this kind of relationship and maintain. These concerns may not even occur in
western industry, and this kind of intangible and unstable factors can cause high risks
on development fail. Besides, relationship within customer aspect makes their
project manager has no power to make decision, hence they have to delay the
project for waiting orders. The company therefore has to more team restructure and
resource schedule to use resources efficiently.
It can be seen from the concept map that culture also influence internal project
management. As discussed by the CEO, customers will usually not give sufficient time,
nor enough budgets. Project managers from customers have less consideration on
realistic, so it is sometimes impossible for the company to gain time for possible
delays and changes during system development. Therefore, the company has to
change its project management style to fit in this kind of culture, which including
decreasing human resources or ignoring standardisation in some cases. By doing this,
customer may consider this culture as a healthy one and keeps on doing in worse
way. This continuous vicious cycle not only increase risks more and more, but also
little by little make staffs of the company believe risks in this area are all avoidable
and accept them.
89
6.7.1.2 Requirement Understanding Decides Technical Complexity of Projects
Customers are wished to have nice requirement understanding on system
development process. Reason for it is requirement can decide what the company
should do during system development, and higher understanding level can reduce
time cost in every development stage. For example, if customer has better
understanding on what kinds of functions he need to have, it will reduce much time
during demand analysis and design stage. However, the reality is not so satisfied.
Customers usually judge technical complexity subjectively, instead of depending on
objective requirements and possible difficulties. It is why sometimes customers ask
for systems that is “the best in the next five to ten years”. They hardly consider about
how to maintain when they have a complex system, and little consider on the
vulnerabilities the system going to face. Lack of consideration on actual requirements
will finally turns to be increase of risks.
6.7.2 Within External Aspect
There are three sub-themes under this theme in theme list, and in concept map,
they have close connection with each other. Define external environment well can
easily understand how majority part of risks occur.
6.7.2.1 Environment, Culture and Relationship
In China, culture and relationship are both inescapable effects on system
development process. It can be considered as a special characteristic which is
different from the modern western software development industry. It is also obvious
that the unhealthy development of software development industry should be
criticised. Subjective judgement on project difficulties turns to unreasonable time
length; ignore on progress and simply noticing on results cause insufficient budget
and support. This kind of culture leads to adverse environment to the industry, and
90
also force the company find other ways to reduce risks besides of traditional way.
Based on this kind of background, relationship becomes more and more important.
Unlike formal business relationship, this kind of relationship builds base on some
kind of friendship between individuals within the company and its customer. If one
senior manager of the company and one in the customer company have good
“friendship”, the project plans and even contracts may be more reasonable. Another
kind of relationship is based on the job positions of two people. As discussed in
former sections, project manager within customer side always have no power to
make decision, or in some ways, he is afraid to make decisions. That is the reason for
why always projects delay, as the project manager may ask for permission from his
leader about every single webpage. It is because making decision himself means high
risks in losing job if he decided something opposite to desire from the director or his
leader. All these relationships have impacts on formal business relationship, and have
higher risks in losing this kind of relationship.
6.7.2.2 Communication with Customer isImportant
It is important to have good communication with customers, as this will influence
business relationship with customers, as well as attitude and requirement
understanding.
Although the individual relationship seems have great impact, the business
relationship still needs to be taken care. Business relationship builds upon attitude of
customer. For example, if customers consider the system progress has negative
influences on their future work (for instance, they may lose their job because of the
new system implementation), they will have bad attitudes. This kind of negative
attitudes can change business relationship between the company and customer. The
causality depends on common subjective desire on systems instead of objective
thoughts, of which customers seldom have. It is different from what western industry
91
acts. However, a similarity still exists by comparing western and Chinese customer,
which is the reliance on communication. Without appropriate communication, both
business relationship and attitude of customer can be reduced and risks of project
fail can be increased.
Besides association with business relationship, attitude of customer can also
influence the decisions and activities on maintenance and update. From interviews, it
can be seen that if customers have less care on their systems, they may have some
maintenance for every one or two years without considering any update. On the
other hand, if customers have more ideas and care on systems, there will be frequent
updates. Attitudes of customer decide the vulnerability of system, which also decide
the potential risks of system fail. Differences between customers reason from their
location, which additionally prove that environment can influence communication
with customer.
Besides of business relationship and attitude of customer, requirement
understanding and professional knowledge also have connections with
communication with customer. As mentioned in previous section, requirement
understanding has impact on internal project management. Within customer aspect,
it can be found that requirement understanding demands both good communication
and professional knowledge. Without knowledge on system development, project
manager from customer aspect cannot understand requirement appropriately, which
lead to insufficient project plan. It can also be figured out that communication
requires professional knowledge as support as well, or customer can hardly
understand what the system for, which may increase difficulties and time length on
understanding. Due to this reason, project management within customer aspect
need professional knowledge as well.
6.7.2.3 Internal Management in Customer Aspect as A Bridge
Whilst the company tries to avoid involvement in customer ’s internal details, there
are little information on how customers actually having their management. However,
92
through interviews, it can be seen that there are some relationships between
management in customer aspect and system development risks.
The CEO mentioned that the environment in China create unhealthy software
development industry, which forces the company to choose relevant management
method. Similarly, customers are also influenced by this environment, and their
management methods are result of these influences as well. On the other hand,
communication with customers need related management method to support.
Lacking effective management will cause inappropriate communication, and finally
cause fail project management in both sides
6.7.3 Contract and Its Relationship with External Environment and
Internal Management
Contract is quite special when consider about the company and its customers. In
general, contract is signed when buyer and seller have come to an agreement.
However, in buyer’s viewpoint, the contract contains what buyer wants to receive
after system development, and how buyer will evaluate the products. Therefore, it
can be said that the external aspect dominantly decides how the contract be.
There are three elements from customer aspect influence contract most in China:
requirement understanding, relationship and professional knowledge. There is no
doubt that requirement understanding can influence how the contract be, as it is the
dominant part to represent what system does the company want. Relationship tends
to be an interesting element, as it is not common in western industry. However, as
the MPD suggested, “If we have satisfied the people, we can then finish the project
in high efficiency.” With emphasis in several sections above, it can be clarified that
relationship has impact on contract setting. Professional knowledge is always
considered as support of reasonable contract.
93
Within contract, amount of budget and time length of whole project can cause
risks. If contract confirms sufficient budget, then the company can provide enough
human resource for the project, which also lead to smooth timetable of
development. In contrast, as the CEO suggested in interview, customers always
provide less budget than the project requires for because they think the company
may ask for more than they need to. In this situation, the project cannot receive
sufficient human resource, as that may cost more than benefit and even the same
time length as reasonable one may also be tight.
When consider about relationship between contract and internal aspect, it can be
said that contract decide how internal aspect be. Contract decides the way of
internal management, and requires internal management to coordinate with
contract so as to produce products. Moreover, contract decides what technology
going to use to produce system and how complexity the technology is. Technology
will then be used to implement the contract into real system.
6.7.4 Within Internal Aspect
During interviews, interviewees were more or less unwilling to admit shortages
and risks within internal aspect. However, as the CEO and the MPD pointed out,
around 20% risks occur from inside. It is emergent to clarify these risks, as they are
those risks can be controlled easily.
6.7.4.1 Management Turns to Be Central
From both interviews and thematic analysis, it can be found that management
turns to be the central of internal management. External environment influences
management, contract decides how the company manage its resources and having
project management. Within the company, communication requires good
94
management to follow, whilst knowledge and experience of staffs can cap the level of
management. As a result, how the management be taken out is extremely important.
Some risks rises directly from management, such as ignore standardisation when the
time length is in emergent; some risks rise in management because of lacking of
other parts, for instance, fail in evaluation of modules lead to recreating modules. All
risks within internal aspect need to consider about management influences.
Within management, project management is considered as the central of the
central. Similar to management in general, project management is influenced by
both external and internal respect. For example, as the DE mentioned,
communication between team members can be poor if project manager pays little
attention on it. Additionally, project management decides how teams be
restructured, and resource scheduling requires project management to support.
Project management should provide new plans for team members understand their
positions and works, especially time length on each project, so as to avoid any
confliction. Fail in project management will cause all elements relevant in high risk.
6.7.4.2 Technical Capability Limits Progress
Although technical capability seems has no negative impact on system
development progress, it does influences management method and can reduce
technical complexity if knowledge and experiences of staffs are sufficient.
Technical complexity of project depends on two sides. If customers have limit
understanding on requirement, or simply consider their requirements subjectively,
the complexity tends to be higher. During the mean time, because requirement
understanding can decide the contract as well, content of contract also may increase
or decrease the complexity of technology. From internal aspect, knowledge and
experience of development engineers have huge affects on technical complexity.
According to the interviews, some project delays are caused by unfamiliar with new
95
technology and developers need time to learn and then put into practice. Whilst the
period for learning new technology is short, some risks possibly rise because of these
technologies.
96
Chapter 7 Conclusion
7.1 Summary
This dissertation sets out to evaluate risk identification in system development
processes with reference to a company calls the Beijing Rewin Network Technology
Co., Ltd, a company producing securities systems for securities companies in China.
The research was initiated with providing a risk checklist when tended to be the
hypothesis of the research. It was considered not only as the risk checklist for this
case study, but also as a general checklist for system development process. Based on
Risk identification list from Pressman (1997), Han et al. (2006) and Cadle and Yeates
(2001), the checklist was predicted as cover all development processes. Besides,
literature reviews were also done in relevant domains. Literatures relate to
information system development and risk management were reviewed as well as
academic journals and books associated with Securities markets and securities
companies in China. Connections between these three areas were pointed out.
In order to identify risks more accurately, both thematic analysis and concept map
were used to indentify risks occur during different development stages and represent
relationships between categories. Interviews were used to collect qualitative data, in
order to gain results in real environment.
7.2 Discussion of Findings
The detailed findings relating to the risks identification of the company during its
system development process have been discussed in details in Results and Findings
chapter. The findings represent complex relationships between different categories
97
of risks within the company and highlight how those concepts influence each other.
Despite being extremely difficult to make conclusions from case study research,
some other issues have been raised and attract academic interests.
Environment of the company, especially the national culture has become one
dominant impact. Whilst China has extraordinary economic growth through these
years, the basic environment for emerging industries dose not update in the same
speed. Many managers are still using the planned economy within the
market-oriented economy background. This kind of disparity leads to unhealthy
development of software development industry. Software development companies
as the case study develops systems by using western model, whilst their customers
are still considering in traditional Chinese way.
Relationship is also an interest element for this case study. Importance of
relationships comes from courtesy, and has impacts in more areas than people
thought. Although customers would consider development capability of the company,
it is important as well or more to have good relationship with individual who is in
charge of projects.
Another aspect relates to attitudes of managers and staffs from the company.
During interviews, they all seem to have great understanding on risks, and the DL and
MPD believed the company has already have sufficient risk management. When the
researcher asked for whether the company have risk control plan, they all consider
plan as unnecessary, but prefer having risk identification and controlling during each
stage. Nevertheless, as soon as the researcher asked for more details about “risk
level” or “risk warning” they mentioned, they seemed have no actual idea on what
these concepts really for. Instead of understanding what risk management really is,
they only have some brief knowledge. The CEO has much more clearer concept on
risk management, and feels worry about the current risk management within his
company, but it seems that he can hardly do anything to change current situation.
The DE, on the other hand, seems have no idea about risk management but just
follow orders from managers.
98
7.3 Recommendation
Depends on what have been discussed, several recommendations can then be
made.
Firstly, although the company cannot change environment, it can change its
business pattern. Whilst it may cost a lot in customisation, the company can produce
more semi-finished products so as to reduce uncertainties. Another possible solution
for customisation is assign developers to customers’ company directly and receives
payment day by day by calculating amount of work. These two solutions both can
reduce risks due to customisation.
Secondly, the company should strictly follow standards it has built. Without
standardisation, system developments may have to depend on “luck”, and
trustworthiness from customers can easily be lost. Once accident occurs, it may take
many years for the company to rebuild its image. Awareness of standardisation
should be haven by every employee in the company, as it may cause problems as
well if low-level employees do not understand why standardisation should be
followed. Whilst these low-level employees are always those who communicate
customers most, they should have clear realisation on importance of
standardisations
Thirdly and the most importantly, managers of the company should build up
systematic understanding of risk management. Despite of unclear ideas or brief
definitions of risk management, managers should be aware of importance on having
structured risk management. By having discussion meeting on risk management or
having training, managers can have clearer concepts on risk management as well as
how they going to control risks.
99
7.4 Limitation of the Research
Some limitations do occur during this research. It is needed to clarify the shortage
of the research, so as to get rid of these problems in other researches and works in
future.
The knowledge limit of the researcher turns out to be one obvious limitation to
this research. Before having this dissertation topic, the researcher seldom has
knowledge about risk management. It is therefore hard for the researcher having
interview at the first time, because having interviews with software development
specialists requires relevant knowledge as support. The limitation could easily be
seen during interviews, as sometimes the researcher could not realise whether there
is any risk within one particular stage.
Another limitation is the language of interviews. When designing interview
questions, the English version was firstly produced and then was translated into
Chinese. Whilst interviews were all held in Chinese, the researcher had to translate
comments from interviewees into English and then analysed them. During these
translations, some comments may possibly be changed or different from original idea
due to insufficient level of English presentation. Therefore, there may also have a risk
that what the researcher commented in Results and Finding chapter were not what
interviewees want to talk about.
7.5 Further Research
Whilst this research concerns about risk identification within one particular
company, the further research can be done in two kinds of extension.
The first kind can concentrate on whole risk management cycle of the company. As
this research just focuses on risk identification, risk assessment, risk controlling and
risk monitoring have paid little attention. However, these three stages are all
extremely important during risk management. It is therefore can be one possible
100
research direction.
The second kind can concentrate not only on one company in this industry, but
also consider about other system development companies as well. Through this way,
whether this company is just a specific example or a common phenomenon on risk
management can be found.
(Words count: 24315)
101
Bibliography:
Alexander, C. (2000) Visions of risk. Pearson Education Limited: London
Atrill, P., & McLaney, E. (2004). Accounting and Finance for Non-specialists (4th ed.).
Harlow: Prentice Hall.
Avsion, D. & Fitzgerald, G. (2008). Information systems development: methodologies,
techniques & tools. Maidenhead: McGraw-Hill Education.
Avison, D. & Shah, H., (1997). The Information System Development Life Cycle : A First
Course in IS. McGraw Hill.
Beynon-Davies, P., (1993). Information Systems Development. Basingstoke:
MACMILLAN PRESS LTD.
Blake, D., (1990). Financial Market Analysis. Maidenhead: McGraw-Hill Education.
Boddy, D., Boonstra, A. & Kennedy, G. (2001) Managing information systems: an
organisational perspective: Financial Times. Prentice Hall: Harlow.
Boehm, B, B.W., (1989), Software Risk Management, IEEE Computer Society Press,
Los Alamitos, California
Brooks, C, P., Grouse, P. J., & Jeffery, D. R., (1982). Information Systems Design.
Prentice Hall.
Burke, R. (1999). Project Management: Planning & Control Techniques. 3rd Edition
Wiley
102
Cadle, J. & Yeates, D., (2001). Project Management for Information Systems. Essex :
Pearson Education Limited.
Chapman, C., & Ward, S. (1997). Project Risk Management: Processes, Techniques
and Insights. UK: John Wiley&Sons.
Deng, Y. (2005). Risk Management in company information project. Information
Science, 24(3), 78-83
Dey, L. (1993). Qualitative Data Analysis: a user-fiendly guide, Routledge.
Elaine, M. H. (2002). Risk Management. Beijing: Beijing Qinghai University publishing
company.
Flick, U., E. Vvon Kardorff, et al. (2004). A Companion to Qualitative Research. London,
Sage.
Flynn, D. J., (1992). Information Systems Requirements: Determination and Analysis.
Maidenhead: McGraw-Hill Education.
Frosdick, S. (1997) “The techniques of risk analysis are insufficient in themselves”
Disaster Prevention and Management, vol. 6, no. 3, pp. 165-177.
Haimes, J. H. (1998). Risk Modelling: Assessment and Management. USA: John
Wiley&Sons.
Higuera, R. P (1995) “Team risk management” Crosstalk: U.S. Department of Defence,
January 1995 pp. 2-4.
Hillson, D. (2001). Extending the risk process to manage opportunities. International
103
Journal of Project Management, 20 (3), pp. 235-240.
Howitt, D., & Cramer, D. (2008). Introduction to Research Methods in Psychology.
Pearson Higher Education.
Hughes, B., & Cotterell, M. (1999). Software Project Management. USA: McGraw Hill.
Jones, C. (1994) Assessment & Control of Software Risks. Prentice Hall, Englewood
Cliffs.
Jones, G. W. (1990) Software engineering. New York : Wiley.
King, N. (2004). Essential Guide to Qualitative Methods in Organizational Research.
London: Sage.
Kleim, R.L., & Ludin, I.S. (2000). Reducing Project Risks. Hampshire: Gower Publishing
Ltd.
Kohn, M. (2004). Financial Institutions and Markets. Oxford : Oxford University Press.
Krug, B. & Hendrischke, H., (2007). The Chinese Economy in the 21st Century:
Enterprise and Business Behaviour. Cheltenham: Edward Elgar Publishing Limited.
Laudon, K. C. & Laudon, J. P., (2004). Management Information Systems. New Jersey :
Pearson Education, Inc.
Lewin, M. D. (2002). Better Software Project Management. Sydney: John Wiley&Sons
Inc.
Lyytinen, K. (1988). Expectation failure concept and systems analysts: view of
104
information system failures: results of an exploratory study: North-Holland
Information and Management, 14, pp.45-56.
McGaughey, R. E. Jr., Snyder, C. A. & Carr, H. H.,(1994), Implementing
Information Technology for competitive advantage: risk management issues:
Information and Management 26, pp. 273-280
McNeill, P. (1990). Research Methods. London: Routledge.
Miles, M. Hurberman, M. (1994) Qualitative Data Analysis: an expanded sourcebook.
London, Beverley Hills.
Mishkin, F. S., (1995). Financial Markets, Institutions, and Money. New York :
HarperColins College Publishers.
Mobey, A. and Parker, D. (2002). Risk evaluation and its importance to project
implementation.: Work Study, 55 (4), pp. 202-206.
Mredith, J.R. (2000). Project Management: A Managerial Approach. New York:
Chichester: Wiley.
Neftci, S. N., (2007). China’s Financial Markets: An Insider’s Guide to How the Markets
Work. San Diego: Elsevier Academic Press.
Nunes, M. B. and Annansingh, F. (2000) The risk factor: IMIS, 12 (6), pp. 12-14.
Ould, M. (1999). Managing Software Quality and Business Risk. London: Wiley.
105
Peppard, J. (1993) IT strategy for business. London: Pitman.
Pilbeam, K., (2010) Finance and Financial Markets, Palgrave.
Rainer, R. K., & Turban, E. (2009). Introduction to Information Systems. Asia: John
Wiley&Sons (Asia) Pte Ltd..
Randon, J. (2011). Concept maps, involvement scheme and simulation: Tools to
improve skills for optimization of chromatographic separations. L, (350), pp. 35-40.
Redmill. F. (1991). Risk Management is for everyone, 1 (1) pp.58-60
Ritter, L. & Silber, W. & Udell, G., (1996). Principles of Money, Banking, and Financial
Markets. New York : Addison-Wesley.
Sallis et al. (1995) Software engineering: practice, management and improvement.
Addison-Wesley: Wokingham.
Sauer, C. (1993). Why Information System Fail: A Case Study Approach. Orchards:
Alfred Waller Ltd.
Saunders, M., Lewis, P., & Thornhill, A. (2007). Research methods for business
students (4. ed.). Harlow [u.a.: Financial Times Prentice Hall.
Su, D., 2003. Chinese Stock Markets: A Research Handbook. Danvers: Clearance
Center, Inc.
Tchankova, L. (2002). Risk identification-basic stage in Risk Management.
Environmental Management and Health, 12(3).
106
Thomsett, R. (1992) The Indiana Jones school of risk management: The American
Programmer, 5 (7), pp. 10-18.
Tong, X., 2005. Financial Services in China. Singapore: China Knowledge Press Private
Limited.
Trochim, W. (2006). Deductive and Inductive Thinking. [Online]. Retrieved May 20,
2011, from www.socialresearchmethods.net/kb.dedind.htm
Valdez, S., (1997). An Introduction to Global Financial Markets. Basingstoke:
PALGRAVE.
Ward, J. and Griffiths, P. (1996) Strategic planning for information systems. 3rd
ed.
Wiley: Chichester.
Weigers, K. (1998). Know your enemy: software risk management.: Software
Development Magazine,Oct.
Williams, JR., C. A., Smith, M. L., & Young, P. C. (1998). Risk Management and
Insurance. USA: The McGraw-Hill Companies.
Yin, R. K. (2003). Case study research: design and methods (3rd ed.). Thousand Oaks:
Sage Publications.
107
Appendix One: Risk Checklist
Contractual and Business Relationship Issues
Contract
- initial
- during and up to acceptance
- maintenance
Communication channels during and after development
Pre-project step:
Not enough funds and resources for the project
Lack of communication with customer before development, lead to functional
requirement not in details
Customer lacking in formal experience in information system
The contract is ill-defined or not agreed between the parties/ informal.
Lack of senior management support
Fail to consider existing systems when replacing systems
Fail to consider existing relationships when replacing systems
Unclear schedule/timetable and lack of milestones
Customer:
User requirement may suddenly change
Conflict between different departments
Internal political difficulties
Resistance to change and accept the new system
Lack of customer support
108
Developing system:
Ineffective use of developing methodologies
Unrealistic timetable/ budget
Lack of risk controlling plan
The develop team may not have sufficient knowledge to develop particular system
Team leader maybe new to development
Team member may have multiple development tasks at same time
Poor estimation of resources needed
Undefined project milestones
Technical aspect
Untested technology not previously used
Unfamiliar programming language to the developers
Unstable develop platform
New hardware/ software support
High technical complexity solution to implement
Other aspect
Develop team may require restructure during developing process
Restructure of develop company
Restructure of customer
Politics/regulations sudden change
109
Appendix Two Interview Questions scripts in English
Interview questions scripts
General Structure:
What is the organisational structure of the company? (CEO)
Which department develop information systems? (CEO)
Which department also involved in development? (CEO)
Structure of department:
How is the develop department structured? (CEO; manager)
What is your role within the department?
Who are other people working in the department and what are their roles?
110
Development in General:
Generally, how are most IS developed?
What kinds of methodology used?
Is there a standard methodology? What phases and stages included?
If not, what other methodology/stages and phases used?
What are individual roles?
How many people may involve?
What are their roles?
How are development monitored and controlled?
How team leader and managers involved?
Development in details
Pre-project:
How the develop team communicate with customer before actual development?
Who will be responsible to communicate with customer?
Who will be responsible to communicate with the team from customer aspect?
How the requirement be identified?
How budget and resources for the development be identified?
Any difficulties occur when communicate with customer?
111
Any confliction with customer about replace existing system/relationship?
Customer:
How customers cooperate with the team?
What kind of resource and support would customer support in realistic?
Any negative attitude from customer during development?
Developing system
How the develop plan be made?
How the roles of developers been set?
How the timetable be scheduled?
112
How well often the schedule and traditional requirements meet at last?
Do the team always have sufficient human resource to develop the system?
Any difficulties on meeting schedule/ milestones?
Does customer provide sufficient resources?
Technical aspect:
What kinds of programme language are used for development?
Is there any situation that a specific language required?
What kinds of software platform developers using?
What kind of hardware require for the systems?
Are requirements of SW and HW difficult to meet?
113
Other aspect:
Any need for restructure team during developing systems?
Why?
How the influences be minimised?
Any situation of restructuring develop company?
How the influences be minimised?
Any situation of restructure of customer?
How the influences be minimised?
114
Any Politics/regulations sudden change during development?
How the influences be minimised?
Risk Management:
Is there any risk controlling plan for development?
If yes, what is the plan?
If not, how will risk be controlled once occurred?
115
Appendix Three: Interview Questions Scripts In Chinese
总体构架:
这个公司的大概运营框架是怎样的？（CEO）
哪个部门主要负责开发系统？（CEO）
还有哪些部门参与了开发？（CEO）
部门构架:
这个开发部门的大概构架是怎样的？（CEO/Manager）
你在这个部门的角色是什么？
这个部门还有哪些人？
他们的角色是什么？
大致开发过程:
总体来说，一般系统是如何被开发出来的？
是否有一个标准的开发理论/流程呢？包括哪些阶段与步骤？
如果没有，开发时会使用哪些理论/流程？
个人的角色是怎样的？
大概会有多少人参与系统开发？
他们都扮演什么角色？
系统开发（过程）是如何被管理与控制的？
项目 leader 与（部门/公司）管理人员是如何参与的？
具体开发过程：
在实际开发前，开发团队如何与客户进行沟通？
客户要求是如何被定义的？
开发所需费用以及资源是如何被定义的？
与客户沟通时是否会出现困难？
客户方：
客户是如何配合开发团队进行开发的？
客户是否有对开发团队提供实际协助（negative）？
116
开发系统：
开发计划是如何制定的？
开发计划是否能最终按时及按要求完成？
开发时是否会遇到一些困难/阻碍？
开发系统（技术方面）:
系统开发时一般会选择什么编程语言进行开发？Java
是否会遇到需要某种指定语言进行开发的情况？
开发人员会使用什么软件平台及硬件环境进行编程？
其他方面:
是否有在开发系统过程中遭遇团队临时重组/换人/个人角色变换的情况？
是否有遇到开发期间大政策/法规变动（以至于影响开发）的情况？
风险管理：
（公司）是否有针对系统开发过程的风险控制计划？
如果有，请描述。
如果没有，当遇到风险时，开发团队是如何规避以及控制风险的？
117
Appendix Four: Consent Form
(The consent form was designed in Chinese)
采访内容介绍以及隐私保护声明
采访人：黄樱 (Ying Huang)
来自：University of Sheffield, Msc in Information System Management, UK
预估采访时间：约每人 1 小时
期望被采访对象：公司 CEO，开发部门经理，开发人员 1-2 人（项目 leader）
导师：Miguel Baptista Nunes, Leader of Information System Management
内容概述
本采访为毕业设计《Assessment of Risk Management within Securities Companies
Oriented Systems Development Company: The Case Study of Beijing Rewin Network
Technology Co., Ltd》的数据收集环节。本毕业设计主要研究证券公司的各类交易
系统开发过程中，开发公司或开发团队可能遇到的风险以及相应的风险管理措施。
根据风险管理的四大步骤，本设计主要关注风险定义方面，即关注在系统开发的
各个阶段可能遇到的风险的定义。
本毕设前期会根据文献罗列出系统开发可能遇到的风险列表，在实际采访过程
中会针对这些风险进行采访，并询问与风险相关的系统开发概况。
隐私保护
根据 University of Sheffield 研究隐私保护条例，本设计道德风险属于低水平范围。
118
在进行采访时，将不会透露一切被采访人的私人信息，只会记录被访人在公司
所处职位等与设计相关内容。
采访问题会事先发给被访人，如有牵涉到公司隐私内容，采访问题可被取消。
所有采访采取自愿原则，被访人有权拒绝回答任何问题，采访人不可强制要求
被访人参与采访。
采访时可能会根据被访人回答随机增加个别问题以收集资料。
为便于后期数据整理分析，采访语音会被录制保存。
所有收集到的数据资料仅会为本毕业设计所使用，不会用于任何商业用途。
（保护条例详情请参考 http://www.shef.ac.uk/ris/other/gov-ethics/researchethics/）