Schedule (Project Management)

In project management, a schedule is the plan that says what work will be done, in what order, by whom, and when. At its simplest it is a list of a project's milestones, activities, and deliverables with start and finish dates. In practice, a useful schedule is more than a list of dates: it is a model of the project in which each task has a duration, depends on other tasks, and is assigned resources, so that when one thing slips, the effect on everything else can be calculated.

Schedules are at the center of project planning and project portfolio management. They tell teams what to work on next, tell managers whether the project is on track, and tell sponsors when they can expect results. A schedule that is built well and kept current is one of the most powerful management tools a project has. A schedule that is built once for approval and then ignored is one of the most common reasons projects are surprised by their own lateness.

This article explains what a schedule contains, where modern scheduling methods came from, how the critical path method and PERT work (with fully worked examples), how schedules are tracked against a baseline, what makes a schedule reliable according to U.S. government auditors, and the pitfalls and misconceptions that trip up planners.

What a schedule contains

The Wikipedia article on project schedules describes the basic contents: milestones, activities, and deliverables, with dependencies and resources defined for each task, and start and finish dates estimated from resource allocation, budget, task duration, and scheduled events. Schedule elements are often tied to the terminal elements of the work breakdown structure (WBS), to the statement of work, or to a contract data requirements list.

Before a schedule can be built, three inputs are usually needed:

• A work breakdown structure, which divides the project's total scope into deliverable-oriented pieces.
• An effort estimate for each task.
• A resource list, with each resource's availability.

If any of these is missing, the article notes they can be created with a consensus estimating method such as Wideband Delphi.

The key building blocks of a schedule are:

Dependency types

Most scheduling tools support four types of logic links:

Finish-to-start is by far the most common and the easiest to understand. Links can also carry a lag (a waiting time, such as "start B three days after A finishes") or a lead (a negative lag, letting B start before A finishes). Auditors generally view heavy use of leads and lags with suspicion because they hide work and make schedules harder to analyze, as described in the section on schedule quality checks below.

What a schedule is for

The Wikipedia article lists several purposes: showing how the work will be done, committing people to tasks, determining resource needs, and serving as a checklist. It describes the schedule as a calendar that links tasks to the resources that will do them and calls it the core of the project plan. It also recommends regular updates, with weekly updates described as best, and redistributing remaining effort among team members while accounting for vacations. In engineering and construction, a full-time scheduler or scheduling team often maintains the schedule, depending on the size and scope of the project.

A short history of scheduling

Bar charts: Adamiecki, Schürch, and Gantt

The bar chart is the most familiar way to display a schedule. According to the Wikipedia article on Gantt charts, the Polish engineer Karol Adamiecki developed the first known tool of this kind in 1896, which he called a harmonogram. He published only in Polish and Russian, which limited its spread. In 1912, Hermann Schürch published chart-like visuals for a construction project, though they did not show dependencies.

Henry Gantt (1861 to 1919) designed his charts around 1910 to 1915, originally to measure worker productivity and identify under- or over-performance. The United States used Gantt charts during World War I at the instigation of General William Crozier. In 1922, Wallace Clark published The Gantt Chart: A Working Tool of Management, which spread the technique, and in 1929 Gantt's collaborator Walter Polakov introduced the charts to the Soviet Union during the First Five-Year Plan.

A Gantt chart lists tasks on the vertical axis and time on the horizontal axis, with a bar for each task whose length shows its duration. Modern Gantt charts can also show dependencies as lines between bars, although linked Gantt charts quickly become cluttered. Gantt charts remain popular because they are easy to read without training.

The critical path method at DuPont and Remington Rand

The critical path method (CPM) was developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley Jr. of Remington Rand. Patrick Weaver's history of scheduling, published by Mosaic Projects, gives a detailed account. DuPont had one of the first UNIVAC computers installed in a commercial business, and DuPont management saw planning, estimating, and scheduling as a good use for it, and Walker was given the job of finding out whether the computer could be programmed to help. On 7 May 1957, a meeting in Newark, Delaware, committed US$226,400 to developing the method, with DuPont contributing $167,700 and Remington Rand Univac contributing $58,700. Kelley, a mathematician, developed the solution, which borrowed from linear programming. The method was trialled on plant shutdowns in 1957, and Kelley and Walker presented their paper "Critical-path planning and scheduling" at the Eastern Joint Computer Conference in Boston in December 1959.

Weaver's history notes that Kelley and Walker originally called the longest path the "main chain" and that the name "critical path" came from the PERT team. The method was initially known as the "Kelley-Walker method" and was popularized as CPM partly through Jim O'Brien's 1964 book CPM in Construction Management. The original CPM computer program is long gone, but the term is now used for any approach that analyzes a project's network of logically linked activities.

PERT and the Polaris program

At almost the same time, the U.S. Navy's Special Projects Office, working with Lockheed Aircraft and the consulting firm Booz Allen Hamilton, developed the Program Evaluation and Review Technique (PERT) to manage the Polaris submarine-launched ballistic missile program. According to Wikipedia, PERT was first made public in 1958 in two Navy reports, initially under the name "Program Evaluation Research Task," and was renamed by 1959. Willard Fazar described its main ideas in The American Statistician in 1959.

PERT's distinctive feature was its treatment of uncertainty. Instead of a single duration for each activity, it used three estimates (optimistic, most likely, and pessimistic) to calculate an expected duration and a measure of spread. Weaver's history notes that when the first Polaris missile was launched in 1960, PERT was credited with saving two years, but also records the view of Russ Archibald, who ran PERT at Aerojet-General on part of the program, that PERT got undeserved credit and that the program's success owed more to the leadership of Admiral "Red" Raborn. An early non-military use of PERT was the planning of the 1968 Winter Olympics in Grenoble, which used it from 1965.

Precedence diagramming

Early CPM and PERT networks used the arrow diagramming method, in which activities are arrows between event nodes. In 1961, Dr. John Fondahl of Stanford University published A Non-Computer Approach to the Critical Path Method for the Construction Industry, the result of research commissioned in 1958 by the U.S. Navy's Bureau of Yards and Docks. Weaver's history says the report sold over 20,000 copies. Fondahl's approach placed activities in nodes connected by lines, which became the precedence diagramming method (PDM). A similar method, the Metra Potential Method, was developed independently in 1958 by B. Roy with METRA Consultants of France. Precedence systems eventually supplanted arrow diagrams in the 1970s, and Wikipedia notes that most current project management software uses a calculation approach developed by Fondahl.

The personal computer era

Scheduling moved from mainframes to desks in the 1980s. The IBM PC was launched in 1981. Primavera was founded in May 1983 by Dick Faris, Joel Koppelman, and Les Seskin. Weaver's history lists many PC scheduling tools of the era, including Microsoft Project, Open Plan, TimeLine, and SuperProject. It also argues that cheap PC tools spread a belief that "anyone can schedule," producing a long training gap in professional scheduling skills.

Critical chain

In 1997, Eliyahu M. Goldratt introduced critical chain project management in his book Critical Chain, applying his theory of constraints to projects. Critical chain treats resource availability as well as logic as a constraint on the schedule, removes safety margins from individual tasks, and pools them into buffers that are managed explicitly.

Summary timeline

How the critical path method works

CPM takes a list of activities, their durations, and their dependencies, and calculates:

• the earliest each activity can start and finish,
• the latest each activity can start and finish without delaying the project,
• the float (slack) of each activity, and
• the critical path, the longest chain of dependent activities, which determines the shortest possible project duration.

The calculation has two passes.

Forward pass. Start at the beginning. Each activity's early start (ES) is the latest early finish of its predecessors (zero for the first activity). Its early finish (EF) is its early start plus its duration.

Backward pass. Start at the end. The project finish is the largest early finish. Each activity's late finish (LF) is the earliest late start among its successors (or the project finish for the last activities). Its late start (LS) is its late finish minus its duration.

Total float is LS minus ES (equivalently, LF minus EF). It is how long an activity can slip without delaying the project. Free float is how long an activity can slip without delaying the early start of any successor. Activities with zero total float are critical; together they form the critical path.

Worked CPM example

This example is hypothetical. A small team is building a backyard workshop. Durations are in working days.

Forward pass (day numbers count completed days, so an activity with ES 3 begins at the start of day 4):

The project takes 31 working days.

Backward pass:

Float:

The critical path is A, D, E, F, H, I: 3 + 7 + 6 + 8 + 5 + 2 = 31 days. Check: free float for B is the early start of its successor E (10) minus B's early finish (8), which is 2. For C, F's early start (16) minus C's early finish (7) is 9. For G, I's early start (29) minus G's early finish (28) is 1.

What the numbers mean for the team:

• The permit (D) drives the project. It is on the critical path, so every day it slips adds a day to the finish.
• Ordering materials (C) has nine days of float. It can wait or slip without consequence, as long as it does not slip more than nine days.
• Design (B) has only two days of float. It is not critical, but it is close.
• Electrical (G) has one day of float, so it is near-critical; a two-day slip there would make it critical and delay the project by a day.

Shortening the schedule: crashing and fast-tracking

Suppose the owner wants the workshop done in 29 days. There are two standard approaches, both named in the Wikipedia article on CPM:

• Crashing adds resources to shorten critical activities, usually at extra cost.
• Fast-tracking performs activities in parallel that were planned in sequence, usually at extra risk.

Say the permit can be expedited from 7 days to 5 for a fee. Recalculating: D now finishes at day 8. E's early start becomes the later of B (8) and D (8), which is 8, so E finishes at 14, F at 22, H at 27, and I at 29. The project is two days shorter, which meets the goal.

But look at B now. B finishes at 8 and E starts at 8, so B's total float has dropped from 2 to 0. There are now two critical paths: A, B, E, F, H, I and A, D, E, F, H, I. Any further crashing of D would achieve nothing unless B is also shortened. This is the general lesson of crashing: shortening the critical path can make other paths critical, and the benefit stops as soon as a parallel path catches up.

The CPM literature calls the amount a critical activity actually extends the project its drag. In the original plan, D's drag was 2 days, because shortening it by more than 2 days would only bring the A, B, E path up to equal length. Knowing drag tells managers how much they can gain from speeding up a particular activity before another path takes over.

Resource leveling

The basic CPM calculation assumes unlimited resources. In reality, if electrical (G) and plumbing (H) both need the same contractor, they cannot happen at the same time. Resource leveling delays activities to resolve such conflicts, which can lengthen the project and make a different path "resource critical." Resource smoothing adjusts activities only within their available float, so it does not change the end date. Critical chain project management takes this further by treating resource dependencies as part of the critical chain from the start.

How PERT handles uncertainty

PERT replaces each single duration with three estimates:

• o: optimistic duration
• m: most likely duration
• p: pessimistic duration

The expected duration is:

t_e = (o + 4m + p) / 6

and the standard deviation of an activity's duration is estimated as:

σ = (p − o) / 6

For a path, the expected durations add, and so do the variances (σ squared), so the path's standard deviation is the square root of the sum of the activity variances. These are the formulas given in Wikipedia's PERT article.

Worked PERT example

Continuing the hypothetical workshop project, suppose the team gives three-point estimates for the critical path activities:

The expected duration of the critical path is 31 days, matching the CPM result. The path's standard deviation is the square root of 4.333, about 2.08 days.

Two observations stand out. First, the permit's most likely duration is 6 days, but its expected duration is 7, because its pessimistic estimate (14 days) is far from the most likely value. Skewed risks pull the expected value later. Second, the permit contributes 2.778 of the 4.333 total variance, about 64 percent. Most of the schedule uncertainty comes from one activity, which tells the team where risk reduction would pay off most.

If we assume, as classic PERT does, that the total path duration is roughly normally distributed, we can estimate the probability of finishing by a target date:

This shows why promising the "expected" date is risky: by definition, there is about a 50 percent chance of missing it.

Limits of classic PERT

Classic PERT analyzes only the critical path. But in this example, activity B sits on a path with only two days of float, and G has one. If B or G also run late, a different path can become critical. When several paths run in parallel and merge, the probability that all of them finish on time is lower than the probability for any single path, so analyzing only the critical path tends to be optimistic. This "merge bias" is one reason modern practice uses Monte Carlo simulation, which samples durations for every activity many times and builds a distribution of project finish dates across all paths. GAO's best practices call for a schedule risk analysis of this kind.

Wikipedia's PERT article also lists more practical disadvantages: networks for large projects can include hundreds or thousands of activities, do not scale down well to small projects, can require several pages to print, and usually lack a time scale, which makes status harder to see.

The schedule baseline and progress tracking

The baseline

Once a schedule is approved, a copy is saved as the baseline. The live schedule is then updated with actual progress, and the two are compared. Without a baseline, there is no way to tell how much the plan has changed or how far performance has drifted from it. Maintaining a baseline schedule is one of GAO's ten best practices.

Updating the schedule

Updating means recording actual start and finish dates, remaining durations for work in progress, and any changes in logic, then recalculating. GAO's best practices call for updating the schedule using actual progress and logic, which means not simply typing new dates over old ones but letting the logic network calculate the consequences of what actually happened.

Earned value management

Earned value management (EVM) combines scope, schedule, and cost into a single performance measurement system. It emerged in U.S. government programs in the 1960s; the Department of Defense established the Cost/Schedule Control Systems Criteria (C/SCSC), a set of 35 criteria, in 1967, and the industry standard ANSI/EIA-748-A, with 32 criteria, was published in May 1998.

EVM uses three basic quantities:

• Planned value (PV): the budgeted value of the work scheduled to be done by now.
• Earned value (EV): the budgeted value of the work actually completed by now.
• Actual cost (AC): what the completed work actually cost.

From these, the schedule and cost measures are:

Worked EVM example

This example is hypothetical. A project has a budget at completion (BAC) of $100,000. At the end of week 6:

• The plan called for $40,000 of work to be done: PV = $40,000.
• Work actually completed is worth $32,000 at budgeted rates: EV = $32,000.
• The completed work actually cost $36,000: AC = $36,000.

Then:

• SV = 32,000 − 40,000 = −$8,000 (behind schedule)
• SPI = 32,000 ÷ 40,000 = 0.80 (completing work at 80 percent of the planned rate)
• CV = 32,000 − 36,000 = −$4,000 (over budget)
• CPI = 32,000 ÷ 36,000 = 0.889
• EAC = 100,000 ÷ 0.889 = $112,500 (100,000 × 36 ÷ 32)

At current efficiency, the project is forecast to cost $12,500 more than budgeted and is behind schedule.

A known weakness, and Earned Schedule

Schedule variance in traditional EVM is measured in money, not time, and it has a well-known flaw. When a project finishes, all planned work is complete, so EV equals PV, SV becomes zero, and SPI becomes 1.0, even if the project finished months late. In 2003, Walter Lipke introduced Earned Schedule in an article titled "Schedule Is Different" in The Measurable News, published by PMI's College of Performance Management. Earned Schedule measures schedule performance in units of time, SV(t) and SPI(t), and avoids the end-of-project distortion.

EVM also does not know about the critical path. A project can earn value quickly by doing easy non-critical work while the critical path slips, so EVM indicators should be read alongside critical path analysis, not instead of it.

What makes a schedule reliable

GAO's ten best practices

The U.S. Government Accountability Office published its Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G) in December 2015, as a companion to its cost estimating guide. It lists ten best practices:

1. Capturing all activities
2. Sequencing all activities
3. Assigning resources to all activities
4. Establishing the duration of all activities
5. Verifying that the schedule can be traced horizontally and vertically
6. Confirming that the critical path is valid
7. Ensuring reasonable total float
8. Conducting a schedule risk analysis
9. Updating the schedule using actual progress and logic
10. Maintaining a baseline schedule

GAO maps these to four characteristics of a reliable schedule: comprehensive, well-constructed, credible, and controlled. The U.S. Department of Energy's project management newsletter, discussing the first practice, explains that the schedule should capture all activities needed to accomplish the deliverables in the WBS, including work by the owner as well as contractors, and warns that if activities are missing, the other best practices cannot be met: nobody can be sure the activities are in the right order, resources are properly allocated, the critical path is valid, or the risk analysis covers all risk. It also notes that schedules defined at too high a level can disguise risk in lower-level work, while too much detail makes progress hard to manage.

"Traced horizontally and vertically" (practice 5) means that the logic flows correctly from start to finish across the schedule (horizontal), and that detailed schedules roll up consistently to summary schedules and milestones (vertical).

The DCMA 14-point assessment

The U.S. Defense Contract Management Agency's 14-point assessment is a widely used set of structural checks on schedules. As summarized in Deltek's documentation for its Acumen analysis tool, the checks and their usual thresholds are:

The 44-working-day figure is roughly two months. Unusually high float often signals a missing logic link: an activity seems to have lots of slack only because nothing depends on it in the schedule, even though something does in reality.

These checks are about structure, not truth. A schedule can pass all fourteen and still have unrealistic durations. But a schedule that fails them, for example one full of hard constraints and missing links, cannot calculate a valid critical path, because its dates are typed in rather than driven by logic.

The PMBOK Guide view

The Project Management Institute's PMBOK Guide, Sixth Edition, describes Project Schedule Management as six processes: Plan Schedule Management, Define Activities, Sequence Activities, Estimate Activity Durations, Develop Schedule, and Control Schedule. These map neatly onto the steps described in this article: decide how scheduling will be done, list the activities, link them, estimate durations, calculate the schedule, and then control it against the baseline.

Building a schedule: a practical sequence

1. Start from the scope. Build or obtain the WBS so the schedule covers all the work.
2. Define activities for each work package at a level of detail that can be managed. Use long-duration planning packages for work far in the future and detail them as it approaches.
3. Sequence activities with logic links, mostly finish-to-start, so that every activity except the first has a predecessor and every activity except the last has a successor.
4. Estimate durations using expert judgment, historical data, or three-point estimates, and record the basis for each estimate.
5. Assign resources and check for overloads.
6. Calculate the schedule with CPM and examine the critical path. Does it make sense? Does it run through the work you expect to be hardest?
7. Check float. Very high float often means missing logic; negative float means the plan cannot meet a constraint.
8. Run a schedule risk analysis to understand the range of possible finish dates.
9. Review with the people doing the work. A schedule nobody believes will not be followed.
10. Baseline it, then update it regularly with actual progress.

Common pitfalls

• Missing work. Testing, reviews, approvals, procurement lead times, and customer-side activities are the usual omissions. GAO's first best practice exists for this reason.
• Hard-coded dates instead of logic. Typing dates into a schedule rather than letting dependencies calculate them breaks the critical path. When something slips, nothing downstream moves.
• Dangling activities. Activities with no successor can slip forever without affecting the project finish in the schedule, even though they matter in reality.
• Overuse of lags. A lag of "10 days" often hides real work, such as a review or a delivery, that should be its own activity with its own owner.
• Single-point optimism. Estimates that assume everything goes well. Daniel Kahneman and Amos Tversky named the tendency to underestimate task durations the planning fallacy in 1979. Wikipedia's article on the planning fallacy gives the Sydney Opera House as an example: expected to be finished in 1963, a scaled-down version opened in 1973, and the original cost estimate of $7 million rose to $102 million.
• Ignoring resources. A logically valid schedule that needs the same person in three places at once is not a real schedule.
• Too much or too little detail. Too little hides risk; too much becomes unmanageable, as the Department of Energy's discussion of GAO practice 1 notes.
• Not updating. A schedule that is not updated stops being a management tool and becomes a historical document.
• Adding people to a late project. In The Mythical Man-Month (1975), Fred Brooks, drawing on his experience managing IBM's OS/360 project, argued that adding manpower to a late software project makes it later, because new people need training and add communication overhead. Brooks himself called this an outrageous oversimplification, but the general warning is widely accepted: crashing by adding people does not work equally well for every kind of task.

Misconceptions

"The Gantt chart is the schedule." A Gantt chart is a way to display a schedule. The schedule is the underlying model of activities, durations, logic, and resources. A bar chart drawn by hand without logic links looks like a schedule but cannot calculate anything.

"The critical path never changes." It changes whenever actual progress differs from the plan. A non-critical activity that uses up its float becomes critical. Monitoring near-critical paths is as important as monitoring the critical path itself.

"Float belongs to whoever owns the activity." Total float is shared by every activity on a path. If the first activity uses it all, the later ones have none left. Many contracts address who owns float because of this.

"If SPI is close to 1, we are on schedule." SPI measures the value of work done, not whether critical work is on time, and it drifts to 1 at completion regardless of lateness. Use it alongside critical path analysis.

"The expected PERT date is a safe commitment." It is roughly a coin flip. Commitments usually need a higher-confidence date or explicit schedule reserve.

"More detail always makes a better schedule." Detail beyond what can be managed and updated creates noise and hides the critical path.

"Agile projects do not have schedules." Agile teams plan in fixed-length iterations and track progress continuously, and larger agile programs still use release plans and milestone schedules. The schedule takes a different form, but the questions of sequence, capacity, and timing do not go away.

Frequently asked questions

What is the difference between a project plan and a project schedule?

A project plan covers the whole approach to the project: scope, budget, risk, quality, communication, and more. The schedule is the part that deals with time: activities, sequence, durations, dates, and resources. The Wikipedia article calls the schedule the core of the project plan.

What is the critical path, in one sentence?

It is the longest chain of dependent activities through the project, and therefore the chain that determines the earliest possible finish date.

Can a project have more than one critical path?

Yes. In the worked example, expediting the permit created two critical paths of equal length. Projects with several parallel critical or near-critical paths are riskier because a delay on any of them delays the project.

What is the difference between total float and free float?

Total float is how long an activity can be delayed without delaying the project finish. Free float is how long it can be delayed without delaying the next activity. Free float is always less than or equal to total float.

Is CPM or PERT better?

They answer different questions. CPM calculates dates and the critical path from single duration estimates. PERT adds an estimate of uncertainty from three-point estimates. Modern practice typically uses CPM logic with a Monte Carlo schedule risk analysis, which extends PERT's idea to all paths.

How often should a schedule be updated?

Often enough to manage the project. Wikipedia's article says weekly updates are best for many projects, and GAO's best practices require updates based on actual progress and logic. Very short projects may need daily updates; long programs often update monthly at the summary level and more often at the working level.

What is an integrated master schedule?

An integrated master schedule (IMS) is a single, logically linked schedule covering all the work on a program, including government, prime contractor, subcontractor, and key vendor work. The Department of Energy describes a project IMS as a collection point for all work scopes needed to complete the project, not simply the prime contractor's schedule.

What software is used for scheduling?

Many tools exist, from spreadsheets and simple Gantt chart applications to enterprise scheduling systems. Primavera and Microsoft Project have been widely used since the PC era of the 1980s. The method matters more than the tool: a schedule built with sound logic in a simple tool is more useful than a poorly built schedule in an expensive one.

Summary

A project schedule is a model of when and in what order a project's work will happen. Its modern methods grew from Gantt's bar charts of the 1910s and from the critical path method and PERT, developed in the late 1950s at DuPont and Remington Rand and in the U.S. Navy's Polaris program. CPM finds the longest chain of dependent work and the float on everything else; PERT and Monte Carlo simulation add an honest picture of uncertainty; earned value and earned schedule measure progress against a baseline. Auditors such as GAO judge schedules on whether they are comprehensive, well-constructed, credible, and controlled. The most common failures are not mathematical but human: missing work, optimistic estimates, hard-coded dates, and schedules that stop being updated once they are approved.

Sources

• Schedule (project management) (Wikipedia))
• Critical path method (Wikipedia)
• Program evaluation and review technique (Wikipedia)
• Gantt chart (Wikipedia)
• Patrick Weaver, "A Brief History of Scheduling," Mosaic Projects
• Kelley and Walker, "Critical-path planning and scheduling" (1959), DOI
• GAO-16-89G, Schedule Assessment Guide: Best Practices for Project Schedules
• U.S. Department of Energy PM Newsletter, July 2022: GAO Best Practice #1
• Deltek Acumen: DCMA 14 Point Assessment Metric Descriptions
• Earned value management (Wikipedia)
• Earned schedule (Wikipedia)
• Critical chain project management (Wikipedia)
• Planning fallacy (Wikipedia)
• The Mythical Man-Month (Wikipedia)
• PMBOK Guide, Sixth Edition, Project Schedule Management (O'Reilly listing)