Project budgeting is the work of turning a scope into a number somebody is willing to be held to. You estimate what each piece of work will cost, add money for the risks you can name, aggregate it into an approved cost baseline, and then track what actually happens against it. The finance team calls the result a budget. Project managers usually mean something slightly different by the word, and the gap between those two meanings causes more arguments than any other part of the job.
Here is the part worth getting right before anything else. A cost estimate, a cost baseline and a project budget are three different numbers, not three words for the same one. The estimate is what the work is expected to cost. The baseline is the estimate plus contingency for the risks you identified. The budget is the baseline plus a management reserve for the things nobody thought of. Different people control each layer. A page that treats them as synonyms will lead you to spend money you were not authorized to spend.
Key takeaways
- Estimate plus contingency reserve equals the cost baseline. Baseline plus management reserve equals the project budget. Three layers, three owners.
- The project manager can draw on contingency for a risk that actually happened. The management reserve belongs to the sponsor and needs a decision to release.
- Estimate accuracy is a function of how much you know, not how hard you try. An early number is honestly plus or minus half, and should be quoted as a range.
- A variance means nothing on its own. Spending 40 percent of the money is fine at 40 percent complete and alarming at 20 percent.
- Committed cost is the number that makes monthly budget reports lie. Money on a signed purchase order is gone whether or not the invoice has arrived.
Last updated August 2026.
What is project budgeting?
Project budgeting is the process of estimating what a project will cost, aggregating those estimates into an authorized spending limit, and controlling actual spend against that limit for the life of the project. It answers three questions in order: what will this cost, how much of that are we approving, and are we still inside it. In most organizations the same team does all three, which is why the boundaries between them blur.
It is distinct from budget management in the accounting sense, where a department gets an annual allocation and spends it down. Project budgets are bounded by a deliverable rather than by a calendar year, they usually cross fiscal boundaries, and they carry a scope that can legitimately change. That last point is the source of most of the difficulty. A department budget that overspends has a discipline problem. A project budget that overspends may have a discipline problem, or it may simply be delivering more than it was originally asked to deliver.
The three layers: estimate, cost baseline, project budget
This table is the whole topic in miniature. If you take one thing from this page, take this.
| Layer | What it contains | Who controls it | What releasing it requires |
|---|---|---|---|
| Cost estimate | The sum of all work package estimates: labor, vendors, licenses, infrastructure, travel | Project manager, built with the delivery team | Nothing. It is a calculation, not an authorization |
| Contingency reserve | Money set aside for identified risks, sized from the risk register | Project manager | A named risk from the register that has actually occurred, logged with the amount drawn |
| Cost baseline | Estimate plus contingency. The number performance is measured against | Approved by the sponsor or governance forum | This is the approved spending limit for normal delivery |
| Management reserve | Money for unknown unknowns: work nobody anticipated at all | Sponsor or the funding body, not the project manager | A formal request and a decision. Releasing it moves the baseline |
| Project budget | Cost baseline plus management reserve. The total funding committed | Sponsor, and usually finance | The number finance holds against the project code |
Swipe to see more →
Two practical consequences fall out of this. First, when someone asks "are we on budget", ask which number they mean. Performance against the baseline is the honest answer; performance against the total budget including management reserve flatters you until the reserve is gone. Second, drawing on contingency is a normal event that gets logged, while drawing on management reserve is a governance event that gets a decision. Teams that treat both as a single pot lose the early warning entirely, because the moment the reserve is touched is exactly when the sponsor most needs to hear about it.
Cost estimation methods, and how accurate each one really is
There is no method that produces a right answer early. What the methods differ in is how much information they consume and how wide the resulting range honestly is. Quote a single number early in a project and you have made a commitment you cannot support.
| Method | How it works | Effort | Honest accuracy | Use it when |
|---|---|---|---|---|
| Analogous | Take a completed similar project and adjust for size and difference | Hours | Roughly minus 25 to plus 75 percent | Idea stage, intake screening, ballpark for a pipeline decision |
| Parametric | Multiply a unit rate by a measured quantity: cost per user migrated, per store fitted, per interface built | Days, once you have the rate | Roughly minus 15 to plus 30 percent | Repeatable work where you have real historical rates |
| Three point (PERT) | Optimistic plus four times most likely plus pessimistic, divided by six | Days | Depends on inputs, but exposes the spread | Any line item with genuine uncertainty you want to make visible |
| Bottom up | Estimate every work package and roll the totals up | Weeks | Roughly minus 5 to plus 10 percent | Once scope is stable and you need the number you will be held to |
| Expert judgment | Ask people who have done this work before, ideally more than one, separately | Hours | Highly variable, and worse when they confer first | Sanity checking any of the above, never on its own |
Swipe to see more →
The ranges above are the reason a stage gated process exists at all. A ballpark estimate is fine for deciding whether an idea is worth investigating. It is not fine for approving funding. If your organization approves projects on analogous estimates and then holds delivery teams to them as if they were definitive, the problem is the process, not the estimators. Ask the people who built the number what method they used, and treat that as the accuracy label.
For labor, which is most of the cost on most projects, the number is really a resource question wearing a finance costume. You cannot cost the work until you can forecast the hours by role and apply a rate to each. Estimating in dollars directly, without a view of who does the work and for how long, is where the largest errors live.
How to build a project budget in seven steps
- Fix the scope you are costing. Write down what is in and what is explicitly out. An estimate without a scope statement attached is not an estimate, it is a guess with a decimal point.
- Break the work into packages small enough to estimate. If a package is too big to estimate confidently, it is too big. Split it until each piece is something a person can picture doing.
- Estimate each package, and record the method. Label every line with how it was produced. Six months later, when the number is challenged, that label is the only defense you have.
- Add the non obvious costs. Licenses beyond year one, environments, data migration, training, hypercare after go live, internal time from teams outside the project. These are the lines that get forgotten and then get called overspend.
- Size contingency from the risk register, not as a percentage. Take the risks with real probability and cost impact, multiply the two, and total them. If you must use a flat percentage, say out loud that it is arbitrary.
- Get the baseline approved, and record who approved it. The approval is what converts an estimate into a commitment. Without a named approver and a date you have no baseline to measure against.
- Set up tracking before the first dollar is spent. A project code, a way to see committed cost, and a monthly cycle. Retrofitting cost tracking three months in never fully works, because the early spend is already lost in general ledger lines nobody coded.
Step 5 is the one most teams skip. A flat 10 percent contingency on a project with three severe risks and a flat 10 percent on a project with none are both wrong. Sizing from the register also gives you something to say when finance asks why the number is what it is. If the risks are already scored for probability and impact, this step takes an afternoon rather than a debate.
What goes in a cost management plan
A cost management plan is the short document that says how money will be handled on this project: what gets measured, in what units, how precisely, and what happens when the numbers move. Most are copied from a template and never read. A useful one is about two pages and answers questions people will actually ask.
| Section | What it states | Test for a good entry |
|---|---|---|
| Units of measure | Labor in hours or days, materials in units, everything reported in one currency | Two people costing the same task would produce the same units without asking |
| Precision and rounding | Estimates rounded to the nearest thousand, reporting to the nearest hundred | Nobody is arguing about a 40 dollar difference in a 900,000 dollar project |
| Control thresholds | The variance percentage that triggers an explanation, and the one that triggers escalation | A number, not "significant variance". If it does not have a percent sign it is decoration |
| Rules of performance measurement | How completion is credited: milestone, percent complete, fixed formula | It removes the ability to claim 90 percent complete for three months running |
| Reporting format and cadence | What the cost section of the report contains and how often it appears | Matches the decision cycle of the people receiving it, not the finance close calendar by default |
| Funding limits | Approval authority by amount, and where money is drawn from at each level | A project manager can tell, without asking, whether they can approve a given invoice |
| Reserve rules | What contingency can be used for, who releases management reserve, how a drawdown is logged | A contingency drawdown names the risk from the register that occurred |
Swipe to see more →
The funding limits row is worth writing even if you write nothing else. Spending authority that lives only in somebody's head produces two failure modes at once: managers who sit on decisions they were entitled to make, and managers who commit money they were not. If spending authority is written down at the start, both disappear.
A filled project budget example
A nine month CRM replacement for a mid sized US distributor, roughly forty internal users, one integration partner. Numbers are illustrative but the structure and the arithmetic are the ones to copy.
| Line | Basis | Method | Amount |
|---|---|---|---|
| Internal delivery team | 3.5 FTE for 9 months at blended internal rate | Bottom up from the resource plan | 420,000 |
| Integration partner | Fixed price statement of work | Quoted | 310,000 |
| Software licenses, year one | 40 users, annual subscription | Parametric, cost per user | 96,000 |
| Data migration specialist | Time and materials, estimated 300 hours | Three point, wide spread | 75,000 |
| Environments and infrastructure | Dev, test and production for 9 months | Parametric | 48,000 |
| Training and adoption support | 6 sessions plus materials plus 4 weeks hypercare | Analogous, prior rollout | 40,000 |
| Cost estimate | Sum of work packages | 989,000 | |
| Contingency reserve | Sized from 6 register risks with probability times cost impact | Risk based | 89,000 |
| Cost baseline | Estimate plus contingency, approved 12 March | 1,078,000 | |
| Management reserve | 5 percent of baseline, held by the sponsor | Policy | 54,000 |
| Total project budget | Baseline plus management reserve | 1,132,000 |
Swipe to see more →
Notice what the table makes visible. The delivery team is 42 percent of the estimate, so a one month slip is not a schedule problem with a cost footnote, it is roughly 47,000 dollars. The data migration line was estimated three point because it is the least understood work, and that uncertainty is carried openly rather than buried in an average. And the contingency is 9 percent of the estimate because six specific risks came to that number, not because 10 percent is what people use.
Contingency reserve vs management reserve
| Contingency reserve | Management reserve | |
|---|---|---|
| Covers | Identified risks in the register | Unknown unknowns, work nobody anticipated |
| Sized from | Probability times cost impact, risk by risk | Organizational policy, commonly 5 to 10 percent of baseline |
| Inside the cost baseline | Yes | No |
| Inside the total budget | Yes | Yes |
| Controlled by | Project manager | Sponsor or funding body |
| Release requires | A logged drawdown against a risk that occurred | A formal request and a governance decision |
| Effect on the baseline | None, it was already in there | Releasing it increases the baseline |
Swipe to see more →
The discipline that makes contingency work is the drawdown log: date, amount, and the register line the money was spent against. Without it, contingency quietly becomes a slush fund that absorbs estimating errors, and by month six nobody can tell whether the project has a risk problem or an estimating problem. With it, you can say something genuinely useful at the halfway point, which is how much contingency is left against how much risk is still open.
Budget variance analysis month by month
A variance is the difference between what you planned to have spent and what you have actually spent, usually expressed as a percentage. On its own it tells you almost nothing, because it says how much money has left the building without saying how much work came back in. Spending 40 percent of the budget is excellent at 45 percent complete and a serious problem at 20 percent.
This is exactly what CPI and the forecast to complete exist to solve: they compare the value of work completed against the money spent, rather than comparing spend to a calendar. If you run anything more complex than a small project, learn that method rather than staring at raw spend curves. For everything else, a threshold policy in the cost management plan does most of the work.
| Variance against baseline | Status | Required response | Who is told |
|---|---|---|---|
| Within plus or minus 5 percent | Normal | Reported, no action | Standard monthly report |
| 5 to 10 percent over | Watch | Written explanation, cause identified, forecast to completion refreshed | Sponsor, in the monthly report |
| Over 10 percent | Escalate | Recovery plan with named actions, or a formal request to rebaseline | Governance forum, within the cycle |
| More than 10 percent under | Investigate | Check whether work is genuinely cheaper or simply has not started | Sponsor, in the monthly report |
| Forecast at completion over budget | Escalate regardless of current variance | Decision on scope, funding or stopping | Governance forum, immediately |
Swipe to see more →
The last two rows are the ones people leave out. An underspend is usually a schedule problem that has not been recognized yet, and it will convert into an overspend the moment the work actually starts. And the forecast matters more than the current position: a project 2 percent over at month four with a credible forecast 18 percent over at completion is in trouble now, not in month nine. Reporting the current variance while sitting on that forecast is the most common way an amber rating becomes a red one overnight.
Committed cost, the number monthly budget reports miss
Most cost reports show two numbers, budget and actuals, where actuals means invoices received and posted. That understates reality every single month. When you sign a statement of work for 310,000 dollars, that money is spent in every meaningful sense on the day you sign, even though the first invoice may be sixty days away. A report that ignores it shows a comfortable underspend right up until the invoices land together.
The fix is to track committed cost alongside actuals: money on signed purchase orders and contracts that has not yet been invoiced. Remaining budget is then the baseline minus actuals minus commitments, which is the only version of the number that is safe to make decisions on. The mechanics of doing that across a portfolio, and the reconciliation cadence that keeps it honest, are covered in the piece on committed cost and purchase orders.
Rolling project budgets into a portfolio view
A PMO does not need every line of every project budget. It needs the few numbers that support a portfolio decision, reported the same way by everyone, on the same cycle. Asking for more than this produces a data collection exercise that nobody can complete on time and nobody reads when they do.
| Level | What it needs | Why |
|---|---|---|
| Project manager | Every line, actuals, commitments, contingency remaining | To manage the work and see problems in the month they start |
| Program | Baseline, forecast at completion, variance, reserve position by project | To move money between projects inside the program before escalating |
| Portfolio and PMO | Approved budget, total forecast, variance against plan, spend to date as a percentage of both budget and completion | To see which projects will need more money, and where the funding would come from |
| Executive and finance | Total portfolio commitment against the annual envelope, plus the projects driving any change | To decide whether the portfolio still fits the money available this year |
Swipe to see more →
The percentage-of-completion column at portfolio level is the one that earns its keep. It converts a spread of unrelated projects into a single comparable signal, and it makes the projects that are burning money without producing anything visible in the first pass. That comparison belongs in the monthly report pack rather than in a separate finance report nobody in delivery ever sees.
Organizations funding long lived teams rather than discrete projects will find some of this awkward, and rightly so. There the unit of funding is a value stream with a guardrail, and the question shifts from "is this project on budget" to "is this investment still worth its run rate". That model is covered separately in funding value streams instead of projects, and it is a genuinely different discipline rather than a variation on this one.
Where project budgeting goes wrong
| Failure | What it looks like | What to do instead |
|---|---|---|
| Single number, no range | An early estimate becomes the commitment because it was the only figure written down | Quote a range with the method label attached until the scope is stable |
| Contingency as a slush fund | Reserve draining steadily with no drawdown log and no risks closed | Every drawdown names a register risk that occurred, with the amount |
| Ignoring commitments | Healthy underspend for five months, then a cliff when the invoices arrive | Report baseline minus actuals minus commitments as remaining budget |
| Scope creep charged as overspend | Team blamed for a variance caused by work that was added later | Every scope addition carries a cost impact through change control before it starts |
| Forecast equals budget | The forecast at completion is copied from the budget every month until month eight | Rebuild the forecast from remaining work, not from remaining budget |
| No internal labor in the number | Only external spend is tracked, so the real cost is invisible | Cost internal time at a rate, even when finance does not require it |
| Rebaselining to hide the problem | The baseline moves quietly whenever the variance gets uncomfortable | Rebaselining is a governance decision with a recorded reason, and the old baseline is kept |
Swipe to see more →
The scope creep row is the one that damages teams. A budget is a commitment to deliver a defined scope for a defined amount, so anything added afterwards should move the number. When a scope addition is approved without a cost impact, the variance appears anyway and lands on whoever is holding the project. Running additions through a formally approved change with a cost line attached is not bureaucracy, it is the mechanism that keeps the original number meaningful. Where that discipline is absent, read the piece on how uncontrolled scope arrives, because the budget symptom is downstream of it.
Frequently asked questions
How do you create a project budget?
Fix the scope, break the work into packages, estimate each one and record the method used, add the costs people forget such as licenses and hypercare, size contingency from the risk register, then get the total approved by a named person on a named date. Set up cost tracking before spending starts, not after.
What is the difference between a cost estimate and a cost baseline?
The estimate is what the work is expected to cost. The cost baseline is that estimate plus contingency reserve, formally approved, and it is the number performance is measured against. An estimate is a calculation anybody can produce. A baseline exists only once somebody with authority has approved it.
What is included in a project budget?
The total project budget includes the cost estimate for all work packages, the contingency reserve for identified risks, and the management reserve for unknown unknowns. In practice that means labor, vendors and contracts, software licenses, infrastructure, training, travel, plus both reserves. Internal staff time belongs in it even when finance does not require the charge.
What is a cost management plan?
A cost management plan is a short document stating how money will be handled on the project: units of measure, rounding precision, the variance thresholds that trigger action, how completion is credited, reporting format and cadence, approval authority by amount, and the rules for using each reserve. Two pages is usually enough.
How accurate should a project budget be?
Accuracy depends on the estimating method and on how much is known. An analogous estimate at idea stage is honestly around minus 25 to plus 75 percent. A bottom up estimate on stable scope reaches roughly minus 5 to plus 10 percent. Holding a team to an early ballpark as if it were definitive is an organizational failure, not an estimating one.
Who approves a project budget?
The sponsor approves the cost baseline, usually with finance confirming the funding exists and a governance forum recording the decision. Above a threshold set by the organization, an investment committee or the steering group approves instead. Whoever it is, the approval needs a name and a date, because that is what converts an estimate into a commitment.
How often should a project budget be updated?
The baseline should change rarely and only through a recorded decision. The forecast at completion should be refreshed every reporting cycle, normally monthly, using remaining work rather than remaining budget. Actuals and commitments update continuously. Confusing these three is why some teams appear to rebaseline every month.
Can a cost baseline be changed?
Yes, through change control or by releasing management reserve, and both are governance decisions with a recorded reason. Keep the original baseline alongside the new one. A project that has rebaselined three times and shows a 2 percent variance against the latest one is not performing well, and only the history makes that visible.
What is the difference between cost management and budget management?
Cost management is the whole discipline: planning, estimating, budgeting and controlling. Budget management is the narrower activity of tracking spend against an approved limit. In project settings the terms are used interchangeably, but if someone distinguishes them, budgeting is the setting of the number and cost management is everything around it.
What is estimate at completion?
Estimate at completion, or EAC, is the forecast of what the project will finally cost given performance so far. The simplest version divides the total budget by the cost performance index. It matters more than the current variance, because a project can be on budget today and clearly heading over by a wide margin at finish.
What is a good budget variance percentage?
Most organizations treat plus or minus 5 percent as normal, 5 to 10 percent as requiring a written explanation, and more than 10 percent as an escalation. The right thresholds depend on project size and risk appetite. What matters more than the number is that it is written in the cost management plan in advance, rather than argued about after the fact.
Why do project budgets go over?
The common causes are estimating on unstable scope, scope added later without a cost impact, forgotten cost lines such as licenses beyond year one and post go live support, internal labor never costed, and forecasts copied from the budget instead of rebuilt from remaining work. Genuine surprises are a smaller share than most post project reviews assume.
If you are building the funding case rather than managing an approved one, the cost side of that argument belongs in the approved business case, and the forum that signs it off is usually the group that owns the decision. Both determine the number you will spend the next nine months defending.