Vài điểm Ban biên tập muốn chia sẻ:
1. Bỏ qua lập luận "đã chi 2,8 tỷ rồi". Đó là chi phí chìm (sunk cost) — đã chi thì không lấy lại được và không nên ảnh hưởng tới quyết định tương lai. Câu hỏi đúng là: với số tiền còn lại, phương án nào tạo ra nhiều giá trị nhất?
2. "Cắt đều" nghe công bằng nhưng thường tệ nhất. Mọi hạng mục đều thiếu một chút → có nguy cơ không hạng mục nào đạt chất lượng đủ để dùng. PMBOK 7 khuyến khích tư duy hệ thống và tập trung vào giá trị: nên xếp hạng lại phạm vi theo giá trị kinh doanh và rủi ro, rồi cắt từ dưới lên.
3. Quay về mục tiêu kinh doanh. Hồ sơ kinh doanh (business case) của ứng dụng là gì — tăng tần suất mua lại? Tăng giá trị đơn hàng? Mỗi tính năng đóng góp thế nào vào chỉ số đó? Nếu marketing đúng rằng đổi điểm là động lực chính, có lẽ nên giữ nó và bỏ những thứ khác (ví dụ mạng xã hội trong ứng dụng, giao diện tuỳ biến).
4. Đưa ra 2–3 phương án cho ban giám đốc, nói rõ đánh đổi:
- Phương án A: giữ ngày, bỏ phạm vi theo thứ tự ưu tiên (MoSCoW: Must/Should/Could/Won't), ra mắt bản tối thiểu có giá trị.
- Phương án B: giữ phạm vi lõi, lùi ngày một chút để giảm chi phí tăng ca/thuê ngoài.
- Phương án C: đổi cách làm — ví dụ dùng giải pháp có sẵn cho đổi điểm thay vì tự xây. Thông điệp quan trọng: "giữ ngày + giữ phạm vi + giảm 20% tiền" mà không đổi gì khác thường là không khả thi, PM có trách nhiệm nói rõ điều đó.
5. Tránh tranh giành giữa các nhóm: tổ chức một buổi ưu tiên chung có sponsor tham gia, dùng tiêu chí minh bạch (giá trị, chi phí, rủi ro, phụ thuộc) đã thống nhất trước. Khi tiêu chí rõ, kết quả ít bị coi là "phe nào thắng".
6. Cập nhật baseline chi phí và phạm vi qua kiểm soát thay đổi, và ghi lại vào nhật ký quyết định để sau này không ai hỏi "sao lại bỏ tính năng X".
Tuyên ngôn Agile có một nguyên tắc rất hợp hoàn cảnh này: tối đa hoá lượng công việc không phải làm. Ngân sách bị cắt đôi khi là dịp buộc cả tổ chức trả lời "thực sự cần gì".
Nguồn: