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. /IRS CADE và CADE 2 (Mỹ): bắt đầu với 30% tờ khai…
Số 119Quản lý Phạm vi

IRS CADE và CADE 2 (Mỹ): bắt đầu với 30% tờ khai đơn giản nhất, rồi mắc kẹt khi phạm vi chạm tới phần phức tạp

Từ năm 1999, Sở Thuế vụ Mỹ (IRS) xây CADE để thay hệ thống Individual Master File đã hàng chục năm tuổi. CADE xử lý được khoảng 41 triệu tờ khai đơn giản nhưng việc mở rộng sang tài khoản phức tạp bị đánh giá có thể kéo tới 2020 hoặc lâu hơn. Năm 2008 IRS đổi chiến lược sang CADE 2; năm 2021 GAO cho biết việc hoàn tất bị dời tới 2030. Bài học về chia phạm vi tăng dần.

HP
Nguyễn Thu Hà, PMP
17/01/2026
4 phút đọc 0 lượt xem
IRS CADE và CADE 2 (Mỹ): bắt đầu với 30% tờ khai đơn giản nhất, rồi mắc kẹt khi phạm vi chạm tới phần phức tạp
Bình luận0

Bối cảnh thực tế

Individual Master File (IMF) là hệ thống lưu trữ và xử lý dữ liệu thuế cá nhân của IRS, được xây dựng từ khoảng 60 năm trước và vẫn đang chạy. Năm 1999 IRS khởi động CADE (Customer Account Data Engine) để thay thế dần IMF.

Theo GAO-11-168 (3/2011):

  • Từ 2005, CADE bắt đầu xử lý tờ khai của cá nhân có tình huống thuế đơn giản. Đến 2010, CADE đã xử lý khoảng 41 triệu tờ khai (khoảng 30% tổng số tờ khai thuế thu nhập cá nhân) và phát khoảng 36 triệu khoản hoàn thuế, nhanh hơn IMF khoảng 5 ngày.
  • Năm 2008, một nhóm rà soát của IRS chỉ ra 6 rủi ro: thiếu kiến trúc đích (target-state architecture) gây làm lại; độ phức tạp có thể đẩy việc hoàn tất tới 2020 hoặc lâu hơn; vận hành hai hệ thống song song làm mùa khai thuế phức tạp hơn; chi phí cập nhật thay đổi luật thuế hằng năm tăng; khó tích hợp tài khoản phức tạp; thiếu nhân sự am hiểu IMF và CADE.
  • Tháng 8/2008 IRS chuyển sang chiến lược CADE 2: trước hết chuyển xử lý hằng tuần sang hằng ngày và xây cơ sở dữ liệu tài khoản toàn diện, rồi mới loại bỏ IMF.

Bài blog của GAO (11/2021) cho biết một cấu phần chính của CADE 2 dự kiến xong năm 2014 bị dời sang 2023, và việc hoàn tất toàn bộ bị dời tới 2030, với chi phí cao hơn đáng kể so với ước tính ban đầu.

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

  • Chia phạm vi theo "dễ trước" mà không có kiến trúc đích

    Bắt đầu với tờ khai đơn giản giúp có giá trị sớm — một quyết định phạm vi hợp lý. Nhưng khi không có kiến trúc đích, mỗi lớp phức tạp thêm vào buộc phải làm lại phần đã xây. Phạm vi tăng dần cần một "bức tranh cuối" để từng increment khớp vào, giống WBS cần mục tiêu dự án ở đỉnh.

  • 30% đầu dễ, 70% còn lại không tuyến tính

    Tỷ lệ khối lượng không phản ánh tỷ lệ độ phức tạp. Phần tài khoản phức tạp chứa phần lớn quy tắc ngoại lệ và tích hợp. Ước tính bằng phép ngoại suy từ phần dễ là cái bẫy kinh điển của ước tính tương tự (analogous estimating) khi các phần không tương đồng.

Vận hành song song là phạm vi ẩn

Hai hệ thống chạy song song nghĩa là mỗi thay đổi luật thuế phải làm hai lần, đối soát dữ liệu giữa hai nơi. Công việc này phải nằm trong WBS và ước tính; nếu không, chi phí "giữ cho mọi thứ chạy" sẽ ăn dần nguồn lực phát triển.

  • Rủi ro nguồn lực chuyên môn hiếm

    Thiếu người am hiểu hệ thống cũ là rủi ro có thể dự báo trong dự án thay thế kéo dài hàng chục năm. Kế hoạch quản lý nguồn lực cần chiến lược chuyển giao tri thức sớm.

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

    1. 1

      Bước 1: Xác định kiến trúc đích trước khi mở rộng phạm vi

      Thống nhất mô hình dữ liệu và kiến trúc cuối cùng, rồi mới quyết định thứ tự increment. CADE 2 đi đúng hướng khi đặt cơ sở dữ liệu toàn diện làm nền móng.

    2. 2

      Bước 2: Chia increment theo giá trị và rủi ro, có tiêu chí rõ

      Mỗi increment có kết quả đo được và điều kiện để chuyển sang increment sau:

      • Kết quả nghiệp vụ

        Ví dụ: chuyển xử lý từ hằng tuần sang hằng ngày cho mọi tài khoản, đo bằng thời gian cập nhật tài khoản.

      • Mức phức tạp

        Đánh giá số quy tắc nghiệp vụ và điểm tích hợp của từng nhóm tài khoản trước khi ước tính.

      • Chi phí song song

        Ước tính riêng và theo dõi chi phí vận hành song song; vượt ngưỡng thì xem lại thứ tự increment.

    3. 3

      Bước 3: Ước tính phần còn lại từ dưới lên

      Dùng ước tính từ dưới lên (bottom-up) cho phần tài khoản phức tạp thay vì ngoại suy từ phần đơn giản.

    4. 4

      Bước 4: Kế hoạch giữ tri thức hệ thống cũ

      Ghép cặp chuyên gia IMF với nhân sự mới, tài liệu hoá quy tắc nghiệp vụ như một sản phẩm bàn giao.

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

    Phân chia phạm vi "dễ trước" mang lại thành quả sớm, nhưng phần khó không tỷ lệ thuận với khối lượng. Không có kiến trúc đích và ước tính riêng cho phần phức tạp, dự án tăng dần sẽ thành chuỗi làm lại kéo dài hàng chục năm.

    Nguồn tham khảo

    • GAO-11-168 — Taxpayer Account Strategy: IRS Should Finish Defining Benefits and Improve Cost Estimates
    • GAO WatchBlog (11/2021) — IRS Efforts to Modernize 60-Year-Old Tax Processing System Almost a Decade Away
    #Quản lý phạm vi#Phát triển tăng dần#Kiến trúc đích#Hệ thống cũ#gao

    Nguồn: GAO-11-168 — Taxpayer Account Strategy: IRS Should Finish Defining Benefits and Improve Cost Estimates ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Sau 2 năm, dự án thay thế hệ thống cũ đã chuyển thành công 30% giao dịch đơn giản nhất. Nhà tài trợ hỏi bao lâu nữa sẽ xong 70% còn lại. Đội đề xuất ngoại suy: "2 năm cho 30% thì khoảng 4–5 năm cho phần còn lại". PM nên phản hồi thế nào?

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

    Nếu là PM dự án thay thế hệ thống thuế đã chạy 60 năm, bạn chọn chiến lược phạm vi 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)