Prove your priorities: the budget squeeze

Whether you are a team leader or the IT director, chances are you will have some input into the annual IT budget process. Perhaps the word process gives too much of a sense of order as most of the budgets I have been involved in over the last 15 years were more of a running battle with skirmishes often continuing throughout the year. The budget wars only petered out when it was time to start thinking about the next one or the economic climate had changed, rendering it obsolete. If this sounds familiar, you are not alone and if it does not, you are very lucky.

I can summarise a popular approach in these few steps: IT starts with a long list of things to do, the firm responds offering only half the money, the battle takes place and IT eventually ends up with two-thirds of the money, sometimes followed by a surprise "haircut" leaving IT with a bit less than that.

So the key to success for IT now hinges on its prioritisation process as clearly not everything will fit into the budget. So how do you work out what to do and more importantly, how does IT demonstrate to the firm that the right things have been selected? This is critical in the current tough economic climate and many firms will inevitably start paying a lot more attention to IT prioritisation processes.

A technique I have seen used occasionally in the past to increase IT funding involves carrying out lower priority work within budget and then asking for an uplift to carry out critical work which the firm is highly unlikely to reject. But you can only get away with this once or twice before the firm starts scrutinising IT funding tactics. In the current climate, many firms may genuinely not be able to afford the additional budget, leaving the company in a poor position and the IT director nursing an unexpected P45.

So how can IT manage successfully within an inadequate budget, keep the firm running and also explain to the wider audience how decisions are made about what to include or exclude? Flavours of the technique described here have worked successfully in a number of banks I am sure must be used in other industries as well. It involves listing key business products and processes and then mapping out the IT systems involved in delivering those processes. Once the main systems have been linked to business processes, areas requiring attention can be identified and prioritised in context of the full landscape. Of course IT already knows what this looks like, but the key point here is to summarise and present it in a coherent way that the business folk will understand and buy into.

In its simplest form, the systems map is a spreadsheet showing products or processes across the top and systems involved down the side. More sophisticated tools and graphics can be used, but the spreadsheet option is usually the cheapest, quickest, easiest to use and has the benefit that most staff in and beyond IT are likely to be armed with MS Excel and know roughly how to use it.

Sources of information for the systems map include asset databases, procurement or licensing records, financial depreciation records, system topologies, design documentation or other similar material a firm may have available. This basic information will often need to be fleshed out by interviewing the IT support teams and business users to understand the process flow in more detail as well as establish the hotspots requiring attention.

The level of detail is an important consideration as it can be a significant ongoing job to keep a complex systems map up to date and this is not usually necessary for budget prioritisation anyway. Establish a suitable threshold of materiality so only the larger systems and higher cost budget items are included and people do not get distracted by a large volume of small projects.

Once the systems map has been created, it is relatively straightforward to pinpoint the proposed work to be included in the budget. Using the spreadsheet, each system requiring attention is colour-coded and classified to highlight hotspots.

This technique effectively presents the business with a full a-la-carte menu with the chef's recommendations in bold. It does not distract people with detailed recipes but does allow the business guys to grasp context and make choices having seen everything on offer. The map allows IT and the business to work together to agree priorities and develop the budget accordingly. Just like a menu, the hotspots must also have cost estimates put against them at this stage.

Systems hotspots can be classified in a number of high-level categories to assist the business in understanding the nature of each issue. Typical examples include:

• Capacity: transaction, data or user volumes are forecast to exceed processing or storage capacity of this system.
• Speed: processing demand is forecast to exceed the ability of this system to complete transactions or batches in the time required, eg, overnight processing or trade reporting.
• Reliability: system does not meet reliability requirements or require excessive support.
• Functionality: additional functionality has been requested or is recommended.
• Support: system supplier is withdrawing support for the product leaving the firm exposed in the event of problems.
• Compliance: a change to internal or external regulation, or compliance policy, or law requires changes to be made.
• Security: system security needs to be improved.
• Competition: a competitor has gained advantage and work is required to retain or increase business supported by that system.
• Cost: another system offers a more cost-effective solution so replacement and decommissioning is recommended.

Different categories will apply to each firm so the list should be developed individually and preferably tied into existing project classifications which the firm may already use.

To indicate priority, hotspots are rated on a scale. Using five levels gives a good balance between resolution and relative importance, with ratings described as follows:

• Priority 1 - critical work with a major impact on the firm if not completed
• Priority 2 - high priority with a material impact on the firm if not completed
• Priority 3 - recommended as delivers net positive benefit or risk reduction to the firm
• Priority 4 - highly desirable but no major benefit or impact associated with it
• Priority 5 - optional, nice to have but not essential
• Unrated - no work proposed

The systems map also shows where the same system appears in multiple processes and how a hotspot associated with it could impact several parts of the business. The map can now be colour-coded to highlight hotspots and indicate their priority and classification - for example, "1A" represents a critical capacity issue and "2F" is a high priority compliance issue.

"Systems Map" diagram:

Having now created the systems map, identified the hotspots, classified and prioritised them, the budget prioritisation grid can be derived from it and used as the basis for establishing or revising the IT budget.

The prioritisation grid is an extract of the systems map showing only the hotspots mapped against priority and classification. This summary should also include cost estimates so IT and the business can discuss the budget in context. Project overviews should also be developed at this stage to support the prioritisation grid.

"Prioritisation Grid" diagram:

We now have the systems map, prioritisation grid, project overviews and cost estimates, which is everything we need to hold structured discussions with the firm about what discretionary work to include in the budget and why, as well as what to leave out. Impact, cost and risk can be considered in light of the whole systems landscape and will give both IT and the firm the best chance of developing a sound investment portfolio. If the systems map is maintained and refined over time, it becomes increasingly efficient to repeat the process in subsequent years. Work-in-progress can also be prioritised along with new work which may well lead to cancellation of existing projects if they no longer make the grade.

Clearly this activity deals with only one aspect of the budget process, but I hope it illustrates the importance of the discretionary investment prioritisation stage. It shows a simple, low-cost technique to structure discussions and demonstrate to the business that IT is both transparent in its approach and also making sound decisions, aligned directly with business objectives. And just as important, it gives the business an insight into the whole IT landscape and what's not being put forward for attention this year. Good luck!

Prioritisation process summary:

1. Identify key business processes supported by IT
2. Map key IT systems to these processes in the sequence they are used
3. Identify, classify and prioritise systems hotspots
4. Summarise hotspots into a prioritisation grid and produce project descriptions
5. Develop cost estimates for each hotspot and add into the prioritisation grid
6. Review systems map and hotspot grid with the business to agree priorities and budget
7. Document the final agreement and report against progress for each budgeted hotspot