Why You Only Find Out a Project Lost Money After It's Over

Every agency has a version of this meeting. The quarter has closed, finance walks the leadership team through the numbers, and somewhere on slide six a project everyone remembers fondly turns out to have lost money. There is a silence, then the ritual questions — when did it go wrong? could we have seen it? — and then the honest, deflating answer: it went wrong in week five, and no, we couldn't have seen it, because the number that would have shown us didn't exist until today.

I sat through years of those meetings as a CTO, on both sides of the silence. What took me embarrassingly long to understand is that nobody in the room was failing. The delivery lead was managing what she could see. Finance was producing the close on schedule. The failure was structural: the only instrument that could measure the problem ran at a cadence that guaranteed it would always report too late.

The close is an accounting instrument, not a management one

The monthly close exists for good reasons — statutory reporting, VAT, payroll reconciliation, accruals. It is built to answer what happened last month, precisely and defensibly, and it does that well.

Per-project margin, at most agencies, is a byproduct of that process: once the month's costs are reconciled, someone allocates them across projects and produces a project profitability view. The number is real. But it inherits the cadence of the instrument that produced it — monthly, plus the two to four weeks the close itself takes. Best case, you learn a project's March margin in mid-April. If the damage happened in the first week of March, the news is six weeks old on arrival.

For managing live delivery, that is the wrong tool in the way a bank statement is the wrong speedometer. Nothing about it is inaccurate. Everything about it is late.

What lateness actually costs

The cost of a late number is the decisions that were taken without it. On a typical four-to-six-month build there are three windows where a live margin figure changes the outcome, and the monthly close misses all of them.

The staffing window. The most common way a project quietly dies is a staffing substitution in the early weeks — the mid-level developer the estimate assumed is unavailable, so a senior fills in "temporarily". At role rates nothing changed; at real, fully-loaded cost the burn rate just rose by a third. Caught in week three, this is a resourcing conversation. Reported in month four, it is a write-off with a backstory.

The scope window. Unbilled extras accumulate mid-project — the change requests that never got papered. While the project is running, each one is a live commercial conversation you could still have with the client. After it ships, they are a gift, retroactively wrapped.

The pricing window. Renewals and next-phase estimates are usually priced while the current phase is still in flight — which means they are priced on the believed margin, not the actual one. An agency that believes a project ran at 40% will price the renewal to repeat it. If the truth was 12%, the renewal locks the error in for another year. This one compounds: mis-measured projects become mispriced renewals become a mis-shaped book of work.

Add the three windows together and the pattern is stark: essentially every decision that determines a project's profitability is taken during the project, and the number those decisions need arrives after it. The close doesn't inform those decisions. It grades them.

"Review margins monthly" answers the wrong question

Ask how often an agency should review project profitability and the sensible-sounding answer is monthly, at the close, because that is when the number appears. But notice what that answer actually does: it lets the availability of the number dictate the cadence of the management, when it should be the other way around.

The right cadence question is: how often do you take decisions that a margin figure would change? For an agency with a portfolio in flight, the honest answer is weekly — staffing moves weekly, scope conversations happen weekly, and a delivery lead can course-correct within a sprint. So the review belongs in the weekly operating rhythm, next to the pipeline and the delivery board.

The reason almost nobody runs it weekly is not discipline. It is that you cannot review a number that does not exist yet. Reviewing is cheap; computing is the bottleneck — and as long as computing happens once a month inside the close, the weekly review is arithmetically impossible. Which is why the fix is not a better meeting. It is a number with a different birthday.

What changes when the number is continuous

Continuous here means something specific and unglamorous: every hour logged in Jira is costed the moment it lands — at the named person's fully-loaded rate, not a role average — overhead accrues onto the project pro-rata as the month runs, and the margin figure on the screen is today's, not last month's. The full anatomy of that calculation is its own piece; what matters here is what it does to the operating rhythm.

The week-five problem surfaces in week five. The senior-for-mid substitution shows up as a burn-rate step the same week it happens, while it is still a conversation rather than a confession. The renewal gets priced on the phase's actual margin to date. And the quarterly meeting changes character entirely — from discovering what happened to deciding what to do about a situation everyone has been watching evolve, with no ambush on slide six.

The role of finance shifts accordingly, from reconstruction to interpretation. I hired two CFOs before understanding this: when the pipeline that produces the number is manual, your most senior finance mind spends the month rebuilding the past. When the number produces itself, that same mind is finally free to work on pricing, capacity and the shape of the book — the work you actually hired them for. The close doesn't disappear; it goes back to its statutory job, and stops moonlighting, badly, as a management information system.

The inputs already exist

The objection I hear most is that continuous margin sounds like an implementation project. It isn't, and the reason is worth stating plainly: every input already exists in systems you already run. The hours are in Jira, logged by the team as they work. The true employee costs are in payroll. The overhead is in the management accounts. What is missing is not data — it is the join, computed more often than monthly.

That join is the entire product surface of Saldo: it reads your Jira worklogs read-only (no workflow changes, nothing written back), holds each person's fully-loaded cost in a ledger only leadership sees, allocates overhead pro-rata, and keeps the real margin of every live project on screen, every day. It is the instrument the week-five meeting always needed — the reference agency has run on it for two years, and the 15-minute demo will show it running on your own projects, not ours.

The shorter version: projects don't lose money at the close — that is merely where the loss is announced. They lose it in week five, in decision windows that a monthly number always misses. Move the number's birthday, and the post-mortem becomes a course correction.