Ask a project-firm owner about margin and you'll get a confident number: "about 35%." Ask which projects produced it — which earned 50%, which lost 10% — and the confidence fades. The firm knows its blended average but not its composition. And a blended average is a hiding place: two projects at 50% can subsidize three at 15%, or one marquee engagement can mask four chronic losers. The decisions you make from the average — pricing, staffing, which work to pursue — are made blind.
Project-level margin is the antidote: the true margin on each engagement, computed the same way every time, reviewed on a rhythm. It's the metric that turns a portfolio of projects into a portfolio of decisions.
Why the overall number misleads
A monthly P&L aggregates everything — good projects, bad projects, bench time, overhead — into one net number. That's appropriate for reporting, but it's terrible for management. A 35% blended margin feels like a strategy ("we're a 35%-margin firm"), when it's really just an arithmetic outcome of whatever mix of work happened to close that month. Next quarter, the mix changes and the margin moves, and nobody can say why — because the average never explained itself in the first place.
Computing true project margin
Project margin is recognized revenue minus the project's true cost, expressed as a percentage of recognized revenue. Every term in that sentence has to be defined honestly, or the metric is fiction.
Recognized revenue is what the project has actually earned under your revenue policy — percent complete against contract value for fixed-fee work, billable amounts for time-and-materials — not what you've invoiced. Invoicing ahead of progress inflates project margin in the short term and guarantees a painful correction later; the WIP discipline keeps this honest.
Direct labor at loaded cost is the heart of the calculation, and the most common place firms get it wrong. Loaded cost means base pay plus payroll taxes, benefits, and PTO — the real cost of an hour of someone's time, which typically runs 25–40% above salary alone. Firms that cost projects at salary rates systematically understate cost and overstate margin, and the understatement is invisible because it's consistent. It also hides which staff are expensive: a senior engineer's loaded hour can cost triple a junior's.
Project-specific expenses — subcontractors, travel, materials, equipment, permits, any other cost that exists because the project exists — get charged directly. What's not charged is allocated overhead: no share of rent, no slice of the marketing budget, no fractional controller. Allocations feel rigorous but they're arbitrary, they argue about the allocation method forever, and they muddy the one question that matters: did this engagement, on its own direct economics, make money? Keep overhead below the line. Project margin is a direct-cost measure; overhead gets covered at the firm level.
The bench question
Every project firm carries bench time — paid hours that aren't assigned to billable work — and the question is where it goes in the math. The honest treatment: bench cost does not get spread across projects as an allocation. It gets measured separately, at the firm level, as its own line — because bench is a capacity decision, not a project decision.
Why this matters: if you load bench cost into project margins, every project's margin drops and nobody knows whether the problem is the projects or the staffing. Measured separately, the two stories separate cleanly. Projects can be healthy at 45% while bench eats 8 points at the firm level — which tells you the issue is sales pipeline and capacity planning, not pricing. Or projects can be at 20% with no bench at all — which tells you the issue is estimation and scope control, and hiring more salespeople won't fix it. One allocation hides the diagnosis; two clean numbers reveal it.
One rule of thumb: hours the project chose are project cost; hours the firm chose to keep are bench cost.
The decisions it changes
Once project-level margin is real, four decisions change.
Pricing. A history of true margins by project type is the most defensible basis for fees. If integration projects consistently land at 25% while advisory work lands at 50%, the next integration proposal gets priced differently — or scoped tighter. Firms that price from blended margin price every engagement as if it were the average engagement; firms that price from project history price each engagement for what it actually is.
Staffing. Margin by staffing mix reveals expensive habits — senior-heavy teams on thin-margin fixed fees, for instance — and moves staffing decisions from availability to economics.
Walking away from bad-fit work. The hardest decision. Some client types or service lines lose money consistently because the economics of the work don't fit the firm. Project-level margin makes the pattern undeniable, and "we don't do that kind of work anymore" becomes a financial decision, not a philosophical one.
Scope and change-order discipline. Projects rarely blow up in one event; they bleed through unbilled scope. When project margin is reviewed monthly with a forecast-at-completion, the bleed shows up early — budget burn outpacing progress, unbilled hours accumulating — while there's still a client conversation to have about scope. Without the metric, the same drift is discovered at closeout, when the only remaining move is the write-off.
Starting the discipline
The barrier is lower than most firms assume: actual hours by project from timesheets, a loaded-cost rate per person computed once a year, project expenses from the ledger, and one consistent revenue-recognition policy. One spreadsheet, updated monthly with the close, reviewed with project managers who can explain the flags. The first month's numbers will be uncomfortable — there's always a project everyone thought was profitable that isn't. That's not a flaw in the metric; it's the metric doing its job.
See the free project profitability tracker template — it structures the budget-versus-actual, loaded-cost, and margin-flag discipline described above into a monthly working file.