Choosing an Anaplan integrator means comparing proposals that do not always describe the same scope. A brand, partner status and project count provide useful context. You also need to know who will build your model, on which assumptions and with what handover.
We recommend a common framework for candidates, supported by evidence you can verify. A precise answer about data, staffing or error recovery is more useful than a general promise of methodology.
Understand badges without expecting them to prove everything
Anaplan’s PartnerAccelerate programme recognises functional and industry specialisations through requirements and verification. Those badges are a relevant signal for your use case. They do not, by themselves, describe the team assigned to your engagement.
Individual certifications describe a different level: a person’s skills. Anaplan identifies Certified Master Anaplanner as its highest technical certification level. Ask which people will own design, construction and validation, and verify their current qualifications.
If a proposal uses an older designation such as Gold or Platinum, ask which period and programme it refers to. Avoid directly comparing a historical tier with a current specialisation badge. An independent firm should also demonstrate relevant experience, available capacity and continuity of service.
Compare candidates using a common framework
| Criterion | Question | Evidence to request |
|---|---|---|
| Assigned team | Who designs, builds and remains available? | Names, roles, qualifications, availability and replacement process. |
| Scope | Which complete cycle will be usable at first go-live? | Inputs, outputs, users, acceptance criteria and exclusions. |
| Data | Which assumptions determine the budget and schedule? | Sources, owners, checks and preparation work. |
| Relevant experience | Which project had comparable constraints? | Actual responsibilities, decisions, limitations and a verifiable reference where possible. |
| Project economics | What could change the quotation? | Assumptions, dependencies, change control and post-delivery costs. |
| Handover | What will your team be able to do independently? | Agreed documentation, training, access, operations and support. |
For each row, record the answer, its evidence and open questions. Set your priorities before sales presentations. An unmet essential constraint deserves explicit treatment, even when a candidate performs well elsewhere.
Observe the reasoning on a representative problem
A scoping workshop on a limited example lets you see how a team clarifies the process, granularity and exceptions. Define a proportionate exercise, usable data and the same expectations for each candidate. The aim is to understand proposed decisions; a quick demonstration alone does not establish the quality of a future production model.
Ask what the team would leave out of the first release, why and with what consequences. The answer should connect to the first go-live definition and budget breakdown.
Check a reference and plan the handover
A reference is useful when it explains the problem, delivered scope, team responsibilities and conditions behind the result. A logo alone cannot do that. An anonymised case can provide substance when its details are confirmed and its limitations are clear.
Before deciding, describe the expected state after delivery: documentation, permissions, training, maintenance routines and named contacts. Include these in the agreed commitments with the same care as the build scope.
Polygon’s Anaplan practice can discuss your scoping decisions or proposed scope. If work has already started, signs of project drift provide another starting point.
