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. /Tình huống
  2. /Quản lý Giao tiếp
  3. /GOV.UK Verify: dự báo 25 triệu người dùng, thực …
Số 170Quản lý Giao tiếp

GOV.UK Verify: dự báo 25 triệu người dùng, thực tế 3,6 triệu và các bộ ngành không muốn dùng nền tảng chung

Verify là nền tảng xác minh danh tính dùng chung cho dịch vụ công trực tuyến của Anh. NAO năm 2019 ghi nhận số người dùng, tỉ lệ xác minh thành công và số dịch vụ tích hợp đều thấp xa dự báo, lợi ích tài chính bị điều chỉnh giảm hơn 650 triệu bảng. Bài học về truyền thông giữa đơn vị xây nền tảng và các bộ ngành — những "khách hàng" có quyền không dùng.

HP
Nguyễn Thu Hà, PMP
09/06/2026
4 phút đọc 0 lượt xem
GOV.UK Verify: dự báo 25 triệu người dùng, thực tế 3,6 triệu và các bộ ngành không muốn dùng nền tảng chung
Bình luận0

Bối cảnh thực tế

GOV.UK Verify do Văn phòng Nội các (Cabinet Office) thông qua Government Digital Service (GDS) phát triển, cho phép người dân chứng minh danh tính một lần để truy cập nhiều dịch vụ công như Universal Credit hay hoàn thuế. Việc xác minh do các nhà cung cấp danh tính thương mại thực hiện theo hợp đồng.

Cuộc điều tra của NAO công bố ngày 5/3/2019 cho thấy:

  • Business case 2016 dự báo 25 triệu người dùng vào năm 2020; đến 2/2019 mới có khoảng 3,6 triệu.
  • Tỉ lệ xác minh thành công khoảng 48%, so với dự kiến 90%.
  • 19 dịch vụ dùng Verify, chưa bằng một nửa con số 46 dịch vụ kỳ vọng vào 3/2018; ít nhất 11 trong 19 dịch vụ còn có cách truy cập trực tuyến khác.
  • Lợi ích tài chính giai đoạn 2016-17 đến 2019-20 bị điều chỉnh từ 873 triệu xuống 217 triệu bảng; chi phí đến cuối 2018 tối thiểu 154 triệu bảng.
  • Trong bảy bộ ngành được gửi hoá đơn phí sử dụng, chỉ HMRC đã thanh toán.

Tháng 10/2018, Cabinet Office tuyên bố ngừng cấp vốn cho Verify từ tháng 3/2020 và chuyển sang mô hình để khu vực tư nhân vận hành. NAO nhận xét khó kết luận rằng các quyết định tiếp tục chương trình trước đó đã được biện minh đầy đủ.

Phân tích nguyên nhân theo chuẩn PMP

  • Bộ ngành là khách hàng có quyền từ chối, nhưng được đối xử như người nhận chỉ đạo

    Một nền tảng dùng chung chỉ tạo giá trị khi các dịch vụ khác tích hợp. Việc nhiều dịch vụ duy trì kênh xác minh riêng và chỉ một bộ trả phí cho thấy nhu cầu thật của bộ ngành (tỉ lệ thành công, chi phí, trải nghiệm người dân) chưa được thu thập và phản hồi qua kênh truyền thông hai chiều.

  • Chỉ số hiệu suất không được truyền đạt kịp thời để điều chỉnh (Monitor Communications)

    Tỉ lệ thành công 48% so với 90% là tín hiệu rõ rằng giả định cốt lõi của business case không đúng. Khi số liệu như vậy không dẫn tới quyết định điều chỉnh sớm, vấn đề nằm ở cách thông tin hiệu suất được trình bày cho người ra quyết định.

Business case không được cập nhật theo thực tế (Monitor and Control Project Work)

Lợi ích bị cắt hơn 650 triệu bảng là dấu hiệu chương trình cần quay lại câu hỏi "còn đáng làm không?". Theo PMBOK 7, quản lý giá trị đòi hỏi đánh giá liên tục sự phù hợp với mục tiêu kinh doanh, không chỉ theo dõi đầu ra.

  • Trải nghiệm người dân bị đứt quãng giữa nhiều bên

    Người dân tương tác với dịch vụ của bộ, rồi bị chuyển sang nhà cung cấp danh tính thương mại. Khi xác minh thất bại, không bên nào "sở hữu" thông điệp giải thích và hướng dẫn tiếp theo — lỗ hổng truyền thông ở điểm chạm quan trọng nhất.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Coi bộ ngành là khách hàng và thiết lập hợp đồng dịch vụ rõ ràng

      Thoả thuận với từng bộ về mức dịch vụ, chi phí và lộ trình tích hợp; họp định kỳ để thu phản hồi và công bố cách đã xử lý phản hồi đó.

    2. 2

      Bước 2: Bảng chỉ số công khai gắn ngưỡng quyết định

      Đưa các chỉ số then chốt vào báo cáo cho hội đồng chương trình, kèm ngưỡng kích hoạt xem xét lại business case:

      • Tiếp tục

        Tỉ lệ xác minh thành công và số dịch vụ tích hợp đạt từ 80% kế hoạch trở lên.

      • Điều chỉnh

        Một chỉ số dưới 80% kế hoạch hai kỳ liên tiếp: phân tích nguyên nhân và trình phương án thay đổi qua quy trình kiểm soát thay đổi.

      • Xem xét lại business case

        Lợi ích dự báo giảm quá một ngưỡng đã thống nhất (ví dụ 30%): trình nhà tài trợ quyết định tiếp tục, thu hẹp hay dừng.

    3. 3

      Bước 3: Một chủ sở hữu cho hành trình người dùng xuyên suốt

      Chỉ định bên chịu trách nhiệm nội dung thông báo lỗi, hướng dẫn thay thế và kênh hỗ trợ khi xác minh thất bại, thay vì để mỗi bên chỉ lo phần của mình.

    4. 4

      Bước 4: Thử nghiệm sớm với vài dịch vụ có lượng giao dịch lớn

      Chứng minh giá trị trên một số dịch vụ trọng điểm rồi mới mở rộng; bằng chứng thực tế là công cụ truyền thông mạnh hơn mọi bản chiến lược.

    PM Takeaway (Bài học rút ra)

    Nền tảng dùng chung sống nhờ những khách hàng tự nguyện. PM phải quản lý truyền thông với các bộ ngành như với khách hàng — lắng nghe, đo lường, phản hồi — và để số liệu hiệu suất thật sự dẫn dắt quyết định về business case.

    Nguồn tham khảo

    • NAO — Investigation into Verify (báo cáo)
    • NAO — Investigation into Verify (thông cáo báo chí)
    #Quản lý truyền thông#NAO#Chính phủ số#Định danh điện tử#business-case

    Nguồn: NAO — Investigation into Verify (2019) ↗ (mở trong thẻ mới)

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

    Câu 1/1
    PM của một nền tảng dùng chung nhận báo cáo quý: tỉ lệ người dùng hoàn tất thành công chỉ khoảng một nửa so với giả định trong business case, và nhiều đơn vị nội bộ vẫn giữ kênh riêng. Nhà tài trợ đang chuẩn bị phê duyệt giai đoạn mở rộng. PM nên làm gì?

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

    Nếu là PM nền tảng dùng chung như Verify, các bộ ngành chần chừ tích hợp vì tỉ lệ thành công thấp, bạn ưu tiên gì?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Giao tiếp

    Khách hàng đòi thay thế Tech Lead & Nghệ thuật Bảo vệ Đội ngũ

    Mảng kiến thức trọng tâm: Quản lý Nguồn lực, Quản lý Các bên liên quan & Lãnh đạo Phục vụ (Resource Management, Stakeholder Engagement & Servant Leadership - PMBOK 6/7)

    1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Quản lý Giao tiếp

    "Hố sâu chuyển giao" (Operational Transition Gap) – Khi Đội Vận hành từ chối tiếp nhận hệ thống

    Mảng kiến thức trọng tâm: Chuyển giao từ Dự án sang Vận hành & Quản lý Các bên liên quan nội bộ (Project-to-Operations Transition, Operational Readiness & Internal Stakeholder Engagement - PMBOK 6/7)

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận13/10/2026
    Quản lý Giao tiếp

    Slack 22/02/2022: nâng cấp Consul làm bộ nhớ đệm rơi, cơ sở dữ liệu quá tải và cách vừa giảm tải vừa thông tin cho người dùng

    Sáng 22/02/2022, đúng giờ cao điểm, nhiều người dùng Slack không kết nối được. Nguyên nhân là một chuỗi yếu tố: nâng cấp Consul theo từng bước 25%, bộ nhớ đệm mất hiệu quả, truy vấn quét mọi shard làm Vitess quá tải và máy khách thử lại dồn dập. Slack giảm tải có kiểm soát, thông báo trên mạng xã hội rồi công bố bản post-mortem kỹ thuật vào cuối tháng 4. Phân tích dưới góc nhìn quản lý truyền thông sự cố.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận09/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)