Predictive dùng CPM và Gantt; Agile dùng Sprint và burndown. PMBOK 8 yêu cầu PM hiểu cả hai và hybrid chúng lại. Bài này đi qua schedule management đủ cả hai approach.
1. Tại sao schedule là ràng buộc dễ vỡ nhất?
Budget có thể xin thêm. Scope có thể cắt giảm. Nhưng thời gian? Một ngày đã qua không bao giờ lấy lại được. Đó là lý do schedule management đặc biệt quan trọng — và PMBOK 8 dành nguyên Performance Domain cho nó.
PMBOK® 8, Section 2.3: "Project scheduling provides a plan that represents how and when the project will deliver the products, services, and results defined in the project scope. The schedule serves as a tool for communication, managing stakeholder expectations, and provides a basis for performance reporting."
Schedule cũng là nơi mọi vấn đề khác "hiện hình" — resource thiếu → schedule trễ, scope creep → schedule trễ, risk xảy ra → schedule trễ. Quản lý schedule tốt = quản lý toàn bộ dự án tốt.
2. Bốn bước phát triển schedule theo PMBOK 8
PMBOK 8 (Section 2.3.2.2) xác định 4 bước rõ ràng:
Bước | Hoạt động | Output |
|---|---|---|
1. Define Activities | Decompose work packages → schedule activities | Activity list, activity attributes, milestone list |
2. Determine Sequence | Xác định logical relationships (dependencies) giữa activities | Project schedule network diagram |
3. Estimate Effort & Duration | Ước tính effort (labor units) và duration (work periods) | Duration estimates, basis of estimates |
4. Adjust | Apply CPM, compression, resource optimization, reserves | Schedule baseline, project schedule |
💡 PMBOK® 8: "Developing an acceptable project schedule is an iterative process. Schedule development may require review and revision of duration estimates, resource estimates, and schedule reserves to establish an approved schedule baseline."
3. Estimation — Từ analogous đến story points
6 kỹ thuật ước tính từ PMBOK 8
Technique | Mô tả | Accuracy | Approach |
|---|---|---|---|
Analogous | Dựa trên dự án tương tự trước đó | Thấp-TB | Predictive & Adaptive |
Parametric | Statistical relationship (VD: 1 developer = 5 stories/sprint) | TB-Cao | Predictive |
Bottom-up | Estimate từng activity, cộng lại | Cao nhất | Predictive |
Three-point (PERT) | (O + 4ML + P) / 6 | TB-Cao | Predictive |
Relative sizing | Story points, T-shirt sizing, Planning Poker | TB | Adaptive |
Expert judgment | SME opinion | Variable | Cả hai |
💡 PMBOK 8 nhấn mạnh benchmarks and historical data: "Project files from previous projects such as scope, cost, schedules, performance measurement baselines" là organizational process assets quý giá nhất cho estimation.
Effort vs. Duration — Phân biệt rõ
Effort | Duration | |
|---|---|---|
Định nghĩa | Số labor units cần để hoàn thành (hours, person-days) | Số work periods từ start đến finish |
Ví dụ | Task cần 40 person-hours effort | Với 2 people → duration = 20 hours (2.5 days) |
Thay đổi khi | Scope thay đổi | Resources thay đổi (thêm/bớt người) |
4. Dependencies và float — DNA của schedule
4 loại dependencies — PMBOK 8
Loại | Mô tả | Ví dụ | Thay đổi được? |
|---|---|---|---|
Mandatory (Hard logic) | Bắt buộc theo logic kỹ thuật/legal | Đổ móng trước khi xây tường | Không |
Discretionary (Soft logic) | Best practice, team preference | Design review trước khi code | Có (khi cần) |
External | Phụ thuộc bên ngoài dự án | Vendor giao equipment, government permit | Không (ngoài kiểm soát) |
Internal | Phụ thuộc trong tổ chức/team | Database team xong → API team bắt đầu | Có thể negotiate |
Precedence Diagramming Method (PDM) — 4 relationship types
Relationship | Ý nghĩa | Ví dụ |
|---|---|---|
Finish-to-Start (FS) | A xong → B bắt đầu | Code xong → Testing bắt đầu (phổ biến nhất) |
Finish-to-Finish (FF) | A xong → B xong | Document viết xong khi code xong |
Start-to-Start (SS) | A bắt đầu → B bắt đầu | Leveling và pouring bắt đầu cùng lúc |
Start-to-Finish (SF) | A bắt đầu → B kết thúc | Rất hiếm — hệ thống mới bắt đầu → hệ thống cũ kết thúc |
Lead và Lag
Lead = overlap giữa activities (VD: testing bắt đầu 2 ngày trước khi coding hoàn tất). Lag = waiting time giữa activities (VD: đổ bê tông xong phải chờ 3 ngày mới tiếp tục = lag 3 days). Lead tăng tốc schedule. Lag làm chậm schedule.
Float (Slack)
Total Float = thời gian activity có thể delay mà KHÔNG ảnh hưởng project end date. Free Float = thời gian activity có thể delay mà KHÔNG ảnh hưởng start date của successor. Activities trên critical path có Total Float = 0.
5. Critical Path Method — Xương sống của schedule predictive
PMBOK 8: "The critical path method is used to estimate the minimum project duration and determine the amount of schedule flexibility on the logical network paths within the schedule model."
Critical Path = chuỗi activities dài nhất qua network diagram = thời gian ngắn nhất để hoàn thành dự án. Bất kỳ delay nào trên critical path = delay toàn bộ dự án.
Critical Chain Method
PMBOK 8 cũng đề cập Critical Chain Method — tương tự CPM nhưng thêm resource constraints và sử dụng buffers (project buffer, feeding buffer) thay vì float. Đặc biệt hữu ích khi resource conflicts phổ biến.
6. Schedule Compression — Khi cần nhanh hơn
Khi schedule cần rút ngắn mà scope không thể giảm — PMBOK 8 cung cấp 2 kỹ thuật:
Fast-Tracking | Crashing | |
|---|---|---|
Kỹ thuật | Chạy song song activities vốn sequential | Thêm resources để rút ngắn duration |
Chi phí | Thường không tăng trực tiếp | LUÔN tăng chi phí |
Risk | Tăng risk (rework nếu predecessor thay đổi) | Ít risk hơn nhưng cost impact |
Áp dụng cho | Activities có discretionary dependency | Activities trên critical path |
Ví dụ | Bắt đầu testing khi coding chưa hoàn tất 100% | Thêm developers, OT, thuê thêm contractor |
Giới hạn | Chỉ áp dụng khi activities CÓ THỂ overlap | Diminishing returns — thêm người không luôn nhanh hơn (Brooks's Law) |
💡 Mẹo PMP: Fast-tracking = KHÔNG tăng cost, TĂNG risk. Crashing = TĂNG cost, ít risk hơn. Khi đề hỏi "compress schedule with minimum additional cost" → fast-tracking. "Compress schedule by adding resources" → crashing. "Compress without increasing risk" → crashing (not fast-tracking).
7. Schedule trong Adaptive — Velocity, burndown, và flow
Agile Release Planning
PMBOK 8: "Relationship among product vision, release planning, and iteration planning" — 3 tầng planning trong agile: Product Vision (toàn bộ product), Release Plan (nhóm iterations tạo thành release), Iteration Plan (sprint-level detailed plan).
Velocity-Based Planning
Velocity = story points hoàn thành mỗi sprint. Sau 3-5 sprints, velocity stabilize → dùng để forecast: Remaining story points ÷ Average velocity = Sprints remaining.
Burndown và Burnup Charts
Iteration Burndown = remaining work trong sprint. Lý tưởng: đường cong giảm đều về 0. Release Burnup = completed work tích lũy qua releases. Lý tưởng: đường cong tăng đều đến target.
Flow-Based Scheduling
PMBOK 8: "Focuses on optimizing the flow of work through a system. Maximizing flow of deliverables based on resource capacity. Minimizing time and resource waste." Kanban boards, WIP limits, và Theory of Constraints — không timeboxed như Scrum mà continuous flow.
8. Baseline, monitor, và analyze variance
Baseline a Project Schedule
PMBOK 8: "The schedule baseline is the approved version of a schedule model that can be changed using formal change control procedures."
Predictive: Schedule baseline approved qua CCB. Changes → formal change request + impact analysis. Adaptive: Baseline per iteration — "defined at the beginning of each iteration and aligned with the prioritized requirements." Flexible, rolling wave.
Analyze Schedule Variance
Metric | Công thức | Ý nghĩa | Giá trị tốt |
|---|---|---|---|
SV (Schedule Variance) | EV - PV | Ahead or behind schedule? | SV > 0 = ahead |
SPI (Schedule Performance Index) | EV / PV | % of planned work completed | SPI > 1.0 = ahead |
⚠️ PMBOK 8 lưu ý: "A schedule variance may show a correlation with project team member dissatisfaction. This correlation can assist in addressing a root cause that may not have been obvious." — Schedule metrics không chỉ đo tiến độ mà có thể reveal deeper issues.
Coordinate with Other Projects
PM phải coordinate: shared resources giữa projects (availability conflicts), inter-project dependencies (deliverables từ project khác), organizational operations (resource competition with BAU work), và portfolio-level constraints (budget allocation timing).
9. Mẹo thi PMP
📍Mẹo 1 — Critical Path = zero float: Activities trên critical path có Total Float = 0. Delay bất kỳ activity nào trên CP = delay project. Khi đề hỏi "which activity delay will impact project end date?" → activity trên critical path.
📍Mẹo 2 — Fast-tracking vs Crashing: Fast-tracking = parallel (no cost, more risk). Crashing = add resources (more cost, less risk). "Minimum cost" → fast-track. "Minimum risk" → crash. Crashing chỉ effective trên CRITICAL PATH activities.
📍Mẹo 3 — PERT formula: (O + 4ML + P) / 6 = Expected duration. Standard deviation = (P - O) / 6. Đề thi thường cho O, ML, P và hỏi expected duration hoặc range.
📍Mẹo 4 — Resource Leveling vs Smoothing: Leveling = CÓ THỂ kéo dài schedule (change critical path). Smoothing = KHÔNG kéo dài (chỉ dùng float). "Deadline cannot change" → smoothing.
10. Mười câu hỏi trắc nghiệm tình huống
Question 1
Your project network has 4 paths: A-B-C (15 days), A-D-E (20 days), A-F-G (18 days), A-H-I (20 days). Activities D-E and H-I both have zero float.
How many critical paths does this project have?
A. 1 — the longest path (A-D-E at 20 days).
B. 2 — both 20-day paths (A-D-E and A-H-I) are critical paths.
C. 4 — all paths are critical.
D. 0 — critical path can only be determined with resource assignments.
Question 2
Your project is 2 weeks behind schedule. The sponsor demands you finish on the original date. The critical path includes activities that can be done in parallel with some risk of rework.
What should you try FIRST?
A. Crash the schedule by adding overtime and contractors.
B. Fast-track by running the parallelizable critical path activities concurrently to recover time without additional cost.
C. Request a schedule extension from the sponsor.
D. Reduce scope to meet the deadline.
Question 3
Your team estimates a task using three-point estimating: Optimistic = 10 days, Most Likely = 15 days, Pessimistic = 26 days.
What is the PERT expected duration?
A. 15 days
B. 16 days
C. 17 days
D. 18 days
Question 4
Your agile team has completed 5 sprints with velocities of: 18, 22, 20, 21, 19 story points. The remaining backlog has 120 story points.
How many sprints are needed to complete the backlog?
A. 5 sprints
B. 6 sprints
C. 7 sprints
D. Cannot be determined without more data
Question 5
A critical path activity has a mandatory Finish-to-Start dependency with its successor. The successor must begin immediately after the predecessor finishes. The PM asks you to start the successor 2 days before the predecessor finishes to save time.
Is this possible?
A. Yes — add a 2-day lead to the FS relationship.
B. No — mandatory dependencies cannot be modified. The activities cannot overlap because the dependency is hard logic.
C. Yes — change to a Start-to-Start relationship.
D. Yes — fast-track by running them in parallel.
Question 6
Your project has SPI = 0.85 at month 4 of a 12-month project. The sponsor asks: "Will we finish on time?"
What is your BEST response?
A. "No — SPI below 1.0 means we will definitely be late."
B. "Currently, we've completed 85% of the work we planned by this point. If this trend continues, we'll likely be late. I recommend analyzing the root causes, developing recovery options, and presenting them to you for a decision."
C. "Yes — we still have 8 months to recover."
D. "I need to calculate EAC before answering."
Question 7
Your construction project must coordinate with a road widening project managed by a different organization. Your project needs the widened road completed before heavy equipment can be delivered to your site.
What type of dependency is this, and what should you do?
A. Internal mandatory — add buffer and monitor.
B. External dependency — outside your control. Add it to the risk register, monitor the other project's progress, establish communication with their PM, and develop contingency plans.
C. Discretionary — you can reroute equipment via another road.
D. Internal discretionary — coordinate with the other team.
Question 8
Your team of 3 developers has been crashing the schedule by adding 2 more developers for 4 weeks. After 2 weeks, velocity has actually DECREASED. The new developers need significant onboarding.
What phenomenon explains this?
A. The new developers are underperforming — replace them.
B. Brooks's Law — adding people to a late project makes it later. New members need onboarding and create communication overhead. Short-term productivity loss is expected before any gain.
C. The team needs better tools to handle the larger size.
D. The original developers are slowing down due to frustration.
Question 9
Your project uses a hybrid approach: predictive for infrastructure and adaptive for software. The infrastructure schedule shows the data center ready by March 15. The software team plans their Sprint 8 deployment for March 1, requiring the data center.
What is the schedule risk, and how should you address it?
A. No risk — software can deploy to a temporary environment.
B. The software deployment depends on infrastructure completion (external dependency within the project). Add a 2-week buffer, monitor infrastructure progress, and have the software team prepare a fallback deployment plan.
C. Ask the infrastructure team to accelerate by 2 weeks.
D. Delay the software sprint to align with infrastructure.
Question 10
During sprint planning, the team estimates a user story at 8 story points. The PM says: "That seems high. Similar stories were 5 points in previous projects. Make it 5."
Is the PM's action appropriate?
A. Yes — the PM should use historical data to calibrate estimates.
B. No — in agile, the team doing the work provides the estimates. The PM can share historical data as input but should NOT override the team's estimate. Historical context is different from current context.
C. Yes — PMs are responsible for schedule accuracy.
D. The PM should escalate to the PO for a final decision.
11. Đáp án
Question 1:
Answer: B — Critical path = longest path(s) with zero float. Both A-D-E and A-H-I are 20 days with zero float. Having 2 critical paths increases risk — delay on EITHER path delays the project. PM should monitor both closely.
Question 2:
Answer: B — Fast-tracking first because it doesn't increase cost. The activities CAN be parallelized (discretionary dependency). If fast-tracking isn't sufficient, THEN consider crashing. Scope reduction (D) and extension (C) change project parameters — try compression first.
Question 3:
Answer: B — PERT = (O + 4ML + P) / 6 = (10 + 4×15 + 26) / 6 = (10 + 60 + 26) / 6 = 96/6 = 16 days. Standard deviation = (P-O)/6 = (26-10)/6 = 2.67 days.
Question 4:
Answer: B — Average velocity = (18+22+20+21+19)/5 = 100/5 = 20 points/sprint. Remaining = 120 points. 120/20 = 6 sprints. Velocity-based forecasting is the primary schedule tool in agile.
Question 5:
Answer: B — PMBOK 8: "Mandatory dependencies involve a relationship that is inherently in the nature of the work being done" — they CANNOT be changed. Only discretionary dependencies can be modified for fast-tracking. Attempting to overlap mandatory dependencies creates unacceptable risk.
Question 6:
Answer: B — SPI = 0.85 means 85% of planned work is done — behind schedule. But PM should analyze WHY (root cause), develop options (fast-track, crash, scope trade-offs), and present transparently. Simply saying "no" (A) doesn't help. Assuming recovery (C) ignores the trend. EAC (D) is for cost, not schedule.
Question 7:
Answer: B — External dependency: another organization's project. PM cannot control it but must manage it: risk register, communication, contingency. Rerouting (C) may be a contingency but the dependency itself is external and real.
Question 8:
Answer: B — Brooks's Law (from The Mythical Man-Month). Communication channels increase with n(n-1)/2 — from 3 channels (3 people) to 10 channels (5 people). New members need onboarding from existing team, reducing everyone's productivity temporarily. Crashing has diminishing returns.
Question 9:
Answer: B — This is an inter-stream dependency in a hybrid project. Software Sprint 8 (March 1) depends on infrastructure (March 15) — a 2-week gap. PM should: recognize the dependency, buffer appropriately, monitor progress, and plan contingency. Simply delaying (D) wastes software team capacity.
Question 10:
Answer: B — PMBOK 8 emphasizes team empowerment. In agile, the development team estimates because they understand current context (technical debt, team composition, complexity). The PM can share benchmarks as DATA but not override the estimate. Different sprints have different contexts — historical data is a guide, not a mandate.
12. Tổng kết
Schedule management kết nối mọi thứ: scope quyết định WHAT, schedule quyết định WHEN, resources quyết định WHO — và cả ba phải synchronized.
Ba takeaways:
1. Critical Path = heartbeat of schedule — Biết critical path là biết dự án sẽ kết thúc khi nào. Mọi delay trên CP = delay project. Mọi effort compression phải target CP activities. PM không biết critical path = PM mù về schedule.
2. Estimate collaboratively, track relentlessly — Team estimates (not PM dictates). Historical data informs (not replaces). Velocity stabilizes after 3-5 sprints. SV/SPI cho biết bạn đang ở đâu. Variance analysis cho biết bạn cần làm gì. Đo liên tục, không đợi đến milestone review.
3. Compression có giá — chọn đúng kỹ thuật — Fast-tracking = free nhưng risky (rework). Crashing = effective nhưng costly (more resources). Resource Leveling = fair nhưng có thể kéo dài schedule. Resource Smoothing = safe nhưng limited (chỉ dùng float). Mỗi kỹ thuật có trade-off — PM phải chọn đúng cho đúng tình huống.
PMBOK® 8, Section 2.3.1: "The detailed project schedule should be flexible throughout the project to adjust for the knowledge gained, increased understanding of the risks and external influences, and value-added activities. Revising and maintaining the project schedule to sustain a realistic schedule should continue throughout the project."
Câu Hỏi Thường Gặp (FAQ)
Hybrid project manage schedule như thế nào khi vừa có phases predictive vừa có sprints agile?
Approach phổ biến: dùng Gantt chart ở level cao (milestones và phases), còn bên trong mỗi phase agile dùng sprint planning và burndown charts. Schedule baseline áp dụng cho milestone dates cứng; còn sprint scope linh hoạt. Communication key: stakeholder nào cần Gantt, team agile cần backlog/burndown.
Schedule Performance Index (SPI) và burndown chart dùng cùng nhau như thế nào?
Trong hybrid: SPI từ EVM đo overall schedule health theo predictive approach. Burndown chart đo sprint-level delivery progress. Nếu SPI < 1 nhưng burndown cho thấy team đang đúng track, có thể team đang re-prioritize đúng backlog — cần phân tích deeper. Không nên dùng SPI đơn lẻ cho agile teams.
Agile Release Planning khác Sprint Planning như thế nào?
Release Planning: xác định features nào sẽ có trong release, estimate velocity, set release date/content — thường lên kế hoạch cho 3-6 sprints. Sprint Planning: chi tiết cho một sprint cụ thể — team commit stories, break down tasks, estimate hours. Release = strategy; Sprint = tactics. Cả hai đều cần trong agile.
Bạn đã nắm vững quản lý tiến độ dự án — giờ là lúc luyện tập với câu hỏi thi thật.
Bài tiếp theo: Đánh Giá Tình Trạng Dự Án: Metrics & Reporting theo PMBOK 8
Nguồn tham khảo chính thức:
Bạn đã sẵn sàng luyện tập chưa?
Thử CertFlow miễn phí — 10 câu hỏi, không cần đăng ký.
Bắt Đầu Miễn Phí


