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. /FBI Sentinel (2006–2012): yêu cầu sáu năm tuổi, …
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.

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

Bối cảnh thực tế

Năm 2005, FBI bỏ dự án hồ sơ điện tử Virtual Case File. Năm 2006, cơ quan này khởi động Sentinel, giao nhà thầu chính Lockheed Martin xây hệ thống quản lý hồ sơ vụ án điện tử để thay quy trình giấy. Kế hoạch ban đầu gồm bốn giai đoạn, chi phí khoảng 425 triệu USD và hoàn thành vào tháng 12/2009; về sau ngân sách được nâng lên 451 triệu USD.

Theo bài của Nextgov (10/2010) dựa trên báo cáo tạm thời của thanh tra Bộ Tư pháp:

  • Đến tháng 8/2010 FBI đã chi khoảng 405 triệu USD trên 451 triệu, nhưng mới giao hai trong bốn giai đoạn cho cán bộ và nhà phân tích.
  • Thanh tra nhận định dự án trễ khoảng hai năm và vượt ít nhất 100 triệu USD.
  • Cán bộ vẫn phải in biểu mẫu ra để lấy chữ ký phê duyệt và giữ hồ sơ giấy; chưa có hai thành phần cuối nên chưa tìm kiếm được hồ sơ.
  • Các yêu cầu kỹ thuật đã sáu năm tuổi, thanh tra đề nghị đánh giá lại để tìm phương án rẻ hơn.

Tháng 3/2010, FBI ra lệnh dừng một phần với Lockheed (một phần giai đoạn 3 và toàn bộ giai đoạn 4) vì phản hồi tiêu cực của người dùng về hiệu năng, tính dễ dùng và chất lượng. Tháng 7/2010 họ ra lệnh dừng toàn bộ phần việc còn lại. Tháng 9/2010, FBI công bố hướng phát triển theo kiểu agile, chủ yếu do nhân sự nội bộ thực hiện và giảm bớt một số năng lực của hệ thống. Thanh tra lo ngại kế hoạch này chưa được phê duyệt chính thức, chưa có văn bản, FBI thiếu kinh nghiệm agile và phần việc khó nhất vẫn còn phía trước; họ khuyến nghị đánh giá lại và xếp thứ tự ưu tiên các yêu cầu còn lại, đồng thời khôi phục đánh giá sức khoẻ dự án và EVM. FBI phản biện rằng báo cáo dùng ước tính chi phí lỗi thời. Theo Wikipedia, dự án sau đó có lãnh đạo mới, ngân sách nhỉnh hơn và phương pháp agile, rồi được dùng toàn cơ quan từ 1/7/2012; một cuộc kiểm toán năm 2014 vẫn ghi nhận hạn chế ở chức năng tìm kiếm.

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

  • Yêu cầu bị đóng băng trong khi bối cảnh thay đổi (Collect Requirements)

    Bộ yêu cầu viết từ 2004–2006 được dùng để xây phần còn lại ở năm 2010. Công nghệ, quy trình nghiệp vụ và kỳ vọng người dùng đều đã đổi. Yêu cầu phải được xem là tài liệu sống, có kiểm soát thay đổi và định kỳ rà soát lại giá trị, không phải bản hợp đồng bất biến.

  • Phạm vi chia theo giai đoạn nhưng không gắn giá trị người dùng (Define Scope, Validate Scope)

    Hai giai đoạn đầu giao xong mà cán bộ vẫn chưa bỏ được giấy và chưa tìm được hồ sơ — tức giá trị cốt lõi nằm ở các giai đoạn sau. Khi bàn giao theo phân hệ kỹ thuật thay vì theo luồng nghiệp vụ trọn vẹn, nghiệm thu từng phần không phản ánh việc người dùng làm được gì.

  • Thiếu cơ chế xếp hạng yêu cầu theo giá trị

    Thanh tra phải khuyến nghị “xếp thứ tự ưu tiên các yêu cầu còn lại”, nghĩa là chưa có backlog xếp hạng. Khi không có ưu tiên, mọi yêu cầu đều coi là bắt buộc, chi phí và thời gian đẩy lên, còn việc cắt giảm chỉ xảy ra khi đã cạn tiền.

  • Kiểm soát và giám sát bị lơi khi dự án trượt (Monitor and Control Project Work)

    Khuyến nghị khôi phục EVM và đánh giá sức khoẻ dự án cho thấy chúng đã bị bỏ dở ở giai đoạn cần nhất. Đồng thời kế hoạch agile mới lại chưa được văn bản hoá và phê duyệt, nên thay đổi cách làm mà thiếu đường cơ sở mới để đo.

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

    1. 1

      Bước 1: Rà soát yêu cầu theo chu kỳ và có ngưỡng kích hoạt

      Đặt lịch xem lại danh mục yêu cầu (ví dụ mỗi năm hoặc khi trễ quá mốc) và quy định khi nào phải đánh giá lại phạm vi:

      • Còn giá trị

        Yêu cầu gắn với một luồng nghiệp vụ người dùng vẫn đang làm hằng ngày; giữ và xếp hạng theo tác động.

      • Cần xem lại

        Yêu cầu dựa trên công nghệ hoặc quy trình đã đổi; làm việc lại với người dùng để cập nhật trước khi xây.

      • Loại hoặc hoãn

        Yêu cầu không còn ai dùng hoặc chi phí vượt xa giá trị; đưa qua kiểm soát thay đổi để loại khỏi đường cơ sở.

    2. 2

      Bước 2: Bàn giao theo lát cắt nghiệp vụ trọn vẹn

      Thay vì chia theo thành phần kỹ thuật, chia theo luồng đầu cuối (tạo hồ sơ, phê duyệt điện tử, tìm kiếm). Mỗi lát cắt được người dùng thật dùng thử, giúp phát hiện sớm phản hồi tiêu cực như đã xảy ra năm 2010.

    3. 3

      Bước 3: Văn bản hoá kế hoạch mới và lập đường cơ sở trước khi đổi cách làm

      Khi chuyển sang agile giữa chừng, lập backlog đã xếp hạng, tiêu chí hoàn thành, chỉ số tiến độ theo tốc độ đội và ngân sách còn lại. Trình ban chỉ đạo và bên giám sát phê duyệt qua Perform Integrated Change Control.

    4. 4

      Bước 4: Giữ giám sát độc lập suốt dự án

      Duy trì báo cáo EVM hoặc burn-up, đánh giá sức khoẻ dự án định kỳ và đối thoại cởi mở với thanh tra; phản biện bằng số liệu hiện hành thay vì tranh luận ước tính cũ hay mới.

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

    Một bộ yêu cầu cũ không phải là hợp đồng thiêng liêng. Khi dự án đã tiêu hao phần lớn ngân sách mà người dùng chưa làm được việc cốt lõi, PM phải dám đặt lại phạm vi, xếp hạng theo giá trị và công khai đường cơ sở mới, thay vì tiếp tục xây phần còn lại của một bản đặc tả lỗi thời.

    Nguồn tham khảo

    • Nextgov — Inspector general slams FBI IT program; bureau officials defend it
    • Nextgov — Report: FBI case management system still falls short
    • Wikipedia — Sentinel (FBI)
    #Quản lý phạm vi#yeu-cau#FBI#agile#Chính phủ Mỹ#Cứu vãn dự án

    Nguồn: Nextgov — Inspector general slams FBI IT program; bureau officials defend it (10/2010) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Bạn tiếp quản một dự án hồ sơ điện tử đã chi hơn 85% ngân sách nhưng mới giao một nửa số giai đoạn; người dùng vẫn phải in giấy để lấy chữ ký. Bộ yêu cầu được viết sáu năm trước. Việc nên làm ĐẦU TIÊN là gì?

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

    Dự án đã chi hơn 85% ngân sách, mới xong nửa số giai đoạn, nhà thầu bị người dùng phản hồi chất lượng kém. 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ý 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

    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
    Số 90Quản lý Phạm vi

    Hệ thống hành lý tự động sân bay Denver: mở rộng phạm vi ra toàn sân bay khi chỉ còn hơn một năm và cái giá 16 tháng trễ khai trương

    Từ một hệ thống hành lý cho riêng United Airlines, Denver mở rộng phạm vi thành hệ thống tích hợp cho cả 3 phòng chờ, mọi hãng bay, chốt hợp đồng chỉ sau 3 buổi làm việc rồi tiếp tục nhận yêu cầu thay đổi. Sân bay khai trương trễ 16 tháng. Phân tích theo Define Scope, Control Scope và kiểm soát thay đổi tích hợp.

    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)