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

Tìm thấy 720 câu.

Câu 361 Process
Khalid and his project team at Edsel Manufacturing are about to meet to determine the costs of their latest project. He will base project estimates on the WBS, and he has decided to use bottom-up estimating. Of the following choices, which one is not a characteristic of bottom-up estimating?
  1. A The estimates are created by the people doing the work
  2. B It is more expensive than other methods
  3. C It gives a more accurate estimate
  4. D It is less expensive than other methods
Xem giải thích

Đáp án

D — NÓ RẺ HƠN CÁC PHƯƠNG PHÁP KHÁC (đây KHÔNG phải đặc điểm của ước lượng từ dưới lên).

Vì sao đúng

⚠ Ước lượng từ dưới lên tốn kém nhất: | Lý do | Nội dung | |---|---| | ⚠ Phải chia nhỏ công việc tới tận GÓI CÔNG VIỆC | ⚠ cần có WBS đầy đủ trước — đúng điều Khalid đang làm | | ⚠ Phải ước lượng TỪNG gói rồi CỘNG LẠI | ⚠ hàng trăm phép ước lượng thay vì một | | ⚠ Cần sự tham gia của NHIỀU NGƯỜI trong nhiều ngày | | | ⚠ Đó chính là cái giá phải trả để có ĐỘ CHÍNH XÁC cao nhất | | | ⚠ Kết luận | ⚠ từ dưới lên là phương pháp CHÍNH XÁC NHẤT và cũng TỐN KÉM NHẤT — nói nó rẻ hơn là sai |

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

  • B (nó đắt hơn các phương pháp khác) — ⚠ phương án gây nhiễu mạnh nhất vì nó là mệnh đề ĐỐI LẬP trực tiếp với đáp án: ⚠ nhưng đây ⚠ ĐÚNG LÀ đặc điểm của ước lượng từ dưới lên ⚠ — thấy hai phương án ngược nhau thì một cái đúng, một cái sai, và ở đây "đắt hơn" mới là cái đúng.

  • C (nó cho ước lượng chính xác hơn) — ⚠ đúng; ⚠ đó là lý do người ta chấp nhận trả giá.

  • A (ước lượng do chính người làm việc tạo ra) — ⚠ đúng; ⚠ và đó cũng là lý do nó chính xác hơn — người làm hiểu công việc nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25990 ở lô 185 (ước lượng tương tự), câu #26049 lô 186 (thứ tự lập kế hoạch — danh sách hoạt động trước sơ đồ mạng), câu #26017 lô 185 (vì sao cần WBS), và câu #26032 lô 185 (ước lượng độc lập). ⚠ Nhóm ước lượng — và câu này bổ sung góc CHI PHÍ của việc ước lượng.

⚠ BỐN kỹ thuật ước lượng — bảng đầy đủ: | Kỹ thuật | Cách làm | Chính xác | Tốn kém | Dùng khi | |---|---|---|---|---| | ⚠ TƯƠNG TỰ | ⚠ lấy dự án giống trước đây | ⚠ THẤP NHẤT | ⚠ RẺ NHẤT | ⚠ giai đoạn đầu, chưa có chi tiết | | ⚠ THAM SỐ | ⚠ đơn giá × khối lượng | ⚠ trung bình tới cao | ⚠ trung bình | ⚠ có dữ liệu thống kê đáng tin | | ⚠ BA ĐIỂM | ⚠ lạc quan, khả dĩ nhất, bi quan | ⚠ cao, tính tới bất định | ⚠ trung bình | ⚠ có bất định đáng kể | | ⚠ TỪ DƯỚI LÊN | ⚠ chia nhỏ tới gói công việc rồi cộng | ⚠ CAO NHẤT | ⚠ ĐẮT NHẤT — CÂU NÀY | ⚠ cần con số chắc chắn, đã có WBS | | ⚠ Quy luật chung | ⚠ chính xác và tốn kém đi CÙNG CHIỀU — không có phương pháp vừa rẻ vừa chính xác |

Từ khoá nhận diện:

"chia nhỏ tới gói công việc rồi cộng" → ⚠ từ dưới lên "chính xác nhất" → ⚠ từ dưới lên "rẻ nhất, nhanh nhất" → ⚠ tương tự ⚠ Hai phương án đối lập nhau trong cùng bộ → ⚠ một cái là đặc điểm thật, cái kia là đáp án của câu phủ định

⚠ Vì sao "người làm việc tự ước lượng" lại quan trọng Lý do
⚠ Họ hiểu công việc chi tiết nhất
⚠ Họ CAM KẾT hơn với con số mình đưa ra ⚠ liên hệ #25993 lô 185 — không áp velocity từ ngoài vào
⚠ Phát hiện được công việc ẩn mà người ngoài không thấy
⚠ Rủi ro ⚠ người ta có xu hướng ĐỘN thêm để an toàn — liên hệ #25645 lô 178
⚠ Cách cân bằng ⚠ để họ ước lượng, nhưng rà soát tổng thể và hỏi về các giả định
⚠ Khi nào KHÔNG nên dùng từ dưới lên Trường hợp
⚠ Giai đoạn đầu, chưa có WBS ⚠ không có gì để chia nhỏ
⚠ Cần con số nhanh để quyết định có làm hay không ⚠ dùng ước lượng tương tự — liên hệ #25990 lô 185
⚠ Dự án nhỏ, chi phí ước lượng vượt lợi ích
⚠ Thực tế phổ biến ⚠ dùng TƯƠNG TỰ ở đầu để quyết định đầu tư, rồi TỪ DƯỚI LÊN khi lập kế hoạch chi tiết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng của bạn do ai tạo ra | ⚠ người làm hay người quản lý | | Bạn có WBS đủ chi tiết để ước lượng từ dưới lên không | | | Chi phí bỏ ra để ước lượng có tương xứng với quy mô dự án không | |

Và điều bảng so sánh này nhắc lại: mọi phương pháp ước lượng đều là một cuộc mua bán giữa ĐỘ CHÍNH XÁC và CÔNG SỨC — và không có phương pháp nào cho bạn cả hai.

Câu 362 Process
As the project manager for the Transcom Project, Luther is aware that the project is falling behind schedule. Additionally, he has already spent $125,000 of the $165,000 budget. What is the $125,000 called?
  1. A Planned value
  2. B Sunk costs
  3. C Capital expenditure
  4. D Present value
Xem giải thích

Đáp án

B — CHI PHÍ CHÌM (sunk costs).

Vì sao đúng

⚠ Định nghĩa chi phí chìm: | Đặc điểm | Nội dung | |---|---| | ⚠ Là tiền ĐÃ TIÊU và KHÔNG THỂ THU HỒI | ⚠ 125.000 Luther đã chi | | ⚠ KHÔNG được tính vào quyết định TƯƠNG LAI | ⚠ nguyên tắc quan trọng nhất | | ⚠ Trong EVM, chi phí chìm chính là AC — chi phí thực tế | | | ⚠ Vì sao có nguyên tắc này | ⚠ tiền đã tiêu không thể lấy lại dù quyết định thế nào, nên nó KHÔNG phải yếu tố phân biệt giữa các lựa chọn | | ⚠ Bối cảnh của Luther | ⚠ dự án đang chậm tiến độ — nếu phải quyết dừng hay tiếp, thì 125.000 đã tiêu KHÔNG được là lý do để tiếp |

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

  • A (giá trị kế hoạch — planned value) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là thuật ngữ EVM về tiền: ⚠ nhưng PV là ⚠ giá trị công việc ĐÁNG LẼ phải hoàn thành tới thời điểm này theo kế hoạch, ⚠ không phải tiền đã tiêu; ⚠ tiền đã tiêu là AC (liên hệ #25985 lô 185).

  • C (chi tiêu vốn — capital expenditure) — ⚠ thuật ngữ KẾ TOÁN chỉ khoản đầu tư vào tài sản dài hạn; ⚠ không phải khái niệm này.

  • D (giá trị hiện tại — present value) — ⚠ giá trị hôm nay của một khoản tiền tương lai; ⚠ dùng để so sánh phương án đầu tư.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25697 ở lô 179 (chi phí chìm = AC = 495.000) — ⚠ hai câu cùng chủ đề, khoá NHẤT QUÁN. ⚠ Xem thêm câu #25668 lô 178 (chi phí cơ hội), câu #26065 lô 186 (CPI 0,89), và câu #26060 (các phương pháp chọn dự án).

⚠ BẪY CHI PHÍ CHÌM — sai lầm phổ biến nhất trong quản lý dự án: | Biểu hiện | Nội dung | |---|---| | ⚠ "Đã tiêu 125.000 rồi, giờ dừng thì phí" | ⚠ lập luận SAI về mặt kinh tế | | ⚠ Đúng phải là: từ bây giờ, tiếp tục có đáng không? | ⚠ so ETC với lợi ích còn lại | | ⚠ Tiền đã tiêu mất rồi dù bạn dừng hay tiếp | | | ⚠ Vì sao khó vượt qua | ⚠ tâm lý con người rất ghét cảm giác "lãng phí" thứ đã bỏ ra | | ⚠ Ở quy mô lớn | ⚠ đây là lý do nhiều siêu dự án không bao giờ bị dừng dù đã rõ là sai — liên hệ #25995 lô 185 |

Từ khoá nhận diện:

"tiền đã tiêu, không thu hồi được" → ⚠ chi phí chìm "đáng lẽ phải hoàn thành bao nhiêu" → ⚠ giá trị kế hoạch (PV) "giá trị hôm nay của tiền tương lai" → ⚠ giá trị hiện tại (PV — trùng viết tắt, khác nghĩa hoàn toàn) "cơ hội bị bỏ qua" → ⚠ chi phí cơ hội — liên hệ #25668 lô 178

⚠ Cẩn thận với hai chữ viết tắt "PV" Phân biệt
⚠ PV trong EVM = PLANNED VALUE ⚠ giá trị công việc theo kế hoạch tới thời điểm này
⚠ PV trong tài chính = PRESENT VALUE ⚠ giá trị hiện tại của dòng tiền tương lai
⚠ Cách phân biệt ⚠ bối cảnh — nói về tiến độ dự án thì là planned value; nói về đầu tư và chiết khấu thì là present value
⚠ Ở câu này ⚠ cả hai đều xuất hiện làm phương án nhiễu, và cả hai đều sai
⚠ Luther nên quyết định thế nào Cách
⚠ BỎ QUA 125.000 đã tiêu
⚠ Tính ETC — còn phải tiêu bao nhiêu để hoàn thành ⚠ liên hệ #26027 lô 185
⚠ So ETC với LỢI ÍCH còn lại của dự án
⚠ Nếu lợi ích còn lại > chi phí còn lại thì TIẾP
⚠ Nếu không thì DỪNG, bất kể đã tiêu bao nhiêu ⚠ liên hệ #26031 lô 185 — lý do chấm dứt dự án
⚠ Điều cần chuẩn bị ⚠ lập luận này rất khó thuyết phục về mặt cảm xúc — cần số liệu rõ ràng để trình bày

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dự án nào ở tổ chức bạn đang tiếp tục chỉ vì "đã lỡ đầu tư" không | | | Quyết định tiếp hay dừng của bạn dựa trên chi phí còn lại hay chi phí đã tiêu | | | Bạn có tính ETC định kỳ không | |

Và câu hỏi duy nhất cần đặt khi đứng trước bẫy chi phí chìm: nếu hôm nay mới bắt đầu, với thông tin đang có, tôi có bỏ tiền vào dự án này không? Câu trả lời đó không phụ thuộc chút nào vào 125.000 đã tiêu.

Câu 363 Process
Kathleen’s team at Oscorp hands out play money to the stakeholder team during backlog prioritization exercises. They limit the use of the money only to prioritizing business functionality. Why?
  1. A Non-business functions like compliance activities should always be placed within the user stories for business functionality.
  2. B This is a method of prioritizing reserves funds on a sliding scale for work separate from business functionality.
  3. C Stakeholders tend not to spend money on things other than business functionality, so other non-functional work might never get done.
  4. D Only business functionality should ever be placed in the backlog.
Xem giải thích

Đáp án

C — Bên liên quan có xu hướng KHÔNG TIÊU TIỀN vào những thứ ngoài chức năng nghiệp vụ, nên các công việc PHI CHỨC NĂNG có thể KHÔNG BAO GIỜ được làm.

Vì sao đúng

⚠ Vấn đề mà Kathleen đang phòng ngừa: | Vấn đề | Nội dung | |---|---| | ⚠ Bên liên quan chỉ nhìn thấy giá trị của TÍNH NĂNG NHÌN ĐƯỢC | | | ⚠ Họ ít khi bỏ phiếu cho bảo mật, hiệu năng, nợ kỹ thuật, tuân thủ | ⚠ những thứ không nhìn thấy trên màn hình | | ⚠ Nếu để họ xếp ưu tiên TẤT CẢ thì phần phi chức năng luôn xếp cuối | | | ⚠ Giới hạn "tiền chơi" chỉ cho chức năng nghiệp vụ | ⚠ tách hai loại công việc ra, không cho chúng cạnh tranh nhau | | ⚠ Phần phi chức năng được xử lý thế nào | ⚠ dành riêng một phần sức chứa, hoặc đưa vào ĐỊNH NGHĨA HOÀN THÀNH |

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

  • B (đây là cách xếp ưu tiên quỹ dự phòng theo thang trượt cho công việc tách khỏi chức năng nghiệp vụ) — ⚠ phương án gây nhiễu mạnh nhất vì dùng nhiều thuật ngữ nghe chuyên môn: ⚠ nhưng nó ⚠ mô tả sai hoàn toàn cơ chế ⚠ — phương pháp tiền chơi không liên quan gì tới quỹ dự phòng.

  • A (công việc phi nghiệp vụ như tuân thủ nên luôn được đặt trong user story nghiệp vụ) — ⚠ có phần đúng trong thực tế ⚠ (gộp yêu cầu phi chức năng vào tiêu chí chấp nhận), ⚠ nhưng ⚠ KHÔNG phải lý do Kathleen giới hạn tiền chơi.

  • D (chỉ chức năng nghiệp vụ mới được đưa vào backlog) — ⚠ SAI: ⚠ backlog chứa MỌI thứ cần làm, kể cả nợ kỹ thuật và công việc phi chức năng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26043 ở lô 186 (phương pháp 100 điểm — 8 người × 100 = 800 tối đa) — ⚠ cùng một họ kỹ thuật: phát "tiền" hoặc "điểm" để buộc đánh đổi. ⚠ Xem thêm câu #26002 lô 185 (xếp hạng tuyệt đối), câu #26010 (bỏ phiếu im lặng), và câu #26036 lô 186 (nắm tay năm ngón).

⚠ Vì sao công việc PHI CHỨC NĂNG hay bị bỏ quên: | Loại công việc | Vì sao bị bỏ | |---|---| | ⚠ BẢO MẬT | ⚠ không nhìn thấy được cho tới khi bị tấn công | | ⚠ HIỆU NĂNG | ⚠ hệ thống nhỏ thì chưa lộ vấn đề | | ⚠ NỢ KỸ THUẬT | ⚠ liên hệ #26069 lô 186 — mã cũ không đạt chuẩn | | ⚠ TUÂN THỦ quy định | ⚠ liên hệ #25962 lô 184 — rủi ro tuân thủ | | ⚠ Khả năng tiếp cận | ⚠ liên hệ #25977 lô 184 — bản mẫu bị từ chối vì bảng màu | | ⚠ Hạ tầng, tự động hoá kiểm thử | ⚠ liên hệ #25986 lô 185 — đầu tư cho CI | | ⚠ Điểm chung | ⚠ chúng KHÔNG tạo ra tính năng nhìn thấy được, nên luôn thua trong cuộc bỏ phiếu công khai |

⚠ Các cách bảo vệ công việc phi chức năng: | Cách | Nội dung | |---|---| | ⚠ TÁCH KHỎI cuộc bỏ phiếu ưu tiên | ⚠ cách của Kathleen — CÂU NÀY | | ⚠ Dành riêng một phần sức chứa mỗi sprint | ⚠ ví dụ 20% cho nợ kỹ thuật | | ⚠ Đưa vào ĐỊNH NGHĨA HOÀN THÀNH | ⚠ khi đó nó là điều kiện bắt buộc, không phải hạng mục cạnh tranh — liên hệ #25953 lô 184 | | ⚠ Biến thành tiêu chí chấp nhận của từng user story | ⚠ ý tưởng của phương án A | | ⚠ Quy đổi thành RỦI RO có giá trị bằng tiền | ⚠ "không làm phần bảo mật này là chấp nhận rủi ro X đô" — cách thuyết phục nhất với bên liên quan | | ⚠ Cách hiệu quả nhất | ⚠ kết hợp: đưa phần bắt buộc vào DoD, phần còn lại có sức chứa riêng |

Từ khoá nhận diện:

"giới hạn bỏ phiếu chỉ cho chức năng nghiệp vụ" → ⚠ bảo vệ công việc phi chức năng "chỉ chức năng nghiệp vụ mới vào backlog" → ⚠ sai — backlog chứa mọi thứ "tiền chơi, 100 điểm, cumulative voting" → ⚠ cùng một họ kỹ thuật buộc đánh đổi "quỹ dự phòng" → ⚠ không liên quan tới kỹ thuật này

⚠ Kathleen còn nên làm gì Việc
⚠ Cho bên liên quan thấy công việc phi chức năng đang được làm ⚠ minh bạch, để họ không nghĩ đội đang giấu việc
⚠ Giải thích HẬU QUẢ nếu bỏ qua ⚠ bằng ví dụ và số liệu, không bằng thuật ngữ kỹ thuật
⚠ Thống nhất TỶ LỆ sức chứa dành cho phần phi chức năng ⚠ để không phải tranh cãi mỗi sprint
⚠ Điều cần tránh ⚠ âm thầm làm mà không nói — bên liên quan sẽ thấy velocity giảm mà không hiểu vì sao

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nợ kỹ thuật của đội bạn có được xếp ưu tiên bao giờ không | | | Yêu cầu phi chức năng nằm ở đâu — backlog hay Định nghĩa Hoàn thành | | | Bên liên quan có biết đội đang dành bao nhiêu sức chứa cho việc không nhìn thấy được không | |

Và lý do cách làm của Kathleen thông minh: cô không tranh cãi với bên liên quan về việc bảo mật có quan trọng hay không — cô chỉ đơn giản không đặt nó lên cùng một bàn cân với tính năng mới.

Câu 364 Process

Henry is a stakeholder for Project QL. Project QL is in its tenth week of implementation, with a CPI of 1.1 and an SPI of 1.01. Recently Henry was reviewing project data and found the scatter diagram in the figure. What conclusion can Henry draw from this diagram?


  1. A Some of the larger tasks should be broken down.
  2. B Nothing, the distribution is too random.
  3. C The higher the quality score, the more hours worked.
  4. D Only high-quality items worked over 75 hours.
Xem giải thích

Đáp án

B — KHÔNG rút ra được kết luận nào, vì phân bố quá NGẪU NHIÊN.

Vì sao đúng

⚠ Biểu đồ phân tán dùng để làm gì: | Mục đích | Nội dung | |---|---| | ⚠ Kiểm tra xem HAI BIẾN có TƯƠNG QUAN với nhau không | | | ⚠ Các điểm tạo thành xu hướng RÕ RÀNG → có tương quan | ⚠ đi lên, đi xuống, hoặc theo đường cong | | ⚠ Các điểm PHÂN TÁN NGẪU NHIÊN → KHÔNG có tương quan | ⚠ trường hợp của Henry | | ⚠ Không có tương quan thì KHÔNG kết luận gì được | ⚠ và đó là một kết luận hợp lệ | | ⚠ Trung thực khoa học | ⚠ nói "không thấy quan hệ nào" tốt hơn nhiều so với gán một quan hệ không tồn tại |

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

  • C (điểm chất lượng càng cao thì số giờ làm càng nhiều) — ⚠ phương án gây nhiễu mạnh nhất vì đó là kết luận người ta MONG MUỐN thấy: ⚠ nhưng ⚠ dữ liệu phân tán ngẫu nhiên KHÔNG cho phép kết luận đó; ⚠ đây là lỗi kinh điển — nhìn thấy mẫu hình trong dữ liệu ngẫu nhiên.

  • D (chỉ những hạng mục chất lượng cao mới làm quá 75 giờ) — ⚠ kết luận quá cụ thể từ dữ liệu không có cấu trúc.

  • A (nên chia nhỏ một số công việc lớn) — ⚠ có thể là lời khuyên tốt về mặt quản lý, ⚠ nhưng ⚠ KHÔNG rút ra được từ biểu đồ này.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25967 ở lô 185 (phân tích xu hướng lỗi), câu #26063 lô 186 (RACI không phải công cụ trình bày hiệu suất), câu #25914 lô 183 (thiết kế thực nghiệm), và câu #26045 lô 186 (Monte Carlo). ⚠ Nhóm công cụ phân tích dữ liệu.

⚠ Đọc biểu đồ phân tán: | Hình dạng | Kết luận | |---|---| | ⚠ Các điểm đi lên từ trái sang phải | ⚠ TƯƠNG QUAN DƯƠNG — biến này tăng thì biến kia tăng | | ⚠ Các điểm đi xuống | ⚠ TƯƠNG QUAN ÂM | | ⚠ Các điểm bám sát một đường | ⚠ tương quan MẠNH | | ⚠ Các điểm tản mát quanh một đường | ⚠ tương quan YẾU | | ⚠ Các điểm rải rác không theo hình nào | ⚠ KHÔNG có tương quan — CÂU NÀY | | ⚠ Cảnh báo quan trọng nhất | ⚠ TƯƠNG QUAN KHÔNG PHẢI NHÂN QUẢ — kể cả khi thấy xu hướng rõ ràng |

Từ khoá nhận diện:

"phân bố ngẫu nhiên" → ⚠ không kết luận được gì "biến này tăng thì biến kia tăng" → ⚠ tương quan dương "quan hệ giữa hai biến" → ⚠ biểu đồ phân tán ⚠ Kết luận nghe hợp lý nhưng dữ liệu không hỗ trợ → ⚠ bẫy phổ biến nhất của mọi câu hỏi về biểu đồ

⚠ Vì sao "không kết luận được gì" lại là câu trả lời ĐÚNG Lý do
⚠ Gán quan hệ không tồn tại dẫn tới quyết định sai ⚠ "cứ làm nhiều giờ là chất lượng tăng" — kết luận nguy hiểm
⚠ Trung thực về giới hạn của dữ liệu là dấu hiệu chuyên nghiệp
⚠ Nó chỉ ra rằng cần thu thập dữ liệu KHÁC hoặc NHIỀU HƠN
⚠ Bước tiếp theo cho Henry ⚠ hỏi xem có biến thứ ba nào ảnh hưởng không, hoặc dữ liệu có đủ nhiều không
⚠ Chi tiết đáng chú ý ⚠ dự án đang chạy TỐT (CPI 1,1 và SPI 1,01) — nên đây không phải lúc đi tìm vấn đề trong dữ liệu ngẫu nhiên
⚠ BẢY CÔNG CỤ CHẤT LƯỢNG CƠ BẢN — nhắc lại Công cụ
⚠ Biểu đồ nhân quả (Ishikawa) ⚠ tìm nguyên nhân gốc — liên hệ #26013 lô 185
⚠ Lưu đồ ⚠ mô tả quy trình
⚠ Phiếu kiểm tra ⚠ thu thập dữ liệu có tổ chức
⚠ Biểu đồ Pareto ⚠ 80/20 — hỏi bốn lần ở lô 177–182
⚠ Histogram ⚠ phân bố tần suất — liên hệ #26063 lô 186
⚠ Biểu đồ kiểm soát ⚠ quy trình có trong tầm kiểm soát không — liên hệ #25983 lô 185
⚠ BIỂU ĐỒ PHÂN TÁN ⚠ quan hệ giữa hai biến — CÂU NÀY
⚠ Bộ đề đã hỏi ⚠ Pareto, Ishikawa, histogram, biểu đồ kiểm soát và nay là phân tán — gần đủ bộ bảy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có bao giờ kết luận từ dữ liệu quá ít không | | | Biểu đồ gần nhất bạn xem có xu hướng thật hay bạn tự thấy | | | Có ai kiểm tra lại kết luận của bạn không | |

Và kỹ năng khó nhất khi làm việc với dữ liệu, khó hơn nhiều so với việc vẽ biểu đồ: dám nói "dữ liệu này không cho ta biết điều gì cả" khi mọi người trong phòng đang chờ một kết luận.

Câu 365 Process
You are the project manager of the Bern Update project for your organization. You are currently working with your project in quantitative analysis to create a contingency reserve. One project risk has a thirty percent probability of happening and will cost the project $45,000 if it occurs. For this one risk, what is the amount of funds that should go into the contingency reserve?
  1. A $13,500
  2. B $15,000
  3. C No funds are allotted until the risk occurs.
  4. D $45,000
Xem giải thích

Đáp án

A — 13.500 ĐÔ LA.

Vì sao đúng

⚠ Phép tính giá trị tiền tệ kỳ vọng (EMV): | Thành phần | Giá trị | |---|---| | ⚠ Xác suất xảy ra | ⚠ 30% = 0,30 | | ⚠ Tác động nếu xảy ra | ⚠ 45.000 đô | | ⚠ EMV = xác suất × tác động | ⚠ 0,30 × 45.000 = 13.500 | | ⚠ Đó là khoản đưa vào DỰ PHÒNG BẤT TRẮC cho rủi ro này | | | ⚠ Vì sao dùng EMV chứ không dùng 45.000 | ⚠ nếu để đủ 45.000 cho MỌI rủi ro thì quỹ dự phòng sẽ lớn hơn cả ngân sách dự án |

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

  • D (45.000) — ⚠ phương án gây nhiễu mạnh nhất vì đó là con số thiệt hại thật nếu rủi ro xảy ra: ⚠ nhưng ⚠ dự phòng được tính theo GIÁ TRỊ KỲ VỌNG, không theo tác động toàn phần; ⚠ để đủ tiền cho mọi kịch bản xấu nhất là bất khả thi về mặt tài chính.

  • C (không cấp quỹ nào cho tới khi rủi ro xảy ra) — ⚠ phủ nhận toàn bộ mục đích của dự phòng bất trắc; ⚠ quỹ này tồn tại chính là để SẴN SÀNG TRƯỚC.

  • B (15.000) — ⚠ không có phép tính nào cho ra con số này; ⚠ có thể là làm tròn sai hoặc tính nhầm 1/3.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26068 ở lô 186 (Joachim dùng nhầm dự phòng bất trắc thay vì dự phòng quản lý) — ⚠ câu đó nói VỀ LOẠI QUỸ, câu này nói CÁCH TÍNH quỹ; hai câu bổ sung nhau trực tiếp. ⚠ Xem thêm câu #25719 lô 179 (EMV −98.000), câu #26003 lô 185 (điểm rủi ro), và câu #26045 lô 186 (Monte Carlo).

⚠ Cách xây dựng DỰ PHÒNG BẤT TRẮC: | Bước | Nội dung | |---|---| | ⚠ 1. Nhận diện rủi ro | ⚠ liên hệ #25923 lô 183 | | ⚠ 2. Ước lượng XÁC SUẤT và TÁC ĐỘNG của từng rủi ro | | | ⚠ 3. Tính EMV = xác suất × tác động cho từng rủi ro | ⚠ CÂU NÀY | | ⚠ 4. CỘNG EMV của tất cả rủi ro lại | ⚠ thành tổng quỹ dự phòng bất trắc | | ⚠ 5. Có thể tinh chỉnh bằng Monte Carlo | ⚠ liên hệ #26045 lô 186 | | ⚠ Quỹ này nằm ở đâu | ⚠ TRONG đường cơ sở chi phí — liên hệ #26068 lô 186 |

⚠ EMV cho rủi ro TIÊU CỰC và TÍCH CỰC: | Loại | Dấu | |---|---| | ⚠ Rủi ro TIÊU CỰC (mối đe doạ) | ⚠ EMV mang dấu ÂM khi tính tổng — là khoản tiền dự kiến MẤT | | ⚠ Rủi ro TÍCH CỰC (cơ hội) | ⚠ EMV mang dấu DƯƠNG — khoản tiền dự kiến ĐƯỢC | | ⚠ Khi tính tổng cho cây quyết định | ⚠ cộng cả hai loại lại để ra giá trị kỳ vọng của một nhánh — liên hệ #26013 lô 185 | | ⚠ Khi tính quỹ dự phòng | ⚠ thường chỉ tính rủi ro tiêu cực |

Từ khoá nhận diện:

"xác suất × tác động" → ⚠ EMV, giá trị tiền tệ kỳ vọng "đưa bao nhiêu vào dự phòng" → ⚠ dùng EMV, không dùng tác động toàn phần "toàn bộ số tiền thiệt hại" → ⚠ bẫy — đó là tác động, không phải EMV "đợi rủi ro xảy ra rồi mới lo" → ⚠ phủ nhận mục đích của dự phòng

⚠ Hạn chế của cách tính EMV đơn giản Hạn chế
⚠ 13.500 KHÔNG BAO GIỜ là số tiền thực chi ⚠ thực tế hoặc là 0 (không xảy ra), hoặc là 45.000 (xảy ra)
⚠ Nó chỉ có ý nghĩa khi cộng NHIỀU rủi ro lại ⚠ luật số lớn — trung bình thì đủ
⚠ Không xử lý được rủi ro "xác suất thấp, tác động thảm khốc" ⚠ liên hệ #26003 lô 185 — điểm thấp nhưng vẫn giết chết dự án
⚠ Cách bù ⚠ với rủi ro thảm khốc, lập kế hoạch dự phòng riêng hoặc chuyển giao qua bảo hiểm — liên hệ #26040 lô 186
⚠ Công cụ tốt hơn cho dự án lớn ⚠ mô phỏng Monte Carlo cho ra phân bố thay vì một con số

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 0,30 × 45.000 = 13.500 | ⚠ kiểm lại phép nhân | | Quỹ dự phòng của bạn tính từ đâu | ⚠ từ phân tích rủi ro hay từ một tỷ lệ phần trăm tròn | | Có rủi ro thảm khốc nào chỉ được đưa vào bằng EMV không | ⚠ loại đó cần xử lý riêng |

Và điều con số 13.500 thật sự nói lên: không có rủi ro nào tốn đúng 13.500 cả — đó là số tiền bạn cần chuẩn bị nếu phải quản lý rất nhiều rủi ro tương tự trong nhiều dự án.

Câu 366 People
Alonso works as a project manager at Schroeder Enterprises, a project-oriented organization. Of the following, which can best describe Alonso's job as a project manager?
  1. A Expediter
  2. B Part-time
  3. C Full-time
  4. D Coordinator
Xem giải thích

Đáp án

C — TOÀN THỜI GIAN (full-time).

Vì sao đúng

⚠ Tổ chức định hướng dự án (projectized): | Đặc điểm | Nội dung | |---|---| | ⚠ Tổ chức được cấu trúc quanh CÁC DỰ ÁN, không quanh phòng ban chức năng | | | ⚠ Quản lý dự án có thẩm quyền CAO tới gần như TOÀN QUYỀN | | | ⚠ Vai trò quản lý dự án là công việc TOÀN THỜI GIAN | ⚠ không kiêm nhiệm | | ⚠ Đội dự án cũng thường làm toàn thời gian cho dự án | | | ⚠ Quản lý dự án kiểm soát ngân sách | | | ⚠ Đối lập | ⚠ trong tổ chức CHỨC NĂNG, PM thường chỉ làm bán thời gian và có rất ít quyền — liên hệ #26076 lô 186 |

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

  • B (bán thời gian) — ⚠ phương án gây nhiễu mạnh nhất vì rất nhiều PM trong thực tế làm bán thời gian: ⚠ nhưng đó là đặc điểm của tổ chức ⚠ CHỨC NĂNG hoặc MA TRẬN YẾU, ⚠ không phải tổ chức định hướng dự án.

  • A (người xúc tiến — expediter) và D (người điều phối — coordinator) — ⚠ hai vai trò có QUYỀN RẤT ÍT, ⚠ đặc trưng của tổ chức chức năng; ⚠ xem bảng phân biệt bên dưới.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26076 ở lô 186 (quyền lực trong tổ chức chức năng thuộc về quản lý chức năng) — ⚠ hai câu là HAI ĐẦU của cùng một dải: câu đó nói về cực có ít quyền nhất, câu này nói về cực có nhiều quyền nhất. ⚠ Xem thêm câu #25855 lô 182 (ma trận yếu), câu #25691 lô 179 (không có điều lệ), và câu #25906 lô 183 (vai trò nhà tài trợ trong tổ chức chức năng).

⚠ CÁC KIỂU CƠ CẤU TỔ CHỨC — bảng đầy đủ: | Cơ cấu | Quyền của PM | PM làm việc | Ai kiểm soát ngân sách | |---|---|---|---| | ⚠ CHỨC NĂNG | ⚠ rất ít hoặc không có | ⚠ BÁN THỜI GIAN | ⚠ quản lý chức năng | | ⚠ MA TRẬN YẾU | ⚠ hạn chế | ⚠ BÁN THỜI GIAN | ⚠ quản lý chức năng | | ⚠ MA TRẬN CÂN BẰNG | ⚠ thấp tới trung bình | ⚠ TOÀN THỜI GIAN | ⚠ chia sẻ | | ⚠ MA TRẬN MẠNH | ⚠ trung bình tới cao | ⚠ TOÀN THỜI GIAN | ⚠ quản lý dự án | | ⚠ ĐỊNH HƯỚNG DỰ ÁN | ⚠ CAO tới gần như toàn quyền | ⚠ TOÀN THỜI GIAN — CÂU NÀY | ⚠ quản lý dự án | | ⚠ Quy luật | ⚠ đi từ trên xuống dưới: quyền của PM TĂNG, quyền của quản lý chức năng GIẢM |

⚠ Ba vai trò dễ nhầm trong tổ chức chức năng: | Vai trò | Quyền hạn | |---|---| | ⚠ NGƯỜI XÚC TIẾN (expediter) | ⚠ ÍT NHẤT — chỉ là trợ lý truyền đạt, KHÔNG có quyền ra quyết định | | ⚠ NGƯỜI ĐIỀU PHỐI (coordinator) | ⚠ có chút quyền ra quyết định, báo cáo cho cấp cao hơn | | ⚠ QUẢN LÝ DỰ ÁN thật sự | ⚠ có thẩm quyền, kiểm soát nguồn lực | | ⚠ Mẹo nhớ | ⚠ xúc tiến < điều phối < quản lý — quyền tăng dần |

Từ khoá nhận diện:

"tổ chức định hướng dự án" → ⚠ PM toàn thời gian, quyền cao nhất "tổ chức chức năng" → ⚠ PM bán thời gian, quyền thấp nhất "người xúc tiến / điều phối" → ⚠ vai trò có ít quyền, thuộc tổ chức chức năng "ma trận" → ⚠ ở giữa, phải xem là yếu, cân bằng hay mạnh

⚠ Ưu và nhược của tổ chức định hướng dự án Đánh giá
⚠ ƯU: PM có thẩm quyền rõ ràng, ra quyết định nhanh
⚠ ƯU: đội trung thành với dự án, không bị kéo đi nơi khác ⚠ liên hệ #26015 lô 185 — đội khác xin mượn người
⚠ ƯU: giao tiếp trong đội đơn giản hơn
⚠ NHƯỢC: nhân sự KHÔNG BIẾT ĐI ĐÂU khi dự án kết thúc ⚠ vấn đề lớn nhất của mô hình này
⚠ NHƯỢC: khó duy trì và phát triển chuyên môn sâu ⚠ không có "ngôi nhà chức năng" để về
⚠ NHƯỢC: dễ trùng lặp nguồn lực giữa các dự án
⚠ Ai hay dùng ⚠ công ty tư vấn, xây dựng, sản xuất phim — nơi công việc vốn đã có dạng dự án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn thuộc kiểu nào | ⚠ quyết định gần như mọi thứ về cách bạn phải làm việc | | Bạn làm quản lý dự án toàn thời gian hay kiêm nhiệm | | | Bạn kiểm soát ngân sách dự án tới mức nào | ⚠ đây là câu hỏi phân biệt chính xác nhất về quyền lực thật |

Và câu hỏi duy nhất để xác định nhanh cơ cấu tổ chức của mình: khi bạn cần một người làm việc cho dự án, bạn RA LỆNH hay bạn ĐI XIN? Câu trả lời cho biết bạn đang ở đâu trên dải này.

Câu 367 Process
In Jesus's new website design project, there are 57 stakeholders, and he expects multiple project change requests. Of the following, which is not true about change requests?
  1. A A stakeholder can initiate a change request.
  2. B Change requests must be documented.
  3. C Change requests always require extra funding.
  4. D Change requests happen while the project work is being done.
Xem giải thích

Đáp án

C — YÊU CẦU THAY ĐỔI LUÔN ĐÒI HỎI THÊM KINH PHÍ (đây là mệnh đề KHÔNG đúng).

Vì sao đúng

⚠ Vì sao thay đổi không nhất thiết tốn thêm tiền: | Trường hợp | Nội dung | |---|---| | ⚠ Thay đổi có thể GIẢM phạm vi | ⚠ bỏ bớt một tính năng — TIẾT KIỆM tiền | | ⚠ Thay đổi có thể chỉ đổi THỨ TỰ công việc | ⚠ không ảnh hưởng tổng chi phí | | ⚠ Thay đổi có thể được xử lý trong DỰ PHÒNG đã có | ⚠ không cần xin thêm ngân sách | | ⚠ Có thay đổi bị TỪ CHỐI — không tốn gì cả | ⚠ vẫn là một yêu cầu thay đổi hợp lệ | | ⚠ Kết luận | ⚠ từ "LUÔN LUÔN" là chỗ sai — thay đổi CÓ THỂ tốn thêm tiền, nhưng không nhất thiết |

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

  • D (thay đổi xảy ra trong lúc công việc dự án đang được thực hiện) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như một khẳng định quá hẹp: ⚠ nhưng nó ⚠ ĐÚNG ⚠ — phần lớn yêu cầu thay đổi phát sinh trong giai đoạn thực hiện và giám sát; ⚠ đó là lúc thực tế va chạm với kế hoạch.

  • A (bên liên quan có thể khởi xướng yêu cầu thay đổi) — ⚠ đúng; ⚠ bất kỳ ai cũng có thể đề xuất — bên liên quan, đội, nhà cung cấp, cơ quan quản lý.

  • B (yêu cầu thay đổi phải được ghi thành văn bản) — ⚠ đúng và bắt buộc; ⚠ liên hệ #26048 lô 186 — luật mới thì việc đầu tiên là lập yêu cầu thay đổi bằng văn bản.

Ghi nhớ

⚠ Đối chiếu — nhóm kiểm soát thay đổi đã lên BẢY câu qua bốn lô: ⚠ #25956 lô 184 (nhật ký thay đổi), ⚠ #25975, #25978 (mạ vàng, phân tích tác động), ⚠ #25991, #26012, #26023 lô 185, ⚠ #26048, #26052, #26066 lô 186, ⚠ và câu này. ⚠ Chủ đề được hỏi dày nhất của bộ đề PMP Set I.

⚠ BA loại thay đổi theo tác động chi phí: | Loại | Ví dụ | |---|---| | ⚠ TĂNG chi phí | ⚠ thêm tính năng, thêm phạm vi | | ⚠ GIẢM chi phí | ⚠ cắt bớt phạm vi, đơn giản hoá giải pháp | | ⚠ KHÔNG đổi chi phí | ⚠ đổi thứ tự, đổi cách làm với cùng công sức, đổi nhà cung cấp cùng giá | | ⚠ Điểm chung | ⚠ CẢ BA đều phải qua kiểm soát thay đổi tích hợp — liên hệ #26052 lô 186 | | ⚠ Vì sao thay đổi GIẢM chi phí vẫn phải qua quy trình | ⚠ nó vẫn đổi ĐƯỜNG CƠ SỞ PHẠM VI, và có thể ảnh hưởng tới thứ khác |

Từ khoá nhận diện:

"LUÔN LUÔN, KHÔNG BAO GIỜ, MỌI" → ⚠ cẩn thận — từ tuyệt đối thường là dấu hiệu của mệnh đề sai "thay đổi phải được ghi thành văn bản" → ⚠ đúng, bắt buộc "ai cũng có thể đề xuất thay đổi" → ⚠ đúng "thay đổi xảy ra khi đang thực hiện" → ⚠ đúng, đó là lúc phổ biến nhất

⚠ Bốn kết quả có thể của một yêu cầu thay đổi Kết quả
⚠ ĐƯỢC DUYỆT — cập nhật đường cơ sở và thực hiện
⚠ BỊ TỪ CHỐI — ghi nhận lý do vào nhật ký ⚠ liên hệ #25956 lô 184 — vẫn phải lưu
⚠ HOÃN — chờ thêm thông tin hoặc chờ giai đoạn sau
⚠ Cần thêm PHÂN TÍCH trước khi quyết ⚠ liên hệ #25978 lô 184
⚠ Trong mọi trường hợp ⚠ phải THÔNG BÁO cho người đề xuất — bước hay bị bỏ nhất
⚠ Vì sao 57 bên liên quan là chi tiết đáng chú ý Ý nghĩa
⚠ Số kênh giao tiếp = 57 × 56 ÷ 2 = 1.596 ⚠ liên hệ #26057 và #26070 lô 186
⚠ Rất nhiều nguồn có thể khởi xướng yêu cầu thay đổi
⚠ Cần quy trình CHẶT CHẼ và KÊNH RÕ RÀNG ⚠ liên hệ #26066 lô 186 — Scotty nhận thay đổi ngoài hệ thống
⚠ Việc Jesus nên làm ⚠ truyền thông quy trình thay đổi tới TẤT CẢ 57 người ngay từ đầu, và làm cho form dễ điền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu thay đổi nào của bạn làm GIẢM chi phí không | ⚠ nếu chưa từng có thì có thể chưa ai nghĩ tới việc cắt bớt | | Mọi bên liên quan có biết cách nộp yêu cầu thay đổi không | | | Người đề xuất có được thông báo kết quả không | |

Và mẹo làm bài áp dụng được cho rất nhiều câu hỏi: mệnh đề nào chứa từ "LUÔN LUÔN" hoặc "KHÔNG BAO GIỜ" thì gần như luôn là mệnh đề sai — chỉ cần nghĩ ra MỘT ngoại lệ là đủ.

Câu 368 Process
Ursula is the project manager for Project Windmill, ten weeks into a thirty-week deployment, two weeks behind schedule, and $5,000 under budget. Recently a few new stakeholders joined the project. What should Ursula do next?
  1. A Update the stakeholder register.
  2. B Invite the new stakeholders to a kickoff meeting.
  3. C Do nothing. The other stakeholders will catch the new ones up.
  4. D Tell the team about the new stakeholders.
Xem giải thích

Đáp án

A — CẬP NHẬT SỔ ĐĂNG KÝ BÊN LIÊN QUAN.

Vì sao đúng

⚠ Vì sao đây là bước ĐẦU TIÊN: | Lý do | Nội dung | |---|---| | ⚠ Sổ đăng ký là NƠI GHI NHẬN chính thức mọi bên liên quan | | | ⚠ Phải PHÂN TÍCH họ trước khi làm gì khác | ⚠ quyền lực, quan tâm, kỳ vọng, yêu cầu | | ⚠ Nhận diện bên liên quan là quy trình LẶP LẠI suốt dự án | ⚠ không làm một lần rồi thôi | | ⚠ Cập nhật sổ rồi mới lập được chiến lược gắn kết | | | ⚠ Nguyên tắc | ⚠ GHI NHẬN và PHÂN TÍCH trước, HÀNH ĐỘNG sau |

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

  • B (mời bên liên quan mới dự một buổi họp khởi động) — ⚠ phương án gây nhiễu mạnh nhất vì đó là việc hợp lý và thân thiện: ⚠ nhưng ⚠ dự án đã đi được MƯỜI TUẦN trên ba mươi ⚠ — buổi khởi động đã qua từ lâu (liên hệ #25971 lô 185); ⚠ và ⚠ chưa phân tích họ thì chưa biết nên truyền đạt gì cho ai.

  • D (báo cho đội biết về bên liên quan mới) — ⚠ việc NÊN LÀM nhưng ở bước SAU; ⚠ báo cái gì khi chưa biết họ quan tâm gì.

  • C (không làm gì, các bên liên quan khác sẽ cập nhật cho họ) — ⚠ bỏ mặc; ⚠ và thông tin truyền miệng qua người khác luôn bị méo.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26046 ở lô 186 (bỏ sót bên liên quan → liên hệ ngay, xin lỗi và phân tích) — ⚠ hai câu cùng một nguyên tắc: PHÂN TÍCH trước, hành động sau. ⚠ Xem thêm câu #26056 (mức gắn kết KHÔNG BIẾT), câu #26062 (ảnh hưởng lớn nhất ở đầu dự án), và câu #26074 (mục đích kế hoạch quản lý bên liên quan). ⚠ Nhóm bên liên quan đã lên MƯỜI HAI câu qua năm lô.

⚠ SỔ ĐĂNG KÝ BÊN LIÊN QUAN chứa gì: | Thông tin | Nội dung | |---|---| | ⚠ ĐỊNH DANH | ⚠ tên, chức vụ, vị trí, vai trò trong dự án, thông tin liên hệ | | ⚠ ĐÁNH GIÁ | ⚠ yêu cầu chính, kỳ vọng, ảnh hưởng tiềm tàng, giai đoạn quan tâm nhất | | ⚠ PHÂN LOẠI | ⚠ quyền lực/quan tâm, trong hay ngoài tổ chức, ủng hộ hay phản đối | | ⚠ Là tài liệu | ⚠ SỐNG — cập nhật liên tục suốt dự án | | ⚠ Lưu ý bảo mật | ⚠ chứa đánh giá nhạy cảm về con người — cân nhắc ai được xem |

Từ khoá nhận diện:

"bên liên quan mới tham gia" → ⚠ cập nhật sổ đăng ký trước "mời họ dự kick-off" → ⚠ kick-off đã qua khi dự án chạy được mười tuần "để người khác cập nhật cho họ" → ⚠ bỏ mặc, thông tin sẽ méo "báo cho đội" → ⚠ bước sau, khi đã biết họ là ai

⚠ Chuỗi việc đầy đủ Ursula nên làm Bước
⚠ 1. CẬP NHẬT sổ đăng ký bên liên quan ⚠ CÂU NÀY
⚠ 2. PHÂN TÍCH: quyền lực, quan tâm, kỳ vọng, yêu cầu
⚠ 3. Xác định mức gắn kết hiện tại và mong muốn ⚠ liên hệ #26056 lô 186
⚠ 4. Cập nhật KẾ HOẠCH GẮN KẾT và KẾ HOẠCH GIAO TIẾP ⚠ liên hệ #25965 lô 185
⚠ 5. Gặp họ để giới thiệu dự án và nghe kỳ vọng
⚠ 6. Thông báo cho đội ⚠ phương án D nằm ở đây
⚠ Kiểm tra thêm ⚠ họ có yêu cầu MỚI nào không — nếu có thì cần qua kiểm soát thay đổi (liên hệ #26089 cùng lô)
⚠ Vì sao bên liên quan mới xuất hiện giữa dự án Nguyên nhân
⚠ Tái cơ cấu tổ chức, thay đổi nhân sự
⚠ Dự án bước sang giai đoạn mới, chạm tới bộ phận khác
⚠ Có người trước đây bị bỏ sót, nay mới lộ ra ⚠ liên hệ #26046 lô 186
⚠ Phạm vi mở rộng kéo theo bên liên quan mới
⚠ Rủi ro nếu bỏ qua ⚠ họ có thể mang theo yêu cầu mới ở tuần thứ mười — và chi phí thay đổi lúc này đã cao (liên hệ #26062 lô 186)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ đăng ký bên liên quan của bạn cập nhật lần cuối khi nào | | | Bạn rà lại danh sách ở mỗi cổng giai đoạn không | | | Bên liên quan mới có được phân tích hay chỉ được thêm tên vào danh sách | |

Và điều dễ bị coi nhẹ trong tình huống này: hai bên liên quan mới ở tuần thứ mười có thể mang theo những yêu cầu mà nếu biết từ tuần đầu thì gần như miễn phí — còn bây giờ thì không.

Câu 369 Process
Dee-dee is the project manager for a bauxite mine in Australia. A recent project set the mining ore goal from which a baseline or a "reach goal" level of bauxite could be obtained. Because this level was met, the project was considered a success. Dee-dee notes as much in her final report for stakeholders. Which information is being used to manage the project closure?
  1. A Completion criteria
  2. B Quality objectives
  3. C Summary description
  4. D Cost objectives
Xem giải thích

Đáp án

A — TIÊU CHÍ HOÀN THÀNH (completion criteria).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Dự án ĐẶT TRƯỚC một mức sản lượng quặng cần đạt | ⚠ ngưỡng định lượng được xác định từ đầu | | ⚠ ĐẠT được mức đó thì dự án được coi là THÀNH CÔNG | ⚠ điều kiện để tuyên bố hoàn thành | | ⚠ Dee-dee ghi điều này trong BÁO CÁO CUỐI | ⚠ dùng để quản lý việc ĐÓNG dự án | | ⚠ Định nghĩa | ⚠ tiêu chí hoàn thành là các điều kiện phải thoả để dự án hoặc giai đoạn được coi là ĐÃ XONG | | ⚠ Vì sao cần | ⚠ không có tiêu chí rõ thì không ai biết khi nào được phép dừng |

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

  • B (mục tiêu chất lượng) — ⚠ phương án gây nhiễu mạnh nhất vì mức sản lượng cũng là một con số đo được: ⚠ nhưng mục tiêu chất lượng nói về ⚠ ĐẶC TÍNH của sản phẩm có đạt chuẩn không ⚠ (độ tinh khiết của quặng, tạp chất), ⚠ không phải về việc dự án có được coi là HOÀN THÀNH hay chưa.

  • D (mục tiêu chi phí) — ⚠ về ngân sách; ⚠ đề không nhắc gì tới tiền.

  • C (mô tả tóm tắt) — ⚠ một phần của báo cáo, không phải TIÊU CHÍ để đánh giá.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25977 ở lô 184 (tiêu chí chấp nhận — bản mẫu bị từ chối), câu #26097 ở lô này (Định nghĩa Hoàn thành), câu #25918 lô 183 (rà soát mục tiêu nào đã hoàn thành), và câu #25927 (hoạt động của giai đoạn đóng). ⚠ Nhóm "thế nào là xong" — và bộ đề hỏi khái niệm này ở nhiều tầng khác nhau.

⚠ BỐN khái niệm "thế nào là xong" — bảng phân biệt: | Khái niệm | Phạm vi | Ai đặt ra | |---|---|---| | ⚠ TIÊU CHÍ HOÀN THÀNH | ⚠ cả DỰ ÁN hoặc GIAI ĐOẠN — CÂU NÀY | ⚠ nhà tài trợ và bên liên quan chính | | ⚠ TIÊU CHÍ CHẤP NHẬN | ⚠ từng BÀN GIAO cụ thể | ⚠ khách hàng / product owner | | ⚠ ĐỊNH NGHĨA HOÀN THÀNH (DoD) | ⚠ CHUNG cho mọi hạng mục trong agile | ⚠ đội — liên hệ #26097 cùng lô | | ⚠ ĐỊNH NGHĨA SẴN SÀNG (DoR) | ⚠ điều kiện để hạng mục ĐƯỢC VÀO sprint | ⚠ đội và product owner | | ⚠ Điểm chung | ⚠ cả bốn đều tồn tại để trả lời một câu hỏi: khi nào thì được phép nói "xong" |

Từ khoá nhận diện:

"đạt mức X thì dự án được coi là thành công" → ⚠ tiêu chí hoàn thành "bàn giao này có đạt chuẩn để nghiệm thu không" → ⚠ tiêu chí chấp nhận "đội thống nhất thế nào là xong một hạng mục" → ⚠ Định nghĩa Hoàn thành "độ tinh khiết, dung sai, sai số cho phép" → ⚠ mục tiêu chất lượng

⚠ Vì sao tiêu chí hoàn thành phải định TRƯỚC Lý do
⚠ Tránh tranh cãi ở cuối dự án về việc đã xong hay chưa
⚠ Cho đội một ĐÍCH rõ ràng để nhắm tới
⚠ Ngăn dự án kéo dài vô hạn vì "chưa hoàn hảo" ⚠ liên hệ #25975 lô 184 — mạ vàng
⚠ Là căn cứ để giải phóng đội và đóng hợp đồng ⚠ liên hệ #25969 lô 184
⚠ Đặc điểm của tiêu chí tốt ⚠ ĐO ĐƯỢC bằng con số, như "mức sản lượng cơ sở" trong tình huống này
⚠ "Reach goal" trong đề nghĩa là gì Ý nghĩa
⚠ Mục tiêu cao hơn mức cơ sở, mang tính phấn đấu
⚠ Đặt HAI MỨC: mức tối thiểu chấp nhận được và mức mong muốn
⚠ Đạt mức cơ sở là THÀNH CÔNG; đạt mức phấn đấu là VƯỢT MỨC
⚠ Thực hành tốt ⚠ định rõ mức TỐI THIỂU để không ai tranh cãi, và mức phấn đấu để tạo động lực
⚠ Rủi ro nếu chỉ có một mức ⚠ hoặc là quá dễ (không ai cố), hoặc quá khó (ai cũng nản)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có tiêu chí hoàn thành viết ra không | | | Tiêu chí đó có ĐO ĐƯỢC không | ⚠ "khách hàng hài lòng" không phải tiêu chí đo được | | Bên liên quan đã đồng ý với tiêu chí đó chưa | ⚠ đồng ý ở ĐẦU dự án, không phải ở cuối |

Và điều một tiêu chí hoàn thành rõ ràng mang lại vào ngày cuối cùng: không ai phải tranh luận xem dự án đã xong chưa — cả hai bên chỉ cần cùng nhìn vào một con số đã thống nhất từ nhiều tháng trước.

Câu 370 Process

Alice is a new project manager, working as part of the project management office team at her organization. She is approached by a senior executive and asked to compress her project's schedule due to the very high demand for the product. Which scheduling compression techniques should Alice consider?

  1. A What-if scenario analysis
  2. B Fast-tracking and what-if scenario analysis
  3. C Crashing and fast-tracking
  4. D Schedule network analysis
Xem giải thích

Đáp án

C — CRASHING (nén bằng nguồn lực) và FAST TRACKING (làm song song).

Vì sao đúng

⚠ Hai kỹ thuật nén lịch trình: | Kỹ thuật | Cách làm | Đánh đổi | |---|---|---| | ⚠ CRASHING | ⚠ THÊM NGUỒN LỰC vào hoạt động trên đường găng | ⚠ TĂNG CHI PHÍ | | ⚠ FAST TRACKING | ⚠ làm SONG SONG các việc vốn nối tiếp | ⚠ TĂNG RỦI RO và khả năng phải làm lại | | ⚠ Điểm chung | ⚠ chỉ có tác dụng khi áp lên ĐƯỜNG GĂNG — liên hệ #25938 lô 184 | | ⚠ Và | ⚠ cả hai đều RÚT NGẮN lịch mà KHÔNG giảm phạm vi | | ⚠ Sau khi nén | ⚠ phải TÍNH LẠI đường găng — nó có thể đã chuyển sang chuỗi khác |

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

  • B (fast tracking và phân tích kịch bản "nếu-thì") — ⚠ phương án gây nhiễu mạnh nhất vì có ĐÚNG MỘT NỬA: ⚠ fast tracking đúng là kỹ thuật nén, ⚠ nhưng ⚠ phân tích kịch bản "nếu-thì" là kỹ thuật PHÂN TÍCH, không phải kỹ thuật NÉN ⚠ — nó giúp ĐÁNH GIÁ tác động của các phương án, không tự rút ngắn lịch.

  • A (chỉ phân tích kịch bản "nếu-thì") — ⚠ cùng lý do, ⚠ và thiếu luôn cả hai kỹ thuật nén.

  • D (phân tích mạng lịch trình) — ⚠ nhóm kỹ thuật để XÂY DỰNG và phân tích lịch ⚠ (đường găng, chuỗi găng, mô phỏng); ⚠ không phải kỹ thuật nén.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25665 ở lô 178 (đường găng là điều kiện cần để crashing), câu #25938 lô 184 (đường găng có độ trễ bằng không), câu #25917 lô 183 (quy luật lợi ích giảm dần khi thêm người), và câu #26075 lô 186 (quan hệ SS — làm song song). ⚠ Nhóm lịch trình.

⚠ CRASHING và FAST TRACKING — bảng so sánh chi tiết: | | CRASHING | FAST TRACKING | |---|---|---| | ⚠ Cách làm | ⚠ thêm người, thêm ca, thuê ngoài, trả thêm giờ | ⚠ gỡ liên kết TUỲ CHỌN để làm song song | | ⚠ Rủi ro chính | ⚠ chi phí tăng, và quy luật lợi ích giảm dần | ⚠ phải làm lại nếu phần trước thay đổi | | ⚠ Giới hạn | ⚠ không phải việc nào cũng chia nhỏ được | ⚠ không gỡ được liên kết BẮT BUỘC | | ⚠ Nên chọn khi | ⚠ có tiền, việc chia nhỏ được | ⚠ không có thêm tiền, chấp nhận được rủi ro | | ⚠ Thường dùng thế nào | ⚠ KẾT HỢP cả hai, và chọn hoạt động có tỷ lệ "rút ngắn trên mỗi đồng chi thêm" tốt nhất | | ⚠ Cảnh báo | ⚠ crashing chịu QUY LUẬT LỢI ÍCH GIẢM DẦN — người thứ mười hai đóng góp rất ít (liên hệ #25917 lô 183) |

Từ khoá nhận diện:

"nén lịch trình" → ⚠ crashing và fast tracking, chỉ hai kỹ thuật này "thêm người, thêm ca" → ⚠ crashing "làm song song" → ⚠ fast tracking "nếu-thì, mô phỏng, Monte Carlo" → ⚠ phân tích, không phải nén

⚠ Các cách rút ngắn lịch KHÁC — không phải nén Cách
⚠ GIẢM PHẠM VI ⚠ phải qua kiểm soát thay đổi — không phải nén lịch
⚠ Hạ tiêu chuẩn chất lượng ⚠ gần như luôn là ý tồi
⚠ Cải thiện quy trình, gỡ vật cản ⚠ thường hiệu quả hơn cả hai kỹ thuật nén
⚠ Phân biệt quan trọng ⚠ NÉN LỊCH giữ nguyên phạm vi; giảm phạm vi là chuyện khác hoàn toàn
⚠ Alice nên hỏi gì trước khi nén Câu hỏi
⚠ Đường găng hiện tại đi qua những hoạt động nào ⚠ nén chỗ khác là vô ích
⚠ Có ngân sách bổ sung không ⚠ quyết định giữa crashing và fast tracking
⚠ Mức rủi ro chấp nhận được tới đâu
⚠ Rút ngắn bao nhiêu là đủ ⚠ "càng nhanh càng tốt" không phải yêu cầu dùng được
⚠ Có liên kết TUỲ CHỌN nào gỡ được không ⚠ liên kết BẮT BUỘC thì không — liên hệ #25934 lô 184
⚠ Và quan trọng nhất ⚠ nén lịch làm đổi ĐƯỜNG CƠ SỞ — phải qua yêu cầu thay đổi (liên hệ #26089 cùng lô)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết đường găng hiện tại của mình không | ⚠ nó DI CHUYỂN khi thực tế thay đổi | | Liên kết nào trong lịch là bắt buộc, liên kết nào là tuỳ chọn | ⚠ rất nhiều dự án không phân biệt | | Nén xong bạn có tính lại đường găng không | |

Và điều một quản lý dự án cần nói rõ với lãnh đạo trước khi nén lịch: cả hai kỹ thuật đều không tạo ra thời gian — chúng chỉ đổi thời gian lấy tiền hoặc lấy rủi ro, và người ra quyết định cần biết mình đang trả bằng gì.