Scope creep in software implementations (2026): why it happens, what it costs, and how implementation and FDE teams contain it

TL;DR: Scope creep in implementations is a memory problem before it is a contract problem. The scope baseline (what was promised, decided, and at risk) lives in Slack threads, call recordings, and one implementation manager's head, so drift is noticed only when the go-live slips. PMI's 2018 Pulse found 52% of projects experienced scope creep, and the 2026 professional services benchmark still shows a 10.7% project overrun rate. Teams that contain it detect drift from the account record first and run change control second. Sellsy did that and saw projects finishing past planned go-live down 55%.

If you run an implementation team, you know the shape of the problem. A deal closes, the SOW says "standard configuration plus two integrations", and eleven weeks later your team is building a third integration and migrating data nobody quoted. Nobody signed a change order. Nobody said no. The margin is gone, and the customer thinks this is what they bought.

That pattern has a name, scope creep, and it has been measured for years. What has changed is the setting. Implementations are customer-driven, the deliverables are intangible (configuration, training, integration work), and the people who made the promises rarely deliver on them. Each condition makes the baseline harder to hold than in product engineering, and forward deployed engineers who are paid to say yes make it harder still.

The argument of this piece is that scope creep is a memory problem before it is a contract problem, and that most teams have the fix backwards. The linked spokes go deeper on each part.

What is scope creep in a software implementation?

Scope creep is uncontrolled growth in what a project delivers, without a matching change in budget, timeline, or approval. In an implementation, that means configuration, integrations, migrations, or training that were never in the SOW, delivered without anyone pricing or scheduling the difference. The word "uncontrolled" carries the weight. A customer asking for more is normal. The problem is a yes given outside any record the implementation lead, the account executive, and the customer all agree on.

Why implementations are worse than product work

Implementations creep faster than product projects because the deliverable is intangible and the customer is in the room. A shipped feature exists or it doesn't. "Configure the approval workflow" has no natural boundary, so one more step and one more field becomes twelve steps by go-live. PMI's 2018 Pulse of the Profession listed inaccurate requirements gathering as a primary cause of failure in 35% of failed projects, and in an implementation the requirements were gathered by a sales team that has already moved on.

There is a second difference. In product work the team that scoped the feature builds it. In an implementation, sales scoped it, an implementation manager or FDE delivers it, and account management inherits it. A Director of Implementations at a vertical SaaS vendor put it plainly: "The handoff from sales to implementation, and then to account management: the retention of that information is the friction point." That gap is where the original scope quietly changes shape, which is why the sales-to-implementation handoff is where promises go to disappear.

Scope creep vs change request vs change order

These are the same event at three stages of control. A change request is the customer asking for something outside the agreed scope. A change order is the formal, priced, approved amendment that results. Scope creep is when the request skips the order and gets built anyway. Every PSA has an object for the second step. Almost none help you notice the first step happened. We compare how change orders work in Rocketlane, Kantata, and Certinia in a dedicated spoke.

A related boundary matters. Not every out-of-scope request is scope creep, some is legitimate discovery, the customer learning what they need as they see the product configured. Telling one from the other is the hardest call in the job, covered in scope creep vs discovery.

Where FDE teams fit

Forward deployed engineering teams face the same creep with a sharper edge. A forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer. The role exists because something has to be built that does not exist yet, so scope is partly undefined at signature. An FDE team without a baseline cannot tell the custom work it signed up for from the custom work that drifted in. Scoping, not coding, is the real FDE job, and it is the part most often skipped.

Where does scope creep enter an implementation?

Scope creep enters at five predictable points, and four of them happen before anyone would call the project at risk. Each leaves different evidence behind.

The presales miss

The first entry point is what sales did not ask. A professional services leader at a compliance software vendor described it: "Any miss in presales comes back and bites us during implementation. That's when you start uncovering what you missed." The questions the customer answered were about the deal, not the delivery.

The side-agreement in Slack

Then there is the promise made in a shared channel. A customer asks "could we also sync the custom object?", an engineer replies "should be doable", and three weeks later that is a commitment nobody put in the SOW or the CRM. The head of a forward deployed engineering team at a Series A AI vendor described the mechanism: "What sales actually sold, or at least promised, doesn't always end up in the contract. And because we have forward deployed engineers, they tend to say yes to everything." How Slack promises become scope, and how to catch them before they harden, is its own spoke.

The kickoff re-discovery

The third entry point is the kickoff call, where the customer meets the delivery team and repeats the requirements from memory. The version they describe rarely matches the SOW, because the SOW was written from a demo and the kickoff is the first real discovery. If the delivery team writes down what they hear without reconciling it against what was signed, the project has two baselines and nobody knows which is binding. Why the closed-won record and the delivery plan drift apart from day one is covered in the CRM handoff spoke.

The late stakeholder

Late stakeholders are the expensive one. The clearest documented example is a 2012 McKinsey and University of Oxford study of more than 5,400 IT projects. In one case, a finance department joined a bank's core system project a few months before go-live, forced several complex changes to the accounting modules, and delayed the launch by more than three months at a cost of more than $8 million. The study named infrequent communication about new requirements and change requests as a root cause. Scale it down to a mid-market implementation and the pattern holds. The person who could have blocked the change was never in the loop.

The go-live squeeze

The squeeze is the final two weeks, when every "we can't go live without this" gets built because the alternative is a slipped date everyone will see. It is the one entry point that happens after the project is visibly at risk, so it is the one teams remember. It is also the least important to fix, because by then the other four have spent the margin.

What does scope creep cost an implementation or professional services team?

Scope creep costs margin first, utilization second, and referenceable customers last, and the 2026 benchmarks show all three under pressure. Unpriced work is delivered by billable people, so every hour of creep is utilization with no revenue attached.

The overrun chain in the 2026 benchmark

SPI Research's 2026 Professional Services Maturity Benchmark, summarized by Deltek, reports a project overrun rate of 10.7%, above the 10% threshold the report treats as healthy. In the same edition, billable utilization fell to 66.4%, the lowest in the survey's history, project margin sat at 37.7%, and on-time delivery was 73.8%. The survey covered 509 global firms per Kantata's sponsor page. Scope creep is not the only driver, but it is the one that connects them. Unpriced work overruns the budget, the overrun eats utilization, and lost utilization shows up as margin.

On-time delivery and the reference you never get

Late projects also cost the next deal. SPI 2026 shows referenceable clients dropping to 68.2% from 70.1%, and Wellingtone's 2026 State of Project Management found that only 36% of organizations always or mostly complete projects on time. A customer whose go-live slipped six weeks will not take the call from your next prospect.

What the project management research says

The link to project failure has been measured for a decade. PMI's 2018 Pulse reported that 52% of projects completed in the prior twelve months experienced scope creep or uncontrolled changes, up from 43% five years earlier, and the same 2018 survey put waste at 9.9% of every dollar due to poor project performance. A 2020 empirical study in IEEE Access (Komal et al., DOI 10.1109/ACCESS.2020.3007098) found the factors of scope creep negatively associated with project success and called it one of the most common causes of software project failure.

Recent PMI data shows the ceiling on discipline alone. In the 2025 Pulse, even professionals rated high on business acumen hit schedule on only 63% of projects. The 2026 Pulse on complex projects found that about a third of complex projects fail, nearly twice the 13% rate for projects overall, and every multi-integration implementation qualifies. The full number set lives in scope creep statistics for 2026.

Why don't the usual controls stop it?

Change control fails in implementations because it starts after a human notices, and the human rarely notices in time. Every mature PSA can raise a change request. None tells you a change already happened in a thread, a call, or an email you weren't on.

The baseline lives in someone's head

The first failure is that there is no baseline to compare against. The SOW is a PDF, the kickoff notes are in a doc, the Slack agreements are in a channel, and the customer's understanding is in their inbox. The only place all four meet is the implementation manager's memory. As a Director of Implementations at a vertical SaaS vendor said: "So much of what we do is still left in the memory of the implementation manager, and they're not going to catch everything." That person is carrying fifteen other accounts. How to build a scope baseline from the account state rather than from the contract alone is its own spoke.

Change request forms start after someone notices

The second failure is sequencing. Certinia's PSA help lets you "raise a change request from your project", which "creates a change request opportunity" for work "outside the scope of the work that was originally agreed". Kantata's knowledge base describes a "Propose Budget Change" flow where a user submits a new budget and others approve or decline it. Both handle the second half of the job, and both wait for a person to click. Rocketlane's own scoping guidance documents project templates and approval-governed time tracking, but no drift-detection step. The gap in every case is detection.

Status is reconstructed by hand, so drift hides in the reconstruction

The third failure is that the status report meant to surface drift is itself a manual reconstruction. Wellingtone found 72% of project professionals spend half a day or more every month collating project reports. When status is assembled from memory once a week, a scope change made on Tuesday is a green cell on Friday. PSA adoption in SPI's data is 68.9%, so the tool is not the constraint. RAG status that isn't theater needs evidence attached to the color, which is what a hand-built report lacks.

How the common setups compare

• Spreadsheets + Slack (the real incumbent). Where the scope baseline lives: The SOW PDF plus what the implementation manager remembers. Who notices the drift: The implementation manager, usually at go-live. How the change gets priced: Ad hoc email or renegotiation after the fact. What the customer sees: A shared channel and a status email rebuilt by hand.
• Rocketlane. Where the scope baseline lives: Project templates (documented on Rocketlane's own page). Who notices the drift: A person, no drift-detection step documented. How the change gets priced: Approval-governed time tracking, no change-order object documented. What the customer sees: Customer portal, varies by plan.
• Kantata OX. Where the scope baseline lives: Project budget in the Budget tab. Who notices the drift: A person, then "Propose Budget Change". How the change gets priced: Approve or decline the proposed budget, notifications on change orders. What the customer sees: Varies by configuration.
• Certinia PS Cloud. Where the scope baseline lives: The project record in Salesforce. Who notices the drift: A person, then "Create Change Request". How the change gets priced: A change request opportunity for extra budget or out-of-scope work. What the customer sees: Varies by configuration.
• Tandem (paired with your PSA or tracker). Where the scope baseline lives: The account brain: what was promised, decided, and at risk, sourced from Slack, email, CRM, tickets, and calls. Who notices the drift: Risk detection flags scope drift red, amber, or green with the evidence attached. How the change gets priced: Tandem agents draft the SOW change, a human approves it, the PSA still holds the priced contract. What the customer sees: A customer workspace showing done, next, and theirs to move.

Tandem sits alongside the PSA rows rather than replacing their resourcing, invoicing, or contract objects. The vendor cells describe only what each vendor documents on its own domain, hence "varies by configuration".

How do implementation and FDE teams contain scope creep?

The teams that contain scope creep reverse the usual order. They detect drift from the account record first and run change control second. A Head of Implementation at a vertical SaaS vendor summarized the priority: "In the end it's not about doing the job for you, it's about highlighting risks. That's the most critical part." The sequence, in the order it has to happen:

• Write the baseline down where the work happens, not only in the SOW. The SOW is the legal baseline. The operational baseline is what was promised, decided, and at risk, across sales, kickoff, and delivery. If it lives only in a PDF, nobody consults it. If it lives in the account state, updated from the sources where promises are made, it can be checked against every new request.
• Make every new commitment visible within days, not at the status meeting. A request in Slack or a "sure, we can do that" on a call should show up as a candidate scope change with its source attached. This is what Tandem's risk detection does: it flags scope drift red, amber, or green with the evidence (the message, the call excerpt, the ticket) linked. At Sellsy, delays surface as ranked risks with the source attached, caught in days instead of weeks. The implementation lead still decides.
• Decide, with the customer, whether it is creep or discovery. Not every flagged request needs a change order. Some belong in scope because the SOW was ambiguous. The conversation goes better when you can show the customer the message where the original scope was agreed.
• Raise the change order before the work starts, with the draft already written. Once something is agreed to be out of scope, the change order should exist before the ticket is opened. Tandem agents draft the SOW change from the flagged evidence. A human reviews and approves the draft before it is sent, and the approved draft carries a visible marker showing it was agent-drafted, with the source messages attached. The priced contract still lives in your PSA.
• Close the loop back to sales and the CRM. A change order that never reaches the account record means the next renewal starts from the wrong number. Tandem agents can update the CRM with the change, again with human approval first and a marker and source attached, so the closed-won record and the delivered scope stop drifting apart.
• Make the scope playbook repeatable so you stop re-scoping every deal. FDE teams re-derive scope from zero on each engagement because each customer is different. Most of the structure is not. Capturing the recurring shape is how FDE playbooks make engagements repeatable, and how you shrink the undefined part of scope before it becomes drift.

Who owns the "no"

The implementation lead owns the no, and the FDE owns the evidence. FDEs are structurally inclined to say yes. They are in the room with the customer and they can build the thing, and asking them to also refuse puts the relationship and the margin in conflict. A cleaner model: the FDE surfaces the request with its source, the implementation lead decides whether it is a change, and the account executive owns the commercial conversation. A change-control board is too slow for a six-week SaaS implementation.

What it looks like when it works

Sellsy's implementation team runs 3x accounts per implementation manager, same team, same quality, with average project duration down 40% and projects finishing past planned go-live down 55%. Their Head of Implementation described the shift: "We stopped reconstructing status and started deciding things. Every project, current, with the risk and the reason. Three times the book per manager, same team, same quality." Against SPI's 73.8% on-time delivery, what changed was when they learned about a scope change, while it could still be priced. The change request form itself is the same one everyone has.

What stays manual

Tandem does not decide whether a request is scope creep, price the change, or say no to your customer. Those stay with the implementation lead and the account executive. Risk detection tells you a commitment appeared in a channel on Tuesday and links to the message. Whether it is a reasonable reading of the SOW or a new deliverable is your call, and often the customer's.

Tandem pairs with a PSA or tracker rather than replacing resourcing and invoicing. The priced change order still lives in whatever holds your contracts. Tandem agents draft the SOW change and can update the CRM, but a human approves every action before it goes anywhere, and every approved action carries a visible marker and its source.

Tandem also needs your playbooks configured first. Scope drift is only detectable against a definition of scope, so the account brain has to know what "standard configuration" means for your product and what always counts as custom. That setup is quick (Sellsy was deployed in under a week) but it is not zero.

This is also a new category with a thin public review base. Ask for references in your segment before you trust it with a portfolio.

Scope creep is a memory problem first

Contracts don't stop scope creep. Memory does, and human memory does not scale to fifteen accounts per manager. The teams that contain it in 2026 treat the account record as the baseline: what was promised, decided, and at risk, sourced from where those things happen, and checked when each new request arrives. Change control then does what it was built for, pricing a change everyone agrees is a change.

The payoff is concrete. A team that decides instead of reconstructing carries more accounts per head without hiring, and go-lives hold their date, which is what Sellsy saw with late projects down 55%.

If your team is carrying the scope baseline in someone's head, see Tandem flag scope drift on one of your live implementations and check whether the risk it surfaces matches what your implementation leads already suspect.

FAQs

What are the most common causes of scope creep in implementations?

The five entry points are a presales miss, a side-agreement in a shared Slack channel, re-discovery at kickoff, a stakeholder who joins late, and go-live pressure. Four of the five happen before the project looks at risk. The common thread is a commitment made outside the record everyone agrees on.

How much does scope creep cost a professional services team?

The 2026 SPI Research benchmark reports a 10.7% project overrun rate, 66.4% billable utilization, and 73.8% on-time delivery across 509 firms. Scope creep is not the only cause, but unpriced work is what connects overrun to utilization to margin.

How do you prevent scope creep in customer onboarding and implementation projects?

Write the operational baseline down where the work happens, make every new commitment visible within days with its source attached, decide with the customer whether it is creep or discovery, and raise the change order before work starts. Change control alone fails because it starts after a person notices.

Does a PSA like Rocketlane, Kantata, or Certinia stop scope creep?

They handle the second half. Certinia lets you create a change request opportunity, Kantata lets you propose a budget change for approval, and Rocketlane documents templates and time-tracking approvals. None documents a step that detects the drift first. Tandem pairs with those tools by flagging the drift with evidence so the change order gets raised in time.

Key terms

Scope creep: Uncontrolled growth in what a project delivers without a matching change in budget, timeline, or approval. In implementations, usually unpriced configuration, integration, or training work.

Scope baseline: The agreed record of what is in and out of scope. The legal baseline is the SOW. The operational baseline is what was promised, decided, and at risk across sales, kickoff, and delivery.

Change order: A formal, priced, approved amendment to the scope of work. PSAs such as Certinia and Kantata provide objects for raising and approving one.

Account brain: The Tandem product block that holds the account state for every implementation, sourced from Slack, email, CRM, tickets, and calls.

Account state: What the account brain holds for one customer: what was promised, decided, and at risk, each with its source attached.

Professional services automation (PSA): Software that manages resourcing, time tracking, budgets, and invoicing for services teams. Tandem pairs with one rather than replacing it.

Forward deployed engineer (FDE): An engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer.