Assumptions và Constraints là 2 khái niệm luôn đi liền và ảnh hưởng nhau. Tóm lại một key word ngắn nhất để nói mối quan hệ giữa chúng là: Assumptions is bounded by Constraints
Điều này có nghĩa là những giả định luôn được giới hạn bởi ràng buộc. Đây là những điều luôn trải qua trong thực tế.
Tôi lấy một ví dụ đơn giản để chúng ta hiểu rõ hơn về Assumption và Constraint. Ví dụ tôi muốn đi siêu thị mua đồ, siêu thị này ở rất xa tôi. Để đi đến đó tôi phải dùng xe máy và đi hết 1 giờ.
Bạn lúc này chưa đi, giả định bây giờ là 6am, bạn đi thì tới 7am bạn sẽ tới. => Đây là Assumption.
Vậy cái gì là điều kiện ràng buộc hay là Constraint?
Thoáng qua bạn có thể thấy 2 cái, thứ nhất giả dụ bạn chỉ có 100K thì bạn chỉ có thể mua trong giới hạn 100K, thứ 2 là lưu ý giờ mở cửa, đóng cửa của siêu thị. Giả sử siêu thị này mở cửa lúc 8am, đóng cửa lúc 10pm thì các Assumption của bạn phải nằm trong từ 8am-10pm. Việc giả sử quá nhiều assumption ko nằm trong Constrain thì chứng tỏ năng lực PM của bạn “quá siêu”
Bạn nghĩ gì về dự án có thời gian constraint là 3 tháng, mà bạn cứ giả sử Assumption dự án làm 6 tháng? điều này ý nghĩa?
Kết luận tổng quan lại là Assumption bị giới hạn bởi Constraint. Khi vào một dự án bạn cần xem nó có constraint gì? về thời gian, chi phí, resource….
Một dự án có rất nhiều Assumption và Constraint, bạn muốn dự án thành công thì bạn phải nắm nó thật chắc. Một PM có 2 mắt thì 1 mắt luôn phải để ý đến Assumption & Constraint.
Assumption & Constraint được định nghĩa qua Project Life Cycle. Những tham số này rất quan trọng trong quy trình Planning, trong đó tài liệu Risk Management Plan có rất nhiều Assumption. Nếu PM phân tích sai chúng, điều này có thể ảnh hưởng đầu ra của dự án.
Bạn có thể tìm thấy Assumption và Constraint trong Project Scope Statement.
Chúng ta hãy cùng nhau xem từng khái niệm 1 (one by one)
Assumptions
Giả định là một lòng tin của PM tin rằng một sự kiện gì sẽ xảy ra trong tương lai. Một giả định được giả định là đúng, nhưng thực tế nó ko nhất thiết phải xảy ra đúng. Đôi khi nó không xảy ra và ảnh hưởng độ tin cậy dự án. PM cho risk vào dự án vì các giả định có thể xảy ra hay không xảy ra.
Hãy trở về ví dụ tôi đi siêu thị ở trên, tôi đã giả định đi lúc 6am, nhưng tôi chưa quan tâm đến kẹt xe, và tôi có thể đến trễ hơn, bản kế hoạch mua sắm của tôi sẽ bị trễ dây chuyền, điều này xem như giả định của tôi bị sai. Đáng nhẽ tôi phải giả định có kẹt xe thì 7h30 tôi mới đến được siêu thị. Giả định này có xảy ra thì tôi cũng đến như hoạch định, giả định này ko xảy ra thì tôi cũng sẽ đến sớm.
Điều này hoàn toàn có thể khó khăn khi bạn làm dự án, bạn giả định có một công cụ cho bạn thực hiện dự án trong giai đoạn nào đó, nhưng đến khi đó lại ko có. Và bạn bị chìm đắm trong tình huống khó khăn này.
Assumption đóng vai trò cực kỳ quan trọng trong xây dựng Risk Management Plan. Vì thế PM cần thu thập càng nhiều Assumption càng tốt.
Dưới đây là một số ví dụ về assumptions:
- PM có thể lấy tất cả tài nguyên mà yêu cầu.
- Vào mùa mưa, lao động thì rẻ hơn.
- Tất cả các stakeholder quan trọng sẽ đến vào buổi họp tới.
Constraints
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ó.
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.
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
Một 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.
Đến đây tôi hy vọng bạn đã hiểu Assumption & Constraint và vị trí của chúng trong QLDA. Một Assumption là những gì bạn nghĩ là đú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 PM và dự án mà PM thực hiện. Assumption & Constraint có thể là bất cứ gì, có thể là cost, quality, time, hr hay bất kỳ một loại tính năng nào…
- Đố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 Stakeholder.