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

Tìm thấy 720 câu.

Câu 161 Process
Your organization is partnering with a competing firm to complete a large construction project, and you will serve as the project manager in this partnership. What is this relationship called?
  1. A Dual-entity project management
  2. B Functional team agreement
  3. C Dual functional structure
  4. D Teaming agreement
Xem giải thích

Đáp án

D — Teaming agreement (thoả thuận hợp tác nhóm).

Vì sao đúng

⚠ Teaming agreement là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Thoả thuận PHÁP LÝ giữa hai hoặc nhiều bên | | | ⚠ Để cùng thực hiện MỘT dự án hoặc MỘT cơ hội kinh doanh | | | ⚠ Các bên có thể là ĐỐI THỦ trong lĩnh vực khác | ⚠ đúng tình huống trong đề | | ⚠ Thường dùng cho dự án LỚN vượt năng lực một công ty | | | ⚠ Quy định vai trò, chia sẻ trách nhiệm, chia lợi nhuận, quyền sở hữu trí tuệ | | | ⚠ Thuộc lĩnh vực | ⚠ quản lý mua sắm — thoả thuận với bên ngoài tổ chức |

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

  • A (Dual-entity project management), B (Functional team agreement), C (Dual functional structure) — ⚠ cả ba đều KHÔNG phải thuật ngữ PMBOK; ⚠ chúng nghe hợp lý nhưng là các phương án bịa.

Ghi nhớ

⚠ Vì sao các công ty đối thủ lại hợp tác: | Lý do | Nội dung | |---|---| | ⚠ Dự án QUÁ LỚN cho một công ty | ⚠ thiếu năng lực, nhân lực hoặc vốn | | ⚠ Mỗi bên có năng lực BỔ SUNG cho nhau | | | ⚠ Chia sẻ RỦI RO của một dự án lớn | | | ⚠ Yêu cầu của chủ đầu tư về năng lực tổng hợp | | | ⚠ Trong ngành xây dựng | ⚠ rất phổ biến — nhiều công trình lớn do liên danh thực hiện |

⚠ Nội dung của một teaming agreement: | Mục | Nội dung | |---|---| | ⚠ PHẠM VI công việc của từng bên | ⚠ ranh giới rõ ràng để tránh tranh chấp | | ⚠ VAI TRÒ và trách nhiệm | ⚠ ai là bên dẫn dắt | | ⚠ Cơ chế RA QUYẾT ĐỊNH | | | ⚠ Chia sẻ DOANH THU và CHI PHÍ | | | ⚠ Quyền SỞ HỮU TRÍ TUỆ | ⚠ cực kỳ quan trọng khi hai bên là đối thủ | | ⚠ BẢO MẬT thông tin | ⚠ thông tin nào được chia sẻ, thông tin nào không | | ⚠ Cơ chế giải quyết tranh chấp | | | ⚠ Điều kiện chấm dứt | |

Từ khoá nhận diện:

"hợp tác với công ty khác để cùng làm một dự án" → ⚠ teaming agreement "hợp đồng mua dịch vụ từ nhà cung cấp" → ⚠ procurement contract "cho phép bắt đầu trước khi ký hợp đồng" → ⚠ letter of intent — xem câu #25871 ở lô 182 "ghi nhớ thoả thuận chung" → ⚠ MOU

⚠ Thách thức đặc biệt khi PM cho liên danh Thách thức
⚠ Hai VĂN HOÁ tổ chức khác nhau
⚠ Hai bộ quy trình và công cụ khác nhau
⚠ Lòng tin hạn chế vì là đối thủ ⚠ xem câu #25787 ở lô 181 về rủi ro niềm tin
⚠ Thông tin nhạy cảm phải được kiểm soát chặt
⚠ Quyền hạn của PM có thể mơ hồ giữa hai bên
⚠ Cách giảm ⚠ làm rõ vai trò bằng RACI, thống nhất quy trình chung, và ghi mọi thoả thuận thành văn bản
⚠ Các dạng hợp tác giữa các tổ chức Dạng
⚠ Teaming agreement ⚠ hợp tác cho một dự án hoặc cơ hội cụ thể
⚠ Joint venture ⚠ lập một pháp nhân MỚI chung
⚠ Consortium ⚠ liên minh nhiều bên, thường cho dự án rất lớn
⚠ Subcontracting ⚠ một bên là nhà thầu chính, bên kia là nhà thầu phụ
⚠ Khác nhau ở ⚠ mức độ ràng buộc pháp lý và cơ cấu quản trị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phạm vi của từng bên có rõ ràng không | ⚠ mơ hồ là nguồn tranh chấp lớn nhất | | Ai có quyền quyết định cuối cùng | | | Thông tin nhạy cảm được kiểm soát thế nào | ⚠ đặc biệt quan trọng khi đối tác cũng là đối thủ |

Và thách thức lớn nhất khi làm PM cho một liên danh với đối thủ: bạn phải xây dựng niềm tin đủ để làm việc, nhưng vẫn giữ ranh giới bảo mật. Thoả thuận rõ ràng bằng văn bản là điều kiện tiên quyết.

Câu 162 Process
Agile models should most likely include
  1. A A detailed diagram of the exact look and feel desired on each screen.
  2. B Use case diagrams and screen mock-ups.
  3. C None of the above, as models are far too detailed to be included in an agile project.
  4. D Fully functional prototypes and data dictionaries.
Xem giải thích

Đáp án

B — Sơ đồ CA SỬ DỤNG (use case diagram) và BẢN PHÁC MÀN HÌNH (screen mock-up).

Vì sao đúng

⚠ Vì sao đây là mức mô hình phù hợp với agile: | Lý do | Nội dung | |---|---| | ⚠ Đủ để cả đội HIỂU CHUNG về sản phẩm | | | ⚠ Không quá chi tiết tới mức tốn công và nhanh lỗi thời | | | ⚠ Là công cụ GIAO TIẾP, không phải sản phẩm bàn giao | | | ⚠ Sửa nhanh khi yêu cầu thay đổi | | | ⚠ Nguyên tắc | ⚠ mô hình VỪA ĐỦ — barely sufficient |

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

  • A (sơ đồ CHI TIẾT chính xác về hình thức mong muốn của từng màn hình) — ⚠ QUÁ chi tiết: ⚠ tốn công trau chuốt, ⚠ và giao diện thường thay đổi sau phản hồi người dùng.

  • D (nguyên mẫu chạy được ĐẦY ĐỦ và từ điển dữ liệu) — ⚠ cũng QUÁ nặng: ⚠ nguyên mẫu chạy đầy đủ gần như là làm sản phẩm hai lần.

  • C (không nên có mô hình nào vì quá chi tiết cho agile) — ⚠ QUÁ TUYỆT ĐỐI: ⚠ agile ⚠ KHÔNG cấm mô hình, ⚠ chỉ phản đối mô hình thừa.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25848 ở lô 182 (không trau chuốt mô hình trong agile) và câu #25768 ở lô 180 (wireframe cố ý vẽ thô). ⚠ Ba câu cùng một nguyên tắc: mô hình phục vụ giao tiếp, không phải để trưng bày.

⚠ Thang mức chi tiết của mô hình: | Mức | Ví dụ | Phù hợp agile không | |---|---|---| | ⚠ Rất thô | ⚠ phác trên bảng trắng, giấy nhớ | ⚠ RẤT phù hợp | | ⚠ Vừa đủ | ⚠ use case diagram, wireframe, screen mock-up | ⚠ PHÙ HỢP NHẤT — CÂU NÀY | | ⚠ Chi tiết | ⚠ thiết kế giao diện hoàn chỉnh có màu và kiểu chữ | ⚠ chỉ khi thật cần | | ⚠ Rất chi tiết | ⚠ nguyên mẫu chạy đầy đủ, từ điển dữ liệu hoàn chỉnh | ⚠ thường là lãng phí | | ⚠ Nguyên tắc | ⚠ dùng mức THÔ NHẤT đủ để trả lời câu hỏi đang có |

⚠ Các mô hình thường dùng trong agile: | Mô hình | Cho biết gì | |---|---| | ⚠ Use case diagram | ⚠ ai dùng hệ thống và dùng để làm gì | | ⚠ Screen mock-up / wireframe | ⚠ bố cục màn hình và luồng chuyển | | ⚠ User story map | ⚠ hành trình người dùng, cơ sở xếp backlog | | ⚠ Persona | ⚠ chân dung người dùng điển hình | | ⚠ Context diagram | ⚠ hệ thống và các bên tương tác với nó | | ⚠ Sơ đồ kiến trúc mức cao | ⚠ để cả đội hiểu chung về cấu trúc | | ⚠ Điểm chung | ⚠ đều NHANH làm, DỄ sửa, và phục vụ một cuộc trò chuyện cụ thể |

Từ khoá nhận diện:

"use case, mock-up, wireframe" → ⚠ mức mô hình phù hợp agile "chi tiết chính xác từng màn hình" → ⚠ quá nặng "nguyên mẫu đầy đủ, từ điển dữ liệu" → ⚠ quá nặng "agile không dùng mô hình" → ⚠ hiểu SAI, luôn là đáp án sai

⚠ Vì sao mô hình vừa đủ lại hiệu quả nhất Lý do
⚠ Làm nhanh nên không tiếc khi phải bỏ đi
⚠ Thô vừa đủ nên người xem tập trung vào CẤU TRÚC, không vào thẩm mỹ ⚠ xem câu #25768
⚠ Đủ rõ để phát hiện hiểu nhầm về yêu cầu
⚠ Sửa được ngay trong buổi họp
⚠ Mô hình quá đẹp ⚠ người ta ngại sửa vì đã tốn công làm — mất tính linh hoạt
⚠ Khi nào mô hình chi tiết VẪN cần Trường hợp
⚠ Kiến trúc hệ thống phức tạp phải bàn giao cho đội vận hành
⚠ Yêu cầu tuân thủ pháp lý bắt buộc ⚠ xem câu #25872 ở lô 182
⚠ Giao diện có yêu cầu thương hiệu nghiêm ngặt
⚠ Nguyên tắc ⚠ chi tiết khi có NGƯỜI CẦN nó, không chi tiết vì thói quen

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình này sẽ được ai dùng và dùng bao lâu | | | Vẽ thô có đủ để đội hiểu không | ⚠ nếu đủ thì dừng ở đó | | Mô hình có được cập nhật khi yêu cầu đổi không | ⚠ nếu không thì nó đang gây hiểu nhầm |

Và câu hỏi quyết định mức đầu tư vào mô hình: nó giúp cuộc trò chuyện nào, và cuộc trò chuyện đó đáng bao nhiêu công. Use case và mock-up thường là điểm cân bằng tốt nhất.

Câu 163 Process
Isabella is a scrum master for a new project at the Orange Corporation. While reviewing her project team, she notes that many of them sit in different parts of the office. Isabella puts in a request to move everyone to sit near each other. When asked, what reason is Isabella most likely to give for having this request?
  1. A Having a team together makes it easier for them to work together.
  2. B Having a team together makes stand-ups easier.
  3. C Having the team together cuts down on distractions.
  4. D Having the team together makes it easier to manage them.
Xem giải thích

Đáp án

A — Việc đội ngồi CÙNG NHAU giúp họ LÀM VIỆC CÙNG NHAU dễ dàng hơn.

Vì sao đúng

⚠ Lợi ích chính của collocation: | Lợi ích | Nội dung | |---|---| | ⚠ Giao tiếp TỰ PHÁT — hỏi ngay không cần hẹn | | | ⚠ Osmotic communication | ⚠ nghe lỏm được thông tin hữu ích từ cuộc trò chuyện xung quanh | | ⚠ Giải quyết vấn đề TẠI CHỖ | | | ⚠ Xây NIỀM TIN nhanh hơn nhiều | | | ⚠ Dùng được bảng vật lý và giấy nhớ | | | ⚠ Kết luận | ⚠ lý do BAO QUÁT nhất và đúng nhất — cả bốn lợi ích trên đều nằm trong "làm việc cùng nhau dễ hơn" |

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

  • B (họp đứng dễ hơn) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ĐÚNG nhưng ⚠ QUÁ HẸP — standup chỉ chiếm 15 phút mỗi ngày; ⚠ lợi ích thật nằm ở 7 giờ 45 phút còn lại.

  • C (giảm bớt sự xao nhãng) — ⚠ thực ra NGƯỢC LẠI: ⚠ ngồi cùng chỗ ⚠ TĂNG sự gián đoạn; ⚠ đó là mặt trái đã biết của collocation.

  • D (dễ QUẢN LÝ họ hơn) — ⚠ SAI về tinh thần agile: ⚠ đội TỰ TỔ CHỨC, ⚠ Scrum Master không "quản lý" đội; ⚠ và lý do này nghe như giám sát vi mô.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25789 ở lô 181 ⚠ (đội ngồi cùng chỗ trong bán kính 33 feet gọi là gì). ⚠ Hai câu ⚠ cùng chủ đề collocation ⚠ nhưng ⚠ hỏi khác nhau: ⚠ #25789 hỏi TÊN GỌI, câu này hỏi LÝ DO. ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ MD5 không bắt được vì lời văn hoàn toàn khác.

⚠ Collocation — nhắc lại: | Đặc điểm | Nội dung | |---|---| | ⚠ Mọi thành viên ngồi CÙNG MỘT NƠI | | | ⚠ Khoảng cách khuyến nghị: trong 33 feet, khoảng 10 mét | | | ⚠ Còn gọi là "tight matrix" hoặc "war room" | | | ⚠ Là công cụ của quy trình Develop Team | | | ⚠ Vì sao 33 feet | ⚠ quá khoảng cách này thì giao tiếp tự phát giảm mạnh |

Từ khoá nhận diện:

"đội ngồi gần nhau" → ⚠ collocation, để phối hợp tốt hơn "giảm xao nhãng" → ⚠ SAI — ngồi cùng chỗ TĂNG gián đoạn "dễ quản lý hơn" → ⚠ trái tinh thần đội tự tổ chức "đội phân tán" → ⚠ virtual team, cần hội nghị truyền hình — xem #25784

⚠ Mặt trái của collocation cần thừa nhận Mặt trái
⚠ Bị GIÁN ĐOẠN liên tục ⚠ mặt trái của giao tiếp tự phát
⚠ Khó tập trung sâu cho công việc cần yên tĩnh
⚠ Chi phí không gian văn phòng
⚠ Giới hạn nguồn nhân tài trong phạm vi địa lý
⚠ Cách dung hoà ⚠ có khu vực yên tĩnh riêng, hoặc quy ước "giờ tập trung" không làm phiền nhau
⚠ Isabella nên trình bày yêu cầu thế nào Cách
⚠ Nêu LỢI ÍCH cụ thể cho dự án, không nêu sở thích
⚠ "Đội trao đổi liên tục nên ngồi gần sẽ giảm thời gian chờ đợi"
⚠ Đưa ví dụ: hiện tại một câu hỏi mất bao lâu để được trả lời
⚠ Thừa nhận mặt trái và đề xuất cách xử lý ⚠ khu vực yên tĩnh cho việc cần tập trung
⚠ Đừng ⚠ nói vì "dễ quản lý" — nghe như muốn giám sát
⚠ Nếu KHÔNG được duyệt thì sao Phương án
⚠ Ngồi cùng nhau vài ngày trong tuần ⚠ mô hình lai
⚠ Dùng công cụ cộng tác để bù phần thiếu
⚠ Tăng tần suất gặp mặt trực tiếp ở thời điểm then chốt ⚠ xem câu #25821 ở lô 181
⚠ Bảng công việc số cho ai cũng thấy được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn ngồi cách nhau bao xa | | | Một câu hỏi mất bao lâu để được trả lời | ⚠ thước đo thực tế của chi phí phân tán | | Có không gian yên tĩnh cho việc cần tập trung không | |

Và lý do đúng nhất để xin cho đội ngồi gần nhau: giảm thời gian chờ đợi giữa các cuộc trao đổi. Đó là lợi ích đo được, khác hẳn với lý do "dễ quản lý".

Câu 164 Process
Your team has been tasked with the construction of an aircraft hangar for a nearby airport. Your team members are relatively new to the organization and are still getting used to the project artifact templates provided by the Project Management Office (PMO). One of your team members with an aeronautical engineering background points out a recent change to the approved specifications for hangar construction. This change will require a significant update to all the templates to comply with new regulations. Which of the following is a tool used to manage changes to a product or service?
  1. A Configuration management system
  2. B Version control
  3. C Configuration management
  4. D Artifact management system
Xem giải thích

Đáp án

A — Configuration management system (hệ thống quản lý cấu hình).

Vì sao đúng

⚠ Vì sao đây là câu trả lời: | Lý do | Nội dung | |---|---| | ⚠ Đề hỏi rõ "CÔNG CỤ được dùng để quản lý thay đổi đối với SẢN PHẨM hoặc DỊCH VỤ" | | | ⚠ Quản lý cấu hình lo các đặc tính KỸ THUẬT của sản phẩm | ⚠ khác với kiểm soát thay đổi lo QUYẾT ĐỊNH duyệt hay không | | ⚠ "System" là CÔNG CỤ, không phải khái niệm suông | ⚠ đề hỏi công cụ nên phải chọn phương án có chữ "system" | | ⚠ Kết luận | ⚠ hệ thống quản lý cấu hình là công cụ đúng cho việc thay đổi đặc tả kỹ thuật |

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

  • C (Configuration management) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ đây là ⚠ KHÁI NIỆM/QUY TRÌNH, ⚠ còn đề hỏi ⚠ CÔNG CỤ — nên phải chọn "system".

  • B (Version control) — ⚠ là MỘT PHẦN của quản lý cấu hình, ⚠ chỉ lo việc theo dõi phiên bản, ⚠ không bao quát toàn bộ việc quản lý thay đổi đặc tả.

  • D (Artifact management system) — ⚠ không phải thuật ngữ chuẩn PMBOK.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25840 ở lô 182 ⚠ (hướng dẫn nào KHÔNG nên dùng khi đánh giá hiện vật — đáp án: "dùng mức TỐI ĐA của quản lý cấu hình"). ⚠ Hai câu cùng chủ đề quản lý cấu hình ⚠ nhưng ⚠ #25840 nói về MỨC ĐỘ áp dụng, câu này nói về CÔNG CỤ. ⚠ Hai khoá KHÔNG mâu thuẫn. ⚠ Cũng cùng bối cảnh dự án xây nhà chứa máy bay như câu #25796 ở lô 181.

⚠ Phân biệt quản lý cấu hình với kiểm soát thay đổi: | Mục | Configuration Management | Change Control | |---|---|---| | ⚠ Đối tượng | ⚠ SẢN PHẨM và các đặc tính kỹ thuật của nó | ⚠ các đường CƠ SỞ của dự án | | ⚠ Câu hỏi trả lời | ⚠ "phiên bản hiện tại của sản phẩm là gì?" | ⚠ "có nên duyệt thay đổi này không?" | | ⚠ Hoạt động | ⚠ nhận diện, kiểm soát, ghi nhận trạng thái, kiểm tra xác nhận | ⚠ đánh giá tác động, phê duyệt, cập nhật đường cơ sở | | ⚠ Cả hai | ⚠ nằm trong Perform Integrated Change Control và bổ sung cho nhau |

⚠ Bốn hoạt động của quản lý cấu hình: | Hoạt động | Nội dung | |---|---| | ⚠ Configuration IDENTIFICATION | ⚠ xác định cái gì được đưa vào kiểm soát | | ⚠ Configuration STATUS ACCOUNTING | ⚠ ghi nhận và báo cáo trạng thái từng phiên bản | | ⚠ Configuration VERIFICATION AND AUDIT | ⚠ kiểm tra sản phẩm khớp với đặc tả đã duyệt | | ⚠ Configuration CONTROL | ⚠ kiểm soát việc thay đổi các mục đã đưa vào cấu hình |

Từ khoá nhận diện:

"công cụ quản lý thay đổi SẢN PHẨM" → ⚠ configuration management SYSTEM "quyết định duyệt hay từ chối thay đổi" → ⚠ change control system, CCB "theo dõi phiên bản tài liệu" → ⚠ version control — một phần của quản lý cấu hình "đề hỏi CÔNG CỤ" → ⚠ chọn phương án có chữ "system"

⚠ Vì sao dự án xây dựng đặc biệt cần quản lý cấu hình chặt Lý do
⚠ Rất nhiều bản vẽ và đặc tả, mỗi thứ nhiều phiên bản
⚠ Dùng nhầm bản cũ gây hậu quả VẬT LÝ tốn kém
⚠ Đổi quy định pháp lý kéo theo phải cập nhật hàng loạt ⚠ đúng tình huống trong đề
⚠ Nhiều nhà thầu cùng cần bản mới nhất
⚠ Không có hệ thống ⚠ mỗi bên làm theo một bản khác nhau — công thức của thảm hoạ
⚠ Việc cần làm trong tình huống của đề Bước
⚠ 1. Xác nhận thay đổi quy định là chính thức
⚠ 2. Đánh giá TÁC ĐỘNG lên toàn bộ mẫu và tài liệu
⚠ 3. Nộp YÊU CẦU THAY ĐỔI qua kiểm soát thay đổi tích hợp
⚠ 4. Nếu duyệt: cập nhật qua hệ thống quản lý cấu hình
⚠ 5. Thông báo cho MỌI bên đang dùng mẫu cũ ⚠ bước hay bị quên nhất
⚠ 6. Kiểm tra xác nhận phiên bản mới đã được áp dụng
⚠ Ghi nhận công của thành viên đội ⚠ người phát hiện thay đổi quy định đã giúp tránh một rủi ro tuân thủ lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết phiên bản nào đang là bản chính thức không | | | Ai được quyền cập nhật mẫu và tài liệu chuẩn | | | Khi có bản mới, mọi người có được thông báo không | |

Và ranh giới cần thuộc: kiểm soát thay đổi quyết định CÓ ĐỔI HAY KHÔNG, quản lý cấu hình đảm bảo AI CŨNG DÙNG ĐÚNG BẢN sau khi đã đổi. Hai việc khác nhau, cả hai đều cần.

Câu 165 Process
Raquel is the scrum master for Project CF, which is in its third iteration and has a velocity of thirty-one story points. While reviewing the project backlog, tasks, and schedule, Raquel realizes that a specific vendor will be needed two weeks sooner than expected. What should Raquel do next?
  1. A Escalate the issue to the product owner.
  2. B Adjust the project schedule so that the vendor is not needed until it was initially planned.
  3. C Review the vendor's contract to determine if they can be brought in earlier.
  4. D Delay the project for two weeks.
Xem giải thích

Đáp án

C — XEM LẠI HỢP ĐỒNG của nhà cung cấp để xác định xem có thể đưa họ vào sớm hơn không.

Vì sao đúng

⚠ Vì sao hợp đồng là nơi phải tra đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Nhà cung cấp là bên NGOÀI tổ chức | ⚠ quan hệ do HỢP ĐỒNG điều chỉnh | | ⚠ Hợp đồng quy định thời điểm bắt đầu, thời hạn báo trước, phí phát sinh | | | ⚠ Có thể có điều khoản cho phép điều chỉnh lịch | ⚠ hoặc không cho phép | | ⚠ Không biết hợp đồng nói gì thì không quyết được gì | | | ⚠ Kết luận | ⚠ thu thập thông tin từ nguồn CHÍNH THỨC trước khi hành động |

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

  • B (điều chỉnh lịch dự án để không cần nhà cung cấp sớm) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe hợp lý, ⚠ nhưng đó là ĐỔI KẾ HOẠCH DỰ ÁN để né vấn đề trước khi biết vấn đề có thật sự tồn tại không; ⚠ và trong agile, lịch backlog do đội và product owner quyết.

  • D (hoãn dự án hai tuần) — ⚠ phản ứng CỰC ĐOAN khi chưa biết có cần thiết không.

  • A (leo thang lên product owner) — ⚠ quá sớm: ⚠ chưa có thông tin gì để trình bày; ⚠ và đây là vấn đề MUA SẮM, không phải vấn đề ưu tiên backlog.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25876 ở lô 182 (cho nhân sự thuê ngoài nghỉ → theo hợp đồng) và câu #25822 ở lô 181 (nhà thầu lắp sai vị trí → đối chiếu hợp đồng). ⚠ Ba câu cùng một nguyên tắc: với bên ngoài tổ chức, HỢP ĐỒNG là căn cứ đầu tiên và tối cao.

⚠ Cần kiểm tra gì trong hợp đồng: | Nội dung | Chi tiết | |---|---| | ⚠ Ngày bắt đầu ĐÃ CAM KẾT | | | ⚠ Có điều khoản cho phép ĐIỀU CHỈNH LỊCH không | | | ⚠ Thời hạn BÁO TRƯỚC cần thiết | | | ⚠ PHÍ PHÁT SINH nếu đổi lịch | | | ⚠ Nhà cung cấp có sẵn nguồn lực sớm hơn không | ⚠ hợp đồng cho phép chưa chắc họ đã rảnh | | ⚠ Nếu hợp đồng không rõ | ⚠ hỏi bộ phận mua sắm — PM thường không tự sửa hợp đồng |

Từ khoá nhận diện:

"cần nhà cung cấp sớm hơn" → ⚠ xem HỢP ĐỒNG trước "đổi lịch dự án để né" → ⚠ hành động trước khi biết vấn đề "hoãn dự án" → ⚠ cực đoan "leo thang" → ⚠ chỉ khi đã có thông tin và vượt thẩm quyền

⚠ Chuỗi hành động đúng của Raquel Bước
⚠ 1. XEM hợp đồng ⚠ bước của câu này
⚠ 2. LIÊN HỆ nhà cung cấp xem họ có sẵn sàng sớm hơn không
⚠ 3. Nếu cần sửa hợp đồng: phối hợp với bộ phận MUA SẮM ⚠ Control Procurements
⚠ 4. Nếu phát sinh chi phí: đưa qua kiểm soát thay đổi
⚠ 5. Nếu không thể: bàn với đội và product owner để sắp lại backlog ⚠ lúc này phương án B mới hợp lý
⚠ 6. Ghi rủi ro vào sổ nếu vẫn còn bất định
⚠ Vai trò của Raquel là SCRUM MASTER Lưu ý
⚠ Cô ấy GỠ TRỞ NGẠI cho đội ⚠ việc nhà cung cấp không tới kịp là một trở ngại
⚠ Không tự ý sắp lại backlog ⚠ đó là quyền của product owner
⚠ Không tự ý sửa hợp đồng ⚠ đó là việc của bộ phận mua sắm
⚠ Việc của cô ấy ⚠ tìm hiểu, thu thập thông tin, và đưa phương án cho người có thẩm quyền quyết
⚠ Vì sao phát hiện SỚM là điều tốt Lý do
⚠ Còn thời gian để xử lý ⚠ mới ở vòng lặp thứ ba
⚠ Đàm phán sớm thường rẻ hơn đàm phán gấp
⚠ Có nhiều phương án để chọn
⚠ Raquel làm đúng ⚠ rà soát backlog, công việc và lịch — đó là cách phát hiện sớm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng nói gì về việc điều chỉnh lịch | | | Nhà cung cấp có thật sự sẵn sàng sớm hơn không | ⚠ hợp đồng cho phép chưa đủ | | Ai có thẩm quyền sửa hợp đồng | ⚠ hầu như không phải PM hay Scrum Master |

Và nguyên tắc chung khi làm việc với bên ngoài: đọc hợp đồng trước khi hứa bất cứ điều gì. Kể cả trong dự án agile, hợp đồng vẫn là văn bản pháp lý ràng buộc.

Câu 166 People
Ariel, a project stakeholder, has come to you with an issue she is having with your team. She feels that her concerns for the project are not being considered. Ariel believes there could be an issue with a supplier even though your team has verified that everything is on track and no delivery disruption has been found. She has been arguing with the team members over how they have been verifying the information, citing that she has more awareness of the situation. What skill could be applied to assure Ariel that her concerns have been noted and confirmed?
  1. A Emotional intelligence
  2. B Conflict management
  3. C Influencing
  4. D Decision making
Xem giải thích

Đáp án

B — Conflict management (quản lý xung đột).

Vì sao đúng

⚠ Dấu hiệu xung đột trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Ariel TRANH CÃI với các thành viên đội | ⚠ đã thành xung đột thật, không chỉ là hiểu nhầm | | ⚠ Hai bên có QUAN ĐIỂM ĐỐI LẬP về cùng một sự việc | ⚠ đội nói mọi thứ ổn, Ariel nói có vấn đề | | ⚠ Ariel cho rằng mình HIỂU tình hình hơn | | | ⚠ Ariel cảm thấy mối lo của mình KHÔNG được xem xét | | | ⚠ Kết luận | ⚠ cần kỹ năng quản lý xung đột để giải quyết bất đồng giữa hai bên |

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

  • A (Emotional intelligence — trí tuệ cảm xúc) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ trí tuệ cảm xúc là ⚠ NỀN TẢNG cần có, ⚠ nhưng ⚠ đề hỏi kỹ năng nào ÁP DỤNG để đảm bảo mối lo của Ariel được ghi nhận và xác nhận — đó là hoạt động cụ thể của quản lý xung đột.

  • C (Influencing — tạo ảnh hưởng) — ⚠ dùng khi cần thuyết phục ai đó làm điều gì; ⚠ ở đây mục tiêu là GIẢI QUYẾT bất đồng, không phải thuyết phục Ariel.

  • D (Decision making — ra quyết định) — ⚠ là kỹ năng chọn phương án; ⚠ vấn đề ở đây chưa tới bước quyết định.

Ghi nhớ

⚠ Đối chiếu: ⚠ bộ NĂM câu về chiến lược giải quyết xung đột — ⚠ #25672 (forcing), #25775 (avoiding), #25785 (collaborating), #25814 (compromising), #25851 (smoothing). ⚠ Câu này hỏi ở tầng KỸ NĂNG, năm câu kia hỏi ở tầng CHIẾN LƯỢC cụ thể.

⚠ Chiến lược nào phù hợp với tình huống của Ariel: | Chiến lược | Phù hợp không | |---|---| | ⚠ COLLABORATING | ⚠ PHÙ HỢP NHẤT — cùng Ariel rà soát lại cách kiểm chứng, xem có góc nhìn nào đội bỏ sót không | | ⚠ Smoothing | ⚠ chỉ trấn an mà không kiểm chứng — Ariel sẽ càng bực | | ⚠ Forcing | ⚠ áp đặt kết luận của đội — làm hỏng quan hệ | | ⚠ Avoiding | ⚠ né tránh — vấn đề sẽ leo thang | | ⚠ Kết luận | ⚠ hợp tác: mời Ariel cùng xem cách đội kiểm chứng, và xem cô ấy biết gì mà đội chưa biết |

Từ khoá nhận diện:

"tranh cãi, quan điểm đối lập" → ⚠ conflict management "hiểu và điều tiết cảm xúc" → ⚠ emotional intelligence — nền tảng, không phải hành động "thuyết phục ai đó làm gì" → ⚠ influencing "chọn giữa các phương án" → ⚠ decision making

⚠ Vì sao Ariel có thể ĐÚNG Lý do
⚠ Cô ấy nói mình có NHẬN THỨC TỐT HƠN về tình hình ⚠ có thể cô ấy có thông tin đội không có
⚠ Bên liên quan thường có mạng lưới thông tin riêng
⚠ Đội xác minh "trên giấy" chưa chắc phản ánh thực tế
⚠ Cách xử lý đúng ⚠ HỎI cô ấy dựa vào đâu, thay vì bảo vệ kết luận của đội
⚠ Liên hệ ⚠ xem câu #25785 ở lô 181 — lời phàn nàn có thể chứa một vấn đề thật của dự án
⚠ Cách xử lý cụ thể Bước
⚠ 1. GẶP RIÊNG Ariel, lắng nghe đầy đủ
⚠ 2. HỎI cô ấy dựa trên thông tin gì ⚠ có thể lộ ra dữ kiện đội chưa biết
⚠ 3. Cùng rà soát lại CÁCH đội kiểm chứng
⚠ 4. Nếu có khoảng trống: kiểm chứng lại bằng nguồn khác
⚠ 5. Nếu không: giải thích rõ phương pháp và bằng chứng cho Ariel
⚠ 6. GHI vào sổ vấn đề và phản hồi kết quả cho cô ấy ⚠ xem câu #25873 ở lô 182
⚠ 7. Nếu vẫn lo: ghi vào sổ rủi ro và theo dõi
⚠ Kết quả ⚠ Ariel thấy mối lo được ghi nhận VÀ xác nhận — đúng yêu cầu của đề
⚠ Các kỹ năng liên cá nhân PMBOK liệt kê Kỹ năng
⚠ Conflict management ⚠ giải quyết bất đồng — CÂU NÀY
⚠ Emotional intelligence ⚠ hiểu và điều tiết cảm xúc
⚠ Influencing ⚠ tạo ảnh hưởng khi không có thẩm quyền
⚠ Decision making ⚠ ra quyết định
⚠ Leadership
⚠ Negotiation
⚠ Team building
⚠ Motivation
⚠ Chúng bổ trợ nhau ⚠ trí tuệ cảm xúc là nền, quản lý xung đột là ứng dụng cụ thể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có HỎI người phản đối dựa vào đâu không | ⚠ hay chỉ bảo vệ kết luận của đội | | Mối lo của họ có được ghi vào sổ vấn đề không | | | Họ có được PHẢN HỒI kết quả không | ⚠ không phản hồi thì họ vẫn thấy bị bỏ qua |

Và điều dễ bỏ lỡ nhất khi một bên liên quan phản đối: họ có thể đang nhìn thấy thứ mà đội không nhìn thấy. Xác minh lại tốn vài giờ; bỏ qua một cảnh báo đúng có thể tốn cả dự án.

Câu 167 Process
You are the scrum master of a software development project that has recently launched. One of your team members has just left the organization, and Adam has been assigned as a replacement. Adam has not worked with scrum before but is an excellent developer on your team. Adam approaches you with some requirements that he thinks should be added to the software solution, but he is uncertain how to make a change request in the scrum project. You explain that the product owner can take the requirements, determine if they are needed, and add them to the product backlog. Adam wants to know how the product owner will determine when the items will be incorporated into the solution. Which one of the following choices would be the best answer?
  1. A Expected Monetary Value (EMV) or business value
  2. B Risk mitigation impact or user impact
  3. C Risk impact or risk probability
  4. D Cost-benefit ratio or customer value
Xem giải thích

Đáp án

A — Expected Monetary Value (EMV) hoặc GIÁ TRỊ KINH DOANH (business value).

Vì sao đúng

⚠ Product owner xếp thứ tự backlog dựa trên gì: | Tiêu chí | Nội dung | |---|---| | ⚠ GIÁ TRỊ KINH DOANH | ⚠ tiêu chí CHÍNH — hạng mục nào mang lại nhiều giá trị nhất thì làm trước | | ⚠ EMV — cách ĐỊNH LƯỢNG giá trị đó bằng tiền | ⚠ xác suất × giá trị | | ⚠ Kết hợp với chi phí, rủi ro và phụ thuộc | | | ⚠ Kết luận | ⚠ giá trị kinh doanh là thước đo chuẩn để xếp ưu tiên trong agile |

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

  • D (tỷ số chi phí – lợi ích hoặc giá trị khách hàng) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ "giá trị khách hàng" rất gần với giá trị kinh doanh, ⚠ nhưng "tỷ số chi phí – lợi ích" là chỉ số CHỌN DỰ ÁN ở cấp danh mục, ⚠ không phải công cụ xếp thứ tự backlog trong một dự án.

  • C (tác động rủi ro hoặc xác suất rủi ro) — ⚠ rủi ro CÓ ảnh hưởng tới thứ tự (hạng mục rủi ro cao nên làm sớm để học), ⚠ nhưng KHÔNG phải tiêu chí chính; ⚠ backlog xếp theo GIÁ TRỊ trước hết.

  • B (tác động giảm nhẹ rủi ro hoặc tác động tới người dùng) — ⚠ "tác động tới người dùng" gần đúng, ⚠ nhưng "tác động giảm nhẹ rủi ro" không phải tiêu chí xếp backlog.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Cặp "EMV hoặc business value" là cách ghép hơi bất thường. ⚠ GIÁ TRỊ KINH DOANH ⚠ đúng là tiêu chí chuẩn và không ai tranh cãi. ⚠ EMV ⚠ thì thường được dạy trong bối cảnh ⚠ PHÂN TÍCH RỦI RO ĐỊNH LƯỢNG, ⚠ không phải công cụ mặc định để xếp backlog — ⚠ dù nó CÓ THỂ dùng để định lượng giá trị kỳ vọng của một hạng mục. ⚠ Phương án D chứa "customer value" cũng rất gần với ý đúng. ⚠ Giữ nguyên khoá A vì nó chứa cụm ⚠ "business value" — ⚠ thuật ngữ chuẩn và không thể tranh cãi. ⚠ Khi thi, nếu thấy phương án nào có chữ "business value" hoặc "customer value" trong câu hỏi về xếp backlog, hãy ưu tiên phương án đó.

⚠ Các yếu tố ảnh hưởng tới thứ tự backlog: | Yếu tố | Vai trò | |---|---| | ⚠ GIÁ TRỊ KINH DOANH | ⚠ tiêu chí HÀNG ĐẦU | | ⚠ RỦI RO | ⚠ hạng mục rủi ro cao nên làm sớm để học sớm — xem câu #25842 ở lô 182 | | ⚠ PHỤ THUỘC kỹ thuật | ⚠ có thứ phải làm trước mới làm được thứ sau | | ⚠ CHI PHÍ và công sức | ⚠ giá trị cao mà rẻ thì làm trước | | ⚠ Thời điểm thị trường | | | ⚠ Yêu cầu tuân thủ bắt buộc | | | ⚠ Ai quyết định | ⚠ PRODUCT OWNER — không phải Scrum Master, không phải đội |

Từ khoá nhận diện:

"giá trị kinh doanh, giá trị khách hàng" → ⚠ tiêu chí xếp backlog "xác suất × tác động" → ⚠ EMV — công cụ định lượng "NPV, IRR, BCR, payback" → ⚠ chỉ số CHỌN DỰ ÁN, không phải xếp backlog "ai xếp thứ tự backlog" → ⚠ product owner

⚠ Các kỹ thuật xếp ưu tiên backlog Kỹ thuật
⚠ MoSCoW ⚠ bắt buộc, nên có, có thì tốt, lần này không — xem câu #25762 ở lô 180
⚠ Kano model ⚠ cơ bản, hiệu năng, hấp dẫn
⚠ Weighted shortest job first (WSJF) ⚠ giá trị chia cho thời gian — dùng trong SAFe
⚠ Value vs Effort matrix ⚠ giá trị cao công sức thấp thì làm trước
⚠ 100-point method
⚠ Điểm chung ⚠ đều xoay quanh GIÁ TRỊ mang lại so với CHI PHÍ bỏ ra
⚠ Adam cần hiểu gì về quy trình thay đổi trong Scrum Điều
⚠ Không có "change request" chính thức như dự án dự đoán
⚠ Ý tưởng mới được đưa vào PRODUCT BACKLOG
⚠ Product owner quyết ĐƯA VÀO hay không và ĐỨNG Ở ĐÂU
⚠ Đội ước lượng khi hạng mục được đưa vào sprint
⚠ Đây là điểm khác biệt lớn ⚠ agile chào đón thay đổi, nhưng vẫn có người quyết thứ tự — không phải ai muốn thêm gì cũng được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog của bạn có được xếp theo giá trị không | ⚠ hay theo thứ tự ai đề xuất trước | | Product owner có giải thích được LÝ DO thứ tự không | | | Đội có hiểu vì sao làm hạng mục này trước không | |

Và điều Adam cần nắm khi chuyển từ cách làm truyền thống sang Scrum: ý tưởng tốt không tự động được làm — nó phải cạnh tranh với các ý tưởng khác về giá trị mang lại.

Câu 168 Process
You are the project manager for the Blinx Corporation, and you have finished a large complex project. Your manager, Kelly, approaches you to let you know that Stefan, a colleague, is leaving the organization, and you will be taking over Stefan's project. You meet with Stefan and learn that some of the stakeholders are not happy with the project and are not supportive of the projected expected benefit. Since you have just taken over the project, you request that Stefan introduce you to the stakeholders and set up meetings with the most critical stakeholders on the project.  Which of the following stakeholders will you make it the highest priority to get to know?
  1. A The project sponsor, who you have successfully worked with on many other projects.
  2. B The stakeholder who is an expert on the project's product but is not interested in implementing it in his department.
  3. C The department employee unfamiliar with the project's product but interested to know more about the positive impacts the product will have on his working environment.
  4. D The department manager known to be resistant to change and who will use the project's product.
Xem giải thích

Đáp án

D — Người quản lý phòng ban nổi tiếng là PHẢN ĐỐI THAY ĐỔI và là NGƯỜI SẼ DÙNG sản phẩm của dự án.

Vì sao đúng

⚠ Vì sao đây là bên liên quan ưu tiên cao nhất: | Yếu tố | Nội dung | |---|---| | ⚠ PHẢN ĐỐI thay đổi | ⚠ mức tham gia hiện tại là RESISTANT — cần chuyển sang ít nhất trung lập | | ⚠ Là NGƯỜI DÙNG sản phẩm | ⚠ thành công của dự án PHỤ THUỘC vào việc họ chấp nhận | | ⚠ Là QUẢN LÝ phòng ban | ⚠ có ảnh hưởng tới cả bộ phận, không chỉ bản thân | | ⚠ Đề nói rõ có bên liên quan không ủng hộ lợi ích dự kiến | ⚠ người này nhiều khả năng nằm trong nhóm đó | | ⚠ Kết luận | ⚠ quyền lực CAO + ảnh hưởng CAO + hiện đang PHẢN ĐỐI = ưu tiên số một |

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

  • B (chuyên gia về sản phẩm nhưng không quan tâm triển khai ở phòng ban mình) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ cũng là người cần tiếp cận, ⚠ nhưng họ THỜ Ơ chứ không PHẢN ĐỐI, ⚠ và mức ảnh hưởng thấp hơn một quản lý phòng ban.

  • A (nhà tài trợ mà bạn đã làm việc thành công nhiều lần) — ⚠ quan hệ ĐÃ TỐT sẵn; ⚠ đầu tư thời gian vào đó cho hiệu quả biên thấp.

  • C (nhân viên chưa biết về sản phẩm nhưng quan tâm tìm hiểu) — ⚠ thái độ TÍCH CỰC và mức ảnh hưởng thấp; ⚠ dễ chuyển thành người ủng hộ, không cần ưu tiên cao.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25702 ở lô 179 (bên liên quan tiêu cực Terry), câu #25813 ở lô 181 (bên liên quan kiểu DISC nhóm D), và câu #25888 ở lô này (Ariel cảm thấy không được lắng nghe). ⚠ Bốn câu cùng chủ đề xử lý bên liên quan khó.

⚠ Ma trận đánh giá mức tham gia — công cụ để quyết ưu tiên: | Bên liên quan | Mức HIỆN TẠI | Mức MONG MUỐN | Khoảng cách | |---|---|---|---| | ⚠ Quản lý phòng ban phản đối | ⚠ RESISTANT | ⚠ SUPPORTIVE | ⚠ RẤT LỚN — ưu tiên số một | | ⚠ Chuyên gia thờ ơ | ⚠ NEUTRAL | ⚠ SUPPORTIVE | ⚠ trung bình | | ⚠ Nhân viên quan tâm | ⚠ NEUTRAL đến SUPPORTIVE | ⚠ SUPPORTIVE | ⚠ nhỏ | | ⚠ Nhà tài trợ quen thuộc | ⚠ SUPPORTIVE hoặc LEADING | ⚠ giữ nguyên | ⚠ không có | | ⚠ Nguyên tắc | ⚠ ưu tiên nơi có KHOẢNG CÁCH LỚN NHẤT và MỨC ẢNH HƯỞNG CAO NHẤT |

Từ khoá nhận diện:

"phản đối thay đổi VÀ là người dùng sản phẩm" → ⚠ ưu tiên cao nhất "quan hệ đã tốt sẵn" → ⚠ ưu tiên thấp — hiệu quả biên thấp "thờ ơ, không quan tâm" → ⚠ ưu tiên trung bình "đã quan tâm và tích cực" → ⚠ ưu tiên thấp

⚠ Vì sao NGƯỜI DÙNG phản đối lại nguy hiểm nhất Lý do
⚠ Sản phẩm KHÔNG được dùng thì dự án THẤT BẠI ⚠ dù giao đúng hạn đúng ngân sách
⚠ Quản lý phòng ban ảnh hưởng tới cả bộ phận
⚠ Phản đối ngầm khó phát hiện hơn phản đối công khai
⚠ Lợi ích dự kiến không thành hiện thực ⚠ xem câu #25835 ở lô 182 — dự án đúng tài liệu vẫn bị coi là thất bại
⚠ Liên hệ ⚠ xem câu #25759 ở lô 180 về benefits management plan
⚠ Cách tiếp cận người phản đối thay đổi Cách
⚠ GẶP RIÊNG, lắng nghe trước khi thuyết phục
⚠ TÌM HIỂU vì sao họ phản đối ⚠ thường có lý do chính đáng: sợ mất việc, sợ gián đoạn, từng gặp dự án thất bại
⚠ Thừa nhận mối lo là chính đáng
⚠ Cho họ VAI TRÒ trong dự án ⚠ người muốn kiểm soát mà không có vai trò sẽ tự tìm chỗ cản
⚠ Chỉ ra lợi ích CỤ THỂ cho phòng ban của họ
⚠ Kể chuyện thành công từ nơi khác
⚠ Đừng ⚠ coi họ là chướng ngại vật — mối lo của họ có thể chỉ ra rủi ro thật
⚠ Vì sao bạn có lợi thế khi vừa tiếp quản Lợi thế
⚠ Bạn là NGƯỜI MỚI — không mang theo mâu thuẫn cũ
⚠ Có lý do tự nhiên để gặp gỡ và lắng nghe
⚠ Có thể hỏi "anh chị muốn gì ở dự án này" mà không bị coi là thoái lui
⚠ Tận dụng ⚠ cửa sổ thời gian này thường chỉ kéo dài vài tuần đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ma trận mức tham gia hiện tại và mong muốn không | | | Bên liên quan nào có khoảng cách lớn nhất | ⚠ đó là nơi cần đầu tư thời gian | | Người phản đối có lý do chính đáng nào không | |

Và nguyên tắc phân bổ thời gian cho bên liên quan: đầu tư nơi có khoảng cách lớn nhất và ảnh hưởng cao nhất. Gặp lại nhà tài trợ thân quen thì dễ chịu, nhưng không thay đổi được kết quả dự án.

Câu 169 People
Lena is an exceptional analyst who does excellent work. Unfortunately, she often volunteers to take on more tasks than she can handle. As a result, some team members do not have enough work as milestones approach, and Lena does not ask for help completing a task until the last minute. Before a meeting with a stakeholder, Lena confides to her project manager that she will not have several deliverables ready on time. How should the project manager respond?
  1. A Stop allowing Lena to volunteer for extra work.
  2. B Assign the tasks to other team members during the meeting.
  3. C Ask Lena to tell that stakeholder that her tasks will not be completed on time.
  4. D Tell the stakeholder that some tasks will not be completed on time.
Xem giải thích

Đáp án

C — Đề nghị CHÍNH LENA nói với bên liên quan rằng phần việc của cô ấy sẽ không xong đúng hạn.

Vì sao đúng

⚠ Vì sao để Lena tự nói: | Lý do | Nội dung | |---|---| | ⚠ Giữ TRÁCH NHIỆM ở người thực hiện | ⚠ cô ấy nhận việc thì cô ấy báo cáo | | ⚠ Xây văn hoá tự chịu trách nhiệm | | | ⚠ Lena đã CHỦ ĐỘNG báo với PM — hành vi đáng khuyến khích | | | ⚠ PM nói thay sẽ khiến cô ấy không học được bài học | | | ⚠ Bên liên quan nghe trực tiếp từ người làm sẽ hiểu rõ hơn | | | ⚠ Kết luận | ⚠ PM hỗ trợ và đồng hành, nhưng không nói thay |

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

  • D (PM nói với bên liên quan rằng một số việc sẽ trễ) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ minh bạch là ĐÚNG, ⚠ nhưng PM nói thay sẽ tước mất trách nhiệm của Lena; ⚠ và cô ấy sẽ lặp lại hành vi nhận quá nhiều việc.

  • B (giao lại công việc cho người khác NGAY TRONG cuộc họp) — ⚠ xử lý gấp gáp trước mặt bên liên quan, ⚠ và làm Lena mất mặt.

  • A (không cho Lena nhận thêm việc nữa) — ⚠ giải quyết TRIỆU CHỨNG bằng cách hạn chế, ⚠ và bỏ phí sự nhiệt tình của một người làm việc xuất sắc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25755 ở lô 180 (Joseph báo trễ việc → bảo anh ấy cập nhật với đội) — ⚠ hai câu gần như song sinh: cùng tình huống người tự báo trễ, cùng khoá là ĐỂ HỌ TỰ NÓI. ⚠ Và câu #25725 ở lô 179 (Samuel làm chậm → không loại khỏi đội).

⚠ Vấn đề THẬT trong tình huống này: | Vấn đề | Nội dung | |---|---| | ⚠ Lena NHẬN nhiều việc hơn khả năng | ⚠ nhiệt tình nhưng ước lượng sai năng lực bản thân | | ⚠ Các thành viên khác THIẾU việc | ⚠ phân bổ công việc không đều | | ⚠ Lena chỉ xin giúp vào PHÚT CHÓT | ⚠ vấn đề nghiêm trọng nhất — mất cơ hội xử lý sớm | | ⚠ Cả ba đều là | ⚠ vấn đề HỆ THỐNG về cách phân bổ và theo dõi công việc, không phải lỗi cá nhân Lena |

Từ khoá nhận diện:

"thành viên tự báo sẽ trễ" → ⚠ để họ tự thông báo, PM đồng hành "PM nói thay" → ⚠ tước trách nhiệm của người thực hiện "xử lý ngay trong cuộc họp" → ⚠ gấp gáp và làm mất mặt "cấm nhận thêm việc" → ⚠ xử lý triệu chứng

⚠ PM nên làm gì NGOÀI việc để Lena tự nói Việc
⚠ CHUẨN BỊ cùng Lena trước cuộc họp ⚠ giúp cô ấy trình bày rõ ràng và có phương án
⚠ Có mặt để hỗ trợ khi cô ấy nói ⚠ không bỏ mặc
⚠ Chuẩn bị PHƯƠNG ÁN khắc phục để trình bày cùng
⚠ SAU cuộc họp: bàn với Lena về cách phân bổ việc
⚠ Cân bằng lại khối lượng trong đội ⚠ giải quyết gốc — người thừa việc, người thiếu việc
⚠ Thiết lập cơ chế cảnh báo SỚM ⚠ để lần sau không phải chờ tới phút chót
⚠ Cơ chế cảnh báo sớm nên có gì Cơ chế
⚠ Cập nhật tiến độ ĐỀU ĐẶN, không chỉ khi có vấn đề
⚠ Văn hoá xin giúp đỡ SỚM được khuyến khích ⚠ không bị coi là yếu kém
⚠ PM chủ động hỏi thay vì đợi người ta báo
⚠ Nhìn vào khối lượng thực tế, không chỉ nhìn danh sách việc
⚠ Liên hệ ⚠ xem câu #25755 ở lô 180 — phạt người báo tin xấu là cách chắc chắn nhất để lần sau không ai báo
⚠ Vì sao KHÔNG nên cấm Lena nhận việc Lý do
⚠ Cô ấy làm việc XUẤT SẮC — đó là tài sản
⚠ Nhiệt tình là thứ khó có, đừng dập tắt
⚠ Vấn đề là ƯỚC LƯỢNG và THỜI ĐIỂM xin giúp, không phải sự nhiệt tình
⚠ Cách đúng ⚠ huấn luyện cô ấy về ước lượng khối lượng và về việc xin giúp sớm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khối lượng công việc trong đội có cân bằng không | | | Người ta có dám xin giúp sớm không | | | Bạn có cơ chế phát hiện trễ trước khi tới hạn không | |

Và điều PM nên tránh nhất trong tình huống này: nói thay để "cho nhanh". Lena tự nói sẽ khó chịu hơn một chút nhưng dạy được bài học mà không lời khuyên nào thay thế được.

Câu 170 Process
You are the project manager for your organization and you are creating cost estimates with your project team. A work package within your work breakdown structure is estimated to cost $50,000, with an accuracy range of ±10 percent. The control account for this portion of the WBS has a risk that a particular resource may not be available due to a higher priority project within your organization. If this risk occurs, the cost will rise by up to $2,500. Which type of risk is this an example of which of the following choices?
  1. A Total risk
  2. B Systemic risk
  3. C Project risk
  4. D Estimate risk
Xem giải thích

Đáp án

B — Systemic risk (rủi ro hệ thống).

Vì sao đúng

⚠ Vì sao đây là rủi ro hệ thống: | Chi tiết | Suy ra | |---|---| | ⚠ Nguồn lực có thể bị lấy đi vì một dự án ƯU TIÊN CAO HƠN | | | ⚠ Nguyên nhân nằm ở CƠ CHẾ PHÂN BỔ nguồn lực của TỔ CHỨC | ⚠ không nằm trong dự án | | ⚠ Mọi dự án trong tổ chức đều chịu rủi ro tương tự | | | ⚠ PM không kiểm soát được ưu tiên ở cấp tổ chức | | | ⚠ Kết luận | ⚠ rủi ro đến từ HỆ THỐNG bên ngoài dự án — systemic risk |

⚠ Phân biệt rủi ro hệ thống với rủi ro riêng của dự án: | Loại | Nguồn gốc | Ai kiểm soát | |---|---|---| | ⚠ SYSTEMIC — hệ thống | ⚠ môi trường, tổ chức, thị trường | ⚠ NGOÀI tầm PM — chỉ ứng phó, không loại bỏ được | | ⚠ PROJECT-SPECIFIC — riêng dự án | ⚠ công việc, công nghệ, đội ngũ của chính dự án | ⚠ PM kiểm soát được nhiều hơn | | ⚠ Ví dụ hệ thống | ⚠ tranh giành nguồn lực, đổi chính sách, suy thoái kinh tế, thay đổi ưu tiên chiến lược |

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

  • C (Project risk) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ ĐÚNG là rủi ro của dự án, ⚠ nhưng quá CHUNG CHUNG — mọi rủi ro trong risk register đều là project risk; ⚠ đề hỏi LOẠI cụ thể.

  • D (Estimate risk) — ⚠ không phải phân loại chuẩn; ⚠ và dải ±10% của ước lượng là chuyện khác, không phải rủi ro nguồn lực.

  • A (Total risk) — ⚠ không phải phân loại chuẩn; ⚠ "overall project risk" thì có, nhưng đó là mức rủi ro TỔNG của toàn dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25862 ở lô 182 (đội làm hai dự án cùng lúc, quá tải) và câu #25855 (ma trận yếu, quản lý chức năng kiểm soát nguồn lực). ⚠ Ba câu cùng một gốc: tranh giành nguồn lực giữa các dự án là rủi ro hệ thống điển hình của tổ chức ma trận.

⚠ Các mức rủi ro trong PMBOK: | Mức | Nội dung | |---|---| | ⚠ Individual project risk | ⚠ một sự kiện cụ thể ảnh hưởng tới mục tiêu dự án | | ⚠ Overall project risk | ⚠ mức bất định TỔNG của cả dự án | | ⚠ Systemic risk | ⚠ rủi ro đến từ hệ thống lớn hơn: tổ chức, thị trường, môi trường — CÂU NÀY | | ⚠ Ứng phó khác nhau | ⚠ rủi ro hệ thống thường phải LEO THANG hoặc lập dự phòng, ít khi né tránh được |

Từ khoá nhận diện:

"nguồn lực bị dự án khác lấy mất" → ⚠ systemic risk "đổi chính sách, suy thoái, thay đổi chiến lược" → ⚠ systemic risk "công nghệ mới có thể không chạy" → ⚠ rủi ro riêng của dự án "mức bất định tổng của dự án" → ⚠ overall project risk

⚠ Ứng phó với rủi ro hệ thống thế nào Cách
⚠ ESCALATE — chuyển lên cấp có thẩm quyền ⚠ chỉ PMO hoặc lãnh đạo mới quyết được ưu tiên giữa các dự án
⚠ Lập DỰ PHÒNG cho khả năng mất nguồn lực ⚠ 2.500 trong bài này
⚠ Xin CAM KẾT bằng văn bản từ quản lý chức năng ⚠ xem câu #25855 ở lô 182
⚠ Chuẩn bị phương án thay thế nguồn lực
⚠ Theo dõi ưu tiên của tổ chức để phát hiện sớm
⚠ Không thể ⚠ NÉ TRÁNH — PM không kiểm soát được ưu tiên cấp tổ chức
⚠ Về các con số trong đề Nội dung
⚠ Gói công việc ước lượng 50.000, sai số ±10% ⚠ tức là từ 45.000 tới 55.000
⚠ Nếu rủi ro xảy ra: chi phí tăng thêm tới 2.500 ⚠ khoảng 5% của gói công việc
⚠ Dải sai số ước lượng KHÁC với rủi ro ⚠ điểm dễ nhầm — một cái là độ chính xác, một cái là sự kiện có thể xảy ra
⚠ Cả hai ⚠ đều cần dự phòng, nhưng thuộc hai loại khác nhau
⚠ Vì sao control account là nơi ghi rủi ro này Lý do
⚠ Control account là điểm QUẢN LÝ tổng hợp chi phí và tiến độ
⚠ Dự phòng cho rủi ro thường gắn ở mức control account
⚠ Liên hệ ⚠ xem câu #25627 ở lô 177 về planning package và control account

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro này nằm trong hay ngoài tầm kiểm soát của bạn | ⚠ quyết định là leo thang hay tự xử lý | | Đã có cam kết nguồn lực bằng văn bản chưa | | | Có dự phòng cho khả năng mất nguồn lực không | |

Và đặc điểm khiến rủi ro hệ thống khó chịu nhất: bạn nhìn thấy nó nhưng không sửa được nó. Ứng phó duy nhất là chuẩn bị dự phòng và leo thang lên người có thẩm quyền.