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


831-ubc_1996-147355.pdf [ 16.71MB ]
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

Full Text

THE INTERACTION B E T W E E N CONTEXT A N D TECHNOLOGY DURING I N F O R M A T I O N 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 I N P A R T I A L F U L F I L M E N T OF T H E R E Q U I R E M E N T S FOR T H E D E G R E E OF D O C T O R OF PHILOSOPHY in T H E F A C U L T Y OF G R A D U A T E STUDIES T H E F A C U L T Y OF C O M M E R C E A N D BUSINESS A D M I N I S T R A T I O N Department of Management Information Systems  We accept this thesis as conforming - to the required standard  T H E U N I V E R S I T Y OF BRITISH C O L U M B I A J U L Y 1996 ®Mike Chiasson, 1996  In presenting  this  degree at the  thesis  in  University of  freely available for reference copying  of  department  this or  partial fulfilment  of  British Columbia,  I agree  and study.  thesis for scholarly by  publication of this  his  or  her  Department of The University of British Columbia Vancouver, Canada  requirements that the  I further agree  purposes  representatives.  may be It  thesis for financial gain shall not  permission.  DE-6 (2/88)  the  is  that  for  an  advanced  Library shall make it  permission for extensive  granted  by the  understood be allowed  that without  head  of  my  copying  or  my written  11  ABSTRACT 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.  Ill  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. research and practice are discussed.  Implications for  iv T A B L E OF CONTENTS ABSTRACT  "  TABLE OF CONTENTS  iv  LIST O F T A B L E S  viii  LIST O F FIGURES  x  ACKNOWLEDGEMENT  xii  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.  9  STAGES AND DIMENSIONS OF SYSTEM DEVELOPMENT  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 2.4.3. Organizational Imperative  16 • 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 2.5. CHAPTER SUMMARY  :  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  46  48  45  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 T W O 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. O U R RESPONSE  76  4.5. O L D AND N E W 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 M O M E N T U M  92  4.11.  DEVELOPMENT QUAGMIRE  95  4.12.  RECOVERY AND SLOW GROWTH TOWARD E A R L Y IMPLEMENTATION  96  4.13.  W H A T LIES A H E A D  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 R E A D Y  115  5.4. PANDORA'S Box OPENS  119  5.5.  124  SQUEEZING THE M O S T FROM TOOLBOOK AND E M P O W E R  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. H E A L T H FUNDERS SKEPTICAL  189  9.3. OURRESPONSE  190  9.4. O L D AND N E W 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 M O M E N T U M  203  9.10.  DEVELOPMENT QUAGMIRE  206  9.11.  RECOVERY AND SLOW GROWTH TOWARD E A R L Y IMPLEMENTATION  210  9.12.  W H A T LIES AHEAD  214  Vll  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.  218  PROJECT DIRECTION, DECISION AND ORGANIZATION  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.  237  HEART DISEASE EPIDEMIOLOGY  11.3. THEORIES OF H E A L T H BEHAVIOR  241  11.4. T H E HEALTH CARE CONTEXT  246  11.5. H E A L T H 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. H E A L T H 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.  309  LINKING PROCESSES TO THE LITERATURE  V1H  LIST OF T A B L E S T A B L E 2-1: STAGES AND DIMENSIONS OF SYSTEM DEVELOPMENT  9  T A B L E 2-2: ACTIONS AND PRODUCTS OF DEVELOPMENT STAGES - COOPER & Z M U D (1990)  10  T A B L E 2-3: REVISED TECHNOLOGICAL AND CONTEXTUAL DIMENSIONS OF SYSTEM DEVELOPMENT.  11  T A B L E 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  T A B L E 3-1: DEVELOPMENT ENVIRONMENT  51  T A B L E 3-2: CHARACTERISTICS OF A PROCESS  60  T A B L E 4-1:  PROCESS STAGES IN THE DEVELOPMENT OF SOFTHEART  ,  64  T A B L E 4-2:  PROCESSES IN PROJECT EMERGENCE  T A B L E 4-3:  PROCESSES IN H E A L T H FUNDERS SKEPTICAL  T A B L E 4-4:  PROCESSES IN O U R RESPONSE TO HEALTH CRITIQUES  78  T A B L E 4-5:  PROCESSES IN THE ENVIRONMENTAL SHOCKS STAGE  80  T A B L E 4-6:  PROCESSES IN THE M O V E AHEAD STAGE  83  T A B L E 4-7:  PROCESSES IN THE INTEREST AND CONSTRAINT STAGE  87  T A B L E 4-8:  PROCESSES IN THE CONFLICT STAGE  90  T A B L E 4-9:  PROCESSES IN THE DECISION TO A C T STAGE  92  •  74 :  76  T A B L E 4-10:  PROCESSES IN THE M O M E N T U M STAGE  94  T A B L E 4-11:  PROCESSES IN THE DEVELOPMENT QUAGMIRE STAGE  96  T A B L E 4-12:  PROCESSES IN THE RECOVERY STAGE  98  T A B L E 4-13:  PROCESSES IN THE FUTURE OF SOFTHEART  100  T A B L E 4-14:  SUMMARY OF PROCESS TYPES IN PROCESS STAGES  101  T A B L E 4-15:  ISD RESEARCH CATEGORIES WITHIN PROCESS STAGES  102  T A B L E 4-16:  EXAMINATION OF SHARED PROCESSES  104  T A B L E 4-17:  NUMBER OF TIMES O N E PROCESS T Y P E IS FOLLOWED ANOTHER T Y P E  105  ix T A B L E 4-18:  NUMBER OF TIMES A SERIES OF O N E PROCESS TYPE WAS TERMINATED BY ANOTHER T Y P E  106  T A B L E 5-1:  PROCESS STAGES IN THE DEVELOPMENT OF E M P O W E R  108  T A B L E 5-2:  PROCESSES IN THE EMERGENCE STAGE  115  T A B L E 5-3:  PROCESSES IN THE "GETTING READY" STAGE  118  T A B L E 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  T A B L E 5-6:  PROCESSES IN "VISIONS OF A N E W E M P O W E R " STAGE  128  T A B L E 5-7: SUMMARY OF PROCESS TYPES IN PROCESS STAGES T A B L E 5-8: I S D RESEARCH CATEGORIES WITHIN PROCESS STAGES  129 :  130  T A B L E 5-9: EXAMINATION OF SHARED PROCESSES  131  T A B L E 5-10:  NUMBER OF TIMES APROCESS T Y P E WAS FOLLOWED BY ANOTHER T Y P E  132  T A B L E 5-11:  NUMBER OF TIMES A SERIES OF O N E T Y P E WAS TERMINATED BY ANOTHER T Y P E  132  T A B L E 6-1:  TECHNOLOGICAL IMPERATIVE SUMMARY FROM CASE O N E AND CASE T W O  135  T A B L E 6-2:  ORGANIZATIONAL IMPERATIVE SUMMARY FROM CASE O N E AND CASE T W O  139  T A B L E 6-3:  EMERGENT PERSPECTIVE SUMMARY FROM CASE O N E AND CASE T W O  143  T A B L E 6-4:  SOCIAL TECHNOLOGY SUMMARY FROM CASE O N E AND CASE T W O  148  X  LIST OF FIGURES 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  FIGURE 2-5:  SOCIAL TECHNOLOGY THEORY  •.  28 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  FIGURE 5-1:  E M P O W E R PROGRAM STRUCTURE  Ill  FIGURE 6-1:  INTEGRATED M O D E L OF CONTEXT AND TECHNOLOGY INTERACTION  154  ;  69  FIGURED-l: P R E C E D E / P R O C E E D MODEL  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 :  271  LIPIDS EDIT PANEL  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:  L O C A L M A P P A G E OF THE SITUATION ANALYSIS  279  FIGURE F-5:  SHARED VISION STATEMENT  280  FIGURE F-6:  R O L E IN THE PROJECT  281  FIGURE F-7:  T H E PROGRAM G O A L PAGE AND CONSULT-ON-TAP RESOURCES  282  FIGUREF-8:  " W H Y " HELP  283  FIGURE F-9:  OTHER REFERENCE HELP  284  FIGUREF-10: D A T A F I L E S  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  ACKNOWLEDGEMENT 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.  1  Chapter 1: Introduction  1.  Introduction 1.1. Description of the Thesis  Information systems development (ISD) involves a process of interaction between 1  technology and context* that results in the initiation, creation, and early implementation of an 2  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 elementsfromtechnology 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 events are extracted from the cases to uncover 4  processes between technology and context during stages of development (Newman & Robey 5  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 and technology on context during information systems development (ISD).  4  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.). appropriate for studying complex social phenomena:  Process theories are considered more  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). With respect to a second motivation, the deployment and diffusion of IT can 7  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 widelyfromnot-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 bidirectional 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 E M P O W E R over a twelve-month period, providing a substantive theory of the E M P O W E R 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 screensfromSoftHeart (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  2.  8  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 Initiation Adoption Adaptation Acceptance Routinization Infusion  User  X X  Organization  Task  Technology  Environment  X X  X X X  X X  X  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 Initiation Adoption  Adaptation Acceptance Routinization Infusion  Actions Search for potential solutions to a problem. Rational and political discussions gain organizational backing for the project. System is developed, installed and maintained. Employees willing to commit time to the application. IT becomes a normal part of operations. IT enhances effectiveness and the IT begins to support higher level tasks.  Products Match of potential solution with a problem. Commitment of resources and time.  A working set of IT. Widespread use of IT throughout the organization. Transparent IT that is embedded in the organization 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  Organization  Task  Technology  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 that the technology provides to the organization.  12  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.  11  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  2.4.  13  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 1980 ; Kling & Scacchi 1982 ; 12  13  Markus 1983 ; Van De Ven 1986 ; Markus & Robey 1988 ; Hirschheim & Klein 1989 ; 14  15  16  17  Burton 1992 ; DeSanctis & Poole 1994 ; Myers 1994b ; Thomas 1994 ). 18  19  20  21  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:  12  Kling discusses systems rationalism and segmented institutionalism.  13  Kling and Scacchi discuss discrete entity and web models of computing.  14  Markus' theories include system driven, people driven, and two interaction theories: political and socio-technical.  15  Van De Ven's theories include technology-driven, customer or need-driven, and simultaneous coupling.  16  Markus & Robey include technological imperative, organizational imperative, and emergent perspective.  17  Hirschheim & Klein focus on the approach and assumptions of the developer toward the organization including functionalist, integrationist, radical structuralist, and neo-humanist.  18  Burton critically analyzes technological determinism and societal determinism.  19  DeSanctis & Poole include decision making, institutional school, and social technology.  20  Myers includes the technology acceptance, organizational change, and organizational problem-solving involving mutual adaptation.  21  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  Organizational Imperative Theory (OI)  Context to Technology.  Emergent Perspective Theory (EP)  Causality is complex between context and technology.  Social Technology Theory (ST)  Social practices moderate the effect of technology on context.  Context rationally chooses, uses, and/or develops technology to suit its needs. Technology is composed of parts that carry social meaning. The result of context-technology interaction is explainable but unpredictable. Both context and technology act as constraints and/or enablers  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. Designers implement technology identified by top management and/or integrated views of users. Developers' and users' ideas and visions determine the criteria for selection, development approaches, the choice, the choices within the choice, and use.  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.  M y 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 1987 ; Gurbaxani & Whang 1991), the "internef * (Rheingold 1993) computers (Franklin 23  2  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 systems , interorganizational systems '', expert 26  2  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, maturationsocialization, 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 principlesfromall 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  systems , and executive information systems , (Johnston & Vitale 1988; Sviokla 1989; 29  29  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.  Chapter 2: Literature Review  19  Figure 2-3: The Organizational Imperative  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/technologyfit(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 and organizational dimensions. technology link.  20  PD&UI focuses on the user, developer/supplier, and  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.  21  Chapter 2: Literature Review  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) diagrams , Object Oriented Design , and Data Flow Diagrams are 33  34  35  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!taskfit,and information/taskfit(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) systems , and their adoption and 37  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 M R P which is more appropriate for continuous production.  Cooper &  Zmud's (1990) results confirmed that adoption of M R P 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/taskfit,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" approaches (Kling 1980; Hirschheim & Klein 38  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).  A l 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  Andfinally,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.  41  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.  27  Chapter 2: Literature Review  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 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.  43  Discrete-entity models examine information technology in isolationfromthe context that surrounds its usage and operation.  44  Hirschheim & Klein (1989) develop four paradigms of system development based on ontology (objective/subjective) and conflict (conflict/integration). The TI and OI fit into theirfunctionalist category where the view of the developer is that the organizational mission and goals are integrated and that the ontology is objective.  45  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), and implementation approaches. The following 46  figure illustrates the emergent perspective theory: Figure 2-4: The Emergent Perspective on Technology and Context  Action Frontier weak or non-existent  ^  Tj  m e  of action over time  Thomas' (1994) phrase for the second level choices made after a software platform is chosen.  B  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" and technology focus is criticized by 48  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)  49  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" perspective. Alternative 51  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" versus "discrete" models, and claim that 53  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  51  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.  52  "Integrative" implies that the organization is integrated in its views, but the views are subjective and can be altered.  53  Web models focus on the many contextual factors that develop, influence, support and sustain IT and IS within a setting.  Chapter 2: Literature Review success.  32  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 hermeneutics  54  and phenomenology  55  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".  55  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,fromexperience 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 environment around technology have been categorized as more turbulent, 61  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; and correctness subject to verification (Brooks 1987; Turner 1987; 62  Forester & Morrison 1990 ; Harrington 1991; Landauer 1991; Gibbs 1994; Keil 1995). 63  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 emergefromlucky 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 1995 ). 66  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.  68  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. technology development.  69  This emergence of technology for a task is the norm in  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 D e V e n (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 organizational learning called "learning by doing" (Carrol & Mack 1984).  40 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. A n 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)  41  Chapter 2: Literature Review  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 c o m p o s e d of technology, organization, environment, and developers/suppliers Time Organization shifts somewhat unpredictably to intermediate action frontiers created by organization a n d c h a n c e Final Action Frontier planned a n d unplanned  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 between  technology  and  production  (technical rationality), while  relationship  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  technologies , Thompson provides various propositions about the proposed fit between core 72  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  73  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  72  Intensive technologies are the best definition of the core technology used in hospitals.  73  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, discusses the potential for IT either to automate or to "informate" work. the displacement of human labor, and is not unique to IT.  75  74  Automation causes  "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 M R P system violated Plant One's power as the lead plant in the production process feeding Plant Two, while Plant Two accepted the  74  Pulp and paper, telecommunications, dental claims, stock and bond transfer, bank, and pharmaceutical companies,  75  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 activities  76  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. technology perspective.  Adaptive structuration research falls within the social  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 Mutually Exclusive Equal Validity Special Case Association  i Explanation 1 Theory 01 explains the technology-context process ! better than theory TI, EP, or ST. | Theory ST and theory 01 explain different aspects of | the process. | Theory ST is a special case of Theory EP. 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 Technological Imperative Organization Imperative  Problems with Unidirectional Theories Emergent Perspective  Social Technology  Research Areas Technology Systems Strategic Information Systems Planning Structured Design and Analysis Task-Technology Fit Integrative and Functionalist Forms of User Involvement Technology Divergence Evidence Against top-down Planning Conceptual Problems Designer's View Alternative Views Predicament of Design Evolution of Technology Political forms of User Involvement Innovation 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  3.  48  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" and other methods (Markus 77  & Robey 1988; Eisenhardt 1989; Lee 1989; Y i n 1994 ; Sabherwal & Robey 1995). These 78  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 Y i n (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.  Using the "information-gathering" method, a  79  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). strategically to extend the emergent theory (Yin 1994).  Case Study Two was then chosen 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  Case One Four P r o c e s s 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. provided below.  A summary of the case studies is  Chapter 3: Research Question and Methodology  51  Table 3-1: Development Environment Dimension/Case Setting of development Setting of usage Time Frame Software/Technology Purpose Task Product IS/IT Concepts Infrastructure Project Team  Software Tools IT/IS Starting Point  Development Approach User Involvement My Role  Case 1 Two heart disease outpatient clinics - hospital setting. Two heart clinics July 1992 to March 1996 Electronic patient record (SoftHeart) Diagnosis, treatment, and patient education Clinical, administrative, and research Tailored software to setting Database - executive information system Computer network LipidLink group (network infrastructure), two programmers, interviews with clinic personnel. Foxpro database, graphics server tool, Windows, and OS/2 DOS standalone patient record in Clipper with 4 Modules (lab, patient, physician, medications) Bottom Up Design, development, deployment Designer/Developer/Programmer  Case 2 Health promotion department on campus. Two Canadian communities. January 1995 to March 1996. Health promotion planning tool (EMPOWER) Teach and assist planning Develop complete health promotion plans Generic software to be diffused to many settings Planning tool with decision support resources. Standalone Health promotion researchers, programmer  Toolbook and Windows Untested US version of software Theory and research model. Some development and deployment 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 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.  59  Chapter 3: Research Question and Methodology Figure 3-2: Ladder of Inference Four Process Theories X  Chapter 6 Tl  EP  Ol  ST  Chapter 2 Tl Research  Chapter 4 and 5  Appendix A and B  Ol Research  EP Research  ST Research  Ladder of Inference  Processes  Events  Time  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; Y i n 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 Contextual Dimensions and/or Contextual Level Technological Level and/or characteristics Time  j Example ) Developer and software supplier x. j System Functionality | 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; Y i n 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.  63  Chapter 4: Processes in the SoftHeart Case  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 Project Emergence Health Funders Skeptical Our Response Old and New Environmental Shocks Decision to Move Ahead Prototype Presentation Sparks Interest and Constraint Conflict Erupts Decision to Act Project Builds Momentum Development Quagmire Recovery and Slow Growth to Early Implementation What Lies Ahead  Time Period April 1990 - August 1992 January 1993 - March 1993 April 1993 - October 1993 August 1993 - March 1994  Stage Initiation  April 1994 - August 1994 September 1994 - October 1994  Adoption & Adaptation  October 1994 - February 1995 February 1995 - March 1995 Nov. 1994 - April 1995 March 1995 - August 1995 August 1995 - Present Present  Adaptation, Acceptance and Routinization Routinization and Infusion  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 Department; a pseudonym).  65  The Heart Health Department (HHD) is funded by both the  hospital and a heart center that supports heart disease clinics within the hospital. H H D 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 physicians.  Approximately half of the patients see one of the dietitians as required.  66 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 atherosclerosis research, focused largely on genetic 89  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 sixweek 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. The SoftHeart software 90  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" (2), side effects (1), and quality of life (1) information. Administrative information is 92  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.  69  Chapter 4: Processes in the SoftHeart Case 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  Staff  Side Effects  Effect Catalogue  -PI  Stress Test Patient  Classes/Times  Event Family History  Drug  Presc Medic Drug Catal.  Diagnosis Catalogue  Diet/Exerci &e — Food Catal.  Medical History  Phys Exam  Smoke, B P , Alcoh  r Medical History Catal  E  x  a  m  Catalogue Lab  Qual of Life  Range Catalogue  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.  Appendix G provides a programming guide to SoftHeart.  93  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 care, information systems, medicine, and health economics.  72  Particularly important in the  project's initiation were the goals and interests of the developer (Schon 1983; Turner 1987; 94  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" (Van De Ven 1986; Brooks 1987; Hirschheim & Klein 1989; King, 96  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 97  (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 (Turner 1987; Attewell 1992; Thomas 1994). 100  Early proposals fused the interests of the different groups. The proposals focused on information "framing" and multimedia computers, and its effect on providing clear risk and 101  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 ( K i m & Michelman 1990). 103  The following table outlines the important processes in the project emergence stage. Table 4-2: Processes in Project Emergence Description  Theory  Technological Level Project conception  Developer Background  EP  Opportunity  EP  Project conception  Framing and multimedia proposals  OI/TI  Project conception  Time Jan 1990 to July 1992 July 1992 to Sep. 1992 July 1992 to Sep. 1992  Type of Interaction Interest and experience  Stakeholders from Context Developer  Interest and opportunity  Developer, committee, physician Developer, committee, physician  Cementing interests.  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 (Latour 1987; 1994). They doubted the ability of "framing" 104  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. 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.  1  Chapter 4: Processes in the SoftHeart Case provider and the patient  105  75  (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 107  (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  108  (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 (Markus 1981; Markus 1983). 109  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  Funders Skeptical  EP/TI  Questioning computer and framing  EP/ST  Technological Level Project Conception, infrastructure  Time  Project Conception, data elements  Feb. 1993 Doubt  Jan. 1993  Type of Interaction Surprise and struggle  Stakeholders from Context Developer, health agencies, committee 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 (Markus 1981; Kling & 110  Scacchi 1982; Latour 1987; Orlikowski 1992b; Van De Ven & Polley 1992). The proposals also removed costly computing technology and focused on printed reports ( F r a n z & Robey m  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). 111  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 (Ives & Olson 1984; Baronas & Louis 1988). The purpose was to understand clinic 112  one's current systems (Earl 1989), and to promote developer learning (Newman & Noble 113  1I4  1990). A structured analysis and system design document was produced (Coad & Yourdon 115  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  116  (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 (Boland 1985, 1990). 117  The following table summarizes these processes:  112  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).  113  The purpose was to identify strategic aspects, and to determine what IT and IS already existed in the clinic (Earl 1989).  114  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).  115  Object oriented analysis (Coad & Yourdon 1991), and Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ER) (Kendall & Kendall 1992) were produced.  116  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).  117  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  Larger IS interventions with fewer computers  ST/EP  Consult staff more closely  01  System objectives and functionality  Feb. to Oct. 1993  Interview and discussions  Learning health promotion and patient education  OI/EP  System objectives  Feb. 1993 to Feb. 1994  Learning  4.5.  Technological Level System objectives and infrastructure  Time Feb. to Oct. 1993  Type of Interaction Revising and questioning  Stakeholders from Context Developer, committee supervisor, thesis committee Developer, clinic personnel, M B A students Developer  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 (Dutton 1981; Lyytinen & Hirschheim 1987). 118  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  119  (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  120  (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  121  (Markus 1983; Orlikowski & Robey 1991). The constraint influenced the course of  the project because of the developer's need for IS research material (Dutton 1981). 122  The following table summarizes the processes in the environmental shock stage:  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).  1  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 Project conception  Time  Hospital One closes  EP  Funders continuing skeptical MIS' need for advanced computer study  EP/ST  Infrastructure  Jan - Mar 1994  EP/ST  Infrastructure  March 1994.  Jan - Mar 1994  Type of Interaction Surprise, doubt and confusion Surprise and struggle Struggle  Stakeholders from Context Developer, Clinic One, government Developer, committee, health agencies 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 (Earl 1989). In addition, the developer hoped these 123  "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 (Markus 1983; Van De Ven 1986; Basalla 124  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 125  (Brooks 1987; Turner 1987; Thomas 1994). Costing only $135 dollars, the package could  be discarded if it failed to meet current and future needs (Schon 1983; Landauer 1991). 126  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 Champy 1993).  128  (Carrol & Mack 1984; Van De Ven & Polley 1992; Hammer &  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 (DBFfilesetc.) (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. 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  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  130  (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  131  (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  132  (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  133  (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 1992).  136  135  (Weitz 1990; Orlikowski & Robey 1991; DeLone & McLean  The following summarizes the processes during this stage:  Table 4-6: Processes in the Move Ahead Stage Description  Theory  Add-ons to EasySys software  EP/OI/ ST  Selecting software platform. Learning the Foxpro software  EP  EP/OI  Technological Level Infrastructure, program, processing, reports, interface Infrastructure, program  Type of Interaction April 1994 Learning and understanding  Stakeholders from Context Developer, Clinic One personnel  May 1994.  Search and comparison  Infrastructure, program, processing, interface, display, data structure Interface and data  June 1994 to June 1995  Learning, frustration, reading, learning  Developer, software suppliers Developer, suppliers, textbooks  July 1994 to present  Creation and reaction Value added functions and project positioning. Learning, understanding, addressing issues.  Time  Prototyping approach adopted. Focus of risk calculation and graphing  OI/EP  01  Functionality and interface  August 1994.  Learning about medical and health promotion  ST/OI  System objectives and functionality  August 1994 to present.  Developer, clinic personnel. Developer, software.  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. were excited about the project  137  (Newman & Noble 1990).  138  Clinic personnel  In addition, the project  exposure created an understanding of the SoftHeart project amongst clinic personnel, and sparked involvement (Ives & Olson 1984; Baroudi, Olson, & Ives 1986; Baronas & Louis 139  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).  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).  1  ' Complexity of design illustrated by the disagreement over theriskcalculator (Nadler 1982). Context "talks back" about theriskcalculator, 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 1977).  14I  (Bostrom & Heinan  The developer's 'scientism' view of ISD was beginning to change  142  (Klein &  Lyytinen 1985; Boland 1987). The diversity of these wants and desires also created a dramatic expansion and stretching of the SoftHeart concept  143  (Van De Ven 1986). Each group saw the technology  as providing something for its specific needs, falling roughly into clinical, administrative, and research purposes  144  (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). !  1  1  "Scientism" focuses only on technology development and deployment, and is criticized in the literature (Klein & Lyytinen 1985; Boland 1987). The management of the core concept is important in innovation (Van De Ven 1986). 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 Orlikowski & Robey 1991).  147  (Kling 1980; Markus 1983;  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 awayfromlaborious 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 Software functionality  Time  Presentation of Prototype  EP  Barrage of user suggestions  EP  Functionality, interface, reporting  Sep. 1994 to present  Discovery and joining of research group to LipidLink  EP/ST  System functionality, infrastructure, input, processing, data structure, program  Oct. 1994  Sep. 29 1994  Type of Interaction Generate interest and direction User Involvement and struggle to integrate Confusion, Learning, and painful learning  Stakeholders from Context Users, Developer, Task, organization Developer, clinic personnel 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  148  (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 innovationfrominside the organization was rejected by powerful forces maintaining the status quo (Thomas 1994).  Chapter 4: Processes in the SoftHeart Case freedom to control her data entry work  149  88  (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  150  (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  15  lyytinen &  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 (Earl 1989). 152  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 (Turner 155  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 demandsfromuser 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 Project conception  Time  Discovery of previous software failure Problems with EasySys  EP/ST  Starting to incorporate legacy systems Conflict  Type of Interaction Oct. 1994 Surprise and bitterness  ST/OI  Data management, data elements  Oct. to Dec. 1994.  OI/TI  Interface, display, input, reporting  Jan 1995 to present  EP  Functionality, infrastructure, interface, input  Jan 1995 to March 1995  Frustration, need to move to new software Conflict  Time consumption and exhaustion  Stakeholders from Context Research group, developer, coordinator Developer, coordinator, old software Developer, coordinator, organization Developer, coordinator, 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 failing to achieve development goals  156  91  (Lyytinen 1987; Lyytinen & Hirschheim 1987;  Hirschheim & Newman 1991; Myers 1994a).  Having received an offer to study the  E M P O W E R project earlier in the week, the developer now had the leverage for action 157  (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  159  (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. requested the EasySys's source code from the coordinator.  Later that week, the director The coordinator's refused to  contact the programmer, leading to a confrontation between her and the director (Markus 160  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 gainfromSoftHeart, 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 Harrington 1991).  161  (Markus 1983;  162  The following summarizes the processes involved in this stage: Table 4-9: Processes in the Decision to Act Stage Description  Theory  Organizational aspects causing project failure List of demands given Director confronts coordinator for the source code Presentation leads to firing  EP  Technological Level Project direction  Time Jan to March 1995  Type of Interaction Interest and worry  EP  Project continuation  March 22  Ultimatum  EP  Project setting  March 23  Conflict  EP  System goal/objective, system functionality  March 27  Force  Stakeholders from Context Developer, environment, clinic personnel Developer, director, coordinator Develop and coordinator  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  163  (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  164  (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  165  (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 differentfromHospital 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). 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).  1  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  166  (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 167  (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  Hospital groups become interested Joining of Second Clinic  ST/EP  Decision to move into Administrative Areas Search for Funding and Resources  OI/EP  OI/ST  ST  Technological Level Functionality, infrastructure  System functionality, infrastructure, data structure, program System Functionality  Infrastructure  Time  Type of Interaction Nov. 1994 Cooperative to present and competitive ideas March 30, High 1995 expectations, new ally  Stakeholders from Context Developers, hospital funding groups, MIS  April 25, 1995  Strategic and assistance  Developer, clerks  April 6, 1995  Optimism  Developer, research director, director of Clinic One  Developer, users in Clinic Two, environment  ' 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 fullscale 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  169  (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 (Dutton 1981; Kling & Scacchi 1982; Lyytinen 170  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 pressuresfromvarious 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 crashesfractureda 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 (Markus 1983; Attewell 1992; Keil 1994). 171  The following summarizes the processes in involved in this stage: Table 4-11: Processes in the Development Quagmire Stage Description  Theory  Explosion In Requirements Loss of Key Personnel  EP  Virus attack  EP  Threat to Quit  ST  EP  Technological Level All levels  Functionality, infrastructure, program, interface, data System goal/objective, infrastructure All levels  Time  Type of Interaction Optimism, confusion, complexity Surprise and sadness  Stakeholders from Context Users, Clinic One and Two, developer Users, environment, organization  June to Sep. 1995  Confusion and frustration  August 20, 1995  Desperation and frustration  Users, developer, organization, environment Users, developer, organization, environment  May to August 1995 March to Sep. 1995  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 (Markus 1981; Orlikowski & Robey 1991). 172  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 (Gibbs 1994). 173  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 (Kidder 1981; Basalla 1988; 175  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  176  (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). 173  174  Technical problems were identified and new safety strategies were constructed (Gibbs 1994).. 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 otherfreshfloppy disks inserted into the computer. The virus eventually destroys the boot sector of the hard drive making it impossible to access the drive. Protectionfromthe virus required anti-virus software, and "safe" computer practices.  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 & ' Petroski 1994). Institutional learning and competence for institutionalizing SoftHeart away from the developer began (Attewell 1992).  175  l  176  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  177  (Argyris, Putnam, & Smith 1985; Van De Ven & Polley 1992; Attewell 1992),  mismatches between technology and task early conflict  179  178  (Cooper & Zmud 1990), misunderstanding and  (Markus 1983), and technical bugs that created user concerns and weakened  confidence (Henderson & Kyng 1991; Wynn 1991). 180  The following summarizes the processes in this stage: Table 4-12: Processes in the Recovery Stage Description  Theory  Support for the project revives Identification of the Virus Research group takes the lead Resources arrive  ST  Technological Level Infrastructure  EP  Infrastructure  EP  System Objectives  EP/OI  Infrastructure, program  EP/OI  Program, input, display, reporting, data management, data  Early Implementation  177  Time August to Sep. 1995  Type of Interaction Optimism  Early Sep. 1995 Dec. 1995  Hope and surprise Project begins to live by itself Sep. 1995 Impetus through Jan 1996 Feb. to Concern, April 1996 Chaos, and Cooperation  Stakeholders from Context Developer, users, directors Research group, developer Research group  Funders, computer suppliers, research group, developer Secretaries and Clerks, developers/ suppliers  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).  178  A mismatch between technology and task in this case was similar to the task-technology literature (Cooper & Zmud 1990).  179  Misunderstandings between administrative and development staff appeared (Markus 1983).  180  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 181  (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 (Kling & 182  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  183  (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 awayfrompatient 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 rolefromthe 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  Threats to Operation  ST  Threats to Impact  ST/OI  Technological Level Project conception  Project conception  Time Future  Type of Interaction Uncertainty  Future  Uncertainty  Stakeholders from Context Developer, research group, MIS department, drug company 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 Project Emergence Health Funders Skeptical Our Response Old and New Environmental Shocks Decision to Move Ahead Presentation Sparks Interest and Constraint Conflict Erupts Decision to act Project Builds Momentum Development Quagmire Recovery and Slow Growth to Early Implementation Future ISD Overall  Number of Processes 3 2 3 3  Process Types EP, EP, OI/TI EP/TI, EP/ST ST/EP, 01, OI/EP EP, EP/ST, EP/ST  6 EP/OI/ST, EP, EP/OI, OI/EP, 01, ST/OI 3 EP, EP, EP/ST 4 EP/ST, ST/OI, OI/TI, EP 4 EP, EP, EP, EP 4 ST/EP, OI/EP, OI/ST, ST 4 EP, EP, EP, ST 5 ST, EP, EP, EP/OI, EP/OI  2 43  ST, ST/OI T l 3, 3 Shared, O l 15,13 Shared, EP 31,15 Shared, ST 16,12 Shared  The following table shows the ISD research attached to the process stages (see table 2-6):  Chapter 4: Processes in the SoftHeart Case Table 4-15: ISD Research Categories within Process Stages Process Stage Project Emergence  Health Funders Skeptical  Process Types TI (1) 01 (1) EP (2) TI (1) EP (2)  Our Response  ST (1) 01 (2)  EP (2)  Old and New Environmental Shocks Decision to Move Ahead  ST (1) EP (3)  ST (2) 01 (5) EP (4)  Prototype Presentation Sparks Interest and Constraint Conflict Erupts  Decision to act Project Builds Momentum  ST (2) EP (3)  ST (1) TI (1) 01 (2) EP (2) ST (2) EP (4) 01 (2) EP (2) ST (3)  ISD Research Technology; System Task technology fit; Designer's view; Evolution of technology; Innovation Technology; Systems Evolution of technology; User involvement; Innovation Adaptive structuration Structured information systems planning; Structured design and analysis; User involvement Evolution of technology; User involvement; Innovation Adaptive structuration; Structural power Technology divergence (Uni); Predicament of design; Evolution of technology; Innovation Adaptive structuration; Structural power Strategic information systems planning; User involvement; Task technology fit Predicament of design; Emergent evolution of technology; Innovation Adaptive structuration; Structural power Developer's view; Alternative views; Predicament of design; User involvement; Innovation Adaptive structuration; Structural power System Task technology fit User involvement Adaptive structuration; Structural power Technology divergence (Uni); User involvement; Innovation Strategic information systems planning Technology divergence (Uni); Predicament of design; User involvement Adaptive structuration; Structural power  102  Chapter 4: Processes in the SoftHeart Case Development Quagmire Recovery and Slow Growth to Early Implementation  EP (3) ST (1) 01 (2)  EP (6)  Future  ST (3) 01 (1) ST (2)  103  Technology divergence; Predicament of design; User involvement; Innovation Structural power Strategic information systems planning  Technology divergence (Uni); Predicament of design; Evolution of technology; User involvement; Innovation Structural power Strategic information systems planning 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 with TI with OI with EP with ST Total Shared* TI 3 2 1 0 13 2 7 5 OI 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. 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:  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.  1  Chapter 4: Processes in the SoftHeart Case  105  Table 4-17: Number of Times One Process Type is Followed Another Type Process TI OI EP ST  Total  byTI  5 21 47 22  byOI 1 2 1 1  byEP 0 7 11 5  by ST 3 8 23 9  1 4 12 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. A n 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 Tl 01 EP ST  Total 3 8 10 9  byTI  -  byEP  by O l  1 1 1  0  by ST 2 5  -  -  5 3  5  1 2 4 • •-  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  5.  107  Processes in the Initiation and Development of EMPOWER The development of E M P O W E R 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 U S 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 .  186  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.  187  First, the chapter describes the development team, the vision of the E M P O W E R ' 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 E M P O W E R ' 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 Project Emergence Getting Ready Pandora's Box Opens Squeezing the Most from Toolbook and E M P O W E R Visions of a New Software Constrained by Resources  Time Period November 1993 - April 1995 March - September 1995 September - October 1993 September 1995 - April 1996  Stage Initiation Adoption Adoption and Adaptation  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 E M P O W E R 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 E M P O W E R 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 B C 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,. E M P O W E R (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 topdown (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 E M P O W E R 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 E M P O W E R to catch user attention, and to provide information about the planning stage described on the page. access to "consult-on-tap" resources.  In addition, menus provide  189  E M P O W E R 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  111  Figure 5-1: EMPOWER Program Structure Project Files: 1. Contacts 2. Project Data 3. Objectives  Situations 3l Analysis  Social Analyrsis  R e s o u r c e Files: 1. Model References (bibliography) 2. University S o u r c e s 3. Non-University S o u r c e s 4. Oncology Centres 5. C o m b i n e d Health Database 6. Y e a r 2000 Objectives 7. Interventions 8. Glossary 9. Model Help  Epidemiolot gical Analysis V  Behavioral a nd Environmen tal Analysis n  ft V  Educational and Organizatior lal Analysis  i l  7 Administrativ te Analysis  •  Page Resources: 1. " C a s e Examples" Help 2. "Responding Here" Help 3. Model References 4. "Why" Help  Currently, E M P O W E R 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 E M P O W E R 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 1994; Thomas 1994).  190  (Basalla 1988; Petroski  The opportunities perceived in the project varied amongst the  individual members of the team.  For the project leader, E M P O W E R 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 E M P O W E R 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.  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).  1  Negotiations between the project leader and the US company over development, use, copyright and marketing of subsequent versions of the software was the developer'sfirstintroduction 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  I92  (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 (Earl 1989; Hirschheim & Klein 1989; Attewell 1992; Thomas 1994). 193  During early 1995, project directions, constraints, commitments, opportunities, and resources arose from discussion and external influences  194  (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  195  (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 o f 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 196  (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 E M P O W E R toward tobacco control, to the modification and field testing of the US mammography screening version in Canada.  The pieces fell into  place (Earl 1989; Orlikowski & Robey 1991). 197  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 Project conception  Time  Type of Interaction Exploration and discussion Key early issues arise  Stakeholders from Context Developer, project leader  Opportunity  EP  Meetings about copyright and statistical data Increasing involvement with health promotion group Meetings of Tobacco control project  EP/OI  Project conception  Jan. 1994 - Jan. 1995  EP/OI  Project conception  June 1994 - Jan. 1995  Interest and exploration  System objectives and system functionality  Feb. Mar. 1995  Organization  EP  System objectives  April 1995  Surprise and loss of momentum  OI/ST  System objectives  April 1995  Rejuvenation and reorientation  Developer, project leader, other health promotion groups Developer, project leader, US company, U B C project team Health funders, U B C project team, Health Canada Developer, project leader, NCIC funder, U B C project team, US company  EP/ST  Tobacco grant rejected Mammography screening funded  Nov. 1993 - Jan 1996  Developer, project leader, US company  5.3. Getting Ready During the Getting Ready stage, the development team focused on the goals and constraints of modifying the E M P O W E R 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 complex paths to consider  198  116  (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.  199  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  200  (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 (Sviokla 1989; DeLone & McLean 201  1992), a good template for future software inventions (Petroski 1994), fewer resources 202  ' 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. 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).  1  Use of expert systems, and evaluating its impact important in the project (Sviokla 1989). Task technologyfitassessed (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  203  (Earl 1989).  204  Advantages of starting from scratch included: freeing  ourselves from the U S 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 program , addressing the 205  fragmented storage of information, and overcoming some undesirable interface characteristics of the US version (Markus 1981; Kling & Scacchi 1982). 206  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 (Kling & Scacchi 1982; Attewell 1992; Tyre & Orlikowski 1994). As a 208  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  209  (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  Many goals  EP/ST  Division of labor  EP  Make versus buy decision  OI/TI/ ST  Infrastructure  Mar. - Sep. 1995  Exploring the US version Addition resources fell into place  EP/ST  Program and data structure  Mar. Dec. 1995  Search and influence  ST/OI  Infrastructure  Sept. 1995  Acquisition  Technological Time Level Mar. 1995 Project conception, -Aug. system objectives 1995 Program, data Mar. structure Aug. 1995  Type of Interaction Weighing goals and alternatives Specialization based on expertise Choice  Stakeholders from Context Developer, and development team Developer, and health promotion researchers Developer, US team, US company, U B C project team Developer, US software team 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  210  (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 211  (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 tofixrippling software bugs (Nadler 1982; 212  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 toripple(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  213  (Van De Ven 1986).  Second, the U S 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  214  (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 E M P O W E R ' s size and produced a mixture of pure educational and pure planning pages (Kling 1980; Kling & Scacchi 1982; Van De Ven 1986; Boland 1990; 21s  Petroski 1994).  216  In addition, problems with "content" in the software indicated that the program might no longer be relevant to the users' setting  217  (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 E M P O W E R 1.1 were discovered, illustrating symptoms of project management problems at the US company (Van De Ven 1986; Latour 1987). Each one of 218  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 E M P O W E R 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 (Kling & Scacchi 1982; Brooks 1987; Turner 1987). In addition, 219  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 220  (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). 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).  1  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 (Nadler 1982; Van De Ven 1986). Large lists of changes by numerous individuals 221  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  222  (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 (Van De Ven 1986; 223  Brooks 1987; Mohr 1987). The developer's reaction to the development problems and the U S 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 promisesfromvarious 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).  :  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).  1  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  E M P O W E R in Community One, suggestions were made to disable features that were bugged or had data irrelevant to the Canadian setting (Gibbs 1994; Keil 1995). In addition, plans 225  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  Exploring the Code Difficult Software bugged and complex  EP  Technological Level Program  EP  Program  Sep. 1995 to Mar. 1995  Software functionality and interface Program and data.  Sep. 1995 to Dec. 1995 Sep. 1995 to Present  Data management  Sep. 1995 - Present  Software functionality  Aug. 1995 - Present  Software functionality  Sep. 1995 Stick with - Present the software  Major EP content problems Version and EP documentation problems with U S version Outsourcing EP including database connection fails Project EP/ST scope expanded Team EP response and impact  Time Sep. 1995 to Present  Type of Interaction Frustration and time consuming Surprise and unwillingness to accept Surprise and Struggle to shape Uncertainty and frustration  Stakeholders from Context Programmer, Developer  Time consumption, frustration, failure Changes piling up  Developer, programmer  Programmer, Developer, US software team Content team, Developer, Programmer US company, content team, Developer, Programmer  Content team, Developer, Programmer U B C project team  5.5. Squeezing the Most from Toolbook and EMPOWER Despite the complexity and software constraints, a number of changes were made to the U S version of E M P O W E R 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  226  (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 (Henderson & Kyng 1991; 227  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 (Attewell 1992; Orlikowski 1992b; 228  Landauer 1995).  229  In addition, summary reports can be loaded directly into a Windows-  based word processor, M S Write, with minimal navigation by the user. Finally, most software and content bugs were removed, providing minimal authenticity ( V a n De Ven 1986; Earl 1989; Orlikowski 1992b). Summary reports are printing most of  230  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:  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).  1  ' 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  Content changes Navigation  OI/ST  Outsourcing successes Bugs Removed  EP  EP/ST EP/ST  Technological Level Interface and resources Interface and movement Interface and program Interface and program engine  Time  Type of Interaction Research and typing Design  July to Dec. 1995 Dec. 1995 to Jan. 1996 Design Oct. to Dec. 1995 Sep. 1995 Search and to Mar. fix 1996  Stakeholders from Context Content team Structural and content teams Structural team Structural team  5.6. Visions of a New Software Constrained by Resources As a result of constraints within the U S version, thoughts about developing E M P O W E R 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 E M P O W E R 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 (Earl 1989; Hammer & Champy 1993). This 232  would allow adaptation and flexibility in the tool's usage (Boland 1987; Henderson & Kyng 233  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 i n g & 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  Developer points to major problems Alternative design visions Constraints keep us focused on old EMPOWER  EP/ST  Technological Level and/or Characteristics Functionality  OI/EP  Data design, functionality  ST/EP  Use of old EMPOWER  Time  Type of Interaction  People Involved  Dec. 1995 Surprise and to Jan. Difficulty 1996  Developer, project team  Enthusiasm Jan. to Mar. 1996 and idea generation Jan. to Pressure and Apr. 1996 need to satisfy groups  Developer, project team Project team, funding agencies, users, communities  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). 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).  1  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 Project Emergence Getting Ready Pandora's Box Opens Squeezing the Most from E M P O W E R and Toolbook Visions of a New EMPOWER Constrained by Resources ISD Overall  Number of Process Types Processes 6 EP, EP/OI, EP/OI, EP/ST, EP, OI/ST 5 EP/ST, EP, OI/TI/ST, EP/ST, ST/OI 7 EP, EP, EP, EP, EP, EP/ST, EP 4 OI/ST, EP, EP/ST, EP/ST  3 EP/ST, OI/EP, ST/EP  25  Tl Ol EP ST  1,1 Shared 7, 7 Shared 21,11 Shared 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 Project Emergence  Getting Ready  Process Types 01 (3) EP (5)  ST (2) T l (1) 01 (2) EP (3)  Pandora's Box Opens  Squeezing the Most from EMPOWER  Visions of a New EMPOWER Constrained by Resources  ST (4) EP (7)  ST (1) 01 (1)  ISD Research Strategic information systems planning Evolution of technology; Alternative views; Predicament of design Innovation Adaptive structuration; Structural power System Strategic information systems planning; Task technology fit Alternative views; Predicament of design; Evolution of technology; Innovation Adaptive structuration Technology divergence (Uni); Alternative views Predicament of design; Evolution of technology Innovation Adaptive structuration Strategic information systems planning; Task technology fit  EP (3) ST (3) 01 (1)  User involvement; Innovation Adaptive structuration 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 with T l Total with O l with EP with ST Shared* Tl 1 1 0 7 1 01 3 EP 11 0 3 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. Process  1 4 8  -  All 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 TI OI EP ST  Total  byTI  2 12 34 17  byEP  by OI 0 0 1 0  0 1 7 2  by ST 1 7 16 10  1 4 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 TI OI EP ST  Total 2 10 9 7  byTI  by OI  byEP  -  0  0 1 0  4 1  by ST 1 6  -  1 4 4  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 E M P O W E R 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  6.  134  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 I S D , categories,  236  approaches.  237  235  the four process theories and the ISD research  the technological levels involved in a process, and the reconciliation 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 soc 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 Followed by:  Terminated by:  Case  Data  Shared with:*  1  3 of 43 3 Shared  OI EP ST  2 TI 1 OI 0 EP ST  1 OI 0 EP 3 ST 1  2  1 of 25 OI 1 Shared EP ST  1 TI 0 OI 1 EP ST  0 OI 0 EP 1 ST 1  Technology Level 0 All levels 2 1  0 Infra1 structure 1  Stakeholders Developer, funding agencies, coordinator Developer, US team, US company, 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. The human-computer interaction and framing literature infrequently discuss the boundaries of their findings. Regardless, the developer and his thesis committee also extended thefindingsinto more complex outcomes such as patient health.  1  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 with: *  1  15 of 43 13 Shared  Tl EP ST  Followed by:  Terminated by:  Technology Level 1 All levels 5 2  Stakeholders  2 Tl 2 Tl All 1 01 7 EP stakehold5 EP 8 ST ers 4 ST 0 Tl 2 7 of 25 Tl 1 Tl 0 All levels All 3 01 1 EP 6 7 Shared EP stakeholdST 4 EP 7 ST 4 ers 4 ST Case One O l Literature: Strategic information systems planning; User involvement; Task technology fit __ Case Two O l 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 shortlived 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 E M P O W E R 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 providerpatient 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 Followed by:  Terminated by:  Case  Data  Shared with:*  1  31 of 43 15 Shared  TI OI ST  1 TI 7 OI 8 EP ST  1 TI 11 OI 23 ST 12  2  21 of 25 11 Shared  TI OI ST  0 TI 3 OI 8 EP ST  1 TI 7 OI 16 ST 10  Technology Level 1 All levels 5 4  1 All levels 4 4  Stakeholders Developer and new stakeholders All stakeholders  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 of design, and political and radical "bottom-up" user involvement.  145 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 E M P O W E R 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.  247  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 E M P O W E R 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. prototyping.  249  The best approach to development in this situation is  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 if 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  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  1  What has been developed might be viewed as a prototype for field-testing.  Chapter 6: Conclusions and Integration constraints  and  opportunities.  Users  "adapt" the  technology  148 within technological,  environmental, and user constraints.  Table 6-4: Social Technology Summary from Case One and Case Two Case  Data  Shared with:*  1  16 of 43 12 Shared  TI OI EP  Followed by:  Terminated by:  Technology Level 1 All levels 3 5  Stakeholders  0 TI 1 TI Developer 5 OI 5 OI and new 8 EP 9 EP stakeholdST 7 ers 2 TI 0 12 of 25 TI 1 TI 0 All levels All 2 OI 12 OI 4 OI 1 stakeholdEP 10 Shared EP 8 EP 6 ers ST 5 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. sixteen participated and four exclusively explained processes.  In Case One,  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 appeared to be solid and permanent.  150  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 E M P O W E R 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 E M P O W E R "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 Smith 1985; Orlikowski & Robey 1991; Thomas 1994).  152  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-andfeel, 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  154  Figure 6-1: Integrated Model of Context and Technology Interaction  Technological Level or Part Stakeholders  rf™°  Integrated and Clear  Diverse and Vague  Level or Part  y  Task  Change: Nonadaptable  Agreement Amongst Stakeholders:  9  Technological Imperative  Adaptable  Organizational Imperative  Sock i\ Tech nology Emergent Emergent Perspective Perspective ( C a s e Two) ( C a s e One)  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 overall * This 25  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.  6.7.  259  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. 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.  1  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  7.  159  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.  E M P O W E R 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 E M P O W E R 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. A n 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. adaptation and restriction of further design changes.  The solution is a balance between 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  In Case One, the developer's original technical perspective on design made emergent shocks and revised learning difficult to absorb into the project.  1  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 readaptation  264  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 processesfromthose far removedfromthe task may be dangerous and based on naive assumptions about the value of an organizational task (Hammer & Champy 1993).. Argyris, Putnam, & Smith (1985) comment that single-loop learning (automation) is much easier than double-loop learning (informating).  1  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 contexttechnology 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) , Argyris, 266  Putnam, & Smith (1985) , Hirschheim & Klein (1989), 267  theoretical lenses on the results.  268  which will provide different  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, perspective, technology, power, and organizational structure (Yin 1994).  emergent 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 E M P O W E R into other settings.  The data from later stages of implementation may  demonstrate more technological and organization imperatives.  Although data were collectedfroma second case to help confirm the initialframework,the revised theory is the product of both case study analyses.  1  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. M y 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  8.  170  References  Akehurst, R. (1985). "The Economic Evaluation of Clinical Practice". Medicine. 20 (10), 1037-1040.  Social Science and  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, 111123. Baroudi, J., Olson, M . H . , & B . Ives. (1986). " A n 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 ColorEnhanced and Graphical Information Presentation: A n 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". Computer. 21 (2), 61-72.  IEEE  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). Futures. June 1990, 462-474.  "Computer Unreliability and Social Vulnerability".  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. ISRA90 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". Human-Computer Interaction. 757-789.  In M . Helander (ed.), Handbook of  Green, L.W., & M : W . Kreuter. (1991). Health Promotion Planning: A n 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), 2327  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. JosseyBass: 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. V o l . 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: A n 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), 541564. Myers, M . D . (1994a). " A Disaster for Everyone to See: A n 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". 289-300.  Human Systems Management. 3,  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.  180  References  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: A n 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". Quarterly. Vol. 24, 570-580.  Administrative Science  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 M i x in Transition", In DRGs: Changes & Challenges. Franklin Shaffer (ed.). National League for Nursing: New York.  181  References  Postman, N . (1992). Technolopoly: The Surrender of Culture to Technology. Vintage Books: New York. Rachlis, M . , & C. Kushner. HarperCollins: Toronto.  Strong Medicine: How to Save Canada's Health System.  Reich, B.H., & I. Benbasat. (1990). " A n 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". Condition Critical. Macmillan: Toronto.  In N Regush (ed.),  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.  182  References  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). " A n 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. V o l . 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. New York.  John Wiley & Sons:  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 InformationProcessing Effects in Risk Assessment" in David Bell et al. (eds.) Decision Making:  References Descriptive. Normative, and Prescriptive Interactions. Cambridge, pp. 152-166.  183 Cambridge University Press:  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. " A n 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. V o l . 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.  185  References  Vogt, T. (1983). Making Health Decisions: A n Epidemiological Perspective on Staying Well. Nelson-Hall: Chicago. Weiser, M . (1991). "The Computer for the 21st Century". 1991, 94-102.  Scientific American. September  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: A n 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  9.  186  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. M y background influenced my attraction to the project and its original focus. M y 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  M y 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 SoftHeart, and also certain perspectives on system development.  187 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  on working life.  Finally, a number of incidents revealed the negative effects of computing 276  The SoftHeart project was an opportunity for myself, and three researchers, including one clinic physician, to achieve numerous goals.  277  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.  M y 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  M y 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.  M y 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. onus was on us to prove IT's systematic effect on health.  The  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. proposal defense,  At my thesis  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. M y experience teaching and working with dBase I V 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. M y 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  D B F files were not native to  the program. As a result, I searched through software packages that used D B F 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 for achieving many of the reporting goals.  289  194  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.  290  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. All 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.  297  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  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).  1  Even calculated values were computed using a calculator and typed into the system.  Appendix A : The SoftHeart Story characteristics from both programs.  200  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 lukewarm supporter into an unfriendly foe.  298  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.  300  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) , and a funding 302  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  At the time, the coordinator stated that she was mentioning these barriers to ensure the success of the project.  301  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.  202  Appendix A : The SoftHeart Story  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 A D T 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 SoftHeart.  307  205  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. M y 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 October 15th, 1995 (June 20), and December 18 (Dec. 7).  309  207 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.  310  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. All 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).  311  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 , and the 312  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  311  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.  313  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 pr