Sign in or start a free trial to avail of this feature.
2. Framing the Problem
Framing the problem at the outset ensures that we won't solve the wrong problem or spend time on redundant work.

Framing the Problem (00:04)
When we frame the problem, we identify exactly what the problem constitutes. In doing so, we identify in detail what the solution constitutes. Sometimes, leaving out details can significantly alter how we perceive a problem. For example, releasing a new product may take several years to generate profits. Changing the time period we analyze may change our decision on whether it is worthwhile to release the product or not.
Vaguely defined problems can lead to analysts solving the wrong problem. Framing the problem before starting prevents this, by dealing with issues like:
 The time period to analyze
 How to subdivide the data
 Whether past data is a reliable guide to future data

Applying to the Case Study (01:43)
Our initial problem for Zippy Airways is too vague, so we consult with the CEO to improve it. We determine that the company wants a quick answer from a simplified model. As a result, we frame their problem as follows:
If we had implemented an overbooking policy, with a common booking limit across some or all of our flights, by how much would we have improved profitability, without adjusting prices, in the last 3 months?
The first stage of modeling is framing the problem. If you're a management consultant, this can also be referred to as writing the problem statement. In some sense, this step might seem trivial, but illdefined problems are often illdefined because what constitutes the problem, and therefore, the solution, is not properly framed. To emphasize the importance of framing the problem, read this short exchange between a company executive and an analyst working at the same company.
By simply adding a time period to the initial problem statement, the analyst reaches two totally different conclusions to the executive's initial question. Many illdefined problems are simply too vague in their description, and as a result, analysts run the risk of solving too many problems, or even solving the wrong problem. Having a more specific problem statement puts boundaries on the model, and reduces the likelihood of redundant work.
Another source of difficulty when framing the problem comes in the word simplified in our definition of a model. Unfortunately, simplified is a subjective term, and so what I might determine simplified, you could perceive as very detailed, and vice versa. Therefore, it's very important at the outset to explain to your manager or client exactly what level of detail they expect from your model. Some questions might include: Should I model by month or by quarter? Should I subdivide by region or by product, or both? And, can I rely on past data as a proxy for future data? Or, should I apply some goal estimates? Now, let's frame the problem for Zippy Airways. The current problem statement is much too vague, so let's put a few questions to the CEO. Our first question relates to the previous three months of operating data, and we'd like to know, is he happy to use this as a proxy for future operating data? The second question relates to the number of options he'd like to pursue in the model. Does he want to use a common overbooking policy on all flights, or would he like to tailor the overbooking policy on a flight by flight basis? And the last question, again, refers to complexity. Would he like us to adjust the company's pricing model to take account of any new overbooking policy? From putting these questions to the CEO, we realize that his priority is to get a quick answer from a simplified model because he'd like to have a preliminary discussion with his board on the topic in the next two weeks. And so, as a result, he agrees to the following revised problem statement: "If we had implemented an overbooking policy, "with a common booking limit across some "or all of our flights, "by how much would we have improved profitability, "without adjusting prices, in the last three months?" Armed with this much more detailed problem statement, we are now in the position to move on to the next stage of the modeling process, which is drawing a diagram of the problem.
Sign in or start a free trial to avail of this feature.