Scope Creep Isn’t the Problem. Starting Without a Baseline Is.
Here is an opinion that may irritate a few project managers and business owners:
Not everything people call “scope creep” is actually scope creep.
Sometimes nobody established the scope clearly enough in the first place. Think about it. A customer asks for something halfway through a project. The project team says:
“That’s out of scope.”
The customer responds:
“I thought that was included.”
Now everyone is frustrated.
The project manager thinks the client is expanding the work. The client thinks the team is trying to charge extra for something that was always expected. The business owner is caught in the middle. And nobody can answer the most important question:
What exactly did we agree to at the beginning?
That is why the scope baseline matters. A scope baseline creates the reference point. It defines the approved scope against which future requests can be evaluated. Without that reference point, “scope creep” becomes an argument instead of a management process.
For a project manager, the baseline is control. For a small business owner, the baseline is protection. It protects time. It protects margin. It protects customer expectations. It protects the team.
And, maybe most importantly, it protects the relationship between the business and the customer. Because disagreements about scope usually are not really about the work.
They are about expectations.
- What did the customer think they were buying?
- What did the business think it was delivering?
- What did the project manager think the team was responsible for?
If those three answers are different, the project already has a problem. The baseline exposes that difference early. That is a good thing. A scope baseline should create a shared definition of what the project is actually going to deliver. That includes more than a paragraph saying:
“Implement the new system.”
Or:
“Renovate the office.”
Or:
“Launch the new website.”
Those statements describe an idea. They do not establish a baseline. A useful baseline needs enough definition that the project team and the customer can both answer:
- What are we delivering?
- What are we not delivering?
- What requirements have been approved?
- What assumptions are we relying on?
- What constraints exist?
- What constitutes acceptance?
- How is the work organized?
- What happens when someone asks for something new?
That is where the work breakdown structure becomes so valuable. The WBS takes the project from a broad statement of intent and breaks it into the work required to produce the outcome.
It turns:
“Build the new customer portal” - into actual components.
- Requirements.
- Design.
- Authentication.
- Customer profile.
- Order history.
- Payment integration.
- Testing.
- Training.
- Deployment.
- Documentation.
- Whatever applies to the project.
Now the conversation becomes much clearer. If someone later asks for a loyalty rewards module and it does not appear anywhere in the approved scope or WBS, the team has something concrete to evaluate. That does not mean the answer automatically has to be no.
This is another place where I think project managers sometimes get scope management wrong. Change is not the enemy. Uncontrolled change is. A customer may have a legitimate new requirement, the business environment may change, a regulation may appear, a competitor may change the market, the original solution may no longer create enough value.
Good project management does not freeze the project in time. It gives the organization a disciplined way to change it.
That is exactly why the baseline exists. The baseline gives you a before-and-after.
- Here was the approved project.
- Here is the proposed change.
- Here is the effect on cost.
- Here is the effect on schedule.
- Here is the effect on resources.
- Here is the effect on risk.
- Here is the effect on the expected business outcome.
Now leadership can make a decision. Approve it - Reject it - Defer it - Trade something else out.
That is scope management. Without the baseline, those decisions become emotional.
- “Can’t you just add it?”
- “It shouldn’t take that long.”
- “I assumed that was already included.”
- “It’s only a small change.”
Those four sentences have destroyed more project margins than I can count. Small business owners should pay particular attention to this.
Large organizations may have contracts teams, PMOs, procurement departments, change-control boards, and legal counsel. Small businesses often have none of those.
The owner sells the work. The same owner may estimate the work. Someone on the team starts delivering it. The customer asks for a few changes.
Nobody wants to damage the relationship. So the team does the extra work. Then another request comes. Then another.
Three months later, the business owner looks at the project and wonders why the job made no money.
The answer may be simple: The business kept delivering work that was never included in the original price.
A scope baseline is not corporate bureaucracy. For a small business, it can be a margin-protection tool.
Imagine an electrical contractor bidding a commercial job. The customer asks for 40 fixtures.
The estimate is based on 40 fixtures. The work begins.
Later, the customer wants six more fixtures, two additional circuits, and relocation of several outlets. Those may all be reasonable requests. But they are changes.
Without a clear baseline, the contractor and customer may end up arguing about whether those items were “supposed to be included.”
With a baseline, the discussion is much simpler.
- Original scope.
- Requested change.
- Cost impact.
- Schedule impact.
- Decision.
The same principle applies to consultants, software companies, marketing agencies, construction firms, professional services firms. Anyone who delivers project-based work.
There is another reason the baseline matters. You cannot measure project performance against something that was never clearly defined.
- How do you know whether the project is 60% complete?
- How do you know whether you are behind?
- How do you know whether your estimate was accurate?
- How do you know whether the team delivered what was promised?
- How do you know whether the customer accepted the correct outcome?
The baseline becomes the reference point. That is why I believe scope development deserves far more attention than it gets. We often rush through scope because everyone wants to “start the project.” But starting faster does not necessarily mean finishing faster. Sometimes the fastest thing you can do is spend another day defining the work.
That is one of the reasons we built AltaVue Scope the way we did.
AltaVue Scope is designed to guide users through the thinking that should happen before a project baseline is approved:
- Project framing.
- Stakeholders.
- Expected outcomes.
- Scope.
- Requirements.
- Prioritization.
- Risk.
- Baseline.
The idea is simple:
Define the project once. Create a structured foundation. Then use that foundation throughout the project lifecycle. The WBS created through scope development should not disappear into a document. It should become the backbone of estimating, scheduling, tracking, agile work, time, and financial visibility.
That is the direction AltaVue is taking. Not another place to type a scope statement. A structured way to build a project from the problem through an approved baseline. Because the baseline should not be an afterthought. It should be the moment when the organization says: “This is the project we are agreeing to execute.”
Everything before that is discovery and planning. Everything after that is delivery against an agreed reference point. And when something changes? Good.
Evaluate the change - Understand the impact - Make a decision - Update the baseline when appropriate - Then keep moving.
That is not resisting change. That is controlling change.
So the next time someone says: “We have a scope creep problem.”
I would ask a different question first: “Show me the approved scope baseline.”
If nobody can produce one, scope creep may not be the real problem. The project may never have established the starting line.
