What 'driver-based planning' actually means

"Driver-based planning" is one of those FP&A buzzwords that sounds like a software feature and is actually a worldview. It's also poorly explained, mostly because the people selling it have a financial interest in keeping it vague.

Here's the plain-English version.

A traditional plan

You sit down once a year. You build a budget. The budget is a big spreadsheet with revenue assumptions, headcount assumptions, and expense assumptions. Each cell is a number you typed.

Three months later, the CEO says "we're hiring 5 more engineers in Q3." You sigh. You go to the headcount tab. You add 5 rows. You go to the salary tab. You add 5 rows. You go to the SaaS tab — because each engineer needs a Github seat. You add 5 rows. You go to the revenue tab — because those engineers are shipping a product that should ship Q4. You don't know how to model that. You guess.

This is *the rebuild*. A normal mid-cycle change takes 4–8 hours.

A driver-based plan

You sit down once a year. You build a model. The model has drivers (HEADCOUNT_ENG, NEW_FEATURES_QUARTER, ACV_MID_MARKET) and member formulas that connect drivers to financial outcomes:

• SALARIES_ENG = HEADCOUNT_ENG × -10000
• GITHUB_SEATS = HEADCOUNT_ENG × -25
• REVENUE_NEW_PRODUCT = NEW_FEATURES_SHIPPED_Q4 × ACV_MID_MARKET × 12

Three months later, the CEO says "we're hiring 5 more engineers in Q3." You change one number — HEADCOUNT_ENG from 12 to 17 — and the entire plan recomputes. Salaries update. Github cost updates. The cascading effect on EBITDA shows up in 2 seconds.

This is the worldview difference. Drivers + formulas = the plan recomputes itself.

Why most FP&A teams don't use this

Three reasons:

1. Excel doesn't really support it. You can do it with named ranges and INDIRECT() — but the model becomes fragile and impossible to audit.
2. Anaplan supports it brilliantly. And costs $150k/year and takes 6 months to implement, so 95% of mid-market companies can't get there.
3. Setting up the drivers feels like a tax. It's 2–3x the work of a static plan up front. The payoff comes when the third mid-cycle change request lands.

When the math flips

Track this for one fiscal year:

• Time spent setting up the original budget
• Number of mid-cycle change requests (CEO, board, ops)
• Time spent rebuilding for each request

If you have 3 or more mid-cycle change requests per quarter, driver-based planning pays for itself within the first cycle. Most growth-stage companies do.

What to model first

Don't try to convert your entire plan to drivers in one go. Start with:

• Headcount, because it's both the biggest driver and the most-changed assumption
• Variable cost per employee (laptops, SaaS seats, recruiter fees, etc)
• Revenue per [unit] for whatever your unit is (deal, customer, transaction)

The other 80% of the plan can stay static. Driver-based 30% of your model gets you 80% of the benefit.

The next step

Want to see what a driver formula actually looks like in practice? The live demo has a working example — type a formula, watch the headcount step up, watch salaries auto-recompute.

Or if you'd rather build it on your own data: book a 15-minute walkthrough. We'll set up your first three drivers in real time.