1. INTRODUCTION

Term projects are a central element in many classes addressing information-systems (IS) development. One popular basis for term projects is the written case study. In addition to using published case studies, many of us in the IS educational community develop our own cases. We do so, in some instances, because this gives additional control over the types of challenges we can present to students. We may also write our own cases where we identify a good opportunity to leverage our personal experiences in some business domain.

This paper examines what it means to author a systems-development case. It draws on recent research in narrative studies and learning theory in an effort to develop a systematic perspective on the case-writing task. The goal is to identify some practical guidance for case writers, but to do so within an integrated framework grounded in theory, rather than in an ad hoc way. The author's recent effort in writing and using a hypothetical case study illustrates a number of the points.

A comment about scope is in order. Our interest here is in term projects that engage students in the analysis of business problems and the articulation of systems solutions. This is in contrast to "programming projects," that is, projects that focus on the technical implementation of software. Accordingly, the perspective offered here most clearly addresses term projects in systems analysis and design courses, database management courses, and systems-development classes that are relatively comprehensive, or "end-to-end," in nature.

2. THE SYSTEMS-PROJECT CASE STUDY AS NARRATIVE

The case study tells a story; it involves narrative,1 and therein lies its unique strength as an educational tool. Narrative occupies a central place in human cognition and learning (Bruner 1986, 1990; Norman 1993; Schank 1990). As Boland and Tenkasi remark (1995: 350), "cognition includes a capacity to narrativize our experience as well as a capacity to process information." While we commonly view cognition to be a matter of information processing, it is principally by means of narrative that we "endow experience with meaning" (Bruner 1986: 12). Stories and storytelling, also, are central in our efforts to make sense of the events taking place around us and of our own actions in relation to those events (Weick 1995: 61). Such sensemaking, moreover, is fundamentally social in nature, and so stories come to play a central role in how we communicate and share knowledge with one another (Boland & Tenkasi 1995; Czarniawska 1998; Fisher 1987). Finally, stories not only are a collective means to better understand new or challenging aspects of the world; they also play a central role in the individual's efforts to create and maintain personal identity, and to comprehend the personae presented by others (Polkinghorne 1988).

While narrative accordingly plays a crucial and multifunctional role in sensemaking and learning generally, within the classroom its particular value is in helping to promote learning that is active and situated (Brown et al. 1989: 40). Active learning strategies recognize that (Elmore 1991: xii):

People learn to the degree to which they can actively manipulate facts within some general framework and can relate general ideas to specific events in their experience. We have knowledge, in other words, only as we actively participate in its construction.

Active learning therefore contrasts with traditional approaches that treat teaching as a matter of information transfer based on abstracted facts, prescriptions, recipes, and formulas (Brown et al. 1989; Bruffee 1993; Christensen et al. 1991; Dewey 1938; Garvin 1991; Whitehead 1929). The concept of situated learning adds the further recognition that acquiring knowledge is fundamentally contextual. In order to be useful in solving future problems, knowledge must be acquired through problem-solving activity in authentic situations (Brown et al. 1989; Bruner 1990; Elmore 1991; Lave & Wenger 1991; McLellan 1995). In short, "situations might be said to co-produce knowledge through activity" (Brown et al. 1989: 32).

The systems-development term project, of course, is an important means by which IS faculty engage students in active learning. The project case study, then, helps to provide the context, or situation, that makes students' active learning situated. This is true in two ways. First, the story presented in the written case gives an account of a situation, replete with settings, actors, events, and problems, relative to which students can visualize the concrete application of the concepts and techniques that are part of the formal subject matter of the course. Second, the term project itself extends the narrative beyond what appears on the printed page. T hat is, in carrying out their project assignments, students become participants whose actions in a sense continue the story about the business. As the students' deliverables move the business from problem to resolution, they in effect add "chapters" to the case.

These two narrative aspects of the systems-project case study provide a point of departure for considering storytelling in the case from a more systematic point of view. We turn to this task next, with the aim of creating a structural model of case-study narrative that can be used as a point of reference in writing new case studies.

3. A NARRATIVE FRAMEWORK FOR THE SYSTEMS-PROJECT CASE

Figure 1 depicts the narrative aspects of the systems-project case. This includes the business case itself and also the project, which again represents a kind of narrative extension on the case. Figure 1 adds the concept of mini-narratives, which will be explained shortly; it also suggests how the deliverables of the project - and, implicitly, the activities that produce them - help to define the project's narrative structure. All of these elements represent opportunities for the faculty member, as the case-study author, to enlarge the term project's learning value.

3.1 The Business Case

What Figure 1 labels the "business case" gives the story about the business that is the basis for the students' project work. Business cases are usually simple in structure. They typically include the following elements, often (although not always) in the following order. First, the case gives some background on the organization, including the type of business it is in, some sense of its scale of operations, the larger business context (if the focus of the case is on an organizational sub-unit), the institutional and competitive context, and perhaps a bit of history. Next, the case raises specific information-management problems having negative effects on current business operations or, perhaps, posing barriers to new opportunities. These problems, of course, provide the motivation for the project and also help to focus attention on specific aspects of the business. The case then provides details with which students must engage, as they carry out the analytical tasks in the project. Depending on the subject matter of the course, the emphasis here may be placed on processes, data, or both. The amount of detail given is governed by the requirements of the project assignments. Samples of business documents are typically included. These documents illustrate the structure and content of data in the firm, and also help to illuminate the firm's business processes, since they represent artifacts that are crucial in the firm's transactions and decision making.

Characters are introduced into the story at one or more points. Characters help to animate the story and, as they speak on behalf of the business, they familiarize students with users' speech, one of the principal modes in which analysts and designers encounter data about user requirements. I have, for the most part, used a single speaking character in the cases I have written, commonly the principal client or main point of contact in the case. However, multiple characters can be used to good effect in showing partial, and in some cases conflicting, perspectives. See the excellent set of cases by Dewitz (1996) for examples of this approach. The information provided by the characters may be delivered through such devices as letters, and memos (see my sample case, below) or fictional interviews (again, see Dewitz 1996). The case's business documents, noted above, are often introduced as if being presented by the characters.

The business case is commonly composed as a single document - which is how we are used to seeing published cases - but this need not be the case. Alternatively, the case can be rolled out in installments. This approach is illustrated in the case example given later in this paper. There, background information and a general introduction to the business's problems are offered in an "opening scenario." Detailed information, including business documents and more complete descriptions of issues and problems, are then presented in a series of "client memos."

Like other pieces of writing, the business case must have a beginning, a middle, and an end. However, the end of the business case by itself does not provide full closure, because it is by its essential nature only half of a story. The students' work on the project actually provides the end of the story, as it carries the business from problem to resolution. (Refer again to Figure 1.) Accordingly, the end to the business case, formally speaking, is provided by whatever device the author/instructor uses to launch the students on the project. This may be done explicitly within the case by a characterization of the "task that lies ahead." Alternatively, it may be done by the instructor through comments outside of the case, while the case itself simply trails off at the point where the author decides that sufficient information has been provided.

3.2 Mini-Narratives

Storytelling plays an important role in the kinds of real systems-development projects that the term project is designed to simulate, as it does more broadly in other knowledge-based activities in organizations (Boland & Tenkasi 1995; Swap et al. 2001). Narrative activity is prevalent among users during requirements analysis (Alvarez 2001), and narrative has a significant place in participants' efforts to rationalize project actions and outcomes (Brown 1998; Brown & Jones 1998). The importance of storytelling in real projects, then, suggests the potential for working "mini-narratives" into the larger business case that focus on particular problems or issues. Mini-narratives make specific points more tangible and vivid, and help the business case overall to read in a more natural and compelling way. Told by the characters themselves, stories are also an effective device for exposing students to the manner in which business people (and clients) think and talk about their own worlds. Since, as noted earlier, the objective in situated learning is to foster problem-solving in authentic situations (Brown et al. 1989), having case-study characters tell stories provides an opportunity to enhance the authenticity of our cases.

3.3 The Term Project as Narrative-in-Action

A number of social and organizational theorists have argued that "social life is best conceived of as an enacted narrative" (Czarniawska 1998: 3). For one thing, human action has narrative properties, with sequences of interrelated events and plots to provide coherency (Ricouer 1981; White 1981). Human action makes sense as narrative, given participants and observers equipped with the appropriate cultural presuppositions. Moreover, for the participants specifically narrative is also generative of action. That is, people act creatively upon cognitively prefigured stories, and they also develop stories together through their negotiated interaction. This relationship between narrative and human action points toward the appropriateness of a "dramatist analysis of human conduct" (Czarniawska 1998: 3). Dramatist (or "dramaturgical") analysis employs the metaphor of the theater to identify personae, roles, and relationships for social actors, and rules for structuring and interpreting action in particular contexts (Burke 1969; Feldman 1995; Goffman 1959, 1967, 1974). Relative to practice, dramatist analysis suggests paying conscious and deliberate attention to narrative structure and staging in the active design of social activity.

In this light, we can view the term project as a kind of drama or living narrative which the participants themselves cooperatively build as the course proceeds.

As characterized earlier (Figure 1), the project extends the story begun in the written business case, as it provides the situation in which students' situated learning is operationalized. It is useful, then, for the faculty member to view the project itself as an undertaking in narrative design.

As the author of the project, the faculty member's central pedagogical challenge is to situate the student effectively as a "character" in the overall drama. This is accomplished by giving students an explicit role in relation to the business's story (e.g., as "consultants") that is integral to the working-out of the underlying plot. That role is given substance by the set of assignments that operationalize the project activities and define the responsibilities, tasks, and knowledge required of the role. The project role not only identifies the substantive skills the student must learn. It also supports the student's efforts to construct a professional identity for him/herself. Moreover, it helps to foster the student's understanding of how that identity has generative potential for creating the kind of "lived narrative" that produces systems solutions. To continue the dramatist metaphor, the term project is a kind of "dress rehearsal" in which students prepare for professional life on the larger stage of real systems projects.

The sequence of project assignments provides the basic storyline, one that carries the business from an identification of its problems toward a system design that (in theory, at least) represents a resolution to these problems. The actual details of this resolution are filled in by the students through their work on the assignments. Of course, organizing a term-project timeline, defining deliverables, and creating assignments are tasks familiar to all experienced faculty. The specifics vary along such practical dimensions as subject matter, the learning objectives for the class, and the time available. Regardless of the particulars, however, viewing the term project as a kind of narrative-in-action, in which students have a central role as characters, can help the faculty member keep in focus the larger goals to be accomplished. When we ask ourselves how well the project experience is preparing our students, the narrative perspective invites us to extend our view beyond the concepts, tools, and techniques that make up the bread and butter of our systems-development courses to consider larger questions about skills in inquiry and problem-solving and the construction of professional identity.

3.4 Rhetorical Qualities of the Case Study Narrative

As just described, Figure 1 gives us a narrative-structure perspective on the systems-development case study. As narrative, the case study can be evaluated for its rhetorical effectiveness, that is, for how convincing or persuasive the reader finds it (Perelman 1982). Overall effectiveness, in this regard, depends on how well the case taps into students' existing frames of reference while simultaneously taking them to a new understanding that lies beyond those frames.2

However, as literary theorists, rhetoricians, and philosophers have come increasingly to recognize (Eagleton 1983), meaning is not inherent in any given text. The reader is essential, because the reader actively supplies the meaning in interaction with the text. This entails a very practical point for the case writer who hopes to take the student to a new level of understanding. The writer must keep in view what it will take to support the student's interpretive efforts. Here, attention to some specific rhetorical qualities3 can help in the accomplishment of the overall goal, including relevance, practicality, clarity, plausibility, authenticity, and compellingness.

Pedagogical relevance is decided first and foremost by whether the case serves the term project's learning objectives. If, for example, the instructor wants to engage students in a challenging data modeling exercise involving an assortment of advanced features (e.g., subtyping, recursive relationships, ternaries, etc.), then the business situation will need to have the requisite complexity. If the instructor wants the students to create a model of business process from a set of partial perspectives, the case will need to describe the process from the point of view of a number of different characters in differing organizational roles. Relevance obviously depends on richness: The case story must introduce facts and situations that exercise the entire range of learning objectives set for it.

Practicality points toward the fact that the case must conform to practical constraints in the teaching situation. Practicality is determined, to a substantial degree, by complexity. A case that is too complex can overwhelm students' efforts and place unrealistic demands on the project timetable. Of course, a case can also be insufficiently complex and thereby fail to support the project's learning objectives - an equally impractical result. Thus, complexity represents a point of control for the instructor to exploit in achieving the appropriate degree of challenge for the students.

Clarity means that students can readily understand the facts of the case. Clarity depends, at its most basic level, on the mechanics of writing: good organization, straightforward sentence structure, appropriate word choice, and so on. Clarity also depends on fitting the writing to the students' scope of experience. Thus, in coming up with metaphorical or analogical references, or working humor into the case, the faculty member needs to be alert to potential problems with intergenerational and cultural gaps.

Plausibility means that the case is acceptable to students as likely, reasonable, and not far-fetched or absurd. The story must be convincing, notwithstanding whatever simplications may be necessary to make it work as a pedagogical tool. In writing cases, however, the faculty member enjoys a softer standard for plausibility than applies to many other types of writing. This is especially true for hypothetical cases: Students generally recognize that such cases are designed for teaching purposes and will not necessarily show all the hallmarks of a "real" story. Even so, as is true for more sophisticated forms of fiction, a case should read like something that could happen. Events that take place should seem reasonable, and characters in the story should talk more or less like real people do.

Authenticity is the degree to which the case presents the kinds of facts, events, and activities that actually appear in the world of practice. Authenticity accordingly helps to determine plausibility: Students should be able to conclude that the situation presented in the case bears some useful resemblance to the real problems they will be dealing with "out there." Authenticity, however, does not guarantee plausibility, because students tend to lack the real-world experience that would allow them to make fully sound judgments about a case's authenticity. (Some students, of course, are prone to overestimate their ability to evaluate authenticity.)

Authenticity is probably best assured by the author following the advice commonly given to aspiring young writers: "Write what you know." This advice is not nearly as constraining as it might sound. Because case-writing is not the creation of high literature, the task does not demand subtleties in character development or rich settings or dense irony. Accordingly, the case author is not necessarily limited to writing about business situations of which s/he has first-hand knowledge. Nevertheless, it is important to draw for the details of the case on relevant direct experience in actual organizational settings, in order to bring into the case realistic elements of business processes, data, documents, and problems.

Finally, compellingness means that the story engages students' attention. The standard here is also relatively undemanding - compared, say, to commercial authorship where sales depend on quickly seizing and holding prospective readers' attention. After all, students are a captive audience and must read the case in order to carry out the project. Even so, a more compelling story improves retention and helps students be more efficient in their interaction with the case. Among the things that can help make the case compelling is to focus on a business domain to which the majority of students can readily, and even enthusiastically relate. For this reason, retail enterprises often make an obvious choice for cases. On the other hand, novelty can also foster compellingness, although care must be taken to provide everyday points of reference, so that clarity is maintained.

3.5 Summary

To this point, we have entertained a general narrative perspective on the systems-project case study, including the different kinds of narrative components in and around the project, and some rhetorical qualities against which the case study can be evaluated. Next, we will consider a recent case study prepared by the author,4 in order to make more tangible a number of the points offered in the preceding discussion. The goal in presenting this example is not to suggest or prescribe a standard structure or particular type of content for systems-project case studies. The potential for variety in case studies is very large. Instead, the goal in what follows is simply to highlight certain things to consider, and particular opportunities to be alert to, as faculty members write cases.

4. A CASE STUDY

4.1 Structure and Contents

The case study described here was developed for use in an introductory database management course for undergraduate information systems majors. Since database design is the focus of the course, the case is light on business-process details. On the other hand, the course emphasizes data-requirements analysis and logical database design and so, in other respects, the case is much like the kind that would support a systems analysis and design course.

The business case was written in installments during the term in which it was first used, and these installments were given to the students as their work proceeded on the project. Figure 2 shows phases in the writing effort alongside the deliverables that gave shape to the larger "project narrative." Case installments appear in italics. The schedule of project assignments was established before the course began, in order to promote better schedule control and to provide the students with a stable set of expectations. Students prepared and turned in the project deliverables on the timetable indicated; these were reviewed and returned to the students with comments. At the end of the term, the students assembled updated versions of this work in a final project deliverable, the Database Project Report.

As the figure suggests, the business case is launched by means of an Opening Scenario and is subsequently elaborated in a series of Client Memos. The Opening Scenario provides sufficient background about the business and its information-management problems to enable students to prepare a short project-justification document, the main purpose of which is to engage the students in certain core database-management and relational concepts. Client Memos then provide the details needed for data modeling and the development of detailed database specifications. We will examine more closely how these installments operationalize the case features outlined in more generalized terms above. These features, again, are the business context, the business problems, and the details of process and data required for substantive analytical and design work.

The general business context is described mainly in the Opening Scenario, although selected aspects are revisited in greater depth in subsequent Memos. This mirrors how an analyst learns about a business on a real project, with a broad understanding typically coming early on, followed by clarifying insights later.

The overall story, which draws on the author's experiences working in contract archaeology, centers on a university-based cultural resources management (CRM) facility. Because this business domain is unfamiliar to most students, the Opening Scenario not only gives basic facts about the CRM facility in question but also characterizes the larger business of CRM and identifies its institutional origins in state and federal laws relating to historic preservation. Three primary business areas are identified for the CRM facility, as described in the following passage from the Opening Scenario:

Coastal State University's anthropology department runs a non-profit program in prehistoric archaeology and cultural resources management (CRM). Located in the basement of Gould Hall on the university's main campus, the CS/CRM facility performs a number of important functions. It serves as curator for a large number of archaeological collections. It also functions as the official Regional Clearinghouse for written reports and maps that document the known archaeological sites in the state. CS/CRM also carries out projects under contract to various public agencies and private entities. Specifically, CS/CRM sends teams of staff archaeologists and students into the field on surveys, in order to identify and assess the extent of cultural resources in locations threatened by development. And CS/CRM also conducts archaeological excavations, where these are needed in order to mitigate damage to cultural resources through scientific documentation and the recovery of physical materials. Through these field projects, CS/CRM works with its sponsoring department to provide training for graduate students in archaeology.

The Opening Scenario goes on to situate CS/CRM's Projects function in its larger competitive environment, noting specifically how CS/CRM competes in surveying and mitigation work with private contract archaeologists. CS/CRM, the Opening Scenario observes, enjoys a competitive edge because of its stewardship of the Regional Clearinghouse and Collections Facility. This automatically gives CS/CRM a high profile in the marketplace. Meanwhile, inexpensive student labor and university subsidies give CS/CRM an additional advantage on the cost side of the equation.

These favorable conditions, however, are far from secure - the point which provides the dramatic tension in the story and the fundamental motivation for the database project:

The key to CS/CRM maintaining its position depends on its image and reputation among the governmental agencies and large private parties that contract for work, as well as the entities that oversee the enforcement of historic preservation laws and policies (e.g., the State Office of Historic Preservation (SOHP), county planning commissions, etc.) CS/CRM's reputation, in fact, has suffered of late. The quality of its contracted field services continues to be very high, in part because of the close supervision provided by the anthropology department faculty. On the other hand, CS/CRM's reputation also depends on the quality of its back-office operations, especially in its clearinghouse and collections functions. And in these areas, there have been increasingly serious problems.

The case goes on to describe problems in each of the three business areas. All relate, in one way or another, to CS/CRM's primitive and largely paper-based arrangements for tracking information. The consequences - such as misplaced reports, lost archaeological collections, slow service, and irregularities and conflicts in project staffing - are tallied. Dire implications, including the threat of withdrawal of institutional sponsorship, loom. Taking the perspective of Doug Fredericks, CS/CRM's director, the Opening Scenario reports:

Fredericks recognizes that continuing problems like the ones noted pose the very real threat that CS/CRM could lose the privilege of hosting the Regional Clearinghouse. Meanwhile, the University president has already informed Fredericks that many more complaints about Collections will lead to the withdrawal of University support for that operation. Losing either of these functions (but especially both) would clearly damage CS/CRM's legitimacy. This, in turn, would seriously hamper CS/CRM's ability to win survey and mitigation work, which would then undermine CS/CRM's capacity to support its host department's educational mission.

Apropos the problems in the Projects area, students are told that:

... No project deadlines have yet been missed, and no clients have complained. Nevertheless, Fredericks is aware that looming trouble in the field could be a knockout blow to his organization.

On a positive note, the Opening Scenario reports that Fredericks and his senior staff are taking steps to develop a system solution for CS/CRM's information-management problems. This sets the stage for the students' term-project work:

[The ArchOp system] would get the information used to track projects, archaeological site reports, and collections - all of which currently exists in paper form - "into the computer." The information would then be made available to CS/CRM staff members at networked PCs throughout the main facility and in the Collections building. ...

Their current hurdle, as they develop their proposal for ArchOp, is figuring out what it really means to get the information "into the computer." This is where you come in.

The Opening Scenario then concludes with an overview of the analysis, design, and prototyping tasks that constitute the database project work.

The Opening Scenario allows students to develop an understanding of the larger problems the organization faces, but it lacks the details required for the subsequent analytical work. These are provided in the Client Memos, ostensibly written by Doug Fredericks and addressed to the student consulting teams. The first and third client memos provide detailed information on the Collections and Projects business areas. Both of these memos run to several pages and include a variety of sample documents that point students toward the details of data structure they will need to represent in their data models and, eventually, capture in their detailed data definitions. (Figures 3 and 4 provide examples. The Appendix provides some sample text, which gives a general sense of the tone and style of the descriptive passages in these memos.)

The second and fourth client memos (refer again to Figure 2) do not provide detailed case information, but rather serve to reduce the scope of the project from that initially suggested by the Opening Scenario. This scope-reduction is an artifact of the inaugural use of the case, which has since been made a durable part of the case narrative. It became apparent, as the case was being written and delivered to the students, that the business problem would demand too large a data model and too voluminous a set of detailed data definitions, given the schedule constraints involved. The second client memo accordingly sets aside the Clearinghouse function from further consideration, once students complete the initial project-justification assignment (Project Exercise 1 in Figure 2). This shift in project scope is made a part of the overall story through the use of a mini-narrative. Fredericks relates the following story about a conversation between the client and one of his organization's primary stakeholders:

Well, I have a new development to report. I had a meeting y esterday with the chief of the State Office of Historic Preservation... mainly to discuss our data management issues in the Clearinghouse. But of course I'm telling him about the overall system project, because it all ties together. He red-flags the idea of having a unified database for the Clearinghouse, Collections facility, and CS/CRM's projects.

The difficulty, which is not a new issue, has to do with potential conflict of interest. Private CRM consultants have been complaining for years about the fact that we run the Clearinghouse, which is this central resource

that everybody uses, but we also compete for projects. In my opinion, we'd have lost the Clearinghouse a while ago if it weren't for the fact that the university shares the costs of it with the SOHP.

So, what does this mean for our current project? We're going to have to develop a separate database for the Clearinghouse. And we're going to put that off. The SOHP has some specific requirements they want satisfied, and they're willing to kick in money. But they have to wait for next Fall's legislative session, before they'll know about funding. ...

The data modeling work (Project Exercise 2) then proceeds on the basis of the Collections and Projects areas. However, upon completion of this exercise the project is again downsized, mainly in order to reduce the amount of repetitive work required to prepare detailed database design specifications. The fourth client memo sets aside the collections area, again in a manner that makes the shift in scope part of the overall narrative:

We've had a new development here, at CSU, that has some bearing on this. The president of the university is talking about giving us some funding for software development on the Collections side of things. We're still negotiating but it looks like one element of that would be some involvement on the part of the IT people from the university. I think we're talking mainly about symbolic participation, but until that's a bit clearer, we need to work on something else. So here's what I'd like you to work on: You should focus on the project staffing side of things. Getting something going in that area will be very helpful in our efforts to improve our internal management. ...

The client memos make judicious use of other mini-narratives in order to make more vivid the problems introduced, in a more abstract way, in the Opening Scenario. For example, in the collections memo what is in practice a truly significant problem in archaeological-collections management is introduced by means of a story that simultaneously highlights CS/CRM's data-management troubles:

Let me start with a story that'll give you the basic idea about our current problems in Collections. Under repatriation laws, a collections facility like ours can no longer hold human remains or funerary objects that can be linked to contemporary Native American groups. ...

Okay. So the story is that a researcher was reading about an early field project, done around 1920 by a faculty member from Berkeley. He wanted to track down the collection from that excavation. He had been doing ethnographic interviews with some of the elders from a coastal tribe, and some of their grandparents and great-grandparents had actually lived at this site, in the late 19th century, where this Berkeley excavation took place later on. His main goal was to get some of the materials that had been recovered, so he could present them to his informants for comment and discussion. But the old project report had also mentioned that some bones and grave goods were part of the collection.

Berkeley no longer had the materials, because everybody associated with the original project was long since retired and dead. You see where this is headed, right? With a series of phone calls, he was able to track the collection down to our facility. We have some very old material in Collections that we "inherited" from various university collections, when we first started up. So, the researcher shows up with the daughter and son-in-law of one of the elders. And we can't find the collection. Well, we did eventually. But we had no record of it in our tracking system. So we had to put two graduate students in the storage rooms for a couple of weeks, opening up the older boxes and looking inside. Needless to say, it was very embarrassing. Fortunately, the grave items had been removed at some point in the past. Our policy is to return a collection that has such items to the donor, but we'd have been hard-pressed to identify the responsible donor in this case, because of our laxness in handling this collection at the beginning.

4.2 Rhetorical Aspects of the Case

As noted earlier, viewing the case study as a kind of multi-layered narrative invites its consideration from a rhetorical perspective. The rhetorical qualities we entertained, again, are relevance, practicality, clarity, plausibility, authenticity, and compellingness.

A case's relevance, as we noted earlier, is defined by its fit to the learning objectives of the project. Practicality, meanwhile, is satisfied by presenting a problem that can be accomplished within the constraints defined by the structure and timetable for the course. For the database course in question, what is wanted is a story that offers a reasonable level of challenge for undergraduate students with little or no prior experience in data modeling and database design. With respect to relevance, then, this case succeeds in presenting a situation that demands the use of a range of basic data model features, and that sets up at the attribute level a number of interesting opportunities for specifying various integrity constraints. The challenge, however, remains within the bounds of what students can be expected to learn in a first, and relatively brief, course in database design. As noted, achieving practicality the first time through required some "in-flight" adjustments to the scope of the case; made an integral part of the story, these adjustments now offer the opportunity to make a pedagogical point about the significance, and prevalence, of scope shifts in real projects.

Clarity in the case reflects the deliberate care in organizing and writing the case documents and assignments, including attention to the logical ordering of materials, the placement and definition of business-domain terms (e.g., see "debitage" in the Appendix), and the task of editing. Students appear to have little difficulty understanding what the story about CS/CRM has to tell them about the business; their questions, for the most part, do not relate to the facts of the case but focus rather on the application of the analytical techniques that make up the technical subject matter of the course. Even so, quality in exposition is largely a matter of editing, and for a living document, like a case study, that sees repeated reuse, editing is a never-ending chore (and opportunity). In short, I expect to revise the case, more than once, as I reuse it in my classes - not only to enhance its clarity, but also to boost its rhetorical quality in other ways.

Plausibility poses an interesting issue, given the unusual business domain involved in this case. On the one hand, students can largely be counted on to lack the personal experience against which to do a "reality-check" of the case. This probably makes them more inclined to take the case at face value. On the other hand, the entire idea of a CRM business may challenge their credulity. In meeting this potential threat to the case's plausibility during its first deployment, I went outside the case itself by describing my own experience in this type of business - adding what was in effect my own meta-narrative layer to the three layers of narrative (Figure 1) already present in the project.

The unusual subject matter is actually more apparent than real. In particular, the sub-plot concerning the Collections facility is essentially an inventory management problem - even if the inventory in question, archaeological materials, is out of the ordinary. And the sub-plot concerning the Projects area is much like any other problem involving projects, project sites, and staffing. For students familiar with inventory management or project work, then, plausibility can be expected to depend to a significant degree on authenticity.

Authenticity, in this instance, is accomplished by drawing on direct experience - respecting, again, the principle "write what you know." In writing the case, I supplemented my memory by seeking out Web sources for materials that could be adapted for use as illustrative documents and sample data, and for identifying fine detail at the level of fields and identifiers. At the story's macro level, authenticity is reinforced by attention to realistic aspects of the larger institutional setting and their impact on project direction and scope. And again, the shifting project scope adds a further element of realism.

Compellingness is promoted in this case in part through the selective use of mini-narratives. These describe action surrounding important issues in the case, and thereby help to make those issues more salient and tangible. Novelty also enhances compellingness. The idea of an archaeology business has, for many students, a kind of "National Geographic" appeal. In the case study's first trial, some teams searched the Web at their own volition for additional clarification and sample data for such fields as the regional archaeological epoch and the geological quadrangle. Novelty can be good thing, in its own right, as students are less able to fall back on their own everyday assumptions and must therefore extend themselves, as they develop their understanding of the business. This is valuable preparation, particularly for those who will work as systems analysts and will find themselves on many occasions dealing with unfamiliar business situations. Novelty in itself, however, does not guarantee interest. Archaeology is one thing, but I would hesitate to base a case study on the tracking of chemical reagents in a pharmaceutical R&D laboratory. Although this happens to be another business situation with which I have personal experience, most students would likely find it difficult to relate to, and visualize, the work processes, materials, and data involved.

5. CONCLUSIONS

This paper has offered a systematic perspective on the task of writing systems-development project cases. It recommends viewing the undertaking as a challenge in narrative design. This calls for attention to storytelling at three levels, including the composition of the business case itself, the use of mini-narratives within the business case, and the design of the project as a kind of narrative-in-action that extends the story begun in the business case. As suggested in the sample case, the instructor may find occasions to contribute a fourth, meta-narrative layer that places the fiction of the business case within the context of his/her own real experience.

Entertaining a narrative perspective on the systems-project case invites the consideration of such rhetorical qualities as relevance, practicality, clarity, plausibility, authenticity, and compellingness. Together, these qualities help to decide what it means to present a rich case situation in which to support students' active and situated learning. Rhetorical effectiveness, in the larger view, is also a matter of the ever-present educational challenge of working within the students' existing frames of reference in order to introduce new understanding - stretching those frames, as it were, without breaking them.

The sample case is a relatively simple one, and many more possibilities exist for leveraging narrative in systems-project cases. For example, business cases can introduce multiple characters in speaking roles, occupying various organizational positions associated with differing and even conflicting perspectives, goals, and ambitions. Plot developments can be made richer, revealing unanticipated opportunities, sudden setbacks, and even betrayals. Greater richness, too, might be brought to the project narrative. For example, beyond structuring the project storyline around assignments and deliverables as described here, the instructor might also assign students to play specific "characters" in the extended story, representing various roles within the project team.

In short, the potential for the faculty member to exercise creativity and imagination in the conduct of the systems project is considerable. The key to tapping this potential is in recognizing that, among the many other roles we play when we field a project case of our own devising, we are also authors. As authors, our ability to create an effective and compelling case is enhanced by a fuller appreciation of the fundamental task we have taken on, namely, the creation of narrative.