Manage Project Changes
QuαΊ£n lΓ½ Thay Δα»i Dα»± Γ‘n
Change lΓ tαΊ₯t yαΊΏu trong mα»i dα»± Γ‘n. PM khΓ΄ng ngΔn chαΊ·n change β PM kiα»m soΓ‘t nΓ³. Integrated Change Control ΔαΊ£m bαΊ£o mα»i change Δược evaluate, approved, vΓ implemented ΔΓΊng cΓ‘ch.
π Change Control Process
πΊπΈ English
Integrated Change Control is the process of reviewing all change requests, approving or rejecting them, and managing the implementation of approved changes across ALL project baselines.
Change Control Board (CCB): A formally chartered group that reviews, evaluates, approves, delays, or rejects changes to the project, with all decisions documented.
Change Request types:
- Corrective action: Realign project performance to plan (reactive)
- Preventive action: Ensure future performance aligns to plan (proactive)
- Defect repair: Fix a product/deliverable that doesn't meet requirements
- Updates: Changes to formally controlled project documents or baselines
Key rule: ALL changes must be documented and approved β even if the PM has authority to approve minor changes. No undocumented changes ever.
Reference: PMI β Integrated Change Control
π»π³ TiαΊΏng Viα»t
Integrated Change Control lΓ quy trΓ¬nh review tαΊ₯t cαΊ£ change requests, phΓͺ duyα»t/tα»« chα»i, vΓ quαΊ£n lΓ½ viα»c implement cΓ‘c changes ΔΓ£ Δược phΓͺ duyα»t trΓͺn TαΊ€T CαΊ’ baselines.
CCB (Change Control Board): NhΓ³m Δược ủy quyα»n chΓnh thα»©c Δα» review, ΔΓ‘nh giΓ‘, phΓͺ duyα»t hoαΊ·c tα»« chα»i changes, vα»i tαΊ₯t cαΊ£ quyαΊΏt Δα»nh Δược ghi lαΊ‘i.
Quy tαΊ―c then chα»t: Mα»I changes phαΊ£i Δược ghi lαΊ‘i vΓ phΓͺ duyα»t β ngay cαΊ£ khi PM cΓ³ quyα»n phΓͺ duyα»t minor changes. KhΓ΄ng bao giα» cΓ³ undocumented changes.
Change Control Process Flow
ββ STEP 1: IDENTIFY βββββββββββββββββββββββββββββββββββββ
Change identified by: team member / stakeholder / PM / external event
Document as formal Change Request (CR) with: description, reason, requester
ββ STEP 2: EVALUATE IMPACT ββββββββββββββββββββββββββββββ
PM assesses impact on:
β’ Scope (what changes?)
β’ Schedule (how many days?)
β’ Cost (how much money?)
β’ Quality (any quality risk?)
β’ Risk (new risks introduced?)
β’ Resources (who is needed?)
ββ STEP 3: CCB REVIEW ββββββββββββββββββββββββββββββββββββ
Present CR to CCB with impact analysis
CCB decision: Approve / Reject / Defer / Approve with conditions
ββ STEP 4: IMPLEMENT (if approved) ββββββββββββββββββββββ
Update ALL affected baselines:
Scope baseline β Schedule baseline β Cost baseline β Risk register β Docs
ββ STEP 5: COMMUNICATE ββββββββββββββββββββββββββββββββββ
Notify affected stakeholders of approved change and updated plans
ββ STEP 6: CLOSE CR ββββββββββββββββββββββββββββββββββββββ
Update Change Log with final status and lessons learned
π Change in Agile vs Predictive
| Aspect | Predictive (Waterfall) | Agile (Scrum) |
|---|---|---|
| Change attitude | Change is managed (controlled, minimized) | Change is welcomed (embraced as competitive advantage) |
| Change mechanism | Formal CCB, change request document | Product Backlog reprioritization by Product Owner |
| Change timing | Formal change control window (phase gates) | Any time β but NOT during a sprint in progress |
| Sprint change rule | N/A | Sprint commitment is protected β only PO can cancel sprint if goal is invalidated |
| Documentation | Change log, updated baselines | Backlog update, sprint velocity adjustment |
| Who approves | CCB (may include sponsor, PM, stakeholders) | Product Owner (for backlog changes) |
Exam Tips β Change Management
- EVERY change must go through change control β no exceptions, even "small" ones
- In Agile, the PO can change backlog at any time β but cannot change sprint goals mid-sprint
- PM should analyze impact BEFORE presenting to CCB β never show up without numbers
- Approved change β update ALL baselines (scope + schedule + cost), not just one
- Emergency change: same process, expedited timeline. "Emergency" doesn't mean "skip process."
- Change log is separate from risk register and issue log β track all three
πΌ Thα»±c chiαΊΏn / Scenario
FinTech Company X β CCB in Action
Situation: Sprint 9. Bank Partner A announces their API will add a mandatory new authentication header (HMAC signature) effective in 3 weeks β a regulatory requirement in their market. This was not in the original integration spec.
PM's process:
- Raise Change Request CR-047: "Mandatory API auth header change β Partner Bank A regulatory requirement"
- Impact analysis: Dev effort = 5 SP (signature library + tests). QA = 3 SP. Deployment = 1 day. Timeline impact = +1 sprint delay OR can be absorbed by descoping low-priority features (8 SP available in current sprint).
- CCB decision: Change approved. Defer two low-priority admin features (8 SP) to Phase 2. No timeline slip. CR-047 APPROVED.
- Baseline update: Sprint 9 scope updated. Product backlog updated. Partner notified of schedule for compliance.
- Retrospective note: Add "partner regulatory change monitoring" to risk register as ongoing process.
PMP lesson: External-driven change still goes through change control. The PM's value is in the impact analysis β not just executing the request, but evaluating options and recommending the best path forward.
βοΈ Practice Questions
Question 1
During project execution, a team member identifies a better technical solution that would require significant changes to the architecture. What should the PM do FIRST?
- A. Ask the team member to implement the improvement during spare time
- B. Reject the idea since the architecture is already approved
- C. Document it as a change request and perform an impact analysis before escalating to CCB
- D. Immediately implement the improvement to avoid delays later
β
Answer: C β All changes, including technical improvements, must go through the change control process. The PM first documents the request and performs an impact analysis (scope, schedule, cost, risk) before presenting to CCB. Option A bypasses process. Option B is too rigid β the idea may have merit. Option D creates unauthorized changes to the approved baseline, which is a professional failure.
Question 2
A change request is submitted to add a feature that will increase project cost by $15,000 but also increase expected revenue by $80,000. The CCB reviews and approves. What must the PM do NEXT?
- A. Start implementation immediately
- B. Update all affected project baselines (scope, schedule, cost) and communicate to stakeholders before implementation
- C. Wait for the sponsor to formally sign off a second time
- D. Only update the cost baseline since the financial impact is the key change
β
Answer: B β An approved change requires updating ALL affected baselines, not just one. Scope, schedule, and cost baselines must all reflect the approved change before work begins. Communicating the updates to stakeholders ensures everyone is aligned before implementation starts. Jumping straight to implementation (A) or updating only the cost baseline (D) leaves other baselines out of sync, destroying the integrity of performance measurement.
Question 3
During a sprint, a Product Owner tries to add a new user story to the current sprint's committed work without going through any process. The Scrum Master should:
- A. Allow it since the PO has authority over the backlog
- B. Explain that the sprint commitment is protected β new work goes to the product backlog for the next sprint, not into the current sprint
- C. Escalate to the PM
- D. Add it but extend the sprint duration
β
Answer: B β Sprint commitment is protected in Scrum. While the Product Owner has authority over the product backlog, they cannot interrupt an in-progress sprint by inserting new work. New stories are added to the backlog and prioritized for the next sprint. This protects the team's focus and ensures the sprint goal remains achievable. Extending the sprint (D) breaks Scrum's time-box principle.
π€ AI Tools for PMs
How AI Augments This Process
AI helps PMs draft change request documentation, generate impact analyses, prepare CCB presentations, and communicate change decisions clearly to all affected stakeholders.
Sample Claude Prompts
Change request documentation drafting
Help me write a complete Change Request document for CCB review.
Change summary: [what is changing]
Requestor: [name / role]
Business driver: [why this change is needed β business value, risk reduction, regulatory]
Change type: [Scope / Schedule / Budget / Technical / Regulatory]
Urgency: [critical / normal / low]
Draft a Change Request document with:
1. Executive summary (3 sentences β what, why, when)
2. Detailed description of the change
3. Impact analysis:
- Scope: what is added/removed/modified
- Schedule: days added, milestones affected
- Cost: effort + direct costs
- Quality: any risks to existing deliverables
- Resources: additional people/tools needed
4. Options analysis:
- Option A: Full implementation
- Option B: Partial implementation (if applicable)
- Option C: Reject and alternatives
5. Recommendation with rationale
6. Approval signatories
Format for a 1-page CCB submission.
CCB meeting preparation
I'm presenting 3 change requests to the Change Control Board this week. Help me prepare.
CR-1: [title, type, impact summary]
CR-2: [title, type, impact summary]
CR-3: [title, type, impact summary]
CCB members: [sponsor, PMO director, technical lead, finance]
Their known concerns: [what each member typically pushes back on]
My recommendations: [approve/reject/defer for each]
Prepare my CCB presentation:
1. Meeting agenda (time-boxed β 45 minutes total)
2. For each CR: 2-minute verbal pitch structure
3. Decision-making criteria table (how to evaluate approve/reject/defer)
4. Anticipated questions from each CCB member and my prepared responses
5. Post-CCB communication plan (how to tell requestors the decision)
Change impact on project baseline
A change has been approved by the CCB. Help me update the project baselines.
Approved change: [CR description and decision]
Original scope baseline: [key scope elements]
Original schedule baseline: [key milestones and dates]
Original cost baseline: [total budget]
Change impact: [scope additions/removals, schedule delta, cost delta]
Help me:
1. Update the scope baseline statement (what's in / out now)
2. Update the schedule β which milestones shift? By how much?
3. Update the cost baseline β new total, new contingency reserve
4. Identify any secondary changes triggered by this change (downstream impacts)
5. Draft the baseline update communication for stakeholders
6. Log the change in the change register
Note: what does the team need to know, and how should I communicate this to avoid confusion?
Jira / Confluence Template
Jira β CCB Change Log
ββ JIRA: CHANGE CONTROL REGISTER ββββββββββββββββββββββββ
Epic/Label: change-control | project:[alpha]
ββ CHANGE RECORD βββββββββββββββββββββββββββββββββββββββββ
CR Number: CR-[###]
Title: [Short descriptive title]
Requested by: [Name / Role]
Date submitted: [YYYY-MM-DD]
Category: [ ] Scope [ ] Schedule [ ] Cost [ ] Technical [ ] Regulatory
ββ IMPACT SUMMARY ββββββββββββββββββββββββββββββββββββββββ
Scope delta: [+/- description]
Schedule delta: +[X] days | New milestone: [date]
Cost delta: +$[amount] | New budget: $[total]
Risk introduced: [new/increased risk]
ββ CCB DECISION ββββββββββββββββββββββββββββββββββββββββββ
Decision: [ ] Approved [ ] Rejected [ ] Deferred [ ] Conditional
Decision date: [YYYY-MM-DD]
Decision by: [CCB chair / members]
Conditions: [any approval conditions or constraints]
Baseline updated: [ ] Yes β [date] [ ] No
Stakeholders notified: [list] | Notification date: [YYYY-MM-DD]