from estimates to a budget

A budget is what happens when the time and effort estimates attached to each WBS work package get a dollar sign in front of them. Bottom-up estimating — costing each work package individually and summing up — is generally far more accurate than guessing a total for the whole project up front, because it forces every piece of scope to be priced instead of relying on a single gut-feel number.
Two cost categories and one accounting distinction come up in almost every project budget: direct vs. indirect costs, and CAPEX vs. OPEX.

direct vs. indirect costs

Direct costs can be traced to this specific project — the salaries of people working on it, a contractor hired specifically for it, software licenses bought just for it, cloud spend the project itself generates.
Indirect costs (overhead) are shared across many projects at once and can't be cleanly attributed to just one — office space, IT support, shared platform infrastructure, HR and finance functions. These are usually allocated to a project as a percentage of direct costs (e.g. "add 15% for overhead") rather than itemized, because tracking the exact overhead consumed by one project among dozens isn't practical.

capex vs. opex

CAPEX (capital expenditure) buys something with lasting value beyond the current period — new servers, office equipment, a building. It's capitalized on the balance sheet and depreciated over time rather than expensed all at once.
OPEX (operational expenditure) covers the recurring cost of running things day to day — salaries, cloud hosting bills, subscriptions, rent. It's expensed in the period it's incurred.
This distinction matters for more than accounting trivia: a project migrating from owned data-center hardware to a cloud provider is, financially, converting a CAPEX cost into an OPEX one — which changes who approves the spend, how it shows up in the budget, and sometimes whether the project even needs the same level of up-front sign-off.

the cost baseline and reserves

Summing every work package's cost produces the project's raw cost estimate. Spread across the schedule over time, it becomes the cost baseline — the approved, time-phased budget that actual spend gets measured against, often visualized as an S-curve (spending starts slow, ramps up during peak execution, tapers off at close).
Two kinds of reserve sit on top of the baseline, and mixing them up is a common mistake:
  • Contingency reserve — covers known risks already identified in the risk register (see risk management). Owned and spent by the project manager without needing new approval, since it's already accounted for in the approved budget.
  • Management reserve — covers unknown risks, the "unknown unknowns" that couldn't be anticipated. Held above the project budget by senior management, and using it requires going back for approval — it's not the PM's to spend freely.

a short example

A company migrating an internal app from on-prem servers to a cloud provider budgets direct costs for the engineers' time and cloud credits consumed during the migration itself, plus an indirect-cost allocation for the shared platform team that reviews the security setup. The old on-prem servers being retired were a sunk CAPEX cost from years earlier; the new ongoing cloud hosting bill is OPEX going forward. A contingency reserve covers the already-identified risk that the legacy database export takes longer than expected; a request to management reserve would only be needed if, say, the cloud provider had an unplanned regional outage during cutover.

practical notes

Budget overruns are more often caused by scope creep — new work quietly added after the baseline was approved — than by bad initial estimates. A tight change-control process protects the budget as much as accurate costing does.
Track actual spend against the baseline regularly, not just at project close. A budget that's 40% overspent at the 30% mark is a very different problem than the same number discovered after the project has already finished.

related topics

reference