Planning, Budgeting & Forecasting Processes – Scoping the Project
8th January 2008 Successful projects are those that deliver early positive results – “quick wins” – that generate enthusiasm amongst users and sponsors alike for the next stage. However, separating the planning process, with its many interdependencies, into self-contained, staged deliverables can be fraught with difficulties. Indeed, there is rarely even consensus regarding how the whole process fits together in the first place. In the fifth of a series of six articles, FSN contributing editor Steve Bows picks his way through the maze of design considerations and presents a few guiding principles.
The Integrated Planning Process
An Example of the Annual Budgeting Process in a Manufacturing Company
In the first article of this series, we touched upon the integrated nature of the annual planning cycle, distinguishing three processes: strategic planning, the annual budget round, and regular re-forecasts. Each of these processes has a number of sub-processes, often implicit and rarely defined as such, that act as discrete “modules” making up the whole. The diagram shows a typical set of modules (sub-processes) composing the annual budget process of a manufacturing company – whilst every organisation is different, the reader should recognise many common features with his or her own business: Direct Expense Planning by Cost Centre, Headcount & Salary Planning by Employee/Cost Centre, and the (frequently mysterious) Overheads Allocation process.
Each of these modules depends on the inputs from, and delivers outputs to, other modules in the process. Revenue projections impact Production (quantities and costs), Labour Costs, Stock Holdings, and should be taken into account when planning Capital Expenditure. Likewise the Profit & Loss, for many the ultimate goal of the process, cannot be operated independently of the Balance Sheet and Cashflow modules if the interest expense is a significant item.
The inter-relationships become even more complex when we superimpose the Strategic Planning and Forecast processes on this map – should the strategic plan focus purely on revenue and treat expenses as a “one-liner”? Or do we need more detail on capital expenditure and staff costs to inform strategic decision-making? How does the forecast fit in – should it focus on tweaking expenses and assume no major change in revenue plans? If not, how can we expect short turnaround times? Once these decisions have been made, how do we feed budget and actual data into the forecast model, forecast into the strategic plan model, and then the plan into the budget? Many Financial Controllers would be forgiven for throwing their arms up in disgust and returning to the clarity of the month-end reporting process, but, difficult though they are, these are important business questions that need to be answered for a successful planning implementation.
Preparing the Ground
Try to avoid getting bogged down in the detail to begin with – a process mapping exercise is usually a good place to start, drawing the high-level connections between different pieces of the puzzle. Focus on the “as-is” budget process if possible, rather than an ideal (“to-be”) planning solution, it will be easier to find common ground and hence get the project started. A diagram such as that above would be a common first output from such an exercise. This map or diagram can then act as a common frame of reference, agreed by all stakeholders and pinned to the wall during the detailed design workshops.
The first thing that will become apparent is that, even at this high level, there is a great deal of uncertainty and disagreement about the process. This is understandable, as it is likely that management thinking has not been channelled explicitly in this direction before, precisely because it can be rather abstract and unclear. What should also emerge, though, is that there are also areas of complete agreement – the Staff Cost Planning module is fairly uncontroversial in most businesses, as is Direct Expense modelling. Revenue planning in “traditional” product-based businesses, where volume x price = revenue, may also find general agreement early on. Wherever it may be, this solid ground is the ideal place to build the first stage of the solution whilst the discussions continue on the remaining elements.
Next, prepare your infrastructure – by establishing separate development and production environments (and perhaps a “test' area too if the project budget extends this far), you are laying the foundations for successive stages of incremental development, releasing the new process in bite-size instalments rather than attempting the daunting task of an all-or-nothing “big-bang” solution which is rarely successful.
This technical infrastructure should also include a planning data mart (see article two of this series), delivering clean dimensional and fact data from the data source or sources most relevant to your starting point. This is often the General Ledger, but can include the Payroll system and perhaps other (sales-related) operational systems. The data that can be gleaned from these systems will often inform the detailed design of the planning modules – for example, if product-by-customer actual sales data is unavailable for comparison, there may be little point in developing a plan down to this level of detail.
Prototyping & Iterative Design
Having mitigated as many risks as possible up front through these three initial steps (process mapping, establishing a development environment, and preparing a suitable data mart), all the management attention can be focussed on the detailed design process for the first module(s). This is best accomplished through a series of workshops, the aim being to draw out requirements in gradually increasing detail. After each workshop, a prototype model should be produced by the consulting team, illustrating their understanding of these requirements and providing a “straw man” to be critiqued and improved upon in the next workshop. The aim of the process should be to produce an application that is robust, elegant, useable and scalable (where possible) to future development. An example of the latter would be choosing to enter employee bonus payments as a “manual” entry line in the first incarnation of the Staff Cost Planning module, with the aim of bolting on a more accurate bonus model at a later date.
The key point of note here is the iterative approach – whatever is designed now will no doubt be tweaked and adjusted in later stages, so it is important not to get too hung up on getting it absolutely right from day one. After all, the only thing we know for sure about a plan is that, however detailed it may be, it is extremely unlikely to be a perfect prediction!
Integration & Reporting
Having prototyped the initial modules, the final design step is to consider the “loose wires” – how should this small subset of the process integrate with the existing (spreadsheet) framework? Best practice is to use the data mart as a hub to feed data into, and extract data from, both the planning modules and the remaining spreadsheets, but this may be too slow in some processes with frequent planning iterations. Creative uses of ETL may be called for in this case, but remember that these are interim connectors that will become redundant once the full model is in place, so don't over-engineer.
Likewise, in an ideal world, reporting from this combined spreadsheet/planning model data should leverage the common hub of the data mart where possible, supplemented by ad-hoc, non-production standard reporting of key information required during the budget process itself. An example of this may be a report of employee transfers across all cost centres, showing zero overall movement – it is not part of the published budget book, but could be a handy cross-checking tool.
Building on Initial Success
The design process complete, the first modules can safely progress to the build and test phases of the project, which are structured much like any other IT project. The moment of truth then arrives when the planning cycle begins. How will the users react to the new tool? If you have an experienced and enthusiastic project team, only the surliest of end users will fail to be impressed by the end product. The trick is to maintain this momentum and cement the initial success, and this is what we shall tackle in the final article in this series.
