Plan and Manage Schedule
Lập kế hoạch và Quản lý Tiến độ
Schedule management là kỹ năng cốt lõi — cân bằng giữa Critical Path (predictive) và Velocity/Burndown (agile). PM không thể để schedule slip mà không có action.
📖 Schedule Development — Core Concepts
🇺🇸 English
Schedule development process: Define Activities → Sequence Activities → Estimate Durations → Develop Schedule → Control Schedule
Critical Path Method (CPM): The longest sequence of dependent activities determining the earliest project completion. Any delay on the critical path = project delay.
- Float/Slack: Time an activity can be delayed without delaying the project. Critical path activities have zero float.
- Total Float: Delay without affecting project end date
- Free Float: Delay without affecting successor activity
- Early Start (ES) / Early Finish (EF): Forward pass
- Late Start (LS) / Late Finish (LF): Backward pass
Schedule compression techniques:
- Fast-tracking: Overlap activities originally planned sequentially. Increases risk.
- Crashing: Add resources to critical path activities to shorten duration. Increases cost.
Reference: PMI — Schedule Management
🇻🇳 Tiếng Việt
Critical Path Method (CPM): Chuỗi dài nhất các hoạt động phụ thuộc nhau, xác định ngày hoàn thành sớm nhất của dự án. Bất kỳ trì hoãn nào trên critical path = dự án bị trì hoãn.
- Float/Slack: Thời gian hoạt động có thể trì hoãn mà không ảnh hưởng đến dự án. Critical path activities có float = 0.
Kỹ thuật nén lịch:
- Fast-tracking: Chạy song song các hoạt động vốn được lên kế hoạch tuần tự. Tăng rủi ro.
- Crashing: Thêm nguồn lực vào critical path để rút ngắn thời gian. Tăng chi phí.
Critical Path — Float Calculation
── FORWARD PASS (ES/EF) ──────────────────────────────────
ES = Latest EF of all predecessors (or 0 for first activity)
EF = ES + Duration - 1
── BACKWARD PASS (LS/LF) ────────────────────────────────
LF = Earliest LS of all successors (or project end for last activity)
LS = LF - Duration + 1
── FLOAT ─────────────────────────────────────────────────
Float = LS - ES (or LF - EF)
Float = 0 → Critical Path activity (no slack allowed)
── EXAMPLE PROJECT ──────────────────────────────────────
A(3d) → B(5d) → D(4d)
A(3d) → C(2d) → D(4d)
Path A→B→D: 3+5+4 = 12 days ← Critical Path
Path A→C→D: 3+2+4 = 9 days
Float on C: 12 - 9 = 3 days
── COMPRESSION DECISION ──────────────────────────────────
Fast-tracking: Overlap B and C (design + build simultaneously) → Risk ↑, Cost same
Crashing: Add developer to B → Duration 5d → 3d, Cost ↑ $2,000/day
Exam Tips — Critical Path & Compression
- Critical path = longest path (not shortest). Determines project duration.
- Activities ON critical path have zero float — any delay = project delay
- Fast-tracking: increases risk. Crashing: increases cost.
- When asked about schedule compression, exam prefers fast-tracking first (no extra cost) but with understanding of added risk
- Float = LS - ES = LF - EF (both give same result)
- There can be multiple critical paths in a network diagram
🔄 Agile Schedule Management
🇺🇸 English
In Agile, schedule is managed through velocity and iteration planning rather than Gantt charts and CPM.
- Velocity: Average story points completed per sprint. Used to forecast completion date.
- Burndown chart: Shows remaining work vs time. Ideal line vs actual.
- Burnup chart: Shows work completed vs total scope. Better for scope change visibility.
- Release planning: How many sprints needed? Remaining backlog / velocity = sprints remaining.
Sprint Goal: The commitment for the sprint — what the team will deliver, not just what they'll do.
🇻🇳 Tiếng Việt
Trong Agile, lịch trình được quản lý thông qua velocity và iteration planning.
- Velocity: Story points trung bình hoàn thành mỗi sprint. Dùng để dự báo ngày hoàn thành.
- Burndown chart: Hiển thị công việc còn lại theo thời gian.
- Release planning: Backlog còn lại / velocity = số sprint cần thiết.
Agile Release Forecast
── VELOCITY-BASED FORECASTING ────────────────────────────
Remaining Backlog = 180 story points
Team Velocity = 25 SP/sprint (average last 3 sprints)
Sprints Remaining = 180 / 25 = 7.2 → 8 sprints
Sprint Duration = 2 weeks
Release Date = Today + (8 × 2 weeks) = 16 weeks from now
── WHEN BEHIND SCHEDULE ─────────────────────────────────
Options (in order of preference):
1. Reduce scope (cut low-value backlog items)
2. Add team member (increases velocity in 2-3 sprints)
3. Increase sprint length (exceptional, use sparingly)
4. Negotiate timeline with stakeholders
── BURNDOWN HEALTH CHECK ─────────────────────────────────
Ideal burndown: straight line from total → 0
Flat line = team not completing work (blocked?)
Line going UP = scope is being added (scope creep!)
🔧 WBS — Work Breakdown Structure
🇺🇸 English
WBS decomposes the total scope of work into manageable components. The Work Package is the lowest level of WBS — where estimates, schedules, and cost accounts are assigned.
100% Rule: WBS captures 100% of work defined in project scope. Nothing more, nothing less.
Rolling Wave Planning: Near-term work is detailed; future work is high-level. Progressive elaboration as the project proceeds.
🇻🇳 Tiếng Việt
WBS phân rã tổng phạm vi công việc thành các thành phần quản lý được. Work Package là cấp thấp nhất của WBS — nơi gán ước tính, lịch trình và chi phí.
Quy tắc 100%: WBS nắm bắt 100% công việc được xác định trong phạm vi dự án.
Rolling Wave Planning: Công việc gần đây được chi tiết hóa; công việc tương lai ở mức cao. Elaboration dần dần khi dự án tiến triển.
| WBS Level | Description | Example (Project Alpha) |
|---|---|---|
| Level 1 | Project | 1.0 Project Alpha |
| Level 2 | Deliverable/Phase | 1.1 Backend API | 1.2 Frontend | 1.3 Integration | 1.4 QA |
| Level 3 | Work Package | 1.1.1 Auth Service | 1.1.2 Credit Engine | 1.3.1 Partner API Integration |
| Level 4 | Activity (for detailed scheduling) | 1.3.1.1 Design API contract | 1.3.1.2 Build mock server | 1.3.1.3 Integration testing |
💼 Thực chiến / Scenario
FinTech Company X — Schedule Recovery Plan
Situation: Sprint 6 review của Project Alpha. SPI = 0.83 (từ EVM calculation). Release date là 8 tuần nữa. Remaining backlog = 80 SP. Team velocity = 22 SP/sprint (dipping from normal 25 due to production incidents). Sponsor yêu cầu release date không thể slip.
Analysis: At 22 SP/sprint × 4 sprints = 88 SP available. But 80 SP remaining + buffer = tight. Risk: another production incident would break the schedule.
Options evaluated:
- Fast-track: Run QA testing in parallel with development (currently sequential). Risk: bugs found late, rework cost. Decision: Accept for low-risk modules only.
- Crash: Hire 1 contractor developer. Cost: +$8,000. Velocity increase: +5 SP/sprint in sprint 7 onward. Decision: Approved by sponsor given release criticality.
- Scope reduction: Move Admin reporting dashboard (15 SP, low business value) to Phase 2. Decision: Accepted. Now remaining = 65 SP, comfortably achievable.
PMP lesson: Schedule recovery is a combination of compression, scope management, and stakeholder communication — không phải chỉ "work harder". Communicate options and tradeoffs clearly; let sponsor decide.
✏️ Practice Questions
Question 1
A project has three paths: Path A = 15 days, Path B = 12 days, Path C = 15 days. A new dependency is added making Path B now 16 days. What happened?
- A. The project duration decreased because more paths are near-critical
- B. Path B is now the critical path and the project duration increased to 16 days
- C. Paths A and C remain critical; Path B has positive float
- D. The project still completes in 15 days as Paths A and C are unchanged
✅ Answer: B — Path B at 16 days is now the longest path, making it the new critical path. The project duration is now 16 days — it increased. Paths A and C now have float (1 day). This demonstrates why the critical path must be monitored throughout the project — it can shift as conditions change.
Question 2
The project is 3 weeks behind schedule. The sponsor insists the original end date must be maintained. The PM's BEST option to compress the schedule without significant cost increase is:
- A. Crash the schedule by hiring additional contractors
- B. Fast-track activities on the critical path by overlapping them
- C. Add overtime to the current team
- D. Remove scope items to reduce the workload
✅ Answer: B — Fast-tracking overlaps activities originally planned sequentially, recovering schedule without adding cost. Crashing (A) recovers schedule but adds cost. Adding overtime (C) also increases cost and risks burnout. Removing scope (D) may be valid but changes project deliverables — fast-tracking is the compression technique that addresses time without direct cost impact (though it increases risk of rework).
Question 3
An agile project has completed 6 sprints. Velocity data: Sprint 1=18, Sprint 2=22, Sprint 3=24, Sprint 4=21, Sprint 5=23, Sprint 6=20. Remaining backlog = 96 story points. How many sprints are needed to complete?
- A. 4 sprints
- B. 5 sprints
- C. 6 sprints
- D. 3 sprints
✅ Answer: B — Use the last 3 sprints for the most accurate forecast (recent data reflects current team performance): (21 + 23 + 20) / 3 = 21.3 SP/sprint. Remaining: 96 / 21.3 ≈ 4.5 sprints → round up to 5 sprints. Using the all-time average (21.3 also here by coincidence) gives the same answer, but the principle is: always prefer recent velocity over historical average when performance has stabilised or changed.
🤖 AI Tools for PMs
How AI Augments This Process
AI helps PMs analyze schedule risks, generate delay impact assessments, interpret velocity trends, draft schedule recovery plans, and communicate timeline changes to stakeholders.
Sample Claude Prompts
Schedule delay impact analysis
My project is experiencing a schedule delay. Help me analyze the impact and options.
Project: [name] | Current milestone: [what we're working toward]
Original planned completion: [date]
Current forecast: [revised date]
Delay: [X days/weeks — how long]
Cause of delay: [what happened]
Remaining work: [% complete]
Critical path activities still remaining: [list]
Budget status: [on track / over / under]
Analyze:
1. Is this delay on the critical path? (will it delay the final deadline?)
2. What is the total float consumed?
3. What compression options are available? (Fast-track: which activities can run in parallel? Crash: where would additional resources reduce duration?)
4. What is the cost of crashing? What is the cost of accepting the delay?
5. Recommendation: which option, and why?
6. Draft the schedule change communication for the sponsor.
Agile velocity trend analysis
I want to analyze my team's velocity trend. Here's the data:
Sprint 1: Planned [SP] / Actual [SP]
Sprint 2: Planned [SP] / Actual [SP]
Sprint 3: Planned [SP] / Actual [SP]
Sprint 4: Planned [SP] / Actual [SP]
Sprint 5: Planned [SP] / Actual [SP]
Context: [any events that affected velocity — new team member, refactoring sprint, incidents]
Analyze:
1. Average velocity and variability
2. Trend direction (improving / stable / declining)
3. Reliability rate (how often does the team hit their commitment?)
4. Forecast: at this velocity, when will the remaining [X story points] be complete?
5. If there's a velocity decline — diagnose the most likely root causes
6. Recommended sprint capacity for the next planning session
Schedule compression decision
My sponsor is pushing to deliver [milestone] 3 weeks earlier than planned. Help me evaluate the options.
Current plan end date: [date]
Target date requested: [date]
Compression needed: [X weeks]
Available activities to fast-track (run in parallel):
Activity A (currently after B): [description, duration, dependency reason]
Activity B: [description, duration]
[list more]
Crash options (add resources to shorten duration):
Activity C: Normal duration [X], crashed duration [Y], additional cost [$Z]
[list more]
Evaluate:
1. Which compression approach achieves the target with least risk?
2. Total additional cost for crashing options
3. Quality/risk implications of fast-tracking
4. My recommendation: what to tell the sponsor
5. What to ask for in return (trade-offs — scope or quality concessions)
Jira / Confluence Template
Confluence — Schedule Recovery Plan
── CONFLUENCE: SCHEDULE RECOVERY PLAN ───────────────────
Project: [Project Alpha] | Date: [YYYY-MM-DD] | Triggered by: [event]
Original end date: [YYYY-MM-DD]
Current forecast: [YYYY-MM-DD] — delay of [X] days
Target recovery to: [YYYY-MM-DD]
── DELAY ROOT CAUSE ──────────────────────────────────────
Primary cause: [What happened]
Contributing: [Secondary factors]
On critical path? Yes → affects final delivery | No → float available
── RECOVERY OPTIONS ──────────────────────────────────────
Option A — Fast-track:
Activities: [which activities to overlap]
Risk: [quality / dependency risk]
Recovery: [X days] | Additional cost: $[amount]
Option B — Crash:
Activities: [where to add resources]
Resource needed: [type, quantity]
Recovery: [X days] | Additional cost: $[amount]
Option C — Scope reduction:
Features to defer: [list]
Recovery: [X days] | Cost impact: $[savings]
── RECOMMENDATION ────────────────────────────────────────
Recommended: Option [A/B/C] — [1-sentence rationale] | CCB approval: [pending/approved]