Steven Barry is a Certified Master Anaplanner and Connected Planning Sales Lead at Kearney.
This is the first article in a two-part series on using a decision contract to improve Anaplan solution design. Part 1 introduces the concept and explains how it can help teams clarify the business outcome before they begin building. Part 2 focuses on translating the contract into model architecture, workflow, user experience, and success measures.
One of the easiest mistakes to make during an Anaplan implementation is to begin with the current process and assume the goal is to reproduce it. The team maps the spreadsheets, documents every handoff, rebuilds the existing approval chain, and creates a page for each person involved.
The result may be technically sound, but it may also leave the business with the same slow and complicated planning process, only in a better tool.
Anaplan creates more value when it is used to improve how decisions are made. That requires a different starting point. Before defining modules, pages, workflows, integrations, or user stories, the project team should define the decision the process is expected to produce.
I refer to this as the decision contract.
What is a decision contract?
A decision contract is a simple design framework that establishes what decision must be made, who owns it, what information is required, and what happens after the decision is made.
It is not intended to add another layer of project documentation. In most cases, it should fit on a single page. Its purpose is to create enough clarity that the business process and the Anaplan solution can be designed around the same outcome.
A complete decision contract should answer six questions.
- What decision is being made?
This should describe an actual business decision, not an activity. “Submit the forecast” is an activity. “Commit to the regional revenue outlook for the quarter” is a decision. “Enter hiring requests” is an activity. “Authorize the positions that the business can afford and recruit” is a decision.
The distinction matters because activities can be completed without creating business value. Decisions create commitments, establish priorities, and change what the organization does next. - Who owns the decision?
Many planning processes involve several contributors, reviewers, and subject matter experts. That does not mean they all own the final decision.
The decision contract should identify one accountable owner or a clearly defined decision-making group. Contributors can provide information and recommendations, but accountability should not become unclear simply because the process is collaborative.
When ownership is not defined, the Anaplan design often compensates with additional approval steps. This makes the process longer without necessarily making the decision better. - When must the decision be made?
A due date is useful, but it is not always enough. The contract should also identify the event or business signal that triggers the decision.
A demand forecast may be reviewed on a monthly schedule. A hiring decision may be triggered when a position becomes vacant. A sales forecast may require an additional review when a material opportunity slips. A supply decision may be triggered when projected inventory falls below an agreed threshold.
Defining the trigger helps separate decisions that belong in a recurring planning cycle from decisions that should be managed by exception. - What evidence is required?
The decision owner should have enough information to make a responsible decision, but more information is not always better.
The contract should identify the minimum evidence required. This may include a system-calculated baseline, historical performance, assumptions, known risks, operational constraints, or recommendations from other teams.
This is where Anaplan can provide significant value. The platform can bring the relevant information together at the point of decision instead of requiring users to assemble it through spreadsheets, emails, and offline conversations. - What guardrails apply?
Guardrails define the boundaries within which a decision can be made without further escalation.
They may include financial tolerances, approval limits, capacity constraints, service-level expectations, risk thresholds, or requirements for additional commentary. They should be specific enough to guide behavior without forcing every decision through the same review path.
A good guardrail allows the majority of routine decisions to move quickly while ensuring that material or unusual decisions receive the appropriate attention. - What changes after the decision is made?
This may be the most important question in the contract.
A decision should create a clear downstream commitment. An approved forecast may become the baseline used by Finance. An authorized position may flow into recruiting and workforce cost projections. An approved demand override may change production, procurement, and inventory requirements.
If nothing changes after a decision is made, the process may be collecting information rather than managing the business.
Applying the decision contract to sales forecasting
Consider a common sales forecasting process.
Every seller updates every opportunity. Sales managers review each submission. Regional leaders adjust the total. Finance compares the result to the target. The process concludes with an executive forecast call.
It is tempting to reproduce this entire sequence in Anaplan. Each role receives an input or review page. Status fields are added. Approval actions are configured. Management reporting is built around submission completion.
The process may become more controlled, but the core business decision can still remain unclear.
The actual decision is not whether every opportunity was updated. The decision is whether the organization is prepared to commit to a revenue outlook and act on the resulting risks and opportunities.
A decision contract for the regional forecast could establish that the regional leader owns the committed outlook by the fifth business day of the month. The required evidence could include open pipeline, renewals, historical conversion, seller overrides, and identified risks. Forecast changes outside an agreed tolerance could require an explanation. Only material exceptions would escalate to the next level. Once approved, the forecast would become the baseline consumed by Finance, workforce planning, and delivery capacity planning.
That contract leads to a different Anaplan design.
The platform can calculate an initial forecast using the available pipeline and historical assumptions. Sellers can focus on opportunities where their judgment is likely to improve the result. Managers can review material overrides instead of every record. Regional leaders can see the forecast, the gap to target, the largest risks, and the actions available to address the gap in one place.
The process becomes less focused on collecting updates and more focused on making a defensible decision.
Conclusion
A well-built Anaplan model can make an existing process faster, more controlled, and easier to maintain. That is valuable, but it should not be the limit of the ambition.
The greater opportunity is to improve how the organization makes decisions. The decision contract provides a practical way to align the business and implementation team on that outcome before development begins.
Part 2 of this series covers how to translate the decision contract into Anaplan design choices, including dimensionality, system-generated baselines, exception-based workflow, decision rationale, connected impacts, and outcome measurement.
