TÓM TẮT
- 1 1. Giới thiệu chung về WBS
- 2 2. Các bước chuẩn bị trước khi vẽ WBS
- 3 3. Quy trình vẽ WBS chi tiết
- 3.1 3.1 Bước 1: Xây dựng cây WBS tổng quan
- 3.2 3.2 Bước 2: Phân chia từng thành phần cấp độ 2 thành các gói công việc cấp độ 3
- 3.3 3.3 Bước 3: Tiếp tục chi tiết hoá tới cấp độ 4 (nếu cần)
- 3.4 3.4 Bước 4: Gán mã số WBS (WBS Code)
- 3.5 3.5 Bước 5: Xác định các thuộc tính của gói công việc
- 3.6 3.6 Bước 6: Kiểm tra tính hợp lý và hoàn chỉnh
- 4 4. Công cụ hỗ trợ vẽ WBS
- 5 5. Thực hành: Vẽ WBS cho dự án “Triển khai Hệ thống CRM”
- 6 6. Các lưu ý quan trọng khi vẽ WBS
- 7 7. Các lỗi thường gặp và cách khắc phục
- 8 8. Kết hợp WBS với các kỹ thuật quản lý khác
- 9 9. Các mẫu WBS mẫu (Template) để tham khảo
- 10 10. Tổng kết
1. Giới thiệu chung về WBS
1.1 WBS là gì?
Work Breakdown Structure (WBS) – hay Cấu trúc Phân công Công việc – là một công cụ quản lý dự án quan trọng, giúp chia nhỏ dự án thành các thành phần công việc có thể quản lý, giám sát và kiểm soát một cách hiệu quả. Mỗi thành phần trong WBS được gọi là “công việc” (task) hoặc “gói công việc” (work package), và chúng được sắp xếp theo một cấu trúc cây, từ cấp độ tổng thể (cấp độ 1) đến cấp độ chi tiết (cấp độ 3, 4,…).
1.2 Tầm quan trọng của WBS trong quản lý dự án
- Rõ ràng, minh bạch: Giúp mọi người trong dự án hiểu rõ phạm vi công việc và trách nhiệm của mình.
- Lập kế hoạch chi tiết: Dựa trên WBS, ta có thể ước tính thời gian, nguồn lực, chi phí cho từng gói công việc.
- Kiểm soát rủi ro: Khi dự án được chia nhỏ, việc phát hiện và xử lý rủi ro trở nên dễ dàng hơn.
- Đánh giá tiến độ: Tiến độ của từng gói công việc có thể được theo dõi độc lập, giúp tổng hợp tiến độ dự án một cách chính xác.
- Giao tiếp hiệu quả: WBS là “ngôn ngữ chung” giữa các bộ phận, các bên liên quan và nhà quản lý dự án.
2. Các bước chuẩn bị trước khi vẽ WBS
2.1 Xác định phạm vi dự án (Project Scope)
Trước khi bắt đầu vẽ WBS, bạn cần một Project Charter hoặc Scope Statement chi tiết, trong đó nêu rõ:
– Mục tiêu dự án
– Sản phẩm (deliverables) cuối cùng
– Các yêu cầu chức năng và phi chức năng
– Giới hạn, ràng buộc và giả định
2.2 Thu thập yêu cầu và tài liệu liên quan
- Yêu cầu khách hàng: Tài liệu yêu cầu, bản mô tả chức năng (Functional Specification), bản mô tả phi chức năng (Non‑functional Specification).
- Tiêu chuẩn ngành: Các chuẩn ISO, PMBOK, PRINCE2 nếu dự án thuộc lĩnh vực đặc thù.
- Các tài liệu tham khảo: Hợp đồng, đề xuất kinh doanh, biểu đồ Gantt mẫu, các dự án tương tự đã hoàn thành.
2.3 Lựa chọn phương pháp phân cấp
Có ba phương pháp phổ biến:
1. Phân cấp dựa trên sản phẩm (Product‑Based) – tập trung vào các thành phẩm, module, thành phần.
2. Phân cấp dựa trên quy trình (Process‑Based) – chia dự án theo các giai đoạn, quy trình thực hiện (phân tích, thiết kế, triển khai, kiểm thử, bàn giao).
3. Phân cấp hỗn hợp – kết hợp cả hai cách trên để đáp ứng nhu cầu đặc thù của dự án.

Có thể bạn quan tâm: Cách Vẽ Watercolor Bằng Phần Tử (pts): Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
2.4 Xác định mức độ chi tiết (Level of Detail)
- Cấp độ 1: Dự án tổng thể.
- Cấp độ 2: Các thành phần chính (ví dụ: Thiết kế, Phát triển, Kiểm thử, Triển khai).
- Cấp độ 3‑4: Gói công việc chi tiết, có thể giao cho một cá nhân hoặc một nhóm nhỏ để thực hiện.
3. Quy trình vẽ WBS chi tiết
3.1 Bước 1: Xây dựng cây WBS tổng quan
- Vẽ khung tổng thể: Đặt tên dự án ở cấp độ 1, trung tâm của cây.
- Xác định các thành phần cấp độ 2: Dựa trên phương pháp đã chọn (sản phẩm hoặc quy trình). Ví dụ:
- 1.0 Quản lý dự án
- 2.0 Phân tích yêu cầu
- 3.0 Thiết kế hệ thống
- 4.0 Phát triển phần mềm
- 5.0 Kiểm thử
- 6.0 Triển khai & Đào tạo
- 7.0 Bảo trì
3.2 Bước 2: Phân chia từng thành phần cấp độ 2 thành các gói công việc cấp độ 3
Ví dụ, 3.0 Thiết kế hệ thống có thể chia thành:
– 3.1 Thiết kế kiến trúc tổng thể
– 3.2 Thiết kế mô-đun
– 3.3 Thiết kế giao diện người dùng (UI/UX)
– 3.4 Đánh giá và phê duyệt thiết kế
3.3 Bước 3: Tiếp tục chi tiết hoá tới cấp độ 4 (nếu cần)
Mỗi gói công việc cấp độ 3 lại được chia thành các công việc cụ thể:
– 3.2.1 Phân tích yêu cầu mô-đun A
– 3.2.2 Lập sơ đồ lớp (Class Diagram) cho mô-đun A
– 3.2.3 Xác định các giao diện (API) của mô-đun A
3.4 Bước 4: Gán mã số WBS (WBS Code)
Mỗi nút trong cây WBS cần một mã duy nhất để dễ dàng theo dõi và liên kết với các công cụ quản lý (MS Project, Primavera, Jira, …). Quy tắc thường dùng:
– Cấu trúc “a.b.c”: Ví dụ 3.2.1 (cấp 3 – mô-đun – công việc chi tiết).
– Mã màu, ký hiệu: Đối với các dự án lớn, có thể dùng màu để phân biệt các bộ phận (phát triển, kiểm thử, quản trị).

Có thể bạn quan tâm: Cách Vẽ Trên Wacom Với Adobe Illustrator: Hướng Dẫn Từ Cơ Bản Đến Nâng Cao
3.5 Bước 5: Xác định các thuộc tính của gói công việc
Mỗi gói công việc (work package) cần có:
– Tên công việc: Ngắn gọn, mô tả rõ ràng.
– Mô tả: Chi tiết nội dung, tiêu chuẩn đầu ra.
– Thời gian dự kiến (Estimated Duration).
– Nguồn lực (Resource) – người, công cụ, phần mềm.
– Chi phí dự toán (Cost Estimate).
– Tiên quyết (Predecessor) và Hậu quả (Successor) – các mối quan hệ công việc.
– Rủi ro (Risk) – các yếu tố có thể ảnh hưởng.
– Tiêu chí chấp nhận (Acceptance Criteria) – tiêu chuẩn hoàn thành.
3.6 Bước 6: Kiểm tra tính hợp lý và hoàn chỉnh
- Đảm bảo tính toàn vẹn (Completeness): Mọi công việc cần thực hiện đã được liệt kê chưa?
- Tránh trùng lặp (Duplication): Hai gói công việc có nội dung chồng chéo không?
- Kiểm tra mức độ chi tiết (Granularity): Mỗi gói công việc có thể giao cho một người hoặc một nhóm nhỏ trong 1‑2 tuần không? Nếu quá lớn, cần chia nhỏ hơn.
- Đánh giá tính khả thi (Feasibility): Các ước lượng thời gian, chi phí có thực tế không?
4. Công cụ hỗ trợ vẽ WBS
| Công cụ | Ưu điểm | Nhược điểm | Đề xuất sử dụng |
|---|---|---|---|
| Microsoft Project | Tích hợp mạnh với lịch Gantt, quản lý tài nguyên, tự động tính toán WBS code. | Chi phí bản quyền cao, học nhanh không dễ. | Dự án quy mô trung bình‑lớn, cần tích hợp sâu với quản lý tiến độ. |
| Excel / Google Sheets | Dễ tiếp cận, linh hoạt, không tốn phí. | Thiếu tính năng tự động, khó quản lý quan hệ phụ thuộc. | Dự án nhỏ, nhóm không muốn đầu tư phần mềm. |
| WBS Schedule Pro | Giao diện trực quan, hỗ trợ export sang MS Project, Primavera. | Phải mua bản quyền, không phổ biến. | Dự án cần biểu đồ WBS chuyên nghiệp, trình bày cho khách hàng. |
| Jira + Structure plugin | Kết hợp quản lý task Agile, phù hợp với Scrum/Kanban. | Cần cấu hình plugin, không phù hợp cho dự án truyền thống. | Dự án phần mềm Agile, muốn đồng bộ WBS với backlog. |
| MindManager / XMind | Dễ tạo cây cấu trúc dạng mind‑map, trực quan. | Không tích hợp sâu với quản lý tài nguyên. | Giai đoạn khởi tạo, brainstorming, trình bày ý tưởng. |
5. Thực hành: Vẽ WBS cho dự án “Triển khai Hệ thống CRM”
5.1 Bước 1: Xác định phạm vi
- Mục tiêu: Cài đặt và tùy chỉnh hệ thống CRM cho công ty XYZ, bao gồm đào tạo người dùng và chuyển giao dữ liệu.
- Deliverables: Hệ thống CRM đã cài đặt, tài liệu hướng dẫn, báo cáo chuyển giao.
5.2 Bước 2: Chọn phương pháp – Process‑Based (theo giai đoạn)
Cấp độ 2 (Các giai đoạn chính)
1.0 Quản lý dự án
2.0 Phân tích yêu cầu
3.0 Thiết kế hệ thống
4.0 Cài đặt & Tùy chỉnh
5.0 Kiểm thử & Đánh giá
6.0 Đào tạo & Hỗ trợ
7.0 Bàn giao & Bảo trì
Cấp độ 3 – Ví dụ “4.0 Cài đặt & Tùy chỉnh”
- 4.1 Cài đặt môi trường server
- 4.2 Cài đặt cơ sở dữ liệu
- 4.3 Tùy chỉnh module bán hàng
- 4.4 Tùy chỉnh module chăm sóc khách hàng
- 4.5 Tích hợp API với hệ thống ERP
Cấp độ 4 – Ví dụ “4.3 Tùy chỉnh module bán hàng”
- 4.3.1 Thu thập yêu cầu chi tiết từ bộ phận kinh doanh
- 4.3.2 Thiết kế giao diện bán hàng
- 4.3.3 Lập trình chức năng quản lý đơn hàng
- 4.3.4 Kiểm thử chức năng
- 4.3.5 Đánh giá và phê duyệt
5.3 Bước 3: Gán mã WBS và thuộc tính
| WBS Code | Tên công việc | Thời gian (ngày) | Nguồn lực | Chi phí (USD) | Tiên quyết | Hậu quả |
|---|---|---|---|---|---|---|
| 4.3.1 | Thu thập yêu cầu chi tiết | 3 | Business Analyst 1 | 900 | 2.0 | 4.3.2 |
| 4.3.2 | Thiết kế giao diện bán hàng | 5 | UI/UX Designer, BA | 1,500 | 4.3.1 | 4.3.3 |
| 4.3.3 | Lập trình chức năng quản lý đơn hàng | 8 | Developer 2 | 2,400 | 4.3.2 | 4.3.4 |
| 4.3.4 | Kiểm thử chức năng | 4 | QA Engineer | 800 | 4.3.3 | 4.3.5 |
| 4.3.5 | Đánh giá và phê duyệt | 2 | Project Manager, Stakeholder | 400 | 4.3.4 | 5.0 |
5.4 Bước 4: Kiểm tra tính hợp lý

Có thể bạn quan tâm: Cách Vẽ Watch (đồng Hồ) Trong Photoshop: Hướng Dẫn Chi Tiết Từng Bước
- Độ chi tiết: Mỗi công việc có thể hoàn thành trong 2‑8 ngày, phù hợp cho việc giao cho cá nhân/nhóm.
- Không trùng lặp: Các công việc được tách rời, không có phần nội dung chồng chéo.
- Quan hệ phụ thuộc: Đã thiết lập đúng thứ tự (tiên quyết → hậu quả).
5.5 Bước 5: Nhập vào công cụ quản lý
- Sử dụng Microsoft Project: Nhập các WBS code, thời gian, nguồn lực. Tự động tạo biểu đồ Gantt và mạng phụ thuộc (Network Diagram).
- Kết quả: Người quản lý dự án có thể theo dõi tiến độ, chi phí và nguồn lực theo từng gói công việc.
6. Các lưu ý quan trọng khi vẽ WBS
6.1 Đừng để WBS quá “phẳng”
Nếu chỉ chia thành 2‑3 cấp độ, bạn sẽ gặp khó khăn trong việc ước lượng chi tiết và kiểm soát rủi ro. Ngược lại, đừng quá chi tiết (có quá 6‑7 cấp độ) vì sẽ gây mất thời gian và khó quản lý.
6.2 Đảm bảo tính Deliverable‑Oriented
Mỗi gói công việc nên liên kết chặt chẽ với một đầu ra (deliverable) cụ thể. Điều này giúp kiểm tra tiến độ và chất lượng dễ dàng hơn.
6.3 Sử dụng ngôn ngữ thống nhất
- Đặt tên công việc bằng động từ + danh từ (ví dụ: “Phân tích yêu cầu”, “Thiết kế giao diện”).
- Tránh dùng các từ mơ hồ như “Xử lý”, “Thực hiện” mà không có mô tả chi tiết.
6.4 Gắn tiêu chuẩn chấm dứt (Definition of Done)
Mỗi gói công việc cần có tiêu chí rõ ràng để đánh giá khi nào công việc được hoàn thành (ví dụ: “Bản thiết kế được duyệt bởi PM và khách hàng”).

Có thể bạn quan tâm: Cách Vẽ Vợ Gà Gunny: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao
6.5 Kiểm tra tính tương thích với các phương pháp quản lý khác
Nếu dự án dùng Agile, hãy đồng bộ WBS với Product Backlog; nếu dùng Waterfall, hãy liên kết WBS với milestones.
6.6 Đánh giá và cập nhật thường xuyên
WBS không phải là tài liệu tĩnh. Khi dự án tiến triển:
– Cập nhật các công việc mới, loại bỏ công việc không còn cần thiết.
– Điều chỉnh thời gian, chi phí dựa trên thực tế.
– Thông báo thay đổi cho tất cả các bên liên quan.
7. Các lỗi thường gặp và cách khắc phục
| Lỗi | Mô tả | Cách khắc phục |
|---|---|---|
| WBS không đầy đủ | Bỏ sót một số công việc quan trọng, dẫn đến thiếu nguồn lực. | Kiểm tra lại Scope Statement, thực hiện workshop với các chuyên gia để rà soát. |
| Quá chi tiết (over‑decomposition) | Mỗi công việc quá nhỏ, gây lãng phí thời gian quản lý. | Giữ mức độ chi tiết sao cho mỗi gói công việc có thể hoàn thành trong 1‑2 tuần. |
| Thiếu mã số WBS | Khó theo dõi, không thể liên kết với các công cụ quản lý. | Áp dụng quy tắc “a.b.c” và sử dụng công cụ hỗ trợ tự động sinh mã. |
| Không liên kết với Deliverable | Khó đo lường thành công dự án. | Đảm bảo mỗi gói công việc đều có đầu ra rõ ràng và tiêu chí chấp nhận. |
| Không cập nhật | WBS cũ không phản ánh thực tế dự án. | Đặt lịch Review WBS định kỳ (hàng tuần hoặc mỗi Sprint). |
8. Kết hợp WBS với các kỹ thuật quản lý khác
8.1 WBS + Gantt Chart
- Mối quan hệ: WBS cung cấp cấu trúc công việc, Gantt Chart hiển thị thời gian và phụ thuộc.
- Cách thực hiện: Nhập WBS vào MS Project, tự động sinh Gantt Chart.
8.2 WBS + RACI Matrix
- Mục đích: Xác định ai Responsible (Chịu trách nhiệm), Accountable (Có thẩm quyền), Consulted (Tham khảo), Informed (Được thông báo) cho từng gói công việc.
- Lợi ích: Rõ ràng vai trò, giảm nhầm lẫn giao tiếp.
8.3 WBS + Earned Value Management (EVM)
- Cách làm: Gán giá trị ngân sách (Budget) cho mỗi gói công việc, tính PV, EV, AC theo tiến độ.
- Kết quả: Đánh giá hiệu suất dự án (CPI, SPI) dựa trên cấu trúc WBS.
8.4 WBS + Risk Register

- Phương pháp: Gắn các rủi ro (Risk ID) vào từng gói công việc.
- Lợi ích: Khi gói công việc bị trễ, có thể nhanh chóng xác định rủi ro liên quan và đưa ra biện pháp khắc phục.
9. Các mẫu WBS mẫu (Template) để tham khảo
9.1 Mẫu WBS cho dự án phần mềm (Waterfall)
1.0 Quản lý dự án 1.1 Lập kế hoạch 1.2 Kiểm soát dự án
2.0 Phân tích yêu cầu 2.1 Thu thập yêu cầu 2.2 Phân tích nghiệp vụ 2.3 Đánh giá tính khả thi
3.0 Thiết kế hệ thống 3.1 Kiến trúc tổng thể 3.2 Thiết kế chi tiết
4.0 Phát triển 4.1 Lập trình backend 4.2 Lập trình frontend 4.3 Kiểm thử đơn vị
5.0 Kiểm thử tích hợp 5.1 Kiểm thử chức năng 5.2 Kiểm thử hiệu năng
6.0 Triển khai 6.1 Cài đặt môi trường 6.2 Đào tạo người dùng
7.0 Bảo trì 7.1 Hỗ trợ kỹ thuật 7.2 Cập nhật phiên bản
9.2 Mẫu WBS cho dự án xây dựng (Construction)
1.0 Quản lý dự án
2.0 Thiết kế kiến trúc
3.0 Giấy phép & Pháp lý
4.0 Đào móng
5.0 Xây dựng khung
6.0 Hệ thống điện – nước
7.0 Hoàn thiện nội thất
8.0 Kiểm tra & Bàn giao
9.3 Mẫu WBS Agile (Scrum)
1.0 Sprint 1 1.1 User Story A 1.1.1 Thiết kế UI 1.1.2 Lập trình backend 1.1.3 Kiểm thử 1.2 User Story B ...
2.0 Sprint 2 ...
Lưu ý: Trong môi trường Agile, WBS thường gắn liền với Product Backlog và Sprint Backlog, do đó mức độ chi tiết có thể thay đổi theo Sprint.
10. Tổng kết
Việc vẽ WBS không chỉ là một bước kỹ thuật, mà còn là cầu nối giữa chiến lược dự án và thực thi chi tiết. Khi thực hiện đúng quy trình:
- Xác định phạm vi rõ ràng, dựa trên tài liệu dự án.
- Lựa chọn phương pháp phân cấp phù hợp (sản phẩm, quy trình, hỗn hợp).
- Xây dựng cây WBS từ cấp độ tổng quan đến chi tiết, gán mã số, và xác định thuộc tính cho mỗi gói công việc.
- Kiểm tra tính hợp lý, tránh quá chi tiết hoặc thiếu sót.
- Sử dụng công cụ hỗ trợ (MS Project, Excel, WBS Schedule Pro, Jira…) để quản lý và theo dõi.
- Kết hợp WBS với các kỹ thuật quản lý khác như Gantt Chart, RACI, EVM, Risk Register để đạt hiệu quả tối đa.
- Cập nhật, điều chỉnh WBS thường xuyên, phản ánh thực tế dự án.
Khi áp dụng đúng cách, WBS sẽ giúp bạn:
– Kiểm soát phạm vi, tránh “scope creep”.
– Ước lượng thời gian, chi phí chính xác hơn.
– Phân bổ nguồn lực hợp lý.
– Theo dõi tiến độ và đánh giá hiệu suất dự án một cách minh bạch.
– Giao tiếp tốt hơn giữa các bên liên quan, giảm thiểu hiểu lầm.
Hy vọng hướng dẫn chi tiết trên sẽ giúp bạn tự tin vẽ WBS cho bất kỳ dự án nào, từ những dự án phần mềm công nghệ cao đến các dự án xây dựng truyền thống. Hãy bắt đầu từ phân tích yêu cầu, xây dựng cây WBS, và đưa nó vào công cụ quản lý để biến kế hoạch thành hiện thực. Chúc bạn thành công!
