Anaplan implementations fail in predictable ways. We know because rescuing them is a meaningful part of our practice, and the same six causes show up in almost every engagement. This post describes them, the symptoms that tell you which one you have, and the triage approach we use when we are brought in to a project that has gone off the rails.
The six causes
1. No process owner. The project has a sponsor (who approved the budget) and a project manager (who runs the plan) but nobody who owns the business process being modeled and can make decisions about it. Every design question becomes a meeting. Every meeting produces a compromise that models two processes at once.
2. Modeling the spreadsheet. The team rebuilt the existing Excel workbook in Anaplan, tab for tab, including the workarounds that existed only because Excel could not do better. The model is as hard to maintain as the spreadsheet, slower, and nobody can explain why they bought a platform.
3. Wrong level of detail. Planning at SKU-store-day when the business decides at category-region-month, because the data was available at that grain. The model is enormous, the planners are overwhelmed, and the forecast is no better than the aggregate would have been.
4. Integration treated as an afterthought. Data loading was scoped as "two weeks at the end." The model was built against a sample file, the real data arrives with different keys, half-populated hierarchies, and a monthly refresh that takes nine hours. Go-live slips by a quarter.
5. No one can build. The implementation partner built everything, left, and the two people who attended the training have since changed jobs. The model cannot be changed, so the business works around it, and within a year it is a reporting tool that nobody trusts.
6. Scope that keeps moving. Each steering committee adds a requirement, none are removed, and the team is trying to land a model that does everything for everyone by a date that has not moved. Quality collapses first, then the date.
Symptoms
If you are not sure which problem you have, the symptoms usually tell you.
| What you see | Likely cause |
|---|---|
| Design decisions reopened repeatedly; sign-offs that do not stick | No process owner (1) |
| Hundreds of modules; formulas nobody can explain; "that's how the spreadsheet did it" | Modeling the spreadsheet (2) |
| Workspace limits hit; ten-minute recalcs; planners entering thousands of cells | Wrong level of detail (3) |
| Go-live slipping on "data issues"; reconciliations that never tie out | Integration afterthought (4) |
| Change requests queued for months; shadow spreadsheets returning | No one can build (5) |
| Backlog growing faster than velocity; testing compressed; fatigue | Moving scope (6) |
Most troubled projects have two of these. One is usually the root cause and the other is a consequence.
Triage: the first two weeks of a rescue
When we are brought in, we do not start by fixing the model. We start by finding out whether the model should be fixed.
Days 1 to 3: listen. Separate conversations with the sponsor, the process owner (or the gap where one should be), the model builders, and three to five end users. The question is the same for all of them: what decision is this model supposed to improve, and is it doing that?
Days 4 to 7: assess the model. Structure (does it follow a recognizable discipline such as DISCO?), size and density, calculation chains, integration status, security configuration, and whether there is ALM in place. We produce a findings list ranked by impact.
Days 8 to 10: assess the process. Who owns it, what the planning calendar is, and what the model needs to do by the next cycle to be useful. This is where the "wrong level of detail" problem usually becomes undeniable.
Days 11 to 14: recommend. One of three paths:
- Stabilize. The design is sound; the problems are execution (integration, performance, missing skills). Fix in place, typically six to twelve weeks.
- Restructure. The design is wrong in a specific, bounded way (level of detail, hub architecture, a module layer that should not exist). Rebuild that part, keep the rest. Typically one planning cycle.
- Restart. The model does not serve a decision anyone is making. Stop, fix the process ownership, define the decision, and rebuild small. This is rarer than people fear and more often the right call than they admit.
We give this recommendation in writing, with effort estimates, and we are comfortable being told no.
What a rescue looks like in practice
A stabilize engagement usually runs in three tracks: integration made reliable and scheduled (often the fastest win), performance fixed through summary settings and module restructuring, and a build-capability track that pairs our consultant with your builders so the knowledge stays. A restructure engagement adds a parallel run with reconciliation before cutover. In both, we put a process owner in place on day one, even if that means the sponsor holds the role temporarily.
How to avoid needing one
- Name the process owner before the kickoff, and give them decision rights.
- Define the decision the model improves, in one sentence, and test every requirement against it.
- Plan at the level the business decides at, and disaggregate for execution.
- Start integration in week one with real data, not at the end with a sample.
- Build your own capability from the start: two trained builders, ALM in place, documentation as part of the definition of done.
- Freeze scope per release. Add to the next one.
If you are partway into a project that is not going to land, or you have inherited a model that nobody can change, our Anaplan Project Rescue team does exactly this work. The first two weeks are the triage above; you get a written recommendation whether or not you engage us further. Contact us to start.