Formulating an Optimization Model

Ask a room of managers "what should we do?" and you get a paragraph — a tangle of goals, resources, rules and hunches. Ask a solver the same question and it needs three precise things: what you may choose, what you want to make best, and what you are not allowed to break. The single hardest, most valuable skill in operations research is the bridge between those two worlds: turning a paragraph into a model. Solving is the part computers do; formulating is the part that decides whether the answer is worth having. A perfectly solved model of the wrong problem is, as we said at the start, wrong with authority.

This page is about that craft — reading a messy situation and writing down its decision variables, its objective, and its constraints, cleanly and honestly.

Variables versus parameters — the first cut

Before anything else, sort every number in the problem into one of two piles. A decision variable is something you control — a quantity the model is free to set (how many tables to build, how many litres to blend, whether to open a depot). A parameter is something you are given — a price, a yield, a capacity, a demand — fixed data that the model reads but cannot change.

If the answer to "could a different decision make this bigger or smaller?" is yes, and you are allowed to make that decision, it is a variable.
If it is a number the world hands you and holds fixed while you decide, it is a parameter (a coefficient in the model).

Getting this cut wrong is the classic beginner's error: freezing something you could have chosen (and so missing the best answer), or treating a fixed cost as adjustable (and so proposing the impossible). A useful discipline is to name the variables first — x_1, x_2, \dots — write exactly what each one counts, and only then let the parameters attach to them as coefficients.

The objective must match the real goal

The objective is the one number you push up or down: profit, cost, time, distance, risk. It sounds obvious, yet it is where models quietly go wrong. Maximising revenue is not maximising profit; minimising cost per unit is not minimising total cost; keeping every machine 100% busy is not delivering orders on time. The objective is a modelling choice, not a mathematical one — choose the quantity the organisation ultimately cares about, and write it as a single linear expression in the variables:

\text{maximise (or minimise)}\quad c_1 x_1 + c_2 x_2 + \dots + c_n x_n .

Each c_j is the per-unit contribution of variable x_j to that goal — the profit of one table, the cost of one litre, the minutes of one trip.

Constraints: the rules reality imposes

Constraints are where honesty lives. Most fall into a handful of recognisable families, and learning to spot them turns a paragraph into a checklist:

Family	What it says	Typical shape
Capacity / resource	You cannot use more than you have	\sum_j a_j x_j \le b
Demand / requirement	You must supply at least this much	\sum_j a_j x_j \ge d
Balance	What goes in equals what comes out	\sum \text{in} = \sum \text{out}
Sign / non-negativity	You cannot make a negative amount	x_j \ge 0

Non-negativity is a real constraint, not a formality. Leave off x_j \ge 0 and the solver will happily "make" −5 chairs to free up wood for tables. Every physical quantity needs its sign pinned down; a variable that genuinely can go either way (a bank balance, a temperature change) is called free and must be declared so deliberately.

Worked example: from paragraph to program

Read this once, then watch it dissolve into mathematics.

"A café bakes two things for the weekend market: batches of scones and batches of muffins. A batch of scones earns £8 profit, a batch of muffins £10. Each batch of scones needs 2 kg of flour and 1 hour of oven time; each batch of muffins needs 1 kg of flour and 2 hours. The café has 40 kg of flour and 50 oven-hours available."

Step 1 — variables. What may the café choose? The number of batches of each. Let x_1 = batches of scones, x_2 = batches of muffins. The £8, £10, kilograms and hours are all parameters.

Step 2 — objective. The goal is profit, and profit is 8x_1 + 10x_2, to be maximised.

Step 3 — constraints. Flour is a capacity limit: 2x_1 + x_2 \le 40. Oven time is another: x_1 + 2x_2 \le 50. And you cannot bake negative batches. Assembled:

\max\; 8x_1 + 10x_2 \quad\text{s.t.}\quad 2x_1 + x_2 \le 40,\;\; x_1 + 2x_2 \le 50,\;\; x_1, x_2 \ge 0.

Three lines have captured the whole weekend. The diagram below traces the same journey — a word problem fanning out into the three parts of a model, then reassembling as a program you can hand to a solver.

Three classics worth recognising

A surprising fraction of real formulations are variations on three templates. Learn their shapes and half your modelling is pattern-matching:

Template	Decision	Objective	Key constraints
Product mix	How much of each product to make	Maximise profit	Resource capacities (\le)
Diet / blending	How much of each ingredient to use	Minimise cost	Nutrient / quality requirements (\ge)
Transportation	How much to ship on each route	Minimise shipping cost	Supply limits and demand balance

Notice that product mix pushes up against resource ceilings (\le), while the diet problem is pulled up to meet nutritional floors (\ge) at least cost — the same machinery, mirror-imaged.

Keep it linear — and keep the units straight

A model is linear when the objective and every constraint are weighted sums of the variables: each variable appears to the first power, multiplied only by a constant. The moment you write a product of variables (x_1 x_2), a ratio (x_1 / x_2), a power (x_1^2) or a step/if-then rule, you have left linear programming for the far harder world of nonlinear or integer models. Whenever the physics genuinely permits it, keep the model linear — the payoff in solvability is enormous.

Finally, a humble but ruthless check: units must agree across every term of a constraint. If the left side of a line is in kilograms, the right side must be in kilograms; a coefficient in "hours per batch" times a variable in "batches" gives "hours", which had better match an "hours" capacity on the right. Dimensional bookkeeping catches more modelling bugs than any other single habit.

In 1945 the economist George Stigler asked a wonderfully practical question: what is the cheapest diet that still meets a human's daily needs for calories, protein, vitamins and minerals? He set it up as a linear program with 77 foods and nine nutrient requirements — but with no computer to hand, he solved it by shrewd guesswork, arriving at a grim but adequate menu costing about \$40 a year in 1939 prices. When the simplex method arrived a few years later, it found the true optimum in a handful of pivots and confirmed Stigler was within a few cents. The diet problem has been a teaching staple ever since — proof that "minimise cost subject to meeting every requirement" is one of the oldest and most useful shapes in the book.

The most common formulation failure is not a wrong equation — it is a missing one. A model that leaves out a hidden constraint will cheerfully return a "solution" that is impossible in reality: negative production because non-negativity was dropped; a schedule that ignores a maintenance window; a blend that meets the average spec but violates a limit no one wrote down. The two silent killers are a forgotten constraint (the model permits the impossible) and a mismatched objective (the model optimises the wrong thing and does it beautifully). Before trusting any answer, ask of every constraint "is it in the model?" and of the objective "is this really what we want more of?" No solver will ask these for you.