2. Framing the Problem

Subtitles Enabled

Sign up for a free trial to access more free content.

Free trial


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


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're a management consultant, 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 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 sub-divide 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.