The 1989 supernatural film Field of Dreams, features Kevin Costner as an Iowa farmer named Ray Kinsella. Throughout the movie, Ray hears voices coming from his crops… “If you build it, they will come.” Ok, it’s actually “he will come”, so suspend your disbelief for the sake of the analogy. To paraphrase the rest: Ray flattens out a bunch of his crops and builds a ballpark, which causes him financial distress. Shoeless Joe Jackson (Ray Liotta) then shows up to play, and he brings other players from the 1919 Chicago White Sox.

Ray then experiences a series of supernatural connections between baseball, his deceased father, the fictional author Terence Mann (James Earl Jones), Fenway Park, and former player-turned-physician Moonlight Graham. Ray’s father then comes back to play; they make amends and have a catch. At this point, we realise that this father-son reconciliation was the purpose of the whole movie.

Faith-based User Adoption Tactics

I could talk about more about the movie, but I want to get back to the point. Towards the end of the film, Mann gives a speech and reassures Ray:

“Ray, people will come, Ray. They’ll come to Iowa for reasons they can’t even fathom. They’ll turn up your driveway, not knowing for sure why they’re doing it. They’ll arrive at your door as innocent as children, longing for the past.”

And sure enough, people arrive from miles away to come to see these historical figures play baseball on Ray’s field, and presumably, the bank doesn’t foreclose on the family farm. Cars as far as the eye can see, paying $20 each, in grainy 1980s VHS.

While this faith-based line of thinking works well in sentimental movies about father-son relationships, it guarantees low end-user adoption rates when it comes to your FP&A software deployment. If you build it, they will NOT come. Well, they might, but I don’t recommend playing those odds. We’re talking about budgets and forecasts and financial reports, dry topics for many non-finance people.

FP&A User Adoption Pitfalls

Here’s a story that might sound familiar if you’re a finance professional who has implemented an FP&A / CPM / EPM platform. Let’s say the outcome you were looking for was a streamlined and efficient Annual budget. 

You selected the product. You brought in the implementation team. You painstakingly went through your requirements and designed a workable solution. You implemented the solution. You rolled out the solution to end-users. You turned the system on. Then what?

• Your end-users don’t really use it much. You have to beg them to enter their budget.
• You receive complaints about logging in. About the setup. About what the numbers mean.
• A few users fail to submit by the deadline, and you do the work for them.
• Other users just email you an Excel file instead of going through the platform.
• No one is accessing the self-help reports.
• The budgets are a mess and detached from reality, and now your job is harder.

Root Causes of Low User Adoption

Ok, that's an extreme, worst-case depiction of a live budget process. But there are probably a few kernels of truth in there that many can relate to. If your end-users are not adopting the software, you’re not getting full value from your investment.

It’s especially true with any forecasting or budgeting process. The success of the system is dependent on everyone cooperating. Your plan doesn’t have teeth if it fails to capture the collective contributions of the greater organisation.

What causes an end-user to reject a new FP&A system? Broadly speaking:

• Your Product - The product isn't excellent to use
• Your Implementation - The implementation does meet the end-users requirements
• Your Culture - The company culture doesn't support an ongoing, collaborative planning processes

1. The Product isn’t that great

What if, instead of Joe Jackson and the 1919 White Sox, the players coming to Ray’s farm were people no one had ever heard of? And they can’t hit, can’t throw, can’t catch?

If the product isn't any good, then people won’t consume it.

We have to put ourselves in the shoes of an end-user. They may only contribute to a budget process once a year (although I recommend more frequent). The most straightforward approach for them might be to maintain the status quo; finance sends them a file, and they fill it out and send it back. End of the story, life is good. Having a separate login and a new system to learn adds no value on its own for them. It’s just more steps and more to remember. But, of course, that hurts the value of the FP&A software, and finance has a more challenging job as a result.

Some of the things that drive end-users crazy:

• It takes too many clicks to perform actions
• The interface isn’t intuitive, and it’s full of technical jargon
• The errors and warning messages are esoteric, or they aren’t even handled at all.  “NullPointerException… what the heck is that!?”
• They need to remember new login credentials, and there is a painful or non-existent password recovery process.
• The installed product components are unstable or “needy”, and it impacts the users' computer even when they’re not using the product.
• The templates or reports are slow to open or interact with. The workplace is full of distractions, and a 20-second delay might be long enough to lose them!

Overall, this should be the easy part since there is far more room for error in the following two sections. If the end-users are complaining about the product, it means you’ve either done a great job with the solution and culture, and there’s nothing else to complain about, or you have a big problem with the product you picked. I run a vendor selection process to minimise risk here.

2. The Implementation missed the mark

What if, instead of a regulation size ballpark, Ray Kinsella had built a little-league diamond? And instead of playing with bats and balls, they used broomsticks and rocks? And the lines and markings on the field were drawn crooked, the park had no lights, and the bleachers were made of balsa wood?

Lots of things can go wrong during implementation. Fortunately, they’re avoidable and within the implementation team's control. There are two sub-categories:

1. The implementation has mistakes
2. The end-users requirements are not being met

2.1 Missing the mark: It has mistakes

This is the most painful category because it’s completely avoidable with proper testing techniques. If the system is misconfigured, users may be blocked or otherwise develop negative sentiments toward the software or towards finance.

Implementation errors come in many forms, from minor inconveniences to show stoppers:

• Data entry fields are locked down instead of accepting input
• The actuals data isn’t tied off correctly
• Calculations aren’t firing properly, or data is blank
• The user security is misconfigured, causing people to see too much of the business, not enough of the business, or the wrong part of the business.
• Formatting and aesthetics are inconsistent or ugly

End-users experiencing these errors will get the impression that the implementation was sloppy or may erroneously think that the product is defective. It’s hard to say which one of these is worse.

2.2 Missing the mark: Misalignment with end-user requirements

It’s very possible that the implementation was built exactly to specifications… but still totally misses the mark.

This happens when the configuration just doesn’t make sense to the end-users. Or it’s not helpful to them. Or it’s convoluted and hard to understand. What makes sense to finance doesn’t always translate appropriately to end-users.

Some likely causes:

• The process is detached from their reality. For instance, a marketing manager thinks about spending through the perspective of campaigns and vendors, but the interface shows unfamiliar GL accounts.
• The solution forces them to do a lot of work offline. A sales manager needs to download the pipeline, put it into Excel, calculate the revenue expected from that pipeline, and then copy and paste the result into the financial plan.
• The reports or templates are structured inconveniently. An IT manager needs to comb through 15 different departments to understand the total IT spend.
• The data they are used to getting is no longer there, perhaps because it was removed from the implementation scope. A cost centre manager is accustomed to looking at historical transactions to understand past spend, but those are no longer available. This is especially risky when planning a “phased” approach to delivery.

Issues like these can make the end-users question whether finance is a true strategic partner.

3. The Company Culture is working against you

So you pick the ideal product and then implement it flawlessly. All good, right? Not necessarily.

What if, instead of building a ballpark in the American mid-west that showcases “America’s Pastime”, Ray Kinsella had set up shop in northern Siberia? And no one for many miles knew anything about baseball or had any desire to watch it? And then Ray failed to take any steps to educate them or raise awareness?

FP&A software usually has an asymmetrical value proposition across an organisation. It’s tremendously useful for finance, but the value varies quite a bit for the end-users… anywhere from “very useful” to “this is awful, and it’s impacting my ability to do my job properly”.

Your end-users aren’t automatically in sync with the finance mission.

What might be going through the head of an end-user?

• Why am I being asked to do this? This isn’t what I was hired to do.
• There’s no point in spending much time on this... No one can predict the future.
• There’s no point in spending much time on this... Finance is just going to change my numbers afterwards.
• There’s no point in spending much time on this... I have no ownership over the results.
• I tried using a system like this years ago, and it never worked properly.
• I’d be happy to help, but I don’t have time for any of this.
• This isn’t useful for me, and I run my department through instinct.
• I don’t understand what any of this means.

Company culture can either exacerbate the asymmetry further, or it can bring it more into balance.

People will pick up on the direct and indirect messaging from upper management and from peers. If planning doesn’t appear to be necessary to leaders across the organisation, product adoption (or lack thereof) will follow.

One strike, and you’re out

• Are you picking the right product?
• Is your implementation set up for success?
• Can your culture shift to support an ongoing collaborative and structured planning process?

Unlike baseball, you don’t always get three chances to adopt an FP&A software solution. Faltering in even one of these three categories can sink a new FP&A software deployment and “poison the well”, so to speak, for future processes.

End-user adoption for FP&A projects needs to be top-of-mind and central to any deployment strategy. I’m looking forward to covering different tactics and strategies for improving end-user adoption in a future post.

For now, I'd love to hear battle stories. What are some of the challenges you've had with getting users to adopt new technology?