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

Tìm thấy 718 câu.

Câu 241 People
Aubry is the project manager for Project OIC, which is currently moving through initial planning for the project work. This project is expected to last six months and will span several regions of the United States. Aubry has gathered the project team for their first planning meeting as an entire team. In addition to an outline of Project OIC, what else should Aubry cover during this meeting?
  1. A How to file expenses
  2. B Team introductions
  3. C The project ground rules
  4. D The team vacation policy
Xem giải thích

Đáp án

B — GIỚI THIỆU CÁC THÀNH VIÊN TRONG ĐỘI (team introductions).

Vì sao đúng

⚠ Chi tiết quyết định nằm trong đề: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ "cuộc họp lập kế hoạch ĐẦU TIÊN với cả đội" | ⚠ lần đầu tiên mọi người ngồi cùng nhau | | ⚠ Dự án trải RỘNG NHIỀU VÙNG của nước Mỹ | ⚠ nhiều người chưa từng gặp nhau | | ⚠ Đề đã nói Aubry sẽ trình bày khái quát dự án | ⚠ nên câu hỏi tìm thứ CÒN THIẾU | | ⚠ Đội đang ở giai đoạn HÌNH THÀNH (forming) | ⚠ việc của giai đoạn này là làm quen | | ⚠ Kết luận | ⚠ không ai cộng tác được với người mình chưa biết tên và chưa biết làm gì |

⚠ Vì sao đây là việc quan trọng chứ không phải thủ tục xã giao: ⚠ giới thiệu không chỉ là nói tên — nó là nói VAI TRÒ, CHUYÊN MÔN và VÙNG mình phụ trách; ⚠ với một đội phân tán, đó là bản đồ để sau này biết cần hỏi ai về việc gì.

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

  • C (quy tắc ứng xử của dự án — project ground rules) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ quy tắc ứng xử đúng là một nội dung của giai đoạn khởi động đội, và PMBOK nhắc tới nó ngay trong bản hiến chương đội: ⚠ nhưng ⚠ quy tắc ứng xử được XÂY DỰNG CÙNG NHAU chứ không phải đọc cho nghe ⚠ — ⚠ và người ta không thoả thuận nổi cách làm việc với nhau khi còn chưa biết nhau là ai; ⚠ giới thiệu đứng trước, quy tắc đứng sau — thường ngay trong cùng buổi hoặc buổi kế tiếp.

  • A (cách kê khai chi phí công tác) — ⚠ việc hành chính; ⚠ có thể gửi bằng email, không xứng chỗ trong buổi họp đầu tiên của cả đội.

  • D (chính sách nghỉ phép) — ⚠ thuộc về nhân sự và quản lý chức năng, không phải nội dung lập kế hoạch dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26469 lô 194 và ⚠ #26537 lô 196 (năm rối loạn của Lencioni — tin cậy là tầng nền), ⚠ #26562 lô 196 (đón thành viên mới), ⚠ #26652 lô 198 (giai đoạn trước khi dự án khởi động), ⚠ #26649 lô 198 (họp video thường xuyên cho đội phân tán).

⚠ HỌP KHỞI ĐỘNG ĐỘI — thứ tự nội dung hợp lý: | Thứ tự | Nội dung | |---|---| | ⚠ 1. Giới thiệu — ai là ai, làm gì, ở đâu | ⚠ ĐÁP ÁN — nền của mọi thứ sau đó | | ⚠ 2. Mục tiêu và phạm vi tổng quát | ⚠ Aubry đã có trong kế hoạch | | ⚠ 3. Vai trò và trách nhiệm | ⚠ ai quyết cái gì | | ⚠ 4. Quy tắc ứng xử của đội | ⚠ xây cùng nhau — phương án C thuộc bước này | | ⚠ 5. Cách giao tiếp và nhịp họp | ⚠ đặc biệt quan trọng với đội phân tán nhiều múi giờ | | ⚠ 6. Bước tiếp theo | | | ⚠ Vì sao thứ tự này | ⚠ mỗi bước dựa trên bước trước: người ta chỉ thoả thuận được quy tắc khi đã biết nhau, và chỉ nhận trách nhiệm khi đã hiểu mục tiêu |

⚠ MÔ HÌNH TUCKMAN — Aubry đang ở đâu: | Giai đoạn | Đặc điểm | Việc của người dẫn dắt | |---|---|---| | ⚠ HÌNH THÀNH (forming) | ⚠ lịch sự, dè dặt, chưa biết nhau — CHÍNH LÀ ĐÂY | ⚠ giới thiệu, làm rõ mục tiêu, tạo an toàn | | ⚠ SÓNG GIÓ (storming) | ⚠ va chạm về cách làm và vai trò | ⚠ hoà giải, nhắc quy tắc chung | | ⚠ ỔN ĐỊNH (norming) | ⚠ hình thành thói quen làm việc chung | ⚠ củng cố, lùi lại một bước | | ⚠ HIỆU SUẤT (performing) | ⚠ đội tự vận hành | ⚠ gỡ vật cản, bảo vệ đội | | ⚠ GIẢI THỂ (adjourning) | ⚠ kết thúc, chia tay | ⚠ ghi nhận, tổng kết bài học | | ⚠ Ghi nhớ cho đề thi | ⚠ hỏi "đội vừa được lập" thì mọi đáp án đúng đều xoay quanh việc LÀM QUEN và LÀM RÕ, không phải việc kiểm soát |

⚠ Với đội trải nhiều vùng, phần giới thiệu nên có thêm: | Nội dung | Vì sao | |---|---| | ⚠ Múi giờ và giờ làm việc của mỗi người | ⚠ để không ai bị họp lúc nửa đêm | | ⚠ Kênh liên lạc ưa dùng của từng người | ⚠ liên hệ #26641 lô 198 | | ⚠ Chuyên môn và kinh nghiệm liên quan | ⚠ để biết hỏi ai khi vướng | | ⚠ Một chi tiết cá nhân nhỏ | ⚠ thứ tạo ra sự gắn kết mà bảng phân vai không tạo được | | ⚠ Nhận xét | ⚠ đội phân tán mất đi những cuộc trò chuyện tình cờ ở hành lang — nên thứ mà đội cùng chỗ có được miễn phí, đội phân tán phải chủ động tạo ra |

Từ khoá nhận diện:

"họp lần đầu, đội vừa tập hợp" → ⚠ GIỚI THIỆU THÀNH VIÊN "quy tắc ứng xử" → ⚠ xây cùng nhau, sau khi đã biết nhau "kê khai chi phí, chính sách nghỉ phép" → ⚠ việc hành chính, không thuộc họp lập kế hoạch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi người trong đội bạn có biết nhau làm gì không | ⚠ hỏi thử một người về vai trò của người khác | | Buổi họp đầu tiên của bạn dành bao nhiêu phút cho việc làm quen | | | Đội phân tán của bạn có kênh nào để trò chuyện ngoài công việc không | |

Và điều mà một vòng giới thiệu tưởng chừng hình thức thật sự làm được: nó biến một danh sách tên trong lịch họp thành một nhóm người biết mình có thể gọi cho ai khi mọi thứ bắt đầu khó.

Câu 242 People
You are the project manager of a large, complex project that will utilize resources from contracting agencies. Management has tasked you with writing the statement of work, defining the requirements to hire contractors and approve invoices for the project. What is it called when a project manager assumes purchasing authority and can sign contracts directly?
  1. A Decentralized contracting
  2. B Intentional contracting
  3. C Centralized contracting
  4. D Purchase agreements
Xem giải thích

Đáp án

A — MUA SẮM PHI TẬP TRUNG (decentralized contracting).

Vì sao đúng

⚠ Hai mô hình tổ chức việc mua sắm: | Mô hình | Đặc điểm | |---|---| | ⚠ PHI TẬP TRUNG (decentralized) | ⚠ quản lý dự án CÓ thẩm quyền mua sắm, ký hợp đồng trực tiếp — ĐÁP ÁN | | ⚠ TẬP TRUNG (centralized) | ⚠ có phòng mua sắm riêng; quản lý dự án phải qua họ | | ⚠ Trong đề: bạn viết SOW, định yêu cầu thuê nhà thầu và DUYỆT HOÁ ĐƠN | ⚠ đó là thẩm quyền mua sắm nằm trong tay người quản lý dự án | | ⚠ Kết luận | ⚠ quyền ký hợp đồng nằm ở dự án chứ không ở một phòng ban trung tâm |

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

  • C (mua sắm TẬP TRUNG) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là đúng cặp đối lập, và nhiều người nhớ nhầm chiều — "tập trung" nghe như "toàn quyền": ⚠ nhưng ⚠ "tập trung" nói về việc THẨM QUYỀN ĐƯỢC GOM VỀ MỘT PHÒNG MUA SẮM, không phải gom vào tay người quản lý dự án ⚠ — ⚠ trong mô hình đó, quản lý dự án phải nộp yêu cầu và chờ phòng mua sắm ký; ⚠ mẹo nhớ: hỏi "quyền nằm ở TRUNG TÂM hay ở DỰ ÁN" — ở dự án là phi tập trung.

  • B (intentional contracting) — ⚠ thuật ngữ bịa, không có trong PMBOK.

  • D (thoả thuận mua hàng — purchase agreements) — ⚠ tên một LOẠI VĂN BẢN, không phải tên của mô hình tổ chức thẩm quyền.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26558 lô 196 (các loại hợp đồng), ⚠ #26678 lô 198 (đàm phán theo nguyên tắc), ⚠ #26673 lô 198 (làm việc với nhiều nhà cung cấp), ⚠ #26705 cùng lô (cắt phạm vi khi hợp đồng đã ký), ⚠ #26718 cùng lô (hai yếu tố bắt buộc của hợp đồng).

⚠ Ưu và nhược của hai mô hình: | Mô hình | Ưu | Nhược | |---|---|---| | ⚠ PHI TẬP TRUNG | ⚠ nhanh, quản lý dự án chủ động, hiểu rõ nhu cầu dự án | ⚠ thiếu chuẩn hoá, dễ sai luật, mất lợi thế đàm phán quy mô, khó phát triển chuyên môn mua sắm | | ⚠ TẬP TRUNG | ⚠ chuyên môn sâu, chuẩn hoá, đàm phán được giá tốt nhờ khối lượng | ⚠ chậm, phòng mua sắm không hiểu đặc thù dự án, quản lý dự án phải xếp hàng chờ | | ⚠ Hệ quả cho người quản lý dự án | ⚠ ở mô hình phi tập trung, bạn phải TỰ BIẾT luật mua sắm và quy định của tổ chức — không có ai đứng sau kiểm giúp bạn nữa |

⚠ Bạn đang phải làm ba việc trong đề — chúng thuộc quy trình nào: | Việc | Quy trình | |---|---| | ⚠ Viết TUYÊN BỐ CÔNG VIỆC (SOW) | ⚠ Lập kế hoạch quản lý mua sắm | | ⚠ Xác định yêu cầu để thuê nhà thầu | ⚠ Lập kế hoạch — tiêu chí lựa chọn nguồn | | ⚠ Duyệt hoá đơn | ⚠ Kiểm soát mua sắm — quản trị hợp đồng | | ⚠ Nhận xét | ⚠ ba việc này trải khắp vòng đời mua sắm, và việc một người làm cả ba chính là dấu hiệu rõ nhất của mô hình phi tập trung |

⚠ Tuyên bố công việc (SOW) cần có gì: | Mục | Nội dung | |---|---| | ⚠ Đặc tả công việc cần mua | ⚠ đủ rõ để nhà cung cấp báo giá được | | ⚠ Sản phẩm bàn giao và tiêu chí nghiệm thu | | | ⚠ Mốc thời gian | | | ⚠ Địa điểm thực hiện và yêu cầu tuân thủ | | | ⚠ Cách báo cáo và cách thanh toán | ⚠ gắn với việc duyệt hoá đơn ở trên | | ⚠ Nguyên tắc | ⚠ SOW mơ hồ là nguồn gốc của gần như mọi tranh chấp hợp đồng về sau — mọi chỗ bạn ngại viết rõ hôm nay sẽ thành chỗ hai bên hiểu khác nhau vào tháng thứ tư |

Từ khoá nhận diện:

"quản lý dự án tự ký hợp đồng" → ⚠ MUA SẮM PHI TẬP TRUNG "có phòng mua sắm riêng, phải qua họ" → ⚠ mua sắm tập trung "intentional contracting" → ⚠ thuật ngữ bịa "purchase agreement" → ⚠ tên một loại văn bản, không phải mô hình thẩm quyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn theo mô hình nào | ⚠ hỏi ai là người ký được hợp đồng thay dự án | | Bạn có biết hạn mức chi mình được tự quyết không | | | SOW gần nhất của bạn có tiêu chí nghiệm thu đo được không | |

Và điều đáng nhớ về quyền ký hợp đồng: nó là thứ đi liền với trách nhiệm — ở nơi bạn được tự ký, bạn cũng là người phải trả lời khi bản hợp đồng ấy có chỗ sai.

Câu 243 Process
Tony is the project manager for Project Yang at the Building Corporation. Project Yang is part of a more extensive program and is currently on schedule and budget. The project timeline has crucial activities that must be completed within specific dates, or the project will be delayed. Several members of his project team are shared with other projects related to the program. What should Tony do to ensure his team members are available for Project Yang?
  1. A Coordinate with the other project managers to ensure his team member's availability works for everyone.
  2. B Tell his team members to tell the other projects they are taking a vacation but work on Project Y.
  3. C Block his team member's time off on the other projects scheduled.
  4. D Wait for the project management office to assign him resources.
Xem giải thích

Đáp án

A — PHỐI HỢP VỚI CÁC QUẢN LÝ DỰ ÁN KHÁC để lịch của thành viên phù hợp với tất cả các bên.

Vì sao đúng

⚠ Vì sao đây là cách đúng: | Lý do | Nội dung | |---|---| | ⚠ Các dự án cùng thuộc MỘT CHƯƠNG TRÌNH | ⚠ mục tiêu chung, nên hợp tác chứ không tranh giành | | ⚠ Thành viên dùng chung giữa nhiều dự án | ⚠ không ai được quyền chiếm riêng | | ⚠ Tony có ngày cố định phải hoàn thành | ⚠ cần báo trước để người khác sắp xếp | | ⚠ Phối hợp giải quyết được nguyên nhân, không chỉ triệu chứng | | | ⚠ Giữ được quan hệ với đồng nghiệp cùng chương trình | ⚠ bạn còn cần họ ở lần sau | | ⚠ Kết luận | ⚠ thương lượng minh bạch, sớm và cùng nhau — đó là công cụ thật của quản lý dự án trong môi trường nguồn lực dùng chung |

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

  • C (tự khoá lịch của thành viên trên các dự án khác) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó nghe như hành động chủ động và dứt khoát để bảo vệ tiến độ, kiểu "người quản lý dự án quyết đoán": ⚠ nhưng ⚠ đó là hành động ĐƠN PHƯƠNG chiếm nguồn lực của dự án khác mà không hỏi ai ⚠ — ⚠ nó phá vỡ tiến độ của đồng nghiệp, phá vỡ lòng tin trong chương trình, và lần sau sẽ có người làm y như vậy với bạn; ⚠ quyết đoán không đồng nghĩa với đơn phương.

  • B (bảo thành viên nói dối là đang nghỉ phép) — ⚠ vi phạm quy tắc đạo đức của PMI: trung thực; ⚠ đây là phương án loại ngay.

  • D (chờ văn phòng quản lý dự án phân người) — ⚠ bị động; ⚠ đề nói mốc thời gian là then chốt, chờ đợi là để rủi ro thành hiện thực.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26680 lô 198 (bị rút nguồn lực trong ma trận yếu), ⚠ #26533 lô 196 (thoả thuận nguồn lực dùng chung), ⚠ #26653 lô 198 (thông tin về mức sẵn có của nguồn lực), ⚠ #26621 lô 197 (nói chuyện trực tiếp trước khi leo thang), ⚠ #26732 cùng lô (vai trò quản lý dự án trong ma trận yếu).

⚠ Nguồn lực dùng chung — thang xử lý theo thứ tự: | Bậc | Việc | |---|---| | ⚠ 1. PHỐI HỢP với các quản lý dự án khác | ⚠ ĐÁP ÁN — rẻ nhất, nhanh nhất, giữ được quan hệ | | ⚠ 2. Thoả thuận lịch bằng văn bản | ⚠ để không ai nhớ khác nhau về sau | | ⚠ 3. Đưa lên quản lý CHƯƠNG TRÌNH nếu không thoả thuận được | ⚠ họ có toàn cảnh và có quyền ưu tiên | | ⚠ 4. Điều chỉnh tiến độ hoặc tìm nguồn lực thay thế | | | ⚠ Điều KHÔNG bao giờ làm | ⚠ tự ý chiếm chỗ (phương án C) hoặc nói dối (phương án B) — cả hai đều giải quyết được vấn đề tuần này và tạo ra một vấn đề lớn hơn cho cả năm |

⚠ Vì sao "cùng một chương trình" là chi tiết quan trọng: | Ý nghĩa | Nội dung | |---|---| | ⚠ Chương trình có mục tiêu lợi ích chung | ⚠ dự án của Tony trễ thì cả chương trình chịu | | ⚠ Có người quản lý chương trình đứng trên để phân xử | ⚠ kênh leo thang rõ ràng khi cần | | ⚠ Các quản lý dự án là đồng nghiệp, không phải đối thủ | ⚠ họ cũng chịu áp lực giống Tony | | ⚠ Tối ưu cục bộ có thể làm hại tổng thể | ⚠ giành được người cho mình mà làm dự án song song trễ thì chương trình không được lợi gì | | ⚠ Ghi nhớ cho đề thi | ⚠ thấy chữ "chương trình" là biết đáp án đúng nghiêng về HỢP TÁC và về LỢI ÍCH TỔNG THỂ, không nghiêng về việc bảo vệ dự án của riêng mình |

⚠ Chuẩn bị gì cho cuộc phối hợp: | Việc | Nội dung | |---|---| | ⚠ Xác định chính xác ngày nào cần ai, bao nhiêu giờ | ⚠ nói bằng lịch cụ thể, không nói "tôi cần họ nhiều" | | ⚠ Biết hoạt động nào là then chốt, hoạt động nào linh động | ⚠ để có chỗ nhượng bộ | | ⚠ Hỏi nhu cầu của phía bên kia trước | ⚠ liên hệ #26678 lô 198 | | ⚠ Đề xuất phương án chia thời gian, không chỉ nêu nhu cầu | | | ⚠ Ghi lại thoả thuận và gửi cho tất cả | | | ⚠ Lời khuyên | ⚠ làm việc này SỚM, ngay khi lập tiến độ — thương lượng nguồn lực vào tuần trước hạn thì bạn không còn gì để thương lượng nữa |

Từ khoá nhận diện:

"nguồn lực dùng chung giữa các dự án cùng chương trình" → ⚠ PHỐI HỢP VỚI CÁC QUẢN LÝ DỰ ÁN KHÁC "tự khoá lịch của họ" → ⚠ chiếm nguồn lực đơn phương "bảo họ nói dối" → ⚠ vi phạm đạo đức, loại ngay "chờ PMO phân người" → ⚠ bị động khi mốc thời gian là then chốt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết thành viên của mình còn cam kết ở đâu nữa không | | | Nhu cầu nguồn lực của bạn có được nói ra trước bao lâu | | | Có thoả thuận bằng văn bản không, hay chỉ là lời hứa miệng | |

Và điều mà việc gọi cho đồng nghiệp trước khi khoá lịch của họ mang lại: lần sau khi chính bạn là người bị kẹt, sẽ có người sẵn lòng nhấc máy — điều mà người vừa bị bạn chiếm mất nguồn lực chắc chắn sẽ không làm.

Câu 244 Process
As the project manager for Wonder Toys, Sterling's latest project is to document all the company's computer systems. His project team must document each computer's operating systems, hardware, network configuration, and software. The project scope has been finished according to plan. What must happen next for the customer to accept the project?
  1. A Implementation of proof-of-concept
  2. B Scope validation should be conducted
  3. C Nothing should happen next. The plan is complete, so the project is complete.
  4. D Lessons learned should be finalized
Xem giải thích

Đáp án

B — TIẾN HÀNH XÁC NHẬN PHẠM VI (validate scope).

Vì sao đúng

⚠ Vì sao phải xác nhận phạm vi: | Lý do | Nội dung | |---|---| | ⚠ Công việc đã hoàn thành theo kế hoạch | ⚠ nhưng "hoàn thành" mới là đánh giá của đội | | ⚠ Xác nhận phạm vi = KHÁCH HÀNG chính thức NGHIỆM THU sản phẩm | ⚠ đúng câu hỏi "để khách chấp nhận dự án" | | ⚠ Nó là quy trình duy nhất có đầu ra "sản phẩm được nghiệm thu" | | | ⚠ Không có bước này thì không có căn cứ đóng dự án | | | ⚠ Kết luận | ⚠ sản phẩm đúng theo kế hoạch chưa chắc là sản phẩm khách hàng chịu ký nhận — chỉ có chính khách hàng nói được điều đó |

⚠ Phân biệt hai quy trình rất hay lẫn: ⚠ KIỂM SOÁT CHẤT LƯỢNG do đội nội bộ làm, hỏi "sản phẩm có ĐÚNG không"; XÁC NHẬN PHẠM VI do KHÁCH HÀNG làm, hỏi "sản phẩm có ĐƯỢC CHẤP NHẬN không" ⚠ — ⚠ kiểm soát chất lượng đứng trước, xác nhận phạm vi đứng sau.

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

  • C (không cần làm gì nữa, kế hoạch xong là dự án xong) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đề nói rõ "phạm vi đã hoàn thành theo kế hoạch", nghe như mọi việc đã trọn vẹn: ⚠ nhưng ⚠ hoàn thành CÔNG VIỆC và được KHÁCH NGHIỆM THU là hai chuyện khác nhau ⚠ — ⚠ và chính câu hỏi đã nói "để khách hàng chấp nhận dự án", tức là bước nghiệm thu vẫn còn ở phía trước; ⚠ bỏ qua nghiệm thu là cách chắc chắn nhất để phát hiện bất đồng vào lúc muộn nhất.

  • A (triển khai bản chứng minh khái niệm) — ⚠ việc của giai đoạn ĐẦU, để thử tính khả thi; ⚠ ở đây công việc đã xong.

  • D (hoàn tất bài học kinh nghiệm) — ⚠ việc của giai đoạn ĐÓNG, và nó phục vụ tổ chức chứ không tạo ra sự chấp nhận của khách hàng; ⚠ ngoài ra bài học phải ghi suốt dự án — liên hệ #26726 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26708 cùng lô (sản phẩm được nghiệm thu rồi thì làm gì tiếp), ⚠ #26697 cùng lô (bản chất của kiểm soát chất lượng), ⚠ #26689 cùng lô (lưu trữ thông tin khi đóng dự án), ⚠ #26651 lô 198 (định nghĩa hoàn thành), ⚠ #26726 cùng lô (bài học kinh nghiệm ghi suốt dự án).

⚠ KIỂM SOÁT CHẤT LƯỢNG và XÁC NHẬN PHẠM VI — bảng phân biệt: | Tiêu chí | Kiểm soát chất lượng | Xác nhận phạm vi | |---|---|---| | ⚠ Ai làm | ⚠ đội dự án / bộ phận chất lượng | ⚠ KHÁCH HÀNG hoặc nhà tài trợ | | ⚠ Câu hỏi | ⚠ "có đúng đặc tả không" | ⚠ "có chấp nhận được không" | | ⚠ Đầu vào | ⚠ sản phẩm bàn giao | ⚠ sản phẩm ĐÃ QUA kiểm soát chất lượng | | ⚠ Đầu ra | ⚠ sản phẩm đã kiểm chứng | ⚠ SẢN PHẨM ĐƯỢC NGHIỆM THU | | ⚠ Trọng tâm | ⚠ tính đúng đắn | ⚠ sự chấp nhận | | ⚠ Thứ tự bắt buộc | ⚠ kiểm soát chất lượng TRƯỚC, xác nhận phạm vi SAU — đưa sản phẩm chưa kiểm cho khách xem là tự tạo ra tranh cãi không cần thiết | |

⚠ Xác nhận phạm vi diễn ra thế nào trong dự án của Sterling: | Bước | Nội dung | |---|---| | ⚠ Đội tự rà lại tài liệu đã lập | ⚠ đủ hệ điều hành, phần cứng, cấu hình mạng, phần mềm cho MỌI máy | | ⚠ So với tiêu chí nghiệm thu trong tuyên bố phạm vi | | | ⚠ Mời khách hàng rà soát chính thức | ⚠ cùng đọc, cùng đối chiếu | | ⚠ Ghi nhận điểm chưa đạt nếu có | ⚠ sinh ra yêu cầu thay đổi hoặc sửa lỗi | | ⚠ Lấy chữ ký nghiệm thu bằng văn bản | ⚠ đây mới là đầu ra thật của quy trình | | ⚠ Vì sao phải bằng văn bản | ⚠ "khách hàng đã đồng ý qua điện thoại" là câu nói phổ biến nhất trong các cuộc tranh chấp cuối dự án |

Từ khoá nhận diện:

"để KHÁCH HÀNG chấp nhận" → ⚠ XÁC NHẬN PHẠM VI "kiểm tra sản phẩm có đúng đặc tả" → ⚠ kiểm soát chất lượng, làm trước "chứng minh khái niệm" → ⚠ giai đoạn đầu, thử khả thi "bài học kinh nghiệm" → ⚠ ghi suốt dự án, hoàn tất khi đóng — không tạo ra sự nghiệm thu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiêu chí nghiệm thu của bạn có đo được không | ⚠ "tài liệu đầy đủ" chưa đo được; "mỗi máy có đủ bốn mục" thì đo được | | Bạn có văn bản nghiệm thu cho từng sản phẩm không | | | Khách hàng có tham gia rà soát trước lúc kết thúc không | ⚠ nếu không, buổi nghiệm thu sẽ thành buổi thương lượng |

Và điều mà một dự án làm xong đúng kế hoạch vẫn có thể vấp phải: kế hoạch là thoả thuận của hôm bắt đầu, còn sự chấp nhận là phán quyết của hôm kết thúc — và chỉ có bước nghiệm thu mới cho bạn biết hai thứ đó có còn khớp nhau không.

Câu 245 Process
You are the project manager of the Sunrise Project for your organization. This project has internal, external, governmental, and media stakeholders. These stakeholders can influence your project, so you need to create a good stakeholder engagement strategy for the different stakeholder groups. The Sunrise Project wants you to identify who is a legitimate stakeholder and who is only topically interested. You are concerned about the stakeholder with power, such as the governmental stakeholders. You also know that many stakeholders are eager for this project to be launched and underway. Which model for stakeholders would you choose?
  1. A Context diagram
  2. B Participation matrix
  3. C Influence/ impact grid
  4. D Salience model
Xem giải thích

Đáp án

D — MÔ HÌNH NỔI BẬT (salience model).

Vì sao đúng

⚠ Ba trục của mô hình nổi bật, ánh xạ thẳng vào đề: | Trục | Câu chữ trong đề | |---|---| | ⚠ QUYỀN LỰC (power) | ⚠ "lo ngại về bên liên quan CÓ QUYỀN LỰC như cơ quan nhà nước" | | ⚠ TÍNH CHÍNH DANH (legitimacy) | ⚠ "ai là bên liên quan CHÍNH ĐÁNG, ai chỉ quan tâm bề mặt" | | ⚠ TÍNH CẤP BÁCH (urgency) | ⚠ "nhiều bên NÓNG LÒNG muốn dự án khởi động" | | ⚠ Kết luận | ⚠ đề nêu đủ CẢ BA trục — không mô hình nào khác có ba trục này |

⚠ Đây là dạng câu "đếm trục": ⚠ mọi mô hình phân loại bên liên quan khác chỉ có HAI chiều; thấy ba yếu tố quyền lực – chính danh – cấp bách xuất hiện cùng lúc thì đáp án luôn là mô hình nổi bật.

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

  • C (lưới ẢNH HƯỞNG / TÁC ĐỘNG) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là công cụ phân loại bên liên quan thật, cũng nói về quyền lực và mức độ ảnh hưởng, nên nghe rất khớp với nửa đầu của đề: ⚠ nhưng ⚠ nó chỉ có HAI trục và KHÔNG có trục tính chính danh ⚠ — ⚠ mà việc "phân biệt bên liên quan chính đáng với người chỉ quan tâm bề mặt" chính là trục chính danh, và đó là đặc sản riêng của mô hình nổi bật; ⚠ cùng họ lưới hai chiều còn có quyền lực/quan tâm và quyền lực/ảnh hưởng — tất cả đều thiếu trục thứ ba.

  • B (ma trận tham gia — participation matrix) — ⚠ đo mức độ tham gia HIỆN TẠI so với MONG MUỐN (không biết → phản đối → trung lập → ủng hộ → dẫn dắt); ⚠ nó là công cụ theo dõi, không phải công cụ phân loại ban đầu.

  • A (sơ đồ ngữ cảnh — context diagram) — ⚠ công cụ của quản lý YÊU CẦU, vẽ ranh giới hệ thống và các tác nhân tương tác; ⚠ không phải công cụ phân tích bên liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26645 lô 198 (chiến lược theo nhóm bên liên quan), ⚠ #26731 cùng lô (khi nào bắt đầu quản lý bên liên quan), ⚠ #26721 cùng lô (bên liên quan quyền lực cao nhưng không tham gia dự án), ⚠ #26642 lô 198 (công chúng hiểu sai), ⚠ #26723 cùng lô (nhận diện nhu cầu).

⚠ MÔ HÌNH NỔI BẬT — bảy nhóm sinh ra từ ba trục: | Nhóm | Có gì | Cách ứng xử | |---|---|---| | ⚠ Ngủ yên (dormant) | ⚠ chỉ QUYỀN LỰC | ⚠ theo dõi — có thể tỉnh dậy bất cứ lúc nào | | ⚠ Tuỳ ý (discretionary) | ⚠ chỉ CHÍNH DANH | ⚠ giữ liên lạc, chi phí thấp | | ⚠ Đòi hỏi (demanding) | ⚠ chỉ CẤP BÁCH | ⚠ ồn ào nhưng không có sức nặng — đừng để họ chiếm hết thời gian | | ⚠ Thống trị (dominant) | ⚠ quyền lực + chính danh | ⚠ quản lý sát — nhóm cơ quan nhà nước thường ở đây | | ⚠ Nguy hiểm (dangerous) | ⚠ quyền lực + cấp bách, KHÔNG chính danh | ⚠ cẩn trọng — có sức ép mà không có tư cách | | ⚠ Phụ thuộc (dependent) | ⚠ chính danh + cấp bách, không quyền lực | ⚠ cần người bảo trợ giúp họ có tiếng nói | | ⚠ Dứt khoát (definitive) | ⚠ ĐỦ BA | ⚠ ưu tiên cao nhất, quản lý chặt chẽ | | ⚠ Giá trị thật của mô hình | ⚠ nó tách được "người có tiếng nói to" khỏi "người thật sự có quyền lợi" — đúng điều mà dự án Sunrise đang cần |

⚠ Bảng so các công cụ phân loại bên liên quan: | Công cụ | Số trục | Trục nào | |---|---|---| | ⚠ Lưới quyền lực / quan tâm | ⚠ 2 | ⚠ quyền lực, mức quan tâm | | ⚠ Lưới quyền lực / ảnh hưởng | ⚠ 2 | ⚠ quyền lực, mức ảnh hưởng | | ⚠ Lưới ảnh hưởng / tác động | ⚠ 2 | ⚠ ảnh hưởng lên dự án, tác động của dự án lên họ | | ⚠ MÔ HÌNH NỔI BẬT | ⚠ 3 | ⚠ quyền lực, chính danh, cấp bách — ĐÁP ÁN | | ⚠ Khối lập phương bên liên quan | ⚠ 3 (khác) | ⚠ quyền lực, mức quan tâm, mức độ tham gia | | ⚠ Mẹo phân biệt nhanh | ⚠ chỉ mô hình nổi bật nói tới CHÍNH DANH; thấy chữ đó là chọn ngay |

⚠ Vì sao dự án Sunrise cần đúng mô hình này: | Đặc điểm dự án | Ý nghĩa | |---|---| | ⚠ Có bên liên quan nội bộ, bên ngoài, nhà nước và BÁO CHÍ | ⚠ rất nhiều nhóm, rất khác nhau về bản chất | | ⚠ Báo chí có tiếng nói lớn nhưng không phải bên có quyền lợi trực tiếp | ⚠ hay rơi vào nhóm "nguy hiểm" hoặc "đòi hỏi" | | ⚠ Cơ quan nhà nước có cả quyền lực và tư cách chính danh | ⚠ nhóm thống trị hoặc dứt khoát | | ⚠ Nguồn lực giao tiếp là hữu hạn | ⚠ phải biết dồn vào đâu | | ⚠ Nhắc nhở | ⚠ phân loại không phải để loại ai ra khỏi cuộc trò chuyện, mà để quyết định ai cần được nói chuyện SÂU và ai chỉ cần được thông tin — và bảng phân loại phải được xem lại định kỳ vì bên liên quan thay đổi theo giai đoạn |

Từ khoá nhận diện:

"quyền lực + chính danh + cấp bách" → ⚠ MÔ HÌNH NỔI BẬT "chính danh / legitimacy" → ⚠ chỉ mô hình nổi bật có trục này "lưới hai chiều bất kỳ" → ⚠ thiếu trục thứ ba "sơ đồ ngữ cảnh" → ⚠ công cụ của quản lý yêu cầu, không phải bên liên quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong sổ bên liên quan của bạn, ai ồn ào nhất | ⚠ kiểm xem họ có tư cách chính danh không | | Có bên liên quan nào có quyền lực mà bạn chưa từng liên hệ không | ⚠ nhóm "ngủ yên" là nguồn bất ngờ lớn nhất | | Bạn cập nhật phân loại bao lâu một lần | |

Và điều mà mô hình ba trục dạy được cho người quản lý dự án: âm lượng không phải là thẩm quyền — và phần lớn thời gian bị mất trong một dự án là thời gian dành cho những người rất cấp bách nhưng chẳng liên quan.

Câu 246 Process
Carl is sitting in his team’s agile workshop and writing his ideas down for five minutes. He will then be asked to present his ideas to the group, just like the rest of the team. Carl is participating in
  1. A Fishbone Diagramming
  2. B Quiet Writing
  3. C Round Robin
  4. D Free Hand
Xem giải thích

Đáp án

B — VIẾT THẦM / QUIET WRITING.

Vì sao đúng

⚠ Đề mô tả đúng ba đặc trưng của kỹ thuật này: | Đặc trưng | Câu chữ trong đề | |---|---| | ⚠ Mỗi người viết ý tưởng MỘT MÌNH | ⚠ "Carl viết ý tưởng của mình xuống" | | ⚠ Trong một khoảng thời gian ẤN ĐỊNH | ⚠ "trong năm phút" | | ⚠ Sau đó TỪNG NGƯỜI trình bày cho cả nhóm | ⚠ "sẽ được mời trình bày, giống như những người còn lại" | | ⚠ Kết luận | ⚠ suy nghĩ độc lập trước, chia sẻ sau — đó chính là viết thầm |

⚠ Mục đích của kỹ thuật: ⚠ chống HIỆU ỨNG NEO và ÁP LỰC NHÓM ⚠ — ⚠ trong một buổi động não nói miệng, ý tưởng đầu tiên định hình toàn bộ cuộc thảo luận, và người nói to nhất thường thắng; viết thầm đảm bảo mọi ý tưởng đều được sinh ra trước khi ai kịp ảnh hưởng tới ai.

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

  • C (vòng tròn — round robin) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ round robin cũng đảm bảo LẦN LƯỢT ai cũng được nói, và phần cuối của đề đúng là mọi người đều trình bày: ⚠ nhưng ⚠ round robin chỉ nói về TRẬT TỰ PHÁT BIỂU, nó không có phần viết một mình trước ⚠ — ⚠ mà chi tiết đặc trưng nhất của đề chính là năm phút viết riêng; ⚠ hai kỹ thuật thường được dùng CHUNG: viết thầm sinh ý tưởng, round robin quyết thứ tự chia sẻ.

  • A (biểu đồ xương cá) — ⚠ công cụ PHÂN TÍCH NGUYÊN NHÂN GỐC, không phải kỹ thuật sinh ý tưởng theo nhóm; ⚠ liên hệ #26656 lô 198.

  • D (free hand) — ⚠ không phải tên một kỹ thuật hội thảo agile; ⚠ thuật ngữ bịa.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26655 lô 198 (fist of five — biểu quyết đồng thuận), ⚠ #26722 cùng lô (trò chơi cộng tác để đạt đồng thuận), ⚠ #26720 cùng lô (xếp ưu tiên tồn đọng), ⚠ #26569 lô 196 (quyết định tập thể), ⚠ #26700 cùng lô (hồi cứu là để cải tiến).

⚠ Các kỹ thuật hội thảo hay gặp trong đề PMP: | Kỹ thuật | Cách làm | Dùng khi | |---|---|---| | ⚠ VIẾT THẦM (quiet writing) | ⚠ viết riêng trong thời gian ấn định rồi trình bày — ĐÁP ÁN | ⚠ muốn ý tưởng đa dạng, tránh bị neo | | ⚠ VÒNG TRÒN (round robin) | ⚠ lần lượt từng người nói, không ai được bỏ qua | ⚠ muốn ai cũng có tiếng nói | | ⚠ ĐỘNG NÃO (brainstorming) | ⚠ nói tự do, không phê phán | ⚠ cần nhiều ý tưởng nhanh | | ⚠ NHÓM DANH NGHĨA (nominal group) | ⚠ động não rồi BỎ PHIẾU xếp hạng | ⚠ cần vừa sinh vừa chọn ý tưởng | | ⚠ DELPHI | ⚠ hỏi chuyên gia ẨN DANH nhiều vòng | ⚠ muốn tránh ảnh hưởng của người có uy tín | | ⚠ NẮM TAY NĂM NGÓN (fist of five) | ⚠ giơ ngón tay đo mức đồng thuận | ⚠ kiểm tra sự đồng thuận nhanh | | ⚠ Điểm chung của viết thầm, nhóm danh nghĩa và Delphi | ⚠ cả ba đều được thiết kế để CHẶN sự chi phối của người nói to nhất hoặc có chức vụ cao nhất — chỉ khác nhau ở mức độ ẩn danh và số vòng |

⚠ Vì sao viết thầm hiệu quả hơn động não thuần nói: | Vấn đề của động não nói | Viết thầm khắc phục thế nào | |---|---| | ⚠ Ý tưởng đầu tiên neo cả nhóm | ⚠ mọi ý tưởng sinh ra song song, không ai nghe ai trước | | ⚠ Người hướng nội ít lên tiếng | ⚠ họ có thời gian và không gian riêng để nghĩ | | ⚠ Người có chức vụ chi phối | ⚠ giấy không biết ai là sếp | | ⚠ Chỉ một người nói tại một thời điểm | ⚠ viết thì cả nhóm cùng nghĩ, hiệu suất cao hơn | | ⚠ Ý tưởng bị quên khi chờ tới lượt | ⚠ đã ghi ra giấy rồi thì không mất | | ⚠ Nghiên cứu về nhóm | ⚠ nhóm sinh ý tưởng riêng rồi gộp lại thường cho nhiều ý tưởng độc đáo hơn nhóm cùng nói từ đầu — đây là lý do kỹ thuật này tồn tại, không phải vì nó lịch sự hơn |

Từ khoá nhận diện:

"viết riêng trong X phút rồi trình bày" → ⚠ VIẾT THẦM (quiet writing) "lần lượt từng người nói" → ⚠ round robin — chỉ nói về trật tự "xương cá" → ⚠ phân tích nguyên nhân gốc, không phải sinh ý tưởng "free hand" → ⚠ thuật ngữ bịa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong buổi họp gần nhất, ai nói nhiều nhất | ⚠ nếu luôn là một người, hãy thử viết thầm | | Ý tưởng cuối cùng chọn có phải ý tưởng nói ra đầu tiên không | | | Người ít nói trong đội có ý kiến khác không | ⚠ cho họ giấy và năm phút thì bạn sẽ biết |

Và điều mà năm phút im lặng làm được cho một buổi hội thảo: nó cho những ý tưởng chưa kịp thành lời một cơ hội tồn tại, thay vì bị cuốn trôi bởi ý tưởng đầu tiên đủ nhanh để được nói ra.

Câu 247 Process
Jordan has just completed the management of a small project that included replacing computer monitors in a single department of a large company. The project took four weeks to complete, was on budget, and was completed on time. The customers and the project sponsor are pleased with the outcome of the project. The project has been officially closed, and the team is ready to move on to other work. Of the following choices, what task should Jordan now complete, even for this small project?
  1. A Archive the project information in the knowledge management system.
  2. B Perform a final earned value management analysis.
  3. C Confirm that the project risks reports are finalized.
  4. D Meet with each stakeholder to confirm closure.
Xem giải thích

Đáp án

A — LƯU TRỮ THÔNG TIN DỰ ÁN vào hệ thống quản lý tri thức của tổ chức.

Vì sao đúng

⚠ Vì sao việc này bắt buộc kể cả với dự án nhỏ: | Lý do | Nội dung | |---|---| | ⚠ Lưu trữ là hoạt động BẮT BUỘC của quy trình ĐÓNG DỰ ÁN | ⚠ không phụ thuộc quy mô | | ⚠ Tài sản quy trình của tổ chức được bồi đắp từ đây | ⚠ ước lượng, bài học, mẫu biểu, hợp đồng | | ⚠ Dự án sau sẽ ước lượng dựa trên dữ liệu này | ⚠ liên hệ #26661 lô 198 — dữ liệu lịch sử | | ⚠ Dự án nhỏ vẫn sinh ra bài học có giá trị | ⚠ và bốn tuần, đúng ngân sách, đúng hạn là dữ liệu tốt | | ⚠ Đội sắp giải tán — không lưu bây giờ thì không bao giờ lưu | | | ⚠ Kết luận | ⚠ "dự án nhỏ" không phải lý do bỏ qua bước đóng — nó chỉ là lý do làm bước đó gọn hơn |

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

  • D (gặp từng bên liên quan để xác nhận việc đóng dự án) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ xác nhận với bên liên quan đúng là một hoạt động của việc đóng dự án và nghe rất chu đáo: ⚠ nhưng ⚠ đề đã nói rõ dự án ĐÃ ĐƯỢC ĐÓNG CHÍNH THỨC, khách hàng và nhà tài trợ ĐÃ HÀI LÒNG ⚠ — ⚠ việc nghiệm thu và chấp nhận đã xong rồi, nên đi gặp lại từng người là lặp lại việc đã làm; ⚠ thứ CHƯA làm là lưu trữ.

  • B (phân tích giá trị thu được lần cuối) — ⚠ dự án đã xong đúng hạn, đúng ngân sách; ⚠ EVM là công cụ GIÁM SÁT trong lúc thực thi, không phải nghi thức đóng dự án; ⚠ số liệu chi phí cuối cùng vẫn được ghi lại, nhưng đó là một phần của việc lưu trữ.

  • C (xác nhận báo cáo rủi ro đã hoàn tất) — ⚠ quá hẹp; ⚠ báo cáo rủi ro chỉ là một trong nhiều tài liệu cần lưu, và bản thân nó không phải hoạt động đóng dự án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26726 cùng lô (bài học phải ghi trong suốt dự án), ⚠ #26661 lô 198 (dữ liệu lịch sử để ước lượng), ⚠ #26686 cùng lô (xác nhận phạm vi trước khi đóng), ⚠ #26667 lô 198 (bảo đảm tài liệu dự án tiếp cận được), ⚠ #26708 cùng lô (tài liệu cho sản phẩm được bàn giao sớm).

⚠ ĐÓNG DỰ ÁN — danh sách việc, kể cả với dự án nhỏ: | Việc | Nội dung | |---|---| | ⚠ Xác nhận công việc đã hoàn thành theo tiêu chí | | | ⚠ Lấy nghiệm thu chính thức từ khách hàng | ⚠ liên hệ #26686 cùng lô | | ⚠ Đóng toàn bộ hợp đồng mua sắm | ⚠ thanh toán nốt, giải quyết tranh chấp | | ⚠ Hoàn tất và lưu BÀI HỌC KINH NGHIỆM | ⚠ liên hệ #26726 cùng lô | | ⚠ LƯU TRỮ tài liệu vào kho tri thức | ⚠ ĐÁP ÁN | | ⚠ Giải phóng nguồn lực và ghi nhận đóng góp | | | ⚠ Đo sự hài lòng của bên liên quan | | | ⚠ Việc hay bị bỏ nhất | ⚠ lưu trữ — vì lúc đó ai cũng đã tinh thần chuyển sang dự án mới, và không ai thấy hậu quả của việc bỏ qua cho tới lần ước lượng tiếp theo |

⚠ Lưu trữ gì trong dự án của Jordan: | Tài liệu | Giá trị cho lần sau | |---|---| | ⚠ Thời gian thực tế: bốn tuần | ⚠ cơ sở ước lượng cho dự án thay màn hình khác | | ⚠ Chi phí thực tế so với dự toán | | | ⚠ Nhà cung cấp đã dùng và chất lượng phục vụ | ⚠ liên hệ #26558 lô 196 | | ⚠ Các vấn đề gặp phải và cách xử lý | | | ⚠ Mẫu kế hoạch và bảng kiểm đã dùng | ⚠ dùng lại được ngay | | ⚠ Phản hồi của khách hàng | | | ⚠ Vì sao dự án nhỏ đặc biệt đáng lưu | ⚠ dự án nhỏ lặp lại nhiều lần trong tổ chức — một bộ hồ sơ tốt của lần này có thể tiết kiệm cả tuần lập kế hoạch cho mười lần sau |

⚠ Vì sao "dự án nhỏ nên bỏ qua thủ tục" là một cái bẫy: | Lập luận thường gặp | Vì sao sai | |---|---| | ⚠ "Chỉ có bốn tuần, không có gì đáng ghi" | ⚠ thời lượng không quyết định giá trị của bài học | | ⚠ "Ai cũng nhớ chuyện gì đã xảy ra" | ⚠ sáu tháng nữa thì không, và người nhớ có thể đã chuyển việc | | ⚠ "Khách hàng hài lòng rồi thì thôi" | ⚠ lưu trữ phục vụ TỔ CHỨC, không phải khách hàng | | ⚠ "Lần sau làm lại từ đầu cũng nhanh" | ⚠ đó chính là chi phí mà bạn đang tự tạo ra | | ⚠ Nguyên tắc | ⚠ quy trình được rút gọn theo quy mô, nhưng không bị bỏ hẳn — với dự án bốn tuần, việc lưu trữ có thể chỉ mất một buổi chiều |

Từ khoá nhận diện:

"dự án đã đóng, còn phải làm gì" → ⚠ LƯU TRỮ vào kho tri thức "dự án nhỏ nên bỏ qua" → ⚠ luôn là bẫy trong đề PMP "gặp lại từng bên liên quan" → ⚠ việc đã xong trước khi đóng "phân tích EVM cuối" → ⚠ công cụ giám sát, không phải nghi thức đóng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án gần nhất của bạn có hồ sơ lưu trữ tìm lại được không | ⚠ thử tìm thật, đừng chỉ tin là có | | Bạn ước lượng dự án mới dựa trên gì | ⚠ dữ liệu cũ hay cảm giác | | Ai trong tổ chức chịu trách nhiệm giữ kho tri thức đó | |

Và điều mà một buổi chiều lưu hồ sơ cho dự án bốn tuần thật sự mua được: quyền được bắt đầu dự án sau từ điểm mà dự án này đã tới, thay vì từ con số không một lần nữa.

Câu 248 Process
The process for applying technical and administrative direction and surveillance of implementing a project is called configuration management. Of the choices below, which activity is not a part of configuration management?
  1. A Controlling changes to project deliverables
  2. B Automatic change request approvals
  3. C Identifying the functional and physical characteristics of the project deliverables
  4. D Scope verification
Xem giải thích

Đáp án

B — TỰ ĐỘNG DUYỆT YÊU CẦU THAY ĐỔI (automatic change request approvals).

Vì sao đúng

⚠ Câu hỏi tìm việc KHÔNG thuộc quản lý cấu hình: | Phương án | Có thuộc quản lý cấu hình không | |---|---| | ⚠ A — kiểm soát thay đổi đối với sản phẩm bàn giao | ⚠ CÓ — đây là lõi của quản lý cấu hình | | ⚠ B — tự động duyệt yêu cầu thay đổi | ⚠ KHÔNG — ĐÁP ÁN | | ⚠ C — nhận diện đặc tính chức năng và vật lý của sản phẩm | ⚠ CÓ — bước đầu tiên: định danh cấu hình | | ⚠ D — kiểm tra phạm vi (scope verification) | ⚠ CÓ — thuộc nhóm kiểm chứng, gắn với việc xác nhận cấu hình |

⚠ Vì sao "tự động duyệt" mâu thuẫn với chính bản chất của quản lý cấu hình: ⚠ toàn bộ mục đích của nó là ĐẢM BẢO MỌI THAY ĐỔI ĐỀU ĐƯỢC XEM XÉT, ghi nhận và phê duyệt có kiểm soát ⚠ — ⚠ "tự động duyệt" nghĩa là không xem xét gì cả, tức là phá bỏ chính cơ chế mình đang nói tới.

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

  • D (kiểm tra phạm vi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "scope verification" là một tên gọi cũ, không còn xuất hiện trong PMBOK bản mới (nay là XÁC NHẬN PHẠM VI), nên nhiều người tưởng nó là thuật ngữ bịa: ⚠ nhưng ⚠ hoạt động kiểm chứng và nghiệm thu cấu hình LÀ một phần của quản lý cấu hình — nó xác nhận sản phẩm đúng với cấu hình đã được duyệt ⚠ — ⚠ và dù tên gọi có đổi, nội dung vẫn thuộc phạm vi câu hỏi này.

  • A (kiểm soát thay đổi đối với sản phẩm bàn giao) — ⚠ chính là mô tả của kiểm soát cấu hình; ⚠ thuộc, nên không phải đáp án.

  • C (nhận diện đặc tính chức năng và vật lý) — ⚠ là bước ĐỊNH DANH CẤU HÌNH, bước đầu tiên trong ba bước; ⚠ thuộc.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26634 lô 198 (đưa thay đổi ra ban kiểm soát thay đổi), ⚠ #26710 cùng lô (thành phần của ban kiểm soát thay đổi), ⚠ #26686 cùng lô (xác nhận phạm vi), ⚠ #26697 cùng lô (kiểm soát chất lượng), ⚠ #26706 cùng lô (tài liệu tuân thủ).

⚠ QUẢN LÝ CẤU HÌNH — ba hoạt động chính: | Hoạt động | Nội dung | |---|---| | ⚠ ĐỊNH DANH CẤU HÌNH | ⚠ xác định và ghi nhận đặc tính chức năng, vật lý của sản phẩm — phương án C | | ⚠ KIỂM SOÁT THAY ĐỔI CẤU HÌNH | ⚠ mọi thay đổi phải qua xem xét và phê duyệt — phương án A | | ⚠ GHI NHẬN VÀ KIỂM CHỨNG TRẠNG THÁI | ⚠ theo dõi phiên bản, kiểm chứng sản phẩm khớp cấu hình đã duyệt — phương án D | | ⚠ Điều tuyệt đối không có | ⚠ duyệt tự động — nếu có thì không còn gì gọi là "kiểm soát" nữa |

⚠ Phân biệt QUẢN LÝ CẤU HÌNH và KIỂM SOÁT THAY ĐỔI: | Tiêu chí | Quản lý cấu hình | Kiểm soát thay đổi | |---|---|---| | ⚠ Đối tượng | ⚠ ĐẶC TÍNH của sản phẩm và tài liệu | ⚠ các đường CƠ SỞ của dự án | | ⚠ Câu hỏi | ⚠ "phiên bản nào đang là chuẩn" | ⚠ "có được thay đổi kế hoạch không" | | ⚠ Ví dụ | ⚠ bản vẽ v3.2 là bản đang thi công | ⚠ duyệt tăng ngân sách 5% | | ⚠ Quan hệ | ⚠ hai cái đan vào nhau — một thay đổi được duyệt sẽ sinh ra một phiên bản cấu hình mới | | | ⚠ Ghi nhớ cho đề thi | ⚠ hỏi về PHIÊN BẢN, ĐẶC TẢ, BẢN VẼ, TÀI LIỆU KỸ THUẬT → quản lý cấu hình; hỏi về ĐƯỜNG CƠ SỞ phạm vi/tiến độ/chi phí → kiểm soát thay đổi |

⚠ Vì sao "duyệt tự động" là ý tưởng nguy hiểm trong thực tế: | Hậu quả | Nội dung | |---|---| | ⚠ Phạm vi phình ra không kiểm soát | ⚠ mỗi thay đổi nhỏ đều được duyệt thì tổng lại thành rất lớn | | ⚠ Tác động chéo không được đánh giá | ⚠ một thay đổi ở mô-đun A có thể phá mô-đun B | | ⚠ Ngân sách và tiến độ trôi mà không ai quyết định | | | ⚠ Không truy được ai quyết cái gì, khi nào | ⚠ mất khả năng kiểm toán | | ⚠ Ngoại lệ hợp lý duy nhất | ⚠ tổ chức có thể phân quyền cho người quản lý dự án duyệt thay đổi DƯỚI một ngưỡng nhất định — nhưng đó vẫn là một quyết định có người chịu trách nhiệm và có ghi nhận, khác hẳn với "tự động duyệt" |

Từ khoá nhận diện:

"tự động duyệt thay đổi" → ⚠ KHÔNG bao giờ thuộc quản lý cấu hình — luôn là đáp án của câu hỏi phủ định "đặc tính chức năng và vật lý" → ⚠ định danh cấu hình "kiểm soát thay đổi sản phẩm bàn giao" → ⚠ kiểm soát cấu hình "scope verification" → ⚠ tên cũ của xác nhận phạm vi, vẫn thuộc nhóm kiểm chứng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết phiên bản nào của đặc tả đang là bản chuẩn không | | | Có loại thay đổi nào trong dự án bạn được duyệt mà không ai xem không | | | Ngưỡng tự quyết của bạn là bao nhiêu, và được ghi ở đâu | |

Và điều đáng nhớ về ba phương án còn lại: chúng đều mô tả công việc, còn phương án đúng mô tả sự vắng mặt của công việc — và trong các câu hỏi phủ định, thứ nghe như một sự tiện lợi thường chính là thứ cần loại.

Câu 249 Process
You are a senior project manager on a restoration project where you are deliberating between renting, leasing, or buying a large sandblaster. The equipment costs $250 per day to rent, $250 per day to lease for 60 days with a 10 percent discount, and $10,000 to purchase. Looking at your schedule, you estimate that the sandblaster will be necessary for 50 to 60 days. Based on the price alone, which decision would you recommend?
  1. A More information is needed.
  2. B Lease the equipment.
  3. C Rent the equipment.
  4. D Purchase the equipment.
Xem giải thích

Đáp án

D — MUA THIẾT BỊ (10.000 đô la).

Vì sao đúng

⚠ Tính đủ ba phương án — đây là câu số học thuần tuý: | Phương án | Cách tính | Kết quả | |---|---|---| | ⚠ THUÊ NGÀY (rent) | ⚠ 250 × 50 ngày = 12.500; 250 × 60 ngày = 15.000 | ⚠ 12.500 – 15.000 đô | | ⚠ THUÊ DÀI HẠN (lease) | ⚠ 250 × 60 ngày = 15.000, giảm 10% → 15.000 × 0,9 | ⚠ 13.500 đô | | ⚠ MUA (purchase) | ⚠ giá trọn gói | ⚠ 10.000 đô — RẺ NHẤT | | ⚠ Kết luận | ⚠ mua rẻ hơn phương án thuê rẻ nhất tới 2.500 đô, và rẻ hơn thuê dài hạn 3.500 đô | |

⚠ Điểm mấu chốt: ⚠ thuê theo ngày ĐÃ VƯỢT giá mua ngay từ ngày thứ 41 ⚠ — ⚠ 10.000 ÷ 250 = 40 ngày là ĐIỂM HOÀ VỐN; ⚠ mà nhu cầu là 50–60 ngày, tức là vượt điểm hoà vốn trong MỌI kịch bản.

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

  • B (thuê dài hạn — lease) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó là phương án duy nhất có KHUYẾN MÃI, và mức giảm 10% khiến người ta cảm thấy đây là lựa chọn "khôn ngoan": ⚠ nhưng ⚠ 13.500 vẫn ĐẮT HƠN giá mua 10.000 tới 3.500 đô ⚠ — ⚠ chiết khấu 10% trên một mức giá cao hơn không làm nó rẻ hơn; ⚠ cái bẫy ở đây là cảm giác được giảm giá, không phải phép tính.

  • C (thuê theo ngày) — ⚠ rẻ nhất là 12.500 đô ở kịch bản 50 ngày, vẫn đắt hơn mua; ⚠ và nếu kéo tới 60 ngày thì thành 15.000 — phương án đắt nhất.

  • A (cần thêm thông tin) — ⚠ đề đã cho đủ số liệu; ⚠ đề cũng nói rõ "chỉ dựa trên GIÁ", nên không cần bàn tới bảo trì, thanh lý hay tồn kho.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26517 lô 195 (chi phí cơ hội), ⚠ #26549 lô 195 (khấu hao đường thẳng), ⚠ #26707 cùng lô (tỉ suất hoàn vốn), ⚠ #26614 lô 197 (tính số tháng hoàn vốn), ⚠ #26684 cùng lô (thẩm quyền mua sắm).

⚠ QUYẾT ĐỊNH THUÊ HAY MUA (make-or-buy / lease-or-buy) — cách làm chuẩn: | Bước | Nội dung | |---|---| | ⚠ 1. Tính ĐIỂM HOÀ VỐN theo thời gian | ⚠ giá mua ÷ chi phí thuê mỗi ngày = 10.000 ÷ 250 = 40 ngày | | ⚠ 2. So với thời gian sử dụng dự kiến | ⚠ 50–60 ngày > 40 ngày → MUA có lợi | | ⚠ 3. Tính cả phương án có chiết khấu | ⚠ đừng để chữ "giảm giá" thay thế phép tính | | ⚠ 4. Xét kịch bản xấu nhất và tốt nhất | ⚠ ở đây cả hai đầu đều nghiêng về mua | | ⚠ Nguyên tắc chung | ⚠ thời gian dùng NGẮN thì thuê; DÀI hơn điểm hoà vốn thì mua — và điểm hoà vốn luôn tính được bằng một phép chia |

⚠ Những yếu tố đề CỐ Ý loại bỏ bằng chữ "chỉ dựa trên giá": | Yếu tố thực tế | Vì sao đề không xét | |---|---| | ⚠ Chi phí bảo trì và bảo hiểm khi sở hữu | ⚠ đề không cho số liệu | | ⚠ Giá trị thanh lý sau dự án | ⚠ thực tế còn làm phương án mua CÀNG có lợi | | ⚠ Chi phí lưu kho và vận chuyển | | | ⚠ Rủi ro hỏng hóc thuộc về ai | ⚠ thuê thì bên cho thuê chịu | | ⚠ Dòng tiền: mua đòi tiền ngay, thuê trải đều | ⚠ có thể quan trọng với tổ chức thiếu vốn | | ⚠ Cách đọc đề | ⚠ khi đề nói "chỉ dựa trên giá", mọi lập luận ngoài con số đều là bẫy — kể cả những lập luận rất đúng trong đời thật |

⚠ Kiểm chứng lại phép tính bằng đường khác: | Cách kiểm | Nội dung | |---|---| | ⚠ Quy về đơn giá mỗi ngày ở mức 60 ngày | ⚠ thuê 250/ngày; thuê dài hạn 13.500 ÷ 60 = 225/ngày; mua 10.000 ÷ 60 ≈ 167/ngày | | ⚠ Xếp hạng | ⚠ mua < thuê dài hạn < thuê ngày — không đổi ở mọi mốc từ 41 ngày trở lên | | ⚠ Kiểm ở mức 50 ngày | ⚠ mua 200/ngày, vẫn rẻ nhất | | ⚠ Kết luận | ⚠ thứ tự không phụ thuộc vào việc dự án dùng 50 hay 60 ngày — nên phương án "cần thêm thông tin" chắc chắn sai |

Từ khoá nhận diện:

"thời gian dùng vượt điểm hoà vốn" → ⚠ MUA "chiết khấu 10%" → ⚠ vẫn phải tính ra số tuyệt đối rồi mới so "chỉ dựa trên giá" → ⚠ bỏ mọi yếu tố ngoài con số "cần thêm thông tin" → ⚠ thường sai khi đề đã cho đủ ba mức giá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tính điểm hoà vốn trước khi quyết thuê hay mua không | | | Chiết khấu bạn vừa nhận có làm giá cuối thấp hơn phương án khác không | | | Thời gian sử dụng ước lượng của bạn có sát thực tế không | ⚠ ước sai thời gian là nguồn sai lớn hơn cả phép tính |

Và điều mà một phép chia mười giây làm được: 10.000 chia 250 ra 40 — và mọi lập luận hùng hồn về gói thuê ưu đãi đều tan sau con số đó.

Câu 250 People
A project manager is working with a User Experience Engineer to finalize the layout for several pages on a company website. When they started the project, they often worked at each others' desks to maximize real-time feedback and capture creative and functional ideas. However, the project manager recently moved and has been fully remote ever since. As they attempt to finalize the visual design, the project manager has sent many emails to the User Experience Engineer to describe how the project should look. Unfortunately, the User Experience Engineer replies to these emails with mock-ups that do not quite capture the project manager's needs. Which alternative should the project managers explore for virtual team member engagement?
  1. A Audio conferencing
  2. B A shared portal
  3. C Video conferencing
  4. D Email/chat
Xem giải thích

Đáp án

C — HỌP VIDEO (video conferencing).

Vì sao đúng

⚠ Vì sao họp video là cách thay thế đúng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Trước đây hai người NGỒI CẠNH NHAU làm việc | ⚠ giao tiếp giàu, phản hồi tức thì | | ⚠ Nay quản lý dự án làm việc từ xa hoàn toàn | ⚠ mất kênh giàu nhất | | ⚠ Email mô tả THIẾT KẾ HÌNH ẢNH không truyền tải được | ⚠ bản mẫu trả về không đúng ý | | ⚠ Cần vừa NHÌN vừa TRAO ĐỔI theo thời gian thực | ⚠ họp video có cả hình, tiếng, chia sẻ màn hình | | ⚠ Kết luận | ⚠ họp video là kênh GẦN NHẤT với cách làm việc cũ đã từng hiệu quả |

⚠ Nguyên tắc nền: ĐỘ GIÀU CỦA KÊNH GIAO TIẾP. ⚠ Công việc càng mơ hồ và càng cần sáng tạo thì càng phải dùng kênh giàu ⚠ — ⚠ thiết kế trực quan là loại việc mơ hồ nhất, nên nó là loại việc tệ nhất để giao tiếp bằng chữ viết.

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

  • B (cổng thông tin dùng chung — shared portal) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ một nơi chung để đăng bản mẫu, ghi chú và phiên bản nghe rất hợp lý cho công việc thiết kế, và nó thật sự hữu ích: ⚠ nhưng ⚠ cổng thông tin là kênh BẤT ĐỒNG BỘ — nó lưu trữ tốt nhưng không tạo ra đối thoại tức thời ⚠ — ⚠ vấn đề ở đây không phải thiếu chỗ lưu bản mẫu, mà là hai người không hiểu nhau khi mô tả bằng chữ; ⚠ cổng thông tin nên dùng KÈM họp video, không thay thế được nó.

  • A (họp thoại — audio conferencing) — ⚠ có tương tác thời gian thực nhưng KHÔNG CÓ HÌNH; ⚠ với thiết kế trực quan, thiếu hình là thiếu đúng thứ quan trọng nhất.

  • D (email / chat) — ⚠ chính là cách đang thất bại; ⚠ chat nhanh hơn email nhưng vẫn là chữ viết.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bài trong bộ nguồn bị CẮT CỤT ở giữa câu hỏi cuối ("Which alternative should the project managers explo…") ⚠ — ⚠ câu đầy đủ là "…should the project manager explore?" (nên tìm tới phương án thay thế nào); ⚠ khoá đáp án được giữ nguyên vì bốn phương án đã đủ để suy ra ý định của đề, và toàn bộ tình huống chỉ dẫn tới một kết luận; ⚠ gặp đề cụt trong phòng thi, hãy đọc bốn phương án trước — chúng thường phục dựng được câu hỏi.

⚠ Ghi nhớ đối chiếu quan trọng: ⚠ #26827 lô 201 có cấu trúc câu hỏi gần giống hệt câu này — cũng hỏi "nên tìm tới phương án thay thế nào" cho một vấn đề giao tiếp của đội làm việc từ xa ⚠ — ⚠ nhưng KHOÁ ĐÁP ÁN NGƯỢC NHAU: ở đây là HỌP VIDEO, ở #26827 là EMAIL/CHAT; ⚠ hai khoá KHÔNG mâu thuẫn vì bản chất công việc khác hẳn: câu này nói về THIẾT KẾ TRỰC QUAN, nơi chữ viết không truyền tải nổi hình ảnh nên cần kênh giàu; còn #26827 nói về các nhiệm vụ RÕ RÀNG mà đội đã chứng minh là làm tốt khi nhận bằng văn bản, lại đang lãng phí các cuộc gọi vào việc tán gẫu; ⚠ bài học: câu trả lời cho "kênh giao tiếp nào" luôn phụ thuộc vào BẢN CHẤT CÔNG VIỆC, không có kênh nào tốt nhất một cách phổ quát.

⚠ Đối chiếu: ⚠ #26827 lô 201 (CÂU ĐỐI CHIẾU — khoá ngược, bối cảnh khác), ⚠ #26649 lô 198 (họp video thường xuyên cho đội phân tán), ⚠ #26641 lô 198 (mỗi bên liên quan có kênh ưa dùng khác nhau), ⚠ #26618 lô 197 (đồng địa điểm — collocation), ⚠ #26601 lô 197 (đơn giản hoá ngôn ngữ), ⚠ #26714 cùng lô (bảng thông tin trực quan).

⚠ THANG ĐỘ GIÀU CỦA KÊNH GIAO TIẾP — từ giàu tới nghèo: | Kênh | Độ giàu | Hợp với việc gì | |---|---|---| | ⚠ Gặp mặt trực tiếp | ⚠ giàu nhất — lời nói, giọng điệu, cử chỉ, bảng trắng | ⚠ đàm phán, xung đột, sáng tạo | | ⚠ HỌP VIDEO | ⚠ gần nhất với trực tiếp — ĐÁP ÁN | ⚠ thiết kế, thảo luận phức tạp, đội phân tán | | ⚠ Họp thoại | ⚠ có giọng điệu, không có hình | ⚠ cập nhật, thảo luận không cần hình ảnh | | ⚠ Chat | ⚠ nhanh nhưng chỉ có chữ | ⚠ hỏi đáp ngắn, phối hợp tức thời | | ⚠ Email | ⚠ chữ, bất đồng bộ, có lưu vết | ⚠ thông báo chính thức, quyết định đã chốt | | ⚠ Cổng thông tin / tài liệu | ⚠ nghèo nhất về tương tác, giàu nhất về lưu trữ | ⚠ tham chiếu, phiên bản, hồ sơ | | ⚠ Quy tắc chọn | ⚠ việc càng MƠ HỒ và càng dễ gây HIỂU LẦM thì càng phải leo lên phía trên bảng; việc càng cần LƯU VẾT thì càng phải có bản ghi ở phía dưới bảng |

⚠ Vì sao email đặc biệt tệ cho thiết kế trực quan: | Vấn đề | Nội dung | |---|---| | ⚠ Từ ngữ mô tả hình ảnh rất mơ hồ | ⚠ "gọn hơn", "hiện đại hơn" — mỗi người hiểu một kiểu | | ⚠ Không có vòng phản hồi tức thì | ⚠ mỗi vòng hiểu nhầm tốn một ngày | | ⚠ Không thấy được phản ứng của người nghe | ⚠ không biết họ đang hiểu sai | | ⚠ Không cùng nhìn vào một màn hình | ⚠ không chỉ trỏ được vào chỗ cụ thể | | ⚠ Mỗi lần lặp lại lại tốn công làm bản mẫu mới | ⚠ lãng phí thật sự nằm ở đây | | ⚠ Cách làm hiệu quả | ⚠ họp video có chia sẻ màn hình, sửa ngay trong lúc nói chuyện, rồi chốt lại bằng một email tóm tắt — kênh giàu để hiểu nhau, kênh nghèo để lưu vết |

Từ khoá nhận diện:

"thiết kế trực quan, làm từ xa, email không hiệu quả" → ⚠ HỌP VIDEO "cổng thông tin dùng chung" → ⚠ bất đồng bộ, bổ sung chứ không thay thế "họp thoại" → ⚠ thiếu hình, thiếu đúng thứ cần "chat" → ⚠ vẫn là chữ viết, cùng loại vấn đề với email

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chủ đề nào trong dự án bạn hay phải giải thích lại nhiều lần | ⚠ đó là chủ đề đang dùng sai kênh | | Bạn có bật hình khi họp không | | | Sau cuộc gọi, ai là người viết lại kết luận | ⚠ kênh giàu cần một bản ghi đi kèm |

Và điều mà chuỗi email không đi tới đâu này thật sự phản ánh: không phải người thiết kế đọc không kỹ, mà là hai người đang cố mô tả một bức tranh bằng chữ — việc mà một cuộc gọi mười lăm phút có bật màn hình sẽ giải quyết xong.