CertFlow PRO
PMBOK8-Process · Bài 8/10

Quản Lý Tiến Độ Dự Án: CPM & Agile Planning theo PMBOK 8

··Cập nhật ·17 phút đọc
Chia sẻ:
Schedule management in PMBOK 8

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. 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. 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. 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.

Làm thử đề PMP miễn phí →

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í
PMPPMBOK 8Plan and Manage ScheduleProcess DomainCritical Path MethodSchedule CompressionAgile PlanningSchedule Baseline