Công cụ phân quyền RACI Delegation

Phân quyền theo ma trận RACI là gì?

Bên cạnh Bảng phân quyền (Delegatin Board), một công cụ khác được đưa ra là RACI, bằng cách điền rõ quyền hạn của mỗi người tương đương với mỗi việc trên một ma trận như hình dưới

R - Responsible

Người thực hiện là người trực tiếp làm cho công việc đó hoàn thành.

Chú ý:

• Phải đảm bảo một công việc luôn có ít nhất một người thực hiện.
• Có thể có nhiều người thực hiện cho một công việc.
  

A - Accountable

Người chịu trách nhiệm giải trình kết quả của công việc này. Người này hiểu được thế nào là một công việc được hoàn thành. Nếu việc hỏng thì chịu trách nhiệm hàng đầu, cho dù người này không phải người thực hiện (R).

Người chịu trách nhiệm (A) cũng có thể chính là người thực hiện (R) hoặc không phải là người thực hiện. Nếu không thực hiện, người chịu trách nhiệm phải ủy quyền cho người thực hiện thông qua việc ủy quyển. Khi ủy quyền người chịu trách nhiệm phải mô tả rõ phạm vi công việc cho người thực hiện (R) bao gồm:

• Lý do, sự quan trọng của công việc đó.
• Thời gian hoàn thành tối đa cho phép.
• Chi phí, nguồn lực được phép sử dụng.
• Tiêu chí nghiệm thu của output để xác định công việc hoàn thành.

Chú ý:

• Mỗi công việc luôn phải có ít nhất 1 người chịu trách nhiệm và chỉ duy nhất một người.
  

C - Consulted

Người tư vấn, tham mưu cho công việc. Không phải người chịu trách nhiệm (A) và người thực hiện (R) nào cũng có đủ kiến thức chuyên môn cho công việc của mình, vì vậy họ sẽ cần đến sự tư vấn tham mưu từ người khác. Tuy nhiên vai trò thực hiện và vai trò chịu trách nhiệm.

I - Informed

Người cần phải nắm thông tin của công việc này. Khi công việc được thực hiện, được hoàn thành, gặp khó khăn hay có sự thay đổi thì luôn cần báo thông tin cho người này (I) cho dù họ không phải là người thực hiện hay người chịu trách nhiệm.

Ví dụ RACI trong các dự án triển khai tại Magestore

• Tại Magestore, các vai trò và chức danh ở hàng đầu được thay bằng tên người cụ thể do thực hiện Cross Function trong team dự án.
• Ma trận trên không cố định mà linh hoạt thay đổi tùy theo đặc thù mỗi dự án và team khác nhau. Mặc dù thường có sự phân công mặc định ban đầu, nhưng tùy thuộc tình hình nguồn lực và khách hàng mà có sự thay đổi phù hợp.
• Khi breakdown to detail issues, với mỗi issue lại có sự phân công chi tiết hơn nữa. Phân công theo issue có thể xảy ra từ đầu dự án, hoặc mỗi thành viên chủ động tự nhận issue.
• Cơ sở của việc xây dựng ma trận dựa trên sự thảo luận và thống nhất từ khi thành lập team và từ đầu dự án, cũng như sau mỗi giai đoạn của dự án.

Các bước xây dựng RACI

• Lập danh sách công việc căn cứ vào các Milestone, Work Breakdown Structure trong dự án của bạn.
• Lên danh sách thành viên dự án.
• Thảo luận và phân công vai trò theo RACI cho mỗi thành viên dự án, tránh các nhiệm vụ chung chung hoặc các nhiệm vụ hành chính như các cuộc họp nhóm hoặc báo cáo trạng thái.
• Nếu team của bạn là Cross Function (Không có vai trò, chức danh cụ thể), hãy điền tên thành viên vào hàng đầu tiên của ma trận.
• Hãy đảm bảo sự cân bằng không để một người phải R quá nhiều và người khác thì quá ít.
• Hãy review và cập nhật lại RACI mỗi khi bối cảnh dự án có sự thay đổi: thay đổi nhân sự, thay đổi yêu cầu, đi qua các mốc milestone..

Kết luận

Còn có rất nhiều mô hình phân quyển, ủy quyền khác nhau như PARIS, PACSI, .... Tuy nhiên điều căn bản nhất vẫn là sự linh hoạt nhưng vẫn đồng thuận, tin tưởng, bọc lót nhau trong team. Một bảng quyền máy móc, thiếu tính đồng thuận và tin tưởng cũng như thiếu rõ ràng cũng không giúp cho team hoạt động hiệu quả, hậu quả có thể là sự đổi lỗi, thoái bỏ trách nhiệm và khiến dự án thất bại hoặc thiếu hiệu quả.