Information systems are implemented in an organization to improve effectiveness and ef- ficiency of that organization. Development and efficiency achieved using such systems provides a measure of these systems usefulness, and creates the need to communicate the usefulness of these systems (Hevner, March, Park, & Ram, 2004).
Lots of research and articles are conducted about the information systems, but in order to achieve the required knowledge and serve the productive application of IS, Hevneret. al suggested the link between two paradigms, these are the behavioural science and the design science.
Behavioural science seeks to develop and justify theories that explain or predict organiza- tional and human phenomena surrounding the analysis, design, implementation, manage- ment, and use of information systems. These theories are supposed to inform researchers and practitioners of the interactions among people, technology, and organizations that must be managed if an information system is to achieve its stated purpose, which is im- proving productivity and efficiency of an organization.
Design science is a problem-solving paradigm. It seeks to create innovations that define the ideas, practices, technical capabilities, and products through which the analysis, de- sign, implementation, management, and use of information systems can be effectively and efficiently accomplished.
Hevneret. al argue that IS research will make significant contributions if engaged to the complementary research cycle between design science and behavioral-science to address fundamental problems faced in the productive application of information technology. ”The realm of IS research is at the confluence of people, organizations, and technology. IT artifacts are broadly defined as constructs (vocabulary and symbols), models (ab- stractions and representations), methods (algorithms and practices), and instantiations (implemented and prototype systems). These are concrete prescriptions that enable IT researchers and practitioners to understand and address the problems inherent in develop- ing and successfully implementing information systems within organizations”(Hevner et al., 2004).
Figure 2.8 presents Hevner the conceptual framework for understanding, executing, and evaluating IS research combining behavioural-science and design-science paradigms. For IS research, it is composed of people, (business) organizations, and their existing or planned technologies. In the environment are the goals, tasks, problems, and opportunities that define business needs as they are perceived by people within the organization. Such perceptions are shaped by the roles, capabilities, and characteristics of people within the organization. Business needs are assessed and evaluated within the context of organiza- tional strategies, structure, culture, and existing business processes. They are positioned relative to existing technology infrastructure, applications, communication architectures, and development capabilities. Together these define the business need or problem, as perceived by the researcher. Framing research activities to address business needs assures research relevance. Given such an articulated business need, IS research is conducted in two complementary phases.
Behavioural science addresses research through the development and justification of the-
Figure 2.8: Hevner Framework for IS research design (Hevner et al., 2004)
ories that explain or predict phenomena related to the identified business needs. Design science addresses research through the building and evaluation of artifacts designed to meet identified business needs. The arrows flow from the IS research in the figure refer to the contribution of it to both the environment and the knowledge base.
2.7.1 Hevner Model for Risk Management in IS/IT Projects
In order to make a structured research, and because it is mainly related to IS/IT, the adjusted version of the Hevner framework will be created, that is to be used for the risk management of IS/IT projects. The target is to eventually find the link between this research and other research and the IS/IT projects. Thus locating the research about IS/IT projects risk in the map and how the research and existing knowledge are exploited. This framework also includes the need for evaluating case studies in expectation of the identification of the weakness in theory or the need to refine and reassess this theory. In the following section, provides a brief explanation of the components of the Hevner model regarding the risk management in IS systems.
2.7.2 Components Of The Adjusted IS Research Framework
Environment
In his article ”Design science in information systems research”, Hevner explains that envi- ronment of the research defines the space of the problem. In other words, the environment refers to everything related to the problem, which might be people or business in the organization and their existing or planned technologies. The environment might include tasks, problems and opportunities as defined by people. Business needs are assessed and evaluated within the context of organizational strategies, structure, culture, and existing business processes. Existing technology infrastructure, applications, communication ar- chitecture and development capabilities together define the business need or problem.
In the context of the problem environment and business needs for this research we already identified the problem at hand which is finding a possible way to identify and quantify risk in order to overcome risks to come in the projects, including the financial risks.
People Risk
In the environment of a given project the people identified are all the stakeholders who have a role in the project, so to name but a few: Top management; Project managers; Users; Clients; Internal and external contractors. Risks expected from people in general, to name but a few:
Top Management risks: Change in ownership of senior management; Changing scope / objectives; Political games or conflicts; Changes to membership on the project team; Lack of top management commitment to the project; Not managing change properly; Contin- ually changing system requirements; Failure to gain user commitment; Failure to manage end-user expectations; Misunderstanding of the requirements; Insufficient procedures to ensure security; integrity and availability of the database; Introduction of new technology; Corporate politics with negative effect on project; Failure to identify all stakeholders; Gold plating (Arnuphaptrairong, 2011).
Project managers: Absence of the declared business benefits; Lack of required knowl- edge /skill in the project personnel; Political games or conflicts; Not managing change properly; Lack of effective project management methodology; Misunderstanding of the re- quirements; Lack of effective project management skills; Unclear / misunderstood scope/ objectives; Unrealistic schedules and budgets; Changes to membership on the project team; Project progress not monitored closely enough (Arnuphaptrairong, 2011).
Users: Conflict between user departments; Absence of the declared business benefits; Political games or conflicts; Lack of adequate user involvement; Lack of cooperation from users; Changes to membership on the project team; Misunderstanding of the requirements; Complicated relationship of stakeholders with the project that may lead to conflict, like users of this project are clients of another project.
Clients: Lack of client responsibility and ownership and Continually changing system requirements (Arnuphaptrairong, 2011).
Organizational Risk Business needs are assessed and evaluated within the context of organizational strategies, structure, culture, and existing business processes. In the con- text of this research we refer to organizational risk in the context of organization. Risks categorized under organizational risks include: Projects that are intended to fail, these projects are started for political reasons, these projects are doomed to fail, they carry no clear business value, but yet they need to be completed; Unstable corporate environment; Insufficient resources; Reputation; Financial fraud (Holmes, 2002).
Operational Risk Under organizational risk we can also identify operational risk which is defined as “The risk of loss resulting from inadequate or failed internal processes, people, and systems or from external events”. from the definition operational risk has to do with bad management of resources, and among operational risks we identify: Damage to physical assets; Business disruption and system failures; Failed execution, delivery, and process management; Contractual risk; Counter-party risk and risk of default (Hull, 2012).
Technological Risk People and organizational context are positioned relative to exist- ing technology. In this case we refer to outdated or incompatible or inadequate techno- logical infrastructure, applications, communication architectures, and development capa- bilities (The Standish Group Report, 2014).
Knowledge Base
The knowledge base provides the raw materials from and through which IS research is accomplished.
Foundations &Methodology Prior IS research and results from reference disciplines provide foundational theories, frameworks, instruments, constructs, models, methods, and instantiations used in the develop/build phase of a research study. Methodologies provide guidelines used in the justify/evaluate phase.
In her research proposal, Ir. Kuiper identified the need for more thorough risk management regarding the IS/IT projects depending on literature research, interviews and observations. For the Knowledge base of this research, there are plethora of collected information about IS/IT projects risk management and many authors as well, to name but few: Software Risk Management: Principles and Practices (B. W. Boehm, 1991); Top Ten Lists of Soft- ware Project Risks; Evidence from the Literature Survey, where (Arnuphaptrairong, 2011) created top ten lists of mostly occurring risks in software projects; in his article “Does risk management contribute to IT project success? A meta-analysis of empirical evidence” (De Bakker et al., 2010) explored the need for risk management and the reasons of failed risk management practices in IT projects.
IS Research
IS research makes use of existing knowledge base which consists of methodologies and foundations, employs them to develop and build theories and artifacts. These theories and artifacts are supposed to fulfill the needs of the environment.
Develop and Build This part refers to building or developing constructs, models, meth- ods like algorithms and practices, and implemented and prototype systems. These con- structs are supposed to help solving the problems of the environment. In this research, we used the existing knowledge to create the risk platform that is the suggested solution to our problem which is risk management for IS/IT projects including risk identification and quantification.
Justify and Evaluate
Justifying and evaluating the proposed artifact is meant to evaluate the applicability and benefits of the solution to either exploit it or searching for a better alternative. The risk platform is a tool used by financial institutions. It provides services for institutions subscribed to the risk platform organization. In addition to the services provided by the platform owners regarding risk management and compliance, it also transfers expertise among companies.
An important fact to justify efficiency of the risk platform is the fact that it provides quantitative measure of the risks to come, and suggests solutions that has proved to be effective. The information provided by the risk platform are based on real events, which is a merit. In the future if the risk platform is extended to be shared among more than one organization, and among multiple sectors, data is gathered from all IS/IT projects
in all sectors. This extension will make more data available, which means more accurate information, more in-depth knowledge, better statistics and consequently better advice and better risk management measures.
Figure 2.9 represents the Hevner model for risk management in IS research, this figure is the original Hevner framework adjusted to the research about risk management in IS/IT projects.
In the ’Environment’ box the items added are the environment elements that triggered the need for the research. People risk, organizational risk and operational risk, all these elements related to information systems projects are the environment that create risk, it is also the environment that will benefit from the results of research. Knowledge base con- tains all the research in the IS/IT field regarding the risk management practices, methods and techniques. The IS research box contains the artifact, the application of risk quantifi- cation as a tool for risk management and the risk platform as an artifact.
Thus, the IS research which is triggered by the environment makes use of existing knowl- edge base -theories and applications- to contribute to the problem of the environment, either by an artifact or the application of theories. Of course other items can be added to each box for an extensive research. Extensive form of the Hevner model for risk manage- ment is in the Appendix F.
Figure 2.9: Adjusted Hevner Framework for Risk Management in IS research design
Chapter two provided the theoretical framework for this research, and at the same time it provided answers to some research sub questions. Section 2.1 explained the risk man- agemet approaches as classified by (De Bakker et al., 2010) an evaluation and management approach, the first is concerned with creating an assumption about the cost to be created by anticipated risks. The latter, which is the management approach is concerned with insuring the proper implementation of the project with no delays and failure by the deci- sion making that facilitates avoiding risks or handling it properly. Section 2.2 provided an answer to the second sub question about the risk quantification practices. IS/IT projects valuation was discussed in sections 2.3 and 2.4, where the section 2.3 defined the IS/IT projects valuation and section 2.4 screened the valuation methods as classified by Ir. Kuiper. Real options, definition use benefits and evaluation were explained in section 2.5. Chapter 3 will further discuss the risk platform creation and its role in risk quantification and projects valuation.
Chapter 3
The Risk Platform
3.1
Introduction to the Risk Platform
As mentioned in section 2.1, the evaluation approach aims at finding generic risks, analyze them, and use the information for next projects. In this context the risk platform is an auxiliary tool to evaluate risks. But before talking about the risk platform, it would be more appropriate to start by the risk register which is a similar concept. The Risk register is a document that contains information about identified project risks, analysis of risk severity and evaluations of the possible solutions to be applied. Presenting this in a spreadsheet is often the easiest way to manage risks, so that key information can be found and applied quickly and easily (Forni & van der Meulen, 2016). The risk register is adopted by PMBOK (Project Management Body of Knowledge) and PRINCE2 make recommendations for the use of it. The risk register is commonly used by project managers. However, the risk register is created during the project delivery stage, and it is used on the project level when reviewing the project upon delivery.
Figure 3.1: Risk Register Screen shot
The risk register currently used should contain at the minimum the following information: A unique identifier for each risk; a description of the risk (including the cause, risk event and effect e.g. Because of heavy rain, there is a threat of the field flooding which would spoil the crops); risk response actions; risk owner. These information are enough for low risk projects, and it is suggested to add more qualitative and quantitative measures
for riskier projects. Any further information added to the register are voluntary by the project owners. Figure 3.1 is a screen shot from the currently used risk register, it shows a description of the event, the cause of it and the consequences. Further fields that are not showing in the figure are the problem owner, the response, the probability, the impact of the risk, the time needed to solve the issue, the costs and the status of the risk(open or closed).
In the organization where the research was held, the risk register is used during the project to archive the events and use them as ’Lessons Learned’ for future projects, and to communicate the events with colleagues and management. As can be seen from the concept of risk register, this approach complies with the evaluation approach in risk management which was explained in section 2.1. However, it can be said that the risk register is not fully exploited, and any lessons learned from the risk register are only an accumulated experience that is limited to the project stakeholders.