# Which implementation projects are actually profitable once licences and rework are counted Source: https://korrel.ai/blog/which-implementation-projects-are-actually-profitable Published: 2026-07-29 Updated: 2026-07-26 Topic: which implementation projects are actually profitable Tags: margin-and-profitability, project-costs --- ## Key points - Rank projects by delivered revenue rather than invoice value, because licence pass-through flatters the worst jobs. - Third-party licences, partner cuts and contracted specialist time inflate revenue while adding almost nothing to margin. - Unbilled integration rework is a real cost hiding inside delivery hours that nobody codes separately. - SPI Research puts industry project margin at 36.4% on time-and-materials work in its 2026 benchmark. - A margin calculated after close-out is a post mortem, so recalculate it monthly while the project runs. 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](https://www.parakeeto.com/blog/customer-profitability-analysis/) 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](/blog/designing-profitable-projects-a-guide-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](/blog/job-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](https://www.rocketlane.com/blogs/professional-services-maturity-index-2026) 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](https://spiresearch.com/reports/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. ## Common questions ### How do you calculate profitability on an implementation project? Subtract every pass-through cost from the invoice first, then measure margin against what is left. Pass-through means third-party licences, the cut a partner or reseller takes, and contracted specialist time. What remains is the money your own people earned. Divide the gap between that figure and your loaded delivery cost by the same figure, and you have a margin comparable across projects of any size. ### Should licence revenue count towards project margin? No, not at the top line. A licence resold at a thin uplift adds a large number to revenue and a small one to margin, so leaving it in makes licence-heavy work look like your strongest delivery. Track the uplift separately as its own margin stream. Judge the delivery team on the services money only. ### How do you track unbilled rework without adding admin? One extra task code per project, used whenever somebody repeats work that was already signed off. That is the whole change. It costs a delivery lead nothing to apply and it turns an invisible cost into a number you can price into the next proposal. Review the code weekly rather than at close-out. ### What project margin should an IT services firm target? Somewhere near the industry benchmark, measured on services revenue rather than total invoice value. SPI Research puts project margin at 36.4% on time-and-materials work. Fixed-price work sits at 37.2%. Licence-heavy projects will read lower if you leave pass-through in the denominator, which is the main reason firms think their margins are worse than they are.