Information and Software Technology 68 (2015) 34–44

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier.com/locate/infsof

The roots of executive information system development risks

Chia-Ping Yu a,1, Houn-Gee Chen b,∗, Gary Klein c,2, Randi Jiang d
a
Department of Information Management, Tamkang University, No. 151, Yingjhuan Rd., Tamsui, New Taipei 25137, Taiwan
b
Department of Management, National Taiwan University, No. 85, Sec 4 Roosevelt Road, Taipei 10617, Taiwan
c
College of Business and Administration, University of Colorado at Colorado Springs, Colorado Springs, CO 80933-7150, 1420 Austin Bluffs Parkway, Colorado
Springs, CO 80918, USA
d
Department of Accounting, College of Business, Florida State University, Tallahassee, FL 32306 600 W. College Avenue, Tallahassee, FL 32306, USA

a r t i c l e i n f o a b s t r a c t

Article history: Context: Executive information systems (EIS) are valuable tools that enable executives to formulate and exe-
Received 11 February 2015 cute strategic decisions in their organizations. However, implementation of an EIS is complex and laden with
Revised 6 August 2015
numerous risks.
Accepted 7 August 2015
Available online 28 August 2015 Objective: We apply the socio-technical model (STM) to propose a framework of risks for the development and
implementation of an EIS. Such a framework may serve to guide risk management strategies and procedures
Keywords: beyond current practices.
Executive information systems
Project management Method: To assess, and better understand, the risks associated with implementing an EIS, interviews were
Software development conducted with the employees of three principle stakeholders of a taxation EIS. The interviews centered
Risk on the detailed experiences of the participants applying and working with EIS projects at their respective
Socio-technical model organizations.
Results: Content analysis of the interviews confirmed an ability to designate risks to both the project and
the product of development through dimensions of task, actor, structure and technology as well as the fit
between each combination. The result adds credence to the model for purposes of risk management in the
development of an EIS.
Conclusion: Executive information systems play an integral role in business decision making. The successful
construction and implementation of an EIS are reliant upon a clear understanding of the appropriate tech-
nology to be used, the end-user accessing the system, and the tasks executed. The STM is a useful tool for
the identification of risks in the creation of an EIS. Further work should consider the extendability to other
systems and its compatibility with development approaches.
© 2015 Elsevier B.V. All rights reserved.

1. Introduction tions and environments including transaction data, financial informa-

Executive information systems (EIS) are flexible tools that provide
broad and deep information such as news, regulations, and compet-
itive analysis for use in executive decision making [1–3]. These sys-
tems were created to address the needs of executives and support
strategic decision making through scanning, analysis, and interpre-
tation functions that continue to expand in their power and scope
[3,4]. An EIS supports users, who perform highly unstructured work,
and processes information from a myriad of sources about organiza-
∗
Corresponding author. Tel.: +886 2 3366 9653; fax: +886 2 3366 9654.
E-mail addresses: cpyu@mail.tku.edu.tw (C.-P. Yu), hgchen@ntu.edu.tw (H.-G.
Chen), gklein@uccs.edu (G. Klein), rjiang05@gmail.com (R. Jiang).
1
Tel.: +886 2 26215656x3511; fax: +886 2 26209737.
2
Tel.: +719 255 3157; fax: +719 255 3494.
tion, online analytical data, external news services, and market trends
[5,6]. For decision makers, the EIS provides valuable information to
help stimulate creative solutions, manage functions, control opera-
tions, and monitor environmental trends as they think about plan-
ning and strategizing [7]. Thus, the core processes of an EIS provide
flexible and easy-to-use tools that add breadth, depth, and a variety
of information for executive decisions.
Organizations often receive significant benefits from EIS imple-
mentations; however, the complexity of EIS implementations yield
high-risk projects [8]. Multiple sources of internal and external data,
the incorporation of decision models, the inclusion of on-demand
modeling and data acquisition, varying decision styles, and man-
agement levels of the users are among the factors that make the
development of an EIS a risky proposition. Yet, in a risk management
framework, the identification of risks early in the development

http://dx.doi.org/10.1016/j.infsof.2015.08.001
0950-5849/© 2015 Elsevier B.V. All rights reserved.
 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
process is crucial to an effective risk management strategy [3,9,10].
Failure to recognize the risks in the development of a system or the
exaggeration of risks often interfere in the effective management of
risks [11,12]. Thus, it is natural that we ask the question: Can we do a
better job of identifying risks in the development of an EIS? It is not
enough to understand the presence and consequences of risk, which
is the focus of most studies, we also must understand the root cause
of risks in order to plan for risks and intervene in their occurrence to
best achieve success.
Extensive literature exists concerning risk in systems develop-
ment from the perspective of identification and control [10,12–14].
Some studies generate risk lists to help developers identify and con-
trol risks [9,12]. Others work to categorize risks in a fashion that
allows for more of an analytical approach to designing risk man-
agement procedures [13,15]. Within these approaches, prior stud-
ies identify structural, actor, task, and technical risk factors such as
user involvement, executive support, appropriate and flexible hard-
ware and software, adequate resources, and well-defined require-
ments [2,13,14]. For better risk management, EIS project managers
must equally consider the social, cultural, organizational, and tech-
nical factors [16]. Although prior studies provide useful insights into
key risks found in EIS development, the origins of risk are not gener-
ally considered. In particular, risk studies tend to ignore the complex
relationships in the development of even basic software, much less a
complex EIS, resulting in a shallow description of risks rather than a
deep examination of root causes [12,14,16].
One key may be in the level considered by prior studies. Of-
ten, the system or project level is the focus of study. A higher
perspective must be considered that is pointed to by a number of
research streams including socio-technical models (STM), conso-
nance, and Task-Technology Fit (TTF) theory [15,17,18]. In brief, the
socio-technical model indicates that systems will often ignore effects
on the people and structure of an organization when dealing with
tasks and technology. Consonance argues that perceptual differences
between multiple stakeholders lead to conditions resulting in failure.
More narrowly, TTF suggests that a root risk to success is the match
of the capability of the technology to the demand of the tasks in the
work environment. Each argues for an alignment – an alignment of
the technical to the social, an alignment of stakeholder understand-
ing, and an alignment of technology to best accomplish a given task.
In a successful EIS development, the tasks are unique for a system
requiring care in the alignment of the technology. User needs are nar-
rowly focused, but must be fully understood by developers to deliver
an effective system product. The technology dimension must not hide
changes required to the decision-making structure of the executives.
For our study, we focus on these more global perspectives to ex-
plore risks in an EIS development and deployment project to deter-
mine if there is a better way to identify risks in the development of
an EIS and perhaps other complex systems as well. Specifically, does
the broad socio-technical model viewed in the light of consonance
and Task-Technology Fit emerge in the development of a major EIS?
Our concern is to be able to identify risks based on how they emerge.
We identify a major EIS implementation to serve as our case, target
key informants across several organizations, and conduct deep inter-
views. The interview data indicates that risks arise from failures to
match across all dimensions of the socio-technical framework, pro-
viding directions for further research and a better view for practition-
ers looking to determine risks earlier in the development process.
2. Background and propositions
In a strategic context, increasing emphasis has been placed
on understanding the link between what information executives
possess that might bear on future performance to how they develop
long-term strategies about future opportunities and threats. In this
scenario, getting essential information to the executives is a core
35
competency of winning organizations [19,20]. Therefore, the EIS
becomes the core system (technology) to provide executive man-
agement (actors) strategically significant information (structure) to
support strategic decision making (task), to update an executive’s
knowledge, and to challenge long-held viewpoints and assumptions.
As organizations developed software for executives, their ill-defined
tasks made it necessary to gather, explicate and understand internal
and external information. Wide-ranging strategic information is a
convergence of knowledge management, business intelligence (BI)
and competitive intelligence [21,22]. Indeed, the EIS should permit
awareness of environmental trends and the ability to monitor im-
portant indicators [23]. Embedding features to allow environmental
scanning and delineation of external information is essential to aid
executive efforts in planning strategies and anticipating changes
[1,23]. Scorecard and dashboards in BI systems report key perfor-
mance indicators, draw from diverse data warehouses, use advanced
data mining and semantic search technologies to access valuable
information on customers, competitors, and the environment at
large. The increased data access and manipulation abilities help
search for valuable information, build complex analytical models,
and evaluate multiple strategies [23]. The complexity of multiple
data sources, inter-organizational applications, sophisticated deci-
sion models, uncertain task structures, and output versatility make
the development of an EIS a risky project.
Several innovative development approaches recognize the impor-
tance of considering further relevant aspects of the system, such as
including more actors and a larger perspective on the environment
[24,25]. Such methods typically begin with a sound analysis of or-
ganizational goals to drive an analysis that considers requirements
defined through communications between developers and poten-
tial users, an emphasis on analytical and decision models under re-
source constraints, requirements shaped by software capabilities, and
achieving an agreeable basis for continued development [25–27]. Ex-
amples of such methodologies include KAOS and i∗ which identify
and document stakeholders’ global goals in a form that can best be
analyzed, communicated, and subsequently implemented or operate
earlier in the software development process to best work with actor
needs [24,25]. Methods that serve to identify a larger set of system
aspects promote awareness of the greater breadth and greater under-
standing of all potential risks [26,27].
Risks can be any condition that will lead to the failure of a project
during development, create errors in the output of a project, or pro-
duce a system with no value. Risk is often measured as a potential
variance from expectations, such as a large cost overrun or delayed
delivery of the system. Certain risks can be anticipated and miti-
gated early in the development process, others must be addressed
as they occur, and still others are never identified because they were
not anticipated or realized. Regardless, potential risks must be recog-
nized and managed to achieve success in an IS project [9,28]. Project
managers must assess risks to design controls that detect and re-
spond to a risk event, mitigate the impact, or lessen the probability
[10,29]. However, the identification of risks is not a straightforward
task [11,12]. It is crucial to gain an understanding of how risks can be
identified and how they can change over the course of development.
Simple lists in the literature of textbooks and trade books do not pro-
vide sufficient malleability or specificity to be of value in a breadth of
settings and times [30–32]. Analysis approaches allow for the design
of controls for broad categories of risk [30]. While the focus of the lit-
erature allows for planning steps to analyze and control risks it is not
sufficient to prepare for an early intervention.
EIS projects fail due to many risks common to most systems as
well as those unique to the system type: inappropriate communi-
cation, lack of skilled actors, unclear task definitions, and complex
technologies [3,11,21,22]. All of these are represented in the socio-
technical model of system risks which could potentially help man-
agers anticipate project risks and increase the likelihood of success
36 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
Social Technical
environment environment
Actors Tasks
Structure Technology
Fig. 1. Socio-technical view of risks.
[33,34]. The socio-technical model considers risks to be in dimen-
sions of tasks performed, actors involved, technology implemented,
and structural relationships as shown in Fig. 1. On the social side,
failures are due to the risks associated with mismanagement of qual-
ifications, lack of user participation, inappropriate skills actors, actor
turnover, political conflicts and power plays, poor communication of
goals, inappropriate workflow, inefficient governance structure, and
a lack of executive support [11]. Technological risks consider the nov-
elty of the application and infrastructure, a diversity of data and data
structures, poorly defined processes, and limitations of anticipated
future needs [3]. Other studies indicate that risk can be the result
of interactions among the four dimensions. Unskilled actors cannot
handle required technology [6]. Matching actors to the tasks is impor-
tant. Otherwise users will resist the new system, and requirements
will not be well understood [34]. However, these studies are limited
and do not provide a complete picture that the number of potential
relationships in Fig. 1 would indicate.
The socio-technical model allows for a greater range of perspec-
tives on risk than considered in the literature [35]. The component
“actors” should represent any group or individual who can affect or
is affected by the achievement of an activity’s purpose [36]. Accord-
ingly, previous studies indicate an important critical success factor
for project success is top management support of the participant’s in-
volvement in the software development to include customers, project
managers, developers, and users [16,28]. EIS users can often not be
able to provide a clear definition of information choice or presenta-
tion because needs vary greatly among the unstructured, non-routine
problems. Moreover, project managers and developers often limit
their options with the choice of development and project manage-
ment methodologies.
“Tasks” constitute the actions a user will take based on business
needs. For software, the tasks are the application goals, making an
understanding of requirements critical [15]. Users of an EIS constantly
address many varied and unpredictable questions of high ambiguity,
making the tasks quite complex. Risks associated with understanding
requirements are very problematic and elevate as does the complex-
ity of the tasks [37]. For example, to face unstructured problems, the
EIS project managers have difficulty identifying the system’s appro-
priate scope due to task uncertainty and complexity.
“Structure” includes authority relations, coordination mecha-
nisms, the degree of centralization, job design, or similar structural
variables [36]. These are also variables in software design and de-
velopment [33]. In the strategic context of an EIS the communica-
tion structures facilitate exploring, acquiring, distributing, and uti-
lizing internal and external factors [11]. Because EIS projects involve
interwoven business processes the structural risks are complex and
numerous [6]. At the same time, the project manager must manage
risks of inappropriately defined responsibilities and coordination.
Lastly, the “technology” component encompasses the way work
is performed or the methods and equipment that are used [36]. For
software development, the technology could be considered as the
methods, tools, and infrastructure used to develop and implement
the software system. Thus, the technology component constrains
how work is performed. Unproven or unfamiliar technologies may
cause disappointment and lead to under performance or conflicts
with unrealistic expectations [8]. To respond adequately, an EIS com-
bines flexible interaction and powerful analytical technologies [38].
Thus, EIS project managers need to consider pitfalls of technology,
such as unproved technology, technological complexity, or simply
poor interfaces. This usually requires complex computer hardware
and software, diverse and broad data, along with new technology
and specific methodologies [3,23]. So it is evident that an EIS should
be characterized by risks from each category, leading to:
Proposition 1. Actor, structure, technology, and task risks will be ob-
served in an EIS development project.
This simple view serves as a baseline to establish the study align-
ment with prior results. However, the IS development and deploy-
ment process is an orchestration of the different dimensions, indicat-
ing that the relationship between each of the four components might
play a more substantial role [13,20]. This is made evident in the expo-
sition of task-technology fit (TTF) [18]. TTF provides a theoretical basis
to guide the user and organization, assessing their information sys-
tems or services. In the TTF model, technologies are viewed as tools
(hardware, software, and data) to provide services and to assist users
in their tasks. Tasks are the actions carried out by individuals. The
assumption of the TTF model is that information systems add value,
and there is a significant relationship between performance impact
and a correspondence between task and technology. In other words,
the TTF model focuses on the impacts of a specific system and it views
technology as a means to complete goal-oriented tasks. Therefore, the
TTF model serves to link two dimensions of the socio-technical model
more tightly than prior research. The fit is achieved in a design pro-
cess aimed at the joint optimization of the task needs and technology
characteristics. Failure to fit task and technology can create variances
and errors, hence risk.
If taken as a whole, the socio-technical view promotes the sys-
tem development process as the interaction and alignment of all four
components. An information system can maximize its performance
only if the social and technical subsystems (i.e., actor, structure, task,
and technology) work in harmony [17,35]. As a result, risks should
be seen as the consequence of failure to consider all associated as-
pects of the ecosystem [17]. An information system can maximize
its performance only if the social and technical subsystems all work
in harmony, while the reverse creates variance and potential errors,
or once again, risk. Therefore, risk management of the system de-
velopment life cycle must deal with risks created through a failure
to match across and within dimensions. Thus, we consider a general
proposition:
Proposition 2. One major risk for an EIS project would be a lack of fit
between actors, tasks, structure, and technology.
To consider specifics, the EIS is a complex system with ill-defined
tasks. A large number of EIS project failures and abandonment fac-
tors relate to an unqualified project manager or user uncertainty with
tasks [11]. During development, executives have little time to spend
with analysts, analysts do not understand the characteristics of the
executives’ work, and executives find it is difficult to specify their re-
quirements for non-routine tasks. This makes it difficult to deliver the
correct task capability to the executive users, resulting in continuous
change and deficient systems [8,29]. Involvement in the development
by managers, not familiar with the tasks, can also lead to uncertainty
and failure to deliver essential support [11]. Therefore, the first de-
tailed proposition is:
 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
Proposition 2a. A risk for an EIS project would be a lack of fit between
actors and tasks.
With EIS systems becoming larger and involving multiple stake-
holders from within and outside of organizations, the complexities
of the communication structure among the variety of stakeholders
and within the development project have escalated significantly [12].
The diversity of requirements among the various executive users of
the system presents structural issues in implementation. Authority
structures can influence the direction of design elements that may
not be most appropriate for all users. Conflict management processes
might not be established to resolve differences [39]. Structural set-
tings might limit access to essential information to certain users. For
example, project managers may adjust the systems of communica-
tion to reduce conflict. These represent situations of structure failing
to fit the needs of the actors, or:
Proposition 2b. A risk for an EIS project would be a lack of fit between
actors and structure.
To manage change, software engineering works to initially iden-
tify technical execution risk factors such as IT personnel skills, techni-
cal complexity, interface flexibility, and user resistance [28]. Watson
and Frolick [1] show that unproven or unfamiliar technologies may
cause disappointment and lead to under-performance or conflict due
to unrealistic expectations. The risk of not providing technology to
the capability of the actor is evident in a lack of use and greater re-
sistance to change [38]. Thus, complex technology solutions are often
difficult for executives to handle when user resistance and training is
key [3]. In this case:
Proposition 2c. A risk for an EIS project would be a lack of fit between
actors and the technology.
To consider task to structure risks in an EIS project, tasks may
change greatly altering the lines of communication and flow of infor-
mation incompatible with extant formal structures within an organi-
zation. These can endanger the success of an EIS if the organization is
not willing to alter formal structures as needed to improve the capa-
bilities inherent in the EIS [17]. Partnerships within an organization
should align with the enabled tasks to best achieve task goals [20].
Ambiguous tasks, potentially brought about by a new system, may
change a business process or workflow resulting in a task that fails to
meet the structure within an organization. Therefore, we consider:
Proposition 2d. A risk for an EIS project would be a lack of fit between
task and structure.
As task uncertainty increases, so does the variety, complexity, and
ambiguity of executive information. The fit between technologies and
the business task has a heavy impact on system success [20]. For an
EIS, a flexible technology that best fits the non-routine task should
prove to be the better system [18,20,40]. The technology must fit the
task requirements in a successful system to deal with the uncertainty
of business challenges and problems [6,38]. Hence, to deal with con-
tinuously changing requirements and uncertain tasks, adopting more
complex technology to access information from diverse sources will
be necessarily. TTF theory and the above discussion leads to:
Proposition 2e. A risk for an EIS project would be a lack of fit between
task and technology.
Work on consonance shows that the perceptions of multiple
stakeholders must be in agreement about the technology, or the
project will be less successful [31,38]. Communication, negotiation,
and conflict management structures, within an organization, can in-
fluence design requirements for the technology, but are often not
aligned with the software product [19]. This is especially so with in-
creasing complexity such as EIS projects. It is difficult for technical
staff on an EIS project to integrate various new and old technologies
37
with the varied sources of data across multiple organizational and
environments. Thus, we propose:
Proposition 2f. A risk for an EIS project would be a lack of fit between
technology and structure.
3. Research methodology
3.1. Research design
To address the issue of risk incidence by EIS project, we conducted
interviews with key project participants and content analysis to iden-
tify risk occurrences. The interviews centered on the detailed experi-
ences of the participants to explore the risks of EIS projects through
the development process in depth [41]. The content analysis utilized
both qualitative and quantitative operations to assess risks during dif-
ferent phases of the development project. Content analysis requires
exposing differences in content themes, coding answers to open-
ended questions in the interviews, identifying the intended meanings
of the participants, revealing the focus of the participants’ responses,
and describing trends in content [42].
3.2. Sampling
According to Cooper and Schindler [41], there are two primary cri-
teria for securing a sample: relevance and frame. Relevance means
that the population must be appropriate for the research objectives,
which for us is to explore the risks in EIS development projects. In
this study, the EIS project case is the “Program of the Reform of the
Taxation Information System (PRTS),” and the total funding is over
3 billion NT dollars. From a high-level perspective, this EIS provides
services to the taxation and financial departments of the Republic
of China. The end-users will use this system to evaluate the service
quality about agency taxation operations, to identify the strength and
weakness of the organization, and to suggest changes and make pol-
icy. Therefore, this EIS project assists in executive work with the po-
tential to make a great impact on government affairs of taxation and
finance. This intent establishes the relevance of the system case to the
domain of EIS.
The origin of the project is due to new taxation regulations and
updates over the years. New tools were developed and deployed to
support various actors within the government agency in their newly
designed tasks. An existing system had grown from a taxpayer trans-
action system by adding additional taxation modules including a gift
tax, amusement tax, and land value increment tax, among others.
Under such an IS landscape, users made an effort to pool all the
tax sources together for better decision support. The processes ran
across different data files and hardware platforms. There were no uni-
fied tools to support the decision-making process. To assist revenue
management and enable financial stimulation of national economic
growth, a supporting EIS was proposed.
The structure included the following agencies under the Ministry
of Finance (MOF): (1) The National Taxation Bureau with a total of five
offices. These are the major revenue service offices that handle tax
collection and represent key users of the EIS. (2) The Fiscal Informa-
tion Agency, which is the IT department that serves the MIS need for
the entire MOF, handles IS system development and maintenance. (3)
The Taxation Administration Office, which is the planning and policy
evaluation office of MOF, are the other key users of EIS. The Minister
of Finance supervises each office. Existing technology from past prac-
tices and experience included ad hoc tools and approaches used in
navigating across different data sources to identify misconduct and
loopholes in the tax filing process. The actors were users at the dif-
ferent governance agencies, each with a set of goals and priorities.
For example, the people from the Information Agency are more con-
cerned about information security and sensibility while users from
38 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44

Table 1
Demographics and responsibilities of interviewees to date.
Case Organization Roles Gender Job experience
(Years)
A CHT Project Manager Male 13
B FDC System Analyst Female 7 25–30
C Male 25
D NTA Coordinator Male 15
E Male 18
F Female 20
G Female 25
H Male 25
I End-user Male 15
J Female 18
K Female 25
L Female 20
M Female 22
the National Taxation Bureau focus more on tax collection. Differ-
ences in perspectives and roles result in wide task variety plus emerg-
ing technology added new challenges. For example, a recent e-receipt
project undertook new validation and verification requirements.
Research frame means that the chosen samples must be represen-
tative of the population. In our study, the large volume of data comes
from multiple departments (e.g. five tax administrations, hundreds
household registration offices and customhouses), the analytics tools
are complex, the reports are various, and the executives depend on
the EIS to manage and control their organization. The subjects chosen
are from multiple agencies including the NTA (National Tax Adminis-
tration), FDC (Financial Data Center), and CHT (Chunghwa Telecom).
All three are key stakeholders in the EIS project: the NTA is respon-
sible for the routine work of the Taiwan state tax system with their
executives being end-users of the EIS; the FDC is the project man-
agement team responsible for design and deployment of the system;
and CHT is the vendor responsible for development. We base this
study on the events and circumstances of the participant’s experi-
ences. Thus, chosen participants worked different roles in the project.
Project managers, senior programmers, as well as managers within
the NTA, FDC and CHT are all in good position to respond to interview
questions dealing with this EIS development project because their
work involves tasks from multiple stages. Overviews of the partici-
pants are in Table 1.
3.3. Interviews
the study to the participants while the other researchers assumed re-
sponsibility for recording the responses and ensuring all questions
Age were asked and answered. Each interview was conducted individu-
ally in Chinese. The interviews were tape recorded and later tran-
40–45
scribed for future coding and analysis. Notes were taken during all
of the interviews. Participants were encouraged to judge the impor-
50–55 tant issues based on the context they were working in. Moreover, the
40–45 researcher summarized the interview data for the interviewee to en-
50–55
sure a common understanding. The interview sessions each lasted
50–55
50–55 about one hour.
50–55
40–45 3.4. Content analysis
45–50
50–55
45–50 Content analysis includes several steps: (1) define the recording
45–50 units; (2) define the categories; (3) test the coding on the text sam-
ple; (4) assess accuracy and reliability; (5) revise the coding rules;
(6) repeat steps (3) through (5) until the reliability is acceptable; (7)
code the text; and (8) assess the achieved reliability/accuracy. Con-
tent analysis can reflect team interaction patterns, reveal the focus
of individual, team, institutional, or societal attention, and disclose
the relationship between intent and content [43,44]. Training data
was randomly selected from interview cases. Two graduate students
served as coders and were supervised by a lead researcher. The grad-
uate students majored in information management and were trained
to ensure adequate coding skill and reliability. The lead researcher
conducted training until the reproducibility of the results from the
two coders exceeded 90% [44].
The comments of project participants are rich in description of
the EIS project context and states and provide useful data reveal-
ing the risk issues from different perspectives. Therefore, we rely on
content analysis to identify the risk characteristics. The process of
content analysis followed the steps of Neuendorf [42]. Themes are
first chosen for a unit of analysis. A theme is a unit of text with no
more than one perceiver, one action agent, one action, and one ac-
tion target. Long or complex sentences were segmented into themes.
Next, a coding scheme was defined based on the four components
of the socio-technical model. The coding scheme was conducted as
proposed by Leavitt [36] and includes (1) task, (2) structure, (3) ac-
tor, and (4) technology [33,36]. Each identified theme was assigned
to a code category. Table 2 provides the basic structure of the cod-
ing scheme. The researchers conducted a content analysis of a sam-
ple from the full data set and made minor adjustments to the rules
assigning themes to coding categories.

A team of five or six researchers conducted the interviews fol-
lowing a predefined framework for the recently completed project.
The case study protocol is in the appendix and considers questions
about the organization, stakeholders, and tasks. Follow up questions
delved into specific issues identified by the preliminary questions.
Researchers administered the interviews at a prearranged time. At
each interview, one researcher explained the nature and purpose of
3.5. Reliability and validity
To consider the quality of this study, we evaluated face validity,
semantic validity, and reproducibility. Face validity is the extent to
which the measure, “on the face of things,” appears to tap the de-
sired concept [42]. To assess face validity, researchers were requested
to take a step back and examine each concept objectively. Validity

Table 2
Socio-technical risk categories.

Category Themes Example phrases

Structure Structure themes focused on authority relations, coordination
mechanisms, and the degree of centralization, job design, rewards, and
other structural variables.
Actor Actor themes represented any group or individual who can affect or is
affected by the achievement of a project’s purpose, such as actor
shortfalls.
Task Task themes characterized a project’s raison d’être, including results,
products, approaches, and goals of the software project.
Technology Technology themes related the way the project is performed through
methods, tools, and equipment - including the infrastructure used to
develop and implement the software system.
Inefficient communication, poor communication system, lack of
communication channels, poorly defined responsibilities, inappropriate
rewards, inefficient governance structure, unrealistic schedules
Short of personnel, turnover, unwilling, ethical problems, poor or
inappropriate skills/experience, political conflict, power plays
number of participants or users, task ambiguity, wrong functions,
continuous change, requirement determination
technical interfaces, defects, new/untried technology, maintainability,
extendibility
 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
Table 3
Quality attributes of case studies.
Case Study attributes
Area 1: Research design
Case research questions
A priori specification of constructs
Clean Theoretical state
Theory of interest, predictions from the theory and
rival theories
Nature of single-case design and replication logic in
multiple-case design
Unit of analysis
Context of the case study
Team-based research and different roles for multiple
investigators
Area 2: Data collection
Elucidation of the data collection process
Multiple data collection methods and mix of
qualitative and quantitative data
Data triangulation
Case study protocol and case study database
Area 3: Data analysis
Coding
Logical chain of evidence
Mode of analysis
Use of natural controls
Quotes
Project review
is reached when the researchers all agreed that the data detailed
the desired concepts. For example, in this study both coders agreed
that only the set of key terms (actor turnover, poor or inappropriate
skills, and political conflicts) could be used to represent the concept
of actor risk. For the grouping to have semantic validity, it is required
that coding units possess similar connotations [42]. In this study, the
coders had experience in system development and were familiar with
the risk management process. Semantic validity was achieved when
coders agreed that grouped words had similar meanings or connota-
tions [43]. Reproducibility is the extent to which content classifica-
tion produces the same results among multiple coders. In this study,
comparison of the coding results showed a similarity of 90.2%, in-
dicating an acceptable level [42]. We summarized the attributes in
Table 3 according to common practices [45].
4. Testing the propositions
In this section, we first describe our findings on the four within-
category risks in consideration of Proposition 1. Table 4 summarizes
the most frequently indicated risks for each stakeholder category in-
terviewed. To begin, the end-users considered inappropriate work-
flow, poor physical arrangements, and procedural changes as key
structural risks. The IT staff thought a lack of communication and
governance structure would present risk, and these were addressed
through established guidelines. For example, the project manager
indicated:
“Normally, there’s one regular team to state the more important is-
sues in the meetings, they arrange meetings and make final decisions.
The director-generals and undersecretaries assure representation …
[important] since we all work in different divisions. I’m in the busi-
39
In this case study
Area 1: Research design
The research question of this study is to investigate the EIS risk management.
The socio-technology theory and task-technology fit theory define the technology and task risks
constructs.
This study adopts social-technology theory and task-technology fit theory to guide our interpretation.
This study considered rival theories to increase predictive power.
There are two criteria for securing a sample: relevance and frame. Our case selection is apparent for
the risks in EIS projects, and it stands as an EIS.
The unit of analysis is a theme.
The context of this study (case period, time spent on the site, the nature of data, etc.) are addressed in
the method session.
A team of researchers conducted this work. To enhance confidence in our findings, investigators were
involved with different roles of EIS.
Area 2: Data collection
We described how interviews were conducted including sampling, the number of interviews and
interviewees, transcription use and validation of an interview guide.
We use interview data and project documentation to provide a richer picture of the events.
Our findings are based on several different sources of information which were collected from different
stakeholders.
The case of this work contains a case study protocol. We use Excel and Word software to process the
interview transcripts, researcher’s notes and coding scheme.
Area 3: Data analysis
Mapping the data into the theoretical constructs based upon social-technical theory.
The research question led to the interview questions under the constraints of socio-technical theory.
The coding and classifications were based on the Socio-technical theory framework. The results
related to Socio-technical theory in a “fit” framework.
Empirical testing (positivist) followed. Pattern matching (comparing observed relationship to
theoretically expected ones) applied to test the propositions.
Multi-cases were selected within users, managers and vendors to limit any confounding influence of
single participant imposed risk management.
Quotes from different clients, end-users, and different venders.
Several project managers from the client organization and vendor reviewed drafts of each case.
ness section, he’s in the system section, and we each are responsible
for representing our concerns.”
The vendors worried more about unrealistic schedules and lack of
regular communication and expected formal processes to help avoid
problems. The manager said:
“We have a specialized project-managing team, so does the owner,
and their qualities are well-controlled … as for the project manage-
ment, such as handing in the daily, monthly or weekly communica-
tions, we also check if anyone is behind schedule … another function
is to communicate and confirm the change of the demands by the
users, with what process they wish to follow, what sorts of impact
will occur, does it influence the budget …”.
In summary, participants of the EIS project anticipated difficulties
in communication and violating schedules, but were prepared with
controls to limit the occurrence of any problems along these lines.
The actor category has risks for all stakeholders in this study. Con-
cerns range from turnover to lack of knowledge. Once again, however,
the different organizations involved in the development of the EIS
have considered these risks and identified strategies for mitigation.
For example, NTA moves employees quickly through many layers of
the organization and across many jobs to work in the different de-
partments and learn various practices. One user said
“According to our organization policy, the organization expects us to
take different positions every five years … you don’t only do that vol-
untarily, sometimes you are forced to! … We are therefore trying to
adjust ourselves every single minute too…”
The vendor identified “poor domain knowledge” as an important
actor risk because required knowledge is wide ranging and requires
40 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44

Table 4
Examples of within-category risks for the EIS development project.

Structure Actor Task Technology

Users (NTA) • Inappropriate workflow and coordination • Actor turnover • Requirements scrubbing • New and untried
technology
• Poor physical arrangements • Non-willing/ethical problems • Poor human interface
• Formal procedures are frequently changed • Actor variation • Data update delay
• Poor or inappropriate
beliefs/skills/experience
• Political conflicts and power plays
Outsourcing vendor • Inefficient communication • Poor or inappropriate domain • Requirements scrubbing • New and untried
(CHT) knowledge technology
• Unrealistic schedules • Actor variation • Task ambiguity
IS department (FDC) • Inefficient communication • Non-willing/ethical problems • Requirements scrubbing • New and untried
technology
• Inefficient governance structure • Actor variation • Task ambiguity
• Poor physical arrangements • Political conflicts and power plays
• Unrealistic schedules

an understanding of complex technology. The project team at the
vendor needed to make an effort to understand the taxation process
also to the technology. The project manager said:
“Technically speaking, we also have many BI category applications
inside Chunghwa Telecom, so we are not that worried about the soft-
ware, … as for the financial application part, it will be a big challenge
for us to cross from the telecom to the financial field …”
On the whole, actor risks are still a prominent concern, but there
is a general awareness of their existence and some controls in place
to lessen their impact or likelihood.
For task risks all users, vendors, and IS staff point out that task am-
biguity is a critical concern. All participants recognize the EIS must
align with user requirements, but the lack of task clarity is a major
target for risk management in this EIS development. The project man-
ager of the vendor said:
“The major problem in the implementation of technology is not the
technicians, nor the programmers, nor the systems analysts. The ma-
jor problem is the business-person who does not know what he or
she wants and is unable to communicate accurately what little they
can figure out. At first, specifications were a bit too coarse and it was
almost like, in order to make this system possible, the system an-
alyst kept on handing unimportant and unnecessary specifications,
like whatever rubbish, to superiors …”
Further, each decision maker has different tasks or a different pro-
cess to accomplish the tasks required of an EIS. That means the user
participants of the EIS project are various and may even change fre-
quently. One end-user said
“When Group A stated its opinion, it was only their point of view.
Group B then states different demands. In the end, nothing corre-
sponds to another, so how many patterns in the world are we de-
veloping? A thousand or just one?”
For the end-user, an EIS is a new system, and they must join the
training program to be prepared for the new technology. One user
said:
“Come on … you merely encounter some operational problems in the
beginning, that’s because you are using a new technique…”
However, the staff of the IS department didn’t consider the tech-
nology risks to be serious. The manager said:
“An EIS is a merger of all completed things/applications, so techni-
cally, it is not difficult to develop an EIS based on the existing available
tools …”
In other words, the EIS participants must work with new tech-
nology, but the technology risks alone are generally, but not al-
ways, believed to be under control. The within-category risks sup-
port Proposition 1, but also seem to be recognized risks with accepted
practices for mitigation and control. We, therefore, turn our attention
to the between-category risks of Proposition 2.
4.1. Proposition 2a: actor-task fit
Skills particular to a given task can be a problem in the develop-
ment of a system and its subsequent use. In our case, the develop-
ment team recognized insufficient task skills on the part of the actors.
The project manager said:
“Policy requires employees to rotate between departments every five
years. Job rotation was never voluntary; we had to adjust constantly
ourselves to new tasks.”
One user expressed similar concerns by saying:
“I am the only person participating in the EIS development [from our
group]. Others in our group may not understand this EIS well … . I feel
that it is insufficient to have one person from the user group involved
in such an important project.”

On the whole, an EIS runs task risks associated with the levels, am-
biguity, complexity, and diversity of stakeholders. This creates prob-
lems in the quality and diversity of requirements and the ability of
the analyst to comprehend these requirements.
Among technology risks, both the users and the outsourcing
vendor identified adopting new and untried technology and poor
human interface as primary considerations. Platform technology
requirements of the client were new to the developer. One of the
programmers said:
“Although [product name] claims it provides an SDK, we continue to
search for it everywhere, even in Mainland China. Our company in
Taiwan is probably the first one to use this SDK with rather fancy
displays.”
These concerns arose from those rotated into new positions being
unfamiliar with the tasks, yet still having to contribute to the require-
ments. There is an identification that specific lack of task knowledge,
by certain individuals, may impede the development of an effective
EIS.
4.2. Proposition 2b: actor-structure fit
The vendor focused on structure and actor risk components while
they rearranged manpower and coordinated parties effectively un-
der a planned schedule. Though not directly a result of the EIS, the
management of an IS project has the potential to conflict with exist-
ing structures, especially when an outside agent is involved [46]. The
project manager said:
 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
“I did not think that we would be able to allocate a significant amount
of developmental resources to this project; although we could handle
tasks during the early stage of the project, the tasks became increas-
ingly challenging later on. Therefore, we outsourced a large part of
the project, and supplier-management became essential. For exam-
ple, I was a PM, but I actually monitored suppliers.”
So it was essential that job design structures be pliable. Chang-
ing needs of the project also led to difficulties in assigning actor re-
sources as the project progressed due to sufficiency concerns. The
project manager also indicated:
“To fulfill the variety of needs of the user groups, manpower allocation
needed to be monitored dynamically and updated accordingly. How-
ever, the vendor was not able to adjust dynamically. The outsourcing
company agreed to look into the manpower issues at the year-end
evaluation meeting.”
Overall, the project dynamics required personnel actions not es-
tablished by the organizational structures or contracts in place. In
systems that alter organizational structures, this risk would be more
directly linked to the product as well as the project.
4.3. Proposition 2c: actor-technology fit
The capabilities of the users are a concern during both the devel-
opment of the requirements for the technology and subsequent use
upon completion. These risks were identified in our case. One of the
analysts indicated:
“Numerous types of reports existed; consequently, users were re-
quired to change their user behaviors to adapt to the system through
training courses designed to help people learn the tools and utilities
and how to set up the reports from the database.”
For the EIS development staff, the vendor would focus on skilled
actors to decrease risk. For example, the project manager said:
“When we hired new people, we chose those familiar with [a commer-
cial EIS] and who had connections to that field. Due to the shortages
of qualified manpower, we needed to recruit offshore talent.”
The comments are essentially rooted in skill concerns, but resis-
tance issues might also surface in other settings.
4.4. Proposition 2d: task-structure fit
An EIS potentially enables wide-ranging analysis due to an in-
creased availability of data and added power of analysis tools to the
executive users. There were concerns that the EIS might lessen the
power of an individual executive by enabling cross-functional analy-
sis by other executives. One user said:
“Regarding cross-referencing, numerous struggles among depart-
ments occurred, and we compared the performance of each depart-
ment in other districts. For example, we were both heads of a cer-
tain department; as a result, if we made comparisons and references
within our own management scope, everything was fine. However, if
comparisons were made across departments, it was difficult to deter-
mine if the heads of the two departments would agree to the compar-
ison. In the end, decisions continued to vary between departments...”
During the development, due to the isolated nature of the depart-
ments, further issues arose contributing to project risks. Requirement
elicitation tasks became a particular problem as indicated by this
comment from an analyst:
“I am concerned that each agency unit may ask for more from the
EIS. However, those requests might not always be relevant. This might
complicate the mission of IS department.”
41
The isolation of tasks clearly had an impact on the ability to design
the system, as indicated by the project manager who said:
“Each agency unit is clearly designed with their own assigned duties
and responsibilities. The IS department is responsible for data and in-
formation management. The sales/service unit deals primarily with
the customers/citizens to serve their needs. This causes a communi-
cation problem …”
Again, the recognized risks have created difficulties in the devel-
opment of the EIS and in the use of the EIS upon completion.
4.5. Proposition 2e: task-technology fit
Deficiencies of any system in completing a task are evident in this
development, both when the design was under consideration and as
an intermediate result. In our case, deficiencies in the existing process
were noted during the design indicating the need for changes in the
development of the EIS. One user stated:
“We were not able to offer integrated information to the supervisors
of each office. One unit integrated and gathered all of the information
before it was presented.”
In particular, the vendor focused on the task risks as they pro-
posed the functional architecture. Still, initial designs of the system
did not yield desired results. The project manager said:
“The report format we generated did not fulfill the requirements of all
departmental directors. Without the EIS forms we currently share, we
were unable to integrate all of the information after we exported our
own reports.”
The database manager noted the need for the new system by in-
dicating a necessary match:
“The tax-related documents are kept for seven years, therefore, the
EIS needs to explore big chunks of data warehoused for control and
management, an efficient technology platform to support timely and
effective decision making is crucial.”
These comments indicate an understanding of the problems aris-
ing from failing to match technology to the tasks required. In this
case, an early attempt at a detailed report did not match.
4.6. Proposition 2f: technology-structure fit
To meet requirements of technology, system inputs, processes,
and outputs must be considered in terms of the structure, with de-
viations representing perceived risk. For example, to make authority
relations hold and preserve smooth communication channels across
the different departments, the EIS must honor the structure either in
place or be redesigned. In the case studied, one user states:
“The access to the EIS system was designed based on hierarchical
authority … any change would render control by authority access
meaningless.”
Another indicated that:
“In copying the flow changes caused by the EIS, our department had
undertaken a restructuring by instituting a new organization design
and manpower plan.”
One analyst recognized the risk:
“The new EIS called for the integration of data sources and a desig-
nated team for its operation and management. How to ensure the fair
access to the integrated data source by different stakeholders needs
to be resolved.”
42 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
On the whole, there is an understanding of the need to be certain
that the EIS technology follows the structural expectations of the or-
ganization. Violations of authority are viewed as problematic.
5. Discussion
This study addresses concerns about the identification of risks in
a complex information system development, an executive informa-
tion system. The approach is to consider the socio-technical model
and confirm an ability to designate risks to both the project and the
product of development through dimensions of task, actor, structure
and technology as well as the fit between each combination. Risks
were identified for each category for either the project, the product or
both. The results indicate that a lack of fit between executives’ tasks
and the proposed technology would lead to a failure of EIS imple-
mentation. This study reveals more fully the appropriateness of the
socio-technical model to describe IS developmental risks than prior
studies due to the limitations of a single dimension perceptive. Not
unexpected, evidence supported the initial proposition, that was al-
ready well received in the literature, but found evidence of risks for
each between-dimension fit.
5.1. Implications for researchers
The results of this study have several implications for our under-
standing of risk in the implementation of an EIS. First, it suggests
that a critical risk of EIS projects is a lack of clear task requirement,
and the proposed EIS must be a good fit with the executives’ tasks.
This suggests that technology-task fit theory could be a good theo-
retical foundation to explain the EIS implementation risk manage-
ment phenomenon, possibly being extendable across all dimensions
in the socio-technical model. New technology keeps expanding to
provide advances in the convenience of operation, flexible modeling,
and access to real-time and wide-ranging information. The task re-
quirements of the executives require a dynamically changing system
to deal with their unstructured problems. These dynamics can only
increase the complexity of the system and the risks that are encoun-
tered. A further understanding of the relationships between each pair
of dimensions is essential, and the building of a new theory for each
set is critical to understanding the risks more fully.
This study also has several implications for the general IS risk
management literature. It is evident from some of the statements
that the nature of the IS application will impact the risk character-
istics. Some risks are with general transaction system developments
including a greater number of actors equating to a greater risk of
having insufficient or inappropriate structure, acquiring unclear
tasks requiring integration, and more difficult control of heteroge-
neous IT capabilities. Different types of IS applications should be
examined separately to understand better the specific risks involved.
The suggested IS risk factors cannot be taken for granted without
considering the specific applications at hand. As examples, task
ambiguity in an EIS is a critical risk factor because the nature of
the task is non-routine and unstructured; task risk played a major
role in the whole EIS project development and the other three risk
components surrounded task risk interactively during the entire
system development project. EIS project managers may need to
concentrate their resources on task risk. For an Enterprise Resource
Planning system, the company often needs to change their business
processes to fit the ERP’s technology, therefore, the critical risks
factors include the structural dimension and fits to actors, tasks,
and technology and is potentially aggravated by unclear system
goals, ineffective communication, and political conflict [12,19]. We
suggest that the dimensions of the socio-technology model can
provide a theoretical foundation for researchers to examine the
risks and their interactions in the future in the context of different
systems.
5.2. Implications for IS managers
This study aids project managers and practitioners, placing stress
on the particular risks to diminish other risks in the IS develop-
ment process. In particular, the socio-technical model can be used
as a framework in a risk identification process. Many methods of risk
identification work to form a framework and the between-dimension
aspects add to any framework. Implementing these additional con-
cerns would be straightforward in a category driven brainstorming
session and in creating a more comprehensive list of potential risks.
Root cause diagrams can be driven by between-dimension and solo-
dimension categories. Attention is also brought to the consideration
of risks that combine dimensions. Since these are more complex, the
mitigation plans must be more complex as well, and control plans
might require joint responsibilities in terms of determining when tol-
erance thresholds are crossed during development.
This research addressed software development project risk rooted
in the context of a public sector application of an EIS application.
Generalization to the private sector should hold for certain dimen-
sions of similarity. Many tasks of analysis will be similar as will
the technology available and considered part of the application.
Thus, aspects within and between those two dimensions should be
expected to hold a good deal of commonality. However, bureaucratic
structures within a government context might vary dramatically
from the private sector and consideration of stakeholders that con-
sider the public interest at large may also not translate well from the
public to the private sector, while a good number of managerial and
user actors may provide some similarity. Those areas where there
would be commonalities should be able to draw conclusions from
this study while structures with more extreme differences should
consider the conclusions with care. In the same vein, transaction-
based systems will have certain common elements to an EIS of actor,
structure, technology. As a last point, goal-oriented requirements
methods present a unique opportunity to implement the theoretical
framework.
5.3. Limitations
There are some limitations to this study. First, our case limits our
findings to the context of the public session. Though many of the
technology and task features will reflect those in private sector con-
texts, the set of public interest actors and unique bureaucratic struc-
tures may make generalization problematic. It would be valuable for
a future study to explore our model in a business setting to test the
extent to which our findings could be generalized beyond the pub-
lic session. Second, we interview the key subjects without directly
observing the interaction among the system stakeholders. These in-
teractions are critical to risk management when the project managers
face problems during the system development process. Thus, it might
be beneficial for further research to conduct a qualitative study to
explore the dynamic risk management process. Third, we employed
content analysis as our chosen methodology, which can enter the bi-
ases and preconceptions of the researchers into the interpretation of
the data.
6. Conclusion
In conclusion, the successful construction and implementation of
an executive information system (EIS) is reliant upon a clear under-
standing of the appropriate technology to be used, the end-user ac-
cessing the system, and the tasks to be executed. We adopted two
competing theories, the socio-technical model and TTF, to investi-
gate EIS implementation risks. The social-technical model classifies
the risks into four categories and suggests that all these risks must be
controlled for IS success. TTF theory specifically points out the “fit”
between the task and technology dimensions is the key to a system’s
 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
success and leads us to extend the requirement to be between all
dimensions.
This study reveals several new insights of our understanding of
socio-technical theory and TTF theory on EIS project risk manage-
ment. First, the social-technical approach provided an integrated
view of the system development context to consider all risk factors in
the EIS context. TTF suggests that a root risk to success is the match of
the capability of the technology to the demand of the tasks. Combin-
ing Socio-technical theory and TTF theory, this study showed the risks
of the EIS derived from mismatches among the various dimensions,
resulting in a deep examination of root causes rather than a shallow
description of risks. In practices, project managers and practitioners
of the EIS may define the task clearly and attempt to understand
the executives’ need for task uncertainty reduction and/or to lead
other risks cascading in the system development phases. Such socio-
technical perspectives detail causal linkages. Second, our study helps
project managers and practitioners to make the proper resources al-
location on specific risks management and adjust them accordingly.
For example, project managers may focus their time to extract and
specify the project’s task at the early phases of the system develop-
ment process for better resources management. Third, this research
assists system managers and practitioners in designing a practical
risk management plan for the life cycle of the software development
process. For example, with the requirement to support executive’s
need and the advancement of IT, the EIS’s system manager may ex-
amine the design risks against the task risks at the early stage of the
system development process. Fourth, the perspective may assist in
the application of goal oriented approached to determining system
requirements in a complementary fashion by providing broader un-
derstanding of the roots of risk.
This research presents evidence for future study on risk manage-
ment of complex systems. Future research is required to explore more
complex and large scale systems or programs. Researchers and practi-
tioners are encouraged to adopt agile software development method-
ology to new contexts. A possible next step would be to develop risk
diagnostics in general and specific types of development methods
and situations. It would be interesting to test the risk diagnostics by
creating and evaluating the resource plan around system life cycle
phases.
This research was partly supported by grants from Ministry of Sci-
ence and Technology, Taiwan under the projects [100-2410-H-002-
015-MY3] and [103-2410-H-002-107-MY3].
Appendix. Interview protocol
Part 1: Organizational strength, weakness, opportunity, and
threat
1. What are the mission and vision of your organization?
2. What are the advantages (e.g. strength and opportunity) delivered
to your organization by EIS implementation? If any, please explain
how they occurred?
3. What are the challenges (e.g. weakness and threat) brought to
your organization by EIS implementation? If any, please explain
how you dealt with them?
4. How does the EIS make an impact on your organization in the fu-
ture? Please give us some examples.
5. How does EIS impact on culture, organizational structure and
workflow in your organization?
Part 2: Identify the stakeholders
6. What’s mission of EIS?
7. How long does it take to develop EIS project?
8. What are the stakeholders of the EIS project? Do they have enough
power, resource, time to involve the EIS project?
9. How much time does your organization spend on the EIS project
development?
43
10. Does your organization seek advice from consultants or experts
outside the organization for EIS project?
11. How do these system stakeholders evaluate your organization
ability in the EIS development process?
12. How does your organization understand the other stakeholders’
judgment?
13. How does your organization interact with other stakeholders of
the EIS project?
14. Who are the most important stakeholders in the EIS project?
15. Please define the roles and responsibility in EIS project. Who are
they?
16. How do you evaluate the ability of these system stakeholders in
the EIS development process?
17. How do you cooperate with the other stakeholders in EIS project?
18. Do you and the other stakeholders work together smoothly now?
Please give some examples.
19. How much effort do these stakeholders make to EIS project?
Part 3: Individual strategic issue and action plan identification
20. What are the strategic issues in your organization when develop-
ing the EIS project?
21. What makes it a priority to these strategic issues?
22. What specific action plans must be taken to implement the strat-
egy?
23. What are the possible barriers to implementing these action
plans?
24. Who are the key persons to lead these plans? What resources does
your organization use to cooperate with others?
25. What criteria will be used for evaluating these action plans?
26. If you could do this project again, would you adopt the same
method to implement this project?
27. Have any important tasks been overlooked? Does the EIS respond
to this problem?
References
[1] H.J. Watson, M.N. Frolick, Determining information requirements for an EIS, MIS
Q. 17 (3) (1993) 255–269.
[2] B.H. Wixom, H.J. Watson, An empirical investigation of the factors affecting data
warehousing success, MIS Q. 25 (2001) 17–41.
[3] F. Marx, J.H. Mayer, R. Winter, Six principles for redesigning executive information
systems—findings of a survey and evaluation of a prototype, ACM Trans. Manag.
Inf. Syst. (TMIS). 2 (4) (2011) 1–19 26.
[4] J.B. Thomas, S.M. Clark, D.A. Gioia, Strategic sensemaking and organizational per-
formance: linkages among scanning, interpretation, action, and outcomes, Acad.
Manag. J. 36 (2) (1993) 239–270.
[5] L.W. Belcher, H.J. Watson, Assessing the value of Conoco’s EIS, MIS Q. 17 (3) (1993)
239–259.
[6] B. Vandenbosch, S.L. Huff, Searching and scanning: how executives obtain infor-
mation from executive information systems, MIS Q. (1997) 81–107.
[7] A. Rai, C. Stubbart, D. Paper, Can executive information systems reinforce biases?
Accounting, Manag. Inf. Technol. 4 (2) (1994) 87–106.
[8] L. Zhou, A. Vasconcelos, M. Nunes, Supporting decision making in risk manage-
ment through an evidence-based information systems project risk checklist, Inf.
Manag. Comput. Secur. 16 (2) (2008) 166–186.
[9] P.L. Bannerman, Risk and risk management in software projects: a reassessment,
J. Syst. Softw. (81:12) (2008) 2118–2133.
[10] S. Islam, H. Mouratidis, E.R. Weippl, An empirical study on the implementation
and evaluation of a goal-driven software development risk management model,
Inf. Softw. Technol. 56 (2014) 117–133.
[11] N. Lesca, M. Caron-Fasan, Strategic scanning project failure and abandonment fac-
tors: lessons learned, Eur. J. Inf. Syst. 17 (4) (2008) 371–386.
[12] W.K. Lim, S.K. Sia, A. Yeow, Managing risks in a failing IT project: a social con-
structionist view, J. Assoc. Inf. Syst. 12 (6) (2011) 414–440.
[13] K. Lyytinen, M. Newman, Explaining information systems change: a punctated
socio-technical change model, Eur. J. Inf. Syst. 17 (2008) 589–613.
[14] L. Mcleod, B. Doolin, Information systems development as situated socio-
technical change: a process approach, Eur. J. Inf. Syst. 21 (2012) 176–191.
[15] C.P. Yu, H.G. Chen, G. Klein, J.J. Jiang, Risk dynamics throughout the system devel-
opment life cycle, J. Comput. Inf. Syst. 53 (3) (2013) 28–37.
[16] R. Young, E. Jordan, Top management support: mantra or necessity, Int. J. Project
Manag 26 (7) (2008) 713–725.
[17] R.P. Bostrom, J.S. Heinen, MIS problems and failures: a socio-technical perspec-
tive, MIS Q. 1 (3) (1977) 17–32.
[18] D.L. Goodhue, R.L. Thompson, Task-technology fit and individual performance,
MIS Q. (1995) 213–232 June.
44 C.-P. Yu et al. / Information and Software Technology 68 (2015) 34–44
[19] B.H. Reich, I. Benbasat, Factors that influence the social dimension of alignment
between business and information technology objectives, MIS Q. 24 (1) (2000)
81–113.
[20] J.N. Luftman, R. Kempaiah, An update on business-IT alignment: “A Line” has been
drawn, MIS Q. Executive 6 (3) (2007) 165–175.
[21] M. Xu, G.R. Kaye, An integrative framework for strategic intelligence, Int. J. Strateg.
Inf. Technol. Appl. (IJSITA) 1 (4) (2010) 1–18.
[22] F.S. Affeldt, S.D. da Silva Junior, Information architecture analysis using business
intelligence tools based on the information needs of executives junior, J. Inf. Syst.
Technol. Manag.: JISTEM 10 (2) (2013) 251–270.
[23] J.H. Mayer, N. Steinecke, R. Quick, T. Weitzel, More applicable environmental scan-
ning systems leveraging “modern” information systems, Inf. Syst. e-Bus. Manag.
11 (4) (2013) 507–540.
[24] A. van Lamsweerde, E. Letier, Handling obstacles in goal-oriented requirements
engineering, IEEE Trans. Softw. Eng. 26 (10) (2000) 978–1005.
[25] A. Pommeranz, C. Detweiler, P. Wiggers, C. Jonker, Elicitation of situated values:
need for tools to help stakeholders and designers to reflect and communicate,
Ethics Inf. Technol. 14 (2012) 285–303.
[26] T.H. Nguyen, B.Q. Vo, M. Lumpe, J. Grundy, KBRE: a framework for knowledge-
based requirements engineering, Softw. Qual. J. 22 (2014) 87–119.
[27] L. Mathiassen, T. Tuunaen, T. Saarinen, M. Rossi, A contigency model for require-
ments development, J. Assoc. Inf. Syst. 8 (11) (2007) 569–597.
[28] B.W. Boehm, Software risk management: principles and practices, IEEE Softw. 8
(1) (1991) 32–41.
[29] D. Tesch, T.J. Kloppenborg, M.N. Frolick, IT project risk factors: the
project management professionals perspective, J. Comput. Inf. Syst. 47 (4)
(2007) 61–69.
[30] J.J. Jiang, G. Klein, T.S. Ellis, A measure of software development risk, Project
Manag. J. 33 (3) (2002) 30–41.
[31] G. Klein, J.J Jiang, Seeking consonance in information systems, J. Syst. Softw. 56
(2) (2001) 195–202.
[32] J.J. Jiang, G. Klein, H.G. Chen, The effects of user partnering and user non-support
on project performance, J. Assoc. Inf. Syst. 7 (2) (2006) 68–88.
[33] K. Lyytinen, L. Mathiassen, J. Ropponen, Attention shaping and software risk-a
categorical analysis of four classical risk management approaches, Inf. Syst. Res.
9 (3) (1998) 233–255.
[34] K. Khaifi, H. Berger, Resistance drivenby non-technical risks in information sys-
tems development: a case study in the sultanate of Oman, in: Proceedings of the
Uk Academy for Information Systems Conference, 2011.
[35] L.F. Luna-Reyes, J. Zhang, J.R. Gil-Garcia, A.M. Cresswell, Information systems de-
velopment as emergent socio-technical change: a practice approach, Eur. J. Inf.
Syst. 14 (2005) 93–105.
[36] H.J. Leavitt, Applied organization change in industry: structural, technical, and
human approaches, New Perspective in Organizational Research, Wiley, Chicago,
1964, pp. 55–71.
[37] L. Wallace, M. Keil, Software project risks and their effect on outcomes, Commun.
ACM:CACM 47 (4) (2004) 68–73.
[38] E.M. Ikart, Executive information systems and the top-officers ‘Roles: an ex-
ploratory study of user-behavior model and lessons learnt, Australas. J. Inf. Syst.:
AJIS. 13 (1) (2005) 78–100.
[39] M. Benaroch, S. Shah, M. Jeffery, On the valuation of multistage information tech-
nology investments embedding nested real options, J. Manag. Inf. Syst.: JMIS 23
(1) (2006) 239–261.
[40] R.V. McCarthy, G.F. Claffey, Task-technology fit in data warehousing environ-
ments: analyzing the factors that affect utilization, J. Int. Technol. Inf. Manag. 14
(4) (2005) 45–61.
[41] M.D.R. Cooper, P.S. Schindler, Business Research Methods, McGraw-Hill, NA, 2008.
[42] K.A. Neuendorf, The Content Analysis Guidebook, Sage, CA, 2002.
[43] K.H. Krippendorff, Content Analysis: An Introduction to Its Methodology, Sage,
London, 1980.
[44] A. Strauss, J. Corbin, Basics of Qualitative Research: Techniques and Procedures
for Developing Grounded Theory, 2nd ed., Sage Publications, Thousand Oaks, CA,
1998.
[45] R.K. Yin, Case Study Research: Design and methods, Sage Publications, CA, 2009.
[46] J.Y. Chang, E.T. Wang, J.J Jiang, G. Klein, Controlling ERP consultants: client and
provider practices, J. Syst. Softw. 86 (5) (2013) 1453–1461.