Burn Rate

Definition

Burn rate is the amount of money — or, in agile, capacity — that a project consumes per unit of time. On a capital job it is usually reported as dollars per week or per month; on an agile programme it is usually story points completed per iteration or engineering hours booked against an epic. Two flavours are common: gross burn (total spend) and net burn (spend minus revenue or value delivered). Whichever flavour you use, the burn rate answers one question faster than any earned-value report: are we running out of money before we run out of scope?

Why Burn Rate Matters

Traditional cost reporting lags. By the time an EVM curve turns, the money has already been spent and the invoices are already in the accounts payable queue. Burn rate is a leading indicator: it tells you the slope before the point is on the chart. Every experienced project controls manager watches burn rate first and cost variance second.

How to Calculate It

• Cost burn rate = actual cost incurred in a period ÷ number of periods.
• Effort burn rate = hours booked in a period ÷ number of periods.
• Runway = remaining budget ÷ current burn rate — the number of periods you can continue before the money runs out at today's pace.

Always calculate burn against a rolling window — the last four weeks is a good default. A single-period snapshot is noisy; a cumulative average smooths away the very signal you are trying to see.

Real-World Construction Example

A design-build contractor on a $180 million water treatment plant tracked weekly burn during the mechanical fit-out. Planned burn was $2.1 million per week. For three consecutive weeks, actual burn ran $2.7 million per week — a 28% overrun. The commercial manager modelled the runway: at that pace the remaining budget would be exhausted six weeks before mechanical completion. The trigger prompted a mid-week working session that traced the overrun to double-shift welding crews the field superintendent had authorised without a formal change order. The team rebased the crew count, recovered $1.4 million of the projected overrun, and — critically — caught the problem eight weeks before it would have shown up on the monthly cost report.

Real-World IT / Agile Example

A payments platform team was chartered to deliver a compliance epic in six iterations. By iteration three they had completed 42 of a planned 108 story points — a burn rate of 14 points per iteration against a plan of 18. Extrapolating, the epic would need eight iterations, not six. Instead of hiding the slip until iteration five, the team surfaced the burn trend at the next steering committee, negotiated a scope split into a mandatory core and a deferred second phase, and delivered the core on the original date. The visible burn line was what made the conversation possible.

Best Practices

• Track burn against a plan, not in isolation — the delta matters, not the absolute number.
• Use a rolling four-week (or four-iteration) average to smooth noise.
• Publish burn weekly. Monthly is too late for a burn signal.
• Separate committed cost (POs raised) from incurred cost (invoices approved); commitment burn leads incurred burn by two to eight weeks depending on payment terms.
• Overlay burn against remaining scope, not just remaining budget — VAC and runway make the picture complete.

Common Mistakes

• Reporting burn without a plan line — the number is meaningless without a reference.
• Using a single-week snapshot; noise is mistaken for signal and provokes bad decisions.
• Ignoring commitment burn and reacting only when invoices land — you lose the eight-week head start.
• Treating burn rate as a finance metric owned by accounting rather than a delivery metric owned by the project.
• Confusing effort burn with progress; hours booked ≠ value delivered.

Expert Tips

• Chart burn against three lines, not one: plan, actual, and forecast. The forecast is the honest one.
• Watch the slope, not the point. A single high week is noise; three high weeks in a row is a trend.
• Publish the runway number. "Six weeks of budget left at current pace" gets attention that a percentage variance does not.
• Reconcile burn with the SPI and CPI weekly. The three tell a consistent story or you have a data problem.
• Do not react to a single overshoot. Wait for the second period, but start the diagnostic on the first.

Practical Lessons Learned

• The projects that finish on budget are almost always the projects that watched burn weekly from the first month, not the projects with the tightest change control at the end.
• Commitment burn is the earliest possible warning; teams that only watch incurred burn are always two months behind the truth.
• The single best conversation-starter with an executive sponsor is a runway number — it converts abstract variance into a concrete date.

Key Takeaways

• Burn rate is the leading indicator of cost or effort drift.
• Always report burn against a plan, over a rolling window.
• Track both committed and incurred burn; the former leads the latter by weeks.
• Convert burn into runway to make the number board-ready.
• Cross-check with EVM indices weekly for internal consistency.

Related Encyclopedia Entries

• Earned Value Management
• Variance at Completion
• Cost Performance Index
• Estimate at Completion
• Velocity

Related Research Articles, Case Studies & Tools

• Burn Rate & Runway Calculator
• Project Controls Academy: Cost Control
• Cost-overrun recovery case studies
• Leading indicators in project cost control