Mở đầu — vì sao bài này quan trọng
Có một câu nói kinh điển trong nghề quản lý dự án: "Sếp không sợ dự án khó, sếp sợ dự án không biết bao giờ xong và tốn bao nhiêu tiền." Ước lượng (estimation) chính là kỹ năng giúp bạn trả lời hai câu hỏi ám ảnh đó: dự án này mất bao lâu? và tốn khoảng bao nhiêu? Nếu bạn ước lượng sai, mọi thứ phía sau — lịch trình, ngân sách, cam kết với khách hàng, thậm chí uy tín của bạn — đều sụp đổ theo.
Trong kỳ thi PMP, ước lượng xuất hiện dày đặc. Bạn sẽ gặp câu hỏi về Analogous, Parametric, Three-point (PERT), Bottom-up, và các khái niệm liên quan như estimate range, confidence level, contingency. PMBOK 7 nhấn mạnh tư duy "ước lượng là một dải giá trị chứ không phải một con số đơn", và rằng độ chính xác của ước lượng phải tăng dần khi dự án tiến triển (progressive elaboration). Đây là một trong những nhóm kiến thức "chắc chắn có trong đề", nên nắm vững sẽ giúp bạn ăn điểm dễ dàng.
Nhưng quan trọng hơn cả điểm thi: trong thực tế, người PM biết ước lượng tử tế sẽ được tin tưởng giao những dự án lớn, còn người ước lượng bừa sẽ mãi loay hoay với các dự án cháy deadline. Bài này sẽ giúp bạn phân biệt rạch ròi từng kỹ thuật, biết khi nào dùng cái nào, và tránh những cái bẫy mà 90% PM mới mắc phải.
Lưu ý phạm vi: bài này tập trung riêng vào các kỹ thuật ước lượng thời lượng và chi phí ở cấp độ activity/work package. Việc xây dựng đường găng (CPM), quản lý chi phí bằng EVM, hay ước lượng độ lớn công việc Agile bằng story point sẽ được xử lý ở các bài khác. Ở đây, ta đào sâu vào bốn kỹ thuật nền tảng và cách phối hợp chúng.
Khái niệm cốt lõi
Trước hết cần hiểu: ước lượng luôn có sai số, và điều đó là bình thường. PMBOK phân biệt hai thứ dễ nhầm — estimate (ước lượng, mang tính dự đoán, có dải sai số) và target/commitment (mục tiêu hoặc cam kết, thường do quản lý áp xuống). Người PM giỏi không bao giờ để cấp trên biến một ước lượng lạc quan thành cam kết cứng.
Một khái niệm quan trọng khác là Cone of Uncertainty (nón bất định): ở đầu dự án, khi thông tin ít, ước lượng có thể sai lệch từ -50% đến +100%. Càng về sau, khi đã làm rõ phạm vi, sai số thu hẹp dần. Vì thế PMBOK phân loại độ chính xác ước lượng thành các cấp: Rough Order of Magnitude (ROM) ở giai đoạn khởi động (thường -25% đến +75%), và Definitive Estimate ở giai đoạn lập kế hoạch chi tiết (-5% đến +10%). Khi thi, nếu đề hỏi "ở giai đoạn ý tưởng ban đầu, độ chính xác ước lượng là bao nhiêu?", đáp án đúng thường là dải ROM rộng.
1. Analogous Estimating (ước lượng tương tự — top-down)
Đây là kỹ thuật dựa trên dữ liệu lịch sử của các dự án tương tự đã làm. Ví dụ: "Dự án website bán hàng năm ngoái mất 4 tháng và 800 triệu, dự án lần này quy mô tương đương nên ước cũng khoảng 4 tháng, 800 triệu."
- Ưu điểm: Nhanh, rẻ, dùng được ngay cả khi thông tin còn rất sơ sài — lý tưởng cho giai đoạn khởi động hoặc để chào giá sơ bộ.
- Nhược điểm: Độ chính xác thấp nhất. Phụ thuộc hoàn toàn vào việc dự án cũ có thực sự giống dự án mới hay không, và vào kinh nghiệm của người ước lượng (expert judgment).
- Khi nào dùng: Giai đoạn đầu, khi cần con số nhanh để quyết định "có làm hay không".
2. Parametric Estimating (ước lượng tham số)
Dùng quan hệ thống kê giữa dữ liệu lịch sử và các biến số để tính ra ước lượng bằng công thức. Điểm mấu chốt là phải có một đơn giá (rate) đáng tin cậy.
Công thức tổng quát: Ước lượng = Khối lượng × Đơn giá.
Ví dụ: nếu lịch sử cho biết lập trình viên viết được 50 dòng code chất lượng mỗi ngày, và module mới cần 5.000 dòng, thì thời gian = 5.000 ÷ 50 = 100 ngày-người. Hoặc trong xây dựng: sơn 1 m² tường mất 0,1 công, tường cần sơn là 500 m² → 50 công.
- Ưu điểm: Chính xác hơn Analogous nếu đơn giá tin cậy và công việc có tính lặp lại, đo lường được. Có thể mở rộng tỷ lệ (scalable).
- Nhược điểm: Chỉ tốt khi công việc đồng nhất. Với công việc sáng tạo, phi tuyến tính (như thiết kế UX, nghiên cứu) thì công thức dễ sai.
3. Three-point Estimating / PERT (ước lượng ba điểm)
Thay vì đoán một con số, bạn đưa ra ba kịch bản:
- O (Optimistic) — lạc quan nhất, mọi thứ suôn sẻ.
- M (Most Likely) — khả năng cao nhất, thực tế nhất.
- P (Pessimistic) — bi quan nhất, mọi thứ trục trặc.
- Phân phối Beta (PERT):
E = (O + 4M + P) / 6— cho trọng số cao hơn cho giá trị Most Likely. - Phân phối Triangular:
E = (O + M + P) / 3— trung bình đơn giản của cả ba.
SD = (P − O) / 6.Ví dụ: một tác vụ có O = 8 ngày, M = 10 ngày, P = 18 ngày.
- PERT: E = (8 + 4×10 + 18) / 6 = 66/6 = 11 ngày.
- SD = (18 − 8)/6 = 1,67 ngày.
Điểm mạnh của PERT là nó buộc bạn suy nghĩ về rủi ro và bất định thay vì đưa một con số ảo tưởng. Đây là kỹ thuật được ưa chuộng cho các tác vụ có độ không chắc chắn cao.
4. Bottom-up Estimating (ước lượng từ dưới lên)
Bạn chia dự án thành các work package/activity nhỏ nhất trong WBS, ước lượng từng phần, rồi cộng dồn lên để ra tổng.
- Ưu điểm: Chính xác nhất trong bốn kỹ thuật, vì ước lượng chi tiết từng phần. Tạo được sự cam kết từ những người trực tiếp làm.
- Nhược điểm: Tốn thời gian và công sức nhất, đòi hỏi phạm vi đã được làm rõ (đã có WBS). Không dùng được ở giai đoạn sơ khai.
Tình huống thực tế
Ví dụ 1 — Công ty phần mềm ở TP.HCM chào giá gấp
FPT Software nhận yêu cầu báo giá một hệ thống quản lý kho cho khách Nhật, và khách cần con số trong 48 giờ để trình hội đồng. Anh Tuấn, PM phụ trách, không có đủ thời gian bóc tách chi tiết. Anh lôi ra dự án WMS đã triển khai năm ngoái cho một khách Singapore — quy mô module gần tương đương — mất 6 tháng và 2,4 tỷ đồng. Anh dùng Analogous Estimating, điều chỉnh +15% vì khách Nhật đòi tài liệu chi tiết hơn, ra con số ROM khoảng 7 tháng và 2,8 tỷ.
Điều anh làm đúng: anh ghi rõ trong báo giá "đây là ước lượng ROM, độ chính xác -25% đến +75%, sẽ tinh chỉnh sau khi khảo sát yêu cầu chi tiết". Nhờ vậy khi phạm vi thực tế phình ra, khách không bất ngờ.
Bài học: Analogous là công cụ tuyệt vời để phản ứng nhanh, nhưng phải luôn kèm nhãn "ROM" và một dải sai số. Đừng bao giờ để con số nhanh này bị hiểu thành cam kết cứng.
Ví dụ 2 — Nhà thầu xây dựng dùng Parametric
Một công ty xây dựng ở Bình Dương ước lượng chi phí ốp gạch cho một tòa văn phòng. Họ có dữ liệu lịch sử rất rõ: chi phí ốp gạch trung bình là 280.000 đồng/m² (đã gồm vật tư và nhân công), và tòa nhà cần ốp 3.500 m². Bằng Parametric Estimating: 3.500 × 280.000 = 980 triệu đồng.
Nhưng chị Hà, chỉ huy trưởng, cẩn thận thêm: khu vực sảnh dùng đá granite nhập, đơn giá tới 1,2 triệu/m² cho 200 m². Chị tách riêng phần này ra tính parametric với đơn giá khác. Đây là điểm tinh tế: parametric chỉ chính xác khi công việc đồng nhất; hễ gặp phần khác biệt, phải tách nhóm và áp đơn giá riêng.
Bài học: Parametric rất mạnh cho công việc lặp lại, đo lường được. Nhưng đơn giá phải "sạch" và bạn phải đủ tỉnh táo để nhận ra khi nào một phần công việc không còn đồng nhất nữa.
Ví dụ 3 — Startup fintech dùng PERT cho tác vụ rủi ro cao
Một startup fintech ở Hà Nội cần tích hợp với cổng thanh toán của một ngân hàng — việc phụ thuộc nhiều vào tốc độ phản hồi của bên ngân hàng, vốn nổi tiếng chậm. PM Minh biết không thể ước một con số cứng. Anh dùng Three-point:
- O = 10 ngày (nếu ngân hàng phản hồi nhanh, tài liệu API đầy đủ).
- M = 20 ngày (kịch bản thực tế).
- P = 45 ngày (nếu ngân hàng đổi yêu cầu, sandbox lỗi liên tục).
Minh trình lãnh đạo: "Tác vụ này khả năng cao mất 22,5 ngày, nhưng vì SD lớn tới 5,8 ngày, độ bất định rất cao — tôi đề nghị dành contingency và không cam kết mốc cứng trước ngày 34." Con số SD lớn chính là bằng chứng định lượng để anh xin thêm dự phòng.
Bài học: Khi tác vụ phụ thuộc yếu tố ngoài tầm kiểm soát, PERT vừa cho con số hợp lý, vừa cho bạn thước đo rủi ro (SD) để đàm phán contingency một cách thuyết phục.
Hướng dẫn từng bước
Đây là quy trình phối hợp các kỹ thuật trong một dự án thực tế:
- Xác định giai đoạn dự án. Nếu đang ở khởi động/ý tưởng, dùng Analogous hoặc Parametric để ra ROM. Nếu đã có WBS chi tiết, chuyển sang Bottom-up.
- Chọn kỹ thuật theo bản chất công việc.
- Thu thập dữ liệu đầu vào. Với Parametric: tìm đơn giá lịch sử. Với PERT: hỏi chuyên gia ba kịch bản O/M/P. Với Bottom-up: bóc tách WBS đến cấp work package.
- Tính toán. Áp công thức tương ứng. Với PERT nhớ tính cả SD để biết mức bất định.
- Cộng dồn và thêm dự phòng (reserve). Cộng các ước lượng lại. Thêm contingency reserve cho rủi ro đã biết (thường tính từ SD hoặc phân tích rủi ro), và lưu ý management reserve cho rủi ro chưa biết (nằm ngoài baseline, do quản lý cấp cao kiểm soát).
- Trình bày dưới dạng dải, không phải một số. Ví dụ "18–24 ngày, 90% tin cậy" thay vì "20 ngày".
- Tinh chỉnh dần (progressive elaboration). Khi dự án tiến triển, cập nhật lại ước lượng, thu hẹp dải sai số theo nón bất định.
Lỗi thường gặp & mẹo
Lỗi 1 — Đưa một con số cứng thay vì một dải. Khi bạn nói "3 tháng", người nghe hiểu là cam kết. Hãy luôn nói "3 đến 4 tháng, tùy…".
Lỗi 2 — Nhầm estimate với target. Sếp bảo "làm sao xong trong 2 tháng nhé" — đó là target, không phải ước lượng của bạn. Đừng để áp lực biến ước lượng thành mong muốn.
Lỗi 3 — Quên padding ẩn. Nhiều PM tự cộng thêm 20% "cho chắc" vào mỗi tác vụ mà không nói ra. Điều này làm mất minh bạch. Thay vào đó, hãy tách riêng phần dự phòng (contingency reserve) rõ ràng.
Lỗi 4 — Dùng đơn giá parametric cho công việc không đồng nhất. Như ví dụ 2, đá granite khác gạch thường. Luôn kiểm tra tính đồng nhất trước khi nhân đơn giá.
Lỗi 5 — Ép ước lượng chính xác quá sớm. Ở giai đoạn ý tưởng mà đòi Bottom-up chi tiết là lãng phí, vì phạm vi còn chưa rõ. Đúng công cụ, đúng thời điểm.
Lỗi 6 — Nhầm công thức PERT và Triangular khi thi. PERT có số 4 và chia 6: (O+4M+P)/6. Triangular chia 3: (O+M+P)/3. Đề PMP hay bẫy ở đây.
Mẹo: Khi thi, nếu đề cho O, M, P mà không nói rõ phân phối, mặc định dùng Beta/PERT (chia 6). Nếu đề nói "simple average" hay "triangular", mới chia 3.
Mẹo: Nhớ SD = (P−O)/6 và quy tắc 68-95-99,7 để trả lời các câu về khoảng tin cậy (confidence interval).
Mẹo văn hóa VN/ĐNA: Ở nhiều team Việt, nhân viên có xu hướng đưa ước lượng lạc quan để "làm hài lòng sếp". Hãy chủ động hỏi cả ba kịch bản O/M/P để kéo ra con số thực tế thay vì con số dễ nghe.
Bài tập thực hành
Bài 1 (PERT cơ bản): Một tác vụ có O = 6 ngày, M = 9 ngày, P = 18 ngày. Tính ước lượng PERT và độ lệch chuẩn. Cho biết khoảng thời gian với 95% độ tin cậy. (Gợi ý đáp án: E = (6+36+18)/6 = 10 ngày; SD = (18−6)/6 = 2; 95% → 10 ± 4 = 6 đến 14 ngày.)
Bài 2 (Parametric): Đội nhập liệu xử lý được 120 hồ sơ/người/ngày. Dự án cần nhập 30.000 hồ sơ, có 5 người làm. Ước lượng số ngày hoàn thành. (Gợi ý: 30.000 ÷ 120 = 250 ngày-người; ÷ 5 người = 50 ngày.)
Bài 3 (Chọn kỹ thuật): Với mỗi tình huống, hãy chọn kỹ thuật phù hợp nhất và giải thích: a) Cần báo giá sơ bộ cho khách trong 1 ngày, đã có 3 dự án tương tự. b) Ước lượng chi phí đổ bê tông sàn theo m³, có đơn giá lịch sử ổn định. c) Ước lượng một tác vụ R&D chưa từng làm, độ bất định rất cao. d) Dự án đã có WBS đầy đủ, khách yêu cầu ngân sách chính xác ±5%. (Gợi ý: a-Analogous, b-Parametric, c-Three-point/PERT, d-Bottom-up.)
Bài 4 (Tư duy thực tế): Sếp bạn xem ước lượng PERT của một tác vụ là 22,5 ngày với SD 5,8 ngày, rồi bảo "cứ ghi 22 ngày vào hợp đồng". Bạn sẽ trả lời thế nào để bảo vệ dự án? Viết ra 3 luận điểm. (Gợi ý: SD lớn = bất định cao; cam kết 22 ngày chỉ ~50% khả năng đạt được; nên cam kết mốc an toàn hơn hoặc kèm contingency reserve.)
Tóm tắt
- Ước lượng là dải giá trị có sai số, không phải một con số thần thánh. Độ chính xác tăng dần theo tiến độ dự án (nón bất định, ROM → Definitive).
- Analogous (top-down): nhanh, rẻ, kém chính xác nhất — dùng khi thông tin ít, cần con số gấp.
- Parametric: dùng công thức Khối lượng × Đơn giá — chính xác khi công việc đồng nhất và đơn giá tin cậy.
- Three-point / PERT: ba kịch bản O/M/P. Nhớ
E=(O+4M+P)/6,SD=(P−O)/6, và quy tắc 68-95-99,7 — lý tưởng cho tác vụ bất định cao. - Bottom-up: chính xác nhất nhưng tốn công nhất — cần WBS chi tiết.
- Luôn phân biệt estimate với target/commitment, tách riêng contingency reserve, và trình bày ước lượng dưới dạng dải.
- Khi thi: cẩn thận công thức PERT (chia 6) và Triangular (chia 3); mặc định dùng PERT nếu đề không nói rõ.