Brief: IT Budgeting
System - Deciding Whether to Build or Buy
To help you answer the build-buy question
well briefly: outline the issue, suggest an approach to making the decision, raise a
few key considerations, and then describe the lessons learned by two organizations that
decided to build.
What is the Issue?
IT has become one of the largest costs for many
organizations. Often, only personnel cost more. Increasingly, senior and IT
management want to know:
- Costs - often to the IT project / activity level
- Cost drivers - the users and purposes
- Budget status - monthly / quarterly report of plan
vs. actual spending
- Forecast - current and future cost predictions
The problem is two-fold: first, legacy budgeting
systems were designed for accounting purposes not modern budgeting, and second, legacy
budgeting processes are not designed to capture the financial, organizational,
operational, and other information needed to give IT and senior management the answers
To remedy the situation, IT and senior management
(sometimes working together-- too often not) are faced with the decision to replace, or
augment, their existing budgeting system. A related decision is whether to develop the
budgeting application in-house or to purchase a commercially developed application.
Approach to the Build-Buy Decision
The decision to build or buy a budgeting system is
not an isolated decision, and should be approached the same way any IT investment decision
The early steps include:
- Develop a concept proposal -
briefly define the need, purpose, stakeholders,
required functionality, priority, alternatives, anticipated benefits and costs,
shortcomings of existing systems (and the budget process), and anticipated timeline
- Get early buy-in - make sure that
there is agreement-in-principle among key decision-makers that (a) they are prepared to
implement a new system and make the necessary budget process changes, and (b) will
objectively evaluate the build vs. buy alternatives
- Perform the analysis - refine the
requirements, thoroughly evaluate the commercial products, and estimate in-house
development requirements. In other words, do the cost-benefit analysis (dont
forget the process changes!)
- Evaluate the risks, benefits, and costs
- compare the in-house option to the commercial alternatives and determine which makes the
most sense for your organization
Once you are completely satisfied that the options
have been thoroughly assessed, the proposal should be refined and submitted for final
decision through the normal IT project decision-making channel.
Be sure to answer these questions for the option
you recommend to senior management:
- Does it comply with organization policies,
requirements, and procedures?
- Is it cost-effective?
- Is it consistent with overall strategic direction
and business objectives?
- Does it meet end-user requirements?
- What are the potential impacts on performance?
- What are the risks?
- What is the life-cycle
A Few Key
The following should be carefully considered in
making the decision:
- Timing - how quickly does the
system need to be in full production
- Future Requirements - once the
system is in production, what new demands are likely to be placed on it
- Related Systems - systems that must
provide data to, and receive data from, the budgeting system
- Expertise - not just the technical
expertise to do the programming, but the budgeting expertise to develop and provide
- Budget Process - whether you build
or buy, the IT budget planning and performance management processes will require redesign
- Analysis, Forecasting, Reporting -
anticipate the need to perform radically different, and often more sophisticated,
analyses, forecasts, and reports
This is a composite of the lessons learned by two
IT organizations that decided to build their own IT budgeting systems. In both cases, the
early motivation was the CIOs desire to prove to senior management that business
users, not the IT organization, were driving IT costs. For one CIO, an additional
objective was to be able to hand business users a bill for the services rendered.
Here is what they learned:
- A simple spreadsheet listing proposed
project-by-project costs can yield impressive information.
- Information starved senior, business, and IT
management will want more.
- Building a "system" of linked spreadsheets
can lead to "spreadsheet hell".
- Developing a rudimentary budgeting application can
take several years.
- The demand for modifications and enhancements is
relentless, as new needs are recognized.
- If the IT budget process is not redesigned, data
collection and analysis become an administrative nightmare.
- Budget analysts will spend more time on systems
development than analyzing the budget and budget performance.
- Its very expensive.
The bottom line - budgets are the lifeblood of IT
organizations. Thoroughly investigate the needs and options before making a decision
to build a budgeting application.