Author
Samuel Low
Certified Master Anaplanner and Senior Associate
Topic
Connected Planning
Share
Connect With an Expert
By Samuel Low
Certified Master Anaplanner and Senior Associate
Teams change. People move on. And when the person who built your planning model leaves, the institutional knowledge often goes with them.
New model builders may spend weeks navigating a structure nobody documented. End users submit support tickets for questions the previous admin could answer in 30 seconds. A tool that should accelerate planning decisions starts to feel like a liability.
This is not a technology problem. It is a continuity problem. And it is more common than most organizations want to admit.
When we asked webinar attendees how long it typically takes a new user to feel confident inside an existing Anaplan model, the most common answer was more than three months.
Three months. In a budget cycle environment where decisions depend on current, accessible data, that is a significant gap.
The good news is that most of what creates that gap is fixable. It does not require rebuilding your model or starting over. It requires building more intentionally from the start and recovering structure if you are already behind.
The Real Cost of Key Person Dependency
Most Anaplan environments have at least one person who knows the model deeply. They understand why certain calculations are structured the way they are. They know which module handles what. They can answer questions without looking anything up.
That person is also the single point of failure for planning continuity.
When they leave, take parental leave, or move to a new role, the organization discovers just how much lived knowledge was never captured. The model works, but nobody can explain why. Enhancements stall. New builders hesitate to touch anything they do not fully understand.
The challenge is not unique to Anaplan. But planning environments are particularly susceptible because so much of the logic is embedded in a structure that is not self-explanatory to anyone who did not build it.
Standardization: The Foundation Before Everything Else
Before documentation, before training, and before any structured onboarding process, there is standardization. Consistent naming conventions and logical model organization reduce the cognitive load for anyone navigating a model they did not build.
A few principles can make a meaningful difference:
- Name modules consistently and uniquely. A prefix like SYS01 for systems modules or CALC02 for calculation modules gives new builders immediate orientation.
- Use the DISCO framework as your organizing structure. Data, Input, System, Calculation, Output. When model navigation reflects this flow, anyone trained in Anaplan fundamentals can orient quickly because the structure matches what they already know.
- Build once, reference many. Mappings and calculations that appear in multiple modules should live in a single systems module. New builders looking for a cost center or account mapping should have one place to look, not twenty.
- Use separators to create visual structure. Separator modules have no data and do not add to model size. But for someone navigating a list of 80 modules, the ability to see groupings at a glance can cut orientation time significantly.
- Maintain a model standards document. Naming conventions, module prefixes, action naming, and list conventions should be captured somewhere accessible. Even a one-page reference document gives new builders something to align to rather than forcing them to reverse-engineer standards from the existing structure.
None of these steps are technically complex. They require discipline and consistency, especially when multiple builders are working in the same model over time.
Documentation: The Part Everyone Skips
Documentation is the piece most teams acknowledge matters but consistently deprioritize. When a build is underway, documentation feels like overhead. After a build is complete, it feels retrospective. The result is that most models operate without it.
The impact of that gap becomes visible the first time someone new needs to understand how the model works.
Three types of documentation are worth investing in:
Model schema
A model schema is a flowchart that shows how data moves through the model. Where does it enter? What transforms it? Where does it go? Model builders and architects who have had Anaplan training know how to read one. Having a current schema on hand gives any new technical resource a navigational map before they open a single module.
Model flow summary
A model flow summary is a higher-level user journey document. It is not the technical architecture, but the UX flow. If I am a planner entering workforce budgets for the first time, which pages do I use and in what order? This document is for end users, not builders. It reduces the support burden and makes onboarding faster for the people who need the tool to do their jobs.
Job aids and step-by-step guides
These are specific, task-level documents. How do I add a new position? How do I run a forecast update? The best job aids are short, task-specific, and easy to find. These are the documents that reduce the number of questions directed at whoever happens to know the model best.
One practical addition worth noting: AI-powered documentation tools are now available that can record a screen walkthrough and automatically generate transcriptions and screenshots. Running through a model process with one of these tools in the background creates documentation in a fraction of the time it takes to write it from scratch.
Tracking Changes So the Model Has a History
One of the most overlooked sources of confusion for new builders is discovering that the model does not match what the design documents describe. Features changed to mid-build. Logic was adjusted. Something was removed because requirements shifted.
Without a record of what changed and why, a new builder cannot distinguish between intentional design and unresolved debt.
A simple change and enhancement tracker, whether in Jira, Smartsheet, a shared spreadsheet, or a module built in Anaplan itself, gives the model a history. When a new architect comes in and sees that the configuration changed six months ago, with a note explaining why, that single record can save hours of investigation.
Revision tags are part of this. Naming revision tags consistently, with a reference ID and a brief description of what changed, turns version history into a readable log rather than a series of timestamps with no context.
A few areas are worth specifically covering in training:
- End user workflows for the most common planning tasks
- Model builder orientation for new technical resources joining the team
- ALM, or Application Lifecycle Management, processes: how changes move from development to production, when to use a test environment, and what the process looks like when something breaks in a live model
- Copy and archive procedures: archiving a model before a revision tag is pushed is a backstop that costs nothing and has saved more than a few teams from a difficult situation
When You Are Starting from an Existing Model with No Documentation
Not every team has the option to build documentation from the beginning. Many organizations inherit a model that has been running for years, built by someone who is no longer there.
The orientation approach for this situation is practical: start at the UX pages and work backward.
UX pages show what users see and reference. The modules behind those pages are the ones that matter most for day-to-day operations. Starting there, then drilling backward through the DISCO flow from output to data gives a new builder a structured way to map the model instead of navigating blindly.
Pay particular attention to excessively large modules. Understanding why a module is large, and whether it needs to be, is often the fastest way to understand where complexity lives.
If the model is complex enough that creating a retroactive schema feels overwhelming, that complexity itself may be the problem. Cleaning up unused lists, consolidating duplicate mappings, and standardizing naming conventions will not only improve documentation. It will make the model faster and easier for everyone who works in it.
If the model is too complex to document, it may be too complex to maintain. Simplification is not just a documentation strategy. It is a planning sustainability strategy.
Building Adoption When Not Everyone Is Enthusiastic
Documentation and training solve part of the adoption challenge. They do not solve all of it.
Some users are not excited to move to a new tool. The transition from spreadsheets they understand to a platform they do not yet trust is genuinely uncomfortable. Acknowledging that discomfort, rather than dismissing it, goes a long way.
Super users and power users play a meaningful role here. When a planner in the budget office sees that their peer on the other side of campus uses the tool confidently, that peer becomes a more credible advocate than any training session or job aid. Building a small group of capable, visible advocates early in an implementation accelerates adoption in a way formal training alone cannot.
A shared support channel, whether an email alias monitored by a Center of Excellence or a dedicated Slack channel, gives new users a place to ask questions without feeling like they are interrupting someone. The faster questions get answered, the shorter the window of frustration that drives people back to old habits.
The Role of AI in Model Continuity
Anaplan’s AI capabilities are beginning to address some of the model navigation and explanation challenges that have historically required a knowledgeable human to solve.
An AI agent that answers natural language questions about how to use the model, for example, how to add a new position to a roster or where to enter forecast adjustments, has real potential to reduce the burden on super users and support staff. For new users who feel uncertain about where to start, having an on-demand resource that can answer their specific question without requiring a live call is meaningful.
This is an area that will continue to develop. The practical frameworks described above, including standardization, documentation, and training, remain foundational. AI tools will augment them, but they do not replace the value of a model that is clean, well-organized, and supported by current documentation.
Where Does Your Model Stand?
The planning tools your team relies on are only as effective as the team’s ability to use them confidently. When institutional knowledge lives in one person’s head, every personnel change becomes a continuity risk.
The question worth asking is not whether your model is working today. It is whether someone new could step in tomorrow and understand it well enough to keep it working.
If the honest answer is uncertain, it is worth addressing before the next team change forces the issue.
About Tru Consulting
Tru Consulting is a strategic planning modernization partner focused exclusively on higher education, academic medical centers, and public sector organizations. Our team helps institutions build connected planning environments that improve visibility, reduce manual effort, and support better decisions. This post is adapted from a Tru workshop session led by Samuel Low, Certified Master Anaplanner and Senior Associate, and John Merriman, Managing Partner.
You can watch the webinar on demand below:
