Two paradigms characterize much of the research in the Information Systems discipline: behavioral science and design science The behavioral-science paradigm seeks to develop and verify theories that explain or predict human or organizational behavior The design-science paradigm seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts Both paradigms are foundational to the IS discipline, positioned as it is at the confluence of people, organizations, and technology Our objective is to describe the performance of design-science research in Information Systems via a concise conceptual framework and clear guidelines for understanding, executing, and evaluating the research In the design-science paradigm, knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact Three recent exemplars in the research literature are used to demonstrate the application of these guidelines We conclude with an analysis of the challenges of performing high-quality design-science research in the context of the broader IS community

/pdf/design-science-in-information-systems-research-1f7l0yvs8e.pdf

Design science in information systems research

https://spectrum.library.concordia.ca/976864/1/OkoliPawlowski2004DelphiPostprint.pdf

The Delphi method as a research tool: an example, design considerations and applications

Introduction It continues to be an exciting time to be a researcher in the information systems discipline; there seems to be a plethora of interesting and pressing research topics suitable for research at the masters or PhD level. Researchers may want to look forward to see what will be the key information systems issues in a wireless world, the ethical dilemmas in social network analysis, and the lessons early adopters learn. Practitioners may be interested in what others think about the strengths and weaknesses of an existing information system, or the effectiveness of a newly implemented information system. The Delphi method can help to uncover data in these research directions. The Delphi method is an iterative process used to collect and distill the judgments of experts using a series of questionnaires interspersed with feedback. The questionnaires are designed to focus on problems, opportunities, solutions, or forecasts. Each subsequent questionnaire is developed based on the results of the previous questionnaire. The process stops when the research question is answered: for example, when consensus is reached, theoretical saturation is achieved, or when sufficient information has been exchanged. The Delphi method has its origins in the American business community, and has since been widely accepted throughout the world in many industry sectors including health care, defense, business, education, information technology, transportation and engineering. The Delphi method's flexibility is evident in how it has been used. It is a method for structuring a group communication process to facilitate group problem solving and to structure models (Linstone & Turloff, 1975). The method can also be used as a judgment, decision-aiding or forecasting tool (Rowe & Wright, 1999), and can be applied to program planning and administration (Delbeq, Van de Ven, & Gustafson, 1975). The Delphi method can be used when there is incomplete knowledge about a problem or phenomena (Adler & Ziglio, 1996; Delbeq et al., 1975). The method can be applied to problems that do not lend themselves to precise analytical techniques but rather could benefit from the subjective judgments of individuals on a collective basis (Adler & Ziglio, 1996) and to focus their collective human intelligence on the problem at hand (Linstone & Turloff, 1975). Also, the Delphi is used to investigate what does not yet exist (Czinkota & Ronkainen, 1997; Halal, Kull, & Leffmann, 1997; Skulmoski & Hartman 2002). The Delphi method is a mature and a very adaptable research method used in many research arenas by researchers across the globe. To better understand its diversity in application, one needs to consider the origins of the Delphi method. The Classical Delphi The original Delphi method was developed by Norman Dalkey of the RAND Corporation in the 1950's for a U.S. sponsored military project. Dalkey states that the goal of the project was "to solicit expert opinion to the selection, from the point of view of a Soviet strategic planner, of an optimal U.S. industrial target system and to the estimation of the number of A-bombs required to reduce the munitions output by a prescribed amount," (Dalkey & Helmer, 1963, p. 458). Rowe and Wright (1999) characterize the classical Delphi method by four key features: 1. Anonymity of Delphi participants: allows the participants to freely express their opinions without undue social pressures to conform from others in the group. Decisions are evaluated on their merit, rather than who has proposed the idea. 2. Iteration: allows the participants to refine their views in light of the progress of the group's work from round to round. 3. Controlled feedback: informs the participants of the other participant's perspectives, and provides the opportunity for Delphi participants to clarify or change their views. 4. Statistical aggregation of group response: allows for a quantitative analysis and interpretation of data. …

/pdf/the-delphi-method-for-graduate-research-2ix019ihg9.pdf

The Delphi Method for Graduate Research

One of the most challenging decisions that a manager must confront is whether to continue or abandon a troubled project. Published studies suggest that failing software projects are often allowed to continue for too long before appropriate management action is taken to discontinue or redirect the efforts. The level of sunk cost associated with such projects has been offered as one explanation for this escalation of commitment behavior. What prior studies fail to consider is how concepts from risk-taking theory (such as risk propensity and risk perception) affect decision makers' willingness to continue a project under conditions of sunk cost. To better understand factors that may cause decision makers to continue such projects, this study examines the level of sunk cost together with the risk propensity and risk perception of decision makers. These factors are assessed for cross-cultural robustness using matching laboratory experiments carried out in three cultures (Finland, the Netherlands, and Singapore). With a wider set of explanatory factors than prior studies, we could account for a higher amount of variance in decision makers' willingness to continue a project. The level of sunk cost and the risk perception of decision makers contributed significantly to their willingness to continue a project. Moreover, the risk propensity of decision makers was inversely related to risk perception. This inverse relationship was significantly stronger in Singapore (a low uncertainty avoidance culture) than in Finland and the Netherlands (high uncertainty avoidance cultures). These results reveal that some factors behind decision makers' willingness to continue a project are consistent across cultures while others may be culture-sensitive. Implications of these results for further research and practice are discussed.

A cross-cultural study on escalation of commitment behavior in software projects

Design activities are central to most applied disciplines. Research in design has a long history in many fields including architecture, engineering, education, psychology, and the fine arts (Cross 2001). The computing and information technology (CIT) field since its advent in the late 1940s has appropriated many of the ideas, concepts, and methods of design science that have originated in these other disciplines. However, information systems (IS) as composed of inherently mutable and adaptable hardware, software, and human interfaces provide many unique and challenging design problems that call for new and creative ideas.

/pdf/design-science-research-in-information-systems-1dq1e7v3c1.pdf

Design Science Research in Information Systems

Identifying Software Project Risks: An International Delphi Study.

Advocates of software risk management claim that by identifying and analyzing threats to success (i.e., risks) action can be taken to reduce the chance of failure of a project. The first step in the risk management process is to identify the risk itself, so that appropriate countermeasures can be taken. One problem in this task, however, is that no validated lists are available to help the project manager understand the nature and types of risks typically faced in a software project. This paper represents a first step toward alleviating this problem by developing an authoritative list of common risk factors. We deploy a rigorous data collection method called a ranking-type Delphi survey to produce a rank-order list of risk factors. This data collection method is designed to elicit and organize opinions of a panel of experts through iterative, controlled feedback. Three simultaneous surveys were conducted in three different settings: Hong Kong, Finland, and the United States. This was done to broaden our view of the types of risks, rather than relying on the view of a single culture-an aspect that has been ignored in past risk management research. In forming the three panels, we recruited experienced project managers in each country. The paper presents the obtained risk factor list, compares it with other published risk factor lists for completeness and variation, and analyzes common features and differences in risk factor rankings in the three countries. We conclude by discussing implications of our findings for both research and improving risk management practice.

Identifying Software Project Risks: An International Delphi Study

We've all heard tales of multimillion dollar mistakes that somehow ran off course. Are software projects that risky or do managers need to take a fresh approach when preparing for such critical expeditions? Software projects are notoriously difficult to manage and too many of them end in failure. In 1995, annual U.S. spending on software projects reached approximately $250 billion and encompassed an estimated 175,000 projects [6]. Despite the costs involved, press reports suggest that project failures are occurring with alarming frequency. In 1995, U.S companies alone spent an estimated $59 billion in cost overruns on IS projects and another $81 billion on canceled software projects [6]. One explanation for the high failure rate is that managers are not taking prudent measures to assess and manage the risks involved in these projects. is Advocates of software project risk management claim that by countering these threats to success, the incidence of failure can be reduced [4, 5]. Before we can develop meaningful risk management strategies, however, we must identify these risks. Furthermore, the relative importance of these risks needs to be established, along with some understanding as to why certain risks are perceived to be more important than others. This is necessary so that managerial attention can be focused on the areas that constitute the greatest threats. Finally, identified risks must be classified in a way that suggests meaningful risk mitigation strategies. Here, we report the results of a Delphi study in which experienced software project managers identified and ranked the most important risks. The study led not only to the identification of risk factors and their relative importance, but also to novel insights into why project managers might view certain risks as being more important than others. Based on these insights, we introduce a framework for classifying software project risks and discuss appropriate strategies for managing each type of risk. Since the 1970s, both academics and practitioners have written about risks associated with managing software projects [1, 2, 4, 5, 7, 8]. Unfortunately , much of what has been written on risk is based either on anecdotal evidence or on studies limited to a narrow portion of the development process. Moreover, no systematic attempts have been made to identify software project risks by tapping the opinions of those who actually have experience in managing such projects. With a few exceptions [3, 8], there has been little attempt to understand the …

A framework for identifying software project risks

Although investment in information technology and information systems continues to increase, projects continue to fail. As a result, IS projects, particularly software projects, are perceived as high risk. By categorizing types of risk, this article helps IS professionals and all project sponsors to identify classes of risk and choose the appropriate managerial behavior to mitigate each of them.

Strategies for Heading Off is Project Failure

Internet-based projects are those that are managed through the Internet. By using the Internet as the channel of communication, project managers can pull together teams that are dispersed geographically and temporally. New software and new services are reaching the market to support Internet-based project management. It is anticipated that improved communications and better workflow management software will reduce threats to the successful completion of projects. Nonetheless, the new approaches and software introduce new complexity and possibly new risks to Internet-based projects. This chapter is an introduction to project risk and the management of project risk in Internet-based software projects. Potential risks arising from Internet-based project management, as opposed to traditional project management, are discussed. Then approaches to the management of risk are compared. An integrated approach to risk assessment and management is advocated.


Keywords:

Internet-based project;
Internet-based project management;
management of project risk;
project risk;
risk assessment;
risk factor

Roy C. Schmidt

Papers

Identifying Software Project Risks: An International Delphi Study.

Identifying Software Project Risks: An International Delphi Study

A framework for identifying software project risks

Strategies for Heading Off is Project Failure

Risk Management in Internet‐Based Software Projects