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

Tìm thấy 201 câu.

Câu 71
June is a project manager in her organization and she’s working with the project sponsor and the immediate project team to identify the project stakeholders. The process of stakeholder identification is best described as first happening when?
  1. A Prior to or during the project charter development and approval
  2. B When the project planning begins by the project sponsor
  3. C At the start of each project phase as directed by the PMBOK Guide
  4. D At the start of project execution but before the WBS creation
Xem giải thích

Đáp án

A — Trước hoặc trong khi phát triển và phê duyệt project charter.

Vì sao đúng

⚠ Identify Stakeholders thuộc nhóm quy trình KHỞI TẠO: | Đặc điểm | Nội dung | |---|---| | ⚠ Là một trong HAI quy trình của nhóm Initiating | ⚠ cùng với Develop Project Charter | | ⚠ Bắt đầu RẤT SỚM | ⚠ trước hoặc song song với charter | | ⚠ LẶP LẠI suốt dự án | ⚠ khi có người mới hoặc bối cảnh đổi |

⚠ Vì sao phải sớm: ⚠ charter cần danh sách bên liên quan, ⚠ và nhiều quyết định ban đầu phụ thuộc vào việc biết ai quan tâm tới dự án.

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

  • C (đầu mỗi giai đoạn theo PMBOK) — ⚠ việc RÀ SOÁT LẠI ở đầu mỗi giai đoạn là đúng, nhưng ⚠ đề hỏi LẦN ĐẦU diễn ra khi nào.

  • B (khi nhà tài trợ bắt đầu lập kế hoạch) — ⚠ quá muộn; nhận diện bên liên quan thuộc nhóm KHỞI TẠO, trước lập kế hoạch.

  • D (đầu giai đoạn thực thi) — ⚠ muộn hơn nữa.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25577 ở lô trước hỏi tài liệu nào giúp nhận diện bên liên quan (benefits management plan). ⚠ Câu này hỏi KHI NÀO. Hai câu bổ sung nhau.

⚠ Hai quy trình của nhóm Initiating: | Quy trình | Lĩnh vực | |---|---| | ⚠ Develop Project Charter | ⚠ Integration Management | | ⚠ Identify Stakeholders | ⚠ Stakeholder Management | | ⚠ Chỉ có hai | ⚠ đây là điểm hay hỏi |

⚠ Bốn quy trình quản lý bên liên quan: | Quy trình | Nhóm | |---|---| | ⚠ Identify Stakeholders | ⚠ Initiating | | ⚠ Plan Stakeholder Engagement | ⚠ Planning | | ⚠ Manage Stakeholder Engagement | ⚠ Executing | | ⚠ Monitor Stakeholder Engagement | ⚠ Monitoring and Controlling |

Từ khoá nhận diện:

"lần đầu nhận diện bên liên quan" → ⚠ trước hoặc trong khi lập charter "rà soát lại" → ⚠ đầu mỗi giai đoạn và khi có thay đổi "danh sách và phân loại" → ⚠ stakeholder register "mức tham gia hiện tại và mong muốn" → ⚠ engagement assessment matrix

⚠ Hậu quả khi nhận diện MUỘN Hậu quả
⚠ Yêu cầu mới xuất hiện khi đã lập kế hoạch xong
⚠ Người phản đối không được xử lý sớm
⚠ Thay đổi càng muộn càng đắt
⚠ Có thể phải làm lại phạm vi
⚠ Đây là ⚠ một trong những nguyên nhân thất bại phổ biến nhất của dự án
⚠ Ai dễ bị bỏ sót khi nhận diện Nhóm
⚠ Người dùng cuối ⚠ khác với người MUA
⚠ Bộ phận vận hành sẽ tiếp nhận sản phẩm
⚠ Bộ phận pháp chế và tuân thủ
⚠ Nhóm phản đối dự án ⚠ hay bị lờ đi vì khó chịu
⚠ Đối tác và nhà cung cấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ phận vận hành đã được đưa vào chưa | ⚠ họ sẽ sống với sản phẩm lâu nhất | | Có nhóm phản đối nào chưa được ghi nhận không | | | Register có được rà soát ở đầu mỗi giai đoạn không | |

Và nhóm bên liên quan bị bỏ sót nhiều nhất trong thực tế: bộ phận sẽ VẬN HÀNH sản phẩm sau khi dự án kết thúc. Họ không tham gia lúc lập kế hoạch nhưng lại là người sống với kết quả lâu nhất — và bỏ qua họ thường dẫn tới một sản phẩm khó vận hành.

Câu 72
Ray is a project manager in his organization and he’s leading a Scrum-based project. In this project, Ray needs to define with the project team how long each project iteration should take. What term best describes the duration of an iteration in a Scrum project?
  1. A Rolling wave planning
  2. B Increment
  3. C Iteration
  4. D Timeboxed period
Xem giải thích

Đáp án

D — Timeboxed period (khoảng thời gian đóng khung).

Vì sao đúng

⚠ Timebox — khoảng thời gian CỐ ĐỊNH, không đổi: | Đặc điểm | Nội dung | |---|---| | ⚠ Độ dài CỐ ĐỊNH | ⚠ thường 1 tới 4 tuần | | ⚠ KHÔNG kéo dài dù chưa xong việc | ⚠ việc chưa xong quay lại backlog | | ⚠ Giữ nhịp ổn định cho đội | | | ⚠ Tạo điểm kiểm tra và phản hồi đều đặn | |

⚠ Nguyên tắc cốt lõi: ⚠ thời gian CỐ ĐỊNH, phạm vi LINH HOẠT — ⚠ ngược với dự án dự đoán, nơi phạm vi cố định và thời gian co giãn.

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

  • C (Iteration) — ⚠ là TÊN GỌI của chính vòng lặp, không phải thuật ngữ mô tả thời lượng của nó.

  • B (Increment) — ⚠ là SẢN PHẨM GIA TĂNG tạo ra sau mỗi vòng lặp.

  • A (Rolling wave planning) — ⚠ kỹ thuật lập kế hoạch chi tiết dần, không phải khái niệm về thời lượng vòng lặp.

Ghi nhớ

⚠ Các sự kiện của Scrum — đều là timebox: | Sự kiện | Thời lượng cho sprint 1 tháng | |---|---| | ⚠ Sprint | ⚠ tối đa 1 tháng | | ⚠ Sprint Planning | ⚠ tối đa 8 giờ | | ⚠ Daily Scrum | ⚠ 15 phút | | ⚠ Sprint Review | ⚠ tối đa 4 giờ | | ⚠ Sprint Retrospective | ⚠ tối đa 3 giờ | | ⚠ Sprint ngắn hơn | ⚠ các sự kiện cũng ngắn theo tỷ lệ |

⚠ Ba tạo tác của Scrum: | Tạo tác | Nội dung | |---|---| | ⚠ Product Backlog | ⚠ toàn bộ yêu cầu, có thứ tự ưu tiên | | ⚠ Sprint Backlog | ⚠ phần đội cam kết cho sprint này | | ⚠ Increment | ⚠ sản phẩm gia tăng có thể dùng được |

Từ khoá nhận diện:

"thời lượng cố định của vòng lặp" → ⚠ timebox "sản phẩm tạo ra sau vòng lặp" → ⚠ increment "lập kế hoạch chi tiết dần" → ⚠ rolling wave planning "tiêu chí để coi là xong" → ⚠ definition of done

⚠ Vì sao timebox lại hiệu quả Lý do
⚠ Tạo nhịp làm việc bền vững
⚠ Buộc ưu tiên — không đủ thời gian cho mọi thứ
⚠ Phản hồi đều đặn, phát hiện sai sớm
⚠ Dễ dự báo năng suất ⚠ velocity ổn định qua các sprint
⚠ Nguyên tắc ⚠ KHÔNG BAO GIỜ kéo dài sprint để cố hoàn thành
⚠ Việc chưa xong khi hết sprint thì sao Xử lý
⚠ KHÔNG kéo dài sprint
⚠ Đưa việc chưa xong về product backlog
⚠ Product Owner sắp xếp lại ưu tiên
⚠ Bàn trong retrospective vì sao ước lượng lệch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sprint có bao giờ bị kéo dài không | ⚠ nếu có thì timebox đã mất ý nghĩa | | Velocity có ổn định qua các sprint không | | | Definition of done đã rõ và thống nhất chưa | |

Và nguyên tắc quan trọng nhất của timebox, cũng là nguyên tắc hay bị vi phạm nhất: không bao giờ kéo dài sprint. Một lần nhân nhượng là timebox mất hết giá trị, và đội quay lại thói quen "làm tới khi xong" — thứ mà cách tiếp cận linh hoạt sinh ra để thay thế.

Câu 73
You are a project manager for the GHB Corporation and you’re working with your project sponsor to discuss a recent project that wasn’t successful. Several of the product testers missed defects that affected lines of business in the organization. The project sponsor wants to know who is responsible for the project as a whole. What’s the best answer?
  1. A You, the project manager, are ultimately responsible
  2. B In this case, the product testers are responsible
  3. C The project team is responsible for the project
  4. D The project team and the project manager are responsible
Xem giải thích

Đáp án

A — Bạn, quản lý dự án, là người chịu trách nhiệm cuối cùng.

Vì sao đúng

⚠ Nguyên tắc trách nhiệm trong quản lý dự án: | Nguyên tắc | Nội dung | |---|---| | ⚠ Quản lý dự án chịu trách nhiệm cuối cùng cho TOÀN BỘ dự án | | | ⚠ Bao gồm cả kết quả công việc của đội | | | ⚠ Kể cả khi lỗi do một cá nhân gây ra | | | ⚠ PM chịu trách nhiệm về HỆ THỐNG | ⚠ quy trình kiểm thử, phân công, giám sát |

⚠ Đây chính là ý nghĩa của chữ A trong RACI — ⚠ accountable, chỉ một người, và với cả dự án thì đó là quản lý dự án.

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

  • B (người kiểm thử chịu trách nhiệm) — ⚠ họ chịu trách nhiệm về CÔNG VIỆC của họ — chữ R, ⚠ nhưng không phải cho cả dự án.

  • C (đội dự án chịu trách nhiệm) — ⚠ trách nhiệm tập thể là KHÔNG có ai chịu trách nhiệm.

  • D (đội và PM cùng chịu trách nhiệm) — ⚠ làm mờ ranh giới; ⚠ đề hỏi ai chịu trách nhiệm cho TOÀN BỘ dự án — câu trả lời phải là một người.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25546 ở lô trước nói mỗi hoạt động chỉ MỘT người mang chữ A. ⚠ Câu này áp nguyên tắc đó lên cấp toàn dự án. Hai câu nhất quán.

⚠ Phân biệt hai chữ trong RACI: | Chữ | Câu hỏi | Ở đây | |---|---|---| | ⚠ R — Responsible | ⚠ ai LÀM | ⚠ người kiểm thử | | ⚠ A — Accountable | ⚠ ai TRẢ LỜI khi hỏng | ⚠ quản lý dự án |

⚠ Nhưng chịu trách nhiệm KHÔNG có nghĩa là đổ lỗi cho mình: | Việc PM nên làm | Nội dung | |---|---| | ⚠ Nhận trách nhiệm trước nhà tài trợ | ⚠ không đổ cho đội | | ⚠ Phân tích NGUYÊN NHÂN GỐC | ⚠ vì sao quy trình để lọt lỗi | | ⚠ Sửa quy trình, không chỉ sửa người | | | ⚠ Ghi vào lessons learned | | | ⚠ Deming | ⚠ phần lớn vấn đề đến từ HỆ THỐNG, không từ con người |

Từ khoá nhận diện:

"chịu trách nhiệm cho cả dự án" → ⚠ quản lý dự án "làm công việc cụ thể" → ⚠ thành viên đội, chữ R "phê duyệt và cấp nguồn lực" → ⚠ nhà tài trợ "trách nhiệm tập thể" → ⚠ thường nghĩa là KHÔNG ai chịu trách nhiệm

⚠ Câu hỏi nên đặt khi có lỗi lọt ra Câu hỏi
⚠ Quy trình kiểm thử có đủ không
⚠ Người kiểm thử có được đào tạo đủ không
⚠ Có đủ thời gian để kiểm thử không ⚠ hay bị ép tiến độ
⚠ Tiêu chí nghiệm thu có rõ ràng không
⚠ Chú ý ⚠ ba trong bốn câu trên chỉ về trách nhiệm của PM
⚠ Trách nhiệm của nhà tài trợ Trách nhiệm
⚠ Cấp nguồn lực và ngân sách
⚠ Gỡ vướng ở cấp tổ chức
⚠ Phê duyệt thay đổi lớn
⚠ Nhưng ⚠ trách nhiệm điều hành hằng ngày vẫn thuộc PM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã phân tích nguyên nhân gốc chưa | ⚠ hay chỉ tìm người để trách | | Quy trình có được sửa để lần sau không lặp lại không | | | Đội có bị ép tiến độ tới mức bỏ qua kiểm thử không | |

Và cách phân biệt một quản lý dự án giỏi khi có sự cố: họ nhận trách nhiệm trước cấp trên và bảo vệ đội, rồi cùng đội sửa quy trình. Đổ lỗi cho người kiểm thử là dễ nhất — và cũng là cách chắc chắn nhất để lỗi đó lặp lại.

Câu 74
Management has just approached you about some defects that were found by the customer during an inspection. Management is unhappy about these defects and needs these addressed immediately by you and the project team. These defects are specifically known as what term?
  1. A Internal defects
  2. B Poor defects
  3. C Sensitive defects
  4. D External defects
Xem giải thích

Đáp án

D — External defects (lỗi bên ngoài).

Vì sao đúng

⚠ Phân loại lỗi theo NƠI PHÁT HIỆN: | Loại | Ai phát hiện | Chi phí | |---|---|---| | ⚠ Internal defect | ⚠ đội dự án, trong nội bộ | ⚠ thấp hơn | | ⚠ External defect | ⚠ KHÁCH HÀNG, sau khi giao | ⚠ CAO NHẤT |

⚠ Đề nói rõ: ⚠ lỗi được khách hàng phát hiện trong buổi kiểm tra → ⚠ đó là external defect.

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

  • A (internal defects) — ⚠ là lỗi do ĐỘI tự phát hiện trước khi giao.

  • B (poor defects) và C (sensitive defects) — ⚠ không phải thuật ngữ chuẩn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25562 ở lô trước hỏi vì sao để khách phát hiện lỗi là cách tệ nhất (vì tốn kém nhất). ⚠ Câu này hỏi TÊN GỌI của loại lỗi đó. Hai câu bổ sung nhau.

⚠ Cost of Quality — bốn nhóm: | Nhóm | Thành phần | Thời điểm | |---|---|---| | ⚠ Prevention | ⚠ đào tạo, quy trình, thiết kế đúng | ⚠ trước khi làm | | ⚠ Appraisal | ⚠ kiểm thử, kiểm tra, đánh giá | ⚠ trong khi làm | | ⚠ Internal failure | ⚠ làm lại, phế phẩm | ⚠ phát hiện nội bộ | | ⚠ External failure | ⚠ bảo hành, thu hồi, mất uy tín, kiện tụng | ⚠ khách phát hiện |

⚠ Hai nhóm đầu là cost of CONFORMANCE — chi để làm đúng. ⚠ Hai nhóm sau là cost of NON-CONFORMANCE — chi vì làm sai.

⚠ Vì sao external failure đắt nhất: | Chi phí | Nội dung | |---|---| | ⚠ Sửa chính lỗi đó | | | ⚠ Thu hồi hoặc triển khai lại | | | ⚠ Hỗ trợ và xử lý khiếu nại | | | ⚠ Mất uy tín và có thể mất khách | | | ⚠ Có thể bị phạt hợp đồng | | | ⚠ Chi phí gián tiếp | ⚠ thường lớn hơn chi phí trực tiếp nhiều lần |

Từ khoá nhận diện:

"khách hàng phát hiện" → ⚠ external defect, external failure cost "đội tự phát hiện" → ⚠ internal defect "chi để phòng ngừa và kiểm tra" → ⚠ cost of conformance "chi vì lỗi" → ⚠ cost of non-conformance

⚠ Việc nên làm ngay khi có external defect Việc
⚠ Xử lý lỗi cho khách trước ⚠ giữ quan hệ
⚠ Phân tích nguyên nhân gốc ⚠ vì sao quy trình để lọt
⚠ Kiểm tra xem còn lỗi tương tự ở đâu không
⚠ Sửa quy trình kiểm thử
⚠ Ghi vào lessons learned
⚠ Đừng chỉ ⚠ sửa lỗi rồi đi tiếp — lỗi sẽ quay lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ lỗi lọt ra khách là bao nhiêu | ⚠ defect escape rate | | Chi phí phòng ngừa có được đầu tư đủ không | | | Có phân tích nguyên nhân gốc cho mỗi lỗi lọt ra không | |

Và chỉ số chất lượng đáng theo dõi nhất trong mọi dự án: tỷ lệ lỗi lọt ra tới khách hàng. Nó phản ánh trực tiếp chất lượng của quy trình kiểm thử — và mỗi lỗi trong con số đó đều đắt gấp nhiều lần một lỗi bắt được từ trong.

Câu 75
As a project manager, you need several different skills to be effective. One skill is communication. According to some research cited in the PMBOK Guide, sixth edition, project managers spend how much of their time communicating?
  1. A 80 percent
  2. B 50 percent
  3. C 90 percent
  4. D 20 percent
Xem giải thích

Đáp án

C — 90 phần trăm.

Vì sao đúng

⚠ Con số được PMBOK dẫn lại: | Nội dung | Chi tiết | |---|---| | ⚠ Quản lý dự án dành khoảng 90% thời gian để GIAO TIẾP | | | ⚠ Bao gồm | ⚠ họp, viết báo cáo, email, trao đổi, đàm phán, thuyết trình | | ⚠ Nghĩa là | ⚠ chỉ khoảng 10% thời gian cho việc "kỹ thuật" thuần tuý |

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

  • A (80%), B (50%), D (20%) — ⚠ không khớp con số PMBOK nêu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25590 trong lô này nói 2% quản lý dự án xuất sắc nổi bật nhờ kỹ năng quan hệ và giao tiếp. ⚠ Con số 90% giải thích VÌ SAO điều đó lại đúng. Hai câu bổ sung nhau.

⚠ Con số 90% chia ra thế nào trong thực tế: | Hoạt động | Nội dung | |---|---| | ⚠ Họp | ⚠ họp đội, họp bên liên quan, họp nhà tài trợ | | ⚠ Viết | ⚠ báo cáo, email, tài liệu, cập nhật kế hoạch | | ⚠ Trao đổi trực tiếp | ⚠ gỡ vướng, giải quyết vấn đề | | ⚠ Lắng nghe | ⚠ phần quan trọng nhất và hay bị coi nhẹ | | ⚠ Đàm phán | ⚠ nguồn lực, phạm vi, hạn chót |

⚠ Hệ quả thực tế của con số này: | Hệ quả | Nội dung | |---|---| | ⚠ Kế hoạch truyền thông KHÔNG phải thủ tục hình thức | ⚠ nó là công cụ làm việc hằng ngày | | ⚠ Đầu tư vào kỹ năng giao tiếp có hiệu quả cao nhất | | | ⚠ Số kênh giao tiếp tăng theo bình phương số người | ⚠ n(n−1)/2 | | ⚠ Chọn phương tiện phù hợp giúp tiết kiệm rất nhiều thời gian | |

Từ khoá nhận diện:

"90% thời gian" → ⚠ dành cho giao tiếp "2% xuất sắc nhất" → ⚠ kỹ năng quan hệ và giao tiếp "năm chữ C" → ⚠ chất lượng thông điệp viết "số kênh giao tiếp" → ⚠ n(n−1)/2

⚠ Cách dùng 90% đó cho hiệu quả Cách
⚠ Có kế hoạch truyền thông rõ ràng ⚠ ai nhận gì, khi nào, bằng cách nào
⚠ Chọn đúng phương tiện ⚠ tin xấu thì gặp trực tiếp
⚠ Dùng kênh pull cho số đông ⚠ wiki, dashboard
⚠ Họp ít hơn nhưng có chuẩn bị hơn
⚠ Lắng nghe chủ động ⚠ xác nhận lại điều đã nghe
⚠ Dấu hiệu giao tiếp đang có vấn đề Dấu hiệu
⚠ Cùng một câu hỏi được hỏi đi hỏi lại
⚠ Bên liên quan bất ngờ trước tin đã được thông báo
⚠ Đội không biết ưu tiên hiện tại là gì
⚠ Quyết định bị đảo ngược vì thiếu thông tin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có kế hoạch truyền thông không, và có ai dùng không | | | Thông tin gửi đi có ai đọc không | | | Bên liên quan có bao giờ bất ngờ không | ⚠ bất ngờ là dấu hiệu truyền thông thất bại |

Và điều con số 90% muốn nói: quản lý dự án về bản chất là một nghề giao tiếp. Ai bước vào nghề này với kỳ vọng dành phần lớn thời gian cho lập kế hoạch và phân tích thường sẽ ngạc nhiên ngay trong tuần đầu tiên.

Câu 76
You are the project manager of the NLK Project for your organization. Your project is scheduled to last for 37 days, starts on a Wednesday, and you’ll not work any weekends on the project. Valerie, your project sponsor, needs to know on what day of the week the project will complete as it may affect some business processes they do. Based on this information, what day of the week will your project complete?
  1. A Wednesday
  2. B Tuesday
  3. C Thursday
  4. D Friday
Xem giải thích

Đáp án

C — Thứ Năm.

Vì sao đúng

⚠ Cách tính: | Bước | Nội dung | |---|---| | ⚠ Một tuần làm việc có 5 ngày | ⚠ Thứ Hai đến Thứ Sáu | | ⚠ Ngày 1 là Thứ Tư | | | ⚠ Chu kỳ lặp lại sau mỗi 5 ngày làm việc | | | ⚠ Lấy (37 − 1) chia 5 lấy dư | ⚠ 36 ÷ 5 = 7 dư 1 | | ⚠ Đếm 1 ngày làm việc từ Thứ Tư | ⚠ Thứ Tư → Thứ Năm | | ⚠ Kết quả | ⚠ THỨ NĂM |

⚠ Kiểm chứng bằng cách liệt kê: | Ngày làm việc | Thứ | |---|---| | ⚠ 1 | ⚠ Tư | | ⚠ 2 | ⚠ Năm | | ⚠ 3 | ⚠ Sáu | | ⚠ 4 | ⚠ Hai | | ⚠ 5 | ⚠ Ba | | ⚠ 6 | ⚠ Tư — chu kỳ lặp lại | | ⚠ Vậy | ⚠ ngày 36 là Thứ Tư, ngày 37 là THỨ NĂM |

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

  • A (Thứ Tư) — ⚠ là ngày 36, lệch một ngày.

  • B (Thứ Ba) — ⚠ là ngày 35.

  • D (Thứ Sáu) — ⚠ là ngày 38.

Ghi nhớ

⚠ Mẹo tính nhanh dạng bài này: | Bước | Nội dung | |---|---| | ⚠ 1. Xác định số ngày làm việc mỗi tuần | ⚠ thường là 5 | | ⚠ 2. Lấy (N − 1) chia cho 5, lấy DƯ | ⚠ trừ 1 vì ngày đầu tiên đã là ngày 1 | | ⚠ 3. Đếm số dư đó từ ngày bắt đầu | ⚠ bỏ qua cuối tuần |

⚠ Sai lầm phổ biến: ⚠ quên trừ 1, ⚠ dẫn tới lệch một ngày.

⚠ Khái niệm liên quan trong lập lịch: | Khái niệm | Nội dung | |---|---| | ⚠ Project calendar | ⚠ ngày làm việc của cả dự án | | ⚠ Resource calendar | ⚠ ngày làm việc của từng nguồn lực — nghỉ phép, ca kíp | | ⚠ Duration | ⚠ số ngày LÀM VIỆC — không tính cuối tuần và nghỉ lễ | | ⚠ Elapsed time | ⚠ số ngày LỊCH — tính cả cuối tuần | | ⚠ Đề này | ⚠ dùng duration, không phải elapsed time |

Từ khoá nhận diện:

"không làm cuối tuần" → ⚠ duration tính theo ngày làm việc "ngày lịch, tính cả cuối tuần" → ⚠ elapsed time "nghỉ phép của một người" → ⚠ resource calendar "ngày nghỉ lễ chung" → ⚠ project calendar

⚠ Vì sao phân biệt duration và elapsed time lại quan trọng Lý do
⚠ Bê tông khô cần 3 ngày LỊCH ⚠ kể cả cuối tuần — elapsed
⚠ Lập trình cần 3 ngày LÀM VIỆC ⚠ duration
⚠ Nhầm lẫn hai loại ⚠ làm lịch sai vài ngày mà không ai nhận ra
⚠ Phần mềm lập lịch ⚠ thường có tuỳ chọn riêng cho từng loại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch dự án đã khai đúng ngày nghỉ lễ chưa | | | Có hoạt động nào tính theo ngày lịch không | ⚠ chờ khô, chờ giao hàng | | Đã trừ 1 khi tính chu kỳ chưa | |

Và lỗi tính toán phổ biến nhất ở dạng bài này: quên rằng ngày bắt đầu đã là ngày thứ nhất. Cộng thẳng 37 ngày từ thứ Tư sẽ ra kết quả lệch đúng một ngày.

Câu 77
Maria is a project manager and she is nearing the end of the GHY Project. Joseph, a project team member, reports that he’ll be done with the final project tasks in the next two days. Maria is reviewing the project budget and she realizes that there is $28,000 still left in the project budget. She decides that she will add several features to the project that the customer isn’t expecting as a surprise. These features will make the product more attractive and will definitely add value to the finished product. She confers with the project team and they agree they can complete these features by the project deadline. What best describes this scenario?
  1. A Scope validation
  2. B Scope creep
  3. C Value-added change
  4. D Gold plating
Xem giải thích

Đáp án

D — Gold plating (mạ vàng).

Vì sao đúng

⚠ Gold plating — thêm thứ khách hàng KHÔNG yêu cầu: | Đặc điểm | Nội dung | |---|---| | ⚠ Đội TỰ QUYẾT định thêm tính năng | | | ⚠ Khách hàng KHÔNG yêu cầu | ⚠ thậm chí không biết | | ⚠ Không qua quy trình kiểm soát thay đổi | | | ⚠ Thường với ý định TỐT | ⚠ "tặng thêm giá trị cho khách" | | ⚠ Nhưng bị coi là THỰC HÀNH XẤU | |

⚠ Đúng tình huống của Maria: ⚠ còn tiền dư, ⚠ thêm tính năng như một bất ngờ cho khách.

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

  • B (Scope creep) — ⚠ phạm vi phình ra do YÊU CẦU BÊN NGOÀI len vào mà không qua kiểm soát; ⚠ ở đây chính ĐỘI tự thêm, nên là gold plating.

  • C (Value-added change) — ⚠ không phải thuật ngữ chuẩn; và nếu là thay đổi thật thì phải qua change control.

  • A (Scope validation) — ⚠ là quy trình khách hàng nghiệm thu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25564 ở lô trước phân biệt quality và grade, và có nhắc gold plating là thêm cấp độ khách không đòi. ⚠ Câu này là một tình huống điển hình. Hai câu bổ sung nhau.

⚠ Gold plating và scope creep — phân biệt bằng NGUỒN GỐC: | Khái niệm | Ai gây ra | |---|---| | ⚠ Gold plating | ⚠ ĐỘI DỰ ÁN tự thêm | | ⚠ Scope creep | ⚠ yêu cầu từ BÊN NGOÀI len vào không kiểm soát | | ⚠ Điểm chung | ⚠ cả hai đều là phạm vi thay đổi KHÔNG qua phê duyệt |

⚠ Vì sao gold plating là thực hành XẤU: | Lý do | Nội dung | |---|---| | ⚠ Tiêu tốn thời gian và tiền cho việc không ai yêu cầu | | | ⚠ Thêm rủi ro và lỗi | ⚠ mã mới, tính năng mới, chưa được kiểm thử kỹ | | ⚠ Khách có thể KHÔNG THÍCH | ⚠ hoặc phải bảo trì thứ họ không cần | | ⚠ Tạo tiền lệ xấu về kiểm soát phạm vi | | | ⚠ Có thể vi phạm hợp đồng | ⚠ bàn giao khác đặc tả | | ⚠ Tiền dư | ⚠ nên TRẢ LẠI tổ chức, không phải tiêu cho hết |

Từ khoá nhận diện:

"đội tự thêm tính năng" → ⚠ gold plating "yêu cầu bên ngoài len vào" → ⚠ scope creep "thay đổi có phê duyệt" → ⚠ approved change request, hoàn toàn hợp lệ "khách nghiệm thu" → ⚠ Validate Scope

⚠ Maria nên làm gì thay vào đó Việc
⚠ Bàn giao ĐÚNG phạm vi đã thoả thuận
⚠ Nếu tính năng thật sự có giá trị, ĐỀ XUẤT chính thức ⚠ qua change request
⚠ Để khách hàng quyết định ⚠ họ mới là người biết mình cần gì
⚠ Trả lại phần ngân sách dư ⚠ đó là thành tích, không phải thất bại
⚠ Nguyên tắc ⚠ kết thúc dưới ngân sách là điều TỐT, không cần tiêu cho hết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tính năng nào trong sản phẩm không truy được về yêu cầu không | ⚠ dùng ma trận truy vết | | Đội có thói quen "làm thêm cho đẹp" không | | | Ngân sách dư được xử lý thế nào | |

Và quan niệm sai lầm đứng sau hầu hết các trường hợp gold plating: nghĩ rằng tiêu hết ngân sách là bắt buộc. Hoàn thành dưới ngân sách là một kết quả tốt cần được báo cáo, không phải một khoảng trống cần lấp bằng tính năng thừa.

Câu 78
In project integration management the process to close the project or phase creates four outputs. Which one of the following is not one of the four outputs of closing the project or phase?
  1. A Project documents updates
  2. B Final report
  3. C Final project team assessment
  4. D Final product
Xem giải thích

Đáp án

C — Đánh giá cuối cùng về đội dự án (final project team assessment).

Vì sao đúng

⚠ Bốn đầu ra của Close Project or Phase: | Đầu ra | Nội dung | |---|---| | ⚠ Project documents updates | ⚠ cập nhật tài liệu, đặc biệt là lessons learned register | | ⚠ Final product, service, or result transition | ⚠ bàn giao sản phẩm cuối cho vận hành hoặc khách hàng | | ⚠ Final report | ⚠ báo cáo tổng kết hiệu suất dự án | | ⚠ Organizational process assets updates | ⚠ cập nhật tài sản quy trình của tổ chức |

⚠ "Đánh giá đội dự án" không nằm trong danh sách — ⚠ đánh giá hiệu suất đội thuộc quy trình Manage Team trong nhóm THỰC THI.

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

  • A (project documents updates), B (final report), D (final product) — ⚠ đều là ba trong bốn đầu ra chính thức.

Ghi nhớ

⚠ Các hoạt động khi đóng dự án: | Hoạt động | Nội dung | |---|---| | ⚠ Xác nhận công việc đã hoàn thành theo yêu cầu | | | ⚠ Hoàn tất mọi hoạt động mua sắm | ⚠ đóng hợp đồng | | ⚠ Nhận nghiệm thu chính thức từ khách hàng | | | ⚠ Ghi và lưu trữ lessons learned | | | ⚠ Bàn giao sản phẩm | | | ⚠ Giải phóng nguồn lực | | | ⚠ Lưu trữ hồ sơ dự án | | | ⚠ Đánh giá sự hài lòng của bên liên quan | |

⚠ Vì sao lessons learned quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Là TÀI SẢN QUY TRÌNH của tổ chức | | | ⚠ Dự án sau tránh được sai lầm cũ | | | ⚠ Nên ghi SUỐT dự án, không chỉ lúc đóng | | | ⚠ Sai lầm phổ biến | ⚠ để tới cuối mới ghi, khi mọi người đã quên chi tiết |

Từ khoá nhận diện:

"đầu ra của đóng dự án" → ⚠ bốn thứ: tài liệu cập nhật, bàn giao, báo cáo cuối, OPA cập nhật "đánh giá hiệu suất đội" → ⚠ Manage Team, nhóm Executing "đóng hợp đồng" → ⚠ một phần của Close Project or Phase "bài học kinh nghiệm" → ⚠ ghi suốt dự án, lưu vào OPA khi đóng

⚠ Dự án bị HUỶ thì có đóng không Có
⚠ VẪN phải thực hiện Close Project or Phase
⚠ Ghi rõ lý do huỷ
⚠ Lưu lại công việc đã làm ⚠ có thể dùng lại sau
⚠ Lessons learned vẫn phải ghi ⚠ dự án thất bại thường cho bài học giá trị nhất
⚠ Bỏ qua bước đóng ⚠ là mất toàn bộ tri thức đã tích luỹ
⚠ Final report gồm gì Nội dung
⚠ Tóm tắt dự án hoặc giai đoạn
⚠ Mục tiêu phạm vi và tiêu chí đánh giá
⚠ Mục tiêu chất lượng và kết quả thực tế
⚠ Mục tiêu chi phí và lịch, so với thực tế
⚠ Xác nhận lợi ích đã đạt hay chưa
⚠ Tóm tắt rủi ro và vấn đề đã xảy ra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có nghiệm thu chính thức bằng văn bản chưa | | | Lessons learned đã lưu vào kho của tổ chức chưa | | | Hợp đồng với nhà cung cấp đã đóng đủ chưa | |

Và bước hay bị bỏ qua nhất khi dự án kết thúc, đặc biệt khi ai cũng đã chuyển sang dự án mới: ghi và lưu bài học kinh nghiệm. Tri thức đắt nhất của một dự án thường biến mất trong đúng hai tuần sau khi đội giải tán.

Câu 79
You are a project manager for the KHAA Organization and you’re working with the project team to define the project scope management plan. You’re using historical information to adopt a similar project to the current project to define the scope management plan. In your plan, however, you know that you will need to define four key processes. All of the following are processes you should define in the project except for which one?
  1. A A process that specifies how formal acceptance of the completed project deliverables will be obtained
  2. B A process that establishes how the project manager can modify the scope requirements
  3. C A process for preparing a project scope statement
  4. D A process that enables the creation of the WBS from the detailed project scope statement
Xem giải thích

Đáp án

B — Quy trình quy định cách QUẢN LÝ DỰ ÁN có thể tự sửa đổi các yêu cầu về phạm vi.

Vì sao đúng

⚠ Đây là điều KHÔNG được có — ⚠ và đề hỏi cái nào không thuộc.

Vấn đề Nội dung
⚠ PM KHÔNG được tự ý sửa phạm vi
⚠ Mọi thay đổi phạm vi phải qua INTEGRATED CHANGE CONTROL
⚠ Change Control Board hoặc người có thẩm quyền quyết định
⚠ Nếu PM tự sửa được ⚠ baseline mất hết ý nghĩa

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

⚠ Ba phương án còn lại đều là quy trình mà scope management plan PHẢI định nghĩa: | Phương án | Nội dung | |---|---| | ⚠ A — cách nhận nghiệm thu chính thức | ⚠ liên quan Validate Scope | | ⚠ C — cách soạn scope statement | ⚠ liên quan Define Scope | | ⚠ D — cách tạo WBS từ scope statement | ⚠ liên quan Create WBS |

⚠ Phương án còn thiếu trong bốn quy trình là cách kiểm soát yêu cầu thay đổi phạm vi — ⚠ nhưng đó là kiểm soát qua quy trình chính thức, không phải "PM tự sửa".

Ghi nhớ

⚠ Scope management plan định nghĩa bốn thứ: | Quy trình | Nội dung | |---|---| | ⚠ Cách soạn project scope statement | | | ⚠ Cách tạo WBS từ scope statement | | | ⚠ Cách duy trì và phê duyệt scope baseline | | | ⚠ Cách nhận nghiệm thu chính thức sản phẩm bàn giao | |

⚠ Sáu quy trình quản lý phạm vi: | Quy trình | Nhóm | |---|---| | ⚠ Plan Scope Management | ⚠ Planning | | ⚠ Collect Requirements | ⚠ Planning | | ⚠ Define Scope | ⚠ Planning | | ⚠ Create WBS | ⚠ Planning | | ⚠ Validate Scope | ⚠ M&C | | ⚠ Control Scope | ⚠ M&C |

Từ khoá nhận diện:

"PM tự sửa phạm vi" → ⚠ SAI, phải qua change control "nghiệm thu chính thức" → ⚠ Validate Scope "kiểm soát thay đổi phạm vi" → ⚠ Control Scope "phạm vi phình ra không kiểm soát" → ⚠ scope creep

⚠ Quy trình kiểm soát thay đổi tích hợp Bước
⚠ Nhận change request
⚠ Đánh giá ảnh hưởng lên phạm vi, lịch, chi phí, chất lượng, rủi ro
⚠ Change Control Board quyết định ⚠ duyệt, từ chối, hoặc hoãn
⚠ Cập nhật baseline nếu duyệt
⚠ Thông báo bên liên quan
⚠ Ghi vào change log
⚠ Vì sao PM không được tự sửa baseline Lý do
⚠ Baseline là CAM KẾT với tổ chức và khách hàng
⚠ Sửa được tuỳ ý thì không đo được hiệu suất
⚠ Mất tính minh bạch và khả năng kiểm toán
⚠ Đây là ⚠ lý do tồn tại của Change Control Board

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có change log không và có được cập nhật không | | | Ai có thẩm quyền duyệt thay đổi phạm vi | | | Có thay đổi nào đã thực hiện mà chưa qua phê duyệt không | |

Và ranh giới không được vượt qua trong quản lý phạm vi: PM đề xuất thay đổi, nhưng KHÔNG tự phê duyệt. Ngay khi ranh giới đó mờ đi, baseline trở thành một con số trang trí và không còn ai biết dự án đang đi đúng hay lệch.

Câu 80
You are a project manager for the ARQ Company, and you’re working with your project management office to learn about the required templates, forms, and tools all project managers in your organization must use. What type of project management office are you working with in this scenario?
  1. A Controlling
  2. B Supportive
  3. C Directive
  4. D Enterprise
Xem giải thích

Đáp án

A — Controlling PMO.

Vì sao đúng

⚠ Ba kiểu PMO theo mức kiểm soát: | Kiểu | Mức kiểm soát | Đặc trưng | |---|---|---| | ⚠ Supportive | ⚠ THẤP | ⚠ CUNG CẤP mẫu, tư vấn, đào tạo — không bắt buộc dùng | | ⚠ Controlling | ⚠ TRUNG BÌNH | ⚠ YÊU CẦU tuân thủ khung, mẫu, quy trình | | ⚠ Directive | ⚠ CAO | ⚠ TRỰC TIẾP quản lý dự án, PM thuộc PMO |

⚠ Đề nói rõ: ⚠ mẫu, biểu mẫu và công cụ mọi quản lý dự án PHẢI dùng → ⚠ đó là bắt buộc tuân thủ = Controlling.

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

  • B (Supportive) — ⚠ chỉ CUNG CẤP chứ không BẮT BUỘC; ⚠ chữ "phải" trong đề loại phương án này.

  • C (Directive) — ⚠ PMO trực tiếp quản lý dự án; ⚠ đề chỉ nói về chuẩn hoá công cụ, không nói PMO điều hành dự án.

  • D (Enterprise) — ⚠ không phải một trong ba kiểu chuẩn; ⚠ "enterprise PMO" là cách gọi theo PHẠM VI, không theo mức kiểm soát.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25574 ở lô trước hỏi chức năng CHÍNH của PMO (hỗ trợ PM). ⚠ Câu này phân loại theo mức kiểm soát. Hai câu bổ sung nhau.

⚠ Mẹo nhận diện kiểu PMO qua ngôn từ trong đề: | Từ khoá trong đề | Kiểu PMO | |---|---| | ⚠ "cung cấp", "có sẵn", "nếu cần" | ⚠ Supportive | | ⚠ "phải dùng", "bắt buộc", "yêu cầu tuân thủ" | ⚠ Controlling | | ⚠ "PMO quản lý dự án", "PM báo cáo cho PMO" | ⚠ Directive |

Từ khoá nhận diện:

"bắt buộc dùng mẫu và công cụ" → ⚠ controlling "có mẫu cho ai cần" → ⚠ supportive "PMO trực tiếp điều hành" → ⚠ directive "chọn đúng dự án theo chiến lược" → ⚠ portfolio management

⚠ PMO theo PHẠM VI — cách phân loại khác Kiểu
⚠ Enterprise PMO — EPMO ⚠ cấp toàn tổ chức, gắn với chiến lược
⚠ Departmental PMO ⚠ cho một phòng ban hoặc đơn vị
⚠ Project-specific PMO ⚠ lập riêng cho một dự án lớn
⚠ Lưu ý ⚠ đây là trục phân loại KHÁC với ba kiểu theo mức kiểm soát
⚠ Được và mất của controlling PMO Điều
⚠ ĐƯỢC: chuẩn hoá, dễ so sánh giữa các dự án
⚠ ĐƯỢC: người mới có khung để theo
⚠ ĐƯỢC: dữ liệu tổng hợp lên cấp cao đáng tin
⚠ MẤT: kém linh hoạt với dự án đặc thù
⚠ MẤT: có thể thành gánh nặng thủ tục
⚠ Cân bằng ⚠ chuẩn hoá cái đáng chuẩn hoá, để tự do ở chỗ cần sáng tạo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | PMO của bạn thuộc kiểu nào | ⚠ quyết định mức tự chủ của bạn | | Mẫu bắt buộc có thật sự hữu ích không | | | Có thể đề xuất điều chỉnh khung cho dự án đặc thù không | |

Và rủi ro thường gặp của controlling PMO khi triển khai quá tay: quy trình trở thành mục tiêu thay vì công cụ. Khi đội dành nhiều thời gian điền biểu mẫu hơn là làm việc, PMO đã đi quá ranh giới giữa chuẩn hoá và quan liêu.