Xây dựng Project Charter cho dự án chuyển đổi số: Những nội dung không thể bỏ qua.

Charter phải giúp dự án được khởi động có căn cứ

Một nhóm triển khai đã họp nhiều lần, nhà cung cấp đã gửi phương án nhưng chưa ai biết quản lý dự án có quyền yêu cầu các phòng ban dành bao nhiêu thời gian. Khi phát sinh bất đồng về quy trình, mọi người chờ một cuộc họp khác. Đây là dấu hiệu dự án có hoạt động mà chưa có nền tảng ủy quyền và cam kết đủ rõ.

Project Charter là văn bản xác lập dự án và thẩm quyền quản lý trong cơ chế của doanh nghiệp. Nội dung cần làm rõ lý do thực hiện, mục tiêu, phạm vi cấp cao, các bên chịu trách nhiệm và giới hạn cam kết. Charter không thay thế kế hoạch chi tiết, nhưng phải giúp người đọc biết dự án được phép làm gì, cần đạt gì và quyết định nào thuộc ai.

Doanh nghiệp có thể dùng tên điều lệ dự án, quyết định khởi động hoặc hồ sơ tương đương. Tên gọi ít quan trọng hơn nội dung và người phê duyệt đúng thẩm quyền. Năng lực xây hồ sơ khởi động trong chương trình quản lý dự án IT giúp tạo căn cứ phối hợp trước khi cam kết nguồn lực lớn.

Viết lý do đầu tư đủ để kiểm tra lại

Phần lý do cần trình bày vấn đề hiện tại và ảnh hưởng, không chỉ nói doanh nghiệp cần theo xu hướng số hóa. Có thể mô tả yêu cầu bị chuyển nhiều lần, dữ liệu không thống nhất hoặc thiếu khả năng kiểm soát. Nếu sử dụng số liệu, ghi nguồn, phạm vi và thời điểm; nếu chưa có dữ liệu, ghi nhiệm vụ khảo sát và người chịu trách nhiệm.

Charter nên dẫn tới căn cứ đầu tư hoặc business case đã được xem xét. Business case đánh giá lựa chọn và tính hợp lý của đầu tư; charter xác lập việc khởi động cùng quyền hạn. Không cần sao chép mọi phân tích vào charter, nhưng các mục tiêu, giả định và giới hạn quan trọng giữa hai hồ sơ phải nhất quán.

Đừng biến lựa chọn giải pháp chưa kiểm chứng thành kết luận cố định. Nếu dự án còn phải khảo sát để chọn cách đáp ứng, cần ghi phạm vi khảo sát và cổng quyết định tiếp theo. Nhà bảo trợ có thể cho phép giai đoạn đánh giá trước khi chốt ngân sách triển khai toàn phần, thay vì phê duyệt một cam kết vượt hiểu biết hiện có.

Mục tiêu, sản phẩm cấp cao và ranh giới

Mục tiêu cần mô tả kết quả mong muốn cho nhóm công việc hoặc người sử dụng cụ thể. Sản phẩm cấp cao cho biết khả năng nào sẽ được tạo, như quy trình thống nhất, dữ liệu đã chuyển, chức năng cần thiết và cơ chế hỗ trợ. Chúng phải nối với mục tiêu nhưng chưa cần chi tiết từng trường dữ liệu hoặc thao tác kiểm thử.

Ghi phạm vi gồm những đơn vị, nhóm người dùng, hệ thống và loại giao dịch nào. Phần ngoài phạm vi cần được ghi rõ cùng các giao diện liên quan. Ví dụ, không thay đổi chính sách giá không có nghĩa dự án được bỏ qua cách hệ thống mới lấy giá từ nguồn đang dùng.

Tiêu chí thành công cấp cao cần đủ rõ để dẫn dắt kế hoạch. Có thể phân biệt chấp nhận sản phẩm, sẵn sàng vận hành và kết quả sau sử dụng. Khi mục tiêu định lượng còn phụ thuộc khảo sát, ghi cách xác nhận lại và quyền phê duyệt. Tránh một dòng “đáp ứng mọi yêu cầu phòng ban” khiến phạm vi trở nên không giới hạn.

Bảng kiểm nội dung tối thiểu

Bảng này là công cụ rà soát thực hành, có thể điều chỉnh theo quy mô và cơ chế doanh nghiệp. Charter ngắn vẫn có thể hữu ích nếu các quyết định rõ; văn bản dài có nhiều mô tả nhưng thiếu quyền hạn sẽ không giúp đội dự án giải quyết vướng mắc.

Ủy quyền cho quản lý dự án và nhận trách nhiệm nghiệp vụ

Ghi tên hoặc chức danh quản lý dự án cùng phạm vi quyền điều phối, theo dõi và báo cáo. Quyền điều phối không mặc nhiên bao gồm thay đổi ngân sách, chính sách hay ưu tiên của phòng ban. Các giới hạn phải đủ rõ để biết khi nào cần đưa vấn đề lên nhà bảo trợ hoặc cấp có thẩm quyền.

Nhà bảo trợ cần có khả năng bảo vệ mục tiêu, tháo gỡ vấn đề liên đơn vị và chốt các cam kết thuộc quyền mình. Chủ nghiệp vụ nhận trách nhiệm cho yêu cầu, quy trình và điều kiện áp dụng cách làm mới. Người nhận vận hành phải được tham gia từ đầu để tránh một dự án bàn giao sản phẩm mà không có bên duy trì.

Nếu dự án có nhiều phòng ban, ghi cơ chế đại diện và cách giải quyết xung đột. Không nên dùng sự đồng thuận của mọi người làm điều kiện cho mọi quyết định. Tư duy trong chương trình lãnh đạo IT hỗ trợ phân biệt phối hợp chuyên môn với quyền chốt cam kết của tổ chức.

Nguồn lực cần là cam kết có thể thực hiện

Đừng chỉ liệt kê tên thành viên. Charter nên xác định nhu cầu vai trò, mức tham gia ban đầu và đơn vị xác nhận nguồn lực. Các chuyên gia nghiệp vụ cần thời gian khảo sát, kiểm thử và chuẩn bị chuyển đổi; không thể coi họ luôn sẵn sàng ngoài công việc thường ngày.

Ngân sách và lịch cấp cao cần thể hiện phạm vi được phép cam kết ở giai đoạn này. Nếu các ước tính chưa đủ chắc, ghi khoảng hoặc cơ sở ước tính và thời điểm đánh giá lại theo quy định nội bộ. Nội dung của chuyên đề ngân sách IT hỗ trợ nhìn cả chi phí nội bộ, triển khai và vận hành khi chốt giới hạn đầu tư.

Các mốc nên gắn với kết quả cần xác nhận, như chốt phạm vi sau khảo sát hoặc cho phép triển khai sau thí điểm. Mốc hợp đồng của nhà cung cấp cần được xem cùng mốc sẵn sàng của nghiệp vụ. Không nên lấy một lịch thương mại làm bằng chứng rằng dữ liệu, người dùng và hỗ trợ đã chuẩn bị đủ.

Giả định, phụ thuộc và rủi ro ban đầu

Giả định là điều đang được dùng để lập kế hoạch nhưng cần kiểm chứng, như dữ liệu nguồn có thể trích xuất hoặc chuyên gia được bố trí đúng thời điểm. Phụ thuộc là điều kiện do công việc hay đơn vị khác cung cấp. Rủi ro là sự không chắc chắn có thể ảnh hưởng mục tiêu; vấn đề đã xảy ra cần được quản lý như vấn đề, không giấu dưới nhãn rủi ro.

Ghi các yếu tố quan trọng nhất cùng chủ xác nhận và thời điểm. Nếu giả định về tích hợp không đúng, dự án sẽ ảnh hưởng phạm vi hay ngân sách thế nào? Những câu hỏi này cần tạo nhiệm vụ kiểm chứng sớm. Cách tiếp cận từ chuyên đề quản trị rủi ro IT giúp chuyển nhận diện thành hành động có trách nhiệm.

Charter không cần chứa toàn bộ sổ rủi ro. Nó cần làm rõ những điều có thể thay đổi quyết định đầu tư và cơ chế đánh giá tiếp. Khi thông tin mới làm thay đổi nền tảng dự án, cần đưa về đúng cấp phê duyệt thay vì để nhóm triển khai tự mở rộng cam kết.

Tình huống giả định: Dự án số hóa phê duyệt nội bộ

Một doanh nghiệp giả định muốn triển khai luồng phê duyệt đề nghị mua hàng. Bản charter đầu ghi mục tiêu triển khai phần mềm và giao IT thực hiện, nhưng không nêu ai được thay đổi hạn mức hay ai xác nhận thời gian của người kiểm thử. Trong khảo sát, các phòng ban đưa ra nhiều quy tắc mâu thuẫn.

Nhà bảo trợ yêu cầu viết lại phần quyền và phạm vi. Chủ quy trình mua hàng nhận trách nhiệm đề xuất quy tắc, tài chính xác nhận kiểm soát thuộc chuyên môn, còn người có thẩm quyền chốt chính sách. Quản lý dự án được quyền điều phối các buổi xác nhận theo nguồn lực đã cam kết và báo cáo khi quyết định quá hạn.

Giai đoạn đầu chỉ cho phép khảo sát và thử một nhóm đề nghị. Ngân sách mở rộng được chốt ở cổng tiếp theo khi có bằng chứng về quy trình, dữ liệu và khả năng sử dụng. Charter trở thành căn cứ thực hiện, giúp dự án tiến lên mà không phải giả định mọi quyết định đã được giải quyết.

Phê duyệt và sử dụng charter trong suốt dự án

Trước phê duyệt, các bên chịu trách nhiệm cần xác nhận phần thuộc phạm vi mình. Người phê duyệt phải có đúng thẩm quyền khởi động và cam kết nguồn lực theo cơ chế tổ chức. Lưu phiên bản, quyết định và các điều kiện đi kèm; chữ ký không thay thế sự hiểu biết về nghĩa vụ cần thực hiện.

Sau khởi động, dùng charter để kiểm tra mục tiêu và giới hạn tại các mốc quản trị. Kế hoạch có thể chi tiết dần, nhưng thay đổi lớn về mục đích, quyền hoặc cam kết cần cập nhật hồ sơ tương ứng. Khi đóng dự án, đối chiếu kết quả với các tiêu chí đã được phê duyệt và bàn giao trách nhiệm còn tiếp tục.

Một charter tốt không cố trả lời mọi câu hỏi kỹ thuật từ ngày đầu. Nó xác định đủ rõ lý do, trách nhiệm và cơ chế để những câu hỏi còn lại được trả lời đúng lúc. Bước thực hành là đưa bản dự thảo cho nhà bảo trợ, chủ nghiệp vụ và người nhận vận hành, yêu cầu họ chỉ ra cam kết mình sẽ thực hiện cùng những điểm chưa thể chấp nhận.

Bài viết liên quan

• Chuyển mục tiêu chuyển đổi số thành phạm vi, sản phẩm bàn giao và kết quả dự án.
• Đánh giá hiện trạng quy trình AS-IS và thiết kế quy trình TO-BE trước khi triển khai giải pháp.
• Dự án chuyển đổi số đúng tiến độ nhưng doanh nghiệp không thay đổi: Vì sao?
• Quản lý yêu cầu nghiệp vụ: Làm thế nào để IT hiểu đúng vấn đề của các phòng ban?

Nguồn tham khảo

1. PMI – The Charter: Selling your Project
2. APM – What is a business case?
3. APM – What is governance?