The Pricing Model Your SI Hopes You Never Question

If you’ve signed an SI engagement for an integration program in the last decade, you’ve probably read more or less the same SOW. Senior architect at $X per hour. Senior consultant at $Y per hour. Mid-level developer at $Z per hour. Estimated hours per phase. A page of assumptions and exclusions. A total estimated fee that looks like a budget but isn’t quite a budget, and a paragraph somewhere acknowledging that the estimate is, well, an estimate.

Six months in, the original number’s been exhausted, a change order is being drafted to add another six hundred hours, and somebody on your finance team is asking how this happened.

Underneath all of that (the rates, the estimated hours, the assumptions, the change orders) is one structural fact the SOW itself doesn’t quite say in those words: the vendor’s revenue grows when the project takes longer.

Time and materials decouples effort from outcome. The customer pays for effort. The vendor produces effort. The working integration at the end of the project is a byproduct of the effort, not the unit of payment.

That decoupling means anything that adds time benefits the vendor, financially. Slowness, revisions, and scope creep all show up as additional billable hours on the next invoice. None of that is a moral failing on the SI’s part. It’s the math working as designed in any contract where the producer is paid per unit of input rather than per unit of output. The SI is operating rationally inside the pricing model their customer signed. Any rational producer in that position produces more effort, not less.

This is most visible in change orders. In a T&M contract, a change order is a short administrative document that adds estimated hours to the engagement. In a fixed-fee contract, a change order is a renegotiation, because the contract price has to move. The difference is real.

Under T&M, the SI’s natural answer to “can we add this thing?” is “sure, here’s the new estimate.” Under fixed-fee, the natural answer is “let’s discuss what that actually costs first.” Neither answer is wrong; they’re just rational responses to two very different pricing models.

A version of this trajectory most engineering leaders will recognize: a mid-sized retailer signs an SI for an OMS-to-ecommerce integration during a re-platform. Original estimate, 600 hours, against a set of Q1 requirements that everyone signs off on at kickoff. By month two, the requirements turn out to be less locked than the kickoff implied (merch and ops both surface needs that weren’t in the original brief), and a discovery extension gets filed. Month three, the OMS vendor pushes a minor API version change and a chunk of the transformation logic has to be refactored to match. Month four, mid-build, the source ecommerce platform is found to have data quality issues that force a defensive redesign on the integration side. By the time UAT surfaces a handful of edge cases that weren’t named in the scope document, the estimate has gone from 600 hours to roughly 1,400. None of it is anybody’s fault. Each individual change order was a reasonable response to a real situation. They were filed on a rolling basis, and there was no single moment for the customer to push back on.

What the math produces in aggregate is roughly what you’d expect.

McKinsey’s analysis of more than 5,400 large IT projects, run with the University of Oxford, found those projects ran on average 45% over budget, 7% over schedule, and delivered 56% less value than originally predicted. That study is more than a decade old. A 2023 survey of enterprise software projects from Forecast found that 66% of those projects still go over budget.

Different methodologies, more than ten years apart, and the pattern hasn’t really moved.

The point isn’t that project management has gotten worse. Plenty has improved over the same period: agile delivery, DevOps, observability tooling, AI-assisted everything. The pattern hasn’t shifted because the pricing model underneath the pattern hasn’t shifted. If you keep paying for effort, you keep getting effort.

Per-integration pricing flips the incentive. The vendor commits to a number for a working integration. The customer pays that number whether the work takes a day or a month. The vendor absorbs the risk of going over, which means the vendor has every reason to be efficient and to invest in repeatable patterns, tooling, and predictable delivery rather than in growing a billable bench.

What the customer is buying changes too. Under T&M, you’re renting a calendar. Under fixed-fee per integration, you’re buying a working integration. The change in unit moves the risk of variability onto whoever can actually engineer it down, which is the vendor. The vendor either delivers efficiently and makes margin, or delivers inefficiently and eats the cost. Either way, the customer’s number stays the customer’s number.

It’s worth being realistic about the tradeoff. Vendors quoting fixed-fee typically build in a 15–30% risk premium to protect their margin against the uncertainty of estimating. The customer pays that premium. What they get for it is a capped number rather than an uncapped one. In a project model that has averaged 45% over budget for more than a decade, paying a 15–30% premium up front for a ceiling on the back end is a reasonable trade for most buyers.

Fixed-fee pricing at integration-level granularity needs predictable delivery, and predictable delivery needs the kind of repeatability that comes from having done the work enough times to engineer the variability out of it. Most large SIs can’t price that way. Their delivery is too variable:

different teams and different tools on every engagement, different starting patterns, different platform combinations. Variability forces hourly billing, because hourly billing is how the vendor passes the cost of variability back to the customer.

That’s the question worth asking on the next pricing call. Ask the SI what they’d charge per integration, not per hour. If the answer is “we don’t price that way,” the reason usually isn’t pricing strategy. The reason is they don’t know how long their work actually takes.

Pivotree built our Agentic Integration Services practice around per-integration pricing, and we built it that way because we built predictable delivery underneath it first. The price isn’t a magic trick. It’s what predictable delivery looks like once it’s been engineered into a contract.

If you’d like to see what that feels like in your environment, we run a free two-day Integration Sprint. We take one to three of your real integrations through our pipeline and hand back working code and a full test suite at the end. No rate sheet, no hourly bill. The point isn’t really those integrations. It’s a chance to see what an SOW looks like when the unit of pricing is the integration itself rather than the hours the engineer spent on it.