“It forces you to think through your business needs as a team. It removes ambiguity when talking with vendors and makes it easier to compare. It ensures your implementation will go the way you expect.”
Document your Requirements up-front
When you’re about to make a sizable investment in FP&A software, up-front diligence can go a long way to save you from a painful implementation and to ensure you make the correct decision on software. Defining and documenting your business requirements in advance is a big part of this and one of the keys to success.
It’s easy to get caught up with watching vendor demos and finding a product with all the right features. It’s important to give equal time to your own finance processes; documenting them in advance and having everyone on the same page before you select a product.
A familiar pattern
I’ve seen this story a number of times.
Imagine a finance team has a cumbersome planning or consolidation process built entirely within Excel. It mostly gets the job done, though it’s very manual and time consuming to use and it doesn’t help them to engage with the rest of the organization. The spreadsheets have passed through a few hands over the years and while a lot of the modeling is impressive, it’s getting to the point where no one fully understands it and it’s starting to feel like a house of cards.
Eventually they realize the current path isn’t sustainable and someone says “we need a system!” They go to market to find an FP&A / CPM tool.
The joys of selecting Enterprise software
Buying enterprise software can lead to lots of wasted time and the final decision isn’t always the best one because of incomplete information.
- They reach out to a half dozen vendors and describe their process over the phone to a half dozen different sales teams.
- The vendor sales teams give a generic software demo for their respective products.
- The finance team rules out three of the products. One was clearly the wrong fit and a waste of time. Another would have actually been a great fit, but was ruled out because of scheduling conflicts. A third was a decent fit but was ruled out because they felt they had already short-listed enough.
- The remaining products seem to be able to do everything they need and are starting to blur together. For any question they ask.. “can your product do blank?”, the answer is always “yes!”
- It’s now time to discuss the implementation costs. The sales team for two of the vendors sends over a few basic services pricing options. The third vendor spends 30 minutes on the phone to scope the project and provide a boilerplate statement of work.
- Now with pricing for licenses, services, and a demonstration of each product, the finance team now feels they have what they need to make a decision.
Cracks in the foundation
Everything seems positive and they sign a multi-year contract. The product looks powerful. The total-cost of-ownership is reasonable. The implementation can be done on time.
The implementation starts. They meet the team who will handle the training and project delivery. This new team asks a lot of detailed questions and spends hours uncovering more information about the desired finance process. As the implementation gets moving, things look less optimistic:
- Members of the finance team aren’t agreeing on how parts of the process should work. They never actually discussed this item in the past (nor did any vendors ask) and now there is much internal deliberation.
- Some of the requirements that the finance team thought were “in scope”, were not so. The finance team remembers discussing them with the sales team early on, but they were not included in the implementation services package that they bought.
- Some of the high-priority product capabilities don’t work the way they expected and are tedious to use and maintain. They had seen it demoed, but it was brief and from a certain perspective where they couldn’t appreciate the shortcomings.
The internal deliberation on requirements set the project back weeks in the early stages. Adding the “new” requirements into the scope will set the project back further along with adding cost to the project. Lastly, there are internal suspicions that the product may not meet their long-term needs, which is casting a pall over the project team. Not good!
Investing the time will pay off
All of this is avoidable when you document your requirements in advance. It forces you to think through your business needs as a team. It removes ambiguity when talking with vendors and makes it easier to compare. It ensures your implementation will go the way you expect. It may even save you implementation dollars since many services proposals will be inherently buffered to account for uncertainty.
If you’re starting on your selection process, we offer high-level advice:
- Document the as-is state of your current process. We know time is always short, so keep it light.
- Based on feedback from the team, create the to-be state for a new system. Spend about 3x the time here as the as-is process.
- Prioritize and identify which requirements are mandatory and which are nice-to-have.
- Do a formal or informal “sign-off” among your team and executive sponsor prior to meeting with vendors to make sure everyone agrees on direction.
- Share the new state with the vendors you are serious about. Insist that all conversations and demos are anchored back to the vision you share.
- Encourage the vendor to draw from their experience to advise you and provide insight into your process.
- Push the vendor for further demonstrations on high-priority items and make sure you get all your questions answered.
- Insist on a detailed estimate or statement of work that properly represents your business requirements. Don’t be afraid to ask the vendor to make it fixed-price if you want to trade a slightly higher cost in favor of cost-certainty.
Documenting your requirements in advance can be a lot of work up-front so it’s important to remember: (1) the work will pay off in the long-run with a more efficient implementation and (2) you shift the odds of picking the right software more into your favor. This is an important best practice for any software implementation.
We can help. Learn more about our vendor selection process.
