Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang lái xe từ Hà Nội vào Đà Nẵng và bạn tự nhủ: "Chắc khoảng 12 tiếng là tới." Nhưng nếu bạn không có mốc thời gian cụ thể tại mỗi thành phố đi qua — Ninh Bình lúc mấy giờ, Vinh lúc mấy giờ, Đồng Hới lúc mấy giờ — thì đến khi tới Huế mà đã mất 11 tiếng, bạn cũng không biết mình đang chậm bao nhiêu, chậm từ chặng nào, và liệu có còn kịp về đích như kế hoạch hay không.
Trong quản lý dự án, Schedule Baseline (đường cơ sở tiến độ) chính là tấm bản đồ có ghi mốc giờ tại từng thành phố đó. Nó là phiên bản lịch trình đã được phê duyệt, đóng băng lại làm chuẩn để so sánh. Còn Schedule Variance (độ lệch tiến độ) là câu trả lời cho câu hỏi sống còn của mọi PM: "Dự án của tôi đang đúng tiến độ, sớm hơn, hay trễ hơn — và trễ bao nhiêu?"
Rất nhiều bạn PM mới vào nghề lập một cái Gantt chart rất đẹp, rồi... để đó. Khi sếp hỏi "dự án thế nào rồi?", họ trả lời bằng cảm tính: "Em thấy cũng ổn ổn ạ." Cảm tính không phải là công cụ quản lý. Bài học này sẽ cho bạn một cơ chế định lượng, rõ ràng, để bất kỳ lúc nào cũng biết chính xác mình đang đứng ở đâu so với kế hoạch — và quan trọng hơn, biết được điều đó sớm, khi vẫn còn thời gian để xử lý.
Khái niệm cốt lõi
Schedule Baseline là gì?
Schedule Baseline là phiên bản lịch trình dự án đã được phê duyệt chính thức (approved version), bao gồm ngày bắt đầu, ngày kết thúc và mốc thời gian của toàn bộ các công việc (activity) cùng các milestone quan trọng. Đặc điểm cốt lõi của baseline nằm ở ba chữ: không được thay đổi tùy tiện.
Baseline chỉ được sửa đổi khi có một formal change request (yêu cầu thay đổi chính thức) đã qua quy trình phê duyệt. Bạn không được lẳng lặng kéo dài mấy thanh Gantt vì công việc bị trễ rồi coi như "kế hoạch mới là đây". Làm vậy là bạn đã tự xóa đi cái chuẩn để so sánh — giống như đang chạy điền kinh mà tự di chuyển vạch đích lùi lại mỗi khi thấy mình sắp thua.
Hãy phân biệt rõ ba khái niệm hay bị nhầm:
- Baseline (đường cơ sở): Kế hoạch đã đóng băng, dùng làm chuẩn so sánh. Không đổi trừ khi có change request.
- Actual (thực tế): Điều thực sự đã diễn ra — công việc này bắt đầu ngày nào, xong ngày nào, tốn bao nhiêu ngày.
- Current/Forecast schedule (lịch hiện hành/dự báo): Lịch cập nhật liên tục, phản ánh tình hình mới nhất và dự báo tương lai dựa trên thực tế.
Vì sao phải "đóng băng" baseline?
Câu trả lời nằm ở chức năng đo lường. Nếu chuẩn cứ trôi theo thực tế thì sẽ không bao giờ có độ lệch, và không có độ lệch nghĩa là không có tín hiệu cảnh báo. Một baseline ổn định cho phép bạn:
- Đo lường hiệu suất một cách khách quan qua thời gian.
- Phát hiện sớm xu hướng chậm trễ khi nó mới manh nha.
- Bảo vệ chính bạn khi báo cáo với stakeholder: mọi con số đều truy nguyên được về một chuẩn đã được các bên đồng thuận.
- Rút kinh nghiệm cho các dự án sau: baseline nào ước lượng sát, baseline nào lệch nhiều.
Schedule Variance (SV) — độ lệch tiến độ
Schedule Variance trả lời câu hỏi: dự án đang nhanh hay chậm so với kế hoạch? Có hai cách hiểu và đo, tùy vào việc bạn dùng phương pháp đơn giản hay phương pháp Earned Value.
Cách 1 — So sánh trực tiếp theo thời gian (đơn giản, trực quan):
Với từng công việc hoặc milestone, bạn so ngày thực tế với ngày trên baseline:
> Độ lệch (ngày) = Ngày hoàn thành thực tế − Ngày hoàn thành theo baseline
Nếu kết quả dương → trễ; âm → sớm; bằng 0 → đúng kế hoạch. Cách này dễ hiểu, phù hợp báo cáo nhanh và các dự án vừa và nhỏ.
Cách 2 — Theo Earned Value Management (định lượng bằng tiền/giá trị công việc):
Đây là cách chuẩn theo PMBOK, cho phép quy tiến độ về một con số duy nhất:
> SV = EV − PV > Trong đó: > - PV (Planned Value): giá trị công việc lẽ ra đã hoàn thành tính đến thời điểm này theo baseline. > - EV (Earned Value): giá trị công việc thực sự đã hoàn thành.
Diễn giải:
- SV > 0 → dự án đi trước tiến độ (ahead of schedule).
- SV < 0 → dự án chậm tiến độ (behind schedule).
- SV = 0 → đúng tiến độ.
> SPI = EV / PV
- SPI > 1: làm nhanh hơn kế hoạch.
- SPI = 1: đúng kế hoạch.
- SPI < 1: chậm hơn kế hoạch.
Lưu ý quan trọng: Bài 36 sẽ đi sâu vào toàn bộ hệ thống Earned Value Management (bao gồm cả chi phí — CV, CPI). Ở bài này, ta chỉ dùng phần liên quan trực tiếp tới tiến độ (SV, SPI) như một công cụ để đo độ lệch so với schedule baseline. Đừng lo nếu bạn thấy EV/PV còn mới — hãy nắm ý nghĩa: chúng biến "tiến độ" thành con số so sánh được.
Milestone như những "trạm kiểm soát"
Ngoài đo theo từng activity, các milestone (cột mốc) trên baseline đóng vai trò như trạm kiểm soát. Mỗi khi tới một milestone, bạn dừng lại và hỏi: milestone này theo baseline phải đạt vào ngày nào, thực tế đạt vào ngày nào, lệch bao nhiêu? Đây là cách theo dõi nhẹ nhàng nhưng cực kỳ hiệu quả cho các dự án không dùng EVM đầy đủ.
Tình huống thực tế
Tình huống 1 — Dự án phần mềm tại FPT Software: baseline bị "trôi"
Anh Tuấn, một PM tại FPT Software, phụ trách dự án phát triển hệ thống quản lý kho cho một khách hàng Nhật Bản, thời lượng 6 tháng, baseline được ký duyệt ngày 1/3.
Trong hai tháng đầu, một số task bị trễ do khách hàng chậm cung cấp yêu cầu chi tiết. Thay vì giữ nguyên baseline và ghi nhận độ lệch, anh Tuấn liên tục kéo dài các thanh Gantt trong MS Project để "lịch cho khớp thực tế". Đến cuối tháng 4, khi giám đốc dự án hỏi tình hình, anh báo "vẫn đúng kế hoạch" — vì trên lịch hiện hành mọi thứ đúng là khớp thật.
Vấn đề vỡ lở ở tháng thứ 5: dự án thực chất đã trễ tổng cộng 18 ngày công so với kế hoạch gốc, nhưng không ai nhìn ra vì baseline đã bị sửa lén nhiều lần. Không còn chuẩn nào để tính SV.
Diễn giải: Nếu anh Tuấn giữ baseline cố định và ghi nhận SV ngay từ tháng đầu, anh sẽ thấy SPI tụt xuống khoảng 0,85 rất sớm, đủ để leo thang vấn đề "khách hàng chậm cung cấp yêu cầu" như một rủi ro chính thức và đàm phán gia hạn có căn cứ.
Bài học: Baseline trôi = mất khả năng cảnh báo. Nếu thực tế buộc phải đổi kế hoạch, hãy đi qua change request chính thức để tạo baseline mới (re-baseline), chứ đừng sửa lén.
Tình huống 2 — Đo SV bằng Earned Value cho dự án xây dựng tại một nhà thầu ở Bình Dương
Công ty xây dựng Đại Phát nhận thi công một nhà xưởng, tổng giá trị hợp đồng 10 tỷ đồng, kế hoạch 10 tháng. Theo baseline, đến hết tháng thứ 4, khối lượng công việc đáng lẽ hoàn thành tương đương PV = 4 tỷ đồng.
Đến cuối tháng 4, chị Hạnh — PM công trình — nghiệm thu và xác định khối lượng thực tế hoàn thành chỉ tương đương EV = 3,2 tỷ đồng.
Tính toán:
- SV = EV − PV = 3,2 − 4,0 = −0,8 tỷ → chậm tiến độ, tương đương 0,8 tỷ đồng khối lượng công việc.
- SPI = EV / PV = 3,2 / 4,0 = 0,8 → chỉ đạt 80% năng suất tiến độ.
Bài học: SV/SPI không chỉ nói "trễ hay không", mà còn cho phép dự báo đích đến. Phát hiện SPI = 0,8 ở tháng 4 khác hoàn toàn với phát hiện ở tháng 8 — thời điểm quyết định mức độ thiệt hại.
Tình huống 3 — Milestone tracking cho startup không dùng EVM
Một startup fintech ở TP.HCM triển khai app ví điện tử, đội chỉ 8 người, PM là chị Ngọc. Chị thấy EVM quá nặng nề cho quy mô này, nên chọn cách theo dõi baseline theo milestone.
Baseline có 5 milestone chính:
| Milestone | Baseline | Thực tế | Độ lệch |
|---|---|---|---|
| Hoàn thành thiết kế UX | 15/03 | 18/03 | +3 ngày |
| Xong module đăng ký/KYC | 15/04 | 22/04 | +7 ngày |
| Tích hợp cổng thanh toán | 15/05 | 30/05 | +15 ngày |
| Kiểm thử bảo mật | 30/05 | — | — |
| Go-live | 15/06 | — | — |
Bài học: Không nhất thiết phải dùng EVM đầy đủ. Với dự án nhỏ, theo dõi độ lệch tại milestone đã đủ mạnh — miễn là baseline được giữ cố định và bạn quan sát xu hướng, không chỉ con số đơn lẻ.
Hướng dẫn từng bước
Đây là quy trình thiết lập và theo dõi schedule baseline mà bạn có thể áp dụng ngay:
Bước 1 — Hoàn thiện lịch trình trước khi baseline. Đảm bảo WBS, ước lượng thời lượng, các phụ thuộc (dependency) và milestone đã đầy đủ và hợp lý. Baseline một lịch còn lỗ hổng sẽ khiến mọi phép đo về sau sai lệch.
Bước 2 — Lấy phê duyệt chính thức. Baseline phải được các bên liên quan chủ chốt (sponsor, khách hàng nếu cần) đồng thuận. Đây là cam kết chung, không phải quyết định riêng của PM.
Bước 3 — "Set baseline" và lưu snapshot. Trong công cụ (MS Project: Project → Set Baseline; các tool như Smartsheet, Primavera đều có tính năng tương tự), lưu lại snapshot ngày baseline. Ghi rõ ngày đóng băng. Nếu làm thủ công trên Excel, hãy copy cột kế hoạch sang một cột "Baseline" và khóa lại.
Bước 4 — Cập nhật actual định kỳ. Theo nhịp đều đặn (thường hàng tuần), ghi nhận % hoàn thành, ngày bắt đầu/kết thúc thực tế của từng công việc. Dữ liệu actual phải trung thực — đây là nguyên liệu cho mọi phép tính.
Bước 5 — Tính độ lệch. So actual với baseline. Với dự án nhỏ: tính độ lệch ngày tại các milestone. Với dự án lớn: tính EV, PV, rồi SV = EV − PV và SPI = EV / PV.
Bước 6 — Phân tích xu hướng và nguyên nhân. Đừng dừng ở con số. Hỏi: độ lệch đang tăng hay giảm? Do đâu (nguồn lực, phụ thuộc bên ngoài, ước lượng sai)? Ảnh hưởng tới critical path không?
Bước 7 — Hành động và báo cáo. Nếu lệch vượt ngưỡng cho phép (ví dụ SPI < 0,9), kích hoạt hành động khắc phục và báo cáo minh bạch cho stakeholder kèm con số.
Bước 8 — Re-baseline khi (và chỉ khi) cần. Nếu có thay đổi phạm vi lớn hoặc gia hạn được duyệt qua change request, hãy tạo baseline mới nhưng lưu giữ baseline cũ để phục vụ lessons learned. Đừng xóa lịch sử.
Lỗi thường gặp & mẹo
Lỗi 1 — Sửa baseline lén lút. Đây là lỗi chết người như tình huống anh Tuấn. Baseline trôi theo thực tế thì không còn là chuẩn nữa. Mẹo: Khóa cột baseline, đặt quyền chỉ-đọc, và chỉ đổi qua change request có ký duyệt.
Lỗi 2 — Không bao giờ set baseline. Nhiều PM lập Gantt rất công phu nhưng chưa bao giờ bấm "set baseline", nên không có gì để so sánh. Mẹo: Set baseline là một milestone bắt buộc trong checklist khởi động dự án.
Lỗi 3 — Nhầm "đúng ngân sách" với "đúng tiến độ". SV nói về tiến độ, không nói gì về tiền. Một dự án có thể SV âm (trễ) nhưng vẫn tiêu đúng tiền, hoặc ngược lại. Mẹo: Luôn nhìn tiến độ (SV/SPI) và chi phí (CV/CPI) song song — sẽ học kỹ ở Bài 36.
Lỗi 4 — Chỉ nhìn con số một thời điểm, bỏ qua xu hướng. SPI = 0,95 nghe ổn, nhưng nếu tuần trước là 0,99 và tuần trước nữa là 1,02 thì bạn đang tuột dốc. Mẹo: Vẽ đường SPI/độ lệch theo thời gian để thấy hướng đi.
Lỗi 5 — Re-baseline quá thường xuyên. Cứ trễ là re-baseline thì cũng như không có baseline. Mẹo: Chỉ re-baseline khi có thay đổi thực chất và được phê duyệt, không phải để "làm đẹp báo cáo".
Mẹo cộng thêm: Đặt ngưỡng cảnh báo (threshold) ngay từ đầu — ví dụ "SPI < 0,9 hoặc bất kỳ milestone nào trễ > 5 ngày thì phải leo thang". Có ngưỡng rõ ràng giúp bạn hành động kịp thời thay vì tranh cãi "thế này đã đáng lo chưa".
Bài tập thực hành
Bài 1 — Tính SV và SPI. Một dự án có baseline: đến hết tháng 3, giá trị công việc kế hoạch PV = 500 triệu đồng. Thực tế EV = 425 triệu đồng. Hãy tính SV, SPI và diễn giải: dự án đang nhanh hay chậm? Nếu năng suất giữ nguyên, dự án 8 tháng dự kiến kéo dài khoảng bao lâu?
Bài 2 — Đọc bảng milestone. Lập một bảng gồm 4 milestone của một dự án bạn tưởng tượng (ví dụ ra mắt website), điền ngày baseline và ngày thực tế sao cho độ lệch tăng dần. Xác định xu hướng và viết 2 câu bạn sẽ báo cáo cho sponsor.
Bài 3 — Tình huống ra quyết định. Dự án của bạn có SPI = 0,82 ở tháng thứ 3 trên tổng thời lượng 9 tháng, nguyên nhân là một nhà cung cấp bên ngoài giao trễ. Bạn sẽ: (a) giữ baseline hay re-baseline? (b) đề xuất những hành động khắc phục nào? Viết ngắn gọn lập luận.
Bài 4 — Thực hành công cụ. Mở MS Project hoặc một file Excel Gantt, tạo 5 công việc, set baseline, rồi giả lập 2 công việc trễ và tính độ lệch tại một milestone. Lưu lại snapshot baseline.
Tóm tắt
- Schedule Baseline là phiên bản lịch trình đã được phê duyệt, đóng băng làm chuẩn so sánh. Nó chỉ đổi qua formal change request — không bao giờ sửa lén theo thực tế.
- Hãy lưu snapshot baseline tại ngày phê duyệt, rồi cập nhật actual định kỳ để so sánh.
- Schedule Variance (SV) đo độ lệch tiến độ. Cách đơn giản: so ngày thực tế với ngày baseline. Cách chuẩn EVM: SV = EV − PV và SPI = EV / PV.
- SV > 0 / SPI > 1: đi trước tiến độ; SV < 0 / SPI < 1: chậm tiến độ.
- SPI còn giúp dự báo thời gian hoàn thành thực tế, cho phép hành động sớm.
- Giá trị lớn nhất của baseline là phát hiện sớm xu hướng chậm trễ. Baseline trôi = mất khả năng cảnh báo.
- Với dự án nhỏ, theo dõi độ lệch tại milestone đã đủ mạnh; với dự án lớn, dùng EVM đầy đủ (sẽ đào sâu ở Bài 36).