Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 8 — Project Charter — Văn bản khai sinh dự án

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa được sếp giao "chạy" một dự án mới. Bạn hào hứng bắt tay vào lập kế hoạch, tuyển người, đặt ngân sách. Rồi ba tuần sau, một trưởng phòng khác bước vào phòng họp, khoanh tay và hỏi: "Ai cho phép anh dùng nhân sự của phòng tôi? Ai duyệt số tiền này? Mục tiêu thực sự của dự án là gì mà tôi chưa từng nghe?". Bạn ú ớ. Bạn không có gì trong tay để chứng minh rằng dự án này là chính thức, rằng bạn có quyền điều động tài nguyên, và rằng mục tiêu đã được lãnh đạo thông qua.

Đó chính xác là khoảnh khắc mà một Project Charter (Điều lệ dự án) lẽ ra phải cứu bạn. Trong PMBOK, Project Charter là văn bản đầu tiên và quan trọng bậc nhất của cả vòng đời dự án — nó là "giấy khai sinh" chính thức. Không có Charter, dự án của bạn về mặt tổ chức là chưa tồn tại: chưa được cấp phép, chưa có người chịu trách nhiệm rõ ràng, và Project Manager (PM) chưa có thẩm quyền hợp pháp để tiêu tiền hay điều người.

Nhiều PM trẻ ở Việt Nam thường bỏ qua bước này vì nghĩ "nội bộ với nhau, cần gì giấy tờ". Đó là một sai lầm đắt giá. Bài học hôm nay sẽ giúp bạn hiểu Charter thực sự là gì, nó chứa những gì, ai ký, và quan trọng nhất — làm sao viết được một Charter đủ sức bảo vệ bạn và định hướng cho cả dự án.

Khái niệm cốt lõi

Project Charter là gì?

Theo PMBOK, Project Charter là văn bản do người bảo trợ (sponsor) ban hành, chính thức khởi tạo dự án và trao quyền cho Project Manager sử dụng tài nguyên của tổ chức vào các hoạt động của dự án.

Hãy chú ý hai vế then chốt trong định nghĩa này:

  • Chính thức khởi tạo dự án: Trước khi có Charter, mọi thứ chỉ là ý tưởng, đề xuất, thảo luận hành lang. Sau khi Charter được ký, dự án chính thức tồn tại trên bản đồ của tổ chức.
  • Trao quyền cho PM: Đây là điểm mà nhiều người bỏ lỡ. Charter không chỉ mô tả dự án — nó bổ nhiệm PM và cho PM quyền điều động tiền bạc, con người, thiết bị. Nếu tên bạn nằm trong Charter với vai trò PM, bạn có cơ sở chính danh để làm việc.

Vì sao phải là Sponsor ký, không phải PM?

Một nguyên tắc vàng của PMBOK: PM không tự tạo ra Charter để rồi tự trao quyền cho chính mình. Charter phải được ban hành bởi một người ở cấp cao hơn dự án — thường là sponsor, giám đốc điều hành, hoặc hội đồng đầu tư (steering committee). Lý do rất logic: quyền lực phải đến từ trên xuống. Bạn không thể tự viết giấy phép cho chính mình rồi bảo mọi người tuân theo.

Trong thực tế, PM thường là người soạn thảo Charter (vì PM hiểu chi tiết nhất), nhưng người ký duyệt và ban hành phải là sponsor. Chữ ký của sponsor mới là thứ tạo ra thẩm quyền.

Charter khác gì với Business Case và Project Plan?

Đây là ba văn bản dễ bị nhầm lẫn:

  • Business Case (Luận chứng kinh doanh): Trả lời câu hỏi "Có nên làm dự án này không?". Nó phân tích chi phí, lợi ích, ROI, rủi ro tài chính. Business Case có trước Charter.
  • Project Charter: Trả lời câu hỏi "Dự án này chính thức là gì, ai làm, và tại sao?". Nó ra đời sau khi Business Case được duyệt, và đánh dấu điểm khởi động.
  • Project Management Plan (Kế hoạch quản lý dự án): Trả lời câu hỏi "Chúng ta sẽ làm như thế nào?". Đây là văn bản chi tiết, ra đời sau Charter, trong giai đoạn lập kế hoạch (không thuộc phạm vi bài này).
Nói ngắn gọn: Business Case là "vì sao", Charter là "khai sinh + cấp phép", còn Plan là "làm sao". Charter đứng ở giữa — ngắn gọn nhưng đầy quyền lực.

Nội dung tối thiểu của một Project Charter

Một Charter tốt thường gói gọn trong 1–3 trang, nhưng phải chứa các thành phần cốt lõi sau:

  • Mục đích & lý do (Project purpose / justification): Vì sao dự án tồn tại? Nó giải quyết vấn đề gì hoặc nắm bắt cơ hội nào?
  • Mục tiêu đo lường được & tiêu chí thành công (Measurable objectives & success criteria): Khi nào thì coi là thành công? Ví dụ: "Giảm thời gian xử lý đơn hàng từ 48h xuống 12h trong Q4".
  • Yêu cầu cấp cao & mô tả dự án (High-level requirements & description): Dự án bao gồm những gì ở mức tổng quan.
  • Ranh giới phạm vi cấp cao (High-level scope, gồm cả những gì KHÔNG làm).
  • Rủi ro tổng thể cấp cao (High-level risks).
  • Mốc thời gian tóm tắt (Summary milestone schedule).
  • Ngân sách tóm tắt (Summary budget).
  • Danh sách stakeholder chính (chỉ ở mức khởi đầu — phân tích chi tiết là ở Bài 9).
  • Yêu cầu phê duyệt (Approval requirements): Ai quyết định dự án thành công? Ai có quyền ký nghiệm thu?
  • PM được bổ nhiệm, mức thẩm quyền và trách nhiệm (Assigned PM, authority level).
  • Tên và thẩm quyền của sponsor (người ký Charter).
Không phải Charter nào cũng cần đủ 11 mục, nhưng thiếu mục "bổ nhiệm PM + thẩm quyền" và "mục đích" thì đó không còn là Charter đúng nghĩa.

Tình huống thực tế

Tình huống 1 — Ngân hàng số tại TP.HCM: Charter cứu PM khỏi "cuộc chiến tài nguyên"

Một ngân hàng thương mại cổ phần ở TP.HCM (gọi tắt là VietBank) triển khai dự án ra mắt ứng dụng mobile banking mới, ngân sách 25 tỷ đồng, mục tiêu go-live trong 9 tháng. Chị Lan được bổ nhiệm làm PM.

Ngay tuần đầu, chị Lan cần 3 lập trình viên backend từ phòng Core Banking. Trưởng phòng Core Banking từ chối vì "team đang bận bảo trì hệ thống". Nếu là một PM thiếu kinh nghiệm, chị Lan sẽ mắc kẹt tại đây.

Nhưng chị đã yêu cầu sponsor — Phó Tổng Giám đốc phụ trách công nghệ — ký một Charter rõ ràng, trong đó ghi: "PM Nguyễn Thị Lan được trao quyền điều động nhân sự IT ở mức ưu tiên P1 cho dự án; các trưởng phòng liên quan có trách nhiệm hỗ trợ nguồn lực theo yêu cầu của PM". Charter được gửi qua email tới toàn bộ ban lãnh đạo cấp trung.

Khi trưởng phòng Core Banking từ chối, chị Lan chỉ cần forward lại Charter kèm một câu: "Nếu anh không thể bố trí, mình cùng trình bày với Phó Tổng để anh ấy quyết định thứ tự ưu tiên nhé". Trong vòng hai ngày, ba lập trình viên được điều sang.

Bài học: Charter không phải giấy tờ hình thức. Nó là vũ khí chính danh của PM trong các cuộc tranh chấp tài nguyên nội bộ — vốn là chuyện xảy ra ở gần như mọi dự án tại Việt Nam, nơi cơ cấu tổ chức thường theo kiểu functional (theo chức năng).

Tình huống 2 — Công ty gia công phần mềm ở Đà Nẵng: Charter mơ hồ dẫn đến scope creep

Một công ty outsourcing tại Đà Nẵng nhận dự án xây dựng hệ thống quản lý kho cho khách hàng Nhật Bản. PM là anh Minh. Vì "khách quen", anh Minh không làm Charter cẩn thận — chỉ có một email trao đổi chung chung về việc "làm hệ thống quản lý kho".

Ba tháng sau, khách hàng liên tục yêu cầu thêm: tích hợp với hệ thống kế toán, thêm module báo cáo BI, thêm app cho thủ kho quét mã QR. Mỗi lần anh Minh muốn từ chối hoặc tính thêm phí, khách hàng đều nói: "Cái này nằm trong 'quản lý kho' mà, sao tính thêm?". Không có Charter ghi rõ ranh giới phạm vi cấp cao và phần "KHÔNG bao gồm", anh Minh không có căn cứ để bảo vệ. Dự án đội chi phí 40%, trễ 2 tháng, và team kiệt sức.

Bài học: Một Charter dù ngắn nhưng ghi rõ high-level scope và đặc biệt là out-of-scope (những gì không làm) sẽ là lá chắn đầu tiên chống lại scope creep. Với các dự án gia công cho khách nước ngoài, phần này còn quan trọng gấp bội vì nó gắn với điều khoản hợp đồng và thanh toán.

Tình huống 3 — Startup thương mại điện tử: Charter giúp "cắt máu" đúng lúc

Một startup e-commerce ở Hà Nội khởi động dự án xây dựng tính năng livestream bán hàng, dự kiến 4 tháng, ngân sách 800 triệu. Trong Charter, sponsor (CEO) đặt tiêu chí thành công rất rõ: "Đạt tối thiểu 2.000 lượt xem đồng thời và tỷ lệ chuyển đổi 3% trong tháng đầu ra mắt; nếu không đạt, dự án sẽ được đánh giá lại để quyết định dừng hay tiếp tục".

Đến tháng thứ 3, một phiên bản thử nghiệm cho thấy hạ tầng streaming quá tốn kém và tỷ lệ xem chỉ đạt 400 người. Nhờ tiêu chí thành công đo lường được trong Charter, ban lãnh đạo có căn cứ khách quan để dừng dự án sớm, tiết kiệm 300 triệu còn lại thay vì "đâm lao phải theo lao".

Bài học: Tiêu chí thành công đo lường được trong Charter không chỉ để ăn mừng khi thắng, mà còn là cơ chế để tổ chức dũng cảm dừng lại khi cần. Charter tốt bảo vệ cả tiền của công ty lẫn uy tín của PM.

Hướng dẫn từng bước

Dưới đây là quy trình soạn thảo một Project Charter hoàn chỉnh:

Bước 1 — Thu thập đầu vào. Trước khi viết, hãy gom các tài liệu nền: Business Case đã được duyệt, hợp đồng hoặc thỏa thuận (nếu là dự án cho khách hàng), các văn bản chiến lược của công ty, và mọi tài sản quy trình có sẵn (mẫu Charter cũ, bài học từ dự án trước).

Bước 2 — Làm rõ mục đích và lý do. Viết 2–4 câu trả lời thẳng vào câu hỏi: "Dự án này giải quyết vấn đề gì?". Tránh viết chung chung kiểu "nâng cao hiệu quả". Hãy cụ thể: "Rút ngắn thời gian duyệt hồ sơ vay từ 5 ngày xuống 2 ngày để giảm tỷ lệ khách bỏ đi 15%".

Bước 3 — Định nghĩa mục tiêu đo lường được và tiêu chí thành công. Áp dụng nguyên tắc SMART (cụ thể, đo được, khả thi, liên quan, có thời hạn). Mỗi mục tiêu phải có con số và mốc thời gian.

Bước 4 — Phác thảo phạm vi cấp cao. Liệt kê những gì dự án sẽ làm và — cực kỳ quan trọng — những gì sẽ không làm. Đây là nơi bạn cắm cọc ranh giới.

Bước 5 — Ghi nhận rủi ro, mốc và ngân sách tổng thể. Ở mức khởi đầu, chỉ cần liệt kê 3–5 rủi ro lớn nhất, các mốc chính (không phải lịch chi tiết), và một con số ngân sách ước lượng.

Bước 6 — Xác định stakeholder chính và yêu cầu phê duyệt. Ai là người liên quan chủ chốt? Ai có quyền tuyên bố dự án thành công?

Bước 7 — Bổ nhiệm PM và ghi rõ mức thẩm quyền. Nêu tên PM và mô tả cụ thể quyền hạn: được duyệt chi tới mức nào, được điều động nhân sự nào, ra quyết định gì mà không cần xin phép thêm.

Bước 8 — Trình sponsor phê duyệt và ký. Đây là bước biến văn bản thành thẩm quyền thực. Không có chữ ký sponsor, Charter chỉ là bản nháp.

Bước 9 — Truyền thông Charter. Gửi Charter đã ký tới toàn bộ stakeholder chính và các trưởng bộ phận liên quan. Charter chỉ phát huy sức mạnh khi mọi người biết nó tồn tại.

Lỗi thường gặp & mẹo

Lỗi 1 — Bỏ qua Charter vì "nội bộ, quen biết". Đây là lỗi phổ biến nhất ở môi trường Việt Nam. Kết quả là PM không có thẩm quyền chính danh, dễ bị các phòng ban khác "đá bóng". Mẹo: Dù dự án nhỏ, hãy làm một Charter 1 trang. Ngắn nhưng có còn hơn không.

Lỗi 2 — PM tự viết rồi tự ký. Charter không do sponsor ký thì vô giá trị về mặt thẩm quyền. Mẹo: Bạn soạn, nhưng luôn đẩy lên đúng người có quyền để ký ban hành.

Lỗi 3 — Viết Charter dài như một Project Plan. Charter không phải kế hoạch chi tiết. Nhồi lịch Gantt, WBS đầy đủ vào Charter là nhầm vai trò của nó. Mẹo: Giữ Charter ở mức cấp cao (high-level), tối đa 1–3 trang. Chi tiết để dành cho Kế hoạch quản lý dự án.

Lỗi 4 — Mục tiêu chung chung không đo được. "Cải thiện trải nghiệm khách hàng" không phải mục tiêu — nó là khẩu hiệu. Mẹo: Mọi mục tiêu phải trả lời được câu "Làm sao biết đã đạt?".

Lỗi 5 — Quên phần out-of-scope. Không ghi rõ những gì KHÔNG làm là mở cửa cho scope creep. Mẹo: Luôn có một đoạn "Ngoài phạm vi" trong Charter.

Lỗi 6 — Không truyền thông Charter. Charter nằm trong ổ cứng của PM thì không bảo vệ được ai. Mẹo: Gửi công khai cho stakeholder ngay sau khi ký.

Bài tập thực hành

Hãy chọn một dự án bạn đang hoặc sắp làm (hoặc dùng tình huống giả định: "Công ty bạn muốn xây website đặt lịch khám cho một phòng khám tư ở Hà Nội, ngân sách 500 triệu, thời gian 5 tháng").

  • Soạn một Project Charter 1 trang với đầy đủ các mục tối thiểu: mục đích, 3 mục tiêu SMART, phạm vi cấp cao (gồm cả phần ngoài phạm vi), 3 rủi ro lớn, ngân sách và mốc tóm tắt, PM được bổ nhiệm cùng mức thẩm quyền, và tên sponsor.
  • Viết cụ thể phần thẩm quyền của PM: liệt kê ít nhất 3 quyền cụ thể (ví dụ: được duyệt chi tới 50 triệu không cần xin thêm; được điều động nhân sự từ 2 phòng ban).
  • Xác định ai nên là sponsor cho dự án này trong tổ chức của bạn, và giải thích vì sao người đó có đủ thẩm quyền ban hành Charter.
  • Tự phản biện: Nếu một stakeholder yêu cầu thêm một tính năng ngoài phạm vi, phần nào trong Charter của bạn sẽ giúp bạn bảo vệ ranh giới? Nếu chưa có, hãy bổ sung.
Hoàn thành bài tập này sẽ cho bạn một mẫu Charter thực dụng có thể tái sử dụng cho nhiều dự án sau.

Tóm tắt

  • Project Charter là "giấy khai sinh" chính thức của dự án — nó khởi tạo dự án và trao thẩm quyền cho PM sử dụng tài nguyên của tổ chức.
  • Sponsor ban hành và ký Charter, không phải PM. PM có thể soạn thảo, nhưng quyền lực đến từ chữ ký của người cấp trên.
  • Charter đứng giữa Business Case ("có nên làm không") và Project Management Plan ("làm thế nào") — nó ngắn gọn nhưng đầy quyền lực.
  • Nội dung tối thiểu gồm: mục đích, mục tiêu đo lường được, phạm vi cấp cao (gồm out-of-scope), rủi ro, mốc và ngân sách tóm tắt, stakeholder chính, yêu cầu phê duyệt, và đặc biệt là bổ nhiệm PM cùng mức thẩm quyền.
  • Trong môi trường tổ chức theo chức năng phổ biến ở Việt Nam, Charter là vũ khí chính danh của PM trong các cuộc tranh chấp tài nguyên, là lá chắn chống scope creep, và là cơ chế giúp tổ chức dừng đúng lúc.
  • Đừng bỏ qua Charter dù dự án nhỏ; đừng viết nó dài như Plan; và luôn truyền thông Charter đã ký tới toàn bộ stakeholder chính.
Charter là bước đầu tiên bạn làm đúng để cả dự án đi đúng. Ở bài tiếp theo, chúng ta sẽ đào sâu vào việc nhận diện và phân tích stakeholder — những con người quyết định thành bại của dự án.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi