WBS (Work Breakdown Structure, cấu trúc phân chia công việc) là sơ đồ dạng cây phân rã toàn bộ phạm vi dự án thành các phần nhỏ dần, tới mức gói công việc có thể ước tính, giao người và theo dõi được. WBS trả lời câu hỏi “dự án phải tạo ra những gì”, chứ chưa trả lời “làm theo thứ tự nào” hay “mất bao lâu”; đó là việc của lịch tiến độ được dựng sau.
WBS là nền của gần như mọi công cụ khác: lịch Gantt, đường găng, ngân sách, phân công trách nhiệm, quản lý giá trị thu được đều lấy gói công việc trong WBS làm đơn vị. Một WBS sai thì mọi thứ dựng trên nó đều lệch. Bài này giải thích nguồn gốc, các quy tắc chuẩn, cách chọn kiểu phân rã, mức độ chi tiết vừa đủ, từ điển WBS và một ví dụ cho dự án mở kho hàng.
Nguồn gốc và vì sao WBS định hướng sản phẩm
WBS hình thành trong các chương trình quốc phòng và hàng không vũ trụ của Mỹ đầu thập niên 1960, khi Bộ Quốc phòng và NASA cần một cách thống nhất để chia những hệ thống khổng lồ thành phần việc giao cho nhiều nhà thầu, rồi cộng ngược lại chi phí và tiến độ. Tài liệu hướng dẫn PERT/Cost năm 1962 đã mô tả cấu trúc phân rã này; về sau Bộ Quốc phòng Mỹ chuẩn hoá thành tiêu chuẩn MIL-STD-881. PMI phát hành riêng một bộ tiêu chuẩn thực hành cho WBS, và cuốn Effective Work Breakdown Structures của Gregory Haugan (2002) phổ biến quy tắc 100%.
Từ nguồn gốc đó, quan niệm chuẩn mực là WBS định hướng sản phẩm bàn giao (deliverable-oriented): các nút là danh từ chỉ thứ được tạo ra, như “hệ thống phòng cháy”, “tài liệu đào tạo”, chứ không phải động từ chỉ hoạt động như “họp”, “kiểm tra”. Lý do là sản phẩm có thể nghiệm thu được và có trạng thái rõ: xong hay chưa xong. Hoạt động thì được liệt kê ở bước sau, khi phân rã gói công việc thành danh sách công việc để xếp lịch.
Nhiều đội vẫn lập “WBS” thực chất là danh sách việc dài không cấu trúc. Hệ quả là khó biết đã đủ phạm vi chưa, khó gom chi phí theo hạng mục, và khi khách hàng hỏi “hạng mục này đã tiêu bao nhiêu tiền” thì không trả lời được.
Các quy tắc cốt lõi khi lập WBS
Quy tắc 100%. WBS bao gồm 100% phạm vi dự án, kể cả phần quản lý dự án; tổng công việc của các nút con đúng bằng nút cha, không thiếu, không thừa. Việc gì không có trong WBS thì không nằm trong phạm vi, và đây là căn cứ để từ chối yêu cầu phát sinh.
Loại trừ lẫn nhau. Hai nút không được chồng lấn. Nếu “lắp đặt điện” xuất hiện ở cả nhánh nhà xưởng và nhánh văn phòng mà không tách rõ, chi phí sẽ bị tính hai lần hoặc mỗi bên nghĩ bên kia làm.
Đặt tên bằng danh từ. Mỗi nút là một kết quả, không phải một hành động. “Hệ thống kệ đã lắp” thay cho “lắp kệ”. Quy ước này giúp nghiệm thu và tránh lẫn với danh sách công việc.
Có mã phân cấp. Mã kiểu 1, 1.1, 1.1.2 cho phép liên kết WBS với lịch, ngân sách, hợp đồng và hệ thống kế toán; khi đó báo cáo chi phí theo hạng mục chỉ là phép cộng.
Lập cùng người làm. WBS do một người ngồi vẽ thường bỏ sót những phần mà chỉ người chuyên môn mới biết, như thử nghiệm, chứng nhận, đào tạo, chuyển đổi dữ liệu. Buổi làm việc nhóm với giấy dán trên tường thường cho kết quả đầy đủ hơn phần mềm.
Có nhánh quản lý dự án. Báo cáo, họp, quản lý rủi ro, mua sắm tiêu tốn nguồn lực thật. Không đưa vào WBS thì chúng bị ẩn và ngân sách luôn thiếu.
Chọn kiểu phân rã ở cấp hai
Cấp một là toàn bộ dự án. Cách chia cấp hai quyết định hình dạng cả cây, và nên chọn theo cách dự án sẽ được quản lý, báo cáo và giao thầu:
| Kiểu phân rã | Ví dụ nút cấp hai | Hợp khi | Rủi ro |
|---|---|---|---|
| Theo sản phẩm, cấu phần | Nhà kho, hệ thống kệ, phần mềm kho, nhân sự | Sản phẩm có cấu trúc vật lý rõ, giao thầu theo hạng mục | Khó thấy thứ tự thời gian |
| Theo giai đoạn | Thiết kế, thi công, chạy thử, bàn giao | Dự án tuần tự, có cổng phê duyệt giữa các giai đoạn | Dễ trượt sang liệt kê hoạt động |
| Theo khu vực địa lý | Chi nhánh miền Bắc, miền Trung, miền Nam | Triển khai lặp lại ở nhiều nơi | Phần dùng chung bị lặp hoặc bỏ sót |
| Theo đơn vị thực hiện | Phòng kỹ thuật, nhà thầu A, nhà thầu B | Hợp đồng tách bạch theo đơn vị | Phần giao thoa giữa các đơn vị không ai nhận |
Có thể trộn kiểu ở các cấp khác nhau: cấp hai theo giai đoạn, cấp ba theo sản phẩm. Điều cần tránh là trộn kiểu trong cùng một cấp, vì sẽ phá quy tắc loại trừ lẫn nhau. Với dự án phần mềm làm theo agile, cấp hai thường là các nhóm tính năng lớn (epic) và WBS được chi tiết dần theo từng đợt phát hành.
Chia đến đâu là đủ: gói công việc và các quy tắc kinh nghiệm
Mức thấp nhất của WBS là gói công việc (work package): đủ nhỏ để ước tính thời gian, chi phí đáng tin và giao cho một người chịu trách nhiệm, nhưng không nhỏ đến mức quản lý tốn hơn làm. Không có con số đúng cho mọi dự án; người làm nghề thường dùng vài quy tắc kinh nghiệm như sau, nên coi là gợi ý chứ không phải chuẩn.
Quy tắc 8/80: gói công việc nên cần không dưới 8 và không quá 80 giờ công. Quy tắc kỳ báo cáo: gói công việc không kéo dài quá một kỳ báo cáo, ví dụ hai tuần, để mỗi kỳ đều có thứ xong hoặc chưa xong rõ ràng. Quy tắc người chịu trách nhiệm: nếu không thể chỉ ra một người duy nhất chịu trách nhiệm cho nút, nút đó cần chia tiếp hoặc gộp lại.
Không phải nhánh nào cũng phải sâu bằng nhau. Phần đã quen làm có thể dừng ở cấp ba, phần mới và rủi ro cần xuống cấp năm. Với phần còn xa về thời gian, có thể dùng lập kế hoạch cuốn chiếu (rolling wave): giữ ở mức khái quát, chi tiết hoá khi tới gần. Điều này hợp lý hơn việc ép chi tiết hoá những thứ chưa ai biết, rồi phải sửa lại liên tục. Dấu hiệu chia quá vụn là danh sách gói công việc dài hàng nghìn dòng mà không ai cập nhật nổi.
Từ điển WBS: phần bị bỏ quên nhưng quyết định chất lượng
Một cái cây chỉ có tên nút thì mỗi người đọc một kiểu. “Phần mềm quản lý kho” có bao gồm chuyển dữ liệu tồn kho cũ không? Có đào tạo người dùng không? Từ điển WBS là tài liệu đi kèm, mô tả từng gói công việc với các trường tối thiểu: mã và tên; mô tả công việc; sản phẩm bàn giao và tiêu chí nghiệm thu; người chịu trách nhiệm; giả định và ràng buộc; ước tính thời gian và chi phí; các mốc liên quan.
Từ điển WBS biến WBS từ hình vẽ thành hợp đồng phạm vi. Khi có tranh cãi “việc này có trong phạm vi không”, câu trả lời nằm trong mô tả gói công việc, không phải trong trí nhớ của người dự họp. Với dự án thuê ngoài, từ điển WBS là căn cứ tốt để viết điều khoản phạm vi trong hợp đồng và nghiệm thu từng đợt.
Không cần viết từ điển cho mọi nút. Ưu tiên các gói công việc có giá trị lớn, có ranh giới mơ hồ với gói khác, hoặc giao cho bên ngoài. Bộ ba gồm WBS, từ điển WBS và bản mô tả phạm vi dự án thường được gọi chung là đường cơ sở phạm vi (scope baseline); mọi thay đổi sau khi đã phê duyệt phải đi qua quy trình kiểm soát thay đổi.
Ví dụ: WBS dự án mở kho hàng mới
Ví dụ giả định cho doanh nghiệp phân phối thuê một nhà kho có sẵn và đưa vào vận hành. Cấp hai theo sản phẩm bàn giao, chỉ trình bày tới cấp ba để dễ đọc:
- 1.1 Mặt bằng kho: 1.1.1 hợp đồng thuê đã ký; 1.1.2 cải tạo sàn và chiếu sáng hoàn thành; 1.1.3 hệ thống phòng cháy được nghiệm thu.
- 1.2 Thiết bị lưu trữ và bốc xếp: 1.2.1 hệ thống kệ đã lắp; 1.2.2 xe nâng và pallet đã nhận; 1.2.3 khu nhận và xuất hàng được bố trí.
- 1.3 Hệ thống thông tin kho: 1.3.1 phần mềm quản lý kho được cấu hình; 1.3.2 dữ liệu mã hàng và vị trí đã nhập; 1.3.3 máy quét và mạng nội bộ hoạt động.
- 1.4 Nhân sự vận hành: 1.4.1 nhân sự được tuyển; 1.4.2 quy trình nhập xuất được ban hành; 1.4.3 nhân sự được đào tạo và kiểm tra.
- 1.5 Chuyển đổi và khai trương: 1.5.1 hàng tồn được chuyển từ kho cũ; 1.5.2 vận hành thử hoàn thành; 1.5.3 bàn giao cho bộ phận vận hành.
- 1.6 Quản lý dự án: 1.6.1 kế hoạch dự án; 1.6.2 báo cáo định kỳ; 1.6.3 quản lý rủi ro và mua sắm; 1.6.4 báo cáo kết thúc.
Để ý những nút hay bị quên nếu chỉ nghĩ tới “thuê kho và mua kệ”: nghiệm thu phòng cháy, nhập dữ liệu vị trí, ban hành quy trình, chuyển hàng tồn và nhánh quản lý dự án. Đây thường là nơi ngân sách và tiến độ bị vượt, chính vì chúng không xuất hiện trong kế hoạch ban đầu.
Những lỗi hay gặp khi lập WBS
Các lỗi dưới đây xuất hiện lặp lại trong dự án ở nhiều ngành; kiểm nhanh WBS của bạn theo danh sách này:
- Biến WBS thành lịch: sắp các nút theo thứ tự thời gian và thêm mũi tên phụ thuộc. WBS không có trục thời gian; thứ tự thuộc về lịch tiến độ.
- Dùng động từ thay vì sản phẩm: “thiết kế”, “mua sắm”, “kiểm tra” lặp lại ở mọi nhánh, làm mất khả năng nghiệm thu theo hạng mục.
- Sao chép sơ đồ tổ chức: chia theo phòng ban khiến các sản phẩm cần nhiều phòng phối hợp không có chủ.
- Bỏ sót phần “mềm”: đào tạo, tài liệu, chuyển đổi dữ liệu, thủ tục pháp lý, quản lý thay đổi tổ chức.
- Không cập nhật: phạm vi đổi qua các yêu cầu thay đổi nhưng WBS vẫn là bản ban đầu, khiến báo cáo chi phí theo hạng mục mất ý nghĩa.
- Quá chi tiết từ đầu: chia tới việc vài giờ cho cả những phần sáu tháng sau mới làm, tốn công lập và không ai duy trì.
Câu hỏi thường gặp
WBS khác danh sách công việc thế nào?
WBS phân rã sản phẩm bàn giao theo cấu trúc cây và tuân theo quy tắc 100%. Danh sách công việc liệt kê các hoạt động cần làm để tạo ra từng gói công việc, có thời lượng và quan hệ phụ thuộc, dùng để dựng lịch. Một gói công việc thường tương ứng với vài đến vài chục công việc.
Có nên dùng phần mềm để vẽ WBS không?
Phần mềm giúp gắn mã, liên kết với lịch và ngân sách, nhưng giai đoạn động não nên làm trên giấy hoặc bảng trắng với cả nhóm để mọi người cùng nhìn thấy cấu trúc. Sau khi thống nhất mới đưa vào công cụ quản lý dự án hoặc bảng tính.
WBS có dùng được cho dự án agile không?
Có, nhưng ở dạng khác. Cấp trên thường là các nhóm tính năng hay mục tiêu đợt phát hành, các cấp dưới được chi tiết dần qua từng vòng lặp. Mục đích vẫn là bảo đảm không bỏ sót phạm vi và gom được chi phí, chỉ không cố định toàn bộ từ đầu.
Ai phê duyệt WBS?
Thường là nhà tài trợ dự án hoặc hội đồng chỉ đạo phê duyệt đường cơ sở phạm vi gồm WBS, từ điển và bản mô tả phạm vi. Với dự án hợp đồng, khách hàng nên xác nhận để WBS trở thành căn cứ nghiệm thu và xử lý phát sinh.
Có mẫu WBS chuẩn theo ngành không?
Nhiều tổ chức xây dựng mẫu WBS cho loại dự án lặp lại như mở cửa hàng, triển khai phần mềm, xây nhà xưởng. Mẫu giúp không quên phần quen thuộc, nhưng cần rà lại cho từng dự án vì mỗi dự án có điểm riêng mà mẫu không lường trước.
Nhánh quản lý dự án chiếm bao nhiêu phần trăm ngân sách?
Không có tỷ lệ cố định; nó phụ thuộc quy mô, độ phức tạp và yêu cầu báo cáo của dự án. Cách hợp lý là ước tính từ dưới lên: số giờ của người quản lý dự án, các cuộc họp, công cụ, báo cáo, thay vì lấy một tỷ lệ chung chung.