IM Engineer Study Notes
← Back to list
Project & Org Management
#PERT#CPM#주공정법#여유시간#일정단축
Last updated · 2026-09-30

PERT/CPM (Schedule Network Analysis · Critical Path Method)

1. Overview

A. Definition

PERT/CPM is a schedule network analysis technique that represents a project's activities and their precedence relationships as a network (graph) and, using each activity's duration, derives float and the critical path through forward and backward passes, thereby quantitatively computing the shortest completion time and the control priorities of the overall schedule. CPM (Critical Path Method) is a deterministic technique that treats activity durations as fixed values, whereas PERT (Program Evaluation and Review Technique) is a probabilistic technique that treats durations with a 3-point estimate.

The fundamental reason these techniques are powerful is that they clearly identify "which tasks, if delayed, delay the entire project." A project has tens to hundreds of activities interwoven in parallel and in series, so simply listing activities and durations does not reveal "where management resources should be concentrated right now." PERT/CPM structures the dependencies among activities as a network and finds the longest path (the critical path), thereby identifying the small set of key activities directly tied to schedule slippage. Activities on the critical path have zero float, so a single day of delay slips the project by exactly one day, while activities off the critical path can slip within their float without affecting the overall schedule. Managers allocate resources and oversight selectively based on this distinction.

B. Background and Necessity

The two techniques were born almost simultaneously in the late 1950s, but from different motivations. CPM was developed in 1957 by Kelley & Walker at DuPont and Remington Rand to jointly optimize the duration and cost of repetitive projects whose durations and costs are relatively well known, such as periodic maintenance and construction of chemical plants. By contrast, PERT was devised in 1958 for the U.S. Navy's Polaris submarine missile program, to handle the uncertainty of novel research and development (R&D) projects where thousands of activities are entangled and durations are hard to fix. That is, CPM started from "cost-duration trade-off" and PERT from "schedule uncertainty management," two distinct problem framings; but today they share the common backbone of network analysis and are often treated together as "PERT/CPM."

The reason this technique is necessary is that the larger and more activity-rich a project is, the more impossible it becomes to predict completion time and bottlenecks by intuition and experience alone. With even a few dozen activities, path combinations explode, and it is common for "a task that feels urgent" to actually be a non-critical activity with large float, while a quietly progressing task turns out to be on the critical path. PERT/CPM strips away such illusions and provides a quantitative basis for establishing the schedule baseline, controlling progress, leveling resources, and making schedule-compression decisions. The PMBOK also treats this technique as a core tool of the schedule management knowledge area, in the flow "sequence activities → estimate durations → develop schedule."

C. Key Characteristics

The first characteristic of PERT/CPM is that it is a dependency-based structural analysis. Because activities are connected by precedence logic rather than merely listed, one can trace how a delay in one activity propagates to which successor activities. For example, if requirements analysis is delayed by 3 days, one can judge on the diagram whether its successors—design, development, testing—slip in a chain, or whether the delay is absorbed within the float of parallel work. Second, it provides a quantitative control metric called float. By computing each activity's Total Float and Free Float, it assigns management priorities numerically, so resources can be allocated to "the work that actually determines the completion date" rather than "work that feels urgent."

Third, it becomes the foundation for what-if analysis. Because one can immediately confirm through network recalculation how the completion date changes when durations are altered or activities are parallelized, it supports schedule-compression (Crashing/Fast Tracking) decisions. Fourth, it creates a common language for communication and control. Because the critical path, milestones, and float are shared as a single diagram, the client, PM, and field staff discuss progress on the same basis and, when delays occur, can objectively negotiate accountability and recovery measures. However, all these characteristics hold only on the premise that activity definition and duration estimation are accurate, and one must also recognize the limitation that a pure network not reflecting resource constraints may diverge from the actual executable schedule.

2. Overall Structure and Components

Schedule network analysis proceeds as a sequence in which work decomposed by the WBS is defined as activities and sequenced, then a network is constructed to derive the critical path, and, if needed, the schedule is compressed. Below is the overall structure diagram.

flowchart TD
  WBS["WBS(Work Breakdown Structure)"] --> ACT["Activity Definition"]
  ACT --> SEQ["Sequence Activities(set dependencies)"]
  SEQ --> EST["Estimate Durations"]
  EST --> NET["Build Schedule Network(AON/AOA)"]
  NET --> FWD["Forward Pass(ES·EF)"]
  FWD --> BWD["Backward Pass(LS·LF)"]
  BWD --> FLOAT["Compute Float"]
  FLOAT --> CP["Identify Critical Path"]
  CP --> BASE["Confirm Schedule Baseline"]
  CP --> COMP["Schedule Compression(Crashing/Fast Tracking)"]
  COMP --> NET

Looking at the components in order: first, an Activity is a unit of work consuming resources and time, obtained by further dividing the lowest-level work package of the WBS into executable units. An Event/Node is the instant marking an activity's start or end and consumes no time. A Dependency is a logical precedence constraint between activities, divided into a mandatory dependency that must be observed (hard logic), a discretionary dependency chosen by convention (soft logic), and an external dependency due to external factors. Duration is the time it takes to complete each activity.

Meanwhile, a Milestone, a special activity with zero duration, is used to mark important control points such as a contract, an approval, or the completion of a phase; it involves no actual work but serves to make agreement points with stakeholders explicit in the network. Placing a milestone on the critical path contractually emphasizes the fact that "if this approval is late, the project is late by exactly that much."

There are two notations for putting activities into a diagram. AON (Activity-on-Node, PDM) represents activities as rectangular nodes and dependencies as arrows, and is the standard adopted by most of today's PM tools (MS Project, Primavera P6). AOA (Activity-on-Arrow, ADM) is the classic style that represents activities as arrows and events as nodes; because it requires a Dummy Activity with no actual work to make the logic consistent, it is rarely used now. PDM subdivides the relationships among activities into four types.

Dependency type Meaning Example
FS (Finish-to-Start) Successor starts after predecessor finishes (most common) Start development after design is complete
SS (Start-to-Start) Successor may start once predecessor starts Start piping soon after excavation begins
FF (Finish-to-Finish) Successor may finish only after predecessor finishes Finish documentation after testing ends
SF (Start-to-Finish) Successor may finish only after predecessor starts (rare) Retire old system after new system goes live

To this, a Lead (overlap) and a Lag (wait) are added to refine the relationship. For instance, "FS + 2-day Lag" means the successor starts after waiting 2 days following the predecessor's finish, modeling real constraints such as concrete curing or awaiting approval. Conversely, "FS − 3-day Lead" means the successor can start 3 days before the predecessor finishes, expressing an overlap in which development begins on the confirmed portions before the design is entirely complete.

The reason AON became the standard should also be understood in a practical context. AOA had to insert dummy activities to distinguish two activities that share the same start/end events but have different logic; as the network grew, dummy activities proliferated, making drafting and interpretation cumbersome. AON places activities as nodes and expresses only relationships as arrows, so no dummy activities are needed and FS·SS·FF·SF and Lead/Lag can be naturally accommodated, which was advantageous for computerization. For this reason, virtually all commercial schedule-management tools today adopt AON (PDM).

3. Critical Path Calculation Procedure (Forward and Backward Passes)

The core of deriving the critical path is to compute each activity's earliest start/finish (ES·EF) and latest start/finish (LS·LF) and connect the activities whose difference—the float—is zero. The calculation proceeds in two directions.

The Forward Pass proceeds from the start of the network to the end, computing ES (Early Start) and EF (Early Finish, = ES + duration). An activity's ES is the maximum of the EFs of all predecessor activities (since it starts only when all predecessors finish). Computing this to the end, the EF of the last activity becomes the shortest project completion time. The Backward Pass, conversely, proceeds from the end to the start, computing LF (Late Finish) and LS (Late Start, = LF − duration). An activity's LF is the minimum of the LSs of all successor activities (since it must align with the earliest of its successors).

Once both passes are done, Total Float (TF) = LS − ES = LF − EF is computed. TF is the maximum time an activity can be delayed without pushing back the project completion date. Free Float (FF) is the time an activity can be delayed without pushing back the ES of successor activities, computed as "minimum ES of successor activities − EF of the activity." The Critical Path is the continuous path of activities with TF = 0; it is the longest path in the network and the path that determines the completion time.

Intuitively, the forward pass asks "if we start as early as possible, when does each activity finish," and the backward pass asks "to keep the completion date, by when at the latest must each activity finish." The reason the forward pass uses "the maximum of predecessor EFs" is that a successor starts only when all predecessors are complete, and the reason the backward pass uses "the minimum of successor LSs" is that the overall schedule is kept only by aligning with whichever successor must start earliest. The values from the two directions meet to form the float, and the points where that float is zero become the critical path with no room for delay.

The calculation is made concrete with the example network below. Starting from activity A (3 days), it branches to B (4 days) and C (2 days); B leads to D (5 days) and C leads to E (6 days), then they merge at F (2 days).

flowchart LR
  START(("Start")) --> A["A (3 days)"]
  A --> B["B (4 days)"]
  A --> C["C (2 days)"]
  B --> D["D (5 days)"]
  C --> E["E (6 days)"]
  D --> F["F (2 days)"]
  E --> F
  F --> END(("End"))

There are two paths. "A→B→D→F" is 3+4+5+2 = 14 days, and "A→C→E→F" is 3+2+6+2 = 13 days. Therefore the shortest completion time is 14 days and the critical path is A-B-D-F. Organizing the forward/backward pass results and float in a table gives the following.

Activity Duration ES EF LS LF TF Critical
A 3 0 3 0 3 0 ●
B 4 3 7 3 7 0 ●
C 2 3 5 7 9 4
D 5 7 12 7 12 0 ●
E 6 5 11 9 12 4
F 2 12 14 12 14 0 ●

C and E have 4 days of float, so even if delayed by up to 4 days they do not affect the project completion date (14 days), whereas A·B·D·F have zero float and even a single day's delay directly pushes back the completion date. From this one table, the manager immediately draws the conclusion "concentrate oversight on A-B-D-F, and there is room to reallocate resources from C·E."

The distinction between total float and free float also matters in practice. Total float is "the limit that does not push back the project completion date," while free float is "the limit that does not push back the start of the immediate successor." In the example above, activity E's free float is the successor F's ES (12) − E's EF (11) = only 1 day. That is, even though E has 4 days of total float, if it is delayed beyond one day it begins to push successor F, so among the same non-critical activities, one whose free float is small must be controlled with greater intensity. Differentiating control intensity by distinguishing the kinds of float is the essence of refined schedule control beyond mere critical-path identification.

4. PERT's Probabilistic Estimation and Comparison with CPM

Whereas CPM sees duration as a single fixed value, PERT explicitly models uncertainty. For each activity, three values—Optimistic (O), Most likely (M), Pessimistic (P)—are estimated, and, assuming a beta distribution, the expected duration te = (O + 4M + P) / 6, standard deviation σ = (P − O) / 6, and variance σ² = ((P − O)/6)² are computed. For example, if a design activity is estimated as O=4 days, M=6 days, P=14 days, then te = (4 + 24 + 14)/6 = 7 days, σ ≈ 1.67 days, σ² ≈ 2.78. Note that although the most likely value is 6 days, the long pessimistic tail stretches the expected duration to 7 days.

The reason different weights are placed on the three values also deserves note. The coefficient (O + 4M + P)/6 approximates the mean of the beta distribution; since in practice values near the most likely (M) appear most frequently, it is given a 4× weight, while the extreme optimistic and pessimistic values are reflected only 1× each. Taking the standard deviation as (P − O)/6 is an approximation exploiting the property that, in a normal distribution, the mean ± 3σ covers about 99.7% of the whole (range = 6σ). Therefore, the wider the gap between the optimistic and pessimistic values, the greater that activity's uncertainty (variance), which becomes the source of completion-date risk.

PERT's true value is that it enables probabilistic statements about the completion date. After summing the te of activities on the critical path to get the project's expected duration, and summing the variances (approximated by a normal distribution on the basis of the central limit theorem) to get the overall standard deviation, standardizing with Z = (target date − expected duration) / σ yields an answer such as "the probability of finishing within the target completion date is about X%." For instance, for a project with an expected duration of 100 days and a standard deviation of 5 days, the probability of finishing within 110 days is Z = (110−100)/5 = 2.0, i.e., about 97.7%. This is a powerful basis for quantitatively presenting to management "how many buffer days are needed to secure the target confidence level."

Looking at a real industry case, in a large SI project, requirements analysis, architecture design, core module development, and integration testing usually form the critical path, while activities such as screen UI or documentation often belong to non-critical work with large float. If the PM here focuses on screen progress rate but misses building the integration test environment (on the critical path), the go-live schedule slips accordingly. Conversely, unprecedented R&D such as a new drug or a satellite has large uncertainty in activity durations, so instead of a single value, one must present completion probability via a 3-point estimate for management to accept launch-timing risk. Thus, even with the same network backbone, the choice between CPM and PERT diverges according to the nature of the project.

The fundamental cause of the difference between the two techniques lies in the nature of the target project. CPM suits repetitive, construction-type projects whose durations are stably known and is strong at cost-duration optimization, while PERT suits R&D and new-product development where there is no precedent and durations cannot be fixed. As a practical implication, imposing the burden of 3-point estimation on a stable project is a waste, and conversely, using a single fixed value on a highly uncertain project underestimates the schedule risk.

Category CPM (Critical Path Method) PERT
Duration estimation Single fixed value (deterministic) 3-point estimate (probabilistic)
Focus Cost-duration trade-off Schedule uncertainty · completion probability
Suitable projects Repetitive · construction · maintenance Novel R&D · non-repetitive projects
Time vs. cost Both considered Time-centric
Representative case DuPont plant maintenance (1957) Polaris missile (1958)

Schedule compression is easier to grasp when made concrete with the earlier example. Suppose the critical path A-B-D-F (14 days) must be reduced to 12 days. If each activity's cost slope is B = KRW 200,000/day, D = KRW 150,000/day, F = KRW 300,000/day, then one shortens starting with the cheapest, D, by 1 day (KRW 150,000), and shortens by another day whichever of D or B has the lower slope, achieving 2 days total at minimum cost (e.g., 15+15 = KRW 300,000 or 15+20 = KRW 350,000). However, if D is shortened excessively, the parallel path A-C-E-F (13 days) rises as the new critical path, so at each step of compression the network must be recalculated to reconfirm which path dominates the completion date. Omitting this procedure results in the waste of pouring cost into "an activity that is no longer on the critical path."

Schedule Compression is a representative use of critical-path analysis. Crashing adds resources (labor/cost) to critical-path activities to reduce duration, shortening from the activity with the smallest "Cost Slope = (crash cost − normal cost)/(normal duration − crash duration)" to meet the target duration at minimum cost. Fast Tracking reduces duration by overlapping in parallel activities originally done sequentially, but increases rework and risk. Both techniques are effective only when applied strictly to the critical path; shortening a non-critical activity is meaningless as it does not affect the completion date. Note that as one shortens the critical path, a "critical-path shift" occurs in which another path becomes the new critical path, so recalculation is needed at every step.

5. Advanced: Monte Carlo Simulation and Modern Extensions

Traditional PERT has the limitation that it "performs probabilistic analysis on only a single critical path." In reality, a non-critical path can become critical at any time depending on activity delays (path convergence/merge bias), and ignoring this optimistically overestimates the completion probability. The modern alternative that overcomes this limitation is Monte Carlo Simulation. After defining each activity's duration as a probability distribution such as triangular, beta, or PERT, thousands to tens of thousands of random samples are drawn, the entire network is recalculated at each iteration, and the distribution of the completion date and the frequency with which each activity is on the critical path (the Criticality Index) are computed. For example, if an activity's Criticality Index is 80%, it means "it is on the critical path in 80% of all scenarios," providing a far more realistic risk priority than a single deterministic analysis. Tools such as Primavera Risk Analysis, @RISK, and Safran Risk support this, and it is used as standard in the quantitative Schedule Risk Analysis of large EPC and SI projects.

A representative trap that Monte Carlo reveals is the aforementioned Merge Bias. When multiple paths meet at a single merge point, the completion date is dominated by "the path that finishes latest" among them. Even if each path has, on average, a 50% probability of finishing on time, because both paths must finish on time for the merge to happen on time, the probability that the merge point is on time plunges to 0.5 × 0.5 = 25%. Deterministic CPM cannot see this effect and overestimates the completion probability, whereas Monte Carlo reproduces it exactly through tens of thousands of simulations to present a realistic completion-date distribution. Hence, the more a project has several near-critical paths with small float, the greater the value of simulation-based analysis.

Another extension is the Critical Chain Project Management (CCPM) based on the Theory of Constraints (TOC). Whereas traditional CPM ignores resource constraints and handles only logical dependencies, CCPM defines a "critical chain" that also considers resource contention, removes the safety margin hidden in individual activities, and gathers it at the project's tail end to manage as a project buffer (for details see [[critical-chain-project-management]]). In agile/hybrid environments, as sprint-unit iteration becomes the main rhythm, the weight of detailed networks has decreased, but network logic and the critical-path concept are still used at the level of release planning, milestone dependency management, and the SAFe roadmap of large programs. In fact, MS Project, Primavera P6, Jira Advanced Roadmaps, and others provide dependency and critical-path highlighting as standard features.

6. Considerations and Implications

First, estimate quality governs analysis reliability (Garbage In, Garbage Out). No matter how sophisticated the network, if activity durations and dependency estimates are poor, the critical path and completion date are distorted. Estimation governance must be in place that combines historical data of similar projects, expert judgment, and 3-point estimation, and that guards against optimism bias and the student syndrome.

Second, resource constraints must be viewed together. Pure CPM assumes infinite resources, so in theory the critical path and the actually executable schedule may diverge. Applying resource leveling changes the critical path or extends the completion date, so a strategy is needed that integrates network analysis with resource management and complements it with CCPM and resource-constrained scheduling.

Third, the critical path is not fixed but shifts dynamically. Because the critical path changes frequently with progress, delays, and compression, one should not finish with a single calculation at initiation but recalculate periodically (re-analyze after reflecting progress). Monitoring near-critical paths (paths with small float) together to proactively manage latent risk is a practical strategy from the professional engineer's perspective.

Fourth, compression decisions are a trade-off among cost, quality, and risk. Crashing increases cost, and Fast Tracking increases rework and quality risk. One should compress step by step starting from activities with low cost slope, reconfirm the critical-path shift at each step, and comprehensively judge whether the compression spreads into downstream risk (overwork, quality degradation).

Fifth, manage the schedule integrated with other performance areas. Critical-path analysis shows its true value when combined with the Schedule Performance Index (SPI) of EVM (Earned Value Management). When SPI worsens, one must distinguish via the network whether the cause is a delay in a critical-path activity or a problem in a non-critical activity to produce an accurate recovery measure (see: [[earned-value-management]]).

Sixth, select the fitness of tools and methods to project characteristics. For repetitive/construction types, CPM+Crashing; for highly uncertain R&D, PERT+Monte Carlo; where resource contention is severe, CCPM; and for software with large requirement volatility, a hybrid with agile is effective. Looking ahead, AI schedule prediction based on performance data will be combined with Monte Carlo simulation, evolving into intelligent schedule management that updates completion probabilities and risk activities in real time.

References

In one line: PERT/CPM is a schedule analysis technique that connects activities into a network and derives float and the critical path through forward and backward passes; CPM excels at deterministic cost-duration optimization and PERT at 3-point-estimate-based probabilistic completion prediction, extended by Monte Carlo and CCPM.