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

Tìm thấy 201 câu.

Câu 151
Kelly and Chris are in a heated debate over which software to use in the project. Both Kelly and Chris have good points to the solution, but Kelly, the senior engineer, finally says that since she has seniority, the decision will be hers to make. What type of conflict resolution is happening in this scenario?
  1. A Forcing
  2. B Compromising
  3. C Power
  4. D Collaboration
Xem giải thích

Đáp án

A — Forcing (ép buộc).

Vì sao đúng

⚠ Dấu hiệu forcing trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ Kelly dùng THÂM NIÊN để áp quyết định | ⚠ dùng quyền chức vụ | | ⚠ Một bên THẮNG, một bên THUA | ⚠ win-lose | | ⚠ Không tìm điểm chung, không kết hợp ý kiến | | | ⚠ Chris không được thuyết phục, chỉ bị áp | | | ⚠ Kết luận | ⚠ đúng định nghĩa forcing / direct — áp đặt quan điểm của mình lên người khác |

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

  • D (Collaboration — hợp tác) — ⚠ là cách TỐT NHẤT: ⚠ kết hợp quan điểm nhiều bên, ⚠ tất cả cùng thắng; ⚠ Kelly đã KHÔNG làm điều này dù cả hai đều có luận điểm tốt.

  • B (Compromising — thoả hiệp) — ⚠ mỗi bên nhượng bộ một phần, ⚠ đôi bên cùng THUA một ít (⚠ lose-lose); ⚠ ở đây không có nhượng bộ nào.

  • C (Power) — ⚠ không phải một trong năm kỹ thuật giải quyết xung đột của PMBOK; ⚠ dù quyền lực đúng là công cụ Kelly dùng, ⚠ tên kỹ thuật vẫn là "forcing".

Ghi nhớ

⚠ Năm kỹ thuật giải quyết xung đột — xếp từ tốt nhất tới tệ nhất: | Kỹ thuật | Nội dung | Kết quả | |---|---|---| | ⚠ Collaborate / Problem Solve | ⚠ kết hợp quan điểm, tìm giải pháp tốt cho tất cả | ⚠ WIN-WIN — TỐT NHẤT | | ⚠ Compromise / Reconcile | ⚠ mỗi bên nhượng bộ một phần | ⚠ LOSE-LOSE — cả hai mất một ít | | ⚠ Smooth / Accommodate | ⚠ nhấn mạnh điểm chung, giảm nhẹ khác biệt | ⚠ giải pháp TẠM THỜI | | ⚠ Force / Direct | ⚠ áp đặt quan điểm của mình | ⚠ WIN-LOSE — CÂU NÀY | | ⚠ Withdraw / Avoid | ⚠ rút lui, hoãn lại, né tránh | ⚠ TỆ NHẤT — vấn đề không mất đi |

Từ khoá nhận diện:

"tôi có thâm niên nên tôi quyết" → ⚠ forcing "chia đôi, mỗi bên nhường một nửa" → ⚠ compromising "chúng ta có nhiều điểm chung mà" → ⚠ smoothing "để bàn sau đi" → ⚠ withdrawing "cùng phân tích rồi tìm giải pháp tốt nhất" → ⚠ collaborating

⚠ Khi nào forcing lại HỢP LÝ Trường hợp
⚠ Tình huống KHẨN CẤP, cần quyết ngay
⚠ Vấn đề liên quan an toàn hoặc pháp lý
⚠ Đã bàn hết cách mà vẫn bế tắc, phải có người quyết
⚠ Trong tình huống này ⚠ KHÔNG hợp lý — cả hai đều có luận điểm tốt, đáng ra nên hợp tác
⚠ Cái giá của forcing Cái giá
⚠ Người thua mất động lực
⚠ Xung đột không mất đi, chỉ chìm xuống
⚠ Lần sau người ta không nêu ý kiến nữa
⚠ Bỏ lỡ giải pháp tốt hơn từ ý kiến bị gạt
⚠ Kelly nên làm gì ⚠ liệt kê tiêu chí chọn phần mềm, chấm điểm cả hai phương án, quyết theo dữ liệu chứ không theo thâm niên

⚠ Đối chiếu: ⚠ câu #25650 ở lô này — ⚠ hai thành viên nêu hai tiêu chí khác nhau về vật liệu. ⚠ Cùng dạng tình huống, và cách xử lý đúng đều là đưa cả hai quan điểm vào một bảng so sánh có tiêu chí.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xung đột này là về VIỆC hay về NGƯỜI | ⚠ xung đột về việc là lành mạnh, nên khai thác | | Đã có tiêu chí khách quan để quyết chưa | | | Người "thua" có được giải thích lý do không | ⚠ nếu buộc phải forcing thì tối thiểu phải làm điều này |

Và điều đáng tiếc nhất trong tình huống này: đề nói rõ "cả hai đều có luận điểm tốt". Đó chính là điều kiện lý tưởng để hợp tác — và Kelly đã đổi một giải pháp có thể tốt hơn lấy một quyết định nhanh hơn.

Câu 152
You are the project manager for the OOG Project for your organization and you’re meeting with your project team. Some of the team members are debating the order and timing of the activities for your project schedule. Frank, the database administrator, states the ordering of the activities must happen in a particular sequence to set up a new server. What type of dependencies is Frank describing?
  1. A Discretionary
  2. B Mandatory
  3. C Required
  4. D Technical
Xem giải thích

Đáp án

B — Mandatory (phụ thuộc bắt buộc).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ "PHẢI xảy ra theo một trình tự cụ thể" | ⚠ → không có lựa chọn nào khác | | ⚠ Để dựng một máy chủ mới | ⚠ → ràng buộc về bản chất kỹ thuật: cài hệ điều hành trước rồi mới cài cơ sở dữ liệu | | ⚠ Frank là quản trị viên cơ sở dữ liệu | ⚠ → nói với tư cách chuyên môn về ràng buộc thật | | ⚠ Kết luận | ⚠ mandatory dependency, còn gọi HARD LOGIC |

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

  • A (Discretionary — tuỳ chọn) — ⚠ là thứ tự do đội CHỌN theo thực hành tốt, ⚠ đổi được; ⚠ đề nói "PHẢI theo trình tự" nên không phải.

  • D (Technical) — ⚠ mô tả đúng bản chất nhưng KHÔNG phải tên phân loại của PMBOK; ⚠ tên chuẩn là "mandatory" hoặc "hard logic"; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • C (Required) — ⚠ cũng không phải thuật ngữ PMBOK.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25642 ở lô này về soft logic — ⚠ hai việc có thể làm theo thứ tự nào cũng được. ⚠ Hai câu là cặp đối lập hoàn chỉnh. ⚠ Và câu #25623 ở lô trước về JIT, nơi một ràng buộc tưởng bắt buộc thực ra chỉ là thói quen.

⚠ Bốn loại phụ thuộc: | Loại | Nghĩa | Đổi được không | |---|---|---| | ⚠ Mandatory (hard logic) | ⚠ bắt buộc về bản chất công việc hoặc hợp đồng | ⚠ KHÔNG | | ⚠ Discretionary (soft logic) | ⚠ do đội chọn, dựa trên kinh nghiệm và thực hành tốt | ⚠ CÓ | | ⚠ External | ⚠ phụ thuộc thứ ngoài dự án: giấy phép, nhà cung cấp, thời tiết | ⚠ thường không | | ⚠ Internal | ⚠ giữa các công việc trong nội bộ đội | ⚠ tuỳ trường hợp | | ⚠ Kết hợp | ⚠ một phụ thuộc có thể vừa mandatory vừa internal, hoặc vừa mandatory vừa external |

Từ khoá nhận diện:

"phải theo trình tự này, không có cách khác" → ⚠ mandatory / hard logic "chúng tôi vẫn quen làm theo thứ tự này" → ⚠ discretionary / soft logic "chờ giấy phép, chờ hàng về" → ⚠ external "về mặt vật lý không thể đảo ngược" → ⚠ mandatory

⚠ Hai nguồn của phụ thuộc bắt buộc Nguồn
⚠ Bản chất công việc ⚠ đổ móng trước khi xây tường, cài hệ điều hành trước khi cài phần mềm
⚠ Hợp đồng hoặc quy định pháp lý ⚠ phải nghiệm thu giai đoạn trước mới được làm giai đoạn sau
⚠ Cả hai ⚠ đều KHÔNG đàm phán được trong phạm vi lịch trình
⚠ Vì sao phải phân biệt cho đúng Lý do
⚠ Chỉ soft logic mới FAST-TRACK được
⚠ Gán nhầm hard thành soft là gây rủi ro kỹ thuật thật
⚠ Gán nhầm soft thành hard là bỏ mất cơ hội rút ngắn lịch
⚠ Cách kiểm tra ⚠ hỏi "nếu đảo thứ tự thì chuyện gì XẢY RA?" — nếu chỉ là bất tiện thì đó là soft logic

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi phụ thuộc trong lịch có ghi rõ loại không | | | Có ràng buộc nào bị gán nhầm là bắt buộc không | ⚠ hỏi lại chuyên gia kỹ thuật | | Đường găng có bị kéo dài bởi soft logic không | ⚠ đó là chỗ rút ngắn được |

Và câu hỏi duy nhất cần đặt để phân loại: "nếu làm ngược thứ tự thì hỏng thật hay chỉ khó chịu?". Hỏng thật là bắt buộc; khó chịu là tuỳ chọn — và tuỳ chọn thì đàm phán được.

Câu 153
Holly is a project manager in her organization and she is leading a project in an adaptive project life cycle. She and the project team are working with Grace, the product owner for the project, throughout the project to identify, prioritize, and delivery the requirements of the project. In this approach, what two project management processes must be repeated in each iteration for Grace?
  1. A Project planning and project execution
  2. B Quality assurance and quality control
  3. C Validate scope and control scope
  4. D Stakeholder identification and Identify risk
Xem giải thích

Đáp án

C — Validate Scope và Control Scope (xác nhận phạm vi và kiểm soát phạm vi).

Vì sao đúng

⚠ Vai trò của product owner trong mỗi vòng lặp: | Việc | Quy trình tương ứng | |---|---| | ⚠ Grace XEM XÉT và CHẤP NHẬN phần bàn giao của vòng lặp | ⚠ VALIDATE SCOPE — ở agile là buổi iteration review / demo | | ⚠ Grace SẮP XẾP LẠI ƯU TIÊN backlog cho vòng tiếp theo | ⚠ CONTROL SCOPE — điều chỉnh phạm vi có kiểm soát | | ⚠ Cả hai LẶP LẠI ở MỌI vòng lặp | ⚠ đây là điểm khác biệt lớn nhất so với vòng đời dự đoán | | ⚠ Trong dự án dự đoán | ⚠ nghiệm thu thường dồn về cuối giai đoạn hoặc cuối dự án |

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

  • A (lập kế hoạch và thực hiện dự án) — ⚠ đúng là chúng cũng lặp lại, ⚠ nhưng đề hỏi riêng về ⚠ vai trò của GRACE — product owner, ⚠ và product owner không phải người thực hiện công việc kỹ thuật.

  • B (đảm bảo chất lượng và kiểm soát chất lượng) — ⚠ thuộc trách nhiệm của ĐỘI, ⚠ không phải của product owner.

  • D (nhận diện bên liên quan và nhận diện rủi ro) — ⚠ có diễn ra liên tục nhưng ⚠ không phải hai quy trình gắn với vai trò product owner ở mỗi vòng lặp.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25666 ở lô này về Control Quality rồi Validate Scope. ⚠ Trong agile, chuỗi đó lặp lại mỗi vòng lặp thay vì diễn ra một lần ở cuối.

⚠ Vai trò của product owner: | Việc | Nội dung | |---|---| | ⚠ SỞ HỮU và sắp xếp ưu tiên product backlog | | | ⚠ Đại diện tiếng nói của khách hàng và người dùng | | | ⚠ Làm rõ yêu cầu cho đội | | | ⚠ CHẤP NHẬN hoặc từ chối kết quả mỗi vòng lặp | ⚠ đây là Validate Scope | | ⚠ Quyết định thứ tự làm gì trước | ⚠ đây là Control Scope | | ⚠ Không làm | ⚠ không quản lý con người, không giao việc cho từng thành viên |

Từ khoá nhận diện:

"chấp nhận bàn giao ở cuối mỗi vòng lặp" → ⚠ Validate Scope "sắp xếp lại ưu tiên backlog" → ⚠ Control Scope "đội tự kiểm thử chất lượng" → ⚠ Control Quality "buổi nhìn lại cách làm việc" → ⚠ retrospective — cải tiến quy trình

⚠ Vì sao agile phải lặp hai quy trình này liên tục Lý do
⚠ Phạm vi CỐ Ý để mở, chi tiết hoá dần
⚠ Phản hồi sớm và thường xuyên là giá trị cốt lõi
⚠ Chờ tới cuối mới nghiệm thu là mất hết ưu thế của agile
⚠ Ưu tiên thay đổi theo giá trị kinh doanh
⚠ Hệ quả ⚠ thay đổi phạm vi là chuyện BÌNH THƯỜNG, không phải sự cố cần kiểm soát thay đổi nặng nề
⚠ So sánh vòng đời dự đoán và thích ứng Điểm khác
⚠ Dự đoán: phạm vi chốt sớm, thay đổi tốn kém
⚠ Thích ứng: phạm vi mở, thay đổi được kỳ vọng
⚠ Dự đoán: nghiệm thu dồn về cuối
⚠ Thích ứng: nghiệm thu MỖI vòng lặp
⚠ Dự đoán: kế hoạch chi tiết từ đầu
⚠ Thích ứng: kế hoạch chi tiết cho vòng lặp gần nhất ⚠ giống rolling wave planning

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Product owner có tham dự buổi review mỗi vòng lặp không | ⚠ vắng mặt là hỏng cơ chế phản hồi | | Backlog có được sắp lại ưu tiên đều đặn không | | | Tiêu chí chấp nhận có rõ trước khi bắt đầu vòng lặp không | ⚠ definition of done |

Và điểm mấu chốt của cách làm thích ứng: nghiệm thu không phải một sự kiện ở cuối dự án mà là một nhịp lặp lại. Chính nhịp đó biến thay đổi từ rủi ro thành lợi thế.

Câu 154
You are the project manager for your organization and your project is to remodel a condo for a client. The client has selected all the items to be included with the remodeling and you and the team are working on implementing the plan. As the project nears the end of the timeline, the customer requests that you change out some of the fixtures for some new fixtures she has found in Paris. You really don’t want to do this as you’re almost done with all the project, but the customer is willing to pay for the cost of the installation. What should you do next?
  1. A Submit a change request
  2. B Ask the project team if they have enough time to install the fixtures
  3. C Refuse to install the fixtures
  4. D Install the fixtures
Xem giải thích

Đáp án

A — Nộp một yêu cầu thay đổi (submit a change request).

Vì sao đúng

⚠ Nguyên tắc bất di bất dịch: | Nguyên tắc | Nội dung | |---|---| | ⚠ MỌI thay đổi phạm vi phải qua yêu cầu thay đổi chính thức | | | ⚠ Khách hàng sẵn sàng TRẢ TIỀN cũng KHÔNG thay đổi điều đó | ⚠ tiền chỉ là một trong nhiều tác động | | ⚠ PM KHÔNG có quyền tự duyệt thay đổi phạm vi | | | ⚠ Sở thích cá nhân của PM cũng không phải căn cứ | ⚠ "tôi không muốn làm" không phải lý do từ chối | | ⚠ Việc của PM | ⚠ ghi nhận, đánh giá tác động, đưa qua quy trình — không tự quyết |

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

  • D (cứ lắp thiết bị mới) — ⚠ bỏ qua kiểm soát thay đổi; ⚠ chính là scope creep dù khách trả tiền.

  • C (từ chối lắp) — ⚠ PM không có thẩm quyền từ chối đơn phương; ⚠ và từ chối vì "sắp xong rồi, ngại làm" là lý do cá nhân, không phải lý do nghiệp vụ.

  • B (hỏi đội xem còn đủ thời gian không) — ⚠ hỏi đội là việc CẦN nhưng thuộc bước ĐÁNH GIÁ TÁC ĐỘNG, ⚠ diễn ra SAU khi yêu cầu thay đổi được ghi nhận; ⚠ đây là phương án gây nhiễu mạnh nhất vì nghe rất hợp lý.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25643 ở lô này về scope creep và câu #25600 ở lô trước về việc ⚠ PM không tự ý sửa phạm vi. ⚠ Ba câu cùng khẳng định một nguyên tắc.

⚠ Quy trình xử lý yêu cầu thay đổi: | Bước | Việc | |---|---| | ⚠ 1. GHI NHẬN yêu cầu bằng văn bản | ⚠ bước bạn đang ở — nộp change request | | ⚠ 2. ĐÁNH GIÁ TÁC ĐỘNG | ⚠ phạm vi, lịch, chi phí, chất lượng, rủi ro, nguồn lực, hợp đồng | | ⚠ 3. Trình CCB hoặc người có thẩm quyền | | | ⚠ 4. Phê duyệt, từ chối, hoặc hoãn | | | ⚠ 5. Nếu duyệt: CẬP NHẬT đường cơ sở và các kế hoạch | | | ⚠ 6. Thông báo cho mọi bên liên quan | | | ⚠ 7. Thực hiện | |

Từ khoá nhận diện:

"khách hàng xin thêm/đổi thứ gì" → ⚠ luôn là yêu cầu thay đổi "khách sẵn sàng trả tiền" → ⚠ KHÔNG bỏ qua được quy trình "bạn nên làm gì TIẾP THEO" → ⚠ bước đầu tiên của quy trình, không phải bước giữa "PM tự quyết" → ⚠ hầu như luôn là đáp án SAI

⚠ Vì sao tiền không giải quyết được vấn đề Lý do
⚠ Thay đổi ảnh hưởng LỊCH TRÌNH ⚠ dự án sắp xong, lắp thêm là kéo dài
⚠ Ảnh hưởng NGUỒN LỰC ⚠ đội có thể đã được phân sang dự án khác
⚠ Thiết bị mua từ Paris có rủi ro giao hàng và tương thích
⚠ Ảnh hưởng bảo hành và trách nhiệm ⚠ thiết bị khách tự chọn thì ai chịu trách nhiệm?
⚠ Vì thế ⚠ phải đánh giá đủ mọi mặt, không chỉ mặt chi phí lắp đặt
⚠ Điều PM cần tránh trong tình huống này Tránh
⚠ Để cảm xúc cá nhân chi phối ⚠ "tôi không muốn làm" không phải căn cứ nghiệp vụ
⚠ Hứa với khách trước khi đánh giá
⚠ Từ chối thẳng mà không giải thích quy trình
⚠ Nên nói với khách ⚠ "tôi sẽ ghi nhận yêu cầu này và đánh giá đầy đủ tác động rồi phản hồi chị"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu đã được ghi thành văn bản chưa | | | Bạn đã đánh giá đủ mọi tác động chưa | ⚠ không chỉ chi phí | | Ai là người có thẩm quyền phê duyệt | |

Và điều dễ nhất để nhớ trong dạng câu này: khi khách hàng xin thay đổi, việc TIẾP THEO của PM luôn là mở yêu cầu thay đổi — không phải làm, không phải từ chối, không phải hỏi đội.

Câu 155
Jon is the project manager of the JKJ Project for his organization and he’s meeting with a large group of stakeholders next week to identify the project risks. Jon knows that some of the risks identified in this meeting are important for the project, but may be sensitive to some of the managers and stakeholders involved. He wants to avoid some of the stakeholders not identifying risks because of politics or fear or backlash. What should Jon do next?
  1. A Implement the Delphi Technique for the participants
  2. B Divide the group to avoid the conflicts but to still capture the risks
  3. C Utilize a moderator and project meeting rules to keep conflicts down
  4. D Establish quiet writing to capture risks in the project meeting
Xem giải thích

Đáp án

A — Áp dụng kỹ thuật Delphi cho những người tham gia.

Vì sao đúng

⚠ Kỹ thuật Delphi giải quyết đúng nỗi lo của Jon: | Vấn đề Jon lo | Delphi giải quyết thế nào | |---|---| | ⚠ Bên liên quan sợ chính trị nội bộ | ⚠ trả lời ẨN DANH — không ai biết ai nêu ý gì | | ⚠ Sợ bị trả đũa | ⚠ người điều phối tổng hợp, không lộ danh tính | | ⚠ Người có chức vụ cao lấn át người khác | ⚠ không họp trực tiếp nên không có áp lực nhóm | | ⚠ Cần ý kiến của nhiều chuyên gia | ⚠ nhiều VÒNG hỏi, mỗi vòng có phản hồi tổng hợp để chỉnh ý kiến | | ⚠ Kết quả | ⚠ đạt đồng thuận mà không ai bị lộ mặt |

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

  • D (viết yên lặng trong buổi họp) — ⚠ giống brainwriting, ⚠ giảm được ảnh hưởng lời nói nhưng ⚠ mọi người vẫn ngồi cùng phòng và giấy vẫn có thể truy ra ai viết; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • C (dùng người điều phối và quy tắc họp) — ⚠ giúp giảm xung đột nhưng KHÔNG giải quyết nỗi sợ: ⚠ ai nói gì vẫn lộ rõ.

  • B (chia nhóm để tránh xung đột) — ⚠ né tránh vấn đề, ⚠ và vẫn không ẩn danh trong từng nhóm nhỏ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25584 ở lô trước về brainwriting. ⚠ Cả hai đều giảm ảnh hưởng của người nói to nhất, nhưng chỉ Delphi mới cho ẩn danh hoàn toàn và nhiều vòng.

⚠ Quy trình kỹ thuật Delphi: | Bước | Việc | |---|---| | ⚠ 1. Chọn nhóm CHUYÊN GIA | | | ⚠ 2. Gửi bảng hỏi ẨN DANH | ⚠ không ai biết ai khác tham gia | | ⚠ 3. Tổng hợp câu trả lời | ⚠ người điều phối làm, giữ kín danh tính | | ⚠ 4. Gửi lại bản tổng hợp cho mọi người | ⚠ để họ xem ý kiến chung | | ⚠ 5. LẶP LẠI vòng hỏi | ⚠ chuyên gia có thể chỉnh ý kiến sau khi thấy tổng hợp | | ⚠ 6. Dừng khi ý kiến HỘI TỤ | ⚠ thường 2–3 vòng |

Từ khoá nhận diện:

"ẩn danh, nhiều vòng, chuyên gia, đồng thuận" → ⚠ Delphi "viết ý tưởng riêng rồi mới thảo luận chung" → ⚠ brainwriting "nói to ý tưởng trong nhóm" → ⚠ brainstorming "bỏ phiếu và thảo luận qua nhiều vòng có thứ hạng" → ⚠ nominal group technique "phân nhóm số lượng lớn ý tưởng" → ⚠ affinity diagram

⚠ So sánh các kỹ thuật thu thập ý kiến Kỹ thuật
⚠ Brainstorming ⚠ nhanh, nhiều ý tưởng, nhưng bị chi phối bởi người nói nhiều
⚠ Brainwriting ⚠ viết trước rồi mới bàn, giảm ảnh hưởng lời nói
⚠ Nominal group technique ⚠ brainstorming + bỏ phiếu xếp hạng
⚠ Delphi ⚠ ẨN DANH, nhiều vòng, chuyên gia — tốt nhất khi có vấn đề nhạy cảm
⚠ Điểm mạnh riêng của Delphi ⚠ loại bỏ hoàn toàn áp lực nhóm và thứ bậc
⚠ Nhược điểm của Delphi cần biết Nhược điểm
⚠ TỐN THỜI GIAN — nhiều vòng gửi qua gửi lại
⚠ Không có tương tác trực tiếp nên mất phần bồi đắp ý tưởng cho nhau
⚠ Phụ thuộc nhiều vào người điều phối ⚠ họ tổng hợp và có thể vô tình thiên lệch
⚠ Khi nào KHÔNG nên dùng ⚠ khi cần quyết nhanh, hoặc vấn đề không nhạy cảm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vấn đề có thật sự nhạy cảm không | ⚠ nếu không thì brainstorming nhanh hơn nhiều | | Người điều phối có đủ trung lập không | | | Bạn có đủ thời gian cho 2–3 vòng không | |

Và lý do Delphi vẫn được dùng sau nửa thế kỷ: rủi ro nguy hiểm nhất thường là rủi ro không ai dám nói ra trong phòng họp. Ẩn danh là cách duy nhất để những rủi ro đó xuất hiện trên giấy.

Câu 156
You are the project manager of the IHI Project for your organization. You are considering outsourcing a portion of the project to a vendor. You are interested in the price of the vendor completing the writing of the technical manual for the software your project team is creating. What documents should you send to vendors?
  1. A RFP and SOW
  2. B Bid and SOW
  3. C IFB and SOW
  4. D RFP and invitation to bidders’ conference
Xem giải thích

Đáp án

C — IFB và SOW (Invitation for Bid + Statement of Work).

Vì sao đúng

⚠ Dấu hiệu quyết định trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ "bạn quan tâm tới GIÁ của nhà cung cấp" | ⚠ → tiêu chí chọn là GIÁ | | ⚠ Công việc đã rõ ràng | ⚠ viết tài liệu kỹ thuật cho phần mềm | | ⚠ Khi phạm vi rõ và chỉ cần so giá | ⚠ → dùng IFB (Invitation for Bid), còn gọi RFB | | ⚠ SOW luôn đi kèm | ⚠ statement of work mô tả công việc cần làm — không có nó thì nhà cung cấp không báo giá được |

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

  • A (RFP và SOW) — ⚠ RFP dùng khi cần nhà cung cấp ĐỀ XUẤT GIẢI PHÁP, ⚠ không chỉ báo giá; ⚠ đề nói rõ chỉ quan tâm giá nên IFB phù hợp hơn; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • B (Bid và SOW) — ⚠ "bid" là thứ nhà cung cấp GỬI LẠI cho bạn, ⚠ không phải thứ bạn gửi đi.

  • D (RFP và thư mời hội nghị nhà thầu) — ⚠ thiếu SOW, ⚠ mà SOW là tài liệu bắt buộc; ⚠ thư mời hội nghị là bước sau.

Ghi nhớ

⚠ Ba loại tài liệu mời thầu — phân biệt theo TIÊU CHÍ CHỌN: | Tài liệu | Dùng khi | Tiêu chí chính | |---|---|---| | ⚠ IFB / RFB — Invitation for Bid | ⚠ phạm vi RẤT RÕ, chỉ cần so giá | ⚠ GIÁ | | ⚠ RFP — Request for Proposal | ⚠ cần nhà cung cấp đề xuất CÁCH LÀM | ⚠ giải pháp, năng lực, giá | | ⚠ RFQ — Request for Quotation | ⚠ mua hàng hoá tiêu chuẩn, số lượng nhỏ | ⚠ báo giá đơn giản | | ⚠ Mẹo nhớ | ⚠ BID = đấu GIÁ; PROPOSAL = đề xuất GIẢI PHÁP; QUOTATION = báo GIÁ nhanh |

⚠ SOW — Statement of Work: | Điều | Nội dung | |---|---| | ⚠ Mô tả CÔNG VIỆC cần nhà cung cấp thực hiện | | | ⚠ Đủ chi tiết để nhà cung cấp báo giá được | | | ⚠ Là cơ sở để đánh giá công việc sau này | | | ⚠ Ba loại SOW | ⚠ performance (mô tả kết quả), functional (mô tả chức năng), design (mô tả chính xác cách làm) | | ⚠ Đừng nhầm với | ⚠ project scope statement — đó là tài liệu nội bộ của dự án |

Từ khoá nhận diện:

"chỉ quan tâm giá" → ⚠ IFB "cần họ đề xuất cách làm" → ⚠ RFP "mua hàng tiêu chuẩn" → ⚠ RFQ "tài liệu bạn GỬI ĐI" → ⚠ IFB/RFP/RFQ + SOW "tài liệu nhà cung cấp GỬI LẠI" → ⚠ bid / proposal / quote

⚠ Chuỗi tài liệu mua sắm theo thứ tự Bước
⚠ 1. Procurement management plan ⚠ kế hoạch mua sắm
⚠ 2. Procurement SOW ⚠ mô tả công việc cho nhà cung cấp
⚠ 3. Bid documents (IFB / RFP / RFQ) ⚠ gửi cho nhà cung cấp
⚠ 4. Bidders' conference ⚠ hội nghị nhà thầu, giải đáp thắc mắc
⚠ 5. Seller proposals ⚠ nhà cung cấp gửi lại
⚠ 6. Source selection criteria ⚠ tiêu chí chấm
⚠ 7. Agreement / Contract ⚠ hợp đồng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phạm vi công việc đã đủ rõ để chỉ so giá chưa | ⚠ chưa rõ mà dùng IFB là mời rắc rối | | SOW có đủ chi tiết để báo giá không | | | Tiêu chí chấm thầu đã định trước chưa | ⚠ định sau khi nhận hồ sơ là mở đường cho thiên vị |

Và cách phân biệt nhanh nhất: IFB hỏi "bao nhiêu tiền", RFP hỏi "làm thế nào và bao nhiêu tiền". Chọn sai loại tài liệu thì hoặc là nhận về những hồ sơ không so sánh được, hoặc là bỏ lỡ giải pháp tốt hơn.

Câu 157

You are the project manager of the GHB Project for your organization. This project is an agile project and is expected to last for 14 months. Your project team has created a charter that identifies their team rules, values, communication guidelines and other agreements that all project team members agree to. Lisa, one of the project team members, has been late on her assignments, has skipped some status meetings, and hasn’t been communicating effectively with the project team and stakeholders. In this instance, who should speak to Lisa about her behavior on the project team?

  1. A Project team
  2. B Lisa’s manager
  3. C Project manager
  4. D Project sponsor
Xem giải thích

Đáp án

A — Project team (đội dự án).

Vì sao đúng

⚠ Nguyên tắc về hiến chương đội: | Nguyên tắc | Nội dung | |---|---| | ⚠ Hiến chương do CHÍNH ĐỘI tạo ra | ⚠ đề nói rõ "your project team has created a charter" | | ⚠ MỌI thành viên đã ĐỒNG Ý với nó | ⚠ "all project team members agree to" | | ⚠ Đã cùng đặt ra thì cùng CHỊU TRÁCH NHIỆM thực thi | | | ⚠ Trong dự án AGILE, đội TỰ QUẢN | ⚠ self-organizing team — càng nhấn mạnh điều này | | ⚠ Kết luận | ⚠ đội nói chuyện với Lisa trước, không phải PM hay quản lý |

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

  • C (Project manager) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ PM chỉ can thiệp ⚠ khi đội đã thử mà không giải quyết được; ⚠ vào cuộc quá sớm là tước quyền tự quản của đội và làm hiến chương mất hiệu lực.

  • B (Quản lý của Lisa) — ⚠ leo thang QUÁ XA: ⚠ đây mới là vi phạm nội bộ đội, ⚠ chưa tới mức đưa ra ngoài.

  • D (Nhà tài trợ dự án) — ⚠ hoàn toàn không phù hợp: ⚠ nhà tài trợ lo business case và nguồn lực, ⚠ không xử lý hành vi từng thành viên.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25632 ở lô trước — ⚠ Sandy bỏ họp thứ Năm, ⚠ và đáp án cũng là ⚠ ĐỘI thực thi quy tắc nền. ⚠ Hai câu gần như song sinh: cùng một nguyên tắc, một câu đặt trong dự án dự đoán, một câu trong dự án agile.

⚠ Team charter — hiến chương đội: | Nội dung điển hình | Mục | |---|---| | ⚠ Giá trị chung của đội | | | ⚠ Hướng dẫn giao tiếp | ⚠ kênh nào, tần suất nào, phản hồi trong bao lâu | | ⚠ Tiêu chí ra quyết định | | | ⚠ Quy trình xử lý xung đột | | | ⚠ Quy tắc họp | | | ⚠ Thoả thuận về hành vi và tôn trọng | | | ⚠ Ai tạo ra | ⚠ CHÍNH ĐỘI, với sự hỗ trợ của PM — không phải PM áp xuống |

Từ khoá nhận diện:

"đội tự đặt ra quy tắc" → ⚠ đội tự thực thi "vi phạm lần đầu / vài lần" → ⚠ giải quyết ở mức thấp nhất trước "đội tự quản trong agile" → ⚠ càng phải để đội xử lý "vi phạm lặp lại dù đội đã nói" → ⚠ lúc đó PM mới vào cuộc

⚠ Thang leo thang khi có vi phạm Bước
⚠ 1. ĐỘI nói chuyện trực tiếp ⚠ bước của tình huống này
⚠ 2. PM nói chuyện riêng nếu vẫn tiếp diễn
⚠ 3. Đưa vào đánh giá hiệu suất
⚠ 4. Trao đổi với quản lý chức năng
⚠ Nguyên tắc ⚠ luôn bắt đầu ở mức thấp nhất có thể
⚠ Vì sao agile đặc biệt nhấn mạnh điều này Lý do
⚠ Đội TỰ TỔ CHỨC là nguyên tắc nền của tuyên ngôn agile
⚠ Scrum Master là LÃNH ĐẠO PHỤC VỤ, không phải sếp
⚠ Trách nhiệm giải trình thuộc về CẢ ĐỘI, không phải từng cá nhân với sếp
⚠ PM/Scrum Master nên làm gì ⚠ tạo điều kiện cho cuộc trò chuyện đó, ví dụ nêu vấn đề trong buổi retrospective
⚠ Cách đội nên nói chuyện với Lisa Cách
⚠ Nói về HÀNH VI cụ thể, không nói về con người ⚠ "ba buổi họp gần đây vắng" thay vì "bạn vô trách nhiệm"
⚠ Nhắc lại thoả thuận CHUNG mà chính Lisa đã đồng ý
⚠ HỎI xem có trở ngại gì không ⚠ có thể Lisa đang gặp vấn đề thật
⚠ Thống nhất bước tiếp theo cụ thể
⚠ Đừng ⚠ nói sau lưng hoặc đi thẳng lên cấp trên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hiến chương đội do ai tạo ra | ⚠ PM áp xuống thì đừng mong đội tự thực thi | | Đội có kỹ năng đưa phản hồi khó không | ⚠ đây là chỗ PM nên huấn luyện | | Đã tìm hiểu nguyên nhân đằng sau chưa | ⚠ hành vi thay đổi thường có lý do |

Và điều PM giỏi làm trong tình huống này: không nói chuyện với Lisa, mà giúp đội có được cuộc trò chuyện đó. Đứng ra thay đội thì lần sau đội lại chờ bạn — và hiến chương chỉ còn là tờ giấy dán tường.

Câu 158
Anna has sent a SOW to 23 vendors for a portion of a construction project. The SOW describes the work in the project, but she has also invited the 23 vendors to a meeting to discuss the SOW and to answer any questions about the project work before the vendors will submit their proposals. What is the name of the meeting that vendors will participate in?
  1. A SOW Clarity Meeting
  2. B SOW Meeting
  3. C Meet-and-Greet Conference
  4. D Bidders’ conference
Xem giải thích

Đáp án

D — Bidders' conference (hội nghị nhà thầu).

Vì sao đúng

⚠ Bidders' conference là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Cuộc họp với TẤT CẢ nhà cung cấp tiềm năng | ⚠ 23 nhà thầu của Anna | | ⚠ Diễn ra TRƯỚC khi nộp hồ sơ dự thầu | | | ⚠ Mục đích: giải đáp thắc mắc về SOW và công việc | | | ⚠ Mọi nhà thầu nghe CÙNG MỘT câu trả lời | ⚠ đảm bảo công bằng — điểm quan trọng nhất | | ⚠ Tên gọi khác | ⚠ vendor conference, pre-bid conference, contractor conference |

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

  • A (SOW Clarity Meeting), B (SOW Meeting), C (Meet-and-Greet Conference) — ⚠ cả ba đều KHÔNG phải thuật ngữ PMBOK; ⚠ chúng nghe hợp lý nhưng là các phương án bịa.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25677 ở lô này về IFB và SOW. ⚠ Hai câu là hai bước liên tiếp của cùng một quy trình mua sắm: gửi tài liệu mời thầu rồi tổ chức hội nghị nhà thầu.

⚠ Vì sao hội nghị nhà thầu quan trọng: | Lý do | Nội dung | |---|---| | ⚠ CÔNG BẰNG | ⚠ mọi nhà thầu nhận cùng thông tin, cùng lúc | | ⚠ MINH BẠCH | ⚠ tránh nghi ngờ ưu ái, đặc biệt trong dự án công | | ⚠ Làm rõ SOW sớm | ⚠ giảm hồ sơ dự thầu dựa trên hiểu nhầm | | ⚠ Hồ sơ dự thầu SO SÁNH được với nhau | ⚠ vì cùng hiểu một đề bài | | ⚠ Rủi ro lớn nhất cần tránh | ⚠ trả lời riêng cho MỘT nhà thầu — đó là hành vi thiên vị |

Từ khoá nhận diện:

"họp với các nhà thầu trước khi nộp hồ sơ" → ⚠ bidders' conference "tài liệu mô tả công việc gửi nhà thầu" → ⚠ SOW "chỉ so giá" → ⚠ IFB "cần họ đề xuất giải pháp" → ⚠ RFP "tiêu chí chấm hồ sơ" → ⚠ source selection criteria

⚠ Nguyên tắc điều hành hội nghị nhà thầu Nguyên tắc
⚠ Mọi câu hỏi và trả lời phải được GHI LẠI
⚠ Phát bản ghi cho TẤT CẢ nhà thầu ⚠ kể cả người không dự
⚠ Không nhận câu hỏi riêng ngoài hội nghị ⚠ hoặc nếu nhận thì phải công bố câu trả lời cho tất cả
⚠ Nếu SOW cần sửa thì phát hành BẢN SỬA ĐỔI chính thức ⚠ addendum
⚠ Người điều hành ⚠ thường là bộ phận mua sắm, không phải PM một mình
⚠ Các bước Conduct Procurements Bước
⚠ 1. Phát hành tài liệu mời thầu ⚠ IFB / RFP / RFQ kèm SOW
⚠ 2. Tổ chức hội nghị nhà thầu ⚠ bước của câu này
⚠ 3. Nhận hồ sơ dự thầu
⚠ 4. Chấm theo tiêu chí đã định trước
⚠ 5. Đàm phán hợp đồng
⚠ 6. Ký hợp đồng và chọn nhà cung cấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi nhà thầu có nhận cùng thông tin không | ⚠ kể cả người vắng mặt | | Câu hỏi và trả lời có được ghi lại không | | | Có ai được trả lời riêng không | ⚠ đó là rủi ro pháp lý và uy tín |

Và lý do bước này không được bỏ qua dù mất thời gian: hồ sơ dự thầu chỉ so sánh được khi mọi người hiểu cùng một đề bài. 23 nhà thầu hiểu 23 kiểu thì bảng chấm điểm trở nên vô nghĩa.

Câu 159
You are a project manager for the POA Project for your organization. You are reviewing the WBS with the project team to define the project activities. What component of the WBS should you be focusing on when creating the activities list with the project team?
  1. A Affinity items
  2. B Cost estimates
  3. C Duration estimates
  4. D Work packages
Xem giải thích

Đáp án

D — Work packages (gói công việc).

Vì sao đúng

⚠ Chuỗi phân rã từ WBS tới hoạt động: | Cấp | Nội dung | |---|---| | ⚠ Control account | ⚠ điểm quản lý để đo giá trị thu được | | ⚠ Planning package | ⚠ biết việc, chưa phân rã chi tiết | | ⚠ WORK PACKAGE | ⚠ mức THẤP NHẤT của WBS — điểm dừng của cây phân rã | | ⚠ ACTIVITY | ⚠ phân rã tiếp từ gói công việc, KHÔNG còn thuộc WBS | | ⚠ Vì thế | ⚠ lập danh sách hoạt động thì lấy GÓI CÔNG VIỆC làm đầu vào |

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

  • B (Cost estimates) và C (Duration estimates) — ⚠ là KẾT QUẢ có được SAU khi đã có danh sách hoạt động, ⚠ không phải đầu vào; ⚠ đảo ngược trình tự.

  • A (Affinity items) — ⚠ không phải thành phần của WBS; ⚠ affinity diagram là kỹ thuật phân nhóm ý tưởng, ⚠ không liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25627 ở lô trước về planning package và câu #25657 ở lô này về code of accounts. ⚠ Ba câu vẽ đủ bức tranh về cấu trúc WBS.

⚠ Quy trình Define Activities: | Mục | Nội dung | |---|---| | ⚠ Thuộc nhóm | ⚠ Lập kế hoạch | | ⚠ Thuộc nhóm kiến thức | ⚠ Project Schedule Management | | ⚠ Đầu vào chính | ⚠ scope baseline — trong đó có WBS và các GÓI CÔNG VIỆC | | ⚠ Kỹ thuật | ⚠ decomposition, rolling wave planning, phán đoán chuyên gia | | ⚠ Đầu ra | ⚠ activity list, activity attributes, milestone list, cập nhật đường cơ sở |

Từ khoá nhận diện:

"mức thấp nhất của WBS" → ⚠ work package "phân rã tiếp gói công việc" → ⚠ activity — không còn thuộc WBS "đánh dấu để lập kế hoạch sau" → ⚠ planning package "điểm đo giá trị thu được" → ⚠ control account

⚠ Ranh giới quan trọng phải thuộc Ranh giới
⚠ WBS dừng ở GÓI CÔNG VIỆC ⚠ đây là mức thấp nhất của WBS
⚠ HOẠT ĐỘNG nằm NGOÀI WBS ⚠ thuộc về lịch trình, không thuộc phạm vi
⚠ Gói công việc là DANH TỪ ⚠ "Tài liệu hướng dẫn sử dụng"
⚠ Hoạt động là ĐỘNG TỪ ⚠ "Viết chương 1", "Rà soát", "Biên tập"
⚠ Mẹo phân biệt ⚠ gói công việc là KẾT QUẢ, hoạt động là VIỆC PHẢI LÀM để có kết quả đó
⚠ Chuỗi quy trình lập lịch theo thứ tự Bước
⚠ 1. Plan Schedule Management
⚠ 2. Define Activities ⚠ từ gói công việc — bước của câu này
⚠ 3. Sequence Activities ⚠ nối các hoạt động, xác định phụ thuộc
⚠ 4. Estimate Activity Durations
⚠ 5. Develop Schedule ⚠ ra đường găng và đường cơ sở lịch
⚠ 6. Control Schedule ⚠ thuộc nhóm giám sát và kiểm soát

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi gói công việc đều có ít nhất một hoạt động chứ | ⚠ gói không có hoạt động là gói bị bỏ quên | | Hoạt động có phân rã quá vụn không | ⚠ quản lý hoạt động một giờ là tốn công hơn giá trị thu được | | Danh sách hoạt động có bao phủ 100% WBS không | |

Và ranh giới hay bị lẫn nhất trong dạng câu này: WBS nói VỀ CÁI GÌ phải giao, lịch trình nói VỀ VIỆC gì phải làm. Gói công việc là điểm giao nhau giữa hai thế giới đó.

Câu 160
Management has asked you, the project manager of the JHK Project, to create a project website dashboard that will allow stakeholders to query the project status, check milestones, and other project information at any time. You task Gene, a project team member, with creating this website. What type of communication are you creating for stakeholders?
  1. A Persistent
  2. B Pull
  3. C One-to-one
  4. D Receiver-only
Xem giải thích

Đáp án

B — Pull (giao tiếp kéo).

Vì sao đúng

⚠ Ba phương pháp giao tiếp của PMBOK: | Phương pháp | Nghĩa | Ví dụ | |---|---|---| | ⚠ Interactive — tương tác | ⚠ trao đổi HAI CHIỀU, thời gian thực | ⚠ họp, gọi điện, gọi video, trò chuyện trực tiếp | | ⚠ Push — đẩy | ⚠ GỬI thông tin tới người nhận cụ thể | ⚠ email, báo cáo, thư, bản tin | | ⚠ Pull — kéo | ⚠ người nhận TỰ TRUY CẬP khi họ cần | ⚠ trang thông tin, kho tài liệu, bảng điều khiển, wiki |

⚠ Vì sao tình huống này là pull: | Chi tiết | Suy ra | |---|---| | ⚠ Trang thông tin dự án | ⚠ → nơi lưu trữ thông tin | | ⚠ Bên liên quan TRA CỨU trạng thái | ⚠ → họ chủ động lấy | | ⚠ "bất cứ lúc nào" | ⚠ → không do bạn quyết định thời điểm gửi | | ⚠ Kết luận | ⚠ đúng định nghĩa pull communication |

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

  • A (Persistent) và D (Receiver-only) — ⚠ không phải phương pháp giao tiếp trong PMBOK.

  • C (One-to-one — một đối một) — ⚠ mô tả SỐ NGƯỜI tham gia, ⚠ không phải phương pháp; ⚠ và trang thông tin phục vụ nhiều người cùng lúc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25604 ở lô trước về mô hình giao tiếp và câu #25620 về số kênh giao tiếp. ⚠ Ba câu cùng thuộc nhóm kiến thức quản lý giao tiếp.

Từ khoá nhận diện:

"trang thông tin, kho tài liệu, wiki, bảng điều khiển" → ⚠ pull "email, báo cáo gửi đi, bản tin" → ⚠ push "họp, gọi điện, trao đổi trực tiếp" → ⚠ interactive "người nhận tự lấy khi cần" → ⚠ pull "tôi gửi và mong họ đọc" → ⚠ push

⚠ Chọn phương pháp nào cho tình huống nào Nguyên tắc
⚠ Thông tin PHỨC TẠP, cần bàn bạc ⚠ INTERACTIVE — hiệu quả nhất nhưng tốn thời gian nhất
⚠ Thông tin quan trọng, cần đảm bảo người ta NHẬN được ⚠ PUSH
⚠ Khối lượng thông tin LỚN, nhiều người cần, mức quan tâm khác nhau ⚠ PULL
⚠ Thực tế ⚠ hầu hết dự án dùng cả ba, tuỳ loại thông tin và tuỳ bên liên quan
⚠ Điểm yếu quan trọng của pull Điểm yếu
⚠ KHÔNG đảm bảo người ta đã đọc ⚠ đặt lên web không có nghĩa là đã truyền đạt
⚠ Không dùng cho thông tin KHẨN CẤP
⚠ Không dùng cho thông tin CẦN HÀNH ĐỘNG NGAY
⚠ Cách bù ⚠ kết hợp: đưa chi tiết lên web (pull) và gửi email báo có bản cập nhật (push)
⚠ Ưu điểm của trang thông tin dự án Ưu điểm
⚠ Giảm số email và số cuộc họp báo cáo
⚠ Mọi người nhìn cùng MỘT nguồn dữ liệu ⚠ tránh tình trạng mỗi người cầm một bản khác nhau
⚠ Bên liên quan xem đúng thứ họ quan tâm
⚠ Có lịch sử, tra cứu lại được
⚠ Điều kiện để thành công ⚠ phải CẬP NHẬT đều — trang thông tin cũ còn tệ hơn không có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thông tin quan trọng có được đẩy đi không | ⚠ đừng chỉ dựa vào pull | | Trang thông tin có được cập nhật đều không | | | Kế hoạch quản lý giao tiếp có ghi rõ dùng phương pháp nào cho ai không | |

Và cạm bẫy lớn nhất của giao tiếp kéo: "tôi đã đăng lên trang dự án rồi" không phải là đã thông báo. Thông tin quan trọng vẫn phải được đẩy tới đúng người, đúng lúc.