Schedule Techniques in Project Management — Complete Guide (All 11 PMBOK 8 Methods)

Every project lives or dies by its schedule. But knowing which scheduling technique to use — and how to apply it correctly — separates project managers who consistently deliver on time from those who are perpetually scrambling to recover from delays.

PMBOK 8 identifies eleven distinct scheduling techniques, each designed for a different type of planning challenge. Some calculate the longest path through a network. Others compress timelines under resource constraints. A few are built specifically for adaptive, agile delivery environments. Together they form the complete toolkit for schedule planning and control.

This guide covers all eleven techniques in depth — definition, when to use, how to apply, and practical examples — plus a comparison table to help you select the right technique for your situation.

1. Critical Path Method (CPM)

What It Is

The Critical Path Method is the most foundational scheduling technique in project management. It identifies the longest sequence of dependent activities through the project network — the sequence whose total duration determines the earliest possible project completion date. Any delay to an activity on this path delays the entire project by the same amount. Activities not on the critical path have float (slack) — meaning they can be delayed within limits without affecting the project end date.

CPM was developed in the late 1950s by DuPont and Remington Rand for industrial plant maintenance and construction projects. Decades later, it remains the dominant analytical technique for schedule planning on complex, sequentially-dependent work.

Core Concepts

• Critical Path: The longest path through the network from project start to project finish. Its total duration equals the minimum possible project duration.
• Float (Total Float): The amount of time an activity can be delayed without delaying the project end date. Activities on the critical path have zero total float.
• Free Float: The amount of time an activity can be delayed without delaying the early start of any successor activity.
• Early Start (ES): The earliest date an activity can begin, given its predecessors.
• Early Finish (EF): The earliest date an activity can finish: ES + Duration − 1.
• Late Start (LS): The latest date an activity can begin without delaying the project end.
• Late Finish (LF): The latest date an activity can finish without delaying the project end.
• Total Float formula: LS − ES = LF − EF.

The Forward and Backward Pass

CPM analysis involves two passes through the network:

Forward Pass (calculating Early dates):

1. Start at the first activity. Set its Early Start to 0 (or the project start date).
2. Calculate Early Finish for each activity: EF = ES + Duration.
3. For each successor, set ES = the largest EF of all its predecessors (this is the merge point rule — when multiple paths merge, the latest predecessor controls).
4. Continue forward through the network. The largest EF at the project’s end node is the project’s minimum duration.

Backward Pass (calculating Late dates):

1. Start at the last activity. Set its Late Finish equal to its Early Finish (or a specified target date if schedule compression is required).
2. Calculate Late Start: LS = LF − Duration.
3. For each predecessor, set LF = the smallest LS of all its successors (the burst point rule — when one activity feeds multiple successors, the most constrained successor controls).
4. Continue backward through the network.

After both passes, calculate float for each activity: Float = LS − ES. Activities with zero float form the critical path.

When to Use CPM

• Projects with well-defined activities and deterministic (known or reliably estimated) durations
• Construction, engineering, manufacturing, IT implementation, and event planning
• Whenever you need to answer: “What is the minimum project duration?” and “Which activities, if delayed, will delay the project?”
• When you need to prioritize management attention — critical path activities demand the most oversight
• When you need to evaluate schedule recovery options (adding resources to critical path activities shortens the path)

How to Apply CPM — Step by Step

1. Define activities: Decompose the project scope into individual activities with clear start and end points.
2. Estimate durations: Assign a duration to each activity (in consistent units — days, weeks).
3. Sequence activities: Identify predecessors for each activity. This defines the network topology.
4. Build the network diagram: Use Precedence Diagramming Method (PDM) to represent activities as nodes and dependencies as arrows. This is the Activity-on-Node (AON) format.
5. Run the forward pass: Calculate ES and EF for every activity.
6. Run the backward pass: Calculate LF and LS for every activity.
7. Calculate float: Float = LS − ES for every activity.
8. Identify the critical path: The sequence of activities with zero float. There may be multiple critical paths.
9. Analyze near-critical paths: Paths with very low float (e.g., 1–3 days) are near-critical and require close monitoring.
10. Maintain and update: After each reporting period, update actual progress, recalculate the schedule, and confirm which activities remain on or near the critical path.

Practical Example

A software deployment project has the following activities:

Forward Pass:

• A: ES=0, EF=3
• B: ES=3, EF=8
• C: ES=3, EF=11
• D: ES=max(8,11)=11, EF=15
• E: ES=15, EF=18
• F: ES=18, EF=19

Minimum project duration: 19 days.

Backward Pass: (LF of F = 19)

• F: LF=19, LS=18
• E: LF=18, LS=15
• D: LF=15, LS=11
• C: LF=11, LS=3 → Float = 0
• B: LF=11, LS=6 → Float = 3
• A: LF=3, LS=0 → Float = 0

Critical Path: A → C → D → E → F (19 days, zero float throughout).

Activity B has 3 days of float — it can slip by 3 days without delaying the project.

Key Limitations of CPM

• CPM assumes deterministic durations. It does not model uncertainty. For projects with high duration uncertainty, PERT or Monte Carlo simulation provide more realistic schedule analysis.
• CPM does not account for resource constraints. It assumes unlimited resources. Use Resource Optimization techniques to adjust the CPM schedule for real resource availability.
• A mathematically correct critical path can be misleading if activity durations were estimated poorly. The quality of CPM analysis depends entirely on the quality of estimates and dependency definitions.

2. Critical Chain Method

What It Is

The Critical Chain Method (CCM) is a schedule planning and control technique developed by Eliyahu Goldratt, introduced in his 1997 book Critical Chain. It extends CPM by explicitly addressing the two most common causes of schedule overruns: resource constraints and the behavioral tendencies of estimators and executors (specifically Parkinson’s Law — work expands to fill available time — and student syndrome — the tendency to start work at the last possible moment).

CCM shifts the focus from individual activity buffers to aggregated project and feeding buffers placed at strategic points in the network, while removing the safety time embedded in individual activity estimates.

Core Concepts

• Critical Chain: The longest path through the project network accounting for both activity dependencies and resource dependencies. Unlike CPM’s critical path, the critical chain can be broken by resource constraints — two activities may have no logical dependency, but if they require the same resource, the resource creates an implicit sequencing constraint.
• Aggressive Activity Estimates: CCM asks estimators to provide 50th-percentile (median) estimates rather than 90th-percentile (high confidence) estimates. The safety margin typically added to individual activities is stripped out and aggregated into buffers.
• Project Buffer (PB): A time buffer placed at the end of the critical chain, between the last activity and the project due date. The project buffer protects the project end date from variations on the critical chain. Typically sized at 50% of the total safety removed from critical chain activities.
• Feeding Buffers (FB): Time buffers placed at every point where a non-critical chain path feeds into the critical chain. They protect the critical chain from delays on feeder paths. Sized proportionally to the safety removed from feeder path activities.
• Resource Buffers: Alerts placed before critical chain activities to ensure resources are available and ready when needed. They do not add time to the schedule; they are notification triggers for resource managers.

When to Use Critical Chain Method

• Projects with chronic schedule overruns despite adequate original planning
• Environments where multitasking dilutes resource effectiveness across multiple projects
• Multi-project environments where shared resources create invisible constraints between projects
• Organizations open to behavioral change — CCM requires teams to resist the urge to use activity safety as personal insurance
• Projects where resource availability is the dominant scheduling constraint

How to Apply CCM — Step by Step

1. Build the initial network: Create the project network using PDM, identical to CPM preparation.
2. Strip individual safety: Re-estimate all activities using aggressive (50th-percentile) durations. Remove the safety margin previously embedded in each estimate.
3. Identify resource constraints: Map which resources are needed for each activity. Identify resource conflicts where the same resource is needed for concurrent activities. Resolve conflicts by sequencing the constrained activities (one resource, one task at a time).
4. Identify the critical chain: The longest path through the network accounting for both logical and resource dependencies.
5. Insert the Project Buffer: Add a project buffer at the end of the critical chain. A common sizing method is 50% of the summed safety removed from critical chain activities.
6. Insert Feeding Buffers: At each merge point where a non-critical chain path joins the critical chain, insert a feeding buffer sized proportionally to the safety removed from that feeder path.
7. Insert Resource Buffers: Place resource alerts before critical chain activities that require scarce resources. These are early-warning triggers, not schedule time.
8. Monitor using Buffer Management: During execution, track buffer consumption. If buffer consumption rate exceeds a threshold (e.g., more than 33% of the project buffer consumed at 20% project completion), escalate and take corrective action.

Practical Example

A product development project has a critical chain of 40 days with individual activity safeties totaling 20 days. Under CCM:

• The 20 days of individual safety are removed from the activity estimates.
• A project buffer of 10 days (50% of 20) is added at the end of the critical chain.
• The scheduled project duration is 50 days (40 critical chain + 10 project buffer), versus a CPM schedule of 60 days (40 + 20 spread across activities).
• A feeder path with 12 days of activity safety feeds the critical chain at day 25. A feeding buffer of 6 days is inserted before that merge point.

During execution, the team tracks buffer consumption weekly. If the project buffer has been consumed by 6 days (60%) while only 50% of the critical chain is complete, the buffer is being consumed faster than planned — a trigger for corrective action.

CPM vs. CCM: Key Differences

3. Precedence Diagramming Method (PDM)

What It Is

The Precedence Diagramming Method is the standard technique for representing activity sequences and dependencies in a project schedule network. It is the visual language of modern project scheduling — the way project managers draw and communicate the logical structure of a project before calculating dates.

In PDM, activities are represented as nodes (boxes), and dependencies between activities are represented as arrows connecting those nodes. This format is called Activity-on-Node (AON) and is the basis for virtually all modern scheduling software, including Microsoft Project, Primavera P6, and others.

PDM was developed in the 1960s by IBM and refined by the Stanford Research Institute. It superseded the earlier Arrow Diagramming Method (ADM or Activity-on-Arrow) because AON networks are easier to construct, read, and modify — particularly because PDM supports four types of logical relationships that ADM cannot represent without dummy activities.

The Four Dependency Types in PDM

This is the most important concept in PDM. The four relationship types give project managers precise control over how activities interact in time:

1. Finish-to-Start (FS) — the default and most common

Activity B cannot start until Activity A finishes. The successor waits for the predecessor to be complete.

• Example: “Testing cannot start until coding is complete.”
• This is the type assumed when no other type is specified.
• With a lag: FS+2 means Activity B starts 2 days after Activity A finishes (e.g., concrete must cure for 2 days before formwork is removed).
• With a lead: FS−3 means Activity B can start 3 days before Activity A finishes (overlapping start).

2. Start-to-Start (SS)

Activity B cannot start until Activity A starts. Both activities proceed in parallel, but B is constrained to begin no earlier than A’s start.

• Example: “Quality control can start once production starts — but not before.”
• With a lag: SS+5 means B can start 5 days after A starts (useful for activities that begin together but one needs a head start).
• Common in construction where multiple crews work on the same type of activity (paving one section must begin before the next section starts, but both run in parallel).

3. Finish-to-Finish (FF)

Activity B cannot finish until Activity A finishes. The completion of B is constrained by the completion of A.

• Example: “Documentation cannot be completed until testing is completed” — because documentation must reflect the final tested state of the system.
• With a lag: FF+3 means B finishes 3 days after A finishes.
• Often used when two activities conclude together, one providing the final input the other needs to close.

4. Start-to-Finish (SF) — rare

Activity B cannot finish until Activity A starts. This is the least intuitive and least used relationship type.

• Example: “The new system cannot be shut down (B finishes) until the legacy system is fully operational (A starts).” Used in technology cutovers and shift handovers.
• In a shift handover: the outgoing shift (B) cannot leave (B finishes) until the incoming shift (A) has started.
• Most experienced project managers rarely use SF, and scheduling tools sometimes handle it inconsistently. Use FS relationships wherever possible to avoid complexity.

Network Diagram Notation

A PDM network node typically shows:

• Activity name or ID (center)
• Duration (below center)
• Early Start (top left)
• Early Finish (top right)
• Late Start (bottom left)
• Late Finish (bottom right)
• Float (bottom center)

Arrows between nodes represent dependencies. The arrow’s label may include the relationship type (if not FS) and any lag or lead value.

When to Use PDM

• PDM is used on virtually every project that uses a formal schedule — it is not optional; it is the foundation.
• During planning, PDM is used to define the logical sequence of activities before any dates are calculated.
• During schedule development, PDM is the input to CPM analysis — without a PDM network, you cannot identify the critical path.
• During schedule review, a PDM diagram communicates project logic to stakeholders more clearly than a Gantt chart alone, because it makes dependencies explicit.

How to Build a PDM Network — Step by Step

1. List all activities: Use the WBS and activity list developed during scope planning.
2. For each activity, ask three questions:
   • What activities must be completed before this one can start?
   • What activities can run in parallel with this one?
   • What activities cannot start (or finish) until this one starts (or finishes)?
3. Assign relationship types: Default to FS unless the actual work logic requires SS, FF, or SF.
4. Add lags or leads: Where appropriate — a 2-day curing time is a lag; a 3-day overlap is a negative lag (lead).
5. Draw the network: Place activities as boxes, draw arrows for each dependency, label non-FS relationships and any lags/leads.
6. Review for logic errors: Check for:
   • Dangling activities: Activities with no successor (except the final activity) or no predecessor (except the first activity).
   • Loops: Circular dependencies (A depends on B, B depends on A) — these make CPM calculation impossible and usually indicate a logic error.
   • Unnecessary constraints: Activities linked with FS when they could logically run in parallel — artificially extending the schedule.
7. Validate with the team: Have subject matter experts review the network logic before running CPM. A logically incorrect network produces a mathematically correct but practically useless schedule.

Practical Example — Software Release Network

A software product release involves the following activities and dependencies:

In this network, Activity E (Documentation) uses an SS+3 relationship with Development — a scheduling efficiency that allows documentation to run concurrently with development rather than waiting for it to finish completely. Activity G uses both an FS dependency on F and an FF dependency on E, ensuring that documentation is finalized in coordination with release preparation, not independently.

Common PDM Mistakes and How to Avoid Them

• Defaulting to FS everywhere: Using only FS relationships when SS or FF would more accurately model the work logic. This creates artificially sequential schedules. Challenge each relationship: is this activity truly blocked until the predecessor finishes, or can it start earlier?
• Overusing lags: Large lags often indicate a missing activity (the wait time is actually work that hasn’t been planned). Investigate every lag greater than 1–2 days to confirm it represents unavoidable elapsed time, not unplanned work.
• Skipping network review: Building a PDM and running CPM without a logic review with subject matter experts. The network logic is as important as the durations — errors here invalidate the entire schedule.
• Creating overly complex networks: Adding SF relationships and multi-level lags that become impossible to understand or maintain. Prefer simple, transparent network logic over clever optimizations.

4. Schedule Network Analysis

What It Is

Schedule Network Analysis is the overarching category of techniques used to analyze the project schedule network and generate the project schedule model. It is less a single method and more a family of analytical approaches — with CPM, Critical Chain, PERT, What-If Scenario Analysis, and simulation (Monte Carlo) all fitting within this family.

PMBOK 8 positions Schedule Network Analysis as the technique by which the project team evaluates the schedule network to find the optimal project schedule — one that is logically correct, resource-feasible, and achievable within project constraints.

What Schedule Network Analysis Includes

• Critical Path Method analysis: Calculating the critical path and float values as described above.
• Critical Chain analysis: Adding resource constraints and buffer management as described above.
• What-If Scenario Analysis: Evaluating alternative scenarios (e.g., “What if Activity C takes 3 days longer than planned?” or “What if we can start Activity F two weeks earlier?”) to understand the schedule’s sensitivity to specific changes. Helps assess risk scenarios and evaluate recovery options.
• Monte Carlo Simulation: Assigning probability distributions to activity durations (instead of single-point estimates) and running thousands of simulated project completions to generate a probability distribution for the project end date. Answers questions like: “What is the probability of completing by the target date?” and “What date gives us a 90% confidence of completion?”
• Resource Optimization: Adjusting the schedule to align with resource availability (resource leveling and resource smoothing — detailed separately below).
• Schedule Compression: Applying crashing or fast-tracking to shorten the schedule (detailed separately below).

When to Use Schedule Network Analysis

• During initial schedule development, to generate and validate the project schedule model
• When evaluating the impact of proposed changes on the project schedule
• When recovering from a schedule delay — to identify which interventions are most effective
• When assessing schedule risk — particularly on projects with significant duration uncertainty
• When presenting schedule confidence levels to senior stakeholders or clients

Practical Application — What-If Scenario Analysis

A construction project has a 120-day critical path. The project manager needs to present three schedule scenarios to the client:

• Base case: All activities complete as estimated. Project finishes day 120.
• Optimistic scenario: Supplier delivery arrives 5 days early; concrete curing time reduced by updated technique. Project finishes day 113.
• Pessimistic scenario: Weather delay adds 8 days to outdoor activities on the critical path; regulatory approval takes 3 extra days. Project finishes day 131.

The scenario analysis reveals that the project schedule has an 11-day potential variation range (113–131 days). The project manager can now have an informed conversation with the client about schedule contingency, rather than presenting a single date as if it were certain.

5. Schedule Compression

What It Is

Schedule Compression refers to techniques that shorten the project schedule without reducing project scope. When a project is behind schedule, when the client imposes an earlier deadline, or when business urgency demands faster delivery, schedule compression techniques provide structured options for shortening the project duration.

PMBOK 8 identifies two primary schedule compression techniques: crashing and fast-tracking. Each has different mechanics, cost implications, and risk profiles.

Crashing

Crashing adds resources to critical path activities to shorten their duration. More resources doing the same work in less time — at increased cost. The goal is to achieve the maximum schedule reduction for the minimum additional cost.

How to crash a schedule:

1. Identify the critical path.
2. For each critical path activity, calculate the crash cost per time unit: (Crash Cost − Normal Cost) ÷ (Normal Duration − Crash Duration).
3. Rank critical path activities by crash cost per day (cheapest first).
4. Crash the cheapest critical path activity by the required amount.
5. Recalculate the critical path — crashing one activity may reveal a new, parallel critical path. Once a second path becomes critical, you must crash both paths simultaneously to continue reducing project duration.
6. Repeat until the target duration is achieved or the maximum crashable duration is reached.

Limitations of crashing:

• Not all activities can be crashed (adding more people to a code review doesn’t speed it up proportionally — Brooks’s Law: adding manpower to a late software project makes it later).
• Crashing increases cost. Beyond a certain point, the cost of further schedule compression exceeds the benefit.
• Crashing only works on critical path activities. Crashing a non-critical activity reduces its float but does not shorten the project.

Fast-Tracking

Fast-tracking overlaps activities that were originally planned in sequence — starting an activity before its predecessor is fully complete. No additional cost is added, but risk increases significantly because the downstream activity is started based on incomplete information from the upstream activity.

When to fast-track:

• When activities have a natural overlap that was conservatively modeled as sequential
• When the downstream activity can begin based on partial completion of the upstream activity (e.g., engineering drawings for Phase 2 can begin before Phase 1 drawings are 100% complete)
• When the team accepts the risk of rework if upstream changes require downstream activities to be redone

Limitations of fast-tracking:

• Increases rework risk — if the upstream activity produces changes after the downstream activity has started, rework may be required.
• Creates coordination complexity — overlapping activities require closer communication and management.
• Some activities genuinely cannot be overlapped (you cannot inspect a building foundation before it exists).

Crashing vs. Fast-Tracking at a Glance

When to Use Schedule Compression

• When the calculated project end date exceeds the required completion date
• When a project falls behind schedule and must recover lost time
• When a client or sponsor mandates an earlier delivery date after planning is complete
• Always analyze both techniques together and present the trade-offs to decision-makers

6. Leads and Lags

What It Is

Leads and lags are schedule modifiers applied to dependency relationships between activities to fine-tune the timing of when a successor activity can begin (or end) relative to its predecessor.

• Lag: A positive time delay added to a dependency relationship. The successor activity must wait a defined amount of time after the trigger condition is met. Example: in an FS relationship, a 3-day lag means the successor cannot start until 3 days after the predecessor finishes.
• Lead: A negative lag — an acceleration. The successor activity can begin before the trigger condition is fully met. Example: in an FS relationship, a 2-day lead (FS−2) means the successor can start 2 days before the predecessor finishes — an overlap.

Common Use Cases for Lags

• Curing and drying time: Concrete must cure for 7 days before loading (FS+7).
• Regulatory waiting periods: A permit application must be submitted and then a mandatory review period observed before construction begins (FS+21).
• Procurement lead time: Equipment ordered at the start of design must be received before installation begins — the lead time is the lag (FS+60).
• Software deployment stabilization: After deploying software, a 3-day stabilization period before parallel activities proceed (FS+3).

Common Use Cases for Leads

• Overlapping design and construction phases: In a building project, construction of Phase 2 can begin while Phase 1 is 80% complete — rather than waiting for full completion (FS−5).
• Test case design beginning during development: Test cases can be designed as soon as the functional specification is 70% written (SS+3 or FS−5).
• Documentation beginning before feature freeze: User documentation can start being drafted while 3 features are still in development (FS−5).

When to Use Leads and Lags

• Use lags when there is a mandatory waiting period between the completion of one activity and the start of another that represents real elapsed time (not unplanned work).
• Use leads when activities have a genuine overlap — when it is both logical and safe to begin the successor before the predecessor is fully complete.
• Scrutinize large lags (more than 2–3 days) — they often represent undocumented activities. A 10-day lag for “procurement lead time” should be replaced by an actual procurement activity on the schedule.
• Use leads deliberately and with awareness of rework risk — a lead assumes the predecessor’s partial output is stable enough to build upon.

Practical Example

A construction project plans the following sequence with leads and lags:

• Foundation Pour → Foundation Inspection: FS+3 (concrete curing lag)
• Foundation Inspection → Framing: FS+0 (inspection must pass before framing begins)
• Framing → Electrical Rough-In: SS+5 (electrical can start once framing is 5 days underway, not after framing is complete)
• Electrical Rough-In → Drywall: FS+0 (drywall cannot start until electrical rough-in is done)
• Drywall → Painting: FS+1 (joint compound must dry overnight)

The SS+5 relationship between Framing and Electrical Rough-In saves 8 days compared to a purely sequential FS schedule — a significant schedule compression without any additional cost or risk.

7. Rolling Wave Planning

What It Is

Rolling Wave Planning is an iterative planning technique in which near-term work is planned in detail, while future work is planned at a higher level of abstraction. The detailed planning horizon “rolls forward” as the project progresses — each new planning cycle elaborates the next wave of work while the current wave is executed.

The name comes from the analogy of ocean waves: you can see the wave immediately in front of you in clear detail, but waves in the distance are visible only as shapes, not details. As each wave passes, the next becomes visible and detailed.

Why Rolling Wave Planning Exists

On complex projects, it is neither possible nor productive to plan every activity in complete detail at the project’s outset. Future work depends on outcomes that are not yet known. Detailed plans for activities 6 months away will be obsolete before they are executed, because conditions will change. Rolling Wave Planning acknowledges this reality and designs the planning process accordingly.

When to Use Rolling Wave Planning

• Long-duration projects where future requirements are uncertain at the start
• R&D and innovation projects where each phase’s outcomes determine the next phase’s approach
• Projects using hybrid methodologies — predictive planning for near-term work, adaptive (Agile) planning for future work
• Any project where attempting to plan everything upfront would be a waste of effort because conditions will change
• Programs and large projects where the full scope is known at a summary level but detailed work packages are defined iteratively

How to Apply Rolling Wave Planning

1. Define the planning horizon: Typically 4–8 weeks of detailed planning at any given time, with 3–6 months of high-level planning beyond that.
2. Plan the near-term wave in detail: Decompose the next 4–8 weeks of work into activities with durations, resources, and dependencies. These activities are schedule-ready.
3. Plan future waves at a summary level: Represent future work as work packages or planning packages in the WBS — identified and estimated but not yet decomposed into activities.
4. Establish a rolling planning cadence: At each planning cycle (e.g., every 2 weeks), elaborate the next wave of work while executing the current wave.
5. Maintain schedule integrity: Ensure the high-level milestones and overall project duration are maintained even as detailed plans evolve. Rolling Wave Planning does not mean re-planning the entire schedule at every cycle.

Practical Example

A pharmaceutical research project is 18 months long. At project initiation:

• Months 1–2 (current wave): Fully detailed activities with durations, assigned resources, and dependencies. Executable immediately.
• Months 3–6 (next wave): Work packages identified, durations estimated at ±30%, resources identified but not yet assigned individually.
• Months 7–18 (future waves): Summary milestones only. Major phase boundaries identified. No activity-level detail — because the approach depends on clinical data not yet available.

At the Month 2 planning review, the team elaborates Months 3–4 into detailed activities and advances the planning horizon. The process repeats every 4 weeks for the project’s duration.

8. Logical Relationship

What It Is

A Logical Relationship defines the dependency connection between two schedule activities — specifically, how the timing of one activity constrains the timing of another. Logical relationships are the structural elements of the schedule network; without them, activities have no sequence and the schedule cannot be calculated.

Every arrow in a PDM network diagram represents a logical relationship. The type of the relationship (FS, SS, FF, or SF) specifies the nature of the constraint, and any lead or lag modifies the timing within that constraint.

Types of Logical Relationships

The four relationship types (fully described in the PDM section above) are:

• Finish-to-Start (FS): B cannot start until A finishes. Most common — 85%+ of relationships in a typical project network.
• Start-to-Start (SS): B cannot start until A starts. Used when activities are naturally parallel but one must initiate before the other.
• Finish-to-Finish (FF): B cannot finish until A finishes. Used when activities must conclude together.
• Start-to-Finish (SF): B cannot finish until A starts. Rare; used in shift handovers and technology cutovers.

Hard Logic vs. Soft Logic

This is a critical distinction for schedule analysis and compression:

• Hard Logic (Mandatory Dependencies): Dependencies that are inherent in the nature of the work and cannot be changed. Physical, technical, or legal constraints. You cannot test software before it is written. You cannot install electrical wiring before walls are framed. These constraints are non-negotiable.
• Soft Logic (Discretionary Dependencies): Dependencies based on best practices, preference, or convenience — but which could be changed if the schedule required it. “We usually test before deploying documentation, but if we had to, we could do both in parallel.” Soft logic is the primary target for fast-tracking and schedule compression.

During schedule development, explicitly label dependencies as hard or soft. When under schedule pressure, systematically review soft-logic relationships for fast-tracking opportunities before applying crashing (which increases cost).

When to Use — Practical Application

• Every time you build or update a schedule network, you are defining logical relationships.
• When analyzing a schedule delay, trace the delay through the network by following the logical relationships from the delayed activity forward to the project end date — this shows the cascade effect.
• When proposing schedule recovery, identify which soft-logic relationships can be converted to parallel execution (fast-tracking).
• During schedule risk assessment, identify which logical relationships are actually assumptions rather than hard constraints — these represent schedule risks if the assumption is wrong.

9. Dependency Determination and Integration

What It Is

Dependency Determination and Integration is the process of identifying, classifying, and documenting the dependencies between project activities — and then integrating those dependencies into a coherent schedule network that accurately reflects how the work must be sequenced.

PMBOK 8 frames dependency determination across two dimensions: the source of the dependency (mandatory vs. discretionary; internal vs. external) and the type of the dependency relationship (FS, SS, FF, SF). The combination of these dimensions gives project managers a complete framework for understanding and managing the constraints on their schedule.

The Four Dependency Attributes

1. Mandatory Dependencies (Hard Logic)

Dependencies that are inherent in the nature of the work. They cannot be altered without changing the fundamental approach to the work.

• Physical: Foundation before structure; structure before roofing.
• Technical: Code before test; data model before database build.
• Regulatory: Permit approval before construction; environmental clearance before excavation.

2. Discretionary Dependencies (Soft Logic or Preferred Logic)

Dependencies based on best practice, organizational preference, or risk management — but which could be modified under schedule pressure.

• “We always complete the design before ordering materials, but in a fast-track scenario we could place material orders based on preliminary design.”
• “We prefer to complete pilot testing before full rollout, but if the pilot findings are positive after 2 weeks, we could begin partial rollout before the pilot is formally closed.”

3. Internal Dependencies

Dependencies between activities within the project team’s control. The project team decides the sequence and can change it if the schedule demands.

4. External Dependencies

Dependencies involving activities or outputs outside the project team’s control — suppliers, regulators, other organizations, or other projects.

• Waiting for a vendor to deliver equipment before installation can begin.
• Waiting for regulatory approval before beginning clinical trials.
• Waiting for a parallel project to complete an interface before integration testing can start.

Integration Aspects

The “integration” component of this technique addresses two key challenges:

• Integrating external dependencies into the schedule: External dependencies are often the most significant schedule risks, because the project team has limited control over them. External dependencies should be identified early, tracked carefully, and buffered with schedule contingency. For each external dependency, assign an owner responsible for monitoring and escalating.
• Integrating dependencies across multiple projects (program-level): In programs or large organizations, project schedules often depend on outputs from other projects. A project cannot begin integration testing until a parallel infrastructure project completes its environment setup. These inter-project dependencies must be explicitly documented in both schedules, with a defined governance mechanism for resolving conflicts.

When to Use

• During Sequence Activities — the formal process of defining dependencies before scheduling.
• When managing external vendor or supplier relationships — tracking their schedule performance as a project dependency.
• When building schedules in a program environment — mapping inter-project dependencies.
• During schedule risk analysis — identifying which dependencies carry the highest risk of delay and planning contingencies accordingly.

Practical Example

A retail store opening project has the following dependency matrix:

The project manager identifies that the two external dependencies (Merchandise Delivery and Business License) are the primary schedule risks. For each, a risk response is developed: buffer time before the Grand Opening milestone, and an owner assigned to track and escalate each external dependency weekly.

10. Resource Optimization

What It Is

Resource Optimization techniques adjust the project schedule to align activity timing with resource availability. A CPM schedule assumes unlimited resources — it calculates dates based purely on activity logic. Resource Optimization adjusts those dates to reflect the reality that resources are finite and that multiple activities competing for the same resource cannot all proceed as logically scheduled.

PMBOK 8 describes two primary resource optimization techniques: Resource Leveling and Resource Smoothing.

Resource Leveling

Resource Leveling adjusts the project schedule when resources are over-allocated — when the logically-derived schedule demands more of a resource at a specific point in time than is actually available. Resource leveling delays activities to eliminate over-allocation, accepting schedule extension as the cost of staying within resource constraints.

When to use Resource Leveling:

• When specific resources are available only in limited quantities and the CPM schedule creates over-allocation peaks
• When the organization imposes hard resource constraints (a specialist is shared across multiple projects and has limited availability per week)
• When resource cost is fixed and adding more resources is not an option

How Resource Leveling works:

1. Plot the CPM schedule and overlay resource demand by time period.
2. Identify over-allocation peaks — time periods where resource demand exceeds availability.
3. Delay activities (starting with those with the most float) to shift resource demand to periods of availability.
4. The critical path may extend — resource leveling can lengthen the project duration.
5. Review the leveled schedule against project constraints and stakeholder expectations. Negotiate resource availability or scope if the extension is unacceptable.

Example: A project requires a database architect for 3 activities that all fall in the same 2-week window on the CPM schedule. The architect is available for only 1 full-time equivalent. Resource leveling sequences the 3 activities, extending that phase by 3 weeks — but eliminating the unrealistic assumption that the architect can be in three places at once.

Resource Smoothing

Resource Smoothing adjusts the schedule within the available float of activities to reduce resource demand peaks — without extending the project end date. Unlike resource leveling, resource smoothing does not extend the critical path; it operates within the float of non-critical activities.

When to use Resource Smoothing:

• When the project end date is fixed and cannot be extended
• When resource demand peaks are moderate — smoothable within available float
• When the goal is to achieve a more uniform resource demand profile (which reduces staffing costs and overtime)

Limitation of Resource Smoothing: It cannot always resolve all over-allocations. If an activity has no float, it cannot be delayed to smooth resource demand — it will remain on its calculated early dates. Resource smoothing is a best-effort optimization within schedule constraints, not a guarantee of full resource optimization.

Resource Leveling vs. Resource Smoothing

When to Use Resource Optimization

• After completing the initial CPM schedule development — always validate resource demands against availability before finalizing the schedule
• When updating the schedule during execution — as activities complete and new activities begin, resource demands shift and may create new over-allocation situations
• When planning across multiple projects in a portfolio — shared resources create inter-project over-allocation that must be managed at the program or portfolio level

11. Agile Release Planning

What It Is

Agile Release Planning is a scheduling technique used in adaptive (Agile) delivery environments to create a high-level plan for delivering a set of features or capabilities over a series of iterations (sprints). It bridges the gap between the product backlog (an unordered list of features) and the project schedule (a time-bounded delivery plan) — translating business value priorities into a realistic delivery roadmap.

Unlike traditional schedule techniques that plan activities in sequence with defined durations, Agile Release Planning plans value delivery in iterations, with the team’s velocity (the amount of work it can complete in a single sprint) as the primary sizing input.

Core Concepts

• Release: A meaningful increment of working product delivered to the customer. A release may contain one or more sprints.
• Sprint/Iteration: A fixed time-box (typically 1–4 weeks) during which the team develops a defined set of backlog items.
• Velocity: The number of story points (or other units) the team completes per sprint on average. Used to forecast how many sprints are needed to deliver a set of features.
• Product Backlog: The prioritized list of features, user stories, and work items to be delivered. The input to release planning.
• Epic: A large body of work (a major feature or capability) that spans multiple sprints and may span multiple releases.
• Release Goal: The business outcome or set of capabilities that the release is intended to deliver. Release planning is anchored to release goals, not to activity completion.

When to Use Agile Release Planning

• Projects using Scrum, SAFe, or other Agile frameworks where delivery is organized in sprints
• Product development projects where requirements evolve and the team needs flexibility to reprioritize between releases
• Hybrid projects where some work is best planned adaptively (new feature development) while other work is predictive (infrastructure, compliance)
• Any situation where you need to communicate a delivery roadmap to stakeholders without committing to a fully detailed traditional schedule

How to Apply Agile Release Planning — Step by Step

1. Define the release goal: What business outcome does this release need to achieve? The goal anchors all subsequent prioritization decisions.
2. Groom the product backlog: Ensure the backlog is prioritized (highest-value items at the top) and that items are estimated in story points or relative sizing.
3. Establish team velocity: Use historical sprint data for an established team, or use capacity-based estimation for a new team. Velocity is typically expressed as story points per sprint.
4. Identify release scope candidates: Working with the Product Owner, identify the minimum set of backlog items required to achieve the release goal. Group them into epics if the scope is large.
5. Calculate the number of sprints needed: Divide the total story points for the release scope by the team’s velocity. This gives the estimated number of sprints.
6. Build the release roadmap: Map epics and features to sprints on a timeline. Identify which capabilities will be available after each sprint and at each release milestone.
7. Identify dependencies and risks: Within the release plan, identify technical dependencies between features, external dependencies (integrations, approvals), and schedule risks.
8. Review and validate: Present the release plan to stakeholders. Confirm that the release goal is achievable within the planned timeframe and that stakeholder expectations are aligned.
9. Update each sprint: After each sprint, recalculate actual velocity, update the release forecast, and adjust the roadmap if needed.

Practical Example

A fintech startup plans a mobile banking app release. The team has a velocity of 30 story points per sprint (2-week sprints). The release backlog for the initial MVP contains 4 epics:

Total Must Have = 135 story points ÷ 30 velocity = 4.5 sprints → plan for 5 sprints (10 weeks) for the MVP release.

With Notifications included: 160 ÷ 30 = 5.3 sprints → plan for 6 sprints (12 weeks) for a full V1 release.

The release roadmap shows:

• Sprint 1–2: Account Dashboard complete
• Sprint 3–4: Transaction History complete + Fund Transfers in progress
• Sprint 5: Fund Transfers complete → MVP release (internal beta)
• Sprint 6: Notifications complete → V1 public release

Agile Release Planning vs. Traditional Schedule Planning

Comparison of All 11 Schedule Techniques

Putting It All Together: How the Techniques Work in Practice

In practice, these eleven techniques are not used in isolation — they work together as an integrated scheduling system. A typical project uses them in sequence:

1. PDM builds the network structure by defining activity sequences and dependency types.
2. Logical Relationship and Dependency Determination classify and validate every dependency — distinguishing hard from soft logic and internal from external constraints.
3. Leads and Lags fine-tune the network timing for activities with natural overlaps or mandatory waiting periods.
4. Schedule Network Analysis (including CPM) calculates dates, identifies the critical path, and models schedule risk scenarios.
5. Critical Chain Method may replace or supplement CPM in resource-constrained environments.
6. Resource Optimization adjusts the CPM schedule for real resource availability — converting the theoretically optimal schedule into a practically feasible one.
7. Schedule Compression is applied when the resource-optimized schedule still exceeds the required project duration.
8. Rolling Wave Planning governs how the schedule is elaborated over time — keeping near-term planning detailed and future planning flexible.
9. Agile Release Planning governs sprint-based delivery for adaptive components of hybrid projects.

The project manager’s skill lies not in knowing each technique individually, but in knowing which techniques to apply, in which combination, for the specific constraints and context of the project at hand.

See all PMBOK 8 topics in the Complete Guide Index

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.