Overtime Analysis: The 85-95% Rule, 80/20 Rule & More

• A cost performance index between 85-95% isn't automatically bad - it's a yellow flag that means watch closely, not stop the project.
• The document you update when a budget changes is the cost baseline, and that update only happens through a formal change request, not a casual plan edit.
• Running overtime consistently in smaller doses almost always beats saving it all up for a crunch at the end - cost, morale, and cash flow all come out ahead.
• The 80/20 rule works for overtime the same way it works for bugs or sales: a small number of tasks or roles usually drive most of your overruns.
• For a growth-stage company, CPI and SPI aren't PM-exam trivia - they're early warning signals for your cash forecast, three to four weeks before the invoice hits your bank account.

1. What's the real downside of using overtime to handle swings in production?

If you've seen the multiple-choice question asking which of these is a disadvantage of varying production through overtime - higher labor cost, inability to meet demand spikes, or fatigued workers losing productivity - the honest answer is all of the above. Overtime solves a short-term capacity problem but creates three separate costs at once, and most operators only budget for the first one.

The labor premium is the obvious cost: time-and-a-half or double-time adds up fast, and it compounds with payroll taxes and workers' comp, since both are usually calculated as a percentage of wages paid. The second cost is a ceiling problem. Overtime only gets you so much extra capacity from the people you already have. If demand jumps 30% and your team is already maxed out, overtime can't close that gap, and you're stuck missing orders or turning away revenue. The third cost is the one that sneaks up on you: fatigue. Tired workers make more mistakes, move slower, and get hurt more often, so the "extra hour" you're paying a premium for often produces less than a normal hour would.

That's why a one-off overtime push to hit a deadline is fine, but a pattern of overtime, week after week, is a sign your base staffing model is wrong. If you're consistently paying for hours four and five of productivity at premium rates, it's usually cheaper to hire.

2. What does a cost performance between 85-95% actually mean?

A cost performance index (CPI) between 85% and 95% means the project is running over budget but not yet in crisis - it's a caution zone where you tighten monitoring and dig into the cause before it gets worse, rather than an automatic stop-work signal.

CPI is calculated as earned value divided by actual cost: CPI = EV ÷ AC. A CPI of 0.67, for example, means you're only getting 67 cents of planned work for every dollar you actually spent ^[1]. A CPI of 1.0 means you're spending exactly what you planned. Most formal control bands treat 0.95 to 1.05 as green (on track), with yellow bands sitting just outside that - commonly 0.90 to 0.95 on the low side - and red below 0.90 or well above 1.10 ^[2]. A CPI sitting between 0.85 and 0.95, which is the "between 85-95%" range you'll see referenced in project cost control materials, straddles the yellow-to-red boundary: close enough to on-plan that you don't panic, far enough off that you don't ignore it either.

The smart move, as a few practitioners put it, isn't to calculate CPI after the fact and react - it's to set your acceptable band in advance and treat it as a control limit you check weekly, not a grade you get at the end ^[3]. For a growth-stage company, that band should be tighter on anything touching payroll, since labor overruns hit cash the fastest of any cost category.

3. How do you build the 17-week, $39,220 overtime variance example yourself?

Picture a 17-week implementation project budgeted at $39,220 in labor cost. The team runs on schedule through week 12, then starts adding overtime in week 13 to catch up on a slipping milestone, and keeps adding more through the final week. The resulting variance, and the CPI it produces, is a useful template you can rebuild with your own numbers.

Run the CPI calculation on the total: $39,220 ÷ $43,580 = 0.90, or 90%. That lands squarely in the 85-95% caution band. It's not a disaster - the project still got delivered - but it tells you something went wrong starting in week 13, and it's worth a root-cause conversation before the next project runs the same pattern.

The real value of building this table yourself isn't the final number. It's seeing exactly which weeks drove the overrun, which is the first step toward the fix in the next section.

4. What is the 80/20 rule for project managers, and how do you use it to cut overtime costs?

The 80/20 rule, or Pareto principle, says a small share of causes usually drives most of the effect - originally observed by economist Vilfredo Pareto, who noticed that roughly 20% of people owned about 80% of the land in Italy ^[4]. Applied to your overtime problem, it means a small number of tasks, roles, or vendors are probably generating most of your overruns, and finding them beats trying to fix everything at once.

One technology firm used its own bug-tracking data and found that a handful of modules were responsible for the bulk of its critical errors ^[4] - the same logic applies to overtime. Pull your labor data by task or department, and you'll usually find that two or three line items (a specific shift, a specific vendor's crew, one bottleneck machine) account for most of the premium pay. Fix those two or three things and you'll often erase most of the overrun, without touching the 80% of the project that was never the problem.

5. Which document do you adjust when your project budget changes?

When a project's budget changes, you update the cost baseline - the approved, time-phased version of the budget used as your comparison point for actual results - and that update only happens through a formal change control procedure, not an informal edit to a spreadsheet ^[5]. Adjusting the project plan or a status report doesn't count; the baseline is the document of record.

The scope baseline and schedule baseline work the same way - both can only be changed through formal change control, not a quiet revision ^[6]. The reason this matters for a $2M-$50M company isn't PMP trivia: if your finance team is forecasting cash off a budget that nobody formally updated, your cash forecast is wrong the moment the first change request gets approved and nobody tells accounting.

6. What are the three major components built during project planning?

The three big components worked out during project planning are the scope baseline, the schedule baseline, and the cost baseline - together they define what you're building, when, and for how much, and finance needs all three before it can forecast cash accurately.

Most overtime problems trace back to one of these being wrong at the start. If the schedule baseline assumed a crew size that was never realistic, overtime becomes the default fix by week three, and by week thirteen you're looking at the kind of variance table from section 3 above.

7. What are the three types of change requests, and when do you use each?

The three types of change requests are corrective action, preventive action, and defect repair - corrective action fixes performance that's already off track, preventive action heads off a problem before it happens, and defect repair fixes something that doesn't meet spec ^[7].

Tagging your overtime by which of these three categories it falls under is a small habit that pays off at budget review time. Corrective-action overtime tells you something broke. Preventive-action overtime tells you demand is growing. Defect-repair overtime tells you quality slipped. Lump them all into one "overtime" line and you lose that signal completely.

8. Allowing overtime throughout vs. cramming it at the end - which actually saves money?

Spreading overtime evenly across a project beats saving it all for a crunch at the end, on cost, morale, and cash flow. A team that works a little extra each week stays rested and the premium cost is predictable; a team that gets slammed with mandatory overtime in the final two weeks burns out, makes more errors, and often costs more in total despite "only" working overtime at the end.

Consider a 17-week project like the one above, run two different ways. In Scenario A, the project manager allows overtime consistently throughout the project - a modest two to four hours a week from week 4 onward - rather than always adding it in a panic near the finish. In Scenario B, the manager holds the line on a standard 40-hour week until week 13, then mandates heavy overtime for the last month to hit the deadline.

These adjustments might have improved morale, kept costs in check, and avoided the rework that ate into the schedule gains the overtime was supposed to buy. That's the core lesson from comparing the two approaches: allowing overtime consistently throughout the project, rather than always adding it in a late scramble, tends to cost less in total even though it starts earlier and looks less dramatic on a weekly report.

On top of the labor math, there's a real cash timing issue. Overtime pay usually lands in the very next payroll cycle, so a late-project overtime spike hits your bank account right when the project is also consuming working capital for final materials, travel, or subcontractor payouts. Spreading the cost out avoids stacking those two cash drains in the same week.

9. How do you turn overtime and EVM data into something your CFO actually uses?

You turn project-management metrics into finance-useful signals by tying CPI and schedule performance index (SPI) directly to your weekly cash forecast, not just a PM status report, and by setting a clear variance threshold that automatically triggers a conversation with leadership.

Here's a simple checklist for when a project's budget variance needs a closer look, and when it needs to go to leadership or the board:

• CPI drops below 0.95 for two consecutive reporting periods, not just one bad week
• Overtime as a share of total labor cost exceeds your department's target (commonly 5-8% in manufacturing, 3-5% in services) for more than a month
• A single change request would move the cost baseline more than 10% from the original approved budget
• Overtime is concentrated in the final third of a project's timeline rather than spread across it
• Cash forecast shows payroll cycles where overtime-driven costs land in the same week as a large vendor payment or debt service

If two or more of these are true at once, that's when it stops being a department-level scheduling issue and becomes a finance conversation. A rough rule of thumb: if the variance would change your cash runway by more than two weeks, the board should hear about it before the next scheduled update, not at the quarterly meeting.

Industry-wide, this gap between PM theory and financial follow-through is common and costly: on average, organizations still waste close to a tenth of every project dollar on poor performance, even after years of improvement ^[8], and a large share of projects finish over budget or late in the first place ^[9]. Closing that gap is less about better PM software and more about making sure finance sees the same variance data the project manager sees, in the same week. If you'd rather not build this tracking by hand, Dear CFO builds it from your QuickBooks, pulling labor and overtime trends straight into your existing cash forecast.

Conclusion

Overtime analysis and earned value management look like separate disciplines, but they answer the same question from two angles: are you getting what you paid for, and can you still afford what's coming next. A CPI between 85% and 95% isn't a crisis, but it's a signal worth acting on before it becomes one. Spread overtime out instead of saving it for a crunch, know which document actually changes when your budget does, and tag your change requests so you can tell a staffing problem from a demand spike. None of this requires a PMP. It requires watching the same numbers every week and knowing which threshold means it's time to talk to the board.

FAQs

About the author

Ethan Lu

Partner, Phoenix Strategy Group

Ethan Lu is a Partner at Phoenix Strategy Group, where he works as a fractional CFO helping founder-led companies maximize their exit value. He currently oversees more than $200M in client enterprise value and has been part of multiple eight-figure exits. Before PSG he was an asset manager and investor for a San Diego family office, where he sat on the investment committee for more than $1B in assets. A data scientist by training, he holds a B.S. in Mathematics with a minor in Accounting from UC San Diego.

LinkedIn