Driver-Based Planning: Forecasts Built on Levers, Not Hope

A planning model is rebuilt around drivers, and the driver tree has ninety-four nodes. It is comprehensive, defensible, and nobody uses it, because filling it requires inputs from fourteen people and half the relationships in it were assumed rather than tested. When a scenario is requested, the team exports the numbers to a spreadsheet and answers the question there. The model describes the business accurately and it cannot be operated, which makes it documentation rather than a planning tool.

A driver model is only useful if someone can move a driver and believe the answer.

Driver-based planning means building plans on a small number of validated drivers that the business can actually influence, with relationships tested rather than assumed and ownership assigned per driver.

The Architecture Layer That Decides If Your AI Product Survives Production

Build the architecture layers that make AI products production-ready.

Download Whitepaper

However, most implementations pursue completeness, producing large models with untested relationships that are too costly to operate and too fragile to trust.

If you are a CFO or VP FP&A, the intent of this article is:

Define why driver count is the critical design constraint
Show how relationships get validated rather than assumed
Lay out what driver ownership requires

To do that, let's start with the basics.

What Is Driver-Based Planning? The Basic Definition

At a high level, driver-based planning expresses financial outcomes as functions of operational drivers: headcount, volume, price, conversion, utilisation. Done well it lets the business ask what happens if a lever moves, and get an answer that follows from a tested relationship. Done poorly it produces a large model where most nodes are assumptions, the input burden exceeds what anyone will sustain, and the answers cannot be trusted because nobody validated the coefficients. The design constraint is therefore the number of drivers, not the fidelity of the representation.

To compare:

A ninety-four node driver tree is a cockpit with every possible instrument and no pilot trained on it. Everything is represented. Nobody can fly it, so they use the window instead.

Why Does Driver-Based Planning Matter?

Issues that it addresses or resolves:

Plans built on line-item growth rates with no causal basis
Scenario questions answered in spreadsheets outside the model
Driver relationships assumed and never tested

Resolved Issues by Driver-Based Planning Done Well

Plans expressed as functions of movable levers
Relationships validated against history
Driver ownership assigned to people who can influence them

Core Components of Driver-Based Planning

Small set of drivers selected for influence and materiality
Relationships validated against actual data
Ownership per driver assigned to an operator
Input burden kept sustainable
Decision linkage so the model answers real questions

Modern Driver-Based Planning Practice

Driver selection by materiality and controllability
Relationship validation with historical fit
Driver ownership in the operating rhythm
Model maintenance cadence
Scenario capability inside the model

These practices make the model usable. Restricting driver count is what keeps the input burden low enough to sustain.

Other Core Issues They Will Solve

Scenarios answered in the model rather than beside it
Assumptions visible and testable
Operators accountable for the drivers they control

In Summary: Driver-based planning works with a small set of validated, owned drivers, and fails when completeness drives the design.

Importance of Driver-Based Planning in 2026

Planning is expected to answer scenario questions quickly. Four reasons explain why this matters now.

1. Large models are not operable.

Input burden across many contributors makes a cycle too slow to sustain.

2. Untested relationships produce untrustworthy answers.

An assumed coefficient gives a precise number with no basis.

3. Unowned drivers do not get maintained.

A driver with no operator becomes a stale input nobody questions.

4. Scenario capability is the point.

If questions get answered in a spreadsheet, the model has failed regardless of its accuracy.

Traditional vs. Modern Driver-Based Planning

Completeness pursued vs. driver count constrained
Relationships assumed vs. validated against history
Drivers unowned vs. owned by operators
Scenarios in spreadsheets vs. scenarios in the model

In summary: A modern approach constrains driver count, validates relationships, and assigns ownership.

Details About the Core Components of Driver-Based Planning: What Are You Designing?

Let's go through each component.

1. Selection Layer

Which drivers.

Selection decisions:

Materiality assessed per candidate
Controllability required
Count deliberately constrained

2. Validation Layer

Do the relationships hold.

Validation decisions:

Historical fit tested
Coefficients estimated rather than assumed
Poor fits rejected or flagged

3. Ownership Layer

Who moves it.

Ownership decisions:

Owner per driver named
Owner able to influence it
Driver in the operating rhythm

4. Burden Layer

Sustainable inputs.

Burden decisions:

Input count per cycle measured
Contributors limited
Defaults for stable drivers

5. Decision Layer

Answering questions.

Decision decisions:

Scenario capability inside the model
Common questions tested
Answers reproducible

Benefits Gained from Driver-Based Planning Done Well

Scenarios answered in the model quickly
Assumptions visible and validated
Drivers owned by people who can move them

How It All Works Together

The finance function selects a small number of drivers on two criteria simultaneously: material effect on outcomes and genuine controllability by someone in the business. A driver that matters but cannot be influenced is context rather than a lever, and a driver that can be influenced but barely moves the outcome adds input burden for nothing. Each retained relationship is validated against historical data with coefficients estimated rather than assumed, and relationships that do not fit are rejected or explicitly flagged as judgement rather than presented as mechanics. Every driver gets a named owner who can actually influence it and who sees it in their operating rhythm. Input burden per cycle is measured and kept low, with stable drivers defaulted rather than re-entered. And scenario capability lives in the model, tested against the questions leadership actually asks.

Common Misconception

A more complete driver model is a better driver model.

Completeness increases input burden, multiplies untested assumptions, and reduces the number of people who can operate the model, all of which make it less likely to be used. A model with eight validated drivers that three people can update in an afternoon will answer more real questions than one with ninety-four nodes that requires fourteen contributors and contains fifty assumed relationships. The purpose is to answer what happens if a lever moves, and that requires a model somebody can run and an answer somebody can believe. Accuracy of representation is worth very little without both.

Key Takeaway: Completeness adds input burden and untested assumptions. Eight validated drivers beat ninety-four assumed ones.

Real-World Driver-Based Planning in Action

Let's take a look at how it operates with a real-world example.

We worked with a finance function whose ninety-four node model went unused, with these constraints:

Constrain the driver count by materiality and controllability
Validate every retained relationship against history
Assign ownership to operators who can move the driver

Step 1: Constrain the Count

Two criteria.

Materiality assessed
Controllability required
Count deliberately limited

Step 2: Validate the Relationships

Test, do not assume.

Historical fit tested
Coefficients estimated
Poor fits rejected or flagged

Step 3: Assign Ownership

To operators.

Owner named per driver
Owner able to influence
Driver in operating rhythm

Step 4: Cut the Input Burden

Sustainability.

Input count measured
Contributors limited
Stable drivers defaulted

Step 5: Test the Questions

Scenarios in the model.

Common questions tested
Answers reproducible
Spreadsheet workarounds eliminated

Where It Works Well

Businesses with identifiable controllable drivers
Relationships with enough history to validate
Functions willing to constrain driver count

Where It Does Not Work Well

Completeness pursued over operability
Relationships assumed without historical fit
Drivers with no owner who can influence them

Key Takeaway: Constrain the count, validate relationships, assign ownership, cut the burden, test the questions.

Common Pitfalls

i) Pursuing completeness

A large model multiplies input burden and untested assumptions, and reduces the number of people who can run it. Constrain the count.

Ninety-four nodes
Fourteen contributors
Scenarios answered in a spreadsheet

ii) Assuming relationships

An assumed coefficient produces a precise answer with no basis, which is worse than an acknowledged judgement. Validate against history or flag it.

iii) Unowned drivers

A driver nobody owns becomes a stale input nobody questions. Assign an owner who can actually influence it.

iv) Ignoring input burden

If a cycle requires inputs from too many people, the model will be bypassed. Measure the burden and cut it.

Takeaway from these lessons: The model exists to answer what happens if a lever moves, and it has to be runnable and believable to do that.

Driver-Based Planning Best Practices: What High-Performing Teams Do Differently

1. Select drivers on materiality and controllability together

Require both, since a driver failing either test adds burden without adding decision value.

2. Validate relationships against history

Estimate coefficients from data and flag anything that is judgement rather than presenting it as mechanics.

3. Assign every driver an owner who can move it

Put drivers into the operating rhythm of the person accountable for them.

4. Measure and constrain input burden per cycle

Keep the model runnable by a small number of people in a short time.

5. Test the model against the questions leadership actually asks

Ensure scenarios are answered inside the model rather than beside it.

Logiciel's value add is helping finance functions build small, validated, owned driver models that answer scenario questions rather than documenting the business.

Takeaway for High-Performing Teams: Constrain the count, validate the maths, assign owners, cut the burden, test real questions.

Signals You Are Doing Driver-Based Planning Well

How do you know it is working? Not by model coverage, but by whether scenarios get answered in the model. These are the signals that separate a planning tool from documentation.

Driver count is small. Selection required materiality and controllability.

Relationships are validated. Coefficients come from data, judgement is flagged.

Drivers are owned. Each has an operator who can move it.

Burden is low. A cycle needs few inputs from few people.

Scenarios run inside. Nobody exports to a spreadsheet to answer questions.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. Driver-based planning depends on, and feeds into, the surrounding finance estate. Ignoring the adjacencies is the most common scoping mistake.

Rolling forecasts depend on driver models to be cheap enough to repeat. Scenario planning consumes the driver structure. Financial forecasting relies on validated relationships. The finance data warehouse supplies driver actuals. Naming these adjacencies upfront keeps the work scoped and helps leadership see driver count as the design constraint.

The common mistake is treating each adjacency as someone else's problem. The driver selection is your problem. The validation is your problem. The input burden is your problem. Pretend otherwise and a comprehensive model will be bypassed for a spreadsheet. Own the adjacencies you depend on, partner with the teams that hold them, and share the driver set.

Conclusion

A driver model earns its place by answering what happens if a lever moves, which requires two properties that completeness works against. Someone has to be able to run it, which means the input burden has to be small enough that a cycle takes hours rather than weeks and involves few contributors. And someone has to believe the answer, which means the relationships have to be validated against history rather than assumed. A large tree of assumed relationships fails both tests and gets bypassed for a spreadsheet. Select few drivers on materiality and controllability, validate every relationship, assign ownership to operators, and test against the questions leadership actually asks.

Key Takeaways:

Completeness increases input burden and multiplies untested assumptions
An assumed coefficient produces a precise number with no basis
A driver nobody can influence is context rather than a lever

Doing driver-based planning well requires constraint. When done correctly, it produces:

Scenarios answered inside the model quickly
Assumptions that are visible and validated

Why Great CTOs Don't Just Build, They Evaluate

Learn how disciplined evaluation separates credible AI systems from hype.