Operations Research for Social Good A Practitioners Introduction Using SAS® and Python

1. 1Write the decision in plain language before any math. Use the book's three-line template: 'I need to decide X (decision variables). I want to achieve Y (objective function). Z cannot happen (constraint).' If you can't fill all three lines, the problem isn't ready for a model.
2. 2Name the scarce resources as constraints. List every financial, human, and material limit that binds: budget, staff or manpower, equipment, tests, capacity per facility. Cleveland Clinic's reopening model capped each resource's capacity, ICU utilization, and the daily supply of rapid tests.
3. 3Pick the objective that expresses efficiency as a KPI: maximize revenue, maximize margin, minimize shortage, minimize overtime, minimize deviation from budget. If two goals compete, rank them. Optimize the primary first, then optimize the secondary while holding the primary within a stated tolerance (the book's example is within 10% of the optimum).
4. 4Check whether the model needs a predictive input. A demand equation such as Demand = 100 − 0.2 × Price comes from a regression or forecast. Build or source that input first, and cap decisions at forecasted demand, as the Clinic model did for patients accepted.
5. 5Write the algebraic formulation, then code it in SAS OPTMODEL or Python Pyomo, then call a solver. Keep the formulation and the code side by side so you can trace each line back to a rule.
6. 6Record the status quo before you solve. The book's claim is that a feasible but not globally optimal solution can still beat the status quo, so you need that baseline to show the gain.
7. 7If run time grows, shrink the model before accepting a weaker answer. Remove variable combinations that violate a rule, such as donor/drop-off pairs beyond the allowed distance. Disaggregate big-M constraints. Reformulate MILP models as network models where the structure fits, so specialized algorithms run faster.
8. 8Report efficiency as a before/after comparison on the chosen KPI, using the same constraints for both. Show the resulting plan as a table or plot, as the police patrol use case does with its shortage plots.

In March 2020, COVID-19 forced hospitals to reassign most resources to ERs and ICUs and to pause elective surgeries. SAS and Cleveland Clinic built a Multicriteria MILP to decide which subservices to reopen and on what dates. The decision variables were the subservices selected and the reopening dates. The constraints were that resource capacity at each facility could not be exceeded, ICU utilization stayed under a set limit, patients accepted never exceeded maximum forecasted demand, and daily emergency surgeries plus accepted patients across all facilities stayed within the number of daily rapid tests. A logical condition kept a subservice open once it opened. The two objectives were to maximize total revenue and total margin, both functions of patients accepted over the planning horizon. The aim was to reboot cash flow, which in turn supports emergency care. Scarce manpower, equipment, and tests were allocated to the sequence of reopenings that earned the most, rather than reopening by instinct. The passages give no result figures, so the resource-efficiency gain here is the structure of the decision, not a quoted number.

• If a decision has many options and hard resource limits (budget, staff, tests, capacity), then model it with optimization rather than a descriptive report or a forecast alone.
• If the objective depends on demand or another uncertain relationship, then build the forecast or regression first and feed it into the model as a constraint or parameter.
• If two goals compete, then rank them: optimize the primary, then optimize the secondary within a stated tolerance of the primary optimum.
• If the solver is slow or cannot prove optimality, then accept a good feasible solution when it beats the status quo, and meanwhile reduce variables or reformulate as a network model.
• If the problem has nonlinear terms and integer variables together (MINLP), then simplify first. The book warns this is where you are 'in for a big headache.'

• Modeling without a baseline. The tell: you report an 'optimal' plan but cannot state the current plan's KPI value, so no efficiency gain is demonstrable.
• Missing or loose constraints. The tell: the solution looks excellent but breaks a real limit, such as exceeding ICU utilization, test supply, or capacity, so operators reject it.
• Skipping the predictive input. The tell: demand or sales values are hard-coded guesses, so the plan optimizes against numbers nobody trusts.
• Chasing global optimality at any cost. The tell: run times stretch for hours while a feasible solution that already beats the status quo sits unused.
• Building the model without a user adoption process. The tell: the model is correct but no one owns the decision workflow. The book names established processes and user adoption as a prerequisite for end value.

• ▸Decision to make: one sentence, 'I need to decide…' (the controllable actions).
• ▸Scarce resources: list each financial, human, and material limit with its numeric cap.
• ▸Objective KPI: the single primary goal (maximize/minimize what) and the secondary goal, if any.
• ▸Secondary tolerance: how far the primary may slip to improve the secondary (for example, within 10% of optimum).
• ▸Predictive inputs needed: demand, price response, or forecasts the model depends on, and their source.
• ▸Business rules and logic: conditions such as 'once open, stays open' or 'projects 2 and 5 not together.'
• ▸Status quo KPI value: current plan's result on the objective, measured under the same constraints.
• ▸Model result KPI value: the solver's result and whether it is proven optimal or just feasible.
• ▸Efficiency gain and owner: the difference from baseline, plus who adopts the decision and by when.

1. 1State the social outcome in the population's terms before touching the model. In the WFP case it is people fed with a nutritious ration (the organization reaches about 80 million people in 75 countries each year), not dollars saved. Write one sentence: 'Success means [population] gets [health/access/safety/hunger result].'
2. 2Translate that outcome into the objective and constraints (the Problem Definition step). Decide which part of the impact is the goal (for example, minimize cost) and which part is a hard rule (for example, nutrient minimums). In the food basket use case, required nutrition levels are the impact guarantee and cost is what gets minimized.
3. 3Encode the impact floor as data, not as a hope. List each impact requirement as a data input with a number: nutrient name and minimum required level (Calories 1800, Protein 45, Fiber 26 in the snapshot). If you cannot write the requirement as a row in a table, you have not defined the impact yet.
4. 4Separate data inputs from settings inputs. Data inputs are large tables from databases (cost per food, nutrient content). Settings inputs are single values a user can change (overall budget, maximum number of items). Put impact thresholds and budget in settings so stakeholders can test them.
5. 5Run the model and read the solution against the impact definition, not just the objective value. Check each constraint tied to the population (nutrient minimums met, rooms not above reduced capacity, donors assigned to sites) and confirm the output table answers the practical question (what goes in the basket, who is assigned where).
6. 6Stress-test the impact with practice-problem style what-ifs. Disallow an item (for example, force Oatmeal to 0), change a cost (new volunteer cost rises to $1200), or change the budget, then compare how the solution and the impact change.
7. 7When impact has more than one dimension, use multicriteria optimization. Rank priorities and bound the loss on the first one, as in the tourism problem: maximize expenditure first, then maximize tourist count while staying within 10% of the optimal expenditure.
8. 8Credit and trace the source application. Each use case documents the original authors and the real-world impact; record where your impact figures come from so the claim can be checked.

The United Nations World Food Programme (WFP) is the largest humanitarian agency fighting hunger, reaching around 80 million people with food assistance in 75 countries each year. Peters et al. built a model that jointly optimizes the food basket, sourcing plan, and routing plan for a recovery operation; it won the 2021 Franz Edelman Award. The book's simplified version isolates the food basket: choose the amount of each food commodity so that required nutrition levels are met at minimum cost. The impact is encoded as the INPUTMININTAKE table: Calories 1800, Protein 45, Fiber 26 (example values). Cost data come from INPUTFOOD (Beef 6, Cheese 0.5, Corn Meal 0.5), and nutrient content from INPUTFOODNUTR (Corn Meal: Calories 360, Protein 9, Fiber 1). The decision variable is the amount of each commodity, and the model buys the cheapest combination that still satisfies every nutrient minimum. The social impact, a nutritious ration for each recipient, is therefore a constraint that cannot be traded away, while cost savings determine how many more people the same budget can reach. A practice problem then disallows Oatmeal to see how the optimal basket changes, which tests whether the impact survives a supply restriction.

• If the impact can be stated as a minimum level (nutrient, capacity, coverage), then make it a constraint and minimize cost; if you can only state it as 'more is better', make it an objective.
• If stakeholders disagree on priorities, then use ranked objectives with a tolerance on the top one (for example, within 10% of the optimum) instead of blending them into one weighted number.
• If a value should be adjustable by the client (budget, number of items, safety capacity percentage), then place it in settings inputs, not buried in data tables or code.
• If an auxiliary binary variable is needed to enforce a safety or access rule (for example, grades not mixed in a room), then use a tight data-dependent big-M such as the grade's population, not 99999.
• If a commodity or option may become unavailable, then rerun with it fixed to 0 and check whether the impact constraints are still met.

• Optimizing cost or revenue and calling it impact. Tell: the objective is dollars, and no constraint or output references the population's health, access, or safety result.
• Impact floors left out of the model. Tell: the solution is cheap but you cannot point to the table row (such as a nutrient minimum) that guarantees the outcome.
• Using a loose big-M such as 99999 to enforce a population rule. Tell: numerical difficulties or long run-times, or, if M is too small, feasible solutions cut off.
• Collapsing competing goals into one objective without checking trade-offs. Tell: stakeholders cannot say how much of one goal was given up for the other, as the 10% tolerance in the tourism problem would show.
• Never testing the solution against changed conditions. Tell: no what-if runs (item disallowed, cost increased, budget changed), so you do not know whether the impact holds when inputs change.

• ▸Target population: who benefits (for example, recipients of food assistance in a recovery operation).
• ▸Impact statement: one sentence describing the health, access, safety, or hunger outcome.
• ▸Impact measure(s): the specific quantities that show the outcome (for example, nutrient levels, students safely seated, donors assigned to sites).
• ▸Minimum thresholds: the required value for each measure, with the source of each number.
• ▸Objective: what you minimize or maximize (cost, shortage, expenditure) and how it relates to reaching more people.
• ▸Settings inputs: single values the client can change (budget, maximum items, capacity percentage).
• ▸Priority order and tolerance: if multiple objectives, which comes first and how much loss is allowed (for example, within 10%).
• ▸What-if tests: at least two changes to run (item disallowed, cost increase) and the result of each.
• ▸Source credit: original authors and link for the application and its reported impact.

1. 1Write the problem in one sentence of the form 'find the [controls] such that [rules] are met at [goal]'. The WFP food basket problem reads: find the optimum food commodities to include in the package, such that required nutrition levels are achieved at minimum cost.
2. 2Split the sentence into the three elements the book's Problem Definition section uses: goals/objective functions, rules/constraints, and controls/decision variables. Put each in its own list, one item per line, before writing any algebra.
3. 3Name each decision variable by what the user controls, not by what the model computes. In the food basket, the control is how much of each commodity goes into the basket. Cost and nutrient totals are derived quantities, not controls.
4. 4Sort every input into data or settings. Data comes from databases and can be large (cost of each food element, nutrient content per commodity, product demand). Settings are single values the user can change (overall budget, maximum number of products in a promotion). Build the data dictionary: table name, variable name, type, description.
5. 5Check that every constraint traces to a stated rule and every rule to a constraint. In the food basket, the minimum required level for each nutrient becomes one constraint per nutrient, using the nutrient content of each commodity as coefficients.
6. 6Write the algebraic formulation (sets, parameters, variables, objective, constraints) before any SAS OPTMODEL or Pyomo code. Use summation notation, since the book assumes that is the only linear-algebra prerequisite.
7. 7Classify the model type (LP, MILP, NLP, network, multicriteria) from the formulation itself. Continuous quantities with linear terms mean LP. Yes/no choices require binaries and mean MILP. Then pick the solver family from that class.
8. 8Extend in stages, as the book does. Solve the simplified basket first, then add delivery decisions (section 4.3). Confirm the base formulation is clean before adding variables.

The WFP food basket problem, simplified from the Franz Edelman Award-winning work of Peters et al. Problem definition: find the optimum food commodities to include in the package so that required nutrition levels are met at minimum cost. Goal: minimize total basket cost. Controls: the amount of each food commodity (for example, Eggs Raw) in the basket. Rules: the basket must reach the minimum required level of each nutrient. Inputs, all classed as data: nutrient levels per commodity, cost per commodity, and the minimum required level per nutrient. The formulation follows directly. The objective sums cost times quantity over commodities. Each nutrient has one constraint summing nutrient content times quantity and requiring at least the minimum level. Every term maps back to a sentence in the problem definition, so a reviewer can check the model against the real problem line by line. The passages do not give the numeric values, so none are asserted here.

• If you cannot state the goal, rules, and controls as three separate lists, stop. The problem is not yet formulated, and writing code will only hide the gap.
• If a quantity can be changed by the user as a single number (budget, cap on items), make it a settings input. If it is a table pulled from a database, make it a data input.
• If a decision is yes/no (open a site, assign a student to a day), model it as a binary variable and treat the problem as MILP. If amounts are continuous and linear, stay with LP.
• If the full problem mixes several decisions (basket, sourcing, routing), formulate the simplest sub-problem first, as the book does with the food basket, and add decisions in later stages.
• If a constraint has no corresponding real-world rule, or a rule has no constraint, fix the formulation before solving.

• Defining variables as outcomes instead of controls (such as 'total cost' as a decision). The tell: you cannot say who or what sets the variable's value in the real operation.
• Mixing data and settings so the user cannot adjust the budget or an item cap without editing a table. The tell: a what-if run requires changing the source data.
• Omitting a rule that exists in practice, for example leaving out one nutrient's minimum. The tell: the solver returns a cheap solution that the domain expert rejects on sight.
• Coding before writing the algebra, so SAS and Python versions of the model drift apart. The tell: the two solvers return different results on the same data.
• Starting with the full, complex problem instead of a simplified one. The tell: the model has many variable types and constraint families, and no one can say which part is wrong.

• ▸One-sentence problem: 'Find [controls] such that [rules] at [goal]'.
• ▸Goal / objective function: state what is minimized or maximized and in which units.
• ▸Controls / decision variables: list each, its index set, and its type (continuous, binary, integer).
• ▸Rules / constraints: list each real-world rule in plain words, with the inequality direction (at least, at most, equal).
• ▸Data inputs: table name, variable, type, description (large, database-sourced).
• ▸Settings inputs: single values the user can modify (budget, item caps) with default values.
• ▸Rule-to-constraint trace: for each rule, the constraint that encodes it, and vice versa.
• ▸Model class: LP, MILP, NLP, network, or multicriteria, with a one-line reason.
• ▸Simplification and staging plan: which sub-problem you solve first and what you add next.

1. 1Write the problem in plain language first: 'I need to decide X (decision variables). I want to achieve Y (objective). Z cannot happen (constraint).' Do this before any algebra, because model type is read off the algebra that follows.
2. 2Classify every decision variable as continuous, integer, or binary. Binary or integer variables (select a subservice, open a site, assign a classroom) rule out plain LP and point to MILP. Continuous-only variables keep you in LP or NLP.
3. 3Write each constraint and the objective algebraically, then test each for linearity. Check whether any term multiplies two variables or whether a variable enters through a nonlinear function. Any such term moves you from LP/MILP to NLP.
4. 4Trace any predictive relationship embedded in the model. The source's demand equation, Demand = 100 − 0.2·Price, comes from a predictive model. Substitute it into the objective and check whether the result is still linear in the decision variables.
5. 5Count the objectives. One objective keeps you in LP, MILP, or NLP. More than one makes it Multicriteria Optimization, which can combine with linear or nonlinear constraints and with continuous, integer, or binary variables.
6. 6Match your findings to the type table: LP (continuous, linear, one objective), MILP (continuous/integer/binary, linear, one objective), NLP (continuous, nonlinear constraints, one objective), Multicriteria (more than one objective). Pick the simplest type that represents the problem without distortion.
7. 7Check for network structure: shortest path, traveling salesman, or minimum-cost network flow. If the MILP is really a network model, reformulate it as a Network model so specialized algorithms replace generic Branch-and-Bound, which is much slower.
8. 8Match the solver call to the chosen type. SAS offers LP, MILP, NLP, and network solvers, and the modeling language stays the same. If the problem is too large for existing solvers, only then consider custom algorithms or heuristics.

The source's pricing example: decide a price for each product, maximize revenue, keep margin nonnegative, with demand = 100 − 0.2·Price. Variables are continuous (prices, Price ≥ 0). The objective is sum over p of Demand_p × Price_p. Substituting demand gives (100 − 0.2·Price_p)·Price_p, a price-times-price term, so the objective is nonlinear and the problem is NLP, not LP. The margin constraint, sum of (Price_p − Cost_p) ≥ 0, is linear, so the nonlinearity comes only from the demand-revenue interaction. A second source case: the Cleveland Clinic reopening model chooses which subservices to reopen and when, so its variables are binary/integer. Its constraints are linear (capacity, ICU utilization limits, and rapid-test limits). It also includes a logical condition that an open subservice stays open. It has two objectives, maximize revenue and maximize margin. Binary variables with linear constraints give MILP, and two objectives make it Multicriteria MILP, which is how the source classifies it.

• If any decision variable must be whole or yes/no (open a site, select a service, assign a group), then use MILP rather than LP, since LP variables are continuous.
• If the objective or any constraint contains a product of variables or another nonlinear relationship, such as price multiplied by price-dependent demand, then use NLP.
• If you have more than one KPI to optimize, such as revenue and margin, then treat it as Multicriteria Optimization instead of collapsing goals without a decision.
• If the MILP describes shortest path, traveling salesman, or minimum-cost network flow, then reformulate it as a Network model to use specialized algorithms.
• If a model is complex and no global optimum is reachable in reasonable time, then accept a good feasible solution when it beats the status quo, rather than oversimplifying the model type.

• Treating a demand-driven revenue objective as linear because the demand equation looks simple. The tell: the objective contains Price × Demand(Price), and an LP solver cannot represent it faithfully.
• Using LP and rounding the results for decisions that are inherently binary or integer. The tell: fractional values for 'open/close' or 'assign' variables.
• Declaring everything MILP and skipping the network check. The tell: a routing or flow problem that is slow under Branch-and-Bound when specialized network algorithms would solve it faster.
• Forgetting that a predictive model feeds the optimization. The tell: demand or KPI relationships appear in the constraints as unexplained numbers, and nobody has checked whether they are linear.
• Merging multiple goals into one without noticing. The tell: stakeholders cite two KPIs (revenue and margin) while the model has a single objective.

• ▸Decision statement: 'I need to decide ___' in plain language.
• ▸Objective(s): list each KPI goal and count them (one vs. more than one).
• ▸Variable types: list each decision variable as continuous, integer, or binary.
• ▸Constraint linearity: for each constraint, mark linear or nonlinear and name the nonlinear term.
• ▸Objective linearity: mark linear or nonlinear after substituting any predictive relationships (e.g., demand equations).
• ▸Predictive inputs: list forecasts or regressions embedded in the model and whether they are linear in the decisions.
• ▸Network structure check: does it resemble shortest path, traveling salesman, or min-cost flow? Yes/No.
• ▸Selected type: LP / MILP / NLP / Multicriteria / Network, with a one-line justification.
• ▸Solver and fallback: solver chosen, and what feasible-solution quality counts as better than the status quo.

1. 1Inventory the formulation before opening an editor. List decision variables (controllable actions), constraints (rules and limitations), and objective(s) (KPI goals), as in the book's Table 2.1. Every line of model code must trace back to one of these three. If a line does not, it is either a data step or a bug.
2. 2Write the generic algebraic form next to the code: objective coefficients c_j, constraint coefficients a_ij, right-hand sides b_i, bounds ℓ_j and u_j. Declare bounds explicitly. Physical quantities usually have ℓ=0 and u=∞, but either bound can be finite, so decide which applies rather than relying on a default.
3. 3Drive the model from tables, not literals. Use the use-case data dictionary pattern: one demand table (e.g., INPUTDEMAND with Time and Demand) and one settings table (INPUTSETTINGS with SettingName, SettingValue, SettingDesc). Read constants such as CAPACITY=40 or a tolerance from the settings table so the same code runs on new data.
4. 4Pick the decision-variable definition that keeps the model compact. In the patrol-scheduling case, define variables as officers who begin a shift at each time of day, not officers patrolling at each time. The source calls this the more compact formulation.
5. 5Implement each objective measure as its own, separately named piece. Total shortage (sum of unmet need across all windows) and maximum shortage (largest unmet need in any window) are different safety concerns. Code them as distinct objectives so you can switch or combine them without rewriting constraints.
6. 6Classify the problem type, then choose or confirm the solver. All-continuous with linear parts is an LP, integers with linear parts is a MILP, and nonlinear with continuous variables is an NLP. A mixed-integer nonlinear problem is flagged as a 'big headache', so reformulate if you land there. In SAS the default algorithm follows problem structure. In Python, call GLPK for LP/MILP and IPOPT for NLP.
7. 7Override defaults only for a structural reason. Use the concurrent option to race algorithms, the network simplex for network-flow structure, Dantzig-Wolfe decomposition for block-angular constraint matrices, and multistart for NLPs with many local optima.
8. 8Verify the output against the formulation. Confirm that decision values respect the settings (e.g., headcount within the capacity setting) and that each reported objective matches its definition. For NLP, remember the result is only locally optimal unless you have evidence of global optimality.

Take the police patrol scheduling use case. The data dictionary defines INPUTDEMAND (Time: beginning hour of the window; Demand: required officers patrolling) and INPUTSETTINGS (SettingName, SettingValue, SettingDesc, e.g., CAPACITY = 40). The snapshot reads roughly Time 0 → 19, Time 1 → 7, Time 2 → 6 (parsed from flattened text). Implementation starts by mapping components: the decision variable is the number of officers starting a shift at each time of day, the constraint is that total scheduled officers cannot exceed the capacity setting, and the objective is to minimize shortage. Because 'shortage' has two meanings, you code two objectives: total shortage (sum of unmet need over all windows) and maximum shortage (largest unmet need in any window). Capacity and the tolerance parameter are read from the settings table, not typed into the model. The problem is linear, so SAS chooses its LP algorithm from the structure, and Python could use GLPK for the same formulation, adding integrality if you need whole officers. You then check that the solution never schedules more than 40 officers and that the reported shortage equals the sum or maximum of the unmet demand you calculate by hand.

• If a constant (capacity, tolerance, budget) appears in a constraint, then it belongs in the settings table, not the code.
• If the problem has all continuous variables with linear parts, then solve it as an LP and accept the default algorithm first. Override it only for known structure: network, block-angular, or many more variables than constraints.
• If integer variables enter a nonlinear problem (MINLP), then stop and reformulate before coding. The source warns of 'a big headache'.
• If an NLP may have many local optima, then enable multistart and treat the result as locally optimal unless you have evidence of global optimality.
• If stakeholders disagree on what 'shortage' means, then implement total and maximum as separate objectives rather than choosing silently.

• Hardcoding settings values: changing CAPACITY requires editing model logic, and results differ between runs with 'the same' data. The tell is numbers in constraints that do not appear in the settings table.
• Choosing a bulky variable definition (officers patrolling per hour instead of shift starts): the model gets larger and harder to read, and the constraints fail to mirror the written formulation.
• Conflating total and maximum shortage: the objective runs but answers a different safety question than the one asked. The tell is a solution that balances sums while leaving one window badly uncovered, or the reverse.
• Forcing a solver or algorithm without a structural reason, or ignoring the problem class: the solve is slow or fails. The tell is an NLP/MINLP sent to an LP solver or an unexplained algorithm override.
• Reporting an NLP result as 'the optimum' when it is only locally optimal: the tell is that different starting points give different objective values.

• ▸Decision variables: list each with its meaning, index set, and bounds (ℓ, u).
• ▸Constraints: list each rule in words, then its algebraic form (a_ij, b_i, and =, ≤ or ≥).
• ▸Objective(s): name each KPI and whether it is a sum or a max.
• ▸Data tables: list table names and columns, copied from the data dictionary.
• ▸Settings table entries: list every constant (SettingName, SettingValue) read from data, not hardcoded.
• ▸Problem class: LP, MILP, or NLP, and confirm it is not MINLP.
• ▸Solver and options: record the solver (SAS default, GLPK, or IPOPT) and any override with its structural justification.
• ▸Output verification: list hand-computed checks (capacity respected, objective recomputed).
• ▸Optimality status: state whether the solution is optimal or only locally optimal (NLP), and whether multistart was used.

1. 1Classify the model before you pick a solver. The book separates LP (all variables continuous, linear objective and constraints), MILP, NLP (objective and/or some constraints nonlinear), and MINLP, which the authors call 'a big headache'. The class sets what 'optimal' can mean and how long you wait.
2. 2Write down the solution-quality standard you need: feasible only, locally optimal, or globally optimal. Both NLP algorithms in SAS return a locally optimal solution, meaning feasible and better than any nearby solution. A globally optimal solution has the best objective value among all solutions, nearby or not.
3. 3Match the LP algorithm to the problem shape. Primal simplex runs Phase I (find a feasible solution) and then Phase II (improve to optimal). The sifting algorithm tends to do better when variables far outnumber constraints. Dual simplex is more efficient to warm start when constraints are added, as in branch-and-bound for MILP.
4. 4Exploit warm starts for sequences of related problems. If every feasible solution of one LP is feasible for the next, as when new decision variables are added, a warm-started primal simplex skips Phase I. If constraints are added instead, use dual simplex.
5. 5For NLP, choose between active-set and interior point. Active-set considers all equality constraints and only a subset of inequalities per iteration, which can cut computation time. Interior point suits large-scale NLPs and uses parallel processing naturally. In SAS it is the default.
6. 6When you cannot tell which NLP algorithm will finish first, use the concurrent option. It runs active-set and interior point simultaneously on multiple threads and returns an optimal solution when the first one finishes.
7. 7When an NLP may have many locally optimal solutions, turn on the multistart option. It improves the likelihood of finding a globally optimal solution. It does not guarantee one.
8. 8Verify the returned solution against the problem definition. Check every constraint, such as non-negative profit, budget limits and demand = 100 − 0.2 × Price. Then compare the SAS and Python results, since the book solves each use case in both OPTMODEL and Pyomo (with solvers such as IPOPT).

The book's prostate brachytherapy seed-placement use case (Chapter 6) is an NLP, so quality has to be read in NLP terms. SAS solves it with interior point by default, and either NLP algorithm returns a locally optimal solution: feasible, and better than any nearby solution. That is not a global guarantee. For a problem with many local optima you would add the multistart option to raise the chance of landing on the global one. If you did not know whether active-set or interior point would be faster, the concurrent option runs both on separate threads and returns the first optimal result. You can then replicate the model in Python with Pyomo and IPOPT, a widely used NLP solver, and check that the objective values agree. The book's practice-problem solution for a nonlinear revenue problem is a useful benchmark: optimum revenue, accounting for disposal costs, is $518.86. Your solver output should reproduce that figure.

• If every variable is continuous and everything is linear, treat the problem as an LP and expect a proven optimum. If any variable becomes integer in a nonlinear model (MINLP), expect trouble and consider reformulating.
• If you re-solve an LP after adding variables, use primal simplex with a warm start. If you re-solve after adding constraints, use dual simplex.
• If an LP has far more variables than constraints, try the sifting algorithm.
• If the NLP is large-scale, start with interior point. If you are unsure which NLP algorithm is faster, use the concurrent option.
• If the NLP may have several local optima, use multistart and report the result as 'likely global', not 'proven global'.

• Calling an NLP result 'optimal' when it is only locally optimal. The tell: a different starting point gives a different objective value.
• Using MINLP formulations without recognizing the added difficulty. The tell: runtimes blow up or no solution returns in an acceptable time.
• Restarting from scratch on a sequence of related LPs. The tell: Phase I is repeated every time even though the previous solution is still feasible.
• Choosing an algorithm without regard to problem shape, such as primal simplex on a model with vastly more variables than constraints. The tell: slow solves where sifting would suit.
• Accepting a returned solution without checking it against the stated constraints and a second implementation. The tell: SAS and Python objective values disagree, or a rule such as non-negative profit is violated.

• ▸Problem class: LP, MILP, NLP or MINLP, with a one-line reason.
• ▸Quality target: feasible only, locally optimal, or globally optimal required.
• ▸Time limit: the acceptable wall-clock time for one solve.
• ▸Algorithm chosen and why: primal simplex, dual simplex, sifting, active-set or interior point, matched to problem shape.
• ▸Warm start available?: record what changed (variables added or constraints added) from the previous solve.
• ▸Concurrent / multistart settings: on or off, with the reason.
• ▸Result status: feasible, locally optimal or globally optimal as reported, plus the objective value.
• ▸Cross-check: the objective value from a second implementation (SAS vs Python) or a known benchmark, and the difference.
• ▸Constraint verification: list each key constraint and whether the solution satisfies it.

1. 1Write the decision in plain language before any math. Use the passage's template: 'I need to decide how to price my products (decision variables). I want to achieve highest revenue (objective function). Margin cannot be negative (constraint).' If the decision owner cannot confirm these three sentences, the model's output will not be adopted.
2. 2Name the controllable actions as decision variables and list who controls each one. In the Cleveland Clinic case these were which subservices to reopen and on what dates. A variable nobody in the organization controls cannot produce an adoptable recommendation.
3. 3Capture every rule and limit as a constraint with the person who owns it. Examples: resource capacity cannot be exceeded, ICU utilization stays under an upper limit, accepted patients never exceed maximum forecasted demand, daily rapid tests cap total patients. Decision-makers trust outputs that visibly respect their real limits.
4. 4Separate inputs that need a predictive model from inputs that are fixed. The demand equation 100 − 0.2*Price needs a model of price versus demand, and the capacity constraints used forecasted demand. Validate those upstream models first, because the optimization inherits their errors.
5. 5Define the objective as KPIs the organization already tracks. Use one objective (maximize revenue) or several (the Cleveland Clinic model used two, both revenue-based, to reboot cash flow). With more than one objective, treat the problem as multicriteria and agree on the trade-off with leadership.
6. 6Formulate algebraically, code it in SAS OPTMODEL or Python Pyomo, and call a solver. Check that the output obeys every written constraint before showing it to anyone.
7. 7Accept a good feasible solution when a provable optimum is out of reach. The passage notes that a feasible but not globally optimal solution can still provide significant business value over the status quo. Compare the model's recommendation against the current heuristic and present the gap.
8. 8Build the adoption process alongside the model. The passage names 'established processes to incorporate new decision-making support systems that focus on user adoption and end value' as a precondition. Name who acts on the output, when, and what happens if they override it.

In March 2020, hospitals had to reassign resources to keep ERs and ICUs ready for COVID-19 and put elective surgeries on hold. SAS and Cleveland Clinic built a Multicriteria MILP to decide when to reopen those optional services. The decision variables were which subservices to reopen and the reopening dates. The constraints were resource capacity at each facility, an upper limit on ICU utilization, patients accepted never exceeding maximum forecasted demand, a daily cap tied to available rapid tests, and a rule that an opened subservice stays open for the rest of the horizon. The two objectives were maximizing total revenue and a second revenue-related goal, both aimed at rebooting cash flow to support emergency care. The decision moves from a heuristic ('reopen what feels safe') to an evidence-based one because the schedule is produced by a solver that respects capacity, tests, and forecasted demand. The source does not report the results, so the adoption test is whether administrators schedule reopenings from the model's output instead of from judgment alone.

• If the decision owner cannot restate the decision variables, constraints, and objective in plain language, then stop and fix the problem statement before formulating or coding anything.
• If the model needs a relationship such as price to demand, then build and validate the predictive model first; do not hard-code an assumed equation into a recommendation you want adopted.
• If the solver cannot prove global optimality in reasonable time, then present the best feasible solution alongside the current practice and quantify the improvement over the status quo.
• If stakeholders hold competing goals, then formulate as multicriteria with explicit objectives rather than blending them into one hidden weighted number.
• If the organization has no process or owner for acting on recommendations, then treat the work as descriptive or predictive and do not claim a prescriptive result until the adoption path exists.

• Building the model without a named decision owner. Tell: the output is admired in a demo but nobody changes a schedule, price, or allocation afterward.
• Omitting real-world constraints so the optimum is infeasible in practice. Tell: users say 'we can't do that' and revert to their heuristic.
• Treating an assumed predictive input as fact, such as the simplified demand = 100 − 0.2*Price. Tell: recommended values collapse when compared to observed outcomes.
• Holding out for a provably optimal solution on a complex problem. Tell: the project stalls on run time while a feasible solution that beats the status quo goes unused.
• Treating analytics as descriptive reporting only. Tell: dashboards explain what happened and why, but no decision variable, constraint, or objective is ever defined.

• ▸Decision statement: write 'I need to decide…' in one sentence.
• ▸Decision owner and cadence: who acts on the output and how often.
• ▸Decision variables: list the controllable actions and the person who controls each.
• ▸Constraints: list each rule or limit (capacity, budget, non-negative margin, cap on tests) and its owner.
• ▸Objective(s): state each KPI goal as maximize or minimize; flag if more than one.
• ▸Predictive inputs needed: list forecasts or relationships (e.g., price to demand) and their validation status.
• ▸Current heuristic baseline: describe how the decision is made today and its KPI result.
• ▸Model recommendation vs. baseline: record the KPI gap, and whether the solution is optimal or feasible.
• ▸Adoption trigger and override log: define what action follows the output and record reasons for any override.