Continuous Planning

With company valuations in the dumpster and credit markets tight, the eco-
nomic crisis is forcing hard looks at revenue sources and spending across the
board. The economy aside, old ways of doing business are continuously chal-
lenged by competitors with innovative business models enabled by the inter-
net.
These and other socio-economic trends are pressuring finance teams every-
where to make planning systems more immediate and responsive. The old way
of thinking—you run a company through the once a year budget process—is
on the way out in favor of new concepts and system approaches generally de-
scribed as “continuous planning”. The practical implementation of conti-
nuous planning is through rolling forecasts—frequent updates of financial
plans that include integrating actuals data and rolling the forecast time pe-
riod beyond the current fiscal year.
This white paper explores the concepts and practices of continuous planning
with a focus on defining application requirements for integrating actuals, fi-
nancial modeling and scenario analysis—the three foundations of a conti-
nuous planning system.
Alight Planning is an integrated planning and reporting software package
that supports the requirements for continuous planning.

Application Requirements for
Continuous Planning
By Rand Heer and Ben Lamorte Beth Anders, CFO for Whitehorse Corp., a
$300 million manufacturer of electronic
equipment, shook her head. The Ops Re-
view meeting, all two hours of it, was a
bomb. Peter Forrester, the Planning Direc-
tor, was looking glum.

Despite three days of preparation, Beth and
Peter’s presentation of the rolling forecast
left too many unanswered questions about
where and how Whitehorse should cut back
operations in light of a recent drop in orders
and rising inventories. Like most manufac-
turers in their industry, the credit crunch
had an immediate ripple effect that required
action.

© 2009 by Alight LLC. All rights reserved.

Application Requirements for Continuous Planning

Preparing for the meeting, Beth and Peter Q1 actual spending rates into Q2 fore-
realized that the company’s 2009 budget cast months.
approved only three months earlier was
useless. Whitehorse had missed Q1 sales Modeling inventories. The budget
and profit targets by a package included modeling tools. For
wide margin. No example, during budgeting Peter could
amount of number forecast inventories in the aggregate
crunching produced a based on links to cost of sales and as-
credible forecast where sumptions about inventory turns. How-
Q1 misses could be ever, for the new forecast he needed
made up in later quar- more granularity, a model that projected
ters. This was a first at inventories by product group and
Whitehorse, coming off type—raw, WIP and finished goods.
the full year budget at The modeling in the budgeting applica-
the end of Q1. tion had an Excel-like formula interface,
but it was too restrictive and difficult to
The real pain, however, came from working use. Forecasting inventories at a more
with the company’s new budgeting soft- detailed level didn’t get incorporated in-
ware. Installed the previous summer, Whi- to the forecast. That was an embarrass-
tehorse replaced its Excel budget templates ment at the Ops Review.
with a high end budget applica-
tion built on an OLAP (on line Beth and Peter needed response times
analytical processing) database.
The new system had seemed to
measured in seconds, not minutes or
work: cycle times for budget re- hours…They needed a tool that made
visions were reduced; line man- collaboration a real time process.
agers were less confused over
how to input data; and consolidations were
Setting up scenarios. While budgeting,
faster with fewer errors.
Peter used the new system’s versioning
Beth and Peter had expected that the bene- capabilities for managing revisions. It
fits would continue as they used the bud- worked. For the rolling forecast, howev-
geting package for developing a rolling er, it didn’t. The focus this time was on
forecast at the end of Q1. However, the new scenarios, also known as “what if” anal-
system failed to support several critical ysis*. The problems were maintenance.
needs. Here were the issues: Peter couldn’t make structure changes,
like adding a line item, across multiple
Integrating actuals. Peter was able to scenarios at one time. As well, if he
import actuals for January through needed to make a change to an input as-
March into the budget package and re- sumption across scenarios—like updat-
port variances against budget. However,
mechanics were not available for inte-
* We use the terms scenario and “what if” inter-
grating actuals data into the balance of
year plan. For example, he could not set changeably. Both have essentially the same
up a model where Q1 actual orders meaning—namely, an alternate financial analy-
sis with its own assumptions that are different
drove Q2 revenues, nor could he spread
from a known starting point or baseline case.

Page 2


ing rent expense—he had to change you run a company through the budget
each scenario one by one. When com- process—is on the way out in favor of new
paring scenarios, Peter could compute approaches such as continuous planning, a
variances only at the account level. discipline for developing plans and decision
There was no visibility into differences making promoted by such organizations as
between scenarios of underlying activity the Beyond Budgeting Round Table and
drivers. In short, the new budget pack- planning gurus like Rob Kugel at Ventana
age didn’t work well for the in-depth Research.
scenario analysis that Whitehorse
needed. Pulling from the literature, the table below
presents the differences between budgeting,
Update response time. The budget ap- the historical discipline, and continuous
plication’s client server architecture and planning, another way of thinking pro-
user security made gathering user in- moted in this white paper.
puts easier than with spreadsheets.
However, Whitehorse’s current plan-
ning situation was not about re-doing
the budget. The company needed to
make short term decisions about staff-
ing, inventory management and other
elements of the business, each with ma-
jor impacts on profitability and cash
flow. During the plan analysis, the cycle
time between changing input assump-
tions and then viewing the impact on fi-
nancials took too much time. Given the
sheer volume of analysis required, Beth
and Peter needed response times meas-
ured in seconds, not minutes or hours.
Historically, budgeting has been the com-
The Need for Continuous Planning mand and control foundation for running a
business—that once a year Uber-process
With company valuations in the dumpster that produces a one size fits all binder docu-
and credit markets tight, the economic crisis ment with performance targets, bonus for-
is forcing hard looks at revenue sources and mulas, sales quotas, headcount and spend-
spending across the board. The economy ing controls, standard costs for inventory
aside, old ways of doing business are conti- valuation, capital budgets, and Wall Street
nuously challenged by competitors with guidance—all based on the same numbers
innovative business models enabled by the with the same underlying assumptions. The
internet. With instant access to product in- budget also becomes the company official
formation and comparative pricing, cus- forecast for at least two quarters because no
tomers rule as never before. manager admits to not being able to “make
budget” sooner than Q3. That’s the politics
These and other socio-economic trends are
of budgeting.
pressuring finance teams everywhere to
make planning systems more immediate Few finance organizations are ready to
and responsive. The old way of thinking— dump budgets per se. However, many are

Page 3


looking critically at their spreadsheets or problems preparing for the Ops Review
canned budgeting applications asking how meeting that bombed.
they can deliver more immediate and res-
ponsive financial plans. In particular, Actuals—the issue is not whether an
finance is getting more serious about roll- application can import actuals data; all
ing forecasts that incorporate a senior level of them do. The issue is how well im-
involvement in core operational issues and ported actuals can be integrated into the
their financial impacts. forecast plan.

Many organizations already do rolling fore- Modeling—the issue is not whether an
casts, principally Fortune 500 companies application includes modeling tools; all
where the discipline is ingrained. Here, the of them do. The issues are how flexible
challenge for finance is to find ways to are the tools for building complex driv-
make the process less political, especially in er-based models and how easy is it for
dealing with hockey sticks forecasts. the super user, people like Peter, to
build and maintain the models.
Requirements for Continuous Planning Scenarios—the issue is not whether an
As Beth and Peter discovered, there can be a application supports versions and sce-
big difference between a budgeting applica- narios; again, they all do. The issue is
tion and what’s needed for real planning— maintaining the scenarios, visibility into
in their case, implementing a rolling fore- the underlying activity drivers of each
cast process that’s heavily focused on mod- scenario, and response times.
eled elements, scenario analysis and near
term decision making. The materials that follow describe these is-
sues and show how Alight Planning han-
Whitehorse’s dilemma sets the stage for the dles the functional requirements.
theme of this white paper: what are the
most important functional requirements to Integrating Actuals
look for in a software package for imple-
Virtually all budgeting appli-
As Beth and Peter discovered, there cations support importing ac-
tuals from the general ledger,
can be a big difference between a bud- typically based on rigid chart
geting application and what’s needed of accounts structures. As
for real planning, in their case a rolling well, you can usually import
headcount and salaries from
forecast… the HR system. Once im-
ported, budget applications also support
menting continuous planning—and its not
comparing actuals to budget based on levels
so distant cousin, rolling forecasts?
in the chart of accounts with computation of
In the materials that follow, we walk amount and percentage variances.
through three software feature/function
Outside the safety of the accounting struc-
areas that are central to all planning appli-
tures, however, lining up actual and plan
cations, whether simple budgeting or more
data in a continuous format for a rolling
sophisticated planning. Not so coincidental-
forecast is typically a zoo, principally be-
ly, these are areas where Beth and Peter had
cause it is difficult to get actuals data ap-

Page 4


ples-to-apples with plan data at the line cally imported from a data warehouse or a
item level. CRM system.

For example, for basic revenue planning: Finally, in our Whitehorse story Peter dis-
covered with the budgeting application that
Units * Sell Price = Sales Amount he could not set up a model where Q1 actual
500 * $100 = $5,000 orders drove Q2 planned revenues, a severe
For actuals, however, you get the data whe- limitation. For robust continuous planning,
rever you can, and the data is typically you must have the capability of truly inte-
amount and units. Therefore, for an apples- grating actuals into the financial plan. That
to-apples comparison across units, price means: 1) being able to model actuals as an
and amount, the actuals data must be mod- activity driver for the rolling forecast, and 2)
eled to back calculate the sell price: spreading actuals data into plan time pe-
riods—e.g. projecting last month’s actual
Sales Amount / Units = Sell Price spending run rates into future months.
$5,000 / 500 = $100

As the examples illustrate, actuals data fre-
quently need modeling different from plan
data to get valid comparisons and trends.
For maximum flexibility in setting up roll- In Alight, you can create data relationships where
ing forecasts, the planning application actuals are activity drivers for plan. In the example,
Product A unit sales drive Product B sales with a two
should allow modeling of actuals with algo- month time lag. Note that Product B’s forecast sales
rithms and linking separate from modeling for Jan 09 are the same as Product A’s actuals for
Nov 08—i.e. actuals are integrated into plan.
of plan data.

In Alight, you can “spread” actuals data into plan
timeframes. In the example, Feb 2009 actual spend-
ing rates for Legal, Accounting and IT Service fees
are spread into the plan time periods Mar and Apr
2009. The spread action on multiple line items is
done in a single operation.

Driver-Based Modeling
Alight includes separate tabs for modeling actuals
and plan at the line item level. In the example, plan Budgeting focuses on gathering static in-
units * rate = amount. For actuals, amount / units =
rate. puts from users, principally for headcount
and expenses. Little modeling is involved—
In addition, actuals data need to be im- typically just calculation of payroll taxes
ported from any source at any level of detail, and benefits.
not just the general ledger. In the above
revenue example, the actual sales amount is Such a process is not workable for conti-
imported from the general ledger, but units nuous planning, especially in the context of
for back calculating average price are typi- rolling forecasts. The cycle time for complet-
ing a forecast after month end close is too
Page 5


tight to accommodate broad based user in- ships based on the names of things—e.g.
volvement on the scale done for budgeting. Commissions are linked to Net Sales and
As well, user based planning involves high the Commission Rate is 5%—versus cell
volumes of static inputs in order to achieve based linking in Excel with formulas
precision. By contrast, continuous planning like = Sales! C45 * $L$15. Object based
needs to reduce the volumes of data, focus- linking makes auditing and visibility in-
ing instead on fewer truly material forecast to activity driver relationships signifi-
elements. cantly easier to track, thus eliminating
many errors, speeding up development
The objective of reducing data volume is and reducing maintenance time.
achieved in part through “driver-based
planning”, a type of financial modeling
where the most material items in a financial
plan are linked to operational drivers or
quantifiable activities of the business —e.g.
volume measures such as units, transac-
tions, subscribers, customers, call levels,
hours, installations and the like.

Such driver-based modeling has three fo-
cuses: 1) revenue forecasting based on the Alight’s modeling interface is based on object-based
volume measures and driver relationships linking where you create data relationships by link-
between products, 2) variable and semi- ing to the names of other line items or totals. Linking
automatically operates across all time periods—i.e.
variable headcount and expenses driven by no fill right as required with spreadsheets.
the volume measures or identified underly-
ing activity levels; and 3) for cash planning, Modeling across dimensions. Planning
balance sheet items such as inventories, ac- applications should support custom di-
counts receivable and accounts payable, mensions—e.g. product, customer,
each based on their respective P&L drivers channel, region, project, job type, grade
at a relevant level of detail. level, etc. The modeling environment
should then allow tapping into the cus-
Companies moving to a continuous plan- tom dimensions for building specialized
ning discipline should closely evaluate the activity-driver models—for example,
modeling environment of the planning ap- aggregating sales line items by channel
plication they are buying into. Modeling to drive channel specific discounts; ag-
and model maintenance should be fast, flex- gregating employee salaries by job class
ible, and (unlike Excel) provide clear visibil- for driving tiered bonuses. Applications
ity into linking relationships. without modeling based on dimensions
do not have the flexibility required for
In our experience, there are two make or
driver-based planning.
break functionalities in the modeling inter-
face needed to make driver-based planning Robust Scenario Analysis
work:
Budgeting is about managing versions, not
Visibility into driver relationships. scenarios. As the budget is developed,
This requires object based linking where finance keeps track of versions to under-
the modeler establishes data relation- stand who changed what and to make sure

Page 6


the right amounts are approved. Once a satisfy the need for speed we’re used to
version is superseded, there is rarely a need with Excel. Scenario analysis must be an
to look back at the old numbers or change interactive process responsive to ques-
them. tions and testing of assumptions on-the-
fly. Continuous planning needs tight
By contrast, continuous planning is about feedback loops on the numbers.
scenarios, lots of them. If you can’t predict
the future, the next best thing is to set up
scenarios that let you explore how you
might behave (or decide) if things are better
or worse or just different. Unlike budgeting
where you care about who changed what
number, scenario analysis is about under-
standing what’s behind the numbers—the
most critical assumptions, volume and rate
impacts, and especially what’s driving ma-
terial changes to the P&L and cash flow. Unlike budgeting apps, in Alight you can change
values of line items across multiple scenarios. Click-
The deliverable of scenario analysis is ac- ing the Scenario button lets you choose which Sce-
narios you want to apply the new values to. Updates
tionable knowledge. By analyzing a specific to financials are immediate.
scenario and comparing it to a baseline case
or other scenarios, the management team is Maintenance across scenarios. Budget
better able to evaluate best courses of ac- versions don’t require ongoing main-
tion. Where there is an immediacy to the tenance because old versions are super-
issues—e.g. to proceed with a capital project seded by new ones. Scenarios do. The
or change pricing—the deliverable is deci- planning application should support
sion making. Because it’s decision and ac- adding, modifying and deleting line
tion focused, robust scenario analysis is the items across selected scenarios in a sin-
most critical underpinning of continuous gle operation. Calculation and update of
planning. financials after structure changes should
take only a minute or two, at most.
The functionality you need for effective
scenario analysis goes beyond simple budg- Robust comparison at the line item
et versioning. Here are our criteria: level. Budgeting focuses on amounts in
accounts. Continuous planning is about
Real time feedback. Whether you’re a in depth comparison of scenarios and
financial analyst working through the differences in values at any level of de-
numbers late at night or the CFO ans- tail, especially at the line item level
wering questions live in an operations where the most significant inputs and
review, scenario analysis should be de- modeling occur. Where the underlying
livered by the planning tool in real time. data or links are available, scenario
That is, when you change a value, all comparisons should reveal variances in
elements of the financial model—the underlying unit activity drivers and
P&L, balance sheet, cash flow, financial rates.
ratios, performance metrics—should
update in seconds, not minutes or
hours. In short, scenario analysis must

Page 7


COMPARISON OF SCENARIOS WITH VOLUME/RATE CAUSAL ANALYSIS: Alight lets you compare scenarios at any
level of detail including analysis of underlying units, rates and amounts. In the report below, the scenario called 2009
Downside is compared to the scenario 2009 Base Forecast. Each scenario has underlying monthly data. The right
hand column is a causal analysis that computes by line item the amount variance between scenarios and the volume
and rate components of the amount variance.

Analytic tools. Scenario analysis should Summary
incorporate related analytic tools such Continuous planning and rolling forecasts
as: require special features that extend beyond
the capabilities of spreadsheets and many
Sensitivity analysis: Tools for iden-
budget applications. Actuals data must be
tifying the most and least sensitive
available for driving forecast values. Model-
input assumptions and calculating
ing tools must be robust and provide trans-
their impacts on sales, profitability
parency into underlying activity drivers.
or any target in the plan.
Scenario analysis should be real time with
Goal seek: Here’s how: 1) choose a maintenance across scenarios. It should in-
target such as operating profit 2) clude supporting analytic tools.
specify a financial goal—e.g. $1 mil-
In a continuous planning environment, the
lion 3) select an input variable—e.g.
return on investment is not from reducing
unit sales. The application calculates
time spent on planning. The ROI comes
how many units are required to
from better financial performance as a result
achieve the $1 million profit goal.
of a more responsive planning environment
Causal analysis: Where underlying and improved decision making.
units and rates are available, com-
_______________________________________
pute volume and rate variance im-
Rand Heer is President of Alight LLC and the
pacts between scenarios. (See exam-
creative force behind Alight Planning. He was
ple above.) also the founder of Pillar and designer of Hyper-
Dashboards: Display key perfor- ion Pillar, the first enterprise software for budg-
mance indicators that update as sce- ets and forecasting.
narios are changed. Allow display
and rapid update of input assump- Ben Lamorte is Vice President, Sales at Alight.
Previously, he headed his own consulting firm
tions from the dashboard.
specializing in complex model building for such
companies as Adobe, Kaiser and PlanetRX.

Web: AlightPlanning.com/Tel: (530) 622-5485.

Page 8

Continuous Planning

More Related Content

Similar to Continuous Planning

More from Ben Lamorte

Recently uploaded

Continuous Planning