Since I sometimes give classes on how to do case teaching and have written a book on the subject with Bill Schiano, I am sometimes asked how to write a teaching case. The following blog post is a quick tips & tricks collection (essentially an update of this post.)
Why are you writing this case?
First and foremost: Cases are written for a teaching purpose – and to write a teaching case, you need to have a teaching objective in mind. It is not enough to have an interesting company. Even the best company story needs to have a pedagogical point, a theory or dilemma to illustrate. So don’t write a teaching case just because you happen to know someone in a really interesting company – it does need to be a good story, but it also need to have a purpose.
The standard outline
Cases – particularly the standard HBS case – follow an outline that can seem rather trite, but which is very effective. It is something like this:
- 0.5 page: Intro: The protagonist is introduced, typically pondering a question of some importance. The idea is to tell the students from which perspective the case is written, to set the scene – and that is all there is to it.
- 1 – 1.5 pages: Description of the company – not the whole history, but the relevant details, explaining what the company is doing, how they make their money. Most companies are to a very large degree formed by their history, so the relevant parts need to be told.
- 1 page: Industry. Companies exist within a context, and you need to set it. Explain the industry, its evolution, and the company’s position within it. Do it succinctly, but leave more detail in than what is strictly necessary.
- 1 – 5 pages: Specific issue. This is the meat of the case, the issue at hand, the story to ponder. Make sure you tell it logically and cooly, not leaving anything out, but also conveying the complexity of the situation.
- 0.5 page: Conclusion, typically with the protagonist wondering what to do, often with some sort of event (board meeting, etc.) where he or she has to present a solution to the problem.
Most cases are just that – one case. You can have a B case and even a C case, but keep them short, since they have to be handed out and read in class. The B case should explain what the company did and perhaps introduce a new problem, the C case, if necessary, should bring some sort of closure, explaining what eventually happened. In my experience, it is very hard to get discussion after a C case – the students become exhausted. As a novice case writer, especially if you are writing about a company with a long history, it can be tempting to create a long string of small cases, but in practice this seldom works well – for one thing, it forces the discussion into a very predictable path.
No theory. A good case should be a description of an interesting situation, frequently a decision point – and nothing else. This means that there should be no theory and no discussion of the case in the case itself. Save that for the teaching note, or write a separate academic article about it. Not only does this make the case more realistic, it also means it can be used for more purposes than the one initially envisioned. This can be quite challenging for the traditional academic writer – but it is actually good practice to only present the facts (though, of course, which facts you choose to present constitute a discussion of sorts).
No hero, no villain. When teaching students how to analyze a case, I always start by saying that for most business situations, if is useful to begin the analysis with the assumption that people are not stupid and not evil. Consequently, when you write a case, make sure it has no heroes and no villains. If a case has a clear-cut hero or villain, it is a sign that you have not done enough research. Write things so that the students can see the issue from many perspectives.
No judgement. I frequently find, when reading prospective teaching cases, especially if written with the help of the communications department of a company, that judgements tend to be embedded in the text itself, though it is supposed to be as neutral and purely descriptive as possible. Do not write that a company is “leading” – instead, describe what they do, perhaps adding a bit of industry numbers for comparison, and let the decision about how leading the company is be up to the student. Do not write “Smith was a highly accomplished manager, leading a successful technology implementation.” Instead, write “Smith, at 29, was promoted to be the youngest vice president in company history after conceiving and overseeing the introduction of the first machine learning platform in the industry.”
No consultingese. Be very careful of weasel terms – is the company embarking on a strategic alliance or merely collaborating with another company for a specific purpose? (As a friend of mine said: “I buy all my socks at Marks and Spencer. That does not mean I have a strategic alliance with them.”) Avoid terms that are not well defined, and be precise in your language. Remember, a teaching case has the longest legs when it describes a human situation (since humans change slowly) and to not tie the narrative to specifically to a technology or a situation. (See the example of Fabritek below.) I quite often use old technology cases, and when the students complain, ask them to take out a pen and change the dates mentioned to current times, update the technology capabilities accordingly – and see if anything else changes.
A really well written case has dramatic structure – there is a beginning, a middle that builds up the story, and a really compelling issue at the end. The best cases are almost like a detective story, where you have to dig deep into the analysis to find surprising and sometimes counter-intuitive conclusions. One example of a “detective story” case is Fabritek 1992*, a very old (first published 1969, rewritten by Jan Hammond) case about a quality control issue in a small mechanical workshop. (Hat tip to Robert D. Austin, eminent case teacher, for making me aware of this case and showing me how to teach it.) The case is excellent because it starts with the company (strategic level), proceeds to describe a new situation and a new process (organizational or business logic level) and then introduces the problem (operational level.) Analyzing the operational details leads to one conclusion, which then can be discussed in terms of the organization and its business logic, which can then be placed into a strategic context. The case is excellent because it allows links between these levels – and also teaches the students that the devil indeed resides in the details, and that you as a manager better be very close to how the business you are leading works and makes money.
A second case which shows quality and innovation is iPremier, written by Robert D. Austin and Jeremy C. Short, the first and only graphic novel (cartoon) case I am aware of. The story is about a small online gift company being attacked by hackers, exposing glaring gaps in their security procedures and forcing managers at various levels to make some really hard decisions. The graphic format is excellent in making the various characters real (though they, on average, tend to be way too good-looking for a normal business situation), illustrates technical issues in a way that is very understandable even by non-technology students, and has a cracking good storyline with a B and a C case. I like to introduce a few technical cases in my courses because, well, I don’t think there is enough technology in business schools, and this cases answers very well because it illustrates that certain technical decisions very much require top management attention – ignore (or mindlessly delegate) technology understanding and responsibility at your peril. The graphic format also provides a welcome break from the standard case verbiage, which can be a trifle dour on occasion.
Details, details, details!
Research cases – the kind that is published in refereed journals – tend to be written from a very specific viewpoint, and only facts pertaining to that perspective is included, often in a very abstract format. A teaching case is the direct opposite: It needs lots of details, frequently made available as exhibits (graphs, pictures, documents, tables, etc.) placed at the end, after the main text. A teaching case writer, when visiting a company to write about it, needs to notice the small details, much like a really good journalist does. I tell my students that they should prepare each case so well that they feel like they have worked in the case company – and to allow them to do that, you need to provide the operational details necessary. (Incidentally, having more details than strictly necessary has the added benefit of making the case realistic – in the real world, you have to decide what is important and what is not.)
Doing it – and reading about it.
I am not aware of many books about how to write a good teaching case, with one exception: Grandon Gill (pictured), professor at University of South Florida and an excellent case teacher, has written a book called Informing with the case method, which is available for free download in PDF, MOBI and EPUB format from his web site. It has lots of details, tips and tricks, not just about case writing, but also about case teaching and course planning. (For the latter, of course, I am duty bound to recommend Bill Schiano’s and my book Teaching with Cases: A Practical Guide.)
Last but definitely not least: Don’t underestimate how much work writing a proper business case is. Getting the details right, describing the dramatis personae, and making the storyline compelling is quite a challenge, in many dimensions different from the traditional academic article. On the other hand, should you get it right, you will have a very effective teaching tool for many years to come.