INFOCHIEF ACADEMY · IT PROJECT MANAGEMENT KNOWLEDGE SERIES
Xây dựng Project Charter và thống nhất mục tiêu trước khi khởi động dự án.
Project Charter chuyển sự đồng ý về chủ trương thành mục tiêu, ranh giới và quyền điều hành rõ ràng. Thống nhất trước khởi động giúp đội dự án xây kế hoạch trên cùng một cơ sở và xử lý khác biệt từ sớm.
Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án IT
Trong một tình huống giả định, dự án cổng dịch vụ nội bộ được khởi động bằng một buổi họp đông đủ. Phòng nhân sự kỳ vọng giảm công việc trả lời yêu cầu, IT muốn thay hệ thống cũ, còn lãnh đạo mong có dữ liệu về chất lượng phục vụ. Mọi người đều đồng ý rằng dự án cần thiết. Đến khi chọn chức năng cho lần triển khai đầu, ba mục tiêu bắt đầu dẫn đến ba thứ tự ưu tiên khác nhau.
Một cuộc họp thống nhất chủ trương chưa tạo ra sự thống nhất về dự án. Project Charter, hay văn bản chính thức cho phép khởi động dự án, cần chuyển mong muốn chung thành mục tiêu, ranh giới và quyền điều hành đủ rõ. Giá trị của văn bản không nằm ở số trang hoặc số chữ ký, mà ở khả năng giúp các bên đưa ra cùng một quyết định khi phải lựa chọn.
Charter phải xác nhận quyết định khởi động nào
Trước khi viết, cần phân biệt lý do đầu tư với quyền triển khai. Business Case giải thích vì sao một lựa chọn đáng đầu tư và các điều kiện tạo lợi ích. Charter xác nhận dự án được phép bắt đầu để thực hiện mục tiêu nào, trong giới hạn nào và do ai điều hành. Hồ sơ có thể được tổ chức chung theo quy trình doanh nghiệp, nhưng hai câu hỏi này vẫn cần câu trả lời riêng.
Ở giai đoạn đầu, chưa chắc mọi yêu cầu chi tiết đã đủ rõ. Điều đó không ngăn doanh nghiệp khởi động một phần công việc có giới hạn, chẳng hạn khảo sát và thử nghiệm. Charter phải chỉ ra phần được phép thực hiện, nguồn lực được sử dụng và điểm cần xem xét tiếp. Một quyết định cho phép nghiên cứu không nên bị hiểu thành quyền triển khai toàn bộ giải pháp.
Người phê duyệt cần có thẩm quyền theo cơ chế tổ chức. Sponsor chịu trách nhiệm bảo trợ và thúc đẩy quyết định liên quan đến mục tiêu đầu tư, nhưng quyền sử dụng ngân sách hay nhân sự có thể cần các xác nhận khác. Người quản lý dự án phải biết những giới hạn đó trước khi giao việc. Tên chức danh trên văn bản chưa đủ nếu quyền chưa được giao thực tế.
PMI mô tả Charter như cơ sở chính thức hóa dự án và quyền của người quản lý. Khi áp dụng vào IT, nên giữ nội dung ngắn nhưng có thể sử dụng trong điều hành. Năng lực quản lý dự án IT bắt đầu từ việc hiểu mình được giao điều gì trước khi xây dựng lịch chi tiết.
Viết mục tiêu từ sự thay đổi trong công việc
Một mục tiêu như “triển khai cổng dịch vụ hiện đại” dễ tạo sự đồng thuận vì chưa buộc ai lựa chọn. Mục tiêu hữu ích hơn phải chỉ ra hoạt động cần cải thiện, nhóm sử dụng và cách kiểm chứng. Trong tình huống mở bài, doanh nghiệp cần xác định ưu tiên là tiếp nhận yêu cầu có thể theo dõi, giảm việc hỏi lại hay đo chất lượng phục vụ. Những mục tiêu này có thể liên quan nhưng không mặc nhiên có cùng mức ưu tiên.
Sản phẩm bàn giao cần được tách khỏi kết quả kinh doanh. Cổng dịch vụ hoạt động là một đầu ra; yêu cầu được xử lý theo quy trình mới là một thay đổi sử dụng; chất lượng phục vụ được cải thiện là kết quả cần đo. Charter không cần chứa mọi phép tính, nhưng phải nêu cách xác nhận thành công và người chịu trách nhiệm cung cấp bằng chứng. Nếu đường cơ sở chưa có, việc thu thập nó phải thành một nhiệm vụ.
Các mục tiêu cũng cần được kiểm tra sự tương thích. Yêu cầu triển khai nhanh với nguồn lực hiện có có thể xung đột với mong muốn thay toàn bộ quy trình. Khi có xung đột, Sponsor và nghiệp vụ phải xác nhận điều gì được ưu tiên cùng phần có thể để sau. Không nên để nhóm kỹ thuật tự giải thích những sự đánh đổi thuộc trách nhiệm kinh doanh.
Tư duy liên kết mục tiêu với đầu tư trong chương trình Giám Đốc CNTT – CIO hỗ trợ cuộc trao đổi này. Khi mục tiêu đã đủ rõ, phạm vi ban đầu mới có một điểm tựa để lựa chọn thay vì trở thành danh sách mọi điều các bên muốn có.
Giữ phạm vi ban đầu đủ rõ nhưng không giả vờ biết hết
Charter cần mô tả các đầu ra chính, đơn vị áp dụng và những phần chưa được phép thực hiện. Với cổng dịch vụ, phải rõ loại yêu cầu nào nằm trong lần đầu, có tích hợp hệ thống nhân sự hay không và có thay quy trình phê duyệt hay chỉ đưa quy trình hiện có lên công cụ. Những ranh giới này ảnh hưởng lớn đến lịch, chi phí và trách nhiệm.
Phần chưa rõ nên được ghi bằng giả định và câu hỏi cần xác minh. Chẳng hạn, khả năng sử dụng dữ liệu nhân sự hiện có có thể là giả định quan trọng. Phải biết ai kiểm tra, kiểm tra trước quyết định nào và điều gì xảy ra nếu giả định không đúng. Ghi một giả định rồi không theo dõi sẽ chỉ chuyển bất định ra khỏi tầm nhìn của người phê duyệt.
Ràng buộc cần được phân biệt với mong muốn. Một thời điểm đóng hệ thống cũ đã được quyết định có thể là giới hạn cần bảo vệ; ngày ra mắt được đề nghị để thuận tiện truyền thông có thể còn thay đổi được. Người quản lý cần hỏi cơ sở của từng giới hạn. Nếu mọi mong muốn đều được ghi là bắt buộc, Charter dễ tạo ra cam kết không thể thực hiện.
Các điều kiện về nguồn lực cũng phải được xác nhận với người có quyền bố trí. Việc ghi tên chuyên gia hay đơn vị vào Charter không thay thế cam kết lịch làm việc. Sự tham gia của Trưởng Phòng IT – IT Manager giúp nối quyền khởi động với khả năng cung cấp đội ngũ. Phạm vi có thể rõ nhưng vẫn chưa khả thi nếu không có năng lực để thực hiện.
Tổ chức cuộc đối thoại trước khi xin chữ ký
Soạn Charter nên là kết quả của những cuộc trao đổi có cấu trúc. Người quản lý dự án có thể chuẩn bị bản nháp, nhưng cần lấy ý kiến của người sở hữu quy trình, đội kỹ thuật, vận hành và các bên chịu tác động quan trọng. Mục đích là tìm khác biệt trong cách hiểu khi chúng còn có thể xử lý với chi phí thấp, thay vì thu thập chữ ký trên một văn bản đã hoàn thiện hình thức.
Bảng dưới đây là công cụ đề xuất cho cuộc họp thống nhất. Mỗi câu trả lời nên gắn với người xác nhận và phần bằng chứng còn thiếu.
| Nội dung cần thống nhất | Câu hỏi đặt tại cuộc họp | Dấu hiệu chưa đủ cơ sở |
|---|---|---|
| Mục tiêu | Hoạt động nào phải thay đổi? | Chỉ mô tả tên hệ thống |
| Thành công | Ai xác nhận kết quả và dựa vào đâu? | Không có người cung cấp dữ liệu |
| Phạm vi | Lần đầu sẽ bao gồm và loại trừ gì? | Mỗi bên hiểu một ranh giới |
| Nguồn lực | Ai cam kết năng lực vào thời điểm cần? | Chỉ có danh sách nhân sự mong muốn |
| Quyền điều hành | Người quản lý được chốt việc gì? | Mọi quyết định đều phải hỏi lại |
| Bất định | Điều gì phải xác minh trước bước tiếp? | Giả định được ghi như dữ kiện |
Một khác biệt được phát hiện không đồng nghĩa với việc dự án chưa nên làm. Có thể thu hẹp phần khởi động để giải quyết bất định trước. Ví dụ giả định, nếu dữ liệu nhân sự chưa đủ rõ, Charter có thể cho phép khảo sát và thử một quy trình giới hạn, rồi đặt một điểm xem xét trước khi mua thêm năng lực hoặc mở rộng tích hợp.
Sau cuộc đối thoại, phải ghi lại các quyết định đã đạt và nội dung còn mở. Sự đồng thuận không có nghĩa mọi bên nhận đủ mong muốn của mình. Nó có nghĩa các bên hiểu lựa chọn đã được phê duyệt, hệ quả và trách nhiệm thực hiện. Những phản đối chưa giải quyết cần được đưa đến đúng người có quyền, không xóa khỏi văn bản để cuộc họp kết thúc thuận lợi.
Trao quyền và chuyển Charter thành nền tảng kế hoạch
Charter được phê duyệt cần trở thành tài liệu tham chiếu trong bước lập kế hoạch. Đội dự án dùng mục tiêu và phạm vi cấp cao để phân rã công việc, xác định điều kiện nghiệm thu và xây dựng lịch. Các giả định cần được đưa vào hoạt động xác minh, còn rủi ro ban đầu phải có người theo dõi. Nếu văn bản chỉ được lưu để hoàn tất thủ tục, khoảng cách giữa chủ trương và thực thi vẫn giữ nguyên.
Quyền của người quản lý cần được diễn đạt theo quyết định cụ thể. Ví dụ, họ có thể sắp xếp công việc trong nguồn lực đã giao, nhưng thay mục tiêu, tăng ngân sách hoặc chấp nhận rủi ro vượt giới hạn cần trình cấp có thẩm quyền. Cơ chế này gắn với năng lực Giám Đốc Dự Án IT – Project Manager, nơi điều hành triển khai phải đi cùng trách nhiệm bảo vệ mục tiêu đầu tư.
Khi có thông tin mới, cần xem nó làm thay đổi kế hoạch chi tiết hay làm mất cơ sở của quyết định khởi động. Một phát hiện nhỏ có thể được xử lý trong quyền được giao. Một thay đổi khiến mục tiêu hoặc phạm vi cấp cao không còn phù hợp cần được xem lại bằng quy trình phê duyệt. Việc cập nhật không nên diễn ra âm thầm chỉ để văn bản trông khớp với thực tế.
Trước buổi kickoff tiếp theo, có thể yêu cầu từng đầu mối diễn đạt bằng lời của mình về mục tiêu, phần họ đóng góp và quyết định nào phải trình lên. Nếu các câu trả lời khác nhau, hãy sửa sự khác biệt đó trước khi giao thêm việc. Charter tốt giúp cuộc họp khởi động có một nền tảng chung: dự án được phép thực hiện điều gì, với ai và trên cơ sở nào.