Financial Consolidation System Implementations: Start At The End
Most financial consolidation system implementations concentrate on just making the shiny new product itself. They may automate all finance functions, throw in a few customisations for good measure and some whizz-bang financial reports that the CFO has never seen before but always wanted. Then the implementation team is off developing a whole suite of new reports that may never see the light of day.
Very often, it’s just too easy to get swept up in what a product could do, rather than what it needs to do.
In the flurry and excitement of a new product and the desire to please the client, what some implementation teams fail to adequately assess and prioritise is what is actually genuinely needed from the new system.
This then, is the crux of project success: the ability to deliver what is needed now and to forsee what is needed in the future. Moreover, it will determine whether and how much the system is used once implemented.
I have witnessed such gross underutilisation and misuse of client’s products over the years that you have to wonder what value they got from it. No wonder so few implementation teams carry out post-project reviews!
So how should implementation teams approach this instead?
In my view, any financial project needs to begin with an open and honest two-way relationship between the implementation team and the client’s finance team.
The implementation team needs to ask the right questions of the finance team, be honest about what the product can and can’t do currently, what developments are possible and how easy or hard they are to achieve. And crucially, not to get side-tracked into cherry picking crowd pleasing ‘quick-wins’ that have no overall impact on the essential project deliverables. These sap time, energy and money from on-time delivery.
Finance teams need to share and prioritise all the current and expected reporting requirements needed from their new system solution. This would also include all disclosure notes, as in most cases these are the hardest to re-engineer into a working system down the line. They need to assess what reporting is on the horizon, for example, following potential accounting or structural changes. And they need to be honest about what is a desirable output and a genuinely necessary one.
For me, I have always started at the end. The final outputs required must be drawn up, even before a project plan. What is out of scope and deferred list of prioritised reports, needs to be agreed, shared and signed-off by both parties at the very beginning. It is this list of deliverables that the whole project hangs on and should refer back to on an ongoing basis.
Too many times I have been caught out spending time and energy developing a system or building a report for a single individual or team that is a ‘nice to have’ or is rarely used. So my advice? Start at the end. If you work backwards, you can’t really go wrong.
Mo Khan is director at consultancy firm Cognova.
