Brief: IT Budgeting System - Deciding Whether to Build or Buy

---

To help you answer the build-buy question we’ll 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 they need.

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.

An 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 is made.

The early steps include:

1. 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
2. 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
3. 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 (don’t forget the process changes!)
4. 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 cost?

A Few Key Considerations

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 detailed specifications
• 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

Lessons Learned

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 CIO’s 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.
• It’s 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.