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ý Tiến độ
  3. /Tàu Psyche của NASA lỡ cửa sổ phóng 2022: phần m…
Số 121Quản lý Tiến độ

Tàu Psyche của NASA lỡ cửa sổ phóng 2022: phần mềm giao muộn và tiếng nói cảnh báo không được lắng nghe

Psyche — sứ mệnh khoảng 1 tỷ USD bay tới tiểu hành tinh kim loại — phải bỏ cửa sổ phóng 08/2022 vì phần mềm dẫn đường, điều hướng và điều khiển (GNC) giao muộn và hệ thống thử nghiệm chưa hoàn thiện. Hội đồng đánh giá độc lập chỉ ra gốc rễ nằm ở giao tiếp, nhân lực và văn hoá quản lý. Phân tích từ góc nhìn quản lý tiến độ và hoạt động trên đường găng.

HP
Nguyễn Thu Hà, PMP
11/08/2026
4 phút đọc 0 lượt xem
Tàu Psyche của NASA lỡ cửa sổ phóng 2022: phần mềm giao muộn và tiếng nói cảnh báo không được lắng nghe
Bình luận0

Bối cảnh thực tế

Psyche là sứ mệnh thuộc chương trình Discovery của NASA, chi phí giới hạn khoảng 1 tỷ USD, do Phòng thí nghiệm Phản lực (JPL) quản lý dự án, nhằm nghiên cứu tiểu hành tinh giàu kim loại 16 Psyche. Lịch phóng ban đầu là tháng 08/2022. Với sứ mệnh liên hành tinh, cửa sổ phóng bị ràng buộc bởi quỹ đạo — lỡ cửa sổ nghĩa là trượt cả năm.

Tháng 06/2022, NASA thông báo không kịp phóng vì phần mềm bay và thiết bị thử nghiệm chưa sẵn sàng. Hội đồng đánh giá độc lập (Independent Review Board — IRB) được lập và báo cáo trước Ủy ban Tư vấn Khoa học Hành tinh ngày 05/12/2022:

  • Nguyên nhân trực tiếp: phần mềm GNC giao muộn và môi trường thử nghiệm (testbed) chưa đủ chín.
  • Ngay cả khi không có hai vấn đề trên, các lỗi phần mềm còn mở, việc kiểm định và xác nhận (V&V) chưa xong và mức sẵn sàng vận hành cũng có thể tự gây trượt lịch.
  • Thành viên đội đã lên tiếng cảnh báo nhưng cảm thấy không được lắng nghe ở nhiều cấp; văn hoá "hãy chứng minh là có vấn đề" khiến cảnh báo bị gạt đi.
  • Lãnh đạo cấp trên không đi đủ sâu vào thực thi dự án nên không nhận ra mức nghiêm trọng kịp thời; khối khoa học hành tinh của JPL trải qua ba lần đổi lãnh đạo và một lần tái tổ chức trong hai năm.

Sau khi JPL tổ chức lại nhân sự, bổ sung người có kinh nghiệm và điều chỉnh chính sách làm việc, IRB đánh giá lại vào giữa 2023 rằng ngày phóng mới 10/2023 là đáng tin cậy. Psyche phóng thành công tháng 10/2023.

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

  • Hoạt động phần mềm và testbed nằm trên đường găng nhưng thiếu dự phòng

    Phần mềm GNC phải xong trước khi chạy V&V trên testbed, và V&V phải xong trước khi phóng — một chuỗi phụ thuộc kết thúc–bắt đầu (finish-to-start) dẫn thẳng tới mốc cố định là cửa sổ phóng. Khi mốc cuối không thể dịch chuyển, mọi hoạt động trên chuỗi này cần dự phòng tiến độ (schedule reserve) đủ lớn và được theo dõi riêng.

  • Thiếu khả năng nhìn thấy tiến độ thật (visibility)

    IRB được giao nhiệm vụ tìm hiểu vì sao không ai thấy trước nguy cơ trượt. Báo cáo tiến độ dựa trên "phần trăm hoàn thành" cho phần mềm thường lạc quan; nếu không có tiêu chí hoàn thành khách quan (ví dụ số yêu cầu đã kiểm thử đạt), đường cong tiến độ trông ổn cho tới tận cuối.

  • Giao tiếp đứt gãy làm vô hiệu hoá trigger rủi ro

    Người trực tiếp làm việc đã phát hiện dấu hiệu, nhưng thông tin không đi lên được. Đây là lỗi của Quản lý truyền thông (Manage Communications) và của môi trường an toàn tâm lý — PMBOK 7 nhấn mạnh việc tạo môi trường để đội dám nêu vấn đề.

  • Nguồn lực bị kéo căng giữa nhiều dự án

    IRB ghi nhận áp lực cân đối nhân sự liên tục chiếm thời gian của quản lý. Khi tài nguyên dùng chung bị phân bổ quá mức, lịch lập trên giả định nguồn lực sẵn có sẽ không còn khả thi — cần cân bằng nguồn lực (resource leveling) và phân tích lại đường găng theo nguồn lực.

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

    1. 1

      Bước 1: Đo tiến độ phần mềm bằng tiêu chí khách quan

      Thay "phần trăm hoàn thành" bằng các thước đo có thể kiểm chứng:

      • Yêu cầu đã kiểm chứng

        Tỷ lệ yêu cầu GNC đã chạy đạt trên testbed so với kế hoạch theo tuần; lệch quá 10% là tín hiệu đỏ.

      • Độ chín của testbed

        Testbed phải đạt mức sẵn sàng đã định trước khi tính phần mềm vào giai đoạn V&V.

      • Lỗi còn mở theo mức độ

        Xu hướng số lỗi nghiêm trọng còn mở phải giảm dần; tăng hai tuần liên tiếp thì leo thang.

    2. 2

      Bước 2: Bảo vệ dự phòng tiến độ trước mốc cố định

      Đặt bộ đệm dự án (project buffer) trước cửa sổ phóng và theo dõi tốc độ tiêu hao buffer so với tiến độ công việc — tư duy của phương pháp chuỗi găng (critical chain).

    3. 3

      Bước 3: Tạo kênh nêu vấn đề không bị chặn

      Thiết lập kênh bất đồng kỹ thuật độc lập, buổi rà soát rủi ro định kỳ có tiếng nói của kỹ sư trực tiếp, và nguyên tắc "người báo vấn đề không phải chứng minh trước" — chuyển gánh nặng chứng minh sang phía khẳng định là ổn.

    4. 4

      Bước 4: Quyết định sớm khi dữ liệu cho thấy không kịp

      Mốc cửa sổ phóng là cố định; quyết định lùi càng sớm thì chi phí giữ đội và kế hoạch lại càng thấp. Cần đặt trước "điểm quyết định đi/không đi" (go/no-go) theo dữ liệu, không chờ đến sát ngày.

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

    Với mốc thời gian không thể dịch chuyển, rủi ro tiến độ lớn nhất không phải là việc chậm, mà là việc phát hiện chậm. Thước đo khách quan cộng với văn hoá cho phép nói "có vấn đề" là hai lớp bảo vệ đường găng hiệu quả nhất.

    Nguồn tham khảo

    • NASA — Psyche Independent Review Board Briefing for PAC (12/2022)
    • Universe Today — Psyche Mission Passes Independent Review Board with Flying Colors
    #Quản lý tiến độ#duong-gang#Phần mềm#giao-tiep#Đánh giá độc lập#NASA

    Nguồn: NASA — Psyche Independent Review Board Briefing (12/2022) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Dự án của bạn có mốc bàn giao cố định không thể dời. Báo cáo tuần cho thấy phần mềm điều khiển "đã hoàn thành 85%" suốt ba tuần liền, trong khi một kỹ sư kiểm thử nói riêng rằng môi trường thử nghiệm vẫn chưa chạy được kịch bản tích hợp. Bạn nên làm gì trước tiên?

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

    Nếu là PM của một sứ mệnh có cửa sổ phóng cố định, 2 tháng trước ngày phóng bạn thấy phần mềm còn nhiều lỗi mở và V&V mới đi được nửa chặng. Bạn chọn hướng nào?

    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ý Tiến độ

    Windows Longhorn thành Vista: "tái lập" năm 2004, khi phụ thuộc chéo giữa các đội làm mọi mốc trượt dần

    Longhorn ban đầu được hình dung là bản phát hành nhỏ vào cuối 2003, rồi dần gánh thêm cả những tính năng vốn dành cho thế hệ sau. Tháng 8/2004 Microsoft quyết định làm lại từ nền Windows Server 2003 SP1, cắt hoặc hoãn WinFS và phần lớn Palladium; Vista chỉ đến tay người dùng tháng 1/2007. Phân tích dưới góc nhìn quản lý tiến độ: phụ thuộc giữa các đội, nợ kỹ thuật và quyết định "đặt lại đường cơ sở".

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Quản lý Tiến độ

    Final Fantasy XIV: làm lại cả trò chơi trong khi bản cũ vẫn vận hành — lộ trình 3 năm từ thất bại 2010 đến A Realm Reborn

    Bản gốc ra mắt tháng 9/2010 với đánh giá rất tệ. Square Enix thay đội lãnh đạo, tạm ngừng thu phí và quyết định xây lại trò chơi trên động cơ, máy chủ mới trong khi vẫn cập nhật bản cũ. Phiên bản A Realm Reborn phát hành 27/8/2013. Phân tích ở góc nhìn tái lập kế hoạch tiến độ, lộ trình công khai và chuyển đổi không gián đoạn.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận04/10/2026
    Số 120Quản lý Tiến độ

    Tên lửa SLS và chuyến bay Artemis I: khi lần tái lập kế hoạch che mất 19 tháng trượt tiến độ

    Báo cáo IG-20-012 (03/2020) của Văn phòng Tổng Thanh tra NASA cho thấy chương trình Space Launch System vượt đường cơ sở cam kết với Quốc hội ít nhất 33%, trong khi một lần tái lập kế hoạch năm 2017 đã rút gần 1 tỷ USD chi phí ra khỏi đường cơ sở mà không hạ mức cam kết — làm mờ tác động của 19 tháng trượt tiến độ. Phân tích theo góc nhìn quản lý tiến độ và đường cơ sở.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận01/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)