Contract Change vs. Scope Change: What Happens First?
admino
A stakeholder asks for a major change.
A seller is under contract.
What should happen first?
Should the project manager:
- approve the project change,
- modify the contract,
- ask the seller to begin,
- or analyze both impacts before anything is authorized?
This is a classic PMP® sequencing problem because several answers can sound reasonable.
The key is to separate two related questions:
Does the project need to change?
and
Does the contract need to change?
Those are separate decisions, but their impacts may need to be understood together.
A useful Project Reasoning Lab principle is:
Project authorization and contractual authorization are separate decisions — but project and contract impacts may need to be analyzed together before implementation begins.
1. Start With the Proposed Change
Consider:
A customer requests a new reporting feature that is not included in the approved scope.
Before anyone authorizes implementation, the project manager needs to understand the request.
That may involve assessing:
- scope,
- schedule,
- cost,
- risk,
- quality,
- resources,
- stakeholder impact.
If contracted work is involved, the PM may also need to understand:
- seller effort,
- pricing impact,
- delivery implications,
- acceptance criteria,
- contractual obligations.
The key distinction is:
Analysis can happen before approval. Implementation should not.
2. Project and Contract Impacts May Need to Be Assessed Together
Suppose:
The requested feature requires additional seller work.
Decision-makers may need to know the contractual consequences before deciding whether to approve the project change.
For example:
- How much additional seller effort is required?
- Does the price change?
- Does the delivery date change?
- Are new acceptance conditions needed?
So the sequence is not always:
approve the project change first → analyze the contract later
A better approach is:
Assess the project impact and, where relevant, the contractual impact before approval.
That gives the appropriate authorities enough information to make a sound decision.
3. A Project Scope Change Does Not Automatically Mean a Contract Change
Consider:
The project changes an internal reporting process, but no seller deliverable, price, responsibility, or schedule is affected.
The project may change.
The contract may not.
This is why:
Project scope and contract scope can overlap without being identical.
A project change only requires a contract change when the agreement itself is affected.
4. A Contract Change May Be Needed When Seller Obligations Change
Now consider:
A new approved requirement requires the seller to deliver additional functionality.
The seller’s obligations are affected.
The contract may need to be updated for:
- scope,
- price,
- schedule,
- responsibilities,
- deliverables,
- acceptance criteria.
The key question is:
Does the change alter what the seller is required to deliver or how the seller is expected to perform?
If yes, contractual modification may be necessary.
5. Do Not Start Seller Work Before the Required Authorization Exists
A tempting response is:
“The change is clearly needed. Let the seller start now and update the paperwork later.”
That can create:
- unapproved work,
- unclear payment obligations,
- schedule disputes,
- acceptance ambiguity,
- inconsistent project and contract records.
A stronger principle is:
Do not authorize seller work until the necessary project and contractual approvals are in place.
The impact analysis may happen early.
The work should wait for authorization.
6. Scenario: Customer Requests Additional Seller Work
Consider:
The customer requests an additional feature that will require 200 extra hours of seller development effort.
A weak response would be:
A. Tell the seller to begin immediately.
A stronger response is:
B. Assess the project and contract impacts, obtain the required approvals, modify the agreement if necessary, then authorize the work.
The important difference is sequence.
7. Scenario: Project Change With No Contract Impact
Consider:
The project changes an internal communication process, but no seller deliverable or obligation is affected.
The project may require internal updates.
The contract may remain unchanged.
So:
Not every project change becomes a contract change.
8. Scenario: Project Change Requires Contract Change
Now consider:
The project approves a new data-integration requirement that must be delivered by the seller.
The PM may need to evaluate:
- additional seller effort,
- price impact,
- schedule impact,
- acceptance conditions,
- contractual authority.
This is both:
a project change
and
a contract change
The two need to be aligned before implementation.
9. Contract Change Without Project Scope Change
The reverse can also happen.
Suppose:
The parties revise invoicing terms or administrative reporting requirements without changing project deliverables.
The contract changes.
The project scope may not.
This reinforces the distinction:
Contract change and project scope change are related, but not interchangeable.
10. Who Has Authority?
The PM may coordinate the change process, but approval authority may differ.
Project-side approval may involve:
- the PM,
- sponsor,
- product owner,
- change authority,
- governance body.
Contract-side approval may involve:
- procurement,
- contract administration,
- delegated commercial authority,
- other authorized management.
The useful question is:
Who has authority to approve the project change, and who has authority to modify the agreement?
Those may be different people.
11. Predictive, Agile, and Hybrid Environments
The project-side change mechanism may vary.
Predictive
A change may require formal impact analysis, change control, and baseline updates.
Agile
A requirement may be refined or reprioritized through backlog management and product authority.
Hybrid
Some work may change flexibly while contractual or baseline-controlled elements remain formal.
But one principle still applies:
Flexible delivery does not remove contractual authorization when seller obligations change.
12. Keep the Project and Contract Aligned
Suppose:
The project approves new functionality, but the seller contract still reflects the previous scope, price, and delivery date.
The project may assume more work can be delivered at the existing price and schedule while the contract still reflects the old obligations.
That creates inconsistency.
The PM should align:
- approved project scope,
- seller obligations,
- contract price,
- contract schedule,
- acceptance criteria.
A strong principle is:
A change is not fully ready for implementation if the project and contract are telling different stories.
13. Fixed Price Does Not Mean Unlimited Added Work
A fixed-price contract applies to the agreed scope.
If the buyer adds material new work, the change may require contractual modification.
So:
Fixed price does not mean the seller automatically absorbs every buyer-driven change.
The contract type does not eliminate the need to align new work with the agreement.
14. A Better Change Sequence
When a proposed change affects contracted work, use this sequence.
1. Identify the proposed change
What exactly is changing?
2. Assess project impact
Consider:
- scope,
- schedule,
- cost,
- risk,
- quality,
- resources.
3. Assess contract impact
If seller work is affected, consider:
- obligations,
- price,
- schedule,
- deliverables,
- acceptance criteria.
4. Obtain the required approvals
Use the appropriate project and commercial authorities.
5. Update project and contract records
Make sure the authorized project scope and seller obligations are aligned.
6. Authorize implementation
Only then should the affected seller work proceed.
This can be summarized as:
Assess → Approve → Align → Implement
15. Quick Comparison
| Situation | Project Change? | Contract Change? |
|---|---|---|
| Internal process changes, seller unaffected | Yes | Not necessarily |
| New seller-delivered feature approved | Yes | Likely yes |
| Payment terms revised, deliverables unchanged | Not necessarily | Yes |
| Customer suggests new feature, not yet approved | Proposed change only | No contractual modification yet |
| Buyer adds approved seller work | Yes | Yes |
| Administrative seller detail changes | No | Possibly administrative update |
| Scope change handled entirely in-house | Yes | No |
The concepts are connected, but they are not the same.
16. Three Common Traps
Trap 1: Project Change Approved = Seller Can Start
Not automatically.
The agreement may still need modification.
Trap 2: Contract Change = Project Scope Change
Not always.
Commercial or administrative terms can change without changing deliverables.
Trap 3: Fixed Price = Seller Absorbs All Added Work
No.
Buyer-driven additions may require a contractual change.
Final Takeaway
When a proposed change affects contracted work, separate two questions:
Does the project need to change?
Does the contract need to change?
Assess both where necessary.
Then obtain the right approvals.
Then align the project and contract records.
Then implement.
Assess the project and contract impacts, obtain the right approvals, align the records, then implement.
That is the sequencing the PMP scenario is really testing.
