Project Profitability Tracking: Catch Overruns Mid-Project, Not at the Post-Mortem

Aug 7, 2026

Written by Gregory Shein, CEO & Founder

Project Profitability Tracking: Catch Overruns Mid-Project, Not at the Post-Mortem

There are two kinds of agencies: the ones that find out a project lost money at the post-mortem, and the ones that find out in week three, while there's still time to do something about it. The difference isn't talent or estimation genius. It's whether budget-vs-actual is a live weekly number or a forensic exercise performed on a corpse.

This article is about project-level profitability: setting a budget you can track against, reading burn signals mid-flight, and intervening early. It's the delivery-side twin of tracking profitability by client — that lens tells you which relationships make money across months; this one tells you which engagements are bleeding right now, while the bleeding can still be stopped. You need both: a profitable client can hide a disastrous project, and vice versa.

Why post-mortems are worth so little

The classic agency ritual: project ships, someone tallies hours, the margin turns out to be 4% instead of the planned 35%, and the team writes a thoughtful retro document that changes nothing. The problem is timing. By the end of the project, 100% of the decisions that determined its margin have already been made. The valuable version of the same information — "we're trending 30% over" — was available in week three, and nobody was looking.

Mid-project, you have real options: rescope, invoke the change-request clause, swap a senior off routine tasks, reset client expectations, or renegotiate before goodwill (and leverage) evaporate. Post-mortem, you have one option: feel bad accurately.

The setup: what a trackable project needs

Four things, all created before kickoff:

  1. An hours budget, by phase or role. Not just "$20,000 fixed fee" — convert it: at a $100 target billable rate that's a 200-hour envelope, e.g. design 60, build 100, PM/QA 40.
  2. A cost baseline. Hours × loaded cost rate (salary × ~1.3 / 1,800 hours) tells you the margin floor. 200 hours at $55 loaded cost = $11,000 cost against $20,000 fee → 45% planned delivery margin.
  3. Time tracked to this project, dammit. Every hour, every person, including PM time and the "quick call" — same day, not reconstructed Friday.
  4. A scope boundary in writing. Overruns come in two species — bad estimates and scope creep — and your response differs, so you need to tell them apart. (Scope creep has its own playbook.)

The one metric: burn ratio

Every week, compute:

Burn ratio = % of hours consumed ÷ % of work completed
  • ≈ 1.0 — on track
  • 1.1–1.25 — yellow: investigate this week
  • > 1.25 — red: intervene, don't observe

"% complete" is the soft input; anchor it to deliverables (wireframes approved = design 50% done), never to gut feel or elapsed time. A project can be perfectly on schedule and catastrophically over-burned — schedule and margin are different diseases.

Worked example: the $20,000 site build

Fixed fee $20,000. Budget: 200 hours (design 60 / build 100 / PM+QA 40). Loaded cost $55/hour → planned cost $11,000, planned margin 45%. Six-week timeline. Watch the weekly numbers:

Week Hours (cum.) Budget consumed Work complete Burn ratio Projected hours Projected margin
1 28 14% 15% 0.93 187 49%
2 66 33% 28% 1.18 236 35%
3 112 56% 40% 1.40280 23%
4 (no action) 158 79% 55% 1.44 287 21%
6 (no action) ~265 133% 100% 1.33 265 27% → 4% real

The projection column is just budgeted hours × burn ratio. By week 3 the math is screaming: at a 1.40 burn, this 200-hour project lands around 280 hours — 80 hours over, $4,400 extra cost, margin collapsing from 45% to ~23%, and much worse once the inevitable end-of-project QA crunch and unbilled client calls pile on. (In the no-action timeline it shipped at 265 tracked hours plus untracked overtime — real margin near 4%.)

The week-3 intervention, in the timeline where someone was looking: the burn was diagnosed in 20 minutes — design ran 18 hours over because the client added a third homepage concept (scope creep, billable as a change request), and the build estimate missed a CMS migration wrinkle (estimate error, ours to eat). The agency invoiced a $2,400 change request for the extra concept, descoped a nice-to-have animation to claw back 15 build hours, and reset the review cadence. Final: 234 hours, $12,870 cost, $22,400 revenue — 43% margin instead of 4%. Same project, same team, same client. The only difference was when someone looked at the ratio.

Plug your own numbers into the project profitability calculator to see what a 20–40% hour overrun does to a fixed-fee margin — it's the fastest way to convince a skeptical partner that weekly tracking pays for itself.

The weekly project health check (copy this)

Fifteen minutes per project, every Monday. One row per project in a shared view:

Check Green Yellow Red
Burn ratio ≤ 1.05 1.05–1.25 > 1.25
Hours budget consumed < 70% 70–90% > 90% (work incomplete)
Untracked-time audit (hours logged vs expected) ±5% ±15% Gaps — data is lying
Scope changes this week Logged + priced Logged, unpriced Absorbed silently
Next invoicemilestoneScheduled This week, not sent Blocked/overdue

Rules of engagement: any red = a named owner and an action this week, not a note. Two consecutive yellows on burn = treat as red. And the meta-rule: if the untracked-time row is red, every other number is fiction — fix tracking first.

Estimate vs actual: the compounding payoff

Mid-project rescue is the headline benefit, but the quiet one compounds: every completed project gives you an estimate-vs-actual pair. After ten projects you know your multipliers — "discovery always runs 1.3×," "we chronically underquote QA by 20%" — and your quoting improves at the source. Agencies that track this stop losing margin at the estimate, which is where most of it is actually lost. That feedback loop, plus pricing and utilization, is covered in the wider system in The Complete Guide to Agency Profitability.

Why this usually fails (and the structural fix)

The method is trivially simple; the failure mode is always the same: hours live in a time tracker, budgets live in a spreadsheet, invoices live somewhere else, and assembling the burn ratio takes 40 minutes per project — so it happens for two weeks and dies. The fix is structural, not motivational: budgets, tracked hours (billable and not), scope tasks, and invoices on one project record, so budget-vs-actual is a column that's simply there every Monday. That's how Corcava treats projects inside the full agency lead-to-invoice workflow — the burn data assembles itself because it was never separated in the first place.

Stop doing autopsies on projects you could have savedstart a free 14-day Corcava trial (no credit card), set an hours budget on one live project, and watch the burn ratio this Monday. Or start smaller: run last quarter's ugliest project through the project profitability calculator and see what week 3 knew.