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

Tìm thấy 201 câu.

Câu 191
Jeffrey is the project manager of the OPO Project for his organization and a portion of his project will be contracted with a vendor. Kelly, the project sponsor of the OPO Project, tells Jeffrey to utilize a screening system for the vendors to help sort out unqualified vendors. Which one of the following is the best example of a screening system?
  1. A Vendors must be licensed and bonded in the US state where the work will take place
  2. B Vendors must attend the bidders’ conference
  3. C Bids must accompany a detailed proposal with timeline
  4. D Bids must be under $250,000
Xem giải thích

Đáp án

A — Nhà cung cấp phải CÓ GIẤY PHÉP và CÓ BẢO LÃNH tại bang nơi công việc diễn ra.

Vì sao đúng

⚠ Screening system — hệ thống sàng lọc là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Là NGƯỠNG TỐI THIỂU phải đạt | ⚠ đạt thì được xét tiếp, không đạt thì LOẠI ngay | | ⚠ Câu trả lời là CÓ hoặc KHÔNG | ⚠ không chấm điểm, không so sánh | | ⚠ Mục đích: loại nhà cung cấp KHÔNG ĐỦ ĐIỀU KIỆN | ⚠ đúng chữ "sort out unqualified vendors" trong đề | | ⚠ Áp dụng TRƯỚC khi chấm điểm chi tiết | ⚠ tiết kiệm công sức đánh giá | | ⚠ Ví dụ điển hình | ⚠ giấy phép hành nghề, chứng chỉ, bảo hiểm, bảo lãnh, năng lực tài chính tối thiểu |

⚠ Vì sao phương án A là ví dụ chuẩn: | Lý do | Nội dung | |---|---| | ⚠ Là điều kiện PHÁP LÝ, có hoặc không | | | ⚠ Không có giấy phép thì KHÔNG THỂ làm việc hợp pháp | | | ⚠ Loại được ngay mà không cần đọc hồ sơ | |

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

  • C (hồ sơ phải kèm đề xuất chi tiết có tiến độ) — ⚠ là YÊU CẦU VỀ HÌNH THỨC hồ sơ, ⚠ không sàng lọc năng lực nhà cung cấp.

  • D (giá thầu phải dưới 250.000) — ⚠ là RÀNG BUỘC NGÂN SÁCH, ⚠ liên quan tới giá chứ không tới việc nhà cung cấp có đủ tư cách hay không; ⚠ đây là phương án gây nhiễu vì nó cũng "loại" được một số hồ sơ.

  • B (phải dự hội nghị nhà thầu) — ⚠ là yêu cầu THỦ TỤC; ⚠ vắng mặt không có nghĩa là không đủ năng lực.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25677 ở lô 178 về IFB và SOW và câu #25679 về hội nghị nhà thầu. ⚠ Ba câu là ba bước liên tiếp của Conduct Procurements.

⚠ Ba hệ thống đánh giá nhà cung cấp — phân biệt cho chắc: | Hệ thống | Cách hoạt động | |---|---| | ⚠ Screening system | ⚠ NGƯỠNG tối thiểu: đạt/không đạt — CÂU NÀY | | ⚠ Weighting system | ⚠ CHẤM ĐIỂM nhiều tiêu chí có TRỌNG SỐ, chọn điểm cao nhất | | ⚠ Seller rating system | ⚠ dữ liệu hiệu suất QUÁ KHỨ của nhà cung cấp | | ⚠ Dùng phối hợp | ⚠ sàng lọc TRƯỚC để loại bớt, rồi mới chấm điểm những hồ sơ còn lại |

Từ khoá nhận diện:

"loại nhà cung cấp không đủ điều kiện" → ⚠ screening system "chấm điểm theo trọng số" → ⚠ weighting system "lịch sử hiệu suất của nhà cung cấp" → ⚠ seller rating system "tiêu chí đạt/không đạt" → ⚠ sàng lọc "tiêu chí so sánh nhiều mức" → ⚠ chấm điểm

⚠ Ví dụ tiêu chí SÀNG LỌC điển hình Tiêu chí
⚠ Có giấy phép hành nghề hợp lệ
⚠ Có bảo hiểm trách nhiệm ở mức tối thiểu
⚠ Có chứng chỉ bắt buộc của ngành ⚠ ISO, an toàn lao động
⚠ Kinh nghiệm tối thiểu N năm hoặc N dự án tương tự
⚠ Năng lực tài chính tối thiểu
⚠ Không nằm trong danh sách bị cấm
⚠ Vì sao sàng lọc trước lại quan trọng Lý do
⚠ Tiết kiệm công sức đánh giá chi tiết ⚠ 23 hồ sơ mà chỉ 8 đủ điều kiện thì chỉ chấm 8
⚠ Tránh chọn nhầm nhà cung cấp không đủ tư cách pháp lý
⚠ Bảo vệ tổ chức khỏi rủi ro pháp lý và tài chính
⚠ Minh bạch: tiêu chí rõ ràng, khách quan
⚠ Nguyên tắc quan trọng ⚠ tiêu chí sàng lọc phải công bố TRƯỚC trong tài liệu mời thầu, không được thêm sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiêu chí sàng lọc có khách quan và đo được không | ⚠ "có uy tín tốt" không phải tiêu chí sàng lọc được | | Tiêu chí đã được công bố trước chưa | ⚠ thêm sau là mở đường cho khiếu nại | | Tiêu chí có quá chặt tới mức không ai đạt không | |

Và ranh giới cần thuộc: sàng lọc trả lời "ai được phép tham gia", chấm điểm trả lời "ai tốt nhất trong số đó". Trộn hai việc lại là vừa mất công vừa dễ bị khiếu nại.

Câu 192
You are a project manager for the IT Department in your organization and you’re working with the project team to define all the constraints and assumptions in your new project. You know that you should record all assumptions in an assumption log. What project management process creates the assumption log document?
  1. A Create the project management plan
  2. B Develop project charter
  3. C Define project scope
  4. D Identify risks
Xem giải thích

Đáp án

B — Develop Project Charter (phát triển điều lệ dự án).

Vì sao đúng

⚠ Assumption log — sổ đăng ký giả định: | Điều | Nội dung | |---|---| | ⚠ Được TẠO RA ở quy trình Develop Project Charter | ⚠ thuộc nhóm KHỞI TẠO | | ⚠ Ghi cả GIẢ ĐỊNH lẫn RÀNG BUỘC | | | ⚠ Ban đầu chứa giả định và ràng buộc ở MỨC CAO | ⚠ từ business case và điều lệ | | ⚠ Được CẬP NHẬT liên tục suốt vòng đời dự án | ⚠ khi phát hiện giả định mới ở mức chi tiết hơn | | ⚠ Vì sao ở đây | ⚠ ngay từ lúc lập điều lệ đã có giả định — về nguồn lực, về thị trường, về công nghệ |

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

  • A (Create the project management plan) — ⚠ quy trình này SỬ DỤNG và CẬP NHẬT assumption log, ⚠ nhưng không TẠO RA nó.

  • C (Define project scope) — ⚠ cũng cập nhật giả định, ⚠ và tuyên bố phạm vi cũng liệt kê giả định, ⚠ nhưng sổ đã tồn tại từ trước.

  • D (Identify risks) — ⚠ DÙNG assumption log làm đầu vào: ⚠ mỗi giả định không chắc chắn là một nguồn rủi ro; ⚠ nhưng không tạo ra nó.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25610 ở lô 177 về assumption log và câu #25637 ở lô 178 về phân biệt giả định với ràng buộc. ⚠ Ba câu là bộ hoàn chỉnh: cái gì là giả định, ghi ở đâu, và ai tạo ra chỗ ghi đó.

⚠ Bốn tài liệu được TẠO RA ở Develop Project Charter: | Đầu ra | Nội dung | |---|---| | ⚠ Project charter | ⚠ đầu ra chính | | ⚠ Assumption log | ⚠ đầu ra thứ hai — CÂU NÀY | | ⚠ Lưu ý | ⚠ PMBOK 6 chỉ liệt kê HAI đầu ra cho quy trình này — nhớ cả hai là đủ |

⚠ Vòng đời của một giả định: | Bước | Việc | |---|---| | ⚠ 1. GHI vào assumption log ngay khi phát hiện | | | ⚠ 2. KIỂM CHỨNG — nó có đúng không? | | | ⚠ 3. Nếu đúng: chuyển thành SỰ THẬT, gỡ khỏi danh sách rủi ro | | | ⚠ 4. Nếu chưa chắc: ghi thành RỦI RO trong risk register | | | ⚠ 5. Nếu sai: xử lý như một VẤN ĐỀ trong issue log | | | ⚠ Nguyên tắc | ⚠ giả định không được kiểm chứng là nguồn gốc của rất nhiều sự cố dự án |

Từ khoá nhận diện:

"tạo ra assumption log" → ⚠ Develop Project Charter "điều ta coi là đúng mà chưa kiểm chứng" → ⚠ giả định "giới hạn đã biết chắc" → ⚠ ràng buộc "giả định này sai thì sao" → ⚠ đó là một RỦI RO

⚠ Các "log" và "register" và nơi tạo ra chúng Tài liệu
⚠ Assumption log ⚠ Develop Project Charter
⚠ Stakeholder register ⚠ Identify Stakeholders
⚠ Risk register ⚠ Identify Risks
⚠ Issue log ⚠ Direct and Manage Project Work
⚠ Change log ⚠ Perform Integrated Change Control
⚠ Lessons learned register ⚠ Manage Project Knowledge
⚠ Mẹo thi ⚠ thuộc bảng này là trả lời được cả một nhóm câu hỏi "tài liệu X sinh ra ở đâu"
⚠ Vì sao giả định lại được ghi từ SỚM như vậy Lý do
⚠ Điều lệ được viết khi thông tin RẤT ÍT ⚠ nên đầy giả định
⚠ Giả định ở mức cao ảnh hưởng tới toàn bộ dự án ⚠ ví dụ "công nghệ X sẽ sẵn sàng vào quý sau"
⚠ Ghi sớm thì mới kiểm chứng sớm được
⚠ Nếu không ghi ⚠ giả định nằm ngầm trong đầu vài người, và không ai kiểm tra nó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có assumption log chưa | | | Mỗi giả định quan trọng đã được kiểm chứng chưa | | | Giả định chưa kiểm chứng có rủi ro tương ứng chưa | |

Và lý do PMBOK cho sổ này ra đời sớm nhất có thể: giả định sai phát hiện ở tuần đầu tốn vài giờ, phát hiện ở tháng thứ sáu tốn cả dự án.

Câu 193
You are a project manager for the BBB Project, and you’re working with Allen, a business analyst, to determine the problems and identify the business needs for the BBB Project. The project scope has been created, but there are some recent requests for additions to the project scope. The request for changes need to be tested and reviewed before being implemented. In this scenario, who is responsible for the requirement-related activities of the project scope considering the project has just started?
  1. A Project sponsor
  2. B Project customer
  3. C Allen, the business analyst
  4. D You, the project manager
Xem giải thích

Đáp án

C — Allen, nhà phân tích nghiệp vụ (business analyst).

Vì sao đúng

⚠ Vai trò của nhà phân tích nghiệp vụ: | Việc | Nội dung | |---|---| | ⚠ Xác định VẤN ĐỀ và NHU CẦU nghiệp vụ | ⚠ đúng điều Allen đang làm trong đề | | ⚠ THU THẬP và phân tích yêu cầu | | | ⚠ TÀI LIỆU HOÁ yêu cầu | | | ⚠ QUẢN LÝ yêu cầu và truy vết chúng | | | ⚠ Kiểm chứng và xác nhận yêu cầu | ⚠ đúng chữ "cần được kiểm thử và rà soát" trong đề | | ⚠ Kết luận | ⚠ mọi hoạt động LIÊN QUAN TỚI YÊU CẦU thuộc trách nhiệm của nhà phân tích nghiệp vụ khi vai trò này có trong dự án |

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

  • D (bạn — quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ PM chịu trách nhiệm ⚠ TỔNG THỂ dự án và ⚠ phê duyệt hoặc trình duyệt thay đổi, ⚠ nhưng khi có nhà phân tích nghiệp vụ thì ⚠ công việc VỀ YÊU CẦU thuộc về người đó.

  • A (nhà tài trợ) — ⚠ sở hữu business case và phê duyệt, ⚠ không làm công việc về yêu cầu.

  • B (khách hàng dự án) — ⚠ CUNG CẤP yêu cầu và NGHIỆM THU, ⚠ nhưng không chịu trách nhiệm phân tích và quản lý chúng.

Ghi nhớ

⚠ Ranh giới giữa quản lý dự án và phân tích nghiệp vụ: | Vai trò | Chịu trách nhiệm | |---|---| | ⚠ Project Manager | ⚠ phạm vi DỰ ÁN, lịch, chi phí, rủi ro, đội ngũ, giao tiếp — LÀM ĐÚNG dự án | | ⚠ Business Analyst | ⚠ phạm vi SẢN PHẨM, yêu cầu, phân tích nhu cầu — LÀM ĐÚNG SẢN PHẨM | | ⚠ Hai vai trò | ⚠ PHỐI HỢP chặt chẽ, không cạnh tranh nhau | | ⚠ Dự án nhỏ | ⚠ một người có thể kiêm cả hai vai |

⚠ Phân biệt hai loại phạm vi — nền tảng của câu này: | Loại | Nghĩa | Ai lo | |---|---|---| | ⚠ Product scope | ⚠ ĐẶC TÍNH và CHỨC NĂNG của sản phẩm | ⚠ business analyst | | ⚠ Project scope | ⚠ CÔNG VIỆC phải làm để tạo ra sản phẩm | ⚠ project manager | | ⚠ Đo bằng gì | ⚠ product scope đo bằng YÊU CẦU; project scope đo bằng KẾ HOẠCH quản lý dự án |

Từ khoá nhận diện:

"yêu cầu, nhu cầu nghiệp vụ, phân tích vấn đề" → ⚠ business analyst "lịch, chi phí, rủi ro, đội ngũ" → ⚠ project manager "phê duyệt và cấp nguồn lực" → ⚠ project sponsor "cung cấp yêu cầu và nghiệm thu" → ⚠ customer

⚠ Trong tình huống này ai làm gì Phân vai
⚠ Allen ⚠ phân tích ba yêu cầu mới, đánh giá tác động tới sản phẩm, kiểm chứng chúng
⚠ Bạn — PM ⚠ đưa yêu cầu thay đổi qua quy trình kiểm soát thay đổi, đánh giá tác động tới lịch và chi phí
⚠ Nhà tài trợ ⚠ phê duyệt hoặc từ chối thay đổi
⚠ Khách hàng ⚠ nêu yêu cầu và nghiệm thu kết quả
⚠ Kết luận ⚠ hai vai trò bổ sung nhau: Allen lo NỘI DUNG yêu cầu, bạn lo QUY TRÌNH thay đổi
⚠ Vì sao PMI tách riêng vai trò này Lý do
⚠ Phân tích nghiệp vụ là một chuyên môn riêng ⚠ PMI có chứng chỉ PMI-PBA riêng
⚠ Yêu cầu sai là nguyên nhân hàng đầu khiến dự án thất bại
⚠ PM thường không đủ thời gian làm sâu phần yêu cầu
⚠ Hai vai trò cần kỹ năng khác nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có nhà phân tích nghiệp vụ không | ⚠ nếu không thì PM phải kiêm | | Ranh giới trách nhiệm giữa PM và BA đã rõ chưa | ⚠ mơ hồ là nguồn xung đột | | Yêu cầu mới có được phân tích trước khi trình duyệt không | |

Và cách tóm gọn ranh giới: nhà phân tích nghiệp vụ đảm bảo ta làm ĐÚNG SẢN PHẨM, quản lý dự án đảm bảo ta làm sản phẩm ĐÚNG CÁCH. Thiếu vế nào cũng dẫn tới thất bại, chỉ là thất bại theo hai kiểu khác nhau.

Câu 194
You are the project manager of the GGG Project for your organization and are leading a recently chartered project that will affect much of the organization. You’re about to meet with the project team and several key stakeholders to complete stakeholder identification. Because of the size of the project you want the meeting participants to come prepared with a list of stakeholders prior to stakeholder identification meeting. What’s the best approach to this scenario?
  1. A Have the participants complete brainwriting before the stakeholder identification meeting
  2. B Have the team investigate potential stakeholders before the meeting
  3. C Complete stakeholder identification on your own and then compare your results to the meeting outcomes
  4. D Create a web survey and distribute it to the entire company to gauge who is, and who is not, a stakeholder
Xem giải thích

Đáp án

A — Cho những người tham dự thực hiện BRAINWRITING trước buổi họp nhận diện bên liên quan.

Vì sao đúng

⚠ Brainwriting là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Là biến thể của brainstorming | | | ⚠ Người tham gia VIẾT ý tưởng RIÊNG TRƯỚC | ⚠ trước khi vào thảo luận nhóm | | ⚠ Sau đó mới gộp lại và bàn chung | | | ⚠ Đúng điều đề yêu cầu | ⚠ "đến họp với một danh sách đã chuẩn bị sẵn" | | ⚠ Lợi ích | ⚠ mỗi người có thời gian suy nghĩ độc lập, không bị chi phối bởi ý kiến người nói trước |

⚠ Vì sao phù hợp với dự án LỚN: | Lý do | Nội dung | |---|---| | ⚠ Dự án ảnh hưởng phần lớn tổ chức | ⚠ rất nhiều bên liên quan tiềm năng | | ⚠ Nhiều góc nhìn khác nhau cùng đóng góp | | | ⚠ Buổi họp hiệu quả hơn vì đã có danh sách sẵn | | | ⚠ Giảm hiện tượng "neo" vào ý kiến đầu tiên | ⚠ anchoring bias |

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

  • B (bảo đội tìm hiểu trước buổi họp) — ⚠ mơ hồ, không phải một kỹ thuật có tên; ⚠ đề hỏi "cách tiếp cận TỐT NHẤT" nên phải chọn kỹ thuật cụ thể.

  • C (bạn tự làm rồi so sánh với kết quả họp) — ⚠ lãng phí và dễ tạo thiên kiến: ⚠ danh sách của bạn sẽ vô tình trở thành chuẩn để đối chiếu.

  • D (khảo sát web gửi toàn công ty) — ⚠ quá rộng và kém hiệu quả; ⚠ đề nói rõ người tham dự là ⚠ đội dự án và một số bên liên quan CHỦ CHỐT, ⚠ không phải toàn công ty.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25584 ở lô 177 về brainwriting và câu #25676 ở lô này về kỹ thuật Delphi. ⚠ Ba câu cùng chủ đề kỹ thuật thu thập ý kiến nhóm — bảng so sánh dưới đây phân biệt cả ba.

⚠ So sánh các kỹ thuật thu thập ý kiến: | Kỹ thuật | Cách làm | Mạnh nhất khi | |---|---|---| | ⚠ Brainstorming | ⚠ nói to ý tưởng trong nhóm | ⚠ cần nhiều ý tưởng nhanh, nhóm cởi mở | | ⚠ Brainwriting | ⚠ VIẾT riêng trước rồi mới bàn chung | ⚠ muốn mọi người suy nghĩ độc lập — CÂU NÀY | | ⚠ Nominal group technique | ⚠ brainstorming + bỏ phiếu xếp hạng | ⚠ cần vừa sinh ý tưởng vừa ưu tiên hoá | | ⚠ Delphi | ⚠ ẨN DANH, nhiều vòng, chuyên gia | ⚠ vấn đề NHẠY CẢM, sợ chính trị nội bộ | | ⚠ Affinity diagram | ⚠ phân nhóm số lượng lớn ý tưởng | ⚠ SAU khi đã có nhiều ý tưởng rời rạc |

Từ khoá nhận diện:

"chuẩn bị danh sách riêng trước khi họp" → ⚠ brainwriting "ẩn danh, nhiều vòng, sợ trả đũa" → ⚠ Delphi "nói to trong nhóm" → ⚠ brainstorming "phân nhóm ý tưởng đã thu được" → ⚠ affinity diagram

⚠ Vì sao brainwriting hiệu quả hơn brainstorming thuần Lý do
⚠ Tránh "neo" vào ý kiến người nói đầu tiên
⚠ Người hướng nội cũng đóng góp được ⚠ brainstorming thường bị người nói nhiều chi phối
⚠ Không ai bị mất ý tưởng vì chờ tới lượt nói
⚠ Nhiều ý tưởng hơn trong cùng thời gian
⚠ Nhược điểm ⚠ mất phần bồi đắp ý tưởng cho nhau theo thời gian thực — nên vẫn cần bàn chung sau đó
⚠ Sau khi có danh sách thì làm gì tiếp Bước
⚠ Gộp và loại trùng lặp
⚠ Phân loại bên liên quan ⚠ power/interest grid hoặc hướng ảnh hưởng
⚠ Ghi vào STAKEHOLDER REGISTER ⚠ xem câu #25699
⚠ Lập kế hoạch tham gia ⚠ xem câu #25704

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai vắng mặt trong buổi họp mà lẽ ra nên có mặt | | | Bạn có bỏ sót nhóm bên liên quan nào không | ⚠ dùng bốn hướng ảnh hưởng để rà | | Danh sách có được cập nhật suốt dự án không | ⚠ nhận diện bên liên quan là việc LIÊN TỤC |

Và lý do bước chuẩn bị này đáng giá: bên liên quan bị bỏ sót ở tuần đầu thường xuất hiện ở tháng thứ sáu, kèm theo một yêu cầu thay đổi lớn. Nửa giờ viết danh sách trước buổi họp là khoản đầu tư rẻ nhất của cả dự án.

Câu 195
Kelly is a project team for your project and she’s trying to predict how long her activity will take. You ask Kelly what’s the optimistic estimate, most likely duration, and the worst-case duration for the task. She considers the question and the reports that the best case is 45 hours, the most likely will be 60 hours, and the worst-case will be 90 hours. Using triangular distribution, what do you expect the duration of the task to be?
  1. A 65 hours
  2. B 45 hours
  3. C 105 hours
  4. D 90 hours
Xem giải thích

Đáp án

A — 65 giờ.

Vì sao đúng

⚠ Phân phối TAM GIÁC — công thức trung bình cộng đơn giản: | Bước | Phép tính | |---|---| | ⚠ Công thức | ⚠ (O + M + P) / 3 | | ⚠ O — lạc quan | ⚠ 45 giờ | | ⚠ M — khả dĩ nhất | ⚠ 60 giờ | | ⚠ P — bi quan | ⚠ 90 giờ | | ⚠ Tính | ⚠ (45 + 60 + 90) / 3 = 195 / 3 = 65 giờ |

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

  • B (45 giờ) — ⚠ là ước lượng LẠC QUAN, ⚠ chưa qua phép tính nào.

  • D (90 giờ) — ⚠ là ước lượng BI QUAN.

  • C (105 giờ) — ⚠ không khớp phép tính nào; ⚠ lớn hơn cả giá trị bi quan nên chắc chắn sai.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25617 ở lô 178 về phân phối BETA (PERT). ⚠ Hai câu là cặp đối chiếu trực tiếp: cùng dạng ước lượng ba điểm, khác công thức. Đề bài luôn nói rõ dùng phân phối nào — phải đọc kỹ.

⚠ Hai công thức ước lượng ba điểm: | Phân phối | Công thức | Ở bài này | |---|---|---| | ⚠ Triangular — TAM GIÁC | ⚠ (O + M + P) / 3 | ⚠ (45 + 60 + 90) / 3 = 65 | | ⚠ Beta — PERT | ⚠ (O + 4M + P) / 6 | ⚠ (45 + 240 + 90) / 6 = 375 / 6 = 62,5 | | ⚠ Khác nhau ở | ⚠ beta cho giá trị "khả dĩ nhất" trọng số GẤP BỐN | | ⚠ Vì thế | ⚠ beta luôn GẦN giá trị khả dĩ nhất hơn triangular |

⚠ Vì sao hai kết quả khác nhau ở bài này: | Điều | Nội dung | |---|---| | ⚠ Ước lượng bi quan (90) LỆCH XA hơn so với lạc quan (45) | ⚠ 60 − 45 = 15, còn 90 − 60 = 30 | | ⚠ Phân bố LỆCH PHẢI | | | ⚠ Triangular chịu ảnh hưởng nhiều hơn từ đuôi bi quan | ⚠ cho 65 | | ⚠ Beta kéo kết quả về gần giá trị khả dĩ nhất | ⚠ cho 62,5 | | ⚠ Bài học | ⚠ khi phân bố lệch, chọn công thức nào có ảnh hưởng thật tới con số |

Từ khoá nhận diện:

"phân phối tam giác" → ⚠ chia cho 3 "phân phối beta" hoặc "PERT" → ⚠ nhân 4 rồi chia cho 6 "đề không nói rõ phân phối nào" → ⚠ mặc định dùng BETA "độ lệch chuẩn" → ⚠ (P − O) / 6

⚠ Các phép tính khác của bộ số này Phép tính
⚠ Độ lệch chuẩn σ = (P − O) / 6 ⚠ (90 − 45) / 6 = 7,5 giờ
⚠ Phương sai = σ² ⚠ 56,25
⚠ Khoảng ±1σ quanh beta 62,5 ⚠ 55 → 70 giờ, 68,27% tin cậy
⚠ Khoảng ±2σ ⚠ 47,5 → 77,5 giờ, 95,45% tin cậy
⚠ Khoảng ±3σ ⚠ 40 → 85 giờ, 99,73% tin cậy
⚠ Vì sao ước lượng ba điểm tốt hơn một con số Lý do
⚠ Buộc người ước lượng nghĩ tới TÌNH HUỐNG XẤU
⚠ Cho ra DẢI chứ không phải điểm duy nhất
⚠ Độ lệch chuẩn cho biết mức BẤT ĐỊNH ⚠ σ lớn nghĩa là công việc khó đoán
⚠ Thay thế cho việc đệm ngầm ⚠ xem câu #25669 về định luật Parkinson
⚠ Chi phí ⚠ tốn thời gian gấp ba — chỉ dùng cho hoạt động quan trọng hoặc bất định cao

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề nói phân phối nào | ⚠ tam giác chia 3, beta chia 6 | | Kết quả có nằm giữa O và P không | ⚠ ngoài khoảng đó là chắc chắn sai | | Ba ước lượng có hợp lý không | ⚠ P quá gần M nghĩa là chưa nghĩ tới tình huống xấu thật sự |

Và mẹo kiểm tra nhanh nhất: kết quả phải nằm giữa 45 và 90. Phương án 105 vượt ra ngoài khoảng đó nên loại được ngay mà không cần tính.

Câu 196
Quincy is the project manager of the GHY Project and he’s working with the project team to build out the project cost estimates. One of the first resources Quincy recommends using is the project charter. The team doesn’t understand why the charter is needed at this point of the project since they are now clearly in planning activities. Why would Quincy need the project charter at this point?
  1. A The charter defines who has authority over project costs.
  2. B The charter defines the total costs of work packages for the project.
  3. C The charter defines who has budget approval.
  4. D The charter defines a summary budget for the project costs.
Xem giải thích

Đáp án

D — Điều lệ dự án chứa NGÂN SÁCH TÓM TẮT cho chi phí dự án.

Vì sao đúng

⚠ Vì sao điều lệ vẫn cần ở giai đoạn lập kế hoạch chi phí: | Lý do | Nội dung | |---|---| | ⚠ Điều lệ chứa "preapproved financial resources" | ⚠ nguồn lực tài chính đã được duyệt sơ bộ | | ⚠ Đó là NGÂN SÁCH TÓM TẮT ở mức cao | ⚠ thường là ước lượng ROM | | ⚠ Là ĐIỂM XUẤT PHÁT và RÀNG BUỘC cho ước lượng chi tiết | | | ⚠ Đội biết mình đang phải bám vào con số nào | | | ⚠ PMBOK liệt kê điều lệ | ⚠ là ĐẦU VÀO của quy trình Estimate Costs và Determine Budget |

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

  • A (điều lệ xác định AI có thẩm quyền về chi phí) — ⚠ điều lệ CÓ nêu thẩm quyền của PM, ⚠ nhưng đó không phải lý do cần nó khi đang LẬP ƯỚC LƯỢNG chi phí; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • C (điều lệ xác định ai phê duyệt ngân sách) — ⚠ tương tự, thuộc về thẩm quyền chứ không phải dữ liệu để ước lượng.

  • B (điều lệ xác định tổng chi phí của các gói công việc) — ⚠ SAI hoàn toàn: ⚠ điều lệ là tài liệu MỨC CAO, ⚠ nó không có chi tiết tới mức gói công việc; ⚠ chi phí gói công việc là kết quả của ước lượng bottom-up.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25695 ở lô này về mục đích của điều lệ và câu #25647 ở lô 178 về ước lượng dứt khoát cần WBS. ⚠ Ba câu vẽ đủ chuỗi: điều lệ cho con số thô, WBS cho con số chi tiết.

⚠ Thang ước lượng chi phí qua các giai đoạn: | Giai đoạn | Nguồn | Độ chính xác | |---|---|---| | ⚠ Điều lệ dự án | ⚠ ngân sách tóm tắt, ước lượng ROM | ⚠ −25% đến +75% | | ⚠ Sau khi có phạm vi | ⚠ ước lượng sơ bộ | ⚠ −10% đến +25% | | ⚠ Sau khi có WBS chi tiết | ⚠ ước lượng dứt khoát, bottom-up | ⚠ −5% đến +10% | | ⚠ Vai trò của điều lệ | ⚠ là mốc so sánh: ước lượng chi tiết có khớp với kỳ vọng ban đầu không |

Từ khoá nhận diện:

"ngân sách tóm tắt, nguồn lực tài chính đã duyệt sơ bộ" → ⚠ project charter "chi phí từng gói công việc" → ⚠ kết quả của Estimate Costs, không có trong điều lệ "đường cơ sở chi phí" → ⚠ đầu ra của Determine Budget "ai có thẩm quyền phê duyệt" → ⚠ cũng có trong điều lệ nhưng là mục khác

⚠ Bốn quy trình quản lý chi phí Quy trình
⚠ Plan Cost Management ⚠ cách ước lượng, cách đo, đơn vị, ngưỡng kiểm soát
⚠ Estimate Costs ⚠ ước lượng chi phí từng hoạt động — BƯỚC CỦA CÂU NÀY
⚠ Determine Budget ⚠ cộng dồn thành ĐƯỜNG CƠ SỞ CHI PHÍ
⚠ Control Costs ⚠ theo dõi, dùng EVM
⚠ Lưu ý ⚠ cost baseline + management reserve = tổng ngân sách dự án
⚠ Điều xảy ra khi ước lượng chi tiết VƯỢT ngân sách tóm tắt Việc phải làm
⚠ Báo cáo NGAY cho nhà tài trợ ⚠ đừng giấu và hy vọng bù được sau
⚠ Trình bày các phương án ⚠ giảm phạm vi, dời hạn, tăng ngân sách, chấp nhận rủi ro cao hơn
⚠ Nếu tăng ngân sách: cập nhật điều lệ ⚠ qua kiểm soát thay đổi
⚠ Đây là lý do ⚠ phải đối chiếu với điều lệ NGAY từ đầu chứ không phải cuối giai đoạn lập kế hoạch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Điều lệ của bạn có nêu ngân sách sơ bộ không | | | Ước lượng chi tiết có khớp với con số đó không | | | Nếu lệch nhiều thì đã báo cáo chưa | |

Và cách trả lời đội của Quincy: "điều lệ cho chúng ta biết tổ chức đã hình dung dự án này tốn bao nhiêu — chúng ta cần biết mình đang bám vào con số nào trước khi ước lượng chi tiết."

Câu 197
You are a project manager for your organization. Your current project has a budget of $1,250,650 and is currently 65 percent done. Due to some errors by the project team, however, you were supposed to 75 percent as of today. In your project you have spent $847,500 – slightly more than what was planned. It has just come to your attention, however, that a major defect will cost the project an additional $29,700. What is your cost performance index now?
  1. A 0.9
  2. B 0.87
  3. C 1.03
  4. D 0.93
Xem giải thích

Đáp án

D — 0,93.

Vì sao đúng

⚠ Bóc tách dữ liệu: | Đại lượng | Cách tính | Kết quả | |---|---|---| | ⚠ BAC | ⚠ đề cho | ⚠ 1.250.650 | | ⚠ EV | ⚠ BAC × 65% | ⚠ 812.922,5 | | ⚠ AC ban đầu | ⚠ đề cho | ⚠ 847.500 | | ⚠ Chi phí khuyết tật PHÁT SINH | ⚠ đề cho | ⚠ 29.700 | | ⚠ AC MỚI | ⚠ 847.500 + 29.700 | ⚠ 877.200 |

⚠ Tính CPI mới: | Bước | Phép tính | |---|---| | ⚠ CPI = EV / AC | | | ⚠ = 812.922,5 / 877.200 | | | ⚠ = 0,9267... | ⚠ ≈ 0,93 | | ⚠ Điểm mấu chốt | ⚠ khuyết tật làm TĂNG chi phí thực tế mà KHÔNG tăng giá trị thu được — nên CPI xấu đi |

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

  • A (0,9) — ⚠ không khớp phép tính nào; ⚠ nếu AC là 903.247 thì mới ra 0,9.

  • B (0,87) — ⚠ quá thấp; ⚠ tương ứng AC khoảng 934.000.

  • C (1,03) — ⚠ lớn hơn 1 nghĩa là TIẾT KIỆM, ⚠ vô lý khi vừa phát sinh thêm chi phí khuyết tật.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là biến thể THỨ BA của cùng một mẫu đề trong bộ này. ⚠ Cùng ngân sách ⚠ 1.250.650, ⚠ cùng cách diễn đạt, ⚠ và câu này dùng ⚠ CHÍNH XÁC bộ số của #25581 và #25685 ⚠ (65%, 75%, AC 847.500) ⚠ nhưng ⚠ THÊM một dữ kiện: chi phí khuyết tật 29.700. ⚠ Bảng đối chiếu bốn biến thể: | Câu | Lô | Số liệu | Hỏi gì | Đáp án | |---|---|---|---|---| | ⚠ #25581 | ⚠ 176 | ⚠ 65/75, AC 847.500 | ⚠ CV | ⚠ (34.578) | | ⚠ #25685 | ⚠ 179 | ⚠ 65/75, AC 847.500 | ⚠ CPI | ⚠ 0,96 | | ⚠ #25708 | ⚠ 179 | ⚠ 75/80, AC 989.000 | ⚠ ETC | ⚠ 329.667 | | ⚠ #25718 | ⚠ 179 | ⚠ 65/75, AC 847.500 + 29.700 | ⚠ CPI mới | ⚠ 0,93 | ⚠ Bốn khoá đáp án đều ĐÚNG và KHÔNG mâu thuẫn nhau. ⚠ So sánh #25685 với câu này rất đáng học: cùng EV, chỉ khác AC, CPI tụt từ 0,96 xuống 0,93 — đó chính là cái giá của một khuyết tật, đo bằng con số.

⚠ Vì sao khuyết tật làm CPI xấu đi: | Điều | Nội dung | |---|---| | ⚠ Tiền sửa khuyết tật là CHI PHÍ THỰC TẾ → AC tăng | | | ⚠ Sửa khuyết tật KHÔNG tạo ra phạm vi mới → EV KHÔNG đổi | ⚠ điểm mấu chốt | | ⚠ CPI = EV / AC, tử số giữ nguyên mà mẫu số tăng → CPI giảm | | | ⚠ Đây chính là | ⚠ chi phí không phù hợp chất lượng, đo được bằng EVM |

⚠ Các chỉ số khác sau khi có khuyết tật: | Chỉ số | Trước | Sau | |---|---|---| | ⚠ AC | ⚠ 847.500 | ⚠ 877.200 | | ⚠ CV = EV − AC | ⚠ −34.577,5 | ⚠ −64.277,5 | | ⚠ CPI | ⚠ 0,96 | ⚠ 0,93 | | ⚠ EAC = BAC / CPI | ⚠ ≈ 1.303.849 | ⚠ ≈ 1.349.752 | | ⚠ VAC = BAC − EAC | ⚠ ≈ −53.199 | ⚠ ≈ −99.102 | | ⚠ Nhận xét | ⚠ một khuyết tật 29.700 làm dự báo vượt ngân sách tăng thêm gần 46.000 — vì xu hướng xấu được nhân lên cho phần việc còn lại |

Từ khoá nhận diện:

"phát sinh thêm chi phí" → ⚠ cộng vào AC, KHÔNG cộng vào EV "CPI bây giờ là bao nhiêu" → ⚠ tính lại với AC mới "vừa xảy ra sự cố" → ⚠ CPI phải XẤU ĐI, loại ngay phương án ≥ 1

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí phát sinh có làm tăng EV không | ⚠ sửa lỗi thì KHÔNG; làm thêm phạm vi được duyệt thì CÓ | | CPI mới có nhỏ hơn CPI cũ không | ⚠ phải nhỏ hơn, nếu không thì tính sai | | EAC mới đã được báo cáo chưa | |

Và bài học đắt giá mà con số này nói ra: 29.700 chi phí khuyết tật kéo dự báo vượt ngân sách tăng thêm gần 46.000. Vì EVM giả định xu hướng hiện tại sẽ tiếp diễn, nên một khuyết tật hôm nay được "nhân lên" cho toàn bộ phần việc còn lại.

Câu 198
You are the project manager for your organization and your project team has identified a risk that has a 40 percent chance of happening and will cost your project $245,000 if it occurs. You present the risk to the project sponsor as it’s a significant risk event in your project. Your project sponsor wants to know what the expected monetary value of the risk is. What’s the best response in this scenario?
  1. A ($245,000)
  2. B $245,000
  3. C ($98,000)
  4. D You can’t know as the risk event has not yet occurred.
Xem giải thích

Đáp án

C — (98.000) — tức âm 98.000.

Vì sao đúng

⚠ Công thức giá trị tiền tệ kỳ vọng (EMV): | Bước | Phép tính | |---|---| | ⚠ EMV = Xác suất × Tác động | | | ⚠ Xác suất | ⚠ 40% = 0,40 | | ⚠ Tác động | ⚠ −245.000 — ÂM vì đây là MỐI ĐE DOẠ, gây thiệt hại | | ⚠ EMV = 0,40 × (−245.000) | ⚠ = −98.000 | | ⚠ Cách viết | ⚠ (98.000) — dấu ngoặc đơn là quy ước kế toán cho số âm |

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

  • B (245.000) — ⚠ là TÁC ĐỘNG đầy đủ nếu rủi ro xảy ra, ⚠ chưa nhân với xác suất; ⚠ và thiếu dấu âm.

  • A ((245.000)) — ⚠ có dấu âm đúng nhưng CHƯA NHÂN xác suất; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • D (không thể biết vì rủi ro chưa xảy ra) — ⚠ SAI về bản chất: ⚠ EMV chính là công cụ để ĐỊNH LƯỢNG rủi ro CHƯA xảy ra.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25533 ở lô 175 cũng tính EMV. ⚠ Cùng công thức, khác con số.

⚠ Quy ước dấu của EMV — điểm hay bị bỏ qua: | Loại rủi ro | Dấu tác động | Dấu EMV | |---|---|---| | ⚠ Threat — mối đe doạ | ⚠ ÂM | ⚠ ÂM — viết trong ngoặc đơn | | ⚠ Opportunity — cơ hội | ⚠ DƯƠNG | ⚠ DƯƠNG | | ⚠ Lưu ý thi | ⚠ nếu đề có cả phương án dương lẫn âm cùng giá trị, hãy xem rủi ro là đe doạ hay cơ hội |

⚠ EMV dùng để làm gì: | Công dụng | Nội dung | |---|---| | ⚠ Tính DỰ PHÒNG cho từng rủi ro | ⚠ contingency reserve | | ⚠ So sánh các rủi ro với nhau để xếp ưu tiên | | | ⚠ Đầu vào của CÂY QUYẾT ĐỊNH | ⚠ decision tree analysis | | ⚠ Thuộc PHÂN TÍCH RỦI RO ĐỊNH LƯỢNG | ⚠ Perform Quantitative Risk Analysis | | ⚠ Cần gì | ⚠ phải ước lượng được cả xác suất lẫn tác động bằng SỐ — không phải rủi ro nào cũng làm được |

Từ khoá nhận diện:

"giá trị tiền tệ kỳ vọng" → ⚠ xác suất × tác động "tổng dự phòng cho các rủi ro" → ⚠ cộng EMV của mọi rủi ro "chọn nhánh nào có lợi nhất" → ⚠ cây quyết định, dùng EMV cho từng nhánh "chạy mô phỏng nghìn kịch bản" → ⚠ Monte Carlo, không phải EMV

⚠ Ví dụ tính dự phòng bằng EMV Ví dụ
⚠ Rủi ro A: 40% × 245.000 thiệt hại ⚠ EMV = −98.000
⚠ Rủi ro B: 20% × 150.000 thiệt hại ⚠ EMV = −30.000
⚠ Cơ hội C: 30% × 80.000 tiết kiệm ⚠ EMV = +24.000
⚠ Tổng EMV ⚠ −98.000 − 30.000 + 24.000 = −104.000
⚠ Dự phòng đề xuất ⚠ khoảng 104.000 cho contingency reserve
⚠ Hạn chế của EMV cần biết Hạn chế
⚠ Là con số TRUNG BÌNH cho nhiều lần lặp ⚠ nhưng dự án chỉ chạy MỘT lần
⚠ Rủi ro 98.000 KHÔNG xảy ra — nó xảy ra ở mức 245.000 hoặc 0
⚠ Không phản ánh rủi ro thảm hoạ hiếm gặp ⚠ 1% × 100 triệu cũng cho EMV giống 100% × 1 triệu, nhưng hai tình huống rất khác nhau
⚠ Vì thế ⚠ EMV để xếp ưu tiên và lập dự phòng, không phải để coi nhẹ rủi ro tác động lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xác suất và tác động lấy từ đâu | ⚠ dữ liệu lịch sử hay phán đoán chuyên gia | | Đây là đe doạ hay cơ hội | ⚠ quyết định dấu của kết quả | | Rủi ro có tác động THẢM HOẠ không | ⚠ nếu có thì đừng chỉ nhìn EMV |

Và cảnh báo quan trọng nhất khi trình bày với nhà tài trợ: con số 98.000 không phải thứ sẽ xảy ra. Thực tế hoặc là mất 245.000, hoặc là không mất gì — EMV chỉ là công cụ để so sánh và lập dự phòng.

Câu 199
Ned is a project manager for his organization and he’s working with the project team to create a schedule for the project work. Ned learns that some of the project team members have vacations scheduled that will affect the project schedule. Where should Ned record information about the project team members’ vacations?
  1. A Project calendar
  2. B Project schedule
  3. C Risk log
  4. D Resource calendar
Xem giải thích

Đáp án

D — Resource calendar (lịch nguồn lực).

Vì sao đúng

⚠ Lịch nguồn lực là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Ghi thời gian mỗi nguồn lực CÓ THỂ làm việc | | | ⚠ Bao gồm NGHỈ PHÉP, nghỉ lễ, cam kết ở dự án khác | ⚠ đúng tình huống của Ned | | ⚠ Áp dụng cho cả NGƯỜI lẫn THIẾT BỊ | ⚠ máy móc cũng có lịch bảo trì | | ⚠ Là ĐẦU VÀO của Estimate Activity Durations và Develop Schedule | | | ⚠ Vì sao quan trọng | ⚠ một hoạt động cần 5 ngày công nhưng người làm nghỉ phép 3 ngày thì thực tế mất 8 ngày |

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

  • A (Project calendar — lịch dự án) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ lịch dự án ghi ⚠ ngày làm việc CHUNG của cả dự án (⚠ thứ Hai tới thứ Sáu, ngày lễ của tổ chức), ⚠ KHÔNG ghi lịch cá nhân của từng người.

  • B (Project schedule — lịch trình dự án) — ⚠ là KẾT QUẢ: ⚠ nó thể hiện hoạt động nào diễn ra khi nào, ⚠ lịch nguồn lực là ĐẦU VÀO để dựng ra nó.

  • C (Risk log) — ⚠ không phải tên tài liệu chuẩn; ⚠ và nghỉ phép đã lên kế hoạch là SỰ THẬT đã biết, ⚠ không phải sự kiện không chắc chắn.

Ghi nhớ

⚠ Phân biệt hai loại lịch — bảng cần thuộc: | Lịch | Ghi gì | Phạm vi | |---|---|---| | ⚠ Project calendar | ⚠ ngày và ca làm việc CHUNG của dự án | ⚠ toàn dự án | | ⚠ Resource calendar | ⚠ thời gian SẴN CÓ của TỪNG nguồn lực | ⚠ từng người, từng thiết bị | | ⚠ Ví dụ project calendar | ⚠ "dự án làm việc thứ Hai tới thứ Sáu, nghỉ Tết từ ngày X tới ngày Y" | | ⚠ Ví dụ resource calendar | ⚠ "Nam nghỉ phép tuần thứ ba của tháng Sáu; Lan chỉ làm 50% thời gian cho dự án này" |

Từ khoá nhận diện:

"nghỉ phép của một thành viên cụ thể" → ⚠ resource calendar "ngày làm việc của cả dự án" → ⚠ project calendar "hoạt động nào diễn ra khi nào" → ⚠ project schedule "người này chỉ làm 50% thời gian cho dự án" → ⚠ resource calendar

⚠ Lịch nguồn lực ghi những gì Nội dung
⚠ Ngày và ca mà nguồn lực sẵn sàng
⚠ Nghỉ phép, nghỉ lễ cá nhân
⚠ Cam kết ở dự án hoặc công việc khác ⚠ rất quan trọng trong cơ cấu ma trận
⚠ Tỷ lệ phân bổ cho dự án ⚠ toàn thời gian hay bán thời gian
⚠ Kỹ năng và năng lực
⚠ Vị trí địa lý và múi giờ ⚠ với đội phân tán
⚠ Lịch bảo trì thiết bị
⚠ Ned nên làm gì tiếp Bước
⚠ 1. Cập nhật lịch nguồn lực với thông tin nghỉ phép
⚠ 2. TÍNH LẠI lịch trình dự án ⚠ thời lượng một số hoạt động sẽ kéo dài
⚠ 3. Kiểm tra ĐƯỜNG GĂNG có bị ảnh hưởng không
⚠ 4. Nếu có: cân nhắc san bằng nguồn lực hoặc đổi người ⚠ resource levelling hoặc resource smoothing
⚠ 5. Nếu vẫn trễ: báo cáo và đề xuất phương án
⚠ Đừng ⚠ ép người ta huỷ kỳ nghỉ đã lên kế hoạch — đó là yếu tố duy trì theo Herzberg
⚠ San bằng và làm mượt nguồn lực Phân biệt
⚠ Resource levelling — san bằng ⚠ ưu tiên giới hạn nguồn lực; CÓ THỂ làm thay đổi đường găng và kéo dài dự án
⚠ Resource smoothing — làm mượt ⚠ chỉ dùng phần float sẵn có; KHÔNG làm đường găng dài ra
⚠ Mẹo nhớ ⚠ levelling có thể trễ dự án, smoothing thì không

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có lịch nguồn lực cho từng người chưa | ⚠ hay chỉ giả định ai cũng sẵn sàng 100% | | Đã hỏi về kế hoạch nghỉ phép ngay từ đầu dự án chưa | | | Lịch trình có tính tới ngày nghỉ thật sự không | ⚠ giả định "ai cũng làm đủ 5 ngày mỗi tuần" là giả định sai kinh điển |

Và giả định nguy hiểm nhất khi lập lịch: coi mọi người đều sẵn sàng 100% thời gian. Nghỉ phép, họp hành, hỗ trợ dự án khác và ốm đau thường chiếm 20–30% quỹ thời gian thật — bỏ qua chúng là lịch sai ngay từ ngày đầu.

Câu 200
You are a project manager for the JHKL Organization, and you are leading an adaptive project. In an adaptive project, who has control of the detailed planning of the product?
  1. A Project sponsor
  2. B Project team
  3. C Product owner
  4. D Project manager
Xem giải thích

Đáp án

B — Project team (đội dự án).

Vì sao đúng

⚠ Phân chia quyền kiểm soát trong dự án thích ứng: | Vai trò | Kiểm soát cái gì | |---|---| | ⚠ PRODUCT OWNER | ⚠ kiểm soát CÁI GÌ được làm và THỨ TỰ ưu tiên — nội dung backlog | | ⚠ ĐỘI DỰ ÁN | ⚠ kiểm soát LÀM THẾ NÀO và lập kế hoạch CHI TIẾT — CÂU NÀY | | ⚠ Scrum Master / PM | ⚠ gỡ vướng, bảo vệ quy trình, huấn luyện — KHÔNG giao việc | | ⚠ Nguyên tắc nền | ⚠ đội TỰ TỔ CHỨC — self-organizing team |

⚠ Cụ thể đội làm gì: | Việc | Nội dung | |---|---| | ⚠ Chia hạng mục backlog thành các công việc nhỏ | | | ⚠ Ước lượng công sức cho từng hạng mục | ⚠ planning poker, story points | | ⚠ Quyết định nhận bao nhiêu việc vào vòng lặp | ⚠ dựa trên velocity | | ⚠ Tự phân công ai làm gì | | | ⚠ Quyết định phương án kỹ thuật | | | ⚠ Vì sao đội quyết | ⚠ họ là người HIỂU CÔNG VIỆC nhất và là người phải thực hiện nó |

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

  • C (Product owner) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ product owner quyết ⚠ LÀM GÌ và ưu tiên nào trước, ⚠ KHÔNG quyết cách làm và không lập kế hoạch chi tiết cho đội.

  • D (Project manager) — ⚠ trong agile, PM đóng vai trò LÃNH ĐẠO PHỤC VỤ, ⚠ không giao việc chi tiết.

  • A (Project sponsor) — ⚠ lo nguồn lực và định hướng chiến lược, ⚠ hoàn toàn không tham gia lập kế hoạch chi tiết.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25674 ở lô 178 — ⚠ Validate Scope và Control Scope lặp lại mỗi vòng lặp cho product owner, ⚠ và câu #25678 về việc ⚠ đội tự thực thi hiến chương đội. ⚠ Ba câu cùng khẳng định nguyên tắc tự tổ chức của đội trong dự án thích ứng.

⚠ Ranh giới trách nhiệm — bảng cần thuộc: | Câu hỏi | Ai trả lời | |---|---| | ⚠ Làm CÁI GÌ? | ⚠ PRODUCT OWNER | | ⚠ Làm theo THỨ TỰ nào? | ⚠ PRODUCT OWNER | | ⚠ Làm THẾ NÀO? | ⚠ ĐỘI | | ⚠ Làm được BAO NHIÊU trong vòng lặp này? | ⚠ ĐỘI | | ⚠ AI làm việc nào? | ⚠ ĐỘI tự phân công | | ⚠ Khi nào coi là XONG? | ⚠ định nghĩa DONE do đội và product owner cùng thống nhất |

Từ khoá nhận diện:

"lập kế hoạch chi tiết, quyết cách làm" → ⚠ đội "sắp xếp ưu tiên backlog, chấp nhận kết quả" → ⚠ product owner "gỡ trở ngại, bảo vệ quy trình" → ⚠ Scrum Master / PM "đội tự tổ chức" → ⚠ nguyên tắc nền của agile

⚠ Vì sao để đội tự lập kế hoạch chi tiết Lý do
⚠ Người làm việc hiểu công việc rõ nhất
⚠ Tự cam kết tạo trách nhiệm cao hơn bị giao việc
⚠ Ước lượng của đội chính xác hơn ước lượng của quản lý
⚠ Quyết định nhanh hơn vì không phải chờ phê duyệt
⚠ Điều kiện để thành công ⚠ đội phải đủ năng lực và được tin tưởng — không phải cứ tuyên bố tự tổ chức là có
⚠ Sai lầm phổ biến của PM khi chuyển sang agile Sai lầm
⚠ Vẫn giao việc cho từng người ⚠ phá vỡ tính tự tổ chức
⚠ Tự quyết đội làm được bao nhiêu mỗi vòng ⚠ đó là việc của đội
⚠ Thay đổi phạm vi GIỮA vòng lặp ⚠ phá vỡ cam kết của đội
⚠ Dùng velocity để so sánh giữa các đội ⚠ velocity chỉ có nghĩa trong nội bộ một đội
⚠ Việc PM NÊN làm ⚠ gỡ trở ngại, bảo vệ đội khỏi can thiệp, huấn luyện, cải thiện quy trình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có tự quyết khối lượng vòng lặp không | | | Ai đang phân công công việc cho từng người | ⚠ nếu là PM thì chưa phải tự tổ chức | | Product owner có can thiệp vào cách làm không | |

Và ranh giới gọn nhất cần thuộc: product owner sở hữu CÁI GÌ và THỨ TỰ, đội sở hữu THẾ NÀO và BAO NHIÊU. Lẫn hai vế này là nguyên nhân của phần lớn xung đột trong đội agile.