Tại sao 70% dự án phần mềm overrun
Standish Group report: 70% dự án IT thất bại (overrun > 30% time/cost hoặc bị cancel). Lý do top: scope creep, no clear ownership, poor communication, không có change control.
Nguyên tắc 1: Có 'product owner' nội bộ
CEO không thể owner mọi dự án. Cần product owner cấp manager (PM, CTO, hoặc functional lead) dành 20-30% time/tuần cho dự án. Họ là single point of contact với vendor.
Không có product owner → CEO bị nhồi 50 câu hỏi/tuần → bottleneck → dự án chậm.
Nguyên tắc 2: Sprint 2 tuần + demo thật
Chia dự án thành sprint 2 tuần. Cuối mỗi sprint, vendor demo feature thật chạy được - không slide, không mockup. CEO xem 30 phút mỗi sprint, đánh giá progress thật.
Demo thật eliminate "đang code" magic. Nếu sprint 4 mà chưa có gì demo → dự án đang fail.
Nguyên tắc 3: Đo deliverable không đo effort
Tránh đo "đội code 200 giờ tuần này" - meaningless. Đo: feature X done? UAT pass? User can use không?
Vendor báo "95% complete" nhiều tháng → đỏ. Done là done - binary.
Nguyên tắc 4: Change request có quy trình
Stakeholder request feature mới giữa chừng - phổ biến + đáng. Nhưng phải qua quy trình:
- Stakeholder submit request viết (Google Form, email).
- Product owner đánh giá: in scope hay không?
- Nếu mới: vendor estimate cost + timeline impact.
- CEO + sponsor approve hoặc reject.
- Update scope doc + sign.
Không quy trình → scope creep 50-100%. Hợp đồng có quy trình change request rõ là điều kiện cần.
Nguyên tắc 5: Risk register update hằng tuần
List 5-10 risk cao nhất + mitigation plan. Update hằng tuần. Vd:
- Risk: vendor delay tuần 6 do dev nghỉ ốm. Mitigation: vendor allocate backup dev.
- Risk: data migration phức tạp hơn dự kiến. Mitigation: dry-run 3 lần trước go-live.
- Risk: nhân viên resist phần mềm mới. Mitigation: training + incentive adoption.
CEO đọc risk register hằng tuần 5 phút. Focus on top 3 risk.
Nguyên tắc 6: Communication rhythm cố định
- Standup vendor + product owner: 2 lần/tuần.
- Sprint demo CEO: 1 lần/2 tuần.
- Steering committee (CEO + product owner + vendor lead): 1 lần/tháng.
- Email update weekly từ product owner.
Rhythm cố định eliminate "không có thông tin" panic. CEO biết khi nào sẽ có update - không cần đuổi vendor.
Khi nào escalate
- Vendor miss 2 sprint liên tiếp → escalate, possible terminate.
- Budget overrun > 20% → review scope.
- Stakeholder không adopt sau 30 ngày → fix change management.
- Critical bug production > 1 tuần unresolved → demand vendor escalate engineer.
Cho CEO doanh nghiệp Việt: communication channel chính nên là Slack/Microsoft Teams + bổ sung Zalo group cho urgent (đặc biệt vendor + nhân viên outsource quen Zalo). Standup nên qua Google Meet/Zoom có ghi VND vào quote chi phí rõ ràng.
CEO đang manage dự án phần mềm? Alodev tham vấn miễn phí 60 phút + audit dự án hiện tại. /lien-he
