When preparing to implement a planning and forecasting system, I am often asked if we can just take the existing spreadsheet solution and squeeze this into the new system. Invariably my answer is: Yes, we can do this, but we should not. Why?

Usually, the existing spreadsheet solution will reflect all the limitations arising from the fact that spreadsheets do not have the capabilities you get from a proper database solution. Its use is likely to be limited to a few users. The structure will probably be based on a maximum of two dimensions. Consolidation and change tracking will be difficult, if possible at all, except manually, and most likely, it will be used for annual budgeting only.

Implementing a new solution to budget, which means to forecast, setting targets and allocating resources, is a great opportunity to redefine how we do things and improve what needs to be improved.
 

The first question we should ask ourselves is why we do a budget at all? What is really the purpose of it, and how will it help us to succeed?  

What we usually call budgeting does, in fact, include three different tasks:

• setting targets,
   
• forecasting performance,
   
• and allocating resources.

The first thing we should do when preparing a new implementation is to think about those different tasks, what they have in common, where they conflict, and how this relates to our business. The purpose of setting targets is not the same as the purpose of forecasting. We set targets to motivate a certain behaviour and usually do this for the longer term. On the other hand, we must do forecasting and resource allocation more often since it is a part of managing the business and staying agile. Every time our environment, internal or external, changes, we must reforecast and reallocate resources accordingly.

Furthermore, we must not forget the conflicts that typically arise when we try to combine forecasting and target setting. A forecast should be realistic, while a target may be, and should be, ambitious. Combining those gives us unrealistic forecasts and unambitious targets. Unrealistic forecasts prevent effective resource allocation. Unambitious targets limit our potential for success.

Once we realise this, we understand that we should perhaps not talk about budgeting at all. Instead, we should talk about target setting, forecasting and resource allocation as separate processes. This should be our starting point.

The next step is to determine which of those processes we need. Do we need detailed targets for the business? What value do they add? Or should we rather do with general high-level targets? If this is the case, do we really need a software application for this? 

When it comes to forecasting and resource allocation, the first step is to understand the way our business works. 

Do we run a stable company in a quiet market or a growing business in a dynamic market? If the latter is the case, we probably need rolling forecasts updated every month or every quarter, using a horizon that fits the business cycle. If not, we may not even need any detailed forecasting. The nature of our business should determine the frequency and detail of reforecast and re-allocation of resources, as well as the appropriate time horizon.

Once we have a rough picture of the requirements, it is time to think about work processes and people. Here there are two key considerations. First, it must be clear who is responsible for the planning process. This will not necessarily be the person responsible for the content of the plan. Second, when deciding on participants, we should think first about the value of their input and then distribute the tasks accordingly.

We should distinguish between the tools we use for forecasting and resource allocation on the one hand and performance measurement on the other.  

Those are different processes performed by different people, and they call for different technical capabilities and different user interfaces. A sales manager pulling together his sales forecast has a limited need for advanced reporting. He needs a robust planning tool that includes basic historical sales analysis, not necessarily much more. The key is that it gives him the possibility to plan from all the relevant angles at the relevant levels. The finance professional needs a consolidation tool, and the CEO needs standard reports for the board, KPIs and scorecards. In short, we should understand the tasks we are going to perform and what they require.

Now we can move on and start looking at different software solutions based on the specific needs we have identified.

Of course, every company is different and has its own specific needs. I know this well, having done implementations for dozens of clients of all shapes and sizes. However, there are always some common requirements that must be fulfilled. Here are some of the most important demands a good planning solution must fulfil:

• It should be flexible enough to allow you to build a model that fits your business.
   
• It must be best of breed when it comes to the target setting, forecasting and resource allocation processes, not on reporting and analysis.
   
• It should be easy to use so that you can let the relevant people work on planning without spending too much time. In other words, your solution should not be used only by finance; it should allow you to go beyond finance.
   
• It must really cut the time you spend on budgeting and consolidation.
   
• It should be centralised and provide a single version of the truth.
   
• It must allow you to use reforecasts/rolling forecasts as a management tool.
   
• It must link seamlessly with your reporting/BI and business process systems.
   
• It should be easily customisable with minimal effort.

 
Once we have selected the appropriate solution, it comes to the implementation project itself.

Apart from general considerations regarding good project management, I would only like to stress two critical points:

       1. Avoid huge implementation projects.

For 90% of companies’ planning models are relatively simple. Implementation projects should, therefore, not have to be very large. There are two main reasons for huge implementations. One is that the solution being implemented is too complex technically and thus difficult to install. Given the wealth of good, easy-to-use applications, we should have avoided this problem in the selection phase. The second reason is that we are trying to integrate processes that are better done elsewhere. For example, for most companies, interest expenses and depreciation are often best done in spreadsheets; you have the flexibility to model those the way you like and, more importantly, to change how you model them. This part of the process is not distributed among many users, so permission and process flow management are of no concern. So why then try to integrate this into the budgeting solution? It only adds complexity to the project and limits your flexibility to model the way best fits you.
 

       2. Remember the rule of diminishing returns.

Based on my experience with such projects, I have found that you will achieve 80% of the work in 50% of the time. After this, the return on additional work will diminish fast. So, rather than use the 100%, make do with the 50% or thereabout. Leave the rest out unless really necessary.
 

Summing it up

Implementing a new planning solution helps streamline planning processes and better manage your business. The key to success is to avoid shortcuts, to reduce the concept of budgeting into its actual components - target setting, forecasting, and resource allocation - to choose the tools that best fit each purpose and avoid overcomplicating the implementation project.