# How to stop unscoped integration work on an implementation project
Source: https://korrel.ai/blog/stop-unscoped-integration-work
Published: 2026-08-14
Updated: 2026-08-10
Topic: how to stop unscoped integration work on an implementation project
Tags: scope-creep, change-control
---
## Key points

- Unscoped integration work is any interface a delivery partner builds that the signed statement of work never priced.
- Migration failure research is written for buyers, so delivery partners must reread it as a scoping checklist.
- HR information systems, identity providers and configuration management databases are integration points routinely overlooked when a brief is written.
- The moment an undocumented interface appears, stop work, document the real surface and price the delta.
- A scope that names and counts every interface turns a later discovery into a change request.

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.

## Why is the migration research written for the buying organisation?

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](https://www.forrester.com/blogs/why-it-service-management-platform-migrations-fail-and-what-it-leaders-must-do-before-switching-platforms/), 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.

## Which integration points go missing from the original scope?

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](https://brainhub.eu/library/data-migration-challenges-risks-legacy-modernization) 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.

## How to stop unscoped integration work on an implementation project

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:

- the system at the far end, by name and version
- the direction of travel, and whether it is one-way or two-way
- the protocol and the authentication method
- expected record volumes and the frequency of the exchange
- which environments exist, and whether you get access to a non-production one
- who at the client can grant that access, by name
- test data, and whether it will be real or synthetic
- the acceptance test that proves the interface works

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](/blog/define-deliverables-clients-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.

## What do you do when an undocumented interface turns up mid-project?

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.

1. **Stop and flag it.** One email to the project sponsor, the day it is found, naming the interface and the fact that it is not in the schedule.
2. **Document what is actually there.** Endpoints, fields, authentication, rate limits, error behaviour, and the gap between the supplied documentation and reality. Timebox it and record the hours.
3. **Price the delta.** Discovery already spent. Build and test. Any effect on the critical path.
4. **Send it before anyone builds.** A change request raised after the work is finished is an invoice dispute wearing a form.

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.

## Price the delta rather than absorbing it

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](/blog/topics/scope-creep).

Keep the mechanics light. Our [change request process for fixed price implementation projects](/blog/change-request-process-fixed-price-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.

## How big should the integration allowance be on the next bid?

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](https://dataflowmapper.com/blog/data-migration-costs-quantitative-analysis) 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.

## Turn each discovered interface into evidence for the next bid

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](/blog/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

### What counts as unscoped integration work?

Any interface you build that the signed scope never named. The test is the document, not the effort. A two-hour field mapping counts if the schedule of interfaces does not list that system. A three-week identity rebuild does not count if it was named, sized and priced before signature.

### Should you absorb a small integration to protect the relationship?

No, but you can discount it to zero in writing. Absorbing it silently costs the same margin and leaves no record, so the next client gets quoted from the same wrong baseline. Raise the change request, show the price, then waive it if the relationship warrants it.

### How do you price an integration change request without full documentation?

Price the discovery first and the build second. Sell a fixed, timeboxed investigation of the real interface, then quote the delivery once you know what the endpoints, fields and authentication actually are. Quoting a build against documentation you have not verified is how the second overrun starts.

### Who is responsible when legacy API documentation is wrong?

Commercially, whoever the contract says relied on it. That is why the assumption belongs in the scope in writing: the estimate assumes the supplied interface documentation is accurate and complete. Without that sentence, a fixed price silently transfers the risk of the client's own records to you.