Quản lý dự án IT không chỉ theo dõi tiến độ: Sáu nhóm công việc cần kiểm soát

Phạm vi: làm rõ doanh nghiệp sẽ nhận được điều gì

Nhóm đầu tiên giữ ranh giới giữa điều được yêu cầu, điều đã thống nhất và điều thực sự phải bàn giao. Một câu như “triển khai hệ thống quản lý khách hàng” chưa đủ để giao việc. Cần xác định quy trình nào được hỗ trợ, dữ liệu nào được đưa vào, đơn vị nào sử dụng và điều kiện nào chứng minh sản phẩm đáp ứng. Những phần ngoài phạm vi cũng phải được nói rõ để tránh các bên tự điền bằng kỳ vọng riêng.

Người quản lý cần nối yêu cầu với sản phẩm và gói công việc. Một yêu cầu quan trọng mà không có phần việc thực hiện sẽ bị bỏ sót; một phần việc không phục vụ yêu cầu hay nghĩa vụ nào cần được xem xét. Việc đối chiếu này giúp phát hiện cả khoảng trống lẫn phần bổ sung tự phát. Công cụ hỗ trợ có thể đơn giản, miễn là đội biết phiên bản nào đã được phê duyệt.

Đây là nền tảng của năng lực quản lý dự án IT: mô tả công việc đủ rõ để lập kế hoạch và kiểm tra, rồi kiểm soát thay đổi trên cùng cơ sở. Không phải mọi chi tiết đều cần biết ngay từ đầu, nhưng phần chưa rõ phải có người làm rõ, thời điểm cần quyết định và giới hạn cam kết tạm thời.

Phạm vi cũng bao gồm những việc ít được chú ý trong buổi trình diễn: chuyển dữ liệu, chuẩn bị môi trường, hướng dẫn và tiếp nhận hỗ trợ. Nếu chúng cần thiết để sản phẩm sử dụng được, chúng phải có vị trí trong kế hoạch. Khi biết cần hoàn thành điều gì, dự án mới có thể hỏi một cách có cơ sở rằng phải hoàn thành theo trình tự nào.

Tiến độ: quản lý chuỗi điều kiện để công việc hoàn tất

Kế hoạch tiến độ phải mô tả quan hệ giữa các công việc, không chỉ đặt ngày cạnh tên nhiệm vụ. Kiểm thử tích hợp cần phiên bản phù hợp, dữ liệu và môi trường sẵn sàng. Chạy chính thức có thể cần một cửa sổ vận hành được duyệt. Nếu những quan hệ đó chỉ nằm trong trí nhớ của từng người, lịch vẫn trông hợp lý cho đến lúc một đầu vào không xuất hiện.

Mỗi kỳ cập nhật nên kiểm tra công việc còn lại, điều kiện bắt đầu và tác động đến mốc sau. Tỷ lệ hoàn thành do người thực hiện tự báo cáo cần được đặt bên cạnh bằng chứng. Một chức năng gần hoàn tất về lập trình có thể vẫn còn nhiều công việc để trở thành sản phẩm được chấp nhận. Dự báo kết thúc phải tính những phần việc đó thay vì chỉ dựa vào thời gian đã dùng.

Đường găng cho biết chuỗi công việc đang quyết định thời điểm kết thúc trong mô hình lịch hiện tại. Chuỗi này có thể thay đổi khi thời lượng, phụ thuộc hoặc nguồn lực thay đổi. Vì vậy, người quản lý cần theo dõi cả những đường gần găng và các mốc bên ngoài. Việc thúc một nhiệm vụ dễ hoàn thành sẽ ít giúp ích nếu điểm nghẽn thật nằm ở một quyết định nghiệp vụ chưa được chốt.

Kế hoạch tốt đưa ra cảnh báo trước khi mốc bị mất, kèm lựa chọn có thể thực hiện. Nhưng lựa chọn thêm người, làm song song hay đổi trình tự đều có hệ quả. Muốn đánh giá chúng, dự án cần nhìn rõ tiền đang được sử dụng cho phần công việc nào.

Chi phí: nhìn phần còn phải chi để hoàn thành

Theo dõi chi phí không dừng ở số tiền đã thanh toán. Người quản lý cần thấy công việc đã được thực hiện, nghĩa vụ đã cam kết và khoản còn phải chi. Một hóa đơn đến chậm có thể khiến báo cáo tạm thời trông tiết kiệm, dù nghĩa vụ thanh toán đã hình thành. Ngược lại, một khoản trả trước không chứng minh dự án đã nhận được giá trị tương ứng.

Ngân sách nên được liên kết với gói công việc và thời gian dự kiến phát sinh. Khi phạm vi hay lịch thay đổi, phải cập nhật dự báo phần còn lại. Nếu kiểm thử kéo dài, chi phí môi trường, chuyên gia và hỗ trợ cũng có thể tăng. Việc giải thích những quan hệ này giúp Sponsor hiểu vì sao số tiền cần để hoàn thành đang khác dự kiến.

Cấp quản lý cần phân biệt đường cơ sở được phê duyệt với dự báo hiện tại. Dự báo phải trung thực ngay khi thông tin mới xuất hiện; việc thay đường cơ sở cần theo quyền và quy trình đã thống nhất. Nếu cứ sửa kế hoạch gốc để khớp thực tế, doanh nghiệp mất khả năng đánh giá sai lệch. Nếu giữ dự báo cũ bất chấp bằng chứng, báo cáo lại mất tính hữu ích.

Các quyết định ảnh hưởng nguồn lực thường cần phối hợp với Trưởng Phòng IT – IT Manager. Dù chi phí còn trong giới hạn, việc bố trí một chuyên gia cho nhiều cam kết cùng lúc vẫn có thể làm kế hoạch không thực hiện được. Vì thế, tiền và năng lực phải được xem cùng nhau.

Nguồn lực: xác nhận năng lực có mặt vào đúng thời điểm

Một tên người trên kế hoạch chưa phải cam kết nguồn lực. Cần biết người đó có kỹ năng gì, có thể dành bao nhiêu thời gian và còn nghĩa vụ nào khác. Trong IT, chuyên gia dữ liệu, tích hợp hoặc an toàn thông tin thường tham gia nhiều dự án. Kế hoạch dùng toàn bộ thời gian của họ nhưng không được người quản lý trực tiếp xác nhận sẽ tạo ra năng lực trên giấy.

Nguồn lực cũng gồm môi trường, công cụ và khả năng tham gia của nghiệp vụ. Một nhóm phát triển đầy đủ vẫn có thể chờ nếu phòng kinh doanh chưa bố trí người kiểm tra quy trình. Người quản lý dự án cần xác định những đầu vào này theo khoảng thời gian thực tế, rồi thống nhất cơ chế xử lý khi chúng không sẵn sàng. Đơn vị cung cấp phải biết hệ quả của việc thay cam kết.

Phân vai giúp tránh tình trạng nhiều người tham gia nhưng không ai chịu trách nhiệm cuối cùng. Tuy nhiên, bảng phân vai chỉ có ích khi người được giao có quyền, thời gian và chấp nhận nhiệm vụ. Khi một điểm bàn giao bị kẹt, phải xác định ai xử lý công việc và ai có thể quyết định sự đánh đổi. Người điều phối không nên trở thành người mặc định làm thay mọi phần còn trống.

Cam kết nguồn lực tạo điều kiện thực hiện, nhưng chưa nói sản phẩm đã đủ tốt để sử dụng. Câu hỏi chất lượng cần được giữ độc lập để dự án không biến áp lực tiến độ thành lý do bỏ qua bằng chứng nghiệm thu.

Chất lượng: kiểm tra tính phù hợp trước khi chuyển trách nhiệm

Chất lượng bắt đầu từ điều kiện chấp nhận. Người dùng và đội kỹ thuật cần thống nhất những kịch bản phải hoạt động, giới hạn hiệu năng, yêu cầu dữ liệu và các điều kiện liên quan. Tiêu chí càng muộn mới được làm rõ, khả năng làm lại càng lớn. Một buổi trình diễn thuận lợi chỉ chứng minh các tình huống đã trình diễn, không thay thế việc kiểm tra những ngoại lệ quan trọng.

Đội dự án nên giữ liên kết giữa yêu cầu, phiên bản sản phẩm và kết quả kiểm tra. Lỗi được đánh giá theo tác động sử dụng, không chỉ mức độ khó sửa. Nếu chấp nhận tồn đọng, phải có người chịu tác động, biện pháp kiểm soát và hạn xử lý. Một quyết định bàn giao cần phản ánh cả sản phẩm đã đạt và phần trách nhiệm còn mở.

Năng lực quản lý dịch vụ IT theo tư duy ITSM giúp kiểm tra điều kiện tiếp nhận: giám sát, hỗ trợ, phục hồi và hướng dẫn vận hành. Sản phẩm đáp ứng chức năng nhưng chưa có khả năng hỗ trợ khi gặp lỗi vẫn có thể chưa sẵn sàng chạy chính thức. Nghiệm thu sản phẩm và cho phép vận hành cần được phân định phù hợp với cơ chế của doanh nghiệp.

Ngay cả khi các phần việc đã được tổ chức tốt, dự án vẫn chịu bất định. Phần kiểm soát cuối cùng giúp đội chuẩn bị trước cho điều có thể xảy ra và xử lý dứt điểm điều đã xảy ra.

Rủi ro và vấn đề: đưa bất định vào quyết định hằng ngày

Rủi ro là điều chưa chắc xảy ra nhưng có thể ảnh hưởng mục tiêu. Vấn đề hiện hữu là điều đã xảy ra hoặc đang cần giải quyết. Hai loại cần liên kết nhưng không được quản lý bằng cùng một lời hứa chung. Một khả năng dữ liệu không đủ chất lượng cần biện pháp phòng ngừa; khi dữ liệu đã bị trả lại, dự án cần người sửa, hạn xử lý và đánh giá tác động ngay.

Người quản lý phải theo dõi hành động ứng phó và dấu hiệu cần kích hoạt phương án dự phòng. Những mục vượt quyền xử lý cần được trình lên cấp có thẩm quyền với quyết định cụ thể. Chỉ gửi một danh sách đỏ không làm rủi ro giảm xuống. Việc này gắn với năng lực điều hành và xử lý sự đánh đổi trong chương trình Giám Đốc Dự Án IT.

Bảng kiểm dưới đây giúp rà soát một dự án đang chạy. Đây là công cụ đề xuất để tổ chức cuộc trao đổi, không phải hệ phân loại duy nhất cho mọi dự án.

Chọn một mốc sắp tới và trả lời cả sáu câu hỏi sẽ cho thấy những khoảng trống mà bảng tiến độ riêng lẻ bỏ qua. Nếu dữ liệu chưa được đối soát như tình huống mở bài, cần nối nó với trách nhiệm, kiểm thử, chi phí và khả năng vận hành. Khi các phần ấy được nhìn cùng nhau, ngày bàn giao trở thành một cam kết có điều kiện rõ ràng, thay vì một ô lịch liên tục bị dời.

Bài viết liên quan

• Xây dựng Project Charter và thống nhất mục tiêu trước khi khởi động dự án.
• Xây dựng kế hoạch tiến độ dự án IT: Xác định phụ thuộc và đường găng.
• Xây dựng ngân sách và đường cơ sở chi phí để kiểm soát dự án.
• Xây dựng Risk Register: Nhận diện, đánh giá và lập phương án ứng phó rủi ro.

Nguồn tham khảo

1. UK Government — Government Functional Standard GovS 002: Project Delivery
2. APM — What is project planning?
3. APM — What is quality management and control?