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

Tìm thấy 720 câu.

Câu 1 Process
As a project manager for Sunflower Enterprises, Layla must ensure which of the following is present for integrated change control?
  1. A The project teams' approval of the change
  2. B Detailed support for the change
  3. C Assessed risk for each proposed change
  4. D An SME's approval of the change
Xem giải thích

Đáp án

B — Căn cứ CHI TIẾT hỗ trợ cho thay đổi (detailed support for the change).

Vì sao đúng

⚠ Kiểm soát thay đổi tích hợp đòi hỏi gì: | Yêu cầu | Nội dung | |---|---| | ⚠ Yêu cầu thay đổi phải được VIẾT RA | ⚠ không nhận thay đổi bằng lời nói | | ⚠ Phải có CĂN CỨ: vì sao cần thay đổi | | | ⚠ Phải nêu TÁC ĐỘNG tới phạm vi, lịch, chi phí, chất lượng, rủi ro | | | ⚠ Phải có đủ thông tin để người phê duyệt QUYẾT ĐỊNH được | | | ⚠ Không có căn cứ chi tiết | ⚠ CCB không có cơ sở nào để duyệt hay từ chối — quy trình trở thành hình thức |

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

  • C (đánh giá rủi ro cho từng thay đổi đề xuất) — ⚠ là MỘT PHẦN của việc đánh giá tác động, ⚠ tức là một phần của "căn cứ chi tiết"; ⚠ nó không bao quát đủ toàn bộ yêu cầu; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • A (đội dự án phê duyệt thay đổi) — ⚠ SAI về thẩm quyền: ⚠ đội KHÔNG phê duyệt thay đổi; ⚠ CCB hoặc nhà tài trợ mới có quyền đó.

  • D (chuyên gia SME phê duyệt thay đổi) — ⚠ SME có thể ĐƯỢC THAM VẤN, ⚠ nhưng không phải người phê duyệt.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25705 ở lô này về đường cơ sở đã duyệt thì mọi thay đổi phải qua quy trình và câu #25675 ở lô 178. ⚠ Ba câu cùng chủ đề kiểm soát thay đổi tích hợp.

⚠ Perform Integrated Change Control — bảy bước: | Bước | Việc | |---|---| | ⚠ 1. GHI NHẬN yêu cầu thay đổi bằng văn bản | | | ⚠ 2. Thu thập CĂN CỨ CHI TIẾT | ⚠ lý do, mô tả, tài liệu hỗ trợ — CÂU NÀY | | ⚠ 3. ĐÁNH GIÁ TÁC ĐỘNG toàn diện | ⚠ phạm vi, lịch, chi phí, chất lượng, nguồn lực, RỦI RO, hợp đồng | | ⚠ 4. Trình CCB hoặc người có thẩm quyền | | | ⚠ 5. Phê duyệt, từ chối, hoặc HOÃN | | | ⚠ 6. Cập nhật đường cơ sở và các kế hoạch nếu được duyệt | | | ⚠ 7. Ghi vào CHANGE LOG và thông báo các bên liên quan | |

Từ khoá nhận diện:

"phải có gì để kiểm soát thay đổi hoạt động được" → ⚠ căn cứ chi tiết bằng văn bản "ai phê duyệt thay đổi" → ⚠ CCB hoặc nhà tài trợ, KHÔNG phải đội "mọi thay đổi được duyệt và bị từ chối đều ghi lại" → ⚠ change log "thay đổi ảnh hưởng hợp đồng" → ⚠ Control Procurements

⚠ Một yêu cầu thay đổi tốt gồm những gì Mục
⚠ Mã định danh và ngày đề xuất
⚠ Người đề xuất
⚠ MÔ TẢ thay đổi
⚠ LÝ DO — vấn đề gì đang cần giải quyết
⚠ TÁC ĐỘNG nếu thực hiện
⚠ TÁC ĐỘNG nếu KHÔNG thực hiện ⚠ mục hay bị quên nhất
⚠ Các phương án thay thế đã cân nhắc
⚠ Mức độ khẩn cấp
⚠ Không có những mục này ⚠ CCB chỉ có thể quyết theo cảm tính
⚠ Vì sao thay đổi bằng lời nói lại nguy hiểm Lý do
⚠ Không ai nhớ chính xác đã thoả thuận gì
⚠ Không có dấu vết để giải trình
⚠ Đường cơ sở không được cập nhật → mọi phép đo hiệu suất sai
⚠ Tạo tiền lệ cho lần sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu thay đổi của bạn có đủ căn cứ để người khác quyết không | | | Bạn đã nêu tác động nếu KHÔNG làm chưa | | | Change log có ghi cả thay đổi bị TỪ CHỐI không | ⚠ rất quan trọng khi có tranh chấp sau này |

Và điều phân biệt quy trình thay đổi thật với quy trình hình thức: người phê duyệt có đủ thông tin để nói KHÔNG hay không. Không có căn cứ chi tiết thì mọi thay đổi đều được duyệt — và đó chính là scope creep có thủ tục.

Câu 2 Process
Risk identification and analysis include careful consideration of project requirements, scope objectives, the nature of the project work, and the project documentation. Based on this information, which one of the following statements must be examined for risk?
  1. A The product requires oak beams.
  2. B The product requires a foil stamp of 0.32 millimeters.
  3. C The product must be constructed during the summer months due to the expected good weather.
  4. D A building inspector must approve the product before August 1.
Xem giải thích

Đáp án

D — Một thanh tra xây dựng phải PHÊ DUYỆT sản phẩm TRƯỚC NGÀY 1 THÁNG 8.

Vì sao đúng

⚠ Vì sao phát biểu này phải được xem xét rủi ro: | Yếu tố rủi ro | Nội dung | |---|---| | ⚠ Phụ thuộc vào BÊN THỨ BA ngoài dự án | ⚠ thanh tra xây dựng — bạn không kiểm soát được lịch của họ | | ⚠ Có HẠN CHÓT CỨNG | ⚠ trước ngày 1 tháng 8 | | ⚠ Kết quả có thể là KHÔNG ĐẠT | ⚠ thanh tra có thể từ chối, phải sửa và kiểm tra lại | | ⚠ Là phụ thuộc BẮT BUỘC và BÊN NGOÀI | ⚠ mandatory external dependency | | ⚠ Kết luận | ⚠ đây là điểm tập trung nhiều bất định nhất trong bốn phát biểu |

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

  • A (sản phẩm cần dầm gỗ sồi) — ⚠ là một YÊU CẦU về vật liệu, ⚠ rõ ràng và trong tầm kiểm soát.

  • B (cần dập kim loại dày 0,32 mm) — ⚠ là một ĐẶC TẢ KỸ THUẬT chính xác, ⚠ càng chính xác càng ít bất định.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Phương án C ("sản phẩm phải được xây dựng vào các tháng mùa hè vì THỜI TIẾT DỰ KIẾN TỐT") CŨNG chứa rủi ro rõ ràng — ⚠ "thời tiết dự kiến tốt" là một GIẢ ĐỊNH chưa kiểm chứng, ⚠ và giả định chưa kiểm chứng chính là nguồn rủi ro. ⚠ Chính câu #25637 ở lô 178 đã khẳng định điều này: "lịch trình dựa trên thời tiết có thể dự đoán được" được xác định là GIẢ ĐỊNH chứ không phải ràng buộc. ⚠ Theo cách đọc chặt chẽ thì ⚠ cả C lẫn D đều đáng xem xét rủi ro. ⚠ Giữ nguyên khoá D vì nó tập trung nhiều yếu tố rủi ro hơn: ⚠ bên thứ ba + hạn chót cứng + khả năng bị từ chối, ⚠ trong khi C chỉ có một giả định về thời tiết. ⚠ Khi thi, nếu có nhiều phương án đều chứa rủi ro, hãy chọn cái có NHIỀU yếu tố bất định nhất và NẰM NGOÀI tầm kiểm soát nhất.

⚠ Đâu là dấu hiệu của một nguồn rủi ro: | Dấu hiệu | Ví dụ | |---|---| | ⚠ Phụ thuộc BÊN NGOÀI | ⚠ cơ quan quản lý, nhà cung cấp, đối tác | | ⚠ HẠN CHÓT cứng không dời được | ⚠ ngày 1 tháng 8 | | ⚠ GIẢ ĐỊNH chưa kiểm chứng | ⚠ "thời tiết sẽ tốt" | | ⚠ Công nghệ hoặc phương pháp MỚI | | | ⚠ Yêu cầu MƠ HỒ | | | ⚠ Nguồn lực khan hiếm hoặc kỹ năng hiếm | |

Từ khoá nhận diện:

"bên thứ ba phải phê duyệt" → ⚠ phụ thuộc bên ngoài, rủi ro cao "trước ngày X" → ⚠ ràng buộc cứng, tăng rủi ro "dự kiến, kỳ vọng, thường thì" → ⚠ giả định, nguồn rủi ro "đặc tả chính xác bằng số" → ⚠ yêu cầu rõ, ít rủi ro hơn

⚠ Cách ứng phó với rủi ro phê duyệt của cơ quan quản lý Cách
⚠ Liên hệ SỚM để nắm quy trình và thời gian xử lý thật
⚠ Đăng ký lịch kiểm tra càng sớm càng tốt
⚠ Chừa THỜI GIAN ĐỆM cho khả năng phải kiểm tra lại
⚠ Tự kiểm tra trước theo đúng danh mục của cơ quan ⚠ giảm khả năng bị từ chối
⚠ Ghi vào risk register kèm chủ sở hữu rủi ro
⚠ Không nên ⚠ giả định thanh tra sẽ duyệt ngay lần đầu
⚠ Bốn nguồn thông tin để nhận diện rủi ro Nguồn
⚠ Yêu cầu dự án ⚠ yêu cầu mơ hồ hoặc quá chặt đều là rủi ro
⚠ Mục tiêu phạm vi
⚠ Bản chất công việc ⚠ mới lạ, phức tạp, hay quen thuộc
⚠ Tài liệu dự án ⚠ assumption log, ràng buộc, hợp đồng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án phụ thuộc bên thứ ba nào | ⚠ liệt kê hết và đánh giá từng cái | | Có hạn chót nào không dời được không | | | Giả định nào chưa được kiểm chứng | ⚠ rà lại assumption log |

Và câu hỏi để lọc rủi ro nhanh nhất: "điều gì ở đây tôi KHÔNG kiểm soát được?". Câu trả lời gần như luôn dẫn tới rủi ro lớn nhất của dự án.

Câu 3 People
Sarah is the project manager of a project designed to create an online help manual for customers of a product her company sells. Samuel, a writer for the project, takes considerably longer than what was planned to create the documentation. Though Samuel’s work is excellent, if he continues to be late with the needed documentation, the project will be late. Which of the following is not an appropriate corrective action for this problem?
  1. A Remove Samuel from the project team.
  2. B Determine why Samuel’s work is late.
  3. C Assign Samuel to noncritical activities.
  4. D Assign other writers to some of Samuel’s project work.
Xem giải thích

Đáp án

A — Loại Samuel khỏi đội dự án. ⚠ Đây KHÔNG phải hành động khắc phục phù hợp.

Vì sao đúng

⚠ Vì sao loại Samuel là phản ứng sai: | Lý do | Nội dung | |---|---| | ⚠ Chất lượng công việc của Samuel XUẤT SẮC | ⚠ đề nói rõ điều này | | ⚠ Chưa TÌM HIỂU nguyên nhân vì sao anh ấy chậm | ⚠ có thể do khối lượng, do công cụ, do yêu cầu mơ hồ | | ⚠ Là phản ứng CỰC ĐOAN nhất, dùng SAU CÙNG | | | ⚠ Mất người viết giỏi làm dự án còn khó hơn | ⚠ người thay thế cần thời gian làm quen | | ⚠ Nguyên tắc | ⚠ hành động khắc phục là để đưa hiệu suất về đúng kế hoạch, không phải để trừng phạt |

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

⚠ Cả ba phương án còn lại ĐỀU là hành động khắc phục hợp lý:

  • B (tìm hiểu vì sao công việc của Samuel bị chậm) — ⚠ là bước ĐẦU TIÊN đúng đắn: ⚠ phân tích nguyên nhân gốc trước khi hành động.

  • C (giao Samuel vào các hoạt động KHÔNG nằm trên đường găng) — ⚠ hợp lý: ⚠ tận dụng chất lượng cao của anh ấy ở nơi có float, ⚠ không gây rủi ro cho lịch trình.

  • D (giao bớt phần việc của Samuel cho người viết khác) — ⚠ hợp lý: ⚠ chia tải để kịp tiến độ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25653 ở lô này về sáu bước giải quyết vấn đề — ⚠ bước 1 là ĐỊNH NGHĨA VẤN ĐỀ, bước 2 là TÌM NGUYÊN NHÂN GỐC. ⚠ Phương án B chính là hai bước đó; phương án A nhảy thẳng tới "giải pháp" mà bỏ qua cả hai.

⚠ Ba loại hành động trong PMBOK: | Loại | Nghĩa | |---|---| | ⚠ Corrective action | ⚠ đưa hiệu suất TƯƠNG LAI về đúng kế hoạch | | ⚠ Preventive action | ⚠ giảm khả năng xảy ra vấn đề trong tương lai | | ⚠ Defect repair | ⚠ sửa phần đã làm ra bị lỗi |

Từ khoá nhận diện:

"chưa tìm hiểu nguyên nhân đã hành động" → ⚠ gần như luôn là đáp án SAI "loại người khỏi đội" → ⚠ biện pháp SAU CÙNG, hiếm khi là đáp án đúng "chất lượng tốt nhưng chậm" → ⚠ vấn đề về khối lượng hoặc quy trình, không phải về năng lực "đưa hiệu suất về đúng kế hoạch" → ⚠ corrective action

⚠ Các nguyên nhân thật có thể khiến Samuel chậm Nguyên nhân
⚠ Khối lượng được giao quá lớn so với thời gian ⚠ lỗi ước lượng, không phải lỗi Samuel
⚠ Yêu cầu không rõ nên phải viết đi viết lại
⚠ Đang chờ đầu vào từ người khác
⚠ Kiêm nhiệm nhiều dự án cùng lúc ⚠ lịch nguồn lực chưa được kiểm tra
⚠ Tiêu chuẩn chất lượng anh ấy tự đặt cao hơn yêu cầu ⚠ có thể là gold plating
⚠ Công cụ hoặc quy trình gây cản trở
⚠ Với mỗi nguyên nhân ⚠ giải pháp hoàn toàn khác nhau — nên bước tìm hiểu là bắt buộc
⚠ Thang phản ứng đúng thứ tự Bước
⚠ 1. Tìm hiểu nguyên nhân
⚠ 2. Nói chuyện riêng, hỏi anh ấy cần gì
⚠ 3. Điều chỉnh khối lượng hoặc hỗ trợ thêm người
⚠ 4. Chuyển sang việc không nằm trên đường găng
⚠ 5. Trao đổi với quản lý chức năng nếu vẫn không cải thiện
⚠ 6. Thay người — biện pháp cuối cùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã hỏi người đó chưa | ⚠ thường lộ ra nguyên nhân trong năm phút | | Ước lượng ban đầu có hợp lý không | ⚠ có khi lỗi nằm ở kế hoạch, không ở người | | Việc đó có nằm trên đường găng không | ⚠ quyết định mức độ khẩn cấp |

Và bài học quản lý con người trong dự án: chậm không đồng nghĩa với kém. Người làm chất lượng xuất sắc mà chậm thường đang gặp vấn đề về khối lượng hoặc về yêu cầu — cả hai đều là thứ quản lý dự án sửa được.

Câu 4 Process
Elizabeth is the project manager for the QWERTY Project, which is two weeks into implementation, is on budget and on schedule. Recently Elizabeth was informed that a specific task is at significant risk of slipping, and a stakeholder is upset. Elizabeth confers with the project team member working on the task, and she reports the work is going as expected. What else should Elizabeth do before speaking with the upset stakeholder?
  1. A Review the communications management plan
  2. B Review the risk management plan
  3. C Review the stakeholder engagement plan
  4. D Review the project scope
Xem giải thích

Đáp án

C — Xem lại KẾ HOẠCH THAM GIA CỦA BÊN LIÊN QUAN (stakeholder engagement plan).

Vì sao đúng

⚠ Vì sao xem kế hoạch tham gia trước khi nói chuyện: | Lý do | Nội dung | |---|---| | ⚠ Biết mức tham gia HIỆN TẠI và MONG MUỐN của người này | | | ⚠ Biết mối QUAN TÂM và KỲ VỌNG của họ | ⚠ vì sao họ bực về đúng công việc này | | ⚠ Biết CHIẾN LƯỢC đã định để làm việc với họ | | | ⚠ Biết mức ảnh hưởng và quyền lực của họ | ⚠ quyết định cách tiếp cận | | ⚠ Elizabeth đã làm gì rồi | ⚠ đã kiểm tra SỰ THẬT với thành viên đội — giờ cần chuẩn bị CÁCH TIẾP CẬN |

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

  • A (xem kế hoạch quản lý giao tiếp) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nó cho biết ⚠ KÊNH và TẦN SUẤT gửi thông tin, ⚠ nhưng không cho biết ⚠ mối quan tâm và chiến lược tham gia của người đang bực.

  • B (xem kế hoạch quản lý rủi ro) — ⚠ nói về CÁCH quản lý rủi ro nói chung, ⚠ không giúp cho cuộc trò chuyện này; ⚠ nếu cần thì phải xem RISK REGISTER chứ không phải kế hoạch.

  • D (xem phạm vi dự án) — ⚠ Elizabeth đã xác nhận công việc đang tiến triển đúng, ⚠ nên vấn đề không nằm ở phạm vi.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25704 ở lô này về kế hoạch tham gia bên liên quan và câu #25702 về bên liên quan tiêu cực. ⚠ Ba câu cùng chủ đề quản lý bên liên quan.

⚠ Phân biệt hai kế hoạch dễ lẫn: | Kế hoạch | Trả lời câu hỏi | |---|---| | ⚠ Communications management plan | ⚠ "gửi THÔNG TIN GÌ cho AI, qua KÊNH nào, TẦN SUẤT nào?" | | ⚠ Stakeholder engagement plan | ⚠ "muốn họ ở mức THAM GIA nào và làm gì để đạt được điều đó?" | | ⚠ Quan hệ | ⚠ kế hoạch giao tiếp là CÔNG CỤ thực thi chiến lược tham gia |

Từ khoá nhận diện:

"chuẩn bị làm việc với một bên liên quan cụ thể" → ⚠ stakeholder engagement plan "gửi báo cáo gì, tần suất nào" → ⚠ communications management plan "thông tin về bản thân bên liên quan" → ⚠ stakeholder register "rủi ro cụ thể của dự án" → ⚠ risk register, không phải risk management plan

⚠ Elizabeth nên chuẩn bị gì cho cuộc trò chuyện Chuẩn bị
⚠ Hiểu VÌ SAO người này quan tâm tới đúng công việc đó
⚠ Nắm sự thật: công việc đang tiến triển đúng ⚠ đã làm rồi
⚠ Chuẩn bị dữ liệu: tiến độ, chi phí, rủi ro của công việc đó
⚠ Xác định mức chi tiết phù hợp với người này
⚠ Chuẩn bị phương án nếu rủi ro trượt tiến độ trở thành thật
⚠ Đừng ⚠ vào cuộc trò chuyện chỉ với câu "đội bảo là ổn"
⚠ Vì sao bên liên quan bực dù dự án đúng tiến độ Nguyên nhân thường gặp
⚠ Họ không được thông tin đầy đủ ⚠ lỗ hổng trong kế hoạch giao tiếp
⚠ Họ nghe tin từ nguồn không chính thức
⚠ Công việc đó ảnh hưởng trực tiếp tới bộ phận của họ
⚠ Kỳ vọng của họ khác với thoả thuận ban đầu
⚠ Bài học ⚠ dự án đúng tiến độ mà bên liên quan vẫn bực nghĩa là vấn đề nằm ở GIAO TIẾP
⚠ Sau cuộc trò chuyện nên làm gì Việc
⚠ Cập nhật sổ đăng ký bên liên quan ⚠ thái độ và mối quan tâm mới
⚠ Điều chỉnh kế hoạch tham gia nếu cần
⚠ Nếu thiếu thông tin: sửa kế hoạch giao tiếp
⚠ Ghi rủi ro trượt tiến độ vào risk register nếu chưa có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết bên liên quan này quan tâm điều gì nhất không | | | Họ có nhận đủ thông tin theo kênh chính thức không | | | Mức tham gia hiện tại có khớp mức mong muốn không | |

Và điều Elizabeth làm đúng nhất: kiểm tra sự thật TRƯỚC khi trò chuyện. Bước còn thiếu chỉ là chuẩn bị cách nói — và đó chính là thứ kế hoạch tham gia bên liên quan được lập ra để trả lời.

Câu 5 People
You are the project manager of a software development project. Ripal is the technical architect for your software development team. He informs you that there is a new update to a universal coding language. The update to the coding language is used throughout the industry and heavily in the team's current project. What should you do next?
  1. A Instruct Ripal to inform other technical contributors of this change.
  2. B Bring this up in the planning stage of the next technical project.
  3. C Instruct Ripal to schedule a training session for the entire organization.
  4. D Submit a change request to refactor the codebase into this new coding language.
Xem giải thích

Đáp án

A — Yêu cầu Ripal thông báo cho các thành viên kỹ thuật khác về thay đổi này.

Vì sao đúng

⚠ Vì sao chia sẻ thông tin là bước đầu tiên: | Lý do | Nội dung | |---|---| | ⚠ Thông tin ẢNH HƯỞNG tới công việc đang làm | ⚠ ngôn ngữ này được dùng nhiều trong dự án hiện tại | | ⚠ Người kỹ thuật cần biết để ĐÁNH GIÁ tác động | | | ⚠ Chia sẻ tri thức là trách nhiệm của PM | ⚠ Manage Project Knowledge | | ⚠ Chưa đủ thông tin để quyết định lớn | ⚠ chưa biết cập nhật này ảnh hưởng thế nào | | ⚠ Nguyên tắc | ⚠ THÔNG TIN trước, ĐÁNH GIÁ sau, QUYẾT ĐỊNH cuối |

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

  • D (nộp yêu cầu thay đổi để viết lại toàn bộ mã sang ngôn ngữ mới) — ⚠ phản ứng CỰC ĐOAN và QUÁ SỚM: ⚠ chưa ai đánh giá xem cập nhật này có cần thiết không, ⚠ chi phí viết lại là bao nhiêu, ⚠ lợi ích có xứng đáng không.

  • C (yêu cầu Ripal tổ chức đào tạo cho TOÀN TỔ CHỨC) — ⚠ vượt xa phạm vi dự án: ⚠ PM không có thẩm quyền quyết định đào tạo toàn tổ chức, ⚠ và chưa chắc mọi bộ phận đều cần.

  • B (đưa vào giai đoạn lập kế hoạch của dự án kỹ thuật TIẾP THEO) — ⚠ BỎ QUA dự án hiện tại, ⚠ trong khi đề nói rõ ngôn ngữ này ⚠ đang được dùng nhiều trong dự án hiện tại.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25630 ở lô 177 về tri thức ẩn và câu #25625 về reverse shadowing. ⚠ Ba câu cùng thuộc quy trình Manage Project Knowledge.

⚠ Trình tự xử lý một thông tin kỹ thuật mới: | Bước | Việc | |---|---| | ⚠ 1. CHIA SẺ thông tin với người liên quan | ⚠ bước của câu này | | ⚠ 2. ĐÁNH GIÁ tác động tới dự án hiện tại | ⚠ có bắt buộc nâng cấp không? có lỗi bảo mật không? | | ⚠ 3. Nếu có tác động: đánh giá chi phí và lợi ích | | | ⚠ 4. Nếu cần đổi: nộp YÊU CẦU THAY ĐỔI | ⚠ phương án D là bước 4, không phải bước 1 | | ⚠ 5. Nếu không cần ngay: ghi vào bài học và cân nhắc cho dự án sau | ⚠ phương án B là bước 5 | | ⚠ Sai lầm | ⚠ nhảy thẳng từ bước 1 sang bước 4 |

Từ khoá nhận diện:

"bạn nên làm gì TIẾP THEO" → ⚠ thường là bước NHỎ NHẤT và ÍT RỦI RO nhất "nộp yêu cầu thay đổi ngay" → ⚠ thường là bẫy khi chưa có đánh giá "đào tạo toàn tổ chức" → ⚠ vượt thẩm quyền PM "chia sẻ thông tin cho người cần biết" → ⚠ hầu như luôn hợp lý

⚠ Những câu hỏi cần trả lời trước khi quyết Câu hỏi
⚠ Bản cũ có còn được hỗ trợ không ⚠ hết hỗ trợ là rủi ro bảo mật
⚠ Cập nhật này có bắt buộc không
⚠ Có lỗ hổng bảo mật nào được vá không ⚠ nếu có thì mức khẩn cấp khác hẳn
⚠ Chi phí chuyển đổi là bao nhiêu
⚠ Có phá vỡ tính tương thích không ⚠ breaking change
⚠ Ảnh hưởng tới lịch và ngân sách thế nào
⚠ Chỉ sau khi có câu trả lời ⚠ mới quyết định có nộp yêu cầu thay đổi hay không
⚠ Vai trò của Ripal — kiến trúc sư kỹ thuật Vai trò
⚠ Là CHUYÊN GIA về mặt kỹ thuật
⚠ Người phù hợp nhất để chia sẻ và giải thích cho đội
⚠ Người phù hợp nhất để đánh giá tác động kỹ thuật
⚠ PM làm gì ⚠ tạo điều kiện, không tự đánh giá thay chuyên gia

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông tin này ảnh hưởng tới ai | ⚠ chia sẻ đúng người, không phải toàn tổ chức | | Đã đánh giá tác động chưa | ⚠ trước khi nghĩ tới thay đổi | | Có yếu tố bảo mật hoặc tuân thủ nào không | ⚠ nếu có thì mức ưu tiên khác hẳn |

Và nguyên tắc chọn đáp án cho dạng câu "làm gì tiếp theo": chọn bước tiếp theo NHỎ NHẤT và HỢP LÝ NHẤT, không phải giải pháp cuối cùng. Đề thi PMP thưởng cho người biết dừng lại thu thập thông tin trước khi hành động lớn.

Câu 6 People
Jackson is a program manager whose department has recently merged with another. Although he has some knowledge of what the other department does, he is unaware of how much funding each project has within the department and the number of projects that are currently active. He requires this knowledge to ensure that his department's funding is consistent with the new projects and the projects his programs include. Which level of knowledge is required?
  1. A Individual-level
  2. B Project-level
  3. C Portfolio-level
  4. D Surface-level
Xem giải thích

Đáp án

C — Portfolio-level (mức DANH MỤC).

Vì sao đúng

⚠ Ba mức quản lý trong tổ chức: | Mức | Phạm vi | Câu hỏi trả lời | |---|---|---| | ⚠ PROJECT — dự án | ⚠ một dự án cụ thể | ⚠ "dự án này chạy thế nào?" | | ⚠ PROGRAM — chương trình | ⚠ nhóm dự án LIÊN QUAN, quản lý phối hợp để thu lợi ích chung | ⚠ "các dự án này phối hợp ra sao?" | | ⚠ PORTFOLIO — danh mục | ⚠ TOÀN BỘ dự án, chương trình và hoạt động của một đơn vị | ⚠ "chúng ta đang đầu tư vào những gì và bao nhiêu?" |

⚠ Jackson cần gì: | Nhu cầu | Thuộc mức nào | |---|---| | ⚠ Biết MỖI DỰ ÁN trong bộ phận có bao nhiêu kinh phí | ⚠ danh mục | | ⚠ Biết CÓ BAO NHIÊU dự án đang chạy | ⚠ danh mục | | ⚠ Đảm bảo kinh phí bộ phận NHẤT QUÁN với các dự án mới | ⚠ danh mục — đây là quyết định phân bổ nguồn lực | | ⚠ Kết luận | ⚠ anh ấy cần cái nhìn TOÀN CẢNH về danh mục sau khi sáp nhập |

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

  • B (Project-level) — ⚠ chỉ cho biết thông tin của MỘT dự án; ⚠ Jackson cần tổng thể nhiều dự án cùng lúc.

  • A (Individual-level) — ⚠ mức cá nhân, ⚠ hoàn toàn không phù hợp với câu hỏi về kinh phí và số lượng dự án.

  • D (Surface-level) — ⚠ không phải thuật ngữ quản lý dự án.

Ghi nhớ

⚠ So sánh ba mức — bảng cần thuộc: | Tiêu chí | Project | Program | Portfolio | |---|---|---|---| | ⚠ Phạm vi | ⚠ mục tiêu XÁC ĐỊNH, chi tiết hoá dần | ⚠ rộng hơn, nhiều dự án liên quan | ⚠ THAY ĐỔI theo chiến lược tổ chức | | ⚠ Thành công đo bằng | ⚠ sản phẩm, chất lượng, đúng hạn, đúng ngân sách | ⚠ LỢI ÍCH tổng hợp mang lại | ⚠ HIỆU SUẤT ĐẦU TƯ tổng thể của danh mục | | ⚠ Người quản lý | ⚠ quản lý DỰ ÁN | ⚠ quản lý CHƯƠNG TRÌNH | ⚠ quản lý DANH MỤC | | ⚠ Trọng tâm | ⚠ LÀM ĐÚNG dự án | ⚠ phối hợp giữa các dự án | ⚠ CHỌN ĐÚNG dự án để làm | | ⚠ Thay đổi | ⚠ kiểm soát chặt | ⚠ kỳ vọng và thích ứng | ⚠ theo dõi liên tục môi trường rộng |

Từ khoá nhận diện:

"tổng kinh phí, số lượng dự án đang chạy, phân bổ đầu tư" → ⚠ portfolio "nhóm dự án liên quan phối hợp để thu lợi ích chung" → ⚠ program "một dự án với mục tiêu cụ thể" → ⚠ project "chọn làm dự án nào" → ⚠ portfolio management "làm dự án cho đúng" → ⚠ project management

⚠ Vì sao sáp nhập bộ phận lại đặt ra vấn đề danh mục Lý do
⚠ Hai danh mục cũ nay thành một
⚠ Có thể có dự án TRÙNG LẶP hoặc XUNG ĐỘT mục tiêu
⚠ Nguồn lực phải phân bổ lại toàn bộ
⚠ Có dự án không còn phù hợp chiến lược mới ⚠ có thể phải huỷ
⚠ Việc đầu tiên cần làm ⚠ lập BẢN KIỂM KÊ đầy đủ: dự án nào, kinh phí bao nhiêu, đang ở giai đoạn nào
⚠ Quản lý danh mục làm gì Việc
⚠ CHỌN dự án và chương trình để đầu tư
⚠ ƯU TIÊN HOÁ theo giá trị chiến lược
⚠ PHÂN BỔ nguồn lực giữa các dự án
⚠ CÂN BẰNG rủi ro của cả danh mục
⚠ DỪNG dự án không còn phù hợp
⚠ Nguyên tắc ⚠ danh mục lo LÀM ĐÚNG VIỆC, dự án lo LÀM VIỆC ĐÚNG CÁCH

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có cái nhìn danh mục không | ⚠ hay mỗi dự án chạy riêng lẻ | | Có dự án nào trùng mục tiêu với dự án khác không | | | Dự án của bạn có còn phù hợp chiến lược hiện tại không | |

Và câu tóm gọn ba mức: danh mục chọn LÀM GÌ, chương trình phối hợp CÁC PHẦN, dự án thực hiện TỪNG PHẦN. Jackson đang ở đúng chỗ cần cái nhìn cao nhất.

Câu 7 People
As an agile team leader, Bianca involves the entire team when problem-solving. This sends what sort of message to the team?
  1. A The team leader does not trust one team member's solution.
  2. B The team leader doubts that the business partners have a resolution.
  3. C According to the team leader, members are capable of being supportive beyond their roles.
  4. D The team leader does not know the solution.
Xem giải thích

Đáp án

C — Theo người dẫn dắt, các thành viên có khả năng HỖ TRỢ VƯỢT RA NGOÀI vai trò của mình.

Vì sao đúng

⚠ Thông điệp khi kéo cả đội vào giải quyết vấn đề: | Thông điệp | Nội dung | |---|---| | ⚠ "Tôi TIN mọi người đóng góp được" | ⚠ kể cả ngoài chuyên môn hẹp của từng người | | ⚠ "Vấn đề này là của CẢ ĐỘI" | ⚠ không phải của riêng ai | | ⚠ "Góc nhìn khác nhau cho giải pháp tốt hơn" | | | ⚠ Xây dựng đội ĐA KỸ NĂNG | ⚠ cross-functional, đặc trưng của agile | | ⚠ Đây là | ⚠ hành vi của LÃNH ĐẠO PHỤC VỤ — tạo điều kiện thay vì ra lệnh |

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

  • A (người dẫn không tin giải pháp của một thành viên) — ⚠ diễn giải TIÊU CỰC và sai: ⚠ mời cả đội tham gia không có nghĩa là nghi ngờ ai.

  • D (người dẫn không biết giải pháp) — ⚠ cũng là diễn giải tiêu cực: ⚠ trong agile, ⚠ người dẫn dắt KHÔNG cần là người có mọi câu trả lời — ⚠ đó là điểm mạnh chứ không phải điểm yếu.

  • B (người dẫn nghi ngờ đối tác kinh doanh có giải pháp) — ⚠ không liên quan tới tình huống.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25721 ở lô này về đội tự tổ chức trong dự án thích ứng và câu #25663 ở lô 178 về lãnh đạo phục vụ. ⚠ Ba câu cùng khắc hoạ vai trò người dẫn dắt trong môi trường linh hoạt.

⚠ Lãnh đạo phục vụ — servant leadership: | Đặc điểm | Nội dung | |---|---| | ⚠ Đặt nhu cầu của ĐỘI lên trước | | | ⚠ GỠ TRỞ NGẠI thay vì giao việc | | | ⚠ Hỏi "đội cần gì" thay vì "đội phải làm gì" | | | ⚠ Tạo điều kiện để đội tự tìm ra giải pháp | ⚠ hành vi của Bianca | | ⚠ Phát triển năng lực của từng người | | | ⚠ Không phải | ⚠ buông lỏng hay thiếu định hướng — vẫn có trách nhiệm rất rõ |

Từ khoá nhận diện:

"kéo cả đội vào giải quyết vấn đề" → ⚠ tin tưởng và trao quyền "gỡ trở ngại cho đội" → ⚠ servant leadership "đội tự tổ chức" → ⚠ nguyên tắc nền của agile "người dẫn phải biết mọi câu trả lời" → ⚠ quan niệm CŨ, không phù hợp agile

⚠ Lợi ích của việc giải quyết vấn đề TẬP THỂ Lợi ích
⚠ Nhiều góc nhìn → giải pháp tốt hơn
⚠ Ai tham gia tìm ra giải pháp thì CAM KẾT thực hiện nó
⚠ Chia sẻ tri thức trong đội ⚠ giảm rủi ro "chỉ một người biết"
⚠ Xây dựng đội đa kỹ năng
⚠ Người trẻ học được cách tư duy của người có kinh nghiệm
⚠ Chi phí ⚠ tốn thời gian của nhiều người — không dùng cho mọi vấn đề nhỏ
⚠ Khi nào KHÔNG nên kéo cả đội vào Trường hợp
⚠ Vấn đề quá nhỏ, một người xử lý được trong vài phút
⚠ Tình huống KHẨN CẤP cần quyết ngay
⚠ Vấn đề nhạy cảm về nhân sự hoặc cá nhân
⚠ Nguyên tắc ⚠ quy mô của cuộc thảo luận phải tương xứng với quy mô của vấn đề
⚠ Đội đa kỹ năng — cross-functional team Đặc điểm
⚠ Có đủ mọi kỹ năng cần thiết để giao hàng ⚠ không phải chờ bộ phận khác
⚠ Mỗi người có chuyên môn chính nhưng hỗ trợ được lĩnh vực khác ⚠ mô hình "chữ T"
⚠ Giảm nút thắt cổ chai
⚠ Thông điệp của Bianca ⚠ chính là xây dựng văn hoá này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có mời đội tham gia giải quyết vấn đề không | ⚠ hay tự quyết rồi thông báo | | Đội có cảm thấy an toàn khi nêu ý kiến trái chiều không | | | Quy mô thảo luận có tương xứng với vấn đề không | |

Và điều đảo ngược quan niệm cũ về lãnh đạo: người dẫn dắt giỏi trong agile không phải người có mọi câu trả lời, mà là người tạo ra môi trường để đội tìm ra câu trả lời.

Câu 8 Process
Donny establishes a non-reprisal policy for anyone who identifies a potential problem during a project. Whenever such a problem is identified, Donny urges the person who identified it to contact him directly or anonymously via several platforms. Donny reviews the potential problem, investigates, and escalates the findings to the project stakeholders if there is evidence that the concern is valid. In these cases, the stakeholders work with Donny to resolve it. This is an example of which type of project governance?
  1. A Stage-gate or phase reviews
  2. B Capturing lessons learned
  3. C Identifying, escalating, and resolving risks
  4. D Defining roles and responsibilities
Xem giải thích

Đáp án

C — Nhận diện, leo thang và xử lý rủi ro (identifying, escalating, and resolving risks).

Vì sao đúng

⚠ Bóc tách những gì Donny làm: | Hành động | Ứng với bước nào | |---|---| | ⚠ Chính sách KHÔNG TRẢ ĐŨA cho người báo cáo vấn đề | ⚠ tạo điều kiện NHẬN DIỆN | | ⚠ Nhiều kênh liên hệ, kể cả ẨN DANH | ⚠ tạo điều kiện NHẬN DIỆN | | ⚠ Donny rà soát và ĐIỀU TRA | ⚠ phân tích | | ⚠ LEO THANG lên bên liên quan nếu có cơ sở | ⚠ ESCALATING | | ⚠ Bên liên quan phối hợp XỬ LÝ | ⚠ RESOLVING | | ⚠ Kết luận | ⚠ đây là một cơ chế quản trị dự án hoàn chỉnh về rủi ro |

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

  • A (rà soát cổng giai đoạn — stage-gate) — ⚠ là các điểm rà soát ĐỊNH KỲ ở cuối mỗi giai đoạn, ⚠ trong khi cơ chế của Donny hoạt động ⚠ LIÊN TỤC, bất cứ lúc nào có người phát hiện vấn đề.

  • B (thu thập bài học kinh nghiệm) — ⚠ là ghi lại điều đã học được, ⚠ không phải cơ chế phát hiện và xử lý vấn đề đang diễn ra.

  • D (xác định vai trò và trách nhiệm) — ⚠ là việc phân vai trong dự án, ⚠ không mô tả cơ chế này.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25676 ở lô này về kỹ thuật Delphi — ⚠ ở đó cũng dùng ẩn danh để vượt qua nỗi sợ chính trị nội bộ. ⚠ Hai câu cùng một nguyên tắc: rủi ro nguy hiểm nhất là rủi ro không ai dám nói ra.

⚠ Bốn cơ chế quản trị dự án điển hình: | Cơ chế | Nội dung | |---|---| | ⚠ Stage-gate / phase reviews | ⚠ rà soát ĐỊNH KỲ ở cuối giai đoạn, quyết định đi tiếp hay dừng | | ⚠ Capturing lessons learned | ⚠ ghi lại và chia sẻ tri thức | | ⚠ Identifying, escalating, resolving risks | ⚠ cơ chế LIÊN TỤC phát hiện và xử lý rủi ro — CÂU NÀY | | ⚠ Defining roles and responsibilities | ⚠ phân vai rõ ràng, ai quyết gì |

Từ khoá nhận diện:

"không trả đũa, kênh ẩn danh, khuyến khích báo cáo" → ⚠ cơ chế nhận diện rủi ro "chuyển lên cấp cao hơn khi vượt thẩm quyền" → ⚠ escalating "rà soát cuối giai đoạn" → ⚠ stage-gate "ghi lại điều đã học" → ⚠ lessons learned

⚠ Vì sao chính sách KHÔNG TRẢ ĐŨA lại quan trọng Lý do
⚠ Rủi ro lớn nhất thường là rủi ro KHÔNG AI DÁM NÓI
⚠ Người phát hiện sớm nhất thường là người ở tuyến dưới ⚠ họ có ít quyền lực nhất
⚠ Sợ bị trách thì người ta im lặng và hy vọng vấn đề tự hết
⚠ Vấn đề phát hiện muộn luôn đắt hơn
⚠ Kênh ẩn danh ⚠ là lưới an toàn cho những trường hợp nhạy cảm nhất
⚠ Escalation — leo thang khi nào Khi nào
⚠ Vấn đề VƯỢT THẨM QUYỀN của quản lý dự án
⚠ Cần nguồn lực mà PM không có quyền cấp
⚠ Ảnh hưởng tới nhiều dự án hoặc cả tổ chức
⚠ Rủi ro ở mức tổ chức chứ không phải mức dự án ⚠ PMBOK 6 gọi đây là chiến lược ESCALATE
⚠ Sau khi leo thang ⚠ rủi ro đó KHÔNG còn do PM theo dõi nữa, nhưng vẫn nên ghi nhận để biết
⚠ Đặc điểm của một cơ chế báo cáo tốt Đặc điểm
⚠ NHIỀU kênh, có kênh ẩn danh
⚠ Cam kết KHÔNG trả đũa, và giữ đúng cam kết đó ⚠ một lần vi phạm là mất niềm tin vĩnh viễn
⚠ Có người CHỊU TRÁCH NHIỆM rà soát ⚠ Donny
⚠ Có PHẢN HỒI cho người báo cáo ⚠ báo mà không thấy gì xảy ra thì lần sau không ai báo
⚠ Có ĐƯỜNG leo thang rõ ràng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có dám báo tin xấu không | ⚠ thử hỏi thẳng, câu trả lời rất đáng suy nghĩ | | Có kênh ẩn danh không | | | Người báo cáo có nhận được phản hồi không | |

Và câu nói đáng nhớ về quản trị rủi ro: dự án không chết vì rủi ro nó biết, mà chết vì rủi ro có người biết nhưng không ai dám nói. Cơ chế của Donny sinh ra để đóng đúng khoảng trống đó.

Câu 9 People
As a requirement for Amira's latest project at Phillips Logistics, she must use earned value management. The end result of earned value management adds to the requirements and targets for reporting performance. Of the choices below, which one does performance reporting not generally provide information for?
  1. A Scope
  2. B Labor issues
  3. C Quality
  4. D Schedule
Xem giải thích

Đáp án

B — Labor issues (các vấn đề về nhân sự).

Vì sao đúng

⚠ Báo cáo hiệu suất cung cấp thông tin về gì: | Lĩnh vực | Đo bằng gì | |---|---| | ⚠ PHẠM VI | ⚠ phần trăm hoàn thành, bàn giao đã nghiệm thu, SV, SPI | | ⚠ LỊCH TRÌNH | ⚠ SV, SPI, tình trạng mốc, dự báo ngày hoàn thành | | ⚠ CHI PHÍ | ⚠ CV, CPI, EAC, ETC, VAC | | ⚠ CHẤT LƯỢNG | ⚠ số khuyết tật, tỷ lệ làm lại, kết quả kiểm thử | | ⚠ RỦI RO | ⚠ rủi ro mới, rủi ro đã xảy ra, mức tiêu dự phòng | | ⚠ VẤN ĐỀ NHÂN SỰ | ⚠ KHÔNG — đây là chuyện quản lý con người, không phải chỉ số hiệu suất dự án |

⚠ Vì sao nhân sự không thuộc báo cáo hiệu suất: | Lý do | Nội dung | |---|---| | ⚠ Là vấn đề CÁ NHÂN và NHẠY CẢM | ⚠ xung đột, hiệu suất từng người, kỷ luật | | ⚠ Không đo được bằng EVM | | | ⚠ Thuộc về quản lý đội và quản lý chức năng | | | ⚠ Đưa vào báo cáo phát rộng là vi phạm quyền riêng tư | | | ⚠ Nếu ảnh hưởng tới dự án | ⚠ báo cáo TÁC ĐỘNG (lịch chậm, chi phí tăng), không báo cáo chuyện cá nhân |

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

  • A (Scope), C (Quality), D (Schedule) — ⚠ cả ba ĐỀU là nội dung tiêu chuẩn của báo cáo hiệu suất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25629 ở lô 177 về ba tầng dữ liệu: data → information → report. ⚠ Báo cáo hiệu suất chính là tầng thứ ba.

⚠ Ba tầng dữ liệu — nhắc lại: | Tầng | Nội dung | |---|---| | ⚠ Work performance DATA | ⚠ số liệu thô: đã xong 5/10 hạng mục, đã chi 500 triệu | | ⚠ Work performance INFORMATION | ⚠ đã phân tích: SPI = 0,83, chậm 17% | | ⚠ Work performance REPORTS | ⚠ đóng gói để gửi bên liên quan — CÂU NÀY |

⚠ Một báo cáo hiệu suất tốt gồm gì: | Mục | Nội dung | |---|---| | ⚠ Tóm tắt tình hình chung | ⚠ xanh/vàng/đỏ | | ⚠ Tiến độ so với ĐƯỜNG CƠ SỞ | ⚠ SV, SPI | | ⚠ Chi phí so với đường cơ sở | ⚠ CV, CPI | | ⚠ DỰ BÁO | ⚠ EAC, ETC, VAC, ngày hoàn thành dự kiến | | ⚠ Tình trạng phạm vi và bàn giao | | | ⚠ Chỉ số chất lượng | | | ⚠ Rủi ro và vấn đề nổi bật | | | ⚠ Hành động cần quyết định | ⚠ mục quan trọng nhất mà hay bị quên |

Từ khoá nhận diện:

"phạm vi, lịch, chi phí, chất lượng, rủi ro" → ⚠ có trong báo cáo hiệu suất "xung đột trong đội, hiệu suất cá nhân" → ⚠ KHÔNG có trong báo cáo hiệu suất "EVM" → ⚠ cung cấp số liệu cho báo cáo hiệu suất "số liệu thô chưa phân tích" → ⚠ work performance data, chưa phải báo cáo

⚠ Nếu vấn đề nhân sự THẬT SỰ ảnh hưởng dự án thì sao Cách xử lý
⚠ Báo cáo TÁC ĐỘNG, không báo cáo chi tiết cá nhân ⚠ "hoạt động X chậm 3 ngày do thiếu nguồn lực"
⚠ Ghi vào ISSUE LOG nếu là vấn đề đang xảy ra
⚠ Trao đổi RIÊNG với quản lý chức năng
⚠ Nếu là rủi ro nguồn lực: ghi vào risk register
⚠ Đừng ⚠ nêu tên người trong báo cáo phát cho nhiều bên liên quan
⚠ Nguyên tắc về mức chi tiết của báo cáo Nguyên tắc
⚠ Lãnh đạo cấp cao: tóm tắt, xu hướng, quyết định cần xin
⚠ Quản lý cấp trung: chi tiết hơn, có phân tích
⚠ Đội dự án: chi tiết đầy đủ
⚠ Cùng dữ liệu ⚠ nhưng đóng gói khác nhau — đó là ý nghĩa của bước "report"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo của bạn có phần "cần quyết định gì" không | | | Có thông tin cá nhân nhạy cảm nào lọt vào không | | | Mức chi tiết có phù hợp người nhận không | |

Và ranh giới cần giữ: báo cáo hiệu suất nói về DỰ ÁN, không nói về CON NGƯỜI. Vấn đề nhân sự có ảnh hưởng thì báo cáo tác động của nó, còn chuyện của từng người thì xử lý riêng.

Câu 10 People
Marsha recently joined a massive organization as a project manager. Because this is a sizeable institutional organization, she has trouble connecting with her project team members, who have been established in their role for several years before Marsha joined. Team members know their jobs and have little need for guidance. Marsha learns from another project manager that her team members do not like being told what to do. Their last project manager was not respected because he was ego-driven and arrogant with the team. Marsha wants to earn the respect of her project team, take them to the next level, and not interrupt the good things that they are already doing. What kind of leadership style can she adopt to accomplish this?
  1. A Servant leadership
  2. B Autocratic
  3. C Directing
  4. D Laissez-Faire
Xem giải thích

Đáp án

A — Servant leadership (lãnh đạo phục vụ).

Vì sao đúng

⚠ Bốn dấu hiệu trong đề đều dẫn tới lãnh đạo phục vụ: | Dấu hiệu | Nội dung | |---|---| | ⚠ Đội đã LÀM TỐT nhiều năm, biết rõ việc của mình | ⚠ không cần hướng dẫn chi tiết | | ⚠ Họ KHÔNG THÍCH bị sai bảo | ⚠ loại ngay phong cách chỉ đạo và độc đoán | | ⚠ Người quản lý trước bị ghét vì TỰ CAO và ĐỘC ĐOÁN | ⚠ bài học rõ ràng về việc nên tránh gì | | ⚠ Marsha muốn giành sự tôn trọng và KHÔNG phá vỡ những gì đang tốt | | | ⚠ Kết luận | ⚠ lãnh đạo phục vụ là phong cách phù hợp nhất: gỡ vướng, hỗ trợ, tin tưởng đội |

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

  • B (Autocratic — độc đoán) — ⚠ chính là phong cách của người quản lý trước ⚠ đã khiến đội ghét bỏ; ⚠ lặp lại là sai lầm rõ ràng nhất.

  • C (Directing — chỉ đạo) — ⚠ phù hợp với đội MỚI, chưa có kinh nghiệm; ⚠ áp lên đội lâu năm và giỏi việc sẽ gây phản ứng.

  • D (Laissez-Faire — buông lỏng) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe giống "không can thiệp", ⚠ nhưng buông lỏng là ⚠ KHÔNG hỗ trợ, không định hướng, không có mặt khi cần; ⚠ Marsha muốn ⚠ "đưa đội lên tầm cao mới" — ⚠ điều đó đòi hỏi sự tham gia CHỦ ĐỘNG, không phải bỏ mặc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25729 ở lô này về lãnh đạo phục vụ trong đội agile, câu #25588 ở lô 177 về laissez-faire, và câu #25663 ở lô 178 về quản lý so với lãnh đạo. ⚠ Bốn câu hợp thành bộ đầy đủ về phong cách lãnh đạo.

⚠ Servant leadership và laissez-faire — khác nhau ở đâu: | Tiêu chí | Servant leadership | Laissez-faire | |---|---|---| | ⚠ Mức tham gia | ⚠ CHỦ ĐỘNG hỗ trợ và gỡ vướng | ⚠ KHÔNG can thiệp, để mặc | | ⚠ Có mặt khi đội cần | ⚠ CÓ | ⚠ thường KHÔNG | | ⚠ Phát triển năng lực đội | ⚠ CÓ, là mục tiêu chính | ⚠ KHÔNG chủ động | | ⚠ Kết quả với đội giỏi | ⚠ đội phát triển thêm | ⚠ đội giữ nguyên hoặc trôi dạt | | ⚠ Điểm giống | ⚠ cả hai đều KHÔNG ra lệnh chi tiết — đó là chỗ dễ nhầm |

⚠ Các phong cách lãnh đạo hay ra thi: | Phong cách | Đặc điểm | Phù hợp khi | |---|---|---| | ⚠ Directing / Autocratic | ⚠ ra lệnh, quyết định một mình | ⚠ khủng hoảng, đội mới, cần quyết nhanh | | ⚠ Coaching | ⚠ hướng dẫn và giải thích | ⚠ đội đang học, giai đoạn Storming | | ⚠ Supporting / Participative | ⚠ cùng bàn bạc, chia sẻ quyết định | ⚠ đội đã có năng lực | | ⚠ Delegating | ⚠ giao toàn quyền, theo dõi kết quả | ⚠ đội trưởng thành | | ⚠ Servant leadership | ⚠ phục vụ đội, gỡ trở ngại | ⚠ đội tự tổ chức, môi trường agile — CÂU NÀY | | ⚠ Laissez-faire | ⚠ không can thiệp | ⚠ hiếm khi phù hợp; dễ bị hiểu là bỏ mặc | | ⚠ Transformational | ⚠ truyền cảm hứng, tạo tầm nhìn | ⚠ cần thay đổi lớn | | ⚠ Transactional | ⚠ thưởng phạt theo kết quả | ⚠ công việc lặp lại, đo được rõ |

Từ khoá nhận diện:

"đội giỏi, ghét bị sai bảo, muốn giành tôn trọng" → ⚠ servant leadership "không can thiệp gì cả" → ⚠ laissez-faire "ra lệnh, quyết một mình" → ⚠ autocratic "đội mới, chưa biết việc" → ⚠ directing hoặc coaching

⚠ Marsha nên làm gì cụ thể Việc
⚠ LẮNG NGHE trước, đừng vội thay đổi gì ⚠ "không phá vỡ những gì đang tốt"
⚠ Hỏi đội: điều gì đang cản trở các bạn?
⚠ GỠ những trở ngại đó ⚠ cách nhanh nhất để giành sự tôn trọng
⚠ Bảo vệ đội khỏi can thiệp từ bên ngoài
⚠ Ghi nhận công khai thành quả của đội
⚠ Chỉ thay đổi khi đã hiểu vì sao mọi thứ đang như vậy
⚠ Tuyệt đối tránh ⚠ áp quy trình mới ngay tuần đầu để "thể hiện quyền uy"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn ở mức trưởng thành nào | ⚠ quyết định phong cách phù hợp | | Bạn đang gỡ vướng hay đang tạo thêm vướng | | | Bạn đã lắng nghe đủ trước khi thay đổi chưa | |

Và cách nhanh nhất để một quản lý dự án mới giành được sự tôn trọng của đội lâu năm: hỏi họ đang vướng gì, rồi gỡ đúng thứ đó. Không có bài phát biểu hay quy trình mới nào hiệu quả bằng.