Stop losing support budget at year-end

Every year, many organisations see the same pattern. In one department, the support budget for a system goes unused and quietly lapses at the end of the financial year. In another, a platform runs short in the third quarter, and someone has to raise a new purchase request, wait for approval and explain why the original estimate was wrong.

Nobody planned it that way. It is what happens when support budgets are set department by department and project by project, and each one is managed on its own.

Why budgets per department fail

Support work is uneven by nature. A platform that is quiet for six months can need weeks of effort when a runtime reaches end of support, a new market is added or a security issue appears. Another platform may be busy at launch and calm afterwards. Fixing a separate budget for each system assumes that every platform will need exactly what was estimated a year earlier. That rarely happens.

The result is predictable:

• Unused effort lapses. Budget that was not needed in one place cannot move to where it is needed.
• Shortfalls need new approvals. A busy platform triggers a mid-year request, with delay and friction for the business.
• Nobody sees the whole picture. Each department sees its own hours, usually as a total in a monthly report. Nobody can say whether the overall spend is right, or what drove a busy month.

The reporting often makes it worse. Monthly slide decks list tickets and hours, but rarely explain them in terms a business owner can act on.

One pool instead of many budgets

The alternative is simple to describe: size the work honestly, then manage it as one pool across departments and platforms.

We have run this model with the regional headquarters of a Japanese automotive manufacturer, covering four platforms under one managed-services agreement. Four steps made it work.

1. Size the baseline honestly, platform by platform

Pooling is not a way to hide estimates. We first sized the baseline for each platform, activity by activity, with the calculation basis written down. The total became the yearly pool, and every department could see how its share was derived.

2. Log every hour against shared service categories

All work is logged against a small set of common categories: incidents, service requests, changes, monitoring, upgrades, reporting and governance. Using the same categories across platforms makes the work comparable, so it is clear whether a busy month was firefighting or planned improvement.

3. Report monthly, in business terms

Instead of a slide deck per platform, the regional HQ gets one dashboard, updated every month. It shows how the pool is being used against plan, which kinds of work drove each month, how the platforms are performing and how projects in progress are going. When a platform runs over, the report says why in plain language, in the same place as the numbers.

This also changed the regular meetings. With the facts already on one page, less time goes into preparing reports and more into deciding what to do next.

4. Agree up front what happens to any surplus

This is the step that changes the conversation. With the client, we agreed in advance that any surplus in the pool would not lapse. It is reinvested in new work, such as prototypes of AI-enabled tools, built in short Craft Sprints and chosen together with the regional HQ.

A run budget that used to be a cost to minimise becomes a source of funding for the next good idea.

What changes

• Effort moves to where it is needed during the year, without new purchase requests.
• Year-end waste disappears, because surplus has an agreed use.
• The business sees one budget and one story, not a set of separate timesheets.
• Meetings focus on decisions, not on reconciling reports.

Where to start

You do not need to restructure every contract at once. A practical first step is to take two or three platforms that the same team already supports, size their baseline openly, and report them together for one quarter. The pattern of under- and over-use usually becomes visible within a few months, and with it the case for pooling.

If your support budgets lapse in one place and run short in another, tell us about it. We can usually show what a shared pool would look like for your platforms in a short working session.