Khi nhận nhiệm vụ thực hiện xây dựng hệ thống quản lý dự án CNTT cho cả tổ chức. Tôi vẫn nhớ mãi cái trăn trở của mình khi thiết kế quy trình lên kế hoạch dự án: “Đâu là những yếu tố thúc đẩy cho một người Project Manager tạo ra một Project Schedule có tính khả thi cao?”. Việc tự lên kế hoạch dựa trên kinh nghiệm của bản thân thì kết quả phụ thuộc chính năng lực của Project Manager. Thứ mà các Project Manager luôn tự cho mình làm tốt nhất và ít khi mở chiếc nắp của cái chai tri thức của bản thân ra để đón nhận phương pháp mới, hiệu quả hơn cho đến khi họ nếm trái đắng của thất bại.

Ở góc nhìn của của một người kiểm soát hệ thống quản lý dự án. Tôi thấy rằng đây là một nguy hại ảnh hưởng đến việc kiểm soát dòng tiền (cash-flow) của doanh nghiệp. Tiền chính là dòng máu duy trì sự sống của doanh nghiệp. Thực tế đang hiện ra rất phũ phàng, dự án về rất nhiều, team làm không xuể, team tăng ca liên tục, nhưng cơ thể doanh nghiệp luôn bị xuất hiện những cơn co giật mạnh vì thiếu máu.

Cuối cùng thì cũng quay về cách nghĩ cơ bản (back to basic) để trả lời các câu hỏi nhỏ hơn như:

• Đâu là thông tin hiện trên Project Schedule?
• Các đầu việc đã chia nhỏ theo chức năng để tạo ra deliverables được mô tả trong Project Plan chưa?
• Các đầu việc được sắp xếp độ ưu tiên theo một critical path hợp lý chưa?
• Nguồn lực nào sẽ đảm nhận các đầu việc liệu các nguồn lực ấy có đáp ứng so với kết quả ước lượng?
• Các đầu việc được lên lịch trình có thoả mãn các milestone của dự án được mô tả trong Project Plan?
• Có đầu việc nào quá lớn mà ta chưa hình dung được cách để hoàn thành nó?
• Có những rủi ro nào tiềm ẩn có thể bẻ gãy đường critical path?
• …

Điều thú vị là những kết quả trả lời của những câu hỏi trên nêu lên 3 điểm chính:

• Project Schedule có tính khả thi cao quyết định nhiều bởi khả năng phân rã các đầu việc và nghệ thuật sắp xếp độ ưu tiên. WBS (Work Breakdown Structure) có thể là kỹ thuật tốt để thực hiện việc phân rã và MoSCoW là kỹ thuật hiệu quả để sắp xếp độ ưu tiên.
• Project Schedule có tính ổn định cao quyết định đến cách mà team dự án hiểu được yêu cầu, biết làm sao để tạo ra các deliverables (hay các kỹ thuật cần áp dụng, cách tích hợp hệ thống, và kiểm thử) và các rủi ro tiềm ẩn. Công việc này quyết định bởi cách thực hành estimate các đầu việc bởi người tham gia thực hiện công việc (chứ không phải PM)
• Để tránh sự phụ thuộc vào Project Manager thì cần có hệ thống quản lý dự án từ tổ chức và mỗi dự án có thể kế thừa tài nguyên này. Bên cạnh đó cần đào tạo tư duy quản lý và phương pháp dẫn dắt cho chính các Project Manager.

Phát hiện thú vị hơn là các nhà quản lý dự án và đội dự án thường xem nhẹ việc phân rã đầu việc và đầu tư thời gian đủ để thực hành estimate. Kết quả là một Project Schedule sơ xài, mang tính chất đối phó, để rồi phải thốt lên “Sao chúng ta tốn quá nhiều thời gian cho re-work?” trong suốt quá trình triển khai dự án trong tâm trạng stress nặng. Stress từ dự án này qua dự án khác. Dấu hiệu stress báo hiệu dòng máu (cash-flow) trong doanh nghiệp có nguy cơ bị tắt.

Quản lý dự án có thể xem là một nghệ thuật thiết kế hệ thống quản trị, mà ở đó người Project Manager là nhà thiết và cũng là người thực thi. Project Schedule là một trong nhiều tài liệu cần thiết của Project Plan. Thành công hay thất bại của dự án quyết định đến kỹ năng thiết kế và kinh nghiệm làm dự án của Project Manager. Nhiều khi thay vì tự mày mò và nếm mùi thất bại để nâng cao kỹ năng thiết kế hệ thống quản lý dự án, bạn hãy tìm ra cách thông minh hơn để sử dụng các best practice về quản lý dự án CNTT và học hỏi kiến thức từ những thành công, lẫn thất bại từ người có nhiều kinh nghiệm.

***

Đây là bài viết cùng chủ đề “Thực hành quản lý dự án CNTT”. Các phần đã phát hành của bài viết:

* Phần 1: Tầm quan trọng của việc viết kế hoạch quản lý dự án CNTT

***

Tôi thường thấy, hàng năm các IT Manager triển khai rất nhiều dự án CNTT trong doanh nghiệp. Có khi nào các IT Manager tự thật lòng với chính mình “Thành công của nghề đến từ sự thành công của các dự án CNTT mà mình làm Project Manager hay là hoạt động vận hành hệ thống hằng ngày?”.

by Cao Trần