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

Tìm thấy 201 câu.

Câu 121
Consider two tasks that could happen in any order in your project but will be completed by the same team resource. You refer to the project team to choose the ordering of the tasks. What type of logic is this?
  1. A Hard logic
  2. B Soft logic
  3. C Team logic
  4. D Management logic
Xem giải thích

Đáp án

B — Soft logic (logic mềm, tức discretionary dependency).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ "hai việc có thể làm theo BẤT KỲ thứ tự nào" | ⚠ → KHÔNG có ràng buộc vật lý | | ⚠ "sẽ do cùng một nguồn lực thực hiện" | ⚠ → chỉ là vấn đề sắp xếp | | ⚠ "hỏi đội để CHỌN thứ tự" | ⚠ → đây là lựa chọn theo ý muốn, không bắt buộc | | ⚠ Kết luận | ⚠ discretionary dependency, còn gọi soft logic hoặc preferred logic |

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

  • A (Hard logic) — ⚠ là mandatory dependency: ⚠ bắt buộc về bản chất công việc, ⚠ ví dụ phải đổ móng trước khi xây tường; ⚠ ở đây thứ tự nào cũng được nên không phải.

  • C (Team logic) và D (Management logic) — ⚠ không phải thuật ngữ PMBOK.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25623 ở lô trước — ⚠ trưởng nhóm coi "đủ vật tư" là bắt buộc trong khi thực ra đó là ràng buộc tuỳ chọn. ⚠ Hai câu cùng một chủ đề: phân biệt bắt buộc thật với thói quen.

⚠ Bốn loại phụ thuộc: | Loại | Nghĩa | Đổi được không | |---|---|---| | ⚠ Mandatory (hard logic) | ⚠ bắt buộc về bản chất công việc hoặc hợp đồng | ⚠ KHÔNG | | ⚠ Discretionary (soft logic) | ⚠ do đội chọn, dựa trên thực hành tốt hoặc kinh nghiệm | ⚠ CÓ | | ⚠ External | ⚠ phụ thuộc bên ngoài dự án: giấy phép, nhà cung cấp | ⚠ thường không | | ⚠ Internal | ⚠ giữa các công việc trong nội bộ đội | ⚠ tuỳ trường hợp | | ⚠ Lưu ý | ⚠ một phụ thuộc có thể VỪA mandatory VỪA external, các cặp này kết hợp được |

Từ khoá nhận diện:

"thứ tự nào cũng được, đội tự chọn" → ⚠ soft / discretionary "về mặt vật lý bắt buộc phải làm trước" → ⚠ hard / mandatory "chờ giấy phép, chờ nhà cung cấp" → ⚠ external "chúng tôi vẫn quen làm theo thứ tự này" → ⚠ soft logic — và đây là chỗ RÚT NGẮN LỊCH được

⚠ Vì sao phân biệt hai loại này lại quan trọng Lý do
⚠ FAST TRACKING chỉ làm được trên SOFT logic ⚠ chạy song song những việc vốn xếp nối tiếp theo thói quen
⚠ Đụng vào HARD logic là gây rủi ro thật ⚠ hoặc đơn giản là không làm được
⚠ Nhiều "quy tắc bất di bất dịch" thực ra là soft logic ⚠ hỏi "vì sao phải theo thứ tự này?" thường lộ ra
⚠ Khi lịch căng ⚠ rà lại toàn bộ phụ thuộc để tìm soft logic là việc đầu tiên nên làm
⚠ Bốn quan hệ giữa hoạt động — dễ lẫn với bốn LOẠI ở trên Quan hệ
⚠ Finish-to-Start (FS) ⚠ phổ biến nhất: A xong thì B mới bắt đầu
⚠ Start-to-Start (SS) ⚠ A bắt đầu thì B mới bắt đầu được
⚠ Finish-to-Finish (FF) ⚠ A xong thì B mới xong được
⚠ Start-to-Finish (SF) ⚠ hiếm nhất: A bắt đầu thì B mới kết thúc được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi phụ thuộc trong lịch của bạn thuộc loại nào | ⚠ nên ghi rõ khi lập lịch | | Có soft logic nào đang kéo dài đường găng không | | | Ai có quyền quyết định đổi thứ tự | ⚠ soft logic thì đội quyết được |

Và giá trị nghề nghiệp của việc phân loại này: khi bị ép rút ngắn lịch, chỗ an toàn nhất để tìm là soft logic. Đụng vào hard logic thì rút được vài ngày mà đổi lấy rủi ro không đáng.

Câu 122
Tom is a software developer on your project team and it’s come to your attention that some of the stakeholders have been approaching Tom and asking for additional items in the software. These additions have caused Tom’s scheduled work to be late and they’ve also driven the overall cost of the project up. What term best describes these additions to the project even though the stakeholders claim they are small changes?
  1. A Integrated change control
  2. B Scope control
  3. C Scope creep
  4. D Gold plating
Xem giải thích

Đáp án

C — Scope creep (phạm vi phình ra ngoài kiểm soát).

Vì sao đúng

⚠ Dấu hiệu scope creep trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ BÊN LIÊN QUAN yêu cầu thêm việc | ⚠ không phải đội tự thêm | | ⚠ Đi thẳng tới thành viên đội, KHÔNG qua quản lý dự án | | | ⚠ KHÔNG qua quy trình kiểm soát thay đổi | ⚠ không ai đánh giá tác động, không ai phê duyệt | | ⚠ "chỉ là thay đổi nhỏ" | ⚠ câu nói kinh điển của scope creep | | ⚠ Hậu quả: chậm lịch và đội chi phí | ⚠ đúng như đề mô tả | | ⚠ Kết luận | ⚠ phạm vi phình dần mà không ai kiểm soát |

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

  • D (Gold plating) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ gold plating là ⚠ ĐỘI TỰ thêm tính năng không ai yêu cầu; ⚠ ở đây ⚠ BÊN LIÊN QUAN yêu cầu — hai hiện tượng khác nhau.

  • A (Integrated change control) — ⚠ là QUY TRÌNH đúng đắn để xử lý thay đổi; ⚠ vấn đề của tình huống này chính là ⚠ quy trình đó ĐÃ BỊ BỎ QUA.

  • B (Scope control) — ⚠ là quy trình PHÁT HIỆN và xử lý scope creep, ⚠ không phải tên của hiện tượng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25635 ở lô này về gold plating, và câu #25600 ở lô trước về việc ⚠ PM không tự ý sửa phạm vi. ⚠ Ba câu cùng vẽ nên ranh giới của quản lý phạm vi.

⚠ Ba hiện tượng phải phân biệt được: | Hiện tượng | Ai gây ra | Có qua quy trình không | |---|---|---| | ⚠ Scope creep | ⚠ bên liên quan / khách hàng | ⚠ KHÔNG | | ⚠ Gold plating | ⚠ đội dự án tự thêm | ⚠ KHÔNG | | ⚠ Change request hợp lệ | ⚠ bất kỳ ai | ⚠ CÓ — có đánh giá và phê duyệt |

Từ khoá nhận diện:

"chỉ là thay đổi nhỏ thôi mà" → ⚠ scope creep "đội tự thêm cho khách vui" → ⚠ gold plating "đánh giá tác động rồi trình duyệt" → ⚠ quy trình đúng "đi thẳng tới lập trình viên" → ⚠ bỏ qua quản lý dự án — dấu hiệu đỏ

⚠ PM nên làm gì trong tình huống này Bước
⚠ 1. Nói chuyện với Tom ⚠ mọi yêu cầu phải chuyển về PM, không tự nhận việc
⚠ 2. Nói chuyện với các bên liên quan ⚠ giải thích quy trình thay đổi và lý do có nó
⚠ 3. Đánh giá các thay đổi ĐÃ làm ⚠ cập nhật lịch và chi phí cho đúng thực tế
⚠ 4. Đưa các yêu cầu còn lại qua kiểm soát thay đổi
⚠ 5. Xem lại kế hoạch giao tiếp ⚠ để bên liên quan biết kênh chính thức ở đâu
⚠ Đừng ⚠ trách Tom là chính — vấn đề nằm ở quy trình chưa được truyền đạt rõ
⚠ Cách phòng scope creep Cách
⚠ Phạm vi được viết rõ và ĐƯỢC KÝ DUYỆT
⚠ WBS đầy đủ — việc không có trong WBS thì không thuộc dự án
⚠ Quy trình kiểm soát thay đổi được công bố cho MỌI bên liên quan
⚠ Đội biết cách từ chối lịch sự và chuyển yêu cầu về PM
⚠ Rà soát phạm vi định kỳ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có biết phải làm gì khi được nhờ thêm việc không | | | Bên liên quan có biết kênh yêu cầu thay đổi ở đâu không | | | Lịch và chi phí hiện tại có phản ánh các thay đổi đã lỡ làm không | |

Và câu cần nhắc đội thuộc lòng: "việc này nghe hợp lý, để tôi chuyển cho quản lý dự án đánh giá". Đội không cần từ chối, chỉ cần không tự nhận.

Câu 123
You are the project manager of Project BNM. The project management office in your organization has been supporting you by supplying specific templates, forms, and tools, and requiring that you comply with the expectations of their usage. Which of the following types best describes your PMO?
  1. A Supportive
  2. B Controlling
  3. C Collaborative
  4. D Directive
Xem giải thích

Đáp án

B — Controlling (PMO kiểm soát).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Cung cấp mẫu biểu, biểu mẫu và công cụ | ⚠ → có hỗ trợ, giống supportive | | ⚠ YÊU CẦU bạn TUÂN THỦ cách dùng chúng | ⚠ → đây là điểm quyết định: có sự BẮT BUỘC | | ⚠ Hỗ trợ + bắt tuân thủ | ⚠ = CONTROLLING PMO |

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

  • A (Supportive) — ⚠ CHỈ cung cấp mẫu biểu, đào tạo và thông tin, KHÔNG bắt tuân thủ; ⚠ mức kiểm soát THẤP; ⚠ ở đây có chữ "requiring that you comply" nên không phải.

  • D (Directive) — ⚠ PMO trực tiếp QUẢN LÝ dự án: ⚠ quản lý dự án là người của PMO và báo cáo cho PMO; ⚠ mức kiểm soát CAO nhất; ⚠ đề không nói bạn thuộc biên chế PMO.

  • C (Collaborative) — ⚠ KHÔNG phải một trong ba loại PMO của PMBOK.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25601 ở lô trước hỏi về controlling PMO, và câu #25602 về việc ⚠ PMO không tạo điều lệ dự án. ⚠ Ba câu cùng chủ đề PMO — lưu ý cả ba đều hay hỏi về mức độ kiểm soát.

⚠ Ba loại PMO theo PMBOK: | Loại | Vai trò | Mức kiểm soát | |---|---|---| | ⚠ Supportive | ⚠ kho tài nguyên: mẫu biểu, đào tạo, bài học kinh nghiệm — dùng hay không tuỳ bạn | ⚠ THẤP | | ⚠ Controlling | ⚠ cung cấp VÀ yêu cầu tuân thủ khung, biểu mẫu, công cụ, quản trị | ⚠ TRUNG BÌNH | | ⚠ Directive | ⚠ trực tiếp quản lý dự án, PM thuộc PMO | ⚠ CAO |

Từ khoá nhận diện:

"cung cấp mẫu, tuỳ bạn dùng" → ⚠ supportive "cung cấp mẫu VÀ bắt tuân thủ" → ⚠ controlling "PMO cử người quản lý dự án, PM báo cáo cho PMO" → ⚠ directive "phải tuân thủ, phải theo khung" → ⚠ tối thiểu là controlling

⚠ Chức năng chung của mọi PMO Chức năng
⚠ Chuẩn hoá quản trị dự án
⚠ Chia sẻ tài nguyên, phương pháp, công cụ
⚠ Cố vấn, đào tạo, kèm cặp quản lý dự án
⚠ Giám sát tuân thủ qua kiểm toán dự án ⚠ rõ nhất ở controlling PMO
⚠ Điều phối giao tiếp giữa các dự án
⚠ Quản lý tài liệu chung và bài học kinh nghiệm
⚠ Nhầm lẫn hay gặp Đính chính
⚠ "PMO tạo ra điều lệ dự án" ⚠ SAI — điều lệ do nhà tài trợ ban hành
⚠ "PMO nào cũng quản lý dự án" ⚠ chỉ DIRECTIVE mới trực tiếp quản lý
⚠ "PMO là cấp trên của PM" ⚠ chỉ đúng với directive PMO
⚠ "Có bốn loại PMO" ⚠ PMBOK 6 nêu BA loại; "collaborative" là phương án bịa
⚠ Ưu và nhược của controlling PMO Điều
⚠ ƯU: dữ liệu các dự án so sánh được với nhau
⚠ ƯU: chất lượng quản trị đồng đều
⚠ NHƯỢC: có thể nặng thủ tục với dự án nhỏ
⚠ NHƯỢC: PM cảm thấy bị bó
⚠ Cách dung hoà ⚠ cho phép cắt giảm quy trình với dự án nhỏ — tailoring

Ba việc kiểm chứng: | Việc | Cách | |---|---| | PMO của bạn thuộc loại nào | ⚠ quyết định bạn có bao nhiêu quyền tự chủ | | Mẫu biểu bắt buộc có phù hợp quy mô dự án không | | | Bạn có được phép cắt giảm quy trình không | ⚠ hỏi rõ thay vì tự ý bỏ |

Và từ khoá duy nhất cần bắt trong dạng câu này: "requiring compliance" — bắt tuân thủ. Có chữ đó là controlling; không có mà chỉ cấp mẫu là supportive; PMO cử người quản lý dự án là directive.

Câu 124
Jen is a project manager for the NQQ Project for her organization. She is working with the project team to create the project schedule. Tom, a project team member, reports that he’s adding ten percent duration to all activities involved with a vendor because vendors are always late. What is the ten percent duration increase in this scenario?
  1. A Constraint
  2. B Assumption
  3. C Risk
  4. D Padding
Xem giải thích

Đáp án

B — Assumption (giả định).

Vì sao đúng

⚠ Vì sao 10% này là một giả định: | Chi tiết | Suy ra | |---|---| | ⚠ Tom nói "nhà cung cấp LÚC NÀO CŨNG trễ" | ⚠ → đây là niềm tin, KHÔNG có dữ liệu chứng minh | | ⚠ Không dẫn số liệu lịch sử nào | | | ⚠ Không phân tích riêng từng nhà cung cấp | | | ⚠ Con số 10% cũng không có căn cứ | | | ⚠ Kết luận | ⚠ toàn bộ phần cộng thêm dựa trên một GIẢ ĐỊNH chưa kiểm chứng — phải ghi vào assumption log |

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

  • A (Constraint) — ⚠ ràng buộc là giới hạn ĐÃ BIẾT CHẮC do bên ngoài đặt ra; ⚠ không ai ép Tom cộng 10%.

  • C (Risk) — ⚠ rủi ro là SỰ KIỆN KHÔNG CHẮC CHẮN có thể xảy ra; ⚠ "nhà cung cấp giao trễ" mới là rủi ro, ⚠ còn 10% là phản ứng với rủi ro đó chứ không phải bản thân rủi ro.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Phương án D ("Padding" — đệm lịch) cũng mô tả đúng HÀNH VI của Tom. ⚠ Cộng thêm thời gian ngầm vào ước lượng từng hoạt động, không công bố, không có căn cứ ⚠ chính là định nghĩa của padding, ⚠ và đây là việc PMBOK khuyên KHÔNG nên làm. ⚠ Đề chọn "Assumption" vì hỏi ⚠ bản chất của cơ sở lý luận (niềm tin chưa kiểm chứng) ⚠ chứ không hỏi tên của hành vi. ⚠ Giữ nguyên khoá B, nhưng người học nên nắm cả hai góc: ⚠ về mặt lý luận đó là giả định, về mặt thực hành đó là padding. ⚠ Nếu gặp câu tương tự nhấn mạnh chữ "thêm thời gian ngầm không công bố" thì đáp án sẽ là padding.

⚠ Padding và reserve khác nhau thế nào: | Điều | Padding | Contingency / Management reserve | |---|---|---| | ⚠ Có công bố không | ⚠ KHÔNG — giấu trong ước lượng | ⚠ CÓ — là khoản riêng, ai cũng thấy | | ⚠ Có căn cứ không | ⚠ thường không | ⚠ dựa trên phân tích rủi ro | | ⚠ Quản lý được không | ⚠ KHÔNG — không ai biết còn bao nhiêu | ⚠ CÓ — theo dõi và tiêu có kiểm soát | | ⚠ Kết luận | ⚠ padding là cách làm SAI; dự trữ mới là cách làm ĐÚNG |

⚠ Hai loại dự trữ trong PMBOK Loại
⚠ Contingency reserve ⚠ cho rủi ro ĐÃ BIẾT — nằm TRONG đường cơ sở chi phí, PM tiêu được
⚠ Management reserve ⚠ cho rủi ro CHƯA BIẾT — nằm NGOÀI đường cơ sở, phải xin phê duyệt mới tiêu
⚠ Mẹo nhớ ⚠ cost baseline + management reserve = budget

Từ khoá nhận diện:

"chúng tôi cho rằng, luôn luôn, thường thì" → ⚠ giả định "cộng thêm thời gian cho chắc, không nói ai" → ⚠ padding "khoản dự phòng có tính toán, có công bố" → ⚠ contingency reserve "đã biết chắc, do bên ngoài áp đặt" → ⚠ ràng buộc

⚠ Jen nên làm gì với Tom Bước
⚠ Ghi giả định vào assumption log ⚠ để nó hiện ra chứ không nằm ngầm
⚠ Kiểm chứng bằng DỮ LIỆU lịch sử ⚠ nhà cung cấp nào trễ, trễ bao nhiêu
⚠ Nếu đúng là có rủi ro: đưa vào risk register
⚠ Lập DỰ TRỮ công khai thay cho phần đệm ngầm
⚠ Vì sao quan trọng ⚠ đệm ngầm khiến lịch mất độ tin cậy và định luật Parkinson làm công việc nở ra lấp đầy thời gian

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng của đội có phần đệm ngầm không | ⚠ hỏi thẳng và không phạt ai thừa nhận | | Giả định nào đang nằm sau các con số | | | Dự trữ đã được lập công khai chưa | |

Và lý do PMBOK ghét padding: khi ai cũng đệm một ít, không ai còn biết lịch thật là bao nhiêu. Dự trữ công khai giải quyết đúng nỗi lo đó mà vẫn giữ được con số trung thực.

Câu 125
Steve is the project manager of the NKQ Project. This project is to paint the 245 offices in his company’s building a new color of gray. The project team is executing the project plan and has already painted 58 of the 245 offices. Stacey, a stakeholder, calls you to report that the project team has actually been painting the offices a light yellow – not the approved gray color the executives have selected. What should you do next?
  1. A Tell the team the team they need to document the error before moving forward.
  2. B Tell the team to continue to paint the offices yellow.
  3. C Tell the team to stop work until you can inspect the error.
  4. D Tell the team to paint all remaining offices the correct color of gray.
Xem giải thích

Đáp án

D — Bảo đội sơn tất cả các phòng CÒN LẠI bằng đúng màu xám đã được phê duyệt.

Vì sao đúng

⚠ Vì sao đây là việc tiếp theo đúng: | Lý do | Nội dung | |---|---| | ⚠ Màu xám là màu ĐÃ ĐƯỢC PHÊ DUYỆT | ⚠ nằm trong đường cơ sở phạm vi | | ⚠ Sơn vàng là KHUYẾT TẬT, không phải thay đổi hợp lệ | ⚠ không ai duyệt màu vàng | | ⚠ Việc CẤP BÁCH nhất là NGỪNG LÀM SAI THÊM | ⚠ 187 phòng còn lại phải đúng ngay | | ⚠ Mỗi phòng sơn sai thêm là thêm chi phí sửa | | | ⚠ 58 phòng đã sơn sai | ⚠ xử lý bằng defect repair — sửa khuyết tật, đi qua kiểm soát thay đổi tích hợp |

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

  • C (dừng toàn bộ công việc để bạn đi kiểm tra) — ⚠ phản ứng THÁI QUÁ: ⚠ màu đúng đã biết rõ, không cần dừng cả dự án để điều tra; ⚠ dừng việc gây tốn kém vô ích.

  • A (bảo đội ghi lại lỗi trước khi đi tiếp) — ⚠ ghi chép là CẦN nhưng KHÔNG PHẢI việc đầu tiên; ⚠ ưu tiên là ngừng làm sai thêm, ghi chép làm song song.

  • B (tiếp tục sơn màu vàng) — ⚠ SAI hoàn toàn: ⚠ đó là chấp nhận một thay đổi chưa ai duyệt.

Ghi nhớ

⚠ Trình tự xử lý khi phát hiện làm sai so với phạm vi: | Bước | Việc | |---|---| | ⚠ 1. NGỪNG làm sai thêm | ⚠ quay về đúng đường cơ sở ngay | | ⚠ 2. Đánh giá phạm vi thiệt hại | ⚠ 58 phòng, chi phí sơn lại là bao nhiêu | | ⚠ 3. Mở yêu cầu sửa khuyết tật | ⚠ defect repair — một dạng yêu cầu thay đổi | | ⚠ 4. Qua kiểm soát thay đổi tích hợp | ⚠ CCB quyết định sơn lại hay chấp nhận | | ⚠ 5. Tìm NGUYÊN NHÂN GỐC | ⚠ vì sao đội hiểu sai màu? tài liệu mơ hồ hay giao tiếp hỏng? | | ⚠ 6. Ghi vào bài học kinh nghiệm | |

Từ khoá nhận diện:

"làm sai so với phạm vi đã duyệt" → ⚠ khuyết tật, không phải thay đổi "sửa cho đúng phạm vi" → ⚠ defect repair — vẫn là yêu cầu thay đổi "ngăn không cho tái diễn" → ⚠ preventive action "đưa về đúng kế hoạch" → ⚠ corrective action

⚠ Ba loại yêu cầu thay đổi PMBOK Loại
⚠ Corrective action ⚠ đưa hiệu suất TƯƠNG LAI về đúng kế hoạch
⚠ Preventive action ⚠ giảm khả năng xảy ra hậu quả xấu trong tương lai
⚠ Defect repair ⚠ sửa hoặc thay thế phần đã làm ra bị lỗi
⚠ Cả ba ⚠ đều phải đi qua Perform Integrated Change Control
⚠ Câu hỏi cần đặt ra sau sự việc Câu hỏi
⚠ Màu được ghi ở đâu và ghi thế nào ⚠ "xám" hay có mã màu cụ thể?
⚠ Đội có đọc tài liệu phạm vi không
⚠ Vì sao 58 phòng mới bị phát hiện ⚠ kiểm soát chất lượng đã ở đâu?
⚠ Ai báo — bên liên quan, không phải đội ⚠ dấu hiệu QC của dự án không hoạt động
⚠ Bài học lớn nhất ⚠ 58 phòng là cái giá của việc không kiểm tra sớm

⚠ Đối chiếu: ⚠ câu #25639 ở lô này — ⚠ chất lượng được lập kế hoạch mà có. ⚠ Tình huống này là ví dụ sống: thiếu điểm kiểm tra sớm nên lỗi nhân lên 58 lần.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặc tả có đủ chính xác để không hiểu nhầm không | ⚠ mã màu thay vì tên màu | | Có điểm kiểm tra sau vài đơn vị đầu tiên không | ⚠ kiểm phòng đầu tiên là đủ bắt lỗi này | | Ai chịu trách nhiệm kiểm tra chất lượng bàn giao | |

Và bài học đắt nhất ở đây không phải màu sơn: lỗi được phát hiện bởi bên liên quan chứ không phải bởi đội. Đó là dấu hiệu quy trình kiểm soát chất lượng của dự án chưa tồn tại trên thực tế.

Câu 126
Mary is the project manager for her organization and she’s been assigned a new project. Management has asked Mary to create a reliable project budget as soon as possible and Mary states she’ll need to create a definitive estimate and this will take some time. In order to create the definitive estimate for a project, what document must first be created? Choose the best answer:
  1. A Project charter
  2. B Work breakdown structure
  3. C Product scope
  4. D Project scope
Xem giải thích

Đáp án

B — Work breakdown structure (cấu trúc phân rã công việc).

Vì sao đúng

⚠ Vì sao phải có WBS trước: | Lý do | Nội dung | |---|---| | ⚠ Definitive estimate là ước lượng CHÍNH XÁC NHẤT | ⚠ sai số khoảng −5% đến +10% | | ⚠ Nó được lập theo phương pháp BOTTOM-UP | ⚠ ước lượng từng gói công việc rồi cộng lên | | ⚠ Muốn có gói công việc thì phải có WBS | ⚠ work package là mức thấp nhất của WBS | | ⚠ Không có WBS thì không biết phải ước lượng CÁI GÌ | | | ⚠ Kết luận | ⚠ WBS là điều kiện tiên quyết của ước lượng dứt khoát |

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

  • D (Project scope — phạm vi dự án) — ⚠ cần thiết nhưng CHƯA ĐỦ: ⚠ tuyên bố phạm vi mô tả công việc ở mức tổng thể, ⚠ chưa phân rã tới mức ước lượng chi tiết được; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • C (Product scope — phạm vi sản phẩm) — ⚠ mô tả ĐẶC TÍNH của sản phẩm, ⚠ không mô tả công việc phải làm.

  • A (Project charter — điều lệ dự án) — ⚠ chỉ ở mức rất cao, ⚠ thường chỉ chứa ước lượng ROM.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25613 ở lô trước về ROM và câu #25606 về definitive estimate. ⚠ Ba câu hợp thành bộ đầy đủ về thang độ chính xác ước lượng.

⚠ Chuỗi tài liệu dẫn tới ngân sách đáng tin: | Bước | Tài liệu | |---|---| | ⚠ 1 | ⚠ Project charter — ROM, −25% tới +75% | | ⚠ 2 | ⚠ Project scope statement — phạm vi mức tổng thể | | ⚠ 3 | ⚠ WBS — phân rã tới gói công việc | | ⚠ 4 | ⚠ WBS dictionary — chi tiết từng gói | | ⚠ 5 | ⚠ Activity list — phân rã gói thành hoạt động | | ⚠ 6 | ⚠ Definitive estimate — ước lượng bottom-up, −5% tới +10% | | ⚠ 7 | ⚠ Cost baseline — đường cơ sở chi phí |

Từ khoá nhận diện:

"ngân sách đáng tin cậy" → ⚠ definitive estimate → cần WBS "con số nhanh, chưa cam kết" → ⚠ ROM → chỉ cần điều lệ "cộng từ dưới lên" → ⚠ bottom-up → bắt buộc có WBS "dựa vào dự án tương tự" → ⚠ analogous → không cần WBS

⚠ Vì sao lãnh đạo hay sốt ruột ở bước này Lý do
⚠ Họ muốn con số ngay hôm nay
⚠ Ước lượng dứt khoát cần THỜI GIAN ⚠ Mary nói đúng
⚠ Giải pháp: đưa ROM ngay kèm DẢI SAI SỐ ⚠ rồi hẹn ngày có con số chính xác
⚠ Sai lầm ⚠ đưa một con số chính xác giả tạo để làm hài lòng lãnh đạo
⚠ Bốn kỹ thuật ước lượng và yêu cầu đầu vào Cần gì
⚠ Analogous ⚠ dữ liệu dự án cũ tương tự
⚠ Parametric ⚠ quan hệ thống kê và đơn giá
⚠ Three-point ⚠ ba ước lượng cho mỗi hoạt động
⚠ Bottom-up ⚠ WBS đầy đủ tới mức gói công việc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WBS của bạn đã phân rã đủ chi tiết chưa | ⚠ gói công việc 8–80 giờ là mốc tham khảo | | Bạn đang bị ép đưa con số chính xác khi chưa đủ dữ liệu không | | | Ước lượng có kèm dải sai số không | |

Và câu Mary nên nói với lãnh đạo: "tôi có thể đưa con số thô ngay hôm nay, con số đáng tin thì cần WBS xong đã". Trung thực về độ chính xác luôn tốt hơn một con số đẹp mà sai.

Câu 127
You are the project manager of the NJK Project and your budget for this project is $575,000. You are 20 percent complete with this project, though you are supposed to be 30 percent complete. So far you have spent 10 percent more than what was expected for the work completed. What is your cost performance index for this project?
  1. A 0.91
  2. B 0.83
  3. C 115000
  4. D 138000
Xem giải thích

Đáp án

A — 0,91.

Vì sao đúng

⚠ Bóc tách dữ liệu đề bài: | Đại lượng | Cách tính | Kết quả | |---|---|---| | ⚠ BAC — ngân sách hoàn thành | ⚠ đề cho | ⚠ 575.000 | | ⚠ EV — giá trị thu được | ⚠ BAC × 20% hoàn thành thực tế | ⚠ 575.000 × 0,20 = 115.000 | | ⚠ PV — giá trị kế hoạch | ⚠ BAC × 30% đáng lẽ phải xong | ⚠ 575.000 × 0,30 = 172.500 | | ⚠ AC — chi phí thực tế | ⚠ chi nhiều hơn 10% so với mức đáng lẽ cho phần việc ĐÃ LÀM | ⚠ 115.000 × 1,10 = 126.500 |

⚠ Tính CPI: | Bước | Phép tính | |---|---| | ⚠ CPI = EV / AC | | | ⚠ = 115.000 / 126.500 | | | ⚠ = 0,909... | ⚠ ≈ 0,91 | | ⚠ Nghĩa là | ⚠ cứ 1 đồng chi ra chỉ đổi được 0,91 đồng giá trị — VƯỢT CHI khoảng 9% |

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

  • B (0,83) — ⚠ không khớp phép tính nào của đề; ⚠ nếu tính nhầm 1 / 1,2 hoặc nhầm tỷ lệ thì mới ra gần con số này.

  • C (115000) — ⚠ đó là EV, ⚠ không phải chỉ số; ⚠ CPI là TỶ SỐ, luôn quanh 1.

  • D (138000) — ⚠ không phải đại lượng nào trong bài.

Ghi nhớ

⚠ Kiểm tra chéo — SPI cũng tính được: | Bước | Phép tính | |---|---| | ⚠ SPI = EV / PV | | | ⚠ = 115.000 / 172.500 | | | ⚠ = 0,667 | ⚠ chậm nặng: mới làm được 2/3 khối lượng đáng lẽ phải xong | | ⚠ Kết luận dự án | ⚠ vừa vượt chi vừa chậm tiến độ |

⚠ Bộ công thức EVM cần thuộc: | Chỉ số | Công thức | Nghĩa | |---|---|---| | ⚠ CV | ⚠ EV − AC | ⚠ âm là vượt chi | | ⚠ SV | ⚠ EV − PV | ⚠ âm là chậm | | ⚠ CPI | ⚠ EV / AC | ⚠ dưới 1 là vượt chi | | ⚠ SPI | ⚠ EV / PV | ⚠ dưới 1 là chậm | | ⚠ EAC | ⚠ BAC / CPI | ⚠ dự báo tổng chi phí khi xong, giả định xu hướng giữ nguyên | | ⚠ ETC | ⚠ EAC − AC | ⚠ còn phải chi bao nhiêu nữa | | ⚠ VAC | ⚠ BAC − EAC | ⚠ âm là sẽ vượt ngân sách | | ⚠ TCPI | ⚠ (BAC − EV) / (BAC − AC) | ⚠ hiệu suất cần đạt để về đúng ngân sách |

⚠ Áp vào bài này: | Chỉ số | Kết quả | |---|---| | ⚠ CV | ⚠ 115.000 − 126.500 = −11.500 | | ⚠ SV | ⚠ 115.000 − 172.500 = −57.500 | | ⚠ EAC | ⚠ 575.000 / 0,909 ≈ 632.500 | | ⚠ VAC | ⚠ 575.000 − 632.500 = −57.500 — dự báo vượt ngân sách |

Từ khoá nhận diện:

"chi nhiều hơn X% cho phần việc đã làm" → ⚠ AC = EV × (1 + X%) "hoàn thành X% nhưng đáng lẽ phải Y%" → ⚠ EV = BAC×X, PV = BAC×Y "chỉ số hiệu suất" → ⚠ luôn là TỶ SỐ quanh 1, loại ngay phương án là số tiền

⚠ Mẹo làm nhanh dạng câu này Mẹo
⚠ EV luôn tính từ % HOÀN THÀNH THỰC TẾ ⚠ không phải % kế hoạch
⚠ PV tính từ % ĐÁNG LẼ phải xong
⚠ Phương án là SỐ TIỀN thì chắc chắn không phải CPI hay SPI ⚠ loại được ngay hai phương án
⚠ Đừng ⚠ nhầm 10% vượt chi thành 10% của BAC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | % hoàn thành báo cáo có đáng tin không | ⚠ EV sai thì mọi chỉ số sai theo | | CPI có xu hướng ổn định hay xấu dần | ⚠ quyết định công thức EAC nào phù hợp | | Đã báo nhà tài trợ chưa | ⚠ CPI 0,91 và SPI 0,67 là mức phải báo cáo |

Và cách đọc nhanh sức khoẻ dự án: CPI 0,91 là vượt chi vừa phải, SPI 0,67 là chậm nghiêm trọng. Vấn đề lớn hơn nằm ở tiến độ, và nếu ép tiến độ bằng thêm nguồn lực thì CPI sẽ còn xấu đi.

Câu 128
You are the project manager for a marketing project to mail out 1,000,000 postcards to prospective customers. Rather than mail out all 1,000,000 postcards at once, you and the team design three cards of different designs that you’ll mail in batches of 100,000. Whichever card gets the best response will be the selected card for the balance of the 1,000,000. What quality tool are you using in this scenario?
  1. A Quality assurance
  2. B Design of experiments
  3. C Design for X
  4. D Rule of seven
Xem giải thích

Đáp án

B — Design of experiments (thiết kế thực nghiệm — DOE).

Vì sao đúng

⚠ Dấu hiệu của DOE trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ Có NHIỀU phương án cần so sánh | ⚠ ba mẫu thiệp khác nhau | | ⚠ Thử trên MẪU NHỎ trước | ⚠ 100.000 thay vì 1.000.000 | | ⚠ ĐO kết quả một cách có hệ thống | ⚠ tỷ lệ phản hồi | | ⚠ Dùng kết quả để CHỌN phương án tốt nhất | | | ⚠ Kết luận | ⚠ đây chính là thiết kế thực nghiệm — thay đổi biến số một cách có kiểm soát để tìm cấu hình tối ưu |

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

  • C (Design for X) — ⚠ là kỹ thuật THIẾT KẾ SẢN PHẨM nhằm tối ưu một khía cạnh cụ thể (⚠ dễ lắp ráp, dễ bảo trì, chi phí thấp); ⚠ không phải thử nghiệm so sánh.

  • A (Quality assurance) — ⚠ là cả một nhóm quy trình, ⚠ không phải một công cụ cụ thể.

  • D (Rule of seven) — ⚠ là quy tắc đọc BIỂU ĐỒ KIỂM SOÁT: ⚠ bảy điểm liên tiếp cùng một phía đường trung tâm là dấu hiệu quy trình mất kiểm soát dù chưa vượt giới hạn.

Ghi nhớ

⚠ Design of Experiments: | Đặc điểm | Nội dung | |---|---| | ⚠ Thay đổi NHIỀU biến CÙNG LÚC một cách có hệ thống | ⚠ hiệu quả hơn thử từng biến một | | ⚠ Tìm ra tổ hợp cho kết quả TỐT NHẤT | | | ⚠ Giảm số lần thử cần thiết | | | ⚠ Dùng ở Plan Quality Management | | | ⚠ Ví dụ điển hình | ⚠ thử ba mẫu quảng cáo, thử ba công thức vật liệu, A/B testing trên web |

Từ khoá nhận diện:

"thử nhiều phương án trên mẫu nhỏ rồi chọn" → ⚠ design of experiments "bảy điểm liên tiếp cùng một phía" → ⚠ rule of seven "thiết kế cho dễ bảo trì / dễ sản xuất" → ⚠ design for X "ba độ lệch chuẩn trên dưới đường trung tâm" → ⚠ control chart

⚠ Rule of seven — vì sao đáng nhớ riêng Nội dung
⚠ Bảy điểm liên tiếp cùng một phía đường trung tâm ⚠ hoặc bảy điểm liên tục tăng / giảm
⚠ Tất cả vẫn NẰM TRONG giới hạn kiểm soát
⚠ Nhưng đó KHÔNG phải ngẫu nhiên ⚠ xác suất quá thấp
⚠ Phải làm gì ⚠ ĐIỀU TRA nguyên nhân — quy trình đã lệch dù chưa vượt ngưỡng
⚠ Vì sao thử trên lô nhỏ là quyết định đúng Lý do
⚠ Sai lầm trên 100.000 thiệp rẻ hơn trên 1.000.000
⚠ Có dữ liệu THẬT thay vì tranh cãi ý kiến
⚠ Cải thiện kết quả cho 700.000 thiệp còn lại
⚠ Đây cũng là tinh thần của ⚠ cách tiếp cận lặp và tăng dần — học sớm, sai rẻ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang đo cái gì để so sánh | ⚠ phải định nghĩa trước khi thử | | Cỡ mẫu có đủ để kết luận không | | | Có biến nào khác đang gây nhiễu không | ⚠ gửi ba mẫu vào ba thời điểm khác nhau là hỏng thí nghiệm |

Và giá trị lớn nhất của DOE trong dự án: nó thay tranh luận bằng dữ liệu. Ba người có ba ý kiến về mẫu thiệp đẹp nhất; 100.000 khách hàng cho một câu trả lời không cãi được.

Câu 129
You are the project manager for your organization and you’re working with the project team. You’ve been tasked with finding a good solution for a remodeling project that keeps the project budget under $125,000 for materials. You’ve already identified the appliances and fixtures with the project team, but now you’re working to make the best choices for the floors, cabinets, and countertops the project will require. Ned, a project team member, has identified that if you choose wood floors instead of tile floors you’ll have $5,000 less for the cabinet portion of the project. Mary, another team member, feels strongly about the tile floors as these are more durable considering the traffic through the room to be remodeled. The team works together, and they find a tile flooring that looks like wood that everyone can agree upon. What is the best description of what’s happening in this scenario?
  1. A Alternatives identification
  2. B Storming
  3. C Product description
  4. D Product scope creation
Xem giải thích

Đáp án

A — Alternatives identification (nhận diện phương án thay thế).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ Có NHIỀU cách để đạt cùng một mục tiêu | ⚠ sàn gỗ hay sàn gạch | | ⚠ Mỗi lựa chọn có ĐÁNH ĐỔI rõ ràng | ⚠ chọn gỗ thì còn ít tiền hơn 5.000 cho tủ bếp | | ⚠ Có tiêu chí khác nhau để cân nhắc | ⚠ Mary nêu độ bền do lưu lượng đi lại | | ⚠ Có RÀNG BUỘC ngân sách 125.000 | | | ⚠ Kết luận | ⚠ đội đang liệt kê và so sánh các phương án — đúng định nghĩa alternatives identification / analysis |

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

  • B (Storming) — ⚠ là giai đoạn phát triển đội trong mô hình Tuckman; ⚠ đề mô tả một cuộc thảo luận kỹ thuật bình thường, ⚠ không phải xung đột về vai trò và quyền lực.

  • C (Product description) — ⚠ là mô tả sản phẩm cần tạo ra, ⚠ không phải hoạt động so sánh phương án.

  • D (Product scope creation) — ⚠ không phải tên quy trình PMBOK nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25615 ở lô trước về alternatives analysis trong Plan Scope Management. ⚠ Cùng một kỹ thuật, ở đây áp dụng vào việc chọn vật liệu trong ràng buộc ngân sách.

⚠ Alternatives identification / analysis: | Đặc điểm | Nội dung | |---|---| | ⚠ Là kỹ thuật PHÂN TÍCH DỮ LIỆU | | | ⚠ Dùng ở RẤT NHIỀU quy trình | ⚠ phạm vi, lịch, chi phí, rủi ro, mua sắm | | ⚠ Việc làm: liệt kê các cách, so sánh, chọn | | | ⚠ Công cụ hỗ trợ | ⚠ ma trận quyết định có trọng số, phân tích chi phí – lợi ích, cây quyết định |

Từ khoá nhận diện:

"cách A hay cách B, mỗi cách được cái này mất cái kia" → ⚠ alternatives analysis "tính giá trị tiền tệ kỳ vọng của từng nhánh" → ⚠ decision tree "chấm điểm nhiều tiêu chí có trọng số" → ⚠ weighted decision matrix "so lợi ích với chi phí" → ⚠ cost-benefit analysis

⚠ Cách xử lý tình huống này cho đúng Bước
⚠ Liệt kê ĐẦY ĐỦ các phương án, không chỉ hai ⚠ có thể có sàn nhựa, sàn công nghiệp
⚠ Xác định TIÊU CHÍ và trọng số ⚠ chi phí, độ bền, thẩm mỹ, thời gian thi công, bảo trì
⚠ Chấm điểm từng phương án theo tiêu chí
⚠ Kiểm tra ràng buộc 125.000 với từng tổ hợp
⚠ Quyết định dựa trên điểm, không dựa trên ai nói to hơn
⚠ Lưu ý ⚠ Mary nêu độ bền là một tiêu chí HỢP LỆ, không phải cãi cùn — phải đưa vào bảng chấm điểm
⚠ Ràng buộc ngân sách tạo ra bài toán gì Nội dung
⚠ Tổng các hạng mục phải ≤ 125.000
⚠ Chi thêm ở hạng mục này là chi bớt ở hạng mục khác ⚠ đúng điều Ned chỉ ra
⚠ Nên nhìn TỔNG THỂ chứ không tối ưu từng hạng mục
⚠ Sai lầm phổ biến ⚠ chọn xong sàn rồi mới phát hiện không đủ tiền làm tủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã liệt kê đủ phương án chưa | ⚠ chỉ có hai lựa chọn thường là dấu hiệu chưa tìm kỹ | | Tiêu chí đánh giá đã được thống nhất trước chưa | ⚠ thống nhất sau khi có kết quả là thiên vị | | Đã kiểm tra tổng ngân sách cho từng tổ hợp chưa | |

Và điều khiến tình huống này thành bài học: hai thành viên không hề mâu thuẫn — họ đang nêu hai TIÊU CHÍ khác nhau. Ned nói về chi phí, Mary nói về độ bền; việc của PM là đưa cả hai vào cùng một bảng so sánh thay vì chọn phe.

Câu 130
You are the project manager for the GHB Project and you’re working with the project team to create the project schedule. Jeff, a project team member, has identified two tasks that don’t need to happen sequentially, but could happen at the same time if one task starts a day before the second task. What type of relationship could you apply to these to two tasks?
  1. A FS
  2. B Lead, one day
  3. C SS
  4. D SF
Xem giải thích

Đáp án

C — SS (Start-to-Start — bắt đầu để bắt đầu).

Vì sao đúng

⚠ Bóc tách tình huống: | Chi tiết | Suy ra | |---|---| | ⚠ "hai việc KHÔNG cần làm nối tiếp" | ⚠ → không phải Finish-to-Start | | ⚠ "có thể làm CÙNG LÚC" | ⚠ → chạy song song | | ⚠ "nếu một việc bắt đầu trước việc kia MỘT NGÀY" | ⚠ → ràng buộc nằm ở điểm BẮT ĐẦU của cả hai | | ⚠ Kết luận | ⚠ quan hệ Start-to-Start, kèm độ trễ một ngày: SS + 1 ngày |

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

  • B (Lead, một ngày) — ⚠ SAI hai lần: ⚠ thứ nhất, ⚠ lead/lag KHÔNG phải một LOẠI QUAN HỆ mà là phần điều chỉnh gắn thêm vào quan hệ; ⚠ thứ hai, ⚠ một ngày chờ giữa hai điểm bắt đầu là LAG (độ trễ) chứ không phải LEAD (độ sớm) — ⚠ lead là khoảng thời gian việc sau được phép bắt đầu SỚM hơn so với logic gốc.

  • A (FS — Finish-to-Start) — ⚠ buộc việc trước phải XONG mới bắt đầu việc sau; ⚠ trái với "làm cùng lúc".

  • D (SF — Start-to-Finish) — ⚠ quan hệ hiếm nhất: ⚠ việc trước bắt đầu thì việc sau mới kết thúc được; ⚠ không mô tả tình huống này.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25605 ở lô trước về lead time. ⚠ Câu này là chỗ dễ nhầm lead với lag nhất — đọc kỹ hai định nghĩa dưới đây.

⚠ Bốn quan hệ logic giữa hoạt động: | Quan hệ | Nghĩa | Mức phổ biến | |---|---|---| | ⚠ Finish-to-Start (FS) | ⚠ A xong thì B mới bắt đầu | ⚠ phổ biến nhất | | ⚠ Start-to-Start (SS) | ⚠ A bắt đầu thì B mới bắt đầu được | ⚠ hay dùng khi chạy song song | | ⚠ Finish-to-Finish (FF) | ⚠ A xong thì B mới xong được | ⚠ ít hơn | | ⚠ Start-to-Finish (SF) | ⚠ A bắt đầu thì B mới kết thúc được | ⚠ HIẾM nhất, thường gặp ở giao ca trực |

⚠ Lead và lag — phân biệt cho chắc: | Khái niệm | Nghĩa | Ký hiệu | |---|---|---| | ⚠ LEAD — độ sớm | ⚠ cho phép việc sau bắt đầu SỚM hơn logic gốc | ⚠ giá trị ÂM, ví dụ FS−2 ngày | | ⚠ LAG — độ trễ | ⚠ BUỘC phải chờ thêm trước khi việc sau bắt đầu | ⚠ giá trị DƯƠNG, ví dụ SS+1 ngày | | ⚠ Ví dụ lead | ⚠ bắt đầu viết tài liệu khi thiết kế còn 2 ngày nữa mới xong | | ⚠ Ví dụ lag | ⚠ đổ bê tông xong phải chờ 3 ngày mới xây tiếp |

Từ khoá nhận diện:

"làm cùng lúc, ràng buộc ở điểm bắt đầu" → ⚠ SS "phải xong cùng lúc" → ⚠ FF "chờ thêm bao nhiêu ngày" → ⚠ LAG, dấu dương "bắt đầu sớm hơn, chồng lấn" → ⚠ LEAD, dấu âm "rút ngắn lịch bằng cách chồng lấn công việc" → ⚠ fast tracking, thường dùng lead

⚠ Vì sao dùng SS thay vì FS Lý do
⚠ Rút ngắn tổng thời gian dự án
⚠ Tận dụng nguồn lực song song
⚠ Phản ánh đúng thực tế công việc ⚠ nhiều việc không cần chờ nhau xong hẳn
⚠ Đánh đổi ⚠ chạy song song làm TĂNG RỦI RO phải làm lại nếu việc trước thay đổi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quan hệ trong lịch của bạn có phải toàn FS không | ⚠ thường là dấu hiệu chưa tối ưu | | Lag trong lịch có căn cứ thật không | ⚠ lag bịa ra là một dạng padding | | Chạy song song có làm tăng rủi ro làm lại không | |

Và mẹo nhớ dấu: lag là chờ nên cộng, lead là sớm nên trừ. Một ngày chờ giữa hai điểm bắt đầu luôn là SS+1, không bao giờ là lead.