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. /Hệ thống lương và nhân sự PPARS (Ireland): ước t…
Số 342Quản lý Phạm vi

Hệ thống lương và nhân sự PPARS (Ireland): ước tính 9,14 triệu euro thành hơn 130 triệu euro chi tiêu khi dự án không có phạm vi rõ ràng từ đầu

Năm 1998, ngành y tế Ireland khởi động PPARS — hệ thống lương và nhân sự dùng chung — với ước tính 9,14 triệu euro. Phạm vi mở rộng qua nhiều lần, có tới bảy lần ước tính chi phí, triển khai chỉ ở một phần tổ chức, rồi bị dừng năm 2005 và bỏ hẳn năm 2007. Kiểm toán nhà nước kết luận dự án thiếu phạm vi rõ ràng từ đầu và được quản lý kém.

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

Bối cảnh thực tế

PPARS (Personnel, Payroll and Related Systems) được khởi động năm 1998 nhằm thay các hệ thống lương và nhân sự rời rạc của ngành y tế Ireland. Ước tính ban đầu là 9,14 triệu euro và khung thời gian hai năm, chỉ cho năm trong mười hội đồng y tế cùng Bệnh viện St James ở Dublin.

Theo báo cáo của Tổng Kiểm toán (C&AG) năm 2005 và báo chí Ireland:

  • Dự án không có phân tích chi phí chi tiết cho đến khi đã vượt ngân sách nhiều; ước tính đầu tiên bỏ sót nâng cấp hạ tầng và hỗ trợ kỹ thuật sau cài đặt. Đến năm 2005 đã có bảy lần ước tính chi phí.
  • Đến cuối 08/2005 đã chi 131 triệu euro, trong đó tư vấn và nhà thầu là khoản lớn nhất (57 triệu). Ước tính triển khai toàn ngành là ít nhất 240 triệu.
  • Không có bằng chứng về khoản tiết kiệm chi phí nhân sự kỳ vọng; hệ thống không được thử nghiệm thí điểm đầy đủ. Một báo cáo năm 2002 đã nêu các rủi ro lớn nhưng không được tiếp thu đủ.
  • Sự cố nổi bật: một nhân viên ở vùng Tây Bắc được trả thừa 1 triệu euro.
  • Tháng 10–11/2005, Cơ quan Y tế (HSE) dừng triển khai. Tháng 7/2007, HSE bỏ việc triển khai tiếp; khi đó hệ thống chỉ chạy ở ba vùng và Bệnh viện St James. C&AG nhận xét dự án không có phạm vi đủ rõ ràng ngay từ đầu.

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

  • Không có tuyên bố phạm vi rõ ràng và được phê duyệt

    Phạm vi ban đầu chỉ là một phần ngành y tế, sau đó dần trở thành hệ thống cho toàn ngành, nhưng không có lần định nghĩa lại chính thức nào. Thiếu tuyên bố phạm vi (Define Scope) với ranh giới, sản phẩm bàn giao và loại trừ, mọi ước tính đều dựa trên nền móng mơ hồ.

  • WBS bỏ sót công việc hỗ trợ

    Hạ tầng và hỗ trợ sau triển khai không có trong ước tính đầu tiên. Nguyên tắc 100% của WBS yêu cầu mọi công việc cần thiết để tạo ra sản phẩm — kể cả chuyển giao và vận hành — phải được thể hiện.

  • Bảy lần ước tính nhưng không lần nào là đường cơ sở được kiểm soát

Ước tính thay đổi liên tục mà không có đường cơ sở phạm vi tương ứng nghĩa là thay đổi phạm vi diễn ra ngầm. Kiểm soát phạm vi cần gắn mỗi lần điều chỉnh chi phí với một thay đổi phạm vi được phê duyệt.

  • Lợi ích không được định nghĩa thành tiêu chí đo được

    Tiết kiệm nhân sự được kỳ vọng nhưng không đạt và không được theo dõi. Phạm vi sản phẩm nên đi kèm các chỉ số lợi ích để có thể Xác nhận phạm vi theo giá trị.

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

    1. 1

      Bước 1: Viết tuyên bố phạm vi có ranh giới và loại trừ

      Nêu rõ tổ chức nào, quy trình lương và nhân sự nào, quy tắc lương nào thuộc phạm vi; những gì không làm trong giai đoạn này.

    2. 2

      Bước 2: Thí điểm trước khi mở rộng

      Dùng kết quả thí điểm làm cổng quyết định mở rộng phạm vi:

      • Mở rộng

        Lương chạy chính xác nhiều kỳ liên tiếp ở đơn vị thí điểm, chi phí thực tế khớp ước tính.

      • Kéo dài thí điểm

        Còn sai sót lương được phát hiện và sửa kịp; cần thêm thời gian ổn định.

      • Dừng mở rộng

        Có sai sót lương nghiêm trọng hoặc chi phí thực tế vượt xa ước tính: rà soát lại phạm vi và cách tiếp cận.

    3. 3

      Bước 3: Lập WBS đầy đủ, gồm hạ tầng và vận hành

      Áp dụng nguyên tắc 100% để ước tính bao gồm hạ tầng, đào tạo, chuyển đổi dữ liệu và hỗ trợ sau triển khai.

    4. 4

      Bước 4: Gắn mỗi lần điều chỉnh ngân sách với một yêu cầu thay đổi phạm vi

      Không cho phép ước tính mới nếu không chỉ ra được thay đổi phạm vi nào gây ra nó.

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

    Một dự án không có phạm vi rõ ràng từ đầu sẽ có ước tính trôi theo mọi kỳ vọng mới. Viết tuyên bố phạm vi có ranh giới, lập WBS đủ 100% công việc và dùng thí điểm làm cổng trước khi mở rộng là cách giữ dự án trong tầm kiểm soát.

    Nguồn tham khảo

    • Irish Examiner — PPARS became ‘money pit’ (12/2005)
    • The Irish Times — HSE to abandon roll-out of Ppars system (07/2007)
    • Magill — The PPARS Debacle (05/2007)
    #Quản lý phạm vi#Tuyên bố phạm vi#Ước tính chi phí#Hệ thống lương#Y tế công#Ireland

    Nguồn: Irish Examiner — PPARS became ‘money pit’ (12/2005) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Dự án hệ thống lương của bạn ban đầu phục vụ một nửa số đơn vị, nay nhà tài trợ muốn mở rộng ra toàn ngành. Ước tính chi phí đã thay đổi sáu lần và chưa có tài liệu nào mô tả ranh giới phạm vi hiện tại. Bạn nên làm gì trước tiên?

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

    Nếu là CEO của HSE tháng 11/2005, khi PPARS đã tiêu hơn 130 triệu euro và chỉ chạy ở một phần ngành y tế, 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

    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)