Case Study Guidelines

Each student will write a case study about a company or industry coping technology in
some way. Unique companies and industries will be selected by each student on a first-
come, first served basis on a class sign-up page. This project could include field work,
analysis, and a Web-based case study. Data for the study can be gathered from the Web,
from publicly available information, from the library, or from a visit to a local firm. The
firm you select should be involved in a key way with technology business, either as a
manufacturer or distributor, or as a user. Interviews with business managers who interact
with the technology and business would be especially useful but are not mandatory. The
case study should be organized to demonstrate a thorough understanding of the
technology business and its potential. As a general guideline, the case study could include
(but not be limited to):

• Describe the company's business in 25 words or less

• Describe the relation of electronic commerce to business practice, noting any
changes from before to after electronic commerce was adopted
• List past business successes and failures
• Give industry background: growth, number of firms, major players, etc.
• Give background of company: age, size, growth, market
• Analyze the Porter five forces and other relevant frameworks
• Perform a SWOT analysis
• Analyze the business model
• Investigate the competitive financial situation: ratio analysis on key operating
performance measures (inventory turnover, sales/employee, ROA, etc.) compared
to industry values
• Discuss key management challenges: today, five years ago, five years hence
• Include names, titles and quotes from people interviewed
• Identify any entrepreneurial opportunities
• Create a final Web-based case study
• Include complete bibliography and references, including complete citation of
works from all sources (including the Web) in proper bibliographic form

On Writing Engineering Cases

(Proceedings of ASEE National Conference on Engineering Case Studies, March 1979)
by Geza Kardos, Carleton University, Ottawa, Ontario.
and C.O. Smith, University of Nebraska, Omaha, Nebraska

This paper is also available in clear text form, and in WordPerfect format.

Contents
  Introduction
 What is an Engineering Case?
 How Engineering Cases are Used
 What's in a Good Case?
 Which Engineering Case to Write?
 Collecting Case Content
 Getting the Words on Paper
 Rescript
 References

Introduction.
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.

What is an Engineering Case?

"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:

1. Is taken from real life (a necessity).

2. Consists of one or more parts, each part usually ending with problems and/or
points for discussion.
3. Includes sufficient data for the reader to treat problems and issues.

To make a case believable to the reader, a good case usually includes:

1. Setting
2. Personalities
3. Sequence of events
4. Problems
5. Conflicts

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.

How Engineering Cases are Used.

Some of the more common uses of Engineering Cases are:

1. Reading assignments to acquaint students with various aspects of engineering.

2. Background to specific problems; problems which may be in the case or may be
posed by the instructor.
3. Practice in formulating problems. students may be required to read the case, to
identify and formulate problems to be solved.
4. Subjects for class discussion, e.g., students can evaluate problems, people, and
situations in the case.
5. Medium for relating engineering history. Engineers are not well versed in the
history or traditions of their profession; cases are one way to develop these.
6. Motivation for laboratory work.
7. Background and source for design projects.

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.
What's in a Good Case?
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:

1. Expressing opinions
2. Stating important issues
3. Expressing personal philosophy
4. Establishing character
5. Expressing differences of opinion
6. Increasing believability

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.

Which Engineering Case to Write?

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.

Collecting Case Content.

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:

1. Were any solutions other than the final one considered? Why were they rejected?
What were the trade-offs?
2. Who made the decisions?
3. Were there any difficulties in completing the project or was it a "breeze"?

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.

Getting the Words on Paper.

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.;

1. As written
2. With minor changes
3. With major changes
4. With names of people and companies disguised, etc.

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.

Rescript.
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!

References
1. Chandler, H. E., "The How To Write What Book," Metals Park, Ohio. The
American Society for Metals, 1978