“Quy trình và công cụ giúp dự án thành hình trên trang giấy, nhưng thấu hiểu con người và kiểm soát kỳ vọng mới là thứ đưa dự án cập bến thành công.”
Nguyễn Văn Hải — Hải Học Kinh Tế · Trích Series Quản trị dự ánBài viết là phần thứ hai trong series 7 bài về Quản trị dự án: Từ lý thuyết đến thực tế do Nguyễn Văn Hải tổng hợp và đúc kết từ tài liệu Buổi 2 khóa học Quản lý dự án tại SEONGON Academy (giảng viên Bùi Thị Mỹ Hảo), kết hợp với kinh nghiệm điều phối thực chiến tại các doanh nghiệp Marketing, E-commerce và Agency.
Lưu ý: Các bài toán thực hành, ma trận RACI và tình huống xử lý xung đột trong bài viết được biên tập nhằm mục đích chia sẻ kiến thức quản trị ứng dụng, bổ trợ cho giáo trình học tập chính khóa.
00. Nhìn lại Buổi 1: 5 lỗi kinh điển khi viết Scope Statement và dựng WBS
Trước khi bước sang chủ đề con người, giảng viên Bùi Thị Mỹ Hảo tại SEONGON Academy đã dành phần đầu Buổi 2 để chữa bài tập thực hành. Qua hàng chục bài làm của học viên, có 5 lỗi tư duy rất phổ biến mà bất kỳ ai mới làm Project Manager (PM) cũng đều từng mắc phải:
| HẠNG MỤC | LỖI HAY MẮC PHẢI | CÁCH SỬA CHUẨN XÁC |
|---|---|---|
| Mục tiêu nghiệm thu (Scope) | Thiếu con số cụ thể, viết chung chung theo cảm xúc. Ví dụ: "Tổ chức tiệc gắn kết", "Không khí vui vẻ", "Chiến dịch thành công". | Lượng hóa bằng chỉ số đo lường được: "Ít nhất 85% nhân sự tham dự (85/100 người)", "Điểm đánh giá mức độ hài lòng đạt ≥ 4.2/5.0". |
| Tiêu chí nghiệm thu (Acceptance Criteria) | Không bám sát mục tiêu dự án. Ví dụ: Mục tiêu đề ra số người tham dự và điểm hài lòng, nhưng tiêu chí nghiệm thu chỉ ghi mỗi ngân sách và giờ kết thúc. | Tiêu chí nghiệm thu phải là tấm gương phản chiếu trực tiếp của Mục tiêu: Mục tiêu có chỉ số nào thì Tiêu chí nghiệm thu phải có công thức đo chỉ số đó. |
| Phần "Không làm" (Out-of-Scope) | Viết mơ hồ, lặp lại sáo rỗng: "Không làm dịch vụ không cần thiết", "Không tổ chức ở chỗ quá xa", "Không làm hạng mục ngoài kế hoạch". | Chỉ rõ ranh giới cụ thể: "Không chi trả chi phí di chuyển cá nhân của khách mời ngoài danh sách", "Không bao gồm chi phí phát sinh đồ uống có cồn sau 22h00". |
| Đặt tên nhánh WBS | Dùng động từ hành động thay vì danh từ sản phẩm bàn giao: "Tìm nhà hàng", "Gửi thư mời", "Chạy quảng cáo". | Quy tắc 100% Deliverables: "Địa điểm tổ chức được ký hợp đồng", "Danh sách 200 khách mời được xác nhận", "Bộ 05 ấn phẩm truyền thông hoàn thiện". |
| Tính toàn vẹn của WBS | WBS không bám 100% Phạm vi công việc: có chỗ bị thừa việc không có trong Scope, có chỗ lại bỏ sót khâu quan trọng (như khâu dọn dẹp hoặc báo cáo nghiệm thu). | Tuân thủ quy tắc 100% Rule: Tổng các gói công việc cấp con phải bằng chính xác 100% gói công việc cấp cha, không thừa một ly, không thiếu một bước. |
Hiểu đúng về Phạm vi (Scope) và phân rã công việc (WBS) là điều kiện cần. Nhưng để một dự án thực sự vận hành trơn tru trong thực tế, chúng ta cần bước sang điều kiện đủ: Quản trị các bên liên quan (Stakeholder Management).
Lời mở đầu: Vì sao kế hoạch hoàn hảo vẫn có thể "chết" vì con người?
Hãy hình dung bạn vừa lập xong một bản kế hoạch Marketing hoàn hảo: WBS chi tiết đến từng đầu việc, Timeline rõ ràng từng mốc ngày, ngân sách tính toán sát sao từng đồng. Bạn gửi kế hoạch cho cả đội và tự tin rằng mọi thứ sẽ diễn ra như dự tính.
Nhưng chỉ sau một tuần triển khai, thực tế bắt đầu "dội gáo nước lạnh":
- Trưởng nhóm Lập trình (Tech Lead): "Tuần này đội anh đang dồn sức fix lỗi cho dự án cốt lõi của công ty, không có nhân sự hỗ trợ dựng landing page cho Marketing đâu nhé!"
- Kế toán trưởng (CFO): "Ủa, sao dự án này chi tiền mua tool ngoài mà không gửi đề xuất duyệt trước ngày 25 tháng trước? Giờ kế toán khóa sổ rồi, không chi đâu!"
- Sếp / Sponsor: "Anh thấy giao diện này chưa sang. Đổi toàn bộ tone màu pastel sang màu đen huyền bí và thêm tính năng AI chat ngay trong tuần này nhé!"
- Nhân sự trong đội: Nhắn tin vào nhóm thì ai cũng "thả tim" nhưng không ai chủ động bắt tay vào làm, vì không biết ai là người chịu trách nhiệm chính.
Bạn nhận ra: Dự án của bạn không gặp rắc rối vì thiếu công cụ hay kỹ thuật, mà đang bế tắc vì bạn chưa quản trị được Con Người.
Một dự án không bao giờ tồn tại trong chân không. Nó luôn bị bao quanh, thúc đẩy hoặc cản trở bởi mạng lưới các bên liên quan. Đó chính là lý do Buổi 2 của SEONGON Academy tập trung vào 4 trụ cột sống còn:
- Nhận diện & Phân loại Stakeholder: Biết rõ ai đang ở đâu trên bàn cờ dự án.
- Làm việc & Giao tiếp: Dùng mô hình RACI để xóa bỏ tình trạng "cha chung không ai khóc" và chọn đúng kênh liên lạc.
- Cải thiện mối quan hệ: Đo lường mức độ gắn kết từ Hiện tại (C) lên Mong muốn (D).
- Kiểm soát kỳ vọng: Đặt luật chơi ngay từ đầu và làm chủ 5 phương thức giải quyết xung đột.
01. Stakeholder là ai? Nhận diện đa chiều các bên liên quan
Trong suy nghĩ thông thường, chúng ta hay đồng nhất Stakeholder với "Khách hàng" hoặc "Sếp trực tiếp". Nhưng trong quản trị dự án chuyên nghiệp, định nghĩa này rộng và bao quát hơn rất nhiều.
Định nghĩa chuẩn (SEONGON Academy & PMI):
“Stakeholder (Bên liên quan) là bất kỳ cá nhân, nhóm hay tổ chức nào có thể ảnh hưởng, bị ảnh hưởng, hoặc tự cảm thấy/cho rằng mình bị ảnh hưởng bởi quyết định, hoạt động hoặc kết quả của dự án.”
3 Nhóm Stakeholder cần nhận diện
Điểm đắt giá nhất trong định nghĩa trên nằm ở cụm từ: "cho rằng mình bị ảnh hưởng". Dù trên thực tế bạn không hề có ý định tác động đến họ, nhưng nếu họ có cảm nhận tiêu cực hoặc lo lắng, họ hoàn toàn có thể trở thành rào cản lớn cho dự án.
| NHÓM STAKEHOLDER | ĐỐI TƯỢNG ĐIỂN HÌNH | ẢNH HƯỞNG TỚI DỰ ÁN |
|---|---|---|
| 1. Nhóm gây ảnh hưởng (Influencing) | Sponsor (Nhà tài trợ / Ban giám đốc), Khách hàng, Supplier (Nhà cung cấp), Đội dự án (Project Team), Cơ quan quản lý nhà nước (Government). | Nắm quyền phê duyệt ngân sách, cung cấp tài nguyên nhân lực, quyết định dự án được tiếp tục hay dừng lại. |
| 2. Nhóm cho rằng mình bị ảnh hưởng (Perceived) | Báo chí & Truyền thông (Press & Media), Giới phê bình, KOLs / KOCs, Cộng đồng người dùng mạng xã hội, Các phòng ban lân cận sợ bị mất vị thế. | Có thể tạo ra làn sóng dư luận trái chiều, khiếu nại hoặc lan truyền thông tin sai lệch nếu không được truyền thông khéo léo. |
| 3. Nhóm trực tiếp bị ảnh hưởng (Impacted) | Khách hàng cuối (End-users), Nhân sự vận hành trực tiếp (Workers), Cộng đồng dân cư chịu tác động tại địa phương. | Là người thụ hưởng hoặc gánh chịu thay đổi từ sản phẩm đầu ra; phản hồi của họ quyết định chất lượng nghiệm thu cuối cùng. |
Quy trình 4 bước nhận diện Stakeholder bài bản
Để không bỏ sót bất kỳ ai, PM cần đi qua quy trình 4 bước tuần tự ngay từ giai đoạn Khởi tạo (Initiating):
| BƯỚC | HÀNH ĐỘNG CỦA PM | CÂU HỎI HƯỚNG DẪN |
|---|---|---|
| BƯỚC 1 Liệt kê (Identify) |
Brainstorm toàn diện danh sách tất cả cá nhân, phòng ban, đối tác liên quan. | Ai bỏ tiền? Ai làm? Ai duyệt? Ai dùng? Ai có thể ngăn cản? Ai sẽ bị ảnh hưởng khi quy trình này thay đổi? |
| BƯỚC 2 Phân tích (Analyze) |
Làm rõ mục tiêu, mối quan tâm, quyền hạn và nỗi sợ của từng bên đối với dự án. | Họ mong muốn đạt được điều gì? Điều gì khiến họ khó chịu nhất? Họ có thẩm quyền ký tá hay chi tiền không? |
| BƯỚC 3 Phân loại (Classify) |
Đặt các bên vào Ma trận Quyền lực - Quan tâm (Power - Interest Grid). | Họ thuộc ô Quyền lực cao hay thấp? Mức độ quan tâm của họ tới công việc này là sâu sát hay chỉ nhìn thoáng qua? |
| BƯỚC 4 Lên chiến lược (Plan) |
Xây dựng kế hoạch giao tiếp, tần suất báo cáo và cách thức duy trì quan hệ phù hợp. | Mỗi tuần báo cáo họ mấy lần? Gặp mặt hay gửi email tóm tắt? Ai cần tham vấn, ai chỉ cần thông báo kết quả? |
02. Ma trận Quyền lực — Quan tâm (Power — Interest Grid)
Nguồn lực và thời gian của Project Manager luôn có hạn. Bạn không thể ngày nào cũng gửi báo cáo dài 10 trang cho tất cả mọi người, cũng không thể họp bàn xin ý kiến của từng nhân viên.
Công cụ kinh điển giúp PM "dồn công sức đúng chỗ" là Ma trận Quyền lực — Quan tâm (Power — Interest Grid), chia các bên liên quan thành 4 nhóm với chiến lược đối ứng riêng biệt:
Chiến lược hành động chi tiết cho từng nhóm
Sau khi định vị các bên vào ma trận, PM cần áp dụng đúng phương thức giao tiếp và mức độ đầu tư thời gian như bảng dưới đây:
| NHÓM STAKEHOLDER | ĐỊNH HƯỚNG | CHIẾN LƯỢC | CÁCH LÀM VIỆC GỢI Ý |
|---|---|---|---|
| Quyền lực cao — Quan tâm cao (Sếp, Khách hàng, Sponsor) |
Làm việc chặt chẽ (Manage Closely) |
Ưu tiên cao nhất | Họp định kỳ (1-on-1 hoặc Weekly Sync), gửi báo cáo chi tiết, chủ động tham vấn và mời tham gia các mốc quyết định quan trọng của dự án. |
| Quyền lực cao — Quan tâm thấp (CFO, Kế toán, Pháp chế) |
Đảm bảo hài lòng (Keep Satisfied) |
Đáp ứng đủ, không làm phiền | Gửi báo cáo tóm tắt định kỳ ngắn gọn (Executive Summary). Chỉ xin ý kiến hoặc họp gấp khi có thay đổi lớn đụng chạm tới ngân sách hay quy định pháp lý. |
| Quyền lực thấp — Quan tâm cao (Đội dự án, Người dùng cuối) |
Cập nhật thông tin (Keep Informed) |
Theo sát, minh bạch dữ liệu | Gửi email cập nhật tiến độ đều đặn, tổ chức Daily Standup nhanh gọn, lắng nghe phản hồi của họ để tháo gỡ khó khăn tác nghiệp kịp thời. |
| Quyền lực thấp — Quan tâm thấp (Nhân sự phòng ngoài, NCC phụ) |
Theo dõi tối thiểu (Monitor) |
Dành ít thời gian nhất | Chỉ gửi thông báo khi thực sự cần phối hợp hoặc có liên quan trực tiếp. Tuyệt đối tránh gửi email thừa làm loãng hộp thư của họ. |
Lời khuyên từ giảng viên Hảo Bùi: “Vị trí của một Stakeholder trên ma trận không phải là cố định vĩnh viễn. Trong giai đoạn lập kế hoạch, Kế toán trưởng có thể ở ô 'Quan tâm thấp'. Nhưng đến tuần thanh toán nghiệm thu, họ lập tức nhảy sang ô 'Quan tâm cực kỳ cao'. PM thông minh luôn phải rà soát ma trận này định kỳ.”
03. Tình huống thực tế: "Ngôi nhà bàn giao bị thấm nước"
Để thấy rõ sự sụp đổ của một dự án khi thiếu phân công trách nhiệm, SEONGON Academy đưa ra tình huống thảo luận rất đắt giá:
Một ngôi nhà chuẩn bị được bàn giao cho khách vào ở. Chỉ huy trưởng công trình (Project Manager) nhắn vào nhóm chat chung có hơn 10 người:
“Cả nhà nhớ kiểm tra kỹ căn nhà một lượt trước khi bàn giao cho khách nhé, đừng để sai sót gì!”
Kết quả: Mấy hôm sau khách hàng đến nhận nhà, vừa bước vào phòng tắm thì phát hiện một mảng tường bị ngấm nước loang lổ — điều đáng lẽ phải được phát hiện và xử lý chống thấm từ tuần trước. Khách hàng vô cùng bực bội, từ chối ký biên bản, buổi bàn giao bị hoãn và công ty chịu tổn thất uy tín nghiêm trọng.
Nguyên nhân thực sự nằm ở đâu?
Rất nhiều người sẽ vội đổ lỗi cho thợ thi công ẩu, hoặc trách giám sát lơ là. Nhưng xét dưới góc độ Quản trị dự án: Lỗi 100% thuộc về Project Manager!
- Tâm lý "Cha chung không ai khóc": Khi bạn nhắn cho "cả nhà", tâm lý đám đông sẽ khiến ai cũng nghĩ rằng: "Chắc người khác kiểm tra rồi, không đến lượt mình".
- Giao việc bằng cảm xúc, thiếu tiêu chuẩn: Thế nào là "kiểm tra kỹ"? Có checklist hạng mục cụ thể không? Ai kiểm tra phần điện? Ai kiểm tra đường nước? Ai chịu trách nhiệm ký xác nhận nghiệm thu?
- Thiếu một người "đứng mũi chịu sào": Trong nhóm 10 người, không một ai được chỉ định rõ ràng là người sẽ chịu trách nhiệm kỷ luật nếu có lỗi rò rỉ.
Để giải quyết triệt để căn bệnh này trong mọi dự án Marketing, phần mềm hay xây dựng, thế giới sử dụng một vũ khí tiêu chuẩn: Mô hình Ma trận RACI.
04. Mô hình RACI & 3 lỗi kinh điển biến dự án thành "bãi chiến trường"
RACI là ma trận phân công trách nhiệm (Responsibility Assignment Matrix), dùng để làm rõ vai trò của từng cá nhân hoặc bộ phận đối với từng gói công việc trong WBS. Mô hình này đặc biệt phát huy sức mạnh với các nhóm từ 3–5 người trở lên.
| CHỮ CÁI | VAI TRÒ TRONG DỰ ÁN | BẢN CHẤT CÔNG VIỆC | QUY TẮC BẮT BUỘC |
|---|---|---|---|
| R Responsible |
Người thực thi (Doer / Executor) |
Người trực tiếp "xắn tay áo" vào làm ra kết quả đầu ra cụ thể (viết code, thiết kế banner, xây tường...). | Có thể có nhiều chữ R trong một đầu việc nếu cần nhiều người cùng phối hợp làm. |
| A Accountable |
Người chịu trách nhiệm (Decision Maker / Owner) |
Người "đứng mũi chịu sào" có quyền duyệt kết quả cuối cùng. Nếu công việc thất bại, đây là người duy nhất bị "trảm". | NGUYÊN TẮC BẤT DI BẤT DỊCH: Mỗi đầu việc chỉ được phép có DUY NHẤT 1 chữ A! |
| C Consulted |
Người được tham vấn (Advisor / Expert) |
Chuyên gia hoặc phòng ban liên quan. Trước khi người thực thi (R) nộp bài hoặc người duyệt (A) bấm nút, bắt buộc phải hỏi ý kiến họ. | Đây là giao tiếp 2 chiều (hỏi và phản hồi). Nhưng người C chỉ tư vấn, không có quyền quyết định thay chữ A. |
| I Informed |
Người được thông báo (Viewer / Stakeholder) |
Người cần biết tiến độ hoặc kết quả để thực hiện các công việc tiếp theo của họ. | Đây là giao tiếp 1 chiều (chỉ gửi thông tin để họ biết, không cần chờ họ đồng ý hay xin ý kiến). |
3 Căn bệnh kinh điển khi áp dụng sai RACI
Một ma trận RACI được thiết kế vụng về có thể làm tê liệt cả bộ máy. Dưới đây là 3 lỗi phổ biến nhất:
| DẤU HIỆU LỖI | HẬU QUẢ THỰC TẾ | GIẢI PHÁP ĐIỀU CHỈNH |
|---|---|---|
| 1. Không có chữ A (No Accountable) |
"Cha chung không ai khóc". Mọi người đùn đẩy trách nhiệm, khi có lỗi phát sinh thì không ai đứng ra giải quyết vì "việc này của cả nhóm mà". | Bắt buộc chỉ định đích danh 1 người duy nhất làm "Owner" chịu trách nhiệm nghiệm thu cuối cùng cho đầu việc đó. |
| 2. Nhiều hơn 1 chữ A (Multiple Accountable) |
"Lắm thầy nhiều ma", "Tam sao thất bản". Hai sếp cùng có chữ A nhưng đưa ra hai chỉ đạo mâu thuẫn nhau, nhân viên thực thi (R) không biết nghe theo lệnh ai. | Tách nhỏ đầu việc ra thành 2 gói công việc độc lập, hoặc chỉ định 1 người có thẩm quyền cao hơn giữ quyền quyết định duy nhất. |
| 3. Quá nhiều chữ C (Too Many Consulted) |
Họp hành liên miên, "đẽo cày giữa đường". Để duyệt một bài viết hay một banner mà phải chờ ý kiến của 5 phòng ban khác nhau, tạo nên nút thắt cổ chai làm trễ hạn dự án. | Chuyển bớt các bên không thực sự trọng yếu từ chữ C (phải hỏi ý kiến) xuống chữ I (chỉ gửi thông báo cập nhật kết quả). |
Áp dụng RACI giải quyết triệt để tình huống bàn giao nhà
Nếu Chỉ huy trưởng công trình áp dụng RACI trước ngày bàn giao, thảm kịch tường thấm nước sẽ không bao giờ xảy ra:
| GÓI CÔNG VIỆC BÀN GIAO | CHỊ HẢO (Chỉ huy trưởng - PM) |
ANH DŨNG (Giám sát QA/QC) |
ANH TÚ (Đội trưởng thi công) |
CHỊ LINH (Kinh doanh bàn giao) |
|---|---|---|---|---|
| 1. Kiểm tra tổng thể kỹ thuật trước bàn giao | A | R | C | I |
| 2. Khắc phục các lỗi phát hiện (chống thấm, sơn) | A | C | R | I |
| 3. Nghiệm thu nội bộ (xác nhận đạt chuẩn bàn giao) | A | R | C | I |
| 4. Tổ chức đón tiếp & Bàn giao chìa khóa cho khách | A | I | I | R |
Nhìn vào bảng trên: Anh Dũng (QA/QC) là người trực tiếp cầm checklist đi soi từng góc phòng tắm (chữ R). Nếu bỏ sót lỗi thấm nước, Chị Hảo (PM - chữ A) sẽ kỷ luật trực tiếp anh Dũng trước khi khách hàng đến. Trách nhiệm minh bạch, không ai có thể đổ lỗi cho nhau!
05. Phương thức và Kênh giao tiếp với Stakeholder: Đúng người, đúng kênh
Có người thích gọi điện thoại, có người chỉ đọc email, có người lại quen chat Telegram. Nếu PM chọn sai kênh giao tiếp, thông tin sẽ bị trôi, gây hiểu lầm hoặc làm bùng phát mâu thuẫn.
3 Chiều kích của Giao tiếp dự án
| CHIỀU KÍCH | PHÂN LOẠI CHI TIẾT | BỐI CẢNH ỨNG DỤNG |
|---|---|---|
| 1. Tính chính thức |
• Formal (Chính thức): Trang trọng, theo quy chuẩn (biên bản họp, hợp đồng, email báo cáo). • Informal (Không chính thức): Trao đổi nhanh qua chat, hỏi thăm bên lề cà phê. |
Dùng Formal khi chốt duyệt mốc quan trọng, thay đổi phạm vi hoặc ngân sách. Dùng Informal để duy trì tình cảm và gắn kết đội ngũ hàng ngày. |
| 2. Hình thức thể hiện |
• Written (Văn bản): Chữ viết, email, biên bản. • Verbal (Lời nói): Trao đổi trực tiếp, gọi điện thoại. • Non-verbal (Phi ngôn ngữ): Ánh mắt, giọng điệu, thái độ. |
Written bắt buộc phải có để "lưu vết" (Audit Trail), tránh cảnh "lời nói gió bay". Verbal và Non-verbal giúp truyền tải sự chân thành và giải tỏa căng thẳng khi đàm phán. |
| 3. Phương thức truyền tải |
• Push (Đẩy 1 chiều): Gửi email, SMS (người nhận bị động, chưa chắc đã đọc). • Pull (Kéo chủ động): Để tài liệu trên Drive, Notion (ai cần thì tự vào lấy). • Interactive (Tương tác 2 chiều): Họp trực tiếp, gọi video call (phản hồi tức thì). |
Dùng Push cho thông báo rộng rãi; dùng Pull cho kho tài liệu tham khảo; dùng Interactive khi cần gỡ vướng mắc khẩn cấp hoặc ra quyết định chung. |
4 Kênh giao tiếp "gối đầu giường" của Project Manager
Trong thực tế điều hành, PM sẽ xoay quanh 4 công cụ chính:
| KÊNH | MỤC ĐÍCH PHÙ HỢP NHẤT | VÍ DỤ THỰC TẾ TRONG DỰ ÁN MARKETING |
|---|---|---|
| 1. Meeting (Họp trực tiếp / Online) |
Cần tương tác trực diện (face-to-face): thống nhất mục tiêu, gỡ nút thắt, giải quyết tranh cãi, ra quyết định then chốt, nghiệm thu dự án. | Họp Kick-off chiến dịch ra mắt sản phẩm; Buổi Pitching chốt hợp đồng với đối tác; Họp Post-mortem rút kinh nghiệm sau sự kiện. |
| 2. Email (Thư điện tử chính thức) |
Cần văn bản hóa để lưu trữ vết tích pháp lý; gửi tới các cá nhân/nhóm cụ thể; trao đổi có tính chất hành chính trang trọng. | Gửi biên bản chốt yêu cầu (Meeting Minutes); Thông báo phê duyệt ngân sách phát sinh (Change Request); Gửi file hợp đồng nghiệm thu. |
| 3. Call (Gọi điện thoại thoại / voice) |
Nội dung cần xử lý ngay lập tức, việc gấp gáp, hoặc vấn đề nhạy cảm dễ bị hiểu lầm/mất lòng nếu thể hiện qua câu chữ khô khan. | Gọi báo sếp khi server sập giữa đợt Flash Sale; Gọi trấn an khách hàng khi đối tác in ấn giao trễ hàng; Làm rõ yêu cầu đang mập mờ. |
| 4. Chat (Slack / Zalo / Telegram) |
Trao đổi nhanh gọn, ngắn hạn, phi chính thức và không quá khẩn cấp: hỏi đáp công việc hàng ngày, nhắc việc nhẹ nhàng, phối hợp tác nghiệp. | Nhắc đồng nghiệp nộp bài trước 17h00; Gửi link tài liệu tham khảo; Hỏi nhanh thông số kích thước banner Facebook. |
06. Cải thiện mối quan hệ: Thang 5 mức độ gắn kết & Ma trận Current (C) — Desired (D)
Mỗi bên liên quan bước vào dự án với một thái độ tâm lý khác nhau. Nhiệm vụ của PM là nhận diện trạng thái hiện tại và từng bước kéo họ về mức độ gắn kết có lợi nhất cho dự án.
Thang 5 mức độ gắn kết của Stakeholder
| MỨC ĐỘ GẮN KẾT | BIỂU HIỆN ĐẶC TRƯNG | TÁC ĐỘNG TỚI DỰ ÁN |
|---|---|---|
| 1. Không biết (Unaware) |
Hỏi những câu ngô nghê về dự án; vắng mặt trong các buổi trao đổi vì nghĩ không liên quan đến mình; ngạc nhiên khi bị nhắc tên. | Không gây hại trực tiếp nhưng có thể tạo ra rủi ro tắc nghẽn khi dự án bất ngờ cần họ phối hợp dữ liệu. |
| 2. Phản đối (Resistant) |
Chủ động phản bác; liên tục nêu lý do dự án sẽ thất bại; trì hoãn việc; né tránh hợp tác; nói xấu sau lưng và lôi kéo người khác chống đối. | Cực kỳ nguy hiểm! Có thể phá hoại tinh thần đồng đội hoặc phủ quyết dự án trong các buổi họp giao ban. |
| 3. Trung lập (Neutral) |
Làm đúng phần việc được giao cho xong rồi về, không làm hơn; ít đóng góp ý kiến; trong cuộc họp thường im lặng gật đầu. | Dự án chạy được nhưng thiếu tính đột phá, không có sự hỗ trợ chủ động khi phát sinh sự cố ngoài dự kiến. |
| 4. Ủng hộ (Supportive) |
Phối hợp tích cực; trả lời tin nhắn và email nhanh chóng, đúng hạn; nhiệt tình đóng góp ý kiến mang tính xây dựng. | Là nền tảng vững chắc giúp dự án duy trì tiến độ và đạt tiêu chuẩn chất lượng cao. |
| 5. Dẫn dắt (Leading) |
Chủ động vượt ra ngoài vai trò: đứng ra tháo gỡ rào cản hành chính, kéo tài nguyên về cho đội, bảo vệ dự án ở những nơi PM không có mặt. | Là "đồng minh chiến lược" quý giá nhất của PM trong ban lãnh đạo công ty. |
Ma trận Đánh giá mức độ gắn kết (Current vs Desired Matrix)
PM dùng ký hiệu C (Current level - Trạng thái hiện tại) và D (Desired level - Trạng thái mong muốn) để trực quan hóa khoảng cách cần thu hẹp:
| STAKEHOLDER TRỌNG YẾU | KHÔNG BIẾT | PHẢN ĐỐI | TRUNG LẬP | ỦNG HỘ | DẪN DẮT |
|---|---|---|---|---|---|
| Chị Thảo (Kế toán trưởng) | C | D | |||
| Anh Nam (Trưởng nhóm Kỹ thuật) | C | D | |||
| Chị Hà (Nhân viên Kinh doanh) | C, D | ||||
| Anh Minh (Nhân viên Marketing) | C | D | |||
| Anh Phúc (COO / Sponsor) | C | D |
2 Bài học cốt lõi từ ma trận C-D:
- Không cần biến tất cả mọi người thành "Dẫn dắt" (Leading): Với Chị Hà (Kinh doanh), chỉ cần chị ở mức "Trung lập" (C, D trùng nhau), làm đúng quy trình nhận bàn giao là dự án đã thành công. Kéo người không cần thiết lên mức cao sẽ lãng phí tài nguyên của PM.
- Tập trung dập lửa ở nhóm Tiêu cực: Ưu tiên số 1 của PM là kéo những người đang ở nhóm "Phản đối" (như Anh Nam Kỹ thuật) hoặc "Không biết" (Chị Thảo Kế toán) về mức tối thiểu là "Ủng hộ" (D) để triệt tiêu các quả bom nổ chậm.
07. Lập kế hoạch cải thiện mức độ gắn kết Stakeholder
Để đưa một người từ C sang D, bạn không thể dùng phép thuật mà phải có hành động cụ thể. Dưới đây là bảng kế hoạch can thiệp mẫu từ giáo trình SEONGON Academy:
| BÊN LIÊN QUAN | QUYỀN LỰC / QUAN TÂM | HIỆN TẠI → MONG MUỐN | KẾ HOẠCH GIAO TIẾP & TÁC ĐỘNG | TẦN SUẤT |
|---|---|---|---|---|
| Chị Thảo Kế toán trưởng |
Quyền lực: Cao Quan tâm: Thấp |
Không biết ↓ Ủng hộ |
• Gặp trực tiếp thông báo mục tiêu dự án và tác động tới dòng tiền kế toán. • Chỉ rõ lợi ích: phần mềm mới sẽ giảm 70% nhập liệu thủ công cho phòng chị. • Mời chị góp ý về cấu trúc báo cáo tài chính để tạo cảm giác được tôn trọng. |
Khi khởi động & Định kỳ hàng tháng |
| Anh Nam Trưởng nhóm Kỹ thuật |
Quyền lực: Cao Quan tâm: Cao |
Phản đối ↓ Ủng hộ |
• Gặp riêng 1-on-1: Lắng nghe chân thành nỗi lo quá tải của đội kỹ thuật. • Mời anh Nam tham gia khâu chốt kiến trúc công nghệ để anh giữ quyền kiểm soát chuyên môn. • Phối hợp với COO điều chỉnh độ ưu tiên backlog, không ép deadline phi thực tế. |
Hàng tuần (Weekly Sync) |
| Chị Hà Nhân viên Kinh doanh |
Quyền lực: Thấp Quan tâm: Thấp |
Trung lập ↓ Trung lập |
• Cập nhật thông tin ngắn gọn, đúng lúc qua bản tin nội bộ. • Gửi thông báo trước 3 ngày khi có mốc bàn giao ảnh hưởng tới phòng kinh doanh. • Chưa cần tác động thêm để tránh tốn thời gian. |
Khi có mốc thay đổi lớn |
| Anh Minh Nhân viên Marketing |
Quyền lực: Thấp Quan tâm: Cao |
Trung lập ↓ Dẫn dắt |
• Cho anh thấy giá trị của dự án đối với KPI cá nhân và cơ hội thăng tiến. • Giao anh làm đầu mối trực tiếp thử nghiệm sản phẩm và thu thập feedback. • Công khai khen ngợi và nêu bật những đóng góp của anh trước ban giám đốc. |
Hàng tuần & Theo từng sprint |
| Anh Phúc COO (Sponsor) |
Quyền lực: Cao Quan tâm: Cao |
Ủng hộ ↓ Dẫn dắt |
• Cập nhật liên tục tiến độ, điểm nghẽn và các rủi ro tiềm ẩn. • Tham vấn anh Phúc ở tất cả các quyết định mang tính chiến lược. • Nhờ anh làm "lá chắn", tháo gỡ rào cản liên phòng ban và lan tỏa tinh thần ủng hộ trong ban lãnh đạo. |
Hàng tuần & Các mốc then chốt |
08. Đặt nguyên tắc & Kiểm soát kỳ vọng (Expectation Management)
Mâu thuẫn trong dự án hiếm khi phát sinh vì ai đó muốn phá hoại, mà hầu hết bắt nguồn từ sự lệch pha về kỳ vọng giữa PM, đội ngũ và sếp/khách hàng.
Khi nào bắt buộc phải thống nhất kỳ vọng?
- Các mốc cố định: Đầu dự án (Kick-off meeting), đầu mỗi giai đoạn (Phase gate), các buổi báo cáo định kỳ (Monthly review), và đặc biệt là trước thời điểm nghiệm thu khoảng 2 tuần đến 1 tháng.
- Các mốc phát sinh: Khi có nhân sự chủ chốt mới tham gia, khi khách hàng yêu cầu đổi phạm vi, khi tiến độ thực tế bị trễ so với kế hoạch, hoặc ngay khi PM ngửi thấy dấu hiệu bất an từ bất kỳ bên nào.
4 Nguyên tắc vàng cần "chốt hạ" bằng văn bản ngay từ ngày đầu
| NGUYÊN TẮC | NỘI DUNG CẦN THỐNG NHẤT | LỢI ÍCH TRÁNH TRANH CÃI |
|---|---|---|
| 1. Thẩm quyền quyết định | Ai là người có quyền ký duyệt tăng ngân sách? Ai chốt giải pháp chuyên môn kỹ thuật? Ai có thẩm quyền điều động thêm nhân sự? | Tránh việc nhân viên tự ý nghe lời sếp phòng khác mà làm vỡ kế hoạch chung của dự án. |
| 2. Quy chuẩn giao tiếp & Báo cáo | Báo cáo qua kênh nào (Email/Notion)? Tần suất bao lâu một lần? Thời hạn tối đa để phản hồi email là mấy tiếng (ví dụ trong vòng 24h)? | Không ai có thể phàn nàn là "không thấy ai báo gì" hoặc để email ngâm cả tuần không trả lời. |
| 3. Định nghĩa hoàn thành công việc | Sản phẩm đầu ra cần đầy đủ những thành phần nào mới được xem là hoàn thành (Definition of Done)? Nếu muốn đổi yêu cầu thì phải đi qua quy trình nào? | Chặn đứng bẫy Scope Creep và bàn giao nửa vời. |
| 4. Văn hóa phối hợp & Phản hồi | "Feedback về công việc — Không feedback về con người". Nếu có nguy cơ chậm tiến độ, bắt buộc phải báo trước deadline ít nhất 24 giờ. | Giữ gìn sự tôn trọng lẫn nhau và cho PM đủ thời gian xoay sở phương án dự phòng. |
09. 5 Phương thức xử lý xung đột khi kỳ vọng không khớp nhau
Khi bất đồng xảy ra giữa các bên liên quan, một PM non tay thường chọn cách né tránh hoặc nhượng bộ vội vã. Nhưng một PM bản lĩnh sẽ linh hoạt lựa chọn trong 5 phương thức giải quyết xung đột chuẩn mực:
| PHƯƠNG THỨC | BẢN CHẤT | ĐẶC ĐIỂM THỰC THI | KHI NÀO NÊN DÙNG? |
|---|---|---|---|
| 1. WIN — WIN (Collaborating / Hợp tác) |
Xử lý tận gốc Giải pháp lý tưởng nhất |
Các bên ngồi lại cùng mổ xẻ vấn đề trên tinh thần xây dựng, tìm ra phương án mới mà cả hai bên cùng đạt được mục tiêu cốt lõi. | Khi vấn đề quá quan trọng không thể nhượng bộ, và mối quan hệ giữa hai bên mang tính chiến lược lâu dài. |
| 2. LOSE — LOSE (Compromising / Thỏa hiệp) |
Xử lý tận gốc Giải pháp tạm thời |
Mỗi bên chấp nhận lùi một bước, chịu thiệt một chút để tìm được tiếng nói chung ở điểm cân bằng ở giữa. | Khi thời gian gấp rút, cần chốt ngay phương án để tiếp tục dự án và hai bên có quyền lực ngang nhau. |
| 3. WIN — LOSE (Competing / Áp đặt) |
Xử lý tận gốc Dùng quyền lực |
Một bên dùng thẩm quyền hoặc vị thế cao hơn để ép bên kia làm theo ý mình (1 bên thắng - 1 bên thua). | Chỉ dùng trong tình huống khẩn cấp sống còn, xử lý khủng hoảng truyền thông hoặc khi an toàn dự án bị đe dọa. |
| 4. XOA DỊU (Accommodating / Nhượng bộ) |
Không tận gốc Giữ hòa khí |
Tạm thời gạt bỏ xung đột qua một bên, chấp nhận nhượng bộ đối phương để bảo toàn mối quan hệ và tập trung vào các ưu tiên lớn hơn. | Khi vấn đề đó rất quan trọng với đối phương nhưng không ảnh hưởng nhiều đến bạn; hoặc khi bạn nhận ra mình sai. |
| 5. NÉ TRÁNH (Avoiding / Rút lui) |
Không tận gốc Hoãn xung đột |
Không trực tiếp đối đầu, trì hoãn thảo luận, lùi lại để các bên hạ nhiệt cảm xúc hoặc chờ thêm dữ liệu chứng minh. | Khi cảm xúc hai bên đang quá nóng nảy, nguy cơ cãi vã vô ích; hoặc khi vấn đề quá vụn vặt không đáng tốn năng lượng. |
10. Bảng Checklist 10 câu hỏi tự vấn trước khi bước vào cuộc họp Stakeholder
Trước khi gõ cửa phòng sếp, gọi điện cho khách hàng hoặc tổ chức buổi họp liên phòng ban, hãy tự trả lời 10 câu hỏi kiểm định này:
| STT | CÂU HỎI TỰ VẤN CỦA PROJECT MANAGER | MỤC TIÊU KIỂM SOÁT |
|---|---|---|
| 01 | Tôi đã liệt kê đầy đủ những người bị ảnh hưởng trực tiếp lẫn gián tiếp chưa? | Tránh bỏ sót Stakeholder ngầm (như kế toán, pháp chế, IT). |
| 02 | Người tham dự cuộc họp này thuộc ô nào trên Ma trận Power — Interest? | Xác định phong cách giao tiếp: Báo cáo sâu hay tóm tắt ngắn. |
| 03 | Mỗi đầu việc trong chương trình họp hôm nay đã có DUY NHẤT 1 chữ A chưa? | Chặn đứng căn bệnh "cha chung không ai khóc". |
| 04 | Tôi có đang mời quá nhiều người ở vai trò C (Tham vấn) làm loãng cuộc họp không? | Cắt giảm thời gian họp vô bổ, tránh nút thắt cổ chai. |
| 05 | Kênh giao tiếp này đã đúng chưa: Cần Meeting trực tiếp hay chỉ cần gửi 1 email? | Tôn trọng quỹ thời gian của đội ngũ và cấp trên. |
| 06 | Stakeholder này hiện đang ở mức gắn kết nào: Phản đối, Trung lập hay Ủng hộ? | Chuẩn bị kịch bản tâm lý và các luận điểm giải tỏa nỗi lo của họ. |
| 07 | Tôi đã làm rõ lợi ích (WIIFM - What's In It For Me) của dự án đối với họ chưa? | Chuyển hóa Stakeholder từ "Bị ép làm" sang "Chủ động hợp tác". |
| 08 | Các mốc kỳ vọng về thẩm quyền, tiến độ và sản phẩm đầu ra đã thành văn bản chưa? | Loại bỏ hiểu lầm ngầm định (Assumptions). |
| 09 | Nếu cuộc họp xảy ra xung đột gay gắt, tôi sẽ chọn phương thức nào (Win-Win, Thỏa hiệp hay Lùi lại)? | Giữ vững sự bình tĩnh chuyên nghiệp, không bị cảm xúc dẫn dắt. |
| 10 | Sau cuộc họp, ai sẽ là người viết và gửi Meeting Minutes trong vòng 2 tiếng? | Lưu vết quyết định chính thức (Audit Trail). |
Kết luận: Khi quản lý dự án thực chất là quản trị các mối quan hệ
Qua hai bài học đầu tiên trong series Quản trị dự án: Từ lý thuyết đến thực tế, bức tranh tổng thể đã dần hiện rõ:
- Bài 01 trả lời câu hỏi: “Dự án này làm cái gì và làm đến đâu?” (Scope Statement & WBS).
- Bài 02 trả lời câu hỏi: “Dự án này do ai làm, ai chịu trách nhiệm, và làm thế nào để tất cả các bên cùng đồng lòng bước về một hướng?” (Stakeholder Management & RACI).
Một người quản lý dự án giỏi không phải là người ra lệnh to nhất, mà là người có khả năng kết nối các điểm chạm lợi ích: giúp sếp an tâm về tiến độ, giúp kỹ thuật không bị quá tải, giúp kế toán rõ ràng số liệu, và giúp khách hàng nhận được giá trị xứng đáng với kỳ vọng.
Khi đã có danh sách gói công việc chuẩn xác (WBS) và bộ máy nhân sự được phân quyền minh bạch (RACI), thử thách tiếp theo của PM là: Làm thế nào để ước lượng thời gian chuẩn xác, sắp xếp thứ tự ưu tiên và vẽ nên bản đồ tiến độ Gantt Chart không thể bị phá vỡ?
Hẹn gặp bạn ở Bài 03: Lập kế hoạch tiến độ & Làm chủ sơ đồ Gantt Chart!