Danh mục dự án IT quá tải: Chọn ưu tiên chiến lược và điều phối nguồn lực thế nào?

Đếm năng lực thực hiện trước khi đếm số dự án

Một danh mục có ít dự án vẫn có thể quá tải nếu tất cả cần cùng chuyên gia, cùng môi trường kiểm thử hoặc cùng chủ dữ liệu. Ngược lại, nhiều dự án nhỏ độc lập có thể được triển khai ổn định. Vì thế, tổng số dự án hoặc tổng nhân sự không phản ánh đầy đủ nút thắt.

Nhóm cần lập hồ sơ nhu cầu theo kỹ năng và thời điểm. Dự án cần bao nhiêu công phân tích nghiệp vụ, kiểm tra bảo mật, tích hợp và thử nghiệm? Người dùng chủ chốt có thể tham gia lúc nào? Các cửa sổ triển khai có trùng mùa cao điểm hoặc kỳ quyết toán không? Những câu hỏi ấy thường phát hiện giới hạn mà kế hoạch theo số lượng người bỏ qua.

Công suất khả dụng phải trừ công việc vận hành, hỗ trợ, nghỉ phép và phần dự phòng phù hợp lịch sử. Không dùng toàn bộ thời gian danh nghĩa để cam kết dự án. Khi không có khoảng xử lý phát sinh, một sự cố vận hành sẽ lan sang nhiều kế hoạch. Mức dự phòng cần dựa vào dữ liệu và loại công việc, không áp một tỷ lệ giống nhau cho mọi nhóm.

APM mô tả quản trị danh mục gắn với mục tiêu chiến lược và năng lực thực hiện của tổ chức. Điều này giúp đặt năng lực triển khai ngang hàng với giá trị kỳ vọng. Một dự án hấp dẫn nhưng chưa có nguồn lực không trở thành khả thi chỉ vì đạt điểm cao trong bảng xếp hạng.

Phân biệt việc bắt buộc với việc được ưu tiên

Một số dự án xuất phát từ nghĩa vụ, rủi ro hoặc nhu cầu duy trì hoạt động. Những việc này cần được xác minh về phạm vi và thời hạn bắt buộc. Không nên để mọi Sponsor gắn nhãn bắt buộc cho đề xuất của mình; cũng không nên loại một việc cần thiết chỉ vì khó quy đổi thành doanh thu.

Với nhóm đầu tư có thể lựa chọn, tiêu chí nên nối với chiến lược: vấn đề kinh doanh, mức tác động, thời điểm cần có năng lực, bằng chứng nhu cầu, khả năng thực hiện và rủi ro. Chọn ít tiêu chí đủ phân biệt, có mô tả mức điểm. Bảng điểm dài với nhiều tiêu chí gần giống nhau dễ tạo ra cảm giác chính xác nhưng vẫn dựa trên cảm nhận.

Trọng số do lãnh đạo thống nhất trước khi chấm. Mỗi điểm cần có giải thích và bằng chứng, cùng mức tin cậy của giả định. Một đề xuất có lợi ích cao nhưng dữ liệu yếu nên được xem như cơ hội cần kiểm chứng, không ngang với lợi ích đã có đường cơ sở. Có thể cấp một giai đoạn khảo sát nhỏ thay vì tài trợ toàn bộ.

Bảng dưới đây là một công cụ sàng lọc đề xuất, không phải mô hình chấm điểm của một tiêu chuẩn. Nó giúp đội dự án chuẩn bị cuộc đối thoại với cấp quản trị danh mục.

Một dự án không vượt sàng lọc khả thi cần điều chỉnh, dù phù hợp chiến lược. Bảng điểm là đầu vào cho quyết định, không thay quyền cân nhắc của lãnh đạo. Khả năng giải thích điều này thuộc tư duy quản trị đầu tư công nghệ, đặc biệt khi các đơn vị đều có lý do chính đáng để đòi ưu tiên.

Chọn một tổ hợp dự án thay vì một danh sách điểm cao

Danh mục tốt không nhất thiết gồm những dự án đứng đầu bảng điểm. Dự án dữ liệu nền có thể lợi ích trực tiếp thấp nhưng là điều kiện cho nhiều sáng kiến. Hai dự án riêng lẻ hấp dẫn có thể trùng cùng nhóm người dùng và gây quá tải thay đổi. Một dự án có thể tạo lựa chọn mới hoặc giảm phụ thuộc cho tổ chức.

Nhóm cần lập bản đồ phụ thuộc: đầu ra nào phải có trước, nguồn lực nào được dùng chung và thời điểm nào không thể trùng. Sau đó thử các tổ hợp khác nhau. Khi chuyển lịch một dự án, cập nhật cả tác động đến những dự án dựa vào nó. Nếu chỉ đổi một dòng trên lịch, tổ chức có thể tạo ra những cam kết mới không thực hiện được.

Tình huống minh họa giả định: một doanh nghiệp cân nhắc cổng khách hàng, phân tích dữ liệu bán hàng và chuẩn hóa mã sản phẩm. Hai sáng kiến đầu dễ nhận tài trợ hơn vì kết quả nhìn thấy rõ. Nhưng nếu mã sản phẩm không nhất quán, cả hai phải xử lý thủ công hoặc làm lại tích hợp. Lãnh đạo có thể ưu tiên một phần công việc dữ liệu trước, trong khi giới hạn phạm vi thử nghiệm của cổng khách hàng.

Đây là lựa chọn minh họa, chưa phải kết quả được kiểm chứng. Nó cho thấy ưu tiên cần tính cả trình tự tạo năng lực. Người học lãnh đạo dự án IT cần hiểu cách trình phụ thuộc để cấp danh mục quyết định, đồng thời tránh tự giành nguồn lực từ các dự án khác vì mục tiêu cục bộ.

Biến ưu tiên thành quyền sử dụng nguồn lực

Một quyết định ưu tiên chỉ có hiệu lực khi thể hiện trong lịch và cam kết của quản lý chức năng. Dự án đứng đầu nhưng vẫn phải tranh người hằng tuần chưa được ưu tiên thực sự. Cần ghi năng lực được cấp theo giai đoạn, điều kiện điều chuyển và người có quyền thay cam kết.

Nếu nhu cầu vượt công suất, tổ chức có vài lựa chọn: đổi trình tự, thu hẹp phạm vi, phát triển năng lực, thuê hỗ trợ hoặc hoãn dự án. Mỗi phương án có giới hạn. Thuê thêm người chưa chắc giải quyết được nút thắt nếu công việc cần kiến thức hệ thống mà chỉ nhân viên nội bộ có. Tăng nhân sự có thể làm tăng công hướng dẫn và kiểm tra trong thời gian đầu.

PMO, tức bộ phận quản lý dự án, có thể tập hợp dữ liệu tải và theo dõi cam kết. Quản lý chức năng xác nhận năng lực khả dụng; cấp danh mục chốt đánh đổi. Quản lý bộ phận IT vì vậy là một phần của cơ chế ưu tiên, không chỉ là nơi cung cấp tên người cho bảng kế hoạch.

Rà soát danh mục khi điều kiện đầu tư thay đổi

Danh mục không nên bị khóa chỉ vì kế hoạch đã được phê duyệt đầu năm. Nhu cầu, rủi ro, năng lực và phụ thuộc có thể thay đổi. Tuy nhiên, rà soát không có nghĩa đảo ưu tiên theo mọi yêu cầu mới. Cần có chu kỳ phù hợp và điều kiện kích hoạt ngoài chu kỳ, chẳng hạn mất nguồn lực thiết yếu hoặc giả định lợi ích bị bác bỏ.

Mỗi dự án nên có trạng thái rõ: đang triển khai, được phép chuẩn bị, chờ điều kiện, hoãn hoặc dừng. Với trạng thái chờ, ghi điều kiện để được xét lại. Nếu không, danh sách chờ sẽ trở thành các cam kết ngầm và đơn vị kinh doanh vẫn kỳ vọng IT bắt đầu. Dừng dự án cũng cần kế hoạch bảo quản tài sản, hồ sơ và giải quyết nghĩa vụ đang mở.

Đánh giá tiếp tục dự án dựa trên lợi ích còn lại, chi phí sắp phát sinh và rủi ro từ thời điểm quyết định. Khoản tiền đã chi không tự tạo lý do để đầu tư tiếp. Nhưng chi phí chấm dứt, nghĩa vụ hợp đồng và tác động phụ thuộc phải được tính, tránh coi dừng là phương án không có chi phí.

Một cuộc rà soát có chất lượng cần người trình bày được những lựa chọn ấy. Năng lực lập kế hoạch và kiểm soát dự án giúp cung cấp dự báo đáng tin, còn quyết định phân bổ phải giữ góc nhìn toàn tổ chức. Điểm cao không bảo vệ một dự án khỏi việc xem lại khi hoàn cảnh đã đổi.

Làm cho quyết định chưa triển khai có thể giải thích

Khi hoãn một dự án, lãnh đạo cần giải thích lý do bằng tiêu chí và giới hạn thực tế. Đơn vị đề xuất nên biết điều gì đã được xem xét, cơ hội nào bị chậm và bằng chứng nào giúp đề xuất được xét lại. Sự rõ ràng giảm áp lực tìm đường đi riêng hoặc đặt mua giải pháp ngoài danh mục.

Có thể bắt đầu bằng một cuộc rà soát ngắn với ba hồ sơ: nhu cầu kỹ năng theo thời điểm, bản đồ phụ thuộc và các dự án đã được cấp quyền sử dụng năng lực. Từ đó xác định phần cam kết vượt khả năng rồi trình các tổ hợp thay thế. Dữ liệu đủ tốt để lựa chọn hữu ích hơn một bảng tải chi tiết nhưng không dẫn tới quyết định.

Với danh mục quá tải ở đầu bài, việc cần làm trước không phải yêu cầu chuyên gia tích hợp tăng tốc cho tất cả. Đó là chốt dự án nào được dùng năng lực ở giai đoạn hiện tại và dự án nào phải đổi lịch. Khi tổ chức lựa chọn rõ, đội IT mới có thể hoàn thành những ưu tiên đã nhận thay vì liên tục chuyển đổi giữa các cam kết xung đột.

Bài viết liên quan

• Thiết lập Project Governance: Phân định quyền quyết định giữa Sponsor, Steering Committee và Project Manager.
• Xây dựng Business Case để đánh giá hiệu quả đầu tư trước khi phê duyệt dự án IT.
• Thiết lập cơ chế Stage-Gate để kiểm soát các quyết định đầu tư và triển khai dự án.
• Điều phối nguồn lực giữa nhiều dự án: Giải quyết xung đột ưu tiên trong tổ chức IT.

Nguồn tham khảo

1. APM — What is portfolio management?
2. APM — What is resource management?
3. UK Government — Government Functional Standard GovS 002: Project Delivery