Over the years I've seen many implementations do very well, and others...not so well. There are many factors to project success, but the one that everyone should focus is on first is having the business adopt - that is, use - the software.
To drive adoption, you need a lot of communication. No, more than that, and much earlier than most finance teams think - hence the need to focus on it first.
Many teams I speak with are reticent to communicate with the business about the new tool until it's ready to use. I understand this point of view, but the reason I advise against it is simple - people don't like change.
What you don't want is to introduce the tool to a budgetholder by saying "This cycle we're moving to a new tool. Here it is, go do your budget. It's due Tuesday." Most people are already not massive fans of the planning process, and you just tossed some uncertainty in there.
What you should do instead is to sell, and involve, as early as possible.
Chances are you will have some processes with budgetholders after you've decided to move to a tool, but before it's implemented. During these, tell them there's a great new tool on the horizon. Highlight things about the process they're going through now that will improve with the new tool. Do that a couple of times and you prime them to approach the tool positively.
That's the selling part. Involving them can be as simple as asking them at the same time - what do you wish was different about this process? You can hedge your bets by noting that you can't factor in everyone's input, but people like to be heard; and what happens a lot is that budgetholders ask for things you were going to do anyway (like having options to automatically spread numbers, rather than them having to calculate it). And often their ideas are good, and achieveable.
That's for the broad user base, but you also probably know who the real key players are. The ones who will influence the opinion of others. Do the same with them, just maybe take it up a notch; often, you can sell it as a great project to be involved in for the CV.
And make sure you set up a feedback process - a dedicated inbox, an anonymous form, or whatever makes sense for your organisation. Leave it open on an ongoing basis, and telegraph its existence, ideally within the software itself.
Finally, focus on what's in it for them, which is a classic obvious but overlooked thing to do. There will be many advantages to you in finance that don't accrue to them - so focus on the self-service, the ease of use, or whatever it is that will benefit the end users.
And don't just send them emails! Use multiple communication channels, because we all already have too many emails. Town halls, presentations at team meetings, a Teams/Slack channel, recorded videos - anything to get the message out.
Here, more is more!
