CPI (Cost Performance Index) và SPI (Schedule Performance Index) là gì?

Trong sách PMP, CPI (Cost Performance Index) và SPI (Schedule Performance Index) thường xuất hiện như những công thức:

• CPI = EV / AC
• SPI = EV / PV

CPI (Cost Performance Index) và SPI (Schedule Performance Index) là các chỉ số then chốt trong phương pháp Quản lý Giá trị Thu được (Earned Value Management - EVM):

1. CPI - Chỉ số Hiệu suất Chi phí

CPI dùng để đo lường hiệu quả sử dụng ngân sách của dự án.

• Công thức: CPI = EV / AC

  • EV (Earned Value): Giá trị thu được (Giá trị công việc thực tế đã hoàn thành).
  • AC (Actual Cost): Chi phí thực tế (Số tiền thực tế đã chi ra).

Ý nghĩa:

• CPI > 1: Dưới ngân sách (Đang tiết kiệm chi phí).
• CPI < 1: Vượt ngân sách (Đang chi tiêu quá mức).

2. SPI - Chỉ số Hiệu suất Tiến độ

SPI dùng để đo lường hiệu quả thực hiện theo tiến độ đã đề ra.

• Công thức: SPI = EV / PV

  • EV (Earned Value): Giá trị thu được.
  • PV (Planned Value): Giá trị lập kế hoạch (Giá trị công việc dự kiến phải hoàn thành tính đến hiện tại).

Ý nghĩa:

• SPI > 1: Vượt tiến độ (Dự án đang chạy nhanh hơn kế hoạch).
• SPI < 1: Chậm tiến độ (Dự án đang trễ so với kế hoạch).

Nghe thì “chuẩn chỉ”, nhưng nhiều PM đọc xong vẫn hỏi: “Rồi dùng nó trong đời thực kiểu gì?”

Vấn đề là CPI/SPI không sinh ra để báo cáo cho đẹp. Nó là hệ thống radar cảnh báo sớm giúp PM ra quyết định khi dự án còn cứu được.

Dưới đây là cách chúng thật sự vận hành trong một dự án phần mềm.

Case study: Dự án phát triển hệ thống CRM trong 6 tháng

• Tổng ngân sách (BAC): 3 tỷ
• Thời gian: 6 tháng
• Chia thành 3 mốc lớn:

1. Core platform
2. Integration
3. Go-live

Sau 3 tháng, ban lãnh đạo hỏi:
👉🏻 “Tình hình sao rồi?”

Team trả lời kiểu quen thuộc:

• Dev: “Cũng gần xong rồi.”
• Tech lead: “Chắc khoảng 70–80%.”
• BA: “Còn vài luồng phức tạp.”
• QA: “Chưa test nên chưa biết.”

Nghe có vẻ ổn… nhưng không ai thật sự biết.

Áp dụng Earned Value

PM chuẩn hóa lại theo EVM:

• PV (Planned Value): theo kế hoạch, 3 tháng phải hoàn thành 50% → 1.5 tỷ
• AC (Actual Cost): đã tiêu 1.8 tỷ
• Sau khi review scope DONE thật sự, PM xác nhận EV = 1.2 tỷ (≈ 40%)

Tính toán

• CPI = 1.2 / 1.8 = 0.67
• SPI = 1.2 / 1.5 = 0.8

Ý nghĩa trong thực tế

CPI = 0.67

👉🏻 Mỗi 1 đồng bỏ ra chỉ thu được 0.67 đồng giá trị.
👉🏻 Team đang "đốt tiền" nhanh hơn giá trị tạo ra.

Nếu xu hướng này giữ nguyên, chi phí cuối dự án có thể vọt lên gần 4.5 tỷ thay vì 3 tỷ.

SPI = 0.8

👉🏻 Tốc độ hiện tại chỉ đạt 80% so với kế hoạch.
👉🏻 Deadline 6 tháng gần như chắc chắn trượt.

Điểm quan trọng: Lúc này mới là giữa dự án

Đây chính là sức mạnh của CPI/SPI.

Nếu đợi đến tháng thứ 6 mới biết trễ và vượt ngân sách thì đã quá muộn.
Nhưng ở tháng thứ 3, PM còn đủ không gian để can thiệp.

CPI/SPI giúp PM đặt các câu hỏi đúng

Thay vì hỏi:
❌ “Bao giờ xong?”

PM hỏi:
✅ “Tại sao chúng ta tiêu tiền nhanh hơn giá trị tạo ra?”

Và bắt đầu nhìn thấy sự thật:

• Rework nhiều
• Scope hiểu chưa rõ
• Dev senior làm việc của junior
• Estimate quá lạc quan
• Task mở nhưng chưa thật sự DONE

Hành động thực tế từ CPI/SPI

Từ radar này, PM và lãnh đạo có thể quyết định:

1. Cắt scope / giảm tham vọng

Chuyển một số tính năng sang Phase 2.

2. Thay đổi cấu trúc team

Bổ sung BA, tăng QA sớm để giảm rework.

3. Review lại Definition of Done

Không cho phép claim % ảo.

4. Đàm phán lại timeline hoặc ngân sách

Làm sớm → còn uy tín.

CPI/SPI giỏi nhất ở điều gì?

Không phải đo lường.
Mà là phá vỡ ảo giác “chúng ta gần xong rồi.”

Rất nhiều dự án phần mềm thất bại vì:

90% trong 90% thời gian đầu,
và 10% cuối chiếm nốt 90% thời gian còn lại.

CPI/SPI bóc trần điều này bằng số liệu.

  Vì sao ảo giác "gần xong" xuất hiện?

Hoàn thành coding ≠ hoàn thành deliverable

Dev viết xong chức năng → nghĩ là xong.
Nhưng sau đó mới bắt đầu:

• Test
• Fix bug
• Integration
• Performance
• security
• UAT
• Deploy
• Tài liệu
• Training

Phần “10% cuối” thật ra là cả một thế giới việc.

Phần khó nhất thường nằm ở cuối

Lúc đầu xử lý "happy path" rất nhanh.
Càng về cuối càng gặp:

• Edge case
• Dữ liệu bẩn
• Phụ thuộc hệ thống khác
• Yêu cầu mơ hồ trước đó

Tiến độ vì thế giảm mạnh.

% hoàn thành thường mang tính cảm giác

Con người có xu hướng lạc quan.
“Chắc còn tí thôi” = câu nói gây trễ deadline nhiều nhất ngành IT.

Nhìn dưới góc độ quản trị

Câu này mô tả một thứ nguy hiểm hơn trễ tiến độ:

→ mất khả năng dự báo.

Nếu tháng nào cũng báo 80–90% nhưng không bao giờ về đích,
lãnh đạo không thể:

• Lên kế hoạch kinh doanh
• Chuẩn bị marketing
• Cam kết với khách hàng

Ví dụ thực tế

Deadline còn 1 tháng.
Team báo: 90% rồi.

Khi soi kỹ:

• Chưa test tích hợp
• Chưa migrate data
• Chưa qua security review
• Chưa chuẩn bị môi trường production

→ thực tế mới khoảng 60–70%.

Một góc nhìn thực chiến mà PM lâu năm hay dùng

Người ta không nhìn CPI/SPI ở một thời điểm.

Họ nhìn trend:

• CPI đang đi lên → team học được cách làm hiệu quả hơn.
• CPI đi xuống → nợ kỹ thuật (technical debt) hoặc rework đang tăng.
• SPI giảm dần → bottleneck sắp nảy sinh (bùng nổ xung đột về schedule)

Trend cho phép PM dự đoán tương lai, chứ không chỉ báo cáo quá khứ.

Khi nào CPI/SPI đặc biệt hữu ích trong phần mềm?

• Dự án fixed price
• Có deadline cứng
• Ban lãnh đạo cần khả năng dự báo
• Chương trình nhiều phụ thuộc (highly interdependent program)
• Stakeholder cần số liệu thay vì cảm giác (cảm tính)

Cách tính CPI/SPI trong JIRA

1️⃣ Quy đổi Jira → Earned Value như thế nào?

Muốn tính được CPI/SPI bạn cần 3 thứ:

• PV (Planned Value) – giá trị đáng lẽ phải hoàn thành tới hôm nay
• EV (Earned Value) – giá trị thực sự đã DONE
• AC (Actual Cost) – chi phí đã tiêu

Jira thường có sẵn scope & tiến độ, còn chi phí thì phải nối thêm từ HR/Finance (thường là phần mềm chấm công).

Cách phổ biến nhất: dùng Story Point hoặc Budget theo Epic

Option A – Story Point

• Tổng SP của dự án = tổng giá trị.
• SP của các issue DONE = EV.
• SP dự kiến DONE tới hôm nay theo plan = PV.

Option B – Budget theo Epic / Feature (được lãnh đạo thích hơn)

• Mỗi Epic có trọng số tiền.
• Epic hoàn thành → ghi nhận EV.
• Epic theo kế hoạch phải xong → PV.

2️⃣ Công thức (vẫn vậy nhưng data từ Jira)

• CPI = EV / AC
• SPI = EV / PV

Ví dụ:

• Planned đến hôm nay: 500 SP
• Done thật: 420 SP
• Đã tiêu 900 triệu, trong khi ngân sách cho 420 SP theo baseline là 700 triệu

→ CPI = 700 / 900
→ SPI = 420 / 500

3️⃣ Các mẹo thực chiến để dựng dashboard từ Jira

Không tính:

• In Review
• In Test
• Code Complete

Chỉ những gì đạt Definition of Done.

Nếu không, CPI/SPI sẽ “đẹp giả”.

Ví dụ mỗi tuần.

Vì issue có thể:

• mở lại
• đổi estimate
• tách nhỏ

Không snapshot → lịch sử bị méo.

PV phải dựa trên kế hoạch ban đầu hoặc đã rebaseline.

Nếu sprint nào cũng đổi plan mà vẫn dùng làm PV, SPI gần như luôn = 1 → vô nghĩa.

Có thể dùng:

• weighted milestone
• hoặc % completion có tiêu chí rõ ràng

Nếu không bạn sẽ thấy:
📉 rất lâu EV = 0
rồi đột nhiên tăng vọt.

Dùng:

• Jira dashboard
• export sang BI
• hoặc plugin EVM

Manual Excel (nhập báo cáo bằng tay) dễ dẫn tới hiện tượng “massage số”.

4️⃣ Các loại thiên kiến (BIAS) nguy hiểm

Đây mới là phần quan trọng!.

Ai cũng tin: “Còn tí thôi”.

Giải pháp:
✔ định nghĩa DONE rõ (Definition of Done - DoD)
✔ phải qua test / deploy được

Team ngại các báo cáo không tốt đẹp về họ.

Kết quả:

• issue bị giữ ở DONE dù còn bug
• hoặc giảm estimate để velocity trông cao

Giải pháp: Hãy thuyết phục team rằng số liệu để giải quyết vấn đề, không phải trừng phạt. Biến nó thành văn hóa chuẩn mực trong tài liệu nội bộ công ty (SOP).

Nếu SP tăng lên sau khi làm → CPI/SPI nhìn sẽ tốt hơn giả tạo.

Giải pháp:
✔ lock estimate (chốt dự toán) khi bắt đầu làm
✔ thay đổi phải được ghi nhận và có lý do.

Bug quay lại nhưng không tính chi phí → CPI ảo.

Giải pháp:
✔ log đầy đủ effort fix bug
✔ tính vào AC.

5️⃣ Nguyên tắc vàng

Garbage in → garbage out.

CPI/SPI không thông minh hơn dữ liệu bạn nhập.

6️⃣ Cách PM kỳ cựu kiểm tra nhanh xem số có “thật” không

Họ sẽ hỏi:

• Nếu SPI tốt → vì sao vẫn OT?
• Nếu CPI tốt → vì sao burn rate vẫn tăng?
• Nếu gần xong → demo production được chưa?

Nếu câu trả lời không khớp → có vấn đề với data.

7️⃣ Mục tiêu cuối cùng

Không phải tạo dashboard đẹp.

Mà là có hệ thống cảnh báo đủ sớm để:

• cắt scope
• tăng nguồn lực
• đổi chiến lược

trước khi quá muộn.

Kết luận

CPI/SPI không phải bài toán. Nó là hệ thống cảnh báo sớm để ra quyết định quản trị.

PM không dùng nó để tính. PM dùng nó để hành động.

CPI và SPI không tồn tại để PM trở thành “kế toán dự án”, cũng không phải để làm ra những biểu đồ xanh đỏ cho đẹp trong slide. Giá trị thật của chúng nằm ở việc tạo ra minh bạch về thực trạng, càng sớm càng tốt. Khi dữ liệu được lấy trực tiếp từ Jira, được khóa baseline rõ ràng, có Definition of Done nghiêm túc và effort được ghi nhận trung thực, CPI/SPI trở thành một loại radar quản trị: nó cho bạn biết xu hướng đang tốt lên hay xấu đi, liệu team đang học nhanh hơn hay đang chìm dần trong rework, liệu deadline có còn khả thi hay đã bắt đầu trượt khỏi tầm với. Quan trọng hơn, nó giúp chuyển cuộc hội thoại từ cảm giác sang bằng chứng; từ “em nghĩ là kịp” sang “với vận tốc hiện tại, chúng ta sẽ thiếu X tuần và Y ngân sách”. Khi có sự thật này trên bàn, lãnh đạo mới có thể đưa ra quyết định đúng: cắt scope, tăng nguồn lực, thay đổi chiến lược release, hay thương lượng lại cam kết với khách hàng. Không có dữ liệu đáng tin, mọi kế hoạch chỉ là hy vọng. Và trong môi trường nhiều phụ thuộc của phần mềm, hy vọng không phải là một chiến lược.