Back to Modern OR Practice
MethodApplied06.10
Modern OR Practice

OR Communication & Change

Get models trusted, adopted, and improved.

Overview

OR Communication & Change focuses on get models trusted, adopted, and improved. In the map of OR, it connects Stakeholder analysis, Decision narratives, Pilots to decisions that must be modeled, solved, explained, and revised as evidence changes.

Great OR work includes stakeholder framing, explainable recommendations, experiments, rollout plans, training, and feedback loops. The practical use case is clearest in Consulting, Enterprise analytics, Public programs, Operations teams, where the method helps turn constraints and tradeoffs into a decision artifact someone can inspect.

Core ideas

Stakeholder analysis

Stakeholder analysis is a core checkpoint for OR Communication & Change: define it concretely, attach units or rules where possible, and test whether stakeholders interpret it the same way.

Decision narratives

Decision narratives is a core checkpoint for OR Communication & Change: define it concretely, attach units or rules where possible, and test whether stakeholders interpret it the same way.

Pilots

Pilots is a core checkpoint for OR Communication & Change: define it concretely, attach units or rules where possible, and test whether stakeholders interpret it the same way.

A/B tests

A/B tests is a core checkpoint for OR Communication & Change: define it concretely, attach units or rules where possible, and test whether stakeholders interpret it the same way.

Adoption

Adoption is a core checkpoint for OR Communication & Change: define it concretely, attach units or rules where possible, and test whether stakeholders interpret it the same way.

How to use it

  1. 1Start with Consulting: write the decision, time horizon, actors, and objective in operational language.
  2. 2Translate the problem into Stakeholder analysis, Decision narratives, and Pilots; define units and data sources for each one.
  3. 3Build a small instance of OR Communication & Change that can be solved or simulated by hand inspection before using full production data.
  4. 4Compare the recommendation against a baseline policy, not just against mathematical optimality.
  5. 5Document assumptions, sensitivity results, and the conditions under which the recommendation should be revisited.

Applications

ConsultingEnterprise analyticsPublic programsOperations teams
  • Consulting: compare feasible policies, quantify the operating tradeoffs, and make the assumptions behind the recommendation visible.
  • Enterprise analytics: compare feasible policies, quantify the operating tradeoffs, and make the assumptions behind the recommendation visible.
  • Public programs: compare feasible policies, quantify the operating tradeoffs, and make the assumptions behind the recommendation visible.
  • Operations teams: compare feasible policies, quantify the operating tradeoffs, and make the assumptions behind the recommendation visible.

Common pitfalls

  • Applying OR Communication & Change because the label sounds appropriate while leaving the actual decision boundary vague.
  • Treating Stakeholder analysis as a technical detail instead of a modeling choice that affects the recommendation.
  • Reporting one answer without showing sensitivity to demand, capacity, costs, or behavioral assumptions.
  • Ignoring implementation details such as data quality, explainability, ownership, and how users will override bad recommendations.

Resources