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ý Phạm vi
  3. /Trực thăng tổng thống VH-71: yêu cầu không được …
Quản lý Phạm vi

Trực thăng tổng thống VH-71: yêu cầu không được đánh đổi, phát triển song song sản xuất và chi phí tăng gấp đôi lên 13 tỷ USD

Để đưa trực thăng mới vào phục vụ sớm 3 năm, Hải quân Mỹ cho VH-71 vừa phát triển vừa sản xuất, với các yêu cầu hiệu năng gần như không có độ linh hoạt. Ước tính chi phí tăng từ khoảng 6,5 lên 13 tỷ USD và chương trình bị huỷ năm 2009 sau gần 3 tỷ USD đã chi. Bài học về quản lý phạm vi, đánh đổi yêu cầu và cách chương trình kế nhiệm làm khác.

HP
Nguyễn Thu Hà, PMP
13/01/2026
4 phút đọc 0 lượt xem
Trực thăng tổng thống VH-71: yêu cầu không được đánh đổi, phát triển song song sản xuất và chi phí tăng gấp đôi lên 13 tỷ USD
Bình luận0

Bối cảnh thực tế

Sau sự kiện 11/9/2001, nhu cầu nâng cấp trực thăng chở Tổng thống Mỹ về vận chuyển, liên lạc và an ninh trở nên cấp bách. Chương trình thay thế khởi động năm 2002 với mục tiêu đưa vào phục vụ khoảng năm 2011; sau đó Nhà Trắng muốn sớm hơn, và Hải quân lập kế hoạch tăng tốc để có trực thăng mới vào cuối năm 2008. Chương trình được đổi tên là VH-71.

Theo GAO-11-380R (2011):

  • Để tăng tốc, Hải quân chia hai giai đoạn (Increment 1 và 2) và cho Increment 1 vừa phát triển vừa sản xuất từ tháng 1/2005. Một đánh giá năm 2004 đã cảnh báo tiến độ rủi ro cao vì thiết kế và sản xuất đồng thời, nhưng rủi ro được chấp nhận.
  • Rà soát yêu cầu hệ thống (tháng 5/2005, sau 4 tháng phát triển) phát hiện thiết kế của nhà thầu không tuân thủ đáng kể yêu cầu hợp đồng; mất khoảng 14 tháng để xử lý.
  • Rà soát thiết kế sơ bộ của Increment 1 hoàn tất sau 13 tháng phát triển; của Increment 2 vẫn chưa có sau 35 tháng, khi phải dừng việc vì lo vượt ngân sách.
  • Các yêu cầu hiệu năng nghiêm ngặt (một số không có độ linh hoạt) được ấn định trước khi phát triển mà gần như không có đánh đổi chi phí – hiệu năng – tiến độ giữa khách hàng và nhà phát triển.
  • Ước tính chi phí tăng gấp đôi, từ khoảng 6,5 tỷ USD (2005) lên khoảng 13 tỷ USD; chương trình vượt ngưỡng Nunn-McCurdy và bị huỷ năm 2009 sau khi đã chi gần 3 tỷ USD.

Chương trình kế nhiệm (VXX, sau là VH-92A) rút bài học: mô tả thuộc tính hiệu năng dưới dạng "giá trị ưu tiên" thay vì yêu cầu cứng, dùng công nghệ đã chín và chọn một mẫu trực thăng có sẵn. Năm 2015, GAO nhận định chương trình mới đã có tình huống kinh doanh dựa trên tri thức.

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

  • Yêu cầu không có không gian đánh đổi

    Quy trình Thu thập yêu cầu (Collect Requirements) không chỉ ghi lại mong muốn mà còn phải ưu tiên hoá và cân đối với nguồn lực. Khi mọi yêu cầu đều là "bắt buộc", PM mất công cụ quan trọng nhất để giữ dự án trong giới hạn: đánh đổi giữa phạm vi, chi phí và tiến độ.

  • Phạm vi chưa được xác nhận chung trước khi cam kết

Việc rà soát yêu cầu sau khi đã bắt đầu phát triển phát hiện thiết kế lệch xa hợp đồng cho thấy hai bên chưa có cùng hiểu biết về phạm vi. Bản mô tả phạm vi (scope statement) và WBS phải được thống nhất trước khi cam kết đường cơ sở.

  • Tiến độ áp đặt làm hỏng tình huống kinh doanh

    Rút ngắn 3 năm bằng cách chồng phát triển lên sản xuất là quyết định chấp nhận rủi ro rất lớn. Khi kỹ thuật hệ thống chưa làm xong, mọi ước tính chi phí đều thiếu cơ sở — và việc tăng gấp đôi là hệ quả có thể dự đoán.

  • Không có cơ chế dừng sớm

    Các mốc rà soát bị trễ liên tục nhưng chương trình vẫn tiếp tục cho tới khi vượt ngưỡng luật định. Cổng giai đoạn cần tiêu chí dừng hoặc tái cấu trúc rõ ràng.

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

    1. 1

      Bước 1: Phân loại yêu cầu theo mức bắt buộc

      Chỉ một số ít yêu cầu là ngưỡng bắt buộc; phần còn lại là giá trị mục tiêu có thể đánh đổi — đúng cách VXX đã làm với "giá trị ưu tiên".

    2. 2

      Bước 2: Xác nhận phạm vi chung trước khi bắt đầu phát triển

      Hoàn tất rà soát yêu cầu hệ thống và thiết kế sơ bộ trước khi ký cam kết phát triển và sản xuất, theo các tiêu chí:

      • Hiểu biết chung

        Bên mua và nhà thầu cùng ký xác nhận yêu cầu hệ thống và cách kiểm chứng từng yêu cầu.

      • Thiết kế sơ bộ

        Thiết kế sơ bộ khả thi đã được rà soát; công nghệ then chốt đã chứng minh trong môi trường đại diện.

      • Cổng dừng

        Rà soát kỹ thuật trễ quá ngưỡng hoặc ước tính tăng quá mức thoả thuận thì trình nhà tài trợ quyết định tái cấu trúc hoặc dừng.

    3. 3

      Bước 3: Trình bày rõ cái giá của việc rút ngắn tiến độ

      Khi khách hàng muốn sớm hơn, PM trình các phương án kèm rủi ro và chi phí — ví dụ giao năng lực cơ bản trước bằng nền tảng có sẵn — để khách hàng chọn có thông tin.

    4. 4

      Bước 4: Dùng sản phẩm có sẵn khi có thể

      Chọn nền tảng đã chín và chỉ phát triển phần thật sự khác biệt giúp giảm mạnh rủi ro phạm vi, như cách VH-92A làm.

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

    Một dự án mà mọi yêu cầu đều không được đánh đổi và tiến độ bị áp đặt sẽ không còn biến số nào để điều chỉnh — ngoài chi phí. Hãy phân loại yêu cầu, xác nhận phạm vi chung trước khi cam kết và cho khách hàng thấy cái giá thật của "sớm hơn".

    Nguồn tham khảo

    • GAO-11-380R — Defense Acquisitions: Application of Lessons Learned and Best Practices in the Presidential Helicopter Program
    • GAO-15-392R — Presidential Helicopter Acquisition: Program Established Knowledge-Based Business Case and Entered System Development with Plans for Managing Challenges
    #Quản lý phạm vi#gao#Quốc phòng Mỹ#Thu thập yêu cầu#Tình huống kinh doanh#Hàng không

    Nguồn: GAO-11-380R — Application of Lessons Learned and Best Practices in the Presidential Helicopter Program ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Khách hàng yêu cầu bàn giao sớm hơn 3 năm và khẳng định mọi yêu cầu hiệu năng đều "không thể thương lượng". Nhóm kỹ thuật chưa hoàn tất thiết kế sơ bộ. Là PM, bạn nên làm gì?

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

    Nếu là PM khi khách hàng cấp cao muốn có sản phẩm sớm hơn 3 năm, bạn đề xuất 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ý Phạm vi

    Duke Nukem Forever: 14 năm phát triển khi phạm vi là một mục tiêu di động và không ai định nghĩa "xong"

    Công bố năm 1997 với kỳ vọng ra mắt cuối 1998, tựa game Duke Nukem Forever chuyển động cơ đồ hoạ nhiều lần, khởi động lại và chỉ phát hành tháng 6/2011 sau khi Gearbox tiếp quản. Phân tích dưới góc nhìn quản lý phạm vi: khi chủ dự án tự quyết mọi thay đổi, không có đường cơ sở và không có tiêu chí hoàn thành.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Quản lý Phạm vi

    FBI Sentinel (2006–2012): yêu cầu sáu năm tuổi, tạm dừng nhà thầu và cuộc đặt lại phạm vi theo hướng agile

    Sau thất bại của Virtual Case File, FBI giao Lockheed Martin xây hệ thống hồ sơ điện tử Sentinel theo bốn giai đoạn. Đến 2010, mới xong hai giai đoạn, thanh tra Bộ Tư pháp cảnh báo yêu cầu đã cũ và kế hoạch mới chưa được văn bản hoá. FBI dừng nhà thầu, tự phát triển theo agile với phạm vi thu hẹp và hệ thống được dùng toàn cơ quan từ 7/2012. Bài học về xếp hạng lại yêu cầu khi đã tiêu hao phần lớn ngân sách.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận12/10/2026
    Quản lý Phạm vi

    Phoenix/Firefox (2002–2004): cắt gọt phạm vi của một bộ ứng dụng cồng kềnh để làm ra trình duyệt gọn nhẹ

    Một nhóm nhỏ trong cộng đồng Mozilla cho rằng áp lực thương mại và việc tính năng chồng chất đã làm Mozilla Suite phình to. Họ làm một trình duyệt độc lập, tối giản (Phoenix, sau đổi tên Firefox), ra bản 1.0 ngày 9/11/2004 và đạt 60 triệu lượt tải trong chín tháng. Ví dụ thành công của việc dám loại bỏ.

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