How to Set Team and Project Budgets

Why 'just be sensible' is not a budget

Most small businesses start without formal budgets because, for a while, the founder can hold the whole picture in their head and simply say yes or no to each purchase as it comes up. That works until it doesn't — usually around the point where a second or third person starts spending independently, or a project runs long enough that nobody can remember what was originally supposed to be spent versus what has actually gone out the door.

'Just be sensible' is not a budget because it gives no number to check against. Two reasonable people can disagree in good faith about what sensible means for a given purchase, and without a figure to test decisions against, every purchase becomes a fresh negotiation. A budget replaces that negotiation with a simple check: is this within the number we agreed, yes or no.

This matters more for projects than for ongoing roles, because a project has a natural end point where the money either worked or it didn't — and if nobody set a number at the start, there is no way to say afterwards whether the project was run well or simply happened to end before anyone noticed the cost.

Building a budget from the work, not from a guess

The most reliable way to set a budget is to build it up from the actual tasks and costs involved, rather than picking a round number that feels roughly right. List every cost category the role, team or project genuinely needs — people time if it's being costed, materials, software, subcontractors, travel — and put a realistic figure against each one based on quotes, past spend, or a specific estimate, not a guess pulled from the air.

Once you have that bottom-up total, compare it honestly against what the business can actually afford to commit, given everything else it is already spending on. If the bottom-up figure is higher than what you can afford, the answer is to reduce scope or extend the timeline, not to quietly shrink the number and hope the gap closes itself — an underfunded budget is worse than no budget, because it creates the appearance of control while guaranteeing an overrun.

For an ongoing team or role budget rather than a one-off project, base the starting figure on the last two to three months of actual spend in that category where you have the data, adjusted for anything you know is about to change, such as a new hire or a planned increase in activity.

1. List every real cost category the budget needs to cover.
2. Put a specific, sourced figure against each category — a quote, a past invoice, or a clear estimate.
3. Sum the categories to get the bottom-up total.
4. Compare the total against what the business can actually afford right now.
5. If it doesn't fit, cut scope or extend timeline — don't just lower the number.
6. Add a stated contingency line, typically a percentage of the total, for the unplanned.

Naming an owner, even when several people spend

Every budget needs exactly one named owner, even if three or four people spend against it day to day. The owner's job is not to approve every individual purchase — that's what your approval thresholds are for — but to know at any point roughly where the budget stands, to flag drift early, and to be the person who answers for the total at the end of the period.

Without a named owner, a shared budget tends to become nobody's responsibility in practice. Each person spending against it reasonably assumes someone else is tracking the total, and by the time anyone actually checks, the gap between plan and reality can be substantial and hard to explain, simply because nobody was watching it continuously.

For a very small team, the owner is often the founder by default, which is fine as a starting point, but it's worth deliberately handing ownership of at least one budget to someone else as the team grows — partly to build their judgement, and partly because a founder holding every budget in their head is exactly the bottleneck this whole hub is trying to help you avoid.

Setting a sensible period and contingency

Match the budget period to the nature of the spend. Ongoing role or team budgets usually work best reviewed monthly against a rolling annual figure, since that catches drift quickly without creating unnecessary admin. Project budgets should run for the life of the project, with checkpoints at natural milestones rather than only at the very end, so that an overrun is visible while there's still time to do something about it.

Build a contingency line into every project budget from the outset, stated as an explicit percentage — commonly somewhere in the region of 10 to 20% depending on how well-understood the work is — rather than treating any unplanned cost as a crisis that requires renegotiating the whole budget. A stated contingency also stops the awkward pattern where every small overrun gets waved through individually because there's no formal mechanism to absorb it.

Once the contingency is used up, treat that as a genuine trigger to stop and reassess rather than continuing to quietly absorb further overruns, since a contingency that never runs out was probably set too generously, and one that's exhausted in week one was set too tight.

The monthly variance check

A budget only works if something compares plan to actual on a regular rhythm, and for most small teams monthly is the right cadence — frequent enough to catch a problem early, infrequent enough not to become its own admin burden. The check itself is simple: pull actual spend for the period, set it against the budgeted figure category by category, and flag anything that's meaningfully over or under.

Being over budget in one category isn't automatically a problem if another category is correspondingly under, but it is worth understanding why before assuming it nets out — sometimes an underspend in one area is masking a delay that will cost more later, not a genuine saving. Ask the budget owner to bring a one-line explanation for anything more than about 10-15% off plan, rather than letting variance accumulate silently month after month.

Keep the check itself short. A five-minute look at a simple spreadsheet or your accounting tool's budget-versus-actual view, done consistently every month, beats an elaborate quarterly review that keeps slipping because it feels like too much work to start.

A budget nobody checks against actual spend is a wish, not a control. The check is what makes the number mean anything.

When to revise a budget mid-period

Budgets should be revisited when something genuinely changes — a project's scope shifts, a new person joins a team, a supplier's pricing moves materially — but not simply because actual spend is running ahead of plan in a way that hasn't yet been explained. Revising the number too readily removes the discipline the budget was meant to provide; the point of a variance is to prompt a conversation about why, not to be smoothed away by moving the target.

When a revision is genuinely warranted, document what changed and why, using the same rigour as when the budget was first set — a new bottom-up figure, checked against affordability, not a round-number adjustment made in the moment. This keeps the budget a living, credible tool rather than something that drifts upward every time it's tested.

Budgets and approval thresholds work together

A budget answers 'how much in total, over what period' while an approval threshold answers 'does this individual purchase need sign-off before it happens' — the two are related but distinct, and small teams sometimes confuse them. It's entirely possible to be well within budget for the month and still need approval for a single large purchase, because the threshold is about the size of one transaction, not the state of the overall total.

Set your approval thresholds first, as your general spending policy, and then let each named budget sit underneath that framework rather than inventing a separate approval process per budget. This keeps the system simple: one set of rules about who can approve what, applied consistently across every team and project budget you run.

Common mistakes with small-team budgets

The most common mistake is setting a budget once at the start of the year and never looking at it again until year end, by which point the gap between plan and reality is too large to do anything constructive about. The second most common is setting a budget so tight that any real-world variation immediately breaks it, which trains people to work around the budget rather than through it. The third is giving a budget to a team without giving anyone clear ownership of tracking it, which guarantees that nobody notices drift until it's substantial.

• Setting it once and never reviewing it against actual spend.
• Setting it too tightly, with no realistic contingency for the unplanned.
• Giving a team a number with no named owner responsible for tracking it.
• Confusing a budget total with an approval threshold for individual purchases.
• Revising the number every time it's challenged rather than investigating variance first.