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.

Tạm ngừng việc thay ngày để xác nhận thực trạng

Trước hết cần chốt thời điểm dữ liệu và thống nhất trạng thái công việc. Một gói ghi hoàn thành có thể mới xong phát triển nhưng chưa qua tích hợp hoặc chưa được nghiệp vụ chấp nhận. Phần việc còn lại phải bao gồm sửa lỗi, kiểm thử lại, chuyển dữ liệu và tiếp nhận. Nếu những hoạt động này đang bị để ngoài lịch, dự án sẽ tiếp tục trễ ngay cả khi mọi chức năng được giao đúng dự kiến.

Cần đối chiếu kế hoạch với bằng chứng: sản phẩm thực tế, kết quả thử, lỗi còn mở và đầu vào chưa có. Không nên chỉ hỏi mỗi trưởng nhóm tỷ lệ hoàn thành, vì cách ước lượng có thể khác nhau. Người thực hiện nên giải thích việc còn phải làm và điều kiện để hoàn tất. Các trạng thái chưa kiểm tra cần được giữ là chưa xác nhận thay vì làm tròn thành đã xong.

Năng lực kiểm soát dự án CNTT cung cấp nền tảng cho bước này. GAO Schedule Assessment Guide trình bày các thực hành xây dựng và duy trì lịch đáng tin cậy; doanh nghiệp có thể tham khảo nguyên tắc gắn hoạt động, phụ thuộc, nguồn lực và cập nhật thực tế. Lịch phục hồi cần bắt đầu từ bức tranh đã xác minh, không từ mong muốn giữ một ngày mới.

Tìm cơ chế gây trễ thay vì quy lỗi cho một nhóm

Cần xem công việc đã mất thời gian ở đâu: thực hiện lâu hơn ước lượng, chờ quyết định, chờ môi trường, chờ dữ liệu hay làm lại. Mỗi cơ chế đòi hỏi biện pháp khác. Thêm lập trình viên không giải quyết việc chủ nghiệp vụ chưa xác nhận quy tắc; tăng họp không làm dữ liệu sạch hơn. Chẩn đoán cần dựa vào vài công việc cụ thể đã chậm, không chỉ vào nhận xét chung rằng đội thiếu năng lực.

Sai lệch cũng có thể bắt nguồn từ kế hoạch. Ước lượng chỉ tính thời gian thao tác nhưng bỏ qua đối soát và phản hồi; nhiều công việc dùng cùng một chuyên gia; đầu vào được giả định có sẵn. Nếu kế hoạch đã không thể thực hiện, yêu cầu nhân sự bù bằng nỗ lực sẽ khó tạo kết quả bền vững. Nhóm phải sửa giả định và cơ chế cam kết, không chỉ cập nhật thời lượng.

Bảng sau hỗ trợ phân loại nguyên nhân trước khi chọn phương án phục hồi. Một dự án có thể đồng thời có nhiều nhóm nguyên nhân và cần xử lý theo quan hệ giữa chúng.

Không cần điều tra toàn bộ lịch sử trước khi hành động. Có thể chọn những nguyên nhân đang tác động trực tiếp mốc kết thúc và những lỗi có khả năng lặp lại. Mục tiêu là giảm cơ chế tạo trễ tiếp theo, đồng thời giữ bằng chứng đủ rõ để không biến cuộc rà soát thành cuộc tranh luận về người chịu lỗi.

Đánh giá lại đường đi tới mốc bàn giao

Nhóm cần nối phần việc còn lại với phụ thuộc và nguồn lực, xác định chuỗi nào đang quyết định thời điểm kết thúc. Một hoạt động chậm nhưng còn khoảng linh hoạt khác với hoạt động làm nhiều nhóm phải chờ. Việc ưu tiên theo số lỗi hoặc phần trăm hoàn thành sẽ dễ bỏ qua những đầu việc ít nổi bật nhưng đang chặn toàn bộ kiểm thử.

Phụ thuộc cần được kiểm tra cả bên ngoài đội dự án. Người dùng chủ chốt có thể chỉ tham gia sau kỳ cao điểm; đối tác có cửa sổ triển khai riêng; môi trường phải qua cấp quyền. Mốc hoàn thành phải phản ánh các giới hạn này. Một lịch chỉ có công việc kỹ thuật và giả định tất cả người liên quan luôn sẵn sàng sẽ tiếp tục tạo cam kết thiếu cơ sở.

Năng lực quản lý nguồn lực IT hỗ trợ xác nhận công suất thực tế. Với vai trò khan hiếm, cần khoảng làm việc đủ tập trung và kế hoạch xử lý gián đoạn. Những cam kết chưa được bên quản lý nguồn lực xác nhận phải được thể hiện như giả định, không được dùng để bảo đảm ngày kết thúc.

So sánh phương án phục hồi cùng chi phí và rủi ro

Có thể đổi trình tự, tăng nguồn lực phù hợp, giảm phạm vi, triển khai theo giai đoạn hoặc thay mốc. Mỗi phương án cần xét khả năng thực hiện. Làm song song có thể giảm thời gian nhưng tăng làm lại khi thiết kế chưa ổn định. Bổ sung người cần thời gian hướng dẫn. Giảm phạm vi cần kiểm tra lợi ích và những phụ thuộc khiến phần bị hoãn vẫn phải được chuẩn bị.

Tình huống minh họa giả định: kiểm thử đầu cuối chậm do dữ liệu chuyển đổi chưa được đối soát. Nhóm đề nghị cho các đơn vị tự kiểm thử với dữ liệu tạm. Cách này có thể kiểm tra một số chức năng, nhưng không thay bằng chứng về dữ liệu vận hành. Phương án phục hồi phải tách phần kiểm thử có thể tiến hành sớm với phần cần chờ đối soát, đồng thời giữ điều kiện trước go-live.

Không nên giải quyết trễ bằng cách bỏ những bằng chứng quan trọng mà không trình tác động. Rút thời gian kiểm thử hoặc đào tạo sẽ chuyển rủi ro sang giai đoạn sử dụng. Nếu cần triển khai phạm vi giới hạn, phải có người chấp nhận, biện pháp xử lý ngoại lệ và điều kiện mở rộng. Mục tiêu là khôi phục một cam kết có thể thực hiện, không chỉ đưa báo cáo trở lại màu xanh.

Năng lực lãnh đạo dự án IT giúp trình những lựa chọn này với Sponsor và cấp có thẩm quyền. Người quyết định cần thấy tác động tới mục tiêu kinh doanh, chi phí hoàn tất và rủi ro còn lại. Một phương án nhanh hơn có thể không phải phương án tạo giá trị tốt hơn trong điều kiện hiện tại.

Phê duyệt đường cơ sở mới cùng điều kiện thực hiện

Lịch tái lập phải có phạm vi, đầu ra, người phụ trách và tiêu chí hoàn tất rõ. Ngân sách cần tính phần việc còn lại, thời gian kéo dài và công sức sửa lỗi. Cam kết của nghiệp vụ, vận hành và đối tác phải được xác nhận trước khi chốt. Những quyết định chưa có cần xuất hiện cùng thời hạn và tác động nếu chậm, thay vì được giấu trong giả định của lịch.

Cần giữ lịch cũ và giải thích thay đổi để lãnh đạo hiểu sai lệch đã tích lũy. Phê duyệt đường cơ sở mới không xóa trách nhiệm về những nguyên nhân chưa được xử lý. Tuy nhiên, cũng không nên tiếp tục đánh giá đội theo một lịch đã biết không khả thi. Đường cơ sở mới phải tạo điểm quản lý rõ cho phần công việc từ lúc quyết định.

Dự báo nên có điều kiện và mức tin cậy phù hợp. Nếu một thử nghiệm trọng yếu chưa hoàn tất, có thể cần khoảng thời gian dự kiến hoặc mốc quyết định tiếp theo. Không nên đưa một ngày chính xác để tạo cảm giác kiểm soát khi bằng chứng chưa đủ. Khoảng bất định phải thu hẹp sau hoạt động làm rõ, nếu không kế hoạch vẫn chưa giải quyết nguyên nhân.

Các cam kết phải được truyền đạt thống nhất tới những bên nhận sản phẩm. Khi lịch thay đổi nhưng doanh nghiệp vẫn lên kế hoạch hoạt động theo ngày cũ, dự án sẽ tạo rủi ro mới bên ngoài đội triển khai. Việc giao tiếp cần giúp người liên quan điều chỉnh công việc, không chỉ xác nhận họ đã nhận thông báo.

Theo dõi phục hồi bằng kết quả và dấu hiệu tái diễn

Trong giai đoạn phục hồi, nên theo dõi các đầu ra ngắn có thể kiểm chứng, thời gian chờ và nguyên nhân làm lại. Không cần tăng tần suất mọi cuộc họp. Chỉ tổ chức thêm những trao đổi giúp chốt quyết định hoặc gỡ phụ thuộc. Một chu kỳ ngắn nên cho biết điều kiện của kế hoạch đang được đáp ứng hay đang tiếp tục mất đi.

Với phần chuẩn bị vận hành, năng lực quản lý dịch vụ IT giúp giữ hỗ trợ, giám sát và phục hồi trong lịch. Những việc này dễ bị cắt khi deadline đã nhiều lần lùi, nhưng chúng quyết định khả năng sử dụng sau bàn giao. Nếu còn tồn đọng, phải có đánh giá và người tiếp nhận đúng quyền.

Bước đầu là xác minh phần việc còn lại của một mốc đang trễ, rồi chọn nguyên nhân có tác động lớn nhất để xử lý. Chỉ cam kết lịch mới khi nguồn lực, đầu vào và quyền quyết định đã được làm rõ. Dự án phục hồi khi tổ chức tạo được một cách thực hiện khác có bằng chứng, không phải khi thay ngày trên bảng kế hoạch thêm một lần.

Bài viết liên quan

• Thiết lập Dashboard điều hành dự án IT phục vụ các cuộc họp Steering Committee.
• Lãnh đạo dự án theo mô hình Agile, Waterfall và Hybrid: Lựa chọn phương pháp theo đặc điểm dự án.
• 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
• Nhà cung cấp không đạt cam kết nhưng dự án không thể dừng: Các lựa chọn điều hành

Nguồn tham khảo

1. GAO — Schedule Assessment Guide
2. APM — What is project controls?
3. APM — What is resource management?