Is the project manager solving a problem—or changing what was approved?

A project team discovers that a critical testing activity is falling behind because a specialist is temporarily unavailable.

The project manager identifies two possible responses.

Option A: Reassign another qualified specialist, recover the delay, and continue within the approved project plan.

Option B: Extend the approved schedule baseline by two weeks to accommodate the delay.

Both options address the same issue.

But they have different implications for project governance.

The first may be possible within the project manager's existing authority. The second would modify an approved baseline and require authorization through the applicable change-control process.

This creates an important PMP® exam question:

Does the problem itself require a change request—or does the proposed response require one?

The distinction matters because not every issue requires a formal change request, and not every proposed solution can be implemented without approval.

A useful Project Reasoning Lab principle is:

Identify the issue first. Then determine whether the response changes something subject to formal control.

1. What Is an Issue?

An issue is a current condition that requires attention, assessment, or resolution.

Unlike a risk, which concerns uncertainty, an issue already exists.

Examples include:

• A specialist becomes unavailable.
• A supplier misses an agreed delivery date.
• A defect is discovered during testing.
• A stakeholder raises an unresolved concern.
• A technical dependency prevents work from progressing.
• An activity is delayed because required information has not arrived.

Each situation may affect project performance.

But identifying an issue does not automatically determine how it must be resolved.

For example, a delayed activity might be recovered through available float, resource reassignment, or adjustments to sequencing that are permitted within the existing plan.

Alternatively, the issue might require a change to approved scope, schedule, cost, or another controlled project element.

The important distinction is:

An issue describes what needs attention. It does not automatically determine the approval process for the response.

2. What Is a Change Request?

A change request is a formal proposal to modify something subject to the project's change-control process.

Depending on the project's governance arrangements, change requests may concern:

• The approved scope baseline.
• The approved schedule baseline.
• The approved cost baseline.
• Controlled requirements or deliverables.
• Project management plans or controlled documents.
• Technical designs or configurations.
• Corrective actions, preventive actions, or defect repairs requiring formal review.

An important nuance is that change requests are not limited to baseline changes.

A project may require formal authorization for certain technical modifications, corrective actions, or controlled document changes even when the main performance baselines remain unchanged.

For example, a defect repair might require approval under configuration management procedures because it modifies a controlled design.

The relevant question is:

Does the proposed response fall under the project's formal change-control requirements?

That determination depends on the nature of the proposed action, the change management plan, and delegated decision authority.

3. Issue Resolution vs. Change Request: The Essential Difference

The two concepts are closely related, but they serve different purposes.

Question	Issue Resolution	Change Request
Main focus	Addressing an existing problem	Proposing a controlled modification
What triggers it?	A current condition requiring attention	A proposed action subject to change control
Is formal change approval always required?	No	The request follows applicable review and authorization procedures
Can the PM act directly?	If authorized	Only within delegated change authority
Can both occur together?	Yes	Yes

Consider a supplier delay.

The project manager may investigate the cause, coordinate recovery, and update the issue log without requesting a baseline change.

However, if the proposed response requires extending the approved project completion date, formal change control may be necessary.

The same issue can therefore lead to different governance decisions.

The existence of a problem and the authorization required for its solution are separate questions.

4. Recording an Issue Is Not Approving a Change

This is an important distinction in PMP scenarios.

When an issue occurs, the project manager may need to:

• Record it in the issue log.
• Assign an owner.
• Assess its impact.
• Identify possible responses.
• Track resolution progress.
• Communicate its status.

These activities support issue management.

But recording an issue does not automatically authorize a controlled change.

Suppose a supplier reports a delay.

The PM documents the issue, analyzes its impact, and identifies a possible recovery plan.

That does not mean a proposed modification to the approved schedule baseline has already been authorized.

Similarly, submitting a change request does not mean that the change has been approved.

A useful distinction is:

Documentation records the problem. Authorization permits the controlled response.

The PM should keep issue management and change authorization connected—but not confuse them.

5. When Can the PM Resolve an Issue Without a Formal Change Request?

Many issues can be resolved within the existing project plan and delegated authority.

Consider three examples.

Resource Reassignment

A specialist becomes unavailable.

Another qualified specialist is available, and the PM is authorized to reassign the work without modifying controlled commitments.

The issue may be resolved without a formal change request.

Using Available Float

An activity is delayed by two days.

It has five days of usable total float, and schedule analysis confirms that the delay does not affect the approved completion date or another controlled commitment.

The PM may be able to manage the delay within the existing plan.

Clarifying a Requirement

A stakeholder misunderstands an approved requirement.

The PM facilitates clarification and confirms the existing interpretation.

If no controlled requirement or commitment changes, formal change control may not be necessary.

These examples share one characteristic:

The response can be implemented within existing authorization.

However, that does not eliminate the need for appropriate documentation, communication, or monitoring.

No formal change request does not mean no management responsibility.

6. When Does Issue Resolution Require Change Control?

An issue may require formal change control when the proposed response modifies a controlled project element or otherwise falls under established change-control requirements.

Changing the Approved Schedule Baseline

A technical problem creates a delay that cannot be recovered within the existing approved plan.

The proposed response is to extend the approved project completion date.

That baseline modification requires authorization through the applicable process.

Increasing the Approved Cost Baseline

Unexpected work creates additional cost.

The PM determines that the existing approved budget is insufficient and proposes an increase to the cost baseline.

The forecast may be updated to reflect the expected overrun, but an increased forecast does not automatically authorize additional budget.

Adding Scope

A stakeholder requests an additional feature outside the approved scope baseline.

The feature may create genuine business value.

But value alone does not authorize implementation.

The proposed addition must be evaluated and approved under the applicable governance arrangements.

Modifying a Controlled Technical Design

A defect requires a change to a configuration-controlled design.

Even if the repair does not affect the approved scope, schedule, or cost baselines, formal authorization may still be required.

This is the broader principle:

A baseline change is a clear reason to examine formal change control—but it is not the only reason.

7. Corrective Action Does Not Automatically Mean No Change Request

This is particularly important for PMP exam reasoning.

A corrective action is intended to bring project performance back into alignment with the project management plan.

However, the purpose of an action does not automatically determine its approval requirements.

Suppose a project is behind schedule.

The PM proposes reassigning qualified personnel within existing resource and cost authority.

If permitted by the project's governance arrangements, that action may be implemented without a formal change request.

Now suppose the proposed recovery requires additional funding beyond the approved cost baseline.

The action remains corrective in purpose.

But implementing it may require a formal change request.

Likewise, a corrective action may itself be subject to integrated change control even when no baseline modification is proposed.

Therefore, avoid the simplistic rule:

Corrective action = no change request.

Instead:

An action can be corrective in purpose and still require formal approval before implementation.

This distinction also applies to preventive actions and defect repairs.

8. Scenario: A Supplier Delay Does Not Automatically Require a Baseline Change

Consider this PMP-style scenario.

A supplier reports that specialized equipment will arrive five days late.

The sponsor requests an immediate change to the approved project completion date.

However:

• The affected activity has seven days of usable total float.
• No additional schedule constraints are affected.
• The supplier has confirmed the revised delivery date.
• Schedule analysis indicates that the approved project finish date remains achievable.

What should the project manager do first?

The PM should assess the actual impact of the supplier delay, manage the issue, and determine whether the proposed baseline extension is necessary.

Because the delay can be absorbed within available schedule flexibility, a change to the approved completion date is not automatically justified.

The issue still requires attention.

The supplier's performance may still need monitoring.

The remaining float has decreased.

But the evidence does not currently demonstrate a need to extend the approved baseline.

An issue may consume project flexibility without requiring a change to the approved baseline.

This is an important connection to critical-path and float analysis.

9. Scenario: Formal Approval Is Required Without a Baseline Change

Now consider a different situation.

During testing, the project team discovers a technical defect in a controlled system design.

The proposed repair:

• Does not increase the approved project budget.
• Does not extend the approved schedule baseline.
• Does not change the approved scope baseline.
• Does modify a configuration-controlled technical component.

The project's configuration management procedures require formal approval before that component can be modified.

Should the PM authorize the repair immediately?

Not without the required authorization.

The PM should document the defect, assess the proposed repair, and follow the applicable configuration and change-control procedures.

The fact that the main project baselines remain unchanged does not eliminate the approval requirement.

The important distinction is:

A change request may be necessary even when the cost, schedule, and scope baselines remain unchanged.

This is why PMP candidates should not use baseline impact as the only test for formal change control.

10. Scenario: A Regulatory Change Requires a Controlled Response

A new regulatory requirement becomes applicable during project execution.

Compliance requires additional testing and a new deliverable not included in the approved scope.

The change also increases expected project cost.

What should the PM do next?

The PM should assess the regulatory requirement, determine its effect on project commitments, and initiate the appropriate change-control process.

The additional controlled work should not simply be treated as though the original approval already covered it.

However, immediate legal, safety, or compliance obligations must still be addressed appropriately. Routine approval procedures should not become a reason to ignore urgent mandatory action.

The key distinction is:

The obligation to comply may be mandatory, while the project's implementation changes still require appropriate governance.

11. What Happens When Formal Change Control Is Required?

When the proposed response is subject to formal change control, the PM should follow the project's established process.

A typical sequence is:

Identify the issue

Understand the existing problem

Assess response options and impacts

Evaluate scope, schedule, cost, risk, and other consequences

Check change-control requirements

Determine the applicable process and authority

Obtain required authorization

Submit and review the change as required

Implement and update records

Communicate the decision and update controlled documents

The precise steps depend on the project's governance framework, and some analysis and documentation activities may occur in parallel.

The central principle remains:

Evaluate the proposed response, determine its authorization requirements, and implement controlled changes only when appropriately authorized.

12. The Role of Authority and Governance

Not every project decision requires escalation.

But not every decision belongs to the project manager.

Depending on the project's governance arrangements, decision authority may rest with:

• The project manager.
• The project sponsor.
• A change control board.
• A designated technical or compliance authority.
• A product owner within delegated product authority.
• Another authorized organizational decision-maker.

For example, a PM may be authorized to reassign resources within the approved budget but not to approve an increase in the cost baseline.

Similarly, a technical authority may need to approve modifications to a controlled design.

The correct PMP reasoning is neither:

Always escalate.

Nor:

Always resolve the problem independently.

Instead:

Act within delegated authority. Seek authorization when the proposed response exceeds that authority.

13. Predictive vs. Agile vs. Hybrid: Does the Answer Change?

Change governance depends partly on the delivery approach.

In predictive projects, approved baselines and integrated change control often play a central role. Modifications to controlled commitments may require formal review and approval.

In agile projects, backlog refinement and reprioritization may occur within established product decision authority without every adjustment becoming a formal project-level change request. However, controlled funding, contractual, compliance, or organizational commitments may still require additional authorization.

In hybrid projects, different components may follow different governance mechanisms.

The principle is:

The delivery approach influences how changes are managed, but it does not eliminate the need for appropriate authorization.

14. Project Reasoning Lab: Five-Question Change Test

When a PMP scenario presents a current problem and a proposed solution, ask five questions.

1. What is the actual issue?Identify the current condition without assuming the first proposed solution is necessary.
2. What response is being considered?Separate the problem from the action intended to resolve it.
3. Does the response require formal change control?Examine controlled baselines, requirements, configurations, documents, and applicable procedures.
4. Who has authority to approve or implement the response?Determine whether the PM can act or another decision-maker must authorize the change.
5. What must happen before implementation?Identify the required analysis, documentation, authorization, communication, and updates.

Issue → Response → Change-Control Requirement → Authority → Action

This framework helps prevent two opposite mistakes:

• Requesting formal changes unnecessarily.
• Implementing controlled changes without required authorization.

15. Five Common PMP Traps

Trap 1: Every Issue Requires a Change Request

No.

An issue may be resolved within existing authority and approved commitments.

The proposed response and applicable governance determine whether formal change control is necessary.

Trap 2: No Baseline Change Means No Change Request

No.

Controlled technical modifications, corrective actions, defect repairs, and document changes may require formal authorization even when the main baselines remain unchanged.

Trap 3: Corrective Actions Never Require Change Requests

No.

A corrective action may itself be subject to formal change control.

Its purpose does not determine its authorization requirements.

Trap 4: Recording an Issue Means the Proposed Solution Is Approved

No.

Issue documentation and change authorization are separate activities.

The issue log records and tracks the problem. It does not automatically authorize a controlled modification.

Trap 5: Every Delay Requires a Schedule Baseline Change

No.

Analyze the critical path, float, dependencies, constraints, and forecast impact before concluding that the approved schedule must change.

Final Takeaway

When a problem appears during project execution, do not automatically submit a change request.

First determine:

What is the actual issue?

What response would resolve it?

Does the response require formal change control?

Who has authority to authorize the action?

What must happen before implementation?

The central distinction is:

An issue tells the project manager what needs to be resolved. The proposed response—and the project's governance requirements—determine whether formal change control is necessary.

And the broader Project Reasoning Lab principle is:

Do not confuse the need to solve a problem with the need to change what has been approved.

The strongest PMP answers come from understanding both the project condition and the authorization requirements surrounding the proposed response.