Which implementation projects are actually profitable once licences and rework are counted

Client profitability analysis ranks customers by the margin they leave behind rather than the revenue they bring in. Agencies have had a settled method for this for years. IT services firms borrowed it, and it fits badly, because the cost base under an implementation project looks nothing like the cost base under a campaign.

Working out which implementation projects are actually profitable means counting three things the invoice hides. Third-party licence cost. The margin a partner takes. Integration rework nobody logged as a cost. Revenue ranks your work one way, margin ranks it another, and the two lists rarely agree.

Your biggest invoice of the year lands in the bottom half of the second one.

Why does invoice value tell you so little?#

Because much of an implementation invoice is money passing straight through you.

Take a $400,000 ERP rollout. If $150,000 of it is vendor licences resold at a thin uplift, the headline number is inflated by money you never earned. Rank by invoice value and the rollout is your project of the year, but rank by what you kept and it can drop below a $90,000 integration build staffed entirely in house.

Agencies solved this years ago with one idea. Strip the pass-through, then measure. Parakeeto's customer profitability analysis method subtracts expenses such as ad spend, print budgets and stock footage from revenue to reach agency gross income. It then measures delivery margin against that figure, aiming for 60 to 70% on each client.

The idea transfers cleanly to IT services. The list of items you strip out does not.

What passes through an IT services project?#

Three cost categories, and only the first is obvious.

• Third-party licences and subscriptions. Resold at a fixed uplift, or passed through at cost to keep the client's procurement team comfortable. Either way, most of that money belongs to the vendor.
• Partner and reseller margin. Where you deliver under somebody else's paper, or bring a specialist partner into a bid, the paper holder takes a cut before anything reaches your books.
• Contracted specialist time. The integration architect you hired for six weeks costs what they cost. Treat that as a direct project expense, never as overhead spread thinly across the year.

Take all three out of the invoice. What remains is the money your own people earned. Call it delivered revenue, and put every margin percentage you calculate over that number rather than the headline one.

Partner margin deserves a second look, because it moves in both directions. When you hold the contract, you keep a cut of the specialist's work and your delivered revenue rises. When you sit underneath somebody else's paper, the reverse happens and nobody in your delivery team ever sees the number. Two projects doing identical technical work can land in very different places on margin purely on whose paper they ran under.

That is a commercial fact about the deal, not a verdict on the engineers, and unless you report it that way your delivery leads will decide the measurement is rigged and stop trusting it.

Nothing here is specific to IT services. Our guide to designing profitable projects for creative agencies makes the same case about margin targets set at scoping time rather than discovered at close-out. Different cost lines, same discipline.

Which implementation projects are actually profitable?#

The ones where delivered revenue covers loaded delivery cost and still carries the rework you never billed for.

The calculation runs to four lines.

1. Start with the invoice total, exactly as the client sees it.
2. Subtract licences, partner cuts and contracted specialist cost. What is left is delivered revenue.
3. Subtract your own team's booked hours at a loaded cost rate, employment cost included rather than salary alone.
4. Divide the remainder by delivered revenue.

The percentage that falls out is comparable across a six-week integration and an eighteen-month rollout. Invoice value never is.

Three things surface within an hour of doing this. Your biggest client is not your best one. Fixed-price work you had written off as underwater turns out fine. And the projects that quietly funded everything else were small, unglamorous and staffed entirely by your own people.

None of this makes licence resale worthless. A 12% uplift on $150,000 of software is real money, and it consumes almost no delivery capacity. Track it as its own margin stream with its own target. What it must never do is sit inside the services margin, where it hides a delivery team running at cost.

What counts as unbilled integration rework?#

Any work done twice because the first version satisfied the specification but not the running system.

Rework never arrives as an invoice. It arrives as hours. A data migration re-run after the source schema moved. Three days rebuilding an interface because the vendor shipped a new API version mid-project. A fortnight of defect fixing after user acceptance testing that everyone had agreed was just finishing off.

None of it lands as a cost, because your time tracking codes it as delivery like everything else, and that is how two projects with identical booked hours end up miles apart on real margin. One of them spent a fifth of those hours doing the same work twice.

Somebody is already absorbing it, quietly. On most overrunning implementations there is a delivery lead who decided that raising a change request for two days of interface work costs more goodwill than it recovers. That is a defensible call in the moment. It also deletes the only evidence that would tell you what the work actually cost.

Code it separately instead. One extra task code per project, named rework, applied whenever somebody repeats work that was already signed off. No new software, no new process, and the number it produces goes straight into your next estimate.

Waiting for close-out defeats the point. Knowing a project's margin while it still has months to run is what lets you renegotiate, reschedule or stop absorbing the change requests.

That is the argument in our piece on how to tell if a job is losing money before it finishes. It was written for construction, where the leading indicators are labour burn and unpriced variations. Swap those for licence pass-through and rework hours. The method survives the translation.

Two projects, one invoice value#

Same invoice, opposite answers.

Line	Project A: ERP rollout	Project B: integration build
Invoice	$400,000	$400,000
Third-party licences	$150,000	nil
Partner margin taken	$40,000	nil
Contracted specialists	$30,000	$60,000
Delivered revenue	$180,000	$340,000
Own-team delivery cost	$120,000	$210,000
Delivery margin	33%	38%
Unbilled rework hours	260	40

Project A wins on revenue and loses on everything after it.

Now price the rework in. At $85 an hour of loaded cost, those 260 hours are another $22,000 out of Project A, and its delivery margin falls to 21%. Project B gives up barely a point. On the invoice ledger the two jobs were twins. They were not close.

What a healthy project margin looks like#

Hold yourself against the sector's own numbers. Revenue growth is not one of them.

Rocketlane's summary of the 2026 benchmark puts industry project margin at 36.4% on time and materials and 37.2% on fixed price. Revenue leakage improved to a five-year low of 4.5%. Billable utilisation fell to 66.4%, under the 70% floor SPI Research treats as healthy.

Those come from the 2026 PS Maturity Benchmark, a survey of 509 professional services organisations employing more than 245,000 consultants, which is the closest thing the sector has to a scoreboard.

Read them as three questions about your own book. Is your project margin near the industry figure once pass-through comes out of the denominator? Is more than 4.5% of what you sold failing to reach an invoice? Are your people billable two days in three, or better than that?

Most firms cannot answer the first one at all. The invoice sits in one system, the cost sits in another, and nobody nets them off until the year end. That is a reporting problem before it is a pricing problem.

Start with the last four projects you closed#

Not the biggest four. The four most recent, so nobody can argue you picked flattering examples.

For each one, write the invoice at the top. Subtract every pass-through line: licences, the partner cut, contracted specialists. Divide what remains by your own team's booked hours at a loaded rate. Then ask the delivery lead a single question: how many of those hours went on doing something twice?

You will not get a precise answer. You will get a ranking, and a ranking is enough to change which work you bid for next quarter.

Korrel exists to make that arithmetic routine rather than annual. A proposal carries deliverables, cost and sell prices, risk flags and a milestone billing schedule, then converts into a project that takes time and expenses booked against those same lines. The comparison between what you priced and what it cost stops being a reconstruction.

Do the four-project spreadsheet first, though. It takes an afternoon, and it tells you whether your real problem is the price you charged or the hours you never charged for.