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. /Khách hàng doanh nghiệp gửi 140 yêu cầu, cái nào…
Quản lý các bên liên quan· Domain: Lập kế hoạch

Khách hàng doanh nghiệp gửi 140 yêu cầu, cái nào cũng "bắt buộc": ưu tiên hoá cùng khách hàng bằng MoSCoW và mô hình Kano

Khi mọi phòng ban của khách hàng đều đánh dấu yêu cầu của mình là "bắt buộc", ưu tiên hoá trở thành cuộc đấu quyền lực. Bài viết kết hợp MoSCoW (với giới hạn khoảng 60% công sức cho Must Have) và mô hình Kano để đưa khách hàng vào cuộc thảo luận về giá trị thay vì danh sách.

HP
Nguyễn Thu Hà, PMP
10/02/2026
5 phút đọc 0 0
Khách hàng doanh nghiệp gửi 140 yêu cầu, cái nào cũng "bắt buộc": ưu tiên hoá cùng khách hàng bằng MoSCoW và mô hình Kano

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 được thuê xây dựng cổng thông tin đại lý cho một hãng bảo hiểm có 3.000 đại lý. Sau năm buổi hội thảo với sáu phòng ban, danh sách yêu cầu có 140 mục. Ước lượng sơ bộ cho toàn bộ danh sách là khoảng 2,3 lần năng lực của đội trong 6 tháng đã cam kết.

PM đề nghị khách hàng ưu tiên hoá. Hai tuần sau, bảng tính quay lại: 131/140 mục được đánh dấu "Bắt buộc". Phòng Kinh doanh, phòng Đào tạo, phòng Tuân thủ, phòng CNTT, phòng Chăm sóc khách hàng và phòng Tài chính mỗi bên tự đánh giá yêu cầu của mình — và không ai muốn yêu cầu của phòng mình rơi xuống dưới.

Vì sao "tất cả đều bắt buộc"

  • Không ai chịu chi phí của lựa chọn: khi ưu tiên không gắn với năng lực có hạn, đánh dấu "bắt buộc" không tốn gì.
  • Sợ không có lần sau: các phòng ban tin rằng cái gì không vào đợt một sẽ không bao giờ được làm.
  • Thiếu tiêu chí chung: mỗi phòng hiểu "bắt buộc" theo cách riêng — bắt buộc về pháp lý, bắt buộc để làm việc, hay chỉ "rất muốn có".
  • Người ra quyết định cuối cùng không rõ: không có ai phía khách hàng được giao quyền xếp hạng giữa các phòng.

Hai công cụ, hai góc nhìn

MoSCoW — ưu tiên theo hậu quả khi không có

MoSCoW do Dai Clegg phát triển năm 1994, gắn với khung DSDM, chia yêu cầu thành Must have, Should have, Could have, Won't have (this time). Định nghĩa quan trọng: Must have là thứ mà thiếu nó thì giải pháp không có ý nghĩa, không hợp pháp hoặc không an toàn — không phải "rất quan trọng".

Agile Business Consortium khuyến nghị Must have không vượt quá khoảng 60% công sức của một khung thời gian; Could have thường chiếm khoảng 20% và đóng vai trò dự phòng. Lý do: khi rủi ro xảy ra, đội cần phần "có thể bỏ" để bảo vệ phần bắt buộc. Một kế hoạch 131/140 Must have là kế hoạch không có dự phòng.

Kano — ưu tiên theo cảm nhận của người dùng

Mô hình Kano (Noriaki Kano, thập niên 1980) phân loại thuộc tính theo tác động tới sự hài lòng:

  • Thiết yếu (must-be): có thì không ai khen, thiếu thì không hài lòng.
  • Một chiều (one-dimensional): càng tốt càng hài lòng.
  • Hấp dẫn (attractive): không ai đòi, nhưng có thì thích thú.
  • : có hay không cũng vậy.

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
Kế hoạch & tiến độLập kế hoạch

Ngày go-live "chắc chắn" chỉ đạt được 8% số lần mô phỏng: phân tích rủi ro tiến độ bằng Monte Carlo

Lịch dự án ERP ghi go-live ở ngày làm việc thứ 120, nhưng ba nhánh công việc cùng hội tụ vào một mốc. Mô phỏng Monte Carlo cho thấy ngày đó chỉ đạt được khoảng 8% số lần lặp. Cách đọc đường cong S, hiểu merge bias và chọn mức dự phòng tiến độ có căn cứ.

Ngày đăng: 04/10/2026Lượt xem: 0Bì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
Không quan tâm (indifferent)
  • Ngược (reverse): có lại gây khó chịu với một số người.
  • Kano giúp phát hiện những mục bị gọi là "bắt buộc" nhưng thực ra người dùng không quan tâm, và những mục "hấp dẫn" đáng làm sớm vì tạo khác biệt.

    Phân tích theo PMBOK® Guide

    • Collect Requirements dùng các kỹ thuật ra quyết định nhóm và phân tích dữ liệu; ma trận truy vết yêu cầu (requirements traceability matrix) nối từng yêu cầu với mục tiêu kinh doanh — mục nào không truy vết được về mục tiêu nào là ứng viên cho Won't have.
    • PMBOK 7 – Focus on value và lĩnh vực hiệu suất Stakeholders: ưu tiên hoá là quyết định của khách hàng về giá trị; PM tạo điều kiện, không quyết thay.
    • Trong agile, Product Owner sắp xếp backlog. Với khách hàng doanh nghiệp nhiều phòng ban, cần một người được trao quyền làm việc này phía khách hàng.

    Cách làm: hội thảo ưu tiên hoá 4 bước

    1. Gắn ưu tiên với năng lực

    Công bố "ngân sách" công sức của đợt một (ví dụ 100 điểm), trong đó tối đa 60 điểm cho Must have. Khi tổng Must have vượt 60, nhóm phải tự bỏ bớt.

    2. Kiểm tra Must have bằng câu hỏi hậu quả

    Với từng mục: "Nếu go-live mà thiếu mục này thì sao? Đại lý vẫn bán được hàng không? Có vi phạm quy định không? Có cách làm tạm không?" Nếu có cách làm tạm chấp nhận được, mục đó là Should have.

    3. Khảo sát Kano với đại lý thật

    Chọn 30–40 mục còn tranh cãi, hỏi một mẫu đại lý theo cặp câu hỏi Kano (cảm nhận khi có và khi không có tính năng). Kết quả thường làm thay đổi cuộc tranh luận giữa các phòng ban, vì dữ liệu đến từ người dùng chứ không từ phòng nào.

    Ví dụ kết quả minh hoạ cho một vài mục:

    Yêu cầuPhòng đề xuấtNhãn ban đầuKết quả KanoNhãn sau hội thảo
    Tra cứu trạng thái hồ sơ bồi thường của kháchChăm sóc khách hàngMustThiết yếuMust
    Bảng xếp hạng doanh số đại lý theo tuầnKinh doanhMustHấp dẫnShould (làm sớm nếu còn năng lực)
    Xuất mọi báo cáo ra năm định dạngCNTTMustKhông quan tâmWon't have this time
    Ký điện tử hợp đồng bảo hiểmTuân thủMustMột chiềuMust (có căn cứ pháp lý và giá trị cao)

    Hai mục "Must" bị hạ bậc không phải vì phòng đề xuất thua cuộc tranh luận, mà vì dữ liệu từ đại lý cho thấy giá trị thấp hơn kỳ vọng.

    4. Trao quyền quyết định và cam kết lộ trình

    Người bảo trợ chỉ định một người có quyền xếp hạng cuối cùng giữa các phòng. Đồng thời công bố lộ trình đợt hai, đợt ba để "Won't have this time" thực sự có nghĩa là chưa phải lúc này, không phải "không bao giờ".

    Sai lầm thường gặp

    • PM tự xếp hạng thay khách hàng: nhanh nhưng khách hàng không sở hữu kết quả, tranh cãi quay lại khi nghiệm thu.
    • Chia đều cho các phòng: công bằng về chính trị nhưng không tối ưu giá trị.
    • Dùng MoSCoW mà không có giới hạn tỷ lệ: kết quả vẫn là "toàn Must".
    • Coi Kano là chân lý tuyệt đối: phân loại thay đổi theo thời gian — tính năng hấp dẫn hôm nay có thể thành thiết yếu sau vài năm.
    • Ưu tiên một lần rồi thôi: danh sách cần được xếp lại ở mỗi mốc phát hành, khi khách hàng đã thấy sản phẩm thật và hiểu rõ hơn điều mình cần.

    Góc ôn thi PMP

    • MoSCoW là kỹ thuật ưu tiên hoá; nhớ chữ W là Won't have this time.
    • Khi các stakeholder tranh chấp ưu tiên, PM tạo điều kiện để các bên thống nhất dựa trên giá trị kinh doanh, chuyển quyết định cho người có thẩm quyền (sponsor, product owner), không tự quyết.
    • Ma trận truy vết yêu cầu giúp đảm bảo mỗi yêu cầu tạo giá trị kinh doanh và được theo dõi đến khi bàn giao.

    Nguồn tham khảo

    • Agile Business Consortium – MoSCoW Prioritisation (khuyến nghị tỷ lệ Must have)
    • Wikipedia – MoSCoW method
    • Wikipedia – Kano model
    #khach-hang-doanh-nghiep#moscow#kano#uu-tien-yeu-cau#Quản lý kỳ vọng

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

    Câu 1/1
    Sáu phòng ban của khách hàng cùng đánh dấu gần như toàn bộ yêu cầu là "Must have". Tổng công sức vượt gấp đôi năng lực đợt một. Mỗi phòng đều nói yêu cầu của mình quan trọng nhất. PM nên làm gì?

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

    Sau hội thảo, Must have vẫn chiếm 75% công sức đợt một. Phòng Tuân thủ và phòng Kinh doanh giằng co 15% còn lại. Người bảo trợ hỏi ý kiến bạn. Nếu là PM, bạn khuyến nghị gì?

    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 "tất cả đều bắt buộc"Hai công cụ, hai góc nhìnPhân tích theo PMBOK® GuideCách làm: hội thảo ưu tiên hoá 4 bướcSai lầm thường gặpGóc ôn thi PMPNguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoTemplate quản lý dự án (mẫu)
    Quảng cáoBộ đề thi thử PMP (mẫu)