Scope Is a Negotiation: Preventing the Change Order Before It Starts

Scope looks wonderfully well behaved in a contract. It sits there in a numbered section with clean dates, neat deliverables, and signatures underneath. Then an input arrives two weeks late, an approver joins halfway through, and somebody asks, “That was included, wasn’t it?” Now the schedule’s moved, the work’s grown, and two reasonable teams are using the same paragraph to explain why the other one should absorb the cost. 

The contract may have done its job. It can settle what was bought and sold without explaining how the work will run once people start doing it. The working version of scope lives in the details: who can make a decision, what a handoff includes, when access will be available, what “finished” means, and whose problem it becomes when an assumption no longer holds. 

That distinction ran through the mixed-group prework reviewed by SNI. Teams described being brought in late, inheriting schedules they couldn’t meet, waiting on missing inputs, arguing over ownership, and reopening work someone else had already considered finished. These often get blamed on execution. But in practice, they’re scope negotiations that happened too late. Put those assumptions on the table before work begins, and far fewer of them return as change orders. 

Scope disputes begin with expectation gaps 

Most scope disputes do not begin with bad intent. They begin with an expectation gap. One party believes a task is included because it’s necessary for the outcome, the other believes  it’s excluded because it’s not named, priced, or assigned. 

The gap becomes expensive when teams discover it after resources are committed, deadlines are close, or the customer expects delivery. At that point, a clarification feels like a demand and a change feels like a failure. 

Define scope in operational terms 

A list of deliverables tells people what they’re getting but doesn’t explain how the work will run once the project is underway. That takes a more practical conversation about what everyone is trying to accomplish, which assumptions the plan rests on, who owes what to whom, who gets the final say, and what happens when the project refuses to follow the script. Nobody can predict every late approval, missing input, or unexpected request. However, they can agree on how those moments will be handled before they argue over the cost. 

1. Outcome: What business or project result is the work intended to produce? 
2. Deliverables: What tangible outputs, services, or milestones will be provided? 
3. Exclusions: What related work is specifically not included? 
4. Assumptions: What conditions, volumes, access, data, approvals, or inputs does the plan depend on? 
5. Dependencies: What must another party provide, and by when? 
6. Acceptance: Who decides whether the work meets the requirement, using which criteria? 
7. Decision rights: Who can approve changes to cost, schedule, design, quality, or scope? 
8. Change triggers: Which events require review, repricing, resequencing, or a formal change decision? 

Negotiate the assumptions before they become facts 

Once the operating terms are on the table, spend some time on what people are taking for granted, because this is usually where the future argument is hiding. One side prices the work on clean data arriving Monday, while the other schedules the launch around approvals coming back within 48 hours. Neither assumption is written down or feels risky to the person making it, but six weeks later the difference has become a missed deadline and an unexpected invoice. 

Kickoff gives the team a chance to catch those assumptions while the plan can still accommodate the answers. Ask each side to talk through three statements: 

1. Our plan assumes that… 
2. We are depending on your team to… 
3. If this condition changes, the likely effect will be… 

This exercise exposes gaps without forcing either side to accuse the other of misunderstanding. It also creates a direct link between the assumption and the consequences. 

Clarify ownership at the handoffs 

From there, trace the work as it moves between teams, because a surprising amount of scope trouble begins after someone says, “I sent it.” The data arrived with half the fields blank, the design showed up without approval, or the request reached the right inbox and sat there because the recipient thought someone else was responsible. Nobody has added to the scope, yet the schedule is already slipping since each side has a different idea of where one person’s job ends, and the next person’s begins. 

Clarifying the handoff means following it all the way through receipt and acceptance. For each major exchange, name the sender, receiver, required format, due date, quality standard, approval step, and the person who acts first when something arrives late or incomplete. That may sound overly detailed while the project is running well, but during a delay it saves the team from spending its first critical hours debating who owns the problem instead of solving it. 

Respond to change requests with options 

Clear handoffs can stop work from falling between teams, but they cannot stop someone from asking for more. When that happens, “That’s out of scope” may be true, but it is a dead end. Confirm what they need, then show them the choices and what each one does to price, timing, or priorities. That way, the tradeoff belongs to the decision rather than looking like a penalty from the delivery team. 

1. Preserve the current scope and explain what the existing plan will deliver. 
2. Add the requested work with a clear effect on price, timing, resources, or risk. 
3. Exchange priorities by removing or delaying other work to protect the budget or deadline. 
4. Test the request through a limited phase before committing to the full change. 

Document decisions in language the operating team can use 

Legal and commercial language remains important, but the people doing the work also need a plain language record. After a scope discussion, document what changed, why it changed, what remains unchanged, who owns the next action, and how cost or timing will be handled. 

A short decision record can include: 

1. The request or issue under review. 
2. The agreed interpretation or selected option. 
3. Any revised deliverable, assumption, owner, date, or acceptance criterion. 
4. The commercial or schedule effect, including no effect when that is the agreement. 
5. Open questions and the person responsible for resolving them. 

The record should be easy to find and visible to every team affected by the decision. 

Create a scope review cadence 

Scope drift tends to arrive one small decision at a time: an assumption changes, a stakeholder joins late, or somebody agrees to a quick request and forgets to update the record. One by one, those decisions rewrite the project without anyone formally agreeing to a new one. 

The decision record gives everyone a place to see those changes, but only if the team returns to it. Build a brief scope review into the regular project rhythm and use it to ask: 

1. Have any assumptions changed? 
2. Are dependencies arriving as planned? 
3. Has any stakeholder requested work that is not reflected in the current record? 
4. Are acceptance criteria still clear? 
5. Do current decisions affect cost, timing, quality, or risk? 
6. Which issue needs a formal change decision now? 

A practical example of negotiating scope early 

The trouble shows up in one question at kickoff: What, exactly, are we launching? 

The sponsor thinks it’s a complete customer experience. The technical team can’t start until somebody approves the requirements. Operations expect training and support materials, but nobody’s claimed them. Everyone walked in believing the scope was clear; within ten minutes, it’s obvious they’re working toward three different versions of launch day. 

The project leader keeps them in the room long enough to follow the missing work instead of parking it for later. That’s how they find the real constraint: content needs approval two weeks earlier than the sponsor expected. If that can’t happen, the full experience won’t make the date. 

So they agree to phase the release, spell out what customers will get first, give content approval to a named owner, and put the decision in front of the people building and supporting it. The scope hasn’t quietly shrunk through delay or confusion. They’ve made the hard call early, while they still have choices, and everyone can leave knowing what launch day means. 

Eight questions to ask before work begins 

1. What exact outcome are we committing to produce? 
2. Which deliverables are included and excluded? 
3. What assumptions support the plan? 
4. Which inputs, approvals, and resources must each party provide? 
5. Who owns each handoff and decision? 
6. How will the work be tested and accepted? 
7. Which changes require commercial or schedule review? 
8. Where will decisions and updated scope be recorded? 

Turn scope clarity into a working agreement 

SNI helps cross-functional teams practice the conversations that clarify expectations, surface assumptions, negotiate tradeoffs, and preserve relationships when plans change. The best time to negotiate a change order is often before anyone calls it a change. 

Reach out to us to learn more.  

Frequently asked questions about scope creep and change orders