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

Tìm thấy 201 câu.

Câu 171
Karen is the project manager of a high-profile project in her organization. She is meeting with the key project stakeholders to identify the risks of this project and she wants to consider several factors in this meeting to get a comprehensive collection of risks to manage in the project. Karen informs the group that they’ll be using the PESTLE approach to risk identification based on the size of the project. What is PESTLE?
  1. A Political, Economic, Social, Timetables, Legal, and Environmental domains
  2. B Parity, Economic, Social, Timetables, Legal, and Environmental domains
  3. C Political, Economic, Social, Technological, Legal, and Environmental domains
  4. D Planned value, Earned Value, Schedule Performance Index, TCPI, Little’s Law, and Expected Value domains
Xem giải thích

Đáp án

C — Political, Economic, Social, Technological, Legal, and Environmental (chính trị, kinh tế, xã hội, công nghệ, pháp lý, môi trường).

Vì sao đúng

⚠ PESTLE — sáu miền phân tích môi trường bên ngoài: | Chữ | Miền | Ví dụ rủi ro cho dự án | |---|---|---| | ⚠ P — Political | ⚠ CHÍNH TRỊ | ⚠ đổi chính sách, bất ổn, thay đổi lãnh đạo cơ quan quản lý | | ⚠ E — Economic | ⚠ KINH TẾ | ⚠ lạm phát, tỷ giá, lãi suất, suy thoái | | ⚠ S — Social | ⚠ XÃ HỘI | ⚠ thay đổi nhân khẩu, thói quen người dùng, dư luận | | ⚠ T — Technological | ⚠ CÔNG NGHỆ | ⚠ công nghệ mới làm lỗi thời giải pháp đang làm | | ⚠ L — Legal | ⚠ PHÁP LÝ | ⚠ luật mới, quy định về dữ liệu, tiêu chuẩn bắt buộc | | ⚠ E — Environmental | ⚠ MÔI TRƯỜNG | ⚠ thời tiết, yêu cầu bền vững, tác động sinh thái |

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

  • A (…Timetables…) — ⚠ SAI chữ T: ⚠ là "Technological" chứ không phải "Timetables"; ⚠ đây là phương án gây nhiễu mạnh nhất vì chỉ khác một từ.

  • B (Parity… Timetables…) — ⚠ SAI cả chữ P lẫn chữ T.

  • D (Planned value, Earned Value…) — ⚠ là các chỉ số EVM, ⚠ hoàn toàn không liên quan tới PESTLE.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25655 ở lô 178 về SIPOC — ⚠ ở đó PESTLE là phương án nhiễu. ⚠ Hai câu đảo vai cho nhau; nắm cả hai khung là loại được nhiễu ở cả hai câu.

⚠ Các khung phân tích hay ra thi: | Khung | Nội dung | Dùng ở đâu | |---|---|---| | ⚠ PESTLE | ⚠ 6 miền môi trường BÊN NGOÀI | ⚠ nhận diện rủi ro, phân tích bối cảnh | | ⚠ SWOT | ⚠ mạnh, yếu, cơ hội, thách thức | ⚠ nhận diện rủi ro cả tiêu cực lẫn tích cực | | ⚠ SIPOC | ⚠ nhà cung cấp, đầu vào, quy trình, đầu ra, khách hàng | ⚠ phân tích quy trình | | ⚠ RACI | ⚠ làm, chịu trách nhiệm, tham vấn, thông báo | ⚠ phân vai | | ⚠ VUCA | ⚠ biến động, bất định, phức tạp, mơ hồ | ⚠ mô tả môi trường dự án |

Từ khoá nhận diện:

"chính trị, kinh tế, xã hội, công nghệ, pháp lý, môi trường" → ⚠ PESTLE "điểm mạnh, điểm yếu bên trong; cơ hội, thách thức bên ngoài" → ⚠ SWOT "nhà cung cấp và khách hàng của một quy trình" → ⚠ SIPOC "toàn diện, dự án lớn, nhiều yếu tố bên ngoài" → ⚠ dấu hiệu nên dùng PESTLE

⚠ Vì sao Karen chọn PESTLE cho dự án lớn Lý do
⚠ Dự án lớn chịu ảnh hưởng của nhiều yếu tố NGOÀI tầm kiểm soát
⚠ Khung sáu miền đảm bảo không bỏ sót nhóm rủi ro nào
⚠ Dễ chia nhóm thảo luận theo từng miền
⚠ Bổ sung cho các kỹ thuật nhìn vào bên trong dự án ⚠ như phân tích WBS hay phân tích giả định
⚠ Kết hợp tốt với ⚠ SWOT — PESTLE lo phần bên ngoài, SWOT nối bên ngoài với bên trong
⚠ Các kỹ thuật nhận diện rủi ro của PMBOK Kỹ thuật
⚠ Brainstorming
⚠ Checklist dựa trên dự án cũ
⚠ Phỏng vấn chuyên gia
⚠ Phân tích nguyên nhân gốc
⚠ Phân tích giả định và ràng buộc
⚠ SWOT và PESTLE
⚠ Phân tích tài liệu
⚠ Kỹ thuật Delphi ⚠ khi rủi ro nhạy cảm về chính trị nội bộ
⚠ Prompt list ⚠ danh sách gợi ý, PESTLE chính là một prompt list

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã quét đủ sáu miền chưa | ⚠ miền pháp lý và môi trường hay bị bỏ sót nhất | | Rủi ro tìm được đã vào sổ đăng ký rủi ro chưa | | | Có rủi ro nào là CƠ HỘI không | ⚠ PESTLE cũng sinh ra cơ hội, không chỉ mối đe doạ |

Và điểm mạnh của prompt list như PESTLE: nó buộc nhóm nghĩ tới những miền không ai tự nhiên nghĩ tới. Một buổi động não tự do gần như luôn bỏ quên rủi ro pháp lý và rủi ro môi trường.

Câu 172
There are five levels of quality management that any project manager should recognize. Of the five levels, which one is the most expensive?
  1. A Plan and design quality from the beginning of the project.
  2. B Let the customer find the defects.
  3. C Prevent defects through quality assurance programs.
  4. D Find the defects through quality control.
Xem giải thích

Đáp án

B — Để KHÁCH HÀNG tự tìm ra khuyết tật.

Vì sao đúng

⚠ Năm mức quản lý chất lượng, xếp từ RẺ tới ĐẮT: | Mức | Nội dung | Chi phí | |---|---|---| | ⚠ 1. LẬP KẾ HOẠCH và THIẾT KẾ chất lượng ngay từ đầu | ⚠ tốt nhất, rẻ nhất | ⚠ thấp nhất | | ⚠ 2. PHÒNG NGỪA khuyết tật qua chương trình đảm bảo chất lượng | | ⚠ thấp | | ⚠ 3. PHÁT HIỆN khuyết tật qua kiểm soát chất lượng, sửa trước khi giao | | ⚠ trung bình | | ⚠ 4. Chỉ SỬA khuyết tật sau khi bị phát hiện, làm lại | | ⚠ cao | | ⚠ 5. ĐỂ KHÁCH HÀNG TỰ TÌM RA | ⚠ tệ nhất | ⚠ ĐẮT NHẤT |

⚠ Vì sao mức 5 đắt nhất: | Chi phí | Nội dung | |---|---| | ⚠ Chi phí sửa lỗi ở vận hành | ⚠ cao gấp nhiều lần sửa ở giai đoạn thiết kế | | ⚠ Chi phí bảo hành và hỗ trợ | | | ⚠ Chi phí thu hồi hoặc bồi thường | | | ⚠ MẤT UY TÍN — khoản không định giá được | ⚠ và không mua lại được bằng tiền | | ⚠ Mất khách hàng và mất hợp đồng tương lai | | | ⚠ Kết luận | ⚠ đây là chi phí lỗi bên ngoài — external failure cost |

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

  • A (lập kế hoạch và thiết kế chất lượng từ đầu) — ⚠ là mức RẺ NHẤT và TỐT NHẤT, ⚠ ngược hẳn.

  • C (phòng ngừa qua chương trình đảm bảo chất lượng) — ⚠ mức 2, vẫn rất rẻ.

  • D (phát hiện qua kiểm soát chất lượng) — ⚠ mức 3, đắt hơn hai mức trên nhưng RẺ HƠN NHIỀU so với để khách tìm ra.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25639 ở lô 178 — ⚠ chất lượng được LẬP KẾ HOẠCH mà có, không phải KIỂM TRA mà có, ⚠ và câu #25628 về chi phí không phù hợp. ⚠ Ba câu là ba cách hỏi khác nhau về cùng một nguyên tắc kinh tế của chất lượng.

⚠ Quy tắc nhân 10 — chi phí sửa một lỗi theo giai đoạn phát hiện: | Giai đoạn phát hiện | Chi phí tương đối | |---|---| | ⚠ Yêu cầu / thiết kế | ⚠ 1 | | ⚠ Lập trình | ⚠ 10 | | ⚠ Kiểm thử | ⚠ 100 | | ⚠ Vận hành — khách hàng tìm ra | ⚠ 1.000 | | ⚠ Ý nghĩa | ⚠ càng phát hiện muộn càng đắt theo cấp số nhân |

Từ khoá nhận diện:

"khách hàng tìm ra lỗi" → ⚠ mức tệ nhất và đắt nhất "lập kế hoạch chất lượng từ đầu" → ⚠ mức tốt nhất và rẻ nhất "phòng ngừa hơn kiểm tra" → ⚠ nguyên tắc nền của quản lý chất lượng "chi phí lỗi bên ngoài" → ⚠ external failure cost

⚠ Bốn nhóm chi phí chất lượng — nhìn lại Nhóm
⚠ Prevention ⚠ đào tạo, quy trình, thiết kế tốt — ứng với mức 1 và 2
⚠ Appraisal ⚠ kiểm thử, kiểm tra — ứng với mức 3
⚠ Internal failure ⚠ làm lại trước khi giao — ứng với mức 4
⚠ External failure ⚠ khách tìm ra — ứng với mức 5
⚠ Vì sao tổ chức vẫn hay rơi vào mức 5 Lý do
⚠ Chi phí phòng ngừa NHÌN THẤY ĐƯỢC ngay trong ngân sách ⚠ dễ bị cắt
⚠ Chi phí lỗi bên ngoài PHÂN TÁN và đến MUỘN ⚠ khó quy về quyết định đã cắt
⚠ Áp lực tiến độ luôn cụ thể hơn rủi ro chất lượng
⚠ Cách chống ⚠ đo và báo cáo chi phí chất lượng theo cả bốn nhóm, không chỉ nhóm nhìn thấy được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn đang ở mức nào trong năm mức | | | Bạn có đo chi phí lỗi bên ngoài không | ⚠ không đo thì phòng ngừa luôn trông như khoản chi thừa | | Khoản chi chất lượng nào bị cắt gần đây | ⚠ và hậu quả của nó sẽ đến khi nào |

Và cách tóm gọn cả năm mức trong một câu: càng để lỗi đi xa khỏi nơi sinh ra nó, càng phải trả đắt — và điểm xa nhất chính là bàn làm việc của khách hàng.

Câu 173
Jane reports that a project she’d like to implement will be worth $160,000 in five years. Considering the rate of return to be six percent, what’s the minimum amount that should be invested in Jane’s project?
  1. A $160,000
  2. B $154,000
  3. C $119,561
  4. D $13,200
Xem giải thích

Đáp án

C — 119.561.

Vì sao đúng

⚠ Đây là bài toán GIÁ TRỊ HIỆN TẠI (Present Value): | Đại lượng | Giá trị | |---|---| | ⚠ FV — giá trị tương lai | ⚠ 160.000 | | ⚠ r — tỷ suất hoàn vốn | ⚠ 6% = 0,06 | | ⚠ n — số năm | ⚠ 5 |

⚠ Công thức và phép tính: | Bước | Phép tính | |---|---| | ⚠ PV = FV / (1 + r)ⁿ | | | ⚠ (1,06)⁵ | ⚠ = 1,3382255... | | ⚠ 160.000 / 1,3382255 | ⚠ = 119.561,2 | | ⚠ Ý nghĩa | ⚠ bỏ ra tối đa 119.561 hôm nay thì mới hoà vốn với mức sinh lời 6%/năm |

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

  • A (160.000) — ⚠ là giá trị TƯƠNG LAI, ⚠ chưa chiết khấu về hiện tại; ⚠ bỏ ra 160.000 hôm nay để nhận lại đúng 160.000 sau 5 năm là LỖ.

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

  • D (13.200) — ⚠ gần với 160.000 × 6% × ... nhưng không phải phép tính đúng; ⚠ đây là con số nhỏ tới mức vô lý cho một khoản đầu tư sinh ra 160.000.

Ghi nhớ

⚠ Bảng luỹ thừa 1,06 để tính nhanh: | n | (1,06)ⁿ | |---|---| | ⚠ 1 | ⚠ 1,060 | | ⚠ 2 | ⚠ 1,124 | | ⚠ 3 | ⚠ 1,191 | | ⚠ 4 | ⚠ 1,262 | | ⚠ 5 | ⚠ 1,338 | | ⚠ Mẹo nhẩm | ⚠ quy tắc 72: ở 6%/năm thì tiền tăng gấp đôi sau khoảng 12 năm |

Từ khoá nhận diện:

"trị giá X sau N năm, tỷ suất R" → ⚠ tính PV = FV / (1+r)ⁿ "số tiền tối thiểu nên đầu tư" → ⚠ chính là giá trị hiện tại "giá trị hiện tại ròng" → ⚠ NPV = tổng PV các dòng tiền − vốn đầu tư "tỷ suất làm NPV bằng 0" → ⚠ IRR "bao lâu thu hồi vốn" → ⚠ payback period

⚠ Vì sao phải chiết khấu Lý do
⚠ Giá trị thời gian của tiền ⚠ một đồng hôm nay đáng giá hơn một đồng năm sau
⚠ Tiền hôm nay có thể ĐEM ĐẦU TƯ sinh lời
⚠ Có rủi ro và lạm phát trong thời gian chờ
⚠ Vì thế ⚠ so sánh dự án phải quy mọi dòng tiền về CÙNG một thời điểm
⚠ Bốn chỉ số chọn dự án và cách đọc Chỉ số
⚠ NPV ⚠ DƯƠNG là nên làm; so nhiều dự án thì chọn NPV cao nhất
⚠ IRR ⚠ cao hơn chi phí vốn là nên làm; chọn IRR cao nhất
⚠ Payback period ⚠ NGẮN hơn là tốt hơn; nhược điểm: bỏ qua giá trị thời gian của tiền
⚠ BCR — tỷ số lợi ích/chi phí ⚠ lớn hơn 1 là có lợi; chọn cao nhất
⚠ Bẫy thi hay gặp ⚠ "chi phí" nghe càng lớn càng tốt — SAI; với BCR và IRR thì CAO là tốt, với payback thì NGẮN là tốt
⚠ Jane nên trình bày thế nào Cách
⚠ Nêu rõ GIẢ ĐỊNH về tỷ suất 6% ⚠ đổi tỷ suất là đổi kết quả
⚠ Nêu mức đầu tư tối đa hợp lý: 119.561
⚠ Nếu chi phí thực tế thấp hơn con số này thì NPV dương
⚠ Kèm phân tích độ nhạy ⚠ nếu tỷ suất là 8% thì sao?

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ suất chiết khấu lấy từ đâu | ⚠ thường là chi phí vốn của tổ chức | | Dòng tiền có chắc chắn không | ⚠ 160.000 sau 5 năm là ước tính hay cam kết | | Đã so với các phương án đầu tư khác chưa | ⚠ chi phí cơ hội |

Và nguyên tắc cốt lõi cần thuộc: tiền trong tương lai luôn đáng giá ít hơn tiền hôm nay. Mọi phép so sánh dự án đều bắt đầu bằng việc quy mọi con số về cùng một mốc thời gian.

Câu 174
Sam is a project manager in his organization, and he is working with the project sponsor to develop the project charter. This new project will implement a new email program that will allow end users to access their email on their phones and their laptops. The project charter’s primary goal in this scenario is to do what?
  1. A Define the success factors for the project
  2. B Authorize the resources to work on the project team
  3. C Define the end users
  4. D Authorize the project to exist
Xem giải thích

Đáp án

D — Cho phép dự án TỒN TẠI (authorize the project to exist).

Vì sao đúng

⚠ Mục đích CHÍNH của điều lệ dự án: | Điều | Nội dung | |---|---| | ⚠ CHÍNH THỨC cho phép dự án tồn tại | ⚠ đây là mục đích số một theo PMBOK | | ⚠ Do người có thẩm quyền BÊN NGOÀI dự án ban hành | | | ⚠ Không có điều lệ thì dự án KHÔNG TỒN TẠI về mặt chính thức | | | ⚠ Mọi thứ khác | ⚠ bổ nhiệm PM, cấp thẩm quyền, nêu mục tiêu — đều là NỘI DUNG bên trong, không phải MỤC ĐÍCH chính |

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

  • B (cho phép nguồn lực làm việc trong đội dự án) — ⚠ là một HỆ QUẢ của việc dự án được cho phép tồn tại, ⚠ không phải mục đích chính; ⚠ đây là phương án gây nhiễu mạnh nhất.

  • A (xác định các yếu tố thành công) — ⚠ CÓ trong điều lệ nhưng ⚠ chỉ là một mục nội dung.

  • C (xác định người dùng cuối) — ⚠ thuộc về nhận diện bên liên quan và thu thập yêu cầu, ⚠ không phải mục đích của điều lệ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25691 ở lô này — ⚠ không có điều lệ nên quản lý chức năng không nhả người. ⚠ Câu kia cho thấy HẬU QUẢ khi thiếu điều lệ; câu này hỏi thẳng MỤC ĐÍCH của nó. ⚠ Và câu #25586 ở lô 177 về người ban hành.

⚠ Điều lệ dự án — ba điều cốt lõi: | Điều | Nội dung | |---|---| | ⚠ CHO PHÉP dự án tồn tại | ⚠ mục đích chính | | ⚠ BỔ NHIỆM quản lý dự án và nêu thẩm quyền | | | ⚠ Liên kết dự án với MỤC TIÊU CHIẾN LƯỢC của tổ chức | | | ⚠ Đặc điểm | ⚠ là tài liệu ở mức CAO, không phải kế hoạch chi tiết |

Từ khoá nhận diện:

"cho phép dự án tồn tại" → ⚠ điều lệ dự án "nói rõ sẽ làm thế nào, khi nào, tốn bao nhiêu" → ⚠ kế hoạch quản lý dự án "vì sao dự án đáng làm" → ⚠ business case, do nhà tài trợ sở hữu "lợi ích sẽ được đo và duy trì thế nào" → ⚠ benefits management plan

⚠ So sánh ba tài liệu hay lẫn nhau Tài liệu
⚠ Business case ⚠ VÌ SAO làm — do nhà tài trợ sở hữu, có TRƯỚC dự án
⚠ Project charter ⚠ CHO PHÉP làm — do nhà tài trợ ban hành, khởi đầu dự án
⚠ Project management plan ⚠ LÀM THẾ NÀO — do PM sở hữu, chi tiết
⚠ Thứ tự ⚠ business case → charter → management plan
⚠ Vì sao điều lệ không được quá chi tiết Lý do
⚠ Nó được viết KHI CÒN RẤT ÍT THÔNG TIN
⚠ Chi tiết hoá là việc của giai đoạn lập kế hoạch
⚠ Điều lệ chi tiết quá thì mỗi lần điều chỉnh lại phải xin ký lại
⚠ Nội dung điển hình ⚠ mục tiêu, yêu cầu mức cao, mốc tóm tắt, rủi ro tổng thể, ngân sách sơ bộ, bên liên quan, tiêu chí kết thúc
⚠ Điều lệ dự án khác điều lệ ĐỘI Phân biệt
⚠ Project charter ⚠ cho phép DỰ ÁN tồn tại, do NHÀ TÀI TRỢ ban hành
⚠ Team charter ⚠ quy tắc làm việc của ĐỘI, do CHÍNH ĐỘI tạo ra
⚠ Hai thứ khác nhau hoàn toàn ⚠ đây là bẫy quen thuộc trong đề thi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có điều lệ được ký chưa | | | Điều lệ có nêu rõ thẩm quyền của PM không | | | Điều lệ có bị viết quá chi tiết như một kế hoạch không | |

Và câu trả lời gọn nhất cho dạng câu hỏi này: điều lệ dự án là giấy khai sinh của dự án. Mọi thứ khác trong đó chỉ là thông tin ghi trên tờ giấy khai sinh ấy.

Câu 175
A solution that your team is creating will cost $568,000 and will cost $25,000 a month to support. A vendor reports that they can offer you the same solution for no out-of-pocket costs and .08 per transaction. You know that there will be approximately 450,000 transactions per month. What should you do?
  1. A Complete the solution in-house if you’ll keep the solution more than one year.
  2. B Hire the vendor if you’ll keep the solution less than four years.
  3. C Complete the solution in-house if you’ll keep the solution less than four years.
  4. D Hire the vendor if you’ll keep the solution longer than five years.
Xem giải thích

Đáp án

B — Thuê nhà cung cấp nếu sẽ dùng giải pháp DƯỚI BỐN NĂM.

Vì sao đúng

⚠ Bóc tách chi phí hai phương án: | Phương án | Chi phí ban đầu | Chi phí hàng tháng | |---|---|---| | ⚠ Tự làm (in-house) | ⚠ 568.000 | ⚠ 25.000 | | ⚠ Thuê nhà cung cấp | ⚠ 0 | ⚠ 0,08 × 450.000 giao dịch = 36.000 |

⚠ Tính điểm hoà vốn: | Bước | Phép tính | |---|---| | ⚠ Chênh lệch ban đầu | ⚠ 568.000 − 0 = 568.000 — tự làm đắt hơn lúc đầu | | ⚠ Chênh lệch hàng tháng | ⚠ 36.000 − 25.000 = 11.000 — tự làm rẻ hơn mỗi tháng | | ⚠ Điểm hoà vốn | ⚠ 568.000 / 11.000 = 51,6 tháng | | ⚠ Đổi ra năm | ⚠ ≈ 4,3 năm | | ⚠ Kết luận | ⚠ dùng DƯỚI khoảng 4,3 năm thì THUÊ rẻ hơn; dùng LÂU HƠN thì TỰ LÀM rẻ hơn |

⚠ Kiểm chứng bằng con số cụ thể: | Mốc | Tự làm | Thuê | Rẻ hơn | |---|---|---|---| | ⚠ 12 tháng | ⚠ 568.000 + 300.000 = 868.000 | ⚠ 432.000 | ⚠ THUÊ | | ⚠ 48 tháng (4 năm) | ⚠ 568.000 + 1.200.000 = 1.768.000 | ⚠ 1.728.000 | ⚠ THUÊ | | ⚠ 60 tháng (5 năm) | ⚠ 568.000 + 1.500.000 = 2.068.000 | ⚠ 2.160.000 | ⚠ TỰ LÀM |

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

  • A (tự làm nếu giữ trên MỘT năm) — ⚠ SAI: ⚠ ở mốc 12 tháng thuê rẻ hơn tới 436.000.

  • C (tự làm nếu giữ DƯỚI bốn năm) — ⚠ SAI ngược hoàn toàn: ⚠ dưới bốn năm thì THUÊ mới rẻ.

  • D (thuê nếu giữ TRÊN năm năm) — ⚠ SAI ngược: ⚠ trên năm năm thì TỰ LÀM rẻ hơn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25621 ở lô 177 — ⚠ cùng dạng bài make-or-buy với điểm hoà vốn 129 tháng. ⚠ Cùng công thức, khác con số. Điểm khác: ở câu này chi phí hàng tháng của nhà cung cấp phải TÍNH RA từ đơn giá giao dịch trước.

⚠ Công thức điểm hoà vốn make-or-buy:

⚠ (Chi phí ban đầu A − Chi phí ban đầu B) / (Chi phí định kỳ B − Chi phí định kỳ A)

⚠ Bốn bước làm dạng bài này Bước
⚠ 1. Quy MỌI chi phí định kỳ về CÙNG đơn vị thời gian ⚠ bước hay sai nhất: 0,08 × 450.000 = 36.000/tháng
⚠ 2. Tìm bên nào đắt hơn LÚC ĐẦU ⚠ tự làm, đắt hơn 568.000
⚠ 3. Tìm bên nào rẻ hơn HÀNG THÁNG ⚠ tự làm, rẻ hơn 11.000
⚠ 4. Chia và đối chiếu với các phương án ⚠ 51,6 tháng ≈ 4,3 năm

Từ khoá nhận diện:

"đơn giá mỗi giao dịch" → ⚠ phải NHÂN với số giao dịch để ra chi phí định kỳ "không tốn chi phí ban đầu" → ⚠ chi phí ban đầu = 0 "tự làm hay đi thuê" → ⚠ make-or-buy, tính điểm hoà vốn "chi phí ban đầu cao, phí định kỳ thấp" → ⚠ có lợi khi dùng LÂU DÀI

⚠ Yếu tố phi tài chính cần cân nhắc thêm Yếu tố
⚠ Số giao dịch có ổn định không ⚠ 450.000 là ước tính; tăng gấp đôi thì phương án thuê đắt gấp đôi
⚠ Đây có phải năng lực cốt lõi cần giữ trong nhà không
⚠ Rủi ro phụ thuộc nhà cung cấp
⚠ Chi phí vận hành và bảo trì nội bộ ⚠ 25.000/tháng đã gồm nhân sự chưa?
⚠ Thời gian đưa vào sử dụng ⚠ thuê thường nhanh hơn nhiều
⚠ Rủi ro lớn nhất của phương án thuê ⚠ chi phí tỷ lệ thuận với khối lượng — thành công càng lớn càng tốn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số giao dịch dự báo có đáng tin không | ⚠ đây là biến nhạy cảm nhất của bài toán | | Vòng đời dự kiến của giải pháp là bao lâu | ⚠ so với 51,6 tháng | | Chi phí 25.000/tháng đã tính đủ chưa | ⚠ hạ tầng, nhân sự, cập nhật, bảo mật |

Và bẫy tính toán duy nhất của dạng bài này: đơn giá theo giao dịch phải quy về chi phí theo tháng trước khi so sánh. Bỏ qua bước đó là mọi phép tính sau đều sai.

Câu 176
Benji is the project manager of the BBB Project for his organization. The planned value for the project work at this point is $450,000, but his actual costs for the project is ten percent more than what was planned. The project’s earned value is $417,000. Management is considering canceling this project due to performance. Based on this information, what is the sunk cost of the project?
  1. A $495,000
  2. B $450,000
  3. C $417,000
  4. D Not enough information to know for certain
Xem giải thích

Đáp án

A — 495.000.

Vì sao đúng

⚠ Chi phí chìm = TOÀN BỘ số tiền đã thực chi: | Bước | Phép tính | |---|---| | ⚠ PV — giá trị kế hoạch tại thời điểm này | ⚠ 450.000 | | ⚠ AC — chi phí thực tế, nhiều hơn kế hoạch 10% | ⚠ 450.000 × 1,10 = 495.000 | | ⚠ Chi phí chìm = AC | ⚠ 495.000 — đây là tiền ĐÃ TIÊU, không thu hồi được |

⚠ Vì sao là AC chứ không phải EV hay PV: | Đại lượng | Ý nghĩa | Có phải chi phí chìm không | |---|---|---| | ⚠ PV = 450.000 | ⚠ số tiền ĐÁNG LẼ đã tiêu theo kế hoạch | ⚠ KHÔNG — đó là kế hoạch, không phải tiền thật | | ⚠ EV = 417.000 | ⚠ GIÁ TRỊ công việc đã hoàn thành | ⚠ KHÔNG — đó là giá trị nhận được, không phải tiền chi ra | | ⚠ AC = 495.000 | ⚠ số tiền THỰC SỰ đã chi | ⚠ ĐÚNG — chính là chi phí chìm |

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

  • B (450.000) — ⚠ là PV, giá trị KẾ HOẠCH; ⚠ đề nói rõ đã chi NHIỀU HƠN 10% so với kế hoạch.

  • C (417.000) — ⚠ là EV, giá trị THU ĐƯỢC; ⚠ đây là phương án gây nhiễu mạnh nhất vì người ta hay nghĩ "giá trị đã tạo ra" chính là tiền đã bỏ.

  • D (không đủ thông tin) — ⚠ SAI: ⚠ đề cho đủ dữ liệu để tính AC.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25634 ở lô 178 về chi phí chìm của Nancy. ⚠ Câu kia hỏi TÊN GỌI, câu này hỏi TÍNH RA con số. Cùng một nguyên tắc.

⚠ Nguyên tắc vàng về chi phí chìm:

⚠ "Chi phí chìm KHÔNG BAO GIỜ được đưa vào quyết định tiếp tục hay dừng dự án."

⚠ Ban lãnh đạo nên quyết định thế nào Cách
⚠ BỎ QUA 495.000 đã chi ⚠ tiền đó mất rồi dù dừng hay tiếp
⚠ Hỏi: từ hôm nay chi thêm bao nhiêu? ⚠ ETC — estimate to complete
⚠ Hỏi: thu về được giá trị gì?
⚠ So hai con số đó với nhau
⚠ Sai lầm cần tránh ⚠ "đã bỏ ra 495.000 rồi, dừng thì phí" — đó là sunk cost fallacy

⚠ Các chỉ số khác của bộ số này: | Chỉ số | Phép tính | Kết quả | |---|---|---| | ⚠ CV = EV − AC | ⚠ 417.000 − 495.000 | ⚠ −78.000 — vượt chi | | ⚠ SV = EV − PV | ⚠ 417.000 − 450.000 | ⚠ −33.000 — chậm tiến độ | | ⚠ CPI = EV / AC | ⚠ 417.000 / 495.000 | ⚠ 0,842 — vượt chi nặng | | ⚠ SPI = EV / PV | ⚠ 417.000 / 450.000 | ⚠ 0,927 — chậm nhẹ | | ⚠ Kết luận | ⚠ CPI 0,84 là mức rất xấu — lý do ban lãnh đạo tính chuyện dừng dự án là hợp lý |

Từ khoá nhận diện:

"chi phí chìm" → ⚠ luôn là AC — tiền THỰC CHI "đã chi nhiều hơn kế hoạch X%" → ⚠ AC = PV × (1 + X%) "giá trị thu được" → ⚠ EV, không phải tiền chi "đang cân nhắc huỷ dự án" → ⚠ quyết định phải dựa vào TƯƠNG LAI, không dựa vào chi phí chìm

⚠ Bẫy hay gặp ở dạng câu này Bẫy
⚠ Nhầm chi phí chìm với EV ⚠ EV là giá trị NHẬN, không phải tiền TIÊU
⚠ Nhầm chi phí chìm với PV ⚠ PV là kế hoạch, không phải thực tế
⚠ Quên nhân 10% ⚠ đề nói "nhiều hơn 10% so với kế hoạch"
⚠ Đưa chi phí chìm vào phép tính nên dừng hay tiếp ⚠ lỗi tư duy, không phải lỗi tính toán

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang tính tiền ĐÃ chi hay SẼ chi | ⚠ chỉ vế sau có ý nghĩa cho quyết định | | ETC còn lại là bao nhiêu | | | Giá trị còn lại của dự án có xứng với ETC không | |

Và câu tổng kết: chi phí chìm là dữ kiện để BÁO CÁO, không phải dữ kiện để QUYẾT ĐỊNH. Ban lãnh đạo cần biết 495.000 đã mất, nhưng quyết định dừng hay tiếp chỉ phụ thuộc vào những gì còn ở phía trước.

Câu 177
John is the project manager of the YOM Project for his organization and he’s working with the project team record all of the requirements needed to satisfy the project scope. Management has asked John and the team to create a table that will show each requirement and its status as it moves through the project timeline. What type of chart is management asking John to provide?
  1. A Affinity diagram
  2. B Work breakdown structure
  3. C Requirements traceability matrix
  4. D Project network diagram
Xem giải thích

Đáp án

C — Requirements traceability matrix (ma trận truy vết yêu cầu).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Ghi lại TOÀN BỘ yêu cầu để thoả mãn phạm vi | ⚠ → tài liệu về yêu cầu | | ⚠ Bảng thể hiện TỪNG yêu cầu | | | ⚠ Kèm TRẠNG THÁI của nó qua dòng thời gian dự án | ⚠ → theo dõi từ đầu tới cuối | | ⚠ Kết luận | ⚠ đúng định nghĩa ma trận truy vết yêu cầu |

⚠ Ma trận truy vết yêu cầu: | Đặc điểm | Nội dung | |---|---| | ⚠ Là bảng NỐI yêu cầu với nguồn gốc và với bàn giao | | | ⚠ Theo dõi trạng thái từng yêu cầu suốt vòng đời | | | ⚠ Đảm bảo mọi yêu cầu đều được đáp ứng | ⚠ không sót | | ⚠ Đảm bảo không làm thứ không ai yêu cầu | ⚠ chống gold plating | | ⚠ Là đầu ra của | ⚠ Collect Requirements |

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

  • B (Work breakdown structure) — ⚠ phân rã CÔNG VIỆC, ⚠ không theo dõi trạng thái từng yêu cầu.

  • A (Affinity diagram) — ⚠ phân NHÓM số lượng lớn ý tưởng, ⚠ dùng lúc thu thập, không dùng để theo dõi.

  • D (Project network diagram) — ⚠ thể hiện trình tự và phụ thuộc giữa các HOẠT ĐỘNG, ⚠ không liên quan tới yêu cầu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25657 ở lô 178 về code of accounts — ⚠ ở đó ma trận truy vết là phương án nhiễu. ⚠ Hai câu đảo vai cho nhau; nắm rõ ranh giới là loại được nhiễu ở cả hai.

⚠ Các cột điển hình của ma trận truy vết: | Cột | Nội dung | |---|---| | ⚠ Mã yêu cầu | | | ⚠ Mô tả yêu cầu | | | ⚠ NGUỒN GỐC — ai yêu cầu | ⚠ bên liên quan nào | | ⚠ Mức ưu tiên | | | ⚠ Liên kết tới mục tiêu dự án | | | ⚠ Liên kết tới bàn giao trong WBS | | | ⚠ Liên kết tới thiết kế và phát triển | | | ⚠ Liên kết tới chiến lược kiểm thử | | | ⚠ TRẠNG THÁI hiện tại | ⚠ đúng điều ban lãnh đạo yêu cầu |

Từ khoá nhận diện:

"theo dõi từng yêu cầu và trạng thái của nó" → ⚠ requirements traceability matrix "ai yêu cầu tính năng này" → ⚠ cột nguồn gốc của ma trận truy vết "phân rã công việc phải làm" → ⚠ WBS "định danh duy nhất cho cấu phần WBS" → ⚠ code of accounts "trình tự và phụ thuộc giữa hoạt động" → ⚠ network diagram

⚠ Ma trận truy vết giúp gì cụ thể Lợi ích
⚠ Không SÓT yêu cầu nào khi bàn giao
⚠ Không làm thứ KHÔNG AI yêu cầu ⚠ chống gold plating
⚠ Đánh giá TÁC ĐỘNG khi có yêu cầu thay đổi ⚠ thấy ngay thay đổi này chạm vào những gì
⚠ Chứng minh phạm vi đã hoàn thành lúc nghiệm thu
⚠ Truy ngược khi phát hiện lỗi ⚠ lỗi này thuộc yêu cầu nào, ai đặt ra
⚠ Ba tài liệu về yêu cầu Tài liệu
⚠ Requirements documentation ⚠ mô tả CHI TIẾT từng yêu cầu
⚠ Requirements traceability matrix ⚠ BẢNG nối và theo dõi trạng thái
⚠ Requirements management plan ⚠ cách thu thập, phân tích, theo dõi và kiểm soát yêu cầu
⚠ Cả ba ⚠ đều liên quan tới quy trình Collect Requirements

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi yêu cầu có nối được tới ít nhất một bàn giao không | ⚠ yêu cầu mồ côi là yêu cầu sẽ bị quên | | Mọi bàn giao có nối ngược về ít nhất một yêu cầu không | ⚠ bàn giao mồ côi là gold plating | | Ma trận có được cập nhật khi có thay đổi không | ⚠ ma trận cũ còn tệ hơn không có |

Và giá trị lớn nhất của công cụ này khi có yêu cầu thay đổi: nó trả lời câu hỏi "thay đổi này chạm vào những gì" trong vài phút. Không có nó thì mọi đánh giá tác động đều là phỏng đoán.

Câu 178
Ben is the project manager of BBB Project for his organization and he’s working with the project team to identify the stakeholders’ interests, concerns, threats, and perceptions of threats. Where should Ben document the project team’s findings in this exercise?
  1. A Risk log
  2. B Stakeholder log
  3. C Risk register
  4. D Stakeholder register
Xem giải thích

Đáp án

D — Stakeholder register (sổ đăng ký bên liên quan).

Vì sao đúng

⚠ Sổ đăng ký bên liên quan chứa gì: | Nhóm thông tin | Nội dung | |---|---| | ⚠ Thông tin ĐỊNH DANH | ⚠ tên, chức vụ, vị trí, vai trò trong dự án, thông tin liên lạc | | ⚠ Thông tin ĐÁNH GIÁ | ⚠ yêu cầu chính, KỲ VỌNG, MỐI QUAN TÂM, mức ảnh hưởng, giai đoạn quan tâm nhất | | ⚠ Phân loại bên liên quan | ⚠ nội bộ/bên ngoài, ủng hộ/trung lập/phản đối, hướng ảnh hưởng | | ⚠ Đề nói tới | ⚠ lợi ích, lo ngại, mối đe doạ và CẢM NHẬN về mối đe doạ — đều thuộc nhóm ĐÁNH GIÁ |

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

  • C (Risk register — sổ đăng ký rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì đề có chữ "threats"; ⚠ nhưng ở đây "mối đe doạ" là ⚠ thứ bên liên quan CẢM NHẬN và LO NGẠI, ⚠ chứ chưa được phân tích thành rủi ro dự án chính thức; ⚠ nếu sau đó chúng trở thành rủi ro thật thì mới ghi sang sổ rủi ro.

  • A (Risk log) và B (Stakeholder log) — ⚠ không phải tên tài liệu chuẩn của PMBOK; ⚠ PMBOK dùng chữ "register" chứ không dùng "log" cho hai thứ này.

Ghi nhớ

⚠ Phân biệt "register" và "log" trong PMBOK: | Tài liệu | Loại | |---|---| | ⚠ Stakeholder register | ⚠ register | | ⚠ Risk register | ⚠ register | | ⚠ Requirements documentation | ⚠ documentation | | ⚠ Assumption log | ⚠ log | | ⚠ Issue log | ⚠ log | | ⚠ Change log | ⚠ log | | ⚠ Lessons learned register | ⚠ register | | ⚠ Mẹo | ⚠ đề thi hay bịa tên bằng cách đổi register thành log và ngược lại |

Từ khoá nhận diện:

"lợi ích, kỳ vọng, lo ngại của bên liên quan" → ⚠ stakeholder register "sự kiện không chắc chắn có thể ảnh hưởng mục tiêu" → ⚠ risk register "vấn đề ĐANG xảy ra cần xử lý" → ⚠ issue log "điều ta coi là đúng mà chưa kiểm chứng" → ⚠ assumption log

⚠ Phân biệt rủi ro và vấn đề — hay lẫn: | Khái niệm | Nghĩa | Ghi ở đâu | |---|---|---| | ⚠ Risk — rủi ro | ⚠ sự kiện CHƯA xảy ra, không chắc chắn | ⚠ risk register | | ⚠ Issue — vấn đề | ⚠ việc ĐÃ xảy ra, cần xử lý ngay | ⚠ issue log | | ⚠ Quan hệ | ⚠ rủi ro xảy ra thì trở thành vấn đề |

⚠ Vì sao ghi cả CẢM NHẬN chứ không chỉ sự thật Lý do
⚠ Bên liên quan hành động theo CẢM NHẬN của họ ⚠ dù cảm nhận đó có đúng hay không
⚠ Cảm nhận sai vẫn tạo ra sự phản đối thật
⚠ Biết được cảm nhận thì mới sửa được bằng giao tiếp
⚠ Ví dụ ⚠ một trưởng phòng tưởng dự án sẽ cắt giảm nhân sự của mình — không đúng, nhưng vẫn khiến họ cản trở
⚠ Lưu ý về BẢO MẬT của sổ đăng ký bên liên quan Lưu ý
⚠ Nó chứa đánh giá NHẠY CẢM về con người ⚠ "phản đối dự án", "ảnh hưởng cao nhưng không ủng hộ"
⚠ KHÔNG nên phát tán rộng rãi
⚠ Cân nhắc tách phần đánh giá ra tài liệu riêng, giới hạn quyền xem
⚠ Nếu lộ ra ⚠ có thể làm hỏng quan hệ nghiêm trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ của bạn có ghi kỳ vọng và lo ngại không | ⚠ hay chỉ có tên và email | | Có được cập nhật khi bên liên quan thay đổi thái độ không | | | Ai được quyền đọc phần đánh giá | |

Và điều phân biệt một sổ đăng ký hữu ích với một danh bạ: danh bạ ghi họ là ai, sổ đăng ký ghi họ MUỐN gì và SỢ gì. Chỉ vế sau mới giúp bạn quản lý được sự tham gia của họ.

Câu 179
Nancy is a project manager for her organization and she’s leading a recently launched project. Her project team has 12 people, some of which have worked together before and others have not. The team has created the project scope statement and the WBS and they are now working to develop the project schedule based on the activity list with the project manager. Some of the project team members are in a conflict about the sequencing of the activities, who’ll do what on the project, and how the work should be done. Based on this information, which one of the following terms best describes this scenario?
  1. A Norming
  2. B Performing
  3. C Storming
  4. D Forming
Xem giải thích

Đáp án

C — Storming (giai đoạn sóng gió).

Vì sao đúng

⚠ Dấu hiệu storming trong đề: | Dấu hiệu | Nội dung | |---|---| | ⚠ Đội mới thành lập gần đây | ⚠ "recently launched project" | | ⚠ Một số người CHƯA từng làm việc cùng nhau | | | ⚠ Xung đột về THỨ TỰ công việc | | | ⚠ Xung đột về AI LÀM GÌ | ⚠ tranh giành vai trò — dấu hiệu điển hình | | ⚠ Xung đột về CÁCH LÀM | ⚠ tranh luận phương pháp | | ⚠ Kết luận | ⚠ đúng đặc trưng của giai đoạn Storming trong mô hình Tuckman |

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

  • D (Forming) — ⚠ giai đoạn đầu: ⚠ mọi người còn ⚠ lịch sự, dè dặt, chưa dám tranh luận; ⚠ đội đã qua giai đoạn này vì họ đang cãi nhau công khai.

  • A (Norming) — ⚠ đã THỐNG NHẤT được cách làm việc và tin tưởng nhau; ⚠ trái với tình huống.

  • B (Performing) — ⚠ làm việc hiệu quả, tự tổ chức, ít cần can thiệp; ⚠ còn xa mới tới.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25631 ở lô 177 hỏi thẳng thứ tự năm giai đoạn Tuckman. ⚠ Câu này đặt một giai đoạn vào tình huống cụ thể. Học chung một lượt.

⚠ Năm giai đoạn Tuckman: | Giai đoạn | Đặc điểm | |---|---| | ⚠ Forming | ⚠ gặp nhau, lịch sự, dè dặt, phụ thuộc vào PM | | ⚠ Storming | ⚠ tranh cãi về vai trò, cách làm, quyền lực — GIAI ĐOẠN NÀY | | ⚠ Norming | ⚠ thống nhất chuẩn mực, bắt đầu tin nhau | | ⚠ Performing | ⚠ hiệu quả cao, tự tổ chức | | ⚠ Adjourning | ⚠ hoàn thành và giải tán |

Từ khoá nhận diện:

"cãi nhau về ai làm gì, làm thế nào" → ⚠ Storming "mới gặp nhau, còn dè dặt" → ⚠ Forming "đã có quy tắc chung, hợp tác tốt" → ⚠ Norming "chạy trơn tru, tự giải quyết vấn đề" → ⚠ Performing

⚠ PM nên làm gì trong giai đoạn Storming Cách
⚠ ĐỪNG né tránh xung đột ⚠ né tránh làm đội KẸT lại ở đây
⚠ Dùng phong cách HUẤN LUYỆN — coaching
⚠ Làm rõ VAI TRÒ và trách nhiệm ⚠ dùng RACI — chính là thứ giải quyết tranh cãi "ai làm gì"
⚠ Hướng xung đột về VIỆC, tránh xung đột về NGƯỜI
⚠ Giúp đội xây hiến chương đội ⚠ team charter, quy tắc chung
⚠ Nhớ rằng ⚠ Storming là giai đoạn TỰ NHIÊN và CẦN THIẾT, không phải dấu hiệu đội hỏng
⚠ Vì sao đội này rơi vào Storming là hợp lý Lý do
⚠ Dự án mới khởi động
⚠ 12 người — đủ lớn để có nhiều quan điểm
⚠ Một số người chưa từng làm việc cùng nhau
⚠ Đang bàn tới việc phân công cụ thể ⚠ thời điểm dễ nảy sinh tranh giành vai trò nhất
⚠ Đội đã làm xong scope statement và WBS ⚠ tức là đã qua giai đoạn Forming
⚠ Xung đột lành mạnh và không lành mạnh Phân biệt
⚠ Xung đột về VIỆC ⚠ LÀNH MẠNH — cho ra quyết định tốt hơn
⚠ Xung đột về NGƯỜI ⚠ KHÔNG lành mạnh — phá vỡ đội
⚠ Việc của PM ⚠ giữ tranh luận ở vế đầu, ngăn nó trượt sang vế sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn đang ở giai đoạn nào | | | Vai trò đã được làm rõ bằng RACI chưa | ⚠ giải quyết trực tiếp tranh cãi "ai làm gì" | | Xung đột đang về việc hay về người | |

Và điều PM mới hay hiểu sai nhất: đội cãi nhau không phải là dấu hiệu bạn quản lý kém. Đó là giai đoạn bắt buộc phải đi qua — và nhiệm vụ của bạn là dẫn đội qua nhanh, không phải ngăn nó xảy ra.

Câu 180
You are the project manager of the GHY Project and you are examining a control chart for your project’s production. In the control chart, there are seven consecutive measurements all on the lower side of the mean. Your project sponsor is concerned about these seven measurements. Why?
  1. A These seven measurements show that the mean is too high.
  2. B These seven measurements show failing quality.
  3. C These seven measurements show a trend.
  4. D These seven measurements show the project is failing.
Xem giải thích

Đáp án

C — Bảy phép đo này cho thấy một XU HƯỚNG (trend).

Vì sao đúng

⚠ Rule of seven — quy tắc bảy điểm: | Điều | Nội dung | |---|---| | ⚠ Bảy điểm LIÊN TIẾP cùng một phía đường trung tâm | ⚠ hoặc bảy điểm liên tục tăng, hoặc liên tục giảm | | ⚠ Tất cả vẫn NẰM TRONG giới hạn kiểm soát | ⚠ không có điểm nào vượt ngưỡng | | ⚠ Nhưng xác suất ngẫu nhiên của việc này CỰC THẤP | ⚠ khoảng 1/128 nếu hoàn toàn ngẫu nhiên | | ⚠ Kết luận: quy trình đã LỆCH, có nguyên nhân xác định | ⚠ assignable cause | | ⚠ Phải làm gì | ⚠ ĐIỀU TRA nguyên nhân, dù chưa có điểm nào ra ngoài giới hạn |

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

  • B (cho thấy chất lượng đang HỎNG) — ⚠ kết luận QUÁ SỚM: ⚠ mọi điểm vẫn trong giới hạn kiểm soát, ⚠ nghĩa là sản phẩm vẫn đạt; ⚠ vấn đề là quy trình đã lệch chứ chưa phải chất lượng đã hỏng.

  • A (cho thấy đường trung tâm quá cao) — ⚠ có thể là MỘT giả thuyết, ⚠ nhưng chưa phải kết luận; ⚠ điều biểu đồ nói ra là "có xu hướng", còn nguyên nhân thì phải điều tra.

  • D (cho thấy dự án đang thất bại) — ⚠ kết luận cực đoan và không có cơ sở.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25649 ở lô 178 về design of experiments — ⚠ ở đó "rule of seven" là phương án nhiễu. ⚠ Hai câu đảo vai cho nhau.

⚠ Biểu đồ kiểm soát — các thành phần: | Thành phần | Nội dung | |---|---| | ⚠ Đường trung tâm (mean) | ⚠ giá trị trung bình của quy trình | | ⚠ UCL / LCL — giới hạn kiểm soát trên và dưới | ⚠ thường ±3 độ lệch chuẩn, do QUY TRÌNH quyết định | | ⚠ USL / LSL — giới hạn đặc tả trên và dưới | ⚠ do KHÁCH HÀNG hoặc yêu cầu kỹ thuật quyết định | | ⚠ Các điểm đo theo thời gian | | | ⚠ Phân biệt quan trọng | ⚠ giới hạn KIỂM SOÁT hẹp hơn giới hạn ĐẶC TẢ; vượt giới hạn kiểm soát chưa chắc đã hỏng sản phẩm |

⚠ Ba dấu hiệu quy trình MẤT KIỂM SOÁT: | Dấu hiệu | Nội dung | |---|---| | ⚠ Điểm nằm NGOÀI giới hạn kiểm soát | ⚠ rõ ràng nhất | | ⚠ RULE OF SEVEN | ⚠ bảy điểm liên tiếp cùng phía hoặc cùng chiều — TRƯỜNG HỢP NÀY | | ⚠ Mẫu hình bất thường khác | ⚠ chu kỳ lặp, xu hướng dốc, dao động quá đều | | ⚠ Cả ba | ⚠ đều gọi là out of control và đều cần điều tra |

Từ khoá nhận diện:

"bảy điểm liên tiếp cùng một phía" → ⚠ rule of seven, cho thấy XU HƯỚNG "nằm ngoài giới hạn kiểm soát" → ⚠ out of control, cần hành động ngay "giới hạn do khách hàng đặt" → ⚠ specification limit "giới hạn do quy trình tự nhiên" → ⚠ control limit

⚠ Bạn nên làm gì tiếp theo Bước
⚠ 1. ĐIỀU TRA nguyên nhân của xu hướng ⚠ dùng Ishikawa và 5 Whys
⚠ 2. Kiểm tra xem có thay đổi gì gần đây không ⚠ đổi nguyên liệu, đổi ca, đổi thiết bị, bảo trì
⚠ 3. Xác nhận hệ thống ĐO có chính xác không ⚠ có khi chỉ là thiết bị đo bị lệch
⚠ 4. Hành động khắc phục nếu tìm ra nguyên nhân
⚠ 5. Tiếp tục theo dõi
⚠ Đừng ⚠ kết luận vội là chất lượng hỏng hay dự án thất bại
⚠ Vì sao phải để ý xu hướng dù chưa vượt ngưỡng Lý do
⚠ Xu hướng thường DẪN TỚI việc vượt ngưỡng ⚠ phát hiện sớm là cơ hội sửa rẻ
⚠ Quy trình lệch có nghĩa là có gì đó ĐÃ thay đổi
⚠ Chờ tới khi có điểm ra ngoài là đã muộn
⚠ Đây chính là ⚠ tinh thần phòng ngừa thay vì kiểm tra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thay đổi nào trùng thời điểm xu hướng bắt đầu không | | | Thiết bị đo đã hiệu chuẩn chưa | | | Giới hạn kiểm soát có được tính lại gần đây không | |

Và cách trả lời nhà tài trợ đúng nhất: "số liệu vẫn đạt yêu cầu, nhưng quy trình đã lệch — chúng tôi đang tìm nguyên nhân trước khi nó vượt ngưỡng." Đó là câu trả lời của người hiểu biểu đồ kiểm soát.