Mở đầu — vì sao bài này quan trọng
Trong thực tế, tôi thấy rất nhiều dự án ở Việt Nam "chết mà không được chôn cất tử tế". Nghĩa là sản phẩm đã bàn giao, khách hàng đã dùng, đội ngũ đã giải tán sang dự án mới — nhưng chưa ai chính thức tuyên bố dự án đóng, chưa ai ký biên bản nghiệm thu cuối cùng, và bài học kinh nghiệm thì trôi tuột vào quên lãng. Ba tháng sau, kế toán vẫn treo một khoản chưa quyết toán với nhà thầu phụ, hoặc một bạn PM mới lại mắc đúng cái lỗi mà dự án trước đã "học" nhưng không ai ghi lại.
Project Closing (đóng dự án) là giai đoạn cuối cùng trong vòng đời dự án, nhưng lại là giai đoạn bị xem nhẹ nhất. Với kỳ thi PMP, đây là một chủ đề "béo bở" vì đề thi rất thích hỏi về thứ tự công việc khi đóng dự án: cái gì làm trước, cái gì làm sau, và đặc biệt là vai trò của Lessons Learned. Trong tư duy PMBOK 7, đóng dự án không chỉ là thủ tục hành chính — nó là hành động thể hiện tính Stewardship (trách nhiệm quản lý) và cam kết với tổ chức về việc chuyển giao giá trị và tri thức.
Bài này tập trung vào năm nhóm hoạt động cốt lõi khi đóng dự án: nghiệm thu bàn giao chính thức, đóng hợp đồng mua sắm, giải phóng nguồn lực, báo cáo cuối cùng, và quan trọng nhất — bài học kinh nghiệm. Đây là phần "hạ cánh an toàn" của mọi dự án.
Khái niệm cốt lõi
Đóng dự án (Close Project or Phase) là quá trình hoàn tất tất cả các hoạt động của dự án hoặc một giai đoạn, để chính thức kết thúc nó. Lưu ý quan trọng cho kỳ thi: chúng ta đóng dự án ngay cả khi dự án bị hủy giữa chừng (terminated), chứ không chỉ khi dự án thành công. Một dự án bị dừng vì cắt ngân sách vẫn phải trải qua quy trình đóng chính thức.
1. Nghiệm thu bàn giao chính thức (Formal deliverable acceptance)
Đây là bước xác nhận rằng sản phẩm/dịch vụ/kết quả đã đáp ứng tiêu chí nghiệm thu (acceptance criteria) và được khách hàng hoặc nhà tài trợ ký chấp nhận chính thức. Từ khóa quan trọng là "formal" — nghĩa là có văn bản, có chữ ký, chứ không phải một câu "ok em, dùng được rồi" qua Zalo. Đầu vào của bước này thường là các deliverable đã được xác minh (verified deliverables) từ quá trình kiểm soát chất lượng. Đầu ra là "accepted deliverables" — sản phẩm được nghiệm thu.
Vì sao PMP nhấn mạnh tính chính thức? Vì chữ ký nghiệm thu là ranh giới pháp lý chuyển giao trách nhiệm và rủi ro từ nhà cung cấp sang khách hàng. Không có nó, bạn không có bằng chứng để bảo vệ mình khi có tranh chấp.
2. Đóng hợp đồng mua sắm (Contract / Procurement closure)
Nếu dự án có sử dụng nhà thầu, nhà cung cấp bên ngoài, bạn phải đóng từng hợp đồng một. Điều này bao gồm: xác nhận nhà thầu đã hoàn thành đúng phạm vi hợp đồng, giải quyết mọi khiếu nại (claims) còn tồn đọng, thanh toán khoản cuối, và lưu trữ hồ sơ hợp đồng. Quy tắc vàng của PMP: procurement closure phải hoàn tất TRƯỚC khi đóng dự án tổng thể. Lý do logic: bạn không thể tuyên bố dự án đóng nếu vẫn còn một hợp đồng treo lơ lửng.
Một điểm hay bị bẫy: hợp đồng có thể được đóng sớm (early termination) do thỏa thuận chung, do vi phạm, hoặc do một bên tiện lợi (termination for convenience). Trong mọi trường hợp, vẫn phải có thủ tục đóng chính thức.
3. Giải phóng nguồn lực (Release resources)
Sau khi mọi việc hoàn tất, PM giải phóng nguồn lực: con người trở về bộ phận chức năng hoặc chuyển sang dự án khác, thiết bị được trả lại, giấy phép phần mềm được thu hồi, văn phòng dự án được trả mặt bằng. Đây không chỉ là chuyện logistics — nó liên quan đến chi phí. Giữ nguồn lực lâu hơn cần thiết là đốt tiền của tổ chức. PMP đề cao việc giải phóng nguồn lực đúng lúc như một biểu hiện của trách nhiệm tài chính.
4. Báo cáo cuối cùng (Final report)
Final report tổng kết dự án: mục tiêu ban đầu so với kết quả thực tế, phạm vi đã hoàn thành, chất lượng đạt được, so sánh ngân sách kế hoạch với chi phí thực tế, so sánh tiến độ, tổng hợp rủi ro đã xảy ra, và đánh giá mức độ đạt được lợi ích kinh doanh (benefits). Đây là tài liệu chính thức "kết sổ" dự án.
5. Bài học kinh nghiệm (Lessons Learned)
Đây là linh hồn của việc đóng dự án. Lessons Learned là tri thức thu được trong suốt dự án về những gì đã diễn ra tốt, những gì diễn ra tệ, và những gì cần làm khác đi. Điểm mấu chốt mà nhiều người hiểu sai: Lessons Learned KHÔNG chỉ làm ở cuối dự án. Trong PMBOK, đội ngũ duy trì một "Lessons Learned Register" (sổ đăng ký bài học) và cập nhật nó liên tục trong suốt vòng đời. Đến cuối dự án, các bài học được tổng hợp và chuyển vào "Lessons Learned Repository" — kho tri thức của tổ chức (một phần của OPA — Organizational Process Assets) để các dự án tương lai tra cứu.
Bài học tốt phải trả lời được: Chuyện gì đã xảy ra? Nguyên nhân gốc rễ là gì? Tác động ra sao? Lần sau nên làm gì? Một bài học chỉ ghi "giao tiếp kém" là vô dụng — phải cụ thể tới mức người khác đọc là hành động được.
Tình huống thực tế
Ví dụ 1: Công ty phần mềm ở TP.HCM và hợp đồng nhà thầu bị bỏ quên
Một công ty gia công phần mềm ở quận 7, TP.HCM (gọi là VinaSoft) hoàn thành dự án xây dựng hệ thống bán hàng cho một chuỗi bán lẻ. Sản phẩm đã go-live, khách hàng hài lòng, đội dev đã chuyển sang dự án mới. PM tưởng dự án đã "xong".
Bốn tháng sau, phòng kế toán phát hiện một nhà thầu phụ thiết kế UI/UX vẫn còn hóa đơn 85 triệu đồng chưa thanh toán, kèm một email khiếu nại về việc thanh toán chậm. Tệ hơn, hợp đồng chưa được đóng chính thức nên không rõ nhà thầu đã bàn giao đủ artefact chưa. Khi cần chỉnh sửa giao diện, công ty phát hiện file thiết kế gốc (source Figma) chưa được thu hồi vì bước procurement closure bị bỏ qua.
Bài học rút ra: Procurement closure phải hoàn tất trước khi tuyên bố đóng dự án. Nếu VinaSoft có checklist đóng dự án bắt buộc kiểm tra "tất cả hợp đồng đã đóng, đã thanh toán, đã thu hồi tài sản trí tuệ", 85 triệu và mớ rắc rối đó đã không tồn tại. Đây đúng là kiểu tình huống PMP hay hỏi: khi còn hợp đồng treo, bạn KHÔNG được đóng dự án.
Ví dụ 2: Dự án ERP bị hủy giữa chừng tại một tập đoàn sản xuất
Một tập đoàn sản xuất ở Bình Dương triển khai dự án ERP trị giá 12 tỷ đồng. Sau 8 tháng, ban lãnh đạo quyết định hủy dự án vì thay đổi chiến lược (chuyển sang giải pháp cloud khác). Đội dự án ngỡ ngàng, và phản ứng đầu tiên là "dự án chết rồi thì đóng làm gì cho mất công".
May mắn, PM là người có chứng chỉ PMP. Chị vẫn thực hiện đóng dự án đầy đủ: nghiệm thu chính thức những cấu phần đã hoàn thành (module kế toán đã chạy được, có thể tái sử dụng), đóng hợp đồng với nhà cung cấp phần mềm theo điều khoản termination for convenience (chấp nhận trả phí hủy hợp đồng), giải phóng đội ngũ, và đặc biệt viết một Final Report kèm Lessons Learned chi tiết.
Bài học ghi nhận: "Việc chọn giải pháp ERP on-premise mà không đánh giá đủ định hướng cloud của tập đoàn dẫn tới hủy dự án sau 8 tháng, thiệt hại khoảng 7 tỷ đồng. Nguyên nhân gốc: business case ban đầu không được phê duyệt bởi ban chiến lược. Khuyến nghị: mọi dự án hạ tầng trên 5 tỷ phải qua hội đồng kiến trúc doanh nghiệp trước khi khởi động." Sáu tháng sau, chính bài học này giúp tập đoàn tránh một sai lầm tương tự trong dự án MES.
Bài học rút ra: Dự án bị hủy vẫn phải đóng chính thức. Và Lessons Learned từ một thất bại thường có giá trị hơn từ một thành công — miễn là nó được ghi lại đủ cụ thể để hành động.
Ví dụ 3: Buổi họp Lessons Learned biến thành đấu tố
Một agency marketing ở Hà Nội tổ chức buổi retrospective cuối dự án cho một chiến dịch bị trễ hạn 3 tuần. Không khí buổi họp nhanh chóng trở thành "đổ lỗi": team creative đổ cho team account nhận brief mập mờ, account đổ cho client đổi yêu cầu liên tục. Kết quả: không ai muốn nói thật, biên bản chỉ ghi được vài dòng chung chung "cần cải thiện giao tiếp", và ba tháng sau lỗi y hệt lặp lại.
Ở dự án kế tiếp, PM đổi cách làm: đặt nguyên tắc "no blame" (không đổ lỗi), tập trung vào quy trình chứ không vào con người, dùng kỹ thuật "5 Whys" để đào nguyên nhân gốc, và mời một facilitator trung lập điều phối. Lần này bài học rút ra cụ thể: "Brief không có mục acceptance criteria rõ ràng khiến creative làm lại 3 vòng. Hành động: áp dụng template brief bắt buộc có mục tiêu đo lường được, ký duyệt trước khi bắt đầu sản xuất." Bài học này được đưa vào quy trình chuẩn của agency.
Bài học rút ra: Chất lượng của Lessons Learned phụ thuộc vào tâm lý an toàn (psychological safety). Nếu người ta sợ bị trừng phạt, họ sẽ giấu sự thật, và bạn học được rác.
Hướng dẫn từng bước
Đây là quy trình đóng dự án tôi khuyên bạn áp dụng, theo đúng logic PMP:
- Xác nhận công việc đã hoàn tất. Kiểm tra toàn bộ deliverable đã được xác minh (verified) qua kiểm soát chất lượng, đối chiếu với phạm vi trong project scope statement và WBS. Không được đóng khi còn hạng mục dở dang chưa được ghi nhận.
- Đóng các hợp đồng mua sắm. Với từng nhà thầu: xác nhận hoàn thành phạm vi, giải quyết claim, thực hiện thanh toán cuối, thu hồi tài sản/tài sản trí tuệ, lưu hồ sơ hợp đồng. Hoàn tất bước này TRƯỚC bước 3.
- Nghiệm thu bàn giao chính thức. Trình bày accepted deliverables cho khách hàng/nhà tài trợ, lấy chữ ký chấp nhận vào biên bản nghiệm thu. Đây là "formal sign-off".
- Giải phóng nguồn lực. Trả người về bộ phận, kết thúc hợp đồng thuê thiết bị, thu hồi license, cập nhật đánh giá hiệu suất thành viên (nếu tổ chức yêu cầu).
- Thu thập và hoàn thiện Lessons Learned. Tổ chức buổi họp với tinh thần no-blame. Tổng hợp Lessons Learned Register (vốn đã cập nhật suốt dự án) thành phiên bản cuối, và chuyển vào Lessons Learned Repository của tổ chức.
- Lập Final Report và bàn giao sản phẩm cho vận hành. Chuyển giao cho bộ phận vận hành/bảo trì, kèm tài liệu hướng dẫn. So sánh kế hoạch với thực tế trên các trục phạm vi, thời gian, chi phí, chất lượng, lợi ích.
- Cập nhật tài sản quy trình tổ chức (OPA) và lưu trữ hồ sơ. Cập nhật template, quy trình, cơ sở dữ liệu ước lượng. Lưu trữ toàn bộ tài liệu dự án theo chính sách lưu trữ.
- Tuyên bố đóng chính thức và ăn mừng. Đừng bỏ qua bước cuối này — công nhận nỗ lực của đội ngũ là một phần của lãnh đạo phục vụ (servant leadership).
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Lessons Learned là việc cuối dự án. Thực tế, đến cuối dự án thì người ta đã quên hết chi tiết, và nửa đội đã đi. Mẹo: cập nhật Lessons Learned Register liên tục sau mỗi mốc quan trọng, mỗi sự cố. Cuối dự án chỉ là tổng hợp lại.
Lỗi 2 — Bài học viết chung chung. "Cần cải thiện giao tiếp" là vô dụng. Mẹo: mỗi bài học phải có cấu trúc Tình huống → Nguyên nhân gốc → Tác động → Khuyến nghị hành động cụ thể. Dùng 5 Whys để đào tới gốc.
Lỗi 3 — Bỏ qua nghiệm thu chính thức. Nghiệm thu miệng qua chat không có giá trị pháp lý. Mẹo: luôn có biên bản nghiệm thu ký tên, đóng dấu — đặc biệt quan trọng khi có tranh chấp thanh toán.
Lỗi 4 — Đóng dự án khi hợp đồng còn treo. Đây là bẫy kinh điển của PMP. Mẹo nhớ: procurement closure ⟶ project closure, không bao giờ ngược lại.
Lỗi 5 — Không đóng dự án bị hủy. Nhiều người nghĩ dự án chết thì thôi. Mẹo: mọi dự án, dù thành công hay bị hủy, đều phải qua quy trình đóng chính thức.
Lỗi 6 — Buổi Lessons Learned biến thành đấu tố. Mẹo: thiết lập nguyên tắc no-blame, tập trung vào quy trình, dùng facilitator trung lập, đảm bảo tâm lý an toàn.
Mẹo thi PMP: Khi gặp câu hỏi "dự án gần hoàn thành, bạn làm gì tiếp theo?", hãy nhớ thứ tự: hoàn tất công việc → đóng hợp đồng → nghiệm thu chính thức → giải phóng nguồn lực → tài liệu hóa Lessons Learned → cập nhật OPA → đóng chính thức. Đề thi rất thích hỏi "cái gì làm ĐẦU TIÊN" hoặc "cái gì làm CUỐI CÙNG".
Bài tập thực hành
Bài tập 1 — Sắp xếp thứ tự. Cho các hoạt động sau, hãy sắp xếp theo đúng trình tự đóng dự án: (a) giải phóng đội ngũ, (b) thanh toán khoản cuối cho nhà thầu, (c) lấy chữ ký nghiệm thu của khách hàng, (d) cập nhật kho Lessons Learned của tổ chức, (e) xác minh deliverable qua kiểm soát chất lượng. Viết ra lý do cho thứ tự bạn chọn.
Bài tập 2 — Viết lại một bài học. Lấy một bài học chung chung "Dự án bị trễ do thiếu nhân sự" và viết lại theo cấu trúc Tình huống → Nguyên nhân gốc (dùng 5 Whys) → Tác động (con số cụ thể) → Khuyến nghị hành động. Mục tiêu: người đọc dự án sau có thể hành động ngay.
Bài tập 3 — Tình huống ra quyết định. Dự án của bạn đã bàn giao xong sản phẩm chính, khách hàng hài lòng. Nhưng còn một nhà thầu phụ đang khiếu nại về khối lượng công việc phát sinh chưa được thanh toán. Sếp giục bạn "đóng dự án ngay để giải phóng ngân sách". Bạn xử lý thế nào và giải thích với sếp ra sao? Viết câu trả lời khoảng 150 từ theo tư duy PMP.
Bài tập 4 — Tự soi dự án gần nhất của bạn. Liệt kê 3 điều dự án gần nhất của bạn (công việc hoặc học tập) làm tốt, và 3 điều cần làm khác đi. Với mỗi điều "cần làm khác", viết một khuyến nghị hành động cụ thể có thể áp dụng ngay cho lần sau.
Tóm tắt
Đóng dự án không phải thủ tục cho có — đó là hành động thể hiện tính chuyên nghiệp và trách nhiệm quản lý. Năm hoạt động cốt lõi cần nhớ: nghiệm thu bàn giao chính thức (có chữ ký, không phải nói miệng), đóng hợp đồng mua sắm (luôn trước khi đóng dự án tổng thể), giải phóng nguồn lực (đúng lúc để tiết kiệm chi phí), báo cáo cuối cùng (đối chiếu kế hoạch với thực tế), và bài học kinh nghiệm (linh hồn của việc đóng dự án).
Ba điểm cần khắc cốt ghi tâm: (1) Lessons Learned được cập nhật liên tục suốt dự án, không phải đợi tới cuối; (2) mọi dự án — kể cả bị hủy — đều phải đóng chính thức; (3) một bài học chỉ có giá trị khi nó cụ thể tới mức người khác hành động được, và chỉ thu được sự thật khi có tâm lý an toàn không đổ lỗi. Hãy nhớ: một dự án "hạ cánh" tử tế để lại di sản tri thức cho cả tổ chức, còn một dự án chết mà không được đóng sẽ để lại rắc rối và những sai lầm lặp lại.