The software usually works. Projects fail for reasons that have nothing to do with the solver, and the same six patterns recur across industries, fleet sizes and price points.
Pattern 1: Optimising on fictional data
What happens. Go-live proceeds with default service times, unverified geocodes and estimated volumes. The plans look tight and beautiful. In week one, drivers run two hours over, windows are missed, and dispatch starts manually rebuilding routes each morning.
Warning signs. Nobody can tell you the source of the service time values. The data migration was described as "a straight export". No one has audited geocode match quality.
What to do. Stop. Audit address data and rebuild the service time model before extending the rollout. Two weeks of data work recovers a project; six months of drivers ignoring plans does not.
Pattern 2: The planner override loop
What happens. Planners do not trust the output, so they adjust it. Their adjustments are not fed back as constraints, so the engine repeats the same "mistake" tomorrow. Within a month, planning is manual again with an expensive system as a map viewer.
Warning signs. High volumes of manual edits post-optimisation. Planners describing the system as "a good starting point". Nobody logging why edits are made.
What to do. Instrument the edits. Categorise a fortnight of them: each category is either a missing constraint (configure it), a data error (fix it), or genuine planner knowledge that must be encoded. Most override loops collapse once three or four constraints are added.
Pattern 3: Ignoring the warehouse
What happens. Routes are optimised for the road and dispatched to a warehouse that cannot load them in that sequence. Loading takes longer, vehicles leave late, and the plan's assumptions about departure times are wrong from the first minute.
Warning signs. Warehouse staff were not in the project. Nobody knows whether the system can output a load sequence. Pick-face layout was never discussed.
What to do. Bring load-out into scope. Reverse-sequence loading lists, staged marshalling areas and realistic departure times in the plan. Sometimes the right answer is to constrain the optimiser to produce loadable routes rather than theoretically shorter ones.
Pattern 4: Change imposed on drivers
What happens. Drivers are told on a Friday that Monday's routes will be different. Their objections are treated as resistance. Adoption becomes a compliance exercise, exception reporting becomes noise, and the local knowledge that used to compensate for bad data disappears.
Warning signs. No driver was consulted during design. Training is a 20-minute briefing. The word "resistance" appears in project updates.
What to do. Involve experienced drivers in design and in constraint capture — they know which customer will not accept a delivery after 10:00 and which street is impassable at school run. Pilot with volunteers. Publish what changed because a driver said so; it is the fastest trust-building action available.
Pattern 5: No baseline, therefore no proof
What happens. Six months in, the CFO asks what the system delivered. Nobody measured the before state properly. The project cannot prove value, budget for phase two evaporates, and the platform drifts into partial use.
Warning signs. The business case cites vendor percentages rather than internal measurements. No agreed metric definitions. "We'll measure once we're stable."
What to do. Establish a baseline before go-live: distance, hours, overtime, vehicle count, stops per hour, failed deliveries, window compliance — over at least four representative weeks. Then hold definitions constant. See building an ROI case.
Pattern 6: Scope that never lands
What happens. The project expands: routing, then telematics integration, then ERP, then customer notifications, then analytics. Eighteen months later nothing is fully live, the sponsor has changed, and the original problem is unsolved.
Warning signs. No phase has an exit criterion. "While we're in there" appears in meetings. Go-live date has moved twice.
What to do. Cut to a defensible first phase — usually one depot, core planning and the driver app — with a hard date and measurable success criteria. Everything else queues behind proven value.
The pattern behind the patterns
Five of the six are organisational, not technical. Route optimisation changes who decides what: it moves planning authority from experienced individuals into a system, and it makes previously invisible performance differences visible. Projects treated as software installations fail; projects treated as operating-model changes with a software component succeed.
A short diagnostic
Answer honestly:
| Question | Bad answer |
|---|---|
| Where do service times come from? | "The defaults" |
| What percentage of geocodes are verified? | "Not sure" |
| How many manual edits per plan? | "Nobody tracks it" |
| Were drivers involved in design? | "They were trained" |
| What is the pre-project baseline? | "We'll work it out later" |
| Who owns the plan-versus-actual report? | Silence |
Three or more bad answers means the project is at risk regardless of which product you bought.
Common questions
Can a stalled rollout be recovered?
Usually, and more cheaply than replacing the system. Nearly every recovery starts the same way: audit data quality, categorise planner overrides, and rebuild the service time model. Only after that is it fair to judge the software.
How long should implementation take?
For a single depot with clean data and a standard integration, 8–16 weeks is realistic. Multi-depot rollouts with ERP integration run 6–12 months. Anything promised in "a few weeks" is either genuinely simple or omitting the data work.
Should we run parallel with the old process?
Briefly — two to four weeks — and with a firm end date. Indefinite parallel running guarantees the old process wins, because it is the one people already trust.
What is a realistic first-year target?
Set targets on the metrics you can measure and control: variance between planned and actual times, window compliance, overtime hours. Distance savings follow, but they are a poor early indicator because they depend on demand mix.
Who should lead the project?
Someone from operations with authority over planning and dispatch, supported by IT — not the reverse. Projects led from IT tend to deliver a working system that nobody uses the way it was designed.
