Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Quản lý các bên liên quan
  2. /Hệ thống chạy ổn hai tháng mà khách hàng chưa ký…
Quản lý các bên liên quan· Domain: Bàn giao

Hệ thống chạy ổn hai tháng mà khách hàng chưa ký biên bản nghiệm thu: thiết kế tiêu chí và quy trình chấp nhận với khách hàng doanh nghiệp

Khách hàng dùng hệ thống hằng ngày nhưng biên bản nghiệm thu vẫn nằm trên bàn, kéo theo khoản thanh toán cuối và việc đóng dự án. Bài viết phân tích vì sao nghiệm thu bị treo và cách thiết kế tiêu chí chấp nhận, người ký, thời hạn phản hồi ngay từ đầu.

HP
Nguyễn Thu Hà, PMP
08/08/2026
6 phút đọc 0 0
Hệ thống chạy ổn hai tháng mà khách hàng chưa ký biên bản nghiệm thu: thiết kế tiêu chí và quy trình chấp nhận với khách hàng doanh nghiệp

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một nhà cung cấp hoàn thành hệ thống quản lý hợp đồng cho một tổng công ty bảo hiểm. Go-live diễn ra đúng hạn. Hai tháng sau, 400 người dùng vẫn làm việc hằng ngày trên hệ thống, số lỗi nghiêm trọng bằng không. Nhưng biên bản nghiệm thu chưa được ký, khoản thanh toán cuối (30% giá trị hợp đồng) chưa được giải ngân, đội dự án chưa được giải phóng.

Mỗi lần PM hỏi, đầu mối phía khách hàng lại đưa ra một lý do:

  • "Phòng Pháp chế muốn xem lại mẫu báo cáo."
  • "Còn 12 lỗi nhỏ về giao diện, sửa xong rồi ký."
  • "Trưởng ban mới về, anh ấy muốn tự kiểm tra lại."
  • "Chưa có tiêu chí rõ ràng thế nào là đạt."

Câu cuối cùng là câu đúng nhất. Hợp đồng chỉ ghi "nghiệm thu khi hệ thống đáp ứng yêu cầu", và tài liệu yêu cầu có hơn 300 mục, nhiều mục viết dạng "hệ thống thân thiện, dễ sử dụng".

Vì sao nghiệm thu bị treo ở khách hàng doanh nghiệp

  • Tiêu chí chấp nhận mơ hồ: không có định nghĩa đạt/không đạt, người ký sợ chịu trách nhiệm nếu sau này phát sinh vấn đề.
  • Không rõ ai có quyền ký: người duyệt yêu cầu, người dùng, phòng IT, phòng Pháp chế — mỗi bên nghĩ bên kia phải ký trước.
  • Ký nghiệm thu là "mất đòn bẩy": sau khi ký, khách hàng sợ nhà cung cấp không còn ưu tiên sửa lỗi.
  • Thay đổi người: người mới không muốn ký cho một việc họ không tham gia.

Về bản chất, đây không phải vấn đề kỹ thuật. Đây là vấn đề kỳ vọng và quyền ra quyết định của stakeholder — cần được thiết kế từ đầu dự án.

Phân tích theo PMBOK® Guide

  • Tiêu chí chấp nhận (acceptance criteria) là tập điều kiện phải đáp ứng trước khi sản phẩm bàn giao được chấp nhận. Chúng thuộc bản mô tả phạm vi dự án (project scope statement) và thường xuất hiện trong SOW — phần mô tả cách bên mua xác định sản phẩm, dịch vụ là chấp nhận được, thường bằng tiêu chí khách quan.
  • Control Quality xác nhận sản phẩm đúng (verified deliverables); Validate Scope là quá trình khách hàng hoặc nhà tài trợ chính thức chấp nhận sản phẩm đã hoàn thành (accepted deliverables). Hai bước khác nhau: đội có thể kiểm tra đạt, nhưng chỉ khách hàng mới chấp nhận.
  • Kiểm thử chấp nhận của người dùng (UAT) xác nhận giải pháp phục vụ được người dùng trong tình huống thật, khác kiểm thử hệ thống ở chỗ trọng tâm là nhu cầu nghiệp vụ.

Tình huống liên quan

Quản lý các bên liên quanCác bên liên quan

Người quyết định thật không có trong sơ đồ tổ chức: nhận diện và gắn kết stakeholder "ẩn"

Mọi cuộc họp với Phó Tổng giám đốc đều suôn sẻ, nhưng quyết định cứ bị "treo" sau đó. Hoá ra người được hỏi ý kiến cuối cùng là một chuyên gia lâu năm không có chức danh quản lý. Cách vẽ bản đồ ảnh hưởng không chính thức và gắn kết stakeholder ẩn mà không đi đường vòng.

Ngày đăng: 06/10/2026Lượt xem: 1Bình luận: 0
Quản lý các bên liên quanCác bên liên quan

Phòng Pháp chế "xuất hiện" sát ngày go-live: nhận diện stakeholder sớm với mô hình Salience

Một bộ phận chưa từng được mời họp bỗng đề nghị dừng go-live vì rủi ro tuân thủ. Vì sao nhận diện stakeholder phải làm sớm, lặp lại, và cách dùng mô hình Salience để ưu tiên.

Ngày đăng: 01/10/2026Lượt xem: 6Bình luận: 0
Quản lý các bên liên quanCác bên liên quan

Stakeholder quyền lực cao liên tục thay đổi yêu cầu: PM nên làm gì?

Giám đốc khối kinh doanh gửi yêu cầu mới mỗi tuần qua tin nhắn. Làm sao giữ quan hệ tốt mà vẫn bảo vệ được baseline dự án?

Ngày đăng: 01/10/2026Lượt xem: 1.245Bình luận: 3Đánh giá: 4.5
Agile & HybridBàn giao

Product Owner kiêm nhiệm "vắng mặt": khi backlog chờ quyết định cả tuần

Product Owner là trưởng phòng nghiệp vụ, chỉ dành được vài giờ mỗi tuần cho đội. Câu hỏi tồn đọng, đội tự đoán yêu cầu và làm lại. Cách chẩn đoán, khôi phục quyền ra quyết định và ủy quyền đúng cách.

Ngày đăng: 01/10/2026Lượt xem: 7Bình luận: 0
  • Close Project or Phase cần bằng chứng chấp nhận chính thức; thiếu nó, dự án không đóng được và nguồn lực bị giữ lại.
  • Cách làm: thiết kế nghiệm thu từ ngày đầu

    1. Viết tiêu chí chấp nhận đo được

    Mỗi nhóm yêu cầu chính có tiêu chí đạt/không đạt:

    • Chức năng: kịch bản UAT X, Y, Z chạy thành công với dữ liệu thật.
    • Hiệu năng: tra cứu hợp đồng dưới 3 giây với 200 người dùng đồng thời.
    • Chất lượng: không còn lỗi mức nghiêm trọng và cao; lỗi mức thấp có kế hoạch sửa.

    Câu "thân thiện, dễ sử dụng" cần được chuyển thành điều kiểm chứng được (ví dụ: 8/10 người dùng hoàn thành tác vụ mẫu không cần hướng dẫn).

    Một bảng tiêu chí chấp nhận gọn có thể trông như sau:

    NhómTiêu chíCách kiểm chứngNgười xác nhận
    Quy trình hợp đồng15 kịch bản UAT chính chạy thành côngBiên bản UAT có chữ ký người kiểm thửTrưởng ban nghiệp vụ
    Báo cáo8 báo cáo khớp số liệu với hệ thống cũ, sai lệch bằng 0Đối soát song song một kỳPhòng Kế toán
    Hiệu năngTra cứu dưới 3 giây, 200 người dùng đồng thờiKết quả kiểm thử tảiPhòng CNTT
    Lỗi tồn đọngKhông còn lỗi mức nghiêm trọng/caoBáo cáo hệ thống quản lý lỗiĐầu mối dự án phía khách hàng

    Mỗi dòng có cách kiểm chứng và người xác nhận — hai cột thường bị bỏ qua nhưng chính là thứ giúp người ký yên tâm.

    2. Phân loại lỗi và quy tắc ngưỡng

    Thống nhất trước: lỗi mức nào chặn nghiệm thu, lỗi mức nào cho phép nghiệm thu có điều kiện (ký kèm danh sách tồn đọng và thời hạn sửa). Điều này tránh tình trạng "còn 12 lỗi giao diện nên chưa ký".

    3. Xác định rõ người ký và trình tự

    Trong ma trận RACI, "ký nghiệm thu" chỉ có một người chịu trách nhiệm cuối cùng (Accountable) phía khách hàng; các phòng khác ở vai trò được tham vấn (Consulted) với thời hạn góp ý cụ thể.

    4. Thời hạn phản hồi và nghiệm thu từng phần

    Hợp đồng có thể quy định thời hạn phản hồi (ví dụ 10 ngày làm việc sau khi bàn giao biên bản). Một số hợp đồng còn có điều khoản nghiệm thu mặc nhiên (deemed acceptance) — nếu không có phản hồi trong thời hạn, sản phẩm được coi là đã chấp nhận. Điều khoản này cần được đàm phán công khai lúc ký hợp đồng, không dùng bất ngờ.

    Nghiệm thu từng phần (theo đợt bàn giao) giúp giảm áp lực cho lần ký cuối.

    5. Tách nghiệm thu khỏi nỗi lo "mất đòn bẩy"

    Khách hàng trì hoãn ký vì sợ bị bỏ rơi. Làm rõ cơ chế bảo hành, thời gian hypercare và cam kết thời gian xử lý lỗi sau nghiệm thu giúp họ yên tâm ký.

    Xử lý khi đã bị treo

    • Cùng đầu mối lập danh sách điều kiện còn thiếu để ký, đóng danh sách đó (không nhận thêm mục mới vào danh sách này; mục mới đi qua quy trình thay đổi hoặc bảo hành).
    • Gặp trực tiếp người có quyền ký, trình bày bằng chứng: kết quả UAT, số liệu vận hành hai tháng.
    • Với người mới nhận nhiệm vụ: tổ chức buổi trình bày ngắn về lịch sử quyết định, kèm biên bản phê duyệt trước đó.
    • Nếu vẫn bế tắc, dùng kênh leo thang đã thống nhất trong cơ chế quản trị dự án.

    Sai lầm thường gặp

    • Chỉ có tiêu chí ở mức "đáp ứng yêu cầu": không ai có thể chứng minh đạt hay không.
    • Nhầm Control Quality với Validate Scope: đội kiểm thử đạt không có nghĩa khách hàng đã chấp nhận.
    • Sửa tiếp mọi yêu cầu phát sinh để "được ký": nghiệm thu trở thành cửa ngõ cho scope creep.
    • Áp dụng nghiệm thu mặc nhiên một cách bất ngờ: thắng về hợp đồng nhưng mất khách hàng.

    Góc ôn thi PMP

    • Validate Scope: đầu vào là sản phẩm đã kiểm tra (verified deliverables); đầu ra là sản phẩm được chấp nhận (accepted deliverables), yêu cầu thay đổi, thông tin hiệu suất công việc.
    • Validate Scope chú trọng sự chấp nhận; Control Quality chú trọng tính đúng đắn. Thường Control Quality làm trước.
    • Câu hỏi "khách hàng từ chối ký nghiệm thu dù sản phẩm đạt kiểm thử" → xem lại tiêu chí chấp nhận đã thống nhất và làm rõ với khách hàng; không tự tuyên bố hoàn thành.

    Nguồn tham khảo

    • Wikipedia – Acceptance testing (UAT và định nghĩa acceptance criteria của PMI)
    • Wikipedia – Statement of work (mục acceptance criteria trong SOW)
    • Wikipedia – Responsibility assignment matrix (RACI)
    #khach-hang-doanh-nghiep#nghiem-thu#acceptance-criteria#validate-scope#uat

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Đội kiểm thử nội bộ đã xác nhận mọi sản phẩm bàn giao đạt chất lượng. Khi PM đưa biên bản nghiệm thu, đại diện khách hàng nói một số báo cáo "chưa đúng ý" nhưng không chỉ ra yêu cầu cụ thể nào bị vi phạm. Đây là hoạt động thuộc quy trình nào và PM nên làm gì?

    Bạn chọn phương án nào?

    Khách hàng đã dùng hệ thống ổn định 60 ngày nhưng chưa ký nghiệm thu. Hợp đồng có điều khoản nghiệm thu mặc nhiên sau 15 ngày không phản hồi, nhưng chưa ai nhắc tới. Nếu là PM, bạn chọn cách nào?

    Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

    Đánh giá bài viết

    Bình luận

    Mục lục

    Tình huống minh hoạVì sao nghiệm thu bị treo ở khách hàng doanh nghiệpPhân tích theo PMBOK® GuideCách làm: thiết kế nghiệm thu từ ngày đầuXử lý khi đã bị treoSai lầm thường gặpGóc ôn thi PMPNguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)
    Quảng cáoTemplate quản lý dự án (mẫu)