PMP Schedule Management: Critical Path, Float, Baselines and Agile Forecasting

A project schedule should take the form that matches how the work will be delivered: a logic-linked network with a critical path for predictive work, a release and iteration cadence (or a continuous flow) for adaptive work, and fixed milestones with adaptive cadence inside them for hybrid work. Choosing the form is the first schedule decision, because it decides what can be estimated, what can be baselined and how variance will be seen.

The PMP Examination Content Outline lists eight enablers for this task, and this lesson follows them: prepare a schedule based on the selected development approach; coordinate with other projects and operations; estimate project tasks (milestones, dependencies, story points); utilize benchmarks and historical data; create a project schedule; baseline it; execute a schedule management plan; and analyze schedule variation.

Two principles sit behind the choice. First, detail follows certainty: forcing story-level dates on scope that will change produces a schedule that is wrong within weeks, while leaving a stable, interdependent build without network logic hides what drives the finish date. Second, constraints still bind: an adaptive stream inside a contract with payment milestones still has to meet those milestones, so the milestones stay in the plan and the iterations are planned within them.

Timeboxes and cadence

In iteration-based delivery the iteration length is fixed. When an iteration ends with items that do not meet the definition of done, the iteration still ends on time; unfinished items are not shown as done or partly done, and they return to the product backlog so the product owner can re-order them against everything else. The principle is that the timebox protects the cadence and the product owner owns the order of work: the cadence is what makes velocity, release forecasts and stakeholder reviews predictable, and every unfinished item competes again for its place in the backlog rather than keeping it by default.

When iterations stop fitting

Reserving a share of each iteration's capacity for interruptions works when interruptions are occasional and roughly predictable. When unplanned work makes up most of the team's load and arrives without warning, any reserve will be guessed wrong and plans break within days; a flow-based system (continuous pull, WIP limits, an expedite class of service) plans continuously and still gives stakeholders predictability through stable throughput. The general test is whether the cause of the broken plans is the length of the planning horizon or the unpredictability of the work itself; changing the horizon does not fix the second.

A dependency is a logical relationship that says how one activity's start or finish constrains another's, and PMI recognises four types: finish-to-start (FS), start-to-start (SS), finish-to-finish (FF) and start-to-finish (SF). Leads and lags then adjust the timing within a relationship.

Pick the relationship by asking which end of each activity is actually constrained. Defaulting to finish-to-start when only the completion depends on the predecessor needlessly delays the successor's start and lengthens the schedule.

Leads and lags

A pure waiting period with no work (curing, drying, a mandatory notice period) is a lag, not an activity. When the wait needs effort or ownership (a review, an inspection), model it as an activity instead.

Two relationships on one pair

An activity can be linked to the same predecessor by two relationships at once, typically SS plus FF, and the successor must satisfy both; the later constraint wins. Example: excavation starts at the beginning of day 1 and takes 10 days; lining takes 5 days with SS + 3 and FF + 4. SS + 3 allows lining to start on day 4 and finish at the end of day 8, but FF + 4 says lining cannot finish before the end of day 14, so lining finishes at the end of day 14 (starting on day 10).

Types of dependency

• Mandatory (hard logic): required by the nature of the work, a contract or a law; you cannot pour a roof before the walls, or start work before a required inspection.
• Discretionary (preferred or soft logic): chosen from best practice or team preference; these are the ones that can be changed or overlapped when time matters.
• External: involve something outside the project (a supplier delivery, another project's output, a regulator).
• Internal: between project activities the team controls.

A milestone is a significant point or event in the schedule with zero duration; it marks that something has happened (a design approved, a test passed, a payment due), while the activities before it carry the time and effort. Keeping events and work separate is what lets the schedule show both when something happens and how long it takes to get there.

• Model the work and the event separately. If an approval needs a review period, schedule the review as an activity with a duration, then a zero-duration milestone at its end. A "milestone" with a duration is really an activity; a bare milestone with nothing before it hides the time the review consumes.
• Milestones are binary. A milestone is achieved or not achieved; it has no percent complete. A report of a milestone as "90% complete" is really describing progress on the activity that leads to it. This matters most when a contract pays on milestone achievement: recording partial achievement would release payment before the event the contract pays for.
• Milestone charts summarise for governance. A milestone chart (or milestone schedule) shows target dates of significant deliverables, approvals and decisions without the underlying activities. It suits boards, steering committees and contracts. Bar charts and network diagrams expose activity detail; burnup charts show scope progress rather than due dates.

Milestones in hybrid delivery

In hybrid projects, milestones are usually where predictive and adaptive streams meet. When a predictive milestone that some backlog items depend on slips, the first response is to work with the product owner to re-order the backlog, bringing forward valuable work that does not need the late item. That keeps the team productive and shows whether the later release milestone is still reachable. A change request to move the release, or escalation, follows only if that analysis shows the release milestone itself is threatened.

Story points are a relative measure of the size of backlog items, combining effort, complexity and uncertainty, on a scale that each team builds from its own reference items. They are deliberately not hours, days or business value: value is a separate dimension the product owner uses for ordering, and converting points into hours throws away the reason for relative estimating.

What velocity can and cannot do

• Velocity is team-specific. Because each team sizes against its own reference stories, one team's 50 points per iteration and another's 20 are in different units. Comparing velocities, or their trends, across teams says nothing about productivity or capacity. Compare outcomes delivered instead.
• Velocity is a forecasting tool, not a target. When velocity is turned into a performance goal, the easiest way to raise it is to give the same work bigger numbers. The sign is velocity rising while the number and size of accepted items stay the same. Estimate inflation makes velocity useless for forecasting until the target is removed and the scale settles again.

Estimating techniques such as planning poker, affinity estimating and three-point (PERT) estimates, and adjusting velocity for capacity changes, are covered in the lessons on integrated planning and on resources; this task is about using the estimates to build and run a schedule.

Historical data and benchmarks

Historical data and benchmarks are evidence used to build estimates and to challenge them, and the more specific the evidence, the more weight it deserves:

Three habits follow. When the team's estimate and the history differ widely, review the estimate with the team against the records, because a large gap usually means a missing work element (the records often say which); the team still owns the estimate, and a gap caused by missing work is a scope question to resolve, not uncertainty to be covered by reserve. When reusing an earlier project's actuals for a larger job, adjust for the differences rather than copying the number or scaling it linearly, since reuse and learning rarely scale in proportion. And treat benchmarks as a check on an adjusted internal figure: they inform the estimate and the risk discussion, but they are not a source of contingency in their own right.

The critical path is the longest path through the schedule network, and its length is the shortest possible project duration; activities on it have zero total float (in a schedule with no imposed date constraints), so any delay to them delays the finish. The critical path method (CPM) finds it with a forward pass (early start and finish) and a backward pass (late start and finish).

Total float and free float

The effect of a delay follows from comparing it with both floats. A delay within free float affects nothing else. A delay beyond free float but within total float pushes successors later by the excess, but the finish date holds. A delay beyond total float moves the project finish by the excess. Example: an activity with 6 days of total float and 1 day of free float slips 3 days; its successor starts 2 days late, and the finish date is unchanged.

A worked network

Activities: P (2 days) starts the project; Q (8 days) and R (4 days) follow P; S (3 days) follows R; T (2 days) follows Q and S and ends the project. Path P-Q-T = 12 days; path P-R-S-T = 11 days. The critical path is P-Q-T, the project takes 12 days, and R and S each have 1 day of total float. The critical path is the path with the longest total, which is not necessarily the path containing the single longest activity.

Near-critical paths

A near-critical path has little float. It matters for two reasons. In monitoring, a near-critical path that has used up its float behaves as critical: its next slip moves the finish date. In compression, shortening the critical path below a near-critical path's length makes that path critical, so the project gains only the difference. If path 1 takes 40 days and path 2 takes 37, crashing path 1 by 6 days shortens the project by only 3 days; path 2 becomes critical and the other 3 crashed days were wasted. After every compression step, recalculate which path is critical.

Multiple paths can be critical at the same time, which raises schedule risk because a slip on any of them moves the finish. Schedule risk analysis such as Monte Carlo simulation turns duration ranges into a probability distribution of finish dates, so a date can be stated with a confidence level rather than as a single point.

Schedule compression shortens the project duration without reducing scope, using two techniques: crashing adds resources to shorten activities at extra cost, and fast-tracking overlaps activities that were planned in sequence at extra risk. Both work only on the critical path, because shortening an activity that has float does not move the finish date.

Choosing what to crash

To crash at least cost, work only with critical activities, take the cheapest cost per day first, respect each activity's crash limit, and move to the next cheapest when the limit is reached; then recheck whether another path has become critical. Example: the project must gain 3 days on critical path K-L-M, with crash options K up to 1 day at $700 per day, L up to 3 days at $1,100 per day and M up to 2 days at $950 per day, and a non-critical activity N at $300 per day. N is cheapest but has float, so it buys nothing. Take K (1 day, $700), then M (2 days, $1,900): 3 days for $2,600. Recheck paths afterward.

Compression is a response to schedule pressure; when an approved change rather than a performance problem is the cause, the baseline route below applies. Resource leveling and resource optimization, which can lengthen a schedule to fit resource limits, are taught in the resources lesson.

A project schedule has to fit around the organization's other projects and its day-to-day operations, so coordination means finding the shared resources, calendars and dependencies early and agreeing dates with their owners before the baseline is set. A conflict found during planning is cheap to fix; the same conflict found at go-live is not.

• Operational calendars. Operations teams run peak periods (month-end and quarter-end processing, seasonal trading) and change freezes or blackout periods when no changes are allowed. Put these on the calendar the schedule uses for deployments and cutovers, and agree windows with operations outside them. The principle is that the project fits around operations rather than the reverse: contingency measures reduce the impact of a clash but do not remove it, and the operational calendar is owned by operations, so the project agrees a window with them.
• Dependencies on other teams and projects. Record each one as an external dependency with an owner and a hand-off date, and leave buffer between the hand-off and anything time-critical that depends on it. A dependency is managed through coordination with its owner; working around it in isolation hides the coordination problem rather than solving it.
• Agile teams sharing a release. When one team's feature needs work that sits low in another team's backlog, bring the product owners together to sequence it against the release goal. Each product owner orders their own backlog; directing another team's priorities bypasses that role. Cross-team planning events and dependency boards make these conflicts visible early.

Collaborate, then escalate

PMI's mindset is to work the problem with the people involved before escalating. When that conversation has already happened and the conflict comes from priorities set elsewhere (another sponsor ranked the work lower), the project manager cannot resolve it peer to peer. If the dependency drives the critical path, raise it promptly with the person who can set priorities across both projects, usually the program manager or portfolio governance. Escalation here is not a failure of collaboration but the right route for a priority decision that sits above both projects, and each team's resources stay under that team's management.

The schedule baseline is the approved version of the schedule model, with baseline start and finish dates, that becomes part of the project management plan and is the reference for measuring schedule variance. The working schedule is updated with actual dates and new forecasts every reporting cycle; the baseline stays fixed so there is something to compare them with.

When the baseline may change

Two delays in the same month can therefore be treated differently: the one that went through change control changes the baseline, and the one that did not remains variance. Rebaselining to match forecasts "with a note" is still hiding variance.

Baselining in hybrid delivery

Baseline at the level where the plan is stable. For adaptive streams whose backlog changes every iteration, that is the release milestones and the iteration cadence, not individual stories; story-level baselines either break constantly or are re-baselined so often that they measure nothing. Whatever level is chosen, every stream needs some baselined reference, because governance reporting covers the whole project, adaptive work included.

The schedule management plan

The schedule management plan is the component of the project management plan that sets the rules for developing, monitoring and controlling the schedule. It typically defines:

• the scheduling method and tool, and the schedule model's level of detail;
• units of measure (hours, days, story points) and the precision of estimates;
• how often the schedule is updated and progress recorded (the update cadence);
• control thresholds: how much variance is tolerated before action is required;
• rules of performance measurement, such as how percent complete is measured and earned value rules;
• reporting formats and the release and iteration length for adaptive work.

Fixed-formula rules make progress reporting objective for short activities: under 0/100 nothing is credited until the activity finishes; under 50/50 half is credited at start and half at finish; under 20/80 20% at start and 80% at finish. If the plan says 0/100, a one-week activity reported as "80% done" is recorded as 0% until it finishes, which stops optimistic estimates overstating progress.

Executing the plan means applying it as written. Keep the agreed update cadence even when a team says it is on track (that is a claim, not evidence, and busy release weeks are when slippage appears), and make the update light enough that it costs little. Control depends on complete, regular data, so the plan's rules apply to all of the work every cycle; if the rules themselves need to change, that change goes through the agreed change route.

Schedule variation analysis compares actual progress with the schedule baseline to find how far the project is ahead or behind, why, and what it means for the finish date. Earned value gives two schedule measures: schedule variance (SV = EV − PV) and the schedule performance index (SPI = EV / PV). An SPI below 1.0 means less work has been done than planned; above 1.0, more. Example: PV $250,000 and EV $225,000 give SV −$25,000 and SPI 0.90. Do not mix in actual cost: EV / AC is the cost performance index (CPI), which says nothing about schedule. The cost side of earned value is taught in the finance lesson.

Why SPI alone is not enough

• SPI aggregates all work, but the finish date is set by the critical path. A project can show SPI above 1.0 because non-critical work started early while critical activities, which have no float, run late. The finish date is then at risk despite the "good" index. Check critical-path and near-critical-path progress directly, and direct any recovery effort at the activities that actually drive the finish date.
• SPI drifts back to 1.0 at the end. SPI compares value, not dates, and planned value stops growing at the planned finish. A project months past its planned finish will have earned nearly all its value, so SPI approaches 1.0 even though it is badly late. Use date-based measures instead: forecast finish against baseline finish, or earned schedule, which converts EV into the time at which that value was planned, giving a time-based SPI(t).
• Cost and schedule are separate. A falling CPI with milestones on time is a cost problem, not a schedule threat.

Reading status findings

To judge whether a finding threatens the finish date, compare each delay with the float available. A critical-path activity behind with no recovery is a direct threat. A near-critical path that has used all its float, with its next activity late, is now effectively critical and also a threat. A late activity still within its float, early finishes and cost-only signals are not schedule threats. When variance does exceed the control thresholds in the schedule management plan, analyze the cause, forecast the finish, and propose corrective action (compression, resequencing) or a change request through the agreed route.

Adaptive schedules are tracked by comparing delivered work with remaining scope over time, using burnup and burndown charts for iteration-based teams and throughput and cycle time for flow-based teams, and forecasts are given as ranges because delivery rates vary.

Forecasting as a range

A forecast built from one number (the best iteration, or the average) hides the variation in the team's history. Use the observed range: for a flow team, remaining items divided by the low and high weekly throughput gives a date range; Monte Carlo simulation over the throughput history gives dates with confidence levels. Teams that do not estimate in points do not need to start just to forecast.

Fixed date, variable scope

When the date cannot move (an event, a regulatory deadline), the question becomes "how much will be done", not "when". Multiply the number of iterations by the low and high ends of the velocity range: commit to the scope at the slow end, ordered by value, and show the scope up to the fast end as possible. Example: 5 iterations at 18 to 26 points (average 22) supports a commitment of 90 points with up to 130 shown as possible. Committing at the average fails about half the time, and committing at the best case almost always fails.