This paper is also available in clear text form, and in WordPerfect format.
With wider acceptance and use of Engineering Cases in engineering education, there is a new form of engineering writing available. This paper presents some ideas based on our experience with cases over the last ten years, including writing over 25 cases (good or bad), assisting with several student-written cases, using cases extensively in our courses, and reviewing many cases, e.g., for Engineering Education.
Use of Engineering Cases is still in its infancy; as use matures, things will change. We have adopted many ideas suggested by colleagues reviewing our cases. We have also drawn heavily on ideas from case writing for business schools.
We do not view this as a definitive paper on case writing. We present these ideas as a compilation which may be useful to those who are considering writing cases and wonder what it is about. We also offer our compilation to seasoned case writers as a position with which to differ.
"Engineering Case", "Case", and "Case Study" are used loosely and interchangeably in engineering. others may prefer broader or narrower definitions, but to us an Engineering Case is: an account of an engineering activity, event or problem containing some of the background and complexities actually encountered by an engineer. A case is used in engineering courses to enhance learning about engineering principles and practices.
An Engineering Case differs from a technical article in which an author tries to make his point as simply and directly as possible using a logical sequence for presenting findings, conclusions, and opinions. This sequence seldom reflects how the engineer arrived at his point. In contrast, an Engineering Case describes a series of events which reflects the engineering activity as it actually happened, warts and all. The case writer suppresses his own opinions and conclusions so the reader can deal with the information and learn from the experience of drawing his own conclusions. Because cases differ from other writing, an aspiring case writer should read a variety of cases to see the many forms they may take.
The major objective of an Engineering Case is to provide a medium through which learning (e.g., analyzing, applying knowledge, reasoning, drawing conclusions) takes place. Imparting additional specific information is relatively minor and coincidental. A good case:
To make a case believable to the reader, a good case usually includes:
Cases come in many varieties. (1) They may simply be a history of an engineering activity. (2) They may be illustrations of some form of engineering activity which students critically evaluate against what they have learned in more formal courses. (3) They may be used for practice in analysis, i.e., students may be required to carry out analysis indicated by the situation or they may be required to complete an analysis started in the case. (4) They may be springboard cases, i.e., they propose problems to be solved, or are starting points for design projects.
Some of the more common uses of Engineering Cases are:
One essential in writing cases is to have in mind at least one way in which the case will be used by students. Because a case is intended for one use does not, of course, negate its usefulness for other purposes.
Engineering Cases differ from other engineering writings; there are certain characteristics found in most good cases, although there are exceptions. Authors who can write good technical reports or journal papers are not necessarily able to write good cases. A different mind-set and approach are necessary. Case writing skills can be learned; they are not difficult.
Engineering cases do not represent "good" or "bad" engineering. Since cases are real-life engineering situations, cases reflect all sorts of engineering activity, failures and successes, old and new techniques, theoretical and empirical results. Facts should not be changed to tell "how it should have been done." Cases must have a ring of truth to them. Only by "telling it like it is", can truth be preserved.
Cases are not examples; they are not a photographic slice of life; they are not guessing contests for students. Simply recording what happened does not produce a good case. People are involved in engineering activities; the case writer must present the facts in such a way that students will become involved.
Most engineering activities have two or more events occurring simultaneously. Engineering problems rarely come neatly packaged as textbook problems do. Cases must reflect this. This is why case writers find it difficult to locate and write cases that illustrate specific points in engineering courses. Attempts to put tight limits on case material to meet course requirements usually lead to failure. It should be remembered that in engineering practice, technological methods are chosen to suit the needs of a project; so it must be in writing cases.
The case writer must present facts so the student using the case can identify with an engineer in the case. To accomplish this, a case is usually written from the point of view of one individual in the case. what did he see as the problem? What facts were available? What events led up to the situation? What resources were available? What were the constraints on his actions? A case should be like an adventure or mystery story in which the student becomes engrossed because he wants to know what will develop. This must be tempered by the fact that engineering cases should focus primarily on technical issues; therefore, the narrative stream must support, but not dominate, the technical problems.
A case should introduce personalities by name. Engineering is done by people; this should be reflected in the case. The background of the more important people should be given. A careful balance is necessary on including personalities; too few and the case seems lifeless - too many and students focus on personalities and turn the case into a human relations problem, especially if technical problems become difficult.
Information in real life is received. over a period of time, even that which is internalized. The sequence in which information is received usually influences how a project is undertaken. In case writing, it is valuable to preserve this sequence and time frame so far as possible. Likewise, decisions are not delayed until all the facts are in; they are made little by little as new data are acquired. Therefore, the sequence of decisions should also be apparent. Where large quantities of data become necessary, "flashbacks" or appendices may be used to introduce these data and avoid tedious prologues.
First hand data necessary to treat the problems should be included. The more nearly the case presents the data as they became available to the engineer in the case, the more useful the case. Background data should be used sparingly, i.e., only in sufficient quantity to permit a student to proceed. As a general rule any information students should be expected to know from their undergraduate programs need not be included. Specialized, pertinent information should be included.
An Engineering Case is an instrument for student learning. The objective is not to tell all the facts and results but to give just enough facts for students to become involved in the case. What is left out is often as important as what is included. Writers are tempted to present only information which will lead students to preconceived conclusions. Don't yield; the student must be allowed as wide a choice of conclusions as the engineer in the case.
Although a case is a tool for learning, it can not do the teaching. Consideration should be given to the instructor who will be assisting a class to use the case. He must have scope to manoeuvre and help students with their learning. An instructor' s note is most valuable for this purpose; it gives him a starting point for using the case. Quality of a case is not measured in terms of its technical content but in terms of its usefulness as instructional material.
Quotations should be considered, they can be used quite effectively for:
One unique aspect of cases is that they seldom have a clear cut-off point. Real life problems do not end cleanly and concisely; things happen, actions are taken, projects run into one another, loose ends abound. Cases are the same way. Cases usually end when the writer runs out of data; or they end with a problem. In using cases, the greater part of learning takes place in wrestling with the problems in the case, not in knowing how it turned out. (Not that knowing the outcome, however incomplete, should necessarily be shunned. It can be the last section of the case, or it can be put in the instructor's note.)
When a case is disguised, one approach is to use only titles or references to positions or departments. Without names, however, a degree of reality is lost. we prefer to change names of principals, companies involved, and/or locations; but without changing any other facts.
Questions posed for the reader by the writer are controversial. We believe the less a writer intrudes into the case the better. Questions throughout the body of a case, posed by the writer rather than by a participant, reduce effectiveness of a case. Questions at the end of sections where there is a break are acceptable, although these can restrict use of a case. We differ some on this point, but we agree that writers' opinions should be restricted to the instructor's note.
Look for an interesting project that illustrates any theory, rather than for situations that illustrate specific pieces of interesting theory or application.
Most professors start writing cases using their own experiences. This is an easy way to start; all the information is at hand. The case can also be written in the first person.
Beyond personal experiences, case writers must depend on other sources. Good case material is often a matter of serendipity. If an acquaintance tells you about, or if you read about, an interesting project, a potentially good case is available. An excellent case can be written entirely from news items, magazine articles, etc. The real starting point of a good case is that somebody has found a specific engineering activity interesting. If a case writer also becomes interested he is on his way to writing a case.
Once you have identified a case you must collect the story. This usually means interviewing one or more engineers (and/or others) involved in the project. Even if the case relies heavily on written material, an interview with at least one participant can provide a story line and insights unobtainable any other way.
In soliciting information from any source it must be made clear that the case will not be published without prior consent of the individual or agency supplying the material. People will speak freely about their difficulties in an engineering activity only when they are confident they will have full opportunity to correct any erroneous or damaging impressions.
In requesting an interview, you should suggest a period of about two hours. If you get the interviewee really interested in telling his story, it may take longer! Some degree of rapport is necessary. if the interviewee is a relative stranger, you might start with questions relating to. himself, technical education, work experience, why he became an engineer, etc. This often also supplies pertinent background information about the company. Once the interviewee starts to talk freely, conversation should be steered to case specifics. The objective is to have him tell the story in his own words. Interrupt just enough to let him know you are interested and to keep him talking. Most engineers recall their actions as the result of a series of logical decisions. They must be allowed to tell it this way the first time.
When he has told his story in his own way, then you can turn to getting the real story behind that. By reference to things he has casually mentioned, or by asking for clarification of some comments, you may be able to develop more controversial aspects. Typical questions are:
Be sure the details needed for writing the case are properly recorded. Be sure to get names and titles of other individuals involved. If any sketches were made during the interview, these should be retained for possible use. Try to get copies of: original calculations, photographs (especially models or prototypes), engineering drawings, sketches, critical memos or letters, schedules, illustrative sales literature, etc. Before completing the interview, review the critical stages, issues, problems, decisions, and individuals. A quick review of the time sequence, to give some feeling for the time required for various stages, is valuable.
Use of a tape recorder is recommended. It will help keep facts straight; the interviewee will be reviewing the final version anyway; and once discussion starts, the recorder is forgotten. A tape recorder simplifies interviewing. Even with it you must be an active listener who prompts the speaker to give detail; you must listen critically to what is said, evaluate its usefulness, and ask for expansion when more detail is needed; you must listen for what is not said, as topics which are not volunteered may be the best parts of a case.
With this information you should have enough to write a case. Don't be surprised if you don't get all you need on the first interview. The way should be left open to request further information, usually specific details, to complete the case. This can often be done by telephone.
A news item, magazine article, or technical paper, may spark interest in a case. It may then be simply a matter of getting permission to reprint the article, then writing some introductory material and points for discussion at the end. If interest starts from a news item, a regular watch for continuing items may provide the material, or it may take a visit to a newspaper files at a later date. Development of a case may take some library research, which we all know how to do.
It is sometimes suggested that fictional cases should be written to better illustrate specific aspects of engineering. One important property of Engineering Cases is that they are believable. To write a truly believable fictional case requires a much greater talent than required for normal case writing. If one has this talent, we would advise him to write novels and reap some financial harvest.
Once data are gathered, it is advisable to get a first draft written rapidly while your impressions are still fresh. An early draft clarifies your thinking and lets you identify any missing data.
A case writer must subordinate his ideas to presenting facts and the opinions of principals in the case. Most engineering writers are accustomed to presenting their own ideas and opinions in a compact logical sequence. This is antithetical to case writing where emphasis is in recounting circumstances that encourage a student to sharpen his thinking. A case writer's opinions can not be completely avoided; selection of what to include is a form of editorializing; but effort must be made to give a well rounded presentation. If you must present your own viewpoint, put it in a separate section at the end of the case or, even better, in the instructor's note where it might provide guidance for what students should discover in the case.
It is important to differentiate between fact and opinion. In general, readers assume given information is factual unless specific steps are taken to clarify. If information is to be questioned by a student, it should be attributed to an individual in the case. Test results, catalog data, etc. are usually objective information. Almost anything else will be opinion. It may be correct, but it is still opinion and should be recognized and regarded as such.
Most cases go through at least three stages of writing. The first stage is a rough draft to sort out information. An easy way to start preparation of the first draft is to listen to the tape recording, jotting down key ideas as they occur on the tape. These may be out of chronological order but all the ideas will be there. You should try to tell the whole story in the first draft. You should not be concerned with separation into parts nor with teaching objectives. The important point is to get a story on paper in some form.
If the case is your personal experience, writing in the first person is excellent. First person can also be used if you have an outstanding interview which needs little changing or rearrangement. For most other situations, it is easier to write in the third person.
If written in the present tense, there is a sense of immediacy. Technology dates rapidly, however, and present-tense cases about out-dated technology have little value in the classroom.
A well-written case has several structures. There is a time structure; events occur in a time sequence which influences outcome. There is an expository structure; specific facts and details are given so the student can deal with issues and problems. There is a narrative structure which ties events together. There is a plot structure that adds interest, drama, and suspense. In a good case, one structure may dominate but it can not stand alone.
The second stage is rewriting to achieve an Engineering Case with issues, problems, and conflicts all highlighted. At this point, you would have some idea of how the case will be used in class, although you should not be overly concerned with teaching objectives. Experience has shown that good cases can be used for many purposes other than the one intended by the writer. It is only important to visualize that the case can be used for at least one purpose. There will be information gaps which must be filled, either by a second interview or library research.
Data should be tabulated where possible or, preferably, given as an exhibit of original copy used by the engineer. If displayed in its original form, the student can see the context in which the data were actually received. Use of original copy, i.e., letters, memos, photographs, etc., is highly desirable as it conveys a sense of reality.
The third stage is editing to get a "tight" final draft. Before proceeding, however, it is advisable to set the work aside for some period. Preparation of a case requires commitment which makes it difficult to view the case objectively or discard any part of it. A dormant period increases objectivity and allows a fresh viewpoint. In editing, be highly critical of your writing. Remember, writer and editor are two different persons with two different, even somewhat opposed, objectives. Assume the reader's role when editing. "Squeeze" the writing to eliminate excess words. Try the writer's acronym: KISS (keep it simple, stupid). When editing a case to shorten, or tighten it, beware of the tendency to extract the humanity and leave the technology. Chandler (l) gives many useful suggestions for writing and editing.
Once you think you have a final draft, it may be useful to read it aloud to check the narrative structure. It should sound like an interesting story, not a technical paper. A useful check is to have someone with no technical background -- spouse, brother, sister, secretary, etc. -- read it. If they find it interesting, you probably have a good case. But; revise as needed.
The final draft should be sent to the source for approval. The process should be made as simple as possible: a letter to sign and return is the simplest. Do not ask for simple acceptance or rejection (You don't want to lose all that effort!), suggest scaled approval, i.e.;
While the final draft is off for approval, prepare an instructor's note, if you plan to include one. Because you withheld your opinion in the case, you can use an instructor's note to present your views on the important issues in the case or a preferred method of solution. Comments on use of the case and questions that can be asked are also appropriate. An instructor's note can be very valuable for the instructor who uses your case.
Well, there it is. Still want to write engineering cases? The most important point is to find an engineering situation which intrigues you enough to want to write about it. Once you have it on paper, there are plenty of people who will gladly comment on it.
Case writing is fun. Try it, you'll like it!