Project Burn Rate: Will Time and Money Last? (+ Calculator)

Okay, imagine this. Your team is doing a project for a client, and it’s week 6. The sprint board looks fine, the client is happy, and Slack’s been pretty quiet. Cool, cool.

Then you decide to message your PM, just to check how everything’s going: “Hey, just a quick question. How many hours have we actually put into this so far?”

Silence.

Your PM probably rolled their eyes, opened the timesheet, and saw half of it empty. Someone logged “8h - dev” 5 days in a row. That major bug fix from Wednesday is nowhere to be found.

They’re dripping in cold sweat and decide to ping everyone on the team, “Hey, what did you work on, and for how long? Need the answer ASAP.”

At the end of the day, you get a response: “It’s somewhere between 400 and 450 hours, give or take.”

Give or take, ha? On a project with a fixed budget. Great…

If this imagined scenario feels familiar, this article is for you. I wanna talk about project burn rate: how fast your team's hours are disappearing, and how to know if you have enough time (and money) left to actually reach launch.

Here’s what we’ll go through:

• First, what burn rate actually means in project management and why it matters, backed by some real research and real-life examples.
• Then, we’ll cover what makes the burn rate spike, the project burn rate formula, and how to calculate it step by step, hours first, then money. I’ll give you an example with real numbers.
• Then, we’ll get to the project burn rate calculator. It’s free, and you can use it whenever you like.
• At the end, we’ll talk about how honest time tracking (I know, bear with me!) can actually help.

If you’re up for all of it, let’s freakin’ go. We’ve got no time to waste.

Key Takeaways:

• Project burn rate is how quickly a team uses its hours and budget, usually measured per week or month.
• Hours burn is the leading indicator, and money burn is the lagging one, so watching hours lets you spot problems early and act.
• Large IT projects ran 45% over budget on average, according to a McKinsey and University of Oxford study of more than 5,000 projects.
• Burn rate spikes mainly because of scope creep, endless revision rounds, underestimation, context switching, and adding people late to a project.
• To calculate it, divide hours logged by time elapsed, compare it with the planned rate, then check the burn ratio, runway, and forecast.
• Every burn rate formula depends on accurate hours, so tracking time, ideally automatically, is what makes the numbers reliable.

What is a burn rate in project management?

Project burn rate is the speed at which your team’s time and the budget attached to it get used up. You might also hear it called the monthly burn rate when it’s tracked in monthly chunks.

The term became common in startup land, especially during the dot-com era, when founders tracked how fast they were spending investor cash. Project teams later adopted it, since every project has a finite budget of time and a deadline.

Usually measured per week or per month, it answers 3 major questions:

1. How fast are we using up our hours?
2. How many hours do we have left?
3. Will we reach the finish line before we run out?

The main focus of this article is on the hours; once you know the hours, the money part is just a multiplication away.

Hours burn vs. money burn

There are 2 ways to look at burn, and the order matters:

• Hours burn is how many hours your team uses per week or month. This is the leading indicator.
• Money burn is those hours multiplied by what they cost you, plus any other spend (tools, freelancers, and licenses). This is the lagging indicator, and shows up later, in invoices and margins.

If you only watch money, you see the problem after it happened. If you watch hours, you see it while you can still do something about it.

(Startup folks also like to split burn into gross and net. Gross is everything you spend; net is spend minus incoming revenue. For most agency and dev projects, the client pays a set budget, so gross is the one you should care about.)

Why project burn rate matters

Project burn rate is the one metric that determines whether a project is profitable.

It matters, because:

#1 Projects overrun (a lot!)

According to a McKinsey and University of Oxford study of more than 5,000 IT projects, large IT projects ran 45% over budget on average and 7% over time, while delivering 56% less value than predicted. Yep.

Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and published their findings in Harvard Business Review. They found that the average overrun was modest, but a surprising share of projects were “black swans” with massive cost blowouts.

And the Project Management Institute keeps measuring the damage. Its 2018 Pulse of the Profession report found that organizations waste 9.9% of every dollar invested due to poor project performance. That’s down from 13.5% in 2013, which is great, but still roughly $99 million lost for every $1 billion spent.

Now, a real-life example you can relate to.

Remember that infamous rollout of Healthcare.gov in the US? The site launched in 2013 and struggled badly. A GAO report found that it was built without effective planning or oversight, and by mid-2014 the cost had reached roughly $840 million. Estimated costs for the federal marketplace alone had jumped from $56 million to more than $209 million, driven in part by constantly changing requirements.

It’s a giant example, but the same logic applies to a 10-person agency project. Scope grows, hours pile up, and nobody checks to see what’s going on with the project until it’s too late.

So, yes, projects do go south. When they do, they cost more than you can imagine, and since most of the cost is people’s time, most of the drift starts as extra hours.

#2 It protects your margins

For agencies, burn rate is basically margin: if your hours burn outruns the plan, your profit shrinks. And the people doing the extra hours feel it too, through late evenings, rushed sprints, and overall chaos.

A clear burn rate lets you say, “Here’s where we are, and here’s what we can still deliver”.

#3 It gives you time to act

This is the best part about project burn rate—it’s like a smoke-detecting system. It allows you to see the problem in week 2, while you still have options. You can cut scope, renegotiate, add budget, or shift priorities.

What makes the burn rate spike

Well, it’s mostly this:

• Scope creep. Like adding one tiny thing 40 times in a row.
• Revision loops. Like those feedback rounds that never seem to end.
• Underestimation. It happens because of the planning fallacy; we’re all way too optimistic about how long things take.
• Context switching. Like jumping between 3 projects and losing focus time.
• Adding people late. Brooks’s law literally says adding people to a late project delays it even longer.
• Bench time and idle gaps. Like people waiting on approvals.
• Meetings that could’ve been an email. No further explanation needed.

Almost all of these are time-related problems. They have nothing to do with how (un)competent or (un)professional your team is.

The project burn rate formula

Alright, it’s time we do some basic math.

We’ll start with hours, because that’s what your team actually controls, and then we’ll turn those hours into money.

Step 1: Set your planned hours burn rate

First, you need to know how many hours the project is supposed to take; that’s your hours budget. It comes from your estimate, your sprint plan, or the hours you sold to the client.

Say you budgeted 2,400 hours for a 6-month project: 2,400 ÷ 6 = 400 hours per month. This is the speed you should be burning at.

Step 2: Calculate your actual hours burn rate

This is the project burn rate formula in its simplest form.

If your team has logged 960 hours over 2 months, that’s 960 ÷ 2 = 480 hours per month. That’s your monthly burn rate, measured in hours, and if you compare it with the plan above, you can already see the gap.

The same math applies for teams:

Step 3: Check hours used vs. time used

Two quick percentages tell you a lot:

Then divide one by the other to get the burn ratio:

And here’s how to read the results:

• Around 1.0 means you’re doing well and keeping up the pace.
• Above 1.0 means you’re burning faster than planned.
• Below 1.0 means you’re running lean or maybe falling behind on delivery.

Step 4: Calculate your runway & forecast

Runway tells you how long your hours will last, and the forecast tells you where you’ll end up if nothing changes.

Step 5: Calculate the labor cost burn

Now it’s time to dive into the financial side. Before you can convert hours into euros, you need to know what an hour of your team’s time costs you.

For example, if a developer costs you €6,000 per month (salary + overhead) and works about 160 hours, that’s €6,000 ÷ 160 = €37.50 per hour.

Now, keep in mind this is your cost rate, not your billable rate. The billable rate is what you charge the client, but burn rate is about what the project costs you, so keep these 2 separate.

If your team has different seniority levels, use a blended rate; that’s the average cost across everyone on the project.

Then, it’s time to calculate the labor cost burn:

If we use the previous example, that’s 480 hours × €37.50 = €18,000 per month.

Step 6: Calculate the total project burn & money burn rate

This is the last step, so add anything else the project spends on, like software licenses, stock assets, freelancers, and cloud hosting.

If you had €1,000 in tools and hosting that month, your total burn for the month is €19,000.

And the money part just follows the hours. Multiply your hours by the cost rate from Step 5, add your non-labor costs like tools, freelancers, and hosting as simple line items, and you’ve got the financial picture.

How to quickly calculate project burn rate step by step (using an example)

Let’s do a quick calculation from start to finish. Hours first, money second.

Here’s the imaginary base for this calculation:

• The project is a 6-month product build for a client.
• Hours budget: 2,400 hours.
• Money budget: €90,000 (that’s 2,400 hours × €37.50 blended cost rate), excluding tools, hosting, and freelancers.
• Planned burn rate: 2,400 ÷ 6 = 400 hours per month (or €15,000 per month)

You run a team of 4 people. Each logs about 120 hours per month on this project.

Part 1: The hours

Actual monthly hours burn: 4 people × 120 hours = 480 hours per month.

You already see a gap: you planned 400 hours per month, but you’re burning 480.

After 2 months, you’ve logged: 480 × 2 = 960 hours.

Hours used % = 960 ÷ 2,400 = 40%

Time used % = 2 months ÷ 6 months = 33%

Meaning, you’ve burned 40% of your hours but only 33% of your time, which is a bit of a red flag. 🚩 Your burn ratio = 40% ÷ 33% = 1.2, which is above 1.

Runway: 

Remaining hours = 2,400 − 960 = 1,440

1,440 ÷ 480 = 3 months of runway, but you still need 4 months to finish, meaning you’re a month short.

Forecast:

960 + (480 × 4) = 2,880 hours, which is 480 hours over the plan, and a 20% overrun. Luckily, you caught it at the end of month 2, not month 6.

Part 2: The money

Okay, let’s translate those hours into euros. To keep the example simple, we’re looking at labor cost only. In a real project, you’d add non-labor costs like software, hosting, and freelancers on top, as we did in Step 6.

Actual monthly labor burn: 480 hours × €37.50 = €18,000 per month (vs. €15,000 planned)

Spent so far: 960 hours × €37.50 = €36,000

Budget used %: €36,000 ÷ €90,000 = 40% (Same 40% as the hours view; told ya it was the same story just in euros.)

Projected total cost: €36,000 + (€18,000 × 4) = €108,000, which is €18,000 over budget. Same 20% overrun.

And that’s it, you’re done.

Now I want you to pay attention to just one thing: money numbers echo the hours, meaning if you fix the hours, the money fixes itself.

That’s why I’m so big on time tracking.

The importance of time tracking when calculating project burn rate

Every formula above depends on one input: hours worked.

If your hours are wrong, your burn rate, runway, and forecast will be too. Your money numbers are wrong, too.

So, it’s clear that you need to track time.

Now, the gag is that time tracking only works if people actually do it. Most devs and designers hate time tracking because it breaks flow, and feels like surveillance.

But what if it doesn’t have to be like that? What if you and your team could just work and time tracks itself?

May I present to you Memtime?

Memtime was built for silent, undetectable tracking. And it has no monitoring features!

It’s our automatic time tracker that runs quietly in the background and records what you work on: apps, docs, websites, files, even calls. It lays it all out in a visual timeline, so you can see what you worked on all day, down to the minute.

It lets you work on multiple projects, switch contexts constantly, and manage clients with different budgets and rules. It follows your workflow like it’s nothing.

Here’s what Memtime can do for your burn rate:

• It captures the hours you’d forget. Because Memtime records your activity as it happens, the ghost minutes show up. That 11-minute context switch or 5-minute client call? All on your timeline, so you end up with a true picture of where your hours actually went. And honest hours mean an honest burn rate.
• It’s built around privacy. Memtime is designed so your data stays under your control, with tracking data stored locally on your device. It’s there to help you reconstruct your own day, not allow a client to micromanage you. That’s why it’s so easy to adopt. 🙂
• Your job is to review and assign (if needed), not track time. At the end of the day or week, you just look at your timeline and assign time entries to the right projects. You can also automate this step so Memtime does it for you. Then, those hours can go straight into the project burn rate calculator.

Your hours are burning whether you watch them or not. 🔥

With Memtime, you can quickly see where they’re going. No timers, no spreadsheets.

Don’t be afraid of the project burn rate

Burn rate is just a number that tells you how fast your team’s hours are going out the door. That’s it. There are no monsters behind it. (Okay, maybe scope creep, context switching, underestimation, etc., but we’ve covered them all.)

The math is friendly. Hours logged, divided by time elapsed. You compare it with the plan, check your runway. Done.

The only tricky part is the input. If your hours are woo-woo, your burn rate is woo-woo, too. So track them, preferably in a way that doesn’t need you to remember anything you did at any point.

And if you want to see your own numbers right now, play with the calculator. It’s free, fast, and won’t judge your numbers.

Now, go forth, comrade, and burn responsibly.

FAQs

What is a good burn rate for a project?

A good burn rate is one that matches your plan. In this article’s method, a burn ratio of around 1.0 means you’re keeping pace with the plan. A ratio above 1.0 means you’re burning faster than planned, while a ratio below 1.0 means you’re running lean or possibly falling behind on delivery. There’s no universal number, because the right pace depends on your hours budget and project length.

What is the difference between gross burn and net burn?

Gross burn is everything you spend over a period. Net burn is that spend minus the money coming in. Startups often track both, since they rely on investor funding rather than a fixed client budget. For most agency and development projects, the client pays a set budget, so gross burn is the one to watch.

How do you calculate runway in project management?

Runway tells you how long your remaining hours will last at the current pace. Divide your remaining hours by your current hours burn rate. For example, with 1,440 hours left and a burn rate of 480 hours per month, you have 3 months of runway. If the project needs 4 more months, you’re a month short.

How do you convert project burn rate from hours to money?

First, calculate your hourly cost rate by dividing a team member’s total monthly cost by their monthly working hours. Then multiply the hours worked by that rate to get your labor cost burn. Add non-labor costs like software, freelancers, and hosting to get the total project burn. Use your cost rate rather than your billable rate, since burn rate measures what the project costs you.

What should you do if your project is burning too fast?

Act as early as possible, while you still have options. You can cut scope, renegotiate with the client, add budget, or shift priorities. Catching the overrun at the end of month 2 instead of month 6 leaves much more room to adjust. Regular hour tracking makes this early warning possible.

How often should you track project burn rate?

Burn rate is usually measured per week or per month. Weekly checks catch problems sooner, while monthly checks suit longer projects with steady workloads. The right frequency depends on how quickly your project can change course. Whatever you choose, accurate logged hours matter more than the schedule, since every formula depends on them.