A consultancy: project margins visible by day eleven, not day sixty
A boutique strategy consultancy in central London was discovering project overruns at month-end. By then the overrun had happened twice and the partners were apologising to clients.
The reading
Twenty-two consultants, four partners, project engagements running from six weeks to nine months. The firm billed on fixed-fee and time-and-materials in roughly equal measure, which meant that profitability on any given project depended on consultant utilisation holding to plan.
It rarely did. The firm discovered overruns at month-end, when the finance manager produced a project P&L spreadsheet from the time-recording export. By then the project had typically been over budget for three weeks, and the response was retrospective.
The senior partner's complaint was precise: "we find out we're losing money on a project at the point where it's too late to not lose money on it".
The month-end revelation
The time-recording system knew everything required. Consultant hours were logged daily, rates were known, project budgets were known. The problem was that the P&L was computed once a month, by hand, in a workbook maintained by the finance manager.
The partners wanted real-time visibility but had assumed it would require replacing the time-recording system. We disagreed; the data was there, the problem was the interval of computation.
- 40-60 live projects at any time
- Monthly P&L computation taking 2.5 days of finance time
- Overruns typically visible 3 weeks after onset
- No partner visibility between month-ends
- Project leads unable to see their own project's financial position
What we built
We wrote a small analytics layer that read the time-recording export every night and produced a per-project dashboard showing budget consumed, forecast completion, and current margin. The project lead saw their own project. The partners saw the whole book. The finance manager saw what she had always seen, but now by exception rather than reconstruction.
The technical choice: we did not build a predictive model. We built a straight-line projection from current burn rate, with the project lead able to override the completion estimate. We considered more sophisticated forecasting and discarded it because the project lead's judgement was almost always better than a model's, and the firm would trust a figure the project lead had endorsed.
The stack was deliberately boring: a nightly Python job, a Postgres data mart, a Metabase dashboard. The whole thing was built in six weeks.
The numbers at ninety days
| What | Before | After |
|---|---|---|
| Days from overrun onset to visibility | 21 | 1 |
| Finance manager monthly P&L hours | 20 | 3 |
| Projects closed within 5% of budget | 48% | 71% |
| Projects with active lead-level P&L view | 0 | 100% |
| Partner review cycle | Monthly | Weekly |
The interval of knowing
The partners' original framing was that they needed better forecasting. They did not. They needed the figures they already had, computed daily instead of monthly. The forecasting improved as a consequence, because the project leads were acting on current information instead of three-week-old information.
Shortening the interval of knowing is often the first and most useful intervention. We think of it as the system-first version of "measure twice, cut once": measure continuously, cut deliberately.