Decision-Support Software
Your decision models turned into software: scenarios, simulations, and sensitivities on demand instead of once.
Analysis that lives in a slide deck dies at the next board meeting. We encode decision models, trees, driver models, simulations, as software: assumptions become adjustable inputs, scenarios become buttons, Monte Carlo runs on demand, and every decision leaves a logged trail that makes the next one smarter.
Who this is for
Teams that keep re-making the same class of decision, capital allocation, pricing, deal screening, with fresh spreadsheets each time.
How the work is done
Formalize the model
The implicit decision logic made explicit: drivers, relationships, constraints, and the uncertainty on each input. This step alone usually surfaces disagreements that spreadsheets had papered over.
Engineer the engine
The model implemented as tested, versioned code, deterministic core, Monte Carlo layer for uncertainty, scenario management for the cases you revisit. Model changes are code-reviewed like the business logic they are.
Design the interaction
Interfaces for the way deciders actually work: assumption sliders with sane bounds, tornado-style sensitivity views that show which inputs matter, side-by-side scenario comparison, and one-click export to the memo.
Log and learn
Every run and decision recorded, inputs, outputs, and the choice made. Over time this becomes a calibration dataset: how good are our assumptions, and are our decisions improving? That feedback loop is the product.
How the Decision-Support Software engagement runs
We begin with the decision, use the evidence that can genuinely change it, and make the reasoning reviewable from first input to final handover.
What we need to begin
- The decision the software serves, and how often it is made.
- The existing model, spreadsheet, or heuristic, including the assumptions buried in it.
- Which inputs change, how often, and who is authorized to change them.
- The scenarios the client runs today, and the ones they cannot run but want to.
If an input is unavailable, we state the gap, its effect on confidence, and the agreed workaround. It is never quietly ignored.
Your four-phase engagement map
-
Phase 1
Formalize the model
Make the implicit decision logic explicit: drivers, relationships, constraints, and the uncertainty on each input.
-
Phase 2
Engineer the engine
Implement the model as tested, versioned code: deterministic core, Monte Carlo layer, and scenario management, code-reviewed like business logic.
-
Phase 3
Design the interaction
Assumption sliders with sane bounds, tornado-style sensitivity views, side-by-side scenario comparison, and one-click export to memo.
-
Phase 4
Log and learn
Record every run and decision so the model becomes a calibration dataset over time.
Methods and models we draw on
- Decision modeling (trees, driver models)
- Monte Carlo simulation engines
- Sensitivity analysis (tornado) interfaces
- Scenario management
- Assumption version control
- Decision logging & calibration
Methods are chosen for the problem, not the brochure, expect a subset of these, applied properly, plus whatever the evidence demands.
The decision this enables
Institutional decision quality: the model outlives the analyst, and the assumptions face the scoreboard.