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. /OPM RetireEZ (Mỹ): hệ thống tính lương hưu bị dừ…
Số 117Quản lý Phạm vi

OPM RetireEZ (Mỹ): hệ thống tính lương hưu bị dừng sau 3 tháng vận hành vì phạm vi và yêu cầu chưa được quản lý

Văn phòng Quản lý Nhân sự Mỹ (OPM) đưa phiên bản đầu của hệ thống hiện đại hoá xử lý hưu trí vào vận hành tháng 2/2008, phải dừng vào tháng 5, chấm dứt hợp đồng với nhà thầu chính tháng 10 và cuối cùng huỷ chương trình năm 2011. GAO chỉ ra 5 điểm yếu: kế hoạch thiếu phạm vi rõ ràng, ước tính chi phí, EVM, quản lý yêu cầu và kiểm thử.

HP
Nguyễn Thu Hà, PMP
18/05/2026
4 phút đọc 0 lượt xem
OPM RetireEZ (Mỹ): hệ thống tính lương hưu bị dừng sau 3 tháng vận hành vì phạm vi và yêu cầu chưa được quản lý
Bình luận0

Bối cảnh thực tế

OPM xử lý hồ sơ nghỉ hưu cho công chức liên bang Mỹ — một quy trình vốn dựa nhiều vào giấy tờ và tính toán thủ công. Chương trình hiện đại hoá (về sau gọi là RetireEZ) nhằm số hoá hồ sơ và tự động tính quyền lợi hưu trí.

Theo Nextgov (10/2008), hợp đồng chính trao tháng 5/2006 cho Hewitt Associates có giá trị khoảng 290 triệu USD trong 10 năm. Bộ tính quyền lợi phải đạt độ chính xác 95% trên tổng số ca kiểm thử và 100% ở các ca trọng yếu, mô phỏng 132 tình huống nghỉ hưu.

Diễn biến theo GAO-09-529 (21/4/2009):

  • Tháng 1/2008, GAO đã khuyến nghị xử lý các rủi ro triển khai; dù vậy OPM vẫn đưa phiên bản giới hạn vào vận hành cuối tháng 2/2008.
  • Tháng 5/2008, OPM dừng hệ thống vì vấn đề chất lượng; sau 5 tháng cố khắc phục, tháng 10/2008 chấm dứt hợp đồng với nhà thầu chính.
  • GAO chỉ ra 5 điểm yếu: kế hoạch chương trình không xác định phạm vi và mục tiêu đo được; ước tính chi phí và quản lý giá trị thu được (EVM) không tin cậy; không có quy trình quản lý yêu cầu; kiểm thử lập kế hoạch quá muộn; giám sát yếu.

Hai bên đổ lỗi cho nhau: nhà thầu cho rằng mình đã làm đúng cam kết hợp đồng giữa lúc chủ đầu tư quản lý chương trình yếu kém. Tháng 2/2011, OPM quyết định chấm dứt chương trình hiện đại hoá.

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

  • Không có đường cơ sở phạm vi thì không đo được gì

    Đường cơ sở phạm vi (scope baseline) gồm bản mô tả phạm vi, WBS và từ điển WBS. Khi kế hoạch chương trình không xác định phạm vi và mục tiêu đo được, EVM cũng mất ý nghĩa: không thể tính giá trị thu được (EV) cho công việc chưa được định nghĩa. Hai điểm yếu "phạm vi" và "EVM" của GAO thực chất là một.

  • Thiếu quản lý yêu cầu nên quy tắc nghiệp vụ phức tạp không được nắm

    Tính lương hưu công chức chứa rất nhiều quy tắc ngoại lệ. Kế hoạch quản lý yêu cầu (requirements management plan) phải mô tả cách thu thập, phân tích, ưu tiên, truy vết và kiểm soát thay đổi yêu cầu. Thiếu nó, nhà thầu và chủ đầu tư hiểu "đúng" theo hai cách khác nhau — đúng như tranh cãi sau khi chấm dứt hợp đồng.

  • Kiểm thử được nghĩ tới quá muộn

    Tiêu chí 95%/100% trên 132 tình huống là tiêu chí chấp nhận tốt, nhưng chỉ có giá trị nếu kế hoạch kiểm thử, dữ liệu kiểm thử và các ca kiểm thử được xây cùng lúc với yêu cầu. Lập kế hoạch kiểm thử muộn biến tiêu chí chấp nhận thành bất ngờ ở cuối dự án.

  • Bỏ qua cảnh báo khi quyết định triển khai

    Đưa hệ thống vào vận hành dù đã được cảnh báo rủi ro là quyết định đi/không đi (go/no-go) thiếu căn cứ. Quy trình Xác nhận phạm vi phải diễn ra trước khi chuyển giao, không phải sau khi người dùng đã gặp lỗi.

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

    1. 1

      Bước 1: Viết bản mô tả phạm vi có mục tiêu đo được

      Xác định rõ sản phẩm bàn giao, loại hồ sơ hưu trí được xử lý trong từng giai đoạn, những gì nằm ngoài phạm vi, và chỉ số thành công (thời gian xử lý, tỷ lệ chính xác).

    2. 2

      Bước 2: Gắn yêu cầu với ca kiểm thử ngay từ đầu

      Mỗi quy tắc tính toán là một yêu cầu có ca kiểm thử tương ứng trong ma trận truy vết:

      • Bộ tình huống chuẩn

        Bộ ca kiểm thử chuẩn do chuyên gia nghiệp vụ của chủ đầu tư xây và ký duyệt trước khi phát triển.

      • Ngưỡng chính xác

        Đạt 100% ở ca trọng yếu và ngưỡng thống nhất ở ca còn lại trong kiểm thử độc lập trước khi vận hành.

      • Kiểm soát thay đổi yêu cầu

        Mọi thay đổi quy tắc đi qua kiểm soát thay đổi, cập nhật cả ca kiểm thử và ước tính.

    3. 3

      Bước 3: Đặt điểm go/no-go dựa trên kết quả kiểm thử

      Quyết định đưa vào vận hành phải do bên có thẩm quyền đưa ra dựa trên kết quả kiểm thử chấp nhận và các rủi ro còn mở, có phương án quay lui về quy trình cũ.

    4. 4

      Bước 4: Thiết lập EVM trên đường cơ sở đã được kiểm chứng

      Chỉ báo cáo CPI/SPI sau khi đường cơ sở đo lường hiệu suất (performance measurement baseline) được rà soát độc lập.

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

    Khi phạm vi và yêu cầu không được xác định chặt, mọi công cụ kiểm soát khác — EVM, kiểm thử, hợp đồng — đều mất điểm tựa. Hãy viết tiêu chí chấp nhận cùng lúc với yêu cầu, và để kết quả kiểm thử quyết định ngày vận hành.

    Nguồn tham khảo

    • GAO-09-529 — Retirement Modernization Planning and Management Shortcomings Need to Be Addressed
    • Nextgov (10/2008) — OPM pulls plug on $290 million RetireEZ contract
    #Quản lý phạm vi#Quản lý yêu cầu#Tiêu chí chấp nhận#Kiểm thử#gao

    Nguồn: GAO-09-529 — Office of Personnel Management: Retirement Modernization Planning and Management Shortcomings Need to Be Addressed ↗ (mở trong thẻ mới)

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

    Câu 1/1
    PM dự án hệ thống tính quyền lợi báo cáo CPI = 1,05 và SPI = 0,98. Kiểm toán viên phát hiện dự án chưa có WBS chi tiết và bản mô tả phạm vi chưa xác định các loại hồ sơ cần xử lý. Nhận định nào đúng nhất?

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

    Nếu là PM của OPM, ngay sau khi phải dừng hệ thống vì lỗi tính toán, bạn chọn hướng nào để cứu chương trình?

    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)