Your optimizer was right and the shift still went wrong

There’s a specific kind of failure that happens after a company buys scheduling software, and it’s more common than anyone in my business likes to admit.

The plan comes out. It’s valid. Every constraint you gave the system is satisfied, the cost number is lower than what you were doing by hand, and the person who ran the project has a slide showing it.

Then the shift runs, and it’s a mess. By ten in the morning the supervisor has rebuilt half of it on paper.

Nobody lied. The solver did what it was asked. The gap is between a mathematically correct answer and a shift that survives contact with a real morning, and it comes from four places. Two of them are your problem. Two of them are the vendor’s, and you should make them own it.

1. The constraints nobody wrote down

This is the biggest one and it’s almost never in the project plan.

Every operation runs on a set of rules that exist in writing, and a much larger set that doesn’t. The written ones go into the model in the first week. The unwritten ones surface over the following six months, one incident at a time.

They sound like this. We don’t put those two on the same team. Gate 4 is always Péter, because Péter knows the sensor is broken. If it’s raining you need an extra person on that stand and it isn’t in any document. The 05:40 briefing overruns every Monday. That customer will complain if we send a new starter, regardless of qualification.

None of these are irrational. Most of them encode a real thing that went wrong once. And a schedule that ignores them is technically feasible and practically unusable, because it violates the operation’s actual constraints rather than its documented ones.

The mistake is treating this as a data-collection exercise you do once. It isn’t. Extracting tacit constraints from the people who hold them is most of the real work in any scheduling project, it takes months, and it’s the part that generates a system worth keeping. Budget for it explicitly. If a vendor’s implementation plan doesn’t have a substantial line item for sitting with dispatchers and supervisors, they haven’t done this before.

One practical way in: run the optimizer’s plan alongside the human plan for a few weeks without acting on it, and ask the supervisor to explain every difference. Each explanation is either a missing constraint or a habit worth losing. Both are worth knowing, and you’ll learn more in three weeks of that than in three months of workshops.

2. Your durations are averages of two different things

Every scheduling model needs to know how long tasks take. Almost every one gets this from either a standard-times table or a historical average, and both are quietly wrong in the same way.

Take a task with a standard time of twenty minutes. Look at what actually happens and you’ll usually find it’s not a distribution around twenty. It’s two distributions. Fourteen minutes with the experienced crew on a familiar aircraft type, thirty-two minutes when it’s a new starter or the equipment is at the far stand or it’s below zero.

The average is twenty-three, and twenty-three is a number that describes no actual event.

Plan with the average and you’re wrong in both directions all day. You under-allocate the hard cases and over-allocate the easy ones, and the errors don’t cancel — they land unevenly, which is exactly what breaks a tight schedule.

Fixing this doesn’t need clever modelling. It needs the model to know what the task actually depends on: which type, which stand, which crew experience level, what the weather is. That’s not a machine learning project. It’s the same constraint-modelling conversation as above, applied to durations, and the data to support it usually already exists somewhere nobody has looked.

Which leads to the uncomfortable prerequisite. If you don’t record what actually happened — task started, task finished, by whom — you can’t do any of this, and your durations will stay guesses forever. Capturing execution isn’t a nice-to-have that comes after optimization. It’s what makes the optimization stop degrading.

3. Optimal means no slack, by definition

This one is the vendor’s fault and it’s rarely explained to buyers.

If you ask a solver to minimise cost or headcount, it will. It will find the arrangement where every person is busy and every gap is closed, because any slack it left would have been a cost it could have removed.

A schedule with no slack is a schedule where the first disruption cascades. The delayed inbound doesn’t just affect that turnaround; it affects the next one, because the person who was going to do it is still on the first, and there was no buffer between them by construction.

So a plan that’s five percent cheaper on paper can be substantially more expensive in practice, once you count the overtime and the recovery and the SLA breach. And you’ll never see that in the comparison, because the comparison was run on the plan.

The fix is to buy slack deliberately rather than have it removed accidentally. Protect the turnarounds where a delay propagates furthest. Keep a float person during the peak bank rather than allocating them. Decide where the buffers go and put them in the model as constraints, so the optimizer works around them instead of eating them.

Ask any vendor how their system handles this. If the answer is that the plan is optimal, that’s the wrong answer.

4. The plan was a hypothesis and nobody updated it

The last one is structural. A plan produced at 05:00 was correct given what was known at 05:00. By 07:00 several things have changed, and the plan is a description of a morning that isn’t happening.

A lot of scheduling software stops here. It plans, it prints, it waits for tomorrow. The re-planning is done by a supervisor with a radio and a marker pen, which is what the software was bought to replace.

The metric that matters is the delay between reality changing and the plan changing. Call it re-plan latency. If it’s overnight, you’ve bought a planning tool. If it’s minutes, you’ve bought an operational system. It’s a fair question to put to every vendor and the answers vary enormously.

Getting it down to minutes needs three things that are all harder than the solve itself: knowing what’s actually happening now, being able to re-solve fast enough to be useful mid-shift, and doing it in a way a supervisor can trigger and understand without opening a configuration screen. That last one is where most of these systems die. A re-plan the supervisor doesn’t trust is a re-plan the supervisor ignores.

Who owns what

Splitting this honestly, because the split determines whether your project works:

Nobody can extract the first pair for you — you can be helped, but the knowledge lives in your people and the data comes from your operation. If you don’t commit real supervisor time to this, no vendor can compensate for it. And if a vendor can’t discuss the second pair specifically, they’re selling you a planner.

The good news is that both halves compound. The constraint model gets more accurate every month someone corrects it. The duration estimates get better every week you record what happened. A scheduling system that isn’t measurably better in year two than on day one isn’t learning anything, and you should ask why.

Optimum Intelligence builds optimization systems for operations where the plan and the reality drift apart before lunch — ground handling, distribution, and facilities. If your supervisors are still rebuilding the plan by hand at ten in the morning, we’re happy to talk.