PMI-SP — PMI Scheduling Professional Cheat Sheet

Last revised: September 28, 2026

Compact PMI-SP Cheat sheet for schedule development, network logic, CPM, float, resource optimization, schedule control, EVM metrics, risk, and exam decision points.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

Build and evaluate a credible schedule model.
Distinguish planning, baseline approval, status updating, forecasting, and change control.
Apply critical path, float, resource, risk, and performance concepts in scenario questions.
Avoid common exam traps such as “just update the baseline,” “add resources to everything,” or “treat percent complete as objective progress.”

Exam mindset: answer as a scheduling professional who protects schedule integrity, uses documented methods, communicates uncertainty clearly, and supports project decision-making with reliable schedule information.

PMI-SP Scheduling Mindset

Exam mindset	What it means in practice	Common trap
Schedule is a model, not a chart	Logic, calendars, resources, constraints, assumptions, and status data drive dates	Treating a Gantt chart as the schedule model
Analyze before acting	Calculate impact, identify drivers, then recommend options	Jumping straight to crashing, escalation, or baseline change
Baselines are controlled	Approved schedule baseline changes require change control	Rebaselining to hide variance
Progress data must be credible	Actual starts/finishes, remaining duration, and data date must be accurate	Reporting percent complete without validating remaining work
Float is a management signal	Total float, free float, and negative float guide prioritization	Assuming every delayed task delays the project
Logic should reflect work	Prefer valid predecessor/successor relationships over artificial constraints	Using hard constraints or lags to force dates
Communication is tailored	Different stakeholders need different schedule views	Sending the same detailed network report to everyone
Risk is integrated	Schedule risk affects reserves, forecasts, and response plans	Treating risk as separate from the schedule

Core Schedule Artifacts

Artifact	Primary use	High-yield exam clue	Watch for
Schedule management plan	Defines how the schedule is planned, developed, monitored, and controlled	“How should scheduling be performed?”	Do not confuse with the schedule itself
WBS / scope baseline	Defines deliverables and work packages that feed activity definition	“Need to identify schedule activities”	Activities should trace to scope
Activity list	Complete list of schedule activities	“What work must be scheduled?”	Work packages are decomposed into activities
Activity attributes	Details such as predecessors, successors, resources, constraints, leads/lags	“Need more detail than activity name”	Attributes mature over time
Milestone list	Significant events or decision points	“Contract date,” “phase gate,” “major deliverable acceptance”	Milestones usually have zero duration
Network diagram	Visual or logical representation of dependencies	“Need to analyze sequence/path”	Logic quality matters more than layout
Schedule model	Data-driven model used to calculate dates	“Update the model and recalculate”	The model includes logic, calendars, constraints, durations, resources
Project schedule	Output view of planned dates	“Communicate planned start/finish dates”	A schedule view is not always the whole model
Schedule baseline	Approved version used for comparison	“Measure variance against approved dates”	Changing it needs approved change control
Schedule data	Supporting details for the schedule	“Need assumptions, constraints, resource details, alternate schedules”	Often more detailed than the displayed schedule
Resource calendars	Resource availability and working periods	“Resource unavailable,” “shift calendar,” “holiday”	Calendar errors distort dates
Risk register	Identified risks and response plans	“Schedule uncertainty,” “delay risk,” “contingency”	Link risk responses to affected activities
Issue log	Current problems requiring action	“Delay has already occurred”	A risk may become an issue
Change log	Records approved/rejected changes	“Track baseline change decisions”	Not a substitute for impact analysis
Work performance data	Raw status data	“Actual start, actual finish, remaining duration”	Must be validated before reporting
Work performance information	Analyzed performance	“Variance, trend, forecast”	Analysis turns data into management insight
Schedule forecast	Predicted future schedule performance	“Will we meet the milestone?”	Forecasts should reflect current status and risk

Schedule Management Plan: Decisions to Define

Planning decision	Examples
Scheduling methodology	Critical path method, critical chain, agile cadence, rolling-wave planning
Scheduling tool and model rules	Naming standards, coding structures, calendars, logic rules
Level of detail	Activity duration ranges, control account alignment, planning package handling
Units of measure	Hours, days, story points, elapsed time
Accuracy and precision	Rounding, estimate confidence, reporting granularity
Control thresholds	Variance thresholds that trigger analysis or action
Update frequency	Weekly, biweekly, monthly, iteration-based, milestone-based
Progress measurement	Percent complete, physical progress, earned value, milestone credit
Baseline control	Who can approve schedule baseline changes
Reporting formats	Executive dashboard, milestone chart, lookahead schedule, variance report
Reserve approach	Contingency for known risks, management reserve where applicable
Tailoring	Predictive, adaptive, hybrid, regulatory, contractual, or organizational needs

Schedule Development Flow

    flowchart LR
	A[Plan schedule management] --> B[Define activities]
	B --> C[Sequence activities]
	C --> D[Estimate resources and durations]
	D --> E[Develop schedule model]
	E --> F[Analyze network, resources, and risk]
	F --> G[Approve schedule baseline]
	G --> H[Monitor and control schedule]
	H --> I[Update actuals and forecasts]
	I --> F
	H --> J[Change control when baseline impact occurs]
	J --> G

Activity Definition and Decomposition

Concept	Use	Exam distinction
Work package	Lowest WBS component for cost/scope management	Describes deliverable-oriented work
Activity	Scheduled unit of work	Used for duration, logic, resources, and progress
Planning package	Future work not yet decomposed in detail	Supports rolling-wave planning
Rolling-wave planning	Near-term work planned in detail; future work planned at higher level	Best when details emerge over time
Milestone	Significant event, often zero duration	Measures progress or decision point, not work effort
Activity attribute	Additional scheduling metadata	Enables analysis, filtering, reporting, and control

Decomposition Checks

Every activity should trace back to authorized scope.
Activities should be small enough to estimate, assign, track, and control.
Avoid extremely long activities unless they are planning packages or summary-level placeholders.
Do not include unauthorized scope just because it helps the schedule look complete.
Clarify acceptance, handoffs, and external dependencies early.

Dependency and Logic Reference

Relationship	Meaning	Typical example	Exam caution
Finish-to-Start	Successor starts after predecessor finishes	Testing starts after build finishes	Most common, but not always correct
Start-to-Start	Successor starts after predecessor starts	Editing starts after drafting starts	May need lag for realistic overlap
Finish-to-Finish	Successor finishes after predecessor finishes	Inspection finishes after installation finishes	Useful for coordinated completion
Start-to-Finish	Successor finishes after predecessor starts	Old system stops after new system starts	Rare; do not choose unless scenario clearly fits

Notes and examples

Dependency type	Meaning	Example	Management implication
Mandatory	Required by nature of work or contract	Foundation before walls	Hard to change without scope/technical impact
Discretionary	Preferred logic or best practice	Review before optional formatting	Candidate for resequencing or fast tracking
External	Outside project team control	Permit approval, vendor delivery	Needs monitoring, agreements, and risk responses
Internal	Within project/team control	Internal design handoff	Easier to negotiate and optimize

Leads, Lags, and Constraints

Item	Use	High-yield warning
Lead	Allows successor to start before predecessor completes	Can increase risk due to overlap
Lag	Waiting time between activities	Should represent real wait time, not hidden contingency
Constraint	Restricts start/finish date	Overuse can mask true network logic
Hard constraint	Strongly fixes a date	Can create negative float or unrealistic results
Soft constraint	Preferred target date	Less restrictive; better for planning guidance
Deadline	Target date used to calculate variance/float	Does not necessarily force the schedule date

Critical Path Method Essentials

Forward and Backward Pass

Use the exam’s stated calendar convention. If a question uses day 0 or day 1 counting, follow that convention consistently.

Forward pass:

\[ ES = \max(EF_{\text{predecessors}}), \quad EF = ES + D \]

Backward pass:

\[ LF = \min(LS_{\text{successors}}), \quad LS = LF - D \]

Total float:

\[ TF = LS - ES = LF - EF \]

Free float:

\[ FF = \min(ES_{\text{successors}}) - EF \]

Term	Meaning	Exam use
Early start	Earliest an activity can start based on predecessors	Forward pass
Early finish	Earliest an activity can finish	Forward pass
Late start	Latest an activity can start without delaying project finish or constraint	Backward pass
Late finish	Latest an activity can finish without delaying project finish or constraint	Backward pass
Total float	Time an activity can slip without delaying the project finish or constrained milestone	Prioritizes schedule risk
Free float	Time an activity can slip without delaying any immediate successor	Useful for team-level flexibility
Critical path	Longest path through the network; normally zero total float	Determines shortest project duration
Near-critical path	Path with low float close to critical	High risk; can become critical quickly
Negative float	Schedule is later than required date/constraint	Requires recovery analysis or expectation reset
Project float	Time project can slip without missing an externally imposed date	May belong to sponsor/customer, not activity owner
Driving path	Path controlling a specific milestone	Useful when milestone matters more than final finish
Longest path	Longest logical path through the project	Often used when constraints distort critical path
Critical chain	Resource-constrained critical path with buffers	Focuses on resource limits and buffer management

Duration Estimating Reference

Technique	Best when	Strength	Weakness / trap
Expert judgment	Experienced specialists are available	Fast and context-sensitive	Can be biased or undocumented
Analogous estimating	Similar past work exists	Quick early estimate	Less accurate if similarity is weak
Parametric estimating	Reliable rate or productivity factor exists	Scalable and data-based	Bad parameters produce bad estimates
Bottom-up estimating	Work is well decomposed	More detailed and defensible	Time-consuming
Three-point estimating	Uncertainty is meaningful	Captures optimistic, most likely, pessimistic	Inputs must be realistic
Data analysis	Historical records and lessons learned exist	Improves credibility	Poor data quality misleads
Reserve analysis	Risks and uncertainty need allowance	Makes uncertainty visible	Padding individual tasks hides risk

Notes and examples

Three-Point Formulas

PERT / beta expected duration:

\[ t_E = \frac{O + 4M + P}{6} \]

Triangular expected duration:

\[ t_E = \frac{O + M + P}{3} \]

PERT standard deviation:

\[ \sigma = \frac{P - O}{6} \]

PERT variance:

\[ \sigma^2 = \left(\frac{P - O}{6}\right)^2 \]

Symbol	Meaning
O	Optimistic duration
M	Most likely duration
P	Pessimistic duration
tE	Expected duration
sigma	Standard deviation

Estimating Traps

Do not treat padding as risk management.
Do not average estimates blindly when the scenario asks for PERT.
Do not ignore resource calendars when converting effort to duration.
Effort and duration are not the same.
A full-time resource may reduce duration; adding more resources may not, especially with coordination or technical limits.
If uncertainty is high, improve assumptions, use ranges, perform risk analysis, or plan progressively.

Duration, Effort, and Elapsed Time

Term	Meaning	Example trap
Effort or work	Labor amount required	“40 hours of effort”
Duration	Working time from start to finish based on resources/calendar	40 hours of effort may take 5 days with one person or less with more resources
Elapsed time	Clock time including nonworking periods	A curing period may take elapsed days regardless of labor
Productivity	Output per unit of effort or time	Adding people does not always increase productivity linearly

A basic relationship is:

\[ \text{Duration} = \frac{\text{Work}}{\text{Resource Units}} \]

This relationship is simplified. Real schedules must also account for calendars, learning curves, handoffs, availability, productivity, and constraints.

Estimating Methods

Method	Best use	Limitation
Analogous estimating	Early planning using similar past work	Less accurate if comparison is weak
Parametric estimating	Repetitive measurable work	Depends on reliable productivity rates
Three-point estimating	Uncertain work with optimistic, most likely, pessimistic values	Inputs may still be biased
Bottom-up estimating	Detailed planning from activity-level estimates	Time-consuming; requires scope detail
Expert judgment	Specialized or novel work	Should be documented and challenged when assumptions are weak

For three-point estimates using a beta/PERT-style weighted average:

\[ E = \frac{O + 4M + P}{6} \]

Where:

\(O\) = optimistic estimate
\(M\) = most likely estimate
\(P\) = pessimistic estimate
\(E\) = expected duration
\(\sigma\) = standard deviation estimate

Exam trap: three-point estimating is not a substitute for risk management. It helps represent uncertainty, but schedule risk still requires analysis, response planning, and monitoring.

Resource and Calendar Concepts

Concept	Meaning	Exam relevance
Effort	Labor required, such as person-hours	Used for estimating workload
Duration	Time from start to finish	Affected by calendars, availability, dependencies
Elapsed duration	Clock time regardless of working time	Useful for curing, waiting, shipping
Resource calendar	When a resource is available	Drives realistic start/finish dates
Project calendar	General working/nonworking periods	Default schedule basis
Activity calendar	Calendar specific to an activity	Needed for special shifts or constraints
Resource histogram	Resource use over time	Shows peaks and overloads
Resource breakdown structure	Hierarchical resource categories	Helps organize planning and reporting
Resource over-allocation	More work assigned than capacity	Requires leveling, smoothing, or negotiation

Notes and examples

Resource Planning

Resource planning connects activity estimates to real execution capacity.

Key concepts:

Resource availability affects duration and sequence.
Specialized resources can create bottlenecks.
Calendars affect working time and forecast dates.
Productivity assumptions must be realistic.
Shared resources across projects can create external schedule risk.

Leveling vs. Smoothing

Technique	What it does	Effect on finish date
Resource leveling	Adjusts activities based on resource limits	May change critical path and extend schedule
Resource smoothing	Adjusts activities within available float	Intended not to change the critical path or project finish, when feasible

Candidate trap: if resources are overallocated, the right first step is not automatically to demand more people. Analyze the constraint, priorities, float, critical path impact, and feasible optimization options.

Compression Techniques

Technique	Meaning	Best used when	Key risk
Crashing	Add resources or cost to shorten duration	Critical path work can be shortened with added resources	Higher cost, diminishing returns, coordination problems
Fast tracking	Perform work in parallel that was originally sequential	Logic is discretionary and overlap is feasible	Rework, quality issues, increased risk
Resequencing	Change logic where valid	Existing dependencies are discretionary or inefficient	May create handoff gaps
Scope tradeoff	Reduce or defer scope with approval	Business priorities allow it	Requires formal approval
Alternative method	Use different technical approach	Better delivery method exists	May introduce unknown risk

Decision rule: compression should usually focus on critical or near-critical paths. Shortening a noncritical activity may consume money without improving the finish date.

Resource Optimization Decision Table

Situation	Best technique	Why	Watch for
Resource demand exceeds availability	Resource leveling	Adjusts dates to resolve overloads	May extend schedule or change critical path
Need to optimize resources without changing critical path	Resource smoothing	Uses available float to even resource use	Cannot exceed available float
Scarce expert assigned to multiple critical tasks	Leveling or prioritization	Resolves impossible plan	Sponsor/functional manager may need to decide priority
Deadline cannot move but overload exists	Add resources, resequence, reduce scope, or escalate	Leveling alone may miss deadline	Must analyze trade-offs
Work can overlap safely	Fast tracking	Reduces duration by parallel work	Increases rework and coordination risk
More resources can shorten critical activity	Crashing	Trades cost/resources for time	Works only where duration is resource-sensitive
Work waits for risk event or handoff	Calendar/logic adjustment	Represents real timing	Avoid artificial lags when a better logic link exists

Schedule Compression

Technique	What changes	Best when	Main risk
Crashing	Adds resources or cost to shorten duration	Critical path activities can be shortened cost-effectively	Increased cost, diminishing returns
Fast tracking	Performs work in parallel that was planned sequentially	Dependencies are discretionary or overlap is acceptable	Rework, quality issues, coordination failure
Scope reduction	Removes or defers work	Sponsor/customer agrees to changed scope	Requires formal approval where baseline is affected
Resequencing	Changes discretionary logic	Logic is preferential, not mandatory	May introduce risk if assumptions are weak
Calendar change	Adds shifts, overtime, or workdays	Resources and policies allow it	Burnout, cost, quality, constraints
Process improvement	Removes waste or improves throughput	Bottlenecks are process-based	Benefits may be uncertain

Notes and examples

Compression Selection Rules

Confirm the activity is on the critical path or driving path.
Identify the least disruptive option first.
Evaluate cost, risk, quality, scope, and stakeholder impact.
Recommend options; do not silently change commitments.
Use change control if baseline dates, scope, cost, or contractual commitments are affected.

Schedule Risk Analysis

Technique	Use	Output
Risk identification	Find threats and opportunities affecting schedule	Updated risk register
Qualitative risk analysis	Prioritize risks by probability/impact	Watch list, high-priority risks
Quantitative risk analysis	Numerically model uncertainty	Probability of meeting dates, confidence ranges
What-if analysis	Test alternate scenarios	Contingency plans and decision options
Monte Carlo simulation	Model many possible schedule outcomes	Date confidence curves, probabilistic finish dates
Sensitivity analysis	Identify variables with greatest impact	Tornado chart, key schedule drivers
Reserve analysis	Check adequacy of contingency	Reserve recommendations
Risk response planning	Reduce threats or enhance opportunities	Mitigation, avoidance, transfer, acceptance, exploitation

Notes and examples

Expected monetary value, when used:

\[ EMV = Probability \times Impact \]

Schedule risk is often better expressed in time impact, probability of meeting milestones, or confidence intervals rather than only cost.

Risk response	Threat use	Opportunity use
Avoid / Exploit	Change plan to eliminate threat	Ensure opportunity occurs
Mitigate / Enhance	Reduce probability or impact	Increase probability or benefit
Transfer / Share	Shift ownership or impact	Partner to capture benefit
Accept	Take no proactive action beyond monitoring/reserve	Accept if benefit does not justify action

Schedule Risk Concepts

A deterministic CPM schedule gives one forecast based on selected assumptions. Real projects have uncertainty. Schedule risk analysis asks, “How likely is this finish date given uncertainty in durations, logic, resources, and risks?”

High-yield concepts:

Uncertainty should be visible and analyzed.
Critical path can shift under risk simulation.
Near-critical paths matter.
Contingency reserves should be based on analysis, not hidden padding.
Risk responses must be integrated into the schedule.
Schedule risk should be communicated in probability or range terms when appropriate.

Common Schedule Risk Sources

Risk source	Example schedule effect
Optimistic estimates	Baseline is unrealistic
External dependency delay	Successor work cannot start
Resource bottleneck	Critical work waits for scarce skill
Technical uncertainty	Rework or longer duration
Approval delay	Milestone slips despite completed work
Procurement lead time	Materials or services unavailable
Weather/site access/operational windows	Work calendar changes
Scope ambiguity	Activity list incomplete
Quality failures	Rework extends path

Reserves and Padding

Concept	Review point
Contingency reserve	Time set aside for identified risks or uncertainty, usually based on analysis
Management reserve	Time held for unknown-unknowns or broader management control, depending on organizational practice
Padding	Undisclosed extra time inserted into estimates; weak practice
Buffer	Explicit protective time used in some scheduling approaches

Candidate trap: padding individual activities can reduce transparency and make the schedule harder to manage. Explicit reserves or buffers, with governance, are more defensible.

Earned Value and Schedule Performance Metrics

Metric	Plain formula	Interpretation
Planned Value	PV = authorized budget for scheduled work	What should have been earned by now
Earned Value	EV = budgeted value of completed work	Value of work actually completed
Actual Cost	AC = actual cost incurred	What has been spent
Schedule Variance	SV = EV - PV	Positive is ahead of planned value; negative is behind
Schedule Performance Index	SPI = EV / PV	Greater than 1 is favorable; less than 1 is unfavorable
Cost Variance	CV = EV - AC	Positive is under budget; negative is over
Cost Performance Index	CPI = EV / AC	Greater than 1 is favorable; less than 1 is unfavorable
Estimate at Completion	EAC = forecast total cost	Cost forecast, not a finish date
Variance at Completion	VAC = BAC - EAC	Expected budget variance
To-Complete Performance Index	TCPI = work remaining / funds remaining	Efficiency needed for remaining work

Notes and examples

EVM Schedule Traps

SV and SPI are value-based, not direct calendar-day measures.
SPI can become less useful near the end of a project because EV approaches PV when all planned work is complete.
A project can have favorable cost performance and still be late.
Percent complete should be based on defined measurement rules, not optimism.
Schedule control should combine EVM, critical path analysis, milestone trends, and forecast dates.

Monitoring and Controlling Schedule

Step	What to do	Exam clue
Establish data date	Set the status point for progress measurement	“As of Friday,” “current reporting period”
Collect actuals	Actual start/finish, remaining duration, percent complete where valid	“Team reports progress”
Validate data	Check completeness, timing, and credibility	“Conflicting status reports”
Update model	Enter actuals and remaining work	“Recalculate schedule”
Check logic	Fix open ends, invalid constraints, out-of-sequence progress	“Dates look wrong”
Analyze variance	Compare current schedule to baseline	“Behind baseline”
Analyze path impact	Determine critical/driving path effect	“Will milestone be missed?”
Forecast	Predict completion dates and confidence	“Can we still meet target?”
Recommend action	Corrective/preventive actions, risk responses, change requests	“What should the scheduler do next?”
Communicate	Tailor message to stakeholders	“Sponsor wants status”
Control changes	Use formal change control for baseline changes	“Need to rebaseline”

Notes and examples

Statusing Rules

Rule	Why it matters
No incomplete work in the past	Remaining work before the data date distorts forecasts
No actual work in the future	Actuals after the data date are invalid
Actual dates override planned dates	Status must reflect reality
Remaining duration matters	Percent complete alone does not forecast finish
Out-of-sequence progress needs review	It may show bad logic, real resequencing, or data error
Recalculate after updates	Do not interpret stale dates
Compare to baseline after model validation	Bad status data produces false variance

Data Date Discipline

The data date is the status date through which progress is reported. Reliable updates require consistency:

Actual starts and finishes should be accurate.
Remaining duration should reflect current forecast, not original duration minus time elapsed.
No actual work should be recorded after the data date.
In-progress activities should have realistic remaining work.
Out-of-sequence progress should be investigated.
Forecast dates should be recalculated after status is entered.

Candidate trap: percent complete alone is often subjective. A schedule professional should look for objective progress measures and remaining duration.

Progress Measurement Methods

Method	Useful when	Risk
Duration percent complete	Progress roughly follows time elapsed	Can be misleading if work output lags time
Physical percent complete	Tangible measurable output exists	Requires clear measurement rules
Units complete	Repetitive units of work	Unit definitions must be consistent
Milestone weighting	Deliverables have objective checkpoints	Weights can be subjective
Earned value integration	Cost and schedule performance are integrated	Requires reliable PV, EV, and AC data

Variance and Forecasting

High-yield earned value schedule metrics:

Metric	Plain formula	Interpretation
Schedule variance	SV = EV - PV	Positive is ahead of planned value; negative is behind
Schedule performance index	SPI = EV / PV	Greater than 1.0 is favorable; less than 1.0 is unfavorable
Cost variance	CV = EV - AC	Useful when schedule decisions affect cost
Cost performance index	CPI = EV / AC	Cost efficiency indicator

Formula reminders:

\[ \mathrm{SV} = \mathrm{EV} - \mathrm{PV} \]\[ \mathrm{SPI} = \frac{\mathrm{EV}}{\mathrm{PV}} \]

Earned value metrics do not replace critical path analysis. A project can show acceptable SPI while a key milestone is at risk, especially if noncritical work is earning value while critical work is slipping.

Variance Analysis Decision Rule

When a variance appears:

Verify the status data.
Identify the driving activities and root cause.
Determine impact on critical and near-critical paths.
Assess resource, risk, cost, and scope implications.
Develop corrective or preventive options.
Recommend action with consequences.
Submit change requests if the approved baseline must change.
Communicate forecast and decisions needed.

Do not jump directly from “variance exists” to “change the baseline.”

Baseline and Change Control Decisions

Scenario	Best next action	Avoid
Activity is late but milestone still has float	Analyze and monitor; communicate if threshold is met	Escalating as if project finish is already late
Critical path activity slips	Assess impact, forecast, identify recovery options	Updating baseline without approval
Sponsor asks to move approved finish date	Perform impact analysis and submit change request if baseline changes	Changing the schedule informally
Team reports unrealistic remaining duration	Validate with team, update assumptions, revise forecast	Accepting optimistic status without challenge
New mandatory dependency appears	Update logic, analyze impact, raise risk/issue/change as appropriate	Hiding dependency with lag
External vendor delay occurs	Update actual/forecast data, assess contractual and milestone impact, plan response	Waiting until the deadline is missed
Negative float appears	Identify driver, develop recovery options, communicate impact	Treating negative float as normal float
Scope is added	Follow integrated change control; update schedule only after authorization	Absorbing scope without schedule impact analysis
Baseline no longer useful due to approved major change	Rebaseline through approved process	Rebaselining to erase poor performance

Notes and examples

Baseline vs. Current Schedule

Item	Meaning
Baseline schedule	Approved reference for measuring performance
Current schedule	Updated forecast based on actuals and remaining work
Forecast finish	Current predicted completion date
Approved change	Authorized modification to scope, schedule, cost, or other baseline element
Rebaseline	Replace or revise the baseline through approved governance

A schedule baseline is not updated every time actual progress changes. Actuals update the current schedule; approved changes may update the baseline.

When a Change Request Is Needed

A change request is usually appropriate when:

Scope changes affect the schedule baseline.
A required milestone or completion date changes.
Approved assumptions are no longer valid and baseline commitments are affected.
Corrective action requires changes beyond the project manager’s authority.
Contractual or stakeholder commitments are affected.
Rebaselining is proposed.

Candidate trap: rebaselining should not be used to erase unfavorable performance history. It should follow governance and preserve traceability.

Schedule Quality Checks

Check	What to look for	Why it matters
Missing predecessors/successors	Open starts or open finishes without justification	Weak logic hides true drivers
Excessive constraints	Must-start/must-finish dates forcing results	Reduces model credibility
Excessive lags/leads	Large or unexplained gaps/overlaps	May hide missing activities or risk
Negative float	Dates cannot meet required target	Requires recovery or expectation reset
High float outliers	Activities disconnected from real logic	May indicate missing dependencies
Long-duration activities	Hard-to-track work packages	Reduces control visibility
Invalid actual dates	Future actuals or inconsistent status	Corrupts forecast
Out-of-sequence progress	Successor progressed before predecessor complete	May require logic or status correction
Calendar mismatch	Wrong workdays, holidays, shifts	Causes inaccurate dates
Resource overloads	Assignments exceed capacity	Schedule may be infeasible
Baseline mismatch	Current schedule not comparable to approved baseline	Invalid variance analysis
Missing risk links	High-risk activities not reflected in reserves/responses	Understates uncertainty

Notes and examples

Schedule Quality Checks

A schedule must be technically credible before its outputs can be trusted.

Quality check	What to look for	Why it matters
Missing predecessors or successors	Open-ended activities without valid reason	Breaks logic continuity
Excessive constraints	Hard dates replacing logic	Hides true forecast dates
Excessive leads/lags	Hidden work or waiting time	Reduces transparency
Out-of-sequence progress	Successor starts before predecessor logic is satisfied	May indicate bad logic or uncontrolled execution
Activities with no clear owner	Unclear responsibility	Weak status reliability
Long-duration activities	Hard to measure progress objectively	May need decomposition
Invalid actual dates	Actuals after the data date or inconsistent progress	Corrupts status
Negative float	Required date is not achievable under current plan	Requires analysis and response
No critical path	Schedule logic may be broken	Forecast is unreliable
Summary-level logic	Dependencies tied to summary bars rather than activities	Can distort calculations
Calendar inconsistencies	Activities assigned to wrong calendars	Produces misleading dates

A strong answer often starts with validating the schedule model before relying on its forecast.

Communication and Reporting

Audience	Useful schedule view	What they usually need
Sponsor / steering group	Milestone summary, trend chart, forecast	Decisions, exceptions, confidence
Project manager	Critical path, variance, risk, recovery options	Control actions and trade-offs
Team leads	Lookahead schedule, handoffs, constraints	Near-term priorities
Functional managers	Resource histogram, allocation forecast	Staffing conflicts and capacity
Customer / client	Contract milestones, deliverable dates, impacts	Commitment status and change implications
Vendors	Interface milestones, delivery dates, dependencies	Coordination and accountability
Agile team	Iteration plan, backlog flow, release forecast	Work sequencing and delivery predictability

Good Schedule Communication

State the data date.
Distinguish baseline dates, current forecast dates, and target dates.
Explain drivers, not just symptoms.
Show options with impacts on time, cost, scope, quality, and risk.
Escalate decisions, not raw confusion.
Do not hide unfavorable information.

Notes and examples

Good Schedule Reporting

Effective schedule communication is tailored, concise, and decision-focused.

Report:

Overall milestone outlook.
Critical and near-critical path changes.
Variances from baseline.
Forecast completion dates.
Key risks and uncertainty.
Resource bottlenecks.
External dependency status.
Corrective actions underway.
Decisions or approvals needed.

Avoid reporting only:

A large unfiltered Gantt chart.
Percent complete without forecast.
Green/yellow/red status without explanation.
Baseline variance without root cause.
Technical scheduling details irrelevant to the audience.

Communication by Audience

Audience	Needs
Sponsor/executives	Milestone confidence, decision needs, major risks, business impact
Project manager	Forecasts, variances, corrective options, tradeoffs
Functional/resource managers	Resource conflicts, upcoming demand, priority decisions
Team leads	Near-term activities, handoffs, constraints, status expectations
Customer/client	Approved milestone outlook, changes, risks, commitments
Vendors/contractors	Interfaces, deliverables, external dependencies, required dates

Predictive, Adaptive, and Hybrid Scheduling

Environment	Scheduling focus	Common artifacts	PMI-SP exam angle
Predictive	Detailed upfront schedule baseline and control	WBS, network diagram, Gantt chart, baseline, milestone chart	CPM, float, baseline variance, change control
Adaptive / agile	Cadence, flow, prioritization, release forecasting	Product backlog, iteration plan, release roadmap, burn chart	Forecast with velocity/throughput and changing scope
Hybrid	Predictive milestones with adaptive delivery inside phases	Integrated master schedule, release plan, phase gates	Align iterative work with fixed milestones
Rolling wave	Detail near-term work; keep future work higher level	Planning packages, updated activity detail	Appropriate when uncertainty decreases over time

Agile Schedule Concepts Worth Knowing

Concept	Meaning	Scheduling use
Timebox	Fixed-duration iteration or event	Protects cadence and predictability
Velocity	Work completed per iteration	Used for release forecasting, not as a productivity weapon
Burndown chart	Remaining work over time	Shows whether team is trending toward completion
Burnup chart	Completed work and total scope over time	Shows progress and scope change
Cumulative flow diagram	Work items by workflow state	Reveals bottlenecks and WIP buildup
Lead time	Time from request to delivery	Customer-facing flow metric
Cycle time	Time actively worked from start to finish	Process efficiency metric
WIP limit	Cap on work in progress	Improves flow and reduces multitasking
Release roadmap	Forecast of features/capabilities over time	Connects agile delivery to stakeholder expectations

Notes and examples

Velocity forecast:

\[ Iterations\ Needed = \frac{Remaining\ Backlog}{Average\ Velocity} \]

Use velocity as a planning input. Do not treat it as a guaranteed commitment when backlog size, team capacity, or priorities change.

Common “What Should the Scheduler Do Next?” Scenarios

Scenario	Best answer pattern
Requested finish date is unrealistic	Build/analyze the schedule, identify gap, propose options, communicate impact
Stakeholder wants a date commitment before analysis	Explain that commitment requires validated estimates, logic, resources, and risk review
Critical resource is unavailable	Update calendar/availability, analyze impact, evaluate alternatives, escalate if priority decision is needed
Team wants to add hidden buffer to each task	Use transparent reserve/risk planning instead
Schedule shows finish later than contract milestone	Verify model, analyze drivers, identify recovery options, communicate and use change/control processes
Many activities use hard constraints	Review and replace with logic where possible
Delay has already happened	Treat as issue; update actuals, forecast impact, plan corrective action
Delay might happen	Treat as risk; assess probability/impact and plan response
Project is behind but cost is favorable	Analyze schedule drivers; do not assume cost performance solves time performance
A manager asks to rebaseline due to poor performance	Rebaseline only through approved change control and valid justification
Agile release forecast slips	Reforecast using actual velocity/throughput, review scope priorities, communicate options
Vendor milestone is missed	Update schedule, review contract/interface impact, escalate per governance, plan mitigation
Stakeholders dispute progress	Validate measurement method, inspect objective evidence, update status transparently

High-Yield Distinctions

Do not confuse	Distinction
Schedule model vs schedule	Model calculates dates; schedule is a communicated output/view
Target date vs baseline date	Target may be desired; baseline is approved for performance measurement
Duration vs effort	Duration is calendar time; effort is labor required
Lag vs contingency	Lag is modeled waiting time; contingency is risk allowance
Risk vs issue	Risk may occur; issue has occurred
Free float vs total float	Free float protects immediate successors; total float protects project/milestone finish
Crashing vs fast tracking	Crashing adds resources/cost; fast tracking overlaps work
Leveling vs smoothing	Leveling may change finish date; smoothing stays within available float
Corrective vs preventive action	Corrective addresses current variance; preventive reduces future variance risk
Forecast vs baseline	Forecast is current prediction; baseline is approved comparison point
Percent complete vs remaining duration	Percent complete reports progress; remaining duration drives finish forecast
Milestone variance vs critical path impact	A missed milestone may or may not affect final completion

Notes and examples

Key Artifact Distinctions

Artifact	What it is	Watch for
WBS	Deliverable-oriented decomposition of project scope	Not the same as the activity list
Activity list	Work actions needed to produce deliverables	Should trace back to scope
Activity attributes	Details such as responsibility, calendar, codes, assumptions, constraints	Helps filtering, reporting, and analysis
Schedule model	The logic-driven representation of activities, durations, dependencies, calendars, resources, and constraints	More than a visual Gantt chart
Project schedule	Schedule outputs presented for execution and communication	Should be derived from the model
Schedule baseline	Approved version used to measure performance	Changed only through approved change control
Schedule data	Supporting information such as assumptions, basis of estimates, milestones, and resource requirements	Often needed to explain decisions

Professional Responsibility for PMI-SP Candidates

PMI-SP scenarios often reward professional schedule behavior:

Report schedule status honestly and objectively.
Do not manipulate logic, constraints, or baselines to hide variance.
Disclose assumptions, uncertainty, and confidence level.
Respect approved governance and change control.
Use historical data responsibly.
Communicate bad news early with options.
Collaborate with project managers, teams, sponsors, vendors, and functional managers.
Protect confidential project information.

Final Review Checklist

Before exam day, make sure you can quickly:

Build a simple network diagram from dependencies.
Perform forward and backward pass calculations.
Identify critical path, total float, free float, and negative float.
Choose between crashing, fast tracking, leveling, and smoothing.
Interpret schedule variance, SPI, and milestone trends.
Explain why a baseline cannot be changed informally.
Diagnose bad schedule logic, constraints, lags, and calendar issues.
Select the right report for the stakeholder.
Distinguish risk responses from issue management.
Apply rolling-wave, agile, or hybrid scheduling when the scenario calls for it.

Next step: practice PMI-SP-style scenario questions that require calculation, schedule diagnosis, and “best next action” decisions under realistic project constraints.

Notes and examples

Final Rapid Review Checklist

Before you move to mock exams, confirm you can explain:

The difference between activity list, schedule model, project schedule, and schedule baseline.
Why a schedule with many constraints may be unreliable.
How total float differs from free float.
Why negative float matters.
How resource leveling can change the critical path.
When crashing is better than fast tracking, and when neither is appropriate.
Why remaining duration is often more useful than percent complete.
Why earned value schedule metrics do not replace critical path analysis.
How to respond when actual progress differs from the baseline.
Why rebaselining requires governance.
How schedule risk analysis improves confidence in milestone forecasts.
What information different stakeholders need from schedule reporting.

High-Yield Review Map

Area	What to know cold	Common exam trap
Schedule strategy	Scheduling approach, governance, update cadence, level of detail, stakeholder reporting needs	Building detailed activities before scope and governance are clear
Schedule planning and development	WBS-to-activity decomposition, sequencing, duration estimating, calendars, resources, constraints, CPM	Treating a Gantt chart as the schedule model
Schedule analysis	Critical path, total/free float, near-critical paths, negative float, what-if analysis, quality checks	Assuming the critical path is always the shortest or most visible path
Resources and calendars	Resource availability, leveling, smoothing, productivity, calendar effects	Ignoring that resource constraints can change the critical path
Risk and uncertainty	Schedule risk, reserves, Monte Carlo concepts, contingency, risk responses	Hiding uncertainty as padding inside activity durations
Monitoring and control	Data date, actuals, remaining duration, variance analysis, forecasts, change control	Rebaselining to conceal poor performance
Communication	Tailored reporting, milestone outlook, exceptions, decisions needed	Sending a large schedule file instead of actionable information
Closeout	As-built schedule, lessons learned, final variance analysis, archive of assumptions and changes	Failing to preserve schedule history for future estimating and claims support

Core Scheduling Lifecycle

A strong PMI-SP exam answer usually follows this logic:

Define the scheduling approach
- Confirm scope basis, scheduling method, tool conventions, calendars, coding structure, and reporting needs.
- Establish update frequency, roles, approvals, and change control expectations.
Develop the schedule model
- Decompose work, define activities, sequence logically, estimate durations, assign resources, apply calendars, and document assumptions.
Analyze and validate
- Run critical path analysis, check float, review resource feasibility, test constraints, perform risk analysis, and correct schedule quality problems.
Approve the baseline
- Obtain stakeholder acceptance of the schedule baseline as the agreed performance reference.
Monitor and control
- Collect status, update actuals and remaining work, compare to baseline, forecast outcomes, recommend corrective action, and manage approved changes.
Close and learn
- Preserve as-built data, document variances, capture lessons learned, and improve future scheduling practices.

Schedule Strategy and Governance

What a Good Schedule Management Approach Defines

A schedule management approach should clarify:

Scheduling methodology and tool conventions.
Required level of detail.
Activity coding and naming standards.
Calendar rules and time units.
Estimating approach.
Resource planning expectations.
Update frequency and data date discipline.
Baseline approval process.
Change control process.
Reporting formats by stakeholder group.
Schedule quality review expectations.
Roles and responsibilities for status collection, approval, and analysis.

Notes and examples

Common Strategy Mistakes

Mistake	Why it is risky
Starting with target dates instead of scope	Creates a date-driven plan with weak logic
Over-detailing early uncertain work	Produces false precision and maintenance burden
Under-detailing near-term work	Makes progress hard to measure and control
Using too many hard constraints	Masks schedule logic and hides true criticality
Ignoring stakeholder reporting needs	Produces schedules that do not support decisions
No documented update process	Causes inconsistent progress data and unreliable forecasts

Level of Detail Decision Rule

Use enough detail to control the work, not so much that the schedule becomes unmaintainable.

Good activity detail usually supports:

Clear responsibility.
Measurable start and finish.
Reasonable duration for the control cycle.
Logical connection to predecessors and successors.
Meaningful progress reporting.

If an activity is too broad, progress becomes subjective. If it is too granular, the schedule becomes administrative noise.

Developing the Schedule Model

From Scope to Activities

A credible schedule begins with scope clarity.

Concept	Review point
WBS	Defines deliverables and scope structure
Work package	Lowest WBS level commonly used for planning and control
Activity	Scheduled work action needed to produce a deliverable
Milestone	Significant event or decision point; normally zero duration
Rolling wave planning	Detail near-term work while keeping later work at a higher level until more is known

Notes and examples

Common trap: a milestone is not work. If a question describes a milestone with effort, duration, or resources, the exam may be testing whether you recognize that the work activities leading to the milestone need to be defined.

Dependencies and Relationships

Most scheduling questions use precedence logic. Know the relationship types.

Relationship	Meaning	Typical use	Trap
Finish-to-Start	Successor starts after predecessor finishes	Most common construction/planning logic	Overusing it when overlap is realistic
Start-to-Start	Successor starts after predecessor starts	Parallel work with controlled start relationship	Can hide incomplete handoffs
Finish-to-Finish	Successor finishes after predecessor finishes	Coordinated completion	Needs careful progress tracking
Start-to-Finish	Successor finishes after predecessor starts	Rare	Often a distractor

Dependency Types

Type	Meaning	Exam implication
Mandatory dependency	Inherent or contractually/technically required sequence	Harder to change
Discretionary dependency	Preferred sequence based on best practice or choice	Candidate for compression review
External dependency	Relationship with work outside the project team’s control	Requires monitoring and communication
Internal dependency	Relationship within the project team’s control	Can often be optimized more directly

Leads and Lags

A lag delays the successor after the dependency condition is met.
A lead allows the successor to start before the predecessor is fully complete.

Use leads and lags carefully. A schedule with excessive lags or leads may be harder to validate because hidden work or waiting time is embedded in relationships instead of shown as explicit activities.

Better exam answer when possible: make significant waiting, curing, review, approval, or handoff periods visible as activities rather than burying them in unexplained lag.

Critical Path and Float

Critical Path Basics

The critical path is the path through the schedule that determines the earliest possible project finish, based on current logic, durations, calendars, constraints, and status.

Important points:

A project can have multiple critical paths.
Near-critical paths can become critical after small delays.
Critical path can change after status updates, resource leveling, or approved changes.
Negative float can appear when a required date is earlier than the calculated completion date.
Critical does not mean “most important” or “highest risk”; it means schedule-driving under the current model.

Notes and examples

Forward and Backward Pass

Forward pass calculates early dates:

\[ \mathrm{EF} = \mathrm{ES} + \mathrm{Duration} \]\[ \mathrm{ES}_{\text{successor}} = \max(\mathrm{EF}_{\text{predecessors}}) \]

Backward pass calculates late dates:

\[ \mathrm{LS} = \mathrm{LF} - \mathrm{Duration} \]\[ \mathrm{LF}_{\text{predecessor}} = \min(\mathrm{LS}_{\text{successors}}) \]

Float:

\[ \mathrm{Total\ Float} = \mathrm{LS} - \mathrm{ES} \]\[ \mathrm{Total\ Float} = \mathrm{LF} - \mathrm{EF} \]\[ \mathrm{Free\ Float} = \min(\mathrm{ES}_{\text{successors}}) - \mathrm{EF} \]

The exam usually tests the concept more than date-counting quirks. Watch for inclusive versus exclusive date conventions if a calculation question gives calendar dates.

Types of Float

Float type	Meaning	Practical use
Total float	Time an activity can slip without delaying project completion or a constrained milestone	Identifies schedule flexibility
Free float	Time an activity can slip without delaying any immediate successor	Useful for team-level coordination
Negative float	Amount by which the current schedule misses a required date	Signals need for analysis, escalation, or corrective action
Project float	Flexibility between planned finish and an external required finish	May be controlled by sponsor/customer expectations

What Can Change the Critical Path?

Change	Possible effect
Activity duration update	May lengthen or shorten a path
Logic correction	Can reveal a different driving path
Resource leveling	May delay activities and create a resource-critical path
Calendar change	Can alter working time and sequence feasibility
Constraint addition/removal	Can create or remove negative float
Actual progress	Can shift remaining work and driving activities
Risk response	Can reduce, transfer, or introduce schedule exposure

Constraints, Assumptions, and Calendars

Constraints

Constraints should be used deliberately and documented.

Constraint issue	Better practice
Hard start/finish dates used everywhere	Use logic-driven scheduling where possible
Constraint added to force desired finish	Analyze why the model does not meet the target
Mandatory date not documented	Record source and approval basis
Constraint hides negative float	Report the gap between required and forecast dates

Constraints are sometimes legitimate, especially for externally imposed milestones or business commitments. The exam trap is treating constraints as a substitute for schedule logic.

Assumptions

Document assumptions about:

Resource availability.
Productivity.
Review and approval durations.
External dependencies.
Procurement or vendor lead times.
Access windows.
Calendars and nonworking periods.
Technical complexity.
Risk response effectiveness.

When assumptions change, assess schedule impact rather than silently editing dates.

Professional and Ethical Scheduling Behavior

PMI exams often reward professional judgment. For PMI-SP scenarios, favor answers that show:

Transparency about uncertainty and variance.
Accurate reporting, even when the news is unfavorable.
Respect for approved change control.
Documentation of assumptions and decisions.
Collaboration with stakeholders and subject matter experts.
Objective progress measurement.
No manipulation of schedule data to create a misleading picture.
Escalation when decisions exceed authority.

If an answer choice hides information, bypasses governance, manipulates dates, or blames stakeholders before analyzing facts, it is usually weak.

Scenario Decision Rules

If the question says…	Think…	Better answer direction
“The sponsor wants an earlier finish date”	Compression request	Analyze critical path options, risks, cost, and change implications
“A key resource is unavailable”	Resource constraint	Assess impact, alternatives, leveling, priorities, and communication
“A team reports 90% complete for weeks”	Subjective progress	Use objective measurement and remaining duration review
“The schedule has many hard constraints”	Logic may be unreliable	Review constraints, replace with logic where possible, document valid constraints
“The project is behind baseline”	Control process	Validate data, analyze root cause, forecast, recommend corrective action
“The baseline no longer matches reality”	Not automatically rebaseline	Use change control; preserve variance history
“A vendor delivery is late”	External dependency	Update forecast, assess critical path, communicate, consider responses
“Critical path changed after update”	Normal possibility	Validate status and logic, then communicate implications
“Negative float appears”	Required date is at risk	Identify drivers, assess options, escalate decision needs
“Activities have no successors”	Open ends	Validate whether legitimate; otherwise correct logic
“Later work is uncertain”	Rolling wave planning	Plan near-term detail; refine future work progressively
“Stakeholders disagree on dates”	Governance and alignment	Refer to approved baseline, requirements, assumptions, and change process

Common Candidate Mistakes

Mistake 1: Confusing the Schedule Model with the Schedule Baseline

The model is the living calculation engine. The baseline is the approved reference. You update the model with actuals; you change the baseline only through approved change control.

Mistake 2: Treating Critical Path as Static

The critical path can change with progress, logic corrections, resource constraints, or risk events. Monitor near-critical paths too.

Mistake 3: Compressing Noncritical Work

Crashing or fast tracking noncritical activities may not improve project finish. First confirm which activities drive the target milestone or completion date.

Mistake 4: Ignoring Resource Feasibility

A logic-only schedule may look achievable while requiring the same person or equipment in multiple places at once. Resource review is part of schedule credibility.

Mistake 5: Using Percent Complete Without Remaining Duration

Percent complete can be subjective. Remaining duration and objective physical progress usually give a better forecast.

Mistake 6: Hiding Risk in Activity Durations

Undisclosed padding makes the schedule less transparent. Use documented assumptions, reserves, buffers, and risk analysis.

Mistake 7: Reporting Data Instead of Insight

A schedule professional should explain what changed, why it matters, what is forecast, and what decision is needed.

Mistake 8: Skipping Root Cause Analysis

If a milestone slips, do not immediately change the date. Determine why the variance occurred and whether corrective or preventive action is possible.

Quick Formula Review

Concept	Plain formula
Expected duration, beta/PERT-style	E = (O + 4M + P) / 6
Standard deviation, beta/PERT-style	Sigma = (P - O) / 6
Early finish	EF = ES + Duration
Late start	LS = LF - Duration
Total float	TF = LS - ES, or TF = LF - EF
Free float	FF = earliest successor ES - current activity EF
Schedule variance	SV = EV - PV
Schedule performance index	SPI = EV / PV
Cost variance	CV = EV - AC
Cost performance index	CPI = EV / AC

Keep formulas connected to scenario meaning. The exam may ask what a result implies or what action should follow, not just the calculation.

High-Yield Practice Targets

After this review, use PM Mastery practice to drill these areas:

Topic drill	What to practice
Schedule model logic	Dependencies, leads/lags, constraints, relationship types
CPM calculations	Early/late dates, float, critical path, negative float
Resource scenarios	Leveling, smoothing, bottlenecks, calendars
Schedule compression	Crashing, fast tracking, tradeoffs, risk impacts
Status updates	Data date, actuals, remaining duration, out-of-sequence progress
Variance analysis	Baseline comparison, forecasts, root cause, corrective action
Change control	When to update current schedule vs. baseline
Schedule risk	reserves, uncertainty, near-critical paths, risk responses
Reporting	Matching schedule information to stakeholder decisions
Closeout	As-built schedules, lessons learned, historical data

For every missed question, ask:

Which schedule artifact is involved?
Is the project planning, baselining, executing, controlling, or closing?
Is the issue logic, resource, risk, stakeholder, or governance-related?
What should a scheduling professional do before changing dates?
Does the answer preserve transparency and schedule integrity?

Put the review into practice

PM Mastery

Start Cheat Sheet practice on Web

Tip: Use the web app to preview question style, then practise the topics you need to revisit.

Use the web app for Cheat Sheet scenario practice, topic drills, timed mock exams, detailed explanations, and saved progress. Original PM Mastery practice only; not official questions, copied live-exam content, or exam dumps.

Current alignment Mapped to the current exam content outline, domains, tasks, learning outcomes, or syllabus areas for this exam.

Practice modes Use topic drills, timed mocks, scenario practice, and focused pages before deeper mixed practice.

Teaching explanations Explanations teach the project, agile, governance, or delivery rule that makes the best option stronger.

Stable bank Questions are prebuilt and reviewed before publication, so practice is stable and inspectable, not improvised during a quiz.

Study Plan