Các ràng buộc thì dễ xác định hơn các giả định, vì chúng thường được áp đặt rõ ràng bởi các cấp quản lý hoặc nhà tài trợ. Các ràng buộc hạn chế lựa chọn trong quá trình lập kế hoạch và hơn thế nữa. Giám đốc dự án phải xử lý nhiều thứ trong dự án, bao gồm các ràng buộc của dự án như tiến độ, chi phí, rủi ro, phạm vi, chất lượng, nguồn lực, sự hài lòng của khách hàng và bất kỳ yếu tố nào khác làm hạn chế các lựa chọn.
Ràng buộc là những giới hạn mà dự án phải chịu đựng, khác với Assumption là có thể xảy ra hay không, Constraints là đã xảy ra và bắt buộc mọi yếu tố khác xoay quanh nó.
Constraint (ràng buộc) là một trong những yếu tố thường xuất hiện trong dự án. Với chức năng “ràng buộc”, nó sẽ giúp việc thực hiện dự án được diễn ra đúng quy trình, đảm bảo tiến độ, ngân sách, chất lượng, hạn chế ảnh hưởng đến việc thực hiện dự án, quy trình hay danh mục.
Chú ý: Ràng buộc về mặt nghiệp vụ hệ thống (business constraint) khác với các quy tắc nghiệp vụ (business rule). Xem thêm: What is the difference between a business rule and business constraint?
Các ví dụ của ràng buộc như:
- Phải sử dụng công nghệ XYZ trong dự án này,
- Đội nhóm dự án phải cần có sự tham gia của chuyên gia A,
- Ngày cột mốc bàn giao một giao phẩm là 1/1/2020,
- Ngày mà dự án phải được hoàn thành là 2/2/2020,
- Mức độ rủi ro tối đa cho phép ở mức ZZZ,
- Ngân sách dự án được giao là 100 tỷ VNĐ,…
Một số ràng buộc phổ biến là thời gian, chi phí, nguồn lực và PM phải làm việc trong phạm vi giới hạn đó. Contraint phải được "define" khi bắt đầu dự án.
Xét về mặt kỹ thuật, có 6 loại constraints trong dự án:
- Scope
- Schedule (Time)
- Quality
- Budget (Cost)
- Resource
- Risk
Bộ 3 Scope, Schedule, Budget gọi là Triple Constraints
Xét về mặt quản trị, constraint có 2 loại:
- Business Constraints: Điều này phụ thuộc tình trạng của DN bạn, ví dụ thời gian, ngân sách hay Budget…
- Technical Constraints: Đây là những ràng buộc khiến giới hạn những lựa chọn thiết kế của bạn. Ví dụ: Dự án cần phải hoàn thành 25% công việc trong 30 ngày đầu, Dự án chỉ cho phép 2 kỹ sư tại site, Dự án yêu cầu ngày nào cũng phải có kỹ sư onsite.
Khác biệt căn bản giữa constraint và assumption:
- Đối với assumption bạn cần phân tích (Be Analyzed).
- Đối với constraint bạn cần định nghĩa rõ (Be Identified).
PM cần phân tích nếu assumption sai hay các ràng buộc vi phạm. Nếu PM quản lý tốt các Assumption và Constraint sẽ giúp hoàn thành dự án đúng kế hoạch mà vẫn thỏa các mong đợi của các bên liên quan (stakeholders).
Những ràng buộc có thể là một thách thức để quản lý
Các cấp quản lý trực tiếp hoặc gián tiếp đặt mức độ ưu tiên của từng ràng buộc. Ưu tiên này sau đó được sử dụng để lập kế hoạch dự án, đánh giá tác động của những thay đổi và chứng minh dự án sẽ hoàn thành thành công. Điều quan trọng là đánh giá hệ quả của việc thay đổi một ràng buộc này đối với tất cả các ràng buộc khác. Nói cách khác, bạn hầu như không thể rút ngắn tiến độ dự án mà không gây ra tác động tiêu cực đến chi phí, rủi ro, v.v. Điều này có tác dụng trong việc lập kế hoạch và khi người giám đốc dự án xử lý các yêu cầu thay đổi. Thí dụ: một hoạt động bổ sung có thể chỉ mất một ngày, nhưng chi phí cho việc thêm hoạt động này phải được đánh giá, cùng với tác động đến đường cơ sở (đường găng - Critical Path). Rủi ro thêm hoặc từ chối hoạt động được yêu cầu cũng phải được đánh giá. Thay đổi kế hoạch dự án thường tác động đến nhiều ràng buộc. Người giám đốc dự án và nhóm có thể đánh giá chúng, nhưng các yêu cầu thay đổi tác động đến các phần đã được phê duyệt của kế hoạch quản lý dự án phải thông qua kiểm soát thay đổi tích hợp.
Đến đây hy vọng bạn đã hiểu Constraint và vị trí của chúng trong QLDA. Trong khi Assumption là những gì bạn nghĩ sẽ đúng trong tương lai nhưng cũng không có gì đảm bảo là chắc chắn và Constraint là những gì giới hạn bởi dự án mà PM thực hiện.
St
