Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Giao tiếp
  3. /Challenger 1986: Khi cảnh báo của kỹ sư không đế…
Quản lý Giao tiếp

Challenger 1986: Khi cảnh báo của kỹ sư không đến được người ra quyết định cao nhất

Đêm trước vụ phóng, kỹ sư Morton Thiokol khuyến nghị không phóng dưới 53°F vì vòng đệm O-ring. Khuyến nghị bị đảo ngược trong một cuộc họp kín và các lãnh đạo cấp cao của NASA không hề biết có phản đối. Phân tích đường leo thang bị "lọc" thông tin theo chuẩn PMP.

HP
Nguyễn Thu Hà, PMP
19/09/2026
4 phút đọc 0 lượt xem
Challenger 1986: Khi cảnh báo của kỹ sư không đến được người ra quyết định cao nhất
Bình luận0

Bối cảnh thực tế

Ngày 28/01/1986, tàu con thoi Challenger vỡ tung sau khi cất cánh, bảy phi hành gia thiệt mạng. Ủy ban Rogers kết luận nguyên nhân kỹ thuật là vòng đệm O-ring ở mối nối tên lửa đẩy nhiên liệu rắn bên phải không làm kín được trong thời tiết lạnh bất thường.

Tối 27/01, trong cuộc họp trực tuyến (teleconference) giữa NASA và nhà thầu Morton Thiokol, các kỹ sư như Roger Boisjoly trình bày dữ liệu về hiện tượng xói mòn O-ring và khuyến nghị không phóng khi nhiệt độ dưới 53°F (khoảng 12°C) — mức thấp nhất mà họ có dữ liệu bay.

Những dấu hiệu bất thường:

  • Phía NASA chất vấn gay gắt khuyến nghị "không phóng" của chính nhà thầu.
  • Ban lãnh đạo Thiokol xin nghỉ khoảng 30 phút để họp riêng; một lãnh đạo đề nghị đồng nghiệp "bỏ mũ kỹ sư, đội mũ quản lý".
  • Sau cuộc họp riêng, Thiokol đổi sang khuyến nghị phóng, dù các kỹ sư vẫn phản đối.
  • Các nhà quản lý cấp cao nhất phụ trách quyết định phóng không hề được báo rằng kỹ sư nhà thầu đã phản đối.

Ủy ban Rogers ghi nhận quy trình ra quyết định có sai sót, thông tin an toàn quan trọng đã "đi vòng" qua các nhà quản lý then chốt.

Phân tích nguyên nhân theo chuẩn PMP

  • Kênh leo thang (escalation path) bị lọc thông tin

    Thông tin rủi ro đi qua nhiều tầng quản lý và mỗi tầng "tóm tắt" lại theo cách có lợi cho tiến độ. Kết quả là người ra quyết định cuối cùng chỉ nghe "các lo ngại đã được giải quyết". Theo PMBOK, kế hoạch quản lý giao tiếp (communications management plan) phải quy định rõ thông tin nào, gửi cho ai, khi nào, qua kênh nào và quy trình leo thang cho các vấn đề chưa thống nhất — đặc biệt với rủi ro an toàn.

  • Đảo ngược nghĩa vụ chứng minh

    Ủy ban Rogers nhận xét NASA đã buộc nhà thầu phải chứng minh rằng phóng là không an toàn, thay vì chứng minh là an toàn. Trong giao tiếp rủi ro, đây là "nhiễu" (noise) nghiêm trọng: người gửi thông điệp (kỹ sư) không có đủ dữ liệu định lượng, người nhận (quản lý) mặc định coi mọi thứ ổn khi chưa có bằng chứng ngược lại.

  • Áp lực tiến độ và thiếu an toàn tâm lý

    Câu nói "bỏ mũ kỹ sư, đội mũ quản lý" cho thấy ý kiến chuyên môn bị gạt sang bên vì mục tiêu lịch trình. Khi chuyên gia cảm thấy ý kiến phản biện không được chào đón, họ im lặng hoặc nói nhỏ đi. An toàn tâm lý (psychological safety) là điều kiện tiên quyết để rủi ro được nêu ra kịp thời.

  • Mô hình giao tiếp: phản hồi không khép vòng

    Trong mô hình người gửi – người nhận (sender–receiver), giao tiếp chỉ hoàn tất khi người nhận xác nhận đã hiểu và phản hồi. Ở đây, phản đối của kỹ sư không được ghi nhận chính thức như một ý kiến bất đồng (dissent) và không được chuyển lên tầng trên, nên vòng phản hồi bị đứt.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Thiết lập quy trình leo thang bắt buộc cho rủi ro an toàn

      Trong kế hoạch quản lý giao tiếp, quy định mọi khuyến nghị "không tiến hành" của chuyên gia kỹ thuật phải được chuyển nguyên văn tới cấp ra quyết định cuối cùng, kèm tên người nêu và dữ liệu đi kèm.

      • Ngưỡng bắt buộc leo thang

        Bất kỳ ý kiến phản đối nào liên quan đến an toàn hoặc ngoài phạm vi dữ liệu đã kiểm chứng.

      • Hình thức

        Văn bản chính thức, ghi rõ người phản đối, lý do và dữ liệu — không chỉ tóm tắt miệng.

      • Thời hạn

        Trước khi ra quyết định "đi/không đi" (go/no-go), không có ngoại lệ vì tiến độ.

    2. 2

      Bước 2: Đặt nghĩa vụ chứng minh đúng chỗ

      Quy tắc ra quyết định: khi điều kiện vận hành nằm ngoài vùng dữ liệu đã thử nghiệm, mặc định là dừng cho đến khi chứng minh được an toàn. Ghi quy tắc này vào tiêu chí go/no-go từ trước, không thương lượng tại chỗ.

    3. 3

      Bước 3: Ghi nhận ý kiến bất đồng (dissenting opinion) vào biên bản

      Mọi cuộc họp ra quyết định quan trọng cần biên bản ghi rõ ai đồng ý, ai phản đối và lý do. Nhật ký quyết định (decision log) giúp người cấp trên thấy đầy đủ bức tranh thay vì chỉ thấy kết luận.

    4. 4

      Bước 4: Tách vai trò người đánh giá kỹ thuật khỏi áp lực tiến độ

      Cho bộ phận đảm bảo an toàn/chất lượng một kênh báo cáo độc lập lên lãnh đạo cao nhất, không phụ thuộc vào người chịu trách nhiệm lịch trình.

    5. 5

      Bước 5: Nuôi dưỡng văn hoá "lên tiếng không bị trừng phạt"

      PM chủ động mời ý kiến phản biện ("Có điều gì khiến anh chị chưa yên tâm không?") và cảm ơn người mang tin xấu. Đây là hành vi của lãnh đạo phục vụ (servant leadership) mà đề PMP đề cao.

    PM Takeaway (Bài học rút ra)

    Thông tin rủi ro chỉ có giá trị khi nó đến được đúng người ra quyết định, nguyên vẹn và kịp thời. Một quy trình leo thang rõ ràng và văn hoá tôn trọng ý kiến phản biện quan trọng không kém dữ liệu kỹ thuật.

    Nguồn tham khảo

    • Rogers Commission Report — Chapter V: The Contributing Cause of the Accident (NASA)
    • Space Shuttle Challenger disaster (Wikipedia)
    #Quản lý giao tiếp#leo-thang#An toàn tâm lý#ra-quyet-dinh

    Nguồn: Report of the Presidential Commission on the Space Shuttle Challenger Accident — Chapter V (NASA) ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Trong một dự án có rủi ro an toàn cao, kỹ sư trưởng của nhà thầu khuyến nghị hoãn một hạng mục thử nghiệm vì điều kiện vận hành nằm ngoài vùng dữ liệu đã kiểm chứng. Quản lý phía nhà thầu sau đó thống nhất "vẫn tiến hành" và chỉ báo lên nhà tài trợ rằng "các lo ngại đã được xử lý". Là PM, bạn biết chuyện này trước giờ ra quyết định. Bạn nên làm gì trước tiên?

    Bạn chọn phương án nào?

    Nếu là PM, 2 giờ trước thời điểm "đi/không đi", một kỹ sư nói với bạn riêng rằng anh ấy "không yên tâm" nhưng không có dữ liệu định lượng, và ban lãnh đạo đang rất muốn giữ lịch. Bạn chọn…?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Giao tiếp

    Khách hàng đòi thay thế Tech Lead & Nghệ thuật Bảo vệ Đội ngũ

    Mảng kiến thức trọng tâm: Quản lý Nguồn lực, Quản lý Các bên liên quan & Lãnh đạo Phục vụ (Resource Management, Stakeholder Engagement & Servant Leadership - PMBOK 6/7)

    1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Quản lý Giao tiếp

    "Hố sâu chuyển giao" (Operational Transition Gap) – Khi Đội Vận hành từ chối tiếp nhận hệ thống

    Mảng kiến thức trọng tâm: Chuyển giao từ Dự án sang Vận hành & Quản lý Các bên liên quan nội bộ (Project-to-Operations Transition, Operational Readiness & Internal Stakeholder Engagement - PMBOK 6/7)

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận13/10/2026
    Quản lý Giao tiếp

    Slack 22/02/2022: nâng cấp Consul làm bộ nhớ đệm rơi, cơ sở dữ liệu quá tải và cách vừa giảm tải vừa thông tin cho người dùng

    Sáng 22/02/2022, đúng giờ cao điểm, nhiều người dùng Slack không kết nối được. Nguyên nhân là một chuỗi yếu tố: nâng cấp Consul theo từng bước 25%, bộ nhớ đệm mất hiệu quả, truy vấn quét mọi shard làm Vitess quá tải và máy khách thử lại dồn dập. Slack giảm tải có kiểm soát, thông báo trên mạng xã hội rồi công bố bản post-mortem kỹ thuật vào cuối tháng 4. Phân tích dưới góc nhìn quản lý truyền thông sự cố.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận09/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)