Financial consolidation system implementations – Start at the end

Ever thought about why at the end of a financial consolidation systems implementation, the final solution is not quite fit for purpose? Why do project teams need to keep developing after “go-live” implementation? The article below tries to explain.

In my experience, most implementations concentrate on making the shiny new product, automate all things finance as the instructions on the box suggest, with a few customisations thrown in for good measure.  Very often it is all too easy getting swept up in what a product could do, rather than what it needs to do. Throw in some whiz-bang financial reports that the CFO has never seen before but always wanted and the implementation team is off developing a whole suite of new reports that may never see the light of day or is used seldomly.

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 really and genuinely needed from the new system. And the reality is, it probably isn’t the CFO that knows.

So this is the crux of project success. Its ability to deliver what is needed now, to forsee what it needs to do in the future and separate that from what is desirable and or unnecessary. Moreover, it will determine whether and how much the system is used once implemented. I have visited and helped so many clients and witnessed such gross underutilisation and or misuse of a product that you have to wonder what value they got out of it. (No wonder so few implementation teams do post-project reviews….but that’s for another time and article!)

Ultimately, this begins with a two-way relationship between implementation and the client’s finance team, which needs to be an honest and open one.

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/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 deliverables of the project. These sap time, energy and money away from delivering on time.

The Client’s finance team 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. Or worse, a major report is needed for a half yearly board meeting has been lost in the mix of requirements. So always, “start at the end.”