Why the algorithm is the easy part, and the change management is the “boss fight.”
Whenever I speak at a conference or just casually talk to people about what we do here at Timefold, I often get asked:
“What is the hardest part of solving the optimization problems?”.
My answer is always the same: “the human side”.
This usually leads to surprised faces. Surely, humans can’t be harder than solving an optimization problem with more possible solutions than there are atoms in the observable universe? And yet, when talking to other optimization experts, they will probably tell you the same.
The math is hard. The psychology is harder.
When we use Timefold to optimize a plan, that plan usually matches all the constraints and is by all formal definitions better than what a human planner would have created in a similar time. Yet, when shown to the stakeholders, the first things they see is usually something like:
Not the 98 improvements. The 2 changes. And they might hate it.
This is the status quo bias in full swing! Change feels risky, even when the plan is objectively better. “This is how we’ve always done it” is a powerful force. People tend to convince themselves that sticking with something worse but familiar is safer, until the problem grows to a scale the current problem can’t solve anymore.
Even before implementation, another bias creeps in. Stakeholders often say: “Let’s just improve what we have. It shouldn’t take long.”
That’s the planning fallacy. We consistently underestimate how long incremental fixes will take. “Just a few tweaks” turns into months of spreadsheet archaeology and fragile macros.
We underestimate the effort required to evolve a manual or semi-manual process because we imagine best-case scenarios not messy reality. That’s why software estimates quietly grow buffers. We’re compensating for our own optimism.
The planning fallacy often meets another one: the sunk cost fallacy. Instead of moving to a entirely novel way of planning their operations, they will try to improve their current solution, whether that is with some custom software development, or adding another bunch of macros to their Excel spreadsheets.
“We’ve put too much work into this to abandon it now.” So instead of moving forward, we keep patching yesterday’s solution.
Let’s say the optimized plan does go live. Drivers ignore the suggested route because “they know a faster way.” Planners manually override assignments because “this is how we usually do it.” That’s the well-travelled road effect at work. Familiar processes feel faster and better than they actually are.
People underestimate how long manual planning takes because they’ve done it for years. The friction has become invisible. And when it’s invisible, why would you ever deal with “change”?
None of these biases are irrational. They’re human.
Optimization is rarely blocked by math. It’s blocked by psychology.
The real constraints in planning projects are often:
So when people ask me what the hardest part of optimization is, I still give the same answer: “the human parts of the schedule”. An optimization tool can search millions of possibilities per second. But humans decide whether the result is accepted.
And honestly? That’s not a bug. It’s a reminder that planning education isn’t just about better models. It’s about better awareness of both the mathematical and human limitations.
Modeling hard constraints is easy. Modeling human behavior is not.
We are introducing JPMS support in Timefold Solver 2.x. In this blog post, we explain what that means to our current users and to the long term maintainability of the project.
Before you can optimize field service operations, you need to organize the data that feeds the engine. This post walks through the three data pillars behind scheduling optimization, and how to get them API-ready.
