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

Tìm thấy 201 câu.

Câu 111
You are the project manager of the NKK Project for your organization. The project team has created the project ground rules for the project team, which includes that all project team members must attend all project status meetings each Thursday unless they are excused from the meeting. Sandy, a project team member, has skipped the last few meetings because she hasn’t any work due in the project at this time. The team approaches you to resolve this situation. What should you do next?
  1. A The project team should enforce the ground rules and speak with Sandy.
  2. B You and the project team should review the ground rules as a whole.
  3. C You should enforce the ground rules and speak with Sandy.
  4. D Sandy doesn’t need to attend the meeting as she has nothing to contribute at this time.
Xem giải thích

Đáp án

A — ĐỘI DỰ ÁN nên thực thi quy tắc nền và nói chuyện với Sandy.

Vì sao đúng

⚠ Nguyên tắc về ground rules: | Nguyên tắc | Nội dung | |---|---| | ⚠ Quy tắc nền do ĐỘI cùng đặt ra | ⚠ đề nói rõ "the project team has created the project ground rules" | | ⚠ Đã do đội đặt thì ĐỘI chịu trách nhiệm thực thi | | | ⚠ PMBOK nói rõ điều này | ⚠ trách nhiệm thực thi thuộc về TẤT CẢ thành viên | | ⚠ PM chỉ can thiệp khi đội KHÔNG tự giải quyết được | | | ⚠ Ở đây | ⚠ đội đã tới gặp bạn nhưng bước ĐÚNG TIẾP THEO vẫn là để đội nói chuyện với Sandy |

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

  • C (BẠN thực thi quy tắc và nói chuyện với Sandy) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ chỉ khác A ở chỗ ai hành động; ⚠ PM đứng ra thay đội sẽ ⚠ tước mất quyền tự quản của đội và ⚠ khiến quy tắc nền trở thành luật do PM áp xuống.

  • B (xem lại toàn bộ quy tắc nền) — ⚠ phản ứng THÁI QUÁ: ⚠ một người vi phạm không có nghĩa quy tắc sai; ⚠ chỉ nên xem lại khi quy tắc chứng tỏ là không phù hợp.

  • D (Sandy không cần dự họp vì không có gì để đóng góp) — ⚠ SAI: ⚠ quy tắc nền áp dụng cho MỌI người; ⚠ và ⚠ họp trạng thái không chỉ để báo cáo mà còn để NGHE những gì ảnh hưởng tới phần việc sắp tới của mình.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25597 ở lô này cũng nói tới cuộc họp thứ Năm. ⚠ Ở câu này thứ Năm chỉ là chi tiết bối cảnh, không phải phép tính.

⚠ Ground rules — quy tắc nền: | Điều | Nội dung | |---|---| | ⚠ Là đầu ra của Develop Team / thuộc team charter | | | ⚠ Do ĐỘI cùng xây dựng, không phải PM áp xuống | ⚠ cùng xây thì mới cùng tuân thủ | | ⚠ Nội dung điển hình | ⚠ giờ họp, cách giao tiếp, cách ra quyết định, cách xử lý xung đột, quy tắc tôn trọng | | ⚠ Ai thực thi | ⚠ TẤT CẢ thành viên đội | | ⚠ Vi phạm lặp lại | ⚠ lúc đó PM mới vào cuộc |

Từ khoá nhận diện:

"quy tắc do đội đặt ra" → ⚠ đội tự thực thi "một người vi phạm lần đầu" → ⚠ đội nói chuyện trực tiếp, chưa cần leo thang "vi phạm lặp lại nhiều lần" → ⚠ PM can thiệp "đội tự quản" → ⚠ PM đứng ra thay là làm suy yếu điều này

⚠ Thang leo thang khi có vi phạm Bước
⚠ 1. Đội nói chuyện trực tiếp với người vi phạm ⚠ bước của tình huống này
⚠ 2. PM nói chuyện riêng nếu vẫn tiếp diễn
⚠ 3. Đưa vào đánh giá hiệu suất
⚠ 4. Trao đổi với quản lý chức năng của người đó
⚠ Nguyên tắc chung ⚠ luôn bắt đầu ở mức THẤP NHẤT có thể
⚠ Vì sao Sandy vẫn nên dự họp Lý do
⚠ Nghe được thay đổi ảnh hưởng tới việc sắp tới của mình
⚠ Biết ai đang vướng để hỗ trợ
⚠ Sự vắng mặt chọn lọc phá vỡ chuẩn mực chung của đội
⚠ Nếu họp thật sự vô ích với một số người ⚠ thì hãy xem lại CÁCH HỌP, đừng để từng người tự ý bỏ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy tắc nền của đội bạn do ai đặt | ⚠ PM áp xuống thì đừng mong đội tự thực thi | | Vi phạm này là lần đầu hay lặp lại | ⚠ quyết định mức leo thang | | Cuộc họp có thật sự cần mọi người không | ⚠ nếu không thì vấn đề nằm ở cuộc họp |

Và lằn ranh cần thuộc trong dạng câu này: đội đặt quy tắc thì đội giữ quy tắc. PM nhảy vào quá sớm sẽ biến một chuẩn mực chung thành mệnh lệnh của sếp, và đội mất luôn khả năng tự điều chỉnh.

Câu 112
You are the project manager of the NK Project for your organization, and you’ve created a tally list for the results of repeated activity in the project. What is a tally list?
  1. A It’s a checklist to conformance
  2. B It’s a list of all the different processes completed in the project
  3. C It’s a requirements traceability matrix for quality measurements
  4. D It’s a list of all the different types of defects in the project
Xem giải thích

Đáp án

D — Là danh sách tất cả các LOẠI khuyết tật trong dự án.

Vì sao đúng

⚠ Tally list — bảng đếm, chính là check sheet: | Đặc điểm | Nội dung | |---|---| | ⚠ Dùng cho HOẠT ĐỘNG LẶP LẠI | ⚠ đúng chữ "repeated activity" trong đề | | ⚠ Liệt kê các LOẠI khuyết tật | ⚠ mỗi loại một dòng | | ⚠ Đếm số lần mỗi loại xuất hiện | ⚠ gạch từng vạch — nên có tên "tally" | | ⚠ Mục đích: thu thập dữ liệu có tổ chức | | | ⚠ Là đầu vào cho | ⚠ biểu đồ Pareto và biểu đồ nhân quả |

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

  • A (danh sách kiểm tra sự phù hợp) — ⚠ đó là CHECKLIST, ⚠ dùng để xác nhận đã làm đủ các bước; ⚠ khác với bảng đếm khuyết tật.

  • B (danh sách các quy trình đã hoàn thành) — ⚠ không phải công cụ chất lượng nào cả.

  • C (ma trận truy vết yêu cầu cho các phép đo chất lượng) — ⚠ ma trận truy vết theo dõi YÊU CẦU từ nguồn tới bàn giao, ⚠ không đếm khuyết tật.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25626 ở lô trước về biểu đồ Pareto. ⚠ Tally list (check sheet) là bước THU THẬP dữ liệu, Pareto là bước XẾP HẠNG dữ liệu đó — hai bước liền nhau.

⚠ Bảy công cụ chất lượng cơ bản: | Công cụ | Dùng để | |---|---| | ⚠ Check sheet / tally sheet | ⚠ ĐẾM và thu thập dữ liệu | | ⚠ Pareto chart | ⚠ xếp hạng theo tần suất | | ⚠ Cause-and-effect (Ishikawa) | ⚠ truy nguyên nhân gốc | | ⚠ Flowchart | ⚠ vẽ luồng quy trình | | ⚠ Histogram | ⚠ phân bố tần suất | | ⚠ Control chart | ⚠ quy trình có ổn định không | | ⚠ Scatter diagram | ⚠ quan hệ hai biến |

Từ khoá nhận diện:

"đếm số lần xuất hiện của từng loại" → ⚠ check sheet / tally list "đánh dấu đã làm đủ các bước chưa" → ⚠ checklist "yêu cầu này đến từ đâu, đi tới bàn giao nào" → ⚠ requirements traceability matrix "hoạt động lặp lại" → ⚠ dấu hiệu của check sheet

⚠ Phân biệt checklist và check sheet Khác nhau
⚠ Checklist ⚠ danh sách VIỆC PHẢI LÀM, tick khi xong
⚠ Check sheet ⚠ bảng ĐẾM dữ liệu, gạch từng lần xảy ra
⚠ Hai từ rất giống nhau trong tiếng Anh ⚠ nhưng công dụng khác hẳn
⚠ Mẹo nhớ ⚠ check-LIST là làm gì, check-SHEET là đếm gì
⚠ Một tally list tốt gồm Cột
⚠ Tên loại khuyết tật
⚠ Số lần xuất hiện
⚠ Thời điểm hoặc ca làm việc ⚠ để thấy xu hướng theo thời gian
⚠ Nơi phát hiện ⚠ để thấy khâu nào sinh lỗi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các loại khuyết tật đã được định nghĩa rõ chưa | ⚠ hai người phân loại phải cho cùng kết quả | | Dữ liệu có được ghi ngay lúc xảy ra không | ⚠ ghi nhớ rồi điền sau là mất chính xác | | Đã dùng dữ liệu này vẽ Pareto chưa | ⚠ thu thập mà không phân tích là công cốc |

Và giá trị thật của công cụ đơn giản này: nó biến cảm giác "dạo này hay lỗi" thành con số bàn được. Không có bảng đếm thì mọi cuộc họp chất lượng đều dừng ở mức phỏng đoán.

Câu 113
Nancy is the project manager of a project to install new software throughout the organization. To date, the project has spent $125,000 of the $200,000 budget. Today, Nancy learns, that the software the project is to install has been replaced by a newer, less expensive software. Effectively, her project is ruined because of the new software released that the stakeholders want in lieu of the software Nancy’s project is to install. What term best describes the $125,000 that Nancy has already spent on the project?
  1. A Operating loss
  2. B Variable cost
  3. C Sunk cost
  4. D Opportunity costs
Xem giải thích

Đáp án

C — Sunk cost (chi phí chìm).

Vì sao đúng

⚠ Sunk cost là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Tiền ĐÃ CHI RỒI | ⚠ 125.000 của Nancy | | ⚠ KHÔNG THU HỒI được | | | ⚠ KHÔNG được tính vào quyết định tiếp tục hay dừng | ⚠ đây là điểm quan trọng nhất | | ⚠ Quyết định chỉ dựa vào chi phí TƯƠNG LAI và lợi ích TƯƠNG LAI | | | ⚠ Tình huống | ⚠ phần mềm mới đã thay thế, dự án mất giá trị — 125.000 đã chi là chi phí chìm |

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

  • A (Operating loss — lỗ hoạt động) — ⚠ là khái niệm KẾ TOÁN về kết quả kinh doanh kỳ báo cáo, ⚠ không mô tả tiền đã chi cho một dự án cụ thể.

  • B (Variable cost — chi phí biến đổi) — ⚠ là chi phí thay đổi theo khối lượng công việc; ⚠ đề không nói gì về quan hệ đó.

  • D (Opportunity cost — chi phí cơ hội) — ⚠ là giá trị của lựa chọn TỐT NHẤT BỊ BỎ QUA; ⚠ nếu Nancy bỏ dự án này để làm dự án khác trị giá 300.000 thì 300.000 mới là chi phí cơ hội.

Ghi nhớ

⚠ Nguyên tắc vàng về sunk cost:

⚠ "Chi phí chìm KHÔNG BAO GIỜ được đưa vào quyết định tiếp tục hay dừng dự án."

⚠ Sai lầm sunk cost fallacy Biểu hiện
⚠ "Đã bỏ ra 125.000 rồi, dừng thì phí" ⚠ SAI — 125.000 mất rồi dù dừng hay tiếp
⚠ Càng đầu tư nhiều càng khó dừng ⚠ escalation of commitment
⚠ Câu hỏi ĐÚNG là ⚠ "từ hôm nay trở đi, chi thêm bao nhiêu và thu về được gì?"
⚠ Với Nancy ⚠ nếu 75.000 còn lại không tạo ra giá trị nào thì nên dừng, bất kể đã chi 125.000

Từ khoá nhận diện:

"tiền đã chi, không thu hồi" → ⚠ sunk cost "giá trị của lựa chọn bị bỏ qua" → ⚠ opportunity cost "thay đổi theo khối lượng" → ⚠ variable cost "không đổi dù làm ít hay nhiều" → ⚠ fixed cost "gán trực tiếp cho dự án được" → ⚠ direct cost "chia sẻ với nhiều dự án, ví dụ tiền điện văn phòng" → ⚠ indirect cost

⚠ Ví dụ chi phí cơ hội cho dễ phân biệt Ví dụ
⚠ Có hai dự án: A lãi 500.000, B lãi 300.000
⚠ Chọn A ⚠ chi phí cơ hội = 300.000 — cái đã bỏ qua
⚠ Không liên quan gì tới số tiền đã chi
⚠ Nancy nên làm gì tiếp Bước
⚠ Phân tích giá trị còn lại của dự án ⚠ BỎ QUA 125.000 đã chi
⚠ Trình bày với nhà tài trợ để họ quyết định ⚠ quyết dừng dự án là của nhà tài trợ
⚠ Nếu dừng: đi đúng quy trình Close Project or Phase ⚠ vẫn phải kết thúc chuẩn, thu hồi bài học kinh nghiệm
⚠ Đừng ⚠ cố làm nốt chỉ để "khỏi phí tiền đã bỏ ra"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang tính chi phí đã chi hay chi phí sắp chi | ⚠ chỉ cái sau có nghĩa | | Giá trị còn lại của dự án là bao nhiêu | | | Ai có thẩm quyền quyết định dừng | ⚠ nhà tài trợ, không phải PM |

Và câu nói đáng nhớ nhất về chi phí chìm: tiền đã tiêu là chuyện của quá khứ, quyết định luôn thuộc về tương lai. Dự án bị huỷ đúng lúc rẻ hơn nhiều so với dự án hoàn thành xong không ai dùng.

Câu 114
Tom and Nancy are project team members and they are in a heated argument about achieving quality in the project. Nancy insists that quality is made by delivering exactly what the customer has requested in the project scope. Tom insists that quality for the customer is actually achieved by providing slightly more than what the customer has asked for but at minimal costs. They look to you, the project manager, to resolve this scenario. What should you do next?
  1. A Tell Tom and Nancy that quality is achieved by delivering more than what was expected.
  2. B Tell Tom and Nancy that quality is achieved by delivering exactly what was requested.
  3. C Tell Tom and Nancy that the customer will decide quality during scope validation and acceptance.
  4. D Tell Tom and Nancy that you’ll decide what quality is based on the Quality Management Plan.
Xem giải thích

Đáp án

B — Nói với Tom và Nancy rằng chất lượng đạt được bằng cách giao ĐÚNG những gì đã được yêu cầu.

Vì sao đúng

⚠ Định nghĩa chất lượng theo PMBOK: | Điều | Nội dung | |---|---| | ⚠ Chất lượng = mức độ ĐÁP ỨNG YÊU CẦU | ⚠ conformance to requirements | | ⚠ Không thừa, không thiếu | | | ⚠ Nancy ĐÚNG | ⚠ "giao đúng cái khách đã yêu cầu trong phạm vi" | | ⚠ Tom SAI | ⚠ "giao nhiều hơn một chút" chính là GOLD PLATING | | ⚠ Vì sao gold plating xấu | ⚠ tốn thời gian và tiền không ai duyệt, thêm rủi ro, và khách hàng không đòi thứ đó |

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

  • A (giao nhiều hơn mong đợi) — ⚠ ủng hộ gold plating, ⚠ trái với PMBOK.

  • C (khách hàng sẽ quyết định chất lượng lúc nghiệm thu phạm vi) — ⚠ lẫn hai khái niệm: ⚠ Validate Scope là xác nhận bàn giao có đúng phạm vi không, ⚠ chất lượng đã được định nghĩa từ lúc lập kế hoạch chứ không phải chờ tới lúc nghiệm thu mới biết.

  • D (bạn sẽ tự quyết dựa trên kế hoạch quản lý chất lượng) — ⚠ né tránh việc dạy đội hiểu đúng nguyên tắc; ⚠ kế hoạch chất lượng ghi lại chuẩn mực đã thống nhất, ⚠ nó không phải công cụ để PM phán quyết một cuộc tranh luận về khái niệm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25598 ở lô trước về gold plating. ⚠ Câu kia hỏi thẳng tên hiện tượng; câu này đặt nó vào một cuộc tranh luận giữa hai thành viên. Cùng một nguyên tắc.

⚠ Ba khái niệm hay bị lẫn: | Khái niệm | Nghĩa | Ai gây ra | |---|---|---| | ⚠ Gold plating | ⚠ ĐỘI tự thêm tính năng không ai yêu cầu | ⚠ đội dự án | | ⚠ Scope creep | ⚠ phạm vi phình ra không qua kiểm soát thay đổi | ⚠ thường từ bên liên quan | | ⚠ Change request hợp lệ | ⚠ thay đổi CÓ đánh giá và CÓ phê duyệt | ⚠ bất kỳ ai, nhưng đi đúng quy trình |

Từ khoá nhận diện:

"cho thêm một chút cho khách vui" → ⚠ gold plating — SAI "giao đúng cái đã thoả thuận" → ⚠ chất lượng theo PMBOK "đáp ứng yêu cầu" → ⚠ quality "đáp ứng nhu cầu thật của người dùng" → ⚠ grade và fitness for use — khái niệm khác

⚠ Vì sao gold plating nguy hiểm hơn vẻ ngoài Lý do
⚠ Tốn thời gian và chi phí KHÔNG có trong đường cơ sở
⚠ Thêm mã là thêm chỗ hỏng và thêm việc bảo trì
⚠ Đặt kỳ vọng sai cho lần sau ⚠ khách quen được cho thêm
⚠ Che giấu vấn đề tiến độ thật ⚠ có thời gian làm thêm nghĩa là ước lượng đã sai
⚠ Muốn thêm tính năng thì ⚠ đưa qua yêu cầu thay đổi chính thức
⚠ Chất lượng và cấp độ — quality vs grade Khác nhau
⚠ Quality ⚠ mức đáp ứng yêu cầu — chất lượng thấp LUÔN là vấn đề
⚠ Grade ⚠ hạng của sản phẩm về tính năng — hạng thấp có thể CHẤP NHẬN được
⚠ Ví dụ ⚠ phần mềm ít tính năng nhưng chạy không lỗi = grade thấp, quality cao — hoàn toàn ổn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng này có trong phạm vi đã duyệt không | ⚠ không có thì đừng làm | | Nếu thấy nên thêm thì đã mở yêu cầu thay đổi chưa | | | Đội có hiểu chất lượng nghĩa là gì không | ⚠ hiểu sai thì gold plating xảy ra âm thầm |

Và cách nói ngắn nhất cho đội: chất lượng là làm đúng, không phải làm nhiều. Một tính năng đẹp mà không ai đặt hàng vẫn là công việc ngoài phạm vi.

Câu 115
You are the project manager of the NK Project for your organization and you’re working with the project team to plan how to manage quality in the project. Your project team is confused, however, about the difference between quality assurance and quality control. What’s the best answer?
  1. A Quality assurance is a management process. Quality control is a project process.
  2. B Quality assurance is planned. Quality control is achieved.
  3. C Quality assurance is prevention-driven. Quality control is testing-driven.
  4. D Quality assurance is about planning quality. Quality control is about achieve quality.
Xem giải thích

Đáp án

A — Đảm bảo chất lượng là một quy trình QUẢN LÝ; kiểm soát chất lượng là một quy trình DỰ ÁN.

Vì sao đúng

⚠ Phân biệt hai quy trình: | Mục | Quality Assurance | Quality Control | |---|---|---| | ⚠ Tên PMBOK 6 | ⚠ Manage Quality | ⚠ Control Quality | | ⚠ Nhóm quy trình | ⚠ THỰC HIỆN | ⚠ GIÁM SÁT VÀ KIỂM SOÁT | | ⚠ Đối tượng | ⚠ QUY TRÌNH — cách làm việc | ⚠ SẢN PHẨM — bàn giao cụ thể | | ⚠ Câu hỏi trả lời | ⚠ "chúng ta có đang làm đúng cách không?" | ⚠ "thứ này có đạt yêu cầu không?" | | ⚠ Ai làm | ⚠ thường là bộ phận chất lượng / cấp quản lý | ⚠ đội dự án, người kiểm thử | | ⚠ Đầu ra chính | ⚠ báo cáo chất lượng, yêu cầu thay đổi | ⚠ phép đo kiểm soát chất lượng, bàn giao ĐÃ XÁC MINH | | ⚠ Vì thế | ⚠ QA mang tính quản lý toàn tổ chức, QC gắn với sản phẩm của chính dự án |

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

  • B (đảm bảo chất lượng được lập kế hoạch, kiểm soát chất lượng đạt được) — ⚠ mơ hồ và không phải cách phân biệt chuẩn; ⚠ cả hai đều có phần lập kế hoạch lẫn phần thực thi.

  • D (đảm bảo chất lượng là lập kế hoạch chất lượng, kiểm soát là đạt chất lượng) — ⚠ SAI: ⚠ lập kế hoạch chất lượng là quy trình RIÊNG Plan Quality Management, không phải QA.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Phương án C ("QA hướng PHÒNG NGỪA, QC hướng KIỂM THỬ") cũng là một cách phân biệt ĐÚNG và được dạy rộng rãi — ⚠ QA đúng là thiên về phòng ngừa, QC đúng là thiên về kiểm tra. ⚠ Đề chỉ có một đáp án nên rõ ràng nguồn đề lấy theo cách diễn đạt "management process vs project process". ⚠ Giữ nguyên khoá A, nhưng người học nên biết ⚠ cách phân biệt ở phương án C cũng chính xác về mặt nội dung — ⚠ nếu gặp câu tương tự mà không có phương án A thì C là đáp án.

⚠ Ba quy trình quản lý chất lượng của PMBOK 6: | Quy trình | Nhóm | Việc | |---|---|---| | ⚠ Plan Quality Management | ⚠ Lập kế hoạch | ⚠ xác định chuẩn chất lượng và cách đo | | ⚠ Manage Quality (QA) | ⚠ Thực hiện | ⚠ kiểm toán quy trình, cải tiến cách làm | | ⚠ Control Quality (QC) | ⚠ Giám sát và kiểm soát | ⚠ đo bàn giao, tìm khuyết tật |

Từ khoá nhận diện:

"kiểm toán quy trình" → ⚠ QA / Manage Quality "kiểm tra sản phẩm, đo bàn giao" → ⚠ QC / Control Quality "bàn giao đã xác minh" → ⚠ đầu ra của QC, là đầu vào của Validate Scope "khách hàng ký nhận" → ⚠ Validate Scope, KHÔNG phải QC

⚠ Trình tự chuẩn phải thuộc Bước
⚠ 1. Plan Quality Management ⚠ định nghĩa thế nào là đạt
⚠ 2. Manage Quality ⚠ đảm bảo quy trình làm việc đúng
⚠ 3. Control Quality ⚠ kiểm tra bàn giao → verified deliverables
⚠ 4. Validate Scope ⚠ khách hàng nghiệm thu → accepted deliverables
⚠ Bẫy thi hay gặp ⚠ đảo thứ tự bước 3 và bước 4

⚠ Đối chiếu: ⚠ câu #25591 ở lô trước hỏi thẳng thứ tự Control Quality trước Validate Scope. ⚠ Hai câu bổ sung nhau.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang kiểm tra QUY TRÌNH hay SẢN PHẨM | ⚠ quyết định gọi là QA hay QC | | Bàn giao đã qua QC trước khi đưa khách nghiệm thu chưa | | | Kết quả kiểm toán quy trình có dẫn tới cải tiến không | ⚠ QA mà không cải tiến gì là hình thức |

Và cách nhớ nhanh nhất: QA nhìn vào CÁCH LÀM, QC nhìn vào THỨ LÀM RA. Một bên sửa quy trình, một bên bắt lỗi sản phẩm.

Câu 116
As a project manager you need to identify assumptions, constraints, risks, and other facets of the project you’re managing. Which one of the following is not an example of a constraint?
  1. A A project requirement to use Microsoft Office
  2. B A project schedule based on predictable weather
  3. C A project budget of $250,000
  4. D A project deadline of December 12
Xem giải thích

Đáp án

B — Lịch trình dự án dựa trên thời tiết có thể dự đoán được. ⚠ Đây là GIẢ ĐỊNH, không phải ràng buộc.

Vì sao đúng

⚠ Phân biệt giả định và ràng buộc: | Khái niệm | Nghĩa | Đặc điểm | |---|---|---| | ⚠ Assumption — giả định | ⚠ điều ta COI LÀ ĐÚNG mà chưa có bằng chứng | ⚠ có thể sai → sinh RỦI RO | | ⚠ Constraint — ràng buộc | ⚠ giới hạn ĐÃ BIẾT CHẮC, bó buộc lựa chọn | ⚠ là sự thật, không phải phỏng đoán |

⚠ Vì sao "thời tiết dự đoán được" là giả định: | Lý do | Nội dung | |---|---| | ⚠ Không ai KIỂM SOÁT được thời tiết | | | ⚠ Không ai CHẮC CHẮN được thời tiết | | | ⚠ Ta chỉ đang GIẢ ĐỊNH nó sẽ như dự báo | | | ⚠ Nếu giả định sai | ⚠ sinh ra rủi ro chậm lịch — phải ghi vào sổ đăng ký rủi ro |

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

  • A (yêu cầu phải dùng Microsoft Office) — ⚠ LÀ ràng buộc: ⚠ giới hạn công nghệ đã được ấn định.

  • C (ngân sách 250.000) — ⚠ LÀ ràng buộc: ⚠ giới hạn chi phí, kinh điển nhất.

  • D (hạn chót 12 tháng 12) — ⚠ LÀ ràng buộc: ⚠ giới hạn thời gian.

Ghi nhớ

Từ khoá nhận diện:

"phải dùng, không được vượt, hạn chót là" → ⚠ ràng buộc "chúng tôi cho rằng, dự kiến, nếu mọi thứ bình thường" → ⚠ giả định "giả định này sai thì sao" → ⚠ đó là một RỦI RO, ghi vào risk register

⚠ Ba loại ràng buộc kinh điển Loại
⚠ Phạm vi ⚠ phải có tính năng gì
⚠ Thời gian ⚠ hạn chót cố định
⚠ Chi phí ⚠ ngân sách trần
⚠ PMBOK còn thêm ⚠ chất lượng, nguồn lực, rủi ro — thành sáu ràng buộc cạnh tranh
⚠ Assumption log — sổ đăng ký giả định Nội dung
⚠ Là đầu ra của Develop Project Charter
⚠ Ghi CẢ giả định LẪN ràng buộc
⚠ Cập nhật liên tục suốt dự án
⚠ Mỗi giả định phải được KIỂM CHỨNG hoặc chuyển thành rủi ro
⚠ Giả định không ai kiểm chứng ⚠ là nguồn gốc của rất nhiều sự cố dự án

⚠ Đối chiếu: ⚠ câu #25610 ở lô trước về assumption log. ⚠ Câu kia hỏi tài liệu nào ghi giả định; câu này hỏi phân biệt giả định với ràng buộc.

⚠ Cách kiểm tra nhanh một phát biểu Câu hỏi
⚠ "Điều này CHẮC CHẮN đúng chứ?" ⚠ chắc chắn → ràng buộc; chưa chắc → giả định
⚠ "Ai đặt ra điều này?" ⚠ có người/tổ chức ấn định → ràng buộc
⚠ "Nếu nó không đúng thì sao?" ⚠ có hậu quả → phải ghi vào sổ rủi ro

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn đang dựa trên giả định nào chưa ai kiểm chứng | | | Mỗi giả định quan trọng có rủi ro tương ứng chưa | | | Ràng buộc nào có thể đàm phán lại được | ⚠ nhiều "ràng buộc" thực ra chỉ là kỳ vọng |

Và mẹo phân biệt nhanh nhất: ràng buộc là thứ có người ĐẶT RA cho bạn, giả định là thứ bạn TỰ TIN là sẽ xảy ra. Thời tiết không ai đặt ra được, nên nó luôn nằm ở nhóm sau.

Câu 117
You are the project manager of the QQQ Project, and you’re working with the project sponsor to review the project performance. Currently, the project has a CPI of 0.9 and SPI of 0.67. Who is accountable for the development and maintenance of the project business case document based on project performance?
  1. A Project sponsor
  2. B Project manager
  3. C Project team
  4. D Project stakeholders
Xem giải thích

Đáp án

A — Project sponsor (nhà tài trợ dự án).

Vì sao đúng

⚠ Ai chịu trách nhiệm về business case: | Điều | Nội dung | |---|---| | ⚠ Business case là tài liệu KINH DOANH | ⚠ lý giải vì sao dự án đáng làm | | ⚠ Được tạo ra TRƯỚC khi dự án tồn tại | ⚠ nên PM còn chưa được bổ nhiệm | | ⚠ NHÀ TÀI TRỢ phát triển và duy trì nó | ⚠ PMBOK nói rõ điều này | | ⚠ Nhà tài trợ cũng là người quyết định dừng dự án | ⚠ khi business case không còn đứng vững | | ⚠ Với CPI 0,9 và SPI 0,67 | ⚠ dự án vượt chi và chậm nặng — nhà tài trợ phải xem lại business case còn hợp lý không |

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

  • B (Project manager) — ⚠ PM chịu trách nhiệm THỰC HIỆN dự án và cung cấp SỐ LIỆU, ⚠ nhưng không sở hữu business case.

  • C (Project team) — ⚠ đội thực hiện công việc, ⚠ không liên quan tới tài liệu kinh doanh.

  • D (Project stakeholders) — ⚠ quá rộng; ⚠ trách nhiệm phải quy về MỘT vai trò cụ thể.

Ghi nhớ

⚠ Ý nghĩa số liệu trong đề: | Chỉ số | Giá trị | Nghĩa | |---|---|---| | ⚠ CPI = 0,9 | ⚠ < 1 | ⚠ cứ 1 đồng chi ra chỉ thu về 0,9 đồng giá trị — VƯỢT CHI | | ⚠ SPI = 0,67 | ⚠ < 1 | ⚠ chỉ làm được 67% khối lượng đáng lẽ phải xong — CHẬM NẶNG | | ⚠ Kết luận | ⚠ dự án đang gặp vấn đề nghiêm trọng ở cả hai mặt |

⚠ Ai sở hữu tài liệu nào: | Tài liệu | Ai sở hữu | |---|---| | ⚠ Business case | ⚠ NHÀ TÀI TRỢ | | ⚠ Benefits management plan | ⚠ NHÀ TÀI TRỢ | | ⚠ Project charter | ⚠ nhà tài trợ KÝ BAN HÀNH, PM có thể soạn thảo | | ⚠ Project management plan | ⚠ QUẢN LÝ DỰ ÁN | | ⚠ Requirements documentation | ⚠ quản lý dự án, với đầu vào từ bên liên quan |

Từ khoá nhận diện:

"business case, benefits management plan" → ⚠ nhà tài trợ "kế hoạch quản lý dự án và các kế hoạch con" → ⚠ quản lý dự án "ai ký ban hành điều lệ" → ⚠ nhà tài trợ hoặc người khởi xướng "ai quyết định dừng dự án" → ⚠ nhà tài trợ

⚠ Vai trò khác của nhà tài trợ Vai trò
⚠ Cấp NGUỒN LỰC và ngân sách
⚠ Ký ban hành điều lệ dự án
⚠ Gỡ vướng mắc vượt thẩm quyền PM
⚠ Bảo vệ dự án trước cấp lãnh đạo
⚠ Phê duyệt thay đổi lớn
⚠ Quyết định tiếp tục hay dừng ⚠ đúng tình huống của câu này
⚠ Khi nào business case phải xem lại Thời điểm
⚠ Cuối mỗi giai đoạn — phase gate
⚠ Khi hiệu suất lệch nhiều so với kế hoạch ⚠ CPI 0,9 và SPI 0,67 là ví dụ
⚠ Khi môi trường kinh doanh thay đổi
⚠ Khi có yêu cầu thay đổi lớn

⚠ Đối chiếu: ⚠ câu #25586 ở lô trước về việc điều lệ dự án không nhất thiết do nhà tài trợ soạn. ⚠ Hai câu cùng chủ đề ranh giới trách nhiệm giữa nhà tài trợ và quản lý dự án.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Business case của dự án bạn còn đứng vững không | | | Nhà tài trợ có đang theo dõi số liệu hiệu suất không | ⚠ PM có nghĩa vụ báo cáo trung thực | | Ai là người có thẩm quyền dừng dự án | ⚠ phải rõ từ đầu |

Và ranh giới cần thuộc: PM chịu trách nhiệm LÀM ĐÚNG dự án, nhà tài trợ chịu trách nhiệm dự án ĐÁNG LÀM. Số liệu xấu là tín hiệu để nhà tài trợ trả lời câu hỏi thứ hai.

Câu 118
Complete this statement about quality: Quality is __________________ into a project and is never _________________________ into a project.
  1. A Quality is made into a project and is never purchased into a project.
  2. B Quality is planned into a project and is never purchased into a project.
  3. C Quality is built into a project and is never planned into a project.
  4. D Quality is planned into a project and is never inspected into a project.
Xem giải thích

Đáp án

D — Chất lượng được LẬP KẾ HOẠCH vào dự án, không bao giờ được KIỂM TRA vào dự án.

Vì sao đúng

⚠ Câu châm ngôn kinh điển của quản lý chất lượng:

⚠ "Quality is PLANNED in, not INSPECTED in."

Ý nghĩa Nội dung
⚠ Chất lượng phải được thiết kế từ ĐẦU ⚠ định nghĩa chuẩn, chọn quy trình, đào tạo người
⚠ Kiểm tra chỉ PHÁT HIỆN lỗi đã có ⚠ nó không TẠO RA chất lượng
⚠ Kiểm tra càng nhiều không làm sản phẩm tốt hơn ⚠ chỉ làm bạn biết nó tệ tới mức nào
⚠ Phòng ngừa RẺ hơn kiểm tra, kiểm tra RẺ hơn sửa lỗi
⚠ Nguồn gốc ⚠ W. Edwards Deming — "chấm dứt việc phụ thuộc vào kiểm tra hàng loạt"

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

  • B (lập kế hoạch / không phải mua) — ⚠ vế đầu ĐÚNG nhưng vế sau SAI: ⚠ câu châm ngôn chuẩn nói về kiểm tra, không nói về mua.

  • C (xây vào / không phải lập kế hoạch vào) — ⚠ SAI ngược hoàn toàn: ⚠ lập kế hoạch chính là cách chất lượng đi vào dự án.

  • A (làm ra / không phải mua) — ⚠ không phải câu châm ngôn nào cả.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25628 ở lô trước — ⚠ bỏ kiểm thử để kịp hạn khiến lỗi lọt ra vận hành. ⚠ Câu này là nguyên tắc, câu kia là hậu quả khi vi phạm nguyên tắc. ⚠ Và câu #25636 phân biệt QA với QC.

⚠ Thứ tự chi phí — nguyên tắc nền tảng: | Hoạt động | Chi phí tương đối | |---|---| | ⚠ PHÒNG NGỪA | ⚠ rẻ nhất — đào tạo, quy trình tốt, thiết kế đúng | | ⚠ KIỂM TRA | ⚠ đắt hơn — kiểm thử, thẩm định | | ⚠ SỬA LỖI NỘI BỘ | ⚠ đắt hơn nữa — làm lại trước khi giao | | ⚠ SỬA LỖI SAU KHI GIAO | ⚠ đắt nhất — bảo hành, mất uy tín, kiện tụng |

Từ khoá nhận diện:

"chất lượng được lập kế hoạch mà có" → ⚠ planned in, not inspected in "kiểm tra hàng loạt để đảm bảo chất lượng" → ⚠ cách làm SAI theo Deming "phòng ngừa hơn chữa" → ⚠ prevention over inspection "chi phí chất lượng" → ⚠ cost of quality, bốn loại

⚠ Chất lượng đi vào dự án bằng những cách nào Cách
⚠ Định nghĩa rõ CHUẨN CHẤT LƯỢNG ngay từ đầu ⚠ Plan Quality Management
⚠ Chọn quy trình và công cụ phù hợp
⚠ Đào tạo người làm
⚠ Thiết kế để dễ kiểm tra và khó sai
⚠ Xây dựng văn hoá không đổ lỗi khi báo lỗi
⚠ Kiểm tra vẫn cần ⚠ nhưng là lưới an toàn, không phải nguồn của chất lượng
⚠ Vài câu châm ngôn chất lượng hay ra thi Câu
⚠ "Chất lượng được lập kế hoạch mà có, không phải kiểm tra mà có"
⚠ "Phòng ngừa hơn kiểm tra" ⚠ prevention over inspection
⚠ "Chất lượng khác cấp độ" ⚠ quality vs grade
⚠ "Chi phí phòng ngừa thấp hơn chi phí sửa lỗi"
⚠ "Trách nhiệm chất lượng thuộc về TẤT CẢ, nhưng cuối cùng là quản lý"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuẩn chất lượng đã được định nghĩa từ đầu chưa | | | Bạn đang dựa vào phòng ngừa hay dựa vào kiểm thử | | | Tỷ lệ lỗi tìm thấy ở kiểm thử có đang tăng không | ⚠ dấu hiệu chất lượng đầu vào kém |

Và cách nói dễ nhớ nhất: cân không làm con lợn béo lên. Đo đếm nhiều tới đâu cũng không cải thiện thứ đã làm ra — chỉ cách làm mới thay đổi được kết quả.

Câu 119
Projects exist and operate in environments that may influence them. Some of these influences originate from the environment outside of the project, whereas some others are internal to the organization. Which of the following is an organizational process asset that can influence a project?
  1. A Legal restrictions
  2. B Government or industry standards
  3. C Organizational culture, structure, and governance
  4. D Processes, policies, and procedures
Xem giải thích

Đáp án

D — Quy trình, chính sách và thủ tục (processes, policies, and procedures).

Vì sao đúng

⚠ Organizational Process Assets — tài sản quy trình tổ chức: | Nhóm | Nội dung | |---|---| | ⚠ Quy trình, chính sách và thủ tục | ⚠ cách tổ chức làm việc — đúng phương án D | | ⚠ Kho tri thức của tổ chức | ⚠ cơ sở dữ liệu bài học kinh nghiệm, hồ sơ dự án cũ, dữ liệu tài chính, kho cấu hình | | ⚠ Đặc điểm chung | ⚠ DO TỔ CHỨC TẠO RA và tổ chức KIỂM SOÁT được | | ⚠ Vì thế | ⚠ tổ chức có thể sửa đổi và cải tiến chúng |

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

⚠ Cả ba phương án còn lại đều là EEF — Enterprise Environmental Factors, tức YẾU TỐ MÔI TRƯỜNG DOANH NGHIỆP:

  • A (Ràng buộc pháp lý) — ⚠ EEF BÊN NGOÀI: ⚠ luật pháp tổ chức không tự đặt ra được.

  • B (Tiêu chuẩn của chính phủ hoặc của ngành) — ⚠ EEF BÊN NGOÀI.

  • C (Văn hoá, cơ cấu và quản trị tổ chức) — ⚠ EEF BÊN TRONG: ⚠ đây là phương án gây nhiễu mạnh nhất vì ⚠ văn hoá nằm bên trong tổ chức, ⚠ nhưng nó là ĐIỀU KIỆN chứ không phải TÀI SẢN dùng lại được — ⚠ PMBOK xếp nó vào EEF.

Ghi nhớ

⚠ Cách phân biệt EEF và OPA — mẹo chắc chắn nhất: | Câu hỏi | Trả lời | |---|---| | ⚠ "Nó có phải thứ tổ chức TẠO RA và DÙNG LẠI được không?" | ⚠ CÓ → OPA | | ⚠ "Nó là ĐIỀU KIỆN mà dự án phải chấp nhận?" | ⚠ CÓ → EEF | | ⚠ Mẹo phụ | ⚠ OPA thường là TÀI LIỆU hoặc DỮ LIỆU; EEF thường là HOÀN CẢNH |

⚠ Bảng phân loại đầy đủ: | Loại | Ví dụ | |---|---| | ⚠ EEF bên ngoài | ⚠ luật pháp, tiêu chuẩn ngành, điều kiện thị trường, tỷ giá, thời tiết, chính trị | | ⚠ EEF bên trong | ⚠ văn hoá, cơ cấu, quản trị, hạ tầng, phần mềm sẵn có, phân bố địa lý, năng lực nhân sự | | ⚠ OPA — quy trình | ⚠ hướng dẫn, mẫu biểu, quy trình chuẩn, tiêu chí đánh giá, thủ tục kiểm soát thay đổi | | ⚠ OPA — kho tri thức | ⚠ bài học kinh nghiệm, hồ sơ dự án cũ, dữ liệu chi phí lịch sử, kho cấu hình, dữ liệu vấn đề và khuyết tật |

Từ khoá nhận diện:

"quy trình, mẫu biểu, bài học kinh nghiệm, dữ liệu lịch sử" → ⚠ OPA "luật, tiêu chuẩn, thị trường, văn hoá, cơ cấu" → ⚠ EEF "tổ chức tự đặt ra và sửa được" → ⚠ OPA "dự án phải chấp nhận, không đổi được" → ⚠ EEF

⚠ Vì sao PMBOK tách hai khái niệm này Lý do
⚠ Chúng xuất hiện ở ĐẦU VÀO của gần như MỌI quy trình ⚠ nên phải phân biệt được
⚠ OPA giúp dự án làm NHANH hơn ⚠ có mẫu sẵn thì không phải dựng từ đầu
⚠ EEF vừa hỗ trợ vừa CẢN TRỞ ⚠ phải nhận diện để lập kế hoạch phù hợp
⚠ Mẹo thi ⚠ văn hoá tổ chức là bẫy quen thuộc nhất — nó là EEF chứ không phải OPA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có kho bài học kinh nghiệm không | ⚠ OPA quý nhất mà hay bị bỏ quên nhất | | Bạn có đang dựng lại thứ tổ chức đã có mẫu không | | | EEF nào đang cản trở dự án | ⚠ chấp nhận và lập kế hoạch quanh nó |

Và ranh giới gọn nhất: OPA là thứ tổ chức ĐƯA CHO bạn dùng, EEF là hoàn cảnh bạn PHẢI SỐNG CÙNG. Văn hoá thuộc vế sau — bạn không mượn nó về dùng như một biểu mẫu được.

Câu 120
Gary is the project manager of the JKP Project, and he believes in McClelland’s Theory of Needs. As part of his belief, he has the project team complete a thematic apperception test. All of the following are part of this theory except for which one?
  1. A Need for affiliation
  2. B Need for power
  3. C Need for ambition
  4. D Need for achievement
Xem giải thích

Đáp án

C — Need for ambition (nhu cầu tham vọng). ⚠ Không có nhu cầu này trong thuyết McClelland.

Vì sao đúng

⚠ Thuyết Nhu cầu của McClelland — ba nhu cầu: | Nhu cầu | Người có nhu cầu này | |---|---| | ⚠ Achievement — THÀNH TỰU | ⚠ thích việc thử thách vừa sức, muốn phản hồi rõ ràng, thích tự chịu trách nhiệm kết quả | | ⚠ Power — QUYỀN LỰC | ⚠ thích ảnh hưởng và dẫn dắt người khác, thích cạnh tranh và địa vị | | ⚠ Affiliation — LIÊN KẾT | ⚠ thích quan hệ hoà thuận, muốn được chấp nhận, tránh xung đột | | ⚠ "Tham vọng" | ⚠ KHÔNG phải một trong ba — đây là phương án bịa |

⚠ Thematic Apperception Test (TAT): | Điều | Nội dung | |---|---| | ⚠ Là công cụ McClelland dùng để đo ba nhu cầu | | | ⚠ Cho người tham gia xem ẢNH mơ hồ rồi bảo họ kể một câu chuyện | | | ⚠ Nội dung câu chuyện phản ánh nhu cầu chiếm ưu thế của họ | | | ⚠ Đề nhắc TAT | ⚠ để xác nhận đúng là đang nói về McClelland |

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

  • A (Need for affiliation), B (Need for power), D (Need for achievement) — ⚠ cả ba ĐỀU là một phần của thuyết.

Ghi nhớ

⚠ Ứng dụng thực tế — giao việc theo nhu cầu: | Người thiên về | Nên giao | |---|---| | ⚠ Thành tựu | ⚠ việc khó vừa sức, có mục tiêu rõ, có phản hồi thường xuyên | | ⚠ Quyền lực | ⚠ vai trò dẫn dắt, đại diện đội, thương lượng | | ⚠ Liên kết | ⚠ việc theo nhóm, phối hợp, chăm sóc quan hệ với bên liên quan | | ⚠ Giao sai | ⚠ người thiên liên kết mà bắt đi đàm phán căng thẳng sẽ rất khổ |

⚠ Các thuyết động lực hay ra thi — bảng so sánh: | Thuyết | Nội dung cốt lõi | |---|---| | ⚠ Maslow | ⚠ tháp năm bậc: sinh lý, an toàn, xã hội, được tôn trọng, tự thể hiện | | ⚠ Herzberg | ⚠ hai yếu tố: DUY TRÌ (lương, điều kiện) chỉ chống bất mãn; ĐỘNG VIÊN (thành tựu, ghi nhận) mới tạo động lực | | ⚠ McGregor | ⚠ Thuyết X (người lười, phải giám sát) và Thuyết Y (người tự giác, muốn làm tốt) | | ⚠ McClelland | ⚠ ba nhu cầu: thành tựu, quyền lực, liên kết | | ⚠ Vroom | ⚠ thuyết kỳ vọng: động lực = kỳ vọng × phương tiện × giá trị phần thưởng | | ⚠ Ouchi | ⚠ Thuyết Z: việc làm trọn đời, quan tâm toàn diện tới nhân viên |

Từ khoá nhận diện:

"ba nhu cầu, bài kiểm tra kể chuyện qua ảnh" → ⚠ McClelland "tháp nhu cầu năm bậc" → ⚠ Maslow "lương cao không tạo động lực, chỉ chống bất mãn" → ⚠ Herzberg "người lười hay người tự giác" → ⚠ McGregor X và Y "tin rằng cố gắng sẽ dẫn tới phần thưởng mình muốn" → ⚠ Vroom

⚠ Bẫy thường gặp Đính chính
⚠ Nhầm McClelland với Maslow ⚠ một bên BA nhu cầu song song, một bên NĂM bậc thang
⚠ Tưởng ba nhu cầu loại trừ nhau ⚠ ai cũng có cả ba, chỉ khác nhau ở mức ưu thế
⚠ Tưởng "quyền lực" là xấu ⚠ McClelland phân biệt quyền lực CÁ NHÂN và quyền lực VÌ TỔ CHỨC — vế sau rất tốt cho lãnh đạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn biết mỗi thành viên thiên về nhu cầu nào không | | | Cách bạn ghi nhận có phù hợp với từng người không | ⚠ người thiên liên kết không thích được khen trước đám đông kiểu thi đua | | Bạn đang giao việc theo năng lực hay theo động lực | ⚠ cả hai đều cần |

Và giá trị thực dụng của thuyết này: cùng một phần thưởng không tạo động lực như nhau cho mọi người. Biết ai cần gì thì cùng một ngân sách khen thưởng cho ra hiệu quả khác hẳn.