An OR project end to end

Why it matters

Textbook problems arrive already formulated. Real ones arrive as a sentence from a manager: "our shipping costs are too high" or "we keep running out of stock in the north". Most OR projects that fail do so not because the maths was wrong but because the team solved the wrong problem, used bad data, or built something nobody adopted. This lesson walks through a supply-chain project from the first meeting to the handover, so you can scope one yourself.

The phases of an OR project

Most practitioners describe roughly the same cycle (the INFORMS Analytics Framework uses similar steps):

1. Frame the business problem. What decision is being made, by whom, how often, and how will success be measured?
2. Translate it into an analytics problem. Which decisions become variables, which goals become the objective, which rules become constraints?
3. Get and check the data.
4. Choose the method and build the model.
5. Validate against history and with the people who know the operation.
6. Deploy: a report, a spreadsheet tool, or a model that runs every night.
7. Monitor and maintain: data and business rules change, and the model must keep up.

A worked case: a regional distributor

The request. A distributor of hardware supplies serves 60 stores from four warehouses. The operations director says freight costs rose 18% in two years and asks whether they "have the right warehouses".

Framing. In the first meeting you ask questions rather than propose a model:

• Is the decision to close a warehouse, open a new one, or just re-assign stores to warehouses?
• What is the planning horizon: next quarter or the next five years?
• What does success mean: lower total cost, faster delivery, or both? Is there a service rule, such as "every store reached within one day"?
• What is out of scope? (Supplier choice, store locations, pricing.)
• Who will use the result, and who could block it (the warehouse managers, a union, the finance team)?

The agreed problem statement: "Choose which of the four warehouses to keep, and which warehouse serves each store, to minimize annual fixed plus freight cost, while every store stays within 300 km of its warehouse and no warehouse exceeds its capacity. Decision due in 10 weeks."

The model. This is a classic facility location model, a mixed-integer program:

y_w  = 1 if warehouse w stays open (binary)
x_ws = share of store s's demand served from warehouse w (0 to 1)

minimize   sum_w fixed_w * y_w + sum_w sum_s freight_ws * demand_s * x_ws
subject to sum_w x_ws = 1                        for every store s
           sum_s demand_s * x_ws <= cap_w * y_w   for every warehouse w (big-M link)
           x_ws = 0 if distance_ws > 300 km       (service rule)

It combines the transportation structure from module 2 with binary open/close decisions.

Data. You need store demand by month (from order history), freight rates per km and per pallet (from carrier invoices), warehouse fixed costs and capacities (from finance and operations) and distances (from a mapping tool). Expect to spend more time here than anywhere else. Reconcile totals with finance: if the model's freight cost for last year's actual flows is 10% below the invoices, something is missing (fuel surcharges, minimum charges, returns).

Baseline and validation. Before optimizing, run the model with today's network fixed and compare its cost with last year's actual cost. This baseline builds trust and is the number every saving is measured against.

Scenarios. Solve several scenarios rather than one answer: close one warehouse, close two, demand grows 10%, freight rates rise again. Show the trade-off between cost and service.

Recommendation and handover. Suppose closing one warehouse saves about 7% of total cost while keeping every store within the service rule. The deliverable is not the model: it is a short memo with the recommendation, the savings against the baseline, the risks (transition costs, staff), and a sensitivity check on freight rates. The model and its data pipeline go to an owner on the operations team, with a simple way to rerun it next year.

What makes projects succeed

• A sponsor who owns the decision and wants it made.
• A small first model delivered early, then improved.
• Validation with operators. Show warehouse managers the store assignments; they will spot an impossible route at once.
• Honest uncertainty. Present ranges, not a single number to the dollar.
• Implementation planning. Many good models die because nobody planned how the result would be used.

Large examples are public: the Franz Edelman Award from INFORMS each year showcases OR projects with measured impact, such as UPS's ORION route-optimization system.

Common mistakes

• Starting with the model before agreeing on the decision and the success measure.
• No baseline, so savings cannot be believed.
• Scope creep: adding supplier choice and pricing halfway through.
• Trusting raw data. Duplicates, missing months and unit mix-ups are normal.
• Handing over a model nobody can run.

Quick recap

• Frame the business problem, translate it to a model, get data, build, validate, deploy, maintain.
• Write a one-paragraph problem statement with decisions, objective, constraints, scope and deadline.
• Validate with a baseline and with the people who run the operation.
• Deliver scenarios and a clear recommendation, not just a solver output.

Try it

In the Do tab, write a one-page scope for a supply-chain optimization project.