[IEEE IPCC 2005. Proceedings. International Professional Communication Conference, 2005. - Limerick, Ireland (July 7, 2005)] IPCC 2005. Proceedings. International Professional Communication

2005 IEEE International Professional Communication Conference Proceedings

0-7803-9028-8/05/$20.00 © 2005 IEEE.

From Fighting Fires to Building Bridges: The Role of Metaphor in Systems Requirements

Dermot Casey University College [email protected]

Cathal Brugha University College [email protected]

Abstract

The problems of systems development have been called a chronic affliction with no apparent cure. We see issues of misunderstanding: misunderstanding in the practice of communication and misunderstanding of the nature of the communication at the heart of this problem. We illustrate the standard model of systems requirements, a reductionist model based on the conduit metaphor of communications, which minimises proper understanding. We describe how this approach is conceptually flawed and use developments from cognitive science to gain a deeper understanding of embodied cognition and the role of metaphor in communication. We show how even our understanding and application of understanding is confined by the usage of analogies and metaphors such as 'grasping' and 'filling', which relate to physical objects. We show that avoiding reductionism is more challenging than not using the conduit approach. It requires working with the problems at the second level. We need to identify and use metaphors about understanding that do not cause an unconscious dumbing down of the processes involved in systems development. Concluding that conceptual difficulties will necessarily arise when groups are working with different metaphorical concepts grounded in their personal experience, we suggest some approaches for improving communication.

Keywords: systems, requirements, metaphor, language, communications

1. Introduction

What causes systems development to fail? As a process, systems development closely resembles

“Groundhog Day”. Despite our best efforts we repeatedly find ourselves back where we started, wondering how another project has failed. Writing more than 20 years ago, Bostrom and Thomas [1] noted: “After 25 years of experience building Computer-Based Information Systems, we still seem to have plenty of problems.” They pointed to poor requirements as a key cause. Twenty years later we are still faced with these problems [2]. Are these problems essences or accidents in systems development [3]? As systems builders and software developers, we construct stories, using familiar settings or frameworks formed by our experience to understand what we are trying to do. These stories, our myths and narratives, reflect universal human characteristics found in all societies and cultures [4], [5]. Storytelling, at the core of what makes us human [6], is central to our concept of communication.

Use of narrative frameworks permeates our personal and organisational lives [7]. In building systems, however, we look to remove ambiguity and develop clean requirements, to help build our data models, and to test our software. The reality of systems development is rarely so simple. The tension between formality and ambiguity is a key problem of systems development. Despite our efforts at formalisation, software continues to fail [8] frequently and catastrophically [9]. We define failure broadly as encompassing both cancelled projects (failing completely) and challenged projects (those that include projects that are late, over budget, or have reduced functionality) [10]. We dub the problems that arise when attempting to develop software ‘fire fighting’, noting that this is a general problem of product development, not simply confined to systems development [11]

Empirical evidence suggests that only 24% of information systems (IS) development projects are

813


delivered on time, on budget, and with the promised functionality [8]. Drawing on Standish [8], Dalcher [10] points to the multi-billion dollar cost of these failures in the US alone. Referred to as the ‘Software Crisis’, these problems stretch back over 30 years, and are well documented in the literature [2], [3], [12], [13], [14]. So enduring are the problems of systems development that Pressman [15] suggests the “software crisis” would better be called a “chronic affliction” in the sense of causing distress and persisting indefinitely. Despite an apparent wealth of knowledge about project management [16], [17], numerous IS development methodologies [18], and fifty years of empirical experience [19], the “chronic affliction” persists.

Concurrent with the problems of developing systems, the information technology (IT)/Organisation Alignment challenge to buildbridges between IT and the broader organisation is seen to be the most pressing concern for IS practice [12], [20], [21]. We propose that both issues, firefighting and building bridges, are two aspects of the same problem, and reflect the difficulty of establishing shared understanding to enable action within organisations. We find a similar understanding in [12]. Building and alignment , we believe, are both dependent on communicating understanding. The first stage in developing an information system is in understanding what to build. This is accomplished through developing the system requirements [17], [22], [23], [24]. Central to this is a requirement description [23], [24]. This paper focuses on organisational communication as the core activity in building the requirements description.

We begin this paper by detailing the problems of communication and the consequent organisational difficulties that arise when developing requirements. We develop this theme by looking at the area of language and our understanding of language. We point to the fundamental role of metaphor and embodied cognition in the development and use of language. Linking the ideas of language, metaphor, and culture, this paper describes the importance of metaphor in everyday language, particularly in how it enables people to understand, reason about, and explain abstract concepts. We focus specifically on the conduit metaphor of communications illustrating its mapping onto the requirements problem. Describing the conceptual difficulties that can arise

when groups are working with different metaphorical concepts grounded in their personal experience, we show how this can lead to learning dysfunctions, poor communications, and poor quality systems.

Arising from this we suggest approaches to dealing with the practical problems of communications in organisations. We base this on the idea that metaphor can provide a way of “partially communicating unshared experiences” [25] and can form an aid to improving communication and could be particularly useful in cross-cultural situations. This paper grew out of an case of software fire fighting experienced by one of the authors [26], a case which addresses some of the themes of this conference, including outsourcing, cross-cultural development, and managing virtual teams. In our discussion, summary, and conclusion we outline some of the problems encountered in this case and reflect on how aspects of theory can improve future practice.

2 Understanding requirements and communication

Understanding requirements is one of the critical tasks in the development process [27]. There is considerable support for the idea that requirements issues are the root cause of many problems with IS projects, and merits serious attention [22], [24], [28], [29]. Brooks has pointed out “the single hardest part of building a software system is deciding precisely what to build”[3]. Parnas and Clements note, “Determining the detailed requirements may well be the most difficult part of the software design process” [30]. We propose that the task of determining requirements exposes the key challenges faced by organisations. Organisations should face these challenges prior to development, or as they become aware of them in the course of developing systems requirements. Doing so will bridge the alignment gap and help to overcome development disasters.

To address the requirements problem we need to understand the nature of the problem. Referring to Simon [31], Halverson notes that, “much problem-solving effort is directed at structuring problems, and only a fraction of it in solving problems once they are structured”. He describes “The problem-setting stage, where the issue is defined as a member of a certain class, as critical to

814


understanding” [32]. In setting out the problem we ask two basic questions: what do we understand by communication, and what do we mean when we talk of requirements?

The Oxford English Dictionary gives a number of definitions for the word communicate, two of which evoke contradictory understandings. One is “to impart, transmit (something intangible or abstract)”. A second is “to succeed in evoking understanding”. We suggest that people frequently confuse these two definitions, conflating human communications with the signal processing problems of information theory1. In doing this we forget that that in Information Theory the “semantic aspects of communication are irrelevant to the engineering problem” [33], i.e. Information Theory is about the transfer of signals, not about evoking understanding. This problem arises because of “the Conduit Metaphor” of communication [27]. The conduit metaphor views communications as the transfer of an object through a conduit from one person to another. This implies a one directional flow, presumably sent once, although allowing for confirmation of its arrival, such as a written communication, fax, email, etc. Evoking understanding implies cycles of two-way communications, including confirmations of major points followed by clarifications and agreements, and elaborations of details. Most importantly, for our purpose, it also implies acknowledging one another’s histories and experiences, both shared and unshared. It implies that understanding is built in layers. I cannot state my understanding about some requirements in detail until I am clearer about your understanding of the project. The term that is most often used is ‘mutual understanding’.

The Irish phrase “ceangailte le” means to be “tied to, linked to, bound up with”. Reflecting the conference theme, our understanding of requirements and the problems posed by requirements is intimately bound up with the language we use to describe them [27], [34]. Wittgenstein was almost right when he commented, “the limits of our language are the limits of our thought”. Language is a cognitive frame that filters our understanding of the world.[35] Defining communications through the Conduit metaphor limits the ways we think about

1 A problem not helped by the title of the seminal paper in the area “A theory of communications”

requirements and undermines our understanding. We see this clearly in the normative description of requirements.

The IEEE defines a requirement as “a property that must be exhibited in order to solve some real-world problem.”[17] Potts notes that “requirements are the properties that should hold in the real world that we want the IA [Information Artefact] to help bring about, not the properties of the IA itself.”[23] Potts notes that any piece of software is an intentional technology that requires “some explicit description of purpose.”[23] The difference between an IA and any other type of artefact is that “implemented purpose is all they are”. As information systems are not grounded directly in the material world, there is more freedom to abstract away from constraining mechanism. In describing a real artefact such as a car “any description of function failing to mention wheels or brakes and merely describing patterns of desired movement and acceleration would be hopelessly abstract.”[23].

Determining what this implemented purpose will be begins by a process of requirements description, variously termed ‘requirements capture’, ‘requirements discovery’, and ‘requirements acquisition’. These descriptions reflect how embedded the conduit metaphor is in our thinking. The phrases capture, discover and acquire infer the existence of tangible objects that already exist and can be touched. We imply that it is possible for one individual to acquire requirements from another.

A fundamental tenet of systems development is that there be good communication between software users and software engineers. IEEE [17] notes “before development begins, requirements specialists may form the conduit for this

communication.” Requirements engineers are seen as mediating between the software users (and other stakeholders) and the technical world of the software engineer removing ambiguity.[17] The normative view is that “Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements which depend for their interpretation on subjective judgement”.[17]

The process of making requirements unambiguous is the nub of the problem.[36] We are warned “ambiguity is the great bugaboo of

815


requirements.”[24] Davies urges us to “Reduce ambiguity in requirements.”[28] The question we ask is: is this possible? Is it possible to describe requirements unambiguously? We know that the failure of systems development in large part reflects a failure of implemented purpose, and a failure to describe requirements unambiguously. Yet despite decades of intense effort, no one has found “a good way to structure this process so that it consistently produces reliable, dependable, high-quality, economical, safe, and usable software.”[2]

The IEEE standard model defines ambiguity as “present any time multiple readers of a requirements statement arrive at different understandings of what it means. Another sign of ambiguity is when a single reader can logically interpret a requirements statement in more than one way.”[17] This standard model of requirements suffers from the conduit metaphor, the idea that language can be literal and unambiguous, that can literally be transferred from one individual to another, and that meaning can be preserved in written language. While there is some recognition that this isn’t entirely possible [2], [36], [37], it is widely assumed that through formalisation all ambiguity can be removed.[28], [36]

In reframing this problem we will offer an alternate explanation for the problems of communications and requirements description. We will base this on modern theories of cognitive science, the origin of language and the role of metaphor. We will then use these ideas to illuminate the conduit metaphor and to describe an alternative approach to getting through the requirements phase of a project. We will then offer some suggestions on how we can improve our communications and address some of the underlying causes of software failure.

3. Metaphors we compute by

Use of metaphor is pervasive in language.[25], [35], [38] The term derives from meta-phereinmeaning ‘to transfer’, emphasising the embeddedness of the conduit metaphor in language. Lakoff and Johnson suggest, “the essence of metaphor is understanding one thing in terms of another.”[38] An example is that we think of difficulties as burdens (the physical grounded metaphor), and can understand “that’s a weight off my mind”. In using metaphor we are performing what Fauconnier & Turner [39] call a conceptual blend. We are taking concepts from one domain

and applying elements of them in another domain. We are not taking all of the concepts from one domain; rather we take aspects of one object and using it creatively to understand something else. In using the term “the world wide web” we see the in the phrase “web” a metaphor for a vast internetwork of computers. Using this idea we can think of the different ways of travelling the web. We conceptualise search engines as spiders moving across the latticework of computers on the web. We ignore other aspects entailed by the idea of a web, such as that Spider’s webs are centrally planned and controlled, and are designed to stop movement.

Metaphors permeate all thinking. They are integral and inescapable aspects of thought and action. Lakoff & Johnson note “... we define our reality in terms of metaphors and then proceed to act on the basis of the metaphors. We draw inferences, set goals, make commitments, and execute plans, all on the basis of how we, in part, structure our experience, consciously and unconsciously, bymeans of metaphor.”[38] Churchill anticipated the modern theory of metaphor in describing the power of analogy: “The ambition of human beings to extend their knowledge favours the belief that the unknown is only an extension of the known: that the abstract and the concrete are ruled by similar principles: that the finite and the infinite are homogeneous. An apt analogy connects or appears to connect these distant spheres. It appeals to the everyday knowledge of the hearer and invites him to decide the problems that have baffled his powers of reason by the standard of the nursery and the heart.”[40]

Historically, the philosophy of language took the approach that literalness was fundamental to language understanding and that metaphor was a colourful bolt on to the basic underlying mechanisms of language.[23], [25], [38] The underlying mechanisms being disembodied, formal, and rational reflected in Descartes notion of disembodied cognition “I think therefore I am”, where “thought is nobler than sense and the objects of thought more real than those of sense perception.”[41]

This leads to the idea of the centrality of description as symbolic representation. We see the antecedents of this in Plato’s notion that that metaphorical language “had a terrible power to corrupt” [42] quoted [43], best avoided and

816


replaced with rigorous thought. We see the descendants of Plato and Descartes in our modern notion of the need to formalise requirements, the need to remove abstraction and the dangers of natural language. The irony, as Hamilton notes, is “the most quoted and best remembered passages in The Republic is based on the cave as a powerful metaphor for the limits of human knowledge” [43]. Similarly Aristotle used metaphor in an attempt to exclude the use of metaphor from formal thought [11]. The problem is that the Cartesian dream of pure thought is on which these ideas rest is false.[16], [44], [45]

To understand the central importance of metaphor in thought and language we need to recognise the origins and purposes of language itself. We have insufficient time and space to provide more than a brief glance at this field. By drawing on work carried out over the past few decades in areas as diverse as Philosophy, Psychology, Nero-biology, Linguistics and Cognitive Science, we can illustrate a comprehensive understanding of the origins of language and communications and their influence on cognition. We use these ideas to point to the fallacy of the conduit metaphor and to point to an improved understanding of communications.

Recent work by Ramachandran [46], [47], suggests that language was boot-strapped by a number of factors in the brain. These factors include the hierarchical nature of tool-making; co-opted for the hierarchical nature of syntax, and the cross activation between the hand and the mouth linking aspects of touch, thought and language. Ramachandran illustrated this through an example of Darwin’s “when people cut with a pair of scissors you clench and unclench your jaws unconsciously as if to echo or mimic the movements of the fingers.” Pointing to the fundamental role of cross-sensory metaphor in language, he notes a “pre-existing translation if you like between the visual appearance and the auditory representation.” This is to be expected and parallels Simon’s idea that “Complexity frequently takes the form of hierarchy and that hierarchic systems have some common properties independent of their specific content”, and that “nature is organized in levels, and the pattern at each level is most clearly discerned by abstracting from the details of the levels far below.”[31] Language is not and cannot be separated from general cognition or from bodily action.

Embodied cognition has developed from environmental filtering, a form of pattern recognition seen as a precursor to survival behaviour.[48] Fundamentally, “all life needs to recognize the patterns that mean food, shelter, or threats to survival.”[48] Embodied language has derived from our ability to thrive in our environments. In our embodied cognition “when perceiving the objects around us, we perceive what they afford to us in terms of action possibilities; i.e. in what ways they are actable.”[49] In doing so we understand the world in terms of our ability to act in and on the world, to better prosper in the world. We have evolved for embodied implemented purposes, and this is reflected in our mental and cognitive structures, the sensorimotor basis of perception.[44], [50], [51] In developing information systems we face the challenge of creating artefacts that are disembodied, implemented purposes, and the difficulties that this brings. Failures of action, such as failures of information systems development, are failures of understanding the world. The sensorimotor basis of perception and cognition provides a significant challenge to the current normative understanding of the nature of requirements.[23]

The action and bodily basis for language, and the concept of metaphors as linguistic action deriving from bodily concepts, are supported by the evidence about the mind as inherently embodied.[25], [38]. Lakoff and Johnson have illustrated that even the most abstracts and formal of fields (philosophy and mathematics) are themselves built on the embodied notions of metaphor and cognitive blending.[23], [25]

We use a metaphor to illustrate the metaphorical nature of understanding itself. The ability to understand an abstract concept is commonly termed an ability to “grasp” the concept. Lakoff & Johnson note that when we think of “grasping” we think of either holding tightly onto something or to understanding an idea. So, the meaning of understanding, itself, rests on a more general “Ideas-Are-Objects” metaphor. The metaphorical translation of this is that “understanding is grasping” produces a conceptual blend that “if an object has gone over one’s head then one hasn’t grasped it” and “If an idea has gone over one’s head then one hasn’t understood it.”[25] Potts [23] points out that a further entailment of this grasping metaphor is that “viewed as a grasped object knowledge is difficult to share or disseminate”.

817


Metaphors based on the body (as extensively documented by Lakoff & Johnson [25], [35]), with a detailed summary of the theory as it pertains to the concept of requirements, can be found in [23].

Pinker summarises the theory of metaphor, noting, “Location in space is one the two fundamental metaphors in language, used for thousands of meanings. The other is force, agency, and causation…. Many cognitive scientists (including me) have concluded from their research on language that a handful of concepts about places, places, path motions, agency and causation underlie the literal or figurative meanings of thousands of words and constructions, not only in English but in every other language that has been studied.” Pinker [5] quoted in [52]. Metaphors are non-arbitrary, universal, hierarchical, fundamental, and overlapping building blocks for language and understanding.

Researchers have recognised elements of the importance and role of metaphors and Language in Information Systems. Thomas & Carroll noted the importance of metaphor in human interaction with the machine, reflecting on human action with each other.[53] Madsen added to this by suggesting approaches for generating, evaluating and developing metaphor to aid systems design [54]. Greenbaum and Mathiassen [55] stress the importance of metaphors in teaching systems development. Hamilton [43] traces how metaphors such as ‘solution to problem’ constrain understanding in problems of Human Computer Interaction. Kendall & Kendall [56] recognised the importance of metaphor in IS failure, looking at the role of metaphor at the organisational level and linking it to how to choose a development methodology. Beck [57] requires the explicit use of metaphor as a practice in Extreme Programming.

Winograd [58] points out that “unconscious metaphor is a central part of language use, including language about and with computer systems (see Lakoff and Johnson, 1980).” Floresand Ludlow [59] introduced the concept of Language Action perspective to Information Systems, arguing that human beings are “fundamentally linguistic and act through language” [34]. The ‘language action’ perspective on information systems takes its main inspiration from Speech-Act theory [37], recognising the fundamental speech act thesis that communication is one kind of action. Winograd [58] recognised

the centrality of metaphor in Language-Action but the field itself has failed to build on this idea.60] Urqhart [61] notes that in early requirements gathering “metaphors are a device used to aid understanding.” More specifically Potts [23], Hamilton, [43] and Brysant [62] all comment on elements of metaphor and its role in Information Systems development.

The focus within information systems has been on the use of metaphor, its role in interface design and its role in shaping thought at the organisational level. For the work carried out to date we can see how thinking is constrained by the use of any single metaphor. We see the emergence of the role of metaphor in communicating understanding through its ability to cross organisational boundaries [63], [64] by building on prior understanding [65], [66], reflecting the cognitive science understanding of metaphor.

4. Metaphors we communicate with

This work on metaphor and the contemporary theory of metaphor derives from Reddy’s theory of the Conduit Metaphor [35]. Reddy, in describing the conduit metaphor, challenges the normative understanding of communication. Expanding on Schön’s idea of metaphor in public policy [34], Reddy recognises the importance of problem understanding rather than problem solving,anticipating section 2 above about the importance of problem setting or problem framing as the critical process as "problem solving" [27].

In describing communications we see language as a carrier of ideas, a conduit from one individual to another. “The way we talk about things ...often depends on root metaphors that are essentially misleading and inaccurate”. Reddy cites typical examples of the ubiquity of the Conduit Metaphor such as “try to get your thoughts across better” and“you haven't given me any idea of what you mean.”[27] Reddy’s assertion is that we see language as a container for meaning, and concurs with the recent evidence from cognitive science. This is the traditional definition of communication in terms of transmitting something from one person to another. The problems ensue when we look at how language, communication and understanding arise in practice, and how this conflicts with the conduit metaphor.

818


Reddy asks us to consider a thought experiment about communication. He asks us to imagine a scenario where individuals are in their own self-contained world, shaped like pie segments in a wagon wheel (figure 1 below). The environments are sealed from each other and have resources in common though not identical to each other: trees, rocks, etc.

Figure 1. (Figure 10.1 in Reddy [10])

The hub of the wheel allows for written instructions to be exchanged between environments, instructions for making artefacts, such as tools for survival. The critical rule is that the written instructions are all that can be exchanged, no face to face contact, no shouting, etc.[27] We see already the similarity to requirement description: the desire for the unambiguous writing of instructions that allows the construction of artefacts. In fact, the situation here represents a simpler case, that of describing the requirements for an artefact that already exists. The environment here represents the human mind, the “internal thoughts and feeling, and perceptions which cannot themselves be sent to anyone by any means that we know of.”[23] The instructions represent the signals of human communication. Reddy ignores the question of how the system of instructions became established. In Section 3 above we presented how the system of communication became established, bootstrapping on our interaction with the environment, accounting for many of the features of metaphor and language.

In this toolmaker world Reddy imagines persons A & B. A invents a rake and sends the instructions for his new invention to B via the hub. This is a simplified version of requirement description as it

describes an artefact that already exists, rather than one that is being imagined.[23] Reddy describes A's environment as containing much wood which A uses to construct his tools. B's environment on the other hand contains mostly rock and, while following A’s instruction he makes the handle of the device from wood, he makes the head out of rock, adapting the design to make it lighter, wondering how strong A must be to use something so heavy. B decides the tool must be for helping to dig up rocks and adapts the design accordingly. B, delighted with his rock-pick, updates the instructions he has used and passes them back to A. Disturbed that B has misunderstood, A “draws a second set of more detailed instructions for the rake head”, which he sends to B. The problem is that, despite furious effort on both A and B's part, the instructions will not match. Reddy describes A in “a kind of absent-minded display of anger” grinding two pebbles together. Suddenly A stops as realisation dawns. He starts writing instructions using “clever iconic symbols for rock and wood which he hopes B will understand.” And eventually B does understand and a new level of communication is reached as previous sets of instructions now begin to make sense. A and B have reached a new level of understanding about each other’s environments.[27] Reddy’s story illustrates many of the problems we encounter with requirements description and artefact creation, the difficulties caused by lack of understanding, the need for rework, and the impossibility of entirely removing ambiguity from instructions.

The alternative conceptualisation – the conduit metaphor - represents a world where the artefacts themselves are transferred via the hub, and building is a matter of replication. Every attribute of the artefact is unambiguously presented and is reproducible. Communication is a matter of transferring an artefact from A to B using an Idea as Object. The difference between the toolmaker paradigm and the conduit metaphor is the difference between the inherent ambiguity of the world and the one where it is possible to remove all ambiguity. Maturana and Varlea [67] reach the same conclusion when examining the biological roots of human understanding: “The phenomenon of communications depends on not what is transmitted, but on what happens to the person who receives it. ... There is always ambiguity in a communication interaction”.Language does not convey meaning, it affords meaning, in Vygotsky’s sense that meaning enacts

819


rather than represents. Communication is about evoking meaning not transferring it, a process not a substance. In examining the failures of systems development Cockburn recognises this when he refers to communication as “touching into a shared experience' with another person …and depends on the experiences shared between the individual people involved” [2]. Meaning derives from the interactive co-ordination of gesture and response through a social act. We can describe the social in human terms as a “highly sophisticated process of cooperative interaction between people in the medium of symbols in order to undertake joint action.”[68] These symbolic processes are always actions. Drawing on Damasio [45], Stacey finds “Mind is the action of the brain, rather like walking is the action of the body”. Symbolic reference is fundamentally built on and grounded in language based on embodied cognition.[67] Metaphor is central as it provides a shared reference for people, based on a universal embodied cognition. Meaning is repeatedly created in the interaction between people.[67] This corresponds very closely to Shannon’s Information Theory as originally presented.[33]

In Information Theory signals are part of a process, not a substance; they do something, they do not contain anything. Reddy notes that “signals” of the mathematical theory are “patterns that can be exchanged”. There is no message contained in the signal, the signals covey the ability to select from a set of possible messages.” In information theory “the system must be designed to operate for each possible selection, not just the one which will actually be chosen since this is unknown at the time of design.” Despite being able – intellectually - to see the problem of the conduit metaphor it has become embedded in Shannon's theory.[27], [69] This is illustrated by reference to Figure 2 below.

Figure 2. Shannon’s communication System from Fig. 1 Shannon (1948) [33]

The variety of possible messages that can be selected from reflects “the economy of language.” [70] Echoing Maturana & Varela, Fauconnier notes “Language forms carry very little information per se, but can latch on to richpreexistent networks in the subjects' brains and trigger massive sequential and parallel activations.”[70] This is the scientific evidence for the descriptions of [25], [38] and [40], evidence also provided by Deacon in explaining the co-evolution of the language and the brain.[71] This aspect of language, instantaneous activation of meaning is similar to and derives from our mode of perception upon which language is based.[39], [44], [70], [71] Language acts as mental scaffolding, working to augment memory and simplify the environment.[44] By associating words with ideas, concepts and actions we“effectively freezes the concept into a sort of cognitive building block- an item that can then be treated as a simple baseline feature for future episodes of thought, learning and search.”[44]. Words act as environmental filters, shortcutting effort, but this shortcut comes with a price, forming conceptual tarpits where our ideas become stuck. Much as train tracks allow for ease of movement, they confine the train to certain paths. Kuhn’s notion of a “paradigm shift” essentially describes a perceptual shift out of the cognitive tarpit. This occurs by replacing one metaphor with a better one, and is a difficult process [72]. A key step in improving communication is changing the frame away from the conduit metaphor.

Day [69] refers to Shannon’s work as the origin of the Conduit Metaphor in Information Sciences, illustrating again the dependence of science on metaphor.[73] Reddy’s analysis of language illustrates that 70% of the terms we use to describe communication are based on the conduit metaphor and explains how the confusion of terms led to Information Theory forming an archetypical example of the Conduit Metaphor. From a software perspective Information Theory has become an example of the confusion about the ability to derive perfect requirements [69]. Reddy notes a highly significant point with reference to Information Theory and the conduit metaphor. We are unable to put the conduit metaphor completely aside even when considering another metaphor for communication. This illustrates a general problem about the difficulty of reframing when dealing with very fundamental concepts. This critical point is

820


overlooked in much of the literature that suggests reframing using new metaphors.[27]

By moving from a conduit metaphor to the toolmakers paradigm we are forced to overturn elements our basic cognitive framework.

5 An Example with Implications for Systems development

One reaction to the problems of systems development, problems described in detail in the first Software Engineering conference in 1968.[2], [74] This proposed formalizing the approach to software development generating more rigorous methods and tighter project management, i.e. more science and less art in development. This was an attempt to turn systems development into a branch of engineering [2] and is reflected in terms such as Software Engineering and Requirements Engineering. These descriptions are themselves metaphors and have significant entailments.[62] They suggest an almost mechanical simplicity and ignore the organised complexity of software systems.[62], [75] Bryant [62] points to the problems embedded in the term Software Engineering and uses metaphor theory and the Conduit Metaphor to illustrate the problems this has caused for Systems development. He overlooks the difficulty in changing deeply embedded metaphors. Potts [23] points to the problems caused for our understanding of the concept of requirements by metaphor theory and embodied cognition. We have seen these problems reflected in practice.

The original concern behind this paper developed from a failed software project involving one of the authors.[26] This software project concerned outsourcing systems development from Ireland to India, and highlights the particular problems encountered in cross-cultural communication, managing virtual teams and the problems of software requirements. This project involved the development of an extranet2 system for a Financial Services company. Much of the work involved the description of an existing artefact, as an older Client/Server3 system preceded the extranet

2An extranet is a private network that uses the Internet protocols and

the public internet system to privately share a business’s information , data or operations with external suppliers, vendors or customers. 3 A computing system in which information and programs are stored on both servers and clients, and processed cooperatively as the client

processor interacts with the server.

development, and illustrates in a practical way the problem Potts posed of whether it is possible to describe an existing software artifact.[23] Development of the extranet system began in February 2001 with a planned release date of November 2001. A cross-functional business team was set up to manage the project. The development was split into two parts: a Web based application (WebApp) used directly by the Customers, and a middleware4 portion (MidApp), which linked WebApp into the main office system. The two parts, interfaced through a Database, were loosely enough coupled to permit parallel development.

WebSoft, a leading Indian Software Vendor, developed WebApp. MQSoft, an Irish software organisation, developed MidApp. After a 5-week on site analysis by WebSoft, a detailed project plan was agreed, a requirements document was signed off and a fixed price contract was approved. WebApp adopted a traditional Systems development Lifecycle Approach (SDLC), following the normative model of Software development. An initial analysis resulting in a requirements document was carried out. This was followed by a design phase, which in turn was followed by a construction phase. These descriptions are themselves metaphors which link to other real world practices; we see software as engineering (requirements engineering), software as architecture (design), software as building (construction). By contrast, MidApp was developed on location in Dublin where the developers worked closely with the IT team, delivering a number of intermediate versions of the system, and proved to be a successful development.

WebApp was premised on a fixed, well-described set of business requirements. Subsequent problems with the system illustrated the pitfalls with this approach, and the difficulty in abstracting intent from implementation. When delivered, the system was buggy, there were significant numbers of requests for changes, and there were significant difference in interpretation of the meanings of the requirements document. These delayed the original project by over six months, increased the overall costs and resulted in a system with significantly reduced functionality. Projects post mortem interviews with members of the Irish and Indian

4 Software that sits between two or more types of software and translates information between them

821


teams illustrate the problems. The WebApp portion of the project suffered from a communications gap, a fundamental lack of understanding of the requirements, problems exacerbated by the virtual, offshore model. Comments from the project participants included

“It’s easier at onsite. There was one to one interaction with the customer. When onshore you can see the person’s body language and what the person is saying. When you are so many miles away, it is necessary to try to reduce the problems by having tighter definitions and processes” Indian Team

“On a lot of these things the requirements change. Sometimes you have to tell people 3 or 4 times before they really understand the requirements. Its just simple communication when people are on the same room, but when they are 5000 miles away its different” – Irish Team

“The problem with communication was not so much different messages from different people but that the message would change with different points in time. Message A would be given at point X then message B would be given at point Y. Everyone in Ireland was singing the same song the problem was that the tune kept changing” - Indian Team

“There was a communications gap on both sides.” – Irish Team

“The problem is we didn’t understand the nuts and bolts of the business at the granular level” - Indian Team

“They didn’t understand the customer” – Irish Team

“We were dealing with a company programming 5,000 miles away. They didn’t understand the customer, or the market process. There was a language barrier even though they spoke English. It must have been difficult for them. I can have sympathy if I was in their shoes” - Indian Team

The inability to understand the requirements, impeded by geography, culture, and language created a communications gap. WebApp needed to bridge a number of cultural domains, organisational and national, technical to business (Ireland – Ireland), technical to business (Ireland – India) and technical to technical (Ireland – India). MidApp by contrast was a wholly technical development and involved only a single small gap (technical – technical Ireland – Ireland).

Adopting the SDLC approach and the normative view of requirements made the development difficult; moving the work offshore and using virtual teams compounded these difficulties. In adopting the SDLC approach the project assumed the normative view of requirements, the ability to completely remove ambiguity and reduce understanding to a document.

Cockburn has described the reduction in understanding that results as richness of communication is eroded.[2], [76] Most communication -most evoked understanding - arises in face-to-face communication; working over the phone, via email and Instant Messenger reduces us to the hub and spoke world of Reddy’s toolmakers, without a proper understanding of how communication takes place.[76] This leads to increased communications difficulties and the problems of WebApp.

An explicit recognition of the conduit metaphor would have acknowledged the risks of adopting the SDLC approach for WebApp. Because multiple interpretations are possible, requirements will necessarily be interpreted in different ways. Using the toolmakers paradigm rather than the conduit metaphor suggests a mechanism for improving development, a mechanism that could have helped WebApp. The requirements should be treated as a starting point to develop dynamic understating, not as the finishing point. Understanding should literally be built with the system. Frequent interaction between onshore and offshore teams is a prerequisite for success. Going further, there is a significant case for a continued onshore presence throughout the project.

A post project review concluded the need for “initiation, and user acceptance testing” in order to “establish trust, increase confidence and help clarify the project objectives for the offshore team”. This also reflects the communication

822


concerns of Cockburn [76] as does the suggestion to use “technological support to help project communications at e.g. low cost technology such as WebCams for face to face communication, in addition to email, phone and instant messenger”. To succeed in proper communications WebApp needed to uncover the different metaphorical concepts that the groups were working with, to make these explicit, and to make sense of the differences between these concepts. This would have involved a continual interaction between the individuals in the project to capture the dynamic context, the meaning and the understanding of what was required from the system. It would have required a continual development and delivery with an ongoing reflection of how the same set of requirements led to different understanding of what was to be done, in essence to reconcile the understanding of the system. This would have enabled ongoing bridge building and avoided the fire fighting that subsequently erupted.

A number of the project comments above related to changing requirements. Fundamentally the system requirements aren’t changing, the understanding of those requirements is changing. This change of understanding is ignored by the conduit metaphor but is explicitly recognised in the toolmakers paradigm that recognised the metaphorical basis of communication. We can see this approach adopted by recent innovations in systems development.

An alternative approach to systems development is that of Agile Software Development.[77], [78] “Agile” implicitly recognises many of the issues raised here when it calls for “individuals and interactions over processes and tools, customer collaboration over contract negotiation, responding to change over following a plan”. Specifically it recognises the impossibility of pure abstract formalised requirements and, in calling for “Working software over comprehensive documentation”, it addresses Potts’ point of the difficulty in separating description and intent from implementation. Cockburn [2] suggests the need for an adjunct model to aspects of his agile approach, suggesting a mental craft needs to be added to Agile Development. “This adjunct model will want to incorporate Peter Naur's consideration of programming as ‘theory building,’ Donald

Schön's idea of ‘reflective conversation with a situation,’ and the issues of efficiency, manipulability and aesthetics of the program”. We suggest that using metaphor in systems development may address this need, and we note that aspects of metaphor are embedded in the Agile development methodology known as Extreme Programming (XP).[57]

6 Conclusions and Suggestions

Systems development is a haphazard process, akin to playing hopscotch in a minefield. Attempts to find a single silver bullet to address the problem have failed.[3] Early successes in Development were based on a well-understood technical problems - developing new electronic switching systems by technical staff who understood switching.[30] Early successes in business software, including the LEO project [79], again involved well-understood problems addressed by people with domain expertise. Software has suffered from an attempt to utilise a wholly mechanical approach to development formalised in the NATO Software Engineering Conference that looked for a “supply of workers who are properly trained, motivated, and interchangeable.”[2] Success in one well understood domain has blinded organisations to the problems that arise when understanding is less well developed. Leading up to the Year 2000 and Euro Changeover much systems development work was outsourced to Indian software companies. This work was for the most part very successful as evidenced by the smooth transfers in both cases. This has led to more work being outsourced using the models adopted by WebApp, and is leading to significant business problems.

Davies [29] proposed the key skills for developing requirements were, “ listening, open-mindedness, feeling, compassion, caring.”and combined within “understanding skills, feeling skills”. Our problem in systems development is a fundamental lack of understanding and a lack of understanding of how we can arrive at understanding. Ultimately because of our embodied nature it is difficult for us to understand what we have not experienced. In formalising our requirements, we become more abstract, we often lose rather than gain understanding, problem that become embedded in our information systems .[80], [81] We have seen the role that metaphor plays in our thinking, for good and ill. We see in them the hope. Metaphor

823


and embodied cognition reflects how we literally map out our understanding.

Everyone makes their own map based on their own understanding; so do communities of practice, academic disciplines, countries etc., leading to the development of cultures.[82], [83] Underlying these cultures are certain universal structures – everyone has the same kind of map. These maps are all pervasive - we use them for every aspect of our decision processes, not just the complex ones to do with work, etc. They are hierarchical - there can be agreement on main bits and variety on minor parts. They are over-lapping – people can be members of many different communities – carrying out multiple roles - at the same time and move with ease from one community to another. Understanding involves iterative re-checking - any disagreement over a cultural issue leads to rechecking about the context, do I understand the current circumstances. This enables people who take part in a dialogue or conversation to establish common ground for understanding.

In addressing the problems of requirements we propose to use some of the cognitive tools that already exist. We suggested in the introduction that storytelling was a key part of human nature. In concluding we return to story telling. Dalcher has pointed to the “key role of story in communicating cultural, moral or historical context to the listener.”[10] He further notes the “strong claims that the narrative is the main mode of human knowledge” Schank (1990),”as well as the main mode of communication” and that children “areoften initiated into culture (and its boundaries) through the medium of story telling, offering models for emulation or avoidance.”[10], [84], [85], [86]

The Irish language is full of ‘seanfhocail’, literally "old sayings" that contain wisdom developed over thousands of years and expressed in metaphors of farming, fishing and rural living. Modern so-called "English" is an international common language that acts as "least common denominator" communication tool, and is mainly devoid of metaphor. Even the few metaphors that remain such as "a stitch in time saves nine" mean little to the modern generation, who never saw anyone knitting, let alone darning or sewing. Systems development usually depends on detailed requirements statements. Yet, when developing their ideas, both those commissioning and those

producing software tend to use metaphors when tentatively communicating their ideas. In a rush to formalise and rely on requirements documents we are losing the context, the meaning and the understanding in the process.

Examining the use of story and metaphor in organisational conversations may provide a mechanism for overcoming the requirements problems. We see here the need to develop requirements that are closely tied to the participants understanding. In the 1970’s the use of narrative was common in specification; however, from the software developers perspective it was deemed that they “neither specify nor inform”. DeMarco in reconsidering his view suggested that “a suitably partitioned spec with narrative text used at the bottom level makes a fine statement of work.”[20] We suggest that the first stage of understanding requirements be in understanding how the organisational participants understand their own situation through the use of story and narrative. This reflects Potts idea that “metaphors suggest ways to translate the authoritative specification into more accessible, local descriptions.”[23]

It is clear that the normative approach to understanding requirements isn’t working. It is also clear that the solutions to resolving the problem should be based on understanding the problem. We suggest that by understanding the embodied nature of thought we are better placed to understand the problems we encounter in developing systems. We can cast a critical eye over the normative frames that constrict out thinking. We also raised some questions for the move to outsourcing. The perceived advantages of outsourcing may never be realised when faced with the difficulties of communication at a distance. At the very least it is important to consider the consequences for communication when planning how the system will be built. It is clearly past time to put out the fires that persist within systems development and begin to build bridges of understanding within and across organisations. Through our understanding of the role of metaphor we begin the first stage in this journey.

References

[1] R. P. Bostrom and B. D. Thomas, "Achieving excellence in communications: A key to developing complete, accurate and shared

824


information requirements," presented at Proceedings of the Twentieth Annual Computer Personnel on Research Conference, Charlottesville, Virginia, 1983.

[2] A. Cockburn, "The End of Software Engineering and the Start of Economic-Cooperative Gaming," ComSIS, vol. 1, pp. 1-32, 2004.

[3] F. P. Brooks, "No Silver Bullet: Essences and Accidents of Software Engineering," IEEE Computer, vol. 20, pp. 10-19., 1987.

[4] D. E. Brown, Human Universals. New York: McGraw-Hill, 1991.

[5] S. Pinker, How the Mind Works, London: WW Norton, 1997.

[6] D. Dutton, "The Pleasures of Fiction," Philosophy and Literature, vol. 28, pp. 453-66., 2004.

[7] M. L. Kaarst-Brown and D. Robey, "More on myth, magic, and metaphor Cultural insights into the management of information technology in organizations," Information Technology & People,vol. 12, pp. 192-217, 1991.

[8] Standish, "The Chaos Report," Standish, 2001.

[9] P. Beynon-Davies, "Information systems 'failure': The case of the London Ambulance Service's Computer Aided Despatch project," European Journal of Information Systems, vol. 4, pp. 171-185, 1995.

[10] D. Dalcher, "Understanding Stories of Information Systems Failures," presented at Action in Language, Organisations and Information Systems (ALOIS 2003), Linköping, Sweden, 2003.

[11] N. P. Repennin, P. Goncalves, and L. J. Black, "The Persistence of firefighting in product development," California Management Review,vol. 43, pp. 44 -63, 2001.

[12] S. Alter, "The Work System Method for Understanding Information Systems and Information System Research," Communications of the AIS, vol. 9, pp. 90-104, 2002.

[13] F. P. Brooks, The Mythical Man Month: Essays on Software Engineering. Reading MA: Addison Wesley, 1995.

[14] P. Naur, B. Randell, and J. Buxton, SoftwareEngineering: Concepts and Techniques. New York: Charter Publishers, 1976.

[15] R. Pressman, Software Engineering: A Practitioner's Approach, Third ed. New York: McGrath-Hill, 1994.

[16] D. I. Cleland, A Guide to the Project Management Body of Knowledge (PMBOK Guide): Project Management Institute, 2000.

[17] IEEE, "Guide to the Software Engineering Body of Knowledge: Ironman," vol. 2005, 3rd ed: IEEE, 2004.

[18] B. Fitzgerald, "Formalised Systems Development Methodologies: A Criticial Perspective," Information Systems Journal, vol. 6, pp. 3-23, 1996.

[19] D. Remenyi, "As the first 50 years of computing draw to an end . . .: what kind of society do we want?" Journal of Information Technology,vol. 17, pp. 3-7, 2002.

[20] T. DeMarco, "Structured Analysis: Beginnings of a New Discipline," in sd&mConference 2001, Software Pioneers, M. Broy and E. Denert, Eds: Springer-Verlag:, 2002, pp. 728pp.

[21] J. Luftman and E. R. McLean, "Key Issues for IT Executives," MIS Quarterly Executive, vol. 3, pp. 89-104, 2003.

[22] S. McConnell, Software Project Survival Guide. Seattle: Microsoft Press, 1998.

[23] C. Potts, "Metaphors of intent," presented at Requirements Engineering, 2001 (RE’01) Proceedings. Fifth IEEE International Symposium on Requirements Engineering, Toronto, 2001.

[24] K. Weigers, Software Requirements.Redmond: Microsoft Press, 1999. [25] G. Lakoff and M. Johnson, Philosophy in the Flesh: The Embodied Mind and Its Challenge to Western Thought. New York: Basic Books, 1999.

825


[26] D. Casey, "Intended Actions, Unintended Consequences: Exploring A Failed IT Development Project," UCD, Dublin, MBA Minor Dissertation August 2001 2001.

[27] M. Reddy, "The Conduit Metaphor - A Case of Frame Conflict in Our Language about Language," in Metaphor and Thought, A. Ortony, Ed., 2 ed. Cambridge: Cambridge University Press, 1993, pp. 164-201.

[28] A. Davies, 201 Principles of Software Development: McGraw-Hill, 1995.

[29] A. Davies, "The Harmony in Rechoirments," IEEE Software, vol. 15, pp. 6-8, 1998.

[30] D. L. Parnas and P. C. Clements, "A Rational Design Process: How and Why to Fake It," IEEETransactions on Software Engineering, vol. SE-12, pp. 251–257, 1986.

[31] H. Simon, The sciences of the artificial.Cambridge, MA: MIT Press, 1996.

[32] Halverson, "Representing Phronesis : Supporting Instructional Leadership Practice in Schools," in Education and Social Policy.EVANSTON, ILLINOIS: Northwestern University, 2002, pp. 411.

[33] C. E. Shannon, "A Mathematical Theory of Communication," The Bell System Technical Journal, pp. 379–423, 623–656, 1948.

[34] D. A. Schön, "Generative Metaphor: A perspective on problem setting in social policy," in Metaphor and Thought, A. Ortony, Ed., 2 ed. Cambridge: Cambridge University Press, 1993, pp. 137-163.

[35] G. Lakoff, "The Contemporary Theory of Metaphor," in Metaphor and Thought, A. Ortony, Ed., Second ed. Cambridge: Cambridge University Press, 1993, pp. 202-251.

[36] D. Gauce and G. M. Weinberg, ExploringRequirements: Quality Before Design: Dorset House, 1989. [37] T. Winograd and F. Flores, Understanding Computers and Cognition: A New Foundation for Design. Norwood, N.J.: Ablex, 1986.

[38] G. Lakoff and M. Johnson, Metaphors We Live By, Second ed. Chicago: University of Chicago Press, 2003.

[39] G. Fauconnier and M. Turner, The Way We Think: Conceptual Blending and the Mind's Hidden Complexities: Basic Books, 2002.

[40] W. Churchill, "The Scaffolding of Rhetoric," 1897.

[41] B. Russell, A History of Western Philosophy, New York: Simon and Schuster; London: George Allen and Unwin, 1946. London: George Allen and Unwin, 1946.

[42] Plato, The Republic. (Trans. Desmond Lee). (Original work written ca. 380BC). London: Penguin, 1955.

[43] A. Hamilton, "Metaphor in theory and practice: the influence of metaphors on expectations," ACM J. Comput. Doc, vol. 24, pp. 237-253, 2000.

[44] A. Clark, Being There: Putting Brain, Body and World Together Again. Cambridge, MA,: MIT Press, 1996.

[45] A. Damasio, Descartes' Error: Emotion, Reason, and the Human Brain. London: Papermac, 1996.

[46] V. S. Ramachandran, Phantoms in the Brain: Human Nature and the Architecture of the Mind.London: 4th Estate, 1998.

[47] V. S. a. E. M. H. Ramachandran, " Synaesthesia--a window into perception, thought and language.," Journal of Consciousness Studies, 8, 3-34., vol. 8, pp. 3-34, 2001.

[48] B. Hill, "The Magic of Reading," vol. 2005: Slate, 1999.

[49] G. Goldkuhl, "Meanings of pragmatism: Ways to conduct information systems research," presented at Action in Language, Organisations and Information Systems (ALOIS 2004), Linköping, Sweden, 2004. [50] H. Maturana and F. Varela, Autopoiesis and Cognition: The Realization of the Living, vol. 42. Dordecht (Holland): D. Reidel Publishing Co, 1980.

826


[51] A. Noë, Action in Perception (Representation and Mind). Cambridge, MA: MIT Press, 2005.

[52] J. Lawley and P. Tompkins, Metaphors in Mind. London: The Developing Company Press, 2000.

[53] J. C. Thomas and J. M. Carroll, "Human factors in Communication," IBM Systems Journal,vol. 20, pp. 237-263, 1981.

[54] K. H. Madsen, "A guide to metaphorical design," Communications of the ACM, vol. 27, pp. 57-62, 1994.

[55] J. Greenbaum and L. Mathiassen, "Zen and the Art of Teaching Systems Development," Computers and Society, vol. 20, pp. 523-533, 1990.

[56] J. E. Kendall and K. E. Kendall, "Metaphors and Methodologies: Living Beyond the Systems Machine," MIS Quarterly, vol. 17, pp. 149-171, 1993.

[57] K. Beck, Extreme Programming Explained: Embrace Change: Addison-Wesley, 1999.

[58] T. Winograd, "A Language/Action Perspective on the Design of Cooperative Work," Human-Computer Interaction, vol. 3, pp. 3-30, 1987.

[59] F. Flores and J. J. Ludlow, "Doing and Speaking in the office," in Decision Support Systems: Issues and Challenges, G. Fick and R. S. Jr, Eds.: Pergamon Press, 1980, pp. 95-118.

[60] D. Casey and C. Brugha, "Understanding the Situation of Information Systems Development Failure: A role for Pragmatism" presented at Action in Language, Organisations and Information Systems (ALOIS 2005), Limerick, Ireland, March 21-23 2005.

[61] K. Uqhart, "Themes in early requirements gathering," presented at IFIP Working groups 8.2 and 8.6 joint Working Conference on Information Systems: Current Issues and Future Changes, Helsinki, Finland, 1998.

[62] A. Bryant, "Software Engineering - solution to the software crisis, or part of the problem?" presented at ICSE 2000, Limerick, Ireland, 2000.

[63] S. Cook and J. S. Brown, "Bridging Epistemologies: The Generative Dance Between Organizational Knowledge and Organizational Knowing," Organization Science, vol. 10, pp. 381–400, 1999.

[64] C. F. Kurtz and D. J. Snowden, "The new dynamics of strategy - sense-making in a complex-complicated world," IBM Systems Journal, vol. 42, pp. 462-484, 2003.

[65] P. Agerfalk, "Pragmatization of Information Systems - A Theoretical and Methodical Outline," in Dept f Computer and Information Science.Linkoping: Linkopings universitet, 1999, pp. 177.

[66] J. Preece, Y. Rogers, H. Sharp, and D. Benyon, Human Computer Interaction: Addisson-Wesley, 1994.

[67] H. Maturana and F. Varela, The Knowledge Tree: The Biological Roots of Human Understanding”, Revised ed. Boston: Shambala, 1992.

[68] R. Stacey, "The Emergence of Knowledge in Organisations," Emergence, vol. 2, pp. 23-49, 2000.

[69] R. E. Day, "The "Conduit Metaphor" and The Nature and Politics of Information Studies," Journal of the American Society for Information Science (JASIS), vol. 51, 2000.

[70] G. Fauconnier, "Introduction to Methods and Generalizations," in Methods and Generalizations: Scope and Foundations of Cognitive Linguistics,Cognitive Linguistics Research Series, T. Janssen and G. Redeker, Eds. The Hague: Mouton De Gruyter, 1999, pp. 95-127.

[71] T. Deacon, The Symbolic Species: The Co-evolution of Language and the Brain. NewYork: W.W.Norton, 1997.

[72] T. S. Kuhn, The Structure of Scientific Revolutions, 3 ed. Chicago: University of Chicago Press, 1996.

[73] T. Roher, "When Metaphors Bewitch, Analogies Illustrate, And Logic Fails: Controversies Over The Use Of Metaphoric Reasoning In Philosophy And Science," in Philosophy: University of Oregon, 1999, pp. 176.

827


[74] P. Naur and B. B. Randell, "Report on a conference sponsored by the NATO Science Committee," presented at Software Engineering, Garmisch, Germany, 1968.

[75] G. M. Weinberg An Introduction to General Systems Thinking, Silver Annivesary ed: Dorset House, 2001.

[76] A. Cockburn, "Characterizing People as Non-Linear, First-Order Components in Software Development," presented at 4th International Multiconference on Systemics, Cybernetics, and Informatics, Orlando, FL, 2000.

[77] M. Fowler and J. Highsmith, "The Agile Manifesto," in Software Development, 2001.

[78] J. Highsmith and A. Cockburn, "Agile Software Development: The Business of Innovation," IEEE Computer, vol. 34, pp. 120-122, 2001.

[79] F. Land, "The First Business Computer: A Case Study in User-driven Innovation," IEEE Annals of the History of Computing, vol. 22, pp. pp. 16-26., 2000.

[80] T. Davenport, "Saving IT's Soul - Human Centered Information Management," Harvard Business Review, vol. 72, pp. 119-131, 1994.

[81] V. A. Martin, M. Lycett, and R. Macredie, "Exploring the Gap between Business and IT: an Information Culture Approach," presented at Action in Language, Organisations and Information Systems, Linköping, Sweden, 2003.

[82] E. Schein, "Three Cultures of Management: The Key to Organizational Learning," MIT Sloan Management Review, vol. 38, pp. 9-20, 1996.

[83] E. Schein, "Culture: The Missing Concept in organization studies," Administrative Science Quarterly . vol. 4, pp. 229 - 239, 1996.

[84] S. Denning, The Springboard: How Storytelling Ignites Action in Knowledge-Era Organizations. Boston: Butterworth-Heinemann, 2001.

[85] W. R. Fisher, Human Communication as Narration: Towards a Philosophy of Reason,

Value and Action. Columbia: University of South Carolina Press, 1987.

[86] R. Shanck, Tell Me a Story: Narrative and Intelligence. Evanston: Northwestern University Press., 1990.

About the Authors

Dermot Casey is PhD Student in the Dept of MIS, University College Dublin. He over 12 years of systems development experience, working most recently as an IT Project Manager. A member of the IEEE, the ACM he as a BSc in Computer Science and an MBA also from University College Dublin

Dr Cathal Brugha is a Senior Lecturer, Department of Management Information Systems, UCD Business Schools, University College Dublin; Director, Centre for Management Science and Systems, Quinn School of Business, University College Dublin, Belfield, Dublin 4; General Editor, International Transactions in Operational Research, official journal of the International Federation of Operational Research Societies; President, Management Science Society of Ireland; Fellow, Marketing Institute of Ireland.

828

Documents

[IEEE IPCC 2005. Proceedings. International Professional Communication Conference, 2005. - Limerick, Ireland (July 7, 2005)] IPCC 2005. Proceedings. International Professional Communication