Việc các tính năng hoặc thay đổi mới được thêm vào giữa chừng dự án mà không có kế hoạch phù hợp là một cơn đau đầu kinh niên của các Project Manager. Nó thường được biết đến với cái tên ‘scope creep’ hay ‘feature creep’, và nó có khả năng làm trật bánh các mốc thời gian, ngân sách, và cả tinh thần của đội nhóm.
Vấn đề cốt lõi không nhất thiết nằm ở bản thân yêu cầu thay đổi, mà ở sự thiếu vắng một quy trình để quản lý sự xuất hiện của nó.
Hiểu được nguyên nhân sâu xa là điều tối quan trọng. Đôi khi, nó xuất phát từ các bên liên quan (stakeholder) không nắm bắt đầy đủ phạm vi ban đầu của dự án hoặc những hệ lụy của việc thay đổi. Những lúc khác, nó lại được thúc đẩy bởi một nhu cầu thực sự cần thích ứng với điều kiện thị trường đang biến đổi hoặc phản hồi từ người dùng. Bất kể nguồn gốc là gì, một câu trả lời “có” một cách bị động hay một lời từ chối thẳng thừng “không” hiếm khi là cách tiếp cận tốt nhất.
Có một vài giải pháp khả thi. Chúng ta có thể triển khai một quy trình yêu cầu thay đổi chính thức, giáo dục các stakeholder về vòng đời của dự án, và thúc đẩy giao tiếp cởi mở. Một quy trình yêu cầu thay đổi sẽ cung cấp một phương pháp có cấu trúc để đánh giá tác động của bất kỳ thay đổi nào được đề xuất lên phạm vi, lịch trình và ngân sách của dự án. Điều này bao gồm việc lập tài liệu về sự thay đổi, đánh giá tác động của nó, và nhận được sự chấp thuận từ các stakeholder liên quan trước khi triển khai. Việc giáo dục các stakeholder giúp họ hiểu được sự phức tạp của việc phát triển phần mềm và những hậu quả tiềm tàng của các thay đổi không được kiểm soát.
Trong số các giải pháp này, một quy trình yêu cầu thay đổi chính thức, kết hợp với việc giao tiếp nhất quán, thường là hiệu quả nhất. Mặc dù việc giáo dục các stakeholder là có lợi, đó lại là một chiến lược dài hạn. Quy trình yêu cầu thay đổi cung cấp sự kiểm soát ngay lập tức, cho phép Project Manager đánh giá tính khả thi, chi phí và tác động.
Cách tiếp cận tối ưu tập trung vào việc hợp tác, chứ không phải đối đầu.
Do đó, câu trả lời nên là “Không, nhưng…”. Nó ghi nhận yêu cầu nhưng đồng thời giới thiệu một khuôn khổ cần thiết để đánh giá đúng đắn.
Để triển khai giải pháp này, cần tạo ra một mẫu yêu cầu thay đổi (chi tiết hóa sự thay đổi, lý do chính đáng, và tác động tiềm tàng), xác định một luồng phê duyệt (ai cần phải ký duyệt), và tích hợp quy trình này vào kế hoạch giao tiếp của dự án. Điều cốt yếu là Project Manager cần phải là người đi đầu và bảo vệ cho quy trình này, đảm bảo nó được áp dụng một cách nhất quán.
Sau khi triển khai, thành công được đo lường bằng sự sụt giảm các yêu cầu thay đổi đột xuất (ad-hoc), việc tuân thủ tốt hơn các mốc thời gian và ngân sách dự án, và sự hài lòng của stakeholder tăng lên (ngay cả khi một số yêu cầu cuối cùng bị từ chối). Các chỉ số chính bao gồm số lượng yêu cầu thay đổi được xử lý chính thức so với không chính thức, tỷ lệ phần trăm các dự án được giao đúng hạn và trong ngân sách, cùng với phản hồi từ các stakeholder và đội ngũ dự án.
Cuối cùng, hãy liên tục cải tiến bằng cách thường xuyên xem xét lại chính quy trình yêu cầu thay đổi.
Nó có quá rườm rà không? Nó có đang bị bỏ qua không? Hãy thu thập phản hồi từ đội nhóm và các stakeholder để xác định các lĩnh vực cần tinh chỉnh, đảm bảo quy trình vẫn hiệu quả và phù hợp với nhu” cầu đang phát triển của dự án. Mục tiêu là tạo ra một hệ thống cân bằng được giữa sự linh hoạt và khả năng kiểm soát, cho phép những sự điều chỉnh cần thiết mà không gây nguy hiểm cho sự thành công của dự án.
