Jeffrey M. Keisler, University of Massachusetts Boston

Ask a roomful of OR instructors what they’re teaching when they teach prescriptive analytics, and you’ll hear a familiar mix: optimisation, simulation, decision trees, scenario analysis. Each is a powerful technique, but they’re often taught as standalone tools rather than as steps in a broader analytical progression. Ask how they’re teaching it, and responses may sound just as familiar: Excel add-ins, hands-on demos, possibly Python code, case studies, problem sets and projects.

Models are introduced, problems are contextualised, buttons are clicked, results interpreted. It seems like a full and reasonable package.

But somewhere in this process, many students fall off the curve. They stumble on what’s being asked of them, what the tools are actually doing, or how to generalise from one example to the next. And we, the instructors, tend to fix this by doubling down: we walk through more models, provide more background, go through the analytics again and get more solutions. The students nod confidently. But not when it’s time to do it alone.

This is a built-in problem of the pedagogical design.

The Modelling-Driven Approach: Ambitious but Confused

The default teaching approach in many analytics courses these days is to prioritise the art of modelling over the science of analytics.

The modelling-driven approach is built around application cases that require students to interpret, build, or adapt spreadsheet models. These are often pulled from different business domains—pricing, inventory, portfolio selection—and are designed to expose students to varied “realistic” problems and “industry-relevant” tools.

 

To support this, we use template models and increasingly powerful analytic add-ins. These tools abstract away the messy parts: solvers handle optimisation, risk software handles the simulations, other software may work textbook decision trees while dashboards get the results ready for presentation. Students can complete their work without understanding the inner workings of the tools. They just need to know how to enter the inputs and read the outputs.

The appeal is obvious. Students can work on polished projects. They can showcase results. There’s even a career argument: this mimics how many analytics tasks look in practice. But the pedagogical tradeoffs are significant.

First, modelling-driven teaching assumes a background that students don’t necessarily have. It leans heavily on domain knowledge— understanding what a queue is, how cash flows work, or what constraints are plausible in a product mix problem. It also assumes they have modelling literacy: knowing what to do when the problem doesn’t line up with a pre-made template. Even if we supply the templates, interpreting them still requires business judgment and abstraction.

“What we’re doing, structurally, is asking students to learn two hard things at once: how to model and how to analyse… The layers of uncertainty stack up quickly.”

Second, analytic tools in this model are treated as accessories. The methods are there, but they’re presented in a fragmented way. One tool for this case, another for that. Underlying mathematical logic is optional at best, glossed over at worst. Add-ins do the work. Formulas with Greek letters appear, but students aren’t expected to spend time with them. The mechanics are hidden behind interfaces. This is a flimsy foundation for learning and action, especially when problems don’t behave as expected

Third, we spend a lot of time teaching spreadsheets themselves. e.g., navigating sheets, formatting outputs, getting graphs to behave. A course on modelling often becomes a course on necessary spreadsheet craftsmanship, more than on analytics insight.

It’s an efficient way to deliver a lot of content. But it’s not a good way to teach prescriptive analytics. What we’re doing, structurally, is asking students to learn two hard things at once: how to model and how to analyse. And both while also interpreting unfamiliar business contexts and navigating new software interfaces. The layers of uncertainty stack up quickly: students aren’t sure whether they don’t understand the problem itself, the method just introduced, or maybe even the earlier method it builds on.

The Analytics-First Alternative: Learn the Science Before the Art

Instead, we can flip the priorities. The analytics-first approach emphasizes the analytical techniques. That lets us think clearly and quantitatively about how models can answer questions before we start formulating questions we hope they can answer.

We start with a single, simple profit calculation model that every student can fully understand. This model becomes the stable platform on which we introduce each analytic technique, one at a time.

Each module incrementally extends the model’s capabilities: adding a data table to explore sensitivity, introducing indexing to track multiple cases, layering in random variables for simulation, aggregating outputs for analysis, and adding constraints for optimisation. At each step, the model stays constant. What changes are the methods and the questions we ask of the model

From there, the standard prescriptive topics flow naturally as layers of inquiry that evolve alongside the methods themselves: What do we assume, and what happens if our assumptions are correct? How do outputs shift with inputs? What if multiple variables change together? How can we generalise across scenarios or include uncertainty? How do we compare more dynamic alternatives? What if it’s not just about profit? What if the issue isn’t what we can do, but what we can’t— because of constraints? Each technique deepens the previous question. This approach has several key characteristics:

  • The model is known. Students aren’t trying to decode the application. They know the inputs, the outputs, the formulas. Their attention is on what the new method is doing.
  • The logic is visible. By staying in spreadsheets and avoiding addins, we show how the techniques work, cell by cell and step by step. Bypassing the math notation too, this supports understanding, not just execution.
  • The techniques are layered. Each new method builds on the previous one. The progression makes sense—sensitivity before simulation, simulation before decision analysis. The learning curve is smooth.
  • The cognitive load is controlled. Students learn one thing at a time. First, they focus on mastering each method. Then, once the methods are internalised, they begin to explore how those methods support more complex modelling. This sequencing is deliberate: the analytics-first approach holds off on modelling complexity until students have a connected set of analytical tools they can reason with. This separation helps all learners—but especially those without strong technical or domain backgrounds.

Learning in Sequence

It’s tempting to say that modelling and analysis happen together in the real world, so that’s how we should teach them. But to everything, there is a season. Meeting prescriptive analytics on its own terms, we can really appreciate it. In the process, students can succeed early and often. This makes later work with modelling, and finally both together all the more meaningful.

This more patient analytics-first approach reduces student confusion and lowers instructional strain. I don’t ask students to instantly be senior analysts, just to be on the right path. It’s how I now teach and how I wrote Prescriptive Analytics: Mastering the Spreadsheet of Everything (Springer, 2024).