Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM của một dự án xây dựng ứng dụng mobile cho một chuỗi cà phê ở TP.HCM. Sếp hỏi: "Bao lâu xong? Tốn bao nhiêu tiền?" Nếu bạn buột miệng "khoảng 3 tháng" mà không dựa trên cơ sở nào, bạn vừa ký một tấm séc khống. Ba tháng sau, khi dự án trễ hạn và vượt ngân sách 40%, không ai nhớ rằng con số đó chỉ là một câu nói vu vơ — người ta chỉ nhớ rằng PM đã cam kết và đã thất hứa.
Ước lượng (estimation) là kỹ năng nền tảng nhất nhưng cũng bị xem nhẹ nhất trong quản lý dự án. Gần như mọi con số quan trọng trong dự án đều bắt nguồn từ estimate: lịch trình (schedule) được suy ra từ ước lượng thời gian của từng công việc; ngân sách (budget) được suy ra từ ước lượng chi phí; kế hoạch phân bổ nguồn lực (resource allocation) phụ thuộc vào việc bạn ước tính cần bao nhiêu người, trong bao lâu; và quan trọng nhất, cam kết với stakeholder — thứ định đoạt uy tín của bạn — đứng trên nền tảng của estimate.
Vấn đề là con người ước lượng rất tệ. Chúng ta mắc "optimism bias" — luôn nghĩ mọi thứ diễn ra suôn sẻ. Chúng ta quên tính đến những rủi ro chưa biết. Và chúng ta thường bị ép đưa ra một con số duy nhất trong khi thực tế luôn là một khoảng bất định. Bài học này sẽ trang bị cho bạn hai công cụ mạnh để đối phó với sự bất định đó: Three-Point Estimation và PERT. Đây không phải lý thuyết khô khan — đây là cách bạn biến "khoảng 3 tháng" thành một con số có cơ sở, có biên độ, và có thể bảo vệ được trước Steering Committee.
Khái niệm cốt lõi
Estimate là gì và không phải là gì
Estimate là một dự đoán có căn cứ về thời gian, chi phí hoặc nguồn lực cần thiết để hoàn thành một công việc. Điểm mấu chốt cần khắc sâu: estimate không phải là commitment, và cũng không phải là con số chính xác tuyệt đối. Một estimate tốt luôn đi kèm với một mức độ tin cậy và một khoảng dao động. Khi bạn nói "công việc này mất 5 ngày ± 2 ngày", bạn đang truyền đạt thông tin trung thực hơn nhiều so với việc nói cứng "5 ngày".
Một nguyên tắc kinh điển: độ chính xác của estimate tăng dần theo vòng đời dự án. Ở giai đoạn khởi động (initiation), khi thông tin còn ít, PMBOK chấp nhận độ chính xác cỡ Rough Order of Magnitude (ROM) từ -25% đến +75%. Đến giai đoạn lập kế hoạch chi tiết, bạn hướng tới Definitive Estimate với độ chính xác -5% đến +10%. Đừng bao giờ đưa ra một con số chính xác từng đồng khi bạn còn chưa biết phạm vi chi tiết — đó là tự đào hố cho mình.
Các kỹ thuật ước lượng phổ biến
Trước khi đi sâu vào Three-Point và PERT, cần đặt chúng vào bức tranh chung của các kỹ thuật ước lượng:
1. Analogous Estimation (ước lượng tương tự — top-down). Bạn dựa vào dữ liệu của một dự án tương tự trong quá khứ để suy ra dự án hiện tại. Ví dụ: "Dự án CRM năm ngoái mất 6 tháng và 12 người, dự án CRM lần này quy mô tương đương nên cũng khoảng vậy." Ưu điểm: nhanh, rẻ, dùng được khi thông tin còn sơ khai. Nhược điểm: kém chính xác, phụ thuộc vào mức độ giống nhau thật sự của hai dự án.
2. Parametric Estimation (ước lượng tham số). Dùng một biến số đơn vị nhân với khối lượng. Ví dụ: "Mỗi màn hình UI mất trung bình 3 ngày công, dự án có 20 màn hình → 60 ngày công." Chính xác hơn analogous nếu bạn có dữ liệu đơn giá đáng tin cậy.
3. Bottom-up Estimation (ước lượng từ dưới lên). Bạn chia nhỏ công việc đến mức work package (dựa trên WBS), ước lượng từng gói rồi cộng dồn lại. Đây là kỹ thuật chính xác nhất nhưng tốn công và thời gian nhất, thường dùng ở giai đoạn planning chi tiết.
4. Three-Point & PERT. Đây là nhân vật chính của bài. Thay vì đưa một con số duy nhất, bạn đưa ba con số để phản ánh sự bất định.
Three-Point Estimation — nghệ thuật của ba con số
Ý tưởng cực kỳ đơn giản nhưng cực kỳ mạnh: thay vì hỏi "công việc này mất bao lâu?", bạn hỏi ba câu:
- O — Optimistic (lạc quan): nếu mọi thứ trơn tru nhất, mất bao lâu?
- M — Most Likely (khả dĩ nhất): trong điều kiện bình thường, mất bao lâu?
- P — Pessimistic (bi quan): nếu gặp trục trặc, mất bao lâu?
Cách 1 — Triangular Distribution (phân phối tam giác):
E = (O + M + P) / 3
Cách 2 — PERT / Beta Distribution (phân phối Beta):
E = (O + 4M + P) / 6
PERT — không chỉ là con số kỳ vọng, mà cả độ bất định
Điểm làm PERT vượt trội so với một estimate đơn thuần là nó cho phép định lượng độ bất định thông qua độ lệch chuẩn (Standard Deviation — SD):
SD = (P - O) / 6
Khoảng cách giữa lạc quan và bi quan càng lớn, độ lệch chuẩn càng cao, nghĩa là công việc đó càng nhiều rủi ro và khó dự đoán. Từ SD, bạn có thể phát biểu estimate theo ngôn ngữ xác suất — thứ mà các stakeholder cấp cao rất thích nghe:
- E ± 1×SD → xác suất khoảng 68% hoàn thành trong khoảng này.
- E ± 2×SD → xác suất khoảng 95%.
- E ± 3×SD → xác suất khoảng 99.7%.
- E = (4 + 4×6 + 14) / 6 = 42/6 = 7 ngày.
- SD = (14 − 4) / 6 = 1.67 ngày.
- Vậy bạn có thể nói: "Tôi tin ~95% task này xong trong khoảng 7 ± 3.34 ngày, tức từ ~3.7 đến ~10.3 ngày."
Khi cộng nhiều task lại thành một chuỗi (ví dụ trên critical path), ta cộng các E lại trực tiếp, nhưng không cộng SD trực tiếp — ta cộng phương sai (variance = SD²) rồi lấy căn: SD_tổng = √(SD1² + SD2² + ...). Đây là điểm nhiều người làm sai.
Tình huống thực tế
Ví dụ 1 — FPT Software và gói tích hợp API bị "đánh giá thấp"
Một team tại FPT Software nhận gói phát triển module tích hợp thanh toán cho một khách hàng Nhật. Kỹ sư trưởng ước lượng "3 ngày là xong" dựa trên kinh nghiệm làm module tương tự. PM yêu cầu áp dụng Three-Point trong buổi planning. Khi được hỏi kỹ, chính kỹ sư đó thừa nhận:
- O = 2 ngày (nếu tài liệu API của phía Nhật đầy đủ).
- M = 4 ngày (thực tế thường có chỗ mập mờ phải hỏi lại).
- P = 12 ngày (nếu phía khách hàng phản hồi chậm do lệch múi giờ và rào cản ngôn ngữ).
Diễn giải: con số "3 ngày" ban đầu thậm chí còn thấp hơn cả kịch bản khả dĩ nhất (4 ngày). Chính khoảng cách O–P quá rộng (2 đến 12) đã phơi bày rủi ro thật: sự phụ thuộc vào phản hồi của khách hàng Nhật. Nhờ nhìn ra điều này, PM đã thêm một hành động phòng ngừa — thống nhất trước SLA phản hồi tài liệu với khách hàng — thay vì chỉ đơn thuần cộng thêm ngày.
Bài học: giá trị lớn nhất của Three-Point không nằm ở con số cuối cùng, mà ở cuộc hội thoại nó bắt buộc phải diễn ra. Câu hỏi "vì sao P lại lớn thế?" thường lôi ra những rủi ro mà không ai nghĩ tới.
Ví dụ 2 — Startup fintech Việt và cái bẫy cộng dồn con số bi quan
Một startup fintech ở Hà Nội lập kế hoạch cho MVP gồm 5 module trên critical path. PM cẩn thận lấy Three-Point cho từng module, nhưng để "an toàn", anh quyết định cộng dồn các con số Pessimistic lại với nhau để báo cáo cho nhà đầu tư: 12 + 15 + 10 + 8 + 20 = 65 ngày.
Nhà đầu tư nhìn con số và cắt ngân sách vì thấy dự án "quá chậm và quá tốn". Nhưng con số 65 ngày là sai về mặt thống kê — xác suất cả năm module cùng lúc rơi vào kịch bản tồi tệ nhất là cực kỳ thấp.
Cách làm đúng là cộng các giá trị E (PERT) lại:
- E các module: 8, 10, 7, 6, 13 → tổng E = 44 ngày.
- Variance từng module (SD²), giả sử SD lần lượt 1.7, 2.2, 1.3, 1.0, 2.8 → tổng variance ≈ 2.89 + 4.84 + 1.69 + 1.0 + 7.84 = 18.26 → SD_tổng = √18.26 ≈ 4.3 ngày.
- Báo cáo đúng: "Kỳ vọng 44 ngày, ~95% hoàn thành trong 44 ± 8.6 ngày, tức khoảng 35–53 ngày."
Ví dụ 3 — Nhà thầu xây dựng ở Bình Dương và Analogous "lười biếng"
Một nhà thầu thi công nhà xưởng ở Bình Dương nhận dự án mới và ước lượng bằng Analogous: "Xưởng năm ngoái 6 tháng, xưởng này y hệt nên cũng 6 tháng." Họ bỏ qua chi tiết: dự án mới nằm trên nền đất yếu cần gia cố móng, và rơi vào mùa mưa.
Kết quả: trễ 2 tháng. Nếu họ dùng Three-Point cho ít nhất các hạng mục rủi ro (phần móng), chênh lệch giữa O và P của hạng mục móng sẽ ngay lập tức báo động rằng đây là điểm bất định lớn cần dự phòng riêng.
Bài học: Analogous rất hữu ích ở giai đoạn sớm, nhưng đừng dùng nó như cái cớ để khỏi suy nghĩ. Hãy áp Three-Point cho những hạng mục có độ bất định cao nhất — đó là nơi rủi ro schedule thật sự ẩn nấp.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay trong buổi estimation với team:
Bước 1 — Chia nhỏ công việc đủ mịn. Dựa trên WBS, đảm bảo mỗi work package đủ nhỏ để có thể ước lượng đáng tin (thường 8–80 giờ công). Task quá lớn thì estimate sẽ vô nghĩa.
Bước 2 — Thu thập ba con số O, M, P cho từng task. Hỏi trực tiếp người sẽ làm việc đó, không phải người quản lý. Với mỗi con số, luôn hỏi kèm "dựa trên giả định gì?". Đặc biệt truy vấn P: "điều gì tệ nhất có thể xảy ra?".
Bước 3 — Tính E theo công thức PERT. E = (O + 4M + P) / 6. Nếu bạn thấy phân phối khá cân đối và không tin M nổi trội, có thể dùng công thức tam giác (O+M+P)/3, nhưng hãy nhất quán trong toàn dự án.
Bước 4 — Tính SD để đo bất định. SD = (P − O) / 6. Đánh dấu những task có SD cao — đó là các "điểm nóng rủi ro" cần chú ý.
Bước 5 — Tổng hợp theo chuỗi công việc. Cộng các E trên đường (thường là critical path). Với bất định, cộng variance (SD²) rồi lấy căn để ra SD tổng, tuyệt đối không cộng SD thẳng.
Bước 6 — Diễn đạt kết quả bằng khoảng và xác suất. Thay vì báo "44 ngày", báo "44 ngày với ~95% tin cậy trong khoảng 35–53 ngày". Điều này quản lý kỳ vọng của stakeholder một cách chuyên nghiệp.
Bước 7 — Xác định contingency reserve. Chênh lệch giữa E và mức tin cậy bạn muốn cam kết chính là cơ sở khoa học để xin dự phòng thời gian/ngân sách, thay vì "áng chừng thêm 20%".
Lỗi thường gặp & mẹo
Lỗi 1 — Ép một con số duy nhất. Khi sếp hỏi "bao lâu?", đừng vội trả lời một số. Hãy trả lời bằng khoảng: "Khả dĩ nhất là X, nhưng có thể dao động từ Y đến Z tùy vào [rủi ro]." Đây là dấu hiệu của một PM trưởng thành.
Lỗi 2 — Nhầm estimate với commitment. Estimate là dự đoán; commitment là lời hứa. Bạn có thể commit ở mức E + buffer để đạt độ tin cậy mong muốn, nhưng đừng commit đúng bằng estimate lạc quan.
Lỗi 3 — Cộng SD thẳng thay vì cộng variance. Đây là lỗi kỹ thuật phổ biến nhất. Nhớ: cộng E thì cộng thẳng, cộng bất định thì √(ΣSD²).
Lỗi 4 — Padding kép (đệm hai lần). Kỹ sư đã tự thêm buffer vào con số M của họ, rồi PM lại thêm buffer nữa, rồi sếp lại thêm nữa. Kết quả là estimate phồng to phi lý (theo hiệu ứng student syndrome, người ta sẽ dùng hết thời gian đó bất kể có cần hay không). Mẹo: yêu cầu con số "thật" không đệm, và quản lý buffer tập trung ở cấp dự án.
Lỗi 5 — Người quản lý ước lượng thay người làm. Ai làm việc, người đó ước lượng. Estimate áp đặt từ trên xuống gần như luôn sai và giết chết tinh thần trách nhiệm.
Mẹo hữu ích:
- Ghi lại giả định đằng sau mỗi estimate. Khi giả định thay đổi, estimate được phép thay đổi — và bạn có căn cứ để giải thích.
- Ước lượng theo nhóm (dùng kỹ thuật như wideband Delphi/Planning Poker) cho các task quan trọng để giảm thiên lệch cá nhân.
- Lưu lại estimate cũ và so với thực tế (actual) sau mỗi dự án — dữ liệu này làm cho các estimate tương lai (nhất là Analogous và Parametric) chính xác hơn hẳn.
- Cảnh giác với đơn vị: người này nghĩ "ngày làm việc", người kia nghĩ "ngày lịch". Thống nhất đơn vị trước.
Bài tập thực hành
Bài 1 — Tính cơ bản. Một task có O = 5 ngày, M = 8 ngày, P = 17 ngày. Hãy tính E theo PERT và SD. (Đáp án: E = (5 + 32 + 17)/6 = 9 ngày; SD = (17−5)/6 = 2 ngày.) Sau đó phát biểu khoảng tin cậy 95%.
Bài 2 — So sánh hai công thức. Với cùng dữ liệu O=5, M=8, P=17, hãy tính E theo phân phối tam giác (O+M+P)/3 và so sánh với PERT. Giải thích vì sao hai con số khác nhau và khi nào bạn chọn công thức nào.
Bài 3 — Chuỗi công việc. Một critical path gồm 3 task với (E, SD) lần lượt là (9; 2), (6; 1.5), (11; 2.5). Hãy tính tổng E và SD tổng của cả chuỗi. (Gợi ý: E_tổng = 26; variance = 4 + 2.25 + 6.25 = 12.5; SD_tổng = √12.5 ≈ 3.54.) Bạn sẽ cam kết mốc bàn giao ở con số nào để đạt ~95% tin cậy?
Bài 4 — Tình huống. Đội của bạn ước lượng một module là "10 ngày". Hãy viết ra 3 câu hỏi bạn sẽ đặt để chuyển nó thành một Three-Point Estimate, và nêu một rủi ro mà câu hỏi về Pessimistic có thể phơi bày.
Tóm tắt
Ước lượng là gốc rễ của mọi con số quan trọng trong dự án — lịch trình, ngân sách, nguồn lực và cam kết đều bắt nguồn từ đây. Con người ước lượng kém do optimism bias, nên chúng ta cần công cụ để đối phó với sự bất định thay vì giả vờ nó không tồn tại.
Three-Point Estimation buộc ta suy nghĩ theo ba kịch bản O, M, P — và chính cuộc hội thoại này giúp lộ ra rủi ro ẩn. PERT dùng công thức E = (O + 4M + P)/6 để tính giá trị kỳ vọng có trọng số, và SD = (P − O)/6 để định lượng độ bất định, cho phép ta phát biểu estimate bằng ngôn ngữ xác suất.
Hãy nhớ ba điều cốt lõi: (1) estimate là dự đoán, không phải lời hứa — luôn báo cáo bằng khoảng và xác suất; (2) khi tổng hợp chuỗi task, cộng E thẳng nhưng cộng bất định qua phương sai √(ΣSD²); (3) giá trị thật của kỹ thuật không nằm ở con số, mà ở việc nó buộc bạn và team đối diện với rủi ro một cách trung thực. Một PM giỏi không phải người đoán đúng con số, mà là người truyền đạt sự bất định một cách có trách nhiệm và biến nó thành kế hoạch dự phòng hợp lý.