As a finance professional implementing an FP&A / CPM / EPM platform, you might face several...
Key contributors:
- Jessika Dhanoa, EY UK Financial Services
- Alex Ignaciuk, EY UK Financial Services
- David Malortie, EY UK Financial Services
This article is the second in a series examining considerations for financial planning and analysis (FP&A) transformation projects. The first article “10 principles for driving long-term value in FP&A transformation’’ set out key principles to follow when considering the approach for FP&A design. This article follows on to identify the ingredients for success in implementation.
“The best big idea is only going to be as good as its implementation.” [1]
Successful implementation requires clarity on the selected tools, delivery methodology and business benefits that the solution aims to deliver. The six considerations set out below aim to improve success for FP&A implementation.
1. Align delivery approach to the users’ ways of working
The delivery approach is a critical consideration as it will affect the relationship between the users and the implementation team. Most organisations are likely to have a preferred or prescribed methodology, based on previous experience and ways of working with transformation teams.
For example, some organisations may prefer a traditional waterfall method, with detailed requirements and scope established early and the solution built with defined release cycles. Other organisations may be more comfortable with a fully agile approach, working collaboratively with developers to scope the requirements and develop new features throughout the project iteratively. Alternatively, a hybrid approach could be adopted to set out detailed requirements at the start, followed by an iterative implementation to enable rapid enhancements to the specifications.
The implementation team can provide an appropriate challenge to the business and help assess alternative approaches that may produce a better outcome. What is important is to agree on an approach that considers users’ ways of working as well as delivery costs and timelines prior to initiating build activities.
2. Configuration over customisation
The tool selected will influence the level and complexity of configuration required during implementation. Some software as a service (SaaS) products are more customisable than others and this will impact where investment is needed in the implementation.
FP&A solutions that apply standard configuration development and avoid customisation help to reduce implementation complexity and accelerate user adoption. Where the requirements lead toward customisation, alternatives should be explored and the trade-off between costs and user benefits should be evaluated. Some configurations will always be required to align to business models, and easily configurable FP&A solutions will reduce build cost and implementation time.
3. Deliver the Minimum Viable Product
As discussed in the previous article on design considerations, organisations may want to roll out a proof of concept before committing time and resources to full implementation. This represents a much smaller up-front investment but can still be leveraged as a basis to enable a larger scale transformation programme.
It’s important to stay true to the scope as defined for the minimum viable product (MVP). The interest from users will build as the solution develops, and there is a risk that extending the scope too early will undermine the quality and buy-in of the MVP. Holding firm on the scope will help to build the increased success of user adoption, preserve quality and shape the requirements for a larger implementation, which in turn will improve the outcome for the business.
4. Optimise the design of the initial implementation
Transformation teams should aim to deliver the MVP and related models with optimal design, setting the foundations for a future build. This means making allowances for integration of new data sources, and extension of data requirements and tool functionality without the need to fundamentally rebuild the solution. For example, the data model should be able to accommodate different levels of data granularity and extended data dimensions with minimal disruption.
In addition, technical optimisation techniques should be employed, for example using numbered lists and focusing on avoidance of data sparsity in models. A conscious effort should be made to minimise technical redesign, which would require a re-build of planning models with existing functional design. Delivering the MVP in a way that anticipates future development “(future-proofing)” will reduce the cost of change and accelerate the post-pilot implementation.
5. Focus on data migration and validation from the outset
Data sourcing and migration is an extensive activity that requires significant input from business users and transformation teams and is often underestimated. Complexity arises for many reasons - for example, one to many mappings where new data granularity is required or from migrating manual journals. The preferred approach may be to obtain early imperfect data extracts from source systems then iterate the data rather than delaying for a perfect first extract.
Similarly, the data validation could be complex and require considerable business support. The reference reports and granularity of reconciliations that will form the basis of data validation should be agreed in advance. Data validation should start with high-level numbers and be able to reconcile with expected results. It is possible that familiar metrics could be redefined or use a different calculation methodology, so users may need help to adjust to new measures.
6. Use testing to promote user engagement
Testing should be a continuous activity factored into each development cycle and release iteration promoted through an agile delivery approach. Testing should also be an opportunity to enable user engagement early and increase ownership of the solution but needs to be balanced with the time and availability of users. Starting with a core user group for early iterations, testing can be expanded to broader groups as use cases are added. This will help all users become familiar with the system and, through feedback, identify use cases for future development.
Testing acceptance criteria and targets need to be defined from the outset to avoid a mismatch of expectations. For example, unit or functional testing may be more ‘binary’ in terms of proving success (it either works, or it doesn’t), whereas there may be some flexibility in the acceptance criteria for end-to-end process testing or data validation based on aggregated numbers.
Conclusions
Successful implementation requires user adoption of the solutions developed – if you build it and no one uses it, then it will be a failure. The key is to find the balance between the delivery approach, the criteria for success, solution optimisation required and resources and time available for implementation. While the considerations set out do not in themselves guarantee to achieve the full potential of a transformation program, they will help guide the development of the approach and minimise the need for re-investment at a later stage. These considerations, combined with strong governance, clear communication and skilled business and systems integration teams can help mitigate the common pitfalls of FP&A implementation and set the conditions for business success.
[1.] "Jay Samit." AZQuotes.com. Wind and Fly LTD, 2021. 25 January 2021. https://www.azquotes.com/quote/880239
This publication contains information in summary form and is therefore intended for general guidance only. It is not intended to be a substitute for detailed research or the exercise of professional judgment. Member firms of the global EY organisation cannot accept responsibility for loss to any person relying on this article.
EYG no. 003903-21Gbl