How to deal with scope changes when you didn’t create a proper Statement of Work
There is a moment in almost every project when someone says:
“I thought that was included.”
And suddenly, everyone is looking at the Project Manager.
You look at the project plan.
You look at the requirements.
You look at your notes.
Then you ask yourself:
“Did we actually define what was in scope?”
If the answer is no, you have a problem.
Not necessarily because the customer is trying to sneak something into the project. Not because the team is trying to do extra work.
Sometimes the problem is much simpler:
We never clearly defined the boundaries of the project in the first place.
And when the boundaries aren’t clear, scope changes become almost impossible to manage.
The SOW Isn’t Just a Document
A Statement of Work—or SOW—is often treated as something that needs to be completed because the process says so.
Sign it.
File it.
Move on.
But a good SOW is much more than paperwork.
It creates a shared understanding of:
- What we are delivering
- What we are not delivering
- Who is responsible for what
- What the customer is responsible for
- What assumptions we are making
- What the key milestones are
- What the expected outcomes are
- How changes will be handled
Think of it as the fence around your project.
Without the fence, it’s hard to tell when someone has wandered outside the yard.
What Happens When the SOW Isn’t Clear?
Let’s say your project is already underway.
The customer asks:
“Can we also add this?”
The team says:
“That’s probably a change request.”
The customer responds:
“I thought that was part of the project.”
Now you’re in the middle.
You don’t have a clear scope statement to point back to.
So the conversation becomes subjective.
Instead of asking:
“Is this within the agreed scope?”
you’re asking:
“What did everyone think the scope was?”
Those are two very different conversations.
And the second one can become uncomfortable very quickly.
Don’t Panic. Rebuild the Scope.
If you’ve already started the project and realize the SOW isn’t good enough, don’t spend the next three months wishing you had written it differently.
Fix it.
The goal isn’t to create a perfect document.
The goal is to create shared understanding.
Here are five simple steps I recommend.
1. Create a One-Page Scope Snapshot
Don’t start with a 20-page document.
Start with one page.
Call it whatever works for your organization:
Project Scope Snapshot
Include five things:
In Scope
What are we actually delivering?
Out of Scope
What are we specifically not delivering?
Deliverables
What tangible things will the project produce?
Assumptions
What are we assuming to be true?
Customer Responsibilities
What does the customer need to provide or complete?
That’s it.
You now have something everyone can review.
And more importantly, everyone can understand.
2. Turn “Gray Areas” Into Questions
This is one of the easiest ways to improve your scope.
Look for statements such as:
“We will migrate the customer’s data.”
That sounds clear.
But what does it actually mean?
Which data?
How much data?
Who cleans it?
Who validates it?
Who provides it?
What happens to historical data?
Instead of allowing vague statements to survive, turn them into questions.
For example:
Data Migration
- What data?
- How much?
- From which systems?
- Who prepares it?
- Who validates it?
- How many migration attempts are included?
- What happens if additional migration work is required?
The more gray areas you remove early, the fewer scope arguments you’ll have later.
3. Create a Simple “In / Out / Maybe” List
This is one of my favorite techniques because it doesn’t require a complicated methodology.
Create three columns:
| IN | OUT | MAYBE |
|---|---|---|
| Agreed deliverables | Not included | Needs clarification |
| Required activities | Customer responsibility | Potential change |
| Contracted functionality | Future phase | Pending decision |
The Maybe column is particularly useful.
Why?
Because projects often contain things that haven’t been decided yet.
Instead of pretending they don’t exist, put them somewhere visible.
Then assign an owner and decision date.
Uncertainty is much easier to manage when it is visible.
4. Establish a Change Rule
Here’s where many projects go wrong.
The team starts treating every new request as either:
“Sure, we’ll do it.”
or
“No, that’s out of scope.”
Neither is particularly helpful.
Instead, establish a simple rule:
New request = evaluate impact before committing.
Look at:
- Scope
- Schedule
- Cost
- Resources
- Risk
- Dependencies
- Customer impact
Then decide.
Maybe it’s in scope.
Maybe it’s out of scope.
Maybe it’s something the team can absorb.
Maybe it belongs in a future phase.
The important thing is that you’re making the decision deliberately, rather than accidentally expanding the project.
5. Start Using the Phrase “Let’s Validate the Scope”
This may be the simplest tip of all.
When someone asks for something new, don’t immediately say:
“That’s out of scope.”
And don’t immediately say:
“Sure, we can do that.”
Say:
“Let’s validate that against the project scope and determine the impact.”
That sentence changes the conversation.
It isn’t confrontational.
It doesn’t blame the customer.
It doesn’t shut down the request.
It creates a process.
You can then review the request together.
If it is included, great.
If it isn’t, you can explain why.
If it is a change, you can discuss the impact.
What If You’ve Already Got Scope Creep?
This is where the Project Manager has to be especially careful.
Don’t go back to the customer and suddenly say:
“We’ve reviewed the project and everything you’ve asked for is now out of scope.”
That can destroy trust.
Instead, acknowledge the situation.
Try something like:
“As we’ve progressed through the project, we’ve identified a few areas where our original scope wasn’t specific enough. I’d like to review those items with you so we can make sure we’re aligned on what the project needs to deliver and identify anything that may require a change.”
That’s a very different conversation.
You’re not looking for someone to blame.
You’re looking for alignment.
A Simple Scope Change Checklist
Before accepting a new request, ask these six questions:
1. What exactly is being requested?
Make sure everyone understands the request.
2. Is it already included in the agreed scope?
Don’t assume. Check.
3. What happens if we accept it?
Look at schedule, cost, resources, risk and dependencies.
4. What happens if we don’t accept it?
Sometimes the impact of not doing something is greater than the effort of doing it.
5. Who needs to approve the change?
Make sure the right people are involved.
6. Where are we documenting the decision?
If it isn’t documented, you may be having the same conversation again three months later.
The 15-Minute Scope Review
Here’s a practice I’ve found particularly useful.
At the beginning of a project, schedule a 15-minute scope review with the core team and customer.
Don’t read the SOW word-for-word.
Instead, ask:
“What are we delivering?”
“What are we NOT delivering?”
“What are you expecting us to do?”
“What are you expecting to do?”
“What assumptions could cause us trouble?”
“What would you consider a change?”
That conversation can prevent hours—or even weeks—of conflict later.
And Here’s Where AI Can Help
This is also an excellent opportunity for AI.
Once you have an approved SOW, you can use AI to help identify potential scope gaps.
For example, ask AI to compare:
- SOW
- Requirements
- Meeting notes
- Project plan
- Change requests
Then ask:
“Identify requests or activities that may not be clearly covered by the approved project scope. Group them into In Scope, Potentially Out of Scope, and Requires Clarification. Do not make assumptions; identify the source information supporting each item.”
AI shouldn’t make the scope decision.
The PM still owns the decision.
But AI can help find the places where you need to have the conversation.
That’s where AI becomes valuable—not replacing the Project Manager, but helping the Project Manager see the project more clearly.
The Goal Isn’t Perfect Scope
Here’s the important lesson.
You don’t need a 50-page SOW to control scope.
You need clarity.
A good Project Manager creates a shared understanding of:
What we’re doing.
What we’re not doing.
Who is doing what.
What happens when something changes.
And when something inevitably does change, you don’t panic.
You evaluate it.
You communicate it.
You document it.
And you make a decision.
Because scope change isn’t necessarily bad.
Uncontrolled scope change is.
The Bottom Line
If your project doesn’t have a great SOW, don’t wait for the perfect opportunity to fix it.
Create a one-page Scope Snapshot.
Define:
IN → OUT → MAYBE → ASSUMPTIONS → RESPONSIBILITIES
Then use that as the foundation for every scope conversation going forward.
It doesn’t need to be complicated.
It needs to be clear enough that two people can read it and come to the same conclusion about what the project is supposed to deliver.
That’s the real purpose of scope.
Not paperwork.
Alignment.
