Introducing the Case Interview Process Model© - Part 1

This post is the first part of describing the Case Interview Process Model©. The second part will come shortly after, and I'll promise it'll be even better.

If you have read some of my previous posts, you know that I take a lot of my case interview philosophy from Victor Cheng, they guy behind the wildly successful site caseinterview.com. One of Victor's core principles is that successful consultants follow a logic, linear thinking which ultimately lead them to a solution of the problem. Similarly, candidates in case interview are expected to display the same consistency of though, so that interviewers are confident that the candidate does possess the skills to success, and didn't just get lucky.

A Process Perspective

As it turns out, the thought pattern promulgated by Victor Cheng is so systematic, so linear, that a very good way to describe it is using process modeling. Despite its rather dreadful name (it was originally invented by IT folks), process modeling is very simple at its core: it visually lays out a sequence of activities triggered by a specific event. No more, no less.

Since a process is a well-defined collection of discreet activities, it is just perfect to describe a logical and linear set of tasks. Yes, just like the case interview ;-)

I therefore here suggest a possible process-centric view on business case interviews, as taught by Victor Cheng. The process is modeled using the Business Process Modeling Notation (BPMN), which has become the industry's standard. The BPMN model presented here follows the Method and Style convention of BPMN's guru Bruce Silver. No worries, you won't need to buy the book to understand the model, we are going to walk along it together.

I haven't came across any modeling of this sort on the web so I believe this is a rather original view to bring to the case interview methodology. The process is far from being perfect and I actually love to hear your suggestions about how to make it better.

So let's all buckle up and put our nose into the wonderful world of the Case Interview Process Model©. It's going to be fun.

The Case Interview Process Model©

The high level process: Master Case Interview

(Click to enlarge)

It all starts from here. This is a very simple view of the case interview with only three sub-processes (the boxes with a + sign). Readers familiar with Victor Cheng's method will recognize the famous three steps of a case:

1. Open the case;
2. Analyze the case; and
3. Close the case

The little twist in that model is the timer attached to the boundary of the Analyse Case sub-process. It requires that if the analysis takes longer than 30 minutes (the whole case should last between 35 and 40 minutes), the analysis must be stopped to close the case.

So far so good? So let's jump to the first sub-process, Open Case, and imagine that we literally open this cute + box.

The first Sub-process: Open Case

(Click to enlarge)

Things start to become more complex at this stage but it remains very logical (that's the whole purpose after all). Let's look at every activity one by one.

Listen to Case Introduction
To open a case correctly, a candidate must first carefully listen to the introduction given by the interviewer. This is a critical step as a lot of crucial information is shared at this stage. Even though it is not shown on the process map, the candidate must absolutely take notes while receiving the introductory data. I can't emphasize this too much as it allows the case to flow smoothly onwards.

Re-phrase Situation
The second task done by the candidate is to explicitly re-phrase the case. While at this point you can't provide any insights (unless you have some paranormal sixth sense), re-phrasing is very useful for the candidate to soak up the information and own the data. By doing so, the chances that the interviewee doesn't understand correctly the situation is fairly slim.

Verify Case Objective
Now, we are tackling THE activity. Since I can't emphasize enough, I'm gonna shout it. A CANDIDATE MUST ALWAYS ALWAYS ALWAYS VERIFY THE OBJECTIVE OF THE CASE. You got it? Yes, every case interview coaches say it and you find this sentence on every blog but I have been amazed by the number of times that a fellow candidate simply did not do it. As a matter of fact, it happens very regularly. No matter how smart and incisive the analysis is, solving the wrong problem makes the interviewee as useful as a trained monkey (nudge to the killer consultant's manifesto). So please, dear readers, always verify the objective of the case, and even better, make this objective measurable and time-bound. If you manage to do it properly, congrats, you have unlocked the first level :)

Analyze Case Background
First, let me talk about the necessity of asking background questions in the opening phase of the case. Here I stand the same ground as Victor Cheng. The candidate should take time to ask various background questions before you start the real analysis of the case, because it just makes your life so easier. Keep in mind that the meat of the analysis is to formulate an hypothesis and verify it (we'll talk about it in great length in the 2nd part). Delving into an analysis without having a good conceptual understanding about the client, its situation and the scope of the problem is at best inefficient, at worst disrespectful to the imaginary client (and as a consultant, you never want to lack respect to the guy that pays this hefty bill your firm is charging him).

The Analyze Case Background activity is actually a kind of sub-process called a parallel box with 4 tasks inside: Assess Problem Scope, Compare with Industry Situation, Compare with Historical Situation and Grok Client's Business. A parallel box in BPMN simply means that all the tasks within that sub-process can start and be completed at any moment and in any order, but all must be finished for the process to continue downstream. I believed that this was the best way to model background questions since they can pop up in a rather random way (at least this is how I do it personally).

You also observe that a timer boundary event, similar to the one seen in the high level process is attached to the Analyze Case box. The meaning is the same: should the whole background questions phase take more than 5 minutes, it is wise to cut it short and proceed to the real analysis of the case.

Now, about the inside tasks.

1. Assess Problem Scope. This also makes the analysis much easier since it the candidate you to precisely fit your analysis to what is relevant. The classic example (shown on the map as text annotation) is the company vs. product line profitability. Should we focus on the overall profits generated by the company or is it wise to breakdown the bottom line by product line? Those are very important information for an efficiency standpoint.
2. Compare with Industry Situation. This task should actually be a sort of reflex whenever you receive data about the company (so candidates should also do it in the analysis portion). By comparing the company to its peers in the industry, you add context to the data, thus increasing your understanding about the situation.
3. Compare with Historical Situation. Similar to the task above, this should be an automatic habit. Knowing what your data means when compared to past information also enhances your conceptual knowledge about the problem at hand.
4. Grok Client's Business. The use of the word 'grok' may be strong but here I wanted to convey that a candidate has the best intimate knowledge about what the client really does before  starting his analysis. If the client is in a very particular niche market with unconventional products, then it is the candidate's goal to really understand this.

That's all for today folks, hope this overall description has been clear so far. In the second part of the explanation of the Case Interview Process Model©, we will focus on the bulk of the process, Analyzing the case. Stay tuned, the article will be out in a few days :)