Thiết lập Dashboard điều hành dự án IT phục vụ các cuộc họp Steering Committee.

Bắt đầu bằng những việc ban chỉ đạo phải chốt

Ban chỉ đạo có thể cần duyệt thay đổi lớn, giải quyết nguồn lực liên phòng ban, xem lại lợi ích hoặc quyết định điều kiện chuyển giai đoạn. Không phải cuộc họp nào cũng có cùng nhu cầu. Dashboard cần phản ánh quyền được giao và giai đoạn hiện tại, thay vì mặc định mọi chỉ số quản lý hằng ngày đều phải xuất hiện trước lãnh đạo.

Một cách thiết kế là lấy vài quyết định thường bị chậm để tìm thông tin còn thiếu. Nếu ban không chốt được bổ sung ngân sách, có thể thiếu dự toán hoàn tất hoặc phương án giảm phạm vi. Nếu không chốt được go-live, có thể thiếu tình trạng dữ liệu, hỗ trợ và rủi ro còn lại. Phần dữ liệu này cần được bổ sung vào cơ chế báo cáo, không chỉ thay màu hoặc hình dạng biểu đồ.

Năng lực lãnh đạo dự án IT giúp nối trách nhiệm ban chỉ đạo với thông tin cần trình. APM, trong tài liệu về governance, xem báo cáo và kiểm soát là các hoạt động hỗ trợ người bảo trợ và lãnh đạo nắm tiến triển. Trong thực hành, dashboard cần làm rõ quyết định nào đội dự án đã xử lý và quyết định nào đang cần cấp cao hơn.

Một trang tổng quan phải kể cùng một câu chuyện dự báo

Trang tổng quan nên nêu mục tiêu và phạm vi được duyệt, mốc dự kiến mới nhất, chi phí dự báo hoàn tất và mức sẵn sàng của sản phẩm. Các chỉ số phải sử dụng cùng phiên bản phạm vi. Nếu lịch đã bỏ một phần chức năng nhưng chi phí và lợi ích vẫn tính theo kế hoạch cũ, bảng tổng quan sẽ cho người đọc một bức tranh không thể xảy ra trong thực tế.

Cần phân biệt số đã thực hiện với số dự báo. Giải ngân thấp chưa chứng minh tiết kiệm; công việc có thể chậm hoặc hóa đơn chưa ghi nhận. Tỷ lệ hoàn thành cao chưa chứng minh gần go-live nếu kiểm thử đầu cuối còn mở. Người đọc nên thấy mức thay đổi so với cam kết, nguyên nhân chính và độ tin cậy của dự báo, thay vì chỉ thấy một trạng thái tại ngày cập nhật.

Bảng dưới đây là cấu trúc đề xuất cho trang tổng quan. Nó là cách tổ chức thông tin, không phải mẫu chỉ số bắt buộc cho mọi dự án.

Không nên ép tất cả chi tiết vào trang đầu. Mỗi vùng có thể dẫn tới phụ lục hoặc hồ sơ bằng chứng. Trang tổng quan đủ để xác định điều cần xem sâu, còn người thẩm tra vẫn có thể kiểm tra cơ sở của nhận định. Khi cấu trúc đã rõ, việc định nghĩa chỉ số phải ngăn những cách hiểu khác nhau giữa các bộ phận.

Định nghĩa chỉ số trước khi đặt màu trạng thái

Mỗi chỉ số cần có ý nghĩa, phạm vi, nguồn dữ liệu, người cập nhật và thời điểm chốt số. Một mốc được ghi đã hoàn thành phải cho biết đã có sản phẩm, đã kiểm tra hay đã được nghiệm thu. Chi phí cần xác định có bao gồm nguồn lực nội bộ và khoản đang cam kết không. Thiếu những định nghĩa này, các nhóm có thể cập nhật đúng cách tính riêng mà tổng báo cáo vẫn sai.

Ngưỡng màu nên gắn với quyền xử lý và hậu quả. Màu đỏ có thể biểu thị vượt giới hạn cần trình, nhưng mức giới hạn phải do doanh nghiệp thống nhất. Không nên lấy một số ngày trễ cố định cho mọi loại mốc. Chậm một mốc còn dư thời gian khác với chậm cửa sổ chuyển hệ thống chỉ có thể thực hiện ở một thời điểm nhất định.

Người cập nhật cần giữ ngày dữ liệu và mức tin cậy. Một số liệu chưa đối soát nên được đánh dấu đang xác minh, không trình như kết quả đã xác nhận. Năng lực quản lý hoạt động và nguồn lực IT hỗ trợ thống nhất dữ liệu từ đội chức năng. Khi chỉ số có cùng cách hiểu, dashboard mới có thể biểu đạt thay đổi qua thời gian.

Thể hiện xu hướng và điều kiện thay vì chỉ một ảnh chụp trạng thái

Một dự báo trễ có thể đáng lo hơn nếu tiếp tục lùi qua nhiều kỳ. Ngược lại, một chỉ số xấu nhưng đang cải thiện theo biện pháp đã kiểm tra có thể chưa cần đổi chiến lược. Dashboard nên nêu biến động và nguyên nhân, tập trung vào những yếu tố quyết định mốc hoặc lợi ích. Không cần thêm biểu đồ cho mọi số liệu chỉ vì công cụ hỗ trợ.

Khi bất định còn lớn, có thể trình khoảng dự báo cùng điều kiện. Mốc sớm cần dữ liệu được xác nhận và nguồn lực đối tác sẵn sàng; mốc muộn phản ánh khả năng phải làm lại một phần tích hợp. Khoảng này không nên được dùng để tránh cam kết. Nó cần thu hẹp khi bằng chứng tăng và được giải thích nếu vẫn rộng ở giai đoạn gần bàn giao.

Cần chỉ ra những rủi ro liên quan nhau. Chậm dữ liệu có thể làm chậm kiểm thử, tăng công sức đối soát và giảm thời gian đào tạo. Ba chỉ số riêng cùng vàng có thể phản ánh một nguyên nhân đang đe dọa toàn bộ chuyển đổi. APM về project controls nhấn mạnh việc lập kế hoạch, theo dõi và phản ứng trước sai lệch; dashboard nên giúp lãnh đạo nhìn quan hệ này để chọn đúng điểm can thiệp.

Năng lực kiểm soát dự án CNTT cung cấp cơ sở cho các dự báo. Nếu kết quả tính không khớp trải nghiệm thực hiện của nhóm, cần điều tra dữ liệu và giả định trước cuộc họp. Một bảng đẹp không sửa được kế hoạch thiếu tính khả thi hoặc định nghĩa hoàn thành chưa nhất quán.

Tổ chức cuộc họp quanh các quyết định có thời hạn

Dashboard nên gửi đủ sớm để thành viên đọc và hỏi làm rõ. Project Manager cần mở cuộc họp bằng những thay đổi trọng yếu và đề nghị quyết định, không đọc lần lượt mọi dòng. Hồ sơ của một quyết định phải có vấn đề, lựa chọn, tác động, khuyến nghị và thời hạn. Phần chưa biết cần được nêu cùng cách làm rõ, tránh buộc ban chỉ đạo chốt dưới một giả định chưa được nhận diện.

Tình huống minh họa giả định: dự án vẫn dự báo đúng hạn nhưng thiếu người nghiệp vụ để kiểm thử ngoại lệ. Dashboard chỉ ghi tiến độ xanh sẽ không tạo lý do bố trí người. Khi thể hiện rằng mốc vận hành phụ thuộc việc kiểm thử trước một ngày cụ thể, ban chỉ đạo có thể chọn điều chuyển nguồn lực, giảm phạm vi hoặc đổi mốc. Các lựa chọn này cần được trình cùng tác động đến hoạt động kinh doanh.

Sau cuộc họp, quyết định phải được chuyển vào kế hoạch và dashboard kỳ sau. Ghi người chốt, người thực hiện, điều kiện và thời điểm kiểm tra. Nếu cấp ngân sách đã đồng ý nhưng nhân sự chưa được huy động, trạng thái không thể tự đổi sang đã xử lý. Việc theo dõi hành động giúp dashboard trở thành công cụ điều hành liên tục, thay vì chỉ là tài liệu họp định kỳ.

Giữ dashboard đủ gọn để dùng và đủ sâu để kiểm tra

Có thể rà soát mỗi vùng báo cáo bằng câu hỏi: nếu bỏ thông tin này, quyết định nào sẽ khó hơn? Những chỉ số không dẫn tới lựa chọn hoặc không cho thấy biến động có thể chuyển xuống phụ lục. Một bảng điều hành gọn không có nghĩa bỏ tin xấu; nó cần giữ rõ các điểm có tác động lớn và những quyết định chưa được giải quyết.

Các phần liên quan vận hành cần có đại diện tiếp nhận xác nhận. Năng lực quản lý dịch vụ IT giúp đưa hỗ trợ, giám sát và phục hồi vào trạng thái sẵn sàng. Cần giữ quyền truy cập và lịch sử báo cáo phù hợp để người có trách nhiệm kiểm tra được thay đổi, không làm lộ dữ liệu nhạy cảm chỉ vì muốn chia sẻ rộng.

Trước khi xây công cụ mới, hãy thử cấu trúc trên với một kỳ họp thật và vài quyết định trọng yếu. Xem người đọc có hiểu cùng một dự báo, có hỏi đúng phần bằng chứng và có chốt được hành động không. Sửa định nghĩa và dòng thông tin trước khi tự động hóa. Khi dashboard giúp ban chỉ đạo lựa chọn trên cùng một bức tranh, giá trị của nó sẽ nằm ở chất lượng quyết định thay vì số biểu đồ xuất hiện.

Bài viết liên quan

• Rủi ro dự án nào đáng báo cáo Ban điều hành? Nhìn từ tác động kinh doanh
• Khi dự án liên tục trễ tiến độ: Phương pháp đánh giá nguyên nhân và tái lập kế hoạch.
• Kiểm soát chất lượng sản phẩm bàn giao và xác định điều kiện nghiệm thu ở cấp quản trị.
• Tiến độ, ngân sách và chất lượng cùng bị đe dọa: Ra quyết định trong khủng hoảng

Nguồn tham khảo

1. APM — What is project controls?
2. APM — What is governance?
3. UK Government — Government Functional Standard GovS 002: Project Delivery