INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Vì sao lãnh đạo mất cam kết giữa dự án? Cách duy trì đồng thuận các bên liên quan

Cam kết suy giảm thường phản ánh thay đổi trong ưu tiên, niềm tin hoặc gánh nặng chuyển đổi. Giám đốc dự án cần nhận biết nguyên nhân, tổ chức đối thoại quanh quyết định và xác nhận những đóng góp có thể thực hiện.

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc dự án IT – Project Manager

← Trở về thư viện bài viết

Minh họa biên tập: quản lý dự án trao đổi trực tiếp với Sponsor và đại diện nghiệp vụ để xác nhận cam kết.

Sponsor từng thúc đẩy dự án ở giai đoạn khởi động, nhưng nay thường vắng mặt trong cuộc họp. Các trưởng bộ phận vẫn nói ủng hộ, trong khi lịch kiểm thử của người dùng liên tục bị đẩy lùi. Project Manager tăng tần suất gửi báo cáo, song những quyết định đang chờ vẫn chưa có người chốt.

Trong tình huống minh họa giả định này, dấu hiệu mất cam kết xuất hiện trước khi ai đó tuyên bố phản đối. Vấn đề có thể nằm ở ưu tiên kinh doanh đã đổi, lợi ích chưa thuyết phục hoặc gánh nặng triển khai được phân bổ không công bằng. Muốn duy trì đồng thuận, lãnh đạo dự án phải hiểu điều gì đã thay đổi trong lý do tham gia của từng bên.

Cam kết ban đầu có thể mất cơ sở khi dự án tiến triển

Ở thời điểm phê duyệt, dự án thường được nhìn qua mục tiêu và lợi ích tương lai. Khi triển khai, những yêu cầu cụ thể mới xuất hiện: cung cấp nhân sự nghiệp vụ, quyết định ngoại lệ, làm sạch dữ liệu, chấp nhận gián đoạn và thay đổi quyền kiểm soát. Một trưởng bộ phận có thể đồng ý với mục tiêu nhưng chưa từng đồng ý với khối lượng công việc mà mục tiêu ấy đòi hỏi.

Bối cảnh kinh doanh cũng có thể thay đổi. Mục tiêu tăng trưởng được điều chỉnh, người bảo trợ chuyển vai trò hoặc một sự cố vận hành buộc lãnh đạo dành sự chú ý sang nơi khác. Nếu nhóm dự án tiếp tục dùng lập luận khởi động, người nghe sẽ cảm thấy báo cáo không phản ánh thực tế. Sự vắng mặt lúc này có thể là dấu hiệu cần đánh giá lại mức ưu tiên, thay vì một vấn đề chỉ giải quyết bằng nhắc lịch.

Cần phân biệt mất thời gian tham gia với mất niềm tin vào dự án. Người vẫn ủng hộ có thể ủy quyền được nếu quyền hạn rõ; người không còn tin vào lợi ích sẽ khó cam kết dù cuộc họp được sắp xếp thuận tiện. Project Manager nên trao đổi trực tiếp về điều đang cản trở và kiểm tra bằng hành vi: quyết định có được đưa ra, nguồn lực có được bố trí, cam kết trước đó có được hoàn thành không?

Năng lực lãnh đạo dự án IT bao gồm việc nhận biết những thay đổi này trước khi chúng thành trì hoãn lớn. Khi lý do mất cam kết đã được phân biệt, việc lập danh sách bên liên quan cũng cần đi sâu hơn sơ đồ chức danh và quyền lực.

Nhìn bên liên quan qua tác động họ phải gánh chịu

Stakeholder engagement — sự tham gia và tương tác với các bên liên quan — cần xem cả người quyết định lẫn người bị thay đổi cách làm việc. APM mô tả đây là một quá trình nhận diện, phân tích, lập kế hoạch và thực hiện hành động có hệ thống. Trong dự án IT, một nhân viên vận hành không có quyền phê duyệt vẫn có thể nắm chi tiết quyết định tính khả thi của quy trình mới.

Bản đồ bên liên quan nên ghi rõ mỗi nhóm kỳ vọng điều gì, phải đóng góp gì và có thể mất điều gì. Bộ phận bán hàng có thể nhận thông tin nhanh hơn nhưng phải nhập dữ liệu chuẩn ngay từ đầu. Kế toán có thể giảm đối soát nhưng phải tham gia kiểm thử nhiều ngoại lệ. Nếu chỉ trình bày lợi ích mà không thừa nhận công sức chuyển đổi, nhóm dự án sẽ khó giải thích phản ứng của họ.

Bảng sau giúp chuẩn bị cuộc trao đổi theo vấn đề thực tế. Đây là công cụ gợi ý; mức tham gia phải điều chỉnh theo quy mô, quyền hạn và giai đoạn của dự án.

Nhóm liên quan	Mối quan tâm cần xác minh	Cam kết có thể quan sát
Sponsor	Lợi ích và ưu tiên đầu tư còn phù hợp?	Chốt quyết định vượt quyền dự án
Chủ quy trình	Ai chịu việc chuyển đổi và ngoại lệ?	Cử người có quyền xác nhận nghiệp vụ
Quản lý nguồn lực	Khối lượng dự án xung đột công việc nào?	Bố trí khoảng thời gian cụ thể
Người dùng chủ chốt	Quy trình mới gây khó ở bước nào?	Kiểm thử tình huống và phản hồi lỗi
Vận hành IT	Điều kiện tiếp nhận đã đủ chưa?	Xác nhận hỗ trợ, giám sát và phục hồi

Sau khi lập bản đồ, cần kiểm tra với chính những người được mô tả. Nhận định “phòng ban này chống thay đổi” thường quá rộng và dễ khiến đối thoại trở nên phòng thủ. Một trở ngại cụ thể như thiếu người kiểm thử hoặc chưa rõ trách nhiệm xử lý lỗi sẽ tạo cơ hội thương lượng. Chính các trở ngại ấy quyết định nội dung cuộc trao đổi tiếp theo.

Tìm hiểu phản đối trước khi tìm cách thuyết phục

Project Manager nên hỏi bên liên quan về một tình huống công việc mà họ cho rằng giải pháp chưa xử lý được. Nếu người dùng nói hệ thống khó dùng, cần quan sát họ hoàn thành nhiệm vụ nào, dữ liệu có sẵn hay chưa và phải chuyển giữa bao nhiêu màn hình. Tranh luận về mức độ thân thiện của phần mềm sẽ ít hữu ích hơn việc nhìn một giao dịch bị bỏ dở.

Một số phản đối là tín hiệu chất lượng. Chủ quy trình có thể phát hiện ngoại lệ chưa được thiết kế; vận hành có thể nhận ra kế hoạch phục hồi chưa thực hiện được; tài chính có thể thấy giả định lợi ích quá lạc quan. Nhóm dự án cần đưa những phản hồi có căn cứ vào quản lý yêu cầu và rủi ro. Duy trì đồng thuận không đòi hỏi mọi người phải ngừng nêu vấn đề.

Những phản đối khác liên quan đến quyền lợi và trách nhiệm. Quy trình mới có thể chuyển quyền phê duyệt, làm rõ năng suất hoặc buộc một bộ phận chịu trách nhiệm dữ liệu mà trước đây chưa ai nhận. Project Manager không thể tự quyết tất cả sự thay đổi này. Cần đưa đúng vấn đề đến Sponsor hoặc người có thẩm quyền, kèm ảnh hưởng kinh doanh và những lựa chọn khả thi.

Đối thoại cần được ghi nhận thành hành động có người phụ trách và thời hạn. Năng lực quản lý đội ngũ IT hỗ trợ việc thương lượng khối lượng, quyền hạn và giới hạn nguồn lực. Khi các trở ngại đã rõ, báo cáo dự án phải chuyển chúng thành thông tin giúp lãnh đạo quyết định.

Thiết kế tương tác quanh quyết định, thay vì quanh lịch báo cáo

Một báo cáo tình trạng có nhiều số liệu chưa chắc khiến Sponsor tham gia. Người bảo trợ cần biết dự án đang bảo vệ mục tiêu nào, điều gì làm mục tiêu đó có nguy cơ và quyết định của họ sẽ thay đổi kết quả ra sao. Khi mọi vấn đề được đặt chung trong một báo cáo dài, quyết định quan trọng có thể bị chìm giữa những việc đội dự án đã tự xử lý được.

Có thể tách cuộc trao đổi về quyết định khỏi cuộc cập nhật vận hành. Đề nghị quyết định nên nêu lựa chọn, phương án thay thế, tác động tới lợi ích, nguồn lực và thời điểm cần chốt. Nếu chưa đủ dữ liệu để lựa chọn, cần xin phép làm rõ bằng chứng hoặc tổ chức thử nghiệm. Việc yêu cầu Sponsor quyết định trong một khoảng thời gian không thực tế sẽ làm tăng khả năng trì hoãn hoặc trả lời hình thức.

Tần suất và hình thức tương tác phải phù hợp nhóm liên quan. Người dùng cần nhìn được quy trình hoặc sản phẩm để phản hồi; tài chính cần hiểu thay đổi chi phí; vận hành cần tham gia các buổi kiểm tra điều kiện tiếp nhận. Không nên gửi cùng một thông điệp rồi coi lượt đọc là bằng chứng đồng thuận. Một cuộc trình diễn có phản hồi cụ thể thường cho biết nhiều hơn email khẳng định tiến độ.

Năng lực lãnh đạo công nghệ ở cấp doanh nghiệp giúp gắn cuộc trao đổi với ưu tiên của Ban điều hành. Khi lãnh đạo thấy rõ quyết định của mình, cam kết cần được chuyển thành những thỏa thuận thực tế có thể theo dõi, thay vì dừng ở sự đồng ý trong phòng họp.

Khôi phục cam kết bằng thỏa thuận nhỏ nhưng cụ thể

Quay lại tình huống giả định ở mở bài, Project Manager cần làm rõ vì sao lịch kiểm thử bị đẩy. Nếu phòng kinh doanh đang vào mùa cao điểm, đề nghị bố trí một nhóm nhỏ kiểm tra những luồng thiết yếu có thể thực tế hơn yêu cầu toàn bộ nhân sự tham gia ngay. Phần còn lại cần được lập lịch lại và đánh giá tác động, chứ không ngầm coi đã kiểm thử đầy đủ.

Thỏa thuận mới phải có phạm vi đóng góp, người được giao quyền và điều kiện thay đổi. Một chủ quy trình có thể cử đại diện, nhưng đại diện ấy cần biết được phép xác nhận gì và khi nào phải hỏi lại. Nếu mọi câu trả lời vẫn phụ thuộc người không tham dự, việc thay người chỉ chuyển địa điểm của nút thắt. Cam kết nguồn lực cũng phải phản ánh lịch làm việc có thể thực hiện.

Nếu bối cảnh đã làm lợi ích dự án giảm đáng kể, cần cập nhật Business Case và trình lại lựa chọn. Khôi phục cam kết bằng cách che rủi ro hoặc giữ nguyên lời hứa cũ sẽ làm suy giảm niềm tin về sau. Dự án có thể được thu hẹp, hoãn một phần hoặc chuyển cách triển khai. Sự đồng thuận đáng tin cậy phải dựa trên quyết định mà các bên hiểu và chấp nhận được.

Một sổ cam kết gọn có thể ghi việc đã thống nhất, người chịu trách nhiệm, thời hạn, bằng chứng hoàn tất và trở ngại. Chỉ giữ những cam kết quan trọng để tránh tạo thêm công việc hành chính. Từ những thỏa thuận này, nhóm dự án cần theo dõi dấu hiệu suy giảm đủ sớm để không phải liên tục khôi phục đồng thuận khi khủng hoảng đã xảy ra.

Theo dõi sức khỏe đồng thuận đến sau bàn giao

Dấu hiệu cần chú ý gồm quyết định lặp lại mà chưa được chốt, người có quyền xác nhận liên tục vắng mặt, nguồn lực bị rút không có thay thế và phản hồi người dùng không được xử lý. Các dấu hiệu này cần xem theo nguyên nhân và xu hướng. Một cuộc họp bị hủy chưa đủ để kết luận Sponsor mất cam kết; nhiều cam kết không thực hiện trong cùng giai đoạn lại đáng được trao đổi trực tiếp.

Trong mỗi mốc quan trọng, Project Manager nên kiểm tra mục tiêu còn phù hợp, chủ sở hữu lợi ích còn nhận trách nhiệm và các bộ phận tiếp nhận đã sẵn sàng. Một dự án có thể nhận đủ chữ ký nghiệm thu nhưng thiếu cam kết thay đổi quy trình sau bàn giao. Khi đó, báo cáo hoàn thành sẽ không bảo vệ được lợi ích ban đầu. Việc tiếp nhận cần bao gồm trách nhiệm xử lý ngoại lệ và thời điểm đánh giá kết quả.

Liên kết với năng lực quản lý dịch vụ IT giúp dự án đưa người vận hành và sử dụng dịch vụ vào quá trình chuẩn bị. Đào tạo, hỗ trợ và kênh phản hồi sau chuyển đổi cần có chủ sở hữu cụ thể. Người dùng sẽ khó duy trì cách làm mới nếu những vướng mắc đầu tiên không có nơi giải quyết.

Bước thực hành phù hợp là chọn ba cam kết đang quyết định tiến độ, trao đổi lại với người chịu trách nhiệm và xác nhận điều kiện thực hiện trong giai đoạn tới. Duy trì đồng thuận là việc liên tục kiểm tra lý do tham gia, gánh nặng chuyển đổi và quyền quyết định. Nhờ đó, sự ủng hộ ban đầu có thể trở thành hành động đủ bền để dự án tạo được kết quả.