Scope creep: Khi dự án cứ “nở ra” từng ngày

Scope creep không đơn giản chỉ đến từ việc quản lý lỏng lẻo, mà là một vấn đề mang tính hệ thống, chịu ảnh hưởng từ nhiều yếu tố trong tổ chức. Khi thị trường biến động liên tục và các bên liên quan liên tục điều chỉnh kỳ vọng, việc phạm vi dự án “trượt đi” so với ban đầu là điều có thể đoán trước được.

Bài viết dưới đây sẽ tập trung vào những vấn đề của scope creep trong bối cảnh B2B, nơi các doanh nghiệp làm việc cùng nhau, chứ không chỉ ở cấp độ cá nhân.

Scope creep là gì?

Scope creep thường được hiểu là việc phạm vi dự án cứ “nở ra” theo thời gian (dĩ nhiên phần lớn không được kiểm soát) trong khi nguồn lực, thời gian hay ngân sách lại không thay đổi tương ứng.

Trong môi trường B2B (theo Brixon), hiện tượng này thường xảy ra với những tình huống quen thuộc như:

• Những yêu cầu nhỏ dạng: “Thêm nhanh cái này được không?”
• Các hạng mục đã duyệt rồi nhưng vẫn tiếp tục bị chỉnh sửa
• Ranh giới giữa các giai đoạn trong dự án không rõ ràng
• Tiêu chuẩn chất lượng cứ từ từ nâng lên trong lúc đang triển khai
• Xuất hiện thêm stakeholder và kéo theo những yêu cầu mới

Scope creep được hiểu là việc phạm vi dự án cứ “nở ra” theo thời gian trong khi nguồn lực hay ngân sách lại không thay đổi tương ứng.
Nguồn: Brands Vietnam

Vì sao scope creep gần như “không thể tránh khỏi”?

Nhu cầu hình thành theo thời gian

Theo Gartnert, hành trình mua hàng trong môi trường B2B thường bao gồm 4 nhiệm vụ chính: xác định vấn đề, tìm kiếm giải pháp, đưa ra nhu cầu và lựa chọn nhà cung cấp. Vấn đề là, những nhiệm vụ này hiếm khi đi theo một đường thẳng. Thay vào đó, có ít nhất một lần phía khách hàng phải lặp lại 1 trong 4 nhiệm vụ này.

Điều này có nghĩa là nhu cầu được định hình dần theo thời gian. Vậy nên, ngay cả khi dự án đã bắt đầu, khách hàng vẫn có thể đang trong quá trình làm rõ nhu cầu của mình. Chính vì vậy, scope (phạm vi công việc) ban đầu, đôi khi, chỉ phản ánh một phần bề nổi của giải pháp. Khi họ dần làm rõ nhu cầu và điều chỉnh kỳ vọng, phạm vi dự án cũng buộc phải thay đổi theo.

Quá nhiều stakeholder liên quan

Cũng theo Gartner, một “buying group” (nhóm mua hàng) trong B2B trung bình có từ 5 đến 11 người, thậm chí nhiều hơn với những dự án phức tạp. Và đương nhiên, mỗi người mang theo những mục tiêu và ưu tiên khác nhau.

Vì vậy, sự “thành công” của dự án không có một định nghĩa duy nhất. Với marketing, đó có thể là số lượng lead; với sales, là tỷ lệ chuyển đổi; với IT, là tính ổn định của hệ thống; còn với ban lãnh đạo, là hiệu quả đầu tư.

Lúc đầu, scope thường sẽ chỉ thể hiện một phần trong số những kỳ vọng này. Nhưng theo thời gian, khi nhiều stakeholder hơn tham gia, phạm vi dự án sẽ dần dần được điều chỉnh để đáp ứng thêm mục tiêu của những người khác.

Scope creep gần như “không thể tránh khỏi” trong môi trường B2B.
Nguồn: Brands Vietnam

Case-study

Để làm rõ những nguyên nhân gốc rễ của scope creep trong một dự án, Project Management Institute (PMI) – Viện Quản lý Dự án, tổ chức hàng đầu thế giới về quản lý dự án – đã đưa ra một case-study giả định.

Giới thiệu

“Năng lượng mới” là một công ty đang phát triển nhanh trong lĩnh vực cung cấp các giải pháp năng lượng “xanh” như tuabin gió, công nghệ năng lượng mặt trời…

Khi đội ngũ Sales ngày càng mở rộng và các chính sách hoa hồng trở nên đa dạng, công ty nhận thấy cần có một hệ thống quản lý hoa hồng tập trung và tự động, thay thế cho cách làm thủ công bằng bảng tính trước đây.

Dự án

Mai (Quản lý dự án) đã đề xuất một kế hoạch với Đông (Trưởng bộ phận Kế toán). Sau quá trình nghiên cứu ban đầu, họ nhận thấy việc mua một phần mềm có sẵn là giải pháp tiết kiệm chi phí nhất.

Dự án mà Mai đề ra bao gồm các mục tiêu chính:

• Nghiên cứu và lập danh sách 3 phần mềm phù hợp nhất với nhu cầu công ty
• Hỗ trợ lựa chọn phần mềm tối ưu
• Mua phần mềm
• Triển khai cài đặt

Dự án giả định xoay quanh việc mua một phần mềm quản lý hoa hồng.
Nguồn: Brands Vietnam

Diễn biến

Việc nghiên cứu và tìm ra 3 phần mềm phù hợp mất khá nhiều tháng. Quá trình lựa chọn cũng gây tranh cãi. Bộ phận Sales muốn một giải pháp có thể chạy trên web, vì theo Chung (Phó Giám đốc Sales) như vậy sẽ dễ sử dụng hơn cho đội Sales. Trong khi đó, bộ phận Kế toán của Đông lại ưu tiên một hệ thống có bảo mật cao và dễ tùy chỉnh. Tuy nhiên, vì dự án được chi trả từ ngân sách kế toán, nên cuối cùng Đông là người quyết định.

• Sai lầm 1: Sau khi ký hợp đồng phần mềm, Đông quá bận rộn nên gần như giao toàn bộ việc triển khai cho Mai và đội kỹ thuật. Đông vẫn yêu cầu dự án phải hoàn thành đúng deadline, khiến Mai chịu áp lực phải đẩy nhanh tiến độ, dù chưa có đủ thời gian để phân tích yêu cầu kỹ lưỡng, đặc biệt khi đội dự án chỉ có một chuyên viên phân tích hệ thống là Bảo.
• Sai lầm 2: Bảo dành phần lớn thời gian để chuyển dữ liệu từ file Excel sang hệ thống mới và tùy chỉnh các giao diện người dùng. Anh cũng phỏng vấn nhiều nhân sự để hiểu nhu cầu sử dụng. Trong quá trình đó, Chung yêu cầu biến giao diện Sales thành một trang web và Bảo đồng ý vì nghĩ rằng đây là việc đơn giản.
• Sai lầm 3: Trong lúc triển khai, bộ phận Sales thông báo ra mắt một dòng sản phẩm mới với cấu trúc hoa hồng hoàn toàn khác. Đông tổ chức họp và yêu cầu phải tích hợp cả cơ chế hoa hồng mới vào dự án nhưng deadline không thay đổi.
• Sai lầm 4: Trong quá trình cài đặt, Bình (Lập trình viên) và An (Trưởng nhóm Account Payable) phát hiện rằng dự án ban đầu không bao gồm việc tích hợp với các hệ thống khác như sổ cái (General Ledger – G/L). Vì vậy, Bình đề xuất viết thêm một đoạn code để xử lý nhanh. Anh cho rằng việc này sẽ giúp An tiết kiệm nhiều thời gian mỗi kỳ trả lương. Và vì thời gian vẫn còn dư dả nên Mai đã đồng ý. Tuy nhiên, việc code và thử nghiệm mất nhiều thời gian hơn dự kiến nên Bình không kịp kiểm tra hết các trường hợp ngoại lệ.

Những sai lầm trong quá trình triển khai dẫn đến nhiều vấn đề phát sinh.
Nguồn: Brands Vietnam

Kết quả, hệ thống vẫn được triển khai đúng hạn, nhưng phát sinh nhiều vấn đề: một số trường hợp không hoạt động đúng, dữ liệu bị lỗi, báo cáo không chính xác. Và Đông không hài lòng với kết quả này.

Đây là hệ quả bắt nguồn từ 5 nguyên nhân chính.

5 nguyên nhân sâu xa của scope creep

#1. Không xác định scope rõ ràng

Khi scope (phạm vi công việc) không được xác định cụ thể, nó sẽ hình thành một khoảng cách trong cách hiểu của mỗi người, và chính khoảng cách này trở thành nền tảng cho những thay đổi về sau.

Trong trường hợp này, vấn đề bắt đầu từ việc scope của dự án không được làm rõ. Đông và Mai chỉ mô tả scope một cách tổng quan như “nghiên cứu, lựa chọn, mua, lắp đặt” chứ không phân tách thành các hạng mục cụ thể. Bên cạnh đó, dưới áp lực tiến độ, đội ngũ triển khai cũng chỉ phân tích yêu cầu một cách sơ sài, khiến scope ngay từ đầu đã rất mơ hồ.

Sự mơ hồ đó dần bộc lộ trong quá trình thực hiện. Các thành viên trong đội ngũ bắt đầu tự diễn giải yêu cầu theo cách hiểu của mình, hoặc trực tiếp làm việc với những người liên quan để bổ sung thêm những gì họ cho là cần thiết. Điều này thể hiện rõ qua việc Bảo và Chung tự thêm các yếu tố ngoài phạm vi như giao diện web, hay việc Bình và An phát triển thêm tính năng dựa trên đánh giá cá nhân thay vì scope ban đầu.

Nguyên nhân số 1: Không xác định scope rõ ràng.
Nguồn: Brands Vietnam

#2. Thu thập yêu cầu không nhất quán

Khi scope đã mơ hồ, bước tiếp theo — làm rõ và thu thập yêu cầu — dễ trở nên thiếu nhất quán. Trong trường hợp này, không có một quy trình rõ ràng để xác định ai nên tham gia, yêu cầu nào cần được ghi nhận, và đâu là tiêu chí để đưa một yêu cầu vào dự án.

Từ đó, scope không “vỡ” ngay lập tức mà dần bị “trôi” đi. Ban đầu chỉ là một hệ thống quản lý hoa hồng, nhưng qua từng thay đổi nhỏ, phạm vi dự án bắt đầu lệch đi. Ví dụ, việc tích hợp thêm với hệ thống sổ cái (G/L) không hề được xác định từ đầu, nhưng cũng không ai nói rõ là không được làm, nên cuối cùng vẫn được đưa vào scope.

Khi scope càng trở nên mơ hồ, đội ngũ buộc phải hỏi thêm ý kiến từ nhiều bên để làm rõ, và điều này kéo theo việc ngày càng nhiều stakeholder tham gia vào quá trình. Mỗi người lại đóng góp thêm yêu cầu của mình. Chẳng hạn, Chung tham gia và đề xuất thêm giao diện web để phục vụ đội Sales — một yêu cầu nghe có vẻ hợp lý, nhưng thực chất lại nằm ngoài phạm vi.

Nguyên nhân số 2: Thu thập yêu cầu không nhất quán.
Nguồn: Brands Vietnam

#3. Không quản lý thay đổi trong quá trình triển khai

Ngoài việc scope và yêu cầu chưa rõ ràng, các thay đổi phát sinh cũng không được quản lý một cách thống nhất trong suốt quá trình thực hiện. Sau khi phê duyệt scope, phía Đông gần như không còn tham gia sát sao, trong khi lại không có một cơ chế quản lý thay đổi rõ ràng.

Ở phía triển khai, đội ngũ bắt đầu tự quyết định việc thêm hoặc bỏ các tính năng, thay vì có một hệ thống kiểm soát rõ ràng để xác định điều gì thuộc scope và ai là người có quyền quyết định. Chẳng hạn, Bảo đồng ý thêm các yêu cầu ngoài từ Chung, Bình và An chủ động bổ sung tính năng mà không thông qua bất kỳ cuộc họp chính thức hay người chịu trách nhiệm chính nào.

Nguyên nhân số 3: Không quản lý thay đổi trong quá trình triển khai.
Nguồn: Brands Vietnam

#4. Người có quyền quyết định tham gia không đủ sâu

Scope creep không chỉ đến từ việc có quá nhiều ý kiến, mà còn xảy ra khi những người có quyền quyết định lại không tham gia đủ sâu vào dự án.

Ở đây, Đông không chuẩn bị “project charter” (tài liệu chính thức về dự án) mà phụ thuộc hoàn toàn vào Quản lý dự án là Mai. Đồng thời, Đông cũng rút khỏi dự án trong giai đoạn triển khai quan trọng. Khi xuất hiện “khoảng trống” trong việc ra quyết định, đội ngũ sẽ tự lấp vào khoảng trống đó.

Kết quả là scope không được kiểm soát từ những người xác định mục tiêu ban đầu, mà bị dẫn dắt bởi các quyết định nhỏ trong quá trình triển khai.

Nguyên nhân số 4: Người có quyền quyết định tham gia không đủ sâu.
Nguồn: Brands Vietnam

#5. Thời gian kéo dài

Dự án càng kéo dài, khả năng xảy ra scope creep càng cao. Trong quá trình đó, hoạt động kinh doanh có thể thay đổi, người có quyền quyết định có thêm thời gian để điều chỉnh kỳ vọng, và đội ngũ triển khai cũng có nhiều “khoảng trống” hơn để bổ sung tính năng.

Trong ví dụ này, việc dự án bị kéo dài nên phía Đông bổ sung thêm yêu cầu (tích hợp cơ chế hoa hồng mới) nhưng không điều chỉnh deadline. Trong khi đó, đội ngũ triển khai khi có dư thời gian cũng chủ động đề xuất thêm các tính năng mới – như Bình đề xuất viết thêm đoạn code. Những thay đổi này, dù hợp lý ở từng thời điểm, lại khiến phạm vi dự án dần mở rộng ngoài kiểm soát.

Nguyên nhân số 5: Thời gian dự án kéo dài.
Nguồn: Brands Vietnam

Làm sao để kiểm soát (không phải loại bỏ)

Quản lý phạm vi dự án rõ ràng

Một phạm vi dự án rõ ràng và được quản lý tốt là nền tảng để hạn chế scope creep. Ngay từ đầu, người chịu trách nhiệm cần chủ động thiết lập một “thỏa thuận chung” thông qua project charter (tài liệu chính thức về dự án) để làm rõ mục tiêu kinh doanh, định hướng dự án và ranh giới những gì thuộc hoặc không thuộc scope. Trên cơ sở đó, scope cần được cụ thể hóa bằng việc phân tách thành các hạng mục công việc chi tiết (Work Breakdown Structure – WBS), tạo nền tảng cho quá trình phân tích yêu cầu.

Việc thu thập và làm rõ yêu cầu cũng cần được thực hiện có hệ thống, với đủ thời gian để đảm bảo đầy đủ và chính xác. Đồng thời, quản lý dự án phải liên tục cân đối giữa phạm vi và tiến độ — hoặc điều chỉnh deadline, hoặc kiểm soát lại scope. Công cụ trực quan như “Mô hình quy trình nghiệp vụ” (Business Process Models) có thể giúp các bên thống nhất cách hiểu, giảm thiểu rủi ro diễn giải sai ngay từ đầu.

Những mô hình quy trình nghiệp vụ phổ biến.
Nguồn: ProcessMaker

Quản lý thay đổi

Người quản lý dự án cần xây dựng một quy trình quản lý thay đổi (change management) như một phần của kế hoạch. Trong đó, mỗi dự án cần xác định cụ thể vai trò và trách nhiệm của từng bên khi đưa ra quyết định.

Nói đơn giản, quản lý phạm vi không phải là ngăn cản mọi thay đổi, mà là đảm bảo mọi yêu cầu mới đều được xem xét một cách có kiểm soát, thay vì được thêm vào một cách tùy tiện.

Ở phía triển khai, chỉ ghi nhận những yêu cầu đã được người có thẩm quyền phê duyệt. Đồng thời, cần áp dụng kỹ thuật truy vết yêu cầu (traceability), tức là mỗi yêu cầu phải được đối chiếu ngược lại với nhu cầu kinh doanh và theo dõi xuyên suốt. Một công cụ phổ biến được áp dụng là “Ma trận truy vết” (Traceability matrix).

Ví dụ về một Ma trận Truy vết.
Nguồn: Gurzu

Phân quyền trách nhiệm

Quản lý dự án cần “kéo” sự chú ý của những người có thẩm quyền vào dự án bằng các báo cáo tiến độ ngắn gọn, dễ hiểu, tập trung vào việc dự án đang tiến gần đến mục tiêu ra sao.

Có thể sử dụng “Ma trận Phân quyền trách nhiệm” (Responsible Accountable Consulted Informed – RACI) để làm rõ vai trò của từng bên trong dự án – ai thực hiện, ai chịu trách nhiệm cuối cùng, ai cần được hỏi ý kiến và ai cần được cập nhật.

Ngoài ra, cần xem việc stakeholder không tham gia đầy đủ là một rủi ro ngay từ đầu, và chuẩn bị sẵn phương án dự phòng cho tình huống này.

Ma trận Phân quyền trách nhiệm.
Nguồn: Monday.com

Chia dự án thành các phần nhỏ

Một cách hiệu quả để hạn chế scope creep là chia dự án thành các phần nhỏ, thay vì triển khai như một “khối” lớn kéo dài. Khi dự án được chia nhỏ, mỗi phần sẽ có mục tiêu rõ ràng và phạm vi chặt hơn, từ đó giảm khả năng bị mở rộng ngoài kiểm soát.

Khi từng giai đoạn hoặc phần việc hoàn thành, nên dừng lại để tổng kết: đã làm được gì, có vấn đề gì, cần điều chỉnh gì cho bước tiếp theo. Những bước này không chỉ giúp cải thiện chất lượng triển khai mà còn giữ được sự quan tâm và tham gia của người có thẩm quyền cũng như các bên liên quan trong suốt dự án.

★★★

Scope creep trong B2B gần như không thể loại bỏ hoàn toàn. Khi nhu cầu kinh doanh luôn thay đổi, việc dự án phải điều chỉnh theo là điều tất yếu. Vấn đề không nằm ở việc có thay đổi hay không, mà là ai đang kiểm soát những thay đổi đó. Vậy nên, chỉ có thể kiểm soát scope creep bằng cách quản lý chặt chẽ và hiệu quả để dự án không “trượt” khỏi quỹ đạo ban đầu.

Theo Sơn Phụng / Brands Vietnam
* Nguồn: Tổng hợp