Quản Lý Phạm Vi Dự Án: Scope Statement, WBS & Scope Control

Bạn có từng gặp tình huống này không?
Dự án ban đầu chỉ cần làm ba tính năng, nhưng cuối cùng team deliver tám tính năng — trong đó hai cái không ai yêu cầu, ba cái khách hàng "ngỏ ý" nhưng chưa chính thức approve?
Kết quả: trễ deadline, vượt budget, và khách hàng vẫn không hài lòng vì ba tính năng gốc bị cắt xén để nhường chỗ cho đám "thêm vào."

Đó là scope management thất bại. Và đáng buồn là nó xảy ra nhiều hơn bạn nghĩ.

Bài viết này đi qua toàn bộ quy trình quản lý phạm vi dự án — từ lập kế hoạch, thu thập requirements, định nghĩa scope, phân rã WBS, kiểm soát thay đổi cho đến nghiệm thu chính thức. Hiểu rõ quy trình này giúp bạn trả lời đúng phần lớn câu hỏi Process domain trong kỳ thi PMP.

Phân Biệt Nền Tảng: Product Scope vs Project Scope

Trước hết, hai khái niệm này khác nhau — và thi PMP hay hỏi.

• Product Scope: Các tính năng và chức năng cần có trong sản phẩm, dịch vụ hoặc kết quả của dự án. Đo lường bằng product requirements.

• Project Scope: Toàn bộ công việc cần thực hiện để deliver sản phẩm với các tính năng đã định. Đo lường bằng project management plan.

Nói đơn giản: Product scope là "cái gì" — khách hàng nhận được gì. Project scope là "làm gì" — team phải làm những công việc nào để tạo ra cái đó. Project scope thường bao gồm cả product scope.

Hai Sai Lầm Kinh Điển

Cả hai đều là đáp án sai trong thi PMP. PM không bao giờ cho phép scope creep, và cũng không bao giờ gold plate.

Bước 1: Plan Scope Management

Trước khi làm bất cứ điều gì với scope, bạn cần một plan — hướng dẫn cách scope sẽ được quản lý xuyên suốt dự án.

Scope Management Plan

Tài liệu này mô tả scope sẽ được define, develop, monitor, control và validate như thế nào. Nó là một thành phần của project management plan, có thể formal hoặc informal tùy nhu cầu dự án.

Requirements Management Plan

Mô tả cách project và product requirements sẽ được phân tích, ghi nhận và quản lý. Bị ảnh hưởng mạnh bởi mối quan hệ giữa các phase — ví dụ phase relationship trong dự án waterfall khác hoàn toàn so với Agile.

Bước 2: Collect Requirements — Thu Thập Đúng Và Đủ

Đây là bước quyết định: requirements sai hoặc thiếu ở giai đoạn này sẽ gây hậu quả xuyên suốt toàn bộ dự án.

Requirement là gì?

Requirement là điều kiện hoặc khả năng mà stakeholder cần để giải quyết vấn đề hoặc đạt mục tiêu. Có nhiều loại:

• Business requirements: Nhu cầu cấp tổ chức — tại sao dự án tồn tại

• Stakeholder requirements: Nhu cầu của các bên liên quan cụ thể

• Solution requirements: Functional (tính năng) + Non-functional (hiệu suất, bảo mật...)

• Transition requirements: Yêu cầu chuyển đổi từ hệ thống cũ sang mới

• Project work requirements: Yêu cầu về time, cost, quality cho công việc dự án

Stated vs Unstated Requirements

Một thách thức lớn: khách hàng không phải lúc nào cũng nói hết những gì họ cần. Stated requirements là những gì họ nói rõ. Unstated requirements là những gì họ mong đợi nhưng không nói — ví dụ "tất nhiên hệ thống phải bảo mật" dù không ai viết requirement đó. PM giỏi phải biết cách khai thác cả hai.

Kỹ Thuật Thu Thập Requirements

PMI giới thiệu nhiều kỹ thuật — bạn cần biết ít nhất các kỹ thuật sau:

• Interviews: Phỏng vấn 1-1 với stakeholder — formal hoặc informal. Phù hợp khi cần thông tin sâu từ cá nhân cụ thể.

• Brainstorming: Thu thập ý tưởng tự phát từ nhóm. 4 quy tắc: đi theo số lượng, không phê phán, chào đón ý tưởng lạ, kết hợp và cải thiện.

• Delphi Technique: Phương pháp ẩn danh — hỏi panel chuyên gia, tổng hợp, lặp lại cho đến khi đạt consensus. Ưu điểm: mọi người bày tỏ ý kiến mà không sợ bị intimidate bởi người có quyền lực.

• Prototypes: Tạo mô hình hoạt động của sản phẩm trước khi xây dựng thật. Requirements thu được từ prototype thường đầy đủ hơn từ tài liệu thuần.

• Wireframes: Bản phác thảo giao diện — low-fidelity, vẽ tay trên giấy. Giúp stakeholder hình dung sản phẩm trước khi viết code.

• Observation (Job shadowing): Quan sát người dùng thực tế làm việc — phát hiện unstated requirements mà phỏng vấn không khai thác được.

• Questionnaires/Surveys: Phù hợp khi cần thu thập từ số lượng lớn người.

• Benchmarking: So sánh với best practices của tổ chức tương đương.

• Document Analysis: Phân tích business plans, process flows, logical data models, hợp đồng...

📍Mẹo thi:
Khi câu hỏi hỏi "kỹ thuật nào giúp tránh bias từ người có quyền lực" → Delphi Technique (vì ẩn danh).
Khi hỏi "kỹ thuật nào phát hiện hidden requirements" → Observation hoặc Prototype.
Khi hỏi "kỹ thuật nào cho số lượng người lớn" → Questionnaires/Surveys.

Requirements Documentation

Mọi requirement phải được ghi nhận với các đặc tính: unambiguous (rõ ràng), measurable and testable (đo lường và kiểm tra được), traceable (truy vết được), complete (đầy đủ), consistent (nhất quán), và acceptable to key stakeholders.

Trong Agile, requirements thường được viết dưới dạng User Stories — phát triển trong requirement workshops.

Requirements Traceability Matrix (RTM)

RTM là ma trận liên kết requirements với business objectives, project objectives và deliverables. Nó giúp truy vết từng requirement xuyên suốt vòng đời dự án — từ khi thu thập đến khi validate. Nếu có ai hỏi "requirement X đến từ đâu và ai phê duyệt?" — RTM trả lời câu đó.

Bước 3: Define Scope — Xác Định Rõ Ràng

Từ danh sách requirements, bạn cần chốt phạm vi cụ thể của dự án.

Quy trình Define Scope

• Chọn final requirements từ requirements documentation

• Phát triển mô tả chi tiết về project và product

• Phân tích alternatives và xác định best approach

• Phân tích risks, assumptions, constraints

• Đồng thuận về deliverables và acceptance criteria

Product Analysis

Chuyển đổi mô tả sản phẩm cấp cao thành deliverables cụ thể. Công cụ: Product Breakdown Structure — phân rã sản phẩm thành các thành phần nhỏ hơn, dễ quản lý.

Project Scope Statement

Tài liệu kết quả quan trọng nhất của bước này. Nó ghi nhận toàn bộ scope — cả project scope và product scope. Bao gồm:

• Deliverables: Mô tả chi tiết các sản phẩm chuyển giao

• Acceptance Criteria: Tiêu chí nghiệm thu cho từng deliverable

• Scope Exclusions: Những gì KHÔNG thuộc phạm vi — rất quan trọng để quản lý kỳ vọng stakeholder

Team và stakeholder cần đồng thuận về scope statement trước khi bắt đầu execution. Không có sự đồng thuận → scope creep chắc chắn xảy ra.

Bước 4: Create WBS — Phân Rã Công Việc

WBS (Work Breakdown Structure) là công cụ được sử dụng nhiều nhất trong scope management — và cũng là concept PMP hỏi nhiều nhất trong phần này.

WBS Là Gì — Và Không Phải Là Gì

Decomposition — Quy Tắc Phân Rã

Phân rã deliverables cấp cao thành các thành phần nhỏ hơn, dễ quản lý. WBS có thể tổ chức theo:

• Project phases: Phase 1 → Phase 2 → Phase n

• Major deliverables: Deliverable 1 → Deliverable 2 → Deliverable n

• Combination: Kết hợp cả hai

Cách tạo WBS:

• Top-down: Dùng templates hoặc guidelines của tổ chức — nhanh nhưng có thể thiếu chi tiết

• Bottom-up: Xây dựng từ input của team members — mất thời gian hơn nhưng team buy-in cao hơn và chi tiết hơn

Work Package — Mức Thấp Nhất Của WBS

Work package là thành phần ở mức thấp nhất của WBS. Từ work package, bạn mới phân rã tiếp thành activities (thuộc schedule management, không còn nằm trong WBS).

Lưu ý quan trọng: WBS phân rã deliverables (danh từ), không phải actions (động từ). Ví dụ: "Báo cáo thiết kế" là WBS component đúng. "Viết báo cáo thiết kế" là activity — không nằm trong WBS.

Rule 100%

Tổng công việc ở mức "con" phải bằng 100% công việc ở mức "cha." WBS không được bao gồm bất kỳ công việc nào nằm ngoài phạm vi thực tế của dự án. Không thừa, không thiếu.

Rule 8/80

Quy tắc ngón tay cái cho mức độ phân rã: không work package nào nhỏ hơn 8 giờ hoặc lớn hơn 80 giờ. Work package cũng không nên vượt quá một reporting period. Phân rã quá nhiều → micromanagement. Phân rã quá ít → mất kiểm soát.

Scope Baseline

Scope baseline = Scope Statement + WBS + WBS Dictionary. Đây là phiên bản được approved, là thành phần của project management plan, và chỉ có thể thay đổi qua formal change control procedures.

WBS Dictionary là tài liệu hỗ trợ WBS, chứa mô tả chi tiết cho từng work package: code of accounts, description of work, assumptions, constraints, responsible organization, schedule milestones...

💡Pro Tip: Trong thi PMP, phân biệt: Work package = mức thấp nhất của WBS, đã phân rã hết. Planning package = mức thấp nhất tại một thời điểm, sẽ được phân rã thêm khi có thêm thông tin (rolling wave planning). Planning package KHÔNG có activities bên dưới.

Bước 5: Control Scope — Kiểm Soát Thay Đổi

Scope đã được baseline — giờ bảo vệ nó. Control Scope là quá trình giám sát trạng thái scope và quản lý thay đổi.

Quy Trình Xử Lý Thay Đổi — 9 Bước

Khi nhận được yêu cầu thay đổi từ stakeholder, tuân theo quy trình:

• Understand the change: Hiểu rõ yêu cầu thay đổi là gì

• Prevent unnecessary changes: Ngăn chặn thay đổi không cần thiết

• Identify root cause: Tìm nguyên nhân gốc rễ — tại sao cần thay đổi?

• Look at impact: Đánh giá tác động lên schedule, cost, quality, risk...

• Create a change request: Tạo change request chính thức

• Perform Integrated Change Control: Đưa lên CCB để approve/reject

• Adjust project management plan: Nếu approved, cập nhật plan và baselines

• Notify stakeholders: Thông báo stakeholder bị ảnh hưởng

• Manage to new plan: Quản lý dự án theo plan mới

Change Control Board (CCB)

CCB là hội đồng có quyền approve hoặc reject change requests. Thành viên CCB có thể bao gồm stakeholders, managers, team members, và người ngoài dự án. Vai trò và trách nhiệm của CCB được ghi rõ trong change management plan.

Một số tên gọi khác bạn có thể gặp: Technical Assessment Board (TAB), Technical Review Board (TRB), Engineering Review Board (ERB).

💡Pro Tip: Trong thi PMP, khi có yêu cầu thay đổi, đáp án đúng hầu như KHÔNG BAO GIỜ là "implement ngay" hay "từ chối ngay." Luôn là: đánh giá impact → tạo change request → đưa vào change control process. Ngay cả khi sponsor yêu cầu — vẫn phải qua process.

Bước 6: Validate Scope — Khách Hàng Nghiệm Thu

Validate Scope là quá trình trình bày deliverables đã hoàn thành cho stakeholder và chính thức nhận sự chấp nhận.

Phân Biệt Validate Scope vs Control Quality

Quy trình: Control Quality (internal verification) → Validate Scope (external acceptance) → Close Project.

Ba Kết Quả Khi Trình Bày Deliverable

Khi PM trình bày deliverable cho khách hàng, có 3 kịch bản:

• Chấp nhận (Accepted): Deliverable đáp ứng requirements → formal acceptance (ký nghiệm thu)

• Có lỗi (Defects): Requirements chưa đáp ứng → team phải fix

• Có thay đổi (Change request): Khách hàng muốn thay đổi → đưa vào change control process, chỉ approved changes mới được implement

Tổng Hợp: Quy Trình Scope Management Từ A → Z

Và nhớ các khái niệm cốt lõi:

• Scope Creep = thay đổi không kiểm soát → luôn sai

• Gold Plating = thêm thứ không ai yêu cầu → luôn sai

• WBS = phân rã deliverables (danh từ), không phải activities (động từ)

• Work Package = mức thấp nhất WBS, 8-80 giờ

• Rule 100% = tổng con = 100% cha

• Scope Baseline = Scope Statement + WBS + WBS Dictionary

• Verified deliverables (QA kiểm tra) → Accepted deliverables (khách hàng chấp nhận)

• Mọi thay đổi phải qua change control process — không ngoại lệ

Scope management là xương sống của dự án — mọi thứ khác (schedule, cost, quality, risk) đều phụ thuộc vào scope có được define và control đúng hay không. Một scope baseline vững chắc giúp bạn nói "không" có cơ sở khi có yêu cầu thay đổi vô lý, và nói "có" đúng cách khi thay đổi mang lại giá trị thực.

Luyện tập các câu hỏi scenario về scope — đặc biệt về change control và WBS — trên CertFlow. Đây là chủ đề chiếm tỷ trọng lớn trong domain Process (41%) của ECO 2026.

Câu Hỏi Thường Gặp (FAQ)

Scope creep là gì và làm thế nào để kiểm soát?

Scope creep là hiện tượng phạm vi dự án mở rộng dần mà không có sự phê duyệt chính thức — thường do stakeholder yêu cầu thêm tính năng nhỏ mà không đi qua change control. Cách kiểm soát: có Scope Statement rõ ràng, áp dụng Integrated Change Control và không bao giờ chấp nhận thay đổi miệng.

Product Scope và Project Scope khác nhau như thế nào?

Product Scope là các tính năng và chức năng của sản phẩm/dịch vụ được tạo ra. Project Scope là công việc cần thực hiện để tạo ra sản phẩm đó — bao gồm cả các công việc quản lý, tài liệu, testing. Hoàn thành project scope đo bằng project plan; product scope đo bằng product requirements.

WBS có thể decompose xuống mức nào là đủ?

WBS nên decompose đến mức Work Package — đơn vị công việc nhỏ nhất có thể ước lượng, assign và kiểm soát. Quy tắc kinh nghiệm: work package không nên dài hơn 2 tuần (8/80 rule). Decompose quá sâu gây overhead quản lý; quá nông thì không ước lượng được chính xác.

Bạn đã nắm vững quản lý phạm vi dự án — giờ là lúc luyện tập với câu hỏi thi thật.

• Bài tiếp theo: Quản Lý Tiến Độ: Critical Path & Schedule Control

• Quản lý scope dự án theo PMBOK 8: định nghĩa và phân rã

• Lập kế hoạch quản lý dự án tích hợp theo PMBOK 8

• Series nền tảng quản lý dự án cho PMP

Làm thử đề PMP miễn phí →

Nguồn tham khảo chính thức:

• Thông tin chứng chỉ PMP chính thức