The budget existed. Nobody was watching it
A project budget gets approved in a kickoff deck, everyone nods, and then nobody looks at it again until a quarterly review flags a number that's already badly wrong. In between, actuals lived in a separate spreadsheet that got updated whenever someone remembered, imported in one bulk batch a quarter later. By the time the overrun surfaces, it's not a course-correction anymore — it's a postmortem.
That's the real shape of weak budget management: not that a budget doesn't exist, but that nobody is comparing it to reality on any cadence shorter than "when it's already too late to fix."
Why the gap opens
The budget and the actuals live in different places. A number in a slide deck and a number in an accounting export don't reconcile themselves — someone has to do it manually, so it happens rarely.
There's no milestone-level breakdown. A single lump-sum project budget can't tell you which phase is bleeding. By the time the total looks wrong, you've lost the ability to trace it back to a specific release or workstream.
Variance review is quarterly, not weekly. A ten-percent overrun caught in week three is a conversation. The same overrun caught in month nine is a crisis with no time left to correct course.
A budget-to-milestone framework
1. Split the budget per release or milestone, not one lump sum for the whole project. A milestone-level budget is the only version that can actually tell you where money is going wrong.
2. Tag every finance entry with project and release. An entry with no release id is unauditable later — you can't trace it back to what it was actually for.
3. Pull weekly variance, not quarterly. Run finance_summary on a fixed weekly cadence. The point isn't the snapshot — it's catching a trend while there's still time to act on it.
4. Set a threshold that triggers a named review. A common default is 10% variance on any milestone bucket — past that line, someone specific has to look at it, not just note it.
5. Sync actuals on a real cadence, not a bulk quarterly import. Use import_finance_entries with a dry run first to catch tagging mistakes before they land in the ledger.
6. Forecast estimate-at-complete, not just spent-to-date. Spent-to-date tells you the past. An EAC forecast is what you actually need before a steering conversation about whether to cut scope or add budget.
7. Retro every budget miss, not just the successes. When a milestone comes in over budget, write the root cause in the wiki before the next planning cycle repeats it blind.
Anti-patterns
- Set the budget once and forget it — the single most common failure mode, and the cheapest to fix
- Confusing budget with burn — budget is the plan, burn is the cash actually spent; track both, they answer different questions
- No named owner for variance review — a threshold with nobody responsible for acting on it doesn't change anything
- Silent over-budget commitments — a scope addition approved verbally with no budget line attached shows up as a mystery overrun later
- Treating spent-to-date as a forecast — it isn't one; it's just where you've already been
How WKFGo helps
Project finance — a per-project ledger that holds the actual entries, not a spreadsheet living outside the tool.
finance_summary (MCP) — the weekly-cadence variance check, readable by a PM without pulling a raw export.
import_finance_entries (MCP) — syncing actuals from external accounting sources, with a dry run to catch tagging errors before they're committed.
Releases — natural budget buckets, so a milestone-level split has somewhere real to attach to.
A realistic weekly rhythm
Friday: pull finance_summary and check variance against each milestone's bucket — anything past the threshold gets a named owner and goes in the next steering conversation. Before any bulk import, dry-run it first. Before any steering meeting, pull an EAC forecast, not just spent-to-date. Flag any line item with no release id for follow-up before it becomes unauditable.
FAQ
Budget vs. burn — what's the actual difference? Budget is the plan; burn is what's actually being spent. Track both — a healthy burn rate against an unrealistic budget is still a problem.
How do we bring in actuals from an existing spreadsheet or accounting tool?
import_finance_entries, dry-run first to catch tagging issues, then commit.
Is this worth setting up for a small project? Yes, at minimum with a single release bucket — a lightweight version of this still beats finding out about an overrun in month nine.
What's the MCP side of this?
finance_summary for the weekly variance check, import_finance_entries for syncing actuals.
Start weekly variance tracking
Split your current project budget into milestone buckets, tag the last few finance entries with a release id, and run finance_summary this Friday. If any bucket is already past ten percent variance, that's this week's conversation — not next quarter's.