Once you reach the software selection process of a planning system implementation, there are several key steps that are critical. Obviously, you need to choose the right tool for the job, but other aspects of this step in the IT journey are equally important.

The second part to the FP&A Guide on Implementing a Planning System provides insights on selecting the right software. In this article, we’ll examine the research you’ll need to do on your software vendors and the RFP documents you’ll need to create.

BACKGROUND RESEARCH

You’ll need to find out who the key players are to identify the ones you would like to examine more closely. Begin with your own reading and review of industry literature. For example, the following publications are known industry and product reviews: Gartner Magic Quadrant for Cloud Financial Planning & Analysis, Forrester Wave, BPM Pulse, and Nucleus Research.

There are multiple ways to meet with vendors before beginning an engagement. AFP’s annual conference and its annual FP&A event FinNext both provide an opportunity to speak to multiple vendors. Many vendors will have local user groups and meet-ups in your area where you can attend, meet other users, and hear about the software capabilities. You can also attend their user conferences and meet with clients and see applications there.

Software selection is also an opportunity to lean on your business network to ask what they are using and their experience; this is especially helpful if your industry has specific tools and templates that you can leverage.

Vendors themselves also offer opportunities to interact with their products without a full engagement. For example, many products have online trials to interact with the software, roundtables and online demonstrations/webinars. If desired, you can also issue a request for information to ask for input to think through a roadmap or eventual RFP. If you reach out for conversation, vendors and implementors ask that customers clarify which stage of the process they are in.

CREATING RFP DOCUMENTS

The goal of the RFP process is to solicit input from the vendor community for the service you want. It is a tool to communicate what you are looking for, and so you should think of it as a document to educate vendors so that they can develop a response for you that meets your needs and provide a fair estimate of cost, time and effort. It is important to resist the temptation to propose a solution; instead clearly state the problem, goals, objectives and key requirements, and let the respondents bring ideas to you!

Frank Chou, FP&A, CTP, senior manager at H&T Nevada, explained his clear goals that guided subsequent decisions: “For us, time to value and cost were the key drivers. We had a very short timeline (<3 months) and needed a system up and running ASAP. I [needed] integration with Excel and an easy-to-learn interface. With a team that had no extensive experiences in systems…I needed something that would ease their transition and enable us to meet tight deadlines without the system itself becoming a constraint.”

There are several documents to help educate the vendors:

The RFP document should help the vendor understand the purpose and parameters of the project, announce the start of a competitive process, and indicate the seriousness of the customer to pay for the services. A sample RFP document is available for download on the AFP website; typical sections include an introduction to the company and the project, how the response process is structured, the scope of the deliverables, timeline and basis for evaluation.

The business (functional) requirements document identifies what the system should be able to do to support your goals and objectives over a three to five-year timeframe; it should not specify how to do it because that limits the potential solutions they can bring back to you. A first draft of this should have been developed as part of the business case. The requirements may be at a high level (especially early in the process); expect to add an additional level of detail as you get closer to implementation. Practitioners and implementers recommend clearly understanding your must-have requirements versus your nice-to-have wishes to ensure your primary needs are met effectively. Overall, a well-crafted requirements document can help to avoid rework, errors and cost, and is worth the investment in time and effort.

A use case is a qualitative description of how a user interacts with the current system, applying several requirements to achieve a desired outcome in a manner consistent with overall project goals. The purpose is to explain to vendors how the software will be used, providing a “day in the life” view of your specific department to both business and technical readers and often helping to bridge gaps between the two groups. The use case may become the basis for a proof of concept to be developed later.

Technical requirements describe the functionality and features of the system. For example: performance, including time to calculate or refresh; availability, such as uptime; reliability concerns; capacity to handle data; hierarchies; security at various levels; single sign-on to the platform; interoperability; and APIs. They are sometimes called service-level requirements or quality of service items. At a high-level, they may be included as part of the RFP process, as they relate to the business functional requirements; at a detailed level, they may be utilized later for design specifications.

For more insights, download AFP Guide to Implementing a Planning System: Part 2, Selecting the Software.