Overview
Change and issues management are core competencies tested heavily on the PMP exam. This guide covers the formal change control process, issues identification and resolution, agile/hybrid approaches, and the tools used to manage both changes and issues. Understanding the distinctions between these concepts — and knowing when and how to apply them — is essential for exam success.
---
1. The Change Control Process
What Is Integrated Change Control?
Perform Integrated Change Control is a monitoring and controlling process that reviews all change requests and manages their approval, rejection, or deferral. It considers the holistic impact of any proposed change across the entire project — not just the area directly affected.
Types of Change Requests
| Type | Definition | Timing |
|------|-----------|--------|
| Corrective Action | Realigns current performance with the plan | Reactive — after deviation occurs |
| Preventive Action | Ensures future performance stays aligned | Proactive — before deviation occurs |
| Defect Repair | Fixes a flaw in a project component or deliverable | After defect is identified |
> Key Concept: All three types must go through the formal change control process. No change is self-approved — not even by the project manager.
The Change Control Board (CCB)
The Change Control Board (CCB) is a formally chartered group with authority to:
• Review and evaluate change requests
• Approve, reject, defer, or request more information
• Document and communicate all decisions
Key Terms
• Change Request — A formal proposal to modify any document, deliverable, or baseline
• Approved Change Request — The official authorization directing the team to implement the change
• Project Baseline — The approved version of scope, schedule, or cost used as a comparison point; can only be updated through an approved change request
• Configuration Management System — Tracks and controls changes to project deliverables and documents, ensuring integrity and traceability
Scope Creep vs. Gold Plating
| Concept | Source | Authorization |
|---------|--------|--------------|
| Scope Creep | External stakeholders or environment | Unauthorized expansion of scope |
| Gold Plating | The project team itself | Unauthorized additions, even with good intentions |
Both are problems. Neither is acceptable without a formal approved change request.
Evaluating a Change Request
Before submitting to the CCB, a change impact assessment (impact analysis) must be performed. This evaluates the effect on:
• Scope — What work is added, removed, or modified?
• Schedule — Does the timeline change?
• Cost — What are the budget implications?
• Quality — Are quality standards affected?
• Risk — Does this introduce new risks?
• Resources — Are additional people or materials needed?
> The most critical input when evaluating impact is the project management plan and its baselines, since they define what was originally approved.
Watch Out For ⚠️
• Never skip the process. If a team member implements a change without approval, the PM must document it and submit a formal change request to either legitimize or reverse it — do not simply accept or ignore it.
• Baselines are sacred. They can only change through an approved change request. Informal updates are never acceptable.
• Corrective vs. preventive is a common trick question. If the problem already happened, it's corrective. If you're acting before the problem, it's preventive.
---
2. Issues Management
What Is an Issue?
An issue is a current problem or concern that requires immediate attention and resolution. It is not a future uncertainty — it is something happening now.
Issue vs. Risk
| Concept | Timeframe | Nature |
|---------|-----------|--------|
| Risk | Future — may or may not occur | Uncertain event |
| Issue | Present — already occurring | Actual problem requiring action |
> Key Relationship: When a risk occurs, it typically becomes an issue and moves from the risk register to the issue log.
The Issue Log
The issue log is the primary tool for tracking and managing issues. It contains:
• Issue description
• Assigned owner (responsible for resolution)
• Target resolution date
• Current status
• Final resolution notes
Who owns resolution? The issue owner assigned in the log — though the project manager oversees the overall process and holds accountability.
When to Escalate an Issue
Escalate when the issue:
• Cannot be resolved within the PM's authority or resources
• Threatens project objectives (scope, schedule, cost, quality)
• Requires a decision from senior management or the sponsor
• Persists unresolved beyond its target date
Which Process Group?
Issues are primarily managed during the Executing process group, specifically within Direct and Manage Project Work, where day-to-day project execution surfaces problems that must be identified, logged, and resolved.
Key Terms
• Issue — A current problem requiring immediate action
• Issue Log — Document tracking all active issues, owners, dates, and status
• Issue Owner — Individual responsible for resolving a specific issue
• Escalation — Elevating an issue to a higher authority when it exceeds the PM's ability to resolve
Watch Out For ⚠️
• Risks ≠ Issues. The exam frequently tests whether you know the difference. If something might happen, it's a risk. If it's already happening, it's an issue.
• Don't confuse the issue log with the change log. The issue log tracks problems; the change log tracks change requests and their status.
• The PM oversees but does not always resolve. The assigned issue owner resolves the issue; the PM monitors and escalates when needed.
---
3. Agile & Hybrid Change Management
Agile Philosophy on Change
In agile/adaptive environments, change is welcomed rather than controlled through a formal CCB. The key mechanisms are:
• Backlog refinement — Continuously updating and reprioritizing the product backlog
• Sprint/iteration planning — Deciding which backlog items to address in the next cycle
• Product Owner authority — The Product Owner manages and prioritizes change requests by adding, removing, or reprioritizing backlog items
The Product Backlog
The product backlog is the single authoritative source of work for the agile team. It:
• Is owned and continuously managed by the Product Owner
• Allows changes to be incorporated in a transparent and controlled manner
• Reflects current priorities based on stakeholder feedback and new information
Agile Issues Management: Impediments
In agile, issues are commonly called impediments — anything that blocks the team from completing its work.
| Role | Responsibility |
|------|---------------|
| Team Members | Resolve impediments within their own control |
| Scrum Master | Removes impediments outside the team's control; protects the team |
The Sprint Retrospective & Issues
The sprint retrospective is a dedicated meeting at the end of each sprint where the team:
• Identifies issues, impediments, and process gaps from the sprint
• Discusses what went well and what needs improvement
• Creates action items to address problems in future sprints
> This is agile's structured approach to continuous improvement and ongoing issues management.
Predictive vs. Agile Change Management
| Dimension | Predictive | Agile |
|-----------|-----------|-------|
| Change philosophy | Controlled, minimize change | Embrace change as value |
| Approval mechanism | CCB review and approval | Product Owner prioritization |
| Change documentation | Formal change request + log | Backlog item |
| Frequency of change review | As needed | Every sprint/iteration |
Watch Out For ⚠️
• Agile does not mean "no control." Change is still managed — just through the backlog and Product Owner rather than a CCB.
• The Scrum Master removes impediments — they do not manage scope or approve changes. Know the role distinctions.
• Retrospectives are about process, not product. They address how the team works, not what they are building.
---
4. Tools and Documentation
Change Log vs. Issue Log
| Feature | Change Log | Issue Log |
|---------|-----------|-----------|
| Tracks | Change requests and their status | Active problems requiring resolution |
| Statuses | Submitted, under review, approved, rejected, deferred | Open, in progress, resolved, closed |
| Purpose | Audit trail of baseline change requests | Resolution tracking of current problems |
| Trigger | Formal change request submitted | Problem or concern identified |
Configuration Management System
A configuration management system ensures:
• All project artifacts are properly identified and versioned
• Changes are tracked with full traceability
• The integrity of deliverables is maintained throughout the project lifecycle
• Stakeholders always know they are working from the current, approved version
Key Process: Perform Integrated Change Control — Inputs, Tools, Outputs
Key Inputs:
• Project management plan (including baselines)
• Change requests
• Work performance reports
Key Tools:
• Change control meetings
• Impact analysis / change impact assessment
• Expert judgment
Key Outputs:
• Approved (or rejected/deferred) change requests
• Updated project management plan components
• Updated project baselines
• Updated project documents
Watch Out For ⚠️
• Outputs of Integrated Change Control include updated baselines — but only when a change is approved. Rejected changes do not update anything.
• Impact analysis comes before CCB review, not after. You assess impact so the CCB can make an informed decision.
• Configuration management ≠ change management, but they work together. Configuration management tracks versions and integrity; change management governs what changes are authorized.
---
Quick Review Checklist ✅
Use this before exam day to confirm your readiness:
• [ ] I can define and distinguish corrective action, preventive action, and defect repair
• [ ] I know that all change requests must go through the formal integrated change control process
• [ ] I understand the role and authority of the Change Control Board (CCB)
• [ ] I can explain the difference between scope creep and gold plating
• [ ] I know that project baselines can only be updated via approved change requests
• [ ] I can distinguish between a risk (future/uncertain) and an issue (present/actual)
• [ ] I know the purpose and contents of the issue log vs. the change log
• [ ] I understand when and how to escalate an issue
• [ ] I can explain how agile manages change through the product backlog and Product Owner
• [ ] I know the Scrum Master's role in removing impediments
• [ ] I understand what happens in a sprint retrospective related to issues
• [ ] I can describe what a configuration management system does and why it matters
• [ ] I know impact analysis is performed before submitting a change to the CCB
• [ ] If a team member makes an unauthorized change, I know the PM must document and formally process it — not ignore it
---
> Final Exam Tip: On situational questions, the PMP exam almost always rewards the answer that follows process first. When in doubt: Document it. Submit a change request. Escalate if needed. Skipping the process is almost never the right answer.