How we build planning models that flex with the business
In a well-built model, a structural change takes an afternoon, not a quarter. That outcome isn't luck. It's the result of a handful of decisions made early in the build, most of them invisible to whoever signs the scope.
The biggest indication of a model's flexibility is
A good model absorbs the change and keeps producing numbers people trust. Nobody opens Excel to bridge the gap while it's getting fixed. A rigid one turns the same change into a project (scoping, rebuild, revalidation), and by the time it ships, the business has moved again. The difference between those two models isn't the platform. It's what happened in the first few weeks of the build.
Five decisions that decide
whether a model bends or breaks
None of these are exotic. They're the things a senior practitioner does without thinking and a junior consultant skips because the spec didn't call for it. Each one comes back the first time the business moves.
Build for the business that's moving, not the one on the kickoff slide.
The one technical decision that most determines whether a model flexes.
Design feeds to fail loudly. Silent failures are the ones that kill trust.
Change the logic layer when the business shifts. The rest holds.
Run a change that hasn't happened yet. Find the seams while we're in the room.
Our models flex because of what a senior practitioner decides early, not because of a smarter platform or a new AI feature.
Scope for how fast the business moves, not for the snapshot
Most implementations get scoped from a description of how planning works today. That's the trap. The model gets built for a business that exists in the kickoff slide, then ships into a business that's already moving.
We scope differently. Before we structure anything, we ask what's changed in the last eighteen months and what's forecasted for the next eighteen. We ask the operational version of that question, not the strategy one. Have you added a sales motion, restructured the org, picked up a new revenue line, moved into a new region, changed how comp works? The pattern of those changes is what the model has to live with. If your business reshapes itself twice a year, we build for a model that gets reshaped twice a year. If you're stable, we build differently.
We were brought in to rebuild an underperforming Anaplan model. The scope said rebuild, not redesign. The previous firm had built it, the client wanted it cleaned up, and the brief was clear. But one of the first things we did in scoping was ask what had changed in the business over the previous eighteen months, and what was expected in the next.
The model had revenue accounts as their own list and product categories as a parallel list. About ninety percent of categories mapped to exactly one account, so it looked clean. When we asked whether that ratio was likely to hold, and whether the number of revenue accounts was stable, the answer was uncertain. That was the signal.
We went back and told the client the rebuild needed to change the underlying architecture. Revenue accounts should become attributes of the categories, not a separate list living beside them. The scope widened. If we'd built the original brief, we'd have shipped a cleaner version of a model with the same structural problem inside it. The scoping question is what caught it.
The dimensions decide everything. Build them with room to grow.
The single technical decision that decides whether a model flexes is how the dimensions get structured. Dimensions are the model's vocabulary: cost centers, products, regions, channels, segments, customer types, comp plans. When the business adds a new one, a well-built model treats it as an addition. A badly built model treats it as a rebuild, because the dimension was sized to today and the logic was written assuming today's list was the whole list.
We build dimensions with explicit headroom. Hierarchies that absorb new branches without rewriting parents. Lists that allow additions without breaking the calculations that read them. Mapping tables that route a new entity to the right home automatically.
It's the kind of thing a senior practitioner does without thinking, and a junior consultant skips because the spec didn't call for it.
That decision to make revenue accounts attributes of categories, rather than separate lists, came back a year later. Our client decided to quadruple their number of revenue accounts.
In the original model, cleaned up or not, that change would have hit a wall. Workspace limits, performance problems, or both. In the rebuilt model, they remapped the product categories to the new account attributes in a few hours. The go-to-market restructure they wanted didn't require a model rebuild.
Trust in a model lives or dies at the integration layer
That's where the numbers come from. If the source is wrong, the pipe is broken, or the data is stale and nobody knows, every calculation downstream is now poisoned. Trust erodes. And once trust is gone, your team is back in Excel and not coming out. Many implementations treat integrations as plumbing. We treat them as part of the foundation.
We design integrations to fail loudly. If a feed is late, the model says so. If a record count drops thirty percent from yesterday, the model says so. If a field changed shape upstream, the model catches it. Silent failures are the ones that kill trust, because the number looks fine until somebody catches it three weeks later. By then half the report has been rebuilt in Excel.
We also map each integration to a named owner on the client side. A stakeholder, not the IT department. Integrations break. When they do, the question isn't whether somebody fixes it, it's how fast.
The difference between two hours and two weeks is whether the team still trusts the system in six months.
A commissions model we built ran an integration over the weekend. No errors. No alerts. Technically successful. But the run had imported zero records.
The weekend batch should have pulled in new deals and new invoices. Zero meant something had broken upstream, in the source data, before the pipeline ever ran. We'd built a threshold check into the integration layer: a technically successful run with zero records still trips it. The system sent notifications automatically, to our team and to the stakeholders who owned the process, before the business day started.
By the time sellers logged in Monday morning, it was already resolved. The system didn't just catch the failure. It caught it early enough that it never became a problem.
Keep inputs, logic, and outputs as separate things
The other technical decision that decides whether a model flexes is whether the three layers are clean. A lot of inherited models tangle them. Logic embedded in input forms. Output reports that recalculate from raw data instead of from the model's actual numbers. Assumptions hardcoded into formulas the team forgot were there. When change comes, nobody can tell what touches what, so changes get made everywhere. The model turns brittle.
We build the layers as separate things. Inputs are inputs. Logic sits in one place and gets changed in one place. Outputs read from the logic, not from the inputs. When the business shifts, we touch the logic layer and the rest holds. When leadership wants a new view, we add to the output layer without going near the spine.
This is the kind of decision that doesn't show up in a sales deck. But it shows up in every quarter after go-live.
Before go-live, we run a change that hasn't happened yet
The last thing we do, every time, is run the model against a change that hasn't happened yet. Before handoff, we sit with the finance lead and pick the most disruptive plausible change in the next twelve months: a new product, a new segment, a carve nobody's announced. Then we run it through the model, not just as a thought experiment.
The point isn't to predict the future. It's to find the seams while we're still in the room. Anything that takes more than an afternoon to absorb is something we restructure before we leave. That exercise is also where the team learns the model. They watch a real change get made in the system by a senior practitioner. By the time we're gone, they've seen it done. The only kind of training that truly transfers.
Before we handed over a territory and quota model, we ran a scenario the client hadn't asked us to run. During the implementation, we'd picked up that the company was in early talks to acquire a global business. Nothing was signed. But if the deal closed, their territory carving strategy would have changed entirely.
Existing territories were carved by geography and account segment. A global acquisition meant new segment types, new hierarchies, new carving logic that had to sit alongside what was already there. The model wasn't built for it. We found the gap before handoff and restructured how segments could be added and remapped without touching the core carving logic.
Six months later, the acquisition closed. The global territories and segments came into the model cleanly, with their own carving approach running alongside the existing one. The change took days, not months. A scenario we weren't sure would ever happen actually happened. And the model was ready for it.
The flexibility isn't only in the platform.
It's in the decisions: the five in the grid above. Our models flex not because they're built on a different platform or a smarter AI feature, but because of the calls a senior practitioner makes early, most of them invisible until the business moves.
If your current model isn't flexing, we can usually tell what's wrong inside a working session. Most of the time, the fix is smaller than the rebuild you're bracing for.