Stakeholder Analysis

Dự án hỏng vì kỹ thuật thì ít, hỏng vì có người quan trọng bị bỏ quên đến tháng thứ tư mới lên tiếng thì nhiều. Stakeholder analysis là việc ngồi liệt kê xem ai bị ảnh hưởng, ai có quyền, ai sẽ chống, rồi quyết định giao tiếp với từng nhóm theo cách nào. BABOK xếp nó vào nhóm nhiệm vụ đầu tiên của Business Analysis Planning, và có lý do cho việc đó.

Stakeholder analysis là bước xác định ai liên quan tới dự án, mức quyền và mức quan tâm của họ ra sao, để bạn biết ai cần được hỏi trước và ai chỉ cần một email tóm tắt.

Power / Interest grid

Công cụ phổ biến nhất, chia hai trục: quyền lực (khả năng tác động đến dự án) và mức quan tâm (họ để tâm tới nó nhiều hay ít).

Ô "quản lý chặt" là nơi bạn dành phần lớn thời gian: họp định kỳ, hỏi ý kiến trước mọi quyết định lớn, cho họ thấy tên mình trong tài liệu. Ô "theo dõi" thì một bản tin mỗi tháng là đủ; đầu tư nhiều hơn là lãng phí.

Vị trí trên lưới không cố định. Một trưởng phòng đang ở ô quan tâm thấp sẽ nhảy sang ô quan tâm cao ngay khi phát hiện hệ thống mới đụng vào chỉ tiêu KPI của phòng họ. Vẽ lại lưới sau mỗi cột mốc lớn.

Onion diagram

Lưới cho biết đối xử thế nào, còn onion diagram cho biết họ đứng ở đâu so với giải pháp. Vẽ các vòng tròn đồng tâm:

• Lõi — giải pháp: chính hệ thống đang xây.
• Vòng 2 — người dùng trực tiếp: giao dịch viên, thủ kho, nhân viên chăm sóc khách hàng.
• Vòng 3 — tổ chức: các phòng ban bị ảnh hưởng, phòng kế toán nhận báo cáo, IT vận hành, kiểm soát nội bộ.
• Vòng ngoài — bên ngoài tổ chức: khách hàng cuối, nhà cung cấp, đối tác tích hợp, cơ quan quản lý.

Onion diagram có một công dụng rất thực tế: nó lộ ra những người bạn quên. Cứ vẽ xong vòng 3 mà thấy trống trơn phần "vận hành và hỗ trợ sau go-live" thì gần như chắc chắn bạn đang bỏ sót một nhóm sẽ phàn nàn dữ dội vào tháng thứ năm.

Ông quyền cao mà không quan tâm

Đây là loại nguy hiểm nhất, và cũng là câu hỏi hay gặp khi phỏng vấn. Một phó tổng ký được ngân sách nhưng bận, không dự họp, đọc email lướt. Vấn đề: họ im lặng suốt cho tới lúc nghiệm thu, rồi phát biểu một câu làm lệch cả dự án.

Vài cách đã dùng và thấy có tác dụng:

1. Đừng cố kéo họ vào họp dài. Họ sẽ không đến. Thay bằng bản cập nhật một trang, ba dòng: đang ở đâu, cần anh quyết gì, rủi ro nào đụng tới anh.
2. Tìm người ủy quyền. Hỏi thẳng: "Việc này cần một người duyệt hàng tuần, anh chỉ định ai đại diện được không." Có người được chỉ định là có kênh chính thức.
3. Chỉ xin đúng một quyết định mỗi lần. Đưa hai phương án kèm khuyến nghị, xin một chữ đồng ý. Đừng gửi 40 trang BRD kèm câu "anh xem giúp em".
4. Gắn dự án vào chỉ số họ đang chịu trách nhiệm. Chứng minh được hệ thống này giảm thời gian chốt sổ cuối tháng từ 5 ngày xuống 2, họ sẽ tự quan tâm.
5. Ghi lại mọi lần họ không phản hồi. Không để bắt lỗi ai; để lúc tranh cãi còn có mốc thời gian rõ ràng đặt lên bàn.

Ví dụ thực tế

Danh sách stakeholder gửi kèm biên bản kick-off có đúng ba dòng: phòng Nhân sự, phòng IT, ban giám đốc. Thứ phải thay là hệ thống chấm công và tính lương của một nhà máy 2.180 công nhân, ba ca, có ca đêm và phụ cấp độc hại.

Đến khi vẽ onion diagram, hai nhóm hiện ra ở vòng 3 mà trước đó chưa ai nhắc: tổ trưởng ca (người thực tế duyệt giờ tăng ca mỗi ngày, 37 người) và công đoàn (bên có tiếng nói về cách tính phụ cấp ca đêm). Tổ trưởng ca nằm ở ô quyền thấp — quan tâm cao, còn công đoàn thì quyền trung bình mà quan tâm rất cao.

Bỏ qua tổ trưởng ca thì hệ thống vẫn chạy, nhưng 37 người đó là người nhập dữ liệu, và họ đang ghi giờ tăng ca vào sổ giấy theo thói quen 6 năm. Nhóm dự án dành hai buổi ngồi cùng 5 tổ trưởng, rút màn hình duyệt tăng ca từ 4 bước xuống 1 bước quét thẻ, rồi mời họ vào UAT. Tuần đầu go-live, tỷ lệ chấm công sai dưới 2%, thay vì kịch bản quen thuộc là nửa nhà máy quay lại dùng sổ.

Mẹo khi đi làm

Đừng để bảng phân tích stakeholder trong file chung. Cột "thái độ" mà ghi "phản đối dự án, cần thuyết phục" lọt vào tay chính người đó thì bạn mất luôn một đồng minh tiềm năng. Bảng đầy đủ giữ riêng, bản chia sẻ chỉ có tên, vai trò và kênh liên lạc.