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. /Chương trình đăng ký súng (Canada): chi phí ròng…
Số 339Quản lý Phạm vi

Chương trình đăng ký súng (Canada): chi phí ròng dự kiến 2 triệu thành hơn 1 tỷ đô la khi hệ thống được xây trước khi luật và quy định ổn định

Năm 1995, Bộ Tư pháp Canada báo với Quốc hội chương trình đăng ký súng tốn 119 triệu đô la và gần như tự bù bằng phí. Đến năm 2000, ước tính đã là ít nhất 1 tỷ đô la. Tổng Kiểm toán chỉ ra Quốc hội không được cung cấp đủ thông tin, còn hệ thống CNTT liên tục phải xây khi luật và quy định chưa chốt. Bài học về kiểm soát phạm vi khi yêu cầu còn biến động.

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

Bối cảnh thực tế

Luật Súng đạn năm 1995 yêu cầu cấp phép cho người sở hữu và đăng ký từng khẩu súng trên toàn Canada. Bộ Tư pháp báo với Quốc hội chi phí triển khai khoảng 119 triệu đô la, trong đó 117 triệu sẽ thu lại từ phí, nên chi phí ròng chỉ khoảng 2 triệu.

Theo báo cáo của Uỷ ban Tài khoản Công Hạ viện (2003) và các phiên điều trần với Tổng Kiểm toán:

  • Năm 2000, Bộ ước tính sẽ chi ít nhất 1 tỷ đô la đến năm tài khoá 2004–05, trong khi phí thu được (sau hoàn trả) chỉ khoảng 140 triệu.
  • Báo cáo tháng 12/2002 của Tổng Kiểm toán (chương 10) kết luận Quốc hội không nhận đủ thông tin để giám sát; thông tin tài chính đưa ra "nhỏ giọt" và không đáng tin cậy để phản ánh chi phí ròng.
  • Giai đoạn 1995–96 đến 2001–02, khoảng 70% trong số 750 triệu được xin qua dự toán bổ sung, thay vì dự toán chính như phần lớn chương trình khác.
  • Nguyên nhân được nêu gồm: một số tỉnh rút khỏi việc phối hợp và vụ kiện lên Toà án Tối cao làm thay đổi mô hình thực hiện ban đầu; luật và quy định liên tục thay đổi, ngoài chu kỳ ngân sách; vấn đề công nghệ; biểu mẫu quá phức tạp với tỉ lệ sai cao gây tồn đọng.
  • Kiểm toán tiếp theo chỉ ra việc phát triển hệ thống thông tin trước khi luật và quy định được hoàn thiện là yếu tố then chốt làm tăng chi phí. Hệ thống CFIS đầu tiên tốn gần 190 triệu đô la đến 03/2005 (gồm vận hành, bảo trì) so với ước tính ban đầu 13–20 triệu; hệ thống thay thế CFIS II lại lặp lại sai lầm xây trước khi các thay đổi quy định hoàn tất.

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

  • Phạm vi được xây trên yêu cầu chưa ổn định

    Luật và quy định chính là nguồn yêu cầu của hệ thống. Khi chúng còn thay đổi, mọi phần thiết kế đều có nguy cơ làm lại. Thu thập yêu cầu (Collect Requirements) cần xác định yêu cầu nào đã "đóng băng" đủ để xây, yêu cầu nào phải chờ.

  • Thay đổi phạm vi không đi qua đường cơ sở được công bố

    Thay đổi diễn ra thường xuyên, ngoài chu kỳ ngân sách, và được tài trợ chủ yếu qua dự toán bổ sung. Đường cơ sở phạm vi và chi phí vì thế không còn là thước đo; Kiểm soát phạm vi (Control Scope) mất tác dụng khi thay đổi không được tổng hợp tác động.

  • Bỏ sót phạm vi phi phần mềm

    Biểu mẫu phức tạp, tỉ lệ sai cao, tồn đọng hồ sơ và chiến dịch tiếp cận chủ sở hữu súng là công việc có thật nhưng không nằm rõ trong WBS ban đầu. Phân rã phạm vi phải bao gồm cả quy trình nghiệp vụ và trải nghiệm người dùng, không chỉ hệ thống.

  • Giả định về bên liên quan sụp đổ mà mô hình không được cập nhật

    Mô hình ban đầu dựa vào sự tham gia của các tỉnh. Khi giả định này sai, tuyên bố phạm vi (scope statement) và business case lẽ ra phải được lập lại chính thức.

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

    1. 1

      Bước 1: Phân loại yêu cầu theo mức ổn định trước khi xây

      Gắn mỗi nhóm chức năng với trạng thái của văn bản pháp lý tương ứng:

      • Được xây

        Luật và quy định đã ban hành, quy tắc nghiệp vụ đã được cơ quan chủ quản ký xác nhận.

      • Thiết kế linh hoạt

        Quy định đang dự thảo: tách thành tham số cấu hình, không lập trình cứng.

      • Chưa xây

        Chính sách còn tranh luận hoặc đang bị kiện: chỉ phân tích, không phát triển.

    2. 2

      Bước 2: Lập lại đường cơ sở khi mô hình thực hiện thay đổi

      Khi các tỉnh rút lui, lập lại tuyên bố phạm vi, ước tính và trình Quốc hội chi phí đầy đủ thay vì xin bổ sung từng phần.

    3. 3

      Bước 3: Đưa trải nghiệm người nộp hồ sơ vào phạm vi

      Thử nghiệm biểu mẫu với người dùng thật trước khi phát hành rộng; đo tỉ lệ hồ sơ lỗi như một chỉ số chất lượng của phạm vi.

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

    Khi yêu cầu đến từ luật và quy định còn đang thay đổi, xây hệ thống trước là đặt cược phạm vi vào một mục tiêu di động. Hãy chỉ xây phần đã ổn định, tham số hoá phần còn biến động và công bố tác động tổng hợp của mọi thay đổi lên đường cơ sở.

    Nguồn tham khảo

    • Hạ viện Canada — Public Accounts Committee, Report 24 (2003)
    • Tổng Kiểm toán Canada — Chương 10, Costs of implementing the Canadian Firearms Program (12/2002)
    • Hạ viện Canada — Điều trần PACP với Tổng Kiểm toán (2006)
    #Quản lý phạm vi#Yêu cầu biến động#Kiểm soát phạm vi#Minh bạch chi phí#Kiểm toán nhà nước#Canada

    Nguồn: House of Commons Canada — Public Accounts Committee, Report 24: Canadian Firearms Program (2003) ↗ (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 xây hệ thống cấp phép theo một luật mới. Các quy định hướng dẫn vẫn đang dự thảo và có thể thay đổi đáng kể trong 6 tháng tới, nhưng nhà tài trợ muốn bắt đầu lập trình ngay để kịp ngày luật có hiệu lực. Bạn nên làm gì?

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

    Nếu là PM của chương trình cuối thập niên 1990, khi một số tỉnh rút khỏi việc phối hợp và quy định tiếp tục thay đổi, 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)