d theory nexus - heim.ifi.uio.noheim.ifi.uio.no/~petterog/kurs/design...

Pries-Heje & Baskerville/The Design Theory Nexus

MIS Quarterly Vol. 32 No. 3, pp. 1-XXX/September 2008 1

1 SPECIAL ISSUE

THE DESIGN THEORY NEXUS12

By: Jan Pries-Heje3Roskilde [email protected]

8Richard Baskerville9Georgia State University10Atlanta, GA [email protected]

Abstract1415

Managers frequently face ill-structured or “wicked” prob-16lems. Such problems are characterized by a large degree of17uncertainty with respect to how the problem should be18approached and how to establish and evaluate the set of19alternative solutions. A design theory nexus is a set of20constructs and methods that enable the construction of models21that connect numerous design theories with alternative solu-22tions. It thereby offers a unique problem-solving approach23that is particularly useful for addressing ill-structured or24wicked problems. For each alternative solution in a design25theory nexus one or more unique criteria are established to26formulate a specific design theory. We develop a general27method for constructing a design theory nexus and illustrate28its utility using two field studies. One develops and applies29an organizational change nexus. The other develops and30applies a user involvement nexus. Each is a specific instan-31tiation of the general design theory nexus constructs. Using32

1Veda Storey was the accepting senior editor for this paper.33

these illustrations, we provide examples of how to evaluatesuch instantiations. We then discuss our findings as well asthe validity of our approach. We conclude that the designtheory nexus provides a viable conceptualization that enablesthe construction of effective problem-solving artifacts.

Keywords:

Introduction

The decision-making situations of real life involve twoelements: factual and value (Simon 1960). These elementsinvoke two kinds of decision-making processes: structuredand judgmental (Keen and Scott Morton 1978). Structureddecisions are repetitive and routine. Unstructured decisionsdefy programmed decision making because they are novel,complex, or value-laden. Semi-structured decisions combinethese two extremes: settings where the unstructured judg-ments of decision makers would be insufficient without sup-port through more structured data modeling or informationgathering.

Perhaps the apex of unstructured decision making occurs inthe context of wicked problems. Such problems are poorlyformulated, confusing, and permeated with conflicting valuesof many decision makers or other stakeholders. Becauseevery outcome of the decision is obscure, the problem cannotbe parted or solved piecemeal (Churchman 1967). Wickedproblems share certain characteristics. For example, they canonly be formulated in terms of a solution. Their solutions arevalue-laden, and cannot be denoted true or false, only good orbad. Their solution space is unbounded, and solutions areirreversible (Rittel and Webber 1973). Wicked problems can-not be approached, nor can alternatives be established or


2 MIS Quarterly Vol. 32 No. 3/September 2008

evaluated, without engaging considerable uncertainty. Yet1social, environmental, and economic conditions are increasing2the wicked problems facing organizational decision makers3today (Courtney 2001).4

5The technical orientation of decision support systems makes6them unsuitable for wicked problems (Mackenzie et al. 2006).7For example, decision making requires one or more criteria.8With only one criterion—price for an IS commodity, for9example—it is easy to rank alternatives for selection, but two10criteria mean determining the weighting for each one. With11multiple criteria decision making (MCDM), the preferences12of the decision maker become very important (e.g., how much13is extra performance of a system worth). Further it also14becomes important when the knowledge about preferences15becomes explicit (Hwang and Masud 1979).16

17There is little practical use for interactive MCMD applica-18tions, perhaps because of their high complexity (Kaliszewski192004). There are at least two other technical problems. For20example, the multiple attribute utility theory (MAUT) (Belton21and Stewart 2001; Keeney and Raiffa 1976, 2002) and the22analytical hierarchy process (AHP) (Saaty 1988; Saaty and23Vargas 1987) both use decision matrices where each decision24alternative is assessed on each of the criteria. One problem is25the assumption that a single number or an interval can be used26to represent the preferences of a decision maker (Wang et al.272007; Xu et al. 2006). The other problem is the assumption28that the same set, tree, or hierarchy of criteria can be used to29compare the decision alternatives. Many decisions in real-life30organizations raise alternatives that are so essentially different31that analytical comparisons invariably become biased because32the analytical criteria will relate well to only a subset of the33alternatives. This asymmetrical criteria problem is repre-34sented in Figure 1. The left bar graph represents a hypothe-35tical set of four criteria and four options, where each option36satisfies multiple criteria to a greater or lesser degree. The37right bar graph represents a different hypothetical set of four38criteria and four options. However, each option essentially39satisfies its own criterion completely, while poorly addressing40the criteria of other options.41

42This asymmetrical criteria problem is wicked because the43solution introduces a singular criterion by which the problem44is formulated, and decision becomes a value judgment about45which problem criterion to address. It remains one of the46most fundamental issues of ill-structured problems: a diver-47gence between alternative formulations of the problem48(Mitroff and Mason 1980). Decision support tools are still49known today to be unsuitable for such wicked problems50(Mackenzie et al. 2006).51

Examples of the asymmetrical criteria problem in informatoinsystems include the selection of ideal approaches from com-peting organizational change theories. Such theories involvevastly differing assumptions about organizational behavior,structure, interaction with technology, etc. The complexity ofsuch selection decisions perplexes practitioners, and evensenior academic researchers in the field faced with similardecisions in formulating research designs (Holmström andTruex 2001).

The decision is further complicated where decision makersconcoct an “ideal” change method from a combination offeatures from multiple approaches. Such innovations raiseissues of consistency and necessarily involving risky,irreversible experimentation in live, working organizations.

The research described in this paper uses design science andthe concept of a theory nexus to distinguish logic, theories,and artifacts aimed at a general, operational decision tool thatapproaches the asymmetrical criteria problem.

Design Theory Nexus

There are differing opinions about what constitutes designtheories for information technology artifacts. Walls et al.(1992) specify two major components of IT design theories:a product component and a development process component.Each draws upon kernel theories (usually taken from thenatural or social sciences) in specifying prescriptive hypothe-ses that enable designers to evaluate whether the product andits development process satisfy the design theory. Goldkuhl(2004) specifies a need for multiple grounding of designtheories in external theories, reference theories, valuetheories, etc. Markus et al. (2002) take a more practical viewof design theories, using these theories to explain the means–ends relationship as a practical, prescriptively causal mech-anism to justify design components.

These experts agree, however, that design research involvesdesigns that are clearly driven by underlying theories.Theories are important elements when used as external, value,or kernel theories in IT artifact design for the purpose ofinsuring that work practices and IT remain correlated andsynergistic.

We are concerned with the design of an artifact to improvethe design of problem-solving approaches where a number ofcompeting approaches exist. In particular, we address suchsettings where each theory has a distinctive design logic (i.e.,responding to different parameters and constraints, focusing


MIS Quarterly Vol. 3X No. X/Month 200X 3

Criteria 1Criteria 2


020406080

100

Option 1 Option 2Option 3 Option 4

Multiple Criteria Decision



020406080

100





020406080

100





020406080

100


Multiple Criteria Decision1

Figure 1. Multiple Criteria Decisions Versus Asymmetric Criteria Decisions2

on different utility functions, and operating with different3command variables). The approach we adopt is similar in4inspiration to Van Aken’s (2005) distinctions between the5algorithmic versus heuristic application of technological rules:6A technological rule is “a chunk of general knowledge linking7an intervention or artifact with an expected outcome or8performance in a certain field of application” (p. 23). The9algorithmic application of a technological rule is highly10deterministic, similar to a statistical determination. The heu-11ristic application offers the rule as a design exemplar for12which a practitioner would develop a special variant for a13specific case. However, in our case, practitioners must not14only apply heuristic rules, they must also choose from among15rather different kinds of technological rules.16

17We propose a design theory nexus to improve the idealized18design of problem-solving approaches where a number of19competing approaches exist, and where each theory has20distinctive design logic. A design theory nexus is a set of21constructs and methods that enable the construction of models22that connect numerous design theories with alternative23solutions.24

25Nexus (and its verb form necto) are Latin terms for binding,26fastening, and joining. Nexus is retained in English as a term27for “a bond, link or junction; a means of connexion between28things or parts” (OED 1989). Particularly important for its29usage in design science research, it also connotes “a con-30nected group or series” (Traupman 1966).31

32Carroll and Kellogg (1989) used the term nexus to ack-33nowledge the interactive nature of theory and design artifacts.34Using examples from human–computer interface, they explain35

how the use of multiple psychological theories overdeterminedesigned artifacts, and that the exact effects of an artifact inrelation to the theories underlying its design can only berealized by experience with the artifact. A design theorynexus extends the deductive view of the relationship betweentheory and artifact to a reciprocal relation between thearticulation and rearticulation of theoretical claims anditerations of design (Carroll and Kellogg 1989).

The most interesting theoretical contribution of a designtheory nexus is its employment of alternative design theories(rather like alternative technologies, rules, and heuristics) forhelping decision makers in choosing which of the theories aremost suitable for their particular goals and their particularsetting. Each alternative solution relates to one or moreunique criteria that in turn imply a specific design theory.The design theory nexus is a nexus at which theories bindwith realities into a design solution, thereby providing a uni-que problem-solving approach that is particularly useful foraddressing ill-structured or wicked problems (see Figure 2).

March and Smith (1995) distinguish between design sciencesas involving building and evaluation while natural sciencesinvolve theorizing and justifying. Four design scienceelements are

1. Constructs are concepts that characterize a phenomenon2. Models describe tasks, situations, or artifacts3. Methods show how to carry out activities toward a goal4. Instantiations are physical implementations

We define five constructs: goals, environment, alternative de-sign theories, theory nexus, and design solutions (see Figure 2).



Goals

TheoryNexus

OrganizationalEnvironment

DesignSolution

ALT

ER

NA

TIVE

DE

SIG

N T

HE

OR

IES

Goals

TheoryNexus


Goals

TheoryNexus


DesignSolutionDesignSolution

ALT

ER

NA

TIVE

DE

SIG

N T

HE

OR

IES

12

Figure 2. General Design Theory Nexus3

Goals are “what the system is for” (Gregor and Jones 2007, p.432), or its utility function (Simon 1996), or its meta-5requirements (Walls et al. 1992, p. 40). Environment is a6construct to denote contingencies that are outside the control7of the people involved. Alternate design theories are each8referring to design theories using the imperative logic of9Simon (1996). The theory nexus is a connection point at10which design theories bind with realities into a design solu-11tion. Finally, a design solution is the result constructed from12highly dissimilar decision alternatives.13

The Design Theory Nexus Elaboration14of Preprogrammed Solutions15

16There are various approaches to the development of the best17alternative solutions when organizations must choose among18vastly differing alternative processes. The use of a design19theory nexus may elaborate a mechanism by which such20approaches can be extended to settings where criteria are21dissimilar. Thus for each alternative solution in a design22theory nexus one or more unique criteria are established to23formulate a specific design theory. Examples of familiar ap-24proaches include contingency theory and method engineering.25

Indeed, in certain settings, the best alternative may have beento simply make no real selection at all, but to allow theorganization to emerge organically.

Contingency theory arises from a broad array of studies, forexample, as a model explaining the high failure rate for infor-mation systems in developing countries (Heeks 2002). Thecore idea in contingency theory is that organizations wantingto optimize performance need to adopt the structure that fitsbest with the situation they are in—the contingencies giventhem. Donaldson (2001) defines contingency theory: “At themost abstract level, the contingency approach says that theeffect of one variable on another depends on some thirdvariable” (p. 5). Contingency models are advocated in difficult settings thatinvolve ambiguous goals, multiple perspectives, and informa-tion that is susceptible to multiple interpretations, especiallywhere interactive multi-person communication medium, suchas face-to-face meetings, are impractical (Galegher and Kraut1994). For example, contingencies such as communicationsupport, process structuring, and information processing(Zigurs and Buckland 1998; Zigurs et al. 1999) condition taskcomplexity at the group level in studies of task/technology fit(Van de Ven and Drazin 1985). Task/technology fit can have



direct impact on individual performance (Goodhue 1995;1Goodhue and Thompson 1995) and contingent factors such as2tool characteristics condition this fit (Lai 1999). In the adop-3tion of EDI, contingent factors include (1) the internal/4external environment; (2) the organizational readiness;5(3) potential positive financial impact, and (4) potential of6achieving workflow productivity (Khazanchi 2005).7

8Contingency theory has been criticized for having a too static9view of the relationship between structure and technology10(Barley 1990). It depends on shared characteristics of various11organizational settings for determining the criteria by which12one of an alternative set of problem-solving approaches may13be evaluated. Contingency theory predicts or programs the14selection by specifying these criteria. Operation of the theory15means matching the characteristics of the potential host16organization to the characteristics of the problem-solving17approach using the criteria. Such criteria may be said to be18symmetrical because they are similar from setting to setting19and approach to approach. This operation breaks down when20the problem-solving approaches or the problem settings them-21selves (or both) are so fundamentally different that their most22prominent characteristics are no longer usefully comparable.23In a worst-case scenario, the criteria for each approach and24the criteria for each problem setting will be unique. This25uniqueness prevents the pre-programming of practical26selection criteria.27

28For example, this situation can arise when organizations are29in a state of continual change, a condition known as emer-30gence. Such situations have been recognized as hostile31settings for mechanistic organizations and planned method-32ologies, and more conducive to organic organizations and33agile approaches (Burns and Stalker 1961). As a result, con-34tingency theory provides an avenue for selecting planned35approaches, but is less effective in emergent organizations36(Truex et al. 2000).37

38Method engineering provides an example of the degree to39which contingency theory dominates the solution space for40competing problem-solving approaches and the issues that41arise. It provides frameworks and processes for assembling42IS development methods from existing methodologies, inven-43tories of method fragments, and innovations (Brinkkemper et44al. 1996). With a focus on the formal models of computer-45aided method engineering (Odell 1996), computer-based46method engineering enables the rapid development of47computer-aided systems analysis and software engineering48(CASA/CASE) tools to uniquely match development settings.49

50The concept of a method fragment or method chunk is one of51the central method engineering premises (Rolland and Pra-52kash 1996). A method fragment is any element of a method-53

ology’s guidelines for its activities that is separated from themethodology. It is a concept, notation, tool, technique, etc.that is lifted from the framework of an overall methodologyand interjected in a specific work practice (Baskerville andStage 2001).

With an orientation toward formal modeling, fragmentselection process is a straightforward engineering decision,taken in a technical rational debating process (cf. Harmsen etal. 1994; Oinas-Kukkonen 1996). For example, a technique–task matrix can be used to map techniques such as prototypingand role modeling onto project tasks such as code, model,plan resources, test, etc. (Henderson-Sellers 2003). The frag-ment selection process extends to consider the rationaleunderlying method use. This rationale is foundational for theuse of evolutionary forms of method engineering. Suchevolutionary forms permit instances of methods to begenerated as business and technology changes (Rossi et al.2004). Field studies have shown that the continuing inte-gration of fragments permits situated method engineering asdevelopers learn about this changing business and tech-nological setting (Van Slooten 1996). It can be used to guidesoftware process improvement settings to develop agilemethods or object-oriented methods from method fragments(Henderson-Sellers and Serour 2005). Compound fragmentscan shape method components that express the transformationof particular artifacts along with the rationale for this trans-formation (Karlsson and Wistrand 2006). Componentizationleads to method configuration, a form of meta-method andsubdiscipline of method engineering that regards adjustmentsto configurable off-the-shelf methods (Karlsson and Ågerfalk2004). Such method components can transform human-oriented conceptual models into system-oriented andmachine-oriented design models (Wand 1996).

Although more sophisticated method structures (such asmethod components) have extended the original concept ofmethod chunks, and method engineering has more sophistic-ated concepts for integrating social, pragmatic, and semioticelements, method engineering necessarily operates as acontingency approach. Elements, although ever more sophis-ticated, are available for modification and integration basedon preprogrammed characteristics. It accordingly depends onsymmetrical criteria for selecting among method fragments,that is, settings in which the same criterion is used to adoptone method fragment while rejecting competing fragments.Consequently method engineering suffers from the samelimitations as contingency theory in settings with asym-metrical criteria.

Within method engineering, this issue is denoted as a “multi-perspective problem” (Nuseibeh et al. 1996, p. 268) arisingfrom potentially conflicting notions of development strategies,



notations, etc. that inhabit the thinking of various systems1development stakeholders. Meta-methods, such as method2engineering, must capture and manage these conflicts. This3process yields technological artifacts into which the social4world has become embedded (Ågerfalk et al. 2006). This5integration also extends to the pragmatic and semiotic6elements of the practical settings (Goldkuhl and Ågerfalk72004). But ultimately, symmetrical criteria are necessary to8guide the integration of these artifacts and elements. Baumoel9(2005) provides an example of the extensive research and10analysis necessary to construct such a criteria framework for11method engineering in selecting organizational change12approaches: a situated method construction approach. She13analyzed 89 cases and 23 change methodologies for the14purpose of developing an activity tree to guide the construc-15tion of change methods. By contrast, asymmetrical settings16are those in which the criterion for adopting one method17fragment, component, or element may be entirely different18from the criterion for adopting a competing method fragment,19component, or element. The theory nexus approach provides20an ideal setting for such asymmetrical settings.21

Methodology: Defining Three Levels2223

Design involves planning for the construction of artifacts.24While it is often contextualized in the fields of the humanities25(such as art, architecture, theater, etc.), its prominence in26fields such as economics, science, and engineering is growing27(Simon 1996). With this growing prominence, design for the28purpose of creating scientific and technical artifacts is29attracting increasing interest in the study of IT artifacts, an30interest simultaneously fueled by the need for more relevance31for economic studies of information technology (Orlikowski32and Iacono 2001).33

34Design science is a “science of the artificial” (Simon 1996)35that involves the scientific adaptation of means–ends36rationality to an environment. Designers, with ends in mind37(a goal), search for the means by which artifacts will achieve38those ends. Design science connects human aims to artifacts39that achieve those aims. Design science develops artifacts40that are acknowledged as subjects of natural law (Simon411996, p. 3). Within the IS discipline, design science is most42directly concerned with the design, specification, and evalua-43tion of technological artifacts.44

45At its foundations, design involves an imperative style of46logic, a search for alternatives, and the evaluation of design.47The logic of design is imperative because it is not a statement48of the way things “are,” but rather a statement of the way49things “should become.” Formal imperative logic is prob-50

lematic (see Simon 1996, p. 115), so design research substi-tutes an imperative adaptation of declarative logic. Once aproblem is expressed as a declarative paradigm, the designprocess is one of searching through alternative values amongthe logical terms in the paradigm until an alternative isdiscovered that satisfies the goals of the design. Simon classi-fied logical terms as command variables, fixed parameters,constraints, and utility functions. Fixed parameters representthe laws of the environment. Utility functions represent thedesign goals. The values of command variables expressdesign alternatives. Constraints are a special form of param-eter, one that may be selected according to the design goals.Under this imperative paradigm, design becomes a searchprocess: Given the constraints and fixed parameters, findvalues of the command variables that satisfy the utilityfunction (Simon 1996, p. 117).

Ultimately, the logic and the search should result in designedartifacts that can be introduced into the information systemcontext. Examples of such artifacts include algorithms,human–computer interfaces, system design methodologies,and protocols (Vaishnavi and Kuechler 2004). Design vali-dity is proven by an evaluation of these artifacts and theirachievement of the design goals (the satisfaction of the utilityfunction).

Walls et al. (1992, 2004) proposed a generalized designtheory that models the imperative logic paradigm, the searchfor alternatives, and the evaluation of the artifact. Theirdesign theory has five components: meta-requirements, meta-design, design method, kernel theories, and testable hypothe-ses. Their model is important because it operates at a meta-meta-level that provides a very general frame within whichclasses of design approaches (meta-designs) can be definedand described (see Table 1).

Gregor and Jones (2007) extend design theorizing into imple-mentation, which is consistent with the concept of the artifactas a theory nexus that involves rearticulation of theories inexperience. Their model defines eight components: (1) pur-pose and scope, similar to meta-requirements, (2) constructs,similar to parameters, variables, and constraints, (3) principlesof form and function, similar to utility functions, (4) artifactmutability, or predicted state changes of the artifact, (5) test-able propositions, similar to hypotheses, (6) justificatoryknowledge, similar to kernel theories, (7) principles of imple-mentation, similar to design method, and (8) expositoryinstantiation, which regards artifact implementation.

We operationalize Simon’s imperative logic, search, and eval-uation at three levels, similar to Sprague’s (1993) frameworkof DSS technology. The three levels of this framework are



Table 1. Comparing Walls et al.’s Design Theory and Simon’s Imperative Logic1

Design2Element3

Design TheoryComponents Description Imperative Logic

Product4 Kernel Theories Natural or social science theories governing designrequirements

Fixed Parameters

Product5 Meta-requirements Applicable class of goals Constraints and Utility Function

Product6 Meta-design Hypothetical class of artifacts meeting meta-requirements

Command Variables

Product7 Product Hypotheses For testing meta-design against meta-requirements Design Product Evaluation

Process8 Kernel Theories Natural or social science theories governing designprocess

Search Process

Process9 Design Method Procedure for constructing the artifact Search Process

Process10 Process Hypotheses For testing results against meta-design Search Process Evaluation

Table 2. Three Operationalization Levels in Our Research the Nexus Design Research11

Level12 Sprague (1993) Framework Adaptation in Nexus Design Research113 Specific DSS (1) Organizational Change Nexus instantiation

(2) User Involvement Nexus instantiation

214 DSS Generator General method for constructing a Design Theory Nexus

315 Fundamental Elements Design Theory Nexus

(1) the specific DSS that actually accomplishes the work by16enabling decision makers to solve real problems; (2) the DSS17generator, which is a package of elements that collectively18embody the capability to build a specific DSS; and (3) funda-19mental DSS elements, which are underlying technologies like20models, languages, graphics hardware, etc.21

22At the third (the highest) level, we develop the concept of a23design theory nexus as an approach to a class of problems in24which the design alternatives do not share similar criteria for25their adoption (a design search across dissimilar or asym-26metrical criteria). This framework allows us to instantiate a27method for designing solution design approaches for active28use in organizational settings (i.e., a general method for con-29structing a design theory nexus). This method comprises the30second level in the framework and provides an approach to31the specific class of problems requiring asymmetrical-criteria32design searches. This second level artifact, method to33construct (design theory) nexus instantiation, is our decision-34system generator. Using this method, designers can search a35design alternative space for ideal solutions, and even integrate36alternatives to form uniquely ideal solutions. Out of this37search, they can instantiate a design solution to operate in38their organizational setting. This design solution corresponds39

to the first level in the framework, a specific decision systemaimed at a real problem. We evaluate this approach using tworeal design settings, which leads to two different, specificimplementations of these artifacts. Table 2 compares theoperationalization of Sprague’s framework with our research.

General Method to Construct anInstance of a Design Theory Nexus

Design theories need principles of implementation to explainand guide the creation of the artifacts (Gregor and Jones2007). We adapted the basic process involving (1) alterna-tives evaluation, (2) analysis, (3) design, and (4) implemen-tation. We elaborated the design component into two distinctsteps in order to distinguish between assertion developmentand assertion evaluation (see below). This model led to afive-step method for constructing an instance of a theorynexus artifact.

The first step in constructing a nexus instantiation is ananalysis of the different approaches available in the given areaof innovation. This analysis required a survey of existing



literature and findings. Literature about these kinds of prob-1lem settings may be overwhelmingly large, inconclusive, or2both. In such cases, developers can supplement the literature3survey with one or more additional analytic techniques such4as a search conference or the qualitative interview study5described in the cases below.6

7The second step involves analyzing the alternative approaches8discovered in the first step, carefully mapping out the ideal9conditions under which each approach has the highest utility.10It may be the case that the approaches are analytically unequal11such that hardly any conditions are equivalent for any pairing12of the approaches. For example, this was the case in our13analysis of organizational change approaches. In other14settings many conditions may be equivalent, such as in the15case in our user involvement nexus instantiation.16

17The third step shifts the process from an analytic to a18constructive design of an artifact that can be used to indicate19whether the conditions identified in step 2 can be found in an20actual problem setting. The existing conditions are for-21mulated as assertions.22

23The fourth step is to design and develop a decision-making24process for evaluation of the formulated assertions.25Depending on the area of innovation, there may be more or26less facilitation required in this decision-making process. For27the organizational change nexus instantiation, we found it28ideal for the management group in each organization to29evaluate and agree upon the assertions because management30plays a key role in organizational change. A facilitated pro-31cess was necessary. For the user involvement nexus instan-32tiation, the problem area was closer to project managers33working early in an IT development project. It was ideal for34these project managers to evaluate the assertions because the35conditions were more equivalent, the process was simpler,36and less facilitation was required.37

38Finally the approaches, conditions, assertions, and the process39are integrated into a tool (an artifact) to support the evalua-40tion. In both cases, spreadsheet software proved adequate for41developing the tool. The purpose of the tool is to calculate42the “fit” for each approach in a given situation. We ultimately43calculated fit in both instantiation settings using a scale from440 to 100 percent, although other scales, such as a 1 to 5 matu-45rity scale, could be more suitable for other problem settings.46

Design Theory Nexus Instantiations4748

The design theory nexus originated in a project aimed at the49discovery of ideal approaches to organizational change for50specific organizational settings. It has subsequently been51

used for resolving a similar approach discovery process forimproving user involvement in IS development. Conse-quently we will describe these two projects in the followingsections.

Organizational Change Nexus Instantiation

The study of change is important in the management disci-pline. Academic and practitioner contributions to organiza-tional change have been built on empirical work in a widevariety of organizations and from such different perspectivesas psychology, sociology, and business. Examples of thiswork include descriptive accounts of change (e.g., Orlikowski1993), normative models to guide the change process (e.g.,Kotter 1996), theoretical models for understanding and ana-lyzing change (e.g., Markus and Robey 1988), typologies ofdifferent approaches to organizational change (e.g., Huy2001), and empirical studies of the success or failure ofchange (e.g., Hong and Kim 2002; Stelzer and Mellis 1998).

With the increasing interdependence of IT and organizationalstructure, behavior, and strategy, change in organizationsinevitably involves correlated change in organizational IT.Regardless of the causal direction (Markus and Robey 1988),the benefits of the coordinated design of both work practicesand related IT artifacts are long established (Ehn 1988;Mumford 1983). Theories of organizational change arecandidates for kernel theories in IT artifact design for thepurpose of insuring that work practices and IT remaincorrelated and synergistic.

There are many different foundational theories for organi-zational change. The process by which an organizationselects the appropriate approach to organizational change isoften ad hoc. Each approach has its advocates and adherents,and there is little comparative research for choosing amongsuch approaches. These approaches are so varied that com-parisons are usually drawn between only two (e.g., Beer andNohria 2000), three, or four alternatives (e.g., Huy 2001).

The clients in this case were from four larger organizations inthe financial sector. The case as described here was part of alarger, three-year research project operated by a researchconsortium of universities and client organizations with a totalproject budget of more than $5 million. The focus in theresearch consortium was improving the ability to improve.

An early experiment in one of the client organizations in-volved a team of three researchers and five practitioners indeveloping a very simple framework based on Beer andNohria’s (2000) theories E and O and the four ideal types of



intervention used by Huy (2001). This experience revealed1no effective way of establishing the situated conditions in2terms of the various theories, and therefore no way of estab-3lishing causal relationships between the conditions in the4organization and the theories. An early, very pragmatic5research question arose: How do we prescribe one of the6myriad change approaches to recommend in an organizational7setting?8

9We developed the fundamentals of the design theory des-10cribed earlier and began an implementation using the design11theory nexus. Following the five steps of the method to12construct the organizational change nexus instantiation, we13analyzed the different change approaches that participants in14the project had identified.15

16Step two involves analyzing the alternative approaches identi-17fied in the first step. From search conferences, we were able18to identify a number of high-level overall approaches. We19analyzed each approach in order to determine its distin-20guishing characteristics and to relate it to theories described21in the literature. In particular, we focused on the essential22goals of each change strategy (the ends) and on the essential23processes (the means). In this way, we refined the approaches24into 10 prominent organizational change strategies, summar-25ized in Table 3. These strategies represent the design theories26used as inputs to the nexus artifact. We then created a tool to27guide change managers in evaluating which of the 10 change28strategies would be most appropriate in their organizational29setting.30

Constructing the Organizational31Change Nexus Instantiation32

33Step three shifted to the constructive design of an artifact that34would guide designers in evaluating and choosing which of35the 10 design theories, or what combinations of the 10 design36theories, would be most appropriate. This design theory37nexus provided the analytical tool to bind the various organi-38zational change theories to actual organizational settings.39

40For each of the 10 organizational change theories (our41implementation-level design theories) in Table 3, we formu-42lated a number of assertions that were based on the prominent43characteristics of each design theory as expressed in the44literature referenced above. For example for the change45approach called commanding, we formulated the following46assertions (based on Huy 2001):47

481. Right now we need change to happen fast.492. It is primarily organizational structures that need to be50

changed.51

3. In the past we have had successes in requiring ordictating change.

As another example, for the change approach called option-ality, we formulated the assertions (based on Rogers 2003):

1. Our employees are self-aware and always have anopinion.

2. We have very knowledgeable employees that know theirareas well.

3. There are vast differences between the tasks of differentemployees.

All of the assertions were assembled into a query form imple-mented as a simple application in a common spreadsheetpackage shown in Figure 3.

This form embodies a design theory as statements repre-senting the conditions of the organization, the employees, thechange ahead, and the current use of metrics. These condi-tions can be compared to the conditions for each of the 10change approaches (Table 3) and the fit can be defined on ascale from 0 to 100 percent. The fit of these conditions canthen be measured by the degree to which these conditions arepresent in the organization based on the assertions in theform.

Following this scoring method, the fit for each of the 10change approaches can be determined. We let 50 percentrepresent an indeterminate item. Thus a fit calculated at 30percent means that the related approach doesn’t fit at all (it isunfit). We let 100 percent indicate a complete fit of allconditions. (It is unlikely that any approach will achieve 100percent in any actual situation).

Step four is to design and develop a decision-making processfor evaluation of the formulated assertions in the field. Achange strategy is heavily influenced by the vision or goalsfor the organization, as well as by whatever pertinent issuesare present in the organizational culture. These issues willdetermine whether change strategies succeed or fail, and suchissues belong to the top level of the organization.

We asked the management group in the IT division of thecompany to fill out forms similar to the one shown in Figure3. The managers worked individually at first, and afterwardwe facilitated a discussion of any major differences broughtforth in the individual assessments. For example, if onemanager responded “agree” to the assertion “In the past wehave had success in requiring or dictating change,” whereasanother manager says “partly disagree,” then we would bringout that discrepancy in the discussion and use it as a basis forfostering fresh agreement within the IT management group.



Table 3. An Overview of the Ten Organizational Change Strategies (Design Theories)1Name of2

Approach3 Approach definition Conditions LiteratureCommanding4

5Change is driven and dictated by(top) management. Managementtakes on the roles as owner,sponsor and change agents.

Where formal structures needs change. Where change is needed fast.

Huy (2001), specifically the ap-proach that is called commanding.The design and positioning schoolsas described by Mintzberg et al.(2002).

Employee6driven7

8

Change is driven from the bottom ofthe organizational hierarchy whenneeds for change arise amongemployees.

Where the need for change arises among theemployees.Where there is no need for a standardizedapproach; the result is more important thanthe process.Where an open management style that willallow change to arise from the bottom.

Andersen et al. (2001)on thegrassroots approach. Kensing(2003) and Kensing and Blomberg(1998) on participatory design.

Exploration910

Change is driven by the need forflexibility, agility, or a need toexplore new markets, technology orcustomer groups.

Where dynamic and complex surroundingsmakes it important to explore

Exploration (Benner and Tushman2003), or the organizational struc-ture called adhocracy (Mintzberg1983).

Learning driven1112

Change is driven by a focus onorganizational learning, individuallearning and what creates newattitudes and behavior.

Where there is a need for change in attitudesand/or behavior. Where the organization istalented in learning.Where relationships between means andgoals are unclear.

Huy (2001), specifically the ap-proach called teaching. Also thelearning organization (Senge 1990).

Metrics driven1314

Change is driven by metrics andmeasurements.

Where there are relatively stable surroundingsso measurements from the past can be usedto decide the future.Where the result of change is measurable.

Total quality management thinking(Oakland 2003). Six Sigmathinking (Pande and Holpp 2000).

Optionality1516

Change is driven by the motivationand need of the individual. It is to alarge degree optional whether theindividual takes the innovation intouse

Where target group is very diverse and haslarge individual differences. Where individuals that should (could) changeare highly educated, very knowledgeable andself-aware.

Rogers (2003) studied groups thattook innovations into use volun-tarily. Many of the models andtechniques in Rogers are valid forthis change approach.

Production17organized18

Change is driven by the need foroptimization and/or cost reduction.

Where you have relatively stablesurroundings. Where you have many homogeneousresources and workflows.

Scientific management, (Bennerand Tushman 2003), Huy (2001),specifically the approach calledengineering.

Reengineering19 Change is driven by fundamentallyrethinking and redesigning businessprocesses to achieve dramatic im-provements in critical, contempor-ary measures of performance, suchas cost, quality, service and speed.

Where a need exists for major change. Forexample when organization has ground to ahalt. Where nothing new happens. Where decisions are made but not carriedout. Where a crisis is eminent.

Bashein et al. (1994), Boudreauand Robey (1996), Davenport(1993), Hammer (1990), Hammerand Champy (1993), King (1994),Malhotra (1998), Willcocks et al.(1997).

Socializing2021

Change in organizational capa-bilities is driven by working withsocial relationships. Diffusion ofinnovations happens through per-sonal contacts rather than throughplans and dictates.

Where organizational skills and capabilitiesneeds to be developed. Where no unhealthy power struggles occur(so people can talk). Where employees thatcan be exemplars are available.

Cohen et al. (1972) and Huy(2001), specifically the approachcalled socializing.

Specialist22driven23

24

Change is driven by specialists,either with professional, technical,or domain knowledge. Examplesare a method or architecturefunction.

Where work has vast complexity and varietyso there really is a need for specialknowledge. Where there is access to necessaryspecialists, eventually by in- sourcing them.

Ciborra (2000), Mintzberg (1983),especially professional bureau-cracy, Simon (1973, 1983), Woods(1988), Woods and Hollnagel(1987).



Assertions/Statements1 AgreePartlyagree

Neithernor

Partlydisagree Disagree

The company and its context2The organizational context is very dynamic and demands frequent3change.4Too little is happening here - we have ground to a halt.5The organization is doing well and making money.6Coordination across the organization is lacking.7The work here is quite complex and depends on specialized8knowledge.9The knowledge and skill we have could be used more optimally,10through economies-of-scale and uniform processes11The employees12The best ideas for change come from the bottom of the13organization.14Our employees are self-aware and always have an opinion.15We have very knowledgeable employees who know their areas16well.17The actions of different employees can vary widely.18We depend on knowledge and specialists from outside.19Organizational change often happens without our contributing to it,20but with our consent.21We have unhealthy power struggles and signs of bad chemistry22between people.23Change in the organization24We make change often.25The changes we initiate always succeed.26Right now we need change to happen fast.27Right now there is much disagreement about what needs to be28changed and what directions we should take.29Primarily, organizational structures need to be changed.30Primarily, complex workflows need to be changed.31Primarily, attitudes and social relations need to be changed in the32future.33Up until now it has been the work with social relations that created34change.35In the past we have had success in requiring or dictating change.36The results of change are much more important than the change37process.38A specific (and separate) part of our organization takes care of39exploring new things.40Experience and “best practices” are always handed down to new41employees and new projects.42Metrics43We have a metrics program today—and we use the results.44It is entirely possible to measure the outcome or result of change.45

Figure 3. The Form Used to Measure Actual Conditions in an Organization46



As another example, if one person agrees that “Right now we1need change to happen fast” and four persons partly agree,2the partly-agree majority yields a calculation of 75 percent3(with agree being 100 percent). For the second question, “It4is primarily organizational structures that need to be5changed,” if two people answer “agree” and three people6answer “partly disagree,” we would initiate a facilitated dis-7cussion. When there was more than one field (in Figure 3)8separating the answers, then managers should explain to each9other why they answered as they did. In the discussions that10follow, their reasoning leads to agreement. In this example,11there was underlying disagreement about organizational12structure. But after discussing their disagreement, all five13decided on “partly agree.” This result is then used to calcu-14late the fit as being 75 percent for this question in relation to15commanding. The third question, “In the past we have had16successes in requiring or dictating change,” was unanimously17answered “disagree.” Disagree equals 0 percent fit. Finally,18we summed up the fit for commanding as 75% + 75% + 0%19divided by 3 = 50% fit.20

21The goal in this process is to determine a degree of fit of all2210 change approaches rather than to calculate a single ideal23approach. Because real settings are complex, we allow the24possibility (indeed the likelihood) that the ideal approach will25involve a combination of features from two or more of the26best-fitting approaches. In this way, our allowance of mul-27tiple, integrated change approaches is an extension of Van28Aken’s (2005) notion that technological rules can sometimes29best serve as heuristic exemplars in practice. The exact set of30features to be included in this combination must be deferred31to the change managers in the setting.32

Implementation and Evaluation3334

Step five draws the approaches, conditions, assertions, and the35process into the design of a tool (part of the implementation36artifact) to support the evaluation. Our goal indicates that the37justification and evaluation of the resulting artifacts should38focus on whether the artifact operates in the problem setting.39We use this simple operational goal because currently there40are no other alternatives for this class of problems. Without41competing solutions, making a better or worse performance42comparison is not possible. Therefore, a nexus instantiation43that can be shown to operate satisfactorily in helping the44people to select alternative approaches where asymmetrical45criteria prevail will be an improvement.46

47The design theory nexus is a human–machine problem-48solving system involving methods as well as an IT artifact.49Implementing and evaluating design solutions in a space50

where none currently operate might be best described as anexploratory form of design research. This exploratory usageis framed in a social-organizational setting highly charac-terized by change. Hevner et al.’s (2004, p. 88) guidelineconcerning design research rigor recommends that “theprinciple aim is to determine how well the artifact works, notto theorize about or prove anything about why the artifactworks.”

Therefore, to evaluate the organizational change nexus instan-tiation empirically, we used the tool in analyzing two realorganizations that were confronting change projects.Working through the research consortium, the four clientcompanies involved in the consortium had agreed toparticipate. We first used an early form of the organizationalchange nexus in Danske Bank in April–May 2004. This firstproject failed because it was too complicated to establishcausal relationships directly between contingencies andchange approaches.

Based on this experience, we turned the solution upside down,developing the set of 10 change approaches using searchconferences. For each change approach, we asked, underwhat circumstances would we recommend this approach?

In February 2005, we evaluated the first version of the designtheory nexus artifact presented in this paper. The evaluationtook place in PBS (Payment Business Services), a companythat specializes in electronic payment services. PBS employs750 people, of which half are working within the IT division.They develop and operate solutions for payment systems andare a leading supplier of such solutions and related services tobanks, private associations, and public institutions, processing1.3 billion transactions last year. A second evaluation—usingfor the first time exactly the design theory nexus presented inthis paper—took place in ATP in September 2005. ATP pro-vides solutions for pension and insurance applications fororganizations and individuals in the labor market. ATP isDenmark’s largest pension scheme and most of the country’sworkforce has accrued rights to one of ATP’s pensions. ATPhas more than a 1,000 employees, 350 of whom work with IT.

A third round of evaluations took place, in May 2006, in threeorganizations. Here we tried the nexus instantiation withindividual people, namely the CIO from each of three organi-zations: Housing, Energy and Communication (real namesanonymized at the request of the CIOs). In Table 4 we showthe results from the five evaluations.

For each organization, we looked at the one or two ap-proaches with the best fit. At PBS, the two top approachessurfaced with exactly the same fit. Accordingly, we decided



Table 4. Results from Using the Organizational Change Theory Nexus in Five Organizations†12 PBS ATP Housing Energy Communication

Reengineering3 31 28 30 40 28Optionality4 54 *71 *92 *92 50Socialization5 *60 59 82 28 63Specialist driven6 37 56 *96 58 63Exploration7 35 29 21 0 17Commanding8 34 *65 8 *63 75Employee driven9 55 18 23 60 63Learning driven10 *60 34 69 0 69Metrics driven11 42 40 58 23 *73Production organized12 56 58 63 50 *75

†Numbers are fit as measured between 0 and 100 percent. For each company, the two best fitting approaches are in bold and with a star in front.13

to recommend a combination of these two approaches. We14could have recommended three or four approaches but we15believe the complexity of combining more than two ap-16proaches would confuse rather than help the organization. In17this way, the organizational change nexus instantiation guided18PBS to a recommendation for a combination of the change19approaches socialization and learning driven. The nexus20instantiation helped the managers analyze the change ap-21proaches in relation to their organizational vision and setting.22Van Aken’s (2004, p. 227) notion of a “design exemplar”23applies. The exemplar can be only a general outline that must24be translated into proper form for the exact problem at hand.25

26The CIO (manager of the IT division) evaluated the results27positively and enthusiastically. He called the results a major28“Aha!” experience, and compared it to the wearisome ex-29changes with previous consultants who seemed to expect him30to “run around with a box of matches” to establish a burning31platform (referred to in phase 1 of Kotter 1996). A month32after the evaluation, PBS began implementation of the organi-33zational change strategy developed with its basis on the34organizational change nexus instantiation. They aimed to35achieve their strategic vision over the next 2 to 3 years. In36terms of the development of a useful change strategy, this37second application of the organizational change nexus38instantiation may be regarded as a complete success.39

40At ATP we discussed whether we should just recommend one41approach (the best at 65 percent of course), but based on the42success experience at PBS, where we recommended two, we43decided to similarly combine the top two approaches from the44evaluation at ATP. The combination of optionality and45commanding approaches was surprising and led to a discus-46sion among the ATP managers as to whether these two ap-47

proaches would fit together as a combination. Ultimately,ATP managers agreed that these could be combined byenabling managers to choose multiple change projects anddriving each initiative separately, using the optionalityapproach in some and the commanding approach in others. Inother words, managers select a few (two or three) initiativeswhere they personally drive the change (commanding) whileat the same time make it clear that other initiatives (many, infact) must be driven by the individuals’ or groups’ need andmotivation (optionality). In this final evaluation by ATP, theorganizational change nexus instantiation was also considereda success, in that it enabled ATP managers to analyze andunderstand complicated and alternative approaches to organi-zational change. They were able to confidently developdecisions about organizational change strategies relative tothe vision and setting at ATP. However, since ATP had for-mulated a rather bold strategic vision, the present study ofchange approaches and its evaluation is altogether too recentto provide indications about the actual impact of the results indriving this organizational change to success.

In the three companies using the organizational change theorynexus most recently, we conducted follow up interviews withtheir CIOs. Overall, they stated high levels of satisfaction, forexample, on a scale from 1 to 5 (with 5 being best), allevaluated the experience of using the nexus artifact at 4 or 5.

Evaluation Results

The organizational change nexus instantiation is an artifactthat provides an analytical tool to help organizational changemanagers formulate organizational change strategy. The de-sign theory used in designing this analytical tool is an example



Design theoriesof specific organizationalchange approaches

Goals/Strategic Vision


OrganizationalChange Nexus

Instantiation ChangeDesign theoriesof specific organizationalchange approaches

Goals/Strategic Vision


OrganizationalChange Nexus

Instantiation Change

12

Figure 4. The Strategic Change Nexus Design Theory3

of a design theory nexus. It draws from multiple sources of4external or kernel theories, including those taken from 105distinctly different change approaches. Analyzed together6with the organizational environment and vision, these theories7are rearticulated into specific change strategies for the setting8as shown in Figure 4.9

10What constitutes success in using the organizational change11nexus instantiation? We operationalized this measure based12on user retrospection and the binary decision by the organi-13zation to implement the results (or not). These are simple14measures of user satisfaction and impact. Overall, the design15theory nexus is a decision making aid. Like any other infor-16mation tool, there can be several alternative fundamental17measures of success, such as quality, use, user satisfaction,18and impact (DeLone and McLean 1992, 2003; Garrity and19Sanders 1998). We could operationalize these in our case as20increased speed of decision making, increased agreement on21decisions, lower or higher satisfaction with the decision, or22even the ability to arrive at a decision at all, and ultimately23better decisions—for example, measured by better outcomes24from implementing the decision.25

26Measuring better outcome would require a longitudinal study.27Both PBS and ATP, for example, had strategic visions28reaching 2 to 3 years ahead in time. Real world situations29typically have complexity too high for unequivocal measures30

of that type of success. Measuring increased speed wouldrequire that the decision, the horizon, and the scope of thedecision are exactly the same to enable us to compare hoursand calendar time used. However, organizational change isseldom discussed alone. In practice it is typically discussedtogether with a number of other issues on the agenda in theparticular organization. Therefore this measure of successwould quickly become distorted.

We settled for a simple, straightforward measure of successthat combined the subjective satisfaction of the involvedmanagers with a measure of whether the actions undertakenin the organization were in fact influenced by the evaluation.In all five cases, this turned out in favor of the organizationalchange nexus instantiation.

User Involvement Nexus Instantiation

User involvement can be defined as “participation in thesystem development process by potential users or their repre-sentatives” (Barki and Hartwick 1989, p. 53). Many haveidentified lack of fulfillment of user needs in IT projects as amajor problem. Clavadetcher (1998, p. 30) summarized theproblem, “Quite simply, the software we build does not meetour customers’ needs...we fail to adequately manage the soft-ware development process. User-developer communicationbreaks down.”



A recent analysis of failing public projects concluded that the1involvement of users in failing projects was flawed in key2ways (Bonnerup 2001). In some cases, too many users were3involved. There were also examples of user–developer4communication breakdowns mainly because the abstraction5level of the communication became too high for the users.6

7Traditionally, user involvement has been found to be a major8factor in systems’ success. This finding builds on theories of9participative decision making (Barki and Hartwick 1994) and10the user role in organizational change (Baroudi et al. 1986).11There is not total agreement on the benefits of user involve-12ment (Ives and Olson 1984). Cavaye (1995) studied the rela-13tionship between user involvement and success and found that14the relationship was more complex than just more user15involvement leading to more success. One explanation may16be that user involvement varies within each stage of the17development process (Newman and Noble 1990). Further,18Robey and Farrow (1982) point out that participation without19influence is unlikely to lead to success. Noyes et al. (1996)20highlight the difficulty in deciding how to involve users, and21where they are involved, the difficulty in using them to their22full potential. Thus it seems that user involvement is very23important but also very hard to do in practice.24

25As with organizational change, there are also many different26fundamental theories for user involvement. Bødker et al.27(2004) provide an excellent overview of a number of these28techniques for user involvement. For example, user involve-29ment through paper-based prototypes is recommended early30in the development process in order to elicit requirements31from the users. Another example is Saleem (1996), who32recommends user involvement when task uncertainty is high.33

34The process by which an IT project selects the appropriate35approach and time for user involvement is often ad hoc. We36set out to develop a Nexus instantiation for user involvement.37

Field Study3839

This study engaged three researchers: one tenured professor40(an author of this paper) and two students writing a disser-41tation on user involvement. In order to build a design theory42nexus instantiation for user involvement, we researched43methods and techniques for user involvement. Again we44followed the method construct as described above. As step45one, we identified hundreds of research papers and books on46this subject and developed a set of alternative methods and47techniques for user involvement. Based on this set of tech-48niques, we then conducted a field study in 10 companies49using exploratory interviews followed by semi-structured50

interviews. We then initiated step two of the method con-struct, analyzing the alternative approaches discovered in thefirst step. The combined findings from our literature studyand our field study indicate that there are three major influ-ences on user involvement: complexity, resources and useridentity.

Complexity. The complexity issue is characterized by sixmajor factors that give rise to complexity. These includedomain knowledge, task complexity, size, technical knowl-edge, perceived change, and the type of system.

The first factor leading to complexity is the degree of knowl-edge held by the developers in the domain in which the userswork. Developers need knowledge about the existingworking styles in order to develop the right system for futurework. Lack of domain knowledge among developers is oneof the three key problems of systems development when thesystem is large (Curtis et al. 1988). Where developers lackknowledge of the users’ work, they need to observe andexperience the users while they do their work (Kensing andMunk-Madsen 1993). A high degree of user involvement isneeded where developers lack domain knowledge (Saleem1996), and this involvement is less urgent where developershave strong domain knowledge. Cavaye (1995) notes thatuser involvement is less urgent if user requirements are well-known.

The second factor is task complexity. Where tasks arestructured at the operational level, the demand for userinvolvement is minimal. Where tasks are unstructured andonly described at the strategic level, the need for userinvolvement is urgent (Cavaye 1995). If a system is wellstructured and well defined, then it is not necessary to involveusers for purposes of system quality (Ives and Olson 1984)but perhaps for system acceptance.

Size is the third factor we found that influences complexity.Size is one of the main influences both on system risk(Applegate et al. 1999) and complexity (Cavaye 1995). Thedistinction between large and small will, of course, vary fromsetting to setting; we asked participants in our field study howthey would distinguish large from small systems.

The fourth influence factor on complexity was knowledge ofthe technology. Lack of technological knowledge increasescomplexity. This factor is a known area that increases risk(Applegate et al. 1999), and we know that there is a need fora balance between the complexity of the application and thecomplexity of the technology (Nicholas 1985). User involve-ment may be unsuitable when considerable technical expertiseis needed (Ives and Olson 1984).



The fifth influence factor is perceived change for stake-1holders. If change is perceived to be considerable, then there2is an advantage in involving users (Cavaye 1995).3

4Finally the sixth influence factor is the type of system. For5example, decision support systems involve more complex6workflows and a higher degree of user involvement may be7needed (Hawk and Dos Santos 1991). When developing8standard applications, such as a payroll system, a small degree9of user involvement may suffice (Saleem 1996).10

11Resources. Three major influence factors developed from the12literature review that regarded resources. The first factor was13management support, which will increase the prospect of user14involvement (Cavaye 1995). Where senior managers are only15moderately positive, or worse still, resistant, then risk16increases considerably (Applegate et al. 1999). Management17must support user involvement in both word and deed, along18with commanding results from the involvement of users.19

20The second factor involves resources in the form of adequate21budget and staff for the project (Cavaye 1995). When a22project has limited resources, then users will be less involved23simply because user involvement is expensive.24

25The third factor is time, especially with regard to whether the26project has a hard or a soft deadline. Projects with hard27deadlines can exclude effective engagement for user involve-28ment (Wilson et al. 1997).29

30User Identity. The degree to which the users are personally31known to the developers depends on the type of development.32User identity is classified as named or nameless users33(inspired by Grudin 1991). The most practical measure of this34identity is whether the developers can name the users, or at35least to obtain the names of the users in advance. In product36development, developers do not know their users until the37users buy the product. It is possible to identify potential users38such as representative users of the last version of a product,39but the complete set of users necessarily remain nameless40until they acquire the product.41

Eight Design Theories on User Involvement4243

Step three of our method construct focused on the construc-44tive design of a nexus instantiation. The literature review and45the field study led to the identification of eight prominent46project types combining the three dimension (complex–not47complex, many–few resources available, named–nameless48users) two-by-two-by-two. Again, as with the organizational49change approaches, we aimed at developing a design theory50for each of the project types.51

For each design theory we then analyzed the ideal setting todetermine which of the techniques best fit the factor configu-ration. Following this analysis, we created a nexus instantia-tion that could guide system developers and project managersin deciding which of the eight design theories and whatcombination of techniques would be most appropriate.

In the process it became evident that the alternative ap-proaches can be selected with symmetrical criteria. Projectsize, complexity, available resources, and user identity arecriteria that are all shared among the competing approaches.While unpredicted, this symmetry made this case ideal forevaluating a design theory nexus instantiation in settingswhere criteria are symmetrical.

Constructing the User InvolvementNexus Instantiation

The fourth step in our method construct is to design anddevelop a decision-making process for evaluation using for-mulated assertions. In combining the influence factors of userinvolvement into the eight design theories, we formulated anumber of assertions that would reveal whether the conditionswere present in an organizational setting. These assertionswere based on the prominent characteristics of each designtheory as expressed in the literature and in the field study. Allof the assertions were assembled into a query form using aspreadsheet package. The complete form is shown inAppendix A.

The design theory is represented in this form in that thestatements represent an expression of the conditions of projectcomplexity, resource situation, and development type in termsof named or nameless users. These conditions are derivedfrom the conditions for each of the eight project types(Appendix A) and the fit as defined on a scale from 0 to 100percent. For example, if we take an example set of conditions

1. When project is complex2. When many resources available3. When users can be named

The fit of these conditions can then be measured by thedegree to which these conditions are present in the project.Some items fit with agreement (the better the fit, the morethey agree) while others fit with disagreement (the better thefit, the more they disagree). Following this scoring method,the fit for each of the eight project types can be determined.The goal in this process is to determine a degree of fit of alleight project types rather than to calculate a single ideal type.Because real settings are complex, we allow the possibility(indeed the likelihood) that the best approach will involve a



Table 5. Evaluation (Part) of Workshop1

Evaluation of Nexus2Don’t know

My expectations meet3 1 10 1 4.0Value of workshop4 1 7 3 1 3.7The Nexus (spreadsheet)5 3 4 5 4.0Derived schedule with milestones6 3 4 5 4.0

7 Nothing Little Some Partly A lotDon’t know

Deviation: Your plan in relation to ”standard8plan” 9 2 4 4 2

To what degree will you expect to use the derived10plan after today11 2 3 5 1 1

combination of features from two or more of the best fitting12project types.13

Implementation and Evaluation1415

Finally the fifth step in our method construct is where it all16comes together in an artifact to support the evaluation. For17the user involvement nexus instantiation we invited com-18panies to a workshop in June 2006. People from 12 com-19panies participated in a workshop that lasted 6 hours. All20workshop participants derived project plans from the user21involvement nexus instantiation. The workshop concluded22with an evaluation by the participants. Overall, the design23nexus instantiation is a tool to aid decision making. We24sought a simple and quick evaluation of impact. The suita-25bility of the user involvement nexus instantiation was mea-26sured according to a participant retrospective and the degree27of their intention to implement the results in practice. These28two measures provided simple, but effective metrics of the29impact of the nexus instantiation on participants and their30future behavior.31

32On a scale from 1 (worst) to 5 (best), we asked the workshop33participants to evaluate the tool and the plan as well as34satisfaction with the workshop as a whole. Table 5 shows35both the form and the results of the evaluation.36

37Three conclusions about the impact of the user involvement38nexus instantiation are indicated from the evaluation. First,39the workshop was deemed very valuable (3.7 average) but the40user involvement nexus instantiation was even more valuable41(4.0). Second the participants were quite satisfied with the42user involvement plans that they derived when using the43

nexus instantiation (4 on a 1 to 5 scale). Third, and perhapsmost importantly, nearly all participants deviated from thestandard plan that was linked by the best fit to the projecttype, and nearly all participants expected to use the plansderived from the nexus instantiation, although 2 out of 12only expected “little” use. Overall, the evaluation indicatedthat the user involvement nexus instantiation delivered theoutcomes expected in accordance with its design logic.

Discussion

The research above developed the design theory nexusconcept at three levels as shown in Figure 5.

Learning from the Instantiations

The importance of the operations using the both the organi-zational change nexus instantiation and the user involvementnexus instantiation lies in the implications for the designtheory nexus’s scope. The first example, the organizationalchange nexus instantiation, provides evidence that nexusinstantiations offer a general solution to the asymmetricalcriteria problem. But does this instantiation offer an elabora-tion of existing approaches, such as contingency theory, or isit an alternative? Does the design theory nexus approachwork for asymmetrical criteria problems only, or does it workfor both symmetrical and asymmetrical problem settings?

An answer was given by the second instantiation, the userinvolvement nexus instantiation. In short, the answer was thatit was possible to develop operational instantiations for both



Design Theory Nexus

OrganizationalChangeNexus

Instantiation

UserInvolvement

NexusInstantiation

N.N:Nexus

Instantiation

N.N:Nexus

Instantiation

N.N:Nexus

Instantiation

N.N:Nexus

Instantiation

Method toConstruct

Design Theory Nexus

OrganizationalChangeNexus

Instantiation

UserInvolvement

NexusInstantiation

N.N:Nexus

Instantiation

N.N:Nexus

Instantiation

N.N:Nexus

Instantiation

N.N:Nexus

Instantiation

Method toConstruct

12

Figure 5. The Design Theory Nexus at Three Abstraction Levels3

kinds of settings. This work suggests that the design theory4nexus approach is more universal than previous approaches to5contingency theory, because it can operate in both sym-6metrical and asymmetrical settings. This wider scope means7that a project can start without knowing at the outset whether8the criteria will be symmetrical or asymmetrical. There is9evidence that a design theory nexus can be instantiated and10operate in both kinds of settings.11

Learning from the Design Theory Nexus1213

Hevner et al. (2004) distinguish between two paradigms that14characterize much of the research in the IS discipline:15behavioral science and design science. The behavioral16science paradigm seeks to develop and verify theories that17explain or predict human or organizational behavior, thus the18objective is problem understanding. The design science19paradigm seeks to extend the boundaries of human and20organizational capabilities by creating new and innovative21artifacts, thus the objective is problem solving.22

23Hevner et al. identify truth and utility as the core outcome of24the two different paradigms. 25

26Behavioral science addresses research through the27development and justification of theories that explain28or predict phenomena related to the identified29business need. Design science addresses research30through the building and evaluation of artifacts31designed to meet the identified business need. The32

goal of behavioral science research is truth. Thegoal of design science research is utility (p. 79-80).

Hevner et al. presented a design science research framework.At the core was a cycle between the build/develop and justify/evaluate activities. In relation to Hevner et al., we developedtwo different applications, namely one (instantiation) forchange approaches and one (instantiation) for user involve-ment. Both of these applications are relevant for people, theyare useful in organizations, and they provide an IT artifact(technology). In Figure 6, this is shown as the arrow from themiddle to the left.

However, our design theory nexus also contributed to theknowledge base. As noted, we were looking at difficult deci-sions where approaches such as MCDM (Belton and Stewart2001), AHP (Saaty 1988), and MAUT (Keeney and Raiffa2002) have been tried. We have added a design theory nexusthat can be used for highly dissimilar approaches. We havealso discussed how existing theories on contingency theoryand method engineering are related to the nexus. Further wehave discussed existing design theory (Hevner et al. 2004;March and Smith 1995; Simon 1996). In Figure 6, our contri-bution to the existing knowledge base is shown as an arrowfrom the middle to the right.

Coping with Uncertainty

A design theory nexus copes with uncertainty rather thanmanages it. It thrives in high-change environments because



Build

Evaluate

IS managers facing highly

dissimilar alternative

approaches to decisions

Knowledge Base1. MCDM, AHP, MAUT etc.2. ContingencyTheory3. Method Engineering4. Existing Design Theory

Businessneeds

Applicableknowledge

Applications

Change ApproachesUser Involvement

Additions:

Design Theory Nexus for highly dissimilar approaches

Build

Evaluate

IS managers facing highly

dissimilar alternative

approaches to decisions

Knowledge Base1. MCDM, AHP, MAUT etc.2. ContingencyTheory3. Method Engineering4. Existing Design Theory

Businessneeds

Applicableknowledge

Applications

Change ApproachesUser Involvement

Additions:

Design Theory Nexus for highly dissimilar approaches

12

Figure 6. The Contribution in Form of Applicatoins and Additions to Knowledge Base3

the entire theoretical framework for determining action is4open to negotiation. New reference theories can be added to5the Nexus, theories whose selection might be based on6entirely different criteria, without changing the overall nexus7framework. This aspect of the design theory nexus is best8illustrated by the case of the organizational change nexus9instantiation, where there were fundamental differences10between the criteria under which a particular theory would be11selected as a driver.12

13A design theory nexus differs from contingency theory in the14way that it promotes the integration of appropriate aspects of15different alternative theories that might be suitable for the16situation. The design theory nexus together with the method-17to-construct may surface multiple alternatives, with indica-18tions of the degree of fit for the situation. Alternatives with19similar fit (although perhaps based on differing assumptions)20can be examined more closely for the development of hybrid21approaches that combine features of multiple alternatives.22This aspect of the design theory nexus is well illustrated by23both the organizational change and the user involvement24nexus instantiations.25

26In these ways, a design theory nexus has promise of helping27resolve the primary limitation of contingency approaches.28This limitation regards the difficulty in estimating precisely29the factors involved in a contingency model (often called the30interaction terms because it is the interaction of the factors31that are interesting in a given situation). These interaction32terms grow quickly irrelevant, “less than one-quarter of the33

interaction terms investigated…have been found to be signi-ficant” (Chin et al. 2003, p. 212). As a result of such flaws,the usefulness of contingency models is open to question(Weill and Olson 1989). Indeed, empirical research aroundcontingency theory continues to provide inconsistent results(Cavaye 1995).

A design theory nexus operates well with both asymmetricalcriteria and symmetrical criteria. This feature opens thepossibility for the use of a design theory nexus within futuremethod engineering systems as well as less formalizeddevelopment settings.

Design Theory Productions

This study helps illuminate the process by which the designtheory approach can generate theory. Existing theory bindswith experience to generate a modified, reoriented, or entirelynew theory as an emergent byproduct of the process ofdesign. Design research is a setting in which theory andexperience are engaged in generating new artifacts intendedto change social and/or physical reality in purposeful ways.It is not so much a logical formulation process as it is anepiphany that follows a clash of old ideas in new situations.

Theory development in design research centralizes the de-signed artifact as a means of changing social and/or physicalreality. This design artifact is an embodiment of the designtheory, and its operating influence on its setting is the



phenomenon of interest. At the general design theory nexus1level, the theory arises as a consequence of the inability of2contingency theory to provide ineffective selection mech-3anisms for settings where asymmetric criteria dominate. This4clash between theory and experience provides the kind of5noisy setting where more satisfactory designs arise. In the6case of the organizational change nexus instantiation, the7theory arises in the potential clash between organizational8change theories and the organizational reality. The outcome9is the set of organizational change theories that may be inte-10grated together to develop a unique organizational change11theory for the exact setting at hand. Such a unique construc-12tion results from the process in which various organizational13change theories bind with each other and the social/physical14reality.15

Validity of Approach1617

Hevner et al. (2004, p. 83) proposed a view for excellence in18design science research in the form of seven guidelines that19are useful for understanding, executing and evaluating design20science.21

221. Must produce a viable artifact.232. Produces technology-based solutions to relevant24

business problems.253. Evaluation that demonstrates of utility, quality, and26

efficacy.274. Research contribution of the design artifact, founda-28

tions, or methodologies.295. Rigor in construction and evaluation method.306. A problem-situated means-ends search for an31

effective artifact.327. Communication to both technical and managerial33

audiences.3435

In relation to these particular guidelines, the design theory36nexus is a designed artifact in the form of constructs, a model,37a method-to-construct and two examples of instantiations38(guideline 1). It provides relevance to an important business39problem, namely how to make decisions as an IS manager40when facing a problem setting with many competing, but41highly dissimilar, alternative approaches, by helping resolve42a multiplicity of alternative approaches into a more cohesive43direction (guideline 2). The utility and efficacy of the design44theory nexus was evaluated in two projects in which a45method-to-construct was applied and two artifacts (instan-46tiations) developed. These provided observational evidence47from field studies to indicate that a nexus instantiation was48operational and valued in practice (guideline 3). The organi-49zational change nexus instantiation provided practical contri-50

butions as an artifact that helped to solve a complex problemcommon to many organizations, and it provided a researchcontribution by extending the concept of a design theorynexus beyond the HCI discipline (guideline 4). Our study didnot adopt a strictly scientific form of design science, and it didnot adopt tightly structured deductive design theory andhypotheses. The approach adopted an interpretive socialresearch stance, one widely accepted as a rigorous form ofresearch (guideline 5). The participative nature of theapproach provided the mechanism for searching and utilizingthe available means to reach the desired ends (guideline 6).Finally the studies provided evidence that the design theorynexus can be presented to both a technology-oriented and amanagement-oriented audience (guideline 7). For example,a number of change agents were present in the three caseswhere the organizational change instantiation of the nexusartifact were evaluated. The evaluation showed that manage-ment in the organizations was more interested in the overallchange strategy.

Conclusion and Future Research

A common but intractable problem faced by many managersinvolves the selection of an ideal approach to a problemsetting in the context of many competing, but highly dis-similar, alternative approaches. In particular, we havefocused on settings where the available alternatives aredifferent in essential ways. These essential differences arisebecause the competing approaches are based on theories withvastly differing assumptions about organizational behavior,structure, interaction with technology, etc. These problemsettings lack comparative research that helps select the mostideal design theory for the precise problem setting at handbecause the theoretical basis is different. Unbiased analyticalcomparisons of such approaches are impossible because theanalytical criteria will relate well to only a subset of thealternatives.

We used concepts from design research to develop a genera-lized approach to these kinds of problem settings. Becausethe competing alternatives were related to competing theories,our approach regarded the alternatives as competing designtheories. From this perspective, competing alternatives eachhave distinctive design logic (i.e., responding to differentparameters and constraints, focusing on different utilityfunctions, and operating with different command variables).The problem then becomes one of design research: searchingthe available design alternatives for the best components indeveloping the best design for the solution. We created adesign theory nexus at three levels (fundamental, method-to-construct, instantiation) for evaluating, selecting, and com-



bining the competing alternative approaches to the problem.1The design theory nexus provides a viable conceptualization2that enables the construction of effective problem-solving3artifacts.4

5Areas for future research develop from our study. We only6applied the instantiations of the design theory nexus within IT7organizations (or the IT part of organizations). Generally,8only IT people were involved. While broader usefulness is9promising, the usefulness of the approach in non-IT areas and10with non-IT people remains unproven. The IT artifact pro-11duced was implemented as a spreadsheet application12specifically for each instantiation of the design theory nexus.13Based on these successes, it seems possible to develop a14general version of the design theory nexus IT artifact that15would support the process of creating a design theory nexus16artifact. Creating the technological artifact from scratch for17each instance of a nexus would no longer be necessary.18Further work is needed to design and develop such an artifact.19There is also a need to exercise the design theory nexus as20well as the method-to-construct in more and larger organi-21zations. Our experiences have been with a relatively small22number of organizations, each involving a relatively small23number of people. It takes a great deal of planning and time24to exercise an instance of a design theory nexus. In general,25the intractable nature of the ideal problem setting for such a26nexus, and the complex nature of the underlying and27competing design theories, does not lend itself to abstract28experiments or surveys. The involvement of real organiza-29tions is necessary, requiring senior management commitment30and a substantial amount of work to arrange the research.31

32There are many implications that can be drawn from the33promising results of this study. For example, the academic34discipline of IS has been criticized for producing research for35which the direct relevance for practice is unclear. To a36degree, this research might become more clearly relevant if37organized for practical application through the use of a design38theory nexus in certain problem areas where complex and39conflicting IS theories compete in a solution space. The40design theory nexus might be useful for directly associating41intractable IS problems with potential solutions found in the42IS research literature.43

44While further research is needed to demonstrate further areas45and purposes for the design theory nexus, it is clearly a46promising and general solution for the selection of an ideal47problem solving approach where the context includes many48competing, highly dissimilar alternatives. The nexus connects49theory to theory, and theory to practice, with highly pragmatic50results. We believe it to be an interesting and valuable51exemplar of design science research.52

Acknowledgments

We thank the ATP, Danske Bank, PBS, SimCorp, and DELTASoftware Engineering for allowing us to develop and evaluate thedesign theory nexus for organizational change. We gratefullyacknowledge the research assistance of Pia Eder and Lise L. Hansenfor their assistance in developing and evaluating the userinvolvement nexus described in this paper.

References

Ågerfalk, P. J., Goldkuhl, G., Fitzgerald, B., and Bannon, L. 2006.“Reflecting on Action in Language, Organisations andInformation Systems,” European Journal of Information Systems(15:1), pp. 4-8.

Andersen, C. V., Krath, F., Krukow, L., L., M., and Pries-Heje, J.2001. “The Grass Root Effort,” in: Improving Software Organi-zations – From Principles to Practice, L. Mathiassen, J. Pries-Heje, and O. Ngwenyama (eds.), Boston: Addison-Wesley, pp.83-98.

Applegate, L., McFarlan, F. W., and McKenney, J. L. 1999. Cor-porate Information Systems Management: Text and Cases NewYork: Irwin–McGraw Hill.

Barki, H., and Hartwick, J. 1989. “Rethinking the Concept of UserInvolvement,” MIS Quarterly (13:1), pp. 55-63.

Barki, H., and Hartwick, J. 1994. “Rethinking the Concept of UserInvolvement, and User Attitude,” MIS Quarterly (18:1), pp.59-79.

Barley, S. R. 1990. “The Alignment of Technology and Structurethrough Roles and Networks,” Administrative Science Quarterly(35:1), pp. 61-103.

Baroudi, J. J., Olson, M. H., and Ives, B. 1986. “An EmpiricalStudy of the Impact of User Involvement on System Usage andInformation Satisfaction,” Communications of the ACM (29:3),pp. 232-238.

Bashein, B. J., Markus, M. L., and Riley, P. 1994. “Preconditionsfor BPR Success: And How to Prevent Failures,” InformationSystems Management (11:2), pp. 7-13.

Baskerville, R., and Stage, J. 2001. “Accommodating EmergentWork Practices: Ethnographic Choice of Method Fragments,” inRealigning Research and Practice in Is Development: The Socialand Organizational Perspective, B. FitzGerald, N. Russo and J.I. DeGross (eds.), New York: Kluwer, pp. 12-28.

Baumoel, U. 2005. “Strategic Agility through Situational MethodConstruction,” in European Academy of Management 5th AnnualConference on Responsible Management in an Uncertain WorldOslo: TUM Business School.

Beer, M., and Nohria, N. 2000. Breaking the Code of Change (1st

ed.), Boston: Harvard Business School Press.Belton, V., and Stewart, T. J. 2001. Multiple Criteria Decision

Analysis—An Integrated Approach, Dordrecht, The Netherlands:Klüwer Academic Publishers.

Benner, M., and Tushman, M. 2003. “Exploitation, Exploration,and Process Management: The Productivity Dilemma Re-visited,” Academy of Management Review (28:2), pp. 238-256.



Bødker, K., Simonsen, J., and Kensing, F. 2004. Participatory IT1Design: Designing for Business and Workplace Realities,2Boston: The MIT Press.3

Bonnerup, E. (ed.). 2001. Store Statslige IT-Projekter - Hvordan4Gør Man Det Bedre? (“Large Public IT Projects - How to Do It5Better?”), Teknologirådet (Danish Technology Council).6

Boudreau, M.-C., and Robey, D. 1996. “Coping with Contradic-7tions in Business Process Re-Engineering,” Information Tech-8nology and People (9:4), pp. 40-57.9

Brinkkemper, S., Lyttinen, K., and Welke, R. (eds.). 1996. Method10Engineering, London: Chapman & Hall.11

Burns, T., and Stalker, G. M. 1961. The Management of Inno-12vation, London: Tavistock.13

Carroll, J. M., and Kellogg, W. A. 1989. “Artifact as Theory-14Nexus: Hermeneutics Meets Theory-Based Design,” CM15SIGCHI Bulletin—Proceedings of the SIGCHI Conference on16Human Factors in Computing Systems: Wings for the Mind17(20:SI), March, pp. 7-14.18

Cavaye, A. L. M. 1995. “User Participation in System Develop-19ment Revisited,” Information & Management (28:5), pp.20311-323.21

Chin, W. W., Marcolin, B. L., and Newsted, P. R. 2003. “A Partial22Least Squares Latent Variable Modeling Approach for Measuring23Interaction Effects: Results from a Monte Carlo Simulation24Study and an Electronic-Mail Emotion/Adoption Study,”25Information Systems Research (14:2), pp. 189-217.26

Churchman, C. W. 1967. “Guest Editorial: Wicked Problems,”27Management Science (14:4), pp. B141-B142.28

Ciborra, C. U. 2000. From Control to Drift. The Dynamics of29Cooporate Information Infrastructures, Oxford, UK: Oxford30University Press.31

Clavadetscher, C. 1998. “User Involvement: Key to Success,”32IEEE Software (15:2), pp. 30-32.33

Cohen, M. D., March, J. G., and Olsen, J. P. 1972. “A Garbage Can34Model of Organizational Choice,” Administrative Science35Quarterly (17:1), pp. 1-25.36

Courtney, J. F. 2001. “Decision Making and Knowledge Manage-37ment in Inquiring Organizations: Toward a New Decision-38Making Paradigm for DSS,” Decision Support Systems (31:1),39pp. 17-38.40

Curtis, B., Krasner, H., and Iscoe, N. 1988. “A Field Study of the41Software Design Process for Large Systems,” Communications42of the ACM (31:11), pp. 1268-1287.43

Davenport, T. H. 1993. Process Innovation: Re-Engineering Work44through Information Technology, Boston, MA: Harvard Business45School Press.46

DeLone, W., and McLean, E. 1992. “Information Systems Success:47The Quest for the Dependent Variable,” Information Systems48Research (3:1), pp. 60-95.49

DeLone, W. H., and McLean, E. R. 2003. “The Delone and50McLean Model of Information Systems Success: A Ten-Year51Update,” Journal of Management Information Systems (19:4), pp.529-30.53

Donaldson, L. 2001. The Contingency Theory of Organizations.54Thousand Oaks, CA: Sage Publications.55

Ehn, P. 1988. Work-Oriented Design of Computer Artifacts (2nd56ed.), Stockholm: Arbetslivscentrum.57

Galegher, J., and Kraut, R. E. 1994. “Computer-Mediated Com-munication for Intellectual Teamwork: An Experiment in GroupWriting,” Information Systems Research (5:2), pp. 110-138.

Garrity, E. J., and Sanders, G. L. 1998. Information Systems Suc-cess Measurement, Hershey, PA: Idea Group Publishing.

Goldkuhl, G. 2004. “Design Theories in Information Systems - aNeed for Multi-Grounding,” Journal of Information TechnologyTheory and Application (6:2), pp. 59-72.

Goldkuhl, G., and Ågerfalk, P. 2004. “IT Artefacts as Socio-Pragmatic Instruments—Towards an Integration of the Prag-matic, Social, Semiotic and Technical,” Workshop on Under-standing Sociotechnical Action, Napier University, Edinburgh.

Goodhue, D. L. 1995. “Understanding User Evaluations of Infor-mation Systems,” Management Science (41:12), pp. 1827-1844.

Goodhue, D. L., and Thompson, R. L. 1995. “Task-Technology Fitand Individual Performance,” MIS Quarterly (19:2), pp. 213-236.

Gregor, S., and Jones, D. 2007. “The Anatomy of a DesignTheory,” Journal of the Association for Information Systems(8:5), pp. 313-335.

Grudin, J. 1991. “Interactive Systems: Bridging the Gaps betweenDevelopers and Users,” IEEE Computer (24:4), pp. 59-69.

Hammer, M. 1990. “Reengineering Work: Don’t Automate,Obliterate,” Harvard Business Review (July-August), pp.104-112.

Hammer, M., and Champy, J. 1993. Reengineering the Corpora-tion: A Manifesto for Business Revolution, New York: HarperBusiness.

Harmsen, A., Brinkkemper, J., and Oei, J. 1994. “Situation MethodEngineering for Information System Project Approaches,” inProceedings of the CRIS 94 Conference, Twente, TheNetherlands: University of Twente, Department of ComputerScience, pp. 1-34.

Hawk, S., and Dos Santos, B. L. 1991. “Successful SystemDevelopment: The Effect of Situational Factors on AlternateUser Roles,” IEEE Transactions on Engineering management(38:4), pp. 316-327.

Heeks, R. 2002. “Information Systems and Developing Countries:Failure, Success, and Local Improvisations,” Information Society(18:2), pp. 101-112.

Henderson-Sellers, B. 2003. “Method Engineering for OO SystemsDevelopment,” Communications of the ACM (46:10), pp. 73-78.

Henderson-Sellers, B., and Serour, M. K. 2005. “Creating a Dual-Agility Method: The Value of Method Engineering,” Journal ofDatabase Management (16:4), pp. 1-23.

Hevner, A. R., March, S. T., Park, J., and Ram, S. 2004. “DesignScience in Information Systems Research,” MIS Quarterly(28:1), pp. 75-105.

Holmström, J., and Truex, D. 2001. “What Does It Mean to Be anInformed IS Researcher? Some Criteria for the Selection andUse of Social Theories in IS Research,” The 24th InformationSystems Research Seminar in Scandinavia.

Hong, K.-K., and Kim, Y.-G. 2002. “The Critical Success Factorsfor ERP Implementation: An Organizational Fit Perspective,”Information and Management (40:1), pp. 25-40.

Huy, Q. N. 2001. “Time, Temporal Capability, and PlannedChange,” Academy of management Review (26:4), pp. 601-623.



Hwang, C.-L., and Masud, A. S. M. 1979. Multiple Objectives1Decision Making—Methods and Applications: A State-of-the-Art2Survey, Berlin: Springer.3

Ives, B., and Olson, M. H. 1984. “User Involvement in MIS4Success: A Review of Research,” Management Science (30:5),5pp. 586-603.6

Kaliszewski, I. 2004. “Out of the Mist—Towards Decision-Maker-7Friendly Multiple Criteria Decision Making Support,” European8Journal of Operational Research (158:2), pp. 293-307.9

Karlsson, F., and Ågerfalk, P. J. 2004. “Method Configuration:10Adapting to Situational Characteristics While Creating Reusable11Assets,” Information and Software Technology (46:9), pp.12619-633.13

Karlsson, F., and Wistrand, K. 2006. “Combining Method14Engineering with Activity Theory: Theoretical Grounding of the15Method Component Concept,” European Journal of Information16Systems (15:1), pp. 82-90.17

Keen, P. G. W., and Scott Morton, M. S. 1978. Decision Support18Systems: An Organizational Perspective, Reading MA: Addison19Wesley.20

Keeney, R. L., and Raiffa, H. 1976. Decisions with Multiple21Objectives: Preferences and Value Tradeoffs, New York: John22Wiley & Sons.23

Keeney, R. L., and Raiffa, H. 2002. Decisions with Multiple24Objectives: Preferences and Value Tradeoffs, Cambridge, UK:25Cambridge University Press.26

Kensing, F. 2003. Methods and Practices in Participatory Design,27Copenhagen: ITU Press.28

Kensing, F., and Blomberg, J. 1998. “Participatory Design: Issues29and Concerns,” Computer Supported Cooperative Work (7:3-4),30pp. 167-185.31

Kensing, F., and Munk-Madsen, A. 1993. “PD: Structure in the32Toolbox,” Communications of the ACM (36:6), pp. 78-85.33

Khazanchi, D. 2005. “Information Technology (IT) Appropriate-34ness: The Contingency Theory Of ‘Fit’ And IT Implementation35in Small and Medium Enterprises,” The Journal of Computer36Information Systems (45:3), pp. 88-95.37

King, W. R. 1994. “Process Reengineering: The Strategic Dimen-38sions,” Information Systems Management (11:2), pp. 71-73.39

Kotter, J. P. 1996. Leading Change, Boston: Harvard Business40School Publishing.41

Lai, V. S. 1999. “A Contingency Examination of Case-Task Fit on42Software Developer’s Performance,” European Journal of Infor-43mation Systems (8:1), p. 27.44

Mackenzie, A., Pidd, M., Rooksby, J., Sommerville, I., Warren, I.,45and Westcombe, M. 2006. “Wisdom, Decision Support and46Paradigms of Decision Making,” European Journal of47Operational Research (170:1), pp. 156-171.48

Malhotra, Y. 1998. “Business Process Redesign: An Overview,”49IEEE Engineering Management Review (26:3).50

March, S. T., and Smith, G. 1995. “Design and Natural Science51Research on Information Technology,” Decision Support Systems52(15:4), pp. 251-266.53

Markus, L., and Robey, D. 1988. “Information Technology and54Organizational Change: Causal Structure in Theory and55Research,” Management Science (34:5), pp. 583-598.56

Markus, M. L., Majchrzak, A., and Gasser, L. 2002. “A DesignTheory for Systems That Support Emergent Knowledge Pro-cesses,” MIS Quarterly (26:3), pp. 179-212.

Mintzberg, H. 1983. Structure in Fives: Designing EffectiveOrganizations, Englewood Cliffs, NJ: Prentice-Hall.

Mintzberg, H., Ahlstrand, B., and Lampel, J. 2002. Strategy Safari:A Guided Tour through the Wilds of Strategic Management.London, UK: Financial Times, Prentice Hall.

Mitroff, I. I., and Mason, R. O. 1980. “Structuring Ill-StructuredPolicy Issues: Further Explorations in a Methodology for MessyProblems,” Strategic Management Journal (pre-1986) (1:4), pp.331-342.

Mumford, E. 1983. Designing Human Systems for New Technol-ogy: The Ethics Method. Manchester: Manchester: ManchesterBusiness School.

Newman, M., and Noble, F. 1990. “User Involvement as anInteraction Process: A Case Study,” Information SystemsResearch (1:1), pp. 89-113.

Nicholas, J. M. 1985. “User Involvement: What Kind, How Muchand When?,” Journal of Systems Management (36), pp. 23-37.

Noyes, J. M., Starr, A. F., and Frankish, C. R. 1996. “UserInvolvement in the Early Stages of the Development of anAircraft Warning System,” Behaviour & Information Technology(15:2), pp. 67-75.

Nuseibeh, B., Finkelstein, A., and Kramer, J. 1996. “MethodEngineering for Multi-Perspective Software Development,”Information and Software Technology (38:4), p 267.

Oakland, J. S. 2003. TQM: Text with Cases (3rd ed.). Burlington,MA: Butterworth-Heinemann.

Odell, J. J. 1996. “A Primer to Method Engineering,” in MethodEngineering: Principles of Method Construction and ToolSupport, S. Brinkkkemper, K. Lyytinen, and R. Welke (eds.),London: Chapman & Hall, pp. 1-7.

OED. 1989. Oxford English Dictionary (2nd ed.), Oxford, UK:Oxford University Press.

Oinas-Kukkonen, H. 1996. “Method Rationale in Method Engi-neering and Use,” in Method Engineering: Principles of MethodConstruction and Tool Support, S. Brinkkkemper, K. Lyytinen,and R. Welke (eds.), London: Chapman & Hall, pp. 87-93.

Orlikowski, W. J. 1993. “CASE Tools as Organizational Change:Investigating Incremental and Radical Changes in SystemsDevelopment,” MIS Quarterly (17:3), pp. 309-340.

Orlikowski, W. J., and Iacono, C. S. 2001. “Research Commentary:Desperately Seeking ‘It’ in IT Research – A Call to Theorizingthe IT Artifact,” Information Systems Research (12:2), pp.121-134.

Pande, P. S., and Holpp, L. 2000. What Is Six Sigma?, New York:McGraw-Hill.

Rittel, H. W. J., and Webber, M. M. 1973. “Dilemmas in a GeneralTheory of Planning,” Policy Sciences (4:2), pp. 155-169.

Robey, D., and Farrow, D. 1982. “User Involvement in InformationSystem Development: A Conflict Model and Empirical Test,”Management Science (28:1), pp. 73-85.

Rogers, E. M. 2003. Diffusion of Innovations (5th ed.), New York:Free Press.

Rolland, C., and Prakash, N. 1996. “A Proposal for Context-Specific Method Engineering,” in Method Engineering: Prin-



ciples of Method Construction and Support, S. Brinkkemper, K.1Lyytinen, and R. Welke (eds.), London: Chapman & Hall, pp.2191-208.3

Rossi, M., Ramesh, B., Lyytinen, K., and Tolvanen, J.-P. 2004.4“Managing Evolutionary Method Engineering by Method5Rationale,” Journal of the Association for Information Systems6(5:9), pp. 356-391.7

Saaty, T. L. 1988. The Analytic Hierarchy Process, Pittsburgh, PA:8University of Pittsburgh.9

Saaty, T. L., and Vargas, L. G. 1987. “Uncertainty and Rank Order10in the Analytic Hierarchy Process,” European Journal of11Operational Research (32:1), pp. 107-117.12

Saleem, N. 1996. “An Empirical Test of the Contingency Ap-13proach to User Participation in Information Systems Develop-14ment,” Journal of Management Information Systems (13), pp.15145-166.16

Senge, P. M. 1990. The Fifth Discipline: The Art and Practice of17the Learning Organization., New York: Doubleday.18

Simon, H. A. 1960. The New Science of Management Decision,19New York: Harper and Row.20

Simon, H. A. 1973. “The Structure of Ill Structured Problems,”21Artificial Intelligence (4), pp. 181-201.22

Simon, H. A. 1983. “Search and Reasoning in Problem Solving,”23Artificial Intelligence (21), pp. 7-29.24

Simon, H. A. 1996. The Science of the Artificial (3rd ed.),25Cambridge, MA: MIT Press.26

Sprague Jr., R. H. 1993. “A Framework for the Development of27Decision Support Systems,” in Decision Support Systems:28Putting Theory into Practice, R. H. Sprague Jr. and H. J. Watson29(eds.), Englewood Cliffs, NJ: Prentice Hall, pp. 3-28.30

Stelzer, D., and Mellis, W. 1998. “Success Factors of Organiza-31tional Change in Software Process Improvement,” Software32Process: Improvement and Practice (4:4), pp. 227-250.33

Traupman, J. C. 1966. The New Collegiate Latin & English Dic-34tionary, New York: Grosset & Dunlap.35

Truex, D. P., Baskerville, R., and Travis, J. 2000. “Amethodical36Systems Development: The Deferred Meaning of Systems37Development Methods,” Accounting, Management and Informa-38tion Technology (10:1), pp. 53-79.39

Vaishnavi, V., and Kuechler, W. 2004. “Design Research in40Information Systems,” retrieved October 2, 2004, from http://41www.isworld.org/Researchdesign/drisISworld.htm.42

Van Aken, J. E. 2004. “Management Research Based on the43Paradigm of the Design Sciences: The Quest for Field-Tested44and Grounded Technological Rules,” Journal of Management45Studies (41:2), pp. 219-246.46

Van Aken, J. E. 2005. “Management Research as a Design47Science: Articulating the Research Products of Mode 2 Knowl-48edge Production in Management,” British Journal of Manage-49ment (16), pp. 19-36.50

Van de Ven, A. H., and Drazin, R. 1985. “The Concept of Fit in51Contingency Theory,” Research in Organizational Behavior (7),52pp. 333-365.53

Van Slooten, K. 1996. “Situated Method Engineering,” Informa-54tion Resources Management Journal (9:3), pp. 24-31.55

Walls, J. G., Widmeyer, G. R., and El Sawy, O. A. 1992. “Buildingan Information System Design Theory for Vigilant EIS,”Information Systems Research (3:1), pp. 36-59.

Walls, J. G., Widmeyer, G. R., and El Sawy, O. A. 2004.“Assessing Information System Design Theory in Perspective:How Useful Was Our 1992 Initial Rendition?,” Journal ofInformation Technology Theory and Application (6:2), pp. 43-58.

Wand, Y. 1996. “Ontology as a Foundation for Meta-Modeling andMethod Engineering,” Information and Software Technology(38:4), pp. 281-287.

Wang, Y.-M., Yang, J.-B., Xu, D.-L., and Chin, K.-S. 2007. “Onthe Combination and Normalization of Interval-Valued BeliefStructures,” Information Sciences (177:5), March 2007, pp.1230-1247.

Weill, P., and Olson, M. H. 1989. “An Assessment of the Con-tingency Theory of Management Information Systems,” Journalof Management Information Systems (6), pp. 59-85.

Willcocks, L., Feeny, D., and Islei, G. 1997. Managing IT as aStrategic Resource, New York: McGraw-Hill.

Wilson, S., Bekker, M., Johnson, P., and Johnson, H. 1997.“Helping and Hindering User Involvement – A Tale of EverydayDesign,” CHI 97: Conference on Human Factors in ComputingSystems, New York: ACM Press.

Woods, D. D. 1988. “Coping with Complexity: The Psychologyof Human Behavior in Complex Systems,” in Tasks, Errors andMental Models, L. P. Goodstein, H. B. Andersen, and S. E. Olsen(eds.), London: Taylor & Francis, pp. 128-148.

Woods, D. D., and Hollnagel, E. 1987. “Mapping CognitiveDemands in Complex Problem-Solving Worlds,” InternationalJournal of Man-Machine Studies (26:2), pp. 257-275.

Xu, D.-L., Jian-Bo, Y., and Wang, Y.-M. 2006. “The EvidentialReasoning Approach for Multi-Attribute Decision Analysis underInterval Uncertainty,” European Journal of OperationalResearch (174:3), pp. 1914-1943.

Zigurs, I., and Buckland, B. 1998. “A Theory of Task/TechnologyFit and Group Support System Effectiveness,” MIS Quarterly(22:3), pp. 313-334.

Zigurs, I., Buckland, B., Connolly, J. R., and Wilson, E. V. 1999.“A Test of Task/Technology Fit Theory for Group SupportSystems,” Database (30:3/4), pp. 34-50.

About the Authors

Jan Pries-Heje is Professor of Information Systems and head of theUser-Driven IT innovation research group in the Department ofCommunication, Business and IT, Roskilde University, Denmark.His research specializes in organizational and managerial aspects ofIT development, such as software process improvement, softwaredevelopment, and—most recently—design and design research. Hehas published in these areas in journals including Annals of SoftwareEngineering, Information Systems Journal, MIS Quarterly, andEuropean Journal of Information Systems. He is the Danish nationalrepresentative to the International Federation for InformationProcessing’s Technical Committee 8 (TC 8) on Information



Systems, and Vice-Chair for TC 8 from 2007. Finally, he is a1member of the ACM, IEEE, and the Danish Computer Society.2

3Richard Baskerville is Board of Advisors Professor in Computer4Information Systems at Georgia State University. His research5specializes in security of information systems, methods of infor-6mation systems design and development, and the interaction of7information systems and organizations. His interests in methods8extend to qualitative research methods. Baskerville is the author of9

Designing Information Systems Security (New York: John Wiley)and more than 100 articles in scholarly journals, practitionermagazines, and edited books. He is editor-in-chief of EuropeanJournal of Information Systems, and associated with the editorialboards of Information Systems Journal and Journal of DatabaseManagement. Baskerville’s practical and consulting experienceincludes advanced information system designs for the U.S. Defenseand Energy departments. He is a former chair of the department atGeorgia State and of the IFIP Working Group WG 8.2.

Appendix A10

The Spreadsheet Form Used to Measure Actual Conditions11in a Project for the User Involvement Nexus12

Complexity13 Answer

Developers have no knowledge of user’s tasks14 2 = agree 1 = partly agree 0 = disagree

System needs to solve many diverse tasks15 2 = agree 1 = partly agree 0 = disagree

More than 36 man months estimated for development16 2 = agree; morethan 24 months

1 = partly agree;between 12 & 24

months

0 = disagree;less than 12

months

More than 24 calendar months estimated for17development18

2 = agree; morethan 24 months

1 = partly agree;between 12 & 24

months

0 = disagree;less than 12

months

Developers do not know the technology that goes into19the future system20

2 = agree 1 = partly agree 0 = disagree

Many stakeholders are involved in the project21 2 = agree 1 = partly agree 0 = disagree

The project has many interfaces, for example, to other22systems23


Resources24 Answer

Project has considerable management support in talk25and action as well as in demand for results26


More than 10% of project resources—monies and27persons—are dedicated to user involvement28

2 = agree; morethan 10%

1 = partly agree;between 3% and

10%

0 = disagree

The project has a fluid deadline that easily can be29changed30


Users31 Answer

The system is developed for users for which we either32know the names or can get the names33

2 = yes; can benamed

0 = no;nameless

343536


1

d theory nexus - heim.ifi.uio.noheim.ifi.uio.no/~petterog/kurs/design...

Documents