Ngân hàng đề — PMP Mock Exam Set

Tìm thấy 201 câu.

Câu 21
You are the project manager of a new construction project for your organization. The project has just recently been chartered, and you’re working with the project team to define the project management plan, scope statement, and cost budget and other project details. Your customer has contacted you and informed you that they have several changes to the project, such as different flooring selection, larger windows, and an outdoor seating area. What should you do next?
  1. A Complete a change request and pass the change through integrated change control.
  2. B Accept the changes and continue with project planning.
  3. C Refuse the changes as the project charter has already been created.
  4. D Ask the team to explore the changes in costs, scope, schedule, risk, and quality concerns before approving the changes for the project.
Xem giải thích

Đáp án

B — Chấp nhận thay đổi và tiếp tục lập kế hoạch dự án.

Vì sao đúng

⚠ Mấu chốt nằm ở GIAI ĐOẠN của dự án: | Trạng thái | Nội dung | |---|---| | ⚠ Dự án vừa được chartered | | | ⚠ ĐANG lập project management plan, scope statement, ngân sách | | | ⚠ CHƯA có baseline được duyệt | | | ⚠ Kết luận | ⚠ chưa có gì để "thay đổi" một cách chính thức |

⚠ Quy trình kiểm soát thay đổi tích hợp chỉ áp dụng khi đã có BASELINE. ⚠ Trong giai đoạn lập kế hoạch, việc tiếp thu ý kiến khách hàng chính là công việc lập kế hoạch.

Vì sao các phương án khác sai

  • A (làm change request qua integrated change control) — ⚠ thủ tục thừa ở giai đoạn này; ⚠ chưa có baseline thì không có gì để so sánh và phê duyệt thay đổi so với nó.

  • D (yêu cầu đội phân tích ảnh hưởng trước khi phê duyệt) — ⚠ nghe rất cẩn trọng, nhưng ⚠ đây là hoạt động BÌNH THƯỜNG của việc lập kế hoạch, không cần thủ tục phê duyệt riêng.

  • C (từ chối vì charter đã lập) — ⚠ SAI; ⚠ charter mô tả yêu cầu ở MỨC CAO, chi tiết được làm rõ dần trong lập kế hoạch.

Ghi nhớ

⚠ Progressive elaboration — chi tiết hoá dần: | Nguyên tắc | Nội dung | |---|---| | ⚠ Đầu dự án: thông tin ở mức cao | | | ⚠ Càng đi càng chi tiết hơn | | | ⚠ Trong lập kế hoạch, làm rõ yêu cầu là ĐÚNG QUY TRÌNH | | | ⚠ Sau khi có baseline | ⚠ mọi thay đổi mới phải qua change control |

⚠ Khi nào cần change request: | Tình huống | Cần change request | |---|---| | ⚠ Đang lập kế hoạch, chưa có baseline | ⚠ KHÔNG | | ⚠ Đã có baseline được duyệt | ⚠ CÓ | | ⚠ Đang thực thi, khách đòi thêm phạm vi | ⚠ CÓ | | ⚠ Sửa lỗi để đưa công việc về đúng kế hoạch | ⚠ CÓ — corrective action cũng là change request |

Từ khoá nhận diện:

"chưa có baseline" → ⚠ cập nhật kế hoạch, không cần change request "đã có baseline" → ⚠ phải qua integrated change control "chi tiết hoá dần" → ⚠ progressive elaboration "thay đổi được duyệt" → ⚠ approved change request

⚠ Quy trình Perform Integrated Change Control Bước
⚠ Nhận change request
⚠ Đánh giá ảnh hưởng ⚠ phạm vi, lịch, chi phí, chất lượng, rủi ro
⚠ Change Control Board quyết định ⚠ duyệt, từ chối, hoặc hoãn
⚠ Cập nhật baseline nếu duyệt
⚠ Thông báo cho bên liên quan
⚠ Ghi vào change log
⚠ Bẫy của câu hỏi này Bẫy
⚠ Phương án A và D nghe RẤT chuyên nghiệp
⚠ Nhiều người chọn theo phản xạ "cứ có thay đổi là làm change request"
⚠ Nhưng đề đã nói rõ dự án ĐANG LẬP KẾ HOẠCH
⚠ Bài học ⚠ luôn xác định dự án đang ở giai đoạn nào trước khi chọn hành động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Baseline đã được duyệt chưa | ⚠ quyết định có cần change control hay không | | Thay đổi này có ảnh hưởng tới charter không | | | Bên liên quan đã được thông báo chưa | |

Và câu hỏi phải trả lời trước mọi tình huống "khách hàng muốn thay đổi": dự án đang ở giai đoạn nào? Cùng một yêu cầu, ở giai đoạn lập kế hoạch là việc bình thường, còn sau khi có baseline lại là một thay đổi cần phê duyệt.

Câu 22
Your organization has asked you, a project manager, to work with a business analyst to create a business case for a proposed project. All of the following items are reasons why a business case may be created except for which one?
  1. A Legal requirement
  2. B Market demand
  3. C Organizational need
  4. D Profit and loss
Xem giải thích

Đáp án

D — Profit and loss (lãi và lỗ).

Vì sao đúng

⚠ PMBOK liệt kê sáu lý do dẫn tới việc khởi tạo dự án: | Lý do | Ví dụ | |---|---| | ⚠ Market demand | ⚠ nhu cầu thị trường — xe tiết kiệm nhiên liệu | | ⚠ Organizational need | ⚠ nhu cầu nội bộ — nâng cấp hệ thống nhân sự | | ⚠ Customer request | ⚠ khách hàng yêu cầu | | ⚠ Technological advance | ⚠ tiến bộ công nghệ | | ⚠ Legal requirement | ⚠ yêu cầu pháp lý mới | | ⚠ Ecological impacts | ⚠ tác động môi trường | | ⚠ Social need | ⚠ nhu cầu xã hội |

⚠ "Profit and loss" là một BÁO CÁO TÀI CHÍNH, ⚠ không phải một lý do khởi tạo dự án.

Vì sao các phương án khác sai

  • A (legal requirement), B (market demand), C (organizational need) — ⚠ đều nằm trong danh sách chính thức.

Ghi nhớ

⚠ Business case gồm những gì: | Mục | Nội dung | |---|---| | ⚠ Nhu cầu kinh doanh | ⚠ một trong sáu lý do trên | | ⚠ Phân tích tình huống | ⚠ các phương án đã cân nhắc | | ⚠ Khuyến nghị | | | ⚠ Đánh giá | ⚠ lợi ích kỳ vọng và cách đo |

⚠ Các chỉ số tài chính hay hỏi trong đề PMP: | Chỉ số | Chọn phương án nào | |---|---| | ⚠ NPV — Net Present Value | ⚠ CAO hơn thì tốt hơn | | ⚠ IRR — Internal Rate of Return | ⚠ CAO hơn thì tốt hơn | | ⚠ Payback period | ⚠ NGẮN hơn thì tốt hơn | | ⚠ BCR — Benefit Cost Ratio | ⚠ CAO hơn thì tốt hơn; trên 1 là có lãi | | ⚠ ROI | ⚠ cao hơn thì tốt hơn |

⚠ Mẹo: ⚠ chỉ có payback period là càng nhỏ càng tốt; ⚠ các chỉ số còn lại đều càng lớn càng tốt.

Từ khoá nhận diện:

"lý do khởi tạo dự án" → ⚠ sáu nhóm của PMBOK "tài liệu biện minh cho dự án" → ⚠ business case "lợi ích sẽ được đo và duy trì thế nào" → ⚠ benefits management plan "báo cáo lãi lỗ" → ⚠ tài liệu kế toán, không phải lý do dự án

⚠ Chi phí chìm — sunk cost Nguyên tắc
⚠ Tiền đã chi và KHÔNG thu lại được
⚠ KHÔNG được tính vào quyết định tiếp tục hay dừng
⚠ Chỉ xét chi phí và lợi ích TỪ NAY VỀ SAU
⚠ Đề PMP hay hỏi ⚠ "đã chi 5 triệu, có nên tiếp tục" — câu trả lời KHÔNG phụ thuộc con số đó
⚠ Business case có được xem lại không Có
⚠ Xem lại ở các mốc quan trọng ⚠ phase gate
⚠ Nếu lợi ích không còn, dự án nên DỪNG
⚠ Đây là ⚠ quyết định của nhà tài trợ, không phải của PM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lý do khởi tạo dự án còn đúng không | | | Lợi ích kỳ vọng có được đo không | | | Có đang tiếp tục dự án chỉ vì đã lỡ chi nhiều không | ⚠ bẫy chi phí chìm |

Và cái bẫy tư duy phổ biến nhất trong việc quyết định dừng hay tiếp một dự án: chi phí chìm. "Đã đổ vào ba tỷ rồi, dừng thì phí" — nhưng ba tỷ đó đã mất dù có tiếp hay không, và chỉ tương lai mới nên được đưa lên bàn cân.

Câu 23
You are a project manager for the NJJ Project and you’re working with the project team to identify project risks. Some of the risks in your project are uncomfortable for the project team to discuss. For example, there is a probability that the project team’s level of productivity may fluctuate or that the number of errors or defects in the project will not always be predictable. Though the team wants to insist that they will remain productive and that they’ll catch errors quickly and fix them, you know there is some fluctuation to be expected. What type of risk events are you defining in this scenario?
  1. A Performance risk
  2. B Variability risks
  3. C Systemic risks
  4. D Team risks
Xem giải thích

Đáp án

B — Variability risks (rủi ro biến động).

Vì sao đúng

⚠ Variability risk — rủi ro biến động: | Đặc điểm | Nội dung | |---|---| | ⚠ Kết quả có thể dao động quanh một giá trị dự kiến | | | ⚠ Không biết trước con số CHÍNH XÁC | | | ⚠ Ví dụ điển hình | ⚠ năng suất đội, số lỗi phát sinh, sản lượng, giá nguyên liệu | | ⚠ Phân tích bằng | ⚠ mô phỏng Monte Carlo, phân tích độ nhạy |

⚠ Đúng tình huống trong đề: ⚠ năng suất có thể dao động, ⚠ số lỗi không đoán trước được — ⚠ đó là biến động chứ không phải một sự kiện có xảy ra hay không.

Vì sao các phương án khác sai

  • A (Performance risk) — ⚠ không phải phân loại chuẩn trong khung rủi ro của PMBOK.

  • C (Systemic risks) — ⚠ rủi ro thuộc về TOÀN HỆ THỐNG, ảnh hưởng tới nhiều dự án cùng lúc; ⚠ ở đây phạm vi hẹp hơn.

  • D (Team risks) — ⚠ không phải thuật ngữ phân loại chuẩn.

Ghi nhớ

⚠ Ba nhóm rủi ro theo cách PMBOK phân loại rủi ro phi sự kiện: | Nhóm | Nội dung | |---|---| | ⚠ Event risk | ⚠ một SỰ KIỆN có thể xảy ra hoặc không — rủi ro truyền thống | | ⚠ Variability risk | ⚠ kết quả DAO ĐỘNG quanh giá trị dự kiến | | ⚠ Ambiguity risk | ⚠ KHÔNG BIẾT chuyện gì có thể xảy ra — thiếu hiểu biết |

⚠ Ứng phó với từng nhóm: | Nhóm | Cách ứng phó | |---|---| | ⚠ Event risk | ⚠ avoid, transfer, mitigate, accept | | ⚠ Variability risk | ⚠ mô phỏng, dự phòng, thiết kế linh hoạt | | ⚠ Ambiguity risk | ⚠ học hỏi dần, làm mẫu thử, mời chuyên gia, tiếp cận lặp |

Từ khoá nhận diện:

"dao động, không đoán trước con số chính xác" → ⚠ variability risk "có thể xảy ra hoặc không" → ⚠ event risk "không biết mình chưa biết gì" → ⚠ ambiguity risk "ảnh hưởng cả tổ chức, nhiều dự án" → ⚠ systemic risk

⚠ Monte Carlo — công cụ cho rủi ro biến động Nội dung
⚠ Chạy mô phỏng hàng nghìn lần ⚠ với các giá trị ngẫu nhiên trong khoảng
⚠ Cho ra PHÂN PHỐI kết quả ⚠ không phải một con số duy nhất
⚠ Trả lời được câu "xác suất hoàn thành trước ngày X là bao nhiêu"
⚠ Thuộc ⚠ Perform Quantitative Risk Analysis
⚠ Ước lượng ba điểm — cũng để xử lý biến động Công thức
⚠ Triangular ⚠ (O + M + P) ÷ 3
⚠ Beta / PERT ⚠ (O + 4M + P) ÷ 6
⚠ Độ lệch chuẩn ⚠ (P − O) ÷ 6
⚠ O, M, P ⚠ lạc quan, khả dĩ nhất, bi quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng có dùng ba điểm không | ⚠ hay chỉ một con số duy nhất | | Dự phòng có tính tới biến động không | | | Đội có dám thừa nhận sự không chắc chắn không | ⚠ đây thường là rào cản văn hoá |

Và rào cản lớn nhất khi bàn về rủi ro biến động, đúng như đề mô tả: đội ngại thừa nhận rằng mình không chắc. Nhưng một ước lượng "chắc chắn 10 ngày" thường kém hữu ích hơn nhiều so với "từ 8 đến 15 ngày, khả dĩ nhất là 10".

Câu 24
Ken is a project manager in his organization and he working with the project team to create the project network diagram for an IT implementation project. His team has identified the tasks of launching the new web server and shutting down the old web server. The team wants to make sure that the new web server is up and running before turning off the older web server. If the new server is the successor activity and the older web server is the predecessor what’s the relationship type between these two tasks in the scenario?
  1. A SS
  2. B LC
  3. C FF
  4. D SF
Xem giải thích

Đáp án

D — SF (Start-to-Finish).

Vì sao đúng

⚠ Đọc kỹ vai trò của hai hoạt động trong đề: | Hoạt động | Vai trò | |---|---| | ⚠ Bật máy chủ MỚI | ⚠ successor — hoạt động SAU | | ⚠ Tắt máy chủ CŨ | ⚠ predecessor — hoạt động TRƯỚC |

⚠ Quan hệ Start-to-Finish: | Nghĩa | Nội dung | |---|---| | ⚠ Successor phải BẮT ĐẦU thì predecessor mới KẾT THÚC được | | | ⚠ Áp vào đây | ⚠ máy mới phải CHẠY thì máy cũ mới được TẮT | | ⚠ Đúng ý đồ của đội | ⚠ không để gián đoạn dịch vụ |

⚠ Máy mới BẮT ĐẦU chạy
        ↓
⚠ Máy cũ mới được KẾT THÚC (tắt)

Vì sao các phương án khác sai

  • C (FF — Finish-to-Finish) — ⚠ hai việc cùng KẾT THÚC; ⚠ không đảm bảo máy mới đã chạy trước khi tắt máy cũ.

  • A (SS — Start-to-Start) — ⚠ hai việc cùng BẮT ĐẦU.

  • B (LC) — ⚠ không phải loại quan hệ nào.

Ghi nhớ

⚠ Bốn loại quan hệ phụ thuộc: | Loại | Nghĩa | Mức phổ biến | |---|---|---| | ⚠ FS — Finish-to-Start | ⚠ A xong thì B bắt đầu | ⚠ PHỔ BIẾN NHẤT | | ⚠ SS — Start-to-Start | ⚠ A bắt đầu thì B bắt đầu | ⚠ hay dùng | | ⚠ FF — Finish-to-Finish | ⚠ A xong thì B xong | ⚠ hay dùng | | ⚠ SF — Start-to-Finish | ⚠ B bắt đầu thì A mới xong | ⚠ HIẾM NHẤT |

⚠ Cách đọc tên: ⚠ chữ ĐẦU nói về PREDECESSOR, chữ SAU nói về SUCCESSOR.

⚠ Với SF: ⚠ Start của successor → Finish của predecessor.

⚠ Ví dụ kinh điển của SF: | Ví dụ | Nội dung | |---|---| | ⚠ Chuyển ca trực | ⚠ ca mới BẮT ĐẦU thì ca cũ mới KẾT THÚC | | ⚠ Chuyển hệ thống | ⚠ hệ thống mới chạy thì hệ thống cũ mới tắt | | ⚠ Điểm chung | ⚠ không được phép có khoảng trống, phải liền mạch |

Từ khoá nhận diện:

"cái mới phải chạy trước khi tắt cái cũ" → ⚠ SF "xong việc này mới làm việc kia" → ⚠ FS "cùng bắt đầu" → ⚠ SS "cùng kết thúc" → ⚠ FF

⚠ Mẹo làm dạng bài này Mẹo
⚠ Xác định rõ ai là predecessor, ai là successor ⚠ đề thường nói rõ, đọc kỹ
⚠ Viết ra câu "X phải ... thì Y mới ..."
⚠ Rồi khớp với bốn loại
⚠ Bẫy thường gặp ⚠ đảo nhầm vai trò predecessor và successor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai là predecessor, ai là successor | ⚠ đọc kỹ đề | | Quan hệ này có phải hard logic không | | | Phần mềm lập lịch có hỗ trợ SF không | ⚠ một số công cụ hạn chế |

Và lý do SF hiếm gặp nhưng vẫn cần biết: nó là cách duy nhất mô hình hoá việc chuyển giao liền mạch. Bất cứ khi nào cái mới phải sẵn sàng trước khi cái cũ được ngừng, đó chính là quan hệ Start-to-Finish.

Câu 25
You are a project manager for the HGJ Project and you’re working with the project team to complete a RACI chart for your project activities. Beth and Laura will be working together on the “Install HW Fixtures” tasks. Beth is a senior electrical engineer and Laura is her assistant. Laura wonders though if she too should have the “A” designation for the task since she’ll be working on it with Beth. What’s the best response?
  1. A If both employees are working on the task equally then yes, both should have the A designation.
  2. B The senior employee should always have the A designation in RACI.
  3. C Only one person per task may have the A designation.
  4. D Beth should have the R designation and Laura, the assistant, should have the A designation.
Xem giải thích

Đáp án

C — Mỗi hoạt động chỉ được có MỘT người mang chữ A.

Vì sao đúng

⚠ Quy tắc nền tảng của RACI: | Chữ | Số lượng cho phép | |---|---| | ⚠ R — Responsible | ⚠ NHIỀU người — ai cũng làm được | | ⚠ A — Accountable | ⚠ ĐÚNG MỘT người | | ⚠ C — Consult | ⚠ nhiều người | | ⚠ I — Inform | ⚠ nhiều người |

⚠ Vì sao chỉ một chữ A: ⚠ nếu hai người cùng chịu trách nhiệm cuối cùng thì ⚠ thực tế là KHÔNG AI chịu trách nhiệm — ⚠ mỗi người đều nghĩ người kia lo.

⚠ Trong tình huống này: ⚠ Beth và Laura cùng làm → ⚠ cả hai đều là R; ⚠ nhưng chỉ một người — thường là Beth, kỹ sư cấp cao — mang chữ A.

Vì sao các phương án khác sai

  • A (cả hai cùng mang A nếu làm ngang nhau) — ⚠ vi phạm quy tắc cốt lõi.

  • B (người cấp cao LUÔN mang chữ A) — ⚠ KHÔNG phải quy tắc; ⚠ chữ A gắn với trách nhiệm giải trình cho hoạt động đó, không phải với chức danh.

  • D (Beth là R, Laura là A) — ⚠ đảo ngược hợp lý; ⚠ người trợ lý ít khi là người chịu trách nhiệm cuối cùng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25529 ở lô trước hỏi RACI viết tắt của gì. ⚠ Câu này kiểm tra quy tắc áp dụng. Hai câu bổ sung nhau.

⚠ Bốn vai trò RACI: | Chữ | Vai trò | Đặc điểm | |---|---|---| | ⚠ R — Responsible | ⚠ người LÀM | ⚠ có thể nhiều người | | ⚠ A — Accountable | ⚠ người CHỊU TRÁCH NHIỆM cuối | ⚠ CHỈ MỘT | | ⚠ C — Consult | ⚠ được hỏi ý kiến | ⚠ hai chiều, TRƯỚC khi làm | | ⚠ I — Inform | ⚠ được thông báo | ⚠ một chiều, SAU khi làm |

⚠ Dấu hiệu một ma trận RACI có vấn đề: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Một hàng có hai chữ A | ⚠ trách nhiệm không rõ | | ⚠ Một hàng không có chữ R | ⚠ không ai làm | | ⚠ Một cột toàn chữ A | ⚠ nút thắt cổ chai ở một người | | ⚠ Một hàng có quá nhiều chữ C | ⚠ quyết định sẽ rất chậm | | ⚠ Một cột toàn chữ I | ⚠ người đó có thật sự cần trong dự án không |

Từ khoá nhận diện:

"chỉ một người chịu trách nhiệm cuối" → ⚠ chữ A "nhiều người cùng làm" → ⚠ chữ R "phải hỏi ý kiến trước" → ⚠ chữ C "chỉ cần biết kết quả" → ⚠ chữ I

⚠ Vì sao "một chữ A" là quy tắc cứng Lý do
⚠ Khi có sự cố, phải biết hỏi AI
⚠ Trách nhiệm chia đôi là trách nhiệm biến mất
⚠ Quyết định cần một người có thẩm quyền cuối
⚠ Một người CÓ THỂ vừa A vừa R ⚠ điều đó hoàn toàn hợp lệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi hàng có đúng một chữ A không | | | Có ai đang là A cho quá nhiều hoạt động không | | | Có hoạt động nào không có R không | |

Và lý do quy tắc "một chữ A" không phải chuyện hình thức: khi mọi việc trôi chảy thì ai chịu trách nhiệm không quan trọng; khi có sự cố thì đó là câu hỏi đầu tiên. Một ma trận có hai chữ A trên cùng một hàng sẽ không trả lời được câu hỏi đó.

Câu 26
Mary is the project manager for her organization, and she is a project manager for a new agile project. Management has asked Mary to show them the detailed project scope statement in this project. Mary reports that in agile projects there is not a detailed project scope. Management then wants to know where the project requirements are documented. What should Mary do next?
  1. A Show management the project scope management plan
  2. B Show management the product backlog
  3. C Show management the project WBS
  4. D Show management the Scrum statement
Xem giải thích

Đáp án

B — Cho ban lãnh đạo xem product backlog.

Vì sao đúng

⚠ Trong dự án linh hoạt, yêu cầu nằm trong PRODUCT BACKLOG: | Đặc điểm | Nội dung | |---|---| | ⚠ Danh sách có THỨ TỰ ƯU TIÊN | ⚠ mục quan trọng nhất ở trên | | ⚠ Là nguồn duy nhất của yêu cầu | ⚠ single source of truth | | ⚠ SỐNG — thay đổi liên tục | ⚠ thêm, bớt, sắp xếp lại mỗi vòng lặp | | ⚠ Product Owner sở hữu | | | ⚠ Mục trên cùng chi tiết hơn mục dưới | ⚠ progressive elaboration |

⚠ Vì sao không có scope statement chi tiết: ⚠ dự án linh hoạt chấp nhận phạm vi tiến hoá, ⚠ nên cố định chi tiết từ đầu là đi ngược nguyên tắc.

Vì sao các phương án khác sai

  • C (WBS) — ⚠ công cụ của cách tiếp cận dự đoán; ⚠ dự án linh hoạt dùng backlog thay cho WBS chi tiết.

  • A (scope management plan) — ⚠ mô tả CÁCH quản phạm vi, không chứa bản thân các yêu cầu.

  • D ("Scrum statement") — ⚠ không tồn tại.

Ghi nhớ

⚠ Đối chiếu công cụ giữa hai cách tiếp cận: | Dự đoán — predictive | Linh hoạt — adaptive | |---|---| | ⚠ Scope statement chi tiết | ⚠ product vision và backlog | | ⚠ WBS | ⚠ product backlog | | ⚠ Baseline cố định | ⚠ backlog sắp xếp lại liên tục | | ⚠ Change control chính thức | ⚠ thay đổi là bình thường, đưa vào backlog | | ⚠ Bàn giao một lần cuối | ⚠ bàn giao gia tăng mỗi vòng lặp |

⚠ Ba mức của backlog: | Mức | Nội dung | |---|---| | ⚠ Product backlog | ⚠ toàn bộ yêu cầu của sản phẩm | | ⚠ Release backlog | ⚠ phần dự kiến cho một lần phát hành | | ⚠ Sprint backlog | ⚠ phần đội cam kết cho vòng lặp hiện tại |

Từ khoá nhận diện:

"yêu cầu trong dự án linh hoạt" → ⚠ product backlog "phân rã sản phẩm bàn giao" → ⚠ WBS, cách dự đoán "làm mịn backlog" → ⚠ backlog refinement, grooming "tiêu chí hoàn thành" → ⚠ definition of done

⚠ Backlog refinement Nội dung
⚠ Làm rõ và ước lượng các mục sắp tới
⚠ Chia mục lớn thành mục nhỏ hơn
⚠ Sắp xếp lại thứ tự ưu tiên
⚠ Diễn ra LIÊN TỤC, không phải một lần
⚠ Thường chiếm ⚠ khoảng 10% thời gian của đội
⚠ Ai quyết định gì trong Scrum Vai trò
⚠ Product Owner ⚠ quyết định LÀM GÌ và theo thứ tự nào
⚠ Development Team ⚠ quyết định LÀM BAO NHIÊU và LÀM THẾ NÀO
⚠ Scrum Master ⚠ bảo vệ quy trình, gỡ vướng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog có được sắp xếp theo ưu tiên không | ⚠ backlog không có thứ tự là danh sách mong muốn, không phải backlog | | Ai là người quyết định thứ tự | | | Các mục trên cùng đã đủ chi tiết để làm chưa | |

Và điều phân biệt một product backlog thật với một danh sách mong muốn: thứ tự ưu tiên. Nếu mọi mục đều "quan trọng như nhau" thì đội không có cơ sở để chọn làm gì trước, và toàn bộ giá trị của backlog biến mất.

Câu 27
You are a project manager for the KJG Project and you want to create a stakeholder register with the project team. In this register, you want to include the stakeholder identification information, the assessment information, and what other attributes should be included?
  1. A Stakeholder classification
  2. B Responsibilities in the project
  3. C Primary concerns for project requirements
  4. D Role of the project team
Xem giải thích

Đáp án

A — Stakeholder classification (phân loại bên liên quan).

Vì sao đúng

⚠ Stakeholder register có ba nhóm thông tin: | Nhóm | Nội dung | |---|---| | ⚠ Identification information | ⚠ tên, chức danh, vị trí, vai trò, thông tin liên hệ | | ⚠ Assessment information | ⚠ yêu cầu chính, kỳ vọng, mức ảnh hưởng, giai đoạn quan tâm nhất | | ⚠ Stakeholder classification | ⚠ trong hay ngoài tổ chức; ủng hộ, trung lập hay phản đối; quyền lực và quan tâm |

⚠ Đề đã nêu hai nhóm đầu, ⚠ nhóm còn thiếu chính là phân loại.

Vì sao các phương án khác sai

  • B (trách nhiệm trong dự án) và D (vai trò của đội dự án) — ⚠ thuộc về ma trận trách nhiệm — RACI, không phải stakeholder register.

  • C (mối quan tâm chính về yêu cầu) — ⚠ đã nằm trong nhóm ASSESSMENT, không phải nhóm thứ ba.

Ghi nhớ

⚠ Các mô hình phân loại bên liên quan: | Mô hình | Trục | |---|---| | ⚠ Power/Interest grid | ⚠ quyền lực × mức quan tâm | | ⚠ Power/Influence grid | ⚠ quyền lực × mức ảnh hưởng | | ⚠ Impact/Influence grid | ⚠ tác động × ảnh hưởng | | ⚠ Salience model | ⚠ quyền lực × tính cấp bách × tính chính danh | | ⚠ Stakeholder cube | ⚠ mô hình ba chiều | | ⚠ Directions of influence | ⚠ lên trên, xuống dưới, ngang, ra ngoài |

⚠ Power/Interest grid — bốn ô và cách ứng xử: | Ô | Cách ứng xử | |---|---| | ⚠ Quyền lực CAO, quan tâm CAO | ⚠ quản lý CHẶT CHẼ — manage closely | | ⚠ Quyền lực CAO, quan tâm THẤP | ⚠ giữ HÀI LÒNG — keep satisfied | | ⚠ Quyền lực THẤP, quan tâm CAO | ⚠ giữ THÔNG TIN — keep informed | | ⚠ Quyền lực THẤP, quan tâm THẤP | ⚠ theo dõi — monitor |

Từ khoá nhận diện:

"phân loại bên liên quan" → ⚠ stakeholder register, nhóm classification "ai chịu trách nhiệm việc gì" → ⚠ RACI "quyền lực, cấp bách, chính danh" → ⚠ salience model "mức tham gia hiện tại và mong muốn" → ⚠ stakeholder engagement assessment matrix

⚠ Năm mức tham gia của bên liên quan Mức
⚠ Unaware ⚠ không biết dự án tồn tại
⚠ Resistant ⚠ phản đối
⚠ Neutral ⚠ trung lập
⚠ Supportive ⚠ ủng hộ
⚠ Leading ⚠ chủ động dẫn dắt
⚠ Ma trận đánh giá ⚠ ghi mức HIỆN TẠI (C) và mức MONG MUỐN (D) cho từng người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Register có được cập nhật khi có người mới không | | | Có bên liên quan nào đang phản đối mà chưa ai xử lý không | | | Người quyền lực cao có được giữ hài lòng không | |

Và điều làm stakeholder register có giá trị thật, thay vì chỉ là một danh sách tên: nó ghi cả thái độ và mức ảnh hưởng. Đó là thứ giúp bạn biết dành thời gian cho ai — và ai là người có thể dừng dự án của bạn bằng một cuộc gọi.

Câu 28
Martha is a project manager in her organization and she is working with the project team to create a data representation of the stakeholders' authority and interest in the project. She wants to create a salience model for the key stakeholders. In this model, all of the following attributes are used except for which one?
  1. A Urgency
  2. B Power
  3. C Legitimacy
  4. D Influence
Xem giải thích

Đáp án

D — Influence (mức ảnh hưởng).

Vì sao đúng

⚠ Salience model dùng ĐÚNG BA thuộc tính: | Thuộc tính | Nghĩa | |---|---| | ⚠ Power — quyền lực | ⚠ khả năng ÁP ĐẶT ý muốn lên dự án | | ⚠ Urgency — tính cấp bách | ⚠ nhu cầu của họ cần được đáp ứng NGAY tới mức nào | | ⚠ Legitimacy — tính chính danh | ⚠ họ có QUYỀN CHÍNH ĐÁNG để tham gia không |

⚠ "Influence" không nằm trong salience model — ⚠ nó là trục của các mô hình khác như Power/Influence grid hay Impact/Influence grid.

Vì sao các phương án khác sai

  • A (Urgency), B (Power), C (Legitimacy) — ⚠ đều là ba thuộc tính chính thức của salience model.

Ghi nhớ

⚠ Bảy nhóm bên liên quan theo salience model: | Nhóm | Có thuộc tính nào | |---|---| | ⚠ Dormant | ⚠ chỉ POWER | | ⚠ Discretionary | ⚠ chỉ LEGITIMACY | | ⚠ Demanding | ⚠ chỉ URGENCY | | ⚠ Dominant | ⚠ power + legitimacy | | ⚠ Dangerous | ⚠ power + urgency — KHÔNG chính danh | | ⚠ Dependent | ⚠ urgency + legitimacy — không có quyền lực | | ⚠ Definitive | ⚠ CẢ BA — quan trọng nhất |

⚠ Nhóm "dangerous" đáng chú ý nhất: ⚠ có quyền lực và cấp bách nhưng không chính danh — ⚠ ví dụ nhóm phản đối gây sức ép.

⚠ So sánh các mô hình phân loại: | Mô hình | Số trục | Trục | |---|---|---| | ⚠ Power/Interest | ⚠ 2 | ⚠ quyền lực, quan tâm | | ⚠ Power/Influence | ⚠ 2 | ⚠ quyền lực, ảnh hưởng | | ⚠ Impact/Influence | ⚠ 2 | ⚠ tác động, ảnh hưởng | | ⚠ Salience | ⚠ 3 | ⚠ quyền lực, cấp bách, chính danh | | ⚠ Stakeholder cube | ⚠ 3 | ⚠ kết hợp các lưới hai chiều |

Từ khoá nhận diện:

"quyền lực, cấp bách, chính danh" → ⚠ salience model "quyền lực và mức quan tâm" → ⚠ power/interest grid "mức tham gia hiện tại và mong muốn" → ⚠ engagement assessment matrix "lên, xuống, ngang, ra ngoài" → ⚠ directions of influence

⚠ Vì sao "legitimacy" quan trọng Lý do
⚠ Phân biệt bên liên quan THẬT với người chỉ ồn ào
⚠ Nhóm dangerous cần chiến lược riêng ⚠ có sức ép nhưng không có quyền chính đáng
⚠ Giúp phân bổ thời gian hợp lý
⚠ Nhưng cẩn thận ⚠ bỏ qua nhóm dangerous là sai lầm — họ vẫn gây hại được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bên liên quan nào thuộc nhóm definitive không | ⚠ họ cần ưu tiên cao nhất | | Có nhóm dangerous nào chưa có chiến lược không | | | Phân loại có được cập nhật khi tình hình đổi không | |

Và giá trị riêng của salience model so với các lưới hai chiều: nó tách được "có quyền lực" khỏi "có quyền chính đáng". Một nhóm gây sức ép mạnh mà không có tư cách chính danh cần cách xử lý hoàn toàn khác với một bên liên quan hợp pháp.

Câu 29
Beth is a project manager for her organization, and she is leading a massive construction project. She and the project team have determined that the electrical work on the project is too dangerous for the team to take on, so they have outsourced this part of the project work. Beth would like to capture this portion of the project in her network diagram, but she doesn’t know all of the activities the electricians would do. What should Beth do next?
  1. A Create a fragnet in her network diagram for the outsourced work.
  2. B Interview the electricians to capture all of their activities.
  3. C Create her network diagram without the electrical work since the project team won’t be doing this work.
  4. D Ask the vendor to provide their project network diagram for the portion of the project they are completing for Beth’s organization.
Xem giải thích

Đáp án

A — Tạo một fragnet trong sơ đồ mạng cho phần việc thuê ngoài.

Vì sao đúng

⚠ Fragnet — còn gọi là subnet hoặc subnetwork: | Đặc điểm | Nội dung | |---|---| | ⚠ Là một PHẦN của sơ đồ mạng lớn | | | ⚠ Đại diện cho một khối công việc | ⚠ có thể chi tiết hoá sau | | ⚠ Dùng khi chưa biết hết chi tiết | ⚠ hoặc khi phần việc lặp lại nhiều lần | | ⚠ Nhà thầu cung cấp chi tiết sau | ⚠ rồi ghép vào đúng chỗ |

⚠ Đúng tình huống của Beth: ⚠ biết có khối công việc điện, ⚠ chưa biết chi tiết, ⚠ nhưng vẫn cần thể hiện nó trong sơ đồ để tính đường găng.

Vì sao các phương án khác sai

  • D (yêu cầu nhà thầu cung cấp sơ đồ mạng của họ) — ⚠ hữu ích và nên làm, nhưng ⚠ không phải bước TIẾP THEO; Beth cần biểu diễn phần việc đó trong sơ đồ của mình ngay.

  • B (phỏng vấn thợ điện để ghi hết hoạt động) — ⚠ quá chi tiết và không cần thiết; đó là việc của nhà thầu.

  • C (bỏ hẳn phần việc điện khỏi sơ đồ) — ⚠ SAI nghiêm trọng; ⚠ bỏ đi thì đường găng và tổng thời lượng dự án đều sai.

Ghi nhớ

⚠ Fragnet dùng trong hai tình huống: | Tình huống | Nội dung | |---|---| | ⚠ Công việc thuê ngoài | ⚠ chưa biết chi tiết, nhà thầu bổ sung sau | | ⚠ Công việc LẶP LẠI | ⚠ ví dụ mỗi tầng của toà nhà đều làm giống nhau | | ⚠ Lợi ích | ⚠ vẽ một lần, dùng nhiều chỗ |

⚠ Nguyên tắc: KHÔNG bỏ công việc thuê ngoài khỏi sơ đồ: | Lý do | Nội dung | |---|---| | ⚠ Nó chiếm THỜI GIAN trong lịch | | | ⚠ Nó có thể nằm trên ĐƯỜNG GĂNG | | | ⚠ Các hoạt động khác phụ thuộc vào nó | | | ⚠ Nó vẫn thuộc phạm vi dự án | ⚠ dù ai làm cũng vậy | | ⚠ Ai làm | ⚠ không đổi được thực tế rằng nó phải xong |

Từ khoá nhận diện:

"khối công việc chưa rõ chi tiết trong sơ đồ mạng" → ⚠ fragnet, subnet "đường dài nhất qua sơ đồ" → ⚠ critical path "thời gian trì hoãn cho phép" → ⚠ float, slack "phần việc giao cho bên ngoài" → ⚠ vẫn thuộc phạm vi dự án

⚠ Khái niệm float — hay hỏi cùng sơ đồ mạng Loại
⚠ Total float ⚠ trì hoãn được bao lâu mà không ảnh hưởng NGÀY KẾT THÚC dự án
⚠ Free float ⚠ trì hoãn được bao lâu mà không ảnh hưởng hoạt động KẾ TIẾP
⚠ Project float ⚠ so với ngày hạn áp đặt từ bên ngoài
⚠ Hoạt động trên đường găng ⚠ có total float bằng 0
⚠ Quản lý phần việc thuê ngoài Việc
⚠ Đưa vào sơ đồ mạng dưới dạng fragnet
⚠ Yêu cầu nhà thầu báo cáo tiến độ định kỳ
⚠ Xác định mốc bàn giao rõ ràng
⚠ Theo dõi như mọi hoạt động khác ⚠ thuê ngoài không có nghĩa là hết trách nhiệm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phần việc thuê ngoài có trong sơ đồ mạng không | | | Nó có nằm trên đường găng không | | | Nhà thầu có cung cấp lịch chi tiết không | |

Và sai lầm nguy hiểm nhất khi thuê ngoài một phần dự án: coi như phần đó không còn là việc của mình. Nó vẫn nằm trong phạm vi, vẫn chiếm thời gian trên đường găng, và khi nó chậm thì dự án của bạn chậm.

Câu 30
Nancy is a project manager in her organization and she’s working with the project team to plan communications management. Robert, the project sponsor, tells Nancy that he’ll be glad when this planning activity is over because he doesn’t like planning and would rather get to the project execution. Nancy tells Robert that the communications planning activity will happen whenever new stakeholders are identified in the project and one other factor. When else should communications planning definitely happen in a project?
  1. A At the start of each project phase
  2. B At the end of the project
  3. C During project procurement
  4. D When risks are identified
Xem giải thích

Đáp án

A — Ở đầu mỗi giai đoạn của dự án.

Vì sao đúng

⚠ Plan Communications Management là quy trình LẶP LẠI: | Khi nào lặp lại | Lý do | |---|---| | ⚠ Đầu mỗi giai đoạn dự án | ⚠ bên liên quan và nhu cầu thông tin thay đổi theo giai đoạn | | ⚠ Khi có bên liên quan MỚI | ⚠ đề đã nêu | | ⚠ Khi cơ cấu tổ chức thay đổi | | | ⚠ Khi cách truyền thông hiện tại không hiệu quả | |

⚠ Ví dụ: ⚠ giai đoạn thiết kế cần trao đổi nhiều với kiến trúc sư; ⚠ giai đoạn thi công lại cần với nhà thầu và cơ quan quản lý — ⚠ hai nhóm hoàn toàn khác nhau.

Vì sao các phương án khác sai

  • B (ở cuối dự án) — ⚠ quá muộn; ⚠ lập kế hoạch truyền thông là việc làm TRƯỚC, không phải sau.

  • C (trong quá trình mua sắm) — ⚠ một tình huống cụ thể, không phải mốc chung của dự án.

  • D (khi nhận diện rủi ro) — ⚠ có thể kéo theo cập nhật, nhưng không phải mốc bắt buộc như đầu giai đoạn.

Ghi nhớ

⚠ Kế hoạch quản lý truyền thông trả lời: | Câu hỏi | Nội dung | |---|---| | ⚠ AI cần thông tin gì | | | ⚠ KHI NÀO và bao lâu một lần | | | ⚠ Bằng ĐỊNH DẠNG và KÊNH nào | | | ⚠ AI chịu trách nhiệm gửi | | | ⚠ AI được phép nhận thông tin nhạy cảm | | | ⚠ Ngôn ngữ và múi giờ | ⚠ với dự án đa quốc gia | | ⚠ Quy trình leo thang khi có vấn đề | |

⚠ Ba phương pháp truyền thông: | Phương pháp | Nội dung | |---|---| | ⚠ Interactive | ⚠ hai chiều thời gian thực — họp, gọi điện | | ⚠ Push | ⚠ gửi đi, không chắc đã đọc — email, báo cáo | | ⚠ Pull | ⚠ người nhận tự lấy — wiki, kho tài liệu |

⚠ Công thức kênh giao tiếp: | Nội dung | Công thức | |---|---| | ⚠ Số kênh | ⚠ n × (n − 1) ÷ 2 | | ⚠ 10 người | ⚠ 45 kênh | | ⚠ 15 người | ⚠ 105 kênh | | ⚠ Bài học | ⚠ thêm người thì độ phức tạp tăng theo BÌNH PHƯƠNG |

Từ khoá nhận diện:

"lặp lại ở đầu mỗi giai đoạn" → ⚠ Plan Communications Management "số kênh giao tiếp" → ⚠ n(n−1)/2 "gửi đi mà không chắc người nhận đọc" → ⚠ push "người nhận tự tìm" → ⚠ pull

⚠ Năm yếu tố của mô hình truyền thông Yếu tố
⚠ Encode ⚠ người gửi mã hoá thông điệp
⚠ Transmit ⚠ truyền qua kênh
⚠ Decode ⚠ người nhận giải mã
⚠ Acknowledge ⚠ xác nhận đã nhận
⚠ Feedback ⚠ phản hồi về nội dung
⚠ Nhiễu — noise ⚠ có thể xen vào ở mọi khâu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch truyền thông đã cập nhật cho giai đoạn hiện tại chưa | | | Có bên liên quan mới nào chưa vào kế hoạch không | | | Người nhận có thật sự đọc thông tin được gửi không | |

Và điểm phân biệt giữa "đã gửi" và "đã truyền đạt": xác nhận và phản hồi. Một báo cáo gửi đi mà không ai đọc là truyền thông thất bại — dù về mặt thủ tục thì bạn đã làm đủ.