You Probably Don't Know Which of Your Projects Lose Money

Here's a question most service businesses can't answer: which of your projects last year made the most money per hour, and which made the least? Not which invoices were largest — which ones were actually worth the time they consumed. Most people have a vague feeling about this, usually based on how a project felt, and the feeling turns out to be unreliable in a specific and expensive way: the projects that feel profitable are the ones with big invoices, and the ones that actually are profitable are often much smaller jobs that went smoothly and quickly.

The gap exists because revenue is measured and time isn't. You know exactly what every client paid, because it's on an invoice. You have only an impression of what each one cost you, because nobody tracked the hours, the revisions, the meetings, the chasing, and the general overhead of dealing with that particular client. So the visible number is compared against an invisible one, and the comparison is decided by whichever number you can see — which is why businesses so often pursue more of exactly the work that's quietly draining them.

The consequences compound. Without this information, you price new work by guessing, you can't tell which client types or project types are worth pursuing, and you may be actively growing the part of your business that loses money — taking on more of the large, prestigious, complicated projects because they look like success while the modest, efficient work that actually sustains you gets treated as filler. Businesses can be busy, growing, and quietly getting poorer, and this is usually how.

The fix is unglamorous and genuinely simple: track your time roughly, compare it against what you were paid, and look at the result. You don't need accounting sophistication or expensive software — you need a few weeks of honest data, which is enough to reveal patterns most people find genuinely surprising. Here's how to do it and what to do with what you find.

Key Takeaways

• Revenue is visible; cost isn't. You know what every client paid and only guess at what they consumed, so the comparison defaults to the number you can see.
• Big projects often aren't the profitable ones. Large invoices frequently come with disproportionate hours, meetings, and revisions that quietly destroy the effective rate.
• Track everything, not just the "real" work. Meetings, revisions, admin, and chasing are project costs, and excluding them is what makes projects look better than they are.
• Effective hourly rate is the number that matters. What you were paid divided by all the time it consumed — comparable across every project regardless of size or pricing model.
• A few weeks of data changes decisions. You don't need perfect records, just enough to see which work is worth pursuing and which needs repricing or declining.

Track the Time, Roughly Is Fine

The whole exercise depends on knowing where your hours actually go, and the good news is that rough data is sufficient. You're not building a billing system; you're looking for patterns, and patterns show up clearly even in imprecise records. Noting roughly how long you spent on each project each day is enough to reveal that one client consumes three times what another does, which is the kind of finding that changes decisions.

What matters more than precision is completeness — specifically, tracking everything the project consumed rather than only the work you think of as the work. That means including client meetings and calls, time spent reading and responding to messages, revisions and rework, project admin, invoicing and chasing payment, and the general overhead of managing that relationship. These are the hours people habitually exclude, and excluding them is exactly what makes unprofitable projects appear fine, because the difference between a good client and a draining one usually lives entirely in this category.

The practical approach is whatever you'll actually maintain. A time-tracking app is convenient and a simple note at the end of each day works nearly as well, since the goal is a rough allocation rather than a precise ledger. The failure mode to avoid is an elaborate system you abandon after two weeks, which is the same failure that kills over-designed content calendars and project systems — complexity makes maintenance harder, and data you stopped collecting tells you nothing. [BACKLINK PLACEHOLDER → suggestion: internal link to article #91, how to manage multiple projects / a simple system you maintain beats a sophisticated one you abandon]

Work Out the Effective Rate

Once you have hours, the calculation is simple: total paid, divided by total hours consumed. That gives you an effective hourly rate, and its usefulness is that it's comparable across everything — projects priced hourly, by project, or on retainer all reduce to the same number, which lets you compare a small quick job against a large complicated one directly.

The results are frequently uncomfortable. It's common to find that a large, impressive project with a substantial invoice produced a poor effective rate because it consumed enormous time in meetings, revisions, and coordination — while a modest job that ran smoothly delivered several times the hourly return. Since the first looks like success and the second looks like small work, businesses often respond to this reality by pursuing more of the first, which is precisely backwards.

Two refinements make the picture more accurate. First, remember that not all of your working time is billable — a substantial share goes to finding work, proposals, admin, and unpaid overhead — so an effective rate on paid projects isn't your actual income per working hour, and you need it to be meaningfully above your floor rather than merely equal to it. [BACKLINK PLACEHOLDER → suggestion: internal link to article #83, how to price your services / calculating your floor using realistic billable hours] Second, include the direct costs a project incurred — licences, assets, subcontractors, anything you paid out — since a project with high external costs is less profitable than its invoice suggests.

Read the Patterns, Not Just the Projects

Individual project numbers are useful; the patterns across them are where the real value is. Once you have a handful of projects measured, group them and look for what the good and bad ones have in common — because the goal isn't to judge past projects but to make better decisions about future ones.

The groupings worth examining are usually client, project type, and size. By client, you'll often find that one or two consume disproportionate time relative to what they pay, which is exactly the information you need for decisions about pricing, boundaries, or whether to continue at all. By project type, you may find that a particular kind of work is consistently more efficient — often the work you've done many times, where experience has made you fast — while another kind consistently overruns. And by size, many small businesses discover that mid-sized work outperforms both the tiny jobs, where fixed overhead per project dominates, and the largest ones, where coordination costs escalate.

Look for the specific causes too, because they're usually actionable. Projects that overrun typically do so for identifiable reasons: unclear briefs producing rework, excessive revision rounds, scope that expanded without repricing, or clients requiring far more meetings than average. Each of those has a fix — clearer briefs, defined revision limits, explicit scope, fewer meetings — so the analysis usually surfaces process improvements rather than just a verdict on which clients to drop. [BACKLINK PLACEHOLDER → suggestion: internal link to article #96, how to write a project brief / vague briefs are one of the most common causes of overrun]

Act on What You Find

Data changes nothing until it changes decisions, and there are usually four available responses. Reprice: if a client or project type consistently returns a poor rate, price that work higher, since you now have concrete evidence of what it actually costs rather than an optimistic guess. Change the process: where overruns have identifiable causes, fix those — tighter briefs, capped revisions, fewer meetings, clearer scope — which often converts a marginal project type into a good one. Pursue more of what works: knowing which work is genuinely efficient tells you what to aim your marketing and your selection at. Decline: some work is consistently unprofitable and not fixable, and knowing which lets you say no with evidence rather than reluctance.

That last option is where this analysis is most valuable, because it converts a vague discomfort into a decision. It's much easier to end or reprice a relationship when you can see that it returns a fraction of what your other work does, and much harder to keep telling yourself that a large invoice justifies whatever it consumes. The honest arithmetic is usually what turns "I should probably do something about this client" into actually doing it. [BACKLINK PLACEHOLDER → suggestion: internal link to article #90, how to end a client relationship professionally / the honest cost arithmetic that makes the decision possible]

Use judgment alongside the numbers, though. Some low-rate projects are worth keeping for reasons the calculation doesn't capture: work that leads reliably to better work, a client whose name genuinely opens doors, a project that builds a capability you want, or work you simply value doing. The point isn't to optimise everything to the highest effective rate — it's to make those trade-offs knowingly rather than accidentally. A low-margin project you've chosen deliberately is fine; a low-margin project you believed was your best work is the problem.