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

Tìm thấy 201 câu.

Câu 81
A PMO may have the authority to act as an integral stakeholder and a key decision maker throughout the life of each project. Which of the following is not a function of a PMO?
  1. A Identifying and developing project management methodology, best practices, and standards
  2. B Creating the charter for a project that is administered by the PMO
  3. C Coordinating communication across projects
  4. D Managing shared resources across all projects administered by the PMO
Xem giải thích

Đáp án

B — Tạo charter cho dự án do chính PMO quản lý.

Vì sao đúng

⚠ Đây KHÔNG phải chức năng chuẩn của PMO — ⚠ và đề hỏi cái nào không phải.

Vấn đề Nội dung
⚠ Charter phải do người NGOÀI dự án ký ⚠ thường là nhà tài trợ
⚠ PMO tự tạo charter cho dự án mình quản ⚠ là vừa đá bóng vừa thổi còi
⚠ Người ký cần có thẩm quyền CẤP NGUỒN LỰC tổ chức
⚠ PMO có thể ⚠ HỖ TRỢ soạn thảo, nhưng không phải bên phê duyệt

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

⚠ Ba phương án còn lại đều là chức năng chuẩn của PMO: | Phương án | Nội dung | |---|---| | ⚠ A — xây phương pháp luận, thực hành tốt, chuẩn | ⚠ chức năng cốt lõi | | ⚠ C — điều phối truyền thông giữa các dự án | ⚠ chức năng chuẩn | | ⚠ D — quản lý nguồn lực chia sẻ giữa các dự án | ⚠ chức năng chuẩn |

Ghi nhớ

⚠ Các chức năng chuẩn của PMO: | Chức năng | Nội dung | |---|---| | ⚠ Quản lý nguồn lực chia sẻ | ⚠ giữa mọi dự án PMO quản | | ⚠ Xác định và phát triển phương pháp luận | ⚠ thực hành tốt, chuẩn | | ⚠ Kèm cặp, đào tạo, giám sát | | | ⚠ Giám sát tuân thủ | ⚠ qua kiểm toán dự án | | ⚠ Phát triển và quản lý chính sách, mẫu, tài liệu | | | ⚠ Điều phối truyền thông GIỮA các dự án | |

Từ khoá nhận diện:

"tạo và ký charter" → ⚠ nhà tài trợ, KHÔNG phải PMO "chuẩn hoá phương pháp luận" → ⚠ PMO "điều phối nguồn lực giữa các dự án" → ⚠ PMO "chọn dự án nào nên làm" → ⚠ portfolio management

⚠ Vì sao charter cần người ngoài dự án ký Lý do
⚠ Bảo đảm dự án được TỔ CHỨC cam kết ⚠ không chỉ là ý muốn của đội
⚠ Người ký phải có quyền cấp nguồn lực
⚠ Tạo cơ chế kiểm tra và cân bằng
⚠ PM cũng vậy ⚠ PM KHÔNG tự ký charter trao quyền cho chính mình
⚠ Nhưng PMO có thể tham gia thế nào Cách
⚠ Hỗ trợ soạn thảo nội dung
⚠ Cung cấp mẫu charter
⚠ Rà soát tính đầy đủ
⚠ Với directive PMO, giám đốc PMO CÓ THỂ là người ký ⚠ nếu có thẩm quyền tổ chức trao
⚠ Nhưng theo nguyên tắc chung ⚠ "tạo charter" không được liệt kê là chức năng của PMO

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Charter dự án của bạn do ai ký | | | Người đó có thẩm quyền cấp nguồn lực không | | | PMO đang đóng vai trò hỗ trợ hay phê duyệt | |

Và nguyên tắc quản trị nằm sau quy định này: người thực hiện và người phê duyệt phải tách nhau. Đó là lý do PM không tự ký charter cho mình, và cũng là lý do PMO không nên là bên duyệt cho chính những dự án mình đang quản.

Câu 82
You have created the project network diagram with your team. Your team is concerned about one of the activities that may be delayed due to some risk on the project. What term is assigned to the total amount of time an activity may be delayed without affecting the early start of a successor activity?
  1. A Free float
  2. B Float
  3. C Slack
  4. D Total float
Xem giải thích

Đáp án

A — Free float.

Vì sao đúng

⚠ Ba loại float — phân biệt bằng ĐIỀU GÌ bị ảnh hưởng: | Loại | Trì hoãn mà không ảnh hưởng tới | |---|---| | ⚠ Free float | ⚠ EARLY START của hoạt động KẾ TIẾP | | ⚠ Total float | ⚠ NGÀY KẾT THÚC dự án | | ⚠ Project float | ⚠ hạn chót áp đặt từ bên ngoài |

⚠ Đề nói rõ "early start của successor" → ⚠ đó chính là định nghĩa của free float.

⚠ Quan hệ giữa hai loại: | Quan hệ | Nội dung | |---|---| | ⚠ Free float ≤ Total float | ⚠ luôn luôn | | ⚠ Free float thường bằng 0 | ⚠ với hoạt động nối tiếp nhau chặt | | ⚠ Ý nghĩa thực tế | ⚠ free float là phần "an toàn tuyệt đối" — dùng mà không ai bị ảnh hưởng |

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

  • D (Total float) — ⚠ liên quan tới NGÀY KẾT THÚC dự án, không phải hoạt động kế tiếp.

  • B (Float) và C (Slack) — ⚠ là tên gọi CHUNG, không chỉ rõ loại nào.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ trong quản lý dự án, ⚠ "float" và "slack" là HAI TỪ ĐỒNG NGHĨA — ⚠ nhưng đề đặt chúng thành hai phương án riêng biệt B và C.

Phương án Nhận xét
⚠ B — Float ⚠ tên chung, đồng nghĩa với slack
⚠ C — Slack ⚠ cũng là tên chung, cùng nghĩa với float
⚠ Hai phương án này ⚠ về bản chất là MỘT — không thể phân biệt
⚠ Nhưng ⚠ cả hai đều quá chung so với "free float"
⚠ Khoá A vẫn ĐÚNG ⚠ vì đề mô tả chính xác định nghĩa free float
⚠ Bài học ⚠ khi có phương án chung và phương án cụ thể, chọn cái CỤ THỂ khớp mô tả

⚠ Công thức tính float: | Công thức | Nội dung | |---|---| | ⚠ Total float = LS − ES = LF − EF | | | ⚠ Free float = ES của successor sớm nhất − EF của hoạt động này | | | ⚠ Tính bằng | ⚠ forward pass rồi backward pass trên sơ đồ mạng |

Từ khoá nhận diện:

"không ảnh hưởng hoạt động kế tiếp" → ⚠ free float "không ảnh hưởng ngày kết thúc dự án" → ⚠ total float "float bằng 0" → ⚠ đường găng "float âm" → ⚠ lịch KHÔNG khả thi, phải nén ngay

⚠ Dùng float thế nào trong quản lý Cách
⚠ Ưu tiên theo dõi hoạt động có float THẤP
⚠ Dùng free float trước, total float sau ⚠ free float an toàn hơn
⚠ Dùng hết total float là hoạt động thành đường găng
⚠ Float âm là tín hiệu KHẨN CẤP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hoạt động nào có total float bằng 0 | ⚠ đường găng | | Có float âm ở đâu không | | | Có đang tiêu float mà không ai để ý không | ⚠ float cạn dần là dấu hiệu sớm của chậm tiến độ |

Và cách dùng float như một hệ thống cảnh báo sớm: theo dõi float CẠN DẦN theo thời gian. Một hoạt động ban đầu có mười ngày float mà nay chỉ còn hai là dấu hiệu rõ ràng, dù nó chưa hề trễ hạn ngày nào.

Câu 83
As a project manager, you should recognize the communication model not only for your exam but also to be a more effective project manager. Which one of the following is the correct ordering of a message through the communications model?
  1. A Sender, Encoder, Transmitter, Decoder, Receiver, Acknowledger
  2. B Sender, Transmitter, Medium, Receiver, Decoder, Acknowledgment
  3. C Sender, Encoder, Medium, Decoder, Receiver, Acknowledgement
  4. D Encoder, Decoder, Acknowledgement
Xem giải thích

Đáp án

C — Sender, Encoder, Medium, Decoder, Receiver, Acknowledgement.

Vì sao đúng

⚠ Trình tự đúng của mô hình truyền thông: | Thứ tự | Thành phần | Nội dung | |---|---|---| | ⚠ 1 | ⚠ Sender | ⚠ người gửi có một ý tưởng | | ⚠ 2 | ⚠ Encoder | ⚠ mã hoá ý thành thông điệp — chọn từ ngữ | | ⚠ 3 | ⚠ Medium | ⚠ kênh truyền — email, cuộc gọi, gặp mặt | | ⚠ 4 | ⚠ Decoder | ⚠ giải mã thông điệp | | ⚠ 5 | ⚠ Receiver | ⚠ người nhận hiểu ý | | ⚠ 6 | ⚠ Acknowledgement | ⚠ xác nhận đã nhận |

⚠ Sau đó là FEEDBACK — ⚠ phản hồi về nội dung, ⚠ và vòng lặp bắt đầu lại theo chiều ngược.

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

  • A (…Transmitter…) — ⚠ thiếu MEDIUM, và "transmitter" không phải thành phần chuẩn.

  • B (Sender, Transmitter, Medium, Receiver, Decoder…) — ⚠ sai thứ tự; ⚠ giải mã phải diễn ra TRƯỚC khi người nhận hiểu được.

  • D (chỉ ba thành phần) — ⚠ thiếu quá nhiều.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25566 ở lô trước hỏi Internet trong họp trực tuyến là thành phần nào (medium). ⚠ Câu này hỏi TRÌNH TỰ đầy đủ. Hai câu bổ sung nhau.

⚠ Nhiễu — noise — xen vào ở MỌI khâu: | Khâu | Nhiễu có thể là | |---|---| | ⚠ Encoding | ⚠ dùng từ chuyên môn người nghe không hiểu | | ⚠ Medium | ⚠ mạng chập chờn, tiếng ồn | | ⚠ Decoding | ⚠ định kiến, mệt mỏi, khác biệt văn hoá | | ⚠ Vai trò người gửi | ⚠ chọn medium và cách mã hoá để GIẢM nhiễu |

⚠ Phân biệt acknowledgement và feedback: | Khái niệm | Nghĩa | |---|---| | ⚠ Acknowledgement | ⚠ "tôi ĐÃ NHẬN được" | | ⚠ Feedback | ⚠ "tôi ĐÃ HIỂU và đây là phản hồi của tôi" | | ⚠ Nhận được | ⚠ KHÔNG có nghĩa là đã hiểu | | ⚠ Vì thế | ⚠ feedback mới là bằng chứng truyền thông thành công |

Từ khoá nhận diện:

"kênh mang thông điệp" → ⚠ medium "chuyển ý thành lời" → ⚠ encode "đọc và hiểu thông điệp" → ⚠ decode "xác nhận đã nhận" → ⚠ acknowledge "phản hồi về nội dung" → ⚠ feedback

⚠ Ba phương pháp truyền thông Phương pháp
⚠ Interactive ⚠ hai chiều thời gian thực — có feedback ngay
⚠ Push ⚠ gửi đi, có acknowledgement nhưng ít feedback
⚠ Pull ⚠ người nhận tự lấy, không có acknowledgement
⚠ Tin quan trọng ⚠ nên dùng interactive để có feedback thật
⚠ Kỹ thuật giảm nhiễu Kỹ thuật
⚠ Lắng nghe chủ động ⚠ nhắc lại điều đã nghe bằng lời của mình
⚠ Chọn medium phù hợp với nội dung
⚠ Tránh từ chuyên môn với người ngoài ngành
⚠ Xác nhận lại bằng văn bản sau cuộc họp quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người nhận có phản hồi cho thấy đã hiểu không | | | Medium có phù hợp với mức quan trọng của tin không | | | Có xác nhận lại bằng văn bản sau trao đổi quan trọng không | |

Và khâu duy nhất chứng minh truyền thông đã thành công: feedback. Acknowledgement chỉ nói rằng thông điệp đã tới nơi — còn nó có được hiểu đúng hay không thì chỉ phản hồi mới trả lời được.

Câu 84
Henry is the project manager of a construction project for his organization. He is examining the project schedule and he has several activities that are scheduled as finish-to-start, but there’s no real reason that the entire activities need to be completed before the successor activity can begin. Henry elects to allow some of the activities to overlap by a few days to compress the overall schedule duration. What technique has Henry likely used in this scenario?
  1. A Lead time
  2. B Negative float
  3. C Schedule compression
  4. D Duration compression
Xem giải thích

Đáp án

A — Lead time (thời gian sớm).

Vì sao đúng

⚠ Lead — cho hoạt động sau BẮT ĐẦU SỚM hơn: | Đặc điểm | Nội dung | |---|---| | ⚠ Cho phép CHỒNG LẤN giữa hai hoạt động | | | ⚠ Hoạt động sau bắt đầu trước khi hoạt động trước kết thúc | | | ⚠ RÚT NGẮN tổng thời lượng | | | ⚠ Ghi trong sơ đồ mạng là số âm | ⚠ ví dụ FS − 3 ngày |

⚠ Đúng tình huống của Henry: ⚠ quan hệ finish-to-start nhưng ⚠ không thực sự cần hoàn tất hoàn toàn → ⚠ áp lead để chồng lấn vài ngày.

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

  • B (Negative float) — ⚠ là dấu hiệu lịch KHÔNG khả thi, không phải một kỹ thuật.

  • D (Duration compression) — ⚠ tên cũ của schedule compression, cũng là tên NHÓM.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C — Schedule compression ⚠ cũng mô tả đúng điều Henry đang làm ở mức KỸ THUẬT.

Phương án Cấp độ khái niệm
⚠ C — Schedule compression ⚠ tên NHÓM kỹ thuật, gồm crashing và fast tracking
⚠ Fast tracking ⚠ kỹ thuật cụ thể — cho hoạt động chồng lấn
⚠ A — Lead time (khoá) ⚠ CƠ CHẾ để thực hiện việc chồng lấn đó
⚠ Đề hỏi ⚠ "kỹ thuật nào Henry ĐÃ DÙNG" — mô tả cụ thể việc áp chồng lấn vài ngày
⚠ Lead là ⚠ câu trả lời chính xác nhất về cơ chế
⚠ Khoá ⚠ giữ nguyên A, nhưng hiểu rằng C mô tả cùng hành động ở mức khái quát hơn

⚠ Lead và Lag — hai khái niệm ngược nhau: | Khái niệm | Nghĩa | Ảnh hưởng lịch | |---|---|---| | ⚠ Lead | ⚠ cho bắt đầu SỚM, chồng lấn | ⚠ RÚT NGẮN | | ⚠ Lag | ⚠ CHỜ thêm giữa hai việc | ⚠ KÉO DÀI |

Từ khoá nhận diện:

"chồng lấn, bắt đầu sớm" → ⚠ lead "chờ thêm, đợi khô" → ⚠ lag "tên nhóm kỹ thuật nén lịch" → ⚠ schedule compression "lịch không khả thi" → ⚠ negative float

⚠ Rủi ro khi dùng lead Rủi ro
⚠ Hoạt động trước có thể còn thay đổi ⚠ phải làm lại phần đã bắt đầu
⚠ Cần phối hợp chặt hơn nhiều
⚠ Chỉ áp được cho SOFT LOGIC ⚠ hard logic không chồng lấn được
⚠ Henry may mắn ⚠ đề nói rõ "không có lý do thật sự phải hoàn tất trước"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quan hệ này là hard logic hay soft logic | ⚠ hard thì không chồng được | | Rủi ro làm lại đã được ước lượng chưa | | | Sau khi áp lead, đường găng có đổi không | |

Và câu hỏi Henry đã đặt đúng: "có lý do THẬT SỰ nào buộc việc này phải xong hẳn trước không?" Rất nhiều quan hệ finish-to-start trong sơ đồ mạng chỉ là thói quen vẽ, chứ không phải ràng buộc thật.

Câu 85
Mary, the project sponsor, has asked you to create the most accurate project cost estimate before starting the project execution. What type of project cost estimate should you create for Mary?
  1. A Budget estimate
  2. B Proof estimate
  3. C ROM
  4. D Definitive estimate
Xem giải thích

Đáp án

D — Definitive estimate (ước lượng xác định).

Vì sao đúng

⚠ Các mức chính xác của ước lượng chi phí: | Loại | Khoảng sai số | Khi nào dùng | |---|---|---| | ⚠ Rough Order of Magnitude — ROM | ⚠ −25% đến +75% | ⚠ giai đoạn khởi tạo, rất ít thông tin | | ⚠ Budget estimate | ⚠ −10% đến +25% | ⚠ khi lập kế hoạch sơ bộ | | ⚠ Definitive estimate | ⚠ −5% đến +10% | ⚠ khi đã có đủ chi tiết, TRƯỚC khi thực thi |

⚠ Đề yêu cầu "chính xác NHẤT" và "trước khi bắt đầu thực thi" → ⚠ definitive estimate.

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

  • A (budget estimate) — ⚠ kém chính xác hơn definitive.

  • C (ROM) — ⚠ kém chính xác NHẤT, dùng ở giai đoạn rất sớm.

  • B (proof estimate) — ⚠ không phải thuật ngữ chuẩn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25580 ở lô trước về kỹ thuật ước lượng (parametric). ⚠ Câu này về ĐỘ CHÍNH XÁC của ước lượng. Hai trục khác nhau, bổ sung cho nhau.

⚠ Hai trục của ước lượng — đừng lẫn: | Trục | Nội dung | |---|---| | ⚠ KỸ THUẬT | ⚠ analogous, parametric, three-point, bottom-up | | ⚠ ĐỘ CHÍNH XÁC | ⚠ ROM, budget, definitive | | ⚠ Quan hệ | ⚠ kỹ thuật bottom-up thường cho ra definitive estimate |

⚠ Nguyên tắc chi tiết hoá dần: | Giai đoạn | Thông tin | Ước lượng | |---|---|---| | ⚠ Khởi tạo | ⚠ rất ít | ⚠ ROM | | ⚠ Lập kế hoạch sơ bộ | ⚠ trung bình | ⚠ budget | | ⚠ Lập kế hoạch chi tiết | ⚠ đầy đủ | ⚠ definitive | | ⚠ Quy luật | ⚠ càng nhiều thông tin, khoảng ước lượng càng HẸP |

Từ khoá nhận diện:

"chính xác nhất, trước khi thực thi" → ⚠ definitive estimate "rất sớm, ít thông tin" → ⚠ ROM "đơn giá nhân số lượng" → ⚠ parametric, là KỸ THUẬT "cộng từ từng gói công việc" → ⚠ bottom-up, cho độ chính xác cao nhất

⚠ Sai lầm phổ biến với ước lượng Sai lầm
⚠ Đưa ra một CON SỐ DUY NHẤT quá sớm ⚠ rồi bị giữ trách nhiệm với nó
⚠ Không nêu KHOẢNG sai số
⚠ Bị ép cam kết definitive khi mới có thông tin ROM
⚠ Cách xử lý ⚠ luôn nêu rõ mức chính xác kèm con số
⚠ Chi phí của việc ước lượng Chi phí
⚠ Definitive estimate TỐN nhiều thời gian và công sức
⚠ ROM rất nhanh và rẻ
⚠ Cân nhắc ⚠ đừng làm definitive cho một ý tưởng chưa chắc được duyệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ước lượng hiện tại thuộc mức nào | | | Bên liên quan có hiểu đó là khoảng chứ không phải con số cứng không | | | Có bị cam kết một con số ROM như thể nó là definitive không | |

Và cạm bẫy nghề nghiệp lớn nhất của quản lý dự án: một con số ROM đưa ra trong cuộc họp đầu tiên bị ghi lại và trở thành cam kết. Luôn nêu rõ mức chính xác kèm mọi ước lượng — nói ra thì dễ, sửa lại về sau thì rất khó.

Câu 86
Projects are often complex and require analytical skills by the project manager and the project team. There are three specific dimensions to the complexity of project management. Which one of the following is not one of the three dimensions of complexity?
  1. A Human behavior
  2. B System behavior
  3. C Team behavior
  4. D Ambiguity
Xem giải thích

Đáp án

C — Team behavior (hành vi của đội).

Vì sao đúng

⚠ Ba chiều phức tạp của quản lý dự án theo PMBOK: | Chiều | Nội dung | |---|---| | ⚠ Human behavior | ⚠ hành vi con người — tương tác giữa người với người, chính trị nội bộ | | ⚠ System behavior | ⚠ hành vi hệ thống — các thành phần phụ thuộc lẫn nhau một cách khó lường | | ⚠ Ambiguity | ⚠ mơ hồ — không rõ chuyện gì sẽ xảy ra, thiếu hiểu biết |

⚠ "Team behavior" không phải một chiều riêng — ⚠ nó nằm trong human behavior.

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

  • A (human behavior), B (system behavior), D (ambiguity) — ⚠ đều là ba chiều chính thức.

Ghi nhớ

⚠ Ba chiều phức tạp — hiểu sâu hơn: | Chiều | Ví dụ trong dự án | |---|---| | ⚠ Human behavior | ⚠ xung đột giữa các phòng ban, kháng cự thay đổi, chính trị tổ chức | | ⚠ System behavior | ⚠ đổi một mô-đun kéo theo lỗi ở mô-đun khác không ai ngờ tới | | ⚠ Ambiguity | ⚠ công nghệ mới chưa ai từng dùng, thị trường chưa rõ hình dạng |

⚠ Ứng phó với từng chiều: | Chiều | Cách ứng phó | |---|---| | ⚠ Human behavior | ⚠ kỹ năng liên cá nhân, quản lý bên liên quan, trí tuệ cảm xúc | | ⚠ System behavior | ⚠ tư duy hệ thống, mô hình hoá, kiểm thử tích hợp sớm | | ⚠ Ambiguity | ⚠ tiếp cận LẶP, làm mẫu thử, học dần |

Từ khoá nhận diện:

"ba chiều phức tạp" → ⚠ human behavior, system behavior, ambiguity "không biết chuyện gì có thể xảy ra" → ⚠ ambiguity risk "kết quả dao động" → ⚠ variability risk "chỉ nhận ra sau khi xảy ra" → ⚠ emergent risk

⚠ Vì sao "ambiguity" ngày càng quan trọng Lý do
⚠ Dự án dùng công nghệ mới ngày càng nhiều
⚠ Yêu cầu thay đổi nhanh
⚠ Không thể lập kế hoạch chi tiết từ đầu
⚠ Đây là lý do ⚠ cách tiếp cận LINH HOẠT ra đời — học dần thay vì dự đoán hết
⚠ Tư duy hệ thống — đối phó với system behavior Nội dung
⚠ Nhìn TOÀN THỂ, không chỉ từng phần
⚠ Chú ý tới quan hệ và vòng phản hồi
⚠ Thay đổi nhỏ ở một chỗ có thể gây hậu quả lớn ở chỗ khác
⚠ Kiểm thử TÍCH HỢP sớm và thường xuyên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chiều phức tạp nào đang gây khó nhất cho dự án | | | Có đang dùng cách tiếp cận phù hợp với mức mơ hồ không | | | Đã kiểm thử tích hợp chưa hay để tới cuối | |

Và điều ba chiều phức tạp nói với người quản lý dự án: không có một công thức chung. Dự án nhiều mơ hồ cần cách tiếp cận lặp; dự án nhiều phức tạp về con người cần đầu tư vào quan hệ — và chọn nhầm cách tiếp cận là nguyên nhân thất bại thường gặp.

Câu 87
Harold is the project manager of the JKL Project for his organization and he’s meeting with the project team to identify some project risks in the next phase of the project. During the meeting, he notices that Char and Holly won’t look at each other and their body language tells Harold, and the rest of the project team members, that there is some hostility between these two individuals. Throughout the meeting, Harold observes that these two individuals won’t speak to each other and it’s causing some disruption in the conference. What component of the communication model is happening and will present a challenge for Harold to overcome?
  1. A Barrier
  2. B Anger
  3. C Blockage
  4. D Emotional intelligence
Xem giải thích

Đáp án

A — Barrier (rào cản).

Vì sao đúng

⚠ Barrier — rào cản trong mô hình truyền thông: | Đặc điểm | Nội dung | |---|---| | ⚠ Là thứ CẢN TRỞ thông điệp tới nơi | | | ⚠ Có thể là vật lý, tâm lý, ngữ nghĩa, văn hoá | | | ⚠ Ở đây là rào cản TÂM LÝ | ⚠ thù địch giữa hai cá nhân | | ⚠ Hệ quả | ⚠ thông tin không được chia sẻ, quyết định thiếu dữ liệu |

⚠ Trong buổi nhận diện rủi ro, ⚠ rào cản này đặc biệt tai hại: ⚠ Char và Holly có thể đang giữ thông tin về rủi ro mà không nói ra.

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

  • B (Anger) — ⚠ là một CẢM XÚC, không phải thành phần của mô hình truyền thông.

  • C (Blockage) — ⚠ không phải thuật ngữ chuẩn trong mô hình này.

  • D (Emotional intelligence) — ⚠ là NĂNG LỰC của người quản lý, cũng chính là thứ Harold cần dùng để xử lý; ⚠ nhưng đề hỏi thành phần nào đang xảy ra.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25604 trong lô này liệt kê trình tự mô hình truyền thông. ⚠ Câu này về thứ CẢN TRỞ mô hình đó. Hai câu bổ sung nhau.

⚠ Các loại rào cản truyền thông: | Loại | Ví dụ | |---|---| | ⚠ Vật lý | ⚠ tiếng ồn, mạng kém, khoảng cách địa lý | | ⚠ Tâm lý | ⚠ thù địch, định kiến, sợ hãi, mệt mỏi | | ⚠ Ngữ nghĩa | ⚠ từ chuyên môn, ngôn ngữ khác nhau | | ⚠ Văn hoá | ⚠ khác biệt về cách diễn đạt và lễ nghi | | ⚠ Tổ chức | ⚠ quá nhiều cấp trung gian, chính trị nội bộ |

⚠ Harold nên làm gì: | Việc | Nội dung | |---|---| | ⚠ Xử lý RIÊNG, không nêu trước cả nhóm | ⚠ tránh làm hai người mất mặt | | ⚠ Tìm hiểu nguyên nhân xung đột | | | ⚠ Dùng kỹ thuật giải quyết xung đột phù hợp | ⚠ ưu tiên collaborate/problem solve | | ⚠ Bảo đảm thông tin về rủi ro vẫn được thu thập đủ | ⚠ có thể hỏi riêng từng người | | ⚠ Cân nhắc kỹ thuật ẩn danh | ⚠ brainwriting hoặc Delphi cho buổi sau |

Từ khoá nhận diện:

"cản trở thông điệp" → ⚠ barrier "nhiễu trong kênh truyền" → ⚠ noise "nhận biết và quản lý cảm xúc" → ⚠ trí tuệ cảm xúc "xung đột giữa thành viên" → ⚠ quản lý xung đột, thuộc Manage Team

⚠ Năm cách xử lý xung đột — theo mức hiệu quả Cách
⚠ Collaborate / Problem solve ⚠ TỐT NHẤT — cùng tìm giải pháp, thắng–thắng
⚠ Compromise ⚠ mỗi bên nhượng bộ một phần
⚠ Smooth / Accommodate ⚠ nhấn điểm chung, tạm gác khác biệt
⚠ Force / Direct ⚠ áp đặt — thắng–thua, có thể cần khi khẩn cấp
⚠ Withdraw / Avoid ⚠ né tránh — KÉM NHẤT về lâu dài
⚠ Vì sao xung đột trong buổi nhận diện rủi ro lại nguy hiểm Lý do
⚠ Rủi ro chỉ được xử lý nếu ĐƯỢC NÓI RA
⚠ Người đang giận thường giữ thông tin lại
⚠ Cả nhóm mất tập trung vào việc chính
⚠ Rủi ro không nhận diện được ⚠ là rủi ro không có kế hoạch ứng phó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai trong đội đang giữ thông tin lại không | | | Xung đột đã được xử lý riêng chưa | | | Có cần dùng kỹ thuật ẩn danh để thu thập không | |

Và cái giá thật của một xung đột cá nhân trong đội, vượt xa sự khó chịu: thông tin ngừng chảy. Trong một buổi nhận diện rủi ro, điều đó nghĩa là những rủi ro thật có thể không bao giờ được ghi vào sổ.

Câu 88
You are a project manager for your organization and management has asked you to present a chart that will show the planned project performance on one axis and the actual project performance on a second axis to see the correlation of what was expected and what was experienced. What type of quality management chart is being requested?
  1. A Fishbone chart
  2. B Scatter diagram
  3. C Pareto chart
  4. D Histogram
Xem giải thích

Đáp án

B — Scatter diagram (biểu đồ phân tán).

Vì sao đúng

⚠ Scatter diagram thể hiện QUAN HỆ giữa hai biến: | Đặc điểm | Nội dung | |---|---| | ⚠ Trục X là một biến | ⚠ ở đây là hiệu suất KẾ HOẠCH | | ⚠ Trục Y là biến kia | ⚠ hiệu suất THỰC TẾ | | ⚠ Mỗi điểm là một quan sát | | | ⚠ Hình dạng đám mây điểm cho thấy mức tương quan | |

⚠ Đọc biểu đồ phân tán: | Hình dạng | Ý nghĩa | |---|---| | ⚠ Điểm bám sát một đường chéo lên | ⚠ tương quan DƯƠNG mạnh | | ⚠ Điểm bám đường chéo xuống | ⚠ tương quan ÂM | | ⚠ Điểm tản mác không theo hình nào | ⚠ KHÔNG tương quan |

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

  • A (Fishbone chart) — ⚠ biểu đồ xương cá của Ishikawa, dùng tìm NGUYÊN NHÂN GỐC.

  • C (Pareto chart) — ⚠ biểu đồ cột xếp theo tần suất giảm dần, tìm ra ít nguyên nhân gây phần lớn vấn đề.

  • D (Histogram) — ⚠ biểu đồ phân bố của MỘT biến, không thể hiện quan hệ hai biến.

Ghi nhớ

⚠ Bảy công cụ chất lượng cơ bản: | Công cụ | Dùng để | |---|---| | ⚠ Cause-and-effect / Fishbone | ⚠ tìm nguyên nhân gốc | | ⚠ Flowchart | ⚠ mô tả quy trình | | ⚠ Check sheet | ⚠ thu thập dữ liệu có cấu trúc | | ⚠ Pareto chart | ⚠ ưu tiên vấn đề theo tần suất | | ⚠ Histogram | ⚠ xem phân bố của một biến | | ⚠ Control chart | ⚠ theo dõi quy trình có ổn định không | | ⚠ Scatter diagram | ⚠ quan hệ giữa HAI biến |

Từ khoá nhận diện:

"quan hệ giữa hai biến" → ⚠ scatter diagram "phân bố của một biến" → ⚠ histogram "ít nguyên nhân gây phần lớn vấn đề" → ⚠ Pareto, quy tắc 80/20 "tìm nguyên nhân gốc" → ⚠ fishbone, hoặc 5 Whys

⚠ Control chart — các khái niệm hay hỏi Khái niệm
⚠ Upper và Lower Control Limit ⚠ giới hạn ỔN ĐỊNH của quy trình, thường ±3 sigma
⚠ Specification limit ⚠ giới hạn CHẤP NHẬN của khách hàng
⚠ Rule of seven ⚠ bảy điểm liên tiếp cùng một phía đường trung tâm là BẤT THƯỜNG
⚠ Điểm ngoài control limit ⚠ quy trình mất kiểm soát, phải điều tra
⚠ Lưu ý quan trọng về tương quan Lưu ý
⚠ Tương quan KHÔNG phải nhân quả
⚠ Hai biến cùng biến động có thể do một nguyên nhân THỨ BA
⚠ Scatter diagram gợi ý, không CHỨNG MINH
⚠ Cần thêm ⚠ phân tích nguyên nhân gốc để xác nhận

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hai biến có thật sự liên quan nhân quả không | | | Có đủ số điểm dữ liệu để kết luận không | | | Có biến thứ ba nào chưa được xét không | |

Và sai lầm thường gặp khi đọc biểu đồ phân tán: nhầm tương quan thành nhân quả. Thấy hai đại lượng cùng biến động không có nghĩa là cái này gây ra cái kia — có thể cả hai cùng chịu ảnh hưởng của một yếu tố chưa được nhìn thấy.

Câu 89
As a project manager, you should be familiar with the project management processes and what the different processes create for a project. Consider the develop project charter process. This process creates the project charter, but also creates what other project item?
  1. A Project manager designation
  2. B Organizational process assets
  3. C Project team charter
  4. D Assumption log
Xem giải thích

Đáp án

D — Assumption log (nhật ký giả định).

Vì sao đúng

⚠ Develop Project Charter tạo ra HAI đầu ra: | Đầu ra | Nội dung | |---|---| | ⚠ Project charter | ⚠ chính thức khai sinh dự án, trao quyền cho PM | | ⚠ Assumption log | ⚠ ghi lại các GIẢ ĐỊNH và RÀNG BUỘC ở mức cao |

⚠ Assumption log ghi gì: | Loại | Ví dụ | |---|---| | ⚠ Giả định | ⚠ "nhân sự chủ chốt sẽ có mặt suốt dự án" | | ⚠ Ràng buộc | ⚠ "ngân sách không vượt 400.000" | | ⚠ Vì sao ghi lại | ⚠ mỗi giả định là một RỦI RO tiềm ẩn nếu hoá ra không đúng |

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

  • B (organizational process assets) — ⚠ là ĐẦU VÀO của quy trình, không phải đầu ra; ⚠ OPA chỉ được cập nhật ở các quy trình khác.

  • A (project manager designation) — ⚠ được ghi TRONG charter, không phải một tài liệu riêng.

  • C (project team charter) — ⚠ là tài liệu về quy tắc làm việc của đội, ⚠ tạo ra ở quy trình Plan Resource Management.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25586 ở lô này về charter — ai soạn, ai ký. ⚠ Câu này về đầu ra thứ hai của cùng quy trình. Hai câu bổ sung nhau.

⚠ Vì sao assumption log quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Giả định SAI là nguồn rủi ro lớn | | | ⚠ Ghi lại giúp kiểm chứng dần | | | ⚠ Khi giả định bị bác bỏ, có thể phải đổi kế hoạch | | | ⚠ Là đầu vào cho nhận diện rủi ro | | | ⚠ Cập nhật | ⚠ SUỐT dự án, không chỉ lúc đầu |

⚠ Phân biệt giả định và ràng buộc: | Khái niệm | Nghĩa | |---|---| | ⚠ Assumption — giả định | ⚠ coi là ĐÚNG mà chưa kiểm chứng | | ⚠ Constraint — ràng buộc | ⚠ giới hạn CHẮC CHẮN có | | ⚠ Ví dụ giả định | ⚠ "nhà cung cấp sẽ giao đúng hạn" | | ⚠ Ví dụ ràng buộc | ⚠ "phải xong trước tháng 6 vì có quy định pháp lý" |

Từ khoá nhận diện:

"giả định và ràng buộc" → ⚠ assumption log "quy tắc làm việc của đội" → ⚠ team charter, thuộc Plan Resource Management "khai sinh dự án" → ⚠ project charter "tài sản quy trình tổ chức" → ⚠ OPA, thường là đầu VÀO

⚠ Team charter gồm gì Nội dung
⚠ Giá trị chung của đội
⚠ Hướng dẫn giao tiếp
⚠ Tiêu chí ra quyết định
⚠ Quy trình giải quyết xung đột
⚠ Quy tắc họp
⚠ Do ĐỘI cùng xây ⚠ cam kết mạnh hơn khi tự đặt ra
⚠ Nguy hiểm của giả định không được ghi lại Nguy hiểm
⚠ Mỗi người giả định một kiểu khác nhau
⚠ Không ai kiểm chứng vì tưởng đã chắc
⚠ Khi vỡ ra thì đã muộn
⚠ Câu hỏi nên hỏi định kỳ ⚠ "giả định nào chúng ta đang dựa vào mà chưa kiểm chứng?"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có assumption log không và có được cập nhật không | | | Giả định nào đã được kiểm chứng, cái nào chưa | | | Giả định nào nếu sai sẽ gây thiệt hại lớn nhất | ⚠ ưu tiên kiểm chứng cái đó trước |

Và câu hỏi đáng đặt ra ở mỗi cuộc họp rà soát dự án: giả định nào chúng ta đang dựa vào mà chưa ai kiểm chứng? Phần lớn bất ngờ trong dự án đến từ một giả định mà mọi người đều tưởng là sự thật.

Câu 90
Consider a project manager in a startup technology company. This project manager has very little authority, works closely with the people in the organization, has other responsibilities in the company other than project management, and everyone in the organization chips in together to complete project work – including the company owner. What type of organizational structure is this?
  1. A Organic
  2. B PMO
  3. C Virtual
  4. D Strong matrix
Xem giải thích

Đáp án

A — Organic (cơ cấu hữu cơ).

Vì sao đúng

⚠ Organic — còn gọi là simple organization: | Đặc điểm | Nội dung | |---|---| | ⚠ Quyền của PM RẤT ÍT hoặc không có | | | ⚠ Làm việc SÁT nhau, ít cấp bậc | | | ⚠ PM thường KIÊM NHIỆM | ⚠ có việc khác ngoài quản lý dự án | | ⚠ Mọi người CÙNG LÀM, kể cả chủ doanh nghiệp | | | ⚠ Ngân sách do CHỦ hoặc người điều hành quản | | | ⚠ Điển hình ở | ⚠ công ty khởi nghiệp và tổ chức rất nhỏ |

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

  • D (Strong matrix) — ⚠ PM có quyền TRUNG BÌNH đến CAO và thường làm toàn thời gian; ⚠ ngược hẳn mô tả.

  • B (PMO) — ⚠ là một ĐƠN VỊ trong tổ chức, không phải kiểu cơ cấu.

  • C (Virtual) — ⚠ là cơ cấu có đội PHÂN TÁN địa lý, giao tiếp qua công nghệ; ⚠ đề nói mọi người làm sát nhau.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25587 ở lô này về vai trò của functional manager trong các cơ cấu. ⚠ Câu này hỏi tên một kiểu cơ cấu cụ thể. Hai câu bổ sung nhau.

⚠ Các kiểu cơ cấu tổ chức và quyền của PM: | Cơ cấu | Quyền của PM | PM toàn thời gian | |---|---|---| | ⚠ Organic / Simple | ⚠ rất ít hoặc không | ⚠ hầu như không | | ⚠ Functional | ⚠ rất ít | ⚠ hầu như không | | ⚠ Multi-divisional | ⚠ rất ít | ⚠ hầu như không | | ⚠ Weak matrix | ⚠ thấp | ⚠ bán thời gian | | ⚠ Balanced matrix | ⚠ thấp đến trung bình | ⚠ toàn thời gian | | ⚠ Strong matrix | ⚠ trung bình đến cao | ⚠ toàn thời gian | | ⚠ Project-oriented | ⚠ CAO tới toàn quyền | ⚠ toàn thời gian | | ⚠ Virtual | ⚠ thấp đến trung bình | ⚠ toàn hoặc bán thời gian | | ⚠ Hybrid | ⚠ hỗn hợp | ⚠ hỗn hợp |

Từ khoá nhận diện:

"khởi nghiệp, ai cũng làm chung, ít cấp bậc" → ⚠ organic "phòng ban riêng, PM ít quyền" → ⚠ functional "đội thuộc về dự án, PM toàn quyền" → ⚠ project-oriented "đội phân tán, làm việc qua mạng" → ⚠ virtual

⚠ Ưu và nhược của cơ cấu organic Điều
⚠ ƯU: linh hoạt, quyết định nhanh
⚠ ƯU: giao tiếp trực tiếp, ít thủ tục
⚠ NHƯỢC: thiếu quy trình chuẩn
⚠ NHƯỢC: PM khó có thẩm quyền rõ ràng
⚠ NHƯỢC: khó mở rộng khi tổ chức lớn lên
⚠ Khi tổ chức lớn dần ⚠ thường chuyển sang functional hoặc matrix
⚠ Làm PM trong cơ cấu organic thế nào Cách
⚠ Dựa vào quan hệ và ảnh hưởng, không dựa vào chức danh
⚠ Làm rõ kỳ vọng bằng văn bản dù thủ tục ít
⚠ Tranh thủ sự ủng hộ trực tiếp của chủ doanh nghiệp
⚠ Đừng áp quy trình nặng nề vào tổ chức nhỏ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức của bạn thuộc kiểu nào | ⚠ quyết định cách bạn phải làm việc | | Bạn có quyền quyết định gì | ⚠ làm rõ với người có thẩm quyền | | Mức quy trình có phù hợp quy mô tổ chức không | |

Và sai lầm phổ biến của người mới học quản lý dự án khi vào một công ty khởi nghiệp: áp nguyên bộ quy trình của tổ chức lớn. Trong cơ cấu organic, ảnh hưởng cá nhân và tốc độ mới là công cụ — không phải biểu mẫu.