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

Tìm thấy 201 câu.

Câu 11
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 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. Which one of the following is an accurate statement about the AQA Project?
  1. A There is a CPI of .96 and an SPI of .89.
  2. B There is a cost variance of -$25,750 and a schedule variance of -$117,250.
  3. C There is a cost variance of five percent and a schedule variance of ten percent.
  4. D The project’s time to complete with be 110 percent and the cost of the project will be an additional five percent.
Xem giải thích

Đáp án

B — Cost variance là −25.750 đô la và schedule variance là −117.250 đô la.

Vì sao đúng

⚠ Tính từ cùng bộ số liệu: | Chỉ số | Phép tính | Kết quả | |---|---|---| | ⚠ BAC | | ⚠ 2.345.000 | | ⚠ EV = 25% × BAC | ⚠ 0,25 × 2.345.000 | ⚠ 586.250 | | ⚠ PV = 30% × BAC | ⚠ 0,30 × 2.345.000 | ⚠ 703.500 | | ⚠ AC | | ⚠ 612.000 | | ⚠ CV = EV − AC | ⚠ 586.250 − 612.000 | ⚠ −25.750 | | ⚠ SV = EV − PV | ⚠ 586.250 − 703.500 | ⚠ −117.250 |

⚠ Cả hai đều ÂM → ⚠ dự án vừa vượt chi vừa chậm tiến độ.

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

  • A (CPI 0,96 và SPI 0,89) — ⚠ CPI đúng là ≈ 0,96, nhưng ⚠ SPI = 586.250 ÷ 703.500 ≈ 0,83, không phải 0,89.

  • C (chênh lệch chi phí 5% và tiến độ 10%) — ⚠ variance có ĐƠN VỊ TIỀN, không phải phần trăm; đó là cách diễn đạt sai khái niệm.

  • D (thời gian hoàn thành 110% và chi phí thêm 5%) — ⚠ không khớp phép tính nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25528 trong lô này dùng CÙNG kịch bản — Mike, dự án AQA, cùng mọi con số — nhưng hỏi về EAC. ⚠ Hai câu bổ sung nhau, không mâu thuẫn.

Câu Hỏi gì Khoá
⚠ #25528 ⚠ EAC là bao nhiêu ⚠ A — 2.448.000
⚠ #25532 (câu này) ⚠ phát biểu nào đúng về dự án ⚠ B — CV −25.750, SV −117.250
⚠ Cùng bộ số liệu ⚠ cùng EV, PV, AC

⚠ Bảng tổng hợp cho dự án AQA: | Chỉ số | Giá trị | Đọc là | |---|---|---| | ⚠ CV | ⚠ −25.750 | ⚠ vượt chi | | ⚠ SV | ⚠ −117.250 | ⚠ chậm tiến độ | | ⚠ CPI | ⚠ ≈ 0,96 | ⚠ dưới 1 là xấu | | ⚠ SPI | ⚠ ≈ 0,83 | ⚠ chậm rõ rệt | | ⚠ EAC | ⚠ ≈ 2.448.000 | ⚠ dự báo vượt ngân sách | | ⚠ VAC = BAC − EAC | ⚠ ≈ −103.000 | ⚠ âm là vượt |

Từ khoá nhận diện:

"variance" → ⚠ phép TRỪ, đơn vị TIỀN "index" → ⚠ phép CHIA, tỷ số không đơn vị "âm hoặc dưới 1" → ⚠ xấu, ở cả bốn chỉ số "dự báo tổng chi phí" → ⚠ EAC

⚠ Mẹo làm nhanh dạng bài này Mẹo
⚠ Luôn tính EV, PV, AC trước ⚠ ba con số này giải được mọi câu hỏi
⚠ Trừ AC → chi phí; trừ PV → tiến độ
⚠ Kiểm tra dấu có hợp logic không ⚠ làm ít hơn kế hoạch thì SV phải âm
⚠ Loại nhanh phương án sai đơn vị ⚠ variance mà ghi phần trăm là sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính EV chưa | | | Dấu của CV và SV có hợp logic không | | | Phương án có đúng đơn vị không | ⚠ tiền hay tỷ số |

Và mẹo loại phương án nhanh nhất trong các bài Earned Value: kiểm tra ĐƠN VỊ trước khi tính. Variance luôn là tiền, index luôn là tỷ số — một phương án ghi "chênh lệch chi phí 5%" đã tự loại mình mà không cần tính gì.

Câu 12
Consider a project manager that has identified a risk in her project. The risk has a 20 percent chance of happening but will cost the project $450,000 if it happens. What’s the expected monetary value of this risk in a project?
  1. A $450,000
  2. B 0.9
  3. C ($90,000)
  4. D $90,000
Xem giải thích

Đáp án

C — (90.000 đô la), tức là ÂM 90.000.

Vì sao đúng

⚠ Expected Monetary Value — giá trị tiền tệ kỳ vọng: | Bước | Phép tính | |---|---| | ⚠ Xác suất | ⚠ 20% = 0,20 | | ⚠ Tác động | ⚠ 450.000 | | ⚠ EMV = xác suất × tác động | ⚠ 0,20 × 450.000 = 90.000 | | ⚠ Đây là rủi ro TIÊU CỰC | ⚠ nên EMV mang dấu ÂM: −90.000 |

⚠ Dấu ngoặc đơn trong tài chính — (90.000) — ⚠ chính là cách ghi số âm.

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

  • D (90.000 dương) — ⚠ đúng độ lớn nhưng SAI DẤU; ⚠ EMV dương nghĩa là cơ hội, không phải mối đe doạ.

  • A (450.000) — ⚠ là TÁC ĐỘNG nếu rủi ro xảy ra, chưa nhân xác suất.

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

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25522 ở lô trước cũng là bài toán có dấu — cost variance −11.500 — nhưng ⚠ phương án ở đó ghi 11500 KHÔNG có dấu âm. ⚠ Câu này thì phân biệt rõ hai phương án chỉ khác nhau ở dấu.

Câu Cách ghi dấu Nhận xét
⚠ #25522 ⚠ 11500 không dấu ⚠ thiếu thông tin về dấu
⚠ #25533 (câu này) ⚠ ($90,000) và $90,000 là HAI phương án riêng ⚠ buộc thí sinh phải hiểu dấu
⚠ Bài học ⚠ luôn xác định rủi ro là ĐE DOẠ hay CƠ HỘI trước khi ghi kết quả

⚠ EMV dùng để làm gì: | Ứng dụng | Nội dung | |---|---| | ⚠ Xếp hạng rủi ro | ⚠ so sánh rủi ro nào đáng xử lý trước | | ⚠ Tính dự phòng | ⚠ contingency reserve = tổng EMV của các rủi ro đã biết | | ⚠ Cây quyết định | ⚠ decision tree analysis — chọn phương án có EMV tốt nhất |

Từ khoá nhận diện:

"xác suất nhân tác động" → ⚠ EMV "rủi ro tiêu cực, threat" → ⚠ EMV ÂM "cơ hội, opportunity" → ⚠ EMV DƯƠNG "dự phòng cho rủi ro đã biết" → ⚠ contingency reserve

⚠ Hai loại dự trữ — hay bị lẫn Loại
⚠ Contingency reserve ⚠ cho rủi ro ĐÃ BIẾT — known unknowns; PM tự dùng
⚠ Management reserve ⚠ cho rủi ro CHƯA BIẾT — unknown unknowns; cần PHÊ DUYỆT mới dùng
⚠ Cost baseline ⚠ gồm contingency reserve
⚠ Budget ⚠ = cost baseline + management reserve
⚠ Bốn chiến lược ứng phó rủi ro tiêu cực Chiến lược
⚠ Avoid ⚠ né — loại bỏ nguyên nhân
⚠ Transfer ⚠ chuyển — bảo hiểm, hợp đồng
⚠ Mitigate ⚠ giảm nhẹ — hạ xác suất hoặc tác động
⚠ Accept ⚠ chấp nhận — chủ động có dự phòng, hoặc bị động
⚠ Với cơ hội ⚠ Exploit, Share, Enhance, Accept

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro này là đe doạ hay cơ hội | ⚠ quyết định dấu của EMV | | Dự phòng có đủ cho tổng EMV không | | | Ai được quyền dùng management reserve | |

Và điều dấu âm của EMV nói lên: đây là tiền dự kiến sẽ MẤT. Cộng dồn EMV của mọi rủi ro tiêu cực đã nhận diện chính là cơ sở để đề xuất mức dự phòng — chứ không phải một con số ước chừng.

Câu 13
Emily is the project manager of the GHY Project. She has hired several sellers to do a portion of the project work to test their competencies and to rate their work in the project. Based on their performance, she’ll choose one vendor to complete a larger portion of the project work. What is the primary advantage of this trial engagement approach?
  1. A Progress will be made on the project while testing the vendors’ performance.
  2. B Emily will save money on the project costs as the vendors will complete the smaller portions of the project work at no cost to the organization.
  3. C Multiple vendors will audition for the larger role on the project team.
  4. D The organization can test the vendor before buying more from the vendor.
Xem giải thích

Đáp án

A — Dự án vẫn TIẾN TRIỂN trong lúc thử năng lực của các nhà cung cấp.

Vì sao đúng

⚠ Đây là kỹ thuật "thuê thử" — trial engagement: | Lợi ích | Nội dung | |---|---| | ⚠ Công việc thật được hoàn thành | ⚠ không phải bài kiểm tra giả | | ⚠ Đánh giá dựa trên kết quả THẬT | ⚠ không chỉ dựa vào hồ sơ dự thầu | | ⚠ Giảm rủi ro cho phần việc lớn | ⚠ biết năng lực trước khi cam kết | | ⚠ Tạo cạnh tranh giữa các nhà cung cấp | |

⚠ Điểm mấu chốt: ⚠ đây không phải thời gian chết — ⚠ dự án vừa thử vừa tiến về phía trước.

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

  • B (tiết kiệm tiền vì nhà cung cấp làm miễn phí) — ⚠ SAI; ⚠ họ vẫn được TRẢ TIỀN cho phần việc đã làm.

  • D (tổ chức có thể thử trước khi mua thêm) — ⚠ ĐÚNG nhưng chỉ nêu lại chính mô tả của phương pháp, không nói được lợi ích thêm là tiến độ vẫn chạy.

  • C (nhiều nhà cung cấp thử vai cho phần việc lớn hơn) — ⚠ cũng chỉ mô tả lại cách làm.

Ghi nhớ

⚠ Vì sao đây là câu hỏi khó: | Vấn đề | Nội dung | |---|---| | ⚠ B, C, D đều "nghe hợp lý" | | | ⚠ Nhưng C và D chỉ MÔ TẢ LẠI phương pháp | ⚠ không phải LỢI ÍCH | | ⚠ Đề hỏi "lợi ích CHÍNH" | ⚠ cần một giá trị tăng thêm | | ⚠ Mẹo làm bài | ⚠ loại các phương án chỉ diễn đạt lại đề bài |

⚠ Các cách chọn nhà cung cấp trong PMBOK: | Cách | Nội dung | |---|---| | ⚠ Least cost | ⚠ giá thấp nhất — cho hàng hoá tiêu chuẩn | | ⚠ Qualifications only | ⚠ chỉ xét năng lực — cho hợp đồng nhỏ | | ⚠ Quality-based | ⚠ chọn theo chất lượng rồi mới đàm phán giá | | ⚠ Fixed budget | ⚠ ngân sách cố định, chọn phạm vi tốt nhất | | ⚠ Sole source | ⚠ chỉ một nhà cung cấp duy nhất khả dĩ | | ⚠ Single source | ⚠ chọn một dù có nhiều lựa chọn |

Từ khoá nhận diện:

"thuê thử phần nhỏ rồi mới giao phần lớn" → ⚠ trial engagement "chỉ có một nhà cung cấp trên thị trường" → ⚠ sole source "chọn sẵn một nhà cung cấp dù có nhiều" → ⚠ single source "tiêu chí chấm thầu" → ⚠ source selection criteria

⚠ Rủi ro của cách làm này Rủi ro
⚠ Tốn chi phí quản lý nhiều nhà cung cấp cùng lúc
⚠ Phần việc bị chia nhỏ, khó tích hợp
⚠ Nhà cung cấp có thể "diễn" trong giai đoạn thử
⚠ Mất thời gian hơn so với chọn thẳng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tiêu chí đánh giá đã rõ và công bố trước chưa | | | Phần việc thử có đại diện cho phần việc lớn không | | | Chi phí quản lý nhiều nhà cung cấp có đáng không | |

Và mẹo hữu ích cho dạng câu hỏi "lợi ích chính là gì": loại ngay những phương án chỉ diễn đạt lại chính đề bài. Chúng nghe rất đúng nhưng không trả lời được câu hỏi — vì lợi ích phải là thứ bạn THU ĐƯỢC, không phải thứ bạn LÀM.

Câu 14
You are a project manager for the HJG Project, and you’re working with your project team and several key stakeholders to identify the project requirements. As part of this activity, you need to reference a specific project management plan that will define how requirements will be planned, tracked, and reported. What project management plan should you reference?
  1. A Project management plan
  2. B Scope management plan
  3. C Requirements management plan
  4. D Communications management plan
Xem giải thích

Đáp án

C — Requirements management plan (kế hoạch quản lý yêu cầu).

Vì sao đúng

⚠ Requirements management plan mô tả cách LÀM VIỆC với yêu cầu: | Nội dung | Chi tiết | |---|---| | ⚠ Cách lập kế hoạch và thu thập yêu cầu | | | ⚠ Cách theo dõi và báo cáo | | | ⚠ Quy trình quản lý thay đổi yêu cầu | | | ⚠ Cấu trúc truy vết yêu cầu | ⚠ requirements traceability matrix | | ⚠ Ưu tiên yêu cầu thế nào | | | ⚠ Chỉ số dùng để đo | |

⚠ Đề nêu đúng ba việc: ⚠ lập kế hoạch, theo dõi, báo cáo yêu cầu.

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

  • B (Scope management plan) — ⚠ mô tả cách định nghĩa, xác nhận và kiểm soát PHẠM VI; ⚠ liên quan chặt nhưng không phải nơi quản lý yêu cầu.

  • A (Project management plan) — ⚠ là kế hoạch TỔNG, chứa mọi kế hoạch con; ⚠ quá rộng cho câu hỏi này.

  • D (Communications management plan) — ⚠ về việc ai nhận thông tin gì.

Ghi nhớ

⚠ Requirements management plan và Scope management plan — phân vai: | Kế hoạch | Trả lời câu hỏi | |---|---| | ⚠ Requirements management plan | ⚠ quản YÊU CẦU thế nào — thu thập, truy vết, đổi | | ⚠ Scope management plan | ⚠ quản PHẠM VI thế nào — định nghĩa, WBS, nghiệm thu, kiểm soát |

⚠ Requirements Traceability Matrix — công cụ đi kèm: | Truy vết từ yêu cầu tới | Nội dung | |---|---| | ⚠ Mục tiêu kinh doanh | ⚠ vì sao cần yêu cầu này | | ⚠ Phạm vi và WBS | | | ⚠ Thiết kế sản phẩm | | | ⚠ Kịch bản kiểm thử | | | ⚠ Giá trị | ⚠ không yêu cầu nào bị rơi, không việc nào thừa |

Từ khoá nhận diện:

"quản lý yêu cầu, truy vết" → ⚠ requirements management plan "định nghĩa và kiểm soát phạm vi" → ⚠ scope management plan "ai nhận thông tin gì" → ⚠ communications management plan "kế hoạch tổng" → ⚠ project management plan

⚠ Các kế hoạch con của project management plan Kế hoạch
⚠ Scope, Requirements, Schedule, Cost
⚠ Quality, Resource, Communications
⚠ Risk, Procurement, Stakeholder engagement
⚠ Cộng ba baseline ⚠ scope, schedule, cost baseline
⚠ Cộng các kế hoạch phụ trợ ⚠ change management, configuration management
⚠ Phân loại yêu cầu Loại
⚠ Business requirements ⚠ nhu cầu cấp tổ chức
⚠ Stakeholder requirements ⚠ nhu cầu của từng bên liên quan
⚠ Solution requirements ⚠ chức năng và phi chức năng
⚠ Transition requirements ⚠ để chuyển từ trạng thái cũ sang mới
⚠ Quality requirements

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ma trận truy vết yêu cầu không | | | Quy trình đổi yêu cầu đã rõ chưa | | | Ai có quyền phê duyệt thay đổi yêu cầu | |

Và giá trị lớn nhất của ma trận truy vết, ngoài việc quản lý: nó chặn phạm vi phình ra. Mỗi yêu cầu phải truy ngược được về một mục tiêu kinh doanh — thứ nào không truy được thì rất đáng đặt câu hỏi vì sao lại làm.

Câu 15
Ken is the project manager for his organization, and he’s working with his manager to discuss a new project. The project being considered is to implement a new hydroelectric dam in a community nearby. Some of the residents are not in favor of the dam, and other residents are excited about the dam. There are many government regulations, and environmental considerations before this dam can be installed. Based on this information, what is the most commonly used document to create the project charter if this project is approved?
  1. A Regulatory approval
  2. B Business case
  3. C Blueprints
  4. D Environmental reports
Xem giải thích

Đáp án

B — Business case (luận chứng kinh doanh).

Vì sao đúng

⚠ Business case là tài liệu nền tảng để lập project charter: | Nội dung của business case | Chi tiết | |---|---| | ⚠ Nhu cầu kinh doanh | ⚠ vì sao cần dự án này | | ⚠ Phân tích chi phí và lợi ích | | | ⚠ Các phương án đã cân nhắc | | | ⚠ Khuyến nghị và lý do chọn | | | ⚠ Tiêu chí thành công | |

⚠ Trong PMBOK, business case là đầu vào chính của quy trình Develop Project Charter — ⚠ cùng với benefits management plan, thoả thuận, và các yếu tố môi trường.

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

  • A (phê duyệt của cơ quan quản lý), C (bản vẽ thiết kế), D (báo cáo môi trường) — ⚠ đều là tài liệu QUAN TRỌNG cho dự án đập thuỷ điện này, nhưng ⚠ chúng là đầu vào kỹ thuật hoặc pháp lý, không phải tài liệu chuẩn để lập charter.

⚠ Bẫy của câu hỏi: ⚠ đề mô tả rất nhiều chi tiết về quy định và môi trường để kéo bạn chọn A hoặc D; ⚠ nhưng câu hỏi là về quy trình chuẩn, không về đặc thù ngành.

Ghi nhớ

⚠ Project charter — nội dung chính: | Mục | Nội dung | |---|---| | ⚠ Mục đích và lý do dự án | | | ⚠ Mục tiêu và tiêu chí thành công đo được | | | ⚠ Yêu cầu ở mức cao | | | ⚠ Mô tả dự án và ranh giới | | | ⚠ Rủi ro tổng thể | | | ⚠ Mốc lịch tóm tắt và ngân sách sơ bộ | | | ⚠ Danh sách bên liên quan | | | ⚠ Tiêu chí phê duyệt và kết thúc | | | ⚠ TÊN quản lý dự án và MỨC THẨM QUYỀN | | | ⚠ Người ký duyệt charter | |

⚠ Vì sao charter quan trọng: | Lý do | Nội dung | |---|---| | ⚠ CHÍNH THỨC khai sinh dự án | ⚠ không có charter thì dự án chưa tồn tại | | ⚠ TRAO QUYỀN cho quản lý dự án | ⚠ được dùng nguồn lực tổ chức | | ⚠ Do người NGOÀI dự án ký | ⚠ nhà tài trợ hoặc PMO, không phải PM tự ký |

Từ khoá nhận diện:

"tài liệu để lập charter" → ⚠ business case "khai sinh dự án, trao quyền cho PM" → ⚠ project charter "lợi ích sẽ được đo và duy trì thế nào" → ⚠ benefits management plan "hợp đồng với bên ngoài" → ⚠ agreement, cũng là đầu vào của charter

⚠ Phân biệt ba tài liệu đầu dự án Tài liệu
⚠ Business case ⚠ VÌ SAO nên làm dự án này
⚠ Project charter ⚠ CHO PHÉP làm, và trao quyền cho ai
⚠ Project management plan ⚠ LÀM thế nào
⚠ Bẫy thường gặp trong đề PMP Bẫy
⚠ Đề kể rất nhiều chi tiết ngành ⚠ để kéo bạn chọn phương án đặc thù
⚠ Câu hỏi thật lại về quy trình CHUẨN
⚠ Cách xử lý ⚠ đọc câu hỏi cuối cùng trước, rồi mới đọc lại tình huống

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Charter đã được người có thẩm quyền ký chưa | | | Charter có nêu rõ mức thẩm quyền của PM không | | | Business case có được cập nhật khi bối cảnh đổi không | |

Và mẹo làm bài quan trọng nhất với đề PMP dạng tình huống dài: đọc câu hỏi ở dòng cuối trước. Rất nhiều chi tiết trong tình huống được đưa vào chỉ để đánh lạc hướng, và biết trước mình đang tìm gì sẽ lọc chúng đi rất nhanh.

Câu 16
Joan is a project manager in her organization and she is working with the project team to create the risk management plan. Joan wants to create a structure to show the decomposition of project risks in a hierarchical approach for the potential sources of risks in the project. What type of chart should Joan create with her project team?
  1. A Risk decomposition map
  2. B Risk burnup chart
  3. C Risk breakdown structure
  4. D Risk burndown chart
Xem giải thích

Đáp án

C — Risk Breakdown Structure (RBS).

Vì sao đúng

⚠ RBS phân rã NGUỒN GỐC rủi ro theo cấu trúc phân cấp: | Cấp 1 | Cấp 2 ví dụ | |---|---| | ⚠ Kỹ thuật | ⚠ yêu cầu, công nghệ, giao diện, hiệu năng, chất lượng | | ⚠ Quản lý | ⚠ ước lượng, lập kế hoạch, kiểm soát, truyền thông | | ⚠ Thương mại | ⚠ nhà cung cấp, hợp đồng, đối tác | | ⚠ Bên ngoài | ⚠ pháp lý, thời tiết, thị trường, khách hàng |

⚠ Mục đích: ⚠ giúp đội nhận diện rủi ro có hệ thống, ⚠ thay vì nghĩ tới đâu ghi tới đó và bỏ sót cả một nhóm.

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

  • A (Risk decomposition map) — ⚠ không phải thuật ngữ chuẩn.

  • B (Risk burnup chart) và D (Risk burndown chart) — ⚠ là biểu đồ THEO DÕI số rủi ro theo thời gian, dùng trong môi trường linh hoạt; ⚠ chúng không phân rã nguồn gốc rủi ro.

Ghi nhớ

⚠ Ba cấu trúc phân rã hay bị lẫn — thêm RBS thành bốn: | Cấu trúc | Phân rã theo | |---|---| | ⚠ WBS | ⚠ sản phẩm bàn giao | | ⚠ OBS | ⚠ phòng ban | | ⚠ RBS — Resource Breakdown Structure | ⚠ loại tài nguyên | | ⚠ RBS — Risk Breakdown Structure | ⚠ nguồn gốc rủi ro |

⚠ Lưu ý: ⚠ hai cấu trúc cùng viết tắt là RBS — ⚠ phải đọc ngữ cảnh để biết là Resource hay Risk.

Từ khoá nhận diện:

"phân rã nguồn gốc rủi ro" → ⚠ Risk Breakdown Structure "phân rã loại tài nguyên" → ⚠ Resource Breakdown Structure "theo dõi số rủi ro theo thời gian" → ⚠ risk burndown chart "xác suất và tác động" → ⚠ probability and impact matrix

⚠ Bảy quy trình quản lý rủi ro của PMBOK Quy trình
⚠ Plan Risk Management ⚠ tạo ra risk management plan và RBS
⚠ Identify Risks ⚠ tạo ra risk register
⚠ Perform Qualitative Risk Analysis ⚠ xếp hạng bằng ma trận xác suất–tác động
⚠ Perform Quantitative Risk Analysis ⚠ EMV, mô phỏng Monte Carlo
⚠ Plan Risk Responses ⚠ avoid, transfer, mitigate, accept
⚠ Implement Risk Responses
⚠ Monitor Risks
⚠ Vì sao RBS hữu ích khi nhận diện rủi ro Lý do
⚠ Đội thường chỉ nghĩ tới rủi ro KỸ THUẬT
⚠ RBS nhắc kiểm cả nhóm quản lý, thương mại, bên ngoài
⚠ Dùng làm danh sách kiểm tra trong buổi brainstorm
⚠ Tái sử dụng được cho dự án sau ⚠ là tài sản quy trình của tổ chức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã rà đủ bốn nhóm nguồn rủi ro chưa | | | Rủi ro nhận diện được có phân bố đều không | ⚠ toàn kỹ thuật là dấu hiệu bỏ sót | | RBS có được cập nhật cho dự án sau không | |

Và dấu hiệu rõ nhất cho thấy một buổi nhận diện rủi ro đã bỏ sót: danh sách toàn rủi ro kỹ thuật. Trong thực tế, rủi ro làm hỏng dự án thường đến từ nhóm quản lý và bên ngoài — chính là những nhóm mà đội kỹ thuật ít nghĩ tới nhất.

Câu 17
Ned is the project manager of an IT upgrade project. He is working with the project team and the key project stakeholders to identify all of the project requirements. To keep the meeting moving along, Ned has created four classifications for requirements: hardware, software, network, and data. As requirements are identified, they are sorted into one of these four areas. What has Ned created in this meeting?
  1. A Nominal group technique
  2. B Brainwriting
  3. C Affinity diagram
  4. D Mind mapping
Xem giải thích

Đáp án

C — Affinity diagram (sơ đồ tương đồng).

Vì sao đúng

⚠ Affinity diagram nhóm các ý tưởng theo sự TƯƠNG ĐỒNG: | Bước | Nội dung | |---|---| | ⚠ Thu thập ý tưởng rời rạc | ⚠ yêu cầu, vấn đề, ý kiến | | ⚠ Nhóm chúng theo chủ đề | | | ⚠ Đặt tên cho từng nhóm | ⚠ ở đây là phần cứng, phần mềm, mạng, dữ liệu | | ⚠ Kết quả | ⚠ danh sách rời rạc trở nên có cấu trúc, dễ rà soát |

⚠ Đúng những gì Ned làm: ⚠ tạo bốn nhóm và phân loại yêu cầu vào đó khi chúng được nêu ra.

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

  • D (Mind mapping) — ⚠ vẽ SƠ ĐỒ TOẢ RA từ một ý tưởng trung tâm; ⚠ dùng để KHAI PHÁ ý tưởng, không phải để phân loại theo nhóm đã định trước.

  • A (Nominal group technique) — ⚠ brainstorm rồi BỎ PHIẾU XẾP HẠNG các ý tưởng.

  • B (Brainwriting) — ⚠ viết ý tưởng ra giấy trước khi thảo luận, để tránh bị chi phối bởi người nói nhiều.

Ghi nhớ

⚠ Bốn kỹ thuật nhóm dễ lẫn — phân biệt bằng MỤC ĐÍCH: | Kỹ thuật | Mục đích | |---|---| | ⚠ Brainstorming | ⚠ SINH ra nhiều ý tưởng | | ⚠ Brainwriting | ⚠ sinh ý tưởng mà KHÔNG bị ảnh hưởng bởi người khác | | ⚠ Nominal group technique | ⚠ sinh ý tưởng rồi XẾP HẠNG bằng bỏ phiếu | | ⚠ Affinity diagram | ⚠ PHÂN LOẠI ý tưởng đã có thành nhóm | | ⚠ Mind mapping | ⚠ vẽ quan hệ toả ra từ một ý tưởng trung tâm |

Từ khoá nhận diện:

"nhóm ý tưởng theo chủ đề" → ⚠ affinity diagram "bỏ phiếu xếp hạng" → ⚠ nominal group technique "viết trước, nói sau" → ⚠ brainwriting "sơ đồ toả ra từ ý trung tâm" → ⚠ mind mapping "chuyên gia trả lời ẩn danh nhiều vòng" → ⚠ Delphi technique

⚠ Vì sao affinity diagram hữu ích trong buổi họp Lý do
⚠ Giữ buổi họp có nhịp ⚠ ý tưởng vào đúng chỗ ngay lập tức
⚠ Lộ ra nhóm nào ĐANG TRỐNG ⚠ dấu hiệu bỏ sót yêu cầu
⚠ Dễ giao việc theo nhóm sau đó
⚠ Người tham gia thấy đóng góp của mình có chỗ đứng
⚠ Các kỹ thuật ra quyết định nhóm Kỹ thuật
⚠ Unanimity ⚠ tất cả đồng ý
⚠ Majority ⚠ quá bán
⚠ Plurality ⚠ nhóm đông nhất thắng, dù chưa quá bán
⚠ Autocratic ⚠ một người quyết
⚠ Delphi ⚠ là kỹ thuật lấy ý kiến chuyên gia, không phải ra quyết định nhóm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có nhóm nào rỗng hoặc rất ít mục không | ⚠ dấu hiệu bỏ sót | | Các nhóm có phủ hết phạm vi không | | | Yêu cầu có được bên liên quan xác nhận không | |

Và lợi ích ít được nhắc tới của affinity diagram: những ô TRỐNG cũng nói lên điều gì đó. Nếu sau buổi họp nhóm "dữ liệu" chỉ có hai mục trong khi ba nhóm kia có mười lăm, đó là tín hiệu rõ ràng rằng khía cạnh dữ liệu chưa được bàn tới đủ.

Câu 18
You are a project manager for the JHK Project for your organization, and you’re working with the project team to build the project network diagram. Your project team has identified a series of tasks that must happen in a specific order, but this order will cause the project duration to increase. What’s the best description on the ordering of these tasks in this scenario?
  1. A Hard logic
  2. B Constrained logic
  3. C Soft logic
  4. D Work logic
Xem giải thích

Đáp án

A — Hard logic (logic cứng).

Vì sao đúng

⚠ Hard logic — còn gọi là mandatory dependency: | Đặc điểm | Nội dung | |---|---| | ⚠ Bắt buộc bởi BẢN CHẤT công việc | ⚠ không thể làm khác | | ⚠ Hoặc bắt buộc bởi hợp đồng, quy định | | | ⚠ Không thương lượng được | ⚠ dù nó làm dự án dài ra | | ⚠ Ví dụ | ⚠ phải đổ móng trước khi xây tường |

⚠ Đề nói rõ: ⚠ thứ tự này PHẢI xảy ra, dù nó làm tăng thời gian dự án → ⚠ đó là hard logic.

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

  • C (Soft logic) — ⚠ còn gọi là discretionary dependency: do đội CHỌN làm theo thứ tự đó vì kinh nghiệm hoặc thực hành tốt; ⚠ có thể đổi được để rút ngắn lịch.

  • B (Constrained logic) và D (Work logic) — ⚠ không phải thuật ngữ chuẩn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25525 ở lô trước cũng về phụ thuộc giữa các hoạt động — bê tông phải khô mới dựng khung, và giải bằng lag. ⚠ Hai câu bổ sung nhau: một về LOẠI phụ thuộc, một về cách MÔ HÌNH HOÁ độ trễ.

⚠ Bốn loại phụ thuộc theo nguồn gốc: | Loại | Nội dung | Đổi được không | |---|---|---| | ⚠ Mandatory — hard logic | ⚠ bản chất công việc, hợp đồng, luật | ⚠ KHÔNG | | ⚠ Discretionary — soft logic | ⚠ đội chọn theo kinh nghiệm | ⚠ CÓ | | ⚠ External | ⚠ phụ thuộc bên ngoài — giấy phép, nhà cung cấp | ⚠ thường không | | ⚠ Internal | ⚠ giữa các hoạt động trong dự án | ⚠ tuỳ |

⚠ Bốn loại này kết hợp thành cặp: ⚠ mandatory-external, discretionary-internal, v.v.

Từ khoá nhận diện:

"bắt buộc, không thể khác" → ⚠ hard logic, mandatory "đội chọn làm thế cho tiện" → ⚠ soft logic, discretionary "chờ giấy phép, chờ nhà cung cấp" → ⚠ external dependency "chờ thêm thời gian" → ⚠ lag

⚠ Vì sao phân biệt hard và soft quan trọng Lý do
⚠ Khi cần NÉN LỊCH, chỉ soft logic đổi được
⚠ Fast tracking ⚠ làm song song các việc vốn nối tiếp — chỉ áp cho soft logic
⚠ Cố nén hard logic ⚠ là tạo rủi ro nghiêm trọng, hoặc bất khả thi
⚠ Vì thế ⚠ rà lại sơ đồ mạng và hỏi "cái này bắt buộc hay do ta chọn"
⚠ Hai kỹ thuật nén lịch Kỹ thuật
⚠ Crashing ⚠ thêm nguồn lực — TĂNG chi phí
⚠ Fast tracking ⚠ làm song song — TĂNG rủi ro và làm lại
⚠ Cả hai ⚠ chỉ áp lên đường găng mới có tác dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phụ thuộc nào trong sơ đồ là soft logic | ⚠ đó là chỗ có thể nén lịch | | Đường găng đi qua những hoạt động nào | | | Nén lịch làm tăng chi phí hay tăng rủi ro | |

Và câu hỏi đầu tiên nên đặt khi lịch dự án quá dài: trong sơ đồ mạng, phụ thuộc nào là bắt buộc thật và phụ thuộc nào chỉ là thói quen? Rất nhiều thứ được vẽ nối tiếp chỉ vì "xưa nay vẫn làm thế", chứ không phải vì buộc phải thế.

Câu 19
Kelly is the project manager of the GHY Project for her organization. Management has asked Kelly to take the project scope baseline, the project cost baseline, and the project schedule baseline and create a hybrid baseline to reflect overall project performance. What should Kelly do next?
  1. A Inform her manager that these are three separate items that are distinct and cannot be merged to show project performance.
  2. B Create a performance measurement baseline to show all three baselines and how the project is performing overall.
  3. C Create a project dashboard.
  4. D Create an information radiator of all the performance requirements management has requested.
Xem giải thích

Đáp án

B — Tạo một performance measurement baseline (đường cơ sở đo lường hiệu suất) để gộp cả ba và thể hiện tình hình dự án tổng thể.

Vì sao đúng

⚠ Performance Measurement Baseline (PMB) là baseline TỔNG HỢP: | Gộp từ | Nội dung | |---|---| | ⚠ Scope baseline | ⚠ phạm vi được duyệt — scope statement, WBS, WBS dictionary | | ⚠ Schedule baseline | ⚠ lịch được duyệt | | ⚠ Cost baseline | ⚠ ngân sách theo thời gian, đã gồm contingency reserve |

⚠ PMB là mốc để SO SÁNH hiệu suất thực tế — ⚠ và là nền tảng của phân tích Earned Value.

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

  • A (nói với quản lý rằng ba thứ này không gộp được) — ⚠ SAI; ⚠ PMB tồn tại chính để làm việc đó.

  • C (tạo dashboard) và D (tạo information radiator) — ⚠ là cách HIỂN THỊ thông tin, không phải baseline để đo hiệu suất.

Ghi nhớ

⚠ Ba baseline và một baseline tổng: | Baseline | Nội dung | |---|---| | ⚠ Scope baseline | ⚠ scope statement + WBS + WBS dictionary | | ⚠ Schedule baseline | ⚠ lịch đã duyệt | | ⚠ Cost baseline | ⚠ ngân sách phân bổ theo thời gian | | ⚠ Performance Measurement Baseline | ⚠ gộp cả ba, dùng cho Earned Value |

⚠ Baseline chỉ đổi được qua quy trình kiểm soát thay đổi tích hợp — ⚠ không ai được tự sửa để "cho khớp thực tế".

Từ khoá nhận diện:

"gộp ba baseline để đo hiệu suất" → ⚠ performance measurement baseline "phạm vi được duyệt" → ⚠ scope baseline "ngân sách theo thời gian" → ⚠ cost baseline "bảng hiển thị trực quan" → ⚠ dashboard hoặc information radiator

⚠ Quan hệ giữa các khái niệm ngân sách Quan hệ
⚠ Ước lượng chi phí hoạt động ⚠ cộng lại thành work package
⚠ Cộng contingency reserve ⚠ ra COST BASELINE
⚠ Cộng management reserve ⚠ ra PROJECT BUDGET
⚠ Nhớ ⚠ management reserve NGOÀI cost baseline
⚠ Vì sao baseline quan trọng Lý do
⚠ Không có baseline thì không đo được sai lệch
⚠ "Chậm tiến độ" chỉ có nghĩa khi so với một mốc
⚠ Bảo vệ dự án khỏi phạm vi phình ra
⚠ Sai lầm phổ biến ⚠ sửa baseline cho khớp thực tế — làm thế là mất luôn công cụ đo
⚠ Information radiator là gì Nội dung
⚠ Bảng hiển thị lớn, đặt nơi ai cũng thấy
⚠ Thường dùng trong dự án linh hoạt ⚠ task board, burndown chart
⚠ Mục đích: minh bạch thông tin
⚠ Nó là ⚠ cách TRUYỀN ĐẠT, không phải cách ĐO

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ba baseline đã được duyệt chính thức chưa | | | Có ai sửa baseline ngoài quy trình thay đổi không | | | Đo hiệu suất bằng gì | ⚠ Earned Value cần PMB |

Và sai lầm làm mất giá trị của toàn bộ hệ thống đo lường: sửa baseline cho khớp với thực tế. Khi baseline chạy theo thực tế thì mọi chỉ số đều đẹp, và không ai còn biết dự án đang đi đúng hay sai.

Câu 20
Ben is a project manager in his organization and he’s leading an adaptive project. In this adaptive project, he knows that much of the leadership of the team shifts to the project team members rather than on himself. He’s also explaining to his manager that in adaptive projects there is an agile approach where the project team members are not necessarily subject matter experts but are called what term to describe their ability to serve in more than one role?
  1. A Generalized specialists
  2. B Self-organizing
  3. C Servant leadership
  4. D Waiters and servers
Xem giải thích

Đáp án

A — Generalized specialists (chuyên gia đa năng).

Vì sao đúng

⚠ Generalized specialist — còn gọi là "T-shaped person": | Đặc điểm | Nội dung | |---|---| | ⚠ Có một chuyên môn SÂU | ⚠ nét dọc của chữ T | | ⚠ Kèm hiểu biết RỘNG ở nhiều lĩnh vực | ⚠ nét ngang của chữ T | | ⚠ Làm được nhiều vai trò khi cần | | | ⚠ Giảm nút thắt cổ chai trong đội | ⚠ không phải chờ một chuyên gia duy nhất |

⚠ Đây là đặc trưng của đội trong dự án linh hoạt — ⚠ đội nhỏ, tự tổ chức, phải tự lo trọn một hạng mục.

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

  • B (Self-organizing) — ⚠ mô tả cách đội TỰ TỔ CHỨC công việc, không mô tả năng lực của từng cá nhân.

  • C (Servant leadership) — ⚠ phong cách LÃNH ĐẠO của quản lý dự án, phục vụ và gỡ vướng cho đội.

  • D (Waiters and servers) — ⚠ không phải thuật ngữ trong quản lý dự án.

Ghi nhớ

⚠ Ba khái niệm về đội trong dự án linh hoạt: | Khái niệm | Nói về | |---|---| | ⚠ Generalized specialist | ⚠ NĂNG LỰC của từng người | | ⚠ Self-organizing team | ⚠ cách đội TỰ PHÂN CÔNG | | ⚠ Cross-functional team | ⚠ đội có ĐỦ mọi kỹ năng cần thiết |

⚠ Servant leadership — phong cách lãnh đạo trong môi trường linh hoạt: | Việc của người lãnh đạo phục vụ | Nội dung | |---|---| | ⚠ Gỡ vướng cho đội | ⚠ remove impediments | | ⚠ Bảo vệ đội khỏi nhiễu bên ngoài | | | ⚠ Tạo môi trường để đội tự quyết | | | ⚠ Phát triển năng lực từng người | | | ⚠ Ngược với | ⚠ phong cách ra lệnh và kiểm soát |

Từ khoá nhận diện:

"làm được nhiều vai" → ⚠ generalized specialist, T-shaped "đội tự phân công công việc" → ⚠ self-organizing "đội có đủ mọi kỹ năng" → ⚠ cross-functional "lãnh đạo gỡ vướng cho đội" → ⚠ servant leadership

⚠ Vì sao đội linh hoạt cần người đa năng Lý do
⚠ Đội nhỏ, thường 5–9 người
⚠ Phải tự hoàn thành trọn một hạng mục ⚠ từ phân tích tới kiểm thử
⚠ Tránh nút thắt "chờ một người duy nhất"
⚠ Linh hoạt khi có người nghỉ
⚠ Đổi lại ⚠ cần đầu tư đào tạo chéo — cross training
⚠ Ba vai trò trong Scrum Vai trò
⚠ Product Owner ⚠ quyết định LÀM GÌ, ưu tiên backlog
⚠ Scrum Master ⚠ servant leader, bảo vệ quy trình
⚠ Development Team ⚠ tự tổ chức, đa chức năng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có kỹ năng nào chỉ MỘT người trong đội biết không | ⚠ đó là nút thắt và là rủi ro | | Đội có tự phân công được không | ⚠ hay vẫn chờ PM giao việc | | Có kế hoạch đào tạo chéo chưa | |

Và rủi ro về nhân sự dễ nhận ra nhất trong một đội: kỹ năng chỉ một người biết. Người đó nghỉ phép là cả một luồng công việc dừng lại — và đầu tư vào đào tạo chéo chính là cách rẻ nhất để gỡ rủi ro đó.