Author: Piotr Weremczuk is a Certified Master Anaplanner and FinSys Application Specialist at EQT.
February 2026 marked my tenth anniversary of logging into Anaplan. A full decade.
When I realized this, I decided it was finally time to write down some of the things I’ve learned about setting up and maintaining complex Anaplan environments — not just the technical tricks, but also sometimes neglected parts: governance, processes, team structure, and mindset.
I very quickly understood that it wouldn’t fit into a single article. There is simply too much to share.
So this first part focuses on the non-technical foundations — the elements that, in my experience, matter far more than any formula or model structure. Part two dives deeper into the technical side.
Anaplan as a strategic decision, not a quick fix
Something I’ve seen repeatedly over the years is organizations purchasing Anaplan to solve one isolated problem. A forecasting pain point here, a budgeting bottleneck there. They look for a robust tool to “replace Excel” in that one area.
And technically, Anaplan can do that.
But what often happens next is always the same: they end up with a powerful, premium platform being used like a very fancy spreadsheet. They never unlock connected planning. They don’t scale their use cases. They get the sportscar… and use it for grocery shopping.
It’s absolutely fine to start small — a trial workspace, a limited number of users — to test a use case and then, before committing long-term, asking themselves a much bigger question:
Are we willing to bet on the platform more broadly? Are we ready to transform the way we plan, operate, and collaborate?
The financial investment is one thing.
The organizational readiness is another.
And in many transformations I’ve witnessed, the second one is actually the harder hurdle.
But here’s the encouraging part:
when organisations do confront this question honestly — and decide to embrace Anaplan not as a tool for a single process but as their connected planning backbone — everything changes. Once they commit to rethinking how they plan, budget, and forecast, the platform’s value multiplies. They stop replacing Excel and start redesigning their planning landscape.
They gain alignment across functions, automation across processes, and insights that were never visible before. In other words, they get a return that goes far beyond solving one problem; they unlock the real promise of the platform.
That step — the decision to truly adopt connected planning — is what separates organizations that simply use Anaplan from those that benefit from it.
The human element: Leadership, vision, and mindset
No complex Anaplan environment can succeed without strong leadership and a team willing to approach planning differently. Governance frameworks, RACI matrices, delivery processes — all of that matters. But none of it works unless someone drives the change with conviction.
Across my projects, the presence (or absence) of a leader with a clear vision has consistently been the single biggest differentiator. When such a leader exists (someone who sees beyond the first model, who understands how connected planning can reshape the organisation), everything moves smoother. Teams are more open to exploring new solutions. Stakeholders align faster. People take ownership.
And the team’s mindset almost always starts with the leadership. When a leader embraces a forward-looking approach, pushes for transformation, and genuinely believes in the potential of connected planning, that mindset naturally radiates outwards. Their drive influences how the team thinks, how they solve problems, and how willing they are to take bold steps in unfamiliar territory. A strong leader doesn’t just set direction, they set tone, energy, and ambition.
Without that kind of leadership, I’ve seen environments drift into chaos: unclear responsibilities, duplicated work, unprioritized backlogs, and teams that don’t fully understand what they’re building or why. The absence of a capable leader — someone who is not only willing to take ownership of the Anaplan journey but also has the soft skills and authority to guide a team — introduces a significant risk right from the start. It becomes far harder to build momentum, align stakeholders, or maintain clarity.
Mindset matters.
But the mindset of the team is rarely independent; it is shaped, encouraged, and amplified by the person leading them. If the team is willing to jump into deep water, solve unfamiliar problems, and embrace new ways of working, the payoff is enormous, not only for them, but for the entire company.
Governance as the first layer of stability
Once leadership and mindset are in place, governance naturally becomes the next foundational block. You start with one strong leader and a motivated team… and very quickly realize that without structure, things get chaotic fast.
I’ve learned that defining roles early is essential. It doesn’t need to be heavy or bureaucratic — in fact, it absolutely shouldn’t be. But there should be clarity:
Who owns the model? Who gathers requirements? Who signs off? Who builds? Who tests? Who maintains?
Most teammates won’t instinctively know where their responsibilities begin and end unless you explicitly tell them.
This doesn’t mean wrapping the project in red tape; it means giving everyone a map so they can walk confidently in the same direction.
The same applies to your delivery flow.
Whether you choose agile, scrum, kanban or structured releases, it matters far less which methodology you select than whether everyone understands how the process works. I’ve seen all frameworks succeed, and all of them fail.
The deciding factor?
Communication.
In teams where stakeholders and business owners were consistently kept in the loop, through stand-ups, status updates, or even simple email checkpoints; everything ran smoother. Issues were spotted early. Surprises were fewer. People trusted each other more.
Sharing knowledge across all relevant parties is hugely underrated. It accelerates almost every phase of the development cycle and reduces disappointment later on.
After the first models: How should you structure your team?
Initial development is only the beginning.
Once the first use cases go live, the real question emerges:
What happens next? How should the team evolve? Should you move toward a Center of Excellence (CoE) model?
Looking back at my ten years in the ecosystem, the answer I keep coming back to is simple:
centralization helps — a lot.
When Anaplan expertise sits within a unified team:
- You can allocate model builders and solution architects more flexibly across projects.
- Knowledge flows naturally. People help each other, share best practices, and reduce dependency risks.
- Platform-wide improvements (new features, optimisation techniques, naming standards) spread much faster.
- The entire environment becomes more coherent and maintainable.
The only real question is team size, and that’s something every organization has to determine for itself.
It depends on use case volume, complexity, company size, delivery expectations, employee seniority, and growth rate.
But here’s a surprising truth:
Most organisations need fewer Anaplanners than they initially think, especially once they embrace the technical accelerators and efficiency principles I’ll describe in Part 2.
The three foundations that matter most
There are countless details that influence whether Anaplan thrives inside a company: processes, integrations, data models, documentation practices, and more.
But after ten years in the ecosystem, three things consistently stand out above everything else:
- Leadership
- Clear accountability
- A centralized, well-structured CoE
If those three foundations are in place, the technical part becomes vastly easier. The platform stops being “just a tool” and becomes a strategic asset; one that evolves with your organization and enables scale rather than restricting it.
In Part 2, I dive into the technical mechanics that make this possible: automation, ALM, integration strategies, and future-proof design. But none of that matters unless the human and organizational foundations are solid.
Check it out here: How to maintain complex Anaplan environments — Part 2: Technical foundations for scale.
Questions? Leave a comment!
