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

Tìm thấy 201 câu.

Câu 1

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 variance for this project?

  1. A 0.91
  2. B

    13800
  3. C

    11500
  4. D 0.83
Xem giải thích

Đáp án

C — 11.500.

Vì sao đúng

⚠ Tính từng bước: | Bước | Phép tính | |---|---| | ⚠ BAC — ngân sách toàn dự án | ⚠ 575.000 | | ⚠ EV — giá trị đạt được | ⚠ 20% × 575.000 = 115.000 | | ⚠ AC — chi phí thực tế | ⚠ chi nhiều hơn 10% so với dự kiến cho phần đã làm | | ⚠ AC | ⚠ 115.000 × 1,10 = 126.500 | | ⚠ CV = EV − AC | ⚠ 115.000 − 126.500 = −11.500 |

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

  • A (0,91) — ⚠ là CPI: 115.000 ÷ 126.500 ≈ 0,909.

  • D (0,83) — ⚠ là SPI: EV ÷ PV = 115.000 ÷ 172.500 ≈ 0,667... hoặc tỷ lệ 20/30 ≈ 0,667; ⚠ dù sao cũng là chỉ số tỷ lệ, không phải variance.

  • B (13.800) — ⚠ không khớp phép tính nào.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đáp án đúng phải là ÂM: −11.500, vì dự án đang VƯỢT chi.

Nội dung Chi tiết
⚠ CV = EV − AC = −11.500 ⚠ giá trị âm
⚠ Phương án C ghi "11500" ⚠ thiếu dấu âm
⚠ Ý nghĩa của dấu ⚠ CV âm là vượt chi, CV dương là tiết kiệm
⚠ Khoá C vẫn ĐÚNG về ĐỘ LỚN ⚠ và là phương án duy nhất khớp
⚠ Khi làm bài ⚠ nhớ rằng dấu mang thông tin, đừng bỏ qua

⚠ Công thức Earned Value cần thuộc: | Chỉ số | Công thức | Ý nghĩa | |---|---|---| | ⚠ PV | ⚠ % kế hoạch × BAC | ⚠ đáng lẽ phải làm được bao nhiêu | | ⚠ EV | ⚠ % thực tế × BAC | ⚠ thực sự làm được bao nhiêu | | ⚠ AC | ⚠ chi phí thực tế | | | ⚠ CV | ⚠ EV − AC | ⚠ âm = vượt chi | | ⚠ SV | ⚠ EV − PV | ⚠ âm = chậm tiến độ | | ⚠ CPI | ⚠ EV ÷ AC | ⚠ dưới 1 = vượt chi | | ⚠ SPI | ⚠ EV ÷ PV | ⚠ dưới 1 = chậm |

Từ khoá nhận diện:

"variance" → ⚠ phép TRỪ, kết quả có ĐƠN VỊ TIỀN "index" → ⚠ phép CHIA, kết quả là TỶ SỐ không đơn vị "âm" → ⚠ xấu, dù là CV hay SV "dưới 1" → ⚠ xấu, dù là CPI hay SPI

⚠ Mẹo nhớ Mẹo
⚠ EV luôn đứng TRƯỚC trong mọi công thức
⚠ Trừ AC → chi phí; trừ PV → tiến độ
⚠ Chia thay vì trừ → ra chỉ số

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính EV trước chưa | ⚠ mọi công thức đều bắt đầu từ EV | | Đề hỏi variance hay index | ⚠ trừ hay chia | | Kết quả âm hay dương có hợp lý không | |

Và bước đầu tiên của mọi bài toán Earned Value: tính EV. Từ EV, mọi chỉ số khác chỉ là một phép trừ hoặc một phép chia — sai EV thì cả bài sai theo.

Câu 2
Gary is a project team member and he’s gathered requirements for your project. Currently, Gary is following a stakeholder and observing the work the stakeholder does to get a clear understanding of the needs and to better define the problems that your project aims to solve. Gary is observing the stakeholder and is not interrupting the work. What type of requirements gathering is Gary doing in this scenario?
  1. A Elicitation
  2. B Passive observation
  3. C Peer review
  4. D Cross training
Xem giải thích

Đáp án

B — Passive observation (quan sát thụ động).

Vì sao đúng

⚠ Observation, còn gọi là "job shadowing", có hai kiểu: | Kiểu | Nội dung | |---|---| | ⚠ Passive — thụ động | ⚠ chỉ QUAN SÁT, KHÔNG can thiệp hay hỏi | | ⚠ Active — chủ động, participant observer | ⚠ người quan sát THAM GIA làm cùng để hiểu sâu hơn |

⚠ Đề nói rõ "không làm gián đoạn công việc" → ⚠ đó là passive observation.

⚠ Vì sao quan sát hữu ích khi thu thập yêu cầu: | Lý do | Nội dung | |---|---| | ⚠ Người ta làm khác với những gì họ MÔ TẢ | | | ⚠ Phát hiện nhu cầu ngầm mà bên liên quan không nói ra | | | ⚠ Thấy được các bước "ai cũng biết nên không ai nhắc" | | | ⚠ Đặc biệt hợp khi | ⚠ bên liên quan khó diễn đạt yêu cầu bằng lời |

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

  • A (Elicitation) — ⚠ là TÊN CHUNG của cả nhóm kỹ thuật thu thập yêu cầu; observation chỉ là một kỹ thuật trong đó, nên A quá rộng.

  • C (Peer review) — ⚠ rà soát chéo sản phẩm công việc, không phải thu thập yêu cầu.

  • D (Cross training) — ⚠ đào tạo chéo để người này làm được việc người kia.

Ghi nhớ

⚠ Các kỹ thuật thu thập yêu cầu trong PMBOK: | Kỹ thuật | Nội dung | |---|---| | ⚠ Brainstorming | ⚠ nghĩ ra ý tưởng theo nhóm | | ⚠ Interviews | ⚠ phỏng vấn từng người | | ⚠ Focus groups | ⚠ thảo luận nhóm có điều phối | | ⚠ Questionnaires and surveys | ⚠ cho số đông | | ⚠ Observation | ⚠ quan sát công việc thật | | ⚠ Prototypes | ⚠ mô hình thử để lấy phản hồi sớm | | ⚠ Benchmarking | ⚠ so với tổ chức khác | | ⚠ Document analysis | ⚠ đọc tài liệu hiện có |

Từ khoá nhận diện:

"quan sát, không can thiệp" → ⚠ passive observation "làm cùng để hiểu" → ⚠ participant observation "mô hình thử để lấy phản hồi" → ⚠ prototype "hỏi số đông" → ⚠ survey

⚠ Khi nào chọn observation Khi nào
⚠ Quy trình phức tạp, khó mô tả bằng lời
⚠ Nghi ngờ quy trình thực tế khác tài liệu
⚠ Bên liên quan bận, khó sắp lịch phỏng vấn dài
⚠ Hạn chế ⚠ tốn thời gian, và người bị quan sát có thể làm khác đi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu thu được có được bên liên quan xác nhận không | | | Quy trình quan sát được có đại diện không | ⚠ hay chỉ là một ca đặc biệt | | Đã kết hợp thêm kỹ thuật nào khác chưa | |

Và lý do quan sát thường cho kết quả khác hẳn phỏng vấn: người ta mô tả quy trình như nó NÊN LÀ, còn quan sát cho thấy nó ĐANG LÀ. Khoảng cách giữa hai điều đó thường chính là nơi vấn đề nằm.

Câu 3
You are a project manager for the NJIK Project and you’re working with your project team to define the communications management plan. As part of this planning, you want to define how you’ll communicate with a hierarchical focus of the organization. Which one of the following describes how you will communicate to the project team members in consideration of the hierarchical structure?
  1. A Vertical
  2. B Downward
  3. C Horizontal
  4. D Matrix
Xem giải thích

Đáp án

B — Downward (giao tiếp xuống dưới).

Vì sao đúng

⚠ Giao tiếp theo thứ bậc trong tổ chức có ba hướng: | Hướng | Nội dung | |---|---| | ⚠ Upward — lên trên | ⚠ báo cáo lên quản lý cấp cao, nhà tài trợ | | ⚠ Downward — xuống dưới | ⚠ quản lý dự án truyền đạt tới THÀNH VIÊN ĐỘI | | ⚠ Horizontal / lateral — ngang | ⚠ giữa các đồng nghiệp cùng cấp, giữa các đội |

⚠ Đề hỏi giao tiếp TỚI thành viên đội dự án → ⚠ đó là downward.

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

  • A (Vertical) — ⚠ là TÊN CHUNG cho cả hướng lên và hướng xuống; ⚠ đề hỏi cụ thể tới thành viên đội nên "downward" chính xác hơn.

  • C (Horizontal) — ⚠ giữa những người CÙNG CẤP.

  • D (Matrix) — ⚠ là một KIỂU CƠ CẤU tổ chức, không phải hướng giao tiếp.

Ghi nhớ

⚠ Bốn chiều giao tiếp trong quản lý dự án: | Chiều | Với ai | |---|---| | ⚠ Upward | ⚠ nhà tài trợ, quản lý cấp cao | | ⚠ Downward | ⚠ thành viên đội | | ⚠ Horizontal | ⚠ đồng nghiệp, quản lý dự án khác | | ⚠ Bên ngoài | ⚠ nhà cung cấp, khách hàng, cơ quan quản lý |

⚠ Công thức kênh giao tiếp — hay hỏi trong đề PMP: | Nội dung | Công thức | |---|---| | ⚠ Số kênh giao tiếp | ⚠ n × (n − 1) ÷ 2 | | ⚠ Với n = 10 người | ⚠ 45 kênh | | ⚠ Thêm một người thành 11 | ⚠ 55 kênh — tăng 10 | | ⚠ Bài học | ⚠ đội càng lớn, độ phức tạp giao tiếp tăng theo BÌNH PHƯƠNG |

Từ khoá nhận diện:

"tới thành viên đội" → ⚠ downward "báo cáo lên nhà tài trợ" → ⚠ upward "giữa các đội ngang hàng" → ⚠ horizontal "số kênh giao tiếp" → ⚠ n(n−1)/2

⚠ Ba kiểu phương pháp giao tiếp Kiểu
⚠ Interactive ⚠ hai chiều thời gian thực — họp, gọi điện
⚠ Push ⚠ gửi đi, không chắc người nhận đã đọc — email, báo cáo
⚠ Pull ⚠ người nhận tự lấy — wiki, kho tài liệu
⚠ Chọn theo ⚠ mức khẩn cấp và quy mô người nhận
⚠ Kế hoạch quản lý truyền thông nên trả lời Câu hỏi
⚠ AI cần thông tin gì
⚠ KHI NÀO và BAO LÂU một lần
⚠ Bằng ĐỊNH DẠNG nào
⚠ AI chịu trách nhiệm gửi
⚠ Thống kê thường được nhắc ⚠ quản lý dự án dành khoảng 90% thời gian cho giao tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kế hoạch truyền thông có nêu rõ ai nhận gì không | | | Thông tin lên nhà tài trợ có đúng mức chi tiết không | | | Đội có biết tìm thông tin ở đâu không | ⚠ kênh pull |

Và con số thường được nhắc trong mọi tài liệu PMP: quản lý dự án dành khoảng 90% thời gian cho giao tiếp. Đó là lý do kế hoạch truyền thông không phải thủ tục hình thức mà là công cụ làm việc hằng ngày.

Câu 4
You are the project manager of the JJ Project, and you and the project team are defining the project activities and sequencing for a project. The team has identified an activity, framing the building, which can’t begin until the concrete pad has adequately cured. The team is concerned that the concrete will take longer than usual due to the humid summer to cure so an extra two days may be needed before the framing can begin. What should you do next?
  1. A Schedule the concrete to dry on a Friday with two days of lead for the framing activity.
  2. B Schedule the framing to start after the concrete is poured, but with two days of lag.
  3. C Schedule the framing to start on a Monday and pour the concrete on a Friday.
  4. D Schedule the framing to start two days after the concrete is poured.
Xem giải thích

Đáp án

B — Lên lịch cho việc dựng khung bắt đầu SAU khi đổ bê tông, với hai ngày LAG.

Vì sao đúng

⚠ Lag và Lead — hai khái niệm ngược nhau: | Khái niệm | Nghĩa | |---|---| | ⚠ Lag — độ trễ | ⚠ CHỜ THÊM giữa hai hoạt động | | ⚠ Lead — độ sớm | ⚠ cho phép hoạt động sau BẮT ĐẦU SỚM hơn, chồng lấn với hoạt động trước |

⚠ Tình huống ở đây: ⚠ bê tông cần thêm thời gian để khô trước khi dựng khung → ⚠ đó là CHỜ, tức là lag.

⚠ Đổ bê tông  →  ⚠ [lag 2 ngày chờ khô]  →  ⚠ Dựng khung

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

  • A (hai ngày LEAD cho việc dựng khung) — ⚠ NGƯỢC hoàn toàn; lead sẽ khiến dựng khung bắt đầu SỚM hơn, tức là dựng khi bê tông chưa khô.

  • C (dựng khung thứ Hai, đổ bê tông thứ Sáu) — ⚠ giải bằng cách ấn định NGÀY CỤ THỂ, không phải cách mô hình hoá phụ thuộc; lịch dự án sẽ vỡ khi có thay đổi.

  • D (dựng khung hai ngày sau khi đổ bê tông) — ⚠ mô tả đúng KẾT QUẢ nhưng không dùng đúng CƠ CHẾ; trong phần mềm lập lịch, cách thể hiện chuẩn là khai lag.

Ghi nhớ

⚠ Bốn loại quan hệ phụ thuộc: | Loại | Nghĩa | |---|---| | ⚠ Finish-to-Start (FS) | ⚠ A xong thì B bắt đầu — phổ biến nhất | | ⚠ Start-to-Start (SS) | ⚠ A bắt đầu thì B bắt đầu | | ⚠ Finish-to-Finish (FF) | ⚠ A xong thì B xong | | ⚠ Start-to-Finish (SF) | ⚠ hiếm gặp nhất |

⚠ Bốn loại phụ thuộc theo nguồn gốc: | Loại | Nội dung | |---|---| | ⚠ Mandatory — bắt buộc | ⚠ hard logic, bản chất công việc — bê tông phải khô trước | | ⚠ Discretionary — tuỳ chọn | ⚠ soft logic, do đội quyết định theo kinh nghiệm | | ⚠ External — bên ngoài | ⚠ phụ thuộc bên thứ ba, giấy phép | | ⚠ Internal — bên trong | ⚠ giữa các hoạt động của chính dự án |

Từ khoá nhận diện:

"chờ thêm, đợi khô, đợi duyệt" → ⚠ LAG "bắt đầu sớm, chồng lấn" → ⚠ LEAD "bản chất công việc buộc phải thế" → ⚠ mandatory dependency "đội chọn làm thế cho tiện" → ⚠ discretionary dependency

⚠ Mẹo nhớ lag và lead Mẹo
⚠ Lag = LAG BEHIND = chậm lại, chờ
⚠ Lead = ĐI TRƯỚC = làm sớm, chồng lấn
⚠ Lead RÚT NGẮN lịch nhưng TĂNG rủi ro ⚠ làm khi việc trước chưa xong hẳn
⚠ Lag KÉO DÀI lịch nhưng phản ánh thực tế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phụ thuộc này là bắt buộc hay tuỳ chọn | ⚠ tuỳ chọn thì có thể rút ngắn được | | Lag có được ghi rõ lý do không | ⚠ để người sau hiểu vì sao có nó | | Có lead nào đang tạo rủi ro không | |

Và khác biệt thực tế giữa lag và lead khi nén lịch: bỏ lead làm lịch an toàn hơn, bỏ lag thường là bất khả thi. Lag mandatory đến từ vật lý hoặc quy định — không thương lượng được với bê tông.

Câu 5
You are a project manager for your company, a startup technology company. Your project needs to purchase 30 laptops from a vendor and management has authorized you to manage the entire procurement decision and transaction as there is no procurement officer in your company. In this scenario, what type of purchasing are you participating in?
  1. A Project purchasing
  2. B Decentralized purchasing
  3. C Vendor-based purchasing
  4. D Direct purchasing
Xem giải thích

Đáp án

B — Decentralized purchasing (mua sắm phi tập trung).

Vì sao đúng

⚠ Hai mô hình tổ chức việc mua sắm: | Mô hình | Nội dung | |---|---| | ⚠ Centralized purchasing | ⚠ có bộ phận mua sắm RIÊNG, phục vụ mọi dự án | | ⚠ Decentralized purchasing | ⚠ KHÔNG có bộ phận riêng; quản lý dự án TỰ lo toàn bộ |

⚠ Đề nói rõ: ⚠ công ty không có nhân viên mua sắm, và ⚠ quản lý dự án được uỷ quyền lo toàn bộ giao dịch → ⚠ đó là phi tập trung.

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

  • A (Project purchasing), C (Vendor-based purchasing), D (Direct purchasing) — ⚠ không phải thuật ngữ chuẩn trong phân loại mua sắm của PMBOK.

Ghi nhớ

⚠ So sánh hai mô hình: | Tiêu chí | Centralized | Decentralized | |---|---|---| | ⚠ Chuyên môn mua sắm | ⚠ CAO — có người chuyên trách | ⚠ thấp hơn | | ⚠ Tốc độ | ⚠ chậm hơn, qua nhiều bước | ⚠ NHANH hơn | | ⚠ Sức mạnh đàm phán | ⚠ CAO — gộp nhu cầu nhiều dự án | ⚠ thấp | | ⚠ Chuẩn hoá quy trình | ⚠ cao | ⚠ thấp, mỗi dự án một kiểu | | ⚠ Trách nhiệm của PM | ⚠ ít | ⚠ NHIỀU — phải hiểu cả hợp đồng | | ⚠ Phù hợp với | ⚠ tổ chức lớn | ⚠ công ty khởi nghiệp, tổ chức nhỏ |

Từ khoá nhận diện:

"không có bộ phận mua sắm, PM tự lo" → ⚠ decentralized "có phòng mua sắm riêng" → ⚠ centralized "hợp đồng giá cố định" → ⚠ fixed price contract "trả chi phí cộng phí" → ⚠ cost-reimbursable

⚠ Ba loại hợp đồng chính Loại
⚠ Fixed Price ⚠ giá cố định — rủi ro thuộc về NHÀ CUNG CẤP
⚠ Cost-Reimbursable ⚠ hoàn chi phí cộng phí — rủi ro thuộc về NGƯỜI MUA
⚠ Time and Materials ⚠ lai giữa hai loại, hợp cho công việc chưa rõ phạm vi
⚠ Rủi ro của mô hình phi tập trung Rủi ro
⚠ PM có thể thiếu kiến thức hợp đồng
⚠ Mua trùng lặp giữa các dự án
⚠ Mất lợi thế đàm phán do mua lẻ
⚠ Khó kiểm soát tuân thủ và đạo đức mua sắm
⚠ Giảm thiểu bằng ⚠ mẫu hợp đồng chuẩn, quy trình duyệt, tư vấn pháp lý khi cần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | PM có đủ thẩm quyền ký kết không | ⚠ kiểm tra hạn mức được uỷ quyền | | Có mẫu hợp đồng chuẩn để dùng không | | | Có ai rà soát điều khoản pháp lý không | |

Và rủi ro lớn nhất khi quản lý dự án tự lo mua sắm: ký một điều khoản mà mình không hiểu hết hệ quả. Tốc độ là ưu điểm của mô hình phi tập trung, nhưng nó không nên đánh đổi bằng việc bỏ qua rà soát pháp lý.

Câu 6
You are working with your project team and management to create the resource management plan for a new project. This project will span several lines of business in your organization and will be a high-profile project. Management has asked that you create a chart to document and illustrate the existing departments and teams with project activities listed under each department to help each department see their responsibilities in the project. What type of chart is management asking you to create?
  1. A Work breakdown structure
  2. B Resource breakdown structure
  3. C Activity list
  4. D Organizational breakdown structure
Xem giải thích

Đáp án

D — Organizational Breakdown Structure (OBS).

Vì sao đúng

⚠ Ba loại "breakdown structure" hay bị lẫn: | Cấu trúc | Phân rã theo | |---|---| | ⚠ WBS — Work Breakdown Structure | ⚠ SẢN PHẨM BÀN GIAO và công việc | | ⚠ OBS — Organizational Breakdown Structure | ⚠ PHÒNG BAN và đơn vị tổ chức, kèm hoạt động dưới mỗi phòng | | ⚠ RBS — Resource Breakdown Structure | ⚠ LOẠI TÀI NGUYÊN — nhân lực, thiết bị, vật tư |

⚠ Đề mô tả rõ: ⚠ biểu đồ thể hiện các phòng ban hiện có, với hoạt động dự án liệt kê dưới mỗi phòng → ⚠ đó chính là OBS.

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

  • B (Resource Breakdown Structure) — ⚠ phân rã theo LOẠI tài nguyên, không theo cơ cấu phòng ban.

  • A (Work Breakdown Structure) — ⚠ phân rã theo sản phẩm bàn giao, không gắn với phòng ban.

  • C (Activity list) — ⚠ danh sách phẳng các hoạt động, không có cấu trúc phân cấp theo tổ chức.

Ghi nhớ

⚠ Ba cách thể hiện vai trò và trách nhiệm: | Dạng | Nội dung | |---|---| | ⚠ Hierarchical — phân cấp | ⚠ WBS, OBS, RBS | | ⚠ Matrix | ⚠ RACI chart — giao điểm giữa người và hoạt động | | ⚠ Text-oriented | ⚠ mô tả vai trò bằng văn bản chi tiết |

Từ khoá nhận diện:

"theo phòng ban" → ⚠ OBS "theo loại tài nguyên" → ⚠ RBS "theo sản phẩm bàn giao" → ⚠ WBS "ai làm gì trên từng hoạt động" → ⚠ RACI matrix

⚠ WBS — vài quy tắc hay hỏi Quy tắc
⚠ Quy tắc 100% ⚠ WBS phải bao gồm TOÀN BỘ phạm vi, không thừa không thiếu
⚠ Work package ⚠ mức thấp nhất của WBS, nơi ước lượng và kiểm soát
⚠ WBS dictionary ⚠ mô tả chi tiết từng phần tử
⚠ WBS mô tả SẢN PHẨM, không mô tả hoạt động ⚠ hoạt động nằm ở activity list
⚠ Vì sao OBS hữu ích Lý do
⚠ Mỗi phòng thấy rõ phần việc của mình
⚠ Dễ phân bổ ngân sách theo phòng
⚠ Hỗ trợ dự án liên phòng ban, nhiều bên tham gia
⚠ Kết hợp WBS và OBS ⚠ ra được ma trận trách nhiệm chi tiết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi work package có chủ sở hữu rõ ràng không | | | Có phòng ban nào bị bỏ sót trong OBS không | | | WBS có phủ 100% phạm vi không | |

Và mẹo phân biệt ba cấu trúc phân rã, ứng với ba câu hỏi khác nhau: WBS hỏi "làm ra CÁI GÌ", OBS hỏi "AI làm", RBS hỏi "cần THỨ GÌ".

Câu 7
Mike is the project manager of the AQA Project for his company. His BAC is $2,345,000, and he is currently 25 percent complete with the project, though he is supposed to be 30 percent complete. In the project so far, Mike has spent $612,000. Management has asked Mike to report on his cost and schedule performance. What is the EAC for AQA Project?
  1. A $2,448,000
  2. B $3,229,087
  3. C $3,221,091
  4. D $2,345,000
Xem giải thích

Đáp án

A — 2.448.000 đô la.

Vì sao đúng

⚠ Tính từng bước: | Bước | Phép tính | |---|---| | ⚠ BAC | ⚠ 2.345.000 | | ⚠ EV = 25% × BAC | ⚠ 586.250 | | ⚠ AC | ⚠ 612.000 | | ⚠ CPI = EV ÷ AC | ⚠ 586.250 ÷ 612.000 ≈ 0,9579 | | ⚠ EAC = BAC ÷ CPI | ⚠ 2.345.000 ÷ 0,9579 ≈ 2.448.000 |

⚠ Đây là công thức EAC phổ biến nhất, dùng khi giả định xu hướng chi phí hiện tại sẽ tiếp diễn.

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

  • D (2.345.000) — ⚠ đó chính là BAC; ⚠ chỉ đúng nếu phần còn lại chạy đúng ngân sách, tức là dùng công thức EAC = AC + (BAC − EV) — không phải giả định của đề.

  • B (3.229.087) và C (3.221.091) — ⚠ quá lớn; ⚠ ứng với công thức có nhân thêm SPI, dùng khi cả chi phí lẫn tiến độ đều ảnh hưởng tới dự báo.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25532 trong lô này dùng CÙNG một kịch bản — Mike, dự án AQA, BAC 2.345.000, tiến độ 25%/30%, đã chi 612.000. ⚠ Hai câu hỏi hai chỉ số khác nhau từ cùng bộ số liệu.

⚠ Bộ số liệu chung của hai câu: | Chỉ số | Giá trị | |---|---| | ⚠ BAC | ⚠ 2.345.000 | | ⚠ EV | ⚠ 586.250 | | ⚠ PV | ⚠ 703.500 | | ⚠ AC | ⚠ 612.000 | | ⚠ CV | ⚠ −25.750 | | ⚠ SV | ⚠ −117.250 | | ⚠ CPI | ⚠ ≈ 0,96 | | ⚠ SPI | ⚠ ≈ 0,83 | | ⚠ EAC | ⚠ ≈ 2.448.000 |

⚠ Bốn công thức EAC — chọn theo giả định: | Giả định | Công thức | |---|---| | ⚠ Xu hướng chi phí tiếp diễn | ⚠ EAC = BAC ÷ CPI | | ⚠ Sai lệch chỉ là bất thường một lần | ⚠ EAC = AC + (BAC − EV) | | ⚠ Cả chi phí lẫn tiến độ ảnh hưởng | ⚠ EAC = AC + [(BAC − EV) ÷ (CPI × SPI)] | | ⚠ Ước lượng lại phần còn lại | ⚠ EAC = AC + ETC mới |

Từ khoá nhận diện:

"dự báo tổng chi phí cuối cùng" → ⚠ EAC "còn phải chi bao nhiêu nữa" → ⚠ ETC = EAC − AC "chênh lệch dự báo so với ngân sách" → ⚠ VAC = BAC − EAC "hiệu suất cần đạt để về đúng ngân sách" → ⚠ TCPI

⚠ Đọc kết quả này thế nào Ý nghĩa
⚠ EAC 2.448.000 > BAC 2.345.000 ⚠ dự báo VƯỢT ngân sách khoảng 103.000
⚠ VAC = BAC − EAC ≈ −103.000 ⚠ âm là xấu
⚠ CPI 0,96 dưới 1 ⚠ mỗi đồng chi ra chỉ tạo ra 0,96 đồng giá trị
⚠ SPI 0,83 dưới 1 ⚠ chậm tiến độ rõ rệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính EV trước chưa | ⚠ mọi công thức bắt đầu từ đó | | Đề giả định xu hướng có tiếp diễn không | ⚠ quyết định chọn công thức EAC nào | | Kết quả có hợp lý so với BAC không | |

Và câu hỏi quyết định khi chọn công thức EAC: sai lệch đang thấy là XU HƯỚNG hay là BẤT THƯỜNG MỘT LẦN? Nếu là xu hướng thì chia cho CPI; nếu chỉ là sự cố đã qua thì cộng thẳng phần việc còn lại theo ngân sách.

Câu 8
Juan is the project manager of the NQA Project, and he has created a RACI chart for this project team to show the roles and responsibilities of several activities. Steph, a project team member, isn’t familiar with this type of chart and needs clarity on what a RACI chart means. What does RACI mean for Stephanie?
  1. A Risk, Account, Contractor, Integration
  2. B Responsible, Actionable, Consult, Inform
  3. C Risk, Action, Communicate, Information
  4. D Responsible, Accountable, Consult, Inform
Xem giải thích

Đáp án

D — Responsible, Accountable, Consult, Inform.

Vì sao đúng

⚠ Bốn vai trò trong ma trận RACI: | Chữ | Vai trò | Nghĩa | |---|---|---| | ⚠ R — Responsible | ⚠ người LÀM | ⚠ thực hiện công việc; có thể nhiều người | | ⚠ A — Accountable | ⚠ người CHỊU TRÁCH NHIỆM | ⚠ phê duyệt và chịu trách nhiệm cuối cùng; CHỈ MỘT người | | ⚠ C — Consult | ⚠ người được HỎI Ý KIẾN | ⚠ giao tiếp HAI chiều, trước khi làm | | ⚠ I — Inform | ⚠ người được THÔNG BÁO | ⚠ giao tiếp MỘT chiều, sau khi làm |

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

  • B (Responsible, Actionable, Consult, Inform) — ⚠ chữ A là ACCOUNTABLE, không phải "Actionable"; đây là bẫy phổ biến nhất.

  • A và C — ⚠ hoàn toàn bịa.

Ghi nhớ

⚠ Quy tắc vàng của RACI: | Quy tắc | Nội dung | |---|---| | ⚠ Mỗi hoạt động có ĐÚNG MỘT chữ A | ⚠ nhiều A nghĩa là không ai thật sự chịu trách nhiệm | | ⚠ Có ít nhất một chữ R | ⚠ không có R thì không ai làm | | ⚠ Một người có thể vừa A vừa R | | | ⚠ Hạn chế số C | ⚠ quá nhiều người phải hỏi ý kiến làm chậm mọi quyết định |

⚠ Phân biệt hai chữ dễ nhầm nhất: | Chữ | Câu hỏi | |---|---| | ⚠ R — Responsible | ⚠ AI LÀM việc này | | ⚠ A — Accountable | ⚠ AI trả lời khi việc này hỏng |

Từ khoá nhận diện:

"ma trận vai trò và trách nhiệm" → ⚠ RACI, một dạng RAM "phân rã theo phòng ban" → ⚠ OBS "phân rã theo sản phẩm" → ⚠ WBS "chỉ một người chịu trách nhiệm cuối" → ⚠ chữ A

⚠ Các biến thể của RACI Biến thể
⚠ RASCI ⚠ thêm S — Support, người hỗ trợ thực hiện
⚠ RACI-VS ⚠ thêm V — Verify và S — Sign-off
⚠ DACI ⚠ Driver, Approver, Contributor, Informed
⚠ Đề PMP ⚠ chủ yếu hỏi RACI chuẩn
⚠ Vì sao RACI hữu ích Lý do
⚠ Loại bỏ tình trạng "tưởng người kia làm"
⚠ Làm rõ ai được quyết định
⚠ Giảm số cuộc họp không cần thiết ⚠ chữ I không cần dự họp
⚠ Dấu hiệu RACI có vấn đề ⚠ một hàng toàn chữ C, hoặc một cột toàn chữ A

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi hàng có đúng một chữ A không | | | Có hoạt động nào không có chữ R không | | | Có ai đang là A cho quá nhiều việc không | ⚠ dấu hiệu nút thắt cổ chai |

Và giá trị thật của RACI không nằm ở cái bảng, mà ở cuộc trao đổi lúc lập nó. Chính lúc tranh luận xem ai là A cho một hoạt động thì những hiểu nhầm về trách nhiệm mới lộ ra.

Câu 9
Beth is the project manager for her organization, and she’s meeting her project sponsor to discuss the competency level of the project team. Bill, the project sponsor, is worried that some of the project team members are new to the skills required in the project and he wants to know Beth’s strategy for these team members. What should Beth do next?
  1. A Some team members will require more oversight than others.
  2. B All team members will be managed with the same level of oversight.
  3. C Some team members will likely be released from the project.
  4. D All team members will be trained on the skills needed to ensure equal understanding.
Xem giải thích

Đáp án

A — Một số thành viên sẽ cần mức giám sát nhiều hơn những người khác.

Vì sao đúng

⚠ Nguyên tắc quản lý theo tình huống — situational leadership: | Mức năng lực của thành viên | Cách quản lý | |---|---| | ⚠ Mới, chưa có kỹ năng | ⚠ hướng dẫn chi tiết, giám sát sát sao | | ⚠ Đang học, có động lực | ⚠ kèm cặp, huấn luyện | | ⚠ Có năng lực nhưng thiếu tự tin | ⚠ hỗ trợ, khuyến khích | | ⚠ Thành thạo và tự chủ | ⚠ uỷ quyền, ít can thiệp |

⚠ Đội dự án luôn có người ở các mức khác nhau → ⚠ mức giám sát phải khác nhau.

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

  • B (quản lý MỌI người ở cùng một mức giám sát) — ⚠ không hiệu quả ở cả hai đầu: ⚠ người mới thiếu hỗ trợ, người giỏi bị quản lý vi mô và mất động lực.

  • D (đào tạo TẤT CẢ để ai cũng hiểu ngang nhau) — ⚠ lãng phí thời gian và ngân sách; ⚠ đào tạo nên nhắm vào người thật sự cần.

  • C (loại một số thành viên khỏi dự án) — ⚠ phản ứng cực đoan, và mâu thuẫn với vai trò phát triển đội của quản lý dự án.

Ghi nhớ

⚠ Năm giai đoạn phát triển đội — mô hình Tuckman: | Giai đoạn | Đặc điểm | |---|---| | ⚠ Forming | ⚠ mới gặp, lịch sự, chưa hiểu vai trò | | ⚠ Storming | ⚠ xung đột, tranh luận về cách làm | | ⚠ Norming | ⚠ hình thành quy tắc chung | | ⚠ Performing | ⚠ làm việc hiệu quả, tự chủ | | ⚠ Adjourning | ⚠ giải tán khi dự án kết thúc |

Từ khoá nhận diện:

"mức giám sát khác nhau theo năng lực" → ⚠ situational leadership "đội trải qua các giai đoạn" → ⚠ mô hình Tuckman "phát triển kỹ năng đội" → ⚠ Develop Team "giải quyết vấn đề của thành viên" → ⚠ Manage Team

⚠ Công cụ phát triển đội Công cụ
⚠ Đào tạo ⚠ cho khoảng trống kỹ năng cụ thể
⚠ Kèm cặp và mentoring
⚠ Hoạt động gắn kết đội ⚠ team building
⚠ Ghi nhận và khen thưởng
⚠ Đồng địa điểm hoặc phòng ảo chung
⚠ Quy tắc nền tảng ⚠ ground rules
⚠ Vì sao quản lý vi mô có hại Lý do
⚠ Người giỏi mất động lực và tự chủ
⚠ Quản lý dự án hết thời gian cho việc quan trọng
⚠ Đội không tự phát triển năng lực
⚠ Nhưng buông hoàn toàn với người mới ⚠ cũng dẫn tới sai sót và mất tự tin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã đánh giá năng lực từng thành viên chưa | | | Người mới có được kèm cặp không | | | Người giỏi có bị quản lý quá chặt không | |

Và sai lầm phổ biến của quản lý dự án lần đầu: áp một mức giám sát cho tất cả. Cách làm đó vừa bỏ rơi người mới vừa làm phiền người giỏi — mà cả hai đều dẫn tới cùng một kết quả là hiệu suất kém.

Câu 10
As a project manager, you are familiar with the quality and how quality affects the acceptability of the product scope. For example, what is the difference between attribute sample and variable sampling?
  1. A Attribute sampling means you measure the product scope defined attributes for acceptability as part of quality control. Variable sampling implies the customer is testing the product scope acceptability as part of scope validation.
  2. B Attribute sampling and variable sampling both test the product scope for quality, but attribute sampling tests only the defined functional requirements, while variable sampling tests all variables of functional and non-functional requirements.
  3. C Attribute sampling means you’re testing a portion of the product scope attributes. Variable sampling means you’re examining several variables of the product scope attributes.
  4. D Attribute sampling means the result either conforms or does not conform. Variable sampling implies the result is rated on a continuous scale that measures the degree of conformity.
Xem giải thích

Đáp án

D — Attribute sampling nghĩa là kết quả hoặc ĐẠT hoặc KHÔNG ĐẠT. Variable sampling nghĩa là kết quả được đánh giá trên một thang ĐO LIÊN TỤC thể hiện mức độ phù hợp.

Vì sao đúng

⚠ Hai kiểu lấy mẫu trong kiểm soát chất lượng: | Kiểu | Kết quả | Ví dụ | |---|---|---| | ⚠ Attribute sampling | ⚠ NHỊ PHÂN — đạt hoặc không đạt | ⚠ bóng đèn có sáng không | | ⚠ Variable sampling | ⚠ THANG LIÊN TỤC — đo được mức độ | ⚠ đường kính ống là 10,02 mm |

⚠ Khác biệt cốt lõi: ⚠ attribute cho câu trả lời CÓ hoặc KHÔNG; ⚠ variable cho một CON SỐ và ta xét nó nằm trong dung sai tới đâu.

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

  • C (attribute là kiểm một PHẦN thuộc tính, variable là kiểm nhiều biến) — ⚠ hiểu nhầm "sampling" thành "lấy một phần"; cả hai kiểu đều là lấy mẫu.

  • A (variable sampling là khách hàng kiểm tra khi nghiệm thu phạm vi) — ⚠ nhầm sang Validate Scope, một quy trình khác.

  • B (attribute chỉ kiểm yêu cầu chức năng, variable kiểm cả phi chức năng) — ⚠ không phải cách phân biệt hai kiểu lấy mẫu.

Ghi nhớ

⚠ Vài khái niệm chất lượng hay hỏi cùng nhau: | Cặp | Phân biệt | |---|---| | ⚠ Quality vs Grade | ⚠ chất lượng là mức đáp ứng yêu cầu; cấp độ là mức tính năng — cấp thấp mà chất lượng cao thì CHẤP NHẬN được | | ⚠ Precision vs Accuracy | ⚠ chụm là các lần đo GẦN NHAU; chính xác là gần GIÁ TRỊ THẬT | | ⚠ Prevention vs Inspection | ⚠ ngăn lỗi xảy ra, so với tìm lỗi sau khi xảy ra | | ⚠ Tolerance vs Control limit | ⚠ dung sai là khoảng CHẤP NHẬN được; giới hạn kiểm soát là khoảng ỔN ĐỊNH của quy trình |

Từ khoá nhận diện:

"đạt hoặc không đạt" → ⚠ attribute sampling "đo được, có thang liên tục" → ⚠ variable sampling "khách hàng nghiệm thu" → ⚠ Validate Scope "kiểm tra sản phẩm đúng yêu cầu" → ⚠ Control Quality

⚠ Quality Assurance và Quality Control Phân biệt
⚠ QA — Manage Quality ⚠ cải thiện QUY TRÌNH, phòng ngừa lỗi
⚠ QC — Control Quality ⚠ kiểm tra SẢN PHẨM, phát hiện lỗi
⚠ Đầu ra của QC ⚠ verified deliverables — đầu vào cho Validate Scope
⚠ Nguyên tắc chi phí chất lượng Nguyên tắc
⚠ Phòng ngừa RẺ hơn kiểm tra
⚠ Kiểm tra rẻ hơn sửa lỗi sau khi giao
⚠ Cost of conformance ⚠ đào tạo, kiểm thử, phòng ngừa
⚠ Cost of non-conformance ⚠ làm lại, bảo hành, mất uy tín

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiêu chí nghiệm thu là nhị phân hay có thang đo | ⚠ quyết định kiểu lấy mẫu | | Dung sai đã được thống nhất bằng văn bản chưa | | | Chi phí phòng ngừa có được đầu tư đủ không | |

Và nguyên tắc kinh tế nền tảng của quản lý chất lượng: một đồng bỏ vào phòng ngừa tiết kiệm nhiều đồng ở khâu sửa lỗi. Kiểm tra chỉ tìm ra lỗi đã có; chỉ phòng ngừa mới ngăn được nó xảy ra.