The post-launch look at the numbers
The site launched and the client is happy. At the monthly review, the owner runs a time report on the project. The design stage used much more time than quoted because the client had several stakeholders. Development ran over on an integration. Project management time, which was a small line in the quote, was several times larger in reality.
None of it is surprising once it is on screen. What stings is that the design overrun was visible halfway through, and could have been discussed with the client when the extra stakeholders appeared. Instead it was absorbed, like the one before it.
Why overruns are found late
- Time is logged against the project, not against the quoted stage or component.
- The quote lives in a proposal document and the time lives in a time tracker.
- Project managers are focused on deadlines and client happiness, not hours.
- Nobody looks at hours until invoicing or a monthly review.
- Raising an overrun with a client feels harder once the project is well advanced.
The information needed to spot an overrun exists every day of the project. It is simply never put side by side with the budget until it is too late to use it.
What late discovery costs
Overruns are absorbed rather than discussed. Opportunities to change scope, raise a change request or adjust the approach are missed. The studio does not learn which stages overrun, so future quotes repeat the mistake. Projects that looked profitable when sold end up making little.
The budget burn view we build
- The quote is broken into stage budgets in hours, taken from your proposal or estimator, and loaded against the project.
- Time entries from your tracker, such as Harvest, Toggl or your project tool, are mapped to stages through the task or a simple tag.
- For each stage the view shows hours used against budget, the stage's progress from your project tool, and a projected finish at the current rate.
- When a stage is projected to overrun beyond the tolerance you set, the project manager and owner are alerted with the reason, for example design hours rising while the stage is still open.
- The project manager records a decision: raise a change request, adjust the approach, or accept the overrun as a known cost.
- Approved change requests add budget to the stage, so the view stays accurate.
- At the end of the project, quote against actual per stage feeds your estimator for the next quote.
| Stage | What the view shows |
|---|---|
| Design | Hours used, progress, projected finish |
| Build | Same, plus integrations separately |
| Content entry | Hours against pages remaining |
| Project management | Running total against its line |
| Change requests | Added budget and hours used |
An overrun is not always wrong. Sometimes the right call is to absorb it for a good client. The view makes it a decision rather than a discovery.
Seeing it in the middle of the project
Midway through design, the project manager gets an alert: design hours are rising and the stage is still open, because the client has added two new stakeholders to the review. She raises it with the client, suggesting a consolidated review with a single approver or a change request for extra rounds. The client chooses the single approver. The stage finishes close to budget, and the project stays profitable.
Are budgets only checked after launch?
- Fixed-price projects are reviewed for hours only at the end.
- Time is not logged by stage.
- Overruns are absorbed rather than discussed with the client.
- Project management time is consistently higher than quoted.
- Nobody compares quotes with actuals to improve estimates.