CertFlow PRO
PMBOK8-Business · Bài 3/8

Quản Lý Thay Đổi Dự Án: Change Control Process theo PMBOK 8

··Cập nhật ·17 phút đọc
Chia sẻ:
Integrated Change Control in PMBOK 8

Change không phải kẻ thù của dự án — change management kém mới là. PMBOK 8 tích hợp change control vào toàn bộ vòng đời dự án. Bài này đi qua process từ A-Z.

1. Tại sao change control là "van an toàn" của dự án?

Hãy tưởng tượng: dự án ERP cho một chuỗi bán lẻ. Tuần 3, VP Marketing yêu cầu "thêm loyalty module." Tuần 6, CFO muốn "tích hợp thêm hệ thống kế toán cũ." Tuần 9, store managers yêu cầu "mobile app cho inventory check." Mỗi request nghe hợp lý. Team accommodate tất cả mà không formal process. Tháng 6, dự án đã phình to 200% scope ban đầu, budget cháy, và deadline bay mất.

Nguyên nhân? Không phải requests sai — mà là không có quy trình đánh giá impact trước khi accept.

PMBOK® 8, Section 2.1.6.8: "Integrated change control helps ensure that changes to the project are managed in a coordinated and controlled manner. By evaluating change requests, conducting impact analyses, making informed decisions, and documenting and communicating changes, the project can maintain alignment with its objectives."

2. Bốn loại thay đổi — Không chỉ có scope changes

PMBOK 8 xác định change requests có thể bao gồm:

Loại Change

Định nghĩa

Ví dụ

Trigger

Corrective Action

Hành động đưa performance TRỞ LẠI đúng plan

Thêm resources vì schedule behind

Variance analysis (SPI < 1.0)

Preventive Action

Hành động NGĂN CHẶN vấn đề tương lai

Thêm buffer cho risky activities

Risk analysis, trend analysis

Defect Repair

Sửa lỗi trong deliverable

Fix bug, sửa tài liệu sai

QC inspection, testing

Update

Thay đổi nội dung, features, scope

Thêm module, modify requirement

Stakeholder request, new regulation

🌟 Mẹo PMP: Đề thi phân biệt rõ 4 loại này. Corrective = fix CURRENT deviation. Preventive = prevent FUTURE deviation. Defect repair = fix PRODUCT. Update = change BASELINE. Khi đề mô tả "project is behind schedule, PM adds overtime" → corrective action. "PM identifies risk and adds buffer" → preventive action.

3. Framework 4 enablers quản lý thay đổi

Enabler

Câu hỏi cốt lõi

Key activities

Execute change control process

Quy trình nào áp dụng cho change requests?

Submit CR, impact analysis, CCB review, decision

Communicate status of proposed changes

Ai cần biết gì, khi nào?

CR tracking, status updates, decision communication

Implement approved changes

Changes được thực hiện đúng không?

Execute per plan, verify implementation, update baselines

Update documentation

Tài liệu có phản ánh thay đổi?

Update plan, baselines, change log, project documents


4. Integrated Change Control — Quy trình cốt lõi

PMBOK 8 mô tả quy trình Assess and Implement Changes với flow diagram rõ ràng:

7 bước Change Control Process

  1. - Identify change — Any stakeholder can request. Verbal requests MUST be documented in writing.

  2. - Document change request — Log trong change management system. Bao gồm: description, rationale, requester, urgency, initial impact estimate.

  3. - Conduct impact analysis — Đánh giá impact trên TOÀN BỘ: scope, schedule, cost, quality, risk, resources, stakeholders.

  4. - Submit to decision authority — PM, CCB, hoặc sponsor tùy governance framework.

  5. - Decision — Approved, Rejected, hoặc Deferred.

  6. - Implement (if approved) — Execute through Manage Project Execution. Update baselines nếu cần.

  7. - Verify and document — Confirm implementation đúng. Update change log, project documents.

PMBOK® 8, Section 2.1.6.8.1: "Although changes can be initiated verbally, they should be documented in writing and entered into the change or configuration management system. Change requests should typically include information on the estimated schedule and cost impacts before they can be approved."

Change Control Flow — PMBOK 8

PMBOK 8 Figure 2-11 mô tả flow: Change Request → Impact Analysis (Scope, Schedule, Finance, Resources, Risk, Stakeholders) → Decision (Approved / Rejected / Deferred / More Information) → Nếu Approved: Corrective Action, Preventive Action, Defect Repair, hoặc Update. Mỗi nhánh đều ảnh hưởng ngược lại toàn bộ domains.

5. Change Control Board (CCB) — Ai quyết định?

PMBOK® 8: "A change control board (CCB) is a formally established group responsible for reviewing, evaluating, approving, deferring, or rejecting changes — and for documenting and communicating these decisions."

Role

Authority

Typical decisions

PM

Minor changes within authority, CR submission

Corrective actions within contingency, minor schedule adjustments

CCB

Baseline changes, significant CRs

Scope changes, schedule baseline changes, cost baseline changes

Sponsor

Strategic decisions, major budget changes

Major scope additions, project continuation, budget increases

Customer

Customer-specific changes (nếu CCB member)

Customer requirement changes, acceptance criteria changes

PMBOK 8 lưu ý: "While awaiting the decision of the CCB, project managers should continually execute planned tasks while also analyzing the impact and risks related to accepting or rejecting the proposed changes to minimize negative impacts." — Dự án không dừng lại chờ CCB quyết định.

Configuration Management

PMBOK 8: Configuration management plan xác định "which project artifacts are subject to configuration control." Đây là hệ thống theo dõi: version nào là version hiện tại, ai đã thay đổi gì, khi nào, và tại sao. Thiếu configuration management = "tôi tìm thấy 3 phiên bản requirements doc, cái nào đúng?"

6. Impact Analysis — Đánh giá trước khi quyết định

Mỗi change request phải được đánh giá impact trên TẤT CẢ dimensions — không chỉ dimension bị thay đổi trực tiếp:

Dimension

Câu hỏi impact

Ví dụ

Scope

WBS thay đổi thế nào? Deliverables nào ảnh hưởng?

Thêm module → thêm work packages

Schedule

Critical path bị ảnh hưởng? Duration tăng?

Thêm 3 tuần development + 2 tuần testing

Cost

Budget impact bao nhiêu? Cần thêm reserves?

$50K additional development + $10K testing

Quality

Quality standards thay đổi? Testing plan cần update?

New module cần integration testing

Risk

New risks xuất hiện? Existing risks change?

Integration risk tăng, vendor dependency mới

Resources

Cần thêm người? Skills mới? Conflicts?

Cần 2 more developers, DB specialist

Stakeholders

Ai bị ảnh hưởng? Communication cần update?

Training plan cho end users thay đổi

PMBOK® 8: "Approved change requests may require new or updated cost estimates, schedule adjustments, resource requirements, and risk assessments. These changes may also require updates to the project management plan and other project documents."

7. Communicate và implement changes

Communicate Status of Proposed Changes

Change log phải tracking: CR number, description, date submitted, requester, status (pending/approved/rejected/deferred), impact summary, decision date, decision rationale. PMBOK 8: "The disposition of all change requests is recorded in the change log as a project document update."

Communication cần reach: requester (CR accepted/rejected/deferred với lý do), affected team members (what changes for them), stakeholders (updated timeline, scope, cost), và governance (CCB decisions documented).

Implement Approved Changes

PMBOK 8: "Approved change requests are implemented via the Manage Project Execution process." Implementation bao gồm: execute the change per plan, verify change implemented correctly, update baselines (scope/schedule/cost nếu cần), update project documents (risk register, stakeholder register, communications plan), và confirm results meet expectations.

Update Documentation

Sau mỗi approved change: project management plan components (whichever are affected), scope baseline / schedule baseline / cost baseline (nếu thay đổi), change log (update status), lessons learned register (if applicable), và risk register (new/modified risks).

8. Predictive vs. Adaptive change management

Aspect

Predictive

Adaptive

Process

Formal change control with CCB

Backlog management — PO adds/reprioritizes items

When changes controlled

After baselines established

Continuously throughout iterations

Decision-maker

CCB, PM, Sponsor

Product Owner (with team input)

Impact analysis

Formal, documented, multi-dimensional

Conducted but less formal — evaluated by priority vs. capacity

"Approved"

CCB formally approves/rejects/defers

PO adds to backlog (= accepted). Low priority item (= deferred). Removed from backlog (= rejected).

Documentation

Change log, updated baselines, plan updates

Backlog updates, sprint records, DoD revisions

Baseline

Updated through formal CCB approval

Iteration baseline changes per sprint planning

PMBOK® 8, Section 2.1.6.8.2: "In adaptive approaches, managing project changes typically involves backlog management rather than a formal change request process. Although these are not formally termed as change requests, an impact analysis is conducted to evaluate the change's effect and set its priority."

Lưu ý quan trọng: ngay cả trong adaptive, some changes still need formal control — budget increases, contract changes, regulatory changes, major architecture decisions. Hybrid approach: formal CCB cho "big" changes, backlog management cho "small" changes.


9. Tip thi PMP

💡Tip 1 — ALL changes through change control: Trong predictive, SAU KHI baseline established, MỌI thay đổi phải qua formal change control. "Just a small change" không phải lý do bỏ qua process. Khi đề mô tả "stakeholder asks for minor addition" → still submit change request.

💡Tip 2 — Assess impact BEFORE decide: Khi đề hỏi "what should PM do FIRST when receiving a change request?" → assess impact (impact analysis), KHÔNG phải approve, reject, hoặc implement. Impact analysis TRƯỚC quyết định.

💡Tip 3 — 4 types of changes: Corrective (fix deviation), Preventive (prevent future issue), Defect Repair (fix product), Update (change scope/baseline). Khi đề mô tả situation → identify WHICH type.

💡Tip 4 — Don't stop work waiting for CCB: PMBOK 8 nói rõ: "while awaiting CCB decision, PM should continue executing planned tasks." Dự án không freeze chờ CCB.


10. Mười câu hỏi trắc nghiệm tình huống

Question 1

The sponsor verbally requests adding a new feature during a hallway conversation. The feature aligns with the project vision.

What should you do?

A. Add the feature since the sponsor has authority and it aligns with the vision.

B. Document the request as a formal change request, conduct impact analysis on scope/schedule/cost/risk, and submit to the appropriate decision authority per the change management plan.

C. Add it to the backlog and prioritize later.

D. Ask the sponsor to submit a formal written request.

Question 2

Your project receives a change request to add a security feature. Impact analysis shows: +$30K cost, +2 weeks schedule, but significantly reduces risk of data breach (estimated $2M exposure).

What should you recommend to the CCB?

A. Reject — it increases cost and schedule.

B. Approve — the $30K investment to mitigate a $2M risk exposure is a strong positive ROI. Present the impact analysis with risk-value comparison to support an informed decision.

C. Defer until the next phase.

D. Approve but find savings elsewhere to offset the $30K.

Question 3

Your team discovers a defect in a delivered module. The defect causes incorrect calculations in 5% of transactions.

What type of change request should be submitted?

A. Corrective action — to bring performance back to plan.

B. Preventive action — to prevent future defects.

C. Defect repair — to fix the product defect.

D. Update — to modify the deliverable.

Question 4

The SPI is 0.85, indicating the project is behind schedule. The PM decides to add overtime for the team to recover.

What type of change is this?

A. Defect repair

B. Preventive action

C. Corrective action — the PM is taking action to bring schedule performance BACK to plan.

D. Update

Question 5

A stakeholder submits a change request. While waiting for CCB review (scheduled in 5 days), the PM stops all related work "to avoid rework if the change is approved."

Is this the right approach?

A. Yes — it prevents potential rework.

B. No — PMBOK 8 states the PM should "continue executing planned tasks while awaiting CCB decision." Stopping work creates unnecessary delay. The PM should analyze impacts while continuing planned execution.

C. It depends on the size of the change.

D. The PM should escalate for faster CCB review.

Question 6

Your agile team's Product Owner adds 10 new user stories to the backlog based on customer feedback. A team member complains: "This is scope creep — we need a change request."

How should you respond?

A. The team member is right — submit formal CRs for each story.

B. In adaptive, backlog management IS the change process. The PO has authority to add items. Adding to the backlog with appropriate prioritization is the correct approach — not every addition requires a formal CR.

C. Remove the stories until the CCB approves.

D. Accept the stories but flag as "unplanned scope."

Question 7

The CCB approves a scope change that adds 3 new requirements. The PM implements the change but forgets to update the WBS, schedule baseline, and risk register.

What problem will this create?

A. No problem — the change was approved and implemented.

B. The project documents no longer reflect reality. Future decisions will be based on outdated baselines — variance analysis will be meaningless, risk exposure is unknown, and team may not know the full scope. ALL affected documents must be updated after approved changes.

C. The PM should update documents at the next milestone.

D. The PMO will catch the documentation gap in their audit.

Question 8

A critical production outage occurs. The fix requires an immediate code change and deployment. There's no time for the normal CCB review process.

What should you do?

A. Implement the fix and skip the change process — it's an emergency.

B. Implement the emergency fix following the emergency change procedures defined in the change management plan — then retroactively document the change, conduct impact analysis, and submit to CCB for formal approval at the next meeting.

C. Wait for CCB approval — even emergencies must follow process.

D. Have the sponsor approve verbally and document later.

Question 9

Over the past 3 months, 15 change requests were approved, adding 25% to scope. Each was properly evaluated and approved by CCB. The sponsor now says: "The project feels completely different from what we started."

What went wrong?

A. Nothing — every change was properly approved.

B. While individual changes were properly governed, nobody assessed the CUMULATIVE impact on the project's value proposition. The PM should have flagged the trend when scope growth exceeded a threshold, presenting a holistic view of how the project evolved versus the original business case.

C. The CCB should have been more restrictive.

D. The sponsor should have attended CCB meetings.

Question 10

A team member implements a "small improvement" to the codebase without submitting a change request. The improvement works well and other team members praise it.

How should you handle this?

A. Praise the initiative — the improvement is beneficial.

B. Acknowledge the good intent, but explain that ALL changes to baselined deliverables must go through the change process — even beneficial ones. Retroactively document the change, assess any impacts, and reinforce the importance of process compliance to prevent uncontrolled changes.

C. Add the improvement to the change log retroactively.

D. This is gold plating — it should be reversed.

Đáp án: 

Question 1: Answer: B 

— PMBOK 8: "Although changes can be initiated verbally, they should be documented in writing and entered into the change management system." Even from the sponsor, even if aligned with vision — the process must be followed. Impact must be assessed before implementation.

Question 2: Answer: B 

— Change decisions should be based on value, not just cost/schedule impact. PMBOK 8: evaluate changes against the project's value proposition. $30K + 2 weeks to avoid $2M exposure = highly favorable trade-off. The PM should RECOMMEND with data, and CCB DECIDES.

Question 3: Answer: C 

— A defect in a deliverable = defect repair. Corrective action (A) addresses process deviation, not product defect. Preventive action (B) prevents FUTURE issues. Update (D) modifies scope, not fixes existing functionality.

Question 4: Answer: C 

— SPI < 1.0 = behind schedule = deviation from plan. Adding overtime to recover = corrective action. Corrective action = "intentional activity that realigns the performance of the project work with the project management plan."

Question 5: Answer: B 

— PMBOK 8 explicitly states: "While awaiting the decision of the CCB, project managers should continually execute planned tasks while also analyzing the impact." Stopping work = self-imposed delay. If the change IS approved, rework may occur — but that's a managed risk, not a reason to halt progress.

Question 6: Answer: B 

— PMBOK 8: "In adaptive approaches, changes involve backlog management rather than formal change request process. Any proposed change can be added to the backlog." The PO adding prioritized stories based on customer feedback is exactly how agile is supposed to work. It's not scope creep if it's managed through backlog prioritization.

Question 7: Answer: B 

— PMBOK 8: "Approved changes may require updates to the project management plan and other project documents." Implementing without updating documentation = baselines diverge from reality. EVM becomes meaningless (comparing actual against wrong baseline), risks aren't tracked, and team doesn't have accurate scope.

Question 8: Answer: B 

— Most change management plans include emergency procedures for situations exactly like this. The key: act quickly but FOLLOW the emergency process, then retroactively formalize. Skipping entirely (A) sets dangerous precedent. Waiting (C) causes ongoing damage. The change management plan should define what constitutes an "emergency" and the expedited approval path.

Question 9: Answer: B

 — Individual compliance ≠ strategic alignment. PMBOK 8's Adopt a Holistic View: "candidate baseline changes are evaluated for which one might yield the highest return on investment." The PM should monitor cumulative change impact and flag when the project has drifted significantly from its original value proposition.

Question 10: Answer: B 

— Even beneficial changes must be controlled. PMBOK 8: "Once the project has a baseline, all changes should go through a formal process." Uncontrolled "improvements" set a precedent where anyone can modify deliverables without oversight. The PM should acknowledge intent (positive), enforce process (non-negotiable), and document retroactively.


11. Tổng kết

Change control là "van an toàn" của dự án — cho phép thay đổi khi cần thiết nhưng ngăn chặn chaos khi không kiểm soát. Ba takeaways:

  1. - Process BEFORE decision — Mọi thay đổi phải qua quy trình: document → impact analysis → decision → implement → update. "Just a small change" không phải lý do bỏ qua process. Impact analysis trên TẤT CẢ dimensions (scope, schedule, cost, quality, risk, resources, stakeholders) TRƯỚC khi approve.

  2. - Predictive ≠ Adaptive, nhưng cả hai đều cần control — Predictive dùng formal CCB. Adaptive dùng backlog management. Nhưng cả hai đều MANAGE changes — chỉ khác mechanism. Và trong hybrid, "big" changes vẫn cần formal CCB ngay cả khi daily work dùng agile backlog.

  3. - Document everything, assess cumulative impact — Change log phải current. Baselines phải updated. Project documents phải reflect reality. Và PM phải monitor CUMULATIVE change impact — 15 approved CRs thêm 25% scope vẫn là red flag, ngay cả khi mỗi CR individually approved.

PMBOK® 8: "Changes are made to create improvements to the original plan and baseline, often based on changing conditions. The results of the changes should be monitored to ensure they yield the desired results."

Câu Hỏi Thường Gặp (FAQ)

Integrated Change Control process theo PMBOK hoạt động như thế nào?

Integrated Change Control (ICC) là process đánh giá tất cả change requests và approve/reject chúng. Bước: (1) Submit change request (CR) bằng văn bản; (2) PM assess impact lên scope, schedule, cost, quality, risks; (3) CCB review và decide (approve/reject/defer); (4) Nếu approved: update plans, baselines, và notify stakeholders; (5) Implement change. Mọi change đều phải qua ICC.

Change Control Board (CCB) gồm những ai và authority đến đâu?

CCB thường gồm: PM, Sponsor hoặc representative, key stakeholders, domain experts liên quan. Authority: approve changes trong scope of delegated authority; escalate lên Sponsor/Executive cho major changes vượt ngưỡng. Composition thay đổi theo project size và complexity — dự án nhỏ có thể chỉ PM và Sponsor; dự án lớn có thể có formal CCB meetings.

Agile project quản lý change khác predictive project như thế nào?

Agile: change là được mong đợi và welcome thông qua Product Backlog grooming — thêm, bớt, re-prioritize stories theo feedback. Không cần formal CCB cho sprint-level changes. Predictive: change control formalized hơn, baselines protected, mọi change đi qua ICC. Hybrid: áp dụng formal CCB cho major scope/budget changes, nhưng agile flexibility cho sprint-level adjustments.


Bạn đã nắm vững quản lý thay đổi dự án — giờ là lúc luyện tập với câu hỏi thi thật.

Làm thử đề PMP miễn phí →

Nguồn tham khảo chính thức:

Bạn đã sẵn sàng luyện tập chưa?

Thử CertFlow miễn phí — 10 câu hỏi, không cần đăng ký.

Bắt Đầu Miễn Phí
PMPPMBOK 8Manage and Control ChangesBusiness Environment DomainChange ControlCCBImpact AnalysisIntegrated Change Control