Blog
8 min read
Unscoped integration work is any interface you end up building that the signed statement of work never named and never priced. Rarely is it a client behaving badly. It is a gap in a document you both approved, found in week five by an engineer who needed a test credential and could not get one.
Knowing how to stop unscoped integration work on an implementation project is a supplier's problem, not a buyer's. The client's exposure is a late go-live. Yours is the margin on a number you quoted before anyone had seen the legacy API.
Because the buying organisation is the audience. Analyst guidance on migration failure is addressed to the IT leader deciding whether to proceed and what to insist on before switching. The delivery partner appears in that story as a line item rather than as the reader.
Read the same material as a supplier and it changes function entirely. It stops being a warning and starts being a scoping checklist. Forrester's Julie Mohr, writing in March 2026 on why ITSM platform migrations fail, names the connection points that get overlooked: HR information systems, monitoring, identity and configuration management databases. A buyer reads that as risk to manage. You should read it as the questions to ask before you put a price on the page.
The ones nobody in the room owns. An integration reaches a brief only when somebody accountable for the system at the other end is present when the brief is written.
| Integration point | Who owns the far end | Why it misses the brief |
|---|---|---|
| HR information system | HR or payroll | Joiners and leavers feel like a people process, not a platform one |
| Identity provider | Security | Assumed to be one connection until you find the legacy directory behind it |
| Configuration management database | Infrastructure | Treated as reference data rather than a live two-way interface |
| Monitoring and alerting | Operations | Nobody notices until incidents stop being raised automatically |
| Finance or billing feed | Finance | Sits outside the sponsoring department's remit entirely |
There is a compounding version of the same problem. One named integration turns out to be several. The identity provider in the brief is the new one, and behind it sits a directory that still authenticates field engineers on a legacy domain nobody has decommissioned. You scoped one connection. You are building two, plus the reconciliation between them.
The second failure is documentation. Brainhub's account of data migration and legacy modernisation risk lists undocumented integrations, business logic buried in legacy scripts, and unseen dependencies such as scheduled jobs and linked reports. Those are not exotic edge cases. They are the ordinary condition of a system that has been in production for eleven years and outlived three of its authors.
So the interface you were shown is not the interface you will build against. Plan for both.
Name every interface in the scope document, then price the ones you have actually seen. That is the whole method. The rest is discipline about what you do when the count changes.
An interface is properly scoped when you can write down all of the following before signature:
Half of those answers will be missing at bid time. Good. A missing answer is a question for the client, not an assumption to swallow. A clarification log with eleven open items beats a tidy proposal built on guesses.
Get that list filled in by the people who own each far end, not by the sponsor. A sponsor answers well for the systems they are accountable for and guesses politely about the rest. Twenty minutes with the identity team before you bid is worth more than any assumption you could write in its place.
A deliverable that says "integrations" has no edges at all. The general case is covered in our guide to defining deliverables a client cannot expand. The integration-specific version is simpler: a numbered schedule of interfaces, with a count at the top. Then one sentence. Interfaces not listed in the schedule are not included in the price.
Add the documentation assumption too. The estimate assumes the interface documentation supplied by the client is accurate and complete. Fourteen words. They decide who pays when the API turns out to behave differently from its own specification.
Stop work on that interface the same day. Do not carry on investigating it while you decide what to say, because the investigation is the expensive part and unbilled discovery is where the margin goes.
Then work through four steps in order.
The conversation is easier than people expect when you get to it early. You are not asking for more money because the job turned out to be hard. You are reporting that a system nobody listed is required for the outcome the client asked for, and asking whether they still want it connected. Some clients drop the interface once it has a price on it.
The step people skip is the second one. Without a written record of the real interface, you are negotiating your own credibility against a client who is holding documentation that says something different.
Absorbing an interface quietly is the most expensive kindness in professional services. The cost lands twice. Once on this job's margin. Again on the next bid, because your estimating baseline still says this work takes the hours you originally guessed.
There is a middle path, and it is not a compromise. Raise the change request, price it properly, then decide separately whether to discount it. A waived charge that appears on paper protects the relationship and the data at the same time. A silent one protects only the relationship, and that is a familiar pattern in scope creep on fixed price work.
Keep the mechanics light. Our change request process for fixed price implementation projects sets out the short version: raise it, size it, price it, book it. Korrel records change requests against the project, marks each item billable or not, and shows the revenue, cost and margin impact before anyone approves it.
Size it per interface, never as a flat percentage of the deal. A percentage allowance hides the arithmetic that would have told you the deal was underpriced.
Discovery deserves its own line. DataflowMapper's compiled review of published migration cost benchmarks puts pre-migration planning at 50 to 70% of total project effort. Useful arithmetic to have in front of you if your estimate treats analysis as a rounding error before the real build starts.
Environment access belongs in the allowance too. An interface you can only test against production is a different job from one with a sandbox, and the difference is not a technical one. It is scheduling. Change windows, approvals from a security team you have never met, and a rehearsal somebody senior has to attend.
Then price each interface with three components: a discovery task, a build task, and a contingency that reflects how much you were shown. An interface you have connected to before on another client carries almost none. One described to you in a meeting, on a system nobody at the client has touched in four years, carries a lot.
Record hours against the interface, not against the project. This is the part that compounds.
At close, you want one row per interface. What it was, what you estimated, what it took, and whether it sat in the original scope or arrived as a change. Ten projects of that and you can quote identity work from your own history rather than from optimism. It also tells you something less comfortable, which is which implementation projects are actually profitable once the unbilled integration hours are counted against them.
Start with the job you finished last. Count the interfaces named in its statement of work, count the ones your team built, and put the two numbers side by side. If they differ, the difference is what you gave away, and the next proposal is where you stop giving it.
COMMON QUESTIONS:
RELATED READING:
The money is lost in the ninety seconds between a client asking for a change and a trade starting it. Here is the pause, price and confirm sequence that closes it.
Stage 3 closes, the client approves, and three weeks later they want the roof pitch changed. Here is how to tell a revision from a new instruction, and what to charge.
Enterprise change control was built for internal IT operations. A delivery partner working to a signed statement of work needs something lighter: raise it, size it, price it, book it.
Korrel turns briefs into structured proposals, then tracks what each job actually costs.
START FREE TRIAL