INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Quản trị tổng thể phạm vi, tiến độ, chi phí và chất lượng ở cấp lãnh đạo dự án.

Phạm vi, tiến độ, chi phí và chất lượng phải cùng mô tả một dự báo kết thúc. Lãnh đạo dự án cần nhìn hệ quả dây chuyền của mỗi lựa chọn để quyết định sự đánh đổi trên bằng chứng thống nhất.

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc dự án IT – Project Manager

← Trở về thư viện bài viết

Quản lý dự án, kỹ sư và chuyên gia chất lượng xem kế hoạch công việc liên kết trên bảng
Minh họa biên tập: quản lý dự án, kỹ sư và chuyên gia chất lượng xem kế hoạch công việc liên kết trên bảng.

Báo cáo tiến độ ghi nhận phần lớn công việc đã hoàn thành, chi phí giải ngân vẫn thấp hơn kế hoạch. Cùng lúc, các lỗi tích hợp tăng và thời gian kiểm thử nghiệp vụ bị rút ngắn để giữ ngày bàn giao. Trong tình huống minh họa giả định này, từng chỉ số riêng có thể trông tích cực, nhưng khả năng hoàn thành dự án lại đang suy giảm.

Ở cấp lãnh đạo, quản trị phạm vi, tiến độ, chi phí và chất lượng cần dựa trên một dự báo thống nhất. Một thay đổi trong phạm vi làm tăng công việc; công việc mới ảnh hưởng nguồn lực và lịch; cách giữ lịch có thể làm tăng chi phí hoặc để lại rủi ro chất lượng. Nếu bốn yếu tố được báo cáo tách rời, người quyết định khó thấy hệ quả của lựa chọn đang được đề xuất.

Xây dựng một đường cơ sở chung để nhìn cùng một dự án

Đường cơ sở là bộ cam kết đã được phê duyệt để so sánh việc thực hiện. Phạm vi phải mô tả sản phẩm và điều kiện chấp nhận; lịch phải phản ánh công việc, phụ thuộc và nguồn lực; ngân sách phải dựa trên chính phạm vi ấy. Nếu nhóm kỹ thuật lập kế hoạch theo một tập yêu cầu, trong khi tài chính duyệt theo tập yêu cầu khác, báo cáo sai lệch sẽ xuất hiện ngay cả khi mọi người cập nhật đúng phần của mình.

Cần phân biệt đường cơ sở với dự báo mới nhất. Đường cơ sở cho biết đã cam kết điều gì; dự báo cho biết với tình hình hiện tại dự án có thể kết thúc ra sao. Việc thay lịch trên công cụ mà không lưu dấu vết sẽ làm biến mất bằng chứng trễ. Ngược lại, giữ lịch cũ trong báo cáo dù nhóm đã biết không thể hoàn thành sẽ ngăn lãnh đạo điều chỉnh kịp thời.

Mỗi gói công việc quan trọng cần có người chịu trách nhiệm và bằng chứng hoàn tất. “Đã phát triển xong” khác với “đã kiểm thử tích hợp” hoặc “đã được nghiệp vụ chấp nhận”. Dùng trạng thái không nhất quán sẽ khiến tỷ lệ hoàn thành tăng nhanh trong khi phần việc để đưa vào sử dụng vẫn còn lớn. Project Manager cần thống nhất cách ghi nhận trước khi so sánh các nhóm.

Năng lực quản lý dự án IT tạo nền tảng cho kế hoạch chung này. Khi có một đường cơ sở đủ rõ, lãnh đạo mới có thể xem phần nào của phạm vi thực sự cần thiết và điều kiện chất lượng nào phải được bảo vệ khi xuất hiện áp lực thời gian.

Phạm vi cần gắn với lợi ích và điều kiện chấp nhận

Quản lý phạm vi không chỉ là giữ nguyên danh sách tính năng. Có yêu cầu bổ sung phát sinh từ việc hiểu rõ hơn nhu cầu đã cam kết, cũng có yêu cầu tạo lợi ích mới ngoài mục tiêu ban đầu. Project Manager cần phân biệt hai trường hợp để đánh giá. Nếu mọi phát hiện đều bị xem là yêu cầu mới, chất lượng giải pháp có thể giảm; nếu mọi bổ sung đều được nhận miễn phí, dự án sẽ mất khả năng kiểm soát.

Điều kiện chấp nhận cần được xác định cùng người dùng và vận hành. Một chức năng có thể chạy đúng trong thử nghiệm nhưng chưa đáp ứng nhu cầu truy xuất, phân quyền hoặc phục hồi. Những yêu cầu này không nên chỉ được nhắc ở cuối dự án. Chúng ảnh hưởng thiết kế và công việc ngay từ đầu, đồng thời quyết định điều gì được phép cắt khi cần thu hẹp phạm vi.

Khi thiếu thời gian, có thể xem xét hoãn một nhóm tính năng chưa thiết yếu thay vì rút ngắn mọi hoạt động kiểm thử. Tuy nhiên, việc hoãn phải kiểm tra phụ thuộc. Một tính năng báo cáo có vẻ độc lập có thể chứa dữ liệu cần cho đối soát vận hành; bỏ nó sẽ chuyển công việc sang thao tác thủ công. Phương án giảm phạm vi phải có đánh giá về lợi ích còn đạt và chi phí phát sinh.

Năng lực lãnh đạo dự án IT giúp đưa sự đánh đổi phạm vi lên đúng cấp quyết định. Sau khi xác định phần phải giữ và phần có thể điều chỉnh, cần xem lịch nào còn khả thi với năng lực thực tế.

Dự báo tiến độ từ phụ thuộc và công việc còn lại

Một tỷ lệ hoàn thành chung không cho biết công việc nào quyết định ngày kết thúc. Nhóm dự án cần xem những chuỗi phụ thuộc và hoạt động không còn dư thời gian. Một lỗi trên giao diện ít sử dụng có thể ít ảnh hưởng lịch, trong khi chậm cung cấp môi trường kiểm thử làm nhiều nhóm phải chờ. Báo cáo lãnh đạo nên tập trung vào những nguyên nhân có thể thay đổi mốc bàn giao.

Phần việc còn lại cần được ước lượng bằng người sẽ thực hiện, có tính đến dữ liệu, môi trường và phản hồi nghiệp vụ. Dự kiến kiểm thử trong một tuần nhưng người xác nhận chỉ sẵn sàng vài buổi sẽ tạo một lịch thiếu khả thi. Tương tự, bổ sung lập trình viên không tự rút ngắn công việc đang chờ quyết định kiến trúc hoặc chờ tích hợp từ đối tác.

Lịch phục hồi phải nêu tác động và điều kiện. Làm song song có thể giảm thời gian nhưng tăng khả năng làm lại khi thiết kế chưa ổn định. Tăng nguồn lực có thể giúp một số hoạt động, nhưng cần thời gian hướng dẫn và điều phối. Project Manager cần so sánh các lựa chọn này với phương án thay đổi mốc hoặc giảm phạm vi, thay vì chỉ đưa ra một lịch mới ngắn hơn.

Có thể trình bày ngày hoàn thành theo một khoảng khi bất định lớn, kèm điều kiện để đạt mốc sớm và yếu tố có thể đẩy đến mốc muộn. Độ chính xác của dự báo cần tăng khi bằng chứng tăng. Khi lịch đã phản ánh phần việc còn lại, dự báo chi phí cũng phải được tính trên cùng giả định, nếu không lãnh đạo sẽ tiếp tục thấy những con số không nối với nhau.

Chi phí đã chi phải đi cùng dự toán để hoàn tất

Giải ngân thấp hơn kế hoạch không luôn là dấu hiệu tiết kiệm. Công việc có thể chậm, hóa đơn chưa nhận hoặc một phần chi phí nội bộ chưa được ghi nhận. Báo cáo cần tách tiền đã chi, khoản đã cam kết và dự toán còn cần để hoàn tất. Với dự án có nhiều nhà cung cấp, việc ghi nhận nhất quán giúp tránh bỏ sót những khoản phát sinh đã được yêu cầu nhưng chưa chính thức thanh toán.

Dự báo tổng chi phí cần phản ánh công việc còn lại, mức giá nguồn lực, thời gian kéo dài và chi phí xử lý lỗi. Một thay đổi nhỏ về tính năng có thể làm phát sinh đào tạo, tài liệu, tích hợp và hỗ trợ. Chỉ cộng công phát triển sẽ đánh giá thấp tác động. Tài chính và Project Manager nên kiểm tra cả thời điểm phát sinh để nhìn áp lực dòng tiền.

Chi phí dự phòng phải gắn với bất định và quyền sử dụng rõ ràng. Không nên tự dùng khoản dự phòng để che một thay đổi phạm vi chưa được duyệt. Khi một rủi ro đã xảy ra, tác động cần được chuyển vào dự báo và kế hoạch xử lý. Việc tiếp tục giữ rủi ro như một dòng ghi chú trong khi chi phí thực tế đang tăng sẽ làm báo cáo mất tính hữu ích.

Năng lực quản lý nguồn lực và ngân sách IT hỗ trợ xác định phần công sức nội bộ. Khi có dự báo tài chính đáng tin cậy, lãnh đạo cần thêm bằng chứng chất lượng để biết sản phẩm dự kiến bàn giao có sử dụng được hay chỉ hoàn thành trên giấy.

Chất lượng cần được dự báo bằng mức sẵn sàng sử dụng

Số lỗi mở là một chỉ báo nhưng chưa mô tả đầy đủ chất lượng. Cần xem mức nghiêm trọng, luồng nghiệp vụ bị ảnh hưởng, tuổi lỗi, tốc độ phát hiện và bằng chứng kiểm thử lại. Một lỗi không làm hệ thống dừng vẫn có thể khiến giao dịch sai và cần xử lý thủ công. Việc gắn lỗi với tác động giúp lãnh đạo hiểu vì sao nó phải được giải quyết trước bàn giao.

Chất lượng cũng bao gồm dữ liệu và vận hành. Kết quả chuyển dữ liệu cần được đối soát; quyền truy cập cần được xác nhận; phục hồi cần được thử theo phạm vi phù hợp. Đội hỗ trợ phải có tài liệu, kênh tiếp nhận và người xử lý. Một hệ thống qua kiểm thử chức năng nhưng chưa có năng lực hỗ trợ sẽ chuyển rủi ro từ dự án sang bộ phận vận hành.

Liên kết với năng lực quản lý dịch vụ IT giúp thiết kế điều kiện tiếp nhận sớm. Báo cáo chất lượng nên làm rõ điều đã kiểm tra, phần chưa kiểm tra và tồn đọng được đề nghị chấp nhận. Trách nhiệm chấp nhận tồn đọng cần thuộc đúng người chịu tác động, đồng thời tuân thủ giới hạn quyền hạn của tổ chức.

Bảng dưới đây nối bốn góc nhìn thành câu hỏi quyết định. Người chuẩn bị cần dùng cùng dữ liệu dự báo, thay vì điền những con số riêng cho từng cột báo cáo.

Góc nhìnBằng chứng phải xemQuyết định có thể phát sinh
Phạm viYêu cầu và điều kiện chấp nhậnGiữ, hoãn hoặc loại một phần
Tiến độPhụ thuộc và công việc còn lạiĐiều chỉnh lịch hoặc nguồn lực
Chi phíĐã chi, đã cam kết, còn cầnCấp bổ sung hoặc thay phương án
Chất lượngKiểm thử, dữ liệu, tiếp nhậnCho phép vận hành hoặc xử lý thêm

Một lựa chọn cần được đọc qua cả bốn dòng. Hoãn chức năng có thể giảm chi phí nhưng cũng giảm lợi ích; tăng tốc có thể làm kiểm thử thiếu đại diện. Chính mối quan hệ này phải xuất hiện trong quy trình thay đổi và cuộc họp lãnh đạo.

Chốt thay đổi trên tác động tổng thể và kiểm tra lại dự báo

APM mô tả change control là quá trình đánh giá và quyết định các đề nghị thay đổi đường cơ sở. Với dự án IT, đề nghị nên nêu lý do, phạm vi ảnh hưởng, lựa chọn và tác động tổng thể. Những thay đổi trong quyền hạn Project Manager có thể xử lý tại cấp dự án; thay đổi vượt giới hạn cần trình đúng người có thẩm quyền theo cơ chế đã thống nhất.

Cuộc họp lãnh đạo nên mở bằng dự báo kết thúc và những quyết định cần chốt. Sau đó mới xem bằng chứng giải thích vì sao dự báo thay đổi. Cách làm này giúp tránh dành phần lớn thời gian đọc các trạng thái đã gửi trước. Mỗi quyết định cần có người thực hiện, thời hạn và cách kiểm tra tác động sau khi triển khai.

Trong tình huống mở bài, giảm thời gian kiểm thử chỉ có thể được cân nhắc sau khi xem luồng bị bỏ, tác động và điều kiện chấp nhận. Một phương án tốt hơn có thể là triển khai phạm vi nhỏ hơn với kiểm thử đầy đủ, hoặc lùi mốc để xử lý tích hợp. Không có lựa chọn mặc định đúng cho mọi dự án; lãnh đạo cần nhìn được chi phí và rủi ro của từng phương án.

Bước thực hành đầu tiên là đối chiếu báo cáo tiến độ, dự toán hoàn tất và trạng thái chất lượng với cùng một phạm vi. Nếu chúng đang mô tả ba kế hoạch khác nhau, hãy thống nhất lại trước khi xin quyết định. Quản trị tổng thể bắt đầu từ một bức tranh chung đủ đáng tin để người có thẩm quyền lựa chọn sự đánh đổi.

Nguồn tham khảo

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