A new planning system does not become useful because the implementation team has configured it correctly. Finance teams adopt it when the system fits the work they need to complete. The model is understandable, and leaders reinforce its use through real budgeting, forecasting, and scenario-review cycles.
EPM change management is the structured work of preparing stakeholders, aligning new planning workflows with finance responsibilities, building confidence through testing and training, and reinforcing usage after go-live. It is not a communications exercise added at the end of an implementation. It is how an organization turns a technically sound system into a planning process people trust and use.
That distinction matters because resistance often reflects a practical concern: unclear ownership, unfamiliar workflows, or uncertainty about whether the numbers can be trusted. Strong Pigment implementation support addresses those concerns while the model is being designed, tested, and introduced.
Start by examining why adoption breaks down even when the technology itself is working.
Why EPM change management fails: it is rarely a technology problem
A planning system can be technically sound and still fail to change how finance works. The more common breakdown is operational: leaders have not agreed on the future workflow. Managers do not understand their role, or contributors do not trust the numbers and assumptions in the model.
That is why epm change management cannot be reduced to a launch email or a few training sessions. Organizational change management is generally described as preparation, implementation, and follow-through, with the goal of helping people adopt and use a change effectively. It also continues after the transition, through outcome assessment, performance tracking, training, and adjustments to the approach.1
Four failure points to address before go-live
Weak sponsorship: The CFO or executive sponsor must make the new planning process the expected way of working. Otherwise, teams may preserve familiar spreadsheets and workarounds.
Workflow mismatch: A model that does not reflect real budget submissions, forecast reviews, scenario discussions, or ownership of assumptions creates extra work instead of removing it.
Low trust: Users need to understand how data moves, how calculations behave, and who owns the inputs. When results cannot be explained, they will validate them elsewhere.
Unresolved readiness concerns: Resistance often signals a practical issue, such as unclear responsibilities, insufficient preparation, or a process that has not been tested with the people expected to use it.
These are leadership and operating-model decisions, not merely configuration tasks. Research on change practice points to the importance of involving senior leaders, managers, and employees, while listening to middle-manager concerns and using feedback to improve the change. Stakeholder input should alter the rollout when it exposes a genuine adoption risk, rather than being collected as a formality.2
Q: Who owns adoption in an EPM implementation?
A: Ownership is shared, but it is not vague. The executive sponsor sets the expectation, finance process owners define how work should be done, managers reinforce the change, and users test whether the workflow works in practice. The implementation team should make risks visible and help coordinate the response.
Q: How can a finance leader tell whether the rollout is ready?
A: Ask whether stakeholders can explain the new process, trust the outputs, complete their responsibilities, and identify where to raise issues. If those answers are uncertain, more configuration alone is unlikely to solve the problem. Address the workflow, sponsorship, readiness, or feedback gap before treating go-live as the finish line.
What change management looks like during a Pigment rollout
Change management is not a communications exercise added after the model is built. It is the operating discipline that helps finance teams understand what is changing, test whether the new process works. And build confidence before they rely on it for budgeting, forecasting, scenario modeling, and reporting. The objective is practical: users should know what they own, why the workflow is changing, and how the new process improves the work they already need to complete.
Amvent's six-phase approach starts that work early and carries it through post-go-live support. The sequence gives leaders clear points to align stakeholders, surface resistance, and adjust the rollout before adoption problems become embedded. Explore the full Pigment implementation methodology for the delivery context behind each phase.
1. Engagement and buy-in: Bring finance leaders, process owners, and affected teams into the conversation at the start. Clarify the case for change, identify concerns, and establish who will sponsor decisions. Amvent's implementation begins with stakeholder engagement, internal buy-in, requirements gathering, and a data-readiness assessment.
2. Design and build: Translate agreed requirements into a model and workflows users can understand. Document the model schema, data-flow architecture, dependencies, and processes so the design does not become a black box maintained by one technical owner.
3. User acceptance testing: Ask representative stakeholders to work through realistic finance scenarios, not just inspect screens. Structured UAT, concurrency testing, and iterative refinement help teams identify gaps and establish trust before the system becomes operational.
4. Go-live readiness: Prepare people and processes for the transition through an internal roadshow, user training, monitoring, and performance management. Readiness means users understand the new workflow and leaders have a way to see where adoption is slowing.
5. Feedback and reinforcement: Create an adoption feedback loop immediately around launch. Listen to users, distinguish a training gap from a workflow or design issue, and use that input to refine the way teams work in Pigment.
6. Post-go-live support: Continue enablement after the initial launch. Support can include training, bug fixes, model maintenance, performance optimization, and documentation, helping teams make the system part of recurring planning cycles rather than reverting to old workarounds.
This approach treats adoption as a shared responsibility. Senior sponsors provide direction, managers reinforce the new process, and end users contribute the operational detail needed to make it fit. That matters because organizational change work is focused on the human factors that sustain project results, not only on whether the technology has been deployed. A rollout is stronger when feedback changes the delivery plan, training reflects real roles, and support remains available after the launch date.
How to get FP&A buy-in before the system goes live
FP&A buy-in is not secured by demonstrating a polished model at the end of an implementation. It is built when the people who submit budgets, update forecasts, review scenarios, and approve assumptions can see how the new workflow will work for them. Treat the rollout as a finance operating change, not only a technology project.
Map concerns before you present the solution
Start with a stakeholder map that distinguishes decision-makers, process owners, contributors, and reviewers. A CFO may care about control and visibility. An FP&A manager may focus on forecast cadence and model ownership. Business partners may want a faster way to submit assumptions without losing the context they use today. These concerns should shape the demonstrations, training plan, and decisions that require explicit sponsorship.
Ask each group what makes the current process difficult, where handoffs break down, and what would make them trust the new numbers. Include middle managers and employees in those conversations rather than relying only on executive approval. Research on organizational change recommends involving senior leaders, managers, and employees, while using stakeholder feedback to adjust the change strategy: stakeholder participation and feedback.
Prove the workflow, not just the model
A generic product tour rarely answers the question, "How will my work change?" Use a real. Contained finance workflow such as a monthly forecast submission, an opex plan, or a scenario review. Walk through the owner, inputs, review points, approvals, and final output. Show how assumptions are documented and how the process connects to the decisions leaders already make.
Keep the first use case narrow enough to test properly. Connected planning commonly starts with a specific use case, proves value, and expands one team at a time. Read Amvent's connected planning approach for the rationale behind that progression. A focused proof point gives skeptical users something concrete to challenge, improve, and eventually endorse.
Make sponsorship visible and practical
Ask the executive sponsor to explain why the change matters, what decisions the new process enables, and what will be expected after go-live. Then give managers a role in reinforcing the message. They should be trained early, invited to review the workflow, and equipped to answer practical questions from their teams. Resistance is easier to address when it is surfaced during design, not discovered after the first planning cycle.
Build confidence through structured user acceptance testing with stakeholders. Let users test their own scenarios, record issues, and see how feedback changes the model before launch. Amvent's implementation methodology begins with stakeholder engagement and internal buy-in, then uses documentation and testing to establish a system users can understand and trust.
Q: What if FP&A supports the project but business teams do not?
A: Do not treat that as a training gap by default. Revisit the workflow with the affected teams, clarify who owns each assumption, and adjust the first use case if it asks for too much change at once. Visible leadership support, practical demonstrations, and a feedback loop are more useful than asking users to accept an abstract future state.
Training strategies that actually drive Pigment adoption
Training should prepare people to complete the finance work they own, not simply show them where features live. In an EPM change management program, that means designing enablement around the decisions, inputs, reviews, and handoffs in each planning cycle. A finance owner needs a different level of practice from an executive who reviews the result. Treating them as one audience creates confusion and leaves critical workflows dependent on a small group of power users.
Start with a realistic end-to-end exercise. For example, a finance team might load department assumptions, review a budget submission, incorporate an updated forecast, and compare a scenario before an executive review. Use the same workflow language, ownership rules, and approval points that the organization will use after go-live. Training then becomes a rehearsal of the future operating model, rather than a disconnected product demonstration.
Finance owners: Practice setting planning assumptions, reviewing submissions, tracing the drivers behind a result, and managing the forecast cycle. They should understand how model design and documented dependencies affect the numbers they are accountable for.
Contributors: Work through the specific inputs they provide, such as department budgets, headcount assumptions, revenue drivers, or operating forecasts. Keep the exercise focused on accurate submission, comments or context where appropriate, and knowing when to escalate an issue.
Reviewers: Rehearse variance review, scenario comparison, challenge questions, and the handoff back to the contributor. This makes review a repeatable control in the planning process instead of an offline spreadsheet exercise.
Executives: Focus on interpreting the approved view, understanding key assumptions, and using scenarios to frame decisions. Executives do not need the same configuration detail as model owners, but they do need confidence in how a result was produced.
Role-based sessions should be supported by simple process documentation. During design and build, documenting the model schema, data flow, dependencies, and processes gives users a foundation they can understand and trust. Structured user acceptance testing with stakeholders is another training opportunity: ask each group to complete its real responsibilities, capture friction, and refine the workflow before go-live. Testing is more valuable when it surfaces an unclear ownership rule or an assumption that people cannot explain.
Adoption also depends on reinforcement. An internal roadshow, targeted refreshers before the first budget and forecast cycles, and a visible feedback loop help teams move past the initial launch. Organizational culture affects whether people accept change, so leaders should respond to feedback rather than treating questions as resistance. After go-live, enablement, documentation, model maintenance, and process optimization keep the system aligned with how finance operates. Teams that need a continued operating partner can explore ongoing Pigment support.
Measuring adoption success in the first 90 days after go-live
Go-live is the start of adoption measurement, not its finish line. The first 90 days provide a useful review window for checking whether the new Pigment workflows are becoming part of the finance operating rhythm. It is a practical window, not a universal deadline. Some teams will need longer to complete a full forecast or planning cycle.
Build the scorecard around observable behavior and confidence rather than login counts alone. A user may open the system frequently without completing a budget submission, while another may use it effectively only at defined points in the cycle.
Use a practical post-go-live adoption scorecard
Post-go-live adoption scorecard. | ||
Area. | What to review. | What the signal tells you. |
|---|---|---|
Workflow completion. | Budget inputs, forecast updates, approvals, and scenario reviews. | Whether Pigment fits the work finance teams must perform. |
Participation. | Roles contributing assumptions, reviewing submissions, and joining planning discussions. | Whether adoption extends beyond the core project team. |
Data confidence. | Reconciliation questions, unexplained variances, and offline workarounds. | Whether users trust the model and its outputs. |
Support patterns. | Repeated questions, unresolved defects, enhancement requests, and training gaps. | Where enablement, documentation, or refinement is needed. |
Review the scorecard at meaningful finance moments
Rather than waiting for a day-90 report, review signals after the first relevant budget submission, forecast cycle, or scenario exercise. Compare what users were expected to do with what happened in practice. If teams still export data to spreadsheets, ask whether the cause is unclear ownership. An untrusted calculation, missing training, or a workflow that does not match the business process.
Amvent's delivery approach includes system monitoring, performance management, and a user adoption and feedback loop at go-live. That loop should produce decisions, not just survey responses. Prioritize the issues that prevent a finance workflow from being completed, then communicate what changed and why. Structured user acceptance testing and iterative refinement before launch can establish confidence, while post-go-live enablement, maintenance, and documentation help sustain it.
Q: What should we do if adoption is weaker than expected?
A: Do not assume the problem is user resistance. Review the workflow, model logic, role permissions, training, and support history together. Speak with finance managers and end users, identify the specific point of friction, and make a focused adjustment. Then measure the same workflow again during the next planning event.
Keep the scorecard visible to the implementation owner, finance sponsor, and functional managers. Their feedback can guide iteration and help the organization move from a successful launch to sustained usage. For planning the rollout itself, review the EPM implementation timeline alongside the adoption plan.
Frequently Asked Questions
When should change management begin in an EPM implementation?
Begin during discovery, before the model is built. Early work should identify affected stakeholders, clarify the finance workflows that will change, and secure agreement on what success looks like. In Amvent's six-phase approach, stakeholder engagement, internal buy-in, requirements, and data readiness come first, so adoption is designed into the implementation rather than added after go-live.
How do you get FP&A users to trust a new EPM system?
Make the model understandable, involve users in decisions, and test it against the work they actually perform. Document the model schema, data flows, dependencies, and processes, then use structured user acceptance testing with stakeholders. Users are more likely to adopt a system when they can trace assumptions, validate outputs, and see their feedback reflected in the final workflow.
What should EPM training cover?
Training should be role-based and tied to real finance activities, such as submitting a budget, updating a forecast, reviewing scenarios, or approving assumptions. Show each user what they own, when they use the system, and how their inputs affect downstream reporting. Include practice in the live workflow, not only feature demonstrations, and provide enablement after go-live as questions emerge.
How can finance leaders measure adoption after go-live?
Track whether users complete the intended workflows on schedule, whether forecast and budget cycles run through the new process, and where support requests or workarounds persist. Pair usage data with user feedback and outcome checks, such as cleaner reconciliations or more reliable scenario reviews. Review the scorecard regularly and adjust training, workflow design, or model guidance when adoption stalls.
Ready to make EPM adoption stick?
A new planning system works best when the implementation plan accounts for how finance teams actually work, from forecast cycles to ownership of assumptions. Discuss your EPM implementation and adoption plan with a team that can help connect the system to those day-to-day workflows.
