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. /DIMHRS (Bộ Quốc phòng Mỹ): 12 năm, khoảng 1 tỷ U…
Quản lý Phạm vi

DIMHRS (Bộ Quốc phòng Mỹ): 12 năm, khoảng 1 tỷ USD cho một hệ thống nhân sự – lương chung chưa bao giờ được đưa vào dùng

DIMHRS nhằm thay khoảng 90 hệ thống nhân sự và trả lương của các quân chủng Mỹ bằng một hệ thống chung dựa trên phần mềm thương mại. Từ năm 2005, GAO cảnh báo yêu cầu chung chưa đầy đủ và chính xác, cách tiếp cận bị chi phối bởi lịch hợp đồng và quản trị thiếu tích hợp. Năm 2010, Bộ trưởng Quốc phòng huỷ chương trình. Bài học về xác định phạm vi khi nhiều bên có nhu cầu khác nhau.

HP
Nguyễn Thu Hà, PMP
11/06/2026
4 phút đọc 0 lượt xem
DIMHRS (Bộ Quốc phòng Mỹ): 12 năm, khoảng 1 tỷ USD cho một hệ thống nhân sự – lương chung chưa bao giờ được đưa vào dùng
Bình luận0

Bối cảnh thực tế

Quân đội Mỹ từ lâu gặp lỗi trả lương do hệ thống nhân sự và hệ thống lương của từng quân chủng tách rời, nhiều hệ thống viết bằng công nghệ từ thập niên 1960. Defense Integrated Military Human Resources System (DIMHRS), khởi động cuối thập niên 1990, nhằm hợp nhất chúng thành một hệ thống nhân sự – lương chung cho toàn bộ lực lượng, dựa trên phần mềm thương mại có sẵn.

Báo cáo GAO-05-189 (11/2/2005) nhận định:

  • Bộ Quốc phòng chưa bảo đảm yêu cầu chung của hệ thống là đầy đủ, chính xác và được người dùng chấp nhận.
  • Chương trình thiếu cơ chế quản trị tích hợp đại diện cho mọi bên — các quân chủng và cơ quan tài chính quốc phòng — với trách nhiệm rõ ràng.
  • Cách tiếp cận bị chi phối bởi lịch hợp đồng; GAO khuyến nghị chuyển sang cách tiếp cận dựa trên sự kiện và rủi ro, cùng văn hoá vốn kháng cự giải pháp dùng chung toàn bộ.

Theo Stars and Stripes (2/2010): sau khoảng 12 năm và khoảng 1 tỷ USD, nhiều lần lùi ngày triển khai (mốc đầu tiên là 4/2006), hệ thống vẫn chưa được đưa vào dùng; Bộ trưởng Quốc phòng và Chủ tịch Hội đồng Tham mưu trưởng Liên quân thông báo huỷ chương trình chung trước Uỷ ban Quân vụ Thượng viện. Các quân chủng tự hiện đại hoá hệ thống của mình.

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

  • Phạm vi "một hệ thống cho tất cả" khi nhu cầu chưa thống nhất

    Thu thập yêu cầu (Collect Requirements) từ nhiều bên có quy trình khác nhau cần kỹ thuật ra quyết định nhóm (group decision-making) và phân tích khoảng cách. Nếu các quân chủng không đồng thuận về quy trình chung, phần mềm thương mại sẽ bị yêu cầu tuỳ biến theo từng bên, phá vỡ chính giả định "dùng sản phẩm có sẵn".

  • Thiếu nhà tài trợ có thẩm quyền trên mọi bên

    Dự án liên tổ chức cần cơ chế quản trị (governance) có quyền quyết định cuối cùng về yêu cầu xung đột. GAO chỉ ra cấu trúc ban đầu thiếu quản trị tích hợp; không ai đủ thẩm quyền buộc các quân chủng thay đổi quy trình.

  • Lịch trình dẫn dắt, không phải sự kiện dẫn dắt

Bám mốc hợp đồng trong khi yêu cầu chưa ổn định là cách nhanh nhất để thiết kế sai. Điểm chuyển giai đoạn phải dựa trên điều kiện đầu vào (entry criteria) — ví dụ yêu cầu đã được người dùng xác nhận — chứ không dựa trên ngày.

  • Kháng cự văn hoá là rủi ro phạm vi

    Kháng cự với giải pháp dùng chung là yếu tố môi trường doanh nghiệp (enterprise environmental factor) đã được nêu rõ. Nó cần được đưa vào phân tích bên liên quan và kế hoạch quản lý thay đổi tổ chức, không chỉ ghi nhận.

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

    1. 1

      Bước 1: Thống nhất quy trình nghiệp vụ trước khi thống nhất hệ thống

      Tổ chức các hội thảo yêu cầu (facilitated workshops) để các bên đồng ý một quy trình chuẩn; phần khác biệt bắt buộc được ghi rõ và có lý do.

    2. 2

      Bước 2: Thiết lập quản trị với quyền quyết định thật

      Một hội đồng cấp cao đại diện mọi bên, có nhà tài trợ đủ thẩm quyền phân xử:

      • Quyết định yêu cầu

        Yêu cầu xung đột được phân xử trong thời hạn cố định; kết quả ràng buộc mọi bên.

      • Giới hạn tuỳ biến

        Đặt ngưỡng tối đa cho tỷ lệ tuỳ biến phần mềm thương mại; vượt ngưỡng phải trình hội đồng.

      • Điều kiện chuyển giai đoạn

        Chỉ chuyển sang xây dựng khi yêu cầu chung đã được người dùng mọi bên ký xác nhận.

    3. 3

      Bước 3: Thử nghiệm với một quân chủng trước

      Triển khai thí điểm cho một bên để kiểm chứng giả định trước khi mở rộng, thay vì cam kết đồng thời cho mọi bên.

    4. 4

      Bước 4: Đưa quản lý thay đổi tổ chức vào phạm vi

      Đào tạo, truyền thông và hỗ trợ chuyển đổi quy trình là gói công việc trong WBS, có ngân sách riêng.

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

    Một hệ thống dùng chung chỉ khả thi khi các bên đã đồng ý một cách làm chung. Nếu chưa có đồng thuận về quy trình và một cơ chế quản trị đủ quyền phân xử, phạm vi "một hệ thống cho tất cả" sẽ trôi dạt thành vô số yêu cầu riêng.

    Nguồn tham khảo

    • GAO-05-189 — DOD Systems Modernization: Management of Integrated Military Human Capital Program Needs Additional Improvements
    • Stars and Stripes (02/2010) — DIMHRS program dumped as a disaster
    #Quản lý phạm vi#Thu thập yêu cầu#quản trị dự án#Phần mềm thương mại#gao

    Nguồn: GAO-05-189 — DOD Systems Modernization: Management of Integrated Military Human Capital Program Needs Additional Improvements ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Bạn quản lý dự án triển khai một phần mềm nhân sự thương mại dùng chung cho 4 đơn vị. Mỗi đơn vị yêu cầu giữ quy trình riêng, khiến khối lượng tuỳ biến tăng gấp ba so với ước tính. Hành động nào phù hợp nhất?

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

    Nếu là PM của DIMHRS năm 2005, sau khi GAO cảnh báo yêu cầu chung chưa hoàn chỉnh và lịch hợp đồng chi phố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)