Test the change before you commit to it.
Build a model of how your operation behaves, then try the decision in the model instead of in the business.
Useful when the change is expensive, hard to reverse, and everyone is arguing from intuition.
Illustrative system example · fictional product and data · not client work
Scenario plannerVANTAGE · illustrative system, fictional data
You may need this when
Some of this probably sounds familiar.
- A capacity decision is being argued from opinion rather than evidence.
- You cannot pilot the change without disrupting live operations.
- The last change had a knock-on effect nobody predicted.
- You need to know what breaks first as demand grows.
- A business case rests on assumptions no one has tested.
What we could build
A model you can ask questions of.
Not a forecast of one future — a way to see how the system responds when something moves.
- Capacity modelWhere the operation saturates, and what breaks first.
- Process simulationQueues, handovers and bottlenecks under realistic load.
- Scenario comparisonTwo or three real options tested on the same basis.
- Sensitivity analysisWhich assumptions actually change the answer.
- Stress testingHow the system behaves at the edges, not just the average.
- Decision modelA structured way to compare options against your criteria.
See an example
Change one assumption. Watch what moves.
Pick a scenario. The point is not the numbers — it is seeing which assumption the whole plan actually depends on.
Every option is shown below. The selector needs JavaScript, so it is not offered here.
OutcomeToday the operation has headroom, and nothing is close to its limit.
OutcomeGrowth breaks the loading bays first — not the fleet everyone assumed was the limit.
OutcomeCutting a shift costs 6 points of on-time delivery, concentrated in one window.
Illustrative interfaces and fictional data. Not client work.
A model earns its place when it shows you the assumption you did not realise the plan was resting on.
What you receive
A model, and what it told you.
- A working model you can re-run as circumstances change
- Scenario results compared on a consistent basis
- The assumptions listed, with the sensitive ones identified
- A written interpretation of what the model does and does not show
- Agreed source code, data and infrastructure handed over according to the project scope and terms
- Handover documentation and any agreed support arrangements
Technical depth
Approach
Discrete-event, agent-based or analytical modelling chosen by the question, rather than a single preferred technique.
Calibration
The model tuned against real historical data and shown to reproduce known outcomes before it is used to predict new ones.
Assumptions
Every input documented with its source, so a disputed number can be changed and the model re-run.
Sensitivity
Inputs varied systematically to identify which ones actually move the outcome.
Validity
The conditions under which the model stops being reliable stated explicitly.
Reuse
Built so your team can run further scenarios without commissioning new work each time.
Often combined with
What usually sits next to this.
- Forecasting & predictive modelling →When you need what is likely, not just what is possible.
- Data & analytics →When the model needs reliable historical data to calibrate against.
- Analysis & research →When the decision also needs evidence weighed and written up.
Tell us the change you are nervous about.
Describe what you are considering and what would go wrong if it were mistimed.