Projects change. The owner’s job is to make sure the consequences of those changes are understood before they quietly become part of the project.
Originally published February 2013. Updated September 2026 to reflect current owner-side project governance and change-control practices.
A project can have a clearly defined scope and still change.
The business changes.
Someone identifies a requirement that was missed.
An operational group sees the design and realizes it won’t work.
A condition is discovered in the field.
Technology requirements evolve.
An executive asks for something different.
None of those automatically represents poor project management.
The problem begins when the project absorbs those changes without clearly answering:
“What does this do to the project?”
A seemingly reasonable request can affect design, procurement, construction, schedule, approvals and other work already underway.
The request may still be worth making.
But the owner should know what is being traded before saying yes.
Not Every Change Is Scope Creep
I wouldn’t label every change after the original scope is established as scope creep.
Some changes correct omissions.
Some respond to information that wasn’t available earlier.
Some protect the owner’s operational requirements.
Some create enough value to justify their cost.
And some really are unnecessary additions.
The important distinction is whether the change is identified, evaluated, authorized and incorporated deliberately.
Calling every change scope creep can create the wrong behavior. Teams may become reluctant to raise legitimate problems because they don’t want to be seen as changing the project.
I’d rather know about the problem while we still have options.
Find Out Why the Request Exists
When someone says:
“Can we add one more thing?”
my first question isn’t necessarily how much it costs.
It’s:
“What changed?”
Did we miss a requirement?
Did the business change?
Did someone misunderstand the approved design?
Did a field condition invalidate an assumption?
Is this a preference?
Or has someone identified something the project genuinely needs?
Those are different problems.
Understanding the reason for the request helps determine whether the project should accommodate it—and whether something in the planning or decision process needs attention.
One Change Rarely Stays in One Place
This is where seemingly small requests become expensive.
Move a wall and you may affect power, data, lighting, sprinklers, HVAC, ceilings, furniture and finishes.
Add equipment and you may affect electrical capacity, cooling, structure or controls.
Change furniture and you may affect power locations, technology, procurement lead times and installation sequencing.
Change an operational requirement and you may affect the layout itself.
The direct cost of the requested item may be the least important part of the decision.
The owner needs to understand the downstream consequences.
Put a Price on the Decision Before Making It
A change should not become part of the project merely because someone requested it.
Before approval, the owner should understand, to the extent reasonably possible:
- What is changing?
- Why is it changing?
- What does it cost?
- What happens to the schedule?
- What work must be redesigned or redone?
- Does it affect procurement or long-lead items?
- Does it create consequences elsewhere?
- Who has authority to approve it?
Not every change warrants weeks of analysis.
The level of review should be proportionate to the decision.
But the principle remains the same:
Make the consequence visible before the commitment is made.
Timing Changes the Cost of Change
The same decision can have very different consequences depending on when it occurs.
Changing a room configuration during programming may require little more than revising a plan.
Changing it after construction documents are complete may require redesign and coordination.
Changing it after materials have been ordered may create cancellation or restocking costs.
Changing it after construction is installed may mean demolition and rework.
That’s why timely owner decisions matter.
A $10,000 idea today can become a $50,000 idea later without becoming any more valuable.
Establish Who Can Change the Project
One of the easiest ways to lose control of scope is to allow informal direction to become project direction.
An end user tells the architect.
An executive tells the contractor.
Facilities tells a subcontractor.
A vendor tells someone in the field.
Everyone may be trying to help.
But the project needs a defined path for evaluating and authorizing changes.
People should be able to raise issues freely.
That doesn’t mean everyone should have authority to commit the project.
The owner needs to establish who can approve changes—and the project team needs to know when a request is merely being evaluated versus actually authorized.
Keep a Decision From Disappearing Into the Project
Once approved, a change has to be incorporated into more than a change log.
The drawings may need revision.
The budget needs updating.
The schedule may need adjustment.
Procurement may need direction.
Vendors may need new information.
Operations may need to understand the result.
Other decisions may now be affected.
A project can approve changes correctly and still lose control if those decisions aren’t carried through the rest of the project controls.
Look for Patterns
One change is a decision.
Twenty similar changes may be telling you something.
Repeated requests from users may indicate inadequate programming.
Repeated field changes may point to incomplete coordination.
Repeated executive changes may suggest that important decisions were made before leadership was aligned.
Repeated technology changes may indicate that the technology team entered the process too late.
The change log isn’t just an accounting mechanism.
It can be diagnostic.
Owners should periodically ask:
“Why are we changing this project so much?”
The answer may reveal a governance problem that is more important than any individual change order.
Don’t Protect the Budget by Building the Wrong Thing
There is also a danger in becoming so resistant to change that the team protects the original scope even after learning that it is wrong.
If a legitimate operational problem is discovered, refusing to address it because “the design is already approved” doesn’t eliminate the problem.
It may simply transfer it to operations after turnover.
Good change control isn’t about preventing change.
It’s about making change intentional.
Make the Tradeoff Explicit
Owners will sometimes knowingly approve a change that increases cost or delays the schedule.
That can be the right decision.
But it should be a conscious one:
“This is what we’re gaining. This is what it will cost. This is what it does to the schedule. We’re choosing to proceed.”
That’s very different from discovering three months later that dozens of individually reasonable requests have quietly changed the project.
Leadership takeaway: Projects will change. Establish a process that makes the reason, cost, schedule effect and downstream consequences visible before changes become commitments. The objective isn’t to eliminate change. It’s to keep the owner in control of it.
About the Author: Richard Neuman advises organizations on capital planning, project governance, and complex capital programs. He has overseen more than $2 billion in capital investments across commercial real estate, healthcare, utilities, industrial, broadcast, and development projects.
He writes candidly from an owner-side perspective about the executive decisions and organizational dynamics that shape capital project outcomes.
Leading a major capital program or facing a complex capital decision?
Contact Richard.
Subscribe for insights on capital planning, project governance, and the executive decisions that shape project outcomes long before construction begins.
Very good article. As a project manager and design build contractor I have had the project creep issue many times. You covered the topic well and I agree with your statement that you need a detailed and well thought out plan before you start. I have tried to explain that to customers and recently have had an issue with a project going over budget due to the customer adding work and not asking for an estimated cost and being suprised at the cost because they didn’t understand the amount of time and materials it would take. Making sure the customer gets a estimate even if they don’t ask for one can save alot of misunderstanding at the end. Again very good article.
I like to identify ‘must-haves’ and ‘nice-to-haves’ with client upfront and provide pricing alternates in bid documents to help save time if bids come in higher than approved budget — or get the CM on board early as BCCI points out to help with costing out alternates. I agree it is critical to obtain client sign-off at each phase of design prior to bid documents to effectively manage client expectations.
A great description of scope creep that all stake holders should read so they understand what is involved with a large project. I’m a Facilities leader that works closely with the project managers (PM) on projects in my buildings and understand what the PM’s have to deal with and how to explain to the stakeholders about changes after the project start.
Great post! Hiring the project team (architect, MEPS engineers, general contractor, furniture vendor, A/V consultant, cabling vendor, kitchen consultant, etc.) early on at the conceptual phase of a project adds significant value to the Owner/end user. It allows the team to align program, design, and budget expectations up front so that informed decisions – on everything from material selection to where power outlets should be located – can be made long before the start of construction. Identifying constructability issues and design conflicts before construction drawings are complete is also key to keeping the budget on target and avoiding scope changes and cost creep. Waiting to value engineer a project later in the game risks delaying the start of construction, which has its own cost implications.
That sums it up perfectly.