Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

The interaction between context and technology during information systems development (ISD) : action… Chiasson, Mike 1996

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1996-147355.pdf [ 16.71MB ]
Metadata
JSON: 831-1.0087839.json
JSON-LD: 831-1.0087839-ld.json
RDF/XML (Pretty): 831-1.0087839-rdf.xml
RDF/JSON: 831-1.0087839-rdf.json
Turtle: 831-1.0087839-turtle.txt
N-Triples: 831-1.0087839-rdf-ntriples.txt
Original Record: 831-1.0087839-source.json
Full Text
831-1.0087839-fulltext.txt
Citation
831-1.0087839.ris

Full Text

THE INTERACTION B E T W E E N CONTEXT A N D T E C H N O L O G Y D U R I N G INFORMATION SYSTEMS D E V E L O P M E N T (ISD) action research investigations in two health settings by M I K E CHIASSON B.Com., University of Alberta, 1990 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE D E G R E E OF DOCTOR OF PHILOSOPHY in THE F A C U L T Y OF G R A D U A T E STUDIES THE F A C U L T Y OF C O M M E R C E A N D BUSINESS ADMINISTRATION Department of Management Information Systems We accept this thesis as conforming - to the required standard THE UNIVERSITY OF BRITISH C O L U M B I A J U L Y 1996 ®Mike Chiasson, 1996 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of The University of British Columbia Vancouver, Canada DE-6 (2/88) 11 A B S T R A C T Software development and implementation failure is perceived by developers and users as a serious problem. Of every six new software development projects, 2 are abandoned, the average project lasts 50% longer than expected, and 75% of large systems are "operating failures" that are rejected or perform poorly. Design failure contributes to the productivity paradox, where increased investment in information technology (IT) has not correlated with improvements in productivity. Many IS researchers state that further research examining the interaction between technology and context during information system development (ISD) is required. This current study is motivated by these calls for research. The marrying of information systems and health research also raises a second motivation. The deployment and diffusion of IT can contribute to the effective utilization of health resources. Another motivation of the thesis is to explore the effect of information systems on disease prevention, and provide an opportunity to develop and diffuse IT tools that promote health. To address these two motivations, two case studies of ISD in two health studies are described. The first case study involved the initiation and development of an electronic patient record in two outpatient clinics specializing in heart disease prevention and rehabilitation (SoftHeart). The second case study involved the development of a windows-based multimedia software that assists the planning of breast cancer educational and policy programs in communities. The first case study covered four years (Summer of 1992 to Spring of 1996) and the second case covered 1 year (Spring of 1995 to Spring of 1996). The purpose of the thesis is to generate hypotheses for future research in ISD. I l l Both studies employed an "action research" approach where the researcher was directly involved with software design and programming. Data from interviews, meeting minutes, field notes, design and programming notes, and other documentation were collected from both studies and triangulated to provide valid interpretations. Important and illustrative technology-context events are extracted from the cases to uncover processes between technology and context during stages of development. Processes are compared with four theories linking technology and context: technological imperative and organizational imperative (unidirectional), and emergent perspective and social technology (bi-directional). These processes are then combined to reach tentative conclusions about the ISD process. Key findings indicate an interplay between a small number unidirectional processes (organizational and technology imperative) and a large number of bi-directional theories (social technology and emergence). Overall, the emergent perspective described or participated in describing a majority of the processes, given the developer's perspective, extraction and interpretation of these key processes. In both cases, the ISD trajectory was best described as emergent. The result of within case and cross-case analysis is a model integrating the four technology-context theories depending on stakeholder agreement and the adaptability of technology during development and use. Dynamics and change in task, technology, and stakeholder configurations are explained by the deliberate or accidental interaction of new and old stakeholders, technology, ideas, agreements and/or tasks over time. Implications for research and practice are discussed. iv T A B L E OF C O N T E N T S A B S T R A C T " T A B L E O F C O N T E N T S i v L I S T O F T A B L E S v i i i L I S T O F F I G U R E S x A C K N O W L E D G E M E N T x i i 1. I N T R O D U C T I O N 1 1.1. DESCRIPTION OF THE THESIS 1 1.2. DESCRIPTION OF CASE STUDIES AND METHODOLOGY 1 1.3. STUDY MOTIVATION 2 1.3.1. Motivation 1: Information Systems Failure 3 1.3.2. Motivation 2: Combining ISD and Health 5 1.4. K E Y FINDINGS. 6 1.5. ORGANIZATION OF THESIS 6 2. L I T E R A T U R E R E V I E W 8 2.1. CHAPTER OVERVIEW 8 2.2. STAGES AND DIMENSIONS OF SYSTEM DEVELOPMENT 9 2.3. TECHNOLOGY'S LINKAGE TO CONTEXTUAL DIMENSIONS 11 2.4. FOUR THEORIES OF THE TECHNOLOGY - CONTEXT 13 2.4.1. Technological Imperative 15 2.4.2. Technological Imperative Research 16 2.4.3. Organizational Imperative • 17 2.4.4. Organizational Imperative Research 19 2.4.5. Reflections on Unidirectional Theories of Technology-Context Interaction 24 2.4.6. Emergent Perspective 28 2.4.7. Emergent Perspective Research 29 2.4.8. Social Technology 40 2.4.9. Social Technology Research 42 2.4.10. Conclusion: Reconciling the Four Theories of Technology and Context Interaction 45 2.5. CHAPTER SUMMARY : 46 3. R E S E A R C H Q U E S T I O N A N D M E T H O D O L O G Y 48 V 3.1. RESEARCH QUESTION '. 48 3.2. METHODOLOGY 48 3.2.1. Comparative Case Design 48 3.2.2. Action Research 52 3.2.3. Longitudinal Analysis. 57 3.2.4. Data Collection and Analysis 57 3.3. SOME LIMITATIONS OF THE METHODOLOGY 62 4. P R O C E S S E S I N T H E I N I T I A T I O N A N D D E V E L O P M E N T O F " S O F T H E A R T " 63 4.1. T H E TWO HEART CLINICS AND SOFTHEART 64 4.1.1. Clinic One 65 4.1.2. Clinic Two 67 4.1.3. Description of SoftHeart and LipidLink 68 4.2. PROJECT EMERGENCE.. . 71 4.3. HEALTHFUNDERS SKEPTICAL 74 4.4. OUR RESPONSE 76 4.5. O L D AND NEW ENVIRONMENTAL SHOCKS 78 4.6. DECISIONS TO M O V E AHEAD 80 4.7. PRESENTATION PROMPTS INTEREST AND CONSTRAINT 84 4.8. CONFLICT ERUPTS 87 4.9. DECISION TO A C T 90 4.10. PROJECT BUILDS MOMENTUM 92 4.11. DEVELOPMENT QUAGMIRE 95 4.12. RECOVERY AND SLOW GROWTH TOWARD EARLY IMPLEMENTATION 96 4.13. WHAT LIES AHEAD 99 4.14. CASE CONCLUSION 100 4.14.1. Process Analysis : 100 4.14.2. Information System Development 106 5. P R O C E S S E S I N T H E I N I T I A T I O N A N D D E V E L O P M E N T O F E M P O W E R 107 5.1. T H E DEVELOPMENT T E A M AND E M P O W E R 108 5.2. PROJECT EMERGENCE 112 5.3. GETTING READY 115 5.4. PANDORA'S Box OPENS 119 5.5. SQUEEZING THE MOST FROM TOOLBOOK AND E M P O W E R 124 vi 5.6. VISIONS OF A N E W SOFTWARE CONSTRAINED BY RESOURCES 127 5.7. CASE CONCLUSION 129 5.7.1. Process Analysis J 29 5.7.2. Information System Development 133 6. C O M P A R I S O N A N D I N T E G R A T I O N 134 6.1. INTRODUCTION 134 6.2. TECHNOLOGICAL IMPERATIVE 134 6.3. ORGANIZATIONAL IMPERATIVE 138 6.4. EMERGENT PERSPECTIVE 143 6.5. SOCIAL TECHNOLOGY 147 6.6. INTEGRATING THE FOUR THEORIES 153 6.7. CONCLUSIONS 157 7. I M P L I C A T I O N S A N D F U T U R E R E S E A R C H 159 7.1. CONTRIBUTIONS 159 7.2. IMPLICATIONS 161 7.3. LIMITATIONS AND FUTURE RESEARCH 167 7.4. CONCLUDING COMMENTS 169 8. R E F E R E N C E S 170 9. A P P E N D I X A : E V E N T S I N T H E D E V E L O P M E N T O F S O F T H E A R T 186 9.1. PROJECT EMERGENCE 186 9.2. HEALTH FUNDERS SKEPTICAL 189 9.3. OURRESPONSE 190 9.4. O L D AND NEW ENVIRONMENTAL SHOCKS 191 9.5. DECISION TO M O V E AHEAD 192 9.6. PROTOTYPE DEMONSTRATION SPARKS INTEREST AND CONSTRAINT 196 9.7. CONFLICT ERUPTS 198 9.8. DECISION TO A C T 2 0 1 9.9. PROJECT BUILDS MOMENTUM 203 9.10. DEVELOPMENT QUAGMIRE 206 9.11. RECOVERY AND SLOW GROWTH TOWARD EARLY IMPLEMENTATION 210 9.12. WHAT LIES AHEAD 214 V l l 10. A P P E N D I X B : E V E N T S I N T H E D E V E L O P M E N T O F E M P O W E R 215 10.1. PROJECT EMERGENCE 215 10.2. PROJECT DIRECTION, DECISION AND ORGANIZATION 218 10.3. PANDORA'S Box OPENS 223 10.4. SQUEEZING THE MOST FROM TOOLBOOK AND E M P O W E R 231 10.5. VISIONS OF A N E W SOFTWARE CONSTRAINED BY RESOURCES 233 11. A P P E N D I X C : C O N T E X T U A L I N F O R M A T I O N F O R C A S E O N E - S O F T H E A R T 237 11.1. INTRODUCTION 237 11.2. HEART DISEASE EPIDEMIOLOGY 237 11.3. THEORIES OF HEALTH BEHAVIOR 241 11.4. T H E HEALTH CARE CONTEXT 246 11.5. HEALTH CARE FUNDING DEBATE 249 12. A P P E N D I X D : C O N T E X T U A L I N F O R M A T I O N F O R C A S E T W O - E M P O W E R 256 12.1. INTRODUCTION 256 12.2. BREAST CANCER EPIDEMIOLOGY AND BREAST CANCER SCREENING..... 256 12.3. HEALTH PLANNING 260 13. A P P E N D I X E : P I C T U R E S O F S O F T H E A R T 266 14. A P P E N D I X F : P I C T U R E S O F E M P O W E R 276 15. A P P E N D I X G : T H E S O F T H E A R T P R O G R A M 289 16. A P P E N D I X H : D E M O N S T R A T I N G T H E L A D D E R O F I N F E R E N C E 305 16.1. CHOOSING THEORETICAL PERSPECTIVES 305 16.2. CATEGORIZING THE LITERATURE 307 16.3. EVENTS AND PROCESSES 308 16.4. LINKING PROCESSES TO THE LITERATURE 309 V1H LIST OF T A B L E S TABLE 2-1: STAGES AND DIMENSIONS OF SYSTEM DEVELOPMENT 9 T A B L E 2-2: ACTIONS AND PRODUCTS OF DEVELOPMENT STAGES - COOPER & ZMUD (1990) 10 T A B L E 2-3: REVISED TECHNOLOGICAL AND CONTEXTUAL DIMENSIONS OF SYSTEM DEVELOPMENT. 11 TABLE 2-4: PROCESS THEORIES OF THE TECHNOLOGY AND CONTEXTUAL DIMENSIONS LINKAGE 14 T A B L E 2-5: RECONCILING THE FOUR THEORIES 46 T A B L E 2-6: SUMMARY OF FOUR PROCESS THEORIES AND ISD RESEARCH 47 TABLE 3-1: DEVELOPMENT ENVIRONMENT 51 TABLE 3-2: CHARACTERISTICS OF A PROCESS 60 T A B L E 4-1: PROCESS STAGES IN THE DEVELOPMENT OF SOFTHEART , 64 TABLE 4-2: PROCESSES IN PROJECT EMERGENCE • 74 TABLE 4-3: PROCESSES IN HEALTH FUNDERS SKEPTICAL : 76 TABLE 4-4: PROCESSES IN OUR RESPONSE TO HEALTH CRITIQUES 78 TABLE 4-5: PROCESSES IN THE ENVIRONMENTAL SHOCKS STAGE 80 TABLE 4-6: PROCESSES IN THE M O V E AHEAD STAGE 83 TABLE 4-7: PROCESSES IN THE INTEREST AND CONSTRAINT STAGE 87 TABLE 4-8: PROCESSES IN THE CONFLICT STAGE 90 TABLE 4-9: PROCESSES IN THE DECISION TO A C T STAGE 92 T A B L E 4-10: PROCESSES IN THE MOMENTUM STAGE 94 TABLE 4-11: PROCESSES IN THE DEVELOPMENT QUAGMIRE STAGE 96 TABLE 4-12: PROCESSES IN THE RECOVERY STAGE 98 TABLE 4-13: PROCESSES IN THE FUTURE OF SOFTHEART 100 TABLE 4-14: SUMMARY OF PROCESS TYPES IN PROCESS STAGES 101 TABLE 4-15: ISD RESEARCH CATEGORIES WITHIN PROCESS STAGES 102 T A B L E 4-16: EXAMINATION OF SHARED PROCESSES 104 TABLE 4-17: NUMBER OF TIMES O N E PROCESS TYPE IS FOLLOWED ANOTHER TYPE 105 ix TABLE 4-18: NUMBER OF TIMES A SERIES OF O N E PROCESS TYPE WAS TERMINATED BY ANOTHER TYPE 106 TABLE 5-1: PROCESS STAGES IN THE DEVELOPMENT OF E M P O W E R 108 TABLE 5-2: PROCESSES IN THE EMERGENCE STAGE 115 TABLE 5-3: PROCESSES IN THE "GETTING READY" STAGE 118 TABLE 5-4: PROCESSES IN THE "PANDORA'S Box OPENS" STAGE 124 T A B L E 5-5: PROCESSES IN THE "SQUEEZING THE MOST" STAGE 127 TABLE 5-6: PROCESSES IN "VISIONS OF A NEW E M P O W E R " STAGE 128 TABLE 5-7: SUMMARY OF PROCESS TYPES IN PROCESS STAGES 129 T A B L E 5-8: ISD RESEARCH CATEGORIES WITHIN PROCESS STAGES : 130 TABLE 5-9: EXAMINATION OF SHARED PROCESSES 131 TABLE 5-10: NUMBER OF TIMES APROCESS TYPE WAS FOLLOWED BY ANOTHER TYPE 132 TABLE 5-11: NUMBER OF TIMES A SERIES OF O N E TYPE WAS TERMINATED BY ANOTHER TYPE 132 TABLE 6-1: TECHNOLOGICAL IMPERATIVE SUMMARY FROM CASE O N E AND CASE TWO 135 TABLE 6-2: ORGANIZATIONAL IMPERATIVE SUMMARY FROM CASE O N E AND CASE TWO 139 TABLE 6-3: EMERGENT PERSPECTIVE SUMMARY FROM CASE O N E AND CASE TWO 143 TABLE 6-4: SOCIAL TECHNOLOGY SUMMARY FROM CASE O N E AND CASE TWO 148 X LIST O F F I G U R E S FIGURE 2-1: ACTION AND ACTION FRONTIER 12 FIGURE 2-2: TECHNOLOGICAL IMPERATIVE 15 FIGURE 2-3: T H E ORGANIZATIONAL IMPERATIVE 19 FIGURE 2-4: T H E EMERGENT PERSPECTIVE ON TECHNOLOGY AND CONTEXT •. 28 FIGURE 2-5: SOCIAL TECHNOLOGY THEORY 41 FIGURE 3-1: RESEARCH DESIGN 50 FIGURE 3-2: LADDER OF INFERENCE 59 FIGURE 3-3: LEVELS OF TECHNOLOGY 61 FIGURE 4-1: D A T A VIEW OF SOFTHEART ; 69 FIGURE 5-1: E M P O W E R PROGRAM STRUCTURE I l l FIGURE 6-1: INTEGRATED M O D E L OF CONTEXT AND TECHNOLOGY INTERACTION 154 F I G U R E D - l : P R E C E D E / P R O C E E D M O D E L 261 FIGURE E - l : INTRODUCTORY SCREEN 266 FIGURE E-2: PATIENT SEARCH WINDOW 267 FIGURE E-3: PATIENT INFORMATION PANEL 268 FIGURE E-4: LIPIDS INFORMATION PANEL 269 FIGURE E-5: MEDICATIONS INFORMATION PANEL 270 FIGURE E-6: LIPIDS EDIT PANEL 271 FIGURE E-7: PATIENT INFORMATION EDIT PANEL 272 FIGURE E-8: TRENDS INFORMATION PANEL 273 FIGURE E-9: SCHEDULING PANEL 274 FIGURE E-10: REPORTING PANEL 275 FIGUREF-1: INTRODUCTORY SCREEN : 276 FIGURE F-2: ASSUMPTIONS SCREEN 277 FIGURE F-3: GLOBAL M A P PAGE 278 xi FIGURE F-4: LOCAL M A P PAGE OF THE SITUATION ANALYSIS 279 FIGURE F-5: SHARED VISION STATEMENT 280 FIGURE F-6: ROLE IN THE PROJECT 281 FIGURE F-7: T H E PROGRAM GOAL PAGE AND CONSULT-ON-TAP RESOURCES 282 FIGUREF-8: "WHY" HELP 283 FIGURE F-9: OTHER REFERENCE HELP 284 FIGUREF-10: DATAFILES 285 FIGUREF-11: UNIVERSITY D A T A FILE 286 FIGURE F-12: CURRENT CAPACITIES AND RESOURCES 287 FIGURE F-13: SUMMARY REPORT FOR SITUATION ANALYSIS 288 FIGURE G - l : T H E SOFTHEART PROGRAM STRUCTURE 290 XII A C K N O W L E D G E M E N T This thesis demonstrates the importance of "context" in producing invention. I would especially like to thank many individuals around me who have provided substantial and continuous support for the project. I owe a great debt of gratitude to my supervisor, professor Albert Dexter, who provided time, encouragement and freedom to explore new ideas. I also owe a great debt to my two committee members: professors Maurice Levi and Lawrence Green. Both have provided me with precious time and guidance in producing this thesis. I am grateful to the two organizations who supported my research, who allowed me to experiment with their information systems and organizational operations, and assisted me in faithfully reporting the findings. I am indebted to my mother, Beth Chiasson, who provided me with an early thirst for learning and understanding, and provided both intellectual and emotional support to my sociological and methodological ideas and references. I owe great thanks to Laurenda Daniells, who provided a home, detailed insights into the university process, important information for surviving in my new city, and wonderful discussion and friendship throughout my graduate years. I also give my warmest appreciation to those colleagues who challenged my thinking, provided wonderful hours of discussion and laughter, and contributed greatly to the thesis: Amos Shachar, Janice Foley, Gary Clark, and Dawne Milligan. I am grateful for the family and friends who continuously and unconditionally supported me with discussion, listening, and laughter: my father Gerry Chiasson, my lovely girlfriend Frances Brodie, my two brothers David and Larry Chiasson, and my faithful companion Gracie. Chapter 1: Introduction 1 1. Introduction 1.1. Description of the Thesis Information systems development (ISD) involves a process1 of interaction between technology2 and context* that results in the initiation, creation, and early implementation of an information system (IS) and information technology (IT). Most of the ISD literature is concerned with descriptive (what is) or normative (what should be) claims about the technology-context interaction. This thesis explores information systems development (ISD) in two health settings, generating hypotheses about the ISD process. The following research question is addressed: (1) What is the nature of the interaction between technology and context during ISD? 1.2. Description of Case Studies and Methodology The first case study describes the initiation and development of an electronic patient record in two outpatient clinics specializing in heart disease prevention and rehabilitation (SoftHeart). The second case study describes the development of a windows-based multimedia software that assists the planning of breast cancer educational and policy programs in communities (EMPOWER - Expert Methods of Planning and Organizing Within 1 Process of interaction between technology and context involves time, an "exchange", and elements from technology and context that contribute in the exchange 2 Technology is a general term in this thesis, used to describe all aspects of the information system including software and infrastructure. It is also used to describe other equipment, machinery, and/or administrative processes in non-IS research.. 3 Context include: users, organization, environment, task, developers/suppliers, and environment. Chapter 1: Introduction 2 Everyone's Reach). The first case study covered four years (Summer of 1992 to Spring of 1996) and the second case covered 1 year (Spring of 1995 to Spring of 1996). The purpose of the thesis is to generate hypotheses for future research in ISD. Both studies employed an "action research" approach where the researcher was directly involved with software design and programming. The action research method allows the researcher to address both descriptive and normative questions about ISD. Data from interviews, meeting minutes, field notes, design and programming notes, and other documentation were collected from both studies and triangulated to provide valid interpretations. Important and illustrative events4 are extracted from the cases to uncover processes between technology and context during stages5 of development (Newman & Robey 1992). Processes are compared with four theories linking technology and context: technological imperative and organizational imperative (unidirectional), and emergent perspective and social technology (bi-directional). These processes are then combined to reach tentative conclusions about the ISD process. 1.3. Study motivation This thesis is motivated by important issues in information systems research and medicine/health promotion. 4 Discrete points in time when technology shapes or is shaped by context (users, developers, organization, environment, task) 5 Certain periods of time where development carries on a certain general form of interaction between technology and context (e.g. iniaition and creation, development, conflict, etc.). Chapter 1: Introduction 3 1.3.1. Motivation 1: Information Systems Failure Software development and implementation failure is perceived by developers and users as a serious problem (Lyytinen 1987; Gibbs 1994; Landauer 1995). Of every six new software development projects, 2 are abandoned, the average project lasts 50% longer than expected, and 75% of large systems are "operating failures" that are rejected or perform poorly (Gibbs 1994). Design failure contributes to the productivity paradox, where increased investment in information technology (IT) has not correlated with improvements in productivity (Burton 1992; Landauer 1995).6 There is disagreement in the IS community, however, over the cause and solutions to these development problems. Some recommend more strategic planning and "linking" of the information system (IS) and information technology (IT) plans with business strategy (McFarlan 1984; Earl 1989). Some recommend the use of better formalized methods and tools to modej business environments (Coad & Yourdon 1991; Wand & Weber 1993). Other researchers recommend the use of user involvement and testing, and more humanistic and interpretive approaches to analyzing decision makers (Boland 1985; Boland 1987; Landauer 1995). Still others fault developers for focusing only on technology while ignoring social context (Kling 1980; Kling & Scacchi 1982; Kling 1987; Turner 1987). Finally, some researchers comment that the social context around technology appropriates and shapes the effect of technology within certain boundaries (Orlikowski 1991, 1992a; 1992b; Zuboff 1988). Each view carries implicit assumptions about the relative influence of context on technology, 6 The literature around the "productivity paradox" is controversial and beyond the scope of this thesis. See Hitt & Brynjolfsson (1994) and Landauer (1995) for a more complete discussion. Chapter 1: Introduction 4 and technology on context during information systems development (ISD). For example, strategic planning approaches carry implicit diffusion and demand notions of system development. Specifically critiquing the implicit demand and diffusion models of ISD, Attewell (1992) quotes Eveland & Tornatzky's (1990) who remark: Problems arise when the diffusion model is applied in situations where its basic assumptions are not met -- that is to say, virtually every case involving complex, advanced technology (p. 123). Further research examining the interaction between technology and context to understand the process of ISD is required. Several researchers have commented on the need for research to understand the process of ISD and technology innovation more generally (Turner 1987; Markus & Robey 1988; Cooper & Zmud 1990; Eveland & Tornatzky 1990; Newman & Robey 1992). Cooper and Zmud (1990) state that very few studies have addressed context (environment, user, developers and suppliers, and organization) and its interaction with technology during ISD, and that little research has attempted to address a number of development stages and contextual dimensions simultaneously: ...that prior studies focus on too few of the model stages and factors and advocate that future research should explore the impact of multiple contextual factors on multiple implementation stages (p. 125). ...studies examining both rational and political forces throughout the IT implementation stages can be especially fruitful. Such studies will be more powerful if they are longitudinal in nature ~ providing the capability to more thoroughly examine the dynamics of individual, organizational, and technological adaptations across the implementation stages (p. 137). Markus & Robey (1988) also recommend further process research mixing levels of analysis (individual, group, organization, etc.). Process theories are considered more appropriate for studying complex social phenomena: Chapter 1: Introduction 5 In summary, we believe that process theories are useful precisely because, while recognizing and accepting the complexity of causal relationships, they do not abandon the goals of generalizability and prediction....With care, findings can be generalized to other settings, and predictions can be tested in later research. The advantage of process theories is that these predictions may correspond more faithfully to actual events in organizations than do the typical predictions of variance formulations (p. 593). This current study is motivated by these calls for research. The purpose of this thesis is to reconcile the ISD literature, and provide empirical data on the process of ISD. 1.3.2. Motivation 2: Combining ISD and Health The marrying of the information systems and health addresses the first motivation and raises a second motivation. With respect to the first motivation, the health setting provides a complex and unique environment to test and expand our understanding of IS development (Kling 1980).7 With respect to a second motivation, the deployment and diffusion of IT can contribute to the effective utilization of health resources.8 The research explores the effect of information systems on disease prevention, and provides an opportunity to develop and diffuse IT tools that promote health.9 7 The Canadian health sector has a number of complex and turbulent environmental characteristics that influence IS development (Emery & Trist 1971). Funding arrangements vary widely from not-for-profit vs. profit, fee-for-service vs. payment by capitation, research versus clinical, etc. The labor force is composed of numerous semi-autonomous professionals providing skilled services. Information and decision making involves both quantitative and qualitative data. Measurement of health outcomes is very difficult to determine at both the individual and organizational level of analysis. There are few standardized information systems compared with other industries. Finally, public debate, input and involvement in health care is extensive. In this sense, the setting provides an outstanding opportunity to test and expand our knowledge of factors, processes, and events influencing information systems development. See Appendix C for a more detailed discussion. 8 As of 1990, health care expenditures comprise 9% and 12.5% of the GNP in Canada and the United States respectively (Evans 1990). There is extensive literature and press coverage suggesting that a significant portion of these resources are not being used effectively, and opportunities exist for researching alternative technologies and delivery approaches. 9 Although this thesis does not provide direct empirical evidence of the IT/IS and health outcomes link, a sampling of the health literature linking IT/IS to processes affecting health outcomes is discussed in the Appendices. Chapter 1: Introduction 6 1.4. Key Findings Four process theories of context-technology interaction are used in this study. Two unidirectional theories (technological imperative and organizational imperative) and two bi-directional theories (emergent perspective and social technology) are used to organize the literature and the case data. Technology-context processes were categorized by level and technology part, the time period, the stakeholders involved, the tasks, and one or more of the four process theories that best described the process. Key findings indicate an interplay between a small number unidirectional processes (organizational and technology imperative) and a large number of bi-directional theories (social technology and emergence). Overall, the emergent perspective described or participated in describing a majority of the processes, given the developer's perspective, extraction and interpretation of key processes. In both cases, the ISD trajectory was best described as emergent. The result of within case and cross-case analysis is a model integrating the four technology-context theories depending on stakeholder agreement and the adaptability of technology during development and use. Dynamics and change in task, technology, and stakeholder configurations are explained by the deliberate or accidental interaction of new and old stakeholders, technology, ideas, agreements and/or tasks over time. Implications for research and practice are discussed. 1.5. Organization of Thesis The thesis is organized as follows. Chapter 2 provides a review of the Information Systems Development (ISD) literature. Process research and theories of ISD and technology Chapter 1: Introduction 7 are discussed and integrated to provide a framework and language for interpreting the case data. Chapter 3 discusses the action research methodology employed in the two case studies, providing an understanding of the method's strengths and weaknesses in addressing the research question. Chapter 4 describes the interaction between context and technology during the development of SoftHeart over a four-year period, providing a substantive theory of the SoftHeart case. Chapter 5 describes the interaction between context and technology during the development of EMPOWER over a twelve-month period, providing a substantive theory of the EMPOWER case. Chapter 6 compares and contrasts the two case studies and relates the findings to the literature. The chapter concludes with a model integrating task, technology, stakeholders, and the four process theories. Chapter 7 draws implications, describes weaknesses, and suggests directions for future research.10 Appendices are provided to support the cases including case descriptions for SoftHeart (Appendix A) and Empower (Appendix B), medical and health promotion literature important in case one (Appendix C) and case two (Appendix D), and snapshots of the screens from SoftHeart (Appendix E) and Empower (Appendix F). Appendix G provides a summary of the SoftHeart program structure. Finally, Appendix H provides an example and a summary of the "rules" used to choose the four technology-context theories, categorize the IS and technology development literature into the four theories, analyze event and process construction, and attach processes to the literature. Chapter 2: Literature Review 8 2. Literature Review 2.1. Chapter Overview The information systems development (ISD) literature holds various descriptive (what is) and normative (what should be) conclusions about the technology-context interaction. Chapter 2 develops a framework and language to understand and integrate these various views, providing alternative theories and perspectives for viewing the case data. ISD research is a fairly large and widespread body of research. However, there are certain characteristics of the ISD research that are particularly applicable to this thesis. First, longitudinal and process-focused research in field settings, with a level of analysis at a group or organizational level, are more relevant to this thesis than variance research. Second, the literature review emphasizes three areas of ISD research. Using the keyword classification of Barki, Rivard, & Tabot (1993), they include IS Implementation, organizational dynamics, and information systems project management. The chapter is organized as follows. First, the chapter identifies the stages and dimensions of system development and implementation. Second, the chapter introduces the "action" and "action frontier" concepts to assist in examining the interaction between the technology and the contextual dimensions. Third, four process theories (two unidirectional and two bi-directional) are examined that link technology to context: the technological imperative, organizational imperative, emergent perspective, and social technology are examined. Classic and exemplar ISD research is discussed under each theory to provide Chapter 2: Literature Review 9 evidence, normative conclusions, and critiques of each of the four theories. This provides a rich understanding of the ISD process (Franz & Robey 1984; Hirschheim & Klein 1989; Orlikowski & Baroudi 1991; Orlikowski & Robey 1991; Newman & Robey 1992). The chapter concludes with methods of comparing and reconciling these four theories, providing a basis for building an integrated theoretical framework. 2.2. Stages and Dimensions of System Development Cooper and Zmud's (1990) framework of the IS implementation literature provides a foundation for this study's framework. Their meta-analysis classifies the IS implementation research into six stages: initiation (unfreezing), adoption and adaptation (changing), and acceptance, routinization, and infusion (refreezing). They also identify five dimensions that affect and/or are affected by the activity of each stage: user, organization, task, technology, and environment. They construct the following table to show where previous research has focused: Table 2-1: Stages and Dimensions of System Development Stage/ Dimension User Organization Task Technology Environment Initiation Adoption X Adaptation X X X X Acceptance X X X X X Routinization Infusion X X There are both actions and products for each of the implementation stages: Chapter 2: Literature Review 10 Table 2-2: Actions and Products of Development Stages - Cooper & Zmud (1990) Stage Actions Products Initiation Search for potential solutions to a problem. Match of potential solution with a problem. Adoption Rational and political discussions gain organizational backing for the project. Commitment of resources and time. Adaptation System is developed, installed and maintained. A working set of IT. Acceptance Employees willing to commit time to the application. Widespread use of IT throughout the organization. Routiniza-tion IT becomes a normal part of operations. Transparent IT that is embedded in the organization Infusion IT enhances effectiveness and the IT begins to support higher level tasks. Its product is an IT used to its fullest potential These stages can be seen as overlapping, often with some elements of a new software system reaching the infusion stage before other parts of the system are created. Cooper and Zmud also identify dimensions involved in IS development and implementation. These include technology, and contextual dimensions surrounding the technology including user, organization, task and environment: Various characteristics and "stakeholders" of these contextual dimensions affect and are affected by ISD. To this framework is added the "developers and suppliers" dimension from the supply-side discussion of ISD (Attewell 1992). The revised framework appears as follows: Chapter 2: Literature Review 11 Table 2-3: Revised Technological and Contextual Dimensions of System Development Stages/Factors User Organi-zation Task Tech-nology Environ ment Developers/ Suppliers Initiation Adoption Adaptation Acceptance Routinization Infusion This framework provides a simple and effective device for categorizing the ISD research and case study data. 2.3. Technology's linkage to Contextual Dimensions The previous section provided a framework for describing and categorizing development stages and dimensions. However, theories about the interaction between the dimensions are missing. Of particular importance is the linkage between technology, which includes information systems (IS) and information technology (IT), and the other "contextual dimensions", which include task, user, organization, environment, and developers and suppliers of technology. To assist with the interpretation of the various theories, the dimensions are collapsed into "action" and the "action frontier". Task and organization will be represented as a single construct called "action". Technology, user, developers and suppliers, and environment are the boundaries and constraining factors around task and organization, and the overlaps among these five dimensions will be called the "action frontier". The action frontier establishes the boundary of possible tasks and organizations. This implies that when examining information systems, we are not as concerned with the technology itself as with the "enabling" qualities Chapter 2: Literature Review 12 that the technology provides to the organization.11 The following diagram illustrates these two new constructs: Figure 2-1: Action and Action Frontier Action Frontier -environment -users -organization The "action frontier" sets the boundaries around the organization and its tasks; what it can do. "Action" is the actual tasks and organizational characteristics of an organization. Using the above conceptual diagram will help with the interpretation of technology and context theories. 1 1 This is somewhat similar to the socio-technical view of technology, suggesting that technology and organizational/task structure are matched and result in certain outcomes. Chapter 2: Literature Review 13 2.4. Four Theories of the Technology - Context In this section, four process theories of technology's linkage to context are described. The purpose of the theories is to provide a set of views of technology and context with which to describe and organize the literature and case data. Several key articles and books discuss the linkage between technology and the stakeholders of contextual dimensions, and identify four theories of technology-context interaction (Kling 198012; Kling & Scacchi 198213; Markus 198314; Van De Ven 198615; Markus & Robey 198816; Hirschheim & Klein 198917; Burton 199218; DeSanctis & Poole 199419; Myers 1994b20; Thomas 199421). The four theories are the technological imperative, organizational imperative, emergent perspective, and social technology. A summary of each theory is included below, providing a set of inference rules for categorizing the literature into the four theories: 1 2 Kling discusses systems rationalism and segmented institutionalism. 1 3 Kling and Scacchi discuss discrete entity and web models of computing. 1 4 Markus' theories include system driven, people driven, and two interaction theories: political and socio-technical. 1 5 Van De Ven's theories include technology-driven, customer or need-driven, and simultaneous coupling. 1 6 Markus & Robey include technological imperative, organizational imperative, and emergent perspective. 1 7 Hirschheim & Klein focus on the approach and assumptions of the developer toward the organization including functionalist, integrationist, radical structuralist, and neo-humanist. 1 8 Burton critically analyzes technological determinism and societal determinism. 1 9 DeSanctis & Poole include decision making, institutional school, and social technology. 2 0 Myers includes the technology acceptance, organizational change, and organizational problem-solving involving mutual adaptation. 2 1 Thomas includes technological determinism, social choice, and power-process. Chapter 2: Literature Review 14 Table 2-4: Process Theories of the Technology and Contextual Dimensions Linkage Perspective /Characteristics Direction of Causality Main Assumption Role of Users and Developers/Suppliers Technological Imperative Theory (TI) Technology to Context Technology carries impact within itself Developers have a simple role of technology installation. In moderate form, users can choose and use the technology. In extreme form, users have no choice. Organizational Imperative Theory (OI) Context to Technology. Context rationally chooses, uses, and/or develops technology to suit its needs. Designers implement technology identified by top management and/or integrated views of users. Emergent Perspective Theory (EP) Causality is complex between context and technology. Technology is composed of parts that carry social meaning. The result of context-technology interaction is explainable but unpredictable. Developers' and users' ideas and visions determine the criteria for selection, development approaches, the choice, the choices within the choice, and use. Social Technology Theory (ST) Social practices moderate the effect of technology on context. Both context and technology act as constraints and/or enablers Developers build technology within constraints and opportunities. Users adapt the technology within technological, environmental, and user constraints ISD research can be classified based on the researcher's implicit or explicit process theory and the stages and contextual dimensions studied. My purpose is to demonstrate how the framework and four process theories can be used to understand and integrate the ISD research. Most of the research cannot be strictly categorized into one theoretical area because the four theories are linked, and some research use conflicting theories. Chapter 2: Literature Review 15 2.4.1. Technological Imperative The technological imperative (TI) process theory states that technology impacts context in a unidirectional manner. In its strong form, TI claims that the action frontier is solely determined by technology, and that new technology external to the organization revolutionizes the environment. This revolution forces or allows the organization to adopt the technology and the new task configurations embedded in the technology. Developers have little role in implementing the technology, and users adopt the technology in a predetermined and uniform manner. The following figure illustrates the technological imperative theory: Figure 2-2: Technological Imperative Old Action Frontier Chapter 2: Literature Review 16 As the diagram demonstrates, the action frontier is changed by technology, and the organization must adopt the technology to align its tasks within the new action frontier. The organization is forced into mapping itself onto the new action frontier in order to survive. 2.4.2. Technological Imperative Research Much popular press coverage employs a strong technological imperative and a large percentage of information systems literature employs a moderate technological imperative. There is generally a future-oriented view of the effects of technology on the industry and society. Some focus on the impact of hardware such as information technology (IT) (Mohr 198723; Gurbaxani & Whang 1991), the "internef2* (Rheingold 1993) computers (Franklin 1990; Postman 1992; Talbott 1995), telecommunications (Hammer & Champy 1993), and computer networks (Sproull & Kiesler 1991).25 Some researchers focus on the impact of systems including group decision support systems26, interorganizational systems2'', expert Mohr (1987) claims that the computer has diffused into many spheres of life, overcoming behavioral inertia. Why? Because the computer can be used and integrated into routine change and readaptation including: search, imitation, craft modernization, market survival, slack distribution, status maintenance, recruitment, play, maturation-socialization, and constituency-satisfaction. Because the computer is seen as a homogeneous tool and solution to many of these issues, it is adopted and adapted easily. The article encompasses a number of principles from all four process theories. The internet is a short word for "inter networking", a term used to identify a growing computer communications system of networks linked together by a standard data communications protocol. This allows the passing of electronic messages and other data to other users on the worldwide internet, and the use of web browsers to see information on the "world wide web". In fairness to Franklin (1990) and Talbott (1995), they both suggest that it is the technological imperative that creates passivity amongst citizens and users of technology, disempowering them to take control of the technology's future. This suggests that the loss of control over technology can be regained through asserting an organizational or social imperative. Group Decisions Support Systems use a set of networked computers in a meeting room to structure and store information about a meeting into the computer. These tools help meeting participants to independently brainstorm ideas, set criteria for selection, reach consensus, vote, and select action steps and solutions. The most well-known interorganizational system is the Electronic Funds Transfer system used in Automated Teller Machines (ATM). Chapter 2: Literature Review 17 systems29, and executive information systems29, (Johnston & Vitale 1988; Sviokla 1989; George, Easton, Nunamaker & Northcraft 1990; Mohan, Holstein & Adams 1990). It is important to note that many of these studies do mention context's effect on technology, recognizing the sometimes unexpected outcomes of technological implementation. However, context is classified into categories, technology still plays the dominant role, and the underlying benefits of technology will be realized when context meets the technology's requirements. A technological imperative is recognized when an author or researcher places the emphasis on a technology's uniform and usually positive effect on context. As a result, technology is an object that can be described and separated from its context. This process is called "reification" (Berger & Luckman 1967; Ritzer 1992).30 In a stronger form, TI claims the context is irrelevant. This implies that technology is an object whose form and function (Rogers 1995) can be described and separated from its context. Thus, both the physical characteristics and the effect of technology on context is universal. 2.4.3. Organizational Imperative The organizational imperative (01) theory describes or recommends the use of a rational planning process to choose the technologies that will meet an organization's strategic objectives. The organizational imperative claims that the organization determines a new Expert Systems are a practical application of artificial intelligence, where the computer stores rules about a well-defined domain of knowledge that can then be used to reach conclusions and suggestions for users based on an initial set of variables. EIS is a decision tool using graphical interfaces to summarize data, and "drill down" capabilities to see the details of the summary information. Berger & Luckman define it as "the apprehension of human phenomena as if they were things, that is, in nonhuman or possibly supra-human terms" (p. 89). Chapter 2: Literature Review 18 action configuration, purchases or develops technology to transform the action frontier, and then moves the organization into this new frontier. Like the technological imperative, technology is still viewed as having deterministic effects on the action domain, and the organization and tasks will almost completely overlap the action frontier. The organizational imperative also views the action frontier as being composed largely of technology. Unlike the technological imperative, the organizational imperative claims organizations use rational choice to choose and/or shape the technology.31 The role of developers is to implement technology chosen by top management, and the role of users is to adopt the technology according to top management plans. If there are problems with technology development and implementation, it is because of low resources and/or uncertainty about the environment (Kling 1980). The following figure illustrates the organizational imperative theory: However, we will see a number of references from the technological imperative section in the organizational imperative literature. Figure 2-3: Chapter 2: Literature Review The Organizational Imperative 19 Old Action Frontier As the diagram illustrates, the organization chooses or builds technology that allows it to move into a chosen action frontier. Technology is rationally chosen by the business executives. The mapping between organization and action is almost one-to-one. 2.4.4. Organizational Imperative Research Extensive information systems literature displays an organizational imperative. Strategic information systems planning (SISP), system design and analysis (SDA), task/technology fit (TTF), and integrative and 'human relation' (Kling 1980; Hirschheim & Klein 1989) forms of participative design and user involvement (PD&UI) are four research areas employing an organizational imperative. SISP and SDA focus on the environment task Chapter 2: Literature Review 20 and organizational dimensions. PD&UI focuses on the user, developer/supplier, and technology link. SISP and SDA are more top-down approaches to information systems development while integrative and functionalist forms of PD&UI are bottom-up approaches. Strategic Information Systems Planning (SISP) research provides planning methods to harness information systems and technology to achieve business advantage in the industry (McKenney & McFarlan 1982; McFarlan, & McKenney 1983; McFarlan, McKenney, & Pyburn 1983; McFarlan 1984; Earl 1989). Case studies of specific firms achieving or losing competitive advantage through the use of IS and IT are used as evidence of technology's role in achieving competitive advantage (Johnston & Vitale 1988; Main & Short 1989; Kim & Michelman 1990; Reich & Benbasat 1990). In this sense, SISP posits an organizational imperative theory linking technology to context. Organizations use the technology to achieve competitive advantage to make higher profits. IT is viewed as a powerful tool for achieving strategic goals, and IS and IT are either fully shaped or picked by the organization because of inherent capabilities. In most cases, little is mentioned in the SISP literature about important stages of ISD including idea generation, prototyping and implementation. The key to achieving the competitive advantage is broad IS management and planning (McFarlan, McKenney & Pyburn 1983; Earl 1989). Planning here tends to follow a rational and top-down approach from business strategy to information systems planning. The result is a "linkage"32 between the business strategic plan and the IT/IS strategic plan in the deployment of information systems and information technology to achieve business objectives. "Linkage" is a term used to describe the fit between information technology, information systems, and the goals of the organization. Chapter 2: Literature Review 21 System Design and Analysis (SDA) is a close partner with SISP, and includes processes and tools used by organizations to develop systems identified by strategic planning. Thus, SDA and SISP coexist together in comfort. Examples of SDA include business process reengineering and structured information systems development. Business Process Reengineering (BPR) promotes the importance of organization, environment, and/or task, but suggests that redesign should follow a prescriptive path: organizational structure needs to change to realize the full potential of the technology (Davenport & Short 1990; Hammer & Champy 1993). The fundamental error that most companies commit when they look at technology is to view it through the lens of their existing processes. They ask, 'How can we use these new technological capabilities to enhance or streamline or improve what we are already doing?' Instead, they should be asking, 'How can we use technology to allow us to do things that we are not already doing?' Reengineering, unlike automation, is about innovation. It is about exploiting the latest capabilities of technology to achieve entirely new goals. (Hammer & Champy 1993, p 85). Structured Information Systems Development (SISD) employs an engineering approach to system development, using methods, tools, and techniques as "social technologies" that are promoted as essential for developing successful information systems. Entity Relationship (ER) diagrams33, Object Oriented Design3 4, and Data Flow Diagrams35 are A diagrammatic technique that is used to model business data that allows easier generation of database designs (especially the relational database design). A diagrammatic technique that models objects, object attributes, methods (i.e. actions that can be carried out by an object), and message communication between objects. The result is a diagram that can be easily programmed in object oriented programming languages. Used as a counterpart with Entity Relationship Diagrams, this diagramming technique models the flow of data and the transformation of that data in processes. Using a hierarchical decomposition, these processes are further developed into subprocesses that exchange data until the lowest level process is mapped. The result is a technique that can easily be programmed into the traditional structured programming languages. Chapter 2: Literature Review 22 all examples of social technologies used in information systems development (Coad & Yourdon 1991; Kendall & Kendall 1992).36 Task Technology Fit (TTF) research addresses the need to design the technology to fit a certain task and/or setting. Most of this research is descriptive, with studies of differences between performance when technology does and does not fit the task, and with prescriptive messages recommending a need to design technology for the task. Task/technology fit evaluates the fit by examining objective characteristics of the task and technology. Two areas of task/technology fit include system!task fit, and information/task fit (DeLone & McLean 1992). System/Task fit claims that certain tasks and production processes require certain information systems. For example, Cooper and Zmud (1990) examine the system characteristics of Material Requirements Planning (MRP) systems37, and their adoption and infusion amongst organizations with more versus less complex production planning and control tasks. More complex planning and control tasks were assumed to violate the assumptions of MRP which is more appropriate for continuous production. Cooper & Zmud's (1990) results confirmed that adoption of MRP was decreased by more complex production planning and control tasks, but the correlation with infusion was weaker. They assert that politics and learning as compared with rational models are likely to be more appropriate for later stages of implementation. 3 6 In this respect, SISD represents an unusual hybrid of technological and organizational imperatives. The view is technologically imperative suggesting that the use of a technological technique will have a deterministic effect on successful IT development. SISD is also an organizational imperative because the promoters claim that using the tools will allow organizations to build information systems that meet their information needs. 3 7 MRP systems are used to plan and gather the materials required for future production runs based on orders, and a detailed inventory of the parts required to produce each product. Chapter 2: Literature Review 23 Examining information/task fit, the content and format of the information produced by the system must match the task requirements: accurate, precise, current, timely, reliable, complete, understandable, and relevant. A number of IS research areas are focused on testing and improving information quality given certain users and tasks. Human/computer interaction is focused on the fit between technology's information quality and task. These studies evaluate task performance based on availability of computerized technology (system and information quality) and/or the features of two computerized technologies (information quality) (Benbasat, DeSanctis & Nault 1993). Some of the features include graphs versus text (Tan & Benbasat, 1990), color and graphics (Benbasat & Dexter 1985a & 1985b), and icons versus menus (Benbasat & Todd 1991). Participative Design and User Involvement (PD & UI) research focuses on the interplay between the user, the developer and the information systems during design, development, and/or deployment. User involvement is a specific instance of participative decision making and group problem solving, and there is a general belief that user involvement is necessary for information systems success (Ives & Olson 1984; Baroudi, Olson & Ives 1986). "Integrationist" and "human relations"38 approaches (Kling 1980; Hirschheim & Klein 1989) to user involvement can be considered an organizational imperative. These approaches to development constitute a bottom-up organizational imperative involving users in building information systems that meet organizational needs. Three explanations of the reasons for Integrationist and human relations approaches to development realize that organizational life is interpreted by the members, and that integration can be achieved through discussion and consensus. Chapter 2: Literature Review 24 successful development of IS and IT with user involvement include self control (Baronas & Louis 1988), learning between, both users and developers (Franz & Robey 1984; Newman & Noble 1990), and conflict resolution and accommodation (Franz & Robey 1984; Robey, Farrow, & Franz 1989; Checkland & Scholes 1990; Newman & Noble 1990). Al l three approaches implicitly or explicitly assume that individuals may have different ideas about successful IT implementation and the goals of the organization, and that involvement achieves consensus through discussion (Robey, Farrow & Franz 1989; Newman & Noble 1990). Variance research by Baroudi, Olson, & Ives (1986) confirms that user involvement leads to both increased system usage and information satisfaction, and that increased information satisfaction leads to increased system usage.39 Therefore, like the technological imperative, the organizational imperative assumes that computing technology delivers specific impacts. Unlike the technological imperative, technology is chosen and shaped by the strategic direction of the organization. Organizational imperative processes include strategic IS planning, system analysis and design using top-down approaches, and integrative and human relation forms of user involvement. 2.4.5. Reflections on Unidirectional Theories of Technology-Context Interaction There is widespread evidence to suggest that both the technological and organizational imperative are unable to explain aspects of ISD and computing development. The strongest evidence against the technological imperative is the high divergence of technology from Thus, demonstrating that users are using a theory of reasoned action approach to system use. Chapter 2: Literature Review 25 perceived goals, including failure (Lyytinen & Hirschheim 1987). Many researchers have alluded to the failure of information technology implementation (Dutton 1981; Lyytinen 1987, Hirschheim and Newman 1991; Myers 1994a; Keil 1995). Forester & Morrison (1990) report that 75% of information systems are either not developed or i f developed, are never used. Other authors report similar results (Gibbs 1994; Landauer 1995). Whether this "failure" is defined by subjective expectations, differences between stakeholder goals, or technical failure, nevertheless weakens the direct connection between context and technology described by the organizational and technological imperatives. Second, there is a lack of consistent findings using similar techniques and technologies, implying that context may have a very important and complex effect on outcome (Orlikowski 1991). Third, an examination of a technology's origins before becoming an object, to be adopted and used, is missing. Fourth, developers' ideas and vision appear to be crucial in technology development (Schon 1983; Turner 1987; Beath & Orlikowski 1994; Petroski 1994; Thomas 1994). Discounting of the technological imperative, however, does not imply acceptance of an organizational imperative (Thomas 1994). First, the organizational imperative cannot escape the problem of technological failure and divergence, without resorting to a call for greater use of its already widely adopted approaches. Second, system planning is missing from many successful IS and IT developments (Turner 1987; Lyytinen 1987). Some researchers remark that the belief in an organization's control of the market through the introduction of IT is very unlikely in the best case, and can be damaging to the organization in the worst case (Harrington 1991). Third, many of the system design and analysis techniques have been Chapter 2: Literature Review 26 criticized for their limited focus on technical issues, and ignorance of social aspects (Kling 1980; Kling & Scacchi 1982; Lyytinen 1987). In addition, system design does not generally follow the top-down and "life-cycle" approach advocated by these methods, and when it does, failure is still high (Gladden 1982; Turner 1987).40 There is also little evidence to suggest that these formalized techniques have significantly improved system success, and a textual analysis of these methods has revealed contradictions (Beath & Orlikowski 1994). Fourth, even though the task/technology fit literature recognizes the importance of context, its method of placing context in boxes ignores its complex interaction and influences on ISD, rendering the categories irrelevant for specific circumstances.41 And finally, there has been inconsistency in results of user involvement on project success if seen as a "factor" necessary for system success (Ives and Olson 1984; Brooks 1987; Hirschheim & Newman 1991).42 As a result, several researchers criticize the technological and organizational imperatives as naive. Burton (1992) states: A moment's thought will show that both approaches [technological imperative and organizational imperative] are open to criticism. Neither, for example, pays attention to the complex inter-linking of society and technology, in which cause and effect are so difficult to disentangle, while technological determinism removes any human values from the process of technological development, (p. 22) 4 0 The life-cycle approach argues that IS development should follow three structured steps: requirements analysis, design, and implementation. 4 1 Checkland & Scholes (1990) comment that in the real life of managers, it is the details that matter, not generalized theories. 4 2 Some have criticized the lack of understanding of the different approaches to user involvement and its effect on system development success (Bostrom & Heinan 1977; Boland 1978; Olson & Ives 1984; Wynn 1991). These differences include the level, stage, quality, and intent (cooperation versus co-optation) of user involvement. Added to this would also be the characteristics of the user group, their position in the organization, and their relationship with the development team (Markus 1981). Olson & Ives (1984) also criticize the research for lacking a theoretical basis to explore user involvement and the causal mechanisms that lead from involvement to technological design and implementation. Chapter 2: Literature Review 27 Thomas (1994) provides a critical comment on both approaches: But both perspectives share a common flaw; because they focus attention primarily on the structural outcomes or impacts of change, they tend to portray the relationship between technical and social systems as static and unidirectional. By neglecting the process of change — especially the process through which choices of technology are made—they generally fail to capture the dynamic and interactive nature of the relationship between the technical and social systems of an organization....to explain what new technology does to organizations—or as it is commonly put, 'how technology impacts organizations'—we must also explain what people are trying to do to organizations and, by extension, to themselves by means of new technology. First, it is not enough to claim that technology 'impacts' organizations; it is essential to ask as well how and why particular technologies are chosen. Second, it is not enough to claim that technology is the simple product of social or strategic choice; it is essential to ask as well how technological alternatives were themselves framed, how the objectives or interests of different organizational actors shape the range of possibilities considered, and, most important, how differences in objectives or interests influence the outcomes of change, (p 4) The technological imperative and organizational imperative fit the description of discrete-entity^ models provided by Kling & Scacchi (1982). They observe that most information systems are developed by multiple groups and thrive in multiple settings, and therefore do not meet the assumptions of the formal-rational perspective implicitly advocated by the technological and organizational imperatives.44 The following sections explore alternative theories of technology-context.45 The alternative process theories are the emergent perspective and the social technology theory. 4 3 Discrete-entity models examine information technology in isolation from the context that surrounds its usage and operation. 4 4 Hirschheim & Klein (1989) develop four paradigms of system development based on ontology (objective/subjective) and conflict (conflict/integration). The TI and OI fit into their functionalist category where the view of the developer is that the organizational mission and goals are integrated and that the ontology is objective. 4 5 These process theories would be explained best by Kling & Scacchi's (1982) web models and Hirschheim & Klein's (1989) radical structuralist, and neo-humanist perspectives. Chapter 2: Literature Review 28 2.4.6. Emergent Perspective The emergent perspective (EP) theory (Markus & Robey 1988) states that a complex interaction occurs between context and technology over time. In this sense, the action frontier has weakly defined boundaries, allowing a large set of task, organization, and technology configurations to emerge from this interaction. In its stronger form, EP states that technology and context are inseparable. Every context and technological appropriation and adaptation is unique. Developers and users determine the method of selection and criteria, the choice, the "choice within the choice" (Thomas 1994),46 and implementation approaches. The following figure illustrates the emergent perspective theory: Figure 2-4: The Emergent Perspective on Technology and Context Action Frontier weak or non-existent ^ T j m e B of action over time Thomas' (1994) phrase for the second level choices made after a software platform is chosen. Chapter 2: Literature Review 29 In the emergent theory, the interaction between technology and context appears somewhat or largely unpredictable. A key part of this complex interaction is that designers and users play crucial roles in design and use (Olson 1981; Nadler 1982; Franz & Robey 1984; Olson & Ives 1984; Petroski 1994; Thomas 1994). 2.4.7. Emergent Perspective Research The research addressing emergence and the issues and methods of designing in emergent settings includes the following: the influence of the designer's world view; alternative views of system development; the predicament of design; the emergent evolution of technology; and the innovation process. Although the research is generally descriptive, prescriptive messages imply that the inability of designers to understand and deal with emergence leads to irrelevant systems that are rejected. An increasing body of literature reveals that the designer's world view affects ISD. Given that many designers are being trained with a technical focus to development, assumptions about social, organizational, and political environments surrounding development and implementation are immature and undeveloped (Bostrom & Heinen 1977; Kling 1980; Dutton 1981; Kling & Scacchi 1982; Gladden 1982; Markus 1983; Robey & Markus 1984; Hirschheim & Klein 1989; Hirschheim & Newman 1991; Myers 1994b). Specifically, there is growing criticism over the mechanistic and deterministic view of organizations by developers.47 The design approach of "scientism"48 and technology focus is criticized by Bostrom & Heinan (1977) are quick to suggest that the blame does not lie entirely with the developers. Complex social and environmental demands and assumptions produce a technical focus. Scientism is the general approach to inquiry that focuses on universal laws of human behavior, disregarding the setting, and ignoring the human "free-will" and contextual influence on the object of study. Chapter 2: Literature Review 30 Bostrom & Heinen (1977), Markus (1981), Gladden (1982), Nadler (1982), Schon (1983), Klein & Lyytinen (1985), Boland (1987), Hirschheim & Klein (1989), and Harrington (1991) 4 9 The misuse of the rational approach by professional groups has also been more generally discussed in philosophy (Saul 1993; Saul 1995). Prescriptive messages from this literature claim that the inability of designers to understand and deal with emergence leads to irrelevant systems that fail because they ignore or simplify users and context (Landauer 1995). A prepared developer would be able to deal with opportunities and/or pitfalls that arise during emergence.50 Some researchers in the ISD and technology literature provide alternative views of design. As a result of the increased complexity of design environments and changing expectations of the methods and goals of ISD (Klein & Hirschheim 1985), a changing mindset has appeared to deal with a number of "failures" in the planning and design (P&D) fields (Nadler 1982). These include: arranging for continual change, using information from many sources, involving people, specifying and presenting a solution (communication), and focusing on solution quality, solution implementation, and effective use of P&D resources. Brook's (1987) suggestions for improving software design are not technological but social and context related. First, organizations should buy instead of build software, because the myriad of general purpose software packages on the market makes building less attractive. Second, iterative development and rapid prototyping should be used, because the hardest part Harrington (1991, p. 199) suggests that designers want to implement first and ask questions later. This approach is encouraged by suppliers and software vendors. Harrington (1991) provides a gloomier picture, claiming that the complex web of computing and its effect on organization is somewhat akin to a lottery, even with prepared developers and suppliers. Luck has an important part to play. Chapter 2: Literature Review 31 of software development is not building, but determining what to build. Third, incremental development should be employed to "grow" software instead of build software. Finally, great designers address an important creative process required to produce excellent software. Hirschheim & Klein (1989) remark that most developers assume organizations are integrated enterprises and reality is fixed and stable, a "functional"51 perspective. Alternative views of development acknowledge the political and fragmented nature of some organizations. Some methods of applying the alternative views are through the use of "integrative"52, "radical structuralist" and "neo-humanist" approaches. Kling (1980), Kling & Scacchi (1982), Kling (1987), Myers (1994b) and Thomas (1994) report that the environment around information systems development and operation is conceived too narrowly and incorrectly. The a priori boundaries, set by developers before development begins, often ignore important relationships that are crucial to short-term and long-term survival of an information system. Kling & Scacchi (1982) compare "web"5 3 versus "discrete" models, and claim that web models more directly challenge some of the assumptions of discrete entity models, and explicitly examine those areas ignored by discrete entity models. These areas include "social leverage", narrow boundaries, and historical constraints and commitments. "Social leverage" means that some groups will win while others may lose on the larger social terrain. Narrow boundaries often fail to include suppliers and vendors and other groups essential for system 5 1 The "functional" perspective assumes organizations are united entities, with little conflict, and integrated goals that achieve specific ends for the organization and society. The term "functional" is most likely a short-hand for Talcott Parson's "structural functionalism" found in the sociological literature. 5 2 "Integrative" implies that the organization is integrated in its views, but the views are subjective and can be altered. 5 3 Web models focus on the many contextual factors that develop, influence, support and sustain IT and IS within a setting. Chapter 2: Literature Review 32 success. Historical constraints and commitments requires an understanding of the organization's history and the emerging social relations and connections between organizational groups and with groups external to the organization. Discrete entity models either ignore or believe these relationships are forged over a short period of time. The result is a weakened link between technology and organizational structure, given the overriding importance of specific "situations" within each case. Boland (1987) and Wurman (1990) observe that decision making is not a mechanistic mixture of data, a human receiver, and behavior. We are fostering an image of the world in which the human meaning of knowledge and action are unproblematic, predefined, and prepackaged. (Boland 1987, p. 365). Boland's (1987) use of the word "in-formation" implies the more idiosyncratic and direct involvement of individuals in forming attitudes, intentions, and actions using the information. "Words are symbols and meanings are always multiple and ambiguous" (p 366). The result is to place the human actor back into the information, decision, and behavior chain. Boland (1985 & 1990) provides hermeneutics54 and phenomenology55 as alternative approaches to system development. 5 4 Hermeneutics is the study of textual interpretation, and the process of understanding that text. Boland (1990) suggest that hermeneutics is a good method to examine the output of an information system; because it does not assume information is a reflection of reality, but needing to be constructed by the reader. Boland pulls in three views of hermeneutics: Pepper's world view as a background metaphor that channels interpretation, Rorty's contingency approach to language as being ever-changing and not simply representing finer grains of reality, and Ricoeur's distanciation where the ideas and thoughts of the writer are separated in text, and readers must come to appropriate the alien text in their own way, "to make ones own what was initially alien". 5 5 Boland (1985) discusses phenomenology. Phenomena is the essence of our experience: that which remains after the accidents, contingencies, and pre-suppositions we bring to our every day experience. Essences are not grasped empirically, but are grasped through intuition. This cycle of essence, from experience to purified understanding, is continual. It tries to grasp the hidden assumptions behind interpretation. Tied to hermeneutics (the reading of text), it is grounded in description. It is critical because it attempts to understand hidden assumptions about our beliefs of reality. Applied to IS, it tries to use phenomenology to understand text. Because of the historical understanding of text and information, the central problem of meaning ignored in traditional IS design is brought to the forefront with Chapter 2: Literature Review 33 Examining user involvement (UI), the organizational imperative approach to UI would use it as a method of building an integrated consensus of task and technology, and/or increasing system acceptance (Bostron & Heinan 1977). The research on user involvement, however, points to inconsistent findings when UI is viewed as a factor (Olson & Ives 1984; Robey & Markus 1984; Robey & Franz 1989). In addition, Hirschheim & Newsman (1991) observe that user resistance may indicate a legitimate problem with the software, integrating information systems may undermine existing commitments and power structures in the organization, the gulf between developers and users is widened by assuming the system developer knows best, IS development and politics are intertwined, and political support is necessary for any successful implementation. As a result, a more emergent view of user involvement as a complex process of information system development is mentioned in the literature. This includes "design-in-use", "participative design", "soft systems development"56 and "spiral development" (Markus 1981; Markus 1983; Franz & Robey 1984; Olson & Ives 1984; Boehm 1988; Gould 1988; Hirschheim & Klein 1989; Checkland & Scholes 1990; Newman & Noble 1990; Henderson & Kyng 1991; Wynn 1991; Newman & Robey 1992; Landauer 1995).57 These views of user involvement move closer to an accommodation, and "neo-humanist" and political approaches to UI. Each assumes that organizational reality is phenomenology. Prejudice is seen as a positive thing because it allows us to experience the text. Based very much on the individual's experience and history, the same text can produce very different meanings. A development approach focused on the human side of computing; hence the word "soft". The result of this process may be what Weiser (1991) calls ubiquitous computing; a vision that good computing technology disappears into the background of work because it is well designed for the task. Key to this is a match between the physical and interface characteristics of the technology and its match with the tasks and user expectations and learning. Chapter 2: Literature Review 34 not fixed and that organizational groups and individuals are divided in their goals and views of organizational life (Franz & Robey 1984; Hirschheim & Klein 1989). "Design-in-use" assumes that individuals in an organization carry special knowledge of their work, including both "doing" and "understanding" (Henderson & Kyng 1991). As a result, the top-down approach to software design is unable to handle emergence: changes in situations may make the software irrelevant, complexity of the organization and environment makes it difficult to anticipate every aspect of the organization and system usage, and many different situations of use create a problem of logically deducing every aspect of the software before implementation.58 The "adaptation" principle of software design is important for building successful software that can handle task, user, and organizational emergence.59 Four characteristics of adaptable software are required: flexible (objects of the system can be interpreted in many ways); "parameterized" (providing a menu of behaviors from which to choose); "integratable" (system can be integrated into other systems/software); and "tailorable" (user can change the parts through accelerators, specialization, and added functionality) (Mohan, Holstein & Adams 1990; Henderson & Kyng 1991).60 In addition to the designer's view and role in ISD, the complex environments of technology causes inherent predicaments with planning and design, implying a risk of technological divergence from original plans and failure for unprepared designers. Nadler ; This is especially true for "canned" or "shrink-wrapped" software that will be used by many users in many different locations. Landauer (1995) disagrees, suggesting that tailorable software can produce too many features and complexity in the software. The "tailorability" idea also assumes that users can measure and evaluate their productivity using different approaches. Human computer interaction suggests that there are universal interface designs that help everyone. ' Henderson & Kyng mention that "object oriented" design and programming is providing many tools for addressing tailorability through inheritance, reusability, and alteration of existing objects. Chapter 2: Literature Review 35 (1982) discusses planning and design (P&D) in general, and Turner (1987), Harrington (1991), and Landauer (1991) discuss system development design specifically. Each provides a similar analysis as Brooks (1987) about the inherent complexity and problems with P&D. The issues facing the P&D field today are very complex, with less definable problems being addressed than in the past (Nadler 1982; Schon 1983). In addition, the environments or causal texture of environment61 around technology have been categorized as more turbulent, less predictable and more inter-connected than in the past (Emery & Trist 1971; Terreberry 1971). The result has been a gross increase in the area of relevant uncertainty (Emery & Trist 1971). Combined with the complex problems is a continued focus on rational/mathematical models and theories. As a result, the following problems have appeared: concentration on solution finding; theories that fail to incorporate psychological and sociological realities of the business or professional world; classification of problems by techniques rather than ends; solutions that lack creativity; splitting of problems in specialized and piecemeal fashions; focus on the "expert" role to the detriment of other more important roles (facilitator, negotiator, coordinator, advocate, and motivator); creation of data overload; and poorly related P&D groups that require closer coordination. In addition, computing technology can radically alter the perception of individuals, producing an imbalance with the other social dimensions of the organization (Harrington 1991; Thomas 1994). Designers appear to disregard and/or downplay these dimensions (Bostron & Heinan 1977; Schon 1983; Boland 1987). A term used by Emery & Trist to describe the complexity and independence of environmental influences around an organization that operates within that environment. Chapter 2: Literature Review 36 Information systems is a P&D activity with its own unique problems: abstraction and "invisibility"; correspondence with unspecified and complex human behavior; changeability; pressures to adapt and incorporate many political views; dependence on a rapidly changing software environment;62 and correctness subject to verification (Brooks 1987; Turner 1987; Forester & Morrison 199063; Harrington 1991; Landauer 1991; Gibbs 1994; Keil 1995).64 Central to many of these issues is that system development involves both problem definition and problem solution simultaneously (Turner 1987; Thomas 1994). Candidate ideas are presented, creative leaps and prior experience are employed to reach these candidate ideas, and prototyping is used to test these ideas (Landauer 1991). Therefore, the predicament of design produces emergence.65 Also supporting emergence is the literature examining the evolutionary and emergent development path of technologies. Several researchers discuss the history of technological evolution from an emergent perspective (Kidder 1981; Latour 1987; Harrington 1991, Dutton's work (1981) provides some interesting insights into the implementation failure of a land planning system (Growth Guidance System - GCS) in the Tulsa municipal government. Dutton's case suggests that the shifting context surrounding IS and IT affects the "appropriateness" of the technology. The CGS was originally designed in a municipal context of controlled land development. When a new pro-growth mayor was elected close to the end of the CGS development cycle, the software was reused to support the pro-growth approach, illustrating the malleable nature of the CGS. Without direct top-level support, however, the system slowly floundered and was abandoned. This case illustrates an emergent perspective of IS. Forester & Morrison (1990) state that software is prone to total rather than partial failure, and enormous complexity means that software can never be fully tested before use. Landauer (1991) suggests that general theory in human-computer interaction is impossible, and that homely and minor impact theories have proven more useful. Many interface ideas emerge from lucky hunches, and iterative testing and analyzing with users. Newman & Robey (1992) state that a complex process of development does not imply chaos and unpredictability. Each stage of development leads to a certain probability of other stage appearing. Their research examining the stages of development in two cases was somewhat predictable from theory. The nature of environmental shocks and the comparison of initial and final plans, however, produces emergence. Chapter 2: Literature Review 37 Franklin 1992; Latour 1994, Petroski 1994; Thomas 1994; Keil 199566). This emergence results from the influence of many groups and individuals involved in design and usage of the technology over time. Kidder (1981) describes the history and people involved in building a Data General computer, and the impact of events, conflict, and controversies on design. Latour (1987 & 1994) describes the controversy surrounding technology and science, and the disappearance of these controversial decisions into the technology long after the controversy has disappeared.67 Basalla (1988) and Petroski (1994) examine the diversity and evolution of various technologies including the paper clip, stapler, barbed wire, and the cotton gin. 6 8 Both conclude that technology emerged from previous natural and man-made templates and evolved through usage and modification by many individuals. Both authors consistently demonstrate how form does not follow from function, as demonstrated by the diversity of tools used for the same task.69 This emergence of technology for a task is the norm in technology development. Franklin (1992) provides a critical examination of technological evolution by examining environmental and social conditions that have affected how we perceive, behave, and modify technology. She examines the evolution from 'holistic' to Keil's "escalating commitment" of software development provides a theory of "run away" ISD. This research can be linked with the concept of ubiquitous computing, where good technology becomes hidden and embedded in organizations and society (Winograd & Flores 1987; Weiser 1991). Petroski hesitates to use the word 'evolution', because to him, it implies random variation. Instead, he states mat variation in technology is driven by annoyance, market differentiation, and purposeful action. Petroski recounts the story of a designer called to the witness stand in a client's case against a manufacturer who had stolen his client's design. The defense's case rested on the inability to produce any other design that would be practical and functional. When the designer was called to the witness stand and asked if he could draw alternative designs, the designer recounted: "I unfolded my easel, placed the drawing board on it, and started making rapid sketches in large black outline, visible to anyone in the back row. Ten minutes later, I had about twenty-five designs, all different, most of them attractive, all of them practical" (p. 178) Chapter 2: Literature Review 38 'prescriptive' technologies as being historically based on the division of labor, the industrial revolution, and the power struggle between capitalists and workers. The result of unguided technological development has produced such unplanned and undesirable properties as pollution, fragmented communication, and poor coordination. Several IS researchers have alluded to IT/IS as an innovation (Kwon & Zmud 1987; King, Gurbaxani, Kraemer, McFarlan, Raman, & Yap 1994), implying that design and the interaction between technology and context is emergent. The term "innovation" is defined by Van DeVen (1986): the development and implementation of new ideas by people who over time engage in transactions with others within an institutional order (p. 590). Van De Ven (1986) discusses several key problems in the process of managing an innovation, providing useful insights on the developer's role linking context to technology. First, the problem of "managing attention" is based on the individual's physiological limitations to handle complexity. Key to the human attention problem is the slow reaction of groups to deteriorating situations, and the crisis approach to innovation that emerges when a full-blown catastrophe strikes. Second, while idea generation is an individual activity, converting ideas into "good currency" requires commitment and collective agreement amongst many groups and individuals. This requires an understanding of the stakeholders around an innovation and the process of involvement bringing these groups together in coalitions. Third, management of part-whole relationships warns that the project should not lose focus of its larger purpose and direction. More often than not, large projects are split into separate tasks to be handled by various groups, with the result that the integration of the parts produces poor Chapter 2: Literature Review 39 results. It must be understood that most projects are a collective achievement, and require the understanding, commitment, and collective wisdom of many groups.70 Finally, institutional leadership and an innovation context are required to allow the innovation to flourish. Mission, purpose, values, and excitement are required in the organization to create an environment that supports innovation, and to foster innovations that support the environment. Contextual events and structures around a project can substantially influence the learning of a development team. Van De Ven & Polley (1992) longitudinally examined the learning that occurs around a new innovation over an eight-year period, examining the contextual structure surrounding the project leading to poor learning and product failure. The macro-structure around the project inhibited early learning about the innovation's problems, as the innovation team continued to 'sugar-coat' the results, and activities concentrated on maintaining funding. In addition, the noisy nature of feedback confused the project leaders as good, bad and mixed signals poured into the meetings. Learning an innovation's capabilities regarding work is important to technological adjustment. Attewell (1992) focuses on the supply side factors and its effect on IT development, adoption and infusion. He calls his approach the knowledge-barrier institutional-network approach. In this theory, communication is viewed differently than the "signaling" and "knowledge transfer" approaches in classical diffusion theory. Learning how a new technology can improve organizational productivity involves a slow process of A key concept in Van De Ven's management of the part-whole relationship is the "hologram" (Morgan 1986); where key elements of the entire project are present with the subunits working on the tasks. The linear approach to project development, from research to development to marketing, should be replaced by simultaneous coupling. Redundant functions allow key elements to be socialized into group members. Requisite variety requires the complexity of the real world to be built into the unit. Chapter 2: Literature Review 40 organizational learning called "learning by doing" (Carrol & Mack 1984). Frequently, unexpected changes in organizational structure and processes are difficult to predict and this change must be learned through a painful readjustment. The result is that technology can be either "competence-enhancing" or "competence-destroying", building on previous work methods or rendering previous work methods obsolete. In addition, Attewell (1992) identifies that technology needs to be learned in the setting, to determine its capabilities and interaction possibilities with other systems, a process called "learning by using". The result is that a large amount of knowledge is not transferable, but specific to the organization. Attewell proposes the following consequences of the knowledge-barrier institutional network approach: (1) technical knowledge needs to be relearned and reinvented by the organization; (2) the burden of organizational learning becomes a barrier to adoption and adaptation; and (3) the supplier must provide more than just the equipment, software, and some information about benefits and technical usage. To summarize, the emergent perspective differs from the technological imperative and the organizational imperative by suggesting that context and technology interact in a complex and somewhat predictable process. Prescriptive messages from this literature remark that the inability of designers to understand and deal with emergent shocks from the environment and learning will most likely lead to irrelevant systems that are rejected. An emergent environment around technology may produce opportunities and/or pitfalls that a prepared developer may be able to deal with effectively. 2.4.8. Social Technology DeSanctis & Poole (1994) construct a fourth theory, the social technology (ST) Chapter 2: Literature Review 41 theory, which posits a "soft-line determinism" between technology and context. Equal focus is provided to both the constraining and enabling features of a technology and context. This fourth view of the technology/context link is diagrammed below: Figure 2-5: Social Technology Theory Old Action Frontier composed of technology, organization, environment, and developers/suppliers Organization shifts somewhat unpredictably to intermediate action frontiers created by organization and chance Final Action Frontier planned and unplanned Time In the ST theory, technology provides a larger domain of action than the technological or organization imperatives, but still has a definite boundary. Actions closer to the boundary are less likely to occur, and actions outside the boundary are impossible. Surprises emerge when action appears in an undesirable position within the action frontier. Chapter 2: Literature Review 42 2.4.9. Social Technology Research Social Technology studies of IS/IT development tend to arise from descriptive accounts of technological implementation and technology's effect on or reaction from organizations. The interaction between technology and context in these studies resembles emergence, but from identifiable characteristics such as mismatches between organizational structure and technology. The research on social technology comes from two areas of research: adaptive structuration and structural power. Both suggest that the interaction between structure and technology is explainable, but only after implementation has occurred.71 Adaptive structuration theory hypothesizes an interplay between the structure of technology and the structure of organizations. Both constrain and/or enable the other. Various researchers examine and discuss the constraining and enabling interplay between context and technology (Thompson 1967; Barley 1986; Ottoson & Green 1987; Zuboff 1988; Weitz 1990; Harrington 1991; Orlikowski 1991; Orlikowski & Robey 1991; Orlikowski 1992a, 1992b; Tyre & Orlikowski 1994). One of the earlier discussions on the constraining and enabling role of technology and context was Thompson's (1967) work. According to Thompson, the main goals of the rational organization are to reduce the uncertainty around the cause-effect relationship between technology and production (technical rationality), while maintaining a product/service that was relevant to the supplier and consumer environment (organizational rationality). Classifying technology into three types, long-linked, mediating, or intensive The research assumes that enough empirical evidence will determine the capabilities of a technology in certain organizational settings, and/or the transmission mechanisms between technology and context that can be eventually controlled by developers (Orlikowski & Robey 1991; Orlikowski 1992a; Orlikowski 1992b). Chapter 2: Literature Review 43 technologies72, Thompson provides various propositions about the proposed fit between core technology, organizational structure and environmental conditions, providing some early ideas of adaptive structuration. Moving specifically to the structuration of IT and context, Orlikowski's (1992b) study of Lotus Notes in a consulting organization points out the unexpected but understandable effect of structure on groupware technology adaptation. Because the culture of competitiveness provided few incentives for sharing information with Lotus notes, the software failed to be adapted and infused into the organization. She comments: where the premises underlying groupware are incongruent with those of the organization's culture, policies, and reward systems, it is unlikely that effective cooperative computing will result without a change in structural properties (p. 368). Tyre & Orlikowski (1994) provide a general description of the interaction between technology and organizational structure through the stages of adaptation and routinization. Challenging the view of continuous and rational acceptance and adaptation to new technology, they studied three organizations: one implementing new precision metal tools, one implementing C A S E 7 3 tools, and one implementing personal computers with users at a university. Their findings demonstrate that short and dramatic changes in work occur at discontinuous points over time. They conclude that the following factors influence this unexpected pattern of adaptation: the need and drive for production impedes adaptation; unchecked work patterns congeal and constrain further adjustments; expectations adjust 7 2 Intensive technologies are the best definition of the core technology used in hospitals. 7 3 Computer Aided Software Engineering that support analysis and design. Chapter 2: Literature Review 44 downward to match less than optimal work patterns; and team membership and enthusiasm erode quickly. Zuboff (1988), in her examination of IT implementation in several companies,74 discusses the potential for IT either to automate or to "informate" work. 7 5 Automation causes the displacement of human labor, and is not unique to IT. "Informating" is a unique characteristic of IT, where the technology produces information about the process and itself. She concludes that IT has the potential to transform the nature of work in the above two directions (automation or informating) based on the implementation and usage of the technology by organizations. Barley (1986) discusses the varying effects of CT scanner technology on the organizational structures and the process of change at two hospitals. Using longitudinal research methods, he shows how in each case, organizational structure affected and was affected by the characteristics of the staff and previous work patterns. Structural power research suggests that IS can influence the balance of power within an organization, thus contributing to resistance and rejection of new IS and IT. Markus' (1981) historical and longitudinal analysis of a Material Requirements Planning (MRP) system in two manufacturing plants within a single company reveals power and political reasons for user resistance and acceptance. The new centralized MRP system violated Plant One's power as the lead plant in the production process feeding Plant Two, while Plant Two accepted the 7 4 Pulp and paper, telecommunications, dental claims, stock and bond transfer, bank, and pharmaceutical companies, 7 5 Harrington (1991) also discusses the ability of IT to produce broader awareness and perception of environment, versus more general technology. Both Zuboff and Harrington implicitly state a moderate technological imperative with emergent properties. Chapter 2: Literature Review 45 system readily because the centralized information allowed it to monitor Plant One's activities7 6 Markus (1983) found similar results in the development of a cost accounting system. Thomas (1994) proposes a process-power perspective where power lies at the root of the manufacturing innovations he studied. Usually engineers and developers of technology lead the innovation to enhance their position in organizations. Responses from other groups to protect and/or enhance their position by shaping the technology's further development and adoption describe the ensuing development path. The social technology perspective takes an intermediate stance between the emergent perspective and the organizational imperative. Technology constrains and enables action in planned and unplanned ways. Adaptive structuration research falls within the social technology perspective. The interplay between technology and organizational structure produces planned and unplanned outcomes. The structural power literature suggests that systems pose opportunities for power posturing within an organization, and that the resistance to or acceptance of a technological system can be explained by referring to a group's power and aspirations. 2.4.10. Conclusion: Reconciling the Four Theories of Technology and Context Interaction Reconciling these four views of the technology and context is an important goal of this thesis. The result of such an analysis may be one of the following: Markus suggests that three areas of power are influenced by IS: decision making, behavior and performance, and symbolic power. Chapter 2: Literature Review 46 Table 2-5: Reconciling the Four Theories Reconciliation Method i Explanation Mutually Exclusive 1 Theory 01 explains the technology-context process ! better than theory TI, EP, or ST. Equal Validity | Theory ST and theory 01 explain different aspects of | the process. Special Case | Theory ST is a special case of Theory EP. Association 1 Theory ST occurs before Theory 01 over time. The purpose of this thesis is to reconcile these four theories and the various IS literature, addressing IS development by comparing and contrasting the data from two case studies. Through this method, I hope to understand and integrate the current IS literature on system development and provide a conceptually rich explanation of the development process. 2.5. Chapter Summary Addressing the first motivation of producing a conceptual language and framework of the ISD research and theory, this chapter described an implementation framework, two descriptive constructs to simplify technology and context (action and "action frontier"), four theories linking technology and context (technological imperative, organizational imperative, emergent perspective, and social technology), and information systems research that employs these theories. The result is a framework, map, and a language for discussing the case studies. The following table provides a summary of the research areas under the four theories: Chapter 2: Literature Review 47 Table 2-6: Summary of Four Process Theories and ISD Research Process Theory Research Areas Technological Imperative Technology Systems Organization Imperative Strategic Information Systems Planning Structured Design and Analysis Task-Technology Fit Integrative and Functionalist Forms of User Involvement Problems with Unidirectional Theories Technology Divergence Evidence Against top-down Planning Conceptual Problems Emergent Perspective Designer's View Alternative Views Predicament of Design Evolution of Technology Political forms of User Involvement Innovation Social Technology Adaptive Structuration Structural Power The final section provided possible methods of comparing and integrating the various process theories that will be explored in the next chapter. Chapter 3: Research Question and Methodology 48 3. Research Question and Methodology 3.1. Research Question The following research question is addressed in this thesis: (1) What is the nature of the interaction between technology and context during ISD? The purpose is to generate new hypotheses about the technology-context interaction for future research. 3.2. Methodology To address this question, two cases of software development were studied and are described using a comparative case, action research, and longitudinal analysis approach. Data collection and data analysis strategies are also discussed. 3.2.1. Comparative Case Design The purpose of this research is to explore the interaction between technology and context across time (Franz & Robey 1987). As a result, this thesis uses a multiple case study approach to compare and contrast the researcher's development experiences in two software development cases (Yin 1994). A case study approach is considered an appropriate method for studying a phenomenon in its natural setting, for employing multiple data collection techniques, uncovering the complexity and richness of a phenomenon, and exploring and generating hypotheses (Benbasat, Goldstein, & Mead 1987; Yin 1994). The purpose of the two case studies is not to produce two isolated stories, but to link them to the theory and Chapter 3: Research Question and Methodology 49 empirical work in the IS field through "analytic generalization"77 and other methods (Markus & Robey 1988; Eisenhardt 1989; Lee 1989; Yin 199478; Sabherwal & Robey 1995). These methods include the search for procedural patterns, the use of rich description to illustrate the data, the use of theory and empirical work to help explain and provide links for generalization, and the comparison of two case studies to allow replication. Case Study One (SoftHeart) was chosen based on accessibility and an opportunity to explore a potential ISD project within a clinical setting. The approach for Case One is the "information gathering" approach (Layder 1993) and what Yin (1994) calls an exploratory case, where data are collected using few preconceived notions in a specific problem area to produce new theory (Eisenhardt 1989). In this thesis, the problem area is software development and early implementation.79 Using the "information-gathering" method, a grounded theory approach is used for Case One, using theory to help interpret and provide a language for exploring the case observations and events. During Case One, the theoretical framework was developed, based on my literature search and review (see Chapter 2). The literature draws from a wide range of ISD and technology research to provide a rich theoretical framework, and to provide for creative juxtaposition of data and research (Eisenhardt 1989). Case Study Two was then chosen strategically to extend the emergent theory (Yin 1994). As a result, Case Two and the continued examination of Case One provide a structured examination of the theoretical Generalization to theory and literature instead of through statistics. Yin talks about analytic generalization to theory, not statistical generalization. My initial approach in case one was a technological imperative. Chapter 3: Research Question and Methodology 50 framework. A model integrating the four process theories is then provided at the conclusion of both studies (see Chapter 6). The following diagram illustrates these three phases: Figure 3-1: Research Design C a s e One Four Process Theories C a s e Two , ^ r e -integrated Theoretical Model => 1992 Time 1 9 9 6 The two cases vary on a number of theoretical and a priori dimensions to allow the theory to emerge from experiences in diverse settings. A summary of the case studies is provided below. Chapter 3: Research Question and Methodology 51 Table 3-1: Development Environment Dimension/Case Case 1 Case 2 Setting of development Two heart disease outpatient clinics - hospital setting. Health promotion department on campus. Setting of usage Two heart clinics Two Canadian communities. Time Frame July 1992 to March 1996 January 1995 to March 1996. Software/Technology Electronic patient record (SoftHeart) Health promotion planning tool (EMPOWER) Purpose Diagnosis, treatment, and patient education Teach and assist planning Task Clinical, administrative, and research Develop complete health promotion plans Product Tailored software to setting Generic software to be diffused to many settings IS/IT Concepts Database - executive information system Planning tool with decision support resources. Infrastructure Computer network Standalone Project Team LipidLink group (network infrastructure), two programmers, interviews with clinic personnel. Health promotion researchers, programmer Software Tools Foxpro database, graphics server tool, Windows, and OS/2 Toolbook and Windows IT/IS Starting Point DOS standalone patient record in Clipper with 4 Modules (lab, patient, physician, medications) Untested US version of software Development Approach Bottom Up Theory and research model. User Involvement Design, development, deployment Some development and deployment My Role Designer/Developer/Program-mer Developer and Programming Consultant The level of analysis in this thesis is what Layder (1993) calls a "situated-activity level-of-analysis, where the interaction between individuals and the outcomes of this interaction are the focus of data collection to provide an embedded case design (Yin 1994).80 I use the term events to represent instances of situated activities, or what I call processes. This fits with Argyris, Putnam, & Smith's (1985) method of dealing with the subjective nature of data by referring to the 'ladder of inference' Events are relatively objective statements at the lower end, and processes are interpreted and generalized event types. Chapter 3: Research Question and Methodology 52 The focus is on: emergent meanings, understanding and definitions of the situation as these affect and are affected by contexts and settings (above) and subjective dispositions of individuals (below) (Layder 1993, p 72). 3.2.2. Action Research This study also employs a specialized form of case research referred to as "implementation", "problem-oriented", or "action" research (Gibson 1975; Wolf & Rossini 1977; Susman & Evered 1978; Sandberg 1985; Wood-Harper 1985; Benbasat, Goldstein, & Mead 1987; Gathers 1990; Jonsson 1991).81 Action research (AR) has been defined as: an inquiry into how human beings design and implement action in relation to one another. Hence it is a science of practice (Argyris, Putnam, & Smith 1985, p. 4). The purpose of A R is both to observe and to promote change in the organization. Action researchers point to this dual role of the research: Action science attempts both to inform action in concrete situations and to test general theory (Argyris, Putnam, & Smith 1985, p. 5). On the one hand, we sought to observe, record, and interpret behavior and events longitudinally...to develop concepts and relationships and to test working hypotheses toward the building of a theory that would be closely grounded in the data and that would yield immediately useful findings for practitioners concerned with the implementation of models. On the other hand, we were committed to assisting and facilitating the implementations. In this respect we worked closely with and between the model builders and the users and undertook to exert influence on the parties as it seemed appropriate (Gibson 1975, p. 53). The method of A R begins by analyzing ad-hoc and permanent meetings between various participants, and intervening in one or more of these groups within a "client-system" Action research (AR) is also an established method in health promotion called "participatory" research (Green, George, Daniel, Frankish, Herbert, Bowie & O'Neill 1995), with similar roots (Lewin 1945). Chapter 3: Research Question and Methodology 53 (Argyris, Putnam & Smith 1985). Client systems could include one group, an organization, a network of organizations, or a community (Susman & Evered 1978). Susman & Evered (1978) identify five cyclical phases to action research: diagnosing, action planning, action taking, evaluating, and specifying learning. A R then falls into four categories based on the study's emphasis: "diagnostic" action research focuses on the researcher collecting diagnostic data for the client and the reporting of this data, "empirical" action research examines the actions naturally taken by the client, and the diagnosing and reporting of this data back to the client, "participant" action research occurs when the researcher is a part of diagnosing and carrying out a change with the client, and "experimental" action research carries the researcher through the phases of diagnosing, acting, and evaluating the intervention through experimental methods. Originally, this thesis began with an experimental action research focus and switched to a participant form when development became the focus. The philosophical foundations of A R are praxis, critical theory, interpretive theory, hermeneutics, pragmatism, process philosophies, and phenomenology (Susman & Evered 1978; Argyris, Putnam, & Smith 1985; Jonsson 1991). (1) A R focuses on what Aristotle called "praxis" knowledge, or the knowledge of action and conduct (Susman & Evered 1978; Angeles 1981). As a result, A R is pragmatic in assigning truth and value to a statement by its practical application to achieving new desired ends (Jonsson 1991). (2) A R tends toward critical theory in identifying hidden dimensions through emancipatory knowledge, and rephrasing individual and organizational problems in Chapter 3: Research Question and Methodology 54 new ways to allow action (Argyris, Putnam & Smith 1985; Lyytinen & Klein 1985; Orlikowski & Baroudi 1991; Myers 1994a, 1994b). The generalization of these findings is created by drawing out the principles of intervention and action from the case settings. (3) Findings from A R research are also potentially generalizable to at least the organizational level through an interpretive approach by searching for shared norms, values, opinions, and understandings of the organization (Sanday 1979; Lee 1991; Orlikowski 1991).82 In this interpretive approach, A R uses hermeneutics, suggesting that knowledge is framed by assumptions, that a holistic understanding of the context is required to understand events and specific instances, and that various individuals in a setting will disagree on meaning (Boland 1985, 1990). A R also gives priority to personal subjective experience in creating knowledge, and thus includes the principles of phenomenology. The principles of phenomenology have been applied in a number of social science settings, including the early action research of Lewin (1946). (4) A R encompasses the "process view" where all knowledge and action is limited by its spatial and temporal context, thus suggesting that you cannot step into the same social system twice (Susman & Evered 1978). There are a number of advantages to using an action research approach in the study of software initiation and creation. Interpretive research is becoming more prevalent in the IS literature (Walsham 1995). Chapter 3: Research Question and Methodology 55 (1) A R is considered valuable for information systems designers who have been unable to utilize the more abstract IS research to deal with system design and implementation (Jonsson 1991). (2) A R allows in-depth understanding of the consultant's role that has been poorly covered in the literature (Jonsson 1991). (3) The goals of A R focus more on the neglected aspects of knowledge, with its focus on , understanding versus prediction, making things happen versus prediction, conjectures versus deduction/induction, engagement versus detachment, and action versus contemplation (Susman & Evered 1978). As a result, action research is future-oriented, collaborative, implies the development of enabling and learning systems, generates theory grounded in action, and provides guidance and methods for tailoring development to specific situations. (4) A R provides rich data to compare with theory by allowing researchers to observe processes and unplanned discovery (Jonsson 1991). (5) The phenomenological and hermeneutic approach of A R has been identified as an , important but overlooked method of studying and understanding information systems development and usage (Boland 1985, 1987, 1990; Myers 1994b). (6) A R combines both observation and the facilitation of implementation to produce change in the host organization (Gibson 1975). This allows a positive interplay between theory and observation, learning, and action (Jonsson 1991). (7) The predominance of positivistic approaches to research in information systems has Chapter 3: Research Question and Methodology 56 led to a philosophically restrictive view of information systems research that needs to be addressed by more research in the interpretive and critical theory arenas (Orlikowski & Baroudi 1991). (8) Information system development has been considered an intervention into a social system where the developer acts as a change agent (Bostrom & Heinan 1977). To limit some of the biases and weakness of the action research approach, this thesis employs a number of Gibson's (1975) and Sandberg's (1985) suggestions: (1) assume knowledge can be extended beyond local settings and isolated stories (Schon 1983; Markus & Robey 1988). (2) develop an action part subordinate to the goals of action. (3) develop a theory part subordinate to the goals of scientific inquiry. (4) create a planned interplay between the two. (5) record processes in a manner that is useful to scientific inquiry. (6) maintain enough professional autonomy. Important conceptual approaches for allowing scientific inquiry to emerge from action research can be drawn from McClintock, Brannon, & Maynard-Moody (1979), Lee (1991) and Sabherwal & Robey (1995). First, McClintock et al. (1979) suggest a longitudinal case study does not need to be treated as a single instance, but the richness of the events and processes can be used to find many instances of a theme or idea. Second, Lee (1991) provides a method of integrating subjective, interpretive, and positivistic understanding of data. The subjective approach attempts to understand the individual perspective of those Chapter 3: Research Question and Methodology 57 involved in the setting. The interpretative approach is the researcher's initial understanding and rephrasing of the subjective. The positivistic approach formalizes the interpretative understanding, using scientific and mathematical language. This thesis uses the subjective and interpretive approach to describe the process of ISD, providing pointers to future positivistic and variance research. Finally, future research of the qualitative data would employ Sabherwal & Robey's (1995) method of quantifying the data within the two cases to uncover statistical patterns. 3.2.3. Longitudinal Analysis Both cases involve the observation and collection of data continuously during the initiation, creation, and development stages. This longitudinal or "time series" design (Yin 1994) allows an examination of the software and organizational process as it unfolds, and addresses an important need for this type of research (Pettigrew 1979; Kling & Scacchi 1982; Das 1983; Pettigrew 1985; Vitalari 1985; Markus & Robey 1988; Monge 1990). Longitudinal research designs address important questions such as time, learning, adaptation, evolution, technology and social systems interaction, rates of change, and responses to contextual factors (Vitalari, 1985; Yin 1994). Various longitudinal methods are used in this study (Pettigrew 1979; Barley 1986, 1990). 3.2.4. Data Collection and Analysis Data sources collected from both cases studies include observations of meetings, patient/provider interactions, clerical work, prototype demonstrations and usage, team meetings, documents, field notes, interviews, diaries, and design notes. This data is Chapter 3: Research Question and Methodology 58 triangulated to produce more valid substantive and theoretical ideas about the cases (Jick 1979; Benbasat, Goldstein, & Mead 1987; Eisenhardt 1989; Yin 1994). Data is collected from multiple levels including individual, group, organization, and the health environment, including literature about heart disease, breast cancer, health behavior, and health promotion.83 This provides a rich context for a complete understanding of the context around technology and ISD (Markus & Robey 1988; Ritzer 1992; Layder 1993). For data analysis, diary notes and summaries of documentation were typed into a word processor, ordered by time. This allowed a scanning for patterns within the data, and the recognition of critical and illustrative events and processes. In addition, an annotated bibliography was constructed to allow quick scanning of the research literature during coding. Diary notes for both cases exceeded 800 pages. Documentation of design notes, database schemas, reports, and meeting minutes exceeded 500 pages. Typewritten summaries of the diaries and documentation summaries produced 189 single-spaced pages of data for the SoftHeart case, and 57 pages for the Empower project. The annotated bibliography exceeded 50 pages. The analysis of the data uses the 'ladder of inference' described by Argyris, Putnam & Smith (1985) and employed by Newman & Robey (1992). The following diagram illustrates the ladder of inference used in this study: See Appendices C & D for a list of the health care and health promotion literature read and used in both cases. Chapter 3: Research Question and Methodology Figure 3-2: Ladder of Inference 59 Chapter 6 Chapter 2 Four Process Theories Tl X Ol E P ST Tl O l E P ST Research Research Research Research Chapter 4 and 5 Appendix A and B Processes Events Time Ladder of Inference Process Stages "Process stages" are time periods where the project maintained a certain ambiance. For example, "project emergence" is a process stage in both cases. Process stages are generated from both key events and processes that altered the project's direction. Critical and illustrative events are extracted from the cases (Miles & Huberman 1994). These events are described in the case write-ups of Appendices A and B (Eisenhardt 1989; Yin 1994). Events are then gathered into "processes" (Newman & Robey 1992).^ Each process is described and characterized by time, "technological levels" affected, and contextual dimensions involved. Events are similar to Newman & Robey's (1992) encounters, and stages matches their definition of episodes. Because these authors are examining the entire system development as a single process, and focus on the interaction between users and analysts, they determine and categorize their episodes based on a single event. These events types include: user-led, system-led, and joint-led. Chapter 3: Research Question and Methodology 60 Following the identification of a process, relevant literature is cited with a process, and the categorization of that literature is used to determine one or more of the four process theories that best describes the process. Using four divergent theories and two cases ensures that bias toward the data is reduced and theoretical opportunities are increased (Eisenhardt 1989; Yin 1994). A series of inference rules allows movement up the ladder from events to processes, processes to the literature (Chapter 4 & 5), and literature to the four process theories (Chapter 2: Table 2-4). As an example of the approach, the following table outlines the three characteristics of a hypothetical process with a process called "search for software platform": Table 3-2: Characteristics of a Process Question/Description j Example Contextual Dimensions and/or ) Developer and software supplier x. Contextual Level Technological Level and/or characteristics j System Functionality Time | January to February j ST One of the key characteristic of a process is the "levels of technology" involved in the process. The term 'levels' is used to describe the macro characteristics of the hardware and software infrastructure, and micro characteristics of the software program and interface influenced by the macro. Certain process types may appear with certain levels of technology while disappearing with others. The following figure illustrates the nested levels of technology, with the micro characteristics at the center, expanding to the macro Chapter 3: Research Question and Methodology 61 characteristics at the boundary: Figure 3-3: Levels of Technology Processes are then combined to reach conclusions about each stage, and conclusions about the entire ISD process. Theoretical patterns in each case are explored by examining the pattern of the four theories across time. Theories can then be compared with "mutual exclusive", "equal validity", "association", and "special case" patterns. Chapters 4 and 5 describe the processes, stages, and ISD process in each case based on the detailed events described in Appendices A and B. Numerical counts are used to illustrate patterns in the subjective extraction and coding of processes, providing results for hypothesis generation. Chapter 6 compares and contrasts the four process theories and their Chapter 3: Research Question and Methodology 62 explanation of the processes, stages and ISD process in both cases, and provides an integrated theoretical model. Percentages of the data explained by a process theory are included. 3.3. Some Limitations of the Methodology Various weaknesses of the case study methodology have been documented (Sandberg 1985; Benbasat, Goldstein, & Mead 1987; Jonsson 1991; Yin 1984), including increased subjectivity, and the need for careful generalization of results beyond the cases through theory. Weaknesses of action research include its lack of control over independent variables, its interference with the object of study, its low generalizability to other settings without careful qualification, and the potential alignment of the researcher with specific interest groups (Gibson 1975; Susman & Evered 1978; Sandberg 1985; Galliers 1990; Jonsson 1991). Thus, the thesis provides ideas for hypothesis generation rather than concluding with certainty the magnitude of the four process theories in explaining the ISD trajectory. Chapter 4: Processes in the SoftHeart Case 63 4. Processes in the Initiation and Development of "SoftHeart" The development of SoftHeart involved a series of "processes" between technology and context over time.85 Important in these processes were various stakeholders including the developer (myself), the developer's thesis committee, clinic physicians, two programmers, clinic personnel, the LipidLink and research group, funding agencies, internal hospital departments, external government agencies, health researchers, and software suppliers. This chapter reports on critical and illustrative technology-context processes in the development of SoftHeart. Processes, process stages and the ISD process are discussed using the four process theories and research of chapter 2. Citations and inference rules to the literature for each process are provided.86 First, the chapter describes the two heart clinics, including their past, present and perceived future information systems, and the role of SoftHeart in the current and future information system. Second, the majority of the chapter examines the technology-context processes that appeared in process stages during the development of SoftHeart.87 The following table summarizes these process stages: At the time of writing this thesis, SoftHeart had reached the early implementation stage. Appendix A provides a more detailed account of the important chronological events in the SoftHeart case, and provides the raw data used to build this chapter. Note that these stages, although presented sequentially, were often overlapping. Chapter 4: Processes in the SoftHeart Case 64 Table 4-1: Process Stages in the Development of SoftHeart Process Stage Time Period Stage Project Emergence April 1990 - August 1992 Initiation Health Funders Skeptical January 1993 - March 1993 Our Response April 1993 - October 1993 Old and New Environmental Shocks August 1993 - March 1994 Decision to Move Ahead April 1994 - August 1994 Adoption & Adaptation Prototype Presentation Sparks Interest and Constraint September 1994 - October 1994 Conflict Erupts October 1994 - February 1995 Decision to Act February 1995 - March 1995 Project Builds Momentum Nov. 1994 - April 1995 Development Quagmire March 1995 - August 1995 Recovery and Slow Growth to Early Implementation August 1995 - Present Adaptation, Acceptance and Routinization Routinization and Infusion What Lies Ahead Present Finally, the chapter concludes with a discussion of the four process theories' description and illustration of the SoftHeart case. 4.1. The Two Heart Clinics and SoftHeart There are two heart clinics involved in the development and usage of SoftHeart. Clinic One has been in the project since the summer of 1992 when the developer first visited its site at Hospital One. When Hospital One was closed in the spring of 1994, Clinic One was moved to Hospital Two, and located beside Clinic Two. In March of 1995, after talks with the director and staff of Clinic Two, the SoftHeart project broadened to encompass both clinics. This was to coincide with a move by both clinics and a research lab to become integrated into a single cardiac prevention program. During early 1996, Clinic One, Clinic Two, and the Research Lab joined together within this umbrella organization (Heart Health Chapter 4: Processes in the SoftHeart Case 65 Department; a pseudonym). The Heart Health Department (HHD) is funded by both the hospital and a heart center that supports heart disease clinics within the hospital. HHD is also funded by research grants and drug companies. 4.1.1. Clinic One Clinic One is involved in the medical or clinical prevention of heart disease through traditional physician/patient visits and the prescription of diet, exercise, and medications to improve patient lipid values.88 Patients are referred to the clinic by general practitioners or cardiologists who believe their patients may have abnormal lipid values and a risk of heart disease. Clinic One's physicians then analyze and prescribe treatment for the patient and provide information to both the referring physician and the patient. Dietitians analyze food intake information to assess dietary factors affecting lipids. Clinic One employs six physicians and two dietitians who assist referring physicians' treatment of patients at risk of heart disease because of abnormal lipid levels. A useful way to visualize the past information system of Clinic One is to follow a typical patient's visit. After being referred to the clinic, the coordinator schedules the patient for a visit, and mails appropriate questionnaires. New patients provide basic family and personal information including a description of their medical history prior to their first visit. Both new and recall patients complete a food intake sheet prior to each visit. Upon arrival at the clinic, all patients are weighed, have a blood sample drawn, and are seen by one of the The term 'lipid' is a more general term for 'cholesterol'. Lipids comprise a range of greasy, waxy, and fatty compounds that are insoluble in water Cholesterol is a 'compound' lipid used in the construction of cell membranes. An imbalance of good cholesterol (High Density Lipids - HDL) to bad cholesterol (Low Density Lipids - LDL) is associated with heart disease. Chapter 4: Processes in the SoftHeart Case 66 physicians. Approximately half of the patients see one of the dietitians as required. A physician spends about 20 minutes with a new patient, and about 8 to 10 minutes with a recall. Blood pressure, smoking, medical history, medication, and physical examination data are collected by the physician, and written in the clinical notes. A dietitian spends anywhere from 5 to 45 minutes with an individual patient. The Food Intake Sheet (FIS), filled out by the patient before the visit, is discussed and various calculations of current and ideal fat consumption, body weight, exercise, and calorie intake are manually calculated and written. Upon making a diagnosis, the physician and the dietitian usually provide the patient with some verbal treatment information, supplemented with appropriate pamphlets and other documentation. The coordinator adds these notes and recommendation letters to the patients' charts, and updates a standalone database (EasySys, a pseudonym) with medication, weight, blood pressure, and smoking information. Two one-page reports are printed and stored in the patient chart for future visits; a lab/diet/weight/blood pressure and smoking spreadsheet, and a medication sheet. At the end of the day, the physician prepares clinical notes for each patient, and the dietitians prepare dietary notes. The dietitian also makes brief informal notes in a "kardex" file. Once lab results are available (usually later than two days), the physicians will dictate letters for the referring physicians with recommendations for patient treatment. New referring physicians' information is entered into the computer. Phone calls from patients and referring physicians for lab information are answered by the coordinator using EasySys. EasySys stores patient demographics, lab, diet, and medication information about the patient gathered at each visit. Chapter 4: Processes in the SoftHeart Case 67 Clinic One is also involved in atherosclerosis89 research, focused largely on genetic causes. Subjects for the studies are recruited from the clinic, and basic research and clinical trials,with medications are conducted. Most of the information and reporting for these research activities are held separately from the clinical care group in separate database programs and files. 4.1.2. Clinic Two Clinic Two is involved in the lifestyle prevention of heart disease through a 6-week exercise program offered to patients at risk of, or recovering from, heart disease. In addition, clinic personnel provide weekly classes on stress, diet, exercise, smoking, and substance abuse. The clinic employs one physician who is also the director, two nurses, three exercise physiologists, a coordinator, and two clerks. Patients are referred in a similar manner to Clinic One by general practitioners and cardiologists with patients recovering from heart disease. Patients are seen by the physician during an assessment clinic, who determines the patients' risk and need for treatment, and places them on a priority list for the program. Patients are eventually scheduled for a six-week exercise program involving two 1.5-hour classes of monitored exercise every week, and assigned a case manager based on their class time. Patients are checked again at mid-point through a diagnostic clinic, and at the end through an exit clinic. Stress test information gathered from an exercise test, determines the patient's capacity for oxygen at both the assessment and exit times. Currently, all information is handled manually in a patient file A disease that results in the fatty build-up of plague in the artery walls causing eventual blockage of blood flow. Chapter 4: Processes in the SoftHeart Case 68 folder. Information is written several times in different formats to satisfy the needs of the various providers in the clinic. Clinic Two is also involved in research activities focusing on various areas of heart disease rehabilitation and prevention. Information for this research is also collected separately, using patients recruited from their classes. 4.1.3. Description of SoftHeart and LipidLink SoftHeart is an electronic patient record, designed to address three areas in order of importance: clinical (patient care), research, and administration.90 The SoftHeart software consists of various modules that involve three design and programming areas: database design, data input, and display (on screen and reports). Each of the modules are in various stages of development.91 SoftHeart includes most modules required in a fully electronic patient record. The following lists the modules, and each module's current completion status is indicated by a number, where "1" means database design only, "2" means database design and input, and "3" means database design input and display/reporting. Modules include lipids (3), lab results (3), medical history (2), family history (1), physical examination data (1-2), medications taken and prescribed (2), diet and exercise (3), smoking (3), alcohol (3), blood pressure (3), "stress test"92 (2), side effects (1), and quality of life (1) information. Administrative information is also gathered including patient demographics (3), referring physician information (3), and a SoftHeart's original focus was solely on clinical and patient care. Screen pictures of SoftHeart are provided in Appendix E. A "stress test" is an exercise test that measures the oxygen capacity of the patient. Chapter 4: Processes in the SoftHeart Case 69 scheduler (3) for class and/or appointment times. Finally, there are several modules that extend the information including a risk calculator that calculates 5 and 10 year risk of heart disease (3), a "modifiables" display panel displaying those items considered under the control of physician and patient (diet, exercise, lipids, medications, etc.) (3), and a graphing module to allow visual inspection of trends (2). The program is about 40% complete, but the modular design has allowed implementation of completed modules in the two clinics. Currently, medications, graphing, and connections with two hospital mainframe systems (administrative discharge tracking and lab medicine) are the main targets for the next months. A view of all data to be eventually collected by SoftHeart is provided below: Figure 4-1: Data View of SoftHeart Ref MDs Patient Family History Staff -PI Classes/Times Event Side Effects Effect Catalogue Stress Test Diagnosis Catalogue Medical Phys History Exam r Medical History Catal E x a m Catalogue Drug Presc Medic Diet/Exerci &e Drug Catal. — Food Catal. Smoke, BP, Alcoh Lab Range Catalogue Qual of Life Chapter 4: Processes in the SoftHeart Case 70 The database structure attaches one-time data directly to the patient, and repetitive information gathered at visits to an event or encounter. Catalogues are also used extensively to allow data to be entered quickly and efficiently for diagnosis, exam, medical history, and side effects. Catalogues are also used to set parameters for abnormal values, to calculate food content in patient diet, and to calculate risk. SoftHeart encompasses a number of design concepts. First, the software uses tabs to provide access to any information with the push of a button. Second, the software separates display from data entry by using panels of information. Depending on the user password, these panels allow data input at the push of an "edit" button, displaying a green editing region in the middle of the screen. A user's password into the system determines the buttons that are displayed on the side and an asterisk indicates whether the panel can be edited by this user. The editing button is then enabled or disabled based on the button label assigned to this user. This feature provides for different levels of security into the data given the role of the individual. Third, each panel has its own program modules for displaying the screen and checking for data integrity, providing modular design. Fourth, SoftHeart's design avoids delaying the user during display and data entry by placing messages off to the side and avoiding the need to press a key to clear, automatic saving, linking editing modules to allow entry to multiple panels without leaving the editing screens, and attachment of appropriate modules into edit screens where appropriate. For example, "Physicians..." and "Scheduling..." are attached in the patient input window to allow linking and scheduling of patients. SoftHeart currently uses over 30,000 lines of code.93 Appendix G provides a programming guide to SoftHeart. Chapter 4: Processes in the SoftHeart Case 71 While the developer had been developing the software, the research arm of the two clinics, under the leadership of their director, developed the infrastructure named "LipidLink" (a pseudonym). The purpose of LipidLink is to provide a computer in every room, including the physician and dietitian consult rooms, to allow access and entry of information through SoftHeart. To accomplish this, the research group has managed to obtain funds from the Heart Center and a drug company to finance the hardware and network software. SoftHeart has only recently begun to be used by the two clinics. Currently, most of the features of EasySys system are available and being used in SoftHeart. These include patient, lab, dietary, and physician data input, and reporting of lab sheets, patient labels, etc. There is also some evidence that new information is being collected, including exercise stress tests, smoking, and blood pressure. LipidLink now provides linkage to SoftHeart in almost every room, except for physician examination rooms. In addition, users are now starting to use the software to examine patient data and test graphing capabilities, and using direct Foxpro queries to query the data for research purposes from their terminals. The following sections provide a stage-by-stage description of the ISD process of SoftHeart. 4.2. Project Emergence Particularly important in understanding information systems development are the processes resulting in the initiation and creation of IS and IT. Project emergence outlines important processes in the initiation and creation of SoftHeart. The SoftHeart project was started by a core group of researchers interested in health Chapter 4: Processes in the SoftHeart Case 72 care, information systems, medicine, and health economics. Particularly important in the project's initiation were the goals and interests of the developer 9 4(Schon 1983; Turner 1987; Beath & Orlikowski 1994; Petroski 1994; Thomas 1994).95 His interest in integrating information systems and health care initiated the project. His background and motivation to research IT and its impact on health care organizations provided a innovation "subsidy" and an "innovation context" 9 6(Van De Ven 1986; Brooks 1987; Hirschheim & Klein 1989; King, Gurbaxani, Kraemer, McFarlan, Raman & Yap 1994; Thomas 1994). His database background from work experience equipped him with some skills for developing SoftHeart, access to the clinic's information system (EasySys), and an interest in improving Clinic One's databases and reporting mechanisms. The developer's inexperience with clinic settings required him to learn the clinical and heart disease setting in order to develop an IS intervention. This inexperience also gave the developer a perhaps naive and technical approach to design at the beginning of the project, and may have prevented an appropriate feasibility study of the site and hospital environment 9 7(Klein & Lyytinen 1985; Boland 1987).98 Schon (1983) discusses the reflective practitioner and the effect of an individual's background on interpretation and action. The practitioner's understanding and background effects the course of development. Turner (1987) characterizes design as a goal, with no immediate procedures for attaining that goal. Beath & Orlikowski (1994) discuss the effect of methodology choice and approach on development. Petroski (1994) talks about the role of designers, their failures and background. Thomas (1994) shows that innovation in manufacturing comes from outside the management circle through technology developers. The developer had little idea at the time what was the future of the project. He approached the problem from a technical perspective, somewhat unaware of the political context of medicine and Clinic One. Van De Ven (1986) suggests that a central problem in innovation is the innovator's ability to manage the project, and to fuse the interests of the different groups. Brooks (1987) discusses the complexity of software design through conformity and changeability of software, and the need for good designers. Hirschheim & Klein (1989) discuss four approaches of a developer in the course of development; functionalist, integrationist, radical structuralist, and neo-humanist. Each view depends on two dimensions: ontology (subjective/objective) and conflict (conflict/integration). Thomas (1994) shows that innovation in manufacturing comes from outside the management circle through developers. Klein & Lyytinen (1985) describe the approach of the developer of SoftHeart during the early stages; a scientific background with a mixture of interpretive, and a naive and technological approach to development. Boland (1987) Chapter 4: Processes in the SoftHeart Case 73 As a result, the SoftHeart project was more an opportunity than a necessity "(Basalla 1988; Petroski 1994). For the developer and his committee, these opportunities included an interest in health care and information systems, a need to find an interesting thesis topic, and a chance for three colleagues to carry out research together (the developer's supervisor, one committee member, and the clinic physician). Thus, the project was driven by supplier and developers 100(Turner 1987; Attewell 1992; Thomas 1994). Early proposals fused the interests of the different groups. The proposals focused on information "framing"101 and multimedia computers, and its effect on providing clear risk and treatment information to the patient that would produce changes in behavior and health outcome 102(Tversky & Kahneman 1981; Benbasat & Dexter 1985a & 1985b; Benbasat, Dexter & Todd 1986a & 1986b; Earl 1989; Cooper & Zmud 1990; Mohan, Holstein & Adams 1990; Tan & Benbasat 1990). These proposals described information technology's discusses the importance of context and background in interpreting information, including the purposes, motivations, and background. At the same time, this naivete provided the developer with the "outsider" view of the events inside the clinic, giving him a more detailed and valid analysis of events and processes. Basalla (1988) and Petroski (1994) both discuss the evolution of design. Technology arises from perceived failure and an "opportunity", not necessity. It is the perceived failure of technology that drives innovation. ° Turner (1987) discusses the reconciliation between human and technical in design. Technology embodies an idea from suppliers and developers. Attewell (1992) and Thomas (1994) say technology is a supply side phenomena, where knowledge is infused into the organization by suppliers both outside and inside the organization. 1 "Framing" involves the systematic shift in an individual's interpretation of similar statistical information that is worded differently. In one study, tank crews were told they either had a 50% chance of death or a 50% of living if they chose to drive their tanks down a path. Those given the "death" framing were less likely to drive the path than those given the "life" framing. 2 Tversky & Kahneman (1981), Benbasat & Dexter (1985a & 1985b), Benbasat, Dexter & Todd (1986a & 1986b), Earl (1989), Cooper & Zmud (1990) and Tan & Benbasat (1990) were all influential in the initial ideas of fitting graphical information presentation to the tasks of patient education. Mohan, Holstein & Adams (1990) document some of the problems with low public sector usage of EIS (Executive Information Systems); a set of systems similar to SoftHeart that use graphical and "drill down" capabilities to view information at general and specific levels. Chapter 4: Processes in the SoftHeart Case 74 'built-in' positive effects on patient outcomes, and that a clinic which develops and implements these technologies will show increased patient health 1 0 3 (Kim & Michelman 1990). The following table outlines the important processes in the project emergence stage. Table 4-2: Processes in Project Emergence Description Theory Technological Level Time Type of Interaction Stakeholders from Context Developer EP Project Jan 1990 Interest and Developer Background conception to July 1992 experience Opportunity EP Project July 1992 Interest and Developer, conception to Sep. 1992 opportunity committee, physician Framing and OI/TI Project July 1992 Cementing Developer, multimedia conception to Sep. interests. committee, proposals 1992 physician 4.3. Health Funders Skeptical Initial reactions to the IS and IT ideas were harsh and critical, as targeted stakeholder's "talked back". The skeptical reaction of health agencies toward the proposals caused a systematic reformulation and rethinking of the ideas. The funding agencies rejected the 'black box' of computing 1 0 4(Latour 1987; 1994). They doubted the ability of "framing" and multimedia computers to accurately inform patients about risk, change behavior, and improve patient outcomes. While some agreed that IT could lead to improved decision making and patient treatment, others suggested computers would destroy rapport between the ' Kim & Michelman (1990) point out the naivete of this approach in hospitals given the conflict between medical and administrative branches, and the lack of system integration resulting in problems with strategic IS use. 1 Latour's work provides some insightful analysis into the controversies of scientific "fact" and technology during the early years of development. The black box of both science and technology hide this controversy in the future when social divisions are healed and agreement is reached on the theory and technology. Chapter 4: Processes in the SoftHeart Case 75 provider and the patient 1 0 5(DeLone & McLean 1992; Franklin 1990; Postman 1992). For those who believed in the potential of IT to improve patient health, a number felt IT was too expensive and too weak to produce definite health outcomes.106 In general, the proposals appeared to violate key assumptions about the health context 1 0 7(Dutton 1981; Markus 1981; Kling & Scacchi 1982; Markus 1983; Van De Ven 1986; Orlikowski 1992b). The funding agencies understood IT as only a "hardware box", and misunderstood the intervention's focus on the communication between patient-and provider. Future proposals would focus less on the technology, and more on the communication of information to overcome these concerns 1 0 8 (Van De Ven & Polley 1992). In addition, a number of health researchers commented that we would be seen as outsiders by the health agencies, and that overwhelming credentials and proposal strength would be required to obtain funding from these groups 1 0 9(Markus 1981; Markus 1983). The following table summaries the important processes in this stage: ' All three authors point to the problem of technology when applied inappropriately to a task, and Franklin (1990) and Postman (1992) discuss the divisive nature of current technology. ' Certain "technologies" are perceived more strongly as imperatives in the health field, including medications and surgery. Information 'treatment' appeared to be too ambiguous to these groups. ' The issue around whether computers were inherently harmful to the task and environment of health care raises questions about the context's goals, assumptions and methods. Dutton (1981) demonstrates the important of context in computer's use and rejection. Markus (1981) provides insights into this case's structural power of the health funding network and the political setting around technology use in health care. Kling & Scacchi (1982) demonstrate the importance of web models and "web analysis". Markus' (1983) comments that technology must meet the structural powers in an environment to succeed, and a need for thorough analysis of political setting. Van De Ven's (1986) managing attention and converting ideas into currency is an important insight into this process. Orlikowski's (1992b) comment about the premises of computer technology and an incongruence between setting and technology, may explain the conflict with the health care setting. 1 learning of the patient-provider and health care settings was inhibited by the search for funding, similar to the case in Van De Ven & Polley (1992). ' Similar to Markus (1981), the development team encountered the structural power and assumptions about funding and IT research in medicine. Similar to Markus (1983), a thorough analysis of the political setting for IT usage was important, and system ideas were rejected by these funding agencies. Chapter 4: Processes in the SoftHeart Case 76 Table 4-3: Processes in Health Funders Skeptical Description Theory Technological Level Time Type of Interaction Stakeholders from Context Funders Skeptical EP/TI Project Conception, infrastructure Jan. 1993 Surprise and struggle Developer, health agencies, committee Questioning computer and framing EP/ST Project Conception, data elements Feb. 1993 Doubt Developer, committee 4.4. Our Response The core development group responded to the initial reaction of targeted stakeholder through a series of learning and action responses. The concepts and the information system details were adjusted and rewritten, based on an early exploration of the epidemiological and medical literature. The IS interventions were increased to develop a stronger experimental condition to satisfy the health agencies' need for guaranteed results 1 1 0(Markus 1981; Kling & Scacchi 1982; Latour 1987; Orlikowski 1992b; Van De Ven & Polley 1992). The proposals also removed costly computing technology and focused on printed reports m (Franz & Robey 1984; Van De Ven 1986). The purpose was to gain funding for the project's core idea: improved information collection and presentation will improve patient outcomes. This was an attempt to deal with experimental assumptions of funding agencies (Markus 1981). The implicit "discrete entity" view of technology did not work with the agencies (Kling & Scacchi 1982). The group was trying to close the black box using rhetoric produced rejection (Latour 1987). The proposals discussed the technology's use toward communication between patient and provider, and a change in focus away from the technology per se (Orlikowski 1992b). The continuing attempts to satisfy the agencies led to a lack of detailed learning (Van De Ven.& Polley 1992). 1 1 1 Rational carries the foreground while political in the background of the proposals (Franz & Robey 1984). This was an attempt to manage people's attention, to create an innovation context, and to produce an authentic system to match expectations was required (Van De Ven 1986). Chapter 4: Processes in the SoftHeart Case 77 The developer also talked with clinic staff to determine feasibility and acceptability of plans 112(Ives & Olson 1984; Baronas & Louis 1988). The purpose was to understand clinic one's current systems 1 1 3(Earl 1989), and to promote developer learning 1 I 4(Newman & Noble 1990). A structured analysis and system design document was produced 1 1 5(Coad & Yourdon 1991; Kendall & Kendall 1992). Finally, the developer's expanded reading of the heart disease, patient education and health promotion literature increased his awareness of the complex path between IT and patient outcomes, and opportunities for IT 1 1 6(Nadler 1982; Schon 1983; Franz & Robey 1984; Turner 1987; Earl 1989). In addition, his reading of this literature allowed him to communicate with both health agencies and clinic personnel 1 1 7(Boland 1985, 1990). The following table summarizes these processes: 1 1 2 There was an assumption that user involvement was important, and the software was to be driven by user needs (Ives & Olson 1984). One goal of involvement was to restore a sense of control to the clinic staff, and to provide understanding of the work environment (Baronas & Louis 1988). 1 1 3 The purpose was to identify strategic aspects, and to determine what IT and IS already existed in the clinic (Earl 1989). 1 1 4 Both learning and conflict with the physicians were generated during the interviews, created by a lack of time and misunderstanding of the developer's reasons for questioning (Newman & Noble 1990). 1 1 5 Object oriented analysis (Coad & Yourdon 1991), and Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ER) (Kendall & Kendall 1992) were produced. 1 1 6 The complexity involved in changing patient behavior emerged in the literature, as the developer red the health promotion literature (Nadler 1982). The developer used "scenarios" and reflective thought to test the feasibility of various IS interventions (Schon 1983). Rational approaches yielded complexity in patient/provider interaction, and political realities were being discovered in the background (Franz & Robey 1984). Goals were set to address patient education and communication; but process of reaching these goals through IT and IS were fuzzy and uncertain (Turner 1987). Nevertheless, the idea was to identify the strategic opportunities for IT in the clinical setting (Earl 1989). 1 1 7 Understanding of the language and the use of critical theory and hermeneutics to understand patient and physician information allowed detailed understanding of the organization (Boland 1985). Also, the developer's background as a chronic patient allowed some ideas and expertise to be added (Boland 1990).. Chapter 4: Processes in the SoftHeart Case 78 Table 4-4: Processes in Our Response to Health Critiques Description Theory Technological Level Time Type of Interaction Stakeholders from Context Larger IS interventions with fewer computers ST/EP System objectives and infrastructure Feb. to Oct. 1993 Revising and questioning Developer, committee supervisor, thesis committee Consult staff more closely 01 System objectives and functionality Feb. to Oct. 1993 Interview and discussions Developer, clinic personnel, M B A students Learning health promotion and patient education OI/EP System objectives Feb. 1993 to Feb. 1994 Learning Developer 4.5. Old and New Environmental Shocks Once again, a period of reaction from targeted stakeholders appeared during this stage of development. In addition, environmental shocks occurred that changed the course of development. Just as the project gained momentum at the end of 1993, several environmental shocks created confusion and uncertainty about the project's continued viability. When Hospital One closed and the Clinic One was forced to move in early 1994, there was a fear that the clinic might close forever and the project would die 1 1 8(Dutton 1981; Lyytinen & Hirschheim 1987). Doubt about the project's continuation remained when the clinic was moved to Hospital Two, Change in hospital settings and support networks threatened to make SoftHeart irrelevant or unsustainable. This is similar to Dutton's (1981) work exarriining the demise of a land planning system after governments changed. The project was pushed into the background, and failure loomed (Lyytinen & Hirschheim 1987). Chapter 4: Processes in the SoftHeart Case 79 and the SoftHeart project was pushed into the background as Clinic One struggled with the move and the new setting 1 1 9 (Van De Ven 1986). In addition, flinders remained skeptical, especially with the now complex interventions designed to address the complicated link between information and patient outcomes. Concern focused on the "contamination" of control groups by experimental procedures, and therefore the inability to measure outcomes 1 2 0(Markus 1981; Nadler 1982; Markus 1983; Latour 1987; Lyytinen & Hirschheim 1987). Finally, by addressing the health issues and the removal of expensive information technology, the university MIS department reacted to the lack of advanced computers in the project 1 2 1(Markus 1983; Orlikowski & Robey 1991). The constraint influenced the course of the project because of the developer's need for IS research material 1 2 2(Dutton 1981). The following table summarizes the processes in the environmental shock stage: 1 The project lost focus and interest amongst clinic personnel, similar to Van De Ven's (1986) "managing attention" and conversion of an idea into "currency".. 1 The interdisciplinary nature of the project caused health, IS and interdisciplinary groups to reject our proposals (Markus 1981,1983). The complexity of dealing with social and psychological realities of patient care continued to effect the project direction (Nadler 1982). The black box of IT continued to remain open to controversy over usage and content within the health care field (Latour 1987). Failure continued to loom over the project with the failure to acquire funding and resources (Lyytinen & Hirschheim 1987). The structural power and boundary spanning activities of the developer offended the IS group at the university (Markus 1983; Rogers 1995). Norms, resources, institutional norms of research were affecting the course of the project (Orlikowski & Robey 1991). : The developer was caught between two settings; health wanted guaranteed health outcomes and MIS wanted advanced technology (Dutton 1981). Chapter 4: Processes in the SoftHeart Case 80 Table 4-5: Processes in the Environmental Shocks Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Hospital One closes EP Project conception Jan - Mar 1994 Surprise, doubt and confusion Developer, Clinic One, government Funders continuing skeptical EP/ST Infrastructure Jan - Mar 1994 Surprise and struggle Developer, committee, health agencies MIS ' need for advanced computer study EP/ST Infrastructure March 1994. Struggle Developer, organization, MIS faculty 4.6. Decisions to Move Ahead Processes during this stage highlight the action and learning of the developer to cope with opportunities and problems identified in the previous stage of development. As the dust cleared in April of 1994, the developer tested and redeveloped the core concept of SoftHeart to deal with the constraints imposed by health funders and the university MIS department. He used his own time and labor to develop "add-on" programs to EasySys, Clinic One's standalone patient record, including the printing of graphical and risk information for patient/provider consults. In this respect, he was trying to leverage and capitalize on a data resources already available at the clinic 1 2 3(Earl 1989). In addition, the developer hoped these "add-ons" would provide evidence to health and other funding agencies that the project was This was an attempt to leverage existing IT and IS resources inside the clinic (Earl 1989). Chapter 4: Processes in the SoftHeart Case 81 progressing and moving toward implementation 1 2 4(Markus 1983; Van De Ven 1986; Basalla 1988; Van De Ven & Polley 1992; Petroski 1994; Thomas 1994). Foxpro was selected as the software platform. This selection was based on experience, intuition, limited assessment of the EasySys program, and experimentation 1 2 5(Brooks 1987; Turner 1987; Thomas 1994). Costing only $135 dollars, the package could be discarded if it failed to meet current and future needs 1 2 6(Schon 1983; Landauer 1991).127 Learning the Foxpro software and building a general approach to program design required time and effort. However, this learning allowed the designer to explore the potential and new possibilities for extending information presentation as the developer explored the software's capabilities 1 2 8(Carrol & Mack 1984; Van De Ven & Polley 1992; Hammer & Champy 1993).129 This was a political maneuver to satisfy MIS, to avoid funding agencies' concern about expensive programming and computer technology; and to keep the project moving (Markus 1981; Van de Ven 1986). Adding and modifying the existing EasySys software points to the use of legacy systems to evolve and create newer systems by using the older technology to generate ideas (Basalla 1988). The change in direction also moved the project away from marketing and into idea generation and learning (Van De Ven & Polley 1992). The maneuver also demonstrated the important push of the supplier and developer in producing and selling innovation (Thomas 1994). ' The project was growing software out of the current system (Brooks 1987). An attempt was made to reconcile human and technical using intuition and experience (Turner 1987). Selecting the tools for innovation, and working in the background suggests a supplier led development and a political process to gain legitimacy in the clinic (Thomas 1994). ' Thought experiments were conducted working with current and future scenarios (DBF files etc.) (Schon 1983). Mock ups were developed to learn, and thrown away if inappropriate (Landauer 1995). ' It was doubtful whether further planning and search period would have solved this problem because the needs of the SoftHeart system were discovered throughout the project. 1 Users were involved in the learning process by direct design and discussion about design (Carrol & Mack 1984). Now that funding worries were left behind, the learning cycle began (Van De Ven & Polley 1992). Identification of processes and information technology that could enhance or transform those processes was the goal (Hammer & Champy 1993). 1 This process continues to this day. Chapter 4: Processes in the SoftHeart Case 82 The developer also decided, based on a belief that user involvement would be essential to system success 1 3 0(Baroudi, Olson, & Ives 1986), that he needed increased access and involvement from the clinic personnel to develop and test IS ideas. It was also important to garner the interest and involvement of physicians, the director, and the coordinator to get an understanding of EasySys, and to gather suggestions and commitment to the intrusive use of computing technology. He also needed to learn about their organization and tasks 1 3 1 (Van De Ven 1986; Earl 1989; Newman & Noble 1990; Attewell 1992). As a result, he began to observe patient-provider discussions and clerical tasks. A prototyping approach was also used to test ideas and search for an integrated understanding and set of IS needs among clinic personnel 1 3 2(Boehm 1988; Gould 1988; Newman & Noble 1990; Cooper & Zmud 1990; Henderson & Kyng 1991; Wynn 1991; Landauer 1995). To have a powerful effect on patient outcomes, the software add-ons needed to provide "value-added" tools for information presentation 1 3 3(Earl 1989). Therefore, early prototypes focused on risk calculation and graphing of information to effect patient provider communication.134 The developer also continued his learning about the medical and health Ives, Baroudi & Olson (1986) discuss the general and often incorrect assumption that user involvement will guarantee system success. 1 Managing attention, getting people's interest, and a need to learn about the organization drove the desire for user involvement (Van De Ven 1986). Identification of strategic areas for IT usage and assessment of resources was another hidden assumption of user involvement (Earl 1989). User involvement was perceived as an interaction between users and specialists for learning and conflict resolution (Newman & Noble 1990). Learning and the barriers to learning about IT were implicitly being addressed in discussions (Attewell 1992). 2 Spiral development was believed to be the best way to deal with organizational complexity and to identify promising future IT projects (Boehm 1988). The result was a focus on users, iterative design, and empirical testing of ideas (Gould 1988). User involvement was an interaction between users and specialists for learning and conflict resolution (Newman & Noble 1990). The purpose was the identification of appropriate tasks that could use information technology (Cooper & Zmud 1990). Tailoring and an understanding of the work environment was believed to be essential to develop a good information system (Henderson & Kyng 1991). The developer took the nuances of practice seriously through direct observation of health providers (Wynn 1991). The developer employed user interface design and testing with users, and formative design evaluation (Landauer 1995). Chapter 4: Processes in the SoftHeart Case 83 promotion literature to learn what technologies and programs had worked or failed with patients in previous studies 1 3 5(Weitz 1990; Orlikowski & Robey 1991; DeLone & McLean 1992).136 The following summarizes the processes during this stage: Table 4-6: Processes in the Move Ahead Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Add-ons to EasySys software EP/OI/ ST Infrastructure, program, processing, reports, interface April 1994 Learning and understand-ing Developer, Clinic One personnel Selecting software platform. EP Infrastructure, program May 1994. Search and comparison Developer, software suppliers Learning the Foxpro software EP/OI Infrastructure, program, processing, interface, display, data structure June 1994 to June 1995 Learning, frustration, reading, learning Developer, suppliers, textbooks Prototyping approach adopted. OI/EP Interface and data July 1994 to present Creation and reaction Developer, clinic personnel. Focus of risk calculation and graphing 01 Functionality and interface August 1994. Value added functions and project positioning. Developer, software. Learning about medical and health promotion ST/OI System objectives and functionality August 1994 to present. Learning, understand-ing, addressing issues. Developer, environment (literature) Focus on strategic and "value added" tools for patient education (Earl 1989). 1 In anticipation of researching this question, the developer began to sit-in on a number of provider-patient visits to assess current communication patterns. ' Societal values and policy choices determined within the context of health care and health promotion were to shape technology (Weitz 1990). Learning would address the institutionalization of technology after implementation and the need for the content of the system to address the constraints and opportunities identified in the health promotion literature (Orlikowski & Robey 1991). Task technology fit and the attempt to use IT to achieve an organizational impact were employed (DeLone & McLean 1991). ' See appendix C for a literature review of the heart disease and theories of health behavior. Chapter 4: Processes in the SoftHeart Case 84 4.7. Presentation Prompts Interest and Constraint Processes during this stage highlight the complex interaction between developer and users during SoftHeart's unveiling. The presentation of the software to the clinic personnel on September 29th produced both intended and unintended consequences. Clinic personnel were excited about the project 137(Newman & Noble 1990).138 In addition, the project exposure created an understanding of the SoftHeart project amongst clinic personnel, and sparked involvement 139(Ives & Olson 1984; Baroudi, Olson, & Ives 1986; Baronas & Louis 1988; Robey, Farrow, & Franz 1989; Hirschheim & Klein 1989). To the developer's surprise, this involvement produced a barrage of numerous and conflicting suggestions. For example, the risk calculator used "total cholesterol" to calculate risk, which raised concerns amongst some physicians. Other physicians stated that the calculator was relatively well-known in the general practitioner community, and was ideal for communicating information to that group. Development and usage of the risk calculator was more complex and controversial than expected 140(Nadler 1982; Schon 1983; Van De Ven Excitement, learning and user involvement were generated (Newman & Noble 1990). 1 Especially interesting was the general agreement that the graphing module would provide universal benefit to patient education, not provider education (Benbasat, Dexter & Todd 1986a; Benbasat, Dexter & Todd 1986b; Tan & Benbasat 1990). 1 Interest and understanding were sparked by the presentation (Ives & Olson 1984). Information satisfaction and usage were the goals of the presentation (Baroudi, Olson, & Ives 1986). The developer was attempting to build a sense of control amongst the clinic personnel to achieve agreement (Baronas & Louis 1988). Participation led to influence, conflict, and some conflict resolution (Robey, Farrow & Franz 1989). What began as an attempt to integrate users generated structural divisions that would lead to future conflict (Hirschheim & Klein 1989). Structural conflict was suggested by the disagreement over risk calculator. Whose side does the developer take? Complexity of design, and the possibility of a radical alteration of the organization could result from the introduction of the risk calculator (Harrington 1991). Ideas and development now being taken over by users in the organization, after two years in the developer's hands (Thomas 1994). ' Complexity of design illustrated by the disagreement over the risk calculator (Nadler 1982). Context "talks back" about the risk calculator, including the feasibility and controversy (Schon 1983). Conflict resolution and conflict creation occurred considering the use of the calculator (Robey, Farrow, & Franz 1989). Chapter 4: Processes in the SoftHeart Case 85 1986; Boland 1987; Turner 1987; Robey, Farrow, & Franz 1989; Hirschheim & Klein 1989; Harrington 1991; Thomas 1994). Many of the suggestions also indicated that the comfort of the users was as equally important in the design as patient outcome 1 4 I(Bostrom & Heinan 1977). The developer's 'scientism' view of ISD was beginning to change 1 4 2(Klein & Lyytinen 1985; Boland 1987). The diversity of these wants and desires also created a dramatic expansion and stretching of the SoftHeart concept 1 4 3 (Van De Ven 1986). Each group saw the technology as providing something for its specific needs, falling roughly into clinical, administrative, and research purposes 1 4 4(Kling 1980; Kling & Scacchi 1982; Markus 1983; Franz & Robey 1984; Newman & Noble 1990). Physicians focused on the potential of the database to store new data, improve information access, and improve information presentation for clinical and research purposes.145 Dietitians believed the system would provide computer resources in the consult room for immediately calculating patient dietary intake, and printing communication Sociotechnical design and the consideration of worker quality of life were being considered as important as technological development (Bostrom & Heinan 1977). ! "Scientism" focuses only on technology development and deployment, and is criticized in the literature (Klein & Lyytinen 1985; Boland 1987). 1 The management of the core concept is important in innovation (Van De Ven 1986). 1 Segmented institutionalism suggests there is a nondeterministic relationship between technology and context during development. Computers are seen as a package surrounded by a social and political setting. In the SoftHeart case, each group saw the technology as something specific and different (Kling 1980). Web models and social leverage were prevalent. Unfortunately, only the narrow boundaries of technology were originally considered by the developer. With so many different and new groups, the complexity of handling these views became complex (Kling & Scacchi 1982). Political perspectives on information systems illustrate that each group saw the technology as something specific and different, and the satisfaction of each group was important for future system survival (Markus 1983). Rational and political perspectives on the risk calculator suggestions, originally sounding like a rational debate, but in many cases, becoming political (Franz & Robey 1984). Conflict resolution, learning and political action appeared, as each group saw the technology as something specific and different, and measured its success by the power and prestige it could offer them individually (Newman & Noble 1990). ' Every physician was impressed with the graphing capabilities of SoftHeart for patient education and research analysis. It was a major selling point of the software. Chapter 4: Processes in the SoftHeart Case 86 messages for patients. The coordinator would see the project as an opportunity to produce a windows-based version of EasySys, with a few additional improvements for improve administrative efficiency.146 One particular group interested in SoftHeart was the research group and its director. The merger of SoftHeart with the research group's vision of an integrated wide-area network (LipidLink) produced both opportunities and constraints 1 4 7(Kling 1980; Markus 1983; Orlikowski & Robey 1991). The opportunities included development of the computing infrastructure, and additional funding and human resources for the project. The first meetings between the research group and the developer, however, also revealed new requirements and constraints on SoftHeart's design, including the research group's desire to use OS/2 as the operating system, to build strict data entry checking, and to develop extensive documentation. The following tables summarizes the processes appearing in this stage: ' When clinic two entered the project in March of 1995 they would see the SoftHeart project as an opportunity to move away from laborious manual tasks of recording, reporting, and counting patient information. They also saw the potential of the program to provide evaluations of their exercise program to themselves, hospital, and a government group skeptical of their program's efficacy. ' Segmented institutionalism describes the interactions and organizational politics. The SoftHeart system encompassed many old and new groups, producing opportunities and constraints (Kling 1980). The power structure and political nature of IS were reflected in the new constraints (Markus 1983). Norms, power, and resource within the organization produced constraints (Orlikowski & Robey 1991). Chapter 4: Processes in the SoftHeart Case 87 Table 4-7: Processes in the Interest and Constraint Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Presentation of Prototype EP Software functionality Sep. 29 1994 Generate interest and direction Users, Developer, Task, organization Barrage of user suggestions EP Functionality, interface, reporting Sep. 1994 to present User Involvement and struggle to integrate Developer, clinic personnel Discovery and joining of research group to LipidLink EP/ST System functionality, infrastructure, input, processing, data structure, program Oct. 1994 Confusion, Learning, and painful learning Developer, research group (users), environment 4.8. Conflict Erupts Processes during this stage highlight the structural power and conflict that erupted during information system development. In addition to the new constraints and requirements from the research group, the developer's new relationship with the research group reopened a schism between this group and the coordinator that had been unknown to him. A four-year history of the conflict between the research group and the coordinator had started when the research group's software (CholeSys; a pseudonym) failed to replace EasySys 1 4 8(Markus 1981; Kling & Scacchi 1982; Hirschheim & Klein 1989; Orlikowski 1991; Thomas 1994). CholeSys' strict data entry annoyed and challenged the coordinator's Political power struggle over CholesSys surfaced. The hiring of consultant by coordinator killed the project (Markus 1981). Web models of computing and the wider context and history of organizational conflict effected the project (Kling & Scacchi 1982). Radical structuralist and neo-humanist approaches to development appeared (Hirschheim & Klein 1989). Control mechanisms around computing and its control on other groups was central in SoftHeart's development (Orlikowski 1991). Supplier led innovation from inside the organization was rejected by powerful forces maintaining the status quo (Thomas 1994). Chapter 4: Processes in the SoftHeart Case 88 freedom to control her data entry work 1 4 9(Mohr 1987). Written in dBase and recently transported into Foxpro, CholeSys contained a number of software bugs. The hiring of an "independent" consultant by the coordinator and Clinic One produced a report that criticized the maintenance and structure of the program. CholeSys was never implemented, and the research group believed the coordinator had killed the project 1 5 0(Markus 1981; Markus 1983). The conflict between the research group and the coordinator would not have affected the development of SoftHeart if the project would have left EasySys alone. In many respects, this was the preferred strategy because programming would have been kept to a minimum. However, the developer discovered a number of problems with EasySys that affected the project's focus on risk calculation and graphing. These problems included missing data for risk calculation, missing fields for important risk data, EasySys' locking of files preventing information sharing, and the inaccessibility to EasySys' source code 1 5 l y y t i n e n & Hirschheim 1987; Cooper & Zmud 1990; Orlikowski 1991; Orlikowski 1992). As a result, the developer began building EasySys' data-entry functionality into SoftHeart in order to achieve the strategic benefits of risk calculation and graphing 1 5 2(Earl 1989).153 Two technologies wrapped in a conflict over control of information entry and delivery (EasySys and CholesSys). The same technology (SoftHeart) produced totally different attitudes amongst different parties (Mohr 1987). 1 System rejected because it failed to satisfy structural power interests in the organization (Markus 1981; Markus 1983). EasySys perceived by the developer as incapable of satisfying the present goals of health promotion and research (Lyytinen & Hirschheim 1987). There was a task-technology fit problem (Cooper & Zmud 1990). There was a desire of the research group to control the work of the coordinator using CholesSys (Orlikowski 1991). EasySys, with its inability to be modified, no longer supported in a changing social and technological environment (Orlikowski 1992). : There were obstacles to the strategic sharing of information with EasySys (Earl 1989). ' A single structural change to the database for new fields meant the old lipid program would be unable to run, because it did not support the data entry or reporting of that information. In addition, because the program locked the files during use, a new program to perform the new data entry and reporting of the data field could not use the data. Chapter 4: Processes in the SoftHeart Case 89 The developer's recent involvement with the research group, the coordinator's general dislike of outsider intrusion, and the developer's efforts to change Clinic One's information system caused the coordinator to demand that SoftHeart's interface be identical to EasySys. Later, these and other demands would become unfriendly and produced ever-changing obstacles to further development as the coordinator refused to work with the developer 154(Hirschheim & Newman 1991). User involvement and attempts to integrate the project goals with hers and those of the research group led to obstruction and derision 155(Turner 1987; Robey, Farrow, & Franz 1989; Newman & Noble 1990; Thomas 1994). The following table summarizes the processes appearing in this stage: User involvement and integration beneficial. Resistance perceived as dysfunctional. Politics needs to be a concern of the developer (Hirschheim & Newman 1991).. ' Goals were ill defined, and the means to those goals were fuzzy and obscured by the developer's inability to distinguish legitimate demands from user resistance. Design complexity and new issues emerged (Turner 1987). Unresolved issues of control and direction in the clinic amongst the clinic personnel (Robey, Farrow & Franz 1989). Conflict and learning about requirements, opportunities and structural conflict occurred (Newman & Noble 1990). Political struggle emerged between the administrative staff and the developers over the supplier-led and developed system (Thomas 1994). Chapter 4: Processes in the SoftHeart Case 90 Table 4-8: Processes in the Conflict Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Discovery of EP/ST Project Oct. 1994 Surprise and Research previous software failure conception bitterness group, developer, coordinator Problems ST/OI Data Oct. to Frustration, Developer, with EasySys management, Dec. need to coordinator, data elements 1994. move to new software old software Starting to OI/TI Interface, display, Jan 1995 Conflict Developer, incorporate input, reporting to present coordinator, legacy organization systems Conflict EP Functionality, infrastructure, Jan 1995 to March Time consumption Developer, coordinator, interface, input 1995 and exhaustion users, organization 4.9. Decision to Act Processes in this stage highlight the response of the developer team to conflict and politics appearing during the previous stage. Conflict with the coordinator, ever changing and increasing "requirements" from discussions with various individuals, and an offer to move to another project prompted the developer to write a series of conditions for his continuation with the project. This caused a sudden and unexpected chain of events over the next week leading to the removal of the coordinator. In late March, the developer concluded that internal problems within the clinic were the cause of the project's slow progress. From the developer's perspective, the project was Chapter 4: Processes in the SoftHeart Case 91 failing to achieve development goals 1 5 6(Lyytinen 1987; Lyytinen & Hirschheim 1987; Hirschheim & Newman 1991; Myers 1994a). Having received an offer to study the EMPOWER project earlier in the week, the developer now had the leverage for action 1 5 7(Markus 1983). The threat to withdraw prompted a series of structural changes as a number of clinic personnel were motivated to keep the project alive 158(Hirschheim & Klein 1989). The developer's list of conditions included equal power with the coordinator and director over administrative matters in the clinic, clinic acceptance of implementation deadlines, and a restriction of programming to areas of direct importance to patients 1 5 9 (Van De Ven 1986). Meetings with the lead physician and the director reconfirmed their commitment to the project. The developer told the director that he needed the source code for EasySys to modify the program to accommodate his research goals. Later that week, the director requested the EasySys's source code from the coordinator. The coordinator's refused to contact the programmer, leading to a confrontation between her and the director 1 6 0(Markus 1983). At a prototype demonstration at the end of March, the physicians' realized that the developer knew the EasySys software and had the capability to replace it. Consequently, the ' The change required in technology, organizational structure, and language context was not occurring (Lyytinen 1987). According to the developer's view, development was failing (Lyytinen & Hirschheim 1987). The belief in the universal success of user involvement was rejected (Hirschheim & Newman 1991). Certain people and groups stood to lose or gain from SoftHeart, and the developer was caught in the middle (Myers 1994a). ' Power, politics, a lack of commitment by important groups, and an offer to work elsewhere provided the leverage for action (Markus 1983). 1 Structural conflict and a threat to withdraw caused political turmoil (Hirschheim & Klein 1989). ' The developer was trying to convert ideas into good currency; and he required control over deadlines and important administrative matters (Van De Ven 1986). 1 A power struggle demonstrated the structural power imbalance between the director and the administrative arm of the organization (Markus 1983).. Chapter 4: Processes in the SoftHeart Case 92 physicians met after the demonstration, and the coordinator was fired 1 6 1(Markus 1983; Harrington 1991).162 The following summarizes the processes involved in this stage: Table 4-9: Processes in the Decision to Act Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Organization-al aspects causing project failure EP Project direction Jan to March 1995 Interest and worry Developer, environment, clinic personnel List of demands given EP Project continuation March 22 Ultimatum Developer, director, coordinator Director confronts coordinator for the source code EP Project setting March 23 Conflict Develop and coordinator Presentation leads to firing EP System goal/objective, system functionality March 27 Force Developer, coordinator, director, users 4.10. Project Builds Momentum Processes identified during this stage of development highlight the momentum the project gained after the conflict phase was resolved. The project moved into a new stage of development in early April of 1995. After the firing of the coordinator on March 31 1995, The firing illustrated a political struggle that had been deeply embedded in the organization (Markus 1983). Intervening in the organization with the SoftHeart project had upset a four year draw between the various groups, and left the organization without the resources of the coordinator (Harrington 1991). ' Many clinic personnel recounted stories about long-standing conflict and political fighting of the coordinator with clinic personnel, including three individuals that had left because of the conflict. Chapter 4: Processes in the SoftHeart Case 93 and with rising support and interest in the project from various internal and external groups, the project's momentum increased. The interest and involvement of the hospital's MIS groups suggested new opportunities and constraints 1 6 3(Kling 1980; Dutton 1981; Markus 1981; Kling & Scacchi 1982; Franz & Robey 1984; Van De Ven 1986; Orlikowski & Robey 1991). These groups became important in either closing the project down or supporting its future. The joining of Clinic Two provided an opportunity to test and develop SoftHeart in an organization focused more on the prevention of heart disease than Clinic One, with a currently manual information system and a more cohesive staff that Clinic One. As a result, the basic design of the software was reassessed, and resulted in structural changes in the data and software interface 1 6 4(Dutton 1981; Brooks 1987; Turner 1987; Argyris, Putnam, & Smith 1985). During this period, a scheduling module for SoftHeart was considered. The decision to build a scheduler was the first attempt to deal with the unique needs of Clinic Two, and to address serious administrative problems in Clinic One affecting patient care 1 6 5 (Van De Ven 1986; Earl 1989). There was a wider web of resources and groups interested in joining the project (Kling 1980). The changed context at Hospital Two was very different from Hospital One (Dutton 1981). The developer was learning about the structural power and interest groups that would affect the project (Markus 1981). The web of computing and social leverage appeared (Kling & Scacchi 1982). Rational and political perspectives were appearing in the meetings with different groups (Franz & Robey 1984). There were problems keeping the project focus, and converting ideas into currency (Van De Ven 1986). Elements of structural power and adaptive structuration were illustrated (Orlikowski & Robey 1991). ' The, Second Clinic produced a dramatic change in the context of SoftHeart's operation (Dutton 1981). SoftHeart was growing and adjusting to new pressures and opportunities (Brooks 1987). The increased complexity of means and goals resulted in a need to clarify boundaries (Turner 1987). Double loop learning was appearing (Argyris, Putnam & Smith 1985). 1 SoftHeart's information system concept was being stretched (Van De Ven 1986). The Scheduler was an attempt to address an important area to patient care (Earl 1989). Chapter 4: Processes in the SoftHeart Case 94 In addition, LipidLink required major expenditures in hardware and software to achieve project goals. The search for funding by the clinic was a response to the developer's threat to leave and a possibility of the project failing without a serious commitment of resources 1 6 6 (Van De Ven 1986; Lyytinen & Hirschheim 1987; Orlikowski & Robey 1991; Van De Ven & Polley 1992). As a result, the "web of computing" continued to expand 1 6 7(Kling & Scacchi 1982; Kling 1987) and the project gathered momentum and new and old individuals from the various dimensions (organization, user, environment, developers). The following summarizes the processes involved in this stage: Table 4-10: Processes in the Momentum Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Hospital groups become interested ST/EP Functionality, infrastructure Nov. 1994 to present Cooperative and competitive ideas Developers, hospital funding groups, MIS Joining of Second Clinic OI/EP System functionality, infrastructure, data structure, program March 30, 1995 High expecta-tions, new ally Developer, users in Clinic Two, environment Decision to move into Adminis-trative Areas OI/ST System Functionality April 25, 1995 Strategic and assistance Developer, clerks Search for Funding and Resources ST Infrastructure April 6, 1995 Optimism Developer, research director, director of Clinic One ' An innovation context was required to support development, and there was a need to manage whole-part relations (Van De Ven 1986). System success and failure depended on these resources. Failure now being redefined based on a full-scale electronic patient record (Lyytinen & Hirschheim 1987). There was an important need to address resources and organizational institutions to support the development of software and IT infrastructure (Orlikowski & Robey 1991). There was a renewed focus on funding and marketing, but learning was maintained (Van De Ven & Polley 1992). ' Web models of resources and infrastructure to support new electronic patient record were required (Kling & Scacchi 1982). In addition, there was a need to define system boundaries (Kling 1987). Chapter 4: Processes in the SoftHeart Case 95 4.11. Development Quagmire The increased momentum, however, combined with a series of new processes, created a bottomless list of requirements for SoftHeart. Soon after or perhaps because of the increased momentum, the developer became concerned with endless development and uncertainty. The increasing requirements and complexity of development reflected the increasing involvement of many diverse groups. These groups were diverse in their views of medicine, treatment, and technology in treatment. Reconciliation and identifying priorities was extremely difficult and not forthcoming from the groups themselves 168(Nadler 1982; Van De Ven 1986; Brooks 1987; Kling 1987; Turner 1987; Henderson & Kyng 1991). The loss of key personnel involved in early design and support for the project reduced the project's momentum, and the introduction of new members required relearning and discussion 1 6 9 (Van de Ven 1986; Attewell 1992). Much time was consumed discussing and motivating new members.. An already fragile relationship between the developer and the research group was fractured by a series of computer crashes 1 7 0(Dutton 1981; Kling & Scacchi 1982; Lyytinen Many groups and pressures from these groups increased complexity (Nadler 1982). Keeping focused and managing attention became important but difficult (Van De Ven 1986). Social pressures from various groups stretched the project in numerous directions (Brooks 1987). Defining the boundaries of the system became difficult but essential (Kling 1987). Defining boundaries and setting priorities was obscured by a fuzzy identification of goals and means to achieving those goals using IT (Turner 1987). Increased pressure and dangers of tailoring the system to everyone's needs increased (Henderson & Kyng 1991). 1 The need to reestablish awareness, rapport, trust and enthusiasm with new people consumed time and effort (Van De Ven 1986). Learning and key sources of information and project support were lost (Attewell 1992). ' Computer crashes fractured a volatile relationship, changing the setting of development (Dutton 1981). The web of computing around technological operation failed (Kling & Scacchi 1982). The contexts around the technology and the understanding of that environment was uncertain and incomplete (Lyytinen 1987). The project was failing (Lyytinen & Hirschheim 1987). Chapter 4: Processes in the SoftHeart Case 96 1987; Lyytinen & Hirschheim 1987). The finger-pointing and harsh reactions by both the developer and the research group threatened to create a schism between the two groups. As a result of an offer to move once again to another project, the developer threatened to quit 1 7 1(Markus 1983; Attewell 1992; Keil 1994). The following summarizes the processes in involved in this stage: Table 4-11: Processes in the Development Quagmire Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Explosion In Require-ments EP All levels May to August 1995 Optimism, confusion, complexity Users, Clinic One and Two, developer Loss of Key Personnel EP Functionality, infrastructure, program, interface, data March to Sep. 1995 Surprise and sadness Users, environment, organization Virus attack EP System goal/objective, infrastructure June to Sep. 1995 Confusion and frustration Users, developer, organization, environment Threat to Quit ST All levels August 20, 1995 Desperation and frustration Users, developer, organization, environment 4.12. Recovery and Slow Growth Toward Early Implementation A series of processes revived the project during this next phase of development. By mid-September 1995, the project was stalled. Once again, however, the developer's threat to Political maneuvers and power relationships threatened the project's success (Markus 1983). Key resources to the project's continuation were being lost. The clinic was not achieving self sufficiency (Attewell 1992). Project escalation resulted in a need to cut losses (Keil 1994). Chapter 4: Processes in the SoftHeart Case 97 leave revived the clinic's support for the project, and coincided with a number of other fortunate events 1 7 2(Markus 1981; Orlikowski & Robey 1991). The Monkey II virus was identified as the cause of the computer crashes, and calmed the fears and hostility about OS/2 by providing the research group with an identifiable cause and solution 1 7 3(Gibbs 1994).174 The research group also took the lead on the project, as the developer moved to the background as a consultant and software advisor. This leadership has been important in achieving the viability of SoftHeart away from its developer 1 7 5(Kidder 1981; Basalla 1988; Attewell 1992; Petroski 1994). The purchase of computers and network hardware and software started to produce visible signs of internal resource support, and coincided with the research group's movement into the lead 1 7 6(Kling & Scacchi 1982; Earl 1989; King et al., 1994). Additional resources arrived, including funding from a drug company, and the hiring of a programmer. The loss of a "free" developer and someone who knew the SoftHeart software caused a shakeup in the organization (Markus 1981). A key resource for future research capabilities and clinical care was threatened by the developer's dissatisfaction (Orlikowski & Robey 1991). 1 7 3 Technical problems were identified and new safety strategies were constructed (Gibbs 1994).. 1 7 4 The Monkey II virus is a boot sector virus released in early 1994, that infects the boot sector of a disk. The virus spreads by activation of a floppy disk in the floppy drive, and copies itself onto the hard drive of a computer. This virus then operates in memory, affecting other fresh floppy disks inserted into the computer. The virus eventually destroys the boot sector of the hard drive making it impossible to access the drive. Protection from the virus required anti-virus software, and "safe" computer practices. 1 7 5 Introduction of different personalities and skills sent the project in the direction of their wishes and dreams (Kidder 1981). The evolution of SoftHeart took a new direction with new people leading its development (Basalla 1988 & l' Petroski 1994). Institutional learning and competence for institutionalizing SoftHeart away from the developer began (Attewell 1992). 1 7 6 SoftHeart's "web" was being developed to support the IT infrastructure (Kling & Scacchi 1982). Strategic acquisition of resources occurred (Earl 1989). Institutional support and outside subsidization of the project appeared (King et al. 1994). Chapter 4: Processes in the SoftHeart Case 98 Early implementation has been difficult because of limited time with busy users, learning 1 7 7(Argyris, Putnam, & Smith 1985; Van De Ven & Polley 1992; Attewell 1992), mismatches between technology and task 1 7 8(Cooper & Zmud 1990), misunderstanding and early conflict 1 7 9(Markus 1983), and technical bugs that created user concerns and weakened confidence 180(Henderson & Kyng 1991; Wynn 1991). The following summarizes the processes in this stage: Table 4-12: Processes in the Recovery Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Support for the project revives ST Infrastructure August to Sep. 1995 Optimism Developer, users, directors Identification of the Virus EP Infrastructure Early Sep. 1995 Hope and surprise Research group, developer Research group takes the lead EP System Objectives Sep.to Dec. 1995 Project begins to live by itself Research group Resources arrive EP/OI Infrastructure, program Sep. 1995 through Jan 1996 Impetus Funders, computer suppliers, research group, developer Early Implementa-tion EP/OI Program, input, display, reporting, data management, data Feb. to April 1996 Concern, Chaos, and Cooperation Secretaries and Clerks, developers/ suppliers 1 7 7 Problems with single loop learning and a struggle to drive double loop learning began (Argyris, Putnam & Smith 1985; Van De Ven & Polley 1992). Learning and the knowledge enhancing or destroying aspects of technology were highlighted (Attewell 1992). 1 7 8 A mismatch between technology and task in this case was similar to the task-technology literature (Cooper & Zmud 1990). 1 7 9 Misunderstandings between administrative and development staff appeared (Markus 1983). 1 8 0 There was a weakening of confidence by producing a software that did not fully consider clerical work (Wynn 1991) and lacked user testing and tailoring (Henderson & Kyng 1991). Chapter 4: Processes in the SoftHeart Case 99 4.13. What Lies Ahead The following provides a number of processes outlining the future of SoftHeart. Structural power both threatens and supports the operation and the impact of SoftHeart 1 8 1(Dutton 1981; Markus 1981; Thomas 1994). The ability of the organizational and technical environment to support SoftHeart's operation and research focus is fairly strong 1 8 2(Kling & Scacchi 1982; Earl 1989). However, the support of SoftHeart's original goal toward patient care and the direct impact on improving patient care is uncertain. The growing role of LipidLink and the research group has shifted the project's focus from patient clinical care to research 1 8 3(Duttori 1981; Markus 1981; Van De Ven 1986).184 The following summarizes these processes: Politics within the clinics, the hospital and the government both threatened and introduced opportunities for SoftHeart to play a role (Markus 1981). Structural power and interests in the clinics moving SoftHeart away from patient clinical care to research (Dutton 1981; Markus 1981; Thomas 1994). : Resources available to support the continued development and infrastructure development appeared (Kling & Scacchi 1982). Strategic benefits of SoftHeart appearing with competition for government and hospital funding (Earl 1989). 1 The changed development environment around SoftHeart has altered its role from the developer's focus on patient and clinical care, to the research group's focus on a database for research. Dutton (1981) discusses the effect of a changed development environment on technology adaptation and rejection. Markus (1981) discusses how technology will only survive if it is adapted to the power relationships in the context. Van De Ven (1986) discusses the need for a core concept, and the focusing of resources on that concept to develop an innovation. In this case, SoftHeart is being stretched in a number of competing directions, and has created a recent funding crisis. 1 Patient clinical care is becoming the least important focus of implementation and development efforts. Instead, research and the administrative data entry and personnel responsible for data entry, have been the focus. Chapter 4: Processes in the SoftHeart Case 100 Table 4-13: Processes in the Future of SoftHeart Description Theory Technological Level Time Type of Interaction Stakeholders from Context Threats to Operation ST Project conception Future Uncertainty Developer, research group, MIS department, drug company Threats to Impact ST/OI Project conception Future Uncertainty Developer, research group, clinics, directors 4.14. Case Conclusion An analysis of the processes, process stages and the overall ISD process will provide some insights into the four process theories. 4.14.1. Process Analysis In terms of mutual exclusivity, the following table shows the process types in each process stage of SoftHeart's development: Chapter 4: Processes in the SoftHeart Case 101 Table 4-14: Summary of Process Types in Process Stages Process Stage Number of Processes Process Types Project Emergence 3 EP, EP, OI/TI Health Funders Skeptical 2 EP/TI, EP/ST Our Response 3 ST/EP, 01, OI/EP Old and New 3 EP, EP/ST, EP/ST Environmental Shocks Decision to Move Ahead 6 EP/OI/ST, EP, EP/OI, OI/EP, 01, ST/OI Presentation Sparks 3 EP, EP, EP/ST Interest and Constraint Conflict Erupts 4 EP/ST, ST/OI, OI/TI, EP Decision to act 4 EP, EP, EP, EP Project Builds 4 ST/EP, OI/EP, OI/ST, ST Momentum Development Quagmire 4 EP, EP, EP, ST Recovery and Slow 5 ST, EP, EP, EP/OI, EP/OI Growth to Early Implementation Future 2 ST, ST/OI ISD Overall 43 T l 3, 3 Shared, Ol 15,13 Shared, EP 31,15 Shared, ST 16,12 Shared 2-6): The following table shows the ISD research attached to the process stages (see table Chapter 4: Processes in the SoftHeart Case 102 Table 4-15: ISD Research Categories within Process Stages Process Stage Process ISD Research Types Project Emergence TI (1) Technology; System 01 (1) Task technology fit; EP (2) Designer's view; Evolution of technology; Innovation Health Funders Skeptical TI (1) Technology; Systems EP (2) Evolution of technology; User involvement; Innovation ST (1) Adaptive structuration Our Response 01 (2) Structured information systems planning; Structured design and analysis; User involvement EP (2) Evolution of technology; User involvement; Innovation ST (1) Adaptive structuration; Structural power Old and New Environmental Shocks EP (3) Technology divergence (Uni); Predicament of design; Evolution of technology; Innovation ST (2) Adaptive structuration; Structural power Decision to Move Ahead 01 (5) Strategic information systems planning; User involvement; Task technology fit EP (4) Predicament of design; Emergent evolution of technology; Innovation ST (2) Adaptive structuration; Structural power Prototype Presentation Sparks Interest and Constraint EP (3) Developer's view; Alternative views; Predicament of design; User involvement; Innovation ST (1) Adaptive structuration; Structural power Conflict Erupts TI (1) System 01 (2) Task technology fit EP (2) User involvement ST (2) Adaptive structuration; Structural power Decision to act EP (4) Technology divergence (Uni); User involvement; Innovation Project Builds Momentum 01 (2) Strategic information systems planning EP (2) Technology divergence (Uni); Predicament of design; User involvement ST (3) Adaptive structuration; Structural power Chapter 4: Processes in the SoftHeart Case 103 Development Quagmire EP (3) Technology divergence; Predicament of design; User involvement; Innovation ST (1) Structural power Recovery and Slow Growth to Early Implementation 01 (2) Strategic information systems planning EP (6) Technology divergence (Uni); Predicament of design; Evolution of technology; User involvement; Innovation ST (3) Structural power Future 01 (1) Strategic information systems planning ST (2) Adaptive structuration; Structural power Keeping in mind the subjective selection of critical events and processes, the following observations can be stated. First, the emergent perspective is linked with thirty one of forty three processes, a result of the complex environment at the two clinics and the role of the developer. Emergence affected all levels of technology, but substantially affected lower levels such as interface design. Emergence best described several important processes including project initiation, external shocks from health funders, new stakeholder groups joining the project, the developer's influence and learning on design, prototyping, internal shocks from political activity inside the clinics, and historical conflict between various groups. Second, the social technology perspective and organizational imperative are used to describe sixteen and fifteen processes respectively, but a large number of these processes ( twelve and thirteen respectively) are also described using other theories. The technological imperative was used to describe the fewest of the case processes, and describes none of the processes on its own. This may reflect the early development period, and the rapid changes in ideas arid software during this stage. Perhaps later stages of implementation would be explained more by a technological imperative once the software is "closed". Chapter 4: Processes in the SoftHeart Case 104 Examining special case and equal validity explanations, the following table summarizes the "shared" processes: Table 4-16: Examination of Shared Processes Process Total Shared* with TI with OI with EP with ST TI 3 - 2 1 0 OI 13 2 - 7 5 EP 15 1 7 - 8 ST 12 0 5 8 -* Note: the "total shared" numbers are one smaller than the sum in the OI, EP and ST rows because of a triple-coded process. The table shows a connection between the emergent perspective and organizational imperative (seven shared), emergent perspective and social technology (eight shared), and social technology and organizational imperative (five shared). Each may be special cases of the other. For example, the connection between the organizational imperative and the other two implies that strategic considerations occur within an environment and set of technological constraints or opportunities. The link between emergence and social technology may indicate a fine line between social technology's soft-line determinism and the unpredictable nature of emergence.185 Examining association between process types over time, the following table summarizes the number of times a process type followed another process type: 1 In fact Barley (1986), an adaptive structuration and social technology researcher, states that many explanations of structure's effect on technology and vice versa can only be explained through historical analysis. Chapter 4: Processes in the SoftHeart Case 105 Table 4-17: Number of Times One Process Type is Followed Another Type Process Total byTI byOI byEP by ST TI 5 1 0 3 1 OI 21 2 7 8 4 EP 47 1 11 23 12 ST 22 1 5 9 7 Once emergence appeared, it was usually followed by another emergent process (twenty three of forty seven). Combining social technology and organizational imperatives described another twenty three of the forty seven emergent "followings", suggesting a close relationship among the theories. This close relationship among the emergent perspective, social technology and the organizational imperative was illustrated in the other numbers. An organizational imperative was followed by an emergent process in eight of twenty one, an organizational imperative in seven of twenty one, and a social technology process in four of twenty one. In addition, social technology was followed by another social technology process in seven of twenty two, and an emergent process nine of twenty two times. Finally, technological imperative "followings" occurred only five times, but three of these five were followed by an emergent perspective, suggesting a connection between the two. The next table shows the likelihood of a series of processes with one type being terminated by one or more other process types, and provides evidence of a possible connection between the organizational imperative and the emergent perspective: Chapter 4: Processes in the SoftHeart Case 106 Table 4-18: Number of Times a Series of One Process Type was Terminated by Another Type Process Total byTI by Ol byEP by ST Tl 3 - 0 2 1 01 8 1 - 5 2 EP 10 1 5 - 4 ST 9 1 3 5 • •-A series of processes described by the emergent perspective were terminated by processes described as organizational imperatives and social technology on five and four respective occasions. On the other hand, a series of processes described by organizational imperative were usually terminated only by an emergent process (five of eight), while a series of social technology processes are terminated by organizational imperatives and emergent perspectives in three and five times respectively. This finding implies that organizational imperatives may be "disturbed" by new emergent processes, and a series of social technology or emergent perspectives may be "disturbed" equally by the other two process types. 4.14.2. Information System Development The predominance of emergent processes suggests an interplay between the emergent perspective and the other process theories, especially social technology, over time. As a result, many process stages in the case were emergent, and ISD was overall emergent. Adaptation to sudden shocks or learning sent the project into reflective disarray. To achieve control once again, it appears that social technological constraints or opportunities were incorporated into the project's concept, the project direction was modified, and development continued. Occasionally, the developers were able to alleviate many of the constraints to create an organizational imperative process. Chapter 5 - Processes in the Development of EMPOWER 107 5. Processes in the Initiation and Development of EMPOWER The development of EMPOWER involved a series of processes between technology and context over time. Important in these processes were various stakeholders including the developer (myself), the project leader, the development team, funding agencies, the US company, health promotion researchers, and software suppliers. This chapter reports on critical and illustrative technology-context processes within "process stages" in the development of E M P O W E R . 1 8 6 Processes, process stages, and the ISD are discussed using the four process theories and research of chapter 2. Citations to the literature and inference rules for each process are provided.1 8 7 First, the chapter describes the development team, the vision of the EMPOWER's role in breast cancer planning, and the software in its present form. The majority of the chapter examines the various processes appearing in the process stages of EMPOWER's development.188 The following table summarizes these process stages: ' At the time of writing this thesis, EMPOWER had reached the early implementation stages in two communities, and development of a new EMPOWER had recently begun. Appendix B provides a more detailed account of the chronological events in the EMPOWER case, and provides the raw data used to build this chapter. 1 Note that these stages, although presented sequentially, were often overlapping. Chapter 5 - Processes in the Development of EMPOWER 108 Table 5-1: Process Stages in the Development of EMPOWER Process Stage Time Period Stage Project Emergence November 1993 - April 1995 Initiation Getting Ready March - September 1995 Adoption Pandora's Box Opens September - October 1993 Adoption and Adaptation Squeezing the Most from Toolbook and EMPOWER September 1995 - April 1996 Visions of a New Software Constrained by Resources December 1995 - April 1996 Initiation, Adoption, Adaptation and Acceptance The chapter concludes with a discussion of the case and the four process theories' explanation of EMPOWER's development. 5.1. The Development Team and EMPOWER The development of a Canadian and international version of EMPOWER was carried out by a team of health promotion researchers, including the developer. The purpose of development was to produce a Canadian and international version of EMPOWER from the US version of the software, and to implement and observe the usage of the software in two Canadian communities planning mammography screening interventions. Further adaptation of the software would be completed from experiences in the field. The team consisted of the principal investigator and project leader, a co-investigator for the BC case study, a co-investigator for the Quebec case study, research assistants at the University of British Columbia and the University of Montreal, a developer (me), a programmer, and one secretary. Other individuals were hired and/or volunteered for various parts of the project. The project was funded by the National Cancer Institute of Canada (NCIC), which was interested only in the implementation and development of a planning Chapter 5 - Processes in the Development of EMPOWER 109 methodology across Canadian communities. NCIC provided a 2 year grant for the pilot testing of the planning tool in the Canadian settings,. EMPOWER (Expert Methods of Planning and Organizing Within Everyone's Reach) is a Windows standalone software program to support planners of mammography screening interventions in community settings. The planning model represented in the software is based on the project leader's model of health promotion planning, which has been employed successfully in numerous settings. The model employs a bottom-up (participatory) and top-down (scientific and technical) approach to planning, assessing the resources of the community for planning (situational analysis), the needs of the population (social analysis), the health issues in the population affecting these needs (epidemiological analysis), the behavioral and environmental factors affecting health (behavioral and environmental analysis), the predisposing, reinforcing, and enabling factors affecting those behaviors and environment (educational and organizational analysis), and the educational, policy, regulatory, and organizational factors needed to change those factors (administrative and policy analysis). In addition, "consult-on-tap" resources are available, including health promotion model references, a combined health information database, case examples, "responding here" help, page references, university and non-university resources, clinical oncology centers, the American 2000 health objectives, intervention ideas, and glossaries. The software platform used to build EMPOWER is Asymetrix's Multimedia Toolbook. Based on the metaphor of a book, the programmer creates books with pages, Chapter 5 - Processes in the Development of EMPOWER 110 backgrounds, and fields for navigating pages, reading information, and entering data. Multimedia capabilities are used in EMPOWER to catch user attention, and to provide information about the planning stage described on the page. In addition, menus provide access to "consult-on-tap" resources.189 EMPOWER consists of 6 basic books to address the six stages of the planning model, and is linked together to provide the users with a sequential view of the planning model and their project. Information about the specific project is entered into a project file, and this information is then used in "expert" summary reports that summarize the data, provide some tips for planning, and display scientific evidence or professional experience in dealing with circumstances described (categorized) by the user. The program structure is displayed below: See Appendix F to view some of the screens in EMPOWER. Chapter 5 - Processes in the Development of EMPOWER Figure 5-1: EMPOWER Program Structure 111 Situations 3l Analysis Social Analy rsis Epidemiolot Analysis gical Behavioral a Environmen V nd tal Analysis n ft Educational Organizatior V and lal Analysis l i • Administrativ 7 te Analysis Project Files: 1. Contacts 2. Project Data 3. Objectives Resource Files: 1. Model References (bibliography) 2. University Sources 3. Non-University Sources 4. Oncology Centres 5. Combined Health Database 6. Year 2000 Objectives 7. Interventions 8. Glossary 9. Model Help Page Resources: 1. " C a s e Examples" Help 2. "Responding Here" Help 3. Model References 4. "Why" Help Currently, EMPOWER is being used in two Canadian communities to assist in developing a mammography screening campaign to increase women's involvement in mammography screening. Initial results confirm that the users use the software for initial planning and as a resource. In the first community (Richmond, B.C.), however, the software is not being used as a planning tool to organize and produce the plan continuously throughout the process. The second setting (Montreal) is just beginning its use of the software at the time of this writing. The following sections provide a stage-by-stage description of the ISD process of the Canadian and international version of EMPOWER. Chapter 5 - Processes in the Development of EMPOWER 112 5.2. Project Emergence Important in understanding information systems development are the processes resulting in the initiation and creation of IS and IT. The EMPOWER project emerged from a series of opportunities and interests between the developer, the director, the project team members, the funding agencies, and the US company stakeholders 1 9 0(Basalla 1988; Petroski 1994; Thomas 1994). The opportunities perceived in the project varied amongst the individual members of the team. For the project leader, EMPOWER represented an opportunity to diffuse his model of planning to many users, and through redevelopment, to free the software from the exclusive control of the US company.191 The project also provided the project leader with an opportunity to redevelop EMPOWER for other health areas, and to produce a generic version to reach many users. For the developer, the project was an opportunity to complete his thesis with a project that would lead to software use. It also provided an opportunity to form closer ties with health promotion researchers. For other team members, the project represented a chance to be a part of an important research grant, to work with the project leader, to work with leading edge technology, to develop a tool to improve planning, and to put their fingerprints and ideas on a potentially wide-reaching tool. For the communities involved in testing the software, the project represented an opportunity to build better plans. 1 The group identified an opportunity to improve and modify the US version of the software for Canada (Basalla 1988). The evolution of a technology and emergence occurred through suppliers (Petroski 1994; Thomas 1994). Negotiations between the project leader and the US company over development, use, copyright and marketing of subsequent versions of the software was the developer's first introduction to the project (January 1994). The developer concluded that because the project leader was paid by the US company, the US version of the program was property of the US company. Any modification of the program would require a percentage royalty to the US company based on the percentage of the original code in the product. Chapter 5 - Processes in the Development of EMPOWER 113 During 1994, meetings about the US copyright and a discussion with Statistics Canada about downloading epidemiological data for EMPOWER, demonstrated the "web of computing" around the project I 9 2 (Kling & Scacchi 1982). In addition, the developer's increasing involvement with a number of software projects with the health researchers fused his interests in studying software development in health settings to the health promotion group's interest in using software as a medium for changing health policy and planning behavior 1 9 3(Earl 1989; Hirschheim & Klein 1989; Attewell 1992; Thomas 1994). During early 1995, project directions, constraints, commitments, opportunities, and resources arose from discussion and external influences 1 9 4(Dutton 1981; Kling & Scacchi 1982; Markus 1983; Orlikowski 1991; Thomas 1994). The problem definition and problem solution were generated and changed simultaneously based on the funding agency that would eventually support the project and the numerous goals and issues raised 1 9 5(Dutton 1981: Kling & Scacchi 1982; Turner 1987; Thomas 1994). Originally focusing on tobacco control, it was soon realized that heart disease, mammography screening, and/or self care were other potential areas of redevelopment depending on funding agency responses. When a research : Web influences around the project included the history of the US version and future connections with data suppliers (Kling & Scacchi 1982). 1 The software represented a medium for changing health policy and planning (Earl 1989). There was an integration of interests and goals toward software development (Hirschheim & Klein 1989). EMPOWER involved learning and supply side innovation (Attewell 1992; Thomas 1994). ' There was a contextual assessment of commitments, opportunities, constraints and assumptions of development (Dutton 1981). This analysis represented a web analysis of key players and goals (Kling & Scacchi 1982). Structural power and different interest groups were identified (Markus 1983). Pressures and forces shaping design were identified (Orlikowski 1991). Process-political considerations of EMPOWER's development were discussed (Thomas 1994). ' The setting of development was being created at the same time as the software ideas were being formulated (Dutton 1981). Resources to support development and implementation of the software in two communities were being considered (Kling & Scacchi 1982). Problem generation and solutions considered simultaneously (Turner 1987). Supplier led development initiated by developers' visions (Thomas 1994). Chapter 5 - Processes in the Development of EMPOWER 114 grant proposal for tobacco control was not funded, a three week period of confusion appeared 1 9 6(Dutton 1981; Kling & Scacchi 1982). When the National Cancer Institute of Canada decided to fund a separate grant proposal that had been submitted earlier, the project shifted focus from the redevelopment of EMPOWER toward tobacco control, to the modification and field testing of the US mammography screening version in Canada. The pieces fell into place 1 9 7(Earl 1989; Orlikowski & Robey 1991). The following table outlines the important processes in the emergence stage: ' Loss of original context made original plans irrelevant (Dutton 1981). Web resources for funding and target audience failed (Kling & Scacchi 1982). ' There was a strategic direction and leveraging of existing US version focused on mammography (Earl 1989). Institutionalization and context affects the constraints, opportunities and governing principles of the project (Orlikowski & Robey 1991). Chapter 5 - Processes in the Development of EMPOWER 115 Table 5-2: Processes in the Emergence Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Opportunity EP Project conception Nov. 1993 - Jan 1996 Exploration and discussion Developer, project leader Meetings EP/OI Project Jan. 1994 Key early Developer, about conception - Jan. issues arise project leader, copyright and 1995 US company statistical data Increasing EP/OI Project June 1994 Interest and Developer, involvement with health conception - Jan. 1995 exploration project leader, other health promotion promotion group groups Meetings of EP/ST System objectives Feb. - Organization Developer, Tobacco and system Mar. 1995 project leader, control functionality US company, project U B C project team Tobacco EP System objectives April 1995 Surprise and Health funders, grant loss of U B C project rejected momentum team, Health Canada Mammo-graphy OI/ST System objectives April 1995 Rejuvena-tion and Developer, project leader, screening reorientation NCIC funder, funded U B C project team, US company 5.3. Getting Ready During the Getting Ready stage, the development team focused on the goals and constraints of modifying the EMPOWER software for the Canadian and international setting. Many visions, ideas and the uncertainty about the US software created a large number of Chapter 5 - Processes in the Development of EMPOWER 116 complex paths to consider 1 9 8(Nadler 1982; Kling 1987; Turner 1987; Orlikowski 1991). Choices were made with uncertain information about their positive and negative impacts on the project. To cope with the complexity, one of the early structural decisions was the separation of the "content" group from the "structural" (programming) group. The structural group was to be led by the project leader with the developer as the programming supervisor. The content group was to be led by the co-investigator on the project team.1 9 9 To form a common language, the team used the Toolbook language (books, pages, buttons, etc.), providing a common ground for discussion between the content and structural groups 2 0 0 (Van De Ven 1986; Boland 1990). The most important decision facing the project at that point was the "make" versus "buy" decision; whether to adopt the US version and modify it for the Canadian setting, or whether to start from scratch. Advantages of modifying the US version appeared to include a nearly completed product and beta-tested source code thereby reducing the need for extensive user involvement, a proven tool for expert planning 2 0 1(Sviokla 1989; DeLone & McLean 1992), a good template for future software inventions 2 0 2(Petroski 1994), fewer resources ' Many visions and ideas about the course of development is similar to the problems of complexity outlined by Nadler (1982). Setting software development boundaries was an important but overlooked issue during early stages (Kling 1987). Problem definition and solution simultaneously considered (Turner 1987). The planning process was to be tightly embedded in the software technology. The number of matches between planning and tools for planning infinite (Orlikowski 1991). ' Without direct user involvement, the content group represented the "users" of the software. 1 Whole part management of the project important (Van De Ven 1986). Hermeneutics and team members' background affected the goals, discussion of the goals and task specialization (Boland 1990). Use of expert systems, and evaluating its impact important in the project (Sviokla 1989). Task technology fit assessed (DeLone & McLean 1992). 1 Evolution or revolution of the US version was discussed. Obvious shortfalls in the US version were uncovered (Petroski 1994). Chapter 5-Processes in the Development of EMPOWER 117 required relative to developing a Canadian version from scratch, and backup support from the US company 2 0 3(Earl 1989).204 Advantages of starting from scratch included: freeing ourselves from the US company over access to the code documentation and copyright, avoiding the difficulty of learning the Toolbook programming language and deciphering the existing code, building a faster program, decreasing the size of the program205, addressing the fragmented storage of information, and overcoming some undesirable interface characteristics of the US version 2 0 6(Markus 1981; Kling & Scacchi 1982).207 A third strategy included a number of intermediate approaches between "buy" and "make", including outsourcing of functions to other programs, and handling most database intensive functions in a separate database platform that would be called by Toolbook. Important in these considerations was the exploration of the US software package to evaluate its technical and functional capabilities. Various factors inadvertently favored the "buy" decision such as limited time, a course with the Toolbook company that favorably influenced the developer's impressions of the software, and the purchase of the Database Connection marketed by the Toolbook company to potentially solve data storage problems in 1 Strategic resource considerations were evaluated (Earl 1989). ' During June of 1995, we did receive some indication that the package had only been tested in educational environments, as part of its demonstration in workshops. We also received warnings about modifying the code from the leader of the US team. ' Currently, EMPOWER requires over 12 Megabytes of disk space. ' Previous commitments and copyright restrictions with the US company considered (Markus 1981). The web around development was in formation and evaluation (Kling & Scacchi 1982). ' These poor interface characteristics included page-by-page navigation, lack of standardized screen appearance, and the large number of pages (96). Chapter 5 - Processes in the Development of EMPOWER 118 the US version 2 0 8 (Kling & Scacchi 1982; Attewell 1992; Tyre & Orlikowski 1994). As a result, the developer recommended the project team redevelop the US version in late August. With the buy decision behind us, the remaining resources fell into place during early September, including the hiring of a programmer whose influence on the project would be important 2 0 9(Kidder 1981; Earl 1989). The following table summarizes the processes involved in this stage: Table 5-3: Processes in the "Getting Ready" Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Many goals EP/ST Project conception, system objectives Mar. 1995 -Aug. 1995 Weighing goals and alternatives Developer, and development team Division of labor EP Program, data structure Mar. -Aug. 1995 Specializa-tion based on expertise Developer, and health promotion researchers Make versus buy decision OI/TI/ ST Infrastructure Mar. - Sep. 1995 Choice Developer, US team, US com-pany, U B C project team Exploring the US ver-sion EP/ST Program and data structure Mar. -Dec. 1995 Search and influence Developer, US software team Addition resources fell into place ST/OI Infrastructure Sept. 1995 Acquisition Developer, project leader, U B C project team, NCIC funder. ' The formation of the web of resources began to support development by purchasing the database connection to solve data storage problems (Kling & Scacchi 1982). Learning and barriers to implementation considered (Attewell 1992). Drive for production and time constraints limited the learning and web formation time (Tyre & Orlikowski 1994). ' Team members' personalities and expertise important for success (Kidder 1981). Strategic resource assessment and procurement completed (Earl 1989). Chapter 5 - Processes in the Development of EMPOWER 119 5.4. Pandora's Box Opens Almost simultaneously as the group was preparing for development, problems were uncovered in the US version of EMPOWER. Examination of the US version revealed some potentially serious problems. Blinded by the possibility of quick success, however, momentum prevented us from responding actively to this evidence 2 1 0 (Van de Ven & Polley 1992). Without documentation, the programmer and the developer were faced with the difficulty of exploring code embedded in numerous objects on each page of the US version of EMPOWER, including push buttons, fields, pages, backgrounds, books, and four large system books. This code was very frequently undocumented except for brief comments, and a significant portion of this code is still unknown and potentially old code that is no longer being used. The problems with object orientation also became an issue with case examples, 'responding here' help information for each page, and references which to our surprise were properties of each page. This made it extremely difficult to review and change the information 2 1 1(Brooks 1987; Turner 1987; Gibbs 1994). As a result of unclear documentation, changes to the program often had unexpected and unwanted results. On many occasions, a single change turned into a string of changes required to fix rippling software bugs 2 1 2(Nadler 1982; Brooks 1987; Turner 1987; Harrington 1991). A clear case of an inability to learn from the symptoms of design flaws in the US version as the lure of quick success prevented double-loop learning (Van De Ven & Polley 1992). Invisibility and complexity of design caused changes to ripple (Brooks 1987). Complex and abstract software with poor documentation hindered learning (Turner 1987). Poor initial design in US version became apparent (Gibbs 1994). The complex environment around design and complex US design caused confusion and anxiety (Nadler 1982). The invisibility and complexity of software made it difficult to analyze and change (Brooks 1987; Turner 1987). Change to software caused unexpected results in program operation and user interface (Harrington 1991). Chapter 5 - Processes in the Development of EMPOWER 120 Discussion with the project leader and the two colleagues identified a number of reasons for the software's complexity. First, the scope of the project extended beyond the resources available at that time 2 1 3 (Van De Ven 1986). Second, the US company's organizational approach to late-stage development was to farm out the software to a private developer who had previously been on the in-house programming staff. This eliminated the chance for closer communication between the US and Canadian programmers and monitoring of activities 2 1 4 (Van De Ven 1986; Keil 1995). Third, both educational and planning objectives were incompletely built into the software by the two colleagues holding these views. This increased EMPOWER's size and produced a mixture of pure educational and pure planning pages 2 1 s (Kling 1980; Kling & Scacchi 1982; Van De Ven 1986; Boland 1990; Petroski 1994).216 In addition, problems with "content" in the software indicated that the program might no longer be relevant to the users' setting 2 1 7(Dutton 1981). First, changes in research approaches toward full breast health, including breast self examination (BSE) and clinical breast examinations (CBE), may have made the singular focus on mammography screening Demands exceeding the resources available, similar to Van De Ven's four central problems of innovation (Van De Ven 1986). ' Inability to leam the US programmer's approach to design caused a reduction in whole-part coordination (Van De Ven 1986). The result was the basis of project escalation and increased commitment (Keil 1995). ' A mixture of planning and educational suggested a possible confusion in approaches and overall goals (Kling 1980; Kling & Scacchi 1982). Reasons for the software poor design included demands exceeding initial resources, and loss of key programmer that sealed the product to easy modification (Van De Ven 1986). There was a hermeneutic confusion trying to understand a foreign object (Boland 1990). The old software was critiqued as evolution begins (Petroski 1994). The loss of key programmer on the project resulted in loss of an essential resource (Keil 1995). ' In fact, some modules were designed primarily by the educational proponent (e.g. situational analysis), and some modules primarily by the planning proponent (e.g. aa^ ministrative and policy analysis). Middle modules were handled by the programming staff. ' Dutton's (1981) study of a change in local governments and their policies effect on the development and relevance of a land planning system provided insights into this EMPOWER process. Chapter 5 - Processes in the Development of EMPOWER 121 unpalatable to researchers and planners in Canada. Second, new references and the rewriting of poorly written case examples were also required to make the software relevant. Finally, four different versions of EMPOWER 1.1 were discovered, illustrating symptoms of project management problems at the US company 2 1 8 (Van De Ven 1986; Latour 1987). Each one of the four versions contained incomplete information, and each version had more complete data in certain areas. This required a building of an integrated version that included the correct data from all four versions. One of the fallback scenarios the U B C team had agreed upon as a contingency plan, i f the EMPOWER software proved difficult to change, was the outsourcing of important functions to other software. However, attaching dynamic link libraries (DLL) to Toolbook was very difficult, and the database connection failed to produce a stable and reliable connection with the files 2 1 9 (Kling & Scacchi 1982; Brooks 1987; Turner 1987). In addition, the use of other database packages to access the program files to update content caused unexpected structural changes to the files. The team found itself stuck with a software "island", and with little time left until software implementation in community one 2 2 0(Orlikowski & Robey 1991). ' Problems with project management at the US company affected and confused the development team (Van De Ven 1986). The development team opened the black box and discovered problems and controversy embedded in poor software code (Latour 1987). 1 The web of computing components failed to fix data management problems (Kling & Scacchi 1982). Complexity and time was consumed working with abstract and poorly documented Dynamic Link Libraries (DLL) (Brooks 1987). The complexity of design and poor support hampered efforts (Turner 1987). 1 The software failed to meet development team expectations, suggesting that structural goals were constraining and directing development (Orlikowski & Robey 1991). Chapter 5 - Processes in the Development of EMPOWER 122 Meanwhile, the development list continued to grow beyond "Canadianization" of the software. Many of the software bugs required detailed work. In addition, many of the development expectations generated by early enthusiasm caused development requirements to expand 2 2 1(Nadler 1982; Van De Ven 1986). Large lists of changes by numerous individuals were compiled in early September and continued to grow throughout the four months. Ideas and visions of international and generic versions of EMPOWER, that would serve many disease and health promotion areas, also increased the "wish" list. The team lost sight of a core concept. The change lists reflected a reactive approach to the software, where problems and functions on each of the ninety six pages drove development 2 2 2 (Van De Ven 1986). Being rather loosely constructed, the US version led us in many directions fixing functions that in retrospect may not be essential to health promotion planning 2 2 3 (Van De Ven 1986; Brooks 1987; Mohr 1987). The developer's reaction to the development problems and the US version were mixed. At various points throughout the project, the developer suggested switching to an alternative software platform, and interjected that the US software was poorly designed. The result would be a product that would fail as a planning tool. At other times, he stated that the Demands and promises from various individuals and groups, combined with inability to penetrate the US version of the software, increased complexity (Nadler 1982). Project requirements and programming team abilities were diverging (Van De Ven 1986). : Software drove the core concept and obscured a core vision (Van De Ven 1986). 1 Management of the project spiraled out of control (Van De Ven 1986). Changeability and expansion in social demands from various groups increased complexity (Brooks 1987). The malleable and expansive nature of IT was not controlled by the development team (Mohr 1987). Chapter 5 - Processes in the Development of EMPOWER 123 US version would eventually yield to programming techniques, and suggested that the group was merely adding to a tested and nearly completed software package.224 Despite these wishes, various project meetings throughout December 1995 were marked with increasing concern about the remaining changes and the inability to achieve many of these goals. With little time remaining until the mid-January implementation of EMPOWER in Community One, suggestions were made to disable features that were bugged or had data irrelevant to the Canadian setting 2 2 5(Gibbs 1994; Keil 1995). In addition, plans were made to ensure that the earlier modules were ready, and later modules would be developed during January and delivered to the community once available. The following summarize the processes in this stage: The developer and programmers found it especially difficult to explain these constraints and alternative approaches to the content team who had difficulty understanding the technical issues behind the problems. It was also difficult to explain broken promises. ' Disabling non-functioning features was a method of avoiding poor software code (Gibbs 1994). This was a last minute attempt to deal with project escalation (Keil 1995). Chapter 5 - Processes in the Development of EMPOWER 124 Table 5-4: Processes in the "Pandora's Box Opens" Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Exploring EP Program Sep. 1995 Frustration Programmer, the Code to Present and time Developer Difficult consuming Software EP Program Sep. 1995 Surprise and Programmer, bugged and to Mar. unwilling- Developer, US complex 1995 ness to accept software team Major EP Software Sep. 1995 Surprise and Content team, content problems functionality and interface to Dec. 1995 Struggle to shape Developer, Programmer Version and documenta-EP Program and data. Sep. 1995 to Present Uncertainty and US company, content team, tion frustration Developer, problems Programmer with US version Outsourcing EP Data management Sep. 1995 Time Developer, including database - Present consump-tion, programmer connection frustration, fails failure Project EP/ST Software Aug. 1995 Changes Content team, scope expanded functionality - Present piling up Developer, Programmer Team EP Software Sep. 1995 Stick with U B C project response and functionality - Present the software team impact 5.5. Squeezing the Most from Toolbook and EMPOWER Despite the complexity and software constraints, a number of changes were made to the US version of EMPOWER to improve its performance, functionality, and relevance. Development team cohesion, resources, and discussions amongst individuals produced a cohesive vision about core software objectives and functionality, and a stability in other Chapter 5 - Processes in the Development of EMPOWER 125 dimensions required to reshape the software. A number of content changes increased the relevance of the software to mammography screening, user planning, and the Canadian and international setting 2 2 6 (Earl 1989; Cooper & Zmud 1990; Orlikowski & Robey 1991). These changes included spelling, case example descriptions, references, and language to more closely reflect Canadian mammography screening goals and terminology. Recent bibliographic references to applications of the planning-evaluation model were included. In addition, relevant mammography screening articles published since the production of the US version had been collected, but time and data input constraints prevented extensive updating within the software. Second, navigation in the US version was linear. To allow more random and "back and forth" access, individual module map pages were constructed, showing the structure of the module pages, and allowing direct access to these pages 227(Henderson & Kyng 1991; Landauer 1995). Changes in module one (situational analysis) to simplify data entry into a single "spreadsheet" screen have also dramatically reduced navigational complexity. A bookmark icon was also added to the toolbar as another aid to navigation and exploration without losing one's previous page. ' Changes to the bibliography achieved strategic purposes (Earl 1989). Changes to the bibliography and other content information also increased task-technology fit (Cooper & Zmud 1990). Institutional and "must have" changes included in the software for breast cancer and Canadian relevance (Orlikowski & Robey 1991). Direct access to pages provided direct user access, similar to Henderson & Kyng's (1991) discussion about tailorable and user designed systems. Direct access and navigation for easier and more productive work after initial entry, is stated in Landauer's (1995) user-centered design. Chapter 5 - Processes in the Development of EMPOWER 126 Third, a few of the outsourcing strategies increased the relevance and power of the program. For example, the programmer produced a linkage between a graphing code library and Toolbook, thus allowing graphing of project data 2 2 8(Attewell 1992; Orlikowski 1992b; Landauer 1995).229 In addition, summary reports can be loaded directly into a Windows-based word processor, MS Write, with minimal navigation by the user. Finally, most software and content bugs were removed, providing minimal authenticity 2 3 0 (Van De Ven 1986; Earl 1989; Orlikowski 1992b). Summary reports are printing most of the information recorded by the user, and additional suggestions are being provided in the reports. The following table summarizes the processes involved in this stage: 1 Learning and supply side barriers were partially overcome (Attewell 1992). An attempt to build tools that are normally used in epidemiological analysis, matched some premises of the technology with the decision environment (Orlikowski 1992b). Better design, and a focus on users' tasks and productivity increased task-technology fit (Landauer 1995). ' However, limits with data storage prevented us from extending the graphing into epidemiological data because data storage and updating was too slow. ' Minimal authenticity of the technology in use was achieved (Van De Ven 1986). Some strategic aspects and promises were reached (Earl 1989). Premises of the technology matched funding agency and development team expectations (Orlikowski 1992b). Chapter 5 - Processes in the Development of EMPOWER 127 Table 5-5: Processes in the "Squeezing the Most" Stage Description Theory Technological Level Time Type of Interaction Stakeholders from Context Content changes OI/ST Interface and resources July to Dec. 1995 Research and typing Content team Navigation EP Interface and movement Dec. 1995 to Jan. 1996 Design Structural and content teams Outsourcing successes EP/ST Interface and program Oct. to Dec. 1995 Design Structural team Bugs Removed EP/ST Interface and program engine Sep. 1995 to Mar. 1996 Search and fix Structural team 5.6. Visions of a New Software Constrained by Resources As a result of constraints within the US version, thoughts about developing EMPOWER from "scratch" and moving to a new software platform were discussed throughout the project. However, as implementation and usage of the software drew nearer, the pressure to continue modifying the old version increased. Late in December and early in January, the developer raised a number of concerns and criticisms of the US and modified versions of EMPOWER. He predicted that the software would be unusable as a planning tool in the communities 2 3 ^Cooper & Zmud 1990; Orlikowski 1992b). This prompted a more systematic redesign and rethinking of the EMPOWER software. In the design documents, the developer once again raised the idea of a "means-ends" chain, consistent with the planning-evaluation model itself, to allow full access to information, and to Despite changes to Empower, the technology was perceived as inappropriate for the task (Cooper & Zmud 1990). The education premise of the software was interfering with planning tasks (Orlikowski 1992b). Chapter 5 - Processes in the Development of EMPOWER 128 simplify data collection and programming 2 3 2(Earl 1989; Hammer & Champy 1993). This would allow adaptation and flexibility in the tool's usage 2 3 3(Boland 1987; Henderson & Kyng 1991). However, despite continued enthusiasm and some resources, the expectations of communities, users and funding agencies forced the team to continue improving the current version, at least to the point of making it workable for the field tests and for educational or training purposes ^ (K l ing & Scacchi 1982; Earl 1989; Orlikowski & Robey 1991). The following table summarizes the processes in this stage: Table 5-6: Processes in "Visions of a New EMPOWER" Stage Description Theory Technological Level and/or Characteristics Time Type of Interaction People Involved Developer EP/ST Functionality Dec. 1995 Surprise and Developer, points to to Jan. Difficulty project team major problems 1996 Alternative OI/EP Data design, Jan. to Enthusiasm Developer, design functionality Mar. 1996 and idea project team visions generation Constraints ST/EP Use of old Jan. to Pressure and Project team, keep us EMPOWER Apr. 1996 need to funding focused on satisfy agencies, users, old groups communities EMPOWER : A generic package was seen as strategic with current and new goals for assisting health promotion planners (Earl 1989). A rethinking of the concept of planning was beginning (Hammer & Champy 1993). ' In-formation in information systems design describes this process (Boland 1987). The generic version would be tailorable for many health areas through developer data, user data and means-ends design (Henderson & Kyng 1991). 1 Expectations from funding and community settings constrained work on the generic version (Kling & Scacchi 1982). Outside pressures and opportunities kept the team focused on fixing the old version (Earl 1989). The software needed to be viable for the planning setting given time, software and resource constraints (Orlikowski & Robey 1991). Chapter 5 - Processes in the Development of EMPOWER 129 5.7. Case Conclusion An analysis of the processes, process stages and the overall ISD process will provide some insights into the connection between the four process theories. 5.7.1. Process Analysis In terms of mutual exclusivity, the following table shows the process types in each process stage of EMPOWER's development: Table 5-7: Summary of Process Types in Process Stages Process Stage Number of Processes Process Types Project Emergence 6 EP, EP/OI, EP/OI, EP/ST, EP, OI/ST Getting Ready 5 EP/ST, EP, OI/TI/ST, EP/ST, ST/OI Pandora's Box Opens 7 EP, EP, EP, EP, EP, EP/ST, EP Squeezing the Most from EMPOWER and Toolbook 4 OI/ST, EP, EP/ST, EP/ST Visions of a New EMPOWER Constrained by Resources 3 EP/ST, OI/EP, ST/EP ISD Overall 25 T l 1,1 Shared Ol 7, 7 Shared EP 21,11 Shared ST 12,12 Shared The following table shows the ISD research areas were attached to the process stages (see table 2-6): Chapter 5 - Processes in the Development of EMPOWER 130 Table 5-8: ISD Research Categories within Process Stages Process Stage Process ISD Research Types Project Emergence 01 (3) Strategic information systems planning EP (5) Evolution of technology; Alternative views; Predicament of design Innovation ST (2) Adaptive structuration; Structural power Getting Ready T l (1) System 01 (2) Strategic information systems planning; Task technology fit EP (3) Alternative views; Predicament of design; Evolution of technology; Innovation ST (4) Adaptive structuration Pandora's Box Opens EP (7) Technology divergence (Uni); Alternative views Predicament of design; Evolution of technology Innovation ST (1) Adaptive structuration Squeezing the Most from EMPOWER 01 (1) Strategic information systems planning; Task technology fit EP (3) User involvement; Innovation ST (3) Adaptive structuration Visions of a New EMPOWER Constrained by Resources 01 (1) Strategic information systems planning; Task technology fit EP (3) Technology divergence (Uni); User involvement ST (2) Adaptive Structuration Keeping in mind the subjective selection of critical events and processes, the following observations can be stated. First, the emergent perspective is linked to twenty one of twenty five processes in the development of EMPOWER. However, unlike Case One, the appearance of this emergence was not from external groups or internal politics, but from the complexity of redeveloping the US version, the many ideas and visions of the software, and the development team's expertise and interactions. Second, social technology and organizational imperatives were used to describe twelve and seven of the twenty five Chapter 5-Processes in the Development of EMPOWER 131 processes respectively, but all of these processes were also described by another type; usually the emergent perspective. Social technology assisted in describing many of the unpleasant and unexpected constraints and learning of the US version. In addition, social technology provides insights into the team's continued revision of the US version. External pressure from groups expecting the software forced the continuation. Finally, the technological imperative participated in describing only one process. Examining special case and equal validity explanations, the following table summarizes the shared processes: Table 5-9: Examination of Shared Processes Process Total Shared* with T l with Ol with EP with ST T l 1 - 1 0 1 01 7 1 - 3 4 EP 11 0 3 - 8 ST 12 1 4 8 -* Note: that the "total shared" number is one less than the sum in the T l , 01, and ST rows because of a triple-coded process. Al l of the processes described with an organizational imperatives were also described with either social technology or the emergent perspective, indicating that strategy is most likely formulated within a set of constraints and/or opportunities presented by the context. These constraints and opportunities included the many visions and ideas, and the inability to fully understand and change the US software. The eight processes shared between social technology and the emergent perspective may indicate a "fine line" between the two theories. Emergence was either a developer response to complexity and constraints (social technology), or an emergent shock that was Chapter 5 - Processes in the Development of EMPOWER incorporated into later stages of development. Examining association between process types over time, the following summarizes the "following" patterns: Table 5-10: Number of Times a Process Type was Followed by Another Type Process Total byTI by OI byEP by ST TI 2 0 0 1 1 OI 12 0 1 7 4 EP 34 1 7 16 10 ST 17 0 2 10 5 The next table shows the likelihood of a series of processes with one type being terminated by one or more other process types: Table 5-11: Number of Times a Series of One Type was Terminated by Another Type Process Total byTI by OI byEP by ST TI 2 - 0 1 1 OI 10 0 - 6 4 EP 9 1 4 - 4 ST 7 0 1 6 -Similar to case one, a process described by an emergent perspective was followed by another process described by an emergent perspective in 16 of 34 "followings". This repetitive pattern did not appear with the other three theories. This may suggest that once an emergent perspective appeared, additional emergent processes, involving shocks and learning, followed. Examining the "termination" data, a series of emergent processes were terminated equally by organizational imperatives and social technology processes. Emergence and social technology processes equally terminated organizational imperatives. On the other hand, social technology processes were overwhelming terminated by emergent processes (six of seven Chapter 5 - Processes in the Development of EMPOWER 133 times). It appears that processes described with a social technology perspectives rarely led to new processes described with an organizational imperative, while organizational imperatives and emergent processes led frequently to processes described by social technology, emergent or organizational imperatives. The story-line supports these findings. Beginning with emergent opportunities and the combining of individual interests, the project settled into organizational imperatives and social technological responses to those imperatives. Shocks from the environment and uncertainty around the software, however, hit the project during the middle of development. The group responded with new imperatives and/or incorporated new constraints and opportunities into design. 5.7.2. Information System Development The ISD process overall is best described as emergent. Although the goal and specific means of producing the Canadian and international version of EMPOWER were driven by top-down plans, the problems with the US version, exploration, learning, testing, and numerous development ideas separated initial plans from the final outcome. The result was an extended educational version of the software, instead of a complete planning tool. Visions of a new and improved EMPOWER, using "means-ends" analysis and a new software platform, were constrained by resources. Chapter 6: Conclusions and Integration 134 6. Comparison and Integration 6.1. Introduction Information systems development (ISD) involves a series of interactions or "processes" between technology and context over time. Each ISD project appears unique, given the different contexts, starting technologies, histories, processes and final technologies. However, the theoretical categorizing of critical technology-context processes allows comparison. Chapter 6 compares and contrasts the two cases to reveal cross-case conclusions about technology-context processes. Important in this discussion are the stages and dimensions of stakeholders involved in ISD, 2 3 5 the four process theories and the ISD research categories,236 the technological levels involved in a process, and the reconciliation approaches.237 The next four sections examine each of the four process theories across the cases. The final section integrates the four theories into a theoretical model. 6.2. Technological Imperative To recall the definition, the technological imperative (Tl) process theory dictates that technology impacts organization and context in a unidirectional manner. Developers have ' Stages include initiation, adoption, adaptation, acceptance, routinization, and infusion. Dimensions include technology, users, tasks, organization, developers and suppliers, and environment. ' The process theories include the technological imperative, organizational imperative, emergent perspective, and social technology. The ISD research categories, for example, included technology and systems for the technological imperative. See table 2-6 for a complete listing. Methods of reconciling these fours views include mutual exclusion, special case, equal validity, and association. Chapter 6: Conclusions and Integration 135 little role in shaping or diffusing this technology, and users "adopt" and use the technology in a predictable manner. The following table summarizes the findings from both cases: Table 6-1: Technological Imperative Summary from Case One and Case Two Case Data Shared with:* Followed by: Termin-ated by: Techno-logy Level Stake-holders 1 3 of 43 3 Shared OI 2 EP 1 ST 0 TI 1 OI 0 EP 3 ST 1 OI 0 EP 2 ST 1 Al l levels Developer, funding agencies, coordina-tor 2 1 of 25 1 Shared OI 1 EP 0 ST 1 TI 0 OI 0 EP 1 ST 1 OI 0 EP 1 ST 1 Infra-structure Developer, US team, US com-pany, U B C project team Case One TI Literature: Technology and Systems Case Two TI Literature: Systems TI - Technological Imperative; OI - Organizational Imperative; EP - Emergent Perspective; ST - Social Technology * - Note: The "shared with" number may be greater than the "data" column because of triple coded in a processes. Little evidence supports a mutual exclusion of the technological imperative in explaining the data. The technological imperative participated in describing only four of the sixty eight critical processes in both cases.238 Three appeared in the SoftHeart case, and one in the Empower case. There are two explanations why TI explained was not used often to describe the critical processes in the two case studies. First, longitudinal and historical analysis showed that many apparent technological imperatives, including EasySys and the US version of Assuming each process represents an equal proportion of the data. Chapter 6: Conclusions and Integration 136 EMPOWER, were really emergent shocks or social technological constraints on the developing systems. For example, in Case One, the coordinator's requirement to create an interface in SoftHeart resembling EasySys was an attempt to keep intruders away from the software and her work. Second, technology may also be more influenced by context during ISD than later stages of diffusion. For example, in Case One, the continuous changes in functionality, interface design, and database design demonstrate technology's subservience to context in both clinics. Possibly as the software is implemented and used, a technological imperative will 239 ' appear. Examining equal validity and special case patterns, TFs "sharing" with other process theories show three of the five processes were shared with an organizational imperative (OI), indicating a link between rational planning and technology impact. This TI-OI link is common in the strategic planning and structured information systems design literature (Kling & Scacchi 1982; McFarlan 1984; Earl 1989; Davenport & Short 1990). The two may be associated as either a two-step process, or have equal validity in explaining the same process. Technological imperatives appeared to be linked with an organizational imperative when the benefits of using the technology are perceived by many individuals (Earl 1989).240 For example, in Case One, the use of computers was reinforced by the perceived successful use of electronic patient records in other hospitals. ' However, initial data on early implementation in both case studies show that the software has an incomplete and sometimes unplanned effect on context. For example, the use of Empower in the community has produced a limited focus on quality of life and health at planning meetings, and SoftHeart's deployment and usage in the clinics has resulted in a number of surprises. ' See Landauer (1995) for a challenge to this view, showing that increases in IT per person is correlated with flat or decreasing productivity. Chapter 6: Conclusions and Integration 137 The stakeholders involved in the initiation of T l processes were mainly developers and suppliers of technology, and not organizational users and "management".241 Most of these developer-derived technological imperatives were based on assumptions which were criticized by other stakeholders.242 Technological imperatives also included "legacy systems" that affected development (i.e. EasySys and the US version of Empower). "Legacy systems" imposed constraints and opportunities on design because the system is imbedded in the organization, and proved to be useful for the new designs (Petroski 1994). In case one, EasySys' data has formed the basis of SoftHeart's data. Without this data, SoftHeart would have been an empty shell with little data to support initial adoption and use. In case two, the US version of Empower dramatically influenced programming and design. Limited time and choice were key processes leading to technological imperatives (Thomas 1994). This suggests that T l may be a special case of social technology when the technological constraints are strict, time is limited, and/or the developer chooses to learn and take advantage of the legacy system (Orlikowski & Robey 1992). The levels of technology correlated with a technological imperative ranged from system ideas to interface details. In case one, initial ideas of the developers and initiators of technology were technological imperatives. The redevelopment of EasySys' interface was also a technological imperative, and was initially agreeable to the developer because the coordinator appeared to know her work and the computing tools required to complete that Users in both case studies were unaware and uninvolved during early conception. 1 The human-computer interaction and framing literature infrequently discuss the boundaries of their findings. Regardless, the developer and his thesis committee also extended the findings into more complex outcomes such as patient health. Chapter 6: Conclusions and Integration 138 work. Further discussions with the coordinator, however, resulted in "requirements" to mimic keystroke-for-keystroke every interface characteristic in EasySys, uncovered political activity to block SoftHeart's influence on EasySys, and revealed the coordinator's intentions to stop the project. Examining inter-process associations, most processes described as technological imperatives were shortly followed by or the result of processes described as emergent. For example, early funding proposals, based on technological imperative visions of multimedia education and information presentation affecting patient outcomes, were rejected by unconvinced health groups. As another example of TTs association with the emergent perspective, the developer's threat to quit the project prompted the Clinic One to fire the coordinator. This released the project from the EasySys technological imperative, and launched an emergent and chaotic phase of development. 6.3. Organizational Imperative The organizational imperative (OI) theory mandates that organizations use a rational planning process to choose and/or develop technologies that will meet their strategic objectives. Developers implement technology identified by top management or users, and users adopt the technology as planned. The following table summarizes the findings from both cases: Chapter 6: Conclusions and Integration 139 Table 6-2: Organizational Imperative Summary from Case One and Case Two Case Data Shared Followed Termin- Techno- Stake-with: * by: ated by: logy holders Level 1 15 of 43 T l 2 T l 2 T l 1 Al l levels Al l 13 EP 1 01 7 EP 5 stakehold-Shared ST 5 EP 8 ST 2 ers ST 4 2 7 of 25 T l 1 T l 0 T l 0 Al l levels Al l 7 Shared EP 3 01 1 EP 6 stakehold-ST 4 EP 7 ST 4 ers ST 4 Case One Ol Literature: Strategic information systems planning; User involvement; Task technology fit _ _ Case Two Ol Literature: Strategic information systems planning; Task technology fit T l - Technological Imperative; 01 - Organizational Imperative; EP - Emergent Perspective; ST - Social Technology * - Note: The "shared with" number may be greater than the "data" column because of triple coded in a processes. Little evidence supports a mutual exclusion of the organizational imperative in describing the processes. In total, the organizational imperative participated in explaining twenty two of the sixty eight critical processes in both cases, and exclusively described only two critical processes. Fifteen participated and two exclusively described processes in Case One, and seven participated and none exclusively described processes in Case Two. The developer-led nature of both projects weakened an organizational imperative description of the data. The early disinterest and disregard in the SoftHeart project amongst clinic directors and personnel weakened an organizational imperative description of this stage. In fact, most of the 'strategic' considerations of the software by "management" have appeared near the end of the development phase, as the two clinics understood SoftHeart and its potential importance to future operations (Thomas 1994). In both cases, the systems were Chapter 6: Conclusions and Integration 140 "pushed" by developers rather than "pulled" by users and management (Attewell 1992; Petroski 1994). Now that the software has proved it can work, most of the clinic personnel are discussing the future of SoftHeart for increasing the profile of the clinic to hospital, government, and research groups (Petroski 1994). Examining equal validity and special case patterns, OI's "sharing" of process descriptions with other process types demonstrated that strategic and IT decisions could not be divorced from the day-to-day realities of organizational life and computing technology.243 Twelve of thirteen processes were shared with the emergent perspective and social technology in Case One, and seven of seven in Case Two. There are a number of descriptive examples of OI's connection with EP and ST. Case One's user-centered design led to many visions of the organization, the work, and the role of IT. Organizational imperatives incorporated new constraints and ideas to ensure the software's relevance to the stakeholders.244 In case two, the "make" vs. "buy" decision was best described as an organizational imperative constrained by money, time, and uncertainty. Examining the level of technology and time, the data demonstrated that organizational imperatives described processes affecting all levels of technology, but their effects are short-lived as emergent learning and shocks shook the project. In addition, the stakeholders involved in strategic direction included only the developers during early stages, thus This contradicts the normative separation between design and implementation advocated by some design philosophies. ' Other reasons for the weak organizational imperatives may be the complexity of the context in Case One, and the relative novelty of the software in Case Two. Also, the developer's inexperience with the clinical setting, electronic patient records and networked software may have prevented the project from developing top-down approaches to development. However, by claiming that the experience of the developer affects strategic planning implies that the emergent perspective accurately explains the process. Chapter 6: Conclusions and Integration 141 weakening the use of 01 descriptions of the processes that focus on top-down strategic planning. The organizational imperative literature attached to technology-context processes included strategic information systems planning and task-technology fit in both cases, and user involvement in Case One. This reflected the different approaches to development in the cases. Case One had extensive user involvement, and Case Two had very little. Some of the user involvement in Case One was categorized as an organizational imperative because the involvement was an attempt to build an integrated understanding of the organizational goals and information system. Examining inter-process associations also demonstrated how context influenced organizational imperative planning. Most organizational imperatives were shortly followed by processes that were categorized as emergent perspectives or social technology. In Case One, thirteen of twenty two "followings" were by emergent or social technology processes, and eight of nine 01 "terminations" were by emergent and/or social technology processes. In Case Two, eleven of twelve "followings" were emergent or social technology, and all ten "terminations" were by the emergent or social technology perspectives. Both cases provide tentative conclusions about the 01 and EP/ST link. In Case One, periods of calm and agreement between various groups resulted in a number of initiatives driven by rational planning and development. For example, a developer-led strategic plan created the original vision of SoftHeart: to improve the communication between patient and provider to improve patient health. The specific "means" for achieving that end, however, Chapter 6: Conclusions and Integration 142 changed rapidly with user involvement, environmental shocks, the removal of the coordinator, and the developer's changed understanding of the environment.245 In addition, user involvement from clinic personnel directed the project toward new "ends", including quality of working life (Bostrom & Heinan 1977). The developer rationalized these administrative and research goals as contributing to patient health, although more indirectly than the clinical presentation of information during provider/patient discussion.246 The interaction between the core concept and IS means was bi-directional. Case Two also illustrated that the original strategic plan was soon overridden by technological struggles with the US version of the software and external group pressure to produce a product. The project started with a general goal of producing a tool to assist the planning of breast cancer interventions. However, the project was driven by problems in the US version of the software, because the project team had assumed that most of the strategic planning and design were embodied within the software. Further exploration revealed these assumptions incorrect, but time and money were limited for redeveloping EMPOWER with a new software platform. ' Even the use of computing technology was dropped in one proposal, in order to address the cost issues of computing equipment raised by the health groups. ' Presently, computers have not been installed in the examination rooms to test the usage of computers during provider-patient discussions. Physicians and clinic personnel feel the technology will disrupt their discussion with the patient. This has occurred despite earlier agreements and discussions project establishing the clinicians' interest in using computers in the examination rooms. Chapter 6: Conclusions and Integration 143 6.4. Emergent Perspective The emergent perspective theory (Markus & Robey 1988) states that a complex interaction occurs between context and technology over time. In its stronger form, EP claims that technology and context are inseparable. Every context and technological appropriation and adaptation is unique. Developers' and users' ideas and visions determine the method of selection and criteria, the choices, and the implementation approaches (Thomas 1994). The following table summarizes the findings from both cases: Table 6-3: Emergent Perspective Summary from Case One and Case Two Case Data Shared Followed Termin- Techno- Stake-with:* by: ated by: logy holders Level 1 31 of 43 TI 1 TI 1 TI 1 Al l levels Developer 15 OI 7 OI 11 OI 5 and new Shared ST 8 EP 23 ST 4 stakehold-ST 12 ers 2 21 of 25 TI 0 TI 1 TI 1 Al l levels Al l 11 OI 3 OI 7 OI 4 stakehold-Shared ST 8 EP 16 ST 4 ers ST 10 Case One EP Literature: Technology divergence; Designer's views; Predicament of Design; Evolution of technology; User involvement; Innovation Case Two EP Literature: Technology divergence; Alternative views; Evolution of technology; Innovation TI - Technological Imperative; OI - Organizational Imperative; EP - Emergent Perspective; ST - Social Technology * - Note: The "shared with" number may be greater than the "data" column because of triple coded in a processes. Evidence does support EP's value in describing the data. The emergent perspective described fifty two of the sixty eight critical processes in both cases, and exclusively described Chapter 6: Conclusions and Integration 144 twenty six processes. In Case One, thirty one participated and sixteen exclusively described critical processes. In Case Two, twenty one participated and ten exclusively described critical processes. Examining the "shared" processes revealed equal validity and special case patterns with other process theories. EP was closely allied with the organizational imperative and social technology perspective in describing processes. Eight of fifteen shared processes in Case One, and eight of eleven shared processes in Case Two were shared with social technology. Seven of fifteen in Case One, and three of eleven processes were shared with the organizational imperative. The linkage of the emergent perspective with social technology and organizational imperatives is also supported by inter-process examination of the "termination" data, with nine of ten Case One and eight of nine Case Two terminations resulting from organization imperatives or social technology. These data suggests a descriptive fine line between the emergent perspective, the social technological perspective, and the organizational imperative. Emergence may be a "general case" of social technology where the boundaries around either organization or technology are weakly defined or changing. For example, once new stakeholders and knowledge of these stakeholders and there needs were identified and incorporated in the software's design, a period of social technology appeared before new shocks and discoveries sent the project into emergence. Although the theoretical patterns are similar between the two cases, the emergent literature attached to the two cases differed. Case One included designer views, predicament Chapter 6: Conclusions and Integration 145 of design, and political and radical "bottom-up" user involvement. Case Two included alternative views and the evolution of technology. These differences are explained by different approaches to design, including the complex and fragmented setting of Case One, the exclusive control of development by the developer, and the extensive user involvement during design. Reasons for the descriptive power of emergence with the critical technology-context processes are numerous. First, both projects emerged from an intersection of various individuals with different interests and expertise. Projects arose more from the wants and desires of developers than from organizational need. Experience in other fields of technological innovation suggests that supply-led development is fairly common, emergent, and based more on supplier desire and intuition than obvious societal need (Petroski 1994; Thomas 1994). In Case One, the developer's database background and work experience provided a "subsidy" to the Case One's initiation and creation, and Case Two's development (King et al., 1994). The developer's lack of experience with clinic settings required him to use various techniques and perspectives to develop an IS intervention (Klein & Lyytinen 1985; Boland 1987). Certainly, the developer's learning, involvement, and interpretation of the setting and its potential effect on the project influenced development (Attewell 1992). The onus was also on the developer to translate user comments into the technology. This process may be called an "inferential leap" (Turner 1987), because the exact reasoning and choice of interface and database design is difficult to describe, and based on compromise between competing objectives (Petroski 1994). The result of this "leap" is tested back in the environment through prototype demonstration, that revealed and uncovered new requirements Chapter 6: Conclusions and Integration 146 and opportunities, and ultimately sent development into another round of emergence (Schon 1983). Second, environmental shocks, learning, discussion with new users, limited time and money, and prototype creation and demonstration based on user discussions, obscured the connection between strategy and technology. For example, Case One began in July 1992 as an experiment to test the effects of multimedia information on patient outcomes. It ended with the development of an electronic patient record that is currently implemented in clerical and research offices. Similarly, the EMPOWER project also experienced emergence. Many of the ideas and suggestions were not reflected in the software's design because the development team was unable to develop new functionality in the US version.2 4 7 Third, both cases demonstrated that the 'ends' of the system are difficult to plan in advance. With over 15 users in Case One with various degrees of experience and professional background, SoftHeart was taken in many directions. The EMPOWER project faced emergence of a different kind, where the ends of the project were changing rapidly based on examination of the program, and as the 'wish list' continued to grow. In addition, findings from the field were to inform revision of the software in accordance with the funding agreement. Fourth, technology can unexpectedly influence unplanned tasks and environmental dimensions. Many of these effects cannot be determined in advance.248 These unexpected Examples include the graphing of epidemiological data and the construction of an improved database engine using the Database connection to fix the contact manager and other data intensive functions. 1 The literature on user centered design, development, and deployment states that the best test of a software product is a test with potential users. Logic, deduction, and intuition are not enough. Chapter 6: Conclusions and Integration 147 influences can produce new opportunities as well as new constraints that must be understood and worked into software design. The best approach to development in this situation is prototyping.249 For example, case one required detailed prototyping and understanding and testing of SoftHeart to determine how this "intrusion" would affect data entry requirements in the front office, physician time in searching for patient names during a consultation, report delivery if reports were printed on a network printer, information "dependency" during clinic visits i f the server crashed, and provider discussion with a patient using a computer. The lack of early prototyping and testing in Case Two may have been partially responsible for some of its usage problems.250 Finally, unexpected technological constraints in both cases affected interface, functionality, and strategic direction. In Case One, the struggle learning the Foxpro language, and the requirement to develop an interface similar to EasySys, produced emergence. In case two, the struggle with the US version prevented us from thoroughly addressing the original goal of fully supporting the planning of mammography campaigns. 6.5. Social Technology The social technology (ST) theory suggests a "soft-line determinism" between technology and organizational structure. Equal focus is provided to both the constraining and enabling features of a technology, and the organization. Developers build technology within 1 Only extensive experience with the setting and the technology can allow IS plarming using a top-down approach. This experience depends not so much on the age of the technology, but the experience of users, developers, and suppliers involved in the project. But even then, each setting is complex, requiring testing and feedback to build a local "theory" of the setting. Thus, experience can only serve as an analogue for future development projects. 1 What has been developed might be viewed as a prototype for field-testing. Chapter 6: Conclusions and Integration 148 constraints and opportunities. Users "adapt" the technology within technological, environmental, and user constraints. Table 6-4: Social Technology Summary from Case One and Case Two Case Data Shared with:* Followed by: Termin-ated by: Techno-logy Level Stake-holders 1 16 of 43 12 Shared TI 0 OI 5 EP 8 TI 1 OI 5 EP 9 ST 7 TI 1 OI 3 EP 5 Al l levels Developer and new stakehold-ers 2 12 of 25 12 Shared TI 1 OI 4 EP 8 TI 0 OI 2 EP 10 ST 5 TI 0 OI 1 EP 6 Al l levels Al l stakehold-ers Case One ST Literature: Adaptive structuration; Structural power Case Two ST Literature: Adaptive structuration TI - Technological Imperative; OI - Organizational Imperative; EP - Emergent Perspective; ST - Social Technology * - Note: The "shared with" number may be greater than the "data" column because of triple coded in a processes. Little evidence supports a mutual exclusive ability of social technology in describing critical processes. In total, the social technology perspective participated in describing twenty eight of the sixty eight processes, and exclusively described four processes. In Case One, sixteen participated and four exclusively explained processes. In Case Two, twelve participated and none exclusively explained processes. Examining the shared processes, ST is closely allied with the organizational imperative and emergent perspectives. The "followings" and "terminations" also illustrated a connection between social technology and the emergent perspective. In terms of time and association, the social technology perspective, in combination with the emergent perspective, described Chapter 6: Conclusions and Integration 149 certain processes such as idea and software adaptation to external demands and shocks. Social technology also helped in understanding the learning of the software required in both case studies, and the opportunities of expanding EasySys in Case One. Thus, both cases exhibited social technology perspectives after emergent processes had settled down, and the development team was able to incorporate these constraints and opportunities into the project. This implies a possible close relationship between social technology and the emergent perspective. There are a number of reasons why the social technology perspective "shared" in describing many critical processes or was associated with the organizational imperative and emergent perspective. First, technological and resource constraints and opportunities appeared to affect the vision and implementation of the information system (Argyris, Putnam, & Smith 1985). It therefore affected any strategic planning and organizational imperatives. For example, faced with little funding and resource support to support the SoftHeart project in May of 1995, the developer decided to use some of his own funding and programming skills to produce an extension to EasySys in order to build graphical and risk reports for patients and physicians.251 Second, Case One also demonstrated that people are the builders and enforcers of constraints and opportunities, and that the loss of these individuals produces emergence or imperatives. For example, in Case One, many of the constraints by the first coordinator That decision has led me to at least one year of design and programming involvement (much of it full time) in SoftHeart's development. Chapter 6: Conclusions and Integration 150 appeared to be solid and permanent. However, her departure released many of these constraints, producing a period of emergence. Finally, as mentioned in the technological imperative section, both cases were strongly influenced by legacy systems. EasySys provided many constraints for design in early stages. Initially, this constraint was accepted by the developer because the program captured valuable data that could be reported and presented effectively. In addition, with the developer's limited clinical experience, the program allowed him to learn a great deal about the types of data and the form of that data important to the clinic. Despite the firing of the coordinator, EasySys influenced the database structure and look-and-feel of SoftHeart. The US version of EMPOWER, a legacy system, and the environment around the development of EMPOWER also enabled and constrained development. The development team's choice to enhance the US version, in order to build upon what the development team considered to be a stable product, introduced a set of known and unknown constraints on development. Initial results of software testing in the communities indicated that the software did not meet the planning needs of the communities, prompting discussions of building EMPOWER "from scratch" using a different software platform. However, the lack of time and money, the push to produce a Canadianized product to satisfy cooperating agencies, users anticipating the new software, and two waiting communities wishing to test the software, prevented the move to a new software platform. Most technological levels were subjected to social technology, especially the functionality and infrastructure. Database and multimedia applications are supported by a large supplier and expertise base that is well established in the microcomputer industry. In Chapter 6: Conclusions and Integration 151 case one, the program and data structure were constrained by industry conventions and ideas.252 In addition, the interface characteristics and input approaches in both cases were constrained and enabled by the Windows environment.253 Stakeholders most involved in social technology processes were the developers, suppliers of software and IT, the thesis committee, and funding agencies. Each provided certain enabling and/or constraining influences on the options available. First, the developer's background and experience both enabled and constrained both projects. Second, suppliers of software enabled and constrained development, and explained the constraints of legacy systems software. Third, the developer's committee provided access to Clinic One, alternative ideas, avenues of development, and knowledge of the IS and health fields. Finally, funding agency ideas and responses also altered the direction of Case One and Two. In addition to the adaptive structuration literature found in both cases, Case One included some structural power literature to help understand and describe critical processes. The clinical setting produced somewhat predictable patterns in personnel responses to IT ideas. For example, the reshaping of SoftHeart toward research and administration and away from the original goals of direct patient care, is the result of structural and funding characteristics in both clinics. Important in most social technology processes was uncertain and imperfect choice. Choices constrained and enabled technological development in Case One (Argyris, Putnam, & The "medical record" and its data structure and data elements have reached certain standards. ' These conventions are themselves the result of emergent processes in the computing industry. For example, the Windows interface is based on an emergent history of research done at Xerox Pare that was eventually incorporated into the Macintosh operating system, which then spread through Microsoft's growing dominance into IBM PCs. Chapter 6: Conclusions and Integration 152 Smith 1985; Orlikowski & Robey 1991; Thomas 1994). Choosing Clinic One as a site enabled certain types of IS development but constrained others. Choosing Windows Foxpro versus DOS Foxpro allowed the developer to tap the many windows resources and look-and-feel, but reduced the processing speed and introduced some common Windows software bugs into the program.254 Many of these choices were made without realizing the full set of constraints or enablers on future development 2 5 5 In case two, many of the problems with the US version were not fully discovered until later in the project. If some choice constrained, other choices weakened and reduced a constraint. For example, to deal with the slow graphing problem in Case One, the developer purchased a graphics package that linked directly into Foxpro as a library of commands. As another example, to address the criticisms of computer cost in the first proposals, the developer changed future proposals to include only a single computer to print enhanced reports for providers and patients. Nevertheless, constraints were often beneficial if they guided and protected the project from over-expansion and streamlined development. Constraints were also good if the software had already been constructed considering these constraints, but a problem if new constraints forced redevelopment. For example, too little constraint in the SoftHeart project led the project in many directions after the coordinator was fired. The most famous is the General Fault Protection error (GFP) resulting from Windows poor memory management capabilities. ' I wonder if I would have known the problems and constraints I would face during SoftHeart's development before beginning, whether I would have even started. Chapter 6: Conclusions and Integration 153 In conclusion, social technology appears to be associated and possibly a special case of emergence where the boundaries around either organization or technology are more strongly defined and stable. These constraints are incorporated into design and/or changed by new choices or environmental shocks. 6.6. Integrating the Four Theories The previous discussion has revealed some tentative associations and patterns between the four process theories. This section introduces a first attempt at an integrated model of context and technology interaction. Two contextual qualities appear to "correlate" with the four process theories, given the level of technology, task(s), and stakeholders involved. The first quality is the agreement about the use of technology for a task amongst those stakeholders who are essential to the technology's operation. Agreement on the use of a specific technology level or function can be classified as either integrated and clear or diverse and vague. The second contextual quality is the potential adaptation of the technology for use and development. Technological change may best be described as either nonadaptable or adaptable. In addition, the model attempts to include dynamics and change by showing technology being composed of several layers of technological levels attached to various tasks, and time as mixing and changing the stakeholders, tasks and technological levels considered. Time and technological levels provide a tentative but strong reason why emergence best explained the critical processes in both cases. The following figure summarizes the integration amongst the four perspectives: Chapter 6: Conclusions and Integration Figure 6-1: Integrated Model of Context and Technology Interaction 154 Technological Level or Part Stakeholders r f ™ ° 9 y Change: Nonadaptable Adaptable Task Agreement Amongst Stakeholders: Integrated and Clear Diverse and Vague Technological Imperative Sock Organizational Imperative i\ Tech Emergent Perspective (Case Two) nology Emergent Perspective (Case One) Level or Part Time As the figure suggests, technological imperatives appear when the technology or technological part for complex and multifaceted technology, is nonadaptable in terms of use and construction, and the stakeholders are integrated and clear about the use of that technology for a particular task. The organizational imperative implies context can adapt the technology through purchase or construction, and that stakeholders have clear and integrated ideas about the technology's use for a task. The social technology perspective straddles the two dimensions, suggesting that technology is somewhat adaptable, but boundaries limit this adaptation. In addition, agreement on the usage of the technology for the task is somewhat integrated and clear, but not entirely. Chapter 6: Conclusions and Integration 155 Finally, the emergent perspective appears whenever there are diverse and vague agreements about the use of the technology for a task. Diverse agreement and nonadaptable technology yields emergence; in some cases rejection, avoidance, or "work arounds".256 In addition, diverse and vague agreement between stakeholders and adaptable technology, is also emergent. In this case, these views may be potentially incorporated into the different parts or levels of the technology. In both cases, the result is that the technology's development and use is a complex interaction between the many stakeholders and the technology. Note that the conclusions about a process depend on the stakeholders, the part or level of technology, and the task being examined. For example, an organizational imperative may explain the use of database applications, but the interface characteristics may be explained by emergence. The reason is that although the use of databases may be integrated and clear, the design of the interface may reveal diverse and vague opinions. As an example of stakeholder agreement, a system that involves a single user will have more integrated and clear agreement than a system that involves many individuals from separate departments. The wider the technology and/or task, the more stakeholders will be involved in a process, and the greater the chances for disagreement. Processes create and integrate various old and new stakeholders with certain technological levels and tasks in a constant reassessment of their use and fit. Change is introduced over time through learning and environmental shocks when new stakeholders, new technology, new tasks, new ideas, new agreements or conflict, or all five are added to a ' The term "work arounds" describes the manual methods used around an information technology. In some cases, these work arounds may consume more time than if the entire process was done manually. Chapter 6: Conclusions and Integration 156 process. These processes will resemble one of the four process theories. Impact occurs when this mixing of old and new tasks, technologies, and stakeholders produces change. For example, EasySys represented a strong social technology and technological imperative before the developer of SoftHeart arrived. Despite disagreement about EasySys' use in clinic one, no one knew how to change the system, except for the coordinator and her programmer. The developer's involvement opened EasySys to modification, thus prompting conflict, and the eventual removal of the coordinator from the clinic. The result was an explosion in requirements as the diverse views expressed themselves into the requirements for the new software.257 From the case data and the integrated theoretical model, a major conclusion can be stated. Because most system development occurs in relatively complex settings using advanced IS and IT, requires significant development time, and will involve many diverse stakeholders, most system development projects will be marked by at least one emergent process. Complex settings imply many stakeholders with different goals and means for achieving those goals, and considerable uncertainty in developing technology compatible with these views. Both complex setting and technology implies that learning of the context will occur throughout development, often making previous plans and development work irrelevant. In addition, longer development times implies that new technology, individuals, or tasks will appear, making current technology and plans obsolete. Emergent shocks, such as the closing of Hospital One in Case One, are a higher likelihood in longer system development Only through efforts to achieve integrated views or to close the technology, did a more organizational and social technology perspectives appear. Chapter 6: Conclusions and Integration 157 projects, also making plans and development work irrelevant. As a result, a major shift in the project design to accommodate emergent shocks will result in emergence overall25* This claim is supported by comparing the initial plans to the final software product in both cases. Both cases and other cases of technological development support this hypothesis.259 6.7. Conclusions Processes in both case studies reveal a pattern among the four process theories. Chapter 6 has integrated the literature of chapter 2 with the data from chapter 4 and 5 to provide a theoretical discussion and integration. Data supporting each of the four process theories were discussed. Mutual exclusivity, equal validity, special case, and associations between the four processes were also discussed. Level of technology, dimensions, and time were explored to position and characterize the theories within the cases. The result was an integrated framework placing the four theories within two contextual "qualities": stakeholder agreement on the use of a technology for certain tasks (integrated/clear or diverse/vague) and technological change (nonadaptable or adaptable). Technological imperatives appear when stakeholder views are clear and integrated, and technological development or use is nonadaptable technology. Organizational imperatives arise when stakeholders have integrated and clear views, and technology is adaptable. Social technological processes appear when agreement is somewhat diverse and technology ' Technology-context interaction between these shocks may be best described as social technology or organizational imperatives. 1 Another more extreme example is the development of the automobile and the aircraft. The inventors of the combustion engine probably were not planning for car travel and air travel on such a massive scale, and the fuel production, road construction, pollution and other consequences that have accompanied these innovations. Chapter 6: Conclusions and Integration 158 somewhat adaptable. Finally, emergent processes emerge from diverse and vague agreement amongst stakeholders. If the technology is nonadaptable, then the system risks rejection, avoidance, or "work arounds". If the technology is adaptable, then the process will involve a complex and non-deterministic interplay between technology and context. Individual processes bring together old and new stakeholders, technologies, and tasks. A process takes on characteristics of one of the four theories, and the result of the process is impact: either the status quo or change. A major conclusion of the thesis is that complex settings, complex IS/IT, and increased development time will likely produce significant learning and/or contextual shocks during development, requiring a major modification of development plans. As a result, comparing initial plans to the final product, the overall information system development process will resemble the emergent perspective. Chapter 7: Contributions, Implications and Future Research 159 7. Implications and Future Research This study of technology-context processes during ISD suggests a number of contributions and implications for researchers and practitioners. This chapter describes these contributions and implications, the limitations of the study, and future research directions. 7.1. Contributions This thesis offers the following contributions to IS research and practice. First, a longitudinal study of the process of information systems development within two natural and complex settings has been conducted (Pettigrew 1979; Kling & Scacchi 1982; Das 1983; Pettigrew 1985; Vitalari 1985; Markus & Robey 1988; Barley 1990). As a result, the two case studies are "relevatory" cases (Yin 1994), examining the interaction between context and technology continuously during information system development. The thesis explored ISD in these settings over a significant time period; 4 years in Case One and 1 year in Case Two. This provides a historical analysis of ISD, a rich description of the people involved, and an , understanding of their chronological influence on design. Second, four theories of technology-context interaction were extracted from the IS and technology literature to classify a substantial amount of ISD research (Kling 1980; Kling & Scacchi 1982; Markus 1983; Van De Ven 1986; Markus & Robey 1988; Hirschheim & Klein 1989; Burton 1992; DeSanctis & Poole 1994; Myers 1994b; Thomas 1994). Technological imperative, organizational imperative, social technology, and the emergent perspective provided comprehensive coverage of the possible interactions between people and Chapter 7: Contributions, Implications and Future Research 160 technology. These theories provide four insightful "lenses" for interpreting the ISD research, and a rich theoretical and empirical background for interpreting ISD cases. Third, these four process theories are integrated into a single theoretical model through two contextual "qualities": stakeholder agreement about the technology's use toward a task, and the adaptability of using and developing the technology (see Figure 6.1). Change was explained by the linking of old and new stakeholders, technologies, tasks, ideas, and environmental shocks. Fourth, as a contribution to action research, the thesis portrayed the developer's role and influence on context and technology during ISD. It also demonstrated the use of newer methods for action research during ISD, such as hermeneutics, phenomenology, and critical theory (Susman & Evered 1978; Boland 1985, Lyytinen & Klein 1985; Boland 1987, 1990; Orlikowski & Baroudi 1991; Myers 1994b). In doing this, the thesis also contributes to a growing field of research joining research and practice in a constructive dialogue. Fifth, the research provided a method of identifying processes affecting ISD, and the linking of these "situated" processes to the IS research. Using "technology level", time, and stakeholders involved, processes were uncovered, examined and linked to the ISD literature. These process characteristics were then used to reach conclusions about the process stage and the overall ISD process. The result is a useful way of drawing theory to guide practice, and practice to guide theory. Sixth, extensive reading of the epidemiology and health promotion literature has identified areas where IT can support interventions for improving health. This will assist in building IT and IS that address patient and population health. Chapter 7: Contributions, Implications and Future Research 161 Seventh, the thesis work has transmitted two new "packages" (Kling 1980) into two settings. SoftHeart has begun early implementation in the two clinics, and is reaching a stable state of development and use. EMPOWER is providing the development team with information about its capabilities in two Canadian communities, and is signaling redesign areas that are to be incorporated into the current or future versions. Finally, both cases have produced a rich set of data for future research. Diary notes from both cases exceeded 800 pages. Documentation of design notes, database schemas, reports, and meeting minutes exceeded 500 pages. Typewritten summaries of the diaries and documentation summaries produced 189 single-spaced pages of data for the SoftHeart case, and 57 pages for the Empower project. In addition, there are 15 prototypes of SoftHeart, and weekly backups of EMPOWER during the course of development. These data are resources for future research, including evolutionary design (Petroski 1994), testing alternative theoretical frameworks, and conducting variance research (Sabherwal & Robey 1995). 7.2. Implications Many of the implications for research and practice point to a tension between two opposing forces during ISD and implementation that need to be considered and balanced. First, emergence is a crucial component of system design. Complex contexts of development in both cases involved many individuals, groups, technological suppliers, developers, and technological options influencing design and development. Along with each individual and/or group came a series of different languages, goals, and technological means to achieving those goals. As a result, key decisions were not technical but social, especially the Chapter 7: Contributions, Implications and Future Research 162 decisions about what the technology would do and contain (Argyris, Putnam & Smith 1985). Emergent learning and shocks caused overall emergence as the developer or development team adapted the software. It is perhaps initially distressing to admit that emergence is an important part of software development projects. However, emergence and an awareness and readiness for emergence was a requirement of good design.260 It is important for designers to alter plans, and design and build software that addresses learning, shocks and events. An understanding of emergence is essential for managing user expectations. In addition, the appearance of project emergence is a sign of innovation and adaptability, as unexpected tasks, technology, and stakeholders are brought together during development. As a result of emergence, there is an inherent tension between the seizing of new opportunities and continuing with detailed plans. The solution is a balance between adaptation and restriction of further design changes. If a new opportunity is seized, the developer must also pause and rethink the basic organization and design of the software, to ensure new requirements are consistently applied to reduce program complexity. Second and related to the first implication, organizational and technological imperatives are difficult to achieve. IS's ability to be interpreted differently by different groups and the onus on the developers of technology to meet stakeholder interests weakens these two imperatives. More prevalent in the cases are social technological processes that 1 In Case One, the developer's original technical perspective on design made emergent shocks and revised learning difficult to absorb into the project. Chapter 7: Contributions, Implications and Future Research 163 appear before and after emergent processes, providing a set of learned constraints and opportunities for development. Third and related to the cause of emergence, both ISD projects emerged from suppliers of technology. Developer visions and personality, design approaches, diverse personal views, inferential leaps from user comments to design, learning, system redesign and rework, and contextual shocks significantly affected the course of development. Other research points to supply-led innovation appearing as an upstart and challenge to inertia and busy demands in user organizations. This implies that a significant portion of ISD is driven by developers, not upper management who direct developers to implement requirements.261 As a result, software development places the onus on the developers to prove the worth of and to take responsibility for IS development. Fourth and related to the cause of emergence, is the involvement of stakeholders in producing and being influenced by these emergent processes. The outcome of involvement will depend on the goals of various stakeholders, the technology, the task, and the characteristics of involvement. Especially important is the history of various groups and legacy systems.262 Choosing a "bottom-up" organizational imperative approach by involving users to achieve a consensus around the goals and technological means, or an emergent perspective by involving users and recognizing political opposition and "accommodation", depends on this context. As a result, it is unclear whether system development projects This is the "hammer finding the nail" issue, where those trained in a certain field use their skills to craft new solutions to old and new problems. 1 For example, the coordinator in Case One, despite her early involvement in the redesign, later blocked and discouraged SoftHeart's development. She might have felt the project was going to reintroduce the research group into controlling her work. As a result, user involvement led to increased conflict and near failure of the project. Chapter 7: Contributions, Implications and Future Research 164 should: 1) build technology to accommodate different views (Hirschheim & Klein 1989; Checkland & Scholes 1990); 2) market technology to convince diverse views that different or similar parts of the technology can serve their needs; 3) side with one powerful party at the expense of other groups (Hirschheim & Klein 1989); and/or 4) move people to agreement through negotiation and integration. Deciding amongst these various competing approaches will depend on learning, the development stage, the political strength and views of various groups, the understanding of stakeholder views, and the adaptability of the software for development and use (Dutton 1981; Markus 1981; Markus 1983; Mohr 1987). What is clear is that the political and power structures in an organization and its connection with user involvement, must be consciously "managed" and assessed during system development. Fifth, emergence either resulted from or was influenced by the use of prototyping. The alternative to prototyping, formalized methodologies, were inadequate in Case One, as demonstrated by their limited assistance and use during the project. It was difficult to plan detailed requirements and design documents with limited understanding of the general and specific clinical environment, and little understanding of the project and the analysis methods by clinic personnel. In Case One, prototyping was used instead, to allow testing of the Foxpro software, to build upon the wealth of data already available in EasySys, and to generate enthusiasm for working prototypes. In Case Two, the US version of Empower was a prototype, which was modified into another prototype for testing in the field. Prototyping allowed the exploration of context, and provided a method of testing certain ideas back into the setting. In both cases, reaction from users provided instant corrective feedback, increasing learning, and establishing trust. In addition, imperfect choice allowed the developers to Chapter 7: Contributions, Implications and Future Research 165 address multiple constraints, realizing that the full impact of these choices would be forthcoming. Any unpleasant outcomes were hedged with escape clauses. Sixth and as a result of prototyping, both cases dissolved the distinctions between design and implementation, development and maintenance, and users and developers. Implementation was considered throughout design, given the multitude of possible designs that can be drawn from a set of needs. The designs were both "mentally" and physically tested in the context to determine their viability. Learning of new requirements and needs, and even problem definition were further refined for the next phases. The result was a cycle of continuous learning and iterative design. Prototyping also dissolved the distinction between development and maintenance, because maintenance is a smaller iterative cycle of development. In addition, shocks from the environment and learning forced a wider cycle of development in later stages to ensure the software's continued relevance to the organization. Prototyping and user involvement also dissolved the distinction between developers and users. In a sense, prototyping and user involvement makes users into developers, and developers into users.263 More generally, it is this common link between two individuals with different goals that produces at least an understanding of each others' perspectives that was crucial to successful ISD. Seventh, there is a tension between developing a significantly different IS for an organization or incremental changes to the current IS. This tension is similar to Zuboffs In these cases, I was also a user of the system in terms of the "use" logs and research information collected from both sites. Chapter 7: Contributions, Implications and Future Research 166 (1988) automating versus informating, Attewell's (1992) competence-enhancing and competence-destroying, Petroski's (1994) evolutionary innovation, Hammer & Champy's (1993) "don't automate; obliterate", and Mohr's (1987) routine change and readaptation264 Automation is concrete, easier to address and competence enhancing, but may produce only a limited impact on work and effectiveness. On the other hand, "informating" and transformation through information technology has a potentially larger impact on work and effectiveness. The wider boundaries of the new IS, however, will attract and require more interest groups than an automation project, and integrate many groups unfamiliar each other (Kling 1987). As a result, a wider boundary can potentially overrun the resources available to consult these groups, risking system obsolescence, restricted involvement, and system survival (Van De Ven 1986).265 Once again, the solution is to find a balance between ambitious IS development that causes widespread change, and minimal ISD that changes very little. Regardless of the outcome, a balance is required between the "analog" (organization setting) and "digital" (computer) world. Determining the tasks to be supported by computerization and tasks that would be harmed by computerization is difficult and requires constant monitoring. The blind overuse of computers into every human activity is difficult at best and harmful at worst. It also suggests that the obliteration of organizational processes from those far removed from the task may be dangerous and based on naive assumptions about the value of an organizational task (Hammer & Champy 1993).. 1 Argyris, Putnam, & Smith (1985) comment that single-loop learning (automation) is much easier than double-loop learning (informating). Chapter 7: Contributions, Implications and Future Research 167 7.3. Limitations and Future Research Limitations of case research are based on the four validities: internal validity, external validity, construct validity, and reliability (Yin 1994). These limitations form the basis for future research. Crucial to many of the conclusions are the use of the four process theories, the subjective categorization of ISD research into one of the four theories, the selection of critical events and processes, and the connection of technology-context processes to the research (construct validity and reliability). The integrated theoretical model linking the four context-technology theories together, also relies on subjective interpretation. Future research with the case data, examining a more systematic coding and analyzing of the diaries, documentation, and design notes will increase construct validity. This data will also be examined using other development theories of Kling and Scacchi (1982)266, Argyris, Putnam, & Smith (1985)267, Hirschheim & Klein (1989),268 which will provide different theoretical lenses on the results. Data will also be analyzed using variance and statistical research to examine process variables and their correlation over time. This will also increase internal validity (Sabherwal & Robey 1995). Other data collected from the cases, including various prototypes of SoftHeart and EMPOWER, can be examined for confirming and extending the theoretical model. Discrete entity and web models. Single-loop and double loop learning: /, O-I, II, and O-II models. Functionalist, social relativism, radical structuralism, and neo-humanism.. Chapter 7: Contributions, Implications and Future Research 168 Future cases are also required to fully test the integrated model to overcome the exploratory nature of this thesis.269 This will increase the internal validity and improve on the construct validity and measurement of concepts such as dimension, process, process stages, technological imperative, organizational imperative, social technology, emergent perspective, technology, power, and organizational structure (Yin 1994).270 The use and/or development of a system methodology closely related to the theory may also be examined (Checkland & Scholes 1990), to test and refine of the model and the methodology. The other weaknesses of the thesis relate to the external validity of the cases. The results of two complex case studies must be carefully generalized and researched in other settings. These future settings should include differences in all six contextual dimensions including organization, user groups, technology, environments, and developer/suppliers. In particular, further observation of the later implementation stages in both case studies will provide a continued examination of the later implementation stages and 'impact'. In Case One, this includes patient/provider talk, and changes in patient attitudes, intentions, social support, reinforcement, patient behavior, biochemical outcomes, and possibly disease incidence onset. In case two, 'impact' will include the health promotion planning process, the health promotion plan and implementation, changes in mammography rates, and diffusion of EMPOWER into other settings. The data from later stages of implementation may demonstrate more technological and organization imperatives. 1 Although data were collected from a second case to help confirm the initial framework, the revised theory is the product of both case study analyses. 1 Construct validity and internal validity have been increased in the thesis by using multiple sources of data, and time series analysis. Reliability has been increased by providing the case descriptions, and a detailed methodology provided in Chapter 3. Chapter 7: Contributions, Implications and Future Research 169 Weakening the generalizability of the results is the developer's background, experience, and role in other projects. My development role in case one and two gave me a special lens on the results of the development. Although individuals in the case studies confirmed my findings (Yin 1994), these other individuals may have seen and experienced other events that I was unable to experience. I also had an important interest and effect on the course of the case studies and my interpretation the information must be taken into consideration. Future research will need to use observational and survey approaches to assess independently the theoretical model. Future research beyond the two case studies can include comparison of user, management, and developer impressions during development. Different types and conditions of user involvement may be examined to study more closely the process of user involvement in action research. Finally, the social conditions of technological imperatives and organizational imperatives could be examined. 7.4. Concluding Comments This thesis joins a stream of research longitudinally studying the process ISD, and the interaction between technology and context. The two cases will continue to be studied into the later stages of implementation, with the assistance of postdoctoral funding. Information system development involves a series of complex processes between technology and context. As a result, the future of both context and technology is fortunately non-deterministic. This allows for numerous ideas and visions to be incorporated into and influenced by technology. I hope to observe, facilitate and contribute to this interaction. References 170 8. References Akehurst, R. (1985). "The Economic Evaluation of Clinical Practice". Social Science and Medicine. 20 (10), 1037-1040. Angeles, P. A. (1981). Dictionary of Philosophy. HarperPerennial: New York. Argyris, C , Putnam, R , & D. Smith. (1985). Action Science: concepts. Methods and Skills for Research and Intervention. Jossey-Bass: San Francisco. Attewell, P. (1992). "Technology Diffusion and Organizational Learning: The Case of Business Computing". Organization Science. 3(1), 1-19. Barki, H . , Rivard, S., & J. Talbot. (1993). " A Keyword Classification Scheme for IS Research Literature: An Update". MIS Quarterly. June 1993, 209-226. Barley, S. (1986). "Technology as an Occasion for Structuring: Evidence from Observations of CT Scanners and the Social Order of Radiology Departments." Organization Science. Vol. 1(3), 220-247. Barley, S. (1990). "Images of Imaging: Notes on Doing Longitudinal Field Work". Organization Science. 1(3), 220-247. Baronas, A.K. , & M.R. Louis. (1988). "Restoring a Sense of Control During Implementation: How User Involvement Leads to System Acceptance". MIS Quarterly. March 1988, 111-123. Baroudi, J., Olson, M . H . , & B. Ives. (1986). "An Empirical Study of the Impact of User Involvement on systems Usage and Information Satisfaction". Communications of the A C M . 29, 232-238. Basalla, G. (1988). The Evolution of Technology. Cambridge University Press: Cambridge. Beath, C M . , & W.J. Orlikowski. (1994). "The Contradictory Structure of Systems Development Methodologies: Deconstructing the IS-User Relationship in Information Engineering", Information Systems Research. Vol. 5(4), 350-377. Benbasat, I., & A. Dexter. (1985a). "Experimental Evaluation of Graphical and Color-Enhanced Information Presentation". Management Science, Vol. 31(11), 1348-1364. References 171 Benbasat, I., & A. Dexter. {1986???} (1985b). "An Investigation of the Effectiveness of Color and Graphical Information Presentation under Varying Time Constraints." Management Information Systems Quarterly. Vol. 10(1). 59-83. Benbasat, I., Dexter, A , & P. Todd. (1986a). "The Influence of Color-Enhanced Graphical Information Presentation on Report Use and Decision Performance in a Simulation Supported Task". Human Computer Interaction, Vol. 2(1), 65-92. Benbasat, I., Dexter, A. , & P. Todd. (1986b). "An Experimental Program Investigating Color-Enhanced and Graphical Information Presentation: An Integration of the Findings." Communications of the A C M . Vol. 29(111 1094-1105. Benbasat, I.., DeSanctis, G , & B . R Nault. (1993). "Empirical Research in Managerial Support Systems: A Review and Assessment". In C.W. Holsapple & A.B. Whinston (eds.), Recent Developments in Decision Support Systems. Springer-Verlag: Berlin, pp. 383-437. Benbasat, I, Goldstein, D.K., & M . Mead. (1987). "The Case Research Strategy in Studies of Information Systems". MIS Quarterly. September 1987, 369-386. Berger, P.L., & T. Luckmann. (1967). The Social Construction of Reality. Anchor Books: New York. Boehm, B . (1988). "A Spiral Model of Software Development and Enhancement". IEEE Computer. 21 (2), 61-72. Boland, R J . (1978). "The Process and Product of System Design", Management Science. Vol . 28(9), 887-898. Boland, R J . (1985). "Phenomenology: A Preferred Approach to Research on Information Systems." In E. Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, pp. 193-201. Boland, R J . (1987). "The In-formation of Information Systems". In R J . Boland & R.A. Hirschheim (eds.). Critical Issues in Information Systems Research. John Wiley & Sons: New York, pp. 363-379. Boland, R J . (1990). "Information System Use as a Hermeneutic Process". In H.E. Nissen, H.K. Klein & R Hirschheim (eds.), The Information Research Arena of the 90's: Challenges. Perceptions, and Alternative Approaches. ISRA-90 Proceedings - Working Conference: Sweden, pp. 255-270. References 172 Bostrom, J., & T. McDonald. (1995). "Outcomes Assessment: At What Cost?". Managed Care Quarterly. Vol. 3(4), 79-83. Bostrom, R.P., & J.S. Heinen. (1977). "MIS Problems and Failures: A Socio-Technical Perspective Part I: The Causes", MIS Quarterly. Vol. 1(3), 17-32. Brooks, F. (1987). "No Silver Bullet: Essence and Accidents of Software Engineering". Computer. April 1987, 10-19. Burton, P.F. (1992). Information Technology and Society: Implications for the Information Professions. Library Association Publishing: London. Carrol, J .M., & R.L. Mack. (1984). "Learning to Use a Word Processor: By Doing, by Thinking, and by Knowing". In J.M. Carrol & R. Mack (eds.), Human Factors in Computer Systems. Ablex: Norwood, pp. 278-297. Carter, W.B.. (1990). "Health Behavior as a Rational Process: Theory of Reasoned Action and Multiattribute Utility Theory". In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory, Research, and Practice. Jossey-Bass: San Francisco, pp. 63-91. Checkland, P. & J. Scholes. (1990). Soft Systems Methodology in Action. J. Wiley: Chichester. Cooper, R.B., & R.W. Zmud. (1990). "Information Technology Implementation Research: A Technological Diffusion Approach". Management Science. Vol. 36(2), 123-139. Das, T.H. (1983). "Qualitative Research in Organizational Behavior". Journal of Management Studies, Vol. 20(3), 301-314. Davenport, T.H., & J.E. Short. (1990). "The New Industrial Engineering: Information Technology and Business Process Redesign". Sloan Management Review. Summer 1990, 11-27. Davis, D.L., & H.L. Bradlow. (1995). "Can Environmental Estrogens Cause Breast Cancer?". Scientific American. October 1995, 166-172 DeLone, W.H., & E.R. McLean. (1992). "Information Systems Success: The Quest for the Dependent Variable." Information Systems Research. 3(1), 60-95. DeSanctis, G., & M.S. Poole. (1994). "Capturing the Complexity in Advanced Technology Use: Adaptive Structuration Theory". Organization Science. Vol. 5(2), 121-147. References 173 DiMatteo, M . R , & D.D. DiNicola. (1982). Achieving Patient Compliance: The Psychology of the Medical Practitioner's Role. Pergamon: New York. Doyle, R. (1995). "Deaths Caused by Breast Cancer, by County". Scientific American, October 1995, p. 32D. Dutton, W.H. (1981). "The Rejection of an Innovation: The Political Environment of a computer-Based Model", Systems, Objectives. Solutions. Vol. 1(4), 179-201. Eisenhardt, K . M . (1989). "Building Theories from Case Study Research," Academy of Management Review. Vol. 14(4), 532-550. Earl, M . (1989). Management Strategies for Information Technology. Prentice-Hall: Hemel. Emery, F.E., & E.L. Trist (1971). "The Causal Texture of Organizational Environments". In J.G. Mauer (ed.), Readings in Organization Theory: Open Systems Approaches. Random House: New York. Erdman, H . P., Klein, M . H. , & J. Griest (1985). "Direct Patient Computer Interviewing". Journal of Consulting & Clinical Psychology. Vol. 53(6), 760-773. Evans, R.G. (1984). Strained Mercy: The Economics of Canadian Health Care. Butterworths: Toronto. Evans, R .G , (1990). What Seems to be the Problem? The International Movement to Restructure Health Care Systems. Health Policy Research Unit: Discussion Paper Series. Eveland, J.D., L . Tornatzky (1990). "The Deployment of Technology". In L . Tornatzky & M . Fletscher (eds.), The Processes of Technological Innovation. Lexington Books: Lexington, M A , pp. 117-147. Forester, T., & P. Morrison. (1990). "Computer Unreliability and Social Vulnerability". Futures. June 1990, 462-474. Franklin, U . (1990). The Real World of Technology. House of Anansi Press: Concord. Franz, C.R., & D. Robey. (1984). "An Investigation of User-Led System Design: Rational and Political Perspectives", Communications of the A C M . Vol. 27, 1202-1209. Franz, C.R., & D. Robey. (1987). "Strategies for Research on Information Systems in Organizations: A Critical Analysis of Research Purpose and Time Frame". In R.J. Boland References 174 and R.A. Hirschheim (eds.), Critical Issues in Information systems Research. John Wiley & Sons: New York, pp. 205-225. Gagne,M. (1994). "Changing the Way We Live". Globe & M a i l January 26. 1994. Gathers, R.D. "Choosing Appropriate Information Systems Research Approaches: A Revised Taxonomy". In H.E. Nissen, H.K. Klein & R. Hirschheim (eds), The Information Research Arena of the 90's: Challenges, Perceptions, and Alternative Approaches. ISRA-90 Proceedings - Working Conference: Sweden, pp. 155-173. George, J., Easton, G., Nunamaker, J., & G. Northcraft. (1990). " A Study of Collaborative Group Work with and without Computer-Based Support". Information Systems Research. Vol. 1(4), 394-415. Gibbs, W. (1994). "Software's Chronic Crisis". Scientific American. September. 86-95. Gibson, C.F. (1975). " A Methodology for Implementation Research", in R.L. Schultz and DP Slevin (eds.), Implementation Operations Research/Management Science. American Elsevier: New York, pp. 53-73. Gladden, G. (1982). "Stop the Life-Cycle: I Want to get Off." Software Engineering Notes. 7(2), 35-39. Goley, G.S. (1993). Creating Foxpro Applications: The Professional Programmer's Guide to Foxpro 2.5. Que Books: Indiana. Gould, J. (1988). "How to Design Usable Systems". In M . Helander (ed.), Handbook of Human-Computer Interaction. 757-789. Green, L.W., & M:W. Kreuter. (1991). Health Promotion Planning: An Educational and Environmental Approach (2nd Edition). Mayfield Publishing: Mountain View. Green, L.W., George, M.A. , Daniel, M . , Frankish, C.J., Herbert, C.J., Bowie, W.R., & M . O'Neill. (1995). Study of Participatory Research in Health Promotion: Review and Recommendations for the Development of Participatory Research in Health Promotion in Canada. Institute of Health Promotion Research in British Columbia and the British Columbia Consortium for Health Promotion Research: Vancouver. Green, L.W. (1996). "Bringing People Back to Health". Promotion & Education, Vol. 3(1), 23-27 References 175 Gurbaxani, V. , & S. Whang. (1991). "The Impact of Information Systems on Organizations and Markets". Communications of the A C M . Vol. 34(1), 59-73. Hammer, M . , & J. Champy. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business: New York. Harrington, J. (1991). Organisational Structure and Information Technology. Prentice Hall: New York. Hayden, M . (1988). Familial Hypercholesterolemia. Pamphlet printed by Bristol Laboratories of Canada. Henderson, A , & M . Kyng. (1991). "There's No Place like Home: Continuing Design in Use". In J. Greenbaum and M . Kyng (eds.), Design at Work. Lawrence Erlbaum: New Jersey, pp. 219-240. Hirschheim, R , & M . Newman. (1991). "Symbolism and Information Systems Development: Myth, Metaphor and Magic". Information Systems Research, 2(1), 29-62. Hirschheim, R, & H . Klein. (1989). "Four Paradigms of Information systems Development", Communications of the A C M . Vol. 32, 9-23. Hitt, L . , & E. Brynjolfsson. "The Three Faces of IT Value: Theory and Evidence". ICIS 1994 Conference Proceedings. Vancouver, December 1994, pp. 263-277. Israel, B. , & S.J. Schurman. (1990). "Social Support, Control, and the Stress Process." In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory. Research, and Practice. Jossey-Bass: San Francisco, pp. 187-215. Ives, B. , & M . H . Olson. (1984). "User Involvement and MIS Success: A Review of Research". Management Science. 30, 586-603. Jick, T. (1979). "Mixing Qualitative and Quantitative Methods: Triangulation in Action". Administrative Science Quarterly. Vol. 24, 602-610. Johnson, H. , & M . Vitale. (1988). "Creating Competitive Advantage with Interorganizational Information Systems". MIS Quarterly. June 1988, 153-165. Jonsson, S. (1991). "Action research," in H.E. Nissen, H.K. Klein, & R. Hirschheim (eds.), Information Systems Research: Contemporary Approaches and Emergent Traditions. North Holland: Amsterdam, pp. 371-396. References 176 Joos, S., & D.H. Hickam. (1990). "How Health Professionals Influence Health Behavior: Patient-Provider Interaction and Health Care Outcomes". In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory. Research, and Practice. Jossey-Bass: San Francisco, pp. 216-241. Kannel, W.B. (1992). "The Framingham Experience". In M . Marmot & P. Elliott (eds), Coronary Heart Disease Epidemiology. Oxford University Press: Oxford. Kaplan, N . , & J. Stamler. (1983). Prevention of Coronary Heart Disease: Practical Management of the Risk Factors. W.B. Saunders Company: Philadelphia. Karam, J.A., Sundre, S.M., & G.L. Smith. (1986). "The Cost/Benefit of Patient Education". Hospital and Health Services Administration, July/August, 82-90. Keil, M . (1995). "Pulling the Plug: Software Project Management and the Problem of Project Escalation". Management Information Systems Quarterly. Dec. 1995, 421-447. Kelman, H . (1958). "Compliance, Identification, and Internationalization: Three Processes of Attitude Change." Journal of Conflict Resolution, Vol. 2, 51-60. Kidder, T. (1981). The Soul of a New Machine. Avon Books: New York. Kim, K . K . , & J.E. Michelman. (1990). "An Examination of the Factors for the Strategic Use of Information Systems in the Healthcare Industry." MIS Quarterly. Vol. 14(2), 201-215. King, J.L., Gurbaxani, V. , Kraemer, K . L . , McFarlan, F.W., Raman, K.S., & C.S. Yap. (1994). "Institutional Factors in Information Technology Innovation". Information Systems Research. Vol. 5(2), 139-167. Klein, H.K., & R. Hirschheim. (1985). "Social Change and the Future of Information Systems Development". In R.J. Boland & R.A. Hirschheim (eds.), Critical Issues in Information Systems Research. John Wiley: New York, pp. 275-305. Klein, H.K., & K. Lyytinen. (1985). "The Poverty of Scientism in Information Systems". In E. Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, pp. 131 -161. Kling, R. (1980). "Social Analysis of Computing: Theoretical Perspectives on Recent Empirical Research". Computing Surveys. Vol. 120). 61-110. References 177 Kling, R. (1987). "Defining the Boundaries of Computing Across Complex Organizations", in R. Boland and R. Hirschheim (eds.), Critical Issues in Information systems Research. John Wiley: New York, pp. 307-362. Kling, R , & W. Scacchi. (1982). "The Web of Computing: Computer Technology as Social Organization." In M . Yovits (ed.), Advances in Computers. 21. Academic Press: New York, pp. 1-90. Kuller, L . H . (1992). "Assessing the Evidence: Risks and Benefits". In M . Marmot & P. Elliott (eds.), Coronary Heart Disease Epidemiology. Oxford University Press: Oxford. Kwon, T.H., & R.W. Zmud. (1987). "Unifying the Fragmented Models of Information Systems Implementation". In R J . Boland & R.A. Hirschheim (eds.), Critical Issues in Information Systems Research. John Wiley & Sons: New York, pp. 227-251. Landauer, T. (1991). "Let's Get Real: A Position Paper on the Role of Cognitive Psychology in the Design of Humanly Useful and Usable Systems". In J.M. Carroll (ed.), Designing Interaction. Cambridge University Press, pp. 60-73. Landauer, T.K. (1995). The Trouble with Computers. Usefulness, Usability, and Productivity. The MIT Press: Cambridge. Latour, B. (1987). Science in Action: How to Follow Scientists and Engineers Through Society. Harvard University Press: Cambridge. Latour, B. (1994). "Where are the Missing Masses? The Sociology of a Few Mundane Artifacts". In W.E. Bijker & J. Law (eds.), Shaping Technology/Building Society: Studies in Sociotechnical Change. The MIT Press: Cambridge, pp. 225-258. Layder, D. (1993). New Strategies in Social Research. Polity Press: Cambridge. Lee, A. (1989). " A Scientific Methodology for MIS Case Studies". MIS Quarterly. March 1989, 33-50. Lee, A. (1991). "Integrating Positivist and Interpretive Approaches to Organizational Research". Organization Science. Vol. 2(4), 342-365. Lewin, K. (1946). "Action Research and Minority Problems". Journal of Social Issues. Vol. 2(4), 34-46. References 178 Lewis, F .M. , & L . H . Daltroy. (1990). "How Causal Explanations Influence Health Behavior: Attribution Theory". In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory. Research, and Practice. Jossey-Bass: San Francisco, pp. 92-114. Lyytinen, K.J . (1987). " A Taxonomic Perspective of Information Systems Development: Theoretical Constructs and Recommendations". In R.J. Boland & R.A. Hirschheim (eds). Critical Issues in Information Systems Research. John Wiley & Sons: New York, pp. 3-41. Lyytinen, K. , & R. Hirschheim. (1987). "Information systems Failures: A Survey and Classification of the Empirical Literature". Oxford Surveys in Information Technology. Vol. 4, 257-309. Lyytinen, K. J., & H.K. Klein. (1985). "The Critical Theory of Jurgen Habermas as a Basis for a Theory of Information Systems". In E. Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, pp. 219-235. Main, T., & J.E. Short. (1989). "Managing the Merger: Building Partnership Through IT Planning at the New Baxter". MIS Quarterly. 13(4), 469-484. Markus, L . (1981). "Implementation Politics: Top Management Support and User Involvement", Systems. Objectives. Solutions. Vol. 1(4), 203-215. Markus, L . (1983). "Power, Politics, and MIS Implementation", Communications of the A C M . Vol. 26(6), 430-444. Markus, L. , & D. Robey. (1988). "Information Technology and Organizational Change: Causal Structure in Theory and Research". Management Science. Vol. 34(5), 583-598. McClintock, C.C., Brannon, D., & S. Maynard-Moody. (1979). "Applying the Logic of Sample Surveys to Qualitative Case Studies: The Case Cluster Method". Administrative Science Quarterly. Vol. 24, 612-628. McCool, W.F. (1994). "Barriers to Breast Cancer Screening in Older Women". Journal of Nurse-Midwifery. Vol. 39(5), 283-299. McFarlan, F.W. (1984). "Information Technology Changes the Way you Compete". Harvard Business Review. May-June, 98-103. McFarlan, F.W., & J.L. McKenney. (1983). "The Information Archipelago - Plotting a Course". Harvard Business Review. May-June, 98-103. References 179 McFarlan, F.W., McKenney, J.L., & P. Pyburn. (1983). "The Information Archipelago --Governing the New World". Harvard Business Review. July-Aug.. 91-99. McKenney, J.L, & F.W. McFarlan. (1982). "The Information Archipelago ~ Maps and Bridges". Harvard Business Review. Sept-Oct, 109-119. Miles, M.B. , & A. M . Huberman. (1994). Qualitative Data Analysis (2nd ed.). Sage: Thousand Oaks. Mohan, L. , Holstein, W. K., & R. B. Adams. (1990). "EIS: It Can Work in the Public Sector". MIS Quarterly, 14 (4), 435-448. Mohr, L . (1987). "Innovation Theory: An Assessment form the Vantage Point of New Electronic Technology in Organizations". In J. Pennings and A. Buitendam (eds), New Technology as Organizational Innovation: The Development and Diffusion of Microelectronics. Ballinger: Cambridge, pp. 13-31. Monge, P.R. (1990). "Theoretical and Analytical Issues in Studying Organizational Processes". Organization Science. 1(4), 406-430. Moore, T.J, (1989). "The Cholesterol Myth". Atlantic Monthly. September 1989, 37-70. Morgan, G. (1986). Images of Organization. Sage: Newbury Park. Mulkay, M . , Ashmore, M . , & T. Pinch. "Measuring Quality of Life: A Sociological Invention concerning the Application of Economics to Health Care". Sociology. Vol. 21(4), 541-564. Myers, M.D. (1994a). " A Disaster for Everyone to See: An Interpretive Analysis of a Failed IS Project", Accounting. Management and Information Technologies. Vol. 4(4), 185-201. Myers, M.D. (1994b). "Dialectical Hermeneutics: A Theoretical Framework for the Implementation of Information Systems", Information Systems Journal. Vol. 5(1), 51-70. Nadler, G. (1982). "The planning and design professions". Human Systems Management. 3, 289-300. Newman, M . , & F. Noble. (1990). "User Involvement as an Interaction Process: A Case Study". Information Systems Research. 1(1). 89-118. Newman, M . , & D. Robey. (1992). " A Social Process Model of User-Analyst Relationships", MIS Quarterly. Vol. 16(2), 249-266. References 180 Olson, M . (1981). "User Involvement and Decentralization of the Development Function: A Comparison of Two Case Studies," Systems, Objectives. Solutions. Vol. 1(2), 59-69. Olson, M . H . , & B. Ives. (1984) "User Involvement in System Design: An Empirical Test of Alternative Approaches". Information and Management. 4. 183-196. Orlikowski, W.J. (1991). "Integrated Information Environment or Matrix of Control? The Contradictory Implications of Information Technology". Accounting Management and Information Technology. Vol. 1(1), 9-42. Orlikowski, W.J. (1992a). "The Duality of Technology: Rethinking the concept of Technology in Organizations". Organization Science. Vol. 3(3), 398-427. Orlikowski, W.J. (1992b). "Learning from Notes: Organizational Issues in Groupware Implementation". CSCW '92 Proceedings. 362-369. Orlikowski, W.J., & J.J. Baroudi. (1991). "Studying Information Technology in Organizations: Research Approaches and Assumptions". Information Systems Research. 2(1), pp. 1-28. Orlikowski, W.J., & D. Robey. (1991). "Information Technology and the Structuring of Organizations". Information Systems Research. 2(2), 143-169. Ottoson, J .M. & L.W. Green. (1987). "Reconciling Concept and Context: Theory of Implementation". Advances in Health Education and Promotion. Vol. 2, pp. 353-382. Perry, C.L., Baranowski, T., & G S . Parcel. (1990). "How Individuals, Environments, and Health Behavior Interact: Social Learning Theory". In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory, Research, and Practice, Jossey-Bass: San Francisco, pp. 161-186. Petroski, H . (1994). The Evolution of Useful Things. Vintage Books: New York. Pettigrew, A . M . (1979). "On Studying Organizational Cultures". Administrative Science Quarterly. Vol. 24, 570-580. Pettigrew, A . M . (1985). "Contextualist Research and the Study of Organisational Change Processes". In E. Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, pp. 53-78. Plomann, M.P., & F A . Shaffer. (1984). "DRGs as One of Nine Approaches to Case Mix in Transition", In DRGs: Changes & Challenges. Franklin Shaffer (ed.). National League for Nursing: New York. References 181 Postman, N . (1992). Technolopoly: The Surrender of Culture to Technology. Vintage Books: New York. Rachlis, M . , & C. Kushner. Strong Medicine: How to Save Canada's Health System. HarperCollins: Toronto. Reich, B.H. , & I. Benbasat. (1990). "An Empirical Investigation of Factors Influencing the Success of Customer-Oriented Strategic Systems". Information Systems Research. 1(3). 325-347. Regush, N . (1987). "Unnecessary High Blood Pressure Treatment". In N Regush (ed.), Condition Critical. Macmillan: Toronto. Rheingold, H . (1993). The Virtual Community: Homesteading on the Electronic Frontier. Addison-Wesley: Reading. Ritzer, G. (1992). Contemporary Sociological Theory: 3rd Edition. McGraw-Hill: New York. Robey, D., Farrow, D., & C.R. Franz. (1989). "Group Process and Conflict in System Development". Management Science. 35(10\ 1172-1191. Robey, D., & L. Markus. (1984). "Rituals in Information System Design", Management Information Systems Quarterly. Vol. 8(1), 5-15. Robinson, R , & R. West. (1992). "A Comparison of Computer and Questionnaire Methods of History Taking in a Genito-urinary Clinic". Psychology & Health. Vol. 6(1-2), 77-84. Rodin, J., & I.L. Janis. (1982). "The Social Influence of Physicians and Other Health Care Practitioners as Agents of Change." In H.S. Friedman and M.R. DiMatteo (eds.), Interpersonal Issues on Health Care. Academic Press: Orlando. Rogers, E. (1995). Diffusion of Innovations (4th ed.). The Free Press: New York. Rosenstock, I. M . . (1990). "The Health Belief Model: Explaining Health Behavior through Expectancies". In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory. Research, and Practice. Jossey-Bass: San Francisco, pp. 39-62. Rudd, J., & K. Glanz. (1990). "How Individuals Use Information for Health Action: Consumer Information Processing". In, Glanz, Lewis, & Rimer (eds.), Health Behavior and Health Education: Theory. Research, and Practice. Jossey-Bass: San Francisco, pp. 115-139. Russell, L B . (1986). Prevention Better Than Cure? The Brookings Institution: Washington. References 182 Sabherwal, R , & D. Robey (1995). "Reconciling Variance and Process Strategies for Studying Information System Development". Information Systems Research. Vol. 6(4), 303-327. Salazar, M.K. , & C. de Moor. (1995). "An Evaluation of Mammography Beliefs Using a Decision Model". Health Education Quarterly. Vol. 22(1), 110-126. Sanday, P.R. (1979). "The Ethnographic Paradigms". Administrative Science Quarterly. Vol. 24, 527-538. Sandberg, A. (1985). "Socio-Technical Design, Trade Union Strategies and Action Research". In E, Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, pp. 79-92. Sarafino, E.P. (1990). Health Psychology: Biopsychosocial Interactions. John Wiley & Sons: New York. Saul, J.R. (1993). Voltaire's Bastards: The Dictatorship of Reason in the West. Penguin Books: Toronto. Saul, J.R. (1995). The Doubter's Companion: A Dictionary of Aggressive Common Sense. Penguin Books: Toronto. Schon, D. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic: New York. Seaton, P.D., Evans, R.G., Ford, M.G. , Fyke, K.J. , Sinclair, D.R., & W.A. Webber. (1991). Closer to Home: The Report of the British Columbia Royal Commission on Health Care and Costs. Crown Publications: Victoria. Sheils, J.f, Young, G.J., & R.J. Rubin. (1992). "O Canada: Do We Expect Too Much from Its Health System?". Health Affairs. Vol. 11(1), Spring 1992, 7-20. Slovic, P., Fischoff, B. , & Lichtenstein, S. (1982). "Facts versus Fears: Understanding Perceived Risk", in Kahneman, Slovic & Tversky (eds.) Judgment under uncertainty: Heuristics and Biases. Cambridge University Press: Cambridge, pp. 463-489. Slovic, P. (1986). "Informing and Educating the Public About Risk". Risk Analysis. Vol. 6(4), 403-415. Slovic, P. (1987). "Perception of Risk". Science. Vol. 236 (April), 280-285. Slovic, P, Fischhoff, B. , & Lichtenstein, S. (1988). "Response Mode, Framing, and Information-Processing Effects in Risk Assessment" in David Bell et al. (eds.) Decision Making: References 183 Descriptive. Normative, and Prescriptive Interactions. Cambridge University Press: Cambridge, pp. 152-166. Slovic, P., Kraus, N . , & V. Covello. (1990). "What Should we Know about Making Risk Comparisons?" Risk Analysis, Vol . 10(3), 389-392. Sproull, L . & S. Kiesler. (1991). "Computers, Networks and Work". Scientific American. Sep. 1991,116-123. Stamler, J. (1992). "Established Major Coronary Risk Factors". In M . Marmot & P. Elliott (eds.), Coronary Heart Disease Epidemiology. Oxford University Press: Oxford. Sviokla, J. (1989). "Expert Systems and their Impact on the Firm: The Effects of PlanPower Use on the Information Processing Capacity of the Financial collaborative". Journal of Management Information systems. Vol. 6(3), 65-84. Susman, G.I., & R.D. Evered. "An Assessment of the Scientific Merits of Action Research". Administrative Science Quarterly. Vol. 23, 592-603. Sutherland, R.W., & J.M. Fulton. (1990). Health Care in Canada: A Description and Analysis of Canadian Health Services. The Health Group: Ottawa. Svarstad, B. (1976). "Physician-patient Communication and Patient Conformity with Medical Advice." In D. Mechanic (ed.), The Growth of Bureaucratic Medicine. Wiley & Sons: New York. Talbott, S. L . (1995). The Future Does not Compute: Transcending the Machines in Our Midst. O'Reilly & Associates: Sebastopol. Tan, J., & I. Benbasat. (1990). "Processing of Graphical Information: A Decomposition Taxonomy to Match Data Extraction Tasks and Graphical Representations". Information Systems Research. 1(4), 416-439. Terreberry, S. (1971). "The Evolution of Organizational Environments". In J.G. Mauer (ed.), Readings in Organizational Theory: Open Systems Approaches. Random House: New York. Theorell, T. (1992). "The Psycho-social Environment, Stress, and Coronary Heart Disease". In M . Marmot & P. Elliott (eds.), Coronary Heart Disease Epidemiology. Oxford University Press: Oxford. References 184 Thomas, R J . (1994). What Machines Can't Do: Politics and Technology in the Industrial Enterprise. University of California Press: Berkeley. Thompson, J.D. (1967). Organizations in Action: Social Science Bases of Administrative Theory. McGraw Hill: New York. Todd, P., & I. Benbasat. (1991). "An Experimental Investigation of the Impact of Computer Based Decision Aids on Decision Making Strategies". Information Systems Research. 2(2), 87-115. Turner, J.A. (1987). "Understanding the Elements of System Design". In R.J. Boland & R.A. Hirschheim (eds.). Critical Issues in Information Systems Research. John Wiley & Sons: New York. Tversky, A. , & D. Kahneman. (1981). "The Framing of Decisions and the Psychology of Choice". Science. Vol.211. 453-458. Tyre, M.J. , & W.J. Orlikowski. (1994). "Windows of Opportunity: Temporal Patterns of Technological Adaptation in Organizations". Organization Science. 5(1), 98-118. Vancouver Sun. (1992). "Where Your Health Care Dollar Goes", p i . Van De Ven, A. (1986). "Central Problems in the Management of Innovation". Management Science. Vol. 32(5), 590-607. Van De Ven, A. & Polley (1992). "Learning while Innovating". Organization Science. Vol. 3(1), 92-116. Vitalari, N . (1985). "The Need for Longitudinal designs in the Study of Computing Environments". In E. Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, 243-265. Walsham, G. (1995). "The Emergence of Interpretivism in IS Research". Information Systems Research. Vol. 6(4), 376-394. Wand, Y . & R. Weber. "On the Ontological Expressiveness of Information Systems Analysis and Design Grammars". Journal of Information Systems. Vol. 3, 217-237. Vladeck, B.C., & P.S.Kramer. "Case Mix Measures: DRGs and Alternatives". Annual Review of Public Health. Vol. 9, 333-359. References 185 Vogt, T. (1983). Making Health Decisions: An Epidemiological Perspective on Staying Well. Nelson-Hall: Chicago. Weiser, M . (1991). "The Computer for the 21st Century". Scientific American. September 1991, 94-102. Weitz, R. (1990). "Technology, Work, and the Organization: The Impact of Expert Systems". A l Magazine. Summer 1990, 50-60. Williams, A. (1985). "The Nature, meaning and Measurement of Health and Illness: An Economic Viewpoint". Social Science and Medicine. Vol. '21(10). 1023-1027. Windeler, J., & O. Gefeller (1992). "Critical Appraisal of Primary Prevention Trials: What is the Effectiveness of Lowering Lipid Levels? MEDINFO 92. 1190-1194. Winograd, T., & F. Flores. (1987). Understanding Computers and Cognition: A New Foundation for Design. Addison-Wesley Publishing: New York. Wolf, C P . , & F.J. Rossini. (1977). "Conceptual Difficulties in Problem-Oriented Research: Formulating the 'Holistic' Question". In R. Scribner & R. Chalk (eds.) Adapting Science to Social Needs: Knowledge. Institutions. People into Action. Proceedings on Problem Oriented Research, American Association for the Advancement of Science: Washington. Wood-Harper, T. (1985). "Research Methods in Information Systems: Using Action Research." In E. Mumford et al. (eds.), Research Methods in Information Systems. Elsevier Science Publishers: North-Holland, pp. 169-191. Wurman, R. S. (1990). Information Anxiety: What to do when Information Doesn't tell you what you need to know. Bantam Books: New York. Wynn, E. (1991). "Taking Practice Seriously", In J. Greenbaum and M . Kyng (eds.), Design at Work. Lawrence Erlbaum: New Jersey, pp. 45-64. Yin, R K . (1994). Case Study Research: Design and Methods. Sage Publications: Beverly Hills. Zuboff, S. (1988). In the Age of the Smart Machine. Basic Books: New York. Appendix A: The SoftHeart Story 186 9. Appendix A: Events in the Development of SoftHeart SoftHeart was developed over a period of time and progressed through a series of events, processes and stages of development. This appendix reports on the events among individuals, myself and the software during the development of SoftHeart. These events will be discussed within the following stages: project emergence, health funders skeptical, our response, old and new environmental shocks, decision to move ahead, prototype demonstration sparks interest and constraint, conflict erupts, decision to act, project builds momentum, development quagmire, and recovery and slow growth to early implementation.271 The final section discusses what lies ahead. 9.1. Project Emergence The project emerged from a mixture of individual interests, skills, and experience. My background influenced my attraction to the project and its original focus. My interest in integrating information systems and health care started with my undergraduate education. During that time, I became interested in accounting, health economics and organizational theory, and produced an undergraduate thesis examining case mix groupings in hospitals; a standard costing method of categorizing patients by disease (April 1990).272 My database experience provided me some of the skills for developing Note that these stages, although presented sequentially, were overlapping to some degree. : Diary notes, documentation, and archival material will be referenced by date, connecting the statements with the raw data. Appendix A: The SoftHeart Story 187 SoftHeart, and also certain perspectives on system development. The training of end-users in a company established by my partner and myself gave me a glimpse of computing "in the trenches", and its effect on the companies and end-user work (May 1990 -February 1991).273 In addition, my experience as a computer programmer hired by the Finance department at a fibre optic cable plant, led to some insights and perspectives about computing and work. I was secretly hired by the Finance department to deal with its programming needs due to the MIS department's inability to meet these needs.274 The challenge of developing reports under conditions of limited documentation, time pressure, and MIS's watchful eye led to certain beliefs about end-user computing in large organizations.275 Finally, a number of incidents revealed the negative effects of computing on working life. 2 7 6 The SoftHeart project was an opportunity for myself, and three researchers, including one clinic physician, to achieve numerous goals.2 7 7 The project emerged out of my interest in health and information, a need to find an interesting thesis topic, and a I talked to many users who developed some interesting and creative applications of generic software, illustrating how software is creatively adapted for individual needs. One user used Lotus 1-2-3 for word processing. The documents looked pretty impressive. 1 Human resources had just received the hiring papers the day I arrived. ' MIS's centralized approach to computing violated many of my beliefs about end-user computing. ' At that time, the fibre optic plant was an unwanted division in the corporate company, and had received numerous cuts in funding. The firing of a billing person one week after developing a program that reduced her time by 8 to 10 hours per week, pointed to the dark side of computing spurred by cost cutting measures. Employees at the firm mentioned that this clerk had received poor evaluations for some time, and that the program had nothing to do with her firing. ' The name "SoftHeart" was not attached to the project until July 2,1995. In fact, the project did not have a name until June 1994 when the software was called the "Adherence Application" to reflect its focus on increasing patient adherence to treatment regimens. Appendix A: The SoftHeart Story 188 chance for three colleagues to carry out research together (my supervisor, one committee member, and the clinic physician).278 During late 1991 and early 1992, I explored various research questions and ideas such as IT's poor diffusion amongst physicians, the poor match between user needs and IT, effects of IT on organizational structure, and the use of information to improve genetic screening and economic outcomes of information. My first meeting with my future supervisor came on February 1, 1992. I explained my interest in health care and its effect on organizational structure. At that time, I was interested in using an ethnographic approach to study the historical process of IT development and adoption in hospitals.279 My supervisor and his colleagues were interested in the economic effect of information used to assist screening of patients, based on their discussion with the Clinic One physician. Trying to consider how to combine my interest and theirs, I examined the framing literature that I had learned in a course the previous semester, and thought of trying to use that literature to develop information that would enhance patient understanding and motivation toward the information (March 1992 - May 1992). This concept of information framing was further extended with literature on multimedia computing and graphical presentation. My visit to Clinic One in July of 1992 seemed to suggest that information framing and multimedia computers could be used by patients while waiting to see ' All three had met a number of months before my arrival, and had discussed a joint project connecting IS, medicine, and economics. ' I had explored the topic in a recent class report. Appendix A: The SoftHeart Story 189 physicians. Early proposals reflected these ideas, employing an experimental approach to test the framing and multimedia effects on patient outcomes (Aug. 17, 1992 and Aug. 26, 1992).280 It appeared the project was underway. 9.2. Health Funders Skeptical In January 1993, the health agencies responded to our proposals. Although some of the referees supported our claim, others had serious doubt about information framing and a computer's ability to influence patient behavior and biochemical outcomes. The onus was on us to prove IT's systematic effect on health.281 Funding rejections forced us to more fully consider the role of the health and patient context in moderating and perhaps negatively influencing the outcome. What was the role of the provider? Had Clinic One been closely consulted about the intervention, and would the clinicians follow strict guidelines for discussing and presenting the information? What about the literature that suggested the widely varying effects of information on different patient populations? New measures were introduced to measure the path from the information intervention toward patient attitudes, behavior, environment, and finally biochemical outcomes to provide process measures of impact. ' At this point, very few people at the clinic had been fully consulted about the project. In fact, I had mistakenly believed that the physician colleague of my supervisor was the clinic director, which later turned out to be incorrect. The results of this first round of funding illustrated the widespread disagreement amongst health providers about the benefits and disadvantages of using computer systems. Some believe it leads to improved decision making and patient treatment, while others suggest computers destroy rapport between the provider and the patient. Appendix A: The SoftHeart Story 190 9.3. Our Response Responding to the criticism throughout the remainder of 1993, we developed new proposals reflecting a move away from information framing, toward the use of more extensive IS and IT to provide a strong test of IT's effect on patient outcomes. If the agencies felt the treatment was too weak, then we would try a larger IS intervention to provide a substantial test of the information effect. In addition, Clinic One's director and personnel were consulted more closely to observe their work and initial reaction and support of the project.282 The proposals also carefully explained the term 'information system', encompassing patient/provider communication as an essential part of a clinical information system. At the same time, proposals were being altered to reduce the cost of technology required to carry out the projects.283 Some of the proposals included only a single computer to collect and print various reports for both the physician and the patient. Therefore, the proposals emphasized the effect of information and information provision on provider/patient communication, and the method of producing this information was considered irrelevant.284 ' A full analysis of clinic one's information system and the feasibility of alternative IT and IS was conducted in April of 1993 by me and three MBA students. ' Although the second set of proposals included more technology such as patient computerized questionnaires, we soon discovered that the health agencies were also unconvinced about the computer's effect on patient behavior and outcomes. ' I once thought that the information could have been provided by carrier pigeons or a team of graphic designers in the back office producing charts for patients and physicians. If health agencies were unconvinced about the use of computers, we could use any method to produce and deliver information to test its effect on patient outcomes. Appendix A: The SoftHeart Story 191 During this period, I began to study the heart disease and health promotion literature to understand more fully the causal chain between information technology and patient outcomes.285 The literature did suggest that the IT-patient outcome chain was filled with many detours and possible traps that required addressing in our design. In addition, presentations of the proposal to medical groups also suggested that the planned intervention would produce too much change in the organization and creating future implementation problems.286 New proposals were submitted on February 28, August 30, and Oct. 4, 1993 reflecting these changes and views. 9.4. Old and New Environmental Shocks During late summer of 1993, the government announced that hospital one was closing for cost cutting measures. Initially shocked that the project might suddenly die, I received word from the director that Clinic One and other outpatient clinics would remain at hospital one. However, despite government promises, Clinic One was moved to hospital two in early 1994, and the project was pushed to the background as the organization struggled with the move and the new setting.287 In addition, old problems continued to haunt the project. Health agencies continued to reject the proposals. The complexity of the project's IS intervention, which was the result of the criticisms in early proposals, created other doubts about the revised ' This was particularly influenced by my first meeting with my future health promotion advisor on November 23, 1993. ' A presentation on March 4, 1994 before several researchers and physicians not connected with the clinic commented that the change was very large and would involve a massive effort in the clinic. Clinic one was moved into a temporary facility in an old nurses residence, using very small consult rooms located one wing away from the administrative office. Appendix A: The SoftHeart Story 192 IS's ability to exclusively target the experimental group without "contaminating" the control group. Agencies continued to be concerned about the cost of the computers, and the lack of tested support for a system that had not already been constructed. It was a "catch 22": we needed the money to build the system, but the money would not be provided until the system was built. While trying to revise the proposal to satisfy health agencies, the research proposal had now crossed another line unacceptable to a different group. During my proposal defense on March 22 1994, a number of researchers within the MIS department at the my university asked the question, "Why is this MIS research"? By dropping computers from the intervention to deal with the health groups' concerns about cost, I was trying provide an inexpensive method of testing improved information and presentation on patient outcomes and deal with the concerns of cost from the health agencies. At my thesis proposal defense, a number of IS researchers now considered the technological intervention too simple, and were dissatisfied with my focus on meeting the demands of the health setting, and not the demands of advanced IS development and testing. 9.5. Decision to Move Ahead . Fearing that time was short, I began to search for IS design ideas that would satisfy both the MIS and health funding agencies throughout the middle of 1994. I started to develop simple programming add-ons to the information already contained in Clinic One's EasySys software, using my own time and money. To do this, I needed access and user involvement from the clinic personnel to determine how best to access and present Appendix A: The SoftHeart Story 193 the information. Specifically, I targeted physicians, the director, and the coordinator in order to get an understanding of EasySys, and to gather suggestions and commitment to an intrusive change to the clinic's information system. The EasySys software used by Clinic One, provided a number of opportunities for system development. My experience teaching and working with dBase IV and my general knowledge of database design allowed me to dissect the software's architecture. Written in Clipper, a dBase programming dialect, it had been used for many years to collect patient, lab, dietary, and medication information. However, its reporting facilities were limited, its data extraction capabilities were slow and limited, and its source code was not available for modification. Originally, I began using Microsoft Access to test the data connection and presentation capabilities. My previous experience on a project using Microsoft Access provided me with this expertise. However, Access proved to be too slow because it attached itself to DBF files through a translation process.288 DBF files were not native to the program. As a result, I searched through software packages that used DBF files directly. I chose Foxpro for Windows in May of 1994, a dBase dialect that appeared to link directly with the old clinic files, to provide a tool for extending data reporting. Foxpro for Windows also claimed to have a software package that could graph data, a necessary tool The 'database file' (DBF) format is a standard data format for many database applications. Appendix A: The SoftHeart Story 194 for achieving many of the reporting goals.2 8 9 In this respect, I was trying to leverage and capitalize on a resource already available at the clinic. The next task was to learn Foxpro programming. Like most programming languages, many of Foxpro's commands were far removed from the language of the setting and what was wanted from the software. More importantly, it was difficult to determine the general approach to programming in Foxpro. To assist me with this task, I purchased a book that provided important concepts for programming clean, efficient, and maintainable code in Foxpro (Goley 1993). To this day, the structure of the program has been heavily influenced by the conventions outlined in the book. 2 9 0 The difficulty of converting design ideas into programming code, however, was still high. For example, a "browse" window constructed in December of 1995 in scheduling provides read only, edit, and calculated fields for date, time, class name, spots allowed, spots available, and day of the class. Each of these fields has validation checks to ensure that the time and date entered is valid. In addition, it marks with an asterisk those classes of the target patient, and marks with an @ those classes worked by the target staff member. Each time the filters are changed on the side, the schedule window needs to be refreshed with those classes that meet the new filter criteria. Each time the user moves to a new record, the staff list in the edit windows is updated. And finally, the browse This graphing using MS Graph turned out to be incredibly slow (Sep. 17 1994). As a result, I purchased an external graphing program on October 6, which reduced the time for graphing from 30 seconds to 3. The graphing module has formed the backbone of the project. ' The use of PRG (program) files that call SPR (screen program) files created a modular and maintainable design. In addition these PRG files contain the functions called by events in the SPR file, because the book warned against the embedding of code in the objects. It claimed the code was difficult to maintain when embedded in the objects. We will see that this became a problem in the second case study and the use of object oriented programming. Appendix A : The SoftHeart Story 195 window also locks and unlocks the record during editing to allow multi-user access and change to the classes. This code is also supported by additional functions (e.g. funlock) that are run when certain events occur. To reach this understanding of the task, context, and programming language took one year.291 The following is the code for this function: BROWSE FIELDS patmark=IIF(fjatinclass(umessch.tnurnb),''*'V' "):H="" :1 :W=.F. :V=f_unlock(),; stfmark=IIF(f_stfi^ "):H="":1:W=.F.,; timessch.tdate :H = "Date*" :V=f_unlock(),; l_day = LEFT(CDOW(timessch.tdate),2) :R :H="Day",; timessch.tstart :P="@R 99:99" :H = "Strt*" :W=f_whenget(VARREAD()) :V=f_valid("START"),; Umessch.tend :P="@R 99:99" :H = "End*" :W=f_whenget(VARREAD()) :V=f_valid("END"),; timessch.tdescr :H = "Descr*" :V=f_unlock(), ; timessch.tmaxpats :H="Spots*" :V=f_unlock(),; l_spots = (timessch.tmaxpats - timessch.tnumbpats) :R :H = "Open"; WHEN f_showinfo(timessch.tnumb); FOR f_browsefor(); WINDOW w_classes; IN WINDOW w_sched; TITLE "Classes"; NOWAIT; NOCLEAR; NODELETE; NORGRTD With the onus on me to develop something of interest to the clinic, health groups, and IS groups, I began developing prototypes by attaching the new program to the old data, and trying various display and reporting formats. The purpose was to learn what could be done in the Foxpro program while at the same time produce a working version of software. There are new software programs that have appeared since the project began, such as Visual Foxpro and Microsoft Access, that claim many of these language issues are solved by their programs. But given the complexity and specific needs of each context, I am doubtful whether higher level prograrnming language will solve the problem of transforming the problems and opportunities of a context into the software (Brooks 1987). Appendix A : The SoftHeart Story 196 Using EasySys' data files also required effort to understand and interpret the files and fields in the database, and how the data reflected the nature of the clinical setting (Aug. 12 and Aug. 17 1994). The risk calculator was the main focus, because I felt it would provide the 'value added' to the organization and produce information different from what was already collected. The graphing of data also provided another avenue for value-added information presentation. I also began developing a statistical calculator that would explore the significance of correlation between various variables for an individual patient. Al l three were considered 'derived' data from EasySys. 9.6. Prototype Demonstration Sparks Interest and Constraint The presentation of a prototype on September 29th, 1994 began a new period in the project, as users and groups became interested in the software.292 Directors and physicians were excited by the possibilities. The demonstration sparked interest in the capabilities of the program, including the graphing as a teaching tool, the use of a risk calculator to summarize large amounts of information, and the potential to expand the database to collect additional information for research purposes. Because the system was aimed at the physicians and their adoption, the enthusiasm was good news.293 ' At this point, the software was quietly called the "adherence application", reflecting the health promotion research question about information's effect on adherence. ' Many people at the meeting knew about me, but did not have a clear understanding of the research goals until that meeting. I had been working in the background for over 2 years at this point, and it was only now that people were learning about the project. Appendix A : The SoftHeart Story 197 The program also sparked a number of comments and concerns, suggesting that more user involvement was required. These comments indicated diverging approaches and interests within the organization. For example, physicians disagreed on the use of total cholesterol (High Density and Low Density Lipids) in risk calculation, instead of singling out Low Density Lipids (LDL); the bad cholesterol.294 Two, the use of Systolic Blood Pressure (contraction) instead of Diastolic Blood Pressure (relaxation) in the risk calculation raised other eyebrows. Recent literature, explained one physician, suggested that the relaxed blood pressure (diastolic) was a better predictor of heart disease. Three, the automatic generation of risk reports using natural language text produced some major concerns about physician liability and the ability to edit. Four, the Framingham data is based on a population that has previously not had a heart attack, while a number of the patients at Clinic One were "rehab" patients recovering from a heart attack. Finally, the system was not addressing provider administrative problems such as consult letter generation, mailing, and other administrative areas. I also discovered the research group at the prototype demonstration in September 1994. I learned quickly that they were very interested in the project, and their vision of an integrated network linked by telephone connections began to add support and vision to the networking aspect that had been ignored thus far by the project. The first meeting with the group, however, revealed strong demands on SoftHeart for strict data entry, a need for medication modules, strict documentation standards, and a The calculator was based on well established epidemiological data from the Framingham study that had examined thousands of individuals since the 1950s. Appendix A : The SoftHeart Story 198 strong belief in OS/2 as the computer and network operating system (October 5). First, I felt there was an emerging issue of ownership of the software, which to that point had been designed and programmed by me. Second, I felt the group was attaching itself to the intellectual and future ownership of a software product that had been solely my work to that point. Finally, my association with the group fractured a fragile relationship with the first coordinator of Clinic One. 9.7. Conflict Erupts Unknown to me, there had been an on-going conflict between the coordinator and the research group based on a software program developed four years ago by the research group to replace EasySys (CholeSys, a pseudonym). CholeSys's interface and design looked very different from the EasySys, and had strong validity checks of data that required the clicking of buttons in order to clear the screen.295 The purpose of CholeSys was not for administrative ease of use, but for correct data entry for research and patient information integrity. EasySys, on the other hand, had been the sole development project of the coordinator. Using clinic funds, she had worked with a programmer to produce a system that reflected her specific wishes. These characteristics included easy data entry, character fields to enter comments and asterisks to highlight data, key punching navigation through the program, etc. ' The designer and creator of CholeSys worked for the research director, and was a former lab employee. Lab systems are designed to store the name of the individual entering data for every item entered into the system. This provides for responsibility and validity checks on data input. Appendix A : The SoftHeart Story 199 CholeSys, having been written in dBase and transported into Foxpro after encountering software problems in dBase, had several software bugs. When a report from an 'independent' external consultant criticized the program's operation and maintenance, the CholeSys project was halted. Comments by the research group and the coordinator indicated a chronic conflict.296 When the research group associated and joined my project in mid October, the coordinator must have viewed this association as evidence of resurrecting CholeSys. This entire conflict may not have erupted if my project had not seriously affected EasySys' operation. In fact, to ease the programming required, this was a preferred strategy. However, technological constraints with EasySys created barriers to achieving improved information reporting. First, being a stand-alone software package, EasySys locked the database files, preventing other programs from accessing the data while it was in use. Second, every piece of data was stored as a character string.2 9 7 As a result, calculations from the data and graphing required extensive use of functions to convert the character strings correctly. Third, important fields required for complete risk calculation using the Framingham tables were missing in the program. Finally, the coordinator was either unwilling or unable to get access to the original source code from the programmer. As a result, I began to examine EasySys more closely, and started to build EasySys's functionality into my software (Feb. 9, 1995), using look-and-feel 1 The research group commented on poor data entry in EasySys and the coordinator's killing of a good software product (Oct. 23). When discussing the past with the coordinator, comments included "are those guys still trying to push that system"? (Oct. 17). Even calculated values were computed using a calculator and typed into the system. Appendix A : The SoftHeart Story 200 characteristics from both programs. This request seemed reasonable because the coordinator had mentioned earlier that Clinic One had planned to move EasySys into Windows, and an integrated package addressing both input and output would be ideal. The result of these intrusions turned the coordinator's from a hesitant and luke-warm supporter into an unfriendly foe. 2 9 8 At the time, I felt the coordinator's reaction was justifiable given the previous work and time spent developing EasySys and maintaining clinic operations. I also assumed that the coordinator knew the job, and should comment on any part of the project that would adversely affect it. Therefore, I accepted her comments to design the data input interface similar to EasySys. On February 23 1995, I decided to give a presentation of the Lipid Program prototype to the coordinator. I wanted the coordinator to have some input into any changes that may be desired, and to show how I was progressing. The demonstration of the emerging software in Windows went very poorly. Being partially completed, the coordinator criticized the software for missing functions and any slight differences in navigation, including bugs in the navigation in the older program that I had fixed. The coordinator commented that I should not demonstrate the program until it was done, and to stop wasting time. When asked what could be improved in this new version from the Lipid Program, the coordinator stated a fax number could be added to the physician record, and typing months using characters instead of numbers would be preferable.299 ' On February 23,1995, insider reports from one employee suggested that the coordinator did not enjoy my presence, and mentioned that I was causing too much change for the coordinator. ' This seemed very incremental to me at the time. Appendix A : The SoftHeart Story 201 At the same time, the coordinator pointed out various barriers that would influence my project, including a new hospital wide system that may affect the project, and a new 'information' ethics form developed by Clinic One. 3 0 0 Further questioning about these barriers did not reveal what and how these would affect the project. On February 28, the coordinator gave me the new 'information' ethics form, that required researchers and investigators to provide project information before they had access to the clinical data.301 It surprised me that I had been working on this project for over 2 1/2 years, including direct work on the database files developing this new software, and I would need permission to work with EasySys' information in the future. 9.8. Decision to Act Concerns about the coordinator's support for the project, the lack of agreement amongst clinic personnel on key design issues, controversy about the use of treating lipid disorders and medications (Feb. 14 1995), the lack of time and commitment from physicians (Feb. 9), the loss of my laptop in a home robbery (Feb. 8) 3 0 2 , and a funding rejection (March 27) threatened the project's survival. I also received an offer to work on another project that appeared to guarantee usage data by its completion (March 21). My first step was to draft a list of conditions toward my continued involvement in the project (March 21). The conditions included a focus on clinical and light input 300 301 At the time, the coordinator stated that she was mentioning these barriers to ensure the success of the project. A talk with the hospital's ethics lawyer revealed that the coordinator had developed the form within the last few weeks (Feb 22,1995). 3 0 2 The clinic was unable to provide me with any computing resources to work on the program. As a result, I had been using my supervisor's laptop for the last 6 months. In addition, the computer also had patient information on the drives. Luckily, no one could get into the software without knowing a great deal about programming. Appendix A : The SoftHeart Story 202 modules to keep the programming time to a minimum, a suitable start date for implementation (June 1995), equal control with the coordinator, director and myself over any administrative changes, equal ownership of the source code for modification and future sales, and 1/2 hour per week with each physician to discuss the system.303 A meeting was arranged with my two committee members and the physician colleague who had allowed us access to his clinic in the summer of 1992. I mentioned the alternative software project. He commented that the software was a gift to the clinic, and he would not let the project die. He described the coordinator as a secretary; employee of the clinic who should not be determining policy. Unfortunately, he said the lack of leadership at the clinic was jeopardizing the project's success. I then had a meeting with the director of Clinic One on March 22 to discuss my conditions. He said that the coordinator has problems with other people stepping on her territory. He felt that the system failing would be a tragedy after so much work, and would do what was necessary to make it work. He promised that the clinic would be moving into the new offices by end of July/August, that he would try his best to get funding for the computer hardware by that time, and that he would meet with the coordinator. The director did meet the coordinator later on that week (March 29). The director asked the coordinator to get the source code for EasySys, but the coordinator stated it was impossible, and that she supported the position of not allowing access to the source During the presentation, the coordinator was asked by the director about the source code and she responded with sadness and defiance. I believe that the inability of the director to control the coordinator in front of his physician colleagues was an embarrassment and prompted his aggressive manner in dismissing her. Appendix A : The SoftHeart Story 203 code. Her explanation was that at least part of the software program was built on top of another program that was marketed several years earlier, and was proprietary. The director was angered by her response, and when the coordinator asked if the clinic would be better without her, he said yes. On March 29,1 appeared before the entire clinic staff, presented my software and the list of conditions. One physician mentioned that I was being courted by another project, and how the clinic wanted to keep this project. Talk about the benefits of the system toward clinical operations, the potential to earn money selling the software and the 50/50 split in project royalties dominated the presentation and conversation. The physicians met behind closed doors after the meeting, and decided to fire to coordinator.304 9.9. Project Builds Momentum There were many events during this period after the firing of the coordinator that pointed to unlimited growth and development in the project. Many people believed that with the removal of the coordinator, the project was free of restrictive constraints (Mar 31 1995). On April 8, I began restructuring a copy of EasySys' database, with the intention of replacing EasySys with SoftHeart in the future.305 The firing came so swiftly and unexpectedly. A number of personnel mentioned that I was not to blame for the firing. Conflict between the coordinator, a few physicians, and other clinic personnel had been occuring for a number of years. 1 Character fields that contained lab data were converted into numeric fields, thus closing the door on EasySys' future operation in the clinic. Appendix A : The SoftHeart Story 204 At the same time as conflict was brewing between myself, the coordinator and the research group, other groups within the hospital showed an interest in the project. Discussions with the research group suggested a vision of HeartNet linking outreach clinics with Clinic One (Oct. 4 1994). Clinic Two was mentioned on Nov. 10,1994 with our meeting with the hospital's MIS group. The merger between the two clinics was discussed, and by the accounts of personnel in both clinics, SoftHeart appeared to be an important component in uniting the two clinics into a single program (Nov. 10 1994). The hospital's MIS department became interested in the project, both for competitive and cooperative reasons (Nov. 10 1994). Throughout the period from November 1994 to March 1995,1 began to understand more about the IS structure within the hospital, including various systems that appeared as possible replacements or complements to SoftHeart. These included the ADT system (Administrative Discharge Tracking System) and P C A (Patient Clinical Administrative) (April 3), CAREVISION (a clinical system to handle patient data) (May 3), and a system in lab medicine.306 On March 30, the same day as the meeting with Clinic One personnel that was followed by firing of the coordinator, I met the coordinator and the director of Clinic Two. I immediately attracted to the clinic because of its focus on health promotion (exercise, stress reduction, smoking reduction), the integrated and cooperative relations between the staff under the direction of a charismatic cardiologist, and its limited use of computers. Clinic Two appeared to be an ideal organization to develop and implement ' However, I had currently been unable to see these systems and understand their infrastructure to determine whether they were a threat or benefit to the project. Appendix A : The SoftHeart Story 205 SoftHeart.307 A demonstration of the software on April 11 seemed to impress the director of Clinic Two. He commented that SoftHeart would require only a few changes to suit their needs. Given their need for computerized systems to report patient statistics to Hospital Two, however, he would be satisfied with just basic demographics for now. My goal was to produce a limited version of SoftHeart for immediate implementation. Efforts were also being made to obtain funding for the project through various sources. A talk on April 6 with the director of Clinic One revealed that $20,000 with the hospital foundation was earmarked for prevention. On April 11, the director of research and I began work on a proposal for money to build the LipidLink infrastructure. April 13 also began my own movement of the software into administrative areas that had been fully controlled by previous coordinator. That day, patients at Clinic One had been waiting two to three hours to see the physician. Discussions with the head clerk revealed that scheduling and booking was "way too manual". I felt that the software could address both issues, and that the construction of a scheduling system would be ideal (April 25). There was also an opportunity to hire a programmer for the summer, based on an offer by the director of Clinic One. Although initially hesitant to take on the extra load of coordinating the work with a second programmer, I decided that it could be worth the time and effort.308 I met with the student on May 6th, and decided to hire him on a 2 One of the alternatives that my committee and I considered was leaving clinic one and switching to the second clinic. 1 The programmer was a friend of the director's son. Appendix A : The SoftHeart Story 206 week trial basis at the beginning of June. From all perspectives, it appeared that the project had momentum, resources, and unlimited freedom. 9.10. Development Quagmire Despite the coordinator leaving, and the perception that the development would now continue at my own pace and to a conclusion, I began feeling the endless refinement and development that was continuing to overrun the project (Apr. 25 1995). Throughout the period I continually felt exhaustion and worry about the future of the project. I began to realize that a "blank cheque" on development had opened the doors to a software "sinkhole", especially with the research group who were now able to press demands without interference from the coordinator (May 3 95). Expectations of a quick implementation with Clinic Two were soon dashed with a prototype demonstration to the coordinator of Clinic Two and a major list of demands to change the software (May 4 95). Refining the database to include the unique scheduling and structure of Clinic Two also required major changes to the database structure (May 26; June 24). Data could no longer be tied directly to every visit, as patients with Clinic Two came many times with only three major data collection points. It took until July 24 to figure out the best database structure to handle these differences. The ever extending implementation date for the new program combined with a never-ending list of requirements being generated by the clinic threatened the delay and completion of my thesis project. The start date had been pushed to June (Jan 24), increased to July 17 (Mar 30), pushed ahead to August 17 (April 27), later moved to Appendix A : The SoftHeart Story 207 October 15th, 1995 (June 20), and December 18 (Dec. 7). 3 0 9 Given that I had been working on software development for over 1 year and two months by that point, with various earlier dates in the year proposed as starting dates, frustration had begun to set in. Software design and development continued to drain huge amounts of time and resources, despite some initial breakthroughs. A switch from a purely display and presentation program to data input prompted dramatic changes in orientation and software code (Apr. 25). In addition, all the functions converting character data from the EasySys software files needed to be removed and replaced with direct access to the new numeric fields (Apr. 11). Combined with the dramatic software restructuring was the endless list of requirements that continued to pile in from many opposing directions. The backlog included requests for building field level security to record the name of the person entering each field into the database, a need for radical changes to the database structure, getting the physicians to understand, support and eventually use the system, setting up and testing new hardware, integrating Foxpro for Windows into the OS/2 platform, training and listening to clinic personnel, building better medication and physical exam catalogues, and addressing documentation and maintenance concerns. The promised resources and support for the project were nowhere to be found. Furthermore, the early summer weather seemed to cause clinic personnel to lose interest. The student programmer who arrived in June was not provided with a computer and office The actual starting dates did not occur until early 1996. Clinic one moved in early January, clinic two in early February, and the first usage of SoftHeart began in early April 1996. Appendix A : The SoftHeart Story 208 space at the hospital during the first couple of weeks, requiring me to house him at the university with my computer (May 26; May 29). By June 20, three weeks after beginning, the programmer had not yet been paid. Attempts throughout June to get the programmer's wages were met with indifference and forgetfulness by one of the research group's personnel. Finally, after continual phone calls, the programmer was paid on July 6th, six weeks after beginning work. 3 1 0 Loss of key personnel who supported, helped develop, and/or provided key information about the organization and the functions of SoftHeart also affected the project's course. The two coordinators from each clinic, and several clerks from the first clinic left during the course of the project. The second coordinator had a health promotion background, and understood the theories and modules in SoftHeart that could address areas not currently covered by the clinics. One of the clerks in Clinic One had been a key source of information about the clinic and a sympathetic supporter of the project (Aug. 22). A second clerk provided important input into the scheduling and patient modules, and would have been a supportive user of the system during testing and debugging. Al l three resigned during the summer and early fall, forcing us to reconsider and develop relationships with other and/or new individuals to continue development and support implementation. In order to develop the system with more input from users, the programmer and I moved from the university to the hospital on June 27. We were greeted, however, with ' Talks with the research director suggested that while the director of clinic one hired the programmer, the research group had never received any funds to pay for his wages. The lack of coordination and communication was evident. Appendix A : The SoftHeart Story 209 general apathy and lack of time by clinic personnel, suggestions that my thesis would never be finished because of lagging development, and computer crashes. Perhaps the most serious and frustrating shocks were the computer crashes during late June and July (June 28; July 10; July 26; July 27), and the finger pointing and hostility it created between the software group (myself and the summer programmer) and the hardware group (research group).3 1 1 Dealing with OS/2 and new computers purchased by the research group, it was initially difficult to determine the cause of the computer crashes. Being skeptical about the research group's support and use of OS/2 over Windows as the operating system for SoftHeart, I originally attributed the crashes to OS/2. On the other hand, the research group placed blame on me, my external backpack hard drive 3 1 2, and the programmer working with me that summer. The testing of my backpack drive by the hardware company supplying the research group apparently caused a computer crash. However, I was unable to talk directly with them about the cause. I reached the conclusion that the research group and the hardware group were protecting their reputations by blaming me. There were several other conditions that prompted me to consider leaving. Stress was a big factor in my visit to emergency on July 30th after falling down and injuring my head.313 A trip to Washington on August 10 to learn the software used by Empower indicated that funding, resources, and consideration for my needs were better on the 3 1 1 This would lead to a continuing anxiety between the research group's network technician and myself for the next several months. • 3 1 2 The external backpack hard drive attaches to the printer port of a computer, operating as an independent hard drive. 3 1 3 1 am a diabetic, and stress causes instability in blood-sugar control. Appendix A : The SoftHeart Story 210 Empower project. Third, while trying to fix a computer as a favor to a clerk on August 15th, the director of research sarcastically commented that the computer has likely contracted a virus from one of my diskettes.314 Discussion with my committee about my treatment and the offer to join the Empower project from my one advisor prompted me once again to consider switching projects. I reached the conclusion soon afterward that facing spiraling software development time, the lack of input and interest from the clinic personnel, the time and effort expended in fixing and dealing with the virus, an offer to work on the Empower project, and pressure from my thesis committee, I indicated to the clinic that I was leaving the project. On Aug. 30,1 reached the conclusion that apathy had killed the project.315 9.11. Recovery and Slow Growth Toward Early Implementation A meeting with the physician colleague of my supervisor on August 27th began a series of surprised reactions by many personnel in both Clinic One and two. He was surprised that I was leaving, and surprised at some of the causes of my leaving. He had no idea of the struggles with the software, unlimited demands, and problems with the research group. He suggested I send a letter to the clinics outlining what was happening. There was something about the comment that pushed me too far, and resulted in another letter and meeting with my committee. ' During the same period, the summer programmer and I worked furiously to get a completed module together for the two clinics that would at least replace the old lipid software (Aug. 19; Aug. 21; Aug. 25). Being completed, I felt that I was leaving with a limited product close to completion. Since I had hardly received any money for the entire work, I felt only somewhat guilty for leaving. Appendix A : The SoftHeart Story 211 I was surprised to see that many people at the clinic wanted me to stay. The coordinator from Clinic Two took me out for lunch. The new coordinator in Clinic One saw the system as an important component in her future work. A talk with the director of Clinic One yielded surprise and concern over my leaving. The director of the research group was also surprised and confused that I was upset with his group. He asked, "are you mad at the machinery or at us?" Once it was discovered that it was the Monkey II virus 3 1 6 that caused the computer crashes, the project began to settle down. 3 1 7 Discussions with the clinic groups reduced my time with the software to one day per week, requiring the clinic to work more efficiently with my time, and to take responsibility for further software development (Sep. 7). I also joined the EMPOWER project officially, thus providing me with an alternative case site to study software development and usage. Therefore, despite continued problems with commitment to the project from software testing to eventual usage (Oct. 11; Oct. 13), the Empower project's release valve stabilized my need for usage data. The research group also took a strong lead on the project, as my role moved to the background as a consultant and software advisor. This leadership has been important in achieving the viability of SoftHeart away from its designer. The original focus of SoftHeart, however, continues to change from clinical and patient care to research on ' The Monkey II virus is a boot sector virus released in early 1994, that infects the boot sector of a disk. The virus spreads by activation of a floppy disk in the floppy drive, and copies itself onto the hard drive of a computer. This virus then operates in memory, affecting other fresh floppy disks inserted into the computer. The virus eventually destroys the boot sector of the hard drive making it impossible to access the drive. However, future crashes of clinic computers continued for the next 6 months as other floppy diskettes from other sources infected the machines. It wasn't until the IBM anti-virus package was installed on every machine that the occurrences of the crashes decreased. Appendix A : The SoftHeart Story 212 large datasets.318 First, the lack of commitment and resources toward computers and reporting to physicians in consult rooms points to this change in emphasis.319 Second, the focus on implementation in the administrative areas has pointed to the data entry personnel responsible for supporting the research database. And finally, work on capturing admitting information and lab information automatically from the hospital systems is trying to reduce the reliance on internal data entry, which is prone to clerical errors and constraints. General meetings with the clinic personnel indicated the clinic had revitalized its search for project funding, and was interested in implementing the system soon; bugs and all (Sep. 28). One physician mentioned channeling $50,000 from the outreach program into SoftHeart's development because the outreach clinics in the province would be interested in using the software. The server finally arrived on October 17, providing solid evidence that the project was going to move ahead. At the same time as these constraints were placed on the project, the clinics received $30,000 from the hospital foundation, and there was discussion about another $100,000 coming from a drug company interested in the project (Nov. 2, 1995).320 ' This movement towards a research focus was later assured by funding of the HeartNet and SoftHeart project from a drug company interested in drug research. 1 Continually, I was reminded of how the physicians would be unwilling to use the computer in the consult rooms; especially data entry. 1 $80,000 was received from the company two weeks later. Appendix A : The SoftHeart Story 213 The clinic also was considering hiring a programmer based on my recommendation (Dec. 2 1995).321 This would greatly reduced the need for my own programming. In addition, despite the initial training period, it meant that I would eventually be able to leave the project by releasing the clinics' dependency on my expertise. Talks turned to methods of implementation (Jan 8, 96; Feb. 14), and a move to the new clinic location occurred in early January.322 SoftHeart went through an early implementation effort, working with clerical staff to begin the transition from EasySys to SoftHeart. Some interesting surprises emerged during on-the-job training and readjustment of the software to deal with work issues. Gaining an initial foothold in a busy and chaotic environment by April 9th has been challenging and frustrating at times (Jan. 30). Initial bugs and missing functionality required by the administrative group prompted early cries for dumping the program and sticking with EasySys. In addition, the need to integrate the system with the wishes of the hospital's MIS and admitting groups has been difficult both for the software and the clinic human resources required (Jan 31 96; Feb. 28 96) during implementation. However, quick response times and relatively easy identification of software problems by myself and the programmer provided assurance to users that the software can work and will be supported (Mar 6; Mar 7). The results so far have been encouraging. Many personnel at the clinic are now referring to SoftHeart as essential for future survival This programmer was the same programmer who I was working with on the Empower project. The new area looked very impressive, and was fully wired with fibre optic cable for a computer network. Appendix A : The SoftHeart Story 214 against funding cuts. SoftHeart appears to be becoming essential for allowing new opportunities in clinical, administrative, and research tasks. 9.12. What Lies Ahead SoftHeart is far from being completed, and despite its early success, still has a number of known and unknown hurdles to overcome before it becomes 'infused' and 'institutionalized' into the clinic. External threats to its survival from the hospital's MIS and lab medicine groups still remain, and the technical stability of both SoftHeart and HeartNet have not fully been attained. Technically and resource-wise, however, the project has the capability to thrive. Additionally, there is the question of SoftHeart's focus on either research, administration or clinical care. This issue has been central in understanding the reactions to the prototype in September 1994, the conflict over EasySys during March, the software explosion in late summer of 1995, and the implementation in April 1996. SoftHeart's focus began with a clear direction toward patient care. Using the same software, SoftHeart is now being implemented and further developed towards research and administration.323 1 This may be a step in the wrong direction, may simply automate and increase computing power in areas further removed from patient care, and may produce little impact on patient outcomes. Appendix B - The E M P O W E R Story 215 10. Appendix B: Events in the Development of EMPOWER This appendix reports on the various events during the development of Empower, providing the raw data for Chapter 5. These events will be discussed within various process stages of the project. The process stages include project emergence, getting ready, Pandora's box opens, squeezing the most from Toolbook and EMPOWER, and visions of a new software constrained by resources32A 10.1. Project Emergence My first exposure to the Empower program and the project director was at a meeting on Nov. 23 1993.3 2 5 The director seemed interested in my work at the two clinics, and I was interested in what I called the 'means-ends' chain model of health promotion planning that was used in Empower for planning breast cancer interventions. Having an interest and need to learn more about the health promotion field, I began to get involved in various projects with the project director. During mid January 1994, I was called by the project director to discuss a copyright issue with the Empower software. Having worked recently on a copyright study, I said I could help. I learned from the project director that the EMPOWER software had been Note that these stages, although presented sequentially, were overlapping to some degree. I originally thought the software was called ENABLER. Appendix B - The E M P O W E R Story 216 developed by a US company, with the director and two colleagues serving as advisors.326 The director was interested in building a Canadian version of the software, and was negotiating with the US company on the division of royalties from any future sales of derivative versions. Questioning the director, I found that he and his two colleagues had been paid for the work they had provided, and thus would have to pay royalties to the company from any derivative products produced in Canada. In early February, I met with the director and a sales representatives from statistics Canada to discuss various methods of obtaining data from Statistics Canada's on-line service. The purpose was to explore methods of supplying specific epidemiological data to users of Empower without requiring us to collect and store the data.327 I also began taking a course with the project director about his planning theory and model in January of 1994. During the summer, I was involved in a workshop focusing on the planning model and the Empower software.328 In addition, I began working on a project with the director involving the collection of information for another project involving heart health, and the development of an information system to assist in the collection and measurement of community health 329 programs. ' The one colleague would later join the US company as a vice president in charger of a division that would develop and market EMPOWER and other information technology products.. ' At the time, we were focusing on redeveloping Empower for heart disease prevention and planning, because a proposal