2. Framing the Problem

Subtitles Enabled
Replay Lesson

Next lesson: Diagram the Problem

Watch next lesson


Framing the problem at the outset ensures that we won't solve the wrong problem or spend time on redundant work.

Lesson Notes

Frame the problem

- Ill-defined problems need to be framed to provide boundaries for the model
- Otherwise, analysts run the risk of solving too many problems, or the wrong problem

Confirming the level of detail

- A 'simplified version of reality' is a very subjective phrase
- What I might perceive as a detailed model, you might consider very basic
- Therefore, its critical that the team are aligned on the level of detail that the model requires


The first stage of modeling is framing the problem. If you are in management consulting, this can also be referred to as, writing the problem statement. In some sense, this step might seem trivial but ill-defined problems are often ill-defined 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 ill-defined 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 from 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 growth 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'd implemented an overbooking policy with a common booking limit across some or all of our flights, by how much would we have improved the profitability without adjusting prices in the last three months? Armed with this much more detailed problem statement we are now in a position to move on to the next stage of the modeling process, which is drawing a diagram of the problem.