Why scope fights, margin erosion, and change order battles start before your project does
The change order conversation almost never starts where the problem started.
A PM is three weeks into an engagement. A deliverable comes up that the client considers baseline and the delivery team considers out of scope. Both parties pull out the SOW. The SOW doesn’t settle it. What follows is a negotiation that nobody wanted, a relationship that takes a hit, and a margin number that quietly bleeds.
The root cause is not at week three. It is not in how the PM managed the engagement. It is not even in how the client interpreted the contract.
It is in a specific and predictable gap that exists between the moment a deal closes and the moment delivery begins. And the reason it keeps happening is that no one inside most professional services organizations officially owns that gap.
What the data actually says about where cost overruns come from
There is a reflex in delivery organizations to treat cost overruns as an execution problem. Project managers are running too many concurrent engagements. Estimates are too optimistic. PMs are not escalating early enough. Delivery teams are absorbing scope without logging change requests.
That reflex is not entirely wrong. Execution discipline matters. But in organizations where cost overruns are persistent and the PM team is competent, the root cause is almost always upstream.
At one organization I led, leadership was attributing rising delivery costs to PM execution inefficiency. The pattern was real. The attribution was not. Direct analysis of the engagement data showed that the actual source of the cost pressure was SOW ambiguity and complexity miscategorization at the point of sale. PMs were running discovery loops, reworking scopes, and managing client expectation gaps that should have been resolved before the contracts were signed. The project management work was sound. The contracts were not.
The fix was not to make the PMs faster or more efficient. The fix was to go upstream and address what was leaving the building before the PM ever touched it.
Where the SOW breaks down
Three failure points show up with enough consistency that they qualify as structural, not situational.
Scope language written to win the deal, not govern the delivery
RFPs create pressure. Sales cycles create pressure. The path of least resistance when translating a client request into a statement of work is to keep the scope language broad enough to avoid any friction that might slow the close.
Broad scope language feels safe during the sales cycle. It becomes a liability the moment two parties need to agree on what it means in practice. “Migrate the environment to the new platform” sounds complete in a proposal. It raises about fifteen questions the first time a PM sits down with a technical lead to map the actual work.
The consequence is not just scope fights. It is the discovery work that PMs absorb at the start of every engagement, trying to close the interpretation gaps that the SOW left open. That discovery work costs hours. Those hours are not in the estimate.
Complexity acknowledged but not validated
There is a meaningful difference between knowing a project is complex and understanding what that complexity actually costs.
In the sales process, complexity tends to be acknowledged in general terms and then reflected in the estimate with a buffer that nobody formally justified. The buffer is not tied to specific complexity factors. It is a judgment call made under time pressure by someone whose primary job is closing the business, not scoping the delivery.
The practical consequence is an estimate built against the optimistic version of the engagement. The client, reasonably, expects to receive what was scoped. When delivery encounters the actual complexity, the PM has no documented complexity basis to reference in a change order conversation. The client does not see a scope change. They see a delivery team failing to deliver what was promised.
The formula error problem I found at one company I led is a specific version of this. A systematic error in the level of effort estimation workbook was causing PM time to be double-counted across every quote leaving the building. The result was consistent over-quoting on contracts, which was creating its own set of competitive and margin problems. Nobody had caught it because nobody was validating the workbook output against delivery reality on a structured basis. It was only visible when the engagement data was analyzed against what the contracts had actually promised.
Change control language without a mechanism anyone will use
Most professional services contracts include change control language. Most of it does not work.
The language tends to be written at a level of abstraction that neither party references when a scope question actually comes up. There is no defined threshold for what triggers a change request. There is no agreed-upon process for how a disputed item gets evaluated. There is no pricing structure the client understood before the engagement started that makes a change order feel like a reasonable outcome rather than a surprise tax.
The result is that when something clearly out of scope comes up, the PM has to decide whether to fight the battle or absorb the work. Most of the time the answer depends on relationship factors and timeline pressure, not on a clean mechanism that both parties agreed to at the start.
Change control language that actually holds is specific. It defines what categories of work constitute a change. It sets a threshold for cost or effort that triggers a formal review. It establishes a process both parties have acknowledged. And it is explained to the client before signatures, not discovered during the first scope dispute.
The organizational problem underneath the contract problem
The three failure points above are tractable. Organizations fix them with process, training, and the right people in the right review conversations. What is harder to fix is the ownership gap that allows them to persist.
Sales owns the deal. Delivery owns the execution. The translation between those two things, the moment where a client request becomes a governed delivery commitment, tends to fall into a gap between them.
This is not a character flaw in either function. It is an organizational structure problem. Sales teams are measured on revenue and close rate. Delivery teams are measured on margin, client satisfaction, and delivery performance. The handoff between them is rarely measured at all. Which means nobody is accountable for whether the thing being handed off is ready to execute.
The organizations that solve this structurally create a checkpoint that sits between deal close and project initiation. The checkpoint is not a bureaucratic gate. It is a deliberate review that answers a defined set of questions before the contract goes out or before delivery begins.
Who is in that review varies by organization. In some contexts it is a pre-sales technical resource and a senior PM reviewing the SOW against the RFP and the discovery documentation. In others it is a delivery leader reviewing the estimate and the complexity assumptions before the contract is finalized. The specific structure matters less than the principle: someone whose job is to represent delivery reality has to sign off on the translation before it becomes a contract.
The pre-sales SOW alignment work with solution architects at one organization I led was a direct result of the root cause analysis described above. The pattern in the Lessons Learned data was clear. Statement of work ambiguity was the single highest-frequency category driving project issues across the portfolio. That finding did not just inform internal process changes. It changed who was involved in the SOW development conversation and when.
Document analysis tools built into the delivery workflow added another layer. Analyzing SOWs, RFPs, and kickoff documents before the engagement started surfaced ambiguity, missing requirements, and complexity signals that the written document had not explicitly addressed. That analysis was not about generating paperwork. It was about giving PMs a concrete basis for asking the right questions in the first client conversation rather than discovering the gaps three weeks in.
What changes when the handoff is owned
The most immediate change is that change order conversations become less adversarial. When a scope boundary is clearly defined at the start and both parties understood the mechanism for handling things outside it, a change request is a process, not a confrontation.
The subtler change is margin predictability. When complexity is validated before the estimate goes out and the estimate reflects what delivery will actually encounter, the gap between what was sold and what it costs to deliver narrows. That gap is where margin lives or dies on professional services engagements.
The relationship change is harder to measure but equally real. Clients who experience a smooth change order conversation, where the process is clear and the pricing is not a surprise, come out of it with a different view of the delivery organization than clients who experience the same situation as a dispute. The contract language shapes the experience before the PM has done a thing.
Organizations that own this handoff do not just write better SOWs. They create the conditions for a delivery relationship that can actually hold.
The ones that do not keep having the same conversation at week three.
Michael Davis writes about delivery leadership, PMO transformation, and the operational patterns that separate high-performing delivery organizations from the ones perpetually fighting fires. Connect with him on LinkedIn or explore more at PMLinks.com.