A strong Pigment user adoption plan starts before launch: connect the model to decisions people already own, involve them in design, and make the new workflow easier to follow than the old one. Finance and operations teams use a planning system consistently when responsibilities are clear, training reflects real tasks, and feedback leads to visible improvements.

Get in touch

What does user adoption mean in a Pigment implementation?

Adoption is not simply the number of people with logins. It means contributors enter and review information on time, managers use shared outputs in decisions, and the process can run without depending on a small group of experts to repair it each cycle.

For finance, that may mean budget owners submit assumptions through a defined workflow and FP&A reviews changes in context. For operations, it may mean sales leaders maintain quotas and capacity assumptions or functional owners update workforce plans. The exact workflow depends on the use case. A system can be technically complete while adoption remains weak if the process is unclear or does not fit how teams make decisions.

Set expectations for each role before configuring workflows. A contributor, reviewer, model owner, and executive decision-maker will not use the system in the same way. Describe what each person needs to do, when they need to do it, and how they will know the work is complete.

How should leaders define the first use case?

Start with a specific planning problem rather than a broad ambition to transform every process at once. Choose a use case with a clear business owner, a recurring decision or cycle, and participants who can explain where the current process creates friction. Many organizations start with FP&A, then expand to adjacent planning areas after the initial workflow is established.

Before design begins, document a simple baseline:

• Decision: What decision should the plan support, and who makes it?

• Participants: Who contributes inputs, reviews them, and resolves exceptions?

• Timing: When does each role need to act within the cycle?

• Inputs: Which assumptions or data are maintained by each team?

• Outcome: What should users be able to review or decide when the cycle ends?

Keep the initial scope small enough to test, but meaningful enough that users recognize its value. If the first release tries to reproduce every spreadsheet and edge case, users may face complexity before the core process is reliable. A focused launch can establish shared definitions and responsibilities, then inform the next phase.

For example, a first forecast cycle might focus on revenue assumptions, headcount, and operating expenses for one business unit. Finance can define a common calendar and output; functional owners contribute their assumptions; leaders review variances at a regular meeting. Once that sequence works, the team can identify which adjacent planning domain should come next. Amvent’s approach to connected planning describes gradual expansion, with an initial use case followed by adjacent domains one team at a time. Consider that sequencing alongside the organization’s broader planning use cases, rather than assuming every group must move at once.

How can finance and operations share ownership?

Adoption is a cross-functional responsibility. Finance often owns the planning calendar, core financial logic, and consolidation of inputs. Operations teams own assumptions closest to their work, such as headcount needs, sales capacity, or operational drivers. Executives clarify priorities and resolve trade-offs. IT may support access, integrations, and technical controls.

Write down ownership in plain language. For each workflow step, name who prepares, who reviews, who approves, and who handles an exception. Avoid assigning an entire process to “Finance” or “Operations” without naming accountable roles. A responsibility matrix can make handoffs visible:

This table is a starting point, not a substitute for your organization’s actual governance. Some teams combine roles; others need separate owners for data, process, and model design. Make the distinction explicit so users know where to take a question. For a smaller team, one person may coordinate the cycle and administer the model, but document the separate responsibilities even when a single name fills both roles. That makes it easier to reassign work when staffing changes.

Involve representatives from each user group in design reviews. Ask them to walk through a real planning task and identify confusing language, missing context, or unnecessary handoffs. This helps reveal adoption barriers while the workflow is still being shaped. For more on clarifying cross-functional responsibilities, see how finance and operations can align on one plan.

How should workflows be designed for everyday use?

Design around the planning cycle users must complete, not just the model’s data structure. A contributor should understand what is expected, where to enter an assumption, and what happens after submission. A reviewer should see enough context to assess the input and return it with a useful reason when it needs revision.

Use consistent names for metrics, versions, and planning periods. Explain terms that are familiar to Finance but not to another function. Make deadlines and review states visible. Where teams need to discuss exceptions, identify the correct channel and owner rather than leaving users to guess.

Consider a department manager entering a hiring plan. The workflow should make the planning period and relevant organizational unit clear, define what counts as a planned role, and identify whether the manager or finance reviewer resolves a mismatch. If a request is returned, the manager needs to understand what to correct and why. A vague “please update” message creates another round of clarification and delays the cycle.

Keep the first workflow focused on essential steps. If every contributor must navigate complex options that apply only to a few administrators, the system can feel harder than the process it replaces. Conversely, hiding necessary context can lead to low-quality inputs and workarounds. Validate the design with representative users before broad rollout. Amvent’s article on testing a planning process before rollout offers further considerations for roles, review criteria, and exceptions.

What training helps users adopt Pigment?

Training should prepare people to perform their role in the planning process, not merely tour the interface. Build short, role-based sessions around realistic tasks. A contributor might practice entering an assumption and responding to a review comment. A manager might practice reviewing submissions and identifying a variance that needs follow-up. A process owner may need deeper guidance on workflow administration and exception handling.

Useful training combines a live walkthrough, a chance to practice, and concise reference material users can revisit during the cycle. Use examples that resemble the decisions and terminology people encounter in their work. Check understanding by asking users to complete a task, not only by asking whether the session was clear.

• Explain the purpose of the planning process and how its outputs are used.

• Show the steps specific to each role, including review and correction.

• Clarify definitions, timing, and where users should request help.

• Provide a safe practice opportunity before a live planning deadline.

• Refresh training when the workflow or responsibilities change.

Prepare a simple practice scenario that follows the entire handoff. For instance, a contributor enters a revenue assumption, a reviewer asks for clarification, and the contributor revises it. Ask the learner to explain where the item stands after each action and what must happen before the cycle is complete. This checks both interface familiarity and process understanding.

Training cannot compensate for unclear ownership or a confusing design. If users repeatedly ask the same question, determine whether the problem is a skills gap, an unclear process, missing context, or a model issue. Fix the source instead of relying on repeated reminders. Keep reference material short enough to use during work: a role-specific checklist, key definitions, a calendar, and a clear route for help are often more useful than a long generic manual.

How can teams prepare for launch and support?

Launch readiness is a coordinated check that people, process, and system are ready to work together. Before go-live, confirm that intended users can access the areas needed for their roles, that the planning calendar and instructions are available, and that critical workflows have been tested with realistic scenarios. Confirm who will monitor incoming questions and how issues will be prioritized.

A practical readiness review can proceed in sequence. First, confirm that each role and its owner are recorded. Second, ask representative users to complete their tasks using the intended instructions. Third, verify that reviewers know how to return incomplete work and contributors know how to respond. Fourth, check that the process owner can see outstanding work and route exceptions. Finally, make sure support contacts and escalation steps are easy to find. A failed check should have an owner and resolution date rather than being silently accepted.

During the first live cycle, make support visible. Users should know where to report an access problem, a confusing instruction, a possible data issue, or a change request. These are different issues and may need different owners. A simple intake process can capture the user, task, impact, and deadline so the team can route requests appropriately.

Use the launch period to listen for recurring friction. If a step consistently causes delays, find out whether the cause is training, model design, timing, or unclear decision rights. Avoid treating every question as resistance. People often identify practical gaps that were not apparent during design. A documented go-live handover plan can help clarify how ownership moves from project delivery to ongoing administration.

How can finance measure adoption without reducing it to logins?

Choose a small set of measures tied to the work. Login counts may help identify access patterns, but they do not show whether a planning cycle is being completed well. Pair activity signals with process outcomes and user feedback.

• Process completion: Are required submissions and reviews completed by the agreed milestones?

• Rework: Do inputs return repeatedly because instructions or definitions are unclear?

• Support patterns: Which tasks generate recurring questions or delays?

• Use in decisions: Are leaders reviewing planned outputs in the meetings where decisions are made?

• User confidence: Can users explain their role and complete common tasks without relying on informal workarounds?

Set a baseline and review patterns over multiple cycles. A late submission may reflect a poorly timed workflow, an upstream data dependency, or unclear accountability—not simply a user’s unwillingness to participate. Look at the context before changing expectations or adding training.

For example, if several departments submit late, map the dates and dependencies before sending reminders. Perhaps the input deadline arrives before managers have the data they need, or review time is too short. If only one type of submission repeatedly returns for correction, examine its definitions and examples. If leaders attend the review meeting but do not use the plan, ask whether the outputs answer the decision they need to make. Each pattern suggests a different remedy.

Keep feedback loops short. Share what the team heard, what it will change, and what will remain as designed. This builds confidence that reporting an issue leads to a considered response. Where requests imply a broader scope change, route them through the agreed governance process instead of making uncontrolled changes mid-cycle. Review a concise list of open issues after each cycle: describe the observed friction, its impact, the likely cause, the owner, and the next action. Close the loop with users so they know whether a request was accepted, deferred, or needs further analysis.

What commonly gets in the way of adoption?

Several avoidable patterns can make a new planning process harder to use:

• Launching too much at once: Broad scope can overwhelm users and make it difficult to learn what is working. Sequence rollout around clear use cases.

• Designing without end users: A technically sound model may not reflect how contributors work. Test real tasks with representative users.

• Training everyone the same way: Different roles need different actions and detail. Tailor sessions to responsibilities.

• Leaving ownership implicit: Users cannot act confidently when no one owns review, exceptions, or decisions.

• Measuring access instead of outcomes: Logins do not establish that the planning process is trusted or completed.

• Ignoring post-launch feedback: Unresolved friction encourages spreadsheets and side channels to persist.

Another risk is preserving a legacy process step simply because it exists in a spreadsheet. Before building it into the new workflow, ask what decision it supports, who uses its output, and whether it is still needed. Removing an obsolete check can make the process clearer, while retaining a control that still matters protects the quality of the plan. Distinguish between “this is how we have always done it” and a genuine business requirement.

Adoption work is not a final communications task after implementation. It is part of scope, model design, governance, testing, and ongoing ownership. When these elements are planned together, teams can build a process that users understand and leaders can sustain. For a practical external framework, the UK Government’s service standard calls for understanding users and their needs when designing services; the same user-centered discipline can help teams shape planning workflows around real tasks. See the GOV.UK Service Standard.

Explore practical EPM adoption considerations

Frequently Asked Questions

When should a Pigment adoption plan begin?

Begin during implementation planning, before workflows are finalized. Early involvement lets finance and operations users help shape roles, instructions, and review steps before the process is launched.

Who should own user adoption?

Adoption is shared. A business process owner coordinates the cycle, functional leaders clarify responsibilities, model owners maintain the system, and executives reinforce how planning outputs inform decisions. Assign named owners rather than leaving responsibility with a department alone.

How can teams encourage use beyond the initial launch?

Make expectations part of recurring planning cycles, provide role-based support, review friction after each cycle, and communicate improvements. Consistent ownership and visible use of outputs help establish the process as routine work.

What should adoption measures include?

Consider completion of submissions and reviews, rework, recurring support needs, use of outputs in decision forums, and user confidence on common tasks. Interpret measures in context rather than treating a single metric as proof of success or failure.

Chat with us about your adoption plan

Make adoption part of the implementation plan

A practical adoption plan ties a focused use case to clear responsibilities, usable workflows, role-based training, and support after launch. Finance and operations teams can build confidence cycle by cycle, using feedback and evidence to guide what should improve or expand next.

Get in touch to discuss your Pigment implementation

Get in touch with our team

Get in touch about user adoption