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

Tìm thấy 718 câu.

Câu 21 Process
You are developing a mobile application that will enable international students to connect with other students on campus. You have years of experience working with waterfall project management but have decided to employ more agile delivery methods. Which of the following artifacts would not be used in a waterfall project?
  1. A Scope baseline
  2. B Business case
  3. C Lessons learned
  4. D Product vision statement
Xem giải thích

Đáp án

D — TUYÊN NGÔN TẦM NHÌN SẢN PHẨM (product vision statement).

Vì sao đúng

⚠ Vì sao đây là hiện vật KHÔNG dùng trong dự án thác nước: | Lý do | Nội dung | |---|---| | ⚠ Tuyên ngôn tầm nhìn sản phẩm là hiện vật của AGILE | ⚠ gắn với vai trò chủ sản phẩm và tư duy hướng sản phẩm | | ⚠ Nó mô tả ĐÍCH ĐẾN mong muốn, cố ý để NGỎ về cách đi | ⚠ trái với tinh thần thác nước là chốt phạm vi từ đầu | | ⚠ Thác nước dùng ĐIỀU LỆ DỰ ÁN và ĐƯỜNG CƠ SỞ PHẠM VI thay cho nó | ⚠ hai thứ đó cụ thể và ràng buộc hơn nhiều | | ⚠ Ba phương án còn lại đều là hiện vật KINH ĐIỂN của thác nước | ⚠ nên chỉ còn một lựa chọn | | ⚠ Kết luận | ⚠ câu hỏi phủ định: tìm cái LẺ LOI |

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

  • B (TÌNH HUỐNG KINH DOANH — business case) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó cũng là tài liệu về "vì sao làm dự án", nghe khá gần với tầm nhìn sản phẩm: ⚠ nhưng ⚠ tình huống kinh doanh là tài liệu NỀN TẢNG của mọi dự án ở mọi phương pháp ⚠ — nó biện minh cho khoản đầu tư, và thác nước đặc biệt phụ thuộc vào nó để phê duyệt dự án ngay từ đầu.

  • A (ĐƯỜNG CƠ SỞ PHẠM VI) — ⚠ hiện vật đặc trưng NHẤT của thác nước: ⚠ tuyên bố phạm vi + WBS + từ điển WBS.

  • C (BÀI HỌC KINH NGHIỆM) — ⚠ dùng ở cả hai phương pháp; ⚠ thác nước ghi vào sổ bài học, agile rút ra ở buổi hồi cứu.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26455/#26458 cùng lô (bài học kinh nghiệm — tri thức ẩn và hiện), ⚠ #26464 cùng lô (xếp hạng backlog), ⚠ #26471 cùng lô (backlog và rủi ro), ⚠ #26439 cùng lô (đội cùng chỗ).

⚠ Hiện vật của hai phương pháp — bảng đối chiếu: | Vai trò | Thác nước | Agile | |---|---|---| | ⚠ Định hướng ban đầu | ⚠ ĐIỀU LỆ DỰ ÁN | ⚠ TUYÊN NGÔN TẦM NHÌN SẢN PHẨM | | ⚠ Biện minh đầu tư | ⚠ TÌNH HUỐNG KINH DOANH | ⚠ TÌNH HUỐNG KINH DOANH — dùng chung | | ⚠ Xác định việc phải làm | ⚠ đường cơ sở phạm vi, WBS | ⚠ backlog sản phẩm, câu chuyện người dùng | | ⚠ Lịch | ⚠ đường cơ sở tiến độ, sơ đồ Gantt | ⚠ lộ trình phát hành, kế hoạch phát hành | | ⚠ Theo dõi tiến độ | ⚠ báo cáo tiến độ, giá trị thu được | ⚠ biểu đồ burndown/burnup, bảng Kanban | | ⚠ Rút kinh nghiệm | ⚠ sổ bài học | ⚠ hồi cứu — dùng chung khái niệm, khác nhịp độ | | ⚠ Điểm chung quan trọng | ⚠ tình huống kinh doanh và bài học kinh nghiệm thuộc CẢ HAI — đó là lý do chúng là nhiễu tốt trong câu hỏi loại này | |

⚠ Tuyên ngôn tầm nhìn sản phẩm — nội dung và mục đích: | Khía cạnh | Nội dung | |---|---| | ⚠ Trả lời câu hỏi | ⚠ sản phẩm này dành cho AI, giải quyết vấn đề GÌ, khác biệt ở ĐÂU | | ⚠ Độ dài | ⚠ ngắn — thường một đoạn, đủ để cả đội thuộc | | ⚠ Ai sở hữu | ⚠ CHỦ SẢN PHẨM | | ⚠ Dùng khi nào | ⚠ mỗi lần cần quyết xem một tính năng có đáng làm không | | ⚠ Vì sao agile cần nó | ⚠ agile không chốt phạm vi từ đầu, nên phải có một la bàn thay thế | | ⚠ Áp dụng cho dự án trong đề | ⚠ "ứng dụng giúp sinh viên quốc tế kết nối với sinh viên trong trường" chính là hạt nhân của một tuyên ngôn tầm nhìn |

⚠ Chuyển từ thác nước sang agile — điều người có kinh nghiệm thác nước hay vấp: | Thói quen cũ | Cần đổi thành | |---|---| | ⚠ Chốt phạm vi đầy đủ trước khi làm | ⚠ chốt TẦM NHÌN, để phạm vi tiến hoá | | ⚠ Kế hoạch chi tiết cho cả dự án | ⚠ chi tiết cho vòng lặp gần, thô cho phần xa | | ⚠ Thay đổi là thứ phải kiểm soát | ⚠ thay đổi là thứ được kỳ vọng | | ⚠ Quản lý dự án phân việc | ⚠ đội tự tổ chức — liên hệ #26460 cùng lô | | ⚠ Điều KHÔNG đổi | ⚠ vẫn cần biết vì sao làm dự án (tình huống kinh doanh) và vẫn phải học từ những gì đã qua (bài học kinh nghiệm) |

Từ khoá nhận diện:

"tuyên ngôn tầm nhìn sản phẩm" → ⚠ AGILE, không có trong thác nước "đường cơ sở phạm vi, WBS" → ⚠ thác nước "tình huống kinh doanh, bài học kinh nghiệm" → ⚠ DÙNG CHUNG cả hai câu hỏi "cái nào KHÔNG" → ⚠ chấm đúng-sai từng cái, chọn cái lẻ loi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội của bạn có phát biểu được tầm nhìn sản phẩm trong một câu không | | | Khi phải bỏ bớt một tính năng, bạn dựa vào đâu để quyết | ⚠ nếu không có tầm nhìn thì thường dựa vào ai nói to nhất | | Bạn có đang mang thói quen chốt phạm vi quá sớm vào một dự án agile không | |

Và điều mà việc chuyển sang agile đòi hỏi nhiều nhất ở một người quen thác nước: không phải học thêm hiện vật mới, mà là chấp nhận rằng bản kế hoạch chi tiết bạn từng tự hào chính là thứ phải bỏ lại.

Câu 22 Process
Zane is a project manager at Camera Corporation and is planning a new project. The project is to create a new digital camera that is tiny, durable, and has a high resolution for photographers. During a recent stakeholder meeting to prioritize the product features, the stakeholders told Zane that every feature was of the highest priority. What should Zane do in this situation?
  1. A Agree, but assign different priorities on his own.
  2. B Prioritize every task as high.
  3. C Work with the stakeholders to stack rank the tasks.
  4. D Escalate the issue to the steering committee.
Xem giải thích

Đáp án

C — Làm việc CÙNG các bên liên quan để XẾP HẠNG TUYỆT ĐỐI (stack rank) các hạng mục.

Vì sao đúng

⚠ Vì sao xếp hạng tuyệt đối là cách thoát duy nhất: | Lý do | Nội dung | |---|---| | ⚠ "Mọi thứ đều ưu tiên cao nhất" = KHÔNG có ưu tiên nào | ⚠ ưu tiên là khái niệm SO SÁNH, không phải nhãn dán | | ⚠ Xếp hạng tuyệt đối buộc phải chọn: 1, 2, 3… không có đồng hạng | ⚠ loại bỏ khả năng trốn tránh quyết định | | ⚠ Làm CÙNG bên liên quan, không làm thay họ | ⚠ giữ quyền quyết định ở đúng chỗ, và họ sẽ cam kết với kết quả | | ⚠ Đây là kỹ thuật thúc đẩy (facilitation) — kỹ năng lõi của quản lý dự án | | | ⚠ Kết luận | ⚠ giải quyết được vấn đề mà không tước quyền của ai |

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

  • A (đồng ý, rồi TỰ MÌNH gán mức ưu tiên khác nhau) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó có vẻ thực dụng: ai đó phải quyết, và Zane là người biết dự án nhất: ⚠ nhưng ⚠ anh ĐỒNG Ý ngoài mặt rồi làm ngược lại sau lưng ⚠ — vừa không trung thực, vừa tước quyền quyết định của bên liên quan; ⚠ và khi họ phát hiện ra, niềm tin mất còn khó lấy lại hơn cả việc phải họp thêm một buổi.

  • B (đặt mọi hạng mục ở mức cao) — ⚠ chấp nhận tình trạng vô nghĩa; ⚠ đội sẽ tự quyết ngầm theo thứ tự nào tiện nhất.

  • D (LEO THANG lên ban chỉ đạo) — ⚠ leo thang quá sớm; ⚠ đây là việc Zane hoàn toàn có thể thúc đẩy được, leo thang chỉ dành cho việc vượt thẩm quyền — liên hệ #26442 cùng lô.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26436 cùng lô (ưu tiên theo TÁC ĐỘNG chứ không theo cấp bậc bên liên quan), ⚠ #26445 cùng lô (kỹ thuật nhóm danh nghĩa), ⚠ #26471 cùng lô (xếp ưu tiên backlog sau khi xét rủi ro), ⚠ #26440 cùng lô (thu ý kiến riêng rồi họp lại).

⚠ Các kỹ thuật XẾP ƯU TIÊN thường gặp trong đề PMP: | Kỹ thuật | Cách làm | Ưu điểm | |---|---|---| | ⚠ XẾP HẠNG TUYỆT ĐỐI (stack ranking) | ⚠ sắp thành một danh sách duy nhất, không đồng hạng | ⚠ buộc phải chọn — đáp án của câu này | | ⚠ MoSCoW | ⚠ Bắt buộc / Nên có / Có thì tốt / Lần này không | ⚠ dễ hiểu, nhưng dễ bị nhồi hết vào "Bắt buộc" | | ⚠ Mô hình Kano | ⚠ cơ bản / hiệu năng / gây thích thú | ⚠ nhìn từ góc độ cảm nhận của khách hàng | | ⚠ So sánh từng cặp | ⚠ so hai hạng mục một lần, tổng hợp lại | ⚠ rất chính xác nhưng tốn thời gian | | ⚠ 100 điểm | ⚠ mỗi người có 100 điểm để chia cho các hạng mục | ⚠ buộc đánh đổi bằng nguồn lực hữu hạn | | ⚠ Điểm chung của mọi kỹ thuật hiệu quả | ⚠ chúng đều tạo ra một sự KHAN HIẾM NHÂN TẠO — vì không khan hiếm thì không ai chịu chọn |

⚠ Vì sao "tất cả đều quan trọng nhất" lại hay xảy ra: | Nguyên nhân | Nội dung | |---|---| | ⚠ Mỗi bên liên quan chỉ nhìn phần của mình | ⚠ và phần của mình thì luôn quan trọng | | ⚠ Sợ rằng hạ ưu tiên nghĩa là bị bỏ hẳn | ⚠ cần nói rõ: xếp sau không phải là loại bỏ | | ⚠ Không ai muốn là người nói "cái của tôi ít quan trọng hơn" | ⚠ áp lực xã hội trong phòng họp | | ⚠ Chưa có ràng buộc thực tế nào được đặt lên bàn | ⚠ không có trần ngân sách hay thời gian thì không có lý do để chọn | | ⚠ Cách phá thế bế tắc | ⚠ đưa RÀNG BUỘC ra trước: "chúng ta chỉ làm được sáu tính năng trong quý này — sáu cái nào?" — câu hỏi đổi từ tầm quan trọng sang lựa chọn, và người ta trả lời được |

⚠ Cách Zane nên điều hành buổi xếp hạng: | Bước | Nội dung | |---|---| | ⚠ 1. Nói rõ ràng buộc thật | ⚠ thời gian, ngân sách, năng lực đội | | ⚠ 2. Thống nhất TIÊU CHÍ xếp hạng trước | ⚠ giá trị kinh doanh, rủi ro, phụ thuộc kỹ thuật, tuân thủ | | ⚠ 3. Thu ý kiến riêng trước khi thảo luận chung | ⚠ tránh hiệu ứng người nói to nhất — liên hệ #26440 và #26445 cùng lô | | ⚠ 4. Xếp thành danh sách duy nhất, công khai | | | ⚠ 5. Ghi lại LÝ DO của thứ tự | ⚠ để lần sau không phải tranh luận lại từ đầu | | ⚠ Vai trò của Zane | ⚠ NGƯỜI THÚC ĐẨY, không phải người quyết — anh giữ tiến trình, họ giữ nội dung |

Từ khoá nhận diện:

"mọi thứ đều ưu tiên cao nhất" → ⚠ CÙNG HỌ XẾP HẠNG TUYỆT ĐỐI "tự mình gán ưu tiên" → ⚠ tước quyền, và ở đây còn kèm việc đồng ý giả "để nguyên tất cả ở mức cao" → ⚠ chấp nhận tình trạng vô nghĩa "leo thang" → ⚠ chỉ khi vượt thẩm quyền, không phải khi việc còn thúc đẩy được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách ưu tiên của bạn có hạng mục nào đồng hạng không | ⚠ có đồng hạng là chưa xếp xong | | Bên liên quan của bạn có biết ràng buộc thật không | ⚠ không biết thì họ không có lý do để chọn | | Ai đang thực sự quyết thứ tự làm việc trong dự án của bạn | ⚠ nếu là lập trình viên đang chọn việc dễ nhất thì bạn chưa có ưu tiên |

Và điều mà một danh sách "tất cả đều ưu tiên cao" luôn dẫn tới: đội vẫn phải chọn thứ tự làm — chỉ là bây giờ họ chọn một mình, không có bạn, và không ai biết dựa trên tiêu chí gì.

Câu 23 Process
Margaret is the project manager for the Momentum Project, which will affect multiple lines of business when it is finished. So that the work does not affect current business cycles, Margaret has decided to schedule each project milestone to end. This is an example of which of the following choices?
  1. A Constraint
  2. B Expert judgment
  3. C Soft logic
  4. D WBS scheduling
Xem giải thích

Đáp án

C — LOGIC MỀM (soft logic — phụ thuộc tuỳ ý).

Vì sao đúng

⚠ Vì sao đây là logic mềm: | Lý do | Nội dung | |---|---| | ⚠ Margaret TỰ CHỌN thời điểm kết thúc từng mốc | ⚠ không có gì về mặt kỹ thuật bắt buộc phải như vậy | | ⚠ Lý do là THUẬN TIỆN cho kinh doanh, không phải bắt buộc vật lý | ⚠ để không đụng chu kỳ kinh doanh đang chạy | | ⚠ Phụ thuộc TUỲ Ý = do đội hoặc tổ chức quyết định | ⚠ dựa trên thực hành tốt hoặc bối cảnh, có thể đổi được | | ⚠ Đổi lại được nếu hoàn cảnh đổi | ⚠ đó chính là dấu hiệu phân biệt với logic cứng | | ⚠ Kết luận | ⚠ một lựa chọn có chủ ý của quản lý dự án, không phải ràng buộc từ bên ngoài |

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

  • A (RÀNG BUỘC — constraint) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ chu kỳ kinh doanh nghe rất giống một ràng buộc thật của tổ chức: ⚠ nhưng ⚠ ràng buộc là thứ ÁP TỪ NGOÀI VÀO mà dự án phải chịu ⚠ — nếu ban lãnh đạo ra lệnh "không được động vào hệ thống trong mùa cao điểm" thì đó là ràng buộc; ⚠ ở đây chính Margaret quyết định cách sắp lịch, nên đó là lựa chọn về trình tự, tức logic mềm.

  • B (PHÁN ĐOÁN CHUYÊN GIA) — ⚠ là một CÔNG CỤ dùng để ra quyết định, không phải TÊN GỌI của loại phụ thuộc; ⚠ Margaret có thể đã dùng phán đoán chuyên gia để chọn, nhưng đề hỏi kết quả là loại gì.

  • D ("WBS scheduling") — ⚠ không phải thuật ngữ chuẩn; ⚠ WBS phân rã công việc, không xếp lịch.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu đề bị CỤT: "Margaret has decided to schedule each project milestone to end." — thiếu phần sau chữ "to end" (nhiều khả năng là "to end after each business cycle" hoặc tương tự) ⚠ — ⚠ vẫn trả lời được vì bối cảnh đủ rõ: cô chủ động sắp lịch để tránh chu kỳ kinh doanh; ⚠ cùng loại lỗi với #26437 cùng lô (tên dự án không nhất quán) và #26306 lô 191 (chỉ có ba phương án).

Ghi nhớ

⚠ Đối chiếu: ⚠ #26454 cùng lô (nén tiến độ — fast-tracking chỉ làm được với logic MỀM), ⚠ #26413 lô 193 (ước lượng từ dưới lên), ⚠ #26448 cùng lô (ước lượng thời lượng).

⚠ BỐN loại phụ thuộc — bảng đầy đủ: | Loại | Còn gọi là | Nguồn gốc | Ví dụ | |---|---|---|---| | ⚠ BẮT BUỘC | ⚠ logic CỨNG | ⚠ bản chất công việc | ⚠ phải đổ móng trước khi xây tường | | ⚠ TUỲ Ý | ⚠ logic MỀM, ưu tiên | ⚠ lựa chọn của đội/tổ chức | ⚠ câu này — sắp mốc theo chu kỳ kinh doanh | | ⚠ BÊN NGOÀI | | ⚠ ngoài tầm kiểm soát dự án | ⚠ chờ giấy phép của cơ quan nhà nước | | ⚠ BÊN TRONG | | ⚠ trong tầm kiểm soát dự án | ⚠ chờ đội khác trong công ty bàn giao | | ⚠ Cách phân loại | ⚠ hai trục độc lập: bắt buộc/tuỳ ý và trong/ngoài — một phụ thuộc luôn có một giá trị ở mỗi trục | | | | ⚠ Vì sao quan trọng | ⚠ chỉ logic MỀM mới bỏ được để làm song song — fast-tracking một logic CỨNG là việc bất khả thi về vật lý, liên hệ #26454 cùng lô | | |

⚠ Phân biệt PHỤ THUỘC và RÀNG BUỘC — hai phương án đầu của câu này: | | Phụ thuộc | Ràng buộc | |---|---|---| | ⚠ Là gì | ⚠ quan hệ THỨ TỰ giữa hai công việc | ⚠ GIỚI HẠN áp lên dự án | | ⚠ Ai đặt ra | ⚠ bản chất công việc hoặc lựa chọn của đội | ⚠ thường là bên ngoài: ngân sách, hạn chót, luật, chính sách | | ⚠ Ví dụ | ⚠ B phải sau A | ⚠ phải xong trước 31/12; ngân sách tối đa 2 triệu | | ⚠ Đổi được không | ⚠ logic mềm thì đổi được, logic cứng thì không | ⚠ phải xin phê duyệt mới đổi được | | ⚠ Trong tình huống này | ⚠ Margaret QUYẾT ĐỊNH trình tự → phụ thuộc tuỳ ý | ⚠ nếu ban lãnh đạo CẤM động vào mùa cao điểm → khi đó mới là ràng buộc |

⚠ Vì sao tránh chu kỳ kinh doanh là quyết định đúng của Margaret: | Lý do | Nội dung | |---|---| | ⚠ Dự án ảnh hưởng NHIỀU MẢNG kinh doanh | ⚠ đề nói rõ | | ⚠ Gián đoạn trong mùa cao điểm gây thiệt hại thật | ⚠ và thiệt hại đó tính vào dự án dù dự án không gây trực tiếp | | ⚠ Bên liên quan sẽ hợp tác hơn khi họ không bận | ⚠ liên hệ #26443 cùng lô | | ⚠ Đây là quản lý rủi ro chủ động | ⚠ né tránh rủi ro bằng cách sắp lịch | | ⚠ Cái giá phải trả | ⚠ lịch dài hơn — logic mềm luôn có giá; điều quan trọng là biết mình đang trả giá đó một cách có ý thức, và bỏ được nó khi cần rút ngắn |

Từ khoá nhận diện:

"quản lý dự án QUYẾT ĐỊNH sắp thứ tự cho thuận tiện" → ⚠ LOGIC MỀM / phụ thuộc tuỳ ý "về mặt vật lý bắt buộc phải theo thứ tự" → ⚠ logic cứng / phụ thuộc bắt buộc "hạn chót, trần ngân sách, quy định cấm" → ⚠ ràng buộc "muốn fast-tracking" → ⚠ chỉ bỏ được logic MỀM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong lịch của bạn, phụ thuộc nào là cứng và phụ thuộc nào là mềm | ⚠ rất nhiều đội không phân biệt, nên tưởng lịch không rút ngắn được | | Có phụ thuộc mềm nào đang kéo dài đường găng không | ⚠ đó là chỗ đầu tiên nên xem khi cần rút ngắn | | Bạn có ghi LÝ DO của các phụ thuộc mềm không | ⚠ không ghi thì vài tháng sau không ai dám bỏ |

Và điều đáng nhớ nhất về logic mềm: nó là những quyết định của con người mặc bộ đồ của quy luật tự nhiên — và phần lớn thời gian thừa trong một bản lịch nằm đúng ở đó.

Câu 24 People
Norah is the project manager for the Schroeder Savings project, an important project that affects a line of business. The customer is uneasy about the project's success. Of the following, which is probably not the customer's main concern?
  1. A Cost
  2. B Personality conflicts
  3. C Schedule
  4. D Project priorities
Xem giải thích

Đáp án

B — XUNG ĐỘT TÍNH CÁCH (personality conflicts) — đây có lẽ KHÔNG phải mối lo chính của khách hàng.

Vì sao đúng

⚠ Vì sao xung đột tính cách không phải mối lo của khách hàng: | Lý do | Nội dung | |---|---| | ⚠ Đó là vấn đề NỘI BỘ của đội dự án | ⚠ thuộc trách nhiệm của quản lý dự án, không phải của khách hàng | | ⚠ Khách hàng quan tâm tới KẾT QUẢ, không quan tâm tới quá trình | ⚠ họ mua sản phẩm, không mua không khí làm việc | | ⚠ Khách hàng thường KHÔNG BIẾT có xung đột trong đội | ⚠ và cũng không nên phải biết | | ⚠ Ba phương án còn lại đều ảnh hưởng trực tiếp tới khách hàng | ⚠ tiền họ trả, thời điểm họ nhận, thứ họ nhận trước | | ⚠ Kết luận | ⚠ câu hỏi phủ định — chọn cái lẻ loi, ở đây là cái duy nhất hướng vào nội bộ |

⚠ Lưu ý quan trọng: ⚠ "không phải mối lo CHÍNH của khách hàng" KHÔNG có nghĩa là "không quan trọng" ⚠ — xung đột trong đội là mối lo rất chính đáng của quản lý dự án, vì nó ảnh hưởng tới đúng ba thứ kia; ⚠ đề chỉ hỏi nó đứng ở góc nhìn của ai.

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

  • D (ƯU TIÊN CỦA DỰ ÁN) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nghe có vẻ là chuyện nội bộ của bên thực hiện: ⚠ nhưng ⚠ ưu tiên quyết định KHÁCH HÀNG NHẬN ĐƯỢC GÌ TRƯỚC ⚠ — và với một dự án ảnh hưởng tới cả một mảng kinh doanh, thứ tự bàn giao là chuyện sống còn; ⚠ liên hệ #26464 cùng lô — xếp ưu tiên là việc làm cùng bên liên quan chính vì lý do này.

  • A (CHI PHÍ) — ⚠ mối lo cổ điển nhất của khách hàng; ⚠ tiền của họ.

  • C (TIẾN ĐỘ) — ⚠ cũng vậy; ⚠ họ có kế hoạch kinh doanh phụ thuộc vào ngày bàn giao.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26436 cùng lô (ưu tiên theo tác động), ⚠ #26443 cùng lô (hỏi bên liên quan điều gì đang khó), ⚠ #26453 cùng lô (kế hoạch gắn kết bên liên quan), ⚠ #26444 cùng lô (truyền phát thông tin).

⚠ Khách hàng lo gì và quản lý dự án lo gì — hai danh sách khác nhau: | Mối lo | Khách hàng | Quản lý dự án | |---|---|---| | ⚠ Chi phí | ⚠ CÓ — tiền của họ | ⚠ có | | ⚠ Tiến độ | ⚠ CÓ — kế hoạch của họ phụ thuộc | ⚠ có | | ⚠ Phạm vi và chất lượng | ⚠ CÓ — thứ họ nhận được | ⚠ có | | ⚠ Ưu tiên bàn giao | ⚠ CÓ — nhận gì trước | ⚠ có | | ⚠ Xung đột trong đội | ⚠ KHÔNG — họ không nhìn thấy | ⚠ CÓ, rất nhiều | | ⚠ Ai làm việc gì trong đội | ⚠ KHÔNG | ⚠ có | | ⚠ Nguyên tắc | ⚠ khách hàng lo về KẾT QUẢ, quản lý dự án lo cả kết quả lẫn QUÁ TRÌNH tạo ra nó | |

⚠ Nhưng xung đột trong đội vẫn đến tay khách hàng — bằng đường vòng: | Đường đi | Nội dung | |---|---| | ⚠ Xung đột → giao tiếp kém → hiểu sai yêu cầu | ⚠ khách hàng thấy: sản phẩm sai | | ⚠ Xung đột → làm lại → chi phí tăng | ⚠ khách hàng thấy: vượt ngân sách, liên hệ #26461 cùng lô | | ⚠ Xung đột → người giỏi bỏ đi → chậm | ⚠ khách hàng thấy: trễ hạn | | ⚠ Kết luận thực dụng | ⚠ khách hàng không lo về xung đột đội, nhưng họ sẽ nhận đủ HẬU QUẢ của nó — đó là lý do việc quản lý xung đột thuộc về bạn chứ không thuộc về họ |

⚠ Cách trấn an một khách hàng đang lo lắng: | Việc | Nội dung | |---|---| | ⚠ Hỏi cụ thể họ lo điều gì | ⚠ "lo lắng" là cảm giác, phải quy về vấn đề cụ thể mới xử lý được — liên hệ #26443 cùng lô | | ⚠ Đưa DỮ LIỆU thay vì lời trấn an | ⚠ chỉ số hiệu năng, tiến độ so với đường cơ sở — liên hệ #26468 cùng lô | | ⚠ Tăng TẦN SUẤT báo cáo cho riêng họ | ⚠ cập nhật kế hoạch gắn kết bên liên quan | | ⚠ Nói cả tin xấu, nói sớm | ⚠ khách hàng mất niềm tin vì bị bất ngờ, không phải vì tin xấu | | ⚠ Điều KHÔNG nên làm | ⚠ hứa rằng mọi thứ sẽ ổn khi bạn chưa có căn cứ — một lời hứa hỏng làm hại nhiều hơn mười báo cáo trung thực |

Từ khoá nhận diện:

"xung đột tính cách trong đội" → ⚠ mối lo của QUẢN LÝ DỰ ÁN, không phải của khách hàng "chi phí, tiến độ, ưu tiên" → ⚠ mối lo trực tiếp của khách hàng câu hỏi "có lẽ KHÔNG phải" → ⚠ tìm cái đứng ở góc nhìn khác với ba cái kia "khách hàng lo lắng" → ⚠ hỏi cụ thể, đưa dữ liệu, tăng tần suất báo cáo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khách hàng của bạn đang lo điều gì cụ thể | ⚠ nếu bạn không trả lời được thì chưa hỏi đủ | | Báo cáo của bạn có số liệu hay chỉ có lời | | | Có vấn đề nội bộ nào đang âm thầm đi ra tới khách hàng không | ⚠ qua ba đường ở bảng trên |

Và ranh giới đáng nhớ giữa hai danh sách mối lo: khách hàng không cần biết đội bạn hoà thuận tới đâu — nhưng họ sẽ là người đầu tiên nhận hoá đơn nếu bạn không giữ được điều đó.

Câu 25 People
As the project manager of an agile project at Beverly Logistics, Raj wants the team to be co-located. Of the following, which describes when an agile team is considered co-located?
  1. A Co-located means all team members are in the same building, on the same floor
  2. B All team members on the same campus is being co-located
  3. C Being co-located is when all team members are in the same city
  4. D Co-located means all team members are located within 33 feet of each other and have no barriers.
Xem giải thích

Đáp án

D — Cùng chỗ nghĩa là mọi thành viên ở trong phạm vi khoảng 33 feet (≈10 mét) của nhau và KHÔNG có vách ngăn.

Vì sao đúng

⚠ Vì sao con số 33 feet là chuẩn được nhắc tới: | Lý do | Nội dung | |---|---| | ⚠ Xuất phát từ nghiên cứu của Alistair Cockburn về GIAO TIẾP THẨM THẤU | ⚠ osmotic communication — nghe được cuộc trò chuyện của người khác mà không phải cố nghe | | ⚠ Ngoài khoảng cách đó, người ta không còn tình cờ nghe thấy nhau | ⚠ và thông tin phải đi qua kênh chính thức mới tới được | | ⚠ "KHÔNG CÓ VÁCH NGĂN" quan trọng ngang khoảng cách | ⚠ hai người cách nhau 5 mét nhưng có tường ở giữa thì không phải cùng chỗ | | ⚠ Mục đích cuối cùng là ĐỘ TRỄ GIAO TIẾP GẦN BẰNG KHÔNG | ⚠ quay ghế là hỏi được, không cần đặt lịch họp | | ⚠ Kết luận | ⚠ định nghĩa duy nhất trong bốn phương án nói tới cả khoảng cách lẫn rào cản |

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

  • A (cùng TOÀ NHÀ, cùng TẦNG) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cùng tầng nghe đã rất gần rồi và nhiều tổ chức thật vẫn gọi đó là cùng chỗ: ⚠ nhưng ⚠ một tầng có thể dài cả trăm mét và đầy vách ngăn ⚠ — hai đội ở hai đầu cùng một tầng gần như không bao giờ nghe thấy nhau; ⚠ khoảng cách và rào cản mới là thứ quyết định, không phải nhãn địa lý.

  • B (cùng KHUÔN VIÊN) — ⚠ rộng hơn nữa; ⚠ đi từ toà này sang toà kia đã là một quyết định, không còn là tình cờ.

  • C (cùng THÀNH PHỐ) — ⚠ quá rộng; ⚠ đây thực chất là mô tả một đội phân tán.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26439 cùng lô (bố trí đội cùng chỗ cho công việc cần thao tác trực tiếp), ⚠ #26421/#26366/#26333 (bộ ba câu về công cụ cho đội từ xa), ⚠ #26456 cùng lô (đội từ xa và cách phát âm tên), ⚠ #26294 lô 191 (kênh giao tiếp).

⚠ Vì sao cùng chỗ có giá trị trong agile: | Lợi ích | Nội dung | |---|---| | ⚠ GIAO TIẾP THẨM THẤU | ⚠ nghe được vấn đề của người khác và giúp được ngay, dù không ai hỏi bạn | | ⚠ Độ trễ gần bằng 0 | ⚠ câu hỏi được trả lời trong 10 giây thay vì 4 giờ | | ⚠ Băng thông cao nhất trong mọi kênh | ⚠ mặt đối mặt có cả giọng nói, nét mặt, cử chỉ, bảng trắng | | ⚠ Xây quan hệ và lòng tin nhanh hơn | ⚠ liên hệ #26469 cùng lô — thiếu lòng tin là gốc của mọi rối loạn đội | | ⚠ Bảng thông tin lớn (big visible chart) phát huy tác dụng | ⚠ bảng Kanban trên tường chỉ hữu ích khi mọi người đi ngang nó hằng ngày | | ⚠ Câu nói kinh điển của Tuyên ngôn Agile | ⚠ "cách truyền đạt thông tin hiệu quả nhất trong và với đội phát triển là trò chuyện MẶT ĐỐI MẶT" |

⚠ Khi không thể cùng chỗ — đội PHÂN TÁN cần bù bằng gì: | Việc cần bù | Cách | |---|---| | ⚠ Mất giao tiếp thẩm thấu | ⚠ kênh chat luôn mở, họp đứng hằng ngày qua video | | ⚠ Mất bảng thông tin trên tường | ⚠ bảng điện tử ai cũng xem được — liên hệ #26333 lô 192 | | ⚠ Mất tình cờ gặp nhau | ⚠ chủ động tạo dịp: giờ cà phê ảo, ghép cặp làm việc | | ⚠ Mất tín hiệu phi ngôn ngữ | ⚠ bật camera, và viết rõ hơn bình thường | | ⚠ Lệch múi giờ | ⚠ công cụ bất đồng bộ — liên hệ #26421 lô 193 | | ⚠ Nhận xét thực tế | ⚠ đội phân tán làm việc tốt được, nhưng phải LÀM CÓ CHỦ Ý những thứ đội cùng chỗ có được miễn phí — bỏ qua phần chủ ý đó là lý do phần lớn đội từ xa hoạt động kém |

⚠ Ba mức bố trí đội — thang đo thực dụng: | Mức | Đặc điểm | Chất lượng giao tiếp | |---|---|---| | ⚠ CÙNG CHỖ THẬT | ⚠ trong 10 mét, không vách ngăn | ⚠ cao nhất | | ⚠ GẦN NHAU | ⚠ cùng tầng, cùng toà, cùng khuôn viên | ⚠ trung bình — gặp được nhưng phải chủ động | | ⚠ PHÂN TÁN | ⚠ khác thành phố, khác quốc gia, khác múi giờ | ⚠ thấp nhất, phải bù bằng công cụ và quy ước | | ⚠ Điều đề muốn kiểm tra | ⚠ rằng "cùng chỗ" là một định nghĩa CÓ NGƯỠNG CỤ THỂ, không phải một cảm giác về sự gần gũi | |

Từ khoá nhận diện:

"trong 33 feet / 10 mét, không có vách ngăn" → ⚠ CÙNG CHỖ theo nghĩa agile "cùng tầng / cùng toà nhà / cùng khuôn viên" → ⚠ gần nhau, chưa phải cùng chỗ "cùng thành phố" → ⚠ thực chất là phân tán "giao tiếp thẩm thấu" → ⚠ lợi ích cốt lõi mà cùng chỗ mang lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có nghe thấy nhau nói chuyện không | ⚠ nếu không thì bạn chưa cùng chỗ, dù ngồi cùng tầng | | Có vách ngăn hay tủ nào chắn giữa các thành viên không | | | Một câu hỏi kỹ thuật của đội bạn mất bao lâu để được trả lời | ⚠ thước đo thực tế nhất của khoảng cách |

Và điều mà con số 10 mét thực sự đo: không phải khoảng cách vật lý, mà là xác suất một người nghe thấy vấn đề của người khác trước khi vấn đề đó kịp lớn lên.

Câu 26 People
You are the project manager of the JNG Project for your organization. This is a high-profile project and several key stakeholders are interested in the project work and progress. One of your stakeholders, Julie, has heard that your project is currently one month behind schedule, and she fears the project may be slipping even farther behind schedule. Julie would like to determine if the rumors are true, and she wants a definitive answer. How can Julie best do this?
  1. A Review the project's key performance indicators.
  2. B Perform earned value management on the current schedule.
  3. C Call the project team members and demand answers.
  4. D Interview the project team collectively without you.
Xem giải thích

Đáp án

A — Xem các CHỈ SỐ HIỆU NĂNG CHÍNH (KPI) của dự án.

Vì sao đúng

⚠ Vì sao KPI là cách tốt nhất cho Julie: | Lý do | Nội dung | |---|---| | ⚠ Julie muốn một câu trả lời DỨT KHOÁT, không muốn tin đồn | ⚠ chỉ dữ liệu mới cho được điều đó | | ⚠ KPI là số liệu ĐÃ ĐƯỢC ĐO và BÁO CÁO CHÍNH THỨC | ⚠ không phụ thuộc vào ai đang kể chuyện | | ⚠ Chúng cho thấy cả TÌNH TRẠNG hiện tại lẫn XU HƯỚNG | ⚠ đúng hai điều Julie hỏi: có trễ thật không, và có đang trễ thêm không | | ⚠ Julie tiếp cận được mà không phải làm phiền đội | ⚠ báo cáo hiệu năng công việc là thứ dành cho bên liên quan | | ⚠ Kết luận | ⚠ đúng người, đúng kênh, đúng loại bằng chứng |

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

  • B (tự thực hiện QUẢN LÝ GIÁ TRỊ THU ĐƯỢC trên lịch hiện tại) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ giá trị thu được ĐÚNG LÀ công cụ đo chênh lệch tiến độ, và SPI trả lời chính xác câu hỏi của Julie: ⚠ nhưng ⚠ Julie là BÊN LIÊN QUAN, không phải người quản lý dự án ⚠ — cô không có dữ liệu gốc (PV, EV, AC) để tự tính; ⚠ và quan trọng hơn, giá trị thu được vốn đã nằm trong bộ KPI mà dự án báo cáo, nên tự làm lại là làm trùng việc bằng dữ liệu kém hơn.

  • C (gọi thẳng cho các thành viên đội và ĐÒI câu trả lời) — ⚠ đi vòng qua quản lý dự án, gây áp lực lên đội; ⚠ và câu trả lời nhận được sẽ là ý kiến cá nhân, không đáng tin hơn tin đồn.

  • D (phỏng vấn cả đội mà KHÔNG có mặt bạn) — ⚠ cũng đi vòng, còn phá vỡ niềm tin; ⚠ và vẫn không cho ra con số.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26459 cùng lô (đọc CPI), ⚠ #26462 cùng lô (CPI 0,96 và SPI 0,85), ⚠ #26308 lô 191 (từ SPI tính thời gian còn lại), ⚠ #26444 cùng lô (truyền phát thông tin tới bên liên quan), ⚠ #26466 cùng lô (mối lo của khách hàng).

⚠ Vì sao KPI tồn tại — và vì sao câu này thực ra là câu về BÁO CÁO: | Vấn đề | Nội dung | |---|---| | ⚠ Tin đồn xuất hiện khi thông tin chính thức không đủ hoặc không kịp | ⚠ Julie phải nghe đồn nghĩa là kênh báo cáo có vấn đề | | ⚠ KPI biến ý kiến thành số liệu | ⚠ "tôi nghe nói trễ một tháng" → SPI = 0,85 | | ⚠ Bên liên quan cần TRUY CẬP ĐƯỢC báo cáo | ⚠ để mặc định lấy thông tin từ nguồn đúng | | ⚠ Tần suất báo cáo ghi trong kế hoạch quản lý giao tiếp | ⚠ liên hệ #26453 cùng lô | | ⚠ Bài học cho quản lý dự án trong đề | ⚠ nếu một bên liên quan quan trọng phải đi hỏi tin đồn, việc cần sửa không phải là trả lời cô ấy — mà là sửa kênh báo cáo để lần sau cô không phải hỏi |

⚠ Các KPI tiến độ thường dùng: | Chỉ số | Cho biết | |---|---| | ⚠ SPI — chỉ số hiệu suất tiến độ | ⚠ < 1 là trễ; xu hướng qua các kỳ cho biết đang xấu đi hay tốt lên | | ⚠ SV — chênh lệch tiến độ | ⚠ EV − PV, tính bằng tiền | | ⚠ Mốc đạt được so với kế hoạch | ⚠ dễ hiểu nhất với bên liên quan không chuyên | | ⚠ Phần trăm hoàn thành so với đường cơ sở | | | ⚠ Tốc độ đội (trong agile) | ⚠ số điểm hoàn thành mỗi vòng lặp | | ⚠ Điều Julie thật sự cần | ⚠ không phải một con số mà là MỘT DÃY số theo thời gian — chỉ xu hướng mới trả lời được câu "có đang trễ thêm không" |

⚠ Ba cách bên liên quan lấy thông tin — thứ tự nên dùng: | Cách | Đánh giá | |---|---| | ⚠ 1. Đọc báo cáo hiệu năng chính thức / KPI | ⚠ đúng kênh, có dữ liệu, không làm phiền ai | | ⚠ 2. Hỏi quản lý dự án | ⚠ hợp lệ, nhất là khi cần diễn giải con số | | ⚠ 3. Hỏi thẳng thành viên đội | ⚠ chỉ nên khi có sự đồng thuận trước; làm sau lưng quản lý dự án là phá vỡ cấu trúc giao tiếp | | ⚠ Vì sao thứ tự quan trọng | ⚠ mỗi bước xuống dưới thì độ tin cậy của thông tin giảm và thiệt hại cho quan hệ tăng — phương án C và D của câu này nhảy thẳng xuống bậc cuối |

Từ khoá nhận diện:

"muốn câu trả lời dứt khoát, không muốn tin đồn" → ⚠ XEM KPI / báo cáo hiệu năng "bên liên quan tự tính giá trị thu được" → ⚠ không có dữ liệu gốc, và trùng việc "gọi thẳng cho đội, đòi câu trả lời" → ⚠ đi vòng, gây áp lực, không cho ra dữ liệu "phỏng vấn đội không có quản lý dự án" → ⚠ phá vỡ niềm tin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có tự xem được số liệu dự án không | ⚠ hay phải hỏi bạn mỗi lần | | Báo cáo của bạn có cho thấy XU HƯỚNG hay chỉ có ảnh chụp một thời điểm | | | Có tin đồn nào đang chạy trong tổ chức về dự án của bạn không | ⚠ có nghĩa là kênh chính thức đang chậm hơn kênh không chính thức — liên hệ #26379 lô 193 |

Và điều mà tình huống của Julie thực sự chẩn đoán: không phải là dự án đang trễ hay không, mà là thông tin về dự án đang đi tới bên liên quan bằng đường nào — và bạn có kiểm soát được đường đó không.

Câu 27 People
You are the project manager of the Fine Server Project for your organization and your project has been running smoothly for one month. One member of your team has recently been struggling with accomplishing his assigned tasks. Although his team members have asked him if anything is wrong, he only says that everything is fine. However, you recognize that the team member does need help but does not want to admit it. Which of Lencioni's Five Dysfunctions of a team best describes the scenario above?
  1. A Avoidance of Accountability
  2. B Fear of Conflict
  3. C Absence of Trust
  4. D Lack of Commitment
Xem giải thích

Đáp án

C — THIẾU LÒNG TIN (Absence of Trust) — rối loạn nền tảng trong mô hình của Lencioni.

Vì sao đúng

⚠ Vì sao đây đúng là thiếu lòng tin: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ Thành viên đang GẶP KHÓ với công việc được giao | ⚠ sự thật khách quan | | ⚠ Đồng đội đã HỎI anh có chuyện gì không | ⚠ đội đã mở cửa | | ⚠ Anh chỉ nói "mọi thứ ổn" | ⚠ che giấu điểm yếu | | ⚠ Anh CẦN giúp nhưng KHÔNG MUỐN THỪA NHẬN | ⚠ đó chính là định nghĩa của thiếu lòng tin theo Lencioni | | ⚠ Lòng tin ở đây = TIN CẬY DỰA TRÊN SỰ TỔN THƯƠNG | ⚠ dám nói "tôi không biết", "tôi sai", "tôi cần giúp" | | ⚠ Kết luận | ⚠ không phải anh không tin đồng đội về mặt đạo đức — anh không thấy an toàn khi để lộ điểm yếu |

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

  • A (NÉ TRÁNH TRÁCH NHIỆM GIẢI TRÌNH) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ bề ngoài trông đúng: anh không nhận trách nhiệm về việc mình không hoàn thành: ⚠ nhưng ⚠ rối loạn đó nói về việc CÁC THÀNH VIÊN KHÔNG DÁM CHẤT VẤN NHAU về hành vi và hiệu suất ⚠ — ở đây đồng đội ĐÃ chủ động hỏi anh, tức là họ không né tránh; ⚠ vấn đề nằm ở phía anh không mở lời, tức là ở tầng thấp nhất của mô hình.

  • B (SỢ XUNG ĐỘT) — ⚠ là tầng thứ hai: ⚠ đội tránh tranh luận thẳng thắn về ý tưởng; ⚠ đề không mô tả cuộc tranh luận nào bị né.

  • D (THIẾU CAM KẾT) — ⚠ là tầng thứ ba: ⚠ quyết định mơ hồ nên không ai thực sự theo; ⚠ đề không nói về quyết định nào.

⚠ Nguyên tắc quan trọng của mô hình Lencioni: ⚠ năm rối loạn XẾP CHỒNG lên nhau, và luôn phải chẩn đoán ở TẦNG THẤP NHẤT có dấu hiệu ⚠ — vì các tầng trên chỉ là hậu quả.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26384 lô 193 (mô hình Tuckman — giai đoạn phát triển đội), ⚠ #26320 lô 191 (an toàn tâm lý), ⚠ #26460 cùng lô (mô hình SCARF), ⚠ #26450 cùng lô (lắng nghe chủ động), ⚠ #26467 cùng lô (cùng chỗ giúp xây lòng tin).

⚠ NĂM RỐI LOẠN CỦA MỘT ĐỘI — Patrick Lencioni, từ dưới lên: | Tầng | Rối loạn | Biểu hiện | Hậu quả | |---|---|---|---| | ⚠ 1 (đáy) | ⚠ THIẾU LÒNG TIN | ⚠ giấu điểm yếu, không dám nói "tôi cần giúp" | ⚠ câu này | | ⚠ 2 | ⚠ SỢ XUNG ĐỘT | ⚠ hoà khí giả tạo, không tranh luận thẳng | ⚠ ý tưởng dở không bị phản biện | | ⚠ 3 | ⚠ THIẾU CAM KẾT | ⚠ gật đầu trong phòng họp, không làm khi ra ngoài | ⚠ quyết định mơ hồ | | ⚠ 4 | ⚠ NÉ TRÁNH TRÁCH NHIỆM GIẢI TRÌNH | ⚠ không ai chất vấn ai về hiệu suất | ⚠ tiêu chuẩn tụt dần | | ⚠ 5 (đỉnh) | ⚠ KHÔNG CHÚ TÂM TỚI KẾT QUẢ | ⚠ đặt cái tôi và mục tiêu cá nhân lên trước | ⚠ đội thua | | ⚠ Logic của tháp | ⚠ mỗi tầng là nguyên nhân của tầng trên — chữa từ đỉnh xuống là chữa triệu chứng; chữa từ đáy lên mới có tác dụng | | |

⚠ Quản lý dự án nên làm gì với tình huống này: | Việc | Nội dung | |---|---| | ⚠ Gặp RIÊNG, không chất vấn trước đội | ⚠ người đang giấu điểm yếu sẽ càng đóng chặt nếu bị hỏi công khai | | ⚠ Hỏi về CÔNG VIỆC, không hỏi về con người | ⚠ "phần này có chỗ nào chưa rõ không" dễ trả lời hơn "anh có sao không" | | ⚠ TỰ MÌNH làm gương trước | ⚠ người lãnh đạo thừa nhận mình từng sai là cách nhanh nhất xây lòng tin | | ⚠ Biến việc xin giúp thành chuyện BÌNH THƯỜNG | ⚠ ghép cặp làm việc, rà soát chéo định kỳ — không ai phải "xin" cả | | ⚠ KHÔNG trừng phạt người báo tin xấu | ⚠ một lần trừng phạt là đủ để cả đội im lặng trong nhiều tháng | | ⚠ Điều tuyệt đối tránh | ⚠ coi đây là vấn đề hiệu suất cá nhân và đưa vào đánh giá — làm vậy là xác nhận đúng nỗi sợ khiến anh im lặng ngay từ đầu |

⚠ Lencioni và Tuckman — hai mô hình về đội, khác nhau thế nào: | | Lencioni | Tuckman | |---|---|---| | ⚠ Mô tả | ⚠ các RỐI LOẠN cần chữa | ⚠ các GIAI ĐOẠN phát triển tự nhiên | | ⚠ Hướng | ⚠ chẩn đoán bệnh | ⚠ theo dõi trưởng thành | | ⚠ Năm/bốn thành phần | ⚠ lòng tin → xung đột → cam kết → giải trình → kết quả | ⚠ hình thành → bão táp → chuẩn hoá → thể hiện (→ giải tán) | | ⚠ Dùng khi | ⚠ đội đang trục trặc và cần biết trục trặc ở đâu | ⚠ muốn biết đội đang ở đâu trên đường trưởng thành | | ⚠ Liên hệ thú vị | ⚠ một đội "sợ xung đột" theo Lencioni là đội không bao giờ đi qua nổi giai đoạn BÃO TÁP của Tuckman — và vì thế không bao giờ tới được giai đoạn thể hiện | |

Từ khoá nhận diện:

"giấu điểm yếu, nói mọi thứ ổn khi không ổn" → ⚠ THIẾU LÒNG TIN "không dám tranh luận thẳng, hoà khí giả tạo" → ⚠ sợ xung đột "gật đầu rồi không làm" → ⚠ thiếu cam kết "không ai chất vấn ai" → ⚠ né tránh trách nhiệm giải trình quy tắc chẩn đoán → ⚠ chọn tầng THẤP NHẤT có dấu hiệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần gần nhất có người trong đội nói "tôi không biết" là khi nào | ⚠ không nhớ nổi là một câu trả lời đáng lo | | Bạn có bao giờ thừa nhận mình sai trước đội không | | | Người gặp khó trong đội bạn được phát hiện bằng cách nào | ⚠ họ tự nói, hay bạn phát hiện qua công việc trễ |

Và điều mà câu "mọi thứ đều ổn" thường thực sự nghĩa là: "tôi chưa tin rằng ở đây, thừa nhận mình cần giúp là an toàn" — và đó là câu trả lời về đội, không phải về người nói.

Câu 28 Process
Luis is the project manager for the Photo Past Project, a project similar to one he completed last year. His task is to electronically store thousands of historical photos for his hometown of Sarasota, Florida's historical society. In this project, quality is of the highest priority. Management expresses concern over why Luis has allotted so much time for project planning. What is Luis's response?
  1. A Planning for a project this large, with quality being a top priority, is mandatory.
  2. B More time is needed because this is a first-time, first-use project.
  3. C Quality is planned into a project, as opposed to being inspected into the project.
  4. D Quality audits are a part of planning time.
Xem giải thích

Đáp án

C — Chất lượng được LẬP KẾ HOẠCH VÀO dự án, chứ không phải được KIỂM TRA vào dự án.

Vì sao đúng

⚠ Vì sao đây là câu trả lời đúng của Luis: | Lý do | Nội dung | |---|---| | ⚠ Đề nói rõ CHẤT LƯỢNG là ưu tiên cao nhất | ⚠ nên lập luận phải xoay quanh chất lượng | | ⚠ Chất lượng đến từ QUY TRÌNH và THIẾT KẾ, không từ việc kiểm nhiều hơn | ⚠ kiểm tra chỉ phát hiện lỗi đã có | | ⚠ Thời gian lập kế hoạch là nơi quyết định tiêu chuẩn, quy trình, cách đo | ⚠ liên hệ #26441 cùng lô — công cụ lập kế hoạch chất lượng | | ⚠ Đây là nguyên lý nền của Deming và Juran | ⚠ và là quan điểm chính thức của PMI | | ⚠ Kết luận | ⚠ trả lời được đúng câu hỏi của ban lãnh đạo: vì sao thời gian đó XỨNG ĐÁNG |

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

  • B (cần thêm thời gian vì đây là dự án LẦN ĐẦU LÀM, LẦN ĐẦU DÙNG) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "first-time, first-use" là một khái niệm PMP có thật và là lý do chính đáng để cần thêm thời gian: ⚠ nhưng ⚠ đề nói rõ đây là dự án TƯƠNG TỰ một dự án Luis đã hoàn thành NĂM NGOÁI ⚠ — nên nó không phải lần đầu; ⚠ so sánh trực tiếp với #26241 lô 189, nơi "lần đầu làm, lần đầu dùng" là đáp án đúng vì bối cảnh thật sự mới.

  • A (dự án lớn với chất lượng ưu tiên cao thì lập kế hoạch là BẮT BUỘC) — ⚠ khẳng định mà không giải thích; ⚠ nói "bắt buộc" không trả lời câu hỏi "vì sao lâu thế".

  • D (kiểm toán chất lượng là một phần của thời gian lập kế hoạch) — ⚠ SAI VỀ SỰ THẬT: ⚠ kiểm toán chất lượng thuộc quy trình Quản lý chất lượng, nhóm Thực thi, không thuộc lập kế hoạch.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26241 lô 189 (lần đầu làm lần đầu dùng — nơi phương án B của câu này LÀ đáp án), ⚠ #26457 cùng lô (QA và QC), ⚠ #26461 cùng lô (chi phí phù hợp), ⚠ #26441 cùng lô (kiểm tra không phải công cụ lập kế hoạch chất lượng), ⚠ #26449 cùng lô (đào tạo là chi phí ngăn ngừa).

⚠ "Lập kế hoạch vào" so với "Kiểm tra vào" — nguyên lý cốt lõi: | | Lập kế hoạch chất lượng vào | Kiểm tra chất lượng vào | |---|---|---| | ⚠ Thời điểm | ⚠ TRƯỚC khi làm | ⚠ SAU khi làm | | ⚠ Việc làm | ⚠ đặt tiêu chuẩn, thiết kế quy trình, đào tạo, chọn công cụ | ⚠ đo, thử, tìm lỗi | | ⚠ Kết quả | ⚠ ít lỗi phát sinh | ⚠ lỗi được tìm ra rồi sửa | | ⚠ Chi phí | ⚠ thấp — chi phí ngăn ngừa | ⚠ cao — cộng thêm chi phí làm lại | | ⚠ Giới hạn | ⚠ cần thời gian trả trước | ⚠ không bao giờ tìm được 100% lỗi | | ⚠ Câu của Deming | ⚠ "đừng dựa vào kiểm tra hàng loạt để đạt chất lượng — hãy loại bỏ nhu cầu kiểm tra bằng cách xây chất lượng vào sản phẩm ngay từ đầu" | |

⚠ Thời gian lập kế hoạch của Luis được dùng vào việc gì: | Việc | Nội dung | |---|---| | ⚠ Xác định TIÊU CHUẨN chất lượng cho ảnh số hoá | ⚠ độ phân giải, định dạng, không gian màu, siêu dữ liệu | | ⚠ Thiết kế QUY TRÌNH xử lý hàng nghìn ảnh | ⚠ quy mô lớn thì quy trình sai một chút cũng nhân lên hàng nghìn lần | | ⚠ Chọn công cụ và thiết bị đạt chuẩn | | | ⚠ Lập kế hoạch KIỂM THỬ và lấy mẫu | ⚠ không thể kiểm 100% hàng nghìn ảnh — phải thiết kế cách lấy mẫu | | ⚠ Lên kế hoạch LƯU TRỮ và sao lưu dài hạn | ⚠ với tài liệu lịch sử, đây là yêu cầu chất lượng thật | | ⚠ Điểm mấu chốt | ⚠ với dự án số hoá quy mô lớn, một quyết định sai về định dạng ở tuần đầu buộc phải làm lại toàn bộ hàng nghìn ảnh — đó chính là lý do thời gian lập kế hoạch đáng giá |

⚠ Vì sao "đã làm dự án tương tự năm ngoái" KHÔNG có nghĩa là bỏ bớt kế hoạch: | Lý do | Nội dung | |---|---| | ⚠ Kinh nghiệm cũ giúp lập kế hoạch NHANH HƠN và TỐT HƠN | ⚠ không phải giúp bỏ qua | | ⚠ Bối cảnh khác: khách hàng khác, bộ ảnh khác, yêu cầu khác | | | ⚠ Nó là đầu vào tuyệt vời cho phán đoán chuyên gia | ⚠ liên hệ #26331 lô 191 | | ⚠ Và nó chính là lý do phương án B sai | ⚠ có tiền lệ nghĩa là KHÔNG phải lần đầu | | ⚠ Cách dùng đúng kinh nghiệm cũ | ⚠ lấy bài học ra, đối chiếu điểm giống và khác, rồi lập kế hoạch cho phần khác — đó vẫn là lập kế hoạch, chỉ là hiệu quả hơn |

Từ khoá nhận diện:

"vì sao dành nhiều thời gian lập kế hoạch chất lượng" → ⚠ CHẤT LƯỢNG ĐƯỢC LẬP KẾ HOẠCH VÀO, KHÔNG PHẢI KIỂM TRA VÀO "lần đầu làm, lần đầu dùng" → ⚠ đúng khi thật sự mới — xem #26241 lô 189; SAI ở đây vì có tiền lệ "kiểm toán chất lượng" → ⚠ thuộc Thực thi, không thuộc Lập kế hoạch "bắt buộc phải làm" → ⚠ khẳng định không kèm lý do, không trả lời câu hỏi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tiêu chuẩn chất lượng viết ra được trước khi bắt đầu không | ⚠ không có thì bạn sẽ chỉ kiểm tra được cảm tính | | Khi lịch bị ép, phần nào bị cắt trước | ⚠ cắt lập kế hoạch là mua thời gian bằng chất lượng | | Kinh nghiệm dự án trước của bạn đang nằm ở đâu | ⚠ trong sổ bài học hay chỉ trong trí nhớ — liên hệ #26455 cùng lô |

Và câu trả lời ngắn nhất mà Luis có thể đưa cho ban lãnh đạo: thời gian bỏ vào kế hoạch là thời gian duy nhất trong dự án mà một giờ có thể thay thế cho mười giờ làm lại.

Câu 29 Process
Gerald has just completed a planning session with his team that lays out the general features and dependencies within each, along with some user stories. His goal is to prioritize the backlog, knowing that their compliance team will be required to ensure everything is in order before release. What is his most likely next step?
  1. A Schedule a product planning session for backlog prioritization.
  2. B Schedule a session that reviews the risk related to the areas identified before prioritization.
  3. C He should prioritize the backlog on his own as the product owner.
  4. D Schedule another session so that all the user stories can be identified.
Xem giải thích

Đáp án

B — Sắp xếp một buổi RÀ SOÁT RỦI RO liên quan tới các mảng đã nhận diện, TRƯỚC KHI xếp ưu tiên.

Vì sao đúng

⚠ Vì sao rà soát rủi ro phải đi trước xếp ưu tiên: | Lý do | Nội dung | |---|---| | ⚠ Gerald ĐÃ nhận diện tính năng, phụ thuộc và câu chuyện người dùng | ⚠ đầu vào cho việc xếp ưu tiên đã đủ | | ⚠ Có ĐỘI TUÂN THỦ phải duyệt trước khi phát hành | ⚠ đó là một RÀNG BUỘC BẮT BUỘC, không thương lượng | | ⚠ Rủi ro và tuân thủ là TIÊU CHÍ để xếp ưu tiên | ⚠ không phải việc làm sau khi đã xếp xong | | ⚠ Xếp trước rồi mới xét rủi ro = phải xếp lại từ đầu | ⚠ lãng phí một buổi họp và làm đội mất niềm tin vào quy trình | | ⚠ Kết luận | ⚠ thu thập đủ thông tin quyết định TRƯỚC khi ra quyết định |

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

  • A (sắp buổi lập kế hoạch sản phẩm để xếp ưu tiên backlog) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đó ĐÚNG LÀ mục tiêu Gerald đã nêu, và nghe như bước tiếp theo hiển nhiên: ⚠ nhưng ⚠ nó BỎ QUA thông tin rủi ro và tuân thủ mà chính đề vừa nhấn mạnh ⚠ — đề đưa chi tiết về đội tuân thủ vào có mục đích; ⚠ xếp ưu tiên mà chưa biết mảng nào có rủi ro tuân thủ là xếp bằng nửa dữ liệu.

  • C (tự mình xếp ưu tiên với tư cách chủ sản phẩm) — ⚠ về hình thức chủ sản phẩm có quyền quyết backlog, ⚠ nhưng ⚠ làm một mình khi có ràng buộc tuân thủ và phụ thuộc kỹ thuật là bỏ mất chuyên môn của đội; ⚠ liên hệ #26464 cùng lô — xếp ưu tiên là việc làm cùng người khác.

  • D (sắp thêm buổi nữa để nhận diện hết câu chuyện người dùng) — ⚠ quay lại bước đã xong; ⚠ agile không đòi phải có đủ mọi câu chuyện trước khi xếp ưu tiên — backlog vốn tiến hoá dần.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26464 cùng lô (xếp hạng tuyệt đối cùng bên liên quan), ⚠ #26463 cùng lô (hiện vật agile), ⚠ #26452 cùng lô (hướng dẫn phân tích tuân thủ), ⚠ #26426 lô 193 (tuân thủ không thương lượng), ⚠ #26436 cùng lô (ưu tiên theo tác động).

⚠ Các tiêu chí thường dùng để xếp ưu tiên backlog: | Tiêu chí | Nội dung | |---|---| | ⚠ GIÁ TRỊ KINH DOANH | ⚠ tiêu chí quen thuộc nhất, nhưng không phải duy nhất | | ⚠ RỦI RO | ⚠ hạng mục rủi ro cao nên làm SỚM để phát hiện vấn đề khi còn kịp | | ⚠ TUÂN THỦ | ⚠ bắt buộc — không có nó thì không phát hành được, dù mọi thứ khác xong | | ⚠ PHỤ THUỘC KỸ THUẬT | ⚠ có thứ phải làm trước vì thứ khác đứng trên nó | | ⚠ CHI PHÍ / công sức | ⚠ giá trị chia công sức để xếp | | ⚠ Học hỏi và giảm bất định | ⚠ làm sớm phần chưa hiểu rõ để biết mình chưa biết gì | | ⚠ Nguyên tắc agile hay bị hiểu sai | ⚠ "làm việc có giá trị cao nhất trước" KHÔNG có nghĩa là chỉ nhìn giá trị — một tính năng giá trị cao mà không qua được tuân thủ thì giá trị thực bằng 0 cho tới khi qua được |

⚠ Vì sao rủi ro nên làm SỚM trong agile: | Lý do | Nội dung | |---|---| | ⚠ Phát hiện sớm thì còn thời gian và tiền để xoay xở | ⚠ phát hiện muộn thì chỉ còn cách chấp nhận | | ⚠ Giảm bất định làm mọi ước lượng sau đó chính xác hơn | ⚠ liên hệ #26448 cùng lô | | ⚠ Rủi ro tuân thủ có thể buộc THIẾT KẾ LẠI | ⚠ biết ở vòng lặp 2 thì sửa được, biết ở vòng lặp 12 thì phải làm lại rất nhiều | | ⚠ Đội tuân thủ cần THỜI GIAN của họ | ⚠ họ là bên liên quan có lịch riêng, mời muộn là chờ | | ⚠ Cách làm tốt | ⚠ mời đại diện đội tuân thủ vào chính buổi rà soát rủi ro — rẻ hơn nhiều so với việc họ bác bỏ sau khi mọi thứ đã xong |

⚠ Trình tự đúng của Gerald từ đây: | Bước | Việc | |---|---| | ⚠ 1. Rà soát rủi ro cho các mảng đã nhận diện | ⚠ có đội tuân thủ tham gia — bước mà đề đang hỏi | | ⚠ 2. Thống nhất tiêu chí xếp ưu tiên | ⚠ giá trị, rủi ro, tuân thủ, phụ thuộc | | ⚠ 3. Xếp ưu tiên backlog cùng đội và bên liên quan | ⚠ liên hệ #26464 cùng lô | | ⚠ 4. Lập kế hoạch phát hành theo thứ tự đó | | | ⚠ 5. Rà soát lại backlog định kỳ | ⚠ backlog refinement — thứ tự không phải chốt một lần | | ⚠ Nhận xét | ⚠ bước 1 chỉ tốn một buổi họp; bỏ qua nó có thể tốn cả một chu kỳ phát hành |

Từ khoá nhận diện:

"có yêu cầu tuân thủ, sắp xếp ưu tiên backlog" → ⚠ RÀ SOÁT RỦI RO TRƯỚC "xếp ưu tiên ngay" → ⚠ quyết định khi chưa đủ dữ liệu "chủ sản phẩm tự xếp một mình" → ⚠ có quyền nhưng bỏ mất chuyên môn của đội "nhận diện thêm câu chuyện người dùng" → ⚠ quay lại bước đã xong; backlog vốn tiến hoá dần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog của bạn xếp theo tiêu chí gì | ⚠ chỉ có giá trị kinh doanh là chưa đủ | | Bên tuân thủ của bạn tham gia từ lúc nào | ⚠ càng muộn càng đắt | | Hạng mục rủi ro cao trong backlog của bạn nằm ở đầu hay cuối | ⚠ nằm cuối là một quyết định, hãy chắc là bạn cố ý |

Và lý do một buổi họp rủi ro trước khi xếp ưu tiên gần như luôn có lãi: thứ tự bạn làm việc chính là giả thuyết của bạn về điều gì quan trọng — và rủi ro là thứ duy nhất có thể chứng minh giả thuyết đó sai trước khi bạn kịp đi hết đường.

Câu 30 Process
Caroline has joined an international organization and is hired to lead the project management office as a senior project manager. One of her new role responsibilities is to strategize scaling various projects across the organization while considering that the types of projects they are executing range from small initiatives to large multinational projects. Which of the following factors will Caroline consider in developing an effective strategy that is scalable for managing projects within the organization?
  1. A Geographical distribution, regulations, organizational and technical complexity, team size
  2. B Geographical distribution, regulatory and organizational complexity, team size
  3. C Geographical distribution, regulatory, organizational, and technical complexity, team size, budget
  4. D Geographical distribution, regulations, team size
Xem giải thích

Đáp án

C — Phân bố địa lý, độ phức tạp về QUY ĐỊNH, TỔ CHỨC và KỸ THUẬT, quy mô đội, và NGÂN SÁCH.

Vì sao đúng

⚠ Vì sao đây là danh sách đúng: | Yếu tố | Vì sao cần cân nhắc khi mở rộng quy mô | |---|---| | ⚠ PHÂN BỐ ĐỊA LÝ | ⚠ đội cùng chỗ và đội xuyên quốc gia cần cách quản trị khác hẳn — liên hệ #26467 cùng lô | | ⚠ Độ phức tạp về QUY ĐỊNH | ⚠ dự án đa quốc gia chịu nhiều hệ thống pháp lý — liên hệ #26452 cùng lô | | ⚠ Độ phức tạp về TỔ CHỨC | ⚠ bao nhiêu phòng ban, bao nhiêu cấp phê duyệt | | ⚠ Độ phức tạp về KỸ THUẬT | ⚠ công nghệ mới hay quen thuộc | | ⚠ QUY MÔ ĐỘI | ⚠ quyết định số kênh giao tiếp — liên hệ #26294 lô 191 | | ⚠ NGÂN SÁCH | ⚠ yếu tố mà ba phương án kia đều thiếu — và là thứ quyết định mức độ quản trị nào khả thi | | ⚠ Kết luận | ⚠ danh sách ĐẦY ĐỦ nhất, và mọi mục trong đó đều có lý do chính đáng |

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

  • A (phân bố địa lý, quy định, độ phức tạp tổ chức và kỹ thuật, quy mô đội) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó gần như trùng khớp với đáp án, chỉ THIẾU ĐÚNG MỘT MỤC: ⚠ NGÂN SÁCH ⚠ — và ngân sách chính là yếu tố phân biệt "sáng kiến nhỏ" với "dự án đa quốc gia lớn", đúng dải mà Caroline phải bao quát; ⚠ đọc lướt là chọn A, phải đối chiếu từng mục mới thấy chỗ thiếu.

  • B (phân bố địa lý, độ phức tạp quy định và tổ chức, quy mô đội) — ⚠ thiếu cả độ phức tạp KỸ THUẬT lẫn NGÂN SÁCH.

  • D (phân bố địa lý, quy định, quy mô đội) — ⚠ ngắn nhất, thiếu nhiều nhất.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là dạng "chọn DANH SÁCH ĐẦY ĐỦ NHẤT", trong đó bốn phương án là các tập con lồng nhau của cùng một danh sách ⚠ — ⚠ đề dạng này không kiểm tra khả năng suy luận mà kiểm tra khả năng ĐỐI CHIẾU CẨN THẬN; ⚠ cách làm là liệt kê ra giấy các mục của từng phương án rồi so cột, đừng đọc trôi; ⚠ và quy tắc thực dụng: khi mọi mục trong danh sách dài đều hợp lý, danh sách dài nhất thường là đáp án.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26467 cùng lô (cùng chỗ và phân tán), ⚠ #26452 cùng lô (phân tích tuân thủ), ⚠ #26294 lô 191 (kênh giao tiếp theo quy mô đội), ⚠ #26451 cùng lô (quản trị mua sắm — một dạng quản trị khác cũng theo ngưỡng).

⚠ Vì sao mỗi yếu tố làm đổi cách quản lý dự án: | Yếu tố | Dự án NHỎ | Dự án LỚN | |---|---|---| | ⚠ Phân bố địa lý | ⚠ một phòng, nói miệng là đủ | ⚠ nhiều múi giờ, phải có quy ước bất đồng bộ | | ⚠ Quy định | ⚠ một hệ thống pháp lý | ⚠ nhiều quốc gia, nhiều chuẩn ngành | | ⚠ Tổ chức | ⚠ một phòng ban, một người duyệt | ⚠ nhiều đơn vị, ban chỉ đạo, nhiều cấp | | ⚠ Kỹ thuật | ⚠ công nghệ quen thuộc | ⚠ tích hợp nhiều hệ thống, công nghệ mới | | ⚠ Quy mô đội | ⚠ 5–9 người, một đội | ⚠ nhiều đội, cần khung mở rộng quy mô | | ⚠ Ngân sách | ⚠ ít quản trị, ít báo cáo | ⚠ kiểm toán, ngưỡng phê duyệt, giám sát chặt | | ⚠ Nguyên tắc chung của việc mở rộng quy mô | ⚠ mức QUẢN TRỊ phải TƯƠNG XỨNG với mức phức tạp — áp quy trình của dự án 50 triệu đô lên sáng kiến 50 nghìn đô sẽ giết chết sáng kiến đó, và ngược lại là mất kiểm soát | |

⚠ Việc thật sự của một PMO khi xây chiến lược mở rộng quy mô: | Việc | Nội dung | |---|---| | ⚠ Phân TẦNG dự án theo mức phức tạp | ⚠ nhỏ / vừa / lớn, dựa trên chính các yếu tố ở trên | | ⚠ Định nghĩa bộ quy trình TỐI THIỂU cho mỗi tầng | ⚠ dự án nhỏ không phải làm đủ mọi tài liệu | | ⚠ Xác định ngưỡng để một dự án chuyển tầng | ⚠ liên hệ #26451 cùng lô — quản trị theo ngưỡng | | ⚠ Cho phép ĐIỀU CHỈNH (tailoring) có kiểm soát | ⚠ khái niệm trung tâm của PMBOK 7 | | ⚠ Đo và cải tiến theo thời gian | | | ⚠ Sai lầm phổ biến nhất của PMO | ⚠ ban hành MỘT bộ quy trình duy nhất cho mọi dự án — kết quả là dự án nhỏ lách luật và dự án lớn thấy quy trình quá sơ sài, cả hai đầu đều thất bại |

⚠ Kỹ thuật làm bài với câu "chọn danh sách": | Bước | Nội dung | |---|---| | ⚠ 1. Liệt kê các mục của TỪNG phương án ra cột | ⚠ đừng đọc trôi — mắt sẽ bỏ qua chỗ thiếu | | ⚠ 2. Đánh dấu mục nào xuất hiện ở đâu | | | ⚠ 3. Hỏi từng mục ĐANG THIẾU: nó có hợp lý không | ⚠ hợp lý mà thiếu → phương án đó loại | | ⚠ 4. Kiểm mục thừa: có mục nào KHÔNG hợp lý không | ⚠ nếu có thì danh sách dài chưa chắc đúng | | ⚠ Cảnh báo | ⚠ quy tắc "chọn cái dài nhất" chỉ đúng khi mọi mục đều hợp lý — luôn làm bước 4 trước khi tin vào nó |

Từ khoá nhận diện:

"chiến lược mở rộng quy mô cho nhiều loại dự án" → ⚠ danh sách ĐẦY ĐỦ gồm cả NGÂN SÁCH danh sách thiếu ngân sách → ⚠ bẫy phổ biến nhất của câu này "điều chỉnh quy trình theo bối cảnh" → ⚠ tailoring, khái niệm trung tâm của PMBOK 7 câu hỏi dạng tập con lồng nhau → ⚠ liệt kê ra cột rồi so, đừng đọc lướt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức của bạn có phân tầng dự án không | ⚠ hay mọi dự án đều theo cùng một bộ quy trình | | Dự án nhỏ ở chỗ bạn có phải làm đủ mọi tài liệu không | ⚠ nếu có thì rất nhiều tài liệu đang được điền cho có | | Ai được quyền điều chỉnh quy trình, và theo tiêu chí gì | |

Và điều Caroline sẽ khám phá ra ở tổ chức mới: thách thức không phải là chọn một phương pháp quản lý dự án, mà là chọn được sáu tiêu chí để biết khi nào phương pháp đó nên nặng và khi nào nên nhẹ.