When it comes to the successful delivery of budgeting/forecasting projects, there is often a disconnect between what is expected and what is delivered.  In almost every situation, the fault does not lie in the software itself, but in how it has been implemented.

All too often we are parachuted in to fix problematic budgeting/forecasting projects or fix solutions that aren’t delivering value.  With a combined 100+ years as a team specializing in planning and reporting systems, and having worked on over 300 projects, we’ve got a pretty good steer on why projects can fail and it’s incredibly infuriating for us.

Summarized below are the top reasons we find that projects don’t live up to expectations, and some tips on how to avoid these pitfalls.

Scoping and design errors

All too often we find models built around replacing Excel processes, not built to optimize TM1/PA.  The result of this is a solution that is a more complex version of Excel, designed within the limitations of Excel, rather than a far more cohesive and intelligent solution that TM1 enables you to do.

Along a similar vein, we see a lift and shift mentality when moving off legacy planning tools such as “Enterprise Cognos Planning (EP)”, in an attempt to minimize the impact of change.  Catering to the limitations of old legacy planning tools and associated processes, without questioning or considering a design around how the business process actually works limits the PA/Solution and even worse it creates frustrations within the customer base.

The key to avoiding issues from the beginning is understanding the business process today and what it should be like in the future.  Legacy tools and Excel models can help unlock some of the processes but spending time on the future state and understanding the business strategy and how TM1/PA can be moulded to help execute it with the right information is key.

Project Governance

Strong project management is often lacking; it increases project costs, often leading businesses to deploy internal project managers, rather than utilizing the teams from software or consulting companies.  However, if they are not effectively holding everyone to account in the project, critical elements can and do get dropped which leads to delays, scope creep and increased cost.  In our experience, it’s critical to closely govern project delivery and especially important to consistently provide feedback to all stakeholders clearly, and deal with issues and impacts swiftly.

Stakeholder engagement

When stakeholders are held at arm’s length, often expectations start to differ.  Getting stakeholders engaged upfront, throughout the project and hands-on after the project is delivered is crucial.  The sooner key stakeholders are comfortable with a change, the more capability and the sooner they are engaged in the solution day-to-day the quicker teams around them adapt, and the less likely they are to return to old habits.

Poor UAT

When go-live deadlines put pressure on project deliverables, UAT can suffer.  Assuming it’s even been planned correctly at the scoping stage, it can be a project stage that is cut down to fit within the budget.  However, it’s crucial this is given the time and focus, to ensure that the solution fits the criteria and adoption by users is high.  It’s a crucial part of the Project Manager’s remit to ensure this happens, balance the pressures of the project, annual leave, month ends etc., to ensure the feedback is comprehensive and relevant changes are incorporated.

Poor/Missing Documentation

Again a project stage that frequently gets cut down or eliminated for commercial reasons, or becomes the responsibility of the internal team, rather than any third-party consulting support.  The outcome?  A higher cost of ownership.  Harder for businesses to take ownership of the solution down the line, with a greater reliance on third-party specialists and a less agile, responsive system.

 

The user interface is not intuitive enough

Too often we see solutions built by developers, contractors or consultants, that are technically accurate but haven’t catered to the differing stakeholder needs, skills or ways of working.  It is not just about the quality of the look and feel, but the way you navigate through the system.  Finance tends to want to view data in different ways for sales, and data needs to be viewed in different ways by different roles.  Failing to consider differing skills, mindsets and ways of working simply means one thing.  A return to Excel.

Lack of integration & automation

Whilst it’s rare nowadays to not see new systems integrated with source data (such as from ERP), we do typically still see lots of challenges with how they are integrated.  Whether the right data is being pulled in at the right time, in the right structure, and whether it surfaces in the models in the right way.  Further, we find that tricks have been missed, and different data sets that would enrich the outcome and ability to make decisions have been omitted or aren’t considered for future development.  If there is missing data, the risk is the new system simply becomes a repository with the data pulled out into Excel to combine with other data sets.

Automation is a must and it’s simply not an excuse not to automate processes.  The mindset must be if you can automate it, automate it.  Because your competitors are.

No long-term vision, projects are standalone

When projects are implemented in an isolated fashion, without clear follow-on developments, change management structure or being part of a wider maturity roadmap, the solution implemented can quickly become outdated, ineffective or lack enough value to be used enough.  Continual investment is needed to ensure you get the most bang for your buck, and your system is optimized as your business changes; it’s continually moving forward in a world that changes so fast now.

Moving from implementing budgeting/forecasting solutions that cater to finance to integrated business planning solutions, that integrate sales, operations (and the whole business) should be a long-term goal. 

Wrong mindset

When new products are bought in to replace Excel for a planning or reporting process, all too often the outcome delivered is an Excel replacement.  The expectation or the reference point for users is excel, so when planning tools are unable to mimic excel-like features, they start to passively resist the adoption of the planning tool, gathering than reframing how it might work in the new world.  By focusing on the limitations (which in some cases, are things that are not that relevant) and having this mindset it starts to unravel the value of the planning tool. 

Rather than viewing the planning product as a transformational, trusted platform, just an excel replacement.  So training and education of the team are not invested in enough, development of the product lacks and quickly its value drops, and Excel again proliferates.

Limitation system integrators – design thinking and approaches

Planning projects are complex and require an understanding of business processes, and how it links back to the overall strategy.  Consultants or companies that design these planning systems, may not have business experience and merely understand the product and capabilities.  When it comes to BI professionals, the way they design or think through solutions is based more on how the solution fits into a relational database and underlying data flow, rather than designing based on how the business process should work, and more importantly how its drives the business forward, and why? 

Planning models should be designed similarly to how excel models are constructed, but done in a multi-dimensional framework.  How you design an excel model is how your planning model should be designed, with lookups, calculated logic etc.…. Effectively, taking an excel model and transforming it into a multi-dimensional planning model is the approach, that is most successful.  This means, that consultants implementing these systems should have financial modelling background, as it is this skillset required to build a planning model successfully. 

If IT or BI professionals leading these projects do not have a modelling background, the design and build-out of these planning systems tend to be limited.  The reason for this is that they are trained and come from a database background, and can only relate to the star schema approach, primary keys and rigid reporting structure.  This is to no fault of their own, but that design thinking limits the true capability and they do not understand how a financial planning model, built with excel, actually works and how you can translate that process to a planning tool. 

Understanding the background of your system integrator is key, and you could make design decisions that are limited and require re-work in the future, once users start to understand the capabilities of the planning tool.

 

If the product is wrong

There are times when the product just simply cannot do what is needed, and a selection error has occurred.  We find that there is over-reliance on research from firms like Gartner, who are paid by software and consulting companies to review their products.  Their insight is never deep or broad enough or tailored enough to individual businesses.  Another common issue is a product is bought because someone has used it before.  Bypassing a structured, unbiased and objective vendor selection program (and not effectively capturing requirements before this), can risk the wrong product choice (and/or paying more than is needed).  We recommend building out a thorough vendor selection criteria matrix.

 

So why do mistakes keep happening in these areas?

Time to focus – Everyone is busy, under pressure and tight on budgets, those aligned internally have BAU to contend with or contractors are introduced. 

Lack of understanding – in the business and stakeholder groups can also be a big factor.  Not enough of the team understand enough or are trained well enough before, during and after implementations.

Experts are not supportive enough – Consultants are too often unable to improve understanding/education within the business/stakeholders, either through their own limitations or because they are held at arm’s length, and software firms are now too focused on the licence deal itself to care.

Relying on an individual in the team or a contractor can wreak havoc.  Aside from being a single point of failure, a contractor’s view isn’t necessarily aligned with the business, after all, they typically want to ensure there are contract extensions.  How is their skill and experience kept up to speed, have they got the financial knowledge, the business logic skills, the database and data integration skills, and the end user mindset?

We work hard to keep our clients accountable to the project, project managers are managing effectively and end-user feedback and sentiment are captured frequently.  We deploy an entire team, not just one person, across project phases as well as ensure strategic conversations are consistently held to align expectations.   Outside??

The outcome is a solution that turns into a platform of trusted data, one that truly transforms the business

Our advice?  Choose a partner that really will be just that.  A Partner.  One that supports you through the good times and the bad, one that constantly helps drive the needle forward, ensuring your platform progresses as your business changes from one week to the next, one that cares more about a long-lasting, highly valuable relationship, rather than a quick payday.

Written By Lance Tylor 

Lance is a business finance professional with a passion for helping businesses grow. He is a Charted Management Accountant (CMA) within Canada and in the UK and has had several roles within the Office of Finance. His experience has always been focused on business strategy, performance management and business process improvement (leveraging the latest technologies).