Cấu trúc phân chia công việc (WBS, Work Breakdown Structure)
1. Tổng quan
A. Định nghĩa
Là cấu trúc phân cấp hướng kết quả (Deliverable-oriented) phân rã theo cấp bậc toàn bộ phạm vi (sản phẩm bàn giao) của dự án thành các đơn vị công việc nhỏ có thể quản lý được. Đây là công cụ cốt lõi của quản lý dự án, trở thành đường cơ sở (Baseline) cho quản lý phạm vi·tiến độ·chi phí·nguồn lực·chất lượng·rủi ro.
Bản chất của WBS là 'chia nhỏ một dự án khổng lồ và mơ hồ thành các kích thước có thể xử lý được'. Một mục tiêu lớn như "xây dựng hệ thống thông tin thế hệ mới" tự thân không thể ước tính tiến độ hay chi phí. Bởi chừng nào phạm vi còn trừu tượng thì không thể chỉ định người phụ trách, cũng không thể tính tỷ lệ tiến độ. WBS phân rã điều này theo dạng cây (tree), bắt đầu từ sản phẩm bàn giao cấp cao nhất xuống các sản phẩm bàn giao con, rồi đến đơn vị nhỏ nhất có thể thực hiện thực tế là gói công việc (Work Package). Chia nhỏ như vậy giúp ước tính cụ thể thời gian·chi phí·người phụ trách của từng công việc, đo lường tiến độ khách quan và kiểm soát toàn bộ mà không bỏ sót.
Nguyên lý quan trọng nhất ở đây là WBS được phân rã xoay quanh 'những gì sẽ tạo ra (sản phẩm bàn giao·kết quả, deliverable)' chứ không phải 'những việc phải làm (hoạt động, activity)'. Ví dụ, không chia thành "lập trình" mà chia theo kết quả như "module đăng nhập", "module thanh toán". Tính hướng sản phẩm bàn giao này mang lại hai hiệu quả thực tiễn. Thứ nhất, nó cho tiêu chí hoàn thành rõ ràng (Definition of Done) có thể xác nhận bằng mắt. Hoạt động thì mơ hồ ở chỗ "đã làm được bao nhiêu", còn sản phẩm bàn giao được phán định bằng "đã được tạo ra chưa". Thứ hai, có thể đối chiếu "đã bỏ sót gì" bằng danh sách sản phẩm bàn giao, qua đó ngăn chặn một cách có cấu trúc việc thiếu phạm vi. Chia theo hoạt động dễ phát sinh trùng lặp·bỏ sót, còn chia theo sản phẩm bàn giao thì quan hệ bao hàm cấp trên - cấp dưới trở nên rõ ràng.
B. Bối cảnh ra đời và sự cần thiết
Dự án càng lớn và phức tạp thì càng khó nắm cần làm gì và bao nhiêu, và phạm vi càng dễ bị xáo trộn. Đặc biệt, trong các dự án IT có sản phẩm bàn giao là phần mềm vô hình như SI·SM, tiến độ khó xác nhận bằng mắt, nên nếu không có tiêu chí phân rã rõ ràng thì dễ rơi vào cái gọi là hội chứng 90% — báo cáo "đã xong 90%" lặp lại cho tới cuối dự án. WBS ra đời để loại bỏ sự mơ hồ này. Nó trực quan hóa·cấu trúc hóa phạm vi để cung cấp đường cơ sở cho lập kế hoạch·kiểm soát, và tạo ra ngôn ngữ chung và sự đồng thuận giữa các bên liên quan như bên đặt hàng·PM·nhà phát triển về "dự án này tạo ra cái gì".
Ngoài ra, WBS đóng vai trò đầu vào (input) cho mọi kế hoạch khác trong bộ kiến thức quản lý dự án. Kế hoạch tiến độ (biểu đồ Gantt·CPM), chi phí (đường cơ sở chi phí), nguồn lực (RAM), rủi ro, chất lượng đều lấy gói công việc của WBS làm điểm xuất phát. Do đó, nếu WBS sơ sài thì phát sinh hiệu ứng dây chuyền khiến mọi kế hoạch sau đó cũng sơ sài, ngược lại một WBS vững chắc trở thành nền tảng cho toàn bộ việc kiểm soát dự án.
2. Cấu trúc phân cấp và các thành phần của WBS
Toàn bộ dự án được đặt làm gốc (root), càng đi xuống càng được phân rã thành các sản phẩm bàn giao cụ thể, và ở tầng thấp nhất là gói công việc — đơn vị quản lý thực tế. Mỗi cấp được cấu thành sao cho biểu diễn trọn vẹn 100% sản phẩm bàn giao của cấp trên.
flowchart TB
P["Xây dựng hệ thống thế hệ mới<br/>(Dự án Level 1)"]
P --> A["Phân tích yêu cầu<br/>(Sản phẩm bàn giao Level 2)"]
P --> B["Thiết kế<br/>(Sản phẩm bàn giao Level 2)"]
P --> C["Phát triển<br/>(Sản phẩm bàn giao Level 2)"]
P --> D["Chuyển đổi·Ổn định<br/>(Sản phẩm bàn giao Level 2)"]
B --> B1["Tài liệu thiết kế kiến trúc"]
B --> B2["Tài liệu thiết kế DB (ERD)"]
C --> C1["Module đăng nhập<br/>(Gói công việc)"]
C --> C2["Module thanh toán<br/>(Gói công việc)"]
C1 --> C1a["Hoạt động: Lập trình·Kiểm thử đơn vị (Activity)"]
style P fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style C1 fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px
WBS gồm nhiều thành phần ăn khớp với nhau để tạo thành một hệ thống quản lý. Mỗi thành phần không chỉ là một tên gọi mà đảm nhận vai trò quản lý khác nhau, nên việc hiểu phân biệt ý nghĩa của chúng là quan trọng.
Gói công việc (Work Package) là phần tử thấp nhất của WBS, là đơn vị cơ bản của quản lý để ước tính tiến độ·chi phí, đo lường tiến độ và phân công trách nhiệm. Nếu đi xuống thấp hơn gói công việc thì đó không còn là WBS mà là hoạt động (activity) thuộc lĩnh vực lập kế hoạch tiến độ. Nói cách khác, tồn tại một ranh giới: WBS dừng ở 'tạo ra cái gì (sản phẩm bàn giao)', còn 'tạo ra nó như thế nào (hoạt động·trình tự)' do kế hoạch tiến độ tiếp theo đảm nhận. Trong thực tế, một gói công việc thường được giao cho một người (hoặc một nhóm), và được thiết kế để có tiêu chí hoàn thành và ngân sách rõ ràng.
Tài khoản kiểm soát (Control Account) là điểm quản lý cấp trên gom nhiều gói công việc để đo lường·kiểm soát hiệu suất. Trong quản lý giá trị thu được (EVM), đơn vị tổng hợp giá trị kế hoạch (PV)·giá trị thu được (EV)·chi phí thực tế (AC) chính là tài khoản kiểm soát này, và hiệu suất chi phí·tiến độ được xem tích hợp ở cấp này. Nếu gói công việc là đơn vị thực thi thì tài khoản kiểm soát là đơn vị đo lường hiệu suất.
Từ điển WBS (WBS Dictionary) là tài liệu chứa thông tin chi tiết của từng gói công việc. Nó mô tả nội dung công việc, sản phẩm bàn giao, người phụ trách, thời gian·chi phí dự kiến, công việc tiên quyết, tiêu chí nghiệm thu (acceptance criteria), thông tin hợp đồng liên quan v.v. Chỉ riêng hình vẽ WBS thì chẳng khác gì bảng tên, nên phải có từ điển WBS đi kèm thì mới thành kế hoạch có thể thực thi. Nguyên nhân phổ biến khiến kế hoạch trôi nổi dù đã vẽ WBS ở hiện trường chính là thiếu từ điển này.
Mã WBS (Code of Accounts) là số định danh phân cấp gán cho mỗi phần tử (ví dụ: 1.3.2), là chìa khóa để liên kết có hệ thống sản phẩm bàn giao với thông tin chi phí·tiến độ và truy vết quan hệ cấp trên - cấp dưới.
| Thành phần | Vai trò | Ý nghĩa quản lý |
|---|---|---|
| Gói công việc | Đơn vị sản phẩm bàn giao thấp nhất | Đơn vị cơ bản để ước tính tiến độ·chi phí, đo lường tiến độ, phân công trách nhiệm |
| Tài khoản kiểm soát | Nhóm các gói công việc | Điểm đo lường·tích hợp hiệu suất EVM (PV·EV·AC) |
| Từ điển WBS | Đặc tả chi tiết gói công việc | Bảo đảm khả năng thực thi (nội dung·tiêu chí·người phụ trách·thời gian) |
| Mã WBS | Số định danh phân cấp | Liên kết và truy vết sản phẩm bàn giao - chi phí - tiến độ |
3. Nguyên tắc và quy trình lập WBS
A. Nguyên tắc lập
WBS không phải là hình vẽ tùy ý mà có các quy tắc phải tuân thủ. Căn bản nhất là quy tắc 100% (100% Rule): tổng các phần tử cấp dưới phải biểu diễn đầy đủ 100% phần tử cấp trên, không thiếu cũng không thừa. Nguyên tắc này áp dụng theo cả hai chiều: hướng lên (không đưa vào công việc không còn cần thiết) và hướng xuống (không bỏ sót công việc). Nếu không tuân thủ quy tắc 100% thì bản thân đường cơ sở phạm vi bị lệch, khiến mọi hoạt động kiểm soát sau đó trở nên vô nghĩa.
Nguyên tắc thứ hai là tính loại trừ lẫn nhau (Mutually Exclusive) giữa các phần tử: cùng một công việc không được nằm trùng trong hai sản phẩm bàn giao. Nếu trùng lặp thì chi phí·công sức bị tính hai lần và ranh giới trách nhiệm trở nên mờ nhạt. Điều này tương ứng chính xác với nguyên tắc MECE (Mutually Exclusive, Collectively Exhaustive) của phân loại logic.
Thứ ba là phân rã theo sản phẩm bàn giao (kết quả) như đã nhấn mạnh, và thứ tư là mức phân rã phù hợp (độ chi tiết phù hợp). Chia quá nhỏ (phân rã quá mức) thì chi phí quản lý bùng nổ, để quá lớn (phân rã chưa đủ) thì không thể kiểm soát tiến độ và chi phí. Trong thực tế, người ta thường lấy quy tắc 8/80 (một gói công việc khoảng 880 giờ, tức lượng công việc 1 ngày2 tuần) làm tiêu chí kinh nghiệm, hoặc lấy thước đo "có thể phán định hoàn thành hay chưa trong một chu kỳ báo cáo không". Ví dụ, với dự án báo cáo tiến độ theo đơn vị 2 tuần, việc điều chỉnh gói công việc có kích thước hoàn thành trong 2 tuần sẽ có lợi cho kiểm soát.
| Nguyên tắc | Nội dung | Vấn đề khi vi phạm |
|---|---|---|
| Quy tắc 100% | Tổng cấp dưới = 100% cấp trên (không thiếu·không thừa) | Sụp đổ đường cơ sở phạm vi, không thể kiểm soát |
| Loại trừ lẫn nhau (MECE) | Không trùng lặp giữa các phần tử | Tính hai lần chi phí·công sức, trách nhiệm mơ hồ |
| Hướng sản phẩm bàn giao | Phân rã theo kết quả chứ không theo hoạt động | Khó phán định hoàn thành·kiểm tra bỏ sót |
| Mức phân rã phù hợp (8/80) | Kích thước đo lường được tiến độ·chi phí | Quá mức: chi phí quản lý / Chưa đủ: không thể kiểm soát |
B. Quy trình lập và cách tiếp cận
Việc lập WBS được tiếp cận chủ yếu theo từ trên xuống (Top-down) và từ dưới lên (Bottom-up). Từ trên xuống là cách bắt đầu từ toàn bộ dự án rồi dần chia xuống các sản phẩm bàn giao chi tiết, phù hợp với dự án có phạm vi tương đối rõ ràng. Từ dưới lên là cách gom các công việc chi tiết mà thành viên nhóm nghĩ ra qua brainstorming rồi nhóm dần lên các hạng mục cấp trên, có lợi cho việc giảm bỏ sót ở các lĩnh vực mới·không chắc chắn. Trong thực tế, thường kết hợp cả hai: dựng khung bằng từ trên xuống và bổ sung chi tiết bằng từ dưới lên.
Cũng cần chọn 'tiêu chí (trục)' phân rã. Có tiêu chí sản phẩm bàn giao (theo sản phẩm·module), tiêu chí giai đoạn (theo phase của vòng đời: phân tích - thiết kế - phát triển - kiểm thử), tiêu chí tổ chức (theo tổ chức thực hiện) v.v., và đôi khi dùng lẫn các trục khác nhau ở cấp trên và cấp dưới. Ví dụ, cấp trên chia theo tiêu chí giai đoạn, còn bên trong giai đoạn phát triển thì chia theo tiêu chí sản phẩm bàn giao (module). Dưới đây là quy trình lập điển hình.
flowchart LR
S1["Bản mô tả phạm vi·<br/>Thu thập yêu cầu"] --> S2["Xác định sản phẩm<br/>bàn giao cấp cao nhất"]
S2 --> S3["Chọn tiêu chí (trục)<br/>phân rã: giai đoạn/sản phẩm"]
S3 --> S4["Phân rã phân cấp<br/>đến gói công việc"]
S4 --> S5["Kiểm chứng<br/>quy tắc 100%·MECE"]
S5 --> S6["Lập từ điển WBS·<br/>Gán mã"]
S6 --> S7["Chốt đường cơ sở<br/>phạm vi (Baseline)"]
S5 -->|Cần bổ sung| S3
style S7 fill:#e8f5e9,stroke:#34a853,stroke-width:2px
C. Hình thức biểu diễn và ví dụ lập
WBS được biểu diễn bằng nhiều hình thức tùy mục đích và đối tượng. Dạng cây (dạng sơ đồ tổ chức) cho thấy quan hệ phân cấp trong một cái nhìn nên tốt cho báo cáo·chia sẻ với bên đặt hàng, dạng danh sách phân cấp (dạng dàn ý) liệt kê bằng văn bản cùng mã nên có lợi cho quản lý bằng công cụ·tài liệu, còn dạng bảng chứa cả người phụ trách·thời gian·chi phí nên phù hợp với quản lý thực thi. Hình thức khác nhau nhưng nội dung chứa đựng (phân cấp·sản phẩm bàn giao·mã) là như nhau.
Dưới đây là ví dụ biểu diễn một dự án SI quy mô nhỏ ở dạng danh sách phân cấp. Mỗi mục thấp nhất là một gói công việc, và từ điển WBS được gắn vào để có người phụ trách·thời gian·chi phí.
| Mã WBS | Sản phẩm bàn giao (gói công việc) | Công sức dự kiến |
|---|---|---|
| 1. Xây dựng cổng thông tin thế hệ mới | (Dự án) | — |
| 1.1 Phân tích yêu cầu | Tài liệu định nghĩa yêu cầu | 60 M/D |
| 1.2 Thiết kế | — | — |
| 1.2.1 Tài liệu thiết kế màn hình | Sản phẩm thiết kế UI | 40 M/D |
| 1.2.2 Tài liệu thiết kế DB (ERD) | Mô hình logic·vật lý | 30 M/D |
| 1.3 Phát triển | — | — |
| 1.3.1 Module đăng nhập | Chức năng xác thực | 20 M/D |
| 1.3.2 Module thanh toán | Chức năng thanh toán | 45 M/D |
| 1.4 Kiểm thử·Chuyển đổi | Báo cáo kết quả kiểm thử tích hợp | 35 M/D |
Trong ví dụ này, '1.3 Phát triển' phải bằng 100% tổng của '1.3.1 Module đăng nhập + 1.3.2 Module thanh toán' (quy tắc 100%), và hai module không được chồng lấn nhau (MECE). Nếu ở đây thiếu "module quản trị" thì tổng cấp dưới không biểu diễn được 100% cấp trên, tức là thiếu phạm vi. Ngoài ra, cộng công sức (M/D) của từng gói công việc sẽ ra tổng công sức dự án và đường cơ sở chi phí, và giá trị này trở thành nền tảng để tính giá trị kế hoạch (PV) của EVM sau đó.
4. Liên kết và ứng dụng với các kế hoạch khác
Giá trị thực sự của WBS không nằm ở bản thân nó mà bộc lộ khi ăn khớp với các công cụ quản lý khác. Thứ nhất, gói công việc của WBS được phân rã thành danh sách hoạt động (activity) cấp dưới, được gán quan hệ trước sau (PDM), và tiến độ được tính bằng phương pháp đường găng (CPM)·biểu đồ Gantt. Thứ hai, cộng chi phí của từng gói công việc tạo thành đường cơ sở chi phí (Cost Baseline), và ở đây áp dụng ước tính từ dưới lên (Bottom-up Estimating). Thứ ba, giao WBS với cấu trúc phân chia tổ chức (OBS) sẽ được ma trận phân công trách nhiệm (RAM/RACI), xác định "ai chịu trách nhiệm sản phẩm bàn giao nào".
Thứ tư, trong giai đoạn kiểm soát tiến độ, WBS trở thành khung xương của quản lý giá trị thu được (EVM). Ví dụ, trong một dự án có tổng ngân sách 1 tỷ won và 100 gói công việc, nếu tại thời điểm theo kế hoạch lẽ ra phải hoàn thành 40 gói mà thực tế chỉ hoàn thành 30, có thể định lượng độ trễ tiến độ bằng chênh lệch giữa giá trị thu được (EV) so với giá trị kế hoạch (PV). Như vậy, không có WBS thì bản thân đơn vị để tổng hợp PV·EV của EVM cũng không tồn tại.
Biện pháp khắc phục khi chậm tiến độ cũng được xây dựng dựa trên WBS·CPM. Tiêu biểu, nén tiến độ (Crashing) là bổ sung nguồn lực vào công việc trên đường găng để rút ngắn thời gian, làm tăng chi phí; còn chồng lấn tiến độ (Fast Tracking) là tiến hành song song các công việc tuần tự, làm tăng rủi ro làm lại. Ví dụ, nếu thiết kế chậm 2 tuần, có thể bổ sung nhân lực để đẩy nhanh thiết kế (Crashing), hoặc khởi động một phần phát triển trước khi thiết kế hoàn tất (Fast Tracking) để bù lại, nhưng dù chọn cách nào cũng phải chấp nhận cái giá (chi phí hoặc rủi ro).
| Biện pháp khắc phục | Nội dung | Cái giá |
|---|---|---|
| Nén tiến độ (Crashing) | Bổ sung nguồn lực vào đường găng để rút ngắn thời gian | Tăng chi phí |
| Chồng lấn tiến độ (Fast Tracking) | Song song hóa các công việc tuần tự | Tăng rủi ro làm lại |
| Điều chỉnh phạm vi | Thu hẹp·hoãn phạm vi có ưu tiên thấp | Giảm sản phẩm bàn giao |
5. Nâng cao: WBS trong môi trường Agile và xu hướng mới nhất
Trong dự án dự đoán (Predictive) truyền thống, WBS lấy tiền đề là chốt toàn bộ phạm vi ngay từ đầu khi khởi động. Tuy nhiên, trong môi trường Agile (thích ứng, Adaptive) nơi yêu cầu liên tục thay đổi, việc đóng đinh toàn bộ phạm vi bằng quy tắc 100% từ đầu lại lệch khỏi thực tế. Vì vậy, Agile thay thế WBS bằng Product Backlog và phân rã story (Epic → Feature → User Story → Task). Điều thú vị là dù tên gọi và thời điểm khác nhau, nguyên lý phân rã là như nhau: "chia phạm vi khổng lồ thành các đơn vị nhỏ có thể quản lý, không trùng lặp·không bỏ sót". Chỉ khác ở chỗ Agile không hoàn thành việc phân rã này một lần mà chi tiết hóa dần (Progressive Elaboration) qua từng sprint.
Xu hướng của bộ kiến thức quản lý dự án mới nhất cũng đáng chú ý. Đến PMBOK phiên bản 6, WBS được quy định rõ ràng là sản phẩm cốt lõi của 'quản lý phạm vi', nhưng PMBOK phiên bản 7 năm 2021 đã được cải tổ từ lấy quy trình làm trung tâm sang lấy nguyên tắc·lĩnh vực hiệu suất (Principle/Domain) làm trung tâm, chuyển sang hướng không bắt buộc công cụ cụ thể. Dù vậy, WBS vẫn là kỹ thuật phân rã phạm vi được dùng rộng rãi nhất, và trong các dự án lai (dự đoán + thích ứng), cách dung hòa quản lý phạm vi cấp cao bằng WBS và thực thi chi tiết bằng backlog đang lan rộng. Tóm lại, hiểu WBS không phải là 'biểu mẫu cố định' mà là 'lối tư duy phân rã' là chính xác cả trong thi cử lẫn thực tiễn.
6. Các điểm cần lưu ý và hàm ý
- Là đường cơ sở (Baseline) của mọi kế hoạch. Không có WBS thì kế hoạch tiến độ (Gantt·CPM)·chi phí (đường cơ sở chi phí)·nguồn lực (RAM)·rủi ro không thể thành lập. Do đó, lập WBS chính xác là điểm xuất phát của thành công dự án, và một WBS sơ sài sẽ lan truyền sai số sang mọi kế hoạch sau đó.
- Nhất định phải đi kèm từ điển WBS. Chỉ hình vẽ thì chẳng khác gì bảng tên. Từ điển WBS chứa nội dung·sản phẩm bàn giao·người phụ trách·thời gian·tiêu chí nghiệm thu của từng gói công việc phải được quản lý cùng thì mới thành kế hoạch có thể thực thi, và khi có yêu cầu thay đổi cũng cần có từ điển mới truy vết chính xác được phạm vi ảnh hưởng.
- Liên kết với quản lý thay đổi·quản lý cấu hình. WBS đã được chốt làm đường cơ sở phạm vi chỉ có thể thay đổi sau khi qua quy trình kiểm soát thay đổi tích hợp (ICC). Sửa WBS không kiểm soát sẽ trở thành lối đi cho phình phạm vi (Scope Creep), nên thay đổi nhất định phải được phê duyệt·ghi lịch sử.
- Độ chi tiết phù hợp và sự tham gia của các bên liên quan là then chốt. Để tránh phân rã quá mức·chưa đủ, cần đặt tiêu chí như quy tắc 8/80, và cho nhóm thực hiện công việc thực tế cùng bên đặt hàng tham gia lập thì mới ra được WBS thực tế và được đồng thuận. Đánh giá chuyên gia (Expert Judgment) và tái sử dụng template của dự án tương tự cũng nâng cao chất lượng.
- Áp dụng linh hoạt theo phương pháp luận. Dự đoán chọn WBS chốt từ đầu, Agile chọn phân rã dần dựa trên backlog, lai chọn dung hòa giữa hai. Khi hiểu WBS không phải biểu mẫu tuyệt đối mà là 'nguyên lý phân rã', có thể áp dụng nhất quán cho nhiều loại dự án khác nhau.
Tài liệu tham khảo
- PMI, "A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition", 2021, https://www.pmi.org/pmbok-guide-standards
- PMI, "Practice Standard for Work Breakdown Structures", https://www.pmi.org/
Tóm tắt một câu: WBS là cấu trúc hướng kết quả phân rã phân cấp phạm vi dự án theo sản phẩm bàn giao đến tận gói công việc, tuân thủ quy tắc 100%·MECE·quy tắc 8/80 để cung cấp đường cơ sở cho quản lý tiến độ·chi phí·tiến triển·trách nhiệm (EVM·RAM); trong Agile nó đổi hình thái thành Product Backlog nhưng 'nguyên lý phân rã' vẫn được giữ nguyên.