INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Xây dựng mô hình quản trị chương trình và danh mục dự án IT cho doanh nghiệp.

Mô hình quản trị cần phân biệt quyết định dự án, chương trình và danh mục. Quyền rõ ràng, dữ liệu chung và trách nhiệm lợi ích giúp nối lựa chọn chiến lược với năng lực triển khai thực tế của doanh nghiệp.

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

Minh họa biên tập: cIO cùng lãnh đạo chương trình và danh mục xem xét các sáng kiến công nghệ trên bảng.

Trong một tình huống giả định, doanh nghiệp có dự án dữ liệu khách hàng, hệ thống bán hàng mới và cải tiến kho vận. Từng dự án đều có người quản lý, lịch triển khai và ngân sách riêng. Tuy nhiên, đội bán hàng chưa thể dùng tính năng mới vì dữ liệu chưa sẵn sàng; kho vận lại phải chờ quy trình thống nhất từ nghiệp vụ. Ban lãnh đạo nhìn thấy nhiều báo cáo tiến độ nhưng chưa có một dự báo đáng tin về lúc khách hàng được phục vụ tốt hơn.

Vấn đề này không thể giải quyết chỉ bằng cách thêm một báo cáo tổng hợp. Doanh nghiệp cần phân định ba loại công việc: quản lý sản phẩm bàn giao ở dự án, phối hợp thay đổi liên quan ở chương trình và lựa chọn đầu tư ở danh mục. Mô hình quản trị phải giúp quyết định đi đúng nơi, đồng thời giữ một đường liên kết từ chiến lược đến kết quả thực tế.

Xác định đơn vị quản trị từ kết quả cần đạt

Dự án có mục tiêu bàn giao trong một phạm vi và khoảng thời gian xác định. Chương trình phối hợp những thay đổi liên quan để tạo ra kết quả mà quản lý từng dự án riêng lẻ khó đạt được. Danh mục nhìn vào tập hợp đầu tư của doanh nghiệp để chọn ưu tiên và phân bổ năng lực. Ba góc nhìn này bổ sung nhau nhưng không nên bị dùng thay thế.

Một chương trình không hình thành chỉ vì các dự án dùng chung tên chiến lược. Cần chỉ ra sự phụ thuộc hoặc lợi ích chung đòi hỏi phối hợp. Trong ví dụ mở bài, chương trình cải thiện trải nghiệm đặt hàng có lý do tồn tại nếu dữ liệu, bán hàng và kho vận phải thay đổi cùng nhau. Người điều hành chương trình phải giải quyết trình tự chuyển đổi và trách nhiệm nghiệp vụ ngoài phạm vi từng dự án.

Ở cấp danh mục, câu hỏi rộng hơn: doanh nghiệp có nên dành năng lực cho chương trình đó trong kỳ đầu tư hiện tại, và phải hoãn việc nào để thực hiện? Một chương trình được tổ chức tốt vẫn có thể chưa phù hợp với năng lực hoặc ưu tiên lúc này. Danh mục vì thế phải giữ quyền xem lại lựa chọn đầu tư khi điều kiện thay đổi.

Các khái niệm của APM về chương trình và danh mục cung cấp nền tảng phân biệt hữu ích. Khi áp dụng vào doanh nghiệp, ranh giới cụ thể cần dựa trên loại quyết định đang bị bỏ trống. Tư duy này cũng gắn với năng lực liên kết đầu tư công nghệ và chiến lược trong chương trình Giám Đốc CNTT – CIO.

Phân quyền theo quyết định thay vì lập thêm nhiều ban

Sau khi xác định đơn vị quản trị, doanh nghiệp cần nhìn vào những quyết định đang chậm hoặc bị lặp lại. Nếu đội dự án phải chờ nhiều cuộc họp để xử lý một thay đổi trong phạm vi được giao, mô hình đang tạo quá nhiều tầng. Nếu một thay đổi ảnh hưởng nhiều đơn vị vẫn được chốt tại dự án, mô hình lại thiếu quyền phối hợp ở nơi cần thiết.

Cấp dự án nên được giao quyền điều hành công việc trong giới hạn đã thống nhất. Cấp chương trình xử lý phụ thuộc, trình tự chuyển đổi và sự đánh đổi giữa các dự án vì kết quả chung. Cấp danh mục xem xét ưu tiên, phân bổ đầu tư và năng lực trên toàn doanh nghiệp. Người chịu trách nhiệm kết quả kinh doanh phải tham gia nơi có quyền quyết định những thay đổi ảnh hưởng đến lợi ích đó.

Bảng sau là một thiết kế tham khảo về nơi đặt quyết định. Doanh nghiệp cần điều chỉnh theo cơ cấu tổ chức và thẩm quyền hiện hành, đồng thời chỉ rõ giới hạn được giao cho từng vai trò.

Cấp quản trị	Quyết định cần sở hữu	Bằng chứng để xem xét
Dự án	Cách thực hiện trong phạm vi và dung sai được giao	Sản phẩm, dự báo hoàn thành và vấn đề triển khai
Chương trình	Trình tự chuyển đổi và phụ thuộc giữa các dự án	Khả năng sử dụng chung và mức sẵn sàng nghiệp vụ
Danh mục	Ưu tiên đầu tư, dừng hoặc hoãn và phân bổ năng lực	Giá trị kỳ vọng, chi phí còn lại và công suất tổ chức

Ranh giới cần được thử bằng một tình huống cụ thể. Nếu dữ liệu khách hàng chậm khiến thời điểm mở kênh bán hàng phải đổi, ai được chọn lại trình tự? Nếu cần lấy chuyên gia từ chương trình khác, ai được điều chỉnh phân bổ? Một mô hình trả lời được hai câu hỏi này sẽ hữu ích hơn sơ đồ có đầy đủ chức danh nhưng không nêu quyền thực tế.

Đặt trách nhiệm lợi ích vào cùng mô hình với trách nhiệm bàn giao

Phân quyền triển khai chưa bảo đảm kết quả kinh doanh có người theo đuổi. Mỗi chương trình cần mô tả điều gì sẽ thay đổi trong hoạt động, ai có khả năng tạo ra thay đổi ấy và khi nào có bằng chứng để đánh giá. Lợi ích phải liên kết với quy trình và hành vi sử dụng, thay vì chỉ gắn với ngày hệ thống được cài đặt.

Trong ví dụ giả định, đội công nghệ có thể bàn giao luồng đồng bộ dữ liệu, nhưng việc giảm đơn hàng sai còn phụ thuộc vào cách nhân viên tạo và xử lý đơn. Người phụ trách nghiệp vụ phải quyết định quy tắc, đào tạo và cơ chế sửa dữ liệu. Nếu những công việc này không nằm trong kế hoạch chuyển đổi, chương trình dễ có nhiều sản phẩm hoàn tất mà kết quả chung vẫn chưa xuất hiện.

Doanh nghiệp nên giữ một chuỗi liên kết ngắn: mục tiêu chiến lược, kết quả hoạt động, thay đổi cần có, sản phẩm hỗ trợ và người chịu trách nhiệm. Mỗi mắt xích cần đủ rõ để kiểm tra. Một lợi ích dùng chung cho nhiều dự án phải được xác định cách ghi nhận để tránh cộng trùng trong báo cáo danh mục. Sự rõ ràng này đặc biệt quan trọng khi nhiều đơn vị cùng đóng góp.

Khi chủ sở hữu lợi ích được xác định, họ cần xuất hiện trong các điểm kiểm tra trước và sau triển khai. Trách nhiệm không kết thúc khi công nghệ bàn giao. Người điều hành chương trình phải theo dõi điều kiện tạo lợi ích, chuyển trách nhiệm về vận hành đúng thời điểm và ghi nhận những giả định cần xem xét lại.

Xây dựng dữ liệu chung đủ để nhìn thấy sự phụ thuộc

Mô hình nhiều cấp dễ tạo thêm báo cáo nếu mỗi nơi yêu cầu một bộ số liệu riêng. Doanh nghiệp nên thống nhất một tập dữ liệu tối thiểu: mục tiêu, phạm vi được phê duyệt, dự báo kết thúc, chi phí còn lại, phụ thuộc, nhu cầu kỹ năng và quyết định đang chờ. Các cấp sử dụng cùng dữ liệu nhưng đặt những câu hỏi khác nhau.

Dự án cần chi tiết đủ để điều hành. Chương trình cần biết một sản phẩm chậm sẽ ảnh hưởng đến kết quả chung ra sao. Danh mục cần nhìn tác động đến ưu tiên và năng lực toàn tổ chức. Một tỷ lệ hoàn thành trung bình không trả lời được cả ba nhu cầu. Dữ liệu quan trọng là dự báo cùng điều kiện để dự báo thành hiện thực, thay vì một con số đẹp nhưng khó kiểm chứng.

Phụ thuộc nên được ghi theo đầu ra cần nhận, ngày cần có, đơn vị cung cấp và hậu quả nếu thiếu. “Phụ thuộc đội dữ liệu” chưa đủ để điều hành. “Cần tập dữ liệu đã đối soát trước khi kiểm thử luồng đặt hàng” cho thấy một điểm phối hợp cụ thể. Cách ghi này cũng giúp phân biệt công việc đã chậm với công việc chưa sẵn sàng để bắt đầu.

Vai trò của PMO là hỗ trợ chất lượng thông tin, chuẩn hóa cách dự báo và chuẩn bị hồ sơ quyết định. PMO không mặc nhiên sở hữu quyền đầu tư hoặc quyền chấp nhận rủi ro kinh doanh. Các năng lực vận hành kế hoạch trong chương trình Quản Lý Dự Án IT giúp hình thành dữ liệu nền; người có thẩm quyền vẫn cần sử dụng dữ liệu đó để chốt lựa chọn.

Gắn nhịp điều hành với chu kỳ nguồn lực và đầu tư

Một danh mục quá tải thường không thiếu việc quan trọng mà thiếu cơ chế chuyển ưu tiên thành phân bổ thực tế. Nếu cuộc họp chỉ xác nhận mọi dự án đều cần tiếp tục, mức độ quá tải vẫn giữ nguyên. Mỗi quyết định nhận thêm việc phải đi kèm câu trả lời về năng lực sử dụng và phần công việc được dịch chuyển hoặc giảm xuống.

Doanh nghiệp có thể tổ chức nhịp theo dõi dự án ngắn hơn nhịp xem lại chương trình và danh mục. Điều quan trọng là các nhịp này có điểm nối. Khi một dự án vượt giới hạn được giao, vấn đề cần đến nơi có quyền xử lý đúng lúc. Cấp danh mục không nên đợi tới kỳ ngân sách tiếp theo nếu một thay đổi lớn đã làm mất cơ sở ưu tiên hiện tại.

Phân bổ nên tính đến kỹ năng khan hiếm và năng lực tiếp nhận thay đổi của nghiệp vụ. Một đội IT có thể triển khai nhiều hệ thống, nhưng cùng một đơn vị kinh doanh chưa chắc đào tạo và thay quy trình đồng thời được. Việc xem xét này gắn với trách nhiệm tổ chức nguồn lực của Trưởng Phòng IT – IT Manager, đồng thời cần sự phối hợp của lãnh đạo nghiệp vụ.

Cấp vốn theo các bước có bằng chứng là một cách giữ khả năng điều chỉnh. Trước khi tạo thêm cam kết, doanh nghiệp xem xét kết quả đã có, giả định còn đúng và phần đầu tư tiếp theo. Một bước thử nghiệm có thể đáng làm dù triển khai toàn bộ chưa đủ cơ sở. Ngược lại, một dự án đã khởi động vẫn cần được xem lại nếu lợi ích hoặc điều kiện thực hiện thay đổi đáng kể.

Thử mô hình trên một chuỗi quyết định trước khi mở rộng

Doanh nghiệp không cần triển khai toàn bộ hệ thống quản trị cùng lúc. Có thể chọn một chương trình có phụ thuộc rõ và một nhóm đầu tư dùng chung nguồn lực để thử cách làm. Mục tiêu thử nghiệm là xem quyết định có nhanh hơn, dữ liệu có nhất quán hơn và trách nhiệm có được thực hiện hay không. Số biểu mẫu đã ban hành không phản ánh những kết quả đó.

Một cuộc diễn tập hữu ích là đưa vào tình huống dữ liệu chậm, một chuyên gia không còn khả dụng và lợi ích kỳ vọng bị giảm. Các vai trò phải chỉ ra ai xử lý, giới hạn quyền ở đâu và cần bằng chứng gì. Những câu trả lời mâu thuẫn cho thấy nơi phải chỉnh mô hình. Sau đó dùng quyết định thực tế để kiểm tra thay vì chỉ tổ chức hội thảo về quy trình.

Đối với đội Giám Đốc Dự Án IT – Project Manager, mô hình này cần tạo hai điều kiện: đủ quyền để điều hành trong phạm vi được giao và một đường xử lý rõ khi vấn đề vượt phạm vi. Người quản lý dự án không nên chịu trách nhiệm cho lợi ích mà họ không có quyền tác động, nhưng phải cung cấp dự báo trung thực và cảnh báo những điều kiện đang mất đi.

Sau giai đoạn thử, doanh nghiệp có thể đơn giản hóa những bước không tạo ra quyết định, bổ sung điểm phối hợp còn thiếu và mở rộng dần. Mô hình quản trị tốt làm cho mối liên hệ giữa chiến lược, đầu tư và thực thi trở nên có thể kiểm tra. Khi cả dự án, chương trình và danh mục cùng làm đúng phần việc của mình, lãnh đạo mới có khả năng chủ động thay đổi đường đi trước khi các cam kết riêng lẻ trở thành một sự chậm trễ chung.