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

Tìm thấy 201 câu.

Câu 41
You are a project manager for the HJG Project and you’re working with the project team to address the testing and control quality processes for your project. Management has requested that zero defects escape from the project and strict quality control processes must be implemented. One of the team members asks why they can’t just address any defects found by the customer as they come up. Of course, this isn’t a good practice for many reasons, but one of the best reasons is which one of the following choices?
  1. A Errors found by customers is the most expensive approach
  2. B Customers may not be able to readily identify all the defects
  3. C It’s not what management has requested
  4. D It’s embarrassing to the organization and hurts the organization
Xem giải thích

Đáp án

A — Lỗi do khách hàng phát hiện là cách TỐN KÉM NHẤT.

Vì sao đúng

⚠ Chi phí sửa lỗi tăng theo cấp số nhân qua từng giai đoạn: | Phát hiện ở giai đoạn | Chi phí tương đối | |---|---| | ⚠ Thiết kế | ⚠ thấp nhất — chỉ sửa tài liệu | | ⚠ Xây dựng | ⚠ cao hơn — làm lại một phần | | ⚠ Kiểm thử | ⚠ cao hơn nữa | | ⚠ Sau khi giao cho khách | ⚠ CAO NHẤT |

⚠ Vì sao khách phát hiện lại đắt nhất: | Chi phí | Nội dung | |---|---| | ⚠ Chi phí sửa chính lỗi đó | | | ⚠ Chi phí thu hồi hoặc triển khai lại | | | ⚠ Chi phí hỗ trợ và xử lý khiếu nại | | | ⚠ Mất uy tín và có thể mất khách hàng | | | ⚠ Có thể phải bồi thường theo hợp đồng | |

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

  • D (gây xấu hổ và tổn hại tổ chức) — ⚠ ĐÚNG nhưng là hệ quả về UY TÍN, ⚠ không phải lý do mạnh nhất về mặt quản lý dự án.

  • B (khách có thể không nhận ra hết lỗi) — ⚠ đúng, nhưng lại là một LÝ DO KHÁC, không phải lý do tốt nhất.

  • C (không phải điều ban lãnh đạo yêu cầu) — ⚠ là lập luận theo mệnh lệnh, không giải thích được VÌ SAO.

Ghi nhớ

⚠ Chi phí chất lượng — Cost of Quality: | Nhóm | Thành phần | |---|---| | ⚠ Cost of Conformance | ⚠ chi phí để LÀM ĐÚNG | | ⚠ — Prevention costs | ⚠ đào tạo, tài liệu quy trình, thiết bị đúng | | ⚠ — Appraisal costs | ⚠ kiểm thử, kiểm tra, đánh giá | | ⚠ Cost of Non-conformance | ⚠ chi phí khi LÀM SAI | | ⚠ — Internal failure | ⚠ phát hiện TRONG dự án — làm lại, huỷ bỏ | | ⚠ — External failure | ⚠ KHÁCH phát hiện — bảo hành, thu hồi, mất uy tín |

⚠ External failure luôn là nhóm ĐẮT NHẤT.

Từ khoá nhận diện:

"khách hàng phát hiện lỗi" → ⚠ external failure cost, đắt nhất "phát hiện trong nội bộ" → ⚠ internal failure cost "đào tạo, quy trình" → ⚠ prevention cost "kiểm thử, kiểm tra" → ⚠ appraisal cost

⚠ Nguyên tắc chất lượng của PMBOK Nguyên tắc
⚠ Phòng ngừa HƠN kiểm tra ⚠ prevention over inspection
⚠ Chất lượng được XÂY VÀO, không kiểm tra ra
⚠ Trách nhiệm quản lý ⚠ ban lãnh đạo chịu trách nhiệm cung cấp nguồn lực cho chất lượng
⚠ Cải tiến liên tục ⚠ PDCA, Kaizen, Six Sigma
⚠ Khái niệm liên quan hay hỏi Khái niệm
⚠ Gold plating ⚠ thêm tính năng khách KHÔNG yêu cầu — nên TRÁNH
⚠ Marginal analysis ⚠ tăng chất lượng tới khi chi phí thêm vượt lợi ích thêm
⚠ Grade và Quality ⚠ cấp thấp mà chất lượng cao thì chấp nhận được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ lỗi lọt ra khách hàng là bao nhiêu | | | Chi phí phòng ngừa có được đầu tư đủ không | | | Có đang làm quá mức yêu cầu không | ⚠ gold plating cũng là lãng phí |

Và con số thường được trích dẫn trong tài liệu chất lượng: sửa một lỗi sau khi giao cho khách tốn gấp nhiều lần so với sửa nó ở giai đoạn thiết kế. Đó chính là lập luận kinh tế cho mọi khoản đầu tư vào phòng ngừa.

Câu 42
John is a project manager, and he’s working with his project team to define all of the requirements used in the project. One of the decisions in the project is the selection of a sculpture that will go in the lobby of the new office complex. John and the key stakeholders have decided to allow everyone to vote on which sculpture will be selected using the plurality approach for the three choices. Sculpture A received 457 votes, Sculpture B received 120 votes, and Sculpture C received 459 votes. Which sculpture will be installed in the lobby?
  1. A Sculpture B will be installed as Sculpture A and Sculpture C cancel each other out, and therefore Sculpture B has the most remaining votes.
  2. B Undetermined; there is not a majority of voters for anyone sculpture as there are more voters against the statue with the most votes.
  3. C Sculpture A and Sculpture C will be voted on again without Sculpture B splitting the votes.
  4. D Sculpture C will be installed as it has the most votes.
Xem giải thích

Đáp án

D — Tượng C sẽ được lắp đặt vì nó có NHIỀU PHIẾU NHẤT.

Vì sao đúng

⚠ Plurality — đa số tương đối: | Nguyên tắc | Nội dung | |---|---| | ⚠ Phương án có NHIỀU PHIẾU NHẤT thắng | | | ⚠ KHÔNG cần quá bán | ⚠ khác với majority | | ⚠ Dùng khi có từ BA lựa chọn trở lên | |

⚠ Kiểm tra số liệu: | Tượng | Phiếu | |---|---| | ⚠ A | ⚠ 457 | | ⚠ B | ⚠ 120 | | ⚠ C | ⚠ 459 — NHIỀU NHẤT | | ⚠ Tổng | ⚠ 1.036 phiếu | | ⚠ Quá bán cần | ⚠ 519 phiếu — không phương án nào đạt | | ⚠ Nhưng | ⚠ plurality không đòi hỏi điều đó |

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

  • B (không xác định được vì không ai quá bán) — ⚠ đó là quy tắc MAJORITY, không phải plurality.

  • C (bỏ phiếu lại giữa A và C) — ⚠ là bỏ phiếu vòng hai — runoff, một quy tắc khác.

  • A (A và C triệt tiêu nhau) — ⚠ không có quy tắc bỏ phiếu nào như vậy.

Ghi nhớ

⚠ Bốn kỹ thuật ra quyết định nhóm: | Kỹ thuật | Nội dung | |---|---| | ⚠ Unanimity | ⚠ TẤT CẢ đồng ý — ví dụ Delphi | | ⚠ Majority | ⚠ QUÁ BÁN, tức hơn 50% | | ⚠ Plurality | ⚠ NHIỀU PHIẾU NHẤT, không cần quá bán | | ⚠ Autocratic | ⚠ MỘT người quyết |

⚠ Mẹo nhớ: ⚠ Majority cần hơn một nửa; Plurality chỉ cần nhiều hơn các phương án khác.

Từ khoá nhận diện:

"nhiều phiếu nhất thắng" → ⚠ plurality "quá bán" → ⚠ majority "tất cả phải đồng ý" → ⚠ unanimity "một người quyết" → ⚠ autocratic

⚠ Khi nào dùng plurality Khi nào
⚠ Có nhiều hơn hai lựa chọn
⚠ Cần quyết định nhanh
⚠ Quyết định không quá quan trọng
⚠ Nhược điểm ⚠ người thắng có thể chỉ được thiểu số ủng hộ — như trường hợp này, 459/1.036 chưa tới 45%
⚠ Các kỹ thuật bỏ phiếu khác trong PMBOK Kỹ thuật
⚠ Fist of five ⚠ giơ 0–5 ngón để thể hiện mức đồng thuận
⚠ Roman voting ⚠ ngón cái lên hoặc xuống
⚠ Multi-voting ⚠ mỗi người có nhiều phiếu, chia cho các lựa chọn
⚠ Mục đích chung ⚠ thấy nhanh mức đồng thuận của nhóm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc bỏ phiếu đã thống nhất TRƯỚC khi bỏ chưa | ⚠ thống nhất sau là nguồn tranh cãi | | Người thắng có được đa số thật sự ủng hộ không | | | Quyết định này có quan trọng tới mức cần đồng thuận cao hơn không | |

Và điều cần thống nhất trước mọi cuộc bỏ phiếu: luật chơi. Tranh cãi về việc "thế nào là thắng" sau khi đã có kết quả là cách nhanh nhất để biến một quyết định thành một mâu thuẫn.

Câu 43
Ned is a project manager in his organization and you are serving as a project management consultant on Ned’s project. Ned insists that his project needs a high-quality grade of material for the project work to be successful. You advise that quality and grade are often misunderstood. What’s the difference between quality and grade?
  1. A Quality is how well the materials fulfill requirements. Grade is a ranking or categorization of the materials.
  2. B Quality is about having the best product, while grade is about having the correct products.
  3. C Grade is the level of satisfaction the workers require from materials, while quality is the ability of the materials to deliver upon their satisfaction.
  4. D Actually, Ned is correct. Quality and grade are now considered to be the same term in the PMBOK Guide, sixth edition.
Xem giải thích

Đáp án

A — Quality là mức độ vật liệu đáp ứng YÊU CẦU. Grade là sự PHÂN HẠNG hay xếp loại của vật liệu.

Vì sao đúng

⚠ Hai khái niệm hoàn toàn khác nhau: | Khái niệm | Nghĩa | |---|---| | ⚠ Quality — chất lượng | ⚠ mức độ đáp ứng YÊU CẦU đã nêu | | ⚠ Grade — cấp độ | ⚠ phân hạng theo đặc tính KỸ THUẬT hoặc tính năng |

⚠ Bốn tổ hợp có thể xảy ra: | Tổ hợp | Chấp nhận được không | |---|---| | ⚠ Cấp THẤP, chất lượng CAO | ⚠ CHẤP NHẬN ĐƯỢC — sản phẩm đơn giản nhưng làm đúng | | ⚠ Cấp CAO, chất lượng CAO | ⚠ tốt, nhưng có thể thừa và tốn kém | | ⚠ Cấp THẤP, chất lượng THẤP | ⚠ VẤN ĐỀ | | ⚠ Cấp CAO, chất lượng THẤP | ⚠ VẤN ĐỀ NGHIÊM TRỌNG — đắt mà vẫn hỏng |

⚠ Nguyên tắc của PMBOK: ⚠ cấp độ thấp có thể chấp nhận, chất lượng thấp thì KHÔNG BAO GIỜ.

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

  • B (chất lượng là có sản phẩm tốt nhất, cấp độ là có sản phẩm đúng) — ⚠ đảo ngược khái niệm.

  • D (hai từ nay được coi là giống nhau) — ⚠ SAI hoàn toàn; ⚠ PMBOK luôn phân biệt rõ hai khái niệm.

  • C (cấp độ là mức hài lòng của người làm) — ⚠ không đúng với định nghĩa nào.

Ghi nhớ

⚠ Ví dụ minh hoạ kinh điển: | Ví dụ | Cấp độ | Chất lượng | |---|---|---| | ⚠ Phần mềm ít tính năng nhưng KHÔNG có lỗi | ⚠ thấp | ⚠ CAO — chấp nhận được | | ⚠ Phần mềm nhiều tính năng nhưng ĐẦY lỗi | ⚠ cao | ⚠ THẤP — không chấp nhận | | ⚠ Bài học | ⚠ khách hàng chấp nhận sản phẩm đơn giản, không chấp nhận sản phẩm hỏng |

Từ khoá nhận diện:

"mức đáp ứng yêu cầu" → ⚠ quality "phân hạng, xếp loại kỹ thuật" → ⚠ grade "các lần đo gần nhau" → ⚠ precision, độ chụm "gần giá trị thật" → ⚠ accuracy, độ chính xác

⚠ Precision và Accuracy — cặp khái niệm hay hỏi cùng Phân biệt
⚠ Precision ⚠ các lần đo GẦN NHAU
⚠ Accuracy ⚠ kết quả GẦN GIÁ TRỊ THẬT
⚠ Chụm mà không chính xác ⚠ luôn lệch cùng một hướng — lỗi hệ thống
⚠ Chính xác mà không chụm ⚠ trung bình đúng nhưng dao động lớn
⚠ Cần cả hai ⚠ để phép đo tin cậy được
⚠ Gold plating — sai lầm liên quan Nội dung
⚠ Thêm tính năng khách KHÔNG yêu cầu ⚠ nâng cấp độ mà khách không đòi
⚠ Tốn chi phí và thời gian
⚠ Thêm rủi ro và lỗi
⚠ Không được tính là "chất lượng cao hơn" ⚠ vì chất lượng đo bằng mức đáp ứng YÊU CẦU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu về cấp độ đã được thống nhất chưa | | | Có đang làm quá mức yêu cầu không | ⚠ gold plating | | Tiêu chí nghiệm thu chất lượng đã rõ chưa | |

Và câu ngắn gọn nhất để nhớ khác biệt: cấp độ là "bao nhiêu tính năng", chất lượng là "có làm đúng không". Một chiếc xe hạng phổ thông chạy tốt là cấp thấp chất lượng cao — và đó là một sản phẩm hoàn toàn hợp lệ.

Câu 44
Consider a project that is running behind schedule. The project manager has elected to utilize fast-tracking to reduce the overall duration of the project. Which one of the following statements best describes fast-tracking characteristics?
  1. A Fast-tracking removes all float in the project to reduce project duration but can increase project risk.
  2. B Fast-tracking allows phases to overlap to reduce project duration but can increase project risk.
  3. C Fast-tracking removes all float to reduce project duration but can increase project cost.
  4. D Fast-tracking adds labor to the project work but can increase project costs.
Xem giải thích

Đáp án

B — Fast-tracking cho phép các giai đoạn CHỒNG LẤN để rút ngắn thời lượng, nhưng có thể LÀM TĂNG RỦI RO.

Vì sao đúng

⚠ Fast-tracking — chạy song song: | Đặc điểm | Nội dung | |---|---| | ⚠ Làm SONG SONG các việc vốn nối tiếp | ⚠ hoặc cho giai đoạn chồng lấn | | ⚠ KHÔNG tốn thêm chi phí trực tiếp | ⚠ không thêm người | | ⚠ TĂNG rủi ro | ⚠ bắt đầu việc sau khi việc trước chưa hoàn tất | | ⚠ Có thể phải LÀM LẠI | ⚠ rework nếu việc trước thay đổi | | ⚠ Chỉ áp cho SOFT LOGIC | ⚠ hard logic không chồng lấn được |

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

  • A và C (fast-tracking loại bỏ mọi float) — ⚠ SAI; ⚠ fast-tracking không xoá float, nó cho các việc chồng lấn; ⚠ float là hệ quả của cấu trúc mạng.

  • D (thêm nhân lực) — ⚠ đó là CRASHING, không phải fast-tracking.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25558 trong lô này về resource leveling — làm lịch DÀI ra. ⚠ Câu này về fast-tracking — làm lịch NGẮN lại. Hai câu là hai chiều ngược nhau của việc điều chỉnh lịch.

⚠ Bốn kỹ thuật điều chỉnh lịch — bảng so sánh: | Kỹ thuật | Tác động lên lịch | Cái giá | |---|---|---| | ⚠ Crashing | ⚠ NGẮN lại | ⚠ TĂNG chi phí | | ⚠ Fast tracking | ⚠ NGẮN lại | ⚠ TĂNG rủi ro và làm lại | | ⚠ Resource leveling | ⚠ thường DÀI ra | ⚠ tôn trọng giới hạn nguồn lực | | ⚠ Resource smoothing | ⚠ KHÔNG đổi | ⚠ chỉ dùng float sẵn có |

⚠ Mẹo nhớ: ⚠ Crashing tốn TIỀN, Fast-tracking tốn RỦI RO.

Từ khoá nhận diện:

"chồng lấn, làm song song" → ⚠ fast tracking "thêm người, thêm ca" → ⚠ crashing "giới hạn nguồn lực" → ⚠ resource leveling "làm phẳng trong float" → ⚠ resource smoothing

⚠ Thứ tự cân nhắc khi cần rút ngắn lịch Bước
⚠ 1. Xác định đường găng ⚠ nén ngoài đường găng là vô ích
⚠ 2. Fast tracking trước ⚠ không tốn tiền, nhưng xem rủi ro có chấp nhận được không
⚠ 3. Crashing sau ⚠ nén hoạt động có chi phí nén thấp nhất trước
⚠ 4. Xem lại phạm vi ⚠ nếu hai cách trên không đủ
⚠ Luôn nhớ ⚠ nén xong phải tính lại đường găng — có thể xuất hiện đường găng MỚI
⚠ Rủi ro cụ thể của fast tracking Rủi ro
⚠ Bắt đầu xây khi thiết kế chưa duyệt xong ⚠ thiết kế đổi thì phải phá đi làm lại
⚠ Kiểm thử khi mã còn đang viết ⚠ kiểm thử lại nhiều lần
⚠ Cần phối hợp chặt hơn hẳn
⚠ Chỉ nên dùng khi ⚠ rủi ro làm lại nhỏ hơn giá trị của việc về đích sớm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hoạt động định chồng lấn có phải soft logic không | ⚠ hard logic thì không chồng được | | Rủi ro làm lại đã được ước lượng chưa | | | Sau khi nén, đường găng có đổi không | |

Và sai lầm phổ biến khi nén lịch: nén những hoạt động KHÔNG nằm trên đường găng. Công sức bỏ ra là thật, nhưng ngày hoàn thành dự án không nhúc nhích một ngày nào.

Câu 45
When two people are communicating via a web conference what component of the communication model is represented by the Internet?
  1. A Host
  2. B Encode/Decode
  3. C Medium
  4. D Transmit message
Xem giải thích

Đáp án

C — Medium (phương tiện truyền).

Vì sao đúng

⚠ Các thành phần của mô hình truyền thông: | Thành phần | Vai trò | Trong ví dụ | |---|---|---| | ⚠ Sender | ⚠ người gửi | ⚠ người nói | | ⚠ Encode | ⚠ mã hoá ý thành thông điệp | ⚠ chọn từ ngữ | | ⚠ Message | ⚠ bản thân thông điệp | | | ⚠ Medium | ⚠ PHƯƠNG TIỆN truyền tải | ⚠ INTERNET, đường truyền | | ⚠ Decode | ⚠ người nhận giải mã | | | ⚠ Receiver | ⚠ người nhận | | | ⚠ Noise | ⚠ nhiễu | ⚠ mạng chậm, tiếng ồn, hiểu nhầm | | ⚠ Feedback | ⚠ phản hồi | |

⚠ Internet chính là KÊNH mang thông điệp đi — ⚠ đó là medium.

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

  • B (Encode/Decode) — ⚠ là việc của NGƯỜI gửi và người nhận, không phải kênh truyền.

  • D (Transmit message) — ⚠ là HÀNH ĐỘNG truyền, không phải phương tiện.

  • A (Host) — ⚠ không phải thành phần của mô hình truyền thông.

Ghi nhớ

⚠ Nhiễu — noise — có thể xen vào ở mọi khâu: | Loại nhiễu | Ví dụ | |---|---| | ⚠ Nhiễu vật lý | ⚠ mạng chập chờn, tiếng ồn xung quanh | | ⚠ Nhiễu ngữ nghĩa | ⚠ dùng từ chuyên môn người nghe không hiểu | | ⚠ Nhiễu tâm lý | ⚠ định kiến, cảm xúc, mệt mỏi | | ⚠ Nhiễu văn hoá | ⚠ khác biệt về cách diễn đạt và lễ nghi | | ⚠ Vai trò của người gửi | ⚠ chọn medium và cách mã hoá để GIẢM nhiễu |

⚠ Chọn phương tiện cho phù hợp: | Tình huống | Phương tiện | |---|---| | ⚠ Vấn đề nhạy cảm, cần đọc phản ứng | ⚠ gặp trực tiếp | | ⚠ Cần thảo luận nhanh | ⚠ gọi điện hoặc họp trực tuyến | | ⚠ Cần lưu vết chính thức | ⚠ email hoặc văn bản | | ⚠ Thông tin tham khảo, ai cần thì lấy | ⚠ wiki, kho tài liệu | | ⚠ Nguyên tắc | ⚠ tin xấu và tin nhạy cảm thì gặp trực tiếp |

Từ khoá nhận diện:

"kênh mang thông điệp" → ⚠ medium "chuyển ý thành lời" → ⚠ encode "xác nhận đã nhận" → ⚠ acknowledge "phản hồi về nội dung" → ⚠ feedback

⚠ Ba phương pháp truyền thông Phương pháp
⚠ Interactive ⚠ hai chiều thời gian thực — họp trực tuyến thuộc nhóm này
⚠ Push ⚠ gửi đi — email, báo cáo, bản tin
⚠ Pull ⚠ người nhận tự lấy — wiki, cổng thông tin
⚠ Vì sao acknowledge khác feedback Khác
⚠ Acknowledge ⚠ "tôi đã nhận được"
⚠ Feedback ⚠ "tôi hiểu và đây là ý kiến của tôi"
⚠ Nhận được ⚠ KHÔNG có nghĩa là đã hiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phương tiện có phù hợp với nội dung không | ⚠ tin xấu không nên gửi qua email | | Có nhiễu nào đang cản trở không | | | Người nhận có phản hồi cho thấy đã hiểu không | |

Và khác biệt then chốt giữa "đã gửi" và "đã truyền đạt được": phản hồi. Chừng nào người nhận chưa nói lại được nội dung theo cách của họ, bạn chưa có bằng chứng nào rằng thông điệp đã tới nơi.

Câu 46
Beth is a project manager in her organization and she’s working with her project sponsor to define the levels of risk in a new project. Beth wants to discuss the project resilience and the unknowable-unknowns in the project. These risk events can only be recognized after they have occurred in the project. What term is best assigned to these type of risk events that attack project resilience?
  1. A Emergent risk
  2. B Apparent risk
  3. C Uncertain risk
  4. D Negative risk
Xem giải thích

Đáp án

A — Emergent risk (rủi ro nổi lên).

Vì sao đúng

⚠ Emergent risk — còn gọi là unknowable-unknowns: | Đặc điểm | Nội dung | |---|---| | ⚠ KHÔNG thể nhận diện trước | ⚠ khác với known-unknowns | | ⚠ Chỉ nhận ra SAU KHI đã xảy ra | | | ⚠ Tấn công khả năng PHỤC HỒI của dự án | ⚠ project resilience | | ⚠ Không lập được kế hoạch ứng phó cụ thể | |

⚠ Cách đối phó không phải là dự đoán, mà là XÂY KHẢ NĂNG PHỤC HỒI: | Biện pháp | Nội dung | |---|---| | ⚠ Dự trữ ngân sách và thời gian phù hợp | ⚠ management reserve | | ⚠ Quy trình linh hoạt, thích ứng nhanh | | | ⚠ Đội có năng lực rộng | ⚠ generalized specialists | | ⚠ Trao quyền cho đội tự xử lý | | | ⚠ Rà soát thường xuyên để phát hiện sớm | |

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

  • D (negative risk) — ⚠ phân loại theo TÁC ĐỘNG là tốt hay xấu, không phải theo khả năng nhận diện.

  • B (apparent risk) và C (uncertain risk) — ⚠ không phải thuật ngữ chuẩn trong PMBOK.

Ghi nhớ

⚠ Ba mức độ hiểu biết về rủi ro: | Mức | Nội dung | Ứng phó | |---|---|---| | ⚠ Known-knowns | ⚠ đã biết chắc — không còn là rủi ro | ⚠ đưa vào kế hoạch | | ⚠ Known-unknowns | ⚠ biết CÓ THỂ xảy ra, không biết có xảy ra không | ⚠ contingency reserve | | ⚠ Unknown-unknowns | ⚠ không biết mình chưa biết gì | ⚠ management reserve, khả năng phục hồi |

⚠ Project resilience — khả năng phục hồi: | Yếu tố | Nội dung | |---|---| | ⚠ Dự trữ đủ | ⚠ thời gian và ngân sách | | ⚠ Quy trình linh hoạt | ⚠ đổi hướng được nhanh | | ⚠ Đội có năng lực đa dạng | | | ⚠ Trao quyền cho người gần vấn đề nhất | | | ⚠ Phát hiện sớm | ⚠ rà soát và giám sát thường xuyên |

Từ khoá nhận diện:

"chỉ nhận ra sau khi xảy ra" → ⚠ emergent risk "biết có thể xảy ra" → ⚠ known-unknown, dùng contingency reserve "dao động quanh giá trị dự kiến" → ⚠ variability risk "không biết chuyện gì có thể xảy ra" → ⚠ ambiguity risk

⚠ Hai loại dự trữ — phân biệt lần nữa Loại
⚠ Contingency reserve ⚠ cho rủi ro ĐÃ BIẾT; nằm TRONG cost baseline; PM tự dùng
⚠ Management reserve ⚠ cho rủi ro CHƯA BIẾT; NGOÀI cost baseline; cần phê duyệt
⚠ Emergent risk ⚠ thuộc nhóm dùng management reserve
⚠ Vì sao khái niệm này ngày càng quan trọng Lý do
⚠ Môi trường kinh doanh biến động nhanh
⚠ Không thể liệt kê hết mọi rủi ro
⚠ Đại dịch, đứt gãy chuỗi cung ứng là ví dụ điển hình
⚠ Xu hướng ⚠ chuyển từ "dự đoán mọi rủi ro" sang "xây khả năng chịu đựng"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có management reserve không và bao nhiêu | | | Dự án có thể đổi hướng nhanh không | | | Đội có đủ năng lực đa dạng để ứng phó bất ngờ không | |

Và sự thay đổi tư duy quan trọng nhất trong quản lý rủi ro hiện đại: không cố dự đoán mọi thứ, mà xây năng lực chịu đựng những thứ không dự đoán được. Danh sách rủi ro dù dài đến đâu cũng không bao giờ đầy đủ.

Câu 47
You are preparing the risk management plan according to the PMBOK Guide, sixth edition. One of the inputs for the process includes the project management plan and all its components. You also know that you should identify risks as early as possible in the project and not all the project management plan is complete. What should you do?
  1. A Complete the risk management plan first, then create the project management plan
  2. B Complete all the project management plan before completing the risk management plan
  3. C Risk management planning is an iterative activity, so this is fine and expected
  4. D Use a project template for the risk management plan and update it as needed in the approach
Xem giải thích

Đáp án

C — Lập kế hoạch quản lý rủi ro là hoạt động LẶP LẠI, nên điều này là bình thường và đúng như mong đợi.

Vì sao đúng

⚠ Bản chất lặp của lập kế hoạch dự án: | Nguyên tắc | Nội dung | |---|---| | ⚠ Các quy trình lập kế hoạch ẢNH HƯỞNG LẪN NHAU | | | ⚠ Không có thứ tự tuyệt đối | ⚠ không phải làm xong cái này mới sang cái kia | | ⚠ Đầu ra của quy trình này là đầu vào của quy trình kia — và ngược lại | | | ⚠ Chi tiết hoá dần | ⚠ progressive elaboration | | ⚠ Với rủi ro | ⚠ nhận diện sớm là RẤT quan trọng — sớm thì rẻ và dễ xử lý hơn |

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

  • B (làm xong toàn bộ project management plan rồi mới làm kế hoạch rủi ro) — ⚠ quá muộn; ⚠ nhiều quyết định trong kế hoạch đã được đưa ra mà chưa xét rủi ro.

  • A (làm kế hoạch rủi ro trước rồi mới làm project management plan) — ⚠ cũng cứng nhắc theo chiều ngược lại.

  • D (dùng mẫu rồi cập nhật) — ⚠ dùng mẫu là thực hành TỐT, nhưng ⚠ không trả lời được câu hỏi về nguyên tắc.

Ghi nhớ

⚠ Vì sao nhận diện rủi ro SỚM lại quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Chi phí ứng phó THẤP hơn nhiều ở giai đoạn đầu | | | ⚠ Còn nhiều lựa chọn để né hoặc giảm nhẹ | | | ⚠ Ảnh hưởng tới cách lập lịch và ngân sách | | | ⚠ Có thể ảnh hưởng tới quyết định LÀM HAY KHÔNG | | | ⚠ Càng muộn | ⚠ càng ít lựa chọn và càng đắt |

⚠ Các quy trình lập kế hoạch ảnh hưởng lẫn nhau ra sao: | Ví dụ | Nội dung | |---|---| | ⚠ Rủi ro ảnh hưởng ước lượng thời gian | ⚠ thêm dự trữ | | ⚠ Ước lượng ảnh hưởng ngân sách | | | ⚠ Ngân sách hạn chế lại sinh ra rủi ro mới | | | ⚠ Phạm vi đổi thì rủi ro đổi theo | | | ⚠ Vì thế | ⚠ lập kế hoạch là VÒNG LẶP, không phải đường thẳng |

Từ khoá nhận diện:

"lặp lại, iterative" → ⚠ bản chất của lập kế hoạch dự án "chi tiết hoá dần" → ⚠ progressive elaboration "làm sớm, chi tiết sau" → ⚠ rolling wave planning "kế hoạch tổng gồm nhiều kế hoạch con" → ⚠ project management plan

⚠ Rolling wave planning Nội dung
⚠ Việc GẦN thì lập kế hoạch CHI TIẾT
⚠ Việc XA thì để ở mức cao
⚠ Chi tiết hoá dần khi tới gần
⚠ Phù hợp khi ⚠ môi trường nhiều bất định
⚠ Risk management plan gồm gì Nội dung
⚠ Chiến lược và phương pháp luận
⚠ Vai trò và trách nhiệm
⚠ Ngân sách và lịch cho hoạt động rủi ro
⚠ Phân loại rủi ro — RBS
⚠ Định nghĩa xác suất và tác động
⚠ Ma trận xác suất–tác động
⚠ Khẩu vị rủi ro của bên liên quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro đã bắt đầu nhận diện từ giai đoạn nào | ⚠ càng sớm càng tốt | | Kế hoạch có được cập nhật khi thông tin mới xuất hiện không | | | Ngưỡng xác suất và tác động đã định nghĩa rõ chưa | |

Và điều dễ hiểu nhầm nhất về các quy trình trong PMBOK: chúng được TRÌNH BÀY theo thứ tự, nhưng không THỰC HIỆN theo thứ tự đó. Chờ hoàn tất mọi thứ trước khi bắt đầu quản lý rủi ro là cách chắc chắn để bắt đầu quá muộn.

Câu 48
Gary is a project manager in his organization and he’s working with management to discuss the risks within the project. Some of the risks, Gary reports, can actually be beneficial to the project and the project should try to take advantage of those opportunities. Marsha, the project sponsor, says that she thinks Gary is mistaken as it’s company policy that all risks are negative and should be avoided in the project. Which one of the following is the best answers in this scenario?
  1. A Marsha is correct as all risks are negative and should be avoided.
  2. B Marsha is correct because she is the project sponsor.
  3. C Gary is correct, as risk outcomes can be beneficial to the project costs.
  4. D Gary is correct, as risks can be positive or negative.
Xem giải thích

Đáp án

D — Gary đúng, vì rủi ro có thể TÍCH CỰC hoặc TIÊU CỰC.

Vì sao đúng

⚠ Định nghĩa rủi ro trong PMBOK: | Nội dung | Chi tiết | |---|---| | ⚠ Một sự kiện hoặc điều kiện KHÔNG CHẮC CHẮN | | | ⚠ Nếu xảy ra sẽ ảnh hưởng tới mục tiêu dự án | | | ⚠ Ảnh hưởng có thể TÍCH CỰC hoặc TIÊU CỰC | |

Loại Tên gọi Chiến lược ứng phó
⚠ Rủi ro tiêu cực ⚠ threat — mối đe doạ ⚠ Avoid, Transfer, Mitigate, Accept
⚠ Rủi ro tích cực ⚠ opportunity — cơ hội ⚠ Exploit, Share, Enhance, Accept

⚠ Ví dụ cơ hội: ⚠ nhà cung cấp mới ra thị trường với giá rẻ hơn; ⚠ công nghệ mới giúp rút ngắn thời gian; ⚠ đội học nhanh hơn dự kiến.

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

  • A (Marsha đúng vì mọi rủi ro đều tiêu cực) — ⚠ SAI về định nghĩa; ⚠ đây là quan niệm cũ, PMBOK đã bao gồm cơ hội từ lâu.

  • B (Marsha đúng vì bà ấy là nhà tài trợ) — ⚠ lập luận theo THẨM QUYỀN, không phải theo kiến thức; ⚠ chức vụ không làm cho một phát biểu sai trở thành đúng.

  • C (Gary đúng vì kết quả rủi ro có lợi cho CHI PHÍ) — ⚠ thu hẹp quá mức; ⚠ cơ hội ảnh hưởng tới mọi mục tiêu: phạm vi, thời gian, chi phí, chất lượng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25533 trong lô này về EMV — ⚠ rủi ro tiêu cực cho EMV ÂM, cơ hội cho EMV DƯƠNG. ⚠ Hai câu cùng dựa trên nguyên tắc rủi ro có hai chiều.

⚠ Bốn chiến lược cho MỐI ĐE DOẠ: | Chiến lược | Nội dung | |---|---| | ⚠ Avoid | ⚠ loại bỏ nguyên nhân — đổi kế hoạch để rủi ro không còn | | ⚠ Transfer | ⚠ chuyển cho bên khác — bảo hiểm, hợp đồng fixed price | | ⚠ Mitigate | ⚠ giảm xác suất hoặc tác động | | ⚠ Accept | ⚠ chấp nhận — chủ động có dự phòng, hoặc bị động |

⚠ Bốn chiến lược cho CƠ HỘI — đối xứng: | Chiến lược | Nội dung | Đối ứng với | |---|---|---| | ⚠ Exploit | ⚠ bảo đảm cơ hội CHẮC CHẮN xảy ra | ⚠ Avoid | | ⚠ Share | ⚠ hợp tác với bên có khả năng nắm bắt tốt hơn | ⚠ Transfer | | ⚠ Enhance | ⚠ tăng xác suất hoặc tác động | ⚠ Mitigate | | ⚠ Accept | ⚠ không chủ động theo đuổi | ⚠ Accept |

⚠ Chiến lược thứ năm cho cả hai: ⚠ Escalate — ⚠ đẩy lên cấp cao hơn khi rủi ro nằm ngoài thẩm quyền của dự án.

Từ khoá nhận diện:

"rủi ro có thể tốt hoặc xấu" → ⚠ định nghĩa chuẩn của PMBOK "bảo đảm cơ hội xảy ra" → ⚠ exploit "loại bỏ mối đe doạ" → ⚠ avoid "ngoài thẩm quyền dự án" → ⚠ escalate

⚠ Cách xử lý tình huống này trong thực tế Cách
⚠ KHÔNG tranh cãi thắng thua với nhà tài trợ
⚠ Trình bày định nghĩa chuẩn kèm ví dụ cụ thể
⚠ Chỉ ra lợi ích kinh doanh của việc theo đuổi cơ hội
⚠ Mục tiêu ⚠ thay đổi chính sách, không phải chứng minh mình đúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ rủi ro có ghi cả cơ hội không | ⚠ hầu hết chỉ ghi mối đe doạ | | Có cơ hội nào đang bị bỏ lỡ không | | | Chính sách của tổ chức có cần cập nhật không | |

Và điều mà hầu hết sổ đăng ký rủi ro trong thực tế đều thiếu: phần cơ hội. Đội quen nghĩ rủi ro là chuyện xấu, nên những khả năng làm dự án tốt hơn không bao giờ được ghi lại và cũng không ai chủ động theo đuổi.

Câu 49
You are the project manager of the NLO Project for your organization. This project is an IT upgrade project which will replace data servers on your company’s network. As part of the requirements gathering process Mark, the CIO of your organization, is concerned about the nonfunctional requirements that must be addressed in the project. Anna is confused about nonfunctional requirements and how they relate to this project. Of the following, what is an example of a nonfunctional requirement Mark may be concerned with?
  1. A Processor size
  2. B Security of data
  3. C Web access to data
  4. D Data
Xem giải thích

Đáp án

B — Bảo mật dữ liệu (security of data).

Vì sao đúng

⚠ Phân biệt yêu cầu chức năng và phi chức năng: | Loại | Nội dung | Trả lời câu hỏi | |---|---|---| | ⚠ Functional | ⚠ hệ thống LÀM GÌ | ⚠ chức năng, hành vi, dữ liệu xử lý | | ⚠ Non-functional | ⚠ hệ thống làm việc đó NHƯ THẾ NÀO | ⚠ chất lượng, ràng buộc, đặc tính |

⚠ Các yêu cầu phi chức năng điển hình: | Nhóm | Ví dụ | |---|---| | ⚠ Bảo mật | ⚠ mã hoá, xác thực, phân quyền | | ⚠ Hiệu năng | ⚠ thời gian phản hồi, thông lượng | | ⚠ Khả dụng | ⚠ uptime, thời gian phục hồi | | ⚠ Khả năng mở rộng | | | ⚠ Khả năng bảo trì | | | ⚠ Tuân thủ | ⚠ quy định pháp lý | | ⚠ Khả năng sử dụng | ⚠ usability |

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

  • C (truy cập dữ liệu qua web) — ⚠ là yêu cầu CHỨC NĂNG; ⚠ nó mô tả hệ thống làm gì.

  • A (kích cỡ bộ xử lý) — ⚠ là một ĐẶC TẢ KỸ THUẬT hoặc ràng buộc, không phải yêu cầu phi chức năng theo cách phân loại chuẩn.

  • D (dữ liệu) — ⚠ quá mơ hồ, không phải một yêu cầu.

Ghi nhớ

⚠ Mẹo phân biệt nhanh: | Câu hỏi | Loại yêu cầu | |---|---| | ⚠ "Hệ thống PHẢI LÀM gì" | ⚠ functional | | ⚠ "Hệ thống phải làm việc đó TỐT ĐẾN MỨC NÀO" | ⚠ non-functional | | ⚠ Mẹo ngôn ngữ | ⚠ yêu cầu phi chức năng thường là DANH TỪ kết thúc bằng "-ility" hoặc "-ance" | | ⚠ Ví dụ | ⚠ security, reliability, scalability, usability, performance |

⚠ Năm nhóm yêu cầu trong PMBOK: | Nhóm | Nội dung | |---|---| | ⚠ Business requirements | ⚠ nhu cầu ở cấp tổ chức | | ⚠ Stakeholder requirements | ⚠ nhu cầu của từng bên | | ⚠ Solution requirements | ⚠ chia thành FUNCTIONAL và NON-FUNCTIONAL | | ⚠ Transition requirements | ⚠ để chuyển từ trạng thái cũ sang mới — đào tạo, di chuyển dữ liệu | | ⚠ Project requirements | ⚠ yêu cầu về cách thực hiện dự án | | ⚠ Quality requirements | ⚠ tiêu chí nghiệm thu chất lượng |

Từ khoá nhận diện:

"bảo mật, hiệu năng, khả dụng" → ⚠ non-functional "hệ thống cho phép người dùng làm X" → ⚠ functional "đào tạo, chuyển dữ liệu khi go-live" → ⚠ transition requirement "truy vết yêu cầu tới mục tiêu" → ⚠ requirements traceability matrix

⚠ Vì sao yêu cầu phi chức năng hay bị bỏ sót Lý do
⚠ Khách hàng thường chỉ nói về chức năng ⚠ "tôi muốn xem báo cáo"
⚠ Ít khi tự nói "báo cáo phải hiện trong 2 giây"
⚠ Nhưng chính chúng quyết định hệ thống có DÙNG ĐƯỢC không
⚠ Vai trò của PM và BA ⚠ chủ động HỎI về các đặc tính này
⚠ Hậu quả khi bỏ sót Hậu quả
⚠ Hệ thống đủ chức năng nhưng chậm tới mức không dùng được
⚠ Không đạt yêu cầu bảo mật khi kiểm toán
⚠ Phải làm lại kiến trúc — cực kỳ tốn kém
⚠ Vì thế ⚠ yêu cầu phi chức năng phải làm rõ TỪ ĐẦU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã hỏi về hiệu năng, bảo mật, khả dụng chưa | | | Các yêu cầu đó có ĐO ĐƯỢC không | ⚠ "nhanh" không phải yêu cầu, "dưới 2 giây" mới là | | Có tiêu chí nghiệm thu cho từng yêu cầu không | |

Và lý do yêu cầu phi chức năng thường gây ra những thất bại đắt nhất: chúng quyết định KIẾN TRÚC hệ thống. Phát hiện muộn rằng hệ thống cần chịu tải gấp mười lần thường có nghĩa là phải thiết kế lại từ đầu.

Câu 50
Your manager has asked you to create a RACI chart for your project. What does the C in RACI stand for?
  1. A Consider
  2. B Confirm
  3. C Conversation
  4. D Consult
Xem giải thích

Đáp án

D — Consult (tham vấn).

Vì sao đúng

⚠ Bốn chữ của RACI: | Chữ | Vai trò | Kiểu giao tiếp | |---|---|---| | ⚠ R — Responsible | ⚠ người LÀM | | | ⚠ A — Accountable | ⚠ người CHỊU TRÁCH NHIỆM cuối | ⚠ chỉ MỘT người | | ⚠ C — Consult | ⚠ người được HỎI Ý KIẾN | ⚠ HAI chiều, TRƯỚC khi làm | | ⚠ I — Inform | ⚠ người được THÔNG BÁO | ⚠ MỘT chiều, SAU khi làm |

⚠ Điểm phân biệt C và I: ⚠ C là hỏi ý kiến TRƯỚC và có đối thoại; ⚠ I chỉ là báo cho biết SAU khi đã xong.

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

  • A (Consider), B (Confirm), C (Conversation) — ⚠ đều bắt đầu bằng chữ C để gây nhiễu, nhưng ⚠ không phải nghĩa đúng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu THỨ BA về RACI trong hai lô gần nhau.

Câu Hỏi gì Khoá
⚠ #25529 ⚠ RACI viết tắt của gì ⚠ D — Responsible, Accountable, Consult, Inform
⚠ #25546 ⚠ hai người có cùng mang chữ A được không ⚠ C — chỉ MỘT người mang A
⚠ #25571 (câu này) ⚠ chữ C nghĩa là gì ⚠ D — Consult
⚠ Ba câu ⚠ nhất quán, cùng kiểm tra một khái niệm từ ba góc
⚠ Chữ cái ⚠ D, C, D — không theo quy luật nào

⚠ Quy tắc vàng của RACI: | Quy tắc | Nội dung | |---|---| | ⚠ Mỗi hoạt động ĐÚNG MỘT chữ A | | | ⚠ Ít nhất một chữ R | | | ⚠ Hạn chế số chữ C | ⚠ nhiều C làm quyết định chậm | | ⚠ Một người có thể vừa A vừa R | |

Từ khoá nhận diện:

"được hỏi ý kiến trước" → ⚠ Consult, hai chiều "chỉ được báo kết quả" → ⚠ Inform, một chiều "chịu trách nhiệm cuối cùng" → ⚠ Accountable "người làm việc" → ⚠ Responsible

⚠ Vì sao phân biệt C và I lại quan trọng Lý do
⚠ Chữ C phải được hỏi TRƯỚC khi quyết định ⚠ bỏ qua là gây mâu thuẫn
⚠ Chữ I chỉ cần biết SAU ⚠ không cần mời họp
⚠ Nhầm I thành C ⚠ họp đông không cần thiết, quyết định chậm
⚠ Nhầm C thành I ⚠ người có chuyên môn không được hỏi, quyết định sai
⚠ Biến thể của RACI Biến thể
⚠ RASCI ⚠ thêm S — Support
⚠ RACI-VS ⚠ thêm Verify và Sign-off
⚠ DACI ⚠ Driver, Approver, Contributor, Informed

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người mang chữ C có thật sự được hỏi trước không | | | Có ai đang là C mà lẽ ra chỉ cần I không | ⚠ làm chậm quyết định | | Mỗi hàng có đúng một chữ A không | |

Và khác biệt thực tế giữa C và I, thường bị coi nhẹ: chữ C phải được hỏi TRƯỚC khi quyết. Bỏ qua một người mang chữ C rồi mới thông báo là cách nhanh nhất tạo ra mâu thuẫn trong đội.