Narayanan V.K., Armstrong D.J. - Causal Mapping for Research in Information Technology (2005)(en)
.pdf260 Larsen and Niederman
Appendix C (Continued)
Documentation consistency |
Specifying outcomes |
Documentation detail |
Staff communication between project phases |
Documentation method |
Staff knowledge and skill |
Documentation process description |
Staff preferences |
Documentation quality |
Staff skills |
Documentation utility |
Staff turnover |
Early involvement |
Staffing |
Early testing |
Staffing turnover |
Enterprise-level requirements process details |
Standardization |
ER (data) model |
Standardized platform approach |
ER diagrams |
Standardized use |
Faith and trust |
Standards |
Focus on overview |
Success measures |
Formal information requirements |
Task accounting |
Functional area |
Task complexity |
Guideline design/process |
Team size |
Hardware capacity |
Technology diversity |
Hardware/software capacity |
Testing/quality assurance |
Hierarchy chart |
Time, money |
Hiring |
Tool investment |
Ideal documentation approach |
Tool platform selection |
Implementation issues with ER versus OO |
Tool use |
Implementation of modeling |
Tools |
Individual expertise and contribution |
Tools description |
Individual performance |
Training |
Information requirements documents |
Training methods |
IT staff skill levels |
UML |
Java provides some CASE tool functionality |
UML use |
Java, OO approach |
UML/CASE tools |
Leadership |
Uncertain situations |
Learning / Improvement |
Universal development approach |
Level at which business process documentation |
Use |
occurs |
|
Linkage of requirements to technical models |
Use case |
Management mandate |
Use of OO |
Manual approach |
Use of packages |
Master scheduling |
Use of UML |
Matrix organization |
Use/non-use of UML |
Measurement |
User characteristics |
Meeting all requirements |
User contract |
Mentors |
User expectations |
Metrics |
User involvement |
Modeling |
User liaison |
Modeling formality |
User satisfaction |
Modeling thoroughness |
User signoff |
Modular training |
User survey |
Multinational staffing |
User type |
Narrowed features/simplification |
Value of CASE tools, difficult to measure |
Need for developer – user communication |
Vendor experience |
Non-OO design |
Vendor selection |
Object /class diagrams |
Vendor staff turnover |
Object diagrams |
Visual representation |
Object-ERD |
Visualization of screens and outputs |
On-line CASE tools |
Word document |
OO |
Work expectations |
OO Approach |
---------------------- |
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Adoption of UML 261
Appendix D: Concept List for
Dependent Variables (Effect)
Ability to model system |
Project cost |
Ability to provide documentation |
Project difficulty |
Ability to provide modeling |
Project management organization |
Adoption of UML practices |
Project management quality |
Amount of risk |
Project management success |
Application success |
Project organization |
Change management |
Project outcomes |
Client satisfaction |
Project process success (ease/flow) |
Client satisfaction |
Project quality |
Communication requirements |
Project success |
Communication with users |
Prototyping |
Component oriented production environment |
Quality assurance |
Cost |
Quality of documentation |
Design quality |
Quality of information requirements document/ |
Detailed user requirements |
Quality of packaged processes |
Developer satisfaction |
Quality of tool use |
Developer skills |
Quality of use of OO |
Developer team communication |
Quick view |
Developer-user communication |
Requirements documents |
Development guidelines |
Reuse |
Development model |
Role of analysts |
Development outcome |
Role specialization |
Deviation from standards |
Satisfaction measure -- questionnaire |
Documentation |
Scalability |
Documentation outcomes |
Scope definition |
Documentation quality |
Scope problems |
Documentation success |
Sense of closure |
Documentation utility |
Skill development |
Documenting business issues/decisions |
Skills |
Ease of data retrieval for user |
Staff mentoring |
Ease of learning OO |
Staff skills |
Economic value |
Staff skills and knowledge |
Effective tool use |
Staff training |
Effort on documentation |
Staffing alternatives |
Enhance knowledge base for project work |
Standardization |
ER use |
Standardized platform approach |
Extra overhead |
Standardized use |
Formality of documentation |
State chart diagram |
Formality of modeling |
State transition diagrams |
Generating user feedback |
Subset of CASE tools |
Information requirements success |
Success measure – fulfill all contracted |
|
requirements |
In-house use of CASE tool |
Sufficient modeling |
Insurance against personnel loss |
System consistency |
Integrating data and process views |
System use |
Integration of development environments |
Technology diversity |
Internal versus external staffing |
Technology diversity |
IT role |
Tendency to use OO/UML |
Learning curve |
Testing effectiveness |
Maintenance |
Thorough modeling |
Model use |
Tool use |
Modeling formality |
Training |
Narrowed features/Simplification |
Turnover |
Need for analysis and documentation |
UML use |
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
262 Larsen and Niederman
Appendix D (Continued)
Need for requirements documentation |
UML use (sequence diagrams and use case |
|
diagrams) |
Need for specific tool |
Use case |
Obligation satisfied |
Use levels of ER |
On-line CASE tools |
Use of DFD and ER |
OO |
Use of modeling |
OO project management |
Use of OO approach |
OO skill development |
Use of sequence diagrams |
OO skills |
Use of use case |
OO success |
Used for development |
OO tool use |
Used for testing |
OO use |
Usefulness of models |
Package customization |
User participation |
Package stability |
User requirements writing |
Pattern of modeling content |
User satisfaction |
Performance |
User understanding |
Pressure for IT personnel to perform |
Version control |
Problem understanding |
Visualization of documentation |
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Using Causal Mapping to Support Information Systems Development 263
Chapter XI
Using Causal Mapping to Support Information Systems Development:
Some Considerations
Fran Ackermann
Strathclyde Business School, UK
Colin Eden
Strathclyde Business School, UK
Abstract
Identifying what different stakeholders in a business need from Information Systems development has always been seen as problematic. There are numerous cases of failure as projects run over time, over budget, and, most significantly, do not meet the needs of the user population. Whilst having a structured design process can go some way towards reducing the potential of failure, these methodologies do not attend sufficiently to clarifying and agreeing objectives or to considering the social and cultural elements inherent in the ownership and adoption of any new system. Instigating an effective, and structured, dialogue between users, developers and, when appropriate, sponsors, is therefore a critical consideration. Linking user needs, as they see them, to the language of IS developers and vice versa is crucial. Both parties need ownership. This chapter focuses upon the use of causal mapping, supported where appropriate by special software, that facilitates the development of a shared understanding (of both business needs and IT opportunities) and through this common platform enables a negotiated and agreed outcome. The nature of the outcome invites translation to structured design processes.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
264 Ackermann & Eden
Introduction
Although Information Systems (IS) are able to provide considerable benefits to organizations, there have been an extensive number of failures. For example, in 1999 the Financial Times noted that 50% of systems projects fail to meet their expected rate of return. A later, more spectacular, example is the system developed by ICL for UK Post Office counters — a system which went massively over budget and was never completed in line with the original specification (Financial Times, 22 July 1999). Explanations for these problems abound and range from poor communication with users and customers, not learning from past experiences, over-ambitious rates on returns, unexpected demand levels, amongst others (Boddy, Boonstra & Kennedy, 2002).
The use of structured approaches such as Structured Systems Analysis and Design Method (SSADM) (Downs, Clare & Coe, 1988), Information Engineering (Martin, 1986) and other such methodologies were touted as aiding the development of the systems through providing careful, logical procedures to follow. However, experience showed that they still fell short in terms of supporting the process of IS development, as they lacked understanding of the boundaries and properties of the systems starting well down the development process. More recent approaches such as prototyping, and Rapid Application Development (Martin, 1991), which were developed to answer some of the difficulties, are still unable to provide what is required. For example, no aid is provided by these techniques for managing differing, and possibly conflicting, objectives of users, or addressing the organization’s social and cultural norms of behaviour. Defining requirements is often regarded as a simple process, or one that can be determined by the Information Systems (IS) staff. As argued by Jayaratna (1994) and Stowell (1995), what is needed is a deeper understanding of the nature of organizations and how the system interacts with the organization
Orlikowski, Walsham, Jones and DeGross (1995) found that even when systems are developed with consideration of the organization’s working practices there are problems as appropriation of systems can often be diverted from original intention as user needs change and are refined over time and use. However, they suggest that this is likely to be particularly the case if and when business practices and their socially construed norms are not well understood. Acknowledging the need to attend to the social and ethical considerations, however, is not new, as noted in Enid Mumford’s work (1983) and, as Zuboff comments, IS “ultimately reconfigures the nature of work and the social relationships that organize productive activity,” (1988) further reinforcing the need.
Therefore, methods and techniques for facilitating dialogue between users, developers and, when appropriate, sponsors is important. Soft Systems Methodology (SSM) — a problem structuring methodology has seen some success in this area (Checkland & Scholes, 1990). As its name suggests, SSM pays particular attention to the “soft” or social issues. The approach recognises that in most situations there is a lack of clarity regarding the objectives of the system in question and that these issues often comprise many aspects and subtleties which make working with the apparently messy IS design situation problematic. Providing some means of surfacing and structuring existing concerns is achieved through the formalism of what is called a “rich picture”— a cartoonlike picture that depicts the aspirations and situations of stakeholders of the system
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Using Causal Mapping to Support Information Systems Development 265
being considered. The process explicitly allows for the social elements to be revealed along with consideration of possible different interpretations of the system (different conceptual models) and so enables an effective dialogue to take place. The process is expected to result in the agreement of an owned outcome.
Another problem structuring method, which is gaining popularity, is the use of causal mapping. There are an increasing number of papers detailing management research and problem solving practices that have effectively applied mapping. These applications appear in a range of research arenas including IS (see Nelson, Nadkarni, Narayanan & Ghods, 2000; Boland, Tenkasi & Te’eni, 1994; Zmud , Anthony & Stair, 1993). Mapping’s ability to surface and structure individual theories of the world with their associated detail not only allows the individuals themselves to understand their thinking better but also provides a rich basis upon which to enable the different stakeholders in the group to negotiate a shared understanding and make agreements.
In this chapter we begin by reviewing the background and features of our particular form of mapping before exploring its use in a real-world example, considering what that experience suggests about the requirements of successful IS design, and then finally making some concluding remarks.
Causal Mapping
As is also evident elsewhere in this book, not only are there a number of different ways that causal mapping can support Information Systems, but there are different forms of Causal Mapping. The particular version considered in this chapter is based upon the work of a cognitive psychologist — George Kelly (1955) — whose propositions about how individuals make sense of their world resulted in a powerful body of theory known as personal construct theory (PCT). From this body of theory Kelly developed an instrument: Repertory Grids (Fransella & Bannister, 1977; Bonarius, Holland & Rosenburg, 1981) which has been used in IS research (Hunter & Beck, 2000; Tan & Hunter, 2002). In addition, and, more pertinently for this chapter, cognitive mapping was developed to reflect more depth and greater appreciation of individuality than that which was offered by repertory grids (Brown, 1992; Eden, 1988). However, as many organizational tasks require the involvement of a number of participants, a range of different forms of group mapping have been developed (Ackermann & Eden, 2001; Eden & Ackermann, 1998) to extend the use of causal mapping that is founded in personal construct theory. These different forms include:
The “Oval Mapping Technique” — a manual, rather than computer-assisted, process. Individuals are provided with oval shaped cards (about 11x19cms, or large rectangular post-its) and identical pens (to help increase anonymity). They are asked to write down any concerns, aspirations, issues or assumptions that come to mind. Each contribution is written on a separate oval card. These ovals are posted up on a flipchart paper-covered wall, enabling others to read and “piggyback” off them. During this process of generating a scatter picture of the important aspects of the situation under consideration, a facilitator works at clustering the material into themes so as to manage the large amount of material.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
266 Ackermann & Eden
It is not untypical to have 200+ contributions surfaced from a group of eight by the end of a two-hour session. Once the rate of contributions has slowed down or stopped, the group, with the help of the facilitator, works through each cluster exploring how the content of the different statements causally influence one another, both within and across clusters. This process inevitably surfaces further views as different chains of causality are presented and captured. The result is a structured causal map. The map represents not only the different themes/clusters but also their degree of interaction with one another. The process invariably enables the participants to move from an often very divergent view of the situation to a more convergent one.
The second form of group mapping involves the use of a mapping software package — Decision Explorer1 — to capture and structure the material. Instead of having participants write down their contributions, the facilitator captures the contributions as they are stated in facilitated discussion, thus in real time. The facilitator regularly checks with participants that views have been captured correctly, and explores their relationships with other already captured statements. This enables participants to concentrate on the discussion — using the developing map as an aide mémoire. As a result of working electronically the group can interactively “play” with the captured material exploring, for example, the consequences of different options, examining possible alternatives, and agreeing objectives/goals (end points of the causal chains). In doing so they are always aware of the causal ramifications of their developing agreements. In addition, rapid searches can be carried out for statements focusing on a particular topic, as well as a range of analyses used to enable exploration of the structure of the map. Analysis results, such as the identification of “central” statements that influence and are influenced by many others, of “potent options” that can affect many goals, and of significant outcomes or goals, subsequently can be colour coded and categorised. Finally by having a number of views available (similar to spreadsheet packages where there can be a number of sheets) of different aspects, managing the complexity of the large body of material surfaced becomes easier.
The third and final form has participants provided with laptops connected together through a local area network, and connected through Decision Explorer to a public screen — the combined system is run through the software Group Explorer2. This allows participants to directly enter their contributions (both statements and relationships) into the map developing on the public screen as soon as they think of them. This allows for total anonymity and reduces the pressure on the facilitator to capture the material. In addition, this mode of working provides other useful features such as the ability for each participant to rate the importance of statements on a scale or to prioritise them. For example, through using the “preferencing system” participants are able to demonstrate anonymously which of the options they will support and which they will not, providing a reality check on the proposed way forward. Alternatively, participants can use the rating tool, which allows them to explore which of the various options might provide best support for an objective and whether there is any consensus about this.
Each of these has been applied to a range of different decision making areas (see Ackermann & Eden, 2004) including problem structuring (Eden & Ackermann, 2001), strategy development (Eden & Ackermann, 1998) and the modelling of disruptions and delays occurring on large engineering projects (Ackermann et al., 1997).
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Using Causal Mapping to Support Information Systems Development 267
In each of these processes the technique of causal mapping provides the means of developing a graphical representation of an individual’s or group’s perception of issues by building up chains of argumentation. Therefore, statements/nodes (facts, assertions, options, issues, goals, etc.) are captured along with their relationships — where the arrow (relationship) implies causality. In Figure 1, the individual is discussing the use (or not) of a financial information system. Node 13 and 7 are both assertions resulting in the perceived consequences of 9 and 6. This is a small causal map — frequently individual maps comprise 80+ statements and group maps in excess of 400 statements.
Furthermore, the analysis of the structure of the causal map can reveal patterns. For example, busy points typically suggest key issues, superordinate statements (those at the top of the chains of arguments) imply values or goals, and feedback loops imply potential dynamic behaviour. In Figure 1, node 17 has a considerable amount of material supporting it — some of which is shown in detail, e.g., nodes 15, 18, 20 and some of which is currently hidden (nodes 27, 25, 23), suggesting that it is likely to be a key issue. Node 8 is displayed as a goal — this was something that the individual felt was good in its own right. Finally on the left of the figure is a feedback loop (comprising nodes 17, 19 & 20)
— in this case operating as a vicious cycle (a self-sustaining negative situation). In this way the user is able to examine both the whole (in terms of emergent properties of its structure) and the detail to help develop a fuller understanding of the interaction of different considerations, and so make a more informed decision.
The map enables a better understanding to be developed as statements are explored alongside their context. Adhering to the formal coding guidelines (see Appendix A) is necessary for the analysis of emergent properties of the map to be reliable, but it also provides a powerful aid to group thinking. For example, the guideline asking that each
Figure 1. An example map
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
268 Ackermann & Eden
statement be worded in an action-orientated form encourages those developing the maps to be clearer about what might be done and why that would be expressed by an assertion. Attending to the direction of causality between two statements prompts consideration of what is the means and what is the desired end or outcome of two action-oriented statements, often revealing underlying values.
Although mapping can help individuals better understand their world, when considering Information Systems design it is mapping’s ability to support group negotiation that is of most interest here. Capturing the views of those participating, along with the full context of their views as chains of argument means individuals are better able to determine what they are concerned about and what they want regarding the system within the context of the opinions of others. Through this extended picture, a greater understanding of meaning is elicited (through the context) and thus an appreciation of the rationale for particular views. Moreover capturing all of the contributions provides participants with a sense that the process is “just” (Kim & Mauborgne, 1991). From this often quite extensive map3, a shared understanding begins to emerge. One objective is for those involved to begin to understand, in use, what is meant by very general descriptions of the proposed system (Checkland & Holwell, 1998).
Using Mapping to Develop an
Information System
As intimated above, developing a clear and shared understanding of the purpose of the system by all who have some stake in its development and use is important for ensuring that the system is used and used within appropriate bounds. Information is always given meaning by its context, and often IS’s are designed with a presumption of context. A good understanding can only be derived from a clear knowledge of purpose and the limits to its application.
Understanding who the stakeholders might be, who will give the information meaning and in what way might they be involved (or effect the usage of the system) is critical. Stakeholder analysis and management techniques such as those described in Boddy, Boonstra and Kennedy (2002) or Ackermann and Eden (2003) provide a good starting point.
Ackermann & Eden employ particular forms of mapping to determine not only who the stakeholders are, but also the details regarding their disposition, relationships with others, and the nature of the power and interest they may use to influence the success or otherwise of the information system. By building a grid whose axes are power and interest, participants are able to position stakeholders according to their relative power to influence success (as determined by the purpose of the IS) and interest in usage. The grid usefully shows those who have both the interest and power to ensure success or failure, and so attention to their views regarding the development of the IS will be crucial. A better understanding of these stakeholders can be elicited by exploring in more depth the bases of power and the nature of interest. Those who have power and no interest in the outcome can easily determine failure (intentionally and unintentionally) and so must be carefully managed. Mapping the influence network among these powerful stakehold-
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Using Causal Mapping to Support Information Systems Development 269
ers provides important clues as to which of them can be used as opinion formers — increasing the chances of success. Analysis of these maps follows the same conventions as those used to analyse causal maps.
By facilitating not only the means of contributing effectively to these deliberations, but also structuring the contributions to enable effective management of the unfolding complexity (rather than reducing it), sufficient and productive time can be spent in the exploration stage. The purpose of the exploration is to consider in depth the emergent properties and develop agreed action packages. This ability through capturing the richness and diversity of views along with managing their structure represents the stages of Intelligence and Design, in what Simon (1959) describes in his four stages of decision making.
By describing a case study that employed mapping as a means of developing an IS, aspects of the process and some of the benefits of mapping will be illustrated and explored. As with most case studies in IS development, the material is sensitive, and so the material presented below is less expansive than preferred.
Developing an Information System for Student Tracking4
The organization discussed below is part of a large University. Rather unusually, it is a self-funded unit receiving no public monies. Therefore, it operates in many ways as a business with one of the main objectives being to not make a loss, and make enough surplus to reinvest in its educational products. At least, sufficient revenue is required so that the organization can pay staff, keep the estate in order, and provide its commitment to a high quality total service to students. The major contribution to finances is unsurprisingly student fees, although executive development programmes, amongst other activities, contribute. Currently the unit delivers its key products in many different locations (product offerings not only at home but in four countries in South East Asia, four in the Middle East, and two European countries).
One of the consequences of having such a widely dispersed programme (at any one time the school has around 2,000 students on its books) is that it is paramount that an effective and efficient information system is available to track enquiries, manage admissions, and monitor the progress of students. However as is often the case, an incremental growth in locations and student numbers along with a growing recognition of the power of information technology had resulted in an ad hoc approach to the development of information systems. Consequently, there were six different systems being used, involving a range of different programmes — databases, spreadsheets, and word-processing packages. Getting data from one to another was problematic, frequent errors occurred and thus accurate and timely information was difficult to attain. A new system was required.
In order to ensure that the new system was as effective as possible, it was necessary to take into account views from staff with responsibilities for marketing, operations, academic delivery, and unit management along with those from the computer support
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.