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. /SSA DCPS (Mỹ): hệ thống xử lý hồ sơ khuyết tật l…
Quản lý Phạm vi

SSA DCPS (Mỹ): hệ thống xử lý hồ sơ khuyết tật làm lại theo Agile nhưng sau 3 năm mới gánh khoảng 7% khối lượng

Cơ quan An sinh Xã hội Mỹ (SSA) xây DCPS để thay các hệ thống riêng của từng cơ quan xét duyệt khuyết tật cấp bang. Bản đầu (ký hợp đồng 2010) bị dừng năm 2015; bản làm lại theo Agile phát hành từ 12/2016 nhưng phạm vi bản đầu nhỏ hơn hẳn cam kết, và đến 9/2019 các đơn vị chỉ xử lý khoảng 7% khối lượng trên DCPS. Tổng Thanh tra không thể kết luận ước tính chi phí, lịch là hợp lý.

HP
Nguyễn Thu Hà, PMP
17/02/2026
4 phút đọc 0 lượt xem
SSA DCPS (Mỹ): hệ thống xử lý hồ sơ khuyết tật làm lại theo Agile nhưng sau 3 năm mới gánh khoảng 7% khối lượng
Bình luận0

Bối cảnh thực tế

Các cơ quan xét duyệt khuyết tật cấp bang (Disability Determination Services — DDS) đánh giá hồ sơ xin trợ cấp khuyết tật cho SSA; năm tài khoá 2019 họ xử lý khoảng 4,2 triệu hồ sơ. Mỗi DDS dùng một hệ thống tuỳ biến riêng, tốn khoảng 31 triệu USD mỗi năm để vận hành. DCPS (Disability Case Processing System) là hệ thống chung nhằm thay thế chúng.

Diễn biến theo báo cáo của Tổng Thanh tra SSA (12/2019) và FedScoop (7/2014):

  • 12/2010: SSA ký hợp đồng phát triển DCPS. Đến 6/2014, một công ty tư vấn đánh giá hệ thống có chức năng hạn chế, trễ lịch và bên liên quan ngày càng lo ngại; FedScoop cho biết khoản đầu tư khi đó khoảng 280–300 triệu USD.
  • 5/2015: SSA dừng bản beta. 10/2015: khởi động lại, chuyển từ cách phát triển truyền thống sang Agile.
  • 9/2015: SSA báo bản phát hành khả dụng đầu tiên (12/2016) sẽ hỗ trợ mọi cấp hồ sơ và loại yêu cầu. 5/2016: thu hẹp còn hồ sơ ban đầu và xem xét lại. Thực tế 12/2016: bản đầu chỉ xử lý được một số ít loại hồ sơ, tại 3 DDS.
  • 9/2019: DCPS có mặt ở 31 trên 52 DDS, xử lý trung bình khoảng 7% khối lượng; các DDS cho biết khoảng trống chức năng ngăn họ dùng nhiều hơn. SSA từng báo Quốc hội việc phát triển sản phẩm hoàn tất 9/2019, nhưng vẫn tiếp tục phát triển sau đó.
  • Ước tính chi phí đến năm tài khoá 2022 khoảng 178 triệu USD; Tổng Thanh tra không thể kết luận ước tính là hợp lý vì SSA chưa xác định khi nào DCPS có đủ chức năng để các DDS bỏ hệ thống cũ.

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

  • Cam kết phạm vi bản phát hành đầu vượt quá hiểu biết

    Hứa "mọi cấp hồ sơ và loại yêu cầu" cho bản đầu khi vừa khởi động lại là cam kết phạm vi cố định trong môi trường bất định cao. Trong cách tiếp cận thích ứng, cam kết với bên ngoài nên ở mức mục tiêu và khoảng thời gian, còn phạm vi cụ thể được làm rõ qua từng vòng lặp.

  • Không có định nghĩa "đủ để bỏ hệ thống cũ"

    Mục tiêu nghiệp vụ là thay hệ thống của từng DDS, nhưng thiếu một định nghĩa rõ về tập chức năng tối thiểu để một DDS ngừng hệ thống cũ. Khi không có đích phạm vi đó, lộ trình sản phẩm (product roadmap) không thể ước tính ngày hoàn thành — đúng điểm Tổng Thanh tra nêu.

  • Agile nhưng báo cáo theo kiểu dự đoán

    Báo cáo Quốc hội "phát triển hoàn tất" theo lộ trình trong khi sản phẩm chưa đủ dùng là lẫn lộn giữa hoàn thành kế hoạch và đạt kết quả. Chỉ số phù hợp hơn là tỷ lệ khối lượng xử lý trên DCPS và số DDS đã ngừng hệ thống cũ.

  • Chi phí song song là phần của trường hợp kinh doanh

    Mỗi năm DDS còn chạy hệ thống cũ là thêm chi phí vận hành; ước tính DCPS chỉ tính chi phí phát triển sẽ làm sai lệch đánh giá giá trị của việc trễ.

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

    1. 1

      Bước 1: Xác định "phạm vi ngừng hệ thống cũ" làm đích lộ trình

      Cùng các DDS liệt kê tập chức năng tối thiểu để tắt hệ thống cũ, rồi đo tiến độ theo tỷ lệ hoàn thành tập này.

    2. 2

      Bước 2: Cam kết theo khoảng và cập nhật minh bạch

      Với nhà tài trợ và Quốc hội, dùng dự báo dựa trên dữ liệu:

      • Dự báo theo tốc độ thực

        Ngày dự kiến tính từ backlog còn lại chia tốc độ thực tế, trình bày dạng khoảng.

      • Chỉ số kết quả

        Báo cáo tỷ lệ khối lượng xử lý trên DCPS và số DDS đã tắt hệ thống cũ mỗi quý.

      • Thay đổi cam kết

        Mọi thu hẹp phạm vi bản phát hành so với cam kết trước phải được thông báo kèm lý do và ngày mới.

    3. 3

      Bước 3: Ưu tiên khoảng trống chức năng mà DDS báo cáo

      Thu thập định kỳ từ quản trị viên DDS những chức năng còn thiếu cản trở việc dùng hệ thống, xếp hạng theo khối lượng hồ sơ bị ảnh hưởng.

    4. 4

      Bước 4: Đưa chi phí vận hành song song vào ước tính

      Tính tổng chi phí sở hữu gồm cả chi phí duy trì hệ thống cũ cho tới khi ngừng hẳn.

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

    Chuyển sang Agile không làm mất câu hỏi "khi nào xong". Cần một đích phạm vi gắn với kết quả nghiệp vụ — ở đây là ngày tắt hệ thống cũ — để lộ trình, ước tính và báo cáo có ý nghĩa với nhà tài trợ.

    Nguồn tham khảo

    • SSA OIG A-14-18-50742 (12/2019) — The Social Security Administration's Cost and Schedule Estimates for the Disability Case Processing System
    • FedScoop (07/2014) — Problem project threatens progress at Social Security Administration
    #Quản lý phạm vi#agile#Lộ trình sản phẩm#Ước tính#Kiểm toán CNTT

    Nguồn: SSA OIG A-14-18-50742 — The Social Security Administration's Cost and Schedule Estimates for the Disability Case Processing System ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Nhà tài trợ yêu cầu PM của một sản phẩm Agile cam kết ngày "hoàn tất" để báo cáo cơ quan cấp trên. Backlog còn lớn và người dùng vẫn báo thiếu chức năng để bỏ hệ thống cũ. PM nên trả lời thế nào?

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

    Nếu là PM DCPS năm 2016, khi thấy bản phát hành đầu không thể có đủ chức năng như đã báo Quốc hội, bạn chọn gì?

    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)