Project economics & loss control
Which of your projects is losing money, and since when
A fixed-price project loses its margin in small decisions made while the work is live: an engineer added for a fortnight, a change accepted without a change order, a review that sat for a week. Finance sees the total at the end of the quarter, when nothing can be done. If you run many projects at once, we forecast that loss per project while there is still time to act, and we put a number on what acting is worth.
Play with the idea in the margin-at-risk calculator, or see a full sample audit ↝
The decision
Where the margin goes
Project margin rarely leaks in one place. It leaks across four decisions, each of whose cost is small enough to ignore on the day, and the portfolio total at year end is not.
-
Which projects are drifting?
Cost-to-complete and probability of loss, per project, refreshed as the work moves rather than at the end of the period.
-
Which to bid, and at what floor?
A minimum acceptable price that reflects the uncertainty in the effort. Last quarter’s average is the number it replaces.
-
How to staff and sequence?
Allocate scarce skills across projects to protect margin and delivery. Filling utilisation is the easy part and usually the wrong one.
-
What to renegotiate, and when?
Distinguish an execution problem from an unrealistic plan, a customer delay, or scope that grew unpriced.
Why it matters
Why the accounts find out last
Late visibility
By the time a P&L turns negative, the staffing and scope decisions that caused it were made months earlier and cannot be unmade. The accounts are accurate, and they are too late by about a quarter.
Hidden interactions
Scope growth, rework and a slow review each look minor in the week they happen. Together they move the whole cost distribution of a project, and nobody sees the three of them on the same page.
One loss pays for the fix
In a portfolio of parallel fixed-price work, one avoided loss is usually worth more than a year of measuring for it. That is the arithmetic that pays for the audit.
How we approach it
What we do about it
A single number for cost-to-complete hides the risk, because the risk is in how wide the range is. So we forecast the whole range for each project, refresh it as the work moves, and rank what a manager can still do about the bad end of it.
For the owner
- A per-project p50/p75/p90 cost-at-completion and a probability of direct loss.
- A decomposition of where margin is going: scope growth, rework, staffing mix, customer-created delay.
- The interventions still available, ranked, and the ones already foreclosed.
For the technical reader
- Lognormal accelerated-failure-time completion model, fit with MCMC, checked with R-hat and effective-sample-size diagnostics.
- Dependency DAG and finite-worker capacity constraints so forecasts stay physically feasible.
- Scope-growth and rework decomposition, and staffing and sequencing as a constrained optimisation with risk-adjusted (CVaR) objectives.
- Calibration is reported (interval coverage, pinball loss) and compared against a simple baseline before anything is trusted.
What we need to see
Engineering activity (Git, issues, CI), a project/plan system, and enough cost and contract context to build a baseline. Where a baseline was never recorded, establishing one is the first deliverable. A forecast cannot repair data that does not exist.
Where to start
Where to start
A Decision Opportunity Audit runs on one project or a slice of your portfolio, establishes the baseline and the economic stakes, and ends with a clear recommendation. Sometimes that recommendation is that no system is needed. If the value is there, a proof of value tests it against that baseline before anything is built.
The loop
- 1. Baseline & economic stakes
- 2. Forecast & loss probability per project
- 3. Intervention shortlist, ranked
- 4. Measured outcome vs. the baseline
The research behind it
The method, published
When this fits
- Multiple simultaneous fixed-price, capped or milestone projects.
- A sponsor close enough to change staffing, scope or pricing.
- Engineering and project data that can be connected.
When it does not
- A single project, or work too small to justify a system.
- No route to cost, effort or contract data.
- Nobody in a position to act on the forecast while it still matters.
FAQ
Questions about project economics
How early can you tell a project is losing money?
Usually months before the accounts do. We forecast the cost to complete and the probability of a loss for each project, and we refresh the forecast as the work moves, without waiting for the period to close. The point is to surface a drifting project while a manager can still change staffing, scope or the price. Once the P&L has turned negative those levers are gone, and a forecast delivered then is a post-mortem with a confidence interval.
What data do you need to start?
Engineering activity such as Git, issues and CI, a project or plan system, and enough cost and contract context to build a baseline. Where a baseline was never recorded, establishing one is the first deliverable. A forecast cannot repair data that does not exist.
What do we get?
A per-project p50, p75 and p90 cost-at-completion and a probability of direct loss. A decomposition of where the margin is going: scope growth, rework, staffing mix, customer-created delay. And the interventions still available, ranked, alongside the ones already foreclosed.
What if the audit finds nothing worth fixing?
Then you have paid a fixed fee to learn that your current practice is already close to good enough, and that is cheaper than any other way of learning it. The audit is allowed to reach that conclusion, and it does in a fair share of cases.
Do you build a platform straight away?
No. We start with an audit on one project or a slice of the portfolio. If the value is there, a proof of value tests the method against your own baseline. Only after that is anything built. Each step is paid for separately, so the invoice follows the evidence and never runs ahead of it.
How do you know the forecast can be trusted?
Calibration is reported, interval coverage and pinball loss, and compared against a simple baseline before anything is relied on. A model that cannot beat a simple baseline on your own history is not trusted just because it is more sophisticated.
Start with the decision
Bring us one project
One project, or a slice of the portfolio. A short audit run by a partner will say where the margin is going and whether a system to watch it is worth what it would cost. The fee is fixed before we start.