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

Tìm thấy 201 câu.

Câu 91
Victor is the project sponsor of the HK Project and he has cautioned Mary of overworking the project team to meet deadlines in the project. Mary is eager to meet the deadlines and feels that the time should work a little extra throughout the project to deliver as promised. What’s one of the key drawbacks of overworking the project team?
  1. A The project will likely experience rework
  2. B Duration estimates will be bloated to reduce actual work hours
  3. C Mary will need improved communication and emotional intelligence
  4. D The team will enjoy bonuses, but won’t enjoy the project work
Xem giải thích

Đáp án

A — Dự án sẽ nhiều khả năng phải LÀM LẠI.

Vì sao đúng

⚠ Hệ quả dây chuyền của việc bắt đội làm quá sức: | Bước | Nội dung | |---|---| | ⚠ Làm việc quá giờ kéo dài | | | ⚠ Mệt mỏi tích tụ | | | ⚠ Chất lượng công việc GIẢM | | | ⚠ Số LỖI tăng | | | ⚠ Phải LÀM LẠI | ⚠ rework | | ⚠ Kết quả nghịch lý | ⚠ làm nhiều giờ hơn nhưng tiến độ KHÔNG nhanh hơn, thậm chí chậm hơn |

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

  • B (ước lượng bị thổi phồng để giảm giờ làm thực) — ⚠ là một hành vi CÓ THẬT trong tổ chức ép tiến độ, nhưng ⚠ là hệ quả về lâu dài, không phải nhược điểm CHÍNH.

  • C (Mary cần cải thiện giao tiếp và trí tuệ cảm xúc) — ⚠ là nhận xét về NGƯỜI QUẢN LÝ, không phải nhược điểm với dự án.

  • D (đội thích thưởng nhưng không thích công việc) — ⚠ không phải nhược điểm được PMBOK nêu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25573 ở lô trước nêu nguyên tắc chất lượng được lập kế hoạch mà có, không phải kiểm tra mà có. ⚠ Câu này cho thấy hệ quả khi vi phạm nguyên tắc đó: ép tiến độ dẫn tới lỗi và làm lại.

⚠ Chi phí thật của việc làm quá sức: | Chi phí | Nội dung | |---|---| | ⚠ Làm lại | ⚠ chi phí trực tiếp rõ nhất | | ⚠ Lỗi lọt ra khách hàng | ⚠ external failure cost — đắt nhất | | ⚠ Kiệt sức và nghỉ việc | ⚠ mất tri thức, tốn chi phí tuyển và đào tạo | | ⚠ Tinh thần đội giảm | | | ⚠ Năng suất giảm ngay cả trong giờ làm bình thường | | | ⚠ Nghiên cứu cho thấy | ⚠ năng suất giảm rõ sau vài tuần làm thêm giờ liên tục |

Từ khoá nhận diện:

"làm quá sức" → ⚠ chất lượng giảm, phải làm lại "thêm người vào dự án đang chậm" → ⚠ thường làm nó chậm hơn "nén lịch bằng nguồn lực" → ⚠ crashing, tăng chi phí "nhịp làm việc bền vững" → ⚠ sustainable pace, nguyên tắc của cách tiếp cận linh hoạt

⚠ Cách xử lý đúng khi lịch căng Cách
⚠ Trình bày ĐÁNH ĐỔI với nhà tài trợ ⚠ phạm vi, thời gian, chi phí, chất lượng
⚠ Đàm phán giảm phạm vi hoặc dời hạn
⚠ Nén lịch có kiểm soát ⚠ crashing hoặc fast tracking, có tính rủi ro
⚠ Làm thêm giờ NGẮN HẠN có giới hạn ⚠ không phải giải pháp lâu dài
⚠ Đừng ⚠ coi làm thêm giờ là cách mặc định để bù tiến độ
⚠ "Sustainable pace" — nguyên tắc từ tuyên ngôn linh hoạt Nội dung
⚠ Đội nên duy trì nhịp làm việc VÔ THỜI HẠN được
⚠ Không dựa vào những đợt nước rút liên tục
⚠ Năng suất ổn định dễ dự báo hơn
⚠ Victor đúng ⚠ khi cảnh báo Mary về việc này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội đã làm thêm giờ liên tục bao lâu rồi | | | Tỷ lệ lỗi có tăng theo thời gian không | ⚠ dấu hiệu rõ nhất của mệt mỏi | | Đã trình bày đánh đổi với nhà tài trợ chưa | ⚠ thay vì âm thầm gánh |

Và nghịch lý mà mọi quản lý dự án cần hiểu: làm thêm giờ kéo dài thường khiến dự án chậm hơn. Số giờ tăng lên nhưng số việc hoàn thành đúng ngay lần đầu lại giảm — và phần chênh lệch đó quay trở lại dưới dạng công việc phải làm lại.

Câu 92
You are stopped in the hallway of your office and Gary, the CIO, wants a quick estimate for a small project. He promises he won’t hold you to the estimate, but needs a rough idea of what the cost of an implementation should be. You tell Gary the cost will likely be $250,000 but could be 25 percent less to 75 percent more, based on your limited information. What type of estimate have you provided Gary?
  1. A SWAG
  2. B Budget
  3. C ROM
  4. D Ad hoc
Xem giải thích

Đáp án

C — ROM (Rough Order of Magnitude — ước lượng thô).

Vì sao đúng

⚠ Dấu hiệu nhận ra ROM trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ Hỏi nhanh, không chuẩn bị | ⚠ "chặn bạn ở hành lang" | | ⚠ Thông tin RẤT ÍT | | | ⚠ Dải sai số RỘNG | ⚠ −25% đến +75% — đúng dải ROM của PMBOK | | ⚠ Không ràng buộc cam kết | ⚠ "sẽ không bắt bạn chịu trách nhiệm về con số này" | | ⚠ Dùng khi | ⚠ giai đoạn khởi tạo, chưa có phạm vi chi tiết |

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

  • B (Budget estimate) — ⚠ có dải hẹp hơn (⚠ khoảng −10% đến +25% ⚠ tuỳ tài liệu); ⚠ cần thông tin chi tiết hơn nhiều.

  • A (SWAG) — ⚠ là tiếng lóng, không phải thuật ngữ PMBOK; ⚠ đề hỏi "loại ước lượng nào" theo chuẩn.

  • D (Ad hoc) — ⚠ không phải một loại ước lượng chi phí trong PMBOK.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25606 ở lô này về definitive estimate — ⚠ đầu kia của thang độ chính xác. ⚠ Hai câu hợp lại thành cặp: ROM đầu dự án, definitive khi đã biết rõ.

⚠ Thang độ chính xác của ước lượng chi phí: | Loại | Dải sai số | Khi nào | |---|---|---| | ⚠ ROM — Rough Order of Magnitude | ⚠ −25% đến +75% | ⚠ khởi tạo, thông tin rất ít | | ⚠ Budget / Preliminary | ⚠ −10% đến +25% | ⚠ đã có phạm vi sơ bộ | | ⚠ Definitive | ⚠ −5% đến +10% | ⚠ đã có WBS chi tiết | | ⚠ Quy luật | ⚠ càng biết nhiều, dải càng hẹp |

Từ khoá nhận diện:

"con số thô, chưa cam kết" → ⚠ ROM "đã có WBS, ước lượng từng gói công việc" → ⚠ definitive "dải sai số thu hẹp dần theo thời gian" → ⚠ progressive elaboration / rolling wave

⚠ Bài học nghề khi bị hỏi ước lượng bất chợt Cách
⚠ LUÔN nói kèm DẢI SAI SỐ ⚠ đừng đưa một con số trần trụi
⚠ LUÔN nói rõ giả định ⚠ "dựa trên thông tin hạn chế hiện có"
⚠ Ghi lại bằng email sau đó ⚠ lời hứa "không bắt chịu trách nhiệm" thường bị quên
⚠ Vì sao quan trọng ⚠ con số thô rất hay biến thành ngân sách chính thức
⚠ "Cone of uncertainty" — hình nón bất định Nội dung
⚠ Đầu dự án: dải rộng nhất
⚠ Càng về sau dải càng hẹp
⚠ Ước lượng lại ở mỗi cột mốc
⚠ Sai lầm ⚠ giữ nguyên ước lượng ban đầu suốt dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng bạn vừa đưa thuộc loại nào | ⚠ và bên kia có hiểu đúng loại đó không | | Bạn đã nêu dải sai số chưa | | | Con số đó có bị dùng làm ngân sách không | ⚠ nếu có thì phải ước lượng lại chính thức |

Và bẫy quen thuộc trong nghề: con số nói ngoài hành lang rất hay xuất hiện trong bản trình bày ngân sách tuần sau. Nói kèm dải sai số và ghi lại bằng văn bản là cách tự bảo vệ.

Câu 93
You are the project manager of AGD Project, and your team comprises of a variety of specialists such as cost analysts, risk management experts, scheduling specialists, and other skilled workers. You are working with the project team to define project integration management processes for your project. Which of the following is an incorrect statement about the Project Integration Management knowledge area of your project?
  1. A The process of finalizing all activities for the project, phase or contract is a part of Project Integration Management.
  2. B You can delegate or transfer the accountability of Project Integration Management to one or more experts in your team.
  3. C Manage project knowledge is one of the processes under Project Integration Management.
  4. D You develop the project management plan as part of Project Integration Management.
Xem giải thích

Đáp án

B — "Bạn có thể uỷ thác hoặc chuyển giao TRÁCH NHIỆM GIẢI TRÌNH của Quản lý tích hợp dự án cho một hay nhiều chuyên gia trong đội." ⚠ Đây là phát biểu SAI.

Vì sao đúng

⚠ Nguyên tắc cốt lõi: | Điều | Nội dung | |---|---| | ⚠ CÔNG VIỆC thì uỷ thác được | ⚠ responsibility — ai làm | | ⚠ TRÁCH NHIỆM GIẢI TRÌNH thì KHÔNG | ⚠ accountability — ai chịu trách nhiệm cuối cùng | | ⚠ Tích hợp là việc RIÊNG của quản lý dự án | ⚠ PMBOK nói rõ điều này | | ⚠ Chỉ PM nhìn được TOÀN CẢNH dự án | ⚠ chuyên gia chỉ nhìn phần của mình | | ⚠ Vì sao không uỷ thác được | ⚠ tích hợp chính là công việc ghép các phần lại — không ai khác ở vị trí làm được |

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

  • A (kết thúc dự án, giai đoạn hoặc hợp đồng thuộc Integration) — ⚠ ĐÚNG: ⚠ Close Project or Phase là quy trình của nhóm kiến thức này.

  • C (Manage Project Knowledge thuộc Integration) — ⚠ ĐÚNG: ⚠ đây là quy trình được thêm vào PMBOK ấn bản 6.

  • D (lập kế hoạch quản lý dự án thuộc Integration) — ⚠ ĐÚNG: ⚠ Develop Project Management Plan là quy trình lõi của nhóm này.

Ghi nhớ

⚠ Bảy quy trình của Project Integration Management: | Quy trình | Nhóm | |---|---| | ⚠ Develop Project Charter | ⚠ Khởi tạo | | ⚠ Develop Project Management Plan | ⚠ Lập kế hoạch | | ⚠ Direct and Manage Project Work | ⚠ Thực hiện | | ⚠ Manage Project Knowledge | ⚠ Thực hiện | | ⚠ Monitor and Control Project Work | ⚠ Giám sát và kiểm soát | | ⚠ Perform Integrated Change Control | ⚠ Giám sát và kiểm soát | | ⚠ Close Project or Phase | ⚠ Kết thúc |

⚠ Responsibility và accountability khác nhau thế nào: | Khái niệm | Nghĩa | Uỷ thác được không | |---|---|---| | ⚠ Responsibility | ⚠ người LÀM việc | ⚠ CÓ | | ⚠ Accountability | ⚠ người CHỊU TRÁCH NHIỆM về kết quả | ⚠ KHÔNG | | ⚠ Trong RACI | ⚠ chỉ có MỘT chữ A cho mỗi công việc |

Từ khoá nhận diện:

"uỷ thác trách nhiệm giải trình" → ⚠ luôn SAI "chỉ PM nhìn thấy toàn cảnh" → ⚠ lý do tích hợp không uỷ thác được "phát biểu nào KHÔNG đúng" → ⚠ đọc kỹ, ba câu còn lại đều đúng

⚠ Vì sao chỉ PM làm được việc tích hợp Lý do
⚠ Chuyên gia chi phí chỉ tối ưu chi phí
⚠ Chuyên gia lịch chỉ tối ưu tiến độ
⚠ Chuyên gia rủi ro chỉ nhìn rủi ro
⚠ Ba mục tiêu đó XUNG ĐỘT nhau ⚠ phải có người cân bằng
⚠ Người đó là ⚠ quản lý dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang uỷ thác việc hay uỷ thác trách nhiệm | ⚠ chỉ cái đầu là hợp lệ | | Ai chịu trách nhiệm cuối cùng cho từng công việc | ⚠ phải là DUY NHẤT một người | | Có ai đang nhìn toàn cảnh dự án không | ⚠ nếu không, tích hợp đang bị bỏ trống |

Và một cách hiểu đơn giản: bạn giao việc được, nhưng khi dự án thất bại thì người ta vẫn tìm bạn. Đó chính là ý nghĩa của accountability, và là lý do câu B sai.

Câu 94
Rick is working on the Plan Scope Management process and has decided to use alternatives analysis as the data analysis technique in his project. Which of the following is not evaluated in this technique?
  1. A Various ways of controlling the scope
  2. B Various ways of validating the scope
  3. C Various ways of creating the product
  4. D Various ways of controlling change
Xem giải thích

Đáp án

D — Các cách kiểm soát THAY ĐỔI (controlling change).

Vì sao đúng

⚠ Alternatives analysis trong Plan Scope Management xét ba thứ: | Xét cái gì | Nội dung | |---|---| | ⚠ Các cách TẠO RA sản phẩm | ⚠ thu thập yêu cầu và xác định phạm vi thế nào | | ⚠ Các cách XÁC NHẬN phạm vi | ⚠ validating scope — nghiệm thu bàn giao ra sao | | ⚠ Các cách KIỂM SOÁT phạm vi | ⚠ controlling scope — theo dõi và xử lý sai lệch phạm vi | | ⚠ KHÔNG xét | ⚠ cách kiểm soát THAY ĐỔI | | ⚠ Vì sao không | ⚠ kiểm soát thay đổi thuộc Perform Integrated Change Control — nhóm kiến thức TÍCH HỢP, không phải phạm vi |

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

  • A (các cách kiểm soát phạm vi) — ⚠ CÓ được xét trong kỹ thuật này.

  • B (các cách xác nhận phạm vi) — ⚠ CÓ được xét.

  • C (các cách tạo ra sản phẩm) — ⚠ CÓ được xét.

Ghi nhớ

⚠ Phân biệt ba khái niệm rất dễ lẫn: | Khái niệm | Thuộc nhóm kiến thức | Việc | |---|---|---| | ⚠ Control Scope | ⚠ Scope Management | ⚠ theo dõi phạm vi, phát hiện scope creep | | ⚠ Validate Scope | ⚠ Scope Management | ⚠ KHÁCH HÀNG nghiệm thu bàn giao | | ⚠ Perform Integrated Change Control | ⚠ Integration Management | ⚠ xử lý MỌI yêu cầu thay đổi trên toàn dự án |

Từ khoá nhận diện:

"kiểm soát thay đổi" → ⚠ Integration, không phải Scope "khách hàng ký nhận bàn giao" → ⚠ Validate Scope "kiểm tra chất lượng bàn giao" → ⚠ Control Quality, làm TRƯỚC Validate Scope "phạm vi phình ra không ai duyệt" → ⚠ scope creep, bắt ở Control Scope

⚠ Sáu quy trình của Project Scope Management Nhóm
⚠ Plan Scope Management ⚠ Lập kế hoạch
⚠ Collect Requirements ⚠ Lập kế hoạch
⚠ Define Scope ⚠ Lập kế hoạch
⚠ Create WBS ⚠ Lập kế hoạch
⚠ Validate Scope ⚠ Giám sát và kiểm soát
⚠ Control Scope ⚠ Giám sát và kiểm soát
⚠ Alternatives analysis là gì Nội dung
⚠ Kỹ thuật phân tích dữ liệu
⚠ Liệt kê nhiều CÁCH LÀM rồi so sánh
⚠ Dùng ở rất nhiều quy trình khác nhau ⚠ không riêng gì phạm vi
⚠ Ở Plan Scope Management ⚠ so sánh cách thu thập yêu cầu, cách xác định, xác nhận và kiểm soát phạm vi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch quản lý phạm vi đã nói rõ cách xác nhận chưa | | | Đã nói rõ cách kiểm soát phạm vi chưa | | | Kiểm soát thay đổi có kế hoạch riêng chưa | ⚠ change management plan, thuộc tích hợp |

Và điểm cần khắc: phạm vi và thay đổi là hai chuyện khác nhau ở PMBOK. Phạm vi có kế hoạch riêng, thay đổi cũng có kế hoạch riêng — trộn hai cái là chỗ mất điểm quen thuộc trong kỳ thi.

Câu 95
As a project manager participating in the PMI certification program, you should be familiar with the PMI Talent Triangle and its components. Which one of the following is not part of the PMI Talent Triangle?
  1. A Strategic and business management
  2. B Quality management
  3. C Leadership
  4. D Technical project management
Xem giải thích

Đáp án

B — Quality management (quản lý chất lượng). ⚠ Đây KHÔNG phải một cạnh của tam giác.

Vì sao đúng

⚠ PMI Talent Triangle — ba cạnh: | Cạnh | Nội dung | |---|---| | ⚠ Technical Project Management | ⚠ kỹ năng chuyên môn quản lý dự án: lịch, chi phí, phạm vi, rủi ro | | ⚠ Leadership | ⚠ lãnh đạo: dẫn dắt, tạo động lực, đàm phán, giải quyết xung đột | | ⚠ Strategic and Business Management | ⚠ hiểu ngành nghề và chiến lược tổ chức, gắn dự án với giá trị kinh doanh | | ⚠ Quản lý chất lượng | ⚠ là một NHÓM KIẾN THỨC, không phải một cạnh của tam giác |

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

  • A (Strategic and business management) — ⚠ LÀ một cạnh.

  • C (Leadership) — ⚠ LÀ một cạnh.

  • D (Technical project management) — ⚠ LÀ một cạnh.

Ghi nhớ

⚠ Vì sao PMI dựng tam giác này: | Lý do | Nội dung | |---|---| | ⚠ Giỏi kỹ thuật thôi KHÔNG đủ | ⚠ PM giỏi lịch mà không dẫn dắt được đội thì dự án vẫn hỏng | | ⚠ Nhà tuyển dụng cần cả ba | ⚠ PMI khảo sát và thấy ba cạnh này quyết định hiệu quả | | ⚠ PDU phải rải đủ ba cạnh | ⚠ để duy trì chứng chỉ PMP | | ⚠ Yêu cầu PDU của PMP | ⚠ 60 PDU mỗi 3 năm, trong đó tối thiểu 8 PDU cho mỗi cạnh |

⚠ Phân bổ PDU tối thiểu theo cạnh Số
⚠ Ways of Working / Technical ⚠ tối thiểu 8 PDU
⚠ Power Skills / Leadership ⚠ tối thiểu 8 PDU
⚠ Business Acumen / Strategic ⚠ tối thiểu 8 PDU
⚠ Tổng cộng 60 PDU / 3 năm ⚠ tối đa 25 PDU từ "Giving Back"

Từ khoá nhận diện:

"ba cạnh tam giác tài năng" → ⚠ kỹ thuật, lãnh đạo, chiến lược kinh doanh "chất lượng, rủi ro, mua sắm, nhân sự" → ⚠ nhóm KIẾN THỨC, không phải cạnh tam giác "duy trì chứng chỉ" → ⚠ 60 PDU / 3 năm, đủ ba cạnh

⚠ Tên mới của ba cạnh — PMI đã đổi cách gọi Tên cũ
⚠ Ways of Working ⚠ Technical Project Management
⚠ Power Skills ⚠ Leadership
⚠ Business Acumen ⚠ Strategic and Business Management
⚠ Lưu ý khi thi ⚠ đề có thể dùng cả tên cũ lẫn tên mới — hiểu nội dung là được

Ghi nhớ về chất lượng câu hỏi: ⚠ Đề dùng bộ tên CŨ (Technical / Leadership / Strategic and business management). ⚠ PMI đã đổi sang Ways of Working / Power Skills / Business Acumen từ năm 2020. ⚠ Nội dung ba cạnh không đổi, chỉ đổi tên — nên KHÔNG sửa khoá đáp án, chỉ ghi chú để người học biết cả hai bộ tên.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang yếu cạnh nào nhất | ⚠ thường là cạnh chiến lược kinh doanh | | PDU của bạn có rải đủ ba cạnh không | ⚠ thiếu một cạnh là không gia hạn được | | Chu kỳ 3 năm của bạn còn bao lâu | |

Và ý nghĩa thật của tam giác này: PMI muốn nói rằng quản lý dự án không phải nghề của bảng Gantt. Hai trong ba cạnh nói về con người và về việc kinh doanh — chỉ một cạnh nói về kỹ thuật.

Câu 96
You are working with the project team to determine the cost of an activity in the project. The project team has provided a pessimistic, optimistic, and most likely estimate of costs for the activity. What type of estimate are you likely creating with the project team in this scenario?
  1. A Monte Carlo
  2. B Beta
  3. C Averaged
  4. D Constant
Xem giải thích

Đáp án

B — Beta (ước lượng ba điểm theo phân phối beta, tức PERT).

Vì sao đúng

⚠ Ước lượng ba điểm — three-point estimating: | Điểm | Ký hiệu | |---|---| | ⚠ Lạc quan | ⚠ O — optimistic | | ⚠ Khả dĩ nhất | ⚠ M — most likely | | ⚠ Bi quan | ⚠ P — pessimistic | | ⚠ Đề nêu ĐỦ CẢ BA | ⚠ dấu hiệu chắc chắn của kỹ thuật này |

⚠ Hai công thức: | Phân phối | Công thức | |---|---| | ⚠ Beta (PERT) | ⚠ (O + 4M + P) / 6 | | ⚠ Triangular | ⚠ (O + M + P) / 3 | | ⚠ Khác nhau ở | ⚠ beta cho "khả dĩ nhất" trọng số GẤP BỐN | | ⚠ Đề hỏi "loại ước lượng nào" | ⚠ beta là đáp án chuẩn khi không nói rõ gì thêm |

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

  • A (Monte Carlo) — ⚠ là mô phỏng chạy hàng nghìn kịch bản cho toàn bộ dự án; ⚠ đây là kỹ thuật phân tích rủi ro định lượng, ⚠ không phải cách ước lượng MỘT hoạt động.

  • C (Averaged) — ⚠ không phải thuật ngữ PMBOK; ⚠ trung bình cộng đơn thuần chính là công thức triangular chứ không có tên gọi này.

  • D (Constant) — ⚠ không phải một loại ước lượng.

Ghi nhớ

Từ khoá nhận diện:

"bi quan, lạc quan, khả dĩ nhất" → ⚠ ước lượng ba điểm, phân phối beta "chạy mô phỏng nghìn lần" → ⚠ Monte Carlo "dựa vào dự án tương tự đã làm" → ⚠ analogous — nhanh, kém chính xác "đơn giá × số lượng" → ⚠ parametric "cộng dồn từ từng gói công việc" → ⚠ bottom-up — chính xác nhất, tốn công nhất

⚠ Bốn kỹ thuật ước lượng chính Đặc điểm
⚠ Analogous ⚠ dựa vào dự án trước, nhanh nhất, kém chính xác nhất
⚠ Parametric ⚠ dựa vào quan hệ thống kê, ví dụ 1.200 đ/viên gạch
⚠ Three-point ⚠ tính đến bất định, cho ra dải
⚠ Bottom-up ⚠ cộng từ dưới lên, chính xác nhất
⚠ Độ lệch chuẩn và dải tin cậy trong PERT Công thức
⚠ Độ lệch chuẩn σ ⚠ (P − O) / 6
⚠ Phương sai ⚠ σ bình phương
⚠ Khoảng ±1σ ⚠ 68,27% tin cậy
⚠ Khoảng ±2σ ⚠ 95,45% tin cậy
⚠ Khoảng ±3σ ⚠ 99,73% tin cậy
⚠ Lưu ý ⚠ ±3σ hay bị nhầm với 6 sigma của quản lý chất lượng — hai chuyện khác nhau

⚠ Ví dụ tính nhanh: ⚠ O = 10, M = 15, P = 26 ⚠ → ⚠ beta = (10 + 60 + 26) / 6 = 96 / 6 = 16; ⚠ triangular = (10 + 15 + 26) / 3 = 51 / 3 = 17; ⚠ σ = (26 − 10) / 6 ≈ 2,67.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề cho đủ ba điểm chưa | ⚠ thiếu một điểm thì không phải three-point | | Đề nói beta hay triangular | ⚠ không nói gì thì dùng beta | | Hỏi giá trị kỳ vọng hay hỏi độ lệch chuẩn | ⚠ hai công thức khác nhau |

Và mẹo nhớ công thức: beta có số 4 và số 6, triangular có số 3. Ba điểm chia ba là trung bình cộng đơn giản; beta cho điểm giữa nặng gấp bốn vì đó là con số đội tin nhất.

Câu 97
John is the project manager for his organization, and he’s working with the project team to create a project cost estimate. John would like to purchase resources for his project from a specific vendor, The JH Goods Company, that he has worked with in the past. John knows that some other vendors may charge slightly less than the JH Goods Company, but he knows this vendor is reliable and does excellent work. What is the best term to describe John’s preference in this scenario?
  1. A Preferred vendor
  2. B Sole source
  3. C Single source
  4. D Oligopoly
Xem giải thích

Đáp án

C — Single source (một nguồn được chọn).

Vì sao đúng

⚠ Phân biệt hai thuật ngữ rất dễ lẫn: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Single source | ⚠ CÓ nhiều nhà cung cấp bán thứ này, nhưng ta CHỌN đúng một | | ⚠ Sole source | ⚠ CHỈ CÓ MỘT nhà cung cấp duy nhất trên thị trường bán được |

⚠ Đề nói gì: | Chi tiết trong đề | Suy ra | |---|---| | ⚠ "một số nhà cung cấp khác có thể rẻ hơn" | ⚠ → THỊ TRƯỜNG CÒN NGƯỜI BÁN KHÁC | | ⚠ "John muốn mua từ JH Goods" | ⚠ → đây là LỰA CHỌN của John, không phải bắt buộc | | ⚠ "đã làm việc trong quá khứ, tin cậy, làm tốt" | ⚠ → lý do ưu tiên | | ⚠ Kết luận | ⚠ có lựa chọn mà vẫn chọn một → single source |

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

  • B (Sole source) — ⚠ SAI vì đề nói rõ có nhà cung cấp khác; ⚠ sole source là khi không còn ai khác bán.

  • A (Preferred vendor) — ⚠ là cách nói thông thường trong doanh nghiệp, ⚠ không phải thuật ngữ PMBOK cho tình huống này.

  • D (Oligopoly) — ⚠ là khái niệm KINH TẾ: ⚠ thị trường do một nhóm ít người bán chi phối; ⚠ không mô tả lựa chọn của John.

Ghi nhớ

Từ khoá nhận diện:

"chỉ có một nơi bán được" → ⚠ sole source "có nhiều nơi nhưng ta chọn một" → ⚠ single source "vài người bán chi phối cả thị trường" → ⚠ oligopoly "chỉ một người mua" → ⚠ monopsony "một người bán duy nhất, không thay thế được" → ⚠ monopoly

⚠ Rủi ro của single source Rủi ro
⚠ Trả giá cao hơn thị trường ⚠ đề nói rõ có nơi rẻ hơn
⚠ Mất năng lực đàm phán ⚠ nhà cung cấp biết mình là lựa chọn duy nhất
⚠ Phụ thuộc: nhà cung cấp gặp sự cố là dự án đứng
⚠ Có thể vi phạm quy định mua sắm của tổ chức ⚠ nhiều nơi bắt buộc mời thầu cạnh tranh
⚠ Cách giảm ⚠ ghi lại lý do chọn bằng văn bản và có người phê duyệt
⚠ Khi nào single source là hợp lý Trường hợp
⚠ Chi phí chuyển đổi nhà cung cấp rất cao
⚠ Cần tính tương thích với thứ đã mua trước đó
⚠ Rủi ro chất lượng quan trọng hơn chênh lệch giá ⚠ lý do của John
⚠ Thời gian gấp, không kịp mời thầu
⚠ Luôn phải ⚠ ghi rõ lý do vào hồ sơ mua sắm
⚠ Bốn quy trình Project Procurement Management Nhóm
⚠ Plan Procurement Management ⚠ Lập kế hoạch
⚠ Conduct Procurements ⚠ Thực hiện
⚠ Control Procurements ⚠ Giám sát và kiểm soát
⚠ Lưu ý ⚠ PMBOK 6 đã bỏ quy trình Close Procurements riêng, gộp vào Control Procurements

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thị trường còn ai bán thứ này không | ⚠ quyết định single hay sole | | Lý do chọn đã ghi thành văn bản chưa | | | Quy định mua sắm của tổ chức có bắt mời thầu không | |

Và mẹo nhớ hai từ dễ lẫn nhất: sole = độc nhất (không còn ai khác), single = đơn lẻ (ta chỉ chọn một). Chữ "sole" trong tiếng Anh có nghĩa "duy nhất", còn "single" chỉ là "một".

Câu 98
You are the project manager of the NJL Project. This project is replacing several servers, workstations, routers, and other equipment in your IT configuration. As part of this project, you and the team have created a WBS Dictionary. All of the following items are part of the WBS Dictionary except for which one?
  1. A Quality requirements
  2. B Code of account identifier
  3. C Technical reference
  4. D Stakeholder requestor
Xem giải thích

Đáp án

D — Stakeholder requestor (người yêu cầu).

Vì sao đúng

⚠ Từ điển WBS — WBS Dictionary chứa gì: | Mục | Nội dung | |---|---| | ⚠ Mã định danh tài khoản | ⚠ code of account identifier — mã số của gói công việc | | ⚠ Mô tả công việc | | | ⚠ Giả định và ràng buộc | | | ⚠ Tổ chức chịu trách nhiệm | ⚠ ĐƠN VỊ nào làm, không phải người nào yêu cầu | | ⚠ Mốc lịch trình | | | ⚠ Hoạt động liên quan tới lịch | | | ⚠ Nguồn lực cần thiết | | | ⚠ Ước lượng chi phí | | | ⚠ Yêu cầu chất lượng | | | ⚠ Tiêu chí nghiệm thu | | | ⚠ Tham chiếu kỹ thuật | | | ⚠ Thông tin thoả thuận | ⚠ hợp đồng liên quan | | ⚠ KHÔNG có | ⚠ "người yêu cầu" — đó là thông tin của sổ đăng ký YÊU CẦU, không phải từ điển WBS |

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

  • A (Yêu cầu chất lượng) — ⚠ CÓ trong từ điển WBS.

  • B (Mã định danh tài khoản) — ⚠ CÓ, ⚠ chính là mục đầu tiên PMBOK liệt kê.

  • C (Tham chiếu kỹ thuật) — ⚠ CÓ.

Ghi nhớ

⚠ WBS và từ điển WBS — hai thứ đi kèm: | Thứ | Vai trò | |---|---| | ⚠ WBS | ⚠ cây phân rã: hình ảnh, chỉ có TÊN các gói công việc | | ⚠ WBS Dictionary | ⚠ văn bản đi kèm: CHI TIẾT từng gói công việc | | ⚠ Cả hai + scope baseline statement | ⚠ hợp thành SCOPE BASELINE |

Từ khoá nhận diện:

"đường cơ sở phạm vi gồm ba thứ" → ⚠ scope statement + WBS + WBS dictionary "ai yêu cầu tính năng này" → ⚠ requirements documentation / traceability matrix "mức thấp nhất của WBS" → ⚠ work package — gói công việc "nhóm gói công việc để theo dõi chi phí" → ⚠ control account

⚠ Quy tắc 100% của WBS Nội dung
⚠ WBS phải chứa 100% công việc của dự án
⚠ Không được thừa việc ngoài phạm vi
⚠ Tổng các nút con = đúng nút cha
⚠ Công việc không có trong WBS thì KHÔNG thuộc dự án ⚠ đây là công cụ chống scope creep mạnh nhất
⚠ Rule of 8/80 — hướng dẫn phân rã Nội dung
⚠ Gói công việc nên tốn từ 8 tới 80 giờ
⚠ Nhỏ hơn 8 giờ: phân rã quá vụn, tốn công quản lý
⚠ Lớn hơn 80 giờ: khó ước lượng và khó theo dõi
⚠ Đây là ⚠ hướng dẫn kinh nghiệm, không phải luật cứng của PMBOK

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi gói công việc có tiêu chí nghiệm thu chưa | ⚠ thiếu là cãi nhau lúc bàn giao | | Mã tài khoản có khớp với hệ thống kế toán không | | | Tổng công việc có đúng 100% phạm vi không | |

Và cách phân biệt gọn: từ điển WBS trả lời "gói công việc này LÀM GÌ và làm THẾ NÀO", còn "ai yêu cầu nó" thuộc về tài liệu yêu cầu và ma trận truy vết — hai tài liệu khác.

Câu 99
You are the project manager for your organization. Your current project has 18 stakeholders on the project that you have to work with each day. How many communication channels are in this project?
  1. A 18
  2. B 342
  3. C 171
  4. D 1
Xem giải thích

Đáp án

C — 171 kênh giao tiếp.

Vì sao đúng

⚠ Công thức số kênh giao tiếp: | Bước | Nội dung | |---|---| | ⚠ Công thức | ⚠ n × (n − 1) / 2 | | ⚠ n là TỔNG SỐ NGƯỜI, ⚠ kể cả chính quản lý dự án | | | ⚠ Đề nói 18 bên liên quan mà BẠN phải làm việc cùng | ⚠ → 18 người đó + chính bạn = 19 | | ⚠ 19 × 18 | ⚠ = 342 | | ⚠ 342 / 2 | ⚠ = 171 |

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

  • B (342) — ⚠ là kết quả QUÊN CHIA CHO 2; ⚠ đây là bẫy phổ biến nhất của dạng câu này.

  • A (18) — ⚠ là số người, không phải số kênh.

  • D (1) — ⚠ không có cơ sở tính toán nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25561 ở lô trước cũng tính kênh giao tiếp nhưng hỏi SỐ KÊNH TĂNG THÊM khi đội lớn lên. ⚠ Cùng công thức, khác cách hỏi — đọc kỹ đề hỏi tổng số hay số tăng thêm.

⚠ Bảng tra nhanh số kênh: | Số người | Số kênh | |---|---| | ⚠ 5 | ⚠ 10 | | ⚠ 10 | ⚠ 45 | | ⚠ 15 | ⚠ 105 | | ⚠ 19 | ⚠ 171 | | ⚠ 20 | ⚠ 190 | | ⚠ 30 | ⚠ 435 | | ⚠ Nhận xét | ⚠ số người tăng gấp đôi thì số kênh tăng gần GẤP BỐN |

Từ khoá nhận diện:

"bao nhiêu kênh giao tiếp" → ⚠ n(n−1)/2, nhớ CỘNG CHÍNH BẠN "tăng thêm bao nhiêu kênh" → ⚠ tính hai lần rồi TRỪ "đội lớn thì giao tiếp phức tạp" → ⚠ đây là lý do PMBOK dạy công thức này

Ghi nhớ về chất lượng câu hỏi: ⚠ Cách diễn đạt của đề có chỗ mơ hồ. ⚠ Nếu hiểu "18 bên liên quan" đã bao gồm cả quản lý dự án thì đáp số là ⚠ 18 × 17 / 2 = 153. ⚠ Nhưng 153 KHÔNG có trong danh sách phương án, ⚠ nên ý đồ của đề rõ ràng là ⚠ 18 người đó KHÔNG tính bạn, tổng là 19. ⚠ Giữ nguyên khoá đáp án C. ⚠ Bài học khi thi: ⚠ nếu kết quả của bạn không có trong phương án, hãy thử cộng hoặc trừ chính quản lý dự án rồi tính lại.

⚠ Vì sao PMI bắt học công thức này Lý do
⚠ Cho thấy độ phức tạp giao tiếp tăng theo BÌNH PHƯƠNG
⚠ Lý giải vì sao đội lớn cần cấu trúc giao tiếp ⚠ họp theo nhóm nhỏ, có người đại diện
⚠ Là lý do cần kế hoạch quản lý giao tiếp
⚠ Trong thực tế ⚠ đây là căn cứ để giới hạn quy mô đội, ví dụ đội Scrum 3–9 người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã cộng chính mình vào n chưa | ⚠ lỗi thường gặp nhất | | Bạn đã chia cho 2 chưa | ⚠ lỗi thường gặp thứ hai | | Đề hỏi tổng hay hỏi phần tăng thêm | |

Và mẹo kiểm tra nhanh: kết quả luôn nhỏ hơn n bình phương chia 2. Với 19 người, 19² / 2 ≈ 180, mà 171 nhỏ hơn một chút — hợp lý. Nếu ra 342 thì rõ ràng đã quên chia đôi.

Câu 100
Alice is the project manager for her organization and she is considering building a solution for her company. If she builds the solution it will cost the organization $650,000 to create and $17,300 per month to support. A vendor promises that they can build the solution for $120,000, but the monthly fee will be $21,400. What should Alice do?
  1. A Build the solution if the organization will use the solution for less than 18 months, but longer than 12 months.
  2. B Buy the solution if the organization will use the solution for less than 13 months, but more than 11 months.
  3. C Buy the solution.
  4. D Build the solution if the organization will use the solution for longer than 13 months, but less than 24 months.
Xem giải thích

Đáp án

C — Mua giải pháp (buy).

Vì sao đúng

⚠ Phân tích make-or-buy — tính điểm hoà vốn: | Phương án | Chi phí ban đầu | Chi phí hàng tháng | |---|---|---| | ⚠ Tự xây (build) | ⚠ 650.000 | ⚠ 17.300 | | ⚠ Mua (buy) | ⚠ 120.000 | ⚠ 21.400 | | ⚠ Chênh lệch ban đầu | ⚠ 650.000 − 120.000 = 530.000 — tự xây đắt hơn | | | ⚠ Chênh lệch hàng tháng | | ⚠ 21.400 − 17.300 = 4.100 — tự xây rẻ hơn |

⚠ Điểm hoà vốn: | Bước | Phép tính | |---|---| | ⚠ 530.000 / 4.100 | ⚠ ≈ 129,3 tháng | | ⚠ Đổi ra năm | ⚠ ≈ 10 năm 9 tháng | | ⚠ Kết luận | ⚠ chỉ khi dùng LÂU HƠN gần 11 năm thì tự xây mới rẻ hơn | | ⚠ Với mọi mốc thời gian hợp lý | ⚠ MUA là lựa chọn đúng |

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

  • A (xây nếu dùng dưới 18 tháng nhưng trên 12 tháng) — ⚠ SAI: ⚠ ở mốc 18 tháng, tự xây = 650.000 + 311.400 = 961.400, mua = 120.000 + 385.200 = 505.200; ⚠ mua rẻ hơn gần một nửa.

  • B (mua nếu dùng dưới 13 tháng nhưng trên 11 tháng) — ⚠ kết luận đúng nhưng ĐIỀU KIỆN sai: ⚠ mua rẻ hơn ở mọi mốc dưới 129 tháng, không riêng khoảng 11–13 tháng.

  • D (xây nếu dùng trên 13 tháng nhưng dưới 24 tháng) — ⚠ SAI: ⚠ ở mốc 24 tháng, tự xây = 650.000 + 415.200 = 1.065.200, mua = 120.000 + 513.600 = 633.600.

Ghi nhớ

⚠ Công thức điểm hoà vốn make-or-buy:

⚠ (Chi phí ban đầu A − Chi phí ban đầu B) / (Chi phí định kỳ B − Chi phí định kỳ A)

⚠ Cách làm dạng bài này trong 30 giây Bước
⚠ Bước 1: xem bên nào đắt hơn LÚC ĐẦU ⚠ ở đây là tự xây, đắt hơn 530.000
⚠ Bước 2: xem bên nào rẻ hơn HÀNG THÁNG ⚠ tự xây rẻ hơn 4.100/tháng
⚠ Bước 3: chia ⚠ 530.000 / 4.100 ≈ 129 tháng
⚠ Bước 4: so với thời gian sử dụng dự kiến

Từ khoá nhận diện:

"tự làm hay đi mua" → ⚠ make-or-buy analysis, tính điểm hoà vốn "chi phí ban đầu cao, phí định kỳ thấp" → ⚠ có lợi khi dùng LÂU DÀI "chi phí ban đầu thấp, phí định kỳ cao" → ⚠ có lợi khi dùng NGẮN HẠN

⚠ Yếu tố PHI TÀI CHÍNH cũng phải cân nhắc Yếu tố
⚠ Năng lực nội bộ có làm nổi không
⚠ Đây có phải năng lực cốt lõi cần giữ trong nhà không
⚠ Rủi ro phụ thuộc nhà cung cấp
⚠ Thời gian đưa ra thị trường ⚠ mua thường nhanh hơn
⚠ Bảo mật và quyền sở hữu trí tuệ
⚠ Đề này ⚠ chỉ cho dữ liệu tài chính nên chỉ so tiền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức dự kiến dùng giải pháp bao lâu | ⚠ so với 129 tháng | | Đã tính chi phí bảo trì nội bộ chưa | ⚠ tự xây còn tốn người vận hành | | Có yếu tố phi tài chính nào lấn át không | |

Và điểm cần khắc: 129 tháng là hơn mười năm — hiếm giải pháp phần mềm nào sống lâu như vậy mà không phải làm lại. Chính vì thế đáp án là mua, không kèm điều kiện gì.