Change Request vs. Change Approval: What Can the PM Do Before Approval?
admino
Requesting is not authorizing.
A project sponsor approaches the project manager with an urgent request.
Senior management wants to add a reporting dashboard to the project deliverables. The feature would provide useful performance information, but it was not included in the approved scope and would require additional development effort.
The sponsor explains:
“This is important. Please have the team start immediately. We can complete the paperwork afterward.”
The project manager recognizes the potential business value of the request.
However, the project’s change management plan requires formal authorization for modifications to the approved scope baseline.
What should the project manager do next?
Should the PM immediately direct the team to begin because the sponsor requested the feature?
Should the PM reject the request because it was not included in the original plan?
Or should the PM document the request, assess its impact, and follow the required change-control process before implementation?
The third response reflects the appropriate reasoning.
The sponsor’s request may be legitimate. The proposed feature may be valuable. But neither condition automatically authorizes the project team to perform the additional work.
This distinction is central to PMP® exam scenarios involving change control:
A request creates something to evaluate. Approval creates authorization to proceed.
The project manager can perform important work before approval. The challenge is recognizing the boundary between evaluating a proposed change and implementing an authorized one.
1. Change Request vs. Change Approval: What Is the Difference?
A change request is a formal proposal to modify a controlled project element or take an action governed by the project’s change-control procedures.
Depending on the project, a change request may concern:
- Approved scope, schedule, or cost baselines.
- Controlled requirements or deliverables.
- Technical designs and configurations.
- Project management plans or controlled documents.
- Corrective actions, preventive actions, or defect repairs subject to formal change control.
A request identifies a proposed modification. It does not establish that the modification has been authorized.
Change approval, by contrast, is an authorization decision made by the appropriate authority under the project’s governance arrangements.
The distinction is straightforward but important.
| Change request | Change approval |
|---|---|
| Proposes a modification | Authorizes a modification |
| Identifies a desired outcome | Establishes an authorized decision |
| May require clarification and impact analysis | Follows the applicable review and decision process |
| Can be supported by a PM recommendation | Must be granted by the designated authority |
| Does not itself authorize implementation | Permits implementation within the approved conditions |
Consider a stakeholder who requests an additional feature.
The PM may estimate the cost, evaluate the schedule consequences, assess risks, and recommend approval.
None of those activities automatically adds the feature to the approved project scope.
The request remains a proposal until the appropriate authorization has been granted.
There is also an important qualification: approval does not necessarily mean the team can begin immediately.
An approved modification may still require procurement authorization, regulatory clearance, updated implementation instructions, or other prerequisites.
For PMP reasoning, keep these concepts separate:
Request → Evaluation → Authorization → Implementation
The precise process may vary, but requesting, approving, and implementing are different activities.
2. What Can the Project Manager Do Before Approval?
A project manager is not expected to remain passive while a change request awaits a decision.
The PM can perform substantial analysis, coordination, and preparation, provided those activities remain within existing authority.
The most useful distinction is between three categories of work.
| Activity | What the PM can do before approval |
|---|---|
| Analysis | Clarify, document, investigate, estimate, and evaluate the proposed change |
| Preparation | Develop alternatives and implementation plans within existing authority |
| Execution | Do not implement the proposed controlled change until the required authorization is obtained |
Document the Request
The PM should ensure that the proposed change is captured through the project’s established process.
The documentation should identify what is being requested, why it is needed, who requested it, and which project elements may be affected.
Clear documentation creates a reliable basis for evaluation.
However, entering a request into the change log does not approve it.
Clarify the Business Need
Before evaluating the proposed solution, the PM should understand the underlying need.
For example, a sponsor requests a new dashboard.
But the real objective may be to provide senior management with more frequent performance information.
That need might be satisfied through an existing reporting tool, a smaller enhancement, or a change in reporting practices.
The PM should distinguish the business need from the stakeholder’s preferred solution.
A requested solution should be evaluated against the problem it is intended to solve.
Assess the Impact
Impact analysis helps decision-makers understand the consequences of approving or rejecting the proposed change.
The PM should examine the areas relevant to the request.
| Area | Questions to investigate |
|---|---|
| Scope | What additional or modified work is required? |
| Schedule | How could activities, dependencies, milestones, or forecasts change? |
| Cost | What additional expenditure or funding may be necessary? |
| Resources | Are qualified personnel and necessary equipment available? |
| Quality | Could the modification affect performance or acceptance requirements? |
| Risk | What new uncertainties or exposures would arise? |
| Benefits | Does the expected value justify the consequences? |
| Dependencies | What other work, suppliers, or deliverables would be affected? |
For example, a requested feature may require only five days of development but introduce three weeks of integration and testing.
Without impact analysis, the decision-maker may underestimate the actual consequences.
Consult Experts and Develop Alternatives
The PM may seek input from technical specialists, team members, procurement professionals, compliance personnel, or other subject-matter experts.
The PM can also evaluate alternatives, including a smaller modification, a later release, or using existing capabilities.
These activities help improve the decision.
Prepare a Recommendation
After evaluating the request, the PM may recommend approval, rejection, deferral, or further analysis.
The recommendation should explain the expected benefits, costs, risks, and consequences.
However, unless the PM has the required delegated authority, the recommendation is not the authorization decision.
The project manager can prepare an informed decision before approval—but cannot treat the proposed change as authorized work.
One important boundary remains: preliminary analysis and preparation must themselves be authorized. The PM cannot incur unauthorized expenditure or create binding commitments merely by calling the activities preparation.
3. What Should the PM Not Do Before Approval?
The project manager must distinguish between preparing a decision and acting as though the decision has already been made.
For a proposed change requiring formal approval, the PM should not prematurely:
- Direct the team to develop an unapproved feature.
- Commit additional funding outside delegated authority.
- Order materials specifically for an unapproved modification.
- Instruct a supplier to perform changed work without the required contractual authorization.
- Replace approved baselines with proposed values.
- Communicate a proposed completion date as though it were an approved baseline.
Consider a proposed change that would extend the project by three weeks.
The PM can model the schedule consequences and present a proposed revised schedule.
However, the analysis does not automatically replace the approved schedule baseline.
Likewise, the PM may estimate that the change would increase project cost by $60,000.
That estimate supports the decision, but it does not authorize the additional expenditure or establish a revised approved cost baseline.
This distinction connects directly to cost and schedule forecasting.
A forecast describes an expected outcome. An approved baseline establishes an authorized performance reference.
A proposed forecast may illustrate what could happen if the change is approved. It does not itself authorize a baseline modification.
The governing principle is:
Preparation supports a decision. Implementation acts on that decision.
4. Does Sponsor Support Mean the Change Is Approved?
A sponsor may have substantial influence over a project.
The sponsor may provide funding, support strategic alignment, resolve organizational obstacles, and participate in governance decisions.
But sponsor support and formal change approval are not necessarily equivalent.
Consider This Scenario
The project’s change management plan gives the sponsor authority to approve scope changes with an estimated cost impact of up to $25,000.
Changes exceeding that threshold require approval from a designated change control board (CCB).
The sponsor requests a new feature estimated to cost $40,000.
The sponsor tells the PM:
“I support this change. Please proceed.”
Can the PM authorize the team to begin?
Not based on that statement alone.
The proposed change exceeds the sponsor’s delegated approval threshold.
The PM should complete the required analysis and submit the change to the designated authority.
Now consider a different situation.
The proposed change costs $15,000, falls within the sponsor’s delegated authority, and satisfies the applicable approval procedure.
In that case, the sponsor may be able to authorize the change without CCB review.
The difference is not the sponsor’s enthusiasm or seniority.
It is the authority established by project governance.
Approval authority depends on the project's decision rules—not simply on who requests the change.
This principle also applies across delivery approaches. In an agile environment, a product owner may have authority to reprioritize backlog items within agreed boundaries. At the same time, changes to controlled funding, contractual commitments, or organizational requirements may require additional authorization.
The PM must identify the applicable authority rather than assume that every change requires the same approval mechanism.
5. What Happens While a Change Request Is Pending?
A pending change request does not automatically require the entire project to stop.
Suppose a proposed technical modification affects one component of a larger system.
While the request is under review, the team may continue unrelated activities under the existing approved plan.
However, the PM should evaluate whether continuing certain work could create unnecessary rework or other risks.
For example, a proposed design modification may affect an interface that another team is about to develop.
If the interface work proceeds unchanged, the team may later need to repeat part of that work.
The PM should assess dependencies and coordinate appropriately within existing authority.
Depending on the circumstances, the PM may:
- Continue unaffected authorized work.
- Communicate the uncertainty to relevant team members.
- Evaluate rework exposure and schedule consequences.
- Adjust authorized work sequencing where permitted.
- Seek direction when the proposed response exceeds delegated authority.
The important distinction is:
A pending request does not authorize the proposed new work, but it does not automatically suspend all existing work.
The PM should maintain delivery progress without creating unauthorized commitments.
6. What Happens After the Change Decision?
A change request does not always result in a simple approval or rejection.
The authorized decision-maker may approve, reject, defer, conditionally approve, or request further information.
Each outcome requires a different response.
| Decision outcome | Appropriate PM response |
|---|---|
| Approved | Record and communicate the decision, update applicable controlled records, and coordinate authorized implementation |
| Rejected | Record and communicate the decision; do not implement the rejected modification |
| Deferred | Track the pending request and continue authorized work as appropriate |
| More information required | Complete the requested analysis and return the proposal for decision |
| Conditionally approved | Confirm the conditions and satisfy the applicable requirements before proceeding |
Approval Is Not Always Immediate Implementation
Suppose a CCB approves a technical modification that requires a supplier to perform additional work.
The project-level change has been approved.
However, thesupplier’ss contract requires a formal amendment before the additional work can begin.
The PM should not assume that CCB approval alone authorizes the supplier to proceed.
The relevant contractual authorization must also be completed.
This illustrates an important distinction:
Approval authorizes the change under the applicable governance process. Implementation begins when the relevant authorization and execution prerequisites have been satisfied.
This subject deserves deeper examination in our next article on approved changes and implementation readiness.
For now, remember that the PM must recognize both the approval decision and any remaining conditions.
7. Three PMP Scenarios: What Can the PM Do Right Now?
Scenario A: The Sponsor Wants Immediate Implementation
A sponsor requests an additional dashboard feature that would increase the approved scope and cost baselines.
The sponsor emphasizes its business importance and asks the PM to begin immediately.
The change management plan requires CCB approval for this type of modification.
What should the PM do first?
The PM should clarify and document the request, assess its impacts, and submit it through the required change-control process.
The sponsor’s support is relevant, but it does not replace the designated approval authority.
Reasoning: Business importance establishes a reason to evaluate the change—not permission to implement it.
Scenario B: The CCB Requests More Information
A PM submits a proposed scope change to the CCB.
The request includes the expected benefits and an initial cost estimate.
However, the schedule impact is uncertain, and the proposal does not adequately address integration risk.
The CCB returns the request for additional analysis.
What should the PM do next?
The PM should coordinate the necessary schedule and risk assessments, update the request, and return it through the established process.
The PM should not treat the request as approved.
Nor should the PM automatically assume it has been rejected.
The important distinction is:
Returned for analysis does not mean rejected—and it certainly does not mean approved.
The decision-maker needs additional information before reaching an authorization decision.
Scenario C: An Urgent Security Problem Appears
During project execution, the technical team discovers a critical security vulnerability.
Immediate containment is necessary to prevent further exposure.
A permanent technical modification is proposed, but that modification is subject to formal configuration and change control.
Must the PM wait for approval of the permanent modification before taking any action?
Not necessarily.
The PM should distinguish immediate protective actions from the proposed permanent controlled modification.
If established incident-response or emergency procedures authorize immediate containment, those actions should proceed under the applicable requirements.
The permanent modification should follow the required change-control process, including any applicable expedited or emergency approval procedure.
The key principle is:
Urgency changes the response priority. Established emergency authority determines which actions may proceed immediately.
Urgency does not automatically give the PM unlimited authority to bypass governance.
8. Project Reasoning Lab: The Five-Step Pre-Approval Test
When a PMP scenario involves a proposed change, use the following reasoning framework.
Step 1 — Request
What modification is being proposed?
Identify the requested change and the business need behind it.
Do not assume that the proposed solution is the only way to achieve the desired outcome.
Step 2 — Impact
What would change, and what are the consequences?
Evaluate relevant scope, schedule, cost, quality, resources, risk, dependencies, and benefits.
Determine whether the request is supported by sufficient information.
Step 3 — Authority
Who is empowered to make the decision?
Identify the designated approval authority, including any delegated limits, thresholds, or conditions.
Do not confuse sponsor support with formal approval authority.
Step 4 — Decision
Has the required authorization actually been granted?
Determine whether the request is approved, rejected, deferred, conditionally approved, or awaiting further information.
A completed analysis or PM recommendation does not substitute for this decision.
Step 5 — Action
What work is now permitted?
Implement authorized changes when the applicable conditions and prerequisites have been satisfied.
Communicate the decision and update relevant project records.
The Five-Step Framework
Request → Impact → Authority → Decision → Action
This is a reasoning framework, not a rigid administrative sequence.
For example, the PM may identify the approval authority while conducting impact analysis. Authorized ongoing work may also continue while the decision is pending.
The purpose is to distinguish the proposed modification, its consequences, the required decision rights, and the actions permitted at the current stage.
9. PMP Scenario Challenge: Choose the Best Next Action
A project sponsor requests an additional feature that would increase project cost.
The project manager completes the impact analysis and recommends approval.
The sponsor expresses strong support.
However, the project’s change management plan requires CCB authorization for this type of modification.
The development team is available and asks whether it should begin immediately.
What should the project manager do next?
A. Direct the team to begin because the sponsor supports the change and the resources are available.
B. Update the cost baseline to reflect the estimated increase, then assign the work.
C. Submit the change for the required approval while continuing appropriate authorized work.
D. Reject the request because the additional feature was not included in the original project scope.
Correct Answer: C
The PM has completed the impact analysis and identified the required approval authority.
The next appropriate step is to submit the proposed change for the required decision.
The team may continue appropriate authorized work while the request is pending, but it should not begin implementing the controlled modification without authorization.
Why the Other Answers Are Incorrect
A — Incorrect. Sponsor support and resource availability do not replace the required CCB approval.
B — Incorrect. The PM cannot treat the proposed cost increase as an approved baseline modification before receiving the necessary authorization.
D — Incorrect. A change request should not automatically be rejected merely because it concerns work outside the original scope. Change control evaluates proposed modifications and determines whether to authorize them.
What Is This Question Really Testing?
The question is not asking whether the proposed feature is valuable.
It is testing whether the candidate recognizes the difference between:
- Sponsor support.
- Completed impact analysis.
- PM recommendation.
- Formal change authorization.
The strongest answer respects the project’s approval requirements while allowing authorized work to continue.
10. Five Common PMP Traps
Trap 1: The Sponsor Requested It so that the PM Can Start
Not necessarily.
The sponsor may support the change but lack the authority to approve that specific modification.
Better reasoning: Check delegated authority, thresholds, and the applicable approval process.
Trap 2: The Impact Analysis Is Complete, So the Change Is Approved
No.
Impact analysis provides information for a decision.
It does not replace authorization.
Better reasoning: Distinguish assessment from approval.
Trap 3: A Pending Change Request Means All Work Must Stop
No.
Unaffected, authorized work can generally continue where appropriate.
Better reasoning: Identify affected dependencies and manage rework exposure without implementing unapproved changes.
Trap 4: An Urgent Problem Automatically Allows the PM to Bypass Change Control
No.
Urgency may activate emergency procedures, but those procedures establish the authority and conditions for immediate action.
Better reasoning: Distinguish emergency response authority from authorization for permanent controlled modifications.
Trap 5: Once a Change Is Approved, All Related Work Can Begin Immediately
Not always.
Implementation may depend on conditions, contractual authorization, regulatory clearance, or other prerequisites.
Better reasoning: Confirm both the approval decision and the requirements for authorized execution.
11. Final Takeaway: Requesting Is Not Authorizing
Return to the opening scenario.
The sponsor wants an additional dashboard and asks the PM to start immediately.
The request may offer genuine business value.
But the project manager should neither reject it automatically nor implement it merely because an influential stakeholder supports it.
Before approval, the PM can clarify the business need, document the proposal, assess impacts, consult experts, evaluate alternatives, and prepare a recommendation.
The PM can also continue appropriate authorized work while the request is pending.
The PM cannot treat an unapproved controlled modification as though it has already been authorized.
The central distinction is:
Before approval, the project manager can prepare an informed decision—but cannot treat the proposed change as authorized work.
And the broader Project Reasoning Lab principle is:
Requesting is not authorizing. Analyzing is not approving. Recommending is not implementing.
Strong PMP reasoning requires recognizing not only whether a proposed change makes sense, but also what the project manager is authorized to do at the current stage of the decision process.
Clear Thinking. Better Projects.
