Khi người bảo trợ dự án nghỉ việc giữa chừng: FDE giữ deployment sống bằng cách nào

Hãy hình dung bạn đang ở tuần thứ sáu triển khai một agent đối soát hóa đơn cho một công ty phân phối. Chiều thứ Sáu, chị giám đốc tài chính, người đã kéo dự án vào công ty và ký duyệt phạm vi, nhắn rằng chị sẽ nghỉ vào cuối tháng.

Sáng thứ Hai, team kế toán vẫn họp với bạn như thường lệ. Nhưng không ai nói được ai sẽ duyệt quyền truy cập ERP còn đang treo, và ai sẽ ký nghiệm thu.

Đây là một trong những tình huống khó nhất của nghề FDE, và nó chẳng liên quan gì đến code. Theo SaaStr, khi champion rời đi, bạn gần như phải bắt đầu lại từ đầu với khách hàng đó.

Khảo sát của PMI năm 2018 cũng cho thấy cứ bốn tổ chức thì có một (26%) coi việc sponsor hỗ trợ không đủ là nguyên nhân chính khiến dự án thất bại.

FDE làm việc sát với team của khách hàng, nên rất có thể bạn là người đầu tiên nhận ra dự án vừa mất chỗ dựa. Nếu vậy, đừng chờ người khác lên tiếng: bạn có đủ thông tin để bắt đầu hành động.

Người đứng tên chưa chắc là người bảo trợ

Ricardo Vargas, người viết nhiều về quản trị dự án, khuyên rằng việc đầu tiên khi sponsor rời đi là đừng nhầm sponsor trên danh nghĩa với sponsor đang thật sự hành động. Sau khi chị giám đốc tài chính nghỉ, gần như chắc chắn sẽ có một người được giao “tạm phụ trách”. Tên người đó trên sơ đồ tổ chức chưa nói lên điều gì.

Hãy thử người đó bằng ba câu hỏi. Họ có gỡ được blocker đang treo không, ví dụ quyền truy cập ERP? Họ có điều được người, chẳng hạn kéo một kế toán viên ra làm việc với bạn hai buổi mỗi tuần?

Họ có dám đứng ra nghiệm thu trước ban giám đốc không? Nếu cả ba câu đều là “để tôi hỏi lại”, thì dự án của bạn đang không có sponsor.

Sự phân biệt này quan trọng vì dữ liệu của PMI cho thấy một mối tương quan rõ. Những tổ chức có sponsor tích cực ở hơn 80% dự án có số dự án thành công nhiều hơn 40% so với nhóm chỉ có ở dưới 50% dự án.

Con số này chỉ cho thấy hai thứ thường đi cùng nhau, chưa chứng minh cái này dẫn đến cái kia. Dù vậy, nó đủ để bạn không dễ dãi khi đánh giá người thay thế.

Một bài tự kiểm tra nhanh cho dự án bạn đang làm: liệt kê ba blocker gần nhất đã được gỡ, rồi ghi ai là người gỡ từng cái. Nếu cả ba đều mang cùng một tên, dự án của bạn đang treo vào một người, và bạn biết mình phải bắt đầu từ đâu.

Ghi rủi ro ra giấy, đừng chỉ nói nhỏ với nhau

Phản xạ tự nhiên của kỹ sư là cứ cắm đầu làm tiếp và hy vọng mọi chuyện tự ổn. Vargas cho rằng việc mất sự tham gia của sponsor phải được ghi nhận rõ ràng như một rủi ro, thay vì chỉ được bàn tán ngoài hành lang. SaaStr cũng nhắc rằng bất ngờ là cách nhanh nhất để đánh mất lòng tin, nên minh bạch là then chốt.

Cụ thể, bạn đưa một mục như sau vào risk register hoặc biên bản họp tuần:

Rủi ro: Mất sponsor dự án (GĐ Tài chính nghỉ cuối tháng)
Tác động: Chưa có người duyệt quyền truy cập ERP và ký nghiệm thu giai đoạn 1
Dấu hiệu hiện tại: 2 yêu cầu đang chờ duyệt, chưa có người thay thế chính thức
Đề xuất: Chỉ định sponsor mới trước ngày X; tạm thời có người được ủy quyền duyệt
Người cần quyết: Ban điều hành dự án / cấp trên trực tiếp của sponsor cũ

Mẫu này chỉ mô tả sự việc và tác động, không phán xét ai. Nó cũng biến một nỗi lo mơ hồ thành một việc cụ thể mà ai đó phải ra quyết định.

Leo thang qua quản trị, đừng leo thang bằng cảm xúc

Có risk register rồi, bạn mang nó lên đúng kênh, tức là ban điều hành dự án nếu có, hoặc cấp trên của sponsor cũ. Vargas nhấn mạnh việc này không nhằm đổ lỗi cho ai. Mục đích là bảo đảm một sáng kiến chiến lược vẫn có lãnh đạo đứng sau.

Lời mở đầu buổi họp có thể theo kịch bản như sau: “Dự án đang đúng tiến độ về kỹ thuật, nhưng tháng tới sẽ thiếu người ra quyết định. Hiện có hai việc đang chờ duyệt. Anh chị muốn ai là người chịu trách nhiệm từ giờ đến lúc nghiệm thu?” Câu cuối là câu hỏi đóng, buộc phía khách hàng phải nêu một cái tên.

Một nguyên tắc nhỏ nên giữ: luôn báo trước cho đầu mối sales hoặc account manager bên bạn trước khi leo thang. Bạn đang đòi hỏi khách hàng phải minh bạch, nên chính team của bạn cũng không nên bị bất ngờ.

Bán lại dự án như một thương vụ mới

Khi đã có người mới, cái bẫy lớn nhất là coi họ như người thừa kế đương nhiên của dự án. SaaStr gọi điều này là sống còn: hãy xem đây là một thương vụ hoàn toàn mới và bán lại giá trị cho người ra quyết định mới. Có thể họ chưa từng tham gia các buổi discovery, và rất có thể họ có ưu tiên khác.

Vì thế buổi gặp đầu tiên nên giống một buổi customer discovery thu nhỏ hơn là một buổi báo cáo tiến độ. Hãy hỏi họ bị đo bằng chỉ số nào trong quý này, rồi nối phạm vi dự án với chỉ số đó. Nếu phạm vi cũ không còn khớp, đây là lúc đàm phán lại, còn chờ đến buổi nghiệm thu thì đã muộn.

Persimmon Group khuyên rằng với một sponsor thiếu nhiệt huyết, chiến thuật đầu tiên là tạo ra quick win và làm cho chúng được nhìn thấy. Trong ví dụ đối soát hóa đơn, quick win có thể là chạy agent trên dữ liệu thật của một tháng rồi đưa ra con số trước/sau. Một con số lấy từ chính dữ liệu của họ thuyết phục hơn mọi slide.

Persimmon cũng gợi ý đừng mặc định rằng bạn bị kẹt với người được giao. Một lãnh đạo khác hưởng lợi từ dự án, ví dụ trưởng bộ phận mua hàng, có thể làm sponsor không chính thức.

Khi không ai chịu đứng ra

Đôi khi bạn đã làm đúng mọi bước mà vẫn không có ai nhận dự án. Theo Vargas, khi không dựng lại được một sponsor thật, phải đặt ra câu hỏi khó hơn: có nên tiếp tục dự án hay không.

Với FDE, đề xuất tạm dừng có kèm tài liệu bàn giao, trạng thái hệ thống và điều kiện để khởi động lại là một kết quả chuyên nghiệp chứ không phải thất bại. Điều làm hại uy tín của bạn hơn nhiều là để một hệ thống không ai chịu trách nhiệm cứ chạy tiếp, cho đến ngày bị bỏ quên.

Những phản xạ cần bỏ

Phòng ngừa từ ngày đầu

Vargas và SaaStr có chung một lời khuyên: dự án không bao giờ nên phụ thuộc hoàn toàn vào một người. Vì thế ngay từ đầu bạn cần có nhiều đầu mối trong tổ chức khách hàng.

Theo CIO.com, người quản lý dự án cần cùng sponsor giữ cho sự ủng hộ dành cho dự án được nhìn thấy liên tục từ đầu đến cuối. Với FDE, cách làm hợp lý là ngay khi dự án còn suôn sẻ, hãy đưa ít nhất hai lãnh đạo vào các buổi demo.

Khi phỏng vấn hoặc viết CV cho vị trí FDE, hãy kể kỹ năng này bằng việc cụ thể thay vì tính từ chung chung. Một dòng như “Giữ dự án qua giai đoạn đổi sponsor: lập sponsor map, leo thang qua ban điều hành, đưa quick win trong 2 tuần” có sức nặng hơn hẳn chữ “giao tiếp tốt”.

Code chạy được chỉ là một nửa của deployment. Nửa còn lại là bảo đảm vẫn có người phía khách hàng muốn nó tiếp tục chạy.