openskills.info
Course Preview

IT Budgeting and Capital Planning

IT budgeting and capital planning turns technology costs, risks, capacity, and expected benefits into an approved portfolio and a funding plan. It covers both the annual budget and the continuing decisions to fund, change, pause, or retire investments.

itFinOps, procurement, and technology economics

Don't Panic — IT Budgeting and Capital Planning

An IT budget is the authorized financial shape of a technology portfolio. It is not a ceremonial spreadsheet in which every request has been declared vital and the total has somehow become a strategy. Capital planning is the continuing work of deciding what enters that portfolio, what keeps its funding, and what leaves when the evidence changes.

Start with demand. Current services need money to run. Products need capacity to grow. Old systems need replacing. Security and contractual obligations arrive with dates attached, because apparently risk also keeps a calendar. Put these requests in one demand register with a sponsor, outcome, timing, lifecycle cost, dependencies, and the consequence of delay.

The first useful distinction is between budget, forecast, and actual. The budget says what may be spent. The forecast says what is now expected. Actuals say what has happened. If the forecast is repeatedly overwritten by the budget, the organization has not achieved alignment. It has misplaced a warning signal.

The second distinction is between economic cost and accounting classification. CapEx records eligible cost as an asset under the applicable policy. OpEx is recognized as incurred. Neither label changes the cash leaving the organization, and a project named “transformation” does not become an asset through confidence alone. Finance decides the policy. Technology preserves the evidence about phase, labor, contracts, and timing.

Selection happens across the portfolio, not one enthusiastic business case at a time. Minimum gates ask whether a proposal has an accountable sponsor, feasible alternatives, a lifecycle estimate, risk analysis, and a measurable outcome. Scores can then expose trade-offs. They cannot manufacture scarce database engineers, which is inconvenient but fairly consistent behavior from arithmetic.

Large uncertain investments need stage gates. Discovery buys evidence about the problem. A pilot tests feasibility, adoption, and operating cost. Scale follows when the case survives contact with reality. Each gate needs authority to continue, change, pause, or stop. A gate that can only admire a status report is a meeting.

Keep operating services inside the loop. Licenses, infrastructure, support, and security often renew more quietly than new projects, even when they consume most of the money. Continuation should be a decision supported by service cost, demand, risk, and outcome evidence.

The Intro explains the whole operating model. Use the Cheatsheet when building a demand record, formula, score, or gate. The Practice Reference keeps the financial calculations close at hand. The Exercise demonstrates the classic discovery that a portfolio can fit the money and still not fit the people. Field Notes is where the polite diagrams give way to the costs of getting the decisions wrong.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources