Model real decisions with linear and integer programming, networks, queues, simulation and decision trees, then present the results so managers act on them.

Optimization & Operations Research

## Why it matters

The numbers in a model are estimates. Profit per table depends on next month's prices; available hours depend on who calls in sick. A manager rarely asks only "what is the optimal plan?". The next questions are "what if we had one more hour of painting?", "how wrong can the price be before the plan changes?" and "what would it take to make this product worth producing?". **Sensitivity analysis** answers them, and every LP solver reports the numbers you need for free.

## The workshop again

```text
maximize   70x + 50y            (x tables, y chairs)
subject to 4x + 3y <= 240       (carpentry hours)
           2x +  y <= 100       (painting hours)
           x, y >= 0
optimum: x = 30, y = 40, profit 4,100
```

Both constraints are **binding** (tight) at the optimum: all 240 carpentry hours and all 100 painting hours are used. A constraint with spare capacity is **non-binding**, and its **slack** is the unused amount.

## Shadow prices

The **shadow price** (also called the dual value) of a constraint is how much the optimal objective changes per extra unit of its right-hand side, all else equal.

For the workshop, suppose carpentry rises to 241 hours. Re-solving the two binding equations `4x + 3y = 241` and `2x + y = 100` gives `x = 29.5, y = 41` and profit `70 * 29.5 + 50 * 41 = 4,115`. One extra carpentry hour is worth **15**. The same calculation for painting gives **5** per hour.

These two numbers are the solution of the **dual** LP:

```text
minimize   240u + 100v
subject to 4u + 2v >= 70        (a table's resources must be "worth" at least its profit)
           3u +  v >= 50        (same for a chair)
           u, v >= 0
solution: u = 15, v = 5, value 240*15 + 100*5 = 4,100
```

The dual's optimal value equals the primal's (strong duality). The dual variables price each resource so that the products you make exactly "pay" for their resources.

How to use a shadow price:

- **Buy more of a resource only if it costs less than its shadow price.** Overtime carpentry at 12 per hour adds 3 per hour of profit; at 20 per hour it loses money.
- **A non-binding constraint has a shadow price of 0.** Extra capacity you are not using is worth nothing.
- Shadow prices are valid only **within a range** of the right-hand side. For carpentry, the same two constraints stay binding while carpentry hours are between 200 and 300; for painting, between 80 and 120. Outside the range the plan's structure changes and the shadow price changes with it.

## Reduced costs

A variable at zero in the optimal plan has a **reduced cost**: how much its objective coefficient must improve before it is worth making.

In the furniture shop from module 1 (desks, tables, chairs; optimum 2 desks, 0 tables, 8 chairs, profit 280), the shadow prices are 0 for lumber (not binding), 10 for finishing and 10 for carpentry. A table uses 6 lumber, 2 finishing and 1.5 carpentry hours, so its resources are "worth" `0*6 + 10*2 + 10*1.5 = 35`. It earns only 30, so its reduced cost is **5**: raise the table profit above 35 and tables enter the plan. A variable that is already in the plan has a reduced cost of 0.

## Ranges of optimality

How much can one objective coefficient change before the optimal **plan** (the corner) changes? The workshop's corner `(30, 40)` stays optimal while the profit ratio of table to chair stays between the slopes of the two binding constraints, `4/3` and `2`:

- With chair profit fixed at 50, table profit can range from about **66.67 to 100**.
- With table profit fixed at 70, chair profit can range from **35 to 52.5**.

Inside the range, the plan stays the same but the total profit changes. Outside, the solver jumps to a different corner.

## Reading solver output

- **scipy** (`method="highs"`): `res.ineqlin.marginals` are the duals of the `<=` rows and `res.ineqlin.residual` the slacks. Because linprog minimizes, flip the sign when you negated a maximization.
- **PuLP**: after solving, `prob.constraints["carpentry"].pi` is the shadow price and `.slack` the slack; `x.dj` is a variable's reduced cost.
- **Excel Solver** prints a Sensitivity Report with "Shadow Price", "Reduced Cost" and "Allowable Increase/Decrease" columns.

## Important limits

- All of this is **one change at a time**. Several simultaneous changes need re-solving (or a scenario run).
- It applies to **LPs**. Integer programs have no clean shadow prices; analysts re-solve scenarios instead.
- With **degenerate** solutions (more binding constraints than needed to fix the corner), shadow prices can differ depending on the direction of the change.

## Quick recap

- Binding constraints have zero slack; non-binding ones have shadow price 0.
- Shadow price = change in the optimum per extra unit of a resource, valid within a range.
- Reduced cost = how much a zero variable's coefficient must improve to enter the plan.
- Ranges of optimality say how far a coefficient can move before the plan changes.
- Sensitivity holds one change at a time, and only for LPs.

## Check yourself

Answer the questions in the **Do** tab.


Read shadow prices, reduced costs and allowable ranges to answer what-if questions about a linear program.

Sensitivity analysis

Linear Programming - Shadow Price, Slack/Surplus calculations

LP Sensitivity Analysis - Reduced Cost, Shadow Price, Optimality, Feasibility -Excel Output

Write the business problem in the manager's words, in one or two sentences.

Name the decision maker, how often the decision is made, and the deadline.

Write the problem statement: the decisions (variables), the objective and the main constraints, in one paragraph.

List what is in scope and at least three things that are explicitly out of scope.

List the data you need, where each item would come from, and one quality check for each (for example, reconcile freight totals with finance).

Describe the baseline you will build first and how you will compare it with actual past results.

Pick the model type (LP, MIP, network, simulation, decision tree) and give one sentence on why it fits.

List three scenarios you would run and the measure you would report for each.

Name who will own and rerun the model after handover, and one risk to adoption with how you would reduce it.

## 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:

```text
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.


Follow a supply-chain optimization project from the first meeting to the handover, and scope one yourself.

An OR project end to end

2016 Franz Edelman Award Winner UPS

Write the recommendation in one sentence, with no OR terms.

State the value in business units (money, hours, people, minutes of waiting) and what it is compared with.

Give two or three reasons, translating model terms (binding constraint, shadow price) into plain language.

Add a small scenario table with at least three rows (base case and two what-ifs) showing how the answer changes.

List the key assumptions and one risk, with the condition under which the recommendation would change.

End with a clear ask: the decision, budget or pilot you need.

Present it to a friend or family member in three minutes, or record yourself, and ask them to repeat the recommendation back to you.

Revise one sentence that they found confusing.

## Why it matters

An optimization model changes nothing until someone acts on it. The people who decide (operations directors, finance teams, hospital managers) rarely want to see a constraint matrix. They want to know what to do, what it is worth, how sure you are, and what could go wrong. Operations research analysts who can explain a model clearly are the ones whose models get used, and communication is listed in nearly every OR job description.

## Lead with the decision

Structure every presentation or memo as **answer first**:

1. **The recommendation** in one sentence: "Close the Riverside warehouse and move its 14 stores to Northgate and Lakeview."
2. **The value**: "This saves about 410,000 per year (7% of distribution cost) against last year's baseline."
3. **The key reasons**: two or three, in business language.
4. **The risks and conditions**: "The saving holds unless freight rates rise more than 25%; transition costs of about 150,000 are included in year one."
5. **What you need from them**: a decision, a budget, a pilot.

The method goes last, briefly, or in an appendix.

## Translate the model into plain language

Replace OR words with the business meaning.

| model term | say instead |
|---|---|
| decision variables | the choices we can make (which warehouses, which routes) |
| objective function | what we are trying to improve (total yearly cost) |
| binding constraint | the limit that is holding us back (Northgate's dock capacity) |
| shadow price | what one more unit of that limit is worth (each extra dock hour saves about 85) |
| infeasible | there is no plan that meets every rule; one rule has to give |
| optimal | the best plan we found under these assumptions |

Shadow prices are especially valuable to managers: they say where an investment pays off. "An extra painter is worth 5 per hour to us; overtime at 12 per hour does not pay" is a sentence a manager can act on.

## Show trade-offs, not a single answer

Optimal models are only optimal for their assumptions. Show how the answer moves.

- **Scenario table**: base case, demand +10%, freight +20%, one warehouse closed, two closed. One row per scenario, with cost and service level.
- **Trade-off curve**: cost versus service (for example, total cost against the share of stores reached within one day). Managers choose a point on the curve; that is their call, not the model's.
- **Ranges, not false precision**: "about 7% (between 5% and 9% across scenarios)" is more honest than "7.13%".

## Make the result believable

- **Start with the baseline.** "The model reproduces last year's actual cost within 2%" earns trust before you show any saving.
- **Explain one example in detail.** Walk through why store 23 is moved: it is 40 km closer to Lakeview and the truck is half empty today.
- **Name the assumptions** and who agreed them.
- **Show the people who run the operation the plan before the meeting.** Their objections are free validation.

## Visuals that work

- A **map** of the network before and after.
- A **bar chart** of cost by component (fixed versus freight) for each scenario.
- A **simple table** of the decision: which store goes to which warehouse.
- Avoid solver logs, matrix dumps and charts with ten colours.

## Careers in operations research

Operations research analysts work in logistics and transport, airlines, manufacturing, healthcare, energy, finance, consulting, technology companies and government, including defence. Common job titles include operations research analyst, decision scientist, optimization engineer and supply-chain analyst.

What employers usually look for:

- **Education**: a bachelor's in a quantitative field (mathematics, statistics, industrial engineering, computer science, economics) is the usual minimum, and many roles ask for a **master's** in operations research, industrial engineering, analytics or a related field.
- **Skills**: linear and integer programming, simulation, statistics, Python or R, SQL, a solver (Gurobi, CPLEX, CBC, OR-Tools or HiGHS), spreadsheets, and communication.
- **A portfolio**: two or three small projects (a staffing model, a routing heuristic, a simulation of a service line) with a short write-up each, ideally on real public data.

**Professional bodies.** INFORMS (the Institute for Operations Research and the Management Sciences, [informs.org](https://www.informs.org)) runs conferences, student chapters, job boards and the Franz Edelman Award; its Certified Analytics Professional (CAP) credential is optional and not required by most employers. In the UK, the OR Society ([theorsociety.com](https://www.theorsociety.com)) plays a similar role. For job outlook and pay in the US, see the Bureau of Labor Statistics page for [operations research analysts](https://www.bls.gov/ooh/math/operations-research-analysts.htm). Requirements and credentials change, so read the official pages before you plan. Checked on 2026-10-23.

## Common mistakes

- **Leading with the method.** Nobody needs the simplex method in slide 2.
- **Presenting one "optimal" number** without scenarios or ranges.
- **Using jargon** such as "the dual of constraint 7 is non-zero".
- **Hiding assumptions.** When one turns out wrong, trust in the whole model goes with it.
- **No clear ask.** End with the decision you need.

## Quick recap

- Answer first: recommendation, value, reasons, risks, ask.
- Translate model terms into business language; shadow prices become "what one more unit is worth".
- Show scenarios, trade-offs and ranges.
- Build trust with a baseline, a worked example and operator review.
- OR careers usually need a quantitative degree (often a master's), solver and coding skills, and a portfolio.

## Try it

In the **Do** tab, turn one of this course's models into a one-page brief for a manager and present it.


Explain an optimization model and its trade-offs to managers, and see what an operations research career requires.

Presenting models

Data Presentation Tutorial | Effectively Communicate Insights to Stakeholders

Operations Research Analysts Career Video

Read sensitivity reports, run an OR project from scoping to handover, and present a model so managers can act on it.