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
  2. /Tình huống
  3. /Quản lý Mua sắm
  4. /Kessel Run của Không quân Mỹ: mua sắm phần mềm k…
Quản lý Mua sắm

Kessel Run của Không quân Mỹ: mua sắm phần mềm kiểu agile thay cho hợp đồng yêu cầu cứng, từ lập kế hoạch tiếp dầu đến tranh chấp quyền truy cập mã

Sau khi dự án phần mềm lập kế hoạch tiếp dầu theo cách truyền thống bị huỷ năm 2017 với chi phí phát triển 745 triệu USD, Không quân Mỹ lập nhóm Kessel Run, phát triển công cụ Jigsaw và dùng được sau khoảng bốn tháng. Mô hình agile mang lại kết quả cụ thể nhưng cũng nêu thách thức: khó báo cáo Quốc hội và tranh chấp quyền truy cập hệ thống độc quyền của nhà thầu. GAO năm 2023 nêu khoảng trống áp dụng agile ở các lộ trình khác.

HP
Nguyễn Thu Hà, PMP
28/08/2026
4 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Tháng 10/2016, tại Trung tâm Điều hành Không chiến Al Udeid (Qatar), các nhà tư vấn quốc phòng phát hiện việc lập kế hoạch tiếp dầu trên không được làm bằng tay trên bảng trắng, mất 8 đến 12 giờ mỗi ngày. Nỗ lực hiện đại hoá trước đó (một dự án của Northrop Grumman bắt đầu năm 2013) bị huỷ tháng 07/2017 sau khi chi phí phát triển lên 745 triệu USD, theo Wikipedia.

Theo bài viết, nhóm Kessel Run được thành lập chính thức vào tháng 04/2017:

  • Hợp tác với Pivotal Software, các lập trình viên xây ứng dụng Jigsaw lập kế hoạch tiếp dầu và trung tâm điều hành dùng được sau khoảng bốn tháng; chi phí Jigsaw được nêu từ 1,5 đến 2,2 triệu USD tuỳ nguồn.
  • Jigsaw rút quy trình nhiều người xuống 2–3 giờ cho một người, giảm 2–3 lần tàu bay phải gấp rút mỗi ngày và tiết kiệm khoảng 350.000 pound nhiên liệu mỗi tuần; chi phí phát triển được cho là hoàn vốn trong tuần đầu.
  • Ngân sách của Kessel Run lên khoảng 140 triệu USD đầu năm 2019 (gồm cả không gian và nhân sự). Mô hình này gợi hứng cho nhiều "nhà máy phần mềm" khác; đến 09/2021 có 17 nhà máy phần mềm của Không quân.

Thách thức cũng được ghi nhận: khảo sát năm 2019 cho thấy một số ứng dụng chưa đáp ứng nhu cầu người dùng; cấu trúc agile khó cho việc báo cáo Quốc hội về sản phẩm sẽ làm trong một đến hai năm; và việc sửa hệ thống bảo trì ALIS của F-35 mất đến tháng 01/2019 mới viết được mã vì phải thương lượng quyền truy cập các hệ thống độc quyền của Lockheed Martin.

Theo GAO-23-105867, chỉ lộ trình mua sắm phần mềm (software pathway) của Bộ Quốc phòng yêu cầu quy trình xác định yêu cầu được điều chỉnh cho agile; các chương trình ở lộ trình khác nhìn chung chưa áp dụng nguyên tắc agile. GAO cũng cho rằng cách làm tuần tự có thể mất trên 10 năm.

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

  • Yêu cầu cứng lập sớm không hợp với sản phẩm phần mềm (Collect Requirements, Plan Scope)

    Dự án trước đó dùng cách tiếp cận tuần tự với yêu cầu chốt trước và kết thúc bằng việc huỷ sau 745 triệu USD. Với phần mềm, nhu cầu của người dùng tiếp tục được khám phá; backlog ưu tiên và phát hành theo đợt nhỏ phản ánh thực tế đó.

  • Chu kỳ phản hồi ngắn với người dùng thật (Agile: Deliver value early)

    Jigsaw dùng được sau khoảng bốn tháng ở chính trung tâm điều hành, cho phép người dùng chỉnh hướng liên tục. Giá trị đo được bằng kết quả vận hành (giờ công, nhiên liệu), chứ không chỉ bằng tài liệu bàn giao.

  • Mô hình hợp đồng và quyền truy cập hệ thống nhà thầu (Plan Procurement)

    Việc sửa ALIS phải chờ đến tháng 01/2019 vì thương lượng quyền truy cập hệ thống độc quyền. Với agile, quyền truy cập dữ liệu, mã và môi trường cần được viết vào hợp đồng; nếu không, đội phát triển bị chặn bởi khung mua sắm.

  • Quản trị và báo cáo cho bên cấp vốn (Stakeholder Engagement)

    Một đội agile khó cam kết sản phẩm cụ thể sau một hai năm, trong khi bên cấp vốn cần dự báo. Cần chỉ số giá trị, hạn mức đầu tư theo đợt và tầm nhìn sản phẩm thay cho danh sách tính năng cố định.

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

    1. 1

      Bước 1: Thiết kế mua sắm theo đợt giá trị thay vì danh sách yêu cầu

      Chọn cấu trúc hợp đồng phù hợp với mức độ chắc chắn của yêu cầu:

      • Đợt nhỏ có thể dừng

        Hợp đồng hoặc đơn hàng theo đợt ngắn, mỗi đợt có mục tiêu giá trị và tiêu chí chấp nhận, có thể dừng hoặc chuyển hướng không phạt.

      • Hạn mức và trần theo giai đoạn

        Giá theo công sức đội nhưng có hạn mức theo giai đoạn và rà soát giá trị đã giao trước khi cấp thêm vốn.

      • Cấu trúc nên tránh

        Một hợp đồng giá cố định theo danh sách yêu cầu chốt sớm cho sản phẩm còn nhiều bất định thì nên tránh.

    2. 2

      Bước 2: Viết quyền truy cập dữ liệu, mã và môi trường vào hợp đồng

      Với hệ thống nhà thầu liên quan, thoả thuận trước quyền truy cập, giao diện và dữ liệu để đội phát triển không phải chờ thương lượng từng lần.

    3. 3

      Bước 3: Báo cáo bên cấp vốn bằng chỉ số giá trị và lộ trình

      Dùng tầm nhìn sản phẩm, chỉ số kết quả vận hành và bản trình diễn định kỳ để thay cho cam kết danh sách tính năng dài hạn.

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

    Với phần mềm, hợp đồng nên mua khả năng học và giao giá trị theo đợt, không mua một danh sách yêu cầu cứng. Agile trong khu vực công vẫn cần quyền truy cập rõ ràng và cách báo cáo mới cho bên cấp vốn.

    Nguồn tham khảo

    • Wikipedia — Kessel Run
    • GAO-23-105867 — Defense Software Acquisitions: Changes to Requirements, Oversight, and Tools Needed for Weapon Programs
    #Quản lý mua sắm#agile#Hợp đồng agile#Không quân Mỹ#Kessel Run#gao

    Nguồn: Wikipedia — Kessel Run ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Cơ quan của bạn cần một công cụ phần mềm mà người dùng chưa mô tả được hết nhu cầu. Phòng mua sắm đề nghị lập danh sách yêu cầu chi tiết rồi đấu thầu giá cố định. Bạn nên đề xuất gì?

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

    Bạn mua phần mềm cho một đơn vị vận hành với yêu cầu thay đổi liên tục. Chọn mô hình 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ý Mua sắm

    Novopay (New Zealand): hệ thống lương cho khoảng 90.000 nhân viên trường học và năng lực quản lý hợp đồng của bên mua

    Bộ Giáo dục New Zealand chọn Talent2 sau đấu thầu để làm hệ thống lương Novopay, chạy từ tháng 8/2012 và gây hàng nghìn lỗi trả lương. Cuộc điều tra cấp bộ (6/2013) kết luận việc chọn nhà thầu không sai, nhưng bộ thiếu kinh nghiệm thương mại, quản trị yếu và báo cáo cho bộ trưởng quá lạc quan; chi phí tăng khoảng 23,9 triệu NZD. Phân tích quản lý mua sắm và nghiệm thu.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận10/10/2026
    Số 140Quản lý Mua sắm

    Hertz kiện Accenture: 32 triệu USD cho dự án website và ứng dụng di động, đồng hồ go-live trượt hai lần rồi bị chấm dứt hợp đồng

    Năm 2016 Hertz thuê Accenture làm lại website và ứng dụng di động. Theo hồ sơ khởi kiện tháng 04/2019, Hertz đã trả 32 triệu USD, mốc go-live 12/2017 trượt sang 01/2018 rồi 04/2018, và Hertz chấm dứt hợp đồng năm 2018. Hertz nêu các cáo buộc về chất lượng mã, kiểm thử và phạm vi; Accenture phản bác. Phân tích điều khoản nghiệm thu, thay đổi và tiêu chí chất lượng trong hợp đồng với nhà tích hợp số.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận04/10/2026
    Số 141Quản lý Mua sắm

    Munich LiMux: gần 15.000 máy tính chuyển sang Linux rồi quay lại Windows, và câu hỏi về khoá nhà cung cấp và tổ chức

    Thành phố Munich (Đức) năm 2003 chọn hệ thống Linux riêng LiMux thay Windows, đến năm 2013 đã chuyển trên 15.000 máy. Tháng 11/2017 hội đồng quyết định quay lại phần mềm nền Windows trước năm 2020. Các nguồn nêu nguyên nhân khác nhau: tương thích phần mềm, vấn đề tổ chức, chính trị. Một ví dụ cân nhắc khoá nhà cung cấp, chi phí chuyển đổi và quản trị nguồn mở.

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