Một khách hàng kết thúc buổi đánh giá trang web với một yêu cầu cuối cùng: “Trong khi các bạn đang làm việc đó, các bạn có thể thêm một trang đặt chỗ được không?” Yêu cầu này nghe có vẻ đơn giản, và nhóm đồng ý mà không cập nhật phạm vi dự án. Hai tuần sau, trang đặt chỗ đó cần tích hợp hệ thống thanh toán và đánh giá chính sách bảo mật, và công ty đã phải dành thêm một tuần cho công việc mà họ chưa từng tính đến.
Đó chính là cách hiện tượng mở rộng phạm vi dự án dần dần hình thành. Dự án dần dần mở rộng thông qua những yêu cầu tưởng chừng như nhỏ nhặt, trong khi ngân sách, dòng thời gian và nguồn lực ban đầu vẫn không thay đổi. Ngay cả những nhà quản lý dự án giàu kinh nghiệm cũng có thể bỏ sót những phần bổ sung này khi phạm vi đã thỏa thuận chỉ được ghi trong một tài liệu, trong khi công việc thực tế lại liên tục mở rộng ở những nơi khác.
Để ngăn chặn điều này, bạn cần có một phương pháp rõ ràng để xác định những gì được bao gồm trong dự án, đánh giá các yêu cầu mới và đảm bảo dự án luôn tuân thủ theo những gì đã được phê duyệt. Hướng dẫn này sẽ giúp bạn hiểu rõ các nguyên nhân gây ra hiện tượng mở rộng phạm vi dự án và bảy bước để quản lý nó trước khi nó ảnh hưởng đến thời hạn, ngân sách hoặc nhóm của bạn.
Tóm tắt
Sự mở rộng phạm vi xảy ra khi công việc vượt quá phạm vi đã thỏa thuận mà không có những điều chỉnh tương ứng trong kế hoạch dự án. Điều này có thể làm tăng chi phí, gây áp lực lên nguồn lực và ảnh hưởng đến tiến độ hoàn thành, ngay cả khi không có sản phẩm đầu ra mới nào xuất hiện trong Danh sách công việc.
Để kiểm soát tình trạng này:
- Đặt ra các ranh giới rõ ràng: Xác định những gì được bao gồm, những gì bị loại trừ và những gì được coi là công việc đã hoàn thành
- Ra quyết định dựa trên thông tin đầy đủ: Đánh giá tác động của các yêu cầu mới đối với các cam kết hiện có, bao gồm các phụ thuộc, chi phí và sức chứa sẵn có
- Theo dõi nỗ lực thực tế: So sánh công việc đã được phê duyệt với các công việc đang thực hiện và đã hoàn thành, bao gồm cả số giờ dành cho các hoạt động ngoài kế hoạch
Lưu ý: Ngay cả những yêu cầu mà cuối cùng bạn từ chối cũng có thể tiêu tốn thời gian dự án thông qua các cuộc thảo luận, kiểm tra tính khả thi và lập dự toán. Trước khi commit cho đánh giá tác động chi tiết, hãy kiểm tra xem yêu cầu đó có hỗ trợ mục tiêu dự án đã thống nhất hay không. Đối với những thay đổi phức tạp, hãy giới hạn nỗ lực đánh giá ban đầu và xin phê duyệt trước khi tiến hành bất kỳ cuộc điều tra sâu hơn nào.
Phạm vi dự án mở rộng là gì?
Sự mở rộng phạm vi là sự gia tăng không kiểm soát được của khối lượng công việc đã thỏa thuận trong dự án mà không có những thay đổi tương ứng về ngân sách, dòng thời gian hoặc nguồn lực. Theo Viện Quản lý Dự án (PMI), hiện tượng này có thể ảnh hưởng đến cả khối lượng công việc trong dự án lẫn sản phẩm cuối cùng được bàn giao.
Yếu tố then chốt là liệu công việc mới có được xem xét, phê duyệt và tính toán đầy đủ hay không. Việc thêm một sản phẩm đầu ra mới vào giữa chừng dự án là một sự thay đổi phạm vi. Để nhóm thực hiện công việc đó mà không đánh giá mức độ nỗ lực bổ sung hoặc điều chỉnh kế hoạch ban đầu chính là lúc hiện tượng mở rộng phạm vi bắt đầu.
Để xác định các nội dung bổ sung này, các nhóm cần có một cơ sở tham chiếu về phạm vi công việc đã được thống nhất. Cơ sở này xác định công việc đã được phê duyệt, bao gồm các sản phẩm đầu ra, tiêu chí chấp nhận và các nội dung loại trừ. Phạm vi công việc có thể ghi chép các ranh giới này, trong khi cấu trúc phân chia công việc (WBS) sắp xếp các sản phẩm đầu ra thành các gói công việc nhỏ hơn.
Sự mở rộng phạm vi so với thay đổi phạm vi đã được phê duyệt
Cả hai tình huống này đều có thể bắt nguồn từ yêu cầu mới của khách hàng hoặc đề xuất nội bộ. Điểm khác biệt nằm ở cách nhóm đánh giá và xử lý công việc được đề xuất.
| Thể loại | Sự mở rộng phạm vi | Thay đổi phạm vi đã được phê duyệt |
|---|---|---|
| Cách xử lý | Công việc bắt đầu mà không qua quá trình xem xét hoặc phê duyệt chính thức | Yêu cầu sẽ được đánh giá và phê duyệt trước khi bắt đầu công việc |
| Tác động đến nguồn lực | Các nỗ lực bổ sung được chấp nhận mà không có sự điều chỉnh đã được thống nhất | Đánh giá tác động đến chi phí, sức chứa và tiến độ |
| Ai là người phê duyệt? | Không có quyết định rõ ràng hoặc được ủy quyền | Chủ dự án, khách hàng hoặc nhà tài trợ được chỉ định |
| Cơ sở tham chiếu phạm vi | Phạm vi đã được phê duyệt và công việc thực tế dần trở nên không đồng bộ | Cơ sở tham chiếu và kế hoạch dự án được cập nhật |
| Kết quả | Chi phí phát sinh ngoài dự kiến, sự chậm trễ hoặc khối lượng công việc tăng thêm | Một sự thay đổi đã được thống nhất với những kỳ vọng rõ ràng và sự cân bằng giữa các yếu tố |
Sự mở rộng phạm vi so với việc làm quá mức cần thiết
"Gold plating" là một dạng của hiện tượng mở rộng phạm vi xảy ra khi nhóm tự ý thêm các cải tiến vượt quá các yêu cầu đã thỏa thuận mà không được yêu cầu. Ví dụ, một nhà thiết kế có thể thêm một hiệu ứng động phức tạp vào trang web, hoặc một nhà phát triển có thể xây dựng một tính năng bổ sung vì họ tin rằng điều đó sẽ cải thiện sản phẩm.
Mặc dù những thay đổi này có thể xuất phát từ ý định tốt, chúng vẫn tiêu tốn thời gian và nguồn lực mà ban đầu chưa được phê duyệt. Chúng cũng có thể dẫn đến các yêu cầu mới về kiểm thử, bảo trì hoặc rà soát.
Các biện pháp kiểm soát phạm vi tương tự cũng áp dụng trong trường hợp này. Trước khi thêm công việc mới, hãy kiểm tra xem công việc đó có nằm trong phạm vi các yêu cầu và tiêu chí chấp nhận đã được phê duyệt hay không. Nếu không, nhóm nên đề xuất đó là một thay đổi và phải được phê duyệt trước khi tiến hành.
Sự mở rộng phạm vi là tốt hay xấu?
Sự mở rộng phạm vi thường gây hại vì nó đưa vào những công việc mà dự án chưa tính đến. Tuy nhiên, các yêu cầu đằng sau đó có thể mang lại giá trị. Một tính năng mới có thể cải thiện sản phẩm, hoặc một sản phẩm đầu ra bổ sung có thể giúp khách hàng đạt được mục tiêu kinh doanh. Vấn đề nảy sinh khi các nhóm chấp nhận những bổ sung này mà không xem xét kỹ lưỡng tác động của chúng đối với công việc đang được triển khai.
Đối với các công ty dịch vụ, tác động của hiện tượng này thường thể hiện qua biên lợi nhuận. Giả sử một dự án có phí cố định được ước tính cần 100 giờ lao động nhưng cuối cùng lại mất 115 giờ. 15 giờ làm thêm đó không được tính phí, dẫn đến chi phí lao động tăng 15% nếu chi phí theo giờ không thay đổi. Đối với các nhóm nội bộ, chi phí này có thể không rõ ràng bằng, khi nhân viên phải phân chia thời gian giữa các ưu tiên cạnh tranh và các dự án khác bị chậm tiến độ.
Khi được xử lý thông qua một yêu cầu thay đổi chính thức, công việc bổ sung có thể trở thành một cơ hội đáng giá. Khách hàng có thể chấp thuận mức phí cao hơn, đồng ý với thời hạn mới hoặc thay thế sản phẩm hiện có bằng sản phẩm mới. Sau đó, nhóm có thể thích ứng với sự thay đổi này với những kỳ vọng rõ ràng về những gì cần thiết để hoàn thành công việc.
Nguyên nhân gây ra hiện tượng mở rộng phạm vi dự án là gì? 5 nguyên nhân phổ biến
Sự mở rộng phạm vi có thể bắt đầu ngay từ giai đoạn kế hoạch dự án hoặc phát sinh do tiến độ công việc. Dưới đây là năm nguyên nhân phổ biến và cách mỗi nguyên nhân có thể ảnh hưởng đến phạm vi đã thỏa thuận.
1. Yêu cầu dự án không rõ ràng
Một tài liệu phạm vi dự án hứa hẹn việc “thiết kế lại trang web” để lại rất nhiều khoảng trống cho việc diễn giải. Phạm vi này bao gồm 2 trang hay 10 trang? Ai sẽ cung cấp nội dung, và bao gồm bao nhiêu vòng chỉnh sửa?
Khi các yêu cầu dự án không làm rõ những chi tiết này, bạn và khách hàng có thể bắt đầu thực hiện công việc với những kỳ vọng khác nhau. Điều mà một bên coi là yêu cầu bổ sung, bên kia có thể cho rằng đã được bao gồm ngay từ đầu.
2. Các yêu cầu nhỏ không qua quy trình phê duyệt
Một kích thước băng rôn bổ sung, một vòng chỉnh sửa nữa, hoặc một thay đổi nhỏ về biểu mẫu có thể trông như không đáng kể khi được đề cập trong cuộc họp. Vì mỗi yêu cầu đều có vẻ nhỏ, nên rất dễ đồng ý và tiếp tục mà không ghi chép lại nỗ lực bổ sung đó.
Khi các yêu cầu này tích lũy dần, bạn sẽ phải quản lý công việc nhiều hơn so với kế hoạch ban đầu, mà không có hồ sơ rõ ràng về lượng thời gian đã tăng thêm hoặc ai là người đã phê duyệt việc đó.
3. Sự thay đổi trong các ưu tiên của các bên liên quan
Các bên liên quan mới có thể đưa ra những ưu tiên mâu thuẫn với nhau khi dự án đang ở giai đoạn giữa. Ví dụ, một giám đốc tiếp thị mới được bổ nhiệm muốn định vị lại một chiến dịch dành cho khách hàng doanh nghiệp, trong khi nhà tài trợ ban đầu vẫn mong đợi các tài sản đã được phê duyệt tại buổi khởi động dự án.
Nếu không có quyền quyết định rõ ràng, bạn có thể phải đối mặt với tình trạng phải cân bằng giữa các kỳ vọng mâu thuẫn. Bản đồ các bên liên quan của dự án sẽ làm rõ ai là người có ý kiến đóng góp định hướng công việc và ai có quyền quyết định cuối cùng khi ưu tiên thay đổi.
4. Các cải tiến chưa được phê duyệt từ nhóm
Bạn có thể tiếp tục hoàn thiện một sản phẩm đầu ra ngay cả khi nó đã đáp ứng đầy đủ các yêu cầu đã thỏa thuận. Điều này thường xảy ra khi các đợt đánh giá nội bộ không có điểm dừng rõ ràng, và mỗi ý tưởng hay cải tiến mới lại trở thành một công việc khác cần hoàn thành trước khi bàn giao.
Theo thời gian, những vòng hoàn thiện và thử nghiệm bổ sung này sẽ tiêu tốn thời gian vốn được phân bổ cho các công việc đã được phê duyệt. Dự án tiếp tục mở rộng, dù khách hàng chưa yêu cầu bất kỳ nội dung mới nào.
5. Việc theo dõi phạm vi dự án không hiệu quả trong quá trình triển khai
Một tài liệu phạm vi chi tiết có thể trở nên lỗi thời nếu bạn ngừng đối chiếu nó với tiến độ công việc. Ví dụ, một tính năng tích hợp mới được thêm vào danh sách công việc phát triển sau khi bàn giao kỹ thuật, và bạn lên lịch thực hiện mà không xác nhận xem nó có nằm trong phạm vi đã được phê duyệt hay không.
Nếu không thường xuyên so sánh giữa các sản phẩm đầu ra theo kế hoạch và các công việc đang thực hiện, khối lượng công việc phát sinh này sẽ dần hòa lẫn vào dự án. Sự chênh lệch này thường chỉ trở nên rõ ràng khi bạn rà soát ngân sách còn lại hoặc nhận ra tiến độ bàn giao đã bị chậm trễ.
Thông tin nhanh: Ngay cả khi có khả năng phán đoán kinh doanh sắc bén, cũng không thể đảm bảo rằng dự án sẽ luôn nằm trong phạm vi đã thỏa thuận. Trong báo cáo “Pulse of the Profession 2025” của PMI, các chuyên gia có tầm nhìn kinh doanh sắc bén cho biết họ tuân thủ ngân sách (73% so với 68%) và tiến độ (63% so với 59%) tốt hơn so với các đồng nghiệp. Tuy nhiên, báo cáo không tìm thấy sự khác biệt có ý nghĩa thống kê nào về hiện tượng mở rộng phạm vi giữa hai nhóm này.
Mặc dù nghiên cứu này không giải thích lý do tại sao hiện tượng này lại xảy ra, nhưng nó đã chỉ ra những giới hạn của việc chỉ dựa vào chuyên môn cá nhân. Các quy tắc rõ ràng về việc xem xét các yêu cầu, phê duyệt công việc bổ sung và cập nhật các cam kết của dự án sẽ giúp bạn có một phương pháp nhất quán hơn để quản lý các thay đổi.
Cách phòng ngừa và quản lý hiện tượng mở rộng phạm vi dự án vào năm 2026: 7 bước
Để ngăn chặn hiện tượng mở rộng phạm vi, hãy thống nhất về những gì dự án sẽ mang lại và cách xử lý các yêu cầu mới. Bảy bước sau đây sẽ giúp bạn quản lý các thay đổi, dù bạn đang theo dõi công việc qua bảng tính, tài liệu chia sẻ hay công cụ quản lý dự án.
Bước 1: Xác định những gì được bao gồm và không được bao gồm trong dự án
Ghi chép lại các sản phẩm đầu ra đã thống nhất, các yêu cầu của chúng và các tiêu chí bạn sẽ sử dụng để chấp nhận công việc. Đặt ra các giới hạn rõ ràng về việc sửa đổi và công việc bổ sung.
Hãy xác định rõ những nội dung nằm ngoài phạm vi dự án. Đối với một dự án thiết kế lại trang web gồm 12 trang, hãy làm rõ liệu thỏa thuận có bao gồm việc viết nội dung, chụp ảnh, tích hợp với các dịch vụ bên thứ ba và các trang bổ sung hay không. Như vậy, bạn sẽ có cơ sở tham chiếu rõ ràng khi ai đó yêu cầu thực hiện thêm công việc.
Đối với các dự án của khách hàng, hãy rà soát các chi tiết này trong quá trình tiếp nhận khách hàng và đạt được thỏa thuận bằng văn bản trước khi bắt đầu công việc. Đối với các dự án nội bộ, hãy soạn thảo một bản mô tả phạm vi công việc chi tiết và liên kết nó với bản tuyên bố dự án.
Hướng dẫn này sẽ chỉ cho bạn cách biến bản tóm tắt dự án chung chung thành các yêu cầu rõ ràng mà bạn có thể kiểm thử:
Bước 2: Chia phạm vi đã được phê duyệt thành các công việc có thể quản lý được
Tạo cấu trúc phân chia công việc (WBS) để chia các sản phẩm đầu ra đã thống nhất thành các gói công việc nhỏ hơn. Mẫu cấu trúc phân chia công việc có thể giúp bạn lập bản đồ công việc, ước tính nỗ lực và phân công người chịu trách nhiệm.
Sau đó, liên kết từng công việc dự án với sản phẩm đầu ra hoặc gói công việc tương ứng. Trong bảng tính, thêm cột “Sản phẩm đầu ra” để thể hiện cách mỗi công việc hỗ trợ phạm vi đã được phê duyệt. Trong công cụ quản lý dự án, sử dụng các công việc cha hoặc Trường Tùy chỉnh để thiết lập liên kết tương tự.
Hãy bao gồm các công việc như kiểm thử và điều phối dự án vào bản phân tích công việc chi tiết. Yêu cầu các bên liên quan phù hợp xem xét và phê duyệt bản cơ sở phạm vi đầy đủ. Sử dụng bản này để kiểm tra xem các công việc mới có thuộc phạm vi dự án hay không.
Bước 3: Xác định rõ quyền sở hữu đối với các quyết định về phạm vi dự án
Trước khi bắt đầu công việc, hãy xác định ai sẽ xem xét các yêu cầu thay đổi và ai có quyền phê duyệt chúng. Ví dụ, người quản lý dự án có thể đánh giá từng yêu cầu, trong khi khách hàng hoặc nhà tài trợ dự án sẽ phê duyệt các thay đổi liên quan đến chi phí, sản phẩm đầu ra hoặc thời hạn.
Nếu nhiều bộ phận chia sẻ công việc, hãy sử dụng ma trận RACI để xác định ai là người thực hiện công việc, ai chịu trách nhiệm về kết quả, ai cung cấp ý kiến đóng góp và ai cần được cập nhật thông tin.
Hãy ghi lại các vai trò này và chia sẻ với tất cả những người liên quan. Việc phân định rõ ràng quyền sở hữu giúp tránh các quyết định phê duyệt mâu thuẫn và chỉ ra cho các bên liên quan nơi cần gửi các yêu cầu mới.
Bước 4: Ghi lại các yêu cầu mới tại một nơi duy nhất
Chọn một nơi duy nhất để ghi lại các đề xuất thay đổi, chẳng hạn như biểu mẫu yêu cầu, sổ ghi chép chung hoặc danh sách công việc. Mỗi yêu cầu cần nêu rõ:
- Những gì người yêu cầu muốn thêm hoặc thay đổi
- Tại sao họ cần sự thay đổi
- Ai đã yêu cầu điều này?
- Các sản phẩm đầu ra nào bị ảnh hưởng
Khi ai đó đưa ra yêu cầu trong cuộc gọi hoặc cuộc trò chuyện không chính thức, hãy thử phản hồi như sau: “Tôi sẽ ghi nhận yêu cầu này và kiểm tra xem nó ảnh hưởng như thế nào đến dòng thời gian và ngân sách trước khi chúng ta đồng ý thực hiện công việc bổ sung.”
Việc này giúp ghi lại yêu cầu và cho bạn thời gian để đánh giá trước khi commit. Hãy sử dụng mẫu yêu cầu thay đổi tiêu chuẩn để thu thập các thông tin giống nhau mỗi lần.
Điều chỉnh quy trình cho phù hợp với sự thay đổi. Nếu việc điều chỉnh nằm trong phạm vi các yêu cầu đã thỏa thuận, hãy xử lý nó như một phần của phạm vi hiện có.
Bước 5: Đánh giá toàn bộ tác động trước khi phê duyệt các thay đổi
Trước khi chấp nhận một thay đổi, hãy ước tính khối lượng công việc phát sinh. Kiểm tra xem thay đổi đó sẽ ảnh hưởng như thế nào đến ngân sách, sức chứa của nhóm, các yếu tố phụ thuộc và thời hạn bàn giao.
Đừng chỉ nhìn vào công việc được nêu trong yêu cầu. Một tính năng mới trên trang web có thể chỉ mất vài giờ để phát triển. Tuy nhiên, nhóm có thể còn phải điều chỉnh thiết kế, thực hiện thêm các bài kiểm thử, cập nhật tài liệu và xin sự chấp thuận lại từ khách hàng.
Để xác định các chi phí phát sinh này, hãy đặt câu hỏi:
- Những công việc hoặc sản phẩm đầu ra hiện có nào sẽ cần phải điều chỉnh?
- Yêu cầu này có làm phát sinh các yếu tố phụ thuộc, nhu cầu kiểm thử hay cần sự phê duyệt từ bên thứ ba không?
- Liệu nhóm có thể hoàn thành công việc trong khung thời gian hiện tại mà vẫn đảm bảo thực hiện các cam kết khác không?
- Nếu bạn đang thay đổi các sản phẩm đầu ra, liệu công việc mới có đòi hỏi mức độ nỗ lực, rủi ro và thời gian đánh giá tương tự không?
Chia sẻ đánh giá của bạn với người có thẩm quyền phê duyệt thay đổi. Cung cấp cho họ các phương án rõ ràng:
- Phê duyệt công việc bổ sung và điều chỉnh ngân sách, dòng thời gian hoặc nhân sự
- Chuyển yêu cầu sang giai đoạn sau với kế hoạch triển khai riêng
- Thay thế một sản phẩm đầu ra hiện có nếu tác động tổng thể là chấp nhận được
- Từ chối hoặc hoãn yêu cầu nếu nó không hỗ trợ các ưu tiên của dự án
Ghi chép lại kết quả đánh giá và quyết định cuối cùng bằng văn bản. Việc truyền đạt thông tin rõ ràng cho các bên liên quan giúp mọi người hiểu rõ các thay đổi đã được phê duyệt và tác động của chúng đối với công việc còn lại.
Bước 6: Cập nhật cơ sở tham chiếu phạm vi sau khi được phê duyệt
Ngay sau khi người ra quyết định phê duyệt một thay đổi, hãy cập nhật các tài liệu dự án trước khi bắt đầu công việc bổ sung. Điều chỉnh bản mô tả phạm vi, WBS, danh sách công việc, ngân sách và lịch trình ở những phần bị ảnh hưởng bởi thay đổi đó.
Ví dụ, một sản phẩm đầu ra mới có thể cần có các gói công việc và công việc riêng. Chỉ định người chịu trách nhiệm, xác định tiêu chí chấp nhận và tính đến các phụ thuộc mới.
Hãy lưu giữ bản thỏa thuận ban đầu và hồ sơ của từng bản sửa đổi đã được phê duyệt. Điều này giúp bạn theo dõi các thay đổi và hỗ trợ các bên liên quan xác định các yêu cầu hiện tại.
Bước 7: Thường xuyên rà soát phạm vi dự án
Hàng tuần, hãy so sánh phạm vi đã được phê duyệt với công việc mà nhóm của bạn đang thực hiện. Kiểm tra danh sách công việc, nhật ký yêu cầu thay đổi và tiến độ so với các sản phẩm đầu ra theo kế hoạch. Đồng thời, hãy so sánh số giờ làm việc hoặc chi phí thực tế với các ước tính của bạn.
Hãy rà soát các công việc vừa hoàn thành, số giờ làm việc đã ghi nhận cũng như các công việc đang dang dở. Một thành viên trong nhóm có thể bắt đầu và hoàn thành một yêu cầu chưa được phê duyệt trong khoảng thời gian giữa các buổi rà soát hàng tuần. Công việc đó sẽ không còn xuất hiện trong danh sách công việc đang thực hiện của bạn, mặc dù nó đã tiêu tốn thời gian của dự án.
Tiếp theo, hãy tìm các công việc không liên quan đến các sản phẩm đầu ra đã được phê duyệt, các công việc đã bắt đầu trước khi được phê duyệt và các công việc đòi hỏi nhiều nỗ lực hơn so với kế hoạch. Hãy tìm hiểu nguyên nhân trước khi coi những trường hợp này là hiện tượng mở rộng phạm vi. Việc vượt quá phạm vi cũng có thể phản ánh việc ước tính không chính xác, độ phức tạp bất ngờ hoặc phải làm lại công việc.
Đối với các công ty quảng cáo, phần mềm theo dõi thời gian làm việc có thể giúp theo dõi các giờ làm việc có thể tính phí và không thể tính phí, đồng thời phát hiện sớm các nỗ lực phát sinh. Hãy cài đặt các ngưỡng để xem xét kỹ lưỡng hơn dựa trên ngân sách của bạn và mức độ chậm trễ mà dự án có thể chấp nhận được.
Hãy ghi chép ngắn gọn về từng vấn đề, nguyên nhân của nó và cách bạn đã giải quyết. Sử dụng các mô hình lặp lại để xác định những điểm cần cải thiện trong quy trình quản lý phạm vi của bạn.
Ví dụ về hiện tượng mở rộng phạm vi trong các dự án khác nhau
Sự mở rộng phạm vi có thể ảnh hưởng đến mọi khía cạnh, từ các sản phẩm giao cho khách hàng đến việc triển khai nội bộ. Các ví dụ sau đây minh họa cách các loại dự án khác nhau có thể vượt quá phạm vi ban đầu và việc cần làm để ngăn chặn những vấn đề tương tự.
1. Dự án của cơ quan: Công việc bổ sung ngoài các sản phẩm đầu ra đã thỏa thuận
Một công ty thiết kế ký hợp đồng để làm mới bộ nhận diện thương hiệu cho khách hàng, bao gồm logo mới, hướng dẫn thương hiệu và hai vòng chỉnh sửa. Giữa chừng dự án, khách hàng yêu cầu thêm các mẫu thiết kế cho mạng xã hội và bộ slide trình bày vào gói dịch vụ xây dựng thương hiệu.
Công ty đồng ý đưa các nội dung đó vào mà không cần xem xét lại hợp đồng. Tuy nhiên, những tài sản bổ sung này đòi hỏi các chu kỳ thiết kế, phản hồi và phê duyệt riêng, khiến thời gian dành cho các dự án khác của khách hàng bị giảm đi.
Cách xử lý: Xác định các tài sản bổ sung là các sản phẩm đầu ra riêng biệt và ước tính chi phí của chúng trước khi commit. Đề xuất chúng dưới dạng phần mở rộng có tính phí hoặc lên lịch thực hiện chúng cho giai đoạn sau, đồng thời hoàn thành gói thiết kế thương hiệu ban đầu đúng hạn.
2. Chiến dịch tiếp thị: Mở rộng sang các thị trường mới sau khi được phê duyệt
Việc ra mắt sản phẩm ban đầu được lập kế hoạch cho một thị trường, nhưng các bên liên quan đã quyết định mở rộng sang hai khu vực khác sau khi phê duyệt bản tóm tắt chiến dịch. Nhóm tiếp thị hiện cần các thông điệp được địa phương hóa, các tài sản sáng tạo bổ sung và các đánh giá phù hợp với từng thị trường.
Do ngày ra mắt và nguồn lực sẵn có vẫn không thay đổi, công việc phát sinh bắt đầu cạnh tranh với chiến dịch ban đầu. Quá trình phê duyệt nội dung sáng tạo mất nhiều thời gian hơn, và kế hoạch ra mắt có nguy cơ bị chậm tiến độ.
Cách xử lý: Giữ nguyên kế hoạch ra mắt ban đầu cho thị trường mục tiêu và đánh giá các khu vực bổ sung một cách riêng biệt. Việc triển khai theo từng giai đoạn cho phép bạn tính đến các yếu tố như bản địa hóa, các thủ tục phê duyệt theo khu vực và nhu cầu về nguồn lực mà không làm gián đoạn các cam kết hiện có.
3. Phát triển phần mềm: Thêm yêu cầu mới giữa chừng sprint
Một nhóm phát triển cam kết hoàn thành tính năng tìm kiếm trong một sprint. Đến giữa chặng đường, các bên liên quan yêu cầu thêm chức năng phân tích và đề nghị các nhà phát triển tích hợp tính năng này vào cùng một sprint.
Các nhà phát triển bắt đầu triển khai các yêu cầu mới mà không đánh giá tác động của chúng đối với Mục tiêu Sprint. Khi sức chứa được chuyển hướng sang các tính năng bổ sung, việc kiểm thử và hoàn thành công việc ban đầu bị chậm trễ.
Cách xử lý: Yêu cầu Product Owner đánh giá các yêu cầu mới và sắp xếp thứ tự ưu tiên của chúng trong Product Backlog. Nếu một yêu cầu thực sự cần được xử lý trong sprint hiện tại, các nhà phát triển và Product Owner có thể đàm phán lại Sprint Backlog trong khi vẫn đảm bảo đạt được mục tiêu sprint.
4. Dự án nội bộ: Mở rộng phạm vi triển khai mà không cần thêm nguồn lực
Văn phòng Quản lý Dự án (PMO) nội bộ có kế hoạch triển khai một công cụ quản lý công việc mới cho bộ phận bán hàng. Sau buổi trình diễn ban đầu, các bộ phận tài chính và nhân sự đã yêu cầu được truy cập trước khi giai đoạn thử nghiệm hoàn thành.
Việc mở rộng triển khai mang lại những yêu cầu về quyền truy cập, nhu cầu đào tạo và khối lượng công việc hỗ trợ khác nhau. Nếu không có thêm sức chứa triển khai, bộ phận ban đầu sẽ nhận được ít sự quan tâm hơn, và việc áp dụng bắt đầu gặp khó khăn.
Cách xử lý: Hoàn thành và đánh giá giai đoạn triển khai ban đầu trước khi mở rộng sang các bộ phận khác. Sử dụng kết quả từ giai đoạn thử nghiệm để ước tính khối lượng công việc đào tạo, nhu cầu cấu hình và sức chứa hỗ trợ cho từng giai đoạn mới. Điều này sẽ giúp bạn có cơ sở rõ ràng hơn để phê duyệt việc triển khai trên quy mô lớn hơn và đặt ra các mốc thời gian thực tế.
Ví dụ thực tế: Một dự án CNTT của chính phủ kéo dài gần bốn năm
Một nghiên cứu điển hình của PMI năm 2004 mô tả dự án số hóa tài liệu của một cơ quan liên bang Hoa Kỳ nhằm xử lý các yêu cầu thông tin công khai. Dự án này có thời gian thực hiện dự kiến từ 18 đến 24 tháng và ngân sách khoảng 10 triệu đô la.
Tuy nhiên, một nghiên cứu điển hình của PMI cho thấy dự án này có sự tham gia của khoảng 50 đại diện người dùng, những người gặp khó khăn trong việc thống nhất các yêu cầu. Khi tiến độ phát triển tăng lên, các nhóm khác nhau đã yêu cầu thay đổi các sản phẩm đầu ra hiện có, đôi khi là vài tuần sau khi đã gửi các phiên bản trước đó.
Do thiếu quyền quyết định rõ ràng, các yêu cầu này liên tục được đưa vào quá trình phát triển. Các tài liệu phải trải qua nhiều lần sửa đổi, các yêu cầu trở nên khó quản lý hơn, và công việc đã hoàn thành lại cần phải điều chỉnh thêm.
Dự án ban đầu có kế hoạch thực hiện trong vòng 18 đến 24 tháng nhưng cuối cùng lại kéo dài gần bốn năm.
Điểm chính: Ngay cả các yêu cầu đã được ghi chép rõ ràng cũng không thể ngăn chặn hiện tượng mở rộng phạm vi nếu các bên liên quan liên tục xem xét lại các quyết định mà không có cơ chế phê duyệt rõ ràng. Việc xác định rõ ai có quyền quyết định cuối cùng, thời điểm đóng góp ý kiến kết thúc và cách các thay đổi ảnh hưởng đến kế hoạch dự án có thể ngăn chặn việc sửa đổi lặp đi lặp lại làm chệch hướng tiến độ triển khai.
Phương pháp Agile có ngăn chặn được hiện tượng mở rộng phạm vi không?
Phương pháp Agile giúp bạn đáp ứng các yêu cầu thay đổi, nhưng không tự động ngăn chặn hiện tượng mở rộng phạm vi. Trong Scrum, Danh sách công việc sản phẩm (Product Backlog) phát triển khi bạn tìm hiểu thêm về nhu cầu của người dùng, nhận phản hồi và điều chỉnh các ưu tiên. Chủ sở hữu sản phẩm (Product Owner) quản lý những thay đổi này, đảm bảo công việc luôn phù hợp với Mục tiêu sản phẩm.
Rủi ro này xuất hiện khi các mục mới trong danh sách công việc (backlog) trở thành cam kết giao hàng mà không xem xét kỹ lưỡng xem dự án có thể đáp ứng được những gì một cách thực tế. Ví dụ, việc thêm một bản ghi kiểm tra (audit trail) vào Danh sách công việc sản phẩm (Product Backlog) sau khi thử nghiệm người dùng là một phản hồi hợp lý đối với phản hồi từ người dùng. Tuy nhiên, việc hứa hẹn sẽ đưa tính năng này vào bản phát hành sắp tới, cùng với tất cả các tính năng đã được lập kế hoạch ban đầu và trong cùng một thời hạn, có thể dẫn đến hiện tượng mở rộng phạm vi dự án.
Để quản lý vấn đề này, hãy phân biệt rõ những gì bạn đang xem xét cho sản phẩm với những gì bạn đã cam kết cung cấp. Khi các yêu cầu mới trở thành ưu tiên, hãy rà soát dự báo phát hành và quyết định xem các tính năng hiện có có cần được điều chỉnh, ngày giao hàng có cần thay đổi hay việc bổ sung nguồn lực có hợp lý hay không.
Hướng dẫn Scrum hỗ trợ tính linh hoạt này thông qua việc liên tục tinh chỉnh và sắp xếp thứ tự ưu tiên của danh sách công việc tồn đọng. Bạn có thể tiếp tục điều chỉnh sản phẩm trong khi vẫn duy trì những kỳ vọng rõ ràng về những gì mỗi bản phát hành sẽ mang lại.
Những sai lầm thường gặp khi đối phó với hiện tượng mở rộng phạm vi (và việc cần làm thay thế)
Một cơ sở phạm vi rõ ràng và quy trình phê duyệt thay đổi sẽ giúp bạn quản lý các yêu cầu mới. Tuy nhiên, phạm vi dự án vẫn có thể mở rộng do phản hồi từ quá trình đánh giá, việc sử dụng quỹ dự phòng của dự án và giờ làm thêm không được theo dõi. Hãy lưu ý ba sai lầm sau đây:
1. Để các tiêu chí chấp nhận thay đổi trong quá trình đánh giá
Một sản phẩm đầu ra có thể đáp ứng mọi yêu cầu đã thỏa thuận nhưng vẫn có thể dẫn đến các yêu cầu công việc bổ sung. Ví dụ: bạn trình bày một bảng điều khiển với các chỉ số đã được phê duyệt. Trong buổi đánh giá cuối cùng, các bên liên quan yêu cầu thêm các tính toán và tùy chọn báo cáo trước khi họ chấp thuận.
Nếu bạn coi những nội dung bổ sung đó là các yêu cầu cần được phê duyệt, bạn sẽ thay đổi định nghĩa về việc hoàn thành dự án. Kế hoạch dự án có thể vẫn hiển thị cùng một sản phẩm đầu ra, ngay cả khi công việc ngày càng tăng.
Việc cần làm: So sánh phản hồi từ các vòng đánh giá với các tiêu chí chấp nhận đã thống nhất. Sửa chữa bất kỳ nội dung nào chưa đáp ứng các yêu cầu đó. Đánh giá các yêu cầu về tính năng mới thông qua quy trình phê duyệt thay đổi của bạn. Ghi chép lại những gì các bên liên quan chấp nhận và thời điểm chấp nhận, đặc biệt khi một sản phẩm đầu ra phải trải qua nhiều vòng đánh giá.
2. Coi thời gian dự phòng như sức chứa dự trữ
Bạn dành ra một khoản thời gian hoặc ngân sách dự phòng để đối phó với các rủi ro của dự án, chẳng hạn như các vấn đề kỹ thuật hoặc sự chậm trễ trong việc phê duyệt từ bên ngoài. Nếu vài tuần đầu tiên diễn ra suôn sẻ, bạn có thể bắt đầu sử dụng khoản dự phòng đó để đáp ứng các yêu cầu mới.
Khi đó, rủi ro sẽ trở thành một vấn đề thực sự, và thời gian hoặc ngân sách bạn cần đã bị tiêu tốn vào những công việc phát sinh.
Việc cần làm: Xác định rõ quỹ dự phòng bao gồm những gì và ai có quyền phê duyệt việc sử dụng quỹ này. Một số dự án cho phép nhóm sử dụng quỹ dự phòng cho những thay đổi nhỏ đã được phê duyệt. Ngay cả trong trường hợp đó, hãy kiểm tra từng yêu cầu trước khi sử dụng quỹ dự phòng. Theo dõi số dư còn lại và xem liệu bạn có đủ quỹ để đối phó với các rủi ro đã xác định hay không.
3. Giải quyết công việc dư thừa thông qua làm thêm giờ
Một dự án vẫn có thể tiến hành đúng tiến độ ngay cả khi phạm vi dự án mở rộng. Các thành viên trong nhóm có thể phải làm việc thêm giờ để xử lý các yêu cầu bổ sung và không ghi nhận nỗ lực đó vào hồ sơ dự án.
Bạn hoàn thành đúng hạn, nhưng công việc lại tốn nhiều thời gian hơn kế hoạch. Nếu bạn dùng dự án đó để ước tính công việc trong tương lai, bạn có thể sẽ đặt ra các mốc thời hạn phụ thuộc vào chính số giờ làm thêm đó.
Việc cần làm: Theo dõi toàn bộ thời gian dành cho dự án, bao gồm cả giờ làm thêm và công việc ngoài khung giờ đã có kế hoạch. So sánh số giờ thực tế với ước tính ban đầu và điều tra các chênh lệch lặp lại. Điều này giúp bạn phát hiện các công việc ngoài kế hoạch trước khi thời hạn bị trễ và cung cấp cơ sở vững chắc cho việc lập kế hoạch sức chứa trong tương lai.
Cách ClickUp giúp bạn kiểm soát hiện tượng mở rộng phạm vi dự án
Một thay đổi đã được phê duyệt chỉ thực sự hữu ích khi nhóm làm việc dựa trên các yêu cầu mới nhất. Điều đó có nghĩa là cần đảm bảo kết nối giữa quyết định, các công việc bị ảnh hưởng và nhu cầu về nguồn lực, để mọi người đều rõ mình cần hoàn thành những gì.
ClickUp tích hợp các khía cạnh này của quản lý phạm vi vào một không gian làm việc duy nhất. Bạn có thể theo dõi các yêu cầu mới, giám sát công việc đã được phê duyệt và phát hiện các dấu hiệu cho thấy dự án cần thêm thời gian hoặc ngân sách.
Hãy bắt đầu với Mẫu Yêu cầu Thay đổi của ClickUp. Mẫu này bao gồm Biểu mẫu Yêu cầu Thay đổi, Trường Tùy chỉnh Tác động đến phạm vi và các trạng thái như Yêu cầu mới, Đang xem xét và Chuẩn bị triển khai. Mỗi lần gửi biểu mẫu sẽ tạo ra một công việc. Giao công việc đó cho người xem xét và đang theo dõi quá trình phê duyệt.
Sau đó, kết nối từng yêu cầu với công việc mà nó ảnh hưởng đến:
- Kiểm tra yêu cầu so với phạm vi đã được phê duyệt. Sử dụng ClickUp Docs để ghi lại các sản phẩm đầu ra, các nội dung không bao gồm và tiêu chí chấp nhận. Liên kết tài liệu phạm vi với công việc yêu cầu để người đánh giá có thể xác định liệu công việc đó đã được bao gồm hay cần được phê duyệt riêng biệt.
- Xác định các công việc sẽ bị ảnh hưởng bởi thay đổi. Sử dụng tính năng "Mối quan hệ" (Relationships) trong Nhiệm vụ ClickUp để liên kết yêu cầu với các công việc triển khai bị ảnh hưởng. Ghi lại tác động đến phạm vi dự án trong các Trường Tùy chỉnh (Custom Fields) và thêm ước lượng thời gian cho các công việc triển khai, kiểm thử và đánh giá.
- Kiểm tra sức chứa trước khi cam kết. Sử dụng chế độ xem Khối lượng công việc kèm theo ngày thực hiện công việc, ước lượng thời gian và sức chứa đã được cấu hình để đánh giá xem nhóm có thể đáp ứng sự thay đổi đó hay không. Dựa trên đánh giá đó, đề xuất điều chỉnh phân công công việc, thời hạn hoặc giai đoạn bàn giao muộn hơn.
- Chuyển yêu cầu để xem xét và ghi lại quyết định. Cấu hình tự động hóa ClickUp để chỉ định người xem xét hoặc thông báo cho chủ sở hữu phạm vi khi có yêu cầu cần được xử lý. Yêu cầu người phê duyệt có thẩm quyền ghi lại quyết định cùng bất kỳ thay đổi nào về chi phí hoặc tiến độ đã được thống nhất. Tách biệt các yêu cầu bị từ chối hoặc hoãn lại khỏi công việc triển khai đã được phê duyệt
- Cập nhật kế hoạch và theo dõi nỗ lực thực tế. Sau khi được phê duyệt, hãy điều chỉnh tài liệu phạm vi, các công việc bị ảnh hưởng, ngân sách và lịch trình, sau đó chuyển yêu cầu sang trạng thái "Đang triển khai". Trong Bảng điều khiển ClickUp, bật tùy chọn "Hiển thị ước lượng thời gian" trong thẻ "Báo cáo thời gian" để so sánh số giờ ước tính và số giờ đã theo dõi cho các công việc có mục nhập thời gian. Điều tra các trường hợp vượt quá thời gian trước khi coi đó là sự mở rộng phạm vi thêm.
Đánh giá yêu cầu thay đổi với ClickUp Brain²
Sử dụng ClickUp Brain² để xem xét đề xuất thay đổi cùng với phạm vi đã được phê duyệt và các hồ sơ công việc liên quan. Ví dụ, hãy hỏi: “So sánh yêu cầu về bộ tài liệu trình bày này với phạm vi thương hiệu đã được phê duyệt. Xác định bất kỳ sản phẩm đầu ra bổ sung, vòng sửa đổi hoặc phê duyệt nào, và trích dẫn các hồ sơ bạn đã sử dụng.”
Hãy xem xét lại bản so sánh trước khi chia sẻ với khách hàng. Yêu cầu Brain² tóm tắt các thay đổi được đề xuất, các ước tính đã ghi nhận, các cam kết bị ảnh hưởng và các câu hỏi vẫn cần được giải đáp. Yêu cầu nhóm triển khai xác nhận nỗ lực và các mối phụ thuộc, sau đó cung cấp cho người phê duyệt có thẩm quyền thông tin cần thiết để chấp nhận, hoãn lại hoặc từ chối yêu cầu.
Xem xét sự mở rộng phạm vi và các rủi ro trong quá trình triển khai cùng các Chuyên gia Hỗ trợ ClickUp
Để giám sát chặt chẽ hơn, hai Chuyên viên Hỗ trợ Cao cấp của ClickUp có thể giúp bạn phát hiện các dấu hiệu tiềm ẩn của hiện tượng mở rộng phạm vi và hiểu rõ hậu quả của nó:
- Công cụ phát hiện sự mở rộng phạm vi (Scope Creep Detector Agent): So sánh công việc hiện tại với cơ sở tham chiếu ban đầu của dự án hoặc sprint. Công cụ này đánh dấu các công việc mới, yêu cầu mở rộng và sản phẩm đầu ra đã thay đổi, đồng thời đo lường mức độ mở rộng phạm vi kể từ khi lập kế hoạch. Trạng thái phê duyệt nhất quán hoặc các Trường Tùy chỉnh có thể giúp công cụ này phân biệt các thay đổi đã được phê duyệt với các nội dung bổ sung cần xem xét
- Trình phân tích đánh giá rủi ro: Kiểm tra các mốc thời gian, phân bổ nguồn lực và mối quan hệ phụ thuộc giữa các công việc để xác định rủi ro liên quan đến việc bàn giao. Ví dụ, công việc tăng thêm có thể khiến một nhà phát triển bị quá tải hoặc đe dọa đến một cột mốc quan trọng phụ thuộc vào công việc đó. Trình phân tích này có thể đánh dấu vấn đề và đề xuất các biện pháp khắc phục dựa trên mức độ nghiêm trọng của vấn đề.
Cấu hình quyền truy cập cho từng thành viên trong nhóm để họ có thể truy cập vào bản cơ sở liên quan, hồ sơ công việc và các quyết định phê duyệt, đồng thời yêu cầu người chịu trách nhiệm về phạm vi dự án xem xét các kết quả này.
Phù hợp nhất với: Các cơ quan và nhóm đa chức năng thường xuyên phải xử lý các yêu cầu thay đổi, các sản phẩm đầu ra được chia sẻ và ngân sách dự án.
Bỏ qua phần này nếu: Bạn đang thực hiện một dự án nhỏ, ngắn hạn với ít bên liên quan và có thể duy trì một bản ghi thay đổi đáng tin cậy trong bảng tính.
Đừng để sự mở rộng phạm vi trở thành một chi phí ẩn
Một dự án có thể hoàn thành đúng hạn, làm hài lòng khách hàng, nhưng vẫn phải đối mặt với hiện tượng mở rộng phạm vi. Nhóm có thể đã giải quyết khối lượng công việc phát sinh thông qua làm thêm giờ, quỹ dự phòng hoặc mượn thời gian từ một dự án khác. Trên giấy tờ, mọi thứ trông đều ổn. Nhưng nỗ lực thực tế để hoàn thành dự án lại kể một câu chuyện khác.
Quản lý hiện tượng mở rộng phạm vi có nghĩa là nhận diện những sự đánh đổi này khi bạn vẫn còn dư địa để thương lượng. Bạn có thể đáp ứng một yêu cầu mới, điều chỉnh cam kết hiện có, hoặc hoãn công việc đó sang giai đoạn sau. Điều quan trọng là phải đưa ra quyết định đó trước khi ai đó đã dành hàng giờ cho công việc đó.
Khi dự án mở rộng, ClickUp giúp các quyết định đó luôn được hiển thị rõ ràng bên cạnh các công việc bị ảnh hưởng. Hãy bắt đầu với Mẫu Yêu cầu Thay đổi để đảm bảo mọi cam kết mới đều được xem xét kỹ lưỡng và có trách nhiệm. Từ đó, hãy sử dụng Không gian Làm việc ClickUp rộng hơn để lập kế hoạch công việc, phối hợp chuyển giao và theo dõi tiến độ thực hiện khi yêu cầu dự án thay đổi.
Các câu hỏi thường gặp về hiện tượng mở rộng phạm vi
Có từ nào khác để chỉ hiện tượng mở rộng phạm vi không?
Các thuật ngữ đồng nghĩa phổ biến bao gồm: "sự mở rộng yêu cầu", "hội chứng 'tất cả mọi thứ'", "sự mở rộng nhiệm vụ" và "sự mở rộng tính năng". Thuật ngữ "sự mở rộng nhiệm vụ" chủ yếu được sử dụng trong các dự án của chính phủ và quân sự, còn "sự mở rộng tính năng" thường áp dụng cho các sản phẩm phần mềm. "Sự mở rộng tính năng" có phạm vi hẹp hơn, vì nó chỉ liên quan đến các tính năng của sản phẩm, trong khi "sự mở rộng phạm vi" bao quát toàn bộ dự án.
Làm thế nào để từ chối yêu cầu mở rộng phạm vi dự án từ phía khách hàng?
Giải thích phần nào của yêu cầu nằm ngoài phạm vi đã thỏa thuận. Nếu khả thi, hãy ước lượng thời gian và chi phí cho phần đó, sau đó đề xuất các phương án: bổ sung phần đó với điều chỉnh ngân sách và tiến độ đã được thống nhất, chuyển sang giai đoạn sau, hoặc thay thế bằng công việc có mức độ nỗ lực và rủi ro tương đương. Nếu yêu cầu đó có thể ảnh hưởng đến các cam kết hiện tại, hãy giải thích lý do tại sao bạn không thể đáp ứng yêu cầu đó.
Làm thế nào để khôi phục một dự án đã bị mở rộng phạm vi?
Bắt đầu bằng việc rà soát công việc còn lại so với phạm vi đã được phê duyệt gần nhất. Xác định các nội dung bổ sung chưa được phê duyệt, ước tính nỗ lực cần thiết để hoàn thành, và quyết định những phần nào cần hoãn lại hoặc loại bỏ. Sau đó, thống nhất với người tài trợ dự án về một kế hoạch khắc phục, bao gồm bất kỳ thay đổi nào về ngân sách, nguồn lực hoặc thời hạn.
Làm thế nào để bạn quyết định liệu một thay đổi phạm vi có đáng để chấp nhận hay không?
Hãy dành chút thời gian để cân nhắc giữa lợi ích dự kiến với chi phí, nỗ lực và rủi ro phát sinh. So sánh yêu cầu đó với các phương án khác, chẳng hạn như hoãn lại hoặc thay thế một sản phẩm đầu ra hiện có. Nếu sự thay đổi này hỗ trợ mục tiêu của dự án mà không làm ảnh hưởng đến công việc có mức độ ưu tiên cao hơn, thì đây có thể là một phương án đáng xem xét.
Liệu mọi trường hợp vượt ngân sách đều đồng nghĩa với hiện tượng mở rộng phạm vi dự án?
Không. Một dự án có thể vượt quá ngân sách mà không cần phải thêm công việc. Chi phí nhân công tăng cao, ước tính không chính xác và việc phải làm lại do những yếu tố bất ngờ đều có thể gây ra tình trạng vượt ngân sách. Hiện tượng mở rộng phạm vi xảy ra khi phạm vi công việc đã thỏa thuận được mở rộng mà không có sự phê duyệt hoặc điều chỉnh thích hợp. Hãy kiểm tra cơ sở tham chiếu phạm vi trước khi kết luận rằng các yêu cầu bổ sung là nguyên nhân dẫn đến sự gia tăng chi phí.