Phụ lục B — Mẫu Project Charter + Business Case đầy đủ (FoodNow)

Bản in từ templates/project-charter/. Dùng làm điểm khởi đầu cho dự án của bạn; đọc kèm Ch05, Ch07, Ch08.

B.1 Business Case

📎 Nguồn: templates/project-charter/FoodNow-Business-Case.md

Tên tài liệu: Business Case — Ứng dụng đặt và giao đồ ăn FoodNow (MVP) Dự án: FoodNow MVP — FoodNow JSC & BrightSoft Phiên bản / ngày: v1.0 — 10/12/2025 (bản trình Hội đồng quản trị FoodNow) Mục đích & khi nào dùng: Chứng minh dự án đáng đầu tư trước khi ký Charter; dùng ở giai đoạn khởi động và khi cần bảo vệ ngân sách.

1. Vấn đề và cơ hội

• Vấn đề: FoodNow đang nhận đơn qua app bên thứ ba. Phí nền tảng cao, không sở hữu dữ liệu khách hàng, không tự làm được khuyến mãi và trải nghiệm riêng.
• Cơ hội: Có app riêng cho khách hàng, nhà hàng, tài xế và trang Admin để tự chủ dữ liệu, giảm phí trung gian và xây thương hiệu.
• Thời điểm: Hội đồng quản trị cần quyết định ngân sách trong tháng 12/2025 để bắt đầu 05/01/2026.

2. Các phương án

3. Chi phí – lợi ích (giả định nêu rõ)

Giả định kinh doanh (do FoodNow cung cấp, cần kiểm chứng sau go-live):

• Giá trị đơn trung bình: 165.000 VND; phí nền tảng thu bình quân 15% → biên đóng góp ≈ 25.000 VND/đơn (đã làm tròn).
• Mục tiêu ổn định: 500 đơn/ngày sau 3 tháng go-live; 3 tháng đầu trung bình 250 đơn/ngày.
• Chi phí vận hành hằng tháng sau go-live: 95 triệu VND (hạ tầng, license, bảo trì, hỗ trợ khách hàng).

Tính toán:

Phân tích độ nhạy: nếu chỉ đạt 350 đơn/ngày ổn định, lợi nhuận ròng ≈ 262,5 − 95 = 167,5 triệu/tháng; payback kéo dài ≈ 15,7 tháng (3 tháng đầu + phần còn lại), vẫn dưới 18 tháng. Nếu chỉ đạt 250 đơn/ngày, lợi nhuận chỉ 92,5 triệu/tháng và payback ≈ 26 tháng → đây là kịch bản dự án không đạt mục tiêu.

4. Chi phí đầu tư MVP (tóm tắt)

(Tổng làm tròn; chi tiết trong FoodNow-Budget.csv, Ch14.)

5. Tiêu chí thành công (đo được)

6. Rủi ro cấp cao

7. Khuyến nghị

Chọn phương án C. Đề nghị Hội đồng quản trị phê duyệt ngân sách MVP 2,4 tỷ VND (gồm dự phòng 12%) và cho phép ký Project Charter. Việc đầu tư R1 và R2 sẽ quyết định sau khi có số liệu 3 tháng sau go-live.

Cách dùng cho dự án của bạn

1. Nêu vấn đề và cơ hội trong 3–5 dòng; tránh mô tả giải pháp trước.
2. Luôn có phương án "không làm gì" và ít nhất một phương án thay thế.
3. Ghi giả định rõ ràng cho từng con số lợi ích và nói ai chịu trách nhiệm kiểm chứng.
4. Tính payback và ROI bằng công thức viết ra; thêm phân tích độ nhạy (kịch bản xấu).
5. Kết bằng khuyến nghị và quyết định cần Sponsor/HĐQT thông qua.

B.2 Project Charter

📎 Nguồn: templates/project-charter/FoodNow-Project-Charter.md

Tên tài liệu: Project Charter — FoodNow MVP Dự án: FoodNow MVP — FoodNow JSC & BrightSoft Phiên bản / ngày: v1.0 — ký ngày 15/12/2025 Mục đích & khi nào dùng: Văn bản chính thức khởi động dự án, trao quyền cho PM và chốt mục tiêu, ràng buộc; dùng ngay sau khi Business Case được duyệt.

1. Mục đích dự án

Xây dựng hệ thống đặt và giao đồ ăn FoodNow gồm 3 ứng dụng và trang Admin để FoodNow tự vận hành kênh bán hàng, sở hữu dữ liệu khách hàng và giảm phụ thuộc phí nền tảng bên thứ ba. (Liên kết: Business Case v1.0, 10/12/2025.)

2. Mục tiêu SMART

3. Ràng buộc ưu tiên

Scope: linh hoạt (cắt để giữ mốc) · Time: cố định (03/10/2026) · Cost: trần 2,4 tỷ · Quality: bất khả nhượng ở luồng thanh toán.

4. Phạm vi sơ bộ

5. Deliverable chính

Bản phát hành MVP đã qua UAT; tài liệu vận hành; bộ kiểm thử; hạ tầng production; đào tạo người dùng; báo cáo đóng dự án.

6. Mốc chính

7. Ngân sách sơ bộ

Chi phí kế hoạch 2,14 tỷ VND + dự phòng 12% (≈ 0,26 tỷ) = 2,4 tỷ VND. Nhân sự 78%, hạ tầng & license 9%, vendor 6%, đào tạo & khác 7% (tính trên chi phí kế hoạch).

8. Giả định và ràng buộc

Giả định: Đội 12 người sẵn sàng từ 05/01/2026 · Khách cung cấp API dữ liệu nhà hàng đúng hạn · PayEasy hoàn tất chứng nhận theo lịch · Sponsor và PO có mặt để quyết định trong 2 ngày làm việc. Ràng buộc: Ngân sách trần 2,4 tỷ · Go-live không sau 03/10/2026 (chiến dịch marketing đã lên kế hoạch) · Tuân thủ quy định bảo vệ dữ liệu cá nhân · Hợp đồng Hybrid: khung fixed-price theo giai đoạn + CR theo T&M.

9. Rủi ro cấp cao

10. Stakeholder chính

Trần Quốc Bảo (Sponsor/CEO) · Lê Minh Châu (PO) · Nguyễn Thu Hà (PM) · Phạm Đức Dũng (Tech Lead) · Vũ Thị Lan (BA) · Đỗ Hoàng Nam (QA Lead) · PayEasy (vendor thanh toán).

11. Quyền hạn của PM

Nguyễn Thu Hà được: (1) điều phối đội dự án và phân bổ công việc trong phạm vi ngân sách; (2) duyệt thay đổi nhỏ trong phạm vi, không ảnh hưởng mốc và ngân sách; (3) sử dụng dự phòng đến 5% ngân sách (≈ 0,12 tỷ) mà không cần xin phê duyệt riêng, báo cáo sau; (4) leo thang trực tiếp đến Sponsor. Các thay đổi phạm vi, lịch hoặc dự phòng vượt mức này cần Sponsor phê duyệt.

12. Chữ ký

Cách dùng cho dự án của bạn

1. Copy cấu trúc mục 1–12; điền mục tiêu SMART và ràng buộc ưu tiên trước, phần còn lại sau.
2. Ghi rõ in-scope/out-of-scope ở mức sơ bộ; chi tiết để dành cho Scope Statement.
3. Viết quyền hạn của PM bằng ngưỡng cụ thể (tiền, ngày), không nói chung chung.
4. Giữ Charter tối đa 2–3 trang; nếu dài hơn, bạn đang viết kế hoạch chứ không phải Charter.
5. Gửi Sponsor ký; lưu bản đã ký làm nguồn tham chiếu khi có tranh cãi.

B.3 Scope Statement

📎 Nguồn: templates/project-charter/scope-statement.md

Tên tài liệu: Scope Statement — FoodNow MVP Dự án: FoodNow MVP Phiên bản / ngày: v1.1 — 13/02/2026 (v1.0 ngày 06/02/2026) Mục đích & khi nào dùng: Chốt ranh giới phạm vi làm căn cứ cho WBS, ước lượng và change control; dùng sau Charter, trước khi lập WBS.

1. Lịch sử phiên bản

2. Mô tả phạm vi sản phẩm (product scope)

Hệ thống đặt và giao đồ ăn cho khu vực nội thành Hà Nội gồm 3 ứng dụng, Admin web và các tích hợp bên thứ ba, phục vụ 3 loại người dùng: khách hàng, nhà hàng, tài xế.

3. Trong phạm vi (In-scope)

4. Ngoài phạm vi (Out-of-scope, tường minh)

5. Deliverable và tiêu chí chấp nhận

6. Giả định và ràng buộc

• Giả định: PayEasy hoàn tất chứng nhận theo lịch; khách cung cấp dữ liệu nhà hàng đúng hạn; đội đủ 12 người sau Sprint 0.
• Ràng buộc: go-live 03/10/2026; ngân sách 2,4 tỷ; tuân thủ bảo vệ dữ liệu cá nhân.

7. Cơ chế thay đổi phạm vi

Thay đổi ngoài bảng in-scope đi qua Change Request (Ch20): đánh giá tác động scope/time/cost/risk/quality → Sponsor duyệt → cập nhật baseline. Thay đổi trong epic (chi tiết story) điều chỉnh qua backlog bởi PO.

Cách dùng cho dự án của bạn

1. Liệt kê epic in-scope trước, sau đó liệt kê tường minh ít nhất 5 mục out-of-scope kèm lý do.
2. Với mỗi deliverable, viết tiêu chí chấp nhận có thể kiểm tra được và ghi người nghiệm thu.
3. Ghi phiên bản và người duyệt; mọi thay đổi phải nâng phiên bản.
4. Gửi Sponsor/PO duyệt bằng email và lưu dấu vết.
5. Dùng bảng này làm đầu vào cho WBS (Ch10) và Change Request (Ch20).

B.4 Team Charter và Working Agreement

📎 Nguồn: templates/project-charter/team-charter-working-agreement.md

Tên tài liệu: Team Charter & Working Agreement — Đội FoodNow Dự án: FoodNow MVP Phiên bản / ngày: v1.0 — 14/01/2026 (Sprint 0), do cả đội cùng thống nhất Mục đích & khi nào dùng: Ghi lại mục đích đội, vai trò, quy tắc làm việc và định nghĩa Ready/Done sơ bộ; dùng trong Sprint 0 và xem lại mỗi 4–6 sprint (ở retro).

1. Team Charter

Sứ mệnh đội: Giao MVP FoodNow đúng mốc 03/10/2026, chất lượng thanh toán bất khả nhượng, và làm việc theo cách để không ai phải làm đêm hai tuần liên tiếp.

Giá trị của đội: nói thật sớm · tôn trọng thời gian nhau · quyết định có dấu vết · học từ lỗi, không đổ lỗi.

Cơ cấu (12 người tương đương FTE; UX và DevOps 50%):

2. Working Agreement

3. Definition of Ready / Done (sơ bộ)

Definition of Ready (story sẵn sàng vào sprint):

• [ ] Có mô tả người dùng – mục đích – giá trị
• [ ] Có tiêu chí chấp nhận kiểm tra được
• [ ] Thiết kế UX (nếu cần) đã duyệt
• [ ] Phụ thuộc đã rõ; đã ước lượng
• [ ] Vừa trong một sprint

Definition of Done (story hoàn thành):

• [ ] Code đã review và merge
• [ ] Unit test viết và xanh; coverage không giảm
• [ ] QA kiểm thử theo tiêu chí chấp nhận
• [ ] Không còn bug Critical/High liên quan
• [ ] Tài liệu/API được cập nhật
• [ ] PO chấp nhận trong Review

(Bản đầy đủ: templates/quality/definition-of-done.md, Ch15.)

4. Cam kết và chữ ký

Chúng tôi đồng ý làm theo thoả thuận này và sửa đổi khi retro thấy cần.

Cách dùng cho dự án của bạn

1. Tổ chức workshop 60–90 phút trong Sprint 0; để cả đội đề xuất, đừng PM tự viết.
2. Chốt từng mục bằng câu "chúng ta có thể sống với điều này không?" — ai phản đối thì sửa.
3. Ghi cụ thể bằng số (giờ, ngày, dòng code) thay vì "sớm", "nhỏ".
4. In/đặt ở nơi đội thấy hằng ngày; nhắc lại khi có người mới.
5. Xem lại ở retro mỗi 4–6 sprint; đổi nếu thấy không hiệu quả.