Four signs an Anaplan project is drifting

Anaplan projects rarely fail loudly. They drift, and the symptoms are visible months before anyone says the word.
Four colleagues in business dress discussing around a meeting table

By the time a client calls us about a model in trouble, the drift has usually been visible for two quarters. Nobody ignored it - it just never crossed the threshold where someone had to act. These are the four signals we see most often, and each has a cheap fix early and an expensive one late.

1. Only one person can change the model

Ask who can safely add a line item to the core module. If the answer is one name - internal or from your integrator - you do not have a planning platform, you have a dependency. This is the highest-severity signal because it compounds: the single owner becomes too busy to document, which makes them more indispensable. The early fix is a second builder trained on the real model. The late fix is reverse-engineering a system whose author has left.

2. The cycle still ends in Excel

Watch what happens after the planning meeting. If the numbers are exported, adjusted offline and mailed round, the platform is a data store, not a planning system. Usually one specific thing is missing - a view, a permission, a calculation the model cannot do - and the workaround has quietly become the process. Find the missing capability and build it. If nobody can name it, that is its own finding: the model was built for a process that does not exist.

3. Scope grows while nothing goes live

Modules multiply, the go-live moves, and each new requirement is genuinely reasonable. This is the most socially difficult signal because everyone is behaving well. The discipline that fixes it is unpopular and simple: pick one planning cycle, put it in production with its real users, and refuse everything else until it runs. A cycle live and trusted changes the conversation more than four modules in UAT.

4. Performance excuses become permanent

"It is slow at month-end" starts as an observation and becomes an accepted property of the system. Users adapt by planning around it - running fewer scenarios, avoiding refreshes - which means the model shapes the process instead of serving it. Slowness is a design outcome: sparsity, dimension order, calculation shape. It is diagnosable and usually fixable in place, but only while people still complain about it. Once they stop, you have lost the signal.

Where to start

Pick the signal you recognise and test it this week - ask who can change the model, or sit in on the next cycle and see where the numbers actually go. Most of these are recoverable without a rebuild if they are caught while the original team is still reachable. Our Anaplan practice does this as a two to three day assessment ending in a written diagnosis, and you keep the document whether or not you continue with us.

Continue reading